以下、図面を参照して、本発明の好適な実施形態について説明する。なお、以下説明する実施形態によって本発明が限定されるものではなく、本発明を適用可能な形態が以下の実施形態に限定されるものでもない。また、図面の記載において、同一部分には同一の符号を付す。
〔第1実施形態〕
図1は、本発明が適用されたコンテンツ提供システム1000の全体構成例を示す図である。コンテンツ提供システム1000は、マルチメディアコンテンツ等のコンテンツを不特定多数で同時に楽しむ配信サービスを提供するコンピュータシステムである。コンテンツの配信に当たっては一例としてストリーミング配信として説明するが、他の方式の配信であってもよいことは勿論である。コンテンツ提供システム1000は、ストリーミングサーバ1100と、複数のユーザ端末1500(1500a,1500b,…,1500T)とを含み、これらが通信回線9を介して相互にデータ通信可能に接続されて構成される。
通信回線9は、データ通信が可能な通信路を意味する。すなわち、通信回線9とは、直接接続のための専用線(専用ケーブル)やイーサネット(登録商標)等によるLAN(Local Area Network)の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線/無線を問わない。
ストリーミングサーバ1100は、提供ユーザ2(2t)のユーザ端末1500(1500T)から提供された少なくとも映像を含むコンテンツを、各視聴ユーザ2(2a,2b,…)のユーザ端末1500(1500a,1500b,…)へ向けて配信するコンテンツ配信システムを実現するコンピュータシステムである。
具体的には、ストリーミングサーバ1100は、本体装置1101と、キーボード1106と、タッチパネル1108と、ストレージ1140とを備え、本体装置1101は、CPU(Central Processing Unit)1151やGPU(Graphics Processing Unit)、DSP(Digital Signal Processor)等の演算回路であるプロセッサ、VRAMやRAM、ROM等の各種ICメモリ1152、通信装置1153等の電子部品が搭載された制御基板1150を内蔵している。なお、制御基板1150の一部又は全部は、ASIC(Application Specific Integrated Circuit)やFPGA(field-programmable gate array)、SoC(System on a Chip)により実現するとしてもよい。
そして、ストリーミングサーバ1100は、制御基板1150が所定のプログラム及びデータに基づいて演算処理することにより、
1)ユーザ登録等に係るユーザ管理機能と、
2)コンテンツの配信サービス機能と、
3)ユーザ端末1500から発信(投稿ともいえる)されたテキストや画像(例えば発信用画像)を配信するユーザ発信サービス機能と、
4)ユーザ発信サービス機能で発信することのできる発信用画像等をオンラインで購入可能にするオンラインショッピング機能と、
を実現する。勿論、これら以外の機能を実現できる構成も可能である。例えば、ソーシャルネットワーキングサービス機能や、その一部としてのチャット機能等を実現できるようにしてもよい。
配信サービス機能は、コンテンツを提供するユーザである提供ユーザ2tのユーザ端末1500Tから動画データ等のコンテンツを取得し、取得したコンテンツを、視聴者登録したユーザである視聴ユーザ2(2a,2b,…)のユーザ端末1500(1500a,1500b,…)へと、コンテンツファイルのダウンロードと並行しながらの視聴を可能な形式で配信する機能である。
ユーザ発信サービス機能は、視聴ユーザ2(2a,2b,…)のユーザ端末1500(1500a,1500b,…)から発信されたテキストや発信用画像を、各視聴ユーザ2(2a,2b,…)のユーザ端末1500(1500a,1500b,…)及び提供ユーザ2tのユーザ端末1500Tへ配信し、配信先にて発信内容を表示させる機能である。
オンラインショッピング機能は、視聴ユーザ2が所持する仮想通貨相当ポイント(以下単に「通貨ポイント」という)を消費して発信用画像等を購入する機能であり、ユーザ端末1500からの要求に応じて電子決済業者等が運営する外部の電子決済サーバと連携し、通貨ポイントの購入手続き(課金処理)を行う。課金処理に際し、電子決済サーバは、ストリーミングサーバ1100からの問合せに応答して通貨ポイントの購入額をユーザのクレジットカードやプリペイドカード等で清算する処理を行う。そして、ストリーミングサーバ1100は、電子決済サーバにより清算された購入額相当の通貨ポイントをユーザに付与する。
なお、ストリーミングサーバ1100は、図1に示す単体の構成に限らず、各機能を分担する複数のブレードサーバを搭載して相互に内部バスを介してデータ通信可能に接続した構成であってもよい。或いは、離れた場所に設置された独立した複数のサーバを、通信回線9を介してデータ通信させることで、全体としてストリーミングサーバ1100として機能させる構成であってもよい。
ユーザ端末1500(1500a,1500b,…,1500T)は、ユーザ2(2a,2b,…,2t)が使用するコンピュータシステムであって、実行するプログラムを変えることで、配信用に提供するコンテンツを作成する提供端末、又は、配信されるコンテンツの視聴を可能にする視聴端末として機能するようになる。図1の例では、ユーザ端末1500Tが提供端末に該当し、ユーザ端末1500a、1500bが視聴端末に該当する。なお、本実施形態のユーザ端末1500は、いわゆるスマートフォンと呼ばれる装置であるが、携帯型ゲーム装置や、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータ等でもよい。
図2は、ユーザ端末1500の一例であるスマートフォンの装置構成例を示す図である。図2に示すように、ユーザ端末1500は、方向入力キー1502と、ホームキー1504と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル1506と、内蔵バッテリー1509と、スピーカ1510と、マイク1512と、イメージセンサモジュール1520と、制御基板1550と、コンピュータ読み出し可能な記憶媒体であるメモリカード1540に対してデータを読み書きできるメモリカード読取装置1542とを備える。その他、図示しない電源ボタン、音量調節ボタン等が設けられている。また、ゲームプレイの対価の支払いが可能なICカード型のクレジットカードやプリペイドカードに対して非接触にデータの読み書きが行えるICカード読取装置等を設けるとしてもよい。
制御基板1550には、CPU1551やGPU、DSP等の各種マイクロプロセッサ、VRAMやRAM,ROM等の各種ICメモリ1552、通信回線9に接続する携帯電話基地局や無線LAN基地局等と無線通信するための無線通信モジュール1553、インターフェース回路1557等が搭載されている。インターフェース回路1557には、方向入力キー1502やホームキー1504からの信号を受信する回路、タッチパネル1506のドライバ回路、スピーカ1510へ音声信号を出力する出力アンプ回路、マイク1512で集音された音声の信号を生成する音声信号生成回路、イメージセンサモジュール1520で撮影された画像の画像データを入力する回路、メモリカード読取装置1542への信号入出力回路等が含まれている。これら制御基板1550に搭載されている各要素は、それぞれがバス回路等を介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。なお、制御基板1550の一部又は全部をASICやFPGA、SoCにて構成してもよい。
この制御基板1550においてICメモリ1552には、提供端末としての機能を実現させるための動画提供プログラム(例えば、コンテンツの作成と提供を可能にする提供端末プログラム)や、視聴端末としての機能を実現させるための視聴プログラム(例えば、配信されるコンテンツの視聴及びテキストや発信用画像の発信を可能にする視聴端末プログラム)、これらのプログラムを実行するのに必要なデータ等が格納される。そして、CPU1551等が提供端末プログラムや視聴端末プログラムを実行して演算処理を実行し、タッチパネル1506や方向入力キー1502、ホームキー1504に対する操作入力に応じてユーザ端末1500の各部を制御することで、ユーザ端末1500によるコンテンツの提供/視聴等を可能にする。
なお、本実施形態では、ユーザ端末1500は、提供端末プログラムや視聴端末プログラム、各種設定データをストリーミングサーバ1100からダウンロードする構成としているが、別途入手したメモリカード1540等の記憶媒体から読み出す構成としてもよい。
図3は、コンテンツを視聴するための視聴画面の画面構成例を示す図である。視聴プログラムを実行しているユーザ端末1500では、図3に例示する視聴画面W1がタッチパネル1506に表示される。視聴画面W1は、例えば、
1)配信されている視聴中のコンテンツ(以下適宜「配信コンテンツ」ともいう)の付帯情報を表示する付帯情報表示部31と、
2)当該配信コンテンツを表示するコンテンツ表示部32と、
3)テキストを入力して発信操作(テキスト発信操作)を行うためのテキスト発信操作部33と、
4)発信用画像8の発信操作(画像発信操作)をするための画像発信操作アイコン34と、
5)汎用表示部35と、
6)各視聴ユーザ2(2a,2b,…)のアバター4(4a,4b,…)や、発信操作されたテキストや発信用画像8の内容を表示する発信内容表示部36と、
7)発信用画像8をオンラインで即時に購入するためのショッピングアイコン37と、
を含む。
付帯情報表示部31に表示される付帯情報には、例えば、タイトル、ジャンル、撮影日時、撮影場所、被写体に関する情報、状況説明文、提供ユーザ2tのプロフィール情報、提供ユーザ2tからのメッセージ等が含まれ得る。また、配信コンテンツがゲームプレイ動画であれば、付帯情報には、プレイ内容やゲーム状況(例えば、プレイしているゲームステージや場所の情報、装備品の情報、敵キャラクタの名称、攻略の状況、プレーヤレベル、ステージクリアまでの残時間や経過時間、入手できるレアアイテム名等)が含まれ得る。
付帯情報は、配信コンテンツの提供前に提供ユーザ2tが自ら設定するのでもよいし、配信サービスの運営者が設定するとしてもよい。また、ゲームプレイ動画の場合には、プレイしているゲームのプレイ情報から自動取得して設定するとしてもよい。本実施形態では、提供ユーザ2tは、提供ユーザ2tに関する情報として、自身のプロフィール情報を事前に設定する。プロフィール情報は、例えば、年齢、性別、生年月日、出身地等の項目の他、例えば好きな動物や好きな食べ物、好きな色、好きな音楽のジャンルといった好きなものや、嫌いなもの等の趣味趣向に関係する項目を含む。
コンテンツ表示部32には、少なくとも動画を含むコンテンツ(例えば、提供ユーザ2tによる演奏や演芸等のライブ中継、提供ユーザ2tがプレイするゲームプレイ、ゲームプレイのライブ中継や録画されたゲームプレイ動画を編集したもの、提供ユーザ2tが撮影や編集を行ったビデオ作品等)の映像が表示される。
テキスト発信操作部33は、発信するコメントやメッセージ等のテキスト(文字・数字・記号)を入力するための入力欄や、入力欄のテキストの発信操作をするための発信実行操作アイコン等を含む。
画像発信操作アイコン34は、発信する発信用画像8を事前に割り当てておくことが可能なワンタッチ操作アイコンである。画像発信操作アイコン34をワンタッチするだけで、割り当て設定されている発信用画像8が発信(投稿)されることになる。
発信用画像8は、配信サービスの運営者が用意し、視聴ユーザ2に無料或いは有料で付与する画像である。視聴ユーザ2は、各々が入手・購入して発信用画像8を保有し、発信に使用することができる。発信された発信用画像8は、視聴ユーザ2の保有数から消費される。
ここで、画像発信操作アイコン34には、視聴ユーザ2が現在保有している発信用画像8の何れかの種類を割り当てることができる。これにより、視聴画面W1上は同じ位置にある同じアイコンであるが、割り当てる発信用画像8が変わることで異なる発信操作をすることができる。
具体的には、所定の割り当て変更操作(例えば、画像発信操作アイコン34の2本指タッチ操作)を行うと、視聴画面W1には、図4に示すようなポップアップ表示W3が表示される。ポップアップ表示W3には、視聴ユーザ2が保有する発信用画像8(8a,8b,…)が、その種類毎に保有数及び加算ポイント数とともに表示される。加算ポイント数は、予め発信用画像8の種類毎に設定される。例えば、販売価格の高いものほど大きい点数を設定しておくことができる。視聴ユーザ2は、このポップアップ表示W3において何れかの発信用画像8をタッチ操作することで、画像発信操作アイコン34に対する発信用画像8の割り当てを設定することができる。現在割り当て設定されている発信用画像8の表示には、選択状態を示すチェックマーク40が添付表示される。
発信用画像8の種類は適宜設定可能であり、静止画に限らず、アニメーションGIF(Graphic Interchange Format)のように変化を伴う画像でもよい。基本的には、発信用画像8は、視聴ユーザ2間のコミュニケーションのアイテムとなるように様々にデザインされている。その中には、配信コンテンツを評価するメッセージ(例えば、いいね、だめだね、面白い、面白くない、凄い、格好いい、…)、提供ユーザ2tへの応援やねぎらいのメッセージ(例えば、頑張れ、落ち着いて、…)、発信者の既定の意思表示(例えば、いいね、面白い等の評価のメッセージや、応援しています、頑張れ、…)等を示すデザインの発信用画像8が含まれる。
したがって、そうしたメッセージや意志表示を含むデザインの発信用画像8が画像発信操作アイコン34に割り当てた状態で画像発信操作をすると、当該操作は、メッセージ発信操作や、既定の意思表示を示す既定発信操作となる。
例えば、画像発信操作アイコン34に割り当てる発信用画像8は、発信用画像8a,8b,8cのような、花や星等の自然物をモチーフとしたグラフィック図形とすることができる。花や星は、喜び、楽しい、対象を良く思っている等の好意的な意志表示のタイミングに発信すると好適である。その他、テキストでは表示されないような大サイズのテキストをモチーフとしたグラフィック図形としてもよい。同じ形状だが、大きさや配色等を異ならせた複数種類の発信用画像8でシリーズ(例えば、春の花シリーズ、夏の花シリーズ等)を用意することもできる。
また、画像発信操作アイコン34に割り当てる発信用画像8は、発信用画像8d,8eのように、キャラクタになにがしかのアイテム(図4の例では、スティック先端に星が付いていて、手に持って振るようにして使う応援グッズ)を持たせた内容、図7(c)に例示する発信用画像8k,8m,8nのようなキャラクタが音楽演奏する内容、キャラクタが何かのポーズやアクション(例えば、投げキッスする、笑いかける、がっかりする等)をしている画像等とすることができる。同じアイテムを持っていてもキャラクタが異なれば違う種類とすることができる。また、同じアクションをしていてもキャラクタが異なれば違う種類とすることができる。
また、画像発信操作アイコン34に割り当てる発信用画像8は、発信用画像8fのように、画像内に単語や文言を含む画像を含めることもできる。キャラクタに吹き出しを付けて表し、あたかもキャラクタがその単語や文言を話しているかのようにデザインしてもよい。勿論、その単語や文言は、マンガの効果音表現のようなオノマトペでもよい。例えば、驚いた様子のキャラクタに「ギク!」の文字、興奮した様子のキャラクタに「ワクワク!」の文字を添えた画像等とすることができる。
なお、本実施形態の発信用画像8(8a,8b,…)は、配信サービスの運営者により予め用意されるものとしているが、ユーザ自らが作成した画像の使用が可能な構成でもよい。勿論、グラフィックデザイン、イラスト、フォントに限らず、実写の画像を用いたものでもよい。
そして、本実施形態では、以上のように発信用画像8が割り当て設定された画像発信操作アイコン34を視聴ユーザ2がタッチ操作し、発信用画像8が発信されると(つまり、視聴ユーザ2が画像発信操作を行うと)、その加算ポイント数が当該配信コンテンツに係る応援ポイントに加算される。したがって、配信開始から終了までの間に多くの視聴ユーザがたくさん画像発信操作を行えば、その分応援ポイントが加点され、当該配信コンテンツは多くの応援ポイントを獲得できる。また、個々の画像発信操作で発信された発信用画像8の加算ポイント数が大きいほど加点が増え、最終的に多くの応援ポイントが貯まることとなる。つまり、応援ポイントは、配信コンテンツに係る配信を1つの番組や舞台、ステージと見立てた場合の盛り上がり度合或いは人気度合を表しているといえる。
図3に戻り、汎用表示部35は、各種報知や演出のための表示等、目的を固定せずに使用される領域である。本実施形態では、主として応援ポイントの表示と、所定のイベント発生条件を満たすと発生するフィーバータイムに関する表示とに用いられる。具体的には、汎用表示部35は、応援ポイントの現在値を表示する応援ポイント表示部351を備える。
また、汎用表示部35には、フィーバータイムの発生時において、後述する「連続コンボ」の連鎖条件を満たした画像発信操作の現在の継続状況(連続コンボに係る現時点での連鎖数:連続コンボ連鎖数)を示すためのコンボゲージ353が表示される。コンボゲージ353は、連続コンボに係る連鎖数が基準値に達するとゲージ値が満タンになるように表示制御され、当該基準値に達すると、フィーバータイムが発生することとなる。基準値は、後述する連続コンボ発生条件の規模条件として予め設定される。したがって、視聴ユーザ2は、このコンボゲージ353によって、あとどのくらい画像発信操作を連鎖させるとフィーバータイムが発生するのかを知ることができ、フィーバータイムの発生を意識して画像発信操作を行うことが可能となる。
また、フィーバータイムの非発生時の汎用表示部35には、視聴ユーザ2が保有する強制発生アイテム355がアイコン化されて表示される。詳細については後述するが、強制発生アイテム355は、通貨ポイントの消費と引き換えにその販売価格で購入することができる特定アイテムであり、そのアイコンをタッチ操作して使用することができる。
発信内容表示部36には、配信コンテンツの視聴ユーザ2(2a,2b,…)のアバター4(4a,4b,…)が表示される。そして、視聴ユーザ2から発信されたテキストは、当該視聴ユーザ2のアバター4(4b,4c)が発言していることを示す吹き出し5(5b,5c)の中に表示される。また、視聴ユーザ2(図3では視聴ユーザ2a)から発信された発信用画像8は、当該視聴ユーザ2(2a)のアバター4(4a)から飛び出すように、或いはアバター4(4a)が取り出したかのようなアクション動作で出現表示がなされる。本実施形態では、これらテキストや発信用画像8は所定の表示時間の間発信内容表示部36に表示され、その後消去される。ただし、発信用画像8については、発信内容表示部36の背景として配信終了まで表示しておく構成でもよい。
ショッピングアイコン37をタッチ操作すると、販売対象の発信用画像8を一覧表示した販売画面がポップアップ表示され、通貨ポイントの消費と引き換えに所望の発信用画像8をその販売価格で購入することができる。また、販売画面では、その他にも、強制発生アイテム355を購入できる。
以上のように構成される視聴画面W1は、図3に示すように、コンテンツ表示部32の手前側(下側)に、各視聴ユーザ2のアバター4を配置表示するようにレイアウトされており、あたかも集まって配信コンテンツを鑑賞しているような雰囲気をユーザに提供する。
加えて、各視聴ユーザ2が発信したテキストをアバター4の吹き出し5で表示したり、発信用画像8をアバター4から出現表示することで、まるで皆で配信コンテンツを鑑賞しつつ、思い思いに感想を述べたり、仲間に話しかけているような雰囲気を醸成している。発信用画像8は、テキストのように一々読まなくてよいので、視聴ユーザ2が感じているところ、思っているところのものを瞬時かつ象徴的にしかも端的に伝えることができる。また、場の盛り上げ効果もテキストよりも大きい。
このように、視聴画面W1は、配信コンテンツを提供する提供ユーザ2tとそれを視聴する視聴ユーザ2(2a,2b,…)とが、あたかも1つのライブステージや舞台を協働して盛り上げている感覚を得やすいように工夫されている。
そして、本実施形態では、テキストや画像のユーザ発信サービス機能を利用して個々の視聴ユーザ2の発信力を高め、それによって視聴ユーザ2間の一体感や連帯感をさらに高める新たな付加価値をもたらすように工夫されている。
[原理]
配信コンテンツを視聴中の各視聴ユーザのユーザ端末1500(1500a,1500b,…)でテキストや画像の発信操作を行うと、いつ何を発信したのかについての情報、すなわち発信実績の情報がストリーミングサーバ1100に蓄積される。また、ストリーミングサーバ1100では、発信実績をもとに画像発信操作を集計し、当該配信コンテンツに係る応援ポイントを更新・管理する。そして、発信実績や応援ポイントの現在値がストリーミングサーバ1100を介して同時に全ての視聴ユーザのユーザ端末1500に送信され、それぞれの視聴画面W1(発信内容表示部36や応援ポイント表示部351)に表示される。応援ポイントは、提供ユーザのユーザ端末1500にも送信され、提供画面に表示される。
そこで、ストリーミングサーバ1100は、画像発信操作に基づく条件を含むイベント発生条件を満たした場合に、配信コンテンツの視聴雰囲気を盛り上げるためのイベントとして、フィーバータイムを発生させる制御(イベント制御)を行う。
なお、本実施形態では、画像発信操作を応援ポイントに反映させることとし、画像発信操作を対象にイベント発生条件の判定を行ってフィーバータイムを発生させることとするが、テキスト発信操作についても応援ポイントに反映させるようにしてもよい。そして、テキスト発信操作も含めてイベント発生条件(連続コンボ条件や組合せコンボ発生条件、操作回数条件)の判定を行うとしてもよい。
1.イベント発生条件
本実施形態では、複数のイベント発生条件が予め定められており、何れかのイベント発生条件を満たすとその都度フィーバータイムが発生する。本実施形態では、例えば、連続コンボ発生条件、組合せコンボ発生条件、操作回数条件、及び強制発生条件の4つがイベント発生条件とされる。
(1)連続コンボ発生条件/組合せコンボ発生条件
図5は、連続コンボ発生条件を説明する図であり、図6は、組合せコンボ発生条件を説明する図である。ストリーミングサーバ1100は、同一又は異なる発信者による発信用画像8の発信が所定規模以上に連鎖した「発信コンボ(ユーザ発信のコンビネーションの略)」の発生をイベント発生条件として判定する。本実施形態では、「連続コンボ」及び「組合せコンボ」の2種類の発信コンボの発生認定を行う。
発信コンボの発生認定は、連鎖条件を満たす状態が規模要件を満たす程に継続された場合に、肯定判定(認定判定)される。
先ず、図5に示すように、連続コンボの連鎖条件は、発信されたタイミング(発信タイミング)に連続性が有る場合に、連鎖条件が満たされたと肯定判定する。
連続性の判定は、発信タイミングの時間差が所定の「連続性認定時間差Δt」以下である場合に、「連続性有り」と肯定判定される。連続性認定時間差Δtは、適宜設定可能である。例えば、5~30秒前後を設定すると好適である。なお、連続性認定時間差Δtは、配信サービスで共通の値とすることもできるし、配信コンテンツのジャンル等、付帯情報に応じて異なる値を適用するのでもよい。
一方、組合せコンボの連鎖条件は、図6に示すように、発信タイミングに上記の連続性が有り、且つ、それらの発信内容に関連性が有る場合に、連鎖条件が満たされたと肯定判定する。関連性の判定は、「連続性有り」と判定された複数の発信内容を対象にして行われ、それら複数の発信内容の共通点やそれらが作り出すパターンの有無によって行われる。換言すると、発信操作同士の関連性が有れば「関連性有り」と肯定判定される。
図7は、関連性有りと判定される例を説明するための図である。図7(a)~(f)は、関連性が有ると認定される異なるタイプの例を示しており、関連性の判定対象となる連続性を有すると判定された発信の内容(連続性を有する発信内容)の例を発信順に左から右に配列して示している。なお、配列されている発信の内容の例やその数は例示のための便宜上のものあり、実際の運用においてこれらに限定されるものではない。
例えば、図7(a)~図7(d)に例示するように、連続性を有する複数の発信内容が共通点を有している場合は、それらは関連性が有ると判定される。図7(a)の例では、何れも発信用画像8aであって、その種類が共通するので関連性有りと判定される。共通点は発信用画像8の種類に限らない。連続性を有する発信内容とされる複数の発信用画像8の配色や形状でもよい。配色の場合は、最も広い面積を示す主要配色や、面積占有順上位の配色の色系等でもよい。全体として丸型、△型、四角型、といった外形についての共通に着目して関連性の条件が定められていてもよい。
また、描かれている内容の共通性に着目してもよい。例えば、図7(b)のように、発信用画像8に描かれているキャラクタは異なるが、ポーズやアクションが共通している場合も、関連性有りと判定することができる。
また、図7(c)のように、キャラクタもポーズやアクションも厳密には異なるが、ポーズやアクションに共通のテーマ性がある場合も、関連性有りと判定することができる。図7(c)の例では、音楽演奏というテーマにおいて共通点があるので、関連性有りと判定されている。他にも「旗を振る」「メガホンで叫んでいる」「拍手をしている」といった特定のアクションが揃うと「応援」というアクションの共通テーマがあるので、関連性有りと判定することもできる。さらにいえば、発信用画像8に描かれているキャラクタが、全体として1つの団体モーションを形成している場合(例えば、スタジアムでの応援に使用されるウェーブモーション等)に、関連性有りと判定することもできる。
また、画像に含まれるテキストに着目すれば、図7(d)に示すように、発信用画像8に含まれるテキストの意味内容が同一であったり、共通のテーマ性がある場合も、関連性有りと判定することができる。図7(d)の例では、何れも「かわいい」を意味するので、関連性有りとしている。
また、連続性を有する発信内容が、発信された順(発信順)にそれらを並べてみるとパターンを形成している場合や、所定のシリーズが揃った場合に、関連性有りと判定することもできる。
例えば、図7(e)の例では、連続性を有する発信内容全てに共通する共通点は無いが、発信用画像8fと発信用画像8bとが発信順に交互に発信された時系列パターンを形成しているので、関連性有りとされる。関連性有りと認める時系列パターンの内容は、適宜設定可能である。
また、図7(f)の例でも、発信用画像8a、8b、8s、8tはそれぞれ異なる種類であるが、所定の「花」シリーズが形成されているので、関連性有りと判定することができる。
次に、規模要件は、連鎖条件を継続して満たしている回数(換言すると連鎖数)が基準値に達している場合に肯定判定される。具体的には、連続コンボの基準値(連続コンボ基準値)は、図5に示すように、「10連鎖」とする。ただし、10連鎖に限らず、2連鎖以上の連鎖数を適宜設定できる。一方、組合せコンボの基準値(組合せコンボ基準値)は、連鎖条件で認定され得る関連性毎に予め定められる。関連性と基準値との関係は予め設定しておけばよい。例えば、図7(a)の関連性については「10連鎖」、図7(b)の関連性については「5連鎖」等、関連性との関係で異なる連鎖数を基準値とすることができる。また、特定のアクションが揃うと認定される関連性については、そのアクションの組合せの数を基準値とすることができる。図6の例では基準値が「3連鎖」の例を示しており、音楽演奏というテーマに共通点がある異なる3つの発信用画像の発信に連続性が有れば、組合せコンボの発生が認定される。
なお、連続性認定時間差Δtに基準値を乗じて、連鎖条件を満たしている時間長を規模条件としてもよい。例えば、連続コンボの場合は時間長が「10×Δt」に達すると規模条件を満たすとし、組合せコンボの場合は時間長が「3×Δt」に達すると規模条件を満たすとしてもよい。
(2)操作回数条件
ストリーミングサーバ1100は、全ての視聴ユーザによる画像発信操作の総数(発信操作総数)をイベント発生条件として判定する。例えば、配信コンテンツの配信開始時からの画像発信操作の回数を計数し、基準値(発信操作総数基準値)を超えた時点で操作回数条件を満たすと判定する。本実施形態では、視聴ユーザの数に所定数(例えば20回)を乗じた値が基準値とされる。ただし、視聴ユーザの数に関わらず固定値としてもよい。
(3)強制発生条件
強制発生条件は、画像発信操作の操作状況に関わらず即時にフィーバータイムを発生させる条件である。本実施形態では、強制発生条件は、視聴ユーザの操作に係る条件と、提供ユーザの操作に係る条件とを含む。
先ず、視聴ユーザ2の操作に係る条件は、「視聴ユーザ2が有償発生指示操作を行ったこと」とされる。本実施形態では、汎用表示部35において強制発生アイテム355のタッチ操作を有償発生指示操作として受け付け、強制発生アイテム355の消費と引き換えにフィーバータイムを発生させる。
なお、視聴ユーザが入手・購入した強制発生アイテム355の使用を介してフィーバータイムを発生させる構成に限らず、汎用表示部35等に強制発生ボタンを配置し、そのタッチ操作を有償発生指示操作として受け付ける構成でもよい。すなわち、視聴ユーザが強制発生ボタンのタッチ操作を行うと、強制発生アイテム355の販売価格に相当する通貨ポイントの消費と引き換えにフィーバータイムを発生させるのでもよい。
一方、提供ユーザ2tの操作に係る条件は、「提供ユーザ2tが発生指示操作を行ったこと」とされる。発生指示操作は、例えば、配信中に提供ユーザ2tのユーザ端末1500に表示される提供画面内にフィーバー発生ボタンを配置し、そのタッチ操作によって受け付ける。この発生指示操作に際しては、その対価を提供ユーザから徴収する。対価の徴収は、提供ユーザが所持する通貨ポイントの消費と引き換えにフィーバータイムを発生させることで実現できる。
より詳細には、発生指示操作には、例えば1つのコンテンツの提供に当たり1回とか、所定時間(例えば1時間)に1回といった制限回数が定められており、1度発生指示操作を行うと、制限解除までの間ボタンが選択不可の状態となる。また、フィーバータイムの発生時も選択不可の状態となる。よって、提供ユーザは発生指示操作をむやみに行うことはできず、当該操作のタイミングは多くの応援ポイントを獲得するための戦略の1つとなる。本実施形態では、制限回数は、1つのコンテンツの提供に当たり1回とする。
2.イベント制御
ストリーミングサーバ1100は、イベント発生条件を満たすと、その非発生時よりも大きな応援ポイントが算出され得るフィーバータイムを発生させる。本実施形態では、フィーバータイムの発生時に画像発信操作がなされると、発信された発信用画像8の加算ポイント数に所定数(例えば1.5)を乗じて応援ポイントに加算する。ここでのイベント制御により、フィーバータイムの発生時に画像発信操作を行えば、非発生時よりも応援ポイントを多く稼げる。
フィーバータイムの長さ(フィーバー時間長)は、予めイベント発生条件毎に定められ、延長もあり得る。本実施形態では、フィーバータイムが発生した後も連続コンボの連鎖条件を満たした状態が継続された場合に、そのフィーバータイム発生後の連鎖数Csに応じた時間長(延長時間長)分フィーバータイムの終了時刻を延長する。
また、フィーバータイム中に操作回数条件を満たした場合も、所定の延長時間長分フィーバータイムの終了時刻を延長する。この場合の延長時間長は、本実施形態では固定(例えば15秒)とする。
そして、ストリーミングサーバ1100は、フィーバータイムを発生させたならば、視聴画面にてフィーバータイム中である旨の演出表示を行う。図8は、フィーバータイム中の視聴画面W11の一例を示す図である。図8に示すように、フィーバータイムが発生すると、汎用表示部35において、フィーバータイム中であることを報知する通知と、フィーバータイムの残り時間の通知とが演出表示される。加えて、図8中に破線で囲って示すように、フィーバータイム中に視聴ユーザ2(図8では視聴ユーザ2a)から発信された発信用画像8の出現表示がフィーバータイムの非発生時とは変更されて、例えば、出現表示が華やかに演出される。なお、上記汎用表示部35における通知の表示箇所は、画面内であれば何処でもよい。また、視聴画面W11の背景をフィーバータイム用の背景に変更する等の演出表示を行ってもよい。
3.ランキング
さて、上記したように、応援ポイントは、配信コンテンツの盛り上がり度合或いは人気度合を表している。そこで、ストリーミングサーバ1100は、例えば1ヶ月毎や1週間毎等、所定の周期で応援ポイントに基づくランキングを算出する。本実施形態では、1ヶ月周期でランキングを算出する。ランキングの対象は、当該周期の期間内(ここでは過去1ヶ月間)に配信されたコンテンツとするが、配信済みの全てのコンテンツを対象としてもよい。
具体的には、ストリーミングサーバ1100は、当該周期の期間内に各提供ユーザが提供したコンテンツの中からその応援ポイントの最大値を提供ユーザ毎に読み出し、読み出した最大値を大きい順に並べて提供ユーザ別のランキング(提供ユーザ別ランキング)を算出する。また、当該周期の期間内に配信されたコンテンツをその応援ポイントの順に並べてコンテンツ別のランキング(コンテンツ別ランキング)を算出する。
そして、ストリーミングサーバ1100は、提供ユーザ別ランキングに基づき提供ユーザに特典を付与するとともに、コンテンツ別ランキングに基づき視聴ユーザに特典を付与する処理(第1特典付与処理)を実行する。
付与する特典の内容は、適宜設定可能である。具体的には、アイテム(例えば特定の発信用画像8が一定時間無料で使えるようになるアイテム等)、クーポン、抽選券、通貨ポイントとして使えるポイント等の付与が挙げられる。
より詳細には、予め提供ユーザ別ランキング及びコンテンツ別ランキングの各ランキング順位別に付与する特典を設定しておく。例えば、順位が高くなるにつれて付与するアイテムやポイント等の数を多く設定するのでもよいし、付与するアイテム等の種類を豊富にするのでもよい。また、順位が高くなるにつれて価値の高いアイテムを付与するとしてもよいし、それらを組み合わせて設定しておくのでもよい。また、特典を付与するランキング順位は、例えば1位~10位まで等適宜制限してよい。
そして、提供ユーザ別ランキングに基づく提供ユーザに対する特典の付与は、各ランキング順位の提供ユーザに対して該当するランキング順位の特典を付与することで行う。一方、コンテンツ別ランキングに基づく視聴ユーザに対する特典の付与は、該当するコンテンツを視聴した視聴ユーザにそのランキング順位の特典を配分することで行う。具体的には、視聴時になされた画像発信操作を視聴ユーザ毎に集計し、発信実績が高い(画像発信操作の回数が多い)視聴ユーザに対してより多くの特典(或いは価値の高い特典)が付与されるように山分けする。山分けの比率は、画像発信操作の回数に基づき決定すればよい。或いは、その画像発信操作で応援ポイントに加点された加算ポイント数の合計値を視聴ユーザ毎に求めてそれを発信実績とし、山分けの比率を決めてもよい。つまり、応援ポイントの獲得に貢献した視聴ユーザに対する特典の配分が多くなるような配分の手法であればよい。
なお、提供ユーザ別ランキングに基づいて、提供ユーザだけでなく視聴ユーザにも特典を付与する構成としてもよい。例えば、ランキング順位が上位の提供ユーザの当該応援ポイントを獲得したコンテンツの視聴ユーザに対し、特典を山分け配分して付与するとしてもよい。
以上説明したように、本実施形態では、イベント発生条件を満たした場合にフィーバータイムを発生させる。そして、このフィーバータイムの発生時に画像発信操作を行うと、非発生時に画像発信操作を行った場合よりも応援ポイントが多く加点される。したがって、各視聴ユーザは、当該加点を目的として、コンボゲージ353や発信内容表示部36に出現表示される他の視聴ユーザからの発信用画像8を見つつ互いに協働して、適宜画像発信操作アイコン34に対する発信用画像8の割り当て設定を変えながら、連続コンボや組合せコンボの連鎖条件を満たす画像発信操作を行うことができる。また、その他にも、操作回数条件を達成するために個々に画像発信操作を繰り返したり、ときに強制発生アイテムを使用して有償発生指示操作を行い、フィーバータイムを発生させることができる。或いは、視聴ユーザは、配信コンテンツの提供ユーザが発信指示操作を行って発生させたフィーバータイムにおいて画像発信操作を行い、その応援ポイントの獲得に貢献することができる。したがって、提供ユーザを沢山応援している感覚や場が盛り上がっている感覚を得やすくすることができ、視聴ユーザ間の一体感や連帯感をさらに高める新たな付加価値をもたらすことが可能となる。
また、本実施形態では、配信済みのコンテンツが獲得した応援ポイントに基づいて、所定周期毎(例えば1ヶ月毎)に提供ユーザ別ランキング及びコンテンツ別ランキングが算出される。そして、提供ユーザ別ランキングのランキング結果から、コンテンツの提供ユーザにそのランキング順位に見合った特典が付与される。一方、コンテンツ別ランキングのランキング結果から、コンテンツの視聴ユーザに対してそのランキング順位に応じた特典が付与される。その際、当該コンテンツの視聴時における発信実績(画像発信操作を行った回数)に応じて当該特典が各視聴ユーザに山分け配分される。つまり、発信実績が高い視聴ユーザに対して多くの特典が配分され、或いは価値の高い特典が配分される。したがって、視聴ユーザは、好きな(応援する)提供ユーザによって提供されたコンテンツであったり好きなジャンルのコンテンツ等のランキング入りや、それに伴い付与される特典を狙って視聴中に画像発信操作や有償発生指示操作を行い、より多くの応援ポイントの獲得を目指すことができる。また、提供ユーザは、自身が提供するコンテンツのランキング入りや、それに伴い付与される特典を狙ってコンテンツの提供時(配信時)に発生指示操作を行い、視聴ユーザに対して画像発信操作を促すことができる。
[機能構成]
1.ストリーミングサーバ
図9は、第1実施形態におけるストリーミングサーバ1100の機能構成例を示すブロック図である。図9に示すように、ストリーミングサーバ1100は、操作入力部100sと、サーバ処理部200sと、画像表示部390sと、音出力部392sと、通信部394sと、サーバ記憶部500sとを備える。
操作入力部100sは、システム管理や保守等のための各種操作を入力するためのものであり、例えばキーボードやマウス、タッチパネル等で実現できる。図1では、キーボード1106がこれに該当する。
サーバ処理部200sは、例えばCPUやGPU、ASIC、FPFA等の演算回路であるプロセッサや、ICメモリ等の電子部品によって実現でき、操作入力部100sやサーバ記憶部500sを含む装置各部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部100sからの操作入力信号、ユーザ端末1500から受信したデータ等に基づいて各種の演算処理を行い、ストリーミングサーバ1100の動作を統括制御する。図1では、制御基板1150やそのCPU1151がこれに該当する。
このサーバ処理部200sは、ユーザ管理部202と、オンラインショッピング管理部204と、配信サービス管理部206と、アバター表示制御部208と、発信サービス管理部210と、計時部280sと、画像生成部290sと、音生成部292sと、通信制御部294sとを備える。
ユーザ管理部202は、ユーザ登録に係る処理及びユーザアカウントに紐付けられる各登録ユーザのデータの管理を行う。例えば、登録ユーザへの固有のユーザアカウントの付与処理、ユーザアカウント別に個人情報を登録管理する登録情報管理処理、課金要素(例えば、オンラインショッピング等)の支払いで消費される電子決済媒体(例えば、仮想通貨の通貨ポイント)の帳簿管理処理、ログイン及びログアウトの履歴等を管理する利用履歴管理処理、アバター4の作成・編集処理等を実行することができる。勿論、これら以外のユーザアカウントに紐付けられる他のデータの管理処理も適宜含めることができる。
オンラインショッピング管理部204は、オンラインショッピングに関する制御を担い、公知のオンラインショッピング技術を適宜利用して実現できる。本実施形態では、視聴ユーザは、オンラインショッピングによって発信用画像や強制発生アイテム等を購入することができる。
配信サービス管理部206は、コンテンツの配信サービスを実現するための各種処理を行う。例えば、コンテンツの配信スケジュールの管理処理、視聴ユーザの管理処理、提供端末から配信用のコンテンツのデータを取得する処理、配信処理等を実行することができる。勿論、これら以外の処理も適宜含めることができる。
アバター表示制御部208は、視聴ユーザ別のアバターを、視聴端末である各視聴ユーザのユーザ端末1500(1500a,1500b,…)において発信内容表示部36に表示させる制御を行う。
発信サービス管理部210は、配信サービスと並行したユーザ発信サービスを実現するための各種処理を行う。この発信サービス管理部210は、発信内容表示制御部212と、応援ポイント算出部213と、イベント発生条件判定部215と、連鎖報知制御部221と、対価徴収処理部223と、イベント制御部225と、ランキング算出部227と、第1特典付与処理部229とを含む。
発信内容表示制御部212は、配信コンテンツに対する発信操作(テキスト発信操作/画像発信操作)が入力されたことを視聴端末から受け付けて、当該発信操作に係る発信内容を、各視聴端末にて発信内容表示部36に表示させる制御を行う。ここでの制御により、視聴端末の発信内容表示部36における吹き出し5によるテキストの表示や、発信用画像8の出現表示が実現される。なお、ストリーミングサーバ1100が、発信内容表示部36として表示される画像それ自体を配信の対象とする場合には、発信内容表示制御部212がその画像を生成するとしてもよい。
応援ポイント算出部213は、画像発信操作が入力されたことを視聴端末から受け付けて、当該画像発信操作を集計して応援ポイントを更新・管理する処理(応援ポイント算出処理)を実行する。
イベント発生条件判定部215は、イベント発生条件である連続コンボ発生条件、組合せコンボ発生条件、操作回数条件、及び強制発生条件を判定する。このイベント発生条件判定部215は、そのうちの連続コンボ発生条件を判定する連続コンボ判定部217と、組合せコンボ発生条件を判定する組合せコンボ判定部219とを含む。
連続コンボ判定部217は、連続コンボの発生認定を行って連続コンボ発生条件を満たすか否かを判定する処理(連続コンボ判定処理)を実行する。
組合せコンボ判定部219は、組合せコンボの発生認定を行って組合せコンボ発生条件を満たすか否かを判定する処理(組合せコンボ判定処理)を実行する。
連鎖報知制御部221は、フィーバータイムの非発生時において、連続コンボ判定処理で設定・更新される現連続コンボ連鎖数619(図16を参照)をゲージ値とするコンボゲージ353を、各視聴端末にて汎用表示部35に表示させる制御を行う。
対価徴収処理部223は、提供ユーザの発生指示操作に際してその対価を徴収する処理を行う。例えば、発生指示操作を行った提供ユーザの通貨ポイントから所定数を消費し、決済媒体帳簿データ592を更新する。
イベント制御部225は、画像発信操作に基づく条件を含むイベント発生条件(本実施形態では、連続コンボ発生条件、組合せコンボ発生条件、操作回数条件、及び強制発生条件)を満たした場合にイベント制御を行い、フィーバータイムを発生させる。
このイベント制御部225は、フィーバータイム延長処理部226を備える。フィーバータイム延長処理部226は、連続コンボ発生条件を満たしたことを受けてフィーバータイムを発生させた後も引き続き連続コンボの連鎖条件を満たした状態が継続されたか否かを判定し、フィーバータイム発生後の連鎖数Csに応じてフィーバータイム終了時刻633を延長する。具体的には、フィーバータイム中、連続コンボの連鎖条件を満たした状態が継続する間は連続コンボ連鎖数を数えて現連続コンボ連鎖数619を更新する。そして、フィーバータイム終了時刻633においてフィーバータイム定義データ580の延長設定に従って延長時間長を決定し、フィーバータイム終了時刻633を更新する。すなわち、現連続コンボ連鎖数619と適用連続コンボ基準値703との差を連鎖数Csとして求め、所定時間(例えば3秒)を乗じた延長時間長をフィーバータイム終了時刻633に加えて更新する。また、フィーバータイム延長処理部226は、フィーバータイム中に操作回数条件を満たした場合にフィーバータイム定義データ580の延長設定から延長時間長を読み出し、フィーバータイム終了時刻633を更新する。なお、延長時間には上限を設けることとすると好適である。
ランキング算出部227は、例えば1ヶ月毎等の所定周期で応援ポイントに基づくランキングを算出する。本実施形態では、提供ユーザ別ランキングと、コンテンツ別ランキングとを算出する。
第1特典付与処理部229は、提供ユーザ別ランキングに基づき提供ユーザに特典を付与するとともに、コンテンツ別ランキングに基づき視聴ユーザに特典を付与する第1特典付与処理を実行する。
計時部280sは、システムクロックを利用して現在日時や制限時間等の計時を行う。
画像生成部290sは、ストリーミングサーバ1100のシステム管理等に関する画像を生成し、画像表示部390sへ出力する。
音生成部292sは、音声データの生成やデコードをするICやソフトウェアの実行により実現され、ストリーミングサーバ1100のシステム管理や動画配信に係る操作音、BGM等の音声データを生成し、或いはデコードする。システム管理に関する音声信号は、音出力部392sへ出力される。
通信制御部294sは、通信部394sを介して外部装置(例えばユーザ端末1500)とのデータ通信のための通信接続及びデータ処理を行い、外部装置とのデータのやりとりを実現する。
画像表示部390sは、画像生成部290sから入力される画像信号に基づいてシステム管理等のための各種画面を表示する。例えば、フラットパネルディスプレイ、ブラウン管(CRT)、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図1では、タッチパネル1108がこれに該当する。
音出力部392sは、音生成部292sから入力される音信号を放音する。図1では、本体装置1101やタッチパネル1108が備えるスピーカ(不図示)がこれに該当する。
通信部394sは、通信回線9と接続して通信を実現する。例えば、無線通信機、モデム、TA(ターミナルアダプタ)、有線用の通信ケーブルのジャックや制御回路等によって実現できる。図1では、通信装置1153がこれに該当する。
サーバ記憶部500sには、ストリーミングサーバ1100を動作させ、ストリーミングサーバ1100が備える種々の機能を実現するためのプログラムや、このプログラムの実行中に使用されるデータ等が予め格納され、或いは処理の都度一時的に格納される。例えば、RAMやROM等のICメモリ、ハードディスク等の磁気ディスク、CD-ROMやDVD等の光学ディスク等によって実現できる。図1では、ICメモリ1152がこれに該当する。
図10は、第1実施形態のサーバ記憶部500sが記憶するプログラムやデータの例を示す図である。図10に示すように、サーバ記憶部500sには、サーバプログラム503と、配信用視聴端末プログラム505と、配信用提供端末プログラム507と、販売品管理データ509と、発信サービス初期設定データ510と、ユーザ管理データ590と、配信管理データ600と、連続コンボ条件設定700と、組合せコンボ条件設定710と、操作回数条件設定720と、適用倍率730と、ランキングデータ740と、現在日時900とが格納される。また、その他にも、例えば、視聴画面W1,W11の背景画像の画像データや、アバターを作成・編集するための素材データ等、必要なデータが適宜格納される。
サーバプログラム503は、サーバ処理部200sをユーザ管理部202、オンラインショッピング管理部204、配信サービス管理部206、アバター表示制御部208、及び発信サービス管理部210として機能させるためのプログラムである。なお、画像生成部290sや音生成部292s、通信制御部294sとして機能させるプログラムも適宜これに含めることができる。
配信用提供端末プログラム507は、提供端末として使用されるユーザ端末1500にダウンロードされるアプリケーションプログラムのオリジナルデータであって、これを実行することにより、そのユーザ端末1500は提供端末として機能できるようになる。なお、配信用提供端末プログラム507は、ライブ配信機能を実装したゲームを実行可能にするためのゲームプログラムの中に含まれている構成も可能である。
配信用視聴端末プログラム505は、視聴端末として使用されるユーザ端末1500にダウンロードされるアプリケーションプログラムのオリジナルデータであって、これを実行することにより、そのユーザ端末1500は視聴端末として機能できるようになる。
販売品管理データ509は、オンラインショッピングによる販売品(販売対象)を定義・管理するためのデータである。例えば、販売品管理データ509は、購入可能なデータを、その在庫数や、課金対価(電子決済媒体からの引き落とし額に相当)等と対応付けて格納している。
発信サービス初期設定データ510は、ユーザ発信サービスのための各種初期設定データを格納する。本実施形態では、発信用画像定義データ520と、イベント発生条件データ530と、フィーバータイム定義データ580と、特典定義データ543とを含む。
発信用画像定義データ520は、発信用画像8を定義するデータである。1つの発信用画像定義データ520は、例えば図11に示すように、発信用画像種類521と、発信用画像データ523と、加算ポイント数525と、販売価格527と、当該発信用画像が発信内容表示部36に表示されてから消失するまでの表示持続時間529とを含む。
イベント発生条件データ530は、イベント発生条件を定義するデータであり、連続性認定条件定義データ531と、関連性認定条件定義データ540と、連続コンボ規模要件定義データ550と、組合せコンボ規模要件定義データ560と、操作回数条件定義データ570とを含む。
連続性認定条件定義データ531は、時間的に隣接する画像発信操作が連続性を有すると見做すための条件を定義する。本実施形態では、連続性認定時間差Δt(図5を参照)を定義している。なお、連続性認定条件定義データ531は、1つの連続性認定時間差Δtを定義しておく構成に限らず、例えばジャンル等の配信コンテンツの内容に応じて連続性認定条件を違えたい場合には、選択条件別(例えばジャンル別)に異なる連続性認定時間差Δtを対応付けて定義しておけばよい。
関連性認定条件定義データ540は、関連性を認定するための条件を定義するデータを格納する。1つの関連性認定条件定義データ540は、例えば図12に示すように、固有の関連性ID541と、当該定義データが選択・適用される条件を記述する選択条件542と、関連性認定条件544とを含む。
選択条件542は、例えば、ジャンル条件542aと、提供ユーザ条件542bと、被写体条件542cと、状況条件542dと、視聴ユーザ数条件542eとを含み、それらのAND条件又はOR条件として記述される。選択条件542が含むこれらの条件は、何れも「設定なし」を含み得る。
ジャンル条件542aは、配信コンテンツのジャンルについての条件である。例えば、「ライブ中継」の時だけに適用される関連性認定条件を用意することもできる。
提供ユーザ条件542bは、提供ユーザに関する情報についての条件である。例えば、提供ユーザの年齢や性別、好きなもの等のプロフィール情報、特定ゲームタイトルにおけるプレーヤレベルや称号、配信サービスにおける当該提供ユーザのランキング順位等についての条件を設定できる。
被写体条件542cは、配信コンテンツの主たる被写体についての条件である。例えば、提供ユーザ自身、子供、動物、料理、自動車、チーム、ゲームキャラクタ等であり、それらの固有名を含めることもできる。その場合、複数の固有名をAND条件又はOR条件として定義してもよい。
状況条件542dは、配信コンテンツの内容の状況についての条件である。コンテンツの付帯情報には、例えば、「(曲名)を演奏してみた」「(番組名のエンディング)を踊ってみた」「(製品名)の開封」「(ゲームタイトル)のステージ難所をクリア」「(ゲームタイトル)の第4ステージボスキャラ攻略」といった状況説明文を含めることができる。状況条件542dは、それらに含まれるキーワードを設定することにより定義付けできる。
視聴ユーザ数条件542eは、配信コンテンツの視聴ユーザの数についての条件である。
関連性認定条件544は、共通点条件544aと、シリーズ条件544bと、のAND条件又はOR条件として記述される。関連性認定条件544が含むこれらの条件は、何れも「設定なし」を含み得る。
共通点条件544aは、連続性を有する複数の画像発信操作の発信内容である発信用画像8に共通するべき要件を定義する。例えば、共通点を有する発信用画像種類のリストや、発信用画像8に含まれる(描かれている)共通のテキスト、主要配色、共通と認められる被写体種類のリスト等を設定することができる。なお、画像発信操作だけでなくテキスト発信操作も含めて関連性を認定する場合には、発信内容であるテキスト同士や発信用画像8とテキストとに共通するべき要件を定義しておけばよい。その場合、主要配色は、発信用画像8の他、発信されたテキストのフォントカラーにも適用できる。
より具体的には、例えば、共通点条件544aとして主要配色が同じ(例えば赤色)発信用画像種類のリストを定義する一方で、提供ユーザ条件542bに「好きな色が赤色であること」を設定すれば、連続性を有するとされた各発信用画像8の主要配色が提供ユーザの好きな赤色と一致する場合に関連性有りと認定する関連性認定条件を定義でき、これにより、提供ユーザと発信用画像8とを関連付けることができる。
シリーズ条件544bは、連続性を有する複数の画像発信操作の発信内容である発信用画像8の組み合わせを定義する。例えば、組合せに係る発信用画像種類のリスト、組合せに係る主要配色のリスト、組合せに係る発信用画像8に含まれている(描かれている)テキストのリスト等であり、それらの発信順も定義に含めることができる。なお、画像発信操作だけでなくテキスト発信操作も含めて関連性を認定する場合には、例えば発信されたテキストに含まれるキーワードの組合せ、発信用画像種類とテキスト(キーワード)との組合せ等を定義しておくことができる。
より具体的には、例えば、「四季の花」と言うタイトルの発信用画像8のシリーズがあったとして、当該シリーズを構成する発信用画像種類のリストを定義すれば、四季の花の発信用画像8の発信が時系列に揃ったときに関連性有りと認定される関連性認定条件を定義できる。また、主要配色のリストとして発信順が虹におけるそれらの配列順と同じとなるように虹の構成色を設定すれば、連続性を有するとされた各発信用画像8に描かれているものが何であれ、発信順に並べると虹と同じ配色パターンを構成していれば関連性有りと認定される関連性認定条件を定義できる。
或いは、シリーズ条件544bとして音楽演奏のアクションを内容とする発信用画像種類のリストを定義する一方、ジャンル条件542aに「音楽演奏」を設定すれば、連続性を有するとされた各発信用画像8が配信コンテンツのジャンルに合った発信用画像8の場合に関連性有りと認定する関連性認定条件を定義でき、これにより、配信コンテンツと発信用画像8とを関連付けることができる。
図10に戻り、連続コンボ規模要件定義データ550は、連続コンボの発生を認定する際に必要とされる規模要件を定義する。本実施形態では連続コンボ基準値(例えば10連鎖)を定義する。なお、例えばジャンル等の配信コンテンツの内容に応じて規模要件を違えたい場合には、関連性認定条件定義データ540の選択条件542と同様の関係条件を対応付けた複数の連続コンボ規模要件定義データを用意しておけばよい。
組合せコンボ規模要件定義データ560は、組合せコンボの発生を認定する際に必要とされる規模要件を定義するデータを格納する。1つの組合せコンボ規模要件定義データ560は、例えば図13に示すように、固有の規模要件ID561と、対応する関連性ID541を格納する対応関連性ID563と、組合せコンボ基準値565とを含み、対応関連性ID563によって関連性認定条件定義データ540と対応付けられる。
操作回数条件定義データ570は、発信操作総数基準値を定義する。本実施形態では、発信操作総数基準値は、視聴ユーザの数×所定数(20回)として設定される。
フィーバータイム定義データ580は、図14に示すように、フィーバータイムの発生時に適用する倍率(例えば1.5倍)581を格納するとともに、各イベント発生条件(連続コンボ発生条件、組合せコンボ発生条件、操作回数条件、及び強制発生条件)と対応付けて、そのフィーバー時間長と、延長設定とを格納する。フィーバー時間長は、対応するイベント発生条件を満たしたときに発生させるフィーバータイムの時間長である。延長設定は、フィーバータイムが延長され得る連続コンボ発生条件及び操作回数条件について延長時間長を格納する。例えば、連続コンボ発生条件の延長時間長は、連鎖数Csに所定時間(図14では3秒)を乗じた時間長として定義される。一方、操作回数条件の延長時間長は、固定長(図14では15秒)として設定される。なお、倍率581は、例示したように各イベント発生条件に一律に適用される値に限らず、イベント発生条件の種類毎に別個の値を設定しておく構成でもよい。
特典定義データ543は、提供ユーザ用の特典定義データ543と、視聴ユーザ用の特典定義データ543とを含む。提供ユーザ用の特典定義データ543には、提供ユーザ別ランキングに係る各ランキング順位と対応付けて、該当する提供ユーザに付与される特典の内容が設定される。一方、視聴ユーザ用の特典定義データ543には、コンテンツ別ランキングに係る各ランキング順位と対応付けて、該当するコンテンツの視聴ユーザに付与(山分け配分)される特典の内容が設定される。
ユーザ管理データ590は、登録ユーザ毎に用意される。1つのユーザ管理データ590は、例えば図15に示すように、固有のユーザアカウント591と、決済媒体帳簿データ592と、アバター設定データ593と、保有発信用画像リスト594と、保有強制発生アイテム数595と、発信ログデータ596とを含む。
決済媒体帳簿データ592は、当該ユーザに紐付けられる電子決済媒体(本実施形態では通貨ポイント)の収支の情報、例えば、通貨ポイントの購入日時や購入数(課金額)の履歴、通貨ポイントの消費日時や消費数の履歴等を格納する。
アバター設定データ593は、当該ユーザのアバター4の設定データを格納する。
保有発信用画像リスト594は、当該ユーザが保有している発信用画像8の発信用画像種類と対応付けて、その保有数を格納する。
発信ログデータ596は、当該ユーザが視聴ユーザとして発信操作(テキスト発信操作/画像発信操作)をする毎に作成される。1つの発信ログデータ596は、例えば、発信日時、発信対象の配信タイトル、当該発信対象のコンテンツを提供した提供ユーザのユーザアカウント、発信内容(発信されたテキストや発信用画像種類)等を格納する。
配信管理データ600は、配信毎に用意され、配信状況を記述する各種データを格納する。1つの配信管理データ600は、例えば図16に示すように、配信タイトル601と、配信スケジュール603と、コンテンツデータ605と、付帯情報607と、視聴ユーザ管理データ609と、アバター表示管理データ611と、テキスト発信実績データ613と、画像発信実績データ615と、現応援ポイント617と、現連続コンボ連鎖数619と、現組合せコンボ連鎖数621、現発信操作総数623と、発生指示操作フラグ625と、フィーバータイム発生状況データ630とを含む。その他にも、例えば、視聴画面(例えば視聴画面W1や視聴画面W11)の背景を定義した背景データや、フィーバータイム中の各種演出表示を行うための素材データが格納される。
視聴ユーザ管理データ609は、当該配信に係るコンテンツ(配信コンテンツ)について視聴者登録された視聴ユーザに関する各種データを格納する。例えば、当該視聴者登録された全ての視聴ユーザのユーザアカウントと対応付けて、当該視聴ユーザのユーザ端末1500に通信回線9を介して通信接続するためのアクセス情報(例えばIPアドレス)等を格納する。
アバター表示管理データ611は、発信内容表示部36における各視聴ユーザのアバターの表示状況を記述する各種データを格納する。例えば、各視聴ユーザのユーザアカウントと対応付けて、そのアバターデータや配置位置座標、表示サイズ等が設定される。
画像発信実績データ615は、視聴端末において視聴ユーザが画像発信操作する毎に作成される。1つの画像発信実績データ615は、発信者である視聴ユーザのユーザアカウントと、発信タイミングと、発信内容データ(発信された発信用画像データ)と、その表示持続時間(表示持続時間529のコピー)とを含む。
テキスト発信実績データ613は、視聴端末において視聴ユーザがテキスト発信操作する毎に作成される。1つのテキスト発信実績データ613は、発信者である視聴ユーザのユーザアカウントと、発信タイミングと、発信内容データ(発信されたテキスト、フォント、フォントサイズ等)と、その表示持続時間とを含む。
発生指示操作フラグ625は、提供ユーザによる発生指示操作の有無(有:ON/無:OFF)を格納する。イベント発生条件判定部215は、コンテンツの配信開始時に発生指示操作フラグ625を「OFF」に初期化し、発生指示操作フラグ625が「OFF」の間だけ提供ユーザの発生指示操作を受け付ける。そして、発生指示操作が入力されたことを提供端末から受け付けると、発生指示操作フラグ625を「ON」に更新する。
フィーバータイム発生状況データ630は、フィーバータイム発生フラグ(発生時:ON/非発生時:OFF)631と、フィーバータイム終了時刻633とを格納する。
図10に戻り、連続コンボ条件設定700は、適用連続性認定条件701と、適用連続コンボ基準値703とを含む。本実施形態では、連続性認定条件は固定なので、適用連続性認定条件701には、連続性認定条件定義データ531がコピーされる。適用連続コンボ基準値703には、連続コンボ規模要件定義データ550がコピーされる。
組合せコンボ条件設定710は、適用連続性認定条件711と、適用関連性認定条件713と、適用組合せコンボ基準値715とを含む。適用連続性認定条件711には、連続性認定条件定義データ531がコピーされる。適用関連性認定条件713には、複数種類ある関連性認定条件定義データ540の中から選択条件542が適合するとして検索された定義データの関連性ID541がコピーされる。適用組合せコンボ基準値715には、適用関連性認定条件713の関連性IDが対応関連性ID563として設定された組合せコンボ規模要件定義データ560の組合せコンボ基準値565がコピーされる。
操作回数条件設定720には、操作回数条件定義データ(発信操作総数基準値)570がコピーされる。
適用倍率730には、フィーバータイムの非発生時には「等倍」が設定され、フィーバータイムの発生時には、フィーバータイム定義データ580の倍率581が設定される。
ランキングデータ740は、ランキング算出部227により所定周期毎に算出される提供ユーザ別ランキングのランキング結果及びコンテンツ別ランキングのランキング結果を格納する。
2.視聴端末
図17は、視聴端末となるユーザ端末1500(1500a,1500b,…)の機能構成例を示すブロック図である。図17に示すように、視聴端末となるユーザ端末1500(1500a,1500b,…)は、操作入力部100と、撮像部102と、集音部104と、端末処理部200と、画像表示部390と、音出力部392と、通信部394と、端末記憶部500とを備える。
操作入力部100は、ユーザが各種操作を入力するためのものであり、例えば、ボタンスイッチ、ジョイスティック、タッチパッド、トラックボール、加速度センサ、角速度センサ等によって実現できる。図2では、方向入力キー1502やホームキー1504、タッチパネル1506がこれに該当する。
撮像部102は、撮影対象からの光を受光して電気信号に変換し、デジタル画像データを生成して端末処理部200へ出力する。例えば、レンズ、メカシャッター、シャッタードライバ、CCDイメージセンサモジュールやCMOSイメージセンサモジュールといった光電変換素子、光電変換素子から電荷量を読み出し画像データを生成するデジタルシグナルプロセッサ(DSP)、ICメモリ等で実現できる。図2では、イメージセンサモジュール1520がこれに該当する。
集音部104は、集音した音声を電気信号に変換して出力する。図2では、マイク1512がこれに該当する。
端末処理部200は、例えばCPUやGPU、ASIC、FPGA等の演算回路であるプロセッサや、ICメモリ等の電子部品によって実現でき、操作入力部100や端末記憶部500を含む装置各部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部100からの操作入力信号、ストリーミングサーバ1100から受信したデータ等に基づいて各種の演算処理を行い、視聴端末としてのユーザ端末1500の動作を統括制御する。図2では、制御基板1550やそのCPU1551がこれに該当する。そして、本実施形態における視聴端末の端末処理部200は、視聴端末演算部260と、計時部280と、音生成部292と、通信制御部294とを備える。
視聴端末演算部260は、操作信号送信制御部262と、視聴画面表示制御部264とを含む。
操作信号送信制御部262は、操作入力部100に対する操作入力に応じて、各種データやリクエスト情報をストリーミングサーバ1100へ送信するための処理を行う。
視聴画面表示制御部264は、ストリーミングサーバ1100から受信した各種データに基づいて視聴画面W1,W11を表示するための制御を行う。
音生成部292は、例えばDSPや音声合成IC等のプロセッサ、音声ファイル再生可能なオーディオコーデック等によって実現され、動画配信に係る効果音、BGM、各種操作音の音信号を生成して音出力部392へ出力する。
通信制御部294は、通信部394を介して外部装置(例えばストリーミングサーバ1100)とのデータ通信のための通信接続及びデータ処理を行い、外部装置とのデータのやりとりを実現する。
画像表示部390は、視聴画面表示制御部264から入力される画像信号に基づいて視聴画面W1,W11等の各種画面を表示する。例えば、フラットパネルディスプレイ、ブラウン管(CRT)、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図2では、タッチパネル1506がこれに該当する。
音出力部392は、音生成部292から入力される音信号に基づいてBGM等を音出力する。図2では、スピーカ1510がこれに該当する。
通信部394は、通信回線9と接続して通信を実現する。例えば、無線通信機、モデム、TA、有線用の通信ケーブルのジャックや制御回路等によって実現できる。図2では、無線通信モジュール1553がこれに該当する。
端末記憶部500には、ユーザ端末1500を視聴端末として動作させ、ユーザ端末1500が備える視聴端末としての機能を実現するためのプログラムや、このプログラムの実行中に使用されるデータ等が予め格納され、或いは処理の都度一時的に格納される。例えば、RAMやROM等のICメモリ、ハードディスク等の磁気ディスク、CD-ROMやDVD等の光学ディスク等によって実現できる。図2では、ICメモリ1552や、メモリカード1540がこれに該当する。
また、視聴端末の端末記憶部500には、視聴端末プログラム504と、受信済配信データ群800と、発信用画像割り当て設定802と、現在日時900とが格納される。勿論、これら以外のプログラムやデータも適宜格納することができる。
視聴端末プログラム504は、端末処理部200を視聴端末演算部260として機能させるためのプログラムである。本実施形態では、ストリーミングサーバ1100から提供される配信用視聴端末プログラム505(図10参照)のコピーとする。
受信済配信データ群800は、配信に際し、ストリーミングサーバ1100から受信した各種配信データを格納する。
発信用画像割り当て設定802は、画像発信操作アイコン34への発信用画像8の割り当てを示す。具体的には、割り当てられている発信用画像8の発信用画像種類を格納する。
3.提供端末
図18は、提供端末となるユーザ端末1500(1500T)の機能構成例を示すブロック図である。なお、図18において、視聴端末となるユーザ端末1500(1500a,1500b,…)と同様の構成には同一の符号を付して示している。
提供端末となるユーザ端末1500(1500T)では、端末処理部200は、所定のプログラムやデータ、操作入力部100からの操作入力信号、ストリーミングサーバ1100から受信したデータ等に基づいて各種の演算処理を行い、提供端末としてのユーザ端末1500の動作を統括制御する。そして、提供端末の端末処理部200は、提供端末演算部270と、計時部280と、音生成部292と、通信制御部294とを備える。
提供端末演算部270は、操作信号送信制御部272と、コンテンツ提供制御部274と、提供画面表示制御部276とを含む。
操作信号送信制御部272は、操作入力部100に対する操作入力に応じて、各種データやリクエスト情報をストリーミングサーバ1100へ送信するための処理を行う。
コンテンツ提供制御部274は、配信用のコンテンツのデータの生成と、ストリーミングサーバ1100への提供制御に関する処理を行う。ライブ配信の場合は、撮像部102で撮影された画像を逐一エンコードして、ストリーミングサーバ1100へ提供制御する、ライブストリーミングエンコーダとしての機能を実現する。
提供画面表示制御部276は、提供画面を表示するための制御を行う。提供画面は、コンテンツのライブ配信のための各種操作を受け付ける操作画面であり、配信状況をモニタするモニタ画面を兼ねている。
端末記憶部500には、ユーザ端末1500を提供端末として動作させ、ユーザ端末1500が備える提供端末としての機能を実現するためのプログラムや、このプログラムの実行中に使用されるデータ等が予め格納され、或いは処理の都度一時的に格納される。例えば、RAMやROM等のICメモリ、ハードディスク等の磁気ディスク、CD-ROMやDVD等の光学ディスク等によって実現できる。
また、提供端末の端末記憶部500には、提供端末プログラム506と、受信済配信データ群800と、提供コンテンツデータ810と、現在日時900とが格納される。勿論、これら以外のプログラムやデータも適宜記憶することができる。
提供端末プログラム506は、端末処理部200を提供端末演算部270として機能させるためのプログラムである。本実施形態では、ストリーミングサーバ1100から提供される配信用提供端末プログラム507(図10参照)のコピーとする。
受信済配信データ群800は、コンテンツの提供に際し、ストリーミングサーバ1100から受信した各種配信データを格納する。
提供コンテンツデータ810は、登録時配信タイトル811と、登録時配信スケジュール813と、登録時付帯情報815と、提供用コンテンツデータ817とを含む。登録時配信タイトル811や登録時配信スケジュール813、登録時付帯情報815は、それぞれ提供ユーザとして配信登録手続きをした際の設定データを格納する。提供用コンテンツデータ817は、配信用のコンテンツのオリジナルデータである。
[処理の流れ]
1.ストリーミングサーバ
図19~図21は、ストリーミングサーバ1100におけるコンテンツのライブ配信に係る処理の流れを示すフローチャートである。ここで説明する処理は、サーバ処理部200sがサーバプログラム503を読み出して実行することによって実現される。なお、ランキング算出部227による提供ユーザ別ランキング及びコンテンツ別ランキングの算出と、第1特典付与処理部229によるそれらランキングに基づく特典の付与(第1特典付与処理)は、本処理とは別に所定の周期毎に行う。
ここで、コンテンツの配信タイトルや配信スケジュール、付帯情報は、提供ユーザによる配信登録手続きに伴い既に設定されているものとする。また、視聴ユーザの視聴端末は、別途ログイン手続き済みであるものとする。
先ず、配信サービス管理部206が、配信管理データ600を初期化する(ステップS100)。なお、配信タイトル601、配信スケジュール603、付帯情報607は、配信登録手続きに伴い設定済みである。コンテンツデータ605は、ライブ配信なので配信開始までは記憶されない。もし、ライブ配信でなければ、予め用意されたコンテンツのデータが格納されることになる。
続いて、配信サービス管理部206は、視聴ユーザ管理データ609に基づいて、例えばアバター表示管理データ611やテキスト発信実績データ613、画像発信実績データ615、現応援ポイント617、現連続コンボ連鎖数619、現組合せコンボ連鎖数621、現発信操作総数623、発生指示操作フラグ625、フィーバータイム発生状況データ630、保有発信用画像リスト594、保有強制発生アイテム数595等の視聴端末及び提供端末に対する各種配信データの配信を開始する(ステップS102:配信α)。配信タイミングは、例えば、それら配信データが追加・削除・更新された時や、新たな視聴ユーザの登録時等とすることができるが、所定周期で配信するとしてもよい。
その後、配信サービス管理部206は、視聴リクエストの受信を監視する(ステップS104)。視聴リクエストは、視聴端末として機能しているユーザ端末1500(1500a,1500b,…)にて視聴ユーザが視聴したい配信タイトルを選択し、所定の視聴操作をすると、ユーザアカウント等の情報とともにストリーミングサーバ1100へと送信される。
この視聴リクエストを受信すると(ステップS104のYES)、配信サービス管理部206は、新たに視聴ユーザ管理データ609を作成して当該視聴端末のユーザを視聴ユーザとして視聴者登録する(ステップS106)。
そして、アバター表示制御部208が、新たなアバター表示管理データ611を作成し、当該視聴ユーザに係るアバターが発信内容表示部36に表示されるようにする(ステップS108)。
前述のようにステップS102にてアバター表示管理データ611の配信は開始されているので、新たに作成したアバター表示管理データ611もまた視聴端末に配信される。視聴端末では、これに基づき各アバターの表示を更新することになる。結果、視聴画面W1では、新たな仮想視聴者がスクリーンの前に出現したかのように見える。
これにより、配信を皆で一緒に視聴する仮想体験がよりリッチなものになり、視聴者の一体感が醸し出される。そして、視聴者の一体感が、みんなで視聴環境を盛り上げようという想いとなり、それが視聴ユーザによる積極的な発信を促し、ついには本実施形態の配信サービスが従来の配信サービス以上に楽しい充実したユーザ体験をもたらす要因の1つとなる。
続いて、オンラインショッピング管理部204が、購入リクエストの受信を監視する(ステップS110)。購入リクエストは、視聴端末にて視聴ユーザが所定の購入操作(例えば、図3のショッピングアイコン37への操作)を行うと、ストリーミングサーバ1100へ送信される。
この購入リクエストを受信すると(ステップS110のYES)、オンラインショッピング管理部204は、発信用画像や強制発生アイテムの購入処理等、オンラインショッピングに係る処理を実行する(ステップS112)。この購入にともなって、購入リクエストした視聴ユーザの保有発信用画像リスト594や保有強制発生アイテム数595が更新され、これもまた視聴端末へと配信される。
また、発信サービス管理部210が、テキスト発信リクエストの受信を監視する(ステップS114)。テキスト発信リクエストは、視聴端末にて視聴ユーザがテキスト発信操作を行うと、ユーザアカウントや発信内容(テキスト)等の情報とともにストリーミングサーバ1100へと送信される。
このテキスト発信リクエストを受信すると(ステップS114のYES)、発信サービス管理部210は、受信した新たな発信内容についてテキスト発信実績データ613を作成し、リクエストした視聴ユーザの発信ログデータ596を作成して更新する(ステップS116)。
このように、ライブ配信前であっても、視聴ユーザは、テキスト発信したり、発信用画像等の購入が可能となり、ライブが始まる前に視聴ユーザ間で思い思いにライブへの期待を語りあったり、ライブ開始に備えた発信用画像等の準備ができる。
その後、ライブ配信の開始予定時刻に達すると(ステップS118のYES)、配信サービス管理部206は、コンテンツのライブ配信を開始する(ステップS120)。ここでの処理により、提供端末からのコンテンツデータの受信と、その視聴端末への配信とが開始される。
コンテンツの配信を開始したならば、連続コンボ判定部217が連続コンボ判定処理を開始する(ステップS122)。ここで開始される連続コンボ判定処理では、先ず、連続性認定条件定義データ531を適用連続性認定条件701に格納するとともに、連続コンボ規模要件定義データ550を適用連続コンボ基準値703に格納する。また、現連続コンボ連鎖数619を「0」に初期化する。
そして、連続コンボ判定処理では、画像発信リクエストを受信するたびに次の処理を行う。すなわち先ず、適用連続性認定条件(連続性認定時間差Δt)701に基づいて、1つ前の発信実績データ636との発信タイミングの時間差がΔt以下であるか否かを判定する。そして、Δt以下であれば、現連続コンボ連鎖数619を1つ増やして更新する。その上で、現連続コンボ連鎖数619が適用連続コンボ基準値703に達しており規模要件を満たす場合には、連続コンボ発生条件を満たすと判定する。なお、Δtを超えている場合には、現連続コンボ連鎖数619を「0」にする。
また、組合せコンボ判定部219が組合せコンボ判定処理を開始する(ステップS124)。ここで開始される組合せコンボ判定処理では、先ず、連続性認定条件定義データ531を適用連続性認定条件711に格納する。次に、複数の関連性認定条件定義データ540の中から選択条件542が適合する定義データを検索して、検索された関連性認定条件定義データ540を適用関連性認定条件713に格納する。そして、複数の組合せコンボ規模要件定義データ560の中から適用関連性認定条件713の関連性IDが対応関連性ID563として設定された定義データを検索して、検索された組合せコンボ規模要件定義データ560の組合せコンボ基準値565を適用組合せコンボ基準値715に格納する。また、現組合せコンボ連鎖数621を「0」に初期化する。
そして、組合せコンボ判定処理では、画像発信リクエストを受信するたびに次の処理を行う。すなわち先ず、適用連続性認定条件(連続性認定時間差Δt)711に基づいて、1つ前の発信実績データ636との発信タイミングの時間差がΔt以下であるか否かを判定する。そして、Δt以下の場合は、今回の発信用画像8と1つ前の発信用画像8とが適用関連性認定条件713の関連性認定条件を満たすか否かを判定し、満たす場合は、現組合せコンボ連鎖数621を1つ増やして更新する。その上で、現連続コンボ連鎖数619が適用組合せコンボ基準値715に達しており規模要件を満たす場合には、組合せコンボ発生条件を満たすと判定する。なお、Δtを超えている場合には、現連続コンボ連鎖数619を「0」にする。
また、イベント発生条件判定部215が、操作回数条件定義データ570を操作回数条件設定720に格納する(ステップS126)。
また、応援ポイント算出部213が応援ポイント算出処理を開始する(ステップS128)。ここで開始される応援ポイント算出処理では、応援ポイント算出部213は、画像発信リクエストの受信を監視する。画像発信リクエストは、視聴端末にて視聴ユーザが画像発信操作を行うと、ユーザアカウントやその発信内容である発信用画像8の発信用画像種類とともにストリーミングサーバ1100へと送信される。発信用画像8の画像データそのものが送信される構成でもよい。
そして、画像発信リクエストを受信するたびに、その発信用画像8の加算ポイント数525に適用倍率730を乗じて調整し、応援ポイントに加算する。後述するステップS178では、フィーバータイム中の適用倍率730を「等倍」からフィーバータイム用の例えば「1.5倍」に変更する。したがって、フィーバータイム中は、加算ポイント数が1.5倍されて応援ポイントに加算される。
その後は、図20に示すように、オンラインショッピング管理部204が、購入リクエストの受信を監視する(ステップS130)。そして、購入リクエストを受信した場合は(ステップS130のYES)、オンラインショッピングに係る処理を実行する(ステップS132)。
また、発信サービス管理部210が、テキスト発信リクエストの受信を監視する(ステップS134)。そして、テキスト発信リクエストを受信した場合は(ステップS134のYES)、受信した新たな発信内容についてテキスト発信実績データ613を作成し、リクエストした視聴ユーザの発信ログデータ596を作成して更新する(ステップS136)。
また、発信サービス管理部210が、画像発信リクエストの受信を監視する(ステップS138)。そして、画像発信リクエストを受信した場合は(ステップS138のYES)、受信した新たな発信内容について画像発信実績データ615を作成し、リクエストした視聴ユーザの発信ログデータ596を作成して更新する(ステップS140)。また、発信された発信用画像8を1つ消費して保有発信用画像リスト594を更新する(ステップS142)。
また、イベント発生条件判定部215がイベント発生条件を満たすと判定したことを受けて、イベント制御部225が、フィーバータイムを発生させるためのイベント制御を行う。すなわち先ず、ステップS122で開始した連続コンボ判定処理で連続コンボ発生条件を満たしたと判定した場合、又は、ステップS124で開始した組合せコンボ判定処理で組合せコンボ発生条件を満たしたと判定した場合には(ステップS144のYES)、フィーバータイム発生フラグ631を判定する。そして、フィーバータイム発生フラグ631が「OFF」でありフィーバータイムの非発生時であれば(ステップS146:YES)、フィーバータイム発生フラグ631を「ON」に更新するとともに(ステップS148)、ステップS144で満たしたと判定した連続コンボ発生条件又は組合せコンボ発生条件に対応するフィーバー時間長をフィーバータイム定義データ580から読み出して、フィーバータイム終了時刻633を設定する(ステップS150)。その後図21のステップS178に移行する。
次に、現発信操作総数623が操作回数条件設定720に達した場合には(ステップS152:YES)、フィーバータイム発生フラグ631を判定する。そして、フィーバータイム発生フラグ631が「OFF」の場合は(ステップS154:YES)、これを「ON」に更新するとともに(ステップS156)、操作回数条件に対応するフィーバー時間長をフィーバータイム定義データ580から読み出して、フィーバータイム終了時刻633を設定する(ステップS158)。一方、フィーバータイム発生フラグ631が「ON」であれば(ステップS154のNO)、操作回数条件に対応する延長時間長をフィーバータイム定義データ580から読み出し、読み出した延長時間長をフィーバータイム終了時刻633に加えてこれを更新する(ステップS160)。その後、ステップS178に移行する。
次に、図21に示すように、有償発生指示操作を視聴端末にて受け付けた旨の通知を受信した場合は(ステップS162:YES)、強制発生アイテムを1つ消費して保有強制発生アイテム数595を更新する(ステップS164)。そして、フィーバータイム発生フラグ631を「ON」に更新するとともに(ステップS166)、強制発生条件の有償発生指示操作に対応するフィーバー時間長をフィーバータイム定義データ580から読み出して、フィーバータイム終了時刻633を設定する(ステップS168)。その後、ステップS178に移行する。
次に、発生指示操作を提供端末にて受け付けた旨の通知を受信した場合は(ステップS170:YES)、対価徴収処理部223が、当該発生指示操作の対価分の通貨ポイントを提供ユーザから徴収する処理を行う(ステップS172)。その後、イベント制御部225が、フィーバータイム発生フラグ631を「ON」に更新するとともに(ステップS174)、強制発生条件の発生指示操作に対応するフィーバー時間長をフィーバータイム定義データ580から読み出して、フィーバータイム終了時刻633を設定する(ステップS176)。その後、ステップS178に移行する。
そして、ステップS178では、イベント制御部225は、適用倍率730に倍率581を格納する。
また、フィーバータイム中は、イベント制御部225は、フィーバータイム終了時刻633を監視する。そして、フィーバータイム終了時刻633となった場合は(ステップS180のYES)、連続コンボ発生条件を満たしたことによるフィーバータイムであれば(ステップS182のYES)、連鎖数Csを用いて延長時間長を算出し、これをフィーバータイム終了時刻633に加えて更新する(ステップS184)。一方、連続コンボ発生条件を満たしたことによるフィーバータイムでない場合や(ステップS180のYES)、ステップS184で算出した延長時間長が0(つまり連鎖数Csが0)でフィーバータイムを延長しない場合は(ステップS186のYES)、適用倍率730を「等倍」に戻す(ステップS188)。
その後は、配信が終了するまでは(ステップS190のNO)、図20のステップS130に戻って上記した処理を繰り返す。そして、配信が終了すると(ステップS190のYES)、一連の処理を終了する。
2.視聴端末
図22は、視聴端末となるユーザ端末1500(1500a,1500b,…)におけるコンテンツの視聴に係る処理の流れを示すフローチャートである。ここで説明する処理は、端末処理部200が視聴端末プログラム504を読み出して実行することによって実現される。
図22に示すように、視聴端末では先ず、ログイン処理を実行する(ステップS300)。その後、コンテンツの配信を視聴するための所定の視聴操作(視聴するコンテンツの選択を含む)を検出すると(ステップS310のYES)、操作信号送信制御部262が、ストリーミングサーバ1100へ視聴リクエストを送信する(ステップS312:通信A)。ここでの視聴リクエストを受けて、ストリーミングサーバ1100では、当該視聴端末のユーザが視聴ユーザとして視聴者登録され、視聴画面W1,W11を表示するための各種配信データの当該視聴端末への配信が開始される(配信α)。そして、視聴端末では、視聴画面表示制御部264が、これらを受信して受信済配信データ群800に格納し、視聴画面の表示を開始する(ステップS314)。ここで開始される視聴画面の表示によって、フィーバータイムの非発生時の視聴画面W1の表示や、フィーバータイムの発生時の視聴画面W11の表示が実現される。
また、発信用画像8や強制発生アイテム等の販売対象の購入操作を検出すると(ステップS320のYES)、操作信号送信制御部262は、ストリーミングサーバ1100へ購入リクエストを送信する(ステップS322:通信B)。
また、操作信号送信制御部262は、テキスト発信操作を検出すると(ステップS330のYES)、テキストの入力編集処理を実行し(ステップS332)、入力されたテキストとともにテキスト発信リクエストをストリーミングサーバ1100へ送信する(ステップS334:通信C)。また、画像発信操作アイコン34をワンタッチする画像発信操作を検出した場合は(ステップS336のYES)、選択された発信用画像種類選択された発信用画像種類とともに画像発信リクエストをストリーミングサーバ1100へ送信する(ステップS338:通信D)。
ここで、視聴端末は、前述のようにステップS314にて各種配信データに基づく視聴画面W1,W11の表示制御を開始している。したがって、ステップS330,S336にて当該視聴端末や他の視聴端末にて視聴ユーザが発信操作した発信内容が、発信内容表示部36に表示されることとなる。具体的には、新たに発信されたテキストを発信者のアバター4から吹き出し5で表示され、或いは、新たに発信された発信用画像8を発信者のアバター4から出現表示される。なお、表示持続時間を超過した発信内容の表示は逐一消去される。
また、汎用表示部35にて強制発生アイテム355をタッチ操作する有償発生指示操作を検出した場合は(ステップS340のYES)、その旨の通知をストリーミングサーバ1100へ送信する(ステップS342:通信E)。
また、視聴端末は、画像発信操作アイコン34への発信用画像の割り当て変更操作を検出すると(ステップS350のYES)、ポップアップ表示W4の表示制御を含む割り当て変更処理を実行して、発信用画像割り当て設定802を変更する(ステップS352)。
その後は、配信が終了するまでは(ステップS360のNO)、ステップS320に戻って上記した処理を繰り返す。そして、配信が終了すると(ステップS360のYES)、一連の処理を終了する。
3.提供端末
図23は、提供端末となるユーザ端末1500(1500T)におけるコンテンツの提供に係る処理の流れを示すフローチャートである。ここで説明する処理は、端末処理部200が提供端末プログラム506を読み出して実行することによって実現される。なお、コンテンツをゲームプレイ動画のライブ中継コンテンツとする場合には、別途ゲームプログラムが実行されているものとする。
図23に示すように、視聴端末では先ず、ログイン処理を実行する(ステップS500)。その後、提供画面表示制御部276が、提供画面の表示制御を開始する(ステップS502)。
続いて、コンテンツ提供制御部274が、提供するコンテンツの配信タイトルや配信スケジュール、付帯情報を設定してその登録手続き処理を行う(ステップS504)。そして、配信予定時刻になると、当該コンテンツの提供を開始する(ステップS506:通信F)。本実施形態では、ライブ配信を想定しているので、例えば実写によるライブ配信の場合は、コンテンツ提供制御部274は、撮像部102で撮影した映像に集音部104で集音した音声を付加したコンテンツデータを逐次作成するとともに、そのライブストリーミングエンコードを行ってストリーミングサーバ1100へ送信する。ゲームプレイ動画をライブ配信する場合は、ゲーム画面をキャプチャした動画にゲーム音声を付加してコンテンツデータを逐次作成する。コンテンツが予め用意された動画データ等の場合には、配信予定時刻を待たずにそれをストリーミングサーバ1100へアップロードする。
また、提供画面にてフィーバー発生ボタンをタッチ操作する発生指示操作を検出した場合は(ステップS508のYES)、その旨の通知をストリーミングサーバ1100へ送信する(ステップS510:通信G)。
そして、コンテンツの配信を終了すると(ステップS512のYES)、一連の処理を終了する。
以上、第1実施形態によれば、コンテンツの配信サービスにおいて、テキストや画像の発信機能を利用して、従来のサービス以上の楽しい充実したユーザ体験を提供することができ、配信のサービスを向上できる。
〔第2実施形態〕
第1実施形態では、全ての視聴ユーザの画像発信操作を対象に配信コンテンツに係る応援ポイントを集計して、フィーバータイムを発生させることとした。これに対し、視聴ユーザをグループ分けし、グループ毎に応援ポイントを算出して当該グループ毎にフィーバータイムを発生させるとしてもよい。
図24は、第2実施形態におけるフィーバータイムの非発生時の視聴画面例を示す図である。本実施形態では、複数のキャラクタC1(C1-1~C1-3)が登場するコンテンツであって、各キャラクタC1が音楽に乗せてダンスを踊る映像として提供されたコンテンツの配信時を想定しており、視聴ユーザ2は、コンテンツの配信に先立ちキャラクタC1の中から好きなキャラクタ(ファンのキャラクタ)Cを登録しておくことができる。
先ず、本実施形態では、ストリーミングサーバ1100は、配信開始から終了までの間に、各視聴ユーザ2のユーザ端末1500で為された画像発信操作をその操作主体(視聴ユーザ2)毎に集計して、個別の応援ポイント(視聴ユーザ別応援ポイント)を更新・管理する。また、各視聴ユーザ2がどのキャラクタC1のファンなのかに応じて視聴ユーザ2をグループ分けし、各グループに属する視聴ユーザ2の画像発信操作をグループ毎に集計して、グループ別の応援ポイント(グループ別応援ポイント)を更新・管理する。図24では、キャラクタC1-1のファン登録をした各アバター4a,4c,4eの視聴ユーザ2a,2c,2eのグループG1と、キャラクタC1-3のファン登録をした各アバター4b,4f,4gの視聴ユーザ2b,2f,2gのグループG2とを破線で囲って例示している。この場合、例えば、グループG1のグループ別応援ポイントは、3人の視聴ユーザ2a,2c,2eが行った画像発信操作に基づき算出する。
そのため、視聴画面は、汎用表示部35において、その視聴ユーザ2(図24では視聴ユーザ2a)に係る視聴者別応援ポイント表示部3511と、その視聴ユーザ2(2a)が属するグループG1に係るグループ別応援ポイント表示部3513とを備える。また、汎用表示部35は、その視聴ユーザ2の画像発信操作に基づく連続コンボ連鎖数を示すコンボゲージ3531と、その視聴ユーザ2(2a)が属するグループG1の各視聴ユーザ2a,2c,2eによる画像発信操作に基づく連続コンボ連鎖数を示すコンボゲージ3533とが表示される。
そして、ストリーミングサーバ1100は、連続コンボ発生条件、組合せコンボ発生条件、及び操作回数条件をグループ単位で判定し、グループ毎にフィーバータイムを発生させる。また、強制発生条件の視聴ユーザ2の操作に係る条件については、何れかの視聴ユーザ2が有償発信指示操作を行うと、当該視聴ユーザ2が属するグループを対象にフィーバータイムを発生させる。つまり、あるグループにフィーバータイムを発生させた場合には、当該グループに属する視聴ユーザ2が発信した発信用画像8の加算ポイント数に適用倍率(例えば1.5倍)を乗じて視聴ユーザ別応援ポイント及びグループ別応援ポイントに加算する。
またその際、当該フィーバータイムの発生に関与した視聴ユーザ2を調整対象視聴ユーザとして特定する。例えば、連続コンボ発生条件を満たしたことによるフィーバータイムであれば、当該連続コンボに係る画像発信操作を行った調整対象視聴ユーザ2を特定する。一例を挙げると、視聴ユーザ2a,2cの2人が画像発信操作を繰り返したことで連続コンボが発生し、その間視聴ユーザ2eは画像発信操作を1回も行わなかった場合には、視聴ユーザ2a,2cを調整対象視聴ユーザとする。そして、特定した調整対象視聴ユーザ2については、適用倍率をさらに上乗せする。前述の例でいえば、視聴ユーザ2aや視聴ユーザ2cについて、適用倍率(1.5倍)に所定値(例えば0.3)を加算して調整する。そして、フィーバータイム中に視聴ユーザ2aや視聴ユーザ2cが画像発信操作を行った場合には、発信された発信用画像8の加算ポイント数を1.8倍して、彼等の視聴ユーザ別応援ポイント及びグループ別応援ポイントに加算する。一方、フィーバータイム中に視聴ユーザ2eが画像発信操作を行った場合の適用倍率は、1.5倍のままとなる。
次に、本実施形態では、ストリーミングサーバ1100は、コンテンツの配信終了時に、各視聴ユーザ2を視聴ユーザ別応援ポイントの順に並べて視聴ユーザ別のランキング(視聴ユーザ別ランキング)を算出するとともに、各グループをグループ別応援ポイントの順に並べてグループ別のランキング(グループ別ランキング)を算出する。
そして、ストリーミングサーバ1100は、グループ別ランキングに基づき視聴ユーザ2に特典を付与する処理(第2特典付与処理)を実行する。すなわち、第2特典付与処理では先ず、グループ別ランキングのランキング順位から各グループの視聴ユーザ2に特典を付与するか否かを判定する。そして、付与すると判定した視聴ユーザ2に対して特典を付与する。例えば、ランキング順位が1位のグループに属する視聴ユーザ2にのみ特典を付与するといったことができる。なお、ランキング順位の何位まで特典を付与するのかは適宜設定できる。そして、付与する特典は、ランキング順位と対応付けて予め設定しておけばよい。
またその際、付与すると判定した視聴ユーザ2の視聴中の発信実績(画像発信操作の数や、その画像発信操作で応援ポイントに加算された加算ポイントの合計値等)を用いて各視聴ユーザ2に特典を配分する。配分(山分け)は、第1実施形態と同様に行うことができる。
また、ストリーミングサーバ1100は、視聴ユーザ別ランキングに基づき視聴ユーザ2に特典を付与する処理(第3特典付与処理)を実行する。すなわち、第3特典付与処理では先ず、視聴ユーザ別ランキングのランキング順位から各視聴ユーザ2に特典を付与するか否かを判定する。そして、付与すると判定した視聴ユーザ2に対して特典を付与する。ランキング順位の何位まで特典を付与するのかは、第2特典付与処理と同様に適宜設定でき、付与する特典についても、ランキング順位と対応付けて予め設定しておけばよい。
[機能構成]
図25は、第2実施形態におけるストリーミングサーバ1100の機能構成例を示すブロック図であり、図26は、第2実施形態においてサーバ記憶部500sが記憶するプログラムやデータの例を示す図である。各図25,26では、第1実施形態と同様の構成には同一の符号を付している。図25に示すように、本実施形態では、サーバ処理部200sの発信サービス管理部210Aが、グループ設定部211Aと、発信内容表示制御部212と、応援ポイント算出部213Aと、イベント発生条件判定部215Aと、連鎖報知制御部221と、対価徴収処理部223と、イベント制御部225Aと、ランキング算出部227Aと、第2特典付与処理部233Aと、第3特典付与処理部235Aを含む。
グループ設定部211Aは、コンテンツの配信開始時において、視聴者登録された視聴ユーザをグループ分けする処理を行う。例えば、図24に示して例示したように、配信中の特定のキャラクタを視聴ユーザが登録することでグループ分けを行う構成の他、視聴ユーザが自身の属するグループを選ぶ構成でもよい。そして、グループ設定部211Aは、グループ分けした各グループにグループIDを割り振り、各グループIDと該当するグループに属する視聴ユーザのユーザアカウントとを対応付けてグループ設定データ750Aを生成する。
応援ポイント算出部213Aは、視聴ユーザ毎に画像発信操作を集計して視聴ユーザ別応援ポイントを算出するとともに、グループ毎に画像発信操作を集計してグループ別応援ポイントを算出する。
イベント発生条件判定部215Aは、上記実施形態のように全ての視聴ユーザを対象とするのではなく、グループ単位でイベント発生条件を判定する。
イベント制御部225Aは、イベント発生条件判定部215Aがイベント発生条件を満たしたと判定した場合に、そのグループについてフィーバータイムを発生させる。このイベント制御部225Aは、このイベント制御部225は、フィーバータイム延長処理部226と、適用倍率調整部231Aとを備える。
適用倍率調整部231Aは、フィーバータイムの発生に関与した調整対象視聴ユーザを特定し、フィーバータイム中の当該調整対象ユーザの画像発信操作に適用する適用倍率730を調整する。
ランキング算出部227Aは、コンテンツの配信終了時において、視聴ユーザ別応援ポイントに基づき視聴ユーザ別ランキングを算出するとともに、グループ別応援ポイントに基づきグループ別ランキングを算出する。
第2特典付与処理部233Aは、グループ別ランキングに基づき視聴ユーザに特典を付与する第2特典付与処理を実行する。
第3特典付与処理部235Aは、視聴ユーザ別ランキングに基づき視聴ユーザに特典を付与する第3特典付与処理を実行する。
また、図26に示すように、サーバ記憶部500sには、サーバプログラム503Aと、配信用視聴端末プログラム505と、配信用提供端末プログラム507と、販売品管理データ509と、発信サービス初期設定データ510と、ユーザ管理データ590と、配信管理データ600Aと、連続コンボ条件設定700と、組合せコンボ条件設定710と、操作回数条件設定720と、グループ設定データ750Aと、適用倍率730Aと、ランキングデータ740Aと、現在日時900とが格納される。また、その他にも、例えば、視聴画面の背景画像の画像データや、アバターを作成・編集するための素材データ等、必要なデータが適宜格納される。
配信管理データ600Aは、図16に示した上記した実施形態の配信管理データ600と概ね同様のデータ構成で実現できるが、現応援ポイント617には視聴ユーザ別応援ポイント及びグループ別応援ポイントの現在値が設定され、現発信操作総数623にはグループ毎の発信操作総数の現在値が設定される。また、フィーバータイム発生状況データ630は、グループ毎に用意される。
グループ設定データ750Aは、グループ設定部211Aによって設定された各視聴者ユーザのグループ分けの情報を格納する。
適用倍率730Aは、視聴者ユーザ毎の適用倍率を格納する。この適用倍率730Aには、フィーバータイムの非発生時は全ての視聴ユーザの適用倍率が「等倍」に設定される。一方、フィーバータイムの発生時は、該当するグループに属する視聴ユーザの適用倍率が「1.5倍」とされ、そのうちの調整対象視聴ユーザの適用倍率にはさらに所定値(例えば0.3)が加算されて「1.8倍」とされる。
ランキングデータ740Aは、ランキング算出部227Aによりコンテンツの配信終了時に算出される視聴ユーザ別ランキングのランキング結果及びグループ別ランキングのランキング結果を格納する。
[処理の流れ]
第2実施形態のストリーミングサーバ1100におけるコンテンツのライブ配信に係る処理は、図19~図21に示した上記実施形態の処理手順と概ね同様の手順で行うことができる。ただし、本実施形態では、コンテンツの配信開始時に、視聴者登録された視聴ユーザをグループ分けする。また、配信開始後の応援ポイント算出処理では、視聴ユーザ別応援ポイント及びグループ別応援ポイントを算出する。そして、イベント発生条件の判定やイベント制御等の各処理をグループ毎に行い、グループ単位でフィーバータイムを発生させる。また、コンテンツの配信終了時に視聴ユーザ別ランキング及びグループ別ランキングを算出し、第2特典付与処理と第3特典付与処理とを順次実行して付与対象の視聴ユーザ2に付与対象の特典を付与(山分け配分)する。
以上、第2実施形態によれば、第1実施形態と同様の効果を奏することができる。また、配信コンテンツの特定の登場人物(例えばキャラクタ)を個々に応援したり、同じキャラクタを応援する視聴ユーザ同士がグループになって当該キャラクタを応援し合うといったことが可能となり、視聴ユーザが皆でコンテンツを盛り上げている感覚をより高め、ユーザ体験をより向上させることが可能となる。
なお、本発明を適用可能な形態は上記した実施形態に限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。
〔変形例1〕
例えば、上記した各実施形態では、クライアント・サーバ型のコンピュータシステムにて配信サービスを実現する例を挙げたが、複数のユーザ端末1500同士をピアツーピア接続したコンピュータシステムにおいて実現するとしてもよい。その場合、何れかのユーザ端末1500にストリーミングサーバ1100としての機能を担わせる。或いは、複数のユーザ端末1500で配信サービス管理部206が有する機能を分担して担う構成としてもよい。
〔変形例2〕
また、上記した各実施形態は、複数のユーザが同時にアクセスしていて、それぞれがテキストや画像の発信操作可能なサービスであればその他のサービスにも適用可能である。
例えば、視聴画面の汎用表示部35より下の画面部分を、ソーシャルネットワーキングサービスのチャット機能を適用したチャット画面とすることもできる。図27及び図28は、その場合の表示例を示す図である。
下側のチャット画面38の左側には、当該画面が表示されるユーザ端末1500を使用する視聴ユーザ2aのアバター4aが表示され、当該視聴ユーザ2aが発信操作したテキストが吹き出し5aで表示されるとともに、当該視聴ユーザ2が発信操作した発信用画像8がアバター4から出現表示される。一方、チャット画面38の右側には、他の視聴ユーザ2b等のアバター4b等が表示され、彼等が発信操作したテキストが吹き出し5で表示されるとともに、画像発信操作した発信用画像8がアバター4から出現表示される。そして、本変形例では、フィーバータイム中にチャット画面38の背景が特別な背景データに適宜変更され、各視聴ユーザ2が発信操作した発信用画像8の出現表示が演出される。
或いは、図28に示すように、視聴画面の付帯情報表示部31、コンテンツ表示部32、及び汎用表示部35の部分で構成されたコンテンツ画面39がチャット画面38の中央に表示される画面構成でもよい。コンテンツ画面39を挟んで両側には、図27の場合と同様に、当該画面が表示されるユーザ端末1500を使用する視聴ユーザ2aのアバター4aや、他の視聴ユーザ2b等のアバター4b等が表示され、吹き出し5でテキストの表示や発信用画像8の出現表示がなされる。そして、コンテンツ画面39の表示位置は固定とし、常にチャット画面38の中央に表示しておく一方、破線で囲って示す両サイドのアバター4や吹き出し5、発信用画像8の出現表示は、新たな発信操作が行われるとスクロール表示する。