以下、図面を参照しながら、本発明の実施形態について説明する。
図1は、本発明の一実施形態に係る動画配信サーバ10を含むネットワークの構成を概略的に示す構成図である。動画配信サーバ10は、図示するように、インターネット等の通信ネットワーク20を介してユーザ端末30と通信可能に接続されている。図1においては、1つのユーザ端末30のみが図示されているが、サーバ10は、複数のユーザ端末30と通信可能に接続されている。動画配信サーバ10は、ライブ動画を配信及び視聴するためのライブ動画配信サービスを、ユーザ端末30を介してユーザに提供する。本実施形態において、ユーザ端末30を操作するユーザは、配信者としてライブ動画を配信することができ、また、視聴者として他のユーザによって提供されるライブ動画を視聴することもできる。動画配信サーバ10は、本発明のシステムの一部又は全部を実装する装置の一例である。
動画配信サーバ10は、一般的なコンピュータとして構成されており、図1に示すように、コンピュータプロセッサ11と、メインメモリ12と、入出力I/F13と、通信I/F14と、ストレージ(記憶装置)15とを備え、これらの各構成要素が図示しないバス等を介して電気的に接続されている。
コンピュータプロセッサ11は、CPU又はGPU等として構成され、ストレージ15等に記憶されている様々なプログラムをメインメモリ12に読み込んで、当該プログラムに含まれる各種の命令を実行する。メインメモリ12は、例えば、DRAM等によって構成される。
入出力I/F13は、ユーザ等との間で情報をやり取りするための各種の入出力装置を含む。入出力I/F13は、例えば、キーボード、ポインティングデバイス(例えば、マウス、タッチパネル等)等の情報入力装置、マイクロフォン等の音声入力装置、カメラ等の画像入力装置を含む。また、入出力I/F13は、ディスプレイ等の画像出力装置、スピーカー等の音声出力装置を含む。
通信I/F14は、ネットワークアダプタ等のハードウェア、各種の通信用ソフトウェア、及びこれらの組み合わせとして実装され、通信ネットワーク20等を介した有線又は無線の通信を実現できるように構成されている。
ストレージ15は、例えば磁気ディスク、フラッシュメモリ等によって構成される。ストレージ15は、オペレーティングシステムを含む様々なプログラム、及び各種データ等を記憶する。
本実施形態において、動画配信サーバ10は、それぞれが上述したハードウェア構成を有する複数のコンピュータを用いて構成され得る。例えば、動画配信サーバ10は、1又は複数のサーバ装置によって構成され得る。
このように構成された動画配信サーバ10は、ウェブサーバ及びアプリケーションサーバとしての機能を有するように構成することができ、この場合、ユーザ端末30にインストールされているウェブブラウザ及びその他のアプリケーション(例えば、ライブ動画配信サービス用のアプリケーション)からの要求に応答して各種の処理を実行し、当該処理の結果に応じた画面データ(例えば、HTMLデータ)及び制御データ等をユーザ端末30に送信する。ユーザ端末30では、受信したデータに基づくウェブページ又はその他の画面が表示され得る。
ユーザ端末30は、一般的なコンピュータとして構成されており、図1に示すように、コンピュータプロセッサ31と、メインメモリ32と、入出力I/F33と、通信I/F34と、ストレージ(記憶装置)35とを備え、これらの各構成要素が図示しないバス等を介して電気的に接続されている。
コンピュータプロセッサ31は、CPU又はGPU等として構成され、ストレージ35等に記憶されている様々なプログラムをメインメモリ32に読み込んで、当該プログラムに含まれる各種の命令を実行する。メインメモリ32は、例えば、DRAM等によって構成される。
入出力I/F33は、ユーザ等との間で情報をやり取りするための各種の入出力装置を含む。入出力I/F33は、例えば、キーボード、ポインティングデバイス(例えば、マウス、タッチパネル等)等の情報入力装置、マイクロフォン等の音声入力装置、カメラ等の画像入力装置を含む。また、入出力I/F33は、ディスプレイ等の画像出力装置、スピーカー等の音声出力装置を含む。
通信I/F34は、ネットワークアダプタ等のハードウェア、各種の通信用ソフトウェア、及びこれらの組み合わせとして実装され、通信ネットワーク20等を介した有線又は無線の通信を実現できるように構成されている。
ストレージ35は、例えば磁気ディスク又はフラッシュメモリ等によって構成される。ストレージ35は、オペレーティングシステムを含む様々なプログラム及び各種データ等を記憶する。ストレージ35が記憶するプログラムは、アプリケーションマーケット等からダウンロードされてインストールされ得る。
本実施形態において、ユーザ端末30は、スマートフォン、タブレット端末、ウェアラブルデバイス、パーソナルコンピュータ、及びゲーム専用端末等として構成され得る。
このように構成されたユーザ端末30を操作するユーザは、ストレージ35等にインストールされているウェブブラウザ又はその他のアプリケーションを介した動画配信サーバ10との通信を実行することによって、動画配信サーバ10が提供するライブ動画配信サービスを利用することができる。
次に、本実施形態の動画配信サーバ10が有する機能について説明する。図2は、動画配信サーバ10が有する機能を概略的に示すブロック図である。サーバ10は、図示するように、様々な情報を記憶及び管理する情報記憶管理部41と、ライブ動画配信サービスの基本機能を制御する基本機能制御部43と、ライブ動画の配信を制御する動画配信制御部45とを有する。これらの機能は、コンピュータプロセッサ11及びメインメモリ12等のハードウェア、並びに、ストレージ15等に記憶されている各種プログラムやデータ等が協働して動作することによって実現され、例えば、メインメモリ12に読み込まれたプログラムに含まれる命令をコンピュータプロセッサ11が実行することによって実現される。また、図2に示すサーバ10の機能の一部又は全部は、サーバ10とユーザ端末30とが協働することによって実現され、又は、ユーザ端末30によって実現され得る。
動画配信サーバ10の情報記憶管理部41は、ストレージ15等において様々な情報を記憶及び管理する。情報記憶管理部41は、例えば、図2に示すように、ライブ動画配信サービスのユーザに関する情報を管理するユーザ情報テーブル411と、個別のライブ動画の配信に関する情報を管理する配信情報テーブル412とを有するように構成される。
動画配信サーバ10の基本機能制御部43は、ライブ動画配信サービスの基本機能の制御に関する様々な処理を実行する。例えば、基本機能制御部43は、基本機能に関する様々な画面の画面データ又は制御データをユーザ端末30に送信し、ユーザ端末30で表示される当該画面を介したユーザによる操作入力に応答して様々な処理を実行し、当該処理の結果に応じた画面データ又は制御データをユーザ端末30に送信する。基本機能制御部43によって制御される基本機能は、例えば、ログイン処理(ユーザ認証)、課金制御、及び、ユーザ管理(例えば、ユーザ情報テーブル411の更新等)等を含む。
動画配信サーバ10の動画配信制御部45は、ライブ動画の配信の制御に関する様々な処理を実行する。例えば、動画配信制御部45は、複数の配信者の各々のライブ動画を複数の視聴者の各々に対して配信するように構成されている。例えば、動画配信制御部45は、配信者のユーザ端末30(以下、「配信者端末30」と言うことがある。)から送信されるライブ動画を受信して、当該ライブ動画を複数の視聴者の各々のユーザ端末30(以下、「視聴者端末30」と言うことがある。)に送信するように構成される。ライブ動画は、例えば、配信者端末30のカメラを介して入力される画像、及び、マイクを介して入力される音声によって構成される。こうしたライブ動画の配信は、例えば、HTTP Live Streaming(HLS)等のプロトコルを用いたストリーミング方式で行われ得る。
本実施形態において、動画配信制御部45は、ライブ動画の配信中において、複数の視聴者の各々による、ライブ動画の配信者に対するアイテムの入力を受け付けるように構成されている。例えば、動画配信制御部45は、各視聴者端末30において表示される所定の画面を介してライブ動画を視聴者に提示し、1の視聴者によって当該所定の画面を介して入力されたアイテムを、各視聴者端末30における当該所定の画面において表示する(例えば、ライブ動画に重ねて表示する)ように構成される。視聴者によって入力されるアイテムは、仮想的及び電子的な様々なアイテムを含み得る。こうしたアイテムは、例えば、様々なタイミングにおいて、有償又は無償で視聴者に付与される。
本実施形態において、動画配信制御部45は、視聴者によるアイテムの入力に応じて、今回のアイテムの入力が所定のコンボ条件を充足するか否かを判定し、当該所定のコンボ条件を充足すると判定される場合にコンボを発生させるように構成されている。所定のコンボ条件は、典型的には、今回のアイテムの入力よりも前の過去のアイテムの入力(例えば、前回の(直前の)アイテムの入力、又は、前回のコンボにおけるアイテムの入力等)との間で要求される条件として構成される。
また、動画配信制御部45は、コンボの発生に応じて、配信者に対して第1の価値を付与するように構成されている。第1の価値は、配信者に対して利益をもたらし得る様々な仮想的及び電子的なアイテム、ポイント、及び各種のパラメータ値として構成され得る。第1の価値の保有数量(合計値)は、例えば、ユーザ情報テーブル411又は配信情報テーブル412において管理される。
このように、本実施形態における動画配信サーバ10は、ライブ動画の複数の視聴者の各々によるアイテムの入力が所定のコンボ条件を充足すると判定される場合にコンボを発生させるから、ライブ動画の視聴者間のコミュニケーションを活性化させることができ、さらに、こうしたコンボの発生に応じて第1の価値を配信者に付与するから、当該ライブ動画の配信者と視聴者との間の繋がりを強化することができる。
また、動画配信制御部45は、今回のアイテムの入力が、前回までのコンボに対するコンボの連鎖が可能な連鎖可能期間(例えば、前回のコンボの発生から所定の時間が経過するまでの期間等)において行われており、且つ、所定のコンボ条件を充足すると判定される場合に、今回発生させるコンボを前回までのコンボに連鎖させると共に、コンボの連鎖数が大きいほど多くの第1の価値を配信者に対して付与するように構成され得る。コンボの連鎖数は、単に「コンボ数」と呼ばれることがある。また、動画配信制御部45は、上記連鎖可能期間の終了に応じてコンボの連鎖をクリアする(コンボの連鎖数をクリアする)ように構成され得る。コンボの連鎖がクリアされると、例えば、次回のコンボの発生から、新たなコンボの連鎖が開始され得る。こうした構成は、コンボの連鎖を促進し、この結果、より一層の、視聴者間のコミュニケーションの活性化が図られる。
本実施形態において、コンボを発生(及び連鎖)させるための所定のコンボ条件は、今回のアイテムの入力(の態様)に要求される様々な条件を含み得る。例えば、所定のコンボ条件は、今回入力されたアイテムの価値と、前回入力されたアイテムの価値又は前回のコンボにおいて入力されたアイテムの価値と、の関係が、所定の関係であるという条件(例えば、今回入力されたアイテムの価値(現実の又は仮想の通貨による価格等)が、前回入力されたアイテム等の価値よりも高いという条件等)を含み得る。こうした構成は、例えば、価値の高いアイテムを保有する視聴者(例えば、上級者)と、価値の高いアイテムを保有しておらず価値の低いアイテムのみを保有する視聴者(例えば、初心者)との間の連携が要求されるから、多様な視聴者間のコミュニケーションの活性化を促進する。
また、所定のコンボ条件は、コンボの連鎖における同一のアイテム(同一の種類のアイテム)の入力回数が閾値以下であるという条件を含み得る。例えば、こうした同一のアイテムの入力回数が1回以下に制限されており、前回までのコンボにおいてアイテムAが入力されている場合、今回のアイテムAの入力は、所定のコンボ条件を充足しない。こうした構成は、連鎖する一連のコンボにおいて多数の種類のアイテムが入力されることを促進する。
また、所定のコンボ条件は、コンボの連鎖における同一の視聴者によるアイテムの入力回数が閾値以下であるという条件を含み得る。例えば、こうした同一の視聴者によるアイテムの入力回数が1回以下に制限されており、前回までのコンボにおいて視聴者Aによってアイテムが入力されている場合、今回の視聴者Aによるアイテムの入力は、所定のコンボ条件を充足しない。こうした構成は、多数の視聴者がコンボの連鎖(アイテムの入力)に参加することを促進する。
また、動画配信制御部45は、ライブ動画の配信中における複数の視聴者の視聴状況に少なくとも基づく数量の第2の価値を配信者に対して付与するように構成され得る。例えば、動画配信制御部45は、視聴者数、及び、複数の視聴者の各々によるアイテム、コメント、いいね等の入力状況等に基づいて、配信者に対して付与する第2の価値の数量を設定するように構成される。第2の価値は、配信者に対して利益をもたらし得る様々な仮想的及び電子的なアイテム、ポイント、及び各種のパラメータ値として構成され得る。第2の価値の保有数量(合計値)は、例えば、ユーザ情報テーブル411又は配信情報テーブル412において管理される。
また、動画配信制御部45は、上記第1の価値の保有数量が閾値以上となることを必要条件として、視聴状況に少なくとも基づいて設定される第2の価値の数量が多くなるように構成された所定のモードを開始するように構成され得る。例えば、視聴状況が同一である場合において、設定される第2の価値の数量は、所定のモードでない場合よりも所定のモードである場合の方が多くなる。この場合、第1の価値は、所定のモードを開始するために蓄積されるパラメータ値等であると言える。こうした構成は、所定のモードを介した配信者に対する利益の付与を可能とする。
また、動画配信制御部45は、第1の価値の保有数量が閾値以上となった後における配信者による指示に応じて、所定のモードを開始するように構成され得る。こうした構成は、配信者が、所定のモードを開始するタイミングを決定することを可能とする。この結果、所定のモードの開始に対する戦略性が要求され、配信者に対して楽しみを与えると共に、配信者及び視聴者間のコミュニケーションを活性化させ得る。
また、動画配信制御部45は、所定のモードの開始に応じて、当該所定のモード用のアイテムの入力を可能とするように構成され得る。こうした構成は、所定のモード用のアイテムの希少価値を向上させ、所定のモードにおけるアイテムの入力を促進し得る。
次に、このような機能を有する本実施形態の動画配信サーバ10の具体例について説明する。図3は、この例において、ユーザ情報テーブル411において管理される情報を例示する。ユーザ情報テーブル411は、ライブ動画配信サービスのユーザに関する情報を管理し、図示するように、個別のユーザを識別する「ユーザアカウント」に対応付けて、アカウント名、年齢、性別等のユーザの基本的な情報である「基本情報」、ライブ動画の配信履歴に関する情報である「配信履歴情報」、他のユーザが配信するライブ動画の視聴履歴に関する情報である「視聴履歴情報」、ユーザがフォローしている他のユーザに関する情報である「フォローユーザ情報」、ユーザをフォローしている他のユーザ(フォロワー)に関する情報である「フォロワー情報」、配信者としてのユーザのランクを示す「ランク」、ランクアップ/ダウンを判定するためのパラメータ値である「ランクメータ値」、ライブ動画配信サービスにおける仮想的なコインの保有数を示す「コイン保有数」、同じく仮想的なダイヤの保有数を示す「ダイヤ保有数」、ライブ動画の配信中においてフィーバータイム(所定のモード)を開始するためのフィーバーゲージの値を示す「フィーバーゲージ値」(第1の価値)等の情報を管理する。
図4は、この例における配信者の「ランク」を説明するための図である。図示するように、この例では、「S」、「A」、「B」、「C」、「D」及び「E」の6つのランク帯が存在し、「S」、「A」、「B」、「C」、「D」の5つのランク帯の各々は、3つのランク(例えば、「S+」、「S」、「S-」のように、ランク帯を示すアルファベットに「+」を付加したランク、当該アルファベットのみのランク、及び、当該アルファベットに「-」を付加したランク)によって構成されている。また、「E」のランク帯は、1つのランク「E」によって構成されている。つまり、この例では、16段階(3×5+1=16)のランクが存在している。
また、ランク帯は、「S」側が最上位であって「E」側が最下位である。また、同一のランク帯内のランクは、「+」側が最上位であって「-」側が最下位である。この例では、ユーザのランクは、初期値として「D-」が設定される。
図5は、この例において、配信情報テーブル412において管理される情報を例示する。配信情報テーブル412は、個別のライブ動画の配信に関する情報を管理し、図示するように、個別の配信を識別する「配信ID」に対応付けて、この配信の配信者を識別する「配信者ユーザアカウント」、「配信日時」、配信の継続時間を示す「配信時間」、「視聴者数(現在値及び最大値)」、視聴者によって入力されたコメントの数である「コメント数」、視聴者によって入力された「いいね」の数である「いいね数」、視聴者によるアイテムの入力に応じて加算される「アイテムポイント」、当該アイテムの入力に応じて発生し得るコンボに関する情報である「コンボ情報」、現在がフィーバータイムであるか否かを示す「フィーバータイムフラグ」、フィーバータイム中におけるコメント、いいね、及びアイテムの入力に応じて加算される「フィーバースコア」、この配信に対して付与される基本ポイントである「基本ポイント」、基本ポイントに対してフィーバースコアを加算したポイントである「配信ポイント」(第2の価値)等の情報を管理する。コンボ情報は、コンボ数及びコンボ履歴(連鎖する各コンボにおけるアイテムの入力の履歴(視聴者及びアイテムの組合せの履歴))等を含む。
図6は、ライブ動画配信サービスのトップ画面60を例示する。当該画面60は、図示するように、「フォロー」、「人気」及び「すべて」と表示されたフィルター領域62と、配信中のライブ動画を一覧表示する一覧表示領域64と、「配信」と表示された配信開始ボタン66とを有する。
フィルター領域62は、一覧表示領域64において表示される配信中のライブ動画に対するフィルタリングを設定するための領域である。具体的には、フィルター領域62において「フォロー」が選択されると、一覧表示領域64において一覧表示されるライブ動画は、ユーザがフォローしているユーザのライブ動画に絞り込まれる。同様に、フィルター領域62において「人気」が選択されると、一覧表示領域64において一覧表示されるライブ動画は、人気を有する動画を抽出するための所定の抽出条件に従って抽出されたライブ動画(例えば、視聴者数(現在値)が閾値以上であるライブ動画)に絞り込まれる。また、フィルター領域62において「すべて」が選択されると、フィルタリングなしで配信中の全てのライブ動画が一覧表示の対象となる。
一覧表示領域64には、各々が個別のライブ動画に関する情報を表示する複数の個別表示領域641が2列で配置される。個別表示領域641は、例えば、ライブ動画の配信者によって予め設定されている静止画像、配信者のアカウント名、及び、視聴者数(現在値)等を表示する。一覧表示領域64は、上下方向へのフリック操作/スライド操作等によって、表示される個別表示領域641が切り替わるように構成されている。
配信開始ボタン66は、ユーザが、配信者としてライブ動画の配信を開始するためのオブジェクトである。当該配信開始ボタン66がユーザによって選択されると、ライブ動画の配信が開始され、具体的には、ユーザ端末30のカメラを介して入力される画像、及び、同じくユーザ端末30のマイクを介して入力される音声によって構成される動画のサーバ10への送信が開始される。また、ライブ動画の配信の開始に応じて、配信情報テーブル412において新たなレコードが作成される。
図7は、配信開始ボタン66の選択(つまり、ライブ動画の配信の開始)に応じて配信者端末30において表示される配信者用画面70を例示する。当該画面70は、画面全体に対応する動画表示領域71と、画面左上隅に位置する基本情報表示領域72と、当該領域72の下側に位置するフィーバーゲージ73と、当該フィーバーゲージ73の下側に位置するアイテム情報表示領域74と、当該領域74の下側に位置するアクション情報表示領域75と、画面下端部中央に位置する円形の配信停止ボタン76とを有する。
動画表示領域71は、配信されるライブ動画、つまり、配信者端末30のカメラを介して入力される画像が表示される。配信者は、通常は、配信者端末30のインカメラを介して配信者自身を撮影するので、配信されるライブ動画には配信者自身が含まれる。
基本情報表示領域72は、この配信の基本情報を表示し、具体的には、配信者情報(プロフィール画像等)、この配信の視聴者数(現在値)、及び、この配信に対して視聴者によって入力された「いいね」の数等を表示する。
フィーバーゲージ73は、配信者のフィーバーゲージの値をゲージ形式で表示する。上述したように、フィーバーゲージの値は、ユーザ情報テーブル411において管理されており、詳しくは後述するが、視聴者によるアイテムの入力に基づくコンボの発生及び連鎖に応じて増加する。
アイテム情報表示領域74は、詳しくは後述するが、視聴者によるアイテムの入力に応じて、当該アイテムの入力に関する情報を表示する。
アクション情報表示領域75は、視聴者によって行われたアクションに関する情報を表示し、具体的には、当該領域75には、各々が個別のアクションに対応する複数のアクションオブジェクトAOが上下方向に並べて配置される。アクション情報表示領域75は、視聴者によって新たなアクションが行われると、対応するアクションオブジェクトAOが下側に追加され、既存のアクションオブジェクトAOが順に上方向に移動するように構成されている。アクション情報表示領域75は、上下方向へのフリック操作/スライド操作等によって、表示されるアクションオブジェクトAOが切り替わるように構成されている。アクション情報表示領域75において表示される視聴者によるアクションは、入室(視聴の開始)、「いいね」の入力、コメントの入力、及び、アイテムの入力が含まれる。
配信停止ボタン76は、配信者がライブ動画の配信を停止するためのオブジェクトである。当該配信停止ボタン76が配信者によって選択されると、ライブ動画の配信(配信者端末30からサーバ10へのライブ動画の送信)が停止される。
図8は、視聴者端末30において表示される視聴者用画面80を例示する。例えば、トップ画面60の一覧表示領域64を介して任意のライブ動画が視聴者によって選択されると、選択されたライブ動画を視聴するための視聴者用画面80が視聴者端末30において表示される。当該画面80は、図示するように、上述した配信者用画面70と同様に、動画表示領域81と、基本情報表示領域82と、フィーバーゲージ83と、アイテム情報表示領域84と、アクション情報表示領域85とを有する。また、視聴者用画面80は、画面下端部において、コメント入力領域86と、ハートマークが表示された「いいね」ボタン87と、プレゼントの図柄が表示されたアイテム入力ボタン88とを有する。
コメント入力領域86は、視聴者がコメントを入力するための領域である。当該領域86を介して視聴者がコメントを入力すると、入力されたコメントに対応するアクションオブジェクトAOが、配信者端末30の配信者用画面70及び各視聴者端末30の視聴者用画面80のアクション情報表示領域75、85に追加される。コメントに対応するアクションオブジェクトAOには、当該コメントを入力した視聴者のアカウント名と共に、コメント自体(テキスト)とが表示される。また、コメントが入力されると、配信情報テーブル412のコメント数が更新(1加算)される。
いいねボタン87は、視聴者が配信者に対して「いいね」を入力するためのオブジェクトである。当該ボタン87が視聴者によって選択されると、「いいね」の入力が行われ、「いいね」に対応するアクションオブジェクトAOが、アクション情報表示領域75、85に追加される。「いいね」に対応するアクションオブジェクトAOには、「いいね」を入力した視聴者のアカウント名と共に、「いいね」が行われたことを示すテキストが表示される。また、「いいね」が入力されると、所定の視覚効果(例えば、ハート型のオブジェクトが画面下側から上側に向かって流れるように表示されるアニメーション効果等)が動画表示領域71、81に付加される。また、「いいね」が入力されると、配信情報テーブル412の「いいね数」が更新(1加算)される。
アイテム入力ボタン88は、視聴者がアイテムを入力するためのオブジェクトである。当該ボタン88が視聴者によって選択されると、図9に例示するアイテム選択画面90が視聴者用画面80に重ねて表示される。当該画面90は、図示するように、各々がアイテムに関する情報を表示する複数の個別表示領域92を一覧表示する。個別表示領域92は、アイテムに対応する画像、及び、当該アイテムの入力に必要なコイン数を表示する。
この例では、視聴者によって入力可能な複数のアイテムが予め定められており、各アイテムには、その価格(価値)としてコイン数が予め設定されている。アイテム選択画面90は、当該入力可能な複数のアイテムを一覧表示する。視聴者によってアイテム選択画面90を介して何れかのアイテムが選択されると、選択されたアイテムの入力が行われる。
ここで、アイテムの入力に関係する処理について詳述する。図10は、この例のサーバ10が実行する、視聴者によるアイテムの入力に関係する処理を例示するフロー図である。サーバ10は、図示するように、ライブ動画の配信中において(ステップS100においてNO)、アイテムの入力を待機し(ステップS115においてNO)、当該待機中にコンボをクリアするためのコンボクリア条件を充足すると(ステップS105においてYES)、これまでのコンボをクリアする(ステップS110)。コンボのクリアについては後述する。
アイテムの入力の待機中において、何れかの視聴者によってアイテムが入力されると(ステップS115においてYES)、サーバ10は、対応するアクションオブジェクトを表示する(ステップS120)。具体的には、配信者用画面70及び視聴者用画面80のアクション情報表示領域75、85において、アイテムの入力に対応するアクションオブジェクトAOが追加される。アイテムの入力に対応するアクションオブジェクトAOには、当該アイテムを入力した視聴者のアカウント名と共に、入力されたアイテムの名称とが表示される。
続いて、サーバ10は、この配信のアイテムポイントを更新する(ステップS123)。具体的には、入力されたアイテムのコイン数に応じたアイテムポイント(例えば、コイン数が多くなるほどポイントも多くなる。)がこの配信に対して付与され、配信情報テーブル412において、対応する配信のアイテムポイントに加算される。
次に、サーバ10は、アイテムを入力した視聴者のコイン保有数を更新する(ステップS125)。具体的には、入力されたアイテムのコイン数が、ユーザ情報テーブル411において、対応するユーザ(アイテムを入力した視聴者)のコイン保有数から減じられる。
そして、サーバ10は、当該アイテムの入力が、コンボ条件を充足するか否かを判定する(ステップS130)。この例におけるコンボ条件は、以下の5つの必要条件によって構成されている。つまり、以下の5つの条件の全てを充足すると、コンボ条件を充足する。
(1)前回のコンボ(前回のコンボが存在しない場合は、前回のアイテムの入力)からの経過時間が30秒以内であること
(2)今回入力されたアイテムのコイン数が、前回のコンボ(前回のコンボが存在しない場合は、前回のアイテムの入力)において入力されたアイテムのコイン数以上であること
(3)今回のアイテムを入力した視聴者が、前回までの(連鎖中の)コンボにおいて未だアイテムを入力していないこと(コンボの連鎖における同一の視聴者によるアイテムの入力回数が1以下であること)
(4)今回入力されたアイテムが、前回までの(連鎖中の)コンボにおいて未だ入力されていないこと(コンボの連鎖における同一のアイテムの入力回数が1以下であること)
(5)フィーバーゲージが満タンでないこと
図11は、この例におけるコンボ条件を説明するための図である。図11において、上から下方向に、アイテムの入力に応じてコンボ数が加算され、又は、加算されない様子が例示されている。なお、以下の説明では、前後するアイテムの入力の間隔は30秒以内であり(条件(1)を充足。)、また、フィーバーゲージは満タンでない(条件(5)を充足。)こととする。図示するように、まず、最初に視聴者01がアイテムA(1)(括弧内はコイン数。以下同様。)を入力したとする。この時点でのコンボ数は0である。
次に、視聴者02がアイテムB(1)を入力すると、今回入力されたアイテムBのコイン数「1」は、前回入力されたアイテムAのコイン数「1」以上であり(条件(2)を充足。)、コンボの連鎖は未だ存在していない(条件(3)、(4)を充足。)から、コンボ条件を充足する。この結果、コンボ数が「0」から1加算されて「1」となる。
続いて、視聴者03がアイテムB(1)を入力すると、今回入力されたアイテムBは、前回のコンボにおいて既に入力されているから、条件(4)を充足せず、コンボ条件を充足しない。この結果、コンボ数は「1」のまま維持される。
そして、視聴者04がアイテムC(3)を入力すると、今回入力されたアイテムCのコイン数「3」は、前回のコンボにおいて入力されたアイテムBのコイン数「1」以上であり(条件(2)を充足。)、今回のアイテムを入力した視聴者04は、前回までのコンボにおいてアイテムを入力しておらず(条件(3)を充足。)、且つ、今回入力されたアイテムCは、前回までのコンボにおいて入力されていない(条件(4)を充足。)から、コンボ条件を充足する。この結果、コンボ数が「1」から1加算されて「2」となる。
続いて、視聴者05がアイテムD(1)を入力すると、今回入力されたアイテムDのコイン数「1」は、前回のコンボにおいて入力されたアイテムCのコイン数「3」未満であるから、条件(2)を充足せず、コンボ条件を充足しない。この結果、コンボ数は「2」のまま維持される。
そして、視聴者06がアイテムE(3)を入力すると、今回入力されたアイテムEのコイン数「3」は、前回のコンボにおいて入力されたアイテムCのコイン数「3」以上であり(条件(2)を充足。)、今回のアイテムを入力した視聴者06は、前回までのコンボにおいてアイテムを入力しておらず(条件(3)を充足。)、且つ、今回入力されたアイテムEは、前回までのコンボにおいて入力されていない(条件(4)を充足。)から、コンボ条件を充足する。この結果、コンボ数が「2」から1加算されて「3」となる。
続いて、視聴者02がアイテムF(5)を入力すると、今回のアイテムを入力した視聴者02は、前回までのコンボにおいて既にアイテムを入力している(初回のコンボにおいてアイテムBを入力している。)から、条件(3)を充足せず、コンボ条件を充足しない。この結果、コンボ数は「3」のまま維持される。
そして、視聴者05がアイテムF(5)を入力すると、今回入力されたアイテムFのコイン数「5」は、前回のコンボにおいて入力されたアイテムEのコイン数「3」以上であり(条件(2)を充足。)、今回のアイテムを入力した視聴者05は、前回までのコンボにおいてアイテムを入力しておらず(条件(3)を充足。)、且つ、今回入力されたアイテムFは、前回までのコンボにおいて入力されていない(条件(4)を充足。)から、コンボ条件を充足する。この結果、コンボ数が「3」から1加算されて「4」となる。
図10のフロー図に戻り、サーバ10は、今回のアイテムの入力が、コンボ条件を充足する判定されない場合には(ステップS130においてNO)、通常用アイテムオブジェクトを表示する一方(ステップS135)、今回のアイテムの入力が、コンボ条件を充足する判定される場合には(ステップS130においてYES)、コンボ用アイテムオブジェクトを表示する(ステップS140)。図12は、アイテム情報表示領域84においてアイテムオブジェクトIOが表示されている視聴者用画面80を例示する。なお、同様に、配信者用画面70のアイテム情報表示領域74においてもアイテムオブジェクトIOが表示される。アイテムオブジェクトIOは、アイテム情報表示領域74、84における表示後、所定の時間が経過すると消える。なお、アイテムオブジェクトIOの表示又は消滅に伴って、入力されたアイテムに対応する所定の視覚効果が動画表示領域71、81に付加されるようにしても良い。
この例では、アイテムの入力がコンボ条件を充足しない場合の通常用アイテムオブジェクト、及び、アイテムの入力がコンボ条件を充足する場合のコンボ用アイテムオブジェクトは、相互に外観が異なっている。図13(A)は、通常用アイテムオブジェクトIO1を例示し、図13(B)は、コンボ用アイテムオブジェクトIO2を例示する。通常用アイテムオブジェクトIO1は、図示するように、角丸長方形の輪郭を有しており、左側に、アイテムを入力した視聴者のプロフィール画像を表示する円形の視聴者画像表示領域IO11を有する。また、通常用アイテムオブジェクトIO1には、視聴者のアカウント名、並びに、入力されたアイテムの名称及び画像が表示される。一方、コンボ用アイテムオブジェクトIO2は、図示するように、通常の(角丸でない)長方形の輪郭を有しており、左側に、アイテムを入力した視聴者のプロフィール画像を表示する台形の視聴者画像表示領域IO21を有する。また、コンボ用アイテムオブジェクトIO2には、視聴者のアカウント名、並びに、入力されたアイテムの名称及び画像に加えて、コンボ数が表示されている(図13(B)の例では「5 combo」と表示されている。)。
図10のフロー図に戻り、サーバ10は、アイテムの入力がコンボ条件を充足しない場合には、通常用アイテムオブジェクトを表示した後に、ステップS100へと戻り、再度、アイテムの入力を待機する。
一方、アイテムの入力がコンボ条件を充足する場合には、コンボ用アイテムオブジェクトを表示した後に、サーバ10は、コンボ情報及びフィーバーゲージ値を更新する(ステップS145)。具体的には、配信情報テーブル412において、対応する配信のコンボ情報(コンボ数及びコンボ履歴)及びフィーバーゲージ値が更新される。コンボ情報の更新では、コンボ数が1加算されると共に、コンボ履歴に今回のアイテムの入力に関する情報(視聴者及びアイテムの組合せ)が追加される。また、フィーバーゲージ値の更新では、今回入力されたアイテムのコイン数と更新後のコンボ数とに基づいて設定される加算値がフィーバーゲージ値に加算される。当該加算値は、コイン数及びコンボ数が多いほど、大きな値となる。フィーバーゲージ値が更新されると、配信者用画面70及び視聴者用画面80のフィーバーゲージ73、83の表示もまた更新される。
そして、更新後のフィーバーゲージが満タンでない(フィーバーゲージ値が最大値に到達していない。)場合には(ステップS150においてNO)、サーバ10は、ステップS100へと戻り、再度、アイテムの入力を待機する。
上述したように、アイテムの入力を待機している期間において、コンボクリア条件を充足する場合には(ステップS105においてYES)、コンボをクリアする(ステップS110)。ここで、コンボのクリアについて説明する。この例におけるコンボクリア条件は、以下の何れかの条件が成立することである。
(1)前回のコンボからの経過時間が30秒に到達すること
(2)フィーバーゲージが満タンになること
これらの何れかの条件が成立すると、コンボのクリアが行われ、具体的には、配信情報テーブル412において、対応する配信のコンボ情報(コンボ数及びコンボ履歴)がクリア(初期化)される。つまり、この例における連鎖可能期間は「前回のコンボから30秒以内」であると言える。
一方、コンボの発生及び連鎖が繰り返された結果、フィーバーゲージが満タンになる(フィーバーゲージ値が最大値に到達する。)と(ステップS150においてYES)、サーバ10は、配信者端末30においてフィーバータイム指示画面を表示し(ステップS155)、ステップS100へと戻り、再度、アイテムの入力を待機する。
図14は、配信者端末30において表示されるフィーバータイム指示画面110を例示する。当該画面110は、図示するように、配信者用画面70に重ねて表示され、「FEVER START」と表示された円形のフィーバータイムボタン112と、「後でやる」と表示された保留ボタン114とを有する。配信者がフィーバータイムボタン112を選択すると、フィーバータイムが開始される。
フィーバータイムが開始されると、所定の視覚効果(例えば、「FEVER」という文字列が踊るように表示されるアニメーション効果等)が、配信者用画面70及び視聴者用画面80の動画表示領域71、81に付加される。また、フィーバータイムにおいては、各視聴者によるコメント、いいね、及び、アイテムの入力に応じて、フィーバースコアが加算される。フィーバースコアは、上述したように、配信情報テーブル412において管理されている。なお、フィーバータイムにおいて、各視聴者によるコメント、いいね、及び、アイテムの入力に応じたコメント数、いいね数、及びアイテムポイントの更新もまた、継続して行われる。つまり、フィーバータイムは、コメント数、いいね数、及びアイテムポイントの加算に加えて、フィーバースコアが加算されるモードであると言える。なお、フィーバータイムにおいて、アイテム選択画面90を介して入力可能な通常用のアイテムに代えて、又は、これに加えて、フィーバータイム用のアイテムの入力が可能となるようにしても良い。
この例において、フィーバータイムは、開始してからの経過時間が所定の時間(例えば、60秒)に到達すると終了する。フィーバータイムの終了に応じて、フィーバーゲージ値及びコンボがクリア(初期化)される。そして、その後、フィーバーゲージが再び満タンとなると、再度、フィーバータイム指示画面110が表示されて、フィーバータイムの開始が可能となる。なお、フィーバーゲージが満タンになる都度、次のフィーバーゲージを満タンとすることの難易度を上げる(例えば、フィーバーゲージ値の最大値を増加させる。)ようにしても良い。また、配信者毎に、単位期間(例えば、1日)においてフィーバーゲージを満タンにする回数に制限を設ける(つまり、フィーバータイムの回数を制限する。)ようにしても良い。
この例では、配信者がフィーバータイム指示画面110の保留ボタン114を選択すると、フィーバータイムの開始が保留される。当該保留期間において、視聴者によるアイテムの入力は可能であるが、フィーバーゲージが満タンであるため(上述した条件(5)を充足しないから)コンボ条件は充足しない(コンボは発生しない。)。配信者は、当該保留期間において、所望のタイミング(例えば、有力な視聴者が視聴を開始したタイミング等)で、フィーバータイムの開始を指示することができる。
上述したように、配信者が、配信者用画面70の配信停止ボタン76を選択すると、ライブ動画の配信が終了する。ライブ動画の配信が終了すると、サーバ10は、当該配信に対する配信ポイントを設定する。この例では、視聴者数(最大値)、いいね数、コメント数、及び、アイテムポイントに基づいて基本ポイントが算出され、当該基本ポイントに対して、フィーバータイムにおけるフィーバースコアが加算されて配信ポイントとなる。基本ポイントは、視聴者数(最大値)、いいね数、コメント数、及び、アイテムポイントが多いほど、多くなるように構成されている。算出された基本ポイント及び配信ポイントは、配信情報テーブル412において登録される。
なお、ライブ動画の配信が終了しても、ユーザ情報テーブル411において管理されているフィーバーゲージ値は維持される。つまり、この例では、フィーバーゲージ値(フィーバーゲージの状態)は、次回の配信に持ち越される。なお、所定のタイミング(例えば、毎日深夜等)で、フィーバーゲージ値(フィーバーゲージの状態)をクリア(初期化)するようにしても良い。
また、この例では、ユーザが前日に獲得した配信ポイントに基づいて当日のランクが決定(更新)される。図15は、各ユーザのランクを更新する際にサーバ10が実行する処理を例示するフロー図である。これらの処理は、毎日深夜(例えば、毎日午前3時)に実行される。
サーバ10は、まず、図示するように、各ユーザのランクメータ値を更新する(ステップS300)。図16は、ランクメータ値の更新ルールを説明するための図である。図示するように、この例では、ユーザが前日に獲得した配信ポイントの当該ユーザが属するランク帯内での順位に基づいてランクメータ値が変動する。特定のユーザが前日に獲得した配信ポイントは、配信情報テーブル412の配信者ユーザアカウント、配信日時、及び、配信ポイントを参照することによって算出される。なお、ユーザが1日に複数の配信を行っている場合、複数の配信でそれぞれ獲得した配信ポイントが合算される。
ランクメータ値の更新ルールは、具体的には、図16に示すように、まず、ランク帯内の配信ポイントの順位が上位10%に含まれる場合には、ランクメータ値の変動は「+2」(2ポイント増加)である。同様に、当該順位が上位11~30%(上位30%から上位10%を除いた残りの20%)に含まれる場合の変動は「+1」であり、当該順位が中位30%(上位31~60%)に含まれる場合の変動は「±0」(増減なし)であり、当該順位が下位40%に含まれる場合の変動は「-1」(1ポイント減少)である。なお、前日の配信が行われなかった場合には、ランク帯内の順位にかかわらず、ランクメータ値の変動は「-1」となる。
ステップS300では、図16に例示される更新ルールに従って、各ユーザのランクメータ値が更新される。なお、ランクメータ値がマイナスであるユーザであって、今回のランクメータ値の変動が増加(具体的には、+2、又は、+1)である場合、ランクメータ値を0にクリアした上で増加させるようにしても良い。つまり、例えば、ランクメータ値の現在値が「-1」であるユーザの今回の変動が「+2」である場合、ランクメータ値を0にクリアした後に2増加させ、変動後のランクメータ値は(「+1」ではなく)「+2」となる。こうすれば、ランクメータ値がマイナスであるユーザ(例えば、配信頻度が低いユーザ等)であっても当該ランクメータ値を一気に増加させることができるから、ライブ動画の配信が促進される。
各ユーザのランクメータ値を更新すると、次に、サーバ10は、更新後のランクメータ値に基づいてランクを更新する(ステップS310)。図17は、ランクの更新内容と必要なランクメータ値との対応関係を説明するための図である。図示するように、まず、ランク帯をまたいでランクアップする場合(言い換えると、各ランク帯内の最上位のランクからランクアップする場合)に必要なランクメータ値は+4である。つまり、各ランク帯内の最上位のランク(例えば、A+)に属するユーザは、ランクメータ値が+4になると、直上のランク帯内の最下位のランク(例えば、S-)にランクアップする。また、同一のランク帯内でランクアップする場合(言い換えると、各ランク帯内の中位又は最下位のランクからランクアップする場合)に必要なランクメータ値は+2である。つまり、各ランク帯内の中位又は最下位のランク(例えば、B又はB-)に属するユーザは、ランクメータ値が+2になると、同一のランク帯内の直上のランク(例えば、B+又はB)にランクアップする。
同様に、図17に例示するように、同一のランク帯内でランクダウンする場合(言い換えると、各ランク帯内の最上位又は中位のランクからランクダウンする場合)に必要なランクメータ値は-2である。つまり、各ランク帯内の最上位又は中位のランク(例えば、B+又はB)に属するユーザは、ランクメータ値が-2になると、同一のランク帯内の直下のランク(例えば、B又はB-)にランクダウンする。また、ランク帯をまたいでランクダウンする場合に必要なランクメータ値は-6である。つまり、各ランク帯内の最下位のランク(例えば、A-)に属するユーザは、ランクメータ値が-6になると、直下のランク帯の最上位のランク(例えば、B+)にランクダウンする。このように、この例では、ランク帯をまたいだランクアップ/ダウンは、同一のランク帯内でのランクアップ/ダウンと比較して、必要なランクメータ値の絶対値が大きくなっている。この結果、短期間での急激なランクアップ/ダウンが抑制される。
ステップS310においては、図17に例示した対応関係に従って、ランクメータ値に基づくランクの更新が行われる。なお、ランクの更新が行われたユーザ(ランクアップ/ダウンが発生したユーザ)のランクメータ値は0にクリアされる。
図18は、ユーザのランクメータ値を表示するランクメータオブジェクト100を例示する。当該オブジェクト100は、例えば、ユーザの基本情報を表示するプロフィール画面等において配置される。ランクメータオブジェクト100は、図示するように、針型の形状を有する針オブジェクト102と、下方に開口するアルファベットのC型の形状を有するスケールオブジェクト104とを有する。針オブジェクト102の下方にはユーザの現在のランク(図18の例では「Aランク」)が表示されている。針オブジェクト102は、ランクメータ値が増加すると右方向に振れ(回転し)、ランクメータ値が減少すると左方向に振れるように構成されている。図18における針オブジェクト102は直立している状態であり(12時の方向を指しており)、ランクメータ値が0である状態に対応している。また、針オブジェクト102は、ランクメータ値が正の方向に大きくなるほど右方向に傾斜する一方、負の方向に小さくなるほど左方向に傾斜する。そして、スケールオブジェクト104の右下側には、ランクアップに必要なランクメータ値に対応するランクアップ領域1041が設定されており、同じくスケールオブジェクト104の左下側には、ランクダウンに必要なランクメータ値に対応するランクダウン領域1042が設定されている。ユーザは、当該ランクメータオブジェクト100を介して、ランクアップ/ダウンに向けたランクメータ値の現在の状況を把握することができる。
また、この例では、前日の配信時間とランク(前日におけるランク)とに基づいて配信者としてのユーザに対する報酬であるダイヤが付与される。図19は、各配信者にダイヤを付与する際にサーバ10が実行する処理を例示するフロー図である。これらの処理は、毎日深夜に実行され、例えば、図15に例示した各ユーザのランクを更新する際に実行され処理よりも前の時刻(例えば、毎日午前0時)に実行される。
サーバ10は、まず、図示するように、各ユーザの前日の配信時間を算出する(ステップS400)。特定のユーザの前日の配信時間は、具体的には、配信情報テーブル412の配信者ユーザアカウント、及び、配信日時を参照することによって算出される。ユーザが1日に複数の配信を行っている場合、複数の配信の各々の配信時間が合算される。
続いて、サーバ10は、算出した配信時間及び基準ダイヤ数に基づく数のダイヤを各ユーザに付与する(ステップS410)。具体的には、算出した配信時間に基準ダイヤ数を乗じた数のダイヤが各ユーザに付与される。基準ダイヤ数は、ランクが上位であるほど多くなるように、ランク毎に予め設定されており、各ユーザの前日のランクに対応する基準ダイヤ数が適用される。ユーザに対してダイヤが付与されると、ユーザ情報テーブル411のダイヤ保有数が更新される。この例では、ダイヤは、コイン又は現実の通貨に交換することができる。
上述した例では、コンボの発生又は連鎖に応じてフィーバーゲージ値を加算し、フィーバーゲージが満タンになるとフィーバータイムの開始が可能となり、当該フィーバータイムにおけるフィーバースコアが配信ポイントに加算されるようにしたが、こうした設計は例示であって、本実施形態の他の例では、その他の設計が適用され得る。例えば、当該他の例では、コンボの発生又は連鎖に応じて配信ポイントが直接加算され得る。また、本実施形態のさらに他の例において、コンボの発生に応じて配信者に対して付与される価値・利益は、フィーバーゲージ値及び配信ポイントに限定されず、例えば、コイン及びダイヤ等であっても良い。
以上説明した本実施形態の動画配信サーバ10は、ライブ動画の複数の視聴者の各々によるアイテムの入力が所定のコンボ条件を充足すると判定される場合にコンボを発生させるから、ライブ動画の視聴者間のコミュニケーションを活性化させることができ、さらに、こうしたコンボの発生に応じて第1の価値(例えば、フィーバーゲージ値)を配信者に付与するから、当該ライブ動画の配信者と視聴者との間の繋がりを強化することができる。
本明細書で説明された処理及び手順は、明示的に説明されたもの以外にも、ソフトウェア、ハードウェアまたはこれらの任意の組み合わせによって実現される。例えば、本明細書で説明される処理及び手順は、集積回路、揮発性メモリ、不揮発性メモリ、磁気ディスク等の媒体に、当該処理及び手順に相当するロジックを実装することによって実現される。また、本明細書で説明された処理及び手順は、当該処理・手順に相当するコンピュータプログラムとして実装し、各種のコンピュータに実行させることが可能である。
本明細書中で説明された処理及び手順が単一の装置、ソフトウェア、コンポーネント、モジュールによって実行される旨が説明されたとしても、そのような処理または手順は複数の装置、複数のソフトウェア、複数のコンポーネント、及び/又は複数のモジュールによって実行され得る。また、本明細書において説明されたソフトウェアおよびハードウェアの要素は、それらをより少ない構成要素に統合して、またはより多い構成要素に分解することによって実現することも可能である。
本明細書において、発明の構成要素が単数もしくは複数のいずれか一方として説明された場合、又は、単数もしくは複数のいずれとも限定せずに説明された場合であっても、文脈上別に解すべき場合を除き、当該構成要素は単数又は複数のいずれであってもよい。