JP6937655B2 - コンテンツ配信システム及びコンピュータシステム - Google Patents

Description

本発明は、提供ユーザにより提供された少なくとも映像を含むコンテンツを、各視聴ユーザのユーザ端末に配信するコンテンツ配信システム等に関する。

チャット機能やテキスト機能と称する機能により、ユーザがテキストや画像を発信することができるソーシャルネットワーキングサービス（ＳＮＳ）や（例えば、特許文献１を参照）、コンテンツの配信サービスなどが知られている。

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

チャット機能やテキスト機能を利用することで、ユーザ同士のコミュニケーションが促進される。例えば、動画の配信サービスであれば、動画を見ながら各々のテキストを発信・投稿することで、皆で一緒に動画を鑑賞しているかのような仮想体験を楽しむことができる。

チャット機能やテキスト機能として、テキストのみならず画像が発信可能な場合には、その画像の発信は「画像投稿」などと呼ばれることもある。例えば、台詞を吹き出し状に示したキャラクタの画像や、喜怒哀楽等のアクションをしているキャラクタの画像を発信（この場合、投稿とも呼ばれる）することで、言葉では言い表せない感情や想いを端的に発信することができる。

こうしたテキストや画像の発信に係る機能がもたらす様々なユーザ体験は、近年のソーシャルネットワーキングサービス（ＳＮＳ）や、コンテンツの配信サービスにおいては、もはや無くてはならない定番となっているとさえ言える。

本発明は、テキストや画像の発信機能を利用した新たな付加価値を創出し、ユーザ体験をより豊かにするための技術を提供することを目的とする。

上述した課題を解決するための第１の発明は、提供ユーザにより提供された少なくとも映像を含むコンテンツを、各視聴ユーザのユーザ端末に配信するコンテンツ配信システムであって、
前記ユーザ端末では、前記コンテンツを表示するコンテンツ表示部と、視聴中の前記コンテンツに対する各視聴ユーザの発信内容を表示する発信内容表示部とを含む視聴画面が表示され、
前記発信内容の表示形態を前記ユーザ端末別に制御する手段であって、当該ユーザ端末の視聴ユーザが発信した発信内容（以下「自身発信内容」という）を明示形態、当該ユーザ端末の視聴ユーザ以外が発信した発信内容（以下「他者発信内容」という）を非明示形態として前記視聴画面中に表示させる制御を行う第１の表示制御手段（例えば、図１の制御基板１１５０、図１１のサーバ処理部２００ｓ、配信サービス管理部２１０、第１表示制御部２２４、図２４のステップＳ１０２、図２５のステップＳ１３４）と、
複数の視聴ユーザによる複数の発信内容が、少なくとも所与の関連性認定条件を含む秘密条件を満たすか否かを判定する判定手段（例えば、図１の制御基板１１５０、図１１のサーバ処理部２００ｓ、配信サービス管理部２１０、イベントクリア判定部２２５、図２１の配信管理データ６２０、秘密条件設定データ６３０、図２６のステップＳ１９０）と、
前記判定手段により肯定判定された発信内容であって、前記第１の表示制御手段により非明示形態とされた発信内容を、明示形態に変更して表示させる制御を行う第２の表示制御手段（例えば、図１の制御基板１１５０、図１１のサーバ処理部２００ｓ、配信サービス管理部２１０、第２表示制御部２２６、図２８のステップＳ２０４）と、
前記判定手段により肯定判定された場合に特典制御を実行する特典制御手段（例えば、図１の制御基板１１５０、図１１のサーバ処理部２００ｓ、配信サービス管理部２１０、特典制御実行部２３０、図１６の特典定義データ５６０、図２８のステップＳ２０６）と、
を備えたコンテンツ配信システムである。

第１の発明によれば、配信されたコンテンツを視聴している視聴ユーザ同士のユーザ端末には、自身の発信内容は視聴画面中で見えるが（明示形態）、他者の発信内容は視聴画面中では分からない非明示形態で表示される。そして、視聴ユーザ同士の発信内容が秘密の関連性を満たすと、非明示形態であった他者の発信内容が明示形態とされて、特典を獲得することができる。よって、テキストや画像の発信機能を利用した新たな付加価値を創出し、ユーザ体験をより豊かにすることができる。

第２の発明は、前記秘密条件が、発信時間間隔に関する時間差条件を更に含む、第１の発明のコンテンツ配信システムである。

第２の発明によれば、秘密条件に、発信時間の間隔に関する条件を含めることで、判定対象とする発信内容の選択に適当な制限を設けることができる。例えば、時間差条件を連続的な発信と認定する条件とすれば、連鎖的になされた発信を判定対象にすることができる。

第３の発明は、前記判定手段が、前記秘密条件を満たすか否かの判定対象とする発信内容を発信順に選択し、且つ、同一の視聴ユーザによる発信を連続して選択しないように選択する、第１又は第２の発明のコンテンツ配信システムである。

第３の発明によれば、同一の視聴ユーザが連続して行った発信を判定対象とすることを回避し、あくまで複数の視聴ユーザが互いに発信し合っているような状況を判定対象とすることができる。

第４の発明は、前記特典制御が、前記視聴ユーザ及び／又は前記提供ユーザに所与の特典を付与する制御である、第１〜第３の何れかの発明のコンテンツ配信システムである。

第４の発明によれば、特典を視聴ユーザ及び／又は提供ユーザに付与できるようになる。

第５の発明は、前記第１の表示制御手段、前記判定手段、前記第２の表示制御手段および前記特典制御手段を、所与の開始条件を満たした場合に機能開始させ、所与の終了条件を満たした場合に機能終了させる秘密イベント制御手段（例えば、図１１のイベント開始終了制御部２２１、図１７のイベント開始条件５７２、イベント終了条件５７３、図２５のステップＳ１３２〜Ｓ１３８）、を備えた第１〜第４の何れかの発明のコンテンツ配信システムである。

第５の発明によれば、第１の表示制御手段、判定手段、第２の表示制御手段および特典制御手段によって実現される機能を、ある条件が整うと自動的に開始されそして終了する特殊なイベントのような機能として利用できるようになる。

例えば、第６の発明として、前記秘密イベント制御手段が、前記第１の表示制御手段、前記判定手段、前記第２の表示制御手段および前記特典制御手段を、所与の期間の間、機能させるように制御する、第５の発明のコンテンツ配信システムを構成すると、期間限定のイベント的な利用が可能となる。

また、第７の発明として、前記秘密イベント制御手段が、前記終了条件として設定された発信内容の発信があった場合に、前記終了条件を満たすとして機能終了させる、第５又は第６の発明のコンテンツ配信システムを構成することができる。

第７の発明によれば、例えばＮＧ（Ｎｏ Ｇｏｏｄ）とされる発信内容を発信してしまうと、第１の表示制御手段、判定手段、第２の表示制御手段および特典制御手段によって実現される機能を終了させるようにできる。あたかも、地雷を設置するかのような趣向を加えることができる。

第８の発明は、前記秘密イベント制御手段が、前記コンテンツの内容及び／又は前記コンテンツの視聴状況に応じて前記秘密条件を設定する、第５〜第７の何れかの発明のコンテンツ配信システムである。

コンテンツの内容は、ジャンルに相当する情報、映されている状況についての情報、被写体についての情報、などであって、提供ユーザが設定するとしても良いし、配信の運営者が設定するとしてもよい。コンテンツの視聴状況は、例えば、視聴ユーザの数及びその変化、視聴ユーザによる発信の数や頻度、のべ視聴時間、などで記述され得る。

第８の発明によれば、コンテンツの内容や視聴状況に応じて秘密条件を変えることができる。秘密条件を満たそうと複数の視聴ユーザが協力して発信する行為は、皆で同じコンテンツを視聴する雰囲気を盛り上げるように作用すると言える。視聴ユーザの数の多寡によって秘密条件が満たされる可能性が変わるので、視聴ユーザが比較的少ない場合と、比較的多い場合とで秘密条件を適切に変更することで、その時々の視聴状況に応じた、秘密条件を満たされる可能性、言い換えれば難易度を適切に設定することが可能になる。

第９の発明は、前記コンテンツが、ゲームプレイ動画であり、前記秘密イベント制御手段は、前記ゲームプレイ動画に係るゲーム状況に応じて前記秘密条件を設定する、第５〜第８の何れかの発明のコンテンツ配信システムムである。

第９の発明によれば、ゲームプレイ動画に係るゲーム状況（例えば、ステージボスをクリアする、罠にはまる、パーティー全滅、レアアイテム獲得、など）に応じて秘密条件を設定することが可能となる。

第１０の発明は、前記秘密イベント制御手段が、前記秘密条件のヒントを前記ユーザ端末に表示させるヒント表示制御手段（例えば、図８のヒント表示７２、追加ヒント表示７４、図１１のヒント表示制御部２２７、図１４のヒントデータセット５４６、図２５のステップＳ１３４、図２６のステップＳ２２０〜ステップＳ２２４）を有する、第５〜第９の何れかの発明のコンテンツ配信システムである。

第１０の発明によれば、秘密条件のヒントを提供することができるようになる。

第１１の発明は、前記ヒント表示制御手段が、前記提供ユーザ又は前記視聴ユーザによる所定の対価支払と引き換えに前記ヒントを表示させる、第１０の発明のコンテンツ配信システムである。

第１１の発明は、対価の支払いと引き換えにヒントを表示できるようになる。

第１２の発明は、前記ヒント表示制御手段が、前記対価支払との引き換えによる前記ヒントを、前記コンテンツを視聴中の視聴ユーザ全員のユーザ端末に表示させる、第１１の発明のコンテンツ配信システムである。

第１２の発明によれば、視聴ユーザの誰かが対価支払いをすれば視聴ユーザ全員がヒントを得られるようになる。「じゃあ、俺が支払うよ」といった発言が視聴ユーザ間で行われれば、視聴ユーザ間で他者（この場合は、支払者）を強く認識するようになり、ひいては、同じコンテンツを視聴する者同士が協力して雰囲気を盛り上げている一体感を醸成することとなる。よって、ユーザ体験をより豊かにすることができる。

第１３の発明は、前記秘密イベント制御手段が、前記提供ユーザ又は前記視聴ユーザによる所定の対価支払がなされたことを前記開始条件とする、第５〜第１２の何れかの発明のコンテンツ配信システムである。

第１３の発明によれば、秘密イベントを対価の支払いをもって実行する、つまりは有料イベントとすることができる。

第１４の発明は、当該コンテンツを視聴中の前記視聴ユーザによる発信状況を少なくとも用いて、当該コンテンツに係る活況指標値を算出する手段（例えば、図１１の活況指標値算出部２３２、図２６のステップＳ２３２、図２８のステップＳ２１２）、前記活況指標値に基づいて各コンテンツをランキングするランキング手段（例えば、図１１のランキング管理部２３４、図１２のランキングデータ５９９、図１９の累積活況指標値５９３、図２６のステップＳ２３４）、を備えた第１〜第１３の何れかの発明のコンテンツ配信システムである。

第１４の発明によれば、コンテンツ視聴中の視聴ユーザによる発信に基づいて、当該コンテンツ視聴の活況状況、換言すれば盛り上がり具合を数値化し、コンテンツをランキングすることができるようになる。コンテンツのランキングは、同じコンテンツを視聴する視聴ユーザの一体感を高め、ユーザ体験をより豊かにするように作用する。

第１５の発明は、各視聴ユーザのユーザ端末と、第１〜第１４の何れか一項に記載のコンテンツ配信システムとを具備した、コンピュータシステムである。

第１５の発明によれば、第１〜第１４の何れかの発明と同様の効果を奏するコンピュータシステムを実現できる。

コンテンツ提供システムの構成例を示す図。 ユーザ端末の構成例を示す正面図。 マルチメディアコンテンツを視聴するための視聴画面の構成を説明するための図。 割り当て変更操作時に表示されるポップアップの表示例を示す図。 ストリーミング配信サービスが備える新たな付加価値について説明するための図。 関連性有りと判定される例を説明するための図。 発信コンボの発生及び特典制御が実行されていることをユーザに報知する例を示す視聴画面図。 秘密イベントについて説明するための視聴画面例を示す図。 イベントクリア時の視聴画面の表示例を示す図。 途切れ許容時間差条件ΔＵと、それに基づく緩和条件について説明するための図。 ストリーミングサーバの機能構成例を示す機能ブロック図。 サーバ記憶部が記憶するプログラムやデータの例を示す図。 発信用画像定義データのデータ構成例を示す図。 関連性認定条件定義データのデータ構成例を示す図。 規模要件定義データのデータ構成例を示す図。 特典定義データのデータ構成例を示す図。 秘密イベント定義データのデータ構成例を示す図。 コンボ発生報知定義データのデータ構成例を示す図。 提供ユーザ登録データのデータ構成例を示す図。 ユーザ管理データのデータ構成例を示す図。 配信管理データのデータ構成例を示す図。 視聴端末となるユーザ端末の機能構成例を示す機能ブロック図。 提供端末となるユーザ端末の機能構成例を示す機能ブロック図。 ストリーミングサーバにおける１つのストリーミング形式によるライブ配信に係る処理の流れについて説明するためのフローチャート。 図２４より続くフローチャート。 図２５より続くフローチャート。 発信コンボ発生判定処理の流れを説明するためのフローチャート。 秘密イベントクリア判定処理の流れを説明するためのフローチャート。 視聴端末となるユーザ端末におけるマルチメディアコンテンツの視聴に係る処理の流れを説明するためのフローチャート。 図２９より続くフローチャート。 図３０より続くフローチャート。 提供端末となるユーザ端末における処理の流れを説明するためのフローチャート。 ソーシャルネットワーキングサービスのチャット機能に適用した場合のチャット画面の表示例を示す図。

以下、本発明の実施形態の例を説明するが、本発明を適用可能な形態が以下の実施形態に限られないことは勿論である。

図１は、本発明が適用されたコンテンツ提供システムの構成例を示す図である。コンテンツ提供システム１０００は、マルチメディアコンテンツに代表されるコンテンツを不特定多数で同時に楽しむストリーミング配信サービスを提供するコンピュータシステムであって、通信回線９を介して相互にデータ通信が可能に接続されたストリーミングサーバ１１００と、複数のユーザ端末１５００（１５００ａ，１５００ｂ，…）とを含む。

通信回線９は、データ通信が可能な通信路を意味する。すなわち、通信回線９とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

ストリーミングサーバ１１００は、提供ユーザ２ｔのユーザ端末１５００Ｔから提供された少なくとも映像を含むマルチメディアコンテンツを、各視聴ユーザ２（２ａ，２ｂ，…）のユーザ端末１５００（１５００ａ，１５００ｂ，…）へ向けてストリーミング配信するコンテンツ配信システムを実現するコンピュータシステムである。

具体的には、ストリーミングサーバ１１００は、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを有し、本体装置１１０１には制御基板１１５０を搭載する。

制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。なお、制御基板１１５０の一部または全部は、ＡＳＩＣ（Application Specific Integrated Circuit）や、ＦＰＧＡ（Field-Programmable Gate Array）、ＳｏＣ（System on a Chip）により実現するとしてもよい。

そして、ストリーミングサーバ１１００は、制御基板１１５０が所定のプログラム及びデータに基づいて演算処理することにより、
１）ユーザ登録等に係るユーザ管理機能と、
２）マルチメディアコンテンツのストリーミング配信機能と、
３）ユーザ端末１５００から発信（投稿とも言える）されたテキストや画像を配信するユーザ発信サービス機能と、
４）ユーザ発信サービス機能で発信（投稿）することのできる発信用画像をオンラインで購入可能にするオンラインショッピング機能と、
を実現する。勿論、これら以外の機能を実現できる構成も可能である。例えば、ソーシャルネットワーキングサービス機能、その一部としてのチャット機能なども実現できるようにしてもよい。

ストリーミング配信機能は、マルチメディアコンテンツを提供するユーザである提供ユーザ２ｔのユーザ端末１５００Ｔから動画データ等のマルチメディアコンテンツを取得し、取得したマルチメディアコンテンツを視聴者登録したユーザである視聴ユーザ２（２ａ，２ｂ，…）のユーザ端末１５００（１５００ａ，１５００ｂ，…）へ、コンテンツファイルのダウンロードと並行しながらの視聴を可能な形式で配信する機能である。

ユーザ発信サービス機能は、視聴ユーザ２（２ａ、２ｂ…）のユーザ端末１５００（１５００ａ、１５００ｂ…）から発信操作されたテキストや画像を、視聴ユーザ２（２ａ、２ｂ…）のユーザ端末１５００（１５００ａ、１５００ｂ…）及び提供ユーザ２ｔのユーザ端末１５００Ｔへ配信し、配信先で発信された内容が反映された反映表示を表示させる機能である。

なお、ストリーミングサーバ１１００は単体として記しているが、各機能を分担する複数のブレードサーバを搭載して相互に内部バスを介してデータ通信可能に接続した構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを、通信回線９を介してデータ通信させることで、全体としてストリーミングサーバ１１００として機能させる構成であっても良い。

ユーザ端末１５００（１５００ａ，１５００ｂ，…，１５００Ｔ）は、ユーザ２（２ａ，２ｂ，…，２ｔ）が使用するコンピュータシステムであって、実行するプログラムを変えることで、ストリーミング配信用に提供するマルチメディアを作成する提供端末、又はストリーミング配信されるマルチメディアコンテンツの視聴を可能にする視聴端末、として機能するようになる。図１の例では、ユーザ端末１５００Ｔが提供端末に該当し、ユーザ端末１５００ａ、１５００ｂが視聴端末に該当する。なお、本実施形態のユーザ端末１５００は、いわゆるスマートフォンと呼ばれる装置であるが、携帯型ゲーム装置や、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータ、などでもよい。

図２は、本実施形態におけるユーザ端末１５００の構成例を示す正面図である。
ユーザ端末１５００は、方向入力キー１５０２と、ボタンスイッチ１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、内蔵バッテリー１５０９と、マイク１５１２と、イメージセンサモジュール１５２０と、制御基板１５５０と、コンピュータ読み出し可能な記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない電源ボタン、音量調節ボタン等が設けられている。また、ゲームプレイの対価の支払いが可能なＩＣカード型のクレジットカードやプリペイドカードに対して非接触にデータの読み書きが行えるＩＣカード読取装置などを設けるとしてもよい。

制御基板１５５０は、ＣＰＵ１５５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサ、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２、通信回線９に接続する携帯電話基地局や無線ＬＡＮ基地局などと無線通信するための無線通信モジュール１５５３、インターフェース回路１５５７などを搭載する。

インターフェース回路１５５７には、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びボタンスイッチ１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、イメージセンサモジュール１５２０で撮影された画像の画像データを入力する回路、メモリカード読取装置１５４２への信号入出力回路、などが含まれている。

制御基板１５５０に搭載されているこれらの要素は、バス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。なお、制御基板１５５０の一部または全部をＡＳＩＣやＦＰＧＡ、ＳｏＣにて構成してもよい。
そして、制御基板１５５０は、提供端末としての機能を実現させるための動画提供プログラムや、視聴端末としての機能を実現させるための視聴プログラム、各種データをＩＣメモリ１５５２に記憶する。

なお、本実施形態では、ユーザ端末１５００は、プログラム（例えば、マルチメディアコンテンツの作成と提供を可能にする提供端末プログラム、ストリーミング配信されたマルチメディアコンテンツの視聴及びテキストや画像の発信を可能にする視聴端末プログラム）や、各種設定データをストリーミングサーバ１１００からダウンロードする構成としているが、別途入手したメモリカード１５４０などの記憶媒体から読み出す構成としても良い。

図３は、本実施形態におけるマルチメディアコンテンツを視聴するための視聴画面の構成を説明するための図である。
視聴プログラムを実行しているユーザ端末１５００では、タッチパネル１５０６に、視聴画面Ｗ３が表示される。視聴画面Ｗ３は、
１）番組タイトルなどの配信されたマルチメディアコンテンツに関して提供ユーザが申告・設定した付帯情報を表示する付帯情報表示部３１と、
２）配信されているマルチメディアコンテンツを表示するコンテンツ表示部３２と、
３）汎用表示部３３と、
４）テキストの入力と発信操作を行うテキスト発信操作部３４と、
５）視聴ユーザのアバター４（４ａ，４ｂ，…）や、発信されたテキスト及び画像の内容が反映された反映表示をする発信内容表示部３５と、
６）発信用画像８の発信操作（画像発信操作）をするための画像発信操作アイコン３６と、
７）発信用画像８をオンラインで即時に購入するためのショッピングアイコン３７と、
８）追加ヒント要求操作アイコン３８と、
９）累積活況指標値表示部３９と、
を含む。

コンテンツ表示部３２では、少なくとも動画を含むマルチメディアコンテンツ（例えば、提供ユーザ自身による演奏や演芸などのライブ中継、提供ユーザがプレイするゲームプレイのライブ中継や録画されたゲームプレイ動画を編集したもの、提供ユーザが撮影や編集を行ったビデオ作品、など）の映像を表示する。

付帯情報表示部３１で表示される付帯情報とは、例えば、タイトルや、ジャンル、撮影日時、撮影場所、被写体に関する情報、状況説明文、提供ユーザからのメッセージ、などが含まれ得る。マルチメディアコンテンツがゲームプレイ動画であれば、プレイ内容やゲーム状況（例えば、プレイしているステージや場所の情報、装備品の情報、敵キャラクタの名称、攻略の状況、ステージクリアまでの残時間や経過時間、入手できるレアアイテム名、など）が含まれ得る。本実施形態では、付帯情報は、マルチメディアコンテンツの提供前に提供ユーザ自らが設定する事とするが、ストリーミング配信サービスの運営者側が設定するとしてもよいし、ゲームプレイ動画であればプレイしているゲームのプレイ情報から自動取得して設定するとしてもよい。

汎用表示部３３には、各種報知や、演出表示、アバター４の表示などに目的を固定せずに使用される領域である。発信内容表示部３５の拡張領域としても使用される。

テキスト発信操作部３４は、コメントやメッセージのテキスト（文字・数字・記号）の入力欄と、発信実行操作アイコンなどを含む。

発信内容表示部３５には、マルチメディアコンテンツを視聴中の視聴ユーザ２のアバター４が表示される。そして、視聴ユーザ２から発信されたテキストは、当該ユーザのアバター４が発言していることを示す吹き出し５（５ｂ，５ｃ，…）の中に表示される。また、視聴ユーザ２から発信された発信用画像８は、当該ユーザのアバター４から飛び出すように、或いはアバター４が取り出したかのようなアクション動作で出現表示がなされる。つまり、テキストや発信用画像８の反映表示が行われる。

画像発信操作アイコン３６は、発信する画像を事前に割り当てておくことが可能なワンタッチ操作アイコンである。当該アイコンにワンタッチするだけで、割り当て設定されている発信用画像８が発信（投稿）されることになる。

詳細は後述するが、ここで言う発信用画像８は、本実施形態のストリーミング配信の運営者が用意し、視聴ユーザ２に無料或いは有料で付与する画像である。視聴ユーザ２は発信用画像８を入手・購入してそれらを保有し、発信（投稿）に使用することができる。発信された発信用画像８は視聴ユーザ２の保有数から消費される。

画像発信操作アイコン３６には、視聴ユーザが現在所有している発信用画像８の何れかの種類を割り当てることができる。
具体的には、所定の割り当て変更操作（例えば、当該アイコンへの２本指タッチ操作）を行うと、視聴画面Ｗ３には、図４に示すようなポップアップ表示Ｗ４が表示される。ポップアップ表示Ｗ４には、視聴ユーザ２が所有する発信用画像８（８ａ，８ｂ，…）が種類毎にその所有数とともに表示される。視聴ユーザ２はそれらのうちの何れかをタッチ操作して、画像発信操作アイコン３６への割り当てを設定することができる。現在割り当てられている発信用画像８の表示には、選択状態を示すチェックマーク４０が添付表示される。

視聴画面Ｗ３上は同じ位置にある同じ操作アイコンであるが、割り当てる発信用画像８が変わることで、異なる発信操作をすることができるようになっている。

発信用画像８の種類は、適宜設定可能である。静止画に限らず、アニメーションＧＩＦのように変化を伴う画像でも良い。そして、発信用画像８は、基本的には視聴ユーザ２間のコミュニケーションのアイテムとなるように様々にデザインされている。その中には、視聴しているマルチメディアコンテンツを評価するメッセージ（例えば、いいね、だめだね、面白い、面白くない、凄い、格好いい、…）、提供ユーザへの応援やねぎらいのメッセージ（例えば、頑張れ、落ち着いて、…）、発信者の既定の意思表示（例えば、いいね、面白い、等の評価のメッセージや、応援しています、頑張れ、…）などを示すデザインの発信用画像８が含まれている。

そうしたメッセージや意志表示を含むデザインの発信用画像８が割り当てられている状態で画像発信操作アイコン３６を操作すると、当該操作は、メッセージ発信操作や、既定の意思表示を示す既定発信操作を行うことになる。

例えば、画像発信操作アイコン３６に割り当てる発信用画像８として、発信用画像８ａ、８ｂ、８ｃのような、花や星などの自然物をモチーフとしたグラフィック図形とすることができる。花や星は、喜び・楽しい・対象を良く思っている、などの好意的な意志表示のタイミングに発信すると好適である。その他、テキストでは表示されないような大サイズのテキストをモチーフとしたグラフィック図形としてもよい。同じ形状だが、大きさや配色などを異ならせた複数種類の発信用画像８でシリーズ（例えば、春の花シリーズ、夏の花シリーズ、など）を用意することもできる。

また、画像発信操作アイコン３６に割り当てる発信用画像８として、発信用画像８ｄ、８ｅのように、キャラクタになにがしかのアイテム（図４の例では、スティック先端に星が付いていて、手に持って振るようにして使う応援グッズ）を持たせた内容や、キャラクタが何かのアクション（例えば、投げキッスする、笑いかける、がっかりする、など）をしている画像、等とすることができる。同じアイテムを持っていてもキャラクタが異なれば違う種類とすることができる。また、同じアクションをしていてもキャラクタが異なれば違う種類とすることができる。

また、画像発信操作アイコン３６に割り当てる発信用画像８として、発信用画像８ｆのように、画像内に単語や文言を含む画像も可能である。キャラクタに吹き出しを付けて表し、あたかもキャラクタがその単語や文言を話しているかのようにデザインしてもよい。勿論、その単語や文言は、マンガの効果音表現のようなオノマトペでも良い。例えば、驚いた様子のキャラクタに「ギク！」の文字、興奮した様子のキャラクタに「ワクワク！」の文字、を添えた画像とすることができる。

また更に、本実施形態の発信用画像８（８ａ，８ｂ，…）は、ストリーミング配信サービスの運営者により予め用意されているものとしているが、ユーザ自らが作成した画像の使用が可能な構成でもよい。勿論、グラフィックデザイン、イラスト、フォントに限らず、実写の画像を用いたものでもよい。

図３に示すように、本実施形態の動画配信サービスの視聴画面Ｗ３は、大きなコンテンツ表示部３２前にして、それよりもずっと小さな視聴ユーザ２のアバター４（４ａ，４ｂ，…）を配置表示するようにレイアウトされており、あたかも集まってマルチメディアコンテンツを鑑賞しているような雰囲気をユーザに提供する。

加えて、各視聴ユーザ２が発信したテキストをアバター４の吹き出し５で表示したり、発信用画像８をアバター４から出現表示させるように反映表示することで、まるで、皆でマルチメディアコンテンツを鑑賞しつつ、思い思いに感想を述べたり、仲間に話しかけているような雰囲気、を醸成している。発信用画像８は、テキストのように一々読まなくて良いので、視聴ユーザ２が感じているところ、思っているところのものを瞬時かつ象徴的にしかも端的に伝えることができる。また、場の盛り上げ効果もテキストよりも大きい。

このように、本実施形態の視聴画面Ｗ３は、配信用のマルチメディアコンテンツを提供する提供ユーザとそれを視聴する視聴ユーザ２とが、あたかも１つのライブステージや舞台を協働して盛り上げている感覚を得やすいように工夫されている。

そして、本実施形態では、テキストや発信用画像８のユーザ発信機能を利用して、視聴ユーザ２間の一体感や連帯感を高める新たな付加価値をもたらすように工夫されている。

図５は、本実施形態のストリーミング配信サービスが備える新たな付加価値について説明するための図である。
本実施形態では、視聴ユーザ２（２ａ，２ｂ，…）のユーザ端末１５００（１５００ａ，１５００ｂ，…）で、テキストや画像の発信操作を行うと、何時何を発信したのかについての情報すなわち発信実績の情報が、ストリーミングサーバ１１００に蓄積される。そして、ストリーミングサーバ１１００を介して同時にマルチメディアコンテンツを視聴している全ての視聴ユーザ２のユーザ端末１５００に送信され、それぞれの視聴画面Ｗ３にて反映表示される。

ストリーミングサーバ１１００は、発信タイミングの前後で発信者が異なる発信が所定規模以上に連鎖した「発信コンボ（ユーザ発信のコンビネーションの略）」の発生に応じて、マルチメディアコンテンツを視聴している雰囲気を盛り上げるための特典制御を実行する。

発信コンボの発生認定は、連鎖条件を満たす状態が規模要件を満たす程に継続された場合に、肯定判定（認定判定）される。

連鎖条件は、発信されたタイミング（発信タイミング）に連続性が有り、且つ、それらの発信内容に関連性が有る場合に、連鎖条件が満たされたと肯定判定する。

連続性の判定は、発信タイミングの時間差が所定の「連続性認定時間差Δｔ」以下である場合に、それらは「連続性有り」と肯定判定される。
連続性認定時間差Δｔは、適宜設定可能である。例えば、５秒前後を設定すると好適である。なお、連続性認定時間差Δｔは、ストリーミング配信サービスで共通の値とすることもできるが、本実施形態では配信されるマルチメディアコンテンツのジャンルなどの内容に応じて異なる値を用意している。

関連性の判定は、「連続性有り」と判定された複数の発信内容を対象にして行われ、それら複数の発信内容の共通点やそれらが作り出すパターンの有無に基づいて行われる。換言すると、発信操作同士の関連性が有れば「関連性有り」と肯定判定される。

図６は、関連性有りと判定される例を説明するための図である。
図６（１）〜（６）は、関連性があると認定される異なるタイプの例を示しており、関連性の判定対象となる連続性を有すると判定された発信の内容（連続性を有する発信内容）の例を発信順に左から右に配列して示している。なお、配列されている発信の内容の例やその数は例示のための便宜上のものあり、実際の運用においてこれらに限定されるものではない。

図６（１）〜図６（４）に示すように、連続性を有する複数の発信内容が、共通点を有している場合に、それらは関連性が有ると判定される。
図６（１）の例では、何れも発信用画像８ａであって、その種類が共通するので関連性有りと判定される。共通点は発信用画像８の種類に限らない。連続性を有する発信内容とされる複数の発信用画像８の配色や形状でもよい。配色の場合は、最も広い面積を示す主要配色や、面積占有順上位の配色の色系、などでもよい。全体として丸型、△型、四角型、といった外形についての共通に着目して関連性の条件が定められていてもよい。

また、描かれている内容の共通性に着目してもよい。例えば、図６（２）のように、発信用画像８に描かれているキャラクタは異なるが、ポーズやアクションが共通している場合も、関連性有りと判定することができる。

図６（３）のように、キャラクタもポーズやアクションも厳密には異なるが、ポーズやアクションに共通のテーマ性がある場合も、関連性有りと判定することができる。図６（３）の例では、音楽演奏というテーマにおいて共通点があるので、関連性有りと判定されている。他にも「旗を振る」「メガホンで叫んでいる」「拍手をしている」といった３つのアクションが揃うと「応援」というアクションの共通テーマがあるので、関連性有りと判定することもできる。更に言えば、発信用画像８に描かれているキャラクタが、全体として１つの団体モーションを形成している場合（例えば、スタジアムでの応援に使用されるウェーブモーションなど）に、関連性有りと判定することもできる。

また更に、画像に含まれるテキストに着目すれば、図６（４）に示すように、発信用画像８に含まれるテキストの意味内容が同一であったり、共通のテーマ性がある場合も、関連性有りと判定することができる。図６（４）の例では、何れも「かわいい」を意味するので、関連性有りとしている。

図６（５）〜図６（６）に示すように、連続性を有する発信内容が、発信された順（発信順）にそれらを並べてみるとパターンを形成している場合や、所定の組み合わせが揃うと、関連性有りと判定される。

図６（５）の例では、連続性を有する発信内容全てに共通する共通点は無いが、発信用画像８ｆと発信用画像８ｂとが発信順に交互に発信された時系列パターンを形成しているので、関連性有りとされる。関連性有りと認める時系列パターンの内容は、適宜設定可能である。

また、図６（６）の例でも、発信用画像８ａ、８ｂ、８ｓ、８ｔはそれぞれ異なる種類であるが、所定の「花」シリーズが形成されているので、関連性有りと判定することができる。

図５に戻って、規模要件の判定は、連鎖条件を継続して満たしている回数（換言すると連鎖数）又は時間長が基準値に達している場合に肯定判定される。本実施形態では連鎖条件を継続して満たしている回数「３連鎖以上」とするが、２連鎖以上の値を適宜設定することができる。または、連続性認定時間差Δｔの当該回数を乗じて、連鎖条件を継続して満たしている時間長「３×Δｔ以上」と設定してもよい。

規模要件が満たされると、「発信コンボが発生した」と認定され、その規模を表す数（本実施形態では連鎖数）が「コンボの連鎖数」「コンボ数」となる。そして、発信コンボが発生すると、特典制御が実行される。

特典制御の内容は、適宜設定可能である。本実施形態では、視聴ユーザ２や提供ユーザへの特典の付与（例えば、アイテム、クーポン、抽選券、ポイント、などの付与）、視聴画面Ｗ３に適用される背景を特別な内容にする、視聴画面Ｗ３に特別な演出表示を行う、特別なイベント（例えば、特定の発信用画像８を一定時間無料で使えるようになる、など）を発生させる、などの内容が設定されている。

そして、特典制御の内容は、図６に示すように、関連性有りと判定される条件別に、異なる内容が割り当てられている。図６中の「特典Ａ１」「特典Ａ２」…がそれに該当する。つまり、発信コンボが発生したと認められたときに満たした関連性認定条件に応じて、実行される特典制御が変わることになる。

特典制御の内容によっては、連鎖数に応じて更に特典制御の内容に差異が設けられており、ストリーミング配信サービス全体でみると多様な特典制御が行われるようになっている。例えば、特典制御がアイテムを付与する内容であった場合、付与対象のユーザ１人当たりの付与数が、連鎖数が大きい程、より多くなるように設定して、差異を設けることができる。また、特別なイベントが発生する場合、連鎖数に応じてイベントの内容が異なるように設定するとしてもよい。

図７は、発信コンボの発生及び特典制御が実行されていることをユーザに報知する例を示す視聴画面図である。発信コンボの発生が認定され、特典制御が実行されると、視聴画面Ｗ７には、コンボ発生通知８０と、特典実行通知８２と、演出表示８４とが、汎用表示部３３に表示される。勿論、表示箇所の設定は、汎用表示部３３に限らず、画面内であれば何処でも良い。

コンボ発生通知８０は、発信コンボの連鎖数を含み、連鎖数に応じて異なるフォントや異なるサイズで報知内容が表示されるように設定されている。
特典実行通知８２は、実行されている特典制御の内容を告げる。
演出表示８４は、発信コンボの連鎖数や特典制御の内容に応じた種類が表示されて、動画視聴の雰囲気を盛り上げる。

さて、本実施形態では、こうした発信コンボの仕様を利用して、更にユーザ体験をより豊かにする工夫が盛り込まれている。それを「秘密イベント」と言う。

図８は、秘密イベントについて説明するための視聴画面例を示す図である。
「秘密イベント」は、同じマルチメディアコンテンツを視聴している視聴ユーザ２同士で、お互いの発信内容が分からない状況で、秘密条件として設定された発信コンボの条件を達成した場合に、特別な特典を獲得することができる視聴者参加型のマルチプレイイベントである。

特定のイベント開始条件が満たされると、「秘密イベント」が発動する。そして、秘密イベントが発動すると、少なくとも関連性の条件を含む秘密条件が自動で設定される。

一方、視聴画面Ｗ８では、秘密イベントが発動すると、秘密イベント発生通知７０が表示されて、視聴ユーザ２にイベント発生が告知される。しかし、秘密条件とされた関連性の条件は視聴ユーザ２には明かされず、ヒント表示７２が視聴画面Ｗ８に表示されるにとどまる。ヒント表示７２は、秘密条件とされた関連性の内容に関する間接的な情報や連想させる情報、いわゆるヒントを開示する。ヒント表示７２は、全視聴ユーザ２に向けた秘密イベントのクリアのための「お題」の提示とも言える。

秘密条件とされた関連性の内容によっては、開示可能な情報が複数、つまりはヒントが複数用意されている場合もある。その場合は、視聴画面Ｗ８に表示される追加ヒント要求操作アイコン３８を操作することによって、追加ヒント表示７４を表示させることができる。但し、追加ヒントの要求には対価が要求される。対価は、電子決済による仮想通貨の消費、特定のアイテムや発信用画像８の消費、などによって実現される。勿論、対価は「０」、すなわち無償に設定することも可能である。

さて、視聴ユーザ２は、ヒント表示７２を参考にして、皆の発信で秘密条件とされた関連性の内容に当たりをつけて、思い思いにテキストや画像の発信を行うことになる。しかし、自分が発信者である発信内容の反映表示は自分の端末においては当該発信内容が明示され（明示形態）、他者の発信内容の反映表示は、その発言内容が非明示な状態（非明示形態）で、つまり「目隠し」された状態で表示される。そのため、そう簡単には秘密条件を満たす発信コンボを作ることはできないようになっており、イベントに視聴者参加型のゲームとしての趣向をもたらしている。

図８の例では、図示の視聴画面Ｗ８が表示されている視聴端末のユーザ端末１５００ａを使用する視聴ユーザ２ａが発信操作した発信用画像８（８ｇ）は標準形態（明示形態）で表示されている。本実施形態では、発信用画像８（８ｇ）がそのまま表示される。対して、他の視聴ユーザが発信したテキストや発信用画像は非明示形態で表示される。本実施形態では、目隠し７（７ｂ、７ｃ、…）で覆われて、視聴端末のユーザ端末１５００ａを使用する視聴ユーザ２ａには、その内容が見えないように表示されている。

非明示形態で反映表示された他の視聴ユーザが発信したテキストや発信用画像は、吹き出し５ｂや近接するアバター４（４ｂ、４ｃ）との相対位置から、概ねどの視聴ユーザによる発信であるかが知れるが、本実施形態では、視聴ユーザ別に固有の目隠し７（７ｂ，７ｃ，…）が設定されており、目隠し７（７ｂ，７ｃ，…）のデザインからもそれがどの視聴ユーザによる発信であるかが分かるようになっている。

視聴ユーザ各々が、他者の発信内容が見えない状態で、発信した結果、見事ターゲットとして設定されている秘密条件を満たす発信コンボを実現すると、当該秘密条件に対応づけられる秘密イベント用の特別特典制御が実行される。この特別特典制御は、秘密イベントではない通常時における発信コンボが発生した場合の特典制御よりも価値ある内容とされる。

そして、各視聴端末では図９に示すように視聴画面Ｗ９が表示される。具体的には、汎用表示部３３では、イベントクリア通知８６と、秘密イベントのクリア特典の内容を通知する秘密イベント用特典通知８２と、演出表示８４と、が表示される。そして、発信内容表示部３５では、非明示形態で表示されていた他視聴ユーザの発言内容が標準形態で表示される。つまり、目隠し７がリベールされ、明示形態とされる。そして、秘密イベントは終了となる。

さて、このように秘密イベントでは、他者の発信内容は目隠しされている。
そのため、図６（１）のように、花柄の発信用画像８を揃えるといった、最も単純なパターンの発信コンボの形成すら困難になる可能性も否定できない。
そこで、本実施形態では、秘密イベントが発動すると、関連性認定条件を秘密イベント中に限り緩和する「緩和条件」を設定する。緩和条件を設けることで、関連性認定条件の判定対象とされる発信内容に、関連性認定条件の成立を阻害する発信内容（以下、「阻害発信」と呼称）が少数含まれていても、便宜上、関連性認定条件が満たされたと見なされるようにする。

「緩和条件」としては、
１）関連性認定条件の判定対象に含まれる阻害発信の許容数、
２）関連性認定条件の判定対象数に含まれる阻害発信の許容割合、
３）途切れ許容時間差条件ΔＵ、
の少なくとも何れかを設定することができる。

途切れ許容時間差条件ΔＵは、図１０に示すように、判定対象とする発信内容の発信タイミングに着目して、阻害発信（図１０の例では発信用画像８ｓ）の発信タイミングｔ４から途切れ許容時間差条件ΔＵ以内に、途中まで満たされていた関連性認定条件（図１０の例では、画像種類が発信用画像８ａで共通）を継続して満たす新たな発信用画像８ａの発信タイミングｔ５までの時間である。図１０の例では、規模要件を「４つ以上」とした場合、緩和条件が無ければ、全部で発信用画像８ａが４つあるが、阻害発信となる発信用画像８ｓが中途に存在することにより規模要件を満たせずに発信コンボが成立しない。しかし、緩和条件が有ることで、阻害発信となる発信用画像８ｓが判定対象から除外され、発信コンボの発生と認定されることになる。
因みに、緩和条件が「許容数＝１以下」或いは「許容割合＝２０％以下」に設定している場合でも、図１０と同じ結果となる。

なお、秘密イベントは、秘密条件とされた関係性を満たす発信コンボがそれまでに実現されなくとも、所定のイベント終了条件が満たされると自動的に終了される。イベント終了条件は、適宜設定可能である。例えば、イベント開始から所定時間経過、発信用画像８のうち当該イベントに限り設定されるＮＧテキストやＮＧ画像（終了条件として設定された発信内容）が発信された場合、などを設定できる。

秘密イベント終了時点で、まだ秘密条件とされた関係性を満たす発信コンボがそれまでに実現されていない場合は、目隠し７はそのままとなる。そして、目隠し７は通常の反映表示と同様に、表示開始から所定時間で発信内容表示部３５から消去される。その際、目隠し７を消去する際に、目隠し７が先に消去されて、これに覆い隠されていた発信用画像８が一瞬だけ見えるように表示制御するとしてもよい。

［機能構成の説明］
図１１は、本実施形態におけるストリーミングサーバ１１００の機能構成例を示す機能ブロック図である。本実施形態におけるストリーミングサーバ１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、音出力部３９０ｓと、画像表示部３９２ｓと、通信部３９４ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段である。図１のキーボード１１０６がこれに該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、ユーザ端末１５００から受信したデータ、等に基づいて各種の演算処理を実行して、ストリーミングサーバ１１００の動作を統合的に制御する。

そして、本実施形態のサーバ処理部２００ｓは、ユーザ管理部２０２と、オンラインショッピング管理部２０４と、配信サービス管理部２１０と、計時部２８０ｓと、音生成部２９０ｓと、画像生成部２９２ｓと、通信制御部２９４ｓとを含む。勿論、これら以外の機能部も適宜含めることができる。

ユーザ管理部２０２は、ユーザ登録手続きに係る処理及びユーザアカウントに紐付けられる各ユーザのデータの管理を行う。本実施形態では、ユーザ管理部２０２は、１）登録ユーザへの固有のユーザアカウントの付与と、２）ユーザアカウント別に個人情報を登録管理する登録情報管理と、３）課金要素（本実施形態ではオンラインショッピングなど）の支払いで消費される電子決済媒体の帳簿管理と、４）ログイン及びログアウトの履歴等を管理する利用履歴管理と、５）アバター４の作成・編集機能と、の各機能を有する。勿論、これら以外のアカウントに紐付けられる他のデータの管理機能も適宜含めることができる。

オンラインショッピング管理部２０４は、オンラインショッピングに関する制御を担い、公知のオンラインショッピング技術を適宜利用して実現できる。本実施形態では、視聴ユーザ２は、オンラインショッピングによって、発信用画像８などを購入することができる。オンラインショッピングにおける販売対象は、これら以外にも適宜設定可能である。

配信サービス管理部２１０は、動画配信サービスの実行管理に係る各種処理を行う。そして、本実施形態の配信サービス管理部２１０は、マルチメディアコンテンツのストリーミング配信サービスを実現するための各種処理を行う。例えば、マルチメディアコンテンツの配信スケジュールの管理処理、視聴ユーザの管理処理、提供端末から配信用のマルチメディアコンテンツのコンテンツデータを取得する処理、ストリーミング配信処理、などを実行することができる。勿論、これら以外の処理も適宜含めることができる。

そして、本実施形態では、配信サービス管理部２１０は、アバター表示制御部２１２と、発信反映制御部２１４と、連鎖条件設定部２１６と、規模要件設定部２１８と、秘密イベント制御部２２０と、特典制御実行部２３０と、活況指標値算出部２３２と、ランキング管理部２３４と、を有する。勿論、これら以外の機能部も適宜含むとしてもよい。

アバター表示制御部２１２は、視聴画面に、視聴ユーザ別のアバターを表示させる制御を行う。本実施形態では、視聴ユーザ別のアバターを表示させるためのデータの配信がこれに含まれる。

発信反映制御部２１４は、視聴中のマルチメディアコンテンツに対する発信操作が入力されたことを視聴者ユーザのユーザ端末（視聴端末）から受け付けて、当該発信操作がなされた反映表示を視聴端末における視聴画面中に表示させる制御を行う。

本実施形態では、視聴端末から発信操作に応じて発信リクエストともに発信内容のデータを受け付け、一時記憶し、全視聴端末及び提供端末へ向けて、発信内容のデータを配信する処理がこれに該当する。そして、本実施形態では、視聴端末側で、受信した発信内容が反映された表示体を発信内容表示部３５（図３参照）に表示させる反映表示の表示制御を行う。具体的には、吹き出し５によるテキストの表示や、発信用画像８の出現表示がこれに該当する。つまり、発信反映制御部２１４は、発信操作に係る視聴ユーザ２のアバターが所与のアクション動作を行うように表示制御することができる。

なお、ストリーミングサーバ１１００が、発信内容表示部３５として表示される画像それ自体も配信の対象とする場合には、発信反映制御部２１４がその画像を生成するとしてもよい。

連鎖条件設定部２１６は、本実施形態で言う所の「発信コンボ」の発生を認定するための条件の１つである連鎖条件を、配信されるマルチメディアコンテンツの種類等に応じて可変に設定する。配信されるマルチメディアコンテンツがゲームプレイ動画である場合には、連鎖条件を、視聴中のゲームプレイ動画に係るゲーム状況に応じて可変に設定することができる。また、連鎖条件の設定に際しては、複数の視聴ユーザにより入力された発信操作同士の関連性を認定するための関連性認定条件を更に含むように連鎖条件を設定する。

規模要件設定部２１８は、本実施形態で言う所の「発信コンボ」の発生を認定するための条件の１つである規模要件を、配信されるマルチメディアコンテンツの種類に応じて可変に設定する。配信されるマルチメディアコンテンツがゲームプレイ動画である場合には、規模要件を、視聴中のゲームプレイ動画に係るゲーム状況に応じて可変に設定することができる。また、規模要件の設定に際しては、連鎖条件を満たした数または時間に基づく条件や、連鎖条件を満たす発信操作を行った視聴ユーザの数に基づく条件、が含まれるように規模要件を設定することができる。

秘密イベント制御部２２０は、秘密イベントに係る各種制御を実行する。具体的には、イベント開始終了制御部２２１と、秘密条件設定部２２２と、緩和条件設定部２２３と、第１表示制御部２２４と、イベントクリア判定部２２５と、第２表示制御部２２６と、ヒント表示制御部２２７と、を含む。

イベント開始終了制御部２２１は、秘密イベントの発生・終了の判定と制御を行う。

秘密条件設定部２２２は、発生した秘密イベントにて適用される関連性認定条件を選択し秘密条件として設定する。本実施形態では、配信されるマルチメディアコンテンツの内容及び／又は当該マルチメディアコンテンツの視聴状況に応じて秘密条件を設定することができる。配信されるマルチメディアコンテンツがゲームプレイ動画の場合は、ゲームプレイ動画に係るゲーム状況に応じて秘密条件を設定することができる。

緩和条件設定部２２３は、秘密条件とされた関連性認定条件の判定に際し、条件を満たす（＝認める）ための緩和内容を設定する。

第１表示制御部２２４は、発信内容の表示形態を視聴端末とされるユーザ端末別に制御する機能部であって、当該ユーザ端末の視聴ユーザが発信した発信内容（自身発信内容）を明示形態、当該ユーザ端末の視聴ユーザ以外が発信した発信内容（他者発信内容）を非明示形態として視聴画面中に表示させる制御を行う。

本実施形態では、視聴端末にて新たな発信操作が行われる毎に、全視聴端末へ向けて同じ情報を配信するので、視聴端末側で当該新たな発信の発信内容が、自身発信内容であるか他者発信内容であるかを判定するための情報として、発信者のユーザアカウントと、目隠し７の情報と、を配信内容とともに送信する。

イベントクリア判定部２２５は、複数の視聴ユーザによる複数の発信内容が、少なくとも所与の関連性認定条件を含む秘密条件を満たすか否かを判定する。本実施形態では、緩和条件設定部２２３が設定した緩和条件を適用して判定する。

また、イベントクリア判定部２２５は、秘密条件を満たすか否かの判定対象とする発信内容を発信順に選択し、且つ、同一の視聴ユーザによる発信を連続して選択しないように選択することができる。異なる視聴ユーザによる交互の発信のみを判定対象とすることで、発明の目的に即するように、１人の視聴ユーザによるイベントクリアではなく、複数の視聴ユーザの参加によるイベントクリアを求めるようにしている。

第２表示制御部２２６は、イベントクリア判定部２２５により肯定判定された発信内容であって、第１表示制御部２２４により非明示形態とされた発信内容を、明示形態に変更して表示させる制御を行う。本実施形態では、所定の秘密イベントのクリア通知の配信がこれに該当する。

ヒント表示制御部２２７は、秘密条件のヒントを視聴端末とされるユーザ端末に表示させる制御を行う。本実施形態では、視聴端末にて、追加ヒント要求操作アイコン３８への操作が検出された場合には、追加ヒント表示７４（図８参照）を表示させることが可能である。その場合、追加ヒントを、提供ユーザ又は視聴ユーザによる所定の対価支払と引き換えに、マルチメディアコンテンツを視聴中の視聴ユーザ全員のユーザ端末に表示させる。なお、追加ヒントの表示は、追加ヒント要求操作アイコン３８へ操作した視聴ユーザの視聴端末に限定する構成としてもよい。また、対価支払いの引き換えによるヒント表示は、追加ヒントに限らずヒント表示７２（図８参照）についても適用する構成も可能である。

特典制御実行部２３０は、発信コンボの発生及び秘密イベントのクリアに伴い、視聴ユーザ及び／又は提供ユーザに所与の特典を付与する制御を実行する。その際、コンテンツの種類や、満たされた関連性認定条件、満たされた規模要件に応じて付与する特典を可変に制御することができる。配信されるマルチメディアコンテンツがゲームプレイ動画である場合には、ゲームプレイ動画に係るゲーム状況に応じて、付与する特典を可変に制御することができる。

活況指標値算出部２３２は、視聴ユーザの発信状況を少なくとも用いて、当該コンテンツに係る活況指標値を算出する。

ランキング管理部２３４は、活況指標値に基づいて各コンテンツをランキングする。

計時部２８０ｓは、システムクロックを利用して現在日時や制限時間等の計時を行う。

音生成部２９０ｓは、音声データの生成やデコードをするＩＣやソフトウェアの実行により実現され、ストリーミングサーバ１１００のシステム管理や動画配信に係る操作音やＢＧＭなどの音声データを生成或いはデコードする。そして、システム管理に関する音声信号は音出力部３９０ｓへ出力する。

音出力部３９０ｓは、音声信号を放音する。図１の例では本体装置１１０１やタッチパネル１１０８が備えるスピーカ（不図示）がこれに該当する。

画像生成部２９２ｓは、ストリーミングサーバ１１００のシステム管理に関する画像等を生成することができる。そして、システム管理に関する画像は画像表示部３９２ｓへ出力することができる。

画像表示部３９２ｓは、画像生成部２９２ｓから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１の例ではタッチパネル１１０８が該当する。

通信制御部２９４ｓは、データ通信に係るデータ処理を実行し、通信部３９４ｓを介して外部装置とのデータのやりとりを実現する。

通信部３９４ｓは、通信回線９と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図１の例では通信装置１１５３が該当する。

サーバ記憶部５００ｓは、サーバ処理部２００ｓにストリーミングサーバ１１００を統合的に制御させるための諸機能を実現するためのプログラムや各種データ等を記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、サーバ処理部２００ｓが各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスク、オンラインストレージなどによって実現される。図１の例では本体装置１１０１が搭載するＩＣメモリ１１５２やハードディスクなどの記憶媒体、及びストレージ１１４０がこれに該当する。

図１２は、本実施形態におけるサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。本実施形態におけるサーバ記憶部５００ｓは、サーバプログラム５０３と、配信用提供端末プログラム５０５と、配信用視聴端末プログラム５０７と、販売品管理データ５０９と、配信サービス初期設定データ５１０と、を記憶する。

また、サーバ記憶部５００ｓは、ストリーミング配信に係り逐次生成・管理されるデータとして、提供ユーザ登録データ５９０と、ランキングデータ５９９と、ユーザ管理データ６００と、配信管理データ６２０と、現在日時８００と、を記憶する。その他、タイマや、カウンタ、各種フラグなどの情報を適宜記憶できる。

サーバプログラム５０３は、サーバ処理部２００ｓが読み出して実行することで、ユーザ管理部２０２と、オンラインショッピング管理部２０４と、配信サービス管理部２１０としての機能を実現させるためのプログラムである（図１１参照）。

配信用提供端末プログラム５０５は、提供端末として使用されるユーザ端末１５００へダウンロードされるアプリケーションプログラムのオリジナルであって、これを実行することにより、そのユーザ端末１５００は提供端末として機能できるようになる。
なお、配信用提供端末プログラム５０５は、ライブ配信機能を実装したゲームを実行可能にするためのゲームプログラムの中に含まれている構成も可能である。

配信用視聴端末プログラム５０７は、視聴端末として使用されるユーザ端末１５００へダウンロードされるアプリケーションプログラムのオリジナルであって、これを実行することにより、そのユーザ端末１５００は視聴端末として機能できるようになる。

販売品管理データ５０９は、オンラインショッピングによる販売品を定義・管理するためのデータを格納する。例えば、購入可能なデータと、在庫数、その課金対価（決済媒体からの引き落とし額に相当）とを対応づけて格納している。

配信サービス初期設定データ５１０は、本実施形態のストリーミング配信サービスを実行するための各種初期設定データを格納している。本実施形態では、発信用画像定義データ５２０と、連続性認定条件定義データ５３０と、関連性認定条件定義データ５４０と、規模要件定義データ５５０と、特典定義データ５６０と、秘密イベント定義データ５７０と、コンボ発生報知定義データ５８０と、を含む。勿論、これら以外のデータも適宜含めることができる。例えば、アバター４を作成・編集するための素材データや、視聴画面の背景画像とすることのできる複数の背景データ、各種演出表示のための素材データを含めることができる。

発信用画像定義データ５２０は、発信用画像８を定義するデータである。
１つの発信用画像定義データ５２０は、例えば図１３に示すように、発信用画像種類５２１と、発信用画像データ５２２と、販売価格５２３と、レアリティ５２４と、当該発信用画像が反映表示されてから消えるなどの表示形態の変更が行われるまでの表示持続時間５２５と、を含む。勿論、これら以外のデータも適宜含めることができる。

図１２に戻って、連続性認定条件定義データ５３０は、異なる視聴ユーザによる時間的に隣接する発信操作が、連続性を有すると見做すための条件を定義する情報を格納する。本実施形態では、連続性認定時間差Δｔ（図５参照）を定義している。本実施形態では、連続性認定条件定義データ５３０は、連続性認定時間差Δｔが１つのみであるが、マルチメディアコンテンツの内容、例えばジャンルなど、に応じて連続性を認定する条件を違えたい場合には、選択条件別に異なる連続性認定時間差Δｔを対応づけて格納すればよい。

関連性認定条件定義データ５４０は、関連性を認定するための条件を定義する各種データを格納する。１つの関連性認定条件定義データ５４０は、例えば図１４に示すように、固有の関連性ＩＤ５４１と、当該定義データが選択・適用される条件を記述する選択条件５４２と、関連性認定条件５４４と、１つ又は複数のヒントデータセット５４６と、を含む。勿論、これら以外のデータも適宜含めることができる。

選択条件５４２は、更に、マルチメディアコンテンツの付帯情報とされる内容に関する条件を含む。本実施形態では、ジャンル条件５４２ａと、提供ユーザ条件５４２ｂと、被写体条件５４２ｃと、状況条件５４２ｄと、視聴ユーザ数条件５４２ｅと、コンボ発生回数条件５４２ｆとを含み、それらのＡＮＤ条件又はＯＲ条件として記述される。勿論、選択条件５４２が内包するこれらの条件は、「設定なし」の場合もあり得る。

ジャンル条件５４２ａは、視聴されるマルチメディアコンテンツのジャンルについての条件である。例えば、「ゲームプレイ実況」の時だけに適用される関連性認定条件を用意することもできる。

提供ユーザ条件５４２ｂは、提供ユーザに関する情報についての条件である。例えば、ユーザアカウント、ユーザ歴、年齢、性別、特定ゲームタイトルにおけるプレーヤレベルや称号、ストリーミング配信サービスにおける人気ランキングのランキング順位、などについての条件を設定できる。

被写体条件５４２ｃは、配信されるマルチメディアコンテンツの主たる被写体についての条件である。例えば、提供ユーザ自身、子供、動物、料理、自動車、紹介する物品、演奏する楽器や曲目、演奏バンド名、ゲームジャンル、ゲーム名、プレイするゲームキャラクタ、などである。それらの固有名を当該条件に含めることもできる。その場合、複数の固有名をＡＮＤ条件又はＯＲ条件として定義してもよい。

状況条件５４２ｄは、配信されるマルチメディアコンテンツの内容の状況についての条件である。提供ユーザが、提供するマルチメディアコンテンツに付帯する情報の中にも、状況に関する情報が含まれている。例えば「（曲名）を演奏してみた」「（番組名のエンディング）を踊ってみた」「（製品名）の開封」「（ゲームタイトル）のステージ難所をクリア」「（ゲームタイトル）の第４ステージボスキャラ攻略」、などとなる。よって、状況条件５４２ｄは、それらに含まれるキーワードを設定することにより定義付けできる。

視聴ユーザ数条件５４２ｅは、その時の視聴ユーザ数についての条件である。
コンボ発生回数条件５４２ｆは、それまでに発生認定された発信コンボの回数についての条件である。
その他、配信中のマルチメディアコンテンツのランキング順位、配信開始からの発信累計数なども選択条件５４２を記述する情報として利用することもできる。

関連性認定条件５４４は、共通点条件５４４ａと、組み合わせ条件５４４ｂと、のＡＮＤ条件又はＯＲ条件として記述される。関連性認定条件５４４が含むこれらの条件は、何れも「設定なし」を含み得る。

共通点条件５４４ａは、連続性を有する複数の発信の発信内容である発信用画像８やテキストに共通するべき要件を定義する。例えば、発信用画像８の種類や、発信用画像８に含まれる（描かれている）共通のテキスト、主要配色、共通と認められる被写体種類のリスト、等を設定することができる。主要配色は、発信用画像８の他、発信されたテキストのフォントカラーにも適用できる。

組み合わせ条件５４４ｂは、連続性を有する複数の発信の発信内容である発信用画像８やテキストの組み合わせを定義する。例えば、発信用画像８の種類のリスト、発信用画像８の主要配色のリスト、発信用画像８に含まれている（描かれている）テキストのリスト、発信されたテキストの戦闘文字の組み合わせ、発信用画像８の種類とテキストの組み合わせ、などであり、それらの発信順も定義に含めることができる。

より具体的には、例えば、「四季の花」と言うタイトルの発信用画像８のシリーズがあったとして、当該シリーズを構成する発信用画像８の種類のリストを定義すれば、四季の花が反映表示として時系列に揃うと、関連性ありと認定される条件を定義できる。また、主要配色のリストに、虹の構成色を、発信順が虹におけるそれらの配列順と同じとなるように設定すれば、連続性を有するとされる発信された発信用画像８（連続性を有するとされた発信操作群）に描かれているものは何であれ、発信順に並べると虹と同じ配色パターンを構成していれば、関連性を認定するとする条件を定義できる。

ヒントデータセット５４６は、ヒント選択条件５４６ａ別に、１つ又は複数の第１ヒント５４６ｂと、１つ又は複数の追加ヒントリスト５４６ｃと、ヒント対価５４６ｄと、対価支払者５４６ｅと、を含む。

ヒント選択条件５４６ａは、当該セットが選択される条件を定義する。本実施形態では、配信中のマルチメディアコンテンツの内容や、視聴状況を条件とする。例えば、マルチメディアコンテンツのジャンル、視聴ユーザ数、それまでの配信コンボ発生回数、配信中のマルチメディアコンテンツのランキング順位、などを、ヒント選択条件５４６ａを記述する情報として利用することができる。

第１ヒント５４６ｂは、ヒント表示７２（図８参照）として表示される内容を定義する。視聴ユーザに向けた「お題」と称しても良い。複数の場合には、何れかをランダムに選択して使用することとする。設定無しも可能である。

追加ヒントリスト５４６ｃは、追加ヒント要求操作に応じて開示・表示される追加ヒントの内容を開示される順番に格納する。追加ヒントは、第１ヒント５４６ｂの後に開示されるので、第２ヒント以降のヒントを順に格納しているといえる。なお、追加ヒントは設定無しも可能である。

ヒント対価５４６ｄは、追加ヒントの表示の支払対価を定義する。対価無しは勿論のこと、追加された追加ヒントの数に応じて対価が変化するように設定してもよい。

対価支払者５４６ｅは、追加ヒントの表示対価を誰が支払うかを指定する。基本的には、追加ヒントの要求操作をした視聴ユーザとするが、提供ユーザや、両方としてもよい。

図１２に戻って、規模要件定義データ５５０は、発信コンボの発生を認めるために必要とされる、連続性のある発信の規模に関する条件（規模要件）を定義するデータを格納する。１つの規模要件定義データ５５０は、例えば図１５に示すように、固有の規模要件ＩＤ５５１と、選択条件５５２と、要件数５５３と、を含む。勿論、これら以外のデータも適宜含めることができる。

選択条件５５２は、関連性認定条件定義データ５４０の選択条件５４２（図１４参照）と同様に構成されている。

要件数５５３は、本実施形態における連鎖条件を満たして継続している規模を定義する値である。本実施形態では、連続性および関連性があると認定された複数の発信の基準となる数を定義している。連続性認定時間差Δｔ（図５参照）と要件数５５３とを乗じて、継続時間の長さで定義するとしてもよい。

図１２に戻って、特典定義データ５６０は、発信コンボの発生が認定された場合に実行される特典制御の内容毎に用意され、特典制御を定義する各種データを格納する。
例えば図１６に示すように、１つの特典定義データ５６０は、固有の特典ＩＤ５６１と、適用関連性ＩＤリスト５６２と、標準特典実行通知素材５６３と、標準特典実行データ５６４と、秘密イベント用特典実行通知素材５６５と、秘密イベント用特典実行データ５６６と、追加特典付与条件５６７と、追加特典通知素材５６８と、追加特典実行データ５６９と、を含む。

適用関連性ＩＤリスト５６２は、当該定義データが適用される発信コンボや秘密イベントを指定する情報である。当該リストで指定された関連性ＩＤの関連性認定条件を満たした発信コンボに当該定義データが適用されることを示す。また、当該リストで指定された関連性ＩＤの関連性認定条件を秘密条件とした秘密イベントにてイベントがクリアされると当該定義データが適用されることを示す。

標準特典実行通知素材５６３と、標準特典実行データ５６４は、それぞれ秘密イベントが開始されていない状態で、適用関連性ＩＤリスト５６２の関連性が満たされた発信イベントが発生したと認められた場合の特典の実行通知と、特典制御を実行するためのデータとを定義している。

秘密イベント用特典実行通知素材５６５と、秘密イベント用特典実行データ５６６は、それぞれ秘密イベントがクリアされた場合の特典の実行通知と、特典制御を実行するためのデータとを定義している。

追加特典通知素材５６８と、追加特典実行データ５６９は、それぞれ秘密イベントがクリアされた場合で、且つ、追加特典付与条件５６７（例えば、追加ヒント無しで、発信コンボの連続数が１０に到達した場合）を満たした場合に限定した追加の特典の実行通知と、その特典制御を実行するためのデータとを定義している。なお、追加特典付与条件５６７と、追加特典通知素材５６８と、追加特典実行データ５６９とは、設定無しとしてもよい。

特典の内容は、適宜設定可能である。アイテム、電子決済用の決済媒体、特別な発信用画像、オンラインショッピングでの割り引き券、などの付与は勿論、イベントの発生、視聴画面の特別な背景への変更、なども特典制御の内容として設定することができる。多彩な特典内容を用意することでマンネリ化を防ぎつつ、より視聴ユーザに積極的な発信を促すことができる。

図１２に戻って、秘密イベント定義データ５７０は、秘密イベントを定義する各種データを格納する。例えば図１７に示すように、固有の秘密イベントＩＤ５７１と、イベント開始条件５７２と、イベント終了条件５７３と、秘密条件とされる関連性認定条件を指定する秘密条件指定関連性ＩＤ５７４と、緩和条件定義データ５７６と、を含む。勿論、これら以外のデータも適宜含めることができる。

緩和条件定義データ５７６は、配信されるマルチメディアコンテンツの内容や視聴状況に応じて複数種類用意されている。１つの緩和条件定義データ５７６は、適用条件５７６ａと、緩和条件５７６ｂとを含む。適用条件５７６ａは、例えば、マルチメディアコンテンツのジャンル、視聴ユーザ数、それまでの発信コンボ発生回数、配信中のマルチメディアコンテンツのランキング順位、提供ユーザの情報、などで記述することができる。

図１２に戻って、コンボ発生報知定義データ５８０は、発信コンボの発生を視聴ユーザ２等に報知する状況別に用意され、発信コンボの発生を報知する方法と内容を定義する各種データを格納する。１つのコンボ発生報知定義データ５８０は、例えば図１８に示すように、適用関連性ＩＤリスト５８１と、適用連鎖数範囲５８２と、標準報知素材データ５８３と、秘密イベント用報知素材データ５８４と、を格納する。

適用関連性ＩＤリスト５８１と、適用連鎖数範囲５８２とで、当該定義データが適用される条件を定義している。適用関連性ＩＤリスト５８１は、当該定義データが適用される条件であって、発信コンボの発生が認定されたときに満たしているべき関連性の種類を定義している。適用連鎖数範囲５８２は、発信コンボの連続数・連鎖数の範囲を指定している。

標準報知素材データ５８３は、秘密イベントが開始されていない状況で発信コンボが発生した場合の報知の内容を定義する。視聴画面Ｗ７（図７参照）にて表示するコンボ発生通知８０や演出表示８４の素材データ（画像データ又はテキスト）、フォント種類、表示サイズ、表示位置、表示時間などを格納する。表示位置は、汎用表示部３３に限らず、視聴画面の外周であったり、背景であったり、適宜設定可能である。

同様に、秘密イベント用報知素材データ５８４は、秘密イベントが開始されている状況で発信コンボが発生した場合の報知の内容を定義する。視聴画面Ｗ９（図９参照）のイベントクリア通知８６や演出表示８４の素材データ（画像データ又はテキスト）、フォント種類、表示サイズ、表示位置、表示時間などを格納する。表示位置は、汎用表示部３３に限らず、視聴画面の外周であったり、背景であったり、適宜設定可能である。

図１２に戻って、提供ユーザ登録データ５９０は、登録ユーザのうち提供ユーザの経験者別に用意された特別な登録データである。１つの提供ユーザ登録データ５９０は、例えば図１９に示すように、ユーザアカウント５９１と、配信素材データ５９２と、累積活況指標値５９３と、を含む。

配信素材データ５９２は、当該提供ユーザが提供したストリーミング配信用の素材毎に用意され、固有の配信タイトル、マルチメディアコンテンツデータ、付帯情報などを格納する。非ライブ配信の場合には、提供ユーザの提供操作に応じて予め用意されることになる。ライブ配信の場合には、提供端末より受信した配信用データをマルチメディアコンテンツデータとして配信中に逐次格納するとしてもよい。

累積活況指標値５９３は、ストリーミング配信を１つの番組や舞台、ステージと見立てた場合の盛り上がり度合、人気度合を表す指標値である活況指標値の累積値である。活況指標値は、視聴ユーザ２の発信数、視聴ユーザ２の数、のべ視聴時間などに応じて付与される。累積された活況指標値で、ランキングデータ５９９（図１２参照）が決まる。

図１２に戻って、ユーザ管理データ６００は、登録ユーザ毎に用意され、固有の識別情報であるアカウントと紐付けられる各種データを格納する。本実施形態では、例えば図２０に示すように、１つのユーザ管理データ６００は、固有のユーザアカウント６０１と、決済媒体帳簿データ６０２と、アバター設定データ６０３と、目隠し７（７ａ，７ｂ，…；図８参照）を表示させるための目隠しデータ６０４と、保有発信用画像管理データ６０８と、発信ログデータ６１０と、を含む。勿論、これら以外のデータも適宜含めることができる。

決済媒体帳簿データ６０２は、当該ユーザに紐付けられる電子決済用の決済媒体（例えば、仮想通貨、サービス内通貨、特定のアイテム）の補充／消費の量と、補充／消費の事由と、変更日時と、の情報を対応づけて格納する所謂帳簿である。課金履歴データ或いは課金履歴情報と読み替えることができる。

アバター設定データ６０３は、当該ユーザのアバター４（図３参照）の設定データを格納する。

保有発信用画像管理データ６０８は、当該ユーザが保有している発信用画像８の種類毎に用意され、当該発信用画像８の最新の保有状態を記述する各種データが格納される。例えば、発信用画像８の種類と保有数とを含む。勿論、これら以外のデータ、例えば消費期限なども適宜含めることができる。

発信ログデータ６１０は、当該ユーザが視聴ユーザ２として発信操作する毎に作成される。１つの発信ログデータ６１０は、例えば、発信タイミング（発信日時）、発信対象配信タイトル、発信対象の提供ユーザのユーザアカウント、発信内容、を格納する。勿論、これら以外のデータも適宜含めることができる。

図１２に戻って、配信管理データ６２０は、ストリーミング配信毎に用意され、配信状況を記述する各種データを格納する。１つの配信管理データ６２０は、例えば図２１に示すように、配信タイトル６２１と、配信スケジュール６２２と、マルチメディアコンテンツデータ６２３と、付帯情報６２４と、背景データ６２５と、視聴ユーザ管理データ６２６と、アバター表示管理データ６２７と、発信実績データ６２８と、秘密条件設定データともなり得る連鎖条件設定データ６３０と、適用規模要件６３６と、連鎖数６３８と、コンボ発生回数６３９と、実行中秘密イベントＩＤ６４０と、適用ヒントデータセット６４１と、ヒント提示数６４２と、を含む。勿論、これら以外のデータも適宜含めることができる。

背景データ６２５は、視聴画面の背景を定義している。

視聴ユーザ管理データ６２６は、視聴ユーザ２毎に用意され、視聴完了まで保存される。１つの視聴ユーザ管理データ６２６は、ユーザアカウントと、当該視聴ユーザ２の視聴端末に通信回線９を介して通信接続するための情報（例えば、ＩＰアドレスなど）である視聴端末アクセス情報と、視聴開始日時と、視聴終了日時とを格納する。同じ視聴ユーザ２が、時間を置いて視聴する場合には、その都度の視聴開始日時と視聴終了日時とが追加格納され、当該視聴ユーザが配信中に視聴を中断したこと、配信中ののべ視聴時間がどれだけかを求めることができるようになっている。

アバター表示管理データ６２７は、視聴中の視聴ユーザ２のアバター毎に用意され、最新の表示状態を記述する各種データを格納する。１つのアバター表示管理データ６２７は、視聴ユーザ２のユーザアカウントと、アバターデータと、配置位置座標と、目隠し７（図９参照）の目隠しデータと、を格納する。勿論、これら以外のデータ、例えばアバターの表示サイズや、付加表示物のデータなども適宜含めることができる。

発信実績データ６２８は、視聴ユーザ２が視聴端末で発信操作する毎に作成される。
１つの発信実績データ６２８は、発信者である視聴ユーザ２のユーザアカウントと、発信タイミングと、発信内容データと、を含む。発信内容データは、テキスト発信の場合は、メッセージ等のテキスト、フォント、サイズなどを含む。画像発信の場合は、発信用画像データ５２２、表示持続時間５２５、などを含む（図１３参照）。勿論、これら以外のデータも発信実績データ６２８に含めることができる。

連鎖条件設定データ６３０は、発信コンボの発生を認定するための要件を定義するデータを格納する。換言すると「発信コンボ発生認定条件設定データ」である。連鎖条件設定データ６３０は、秘密イベント実行中にもイベントクリア判定の際に参照されるので、イベントをクリアするための「秘密条件設定データ」も兼ねることとなる。

連鎖条件設定データ６３０は、適用連続性認定条件定義データ６３１と、適用関連性ＩＤ６３４と、適用緩和条件６３５と、を含む。

本実施形態では、秘密イベントの実行中か否かに係わらず、連続性認定条件は固定である。適用連続性認定条件定義データ６３１には、連続性認定条件定義データ５３０（図１２参照）がコピーされる。

なお、連続性認定条件定義データ５３０に、マルチメディアコンテンツの付帯情報や、視聴状況に応じて連続性認定時間差Δｔ（図５参照）を違えた複数の候補を用意し、そののなかから何れかを選択する構成も可能である。その場合には、選択された何れか条件データ又はその識別情報を格納することになる。

また、秘密イベントに限定した連続性認定条件定義データ５３０を用意する構成も可能である。その場合は、途切れ許容時間差条件ΔＵに相当する連続性認定時間差Δｔを設定して、秘密イベントの開始時点でこれを適用連続性認定条件定義データ６３１にコピーするとしてもよい。

適用関連性ＩＤ６３４には、秘密イベントが実行されていない状況では、複数種類ある関連性認定条件定義データ５４０（図１２参照）のうち、その時配信されているマルチメディアコンテンツや視聴状況が、適合する選択条件５４２（図１４参照）の定義データの関連性ＩＤ５４１が格納される。秘密イベントが開始されている状況では、当該イベントの秘密イベント定義データ５７０（図１７参照）から秘密条件指定関連性ＩＤ５７４がコピーされる。

適用緩和条件６３５は、実行中の秘密イベントに適用される緩和条件を指定する。具体的には、実行中の秘密イベントの秘密イベント定義データ５７０（図１７参照）に格納されている緩和条件定義データ５７６の中から、その時配信されているマルチメディアコンテンツや視聴状況が適合する適用条件５７６ａの定義データが検索され、検索された定義データの緩和条件５７６ｂがコピーされる。秘密イベントが実行中でなければ、設定無しを意味する所定値（例えば、ＮＵＬＬ）が設定される。

適用規模要件６３６は、規模要件の設定結果を格納する。本実施形態では、複数の規模要件定義データ５５０（図１５参照）の中から、選択条件５５２が適合する定義データの要件数５５３がコピーされることになる。

連鎖数６３８は、連続性の判定毎に更新され、連続性を満たしていると判定された発信の数が格納される。更新時点では、実質的には単に連続数を示していることになるが、関連性を満たしていると判定された時点で、連鎖条件を継続している回数つまりはコンボ数を表していることになる。なお、秘密イベントが実行中においては、適用緩和条件６３５が満たされる場合は、連続性が満たされた状態が継続しているものと見なされる。

コンボ発生回数６３９は、配信開始時の初期値が「０」で、発信コンボの発生が認定される毎に「１」アップされる。

実行中秘密イベントＩＤ６４０は、実行中の秘密イベントの識別情報（秘密イベントＩＤ５７１；図１７参照））が格納される。未実行中では「ＮＵＬＬ」に設定される。

適用ヒントデータセット６４１は、秘密イベントが開始されると、当該秘密イベントの秘密条件とされた関連性の関連性認定条件定義データ５４０（図１４参照）のヒントデータセット５４６の中から、その時配信されているマルチメディアコンテンツや提供ユーザについての情報、視聴状況が適合するヒント選択条件５４６ａのデータセットが検索され、それがコピーされる。

ヒント提示数６４２は、秘密イベントの開始に係り、視聴端末にて開示されているヒントの数を格納する。故に、秘密イベント開始時には「０」に設定される。そして、当該秘密イベントにおける秘密条件とされた関連性のヒントデータセット５４６（図１４参照）の第１ヒント５４６ｂの設定があれば自動的に「１」に変更される。以降、追加ヒント要求があって、且つそれに応じるだけの追加ヒントリスト５４６ｃが提供できたならば、その都度「１」加算される。

図２２は、本実施形態における視聴端末となるユーザ端末１５００（１５００ａ、１５００ｂ、…）の機能構成例を示す機能ブロック図である。視聴端末となるユーザ端末１５００は、操作入力部１００と、撮像部１０２と、端末処理部２００と、音出力部３９０と、画像表示部３９２と、通信部３９４と、端末記憶部５００とを備える。

操作入力部１００は、ユーザによって為された各種の操作入力に応じた操作入力信号を端末処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ＣＣＤモジュール、などによって実現できる。図２の方向入力キー１５０２や、ボタンスイッチ１５０４、タッチパネル１５０６がこれに該当する。

撮像部１０２は、撮影対象からの光を受光して電気信号に変換し、デジタル画像データを生成し、端末処理部２００へ出力する。例えば、レンズ、メカシャッター、シャッタードライバ、ＣＣＤイメージセンサモジュールやＣＭＯＳイメージセンサモジュールといった光電変換素子、光電変換素子から電荷量を読み出し画像データを生成するデジタルシグナルプロセッサ（ＤＳＰ）、ＩＣメモリなどで実現される。図２のイメージセンサモジュール１５２０がこれに該当する。

端末処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や端末記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、ストリーミングサーバ１１００から受信した各種データに基づいて各種の演算処理を実行して、視聴端末としてのユーザ端末１５００の動作を制御する。図２の制御基板１５５０がこれに該当する。そして、本実施形態における視聴端末の端末処理部２００は、視聴端末演算部２６０と、計時部２８０と、音生成部２９０と、通信制御部２９４と、を備える。

視聴端末演算部２６０は、操作信号送信制御部２６１と、視聴画面表示制御部２６２とを含む。

操作信号送信制御部２６１は、操作入力部１００へ為された操作に応じて、各種データやリクエストをストリーミングサーバ１１００へ送信するための処理を実行する。

視聴画面表示制御部２６２は、ストリーミングサーバ１１００から受信した各種データに基づいて視聴画面を表示するための制御を行う（図３，図７〜図９参照）。

音生成部２９０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイル再生可能なオーディオコーデック等によって実現され、視聴するマルチメディアコンテンツの音声や、視聴ユーザの発信内容の反映表示に係る効果音、ＢＧＭ、各種操作音の音信号を生成し、音出力部３９０に出力する。

音出力部３９０は、音生成部２９０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１５１０がこれに該当する。

画像表示部３９２は、視聴画面表示制御部２６２から入力される画像信号に基づいて各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図２のタッチパネル１５０６がこれに該当する。

通信制御部２９４は、データ通信に係るデータ処理を実行し、通信部３９４を介して外部装置とのデータのやりとりを実現する。通信部３９４は、通信回線９と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２の無線通信モジュール１５５３がこれに該当する。

端末記憶部５００は、端末処理部２００に、ユーザ端末１５００を視聴端末として統合的に制御するための諸機能を実現するためのプログラムや、各種データ等を記憶する。また、端末処理部２００の作業領域として用いられ、端末処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御基板１５５０が搭載するＩＣメモリ１５５２やメモリカード１５４０がこれに該当する。

視聴端末の端末記憶部５００は、視聴端末プログラム５０４と、受信済配信データ群７００と、発信用画像割り当て設定７０８と、反映表示管理データ７１０と、現在日時８００と、自機を使用する視聴ユーザのアカウントである自機ユーザアカウント８０２と、秘密イベント実行中フラグ８０４と、を記憶する。勿論、これら以外のプログラムやデータも適宜記憶することができる。

視聴端末プログラム５０４は、端末処理部２００が読み出して実行することによって視聴端末演算部２６０としての機能を実現させるためのアプリケーションソフトウェアである。本実施形態では、ストリーミングサーバ１１００から提供される配信用視聴端末プログラム５０７（図１２参照）のコピーとする。

受信済配信データ群７００は、ストリーミング配信に係りストリーミングサーバ１１００から受信した各種配信データを格納する。本実施形態では、アバター表示管理データ７０４と、保有発信用画像管理データ７０６と、が含まれる。保有発信用画像管理データ７０６は、ユーザのログイン時又は視聴ユーザの登録時に、保有発信用画像管理データ６０８（図２０参照）がコピーされる。

発信用画像割り当て設定７０８は、画像発信操作アイコン３６（図３参照）への発信用画像８の割り当てを示す。具体的には、割り当てされている発信用画像８の発信用画像種類などが格納される。

反映表示管理データ７１０は、視聴ユーザ２による発信操作の反映表示が行われる毎に作成され、その表示管理に関する各種データを格納する。１つの反映表示管理データ７１０は、発信内容データと、表示位置と、表示サイズと、表示開始日時と、表示持続時間と、を格納する。勿論、これら以外のデータも適宜含めることができる。

自機ユーザアカウント８０２は、視聴ユーザがログインする際に記憶される。
秘密イベント実行中フラグ８０４は、初期状態は「０（未実行）」とされ、ストリーミングサーバ１１００から秘密イベント開始通知や、当該イベントの第１ヒントのデータを受信すると、「１（実行中）」に変更される。そして、ストリーミングサーバ１１００から秘密イベントの終了通知を受信すると「０（未実行）」に戻される。

図２３は、本実施形態における提供端末となるユーザ端末１５００（１５００Ｔ）の機能構成例を示す機能ブロック図である。提供端末となるユーザ端末１５００は、操作入力部１００と、撮像部１０２と、端末処理部２００と、音出力部３９０と、画像表示部３９２と、通信部３９４と、端末記憶部５００とを備える。

端末処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や端末記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、ストリーミングサーバ１１００から受信した各種データに基づいて各種の演算処理を実行して、提供端末としてのユーザ端末１５００の動作を制御する。そして、本実施形態における提供端末の端末処理部２００は、提供端末演算部２７０と、計時部２８０と、音生成部２９０と、通信制御部２９４と、を備える。

提供端末演算部２７０は、操作信号送信制御部２７２と、コンテンツ提供制御部２７４と、操作画面表示制御部２７６とを含む。

操作信号送信制御部２７２は、操作入力部１００へ為された操作に応じて、各種データやリクエストをストリーミングサーバ１１００へ送信するための処理を実行する。

コンテンツ提供制御部２７４は、配信用のマルチメディアコンテンツのデータの生成と、ストリーミングサーバ１１００への提供制御に関する処理を行う。ライブ配信の場合は、撮像部１０２で撮影された画像を逐一エンコードして、ストリーミングサーバ１１００へ制御する、ライブストリーミングエンコーダとしての機能を実現する。

操作画面表示制御部２７６は、提供端末としての操作画面を表示するための制御を行う。

端末記憶部５００は、端末処理部２００に、ユーザ端末１５００を視聴端末として統合的に制御するための諸機能を実現するためのプログラムや、各種データ等を記憶する。また、端末処理部２００の作業領域として用いられ、端末処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御基板１５５０が搭載するＩＣメモリ１５５２やメモリカード１５４０がこれに該当する。

提供端末の端末記憶部５００は、提供端末プログラム５０６と、受信済配信データ群７００と、登録時配信タイトル７２０と、登録時配信スケジュール７２２と、登録時付帯情報７２４と、提供用マルチメディアコンテンツデータ７２６と、発信コンボ発生統計データ７２８と、現在日時８００と、を記憶する。勿論、これら以外のプログラムやデータも適宜記憶することができる。

提供端末プログラム５０６は、端末処理部２００が読み出して実行することによって提供端末演算部２７０としての機能を実現させるためのアプリケーションソフトウェアである。本実施形態では、ストリーミングサーバ１１００から提供される配信用提供端末プログラム５０５（図１２参照）のコピーとする。

受信済配信データ群７００は、ストリーミングサーバ１１００から受信した各種配信データを格納する。

登録時配信タイトル７２０と、登録時配信スケジュール７２２と、登録時付帯情報７２４は、それぞれ提供ユーザとして配信登録手続きをした際に申告・設定したそれぞれの情報を格納している。

提供用マルチメディアコンテンツデータ７２６は、配信用のマルチメディアコンテンツのオリジナルデータである。

発信コンボ発生統計データ７２８は、ストリーミングサーバ１１００から配信された発信コンボ発生の報知の情報の統計データである。例えば、配信開始からの発信コンボの累計回数、平均コンボ数、最大コンボ数、などである。統計内容は適宜設定可能である。
当該統計データは、マルチメディアコンテンツを提供中に表示されるモニタ画面兼操作入力画面である提供画面にて表示される。

［動作の説明］
次に、コンテンツ提供システム１０００の動作について説明する。
先ず、図２４〜図２６は、ストリーミングサーバ１１００における１つのストリーミング形式によるライブ配信に係る処理の流れについて説明するためのフローチャートである。ここで説明する処理の流れは、サーバ処理部２００ｓがサーバプログラム５０３を実行することにより実現される。なお、配信タイトルと配信スケジュールは予め提供ユーザによる配信登録手続きに伴い、既に設定されているものとする。また、視聴ユーザの視聴端末は、別途ログイン手続き済みであるものとする。

図２４に示すように、ストリーミングサーバ１１００は、先ず提供ユーザによる配信タイトルと配信スケジュールの登録時に作成された配信管理データ６２０（図２１参照）を初期化する（ステップＳ１００）。

すなわち、配信タイトル６２１、配信スケジュール６２２、付帯情報６２４は、配信登録手続きに伴い設定されている。マルチメディアコンテンツデータ６２３は、ライブ配信なので配信開始までは記憶されない。もし、ライブ配信でなければ、予め用意されたマルチメディアコンテンツのデータが格納されることになる。

背景データ６２５は、所定の背景が表示されるように初期値が設定される。視聴ユーザ管理データ６２６とアバター表示管理データ６２７は、視聴リクエストを視聴端末から受信するまで未設定である。発信実績データ６２８、連鎖条件設定データ６３０、適用規模要件６３６は、この時点では記憶されていない。連鎖数６３８とコンボ発生回数６３９は「０」に初期化される。

また、実行中秘密イベントＩＤ６４０は「ＮＵＬＬ」、適用ヒントデータセット６４１は未設定、ヒント提示数６４２は「０」に初期化される。

次に、ストリーミングサーバ１１００は、背景データ６２５、アバター表示管理データ６２７、発信実績データ６２８、などを、視聴ユーザ管理データ６２６に基づく視聴端末及び提供端末への配信を開始する（ステップＳ１０２）。配信タイミングは、所定周期としても良いし、新たな視聴ユーザの登録や、対象とされるデータが追加・削除・更新される都度に配信するとしてもよい。

また、視聴ユーザへの所定の発信用画像８の無料配付を開始する（ステップＳ１０４）。例えば、視聴時間が一定時間経過する毎に当該発信用画像を無料で付与する。これにともない、視聴ユーザの保有発信用画像管理データ６０８が更新されるので、ストリーミングサーバ１１００は、各視聴ユーザ別に、更新された保有発信用画像管理データ６０８を配信する。

次に、ストリーミングサーバ１１００は、視聴リクエストの受信有無を判定する（ステップＳ１１０）。視聴リクエストは、視聴端末として機能しているユーザ端末１５００（１５００ａ，１５００ｂ，…）にて視聴ユーザが視聴したい配信タイトルを選択した後に所定の視聴操作をすると、視聴端末からストリーミングサーバ１１００へ、ユーザアカウント等の情報とともに送信される。

そして、ストリーミングサーバ１１００は、視聴リクエストを受信すると（ステップＳ１１０のＹＥＳ）、新たに視聴ユーザ管理データ６２６（図２１参照）を作成して、視聴リクエストしたユーザを視聴ユーザとして登録し、新たなアバター表示管理データ６２７を作成して、当該ユーザのアバター４が視聴画面で表示されるようにする（ステップＳ１１２）。そして、新たなアバターが追加されたので、視聴画面の発信内容表示部３５（図３参照）にて、視聴ユーザのアバター同士が重なり合わないように、できるだけ分散するように全アバターの配置位置を更新する（ステップＳ１１４）。

前述のようにステップＳ１０２にてアバター表示管理データ６２７の配信は開始されているので、配置位置が更新されたアバター表示管理データ６２７もまた視聴端末に配信される。視聴端末では、配信されたアバター表示管理データ６２７に基づいて、各アバター４の表示位置を変更することになる。視聴画面では、新たな仮想視聴者がスクリーンの前に出現したかのように見える。

これにより、ストリーミング配信を皆で一緒に視聴する仮想体験がよりリッチなものになり、視聴者の一体感が醸し出される。そして、視聴者の一体感が、みんなで視聴環境を盛り上げようという想いとなり、それが視聴ユーザによる積極的な発信を促し、ついには本実施形態のストリーミング配信サービスが従来の配信サービス以上に楽しい充実したユーザ体験をもたらす要因の１つとなる。

次に、ストリーミングサーバ１１００は、テキスト発信リクエストの有無を判定する（ステップＳ１２０）。テキスト発信リクエストは、視聴端末のユーザ端末１５００（１５００ａ，１５００ｂ，…）にて視聴ユーザがテキスト発信操作部３４（図３参照）にて、テキスト入力して所定の発信操作を行うと、ストリーミングサーバ１１００へ、ユーザアカウントと、入力されたテキストなどとともに送信される。

ストリーミングサーバ１１００は、テキスト発信リクエストを受信すると（ステップＳ１２０のＹＥＳ）、受信した新たなテキスト発信についての発信実績データ６２８（図２１参照）を追加作成する（ステップＳ１２２）。

前述のようにステップＳ１０２にて発信実績データ６２８の配信は開始されているので、新たなテキスト発信の情報もまた視聴端末に配信される。視聴端末では、追加配信された発信実績データ６２８に基づいて、テキスト発信した視聴ユーザのアバター４の吹き出し５にて発信内容が表示され、あたかも当該アバターが話したかのように見える。これもまた、ストリーミング配信を皆で一緒に視聴する仮想体験をよりリッチなものにしてくれる。

次に、ストリーミングサーバ１１００は、発信用画像の購入リクエストの有無を判定する（ステップＳ１２４）。購入リクエストは、視聴端末にて視聴ユーザが所定の購入操作（例えば、図３のショッピングアイコン３７への操作）を行うと、ストリーミングサーバ１１００へ送信される。

ストリーミングサーバ１１００は、購入リクエストを受信すると（ステップＳ１２４のＹＥＳ）、発信用画像８のオンラインショッピングに係る処理を実行する（ステップＳ１２６）。この購入に伴って、購入リクエストした視聴ユーザのユーザ管理データ６００（図２０参照）の保有発信用画像管理データ６０８の新たな追加又は更新が行われる。また、購入する視聴ユーザの視聴端末で記憶されている保有発信用画像管理データ７０６（図２２参照）も同様に更新される。

このように、ライブ配信前であっても、視聴ユーザは、テキスト発信したり、発信用画像８の購入が可能となり、ライブが始まる前に視聴ユーザ間で思い思いにライブへの期待を語りあったり、ライブ開始に備えた画像発信の準備ができる。

ライブ配信の開始予定時刻に達すると（ステップＳ１２８のＹＥＳ）、ストリーミングサーバ１１００はマルチメディアコンテンツのライブ配信を開始する（ステップＳ１３０）。

図２５に移って、マルチメディアコンテンツの配信を開始した後は、ストリーミングサーバ１１００は、秘密イベントを開始するべき条件が整ったかを監視している。すなわち、秘密イベント定義データ５７０（図１７参照）を参照して、イベント開始条件５７２が満たされた秘密イベントを検索する。そして、ストリーミングサーバ１１００は、秘密イベントが実行されていない状態で、且つ、イベント開始条件５７２が満たされている秘密イベントがあれば（ステップＳ１３２のＹＥＳ）、秘密イベントの開始処理を実行する（ステップＳ１３４）。

秘密イベントの開始処理として、具体的には、次の処理を行う。
１）ストリーミングサーバ１１００は、配信管理データ６２０（図２１参照）の実行中秘密イベントＩＤ６４０を、ステップＳ１３２で条件を満たしたと判定された秘密イベントの秘密イベントＩＤ５７１（図１７参照）に設定。
２）ヒント提示数６４２を「０」に設定。
３）適用関連性ＩＤ６３４に、当該秘密イベントの秘密条件指定関連性ＩＤ５７４（図１７参照）を設定。
４）当該ＩＤの関連性認定条件定義データ５４０のヒントデータセット５４６（図１４参照）の中から、ヒント選択条件５４６ａが適合する定義データを検索し、該当するデータセットを、適用ヒントデータセット６４１にコピー。
５）当該秘密イベントの緩和条件定義データ５７６（図１７参照）のうち、適用条件５７６ａが満たされている定義データを検索して、その緩和条件定義データ５７６（図１７参照）を適用緩和条件６３５にコピー。
６）所定の秘密イベント開始通知信号と、適用ヒントデータセット６４１のうちの何れかの第１ヒント（第１ヒント５４６ｂのコピー）とを視聴端末及び提供端末へ配信。
７）第１ヒントを配信下場合は、ヒント提示数６４２を「１」に変更。

また、マルチメディアコンテンツの配信開始以降、ストリーミングサーバ１１００は、実行中の秘密イベントの終了条件が満たされたかを監視している。そして、実行中秘密イベントＩＤ６４０が示す実行中の秘密イベントのイベント終了条件５７３（図１７参照）が満たされている場合（ステップＳ１３６のＹＥＳ）、秘密イベントの終了処理を実行する（ステップＳ１３８）。当該終了処理として、具体的には、所定の秘密イベント終了通知信号を、視聴端末及び提供端末へ配信する。

また、マルチメディアコンテンツの配信開始以降、ストリーミングサーバ１１００は購入リクエストの受信を監視する。そして、当該リクエストを受信すると（ステップＳ１４０のＹＥＳ）、発信用画像８の購入処理を実行する（ステップＳ１４２）。

また、マルチメディアコンテンツの配信開始以降、ストリーミングサーバ１１００はテキスト発信リクエストの受信を監視する。そして、当該リクエストを受信すると（ステップＳ１４４のＹＥＳ）、新たな発信実績データ６２８（図２１参照）とリクエストした視聴ユーザの発信ログデータ６１０（図２０参照）を作成して更新する（ステップＳ１４６）。

また、マルチメディアコンテンツの配信開始以降、ストリーミングサーバ１１００は、画像発信のリクエストの受信を監視する（ステップＳ１５０）。
画像発信リクエストは、視聴端末にて視聴ユーザが所定の画像発信操作（例えば、図３の画像発信操作アイコン３６へのタッチ操作）を行うと、ユーザアカウントと、発信タイミングと、発信内容としての発信用画像８の識別情報又は画像データそのものとが、ストリーミングサーバ１１００へ送信される。

ストリーミングサーバ１１００は、画像発信リクエストを受信すると（ステップＳ１５０のＹＥＳ）、当該リクエストをした視聴ユーザの保有発信用画像管理データ６０８（図２０参照）を参照して、発信内容とされる発信用画像８の残数があるのを確認する（ステップＳ１５２）。そして、残数が有れば（ステップＳ１５２のＹＥＳ）、ストリーミングサーバ１１００は当該発信用画像を１つ消費して、その残数を返信し（ステップＳ１５４）、新たな発信実績データ６２８（図２１参照）と、リクエストした視聴ユーザの発信ログデータ６１０（図２０参照）を追加作成し更新する（ステップＳ１５６）。

前述のようにステップＳ１０２にて発信実績データ６２８の配信は開始されているので、新たな画像発信の情報もまた視聴端末に配信される。視聴端末では、追加配信された発信実績データ６２８に基づいて、画像発信した視聴ユーザのアバター４から、発信内容の発信用画像８が飛び出るように出現表示される。これは、あたかも当該アバターが舞台に花束を投げ込む行為のように見え、ストリーミング配信を皆で一緒に視聴する仮想体験をよりリッチなものにしてくれる。

図２６に移って、次に、秘密イベントが実行中でなければ（ステップＳ１６０のＹＥＳ）、ストリーミングサーバ１１００は、発信コンボ発生判定処理を実行する（ステップＳ１６２）。

図２７は、発信コンボ発生判定処理の流れを説明するためのフローチャートである。
同処理において、ストリーミングサーバ１１００は、先ず、連続性認定条件を満たす複数の発信実績データの有無を判定する（ステップＳ１６４）。
具体的には、発信実績データ６２８（図２１参照）の中から、発信タイミングが新しい方から順に辿って、１）発信タイミングが前後する他の発信実績データ６２８と発信者を示すユーザアカウントが異なっていて、且つ、２）発信タイミングが１つ前の発信実績データ６２８との発信タイミングの時間差が、連続性認定条件定義データ５３０（図１０参照）の連続性認定時間差Δｔ以下である、発信実績データ６２８を抽出する。抽出される発信実績データ６２８が複数であれば、「連続性のある複数の発信有り」として肯定判定する。

そして、「連続性を有する複数の発信有り」の場合（ステップＳ１６４のＹＥＳ）、ストリーミングサーバ１１００は、それらの数をカウントして連鎖数６３８（図２１参照）に設定し（ステップＳ１６６）、複数の関連性認定条件定義データ５４０の中から選択条件５４２（図１４参照）が適合する定義データを検索し、今回適用する関連性認定条件を設定する（ステップＳ１６８）。つまり、今回の発信コンボの認定に適用する連鎖条件を設定する。検索結果は、連鎖条件設定データ６３０（図２１参照）の適用関連性ＩＤ６３４に格納される。

次に、ストリーミングサーバ１１００は、連続性を有する複数の発信の内容が、適用する関連性認定条件を満たしているかを判定する。そして、肯定判定の場合、つまりは連鎖条件を満たしている場合（ステップＳ１７０のＹＥＳ）、ストリーミングサーバ１１００は、複数の規模要件定義データ５５０の中から、選択条件５５２（図１５参照）が適合する定義データを検索して、今回適用する規模要件を設定する（ステップＳ１７２）。これに伴い、検索された規模要件定義データ５５０の要件数５５３が、適用規模要件６３６（図２１参照）に設定される。

そして、先に連鎖条件を満たすと判定された複数の発信が、適用規模要件６３６を示す規模要件を満たしているか判定する（ステップＳ１７４）。具体的には、連鎖条件を満たすと判定された複数の発信数を示している連鎖数６３８（図２１参照）が適用規模要件６３６に達していれば、規模要件を満たしていると判定する。

これで、連鎖条件を満たし且つ規模要件を満たしたことになるので、ストリーミングサーバ１１００は、「発信コンボが発生した」と認定して（ステップＳ１７４のＹＥＳ）、コンボ発生回数６３９（図２１参照）を「１」加算して、視聴端末にて発信コンボの発生を報知させる為の報知素材データ等の配信を行う（ステップＳ１７６）。

具体的には、複数のコンボ発生報知定義データ５８０（図１８参照）の中から、適用関連性ＩＤリスト５８１に、適用関連性ＩＤ６３４（図２１参照）に設定されている関連性ＩＤが含まれている定義データを選択する。そして、その標準報知素材データ５８３とともに連鎖数６３８などの関連情報を、視聴端末及び提供端末へ配信する。視聴端末ではこれを受信して、視聴画面の汎用表示部３３等においてコンボ発生通知８０や演出表示８４を表示させる。

次いで、ストリーミングサーバ１１００は、発信コンボの発生が認定された状況に応じた特典制御を実行する（ステップＳ１７８）。
具体的には、複数の特典定義データ５６０（図１６参照）の中から、適用関連性ＩＤリスト５６２に適用関連性ＩＤ６３４（図２１参照）に設定されている関連性ＩＤが含まれている定義データを選択し、当該定義データの標準特典実行データ５６４に基づいて特典制御を開始する。

次いで、ストリーミングサーバ１１００は、視聴端末にて特典実行の報知を行わせる為の標準特典実行通知素材５６３の配信を行う（ステップＳ１８０）。
具体的には、先に選択した特典定義データ５６０の標準特典実行通知素材５６３（図１６参照）を視聴端末及び提供端末に配信する。視聴端末ではこれを受信して、視聴画面の汎用表示部３３等において特典実行通知８２を表示させる。

次に、ストリーミングサーバ１１００は、活況指標値を提供ユーザへ付与する（ステップＳ１８２）。例えば、連鎖数６３８やコンボ発生回数６３９、視聴者数などを変数とする秘密イベント未実行中に適用される所定の算出関数又はテーブルデータを用意しておいて、それらのパラメータの値が大きいほど、より活況指標値が算出する。そして、算出された活況指標値を、提供ユーザに付与する。これにより、提供ユーザの該当する累積活況指標値５９３（図１９参照）が更新される。
そして、ストリーミングサーバ１１００は、発信コンボ判定処理を終了する。

図２６に戻って、秘密イベントが実行中の場合は（ステップＳ１６０のＹＥＳ）、ストリーミングサーバ１１００は、実行中の秘密イベントがクリアされたかを判定する秘密イベントクリア判定処理を実行する（ステップＳ１８０）。

図２８は、秘密イベントクリア判定処理の流れを説明するためのフローチャートである。
同処理において、ストリーミングサーバ１１００は、発信実績データ６２８（図２１参照）の中から、秘密イベントのクリア判定の対象とされる発信を抽出する（ステップＳ１９２）。

具体的には、発信実績データ６２８のなかから、発信タイミングの順に過去へ辿って、所定数の発信を抽出する。ここで言う、所定数は、緩和条件を適用した場合に相当する値とする。
より具体的には、例えば、連鎖数１０（１０コンボ）以上ならば全て特典制御の内容が一緒になる構成で、緩和条件を「阻害発信の許容数」で定義し、その許容数を「３」とするならば、所定数＝１０＋３となる。緩和条件を「阻害発信の許容割合」で定義し、その許容割合が５０％とするならば、所定数＝１０／０．５となる。緩和条件を「途切れ許容時間差条件ΔＵ」で定義する場合は、発信実績データ６２８のうち最新の発信タイミングから過去「１０×ΔＵ」以内に発信された任意の数となる。

なお、本実施形態では、判定対象とする発信の抽出には、適用連続性認定条件定義データ６３１の適用を除外して、よりクリアし易い様にしている。しかし、適用連続性認定条件定義データ６３１を適用して判定対象を選択することも可能である。

次に、ストリーミングサーバ１１００は、適用規模要件６３６を決定し（ステップＳ１９４）、更に判定対象として抽出した発信の発信内容から、適用関連性ＩＤ６３４が示す関連性認定条件定義データ５４０（図１４参照）の関連性認定条件５４４を満たしている発信内容を抽出する（ステップＳ１９６）。

そして、その数が適用規模要件６３６の示す値に達していなければ（ステップＳ１９８のＮＯ）、未クリアと判定し（ステップＳ２００）、秘密イベントクリア判定処理を抜ける。

対して、関連性認定条件５４４を満たしていている発信内容の数が適用規模要件６３６の示す値に達していれば（ステップＳ１８８のＹＥＳ）、今回の秘密イベントはクリアされたと判定し（ステップＳ２０２）、ストリーミングサーバ１１００は、所定の秘密イベントクリア通知とともに、適用関連性ＩＤ６３４が適用関連性ＩＤリスト５８１に含まれるコンボ発生報知定義データ５８０（図１８参照）を検索して、その秘密イベント用報知素材データ５８４を視聴端末及び提供端末へ配信する（ステップＳ２０４）。

次いで、ストリーミングサーバ１１００は、秘密イベント用の特典制御を開始する（ステップＳ２０６）。具体的には、適用関連性ＩＤ６３４が適用関連性ＩＤリスト５６２に含まれる特典定義データ５６０（図１６参照）の秘密イベント用特典実行データ５６６を参照して、特典制御を開始する。

そして、ストリーミングサーバ１１００は、同じ特典定義データ５６０の秘密イベント用特典実行通知素材５６５を、視聴端末及び提供端末へ配信し（ステップＳ２０８）、秘密イベントの終了処理を実行する（ステップＳ２１０）。

次いで、ストリーミングサーバ１１００は、活況指標値を提供ユーザへ付与する（ステップＳ２１２）。例えば、連鎖数６３８やコンボ発生回数６３９、視聴者数などを変数とする秘密イベント実行中に適用される所定の算出関数又はテーブルデータを用意しておいて、それらのパラメータの値が大きいほど、より活況指標値が算出する。そして、算出された活況指標値を、提供ユーザに付与する。

そして、活況指標値を付与したならば、ストリーミングサーバ１１００は、秘密イベントクリア判定処理を抜ける。

図２６に戻って、秘密イベントが実行されている間、ストリーミングサーバ１１００は、追加ヒントの要求を監視している。ストリーミングサーバ１１００は、視聴端末から追加ヒントリクエストが受信されると（ステップＳ２２０のＹＥＳ）、ヒント対価の支払処理を実行して（ステップＳ２２２）、未開示の追加ヒントを全視聴端末及び提供端末へ配信する（ステップＳ２２４）。

具体的には、適用ヒントデータセット６４１（図２１参照：内容は図１４のヒントデータセット５４６に同じ）の対価支払者５４６ｅの設定に従って、追加ヒントリクエストした視聴端末の視聴ユーザ又は、配信されているマルチメディアコンテンツの提供ユーザから対価を徴収する。そして、追加ヒントリスト５４６ｃから、ヒント提示数６４２の示す順番の追加ヒントを、未開示の追加ヒントとして配信し、ヒント提示数６４２を「１」加算する。なお、追加ヒントリスト５４６ｃには、１つも追加ヒントが設定されていない場合もあり得る。その場は、追加ヒントが無い旨の通知を、追加ヒントリクエストした視聴端末へ返信するものとする。

ストリーミングサーバ１１００は、マルチメディアコンテンツの配信が終了するまで（ステップＳ２３０のＮＯ）、ステップＳ１３２からステップＳ２２４を繰り返す。
そして、配信が終了すると（ステップＳ２３０のＹＥＳ）、ストリーミングサーバ１１００は、今回のストリーミング配信の総括として活況指標値を提供ユーザに付与し、付与された活況指標値の通知を視聴端末へ配信する（ステップＳ２３２）。具体的には、総括としての活況指標値は、視聴ユーザ数（延べ人数でも良い）、全視聴ユーザによる視聴時間の合計、平均視聴時間、テキスト発信や画像発信の累計数、などを変数とし、それらが大きいほどより高値となるような関数やテーブルデータを用意して決定する。

次いで、ストリーミングサーバ１１００は、累積活況指標値５９３（図１９参照）に基づく配信タイトルのランキングを更新し、ランキング情報を配信して（ステップＳ２３４）、一連の処理を終了する。

図２９〜図３１は、本実施形態における視聴端末となるユーザ端末１５００（１５００ａ，１５００ｂ，…）におけるマルチメディアコンテンツの視聴に係る処理の流れを説明するためのフローチャートである。なお、視聴端末となるユーザ端末１５００では、視聴端末プログラム５０４が実行状態にあるものとする。

図２９に示すように、視聴端末では、先ずログイン処理を実行する（ステップＳ３００）。そして、マルチメディアコンテンツの配信を視聴するための所定の視聴操作（視聴するコンテンツの選択を含む）を検出すると（ステップＳ３１０のＹＥＳ）、ストリーミングサーバ１１００へ視聴リクエストを送信する（ステップＳ３１２：通信Ａ）。

視聴リクエストがストリーミングサーバ１１００にて受信されると、視聴ユーザ登録が行われ、当該視聴端末へ、アバター表示管理データ６２７や、発信実績データ６２８などの配信が開始される（配信α）。
視聴端末は、これらを受信して受信済配信データ群７００（図２２参照）に格納して、視聴画面Ｗ３（図３参照）の表示を開始する（ステップＳ３１４）。視聴画面が表示されると、マルチメディアコンテンツの配信が始まれば自動的にコンテンツ表示部３２にて当該マルチメディアコンテンツの映像が表示される。また、他の視聴ユーザが発信したテキストの吹き出し５や発信用画像８が発信内容表示部３５にて逐一表示されるようになる。

視聴端末は、視聴画面の表示開始以降、イベントの開始／終了の通知を監視している。
視聴端末は、ストリーミングサーバ１１００から秘密イベントの開始通知（通信Ｍ）や終了通知（通信Ｎ）の受信に応じて、秘密イベントの開始／終了の通知を視聴画面に表示させる（ステップＳ３１６）。これに伴い、秘密イベント実行中フラグ８０４が「０（未実行）」「１（実行中）」に切り換られる。

また、視聴端末は、発信用画像８の購入操作を検出すると（ステップＳ３２０のＹＥＳ）、ストリーミングサーバ１１００へ購入リクエストを送信し（ステップＳ３２２；通信Ｂ）、購入手続き処理を実行する（ステップＳ３２４）。当該手続き処理にともなって、当該視聴端末で記憶されている保有発信用画像管理データ７０６（図２２参照）が更新される。

また、視聴端末は、テキスト発信操作部３４（図３参照）にてテキスト入力操作を検出すると（ステップＳ３３０のＹＥＳ）、テキストの入力編集処理を実行する（ステップＳ３２３）。そして、テキスト発信操作が検出されたならば（ステップＳ３３４のＹＥＳ）、入力されたテキストを含むテキスト発信リクエストをストリーミングサーバ１１００へ送信する（ステップＳ３３６；通信Ｃ）。

ストリーミングサーバ１１００は、当該リクエストを受信すると発信実績データ６２８（図２１参照）を更新して配信する。視聴端末は、前述のようにステップＳ３１４にて各種配信データに基づく視聴画面の表示制御を開始しているので、視聴ユーザの発信したテキストが視聴画面内に表示されることとなる。

図３０に移って、視聴端末は、画像発信操作アイコン３６（図３参照）への発信用画像の割り当て変更操作を検出すると（ステップＳ３４０のＹＥＳ）、ポップアップ表示Ｗ４（図４参照）の表示制御を含む割り当て変更処理を実行して、発信用画像割り当て設定７０８（図２２参照）を変更する（ステップＳ３４２）。

視聴端末は、画像発信操作を検出すると（ステップＳ３５０のＹＥＳ）、画像発信リクエストをストリーミングサーバ１１００へ発信し（ステップＳ３５２；通信Ｄ）、発信内容の発信用画像８の残数を「１」減らすように、保有発信用画像管理データ７０６（図２２参照）を更新する（ステップＳ３５４）。

ストリーミングサーバ１１００は、画像発信リクエストを受信すると発信実績データ６２８（図２１参照）を更新して配信する（配信α）。
視聴端末は、ストリーミングサーバ１１００から新たに配信された発信実績データ６２８を受信すると（ステップＳ３６０のＹＥＳ）、新たな反映表示管理データ７１０を作成し、新たな反映表示の表示開始日時と、表示持続時間を設定する（ステップＳ３６２）。

そして、新たに発信されたテキストや発信用画像８の反映表示制御をする（ステップＳ３６４；図３参照）。
その際、秘密イベントが実行されていない場合には、当該新たな発信の反映表示を、その発信内容が分かるような明示形態で表示する。すなわち、新たに発信されたテキストを発信者のアバター４から吹き出し５で表示させたり、新たに発信された発信用画像８を発信者のアバター４から出現するように反映表示制御する（視聴画面Ｗ３；図３参照）。

対して、秘密イベントが実行されている場合には、その発信内容が分からないように非明示形態で表示する。すなわち、発信者別の目隠し７で発信内容を覆う又は置換して表示することで非明示に表示する（視聴画面Ｗ８；図８参照）。

なお、視聴端末は、表示持続時間を超過した反映表示は逐一消去する（ステップＳ３６６）。すなわち、反映表示管理データ７１０（図２２参照）のうち、表示開始時間から表示持続時間を超過した反映表示（発信されたテキスト、発信された発信用画像）を消去する。

視聴端末は、ストリーミングサーバ１１００から配信された発信コンボの発生を報知するための報知素材データ等を受信すると（ステップＳ３７０のＹＥＳ）、
当該素材データに基づいてコンボ発生通知８０と演出表示８４とを視聴画面に表示させる（ステップＳ３７２；図３参照）。

また、視聴端末は、ストリーミングサーバ１１００から秘密イベントクリア通知及び秘密イベント用報知素材データ５８４（通信Ｑ）を受信すると（ステップＳ３７４のＹＥＳ）、視聴画面にイベントクリア通知８６を表示させ（視聴画面Ｗ９；図９参照）、非明示形態で表示されていた反映表示を明示形態に変更する（ステップＳ３７６）。すなわち、本実施形態で言う所の目隠し７により隠されていた本来のテキストの吹き出し５（５ａ，５ｂ，…）や発信用画像８（８ａ，８ｂ，…）を明らかにする。

図３１に移って、視聴端末は、ストリーミングサーバ１１００から配信された特典実行通知素材データを受信すると（ステップＳ３８０のＹＥＳ）、当該データに基づいて特典実行通知８２を視聴画面に表示させる（ステップＳ３８２；図３、図９参照）。

視聴端末は、追加ヒント要求操作アイコン３８（図８参照）への操作を検出すると（ステップＳ３９０のＹＥＳ）、所定の追加ヒントリクエストと自機ユーザアカウント８０２と、をストリーミングサーバ１１００へ送信する（ステップＳ３９２；通信Ｌ）。

ストリーミングサーバ１１００は、当該リクエストを受信すると、追加ヒントを配信する（通信Ｐ）。
視聴端末は、配信された追加ヒントを受信すると（ステップＳ３９４）、これを追加ヒント表示７４（図９参照）として視聴画面Ｗ８にて表示する（ステップＳ３９６）。

配信が終了するまでは（ステップＳ４００のＮＯ）、視聴端末ではステップＳ３２０〜Ｓ３８４が繰り返される。
配信が終了すると（ステップＳ４００のＹＥＳ）、視聴端末は、ストリーミングサーバ１１００から配信された活況指標値の付与実績とランキング情報とを表示して（ステップＳ４０２）、一連の処理を終了する。

図３２は、本実施形態における提供端末となるユーザ端末１５００（１５００Ｔ）における処理の流れを説明するためのフローチャートである。なお、提供端末のユーザ端末１５００では、提供端末プログラム５０６（図２３参照）が実行されているものとする。また、マルチメディアコンテンツをゲームプレイ動画のライブ中継コンテンツとする場合には、別途、ゲームプログラムが実行されているものとする。

提供端末は、先ずログイン処理を実行し、提供画面の表示制御を開始する（ステップＳ５００）。提供画面は、マルチメディアコンテンツのライブ配信のための各種操作を受け付ける操作画面であり、且つ、配信状況をモニタするモニタ画面を兼ねている。

次に、提供端末は、配信タイトルと、配信スケジュール、付帯情報の設定・登録手続き処理を行う（ステップＳ５０２）。そして、配信予定時刻になるとマルチメディアコンテンツの提供を開始する（ステップＳ５０４）。本実施形態では、ライブ配信を想定しているので、例えば、実写によるライブ配信の場合は、提供端末は、自機のイメージセンサモジュール１５２０で撮影した映像にマイク１５１２で集音した音声を付加したマルチメディアコンテンツデータを逐次作成するとともに、そのライブストリーミングエンコードを行ってストリーミングサーバ１１００へ送信する。マルチメディアコンテンツが予め用意された動画データなどの場合には、配信予定時刻を待たずに、配信タイトル等の登録手続きとともに、ストリーミングサーバ１１００へアップロードする。ゲームプレイの画面をライブ配信する場合は、ゲーム画面をキャプチャした動画にゲーム音声を付加してマルチメディアコンテンツデータを逐次作成する。

コンテンツの提供を開始した後、ストリーミングサーバ１１００から発信コンボの発生の報知を受信すると（ステップＳ５１０のＹＥＳ）、提供端末は、報知表示するとともに（ステップＳ５１２）、発信コンボ発生統計データ７２８（図２３参照）を更新して、最新の統計の表示を更新する（ステップＳ５１４）。

つまり、提供端末にて、発信コンボの最新の発生をモニタできるとともに、配信開始からの発信コンボの発生の統計を逐一確認できるようになるので、提供ユーザはストリーミング配信の活況具合を確認しながらのライブ配信ができる。例えば、それを元にアドリブを追加するなどの内容のアップデートが可能となるので、マルチメディアコンテンツの品質向上、視聴ユーザのユーザ体験の向上する可能性が高くなる。また、ライブ配信であれば、発信コンボの発生の御礼を視聴ユーザ向けにアドリブで追加すれば、視聴ユーザとの一体感をより醸成するのに寄与するであろう。それはまた、更なる発信コンボを誘発し、ユーザ体験の向上をもたらすこととなる。

また、ストリーミングサーバ１１００から標準特典実行通知素材５６３を受信すると（ステップＳ５２０）、提供端末は、提供画面に特典実行の報知をログ表示する（ステップＳ５２２）。

そして、マルチメディアコンテンツの配信を終了すると（ステップＳ５２４のＹＥＳ）、一連の処理を終了する。

以上、本実施形態によれば、配信されたマルチメディアコンテンツを視聴している視聴ユーザ同士のユーザ端末には、自身の発信内容は視聴画面中で見えるが（明示形態）、他者の発信内容は視聴画面中では分からない非明示形態で表示される。そして、視聴ユーザ同士の発信内容が秘密の関連性を満たすと、非明示形態であった他者の発信内容が明示形態とされて、特典を獲得することができる。よって、テキストや画像の発信機能を利用した新たな付加価値を創出し、ユーザ体験をより豊かにすることができる。

また、ユーザテキストや画像の発信機能を利用して、マルチメディアコンテンツのストリーミング配信サービスにて、発信コンボと、秘密イベントという新たな付加価値を創出できる。よって、複数の視聴ユーザが皆で集まって１つのマルチメディアコンテンツを視聴するという仮想ユーザ体験がより豊かになり、ストリーミング配信のサービスを向上できる。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明を適用可能な形態は上記形態に限定されるものではなく適宜構成要素の追加・省略・変更を施すことができる。

［その１］
例えば、上記実施形態では、クライアント・サーバ型のコンピュータシステムにてストリーミング配信サービスを実現する例を挙げたが、複数のユーザ端末１５００同士をピアツーピア接続したコンピュータシステムにおいて実現するとしてもよい。その場合、何れかのユーザ端末１５００にストリーミングサーバ１１００としての機能を担わせる。或いは、複数のユーザ端末１５００で配信サービス管理部２１０が有する機能を分担して担う構成としてもよい。

［その２］
また、上記実施形態は、複数のユーザが同時にアクセスしていて、それぞれがテキストや画像の発信操作が可能なサービスであればその他のサービスにも適用可能である。

例えば、図３の視聴画面Ｗ３のうち、コンテンツ表示部３２より下の画面部分を、ソーシャルネットワーキングサービスのチャット機能を適用した画面とすることもできる。図３３は、その場合の表示例を示す図である。

視聴画面Ｗ３３に、チャット機能を適用した画面であるチャット画面Ｗ２９を含める。
チャット画面Ｗ２９の左側には、当該画面が表示されるユーザ端末１５００を使用するユーザのアバター４ａが表示され、当該ユーザが発信操作したテキストが吹き出し５で反映表示され、当該ユーザが発信操作した発信用画像８が反映表示される。
チャット画面Ｗ２９の右側には、他ユーザのアバター４ｂ、４ｃ、…が表示されるともに、彼等が発信操作したテキストの吹き出し５や発信用画像８が表示される。

チャット画面Ｗ２９の背景は、特典制御として特別な背景データが付与される場合には、アクセスしている全ユーザのユーザ端末１５００にて同じ特別な背景へ表示が切り換えられる。また、アバター４や吹き出し５、発信用画像８が表示される表示レイヤーと、背景レイヤーとの間の中間レイヤーにて、コンボ発生通知８０や特典実行通知８２などの各種通知、演出表示８４などが表示される。特典制御として、特別な演出表示８４ｓを表示する場合にもこの中間レイヤーを使用することができる。

また、秘密イベントに関しては、上記実施形態では秘密イベントは自動且つ無料で実行されたが、秘密イベントの実行を有料としてもよい。その場合、秘密イベント定義データ５７０（図１７参照）に別途、実行対価についての情報と、当該実行対価を誰に支払わせるかを指定する対価支払者指定情報とを追加しておく。そして、ステップＳ１３２とステップＳ１３４（図２５参照）との間で、対価支払指定者のユーザ端末１５００での実行対価についての説明通知と承認要求とを行うステップを追加する。そして、承認要求された場合に、実行対価の徴収を行うステップを追加すれば良い。

４…アバター
５…吹き出し
８…発信用画像
３２…コンテンツ表示部
３４…テキスト発信操作部
３５…発信内容表示部
３６…画像発信操作アイコン
３８…追加ヒント要求操作アイコン
７０…秘密イベント発生通知
７２…ヒント表示
７４…追加ヒント表示
８６…イベントクリア通知
８８…秘密イベント用特典通知
２００ｓ…サーバ処理部
２１０…配信サービス管理部
２１６…連鎖条件設定部
２１８…規模要件設定部
２２０…秘密イベント制御部
２２１…イベント開始終了制御部
２２２…秘密条件設定部
２２３…緩和条件設定部
２２４…第１表示制御部
２２５…イベントクリア判定部
２２６…第２表示制御部
２２７…ヒント表示制御部
２３０…特典制御実行部
２３２…活況指標値算出部
２３４…ランキング管理部
５００ｓ…サーバ記憶部
５０３…サーバプログラム
５０５…配信用提供端末プログラム
５０７…配信用視聴端末プログラム
５１０…配信サービス初期設定データ
５２０…発信用画像定義データ
５３０…連続性認定条件定義データ
５４０…関連性認定条件定義データ
５４２…選択条件
５４４…関連性認定条件
５４６…ヒントデータセット
５５０…規模要件定義データ
５６０…特典定義データ
５７０…秘密イベント定義データ
５７２…イベント開始条件
５７３…イベント終了条件
５７４…秘密条件指定関連ＩＤ
５７５…緩和条件定義データ
５８０…コンボ発生報知定義データ
５９０…提供ユーザ登録データ
５９３…累積活況指標値
５９９…ランキングデータ
６００…ユーザ管理データ
６０４…目隠しデータ
６０８…保有発信用画像管理データ
６２０…配信管理データ
６２３…マルチメディアコンテンツデータ
６２４…付帯情報
６２６…視聴ユーザ管理データ
６２８…発信実績データ
６３０…連鎖条件設定データ
６３１…適用連続性認定条件定義データ
６３４…適用関連性ＩＤ
６３５…適用緩和条件
６３６…適用規模要件
６４０…実行中秘密イベントＩＤ
６４１…適用ヒントデータセット
６４２…ヒント提示数
１０００…コンテンツ提供システム
１１００…ストリーミングサーバ
１５００…ユーザ端末

Claims (15)

1. 提供ユーザにより提供された少なくとも映像を含むコンテンツを、各視聴ユーザのユーザ端末に配信するコンテンツ配信システムであって、
   前記ユーザ端末では、前記コンテンツを表示するコンテンツ表示部と、視聴中の前記コンテンツに対する各視聴ユーザの発信内容を表示する発信内容表示部とを含む視聴画面が表示され、
   前記発信内容の表示形態を前記ユーザ端末別に制御する手段であって、当該ユーザ端末の視聴ユーザが発信した発信内容（以下「自身発信内容」という）を明示形態、当該ユーザ端末の視聴ユーザ以外が発信した発信内容（以下「他者発信内容」という）を非明示形態として前記視聴画面中に表示させる制御を行う第１の表示制御手段と、
   複数の視聴ユーザによる複数の発信内容が、少なくとも所与の関連性認定条件を含む秘密条件を満たすか否かを判定する判定手段と、
   前記判定手段により肯定判定された発信内容であって、前記第１の表示制御手段により非明示形態とされた発信内容を、明示形態に変更して表示させる制御を行う第２の表示制御手段と、
   前記判定手段により肯定判定された場合に特典制御を実行する特典制御手段と、
   を備えたコンテンツ配信システム。
2. 前記秘密条件は、発信時間間隔に関する時間差条件を更に含む、
   請求項１に記載のコンテンツ配信システム。
3. 前記判定手段は、前記秘密条件を満たすか否かの判定対象とする発信内容を発信順に選択し、且つ、同一の視聴ユーザによる発信を連続して選択しないように選択する、
   請求項１又は２に記載のコンテンツ配信システム。
4. 前記特典制御は、前記視聴ユーザ及び／又は前記提供ユーザに所与の特典を付与する制御である、
   請求項１〜３の何れか一項に記載のコンテンツ配信システム。
5. 前記第１の表示制御手段、前記判定手段、前記第２の表示制御手段および前記特典制御手段を、所与の開始条件を満たした場合に機能開始させ、所与の終了条件を満たした場合に機能終了させる秘密イベント制御手段、
   を備えた請求項１〜４の何れか一項に記載のコンテンツ配信システム。
6. 前記秘密イベント制御手段は、前記第１の表示制御手段、前記判定手段、前記第２の表示制御手段および前記特典制御手段を、所与の期間の間、機能させるように制御する、
   請求項５に記載のコンテンツ配信システム。
7. 前記秘密イベント制御手段は、前記終了条件として設定された発信内容の発信があった場合に、前記終了条件を満たすとして機能終了させる、
   請求項５又は６に記載のコンテンツ配信システム。
8. 前記秘密イベント制御手段は、前記コンテンツの内容及び／又は前記コンテンツの視聴状況に応じて前記秘密条件を設定する、
   請求項５〜７の何れか一項に記載のコンテンツ配信システム。
9. 前記コンテンツは、ゲームプレイ動画であり、
   前記秘密イベント制御手段は、前記ゲームプレイ動画に係るゲーム状況に応じて前記秘密条件を設定する、
   請求項５〜８の何れか一項に記載のコンテンツ配信システム。
10. 前記秘密イベント制御手段は、前記秘密条件のヒントを前記ユーザ端末に表示させるヒント表示制御手段を有する、
    請求項５〜９の何れか一項に記載のコンテンツ配信システム。
11. 前記ヒント表示制御手段は、前記提供ユーザ又は前記視聴ユーザによる所定の対価支払と引き換えに前記ヒントを表示させる、
    請求項１０に記載のコンテンツ配信システム。
12. 前記ヒント表示制御手段は、前記対価支払との引き換えによる前記ヒントを、前記コンテンツを視聴中の視聴ユーザ全員のユーザ端末に表示させる、
    請求項１１に記載のコンテンツ配信システム。
13. 前記秘密イベント制御手段は、前記提供ユーザ又は前記視聴ユーザによる所定の対価支払がなされたことを前記開始条件とする、
    請求項５〜１２の何れか一項に記載のコンテンツ配信システム。
14. 当該コンテンツを視聴中の前記視聴ユーザによる発信状況を少なくとも用いて、当該コンテンツに係る活況指標値を算出する手段、
    前記活況指標値に基づいて各コンテンツをランキングするランキング手段、
    を備えた請求項１〜１３の何れか一項に記載のコンテンツ配信システム。
15. 各視聴ユーザのユーザ端末と、請求項１〜１４の何れか一項に記載のコンテンツ配信システムとを具備した、コンピュータシステム。

Images