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

Abstract

【課題】コンテンツに対する投げ銭などの発生数を適正化する。【解決手段】本発明の一態様によれば、サーバは、算出部と、決定部と、投入実施部とを含む。算出部は、コンテンツに対するアイテム投入の活発さの予測値に相当する指標を算出する。決定部は、コンテンツの観客がコンテンツに対してアイテム投入を実施するための対価を指標に基づいて決定する。投入実施部は、アイテム投入の実施要求が受信された場合に、対価と引き替えに実施要求の対象となるアイテムの画像をコンテンツに重畳させる。決定部は、指標が第１の予測値に相当する場合には対価を第１の値に決定し、指標が第１の予測値よりもコンテンツに対するアイテム投入が活発であることに対応する第２の予測値に相当する場合には対価を第１の値よりも高い第２の値に決定する。【選択図】 図１

Description

本発明は、コンテンツ配信に関する。

従来、動画などのコンテンツの生放送（配信）サービスでは、観客がコメントを投稿し、配信者が投稿されたコメントに反応するという双方向的な視聴体験が可能である。また近年、いわゆる投げ銭機能を実装した生放送サービスも提案されている。

例えば特許文献１では、動画などのコンテンツの共有サービスを提供する情報提供システムにおいて、コンテンツの演者に対する祝儀や差し入れなどに相当する機能を提供することが提案されている。

特開２０１２−１２００９８号公報

投げ銭機能を実装することで、配信者にコンテンツを作成するインセンティブを与えることが可能となる。また、観客が支払った対価に対応するアイコンに加えて観客の名前（ニックネーム）やコメントなどをコンテンツに重畳して表示することで、投げ銭機能は、配信者が投げ銭を行った観客にお礼を言う、他の観客が高額な投げ銭に反応する、などの双方向的なコミュニケーションの形成にも寄与する。さらに、投げ銭を行った観客からすれば、自分がいくらの投げ銭を行ったかを配信者や他の観客にアピールすることもできる。すなわち、投げ銭機能は、観客の自己顕示欲を刺激するという側面もある。

しかしながら、例えば人気コンテンツにおいて多数の観客が同時多発的に投げ銭を要求し、これにより配信者および観客の認知能力を超える数のアイコンなどを短期間に集中して表示すれば、配信者も観客も誰がいくらの投げ銭を行ったのかを把握することが困難となり、前述の双方向的なコミュニケーションが阻害され得る。また、投げ銭を行った観客は、対価を支払ったにも関わらず期待したほどの注目を集められず不満を感じるかもしれない。これは、投げ銭機能への不信、ひいては利用の低迷につながる可能性がある。また、投げ銭が集中することにより、コンテンツがアイコンなどに遮蔽され見辛くなる、アイコンなどの表示による処理負荷が重くなる、などの問題もある。

観客が投げ銭を行うためのハードル、例えば最低金額を高額に設定すれば、投げ銭の集中が緩和する可能性はある。しかしながら、このハードルを過度に高く設定すると、観客は気軽に投げ銭を行うことができなくなるため、投げ銭機能の利用が想定を超えて低調となる可能性がある。他方、このハードルを過度に低く設定すると、投げ銭の集中が殆ど緩和されない可能性がある。なお、かかる問題は、投げ銭のような配信者に財貨を還元する仕組みの有無に関わらず、例えば観客が対価と引き替えにコンテンツを装飾するような拡張機能全般にあてはまる。

本発明は、コンテンツに対する投げ銭などの発生数を適正化することを目的とする。

本発明の一態様によれば、サーバは、算出部と、決定部と、投入実施部とを含む。算出部は、コンテンツに対するアイテム投入の活発さの予測値に相当する指標を算出する。決定部は、コンテンツの観客がコンテンツに対してアイテム投入を実施するための対価を指標に基づいて決定する。投入実施部は、アイテム投入の実施要求が受信された場合に、対価と引き替えに実施要求の対象となるアイテムの画像をコンテンツに重畳させる。決定部は、指標が第１の予測値に相当する場合には対価を第１の値に決定し、指標が第１の予測値よりもコンテンツに対するアイテム投入が活発であることに対応する第２の予測値に相当する場合には対価を第１の値よりも高い第２の値に決定する。

本発明によれば、コンテンツに対する投げ銭などの発生数を適正化することができる。

実施形態に係る投入制御サーバを例示するブロック図。 図１の投入制御サーバを含む、動画生放送システムを例示するブロック図。 図１の投入制御サーバにおける対価決定に関する動作の概念図。 図２の動画生放送システムにおいて観客端末に表示される動画視聴ページを例示する図。 図４の投入アイコンを選択した場合の遷移先である投入アイテムメニューページを例示する図。 図５のアイテムアイコンが選択されたことをトリガとしてポップアップする投入確認ウィンドウを例示する図。 図５の投入履歴ボタンが選択された場合の表示される投入履歴を例示する図。 図１の投入制御サーバの動作を例示するフローチャート。

以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。

なお、実施形態の説明では、コンテンツとして生放送動画を仮定するが、コンテンツは動画以外の生放送コンテンツ（例えば、静止画、テキスト、など）、または変形例において説明するように予め蓄積されたコンテンツ（以降、アーカイブコンテンツと称する）であってもよい。また、実施形態の説明では、いわゆる投げ銭機能を包含する機能として「アイテム投入」という表現を用いる。これは、観客がアイテムを選んで対価を支払うことで、選んだアイテムを生放送動画（コンテンツ）に重畳して表示する機能を意味する。観客がアイテム投入のために支払った対価の一部は、従来の投げ銭機能のように生放送動画の配信者に還元されてもよいし、されなくてもよい（単なる動画の盛り上げ効果に留めてもよい）。ここで、対価とは、現実の財貨によって表されてもよいし、動画生放送システムにおいて使用可能な仮想的な財貨（ポイントを含む）によって表されてもよい。

また、生放送動画とは、動画ソース（例えば、配信者端末）から生放送サーバへのアップロードと、その配信とがリアルタイムに行われる動画全般を指しており、その種類は特に限定されない。具体的には、生放送動画は、配信者による単なる撮影動画（例えば、自撮り動画、定点カメラの映像、ドライブレコーダーの映像、など）、配信者の実演（例えば、配信者による、歌唱、ダンスなどのパフォーマンス、ゲームプレイ、トーク、など）を撮影した動画、配信者が例えばゲームなどの対象について実況／解説を行う実況動画、配信者の分身であるアバターが存在する仮想空間の映像を仮想カメラにより撮影したＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）動画、などであり得る。

（実施形態）
実施形態に係る投入制御サーバは、図２に例示される、動画生放送システムに組み込むことができる。このシステムは、実施形態に係る投入制御サーバ１００と、配信者端末２００と、生放送サーバ３００と、観客端末４００と、決済サーバ５００と、保有資産管理サーバ６００と、コメントサーバ７００とを含む。各種サーバは、各種端末と例えばインターネットなどのネットワーク経由で接続されており、互いにデータを送受信し得る。また、各種サーバは、他のサーバともネットワーク経由で接続されており、互いにデータを送受信し得る。

配信者端末２００は、逐次、例えば配信者端末２００に接続されたカメラ／マイクロフォンによって生成された画像／音声データをエンコードし、エンコード済み（マルチメディア）データを生放送サーバ３００へ送信（アップロード）する。

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

生放送サーバ３００は、配信者端末２００からエンコード済みデータを受信し、これに対して、例えば、投入制御サーバ１００によって投入を要求されたアイテムの画像などの重畳、再エンコード、ＨＬＳ（ＨＴＴＰ （Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）形式への変換、などの加工を必要に応じて行う。ここで、アイテム画像に加えて、アイテム投入を要求した観客（投入要求者）の名前（ニックネーム）および／または投入要求者からのコメントが重畳されてもよい。生放送サーバ３００は、（加工後の）エンコード済みデータを配信者端末２００および観客端末４００へ配信する。

また、生放送サーバ３００は、投入制御サーバ１００へ、生放送動画の同時視聴者数、生放送動画の配信者の属性（例えば、フォロワー数、有料チャンネル会員数、レベル、など）、生放送動画の観客の属性（例えば、視聴中の生放送動画の配信者をフォローしているかどうか、この配信者の有料チャンネル会員であるかどうか、生放送システムのプレミアムサービスプランの加入者であるか否か、など）のデータを送信し得る。ここで、レベルとは、配信者の動画生放送システムにおける活動実績によって決まる値であってよく、例えば配信者のフォロワーのうち特定の属性を持つ者、例えば上記プレミアムサービスプランの加入者の数によって決まる値であり得る。

観客端末４００は、生放送サーバ３００からエンコード済みデータを受信し、これを復号し、生放送動画（音声を含む）を再生する。観客端末４００は、逐次、コメントサーバ７００から生放送動画に対して当該観客端末４００を操作するユーザまたはその他の観客によって投稿されたコメントデータを受信し、当該コメントデータの示すコメントを生放送動画に重畳して表示する。コメントは、生放送動画の表示領域の右端から左端に向かって移動するように所定時間に亘って表示されてよい。他方、観客端末４００は、ユーザからの操作入力に基づいて生放送動画に投稿するコメントデータを生成し、コメントサーバ７００へ送信し得る。

また、観客端末４００は、ユーザからの操作入力に基づいて生放送動画に対するアイテム投入の実施要求を発行し、投入制御サーバ１００へ送信する。さらに、観客端末４００は、ユーザからの操作入力に基づいて、当該観客端末４００のユーザの識別子に関連付けられた保有資産データの閲覧要求などを発行し、保有資産管理サーバ６００へ送信することもできる。

観客端末４００は、配信者端末２００と同様の電子デバイスであり得る。ただし、観客端末４００は、画像／音声データを取り込んだり、これをエンコードしたりする能力は必要とされない。他方、配信者端末２００は、観客端末４００と同様に、生放送動画の再生、コメントの投稿・閲覧、当該配信者端末２００のユーザの識別子に関連付けられた保有資産データの閲覧などが可能である。

決済サーバ５００は、主に投入制御サーバ１００からの決済要求に応じて、ユーザ、すなわち配信者または観客の保有資産に対する決済処理を行う。例えば決済サーバ５００は、投入制御サーバ１００からアイテム投入に関する決済要求を受信すると、この決済要求から投入要求者の識別子と、アイテム投入の対価を表すデータとを抽出する。そして、決済サーバ５００は、保有資産管理サーバ６００にアクセスし、観客の識別子に対応付けられる保有資産データを、アイテム投入の対価に対応する価値、例えば金額またはポイント分減るように更新する。また、決済サーバ５００は、保有資産管理サーバ６００にアクセスし、アイテム投入の対象となった動画の配信者の識別子（これは、決済要求に含まれ得る）に対応付けられる保有資産データを、アイテム投入の対価に対応する価値の一部相当分増えるように更新してもよい。これにより、観客の支払った対価の一部が配信者に還元されることになる（投げ銭機能に相当）。

決済サーバ５００は、決済が成功したか否かを表すコードを含み得る決済応答を投入制御サーバ１００に返す。このほか、決済サーバ５００は、配信者端末２００または観客端末４００からの要求に応じて、かかる要求の発行を指示したユーザの保有資産への入金処理（すなわち、保有資産の残高を増やす処理）を行ってもよい。

保有資産管理サーバ６００は、ユーザ、すなわち配信者または観客の識別子に、当該ユーザの保有資産データを関連付けて保存するデータベースサーバである。保有資産管理サーバ６００は、決済サーバ５００からの要求に応じて、ユーザの保有資産データを更新、すなわち増やしたり減らしたりする。また、保有資産管理サーバ６００は、配信者端末２００または観客端末４００からの要求に応じて、かかる要求の発行を指示したユーザに保有資産データを閲覧させる。具体的には、保有資産管理サーバ６００は、保有資産データの閲覧要求を受信すると、当該閲覧要求の発行を指示したユーザの保有資産データを、閲覧要求の送信元となる配信者端末２００または観客端末４００へ返す。

コメントサーバ７００は、配信者端末２００または観客端末４００から生放送中の動画に対するコメントデータを受信し、これを逐次、同動画を受信中の配信者端末２００または観客端末４００へ送信する。これにより、配信者および観客は、動画の生放送中であってもテキストベースでコミュニケーションを取ることが可能となる。

投入制御サーバ１００は、観客端末４００から生放送動画に対するアイテム投入の実施要求を受信すると、決済サーバ５００へアクセスし、この実施要求に基づく決済処理を行う。投入制御サーバ１００は、決済が成功した場合には、アイテム投入要求を生放送サーバ３００へ送信する。アイテム投入要求は、例えば、投入の対象となるアイテムを識別する識別子と、投入要求者である観客を識別する識別子とを含み得る。さらに、この要求は、オプションとして、投入要求者が支払った対価を示すデータ、投入要求者である観客からのコメントデータ、などをさらに含んでもよい。

投入制御サーバ１００は、アイテム投入の対価を固定せずに可変とする。具体的には、投入制御サーバ１００は、生放送動画に対するアイテム投入の活発さの予測値に相当する指標を算出し、当該指標に基づいて対価を決定する。そして、投入制御サーバ１００は、決定した対価を示す通知データを生成してこれを観客端末４００へ送信する。

指標の詳細は後述するが、投入制御サーバ１００は、例えば、動画の同時視聴者数、アイテム投入要求の受信状況、配信者／観客の属性、などから動画に対して近い将来にどれくらいのアイテム投入が行われるか、ひいてはそれによってどれくらいのアイテム画像などが動画に重畳されるかをある程度予測できる。例えば、多数の観客が動画を視聴している状況ではそうでない状況に比べて、アイテムの潜在的な投入要求者が多いうえに、アイテム投入により多数の観客の反応が期待できるので、アイテム投入を行いたいと考える観客が多い可能性が高い。そして、実際にアイテム投入要求が多数発行されれば、近い将来に動画の大部分がアイテム画像などで埋め尽くされ、個々のアイテム投入を把握することが困難となるであろう。他方、アイテム投入要求が殆ど発行されなければ、近い将来に動画に重畳されるアイテム画像も殆どなく、個々のアイテム投入を把握するのに殆ど支障はないであろう。

投入制御サーバ１００は、生放送動画に対するアイテム投入の活発さが高いと予測されるほど、対価も高くなるように決定する。故に、生放送動画に対するアイテム投入が活発となりそうな、すなわち個々のアイテム投入の把握に困難を来しそうな状況ではアイテム投入の対価が上がるため、観客はアイテム投入を躊躇し、アイテム投入数が過多になるのを防ぐことができる。すなわち、過度に多くのアイテム投入が行われること起因する諸問題、例えば、双方向的なコミュニケーションが阻害される、アイテムを行った観客が期待ほど注目を浴びないことに不満を感じる、生放送サーバ３００におけるアイテム画像などの重畳処理が過大になる、などを回避できる。他方、生放送動画に対するアイテム投入が活発とならなそうな、すなわち個々のアイテム投入の把握に支障がなさそうな状況ではアイテム投入の対価が下がるため、観客はアイテム投入をしやすくなる。すなわち、アイテム投入機能の利用が適度に促進される。

なお、図２において示される各装置の数は、例示に過ぎない。例えば、観客端末４００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、図２の生放送システムは、複数の動画を並列的に生放送することができるので、配信者端末２００の数も複数となり得る。さらに、図２に示されないＷｅｂサーバなどがさらに設けられてもよい。

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

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

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

投入制御サーバ１００は、さらに、ネットワークに接続するための通信Ｉ／Ｆ（インタフェース）を利用可能である。通信Ｉ／Ｆは、投入制御サーバ１００に内蔵されてもよいし、投入制御サーバ１００に外付けされてもよい。通信Ｉ／Ｆは、ネットワーク経由で、外部装置、例えば、生放送サーバ３００，観客端末４００、決済サーバ５００、などと通信をするためのモジュールであり得る。

次に、図１を用いて投入制御サーバ１００の構成例の説明を続ける。図１の投入制御サーバ１００は、通信部１１０と、投入制御部１２０と、種々の記憶部とを含む。
通信部１１０は、例えば前述の通信Ｉ／Ｆであってよく、ネットワーク経由で、例えば観客端末４００からアイテム投入の実施要求を受信したり、当該実施要求に基づいて生成された決済要求を決済サーバ５００へ送信したり、当該決済要求の応答を決済サーバ５００から受信したり、決済が正常に行われた実施要求に対応するアイテム投入要求を生放送サーバ３００へ送信したりする。
具体的には、通信部１１０は、受信部１１１および送信部１１２を含む。

受信部１１１は、例えば、生放送サーバ３００、観客端末４００、決済サーバ５００、などから種々のデータを受信する。
（１） 受信部１１１は、観客端末４００からアイテム投入の実施要求を受信する。ここで、アイテム投入の実施要求は、例えば投入の対象となるアイテムを識別する識別子と、投入要求者である観客を識別する識別子と、当該要求の発行時に投入要求者の観客端末４００の画面に表示されていた対価、すなわち投入要求者が支払いに同意した対価を示すデータと、オプションとして投入要求者からのコメントデータとを含み得る。対価を示すデータは、当該対価または後述される中間パラメータの値を直接的に示すものであってもよいし、いつ決定／通知された対価か、または何番目に決定／通知された対価かを示すものであってもよい。受信部１１１は、実施要求を投入実施部１２１へ送る。

（２） 受信部１１１は、生放送サーバ３００から生放送中の動画に関するデータを受信し得る。具体的には、受信部１１１は、動画の同時視聴者数、動画の同時視聴者数のうちその動画の配信者のフォロワー数、動画の同時視聴者数のうちその動画の配信者の特別なフォロワー数、配信者の属性、観客の属性、などを示すデータを受信し得る。受信部１１１は、生放送中の動画に関するデータを指標算出部１２３へ送る。

ここで、特別なフォロワーとそれ以外の通常のフォロワーとは、配信者が提供する有料チャンネルの会員であるか否か、などにより定められてよい。配信者が提供する有料チャンネルの会員である観客は、そうでない観客に比べて、当該配信者から注目を浴びることへの欲求や当該配信者の活動を応援したいという気持ちが強く、結果的にアイテム投入を積極的に行う可能性がある。また、観客の属性には、生放送システムの提供するサービスに支払うサービス料の多寡、例えば、観客が前述のプレミアムサービスプランの加入者であるか否かが含まれ得る。生放送システムによって提供されるサービスに多額のサービス料を支払う観客は、そうでない観客に比べてアイテム投入を行うことの心理的ハードルが低い可能性がある。

（３） 受信部１１１は、決済サーバ５００から送信済みの決済要求に対する決済応答を受信し、これを決済制御部１２２へ送る。
（４） 受信部１１１は、後述される対価の通知データの取得要求を観客端末４００から受信し、これを通知データ生成部１２５へ送り得る。

送信部１１２は、例えば、生放送サーバ３００、観客端末４００、決済サーバ５００、などへ種々のデータを送信する。具体的には、送信部１１２は、投入実施部１２１からアイテム投入要求を受け取り、これを生放送サーバ３００へ送信する。また、送信部１１２は、決済制御部１２２から決済要求を受け取り、これを決済サーバ５００へ送信する。さらに、送信部１１２は、通知データ生成部１２５から通知データを受け取り、これを観客端末４００へ送信する。なお、通知データは、観客端末４００へ直接送信されてもよいし、生放送サーバ３００などを経由して観客端末４００へ送信されてもよい。

通知データの詳細は、後述されるが、個別のアイテム投入についての対価の値を示してもよいし、このような個別の対価を一意に算出するための中間パラメータの値を示してもよい。また、送信部１１２は、投入実施部１２１からアイテム投入の実施要求の受理／拒否を示す応答を受け取り、これを投入要求者の観客端末４００へ送ってもよい。

投入制御部１２０は、前述のプロセッサおよびメモリであってよい。投入制御部１２０は、通信部１１０から、アイテム投入の実施要求、生放送中の動画に関するデータ、決済応答、通知データの取得要求、などのデータを受け取る。また、投入制御部１２０は、種々の記憶部から必要なデータを読み出す。投入制御部１２０は、通信部１１０から受け取ったデータおよび／または種々の記憶部から読み出したデータに基づいて、指標を算出して対価を決定したり、対価を示す通知データを生成したり、決済サーバ５００による決済処理を制御したり、アイテム投入を実施したりする。さらに、投入制御部１２０は、通知データ、決済要求、アイテム投入の実施要求の受理／拒否を示す応答、アイテム投入要求、などの種々のデータを通信部１１０へ送る。具体的には、投入制御部１２０は、投入実施部１２１と、決済制御部１２２と、指標算出部１２３と、対価決定部１２４と、通知データ生成部１２５とを含む。

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

投入実施部１２１は、決済制御部１２２から決済に成功したとの報告を受けると、アイテム投入要求を発行し、送信部１１２へ送る。これにより、投入実施部１２１は、生放送サーバ３００に、実施要求の対象となったアイテムを投入させることができる。すなわち、アイテム投入要求を受信した生放送サーバ３００は、生放送動画にアイテム画像などを重畳する加工を行い、それから配信者端末２００および観客端末４００へ配信することになる。また、投入実施部１２１は、アイテム投入が実施されることをその投入要求者に伝えるために、アイテム投入の実施要求の受理を示す応答を生成し、送信部１１２へ送ってもよい。さらに、後述されるように、指標算出部１２３が、受信済みのアイテム投入の実施要求の情報に基づいて指標を算出する場合には、投入実施部１２１は、受信済みのアイテム投入の実施要求に関するデータである受信要求データを要求記憶部１３１に書き込む。受信要求データは、後述されるように、集計期間内に受信されたアイテム投入の実施要求の数をカウントした値であり得る。

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

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

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

指標算出部１２３は、（１）生放送中の動画に関するデータ、（２）指標を算出する以前に受信済みのアイテム投入の実施要求（以降、単に受信要求データと称する）、などに基づいて、生放送動画に対するアイテム投入の活発さの予測値に相当する指標を算出する。指標算出部１２３は、算出した指標を対価決定部１２４へ送る。なお、指標算出部１２３は、これら（１）、（２）の一方に基づいて指標を算出してもよいし、両方に基づいて指標を算出してもよい。

まず、上記（１）の場合の指標算出部１２３の動作について説明する。指標算出部１２３は、受信部１１１から生放送中の動画に関するデータを受け取る。かかるデータは、例えば数十秒おき、数分おき、などの周期で生放送サーバ３００から受信され得る。なお、この周期は、固定であってもよいし、可変であってもよい。或いは、かかるデータは、当該データに基づいて定められるイベントの発生時（例えば、同時視聴者数が１００人を超えた時、同時視聴者数のうちの同動画の配信者のフォロワー数が５０人を下回った時、など）に、生放送サーバ３００によって送信されるようにしてもよい。

指標算出部１２３は、同時視聴者数をそのまま指標としてもよいし、または何らかの数式に同時視聴者数を代入して指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。同時視聴者数が多いほど潜在的な投入要求者数が多いうえに、アイテム投入により多数の観客の反応が期待できることを意味するので、指標算出部１２３は、より高い活発さに対応する予測値を示す指標を算出する。

また、指標算出部１２３は、同時視聴者数に加えて配信者または観客の属性に基づいて指標を算出することもできる。具体的には、指標算出部１２３は、同時視聴者数のうちの同動画の配信者の（全）フォロワー数、同時視聴者数のうちの同動画の配信者の特別なフォロワー数、または同時視聴者数のうちの前述のプレミアムサービスプランの加入者数、などをそのまま指標としてもよいし、または何らかの数式にこれらの数を代入して指標を算出してもよい。

配信者のフォロワーである観客は、そうでない観客に比べて、当該配信者から注目を浴びることへの欲求や当該配信者の活動を応援したいという気持ちが強く、結果的にアイテム投入を積極的に行う可能性がある。また、配信者の特別なフォロワーである観客ではよりその傾向が強い。さらに、前述のプレミアムサービスプランの加入者である観客は、そうでない観客に比べてアイテム投入を行うことの心理的ハードルが低い可能性がある。故に、これらの数が多いほど潜在的な投入要求者数が多いことを意味するので、指標算出部１２３は、より高い活発さに対応する予測値を示す指標を算出する。

さらに、指標算出部１２３は、配信者／観客の属性に基づいて指標を算出してもよい。例えば、過去にアイテム投入が活発に行われた動画の配信者、または過去にアイテム投入を活発に行った観客が関与する生放送動画では、アイテム投入が活発に行われる可能性がある。そこで、指標算出部１２３は、配信者の過去（例えば前回）の生放送動画において実施された投入アイテムに関する対価の総額を示すデータを受信し、これらのデータまたはその統計値に基づいて、生放送中の動画に対するアイテム投入の活発さを予測してもよい。同様に、指標算出部１２３は、観客の過去（例えば前回）の（同配信者または別の配信者の）生放送動画において実施した投入アイテムに関する対価の総額を示すデータを受信し、これらのデータまたはその統計値に基づいて、生放送中の動画に対するアイテム投入の活発さを予測してもよい。

次に、上記（２）の場合の指標算出部１２３の動作について説明する。指標算出部１２３は、要求記憶部１３１から受信要求データを受け取る。ここで、受信要求データは、例えば、集計期間内に受信されたアイテム投入の実施要求の数をカウントした値であってもよい。

具体的には、指標算出部１２３は、実施要求の数をそのまま指標としてもよいし、または何らかの数式に実施要求の数を代入して指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。実施要求の数が多いほどより多くのアイテム投入が生放送動画に対して実施されようとしている／されたことを意味するので、指標算出部１２３は、より高い活発さに対応する予測値を示す指標を算出する。

指標算出部１２３は、生放送動画に対するアイテム投入の活発さの短期間の変動に対価を追従させるために、指標を周期的に、例えば数十秒おき、数分おき、程度に算出してもよい。なお、周期は、固定であってもよいし、可変であってもよい。この周期は、上記集計期間と一致してもよいし、しなくてもよい。

対価決定部１２４は、指標算出部１２３から指標を受け取り、これに基づいて対価を算出する。具体的には、対価決定部１２４は、指標の示す、生放送動画に対するアイテム投入の活発さが高いほど高くなるように対価を決定する。例えば、指標が第１の予測値に相当する場合には対価を第１の値に決定し、指標が第１の予測値よりも生放送動画に対するアイテム投入が活発であることに対応する第２の予測値に相当する場合には対価を第１の値よりも高い第２の値に決定してもよい。対価決定部１２４は、例えば、活発さの増加に対して単調増加するように（すなわち活発さの増加に対して減少しないように）対価を決定してもよい。なお、対価は、活発さの増加に対して線形に増加してもよいし、非線形（例えばステップ状）に増加してもよい。対価決定部１２４は、決定した対価を示すデータを対価記憶部１３３に書き込む。

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

前述のように指標算出部１２３が指標を周期的に算出する場合には、対価決定部１２４も対価を周期的に決定してもよい。これに伴い、通知データ生成部１２５は、通知データを繰り返し生成し、送信部１１２は通知データを観客端末４００へ繰り返し送信して、観客端末４００は通知データを受信する度に最新の対価を画面に表示できる。

通知データ生成部１２５は、受信部１１１から、対価の通知データの取得要求を受け取る。通知データ生成部１２５は、この取得要求をトリガに、対価記憶部１３３から最新の対価を示すデータを読み出し、これに基づいて通知データを生成する。通知データ生成部１２５は、通知データを送信部１１２へ送る。

通知データの取得要求は、例えば、アイテム投入の対価が記載されたＷｅｂページの取得要求であり得る。その一例を説明する。図４の動画視聴ページは、生放送動画を表示するための動画表示領域に加えて、複数のアイコンを表示可能なランチャーを含むＷｅｂページである。ランチャーに表示された２つのアイコンのうちプレゼント形の投入アイテムアイコンは、アイテム投入の対価が記載されたＷｅｂページである投入アイテムメニューページへの遷移を可能とする。そして、この場合における通知データの取得要求は、上記投入アイコンがユーザによって選択された時に観客端末４００が発行する投入アイテムメニューページの取得要求に相当し、通知データはこの取得要求の応答として得られるデータに相当する。

或いは、通知データの取得要求は、上記投入アイコンによる遷移先である投入アイテムメニューページ（図５に例示される）の表示中に自動的にまたはユーザからの操作入力により発行される、更新要求に相当し、通知データはこの更新要求の応答として得られるデータに相当し得る。なお、図４および図５の例では、動画視聴ページと投入アイテムメニューページとは別画面であるが、両者は同一画面であってもよい。

図５の投入アイテムメニューページは、複数の投入アイテムアイコン、具体的には、「コイン」、「だるま」、および「宝箱」と、それぞれのアイテム投入の対価を示す情報「１００ｐｔ」、「３０００ｐｔ」および「５０００ｐｔ」を含む。なお、投入アイテムアイコンの外観および数、およびそれぞれの対価は例示に過ぎないし、アイテム投入の対価は通知データの受信毎に更新されることになる。投入アイテムアイコンの外観は、実際に投入されるアイテム画像と一致していてもよいし、異なっていてもよい。また、図５の例では示されていないが、現在の相場が割安であるか割高であるかの情報も併せて表示されてもよい。これにより、観客は対価の絶対額そのものを吟味せずとも、アイテム投入がしやすい相場かそうでない相場かを容易に見極めて、アイテム投入を行うタイミングを判断できる。

それぞれの投入アイテムアイコンを選択すると、観客端末４００は、投入確認ウィンドウをポップアップしてもよい。図６に、「宝箱」アイコンが選択された場合にポップアップする投入確認ウィンドウを例示する。この投入確認ウィンドウは、選択したアイテムの名称と、当該アイテムのアイコン（または実際に投入される画像）と、当該アイテムを投入するための対価を示す情報と、アイテム投入の実施要求を発行するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）部品（ウィジェット）としての投入ボタン（「規約に同意して投げる」ボタン）とを含む。観客端末４００のユーザがこの投入ボタンを選択する操作入力を行うと、観客端末４００は、アイテム投入の実施要求を発行し、投入制御サーバ１００へ送信する。なお、ここで説明した要素の一部または全部が、投入確認ウィンドウに表示されなくてもよいし、投入ボタンは投入アイテムメニューページなどのアイテム投入の対価が記載されたＷｅｂページに表示されてもよい。また、投入要求者からのコメントを受け付けるテキスト入力欄が投入ボタンと共に設けられてもよい。

また、図５の投入アイテムメニューページは、当該ページに対応付けられる動画視聴ページに表示される動画のタイトル（コンテンツタイトル）と、配信者（コンテンツオーナー）と、配信者コメント、動画カテゴリ、動画に対して付与されたキーワードである動画タグ、動画カテゴリ、および動画のスポンサー名、などの各種関連情報（コンテンツ情報）とを含む。ただし、これらの要素の一部または全部が、アイテム投入の対価が記載されたＷｅｂページに表示されなくてもよい。

さらに、図５の投入アイテムメニューページは、当該ページに対応付けられる動画視聴ページに表示される動画に対して実施されたアイテム投入により支払われた対価（貢献度）の累計と、動画における投入者別の貢献度のランキングまたは動画に対して実施されたアイテム投入の履歴（投入履歴）のいずれかとを含む。なお、ランキングおよび投入履歴は、それぞれ対応するボタンにより表示を切り替え可能である。図５にはランキングが表示されているが、観客端末４００のユーザが「投入履歴」ボタンを選択することで、図７に例示される投入履歴を代わりに表示することが可能である。ランキングによれば、投入者がどの程度の対価を支払って配信者および動画に貢献しているのかを、配信者および他の観客に周知することができる。他方、投入履歴によれば、配信者および他の観客は、アイテム投入の瞬間を見逃したとしても、どの投入者がどの程度の対価を支払ったかを事後的に確認することができる。ただし、これらの要素の一部または全部が、アイテム投入の対価が記載されたＷｅｂページに表示されなくてもよい。また、ランキングおよび投入履歴は択一的に表示される必要はなく、例えば同時に表示されてもよい。

なお、通知データ生成部１２５は、観客端末４００からの取得要求を待たなくてもよい。すなわち、通知データ生成部１２５は、対価決定部１２４が対価を決定する毎に、自発的に通知データを生成し、送信部１１２にこれを観客端末４００へ送信させてもよい。

ここで、図３を用いて、投入制御サーバ１００が対価の決定に関してどのように動作するかを概念的に説明する。図３の例では、指標算出部１２３は、前述の具体例の１つのように、同時視聴者数に基づいて指標を算出することとする。

受信部１１１は、同時視聴者数の集計期間Ｔ０（これは図３中のＴ１の１つ前の期間であって図３には示されていない）内に、生放送動画の同時視聴者数が１６０人であることを示すデータを生放送サーバ３００から受信する。なお、同時視聴者数の集計期間は、前述のアイテム投入の実施要求の数をカウントするための集計期間と同一であってもよいし、異なっていてもよい。また、同一の集計期間に同時視聴者数を示すデータを複数回受信する場合には、例えば受信タイミングが最も新しいものを採用してもよい。指標算出部１２３は、期間Ｔ０の終了後に、この同時視聴者数（１６０人）に基づいて指標を算出する。例えば、指標算出部１２３は、指標＝ｌｏｇ_２（同時視聴者数／４０）の数式に同時視聴者数を代入してもよい。そして、対価決定部１２４は、この指標に基づいて、対価の変動比率ｒを２に決定する。この変動比率を示す通知データが観客端末４００へ送信され、観客端末４００は通知された変動比率に基づいて対価を再計算し、画面上に最新の対価（２００Ｐ）を表示する。

同様に、受信部１１１は、同時視聴者数の集計期間Ｔ１内に、生放送動画の同時視聴者数が８０人であることを示すデータを生放送サーバ３００から受信する。指標算出部１２３は、期間Ｔ１の終了後に、同時視聴者数（８０人）に基づいて指標を算出する。そして、対価決定部１２４は、この指標に基づいて、対価の変動比率ｒを１に決定する。この変動比率を示す通知データが観客端末４００へ送信され、観客端末４００は通知された変動比率に基づいて対価を再計算し、画面上に最新の対価（１００Ｐ）を表示する。

同様に、受信部１１１は、同時視聴者数の集計期間Ｔ２内に、生放送動画の同時視聴者数が３２０人であることを示すデータを生放送サーバ３００から受信する。指標算出部１２３は、期間Ｔ２の終了後に、同時視聴者数（３２０人）に基づいて指標を算出する。そして、対価決定部１２４は、この指標に基づいて、対価の変動比率ｒを３に決定する。この変動比率を示す通知データが観客端末４００へ送信され、観客端末４００は通知された変動比率に基づいて対価を再計算し、画面上に最新の対価（３００Ｐ）を表示する。

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

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

対価記憶部１３３は、対価を示すデータを保存する。具体的には、対価記憶部１３３は、対価を示すデータに関連付けて、当該対価がいつ決定されたか、または生放送動画の開始後、何番目に決定されたかを示すデータも保存し得る。これらのデータは、決済制御部１２２が、申告対価が不正でないことを検査するために必要となり得る。対価を示すデータは、対価決定部１２４によって書き込まれ、または書き換えられ得る。対価を示すデータは、決済制御部１２２および通知データ生成部１２５によって読み出される。

次に、図８を用いて、投入制御サーバ１００の動作例を説明する。なお、図８の例では、指標算出部１２３は、前述の具体例の１つのように、同時視聴者数に基づいて指標を算出することとする。

まず、受信部１１１が観客端末４００からアイテム投入の実施要求を受信すると（ステップＳ８０１）、投入実施部１２１は、この実施要求に基づいて決済制御部１２２に対価の決済を行わせる（ステップＳ８０２）。

ステップＳ８０２における対価の決済が正常に終了すれば処理はステップＳ８０４へ進み、そうでなければ受信された実施要求に基づくアイテム投入は行われない。ステップＳ８０４において、投入実施部１２１は、アイテム投入を行う。すなわち、投入実施部１２１は、アイテム投入要求を発行し、生放送サーバ３００へ送信する。

投入制御サーバ１００は、このように、ステップＳ８０１乃至ステップＳ８０４、すなわちアイテム投入の実施要求の待ち受けと受信した実施要求に基づく処理（決済制御および必要に応じてアイテム投入）とを動画の生放送が終了するまで（ステップＳ８０９）繰り返す。ただし、指標および対価を更新する必要がある場合、すなわち図８の例では予め定められた同時視聴者数の集計期間が満了した場合（ステップＳ８０５）、ステップＳ８０６乃至ステップＳ８０８の処理が行われることになる。なお、ステップＳ８０１乃至ステップＳ８０４の処理と、ステップＳ８０６乃至ステップＳ８０８の処理とは並列的に行われ得る。また、同時視聴者数の集計期間は必ずしも定められなくてもよく、例えば同時視聴者数を示すデータが受信される毎に、ステップＳ８０６乃至ステップＳ８０８の処理が行われるようにしてもよい。

ステップＳ８０６において、指標算出部１２３は、集計期間内に受信した、同時視聴者数を示すデータに基づいて指標を算出する。同時視聴者数を示すデータは、ステップＳ８０６の実行前、すなわちステップＳ８０１乃至ステップＳ８０４の繰り返し実行中に受信部１１１によって受信され得る。対価決定部１２４は、ステップＳ８０６において算出された指標に基づいて対価を決定する（ステップＳ８０７）。通知データ生成部１２５は、ステップＳ８０７において決定された対価を示す通知データを生成し、観客端末４００へ送信する（ステップＳ８０８）。

なお、ステップＳ８０８がいつ行われるかは通知データ生成部１２５がどのように動作するかに依存する。通知データ生成部１２５が自発的に通知データを生成および送信する場合には、ステップＳ８０７の完了後無条件にステップＳ８０８が行われ得る。他方、通知データ生成部１２５が、観客端末４００からの取得要求をトリガとして通知データを生成および送信する場合には、この取得要求が受信されるまでステップＳ８０８は実行されないことになる。

以上説明したように、実施形態に係る投入制御サーバは、生放送動画などのコンテンツに対するアイテム投入の活発さの予測値を示す指標を算出し、当該指標に基づいて対価を決定し、当該対価を示す通知データを観客端末へ送信する。より具体的には、投入制御サーバは、指標の示す活発さが高いほど高くなるように対価を決定する。故に、コンテンツに対するアイテム投入が活発となりそうな、すなわち個々のアイテム投入の把握に困難を来しそうな状況ではアイテム投入の対価が上がるため、観客はアイテム投入を躊躇し、アイテム投入数が過多になるのを防ぐことができる。すなわち、過度に多くのアイテム投入が行われること起因する諸問題、例えば、双方向的なコミュニケーションが阻害される、アイテムを行った観客が期待ほど注目を浴びないことに不満を感じる、生放送サーバにおけるアイテム画像などの重畳処理が過大になる、などを回避できる。他方、コンテンツに対するアイテム投入が活発とならなそうな、すなわち個々のアイテム投入の把握に支障がなさそうな状況ではアイテム投入の対価が下がるため、観客はアイテム投入をしやすくなる。すなわち、アイテム投入機能の利用が適度に促進される。このように、実施形態に係る投入制御サーバによれば、コンテンツに対するアイテム投入（投げ銭を含む）の発生数を適正化することができる。

（変形例）
実施形態は、主に生放送動画などの生放送コンテンツへの適用を想定して説明された。しかしながら、以下に説明するように、実施形態はアーカイブコンテンツへも適用可能である。アーカイブコンテンツは、タイムシフト再生される生放送コンテンツを含み得る。

具体的には実施形態と同様に、変形例に係る投入制御サーバは、コンテンツに対するアイテム投入の活発さの予測値を示す指標を算出し、当該指標に基づいて対価を決定し、当該対価を示す通知データを観客端末へ送信する。より具体的には、投入制御サーバは、指標の示す活発さが高いほど高くなるように対価を決定する。

ただし、生放送コンテンツでは全ての観客が同じ場面を略同時に視聴するのに対して、アーカイブコンテンツでは観客によって視聴する時間はばらばらとなり得るので、観客全員が同じ場面を同時に視聴することは想定し難い。そこで、変形例に係る投入制御サーバは、実施形態とは異なる手法により指標を算出してもよい。

例えば、投入制御サーバ（の指標算出部）は、「同時視聴者数」の代わりに、総観客数、または例えば直近２４時間、直近１週間、などの所定期間内の観客数を利用して指標を算出してもよい。

また、コメントサーバが、コメントデータに対応付けて、コメント投稿者の端末におけるコメント投稿時のアーカイブコンテンツの再生時間を記録する場合には、記録された再生時間データに基づいてコメント投稿数の時間軸上の分布を求めることができる。これにより、例えばコンテンツの盛り上がりの時間変化を把握することが可能となる。コンテンツが盛り上がる場面では、観客の注目度も高くなりやすいので、このようなタイミングでアイテム投入を行えば多数の観客の反応が期待でき、観客のアイテム投入が増えると予測できる。そこで、投入制御サーバ（の指標算出部）は、時間軸上のコメント数の増減に応じて、指標を増減させてもよい。

さらに、投入制御サーバまたはその他のサーバが、アイテム投入の要求者の端末における投入要求時のアーカイブコンテンツの再生時間を記録しておいてもよい。記録された再生時間データに基づいて、アイテム投入の実施要求の発生数の時間軸上の分布を求めることができる。これにより、前述のコメント投稿数の時間軸上の分布の例と同様に、例えばコンテンツの盛り上がりの時間変化を把握することが可能となる。そこで、投入制御サーバ（の指標算出部）は、時間軸上のアイテム投入の実施要求の発生数の増減に応じて、指標を増減させてもよい。

このように、コンテンツに対するアイテム投入が活発となりそうな、すなわち個々のアイテム投入の把握に困難を来しそうな状況ではアイテム投入の対価が上がるため、観客はアイテム投入を躊躇し、アイテム投入数が過多になるのを防ぐことができる。すなわち、過度に多くのアイテム投入が行われること起因する諸問題、例えば、双方向的なコミュニケーションが阻害される（アーカイブコンテンツの場合であっても、生放送コンテンツに比べて時間差は大きくなりがちであるが、双方向的なコミュニケーションは成立し得る）、アイテムを行った観客が期待ほど注目を浴びないことに不満を感じる、コンテンツ配信サーバにおけるアイテム画像などの重畳処理が過大になる、などを回避できる。他方、コンテンツに対するアイテム投入が活発とならなそうな、すなわち個々のアイテム投入の把握に支障がなさそうな状況ではアイテム投入の対価が下がるため、観客はアイテム投入をしやすくなる。すなわち、アイテム投入機能の利用が適度に促進される。このように、変形例に係る投入制御サーバによれば、アーカイブコンテンツに対するアイテム投入（投げ銭を含む）の発生数を適正化することができる。

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

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

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

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

１００・・・投入制御サーバ
１１０・・・通信部
１１１・・・受信部
１１２・・・送信部
１２０・・・投入制御部
１２１・・・投入実施部
１２２・・・決済制御部
１２３・・・指標算出部
１２４・・・対価決定部
１２５・・・通知データ生成部
１３１・・・要求記憶部
１３３・・・対価記憶部
２００・・・配信者端末
３００・・・生放送サーバ
４００・・・観客端末
５００・・・決済サーバ
６００・・・保有資産管理サーバ
７００・・・コメントサーバ

Claims (10)

1. コンテンツに対するアイテム投入の活発さの予測値に相当する指標を算出する算出部と、
   前記コンテンツの観客が前記コンテンツに対して前記アイテム投入を実施するための対価を前記指標に基づいて決定する決定部と、
   前記アイテム投入の実施要求が受信された場合に、前記対価と引き替えに前記実施要求の対象となるアイテムの画像を前記コンテンツに重畳させる投入実施部と
   を具備し、
   前記決定部は、前記指標が第１の予測値に相当する場合には前記対価を第１の値に決定し、前記指標が前記第１の予測値よりも前記コンテンツに対する前記アイテム投入が活発であることに対応する第２の予測値に相当する場合には前記対価を前記第１の値よりも高い第２の値に決定する、
   サーバ。
2. 前記算出部は、前記コンテンツに関するデータに基づいて前記指標を算出する、請求項１に記載のサーバ。
3. 前記コンテンツは、生放送コンテンツであり、
   前記算出部は、前記生放送コンテンツの同時視聴者数に基づいて前記指標を算出する、請求項２に記載のサーバ。
4. 前記算出部は、前記コンテンツの観客の属性に基づいて前記指標を算出する、請求項２または請求項３に記載のサーバ。
5. 前記算出部は、前記コンテンツの配信者の属性に基づいて前記指標を算出する、請求項２乃至請求項４のいずれか１項に記載のサーバ。
6. 前記算出部は、受信された前記実施要求に基づいて、前記指標を算出する、請求項１に記載のサーバ。
7. 前記算出部は、受信された前記実施要求の数に基づいて、前記指標を算出する、請求項６に記載のサーバ。
8. 前記算出部は、前記指標を周期的に算出し、
   前記決定部は、前記指標に基づいて、前記対価を周期的に決定する、
   請求項１に記載のサーバ。
9. 前記決定部は、前記対価の中間パラメータである変動比率を前記指標に基づいて決定し、
   前記対価は、当該対価に対応するアイテムの種類に対して予め定義された基準対価に前記変動比率を乗じた値である、
   請求項１に記載のサーバ。
10. コンピュータを、
    コンテンツに対するアイテム投入の活発さの予測値に相当する指標を算出する手段、
    前記コンテンツの観客が前記コンテンツに対して前記アイテム投入を実施するための対価を前記指標に基づいて決定する手段、
    前記アイテム投入の実施要求が受信された場合に、前記対価と引き替えに前記実施要求の対象となるアイテムの画像を前記コンテンツに重畳させる手段と
    として機能させ、
    前記決定する手段は、前記指標が第１の予測値に相当する場合には前記対価を第１の値に決定し、前記指標が前記第１の予測値よりも前記コンテンツに対する前記アイテム投入が活発であることに対応する第２の予測値に相当する場合には前記対価を前記第１の値よりも高い第２の値に決定する、
    プログラム。