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

Description

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

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

ライブ配信において、配信者が用意した２択の選択肢に対して視聴者が任意で投票することができる投票機能が知られている（例えば、非特許文献１参照）。

「配信画面の見方（ライバ－）」、１７ＬＩＶＥ株式会社、URL:https://17live-jp.zendesk.com/hc/ja/articles/4402915219087-%E9%85%8D%E4%BF%A1%E7%94%BB%E9%9D%A2%E3%81%AE%E8%A6%8B%E6%96%B9-%E3%83%A9%E3%82%A4%E3%83%90%E3%83%BC-

ライブ配信の視聴者が配信者にやってほしいことがある場合、現在のライブ配信の仕組みにおいては、視聴者はやってほしいことをコメントに投稿することができる。しかしながら、常時多くの視聴者からコメントが投稿されるので、やってほしいことのコメントは短時間で配信者の視界から消えるものである。また、コメントは基本的に自由に入力されるので、配信者にとって、やってほしいことを統計的または体系的に把握することは困難である。

本開示はこうした課題に鑑みてなされたものであり、その目的は、ライブ配信において配信者にやってほしいことを視聴者からシステマチックに拾い上げることができる技術の提供にある。

本発明のある態様は、サーバに関する。このサーバは、ユーザによる端末への入力内容であってライブ配信の配信者に関連付けられた入力内容を、当該配信者にやってほしいこととして、当該端末からネットワークを介して受け付ける第１受付手段と、受け付けられた配信者にやってほしいことを、配信者に関連付けられたウィッシュリストに登録する登録手段と、ウィッシュリストを配信者に通知する通知手段と、を備える。

本発明の別の態様は、サーバである。このサーバは、ユーザの端末のディスプレイに表示される所定のオブジェクトであって、ライブ配信の配信者に関連付けられた所定のオブジェクトが指定された場合、当該指定を、当該配信者に対するライブ配信の実施の求めとして受け付ける受付手段と、配信者に対するライブ配信の実施の求めを受け付けた場合、配信者に、ライブ配信の実施の求めがあることを通知する通知手段と、を備える。

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

第１の実施の形態に係るライブ配信システムの構成を示す模式図である。 図１のユーザ端末の機能および構成を示すブロック図である。 図１のサーバの機能および構成を示すブロック図である。 図３のストリームＤＢの一例を示すデータ構造図である。 図３のユーザＤＢの一例を示すデータ構造図である。 図３のギフトＤＢの一例を示すデータ構造図である。 図３のウィッシュリストＤＢの一例を示すデータ構造図である。 図３の実現リストＤＢの一例を示すデータ構造図である。 図１のライブ配信システムにおける一連の処理の流れを示すフローチャートである。 図３の賛同設定ＤＢの一例を示すデータ構造図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される希望入力画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるウィッシュリスト概要画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される希望詳細画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示される実現リスト表示画面の代表画面図である。 アクティブユーザのユーザ端末のディスプレイに表示される実現リスト表示画面の代表画面図である。 第２の実施の形態に係るサーバの機能および構成を示すブロック図である。 図１８の配信希望ＤＢの一例を示すデータ構造図である。 第２の実施の形態に係るライブ配信システムにおける配信実施希望に係る処理の流れを示すフローチャートである。 アクティブユーザのユーザ端末のディスプレイに表示されるプロフィール画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示される通知画面の代表画面図である。 配信者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 第１の実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。

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

（第１の実施の形態）
第１の実施の形態に係るライブ配信システムでは、ライブ配信の視聴者が対価を支払うことで配信者にやってほしいこと（以下、希望と称す）を提出し、提出された希望が当該配信者に対するウィッシュリストに登録される。ライブ配信システムは、ライブ配信の配信者に対するウィッシュリストを当該ライブ配信の視聴者に提示する。視聴者は、ウィッシュリストに登録されている希望のなかに、自分も配信者にやってほしいと思うものがあれば、対価を支払い賛同の意を示す。ライブ配信システムはウィッシュリストを賛同の数と共に配信者に通知し、配信者に希望を実現するよう促す。これにより、配信者は自分の視聴者が何を望んでいるのかをよく知ることができ、視聴者により楽しんでもらえるライブコンテンツを作成することができる。視聴者は自分の希望をライブ配信に反映させるための手段を得ることができる。これらの結果、配信者と視聴者との相互作用（interaction）をより活発にし、配信者と視聴者とのつながりをより豊かにすることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

配信外処理部４００は、配信外ＵＩ制御部４０２と、配信外通信部４０４と、を含む。配信外ＵＩ制御部４０２は、アクティブユーザ向けのＵＩを制御する。例えば、配信外ＵＩ制御部４０２は、現在参加可能なライブ配信のリストを表示してアクティブユーザによるライブ配信の選択を受け付けるためのライブ配信選択画面を生成し、ディスプレイに表示させる。配信外ＵＩ制御部４０２は、任意のユーザのプロフィール画面を生成し、ディスプレイに表示させる。配信外ＵＩ制御部４０２は、過去のライブ配信を録音・録画することにより生成されたアーカイブを再生する。

配信外通信部４０４は、ライブ配信外のサーバ１０との間の通信を制御する。配信外通信部４０４は、ネットワークＮＷを介してサーバ１０から、ライブ配信選択画面を生成するための情報や、プロフィール画面を生成するための情報や、アーカイブの情報を受信する。配信外通信部４０４は、アクティブユーザによる入力の内容を、ネットワークＮＷを介してサーバ１０に送信する。

図３は、図１のサーバ１０の機能および構成を示すブロック図である。サーバ１０は、配信情報提供部３０２と、中継部３０４と、ギフト処理部３０８と、支払い処理部３１０と、希望受付部３２２と、希望登録部３２４と、賛同受付部３２６と、賛同登録部３２８と、シェア部３３０と、実現促進部３３２と、実現確認部３３４と、ストリームＤＢ３１４と、ユーザＤＢ３１８と、ギフトＤＢ３２０と、ウィッシュリストＤＢ３３６と、実現リストＤＢ３３８と、賛同設定ＤＢ３３９と、を備える。

図４は、図３のストリームＤＢ３１４の一例を示すデータ構造図である。ストリームＤＢ３１４は現在行われているライブ配信の情報を保持する。ストリームＤＢ３１４は、ライブ配信システム１が提供するライブ配信プラットフォームにおいてライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者を特定するユーザＩＤである配信者ＩＤと、当該ライブ配信の視聴者を特定するユーザＩＤである視聴者ＩＤと、を対応付けて保持する。

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

図５は、図３のユーザＤＢ３１８の一例を示すデータ構造図である。ユーザＤＢ３１８は、ユーザに関する情報を保持する。ユーザＤＢ３１８は、ユーザを特定するユーザＩＤと、当該ユーザが有しているポイントと、当該ユーザに付与された報酬と、当該ユーザが行った前回のライブ配信の配信日時と、を対応付けて保持する。前回配信日時は前回の配信が行われた時を示す代表的な時刻であり、前回のライブ配信の開始時刻であってもよいし、終了時刻であってもよい。

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

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

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

図７は、図３のウィッシュリストＤＢ３３６の一例を示すデータ構造図である。ウィッシュリストＤＢ３３６は、配信者ごとに当該配信者に対するウィッシュリストの情報を保持する。ウィッシュリストは、対応する配信者に対する希望のリストである。ウィッシュリストＤＢ３３６は、希望の対象となっている配信者のユーザＩＤである対象配信者ＩＤと、希望を提出した視聴者のユーザＩＤである要求者ＩＤと、希望の内容と、希望への賛同の数（以下、賛同数という）と、「Super vote」で賛同の意を示したユーザのユーザＩＤと、「I like it vote」で賛同の意を示したユーザのユーザＩＤと、「Nice vote」で賛同の意を示したユーザのユーザＩＤと、を対応付けて保持する。図７の例の１行目のエントリは、配信者「ABC」に対して視聴者「USR1」が「A funny dance, ...」という内容の希望を提出したこと、当該希望への賛同数が２０であること、当該希望に対して「Super vote」を行ったユーザは「USR2」、「USR3」の２名、当該希望に対して「I like it vote」を行ったユーザは「USR5」、「USR6」の２名、当該希望に対して「Nice vote」を行ったユーザは「USR4」、「USR7」、「USR8」、「USR9」の４名であることを示す。

図８は、図３の実現リストＤＢ３３８の一例を示すデータ構造図である。実現リストＤＢ３３８は、配信者ごとに、所定の達成促進条件を充たした希望のリストである実現リスト（Dream come true list）を保持する。実現リストＤＢ３３８は、所定の達成促進条件を充たした希望の対象配信者ＩＤと、当該希望の要求者ＩＤと、当該希望の内容と、当該希望への賛同数と、当該希望に賛同の意を示した視聴者の視聴者ＩＤである賛同者ＩＤと、当該希望が実現されたか否かを示す実現済みフラグと、を対応付けて保持する。

図１０は、図３の賛同設定ＤＢ３３９の一例を示すデータ構造図である。賛同設定ＤＢ３３９は賛同の設定を保持する。本実施の形態では、視聴者により支払われる対価が多いほど賛同数が多くなるよう設定される。すなわち、同じ一人の視聴者による賛同であっても、支払われる対価によって賛同数が変動する。賛同設定ＤＢ３３９は、賛同のタイプごとに名称と、賛同を登録するために必要な対価ポイントと、賛同が登録されたときに加算される賛同数と、を対応付けて保持する。図１０の例では、「Super vote」、「I like it vote」は対価の支払いを必要とする賛同であり、「Nice vote」は対価の支払いを必要としない賛同である。

図３に戻り、配信情報提供部３０２は、ネットワークＮＷを介して、配信者のユーザ端末２０からライブ配信を開始する旨の通知を受けると、当該ライブ配信を特定するストリームＩＤと、当該ライブ配信の配信者の配信者ＩＤと、をストリームＤＢ３１４に登録する。配信情報提供部３０２は、ネットワークＮＷを介して、アクティブユーザのユーザ端末の配信外通信部４０４からライブ配信に関する情報の提供要求を受けると、ストリームＤＢ３１４を参照して現在視聴可能なライブ配信のリストを生成する。配信情報提供部３０２は、ネットワークＮＷを介して、生成されたリストを要求元のユーザ端末に送信する。要求元のユーザ端末の配信外ＵＩ制御部４０２は、受信したリストに基づいてライブ配信選択画面を生成し、ユーザ端末のディスプレイに表示させる。

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

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

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

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

希望受付部３２２は、視聴者によるユーザ端末３０への入力内容であって当該視聴者が参加しているライブ配信の配信者に関連付けられた入力内容を、当該配信者への希望として、当該ユーザ端末３０からネットワークＮＷを介して受け付ける。入力内容は例えばテキストや、複数の選択肢のなかから選択されたひとつの選択肢であってもよい。希望受付部３２２は、視聴者による対価の支払いまたは支払いの承諾を条件として、入力内容を希望として受け付ける。

より具体的には、希望受付部３２２は、ライブ配信中にネットワークＮＷを介して視聴者のユーザ端末３０から希望登録要求を受信する。希望登録要求は、当該ライブ配信の配信者の配信者ＩＤと、要求元のユーザ端末３０の視聴者の視聴者ＩＤと、視聴者による対価の支払いの承諾を示す情報と、ユーザ端末３０において入力された希望の内容を示すテキストと、を含む。

希望登録部３２４は、希望受付部３２２によって受け付けられた希望を、当該希望の対象となっている配信者に関連付けられたウィッシュリストに登録する。より具体的には、希望登録部３２４は、希望受付部３２２によって受信された希望登録要求に含まれる配信者ＩＤ、視聴者ＩＤ、テキストをそれぞれ対象配信者ＩＤ、要求者ＩＤ、希望内容としてウィッシュリストＤＢ３３６に登録する。

賛同受付部３２６は、配信者のウィッシュリストに登録されている希望に対する賛同を、当該配信者のライブ配信に参加している視聴者からネットワークＮＷを介して受け付ける。賛同受付部３２６は、視聴者による対価の支払いまたは支払いの承諾を条件として、希望に対する賛同を当該視聴者から受け付ける。賛同受付部３２６は、視聴者から賛同を受け付ける際に、賛同の対象となっている希望に既に賛同した他の視聴者の視聴者ＩＤを提示する。

より具体的には、賛同受付部３２６は、ライブ配信中にネットワークＮＷを介して視聴者のユーザ端末３０から賛同登録要求を受信する。賛同登録要求は、当該ライブ配信の配信者の配信者ＩＤと、賛同の対象となる希望の内容と、賛同のタイプと、視聴者による対価の支払いの承諾を示す情報と、要求元のユーザ端末３０の視聴者の視聴者ＩＤと、を含む。

賛同登録部３２８は、賛同受付部３２６によって受け付けられた賛同をウィッシュリストＤＢ３３６に登録する。より具体的には、賛同登録部３２８は賛同設定ＤＢ３３９を参照し、受信された賛同登録要求に含まれる賛同のタイプに対応する賛同数を特定する。賛同登録部３２８は、賛同受付部３２６によって受信された賛同登録要求に含まれる配信者ＩＤおよび希望の内容に対応する賛同数に、特定された賛同数が加算されるようにウィッシュリストＤＢ３３６を更新する。併せて賛同登録部３２８は、当該賛同登録要求に含まれる視聴者ＩＤを賛同者ＩＤに追加する。賛同者ＩＤは、賛同のタイプごとに分類される。

シェア部３３０は、賛同受付部３２６が視聴者から賛同を受け付ける際に、希望への賛同を求めるための当該視聴者によるシェアを可能とする。シェアはライブ配信システム１により実現されるライブ配信プラットフォーム以外のシステムやサービス（例えば、ソーシャルネットワークサービスやメッセージングサービスやプッシュ通知サービス）に情報を提供することにより実現される。シェアを実現するための技術自体は公知であるから詳述しない。

実現促進部３３２は、ウィッシュリストＤＢ３３６に保持されているウィッシュリストを、当該ウィッシュリストに対応する配信者に通知する。実現促進部３３２は、ウィッシュリストに登録されている希望に併せて、当該希望に対する賛同数を配信者に通知する。賛同数は希望に対する賛同の大きさを示す指標の一例である。他の実施の形態では、希望に対して支払われた対価の累計や、希望がシェアされた回数などを、賛同の大きさを示す指標として採用してもよい。

実現促進部３３２は、ウィッシュリストＤＢ３３６に登録されている各希望について達成促進条件が充たされたか否かを判定する。達成促進条件は例えば賛同数がしきい値を上回ることである。実現促進部３３２は、達成促進条件が充たされたと判定された希望を実現リストＤＢ３３８に登録する。実現促進部３３２は、ライブ配信中に、達成促進条件が充たされたと判定された希望を、当該ライブ配信の配信者および視聴者に通知する。

実現確認部３３４は、実現リストＤＢ３３８に登録されている各希望について当該希望が実現されたか否かを判定する。実現確認部３３４は、ライブ配信中にネットワークＮＷを介して配信者のユーザ端末２０から実現済登録要求を受信する。実現済登録要求は、当該ライブ配信の配信者の配信者ＩＤと、実現済みとされた希望の内容と、を含む。実現確認部３３４は、受信された実現済登録要求に含まれる配信者ＩＤおよび希望の内容に対応する実現済みフラグをＮＯからＹＥＳに変更するように実現リストＤＢ３３８を更新する。併せて実現確認部３３４は、受信された実現済登録要求に含まれる配信者ＩＤおよび希望の内容に対応する希望をウィッシュリストＤＢ３３６から消去する。

以上の構成によるライブ配信システム１の動作を説明する。
図９は、ライブ配信システム１における一連の処理の流れを示すフローチャートである。配信情報提供部３０２は配信者のユーザ端末２０からライブ配信を開始する旨の通知を受けると、ライブ配信の中継を開始する（Ｓ２０２）。視聴者は、上述の配信要求に係るプロセスにより、ステップＳ２０２で開始されたライブ配信に参加することができる。

希望受付部３２２は、ステップＳ２０２で開始されたライブ配信を視聴中の視聴者から、配信者に対する希望を受け付ける（Ｓ２０４）。希望受付部３２２は、ネットワークＮＷを介して視聴者のユーザ端末の視聴側通信部２０４から希望登録要求を受信する。支払い処理部３１０は、希望受け付けの対価の支払い処理を行う（Ｓ２０６）。支払い処理部３１０は、希望登録要求の受信に応じて、要求元の視聴者による対価の支払いを処理する。支払い処理部３１０は、希望登録要求に含まれる視聴者ＩＤで特定される視聴者のポイントから希望登録の対価ポイントを差し引くようユーザＤＢ３１８を更新する。

希望登録部３２４は、ステップＳ２０６で対価の支払いが完了すると、受け付けた希望をウィッシュリストＤＢ３３６に登録する（Ｓ２０８）。

賛同受付部３２６は、ステップＳ２０２で開始されたライブ配信を視聴中の他の視聴者から、ステップＳ２０８で登録された希望に対する賛同を受け付ける（Ｓ２１０）。賛同受付部３２６は、ネットワークＮＷを介して他の視聴者のユーザ端末の視聴側通信部２０４から賛同登録要求を受信する。支払い処理部３１０は、賛同受け付けの対価の支払い処理を行う（Ｓ２１２）。支払い処理部３１０は、賛同登録要求の受信に応じて、要求元の他の視聴者による対価の支払いを処理する。支払い処理部３１０は賛同設定ＤＢ３３９を参照し、受信された賛同登録要求に含まれる賛同のタイプに対応する対価ポイントを特定する。支払い処理部３１０は、賛同登録要求に含まれる視聴者ＩＤで特定される視聴者のポイントから特定された対価ポイントを差し引くようユーザＤＢ３１８を更新する。賛同受け付けの対価が無料のタイプの賛同の場合、ステップＳ２１２はスキップされる。

賛同登録部３２８は、ステップＳ２１２で対価の支払い処理が完了すると、対価に応じた数の賛同が加算されるようにウィッシュリストＤＢ３３６を更新する（Ｓ２１４）。

実現促進部３３２は、ステップＳ２１４で賛同数が更新された希望について、更新後の賛同数がしきい値を上回ったか否かを判定する（Ｓ２１６）。更新後の賛同数がしきい値以下の場合（Ｓ２１６のＮ）、処理はステップＳ２１０に戻る。更新後の賛同数がしきい値を上回る場合（Ｓ２１６のＹ）、実現促進部３３２は、ステップＳ２１４で賛同数が更新された希望を実現リストＤＢ３３８に登録する（Ｓ２１８）。しきい値は例えば２０、５０、１００などであってもよく、管理者により適宜定められてもよい。

実現促進部３３２は、ステップＳ２１４で賛同数が更新された希望への賛同が多いことを、ステップＳ２０２で開始されたライブ配信のライブ配信ルーム画面において配信者および視聴者に通知する（Ｓ２２０）。ライブ配信の配信者は、当該通知を見ることで、ステップＳ２１４で賛同数が更新された希望への賛同が多いことを知る。配信者は当該希望を実現する（Ｓ２２２）。実現確認部３３４は、配信者から、ステップＳ２２０で通知された希望が実現されたことの報告を受け付ける（Ｓ２２４）。実現確認部３３４は、実現された希望を消去するようウィッシュリストＤＢ３３６を更新すると共に、当該希望が実現済みとなったことを示すよう実現リストＤＢ３３８を更新する（Ｓ２２６）。

中継部３０４は、配信者のユーザ端末２０からライブ配信を終了する旨の通知を受けると、ライブ配信の中継を停止することでライブ配信を終了する（Ｓ２２８）。実現確認部３３４は、終了したライブ配信に係るウィッシュリストをウィッシュリストＤＢ３３６から消去する。実現確認部３３４は、終了したライブ配信に係る希望を実現リストＤＢ３３８から消去する。すなわち、本実施の形態では、希望の提出および賛同の登録はライブ配信内でのみ有効に行われる。すなわち、ウィッシュリストには時間の制限があり、ライブ配信の終了に併せてウィッシュリストも消去される。

図１１は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６０８の代表画面図である。ライブ配信ルーム画面６０８は、配信者のユーザ端末２０で生成された動画像をリアルタイムで表示する。ライブ配信ルーム画面６０８は、サーバ１０から受信した動画データを再生することにより得られる配信者の動画像６１０と、視聴者によるギフトの使用を可能とするギフトオブジェクト６１２と、コメント入力領域６１６と、コメント表示領域６１８と、ウィッシュリストオブジェクト６２０と、実現リストオブジェクト６２２と、希望提出オブジェクト６２４と、を有する。視聴側ＵＩ制御部２０２は、動画データを再生することにより得られる動画像６１０に、他のオブジェクト、すなわちギフトオブジェクト６１２、コメント入力領域６１６、コメント表示領域６１８、ウィッシュリストオブジェクト６２０、実現リストオブジェクト６２２、希望提出オブジェクト６２４を重畳表示することによりライブ配信ルーム画面６０８を生成する。

コメント表示領域６１８は、ライブ配信ルーム画面６０８を表示しているユーザ端末３０の視聴者により入力されたコメントと、他の視聴者により入力されたコメントと、配信者により入力されたコメントと、システムからの通知と、を含みうる。システムからの通知は、実現促進部３３２により生成される、達成促進条件が充たされたと判定された希望に関する情報を含む。図１１の例では、「A Funny dance」という希望への賛同数がしきい値を超えたので、当該希望への賛同が多く集まっていることを示すテキスト６１９がシステムからのコメントとしてコメント表示領域６１８に表示されている。視聴側ＵＩ制御部２０２はサーバ１０から受信した他の視聴者や配信者のコメントおよびシステムからの通知を含むコメント表示領域６１８を生成し、生成されたコメント表示領域６１８をライブ配信ルーム画面６０８に含める。

コメント入力領域６１６は視聴者によるコメントの入力を受け付ける。視聴側通信部２０４は、コメント入力領域６１６に入力されたコメントを含むコメント入力信号を生成し、ネットワークＮＷを介してサーバ１０に送信する。併せて視聴側ＵＩ制御部２０２は、コメント入力領域６１６に入力されたコメントを表示するようにコメント表示領域６１８を更新する。

図１２は、配信者のユーザ端末２０のディスプレイに表示されるライブ配信ルーム画面６５０の代表画面図である。ライブ配信ルーム画面６５０は、配信者のユーザ端末２０で生成された動画データを再生することにより得られる配信者の動画像６５２と、コメント表示領域６１８に対応するコメント表示領域６５４と、コメント入力領域６１６に対応するコメント入力領域６５６と、ウィッシュリストオブジェクト６５８と、実現リストオブジェクト６６０と、を有する。

動画像６５２は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６０８の動画像６１０と実質的に同じである。コメント表示領域６５４は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６０８のコメント表示領域６１８と実質的に同じである。

図１１の希望提出オブジェクト６２４へのタップが検出されると、ユーザ端末３０の視聴側ＵＩ制御部２０２は、視聴中のライブ配信の配信者に対する希望の入力を受け付けるための希望入力画面６２６を生成し、ユーザ端末３０のディスプレイに表示させる。図１３は、視聴者のユーザ端末３０のディスプレイに表示される希望入力画面６２６の代表画面図である。希望入力画面６２６は、視聴者によるテキスト入力を受け付ける入力領域６２８と、提出ボタン６３０と、希望提出の対価の額を示すテキスト６３２と、を有する。

視聴者は入力領域６２８に配信者への希望をテキストで入力し、提出ボタン６３０をタップする。視聴側ＵＩ制御部２０２は、提出ボタン６３０へのタップが検出されると、入力領域６２８に入力されたテキストを希望の内容を示すテキストとして含む希望登録要求を生成する。視聴側ＵＩ制御部２０２は、提出ボタン６３０へのタップが検出されると、それを、視聴者による対価の支払いの承諾として受け付ける。視聴側通信部２０４は生成された希望登録要求をサーバ１０に送信する。サーバ１０における希望登録要求の処理は上述のとおりである。

図１１のウィッシュリストオブジェクト６２０へのタップが検出されると、ユーザ端末３０の視聴側通信部２０４は、視聴中のライブ配信の配信者の配信者ＩＤを含むウィッシュリスト情報要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０の実現促進部３３２は、ウィッシュリスト情報要求を受信すると、当該要求に含まれる配信者ＩＤで特定される配信者に対するウィッシュリストをウィッシュリストＤＢ３３６から読み出す。具体的には実現促進部３３２は、受信したウィッシュリスト情報要求に含まれる配信者ＩＤと合致する対象配信者ＩＤを有する希望の要求者ＩＤ、希望内容、賛同数、各タイプの賛同者ＩＤをウィッシュリストＤＢ３３６から読み出してリスト化することでウィッシュリストを取得する。実現促進部３３２は、取得したウィッシュリストを要求元のユーザ端末３０に送信する。ユーザ端末３０の視聴側ＵＩ制御部２０２は、受信したウィッシュリストの内容を提示するためのウィッシュリスト概要画面６３４を生成し、ユーザ端末３０のディスプレイに表示させる。

図１４は、視聴者のユーザ端末３０のディスプレイに表示されるウィッシュリスト概要画面６３４の代表画面図である。ウィッシュリスト概要画面６３４は、配信者に対する希望をリスト形式で表示するリスト表示領域６３６と、分布表示領域６３８と、しきい値表示領域６４０と、を有する。リスト表示領域６３６は、配信者に対する希望ごとに、希望の内容６４２とその希望に対する賛同数６４４とを対応付けて表示する。リスト表示領域６３６は、希望を賛同数６４４が多い順に上から表示する。分布表示領域６３８は賛同の分布を示す。しきい値表示領域６４０は、希望をウィッシュリストから実現リストに移すために必要な賛同数を示す。

視聴者は、図１４のリスト表示領域６３６に表示されている希望を見て、興味のある希望があればその希望が表示されている領域をタップする。ユーザ端末３０の視聴側ＵＩ制御部２０２は、タップされた領域に対応する希望の詳細を表示する希望詳細画面６７０を生成し、ユーザ端末３０のディスプレイに表示させる。

図１５は、視聴者のユーザ端末３０のディスプレイに表示される希望詳細画面６７０の代表画面図である。希望詳細画面６７０は、図１４において視聴者によって指定された希望の詳細な内容を表示する詳細表示領域６７２と、当該希望を提出または要求した視聴者の視聴者ＩＤ（すなわち要求者ＩＤ）を示す要求者表示領域６７４と、当該希望に賛同した視聴者の視聴者ＩＤ（すなわち賛同者ＩＤ）を示す賛同者表示領域６７６と、希望詳細画面６７０を見ている視聴者から当該希望へのSuper voteを受け付けるための賛同ボタン６７８と、希望詳細画面６７０を見ている視聴者から当該希望へのI like it voteを受け付けるための賛同ボタン６８０と、希望詳細画面６７０を見ている視聴者から当該希望へのNice voteを受け付けるための賛同ボタン６８２と、希望詳細画面６７０を見ている視聴者が当該希望を他の者にシェアするためのシェアボタン６８４と、を有する。賛同者表示領域６７６は、賛同のタイプごとに賛同者ＩＤを表示する。各賛同ボタン６７８、６８０、６８２は、対応する賛同を登録するために必要な対価の額を示す。ただし、賛同ボタン６８２に対応する賛同は無料なので、無料を示す「Free」の文字が表示される。

視聴者は詳細表示領域６７２に表示される希望の詳細を読む。視聴者は、賛同者表示領域６７６を見ることで、当該希望に賛同を示した他の視聴者を知る。視聴者は、これらの情報を総合的に判断し、自分も当該希望に賛同すると決定する。視聴者は、３つの賛同のタイプのなかからひとつを選択し、選択したタイプの賛同ボタンをタップする。視聴側ＵＩ制御部２０２は、賛同ボタンへのタップが検出されると、ライブ配信の配信者の配信者ＩＤと、希望詳細画面６７０で詳細が表示されている希望の内容と、タップされた賛同ボタンに対応する賛同のタイプと、視聴者による対価の支払いの承諾を示す情報と、視聴者の視聴者ＩＤと、を含む賛同登録要求を生成する。視聴側ＵＩ制御部２０２は、賛同ボタンへのタップが検出されると、それを、視聴者による対価の支払いの承諾として受け付ける。視聴側通信部２０４は生成された賛同登録要求をサーバ１０に送信する。サーバ１０における賛同登録要求の処理は上述のとおりである。

視聴者は、詳細表示領域６７２に表示される希望を他の者にシェアすると決定した場合、シェアボタン６８４をタップする。視聴側ＵＩ制御部２０２は、シェアボタン６８４へのタップが検出されると、視聴者からシェア対象の指定（例えば、シェア先のサービス）を受け付けるためのポップアップ（不図示）をディスプレイに表示させる。視聴側ＵＩ制御部２０２は、シェア対象の指定を受け付けると、ライブ配信の配信者の配信者ＩＤと、希望詳細画面６７０で詳細が表示されている希望の内容と、指定されたシェア対象のサービスと、視聴者の視聴者ＩＤと、を含むシェア要求を生成する。視聴側通信部２０４は、生成されたシェア要求をサーバ１０に送信する。サーバ１０のシェア部３３０は、受信したシェア要求に基づきシェアを実行する。

図１２のウィッシュリストオブジェクト６５８へのタップが検出された場合に配信者のユーザ端末２０およびサーバ１０で行われる処理は、図１１のウィッシュリストオブジェクト６２０へのタップが検出された場合に行われる上述の処理に準じる。特に、実現促進部３３２は、要求元の配信者に対するウィッシュリストを当該要求元の配信者のユーザ端末２０に送信する。その結果、配信者は図１４のウィッシュリスト概要画面６３４と同様のウィッシュリスト概要画面を見ることで、自分に対する希望のリストを確認することができる。また、配信者は図１５の希望詳細画面６７０と同様の希望詳細画面を見ることで、希望の詳細と、当該希望の要求者と、当該希望への賛同者と、を確認することができる。なお、配信者に対して表示される希望詳細画面においては、図１４の賛同ボタン６７８、６８０、６８２およびシェアボタン６８４は表示されない。

図１２の実現リストオブジェクト６６０へのタップが検出されると、配信者のユーザ端末２０の配信側ＵＩ制御部１０８は、当該配信者の配信者ＩＤを含む実現リスト情報要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０の実現確認部３３４は、実現リスト情報要求を受信すると、当該要求に含まれる配信者ＩＤで特定される配信者に対する実現リストを実現リストＤＢ３３８から読み出す。具体的には実現確認部３３４は、受信した実現リスト情報要求に含まれる配信者ＩＤと合致する対象配信者ＩＤを有する希望の要求者ＩＤ、希望内容、賛同数、賛同者ＩＤ、実現済みフラグを実現リストＤＢ３３８から読み出してリスト化することで実現リストを取得する。実現確認部３３４は、取得した実現リストを要求元のユーザ端末２０に送信する。ユーザ端末２０の配信側ＵＩ制御部１０８は、受信した実現リストの内容を提示するための実現リスト表示画面６８８を生成し、ユーザ端末２０のディスプレイに表示させる。

図１６は、配信者のユーザ端末２０のディスプレイに表示される実現リスト表示画面６８８の代表画面図である。実現リスト表示画面６８８は、配信者は実現リストに表示されている希望を実現する義務を負っていない旨を示すテキスト６９０と、受信した実現リストに登録されている希望のうちまだ実現されていない希望（実現済みフラグがＮＯの希望）をリスト形式で表示する実現待ち希望表示領域６９２と、受信した実現リストに登録されている希望のうち実現済みの希望（実現済みフラグがＹＥＳの希望）をリスト形式で表示する実現済み希望表示領域６９４と、を有する。実現待ち希望表示領域６９２は、まだ実現されていない希望ごとに、希望の内容６９８とその希望の実現完了申請を受け付けるための実現完了ボタン６９６と、を対応付けて表示する。

配信者は、実現待ち希望表示領域６９２に表示されている希望をライブ配信内で実現した場合、その希望に対応する実現完了ボタン６９６をタップする。ユーザ端末２０の配信側ＵＩ制御部１０８は、ライブ配信の配信者の配信者ＩＤと、タップされた実現完了ボタン６９６に対応する希望の内容と、を含む実現済登録要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０における実現済登録要求の処理は上述のとおりである。図１１の実現リストオブジェクト６２２へのタップが検出された場合に視聴者のユーザ端末３０およびサーバ１０で行われる処理は、図１２の実現リストオブジェクト６６０へのタップが検出された場合に行われる上述の処理に準じる。なお、視聴者に対して表示される実現リスト表示画面においては、図１６の実現完了ボタン６９６は表示されない。

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

本実施の形態に係るライブ配信システム１によると、視聴者が配信者に対する希望を提出し、配信者は自分への希望がリスト化されたウィッシュリストを受け取る。これにより、配信者は自分の視聴者が何を望んでいるのかをより容易かつ正確に把握することができる。その結果、配信者はより視聴者に喜んでもらえるライブ配信を行うことができる。

また、本実施の形態に係るライブ配信システム１では、視聴者は、ウィッシュリストにリストされている希望のなかから気に入った希望に賛同することができる。ウィッシュリストには、希望に対応付けて当該希望に対する賛同の大きさを示す指標（本例では賛同数）が含まれる。したがって、当該ウィッシュリストに触れた配信者は、自分への希望のなかでも多くの賛同を集めている希望を知ることができる。その結果、賛同の多い希望から実現することでライブ配信をより効率的に行うことができる。

ライブ配信において、多くの視聴者による賛同を集めた希望が配信者によって実現されることで、配信者と視聴者との対話を促進し、両者の満足度を向上させることができる。

また、本実施の形態に係るライブ配信システム１では、視聴者は希望を提出するために対価を支払う必要がある。これにより、安易な希望が大量に提出される事態を抑制または回避することができる。

また、本実施の形態に係るライブ配信システム１では、視聴者は自己の賛同の強さに応じた賛同のタイプを選択することができる。したがって、多くの対価を支払ってでも配信者に希望を叶えてほしいと思う視聴者の思いも、対価を払うほどではないけれど希望を叶えてくれると嬉しいと思う視聴者の思いも、反映できるライブ配信システム１が実現される。

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

本実施の形態では、ライブ配信中に希望および賛同を受け付ける場合を説明したが、これに限られず、例えばライブ配信の有無に関わらず希望や賛同を受け付けてウィッシュリストに登録してもよい。本変形例では、例えば配信者のプロファイル画面またはアーカイブに希望入力画面６２６への導線となる希望提出オブジェクトと、ウィッシュリスト概要画面６３４への導線となるウィッシュリストオブジェクトと、実現リスト表示画面６８８への導線となる実現リストオブジェクトと、を配置する。アクティブユーザまたは配信者は、当該プロファイル画面またはアーカイブから各オブジェクトをタップすることで各画面にアクセスすることができる。

本変形例では、実現促進部３３２は、配信者への希望に対応するライブ配信の予定が生成された場合、それに賛同したユーザに当該予定を通知する。実現促進部３３２は、希望に対する賛同数が更新された場合、更新後の賛同数がしきい値を上回ったか否かを判定する。更新後の賛同数がしきい値を上回った場合、実現促進部３３２は、賛同数が更新された希望を実現するためのライブ配信の配信予定を受け付ける画面（不図示）を配信者のユーザ端末２０に表示させる。実現促進部３３２は当該画面を通じて配信者から、ライブ配信の配信予定を受け付ける。実現促進部３３２は、賛同数が更新された希望と、受け付けた配信予定と、を対応付けて実現リストＤＢ３３８に登録する。実現促進部３３２は、賛同数が更新された希望の賛同者のユーザ端末に、配信予定を含む通知を送信する。

図１７は、アクティブユーザのユーザ端末のディスプレイに表示される実現リスト表示画面７００の代表画面図である。アクティブユーザが配信者のプロフィール画面やアーカイブに設けられた実現リストオブジェクトをタップすると、図１６を参照して説明した処理と同様の処理により配信外ＵＩ制御部４０２は実現リスト表示画面７００を生成し、ディスプレイに表示させる。実現リスト表示画面７００は、テキスト６９０と同様のテキスト７０２と、受信した実現リストに登録されている希望のうちまだ実現されていない希望（実現済みフラグがＮＯの希望）をリスト形式で表示する実現待ち希望表示領域７０４と、受信した実現リストに登録されている希望のうち実現済みの希望（実現済みフラグがＹＥＳの希望）をリスト形式で表示する実現済み希望表示領域７０６と、を有する。実現待ち希望表示領域７０４は、まだ実現されていない希望ごとに、希望の内容および配信予定７１０と、リマインドボタン７０８と、を対応付けて表示する。アクティブユーザが非アクティブ状態のリマインドボタン７０８をタップすると、配信外ＵＩ制御部４０２はタップされたリマインドボタン７０８に対応する希望の配信予定をアクティブユーザのリマインドリストに登録する。配信外ＵＩ制御部４０２は、タップされたリマインドボタン７０８を非アクティブ状態からアクティブ状態に遷移させる。配信外ＵＩ制御部４０２は、リマインドリストに登録されている配信予定が近づくとアクティブユーザに通知する。リマインドの技術は公知であるから本明細書では詳述しない。

本実施の形態において、配信者がウィッシュリストまたは実現リストに登録されている希望を実現した場合、当該希望の提出に要した対価および／または当該希望への賛同の登録に要した対価に応じた報酬を当該配信者に付与してもよい。例えば、希望受付部３２２は、受け付けた希望と、希望提出の対価に応じた報酬と、を対応付けてウィッシュリストＤＢ３３６に登録する。賛同受付部３２６も同様に賛同の対価に応じた報酬をウィッシュリストＤＢ３３６に登録する。実現確認部３３４は、希望の実現を確認すると、当該希望に対応付けられた報酬が配信者の報酬に追加されるようユーザＤＢ３１８を更新する。この場合、配信者の自己申告によらない希望の実現の確認がなされてもよい。例えば、所定数以上の視聴者によって希望の実現が確認された場合に当該希望の実現が承認され、登録されてもよい。

本実施の形態では、視聴者による対価の支払いの承諾を条件として希望を受け付ける場合を説明したが、これに限られず、例えば視聴者による対価の支払いを条件として希望を受け付けるよう構成してもよい。対価の支払いを条件とする場合、例えばまず必要な対価の支払い処理を実行し、その後に希望を示すテキストを受け付けるよう構成してもよい。賛同の対価についても同様である。

本実施の形態では、支払う対価の異なる３つのタイプの賛同を設ける場合を説明したが、これに限られず、例えば無料の賛同のみを設けてもよい。この場合、全ての視聴者が平等な一票を有することとなる。

（第２の実施の形態）
第２の実施の形態に係るライブ配信システムでは、配信者がライブ配信を行わない期間が所定期間を超えると、当該配信者のプロフィール画面において、配信者に対するライブ配信の実施の求め（以下、配信実施希望という）をアクティブユーザから受け付けるための配信実施希望オブジェクトの表示が開始される。当該配信者によるライブ配信を望むアクティブユーザ（例えば、過去に当該配信者のライブ配信を継続視聴していた視聴者）は、当該配信者のプロフィール画面を閲覧し、配信実施希望オブジェクトをタップする。配信実施希望オブジェクトがタップされると、サーバは当該配信者に配信実施希望があった旨の通知を行う。これにより、アクティブユーザはオブジェクトをタップするという少ない手間で配信者に配信実施希望を伝えることができる。配信者は配信実施希望があった旨の通知を受け取ることでライブ配信を実施するモチベーションを得ることができる。

なお、本実施の形態の説明では、過去にライブ配信を行ったが現在はライブ配信を行っていないユーザも「配信者」と称する。

図１８は、第２の実施の形態に係るサーバ５０の機能および構成を示すブロック図である。サーバ５０は、配信情報提供部３０２と、中継部３０４と、ギフト処理部３０８と、支払い処理部３１０と、配信希望受付部５０２と、配信希望登録部５０４と、配信希望通知部５０６と、配信開始通知部５０８と、ストリームＤＢ３１４と、ユーザＤＢ３１８と、ギフトＤＢ３２０と、配信希望ＤＢ５１０と、を備える。

図１９は、図１８の配信希望ＤＢ５１０の一例を示すデータ構造図である。配信希望ＤＢ５１０は、アクティブユーザから受け付けた配信実施希望の情報を保持する。配信希望ＤＢ５１０は、ライブ配信の実施を求められている配信者の配信者ＩＤである対象配信者ＩＤと、当該配信者によるライブ配信の実施を希望するアクティブユーザの総数である希望者総数と、当該アクティブユーザのユーザＩＤである配信希望者ＩＤと、カムバックギフトの合計と、を対応付けて保持する。カムバックギフトは、アクティブユーザが対価を支払って配信実施希望を提出する場合の当該対価に対応する報酬である。配信者はライブ配信の実施を条件としてカムバックギフトの付与を受けることができる。

図１８に戻り、配信希望受付部５０２は、アクティブユーザのユーザ端末のディスプレイに表示される配信実施希望オブジェクトであって、ライブ配信の配信者に関連付けられた配信実施希望オブジェクトが指定された場合、当該指定を、当該配信者に対する配信実施希望として受け付ける。

配信実施希望オブジェクトはアクティブユーザが閲覧可能な画面であって特定の配信者に関連付けられている画面、、例えば配信者のプロフィール画面やアーカイブ選択画面、に設けられてもよい。以下、配信者のプロフィール画面に配信実施希望オブジェクトが設置される場合を説明する。

配信実施希望オブジェクトは、配信者がライブ配信を行なっていない期間の長さがしきい値を超えると当該配信者のプロフィール画面に表示される。言い換えると、配信者のプロフィール画面は、当該配信者がライブ配信を行なっていない期間の長さがしきい値を超えると配信実施希望オブジェクトの表示を開始する。配信実施希望オブジェクトは、配信者の前回の配信から所定の期間内に表示される当該配信者のプロフィール画面には表示されない。

アクティブユーザは所望の配信者のプロフィール画面の表示をユーザ端末に要求する。アクティブユーザのユーザ端末の配信外通信部４０４は、アクティブユーザにより指定された配信者の配信者ＩＤを含むプロフィール情報要求を生成し、ネットワークＮＷを介してサーバ５０に送信する。配信希望受付部５０２は、受信されたプロフィール情報要求に含まれる配信者ＩＤで特定される配信者のプロフィール情報を不図示の保持部から取得する。配信希望受付部５０２は、ユーザＤＢ３１８を参照し、当該配信者の前回のライブ配信の配信日時を取得する。配信希望受付部５０２は、取得された配信日時から現在までの期間の長さがしきい値（例えば、一週間や一ヶ月）を上回るか否かを判定する。配信希望受付部５０２は、上回ると判定された場合、オブジェクトフラグをオンに設定した上で当該オブジェクトフラグをプロフィール情報に含める。配信希望受付部５０２は、そうでなければオブジェクトフラグをオフに設定する。配信希望受付部５０２は、オブジェクトフラグを含むプロフィール情報を、要求元のユーザ端末にネットワークＮＷを介して送信する。ユーザ端末の配信外ＵＩ制御部４０２は、受信したプロフィール情報に基づきプロフィール画面を生成し、ディスプレイに表示させる。その際、配信外ＵＩ制御部４０２は、プロフィール情報に含まれるオブジェクトフラグがオンに設定されていると、プロフィール画面に配信実施希望オブジェクトを含める。オブジェクトフラグがオフに設定されている場合は配信実施希望オブジェクトは表示されない。

配信外通信部４０４は、配信者のプロフィール画面に表示された配信実施希望オブジェクトへのタップを検出すると、当該配信者の配信者ＩＤとタップしたアクティブユーザのユーザＩＤとを含む配信実施希望登録要求を生成し、ネットワークＮＷを介してサーバ５０に送信する。配信希望受付部５０２は、配信実施希望登録要求を受信すると、当該要求に含まれる配信者ＩＤで特定される配信者のプロフィール画面において配信実施希望オブジェクトが指定されたと認識する。配信希望受付部５０２は、当該指定を、当該配信者に対する配信実施希望として受け付ける。

配信希望登録部５０４は、配信希望受付部５０２によって受け付けられた配信実施希望を配信希望ＤＢ５１０に登録する。より具体的には、配信希望登録部５０４は、配信希望受付部５０２によって受信された配信実施希望登録要求に含まれる配信者ＩＤが既に配信希望ＤＢ５１０の対象配信者ＩＤに登録されているか否かを判定する。登録されている場合すなわち配信実施希望登録要求に含まれる配信者ＩＤに一致する対象配信者ＩＤが既に存在する場合、配信希望登録部５０４は当該対象配信者ＩＤに対応する希望者総数に１を加算し、併せて対応する配信希望者ＩＤに配信実施希望登録要求に含まれるユーザＩＤを追加する。登録されていない場合すなわち配信実施希望登録要求に含まれる配信者ＩＤに一致する対象配信者ＩＤがない場合、配信希望登録部５０４は配信希望ＤＢ５１０に新たなエントリを生成する。配信希望登録部５０４は当該エントリの対象配信者ＩＤに配信実施希望登録要求に含まれる配信者ＩＤを登録し、当該エントリの希望者総数に１を登録し、当該エントリの配信希望者ＩＤに配信実施希望登録要求に含まれるユーザＩＤを登録する。

本実施の形態では無料の（対価を要しない）配信実施希望と有料の（対価を要する）配信実施希望とを設ける。有料の配信実施希望の場合、配信希望受付部５０２は、アクティブユーザによる対価の支払いまたは支払いの承諾を条件として、配信者に対する配信実施希望を受け付ける。より具体的には、アクティブユーザが配信者のプロフィール画面において有料の配信実施希望に対応する配信実施希望オブジェクトをタップした場合、配信外ＵＩ制御部４０２は、配信実施希望オブジェクトへのタップを、アクティブユーザによる対価の支払いの承諾として受け付ける。配信外通信部４０４は、アクティブユーザによる対価の支払いの承諾を示す情報を配信実施希望登録要求に含める。支払い処理部３１０は、配信実施希望登録要求を受信すると、アクティブユーザによる対価の支払い処理を行う。配信希望登録部５０４は、対価に対応する報酬を配信希望ＤＢ５１０のカムバックギフトの合計に加算または新規登録する。対価と報酬との関係はライブ配信プラットフォームの管理者により適宜設定されてもよい。

配信希望通知部５０６は、配信者に対する配信実施希望を受け付けた場合、当該配信者に、配信実施希望があった旨を通知する。併せて配信希望通知部５０６は、当該配信者に対する配信実施希望の希望者総数および／またはカムバックギフトの合計を通知する。希望者総数は、対象配信者に対する配信実施希望の大きさを示す指標の一例である。カムバックギフトの合計は、対象配信者に対する配信実施希望の大きさを示す指標の他の例である。配信希望通知部５０６は、配信希望ＤＢ５１０に登録されている対象配信者について、希望者総数がしきい値を超えると、当該対象配信者に対して配信実施希望があった旨の通知（以下、配信希望通知という）を行う。配信希望通知部５０６は、配信実施希望があった旨を示すテキストおよび希望者総数を含む通知を、対象配信者のユーザ端末に送信することで配信希望通知を行う。

配信開始通知部５０８は、配信希望ＤＢ５１０に登録されている対象配信者がライブ配信を開始した場合、またはライブ配信の実施の予約を行った場合、当該対象配信者に対応付けて配信希望ＤＢ５１０に登録されている配信希望者に通知を行う。配信開始通知部５０８は、配信情報提供部３０２がライブ配信の開始を受け付けると、当該ライブ配信の配信者が配信希望ＤＢ５１０の対象配信者に登録されているか否かを判定する。配信開始通知部５０８は、登録されている場合、その対象配信者に対応付けて保持されている配信希望者を特定する。配信開始通知部５０８は、特定された配信希望者のユーザ端末に、対象配信者のライブ配信が開始された旨を示すテキストを含む通知を送信する。登録されていない場合、配信開始通知部５０８は通知を行わない。配信者によるライブ配信の実施の予約が受け付けられた場合、配信開始通知部５０８は同様の処理により対応する配信希望者に通知を行う。配信開始通知部５０８は、配信希望ＤＢ５１０に登録されている対象配信者がライブ配信を開始した場合、当該対象配信者に係るエントリを配信希望ＤＢ５１０から削除する。

配信開始通知部５０８は、配信希望ＤＢ５１０に登録されている対象配信者によるライブ配信の実施を条件として、カムバックギフトの合計を当該対象配信者に付与するための処理を行う。配信開始通知部５０８は、対象配信者の配信者ＩＤに対応する報酬に、カムバックギフトの合計を加えるようユーザＤＢ３１８を更新する。

図２０は、ライブ配信システム１における配信実施希望に係る処理の流れを示すフローチャートである。配信希望受付部５０２は、アクティブユーザから、配信者に対する配信実施希望を受け付ける（Ｓ２４０）。配信希望受付部５０２は、アクティブユーザのユーザ端末からネットワークＮＷを介して配信実施希望登録要求を受信する。

支払い処理部３１０は、配信実施希望が有料の場合、配信実施希望受け付けの対価の支払い処理を行う（Ｓ２４２）。配信実施希望が無料の場合、ステップＳ２４２はスキップされる。支払い処理部３１０は、配信実施希望登録要求の受信に応じて、要求元のアクティブユーザによる対価の支払いを処理する。支払い処理部３１０は、配信実施希望登録要求に含まれるユーザＩＤで特定されるアクティブユーザのポイントから、配信実施希望の対価ポイントを差し引くようユーザＤＢ３１８を更新する。

配信希望登録部５０４は、ステップＳ２４２で対価の支払い処理が完了すると、ステップＳ２４０で受け付けた配信実施希望を配信希望ＤＢ５１０に登録する（Ｓ２４４）。ステップＳ２４４では希望者総数、配信希望者ＩＤが更新され、有料の配信実施希望の場合はさらにカムバックギフトの合計が更新される。

配信希望通知部５０６は、ステップＳ２４４で希望者総数が更新された対象配信者について、更新後の希望者総数がしきい値（例えば、１０や３０）を上回ったか否かを判定する（Ｓ２４６）。更新後の希望者総数がしきい値を上回る場合（Ｓ２４６のＹ）、配信希望通知部５０６は、ステップＳ２４４で希望者総数が更新された対象配信者のユーザ端末に、配信希望通知を送信する（Ｓ２５０）。

更新後の希望者総数がしきい値以下の場合（Ｓ２４６のＮ）、配信希望通知部５０６は、ステップＳ２４４でカムバックギフトの合計が更新された対象配信者について、更新後のカムバックギフトの合計がしきい値（例えば、１０００や１００００）を上回ったか否かを判定する（Ｓ２４８）。更新後のカムバックギフトの合計がしきい値以下の場合（Ｓ２４８のＮ）、配信希望受付部５０２は新たな配信実施希望を待ち受ける状態となり、処理はステップＳ２４０に戻る。無料の配信実施希望の場合も同様に処理はステップＳ２４０に戻る。更新後のカムバックギフトの合計がしきい値を上回る場合（Ｓ２４８のＹ）、処理はステップＳ２５０に進む。

図２１は、アクティブユーザのユーザ端末のディスプレイに表示されるプロフィール画面７２０の代表画面図である。プロフィール画面７２０は、プロフィールの表示対象となっている配信者の配信者ＩＤ７２２と、当該配信者のサムネイル７２４と、当該配信者のライブ配信プラットフォームにおけるステータス７２６と、無料配信実施希望ボタン７２８と、有料配信実施希望ボタン７３０と、現在までに当該配信者に対して配信実施希望を提出したユーザの総数すなわち希望者総数を含むテキスト７３２と、を有する。無料配信実施希望ボタン７２８および有料配信実施希望ボタン７３０は配信実施希望オブジェクトの例である。有料配信実施希望ボタン７３０は配信実施希望の対価の額の表示を含む。

配信外通信部４０４は、無料の配信実施希望に対応する無料配信実施希望ボタン７２８へのタップを検出すると、プロフィールの表示対象となっている配信者の配信者ＩＤとタップしたアクティブユーザのユーザＩＤとを含む配信実施希望登録要求を生成し、ネットワークＮＷを介してサーバ５０に送信する。配信外通信部４０４は、有料の配信実施希望に対応する有料配信実施希望ボタン７３０へのタップを検出すると、プロフィールの表示対象となっている配信者の配信者ＩＤとタップしたアクティブユーザのユーザＩＤと当該アクティブユーザによる対価の支払いの承諾を示す情報とを含む配信実施希望登録要求を生成し、ネットワークＮＷを介してサーバ５０に送信する。

図２２は、配信者のユーザ端末のディスプレイに表示される通知画面７３４の代表画面図である。通知画面７３４は、希望者総数がしきい値を上回った場合に配信希望通知部５０６により送信される第１配信希望通知７３６と、カムバックギフトの合計がしきい値を上回った場合に配信希望通知部５０６により送信される第２配信希望通知７３８と、を含む。配信者のユーザ端末の配信外ＵＩ制御部４０２は、ネットワークＮＷを介して受信した第１配信希望通知７３６および／または第２配信希望通知７３８を含む通知画面７３４を生成してディスプレイに表示させる。

第１配信希望通知７３６は、図２０のステップＳ２４６で希望者総数がしきい値を上回った場合にステップＳ２５０で送信される配信希望通知に対応する。第１配信希望通知７３６は、現在までに配信者に対して配信実施希望を提出したユーザの総数７４２すなわち希望者総数と、代表的な配信希望者の配信希望者ＩＤ７４０と、を含む。第２配信希望通知７３８は、図２０のステップＳ２４８でカムバックギフトの合計がしきい値を上回った場合にステップＳ２５０で送信される配信希望通知に対応する。第２配信希望通知７３８は、現在のカムバックギフトの合計７４４を含む。

配信外通信部４０４は、第１配信希望通知７３６または第２配信希望通知７３８へのタップを検出すると、ライブ配信を開始する旨の通知を生成し、ネットワークＮＷを介してサーバ５０に送信する。

図２３は、配信者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面７４６の代表画面図である。第１配信希望通知７３６や第２配信希望通知７３８を受けた配信者がライブ配信を開始すると、当該配信者のユーザ端末のディスプレイにライブ配信ルーム画面７４６が表示される。ライブ配信ルーム画面７４６の構成は図１２のライブ配信ルーム画面６５０の構成と以下の点を除き同様である。ライブ配信ルーム画面７４６は、配信者がライブ配信を再開したことにより当該配信者に付与されたカムバックギフトの合計を含むギフト取得通知７４８を有する。

本実施の形態に係るライブ配信システム１によると、アクティブユーザは対象の配信者のプロフィール画面において配信実施希望オブジェクトを指定するという簡単な操作で、当該配信者に対する配信実施希望を提出することができる。加えて、配信者はアクティブユーザから配信希望通知を受けることでライブ配信を行うモチベーションを得ることができる。

本発明者等は、ライブ配信プラットフォームの運営に係る経験から、ライブ配信をいったん止めた配信者が再びライブ配信を始める理由のひとつに、元の視聴者から配信を再開してほしいと言われたことがあることを見出した。ダイレクトメッセージなどのコミュニケーションツールを用いて元の視聴者が配信者に希望を伝えるという方法もあるが、多数の視聴者とそれぞれ濃いコミュニケーションをとることは配信者に大きな負担を与えうる。そこで、本実施の形態では、元の視聴者や他のアクティブユーザの声を簡単に配信者に届ける機能を、配信実施希望オブジェクトにより実現する。これにより、配信者の負担を抑えつつ、より多くの視聴者／アクティブユーザの配信実施希望を配信者に伝えることができる。その結果、配信者のライブ配信離脱を低減または防止して、ライブ配信への復帰へと誘導することができる。

また、本実施の形態に係るライブ配信システム１では、配信者に対するライブ配信の実施の求めの大きさを示す指標を配信者に通知する。したがって、配信者は求めの大きさの程度に応じてライブ配信を再開するか否かを決めることができる。

また、本実施の形態に係るライブ配信システム１では、配信実施希望オブジェクトは配信者がライブ配信を行なっていない期間の長さがしきい値を超えると表示される。したがって、比較的長期間ライブ配信を止めていた配信者をターゲットとした配信実施希望の通知を実現することができる。さらに、このようなしきい値を設けることで、継続してライブ配信を行っているにもかかわらず多数の配信希望通知を受けてしまうといったトラブルを防ぐことができる。これらの結果、継続してライブ配信を行っている配信者への悪影響を低減または除去しつつ、比較的長期間ライブ配信を止めている配信者のライブ配信への復帰を促すことができる。

また、本実施の形態に係るライブ配信システム１では、アクティブユーザは有料の配信実施希望を提出することができ、配信者はライブ配信を再開することで当該希望の対価に応じたカムバックギフトを受け取ることができる。これにより、ライブ配信の再開を強く希望するアクティブユーザはその希望の大きさを対価の支払いという形で示すことができる。カムバックギフトの存在は、対象の配信者がライブ配信を再開する追加的なモチベーションとなるので、ライブ配信への復帰がより促進される。

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

本実施の形態では、希望者総数がしきい値を上回った場合、または、カムバックギフトの合計がしきい値を上回った場合に配信希望通知を配信者に送信する場合を説明したが、これに限られない。例えば、希望者総数にしきい値を設けることなく、配信実施希望を受け付けるたびに配信希望通知を送信するよう構成してもよい。あるいはまた、希望者総数にしきい値を設ける一方、有料の配信実施希望を受け付けるたびに配信希望通知を送信するよう構成してもよい。この際、有料の配信実施希望を提出したアクティブユーザのユーザＩＤを配信希望通知に表示してもよい。この場合、無料の配信実施希望が提出された場合は希望者総数がしきい値を上回ることを条件として配信希望通知がなされる一方、有料の配信実施希望が提出された場合はその都度配信希望通知がなされる。これにより、有料と無料との効果の差を出すことができる。あるいはまた、複数の異なるしきい値を設けてもよい。例えば、希望者総数のしきい値として１００、３００、１０００の３つを設けてもよい。この場合、希望者総数が増えるにつれて合計３回の配信希望通知がなされる。

本実施の形態では、配信実施希望の受け付けをトリガとして配信希望通知を送信する場合を説明したが、これに限られず、例えば配信希望通知部５０６は一時間ごと、毎日など周期的に配信希望ＤＢ５１０を参照し、条件を充たす対象配信者に配信希望通知を行ってもよい。

本実施の形態では、対象配信者がライブ配信を再開することを条件としてカムバックギフトの合計を当該対象配信者に付与する場合を説明したが、これに限られず、配信時間や視聴者数に応じて段階的にカムバックギフトの合計を付与してもよい。例えば、対象配信者がライブ配信を再開することでカムバックギフトの合計の５％を対象配信者に付与し、以降視聴者が一人増えるごとに３％を付与してもよい。あるいはまた、配信時間１分当たり所定量のギフトを、カムバックギフトの合計に到達するまで付与してもよい。この場合、対象配信者がライブ配信を再開してカムバックギフトの合計を回収し、その後すぐに当該ライブ配信を終了する、というような事態を抑制することができる。

本実施の形態では、第１配信希望通知７３６と第２配信希望通知７３８とを異なる通知としたが、これに限られず、両者をまとめてひとつの通知としてもよい。例えば、希望者総数とカムバックギフトの合計とを含む配信希望通知を提供してもよい。

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

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

情報処理装置９００は、ＣＰＵ９０１、ＲＯＭ（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 (2)

1. ユーザの端末のディスプレイに表示される所定のオブジェクトであって、ライブ配信の配信者に関連付けられた所定のオブジェクトが指定された場合、当該指定を、当該配信者に対するライブ配信の実施の求めとして受け付ける受付手段と、
   前記ユーザによる前記所定のオブジェクトの指定を通じて前記配信者に対するライブ配信の実施の求めを受け付けた場合、前記配信者に、ライブ配信の実施の求めがあることを通知する通知手段と、
   前記ユーザによる前記所定のオブジェクトの指定を通じて前記配信者に対するライブ配信の実施の求めを受け付けた場合、前記ユーザを、前記配信者によるライブ配信の開始に係る通知を送信する対象として登録する登録手段と、を備えるサーバ。
2. 前記配信者によるライブ配信の実施を希望する他のユーザの数を、前記ユーザの前記端末に送信する送信手段をさらに備え、
   前記ユーザの前記端末の前記ディスプレイにおいて、前記所定のオブジェクトは送信された前記数と関連付けて表示される請求項１に記載のサーバ。

Images