(57)【要約】【課題】ユーザの参加可能範囲にゲーム性を持たせ、イベントの面白さを向上させることが可能なプログラム、サーバ及びゲームシステムを提供すること。【解決手段】現実世界で発生する事象を予想する予想ゲームのイベントに関するサーバであって、ユーザが所有する仮想通貨の値を制御し、ユーザの仮想通貨を消費することを条件に、当該ユーザから前記事象の予想情報を受け付け、記事象発生後、前記予想情報を受け付けたユーザ毎に、ユーザの前記予想情報と前記事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算する。ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定する。【選択図】図３
2018128788.tif 000002
【特許請求の範囲】
【請求項１】
現実世界で発生する事象を予想する予想ゲームのイベントに関するサーバのプログラムであって、
ユーザが所有する仮想通貨の値を制御する仮想通貨制御部と、
ユーザの仮想通貨を消費することを条件に、当該ユーザから前記事象の予想情報を受け付ける予想情報受付部と、
前記事象発生後、前記予想情報を受け付けたユーザ毎に、ユーザの前記予想情報と前記事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算するパラメータ制御部と、
ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定する設定部として、コンピュータを機能させることを特徴とするプログラム。
【請求項２】
請求項１において、
前記設定部が、
ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する所定の権限の有無を設定することを特徴とするプログラム。
【請求項３】
請求項２において、
前記設定部は、
ユーザのポイントが初期値である場合、前記イベントに関する特定の情報の閲覧権限を有に設定し、前記イベントに関する特定の情報の送信権限を無に設定することを特徴とするプログラム。
【請求項４】
請求項１〜３のいずれかにおいて、
複数種類のイベントを進行させる進行制御部として、コンピュータを更に機能させ、
前記パラメータ制御部が、
前記複数種類のイベントにおいて共通の前記ユーザのポイントを用いることを特徴とするプログラム。
【請求項５】
請求項１〜４のいずれかにおいて、
同一のイベントにおいて、前記事象が複数回発生する前記イベントを進行させる進行制御部として、コンピュータを更に機能させ、
前記パラメータ制御部が、
同一のイベントにおいて、事象が発生する度に、各ユーザのポイントを更新し、
前記設定部が、
事象が発生する度に、更新後の各ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定することを特徴とするプログラム。
【請求項６】
請求項１〜５のいずれかにおいて、
前記事象は、前記イベントの出演者によって発生する事象であって、
前記設定部が、
各ユーザのポイントに基づいて、前記出演者に対するメッセージを送信する権限の有無を設定することを特徴とするプログラム。
【請求項７】
現実世界で発生する事象を予想する予想ゲームのイベントに関するサーバであって、
ユーザが所有する仮想通貨の値を制御する仮想通貨制御部と、
ユーザの仮想通貨を消費することを条件に、当該ユーザから前記事象の予想情報を受け付ける予想情報受付部と、
前記事象発生後、前記予想情報を受け付けたユーザ毎に、ユーザの前記予想情報と前記事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算するパラメータ制御部と、
ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定する設定部と、を含むことを特徴とするサーバ。
【請求項８】
現実世界で発生する事象を予想する予想ゲームのイベントに関するサーバと、ユーザの端末とがネットワークを介して接続されたゲームシステムであって、
前記サーバが、
ユーザが所有する仮想通貨の値を制御する仮想通貨制御部と、
ユーザの仮想通貨を消費することを条件に、当該ユーザから前記事象の予想情報を受け付ける予想情報受付部と、
前記事象発生後、前記予想情報を受け付けたユーザ毎に、ユーザの前記予想情報と前記事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算するパラメータ制御部と、
ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定する設定部と、を含み、
前記ユーザの端末が、
前記ユーザの入力に基づいて前記予想情報を前記サーバに送信する予想情報制御部と、
前記サーバから、前記イベントに関する当該ユーザの参加可能範囲を受信し、当該ユーザの参加可能範囲を設定する設定部と、を含むことを特徴とするゲームシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム、サーバ及びゲームシステムに関する。
【背景技術】
【０００２】
アイドルや芸人などの出演者が、会場でミニゲームや競技を行って順位を競うイベントを開催することがある。例えば、出演者のファンであるユーザがイベントの会場に出向いてアイドルのミニゲームのプレイ等を観覧し楽しむ。また、会場にいないユーザも、ユーザの端末のディスプレイに表示されたイベントの動画を閲覧して楽しむことがある。
【０００３】
また、従来技術では、動画データに対して一の視聴者により送信（投稿）されたメッセージ（コメント）を、他の視聴者の端末において当該動画データの再生時に表示するものが存在する（特許文献１の０００９段落等参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−２２０６１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
イベント事業者にとってイベントの面白さを向上させることが課題となっている。また、従来技術のメッセージ送信機能は、視聴者同士が動画データに対する意識や感想を共有することができ、動画視聴の面白みを高めている。しかし、従来技術は、メッセージの送信機能について制限はなく、メッセージが煩雑化しているという問題があった。
【０００６】
本発明は、以上の課題に鑑みてなされたものであり、その目的とするところは、ユーザの参加可能範囲にゲーム性を持たせ、イベントの面白さを向上させることが可能なプログラム、サーバ及びゲームシステムを提供することにある。
【課題を解決するための手段】
【０００７】
（１）本発明は、
現実世界で発生する事象を予想する予想ゲームのイベントに関するサーバのプログラムであって、
ユーザが所有する仮想通貨の値を制御する仮想通貨制御部と、
ユーザの仮想通貨を消費することを条件に、当該ユーザから前記事象の予想情報を受け付ける予想情報受付部と、
前記事象発生後、前記予想情報を受け付けたユーザ毎に、ユーザの前記予想情報と前記事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算するパラメータ制御部と、
ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定する設定部として、コンピュータを機能させるプログラムに関する。
【０００８】
また、本発明は、コンピュータ読み取り可能な情報記憶媒体であって、上記各部としてコンピュータを機能させるための上記プログラムを記憶した情報記憶媒体に関する。また、本発明は、上記各部を含むサーバに関する。
【０００９】
本発明によれば、イベントに関する当該ユーザの参加可能範囲はユーザのポイントに基づいて設定され、当該ポイントに加算される加算ポイントは、予想ゲームでユーザが予想
した予想情報と、現実世界で発生した事象とに基づいて算出される。ゆえに、本発明は、ユーザの参加可能範囲にゲーム性を持たせ、イベントの面白さを向上させることができる。
【００１０】
（２）また、本発明のプログラム、情報記憶媒体、及びサーバは、
前記設定部が、
ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する所定の権限の有無を設定するようにしてもよい。
【００１１】
本発明によれば、イベントに関する所定の権限の有無はユーザのポイントに基づいて設定され、当該ポイントに加算される加算ポイントは、予想ゲームでユーザが予想した予想情報と、現実世界で発生した事象とに基づいて算出される。ゆえに、本発明は、イベントに関する所定の権限の有無にゲーム性を持たせ、イベントの面白さを向上させることができる。
【００１２】
（３）また、本発明のプログラム、情報記憶媒体、及びサーバは、
前記設定部は、
ユーザのポイントが初期値である場合、前記イベントに関する特定の情報の閲覧権限を有に設定し、前記イベントに関する特定の情報の送信権限を無に設定するようにしてもよい。
【００１３】
本発明によれば、ユーザのポイントが初期値である場合、イベントに関する特定の情報の閲覧権限を有に設定するので、初めて参加したユーザにとってもイベントに関する特定の情報を閲覧することができる。また、本発明は、初めて参加したユーザに対して、特定の情報の送信権限を得られるよう、予想ゲームへの参加を積極的に促すことができる。
【００１４】
「特定の情報の閲覧権限」とは、例えば、チャット等のメッセージを閲覧する権限であり、「特定の情報の送信権限」とは、例えば、チャットに参加できるメッセージ送信権限である。
【００１５】
（４）また、本発明のプログラム、情報記憶媒体、及びサーバは、
複数種類のイベントを進行させる進行制御部として、コンピュータを更に機能させ、
前記パラメータ制御部が、
前記複数種類のイベントにおいて共通の前記ユーザのポイントを用いるようにしてもよい。
【００１６】
本発明によれば、複数種類のイベントにおいて共通のユーザのポイントを用いるので、ユーザに対し、複数種類のイベントそれぞれの予想ゲームでユーザのポイントが上昇するように積極的に継続的にイベントの参加を促すことができる。
【００１７】
（５）また、本発明のプログラム、情報記憶媒体、及びサーバは、
同一のイベントにおいて、前記事象が複数回発生する前記イベントを進行させる進行制御部として、コンピュータを更に機能させ、
前記パラメータ制御部が、
同一のイベントにおいて、事象が発生する度に、各ユーザのポイントを更新し、
前記設定部が、
事象が発生する度に、更新後の各ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定するようにしてもよい。
【００１８】
本発明によれば、事象が複数回発生するイベントにおいて、事象が発生する度に、各ユ
ーザのポイントが更新され、更新後の各ユーザのポイントに基づいて、イベントに関する当該ユーザの参加可能範囲を設定する。ゆえに、本発明は、ユーザに対し、同一イベントにおいて複数回発生する事象それぞれに対して予想するモチベーションを与えることができる。
【００１９】
（６）また、本発明のプログラム、情報記憶媒体、及びサーバは、
前記事象は、前記イベントの出演者によって発生する事象であって、
前記設定部が、
各ユーザのポイントに基づいて、前記出演者に対するメッセージを送信する権限の有無を設定するようにしてもよい。
【００２０】
本発明によれば、各ユーザのポイントに基づいて、出演者に対するメッセージを送信する権限の有無を設定するので、ユーザに対して、メッセージを送信する権限が有になるように、積極的に予想ゲームに参加するように促すことができる。
【００２１】
（７）また、本発明は、
現実世界で発生する事象を予想する予想ゲームのイベントに関するサーバと、ユーザの端末とがネットワークを介して接続されたゲームシステムであって、
前記サーバが、
ユーザが所有する仮想通貨の値を制御する仮想通貨制御部と、
ユーザの仮想通貨を消費することを条件に、当該ユーザから前記事象の予想情報を受け付ける予想情報受付部と、
前記事象発生後、前記予想情報を受け付けたユーザ毎に、ユーザの前記予想情報と前記事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算するパラメータ制御部と、
ユーザ毎に、ユーザのポイントに基づいて、前記イベントに関する当該ユーザの参加可能範囲を設定する設定部と、を含み、
前記ユーザの端末が、
前記ユーザの入力に基づいて前記予想情報を前記サーバに送信する予想情報制御部と、
前記サーバから、前記イベントに関する当該ユーザの参加可能範囲を受信し、当該ユーザの参加可能範囲を設定する設定部と、を含むゲームシステムに関する。
【図面の簡単な説明】
【００２２】
【図１】本実施形態のゲームシステムを示す図。
【図２】本実施形態のイベントの概念図の一例を示す図。
【図３】本実施形態のゲームシステムのプラットフォームの一例を示す図。
【図４】本実施形態の端末１０の機能ブロック図の一例を示す図。
【図５】本実施形態のサーバ２０の機能ブロック図の一例を示す図。
【図６】本実施形態のイベントの進行に関する時系列の説明図の一例を示す。
【図７】本実施形態の予想ゲームの進行に関する時系列の説明図の一例を示す。
【図８】本実施形態の出演者の情報の一例。
【図９】本実施形態のチームの情報の一例。
【図１０】本実施形態の予想入力画面の一例。
【図１１】本実施形態の１位予想におけるベット額設定画面の一例。
【図１２】本実施形態の賭け率の一例。
【図１３】本実施形態の１位予想における確認画面の一例。
【図１４】本実施形態の１位２位予想におけるベット額設定画面の一例。
【図１５】本実施形態の１位２位予想における確認画面の一例。
【図１６】本実施形態の各ユーザの予想情報の一例。
【図１７】本実施形態のミニゲームの結果の一例。
【図１８】本実施形態の予想ゲームの結果を表示する画面の一例。
【図１９】本実施形態のポイントのランキングが表示される画面の一例。
【図２０】本実施形態の称号、係数、メッセージ送信権限に関する対応関係の一例。
【図２１】本実施形態の端末においてメッセージ送信権限が付与されたことを示す情報が表示される画面の一例。
【図２２】本実施形態の端末においてメッセージ送信権限が消失されたことを示す情報が表示される画面の一例。
【図２３】本実施形態のチャット画面の一例。
【図２４】本実施形態のチャット画面の一例。
【図２５】本実施形態の領地獲得に関する説明。
【図２６】本実施形態の領地獲得に関する画面の一例。
【図２７Ａ】本実施形態のサーバ２０が行う処理の一例のフローチャート。
【図２７Ｂ】本実施形態のサーバ２０が行う処理の一例のフローチャート。
【図２８】本実施形態のユーザ情報の一例。
【図２９】本実施形態のユーザ情報の一例。
【図３０】本実施形態のユーザ情報の一例。
【図３１】本実施形態のユーザ情報の一例。
【図３２】本実施形態のサーバ２０が行う処理の一例のフローチャート。
【発明を実施するための形態】
【００２３】
以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必要構成要件であるとは限らない。
【００２４】
１．ゲームシステム
本実施形態では、イベントを開催する事業者が、会場に出演者（アイドル、芸人など）やユーザを招致し、ユーザに対してイベントのサービスを提供する例について説明する。なお、出演者のことをキャストと呼んでもよい。
【００２５】
図１は、本実施形態のゲームシステム１を示す。本実施形態では、複数のユーザの端末１０と、事業者が管理するサーバ２０（サーバシステム）とによって構成される。つまり、図１に示すように、本実施形態のゲームシステム１は、サーバ２０と、ユーザの端末１０とが、ネットワーク（例えば、インターネット）を介して接続可能に構成される。
【００２６】
サーバ２０は、イベントで用いるゲームサーバ、ＳＮＳ（ソーシャル・ネットワーキング・サービス）と呼ばれるコミュニティ型のサービスを提供するＳＮＳサーバ等の機能を有している。
【００２７】
ユーザの端末１０は、インターネット（ＷＡＮ）、ＬＡＮなどのネットワークを介してサーバ２０に接続可能な装置である。なお、ユーザの端末１０とサーバ２０との通信回線は、無線であるが有線であってもよい。
【００２８】
また、サーバ２０は、複数の装置（ハードウエア）によって構成されていてもよく、処理の機能やストレージを分散してもよい。
【００２９】
本実施形態のゲームシステム１は、予めユーザ登録を行ったユーザがイベントに参加することができ、ゲームを行うことができる。
【００３０】
また、図２に示すように、事業者が会場に出演者やユーザを招致し、会場内のユーザは、イベントに参加することができる。会場には、大きなスクリーン（表示装置）を設置し
、多くのユーザがスクリーンを見て、イベントを撮影した画像、動画や、ゲーム画面を見ることができる。また、会場内のユーザ及び会場外のユーザは、ユーザ登録（ユーザ登録）をすることを条件に、イベント内で実施されるゲーム結果やミニゲームのゲーム結果（事象）を予想するゲームに参加することができ、当該ユーザの端末１０で表示される動画やゲーム画面を見ることができる。
【００３１】
２．ゲームシステムのプラットフォームの構成図
図３は、本実施形態のゲームシステム１のプラットフォームＰＦの構成図の一例を示す。
【００３２】
例えば、プラットフォームＰＦは、ユーザ情報が格納されるデータベースと、決済、動画配信、ＳＮＳ、ベット（賭け）、クラウドファンディングで構成されるシステムとが基盤となる。また、プラットフォームＰＦは、バトル、クイズ、スポーツ等の複数の属性（種類）のイベントから一のイベントのプログラムを動作させ、イベントを開催する。また、プラットフォームＰＦは、アイドル、芸人、タレントなどの属性に応じた出演者がイベント開催中にミニゲームや競技を行い、事象（ミニゲームのゲーム結果、競技結果）が発生する。
【００３３】
事業者は、出演者のファンであるユーザを集客することもできるし、イベントの属性に応じて特定のユーザを集客することもできる。なお、プラットフォームＰＦにおけるイベントをエンジン（特定の処理を行う処理装置やプログラム）と呼んでもよい。
【００３４】
３．構成
３．１  ユーザの端末の構成
図４に本実施形態のユーザの端末１０の機能ブロック図の一例を示す。なお、本実施形態のユーザの端末１０は、図４の構成要素（各部）の一部を省略した構成としてもよい。
【００３５】
入力部１６０は、ユーザからの入力情報を入力するための機器であり、ユーザの入力情報を処理部に出力する。本実施形態の入力部１６０は、ユーザの入力情報（入力信号）を検出する検出部１６２を備える。入力部１６０は、例えば、レバー、ボタン、ステアリング、マイク、タッチパネル型ディスプレイ、キーボード、マウスなどがある。
【００３６】
本実施形態のユーザの端末１０は、タッチパネルへタッチ入力（接触操作）で操作するものであるが、ユーザの端末１０には、ボタン、方向キーなどの操作子（ボタン、方向キー等）を有していてもよい。
【００３７】
また、入力部１６０は、３軸の加速度を検出する加速度センサや、角速度を検出するジャイロセンサ、撮像部を備えた入力機器でもよい。例えば、入力機器は、ユーザが把持して動かすものであってもよいし、ユーザが身につけて動かすものであってもよい。また、入力機器には、ユーザが把持する刀型コントローラや銃型コントローラ、あるいはユーザが身につける（ユーザが手に装着する）グローブ型コントローラなど実際の道具を模して作られたコントローラも含まれる。また入力機器には、入力機器と一体化されているゲーム装置、携帯型ゲーム装置、携帯電話なども含まれる。本実施形態のユーザの端末１０は、複数の入力部１６０を備えていてもよい。
【００３８】
記憶部１７０は、処理部１００の各部としてコンピュータを機能させるためのプログラムや各種データを記憶するとともに、処理部１００や通信部１９６の記憶領域として機能する。
【００３９】
記憶部１７０は、一時的な記憶領域や、ストレージを含む。ストレージとは、ハードデ
ィスク、光学ディスク、フラッシュメモリ、磁気テープ等であり、データを永続的に記憶する装置のことをいう。また、記憶部１７０は、情報記憶媒体１８０に格納されているプログラムやデータを記憶してもよい。
【００４０】
そして、本実施形態の記憶部１７０は、ワーク領域として使用される主記憶部１７１と、表示画像等が記憶される画像バッファ１７２とを含む。なお、これらの一部を省略する構成としてもよい。
【００４１】
主記憶部１７１は、ＲＡＭなどにより実現できる。主記憶部１７１は、本実施形態の処理において使用される記憶領域である。画像バッファ１７２は、ＶＲＡＭなどにより実現できる。
【００４２】
情報記憶媒体１８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などにより実現できる。なお、情報記憶媒体１８０はストレージである。
【００４３】
また、情報記憶媒体１８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）を記憶することができる。
【００４４】
なお、サーバ２０が有する情報記憶媒体や記憶部に記憶されているプログラムや各種データを、ネットワークを介して受信し、受信したプログラムやデータを記憶部１７０や情報記憶媒体１８０に記憶してもよい。このようにプログラムや各種データを受信して端末１０の処理部１００の各部としてコンピュータを機能させる場合も本発明の範囲内に含む。なお、処理部１００は、後述するように、記憶部１７０や情報記憶媒体１８０に格納されるプログラムやデータに基づいて本実施形態の種々の処理を行う。
【００４５】
表示部１９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、タッチパネルディスプレイ、或いはＨＭＤ（ヘッドマウントディスプレイ）などにより実現できる。
【００４６】
なお、表示部１９０は、タッチパネルディスプレイを用いることによりユーザが操作を行う入力部１６０としても機能してもよい。ここでタッチパネルとして、例えば抵抗膜方式（４線式、５線式）、静電容量方式、電磁誘導方式、超音波表面弾性波方式、赤外線走査方式などのタッチパネルを用いることができる。
【００４７】
音出力部１９２は、処理部１００で生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
【００４８】
通信部１９６はサーバ２０との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。
【００４９】
処理部１００（プロセッサ）は、入力部１６０からの操作入力（入力情報）、記憶部１７０や情報記憶媒体１８０に格納されるプログラム及びデータ、通信部１９６を介して受信したデータなどに基づいて、プログラムの実行処理、画像生成処理、音生成処理、などの処理を行う。処理部１００は、記憶部１７０内の主記憶部１７１をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。
【００５０】
処理部１００は、ユーザ登録部１１０、チーム決定部１１１、予想情報制御部１１２、設定部１１３、画像生成部１３０、音生成部１４０を含む。
【００５１】
ユーザ登録部１１０は、ユーザの入力に基づき、サーバ２０にユーザの基本情報（ユーザ名等）を送信する処理を行い、ユーザ登録を行う。
【００５２】
チーム決定部１１１は、ユーザの入力情報に基づき、複数のチーム（赤、青、緑、黄のチーム）の中から一のチームの選択を受け付ける処理を行う。チーム決定部１１１は、ユーザが選択したチーム名（チームＩＤ）を、サーバ２０に送信する処理を行う。
【００５３】
予想情報制御部１１２は、ユーザの入力に基づいて予想情報をサーバ２０に送信する。つまり、予想情報制御部１１２は、ユーザの入力情報に基づき、ユーザがベットする出演者と、賭け額を受け付け、ユーザがベットした出演者及び賭け額等を含む予想情報をサーバ２０に送信する処理を行う。
【００５４】
設定部１１３は、サーバ２０から、イベントに関する当該ユーザの参加可能範囲を受信し、当該ユーザの参加可能範囲を設定する。例えば、設定部１１３は、メッセージ閲覧権限が有の場合、メッセージを閲覧可能に設定する。また、設定部１１３は、メッセージ送信権限が有の場合、メッセージを送信可能に設定する。
【００５５】
画像生成部１３０は、処理部１００で行われる種々の処理の結果に基づいて描画処理を行い、これにより画像を生成し、表示部１９０に出力する。画像生成部１３０は、オブジェクト空間内において仮想カメラ（所与の視点）から見える画像（いわゆる３次元画像）を生成してもよい。
【００５６】
例えば、画像生成部１３０は、３次元画像を生成する場合には、まず、座標変換（ワールド座標変換、カメラ座標変換）、クリッピング処理、或いは透視変換等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ（プリミティブ面の頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等）が作成される。そして、この描画データ（プリミティブ面データ）に基づいて、透視変換後（ジオメトリ処理後）のオブジェクト（１又は複数プリミティブ面）を画像バッファ１７２（フレームバッファ、ワークバッファなどのピクセル単位で画像情報を記憶できるバッファ。ＶＲＡＭ）に描画する。これにより、オブジェクト空間内において仮想カメラ（所与の視点）から見える画像が生成される。
【００５７】
音生成部１４０は、処理部１００で行われる種々の処理の結果に基づいて音処理を行い、ＢＧＭ、効果音、又は音声などの音を生成し、音出力部１９２に出力する。
【００５８】
３．２  サーバの構成
図５に本実施形態のサーバ２０の機能ブロック図の一例を示す。なお本実施形態のサーバは図５の構成要素（各部）の一部を省略した構成としてもよい。
【００５９】
記憶部２７０は、処理部２００の各部としてコンピュータを機能させるためのプログラムや各種データを記憶するとともに、処理部２００や通信部２９６の記憶領域として機能する。
【００６０】
記憶部２７０は、一時的な記憶領域や、ストレージを含む。また、記憶部２７０は、情報記憶媒体２８０に格納されているプログラムやデータを記憶してもよい。
【００６１】
そして、本実施形態の記憶部２７０は、ワーク領域として使用される主記憶部２７２と、ユーザ情報記憶部２７３とを含む。なお、これらの一部を省略する構成としてもよい。
【００６２】
主記憶部２７２は、ＲＡＭなどにより実現できる。主記憶部２７２は、本実施形態の処理において使用される記憶領域である。
【００６３】
ユーザ情報記憶部２７３には、サーバ２０が管理するユーザ情報を格納する。例えば、ユーザ情報記憶部２７３には、ユーザＩＤ（ユーザ識別情報）に対応付けて、ユーザに関する情報が記憶される。例えば、ユーザ情報記憶部２７３には、参加状況を含むユーザ情報等が記憶される。
【００６４】
情報記憶媒体２８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などにより実現できる。処理部２００は、情報記憶媒体２８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体２８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。
【００６５】
通信部２９６は外部（例えば、ユーザの端末１０、他のサーバや他のネットワークシステム）との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。
【００６６】
処理部２００（プロセッサ）は、記憶部２７０や情報記憶媒体２８０に記憶されるプログラム及びデータ、通信部２９６を介して受信したデータなどに基づいて、処理を行う。
【００６７】
また、処理部２００は記憶部２７０内の主記憶部２７１をワーク領域として各種処理を行う。処理部２００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。
【００６８】
特に、本実施形態のサーバ２０の処理部２００は、参加制御部２１０、仮想通貨制御部２１１、予想情報受付部２１２、判断部２１３、パラメータ制御部２１４、設定部２１５、進行制御部２１６、ユーザ情報管理部２１７、抽出処理部２１８、動向調査部２１９、決済制御部２２０、動画配信部２２１、ＳＮＳ制御部２２２、クラウドファンディング制御部２２３を含む。なお、これらの一部を省略する構成としてもよい。
【００６９】
参加制御部２１０は、ユーザ登録により、出演者が出演するイベントに、ユーザを参加させる。例えば、参加制御部２１０は、端末１０から受信したユーザの基本情報をユーザ情報記憶部２７３に記憶することによって、ユーザ登録を行う。
【００７０】
仮想通貨制御部２１１は、ユーザが所有する仮想通貨の値を制御する。例えば、仮想通貨制御部２１１は、イベントの予想ゲームの予想情報を受け付ける場合に、ベット額（賭け額）に応じた値を、ユーザが所有する仮想通貨から減算する。また、仮想通貨制御部２１１は、ユーザが課金することによって、課金額に応じた値を、ユーザが所有する仮想通貨に加算する。
【００７１】
予想情報受付部２１２は、イベントに参加したユーザから、事象の予想情報を受け付ける。特に、本実施形態の予想情報受付部２１２は、ユーザの仮想通貨を消費することを条件に、当該ユーザから事象の予想情報を受け付ける。なお、事象は、例えば、イベントの出演者によって発生する事象である。具体的には、イベントの出演者のミニゲームをプレ
イすることによって発生するゲーム結果や、イベントの出演者の競技をプレイすることによって発生する競技結果等である。
【００７２】
判断部２１３は、事象発生後、予想情報を受け付けたユーザ毎に、ユーザの予想情報と当該事象とに基づいて、ユーザの予想情報が的中したか否かを判断する。
【００７３】
パラメータ制御部２１４は、事象発生後、予想情報を受け付けたユーザ毎に、ユーザの予想情報と事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算する。また、パラメータ制御部２１４は、複数種類のイベントにおいて共通のユーザのポイントを用いる。また、パラメータ制御部２１４は、同一のイベントにおいて、事象が発生する度に、各ユーザのポイントを更新する。
【００７４】
設定部２１５は、ユーザ毎に、ユーザのポイントに基づいて、イベントに関する当該ユーザの参加可能範囲を設定する。例えば、設定部２１５は、ユーザ毎に、ユーザのポイントに基づいて、イベントに関する所定の権限の有無を設定する。また、設定部２１５は、ユーザのポイントが初期値である場合、イベントに関する特定の情報の閲覧権限を有に設定し、イベントに関する特定の情報の送信権限を無に設定する。
【００７５】
また、設定部２１５は、事象が発生する度に、更新後の各ユーザのポイントに基づいて、イベントに関する当該ユーザの参加可能範囲を設定する。また、設定部２１５は、各ユーザのポイントに基づいて、出演者に対するメッセージを送信する権限の有無を設定する
進行制御部２１６は、複数種類のイベントを進行させる。例えば、進行制御部２１６は、同時に複数種類のイベントを進行させてもよいし、複数のイベントを、順番に進行させるようにしてもよい。また、進行制御部２１６は、同一のイベントにおいて、事象が複数回発生するイベントを進行させる。例えば、進行制御部２１６は、同時に複数の事象が発生するイベントを進行させてもよいし、複数の事象が順番に発生するイベントを進行させるようにしてもよい。イベントの進行制御とは、時間軸に沿った制御であり、例えば、イベントの予想ゲームにおいて予想受付期間を定める処理、事象発生後、ポイント演算を開始する制御、等である。
【００７６】
ユーザ情報管理部２１７は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザの参加状況を含むユーザ情報を蓄積してユーザ情報記憶部２７３に記憶する。
【００７７】
抽出処理部２１８は、ユーザ毎に、ユーザの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する処理を行う。また、抽出処理部２１８は、ユーザ毎に、ユーザの参加状況に基づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する処理を行う。
【００７８】
また、抽出処理部２１８は、ユーザの参加状況に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行う。例えば、抽出処理部２１８は、ユーザのログイン回数に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行う。また、抽出処理部２１８は、ユーザの予想ゲームの予想情報に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行う。また、抽出処理部２１８は、ユーザの決済情報に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行う。
【００７９】
また、抽出処理部２１８は、ユーザ毎に、ユーザ及び当該ユーザのフレンドの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する処理を行う。
【００８０】
また、抽出処理部２１８は、ユーザ毎に、ユーザ及びユーザのフレンドの参加状況に基
づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する処理を行う。
【００８１】
動向調査部２１９は、ユーザ毎に、特定時点でのユーザのイベントの参加態様を特定する。また、動向調査部２１９は、ユーザ毎に、特定時点でのユーザの参照ページを特定する。また、動向調査部２１９は、ユーザ毎に、特定時点でのユーザ及び当該ユーザのフレンドの参加態様及び参照ページの少なくとも一方を特定する。
【００８２】
決済制御部２２０は、ユーザの端末からの課金情報（課金対象の項目（仮想通貨、クラウドファンディング等の情報）、課金額）を受信して、当該課金情報に基づき決済を行う。決済とは、売買取引を完了させることであり、例えば、クレジットカードでの決済や、電子マネーによる決済等を行う。
【００８３】
動画配信部２２１は、会場の様子を撮影した動画データをユーザの端末に配信（送信）する処理を行う。
【００８４】
ＳＮＳ制御部２２２は、ＳＮＳサイト（ＳＮＳサーバ）と連携し、ユーザＩＤに対応付けられたＳＮＳサイトのユーザＩＤを利用して、ＳＮＳサイトへの投稿等を利用可能に制御する。
【００８５】
クラウドファンディング制御部２２３は、ユーザの入力情報に基づき、出演者に対して投資額を設定して、当該出演者に対して投資を行う。
【００８６】
４．バトルのイベントの例
４．１  概要
次に、本実施形態において、図３に示すプラットフォームＰＦにおいて、出演者の属性を現実世界に存在するアイドルとし、イベントの属性をバトルとする例について説明する。
【００８７】
まず、事業者は、現実世界の会場に８人のアイドルを招致し、青、赤、黄、緑の４チームに２名の出演者を配属させ、チーム戦でミニゲームや競技を行い、領地（例えば、日本の県）を獲得するイベントを開催する。つまり、ゲームシステム１は、現実に行われるイベントに融合したシステムとなる。
【００８８】
また、ユーザは、青、赤、黄、緑の４チームの中から１つのチームを選択して所属チームを決定し、イベント中に、事象を予想する予想ゲームに参加することができる。事象を予想する予想ゲームとは、アイドルがプレイするミニゲームや競技の結果を予想するゲームである。ユーザは、予想が当たるとポイントを獲得することができる。サーバ２０は、ユーザのポイントをランキング化し、上位の一部のユーザに対して、出演者に対してメッセージを送信できるように制御する。
【００８９】
そして、各チームの出演者は、自身のミニゲームのゲーム結果及びユーザの予想結果に応じて領地を獲得することができる。予想ゲームは複数回行われ、最終的に、多くの領地を獲得したチームが優勝となる。
【００９０】
このように、本実施形態のイベントによれば、ユーザはアイドルのゲームプレイやミニゲームの様子を楽しむことができる。また、ユーザは、ミニゲーム（或いは競技）の結果を予想するゲームに参加でき、イベントを一層楽しむことができる。
以下、詳細に本実施形態の処理について説明する。
【００９１】
４．２  ユーザ登録
本実施形態のサーバ２０は、ユーザの端末１０から登録要求を受け付けた場合に、当該ユーザの登録処理を行う。ユーザ毎に、ユーザＩＤ（ユーザの識別情報）に対応づけてユーザのユーザ名、ニックネーム等の基本情報を記憶する。
【００９２】
４．３  仮想通貨の説明
本実施形態では、ユーザ毎に、ユーザが所持する仮想通貨を設定している。例えば、サーバ２０は、ユーザの仮想通貨の初期値として１０００円を付与する。ユーザは、事象を予想するゲームに参加する際に、少なくとも１円以上の仮想通貨を消費することになる。なお、説明の便宜上、仮想通貨の単位を円で説明しているが、ドル、ユーロの他、仮想上の通貨単位であってもよい。なお、「仮想通貨」は、「ゲーム内通貨」ともいう。また、ユーザは、課金することによってユーザが所持する仮想通貨の金額を増加させることができる。
【００９３】
４．４  所属チーム
本実施形態の端末１０は、ユーザが事象を予想するゲームに参加する前に、ユーザの入力情報に基づき、イベントにおけるチーム（赤、青、緑、黄のチーム）の中から一のチームの選択を受け付ける処理を行う。端末１０は、ユーザが選択したチームの識別情報（例えば、チーム名）を、サーバ２０に送信する処理を行う。例えば、ユーザＰ１が、青チームを選択した場合、ユーザＰ１に対応付けて所属チームを青に設定する。
【００９４】
４．５  イベントの流れ
まず、事業者側が、イベントの開始日時を予め定める。本実施形態では、図６に示すように、イベント期間中、複数の予想ゲームを行ってイベントを進行させる。全ての予想ゲームが終了すると、イベントを終了する。
【００９５】
また、事業者は、イベントの開始日時の前において、ユーザの端末１０に対して、イベントの開始日時やイベント内容（予想ゲーム内容）の告知をする。イベントは、現実世界にリアルタイムに開催されるものである。イベント期間は２時間〜３時間程度になる。本実施形態のイベントでは、予想ゲームを８回行うが、予想ゲームの回数は複数回でもよいし、予想ゲームの回数は１回でもよい。
【００９６】
４．６  予想ゲームの流れ
図７は、事象を予想するゲーム（予想ゲーム）の時間軸の流れを示す。Ｒ１〜Ｒ７のゲーム期間において、事象（ミニゲームのゲーム結果）の予想を受け付ける予想受付期間Ｒ１〜Ｒ２を設ける。言い換えると、予想受付期間Ｒ１〜Ｒ２において、ユーザが、出演者（アイドル）の中から誰が１位になるか、或いは、誰が１位で誰が２位になるかを予想し、ユーザの仮想通貨をベットする（賭ける）。
【００９７】
予想受付期間の終了後、ミニゲームのゲームプレイ期間Ｒ３〜Ｒ４において、出演者がミニゲームをプレイする。ミニゲームのゲームプレイ期間終了後、結果発表期間Ｒ５〜Ｒ６があり、その後、領地獲得期間Ｒ６〜Ｒ７がある。結果発表期間では、ミニゲームのゲーム結果が発表され、ユーザの予想が的中したか否かを判定する。領地獲得期間では、出演者が、いずれの領地を獲得するかを発表する。
【００９８】
４．７  出演者の情報
図８は、サーバ２０が管理する出演者の情報の一例を示す。例えば、サーバ２０は、出演者ＩＤ（出演者の識別情報）に対応付けて、出演者の氏名、出演者が所属するチーム名を記憶する。
【００９９】
４．８  チームの情報
図９は、サーバ２０が管理するチームの情報の一例を示す。例えば、サーバ２０は、チーム名（チームの識別情報、チームＩＤ等）に対応付けて、チーム名、領地数、順位を記憶する。
【０１００】
４．９  予想情報受付処理
次に、本実施形態のサーバ２０が、事象（ミニゲームのゲーム結果）を予想する予想情報を受け付ける処理について具体的に説明する。図１０は、ミニゲームの実施前に、ユーザの端末１０に表示される予想入力画面の一例を示す。例えば、予想受付期間に予想入力画面を表示する。
【０１０１】
図１０に示すように、１〜８の番号に対応付けて、出演者の名前、所属チーム名（青、緑、赤、黄のいずれか）、出演者の画像を表示する。本実施形態のイベントでは、各チーム２名の出演者がミニゲームを行うので、合計８名の出演者の名前等が表示される。
【０１０２】
まず、ユーザは、「１位予想」をするのか、「１位２位予想」をするのかを、選択する。例えば、ユーザの端末は、「１位予想」ボタンＣ１の入力を受け付けた場合、ユーザは、ミニゲームを行う８名の出演者の中から、１位になると思う出演者１名に自分の仮想通貨を賭ける（ベットする）。
【０１０３】
例えば、ユーザＰ１が１位になると思う出演者に、１番の出演者（青チーム、Ｎａｏｍｉ）を選ぶ場合には、ユーザＰ１の端末１０において、１番の出演者（青チーム、Ｎａｏｍｉ）の表示エリアをタッチ入力する。ユーザＰ１の端末１０は、１番の出演者（青チーム、Ｎａｏｍｉ）の選択を受け付けると、ベット額設定画面に移行する。
【０１０４】
図１１は、１位予想におけるベット額設定画面の一例を示す。例えば、ベット額設定画面では、ユーザＰ１が選択した１番の出演者（青チーム、Ｎａｏｍｉ）に対して、ユーザＰ１の所有の仮想通貨から賭ける額を決定する。また、ベット額設定画面では、ユーザＰ１が選択した１番の出演者（青チーム、Ｎａｏｍｉ）に対して、賭け率Ａ１を表示する。図１１の例では、賭け率は４０倍である。
【０１０５】
そして、図１１に示すように、例えば、ユーザＰ１の端末１０は、「１０」ボタンＡ４の入力を受け付けた場合に、１０円単位で賭け額を増やし、「１」ボタンＡ５の入力を受け付けた場合に、１円単位で賭け額を増やす。Ａ３エリアには、現在の１番の出演者（青チーム、Ｎａｏｍｉ）に対する賭け額（例えば、１円）を表示する。
【０１０６】
また、ユーザＰ１の端末１０は、「クリア」ボタンＡ２の入力を受け付けた場合に、ユーザＰ１が選択した１番の出演者（青チーム、Ｎａｏｍｉ）の賭け額を０円に更新する。
【０１０７】
そして、ユーザＰ１の端末１０において、１番の出演者（青チーム、Ｎａｏｍｉ）について、１円の賭け額が設定され、ベット確認ボタンＡ６の入力を受け付けると、確認画面に移行する。
【０１０８】
なお、サーバ２０は、図１２に示すように、予想ゲーム毎に、予め賭け率（オッズ）を設定している。例えば、サーバ２０は、１位予想の出演者毎に賭け率を設定し、１位２位予想の２人組の出演者毎に賭け率を設定する。
【０１０９】
図１３は、確認画面の一例を示す。確認画面では、賭け率Ｂ１、「１位予想」或いは「１位２位予想」の種別Ｂ２、賭け額Ｂ３、賭けに勝った場合に、ユーザが受け取れるポイントＢ４を表示する。
【０１１０】
例えば、図１３の例によれば、ユーザＰ１は、１番の出演者（青チーム、Ｎａｏｍｉ）を１位と予想し、賭け額が１円であることを示す。また、予想が的中した場合（賭けに勝った場合）に、ユーザＰ１が４０ポイントを取得することを示している。
【０１１１】
また、確認画面において、ユーザが所持する仮想通貨から賭け額を使用（消費、減算）して、ベットする内容を示すメッセージをＢ５エリアに表示する。
【０１１２】
ユーザＰ１の端末１０において、「はい」のボタンＢ７の入力を受け付けると、ユーザＰ１の所有している仮想通貨から１円を減算し、１番の出演者（青チーム、Ｎａｏｍｉ）を１位予想として１円をベットすることを確定する。
【０１１３】
そして、ユーザＰ１の端末１０は、ベット確定後、予想情報（ベット情報）をユーザＰ１のＩＤに対応付けて、サーバ２０に送信する。予想情報とは、例えば、賭けた出演者名（例えば、Ｎａｏｍｉ）、賭けの種別（例えば、１位予想）、賭け額（例えば、１円）等である。
【０１１４】
一方、ユーザＰ１の端末１０において、「いいえ」のボタンＢ６の入力を受け付けると確定せずに、図１０の予想入力画面、又は、図１１のベット額設定画面に戻る。
【０１１５】
次に、本実施形態において、ユーザが「１位２位予想」を選択した場合の処理について説明する。
【０１１６】
例えば、図１０の予想入力画面で、ユーザの端末は、「１位２位予想」ボタンＣ２の入力を受け付けた場合、ユーザは、ミニゲームを行う８名の出演者の中から、１位になると思う出演者１名と、２位になると思う出演者１名の組で自分の仮想通貨を賭ける（ベットする）。
【０１１７】
例えば、ユーザＰ１が１位になると思う出演者に、１番の出演者（青チーム、Ｎａｏｍｉ）を選ぶ場合には、ユーザＰ１の端末１０において、１番の出演者（青チーム、Ｎａｏｍｉ）の表示エリアをタッチ入力する。そして、１番の出演者（青チーム、Ｎａｏｍｉ）の表示エリアをタッチ入力後、ユーザＰ１が２位になると思う出演者に４番の出演者（緑チーム、Ｊａｎｅ）を選ぶ場合に、ユーザＰ１の端末１０において、４番の出演者（緑チーム、Ｊａｎｅ）の表示エリアをタッチ入力する。
【０１１８】
ユーザＰ１の端末１０は、１番の出演者（青チーム、Ｎａｏｍｉ）、４番の出演者（緑チーム、Ｊａｎｅ）を受け付けると、ベット額設定画面に移行する。
【０１１９】
図１４は、１位２位予想におけるベット額設定画面の一例を示す。例えば、ベット額設定画面では、ユーザＰ１が選択した１位の１番の出演者（青チーム、Ｎａｏｍｉ）、２位の４番の出演者（緑チーム、Ｊａｎｅ）に対して賭ける仮想通貨の額を決定する。
【０１２０】
例えば、図１４に示すように、ユーザＰ１の端末１０において、１位の１番の出演者（青チーム、Ｎａｏｍｉ）、２位の４番の出演者（緑チーム、Ｊａｎｅ）に対して、１０円の賭け額が設定され、ベット確認ボタンＡ６のタッチ入力を受け付けると、確認画面に移行する。
【０１２１】
図１５は、１位２位予想における確認画面の一例を示す。例えば、確認画面では、１番の出演者（青チーム、Ｎａｏｍｉ）を１位、４番の出演者（緑チーム、Ｊａｎｅ）を２位と予想し、賭け率は２１０倍、賭け額が１０円であることを示す。また、予想が的中した場合（賭けに勝った場合）に、ユーザＰ１が２１００ポイントを取得することを示してい
る。
【０１２２】
また、ユーザＰ１の端末１０の確認画面において、「はい」のボタンＢ７の入力を受け付けると、ユーザＰ１の所有している仮想通貨から１０円を減算し、１番の出演者（青チーム、Ｎａｏｍｉ）を１位、４番の出演者（緑チーム、Ｊａｎｅ）を２位と予想として１０円をベットをすることを確定する。
【０１２３】
そして、ユーザＰ１の端末１０は、ベット確定後、予想情報をユーザＰ１のＩＤに対応付けて、サーバ２０に送信する。予想情報とは、例えば、１位に賭けた出演者名（例えば、Ｎａｏｍｉ）、２位に賭けた出演者名（例えば、Ｊａｎｅ）、賭けの種別（例えば、１位２位予想）、賭け額（例えば、１０円）等である。
【０１２４】
一方、ユーザＰ１の端末１０において、「いいえ」のボタンＢ６の入力を受け付けると確定せずに図１０の予想入力画面、又は、図１１のベット額設定画面に戻る。
【０１２５】
なお、端末１０は、図１５に示すように、設定済みの予想情報Ｂ８を表示してもよい。
【０１２６】
そして、予想受付期間が終了すると、サーバ２０は、予想情報の受け付けを終了する。端末１０は、サーバ２０から予想受付期間の終了時刻の情報を受信すると、予想入力画面、ベット額設定画面、確認画面それぞれにおいて予想受付終了時刻までの残り時間を表示し、予想受付期間終了時に、予想受付を終了したことを示す情報を表示する。
【０１２７】
図１６は、サーバ２０が管理する各ユーザの予想情報の一例を示す。サーバ２０は、１位予想の種別の場合、ユーザＩＤ及びベットＩＤに対応付けて、１位予想の出演者名と賭け額を記憶する。サーバ２０は、１位２位予想の種別の場合において、ユーザＩＤ及びベットＩＤに対応付けて、１位予想の出演者名と２位予想の出演者名、及び、賭け額を記憶する。
【０１２８】
本実施形態では、ユーザは、賭けの対象の出演者や種別を異ならせて複数の賭け（ベット）の設定を行うことができる。例えば、予想受付期間が終了していない場合、ユーザＰ１から別の出演者に対して１位予想の予想情報、１位２位の予想情報を受け付けてもよい。また、ユーザは、自身が所属するチームに関係なく、出演者をベット対象に選んでもよい。
【０１２９】
４．１０  ミニゲームの実施
予想受付期間終了後、ミニゲームの実施が進行する。例えば、イベントの進行役である司会者が「ミニゲームを始めます」など宣言し、ミニゲームのゲームプレイを開始する。そして、各チーム２名、合計８名の出演者がミニゲームを行い、順位を決定する。
【０１３０】
ミニゲームの内容は、例えば順位を競うゲーム（音楽ゲーム、レースゲーム等）である。なお、ミニゲームの替わりに、スポーツなどの順位を競う競技（マラソン等）を行ってもよい。
【０１３１】
サーバ２０は、ミニゲームの様子を撮影した動画データを、ユーザの端末１０に対してストリーミング配信する。したがって、会場にいないユーザも、出演者がプレイしているミニゲームの様子を楽しむことができる。例えば、ユーザは、自分が所属するチームの出演者を応援するだけでなく、自分がベットした出演者を応援するので、イベントの内容は白熱したものになる。
【０１３２】
４．１１  結果発表
ミニゲームのプレイ期間が終了すると、会場において、スクリーンにミニゲームを行った８名の出演者のゲーム結果（順位）を発表する。また、サーバ２０は、結果発表の様子を撮影した動画データを、ユーザの端末１０に対してストリーミング配信する。
【０１３３】
図１７は、ミニゲームのゲーム結果の一例を示す。例えば、１位が青チームのＮａｏｍｉであり、２位が、赤チームのＡｎｎａであることを示す。
【０１３４】
つまり、１位予想において１位に青チームのＮａｏｍｉに予想（ベット）したユーザは勝ちと判定される。また、１位２位予想において１位に青チームのＮａｏｍｉ、２位に赤チームのＡｎｎａに予想（ベット）したユーザは勝ちと判定される。
【０１３５】
４．１２  ポイントの演算
本実施形態のサーバ２０は、ミニゲーム終了後、ユーザ毎に、当該ミニゲームのゲーム結果（事象）とユーザの予想情報とを比較し、予想情報が的中したか否か、すなわち、ベットに勝ったか否かを判断する。そして、サーバ２０は、予想ゲーム毎に、予想情報が的中したか否かを判断する。
【０１３６】
例えば、図１８は、ユーザＰ１の端末１０において、ユーザＰ１の各予想情報の勝ち、負けの結果（予想ゲームの結果）を示す画面である。つまり、サーバ２０は、ユーザＰ１の、１位２位予想の予想情報は的中しなかったと判断し、１位予想の予想情報は的中したと判断する。
【０１３７】
また、サーバ２０は、イベント中に開催されるミニゲームのゲーム期間の終了時に、ユーザ毎に、事象に対するユーザの予想情報が的中したか否かに基づいて、ユーザのポイントに加算するための加算値を算出し、加算値をユーザのポイントに加算する。つまり、サーバ２０は、予想ゲーム毎に加算値を算出し、ユーザのポイントを更新する。加算値の算出は、下式（１）によって行う。なお、係数の初期値は１である。
【０１３８】
加算値＝賭け額×賭け率×係数・・・（１）
例えば、ユーザＰ１のベットＩＤ＝１の予想情報である１位予想が的中している。なお、ユーザＰ１の係数は１であるとする。すると、ユーザＰ１の１位予想の賭け額１（円）に賭け率４０倍を乗じた４０に、更に係数１を乗じた値４０を、ユーザＰ１の加算値とする。
【０１３９】
例えば、ミニゲームの実施前のユーザＰ１のポイントの値が１０００である場合には、ユーザＰ１のポイントに加算値４０を加算し、ユーザＰ１のポイントの値は１０４０に更新される。
【０１４０】
また、ユーザＰ２のベットＩＤ＝１の予想情報である１位予想、及び、ベットＩＤ＝５の予想情報である１位２位予想が的中している。なお、ユーザＰ２の係数は１であるとする。すると、ユーザＰ２の予想的中した１位予想の賭け額２（円）に４０倍×１倍を乗じた８０と、ユーザＰ２の予想的中した１位２位予想の賭け額１０（円）に２１０倍×１倍を乗じた２１００とを、ユーザＰ２のポイントに加算する。
【０１４１】
例えば、ミニゲームの実施前のユーザＰ２のポイントの値が２０００である場合には、ユーザＰ２のポイントに、加算値８０と加算値２１００とを加算し、ユーザＰ２のポイントの値は４１８０に更新される。
【０１４２】
４．１３  ポイントのランキング、及び、称号の更新
本実施形態のサーバ２０は、チーム毎に各ユーザのポイントをランキング化（順位付け
）する。ランキング化とは、ポイントの高い順に並び替えることを意味する。
【０１４３】
図１９は、青チームの各ユーザをポイントの高い順に並び替えた、ランキングの画面の一例を示す。なお、サーバ２０は、青チームだけでなく各チームそれぞれのユーザのポイントを高い順に並び替えてランキング化を行う。また、サーバ２０は、予想ゲーム毎に、ユーザのポイントを更新するので、予想ゲーム毎に、ランキングを更新する。
【０１４４】
また、各ユーザの端末１０は、ユーザの所属するチームのユーザのポイントのランキングを表示する。例えば、端末１０は、ユーザが所属するチームの１位〜２００位までのユーザのランキングと称号、ユーザ名（ユーザＩＤやニックネームでもよい）、ポイントの値を表示する。このようにすれば、ユーザは、自身のポイントと他のユーザのポイントとを比較することができる。また、次の予想ゲームに対するモチベーションを高めることができる。
【０１４５】
また、サーバ２０は、図１９に示すように、チーム毎に、各ユーザの称号を更新する。称号は、階級のことであり、称号が高いほど、ユーザにとってメリットがある。なお、サーバ２０は、予想ゲーム１のランキング化前の初期状態においては、各ユーザに最も低い階級の「足軽」の称号を付与する。
【０１４６】
例えば、サーバ２０は、図２０に示すように、ランキング化後、１位のユーザに「大将」の称号を付与し、２位のユーザに「副将」の称号を付与し、３位に「五千人将」の称号を付与し、４位に「三千人将」の称号を付与し、５位〜１０位に「千人将」の称号を付与し、１１位〜２０位に「五百人将」の称号を付与し、２１位〜１００位に「百人将」の称号を付与し、１０１位〜２００位に「組頭」の称号を付与し、２０１位〜１０００位に「伍長」の称号を付与する。なお、１００１位以上は「足軽」の称号とする。また、各チームの１名の出演者は、「総大将」の称号が与えられ、各チームの他の１名の出演者は、「軍師」の称号が与えられている。
【０１４７】
また、サーバ２０は、図２０に示すように、加算値算出時に用いられる係数を称号に対応付けて記憶する。称号が上がれば上がるほど、係数を上昇させるようにし、ユーザにとって加算値が増えるように制御している。
【０１４８】
また、本実施形態のサーバ２０は、各ユーザのポイント更新後、チームに関係なく全ユーザのポイントのランキング化し、各ユーザの端末１０は、サーバ２０から当該ランキング結果を受信して表示してもよい。
【０１４９】
４．１４  各ユーザの参加可能範囲の設定
本実施形態のサーバ２０は、ユーザ毎に、ユーザのメッセージ閲覧権限（所定の権限の一例）の有無をフラグ（有を１、無を０）で設定し、ユーザ毎に、ユーザの送信権限（所定の権限の一例）の有無をフラグ（有を１、無を０）で設定することによって、各ユーザの参加可能範囲を設定する。
【０１５０】
メッセージ閲覧権限は、例えば、ユーザや他のユーザが出演者に向けて送信したメッセージを閲覧することができるか否かを示す権限である。メッセージ閲覧権限は、チャット閲覧権限ともいう。サーバ２０は、ユーザ登録を行った全てのユーザに対して、メッセージ閲覧権限を有に設定する。
【０１５１】
メッセージ送信権限は、ユーザが出演者に向けてメッセージを送信することができるか否かを示す権限である。メッセージ送信権限は、チャット参加権限ともいう。サーバ２０は、各チームのポイントのランキングが２００位以内のユーザに、メッセージ送信権限を
有に設定している。つまり、図２０に示すように、サーバ２０は、各チームの「大将」、「副将」、「五千人将」、「三千人将」、「千人将」、「五百人将」、「百人将」、「組頭」の称号が付与されたユーザに対して、メッセージ送信権限を「１」（有）に設定し、「伍長」「足軽」の称号が付与されたユーザのメッセージ送信権限を「０」（無）に設定する。
【０１５２】
例えば、サーバ２０は、メッセージ送信権限が「０」から「１」に変更されたユーザに対して、図２１に示すように、メッセージ送信権限が付与されたことを示す情報を当該ユーザの端末１０の表示部に表示してもよい。
【０１５３】
また、サーバ２０は、メッセージ送信権限が「１」から「０」に変更されたユーザに対して、図２２に示すように、メッセージ送信権限が消失されたことを示す情報を当該ユーザの端末１０の表示部に表示してもよい。
【０１５４】
図２３は、メッセージ送信権限が「１」のユーザの端末１０において、表示されるチャット画面の一例を示す。図２４は、メッセージ送信権限が「０」のユーザの端末１０において、表示されるチャット画面の一例を示す。
【０１５５】
つまり、メッセージ送信権限が「１」のユーザは、図２３に示すように、所属するチームのチャット画面において、ユーザのメッセージを送信することができる。例えば、メッセージ送信権限フラグが「１」のユーザは、所属するチームのチャット画面において、メッセージを入力欄Ｄ１に入力し、送信ボタンＤ２をタッチ入力することで、自身のメッセージをサーバ２０に送信し、チャットすることができる。このチャット画面は、チームの出演者（総大将）に送信するものであるので、ユーザは、出演者に対して親近感を感じることができ、イベントを一層楽しむことができる。
【０１５６】
なお、サーバ２０は、イベント期間内において、メッセージ送信権限が「１」のユーザの端末からのメッセージを受信可能に制御してもよいし、特に時期的な制限を設けることなく、メッセージ送信権限が「１」のユーザの端末からのメッセージを受信可能に制御してもよい。
【０１５７】
一方、メッセージ送信権限が「０」のユーザは、図２４に示すように、端末１０において、所属するチームのチャット画面において、メッセージを入力することができないが、他のユーザのメッセージ等を含むチャット画面を閲覧することはできる。
【０１５８】
なお、端末１０の表示部や会場のスクリーンに、メッセージ毎に、メッセージを送信したユーザ名（ユーザＩＤ、ニックネーム等でもよい）、メッセージ、送信日時に関する情報が表示される。
【０１５９】
４．１５  領地取得
イベント会場にいる出演者は、ミニゲーム実施終了後、所属するチームの出演者のミニゲームの結果と、チームに所属するユーザの予想情報（ベット）の結果とに基づいて、点数Ｙを算出し、各チームは、点数Ｙに応じて領地を取得する。本実施形態では、予想ゲーム毎に、点数Ｙを算出する。
【０１６０】
まず、点数Ｙの算出手法について説明する。本実施形態では、出演者のミニゲームのゲーム結果の点数Ｘ１及び、チームに所属しているユーザの予想情報の的中度合いの点数Ｘ２に基づき、点数Ｙを算出する。なお、各チームのＹの初期値は０点である。
【０１６１】
まず、予想ゲームで実施されたミニゲームのゲーム結果が１位のチームのＸ１の値を４
点とする。また、２位のチームのＸ１の値を３点とする。また、３位のチームのＸ１の値を２点とする。また、４位のチームのＸ１の値を１点とする。
【０１６２】
例えば、図１７に示すように、予想ゲーム１においてミニゲームのゲーム結果が１位のチームは青チームであるので、青チームのＸ１の値に４点を設定する。また、予想ゲーム１においてミニゲームのゲーム結果が２位のチームは赤チームであるので、赤チームのＸ１の値に３点を設定する。また、予想ゲーム１においてミニゲームのゲーム結果が３位のチームは緑チームであるので、緑チームのＸ１の値に２点を設定する。また、予想ゲーム１においてミニゲームのゲーム結果が４位のチームは黄チームであるので、黄チームのＸ１の値に１点を設定する。
【０１６３】
また、予想ゲームにおいて、各チームのユーザの加算ポイントの合計値を集計し、加算ポイントの合計値が最も高いチームのＸ２の値を４点とする。また、当該合計値が２位のチームのＸ２の値を３点とする。また、３位のチームのＸ２の値を２点とする。また、４位のチームのＸ２の値を１点とする。
【０１６４】
例えば、予想ゲーム１において、青チームに所属するユーザの加算ポイントの合計値が２００，０００，０００ポイントで最も高いチームである場合、青チームのＸ２の値に４点を設定する。また、予想ゲーム１において、緑チームに所属するユーザの加算ポイントの合計値が１９０，０００，０００ポイントで２番目に高いチームである場合、緑チームのＸ２の値に３点を設定する。また、予想ゲーム１において、黄チームに所属するユーザの加算ポイントの合計値が１８０，０００，０００ポイントで３番目に高いチームである場合、黄チームのＸ２の値に２点を設定する。また、予想ゲーム１において、赤チームに所属するユーザの加算ポイントの合計値が１７０，０００，０００ポイントで４番目に高いチームである場合、赤チームのＸ２の値に１点を設定する。そして、図２５に示すように、各チームのＸ１とＸ２との合計値を点数Ｙとする。
【０１６５】
領地取得について図２６を用いて具体的に説明する。本実施形態では、図２６に示すように、日本地図を模した複数の領地（マス目）を用意する。各チームは、点数Ｙに応じて空きの領地や他チームの領地を獲得することができる。
【０１６６】
本実施形態では、自チームの点数Ｙから１点を減算して、自チームの１つの領地を取得することができる。なお、初めて取得する領地は、任意の箇所とすることができるが、２つ目移行に取得する領地は、既に獲得した領地に隣接する領地であることが条件となる。なお、他のチームの領地を自チームの領地とする場合には、点数Ｙから２点を減算して、他のチームの領地を自チームの領地として獲得することができる。なお、本実施形態では、各チームの出演者の指示に基づいて、領地を取得する。
【０１６７】
図２６は、端末１０に表示される各チームの領地獲得状況を示す画面の一例を示す。例えば、ＡＢは青チームの獲得領地数であり、点数Ｙが８点であるので青チームは８つの領地数を獲得していることを示す。ＡＲは赤チームの獲得領地数であり、赤チームは、点数Ｙが４点であるので４つの領地数を獲得していることを示す。ＡＧは緑チームの獲得領地数であり、緑チームは、点数Ｙが５点であるので５つの領地数を獲得していることを示す。ＡＹは黄チームの獲得領地数であり、黄チームは点数が３点であるので３つの領地数を獲得していることを示す。なお、領地獲得状況を示す画面は、会場のスクリーンにおいて表示してもよい。
【０１６８】
また、図２６に示すように、獲得領地数の多い順に、各チームの順位を表示する。予想ゲーム１の終了時点では、青チームが１位、緑チームが２位、赤チームが３位、黄チームが４位であることを示している。
【０１６９】
本実施形態のイベントでは、第Ｎの予想ゲームの後に次の第Ｎ＋１の予想ゲームが開始される。第Ｎ＋１の予想ゲームでは、第Ｎの予想ゲームにおいての領地獲得の状況から、領地を獲得することになる。例えば、予想ゲーム２の終了後、各チームは、予想ゲーム２の点数Ｙに基づいて、予想ゲーム１終了時に獲得した領地に隣接する領地を獲得する。
【０１７０】
このように、各チームは予想ゲームを繰り返し行い、最終的に、予想ゲーム８の終了時に最も多い領地を獲得したチームが優勝する。
【０１７１】
４．１６  フローチャート
本実施形態のサーバ２０の処理の流れを図２７Ａ、図２７Ｂを用いて説明する。まず、図２７Ａに示すように、Ｎに１を代入する（ステップＳ１）。そして、第Ｎの事象（例えば、第Ｎの予想ゲームのミニゲームのゲーム結果）の予想受付期間の開始時刻が到来したか否かを判断する（ステップＳ２）。第Ｎの事象の予想受付期間の開始時刻が到来した場合（ステップＳ２のＹ）、ユーザ毎に、ユーザの仮想通貨（ユーザが所有する仮想通貨）を消費することを条件に第Ｎの事象の予想情報を受け付ける（ステップＳ３）。そして、第Ｎの事象の予想受付期間の終了時刻が到来したか否かを判断する（ステップＳ４）。第Ｎの事象の予想受付期間の終了時刻が到来した場合（ステップＳ４のＹ）、第Ｎの事象の予想情報の受け付けを終了する（ステップＳ５）。なお、第Ｎの事象の予想受付期間の終了時刻が到来していない場合（ステップＳ４のＮ）、ステップＳ３に戻る。
【０１７２】
次に、図２７Ｂに示すように、現実世界において第Ｎの事象が発生したか否かを判断する（ステップＳ１０）。第Ｎの事象が発生した場合（ステップＳ１０のＹ）、ユーザ毎に、ユーザの予想情報と現実世界の第Ｎの事象とに基づいて、ユーザの加算値を算出する（ステップＳ１１）。そして、ユーザ毎に、ユーザの加算値をユーザのポイントに加算する（ステップＳ１２）。そして、各チームにおいて、ポイントの高い順にランキングする（ステップＳ１３）。
【０１７３】
そして、各チームにおいて、２００位以内のユーザに、メッセージ送信権限を有に設定し、２０１位以上のユーザに、メッセージ送信権限を無に設定する（ステップＳ１４）。そして、Ｎ＝８であるか否かを判断し（ステップＳ１５）、Ｎ＝８である場合（ステップＳ１５のＹ）は、処理を終了し、Ｎ＝８でない場合、Ｎに１を加算し（ステップＳ１６）、ステップＳ２に戻る。以上で処理が終了する。
【０１７４】
４．１７  会場のスクリーン
本実施形態の会場では、青チーム、赤チーム、黄チーム、緑チームそれぞれのチーム用のスクリーン（チーム画面）や、メインのスクリーン（メイン画面）を設けてもよい。
【０１７５】
例えば、チーム用のスクリーンでは、各チームのチャット画面を表示し、メインのスクリーンでは、現在の各チームの順位や領地数等の領地獲得状況を示す画面を表示する。
【０１７６】
４．１８  クラウドファンディング
本実施形態では、ユーザの入力情報に基づき、出演者に対して投資額を設定して、投資を行うようにしてもよい。例えば、サーバ２０が、ユーザから複数の出演者の中から一の出演者の選択を受け付け、選択された出演者に対して、ユーザが指定する投資額（例えば、１０００円）を付与する。このとき、サーバ２０は、ユーザの指定する投資額の決済処理を行う。出演者の目標投資額（例えば、１０万円）に到達した場合に、当該出演者の投資受付を終了する。このようにすれば、出演者のファンのユーザは、具体的に投資によって応援することができ、更にイベントを楽しむことができる。なお、サーバ２０は、ユーザの投資額に応じて、ユーザのポイントを上昇させるようにしてもよいし、ユーザの投資
額に応じて、ユーザの仮想通貨を上昇させるようにしてもよい。
【０１７７】
４．１９  投票
本実施形態では、ユーザの投票に基づいて、予想ゲームの開始前に、イベントに出演させる出演者を決定してもよい。例えば、２０人存在するアイドルの中から、投票数の多い１０人のアイドルを、イベントに出演させるようにしてもよい。
【０１７８】
４．２０  その他
本実施形態では、各予想ゲームの予想受付は、予想ゲームの予想受付期間に限らず、予想受付期間開始前から当該予想ゲームの予想受付を行ってもよい。例えば、イベント期間の開始前に、各予想ゲームの予想受付を行ってもよい。
【０１７９】
５．ユーザ情報の管理
５．１  概要
本実施形態では、図３に示すように、出演者の属性やイベントの属性に応じて種々のイベントを開催することができる。上述したように、プラットフォームＰＦにおいて、出演者の属性を現実世界に存在するアイドルとし、イベントの属性をバトルとする例について説明したが、出演者の属性を芸人とし、イベントの属性をクイズとするイベントを開催してもよい。また、出演者の属性をアイドルと、イベントの属性をスポーツとするイベントを開催してもよい。このように、本実施形態のプラットフォームＰＦにおいて、複数の種類のイベントを実現することができる。
【０１８０】
本実施形態のサーバ２０は、各ユーザの好みの考慮したイベント運営を行い、イベント運営の向上が図れるよう、ユーザ情報を管理する。以下、詳細に説明する
５．２  出演者の属性
出演者とは、アイドル、芸人、タレント、女優、俳優、音楽家、アスリート、アナウンサーなど、一般人よりも知名度が高い人を意味する。
【０１８１】
出演者の属性とは、出演者の種類（種別、職種等）を意味する。例えば、図３に示すように、「アイドル」、「芸人」、「タレント」のように、サーバ２０が予め出演者の属性を定める。
【０１８２】
なお、出演者の属性は、出演者を識別するための識別情報でもよい。例えば、サーバ２０が予め定める出演者の氏名を出演者の属性としてもよい。
【０１８３】
５．３  イベントの属性
イベントとは、催し物、行事のことである。特に、本実施形態のイベントは、会場に出演者を招致し、出演者に競技やミニゲームを行わる。また、本実施形態のイベントは、会場内または会場外のユーザが出演者によって発生する事象（ミニゲームのゲーム結果、競技結果等）を予想する予想ゲームを行うことが可能なイベントである。
【０１８４】
イベントの属性とは、イベントの種類（種別）を意味する。例えば、図３に示すように、「バトル」、「クイズ」、「スポーツ」のように、サーバ２０が予めイベントの属性を定める。
【０１８５】
なお、イベントの属性は、イベントを識別するための識別情報でもよい。例えば、サーバ２０が予め定めるイベント名をイベントの属性としてもよい。
【０１８６】
５．４  ユーザ情報
本実施形態では、ユーザ情報をユーザ情報記憶部２７３に記憶する。具体的には、以下
の情報を記憶する。
【０１８７】
（１）基本情報
本実施形態では、ユーザ登録時にユーザ情報の基本情報を登録する。例えば、基本情報とは、ユーザＩＤ、ユーザ名、ニックネーム、性別、年齢、生年月日、ユーザ登録日、フレンド関係にあるフレンド（フレンドのユーザのＩＤ）等であり、サーバ２０は、ユーザの端末１０からの入力情報に基づき、基本情報をユーザ情報記憶部２７３に記憶する。
【０１８８】
（２）ログイン履歴
ログイン履歴は、ユーザからのサーバ２０へのログインの履歴であり、ユーザの参加状況の一例である。例えば、図２８に示すように、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ログイン日時をユーザ情報記憶部２７３に蓄積して記憶する。
【０１８９】
（３）参加回数、参加態様、参照ページ
参加回数、参加態様、参照ページは、ユーザの参加状況の一例である。本実施形態のサーバ２０は、ログイン履歴に基づき、ユーザ毎に、イベントの属性又は出演者の属性に対応付けて、所定期間の参加回数（ログイン回数）を算出する。所定期間とは、例えば、イベント期間でもよいし、所定の１日の期間でもよいし、ユーザ登録日から現時点までの期間でもよい。このようにすれば、ユーザが所定期間に、どのイベントの属性にどのくらい参加したのか、どの出演者の属性にどのくらい参加したのかを認識することができる。なお、サーバ２０は、ユーザ毎に、算出された所定期間の参加回数（ログイン回数）を、イベントの属性又は出演者の属性に対応付けて、ユーザ情報記憶部２７３に記憶してもよい。
【０１９０】
また、本実施形態のバトルのイベントの場合、「予想」、「チャット」、「クラウドファンディング」、「投票」の４つの参加態様がある。サーバ２０は、図２９に示すように、ユーザ毎に、イベントの属性及び出演者の属性、所与の時刻に対応付けて、ユーザの参加態様をユーザ情報記憶部２７３に蓄積して記憶する。例えば、サーバ２０は、所定の周期（５分毎）に、当該ユーザの参照ページから参加態様を特定し、ユーザ情報記憶部２７３に記憶する。このようにすれば、ユーザがどの時点で、どの属性のイベント、どの出演者の属性で、どのような参加態様で参加していたのか等を認識することができる。なお、サーバ２０は、予め作成されたページ毎に、参加態様を設定する。
【０１９１】
また、本実施形態のサーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性、参照時刻に対応付けて、ユーザの参照ページをユーザ情報記憶部２７３に蓄積して記憶する。つまり、サーバ２０は、ユーザの端末１０からアクセスされた参照ページ（Ｗｅｂページ等）のログ履歴（アクセスログ）をユーザ情報記憶部２７３に記憶する。このようにすれば、ユーザがどの時点で、どのページを見ていたのか等を認識することができる。
【０１９２】
（４）決済情報
決済情報は、ユーザの参加状況の一例である。決済情報とは、例えば、課金額である。例えば、図３０に示すように、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、課金額をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性にどのくらい課金したのか、どの出演者の属性にどのくらい課金したのかを認識することができる。なお、サーバ２０は、課金額に対応付けて課金された日時も記憶してもよい。また、サーバ２０は、課金額に対応付けて、課金対象の項目（仮想通貨、クラウドファンディング）等の種類も記憶してもよい。
【０１９３】
（５）予想情報
予想情報は、ユーザの参加状況の一例である。予想情報とは、例えば、予想ゲームにおいてユーザが予想した情報を示す予想情報である。
【０１９４】
例えば、図３１に示すように、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、予想情報をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性に何回予想したのか、どの出演者の属性に何回予想したのか、賭け額はいくらか等を認識することができる。なお、サーバ２０は、予想情報が確定された日時も記憶してもよい。
【０１９５】
（６）ポイントの更新履歴
ポイントは、ユーザの参加状況の一例である。ポイントが高いほど、ユーザが熱心に参加していることがわかる。
【０１９６】
また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザのポイントが更新される度に、更新後のユーザのポイントをユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性にポイントが変化したのか、どの出演者の属性のときにポイントが変化したのかを認識することができる。なお、サーバ２０は、ポイント更新日時も記憶してもよい。
【０１９７】
（７）投票履歴
投票履歴は、ユーザの参加状況の一例である。投票数が高いほど、ユーザが熱心に参加していることがわかる。
【０１９８】
また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザが投票した出演者をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性又は出演者の属性に、どの出演者に投票したのかを認識することができる。なお、サーバ２０は、投票日時も記憶してもよい。
【０１９９】
（８）クラウドファンディングの履歴
また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザがクラウドファンディングで投資した出演者をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性に投資したのか、どの出演者の属性に投資したのかを認識することができる。なお、サーバ２０は、投資日時も記憶してもよい。
【０２００】
（９）ＳＮＳ投稿履歴
ＳＮＳ投稿履歴は、ユーザの参加状況の一例である。ＳＮＳ投稿が多いほど、ユーザが多くの人にイベントに関する情報を知らせようとしていることがわかる。
【０２０１】
また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザが投稿したＳＮＳサイトをユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性のときにＳＮＳサイトを利用したのか、どの出演者の属性のときにＳＮＳサイトを利用したのかを認識することができる。なお、サーバ２０は、投稿日時や投稿したＳＮＳサイトの種別も記憶してもよい。
【０２０２】
５．５  ユーザ毎に、特定のイベントの属性、特定の出演者の属性を抽出する処理の説明
本実施形態のサーバ２０は、ユーザ毎に、ユーザ情報記憶部２７３に記憶されているユーザの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する。
【０２０３】
また、サーバ２０は、ユーザ毎に、ユーザ情報記憶部２７３に記憶されているユーザの参加状況に基づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する。以下、具体例を説明する。
【０２０４】
（１）過去に参加したイベント
サーバ２０は、ログイン履歴等に基づき、ユーザ毎に、ユーザが過去に参加したイベントの属性や、ユーザが過去に参加したイベントに出演した出演者の属性を抽出してもよい。
【０２０５】
（２）参加回数
例えば、サーバ２０は、ユーザ毎に、複数のイベントの属性の中から参加回数が所定回数以上のイベントの属性や出演者の属性を抽出してもよい。
【０２０６】
つまり、ユーザＰ１が、バトルのイベントの参加回数が１０回以上であり、他の属性のイベント（例えば、クイズ、スポーツのイベント）の参加回数が１０回未満である場合、ユーザＰ１に対して、バトルに関するイベントを告知することが望ましい。本実施形態のサーバ２０によれば、ユーザＰ１にバトルの属性を抽出することができるので、ユーザＰ１にバトルに関するイベントを告知することができる。つまり、本実施形態によれば、ユーザの好みに適したイベントの属性を知ることができ、イベントの属性に特化した集客を行うことができる。
【０２０７】
また、ユーザＰ２が、出演者の属性がアイドルである場合の参加回数が１０回以上であり、他の属性の出演者（例えば、芸人、音楽家の参加回数）である場合の参加回数が１０回未満である場合、ユーザＰ２に対して、アイドルに関するイベントを告知することが望ましい。本実施形態のサーバ２０によれば、ユーザＰ２にアイドルの属性を抽出することができるので、ユーザＰ２にアイドルに関するイベントを告知することができる。つまり、本実施形態によれば、ユーザの好みに適した出演者の属性を知ることができ、出演者の属性に特化した集客を行うことができる。
【０２０８】
（２）課金額
また、サーバ２０は、ユーザ毎に、複数のイベントの属性の中から課金額が所定額以上のイベントの属性や出演者の属性を抽出してもよい。
【０２０９】
例えば、ユーザＰ３が、バトルのイベントの課金額が１０００円以上であり、他の属性のイベント（例えば、クイズ、スポーツのイベント）の課金額が１０００円未満である場合、ユーザＰ３に対して、バトルに関するイベントを告知することが、イベント事業者にとって運営上望ましい。本実施形態のサーバ２０によれば、ユーザＰ３にバトルの属性を抽出することができるので、ユーザＰ３にバトルに関するイベントを告知することができる。
【０２１０】
また、ユーザＰ４が、出演者の属性がアイドルである場合のイベントの課金額が１０００円以上であり、他の属性の出演者（例えば、芸人、音楽家）であるときの課金額が１０００円未満である場合、ユーザＰ４に対して、アイドルに関するイベントを告知することが望ましい。本実施形態のサーバ２０によれば、ユーザＰ４にアイドルの属性を抽出することができるので、ユーザＰ４にアイドルに関するイベントを告知することができる。
【０２１１】
（３）予想回数
また、サーバ２０は、ユーザ毎に、複数のイベントの属性の中から予想回数が所定回数以上のイベントの属性や出演者の属性を抽出してもよい。なお、ユーザの予想回数は、ユ
ーザの予想情報に基づき特定することができる。
【０２１２】
例えば、ユーザＰ５が、バトルのイベントの予想回数が１０回以上であり、他の属性のイベント（例えば、クイズ、スポーツのイベント）の予想回数が１０回未満である場合、ユーザＰ５に対して、バトルに関するイベントを告知することが、ユーザＰ５が意欲的にイベントに参加でき望ましい。本実施形態のサーバ２０によれば、ユーザＰ５にバトルの属性を抽出することができるので、ユーザＰ５にバトルに関するイベントを告知することができる。
【０２１３】
また、ユーザＰ６が、出演者の属性がアイドルである場合のイベントの予想回数が１０回以上であり、他の属性の出演者（例えば、芸人、音楽家）であるときのイベントの予想回数が１０回未満である場合、ユーザＰ６に対して、アイドルに関するイベントを告知することが、ユーザＰ６が意欲的にイベントに参加でき望ましい。本実施形態のサーバ２０によれば、ユーザＰ６にアイドルの属性を抽出することができるので、ユーザＰ６にアイドルに関するイベントを告知することができる。
【０２１４】
（４）ユーザ及び当該ユーザのフレンド
また、サーバ２０は、ユーザ毎に、ユーザ及び当該ユーザのフレンドの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する処理を行ってもよい。例えば、ユーザＰ１とユーザＰ２とがフレンド関係にある場合、ユーザＰ１及びユーザＰ２が参加したイベントを抽出する処理を行う。
【０２１５】
また、サーバ２０は、ユーザ毎に、ユーザ及び当該ユーザのフレンドの参加状況に基づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する処理を行ってもよい。例えば、ユーザＰ１とユーザＰ２とがフレンド関係にある場合、ユーザＰ１及びユーザＰ２が参加したイベントに出演した出演者を抽出する処理を行う。
【０２１６】
（５）通知（告知）
本実施形態のサーバ２０は、ユーザ毎に、ユーザに対して抽出されたイベントの属性に関する情報（例えば、イベントの開催日時や内容）を、通知（告知）するようにしてもよい。
【０２１７】
本実施形態のサーバ２０は、ユーザ毎に、ユーザに対して抽出された出演者の属性に関する情報（例えば、抽出された出演者が出演するイベントの開催日時や内容）を、通知（告知）するようにしてもよい。
【０２１８】
なお、通知とは、告知を意味し、例えば、サーバ２０がユーザの端末１０にメッセージを通知してもよいし、ログイン後のユーザ端末１０に、当該ユーザに対して抽出されたイベントの属性に関する情報や出演者の属性に関する情報を表示するようにしてもよい。
【０２１９】
５．６  フィルタリング
本実施形態のサーバ２０は、ユーザの参加状況に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行ってもよい。
【０２２０】
（１）ログイン回数
例えば、サーバ２０は、ユーザのログイン回数に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行うようにしてもよい。例えば、ユーザのログイン回数が１０回以上という条件に該当するユーザを抽出するようにしてもよい。このようにすれば、ログイン回数に基づき、イベントに意欲的に参加するユーザを抽出することができる。
【０２２１】
（２）予想情報
また、サーバ２０は、ユーザの予想ゲームの予想情報に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行うようにしてもよい。例えば、ユーザの予想回数が１０回以上という条件に該当するユーザを抽出するようにしてもよい。このようにすれば、予想回数に基づき、予想ゲームに意欲的に参加するユーザを抽出することができる。
【０２２２】
（３）決済情報
また、サーバ２０は、ユーザの決済情報に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行うようにしてもよい。例えば、ユーザの課金額が１００００円以上という条件に該当するユーザを抽出するようにしてもよい。このようにすれば、課金を多く行う傾向にあるユーザを抽出することができる。
【０２２３】
（４）その他
また、サーバ２０は、フィルタリング条件を種々に設定することができる。例えば、特定のイベントの属性や、特定の出演者の属性をフィルタリングの条件に加えてもよい。
【０２２４】
５．７  ユーザの動向調査
本実施形態のサーバ２０は、ユーザ情報記憶部２７３に記憶されている各ユーザの参加状況に基づいて、ユーザの動向を調査する処理を行ってもよい。サーバ２０において、調査された内容は、イベント事業者のイベントの企画や運営する上で重要なデータとなる。
【０２２５】
（１）イベントの参加態様
例えば、サーバ２０は、ユーザ毎に、特定時点でのユーザのイベントの参加態様を特定するようにしてもよい。例えば、サーバ２０は、各ユーザのバトルの属性のイベントの結果発表時点での、ユーザのイベントの参加態様を特定し、どのような参加態様が多かったのかを判断するようにしてもよい。
【０２２６】
（２）参照ページ
また、サーバ２０は、ユーザ毎に、特定時点でのユーザの参照ページを特定するようにしてもよい。例えば、サーバ２０は、各ユーザの予想ゲーム開始前の特定のタイミングにおいて、各ユーザの参照ページを特定し、各ユーザがどのような内容のページに関心があるのか、を判断するようにしてもよい。
【０２２７】
（３）フレンド
また、サーバ２０は、ユーザ毎に、特定時点でのユーザ及び当該ユーザのフレンドの参加態様及び参照ページの少なくとも一方を特定するようにしてもよい。例えば、サーバ２０は、ユーザとそのフレンドとの参加態様及び参照ページの少なくとも一方を特定することによって、ユーザとそのフレンドが、どのようなことに興味、関心があるのかを、判断するようにしてもよい。
【０２２８】
５．７  フローチャート
サーバ２０の処理の一例を、図３２を用いて説明する。まず、サーバ２０は、Ｎに１を代入する（ステップＳ２１）。そして、第Ｎのユーザの参加状況に基づいて、第Ｎのユーザに対して、特定のイベントの属性を抽出する（ステップＳ２２）。第Ｎのユーザに対して、抽出されたイベントの属性に関する情報を告知する（ステップＳ２３）。
【０２２９】
そして、サーバ２０は、第Ｎのユーザの参加状況に基づいて、第Ｎのユーザに対して、特定の出演者の属性を抽出する（ステップＳ２４）。第Ｎのユーザに対して、抽出された出演者の属性に関する情報を告知する（ステップＳ２５）。そして、全ユーザについて処理したか否かを判断し（ステップＳ２６）、全ユーザについて処理をしていない場合（ス
テップＳ２６のＮ）、Ｎに１を加算し（ステップＳ２７）、ステップＳ２２に戻る。全ユーザについて処理した場合（ステップＳ２６のＹ）、処理を終了する。
【０２３０】
６．その他
本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語として引用された用語は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。
【符号の説明】
【０２３１】
１  ゲームシステム、１０  端末、２０  サーバ、
ＰＦ  プラットフォーム、
１００  処理部、１１０  ユーザ登録部、１１１  チーム決定部、１１２  予想情報制御部、１１３  設定部、１３０  画像生成部、１４０  音生成部、１６０  入力部、１６２
検出部、１７０  記憶部、１７１  主記憶部、１７２  画像バッファ、１８０  情報記憶媒体、１９０  表示部、１９２  音出力部、１９６  通信部、
２００  処理部、２１０  参加制御部、２１１  仮想通貨制御部、２１２  予想情報受付部、２１３  判断部、２１４  パラメータ制御部、２１５  設定部、２１６  進行制御部、２１７  ユーザ情報管理部、２１８  抽出処理部、２１９  動向調査部、２２０  決済制御部、２２１  動画配信部、２２２  ＳＮＳ制御部、２２３  クラウドファンディング制御部、２７０  記憶部、２７２  主記憶部、２７３  ユーザ情報記憶部、２８０  情報記憶媒体、２９６  通信部
【図１】
2018128788.tif 000003
【図２】
2018128788.tif 000004
【図３】
2018128788.tif 000005
【図４】
2018128788.tif 000006
【図５】
2018128788.tif 000007
【図６】
2018128788.tif 000008
【図７】
2018128788.tif 000009
【図８】
2018128788.tif 000010
【図９】
2018128788.tif 000011
【図１０】
2018128788.tif 000012
【図１１】
2018128788.tif 000013
【図１２】
2018128788.tif 000014
【図１３】
2018128788.tif 000015
【図１４】
2018128788.tif 000016
【図１５】
2018128788.tif 000017
【図１６】
2018128788.tif 000018
【図１７】
2018128788.tif 000019
【図１８】
2018128788.tif 000020
【図１９】
2018128788.tif 000021
【図２０】
2018128788.tif 000022
【図２１】
2018128788.tif 000023
【図２２】
2018128788.tif 000024
【図２３】
2018128788.tif 000025
【図２４】
2018128788.tif 000026
【図２５】
2018128788.tif 000027
【図２６】
2018128788.tif 000028
【図２７Ａ】
2018128788.tif 000029
【図２７Ｂ】
2018128788.tif 000030
【図２８】
2018128788.tif 000031
【図２９】
2018128788.tif 000032
【図３０】
2018128788.tif 000033
【図３１】
2018128788.tif 000034
【図３２】
2018128788.tif 000035