JP6378849B1 - サーバおよびプログラム - Google Patents

Abstract

【課題】ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入が短期間に集中することによる双方向的なゲーム体験の破綻を回避する。
【解決手段】本発明の一態様に係るサーバは、算出部と、決定部と、送信部と、介入部とを含む。算出部は、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。決定部は、ゲームのリアルタイムプレイ動画の観客がゲームに対して介入を実施するための対価を負荷指標に基づいて決定する。送信部は、対価を示す情報を観客の端末へ送信する。介入部は、介入の実施要求が受信された場合に、対価と引き替えにゲームに対して当該実施要求の対象となる介入を実施する。決定部は、負荷指標が第１の負荷を示す場合には対価を第１の値に決定し、負荷指標が第１の負荷よりも重い第２の負荷を示す場合には対価を第１の値よりも高い第２の値に決定する。
【選択図】 図３

Description

本発明は、双方向的なゲーム体験を提供するゲームのリアルタイムプレイ動画の配信システムに関する。

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

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

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

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

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

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

生放送の動画に対して観客がコメントを付け、それを配信者が閲覧できるという仕組みのみでは、観客のゲーム進行に対する影響力は限定的である。例えば、観客がいくらコメントを付けようとも配信者がこれを見落としたり無視したりすれば、観客のコメントはゲームの進行に影響を与えない。このように従来のゲーム実況生放送では、ゲームの進行に直接的に関与できるのはプレイヤである配信者のみであるから、配信者の意思と無関係に観客の意思がゲームの進行に影響を与えることはない。

一方、ゲーム実況生放送の観客が例えばアイテムの投下といった（サブ）イベントを発生させるなどしてゲームの進行に介入できるようにすることも想定される。このような枠組みによれば、ゲーム上では、プレイヤである配信者の操作により発生するイベントやゲームの進行に応じて自動的に発生するイベントに加えて、観客の介入によるイベントも発生することになる。これは、プレイヤのみがゲームを遊ぶ場合に比べて多くのイベントが発生し得ることを意味する。

多数の観客が同時多発的に介入を要求し、これにより配信者および観客の認知能力を超える数のイベントが短期間に集中して発生すれば、たとえそれぞれのイベントの発生が都度通知されたとしても配信者も観客もゲーム状態を把握することが困難となる。これは、ゲームおよびそのプレイ動画の面白さを損ねたり、配信者−観客間または観客間のコミュニケーションを阻害したりするなどして、双方向的なゲーム体験を破綻させるおそれがある。さらに、短期間に多数のイベントを発生させたりその通知をしようとしたりすれば、ゲームの実行主体（ゲームサーバまたは配信者の端末）の処理負荷も重くなる。

観客による介入を無条件に実現するのではなく、何らかの必要条件（例えば課金）を設ければ観客による介入は減るであろう。しかしながら、この必要条件が厳しすぎると、ごく一部の熱心な観客だけがゲームの進行に介入し、他の多くの観客はゲームの進行に介入しようとせず一体感が薄れる、といった事態が起こる可能性がある。他方、この必要条件が緩すぎると、無条件とした場合と同様の問題が起こる可能性がある。

特許文献２には、ユーザが所望するオブジェクトの対価を設定するための態様として、ゲーム制御装置の処理負荷に関する情報に基づいて、処理負荷が高いほど所定の対価が多く必要になるように設定すること（［００１３］）、および、検索料あるいは検索条件に関する情報をユーザに提示すること（［００５１］、［００８０］、図１１、図１６）、などが記載されている。しかしながら、特許文献２では、ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入を許容することがそもそも想定されていない。

本発明は、ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入が短期間に集中することによる双方向的なゲーム体験の破綻を回避することを目的とする。

本発明の一態様に係るサーバは、算出部と、決定部と、送信部と、受信部と、介入部とを含む。算出部は、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。決定部は、ゲームのリアルタイムプレイ動画の観客がゲームに対して介入を実施するための対価を負荷指標に基づいて決定する。送信部は、対価を示す情報を観客の端末へ送信する。受信部は、端末から介入の実施要求を受信する。介入部は、介入の実施要求が受信された場合に、対価と引き替えにゲームに対して当該実施要求の対象となる介入を実施する。決定部は、負荷指標が第１の負荷を示す場合には対価を第１の値に決定し、負荷指標が第１の負荷よりも重い第２の負荷を示す場合には対価を第１の値よりも高い第２の値に決定する。

本発明の別の態様に係るサーバは、算出部と、決定部と、送信部と、受信部と、介入部とを含む。算出部は、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。決定部は、ゲームのリアルタイムプレイ動画の観客がゲームに対して介入を実施するための所要人数を負荷指標に基づいて決定する。送信部は、所要人数を示す情報を観客の端末へ送信する。受信部は、端末から介入の実施要求を受信する。介入部は、所要人数以上の観客の端末から介入の実施要求が受信された場合に、ゲームに対して当該実施要求の対象となる介入を実施する。決定部は、負荷指標が第１の負荷を示す場合には所要人数を第１の値に決定し、負荷指標が第１の負荷よりも重い第２の負荷を示す場合には所要人数を第１の値よりも多い第２の値に決定する。

本発明によれば、ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入が短期間に集中することによる双方向的なゲーム体験の破綻を回避することができる。

実施形態に係る補助サーバを含む、ゲームのリアルタイムプレイ動画の配信システムの一例を示すブロック図。 図１の変形例を示す図。 図１中の補助サーバを例示するブロック図。 図２の補助サーバの対価決定に関する動作の概念図。 介入重みテーブルを例示する図。 オブジェクト重みテーブルを例示する図。 ある時点で観客に提示される対価を例示する図。 図７Ａとは別の時点で観客に提示される対価を例示する図。 図２の補助サーバの動作を例示するフローチャート。 実施形態の変形例において、ある時点で観客に提示される所要人数を例示する図。 実施形態の変形例において、図９Ａとは別の時点で観客に提示される所要人数を例示する図。

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

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

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

ここで、ゲームは、例えば人工生命体の育成ゲームであってもよい。この育成ゲームにおいて、プレイヤは、人工生命体をフィールドと呼ばれる仮想世界に移し、その生態や当該人工生命体が群れ（一族）を形成して他の群れと共存する様子などを鑑賞して楽しむことができる。プレイヤは、自己の所有する人工生命体の死亡やその所属する一族の滅亡を防ぐため、その一族を有利にするため、などの目的で、人工生命体のエネルギーを補充するためのアイテム（フード）やその他の効果のあるオブジェクトをフィールドに投下することができる。このシステムでは、プレイヤである配信者だけでなく、観客も補助サーバ４００を利用してこのような介入を実施して、プレイヤ（配信者）と一緒に好みの人工生命体やその所属する一族をサポートしたり、逆に敵対勢力の活動を邪魔したりすることができる。

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

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

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

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

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

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

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

補助サーバ４００は、観客端末３００およびゲームサーバ５００とネットワーク経由で接続している。補助サーバ４００は、観客端末３００から介入の実施要求を受信し、この要求に基づくイベントの発生要求をゲームサーバ５００へ送信する。イベントの発生要求は、例えば要求するイベントの種類を示すデータと、要求の主体である観客（以降、要求者と呼ぶ）を示すデータとを含み得る。以降の説明において、イベントおよびサブイベントは区別せず、いずれもイベントと称する。

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

なお、補助サーバ４００は、基本的に、観客端末３００からの介入の実施要求を条件付きで受け付ける。具体的には、補助サーバ４００は、介入対価（以降、対価と称する）の支払いを条件に観客によるゲームへの介入を許容してもよい。ここで、対価とは、現実の財貨によって表されてもよいし、動画配信システムにおいて使用可能な仮想的な財貨（ポイントを含む）によって表されてもよい。観客は、ゲームへの介入を実施したい場合には、観客端末３００に表示された対価の支払いに同意のうえ当該観客端末３００を操作して実施要求を発行する。補助サーバ４００は、観客端末３００から介入の実施要求を受信すると、当該要求の発行時に当該観客端末３００に表示されていた対価と引き替えに、ゲームに対して当該介入を実施する。なお、対価の決済処理は、補助サーバ４００が行ってもよいし、補助サーバ４００とは別の決済サーバが行ってもよい。

補助サーバ４００は、ゲームの実行に関わる負荷を示す負荷指標を算出し、当該負荷指標に基づいて対価を決定し、当該対価を示す情報を観客端末３００へ送信する。なお、ゲームの実行に関わる負荷の詳細については後述する。ここで、補助サーバ４００は、負荷指標の示す負荷が重いほど高くなるように対価を決定する。故に、負荷が重い時には介入がしづらくなるので、負荷のさらなる増大が抑制される。すなわち、プレイヤおよび観客の認知能力を超えてゲーム状態が複雑になることによる双方向的なゲーム体験の破綻、および／またはゲーム実行装置におけるゲームプログラムの実行負荷が過大になることを回避できる。他方、負荷が軽い時には介入がしやすくなるので、介入が話題作りの役割を果たし、観客間、または観客−配信者（プレイヤ）間のコミュニケーションが促進され、双方向性の高いゲーム体験を提供することが可能となる。例えば、観客からの介入が減って盛り上がりに欠ける場面で観客からの介入を呼び込めるので、プレイヤ／観客のプレイ／視聴のモチベーションを保ちやすくなる。また、介入を積極的にしたいが対価の支払いを節約したい観客を、負荷が小さいと期待されるプレイ動画、例えば観客数やコメント数の少ないプレイ動画へ誘導するという効果も期待できる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通信Ｉ／Ｆは、ネットワーク経由で、観客端末３００およびゲーム実行装置（図１の例ではゲームサーバ５００であり、図２の例では配信者端末６００である）と通信をするためのモジュールであり得る。例えば、通信Ｉ／Ｆは、観客端末３００から介入の実施要求を受信したり、この実施要求に基づくイベント発生要求などの種々の要求をゲーム実行装置へ送信したりする。また、通信Ｉ／Ｆは、ゲーム実行装置から、例えばゲームのプレイ画面に描画されるオブジェクト（の種類）を示すデータ（後述される）を受信し得る。

次に、図３を用いて補助サーバ４００の構成例の説明を続ける。図３の補助サーバ４００は、通信部４１０と、介入制御部４２０と、種々の記憶部とを含む。

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

受信部４１１は、観客端末３００から介入の実施要求を受信する。ここで、介入の実施要求は、例えば要求する介入の種類を示すデータと、当該要求の主体である観客（以降、要求者と呼ぶ）を示すデータと、当該要求の発行時に要求者の観客端末３００の画面に表示されていた対価、すなわち要求者が支払いに同意した対価を示すデータとを含み得る。以降の説明において、イベントおよびサブイベントは区別せず、いずれもイベントと称する。対価を示すデータは、当該対価または中間パラメータの値を直接的に示すものであってもよいし、いつ決定／通知された対価か、または何番目に決定／通知された対価かを示すものであってもよい。

また、受信部４１１は、ゲーム実行装置から、ゲームのプレイ画面に描画されるオブジェクトを示すデータを受信し得る。このデータは、例えば対象となるオブジェクトそれぞれの種類（或いは必要であれば個体）を識別する識別子であり得る。前述のように、オブジェクトは、キャラクタ、アイテム、背景、ビジュアルエフェクトなどを含み得る。さらに、受信部４１１は、図示されない決済サーバから対価の決済応答を受信し得る。決済応答は、決済が成功したか失敗したかを示すコードを含み得る。

受信部４１１は、これらの受信データを介入制御部４２０へ送る。具体的には、受信部４１１は、介入の実施要求を介入実施部４２１へ送り、オブジェクトを示すデータを負荷指標算出部４２３へ送り、決済応答を決済制御部４２２へ送る。

送信部４１２は、対価決定部４２４から対価を示す情報を受け取り、これを観客端末３００へ送る。かかる情報は、観客端末３００へ直接送信されてもよいし、動画配信サーバ２００などを経由して観客端末３００へ送信されてもよい。対価を示す情報の詳細は、後述されるが、個別の介入についての対価の値を示してもよいし、個別の介入についての対価を一意に算出するための中間パラメータの値を示してもよい。また、送信部４１２は、介入実施部４２１から介入の実施要求の受理／拒否を示す応答を受け取り、これを要求者の観客端末３００へ送ってもよい。

さらに、送信部４１２は、介入実施部４２１からゲーム実行装置に対する要求、例えばイベント発生要求を受け取り、これをゲーム実行装置へ送る。また、送信部４１２は、決済制御部４２２から対価の決済要求を受け取り、これを図示されない決済サーバへ送り得る。

介入制御部４２０は、前述のプロセッサおよびメモリであってよい。介入制御部４２０は、通信部４１０から、介入の実施要求、オブジェクトを示すデータ、対価の決済応答、などのデータを受け取る。また、介入制御部４２０は、種々の記憶部から必要なデータを読み出す。介入制御部４２０は、通信部４１０から受け取ったデータおよび／または種々の記憶部から読み出したデータに基づいて、介入を実施したり、対価を決定したり、図示されない決済サーバに対価の決済を要求したりする。さらに、介入制御部４２０は、ゲーム実行装置への種々の要求、決定した対価を示す情報、対価の決済要求、介入の実施要求の受理／拒否を示す応答、などの種々のデータを通信部４１０へ送る。具体的には、介入制御部４２０は、介入実施部４２１と、決済制御部４２２と、負荷指標算出部４２３と、対価決定部４２４とを含む。

介入実施部４２１は、受信部４１１から介入の実施要求を受け取ると、対価と引き替えにゲームに対して当該実施要求の対象となる介入を実施する。まず、介入実施部４２１は、対価の決済を行うために、介入の実施要求を決済制御部４２２へ送る。介入実施部４２１は、それから、決済制御部４２２から決済に失敗／成功したとの報告を受ける。

介入実施部４２１は、決済制御部４２２から決済に成功したとの報告を受けると、介入の実施要求に応じた要求、例えばイベントの発生要求を生成し、送信部４１２へ送る。また、介入実施部４２１は、介入が実施されることをその要求者に伝えるために、介入の実施要求の受理を示す応答を生成し、送信部４１２へ送ってもよい。さらに、後述されるように、受信済みの介入の実施要求の情報に基づいて負荷指標を算出する場合には、介入実施部４２１は、かかる情報を受信要求情報記憶部４３１に書き込む。

介入実施部４２１は、決済制御部４２２から決済に失敗したとの報告を受けると、介入を取り止める。また、介入実施部４２１は、介入が実施されないことをその要求者に伝えるために、介入の実施要求の拒否を示す応答を生成し、送信部４１２へ送ってもよい。ここで、決済の失敗には様々な理由が想定される。そこで、介入実施部４２１は、この応答に介入の実施要求が拒否された理由を示すデータを含めてもよい。例えば、決済の失敗を報告する場合に、要求者の保有する財貨が対価に満たない（すなわち残高不足）、実施要求に含まれるデータの示す対価（以降、申告対価と称する）が不正である、などの理由が想定される。これらの理由は、決済制御部４２２が決済の失敗と一緒に介入実施部４２１へ報告し得る。

決済制御部４２２は、介入実施部４２１から介入の実施要求を受け取る。決済制御部４２２は、対価記憶部４３３からこの実施要求の対象となる介入の対価の履歴を読み出し、この実施要求の申告対価が適正であるか否かを判定する。例えば、申告対価が、過去に決定されたいずれの対価とも一致しない場合や、古すぎる場合（例えば２つ以上前に決定された対価である場合、所定時間以上前に決定された対価である場合、など）には、決済制御部４２２は、申告対価が不正であるため決済に失敗したと介入実施部４２１に報告してもよい。

他方、決済制御部４２２は、申告対価が適正であると判定した場合には、当該申告対価の決済を図示されない決済サーバに要求してもよい。具体的には、決済制御部４２２は、対価の決済要求を送信部４１２へ送り、そして、受信部４１１からこの決済要求に対する決済応答を受け取ってもよい。そして、決済制御部４２２は、決済応答に基づいて決済に成功したか失敗したかを判定し、その結果を介入実施部４２１に報告してもよい。

なお、決済処理は、決済サーバの代わりに補助サーバ４００またはその他のサーバによって行われてもよい。

負荷指標算出部４２３は、（１）負荷指標を算出する以前の単位期間内に受信済みの介入の実施要求の情報（以降、単に受信要求情報と称する）、および（２）負荷指標を算出する以前のある時点においてゲームのプレイ画面に描画されるオブジェクト、のうちの一方または両方に基づいて、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。このほか、重み記憶部４３２は、ゲーム実行装置から例えば、ＣＰＵ使用率、メモリ使用量などの情報を取得し、当該情報を考慮して負荷指標を算出してもよい。負荷指標算出部４２３は、算出した負荷指標を対価決定部４２４へ送る。

負荷指標算出部４２３は、負荷の短期間の変動に対価を追従させるために、負荷指標を周期的に、例えば数十秒おき、数分おき、程度に算出してもよい。なお、周期は、固定であってもよいし、可変であってもよい。この周期は、上記単位期間と一致してもよいし、しなくてもよい。

ここで、負荷、とは、ゲーム実行装置におけるゲームプログラムの実行負荷と捉えることもできるが、プレイヤおよび観客のゲーム状態の認知負荷と捉えることもできる。前者の負荷は、ゲーム実行装置のハードウェア能力の増強により、殆ど問題とならなくなる可能性もある。他方、人間のゲーム状態に関する認知能力は本人の情報処理能力や当該ゲームのプレイ経験に応じてある程度異なると考えられるものの、生理的な限界は存在する。故に、ゲーム実行装置のハードウェア能力が十分に高い場合であっても、後者の負荷が過度に大きくならないように、観客の介入に歯止めをかけることには意義がある。

まず、上記（１）の場合の負荷指標算出部４２３の動作について説明する。負荷指標算出部４２３は、受信要求情報記憶部４３１から受信要求情報を受け取る。ここで、受信要求情報は、例えば、（１−１）単位期間内に受信された介入の実施要求の数をカウントした値であってもよいし、（１−２）単位期間内に受信された介入の実施要求それぞれの対象となる介入の種類を示すデータであってもよい。

上記（１−１）について、負荷指標算出部４２３は、実施要求の数をそのまま負荷指標としてもよいし、または何らかの数式に代入して負荷指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。実施要求の数が多いほどより多くの介入がゲームに対して実施されるので、負荷指標算出部４２３は、より重い負荷を示す負荷指標を算出する。

上記（１−２）について、負荷指標算出部４２３は、実施要求のそれぞれに割り当てられた介入重みを重み記憶部４３２から読み出す。この介入重みは、実施要求の対象となる介入の種類毎に予め定義されて、介入の種類に対応付けて重み記憶部４３２に保存されている。故に、負荷指標算出部４２３は、受信要求情報の示す各実施要求の介入の種類をキーとして、当該実施要求に割り当てられた介入重みを重み記憶部４３２から読み出すことができる。重み記憶部４３２は、介入重みの総和を負荷指標としてもよいし、または他の何らかの数式に代入して負荷指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。

ここで、介入重みは、例えば、より重い負荷を生じさせる介入にはより大きな値が定義されてよい。例えば、第１の種類の介入の実施により生じる負荷は、第２の種類の介入の実施により生じる負荷よりも重いとする。この場合に、第１の種類の介入の実施要求に割り当てられる介入重みは、第２の種類の介入の実施要求に割り当てられる介入重みに比べて大きく定義され得る。実施要求に割り当てられた重みが大きいほどゲームに対してより重い負荷の介入が実施されるので、負荷指標算出部４２３は、より重い負荷を示す負荷指標を算出する。

介入の種類とその介入重みとを対応付ける介入重みテーブルの一例を図５に示す。図５において、介入重みは、３（最高）から１（最低）までの３段階で付与されている。故に、単位期間内に、「フード（低価値）をフィールドに投下する」ことの実施要求（介入重み１）と、「オブジェクト（高価値）をフィールドに投下する」ことの実施要求（介入重み２）と、「新しい人工生命体をフィールドに投下する」ことの実施要求（介入重み３）とが受信されたとすれば、負荷指標算出部４２３は、例えばこれらの総和である「６」を負荷指標として算出してもよい。なお、図５は例示に過ぎないので、介入重みを図５と異なるように割り当てることも可能である。

次に、上記（２）の場合の負荷指標算出部４２３の動作について説明する。負荷指標算出部４２３は、受信部４１１から、ある時点においてゲームのプレイ画面に描画されるオブジェクトを示すデータを受け取る。そして、負荷指標算出部４２３は、オブジェクトのそれぞれに割り当てられたオブジェクト重みを重み記憶部４３２から読み出す。このオブジェクト重みは、オブジェクトの種類（または個体）毎に予め定義されて、オブジェクトに対応付けて重み記憶部４３２に保存されている。故に、負荷指標算出部４２３は、受信部４１１から受け取ったデータの示すオブジェクトの種類をキーとして、当該オブジェクトに割り当てられたオブジェクト重みを重み記憶部４３２から読み出すことができる。重み記憶部４３２は、オブジェクト重みの総和を負荷指標としてもよいし、または他の何らかの数式に代入して負荷指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。

ここで、オブジェクト重みは、例えば、より重い負荷を生じさせるオブジェクトにはより大きな値が定義されてよい。例えば、ゲームのプレイ画面にある第１の種類のオブジェクトが存在することで生じる負荷（例えば、管理／描画負荷であってもよいし、人間の認知負荷であってもよい）は、同画面に第２の種類のオブジェクトが存在することで生じる負荷よりも重いとする。この場合に、第１の種類のオブジェクトに割り当てられるオブジェクト重みは、第２の種類のオブジェクトに割り当てられるオブジェクト重みに比べて大きく定義され得る。オブジェクトに割り当てられた重みが大きいほどゲームのプレイ画面の管理／描画／認知負荷が重くなるので、負荷指標算出部４２３は、より重い負荷を示す負荷指標を算出する。

オブジェクトの種類とそのオブジェクト重みとを対応付けるオブジェクト重みテーブルの一例を図６に示す。図６において、オブジェクト重みは、５（最高）から１（最低）までの５段階で付与されている。故に、ある時点のゲームのプレイ画面に、２体の「プレイヤキャラクタ」（オブジェクト重み５）と、１体の「エネミーキャラクタ」（オブジェクト重み５）と、１つのアイテム（低価値）（オブジェクト重み１）とが描画されるとすれば、負荷指標算出部４２３は、例えばこれらの総和である「１６」を負荷指標として算出してもよい。なお、図６は例示に過ぎないので、オブジェクト重みを図６と異なるように割り当てることも可能である。

対価決定部４２４は、負荷指標算出部４２３から負荷指標を受け取り、これに基づいて対価を算出する。具体的には、対価決定部４２４は、負荷指標の示す負荷が重いほど高くなるように対価を決定する。例えば、負荷指標が第１の負荷を示す場合には対価を第１の値に決定し、負荷指標が第１の負荷よりも重い第２の負荷を示す場合には対価を第１の値よりも高い第２の値に決定してもよい。対価決定部４２４は、例えば、負荷指標の示す負荷の増加に対して単調増加するように（すなわち負荷の増加に対して減少しないように）対価を決定してもよい。なお、対価は、負荷の重さに対して線形に増加してもよいし、非線形（例えばステップ状）に増加してもよい。対価決定部４２４は、決定した対価を示す情報を送信部４１２へ送り、さらに対価記憶部４３３に書き込む。

対価決定部４２４は、負荷指標に基づいて、介入の種類毎に対価を個別に決定してもよいが、代わりに、介入の種類間で共通の変動比率を決定してもよい。この変動比率は、対価の中間パラメータに相当する。この場合に、介入の種類毎の対価は、当該種類に予め定義された基準対価にこの変動比率をそれぞれ乗じることで一意に導出可能である。これにより、対価を更新する度に全種類の対価を通知せずとも変動比率を通知するだけで、観客端末３００は全種類の対価について最新の値を表示できる（ただし、観客端末３００において基準対価は既知であるとする）。これは、対価を示す情報の通知に関するオーバーヘッドの削減に寄与する。また、新たな種類の介入がゲームプログラムのアップデートなどにより追加される場合であっても、当該介入の対価を決定するための追加のプログラムコードを作成する必要はなく、新たな基準対価を定義するだけで済む。

前述のように負荷指標算出部４２３が負荷指標を周期的に算出する場合には、対価決定部４２４も対価を周期的に決定してもよい。これにより、送信部４１２は対価を示す情報を観客端末３００へ繰り返し送信し、観客端末３００はかかる情報を受信する度に最新の対価を画面に表示できる。例えば、観客端末３００の画面に、ある時には図７Ａのような画面が表示され、別の時には図７Ｂのような画面が表示されるとする。これらは、いずれも、介入の実施要求を発行するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）部品（ウィジェット）として介入ボタンを含む介入メニュー画面を表す。図７Ａおよび図７Ｂにおいて、介入ボタンは、実施要求を発行する対象となる介入と、その介入を実施するための対価とをそれぞれ示す。図７Ａの例では、図７Ｂの例に比べて、それぞれの介入の対価が割安であることが看取できる。このように、観客は、対価の変動を見守りながら、自らが介入するタイミングを判断することができる。

ただし、観客端末３００が対価を示す情報を受信する度に最新の対価を画面に表示することは必須ではない。例えば、ゲームのリアルタイムプレイ動画を表示するページと、介入メニュー画面を表示するページとが異なっている場合には、観客が観客端末３００を操作して後者の画面に遷移した時に受信済みの情報に基づいて最新の対価が表示されるようにしてもよい。また、補助サーバ４００が対価を決定する度に全ての観客端末３００に即時にこの対価を通知することも必須ではない。すなわち、観客が観客端末３００を操作して介入メニュー画面を表示するページ画面に遷移した時に、観客端末３００が対価の取得要求を補助サーバ４００へ送信し、補助サーバ４００がこれに応じて最新の対価を示す情報を返送するようにしてもよい。

ここで、図４を用いて、補助サーバ４００が対価の決定に関してどのように動作するかを概念的に説明する。図４の例では、負荷指標算出部４２３は、上記（１−１）の例に従って、負荷指標を算出することとする。

受信部４１１は、単位期間Ｔ１に介入の実施要求を１つ受信する。負荷指標算出部４２３は、単位期間Ｔ１の終了後に、当該単位期間Ｔ１における要求受信数（１）に基づいて負荷指標を算出する。そして、対価決定部４２４は、この負荷指標に基づいて、対価の変動比率ｒを１に決定する。この変動比率を示す情報が観客端末３００に通知され、観客端末３００は通知された変動比率に基づいて対価を再計算し、画面上に最新の対価（１００Ｐ）を表示する。

同様に、受信部４１１は、単位期間Ｔ２に介入の実施要求を３つ受信する。負荷指標算出部４２３は、単位期間Ｔ２の終了後に、当該単位期間Ｔ２における要求受信数（３）に基づいて負荷指標を算出する。そして、対価決定部４２４は、この負荷指標に基づいて、対価の変動比率ｒを３に決定する。この変動比率を示す情報が観客端末３００に通知され、観客端末３００は通知された変動比率に基づいて対価を再計算し、画面上に最新の対価（３００Ｐ）を表示する。

図３の例において種々の記憶部は、受信要求情報記憶部４３１と、重み記憶部４３２と、対価記憶部４３３とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

受信要求情報記憶部４３１は、受信要求情報を保存する。受信要求情報は、介入実施部４２１によって書き込まれ、または書き換えられる。また、受信要求情報は、負荷指標算出部４２３によって読み出される。ただし、受信要求情報を負荷指標の算出において全く利用しないことも可能である（上記（２）の例）。この場合には、受信要求情報記憶部４３１は削除され得る。

重み記憶部４３２は、例えば図５に示した介入重みテーブルの形式で、介入の種類に対応付けて介入重みを保存し、および／または、例えば図６に示したオブジェクト重みテーブルの形式で、オブジェクトの種類（または個体）に対応付けてオブジェクト重みを保存する。介入重みおよび／またはオブジェクト重みは、例えば補助サーバ４００のプログラムのインストールまたはアップデート時に重み記憶部４３２に書き込まれ、または書き換えられ得る。介入重みおよび／またはオブジェクト重みは、負荷指標算出部４２３によって読み出される。

ただし、介入重みおよびオブジェクト重みの一方または両方を負荷指標の算出において全く利用しないことも可能である。例えば、介入重みは上記（１−２）の例以外では不要となり得るし、オブジェクト重みは上記（２）の例以外では不要となり得る。また、上記（１−１）の例では、介入重みおよびオブジェクト重みの両方が不要となり得る。この場合には、重み記憶部４３２は削除され得る。

対価記憶部４３３は、対価を示す情報を保存する。具体的には、対価記憶部４３３は、対価を示す情報に関連付けて、当該対価がいつ決定されたか、または何番目に決定されたかを示す情報も保存し得る。これらの情報は、決済制御部４２２が、申告対価が不正でないことを検査するために必要となり得る。対価を示す情報は、対価決定部４２４によって書き込まれ、または書き換えられ得る。対価を示す情報は、決済制御部４２２によって読み出される。

次に、図８を用いて、１つの単位期間についての補助サーバ４００の動作例を説明する。なお、図８の例では、負荷指標算出部４２３は、上記（１）の例に従って、負荷指標を算出することとする。

まず、受信部４１１は観客端末３００から介入の実施要求を受信すると（ステップＳ７０１）、介入実施部４２１は、決済制御部４２２と連携して、当該実施要求の対象となる介入を実施する（ステップＳ７０２）。ただし、介入実施部４２１は、対価の決済の成否次第で、実施要求を拒否し得る。かかる処理が単位期間の満了まで繰り返され（ステップＳ７０３）、処理はステップＳ７０４へ進む。他方、次の単位期間について図８の動作が並列的に開始し得る。すなわち、介入実施部４２１は、次の単位期間に受信した実施要求の対象となる介入を実施し始める。

ステップＳ７０４において、負荷指標算出部４２３は、この単位期間に受信した介入の実施要求に基づいて、負荷指標を算出する。次に、対価決定部４２４は、ステップＳ７０４において算出された負荷指標に基づいて対価を決定する（ステップＳ７０５）。次に、送信部４１２は、ステップＳ７０５において決定された対価を示す情報を観客端末３００へ送信する（ステップＳ７０６）。

以上説明したように、実施形態に係る補助サーバは、ゲームの実行に関わる負荷を示す負荷指標を算出し、当該負荷指標に基づいて対価を決定し、当該対価を示す情報を観客端末へ送信する。より具体的には、補助サーバは、負荷指標の示す負荷が重いほど高くなるように対価を決定する。故に、負荷が重い時には介入がしづらくなるので、負荷のさらなる増大が抑制される。すなわち、プレイヤおよび観客の認知能力を超えてゲーム状態が複雑になることによる双方向的なゲーム体験の破綻、および／またはゲーム実行装置におけるゲームプログラムの実行負荷が過大になることを回避できる。他方、負荷が軽い時には介入がしやすくなるので、介入が話題作りの役割を果たし、観客間、または観客−配信者（プレイヤ）間のコミュニケーションが促進され、双方向性の高いゲーム体験を提供することが可能となる。例えば、観客からの介入が減って盛り上がりに欠ける場面で観客からの介入を呼び込めるので、プレイヤ／観客のプレイ／視聴のモチベーションを保ちやすくなる。また、介入を積極的にしたいが対価の支払いを節約したい観客を、負荷が小さいと期待されるプレイ動画、例えば観客数やコメント数の少ないプレイ動画へ誘導するという効果も期待できる。

（変形例）
上記実施形態では、補助サーバは、負荷指標の示す負荷が重いほど高くなるように対価を決定する。ところで、介入に課される条件は対価に限られない。例えば、観客が○○人、この介入の実施を要求した場合に当該介入を実施する、というように、対価の代わりに介入を実施するための所要人数を条件としてもよい。本変形例では、対価の代わりにこの所要人数を変動させる。

すなわち、変形例に係る補助サーバは、対価決定部４２４の代わりに図示されない所要人数決定部を備えている。そして、この所要人数決定部は、負荷指標の示す負荷が重いほど多くなるように所要人数を決定する。例えば、負荷指標が第１の負荷を示す場合には所要人数を第１の値に決定し、負荷指標が第１の負荷よりも重い第２の負荷を示す場合には所要人数を第１の値よりも多い第２の値に決定してもよい。

また、変形例に係る補助サーバにおいて、送信部４１２は、対価の代わりに所要人数を示す情報を観客端末３００へ送信することになる。この結果、例えば、観客端末３００の画面に、ある時には図９Ａのような画面が表示され、別の時には図９Ｂのような画面が表示されるとする。これらは、いずれも介入メニュー画面を表す。図９Ａおよび図９Ｂにおいて、介入ボタンは、実施要求を発行する対象となる介入と、その介入を実施するための所要人数とをそれぞれ示す。

さらに、変形例に係る補助サーバにおいて、決済に関する機能部、例えば決済制御部４２２は不要となり得る。また、介入実施部４２１は、受信部４１１によって、所要人数以上の観客端末３００から介入の実施要求が受信された場合に、ゲームに対して当該実施要求の対象となる介入を実施することになる。

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

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

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

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

１００，６００・・・配信者端末
２００・・・動画配信サーバ
３００・・・観客端末
４００・・・補助サーバ
４１０・・・通信部
４１１・・・受信部
４１２・・・送信部
４２０・・・介入制御部
４２１・・・介入実施部
４２２・・・決済制御部
４２３・・・負荷指標算出部
４２４・・・対価決定部
４３１・・・受信要求情報記憶部
４３２・・・重み記憶部
４３３・・・対価記憶部
５００・・・ゲームサーバ

Claims (11)

1. プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する算出部と、
   前記ゲームのリアルタイムプレイ動画の観客が前記ゲームに対して介入を実施するための対価を前記負荷指標に基づいて決定する決定部と、
   前記対価を示す情報を前記観客の端末へ送信する送信部と、
   前記端末から前記介入の実施要求を受信する受信部と、
   前記介入の実施要求が受信された場合に、前記対価と引き替えに前記ゲームに対して当該実施要求の対象となる介入を実施する介入部と
   を具備し、
   前記決定部は、前記負荷指標が第１の負荷を示す場合には前記対価を第１の値に決定し、前記負荷指標が前記第１の負荷よりも重い第２の負荷を示す場合には前記対価を前記第１の値よりも高い第２の値に決定する、
   サーバ。
2. 前記算出部は、前記負荷指標を算出する以前の単位期間内に受信された前記実施要求に基づいて、前記負荷指標を算出する、請求項１に記載のサーバ。
3. 前記算出部は、前記単位期間に受信された前記実施要求の数に基づいて、前記負荷指標を算出する、請求項２に記載のサーバ。
4. 前記算出部は、前記単位期間に受信された前記実施要求に割り当てられた介入重みに基づいて、前記負荷指標を算出する、
   前記介入重みは、前記実施要求の対象となる介入の種類毎に予め定義される、
   請求項２に記載のサーバ。
5. 第１の種類の介入の実施要求に割り当てられる前記重みは、第２の種類の介入の実施要求に割り当てられる前記重みに比べて大きく、
   前記第１の種類の介入の実施により生じる負荷は、前記第２の種類の介入の実施により生じる負荷よりも重い、
   請求項４に記載のサーバ。
6. 前記算出部は、前記負荷指標を算出する以前のある時点において前記ゲームのプレイ画面に描画されるオブジェクトに割り当てられたオブジェクト重みに基づいて、前記負荷指標を算出し、
   前記オブジェクト重みは、前記オブジェクトの種類毎に予め定義される、
   請求項１に記載のサーバ。
7. 前記算出部は、前記負荷指標を周期的に算出し、
   前記決定部は、前記対価を前記負荷指標に基づいて周期的に決定し、
   前記送信部は、前記端末へ前記対価を示す情報を周期的に送信し、
   前記端末は、前記対価を示す情報を受信する度に最新の対価を画面に表示する、
   請求項１に記載のサーバ。
8. 前記決定部は、前記対価の中間パラメータである変動比率を前記負荷指標に基づいて決定し、
   前記送信部は、前記端末に、前記対価を示す情報として前記変動比率を送信し、
   前記対価は、当該対価に対応する介入の種類に対して予め定義された基準対価に前記変動比率を乗じた値である、
   請求項１に記載のサーバ。
9. プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する算出部と、
   前記ゲームのリアルタイムプレイ動画の観客が前記ゲームに対して介入を実施するための所要人数を前記負荷指標に基づいて決定する決定部と、
   前記所要人数を示す情報を前記観客の端末へ送信する送信部と、
   前記端末から前記介入の実施要求を受信する受信部と、
   前記所要人数以上の観客の端末から前記介入の実施要求が受信された場合に、前記ゲームに対して当該実施要求の対象となる介入を実施する介入部と
   を具備し、
   前記決定部は、前記負荷指標が第１の負荷を示す場合には前記所要人数を第１の値に決定し、前記負荷指標が前記第１の負荷よりも重い第２の負荷を示す場合には前記所要人数を前記第１の値よりも多い第２の値に決定する、
   サーバ。
10. コンピュータを、
    プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する手段、
    前記ゲームのリアルタイムプレイ動画の観客が前記ゲームに対して介入を実施するための対価を前記負荷指標に基づいて決定する手段、
    前記対価を示す情報を前記観客の端末へ送信する手段、
    前記端末から前記介入の実施要求を受信する手段、
    前記介入の実施要求が受信された場合に、前記対価と引き替えに前記ゲームに対して当該実施要求の対象となる介入を実施する手段
    として機能させるためのプログラムであって、
    前記決定する手段は、前記負荷指標が第１の負荷を示す場合には前記対価を第１の値に決定し、前記負荷指標が前記第１の負荷よりも重い第２の負荷を示す場合には前記対価を前記第１の値よりも高い第２の値に決定する、
    プログラム。
11. コンピュータを、
    プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する手段、
    前記ゲームのリアルタイムプレイ動画の観客が前記ゲームに対して介入を実施するための所要人数を前記負荷指標に基づいて決定する手段、
    前記所要人数を示す情報を前記観客の端末へ送信する手段、
    前記端末から前記介入の実施要求を受信する手段、
    前記所要人数以上の観客の端末から前記介入の実施要求が受信された場合に、前記ゲームに対して当該実施要求の対象となる介入を実施する手段
    として機能させるためのプログラムであって、
    前記決定する手段は、前記負荷指標が第１の負荷を示す場合には前記所要人数を第１の値に決定し、前記負荷指標が前記第１の負荷よりも重い第２の負荷を示す場合には前記所要人数を前記第１の値よりも多い第２の値に決定する、
    プログラム。