JP7272572B1 - サーバおよび方法 - Google Patents

Abstract

【課題】所定の配信者やライブ配信をプロモートするかまたは所定の視聴者を優遇する。【解決手段】サーバは、ライブ配信内でプレイ可能な、ポイントの得喪を伴うゲームを提供するよう構成されたサーバであって、配信者の端末から視聴者の端末へのライブ配信に係る動画データの伝送を中継する手段と、視聴者の端末からネットワークを介して、ゲームの開始要求を受信する手段と、開始要求の受信に応じて、ライブ配信の配信者に対応する得喪設定を有するゲームの、ライブ配信内における視聴者の端末への提供を開始する手段と、を備える。【選択図】図１

Description

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

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

ライブ配信の視聴を促進するためにライブ配信内でプレイ可能なゲームを提供することが知られている（例えば非特許文献１、２参照）。

特表２０２２－５２１３４８号公報

FayBlog、「Uplive（アップライブ）のダイヤ獲得方法！ミニゲームについても解説！」、URL:https://fayevery.blog/uplive-diamond#index_id6 日経ＸＴＲＥＮＤ、「23年ブレイク必至「ライブゲーム」 ミラティブが掘り当てた新鉱脈」、２０２２年１２月５日、URL:https://xtrend.nikkei.com/atcl/contents/18/00745/00002/

ライブ配信プラットフォームの運営上の施策として、所定の配信者やライブ配信をプロモートしたり、所定の視聴者を優遇することがある。そのための新たな仕組みが求められている。

本開示はこうした課題に鑑みてなされたものであり、その目的は、所定の配信者やライブ配信をプロモートするかまたは所定の視聴者を優遇するための技術の提供にある。

本発明のある態様は、サーバに関する。このサーバは、ライブ配信内でプレイ可能な、ポイントの得喪を伴うゲームを提供するよう構成されたサーバであって、配信者の端末から視聴者の端末へのライブ配信に係る動画データの伝送を中継する手段と、視聴者の端末からネットワークを介して、ゲームの開始要求を受信する手段と、開始要求の受信に応じて、ライブ配信の配信者に対応する得喪設定を有するゲームの、ライブ配信内における視聴者の端末への提供を開始する手段と、を備える。

本発明の別の態様は、コンピュータプログラムである。このコンピュータプログラムは、ライブ配信内でプレイ可能な、ポイントの得喪を伴うゲームを提供するよう構成されたサーバとネットワークを介して通信する機能と、第１得喪設定を有するゲームに関連付けられた第１ライブ配信と、第１得喪設定とは異なる第２得喪設定を有するゲームに関連付けられた第２ライブ配信と、を含む視聴可能なライブ配信のリストを、サーバからネットワークを介して受信する機能と、リストに含まれるライブ配信を表すオブジェクトをディスプレイに表示させる際、第１ライブ配信を表すオブジェクトの表示態様と第２ライブ配信を表すオブジェクトの表示態様とを異ならせる機能と、を端末に実現させる。

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

本発明によれば、所定の配信者やライブ配信をプロモートするかまたは所定の視聴者を優遇することができる。

本開示の実施の形態に係るライブ配信システムの構成を示す模式図である。 図１のユーザ端末の機能および構成を示すブロック図である。 図１のサーバの機能および構成を示すブロック図である。 図３のストリームＤＢの一例を示すデータ構造図である。 図３のユーザＤＢの一例を示すデータ構造図である。 図３のギフトＤＢの一例を示すデータ構造図である。 図３の割り当てＤＢの一例を示すデータ構造図である。 ライブ配信中に視聴者によってゲームの開始の指示が入力されたときのライブ配信システムにおける一連の処理の流れを示すフローチャートである。 アクティブユーザのユーザ端末のディスプレイに表示されるライブ配信選択画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示されるライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される、ゲーム領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 視聴者のユーザ端末のディスプレイに表示される、ゲーム領域が重畳表示されたライブ配信ルーム画面の代表画面図である。 本実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。 図１４（ａ）～（ｅ）は、ゲームインスタンス構成の例を示す模式図である。

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

実施の形態に係るライブ配信システムでは、ライブ配信内でプレイ可能な、ポイントの得喪を伴うゲーム（以下、単にゲームという）がライブ配信の視聴者に提供される。このゲームは、ライブ配信の配信者に対応する得喪設定を有する。すなわち、視聴している配信者が異なれば、ゲームの得喪設定も異なりうる。得喪設定は倍率、勝率などを含み、ゲームの結果払い戻されるポイントの期待値により特徴付けられる。本実施の形態では、所定の配信者に対して、通常得喪設定よりもポイントの得喪に関して視聴者にとって有利な特別得喪設定を対応付ける。例えば、特別得喪設定の期待値を通常得喪設定の期待値よりも大きく設定する。このように配信者に応じてゲームの有利さを調整することで、ゲームに変化をもたせて興趣を向上させることができる。また、特定の配信者をプロモートすることができる。

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

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

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

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

本明細書において「配信時間」は、ひとつのライブ配信に関連付けられたパラメータであって、当該ライブ配信が継続した期間の長さを指す。配信時間は、当該ライブ配信に視聴者がいるか否かとは無関係に算出される。
本明細書において「総配信時間」は、配信者に関連付けられたパラメータであって、所定の期間において対象の配信者が行ったライブ配信の配信時間を通算することで得られる時間である。
本明細書において「視聴時間」は、視聴者と配信者とのペアに関連付けられたパラメータであって、当該視聴者が当該配信者のライブ配信を視聴した期間の長さ（view duration）を指す。
本明細書において「被視聴時間」は、配信者に関連付けられたパラメータであって、当該配信者のライブ配信が視聴者に視聴された期間の長さ（viewed duration）を指す。この場合の視聴者はランダムに選択された一名であってもよいし、ランダムに選択された視聴者の部分集合であってもよいし、全ての視聴者であってもよい。あるいはまた、被視聴時間は視聴者に亘って算出された平均値であってもよい。被視聴時間は、配信者のライブ配信が視聴者側でどの程度視聴されているかを示す指標である。
本明細書において「総被視聴時間」は、被視聴時間の一態様であって、所定の期間において対象の配信者のライブ配信を視聴した全ての視聴者について、その視聴時間を通算することで得られる時間である。

例えば、所定の期間において配信者Ａのライブ配信を視聴者Ｂが２時間、視聴者Ｃが３時間、視聴者Ｄが４時間、視聴した場合、以下のようになる。
視聴者Ｂの視聴時間＝２時間
視聴者Ｃの視聴時間＝３時間
視聴者Ｄの視聴時間＝４時間
配信者Ａのライブ配信の総被視聴時間＝２＋３＋４＝９時間
配信者Ａのライブ配信の平均被視聴時間＝９／３＝３時間
配信者Ａのライブ配信の被視聴時間：総被視聴時間でもよいし、平均被視聴時間でもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図５は、図３のユーザＤＢ３１８の一例を示すデータ構造図である。ユーザＤＢ３１８は、ユーザに関する情報を保持する。ユーザＤＢ３１８は、ユーザを特定するユーザＩＤと、当該ユーザが有しているポイントと、当該ユーザに付与された報酬と、を対応付けて保持する。

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

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

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

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

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

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

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

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

ゲーム処理部３３０は、ライブ配信内におけるゲームの提供に係る処理を行う。ゲーム処理部３３０は、開始要求受付部３３２と、通常インスタンス３３４と、特別インスタンス３３６と、割り当てＤＢ３３８と、インスタンス制御部３４０と、を含む。

本実施の形態では、ゲームはシングルプレイヤーゲームであって、そのゲームではまず視聴者は複数の要素のなかからひとつの要素を選択してポイントを供出する。ゲーム処理部３３０のゲームインスタンスは所定の確率に従う抽選を行い、複数の要素のなかから当たりの要素を決める。視聴者が選択した要素が抽選に当たれば視聴者は勝利し、そうでなければ視聴者は敗北する。各要素は対応するオッズ（倍率）に関連付けられている。視聴者が勝利すれば供出したポイント×オッズ分のポイントが払い戻され、敗北すれば払い戻しはない。要素のオッズが高いほど、その要素が抽選で選ばれる確率は低くなる。このようなライブ配信内ゲームは、例えば非特許文献１に記載される技術により実現されてもよい。

インスタンス制御部３４０は、得喪設定の異なる複数のゲームインスタンスを生成し、それらを制御する。本実施の形態では、通常得喪設定を有する通常インスタンス３３４と、特別得喪設定を有する特別インスタンス３３６と、が生成される。以下にゲームの例を示す。
（ゲーム甲）
ルール
・視聴者が要素Ａおよび要素Ｂのうちからひとつの要素を選択する
・ゲームインスタンスが要素Ａおよび要素Ｂのうちから抽選でひとつの要素を当たりの要素として選択する
・要素Ａが抽選で選択される確率を０．７、要素Ｂが抽選で選択される確率を０．３に設定する
・要素Ａが視聴者に選択される確率と要素Ｂが視聴者に選択される確率は等しい、すなわちそれぞれ０．５と仮定する
通常得喪設定
・要素Ａのオッズを１．２倍、要素Ｂのオッズを３倍に設定する。従って期待値は
０．５×０．７×１．２ ＋ ０．５×０．３×３ ＝ ０．８７
特別得喪設定
・要素Ａのオッズを１．４倍、要素Ｂのオッズを３．２倍に設定する。従って期待値は
０．５×０．７×１．４ ＋ ０．５×０．３×３．２ ＝ ０．９７
ゲーム甲の場合、オッズを調整することにより、特別得喪設定の期待値（０．９７）は通常得喪設定の期待値（０．８７）よりも大きく設定されている。したがって、特別得喪設定のほうが通常得喪設定よりも視聴者にとって有利であると言える。
（ゲーム乙）
ルール
・視聴者が要素Ｃおよび要素Ｄのうちからひとつの要素を選択する
・ゲームインスタンスが要素Ｃおよび要素Ｄのうちから抽選でひとつの要素を当たりの要素として選択する
・要素Ｃのオッズを１．１倍、要素Ｄのオッズを４倍に設定する。
・要素Ｃが視聴者に選択される確率と要素Ｄが視聴者に選択される確率は等しい、すなわちそれぞれ０．５と仮定する
通常得喪設定
・要素Ｃが抽選で選択される確率を０．９、要素Ｂが抽選で選択される確率を０．１に設定する。従って期待値は
０．５×０．９×１．１ ＋ ０．５×０．１×４ ＝ ０．６９５
特別得喪設定
・要素Ｃが抽選で選択される確率を０．８、要素Ｂが抽選で選択される確率を０．２に設定する。従って期待値は
０．５×０．８×１．１ ＋ ０．５×０．２×４ ＝ ０．８４
ゲーム乙の場合、抽選で選択される確率を調整することにより、特別得喪設定の期待値（０．８４）は通常得喪設定の期待値（０．６９５）よりも大きく設定されている。したがって、特別得喪設定のほうが通常得喪設定よりも視聴者にとって有利であると言える。
他の例として得喪設定によりオッズおよび抽選確率の両方を調整するゲームがあってもよい。

通常インスタンス３３４、特別インスタンス３３６などのゲームインスタンスは、例えば特許文献１に開示されるゲームインスタンス化の技術を用いて実現されてもよい。本実施の形態におけるゲームインスタンスは共通のゲームロジックおよび共通のユーザインタフェースを有しつつ、オッズや確率などのパラメータが異なるよう設定される。このパラメータはライブ配信プラットフォームの管理者により設定されてもよい。

図７は、図３の割り当てＤＢ３３８の一例を示すデータ構造図である。割り当てＤＢ３３８は、配信者と得喪設定との対応関係を保持する。割り当てＤＢ３３８は、配信者の配信者ＩＤと、当該配信者に対応付けられている得喪設定を示す情報と、を対応付けて保持する。図７の例では、得喪設定を示す情報は、通常得喪設定であれば「通常」、特別得喪設定であれば「特別」、となる。

割り当てＤＢ３３８はライブ配信プラットフォームの管理者により更新されてもよい。管理者は、ライブ配信プラットフォームでライブ配信を始めてから所定の期間、例えば１週間、が経過していない新規配信者に特別得喪設定が対応付けられるように割り当てＤＢ３３８の内容を更新してもよい。その結果、割り当てＤＢ３３８は、新規配信者と特別得喪設定を示す情報とを対応付けて保持することとなる。この場合、より有利な得喪設定を求めて新規配信者のライブ配信に視聴者が集まりやすくなるので、新規配信者をプロモートすることができる。あるいはまた、管理者は、ライブ配信のイベントに関連して選択されたイベント配信者に特別得喪設定が対応付けられるように割り当てＤＢ３３８の内容を更新してもよい。その結果、割り当てＤＢ３３８は、イベント配信者と特別得喪設定を示す情報とを対応付けて保持することとなる。この場合、より有利な得喪設定を求めてイベント配信者のライブ配信に視聴者が集まりやすくなるので、イベントを盛り上げることができ、またイベント配信者をプロモートすることができる。

図７の例では割り当てＤＢ３３８は配信者ＩＤを保持する場合を説明したが、これに限られず、例えば配信者ＩＤに代えてストリームＩＤを保持してもよい。この場合、割り当てＤＢ３３８は、ストリームＩＤを介して、当該ストリームＩＤで特定されるライブ配信を行っている配信者の配信者ＩＤと、得喪設定の種別と、を間接的に対応付ける。

図３に戻り、開始要求受付部３３２は、視聴者のユーザ端末３０からネットワークＮＷを介して、ゲームの開始要求（以下、ゲーム開始要求という）を受信する。視聴者はライブ配信の視聴を開始してライブ配信を視聴しているときに、ゲームの開始の指示をユーザ端末３０に入力する。ユーザ端末３０の視聴側通信部２０４は、その指示を受け付けると、視聴者が視聴しているライブ配信の配信者の配信者ＩＤを含むゲーム開始要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。開始要求受付部３３２はそのように送信されたゲーム開始要求を受信する。

インスタンス制御部３４０、通常インスタンス３３４、特別インスタンス３３６は合わせて、開始要求受付部３３２によるゲーム開始要求の受信に応じて、視聴者が視聴しているライブ配信の配信者に対応する得喪設定を有するゲームの、当該ライブ配信内における当該視聴者のユーザ端末３０への提供を開始する手段を構成する。

インスタンス制御部３４０は、開始要求受付部３３２によるゲーム開始要求の受信に応じて、割り当てＤＢ３３８を参照し、当該ゲーム開始要求の送信元の視聴者が視聴するライブ配信の配信者に対応する得喪設定を特定する。インスタンス制御部３４０は、受信したゲーム開始要求から配信者ＩＤを抽出する。インスタンス制御部３４０は、抽出された配信者ＩＤに対応する得喪設定の種別を、割り当てＤＢ３３８を参照することで特定する。

インスタンス制御部３４０は、特定された種別の得喪設定に対応するゲームインスタンスに、ゲーム開始要求の送信元の視聴者のユーザ端末３０へのゲームの提供を開始させる。インスタンス制御部３４０は、通常得喪設定が特定された場合は通常インスタンス３３４を選択し、特別得喪設定が特定された場合は特別インスタンス３３６を選択する。インスタンス制御部３４０は、選択されたゲームインスタンスにゲームの提供を開始させる。

図７の例では、配信者「ＡＢＣ」のライブ配信において視聴者「ＵＳＲ１」からゲーム開始要求が送信された場合、インスタンス制御部３４０は配信者「ＡＢＣ」に対応する通常得喪設定を特定し、したがって通常インスタンス３３４を選択する。通常インスタンス３３４は、配信者「ＡＢＣ」のライブ配信のなかで視聴者「ＵＳＲ１」のユーザ端末への、通常得喪設定を有するゲームの提供を開始する。また、配信者「ＤＥＦ」のライブ配信において視聴者「ＵＳＲ１」からゲーム開始要求が送信された場合、インスタンス制御部３４０は配信者「ＤＥＦ」に対応する特別得喪設定を特定し、したがって特別インスタンス３３６を選択する。特別インスタンス３３６は、配信者「ＤＥＦ」のライブ配信のなかで視聴者「ＵＳＲ１」のユーザ端末への、特別得喪設定を有するゲームの提供を開始する。このように同じ視聴者「ＵＳＲ１」がプレイするゲームであっても、ライブ配信の配信者が異なると提供元のインスタンスも異なることとなり、ゲームの有利さも異なることとなる。

以上の構成によるライブ配信システム１の動作を説明する。
図８は、ライブ配信中に視聴者によってゲームの開始の指示が入力されたときのライブ配信システム１における一連の処理の流れを示すフローチャートである。サーバ１０は、ゲーム開始要求を待ち受ける（Ｓ２０２）。ゲーム開始要求が受信された場合（Ｓ２０２のＹ）、サーバ１０はゲーム開始要求に含まれる配信者ＩＤを、要求元の視聴者が視聴しているライブ配信の配信者の配信者ＩＤとして特定する（Ｓ２０４）。サーバ１０は、特定された配信者ＩＤに対応するゲームインスタンスを特定する（Ｓ２０６）。通常インスタンス３３４が特定された場合（Ｓ２０６の「通常」）、サーバ１０は要求元の視聴者のユーザ端末３０と通常インスタンス３３４とを接続することで、通常得喪設定を有するゲームの提供を開始する（Ｓ２１０）。特別インスタンス３３６が特定された場合（Ｓ２０６の「特別」）、サーバ１０は要求元の視聴者のユーザ端末３０と特別インスタンス３３６とを接続することで、特別得喪設定を有するゲームの提供を開始する（Ｓ２１２）。

図９は、アクティブユーザのユーザ端末のディスプレイに表示されるライブ配信選択画面６００の代表画面図である。ライブ配信選択画面６００は、サーバ１０から受信した現在視聴可能なライブ配信のリストにある各ライブ配信を示すサムネイル６０２、６０４を含む。配信外ＵＩ制御部４０２は、サーバ１０から取得したライブ配信のリストに基づいてライブ配信選択画面６００を生成し、ディスプレイに表示させる。図９の例では、配信外通信部４０４は、特別得喪設定を有するゲームに関連付けられた第１ライブ配信と、特別得喪設定とは異なる通常得喪設定を有するゲームに関連付けられた第２ライブ配信と、を含む視聴可能なライブ配信のリストを、サーバ１０からネットワークＮＷを介して受信する。配信外ＵＩ制御部４０２は、受信したリストに含まれるライブ配信を表すサムネイルをディスプレイに表示させる際、第１ライブ配信を表すサムネイル６０２の表示態様と第２ライブ配信を表すサムネイル６０４の表示態様とを異ならせる。より具体的には、配信外ＵＩ制御部４０２は、リストに含まれるライブ配信に対応付けられたフラグが特別得喪設定を示す場合は、そのライブ配信のサムネイル６０２に特別設定バッジ６０６を付加する。フラグが通常得喪設定を示す場合は特別設定バッジ６０６は付加されない（サムネイル６０４参照）。

このように、特別得喪設定を有するゲームを提供する第１ライブ配信のサムネイル６０２を、通常得喪設定を有するゲームを提供する第２ライブ配信のサムネイル６０４よりも目立たせることで、アクティブユーザが第１ライブ配信を見つけやすくなる。これにより、特別得喪設定による配信者のプロモートの効果を高めることができる。

なお、特別設定バッジ６０６の付与に代えてまたは加えて、ライブ配信選択画面６００において、第１ライブ配信のサムネイル６０２は、第２ライブ配信のサムネイル６０４よりも目立つ位置、例えば画面の上部、に配置されてもよい。この場合、ライブ配信プラットフォームにおいて、特別得喪設定を有するゲームを提供可能な配信者をさらにプロモートすることができる。

図１０は、視聴者のユーザ端末３０のディスプレイに表示されるライブ配信ルーム画面６０８の代表画面図である。図９のライブ配信選択画面６００において視聴者がサムネイル６０２をタップすると、図１０のライブ配信ルーム画面６０８がディスプレイに表示される。ライブ配信ルーム画面６０８は、配信者のユーザ端末２０で生成された動画像をリアルタイムで表示する。ライブ配信ルーム画面６０８は、サーバ１０から受信した動画データを再生することにより得られる配信者の動画像６１０と、ギフトオブジェクト６１２と、コメント入力領域６１６と、コメント表示領域６１８と、視聴終了ボタン６２０と、ゲームオブジェクト６０９と、特別設定インジケータ６１１と、を有する。視聴側ＵＩ制御部２０２は、動画データを再生することにより得られる動画像６１０に、他のオブジェクト、すなわちギフトオブジェクト６１２、コメント入力領域６１６、コメント表示領域６１８、視聴終了ボタン６２０、ゲームオブジェクト６０９、特別設定インジケータ６１１を重畳表示することによりライブ配信ルーム画面６０８を生成する。

コメント表示領域６１８は、視聴者により入力されたコメントと、他の視聴者により入力されたコメントと、システムからの通知と、を含みうる。システムからの通知は、配信者に誰がどのギフトを贈ったかを示す情報を含む。視聴側ＵＩ制御部２０２はサーバ１０から受信した他の視聴者のコメントおよびシステムからの通知を含むコメント表示領域６１８を生成し、生成されたコメント表示領域６１８をライブ配信ルーム画面６０８に含める。

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

視聴終了ボタン６２０は、ライブ配信の視聴を止めるための指示を視聴者から受け付けるためのオブジェクトである。

ゲームオブジェクト６０９は、視聴者がライブ配信を視聴しているときに、ゲームの開始の指示を当該視聴者から受け付けるためのオブジェクトである。

特別設定インジケータ６１１は、ライブ配信の配信者が特別得喪設定に対応付けられている場合に表示される。ライブ配信の配信者が通常得喪設定に対応付けられている場合、特別設定インジケータ６１１は表示されない。視聴者は、特別設定インジケータ６１１の有無により、現在視聴しているライブ配信を通じてプレイ可能なゲームが特別得喪設定を有するかそれとも通常得喪設定を有するかを容易に判別することができる。

視聴者はライブ配信を視聴しているときに、ゲームオブジェクト６０９をタップする。ユーザ端末３０の視聴側ＵＩ制御部２０２は、ゲームオブジェクト６０９へのタップを検出すると、それをゲームの開始の指示として受け付ける。ユーザ端末３０の視聴側通信部２０４は、その指示を受け付けると上述のゲーム開始要求を生成し、ネットワークＮＷを介してサーバ１０に送信する。サーバ１０のインスタンス制御部３４０は、ゲーム開始要求の受信に応じて、特別インスタンス３３６に、視聴者のユーザ端末３０へのゲームの提供を開始させる。ユーザ端末３０の視聴側ＵＩ制御部２０２は、特別インスタンス３３６から受信したゲームデータに基づきゲーム６２２を生成する。視聴側ＵＩ制御部２０２は生成されたゲーム領域６２２をライブ配信ルーム画面６０８に重畳表示させる。

図１１は、視聴者のユーザ端末３０のディスプレイに表示される、ゲーム領域６２２が重畳表示されたライブ配信ルーム画面６０８の代表画面図である。ゲーム領域６２２はライブ配信ルーム画面６０８の上に重畳表示されたポップアップダイアログである。ゲーム領域６２２は、現在のゲームラウンドの残り時間を示す残り時間領域６２４と、それぞれが対応するオッズに関連付けられた三つの異なる要素６２６、６２８、６３０と、低ベットオブジェクト６３２と、高ベットオブジェクト６３４と、プレイヤーたる視聴者が現在有しているポイントの量および当該視聴者の現在の総利益／損失を示すポイント表示領域６３６と、を有する。

視聴者は三つの要素６２６、６２８、６３０のうちのひとつをタップして、その要素にいくらかのポイントをベットする。あるいはまた、視聴者は低ベットオブジェクト６３２および高ベットオブジェクト６３４のうちのひとつをドラッグして所望の要素の上でドロップすることでベットしてもよい。現在のゲームラウンドの期間が満了すると、特別インスタンス３３６は抽選を行い、三つの要素６２６、６２８、６３０のなかから当たりの要素を決定する。

図１２は、視聴者のユーザ端末３０のディスプレイに表示される、ゲーム領域６２２が重畳表示されたライブ配信ルーム画面６０８の代表画面図である。図１２は、図１１に示されるゲームラウンドにおいて視聴者が勝利した状況に対応する。視聴者は要素６２８（ぶどう）に低ベットオブジェクト６３２をドラッグアンドドロップすることでベットし、特別インスタンス３３６は抽選により要素６２８を当たりの要素として決定する。ゲーム領域６２２には、視聴者のベットを示すオブジェクト６４０と当たりの要素６２８を示す枠６３８とが表示される。特別インスタンス３３６は、視聴者が３倍のオッズで勝利したと判定し、視聴者に（－１００）＋（１００×３）＝＋２００ポイントを払い戻すための処理（例えば、ユーザＤＢ３１８の更新）を行う。図１２のポイント表示領域６３６にはこの払い戻しの結果が反映されている。

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

本実施の形態に係るライブ配信システム１によると、ライブ配信内でプレイ可能なゲームについて、所定の配信者を、通常得喪設定よりも視聴者にとって有利な特別得喪設定に対応付けることができる。したがって、そのような所定の配信者をプロモートすることができる。例えば、新規の配信者やイベントに参加した配信者に特別得喪設定を対応付けることで、新規の配信者に多くの視聴者を呼び込んでライブ配信を軌道に乗せたり、イベントを盛り上げたりすることができる。

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

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

1. ライブ配信内でプレイ可能な、ポイントの得喪を伴うゲームを提供するよう構成されたサーバであって、
   配信者の端末から視聴者の端末へのライブ配信に係る動画データの伝送を中継する手段と、
   視聴者の端末からネットワークを介して、ゲームの開始要求を受信する手段と、
   開始要求の受信に応じて、ライブ配信の配信者に対応する得喪設定を有するゲームの、ライブ配信内における視聴者の端末への提供を開始する手段と、を備えるサーバ。
2. 配信者と得喪設定との対応関係を保持する保持手段と、
   開始要求の受信に応じて、前記保持手段を参照し、当該開始要求の送信元の視聴者が視聴するライブ配信の配信者に対応する得喪設定を特定する手段と、をさらに備え、
   前記開始する手段は特定された得喪設定を有するゲームの提供を開始する請求項１に記載のサーバ。
3. 前記保持手段は、所定の配信者と、他の得喪設定よりもポイントの得喪に関して視聴者にとって有利な所定の得喪設定と、の対応関係を保持する請求項２に記載のサーバ。
4. 前記所定の配信者は、ライブ配信を始めてから所定の期間が経過していない配信者を含む請求項３に記載のサーバ。
5. 前記所定の配信者は、ライブ配信のイベントに関連して選択された配信者を含む請求項３に記載のサーバ。
6. ポイントはライブ配信中に視聴者から配信者にギフトを贈るために用いられる請求項１に記載のサーバ。
7. 前記保持手段は、配信者と、ランダムに決定された異なる複数の得喪設定のうちのひとつと、の対応関係を保持する請求項２に記載のサーバ。
8. ライブ配信内でプレイ可能な、ポイントの得喪を伴うゲームを提供するよう構成されたサーバで行われる方法あって、
   配信者の端末から視聴者の端末へのライブ配信に係る動画データの伝送を中継することと、
   視聴者の端末からネットワークを介して、ゲームの開始要求を受信することと、
   開始要求の受信に応じて、ライブ配信の配信者に対応する得喪設定を有するゲームの、ライブ配信内における視聴者の端末への提供を開始することと、を含む方法。
9. ライブ配信内でプレイ可能な、ポイントの得喪を伴うゲームを提供するよう構成されたサーバとネットワークを介して通信する機能と、
   第１得喪設定を有するゲームに関連付けられた第１ライブ配信と、第１得喪設定とは異なる第２得喪設定を有するゲームに関連付けられた第２ライブ配信と、を含む視聴可能なライブ配信のリストを、前記サーバからネットワークを介して受信する機能と、
   前記リストに含まれるライブ配信を表すオブジェクトをディスプレイに表示させる際、前記第１ライブ配信を表すオブジェクトの表示態様と前記第２ライブ配信を表すオブジェクトの表示態様とを異ならせる機能と、を端末に実現させるためのコンピュータプログラム。

Images