JP7246055B1 - サーバ及び方法 - Google Patents

Abstract

【課題】開始されたライブ配信に視聴者を集める仕組みを提供することで配信者を支援するサーバ及び方法を提供する。【解決手段】サーバ、配信者側のユーザ端末及び視聴者側のユーザ端末が、有線または無線の各種ネットワークにより互いに通信可能に接続されるライブ配信システムにおいて、サーバは、優先提案対象のライブ配信を特定する優先提案対象特定部と、特定した優先提案対象のライブ配信に対応する被提案ユーザ数を算出する被提案ユーザ数算出部と、取得した被提案ユーザ数に対応する数のアクティブユーザを選択することでユーザプールを生成するユーザプール生成部と、生成したユーザグループに含まれるユーザの端末において優先提案対象のライブ配信が他のライブ配信よりも優先して提案されるように、当該ユーザに提案するライブ配信のリストを設定するおすすめリスト設定部と、を備える。【選択図】図３

Description

本開示は、サーバ及び方法に関する。

ＩＴ技術の発展と共に情報のやりとりの様も移り変わってきた。昭和の時代には新聞やテレビなどの一方通行の情報伝達が主であった。平成になると、ケータイやパソコンが普及し、インターネットの通信速度も大きく改善されたので、チャットサービスなどの即時双方向通信サービスが台頭し、また記憶コストの低減に伴ってオンデマンド型の動画配信サービスが受け入れられていった。そして、現在、令和の時代となり、スマートフォンの高機能化や５Ｇに代表されるネットワークの速度のさらなる向上を受けて、動画によるリアルタイムのコミュニケーションを実現するサービス、特にライブ配信（Live Streaming）サービスが急速に認知度を高めている。ライブ配信サービスは、離れた場所にいても皆が同じ楽しい時間を共有できるサービスとして、若者を中心に利用者が拡大している。

ライブ配信プラットフォームでは、配信者は自分が好きなときにライブ配信を開始することができ、視聴者は自分の好きなときに興味のあるライブ配信を視聴できる。特許文献１には、機械学習を用いてライブストリーミングコンテンツを推奨する技術が開示されている。

特表２０２０－５２１２０７号公報

通常、配信者がライブ配信を開始した直後は視聴者はおらず、ライブ配信を続けていくうちに視聴者が集まってくる。人気のある配信者のライブ配信であればすぐに視聴者が集まるが、他の大抵の配信者、特に新規の配信者、のライブ配信が最初の視聴者を得るまでには比較的時間がかかる傾向にある。視聴者の集まりが悪い場合、配信者がライブ配信を止めてしまう可能性も高くなる。

本開示はこうした課題に鑑みてなされたものであり、その目的は、開始されたライブ配信に視聴者を集める仕組みを提供することで配信者を支援することができる技術の提供にある。

本発明のある態様は、サーバに関する。このサーバは、優先提案対象のライブ配信を特定する手段と、特定された優先提案対象のライブ配信に対応する被提案ユーザ数を取得する手段と、取得された被提案ユーザ数に対応する数のユーザを選択することでユーザ群を生成する手段と、生成されたユーザ群に含まれるユーザの端末において優先提案対象のライブ配信が他のライブ配信よりも優先して提案されるように、当該ユーザに提案するライブ配信のリストを設定する手段と、を備える。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本開示の実施の形態に係るライブ配信システムの構成を示す模式図である。 図１のユーザ端末の機能および構成を示すブロック図である。 図１のサーバの機能および構成を示すブロック図である。 図３のストリームＤＢの一例を示すデータ構造図である。 図３のユーザＤＢの一例を示すデータ構造図である。 図３のギフトＤＢの一例を示すデータ構造図である。 図３のクリック率ＤＢの一例を示すデータ構造図である。 図３の設定ＤＢの一例を示すデータ構造図である。 図３のユーザプールテーブルの一例を示すデータ構造図である。 アクティブユーザのユーザ端末のディスプレイに表示されるおすすめライブ配信画面の代表画面図である。 図１１（Ａ）、（Ｂ）は、優先提案対象特定部における優先提案対象のライブ配信の特定方法の説明図である。 図１２（Ａ）、図１２（Ｂ）、図１２（Ｃ）は、おすすめライブ配信リストの生成の過程を示す図である。 優先提案対象のライブ配信を評価する際のサーバにおける一連の処理の流れを示すフローチャートである。 本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。

以下、各図面に示される同一または同等の構成要素、部材、処理、信号には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。

実施の形態に係るライブ配信システムでは、配信者がライブ配信（以下、対象ライブ配信という）を始めると、当該配信者のレベルに応じた被提案ユーザ数が算出される。ライブ配信システムは、ライブ配信プラットフォームにログインしているアクティブユーザと対象ライブ配信との類似スコアを算出する。ライブ配信システムは、類似スコアが高い方から被提案ユーザ数に等しい人数のユーザを選択することで、対象ライブ配信に対応するユーザプール（ユーザ群）を生成する。ライブ配信システムは、ユーザプールに含まれる各ユーザのユーザ端末に、対象ライブ配信をおすすめの上位に表示するよう設定されたおすすめライブ配信リストを送信する。当該ユーザ端末は、受信したおすすめライブ配信リストに基づいておすすめのライブ配信のサムネイルをおすすめライブ配信画面に表示させる。これにより、被提案ユーザ数に対応する人数のユーザのおすすめライブ配信画面において対象ライブ配信が上位に表示される。したがって、対象ライブ配信に視聴者が集まりやすくなり、配信者は配信を続けるモチベーションを得ることができる。併せて、対象ライブ配信を上位に表示する対象のユーザの数を被提案ユーザ数で制限することにより、同時期に多くのライブ配信が開始された場合でも各ライブ配信が上位に表示される期間を十分にとることができる。

図１は、本開示の実施の形態に係るライブ配信システム１の構成を示す模式図である。ライブ配信システム１は、配信者（ライバー、ストリーマ（Streamer）ともいう）ＬＶと視聴者（オーディエンスともいう）ＡＵ（ＡＵ１、ＡＵ２、…）とがリアルタイムでやりとりできる双方向型のライブ配信サービスを提供する。図１に示すように、ライブ配信システム１は、サーバ１０と、配信者側のユーザ端末２０と、視聴者側のユーザ端末３０（３０ａ、３０ｂ、…）と、を備える。配信者および視聴者をユーザと総称することがある。サーバ１０は、ネットワークＮＷに接続された一または複数の情報処理装置によって構成されてもよい。ユーザ端末２０、３０は例えばスマートフォンやタブレット型端末やラップトップＰＣやレコーダや携帯型ゲーム機やウェアラブル装置などの携帯端末であってもよいし、デスクトップＰＣなどの据え置き型の装置であってもよい。サーバ１０、ユーザ端末２０およびユーザ端末３０は、有線または無線の各種ネットワークＮＷにより互いに通信可能に接続される。

ライブ配信システム１には、配信者ＬＶと、視聴者ＡＵと、サーバ１０を管理する管理者（不図示）と、が関与する。配信者ＬＶは、自分の歌や、トーク、パフォーマンス、占い、ゲーム実況などのコンテンツを自身のユーザ端末２０で録音・録画してそのままサーバ１０にアップロードすることで、リアルタイムにコンテンツを発信する者である。管理者は、サーバ１０においてコンテンツのライブ配信のためのプラットフォームを提供し、また、配信者ＬＶと視聴者ＡＵとのリアルタイムのやりとりを仲介または管理する。視聴者ＡＵは、ユーザ端末３０でプラットフォームにアクセスして所望のコンテンツを選択し、視聴する。このコンテンツのライブ配信中に視聴者ＡＵがユーザ端末３０を介してコメントをしたり応援したり占いを依頼したりするための操作を行い、当該コンテンツを提供する配信者ＬＶがそのようなコメントや応援や依頼に反応し、当該反応が映像および／または音声で視聴者ＡＵに伝わることで、双方向のコミュニケーションが成立する。

本明細書において「ライブ配信」は、配信者ＬＶのユーザ端末２０で録音・録画されたコンテンツが実質的にリアルタイムで視聴者ＡＵのユーザ端末３０で再生され視聴可能となる状態を実現するデータの伝送態様を意味するものであってもよく、またはそのような伝送態様により実現される配信そのものを意味してもよい。ライブ配信は、HTTP Live StreamingやCommon Media Application FormatやWeb Real-Time CommunicationsやReal-Time Messaging ProtocolやMPEG DASHなどの既存のライブ配信技術を用いて実現されてもよい。ライブ配信は、配信者ＬＶがコンテンツを録音・録画しているときに、視聴者ＡＵが所定の遅延をもって当該コンテンツを視聴可能な伝送態様を含む。遅延の大きさについて、少なくとも、配信者ＬＶと視聴者ＡＵとのやりとりが成立する程度の大きさの遅延は許される。ただし、ライブ配信は、コンテンツを録音・録画したデータ全体をいったんサーバに保存し、その後の任意のタイミングでユーザからの求めに応じて当該データをサーバからユーザに提供するいわゆるオンデマンド型の配信とは区別される。

本明細書において「動画データ」は、ユーザ端末２０、３０の撮像機能により生成される画像データ（ビデオデータともいう）と、ユーザ端末２０、３０の音声入力機能により生成される音声データ（オーディオデータともいう）と、を含むデータである。動画データは、ユーザ端末２０、３０で再生されることで、ユーザによるコンテンツの視聴を可能とする。本実施の形態では、動画データが配信者のユーザ端末で生成されてから視聴者のユーザ端末で再生されるまでの間に、圧縮や伸張や符号化や復号やトランスコーディングなどの、データの形式やサイズや仕様を変更する処理が行われることが想定されている。このような処理の前後で動画データが表す内容（例えば、動画像や音声）は実質的に変わらないので、本実施の形態ではそのような処理が行われた後の動画データはそのような処理が行われる前の動画データと同じであるとして説明する。すなわち、動画データが配信者のユーザ端末で生成されてからサーバ１０を経由して視聴者のユーザ端末で再生される場合、配信者のユーザ端末で生成された動画データと、サーバ１０を通過する動画データと、視聴者のユーザ端末で受信されて再生される動画データと、は全て同じ動画データである。

図１の例では、配信者ＬＶがトークをライブ配信している。配信者ＬＶのユーザ端末２０はトークを行っている配信者ＬＶの像および音声を録画・録音することで動画データを生成し、ネットワークＮＷを介してサーバ１０に送信する。併せてユーザ端末２０は、録画された配信者ＬＶの動画像ＶＤをユーザ端末２０のディスプレイに表示させることで、配信者ＬＶによる配信内容の確認を可能とする。

配信者ＬＶのライブ配信の視聴をプラットフォームに要求した視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂはそれぞれ、ネットワークＮＷを介してライブ配信に係る動画データを受信し、受信した動画データを再生することでディスプレイに動画像ＶＤ１、ＶＤ２を表示させると共にスピーカーから音声を出力する。各ユーザ端末３０ａ、３０ｂで表示される動画像ＶＤ１、ＶＤ２は配信者ＬＶのユーザ端末２０が撮像した動画像ＶＤと実質的に同一であり、各ユーザ端末３０ａ、３０ｂで出力される音声も配信者ＬＶのユーザ端末２０が録音した音声と実質的に同一である。

配信者ＬＶのユーザ端末２０における録音・録画と、視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂにおける動画データの再生と、は実質的に同時に行われる。配信者ＬＶのトークの内容についてひとりの視聴者ＡＵ１がコメントをユーザ端末３０ａに入力すると、サーバ１０は当該コメントをリアルタイムで配信者ＬＶのユーザ端末２０に表示させると共に各視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂにも表示させる。当該コメントを読んだ配信者ＬＶがその内容に被せたトークを展開すると、そのトークの動画像と音声が各視聴者ＡＵ１、ＡＵ２のユーザ端末３０ａ、３０ｂで出力され、これにより配信者ＬＶと視聴者ＡＵ１との会話が成立したと認識される。このように、ライブ配信システム１では、一方通行でない双方向のコミュニケーションを可能とするライブ配信が実現される。

図２は、図１のユーザ端末２０の機能および構成を示すブロック図である。ユーザ端末３０はユーザ端末２０と同様の機能および構成を有する。図２および以後のブロック図に示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組み合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

配信者ＬＶおよび視聴者ＡＵは、ダウンロードサイトからネットワークＮＷを介して、本実施の形態に係るライブ配信アプリケーションプログラム（以下、ライブ配信アプリという）をユーザ端末２０、３０にダウンロードし、インストールする。あるいはまた、ライブ配信アプリはユーザ端末２０、３０にプリインストールされていてもよい。ライブ配信アプリがユーザ端末２０、３０により実行されることにより、ユーザ端末２０、３０はネットワークＮＷを介してサーバ１０と通信し、各種機能を実現する。以下、ユーザ端末２０、３０（のＣＰＵなどのプロセッサ）がライブ配信アプリを実行することにより実現する機能をユーザ端末２０、３０の機能として説明する。それらの機能は実際はライブ配信アプリがユーザ端末２０、３０に実現させる機能である。なお、他の実施の形態では、これらの機能は、サーバ１０からユーザ端末２０、３０のウェブブラウザにネットワークＮＷを介して送信され、そのウェブブラウザによって実行される、ＨＴＭＬ（HyperText Markup Language）などのプログラミング言語により記述されたコンピュータプログラムにより実現されてもよい。

ユーザ端末２０は、ユーザの像および音声を記録した動画データを生成してサーバ１０に提供する配信部１００と、サーバ１０から動画データを取得して再生する視聴部２００と、を備える。ユーザは、配信を行う場合は配信部１００を、視聴を行う場合は視聴部２００を、それぞれ起動する。配信部１００がアクティブとなっているユーザ端末は配信者側、つまり動画データの生成側のユーザ端末であり、視聴部２００がアクティブとなっているユーザ端末は視聴者側、つまり動画データの再生側のユーザ端末である。

ライブ配信を配信している配信者、ライブ配信を視聴している視聴者の他に、ライブ配信プラットフォームにログインしたが配信も視聴もしていないユーザもいる。このようなユーザをアクティブユーザという。

配信部１００は、撮像制御部１０２と、音声制御部１０４と、動画送信部１０６と、配信側ＵＩ制御部１０８と、配信側通信部１１０と、を含む。撮像制御部１０２は図２では不図示のカメラと接続され、カメラによる撮像を制御する。撮像制御部１０２はカメラから画像データを取得する。音声制御部１０４は図２では不図示のマイクロフォンと接続され、マイクロフォンによる音声入力を制御する。音声制御部１０４は、マイクロフォンから音声データを取得する。動画送信部１０６は、撮像制御部１０２により取得された画像データおよび音声制御部１０４により取得された音声データを含む動画データを、ネットワークＮＷを介してサーバ１０に送信する。動画送信部１０６による動画データの送信はリアルタイムで行われる。すなわち、撮像制御部１０２および音声制御部１０４による動画データの生成と、生成された動画データの動画送信部１０６による送信と、は実質的に同時に行われる。

配信側ＵＩ制御部１０８は、配信者向けのＵＩを制御する。配信側ＵＩ制御部１０８は、図２では不図示のディスプレイと接続され、動画送信部１０６による送信対象となっている動画データを再生することにより動画像をディスプレイに表示させる。配信側ＵＩ制御部１０８は、図２では不図示のタッチパネルやキーボードやディスプレイなどの入力手段と接続され、それら入力手段を介して配信者による入力を取得する。配信側ＵＩ制御部１０８は、動画像に所定のフレーム画像を重畳させる。フレーム画像は、配信者から入力を受け付けるための様々なユーザインタフェースオブジェクト（以下、単にオブジェクトという）と、視聴者により入力されたコメントと、サーバ１０から取得した情報と、を含む。配信側ＵＩ制御部１０８は例えば配信者によるオブジェクトに対するタップ入力を受け付ける。

配信側通信部１１０は、ライブ配信中のサーバ１０との間の通信を制御する。配信側通信部１１０は、配信側ＵＩ制御部１０８が取得した配信者による入力の内容を、サーバ１０にネットワークＮＷを介して送信する。配信側通信部１１０は、ライブ配信に関連付けられた各種の情報をサーバ１０からネットワークＮＷを介して受信する。

視聴部２００は、視聴側ＵＩ制御部２０２と、視聴側通信部２０４と、を含む。視聴側通信部２０４は、ライブ配信中のサーバ１０との間の通信を制御する。視聴側通信部２０４は、ネットワークＮＷを介してサーバ１０から、配信者と視聴者とが参加するライブ配信に係る動画データを受信する。

視聴側ＵＩ制御部２０２は、視聴者向けのＵＩを制御する。視聴側ＵＩ制御部２０２は、図２では不図示のディスプレイおよびスピーカと接続され、受信された動画データを再生することにより動画像をディスプレイに表示させると共に音声をスピーカから出力させる。ディスプレイに画像が出力されると共にスピーカから音声が出力されることを、合わせて「動画データが再生」されていると言うことができる。視聴側ＵＩ制御部２０２は、図２では不図示のタッチパネルやキーボードやディスプレイなどの入力手段と接続され、それら入力手段を介して視聴者による入力を取得する。視聴側ＵＩ制御部２０２は、サーバ１０から取得された動画データの画像に所定のフレーム画像を重畳させる。フレーム画像は、視聴者から入力を受け付けるための様々なオブジェクトと、視聴者により入力されたコメントと、サーバ１０から取得した情報と、を含む。視聴側通信部２０４は、視聴側ＵＩ制御部２０２が取得した視聴者による入力の内容を、ネットワークＮＷを介してサーバ１０に送信する。

図１０は、アクティブユーザのユーザ端末３０のディスプレイに表示されるおすすめライブ配信画面６００の代表画面図である。視聴側ＵＩ制御部２０２は、サーバ１０から受信したおすすめライブ配信リストに基づいておすすめライブ配信画面６００を生成し、ディスプレイに表示させる。視聴側通信部２０４は、おすすめライブ配信画面６００におけるアクティブユーザによるライブ配信の選択（例えば、ライブ配信のサムネイルのタップ）を受け付けると、選択されたライブ配信のストリームＩＤを含む配信要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。

おすすめライブ配信画面６００は、おすすめライブ配信リストに含まれる各ライブ配信を示すサムネイル６０２を含む。図１０の例では、おすすめライブ配信画面６００は、一段に２つのサムネイル６０２が表示されるリスト表示が上下方向にスクロール可能に構成される。本明細書では、おすすめライブ配信画面６００におけるサムネイルの表示位置の番号を以下のように定義する。
１：最上段の左
２：最上段の右
３：２段目の左
４：２段目の右
…
図１０において便宜的に表示位置の番号を括弧で示している。おすすめライブ配信画面６００は、それが開かれた直後は一番上までスクロールされた状態で表示される。図１０の例では、おすすめライブ配信画面６００が開かれた直後は最上段および２段目は必ず表示される。したがって、最上段および２段目のサムネイルは他の位置のサムネイルよりも目立つ位置にあるといえる。すなわち、表示位置の数字が小さいほど目立つ位置または優先して提案される位置となる。

図３は、図１のサーバ１０の機能および構成を示すブロック図である。サーバ１０は、配信情報提供部３０２と、中継部３０４と、ギフト処理部３０８と、支払い処理部３１０と、配信評価部３１２と、ストリームＤＢ３１４と、ユーザＤＢ３１８と、ギフトＤＢ３２０と、クリック率ＤＢ３２２と、設定ＤＢ３２４と、ユーザプールテーブル３２６と、を備える。

図４は、図３のストリームＤＢ３１４の一例を示すデータ構造図である。ストリームＤＢ３１４は現在行われているライブ配信の情報を保持する。ストリームＤＢ３１４は、ライブ配信システム１が提供するライブ配信プラットフォームにおいてライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者を特定するユーザＩＤである配信者ＩＤと、当該ライブ配信の視聴者を特定するユーザＩＤである視聴者ＩＤと、当該ライブ配信の定着視聴者またはエンゲージド視聴者（engaged viewers）の数と、当該ライブ配信の開始時刻と、当該ライブ配信の内容を表す内容タグと、当該ライブ配信に付与された評価と、を対応付けて保持する。

本実施の形態に係るライブ配信システム１が提供するライブ配信プラットフォームでは、ユーザがライブ配信を行う場合そのユーザは配信者となり、また同じユーザが他のユーザが配信するライブ配信を視聴する場合は視聴者となる。したがって、配信者・視聴者の別は固定的なものではなく、あるとき配信者ＩＤとして登録されていたユーザＩＤが別のタイミングでは視聴者ＩＤとして登録されることもある。

ライブ配信の定着視聴者は、当該ライブ配信に定着している、または定着する蓋然性の高い視聴者を指す。例えば、ライブ配信の定着視聴者は、当該ライブ配信の視聴者のうち、所定時間以上、例えば５分以上継続して当該ライブ配信を視聴している視聴者である。あるいはまた、ライブ配信の定着視聴者は、当該ライブ配信の視聴者のうち、所定量以上のギフティングを行った視聴者である。あるいはまた、ライブ配信の定着視聴者は、当該ライブ配信の視聴者のうち、所定量以上、例えば１０回以上のコメントを行った視聴者である。あるいはまた、継続視聴時間、ギフティングおよびコメントの３つの条件を適宜組み合わせることで定着視聴者を判定してもよい。

ライブ配信の内容タグは、配信者がライブ配信を始める際に指定したタグであってもよいし、機械学習により生成されたモデルがライブ配信をリアルタイムで解析することで得られるタグであってもよい

図５は、図３のユーザＤＢ３１８の一例を示すデータ構造図である。ユーザＤＢ３１８は、ユーザに関する情報を保持する。ユーザＤＢ３１８は、ユーザを特定するユーザＩＤと、当該ユーザが有しているポイントと、当該ユーザに付与された報酬と、当該ユーザのレベルと、当該ユーザの属性と、当該ユーザのステータスと、を対応付けて保持する。ユーザの属性は、当該ユーザの年齢の範囲と、当該ユーザの性別と、当該ユーザの髪の色と、を含む。

ポイントは、ライブ配信プラットフォーム内で流通する電子的価値である。ユーザはクレジットカードや他の決済手段によりポイントを購入する。報酬はライブ配信プラットフォーム内で定義される電子的価値であり、配信者がライブ配信プラットフォームの管理者から受け取る金銭の額を決めるための指標である。ライブ配信プラットフォームでは、ライブ配信内やライブ配信外で視聴者が配信者にギフトを贈ると、視聴者のポイントが消費され、併せて配信者の報酬が相応分だけ増加する。

レベルは、ライブ配信プラットフォームにおけるユーザの配信者としての実績を示す指標である。他の実施の形態では、レベルは、ライブ配信プラットフォームにおけるユーザの視聴者としての実績を示す指標であってもよいし、ユーザの配信者としての実績および視聴者としての実績を合わせて示す指標であってもよい。レベルは、ライブ配信を行った回数、ライブ配信の総配信時間、ライブ配信の総被視聴時間、ライブ配信の視聴者としての総視聴時間、ギフトを贈った回数および／または量、ギフトをもらった回数および／または量、コメントの回数などに応じて増減してもよい。あるいはまた、配信者のレベルは、当該配信者に対するレビューや当該配信者のライブ配信の視聴者満足度や当該配信者のライブ配信内でなされたコメントを基に管理者により評価、決定されてもよい。あるいはまた、レベルは、所定のルールまたは機械学習モデルにより自動的に決定されてもよい。

ステータスは、アクティブユーザである場合は「アクティブ」、ライブ配信を行っている場合は「配信中」、ライブ配信を視聴している場合は「視聴中」、ライブ配信プラットフォームにログインしていない場合は「ログアウト」、となる。

図６は、図３のギフトＤＢ３２０の一例を示すデータ構造図である。ギフトＤＢ３２０は、ライブ配信において視聴者が使用可能なギフトに関する情報を保持する。ギフトは、以下の特徴を有する電子データである。
・ポイントや金銭を対価として購入可能、または無料で付与可能。
・視聴者が配信者に贈ることができるもの。配信者にギフトを贈ることを、ギフトを使用する、またはギフトを投げるともいう。
・ギフトの購入と使用とがセットで同時に発生するタイプのものもあれば、購入した後、視聴者が任意のタイミングで使用可能なタイプのものもある。
・視聴者が配信者にギフトを贈ると、その配信者に相応の報酬が付与される。
・ギフトが使用された場合、ギフトに関連付けられた効果が生じることがある。例えば、ギフトに対応するエフェクトがライブ配信ルーム画面に表れる。

ギフトＤＢ３２０は、ギフトを特定するギフトＩＤと、当該ギフトを配信者に贈った場合に当該配信者に付与される報酬である付与報酬と、当該ギフトを使用する際に支払うべき対価である対価ポイントと、を対応付けて保持する。視聴者は、ライブ配信の視聴中に、所望のギフトの対価ポイントを支払うことで配信者に当該ギフトを贈ることができる。この対価ポイントの支払いは適宜の電子的決済手段により行われてもよく、例えば対価ポイントを視聴者が管理者に支払うことで行われてもよい。あるいはまた、銀行振込やクレジットカードによる支払いが用いられてもよい。付与報酬と対価ポイントとの関係は管理者が任意に設定可能である。例えば、付与報酬＝対価ポイントに設定してもよい。または付与報酬に１．２などの所定の係数を乗じて得られるポイントを対価ポイントに設定してもよいし、付与報酬に所定の手数料ポイントを加算して得られるポイントを対価ポイントに設定してもよい。

図７は、図３のクリック率ＤＢ３２２の一例を示すデータ構造図である。クリック率ＤＢ３２２は、ライブ配信をユーザに優先して提案する際のサムネイルの表示位置の範囲と、平均クリック率と、を対応付けて保持する。平均クリック率または平均変換率（Average Conversion Rate）は、おすすめライブ配信画面６００を開いたユーザのうち、対応する範囲内の表示位置のうちのひとつに表示されたサムネイルをクリックしてライブ配信の視聴を開始したユーザの割合である。平均クリック率は過去のライブ配信の視聴履歴を解析することで算出されてもよい。本実施の形態では、表示位置の範囲ごとに、その範囲内のいずれかの表示位置のサムネイルがクリックされる確率をまず算出し、その確率を範囲内の表示位置の個数で割ることで平均クリック率を算出する。図７の例では、過去のデータから例えば表示位置１のクリック率が１５％、表示位置２のクリック率が１３％、表示位置３のクリック率が１１％、表示位置４のクリック率が９％、表示位置５のクリック率が７％、表示位置６のクリック率が５％、であった場合、まず表示位置の範囲１～６のクリック率を１５＋１３＋１１＋９＋７＋５＝６０と算出する。この算出された値６０を表示位置の個数６で除すことで、表示位置の範囲１～６に対応する平均クリック率１０％が算出される。

クリック率ＤＢ３２２に保持される表示位置の範囲は、最もクリック率の高い表示位置１から始まる範囲であるから、当該範囲内の表示位置にサムネイルが表示される場合、そのサムネイルのライブ配信は当該範囲外の表示位置にサムネイルが表示されるライブ配信よりも優先してユーザに提案される。クリック率ＤＢ３２２に保持される表示位置の範囲を優先範囲と称す。平均クリック率は、ライブ配信が優先して提案された場合に当該ライブ配信がユーザに選択される確率の一例である。他の実施の形態では、平均クリック率に代えて表示位置ごとのクリック率を用いてもよい。平均クリック率はユーザのレベルとは無関係なパラメータである。

図８は、図３の設定ＤＢ３２４の一例を示すデータ構造図である。設定ＤＢ３２４は、被提案ユーザ数を算出するためのパラメータの値を保持する。設定ＤＢ３２４は、レベルの範囲と、必要定着視聴者数と、必要クリック数と、を対応付けて保持する。

必要定着視聴者数は、配信者の配信継続率により設定されるパラメータであり、配信者のレベルが高いほど被提案ユーザ数が多くなるよう設定される。図８の例では、レベルが高くなるほど必要定着視聴者数は多くなる。

必要定着視聴者数について、本発明者は、ライブ配信の配信時間と、そのライブ配信の定着視聴者数と、の間に相関があることを見出した。特に本発明者は、定着視聴者数が多いほど配信者がライブ配信をより長く続けることを見出した。この知見から、本明細書では、配信者の配信継続率を、当該配信者が所定時間、例えば３０分、以上ライブ配信を続ける確率と定義する。配信者の必要定着視聴者数を、当該配信者の配信継続率が所定値、例えば８０％、を上回るために最低限必要な定着視聴者数として定義する。図８の例では、レベルの範囲ごとに必要定着視聴者数を設定している。必要定着視聴者数は過去のライブ配信の視聴履歴を解析することで求められてもよい。

レベルが高くなるほど必要定着視聴者数が多くなる理由としては、配信者のレベルが高くなるほどライブ配信に慣れており、ライブ配信への期待も大きいので、より多くの定着視聴者を必要とするからであると考えられる。あるいは、レベルが低く経験が浅いうちは少ない数の視聴者でも嬉しく感じるが、経験を積むに従い視聴者が少ないと物足りなさを感じるようになるからであると考えられる。

必要クリック数またはクリックエンゲージ率（ClickToEngage Rate）は、視聴者の視聴継続率により設定されるパラメータであり、配信者のレベルが高いほど被提案ユーザ数が少なくなるよう設定される。図８の例では、レベルが高くなるほど必要クリック数は少なくなる。配信者の必要クリック数は、当該配信者が当該配信者のライブ配信を訪れた視聴者を定着視聴者に変換できる確率に対応する数である。例えば、必要クリック数＝３は、３人の視聴者がライブ配信を訪れた場合、そのうちの１人が定着視聴者となる確率が所定値、例えば８０％、を上回ることを示す。視聴者の視聴継続率を、当該視聴者が定着視聴者となる確率と定義すると、必要クリック数は視聴継続率の逆数に対応する。例えば、必要クリック数＝３は視聴継続率＝１／３に対応し、これはすなわち約３３％の視聴継続率であれば１人の定着視聴者を得るために３人の視聴者が必要であることを示す。必要クリック数は過去のライブ配信の視聴履歴を解析することで求められてもよい。

レベルが高くなるほど必要クリック数が少なくなる理由としては、配信者が経験を積むほど配信の質や配信者の技術が向上し、視聴者が定着しやすくなることがある。

図９は、図３のユーザプールテーブル３２６の一例を示すデータ構造図である。ユーザプールテーブル３２６は開始された特定のライブ配信に対応付けら、そのようなライブ配信ごとに設けられる。ユーザプールテーブル３２６は、番号と、アクティブユーザのユーザＩＤと、特定のライブ配信と当該アクティブユーザとの類似スコアと、を対応付けて保持する。ユーザプールテーブル３２６には、特定のライブ配信について算出された被提案ユーザ数に対応する数のユーザＩＤ、特に被提案ユーザ数と同数のユーザＩＤ、が保持される。

図３に戻り、配信情報提供部３０２は、ネットワークＮＷを介して、配信者のユーザ端末２０からライブ配信の開始を示すライブ配信開始信号を受信すると、当該ライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者の配信者ＩＤと、当該ライブ配信の開始時刻と、利用可能であれば当該ライブ配信の内容タグと、をストリームＤＢ３１４に登録する。配信情報提供部３０２は、ストリームＤＢ３１４等を参照しておすすめライブ配信リストを生成し、ネットワークＮＷを介してアクティブユーザのユーザ端末に送信する。配信情報提供部３０２は、優先提案対象特定部３３０と、被提案ユーザ数算出部３３２と、ユーザプール生成部３３４と、おすすめリスト設定部３３６と、おすすめリスト送信部３３８と、を含む。

優先提案対象特定部３３０は、ライブ配信の開始を示すライブ配信開始信号の受信に応じて当該ライブ配信を優先提案対象のライブ配信として特定する。優先提案対象特定部３３０は、周期的に（例えば１日１回、１時間に１回、１０分に１回など）優先提案対象のライブ配信を特定するための処理を行う。優先提案対象特定部３３０における特定の方法には、所定時刻から後ろ向き、つまり時間を遡るようにして優先提案対象のライブ配信を特定するバッチ処理型の特定方法と、所定時刻から前向き、つまり時間の経過に伴って優先提案対象のライブ配信を特定するリアルタイム処理型の特定方法と、がある。

図１１（Ａ）、（Ｂ）は、優先提案対象特定部３３０における優先提案対象のライブ配信の特定方法の説明図である。図１１（Ａ）はバッチ処理型の特定方法を説明し、図１１（Ｂ）はリアルタイム型の特定方法を説明する。図１１（Ａ）において黒丸はライブ配信の開始を示し、黒丸から延びる実線はライブ配信が継続していることを表す。図１１（Ｂ）につても同様である。

（バッチ処理型）
優先提案対象特定部３３０は、所定の時刻が到来すると、当該所定の時刻を終点時刻とし、終点時刻から所定の時間（例えば、３０分）遡った時刻を始点時刻とする特定期間４０２を設定する。優先提案対象特定部３３０はストリームＤＢ３１４を参照し、開始時刻が特定期間４０２内となるライブ配信を優先提案対象のライブ配信として特定する。ライブ配信開始信号が受信されて始めて開始時刻がストリームＤＢ３１４に登録され、開始時刻が特定期間４０２内となるライブ配信が優先提案対象のライブ配信として特定されるので、ライブ配信開始信号の受信に応じて優先提案対象のライブ配信が特定されているといえる。

図１１（Ａ）の例では、優先提案対象特定部３３０は１日１回、午前１０時に優先提案対象のライブ配信を特定する処理を行う。６月２０日午前１０時が到来すると、優先提案対象特定部３３０は、午前１０時を終点時刻とし、午前９時３０分を始点時刻とする特定期間４０２を設定する。優先提案対象特定部３３０はストリームＤＢ３１４を参照し、開始時刻が特定期間４０２内となるライブ配信「ＳＴ２」、「ＳＴ３」をそれぞれ優先提案対象のライブ配信として特定する。ライブ配信「ＳＴ１」は特定期間４０２の始点時刻よりも前に開始されているので、優先提案対象のライブ配信とはならない。６月２１日午前１０時が到来すると優先提案対象特定部３３０は同様の特定処理を行う。

（リアルタイム処理型）
優先提案対象特定部３３０は、所定の時刻が到来すると、当該所定の時刻を始点時刻とし、始点時刻から所定の時間（例えば、３０分）進んだ時刻を終点時刻とする特定期間４０４を設定する。優先提案対象特定部３３０は特定期間４０４中にライブ配信開始信号を受信すると、受信したライブ配信開始信号に係るライブ配信を優先提案対象のライブ配信として特定する。

図１１（Ｂ）の例では、優先提案対象特定部３３０は１日１回、午前１０時に優先提案対象のライブ配信を特定する処理を開始する。６月２０日午前１０時が到来すると、優先提案対象特定部３３０は、午前１０時を始点時刻とし、午前１０時３０分を終点時刻とする特定期間４０４を設定する。優先提案対象特定部３３０は特定期間４０４中ライブ配信開始信号を待ち受けるかまたはその有無を監視する。優先提案対象特定部３３０は、特定期間４０４中にライブ配信「ＳＴ４」の開始を示すライブ配信開始信号を受信すると、そのライブ配信「ＳＴ４」を優先提案対象のライブ配信として特定する。ライブ配信「ＳＴ５」は特定期間４０４の終点時刻よりも後に開始されているので、優先提案対象のライブ配信とはならない。ライブ配信「ＳＴ６」は特定期間４０４の始点時刻よりも前に開始されているので、優先提案対象のライブ配信とはならない。６月２１日午前１０時が到来すると優先提案対象特定部３３０は同様の特定処理を行う。

図３に戻り、被提案ユーザ数算出部３３２は、優先提案対象特定部３３０によって特定された優先提案対象のライブ配信に対応する被提案ユーザ数を取得する。被提案ユーザ数算出部３３２は、特定されたライブ配信の配信者のレベルに応じて被提案ユーザ数を決定する。被提案ユーザ数は必要定着視聴者数と必要クリック数と平均クリック率とに基づいて決定される。

被提案ユーザ数算出部３３２は、ストリームＤＢ３１４を参照し、優先提案対象のライブ配信の配信者ＩＤを特定する。被提案ユーザ数算出部３３２は、ユーザＤＢ３１８を参照し、特定された配信者ＩＤに対応するレベルを特定する。被提案ユーザ数算出部３３２は、設定ＤＢ３２４を参照し、特定されたレベルを含むレベル範囲に対応する必要定着視聴者数と必要クリック数とを特定する。被提案ユーザ数算出部３３２は、クリック率ＤＢ３２２を参照し、所定の優先設定に対応する平均クリック率を特定する。優先設定は、管理者により生成される設定であり、優先提案対象のライブ配信をどの程度優先して提案するかを示す。本実施の形態では、優先設定は優先範囲の指定を含む。図７の例では、優先設定が優先範囲「１～６」である場合、被提案ユーザ数算出部３３２は平均クリック率「１０％」を取得する。優先設定はアクティブユーザの人数、時期、イベントの数等のライブ配信プラットフォームの状況に基づき管理者により定められてもよい。

被提案ユーザ数算出部３３２は、以下の式により被提案ユーザ数を算出する。
被提案ユーザ数 ＝（必要定着視聴者数）×（必要クリック数）／（平均クリック率）
図５、図７、図８の例では、配信者「ＬＲ２」のライブ配信が優先提案対象のライブ配信として特定された場合、配信者「ＬＲ２」のレベル「７」に対して必要定着視聴者数「５」、必要クリック数「３」が特定される。優先設定に従い平均クリック率「１０％」が特定される。被提案ユーザ数は、５×３／０．１＝１５０人と算出される。

ユーザプール生成部３３４は、被提案ユーザ数算出部３３２によって取得された被提案ユーザ数に対応する数のアクティブユーザを選択することでユーザプールを生成する。ユーザプール生成部３３４は、優先提案対象のライブ配信に対応付けられたユーザプールテーブル３２６を生成する。この段階ではユーザプールテーブル３２６は何もデータを含んでいない。優先提案対象のライブ配信とユーザプールテーブルとは１対１で対応する。ユーザプール生成部３３４は、優先提案対象のライブ配信の属性を取得する。より具体的には、ユーザプール生成部３３４は、ストリームＤＢ３１４を参照し、優先提案対象のライブ配信の配信者ＩＤと、内容タグと、を特定する。ユーザプール生成部３３４は、ユーザＤＢ３１８を参照し、特定された配信者ＩＤに対応するユーザ（配信者）の属性と、レベルと、を取得する。優先提案対象のライブ配信の属性は、当該ライブ配信の配信者の属性およびレベルと、内容タグと、を含む。ユーザプール生成部３３４は、ユーザＤＢ３１８を参照し、ステータスがアクティブとなっているユーザ（すなわちアクティブユーザ）およびその属性を特定する。ユーザプール生成部３３４は、優先提案対象のライブ配信の属性と、特定されたアクティブユーザの属性および視聴履歴と、から両者の類似スコアを算出する。視聴履歴は不図示の視聴履歴ＤＢから取得される。このようなライブ配信とユーザとの類似スコアの算出は、例えば特許文献１に記載されるような公知の機械学習技術を用いて実現されてもよい。あるいはまた、ライブ配信とユーザとの類似スコアの算出は、例えば特開２０１９－１６４６１７号公報に記載されるような公知のマッチング技術を用いて実現されてもよい。ユーザプール生成部３３４は、ユーザＤＢ３１８に登録されている全てのアクティブユーザについて、優先提案対象のライブ配信との類似スコアを算出する。ユーザプール生成部３３４は、算出された類似スコアの高い方から順に被提案ユーザ数と同数のアクティブユーザを特定し、特定されたアクティブユーザのユーザＩＤおよびその類似スコアを、最初に生成しておいたユーザプールテーブル３２６に登録する。

おすすめリスト設定部３３６は、ユーザプール生成部３３４によって生成されたユーザプールテーブル３２６に登録されているアクティブユーザのユーザ端末において、当該テーブル３２６に対応する優先提案対象のライブ配信が他のライブ配信よりも優先して提案されるように、当該アクティブユーザに提案するライブ配信のリストすなわちおすすめライブ配信リストを設定する。おすすめリスト設定部３３６は、ユーザプール生成部３３４におけるライブ配信とユーザとのマッチング処理と同様のマッチング処理を行うことにより、ユーザプールテーブル３２６に登録される各アクティブユーザに対応するおすすめライブ配信リストを生成する。おすすめリスト設定部３３６は、このおすすめライブ配信リストを生成する際、優先提案対象のライブ配信を優先範囲内にリストする。

図１２（Ａ）、図１２（Ｂ）、図１２（Ｃ）は、おすすめライブ配信リスト３５０の生成の過程を示す図である。図１２（Ｃ）に示されるおすすめライブ配信リスト３５０は、図９のユーザプールテーブル３２６に登録されているアクティブユーザ「ＵＳ１」に対して提案されるライブ配信のリストの一例である。おすすめリスト設定部３３６はまず、アクティブユーザ「ＵＳ１」との類似スコアの高い方から順に所定個数、例えば１００個、のライブ配信のストリームＩＤ、サムネイルデータ、類似スコアを、おすすめライブ配信リスト３５０に登録する。この際、おすすめリスト設定部３３６は、類似スコアの高い方から順により目立つ表示位置を割り当てていく。図１２（Ａ）の例では、最も類似スコアの高いライブ配信「ＳＴ３３」に、最も目立つ表示位置「１」を割り当てている。

おすすめリスト設定部３３６は、優先提案対象のライブ配信を挿入または移動する先の表示位置を決定する。おすすめリスト設定部３３６は、優先範囲のなかからランダムにひとつの表示位置を選択してもよいし、ユーザプールテーブル３２６に登録されているアクティブユーザに亘るラウンドロビン方式により優先範囲のなかからひとつの表示位置を選択してもよい。

おすすめリスト設定部３３６は、決定された表示位置を空けるようにおすすめライブ配信リスト３５０を更新する。図１２（Ｂ）の例では、挿入先として表示位置「１」が決定されたので、おすすめリスト設定部３３６は、既に登録されている全てのライブ配信のデータについて、表示位置が＋１となるよう更新する。他の例では、表示位置「２」が決定された場合、おすすめリスト設定部３３６は、既に登録されている表示位置「１」のライブ配信はそのままとし、既に登録されている表示位置「２」以降の全てのライブ配信のデータについて、表示位置が＋１となるよう更新する。

おすすめリスト設定部３３６は、アクティブユーザ「ＵＳ１」が登録されているユーザプールテーブル３２６に対応付けられた優先提案対象のライブ配信のストリームＩＤ「ＳＴ２」と、そのサムネイルデータと、その類似スコアとを、決定された表示位置に移動または挿入する。ライブ配信「ＳＴ２」が既におすすめライブ配信リスト３５０に登録されている場合は移動となり、登録されていなければ新規のデータの挿入となる。図１２（Ｂ）の例では、表示位置「１」が空いた後、そこに優先提案対象のライブ配信「ＳＴ２」のデータが挿入される。その結果、図１２（Ｃ）に示されるおすすめライブ配信リスト３５０が生成される。図１２（Ｃ）は、優先提案対象のライブ配信「ＳＴ２」のユーザプールテーブル３２６に登録されているアクティブユーザ「ＵＳ１」に対するおすすめライブ配信リスト３５０を示す。このリスト３５０では、優先提案対象のライブ配信「ＳＴ２」は、アクティブユーザ「ＵＳ１」との類似スコアは比較的低いものの、最も優先して提案される表示位置「１」にリストされている。

図３に戻り、おすすめリスト送信部３３８は、おすすめリスト設定部３３６によって生成されたおすすめライブ配信リスト３５０を、それに対応するアクティブユーザのユーザ端末にネットワークＮＷを介して送信する。アクティブユーザのユーザ端末は、受信したおすすめライブ配信リスト３５０に基づき、図１０に示されるようなおすすめライブ配信画面６００をディスプレイに表示させる。アクティブユーザがそのおすすめライブ配信画面６００を開くとまずは表示位置１～６のサムネイルが表示されるので、それらの表示位置に対応するライブ配信は優先して提案されると言える。

ユーザ端末の視聴側通信部２０４は、おすすめライブ配信画面６００におけるアクティブユーザによるライブ配信の選択を受け付けると、選択されたライブ配信のストリームＩＤを含む配信要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。配信情報提供部３０２は、受信した配信要求に含まれるストリームＩＤにより特定されるライブ配信の、要求元のユーザ端末への提供を開始する。配信情報提供部３０２は、当該ストリームＩＤの視聴者ＩＤに要求元のユーザ端末のアクティブユーザのユーザＩＤが含まれるようにストリームＤＢ３１４を更新する。

中継部３０４は、配信情報提供部３０２によって開始されたライブ配信において、配信者のユーザ端末２０から視聴者のユーザ端末３０への動画データの伝送を中継する。中継部３０４は、ライブ配信中すなわち動画データの再生中における視聴者によるユーザ入力を示す信号を視聴側通信部２０４から受信する。ユーザ入力を示す信号は、ユーザ端末３０のディスプレイに表示されたオブジェクトの指定を示すオブジェクト指定信号であってもよく、当該オブジェクト指定信号は、視聴者の視聴者ＩＤと、視聴者が視聴しているライブ配信を行っている配信者の配信者ＩＤと、オブジェクトを特定するオブジェクトＩＤと、を含む。オブジェクトがギフトアイコンである場合、オブジェクトＩＤはギフトＩＤとなる。その場合のオブジェクト指定信号は、視聴者による配信者に対するギフトの使用を示すギフト使用信号となる。同様に、中継部３０４は、動画データの再生中における配信者によるユーザ入力を示す信号、例えばオブジェクト指定信号をユーザ端末２０の配信部１００の配信側通信部１１０から受信する。

ギフト処理部３０８は、ギフト使用信号に含まれるギフトＩＤで特定されるギフトの付与報酬に応じて配信者の報酬を増加させるようにユーザＤＢ３１８を更新する。ギフト処理部３０８は、ギフトＤＢ３２０を参照し、受信したギフト使用信号に含まれるギフトＩＤに対応する付与報酬を特定する。ギフト処理部３０８は、ギフト使用信号に含まれる配信者ＩＤに対応する報酬に、特定された付与報酬を加えるようユーザＤＢ３１８を更新する。

支払い処理部３１０は、ギフト使用信号の受信に応じて、視聴者によるギフトの対価の支払いを処理する。支払い処理部３１０は、ギフトＤＢ３２０を参照し、ギフト使用信号に含まれるギフトＩＤで特定されるギフトの対価ポイントを特定する。支払い処理部３１０は、ギフト使用信号に含まれる視聴者ＩＤで特定される視聴者のポイントから特定された対価ポイントを差し引くようユーザＤＢ３１８を更新する。

配信評価部３１２は、優先提案対象のライブ配信が必要定着視聴者数に関する評価基準を充たすと当該ライブ配信に肯定的な評価を付与し、肯定的な評価が付与されない場合は否定的な評価を付与する。評価基準は、ライブ配信が、優先提案対象として特定されてから優先期間（例えば、１５分間）が満了するまでの間に、必要定着視聴者数以上の定着視聴者を獲得したか否かという基準を含む。必要定着視聴者数以上の定着視聴者を獲得した場合に評価基準は充たされる。

配信評価部３１２は、優先提案対象のライブ配信を監視し、当該ライブ配信の定着視聴者の数をカウントする。例えば、配信評価部３１２は優先提案対象のライブ配信の視聴者の連続視聴時間が５分を上回ると、その視聴者を当該ライブ配信の定着視聴者としてカウントする。配信評価部３１２は、得られた定着視聴者の数でストリームＤＢ３１４を更新する。配信評価部３１２は、監視しているライブ配信について、リフレッシュ期間（例えば、３分間）が経過するごとに当該ライブ配信の定着視聴者数と必要定着視聴者数とを比較する。配信評価部３１２は、比較の結果、前者が後者以上である場合、当該ライブ配信の評価が「良い」となるようストリームＤＢ３１４を更新する。優先期間とリフレッシュ期間との関係について、優先期間はリフレッシュ期間を含むがそれよりも長く設定される。配信評価部３１２の処理のさらなる詳細は後述する。

以上の構成によるライブ配信システム１の動作を説明する。
図１３は、優先提案対象のライブ配信を評価する際のサーバ１０における一連の処理の流れを示すフローチャートである。優先提案対象特定部３３０は、優先提案対象のライブ配信を特定する（Ｓ２０２）。被提案ユーザ数算出部３３２は、特定されたライブ配信に対応する被提案ユーザ数を算出する（Ｓ２０４）。ユーザプール生成部３３４は、特定されたライブ配信と各アクティブユーザとの類似スコアを算出する（Ｓ２０６）。ユーザプール生成部３３４は、算出された類似スコアの高い方から順に被提案ユーザ数と同じ数のアクティブユーザを選択することでユーザプールを生成する（Ｓ２０８）。おすすめリスト設定部３３６は、特定されたライブ配信を、ステップＳ２０８で生成されたユーザプールに含まれるアクティブユーザのそれぞれに送信するおすすめライブ配信リストの優先範囲内に設定する（Ｓ２１０）。おすすめリスト送信部３３８は、ステップＳ２１０の設定がなされたおすすめライブ配信リストを、対応するアクティブユーザのユーザ端末に送信する（Ｓ２１２）。

配信評価部３１２は、ステップＳ２１２でユーザプールに含まれる各アクティブユーザのユーザ端末におすすめライブ配信リストが送信された後、リフレッシュ期間が経過するまで待機する（Ｓ２１４）。併せて配信評価部３１２はステップＳ２０２で特定されたライブ配信を監視し、その定着視聴者数をカウントする。配信評価部３１２は、リフレッシュ期間が経過すると、その時点での定着視聴者数が必要定着視聴者数以上となったか否かを判定する（Ｓ２１６）。例えば配信評価部３１２は、ストリームＤＢ３１４を参照し、ステップＳ２０２で特定されたライブ配信のその時点での定着視聴者数を取得する。配信評価部３１２は、設定ＤＢ３２４を参照し、特定されたライブ配信の配信者のレベルに対応する必要定着視聴者数を取得する。配信評価部３１２は、取得された定着視聴者数と、取得された必要定着視聴者数と、を比較することで判定を行う。

ステップＳ２１６で定着視聴者数が必要定着視聴者数以上となったと判定された場合（Ｓ２１６のＹＥＳ）、配信評価部３１２は特定されたライブ配信に良い評価を付与する（Ｓ２２０）。配信評価部３１２は、特定されたライブ配信の評価に「良い」が登録されるようにストリームＤＢ３１４を更新する。ステップＳ２１６で定着視聴者数が必要定着視聴者数以上となっていない判定された場合（Ｓ２１６のＮＯ）、配信評価部３１２はステップＳ２０２で特定されたライブ配信の優先期間が満了したか否かを判定する（Ｓ２１８）。満了していない場合（Ｓ２１８のＮＯ）、処理はステップＳ２０６に戻り、新たなユーザプールが生成される。満了した場合（Ｓ２１８のＹＥＳ）、配信評価部３１２は特定されたライブ配信に悪い評価を付与する（Ｓ２２２）。配信評価部３１２は、特定されたライブ配信の評価に「悪い」が登録されるようにストリームＤＢ３１４を更新する。

以上の処理の結果、リフレッシュ期間内に優先提案対象のライブ配信が評価基準を充たさなかった場合（Ｓ２１６のＮＯ）、かつ、配信評価部３１２により否定的な評価が付与されない場合（Ｓ２１８のＮＯ）、ユーザプール生成部３３４は新たなユーザプールを生成することとなる。また、配信評価部３１２は、優先期間内に優先提案対象のライブ配信が評価基準を充たさなかった場合、当該ライブ配信に悪い評価を付与する。

おすすめリスト設定部３３６は、上記のステップＳ２２０、Ｓ２２２でライブ配信に付与された評価に基づいて、ユーザプールテーブル３２６に登録されている各アクティブユーザ向けのおすすめライブ配信リストを生成してもよい。例えば、「良い」評価が付与されているライブ配信は、「悪い」評価が付与されているライブ配信よりも、他の条件が同じであれば類似スコアが高くなるように類似スコアの計算式を設定してもよい。あるいはまた、おすすめリスト設定部３３６は、「悪い」評価が付与されたライブ配信をおすすめライブ配信リストに含めなくてもよい。

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

本実施の形態に係るライブ配信システム１によると、開始されてから間もない、もしくは開始された直後のライブ配信が優先提案対象のライブ配信として特定され、そのライブ配信との類似スコアの高いアクティブユーザに優先して提案される。したがって、優先提案対象のライブ配信に視聴者が集まりやすくなり、配信者は配信を続けるモチベーションを得ることができる。併せて、優先提案対象のライブ配信を優先して提案する対象のアクティブユーザの数を被提案ユーザ数で制限することにより、同時期に多くのライブ配信が開始された場合でも各ライブ配信が上位に表示される期間を十分にとることができる。

また、本実施の形態に係るライブ配信システム１では、被提案ユーザ数は配信者のレベルに応じて決定される。このように被提案ユーザ数をレベルの変数とすることにより、レベルの違いによる配信者の傾向の違いを吸収することができる。

また、本実施の形態に係るライブ配信システム１では、過去のライブ配信の視聴データを解析することで得られた必要定着視聴者数を確保できるように、優先提案対象のライブ配信の被提案ユーザ数が算出される。配信開始から優先期間内は、この必要定着視聴者数が達成されるまで、ユーザプールの生成とおすすめライブ配信リストの送信が繰り返される。したがって、優先提案対象のライブ配信を全てのアクティブユーザに優先して提案する場合と比較して、アクティブユーザの数を被提案ユーザ数で制限する分優先期間を長くすることができるか、もしくは優先提案対象として特定できるライブ配信の数を増やすことができる。これにより、視聴者が集まらないことでライブ配信を止めてしまう配信者の数を低減し、配信者の満足度を向上することができる。

優先提案対象のライブ配信を、特に制限を設けず全てのアクティブユーザに優先して提案する場合、優先提案対象のライブ配信の数が増えると各ライブ配信を優先して提案できる期間が短くなるか、または優先提案対象として選択できるライブ配信の数が少なくなる。また、本発明者の独自の検討によると、優先して提案する先のアクティブユーザの数を増やせば増やすほど比例的に定着視聴者数が伸びるという訳ではない。したがって、優先提案対象のライブ配信を全てのアクティブユーザに優先して提案するという戦略は最適ではない。本実施の形態では、被提案ユーザ数を導入し、優先して提案する先のアクティブユーザの数をこの被提案ユーザ数で制限する。これにより優先提案の最適化が可能となる。

従来のライブ配信プラットフォームでは、ライブ配信に一旦人気が出ると視聴者が一気に増え、それによりそのライブ配信のスコアが上昇し、それにより検索やおすすめの上位に表示され、さらに視聴者が増える、という正のフィードバックが存在する。これは認知度を一気に高めて人気者になりたい配信者には適したシステムである。しかしながら、この従来のシステムは、ライブ配信を始めたばかりの配信者や、こつこつとライブ配信を続けていくことでライブ配信の品質を高めていく後伸び型の配信者には不利である。この従来のシステムだと、新規配信者や後伸び型の配信者が検索上位やおすすめ上位に表示される蓋然性は低く、したがってライブ配信に視聴者が集まりにくく、ライブ配信の品質の高さを実感してもらえるチャンスが少ないからである。

また、従来のシステムでは、スコアが高い人気のあるライブ配信が品質の高いライブ配信であるとは限らない。品質が悪くてもバズれば一気に人気のライブ配信になってしまうからである。このような事態は、品質の高いライブ配信を提供する必要があるライブ配信プラットフォームとしては好ましくない。

そこで、本実施の形態に係るライブ配信システム１はライブ配信をなるべく平等に評価する仕組みを提供する。優先提案対象として特定されたライブ配信は、同時に評価対象のライブ配信でもある。評価の基準は、ライブ配信が配信開始から優先期間内に必要定着視聴者数以上の定着視聴者数を得ることができるか否かである。この際、ライブ配信のユーザプールに登録されるアクティブユーザの数である被提案ユーザ数は配信者のレベルに応じて決定され、かつ、必要定着視聴者数も配信者のレベルに応じて決定される。すなわち、本実施の形態では、高いレベルの配信者にはより多くの被提案ユーザ数が割り当てられるが、同時にクリアしなければならない必要定着視聴者数も多くなる。これにより、高いレベルの配信者のライブ配信と低いレベルの配信者のライブ配信とをより平等に比較、評価することができる。また、定着視聴者数を評価に用いることでライブ配信の品質を視聴者目線でより正確に評価することができる。

また、本実施の形態に係るライブ配信システム１ではライブ配信に付与された評価に基づいておすすめライブ配信リストが生成または更新される。したがって、より品質の高いライブ配信をユーザに推薦することができる。

また、本実施の形態に係るライブ配信システム１では、管理者がデータの解析結果に応じて適宜クリック率ＤＢ３２２や設定ＤＢ３２４に保持されるパラメータの値を変更することができる。したがって、ライブ配信プラットフォームの実態に基づく効果的な運用が可能となる。

図１４を参照して、本実施の形態に係る情報処理装置のハードウェア構成について説明する。図１４は、本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。図示された情報処理装置９００は、例えば、本実施の形態におけるサーバ１０およびユーザ端末２０、３０のそれぞれを実現しうる。

情報処理装置９００は、ＣＰＵ９０１、ＲＯＭ（Read Only Memory）９０２、およびＲＡＭ（Random Access Memory）９０３を含む。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インタフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、ドライブ９２１、接続ポート９２５、通信装置９２９を含んでもよい。さらに、情報処理装置９００は、カメラなどの撮像装置（不図示）を含む。また、情報処理装置９００は、ＣＰＵ９０１に代えて、またはこれとともに、ＤＳＰ（Digital Signal Processor）またはＡＳＩＣ（Application Specific Integrated Circuit）と呼ばれるような処理回路を有してもよい。

ＣＰＵ９０１は、演算処理装置および制御装置として機能し、ＲＯＭ９０２、ＲＡＭ９０３、ストレージ装置９１９、またはリムーバブル記録媒体９２３に記録された各種プログラムに従って、情報処理装置９００内の動作全般またはその一部を制御する。例えば、ＣＰＵ９０１は、本実施の形態におけるサーバ１０およびユーザ端末２０、３０のそれぞれに含まれる各機能部の動作全般を制御する。ＲＯＭ９０２は、ＣＰＵ９０１が使用するプログラムや演算パラメータなどを記憶する。ＲＡＭ９０３は、ＣＰＵ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。ＣＰＵ９０１、ＲＯＭ９０２、およびＲＡＭ９０３は、ＣＰＵバスなどの内部バスにより構成されるホストバス９０７により相互に接続されている。さらに、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Peripheral Component Interconnect/Interface）バスなどの外部バス９１１に接続されている。

入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置であってもよいし、マイクロフォンなどの音センサ、加速度センサ、傾きセンサ、赤外線センサ、深度センサ、温度センサ、湿度センサなど物理量を電気信号に変換する装置であってもよい。入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置９００の操作に対応した携帯電話などの外部接続機器９２７であってもよい。入力装置９１５は、ユーザが入力した情報または感知した物理量に基づいて入力信号を生成してＣＰＵ９０１に出力する入力制御回路を含む。ユーザは、この入力装置９１５を操作することによって、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりする。

出力装置９１７は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置９１７は、例えば、ＬＣＤ、ＰＤＰ、ＯＥＬＤなどのディスプレイ、スピーカおよびヘッドホンなどの音響出力装置、ならびにプリンタ装置などでありうる。出力装置９１７は、情報処理装置９００の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音響などの音として出力したりする。

ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ（Hard Disk Drive）などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。

ドライブ９２１は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体９２３のためのリーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２１は、装着されているリムーバブル記録媒体９２３に記録されている情報を読み出して、ＲＡＭ９０３に出力する。また、ドライブ９２１は、装着されているリムーバブル記録媒体９２３に記録を書き込む。

接続ポート９２５は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２５は、例えば、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Small Computer System Interface）ポートなどでありうる。また、接続ポート９２５は、ＲＳ－２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（登録商標）（High-Definition Multimedia Interface）ポートなどであってもよい。接続ポート９２５に外部接続機器９２７を接続することで、情報処理装置９００と外部接続機器９２７との間で各種のデータが交換されうる。

通信装置９２９は、例えば、ネットワークＮＷに接続するための通信デバイスなどで構成された通信インタフェースである。通信装置９２９は、例えば、有線または無線ＬＡＮ（Local Area Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Wireless USB）用の通信カードなどでありうる。また、通信装置９２９は、光通信用のルータ、ＡＤＳＬ（Asymmetric Digital Subscriber Line）用のルータ、または、各種通信用のモデムなどであってもよい。通信装置９２９は、例えば、インターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置９２９に接続される通信ネットワークＮＷは、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などである。なお、通信装置９２９は、通信部としての機能を実現する。

カメラなどの撮像装置（不図示）は、例えばＣＣＤ（Charge Coupled Device）またはＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子、および撮像素子への被写体像の結像を制御するためのレンズなどの各種の部材を用いて実空間を撮像し、撮像画像を生成する装置である。当該撮像装置は、静止画を撮像するものであってもよいし、または動画を撮像するものであってもよい。

以上、実施の形態に係るライブ配信システム１の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解される。

実施の形態では、おすすめライブ配信画面のより目立つ位置にサムネイルを配置することで優先提案対象のライブ配信をアクティブユーザに優先して提案する場合を説明したが、これに限られない。例えば優先提案対象のライブ配信をプッシュ通知やバナー広告等によりアクティブユーザに優先して提案してもよい。この場合、優先提案対象のライブ配信に対応するユーザプールに登録されているアクティブユーザにプッシュ通知を送るかバナー広告を表示する。

実施の形態では、おすすめリスト設定部３３６がユーザプールに含まれる各アクティブユーザに対するおすすめライブ配信リストを生成する場合を説明したが、これに限られない。例えば、おすすめリスト設定部３３６は既に他で生成されたアクティブユーザに対するおすすめライブ配信リストを、優先提案対象のライブ配信が優先範囲内の表示位置に含まれるように更新してもよい。この場合、配信情報提供部３０２は、ネットワークＮＷを介して、優先提案対象のライブ配信のユーザプールに登録されているアクティブユーザのユーザ端末３０からライブ配信に関する情報の提供要求を受けると、ストリームＤＢ３１４を参照しておすすめライブ配信リストを生成する。おすすめリスト設定部３３６は、優先提案対象のライブ配信が優先して提案されるように、配信情報提供部３０２によって生成されたおすすめライブ配信リストを更新する。配信情報提供部３０２は、ネットワークＮＷを介して、おすすめライブ配信リストを要求元のユーザ端末３０に送信する。

あるいはまた、おすすめリスト設定部３３６は、おすすめライブ配信リスト自体を変更する代わりに、当該リストに付随する情報に、優先提案対象のライブ配信を優先範囲内の表示位置に表示させるためのコマンドを加えてもよい。

実施の形態では、配信評価部３１２を設けて優先提案対象のライブ配信を評価する場合を説明したが、これに限られず、ライブ配信の評価を行わないのであれば配信評価部３１２を設けなくてもよい。

実施の形態におけるギフトの対価ポイントから付与報酬への換算率は一例であって、これらは例えばライブ配信システムの管理者により適宜設定されてもよい。

実施の形態に係る技術的思想を、配信者の画像の代わりに配信者の動きと同期した動きをするアバターを用いるバーチャルライブ配信や、ライブコマースに適用してもよい。

本明細書において説明された処理手順、特にフロー図、フローチャートを用いて説明された処理手順においては、その処理手順を構成する工程（ステップ）の一部を省略すること、その処理手順を構成する工程として明示されていない工程を追加すること、及び／又は当該工程の順序を入れ替えることが可能であり、このような省略、追加、順序の変更がなされた処理手順も本開示の趣旨を逸脱しない限り本開示の範囲に含まれる。

サーバ１０により実現される機能の少なくとも一部は、サーバ１０以外の装置、例えばユーザ端末２０、３０により実現されてもよい。ユーザ端末２０、３０により実現される機能の少なくとも一部は、ユーザ端末２０、３０以外の装置、例えば、サーバ１０により実現されてもよい。例えば、視聴者のユーザ端末で行われる動画データの画像への所定のフレーム画像の重畳は、サーバ１０で行われてもよいし、配信者のユーザ端末で行われてもよい。

Claims (7)

1. 優先提案対象のライブ配信を特定する手段と、
   特定された優先提案対象のライブ配信に対応する被提案ユーザ数を取得する手段と、
   取得された被提案ユーザ数に対応する数のユーザを選択することでユーザ群を生成する手段と、
   生成されたユーザ群に含まれるユーザの端末において優先提案対象のライブ配信が他のライブ配信よりも優先して提案されるように、当該ユーザに提案するライブ配信のリストを設定する手段と、を備え、
   前記取得する手段は、特定されたライブ配信の配信者の、ライブ配信プラットフォームにおける実績を示す指標に応じて決定された被提案ユーザ数を取得し、
   被提案ユーザ数は、配信者の配信継続率により設定された第１パラメータと、視聴者の視聴継続率により設定された第２パラメータと、に基づいて決定されるサーバ。
2. 第１パラメータは、配信者の実績が多いほど被提案ユーザ数が多くなるよう設定され、
   第２パラメータは、配信者の実績が多いほど被提案ユーザ数が少なくなるよう設定される請求項１に記載のサーバ。
3. 被提案ユーザ数はさらに、ライブ配信が優先して提案された場合に当該ライブ配信がユーザに選択される確率に基づいて決定される請求項１に記載のサーバ。
4. 前記特定する手段は、ライブ配信の開始を示す信号の受信に応じて当該ライブ配信を優先提案対象のライブ配信として特定し、
   前記サーバはさらに、
   優先提案対象のライブ配信が第１パラメータに関する評価基準を充たすと当該ライブ配信に肯定的な評価を付与し、肯定的な評価が付与されない場合は否定的な評価を付与する手段を備える請求項１に記載のサーバ。
5. 前記生成する手段は、第１期間内に優先提案対象のライブ配信が前記評価基準を充たさなかった場合、かつ、前記付与する手段により否定的な評価が付与されない場合、新たなユーザ群を生成し、
   前記付与する手段は、第１期間を含むがそれよりも長い第２期間内に優先提案対象のライブ配信が前記評価基準を充たさなかった場合、当該ライブ配信に否定的な評価を付与する請求項４に記載のサーバ。
6. 前記設定する手段は、ライブ配信に付与された評価に基づいて、ユーザに提案するライブ配信のリストを設定する請求項５に記載のサーバ。
7. 情報処理装置が、優先提案対象のライブ配信を特定することと、
   前記情報処理装置が、特定された優先提案対象のライブ配信に対応する被提案ユーザ数を取得することと、
   前記情報処理装置が、取得された被提案ユーザ数に対応する数のユーザを選択することでユーザ群を生成することと、
   前記情報処理装置が、生成されたユーザ群に含まれるユーザの端末において優先提案対象のライブ配信が他のライブ配信よりも優先して提案されるように、当該ユーザに提案するライブ配信のリストを設定することと、を含み、
   前記取得することは、特定されたライブ配信の配信者の、ライブ配信プラットフォームにおける実績を示す指標に応じて決定された被提案ユーザ数を取得することを含み、
   被提案ユーザ数は、配信者の配信継続率により設定された第１パラメータと、視聴者の視聴継続率により設定された第２パラメータと、に基づいて決定される方法。

Images