JP2018151743A - プログラム、サーバ及びゲームシステム - Google Patents

Abstract

【課題】イベントの進行に応じて複数のキーワードを提示でき、ユーザはキーワードを含むメッセージを簡単に入力することが可能なプログラム、サーバ及びゲームシステムを提供すること。
【解決手段】ユーザからのメッセージを受け付け、チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チームに所属する各ユーザの端末に提示する。そして、チーム毎に、イベントの進行に応じてユーザが選択可能な複数のキーワードの候補を提示し、複数のキーワードの候補の中からユーザによって選択されたキーワードをメッセージの一部として受け付ける。
【選択図】図４５

Description

本発明は、プログラム、サーバ及びゲームシステムに関する。

アイドルや芸人などの出演者が、会場でミニゲームや競技を行って順位を競うイベントを開催することがある。例えば、出演者のファンであるユーザがイベントの会場に出向いてアイドルのミニゲームのプレイ等を観覧し楽しむ。また、会場にいないユーザも、ユーザの端末のディスプレイに表示されたイベントの動画を閲覧して楽しむことがある。

また、従来技術では、動画データに対して一の視聴者により送信（投稿）されたメッセージ（コメント）を、他の視聴者の端末において当該動画データの再生時に表示するものが存在する（特許文献１の０００９段落等参照）。

また、従来技術では、ＳＮＳサーバや管理サーバにおいて、投稿されたメッセージ（内容）を記憶部に記憶し、ユーザ同士が投稿されたメッセージを閲覧できるサービスが存在する（特許文献２の００２７段落参照）。

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

特許文献１に示す従来技術のメッセージ送信機能は、視聴者同士が動画データに対する意識や感想を共有することができ、動画視聴の面白みを高めている。しかし、特許文献１に示す従来技術は、メッセージの送信機能について制限はなく、メッセージが煩雑化しているという問題があった。

また、特許文献２に示す従来技術は、ユーザが投稿したメッセージにおいて感情の種類に応じたキーワードを特定できた場合に、特定できた感情に応じたモーションを情報に基づき、当該ユーザの画像のモーションを設定することが開示されている。しかし、特許文献２に示す従来技術は、ユーザ自身の感情をモーションで表現できたとしても、イベントの進行に応じて複数のキーワードを提示でき、ユーザがキーワードを含むメッセージを簡単に入力することができない、という問題がある。

本発明は、以上の課題に鑑みてなされたものであり、その目的とするところは、イベントの進行に応じてユーザが選択可能な複数のキーワードを提示でき、ユーザがキーワードを含むメッセージを簡単に入力することが可能なプログラム、サーバ及びゲームシステムを提供することにある。

（１）本発明は、
複数のチームが順位を競うイベントに関するサービスを提供するサーバのためのプログラムであって、
ユーザからのメッセージを受け付けるメッセージ受付部と、
チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チームに所属
する各ユーザの端末に提示する提示部として、コンピュータを機能させ、
前記提示部が、
チーム毎に、前記イベントの進行に応じて前記ユーザが選択可能な複数のキーワードの候補を提示し、
前記メッセージ受付部が、
前記複数のキーワードの候補の中からユーザによって選択されたキーワードを前記メッセージの一部として受け付けるプログラムに関する。

また、本発明は、コンピュータ読み取り可能な情報記憶媒体であって、上記各部としてコンピュータを機能させるための上記プログラムを記憶した情報記憶媒体に関する。また、本発明は、上記各部を含むサーバに関する。

本発明によれば、イベントの進行に応じてユーザが選択可能な複数のキーワードの候補を提示することができる。そして、本発明によれば、提示された複数のキーワードの候補の中から、ユーザがメッセージに含ませたいキーワードを選択できるので、ユーザはキーワードを含むメッセージを簡単に入力することができる。

（２）また、本発明のプログラム、情報記憶媒体、及びサーバは、
前記メッセージ受付部が受け付けた前記メッセージを蓄積して記憶部に記憶し、チーム毎に、前記イベントの進行に応じた期間の前記メッセージから前記キーワードを抽出するキーワード抽出部と
チーム毎に、前記キーワード抽出部により抽出される前記キーワードの抽出数の多い順に並べて前記キーワードのランキングを行うキーワードランキング部として、コンピュータを更に機能させ、
前記提示部が、
チーム毎に、前記キーワードのランキングの結果を提示するようにしてもよい。

本発明によれば、ユーザはイベントの進行に応じた期間において注目されているキーワードを把握することができる。

（３）また、本発明のプログラム、情報記憶媒体、及びサーバは、
前記提示部が、
チーム毎に、ランキング上位のキーワードを、候補の１つとするようにしてもよい。

本発明によれば、注目されているキーワードを候補として提示することができる。したがって、本発明によれば、ユーザは、注目されているキーワードを選択すれば、当該キーワードを含むメッセージを簡単に入力することができる。

（４）また、本発明のプログラム、情報記憶媒体、及びサーバは、
前記提示部が、
前記メッセージ受付部が受け付けた前記メッセージに含まれるキーワードを、識別して提示するようにしてもよい。

本発明によれば、キーワードが識別して提示されるので、ユーザはメッセージからキーワードを瞬時に把握できる。

（５）また、本発明は、
複数のチームが順位を競うイベントに関するサービスを提供するサーバと、各チームに所属する各ユーザの端末とが、ネットワークを介して接続されるゲームシステムであって、
前記サーバは、
ユーザからのメッセージを受け付けるメッセージ受付部と、
チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チームに所属する各ユーザの端末に提示する提示部と、を含み、
前記提示部が、
チーム毎に、前記イベントの進行に応じて前記ユーザが選択可能な複数のキーワードの候補を提示し、
前記メッセージ受付部が、
前記複数のキーワードの候補の中からユーザによって選択されたキーワードを前記メッセージの一部として受け付け、
前記各ユーザの前記各端末が、
ユーザからのメッセージを前記サーバに送信するメッセージ送信部と、
前記サーバから提示された前記メッセージを表示する表示制御部と、を含み
前記表示制御部が、
前記サーバから提示された前記複数のキーワードの候補を表示し、
前記メッセージ送信部が、
前記複数のキーワードの候補の中からキーワードの選択を受け付け、選択された当該キーワードを前記メッセージの一部とするゲームシステムに関する。

本実施形態のゲームシステムを示す図。 本実施形態のイベントの概念図の一例を示す図。 本実施形態のゲームシステムのプラットフォームの一例を示す図。 本実施形態の端末１０の機能ブロック図の一例を示す図。 本実施形態のサーバ２０の機能ブロック図の一例を示す図。 本実施形態のイベントの進行に関する時系列の説明図の一例を示す。 本実施形態の予想ゲームの進行に関する時系列の説明図の一例を示す。 本実施形態の出演者の情報の一例。 本実施形態のチームの情報の一例。 本実施形態の予想入力画面の一例。 本実施形態の１位予想におけるベット額設定画面の一例。 本実施形態の賭け率の一例。 本実施形態の１位予想における確認画面の一例。 本実施形態の１位２位予想におけるベット額設定画面の一例。 本実施形態の１位２位予想における確認画面の一例。 本実施形態の各ユーザの予想情報の一例。 本実施形態のミニゲームの結果の一例。 本実施形態の予想ゲームの結果を表示する画面の一例。 本実施形態のポイントのランキングが表示される画面の一例。 本実施形態の称号、係数、メッセージ送信権限に関する対応関係の一例。 本実施形態の端末においてメッセージ送信権限が付与されたことを示す情報が表示される画面の一例。 本実施形態の端末においてメッセージ送信権限が消失されたことを示す情報が表示される画面の一例。 本実施形態のチャット画面の一例。 本実施形態のチャット画面の一例。 本実施形態の領地獲得に関する説明。 本実施形態の領地獲得に関する画面の一例。 本実施形態のサーバ２０が行う処理の一例のフローチャート。 本実施形態のサーバ２０が行う処理の一例のフローチャート。 本実施形態のユーザ情報の一例。 本実施形態のユーザ情報の一例。 本実施形態のユーザ情報の一例。 本実施形態のユーザ情報の一例。 本実施形態のサーバ２０が行う処理の一例のフローチャート。 本実施形態の領地獲得に関する画面の一例。 本実施形態の取得状況に関する情報の一例。 本実施形態の各チームの領地の番号（キーワード）の候補の一例。 本実施形態の領地獲得に関する画面の一例。 本実施形態の領地獲得に関する画面の一例。 本実施形態の領地獲得に関する画面の一例。 本実施形態の領地獲得に関する画面の一例。 本実施形態のチャット画面の一例。 図４１（Ａ）、図４１（Ｂ）、図４１（Ｃ）は、本実施形態のキーワードの選択受け付けに関する説明図。 本実施形態のサーバ２０の記憶部に記憶されるメッセージの一例。 本実施形態の各領地の番号（各キーワード）の抽出数の一例。 本実施形態のチャット画面の一例。 本実施形態のキーワードの候補を提示する処理の流れの一例のフローチャート。 本実施形態のキーワードのランキングに関する処理の流れの一例のフローチャート。 本実施形態のユーザの端末１０の機能ブロック図の一例。 本実施形態のサーバ２０の機能ブロック図の一例。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必要構成要件であるとは限らない。

１．ゲームシステム
本実施形態では、イベントを開催する事業者が、会場に出演者（アイドル、芸人など）やユーザを招致し、ユーザに対してイベントのサービスを提供する例について説明する。なお、出演者のことをキャストと呼んでもよい。

図１は、本実施形態のゲームシステム１を示す。本実施形態では、複数のユーザの端末１０と、事業者が管理するサーバ２０（サーバシステム）とによって構成される。つまり、図１に示すように、本実施形態のゲームシステム１は、サーバ２０と、ユーザの端末１０とが、ネットワーク（例えば、インターネット）を介して接続可能に構成される。

サーバ２０は、イベントで用いるゲームサーバ、ＳＮＳ（ソーシャル・ネットワーキング・サービス）と呼ばれるコミュニティ型のサービスを提供するＳＮＳサーバ等の機能を有している。

ユーザの端末１０は、インターネット（ＷＡＮ）、ＬＡＮなどのネットワークを介してサーバ２０に接続可能な装置である。なお、ユーザの端末１０とサーバ２０との通信回線は、無線であるが有線であってもよい。

また、サーバ２０は、複数の装置（ハードウエア）によって構成されていてもよく、処理の機能やストレージを分散してもよい。

本実施形態のゲームシステム１は、予めユーザ登録を行ったユーザがイベントに参加することができ、ゲームを行うことができる。

また、図２に示すように、事業者が会場に出演者やユーザを招致し、会場内のユーザは、イベントに参加することができる。会場には、大きなスクリーン（表示装置）を設置し、多くのユーザがスクリーンを見て、イベントを撮影した画像、動画や、ゲーム画面を見ることができる。また、会場内のユーザ及び会場外のユーザは、ユーザ登録（ユーザ登録）をすることを条件に、イベント内で実施されるゲーム結果やミニゲームのゲーム結果（事象）を予想するゲームに参加することができ、当該ユーザの端末１０で表示される動画やゲーム画面を見ることができる。

２．ゲームシステムのプラットフォームの構成図
図３は、本実施形態のゲームシステム１のプラットフォームＰＦの構成図の一例を示す。

例えば、プラットフォームＰＦは、ユーザ情報が格納されるデータベースと、決済、動画配信、ＳＮＳ、ベット（賭け）、クラウドファンディングで構成されるシステムとが基盤となる。また、プラットフォームＰＦは、バトル、クイズ、スポーツ等の複数の属性（種類）のイベントから一のイベントのプログラムを動作させ、イベントを開催する。また、プラットフォームＰＦは、アイドル、芸人、タレントなどの属性に応じた出演者がイベント開催中にミニゲームや競技を行い、事象（ミニゲームのゲーム結果、競技結果）が発生する。

事業者は、出演者のファンであるユーザを集客することもできるし、イベントの属性に応じて特定のユーザを集客することもできる。なお、プラットフォームＰＦにおけるイベントをエンジン（特定の処理を行う処理装置やプログラム）と呼んでもよい。

３．構成
３．１ ユーザの端末の構成
図４に本実施形態のユーザの端末１０の機能ブロック図の一例を示す。なお、本実施形態のユーザの端末１０は、図４の構成要素（各部）の一部を省略した構成としてもよい。

入力部１６０は、ユーザからの入力情報を入力するための機器であり、ユーザの入力情報を処理部に出力する。本実施形態の入力部１６０は、ユーザの入力情報（入力信号）を検出する検出部１６２を備える。入力部１６０は、例えば、レバー、ボタン、ステアリング、マイク、タッチパネル型ディスプレイ、キーボード、マウスなどがある。

本実施形態のユーザの端末１０は、タッチパネルへタッチ入力（接触操作）で操作するものであるが、ユーザの端末１０には、ボタン、方向キーなどの操作子（ボタン、方向キー等）を有していてもよい。

また、入力部１６０は、３軸の加速度を検出する加速度センサや、角速度を検出するジャイロセンサ、撮像部を備えた入力機器でもよい。例えば、入力機器は、ユーザが把持して動かすものであってもよいし、ユーザが身につけて動かすものであってもよい。また、入力機器には、ユーザが把持する刀型コントローラや銃型コントローラ、あるいはユーザが身につける（ユーザが手に装着する）グローブ型コントローラなど実際の道具を模して作られたコントローラも含まれる。また入力機器には、入力機器と一体化されているゲーム装置、携帯型ゲーム装置、携帯電話なども含まれる。本実施形態のユーザの端末１０は、複数の入力部１６０を備えていてもよい。

記憶部１７０は、処理部１００の各部としてコンピュータを機能させるためのプログラムや各種データを記憶するとともに、処理部１００や通信部１９６の記憶領域として機能する。

記憶部１７０は、一時的な記憶領域や、ストレージを含む。ストレージとは、ハードディスク、光学ディスク、フラッシュメモリ、磁気テープ等であり、データを永続的に記憶する装置のことをいう。また、記憶部１７０は、情報記憶媒体１８０に格納されているプログラムやデータを記憶してもよい。

そして、本実施形態の記憶部１７０は、ワーク領域として使用される主記憶部１７１と、表示画像等が記憶される画像バッファ１７２とを含む。なお、これらの一部を省略する構成としてもよい。

主記憶部１７１は、ＲＡＭなどにより実現できる。主記憶部１７１は、本実施形態の処理において使用される記憶領域である。画像バッファ１７２は、ＶＲＡＭなどにより実現できる。

情報記憶媒体１８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などにより実現できる。なお、情報記憶媒体１８０はストレージである。

また、情報記憶媒体１８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）を記憶することができる。

なお、サーバ２０が有する情報記憶媒体や記憶部に記憶されているプログラムや各種データを、ネットワークを介して受信し、受信したプログラムやデータを記憶部１７０や情報記憶媒体１８０に記憶してもよい。このようにプログラムや各種データを受信して端末１０の処理部１００の各部としてコンピュータを機能させる場合も本発明の範囲内に含む。なお、処理部１００は、後述するように、記憶部１７０や情報記憶媒体１８０に格納されるプログラムやデータに基づいて本実施形態の種々の処理を行う。

表示部１９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、タッチパネルディスプレイ、或いはＨＭＤ（ヘッドマウントディスプレイ）などにより実現できる。

なお、表示部１９０は、タッチパネルディスプレイを用いることによりユーザが操作を行う入力部１６０としても機能してもよい。ここでタッチパネルとして、例えば抵抗膜方式（４線式、５線式）、静電容量方式、電磁誘導方式、超音波表面弾性波方式、赤外線走査方式などのタッチパネルを用いることができる。

音出力部１９２は、処理部１００で生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。

通信部１９６はサーバ２０との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。

処理部１００（プロセッサ）は、入力部１６０からの操作入力（入力情報）、記憶部１７０や情報記憶媒体１８０に格納されるプログラム及びデータ、通信部１９６を介して受信したデータなどに基づいて、プログラムの実行処理、画像生成処理、音生成処理、などの処理を行う。処理部１００は、記憶部１７０内の主記憶部１７１をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

処理部１００は、ユーザ登録部１１０、チーム決定部１１１、予想情報制御部１１２、設定部１１３、画像生成部１３０、音生成部１４０を含む。

ユーザ登録部１１０は、ユーザの入力に基づき、サーバ２０にユーザの基本情報（ユーザ名等）を送信する処理を行い、ユーザ登録を行う。

チーム決定部１１１は、ユーザの入力情報に基づき、複数のチーム（赤、青、緑、黄のチーム）の中から一のチームの選択を受け付ける処理を行う。チーム決定部１１１は、ユーザが選択したチーム名（チームＩＤ）を、サーバ２０に送信する処理を行う。

予想情報制御部１１２は、ユーザの入力に基づいて予想情報をサーバ２０に送信する。つまり、予想情報制御部１１２は、ユーザの入力情報に基づき、ユーザがベットする出演者と、賭け額を受け付け、ユーザがベットした出演者及び賭け額等を含む予想情報をサーバ２０に送信する処理を行う。

設定部１１３は、サーバ２０から、イベントに関する当該ユーザの参加可能範囲を受信し、当該ユーザの参加可能範囲を設定する。例えば、設定部１１３は、メッセージ閲覧権限が有の場合、メッセージを閲覧可能に設定する。また、設定部１１３は、メッセージ送信権限が有の場合、メッセージを送信可能に設定する。

画像生成部１３０は、処理部１００で行われる種々の処理の結果に基づいて描画処理を行い、これにより画像を生成し、表示部１９０に出力する。画像生成部１３０は、オブジェクト空間内において仮想カメラ（所与の視点）から見える画像（いわゆる３次元画像）を生成してもよい。

例えば、画像生成部１３０は、３次元画像を生成する場合には、まず、座標変換（ワールド座標変換、カメラ座標変換）、クリッピング処理、或いは透視変換等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ（プリミティブ面の頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等）が作成される。そして、この描画データ（プリミティブ面データ）に基づいて、透視変換後（ジオメトリ処理後）のオブジェクト（１又は複数プリミティブ面）を画像バッファ１７２（フレームバッファ、ワークバッファなどのピクセル単位で画像情報を記憶できるバッファ。ＶＲＡＭ）に描画する。これにより、オブジェクト空間内において仮想カメラ（所与の視点）から見える画像が生成される。

音生成部１４０は、処理部１００で行われる種々の処理の結果に基づいて音処理を行い、ＢＧＭ、効果音、又は音声などの音を生成し、音出力部１９２に出力する。

３．２ サーバの構成
図５に本実施形態のサーバ２０の機能ブロック図の一例を示す。なお本実施形態のサーバは図５の構成要素（各部）の一部を省略した構成としてもよい。

記憶部２７０は、処理部２００の各部としてコンピュータを機能させるためのプログラ
ムや各種データを記憶するとともに、処理部２００や通信部２９６の記憶領域として機能する。

記憶部２７０は、一時的な記憶領域や、ストレージを含む。また、記憶部２７０は、情報記憶媒体２８０に格納されているプログラムやデータを記憶してもよい。

そして、本実施形態の記憶部２７０は、ワーク領域として使用される主記憶部２７２と、ユーザ情報記憶部２７３とを含む。なお、これらの一部を省略する構成としてもよい。

主記憶部２７２は、ＲＡＭなどにより実現できる。主記憶部２７２は、本実施形態の処理において使用される記憶領域である。

ユーザ情報記憶部２７３には、サーバ２０が管理するユーザ情報を格納する。例えば、ユーザ情報記憶部２７３には、ユーザＩＤ（ユーザ識別情報）に対応付けて、ユーザに関する情報が記憶される。例えば、ユーザ情報記憶部２７３には、参加状況を含むユーザ情報等が記憶される。

情報記憶媒体２８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などにより実現できる。処理部２００は、情報記憶媒体２８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体２８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。

通信部２９６は外部（例えば、ユーザの端末１０、他のサーバや他のネットワークシステム）との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。

処理部２００（プロセッサ）は、記憶部２７０や情報記憶媒体２８０に記憶されるプログラム及びデータ、通信部２９６を介して受信したデータなどに基づいて、処理を行う。

また、処理部２００は記憶部２７０内の主記憶部２７１をワーク領域として各種処理を行う。処理部２００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

特に、本実施形態のサーバ２０の処理部２００は、参加制御部２１０、仮想通貨制御部２１１、予想情報受付部２１２、判断部２１３、パラメータ制御部２１４、設定部２１５、進行制御部２１６、ユーザ情報管理部２１７、抽出処理部２１８、動向調査部２１９、決済制御部２２０、動画配信部２２１、ＳＮＳ制御部２２２、クラウドファンディング制御部２２３を含む。なお、これらの一部を省略する構成としてもよい。

参加制御部２１０は、ユーザ登録により、出演者が出演するイベントに、ユーザを参加させる。例えば、参加制御部２１０は、端末１０から受信したユーザの基本情報をユーザ情報記憶部２７３に記憶することによって、ユーザ登録を行う。

仮想通貨制御部２１１は、ユーザが所有する仮想通貨の値を制御する。例えば、仮想通貨制御部２１１は、イベントの予想ゲームの予想情報を受け付ける場合に、ベット額（賭け額）に応じた値を、ユーザが所有する仮想通貨から減算する。また、仮想通貨制御部２１１は、ユーザが課金することによって、課金額に応じた値を、ユーザが所有する仮想通
貨に加算する。

予想情報受付部２１２は、イベントに参加したユーザから、事象の予想情報を受け付ける。特に、本実施形態の予想情報受付部２１２は、ユーザの仮想通貨を消費することを条件に、当該ユーザから事象の予想情報を受け付ける。なお、事象は、例えば、イベントの出演者によって発生する事象である。具体的には、イベントの出演者のミニゲームをプレイすることによって発生するゲーム結果や、イベントの出演者の競技をプレイすることによって発生する競技結果等である。

判断部２１３は、事象発生後、予想情報を受け付けたユーザ毎に、ユーザの予想情報と当該事象とに基づいて、ユーザの予想情報が的中したか否かを判断する。

パラメータ制御部２１４は、事象発生後、予想情報を受け付けたユーザ毎に、ユーザの予想情報と事象とに基づいて加算値を算出し、算出した当該加算値を当該ユーザのポイントに加算する。また、パラメータ制御部２１４は、複数種類のイベントにおいて共通のユーザのポイントを用いる。また、パラメータ制御部２１４は、同一のイベントにおいて、事象が発生する度に、各ユーザのポイントを更新する。

設定部２１５は、ユーザ毎に、ユーザのポイントに基づいて、イベントに関する当該ユーザの参加可能範囲を設定する。例えば、設定部２１５は、ユーザ毎に、ユーザのポイントに基づいて、イベントに関する所定の権限の有無を設定する。また、設定部２１５は、ユーザのポイントが初期値である場合、イベントに関する特定の情報の閲覧権限を有に設定し、イベントに関する特定の情報の送信権限を無に設定する。

また、設定部２１５は、事象が発生する度に、更新後の各ユーザのポイントに基づいて、イベントに関する当該ユーザの参加可能範囲を設定する。また、設定部２１５は、各ユーザのポイントに基づいて、出演者に対するメッセージを送信する権限の有無を設定する。

進行制御部２１６は、複数種類のイベントを進行させる。例えば、進行制御部２１６は、同時に複数種類のイベントを進行させてもよいし、複数のイベントを、順番に進行させるようにしてもよい。また、進行制御部２１６は、同一のイベントにおいて、事象が複数回発生するイベントを進行させる。例えば、進行制御部２１６は、同時に複数の事象が発生するイベントを進行させてもよいし、複数の事象が順番に発生するイベントを進行させるようにしてもよい。イベントの進行制御とは、時間軸に沿った制御であり、例えば、イベントの予想ゲームにおいて予想受付期間を定める処理、事象発生後、ポイント演算を開始する制御、等である。

ユーザ情報管理部２１７は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザの参加状況を含むユーザ情報を蓄積してユーザ情報記憶部２７３に記憶する。

抽出処理部２１８は、ユーザ毎に、ユーザの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する処理を行う。また、抽出処理部２１８は、ユーザ毎に、ユーザの参加状況に基づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する処理を行う。

また、抽出処理部２１８は、ユーザの参加状況に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行う。例えば、抽出処理部２１８は、ユーザのログイン回数に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行う。また、抽出処理部２１８は、ユーザの予想ゲームの予想情報に関するフィルタリング条件に該当す
る特定のユーザを抽出する処理を行う。また、抽出処理部２１８は、ユーザの決済情報に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行う。

また、抽出処理部２１８は、ユーザ毎に、ユーザ及び当該ユーザのフレンドの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する処理を行う。

また、抽出処理部２１８は、ユーザ毎に、ユーザ及びユーザのフレンドの参加状況に基づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する処理を行う。

動向調査部２１９は、ユーザ毎に、特定時点でのユーザのイベントの参加態様を特定する。また、動向調査部２１９は、ユーザ毎に、特定時点でのユーザの参照ページを特定する。また、動向調査部２１９は、ユーザ毎に、特定時点でのユーザ及び当該ユーザのフレンドの参加態様及び参照ページの少なくとも一方を特定する。

決済制御部２２０は、ユーザの端末からの課金情報（課金対象の項目（仮想通貨、クラウドファンディング等の情報）、課金額）を受信して、当該課金情報に基づき決済を行う。決済とは、売買取引を完了させることであり、例えば、クレジットカードでの決済や、電子マネーによる決済等を行う。

動画配信部２２１は、会場の様子を撮影した動画データをユーザの端末に配信（送信）する処理を行う。

ＳＮＳ制御部２２２は、ＳＮＳサイト（ＳＮＳサーバ）と連携し、ユーザＩＤに対応付けられたＳＮＳサイトのユーザＩＤを利用して、ＳＮＳサイトへの投稿等を利用可能に制御する。

クラウドファンディング制御部２２３は、ユーザの入力情報に基づき、出演者に対して投資額を設定して、当該出演者に対して投資を行う。

４．バトルのイベントの例
４．１ 概要
次に、本実施形態において、図３に示すプラットフォームＰＦにおいて、出演者の属性を現実世界に存在するアイドルとし、イベントの属性をバトルとする例について説明する。

まず、事業者は、現実世界の会場に８人のアイドルを招致し、青、赤、黄、緑の４チームに２名の出演者を配属させ、チーム戦でミニゲームや競技を行い、領地（例えば、日本の県）を獲得するイベントを開催する。つまり、ゲームシステム１は、現実に行われるイベントに融合したシステムとなる。

また、ユーザは、青、赤、黄、緑の４チームの中から１つのチームを選択して所属チームを決定し、イベント中に、事象を予想する予想ゲームに参加することができる。事象を予想する予想ゲームとは、アイドルがプレイするミニゲームや競技の結果を予想するゲームである。ユーザは、予想が当たるとポイントを獲得することができる。サーバ２０は、ユーザのポイントをランキング化し、上位の一部のユーザに対して、出演者に対してメッセージを送信できるように制御する。

そして、各チームの出演者は、自身のミニゲームのゲーム結果及びユーザの予想結果に応じて領地を獲得することができる。予想ゲームは複数回行われ、最終的に、多くの領地
を獲得したチームが優勝となる。

このように、本実施形態のイベントによれば、ユーザはアイドルのゲームプレイやミニゲームの様子を楽しむことができる。また、ユーザは、ミニゲーム（或いは競技）の結果を予想するゲームに参加でき、イベントを一層楽しむことができる。以下、詳細に本実施形態の処理について説明する。

４．２ ユーザ登録
本実施形態のサーバ２０は、ユーザの端末１０から登録要求を受け付けた場合に、当該ユーザの登録処理を行う。サーバ２０は、ユーザ毎に、ユーザＩＤ（ユーザの識別情報）に対応づけてユーザのユーザ名、ニックネーム等の基本情報を記憶する。

４．３ 仮想通貨の説明
本実施形態では、ユーザ毎に、ユーザが所持する仮想通貨を設定している。例えば、サーバ２０は、ユーザの仮想通貨の初期値として１０００円を付与する。ユーザは、事象を予想するゲームに参加する際に、少なくとも１円以上の仮想通貨を消費することになる。なお、説明の便宜上、仮想通貨の単位を円で説明しているが、ドル、ユーロの他、仮想上の通貨単位であってもよい。なお、「仮想通貨」は、「ゲーム内通貨」ともいう。また、ユーザは、課金することによってユーザが所持する仮想通貨の金額を増加させることができる。

４．４ 所属チーム
本実施形態の端末１０は、ユーザが事象を予想するゲームに参加する前に、ユーザの入力情報に基づき、イベントにおけるチーム（赤、青、緑、黄のチーム）の中から一のチームの選択を受け付ける処理を行う。端末１０は、ユーザが選択したチームの識別情報（例えば、チーム名）を、サーバ２０に送信する処理を行う。例えば、ユーザＰ１が、青チームを選択した場合、ユーザＰ１に対応付けて所属チームを青に設定する。

４．５ イベントの流れ
まず、事業者側が、イベントの開始日時を予め定める。本実施形態では、図６に示すように、イベント期間中、複数の予想ゲームを行ってイベントを進行させる。全ての予想ゲームが終了すると、イベントを終了する。

また、事業者は、イベントの開始日時の前において、ユーザの端末１０に対して、イベントの開始日時やイベント内容（予想ゲーム内容）の告知をする。イベントは、現実世界にリアルタイムに開催されるものである。イベント期間は２時間〜３時間程度になる。本実施形態のイベントでは、予想ゲームを８回行うが、予想ゲームの回数は複数回でもよいし、予想ゲームの回数は１回でもよい。

４．６ 予想ゲームの流れ
図７は、事象を予想するゲーム（予想ゲーム）の時間軸の流れを示す。Ｒ１〜Ｒ７のゲーム期間において、事象（ミニゲームのゲーム結果）の予想を受け付ける予想受付期間Ｒ１〜Ｒ２を設ける。言い換えると、予想受付期間Ｒ１〜Ｒ２において、ユーザが、出演者（アイドル）の中から誰が１位になるか、或いは、誰が１位で誰が２位になるかを予想し、ユーザの仮想通貨をベットする（賭ける）。

予想受付期間の終了後、ミニゲームのゲームプレイ期間Ｒ３〜Ｒ４において、出演者がミニゲームをプレイする。ミニゲームのゲームプレイ期間終了後、結果発表期間Ｒ５〜Ｒ６があり、その後、領地獲得期間Ｒ６〜Ｒ７がある。結果発表期間では、ミニゲームのゲーム結果が発表され、ユーザの予想が的中したか否かを判定する。領地獲得期間では、出
演者が、いずれの領地を獲得するかを発表する。

４．７ 出演者の情報
図８は、サーバ２０が管理する出演者の情報の一例を示す。例えば、サーバ２０は、出演者ＩＤ（出演者の識別情報）に対応付けて、出演者の氏名、出演者が所属するチーム名を記憶する。

４．８ チームの情報
図９は、サーバ２０が管理するチームの情報の一例を示す。例えば、サーバ２０は、チーム名（チームの識別情報、チームＩＤ等）に対応付けて、チーム名、領地数、順位を記憶する。

４．９ 予想情報受付処理
次に、本実施形態のサーバ２０が、事象（ミニゲームのゲーム結果）を予想する予想情報を受け付ける処理について具体的に説明する。図１０は、ミニゲームの実施前に、ユーザの端末１０に表示される予想入力画面の一例を示す。例えば、予想受付期間に予想入力画面を表示する。

図１０に示すように、１〜８の番号に対応付けて、出演者の名前、所属チーム名（青、緑、赤、黄のいずれか）、出演者の画像を表示する。本実施形態のイベントでは、各チーム２名の出演者がミニゲームを行うので、合計８名の出演者の名前等が表示される。

まず、ユーザは、「１位予想」をするのか、「１位２位予想」をするのかを、選択する。例えば、ユーザの端末は、「１位予想」ボタンＣ１の入力を受け付けた場合、ユーザは、ミニゲームを行う８名の出演者の中から、１位になると思う出演者１名に自分の仮想通貨を賭ける（ベットする）。

例えば、ユーザＰ１が１位になると思う出演者に、１番の出演者（青チーム、Ｎａｏｍｉ）を選ぶ場合には、ユーザＰ１の端末１０において、１番の出演者（青チーム、Ｎａｏｍｉ）の表示エリアをタッチ入力する。ユーザＰ１の端末１０は、１番の出演者（青チーム、Ｎａｏｍｉ）の選択を受け付けると、ベット額設定画面に移行する。

図１１は、１位予想におけるベット額設定画面の一例を示す。例えば、ベット額設定画面では、ユーザＰ１が選択した１番の出演者（青チーム、Ｎａｏｍｉ）に対して、ユーザＰ１の所有の仮想通貨から賭ける額を決定する。また、ベット額設定画面では、ユーザＰ１が選択した１番の出演者（青チーム、Ｎａｏｍｉ）に対して、賭け率Ａ１を表示する。図１１の例では、賭け率は４０倍である。

そして、図１１に示すように、例えば、ユーザＰ１の端末１０は、「１０」ボタンＡ４の入力を受け付けた場合に、１０円単位で賭け額を増やし、「１」ボタンＡ５の入力を受け付けた場合に、１円単位で賭け額を増やす。Ａ３エリアには、現在の１番の出演者（青チーム、Ｎａｏｍｉ）に対する賭け額（例えば、１円）を表示する。

また、ユーザＰ１の端末１０は、「クリア」ボタンＡ２の入力を受け付けた場合に、ユーザＰ１が選択した１番の出演者（青チーム、Ｎａｏｍｉ）の賭け額を０円に更新する。

そして、ユーザＰ１の端末１０において、１番の出演者（青チーム、Ｎａｏｍｉ）について、１円の賭け額が設定され、ベット確認ボタンＡ６の入力を受け付けると、確認画面に移行する。

なお、サーバ２０は、図１２に示すように、予想ゲーム毎に、予め賭け率（オッズ）を設定している。例えば、サーバ２０は、１位予想の出演者毎に賭け率を設定し、１位２位予想の２人組の出演者毎に賭け率を設定する。

図１３は、確認画面の一例を示す。確認画面では、賭け率Ｂ１、「１位予想」或いは「１位２位予想」の種別Ｂ２、賭け額Ｂ３、賭けに勝った場合に、ユーザが受け取れるポイントＢ４を表示する。

例えば、図１３の例によれば、ユーザＰ１は、１番の出演者（青チーム、Ｎａｏｍｉ）を１位と予想し、賭け額が１円であることを示す。また、予想が的中した場合（賭けに勝った場合）に、ユーザＰ１が４０ポイントを取得することを示している。

また、確認画面において、ユーザが所持する仮想通貨から賭け額を使用（消費、減算）して、ベットする内容を示すメッセージをＢ５エリアに表示する。

ユーザＰ１の端末１０において、「はい」のボタンＢ７の入力を受け付けると、ユーザＰ１の所有している仮想通貨から１円を減算し、１番の出演者（青チーム、Ｎａｏｍｉ）を１位予想として１円をベットすることを確定する。

そして、ユーザＰ１の端末１０は、ベット確定後、予想情報（ベット情報）をユーザＰ１のＩＤに対応付けて、サーバ２０に送信する。予想情報とは、例えば、賭けた出演者名（例えば、Ｎａｏｍｉ）、賭けの種別（例えば、１位予想）、賭け額（例えば、１円）等である。

一方、ユーザＰ１の端末１０において、「いいえ」のボタンＢ６の入力を受け付けると確定せずに、図１０の予想入力画面、又は、図１１のベット額設定画面に戻る。

次に、本実施形態において、ユーザが「１位２位予想」を選択した場合の処理について説明する。

例えば、図１０の予想入力画面で、ユーザの端末は、「１位２位予想」ボタンＣ２の入力を受け付けた場合、ユーザは、ミニゲームを行う８名の出演者の中から、１位になると思う出演者１名と、２位になると思う出演者１名の組で自分の仮想通貨を賭ける（ベットする）。

例えば、ユーザＰ１が１位になると思う出演者に、１番の出演者（青チーム、Ｎａｏｍｉ）を選ぶ場合には、ユーザＰ１の端末１０において、１番の出演者（青チーム、Ｎａｏｍｉ）の表示エリアをタッチ入力する。そして、１番の出演者（青チーム、Ｎａｏｍｉ）の表示エリアをタッチ入力後、ユーザＰ１が２位になると思う出演者に４番の出演者（緑チーム、Ｊａｎｅ）を選ぶ場合に、ユーザＰ１の端末１０において、４番の出演者（緑チーム、Ｊａｎｅ）の表示エリアをタッチ入力する。

ユーザＰ１の端末１０は、１番の出演者（青チーム、Ｎａｏｍｉ）、４番の出演者（緑チーム、Ｊａｎｅ）を受け付けると、ベット額設定画面に移行する。

図１４は、１位２位予想におけるベット額設定画面の一例を示す。例えば、ベット額設定画面では、ユーザＰ１が選択した１位の１番の出演者（青チーム、Ｎａｏｍｉ）、２位の４番の出演者（緑チーム、Ｊａｎｅ）に対して賭ける仮想通貨の額を決定する。

例えば、図１４に示すように、ユーザＰ１の端末１０において、１位の１番の出演者（
青チーム、Ｎａｏｍｉ）、２位の４番の出演者（緑チーム、Ｊａｎｅ）に対して、１０円の賭け額が設定され、ベット確認ボタンＡ６のタッチ入力を受け付けると、確認画面に移行する。

図１５は、１位２位予想における確認画面の一例を示す。例えば、確認画面では、１番の出演者（青チーム、Ｎａｏｍｉ）を１位、４番の出演者（緑チーム、Ｊａｎｅ）を２位と予想し、賭け率は２１０倍、賭け額が１０円であることを示す。また、予想が的中した場合（賭けに勝った場合）に、ユーザＰ１が２１００ポイントを取得することを示している。

また、ユーザＰ１の端末１０の確認画面において、「はい」のボタンＢ７の入力を受け付けると、ユーザＰ１の所有している仮想通貨から１０円を減算し、１番の出演者（青チーム、Ｎａｏｍｉ）を１位、４番の出演者（緑チーム、Ｊａｎｅ）を２位と予想として１０円をベットをすることを確定する。

そして、ユーザＰ１の端末１０は、ベット確定後、予想情報をユーザＰ１のＩＤに対応付けて、サーバ２０に送信する。予想情報とは、例えば、１位に賭けた出演者名（例えば、Ｎａｏｍｉ）、２位に賭けた出演者名（例えば、Ｊａｎｅ）、賭けの種別（例えば、１位２位予想）、賭け額（例えば、１０円）等である。

一方、ユーザＰ１の端末１０において、「いいえ」のボタンＢ６の入力を受け付けると確定せずに図１０の予想入力画面、又は、図１１のベット額設定画面に戻る。

なお、端末１０は、図１５に示すように、設定済みの予想情報Ｂ８を表示してもよい。

そして、予想受付期間が終了すると、サーバ２０は、予想情報の受け付けを終了する。端末１０は、サーバ２０から予想受付期間の終了時刻の情報を受信すると、予想入力画面、ベット額設定画面、確認画面それぞれにおいて予想受付終了時刻までの残り時間を表示し、予想受付期間終了時に、予想受付を終了したことを示す情報を表示する。

図１６は、サーバ２０が管理する各ユーザの予想情報の一例を示す。サーバ２０は、１位予想の種別の場合、ユーザＩＤ及びベットＩＤに対応付けて、１位予想の出演者名と賭け額を記憶する。サーバ２０は、１位２位予想の種別の場合において、ユーザＩＤ及びベットＩＤに対応付けて、１位予想の出演者名と２位予想の出演者名、及び、賭け額を記憶する。

本実施形態では、ユーザは、賭けの対象の出演者や種別を異ならせて複数の賭け（ベット）の設定を行うことができる。例えば、予想受付期間が終了していない場合、ユーザＰ１から別の出演者に対して１位予想の予想情報、１位２位の予想情報を受け付けてもよい。また、ユーザは、自身が所属するチームに関係なく、出演者をベット対象に選んでもよい。

４．１０ ミニゲームの実施
予想受付期間終了後、ミニゲームの実施が進行する。例えば、イベントの進行役である司会者が「ミニゲームを始めます」など宣言し、ミニゲームのゲームプレイを開始する。そして、各チーム２名、合計８名の出演者がミニゲームを行い、順位を決定する。

ミニゲームの内容は、例えば順位を競うゲーム（音楽ゲーム、レースゲーム等）である。なお、ミニゲームの替わりに、スポーツなどの順位を競う競技（マラソン等）を行ってもよい。

サーバ２０は、ミニゲームの様子を撮影した動画データを、ユーザの端末１０に対してストリーミング配信する。したがって、会場にいないユーザも、出演者がプレイしているミニゲームの様子を楽しむことができる。例えば、ユーザは、自分が所属するチームの出演者を応援するだけでなく、自分がベットした出演者を応援するので、イベントの内容は白熱したものになる。

４．１１ 結果発表
ミニゲームのプレイ期間が終了すると、会場において、スクリーンにミニゲームを行った８名の出演者のゲーム結果（順位）を発表する。また、サーバ２０は、結果発表の様子を撮影した動画データを、ユーザの端末１０に対してストリーミング配信する。

図１７は、ミニゲームのゲーム結果の一例を示す。例えば、１位が青チームのＮａｏｍｉであり、２位が、赤チームのＡｎｎａであることを示す。

つまり、１位予想において１位に青チームのＮａｏｍｉに予想（ベット）したユーザは勝ちと判定される。また、１位２位予想において１位に青チームのＮａｏｍｉ、２位に赤チームのＡｎｎａに予想（ベット）したユーザは勝ちと判定される。

４．１２ ポイントの演算
本実施形態のサーバ２０は、ミニゲーム終了後、ユーザ毎に、当該ミニゲームのゲーム結果（事象）とユーザの予想情報とを比較し、予想情報が的中したか否か、すなわち、ベットに勝ったか否かを判断する。そして、サーバ２０は、予想ゲーム毎に、予想情報が的中したか否かを判断する。

例えば、図１８は、ユーザＰ１の端末１０において、ユーザＰ１の各予想情報の勝ち、負けの結果（予想ゲームの結果）を示す画面である。つまり、サーバ２０は、ユーザＰ１の、１位２位予想の予想情報は的中しなかったと判断し、１位予想の予想情報は的中したと判断する。

また、サーバ２０は、イベント中に開催されるミニゲームのゲーム期間の終了時に、ユーザ毎に、事象に対するユーザの予想情報が的中したか否かに基づいて、ユーザのポイントに加算するための加算値を算出し、加算値をユーザのポイントに加算する。つまり、サーバ２０は、予想ゲーム毎に加算値を算出し、ユーザのポイントを更新する。加算値の算出は、下式（１）によって行う。なお、係数の初期値は１である。

加算値＝賭け額×賭け率×係数・・・（１）
例えば、ユーザＰ１のベットＩＤ＝１の予想情報である１位予想が的中している。なお、ユーザＰ１の係数は１であるとする。すると、ユーザＰ１の１位予想の賭け額１（円）に賭け率４０倍を乗じた４０に、更に係数１を乗じた値４０を、ユーザＰ１の加算値とする。

例えば、ミニゲームの実施前のユーザＰ１のポイントの値が１０００である場合には、ユーザＰ１のポイントに加算値４０を加算し、ユーザＰ１のポイントの値は１０４０に更新される。

また、ユーザＰ２のベットＩＤ＝１の予想情報である１位予想、及び、ベットＩＤ＝５の予想情報である１位２位予想が的中している。なお、ユーザＰ２の係数は１であるとする。すると、ユーザＰ２の予想的中した１位予想の賭け額２（円）に４０倍×１倍を乗じた８０と、ユーザＰ２の予想的中した１位２位予想の賭け額１０（円）に２１０倍×１倍
を乗じた２１００とを、ユーザＰ２のポイントに加算する。

例えば、ミニゲームの実施前のユーザＰ２のポイントの値が２０００である場合には、ユーザＰ２のポイントに、加算値８０と加算値２１００とを加算し、ユーザＰ２のポイントの値は４１８０に更新される。

４．１３ ポイントのランキング、及び、称号の更新
本実施形態のサーバ２０は、チーム毎に各ユーザのポイントをランキング化（順位付け）する。ポイントのランキング化とは、ポイントの高い順に並び替えることを意味する。

図１９は、青チームの各ユーザをポイントの高い順に並び替えた、ランキングの画面の一例を示す。なお、サーバ２０は、青チームだけでなく各チームそれぞれのユーザのポイントを高い順に並べてランキングを行う。また、サーバ２０は、予想ゲーム毎に、ユーザのポイントを更新するので、予想ゲーム毎に、ポイントのランキング（順位付け）を更新する。

また、各ユーザの端末１０は、ユーザの所属するチームのユーザのポイントのランキングの結果（順位）を表示する。例えば、端末１０は、ユーザが所属するチームの１位〜２００位までのユーザのランキングの結果（順位）と称号、ユーザ名（ユーザＩＤやニックネームでもよい）、ポイントの値を表示する。このようにすれば、ユーザは、自身のポイントと他のユーザのポイントとを比較することができる。また、次の予想ゲームに対するモチベーションを高めることができる。

また、サーバ２０は、図１９に示すように、チーム毎に、各ユーザの称号を更新する。称号は、階級のことであり、称号が高いほど、ユーザにとってメリットがある。なお、サーバ２０は、予想ゲーム１のランキング化前の初期状態においては、各ユーザに最も低い階級の「足軽」の称号を付与する。

例えば、サーバ２０は、図２０に示すように、ランキング化後、１位のユーザに「大将」の称号を付与し、２位のユーザに「副将」の称号を付与し、３位に「五千人将」の称号を付与し、４位に「三千人将」の称号を付与し、５位〜１０位に「千人将」の称号を付与し、１１位〜２０位に「五百人将」の称号を付与し、２１位〜１００位に「百人将」の称号を付与し、１０１位〜２００位に「組頭」の称号を付与し、２０１位〜１０００位に「伍長」の称号を付与する。なお、１００１位以上は「足軽」の称号とする。また、各チームの１名の出演者は、「総大将」の称号が与えられ、各チームの他の１名の出演者は、「軍師」の称号が与えられている。

また、サーバ２０は、図２０に示すように、加算値算出時に用いられる係数を称号に対応付けて記憶する。称号が上がれば上がるほど、係数を上昇させるようにし、ユーザにとって加算値が増えるように制御している。

また、本実施形態のサーバ２０は、各ユーザのポイント更新後、チームに関係なく全ユーザのポイントのランキング化し、各ユーザの端末１０は、サーバ２０から当該ランキング結果を受信して表示してもよい。

４．１４ 各ユーザの参加可能範囲の設定
本実施形態のサーバ２０は、ユーザ毎に、ユーザのメッセージ閲覧権限（所定の権限の一例）の有無をフラグ（有を１、無を０）で設定し、ユーザ毎に、ユーザの送信権限（所定の権限の一例）の有無をフラグ（有を１、無を０）で設定することによって、各ユーザの参加可能範囲を設定する。

メッセージ閲覧権限は、例えば、ユーザや他のユーザが出演者に向けて送信したメッセージを閲覧することができるか否かを示す権限である。メッセージ閲覧権限は、チャット閲覧権限ともいう。サーバ２０は、ユーザ登録を行った全てのユーザに対して、メッセージ閲覧権限を有に設定する。

メッセージ送信権限は、ユーザが出演者に向けてメッセージを送信することができるか否かを示す権限である。メッセージ送信権限は、チャット参加権限ともいう。サーバ２０は、各チームのポイントのランキングの結果（順位）が２００位以内のユーザに、メッセージ送信権限を有に設定している。つまり、図２０に示すように、サーバ２０は、各チームの「大将」、「副将」、「五千人将」、「三千人将」、「千人将」、「五百人将」、「百人将」、「組頭」の称号が付与されたユーザに対して、メッセージ送信権限を「１」（有）に設定し、「伍長」「足軽」の称号が付与されたユーザのメッセージ送信権限を「０」（無）に設定する。

例えば、サーバ２０は、メッセージ送信権限が「０」から「１」に変更されたユーザに対して、図２１に示すように、メッセージ送信権限が付与されたことを示す情報を当該ユーザの端末１０の表示部に表示してもよい。

また、サーバ２０は、メッセージ送信権限が「１」から「０」に変更されたユーザに対して、図２２に示すように、メッセージ送信権限が消失されたことを示す情報を当該ユーザの端末１０の表示部に表示してもよい。

図２３は、メッセージ送信権限が「１」のユーザの端末１０において、表示されるチャット画面の一例を示す。図２４は、メッセージ送信権限が「０」のユーザの端末１０において、表示されるチャット画面の一例を示す。ユーザの端末１０は、サーバ２０にチャット画面を要求することによって、チャット画面を端末１０に表示することができる。サーバ２０は、ユーザの端末１０からのチャット画面の要求に応じて、当該ユーザのチームのチャット画面の情報を送信する。

つまり、メッセージ送信権限が「１」のユーザは、図２３に示すように、所属するチームのチャット画面において、ユーザのメッセージを送信することができる。例えば、メッセージ送信権限フラグが「１」のユーザは、所属するチームのチャット画面において、メッセージを入力欄Ｄ１に入力し、送信ボタンＤ２をタッチ入力することで、自身のメッセージをサーバ２０に送信し、チャットすることができる。このチャット画面は、チームの出演者（総大将）に送信するものであるので、ユーザは、出演者に対して親近感を感じることができ、イベントを一層楽しむことができる。

なお、サーバ２０は、イベント期間内において、メッセージ送信権限が「１」のユーザの端末からのメッセージを受信可能に制御してもよいし、特に時期的な制限を設けることなく、メッセージ送信権限が「１」のユーザの端末からのメッセージを受信可能に制御してもよい。

一方、メッセージ送信権限が「０」のユーザは、図２４に示すように、端末１０において、所属するチームのチャット画面において、メッセージを入力することができないが、他のユーザのメッセージ等を含むチャット画面を閲覧することはできる。

なお、端末１０の表示部や会場のスクリーンに、メッセージ毎に、メッセージを送信したユーザ名（ユーザＩＤ、ニックネーム等でもよい）、メッセージ、送信日時に関する情報が表示される。

４．１５ 領地取得
イベント会場にいる出演者は、ミニゲーム実施終了後、所属するチームの出演者のミニゲームの結果と、チームに所属するユーザの予想情報（ベット）の結果とに基づいて、点数Ｙを算出し、各チームは、点数Ｙに応じて領地を取得する。本実施形態では、予想ゲーム毎に、点数Ｙを算出する。

まず、点数Ｙの算出手法について説明する。本実施形態では、出演者のミニゲームのゲーム結果の点数Ｘ１及び、チームに所属しているユーザの予想情報の的中度合いの点数Ｘ２に基づき、点数Ｙを算出する。なお、各チームのＹの初期値は０点である。

まず、予想ゲームで実施されたミニゲームのゲーム結果が１位のチームのＸ１の値を４点とする。また、２位のチームのＸ１の値を３点とする。また、３位のチームのＸ１の値を２点とする。また、４位のチームのＸ１の値を１点とする。

例えば、図１７に示すように、予想ゲーム１においてミニゲームのゲーム結果が１位のチームは青チームであるので、青チームのＸ１の値に４点を設定する。また、予想ゲーム１においてミニゲームのゲーム結果が２位のチームは赤チームであるので、赤チームのＸ１の値に３点を設定する。また、予想ゲーム１においてミニゲームのゲーム結果が３位のチームは緑チームであるので、緑チームのＸ１の値に２点を設定する。また、予想ゲーム１においてミニゲームのゲーム結果が４位のチームは黄チームであるので、黄チームのＸ１の値に１点を設定する。

また、予想ゲームにおいて、各チームのユーザの加算ポイントの合計値を集計し、加算ポイントの合計値が最も高いチームのＸ２の値を４点とする。また、当該合計値が２位のチームのＸ２の値を３点とする。また、３位のチームのＸ２の値を２点とする。また、４位のチームのＸ２の値を１点とする。

例えば、予想ゲーム１において、青チームに所属するユーザの加算ポイントの合計値が２００，０００，０００ポイントで最も高いチームである場合、青チームのＸ２の値に４点を設定する。また、予想ゲーム１において、緑チームに所属するユーザの加算ポイントの合計値が１９０，０００，０００ポイントで２番目に高いチームである場合、緑チームのＸ２の値に３点を設定する。また、予想ゲーム１において、黄チームに所属するユーザの加算ポイントの合計値が１８０，０００，０００ポイントで３番目に高いチームである場合、黄チームのＸ２の値に２点を設定する。また、予想ゲーム１において、赤チームに所属するユーザの加算ポイントの合計値が１７０，０００，０００ポイントで４番目に高いチームである場合、赤チームのＸ２の値に１点を設定する。そして、図２５に示すように、各チームのＸ１とＸ２との合計値を点数Ｙとする。

領地取得について図２６を用いて具体的に説明する。本実施形態では、図２６に示すように、日本地図を模した複数の領地（マス目）を用意する。各チームは、点数Ｙに応じて空きの領地や他チームの領地を獲得することができる。

本実施形態では、自チームの点数Ｙから１点を減算して、自チームの１つの領地を取得することができる。なお、初めて取得する領地は、任意の箇所とすることができるが、２つ目移行に取得する領地は、既に獲得した領地に隣接する領地であることが条件となる。なお、他のチームの領地を自チームの領地とする場合には、点数Ｙから２点を減算して、他のチームの領地を自チームの領地として獲得することができる。なお、本実施形態では、各チームの出演者の指示に基づいて、領地を取得する。

図２６は、端末１０に表示される各チームの領地獲得状況を示す画面の一例を示す。例えば、ＡＢは青チームの獲得領地数であり、点数Ｙが８点であるので青チームは８つの領地数を獲得していることを示す。ＡＲは赤チームの獲得領地数であり、赤チームは、点数Ｙが４点であるので４つの領地数を獲得していることを示す。ＡＧは緑チームの獲得領地数であり、緑チームは、点数Ｙが５点であるので５つの領地数を獲得していることを示す。ＡＹは黄チームの獲得領地数であり、黄チームは点数が３点であるので３つの領地数を獲得していることを示す。なお、領地獲得状況を示す画面は、会場のスクリーンにおいて表示してもよい。

また、図２６に示すように、獲得領地数の多い順に、各チームの順位を表示する。予想ゲーム１の終了時点では、青チームが１位、緑チームが２位、赤チームが３位、黄チームが４位であることを示している。

本実施形態のイベントでは、第Ｎの予想ゲームの後に次の第Ｎ＋１の予想ゲームが開始される。第Ｎ＋１の予想ゲームでは、第Ｎの予想ゲームにおいての領地獲得の状況から、領地を獲得することになる。例えば、予想ゲーム２の終了後、各チームは、予想ゲーム２の点数Ｙに基づいて、予想ゲーム１終了時に獲得した領地に隣接する領地を獲得する。

このように、各チームは予想ゲームを繰り返し行い、最終的に、予想ゲーム８の終了時に最も多い領地を獲得したチームが優勝する。

４．１６ フローチャート
本実施形態のサーバ２０の処理の流れを図２７Ａ、図２７Ｂを用いて説明する。まず、図２７Ａに示すように、Ｎに１を代入する（ステップＳ１）。そして、第Ｎの事象（例えば、第Ｎの予想ゲームのミニゲームのゲーム結果）の予想受付期間の開始時刻が到来したか否かを判断する（ステップＳ２）。第Ｎの事象の予想受付期間の開始時刻が到来した場合（ステップＳ２のＹ）、ユーザ毎に、ユーザの仮想通貨（ユーザが所有する仮想通貨）を消費することを条件に第Ｎの事象の予想情報を受け付ける（ステップＳ３）。そして、第Ｎの事象の予想受付期間の終了時刻が到来したか否かを判断する（ステップＳ４）。第Ｎの事象の予想受付期間の終了時刻が到来した場合（ステップＳ４のＹ）、第Ｎの事象の予想情報の受け付けを終了する（ステップＳ５）。なお、第Ｎの事象の予想受付期間の終了時刻が到来していない場合（ステップＳ４のＮ）、ステップＳ３に戻る。

次に、図２７Ｂに示すように、現実世界において第Ｎの事象が発生したか否かを判断する（ステップＳ１０）。第Ｎの事象が発生した場合（ステップＳ１０のＹ）、ユーザ毎に、ユーザの予想情報と現実世界の第Ｎの事象とに基づいて、ユーザの加算値を算出する（ステップＳ１１）。そして、ユーザ毎に、ユーザの加算値をユーザのポイントに加算する（ステップＳ１２）。そして、各チームにおいて、ポイントの高い順にランキングする（ステップＳ１３）。

そして、各チームにおいて、２００位以内のユーザに、メッセージ送信権限を有に設定し、２０１位以上のユーザに、メッセージ送信権限を無に設定する（ステップＳ１４）。そして、Ｎ＝８であるか否かを判断し（ステップＳ１５）、Ｎ＝８である場合（ステップＳ１５のＹ）は、処理を終了し、Ｎ＝８でない場合、Ｎに１を加算し（ステップＳ１６）、ステップＳ２に戻る。以上で処理が終了する。

４．１７ 会場のスクリーン
本実施形態の会場では、青チーム、赤チーム、黄チーム、緑チームそれぞれのチーム用のスクリーン（チーム用の表示部、チーム用の画面）や、メインのスクリーン（メイン画面）を設けてもよい。

例えば、チーム用のスクリーンでは、各チームのチャット画面を表示し、メインのスクリーンでは、現在の各チームの順位や領地数等の領地獲得状況を示す画面を表示する。

４．１８ クラウドファンディング
本実施形態では、ユーザの入力情報に基づき、出演者に対して投資額を設定して、投資を行うようにしてもよい。例えば、サーバ２０が、ユーザから複数の出演者の中から一の出演者の選択を受け付け、選択された出演者に対して、ユーザが指定する投資額（例えば、１０００円）を付与する。このとき、サーバ２０は、ユーザの指定する投資額の決済処理を行う。出演者の目標投資額（例えば、１０万円）に到達した場合に、当該出演者の投資受付を終了する。このようにすれば、出演者のファンのユーザは、具体的に投資によって応援することができ、更にイベントを楽しむことができる。なお、サーバ２０は、ユーザの投資額に応じて、ユーザのポイントを上昇させるようにしてもよいし、ユーザの投資額に応じて、ユーザの仮想通貨を上昇させるようにしてもよい。

４．１９ 投票
本実施形態では、ユーザの投票に基づいて、予想ゲームの開始前に、イベントに出演させる出演者を決定してもよい。例えば、２０人存在するアイドルの中から、投票数の多い１０人のアイドルを、イベントに出演させるようにしてもよい。

４．２０ その他
本実施形態では、各予想ゲームの予想受付は、予想ゲームの予想受付期間に限らず、予想受付期間開始前から当該予想ゲームの予想受付を行ってもよい。例えば、イベント期間の開始前に、各予想ゲームの予想受付を行ってもよい。

５．ユーザ情報の管理
５．１ 概要
本実施形態では、図３に示すように、出演者の属性やイベントの属性に応じて種々のイベントを開催することができる。上述したように、プラットフォームＰＦにおいて、出演者の属性を現実世界に存在するアイドルとし、イベントの属性をバトルとする例について説明したが、出演者の属性を芸人とし、イベントの属性をクイズとするイベントを開催してもよい。また、出演者の属性をアイドルと、イベントの属性をスポーツとするイベントを開催してもよい。このように、本実施形態のプラットフォームＰＦにおいて、複数の種類のイベントを実現することができる。

本実施形態のサーバ２０は、各ユーザの好みの考慮したイベント運営を行い、イベント運営の向上が図れるよう、ユーザ情報を管理する。以下、詳細に説明する。

５．２ 出演者の属性
出演者とは、アイドル、芸人、タレント、女優、俳優、音楽家、アスリート、アナウンサーなど、一般人よりも知名度が高い人を意味する。

出演者の属性とは、出演者の種類（種別、職種等）を意味する。例えば、図３に示すように、「アイドル」、「芸人」、「タレント」のように、サーバ２０が予め出演者の属性を定める。

なお、出演者の属性は、出演者を識別するための識別情報でもよい。例えば、サーバ２０が予め定める出演者の氏名を出演者の属性としてもよい。

５．３ イベントの属性
イベントとは、催し物、行事のことである。特に、本実施形態のイベントは、会場に出演者を招致し、出演者に競技やミニゲームを行わる。また、本実施形態のイベントは、会場内または会場外のユーザが出演者によって発生する事象（ミニゲームのゲーム結果、競技結果等）を予想する予想ゲームを行うことが可能なイベントである。

イベントの属性とは、イベントの種類（種別）を意味する。例えば、図３に示すように、「バトル」、「クイズ」、「スポーツ」のように、サーバ２０が予めイベントの属性を定める。

なお、イベントの属性は、イベントを識別するための識別情報でもよい。例えば、サーバ２０が予め定めるイベント名をイベントの属性としてもよい。

５．４ ユーザ情報
本実施形態では、ユーザ情報をユーザ情報記憶部２７３に記憶する。具体的には、以下の情報を記憶する。

（１）基本情報
本実施形態では、ユーザ登録時にユーザ情報の基本情報を登録する。例えば、基本情報とは、ユーザＩＤ、ユーザ名、ニックネーム、性別、年齢、生年月日、ユーザ登録日、フレンド関係にあるフレンド（フレンドのユーザのＩＤ）等であり、サーバ２０は、ユーザの端末１０からの入力情報に基づき、基本情報をユーザ情報記憶部２７３に記憶する。

（２）ログイン履歴
ログイン履歴は、ユーザからのサーバ２０へのログインの履歴であり、ユーザの参加状況の一例である。例えば、図２８に示すように、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ログイン日時をユーザ情報記憶部２７３に蓄積して記憶する。

（３）参加回数、参加態様、参照ページ
参加回数、参加態様、参照ページは、ユーザの参加状況の一例である。本実施形態のサーバ２０は、ログイン履歴に基づき、ユーザ毎に、イベントの属性又は出演者の属性に対応付けて、所定期間の参加回数（ログイン回数）を算出する。所定期間とは、例えば、イベント期間でもよいし、所定の１日の期間でもよいし、ユーザ登録日から現時点までの期間でもよい。このようにすれば、ユーザが所定期間に、どのイベントの属性にどのくらい参加したのか、どの出演者の属性にどのくらい参加したのかを認識することができる。なお、サーバ２０は、ユーザ毎に、算出された所定期間の参加回数（ログイン回数）を、イベントの属性又は出演者の属性に対応付けて、ユーザ情報記憶部２７３に記憶してもよい。

また、本実施形態のバトルのイベントの場合、「予想」、「チャット」、「クラウドファンディング」、「投票」の４つの参加態様がある。サーバ２０は、図２９に示すように、ユーザ毎に、イベントの属性及び出演者の属性、所与の時刻に対応付けて、ユーザの参加態様をユーザ情報記憶部２７３に蓄積して記憶する。例えば、サーバ２０は、所定の周期（５分毎）に、当該ユーザの参照ページから参加態様を特定し、ユーザ情報記憶部２７３に記憶する。このようにすれば、ユーザがどの時点で、どの属性のイベント、どの出演者の属性で、どのような参加態様で参加していたのか等を認識することができる。なお、サーバ２０は、予め作成されたページ毎に、参加態様を設定する。

また、本実施形態のサーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性、参照時刻に対応付けて、ユーザの参照ページをユーザ情報記憶部２７３に蓄積して記憶する
。つまり、サーバ２０は、ユーザの端末１０からアクセスされた参照ページ（Ｗｅｂページ等）のログ履歴（アクセスログ）をユーザ情報記憶部２７３に記憶する。このようにすれば、ユーザがどの時点で、どのページを見ていたのか等を認識することができる。

（４）決済情報
決済情報は、ユーザの参加状況の一例である。決済情報とは、例えば、課金額である。例えば、図３０に示すように、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、課金額をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性にどのくらい課金したのか、どの出演者の属性にどのくらい課金したのかを認識することができる。なお、サーバ２０は、課金額に対応付けて課金された日時も記憶してもよい。また、サーバ２０は、課金額に対応付けて、課金対象の項目（仮想通貨、クラウドファンディング）等の種類も記憶してもよい。

（５）予想情報
予想情報は、ユーザの参加状況の一例である。予想情報とは、例えば、予想ゲームにおいてユーザが予想した情報を示す予想情報である。

例えば、図３１に示すように、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、予想情報をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性に何回予想したのか、どの出演者の属性に何回予想したのか、賭け額はいくらか等を認識することができる。なお、サーバ２０は、予想情報が確定された日時も記憶してもよい。

（６）ポイントの更新履歴
ポイントは、ユーザの参加状況の一例である。ポイントが高いほど、ユーザが熱心に参加していることがわかる。

また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザのポイントが更新される度に、更新後のユーザのポイントをユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性にポイントが変化したのか、どの出演者の属性のときにポイントが変化したのかを認識することができる。なお、サーバ２０は、ポイント更新日時も記憶してもよい。

（７）投票履歴
投票履歴は、ユーザの参加状況の一例である。投票数が高いほど、ユーザが熱心に参加していることがわかる。

また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザが投票した出演者をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性又は出演者の属性に、どの出演者に投票したのかを認識することができる。なお、サーバ２０は、投票日時も記憶してもよい。

（８）クラウドファンディングの履歴
また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザがクラウドファンディングで投資した出演者をユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性に投資したのか、どの出演者の属性に投資したのかを認識することができる。なお、サーバ２０は、投資日時も記憶してもよい。

（９）ＳＮＳ投稿履歴
ＳＮＳ投稿履歴は、ユーザの参加状況の一例である。ＳＮＳ投稿が多いほど、ユーザが多くの人にイベントに関する情報を知らせようとしていることがわかる。

また、サーバ２０は、ユーザ毎に、イベントの属性及び出演者の属性に対応付けて、ユーザが投稿したＳＮＳサイトをユーザ情報記憶部２７３に蓄積して記憶する。このようにすれば、ユーザがどのイベントの属性のときにＳＮＳサイトを利用したのか、どの出演者の属性のときにＳＮＳサイトを利用したのかを認識することができる。なお、サーバ２０は、投稿日時や投稿したＳＮＳサイトの種別も記憶してもよい。

５．５ ユーザ毎に、特定のイベントの属性、特定の出演者の属性を抽出する処理の説明
本実施形態のサーバ２０は、ユーザ毎に、ユーザ情報記憶部２７３に記憶されているユーザの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する。

また、サーバ２０は、ユーザ毎に、ユーザ情報記憶部２７３に記憶されているユーザの参加状況に基づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する。以下、具体例を説明する。

（１）過去に参加したイベント
サーバ２０は、ログイン履歴等に基づき、ユーザ毎に、ユーザが過去に参加したイベントの属性や、ユーザが過去に参加したイベントに出演した出演者の属性を抽出してもよい。

（２）参加回数
例えば、サーバ２０は、ユーザ毎に、複数のイベントの属性の中から参加回数が所定回数以上のイベントの属性や出演者の属性を抽出してもよい。

つまり、ユーザＰ１が、バトルのイベントの参加回数が１０回以上であり、他の属性のイベント（例えば、クイズ、スポーツのイベント）の参加回数が１０回未満である場合、ユーザＰ１に対して、バトルに関するイベントを告知することが望ましい。本実施形態のサーバ２０によれば、ユーザＰ１にバトルの属性を抽出することができるので、ユーザＰ１にバトルに関するイベントを告知することができる。つまり、本実施形態によれば、ユーザの好みに適したイベントの属性を知ることができ、イベントの属性に特化した集客を行うことができる。

また、ユーザＰ２が、出演者の属性がアイドルである場合の参加回数が１０回以上であり、他の属性の出演者（例えば、芸人、音楽家の参加回数）である場合の参加回数が１０回未満である場合、ユーザＰ２に対して、アイドルに関するイベントを告知することが望ましい。本実施形態のサーバ２０によれば、ユーザＰ２にアイドルの属性を抽出することができるので、ユーザＰ２にアイドルに関するイベントを告知することができる。つまり、本実施形態によれば、ユーザの好みに適した出演者の属性を知ることができ、出演者の属性に特化した集客を行うことができる。

（３）課金額
また、サーバ２０は、ユーザ毎に、複数のイベントの属性の中から課金額が所定額以上のイベントの属性や出演者の属性を抽出してもよい。

例えば、ユーザＰ３が、バトルのイベントの課金額が１０００円以上であり、他の属性のイベント（例えば、クイズ、スポーツのイベント）の課金額が１０００円未満である場
合、ユーザＰ３に対して、バトルに関するイベントを告知することが、イベント事業者にとって運営上望ましい。本実施形態のサーバ２０によれば、ユーザＰ３にバトルの属性を抽出することができるので、ユーザＰ３にバトルに関するイベントを告知することができる。

また、ユーザＰ４が、出演者の属性がアイドルである場合のイベントの課金額が１０００円以上であり、他の属性の出演者（例えば、芸人、音楽家）であるときの課金額が１０００円未満である場合、ユーザＰ４に対して、アイドルに関するイベントを告知することが望ましい。本実施形態のサーバ２０によれば、ユーザＰ４にアイドルの属性を抽出することができるので、ユーザＰ４にアイドルに関するイベントを告知することができる。

（４）予想回数
また、サーバ２０は、ユーザ毎に、複数のイベントの属性の中から予想回数が所定回数以上のイベントの属性や出演者の属性を抽出してもよい。なお、ユーザの予想回数は、ユーザの予想情報に基づき特定することができる。

例えば、ユーザＰ５が、バトルのイベントの予想回数が１０回以上であり、他の属性のイベント（例えば、クイズ、スポーツのイベント）の予想回数が１０回未満である場合、ユーザＰ５に対して、バトルに関するイベントを告知することが、ユーザＰ５が意欲的にイベントに参加でき望ましい。本実施形態のサーバ２０によれば、ユーザＰ５にバトルの属性を抽出することができるので、ユーザＰ５にバトルに関するイベントを告知することができる。

また、ユーザＰ６が、出演者の属性がアイドルである場合のイベントの予想回数が１０回以上であり、他の属性の出演者（例えば、芸人、音楽家）であるときのイベントの予想回数が１０回未満である場合、ユーザＰ６に対して、アイドルに関するイベントを告知することが、ユーザＰ６が意欲的にイベントに参加でき望ましい。本実施形態のサーバ２０によれば、ユーザＰ６にアイドルの属性を抽出することができるので、ユーザＰ６にアイドルに関するイベントを告知することができる。

（５）ユーザ及び当該ユーザのフレンド
また、サーバ２０は、ユーザ毎に、ユーザ及び当該ユーザのフレンドの参加状況に基づいて、複数のイベントの属性の中から特定のイベントの属性を抽出する処理を行ってもよい。例えば、ユーザＰ１とユーザＰ２とがフレンド関係にある場合、ユーザＰ１及びユーザＰ２が参加したイベントを抽出する処理を行う。

また、サーバ２０は、ユーザ毎に、ユーザ及び当該ユーザのフレンドの参加状況に基づいて、複数の出演者の属性の中から特定の出演者の属性を抽出する処理を行ってもよい。例えば、ユーザＰ１とユーザＰ２とがフレンド関係にある場合、ユーザＰ１及びユーザＰ２が参加したイベントに出演した出演者を抽出する処理を行う。

（６）通知（告知）
本実施形態のサーバ２０は、ユーザ毎に、ユーザに対して抽出されたイベントの属性に関する情報（例えば、イベントの開催日時や内容）を、通知（告知）するようにしてもよい。

本実施形態のサーバ２０は、ユーザ毎に、ユーザに対して抽出された出演者の属性に関する情報（例えば、抽出された出演者が出演するイベントの開催日時や内容）を、通知（告知）するようにしてもよい。

なお、通知とは、告知を意味し、例えば、サーバ２０がユーザの端末１０にメッセージを通知してもよいし、ログイン後のユーザ端末１０に、当該ユーザに対して抽出されたイベントの属性に関する情報や出演者の属性に関する情報を表示するようにしてもよい。

５．６ フィルタリング
本実施形態のサーバ２０は、ユーザの参加状況に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行ってもよい。

（１）ログイン回数
例えば、サーバ２０は、ユーザのログイン回数に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行うようにしてもよい。例えば、ユーザのログイン回数が１０回以上という条件に該当するユーザを抽出するようにしてもよい。このようにすれば、ログイン回数に基づき、イベントに意欲的に参加するユーザを抽出することができる。

（２）予想情報
また、サーバ２０は、ユーザの予想ゲームの予想情報に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行うようにしてもよい。例えば、ユーザの予想回数が１０回以上という条件に該当するユーザを抽出するようにしてもよい。このようにすれば、予想回数に基づき、予想ゲームに意欲的に参加するユーザを抽出することができる。

（３）決済情報
また、サーバ２０は、ユーザの決済情報に関するフィルタリング条件に該当する特定のユーザを抽出する処理を行うようにしてもよい。例えば、ユーザの課金額が１００００円以上という条件に該当するユーザを抽出するようにしてもよい。このようにすれば、課金を多く行う傾向にあるユーザを抽出することができる。

（４）その他
また、サーバ２０は、フィルタリング条件を種々に設定することができる。例えば、特定のイベントの属性や、特定の出演者の属性をフィルタリングの条件に加えてもよい。

５．７ ユーザの動向調査
本実施形態のサーバ２０は、ユーザ情報記憶部２７３に記憶されている各ユーザの参加状況に基づいて、ユーザの動向を調査する処理を行ってもよい。サーバ２０において、調査された内容は、イベント事業者のイベントの企画や運営する上で重要なデータとなる。

（１）イベントの参加態様
例えば、サーバ２０は、ユーザ毎に、特定時点でのユーザのイベントの参加態様を特定するようにしてもよい。例えば、サーバ２０は、各ユーザのバトルの属性のイベントの結果発表時点での、ユーザのイベントの参加態様を特定し、どのような参加態様が多かったのかを判断するようにしてもよい。

（２）参照ページ
また、サーバ２０は、ユーザ毎に、特定時点でのユーザの参照ページを特定するようにしてもよい。例えば、サーバ２０は、各ユーザの予想ゲーム開始前の特定のタイミングにおいて、各ユーザの参照ページを特定し、各ユーザがどのような内容のページに関心があるのか、を判断するようにしてもよい。

（３）フレンド
また、サーバ２０は、ユーザ毎に、特定時点でのユーザ及び当該ユーザのフレンドの参加態様及び参照ページの少なくとも一方を特定するようにしてもよい。例えば、サーバ２
０は、ユーザとそのフレンドとの参加態様及び参照ページの少なくとも一方を特定することによって、ユーザとそのフレンドが、どのようなことに興味、関心があるのかを、判断するようにしてもよい。

５．８ フローチャート
サーバ２０の処理の一例を、図３２を用いて説明する。まず、サーバ２０は、Ｎに１を代入する（ステップＳ２１）。そして、第Ｎのユーザの参加状況に基づいて、第Ｎのユーザに対して、特定のイベントの属性を抽出する（ステップＳ２２）。第Ｎのユーザに対して、抽出されたイベントの属性に関する情報を告知する（ステップＳ２３）。

そして、サーバ２０は、第Ｎのユーザの参加状況に基づいて、第Ｎのユーザに対して、特定の出演者の属性を抽出する（ステップＳ２４）。第Ｎのユーザに対して、抽出された出演者の属性に関する情報を告知する（ステップＳ２５）。そして、全ユーザについて処理したか否かを判断し（ステップＳ２６）、全ユーザについて処理をしていない場合（ステップＳ２６のＮ）、Ｎに１を加算し（ステップＳ２７）、ステップＳ２２に戻る。全ユーザについて処理した場合（ステップＳ２６のＹ）、処理を終了する。

６．領地取得とチャット機能に関する詳細な説明
６．１ 概要
本実施形態のプラットフォームＰＦで、出演者の属性を「アイドル」、イベントの属性を「バトル」にした例における領地取得とチャット機能について、詳細に説明する。

上述したように、予想ゲーム毎に、イベント会場にいる各チームの出演者は、チームの領地を取得する。各チームの出演者は、各チーム用のスクリーンに表示されたメッセージ（各チームのユーザが投稿したメッセージ）のうち、取得すべき領地に関するメッセージを参考にする。しかし、スクリーンに膨大に流れるメッセージを見ても、結局はどの領地を狙えばよいのかわからなくなってしまうおそれがある。また、各チームのユーザも、出演者に対して自分の領地取得に関する意見を簡単に操作して伝えたいという要望がある。

そこで、本実施形態のサーバは、イベントの進行に応じて複数のキーワード（例えば、領地の番号）の候補を提示し、ユーザの端末においてユーザがキーワードを入力しやいように制御する。更に、サーバ２０は、投稿されたメッセージからキーワードを抽出して、出演者やユーザに対して、キーワードのランキングを提示するようにし、どのキーワードが注目されているのかを提示できるように制御する。

６．２ イベントの進行
本実施形態は、各チーム（各チームの出演者）が領地を取得する行動を行うことによって、イベントが進行する。

（１）領地について
まず、サーバ２０は、図３３に示すように、各端末１０や各チーム用のスクリーンに、各チームの領地獲得状況を示す画像を提示する。例えば、サーバ２０は、ユーザの各端末１０から領地獲得状況を示す画像の取得要求に応じて、当該画像を送信する。各端末１０は、サーバ２０から受信した当該画像を表示部に表示する。なお、サーバ２０は、会場のスクリーンに、当該画像を表示するようにしてもよい。

本実施形態では、説明の便宜上、各領地に、領地を識別するための番号を付している。なお、番号で領地を識別しているが、地名（例えば、県名）等によって領地を識別してもよい。

（２）領地の取得方法
本実施形態では、予想ゲーム毎に、領地獲得期間（例えば、図７のＲ６〜Ｒ７）において各チームに領地を取得させる。そして、各予想ゲームのミニゲーム終了後、各チームの点数Ｙを算出し、所与の順で、各チームに領地を取得させる。例えば、点数Ｙの高い順で、各チームに領地を取得させる。本実施形態では、一のチームに１つの領地を取得させると、次のチームに１つの領地を取得させる。

具体的に説明すると、予想ゲーム１のミニゲーム終了後、点数Ｙの高い順が青チーム、緑チーム、赤チーム、黄チームの順であるとすると、図３４に示すように、青チームが１番の領地を取得すると、次に緑チームが３２番の領地を取得し、次に赤チームが３３番の領地を取得し、次に黄チームが３７番の領地を取得するとする、といったように、各チーム１つの領地を取得する。そして、再度、青チームの順になり、青チームから順に領地を取得する。

なお、サーバ２０は、図３４に示すように、取得状況に関する情報（各チームの領地の取得タイミングと取得した領地の番号等）をサーバ２０の取得状況記憶部２７６に記憶する。

本実施形態では、チームの点数Ｙから１点を減算することを条件に、当該チームは空き領地を１つ取得することができる。また、チームの点数Ｙ（Ｙ≧２）から２点を減算することを条件に、当該チームは他チームの領地を１つ取得することができる。チームの点数Ｙが０に達すると領地を取得することはできないし、チームの点数が１点である場合であって空き領地がない場合は領地を取得することはできない。

（３）取得済の領地の識別表示
サーバ２０は、図３３に示すように、各チームが取得した領地を色によって識別表示する。例えば、サーバ２０は、青チームが１、２、３、４、５、６、７、８番の領地を取得している場合、１、２、３、４、５、６、７、８番の領地を青色で表示する。また、サーバ２０は、緑チームが２６、２７、３０、３１、３２番の領地を取得している場合、２６、２７、３０、３１、３２番の領地を緑色で表示する。また、サーバ２０は、赤チームが３３、３４、３５、３６番の領地を取得している場合、３３、３４、３５、３６番の領地を赤色で表示する。また、サーバ２０は、黄チームが３７、３８、３９番の領地を取得している場合、３７、３８、３９番の領地を黄色で表示する。

６．３ キーワードの候補の提示
サーバ２０は、チーム毎に、イベントの進行に応じてイベントに関する複数のキーワードの候補を提示する。なお、キーワードとは、インベトで重要な意味を持つワード（語句、言葉）であり、本実施形態においては領地の番号である。要するに、本実施形態のサーバ２０は、各チームの行動（領地取得）に応じて領地の番号の候補を提示する。

（１）候補の決め方
まず、サーバ２０が、チーム毎に、候補を決める手法について説明する。本実施形態のサーバ２０は、各チームが領地を取得することによってイベントが進行するので、各チームが領地を取得するタイミングで各チームの候補を決めて（更新して）提示するように制御している。

例えば、サーバ２０は、自チームの領地に隣接する領地を候補とする。候補となる領地は、空き領地に限らない。例えば、他チームの領地を候補にしてもよい。つまり、サーバ２０は、次のパターン（類型）に応じて、自チームの領地に隣接する領地を候補とする。

（パターン１）自チームに隣接する領地が「他チームの領地」である場合
（パターン２）自チームに隣接する領地が「空き領地」である場合
つまり、パターン１は、点数Ｙから２点を減算して取得する領地であり、パターン２は、点数Ｙから１点を減算して取得する領地であるので、２つのパターンそれぞれを候補として提示することが望ましいと考えられる。

図３５は、各チームが領地を取得するタイミングと、各チームが領地を取得するタイミングに応じて決定する各チームの領地の番号（キーワード）の候補の例を示す。例えば、予想ゲーム１において、最後のターン（順番）の青チームが番号８の領地を取得した時点をＫ２０とする。

そして、予想ゲーム２のミニゲーム終了後、緑チームの点数Ｙが７点、黄チームの点数Ｙが６点、青チームの点数Ｙが４点、赤チームの点数Ｙが３点と算出され、予想ゲーム２において、緑チーム、黄チーム、青チーム、赤チームの順で、領地取得を進行させるとする。

具体的に緑チームを例にとり説明する。予想ゲーム１において、最後のターンの青チームが番号８の領地を取得したＫ２０時点から、予想ゲーム２において緑チームが領地を取得する前の各チームの領地取得状況は、図３３に示す通りである。

ここで、サーバ２０は、時点Ｋ２０から予想ゲーム２において最初に緑チームが領地を取得するまでの間において、緑チームの候補を２５番、２９番に決定する。例えば、図３３に示すように、緑チームの領地（２６、２７、３０、３１、３２番）に隣接する領地は、２２、２３、２５、２８、２９番の領地であるが、すべて「空き領地」（パターン２）に該当する。

本実施形態のサーバ２０では、２２、２３、２５、２８、２９番の領地の中から、他のチームの領地（例えば、赤チーム３４番の領地）と隣接する２９番の領地を、１つの候補として抽出し、２２、２３、２５、２８、２９番の領地の中から、他のチームの領地と隣接しない２２、２３、２５、２８番の領地の少なくとも１つを（例えば、２５番の領地を）、１つの候補として抽出する。

また、サーバ２０は、空き領地が３つ以上である場合、直前に取得した領地に隣接する空きの領地の番号を、候補として抽出してもよい。

そして、緑チームが、Ｋ２１時点で領地２９番を取得したとする。なお、図３６は、緑チームが２９番の領地を取得したときの各チームの領地取得状況を示す。

サーバ２０は、緑チームが２９番の領地を取得したＫ２１時点から、黄チームが次の領地を取得するまでの間において、緑チームの候補を２５番と３４番に決定する。

例えば、図３６に示すように、緑チームの領地（２６、２７、２９、３０、３１、３２番）に隣接する領地は、２２、２３、２５、２８、３４番の領地であるが、３４番は、「他チームの領地」（パターン１）に該当し、２２、２３、２５、２８番は、「空き領地」（パターン２）に該当する。

本実施形態のサーバ２０では、２２、２３、２５、２８、３４番の領地の中から、「他チームの領地」（パターン１）に該当する領地（例えば、３４番）を、１つの候補として抽出し、「空き領地」（パターン２）に該当する領地（例えば、２５番の領地）を、１つの候補として抽出する。

そして、黄チームが、Ｋ２２時点で領地１１番を取得したとする。なお、図３７は、黄チームが１１番の領地を取得したときの各チームの領地取得状況を示す。

サーバ２０は、黄チームが１１番の領地を取得した時点Ｋ２２から、青チームが次の領地を取得するまでの間において、緑チームの候補を２５番と３４番に決定（維持決定）する。

例えば、図３７に示すように、黄チームが領地１１番を取得後、青チームが領地を取得するまで、緑チームの領地（２６、２７、２９、３０、３１、３２番）に隣接する領地に変化はないので、緑チームの候補を２５番と３４番に維持する。

そして、青チームが、Ｋ２３時点で領地９番を取得したとする。なお、図３８は、青チームが９番の領地を取得したときの各チームの領地取得状況を示す。

サーバ２０は、青チームが９番の領地を取得した時点Ｋ２３から、赤チームが次の領地を取得するまでの間において、緑チームの候補を２５番と３４番に決定（維持決定）する。

例えば、図３８に示すように、青チームが領地９番を取得後、赤チームが領地を取得するまで、緑チームの領地（２６、２７、２９、３０、３１、３２番）に隣接する領地に変化はないので、緑チームの候補を２５番と３４番に維持する。

そして、赤チームが、Ｋ２４時点で領地２９番を取得したとする。なお、図３９は、赤チームが２９番の領地を取得したときの各チームの領地取得状況を示す。

サーバ２０は、赤チームが２９番の領地を取得した時点Ｋ２４から、緑チームが次の領地を取得するまでの間において、緑チームの候補を２５番と２９番に決定する。

例えば、図３９に示すように、緑チームの領地（２６、２７、３０、３１、３２番）に隣接する領地は、２２、２３、２５、２８、２９番の領地であるが、２９番は、「他チームの領地」（パターン１）に該当し、２２、２３、２５、２８番は、「空き領地」（パターン２）に該当する。

本実施形態のサーバ２０では、２２、２３、２５、２８、２９番の領地の中から、「他チームの領地」（パターン１）に該当する領地（例えば、２９番）を、１つの候補として抽出し、「空き領地」（パターン２）に該当する領地（例えば、２５番の領地）を、１つの候補として抽出する。

特に、２９番の領地は赤チームに取られた領地である。緑チームのユーザは赤チームに取られた２９番の領地を取り戻したいという要望が強いと考えられる。そこで、Ｋ２４の時点から緑チームが領地を取得するまでの間、少なくとも２９番の領地を候補として提示することが望ましいといえる。

なお、パターン１の領地が複数存在する場合は、過去に自チームであった領地を優先的に候補として抽出してもよい。

本実施形態では、黄チーム、青チーム、赤チームについても緑チームと同じように候補を決める。

なお、サーバ２０は、チーム毎に、チームの領地に隣接する領地から、パターン１に該当する領地のみを候補として抽出してもよいし、チームの領地に隣接する領地から、パターン２に該当する領地のみを候補として抽出してもよい。また、サーバ２０は、チーム毎に、チームの領地に隣接する領地から、ランダムに２つの領地を候補として抽出してもよい。

（２）提示手法
例えば、サーバ２０は、チーム毎に、チームに所属するユーザの端末１０に、当該チームの候補の領地の番号を提示する。例えば、サーバ２０は、チームに所属するユーザの端末１０に、当該チームの候補の領地の番号を含むチャット画面を提示する。また、サーバ２０は、チーム毎に、チーム用のスクリーン（チーム用の表示部）に、当該チームの候補の領地の番号を提示する。例えば、サーバ２０は、チーム用のスクリーンに、当該チームの候補の領地の番号を含むチャット画面を提示する。つまり、本実施形態において、サーバ２０が候補の領地の番号等を「提示」するとは、候補の領地の番号等（例えば、候補の領地の番号を含むチャット画面）の情報をユーザ端末１０等に「送信」すること、ユーザの端末１０に候補の領地の番号等を「表示」させること、チーム用のスクリーンに候補の領地の番号等を「表示」させること等を意味する。

なお、サーバ２０は、メッセージ送信権限が「１」（有）に設定されたユーザに対して、候補の領地の番号を提示する。

例えば、Ｋ２０時点から緑チームが領地を取得するまでの間（Ｋ２０〜Ｋ２１の間）において緑チームの候補の領地の番号が２５番、２９番である場合、図４０に示すように、緑チームのチャット画面において、「２５番」の候補ＢＡと、「２９番」の候補ＢＢとを提示する。

（３）候補数
本実施形態のサーバ２０は、２つの領地を候補として提示するが、候補数は２つに限らず、３つ以上でもよい。

６．４ キーワードの選択を受け付け
端末１０は、各チームのユーザ毎に、ユーザから複数のキーワード候補の中からキーワードの選択を受け付け、選択された当該キーワードをメッセージの一部として受け付ける。

例えば、緑チームのユーザＰ１０（メッセージ送信権限が「１」（有）のユーザＰ１０）が、例えば、図４１（Ａ）に示すように、「次は」までは文字入力を行い、図４１（Ｂ）に示すように、ＢＢの入力エリアを入力（タッチ入力）して「２９番」を入力し、図４１（Ｃ）に示すように、「の領地だ！」の文字入力を再度行う。

このようにすれば、ユーザＰ１０が緑チームの出演者Ｎｏｒａに自分の意思を伝えるとともに、次の領地は「２９番」を望んでいることを簡易に入力することができる。つまり、本実施形態では、候補の入力エリアＢＢをタッチ入力するだけなので、ユーザが入力しやすい操作上の利点がある。

なお、ユーザＰ１０の端末１０は、ユーザＰ１０によって入力を受け付けたメッセージを、ユーザＩＤに対応付けてサーバ２０に送信する。サーバ２０は、当該メッセージを受信し、当該メッセージをユーザＩＤに対応付けてメッセージ記憶部２７５に記憶する。

６．５ キーワードのランキング
サーバ２０は、チーム毎に、ユーザＩＤに対応付けてメッセージを蓄積してメッセージ記憶部２７５に記憶し、メッセージ記憶部２７５に記憶されたメッセージからキーワードを抽出する。

図４２は、メッセージ記憶部２７５に記憶された、緑チームのメッセージの一例を示す。例えば、本実施形態のサーバ２０は、端末１０から受信したメッセージにメッセージを識別するためのメッセージＩＤを付与し、メッセージＩＤに対応付けて、メッセージ、ユーザＩＤ、日時（例えば、サーバ２０側の受信日時、或いは、端末１０側の送信日時）を記憶する。

そして、サーバ２０は、チーム毎に、イベントの進行に応じた期間のメッセージから、領地の番号（キーワードの一例）を抽出する。ここで、イベントの進行に応じた期間とは、領地の番号を抽出するための対象の期間であり、例えば、前回領地を取得した時点から現時点までの期間である。具体的に緑チームを例にとり説明すると、サーバ２０は、現時点が、予想ゲーム２において緑チームが未だ領地を取得していない場合、予想ゲーム１において、緑チームが最後の領地を取得した時点Ｋ１７から現時点までの期間、緑チームのメッセージから領地の番号を抽出する。

なお、イベントの進行に応じた期間は、自チームが前回領地取得した時点から現時点までの期間に限らず、いずれかのチーム（自チーム或いは他チーム）が前回領地を取得した時点から現時点までの期間でもよい。また、イベントの進行に応じた期間は、イベントを開始した時点から現時点までの期間でもよいし、実行中（実施中）の予想ゲームの期間（例えば、実行中の予想ゲーム２の開始時点から、同じ予想ゲーム２における現時点までの期間）でもよい。

例えば、サーバ２０は、現時点が、予想ゲーム２において緑チームが未だ領地を取得していない場合、予想ゲーム１において、緑チームが最後の領地を取得した時点Ｋ１７から予想ゲーム２のイベント進行中、緑チームが現時点までに蓄積されたメッセージから、領地の番号を抽出する。例えば、サーバ２０は、メッセージＩＤ＝１００１のメッセージ「次は２９番がいいと思う。」から、領地の番号「２９番」を抽出する。サーバは、メッセージＩＤ毎に、当該メッセージＩＤのメッセージから領地の番号を抽出する。

そして、サーバ２０は、領地の番号毎に、抽出された数をカウントする。例えば、メッセージＩＤ＝１００１のメッセージから、領地の番号「２９番」を抽出した場合、２９番の抽出数ＥＸに１を加算する。

サーバ２０は、チーム毎に、抽出数の多い順に、領地の番号（キーワード）のランキング（順位付け）を行う。図４３は、緑チームが最後の領地を取得した時点Ｋ１７から現時点（領地取得前）までの期間の緑チームの抽出数の多い順に並びかえてランキングされた、領地の番号と抽出数ＥＸとを示す。

図４３の例によれば、緑チームが最後の領地を取得した時点Ｋ１７から現時点（領地取得前）までの期間において、２９番の領地についてのメッセージ数が最も多いことがわかる。

そして、サーバ２０は、チーム毎に、チームのキーワードのランキングの結果（各キーワードの順位）を提示する。例えば、緑チームを例に説明すると、サーバ２０は、図４４に示すように、Ｋ１７時点から予想ゲーム２の現時点までの期間における蓄積されたメッセージから、抽出数の多い順に並べた領地の番号のランキングの結果ＲＡ（上位５位）を緑チームのユーザの端末１０や緑チームのスクリーンに提示する。特に、本実施形態では
、チャット画面に、ランキングの結果ＲＡを提示する。例えば、図４４によれば、緑チームのユーザや出演者は、２９番の領地が１位であり最も注目されていることを認識することができる。

なお、サーバ２０は、青、赤、黄チームにおいても、緑チームと同様に、自チームが前回領地を取得した時点から現時点までの期間における蓄積されたメッセージから、領地の番号を抽出し、抽出数の多い順に、領地の番号のランキングを行い、ランキング結果を各チームのユーザの端末１０や各チームのスクリーンに提示する。

なお、サーバ２０は、メッセージ送信権限が「１」（有）のユーザに対してランキングの結果を提示してもよい。また、サーバ２０は、メッセージ送信権限の値にかかわらず、メッセージ閲覧権限が「１」（有）のユーザに対してランキングの結果を提示してもよい。

６．６ キーワードの識別表示
本実施形態のサーバ２０は、受け付けたメッセージに含まれるキーワードを識別して提示する。例えば、図４０、図４４に示すように、チャット画面において表示される各メッセージについて、メッセージに含まれる領地の番号を太く大きく表示するようにする。

チャット画面では、五月雨式にメッセージが表示されるので、このように領地の番号を識別して提示することで、ユーザや出演者が瞬時に、どの番号の領地についてのメッセージであるのかを認識できるようにしている。

６．７ フローチャート
（１）キーワードの候補（領地の番号）の提示に関する処理の流れ
次に本実施形態において、サーバ２０がキーワードの候補を提示する処理の流れについて、図４５を用いて説明する。まず、いずれかのチームが領地を取得したか否かを判断する（ステップＳ３１）。いずれかのチームが領地を取得した場合（ステップＳ３１のＹ）、チーム毎に、キーワードの候補を決定し（ステップＳ３２）、チーム毎に、キーワードの候補を提示する（ステップＳ３３）。そして、イベントが終了したか否かを判断し（ステップＳ３４）、イベントが終了した場合（ステップＳ３４のＹ）、処理を終了する。一方、イベントが終了していない場合（ステップＳ３４のＮ）、ステップＳ３１に戻り処理を続行する。

（２）キーワードのランキングに関する処理の流れ
次に本実施形態において、サーバ２０が領地の番号（広義には、キーワードの候補）のランキングに関する処理の流れについて、図４６を用いて説明する。

まず、チーム毎に、前回領地を取得した時点から現時点までの期間のメッセージからキーワードを抽出する（ステップＳ４１）。そして、チーム毎に、キーワードの抽出数の多い順にキーワードを並べて、ランキングを行う（ステップＳ４２）。そして、チーム毎に、キーワードのランキングの結果を提示する（ステップＳ４３）。そして、イベントが終了したか否かを判断し（ステップＳ４４）、イベントが終了した場合（ステップＳ４４のＹ）、処理を終了する。一方、イベントが終了していない場合（ステップＳ４４のＮ）、ステップＳ４１に戻り処理を続行する。

６．８ 構成
（１）端末の構成
図４７に本実施形態のユーザの端末１０の機能ブロック図の一例を示す。なお、本実施形態のユーザの端末１０は、図４７の構成要素（各部）の一部を省略した構成としてもよ
い。なお、図４に示すユーザの端末１０の機能と同じ機能については、説明を省略する。

メッセージ送信部１２１は、ユーザからのメッセージをサーバ２０に送信する。また、メッセージ送信部１２１は、複数のキーワードの候補の中からキーワードの選択を受け付け、選択された当該キーワードをメッセージの一部とする。特に、本実施形態では、設定部１１３によって、メッセージ送信権限が有（１）に設定されている場合に、メッセージをサーバ２０に送信する。

表示制御部１２２は、サーバ２０から提示されたメッセージを表示する。特に、表示制御部１２２は、メッセージに含まれるキーワードを識別表示する。そして、表示制御部１２２は、サーバ２０から提示された複数のキーワードの候補を表示する。また、表示制御部１２２は、サーバ２０から提示されたキーワードのランキング結果を表示する。

（２）サーバの構成
図４８に本実施形態のサーバ２０の機能ブロック図の一例を示す。なお、本実施形態のサーバ２０は、図４８の構成要素（各部）の一部を省略した構成としてもよい。なお、図５に示すサーバ２０の機能と同じ機能については、説明を省略する。

キーワード記憶部２７４には、キーワード（領地の番号）が記憶される。なお、サーバ２０は、キーワード（領地の番号）に対応付けて、空き領地であるか否かを示す情報をキーワード記憶部２７４に記憶してもよい。

メッセージ記憶部２７５には、チーム毎に、チームに所属するユーザから受け付けたメッセージが記憶される。

取得状況記憶部２７６には、各チームの取得状況に関する情報が記憶される。つまり、取得状況記憶部２７６には、図３４に示すように、領地を取得する順番（ターン）に対応付けて、領地を取得したチームのチーム名、当該領地を取得した取得タイミング、取得した領地の番号（キーワード）が記憶される。

メッセージ受付部２３０は、ユーザからのメッセージを受け付ける。また、メッセージ受付部２３０は、複数のキーワードの候補の中からユーザによって選択されたキーワードをメッセージの一部として受け付ける。

提示部２３１は、チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チームに所属する各ユーザの端末に提示する。また、提示部２３１は、チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チーム用の表示部（スクリーン）に提示する。

提示部２３１は、チーム毎に、イベントの進行に応じてユーザが選択可能な複数のキーワードの候補を提示する。また、提示部２３１は、チーム毎に、キーワードのランキングの結果を提示する。また、提示部２３１は、チーム毎に、ランキング上位のキーワードを、候補の１つとして制御してもよい。提示部２３１は、メッセージ受付部２３０が受け付けたメッセージに含まれるキーワードを、識別して提示してもよい。

キーワード抽出部２３２は、メッセージ受付部が受け付けたメッセージを蓄積して記憶部（例えば、メッセージ記憶部２７５）に記憶し、チーム毎に、イベントの進行に応じた期間のメッセージからキーワードを抽出する。

キーワードランキング部２３３は、チーム毎に、キーワード抽出部２３２により抽出さ
れるキーワードの抽出数の多い順に並べてキーワードのランキングを行う。

６．９ 応用例
（１）領地取得
本実施形態のイベントにおいて、各チームは自チームに隣接しない領地を取得できるようにしてもよい。例えば、各チームに特別なカード（ジョーカーカード）を２枚付与し、出演者は、イベント（予想ゲーム１〜８）の中で、特別なカードを１枚消費（使用、減算）して、自チームの領地に隣接しない領地を取得できるようにしてもよい。つまり、各チームは、イベントを通して２回に限り、自チームの領地に隣接しない領地を取得できる。

（２）候補の決め方
本実施形態において、サーバ２０が、チーム毎に、自チームの領地に隣接する領地を候補とする例について説明したが、ランキング上位の領地を、候補の１つとしてもよい。

サーバ２０は、現時点において予想ゲーム２において緑チームが未だ領地を取得していない場合、予想ゲーム１において緑チームが最後の領地を取得した時点Ｋ１７から、予想ゲーム２の現時点（領地取得前）までの期間の緑チームのメッセージから、領地の番号を抽出している場合、現在１位である領地の番号（２９番）と、現在２位である領地の番号（２５番）とを、候補の領地として提示してもよい。このようにすれば、ランキングが上位である領地を、候補として提示することができる。

なお、本実施形態において、チームが領地を取得していない初期状態において、サーバ２０は、イベント開始時点（予想ゲーム１の開始時点）から、領地取得前の現時点においてランキング上位の領地を候補として提示してもよい。例えば、予想ゲーム１において、緑チームが未だ領地を取得していない場合、イベント開始時点から予想ゲーム１の現時点（領地取得前）までの期間の緑チームのメッセージから、領地の番号を抽出している場合、現在１位である領地の番号と、現在２位である領地の番号とを、候補の領地として提示してもよい。

７．その他
本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語として引用された用語は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。

１ ゲームシステム、１０ 端末、２０ サーバ、
ＰＦ プラットフォーム、
１００ 処理部、１１０ ユーザ登録部、１１１ チーム決定部、１１２ 予想情報制御部、１１３ 設定部、１２１ メッセージ送信部、１２２ 表示制御部、１３０ 画像生成部、１４０ 音生成部、１６０ 入力部、１６２ 検出部、１７０ 記憶部、１７１ 主記憶部、１７２ 画像バッファ、１８０ 情報記憶媒体、１９０ 表示部、１９２ 音出力部、１９６ 通信部、
２００ 処理部、２１０ 参加制御部、２１１ 仮想通貨制御部、２１２ 予想情報受付部、２１３ 判断部、２１４ パラメータ制御部、２１５ 設定部、２１６ 進行制御部、２１７ ユーザ情報管理部、２１８ 抽出処理部、２１９ 動向調査部、２２０ 決済制御部、２２１ 動画配信部、２２２ ＳＮＳ制御部、２２３ クラウドファンディング制御部、２３０ メッセージ受付部、２３１ 提示部、２３２ キーワード抽出部、２３３ キーワードランキング部、２７０ 記憶部、２７２ 主記憶部、２７３ ユーザ情報記憶部、２７４ キーワード記憶部、２７５ メッセージ記憶部、２７６ 取得状況記憶部、２８０ 情報記憶媒体、２９６ 通信部

Claims (6)

1. 複数のチームが順位を競うイベントに関するサービスを提供するサーバのためのプログラムであって、
   ユーザからのメッセージを受け付けるメッセージ受付部と、
   チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チームに所属する各ユーザの端末に提示する提示部として、コンピュータを機能させ、
   前記提示部が、
   チーム毎に、前記イベントの進行に応じて前記ユーザが選択可能な複数のキーワードの候補を提示し、
   前記メッセージ受付部が、
   前記複数のキーワードの候補の中からユーザによって選択されたキーワードを前記メッセージの一部として受け付けることを特徴とするプログラム。
2. 請求項１において、
   前記メッセージ受付部が受け付けた前記メッセージを蓄積して記憶部に記憶し、チーム毎に、前記イベントの進行に応じた期間の前記メッセージから前記キーワードを抽出するキーワード抽出部と
   チーム毎に、前記キーワード抽出部により抽出される前記キーワードの抽出数の多い順に並べて前記キーワードのランキングを行うキーワードランキング部として、コンピュータを更に機能させ、
   前記提示部が、
   チーム毎に、前記キーワードのランキングの結果を提示することを特徴とするプログラム。
3. 請求項２において、
   前記提示部が、
   チーム毎に、ランキング上位のキーワードを、前記候補の１つとすることを特徴とするプログラム。
4. 請求項１〜３のいずれかにおいて、
   前記提示部が、
   前記メッセージ受付部が受け付けた前記メッセージに含まれるキーワードを、識別して提示することを特徴とするプログラム。
5. 複数のチームが順位を競うイベントに関するサービスを提供するサーバであって、
   ユーザからのメッセージを受け付けるメッセージ受付部と、
   チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チームに所属する各ユーザの端末に提示する提示部と、を含み、
   前記提示部が、
   チーム毎に、前記イベントの進行に応じて前記ユーザが選択可能な複数のキーワードの候補を提示し、
   前記メッセージ受付部が、
   前記複数のキーワードの候補の中からユーザによって選択されたキーワードを前記メッセージの一部として受け付けることを特徴とするサーバ。
6. 複数のチームが順位を競うイベントに関するサービスを提供するサーバと、各チームに所属する各ユーザの端末とが、ネットワークを介して接続されるゲームシステムであって、
   前記サーバは、
   ユーザからのメッセージを受け付けるメッセージ受付部と、
   チーム毎に、チームに所属するユーザから受け付けたメッセージを、当該チームに所属する各ユーザの端末に提示する提示部と、を含み、
   前記提示部が、
   チーム毎に、前記イベントの進行に応じて前記ユーザが選択可能な複数のキーワードの候補を提示し、
   前記メッセージ受付部が、
   前記複数のキーワードの候補の中からユーザによって選択されたキーワードを前記メッセージの一部として受け付け、
   前記各ユーザの前記各端末が、
   ユーザからのメッセージを前記サーバに送信するメッセージ送信部と、
   前記サーバから提示された前記メッセージを表示する表示制御部と、を含み
   前記表示制御部が、
   前記サーバから提示された前記複数のキーワードの候補を表示し、
   前記メッセージ送信部が、
   前記複数のキーワードの候補の中からキーワードの選択を受け付け、選択された当該キーワードを前記メッセージの一部とすることを特徴とするゲームシステム。

Images