JP2019166300A

JP2019166300A - サーバおよびプログラム

Info

Publication number: JP2019166300A
Application number: JP2018141288A
Authority: JP
Inventors: 量生川上; Kazuo Kawakami; 樹青柞山; Tao Sakuyama; 裕司千野; Yuji Chino
Original assignee: Dwango Co Ltd
Current assignee: Dwango Co Ltd
Priority date: 2018-07-27
Filing date: 2018-07-27
Publication date: 2019-10-03

Abstract

【課題】リアルタイムコンテンツの配信サービスの利用に対する観客のモチベーションの低下を抑制する。【解決手段】本発明の一態様によれば、サーバは、受信部と、メッセージ生成部と、送信部とを含む。受信部は、リアルタイムコンテンツの観客の端末から、リアルタイムコンテンツに関わる複数の要素をグループ化した複数のグループのいずれかを指定する投票を受信する。メッセージ生成部は、複数のグループの１つである第１のグループへの投票の継続が不可能となったことを検知した場合に、当該第１のグループを投票先とする観客の端末の画面に、第１のグループ以外のグループのいずれかへの投票を促す第１のメッセージを表示するための第１のメッセージデータを生成する。送信部は、第１のメッセージデータを第１のグループを投票先とする観客の端末へ送信する。【選択図】図３

Description

本発明は、リアルタイムコンテンツの配信システムに適用可能な補助機能に関する。

ビデオゲームは、スタンドアローン（ＳｔａｎｄＡｌｏｎｅ）型、またはオンラインゲーム（例えば、クラウドゲーム、ＭＯ（ＭｕｌｔｉｐｌａｙｅｒＯｎｌｉｎｅ）ゲーム、ＭＭＯ（ＭａｓｓｉｖｅｌｙＭｕｌｔｉｐｌａｙｅｒＯｎｌｉｎｅ）ゲーム）に大別することができる。また、オンラインゲームは、Ｃ／Ｓ（Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ）型およびＰ２Ｐ（ＰｅｅｒｔｏＰｅｅｒ）型にさらに分類することができる。スタンドアローン型のゲームおよびＰ２Ｐ型のオンラインゲームは、プレイヤの端末がゲームプログラムを実行することで実現され、１人ないし高々数十人程度のプレイヤがプレイする。他方、特にＣ／Ｓ型では、プレイヤの端末に接続されたゲームサーバがゲームプログラムの一部（サーバサイドプログラム）を実行することで実現され、ＭＭＯ型のゲームでは数百人から数百万人ものプレイヤがネットワークに同時接続してプレイすることができる。

ビデオゲームの基本的な仕組みは、プレイヤが、ゲームプログラムの出力であるゲーム画面、音声、振動などを認知し、これに基づいて判断を行って操作を入力し、ゲームプログラムがその操作に基づいてゲーム状態を遷移させてさらなる出力を生成する、というプレイヤ−ゲームプログラム間のやり取りの繰り返しである。

近年、動画共有システムでは、ゲーム実況生放送と呼ばれるジャンルの動画が台頭しつつある。ゲーム実況生放送とは、プレイヤ（配信者）が、ゲームをリアルタイムにプレイする様子を、多数の観客へ生放送（配信）する形態のコンテンツ共有法である。ゲーム実況生放送によれば、プレイヤ以外の観客も、ゲームを擬似的に体験して楽しむことができる。

例えば、ゲームの１ジャンルである戦国シミュレーションゲームは、プレイヤがいずれかの国の大名またはその家臣として意思決定を行い、他の国と合戦や同盟を結ぶなどして領土拡大を目指す、というものが多い。このようなゲームのリアルタイムプレイ動画の観客は、動画の視聴中に（或いは視聴前から）特定のキャラクタ、例えば、大名、武将、家臣などに愛着を抱くことがあり、その場合にはお気に入りのキャラクタの活躍を期待して、プレイ動画を能動的／継続的に視聴する可能性がある。

また、特許文献１には、複数のキャラクタがレースを行い、着順を競うレースゲームにおいて（［０００１］）、レースに登場する複数のキャラクタについて、所定数で組み合わせたチームを形成し、チームに対してベットできるようにすること（［００２０］）が記載されている。さらに、特許文献１には、レースの結果に基づいてチームごとのポイントを計算し（［００２１］）、レースに出走したキャラクタの着順に基づいてチーム順位を決定すること（［００５３］）、も記載されている。かかるレースゲームにおいて、プレイヤがチームにベットした場合に当該チームの活躍を願うことはあり得る。ただし、特許文献１によれば、チームはおろか出走するキャラクタすらもレース毎に再編される（図１、Ｓ１０１）ため、プレイヤが自らベットしたチームの活躍を願うのはそのレース限りであるといえる。

さらに、一部の動画共有システムでは、生放送の動画に対して観客がコメントを付けることができる。ゲーム実況生放送において、観客が付けたコメントは、他の観客に加えて配信者もリアルタイムに閲覧することができる。配信者が観客からの助言コメントまたはリクエストコメントに応じたプレイをし、観客がさらにコメントを付けるなどして、双方向的なゲーム体験を生み出すことができる。

また、特許文献２には、ゲームプレイ動画の閲覧中に入力されたコメントを取得・集計し、演出方法を選択すること［００１１］が開示されている。ただし、特許文献２では、エフェクト、背景素材、及び画面装飾の異なる演出方法が定められているが、何れの演出方法も、ゲームプレイの内容そのものが変わるわけではなく、見た目が変わるだけである、とされている（［００８５］、［図１８］）。

特開２００９−２１３８２７号公報特開２０１６−１８９８０４号公報

観客がゲームのリアルタイムプレイ動画において自己のお気に入りのキャラクタに活躍してもらうために採ることのできる手段は限られる。コメント投稿可能な動画共有システムでは、プレイヤである配信者はコメントを考慮に入れてプレイをするかもしれないが、コメント投稿自体がゲームに対して直接的な影響を及ぼすわけではない。例えば、観客がいくらコメントを付けようとも配信者がこれを見落としたり無視したりすれば、観客のコメントはゲームの進行に影響を与えない。このように従来の、ゲームのリアルタイムプレイ動画では、ゲームの進行に直接的に関与できるのはプレイヤである配信者のみであるから、配信者の意思と無関係に観客の意思がゲームの進行に影響を与えることはない。

また、観客が特定のキャラクタに愛着を抱くことで、動画の能動的／継続的な視聴が見込める反面、当該キャラクタが死亡などによりゲームから離脱した時に観客の視聴意欲が低下して以降の視聴をやめてしまうおそれもある。すなわち、観客のお気に入りのキャラクタがゲームのリアルタイムプレイ動画に存在していることが、そのまま当該観客が当該動画を視聴、すなわち当該動画の配信サービスを利用する主要なモチベーションとなりがちである。

また、ゲームのリアルタイムプレイ動画に限らずリアルタイムコンテンツ全般についても類似の問題がある。具体的には、観客が特定の配信者に愛着を抱くことで、当該配信者がリアルタイムコンテンツの配信を開始した時に観客がこれを例えばお知らせ機能などにより認知して当該コンテンツの視聴を開始することを期待できる反面、当該コンテンツの配信が終了すると観客も当該コンテンツの配信サービスの利用をやめがちである。すなわち、観客のお気に入りの配信者がリアルタイムコンテンツを配信中であることが、そのまま当該観客が当該コンテンツの配信サービスを利用する主要なモチベーションとなりがちである。

本発明は、リアルタイムコンテンツの配信サービスの利用に対する観客のモチベーションの低下を抑制することを目的とする。

本発明の一態様によれば、サーバは、受信部と、算出部と、作成部と、メッセージ生成部と、送信部とを含む。受信部は、リアルタイムコンテンツの観客の端末から、リアルタイムコンテンツに関わる複数の要素をグループ化した複数のグループのいずれかを指定する投票を受信する。算出部は、複数のグループの各々について当該グループに所属する要素のパラメータに基づいて当該グループの指標を算出する。作成部は、指標についての複数のグループの順位を示すランキングデータを作成する。メッセージ生成部は、複数のグループの１つである第１のグループへの投票の継続が不可能となったことを検知した場合に、当該第１のグループを投票先とする観客の端末の画面に、第１のグループ以外のグループのいずれかへの投票を促す第１のメッセージを表示するための第１のメッセージデータを生成する。送信部は、第１のメッセージデータを第１のグループを投票先とする観客の端末へ送信する。

本発明によれば、観客のリアルタイムコンテンツに対する視聴意欲の低下を抑制することができる。

実施形態に係る補助サーバを含む、ゲームのリアルタイムプレイ動画の配信システムの一例を示すブロック図。図１の変形例を示す図。図１中の補助サーバを例示するブロック図。図３の補助サーバの単位期間中の動作の概念図。投票可能期間に観客端末の画面に表示されるメッセージを例示する図。観客端末に表示される投票メニュー画面を例示する図。ランキングの発表準備が完了した後に観客端末の画面に表示されるメッセージを例示する図。観客端末に表示されるランキング発表画面を例示する図。投票していたグループへの投票の継続が不可能となった時に観客端末の画面に表示されるメッセージを例示する図。新たなグループがゲームに追加された時に観客端末の画面に表示されるメッセージを例示する図。図３の補助サーバの動作を例示するフローチャート。

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

（実施形態）
実施形態に係る補助サーバは、図１に例示される、ゲームのリアルタイムプレイ動画の配信システムに組み込むことができる。この配信システムは、配信者端末１００と、動画配信サーバ２００と、観客端末３００−１，３００−２，・・と、補助サーバ４００と、ゲームサーバ５００とを含む。

図１の例では、動画配信サーバ２００は、配信者端末１００（クライアント）およびゲームサーバ５００（サーバ）において実行されるＣ／Ｓ型のオンラインゲームのリアルタイムプレイ動画を、観客端末３００（および配信者端末１００）へ配信する。

ここで、ゲームは、前述の戦国シミュレーションゲーム、スポーツゲーム、などであってもよいし、例えば人工生命体またはその他のキャラクタの育成ゲームであってもよい。この人工生命体の育成ゲームにおいて、プレイヤは、人工生命体をフィールドと呼ばれる仮想世界に移し、その生態や当該人工生命体が群れ（一族）を形成して他の群れと共存する様子などを鑑賞して楽しむことができる。プレイヤは、自己の所有する人工生命体の死亡やその所属する一族の滅亡を防ぐため、その一族を有利にするため、などの目的で、人工生命体のエネルギーを補充するためのアイテム（フード）やその他の効果のあるオブジェクトをフィールドに投下することができる。

図１のシステムにおいて、プレイヤである配信者だけでなく、観客も補助サーバ４００を利用してこのような介入を実施して、プレイヤ（配信者）と一緒に好みの人工生命体やその所属する一族をサポートしたり、逆に敵対勢力の活動を邪魔したりすることができるようにしてもよい。

いずれにせよ、ゲームは、複数のキャラクタが併存可能であって、かつ、それぞれのキャラクタが複数のグループの少なくとも１つに所属可能である仮想空間を舞台とするものとする。キャラクタとは、例えば、人工生命体、選手、武将、家臣、などゲームにより様々に定義され得る。グループとは、キャラクタをグループ化し、例えば、群れ、一族、チーム、国、などゲームにより様々に定義され得る。

キャラクタは、所定の条件を満たすことでゲームから離脱し得る。キャラクタのゲームからの離脱とは、一例としてキャラクタが当該ゲームに永続的または半永続的に登場しなくなることを指し、死亡、消滅、逃亡、移籍、引退、などゲームにより様々に定義され得る。また、グループに所属する全てのキャラクタがゲームから離脱した場合には、当該グループもゲームから離脱すると定義されてよい。

同様に、キャラクタは、所定の条件を満たすことでゲームに新たに追加され得る。キャラクタのゲームへの追加は、誕生、出現、移籍、加入、などゲームにより様々に定義され得る。キャラクタは、ゲームに追加されると同時に、または追加後に所定の条件が満足した場合に、いずれかのグループの要素として加えられてよい。

また、グループは、ゲーム内のルールにより、例えばキャラクタの血縁や出生地などから自動的に決定されてもよいし、ランダムに決定されてもよい。或いは、配信者を含むプレイヤおよび／または観客に、編集する権限が与えられてもよい。プレイヤおよび／または観客によるグループの編集は、たとえば、ゲームへの新たなグループの追加、ゲーム中の既存グループの削除、または当該既存グループに所属するキャラクタの編集（追加、変更もしくは削除）、などの一部または全部を含み得る。

配信者端末１００は、ゲームプログラム（クライアントサイドプログラム）を実行する。配信者端末１００は、ゲームサーバ５００からゲームプログラム（サーバサイドプログラム）の実行結果を受信し、ゲーム画面／音声（振動、またはその他のフィードバックを含み得る）を出力し、プレイヤとしての配信者はこの出力を認知する。ここで、ゲームプログラムの実行結果とは、例えば、ゲーム画面／音声（のエンコード済みデータ）そのものであってもよいし、ゲーム状態のようなゲーム画面／音声を生成するために必要なデータであってもよい。例えば、クラウドゲームでは、ゲーム画面／音声そのものが配信者端末１００へ伝送され得る。

後者の例では、配信者端末１００は、ゲーム画面の描画および出力音声を決定するために、ゲームの素材データ、例えば、オブジェクト（具体的には、キャラクタ、アイテム、背景、ビジュアルエフェクト（ｖｉｓｕａｌｅｆｆｅｃｔ）、など）の画像データ、効果音（ＳＥ：ＳｏｕｎｄＥｆｆｅｃｔ）、ＢＧＭ(ｂａｃｋｇｒｏｕｎｄｍｕｓｉｃ)、キャラクターボイス（ＣｈａｒａｃｔｅｒＶｏｉｃｅ）、などの音声データ、振動パターン、などを主記憶または補助記憶装置に保存しておく必要がある。

プレイヤは、配信者端末１００からの出力を認知し、これに基づいて操作を当該配信者端末１００へ入力する。配信者端末１００はプレイヤの操作データをゲームサーバ５００へ送信する。さらに、配信者端末１００は、逐次、ゲーム画面／音声、そして必要があれば付加的な画像／音声をエンコードし、エンコード済みデータを動画配信サーバ２００へ送信（アップロード）する。ここで、付加的な画像／音声は、例えば、配信者を撮影した画像や配信者の実況音声などを含み得る。

配信者端末１００は、ゲームプログラム（クライアントサイドプログラム）が実行可能なコンピュータなどの電子デバイス、例えば、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）、モバイル端末（例えば、タブレット、スマートフォン、ラップトップ、フィーチャーフォン、ポータブルゲーム機、デジタルミュージックプレイヤー、電子書籍リーダなど）、ＶＲ（ＶｉｒｔｕａｌＲｅａｌｉｔｙ）端末、ＡＲ(ＡｕｇｍｅｎｔｅｄＲｅａｌｉｔｙ)端末、ゲーム機、テレビ受像機（インターネットテレビを含む）、などであり得るが、これらに限られない。

なお、配信者端末１００は、ゲームプログラムを実行する装置（ゲーム実行装置）と、画像／音声をエンコードし、エンコード済みのマルチメディアデータを送信する装置（エンコード・アップロード装置）とに物理的に分離されてもよい。またこの場合に、ゲーム画面／音声のデータは、ゲーム実行装置からエンコード・アップロード装置へ直接的に出力されてもよいし、されなくてもよい。後者の場合には、例えば、ゲーム実行装置に接続された表示装置の画面を撮影し、スピーカからの出力音声を録音することで、エンコード・アップロード装置はゲーム画面／音声データを取り込むことができる。

動画配信サーバ２００は、配信者端末１００および観客端末３００とネットワーク経由で接続しており、データを互いに送受信できる。動画配信サーバ２００は、逐次、配信者端末１００からエンコード済みデータを受信し、これを観客端末３００へ送信する。

観客端末３００は、ユーザからの操作入力に基づいて、後述される投票、ゲームに対する介入の実施要求などの種々の要求を発行し、補助サーバ４００へ送信する。観客端末３００は、配信者端末１００と同様の電子デバイスであり得る。ただし、観客端末３００は、ゲームプログラムを実行する能力は必要とされない。

補助サーバ４００は、観客端末３００およびゲームサーバ５００とネットワーク経由で接続している。補助サーバ４００は、観客端末３００からゲーム中の複数のグループのいずれかへの投票を受け付け、観客毎に投票先を管理する。それから、補助サーバ４００は、ゲーム中の各キャラクタのパラメータをゲームサーバ５００から収集し、当該パラメータに基づいてグループ毎の指標を算出し、この指標についての複数のグループの順位を示すランキングデータを作成する。補助サーバ４００は、このランキングデータを観客向けに発表するとともに、当該ランキングデータにおけるグループの順位に応じて、当該グループを投票先とする観客へ付与する特典を決定する。

観客は、グループへの投票行為と自らの投票したグループの順位の確認とをするうちに、ゲーム中に登場するキャラクタだけでなく、キャラクタの束であるグループにも愛着を抱くように仕向けられる。観客がグループに愛着を抱くようになれば、そうならなかった場合に比べて、観客のお気に入りのキャラクタが死亡などによりゲームを離脱した時にも観客の視聴意欲は低下しにくくなると予想される。さらに、キャラクタ単位ではなくグループ単位でランキング化をすることは、補助サーバ４００における負荷の軽減にも寄与する。

なお、例えば、補助サーバ４００は、オプションとして、介入対価（以降、対価と称する）の支払いを条件に観客によるゲームへの介入を許可し得る。ここで、対価とは、現実の財貨によって表されてもよいし、図１または図２のシステムにおいて使用可能な仮想的な財貨によって表されてもよい。

このように補助サーバ４００が観客によるゲームへの介入を許可することで、例えば、ゲームのリアルタイムプレイ動画を視聴する観客の意思の少なくとも一部が、当該ゲームの進行に影響し、ひいては当該観客の視聴するリアルタイムプレイ動画へも波及し、双方向的で一体感の高いゲーム体験を実現することができる。

投票を行った観客に付与される特典は、図１のシステムにおいて何らかのサービスと引き替え可能な仮想的な財貨、例えばポイントであってよい。さらに、特典としての仮想的な財貨は、上記対価の支払いに充当可能であってもよい。或いは、特典が、観客が何らかの介入を行う権利そのものであってもよい。このように、観客が投票行為によって獲得した特典を源泉として介入を行うことで、お気に入りのグループがゲーム中で有利となるように、或いは敵対するグループがゲーム中で不利となるように働きかけることができ、お気に入りのグループへの愛着が沸きやすくなる。

観客は、ゲームへの介入を実施したい場合には、観客端末３００の画面に表示された対価の支払いに同意のうえ当該観客端末３００を操作して実施要求を発行する。補助サーバ４００は、観客端末３００から介入の実施要求を受信すると、既定の対価と引き替えに、ゲームに対して当該介入を実施する。なお、対価の決済処理は、補助サーバ４００が行ってもよいし、補助サーバ４００とは別の決済サーバが行ってもよい。

ゲームサーバ５００は、配信者端末１００および補助サーバ４００とネットワーク経由で接続しており、互いにデータを送受信できる。ゲームサーバ５００は、ゲームプログラムを実行する。図１の例においてゲームサーバ５００は、ゲーム実行装置と呼ぶことができる。

ゲームサーバ５００は、基本的に、配信者端末１００から送信されるプレイヤの操作データに基づいて、ゲーム状態を遷移させる。また、補助サーバ４００がイベントの発生要求を送信する場合には、ゲームサーバ５００はこれにも基づいてゲーム状態を遷移させ得る。ゲームサーバ５００は、逐次、ゲームプログラムの実行結果を配信者端末１００へ送信する。

なお、図１において示される各装置の数は、例示に過ぎない。例えば、観客端末３００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、図１に示されないＷｅｂサーバ、決済サーバまたはコメント配信サーバなどがさらに設けられてもよい。

図２には、ゲームのリアルタイムプレイ動画の配信システムの別の例が示される。この配信システムは、配信者端末６００と、動画配信サーバ２００と、観客端末３００−１，３００−２，・・と、補助サーバ４００とを含む。

図２の例では、動画配信サーバ２００は、配信者端末６００において実行されるスタンドアローン型のゲームまたはＰ２Ｐ型のオンラインゲームのリアルタイムプレイ動画を、観客端末３００（および配信者端末６００）へ配信する。

図２の動画配信サーバ２００、観客端末３００および補助サーバ４００は、図１の動画配信サーバ２００、観客端末３００および補助サーバ４００と同一であり得る。ただし、図１に関する説明における「配信者端末１００」および「ゲームサーバ５００」を「配信者端末６００」に置き換える必要がある。

配信者端末６００は、ゲームプログラムを実行する。また、配信者端末６００は、ゲームの素材データをその主記憶または補助記憶装置に保存しているものとする。図２の例において配信者端末６００は、ゲーム実行装置と呼ぶことができる。

配信者端末６００は、基本的に、プレイヤからの操作を受け付け、受け付けた操作に基づいてゲーム状態を遷移させる。また、補助サーバ４００がイベントの発生要求を送信する場合には、配信者端末６００は、これにも基づいて、ゲーム状態を遷移させ得る。配信者端末６００は、逐次、ゲーム状態およびゲームの素材データに基づいて、ゲーム画面／音声を生成して出力する。

プレイヤは、配信者端末６００からの出力を認知し、これに基づいて操作を当該配信者端末６００へ入力する。配信者端末６００はプレイヤの操作を受け付けて、ゲーム状態をさらに遷移させる。さらに、配信者端末６００は、逐次、ゲーム画面／音声、そして必要があれば付加的な画像／音声をエンコードし、動画配信サーバ２００へ送信する。

配信者端末６００は、ゲームプログラムが実行可能なコンピュータなどの電子デバイス、例えば、図１の配信者端末１００と同様の電子デバイスであり得る。なお、配信者端末６００は、ゲームプログラムを実行する装置（ゲーム実行装置）と、画像／音声をエンコードし、エンコード済みのマルチメディアデータを送信する装置（エンコード・アップロード装置）とに物理的に分離されてもよい。またこの場合に、ゲーム画面／音声のデータは、ゲーム実行装置からエンコード・アップロード装置へ直接的に出力されてもよいし、されなくてもよい。後者の場合には、例えば、ゲーム実行装置に接続された表示装置の画面を撮影し、スピーカからの出力音声を録音することで、エンコード・アップロード装置はゲーム画面／音声データを取り込むことができる。

なお、図２において示される各装置の数は、例示に過ぎない。例えば、観客端末３００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、図２に示されないＷｅｂサーバ、決済サーバまたはコメント配信サーバなどがさらに設けられてもよい。

以下、図３乃至図１１を用いて、補助サーバ４００について詳しく説明する。
補助サーバ４００は、コンピュータであって、例えば、入出力制御、通信制御、ランキング処理（すなわち、投票処理、指標算出、ランキング作成、特典決定、グループ管理、メッセージ生成、属性管理、など）、介入制御（すなわち、介入の実施、決済の制御、など）、などを行うプロセッサを含む。ただし、前述のように観客によるゲームへの介入はオプションであるから、プロセッサは、介入制御を行わないこともあり得る。ここで、プロセッサは、典型的にはＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）および／またはＧＰＵ（ＧｒａｐｈｉｃｓＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）であるが、マイコン、ＦＰＧＡ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）、またはＤＳＰ（ＤｉｇｉｔａｌＳｉｇｎａｌＰｒｏｃｅｓｓｏｒ）、などであってもよい。また、補助サーバ４００は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリを含んでいる。

なお、補助サーバ４００は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、補助サーバ４００に内蔵または外付けされたＨＤＤ（ＨａｒｄＤｉｓｃＤｒｉｖｅ）、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）、フラッシュメモリなどであってもよいし、補助サーバ４００からアクセス可能なデータベースサーバであってもよい。

また、補助サーバ４００は、複数のコンピュータの組み合わせであってよい。例えば、補助サーバ４００の機能部、例えば後述される通信部４１０とランキング処理部４２０および種々の記憶部とが別個のコンピュータに分散して実装されてもよい。

補助サーバ４００は、さらに、ネットワークに接続するための通信Ｉ／Ｆ（インタフェース）を利用可能である。通信Ｉ／Ｆは、補助サーバ４００に内蔵されてもよいし、補助サーバ４００に外付けされてもよい。

通信Ｉ／Ｆは、ネットワーク経由で、観客端末３００およびゲーム実行装置（図１の例ではゲームサーバ５００であり、図２の例では配信者端末６００である）と通信をするためのモジュールであり得る。

補助サーバ４００は、複数の単位期間に亘って繰り返し動作する。そして、この複数の単位期間の各々は、投票可能期間（第１の部分期間）と、当該投票可能期間よりも後の特典決定期間（第２の部分期間）とを含む。

複数の単位期間同士は、必ずしも連続している必要はなく、互いに間隔が空いていてもよい。逆に、複数の単位期間が部分的に並行して存在してもよい。具体的には、ある単位期間の特典決定期間中に次の単位期間の投票可能期間が開始してもよい。また、単位期間、投票可能期間および／または特典決定期間は、固定長であってもよいし、可変長であってもよい。

次に、図３を用いて補助サーバ４００の構成例の説明を続ける。図３の補助サーバ４００は、通信部４１０と、ランキング処理部４２０と、種々の記憶部とを含む。

通信部４１０は、例えば前述の通信Ｉ／Ｆであってよく、ネットワーク経由で、例えば観客端末３００およびゲーム実行装置からデータを受信したり、観客端末３００およびゲーム実行装置へデータを送信したりする。具体的には、通信部４１０は、受信部４１１および送信部４１２を含む。

受信部４１１は、投票可能期間中に、観客端末３００から複数のグループのいずれかを指定する投票を受信する。投票は、投票の主体である観客（投票者）を識別するデータ（ユーザ識別子）と投票先であるグループを識別するデータ（グループ識別子）とを含み得る。受信部４１１は、受信した投票を投票処理部４２１へ送る。他方、受信部４１１は、投票可能期間外、例えば特典決定期間中には投票の受信を拒否してもよい。或いは、受信部４１１は投票可能期間か否かに関わらず投票を受信しつつ、投票処理部４２１が投票可能期間外には投票の受け取りを拒否し、または受け取り後に破棄してもよい。

ここで、観客端末３００は、ユーザからの操作入力に基づいて投票を発行し、補助サーバ４００へ送信する。一例として、観客端末３００には図６に例示される投票メニュー画面が表示され、観客がこの投票メニュー画面に含まれる「グループ」ボタンのいずれかを選択すると、当該観客端末３００は選択されたボタンに対応するグループを投票先とする投票を発行し、補助サーバ４００へ送信し得る。

図６の投票メニュー画面は、ゲームのリアルタイムプレイ動画が表示されるページと同一ページに組み込まれていてもよいし、当該ページに含まれるリンクからジャンプ可能なページに組み込まれていてもよい。一例として、図５に示されるように、観客端末３００の画面には、投票可能期間毎に投票を促すメッセージが記載されたメッセージウィンドウが表示（例えばトースト通知）されてよく、観客が当該ウィンドウに表示される「はい」ボタンを選択すると当該観客端末３００の画面が図６に例示した投票メニュー画面へ遷移してもよい。

また、受信部４１１は、ゲーム実行装置からゲーム中のキャラクタのパラメータを受信する。なお、受信部４１１によって受信されるパラメータは、ゲーム中の全キャラクタの全パラメータである必要はなく、特定のキャラクタ（いずれかのグループに所属しているキャラクタ）の指標のベースとなるパラメータに限られてよい。一例として、パラメータは、キャラクタのエネルギー吸収量、武力、財力、領土面積、人口、その他の何らかの能力値（例えば、体力、走力、打率、打点、ホームラン数、得点率、など）、などゲームにより様々に定義され得る。受信部４１１は、ランキング作成に必要な頻度で、例えば単位期間毎に少なくとも１度、パラメータを受信し得る。受信部４１１は、パラメータを指標算出部４２２へ送る。

また、受信部４１１は、配信者端末１００および／または観客端末３００からグループ定義変更要求を受信する。グループ定義変更要求は、要求の主体（要求者）である配信者／観客を識別するデータ（ユーザ識別子）と、要求の種類を示すデータ（要求コード）と、要求の詳細を示すデータとを含み得る。要求の種類は、例えば、ゲームへの新たなグループの追加、ゲーム中の既存のグループに所属するキャラクタの追加、変更もしくは削除、または既存のグループの削除、などであり得る。受信部４１１は、受信したグループ定義変更要求をグループ管理部４２５へ送る。

また、受信部４１１は、ゲーム実行装置からグループの定義に関わるイベントデータを受信し得る。具体的には、このイベントデータは、あるキャラクタがいずれかのグループに所属したこと、あるキャラクタがいずれかのグループから離脱したこと、あるキャラクタがゲームに追加されたこと、あるキャラクタがゲームから離脱したこと、あるグループがゲームに追加されたこと、あるグループがゲームから離脱したこと、などを示し得る。受信部４１１は、受信したイベントデータをグループ管理部４２５へ送る。

また、受信部４１１は、動画配信サーバ２００から観客の属性を示す属性データを受信し得る。受信部４１１によって受信され得る属性データは、例えば、リアルタイムコンテンツ（図１および図２の例ではリアルタイムプレイ動画）へのコメント投稿履歴、当該リアルタイムコンテンツの視聴条件（例えば、視聴継続時間、使用中のブラウザ）、などを示し得る。受信部４１１は、属性データを属性管理部４２７へ送る。

さらに、受信部４１１は、観客端末３００から介入の実施要求を受信し得る。ここで、介入の実施要求は、例えば要求者を示すデータと、要求する介入の種類を示すデータとを含み得る。受信部４１１は、受信した介入の実施要求を介入実施部４２８へ送る。

送信部４１２は、ランキング作成部４２３からランキングデータを受け取り、これを観客端末３００へ送信し得る。送信部４１２は、各単位期間において、当該単位期間または１つ前の単位期間のランキングデータを観客端末３００へ自動的に送信してもよいし、当該ランキングデータの要求を発行するＧＵＩ（ＧｒａｐｈｉｃａｌＵｓｅｒＩｎｔｅｒｆａｃｅ）部品（ウィジェット）を観客端末３００の画面に表示させるためのデータ、ランキングデータの場所を特定するＵＲＬ（ＵｎｉｖｅｒｓａｌＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）、などを観客端末３００へ送信してもよい。

或いは、送信部４１２は、ランキングデータを動画配信サーバ２００へ送信することもあり得る。この場合に、動画配信サーバ２００は、ランキングデータをゲームのリアルタイムプレイ動画に重畳（例えば、ピクチャーインピクチャー（Ｐｉｃｔｕｒｅ−ｉｎ−Ｐｉｃｔｕｒｅ）表示）し、観客端末３００へ配信してもよい。

また、送信部４１２は、メッセージ生成部４２６から、観客端末３００の画面にメッセージ、例えば投票を促すメッセージを表示するためのメッセージデータを受け取り、これを当該観客端末３００へ送信する。

さらに、送信部４１２は、介入実施部４２８からゲーム実行装置に対する要求、例えばイベント発生要求を受け取り、これをゲーム実行装置へ送信し得る。他方、送信部４１２は、介入実施部４２８から介入の実施要求の許可／拒否を示す応答を受け取り、これを要求者の観客端末３００へ送信し得る。

ランキング処理部４２０は、前述のプロセッサおよびメモリであってよい。ランキング処理部４２０は、通信部４１０から、投票、パラメータ、グループ定義変更要求、イベントデータ、属性データ、介入の実施要求、などのデータを受け取る。また、ランキング処理部４２０は、種々の記憶部から必要なデータを読み出す。ランキング処理部４２０は、通信部４１０から受け取ったデータおよび／または種々の記憶部から読み出したデータに基づいて、観客の投票先を管理したり、指標を算出したり、当該指標に基づいてランキングデータを作成したり、当該ランキングデータに基づいて観客に付与する特典を決定したり、グループの定義を管理したり、メッセージデータを生成したり、属性データを管理したり、介入を実施したりする。さらに、ランキング処理部４２０は、ランキングデータ、メッセージデータ、ゲーム実行装置への種々の要求、介入の実施要求の許可／拒否を示す応答、などの種々のデータを通信部４１０へ送る。

具体的には、ランキング処理部４２０は、投票処理部４２１と、指標算出部４２２と、ランキング作成部４２３と、特典決定部４２４と、グループ管理部４２５と、メッセージ生成部４２６と、属性管理部４２７と、介入実施部４２８とを含む。

投票処理部４２１は、受信部４１１から投票を受け取る。投票処理部４２１は、受け取った投票に含まれるユーザ識別子およびグループ識別子を互いに対応付けて、投票先記憶部４３１に書き込む。これは、ユーザ識別子によって識別される観客の投票先として、グループ識別子によって識別されるグループが登録されることを意味する。なお、投票先記憶部４３１に、受け取った投票と同一のユーザ識別子に対応付けられたグループ識別子が既に保存されていたならば、投票処理部４２１は、既存のグループ識別子を、新たに受け取った投票に含まれるグループ識別子によって書き換える。

また、投票処理部４２１は、投票者のユーザ識別子および投票先のグループ識別子を属性管理部４２７へ送ってもよい。属性管理部４２７は、これらのデータに基づいて、例えば、観客の投票回数、および／または観客の現在の投票先が維持されている期間（これは、投票先継続期間と呼ぶことができ、実時間長であってもよいし、単位期間の数で換算されてもよい）などを管理し得る。

なお、投票処理部４２１は、投票可能期間に限って投票を受け付け得る。換言すれば、投票処理部４２１は、投票可能期間外、例えば特典決定期間中には、投票の受け取りを拒否し、または受け取り後に破棄し得る。或いは、前述のように、受信部４１１が、投票可能期間外には投票の受信を拒否してもよい。

指標算出部４２２は、各単位期間において、受信部４１１から各キャラクタのパラメータを受け取る。そして、指標算出部４２２は、複数のグループの各々について当該グループに所属するキャラクタのパラメータに基づいてグループの指標を算出する。指標は、パラメータの統計値であり得る。ここでの統計値は、例えば、総和、重み付き和、平均値、最頻値、中央値、最大値、最小値などであり得る。指標算出部４２２は、各グループの指標をランキング作成部４２３へ送る。

また、指標算出部４２２は、各キャラクタがどのグループに属するか、すなわち各パラメータがどのグループの指標のベースとなるかを判定するために、グループ定義記憶部４３２に保存されたグループ定義データを参照してもよい。グループ定義データは、例えば、グループの識別子と、当該グループに属するキャラクタの識別子との組であり得る。

なお、指標算出部４２２は、投票可能期間の終了後、例えば特典決定期間中のいずれかの時点のパラメータをベースにグループの指標を算出してもよいし、投票可能期間中のいずれかの時点のパラメータをベースにグループの指標を算出してもよい。前者の例によれば、投票受付の締め切り後に指標のベースとなるパラメータが確定するので、観客には順位を予想して楽しむ余地がある。他方、後者の例によれば、指標の算出を前倒しで行うことができるので、特典決定期間の短縮化、すなわち投票受付の締め切り後にテンポよく観客が獲得した特典を発表することができる。

ランキング作成部４２３は、各単位期間において、指標算出部４２２から各グループの指標を受け取る。ランキング作成部４２３は、各単位期間において算出された指標についての複数のグループの順位を示すランキングデータを作成する。ランキング作成部４２３は、グループの順位を、当該グループの指標の降順または昇順に決定する。

ランキングデータは、少なくとも、順位毎に、当該順位を占めるグループを示すデータ（例えば名称）を含む。また、ランキングデータは、オプションとして、各順位を占めるグループの指標、支持率、得票数、などの要素を含んでもよいし、当該グループに投票した観客に分配される特典、例えば仮想的な財貨の総額（後述される図８の例では賞金と呼ばれている）または１人当たりの獲得額などの要素を含んでもよい。グループの得票数は、例えば、そのグループを投票先とする観客の数であり得る（１人１票の場合）。また、グループの支持率は、例えば、そのグループを投票先とする観客の比率であって、グループの得票数／全グループに亘る得票数の総和、により計算可能である。ランキング作成部４２３は、得票数および／または支持率を算出するために、投票先記憶部４３１を参照してもよい。

グループの得票数／支持率をランキングデータに含めることで、配信者および／または観客は、どのグループが人気を集めているのかを把握でき、そのグループが有利になるように、或いは逆に不利になるように、操作および／または介入を行って、動画を盛り上げやすくなる。また、後述されるように、観客への特典が同じグループに投票した観客同士の山分けにより決まる場合には、観客は、特典の分け前が大きくなることを狙って、自らの好みおよび順位よりも、得票数および支持率の低さを重視して、或いはその裏を読んで投票先を決める、など戦略的に投票を楽しむことができる。

なお、ランキング作成部４２３は、指標算出部４２２による指標の算出が完了すれば、ランキングデータを作成できる。故に、ランキング作成部４２３は、特典決定期間中に限らず、特典決定期間前にランキングデータを作成することもあり得る。ただし、ランキングの発表は、投票可能期間の終了後に行う必要がある。

ランキング作成部４２３は、作成したランキングデータを送信部４１２および特典決定部４２４へ送る。なお、ランキング作成部４２３は、ランキングデータそのものの代わりに、ランキングデータの要求を発行するウィジェットを当該観客端末３００の画面に表示させるためのデータ、ランキングデータの場所を特定するＵＲＬ、などを送信部４１２へ送ってもよい。

一例として、図７に示されるように、観客端末３００の画面には、ランキングの発表準備が完了する毎にその旨を知らせるメッセージが記載されたメッセージウィンドウが表示されてよく、観客が当該ウィンドウに表示される「はい」ボタンを選択すると当該観客端末３００の画面が図８に例示するランキング発表画面へ遷移してもよい。

図８のランキング発表画面では、ランキングに加えて、観客の投票先を示す情報、当該投票先の順位を示す情報、観客が獲得した特典を示す情報、および観客が保有している特典を示す情報が表示されている。しかしながら、このランキング発表画面は一例に過ぎない。具体的には、ランキング発表画面は、全観客に共通の情報（例えばランキング結果）と、投票先が同じ観客に共通の情報（例えば投票先の順位を示す情報）と、観客個別の情報（例えば観客が獲得した／保有している特典を示す情報）とのうち、一部を含まなくてもよい。なお、観客が獲得した／保有している特典を示す情報は、例えば、特典決定部４２４から取得することが可能である。

特典決定部４２４は、ランキング作成部４２３からランキングデータを受け取り、投票先記憶部４３１から観客毎に当該観客の投票先を示すグループ識別子を読み出す。また、特典決定部４２４は、属性記憶部４３３から属性データを読み出し得る。特典決定部４２４は、各観客に付与する特典をこれらのデータに基づいて決定する。このように投票をした観客へ特典を付与することは、観客が投票をするインセンティブとなり得る。そして、観客は、グループへの投票行為と自らの投票したグループの順位の確認とをするうちに、当該グループに愛着を抱くように仕向けられる。

まず、特典決定部４２４は、各特典決定期間中に、当該特典決定期間が属する単位期間における観客の投票先を特定する。ここで、特典決定部４２４は、各観客の投票先を、投票先記憶部４３１において当該観客を識別するユーザ識別子に対応付けて保存されているグループ識別子から特定することができる。

すなわち、特典決定部４２４は、投票可能期間中に観客の端末３００から投票が受信された場合には、当該投票によって指定されたグループを当該投票可能期間の属する単位期間における当該観客の投票先として特定する。他方、特典決定部４２４は、投票可能期間中に観客の端末３００から投票が受信されなかった場合には、当該単位期間よりも過去の単位期間における投票可能期間中に当該端末３００から受信された投票によって指定されたグループを当該投票可能期間の属する単位期間における当該観客の投票先として維持する。すなわち、観客がある単位期間に投票をしなかったとしても、特典決定部４２４は当該観客が当該単位期間も過去と同じ投票先に再投票したものとみなして、当該観客に付与する特典を決定できる。これは、観客が投票先を変えない場合であっても単位期間の度に同じ投票先に再投票しなければならないという煩雑さをなくすことができるととともに、補助サーバ４００において単位期間あたりに処理しなければならない投票数を削減して負荷を軽減できるというメリットがある。

それから、特典決定部４２４は、各特典決定期間中に、当該特典決定期間が属する単位期間において作成されたランキングデータにおけるグループの順位に応じて、当該グループを投票先とする観客へ付与する特典を決定する。

例えば、特典決定部４２４は、各グループの順位に応じた固定の特典を、当該グループを投票先とする観客へ一律に付与すると決定してもよい。この例によれば、同じグループに投票した観客がどれだけ増えようと、各観客に付与される特典は目減りしない。

或いは、特典決定部４２４は、各グループの順位に応じた固定の特典（例えば、固定額の仮想的な財貨）を、当該グループを投票先とする観客に分配（すなわち山分け）すると決定してもよい。この例によれば、同じグループに投票した観客が増えるほど、各観客に付与される特典（分け前）は減ることになる。

例えば順位が容易に変動しない場合には、観客の投票先が上位常連のグループに過度に偏り、ランキングが代わり映えしないものとなる可能性がある。そこで、このように固定の特典を投票者間で山分けすることで、上位常連でないグループにも投票が分散するように促してもよい。

さらに、分配比率は一様であってもよいし、観客間で差を付けてもよい。特典決定部４２４は、各観客の属性に基づいて、当該観客への上記特典の分配比率を決定してもよい。具体的には、属性は、観客のリアルタイムプレイ動画へのコメント投稿履歴／介入実施履歴、観客のリアルタイムプレイ動画の視聴条件、観客の投票先継続期間、観客の投票回数、などであり得る。

具体的には、コメント投稿／介入実施が活発になるほど、リアルタイムプレイ動画は盛り上がりやすいと考えられる。故に、特典決定部４２４は、観客のコメント投稿／介入実施を推奨すべく、コメント投稿数／介入実施数の多い観客の分配比率を高くしてもよい。また、視聴意欲の高い観客は、リアルタイムプレイ動画を長時間視聴すると考えられる。故に、特典決定部４２４は、かかる視聴意欲の高い観客へのボーナスとして、視聴継続時間の長い観客の分配比率を高くしてもよい。また、グループへの愛着が強く視聴意欲の高い観客は、投票先を変更しにくいと考えられる。故に、特典決定部４２４は、かかる視聴意欲の高い観客へのボーナスとして、投票先継続期間が長い観客の分配比率を高くしてもよい。さらに、投票先を頻繁に変更する観客は、自らの好みよりも寧ろ特典の分け前が大きくなることを優先して戦略的に投票先を変更していると考えられる。故に、特典決定部４２４は、観客が同じグループを支持し続けることを推奨すべく、投票回数の多い観客の分配比率を低くしてもよい。なお、ここで説明した分配比率の決定方針は例示に過ぎない。特典決定部４２４は、ここで説明したのとは異なる、例えば逆の方針で、分配比率を決定してもよい。

さらに、特典決定部４２４は、決定した特典に応じて、観客の保有する特典のデータを更新し得る。図３の例では、特典は仮想的な財貨としてのポイントであり、特典決定部４２４は、ポイント記憶部４３４からユーザ毎の保有ポイントを読み出し、これに当該ユーザの獲得したポイントを加算し、ポイント記憶部４３４に書き込む。

ここで、図４を用いて、補助サーバ４００が単位期間中にどのように動作するかを概念的に説明する。図４の例では、１つの単位期間Ｔ１が示されており、この単位期間Ｔ１は投票可能期間Ｔ１−１および特典決定期間Ｔ１−２を含む。

投票処理部４２１は、投票可能期間Ｔ１−１中に受信部４１１によって受信された投票を受け付けて、投票先を書き換える。すなわち、投票処理部４２１は、受け取った投票に含まれる投票者の識別子および投票先の識別子を互いに対応付けて、投票先記憶部４３１に書き込む。

指標算出部４２２は、単位期間Ｔ１中に、受信部４１１によって受信された、各キャラクタのパラメータを収集する。それから、指標算出部４２２は、収集したパラメータに基づいて各グループの指標を算出する。なお、図４の例では、指標算出部４２２は、パラメータの収集および指標の算出の両方を特典決定期間Ｔ１−２中に行っているが、これは例示に過ぎない。指標算出部４２２は、パラメータの収集および指標の算出の一方または両方を投票可能期間Ｔ１−１中に行ってもよい。

ランキング作成部４２３は、単位期間Ｔ１中であって、かつ、指標算出部４２２が各グループの指標を算出した後に、当該指標についてランキングデータを作成する。なお、図４の例では、ランキング作成部４２３は、特典決定期間Ｔ１−２中にランキングデータを作成しているが、これは例示に過ぎない。ランキング作成部４２３は、投票可能期間Ｔ１−１中にランキングデータを作成してもよい。

また、ランキング作成部４２３は、単位期間Ｔ１中であって、かつ、ランキングデータを作成した後に、当該ランキングを発表する。具体的には、ランキング作成部４２３は、作成したランキングデータを送信部４１２へ送ってもよいし、ランキングデータそのものの代わりに、ランキングデータの要求を発行するウィジェットを当該観客端末３００の画面に表示させるためのデータ、ランキングデータの場所を特定するＵＲＬ、などを送信部４１２へ送ってもよい。なお、図４の例では、ランキング作成部４２３は、特典決定部４２４が各観客に付与する特典を決定した後に、ランキングを発表しているがこれは例示に過ぎない。例えば、ランキング発表画面に観客が獲得した／保有している特典を示す情報を含めない場合には、ランキング作成部４２３は、特典の決定を待たずにランキングを発表し得る。ただし、ランキングの発表は、投票可能期間Ｔ１−１の終了後、例えば特典決定期間Ｔ１−２中に行う必要がある。

特典決定部４２４は、特典決定期間Ｔ１−２中であって、かつ、ランキング作成部４２３がランキングデータを作成した後に、単位期間Ｔ１における各観客の投票先を特定し、当該ランキングデータに基づいて各観客に付与する特典（図４の例ではポイント）を決定し、ポイント記憶部４３４に保存されている各観客のポイントデータを更新する。

グループ管理部４２５は、グループの定義を管理する。具体的には、グループ管理部４２５は、受信部４１１から、グループの定義に関わるイベントデータを受け取り得る。グループ管理部４２５は、グループ定義記憶部４３２に保存されているグループ定義データをこのイベントデータに応じて書き換える。

具体的には、グループ管理部４２５は、あるキャラクタがいずれかのグループに所属したことを示すイベントデータを受け取ると、このグループの識別子にこのキャラクタの識別子を対応付けてグループ定義記憶部４３２に保存する。グループ管理部４２５は、あるキャラクタがいずれかのグループから離脱したことを示すイベントデータを受け取ると、グループ定義記憶部４３２においてこのグループの識別子に対応付けて保存されているこのキャラクタの識別子を削除する。グループ管理部４２５は、あるキャラクタ／グループがゲームに追加されたことを示すイベントデータを受け取ると、このキャラクタ／グループの識別子を新たに発行してグループ定義記憶部４３２に書き込む。グループ管理部４２５は、あるキャラクタ／グループがゲームから離脱したことを示すイベントデータを受け取ると、グループ定義記憶部４３２に保存されているこのキャラクタ／グループの識別子を削除する。

また、グループ管理部４２５は、受信部４１１から、グループ定義変更要求を受け取り得る。グループ定義記憶部４３２に保存されているグループ定義データをこのグループ定義変更要求に応じて書き換える。

具体的には、グループ管理部４２５は、グループ定義変更要求の許可／拒否を判定し、要求を拒否する場合にはその旨を示すコードを応答として送信部４１２へ送る。他方、グループ管理部４２５は、要求を許可する場合には、グループ定義記憶部４３２に保存されているグループ定義データを当該要求に応じて書き換える。そして、グループ管理部４２５は、要求が許可された旨のコードを要求に対する応答として送信部４１２へ送る。

ここで、グループ管理部４２５は、例えば、要求単位で設定された権限に基づいて、グループ定義変更要求の許可／拒否を判定し得る。権限は、プレイヤが自由に編集可能としてもよいし、補助サーバ４００の運営者が一括で設定してもよいし、ゲームの仕様により定められていてもよい。

権限は、例えば以下の（ａ）〜（ｃ）のようなものであり得る。なお、以下の権限（ａ）〜（ｃ）は例示に過ぎず、これらと異なるように権限が定められてもよい。
（ａ）ゲームへの新たなグループの追加（定義）は、対価の支払いを条件に、配信者およびブラックリストに登録されていない観客のみに許可される。ここで、ブラックリストには、例えば、ユーザ間で共通のＮＧユーザリストに登録されているユーザ、配信者が個別指定した他のユーザ、などが登録され得る。

（ｂ）ゲーム中の既存のグループに所属するキャラクタの追加、変更または削除は、対価の支払いを条件に配信者および当該キャラクタに名前を付けた観客のみに許可される。ここで、キャラクタに名前を付けることは、補助サーバ４００によって実施可能な介入の１つであり得る。また、観客があるキャラクタに名前を付けたことを示すデータが、例えば属性データの１つとして属性記憶部４３３に保存され得る。

（ｃ）ゲーム中の既存のグループの削除は、対価の支払いを条件に配信者およびホワイトリストに登録されている観客のみに許可される。ここで、ホワイトリストには、例えば、配信者のフォロワー、配信者がフォローしているユーザ、配信者のフレンド、配信者が個別指定した他のユーザ、などが登録され得る。

さらに、グループ管理部４２５は、グループ定義データを書き換えた場合に、その旨をメッセージ生成部４２６へ報告し得る。例えば、グループ管理部４２５は、ゲーム中のグループの増減があった場合に、その旨をメッセージ生成部４２６へ報告し得る。これにより、メッセージ生成部４２６は、自らの投票していたグループへの投票の継続が不可能となった（例えば、当該グループがゲームから離脱してしまった）観客、および新たに追加されたグループに興味を持ちそうな観客、例えば当該グループに所属するキャラクタに名前を付けた観客向けに、投票を促すメッセージを生成することができる。また、グループ管理部４２５は、グループの増減以外にも、ゲーム中の既存のグループに所属するキャラクタの追加、変更または削除があった場合にも、その旨をメッセージ生成部４２６へ報告してもよい。これにより、メッセージ生成部４２６は、特定のキャラクタに愛着を抱いている観客、例えば当該キャラクタに名前を付けた観客向けに、当該キャラクタの異動に追従した投票を促すメッセージを生成することができる。

メッセージ生成部４２６は、グループ管理部４２５からグループ定義データの書き換えがあったとの報告を受けると、観客端末３００の画面に観客に投票を促すメッセージを表示するためのメッセージデータを生成する。メッセージ生成部４２６は、生成したメッセージデータを送信部４１２へ送る。

なお、メッセージ生成部４２６は、全ての観客端末３００をメッセージデータの送信先に設定してもよいし、一部の観客端末３００をメッセージデータの送信先に設定にしてもよい。メッセージ生成部４２６は、メッセージデータの送信先を決定するために、投票先記憶部４３１を参照してもよい。

具体的には、メッセージ生成部４２６は、グループ管理部４２５からの報告によりあるグループへの投票の継続が不可能となったこと（例えば、当該グループがゲームを離脱したこと）を検知すると、当該グループを投票先としていた観客の端末３００をメッセージデータの送信先に設定してもよい。これにより、メッセージデータを受信した観客端末３００の画面には、図９のようなメッセージが記載されたメッセージウィンドウが表示され、観客はこれまでの投票先以外のグループのいずれかへ投票するように促される。この投票行為により、観客の意識は別のグループへと向くので、お気に入りのグループへの投票の継続が不可能となったことによる視聴意欲の低下が緩和する可能性がある。

図９のメッセージウィンドウには「はい」ボタンが表示されているが、一例として観客がこのボタンを選択すると観客端末３００の画面が図６に例示した投票メニュー画面へ遷移してもよい。さらに、かかる投票メニュー画面から新たな投票を行った観客には、何らかのボーナスが付与されてもよい。ボーナスは、既定の特典であってもよいし、以降の１回または複数回のランキングにより獲得する特典の分配比率を引き上げることであってもよい。

同様に、メッセージ生成部４２６は、グループ管理部４２５からの報告により新たなグループがゲームに追加されたことを検知すると、少なくとも一部の観客、例えば当該グループに所属するキャラクタのいずれかに名前を付けた観客の端末３００をメッセージデータの送信先に設定してもよい。これにより、メッセージデータを受信した観客端末３００の画面には、図１０のようなメッセージが記載されたメッセージウィンドウが表示され、観客は新たなグループを含む複数のグループのいずれかへ投票するように促される。

図１０のメッセージウィンドウには「はい」ボタンが表示されているが、一例として観客がこのボタンを選択すると観客端末３００の画面が図６に例示した投票メニュー画面へ遷移してもよい。

なお、図１０のメッセージの代わりに、「あなたが名付けた○○が所属する××グループがゲームに追加されました。このグループに投票しますか？」のようなメッセージが記載されたメッセージウィンドウが観客端末３００の画面に表示されてもよい。

属性管理部４２７は、受信部４１１から観客の属性データを受け取り、これを属性記憶部４３３へ書き込む。また、属性管理部４２７は、必要に応じて、例えば観客の介入実施履歴、投票先継続期間および／または投票回数を管理し得る。例えば、属性管理部４２７は、介入実施部４２８から取得可能な情報、例えば介入実施部４２８によって実施された介入とその要求者の情報、に基づいて観客の介入実施履歴を管理してもよい。属性管理部４２７は、投票処理部４２１から取得可能な情報、例えば投票者およびその投票先の情報に基づいて、観客の投票先継続期間および／または投票回数を管理してもよい。

介入実施部４２８は、受信部４１１から介入の実施要求を受け取ると、例えば対価に相当するポイントと引き替えにゲームに対して当該実施要求の対象となる介入を実施する。まず、介入実施部４２８は、対価の決済を行うために、ポイント記憶部４３４から要求者の保有ポイントを読み出し、対価に相当するポイントを減算する。

ここで、減算結果が正であれば、介入実施部４２８はこの減算結果によってポイント記憶部４３４に保存されている要求者の保有ポイントを書き換える。そして、介入実施部４２８は、介入の実施要求に応じた要求、例えばイベントの発生要求を生成し、送信部４１２へ送る。また、介入実施部４２８は、介入が実施されることをその要求者に伝えるために、介入の実施要求の許可を示す応答を生成し、送信部４１２へ送ってもよい。

他方、減算結果が負であれば、介入実施部４２８は、要求者の保有するポイントが要求した介入の対価に満たない（すなわち残高不足）として、介入を取り止める。また、介入実施部４２８は、介入の実施要求の拒否を示す応答を生成し、送信部４１２へ送ってもよい。

なお、上記説明では、介入実施部４２８が対価の決済処理も担当しているが、対価の決済処理は図示されない決済サーバによって行われてもよい。また、ポイント記憶部４３４は、補助サーバ４００とは別のサーバに設けられてもよい。これにより、仮に補助サーバ４００への不正アクセスがなされたとしても、それ自体がポイントの不正閲覧、改竄、消失、などのトラブルに直接結びつくことはない。

図３の例において種々の記憶部は、投票先記憶部４３１と、グループ定義記憶部４３２と、属性記憶部４３３と、ポイント記憶部４３４とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

投票先記憶部４３１は、観客毎の投票先のデータを保存する。具体的には、投票先記憶部４３１は、投票者のユーザ識別子に対応付けて投票先のグループ識別子を保存する。観客毎の投票先のデータは、投票処理部４２１によって書き込まれ、または書き換えられる。また、観客毎の投票先のデータは、ランキング作成部４２３および特典決定部４２４によって読み出され得る。

グループ定義記憶部４３２は、グループ定義データを保存する。具体的には、グループ定義記憶部４３２は、グループの識別子に対応付けて当該グループに属する要素（キャラクタ）の識別子を保存する。グループ定義データは、グループ管理部４２５によって書き込まれ、または書き換えられる。また、グループ定義データは、様々な機能部、具体的には、指標算出部４２２、ランキング作成部４２３および特典決定部４２４により読み出され得る。

属性記憶部４３３は、観客毎の属性データを保存する。具体的には、属性記憶部４３３は、観客の識別子に対応付けて当該観客の少なくとも１つの属性の値を保存する。属性データは、属性管理部４２７によって書き込まれ、または書き換えられる。また、属性データは、特典決定部４２４によって読み出され得る。

ポイント記憶部４３４は、観客毎のポイントデータを保存する。具体的には、ポイント記憶部４３４は、観客の識別子に対応付けて当該観客の保有ポイントの値（残高）を保存する。ポイントデータは、特典決定部４２４（ポイントの付与）および介入実施部４２８（介入の実施に伴う決済）により書き込まれ、または書き換えられる。

次に図１１を用いて、１つの単位期間についての補助サーバ４００の動作例を説明する。
まず、投票可能期間中に、受信部４１１は投票を待ち受ける。受信部４１１が投票を受信すると（ステップＳ７０１）、投票処理部４２１はこの投票に基づいて投票者の投票先を更新する（ステップＳ７０２）。かかる処理が投票可能期間の満了まで繰り返される（ステップＳ７０３）。

他方、ステップＳ７０４において、指標算出部４２２は、受信部４１１によって受信された、各キャラクタのパラメータを収集する。次に、指標算出部４２２は、ステップＳ７０４において収集したパラメータに基づいて、各グループの指標を算出する（ステップＳ７０５）。そして、ランキング作成部４２３は、ステップＳ７０５において算出された指標についてランキングデータを作成する（ステップＳ７０６）。

なお、図１１の例では、ステップＳ７０４乃至ステップＳ７０６は、いずれもステップＳ７０３の後、すなわち投票可能期間の終了後に行われているが、これは例示に過ぎない。これらのステップの一部または全部が、投票可能期間中、すなわちステップＳ７０１乃至ステップＳ７０３と並行して行われてよい。

特典決定部４２４は、この単位期間における各観客の投票先を特定し、それからステップＳ７０６において作成されたランキングデータに基づいて、各観客に付与する特典（図１１の例ではポイント）を決定する（ステップＳ７０７）。さらに、特典決定部４２４は、ステップＳ７０７において決定した特典に従って、ポイント記憶部４３４に保存されている各観客のポイントデータを更新する（ステップＳ７０８）。

ランキング作成部４２３は、ステップＳ７０６において作成したランキングを発表する（ステップＳ７０９）。なお、図１１の例では、ランキング作成部４２３は、ステップＳ７０７およびステップＳ７０８の後に、ランキングを発表しているがこれは例示に過ぎない。例えば、ランキング発表画面に観客が獲得した／保有している特典を示す情報を含めない場合には、ランキング作成部４２３は、ステップＳ７０７およびステップＳ７０８の実行を待たずにランキングを発表し得る。ただし、ステップＳ７０９は、投票可能期間の満了後、すなわちステップＳ７０１乃至ステップＳ７０３の後に行う必要がある。

以上説明したように、実施形態に係る補助サーバは、観客端末からゲーム中の複数のグループのいずれかへの投票を受け付け、観客毎に投票先を管理する。それから、補助サーバは、ゲーム中の各キャラクタのパラメータをゲーム実行装置から収集し、当該パラメータに基づいてグループ毎の指標を算出し、この指標についての複数のグループの順位を示すランキングデータを作成する。補助サーバは、このランキングデータを観客向けに発表するとともに、当該ランキングデータにおけるグループの順位に応じて、当該グループを投票先とする観客へ付与する特典を決定する。故に、この補助サーバによれば、観客は、グループへの投票行為と自らの投票したグループの順位の確認とをするうちに、ゲーム中に登場するキャラクタだけでなく、キャラクタの束であるグループにも愛着を抱くように仕向けられる。観客がグループに愛着を抱くようになれば、そうならなかった場合に比べて、観客のお気に入りのキャラクタが死亡などによりゲームを離脱した時にも観客の視聴意欲は低下しにくくなると予想される。さらに、キャラクタ単位ではなくグループ単位でランキング化をすることは、補助サーバにおける負荷の軽減にも寄与する。

また、補助サーバは、観客がある単位期間に投票をしなかったとしても、当該観客が当該単位期間も過去と同じ投票先に再投票したものとみなして、当該観客に付与する特典を決定してもよい。これは、観客が投票先を変えない場合であっても単位期間の度に同じ投票先に再投票しなければならないという煩雑さをなくすことができるととともに、補助サーバにおいて単位期間あたりに処理しなければならない投票数を削減して負荷を軽減できるというメリットがある。

さらに、補助サーバは、あるグループへの投票の継続が不可能となったこと（例えば、当該グループがゲームを離脱したこと）を検知すると、当該グループを投票先としていた観客の端末の画面に、他のグループへの投票を促すメッセージを表示するためのメッセージデータを生成し、当該端末へ送信する。これにより、観客はこれまでの投票先以外のグループのいずれかへ投票するように促される。この投票行為により、観客の意識は別のグループへと向くので、お気に入りのグループへの投票の継続が不可能となったことによる視聴意欲の低下が緩和する可能性がある。

（変形例）
前述の実施形態では、ゲームのリアルタイムプレイ動画の観客向けに、当該ゲーム中のキャラクタをグループ化したグループに投票できる仕組みを提供し、当該観客のお気に入りのキャラクタがゲームを離脱した場合の視聴意欲の低下を防止する。

この実施形態の変形例として、リアルタイムコンテンツ全般の観客向けに、リアルタイムコンテンツに関わる要素、例えば配信者および／またはリアルタイムコンテンツそのもの、をグループ化したグループに投票できる仕組みを提供し、当該観客のお気に入りの配信者および／またはリアルタイムコンテンツが配信を終了した時の視聴意欲の低下を抑制してもよい。

この変形例において、指標は、リアルタイムコンテンツに関わる要素のパラメータ、例えば、リアルタイムコンテンツの観客数もしくはコメント投稿数、またはこれらの短期的な変動（例えば単位期間あたりの増数）、などをベースに算出され得る。

概括すれば、変形例に係る補助サーバは、観客端末からリアルタイムコンテンツの配信者（またはリアルタイムコンテンツ）のグループのいずれかへの投票を受け付け、観客毎に投票先を管理する。それから、補助サーバは、リアルタイムコンテンツに関わる要素のパラメータをリアルタイムコンテンツ配信サーバ（例えば動画配信サーバ２００）から収集し、当該パラメータに基づいてグループ毎の指標を算出し、この指標についての複数のグループの順位を示すランキングデータを作成する。補助サーバは、このランキングデータを観客向けに発表するとともに、当該ランキングデータにおけるグループの順位に応じて、当該グループを投票先とする観客へ付与する特典を決定する。

故に、この補助サーバによれば、観客は、グループへの投票行為と自らの投票したグループの順位の確認とをするうちに、お気に入りの配信者（またはリアルタイムコンテンツ）だけでなく、配信者（またはリアルタイムコンテンツ）の束であるグループにも愛着を抱くように仕向けられる。観客がグループに愛着を抱くようになれば、そうならなかった場合に比べて、観客のお気に入りの配信者（またはリアルタイムコンテンツ）が配信を終了した時にもリアルタイムコンテンツの配信サービスの利用に対する観客のモチベーションが低下しにくくなり、同一グループに属する他の配信者（またはリアルタイムコンテンツ）を選択して視聴を継続する可能性がある。さらに、配信者（またはリアルタイムコンテンツ）単位ではなくグループ単位でランキング化をすることは、補助サーバにおける負荷の軽減にも寄与する。

さらに、補助サーバは、あるグループへの投票の継続が不可能となったこと（例えば、当該グループに属する全ての配信者／リアルタイムコンテンツの配信が終了したこと）を検知すると、当該グループを投票先としていた観客の端末の画面に、他のグループへの投票を促すメッセージを表示するためのメッセージデータを生成し、当該端末へ送信する。これにより、観客はこれまでの投票先以外のグループのいずれかへ投票するように促される。この投票行為により、観客の意識は別のグループへと向くので、お気に入りのグループへの投票の継続が不可能となったことによる視聴意欲の低下が緩和する可能性がある。

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

上述の実施形態では、いくつかの機能部を説明したが、これらは各機能部の実装の一例に過ぎない。例えば、１つの装置に実装されると説明された複数の機能部が複数の別々の装置に亘って実装されることもあり得るし、逆に複数の別々の装置に亘って実装されると説明された機能部が１つの装置に実装されることもあり得る。

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

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

１００，６００・・・配信者端末
２００・・・動画配信サーバ
３００・・・観客端末
４００・・・補助サーバ
４１０・・・通信部
４１１・・・受信部
４１２・・・送信部
４２１・・・投票処理部
４２２・・・指標算出部
４２３・・・ランキング作成部
４２４・・・特典決定部
４２５・・・グループ管理部
４２６・・・メッセージ生成部
４２７・・・属性管理部
４２８・・・介入実施部
４３１・・・投票先記憶部
４３２・・・グループ定義記憶部
４３３・・・属性記憶部
４３４・・・ポイント記憶部
５００・・・ゲームサーバ

Claims

リアルタイムコンテンツの観客の端末から、前記リアルタイムコンテンツに関わる複数の要素をグループ化した複数のグループのいずれかを指定する投票を受信する受信部と、
前記複数のグループの各々について当該グループに所属する要素のパラメータに基づいて当該グループの指標を算出する算出部と、
前記指標についての前記複数のグループの順位を示すランキングデータを作成する作成部と、
前記複数のグループの１つである第１のグループへの投票の継続が不可能となったことを検知した場合に、当該第１のグループを投票先とする観客の前記端末の画面に、前記第１のグループ以外のグループのいずれかへの投票を促す第１のメッセージを表示するための第１のメッセージデータを生成するメッセージ生成部と、
前記第１のメッセージデータを前記第１のグループを投票先とする観客の端末へ送信する送信部と
を具備する、サーバ。
前記リアルタイムコンテンツは、複数のキャラクタが併存するゲームのリアルタイムプレイ動画であって、
前記複数のグループは、前記複数のキャラクタをグループ化する、
請求項１に記載のサーバ。
前記メッセージ生成部は、前記第１のグループが前記ゲームを離脱したことを検知した場合に、前記第１のメッセージデータを生成する、請求項２に記載のサーバ。
前記メッセージ生成部は、さらに、新たなグループが前記ゲームに追加されたことを検知した場合に、前記端末の画面に、前記新たなグループを含む複数のグループのいずれかへの投票を促す第２のメッセージを表示するための第２のメッセージデータを生成し、
前記送信部は、さらに、前記第２のメッセージデータを前記端末へ送信する、
請求項２に記載のサーバ。
前記複数のグループの定義を管理するグループ管理部をさらに具備する、請求項２に記載のサーバ。
前記観客の投票先を特定し、前記ランキングデータにおける当該投票先の順位に応じて当該観客に付与する特典を決定する決定部をさらに具備し、
前記特典は、前記観客による前記ゲームへの介入を実施するための対価の支払いに充当可能な仮想的な財貨である、
請求項２に記載のサーバ。
前記観客の投票先を特定し、前記ランキングデータにおける当該投票先の順位に応じて当該観客に付与する特典を決定する決定部をさらに具備する、請求項１または請求項２に記載のサーバ。
前記複数のグループは、第２のグループを含み、
前記特典は、仮想的な財貨であり、
前記決定部は、前記ランキングデータにおける前記第２のグループの順位に応じた固定額の前記仮想的な財貨を、当該第２のグループを投票先とする観客に分配すると決定する、
請求項７に記載のサーバ。
前記決定部は、前記第２のグループを投票先とする観客それぞれの属性に基づいて当該観客への前記固定額の仮想的な財貨の分配比率を決定する、請求項８に記載のサーバ。
前記属性は、前記観客の前記リアルタイムコンテンツへのコメント投稿履歴、前記観客の前記リアルタイムコンテンツの視聴条件、前記観客の投票先が前記第２のグループとして維持されている期間、前記観客の投票回数、のうちの少なくとも１つを含む、請求項９に記載のサーバ。
前記サーバは、複数の単位期間に亘って繰り返し動作し、
前記複数の単位期間の各々は、第１の部分期間と当該第１の部分期間よりも後の第２の部分期間とを含み、
前記受信部は、前記第１の部分期間中に、前記端末から前記投票を受信し、
前記算出部は、前記複数の単位期間の各々において、前記複数のグループの各々について当該グループに所属する要素のパラメータに基づいて当該グループの指標を算出し、
前記作成部は、前記複数の単位期間の各々において算出された前記指標についての前記ランキングデータを作成し、
前記決定部は、前記第２の部分期間中に、（ａ）当該第２の部分期間が属する単位期間における前記第１の部分期間中に前記端末から前記投票が受信された場合には、当該投票によって指定されたグループを当該観客の投票先として特定し、（ｂ）当該第１の部分期間中に前記端末から前記投票が受信されなかった場合には、当該単位期間よりも過去の単位期間における前記第１の部分期間中に当該端末から受信された投票によって指定されたグループを当該観客の投票先として維持する、
請求項６または請求項７に記載のサーバ。
前記ランキングデータは、前記複数のグループそれぞれを投票先とする観客の数または比率をさらに示す、請求項１乃至請求項１１のいずれか１項に記載のサーバ。
コンピュータを、
リアルタイムコンテンツの観客の端末から、前記リアルタイムコンテンツに関わる複数の要素をグループ化した複数のグループのいずれかを指定する投票を受信する手段、
前記複数のグループの各々について当該グループに所属する要素のパラメータに基づいて当該グループの指標を算出する手段、
前記指標についての前記複数のグループの順位を示すランキングデータを作成する手段、
前記複数のグループの１つである第１のグループへの投票が不可能となったことを検知した場合に、当該第１のグループを投票先とする観客の前記端末の画面に、前記第１のグループ以外のグループのいずれかへの投票を促す第１のメッセージを表示するための第１のメッセージデータを生成する手段、
前記第１のメッセージデータを前記第１のグループを投票先とする観客の端末へ送信する手段
として機能させるプログラム。