JP6651195B1 - 通信ゲームシステム及びプログラム等 - Google Patents

Abstract

【課題】 新しいコンセプトに基づく創造性のある通信ゲームシステムを提供すること【解決手段】 サーバと、そのサーバにネットワークを介して通信可能に接続する複数の端末を備える。端末は、その端末の表示部に複数の選択肢ｄ１をゲーム画面Ｇ５に表示する機能と、その複数の選択肢の中から選択された一つ（鹿が選択され、チェックマークｄ３）を特定する選択情報をサーバに通知する機能を備える。サーバは、複数の端末からそれぞれ送られてきた選択情報に基づき、複数の選択肢のそれぞれについて選択された投票数を求めるとともに、投票数が１の選択肢が存在する場合はその選択肢を選択したものを勝者とし、投票数が１の選択肢がない場合には投票数が最も少ない選択肢を選択したもの勝者とする。結果は、判定結果画面Ｇ６に表示する。【選択図】 図４

Description

本発明は、通信ゲームシステム及びプログラム等に関するものである。

例えば特許文献１に開示された「通信ゲームシステム、記録媒体およびプログラム」などのように、不特定多数のユーザが、ネットワークを通じて共通のフィールドに参加し、所定のルールに従ってゲームを行う通信システムが種々開発されている。

特開２００４−１６７１７２号公報

従来の通信ゲームシステムは、例えば既存のボードゲームや、スタンドアローンの家庭用ゲーム機でプレイされていたゲームをベースにし、開発されている。よって、従来にない新しいゲーム、新しいコンセプトに基づく創造性のあるゲームの提供が望まれている。

また、ゲームをプレイするユーザは、既存のボードゲームや家庭用ゲーム機をプレイする場合、それら家庭用ゲーム機が設置された現実空間に集まった特定の人たちである。これに対し、通信ゲームシステムをプレイする場合、ユーザは、一箇所に集まる必要は無く遠隔地にいる複数の人たちであり、不特定多数の場合もある。このように、通信ゲームは、ネットワークを介して繋がっているが、そのことが体感しにくい。

上述した課題はそれぞれ独立したものとして記載しているものであり、本発明は、必ずしも記載した課題の全てを解決できる必要はなく、少なくとも一つの課題が解決できれば良い。またこの課題を解決するための構成についても単独で分割出願・補正等により権利取得する意思を有する。

（１）上述した課題を解決するために、本発明に係る通信ゲームシステムは、サーバと、そのサーバにネットワークを介して通信可能に接続する複数の端末を備え、前記端末は、その端末の表示部に複数の選択肢を表示する機能と、その複数の選択肢の中から選択された一つを特定する選択情報を前記サーバに通知する機能を備え、前記サーバは、前記複数の端末からそれぞれ送られてきた前記選択情報に基づき、前記複数の選択肢のそれぞれについて選択された投票数を求めるとともに、その求めた投票数に基づいて勝者を決定する機能を備え、前記投票数に基づく勝者の決定処理は、投票数が１の選択肢が存在する場合はその選択肢を選択したものを勝者とし、投票数が１の選択肢がない場合には投票数が最も少ない選択肢を選択したもの勝者とするように構成した。

（２）前記複数の選択肢は、関係性のある複数のイメージを備えるグループを複数備え、前記サーバが、その複数のグループの中からランダムで決定した１つのグループを構成する前記複数のイメージであり、前記端末は、前記サーバからの指示に従い前記複数のイメージを指定された出現位置に表示する機能を備えるとよい。

（３）前記グループ構成する複数のイメージは、３個のイメージであり、その３個のうち２つは似たイメージでとし、残りの１つは異なるイメージとするとよい。

（４）前記複数の選択肢は、予め用意した関係性のあるＭ個のイメージの中からランダムで決定したＮ個（Ｎ＜Ｍ）のイメージであり、前記端末は、前記サーバからの指示に従い前記Ｎ個のイメージを指定された出現位置に表示する機能を備えるとよい。

（５）前記サーバは、前記出現位置をランダムに決定する機能を備え、前記複数の端末における前記複数のイメージの出現位置は、同一にするとよい。

（６）前記複数の選択肢の中から一つを選択する処理は、前記複数の選択肢を表示後の一定期間に行うようにし、前記一定期間内の途中で前記複数の選択肢の中で一番選ばれていない選択肢を報知する機能を備えるとよい。

（７）前記複数の選択肢は、複数の数字の組み合わせであり、直近に開催された過去の所定数のゲームの傾向情報を取得し、前記端末の前記表示部に報知する機能を備えるとよい。

（８）前記ゲームの傾向情報を分析し、一つの選択肢を選択する際に考える判断要素となる分析結果を前記端末の前記表示部に表示する機能を備えるとよい。

（９）本発明に係るプログラムは、上記の（１）から（８）のいずれかに記載の通信ゲームシステムを構成する前記端末に用いられる機能をコンピュータに実現させるためのプログラムとする。

本発明は、従来にない新しいゲーム、新しいコンセプトに基づく創造性のあるゲームを構成することができる。

本発明に係る通信ゲームシステムの好適な一実施形態を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 イージーモードのゲームを実施するためのフローチャートである。 イージーモードのゲームの実施に伴う端末の表示部に表示される表示画面の画面遷移図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 動物の部屋に属する複数のグループの一例を示す図である。 猫の部屋に属する複数のグループの一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 海の部屋に属する複数のグループの一例を示す図である。 ハードモードのゲームを実施するためのフローチャートである。 ハードモードのゲームの実施に伴う端末の表示部に表示される表示画面の画面遷移図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。 端末の表示部に表示される表示画面の一例を示す図である。

以下、本発明の好適な実施形態について図面に基づき、詳細に説明する。なお、本発明は、これに限定されて解釈されるものではなく、本発明の範囲を逸脱しない限りにおいて、当業者の知識に基づいて、種々の変更、修正、改良を加え得るものである。

図１に示すように、本実施形態の通信ゲームシステム１０は、ユーザが操作する端末１１が、ネットワーク１２を介してサーバ１３にアクセス可能に構成される。ネットワーク１２は、例えばインターネット網を利用するとよいが、公衆回線網や専用回線を用いてもよい。

端末１１は、ネットワーク１２に接続し通信を行う通信インタフェース１５と、所定の情報を表示する表示部１６と、入力部１７と、制御部１８と記憶部１９等を備える。端末１１は、例えばスマートフォン、タブレットその他の携帯端末とすると良い。当該携帯端末を用いた場合、端末１１を構成する通信インタフェース１５、表示部１６、入力部１７、制御部１８並びに記憶部１９は、携帯端末に標準装備された機器をそのまま使用する。入力部１７は、例えば表示部１６に重ねた配置されたタッチパネルで構成する。そして本実施形態のゲームに参加するための機能は、アプリとして実現する。そして、当該アプリを端末１１にインストールすることで、端末１１が通信ゲームシステム１０を実行可能となる。アプリをインストールすると、通信ゲームを実行するプログラムや、ゲームの進行に伴い表示するイメージデータ等が、記憶部１９に記憶保持される。

サーバ１３は、例えばウェブ・サーバでもあり、ネットワーク１２を介して接続した端末１１に実装された公知のウェブの閲覧機能と連動し、端末１１の表示部１６に所定の画面を表示し、ゲームを進行する。また、本実施形態では、多くの画像データ等を予めアプリをインストールした端末１１の記憶部１９に記憶保持させているため、必ずしもウェブ・サーバにすることはなく、サーバ１３側からは表示する画像デー等を特定する情報を送り、それを受けた端末１１側で必要な画面を生成し表示するようにしてもよい。そして、本実施形態のサーバ１３は、ネットワーク１２に接続し通信を行う通信インタフェース２１と、制御部２２と、ユーザ情報を記録するユーザデータベース２３等を備える。ユーザデータベース２３は、ユーザを一意に特定するＩＤやニックネーム等の特定情報と、性別，年齢，国籍等のユーザ情報と、ユーザが保有するコイン数と、ゲームのプレイ履歴（例えば、各ゲームへの参加数、勝利数等）などを記憶する。

この通信ゲームシステム１０で稼働するゲームは、「イノベーターズワールド」と称する。このイノベーターズワールドは、表示された複数の要素のなかから、参加者のみんなが選ばない要素を予想して当てるゲームであり、人と違う考え方ができる人（イノベータ）になる訓練を行えるゲームである。このゲームの勝敗は、ゲームに参加するプレイヤーが、自分以外が選ばない要素を選択し、オンリーワンとなった人が勝ち、オンリーワンとなるプレイヤーがいない場合には、最も投票数の少ない要素を選択したプレイヤーが勝つものとする。よって、例えば、三つの要素（ａ，ｂ，ｃ）の中から一つの要素を選択するゲームにおいて、二つの要素（例えばａ，ｂ）を選択したプレイヤーがそれぞれ一人ずついて、他の全てのプレイヤーが残りの要素（例えばｃ）を選択した場合には、ａ，ｂを選択したプレイヤーがともに勝者となる。また、例えば一つの要素（例えばａ）を選択したプレイヤーが０人で、他の要素（ｂ，ｃ）を選択したプレイヤーがそれぞれ複数人ずついた場合、オンリーワンとなるプレイヤーがいなく、最も投票数の少ない要素（例えばａ）を選んだプレイヤーもいないため、参加者全員が負けとなる。

以下、上記の以下、ユーザが行う具体的な処理を説明しつつ、端末１１並びにサーバ１３の機能をさらに説明する。また、本形態では、端末１１は、スマートフォンから構成し、そのスマートフォンに「イノベーターズワールド」を実行するためのアプリをインストールしておく。ユーザは、図示省略する端末１１の表示部１６に表示したアプリのアイコンをタップする。端末１１の制御部１８は、当該アイコンのタップを検知すると、「イノベーターズワールド」を起動する。後述するように、ゲームに参加する場合には、最初にユーザに関する所定の情報をサーバ１３に登録する。そして、本形態では、ユーザは、イノベーターズワールドに参加するすべてのユーザの中から一意に特定するＩＤとニックネームを持つ。そこで制御部１８は、例えば初期登録時の適宜のタイミングで、端末１１の記憶部１９にサーバに登録したニックネーム等のユーザを特定する特定情報を記憶させる。

そこで制御部１８は、アプリを起動したら、例えば記憶部１９にニックネーム等の特定情報が記憶されているか否かを確認し、初回ログインか否を判断する。特定情報が記憶されていない場合、制御部１８は、初回ログインと判断する。

初回ログインの場合、端末１１の制御部１８は、表示部１６に登録トップ画面Ｇ１（図２（ａ）参照）を表示する。この登録トップ画面Ｇ１を初め、以下に説明する各画面を構成する要素等は、アプリのインストール時に記憶部１９に記憶保持する。登録トップ画面Ｇ１は、ゲームについてのメッセージと、ニックネーム登録ボックスａ１と、決定ボタンａ２等を備える。ユーザは、端末１１の入力部を操作しニックネーム登録ボックスａ１に使用を希望するニックネームを入力し、決定ボタンａ２をタップする。端末１１の制御部１８は、決定ボタンａ２のタップを検知すると、ニックネーム登録ボックスａ１に入力されているニックネームをサーバ１３に送信する。

サーバ１３の制御部２２は、ニックネーム等の情報を受信すると、ユーザデータベース２３にそのユーザに関する情報を登録する。すなわち、サーバ１３の制御部２２は、端末１１の制御部１８と通信し、端末１１の表示部にユーザ情報を登録するために必要な入力画面や説明画面等を表示し、必要な情報を取得し、記録する。また、ユーザが保有するコイン数は、初期値は０枚とする。また、具体的な手順の説明を省略するが、端末１１とサーバ１３は通信を行い、ユーザは、端末１１の表示部１６に表示した初期登録画面を用いて初期登録のための必要な情報を入力する。そして、端末１１は、入力された情報をサーバ１３に送り初期登録を行う。

上記の初期登録が完了した場合や、初回ログインでない場合、端末１１は、表示部１６にタイトル画面Ｇ２（図２（ｂ）参照）を表示する。タイトル画面Ｇ２は、スタートボタンａ３を備える。スタートボタンａ３がタップされたことを検知した端末１１の制御部１８は、図省略するゲームモード選択画面を端末１１の表示部１６に表示する。本実施形態では、ゲームモードは、イージーモードとハードモードの２つのモードを備える。

ユーザは、表示されたゲームモード選択画面を操作し、プレイするモードを選択する。端末１１は、モード選択画面で選択されたモードのトップ画面を端末１１の表示部１６に表示する。

また、本実施形態では、図２（ｂ）に示すタイトル画面Ｇ２のスタートボタンａ３がタップされると、ゲームモード選択画面を表示するようにしたが、例えば、後述するように各ゲームモードのトップ画面で別のモード画面への切り替え機能を備えるので、スタートボタンａ３がタップされた場合の画面遷移先として、例えば、予め設定したゲームモード（例えばイージーモード）を表示するようにすると良い。このようにすると、設定したゲームモードをＰＬＡＹするユーザにとっては、ゲーム開始までの操作回数が少なくて良く、ゲームモードのトップ画面で別のモードに切り替え可能にすることで、設定したゲームモードをＰＬＡＹしないユーザにとってもゲームモード選択画面を介してゲームモードを選択する場合と変わらない操作回数で済むので良い。さらに、図２（ｂ）に示すタイトル画面Ｇ２に替えて、例えば図１９に示すようにモード選択ボタンａ４を備えた画面を表示すると良い。

イージーモードは、所定数（例えば３個或いは５個）の選択肢の中から１番選ばれないものを予測して遊ぶモードである。後述するように、選択肢は共通のカテゴリーのグループに属する要素をあらわすイメージである。同一のカテゴリーに属する各イメージは、イメージに対する印象等により、イメージ自体に選択されやすさの程度が相違するようなものとすると良い。イージーモードのゲームは、無料（消費コイン無し）で参加でき、勝つと３コインをもらえる。ケットしたコインは、例えばハードモードのゲームをプレイする際に使用する。

ハードモードは、９つの数字の中から１番選ばれないものを予測して遊ぶモードである。ハードモードは、イージーモードに比べて選択肢の数が増えると共に、イージーモードの選択肢を構成するイメージに比べ、個々の数字自体の選択されやすさのばらつきは小さいため、予測がより難しくなる。ハードモードのゲームは、１回プレイ（投票）するのに３コイン消費し、勝者が所定のコインをゲットする。ユーザは、３コインをベットしてプレイする。

このとき使用するコインは、例えば、イージーモードに参加し、勝利した際にゲットしたものを使用する。そして、上述したように、イージーモードのゲームをプレイする際にコインは不要であるので、無料でゲームに参加することを繰り返し、コインを貯めることができる。また、係るコインは、例えば、通信ゲームシステム内などで画面内にバナーを表示し、バナーをクリックしてバナーにリンクした広告を表示することにともないコインをゲットする機能を備えると良い。例えばサーバは、クリックした回数をカウントし、ユーザデータベース２３に登録し、例えばクリック数がＭ回（Ｍは１以上の整数）になると３コインと交換する機能を備えると良い。この交換は、自動的に行うようにしてもよいし、ユーザからの指示に基づいて行うようにしてもよい。さらに、課金によりコインをゲットする機能を有すると良い。

［イージーモード］
イージーモードが選択された場合、端末１１とサーバ１３がデータの送受を行い、図３に示すフローチャートを実行し、ゲームを進行する。図４は、ゲームの進行に伴い端末１１の表示部１６に表示する画面の状態遷移図である。

イージーモードが選択されると、端末１１は、表示部１６にイージーモードトップ画面Ｇ３を表示する。イージーモードトップ画面Ｇ３は、上から順に第一ゲーム選択領域ｂ１，第二ゲーム選択領域ｂ２，第三ゲーム選択領域ｂ３を配置するレイアウトをとる。図示の例では、第一ゲーム選択領域ｂ１には「動物をカテゴリーとする選択肢が３個のゲーム」を選択するためのアイコンが割り当てられ、第二ゲーム選択領域ｂ２には「猫をカテゴリーとする選択肢が５個のゲーム」を選択するためのアイコンが割り当てられ、第三ゲーム選択領域ｂ３にはゲームの割り当てを行っていない。また、ゲーム選択領域は、本形態では３個としたが、４個以上配置しても良く、１画面中に同時に表示できない場合、例えば画面スクロールにより表示を切り替えるようにすると良い。

さらにイージーモードトップ画面Ｇ３は、その表示画面の上端近傍にモード切替ボタンｂ４を配置する。このモード切替ボタンｂ４がタップされると、端末１１は、プレイするゲームモードを切替、表示部１６にハードモードトップ画面Ｇ１１を表示する（図１４参照）。

ユーザは、表示部１６に表示された所望のゲーム選択領域をタップし、ゲームの部屋を選択する（Ｓ１）。端末１１は、タップされたゲーム選択領域を認識し、選択されたゲームの種類を例えばニックネームと共にサーバ１３に通知する。サーバ１３は、通知を受けたユーザを特定する特定情報を含む参加者情報を取得し、通知を受けたゲームの部屋に参加者として登録する（Ｓ２）。取得する参加者情報は、参加者の国籍、ニックネーム、戦績（参加試合数と勝利数）などがある。サーバ１３の制御部２２は、例えば取得したニックネームをキーにユーザデータベース２３にアクセスし、国籍と戦績等を取得する。サーバ１３は、Ｓ２の処理を実行して参加者を登録することで、ゲームの部屋の参加者リストを更新する。サーバ１３の制御部２２は、参加者が一人入った場合（時に）待機時間をスタートする。待機時間は、例えば１５秒とすると良い。すなわち、本実施形態では、待機している人がいない０人のゲームの部屋に入ると、参加者のグループが形成され、待機期間中にその後に入ってくる参加者とのマッチングをとる。また、後述するように待機時間が経過してマッチングされた参加者同士で実際のゲームの投票期間が開始してすると、そのゲームの部屋の参加者は０人になる。よって、係る実際のゲームが開始している際に、同じゲームの部屋に参加者が入ってくると、別の参加者のグループが形成され、他の参加者を待つ。

端末１１は、ゲームの部屋に登録した際に、サーバ１３が保有する現在の参加者リストを取得し、取得した情報に基づき表示部１６に表示する参加者情報画面Ｇ４を表示する（Ｓ３）。参加者情報画面Ｇ４は、表示画面の上方から順に、第一表示領域ｃ１、第二表示領域ｃ２、第三表示領域ｃ３、第四表示領域ｃ４を備える。第一表示領域ｃ１には、その中央にタイトル（図示の例では、「ＭＡＴＣＨＩＮＧ」）を表示し、右端にユーザが持つコイン数（図示の例では「２０」）を表示する。第二表示領域ｃ２には、参加中のゲームを示す画像を表示する。第三表示領域ｃ３には、左側に待機時間の残り時間に関する情報（アイコンと、時間（図示の例では「０９秒」）を表示し、右側に参加人数に関する情報（アイコンと、人数（図示の例では、「３人」）を表示する。第四表示領域ｃ４には、取得した参加者リストに基づき、ゲームの部屋の登録している各参加者の参加者情報（ここでは、国籍、ニックネーム、戦績）をリスト表示する。

また、端末１１は、あるゲームの部屋に登録した際に、待機時間の残り時間に関する情報も取得する。取得した情報に基づき、参加者情報画面Ｇ４の第三表示領域ｃ３の左側に、待機時間の残り時間を適切な数値で表示する。端末１１は、内部時計やタイマー等に基づき待機時間の残り時間の表示を適宜更新する。例えば内部のタイマーを備える場合、取得した待機時間の残り時間を当該タイマーにセットし、スタートする。タイマーは時間の経過に伴い０に近づくように数値が減少するものであり、端末１１の制御部１８は、そのタイマーの値を、第三表示領域ｃ３の左側の所定位置に表示する。

また、端末１１は、あるゲームの部屋に登録した後は、定期的にサーバ１３から自己が参加しているゲームの部屋の参加者リスト等を取得し、取得した情報に基づき表示部１６に表示する参加者情報画面Ｇ４を更新する。また、端末１１が定期的にアクセスするのではなく、参加しているゲームの部屋に新たに登録した参加者が発生した場合に、サーバ１３が、参加者情報の一覧或いは新たに参加した参加者の参加者情報を所定の端末１１に送信することで、端末１１が参加者情報を取得し一覧表示するようにしてもよい。

上述したように、端末１１は、定期的に処理ステップＳ３を実行するため、ユーザがゲームの部屋を選択したときに、既に参加している参加者の一覧表を第四表示領域ｃ４に表示し、その後の待機時間中に新たにゲームの部屋に登録した参加者が来ると、新たな参加者を含む参加者リストを表示する。

ユーザは、ゲームの部屋に登録し参加者になったなら、その部屋に所定の人数以上の参加者が集まるのを待つ（Ｓ４）。

また端末１１は、ゲームの部屋に登録した参加者の人数が、ゲーム開始条件を満たすのを待つ（Ｓ５）。ゲーム開始条件は、例えば、待機時間を経過した際に最低参加人数に達していた場合とすると良い。待機時間は、例えば１５秒とし、最低参加人数が４人とした場合、各端末１１は、例えば第三表示領域ｃ３に表示するための情報（残り時間，参加人数）に基づき参加者が集まったか否かを判断する。待機時間の経過は、例えば内部タイマーが０になったことにより判断すると良い。このようにすると、待機時間が経過するまでは待機することになる。よって、最初に登録した人は、待機時間（例えば１５秒）を必ず待つことになり、待機期間中に登録したユーザは、そのときの残り時間だけ待つことになる。

このように必ず待機時間を待つのでは無く、参加者人数が所定の基準値を以上になった場合には待機時間を経過する前に始めても良い。所定の基準値は、最低参加人数よりも多い人数とする。このようにすると、一度にたくさんの人が参加してきた場合、待機時間を経過する前にゲームが開始されるので、少ない待ち時間でプレイすることができるので良い。一方、ゲームに参加する人数があまりに少ないと、ゲームの面白みに欠けるので、待機時間を待っても最低参加人数に満たない場合、ゲーム不成立とすると良い。なお、参加人数に関係なく待機時間を経過したときにゲームを開始するようにしてもよい。

参加者が集まった場合、端末１１は、ゲーム画面に移行する（Ｓ６）。端末は、最終的に選択肢の選択をするゲーム画面Ｇ５を表示する前に、移行中を示す画面を表示する。この移行中を示す仮面は、例えば、「３」→「２」→「１」のようにカウントダウンをする表示とし、ユーザに所定数の選択肢が表示されることに対する心の準備をさせると良い。

次いで端末１１は、所定数（３個或いは５個）の選択肢を所定位置に配置したゲーム画面Ｇ５を表示する（Ｓ７）。配置する所定数の選択肢からなるイメージ群は、今回のゲームの部屋に最初に参加者が登録された際に、サーバ１３が決定する。具体的な決定処理の内容については後述する。

この決定したイメージ群の情報は、それぞれの端末１１がサーバ１３にアクセスし、そのゲームの部屋に参加登録した際に、参加者情報の一覧リストとともにあわせて取得する。また、サーバ１３は、イメージ群と共にゲーム画面Ｇ５に使用する背景画面も決定し、イメージ群の情報と共にあわせて使用する背景画面を特定する情報もあわせて端末１１に送る。端末１１は、待機時間のタイムアップに伴い、最初に取得していたイメージ群の情報に基づき、端末１１の記憶部１９に記憶している選択肢の要素のイメージや背景画面を読み出し、それらを組み合わせてゲーム画面を作成し、表示部１６に表示する。

ゲーム画面Ｇ５は、画面の全面に背景画面を表示し、その背景画面に重ねて所定数（図３に示す例では３個）の選択肢ｄ１を三角形の各頂点の位置に表示し、背景画面に重ねて上方部位に、インジケータｄ２を表示するレイアウトをとる。このゲーム画面Ｇ５は、同じゲームに参加しているすべての端末１１で同じにする。すなわち、このゲーム画面Ｇ５に表示する背景画面と、イメージ群を構成する各イメージと、そのイメージを配置する位置は、すべての端末で同じである。

図示の例では、「動物をカテゴリーとする選択肢が３個のゲーム」であるため、選択肢ｄ１として動物を構成する３つの要素（図示の例では、「イノシシ」，「鹿」，「蝶」）のイメージを表示する。またインジケータｄ２は、ユーザが選択肢を選択可能なシンキングタイムの残り時間を表示するためのものである。シンキングタイムは、例えば１０秒程度の短い時間とすると良い。短い時間とすることで、直感的にみんなが選択しなさそうな要素を判断する直感力が鍛えられる。また、１回のゲームに要する時間が短いため、ユーザは、何回も遊ぶことができる。特に、イージーモードの参加は、コインが不要であるので、短時間で繰り返し遊ぶことで、直感力をより鍛えると共に、勝者になる回数も増え、効率よくコインを貯めることができる。

ユーザは、表示されたゲーム画面Ｇ５に表示された３つ或いは５つの選択肢ｄ１の中から１つ選ぶ（Ｓ８）。選択肢ｄ１の選択は、例えば、表示された選択肢ｄ１の要素のイメージの部分をタップすることで行う。

端末１１は、ゲーム画面に切り替わりシンキングタイム中は、時間の経過に伴いインジケータｄ２の表示態様を徐々に切り替えると共に、表示された選択肢ｄ１のいずれかがタップされたのを検知すると、そのタップ位置からユーザが選択した要素を認識し、選択された選択肢ｄ１の付近にチェックマークｄ３を表示すると共に、その選択情報を保持する（Ｓ１０）。端末１１は、シンキングタイムが終了すると（Ｓ１０）、保持している選択情報をサーバ１３に送る（Ｓ１１）。

サーバ１３は、ゲームに参加している各端末１１から送られてくる選択情報を集計する（Ｓ１２）。サーバ１３は、送られてきた選択情報の数、すなわち、投票数が最低投票数を満たしたか否かを判断する（Ｓ１３）。ゲームの部屋に入った参加者が、実際にタップをせずに選択しなかった場合、選択情報が無いので端末１１は「投票しなかった」という情報を送信する。よって、実際に投票した人数は、ゲーム開始時の参加者の人数よりも少ない場合があり、実際に投票した人数が最低投票数に達しない場合（Ｓ１３でＮｏ）、今回のゲームは不成立となり、今回のゲームの部屋を一旦閉じる。そして、処理ステップＳ１に戻り、端末１１はイージーモードトップ画面Ｇ３を表示し、ユーザは改めて部屋の選択を行う。最低投票数は、例えば処理ステップＳ５における最低参加人数と同じとすると良い。

一方、実際に投票した人数が最低投票数を満たした場合、サーバ１３は３つ或いは５つの各選択肢に対して選択した参加者の人数をそれぞれ求め、勝者を判定する（Ｓ１４）。すなわち、ある選択肢に投票したユーザが１人の場合、サーバ１３は、そのユーザを勝者にする。また、投票したユーザが一人の選択肢が複数存在する場合、その複数の選択肢に投票したそれぞれのユーザがともに勝者となる。そして、投票したユーザが０人の選択肢がある場合、勝者は無しとなる。そして、すべての選択肢に対して、投票者が複数いる場合、最も投票数の少ない選択肢の要素を選択したユーザを勝者にする。

勝者の判定（勝者なしも含む）の結果に基づき、サーバ１３の制御部２２は、勝者にコインを配布する（Ｓ１５）。具体的には、ユーザデータベース２３に記録している勝者のユーザの保有コイン数を１加算する（Ｓ１６）。

また、サーバ１３は判定結果を端末１１に送る。端末１１は、サーバ１３から判定結果を取得し、判定結果画面Ｇ６を表示する（Ｓ１７）。判定結果画面Ｇ６は、上方に勝者報酬表示部ｅ１を配置し、中央に投票結果表示部ｅ２を配置し、下方に操作ボタンｅ３を配置するレイアウトとする。勝者報酬表示部ｅ１は、勝者となったユーザの端末１１の場合、報酬であるコインが１個ゲットされたことを通知する。敗者ユーザの端末１１の場合、勝者報酬表示部ｅ１は空欄のままとなる。

投票結果表示部ｅ２は、各選択肢のイメージを並べるとともに、各イメージの下に投票数を表示し、勝者の選択肢の上に勝利を示す勝者マークを表示する。勝者マークは、本実施形態では、王冠を模した図としている。さらに自分が選択した選択肢がわかるような選択要素報知部もあわせて表示する。選択要素報知部は本実施形態では、イメージの外周を囲む所定の色（例えば赤色）からなる枠体と、チェックマークを用い、さらに、投票数の表示色も異なる色（例えば赤色）としている。このように複数の異なる報知態様をとることで、ユーザは自分が選択した要素を容易に確認でき、勝ったか否かも直感的に理解出来る。図示の例では「鹿」と「イノシシ」の投票数がそれぞれ１人ずつであり、両者がともに勝者となっている。また、参加者情報画面Ｇ４では参加人数が３人であるところ、一人が投票せず最終の投票人数は２人であるとがわかる。なお、図示の便宜上、参加人数が３人で、投票数が２人の例を示したが、実際には、最低参加人数や最低投票数はもっと大きい数字（例えば何れも４人以上）にし、３人ではゲームが開始せず、２人では最低投票数に達しないようにすると良い。

操作ボタンｅ３は、本実施形態では、３個のボタンを備える。左のメニューボタンは、イージーモードトップ画面Ｇ３に戻るためのボタンであり、異なるゲームのプレイを可能にする。中央の「PLAYAGAIN」ボタンは、同じゲームをもう一回ＰＬＡＹするためのボタンであり、端末１１は当該ボタンのタップを検知すると参加者情報画面Ｇ４を表示する。

また、イージーモードでは、選択肢ｄ１の選び直しを許容するように構成すると良い。イージーモードは、比較的簡単で初心者も気軽に遊べることを目的の一つとしており、あまり熟考せず、直感的に選択することも多々ある。そのため、ユーザは、一度選択した後で、気が変わることもあり得る。そこで、上述したように選択肢ｄ１の選び直しができる機能を備えると良い。選び直すための機能は、例えば、最後にタップしたものを最終的な選択した選択肢に認定し、選択情報として保持すると良い。例えば、選択したものを一旦キャンセルし、その後で改めて選択するようにし、選び直す意思表示をしっかりとさせるように構成しても良いが、複数回の選択（タップ）を許容し、最後にタップしたイメージの要素を最終的な選択肢とするようにすると操作が簡単になるので良い。特に、シンキングタイムが例えば１０秒などと短い時間であるので、キャンセル操作を行わせるとキャンセルした状態でタイムアップして参加できない事態を生じるおそれがあるが、最後にタップした選択肢を有効にするように構成すると、かかる問題を生じないので良い。

上述したように、ユーザが処理ステップＳ９を実行してある選択肢をタップすると、端末１１はタップされた選択肢の要素を特定する選択情報を保持する。そこで図示の例では、端末１１は、一つの選択肢の要素である「鹿」の付近にチェックマークｄ３を表示する。端末１１は選択情報を保持するので、ユーザがその後画面をタップしなければ、端末１１はタイムアップと共にその「鹿」を選択情報として送る。一方、「鹿」が選択された状態で「蝶」或いは「イノシシ」のように別の要素をタップすると、選択情報は新たにタップされた要素(「蝶」或いは「イノシシ」)に書き換えられる。

さらに本実施形態では、シンキングタイム中にユーザに対して選択肢を選ぶための情報を提供する機能を備える。選択肢を選ぶための情報は、例えば、今まで一番選ばれていない選択肢の要素を報知するものとするとよい。

一番選ばれていない選択肢の要素の報知の仕方は、例えば、図５に示すように、該当する要素のイメージの近傍に、所定のチャンスマークｄ５（例えば星印）を表示すると良い。近傍は、星の一部がイメージに重なるようにすると良い。一番選ばれていない選択肢の要素の報知を行う場合、そのゲームに参加しているすべてのユーザの端末に対し、同じタイミングで行う。

一番選ばれていない選択肢を求めるため、サーバ１３は、所定数の選択肢を決定すると、各端末１１から参加者の過去に選択した要素毎の投票数を取得し、それらを集計することで求める。すなわち、例えば端末１１は、各選択肢の要素毎の投票の履歴情報を記憶保持し、処理ステップＳ１１の選択情報を送信する都度、対応する要素の投票数を１加算する処理を実行する。そして、サーバ１３から今回のゲームに使用する所定数の選択肢の要素の情報を取得すると、端末は対応する選択肢の要素の投票数を送信する。

サーバ１３は、待機時間が終了した際に、各端末１１から取得した投票数の情報に基づき、イメージ群を構成する各選択肢のイメージ・要素の中で今回の参加者が一番選ばれていない選択肢を求める（Ｓ１８）。そして、サーバ１３は、求めた選択肢を特定する情報を端末１１に送信する。

端末１１は、受信した一番選ばれていない選択肢を特定する情報に基づき、所定のタイミングで該当する選択肢のイメージの近傍に星印等のチャンスマークｄ５を付記した画面を生成し、表示部１６に表示する（Ｓ１９）。

このように一番選ばれていない選択肢の要素を報知することで、目立たせて選ばれやすくしたり、裏を読んで別のものを選択させたりするようになり、ユーザに対して単純な直感だけでなく、推理も働かせることができ、より趣のあるゲームとなるので良い。一番選ばれていない選択肢の要素の報知を行う場合、その要素が目立つようにするとよい。目立つようにすると、ユーザの注意がより向くので、選択する際の有用な情報となるので良い。

一番選ばれていない選択肢の要素を報知するタイミングは、例えば２回に１回のように定期的に行っても良いし、毎回としてもよいが、ランダムとするとより好ましい。さらに、一番選ばれていない選択肢の要素を報知する場合でもシンキングタイムの最初から報知するのではなく、制限時間の途中で報知（チャンスマークｄ５の表示）をすると良い。例えば、制限時間の１/３を経過したタイミングでチャンスマークｄ５を表示し、最後まで表示するとよい。

このように途中でチャンスマークｄ５を表示すると、最初は係る情報が無い状態で選択しようとしたところ、新たな情報が追加されることで、単純に今までの考えをそのまま通すことが行いにくくなり、ゲームの意外性・面白みが増すので良い。例えば、ゲーム開始の早い段階で、直感等に基づいて投票済みの参加者は、途中で人気のないものがわかることで、そのまま行くか選択し直すかを悩み、正解に近づけるのでより好ましい。途中で報知することで、そこで新たに悩ますことができるので良い。

上述したように一番選ばれていない選択肢の要素を報知するタイミングをランダムにし、しかも、シンキングタイムの途中で報知するようにすると、ゲームの開始直後は、今回のゲームで一番選ばれていない選択肢の要素が報知されるか否かが不明のため、係る報知が行われるか否かも気にしながら選択肢を考えることもあるのでスリルや面白みが増すので良い。

星印等のチャンスマークｄ５を表示しようとした際に、３つ或いは５の要素のうち、複数の要素が同数で最少の場合、複数の要素についてそれぞれに表示しても良いが、表示しないようにすると良い。特に選択肢が３つの場合、２つ要素の選択数が同数の場合に、その２つの要素に星印等のチャンスマークｄ５を表示すると、かえって表示しない１つの要素が目立つので、敢えて表示しないようにすると良い。また、参加者の経験数（プレイ回数）に応じて、チャンスマークｄ５を表示する頻度・確率を変えると良い。

また、上述した実施形態では、一番選ばれていない選択肢を報知するようにしたが、例えば三角形の頂点など、各イメージを表示する場所の中で一番選ばれていない場所を報知するようにしてもよい。

また、イージーモードトップ画面Ｇ３において、第二ゲーム選択領域ｂ２がタップされると（図３のＳ１）、通信ゲームシステムは、図３に示す処理フローを実行する。そして、端末１１は、処理が進むにつれ、表示部１６に参加者情報画面Ｇ４を表示し、さらにゲームが開始されるとゲーム画面Ｇ５を表示する。第二ゲーム選択領域ｂ２に対応づけられたゲームは、「猫をカテゴリーとする選択肢が５個のゲーム」であるので、サーバ１３の制御部２２は、処理ステップＳ６を実行し、猫というカテゴリーに属する５個の選択肢の要素のイメージを抽出し、イメージ群を決定する。そして、サーバ１３の制御部２２は、例えば図６に示すように背景画面上のイメージの出現場所（右下、左下、右中、左中、上）に抽出した各洋装のイメージを配置したゲーム画面を作成する。端末１１は、このゲーム画面Ｇ５を表示部１６に表示する。図示の例では、チャンスマークｄ５も表示された状態を示している。

ゲームの部屋に登録し、参加者を待つ待機時間を経過した際に、参加者数が最低参加人数に満たない場合、ゲーム不成立としても良いが、足りない参加人数分については、サーバが参加者となりゲームを開始するようにすると良い。サーバ側の参加者は、ランダムに選択肢を選択することで、上述した処理を実行し勝者を判定する。このようにすると、参加人数が少なくてゲーム不成立になることがなく、ゲームの部屋に登録したユーザは必ずＰＬＡＹできるので良い。

次に、処理ステップＳ６の具体的な処理について説明する。まず、上述したように本実施形態では、第一ゲーム選択領域ｂ１に対応する「動物の部屋」の３択ゲームと、第二ゲーム選択領域ｂ２に対応する「猫の部屋」の５択ゲームを用意している。「動物の部屋」の３択ゲームは、関係性のある３つのイメージが１つのグループとして固定しており、サーバ１３が、用意された複数のグループの中からランダムで決定し、決定したグループに属する３つのイメージの配置位置をランダムに決定する。またサーバ１３は、使用する背景画像も決定する。そしてサーバ１３は、決定したグループの番号と、そのグループに属する各要素のイメージの配置位置の情報を端末１１に伝え、端末が取得した情報に基づき、ゲーム画面Ｇ５を作成する。

これにより、表示される選択肢のイメージ群は、グループ単位となるのでも例えば図７に示すように、通信ゲームシステムは、「牛」のグループを選択して表示したり、「ライオン」のグループを選択して表示したりする。グループ単位で選択肢を決定するので、例えば異なるグループに属する「牛」と「ライオン」が一つのイメージ群の中に共存して選ばれることはない。例えば関係性のない異なるグループに属するイメージが配置されると、参加者のグルーブに対する好き嫌いなどの心証によって投票結果がばらつくことがあるが、関係性のあるイメージに纏めるので、好みによる影響を排除できるので良い。

さらに、同じグループが選択された場合でも、各イメージの表示位置をランダムで設定するため、例えば図８に示すように牛を示す３つのイメージの配置位置が異なることがあり、何回も参加するユーザにとってもその都度位置を確認するので新鮮で飽きが来ないのでよい。さらに背景画像も複数の中から選択するので、同じグループのイメージであっても背景画像が変わることで各選択肢のイメージの雰囲気も変わり、どれを選択するか考える際の要因の一つになるので良い。

図９は、動物の部屋に属する複数のグループの一例を示している。図中横一列が１つのグループとして固定され、ゲーム画面に出現する。各選択肢の要素は、例えばグループ番号と、そのグループ内での要素番号（１，２，３等）により特定する。これにより、サーバ１３は、端末１１に対し、例えば、今回のゲームで使用するイメージ群を送る際にグループ番号と、出現場所（右、左、上）に配置するイメージの要素番号により簡単に通知することができる。例えば要素番号を「２，１，３」の場合、２番の要素を右に配置し、１番の要素を左に配置し、３番の要素を上に配置するなどとするとよい。

また図９に示すように、グループを構成する関係性のある３つのイメージは、例えば、「キリン」、「犬」、「牛」、「ライオン」のように同じ種類・種族の動物であったり、「シマウマ」、「パンダ」、「漠」のように白黒の模様からなる動物であったり、「犬」、「猿」、「雉」のように同じ物語（例えば「桃太郎」）に登場する動物などがある。また同じ種類・種族の動物の場合、２つは似たイメージで１つを極端に変えたものとすると良い。例えば「キリン」の場合、２つの「キリン」は顔のアップで角の部分を少し変えたイメージにするのに対し、３番目の「キリン」は全体を示し、しかもデフォルメしてコミカルなイメージとしている。「犬」や「ライオン」の場合、１番目と２番目は全体像を示し、３番目は顔部分をアップしたイメージとしている。「牛」の場合、１番目と２番目は白・黒のまだら模様の普通の姿にするのに対し、３番目は胴体部分に迷路を模した図柄を嵌め込んだ姿にしている。

例えば、同じ種族に属する動物の場合、３つともイメージが似ていたり、３つとも全くコンセプトが違ったりした場合、例えば数字を選ぶように選択しやすさがどれも同じになる。一方、本形態のように２つが似ていて１つを奇抜・変わった姿態にすることで、その１つが目立ちそれを選びたくなる。このような状態にすると、みんなが素直にそれを選択すると投票が集中し勝てないので、裏を読んで別のものを選ぼうとしたり、他人が別のものを選ぶのを予測して敢えて奇抜な１つを選択するなど、推理が働きゲーム性が増すのでよい。さらに、裏を読んで別のものを選択しようとした場合には、似ている２つから選択する２択になり、そこで票が割れる。このようなことから、４択や５択ではなく、３択とすると良い。

「猫の部屋」の５択ゲームは、サーバ１３が関係性のある２４個のイメージ（図１０参照）からランダムに５つのイメージを選択し、その選択した５つのイメージの出現位置をランダムに決定する。イメージの出現場所は、右下、左下、右中、左中、上で固定し、固定された位置に対し、選択した５つのイメージをそれぞれランダムに振り分ける。これにより、図１１に示すように表示されるイメージ自体が異なる場合もあれば、選択された５つのイメージは同じでも出現位置が異なる場合もある。また選択される５つのイメージは、「猫」というカテゴリーの他に関係性はない。またサーバ１３は、使用する背景画像も決定する。そしてサーバ１３は、決定した５つのイメージを特定する番号等の情報を、配置位置がわかるように端末１１に伝え、端末１１が取得した情報に基づき、ゲーム画面Ｇ５を作成し、表示する。図１１は、このようにして作成し表示される５択ゲームのゲーム画面Ｇ５の一例を示している。

上述した実施形態では、３択ゲームは、「動物の部屋」のように関係性のある３つのイメージが１つのグループとして固定しており、グループ単位で選択肢のイメージ群を構成するようにしたが、グループを構成するカテゴリーは動物に限ることはなく、例えば図１２に示すように海の生き物等を用い、「海の部屋」というゲームを用いるなど、各種のカテゴリーのものを用意すると良い。また、例えば上述した５択ゲームの「猫の部屋」用の２４個のイメージを用い、そこから３つのイメージをランダムで選択し、３択ゲームを構成するようにしてもよい。同様に、５択ゲームにおいても、上述した実施形態のように所定数の（例えば２４個）の中からランダムに５個のイメージを選択するのではなく、５つのイメージを一つのグループとして固定したものを複数グループ用意し、グループを選択するようにしてもよい。但し、３択ゲームの場合、２つの似たイメージと一つの異なるイメージのような組み合わせとするのが良いので、同時に表示される３つのイメージの組は同じになるようにグループ単位で選択するようにすると良い。また、５択ゲームの場合、選択肢が多くなることから、例えば２つが似ていても残りの３つが似ていないと特定のイメージを目立たせることができず、一方、一つのイメージを目立たせるために残りの４つを似せると面白みに欠ける。そこで、多数のイメージの中から５つを選択する方式をとるとバラエティーに富んだ組み合わせができ、同時に出現する他のイメージとの相関で選択されやすさの程度も変わるので良い。

［ハードモード］
ハードモードが選択された場合、端末１１とサーバ１３がデータの送受を行い、図１１に示すフローチャートを実行し、ゲームを進行する。図１２は、ゲームの進行に伴い端末１１の表示部１６に表示する画面の状態遷移図である。

このハードモードは、９個の数字の中から一番選ばれないであろうものを予測して遊ぶ９拓のゲームである。イージーモードと相違し、選択肢の９個の数字は、１から９の各数字で固定されており、配列も固定されていて各端末で同じ並びとする。

ハードモードのゲーム（ナンバーズゲーム）は、イージーモードのゲームと相違し参加者を待つのではなく、サーバ１３が主体となって定期的（例えば１分）に開催し、投票期間中に投票された投票数に基づき勝敗を判定する。つまりこのナンバーズゲームは、例えば１分の投票期間を終了すると、投票期間中に行われた投票に基づき集計し、勝敗を判定する。そして、集計・判定処理が終わったあとに次の投票期間が開始する。よって、参加者は、１分間の投票期間中に例えばゲームに関する参考情報を見て、投票する数字を決定し、投票を行うが、タイムアップになると、次の投票サイクルで投票することになる。そしてサーバは、１分ごとの投票期間中に参加したランダムの参加者からの投票を集計し、勝者を決定する。

勝者の判定は、イージーモードと同様に、９個の数字のそれぞれの投票数を求め、同じ数字に投票した人が１人の場合、その人が勝者となる。また、投票数が１の数字が複数同時に発生した場合、それぞれが勝者となる。そして、投票数か１人の数字がない場合、投票数が一番少ない数字に投票した参加者が勝者となる。よって、イージーモードと同様に、投票数が１人の数字がなく、０人の数字がある場合には、参加者全員が敗者となる。そして、投票する場合、ユーザの保有コイン数から例えば３コインが消費され、勝者になると、そのときの投票に伴いベットされたコインを取得する。勝者が複数いる場合、総コイン数を勝者で山分けする。そして、係るハードモードのゲームを実施するため、端末並びにサーバは以下に示す処理を実行する。

ユーザは、ゲームモード選択画面においてハードモード（ナンバーズゲームの部屋）を選択する（Ｓ２１）。端末１１は、ハードモードが選択されたことを検知すると、サーバ１３にアクセスし、ユーザ（閲覧者）の特定情報等と共にハードモードを選択したことを通知する。

また端末１１は、ゲームの参加をサーバ１３へ通知すると共に、表示部１６にハードモードトップ画面Ｇ１１を表示する。ハードモードトップ画面Ｇ１１は、スタートボタンｋ１を備える。このスタートボタンｋ１がタップされると、端末１１は、ハードモードのゲーム画面Ｇ１２を表示する。さらにハードモードトップ画面Ｇ１１は、その表示画面の上端近傍にモード切替ボタンｋ２を配置する。このモード切替ボタンｋ２がタップされると、端末１１は、プレイするゲームモードを切替、表示部１６にイージーモードトップ画面Ｇ３を表示する（図４参照）。

図１５に拡大して示すように、このゲーム画面Ｇ１２の上端右側には、ユーザが保有するコイン数を表示するコイン数表示部ｆ１を設ける。そのコイン数表示部ｆ１の下には、左側に投票時間の残り時間に関する情報を表示する制限時間表示部ｆ２を配置し、右側に現在開催中のゲームに参加している人数に関する情報を表示する参加人数表示部ｆ３を配置する。そして、これら制限時間表示部ｆ２と参加人数表示部ｆ３の下には、分析結果表示部ｆ４を配置する。

さらにこの分析結果表示部ｆ４の下には、ゲーム画面Ｇ１２の中央の広い領域に、数字選択画面兼情報表示部ｆ５を配置する。この数字選択画面兼情報表示部ｆ５は、ユーザが１番選ばれないであろうと予測した数字を選び、投票する画面である。この数字選択画面兼情報表示部ｆ５は、１から９の数字を３×３に配列する。そしてユーザは、各数字の部分をタップして、その数字を投票する。

ゲーム画面Ｇ１２の下方には、画面遷移するためのボタン領域を配置する。ここでは、左端に戻るボタンｆ６，中央から右よりに傾向情報表示ボタンｆ７，右端にビンゴシートボタンｆ８を配置する。戻るボタンｆ６をタップすると、イージーモードとハードモードの選択画面に戻り、傾向情報表示ボタンｆ７をタップすると、所定の傾向情報表示画面Ｇ１３を表示し、ビンゴシートボタンｆ８をタップすると、ビンゴシート表示画面Ｇ１４を表示する。なお、傾向情報表示画面Ｇ１３に基づくゲームの傾向情報の表示機能や、ビンゴシート表示画面Ｇ１４に基づくビンゴ機能の詳細は後述する。

サーバ１３は、端末１１からハードモードを選択することの通知を受けると、閲覧者のデータを保存する（Ｓ２２）。すなわち、現在開催中のゲームを閲覧しているユーザ（閲覧者）のリスト中に登録する。また、サーバ１３の制御部２２は、端末１１から送られてきた情報が不足する場合、特定情報に基づきユーザデータベース２３にアクセスし、必要なデータを取得し、登録した閲覧者に関連付けて保存する。

端末１１は、サーバ１３から取得した閲覧者の属性データを例えばゲーム画面Ｇ１２や、そのゲーム画面Ｇ１２から遷移する画面を用いて出力する（Ｓ２３）。すなわち、端末１１は、例えば自己が保有するコイン数を、コイン数表示部ｆ１に表示し、現在開催中のゲームに参加している閲覧者の人数を参加人数表示部ｆ３に表示する。また端末１１は、ゲームへの参加を通知した際にサーバ１３から現在開催中のゲームの制限時間（残り時間）を取得し、取得した残り時間を制限時間表示部ｆ２に表示する。また、端末１１は、参加時に制限時間を取得したら、以後、内部時計・カウンターなどを用いて残り時間を求め、制限時間表示部ｆ２の表示を更新する。たとえば、端末１１は、サーバ１３が管理する正規の制限時間（残り時間）が更新されると、端末１１はその更新を感知し、端末１１側の制限時間も最新のものに更新する。但し、端末１１の数が多くなると、多数の端末１１からアクセスが集中してしまうので、ゲームのサイクルが１分ごとで制限時間が短いこともあるので、制限時間は個々の端末１１側で管理すると良い。

またサーバ１３は、ゲームの過去の傾向情報を取得し（Ｓ２４）、取得したゲームの傾向情報を端末１１に対し送信する（Ｓ２５）。ゲームの傾向情報は、投票する数字を決定するのに有益な判断材料になる情報である。例えば、最近のゲームの投票等の傾向データや、現在ナンバーズゲームの部屋に入っている人（閲覧者）に関するデータ等がある。これらの詳細については後述する。

端末１１は、サーバ１３から送信されてきたゲームの傾向情報を受信すると、その情報を記憶部１９に記録し保持する（Ｓ２６）。そして端末１１は、記憶保持した傾向情報を出力する（Ｓ２７）。この傾向情報の出力処理は、ユーザが端末１１に設けたボタンをタップし、そのタップに基づき端末１１が表示内容を変えることで行う（Ｓ２８）。このユーザからの指示に従って行う傾向情報の実際の出力処理の具体例については後述する。

さらにゲームのより詳細な分析処理を行い、分析情報を表示する（Ｓ２９）。この分析は、例えば、直近のデータを元にユーザ（閲覧者）が考える要素になる傾向分析（つぶやき）を行うものであり、例えば、よく勝っている選択肢や連続して出ている選択肢などの情報とすると良い。端末１１は、分析結果を分析結果表示部ｆ４に表示する。また分析結果表示部ｆ４を例えば上下に複数個を表示可能にし、複数の分析結果を同時に表示するようにしてもよいが、多くの情報を表示すると、制限時間が短いこともあり、全てを正確に把握することができないおそれがあるので、本形態のように１つとすると良い。

具体的な傾向分析の仕方は、以下のようなものがある。例えば、過去ｎゲームの結果を集計し、一番選ばれていない選択肢を表示する。表示例としては、「今日は○○を選ぶ人が少ないようです。」などでなる。また、過去ｎゲームの結果を集計し、一番選ばれている選択肢を表示する。表示例としては、「今日は○○を選ぶ人が多いようです。」などである。また連続で同じ選択肢が勝ちとなった場合にその選択肢を表示する。表示例としては、「さきほど○○は連続して勝ちになりました。」などである。また、獲得したコインが大きい選択肢を表示する。表示例としては、「今日○○を選んだ人が最高○○コインをゲットしました。」などとなる。

端末１１は、どのデータを用いどのような分析を行うかについて、サーバ１３から傾向情報を取得する際に併せて指定を受ける。この指定は、すべての端末１１で同じである。これにより、分析処理は個々の端末１１で行うが、端末１１に表示される内容は、すべてのユーザで同じになる。さらに、傾向分析の具体的な条件等はランダムに決定するが、分析結果表示部ｆ４に表示する内容は、１つのゲーム中で、１つとしている。

Ｓ２７，Ｓ２８の処理は、例えば以下のように行う。例えば、ユーザがゲーム画面Ｇ１２の傾向情報表示ボタンｆ７をタップすると、それを検知した端末１１は図１６に拡大して示すような傾向情報表示画面Ｇ１３を表示する。この傾向情報表示画面Ｇ１３は、ゲーム画面Ｇ１２をベースとし、数字選択画面兼情報表示部ｆ５に表示する情報を、直近のゲーム傾向データ（ＳＴＡＴＳ）の表示に切り替えたものである。

数字選択画面兼情報表示部ｆ５に表示する情報は、左側半分の情報の第一領域ｇ１に１〜９までの選択肢別の勝ちになった回数をグラフで表示し、右側半分の左側の第二領域ｇ２に、勝ちとなった選択肢の履歴を表示し（上側が最新のもの）、右側半分の右側の第三領域ｇ３に勝者が獲得したコイン数をゲーム毎に表示する（上側が最新のもの）。第一領域ｇ１に表示するグラフデータは、直近のＮゲームについてのものであり、第一ボタンｇ４、第二ボタンｇ５、第三ボタンｇ６のタップにより切り替える。本形態では、第一ボタンｇ４がタップされると、端末１１は直近の１０ゲームの傾向データにグラフの表示に変更し、第二ボタンｇ５がタップされると、端末１１は直近の２０ゲームの傾向データにグラフの表示に変更し、第三ボタンｇ６がタップされると、端末１１は直近の３０ゲームの傾向データにグラフの表示に変更する。また、第一ボタンｇ４，第二ボタンｇ５，第三ボタンｇ６は、最後にタップされたボタン部分の色を他と異なる色で表示する。図では、第二ボタンｇ５がタップされ、第二ボタンｇ５のみ所定の色が表示される。これにより、どのボタンに色が表示されているかにより、第一領域ｇ１に表示するグラフが直近何ゲームのものかが一目でわかるので良い。

このように、直近の勝った数字のデータを見ることで、現在参加しているプレイヤーが選びやすい／選ばれにくい（勝ちやすい）数字がわかる。プレイヤーは、１回のみ参加するのではなく、通常は複数回連続して参加するので直近のデータを見ることで、現在参加しているプレイヤーの傾向がわかるのでよい。

また、本形態では、勝った数字や、各数字の勝利数のように最も選ばれなかった数字についてのデータを表示するようにしたが、本発明はこれに限ることはなく、例えばサーバは閲覧者のデータとして閲覧者が過去（直近のＮ回、或いはすべての期間）に各数字に対しそれぞれの投票回数を取得し、それらを集計して参加している閲覧者の各数字に対する投票数の総数を表示するようにする機能を備えると良い。このようにすると、開催中のゲームの閲覧者が投票しやすい数字の傾向がわかるので良い。

また、画面の下方には、左端に戻るボタンｇ７を配置し、右端に画面切替ボタンｇ８を配置する。戻るボタンｇ７がタップされると、一つ上の階層であるゲーム画面Ｇ１２の表示に戻る。また画面切替ボタンｇ８がタップされると、それを検知した端末１１は図１７に示す閲覧者データ表示画面Ｇ１６を表示する。この閲覧者データ表示画面Ｇ１６は、ゲーム画面Ｇ１２をベースとし、数字選択画面兼情報表示部ｆ５に表示する情報を閲覧者データ（ＰＬＡＹＥＲ）に切り替えたものである。

数字選択画面兼情報表示部ｆ５に表示する情報は、上方に閲覧者の所定の情報についての割合を示す円グラフｈ１を表示し、下方に所定の情報を特定する選択ボタンを表示する。選択ボタンとしては、国籍を選択する第一選択ボタンｈ２、年齢を選択する第二選択ボタンｈ３、コインを選択する第三選択ボタンｈ４を有する。第一選択ボタンｈ２がタップされると、端末１１は現在ゲームルームにいる人の国籍別割合データに切替表示する。第二選択ボタンｈ３がタップされると、端末１１は現在ゲームルームにいる人の年齢別割合データに切替表示する。第三選択ボタンｈ４がタップされると、端末１１は現在ゲームルームにいる人の所持コイン別のデータに切替表示する。

また、第一選択ボタンｈ２，第二選択ボタンｈ３，第三選択ボタンｈ４は、最後にタップされたボタン部分の色を他と異なる色で表示する。図では、第一選択ボタンｈ２がタップされ、第一選択ボタンｈ２のみ所定の色が表示される。これにより、どのボタンに色が表示されているかにより、何に基づく割合の円グラフが表示されているかが一目でわかるので良い。

また、画面の下方には、左端に戻るボタンｈ５を配置し、右端に画面切替ボタンｈ６を配置する。戻るボタンｈ５がタップされると、一つ上の階層であるゲーム画面Ｇ１２の表示に戻る。また画面切替ボタンｈ６がタップされると、それを検知した端末１１は図１６に示す傾向情報表示画面Ｇ１３を表示する。

またサーバは、新たにユーザがゲームに参加する都度、閲覧者データや傾向情報を更新し、上述した数字選択画面兼情報表示部ｆ５に表示するデータは、閲覧者の変動に合わせてリアルタイムに最新の情報に切り替わる。

上述したように閲覧者のデータを表示することで、以下のような効果を奏する。例えば、国籍を表示することで、国籍から選びやすい数字や選ばれにくい数字を想像し、それに基づき自分が投票する数字を決定することができる。また、国籍を表示することで、ゲームの部屋で世界と繋がっていることが感じられるので良い。

所持するコイン数が多い人ほど、ゲームに強い人の可能性が高い。従って、コイン数を表示することで、例えば所持数が多い閲覧者の比率が高い場合、ゲームに強い人が参加しているので今回は投票しないという策がとれる。

さらに年代を表示することで、自分と同じ年代が多ければ、普通に自分が選ぶ感覚の裏をかいたりできるのでよい。また、年代さらには性別などを表示すると、どんな人がやっているかがわかるので親しみがわいたり、うれしくなったりする。さらに例えば参加者が若く、他の閲覧者が年上の人が多い場合に勝てるとうれしいなど、投票に対する意欲が増すので良い。このように閲覧者に関するデータは、投票する数字を決定する際の判断材料になると共に、ゲームを楽しむための情報としても有効に機能する。

ユーザは、画面を切り替えながら表示される各データを見て分析し、制限時間内に投票する（Ｓ３０，Ｓ３１）。投票は、ゲーム画面Ｇ１２の数字選択画面兼情報表示部ｆ５に表示されている数字の部分をタップして行う。端末１１は、数字選択画面兼情報表示部ｆ５に数字が表示されている状態で、数字選択画面兼情報表示部ｆ５内がタップされた場合、そのタップ位置から選択した数字を特定し、サーバ１３に送る。ハードモードのナンバーズゲームでは、一回投票すると選択肢が確定する。すなわち、イージーモードのように投票し直しはできないようにしている。

サーバ１３は端末１１から送られてきた選択肢を取得し、保存する（Ｓ３２）。このとき、ゲームのＰＬＡＹ用として所定数（例えば３枚）のコインを消費する。サーバ１３は、送られてきた選択肢の数、すなわち、投票数が最低投票数を満たしたか否かを判断する（Ｓ３３）。

ゲームの部屋に入った参加者が、実際にタップをせずに選択しなかった場合、選択情報が無いので端末１１は選択情報を送信しない。よって、実際に投票した人数は、閲覧者の人数よりも少ない場合があり、実際に投票した人数が最低投票数に達しない場合（Ｓ３３でＮｏ）、今回のゲームは不成立となり、そのまま制限時間を延長する。延長する時間は、１回のゲームの制限時間と同じにしている。従って、例えば制限時間が１分間とすると、１分経過時に投票数が最低投票数に満たない場合、制限時間を１分延長する。延長の回数に制限はない。このようにすると、一度投票した場合必ずゲームの決着が付く。このように最低参加者数に満たない場合、１分単位で投票期間が延長するが、既に投票した場合にはその内容が確定され延長時に投票し直しはできないようにしている。

一方、実際に投票した人数が最低投票数を満たした場合、サーバ１３は各数字に対する投票数に基づきゲームの判定を行う（Ｓ３４）。そしてゲームの結果をユーザデータベースに書き込む（Ｓ３５）。すなわち、ある選択肢（数字）に投票したユーザが１人の場合、サーバ１３は、そのユーザを勝者にする。また、投票したユーザが一人の選択肢（数字）が複数存在する場合、その複数の選択肢（数字）に投票したそれぞれのユーザがともに勝者となる。そして、投票したユーザが０人の選択肢（数字）がある場合、勝者は無しとなる。そして、すべての選択肢（数字）に対して、投票者が複数いる場合、最も投票数の少ない選択肢（数字）の要素を選択したユーザを勝者にする。

サーバ１３は、ゲームの判定結果をデータベースに書き込み（Ｓ３５）、勝者の判定（勝者なしも含む）の結果に基づき、勝者にコインを配布する。具体的には、ユーザデータベース２３に記録している勝者のユーザの保有コイン数に加算する（Ｓ３６）。勝者が取得するコインは、今回の参加者がベットしたコイン数を、勝者の数で等分する。すなわち、勝者は、ベットされたコインの総数を勝者の数で除算して求めた商（整数）のコインを受け取り、余りのコインはサーバ（管理者）が取得する。

また、サーバ１３はゲームの結果を端末１１に送る。端末１１は、サーバ１３からゲームの結果を取得すると、所定の手順を経て結果画面Ｇ１５を表示する（Ｓ３８）。結果画面Ｇ１５は、上方に勝者報酬表示部ｉ１を配置し、中央に投票結果表示部ｉ２を配置し、下方に操作ボタンｉ３を配置するレイアウトとする。勝者報酬表示部ｉ１は、勝者となったユーザの端末１１の場合、ゲットしたコイン数（ここでは５１個）を表示する。敗者ユーザの端末１１の場合、制御部は獲得する報酬がない旨を勝者報酬表示部ｉ１に表示する。

投票結果表示部ｉ２は、各選択肢である数字を並べるとともに、各数字の上に投票数を表示（この例ではグラフと数値）し、勝者の選択肢が視覚によりわかるように表示する。視覚によりわかるような表示は、例えばグラフの色を異なる色で表示する。

操作ボタンｉ３は、本実施形態では、２個のボタンを備える。右の「Close」ボタンをタップすると、結果画面Ｇ１５を閉じてゲーム画面Ｇ１２に戻る。「Close」ボタンは、同じゲームをもう一回ＰＬＡＹするためのボタンとも言える。

また、本実施形態では、ハードモードのナンバーズゲームは、１分間で繰り返しゲームが行われるので、結果画面Ｇ１５を表示している間も、次のサイクルのゲームが開始され制限時間が時々刻々と減少していく。従って、連続してゲームを参加している人は、１分という限られた時間を有効に使って各種データを見て投票する数字を決めたいという要求がある。

そこで、結果が出たら結果画面Ｇ１５を強制的に表示してもよいが、本形態では、前回参加したユーザに対して、集計ができたタイミングでその旨を通知する。例えば、次のゲームに参加してゲーム画面Ｇ１２やその他のデータを見るための画面を見てスタッツなどを確認している際に、割り込みで通知メッセージが画面上に一部が重なるように表示する。ユーザは通知メッセージに伴い結果を確認しても良いし、結果を見ることなくそのまま次のゲームの投票を行っても良い。よって、結果を見ることなくゲームを続けると、複数の結果が未開封で溜まることもある。

結果の確認は、例えば通知メッセージの部分をタップすることで行うと良い。端末１１は、通知メッセージの部分がタップされた場合、対応する結果画面を表示する。そして本形態では、勝った場合の持ちコインの反映は、結果通知を開封し結果画面Ｇ１５を見ないと行わないようにすると良い。つまり、投票したときに、参加コイン（３コイン）により所持コイン数が減り、仮に勝ったとしても結果通知を見ない限りコインが減った状態のままとなる。このようにすると、必ず結果を見るようになるので良い。すなわち、例えばコインをたくさん持っているユーザは、１分間で繰り返しリスタートするゲームで１分間の投票時間を有効に使うため、結果通知を見ないでゲームを続けることがあるが、勝者のコインを実際にゲットし所持コイン数に反映するためには結果を見る必要がある。このように本形態では、投票したタイミングと結果を見たタイミングでコインの数が増減する。

係る所持コイン数の増減を行うため、例えば処理ステップＳ３６で行うデータベースの書き込みは、仮獲得コイン、獲得予定コインのように所持コイン数とは別に管理し、結果を見たことの通知を受けたものに対して所持コイン数を増加する処理を行うと良い。

（ビンゴ機能）
上述した基本機能に加え、ビンゴ機能を備えると良い。本形態のビンゴ機能は、各ユーザがビンゴシートを保有し、自分が選択した数字でゲームに勝利した場合、選択した数字に対応するビンゴシートの数字を抜く。既に抜かれている数字と同じ数字で勝利してもビンゴシートに変化は無く、元に戻ることもない。ビンゴシートが一定の条件を満たすと勝利時に得られるコインの数が増えるボーナス機能を備える。

まず、自己が保有するビンゴシートは、ゲーム画面Ｇ１２のビンゴシートボタンｆ８をタップすることで確認できる。すなわち、ユーザがビンゴシートボタンｆ８をタップすると、それを検知した端末１１は、図１８に拡大して示すようなビンゴシート表示画面Ｇ１４を重ねて表示する。ビンゴシート表示画面Ｇ１４は、勝利時に選択した数字のマスが異なる色（例えば赤色）に塗られる。図では、ユーザが１を選択し、勝利した時のイメージである。ビンゴシートの配列は、必ずしも数字選択画面兼情報表示部ｆ５に表示する数字の配列と等しくする必要は無いが、すべてのユーザで同じ配列としている。また、ビンゴシート表示画面Ｇ１４の下方には、ＯＫボタンｊ１が配置されている。このＯＫボタンｊ１をタップすると、ビンゴシート表示画面Ｇ１４の表示を消し、ゲーム画面Ｇ１２が出現する。

勝利時に得られるコインの数が増える一定の条件は、複数設けるとゲーム性が増すので良い。ここで一定の条件とは、例えば、通常のビンゴのように縦・横・斜めにいずれか１列が揃うと、その時の獲得コインがｎ倍になる。そして、同時にｍ列揃った時は例えば、ｍ×ｎ倍、ｎ＾ｍ倍、もしくはｍ＾ｎ倍になる。このようにすると、ユーザは、現在の自己のビンゴシートの状況を確認しながら、同時にできるだけ多くの複数列でビンゴになるようにすると、勝利時に獲得できるコイン数が増えるので良い（条件１）。

また、別の条件（条件２）としては、例えば、１から順番に勝っていくと、２≦ｎ９番目に勝った時にコインがｍ倍になる。例えば、１，２，３，４と順番に勝利していき、５で勝った時には獲得コインが１０倍になる。

さらに別の条件（条件３）としては、例えば偶数あるいは奇数のみのすべてで勝利した時にｎ倍のコインを獲得することができる。

上述したｎおよびｍの値は変更することが可能であるが、すべてのユーザで同じ条件にする。ビンゴシートは全ユーザで共通のもので、同じ条件下でゲームが開催される。一定の条件やルール・シートは定期的に変更され、その時にビンゴもリセットされ、今までの塗ってきた場所がすべて白紙に戻される。そのため、ビンゴ開催中に一定の条件を満たす必要があるが、全員が同じシートであるため、選択肢の思考に偏りが生まれやすく、ユーザが選択肢を考える材料となる。

例えば、上記の条件１のルールの場合、５以外の１，２，３，４，６，７，８，9を揃えた後に５で勝利すると縦・横、斜め（２個）の4列同時ビンゴが発生するので、最後に５で勝つと大量のコインをゲットできる。一方、ゲームは一番選ばれないものを選んだ者が勝ちとなるため、最後に５で勝ちたいと考える人が多いほど、最後に５で勝利するのが難しくなる可能性があり、駆け引きが必要になる。また既に抜かれている数字と同じ数字で勝利してもビンゴシートに変化は無いので、ユーザは、自己のビンゴシートを確認しながら、抜けていない数字を選択しようとすると、選択の幅が狭くなり勝利しにくくなる。

ビンゴシートは、一定期間（例えばカレンダーの一週間）で更新するとよい。この場合、ビンゴにならなくても新しくなる。また、期間中にビンゴになったら、新しいビンゴカードが発行される。２枚目のビンゴカードも同じ配列であるが、ポイント倍増のルールが変わるようにすると良い。

ビンゴシートは、例えばビンゴ開催期間中の最初にゲームに参加した際に無料（コイン無し）で配布され、ビンゴ開催期間終了時になくなる。そして上述した実施形態では、ビンゴ開催中は、すべてのユーザが、同じ内容のビンゴカードを一枚保有するようにしたが、配列の異なるビンゴシートを複数パターン用意し、各ユーザにランダムに一枚ずつ配布するようにしてもよい。ランダムにすると、中央のマスの数字が異なるユーザが存在するため、一つの数字に集中することがなくなるため、高配当を得やすくなるので良い。但し、考える判断材料としての要素が減るので、すべてのユーザが同じ配列のビンゴシートとすると良い。

また、異なる配列のビンゴシートを配布する場合、ユーザは、ビンゴシートを複数枚保有できるようにしてもよい。複数枚保有する場合、１枚は無料で配布し、追加シートは所定のコイン数と交換したり、所定の条件（前回のビンゴ期間等で９マス空けたり、コインのゲット数、コインの所持数の優秀者など）の対価で配布したりすると良い。そして、複数枚保有した場合でも、１回のゲームの際に使用できるビンゴシートは１枚とすると良い。１枚に限定することで、１枚しか保有していないユーザとの不公平感が多くなりすぎるのを抑制する。また、複数枚所有するユーザは、勝ちそうな数字にあわせてビンゴシートを適宜切り替えることで、勝利時の高配当を期待できるので良い。

参加人数表示部ｆ３は、ゲームの部屋に入っている閲覧者の人数を表示するようにしたが、これに変えて或いはこれと共に実際に投票した人数を表示すると良い。実際に投票した人数がわかると、勝利の容易性が判断でき、勝利したときにゲットできるコイン数も予測でき、投票するか否かの判断ができるので良い。

また、上述したビンゴ機能は、ハードモードのナンバーズゲームに実装したが、この機能は必ずしも無くても良い。また、実装する場合にイージーモードに実装しても良い。イージーモードに実装する場合、例えば動物の部屋のように選択肢を構成するイメージをグループ毎に選択する場合、勝利したときに選択したイメージを記録し、同一のグループに属するすべてのイメージで勝利をした場合、コインゲット（例えば５コイン）するようにしたり、例えば猫の部屋のように複数（例えば２４個）のイメージからランダムに所定数を選択する場合には勝利時に選択したイメージが所定数（例えば５個，１０個等）のときに、コインゲット（例えば５コイン）するようにしたりするとよい。

（共通表示項目の変形例）
上述した実施形態では、各画面における共通表示項目として、上から二段目の左側に配置する制限時間表示部ｆ２や、右側に配置する参加人数表示部ｆ３等を備えている。これらの表示項目は、数字を決定する際の参考情報の一つ、判断材料となるが、これら以外にも各種の情報を表示すると良い。例えば、図２０に示すように、現在ベットされた総コイン数を表示する総ベット数表示部ｆ１０を設けるとよい。このようにすると、現在の参加者人数に加え、実際に投票を行った人数（総ベット数／３）がわかるとともに、勝者となったときに得られるコインの予測が立ち、投票する際のモチベーションが上がったり、投票を回避するか否の判断材料になったりするので良い。

（モード切替機能）
上述した実施形態では、イージーモードとハードモードの切替を、イージーモードトップ画面Ｇ３とハードモードトップ画面Ｇ１１のそれぞれに設けたタップ式のモード切替ボタンｂ４，ｋ２で行うようにしたが、例えば、図２１に示すように、スライド式のモード切替部ｍ１を設け、スライダｍ２を左右にスライドすることで、モードを切り替えるようにすると良い。

（ランキング表示機能）
図２１に示すように、例えば各モードにおける各画面の共通表示項目として、表示部の表示画面の上端左側に、ランキングボタンｆ９を設けるとよい。図２１では、イージーモードのイージーモードトップ画面Ｇ３と、ハードモードのゲーム画面Ｇ１２を例示しているが、他の画面でも共通に表示する。そして、ランキングボタンｆ９がタップされると、端末１１は図２２に示すように、現在表示している画面の上に重ねて、ランキングリスト画面Ｇ７を表示する。ＯＫボタンｎ１がタップされると、端末１１はランキングリスト画面Ｇ７を消す。これにより、下側に表示していたもとの画面が出現する。
このランキングは、コインの保有数についてのランキングとすると良い。コインの保有数は、本形態のゲームに強い人、すなわち、人と違う考え方ができる人（イノベータ）の指標となる。ランキングは、総コイン数以外にも、その日、その週、その月、ある一定の時間など区切った範囲で獲得したコイン数に基づいて決定すると良い。このようにすると、途中からゲームに参加した人でもランキング上位になれるのでよい。

また、コインの保有数であるが、ゲームに参加する際に支払うベット用のコインと、勝った時に得られるコインを区別し、勝ったときに得られるコインの保有数に基づいてランキングをすると良い。例えば、ベット用のコイン（第一コイン）は、広告閲覧か、課金でゲットできる。これにより、上述した実施形態において、勝者が得る「コイン」は「スコア」となり、例えば３コインを取得するようなケースでは、３スコアを取得する。このスコアもユーザデータベース２３で管理し、ゲームの勝者となりスコアを取得するごとに、既存の保有するスコアの値に加算し、保有スコアの値を更新する。

例えば、コインを課金によりゲットできるようにすると、コインが１種類の場合、コインの保有数は、ゲームに勝って得たコイン数と課金により取得したコイン数の合わさった値となり、単純にゲームの強さが反映されず、お金を積んだプレイヤーが強いということになってしまうおそれがある。本形態のように、コインとスコアを区別し、スコアに基づくランキングを表示することで係る問題が解消され、ゲームに強い人、すなわち、人と違う考え方ができる人(イノベータ)の指標をあらわすランキングを表示することができる。さらに、スコアは、所定の料率でコインに変換可能とすると良く、変換時の料率は透過ではなく、例えば１００スコアで５０コインのようにスコアの価値を低くすると良い。

（統計表示機能の変形例）
傾向情報表示ボタンｆ７をタップした際に表示する図１５に示す数字選択画面兼情報表示部ｆ５の表示レイアウトを例えば、図２３のように統計画面Ｇ８を表示すると良い。図示の例では、統計画面Ｇ８の上方領域に過去にベットされた数字を棒グラフで表示し、下方領域にイノベーター（勝者）になった数字（勝ち目）を棒グラフで表示するレイアウトにしている。上方領域に表示する過去にベットされた数字の棒グラフは、右端に設けた切り替えボタンのタップに基づき、「前回」、「過去５ゲーム」、「過去１０ゲーム」の情報を切替表示する。下方領域に表示するイノベーターになった数字の棒グラフは、右端に設けた切り替えボタンのタップに基づき、「過去１０ゲーム」、「過去２０ゲーム」、「過去３０ゲーム」の情報を切替表示する。ＯＫボタンｎ１がタップされると、端末１１はランキングリスト画面Ｇ７を消す。これにより、下側に表示していたもとの画面が出現する。

（ハードモードのゲーム画面Ｇ１２の変形例）
図２４は、ユーザが数字をベットするためのハードモードのゲーム画面Ｇ１２の変形例を示している。この変形例では、コイン数表示部ｆ１の下に、スコア数表示部ｆ１１を備えるレイアウトとした。上述した変形例のように、ゲームに勝ったときに得られるコイン（第二コイン）を別の単位（例えば「スコア」）にする機能を備えた場合、本形態のように現在の保有スコア数を同時に表示することで、現在のコイン数とともに現在のスコア数も容易に確認でき、ユーザは、スコアをコインに変換すればゲームを計測できる状況あるのか否かを簡単に認識できる。

この変形例では、数字選択画面兼情報表示部ｆ５の右上（この例では数字３の上）にＣＨＡＲＧＥボタンｆ１２を配置する。このＣＨＡＲＧＥボタンｆ１２は、ユーザがコインを取得するための機能のためのボタンである。制御部１８は、ＣＨＡＲＧＥボタンｆ１２がタップされたのを検知すると、表示部１６に例えばインターネットを介して取得した動画広告を表示する。この動画広告は例えば、短時間（例えば５秒）でスキップできる広告と、スキップできない長時間（例えば３０秒間）見なければならない広告を有し、制御部１８はそれらの広告をランダムに表示するとよい。ユーザは、１回の動画閲覧で３コインを取得する。すなわち、広告を最後まで再生された場合（スキップされた場合も含む）、制御部１８は、サーバ１３にその旨を通知し、ユーザが保有するコイン数を加算する。また、サーバ１３は、その通知を受信するとユーザデータベース２３を更新する。そして制御部１８は、動画広告の再生を終了すると、ゲーム画面Ｇ１２を表示する。これにより、ユーザ（プレイヤー）はそのままハードモードのゲームをプレイすることができる。

係る機能は、特に、上述したゲームに勝ったときに得られるコイン（第二コイン）を別の単位（例えば「スコア」）にした変形例と組み合わせると良い。コインとスコアを区別すると、コインの消費が早くなる。そのため、コインが０になった時にプレイヤーはゲームができなくなるので、そこでプレイを終了するか、或いはイージーモードや広告でコインを稼いでからプレイをする必要がある。このＣＨＡＲＧＥボタンｆ１２を備えることで、簡単にコインをゲットし、ハードモードでのプレイを継続できるのでよい。

動画広告により得られるコイン数は、ハードモードのゲームを１回プレイ、すなわち、数字の投票を行うために必要なコイン数と同じか、それ以上にすると良い。このようにすると、コインの保有数が０になったユーザは、動画を１回見ることでゲームを１回プレイすることができる。

動画の再生時間は、長時間の場合でも、１回の投票時間よりも短くするとよく、特に、長時間の動画再生が終わった後でも投票を行うための時間が確保されるようにすると良い。このようにすると、例えばコインが０になったプレイヤーでも、数字を投票するベットの待ち時間（例えば最大５０秒程度）の間にすばやく広告を見て３コインをゲットし、そのゲーム或いは遅くとも次のゲームベットすることができる。よって、ＣＨＡＲＧＥボタンｆ１２のようにすぐに広告にアクセスできるボタン等の手段を備えることで、プレイヤーは仮にコインが０でもゲーム離れを起こさず、プレイを続けやすいので好ましい。

さらにこの変形例では、画面の下方部に、第三のボタンとして、プレイヤーボタンｆ１３を配置した。制御部１８はこのプレイヤーボタンｆ１３がタップされたのを検知すると、サーバ１３にアクセスし、現在ベット済みのプレイヤーの情報を取得し、当該プレイヤーを一覧で表示する。例えばイージーモードでは、参加者情報画面Ｇ４で入室してきたプレイヤーのニックネームが表示されるため、ユーザは、事前にどのプレイヤーが参加しているかを確認できる。プレイヤーボタンｆ１３並びにベット済みのプレイヤーの一覧リストは、同様の機能をハードモードでも実現するものである。ユーザは、どんなプレイヤーがベットしているかを知ることで、投票するか否かの判断や、投票する数字の選択の判断に有為に機能する。

サーバは１つの装置から構成しても良いし、所定の機能を適宜分散し複数のサーバから構成しても良い。また、コインは、ゲーム上で使用するものでもよいが、例えば、仮想通貨に交換できたり、仮想通貨自体としたりすると良い。

上述した実施形態等において、ハードモードのゲームは、１回プレイ（投票）するのに３コイン消費し、勝者が所定のコインをゲットするように構成した。１回プレイするために消費するコイン数は、３コインに限ることはなく、適宜に設定しても良い。

また、上述した実施形態では、１回プレイ（投票）するごとに消費されるコイン数は、すべてのユーザで等しくしたが、ユーザがベットするコイン数を設定できるように構成しても良い。この場合に、勝者になったときに得られるコイン数・スコア数は、ベットしたコイン数に応じた値とすると良い。例えば勝者が複数人いる場合に投票に伴いベットした総コイン数を複数の勝者で按分する際に、ベットしたコイン数に応じて分ける比率を異なるようにする。また、例えば、投票する際に必要な最低コイン数を設定し、最低コイン数を超えたコイン数で投票して勝者に待った場合、ゲームに参加したすべてのユーザがベットしたコインとは別に、サーバの管理者等がボーナスポイントとして所定数のコイン・スコアを与えるようにすると良く、その他、各種の還元方法を提供すると良い。

以上、本発明の様々な側面を実施形態並びに変形例を用いて説明してきたが、これらの実施形態や説明は、本発明の範囲を制限する目的でなされたものではなく、本発明の理解に資するために提供されたものであることを付言しておく。本発明の範囲は、明細書に明示的に説明された構成や製法に限定されるものではなく、本明細書に開示される本発明の様々な側面の組み合わせをも、その範囲に含むものである。本発明のうち、特許を受けようとする構成を、添付の特許請求の範囲に特定したが、現在の処は特許請求の範囲に特定されていない構成であっても、本明細書に開示される構成を、将来的に特許請求する可能性があることを、念のために申し述べる。

１０ ：通信ゲームシステム
１１ ：端末
１２ ：ネットワーク
１３ ：サーバ
１５ ：通信インタフェース
１６ ：表示部
１７ ：入力部
１８ ：制御部
１９ ：記憶部
２１ ：通信インタフェース
２２ ：制御部
２３ ：ユーザデータベース
Ｇ１ ：登録トップ画面
Ｇ２ ：タイトル画面
Ｇ３ ：イージーモードトップ画面
Ｇ４ ：参加者情報画面
Ｇ５ ：ゲーム画面
Ｇ６ ：判定結果画面
Ｇ１１ ：ハードモードトップ画面
Ｇ１２ ：ゲーム画面
Ｇ１３ ：傾向情報表示画面
Ｇ１４ ：ビンゴシート表示画面
Ｇ１５ ：結果画面
Ｇ１６ ：閲覧者データ表示画面

Claims (7)

1. サーバと、そのサーバにネットワークを介して通信可能に接続する複数の端末を備え、
   前記端末は、その端末の表示部に複数の選択肢を表示する機能と、その複数の選択肢の中から選択された一つを特定する選択情報を前記サーバに通知する機能を備え、
   前記サーバは、前記複数の端末からそれぞれ送られてきた前記選択情報に基づき、前記複数の選択肢のそれぞれについて選択された投票数を求めるとともに、その求めた投票数に基づいて勝者を決定する機能を備え、
   前記複数の選択肢は、複数の数字の組み合わせであり、
   前記投票数に基づく勝者の決定処理は、投票数が１の選択肢が存在する場合はその選択肢を選択したものを勝者とし、投票数が１の選択肢がない場合で、投票数が０の選択肢がある場合には勝者は無しとし、投票数が１の選択肢がない場合で、すべての選択肢に対して投票者がいる場合には投票数が最も少ない選択肢を選択したものを勝者とすることを特徴とする通信ゲームシステム。
2. 前記端末を操作してゲームに参加している参加者に関する情報を、前記端末に表示する機能を備えることを特徴とする請求項１に記載の通信ゲームシステム。
3. 前記選択肢の複数の数字は、前記複数の端末で、同じ配列で、同じ並びにすることを特徴とする請求項１または２に記載の通信ゲームシステム。
4. 前記サーバは、前記選択肢への選択を受け付ける処理を、投票期間ごとに区切るととともに繰り返し行うようにし、その各投票期間ごとに前記投票数を求め前記勝者を決定するようにしたことを特徴とする請求項１から３のいずれかに記載の通信ゲームシステム。
5. 前記選択肢への選択を受け付ける処理を繰り返して行う場合、前記端末に表示する前記複数の選択肢の前記複数の数字の組み合わせは、毎回同じであることを特徴とする請求項４に記載の通信ゲームシステム。
6. 前記端末は、前記複数の数字を配列したビンゴシートを保有し、
   前記勝者となった際に選択した前記選択肢の数字に対応する前記ビンゴシートのマスをあけ、前記ビンゴシートが一定の条件を満たすと勝利時に特典が得られる機能を備えることを特徴とする請求項１から５のいずれかに記載の通信ゲームシステム。
7. 請求項１から６のいずれか１項に記載の通信ゲームシステムに用いられる機能をコンピュータに実現させるためのプログラム。

Images