JP7444542B2 - ゲームプログラム、方法、および情報処理装置 - Google Patents

Description

特許法第３０条第２項適用 ・ウェブサイトのアドレス （Ａ）ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ｃｏｌｏｐｌ＿ｄｒｅａｍｉｎｇ 掲載日 ２０１８年３月７日～ （Ｂ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｄｒｅａｍｉｎｇ／ 掲載日 ２０１８年３月７日～ （Ｃ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／２０１８０５１１０１．ｐｈｐ 掲載日 ２０１８年５月１１日 （Ｄ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／ ２０１８年６月２５０１．ｐｈｐ 掲載日 ２０１８年６月２５日 （Ｅ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／２０１８年８月９０１．ｐｈｐ 掲載日 ２０１８年８月９日 （Ｆ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／ ２０１８年１１月１２０１．ｐｈｐ 掲載日 ２０１８年１１月１２日 （Ｇ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｃＪｔｈ８ｗｐ５Ｚ１Ｅ 掲載日 ２０１８年６月２１日 （Ｈ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｗＦｋＣＨ－＿ＪＬＬＵ 掲載日 ２０１８年６月２４日 （Ｉ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｆＴｗ０７０ｋＧＧＣ０ 掲載日 ２０１８年６月２４日 （Ｊ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＳＡｐ７ＣＦＺＩＩＫｗ 掲載日 ２０１８年６月２４日 （Ｋ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝Ｉ３ＯＢＬｋ１ｒＬｋｇ 掲載日 ２０１８年６月２４日 （Ｌ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｗｒＦｉＬｑｚｊｒｔ４ 掲載日 ２０１８年６月２６日 （Ｍ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＲｃＪｕ－Ｕ７Ｂ１Ｓｓ 掲載日 ２０１８年６月２７日 （Ｎ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＢＡＡＤＤ５ｐＱｖＺｋ 掲載日 ２０１８年７月１日 （Ｏ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｊＭ２ｐＰＺＤ４ｂａＩ 掲載日 ２０１８年７月２日

特許法第３０条第２項適用 （Ｐ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｌＨｎＪＪＦｚＦｙｘ０ 掲載日 ２０１８年７月３日 （Ｑ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝９９ＸＵＫ３３ｉｘＦｗ 掲載日 ２０１８年７月４日 （Ｒ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝Ｘ４８ＵＤｉＷＭｋＺ８ 掲載日 ２０１８年７月５日（Ｓ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＲｎＬＳＯｄ＿Ｂｓ５Ｉ 掲載日 ２０１８年７月６日 （Ｔ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｔ４ＨａｆＳ４ＢＰＨｃ 掲載日 ２０１８年７月７日 （Ｕ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｒｕｃ２ＦＣＮｇｘＮＩ 掲載日 ２０１８年７月１２日 （Ｖ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝５Ｑ０ｘＥｐｎ２Ｎ００ 掲載日 ２０１８年７月２４日 （Ｗ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｃＷｇＱＱ４Ｊｉ２ｑｋ 掲載日 ２０１８年７月２４日 （Ｘ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｕ＿ｑｅＪＸ９ｖＦ９４ 掲載日 ２０１８年８月１０日 （Ｙ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｕｓｚＪ５Ｚ４Ｈ６Ｏｇ 掲載日 ２０１８年１０月１０日 （Ｚ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＫＸＬｋｄ－ｅＥ９－ｓ 掲載日 ２０１８年１０月１７日 （ＡＡ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＣＩ６ＡＬ１ｕｔｅ０ｇ 掲載日 ２０１８年１０月２６日 （ＡＢ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｉｔ６ｒ８ＱｊＢＳＶＭ 掲載日 ２０１８年１１月１１日 （ＡＣ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｗａｔｃｈ／ｌｖ３１３９３９７６５ 掲載日 ２０１８年７月１日

特許法第３０条第２項適用 （ＡＤ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｗａｔｃｈ／ｌｖ３１４２１９６５３ 掲載日 ２０１８年７月２４日 （ＡＥ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｗａｔｃｈ／ｌｖ３１４９２３６０８ 掲載日 ２０１８年８月２２日 （ＡＦ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１５３７７０３５ 掲載日 ２０１８年９月１９日 （ＡＧ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１５９９４９２９ 掲載日 ２０１８年１０月１９日 （ＡＨ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１６６３７３５２ 掲載日 ２０１８年１１月２８日 （ＡＩ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１８０２２２４４ 掲載日 ２０１９年１月２９日 ・アプリケーション名：「ＤＲＥＡＭ！ｉｎｇ」 アプリケーションバージョンおよびリリース・アップデート日：Ｖｅｒ．１．０．０ ２０１８年８月８日 Ｖｅｒ．１．０．１ ２０１８年８月１３日 Ｖｅｒ．１．０．２ ２０１８年８月１７日 Ｖｅｒ．１．０．３ ２０１８年８月２２日 Ｖｅｒ．１．０．４ ２０１８年８月３１日 Ｖｅｒ．１．０．５ ２０１８年９月７日 Ｖｅｒ．１．０．６ ２０１８年９月１４日 Ｖｅｒ．１．０．７ ２０１８年９月２８日 Ｖｅｒ．１．０．８ ２０１８年１０月１１日 Ｖｅｒ．１．０．９ ２０１８年１０月３０日 Ｖｅｒ．１．０．１０ ２０１８年１１月１５日 Ｖｅｒ．１．０．１１ ２０１８年１１月１６日 Ｖｅｒ．１．０．１２ ２０１８年１１月２９日 Ｖｅｒ．１．０．１３ ２０１８年１１月３０日 Ｖｅｒ．１．０．１４ ２０１８年１２月１２日 Ｖｅｒ．１．０．１５ ２０１８年１２月１８日 Ｖｅｒ．１．０．１６ ２０１９年１月１８日 Ｖｅｒ．１．０．１７ ２０１９年１月２８日 Ｖｅｒ．１．０．１８ ２０１９年２月８日 Ｖｅｒ．１．０．１９ ２０１９年２月２２日

本開示はゲームプログラム、ゲームプログラムを実行する方法および情報処理装置に関する。

所望の報酬をもらえるまで所定の行為を繰り返し実施し、スタンプやポイントなどを所定数集めるといった制度が従来存在する。

"GameWith - 国内最大級のゲームアプリ情報・攻略サイト"、[online］、GameWith, Inc.、[２０１９年１月２１日検索]、インターネット（ＵＲＬ：https://gamewith.jp/shironeko/article/show/55860）

上述のような制度において、スタンプやポイントを所定数集めるというゴールまでの道のりが遠いと感じるユーザは少なくない。このようなユーザは、ゴールを目指すことを最初からあきらめてしまうことがある。このようなユーザに所定の行為を動機付けることは難しく、上述の制度の導入によって期待された成果が得られない可能性がある。ゲームの分野においても、上述の制度を導入するにあたり、ユーザに所定の行為の実施を効果的に促すためには依然工夫の余地がある。本開示の一態様は、ユーザに所定の行為の実施を動機付けることを目的とする。

本開示に係るゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、ユーザによって、ゲームプログラムに基づくゲームにおいて利用可能な有償アイテムを購入する第１行為が実施されたことに応答して、値が第１値よりも大きい第２値に設定されたパラメータ情報をユーザに付与するステップと、ユーザによって、ゲーム上で第１行為とは異なる第２行為が実施されたことに応答して、パラメータ情報に設定されている値を更新するステップと、値が、該パラメータ情報に設定されている第１の閾値に到達した場合に、該パラメータ情報に設定されている、ゲームで利用可能な第１の報酬をユーザに付与するステップと、を実行させる。

本開示の一態様によれば、ゲームの興趣性を向上させる効果を奏する。

ゲームシステムのハードウェア構成を示す図である。 ゲームシステムで実行されるゲームのゲームサイクルの一例を説明する図である。 ユーザ端末およびサーバの機能的構成を示すブロック図である。 カードのデータ構造の一例を示す図である。 キャラクタを定義するキャラクタデータのデータ構造の一例を示す図である。 （Ａ）は、ペアパラメータテーブルのデータ構造の一例を示す図であり、（Ｂ）は、ペアパラメータＤＢのデータ構造の一例を示す図である。 ストーリーリストのデータ構造の一例を示す図である。 ユーザ情報のデータ構造の一例を示す図である。 パラメータ情報のデータ構造の一例を示す図である。 実施形態１に係るゲームシステムにおいて実行される処理の流れを示すフローチャートである。 （Ａ）は、ユーザ端末の表示部に表示される抽選画面の一例を示す図であり、（Ｂ）は、ユーザ端末の表示部に表示されるスタンプカード画面の一例を示す図である。 （Ａ）は、ユーザ端末の表示部に表示される購入画面の一例を示す図であり、（Ｂ）は、ユーザ端末の表示部に表示されるスタンプカード画面の一例を示す図である。 ゲームシステムが提供する月極サービスにおける、契約期間の定め方の一例を説明する図である。 パラメータ情報のデータ構造の他の例を示す図である。 実施形態２に係るゲームシステムにおいて実行される処理の流れを示すフローチャートである。 （Ａ）および（Ｂ）は、ＵＩ部品としてユーザ端末の表示部に表示されるスタンプカードの他の例を示す図である。 押印規則のデータ構造の一例を示す図である。

〔実施形態１〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。

＜ゲームシステム１のハードウェア構成＞
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えばWi-Fi（登録商標））等が挙げられる。

サーバ２００（コンピュータ、情報処理装置）は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ２００は、プロセッサ２０と、メモリ２１と、ストレージ２２と、通信ＩＦ２３と、入出力ＩＦ２４とを備える。サーバ２００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。

ユーザ端末１００（コンピュータ、情報処理装置）は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末１００は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末１００は図示の通り、プロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５（表示部）と、カメラ１７と、測距センサ１８とを備える。ユーザ端末１００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末１００は、タッチスクリーン１５に代えて、または、加えて、ユーザ端末１００本体とは別に構成されたディスプレイ（表示部）を接続可能な入出力ＩＦ１４を備えていてもよい。

また、図１に示すように、ユーザ端末１００は、１つ以上のコントローラ１０２０と通信可能に構成されることとしてもよい。コントローラ１０２０は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信規格に従って、ユーザ端末１００と通信を確立する。コントローラ１０２０は、１つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末１００へ送信する。また、コントローラ１０２０は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末１００へ送信する。

なお、ユーザ端末１００がカメラ１７および測距センサ１８を備えることに代えて、または、加えて、コントローラ１０２０がカメラ１７および測距センサ１８を有していてもよい。

ユーザ端末１００は、例えばゲーム開始時に、コントローラ１０２０を使用するユーザに、該ユーザの名前またはログインＩＤ等のユーザ識別情報を、該コントローラ１０２０を介して入力させることが望ましい。これにより、ユーザ端末１００は、コントローラ１０２０とユーザとを紐付けることが可能となり、受信した出力値の送信元（コントローラ１０２０）に基づいて、該出力値がどのユーザのものであるかを特定することができる。

ユーザ端末１００が複数のコントローラ１０２０と通信する場合、各コントローラ１０２０を各ユーザが把持することで、ネットワーク２を介してサーバ２００などの他の装置と通信せずに、該１台のユーザ端末１００でマルチプレイを実現することができる。また、各ユーザ端末１００が無線ＬＡＮ（Local Area Network）規格等の無線規格により互いに通信接続する（サーバ２００を介さずに通信接続する）ことで、複数台のユーザ端末１００によりローカルでマルチプレイを実現することもできる。１台のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、ユーザ端末１００は、さらに、サーバ２００が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末１００は、サーバ２００が備える後述する種々の機能を分散して備えていてもよい。

なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末１００はサーバ２００と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ２００に送信してもよい。

また、コントローラ１０２０は、ユーザ端末１００に着脱可能な構成であるとしてもよい。この場合、ユーザ端末１００の筐体における少なくともいずれかの面に、コントローラ１０２０との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末１００とコントローラ１０２０とが結合している場合は、ユーザ端末１００とコントローラ１０２０とは、有線を介して信号を送受信する。

図１に示すように、ユーザ端末１００は、外部のメモリカード等の記憶媒体１０３０の装着を、入出力ＩＦ１４を介して受け付けてもよい。これにより、ユーザ端末１００は、記憶媒体１０３０に記録されるプログラム及びデータを読み込むことができる。記憶媒体１０３０に記録されるプログラムは、例えばゲームプログラムである。

ユーザ端末１００は、サーバ２００等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末１００のメモリ１１に記憶してもよいし、記憶媒体１０３０から読み込むことにより取得したゲームプログラムをメモリ１１に記憶してもよい。

以上で説明したとおり、ユーザ端末１００は、該ユーザ端末１００に対して情報を入力する機構の一例として、通信ＩＦ１３、入出力ＩＦ１４、タッチスクリーン１５、カメラ１７、および、測距センサ１８を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。

例えば、操作部が、カメラ１７および測距センサ１８の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末１００の近傍の物体１０１０を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体１０１０としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体１０１０の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末１００は、カメラ１７の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ（ユーザの手の一連の動き）を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。

あるいは、操作部がタッチスクリーン１５で構成される場合、ユーザ端末１００は、タッチスクリーン１５の入力部１５１に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信ＩＦ１３で構成される場合、ユーザ端末１００は、コントローラ１０２０から送信される信号（例えば、出力値）をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力ＩＦ１４で構成される場合、該入出力ＩＦ１４と接続されるコントローラ１０２０とは異なる入力装置（図示せず）から出力される信号をユーザの入力操作として特定し、受け付ける。

＜各装置のハードウェア構成要素＞
プロセッサ１０は、ユーザ端末１００全体の動作を制御する。プロセッサ２０は、サーバ２００全体の動作を制御する。プロセッサ１０および２０は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、およびＧＰＵ（Graphics Processing Unit）を含む。

プロセッサ１０は後述するストレージ１２からプログラムを読み出し、後述するメモリ１１に展開する。プロセッサ２０は後述するストレージ２２からプログラムを読み出し、後述するメモリ２１に展開する。プロセッサ１０およびプロセッサ２０は展開したプログラムを実行する。

メモリ１１および２１は主記憶装置である。メモリ１１および２１は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の記憶装置で構成される。メモリ１１は、プロセッサ１０が後述するストレージ１２から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ１０に作業領域を提供する。メモリ１１は、プロセッサ１０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ２１は、プロセッサ２０が後述するストレージ２２から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ２０に作業領域を提供する。メモリ２１は、プロセッサ２０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

本実施形態においてプログラムとは、ゲームをユーザ端末１００により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末１００とサーバ２００との協働により実現するためのゲームプログラムであってもよい。なお、ユーザ端末１００とサーバ２００との協働により実現されるゲームは、一例として、ユーザ端末１００において起動されたブラウザ上で実行されるゲームであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末１００の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末１００とサーバ２００との間または複数のユーザ端末１００間で送受信する指示または通知を含んでいる。

ストレージ１２および２２は補助記憶装置である。ストレージ１２および２２は、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）等の記憶装置で構成される。ストレージ１２およびストレージ２２には、ゲームに関する各種データが格納される。

通信ＩＦ１３は、ユーザ端末１００における各種データの送受信を制御する。通信ＩＦ２３は、サーバ２００における各種データの送受信を制御する。通信ＩＦ１３および２３は例えば、無線ＬＡＮ（Local Area Network）を介する通信、有線ＬＡＮ、無線ＬＡＮ、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。

入出力ＩＦ１４は、ユーザ端末１００がデータの入力を受け付けるためのインターフェースであり、またユーザ端末１００がデータを出力するためのインターフェースである。入出力ＩＦ１４は、ＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行ってもよい。入出力ＩＦ１４は、例えば、ユーザ端末１００の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ２００の入出力ＩＦ２４は、サーバ２００がデータの入力を受け付けるためのインターフェースであり、またサーバ２００がデータを出力するためのインターフェースである。入出力ＩＦ２４は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。

ユーザ端末１００のタッチスクリーン１５は、入力部１５１と表示部１５２とを組み合わせた電子部品である。入力部１５１は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部１５２は、例えば液晶ディスプレイ、または有機ＥＬ（Electro-Luminescence）ディスプレイ等によって構成される。

入力部１５１は、入力面に対しユーザの操作（主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作）が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部１５１は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。

図示していないが、ユーザ端末１００は、該ユーザ端末１００の保持姿勢を特定するための１以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末１００がセンサを備えている場合、プロセッサ１０は、センサの出力からユーザ端末１００の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ１０は、ユーザ端末１００が縦向きに保持されているときには、縦長の画像を表示部１５２に表示させる縦画面表示としてもよい。一方、ユーザ端末１００が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ１０は、ユーザ端末１００の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。

カメラ１７は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。

測距センサ１８は、測定対象物までの距離を測定するセンサである。測距センサ１８は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ１８は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ１８は、指向性を有する光を発する光源を有することとしてもよい。

ここで、ユーザ端末１００が、カメラ１７と測距センサ１８とを用いて、ユーザ端末１００の近傍の物体１０１０を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ１７および測距センサ１８は、例えば、ユーザ端末１００の筐体の側面に設けられてもよい。カメラ１７の近傍に測距センサ１８が設けられてもよい。カメラ１７としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ１７に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ１７の撮影画像に基づく物体の検出精度をいっそう向上させることができる。

プロセッサ１０は、カメラ１７の撮影画像に対して、例えば以下の（１）～（５）に示す処理のうち１つ以上の処理を行ってもよい。（１）プロセッサ１０は、カメラ１７の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ１０は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。（２）また、プロセッサ１０は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ１０は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数（伸びている指の本数）を特定する。プロセッサ１０はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ１０は、指の本数が５本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が０本である（指が検出されなかった）場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が２本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。（３）プロセッサ１０は、カメラ１７の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。（４）プロセッサ１０は、カメラ１７の撮影画像の画像認識結果、および、測距センサ１８の出力値等の少なくともいずれか１つに基づいて、ユーザ端末１００の近傍の物体１０１０（ユーザの手など）とユーザ端末１００との距離を検出する。例えば、プロセッサ１０は、カメラ１７の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末１００の近傍（例えば所定値未満の距離）にあるのか、遠く（例えば所定値以上の距離）にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ１０は、ユーザの手がユーザ端末１００に接近しているのか遠ざかっているのかを検出してもよい。（５）カメラ１７の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末１００とユーザの手との距離が変化していることが判明した場合、プロセッサ１０は、ユーザが手をカメラ１７の撮影方向において振っていると認識する。カメラ１７の撮影範囲よりも指向性が強い測距センサ１８において、物体が検出されたりされなかったりする場合に、プロセッサ１０は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。

このように、プロセッサ１０は、カメラ１７の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か（「グー」のジェスチャであるか、それ以外のジェスチャ（例えば「パー」）であるか）を検出する。また、プロセッサ１０は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ１０は、ユーザがこの手をユーザ端末１００に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末１００は、例えば、ユーザの手の移動に応じて、タッチスクリーン１５においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末１００は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末１００は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作（またはドラッグ操作）に対応する操作として認識することもできる。また、ユーザ端末１００は、カメラ１７の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。

＜ゲーム概要＞
実施形態１に係るゲームシステム１がゲームプログラムに基づいて実行するゲーム（以下、本ゲーム）は、一例として、デッキ編成要素を含むゲームである。すなわち、ゲームシステム１は、ゲーム上で利用可能な、デジタルデータとしてのゲーム媒体をユーザに保有させ、これらのゲーム媒体の集合（以下、デッキ）を構成し、該デッキに基づいてゲームを進行させる。

本ゲームでは、ゲーム媒体は、ゲームにおいて、ユーザの操作にしたがって何らかの動作を主体的に行うことにより、ゲームの進行内容に影響を与える。ゲーム媒体は、一例として、デッキを構成する最小単位としてのカードという表現形態でユーザに提供される。

本ゲームでは、一例として、それぞれのカードには、該カードを分類するグループ識別子として、本ゲームに登場する複数のキャラクタのうちの１つが紐付けられている。キャラクタは、本ゲームを構成する少なくともいずれかのプレイパートにおいて、上述の動作を行う主体として表現される。本ゲームでは、カードおよびキャラクタには各種のパラメータが設定されている。ユーザは、ゲームをプレイすることを経てこれらのパラメータを強化することができる。すなわち、本ゲームは、カードまたはキャラクタを育成する育成要素を含むゲームであってもよい。

本ゲームは、一例として、育成シミュレーションゲームである。該育成シミュレーションゲームは、一例として、アイドルを目指しているキャラクタを育成するアイドル育成シミュレーションゲームである。本ゲームでは、上述のキャラクタは、例えば、架空の世界でアイドルを目指して学校生活を送る男子高校生である。

ゲームシステム１は、特定のジャンルに限らず、あらゆるジャンルのゲームを実行するためのシステムであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、ＲＰＧ、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。

また、ゲームシステム１は、特定のプレイ形態に限らず、あらゆるプレイ形態のゲームを実行するためのシステムであってもよい。例えば、単一のユーザによるシングルプレイゲーム、および、複数のユーザによるマルチプレイゲーム、また、マルチプレイゲームの中でも、複数のユーザが対戦する対戦ゲーム、および、複数のユーザが協力する協力プレイゲームなどであってもよい。

本ゲームを実行するためのゲームプログラムは、サーバ２００からユーザ端末１００へ基本的に無料で提供される。本ゲーム内のサービスの一部は、有料で提供される。一例として、本ゲームは、いわゆる、アイテム課金制のゲームである。

本実施形態では、一例として、本ゲーム内で利用可能なゲーム媒体の一部が、有料で提供される。有料で提供されるゲーム媒体を、有償アイテムと称する。有償アイテムは、例えば、本ゲーム内でダイヤを模して表現される。本ゲームにおいて、ダイヤは、ユーザに所有させるゲーム媒体としてのカードを所定の規則に基づいて選択する処理、いわゆる「抽選」をゲームシステム１に実行させるために消費されるものであってよい。

本実施形態では、ダイヤは、ユーザがダイヤを購入するための支払いを実施したことに伴って該ユーザに付与される。また、ダイヤは、ユーザが支払いを実施する代わりに、本ゲームをプレイして、本ゲームの進行状況を予め定められた条件に合致するように進めた場合に、プレイ報酬として該ユーザに配布されてもよい。

ゲームシステム１において、ユーザの購入行動に伴って付与されたダイヤと、ユーザの購入行動に代えて、ユーザのプレイ内容に応じて配布されたダイヤとは、区別して管理されてもよいし、区別せずにトータル個数のみが管理されてもよい。以下では、前者のダイヤを、購入ダイヤ（第１の有償アイテム）と称し、後者のダイヤを、配布ダイヤ（第２の有償アイテム）と称して必要に応じて区別する。一例として、ゲームシステム１は、購入行動に伴って付与された購入ダイヤと、購入行動に代えて、プレイ報酬として配布された配布ダイヤとを区別してそれぞれ個数を管理するものとする。

＜ゲームサイクル＞
図２は、本ゲームのゲームサイクルの一例を説明する図である。本ゲームは、複数のプレイパートで構成される。本ゲームは、育成シミュレーションゲームであって、一例として、ストーリーパート、練習パート、実践パート、抽選パート、および、能力管理パートの５つのプレイパートを含む。

ストーリーパートは、ユーザが、キャラクタにまつわる物語を読み進めて、ゲームを進行させるパートであり、本ゲームにおけるユーザの主たる目的となるパートである。物語は、ユーザ端末１００において、静止画および動画を含む映像、音声、および、テキストなどの少なくともいずれかを含むストーリーデータとしてユーザに対して提供される。

本実施形態では、一例として、ストーリーデータは、共通ストーリーまたは個別ストーリーのいずれかの内容を含むストーリーデータとして提供される。共通ストーリーは、本ゲームの主軸の物語として展開され、本ゲームで用意されたさまざまなキャラクタが登場する、本ゲームのメインストーリーともいうべきコンテンツである。共通ストーリーは、分岐もなくすべてのユーザが一本道で読み進めるものとする。個別ストーリーは、共通ストーリーに登場する個々のキャラクタにまつわるサイドストーリー、例えば、外伝またはスピンオフ作品として展開されるコンテンツである。個別ストーリーは、ユーザのプレイ状況に応じて、分岐があったり、読み進める順番が異なったりしてもよい。

こうして、ユーザは、映像、音声および、テキストを介して、共通ストーリーを読み進めるとともに、お気に入りのキャラクタについての個別ストーリーを楽しむことができる。個別ストーリーは、１人のキャラクタに焦点を当てた物語であってもよいし、特定の複数人のキャラクタおよびそれらのキャラクタの関係性に焦点を当てた物語であってもよい。

本実施形態では、物語を読むための条件が設定されており、ユーザは、ロックされた物語を解放すべく、その条件を満たすように、以下のプレイパートをプレイする。本ゲームのゲームとしての遊戯性は、例えば、ユーザが、物語を解放するために、以下のプレイパートをいかに有利にプレイするかという点に見出される。一方、ユーザが特段のプレイ条件を満たさずとも、時間が来たら、あるいは、サーバ２００から供給されたら、自動的に解放される物語があってもよい。

ユーザがストーリーパートをプレイすると、ユーザは、該パートをプレイしたことに基づいて、以後のゲーム進行、とりわけ、練習パートおよび実践パートを有利に進めるための何らかの成果を得る。成果は、一例として、練習パートおよび実践パートでプレイできるクエストの解放である。以下では、クエストを、本育成シミュレーションゲームの文脈に即して、キャラクタ達がアイドルとしてのパフォーマンスを披露する「ステージ」と称する。他の成果として、配布ダイヤ、抽選ポイント、または、抽選チケット（消費アイテム）がユーザに付与されてもよい。例えば、ユーザが、１つの物語に対応する１つのストーリーデータを読了すると、読了報酬として、所定個の配布ダイヤが該ユーザに付与されてもよい。これにより、ユーザは、解放したストーリーデータを次々に読了し、配布ダイヤを貯めて、後述する抽選パートに興じることができる。

練習パートは、カードおよびそのカードに対応するキャラクタを育成するパートである。一例として、練習パートでは、カードが編成されたデッキを用いてステージを進行させる。ユーザがプレイしたいステージを選択して該ステージを最後まで進行させると、ユーザは、該ステージをクリアしたと判定される。ユーザは、ステージをクリアしたことに基づいて、以後のゲーム進行、とりわけ、実践パートを有利に進めるための何らかの成果を得る。成果は、一例として、報酬獲得、カードまたはキャラクタのパラメータ強化、ユーザのステータス向上、および、キャラクタの個別ストーリーの解放などである。報酬は、例えば、各パートで利用可能なカード、および、カードまたはキャラクタを強化するための強化アイテムなどである。練習パートを繰り返しプレイすることにより育成されたカードおよびキャラクタは、例えば、以下の実践パートにおいて、より有利に動作する。

実践パートは、育成したカードが編成されたデッキを用いて、ステージにおいて課された課題をクリアするパートである。ユーザがプレイしたいステージを選択して該ステージをクリアすると、ユーザは、該ステージをクリアしたことに伴う成果を得ることができる。成果は、例えば、クリア報酬、および、共通ストーリーの解放である。クリア報酬は、例えば、カード、および、強化アイテムなどである。他の成果として、例えば、カードまたはキャラクタのパラメータ強化、および、ユーザのステータス向上などの成果がユーザに与えられてもよい。

本実施形態では、実践パートは、一例として、ユーザによって保有される１以上のカード（ゲーム媒体）を、対戦相手のカードと対戦させるパートであってもよい。対戦相手は、他のユーザであってもよいし、ゲームプログラムにしたがって動作するコンピュータ（ＣＯＭ）であってもよい。また、対戦で使用する１以上のカードは、デッキに組み入れることによって対戦で使用可能であってもよい。デッキは、練習パートで編成されるデッキと異なる構成を有していてもよいし、同じ構成を有していてもよい。本実施形態では、一例として、実践パートは、ユーザが編成したデッキの各キャラクタと、ゲームプログラム１３１に基づいてコンピュータが編成したデッキの各キャラクタとが、アイドルとしてのパフォーマンスの高さを競う対戦（ＣＯＭ戦）を含む。本実施形態では、ＣＯＭ戦の結果が、勝利、引き分け、または、敗北のいずれであるのかに応じてクリア判定がなされ、ユーザに与えられる成果が決定される。一例として、対戦は、該対戦で使用されるユーザのカードのパラメータが、例えば先の練習パートなどにおいて強化されていればいるほど、ユーザ側が勝利しやすいように進行してもよい。

抽選パートは、本ゲームで利用できるデジタルデータとしてのゲーム媒体を、ゲーム内価値と引き換えに、ユーザに獲得させるパートである。本実施形態では、一例として、抽選パートの進行中に、ゲームシステム１において抽選が実行される。具体的には、サーバ２００は、ユーザに所有させるゲーム媒体を、複数のゲーム媒体で構成される母集団の中から所定の規則に基づいて選択することにより抽選を実行する。抽選の実行と引き換えられるゲーム内価値は、例えば、ユーザが課金により入手した仮想通貨などの有価媒体であってもよいし、プレイ報酬として無償で提供されるポイントまたは消費アイテムなどであってもよい。本実施形態では、一例として、抽選パートにおいて抽選が実行されると、当選したカードがユーザによって保有される。当選したカードは、練習パートおよび実践パートなどで利用することが可能となる。

抽選を実行するために消費される有価媒体とは、本実施形態において上述の有償アイテムのことであり、より具体的には、上述のダイヤのことを指す。抽選を実行するために消費される消費アイテムは、一例として、抽選チケットの形態で表現される。本ゲームでは一例として、ユーザは、所定個のダイヤと引き換えるか、または、抽選チケットを所定枚数消費することにより、抽選をゲームシステム１において実行させることができる。

なお、一例として、抽選に関して、購入ダイヤと配布ダイヤとは等価なものとして取り扱われる。したがって、購入ダイヤであっても配布ダイヤであっても抽選に必要な個数は同じであり、いずれのダイヤが消費されても、抽選は同様に実行される。すなわち、同じ母集団から同じ規則にしたがって、ユーザに付与するカードの選択が行われる。

一例として、抽選チケット１枚で、１枚のカードが当選する抽選が１回実行される。さらに、抽選チケットと交換可能な抽選ポイントがユーザに付与され得る。本ゲームにおいて、ユーザに付与される抽選ポイント１００ｐｔにつき、１枚の抽選チケットと交換が可能であるとする。抽選ポイントは、ログインボーナス、および、プレイ報酬などとして、ユーザに配布される。

以上のとおり、本ゲームにおいて、ユーザは、ゲームシステム１に抽選を実行させるための手段として以下の３つを有する。（１）ダイヤを購入し、入手した購入ダイヤと引き換えに抽選を実施する。（２）所定条件が満たされるようにゲームをプレイし、入手した配布ダイヤと引き換えに抽選を実施する。（３）所定条件が満たされるようにゲームをプレイして抽選ポイントを貯め、抽選ポイントと交換で手に入れた抽選チケットを消費して抽選を実施する。

ここで、「（ゲーム媒体などを）ユーザに獲得させる／保有させる／付与する」とは、一例として、ユーザに対応付けて管理されているゲーム媒体などのデジタルデータの状態を、使用不可から使用可能に遷移させることであってもよい。あるいは、デジタルデータを、ユーザ識別情報またはユーザ端末ＩＤなどに対応付けて、ゲームシステム１に含まれるメモリ１１およびメモリ２１のうちの少なくともいずれかのメモリに記憶させることであってもよい。

能力管理パートは、上述の各パートで獲得された強化アイテムを消費して、カードまたはキャラクタの能力を解放したり、強化したりするパートである。ユーザは、本パートにおいてカードまたはキャラクタの能力を解放したり、強化したりすることにより、練習パートおよび実践パートをより有利に進めることが可能となる。

なお、本ゲームは、ミニスケープゲーム、いわゆる、箱庭ゲームの要素を含んでいてもよい。例えば、本ゲームは、上述の５つのプレイパートの他にも、箱庭パートを含んでいてもよい。箱庭パートでは、ユーザは、上述の各パートをプレイすることにより入手したアイテム、および、カードなどの各種ゲーム媒体をマップに配置し、該マップの世界を俯瞰して楽しむことができる。また、箱庭パートのプレイ成果が、上述の他のパートにおいて有利に作用するように、該成果が設定されてもよい。

＜ゲームシステム１の機能的構成＞
図３は、ゲームシステム１に含まれるサーバ２００およびユーザ端末１００の機能的構成を示すブロック図である。サーバ２００およびユーザ端末１００のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。

ユーザ端末１００は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信ＩＦ１３、および入出力ＩＦ１４等の協働によって、制御部１１０および記憶部１２０として機能する。

サーバ２００は、各ユーザ端末１００と通信して、ユーザ端末１００がゲームを進行させるのを支援する機能を有する。ゲームがマルチプレイゲームである場合には、サーバ２００は、ゲームに参加する各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する機能を有していてもよい。サーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、および入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２２０として機能する。

記憶部１２０および記憶部２２０は、ゲームプログラム、ゲーム情報１３２およびユーザ情報１３３を格納する。ゲームプログラム１３１は、ユーザ端末１００が実行するゲームプログラムである。ゲームプログラム２３１は、サーバ２００が実行するゲームプログラムである。ゲーム情報１３２は、制御部１１０および制御部２１０がゲームプログラムを実行する際に参照するデータである。ユーザ情報１３３は、ユーザのアカウントに関するデータである。記憶部２２０において、ゲーム情報１３２およびユーザ情報１３３は、ユーザ端末１００ごとに格納されている。

（サーバ２００の機能的構成）
制御部２１０は、記憶部２２０に格納されたゲームプログラム２３１を実行することにより、サーバ２００を統括的に制御する。例えば、制御部２１０は、ユーザ端末１００に各種データおよびプログラム等を送信する。制御部２１０は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末１００から受信する。ゲームがマルチプレイゲームである場合には、制御部２１０は、ユーザ端末１００からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末１００に送信してもよい。

制御部２１０は、ゲームプログラム２３１の記述に応じて、進行支援部２１１、販売処理部２１２、サービス提供部２１３、および、抽選実行部２１４として機能する。制御部２１０は、実行するゲームの性質に応じて、ユーザ端末１００におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。

進行支援部２１１は、ユーザ端末１００と通信し、ユーザ端末１００が、本ゲームに含まれる各種のプレイパートを進行させるための支援を行う。例えば、上述の各プレイパートのいずれが実行されているのかに応じて、そのときにユーザ端末１００が参照すべき情報を適宜提供する。

販売処理部２１２は、ユーザ端末１００の購入処理部１１５と通信し、販売処理を実行する。具体的には、販売処理部２１２は、ユーザから本ゲームを提供する運営団体に対して料金の支払い受け付ける。そして、要求されたサービスを該ユーザに提供するように、要求されたサービスを提供する後述の各部を制御する。

サービス提供部２１３は、ユーザ端末１００のサービス受取部１１６に対してサービスを提供する。本実施形態では、サービスを提供する期間の開始時点と終了時点とが固定されており、開始時点から終了時点までが契約期間として定められている。サービス提供部２１３は、販売処理部２１２がサービスに対する対価の支払いをユーザから受け付けると、定められた契約期間中、例えば周期的に、サービスを該ユーザのユーザ端末１００に提供する。以下では、運営団体に対して料金を支払い、上記のサービスを受け取る資格があるユーザと、料金を支払っていないユーザとを区別したい場合に、前者を契約ユーザ、後者を一般ユーザと称することがある。

抽選実行部２１４は、ユーザ端末１００の抽選パート進行部１１７からのリクエストに応答して、抽選を実行する。具体的には、本ゲームにおいて利用可能なカードの中から、ユーザに付与するカードを、予め定められたカードの母集団の中から所定の規則に基づいて選択する。ユーザに付与するカードは、一例として、本ゲームに登場する複数のキャラクタの中の少なくとも１つのキャラクタが紐付けられたカードである。ユーザが所有するカードは、例えば、記憶部１２０に記憶され、ゲーム進行部１１１によって、本ゲームを進行させるために、適宜参照されて使用される。

（ユーザ端末１００の機能的構成）
制御部１１０は、記憶部１２０に格納されたゲームプログラム１３１を実行することにより、ユーザ端末１００を統括的に制御する。例えば、制御部１１０は、ゲームプログラム１３１およびユーザの操作にしたがって、ゲームを進行させる。また、制御部１１０は、ゲームを進行させている間、必要に応じて、サーバ２００と通信して、情報の送受信を行う。

制御部１１０は、ゲームプログラム１３１の記述に応じて、ゲーム進行部１１１、カード管理部１１２、報酬付与部１１４、購入処理部１１５、サービス受取部１１６および抽選パート進行部１１７として機能する。

なお、制御部１１０は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。

さらに、制御部１１０は、図示しない操作受付部、および、表示制御部などとしても機能する。操作受付部は、入力部１５１に対するユーザの入力操作を検知し受け付ける。例えば、操作受付部は、上述の入力操作の、入力部１５１における入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部は、例えば、タッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。表示制御部は、タッチスクリーン１５の表示部１５２に対して、制御部１１０の各部によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部は、制御部１１０の各部によって生成された映像を含むゲーム画面を表示部１５２に表示してもよい。また、表示制御部は、グラフィカルユーザインターフェース（以下、ＧＵＩ）を、該ゲーム画面に重畳して描画してもよい。

ゲーム進行部１１１は、本ゲームを構成する１要素であるゲームパートを進行させる。例えば、本ゲームが育成ゲームであって、本ゲームを構成する要素として、上述の、ストーリーパート、練習パート、および、実践パートを含む場合、ゲーム進行部１１１は、サーバ２００の進行支援部２１１と通信して、それぞれ、ストーリーパート、練習パート、および、実践パートを進行させる。すなわち、ゲーム進行部１１１は、ストーリーパート進行部、練習パート進行部、および、実践パート進行部として機能する。

カード管理部１１２は、パラメータ情報を処理し、管理する。具体的には、カード管理部１１２は、発行部１１２１および押印部１１２２としての機能を有する。発行部１１２１は、ユーザにパラメータ情報を付与する。一例として、発行部１１２１は、スタンプカードを模したパラメータ情報を発行し、ユーザに所有させる。押印部１１２２は、ユーザがゲーム内で所定の行為（第２行為）を実施したことに応答して、該ユーザのスタンプカードにスタンプを所定数押印する。本ゲームでは、例えば、所定の行為とは、ユーザが抽選パートにおいて抽選を実施することを指す。

なお、パラメータ情報としてのスタンプカードは、例えば、抽選で使用されている母集団ごとに配布されてもよい。母集団とは、実行される抽選において当選し得るゲーム媒体の集合と、該ゲーム媒体ごとの当選確率とを定義したデータである。例えば、第１の母集団に基づいて実行される第１の抽選に関しては、第１のスタンプカードが発行され使用される。そして、ゲームシステム１において、第１の母集団に基づく抽選のサービスの提供期間が終了し、第２の母集団に基づく新しい抽選のサービスが開始されると、第１のスタンプカードは押印済みのスタンプとともに抹消されて、第２の母集団に対応する第２のスタンプカードが発行されてもよい。

別の実施形態では、抽選で使用する母集団が変更されても、１人のユーザにつき１枚のスタンプカードが発行されてもよい。

報酬付与部１１４は、スタンプカードに押印されたスタンプの数が、第１の閾値に到達したと判定した場合に、該スタンプカードに設定されている第１の報酬をユーザに付与する。

スタンプカードとは、ユーザが所有するスタンプの数を値として管理するパラメータ情報の形態の１つである。パラメータ情報は、スタンプカードとして実現されてもよいし、ユーザが所有するポイントを値として蓄積可能なゲージとして実現されてもよい。パラメータ情報は、ユーザのゲーム情報１３２として記憶部１２０に記憶されている。パラメータ情報がスタンプカードである場合、パラメータ情報に設定される値は、スタンプの数である。ユーザがゲーム内で所定の行為を実施したことに応答して値は更新される。例えば、値は増分されてもよい。具体的には、スタンプカードにスタンプが押印される。一例として、ユーザが、抽選パートにおいて、１０枚のカードが当選する抽選（いわゆる、１０連抽選）を１回プレイするごとに、所定数のスタンプが、上述のスタンプカードに押印されてもよい。あるいは、ユーザが、抽選パートにおいて、１枚のカードが当選する抽選（以下、単発抽選）を１回プレイするごとに、所定数のスタンプが、上述のスタンプカードに押印されてもよい。あるいは、１０連抽選、および、単発抽選のいずれをプレイしてもスタンプが押印されるものとし、１０連抽選が１回プレイされた場合には、単発抽選が１回プレイされたときの１０倍の数のスタンプが押印されてもよい。そして、スタンプカードに押印されたスタンプの数が、第１の閾値に到達した場合に、該スタンプカードにおいて、第１の閾値に紐付けて設定されている第１の報酬がユーザに付与される。

購入処理部１１５は、ユーザが、本ゲームを提供する運営団体に対して、サービスの対価を支払うための支払処理を実行する。購入処理部１１５が支払処理を実行することにより、ユーザは、ゲーム内で提供されるサービスの対価を運営団体に支払うことができ、該サービスを享受することができる。サービスの対価は、実社会で流通する通貨および電子マネー、ポイントなどの仮想通貨で支払われてもよいし、ゲーム内で価値を有しているダイヤ、クリスタル、コインおよびゴールドなどのゲーム内仮想通貨で支払われてもよい。ここでは、サービスの対価を支払うことを、対価としての流通媒体の性質を問わず、一律支払または購入と称する。購入処理部１１５は、上述の契約期間の間に長期的に提供される後述の期間固定サービス、具体的には、月極サービスを、通貨または仮想通貨と引き換えにユーザに享受させること、および、ゲーム内仮想通貨としてのダイヤを通貨または仮想通貨と引き換えにユーザに所有させることを支払処理として実行してよい。例えば、購入処理部１１５は、契約の開始時点と終了時点とが固定されている契約期間内において提供するサービスについて、該サービスの対価の支払処理を行うステップを実行する。

サービス受取部１１６は、サーバ２００のサービス提供部２１３から提供されたサービスに係る便益をユーザに享受させる。サービスは、期間固定サービスであるので、サービス受取部１１６は、定められた契約期間において、例えば、周期的に、期間固定サービスに係る便益をユーザに享受させる。例えば、サービス受取部１１６は、契約期間内において上述の終了時点が到来するまで、サービスをユーザに享受させるステップを実行する。

例えば、期間固定サービスは、該サービスを購入した契約ユーザ専用のログインボーナスを、該契約ユーザがログインした場合に各日に付与することである。契約ユーザ専用のログインボーナスは、期間固定サービスを購入していない一般ユーザに付与されるログインボーナスよりもゲーム内価値が高い。

あるいは、例えば、期間固定サービスは、該サービスを購入した契約ユーザ専用のデイリーミッションに挑戦する権利を、該契約ユーザに各日に付与することである。契約ユーザ専用のデイリーミッションが達成されたときに付与される報酬は、期間固定サービスを購入していない一般ユーザに課されるデイリーミッションの達成報酬よりもゲーム内価値が高い。あるいは、例えば、期間固定サービスは、契約ユーザ専用のスタンプカードを該契約ユーザに付与することを含んでいてもよい。

サービス受取部１１６は、契約ユーザについて、契約期間ごとのスタンプの数に応じて、スタンプカードをアップグレードしてよい。スタンプカードのグレードが上がるほど、スタンプを貯めて報酬を受け取るという一連のユーザの行為が有利に進められる。期間固定サービスを購入していない一般ユーザに対しては、アップグレードされたスタンプカードは配布されないことが好ましい。

抽選パート進行部１１７は、ユーザから抽選の実行を指示する入力操作を受け付けて、サーバ２００の抽選実行部２１４に抽選を実行させる。そして、抽選パート進行部１１７は、抽選実行部２１４から通知された当選したカードをユーザに提示する。当選したカードをユーザに付与する処理は、抽選実行部２１４が実行してもよいし、抽選パート進行部１１７が実行してもよい。

図２に示すサーバ２００およびユーザ端末１００の機能は一例にすぎない。サーバ２００は、ユーザ端末１００が備える機能の少なくとも一部を備えていてもよい。ユーザ端末１００は、サーバ２００が備える機能の少なくとも一部を備えていてもよい。ユーザ端末１００およびサーバ２００以外の他の装置をゲームシステム１の構成要素とし、該他の装置にゲームシステム１における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末１００、サーバ２００、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。

＜処理概要＞
本実施形態では、ユーザ端末１００（サーバ２００）は、ユーザに所定の行為の実施を動機付けるために、ゲームプログラム１３１（ゲームプログラム２３１）に基づいて、以下のステップを実行するように構成されている。具体的には、ユーザ端末１００（サーバ２００）は、ユーザによって、ゲームプログラムに基づくゲームにおいて利用可能な有償アイテムを購入する第１行為が実施されたことに応答して、値が第１値よりも大きい第２値に設定されたパラメータ情報をユーザに付与するステップと、ユーザによって、ゲーム上で第１行為とは異なる第２行為が実施されたことに応答して、パラメータ情報に設定されている値を更新するステップと、値が、該パラメータ情報に設定されている第１の閾値に到達した場合に、該パラメータ情報に設定されている、ゲームで利用可能な第１の報酬をユーザに付与するステップと、を実行する構成である。

＜データ構造＞
（カード）
図４は、カードのデータ構造の一例を示す図である。図４は、カード１枚に相当するデータのデータ構造を示す。図４に示すデータ構造を有するカードは、ゲーム情報１３２として、ユーザが保有するカードの枚数分、記憶部１２０に記憶されている。このカードの集合体によりカードデータベース（ＤＢ）が構築される。カードＤＢは、ユーザが保有するカードを一元管理するためのデータベースである。カードＤＢでは、図４に示すデータ構造を有するカードは、１つのレコードとして取り扱われる。

カードは、一例として、カードＩＤ、キャラクタ名、希少度、属性、カードレベル、魅力、練習スキル、メインスキル、サブスキル、および、セリフ管理情報の各項目を含む。

カードＩＤの項目には、カードＩＤが格納されている。カードＩＤは、ユーザが保有するカードをゲームシステム１上で一意に管理するために、カードに固有に割り当てられた識別情報のことである。本実施形態では、同じ内容のカードが複数枚重複して獲得されることがある。したがって、同じ内容のカードが複数枚ある場合には、それぞれのカードを識別するために、それぞれのカードに異なるカードＩＤが付与される。

キャラクタ名の項目には、該カードを分類するグループ識別子として該カードに紐付けられているキャラクタの名前が格納されている。本実施形態では、カードに紐付けられるキャラクタは、本ゲームに登場する複数のキャラクタのうちの１つである。キャラクタは、練習パートおよび実践パートなどにおいて、所定の行為を実施する動作主体であり、例えば、練習パートで使用されるデッキに編成されたカードに紐付けられているキャラクタは、該練習パートにおいて、動作主体として機能する。本ゲームにおいて動作主体として登場する各キャラクタには、他のキャラクタと重複しない固有の名前が設定されている。すなわち、キャラクタ名によって、該カードに紐付けられているキャラクタを一意に識別することができる。キャラクタＩＤも、キャラクタを一意に識別するためにキャラクタ固有に割り当てられている。そのため、該項目には、キャラクタ名に代えてキャラクタＩＤが格納されてもよい。

また、本実施形態では、異なるカードに、同じキャラクタが紐付けられていてもよい。したがって、ユーザが、同じキャラクタが紐付けられているカードを複数枚保有することが起こり得、この場合、その複数枚のそれぞれのカードは、別のカードとして取り扱われる。

希少度の項目には、カードに設定された希少度が格納される。希少度は、カードの本ゲーム内での希少価値を等級で表したものである。一般に、ゲーム上、特に、練習パートおよび実践パートにおいて良好な成果をもたらすカードには、上級の希少度が設定されている。本実施形態では、希少度は、等級が高いものから順に、ＳＳＲ、ＳＲ、Ｒ、Ｎの４段階で表される。なお、希少度は、例えば、カードの入手困難性、より具体的には、カードが当たる抽選における当選確率、ステージのクリア報酬として入手される場合のステージの難易度、または、有償入手の場合の価格などと相関があってもよい。カードの入手困難性が高いほど、カードの希少度は高く設定される。

属性の項目には、カードを属性で分類する場合に、該カードがどの属性に分類されるのかを示す情報が格納されている。本ゲームでは、一例として、赤、青、および、黄の３種類の属性が設けられている。カードは、赤、青、および、黄のいずれかの属性に分類される。なお、属性の名称は、ゲームの文脈に応じて適宜設定されるものである。例えば、アイドルが登場するゲームであれば、情熱、知性、優雅の３属性であってもよいし、魔法使いが登場するゲームであれば、火、水、雷の３属性であってもよい。

属性は、練習パートにおいて、カードを用いてゲームが進行する場にも設定されていてもよい。本ゲームにおいて場とは、デッキに編成されたカードのうち、ゲームを進行させるために使用するカードとして選択されたカードを配置する場所を指す。ユーザは、ゲームで使用したいカードを場に出すことによって、該カードを使用してゲームを進めることができる。場に設定されている属性を場属性と称する。デッキに組み入れられたカードの属性（以下、カード属性）および場属性は、例えば、ステージクリア時の成果を決定するために、練習パートの進行中においてゲーム進行部１１１によって参照される。

また、属性は、カードのパラメータを強化するための強化アイテムにも設定されていてもよい。強化対象カードのカード属性および強化アイテムの属性は、例えば、能力管理パートの進行中において、図示しない能力管理部によって参照される。例えば、カードと同じ属性の強化アイテムを該カードの強化に用いることで、強化効率が向上する。

カードレベルの項目には、カード自体のレベルを示す値が格納される。本実施形態では、カードレベルが高いほど、実践パートにおいて良好な結果をもたらす性能が高いことを意味する。カードレベルは、例えば、練習パートのステージをクリアしたことの成果として上昇させることができる。

魅力の項目には、カードの性能の１つとしての魅力のパラメータ値が格納される。魅力のパラメータ値が高いほど、実践パートにおけるＣＯＭ戦において該カードが有利に作用する。例えば、観客動員数を競うＣＯＭ戦において、魅力が高いほど、多くの観客を動員することができ、ＣＯＭ戦に勝利しやすくなる。魅力は、カードレベルと相関があり、カードレベルが上がるほど、魅力のパラメータ値も高くなる。

練習スキルの項目には、練習スキルの詳細情報が格納される。練習スキルは、カードに紐付けられており、該カードが、練習パートにおけるデッキに組み入れられた場合に、練習パートにおけるステージの進行中に発動可能となるものである。

メインスキルの項目には、メインスキルの詳細情報が格納される。メインスキルは、カードに紐付けられており、該カードが、実践パートにおけるメインデッキに組み入れられた場合に、実践パートにおけるステージの進行中に発動可能となるものである。

サブスキルの項目には、サブスキルの詳細情報が格納される。サブスキルは、カードに紐付けられており、該カードが、実践パートにおけるサブデッキに組み入れられた場合に、実践パートにおけるステージの進行中に発動可能となるものである。

カードに紐付けられている上述の各スキルは、ステージの進行中、該カードに表現されているキャラクタが発動したものとして演出されてもよい。スキルが発動されると、各パートの進行に有利な効果がもたらされる。各スキルの詳細情報としては、例えば、スキルの名称、効果の内容、効果値、発動条件などが含まれる。

セリフ管理情報の項目には、セリフ管理情報が格納される。セリフ管理情報は、キャラクタに発話させるセリフを管理するための情報であり、サーバ２００から供給される。なお、練習パート等において、キャラクタ同士の対話をイベントとして発生させない場合は、カードにおいて、セリフ管理情報の項目は省略されてもよい。

（キャラクタ）
図５は、キャラクタを定義するキャラクタデータのデータ構造の一例を示す図である。図５に示すデータ構造を有するキャラクタデータは、本ゲームの各ゲームパートにおいてキャラクタごとに作成され、ゲーム情報１３２として記憶部１２０に記憶される。ユーザが保有するカードに紐付けられているキャラクタの分だけキャラクタデータが記憶部１２０に記憶されていてもよいし、ユーザがカードを入手する前から、本ゲームに登場するすべてのキャラクタの分のキャラクタデータが記憶部１２０に記憶されていてもよい。

キャラクタデータは、一例として、キャラクタＩＤ、キャラクタ名、所属（カテゴリ）、ペアパラメータテーブル、ストーリーリスト、セリフデータベース（以下、ＤＢ）、および、カードＩＤリストの各項目を含む。

キャラクタＩＤの項目には、キャラクタＩＤが格納されている。キャラクタＩＤは、各ゲームパートにおいて動作主体として機能するキャラクタをゲームシステム１上で一意に管理するために、キャラクタに固有に割り当てられた識別情報のことである。キャラクタＩＤは、体系的にユニークなテキスト列（記号、英数字など）で構成されていることが好ましい。

キャラクタ名の項目には、キャラクタ名が格納されている。キャラクタ名は、ユーザがキャラクタを識別するために、キャラクタに固有に割り当てられた識別情報のことである。キャラクタが男子高校生アイドルである場合は、ユーザが識別しやすいように、人名またはニックネームなどと分かるような文字列で構成されていることが好ましい。

所属の項目には、キャラクタがどの集合に属するのかを示すパラメータが格納されている。ストーリーパートにおいて展開される物語の中で各キャラクタには、該キャラクタの性質または所属などのように、キャラクタのカテゴリを示すさまざまな設定がなされている。所属の項目は、複数設けられてもよい。所属の項目は、ゲームの文脈および世界観などに応じて、より具体的に定義されてもよい。例えば、キャラクタが、男子高校生である場合、所属の項目として、該キャラクタの「学年」、「部活」、「所属寮」、「派閥」、「血液型」などの、キャラクタのカテゴリを表す項目が設けられてもよい。

ペアパラメータテーブルの項目には、ペアパラメータテーブルまたは該ペアパラメータテーブルが格納されている場所を示すアクセス情報が格納されている。ペアパラメータとは、該キャラクタと、その他のキャラクタとの間の関係性を表す数値化したものである。本実施形態では、本ゲームにおいて登場するすべてのキャラクタの組み合わせごとにペアパラメータが設定されている。ペアパラメータテーブルは、図５に示すキャラクタデータによって定義されているキャラクタを基準として、その他のキャラクタとの間に設定されたペアパラメータを、その他のキャラクタごとに一覧にしたものである。

なお、ゲームシステム１は、キャラクタごとにペアパラメータテーブルを管理する代わりに、本ゲームに登場するすべてのキャラクタの組み合わせごとに設定されたペアパラメータを一元管理するためのペアパラメータデータベース（以下、ＤＢ）を記憶部（記憶部１２０または記憶部２２０）において保持していてもよい。この場合、ペアパラメータテーブルの項目には、ペアパラメータＤＢから、該キャラクタにおける他のキャラクタとのペアパラメータを抽出するためのクエリが格納されていてもよい。ペアパラメータテーブルおよびペアパラメータＤＢについては、データ構造図に基づいて後に詳述する。

ストーリーリストの項目には、ストーリーリストまたはストーリーリストにアクセスするためのアクセス情報が格納されている。ストーリーリストは、該キャラクタにまつわる個別ストーリーをまとめたリストである。本実施形態では、一例として、キャラクタにまつわる個別ストーリーは、該キャラクタとその他のキャラクタとのペアに焦点を当てた物語である。ストーリーリストについては、データ構造図に基づいて後に詳述する。

セリフデータベースの項目には、セリフＤＢまたはセリフＤＢにアクセスするためのアクセス情報が格納されている。セリフＤＢは、該キャラクタに紐付けられたセリフパックを一元管理するデータベースである。セリフパックは、練習パートにおいてイベントを進行させるために必要なコンテンツデータおよびそのメタデータなどがひとまとまりにパッケージ化された情報である。具体的には、セリフパックは、該キャラクタまたは該キャラクタとペアリングされた相手キャラクタに発話させる１以上のセリフからなるセリフ群を少なくとも含む。なお、練習パートまたは実践パート等において、対話するイベントが発生しない場合は、該セリフデータベースの項目は、キャラクタデータから省略されてもよい。

カードＩＤリストの項目には、カードＩＤリストまたはカードＩＤリストにアクセスするためのアクセス情報が格納されている。カードＩＤリストは、ユーザが保有するカードのうち、該キャラクタが紐付いているカードのカードＩＤをまとめたリストである。ユーザ端末１００は、カードＩＤリストを参照することにより、ユーザが保有しているカードの中から、該キャラクタが紐付いているカードをすぐに抽出することができる。

本実施形態では、キャラクタとカードとは１対多の関係である。すなわち、１つのカードにおいて紐付けられるキャラクタは１体であるが、異なる複数のカードに対して同じキャラクタが紐付けられ得る。また、同じキャラクタでも、紐付けられているカードが異なれば、カードごとに異なる属性が設定され得る。

また、本実施形態では、キャラクタごとにも、図５に示すとおり、上述の各種項目が紐付けられており、これらのキャラクタごとの情報は、同じキャラクタが紐付けられている各カードで共有される。

換言すれば、カードは、キャラクタごとにグルーピングすることが可能であり、キャラクタは、カードを分類するためのグループ、キャラクタＩＤおよびキャラクタ名は、カードをグルーピングするためのグループ識別子と捉えることができる。そして、同じグループに属する各カードが利用されるとき、該グループに紐付けられた情報が、各カードに共通で参照される。具体的には、ユーザ端末１００は、同じキャラクタが紐付いている各カードをデッキに組み入れて利用する際、該カードに紐付けられているキャラクタを動作させるときに、該キャラクタを定義する上述の各項目を参照する。

なお、カードは、キャラクタ以外にも、上述したとおり、希少度または属性などに基づいて分類することも可能である。さらに、カードは、キャラクタに設定されている所属などに基づいて分類することも可能である。

（ペアパラメータテーブル）
図６の（Ａ）は、ペアパラメータテーブルのデータ構造の一例を示す図である。本ゲームでは、一例として、５人のキャラクタが物語に登場する。５人のキャラクタのキャラクタ名は、一例として、Ａ太、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎である。同図には、一例として、キャラクタ「Ａ太」に紐付けられているペアパラメータテーブルを示している。同様のペアパラメータテーブルが、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎のキャラクタごとに作成される。

ペアパラメータテーブルは、相手キャラクタ、および、ペアパラメータの各項目を含む。ペアパラメータは、上述のとおり、ペアを構成する２人のキャラクタ間の関係性を数値化したものであり、本実施形態では、一例として、友好度と調和度との２種類のペアパラメータが設定されている。

相手キャラクタの項目には、基準となるキャラクタとペアリングされた相手キャラクタのキャラクタ名が格納されている。例えば、図６に示す第１のレコードは、基準となるキャラクタ「Ａ太」と、その相手キャラクタである「Ｂ介」との間のペアパラメータを格納するためのレコードである。

友好度の項目には、キャラクタ間の友好度を示す数値が格納される。友好度とは、ペアとなっているキャラクタ間の友好の度合いを評価する指標である。本実施形態では、数値が高いほど、ペアの友好の度合いが高い、すなわち、２人は仲が良いということを意味する。図６に示す例では、例えば、「Ａ太」と「Ｂ介」との友好度は「２５」である。友好度は、ペアごとの個別ストーリーを解放する条件として参照される。

調和度の項目には、キャラクタ間の調和度を示す数値が格納される。調和度とは、ペアとなっているキャラクタ間の連携の良さを評価する指標である。本実施形態では、１００％を、ペアがとり得る最大の調和度とし、数値が高いほど、ペアの連携が良くとれている、すなわち、該ペアによってよりよいパフォーマンスが出力されるということを意味する。

例えば、実践パートのステージをプレイする際、該ステージで使用するカードのうち、特定の２枚のカードがそれぞれ示すキャラクタ間の調和度の数値に応じて、実践パートのステージにおける、該２体のキャラクタに係る、画像、動画、および音声等での演出が変化してもよい。具体的には、該２体のキャラクタ間の調和度の数値が所定値以上の場合、該２体のキャラクタが親密であることを示す画像、動画、および音声の少なくともいずれかを出力することとしてもよい。また、該２体のキャラクタ間の調和度の数値が高いほど、該演出がより豪華な演出になるようにしてもよい。また、該２体のキャラクタ間の調和度の数値が高いほど、該演出の回数、すなわち演出頻度が増加してもよい。

また例えば、該２体のキャラクタ間の調和度の数値が高いほど、実践パートのステージ進行が有利になってもよい。具体的には、該２体のキャラクタ間の調和度の数値が高いほど、実践パートのステージにおいて発動可能なスキルの効果値または効果内容の継続時間が増加してもよい。また、該２体のキャラクタ間の調和度の数値が高いほど、実践パートのステージにおいて、該２体のキャラクタの少なくとも一方のスキルの、発動可能回数および発動機会の少なくとも一方が増加してもよい。

また例えば、上述の２体のキャラクタ間の調和度の数値が高いほど、これらのキャラクタ、または該キャラクタに対応するカードに設定されている各種パラメータの値を、ゲームが有利になるように変更してもよい。具体的には、該２体のキャラクタ間の調和度の数値が高いほど、これらのキャラクタに対応するカードの魅力のパラメータ値が上昇してもよい。また、実践パートのステージが、ユーザの自陣営と、敵陣営とが対戦する対戦形式のステージである場合、自陣営の特定の２枚のカードが示すキャラクタ間の調和度と、敵陣営の特定の２枚のカードが示すキャラクタ間の調和度とを比較してもよい。そして、該比較の結果、調和度が高い方の陣営の、該特定の２枚のカードのパラメータを増加させてもよい。もしくは、該比較の結果、調和度が低い方の陣営の、該特定の２枚のカードのパラメータを低下させてもよい。

また例えば、実践パートのステージが、自陣営のターンと敵陣営のターンとを実行することで進行するゲームの場合、前述の比較の結果、調和度が高い方の陣営のターンを先に行うようにしてもよい。一例として、調和度が高い方の陣営が対戦で有利な先手を取る確率を高めるなどが想定される。または、前述の比較の結果、調和度が高い方の陣営のターンを実行する頻度を上昇させてもよい。

本実施形態では、一例として、調和度は、練習パートにおいて、ペアが練習を積むことにより高めることができ、実践パートにおいて、ペアが特定のパフォーマンスを出力するために消費される。すなわち、調和度は、ユーザが、練習パートと実践パートとを繰り返しプレイすることにより増減する数値である。

図６の（Ｂ）は、ペアパラメータＤＢのデータ構造の一例を示す図である。本実施形態では、ペアパラメータＤＢにおいて、本ゲームに登場するキャラクタの組み合わせ、すなわち、ペアを主キーとし、該ペアごとにレコードが作成される。そして、該レコードにペアパラメータが格納されている。具体的には、友好度と調和度とが格納されている。

本実施形態では、上述したとおり、５人のキャラクタが登場する。この場合、５人のキャラクタのすべての組み合わせは、１０通りあるので、ペアパラメータＤＢは、１０個のレコードを有する。ユーザ端末１００の制御部１１０は、ペアパラメータＤＢから、１人のキャラクタをキーにして、ペアパラメータのレコードを抽出してもよい。例えば、「主キーにＡ太が含まれているレコードを抽出する」というクエリに基づいてペアパラメータＤＢを操作すれば、図６の（Ａ）に示すとおり、Ａ太についてのペアパラメータテーブルが得られる。

（ストーリーリスト）
図７は、ストーリーリストのデータ構造の一例を示す図である。同図には、一例として、キャラクタ「Ａ太」に紐付けられているストーリーリストを示している。同様のストーリーリストが、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎のキャラクタごとに作成される。

ストーリーリストは、相手キャラクタ、ストーリーＩＤおよび状態の各項目を含む。

相手キャラクタの項目には、基準となるキャラクタ（ここでは「Ａ太」）とペアリングされた相手キャラクタのキャラクタ名が格納されている。

ストーリーＩＤの項目には、該ペアに紐付けられた個別ストーリーのストーリーＩＤが格納されている。ストーリーＩＤは、個別ストーリーに対応するコンテンツデータをゲームシステム１において一意に識別するための識別情報である。個別ストーリーを一意に識別できる情報であれば何でもよく、例えば、該項目には、ストーリーＩＤに代えて、個別ストーリーごとに設定された物語のタイトル、章番号などが格納されていてもよい。あるいは、該項目には、ストーリーＩＤに代えて、個別ストーリーに対応するコンテンツデータが格納されている場所を示すアドレス情報が格納されていてもよい。

個別ストーリーは、１つのペアにつき、複数個ユーザに提供されてもよい。同図に示す例では、例えば、Ａ太とＢ介とのペアにまつわる個別ストーリーは、ストーリーＩＤ「ＡＢ００１」から「ＡＢ００３」までの３話分ユーザに提供されている。

状態の項目には、該個別ストーリーの状態を示すパラメータが格納されている。個別ストーリーの状態を示すパラメータは、一例として、個別ストーリーが解放済みであるか、未解放であるのかを示すフラグであってもよい。本実施形態では、個別ストーリーが「解放済みである」とは、ユーザが、該個別ストーリーのコンテンツデータにユーザ端末１００を介してアクセスすることが可能であって、該個別ストーリーをユーザが読むことができる状態であることを意味する。

さらに、上述の状態の項目または別に設けられた項目には、個別ストーリーの状態を示すパラメータとして、解放進捗が格納されていてもよい。解放進捗は、個別ストーリーが未解放である場合に、解放の条件をユーザがどれだけ満たしているのかを示した情報である。本実施形態では、解放進捗は、一例として、分数であり、解放に必要な友好度を示す分母と、ユーザがゲームをプレイすることによって蓄積した該ペアの現在の友好度を示す分子とで構成される。

なお、個別ストーリーは、図６の（Ｂ）に示したペアパラメータＤＢと同様に、ペアを主キーとするデータベースにて、ペアごとに一元管理されてもよい。

（ストーリーリスト）
図７は、ストーリーリストのデータ構造の一例を示す図である。同図には、一例として、キャラクタ「Ａ太」に紐付けられているストーリーリストを示している。同様のストーリーリストが、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎のキャラクタごとに作成される。

ストーリーリストは、相手キャラクタ、ストーリーＩＤおよび状態の各項目を含む。

相手キャラクタの項目には、基準となるキャラクタ（ここでは「Ａ太」）とペアリングされた相手キャラクタのキャラクタ名が格納されている。

ストーリーＩＤの項目には、該ペアに紐付けられた個別ストーリーのストーリーＩＤが格納されている。ストーリーＩＤは、個別ストーリーに対応するコンテンツデータをゲームシステム１において一意に識別するための識別情報である。個別ストーリーを一意に識別できる情報であれば何でもよく、例えば、該項目には、ストーリーＩＤに代えて、個別ストーリーごとに設定された物語のタイトル、章番号などが格納されていてもよい。あるいは、該項目には、ストーリーＩＤに代えて、個別ストーリーに対応するコンテンツデータが格納されている場所を示すアドレス情報が格納されていてもよい。

個別ストーリーは、１つのペアにつき、複数個ユーザに提供されてもよい。同図に示す例では、例えば、Ａ太とＢ介とのペアにまつわる個別ストーリーは、ストーリーＩＤ「ＡＢ００１」から「ＡＢ００３」までの３話分ユーザに提供されている。

状態の項目には、該個別ストーリーの状態を示すパラメータが格納されている。個別ストーリーの状態を示すパラメータは、一例として、個別ストーリーが解放済みであるか、未解放であるのかを示すフラグであってもよい。本実施形態では、個別ストーリーが「解放済みである」とは、ユーザが、該個別ストーリーのコンテンツデータを所有していること、または、該コンテンツデータにユーザ端末１００を介してアクセスする権限を有していることであって、該個別ストーリーをユーザが読むことができる状態であることを意味する。

さらに、上述の状態の項目または別に設けられた項目には、個別ストーリーの状態を示すパラメータとして、解放進捗が格納されていてもよい。解放進捗は、個別ストーリーが未解放である場合に、解放の条件をユーザがどれだけ満たしているのかを示した情報である。本実施形態では、解放進捗は、一例として、分数であり、解放に必要な友好度を示す分母と、ユーザがゲームをプレイすることによって蓄積した該ペアの現在の友好度を示す分子とで構成される。

なお、個別ストーリーは、図６の（Ｂ）に示したペアパラメータＤＢと同様に、ペアを主キーとするデータベースにて、ペアごとに一元管理されてもよい。

（ユーザ情報）
図８は、ユーザ情報のデータ構造の一例を示す図である。ユーザ情報は、ユーザ端末１００の記憶部１２０において、ユーザ情報１３３として記憶され、管理されている。また、ユーザ情報１３３は、該ユーザ端末１００のユーザ、または、該ユーザ端末１００の識別情報が関連付けられて、サーバ２００の記憶部２２０においても記憶され、両者は同期するように適宜管理される。

ユーザ情報１３３は、一例として、ユーザＩＤ、ユーザ区分、購入ダイヤ、配布ダイヤ、抽選チケット、および、抽選ポイントの各項目を含む。ユーザ情報１３３は、ユーザランク、および、経験値などの各種の項目を含んでいてもよい。

ユーザＩＤの項目には、ゲームシステム１においてユーザを一意に識別するためのユーザ識別情報が格納されている。ユーザＩＤに加えて、ユーザ名が格納されていてもよい。ユーザ名は、ゲームシステム１をプレイするユーザ本人を指す名称である。ユーザ名は、例えば、ユーザ本人および他のユーザが、該ユーザ本人を識別するために用いられる。

ユーザ区分の項目には、ユーザが、契約ユーザおよび一般ユーザのいずれの区分に該当するのかを示す情報が格納されている。ユーザが、サービスに対する対価の支払いを行って契約が成立すると、購入処理部１１５は、該項目の格納されている情報を、一般ユーザから契約ユーザへと変更する。

購入ダイヤの項目には、ユーザが購入行動を経て入手し、所有している購入ダイヤの数が格納されている。ユーザがダイヤに対する対価の支払いを行ってダイヤを入手すると、購入処理部１１５は、該項目の数値を、購入された分更新する。また、ユーザが抽選に興じるなどしてダイヤを消費すると、購入処理部１１５は、該項目の数値を、抽選で消費された分減算する。

配布ダイヤの項目には、ユーザがプレイを経て入手し、所有している配布ダイヤの数が格納されている。例えば、ユーザが、ストーリーデータを読了するなどしてゲームの進行状況について所定の条件を満足すると、ゲーム進行部１１１は、該項目の数値を、読了報酬として付与された分更新する。購入ダイヤと同様に、抽選で配布ダイヤが消費された場合には、当該項目の数値が抽選で消費された分減じられる。

抽選チケットの項目には、ユーザが所有している抽選チケットの枚数が格納されている。抽選ポイントの項目には、ユーザが所有している抽選ポイントが格納されている。

ユーザが、抽選チケットを消費して抽選を実施した場合、抽選パート進行部１１７は、抽選チケットの項目の数値を消費された分減算する。ユーザが本ゲームをプレイし、ゲームの進行状況が所定の条件を満足したことにより抽選チケットが該ユーザに付与されると、ゲーム進行部１１１は、抽選チケットの項目の数値を付与された分更新する。

ユーザが本ゲームをプレイし、ゲームの進行状況が所定の条件を満足したことにより抽選ポイントが該ユーザに付与されると、ゲーム進行部１１１は、抽選ポイントの項目の数値を付与された分更新する。更新の結果、抽選ポイントが１００に到達すると、ゲーム進行部１１１は、抽選チケットの項目の数値を１増分して、抽選ポイントを０ポイントにリセットしてよい。１回の抽選ポイントの付与により、抽選ポイントが１００を超えた場合、そのオーバーフロー分は、リセット後に持ち越され、更新されることが好ましい。

（パラメータ情報）
図９は、パラメータ情報のデータ構造の一例を示す図である。パラメータ情報は、ユーザ端末１００の記憶部１２０において、ユーザ情報１３３の一部として記憶され、管理されている。パラメータ情報は、該ユーザ端末１００のユーザ、または、該ユーザ端末１００の識別情報が関連付けられて、サーバ２００の記憶部２２０においても記憶され、両者は同期するように適宜管理される。

パラメータ情報は、一例として、所有フラグ、パラメータ種別、閾値、報酬、現在値、および、満杯回数の各項目を含む。

所有フラグの項目には、ユーザが、パラメータ情報を所有しているか否かを示すフラグが格納されている。パラメータ種別の項目には、パラメータ情報の種別を指定する情報が格納されている。

一例として、パラメータ情報は、スタンプカードであり、スタンプカードは、グレードや、どういった行為によって貯まるスタンプかなどに応じて様々な種別があってよい。一例として、グレードの低いものから順に、シルバー、ゴールド、ブラックの３つのグレードの異なるスタンプカードが用意されている。例えば、ユーザには、一律、シルバーグレードのスタンプカード（以下、シルバースタンプカード）が配布される。後述する実施形態２では、契約ユーザに限り、ゴールドグレードのスタンプカード（以下、ゴールドスタンプカード）またはブラックグレードのスタンプカード（以下、ブラックスタンプカード）が配布されることがある。一例として、本ゲームにおいて、ユーザには、スタンプカードは、最大で１枚所有するように配布される。同種、異種問わず、ユーザに、同時に２枚以上のスタンプカードが配布されることがないものとする。

所有フラグとパラメータ情報の種別とによって、どの種別のスタンプカードをユーザが所有しているのかが管理される。「１」は、そのスタンプカードをユーザが所有していることを示し、「０」は、そのスタンプカードをユーザが所有していないことを示す。図示の例では、ユーザは、シルバースタンプカードを所有しており、その他の種別のスタンプカードを所有していないことを示す。

閾値の項目には、そのパラメータ情報に設定されている１以上の閾値が格納されている。閾値は、ユーザに報酬を付与する情報を規定する値である。パラメータ情報に関連付けてユーザが所有する値が閾値に到達した場合に該閾値に対応する報酬が該ユーザに付与される。本実施形態では、パラメータ情報はスタンプカードであるので、閾値は、スタンプカードに設定されている目標スタンプ数である。

報酬の項目には、パラメータ情報に関連付けてユーザが所有する値が上述の閾値に到達した場合にユーザに付与される報酬の内容を示す情報が格納されている。一例として、図示のとおり、報酬は、閾値ごとに設定されているが、各閾値で同じ報酬が付与されるように、当該項目が設定されてもよい。例えば、図示の例では、シルバースタンプカードにおいて、スタンプを４個貯めた場合にユーザに付与される報酬は、スタミナ回復アイテムである。なお、スタミナとは、ユーザは、練習パートおよび実践パートにおける各ステージを１回プレイするごとにその引き換えとして値が消費されるパラメータのことである。スタミナが尽きると、あるいは、蓄積されているスタミナの値が、ステージ１回分の必要量に満たないと、ユーザは、ステージをプレイすることができないものとする。スタミナ回復アイテムは、このスタミナの値を回復させるアイテムを指す。本ゲームにおいて、スタミナ回復アイテムは、１度使うと無くなる消耗品として扱われるものとする。報酬の他の例としては、ダイヤ、カードを強化するための強化アイテム、ＳＳＲの希少度のカードが高確率または１００％の確率で当選する特殊な抽選チケット、特定のキャラクタのカードが高確率または１００％の確率で当選する特殊な抽選チケット、あるいは、抽選を実施する際に消費されるダイヤの個数が割り引かれる割引チケットなどが想定される。

現在値の項目には、そのパラメータ情報に関連付けてユーザが現在所有している値が格納される。パラメータ情報は、スタンプカードであるので、現在値の項目には、スタンプカードに現在押印されているスタンプ数が格納されている。図示の例では、ユーザは、シルバースタンプカードを所有している。よって、現在値「６」は、該シルバースタンプカードにスタンプが６個押されていることを示している。現在値の項目は、図示のとおり、パラメータ情報の種別を問わずに、１つ設けられて、１ユーザにつき１つの現在値が管理されるようなデータ構造であってもよい。上述のデータ構造により、スタンプカードのグレードを問わず、１ユーザにつき１つの現在値を管理するものとする。これにより、スタンプ数を維持しつつスタンプカードのグレードだけを変更するなど、紙のスタンプカードでは通常行われない電子的処理を実施することが可能となる。グレードの変更については、実施形態２にて詳述する。別の実施形態では、現在値の項目は、パラメータ情報の種別ごとに設けられるデータ構造であってもよい。

満杯回数の項目には、所定期間において、ユーザが、そのパラメータ情報に関して値を満杯にすることができた回数が格納されている。例えば、パラメータ情報は、スタンプカードであり、スタンプカードには最大１０個のスタンプを押印することができるものとする。一例として、所定期間を１ヶ月とする。この場合、図示されているパラメータ情報は、ユーザは、１枚のシルバーカードを１０個のスタンプで満杯にし、現在、２枚目のシルバーカードについてスタンプを６個まで貯めているということを意味している。

このように、制御部１１０の各部は、月ごとにスタンプを１０個全部貯めたスタンプカードの枚数を管理してもよい。これにより、ゲームシステム１は、月ごとに満杯にできたスタンプカードの枚数に応じて、月ごとに報酬をユーザに付与することができる。

＜処理フロー＞
図１０は、ゲームシステム１が、パラメータ情報を管理する処理の流れを示すフローチャートである。以下では、一例として、図１０に示す各ステップは、ユーザ端末１００が実行するものとして説明するが、すべてのステップまたは一部のステップをサーバ２００が実行してもよい。

一例として、スタンプカードが、パラメータ情報としてユーザに配布されるものとする。スタンプカードにおいて、第２行為としてユーザが抽選を実施するごとにスタンプが貯まる。ユーザが、第２行為とは異なる第１行為としてダイヤを購入すると、購入特典として、第２行為実施相当のスタンプが予め押印された状態のスタンプカードがユーザに配布されるものとする。カード管理部１１２は、ユーザが購入手続きを経ずに配布ダイヤを獲得したとしても、これを第１行為が実施されたとはみなさず、スタンプカードを配布しないものとする。

図１０に示す、パラメータ情報を管理するための一連の処理は、ユーザが、上述の第１行為、または、第２行為を実施することにより開始される。

ステップＳ１０１では、購入処理部１１５は、第１行為としてダイヤの購入を指示する入力操作をユーザから受け付ける。購入処理部１１５は、ユーザの入力操作に応じてダイヤを購入するための支払処理を実行した場合に、ステップＳ１０１のＹＥＳからステップＳ１０６に進む。

あるいは、ステップＳ１０２では、抽選パート進行部１１７は、第２行為として抽選の実行を指示する入力操作をユーザから受け付ける。抽選パート進行部１１７は、ユーザの入力操作に応じて抽選の実行をサーバ２００に対して要求した場合に、ステップＳ１０２のＹＥＳからステップＳ１０３に進む。

ステップＳ１０３では、カード管理部１１２は、ユーザ情報１３３、具体的には、図９に示すパラメータ情報の所有フラグを参照して、ユーザがスタンプカードを所有しているか否かを判定する。ユーザがスタンプカードをまだ所有していない場合、ステップＳ１０３のＮＯからステップＳ１０４に進み、ユーザがスタンプカードをすでに所有している場合、ステップＳ１０３のＹＥＳからステップＳ１０５に進む。

ステップＳ１０４では、カード管理部１１２は、第２行為実施相当数の値が設定されたパラメータ情報をユーザに付与する。具体的には、まず、発行部１１２１は、図９に示すパラメータ情報において所有フラグを「０」から「１」に更新することにより、１枚のスタンプカードをユーザに所有させる。そして、押印部１１２２は、ステップＳ１０２に応答して抽選が実施された回数に応じた個数のスタンプを発行されたばかりのスタンプカードに押印する。

ステップＳ１０５では、押印部１１２２は、すでにユーザに所有されているパラメータ情報に関連付けられている現在値を、第２行為実施相当数分更新する。具体的には、押印部１１２２は、すでにユーザが所有しているスタンプカードに、抽選が実施された回数に応じた個数のスタンプを押印する。

ステップＳ１０６では、カード管理部１１２は、ステップＳ１０３と同様に、所有フラグを参照して、ユーザがスタンプカードを所有しているか否かを判定する。ユーザがスタンプカードをまだ所有していない場合、ステップＳ１０６のＮＯからステップＳ１０７に進み、ユーザがスタンプカードをすでに所有している場合、ステップＳ１０６のＹＥＳからステップＳ１０８に進む。

ステップＳ１０７では、カード管理部１１２は、第２行為実施相当数より大きい数の値が設定されたパラメータ情報をユーザに付与する。具体的には、まず、発行部１１２１は、図９に示すパラメータ情報において所有フラグを「０」から「１」に更新することにより、１枚のスタンプカードをユーザに所有させる。そして、押印部１１２２は、抽選が実施されたときに押されるスタンプ数よりも多い数のスタンプを、発行されたばかりのスタンプカードに押印する。例えば、本実施形態において、１枚のカードが当選する抽選１回につき１個のスタンプが押印されるとすると、押印部１１２２は、１個よりも多い２個のスタンプを発行されたばかりのスタンプカードに押印する。これにより、抽選を実施したことがなくスタンプカードを所有していなかったユーザに対して、ダイヤを購入した特典として、抽選２回分相当のスタンプがあらかじめ押印されているスタンプカードを付与することができる。

ステップＳ１０８では、押印部１１２２は、すでにユーザに所有されているパラメータ情報に関連付けられている現在値を、第２行為実施相当数より大きい数の値分更新してもよい。例えば、本実施形態において、１枚のカードが当選する抽選１回につき１個のスタンプが押印されるとすると、押印部１１２２は、１個よりも多い２個のスタンプをすでにユーザが所有しているスタンプカードに押印する。これにより、スタンプカードをすでに所有していたユーザに対して、ダイヤを購入した特典として、抽選２回分相当のスタンプを押印することができる。

ステップＳ１０９では、報酬付与部１１４は、ユーザが所有しているパラメータ情報に関連付けられている値が、該パラメータ情報に設定されている閾値に到達したか否かを判定する。具体的には、報酬付与部１１４は、ステップＳ１０４、Ｓ１０５、Ｓ１０７、および、Ｓ１０８においてスタンプが押印された後、スタンプ数が、予め設定されている目標のスタンプ数に到達したか否かを判定する。例えば、図９に示すとおり、シルバースタンプカードには、１番目に閾値「４」、２番目に閾値「５」、３番目に閾値「７」、４番目に閾値「９」・・・が設定されている。現在のスタンプ数を示す現在値「６」が、スタンプが２個押印された結果「８」に更新された場合には、報酬付与部１１４は、現在値が、３番目の閾値「７」に到達したと判定する。現在値が、閾値に到達したと判定した場合には、報酬付与部１１４は、ステップＳ１０９のＹＥＳからステップＳ１１０に進む。

ステップＳ１１０では、報酬付与部１１４は、到達した閾値に対応する報酬をユーザに付与する。例えば、上述の例では、報酬付与部１１４は、３番目の閾値「７」に対応する３番目の報酬「スタミナ回復アイテム」をユーザに付与する。

＜画面例＞
（抽選画面とスタンプカード画面）
図１１の（Ａ）および（Ｂ）は、ユーザ端末１００の表示部１５２に表示されるゲーム画面の一例を示す図である。図１１の（Ａ）に示すゲーム画面は、ユーザの第２行為の実施を支援するためのゲーム画面である。該ゲーム画面は、一例として、ユーザが抽選の実施を指示する入力操作を行うためのＵＩとして機能する抽選画面４００である。

抽選パート進行部１１７は、例えば、抽選パートの進行を開始した後、図１０に示すステップＳ１０２が実行されるまで、抽選画面４００を表示部１５２に表示する。

抽選画面４００は、一例として、ダイヤ所有数４０１、チケット所有数４０２、ポイント所有数４０３、および、抽選指示ボタン４０４～４０７などの各種のＵＩ部品を含む。さらに、抽選画面４００は、実行される抽選の母集団、および、抽選の規則になどに係る情報をユーザに提示するためのＵＩ部品を含んでいてもよい。例えば、当選するカードの一覧、および、それぞれのカードの当選確率などを開示してもよい。

ダイヤ所有数４０１は、ユーザが所有しているダイヤの個数をユーザに提示するためのＵＩ部品である。ダイヤ所有数４０１は、図８に示す購入ダイヤの項目と、配布ダイヤの項目とに基づいて生成される。ダイヤ所有数４０１は、一例として、購入ダイヤと配布ダイヤとに分けて所有数を示すように構成される。

チケット所有数４０２は、ユーザが所有している抽選チケットの枚数をユーザに提示するためのＵＩ部品である。チケット所有数４０２は、図８に示す抽選チケットの項目に基づいて生成される。

ポイント所有数４０３は、ユーザが所有している抽選ポイントをユーザに提示するためのＵＩ部品である。ポイント所有数４０３は、図８に示す抽選ポイントの項目に基づいて生成される。ポイント所有数４０３は、一例として、１００ポイントを満杯として、現在のポイントと、満杯のときのポイント（１００ポイント）との差分が視覚的に分かり易いゲージの形態で構成されることが好ましい。

抽選指示ボタン４０４～４０７は、ユーザが抽選の実行をゲームシステム１に対して指示するためのＵＩ部品である。例えば、ユーザが、抽選指示ボタン４０４～４０７をタップすると、抽選パート進行部１１７は、タップされたボタンに対応する態様にて抽選が実行されるように、サーバ２００に対して要求する。サーバ２００の抽選実行部２１４は、該要求に応答して、抽選を実行し、当選結果をユーザ端末１００に返す。当選結果に基づいて、ユーザ端末１００は、当選したカードをユーザに所有させる。

一例として、抽選画面４００において、ダイヤと引き換えに抽選を１回実行することを指示するための抽選指示ボタン４０４と、ダイヤと引き換えに抽選を１０回実行することを指示するための抽選指示ボタン４０５と、抽選チケットと引き換えに抽選を１回実行することを指示するための抽選指示ボタン４０６と、抽選チケットと引き換えに抽選を１０回実行することを指示するための抽選指示ボタン４０７とを設けてもよい。各ボタンには、抽選の実行に必要な各アイテムの数量が明示されていてもよい。１回の抽選の実施とは、１枚のカードが当選するくじを１回引くことを指すものとする。したがって、１０回抽選を実施すると、合計で１０枚のカードが当選することになる。

抽選指示ボタン４０４または抽選指示ボタン４０５がタップされて、ダイヤと引き換えに抽選することが指示された場合、抽選パート進行部１１７は、購入ダイヤを優先的に消費してもよいし、配布ダイヤを優先的に消費してもよいし、入手日時が古いものから順に消費してもよい。

以上のように抽選画面４００を操作することにより、ユーザは、第２行為としての抽選を、所望の態様で、所望の回数、実施することができる。

図１１の（Ｂ）に示すゲーム画面は、ユーザが第２行為を実施したことに応答してパラメータ情報が処理された結果をユーザに通知するためのゲーム画面である。該ゲーム画面は、一例として、抽選の実施回数に応じてスタンプが押印されたことをユーザに通知するＵＩとして機能するスタンプカード画面４５０である。

カード管理部１１２は、抽選が実行された後、図１０に示すステップＳ１０４またはＳ１０５が実行されたときに、スタンプカード画面４５０を表示部１５２に表示する。

スタンプカード画面４５０は、一例として、スタンプカード４５１をＵＩ部品として含む。スタンプカード画面４５０は、図示のとおり、必要に応じて、抽選指示ボタン４０４～４０７を含んでいてもよい。さらに、スタンプカード画面４５０は、今回実行された抽選によって何個のスタンプが押印されたか、および、次の報酬までスタンプがあと何個必要かなどの情報をユーザに提示するための情報を含んでいてもよい。

スタンプカード４５１は、一例として、スタンプ押印領域４５２と、報酬４５３および４５４とをＵＩ部品として含む。さらに、ユーザが所有しているスタンプカードにスタンプが押印されている場合には、スタンプカード４５１は、スタンプ４５５をＵＩ部品として含む。物理的なスタンプカードと同様に、スタンプカード４５１は、スタンプ押印の条件を説明する文章を含んでいてもよい。

スタンプ押印領域４５２は、スタンプを、スタンプカードが保持し得る満杯の個数分押印するためのスペースを少なくとも有する。各スペースには、押印個数を示す数値が関連付けられている。スタンプカードは、最大で１０個スタンプを押印できるので、スタンプ押印領域４５２は、１０個分のスペースを有し、各スペースには、１～１０の数値が関連付けられている。図示の例では、テーブルを構成するように各スペースが配置されているが、すごろくのように、各スペースがチェーンでつながって並んでいるような態様で配置されてもよい。

ユーザが所有しているスタンプカードに設定されている閾値と該閾値に到達したときに獲得される報酬は、一例として、閾値の数値が関連付けられているスペースに報酬のアイコンを配置することにより、ユーザに示されてもよい。報酬のアイコンは、一例として、スタミナ回復アイテムを示すアイコンとしての報酬４５３、および、ダイヤを示すアイコンである報酬４５４である。例えば、スタンプカードに設定されている１番目の閾値は「４」であって、１番目の閾値に対応付けられている１番目の報酬がスタミナ回復アイテムである場合、１番目の閾値「４」が関連付けられているスペース４５６に、スタミナ回復アイテムを示す報酬４５３が配置される。これにより、ユーザは、スタンプをあと何個貯めればどのような報酬を獲得できるのかを一目で確認することができる。

カード管理部１１２は、今回実行された抽選の回数に相当する数のスタンプを、スタンプカード４５１に押印するアニメーションを出力することが好ましい。例えば、カード管理部１１２は、今回押印されたスタンプ４５５の周囲に星が光るようなエフェクトを付加してもよい。これにより、今回押印されたスタンプ４５５を、すでに押印されていたスタンプ４５５よりも目立たせることができる。これにより、ユーザは、今回実施した抽選によってスタンプが何個押されたのかを直感的に認知することができる。

さらに、カード管理部１１２は、スタンプカード画面４５０にも、抽選指示ボタン４０４～４０７を配置し、ユーザに対してさらなる抽選の実施を促してもよい。ユーザに対して、スタンプをあと何個貯めればどのような報酬を獲得できるのかを提示したまさにそのタイミングで、抽選指示ボタン４０４～４０７を提示することにより、ユーザに第２行為、すなわち、抽選の実施を、一層強く動機付けることができる。

（購入画面とスタンプカード画面）
図１２の（Ａ）および（Ｂ）は、ユーザ端末１００の表示部１５２に表示されるゲーム画面の一例を示す図である。図１２の（Ａ）に示すゲーム画面は、ユーザの第１行為の実施を支援するためのゲーム画面である。該ゲーム画面は、一例として、ユーザがダイヤの購入を指示する入力操作を行うためのＵＩとして機能する購入画面５００である。

購入処理部１１５は、例えば、本ゲームの不図示のホーム画面において、購入画面５００の表示を指示する入力操作が行われた後、図１０に示すステップＳ１０１が実行されるまで、購入画面５００を表示部１５２に表示する。

購入画面５００は、一例として、販売個数５０１、価格５０２、および、購入ボタン５０３などの各種のＵＩ部品を含む。

販売個数５０１は、運営団体が販売するダイヤの個数をユーザに提示するためのＵＩ部品である。価格５０２は、上述の個数のダイヤの価格をユーザに提示するためのＵＩ部品である。購入ボタン５０３は、ユーザが、上述の個数のダイヤを購入することをユーザ端末１００に対して指示するためのＵＩ部品である。価格５０２は、購入ボタン５０３に紐付けられており、図示のとおり、購入ボタン５０３の表示領域上に配置されてもよい。

ユーザは、ダイヤを購入することを決めたら、購入ボタン５０３をタップできる。購入処理部１１５は、購入ボタン５０３に対する入力操作に応答して、サーバ２００の販売処理部２１２と協働して購入処理を実行し、上述の個数のダイヤをユーザに所有させる。なお、ダイヤは、１０個以上の単位でまとめて購入できるようにパッケージングされ、販売されてもよい。この場合、購入画面５００において、図示のように、単位が異なる販売パッケージごとに、販売個数５０１、価格５０２、および、購入ボタン５０３が設けられてもよい。別の実施形態では、ダイヤは、ばら売りされてもよく、この場合、購入画面５００において、ユーザが購入個数を指定するためのＵＩ部品が配置される。

以上のように購入画面５００を操作することにより、ユーザは、第１行為としてのダイヤの購入を実施することができる。

図１２の（Ｂ）に示すゲーム画面は、ユーザが第１行為を実施したことに応答してパラメータ情報が処理された結果をユーザに通知するためのゲーム画面である。該ゲーム画面は、一例として、ダイヤ購入の特典として、スタンプ押印済みのスタンプカードが発行されたことをユーザに通知するＵＩとして機能するスタンプカード画面５５０である。

カード管理部１１２は、例えば、購入処理が実行された後、図１０に示すステップＳ１０７またはＳ１０８が実行されたときに、スタンプカード画面５５０を表示部１５２に表示する。

スタンプカード画面５５０は、一例として、スタンプカード５５１をＵＩ部品として含む。さらに、スタンプカード画面５５０は、ダイヤが購入されたことの特典としてスタンプカード５５１が発行されたことをユーザに認知させる情報を含んでいてもよい。さらに、スタンプカード画面５５０は、特典としてのスタンプカード５５１は、発行の時点で、すなわち、抽選を実施する前からすでに１個以上のスタンプが押印済みの付加価値が付いたスタンプカードであることをユーザに認知させる情報を含んでいてもよい。

スタンプカード５５１は、図１１の（Ｂ）に示すスタンプカード４５１と同様に、スタンプ押印領域４５２、報酬４５３、および、報酬４５４を含む。スタンプカード４５１と異なる点は、特典として、スタンプがすでに押印されていることを示すスタンプ５５２が配置されている点である。

さらに、カード管理部１１２は、スタンプカード画面５５０において、上述の認知させる情報と併せて、付加価値であるスタンプ５５２を目立たせるための強調アイコン５５３をスタンプ５５２の周辺に配置してもよい。

以上の各種のＵＩ部品により、ユーザは、スタンプカード５５１を見て、ダイヤの購入特典として付加価値が付いたスタンプカードを獲得したことを意識することができ、ダイヤを購入したことについて満足感を得ることできる。

さらに、スタンプ５５２は、抽選の実行時に押印されるスタンプ４５５と同じ表示態様で配置されてもよいが、ダイヤの購入特典であることを示すために、スタンプ４５５とは異なる表示態様で配置されてもよい。例えば、スタンプ５５２は、スタンプ４５５とは異なる形状、または、異なる色で配置されてもよい。これにより、ユーザは、これ以後、スタンプカード５５１が表示部１５２に表示される度に、スタンプ５５２は、ダイヤの購入特典として押印されたものであるということを意識することができ、ダイヤを購入したことについて一層満足感を得ることできる。

さらに、カード管理部１１２は、購入されたダイヤを使って、すぐに、抽選を実施できるように、スタンプカード画面５５０において、抽選画面４００を呼び出すためのボタン５５４を配置することが好ましい。

第２行為（抽選）の実施を可能とするための第１行為（ダイヤ購入）が実施された直後に、第２行為によってスタンプが貯められるスタンプカードが特典として提示される。そして、スタンプを貯めるに際して有利になる付加価値ともにスタンプカードが提示されたまさにそのタイミングで、第２行為を促すボタン５５４を提示することにより、ユーザに第２行為、すなわち、抽選の実施を、より一層強く動機付けることができる。

〔実施形態２〕
実施形態２では、契約ユーザに対して、所定期間内にユーザが集めたパラメータ情報の値に応じて、パラメータ情報のグレードを、該所定期間ごとに変更するサービスを提供する。契約ユーザとは、上述のとおり、運営団体に対して料金を支払い、定められた契約期間の間、サービスを受け取る資格があるユーザを指す。その他のユーザを一般ユーザと称して、契約ユーザと区別する。

＜月極サービスについて＞
一例として、契約ユーザが受けるサービスは、月極サービスであってよい。月極サービスでは、図１３に示すとおり、サービスを提供する期間である契約期間が月単位で定められ、該サービスの対価の支払は、月単位で実施されてよい。

図１３は、本実施形態に係るゲームシステム１が提供する月極サービスにおける、契約期間の定め方の一例を説明する図である。

本実施形態では、一例として、月極サービスの月ごとの契約期間の開始時点および終了時点は、ユーザによらず、また、ユーザの支払時点によらず、一律に予め固定されている。一例として、月極サービスの契約期間の開始時点は、月の初日であり、終了時点は、月の末日である。例えば、１月度の月極サービスの契約期間は、１月１日から１月３１日までであり、２月度の月極サービスの契約期間は、２月１日から２月２８日（閏年は、２月２９日）までである。

本実施形態では、一例として、月極サービスの対価の支払いは、契約期間の開始時点より前から、契約期間の終了時点より前まで受け付けられる。以下では、月極サービスの対価の支払いを、第１支払と称する。

本実施形態では、販売処理部２１２は、契約期間の開始時点、および、上述の第１支払をユーザから受け付けた支払時点のいずれか遅い方の時点から、契約期間の終了時点までを実質契約期間と定める。サービス提供部２１３は、実質契約期間に相当する分の月極サービスを該ユーザのユーザ端末１００に提供する。具体的には、サービス提供部２１３は、実質契約期間の間、周期的に、月極サービスを提供する。一例として、サービス提供部２１３は、実質契約期間の間、各日に、契約ユーザ専用のログインボーナスおよびデイリーミッションの挑戦権をユーザ端末１００に提供する。

具体的には、販売処理部２１２が、ユーザから、契約期間の開始時点または該開始時点より前に当月度の第１支払を受け付けた場合、サービス提供部２１３は、当月の初日から末日までの期間、各日に月極サービスを提供する。図示の例では、販売処理部２１２は、２月度の「第１支払（２）」を、１月３０日に受け付けた場合、２月度の実質契約期間（２）を２月１日から２月２８日（閏年は、２月２９日）までと定める。サービス提供部２１３は、該実質契約期間の間、各日に２月度の月極サービスを提供する。

あるいは、具体的には、販売処理部２１２が、ユーザから契約期間の開始時点より後に当月度の第１支払を受け付けた場合、サービス提供部２１３は、支払日から末日までの期間、各日に月極サービスを提供する。図示の例では、販売処理部２１２は、１月度の「第１支払（１）」を、１月１１日に受け付けた場合、１月度の実質契約期間（１）を１月１１日から１月３１日までと定める。サービス提供部２１３は、該実質契約期間の間、各日に１月度の月極サービスを提供する。

別の例として、サービス提供部２１３は、月ごとに契約ユーザが貯めたスタンプカードのスタンプ数に応じて、スタンプカードのグレードを、月ごとに変更するサービスを月極サービスとして提供する。一般ユーザには、一律、シルバースタンプカードが配布される。これに対して、契約ユーザには、最初にシルバースタンプカードが配布されるが、月ごとのスタンプ数に応じて、シルバースタンプカードよりグレードが高い、ゴールドスタンプカード、または、ブラックスタンプカードへの変更のチャンスが与えられる。スタンプカードのグレードが上がると、報酬が獲得しやすくなる、獲得できる報酬のゲーム内価値が上がる、など、ユーザにとって利点がある。

契約ユーザが所有するユーザ端末１００のサービス受取部１１６は、サービス提供部２１３と協働して、契約ユーザが貯めたスタンプ数を月単位で集計し、集計したスタンプ数に応じて、契約ユーザが所有しているスタンプカードをアップグレードする。

サービス受取部１１６は、ユーザが月極サービスの対価の支払を完了させると、対応する契約期間の間、図８に示すユーザ情報１３３のユーザ区分の項目に、契約ユーザであることを示す情報を格納する。

＜データ構造＞
図１４は、実施形態２におけるパラメータ情報のデータ構造の一例を示す図である。実施形態１に係るゲームシステム１において処理されるパラメータ情報と異なる点は、パラメータ情報が、さらに、月別集計値の項目を有している点である。

月別集計値の項目には、当月度の契約期間の開始時点から終了時点までの間で、ユーザが獲得したスタンプ数が格納されている。月別集計値に基づいて、月ごとの満杯回数を求めることができるので、パラメータ情報において、満杯回数の項目は省略されてもよい。

スタンプカードに押印されているスタンプ数を示す現在値は、月をまたいで引き継がれる。つまり、月をまたいだときにリセットされるのではなく、スタンプカード満杯になり、新しいスタンプカードが発行されたときにリセットされる値である。そのため、ユーザが当月ひと月で貯めたスタンプの数（以下、当月度の獲得スタンプ数）を正確に把握するために、契約期間、例えば、ひと月ごとにスタンプ数を集計するための月別集計値の項目が別途設けられている。

カード管理部１１２は、押印部１１２２によってスタンプが１個押印される度に、現在値を１増分するとともに、月別集計値を１増分する。現在値は、スタンプカードが満杯になって満杯回数が１増分されるタイミングで、カード管理部１１２によって０にリセットされる。これに対し、月別集計値は、サービス受取部１１６が当月度の獲得スタンプ数を計上した後、次月度のカウントが始まるまでに、サービス受取部１１６によって０にリセットされる。

具体的には、サービス受取部１１６は、当月度において予め定められた締日が到来すると、当月度の獲得スタンプ数を、月別集計値の項目から取得して、サーバ２００のサービス提供部２１３に送信する。ここで、サービス受取部１１６は、次月度のスタンプ数のカウントが開始できるように、当該項目の値を０にリセットする。

サーバ２００において、当月度の獲得スタンプ数に応じて、契約ユーザが所有するスタンプカードのグレードを変更するか否かが判定され、その判定結果が、サービス提供部２１３から、サービス受取部１１６へ送信される。

サービス受取部１１６は、サービス提供部２１３からスタンプカードをアップグレードする旨の通知を受信した場合には、１段階グレードが上のスタンプカードをユーザに所有させる。具体的には、サービス受取部１１６は、当月度の現在値を維持したまま、所有フラグの項目を更新して、スタンプカードのアップグレードを実行する。例えば、図９に示すとおり、ユーザが、現在値「６」が関連付けられたスタンプカード、つまり、スタンプが６個押印されたシルバーカードを所有して、当月度を終えたとする。この場合、サービス受取部１１６は、上述の通知にしたがって、図１４に示すとおり、現在値「６」を維持したまま、パラメータ種別がシルバーのパラメータ情報の所有フラグを「０」に更新し、パラメータ種別がゴールドのパラメータ情報の所有フラグを「１」に更新する。これにより、６個のスタンプは押印された状態のまま、ユーザが所有するスタンプカードのグレードだけを、シルバーからゴールドにアップグレードすることができる。ユーザは、次月度から、６個のスタンプは押印された状態のゴールドスタンプカードを所有して、スタンプを貯めていくことができる。

なお、サービス受取部１１６は、サービス提供部２１３が有する機能、すなわち、スタンプカードのグレード変更の要否を判定する機能を有していてもよい。具体的には、アップグレードの要件となる目標値のスタンプ数が、記憶部１２０において予め記憶されており、サービス受取部１１６は、月別集計値の項目から取得した、当月度の獲得スタンプ数を、目標値のスタンプ数と比較する。サービス受取部１１６は、当月度の獲得スタンプ数が、目標値のスタンプ数に到達して、アップグレードの要件を満たしている判定した場合に、パラメータ情報の所有フラグを更新して、ユーザに所有させるスタンプカードをアップグレードしてもよい。

＜処理フロー＞
図１５は、スタンプカードのグレードを変更する処理の流れを示すフローチャートである。以下では、一例として、図１５に示す各ステップは、ユーザ端末１００が実行するものとして説明するが、すべてのステップまたは一部のステップをサーバ２００が実行してもよい。スタンプカードのアップグレードは、契約ユーザが受けられるサービスであるとし、図１５に示す各ステップは、契約ユーザのユーザ端末１００が実行するものとする。

一例として、月ごとの獲得スタンプ数の目標値として、第１目標値と第２目標値との２つが定められている。第１目標値は、スタンプカードのアップグレードの要件を示し、第２目標値は、スタンプカードのダウングレードの要件を示すものとする。第１目標値は、例えば、「５個」であり、第２目標値は、例えば、「２個」である。シルバーとゴールドとの間のグレードのアップダウン判定に用いる第１目標値および第２目標値の組み合わせと、ゴールドとブラックとの間の判定に用いる第１目標値および第２目標値の組み合わせとは、値が一致していてもよいし、異なっていてもよい。

ステップＳ２０１にて、当月度の締日が到来すると、サービス受取部１１６は、スタンプカードのグレードを変更するための以下の一連の処理を開始する。

ステップＳ２０２では、サービス受取部１１６は、図１４に示す月別集計値の項目から、当月度の獲得スタンプ数を取得する。ここで、サービス受取部１１６は、取得した当月度の獲得スタンプ数を、記憶部１２０に退避させて、月別集計値の項目を次月度に備えて０にリセットしてもよい。

ステップＳ２０３では、サービス受取部１１６は、当月度の獲得スタンプ数が第１目標値に到達しているか否かを判定する。当月度の獲得スタンプ数が第１目標値以上であれば、サービス受取部１１６は、ステップＳ２０３のＹＥＳからステップＳ２０４に進む。当月度の獲得スタンプ数が第１目標値未満であれば、サービス受取部１１６は、ステップＳ２０３のＮＯからステップＳ２０５に進む。

ステップＳ２０４では、サービス受取部１１６は、ユーザが当月所有していたスタンプカードより１段階上のグレードのスタンプカードが存在する場合、次月度にユーザに所有させるスタンプカードのグレードを１段階上げる。例えば、当月ユーザが所有していたスタンプカードのグレードがシルバーであれば、次月にユーザに所有させるスタンプカードのグレードを１段階上のゴールドに変更する。

ステップＳ２０５では、サービス受取部１１６は、当月度の獲得スタンプ数が第２目標値に到達しているか否かを判定する。当月度の獲得スタンプ数が第２目標値以上であれば、サービス受取部１１６は、ステップＳ２０５のＹＥＳに進んで一連の処理を終了する。すなわち、当月度の獲得スタンプ数が、第２目標値以上第１目標値未満であれば、次月度も、スタンプカードは、当月度と同じグレードに維持される。当月度の獲得スタンプ数が第２目標値未満であれば、サービス受取部１１６は、ステップＳ２０５のＮＯからステップＳ２０６に進む。

ステップＳ２０６では、サービス受取部１１６は、ユーザが当月所有していたスタンプカードより１段階下のグレードのスタンプカードが存在する場合、次月度にユーザに所有させるスタンプカードのグレードを１段階下げる。例えば、当月ユーザが所有していたスタンプカードのグレードがブラックであれば、次月にユーザに所有させるスタンプカードのグレードを１段階下のゴールドに変更する。

スタンプカードのグレードが上がるほど、報酬が獲得しやすくなる、獲得できる報酬のゲーム内価値が上がる、など、ユーザにとって利点がある。上述の方法によれば、契約ユーザは、カードのグレードを上げるチャンスが与えられ、一般ユーザよりも有利に報酬を獲得することができる。これにより、契約ユーザにおける、月極サービスに対する満足度を高めることが可能となる。そして、グレードが上のスタンプカードのメリットを踏まえて、契約ユーザは、スタンプのグレードを上げたい、または、高いグレードを維持したいと望むようになる。したがって、契約ユーザに対して、スタンプを貯めるための第２行為、例えば、抽選の実施を一層動機付けることが可能となる。

＜ＵＩ例＞
図１６の（Ａ）は、図１１の（Ｂ）または図１２の（Ｂ）に示されるシルバースタンプカードの１段階上のグレードのゴールドスタンプカードの一例を示す図である。図９および図１４のパラメータ情報が示すとおり、ゴールドスタンプカードは、シルバースタンプカードと比較して、報酬の獲得要件である閾値が共通しているが、同じ要件でも、シルバースタンプカードに設定されている報酬よりも、ゴールドスタンプカードに設定されている報酬の方が、ゲーム内価値が高い。例えば、スタンプを同じく７個貯めた場合でも、シルバースタンプカードにおいて７個貯めた場合では、ユーザに付与される報酬は、スタミナ回復アイテム１個である。一方、図１６の（Ａ）に示すとおり、ゴールドスタンプカードにおいて７個貯めた場合では、スタミナ回復アイテムが２個、報酬としてユーザに付与される。このように、スタンプカードにおいて、同じ閾値に対しゲーム内価値が高い報酬を設定することで、グレードによるゲーム内価値の差別化を実現してもよい。

図１６の（Ｂ）は、図１６の（Ａ）に示されるゴールドスタンプカードの１段階上のグレードのブラックスタンプカードの一例を示す図である。図９および図１４のパラメータ情報が示すとおり、ブラックスタンプカードは、ゴールドスタンプカードと比較して、設定されている報酬のゲーム内価値は同じであるが、報酬が同じでも、ゴールドスタンプカードの閾値よりも、ブラックスタンプカードの閾値の方が、低く設定されている。すなわち、報酬獲得の要件が、ブラックスタンプカードの方が緩く設定されている。例えば、「配布ダイヤ３個」の報酬を獲得しようとすると、ゴールドスタンプカード所持時には、スタンプを１０個貯める必要がある。一方、図１６の（Ｂ）に示すとおり、ブラックスタンプカード所持時には、スタンプを９個貯めるだけで、「配布ダイヤ３個」の報酬が得られる。このように、スタンプカードにおいて、同じ報酬に対して閾値を低く設定することで、グレードによるゲーム内価値の差別化を実現してもよい。

〔変形例〕
＜押印規則＞
本変形例では、押印部１１２２は、「抽選をＮ回実施する」という１つの第２行為が行われた場合でも、第２行為が、有償アイテムの消費を伴って実施されたのか否かに応じて、押印するスタンプの数を異ならせてもよい。

また、押印部１１２２は、「有償アイテムを消費して抽選をＮ回実施する」という１つの第２行為が行われた場合でも、第２行為が、購入ダイヤの消費を伴って実施されたのか、配布ダイヤの消費を伴って実施されたのかに応じて、押印するスタンプの数を異ならせてもよい。

図１７は、押印規則のデータ構造の一例を示す図である。押印規則は、例えば、記憶部１２０に記憶されており、押印部１１２２によって必要に応じて参照される。押印規則は、第２行為が実施されたときに消費されるゲーム媒体の種別ごとに、押印すべきスタンプの数を規定する情報である。

一例として、本変形例では、押印部１１２２は、図示された押印規則にしたがって、ダイヤを消費して抽選が実施された場合に、抽選チケットを消費して抽選が実施された場合よりも多くのスタンプをユーザのスタンプカードに押印する。また、押印部１１２２は、上記押印規則にしたがって、購入ダイヤを消費して抽選が実施された場合に、配布ダイヤを消費して抽選が実施された場合よりも多くのスタンプをユーザのスタンプカードに押印する。

上述の構成よれば、ユーザは、スタンプを貯めるために、ダイヤを獲得し、抽選チケットよりもダイヤを消費して抽選を実施するように促される。ユーザは、ダイヤを獲得できるようにゲーム（例えば、ストーリーパート）をプレイすることを動機付けられる。また、ユーザは、配布ダイヤよりも購入ダイヤを消費した方が多くスタンプを貯められる。そのため、ダイヤを購入したことに対するユーザの満足度を高めることが可能となる。

＜パラメータ情報のアップグレード＞
パラメータ情報のグレードに差を付ける方法として、実施形態２に示した例の他に、以下のようにパラメータ情報を処理してもよい。パラメータ情報がスタンプカードである場合を例に説明する。

例えば、サービス受取部１１６は、当月度のシルバースタンプカードを、次月度からゴールドスタンプカードにアップグレードするとき、当月度のシルバースタンプカードに関連付けられているスタンプ数よりも多い数のスタンプが押印されたゴールドスタンプカードを、次月度からユーザに所有させてもよい。このように、押印されているスタンプ数を増量することにより、スタンプカードのグレードが高められてもよい。

あるいは、例えば、サービス受取部１１６は、当月度のシルバースタンプカードを、次月度からゴールドスタンプカードにアップグレードするとき、シルバースタンプカードに押印されている第１種スタンプを、ゴールドスタンプカードにおいて個数を維持したまま第２種スタンプに変更してもよい。第２種スタンプは、第１種スタンプよりも価値が高く、より少ない個数でより価値が高い報酬と交換することが可能である。このように、スタンプ数を維持したまま、押印されているスタンプの価値を高めることにより、スタンプカードのグレードが高められてもよい。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック（特に、進行支援部２１１、販売処理部２１２、サービス提供部２１３、および、抽選実行部２１４）、ならびに、制御部１１０の制御ブロック（特に、ゲーム進行部１１１、カード管理部１１２、発行部１１２１、押印部１１２２、報酬付与部１１４、購入処理部１１５、サービス受取部１１６、および、抽選パート進行部１１７）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

後者の場合、制御部２１０または制御部１１０、もしくはその両方の機能を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。

（項目１） ゲームプログラム（１３１、２３１）について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ（１０、２０）およびメモリ（１１、２１）を備えるコンピュータ（ユーザ端末１００およびサーバ２００の少なくとも一方）により実行される。ゲームプログラムは、プロセッサに、ユーザによって、ゲームプログラムに基づくゲームにおいて利用可能な有償アイテム（ダイヤ）を購入する第１行為が実施されたことに応答して、値（スタンプ）が第１値よりも大きい第２値に設定されたパラメータ情報（スタンプカード）をユーザに付与するステップ（Ｓ１０７）と、ユーザによって、ゲーム上で第１行為とは異なる第２行為が実施されたことに応答して、パラメータ情報に設定されている値を更新するステップ（Ｓ１０５）と、値が、該パラメータ情報に設定されている第１の閾値に到達した場合に、該パラメータ情報に設定されている、ゲームで利用可能な第１の報酬をユーザに付与するステップ（Ｓ１１０）と、を実行させる。

上述の構成によれば、ユーザが第１行為を実施すると、パラメータ情報が付与される。このとき付与されるパラメータ情報は、値が第１値よりも大きい第２値に設定されているという付加価値を有したパラメータ情報である。付加価値は、いわば、第１行為の特典である。付加価値により、パラメータ情報が付与された時点で、すでに、第２値が貯まっており、“第１の報酬を獲得する”というゴールが、付加価値がないパラメータ情報と比較して近くなっている。ユーザは、このアドバンテージを享受して、ゴールを目指すことができる。そのため、ゴールを目指そうというユーザの意欲を高めることができる。結果として、ゴールのために必要な第２行為の実施をユーザに強く動機付けることができるという効果を奏する。

（項目２） （項目１）において、パラメータ情報を付与するステップでは、パラメータ情報を付与されていないユーザによって第２行為が実施されたことに応答して、値がゼロよりも大きい第１値に設定されたパラメータ情報をユーザに付与し（Ｓ１０４）、パラメータ情報を付与されていないユーザによって第１行為が実施されたことに応答して、値が第１値よりも大きい第２値に設定されたパラメータ情報をユーザに付与（Ｓ１０７）してもよい。

（項目３） （項目１）または（項目２）において、ゲームプログラムは、プロセッサに、さらに、契約の開始時点と終了時点とが固定されている契約期間内において提供するサービスについて、該サービスの対価の支払処理を実行するステップと、契約期間内において終了時点が到来するまで、サービスをユーザに享受させるステップと、第１の契約期間において、サービスを利用しているユーザに付与された第１のパラメータ情報の値が、第１目標値に到達した場合に、第１の契約期間の後に到来する第２の契約期間において、ユーザが所有していた第１のパラメータ情報（シルバースタンプカード／ゴールドスタンプカード）を、該第１のパラメータ情報よりも、設定されている値、報酬および閾値の少なくともいずれか１つがより有利に設定されている第２のパラメータ情報（ゴールドスタンプカード／ブラックスタンプカード）に変更するステップ（Ｓ２０４）と、を実行させてもよい。

（項目４） （項目３）において、変更するステップでは、第１のパラメータ情報に設定されている値よりも大きい値が設定されている第２のパラメータ情報に変更する、または、値を維持したまま、該値が有する価値が高められた第２のパラメータ情報に変更してもよい。

（項目５） （項目３）において、変更するステップでは、第１のパラメータ情報に設定されている値を維持したまま、該第１のパラメータ情報よりも報酬および閾値の少なくともいずれか一方が有利に設定されている第２のパラメータ情報に変更してもよい。

（項目６） （項目５）において、第２のパラメータ情報には、第１のパラメータ情報に設定されている第１の閾値と同じ大きさの第３の閾値と、値が該第３の閾値に到達することで付与される報酬として、第１のパラメータ情報に設定されている第１の報酬よりも価値が高い第２の報酬とが設定されている、または、第１のパラメータ情報に設定されている第１の報酬と同じ価値の第３の報酬と、該第３の報酬が付与される条件として、第１のパラメータ情報に設定されている第１の閾値よりも小さい第４の閾値とが設定されていることが好ましい。

（項目７） （項目３）から（項目６）までのいずれか１項目において、変更するステップでは、第１の契約期間において、サービスを利用しているユーザに付与された第１のパラメータ情報の値が、第２目標値に到達しなかった場合に、第１の契約期間の後に到来する第２の契約期間において、ユーザが所有していた第１のパラメータ情報（ゴールドスタンプカード／ブラックスタンプカード）を、該第１のパラメータ情報よりも、設定されている値、報酬および閾値の少なくともいずれか１つがより不利に設定されている第３のパラメータ情報（シルバースタンプカード／ゴールドスタンプカード）に変更（Ｓ２０６）してもよい。

（項目８） （項目１）から（項目７）までのいずれか１項目において、パラメータ情報を付与されたユーザによって第１行為が実施されたことに応答して、パラメータ情報を付与するステップでパラメータ情報を付与せずに、更新するステップにて、ユーザが所有するパラメータ情報の値を、第１値よりも大きい第２値分更新（Ｓ１０８）してもよい。

ユーザにすでにパラメータ情報が付与されていて、第１行為が実施された場合に、付加価値（第２値）がついたパラメータ情報が付与されないとなると、ユーザは、パラメータ情報を所有しているときに第１行為を実施すると損をした気分になる。そのため、パラメータ情報を所有しているときには第１行為の実施をためらうことが起こり得る。そこで、パラメータ情報がすでに付与されていて、第１行為が実施された場合には、すでに所有しているパラメータ情報において、第２値分の更新を行う。これにより、ユーザが第１行為の実施をためらうことを回避することができる。

（項目９） （項目１）から（項目８）までのいずれか１項目において、パラメータ情報を付与するステップでは、第１行為として、第２行為を実施する際に消費される有償アイテムがユーザによって購入されたことに応答して、パラメータ情報を該ユーザに付与してもよい。

有償アイテムを購入するという第１行為の特典として、第２値分の付加価値がついたパラメータ情報がユーザに付与される。有償アイテムは、第２行為を実施する際に必要となるアイテムであり、パラメータ情報は、第２行為の実施よって値を増やしていくことで報酬が獲得できるものである。ユーザは、有償アイテムの購入特典として第２値分の付加価値がついたパラメータ情報を獲得して、第２行為の実施を一層動機付けられる。そして、ユーザが第２行為を実施して有償アイテムが消費されると、また、第１行為の実施が動機付けられる、というように、ユーザに継続してゲームプレイを促す好循環サイクルを生むことができる。

（項目１０） （項目１）から（項目９）までのいずれか１項目において、ゲームプログラムは、プロセッサに、有償アイテム（ダイヤ）またはユーザに無償で提供される消費アイテム（抽選チケット）を消費することにより、ゲームにおいて利用可能なゲーム媒体の母集団の中から規則に基づいて選択されたゲーム媒体を、ユーザに付与するステップ（Ｓ１０２）を実行させ、更新するステップでは、第２行為として、ユーザが、選択されたゲーム媒体を付与するステップの実行を指示したことに応答して、パラメータ情報に設定されている値を更新し（Ｓ１０５）、更新するステップでは、消費アイテムと引き換えに選択されたゲーム媒体を付与するステップの実行が指示された場合に、値を、第３値分更新し、有償アイテムと引き換えに選択されたゲーム媒体を付与するステップの実行が指示された場合に、値を、第３値よりも大きい第４値分更新してもよい。

（項目１１） （項目１０）において、ゲームプログラムは、プロセッサに、ゲームの進行状況が予め定められた条件を満たした場合に、ユーザが有償アイテムを購入するための支払いを実施せずとも、該有償アイテムをユーザに配布するステップと、支払いを経てユーザに付与された第１の有償アイテム（購入ダイヤ）と、支払いを経ずにユーザに配布された第２の有償アイテム（配布ダイヤ）とを識別するステップと、を実行させ、更新するステップでは、第２の有償アイテムと引き換えに選択されたゲーム媒体を付与するステップの実行が指示された場合に、値を、第５値分更新し、第１の有償アイテムと引き換えに選択されたゲーム媒体を付与するステップの実行が指示された場合に、値を、第５値よりも大きい第６値分更新してもよい。

（項目１２） （項目１１）において、パラメータ情報を付与するステップでは、第２の有償アイテムがユーザに付与された場合に、パラメータ情報を該ユーザに付与しない。

上述の構成によれば、ユーザが購入手続きを経て有償アイテムを獲得したときには、付加価値である第２値が設定されたパラメータ情報が付与されるが、ユーザが、ゲームのプレイ報酬などで配布された有償アイテムを獲得しても、付加価値どころか、そもそもパラメータ情報は付与されない。ユーザは、魅力的な特典である、付加価値がついたパラメータ情報を得るために、購入手続きを経て有償アイテムを獲得することを動機付けられる。

（項目１３） ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。該方法は、プロセッサが（項目１）に記載の各ステップを実行する方法である。（項目１３）に係る方法は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

（項目１４） 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、（項目１）に係るゲームプログラムを記憶するメモリ（メモリ１１、記憶部１２０）と、該ゲームプログラムを実行することにより、情報処理装置（ユーザ端末１００）の動作を制御するプロセッサ（プロセッサ１０、制御部１１０）とを備える。（項目１４）に係る情報処理装置は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

１ ゲームシステム、２ ネットワーク、１０，２０ プロセッサ、１１，２１ メモリ、１２，２２ ストレージ、１３，２３ 通信ＩＦ（操作部）、１４，２４ 入出力ＩＦ（操作部）、１５ タッチスクリーン（表示部、操作部）、１７ カメラ（操作部）、１８ 測距センサ（操作部）、１００ ユーザ端末（情報処理装置）、１１０，２１０ 制御部、１１１ ゲーム進行部、１１２ カード管理部、１１４ 報酬付与部、１１５ 購入処理部、１１６ サービス受取部、１１７ 抽選パート進行部、１２０，２２０ 記憶部、１３１，２３１ ゲームプログラム、１３２ ゲーム情報、１３３ ユーザ情報、１５１ 入力部（操作部）、１５２ 表示部、２００ サーバ、２１１ 進行支援部、２１２ 販売処理部、２１３ サービス提供部、２１４ 抽選実行部、１０１０ 物体、１０２０ コントローラ（操作部）、１０３０ 記憶媒体、１１２１ 発行部、１１２２ 押印部

Claims (14)

1. ゲームプログラムであって、
   前記ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行されるものであり、
   前記ゲームプログラムは、前記プロセッサに、
   ユーザによって、前記ゲームプログラムに基づくゲームにおいて利用可能な有償アイテムを購入する第１行為が実施されたことに応答して、値が第１値よりも大きい第２値に設定されたパラメータ情報を前記ユーザに付与するステップと、
   前記ユーザによって、前記ゲーム上で前記第１行為とは異なる第２行為が実施されたことに応答して、前記パラメータ情報に設定されている値を更新するステップと、
   前記値が、該パラメータ情報に設定されている第１の閾値に到達した場合に、該パラメータ情報に設定されている、前記ゲームで利用可能な第１の報酬を前記ユーザに付与するステップと、を実行させ、
   前記パラメータ情報を提示した場合において、前記値が、該パラメータ情報に設定されている前記第１の閾値に到達していない際に、前記パラメータ情報と共に前記第２行為を促すボタンを提示し、
   前記第１行為は、前記第２行為の実施を可能とするための行為である、ゲームプログラム。
2. 前記パラメータ情報を付与するステップでは、
   前記パラメータ情報を付与されていないユーザによって前記第２行為が実施されたことに応答して、値がゼロよりも大きい前記第１値に設定された前記パラメータ情報を前記ユーザに付与し、
   前記パラメータ情報を付与されていないユーザによって前記第１行為が実施されたことに応答して、値が前記第１値よりも大きい前記第２値に設定された前記パラメータ情報を前記ユーザに付与する、請求項１に記載のゲームプログラム。
3. 前記ゲームプログラムは、前記プロセッサに、さらに、
   契約の開始時点と終了時点とが固定されている契約期間内において提供するサービスについて、該サービスの対価の支払処理を実行するステップと、
   前記契約期間内において前記終了時点が到来するまで、前記サービスを前記ユーザに享受させるステップと、
   第１の前記契約期間において、前記サービスを利用しているユーザに付与された第１のパラメータ情報の値が、第１目標値に到達した場合に、第１の前記契約期間の後に到来する第２の前記契約期間において、前記ユーザが所有していた前記第１のパラメータ情報を、該第１のパラメータ情報よりも、設定されている前記値、前記報酬および前記閾値の少なくともいずれか１つがより有利に設定されている第２のパラメータ情報に変更するステップと、を実行させる、請求項１または２に記載のゲームプログラム。
4. 前記変更するステップでは、
   前記第１のパラメータ情報に設定されている前記値よりも大きい値が設定されている前記第２のパラメータ情報に変更する、または、
   前記値を維持したまま、該値が有する価値が高められた前記第２のパラメータ情報に変更する、請求項３に記載のゲームプログラム。
5. 前記変更するステップでは、前記第１のパラメータ情報に設定されている前記値を維持したまま、該第１のパラメータ情報よりも前記報酬および前記閾値の少なくともいずれか一方が有利に設定されている前記第２のパラメータ情報に変更する、請求項３に記載のゲームプログラム。
6. 前記第２のパラメータ情報には、
   前記第１のパラメータ情報に設定されている前記第１の閾値と同じ大きさの第３の閾値と、前記値が該第３の閾値に到達することで付与される報酬として、前記第１のパラメータ情報に設定されている前記第１の報酬よりも価値が高い第２の報酬とが設定されている、または、
   前記第１のパラメータ情報に設定されている前記第１の報酬と同じ価値の第３の報酬と、該第３の報酬が付与される条件として、前記第１のパラメータ情報に設定されている前記第１の閾値よりも小さい第４の閾値とが設定されている、請求項５に記載のゲームプログラム。
7. 前記変更するステップでは、第１の前記契約期間において、前記サービスを利用しているユーザに付与された前記第１のパラメータ情報の値が、第２目標値に到達しなかった場合に、第１の前記契約期間の後に到来する第２の前記契約期間において、前記ユーザが所有していた前記第１のパラメータ情報を、該第１のパラメータ情報よりも、設定されている前記値、前記報酬および前記閾値の少なくともいずれか１つがより不利に設定されている第３のパラメータ情報に変更する、請求項３から６のいずれか１項に記載のゲームプログラム。
8. 前記パラメータ情報が付与されたユーザによって前記第１行為が実施されたことに応答して、前記パラメータ情報を付与するステップで前記パラメータ情報を付与せずに、
   前記更新するステップにて、前記ユーザが所有する前記パラメータ情報の値を、前記第１値よりも大きい前記第２値分更新する、請求項１から７のいずれか１項に記載のゲームプログラム。
9. 前記パラメータ情報を付与するステップでは、前記第１行為として、前記第２行為を実施する際に消費される有償アイテムが前記ユーザによって購入されたことに応答して、前記パラメータ情報を該ユーザに付与する、請求項１から８のいずれか１項に記載のゲームプログラム。
10. ゲームプログラムであって、
    前記ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行されるものであり、
    前記ゲームプログラムは、前記プロセッサに、
    ユーザによって、前記ゲームプログラムに基づくゲームにおいて利用可能な有償アイテムを購入する第１行為が実施されたことに応答して、値が第１値よりも大きい第２値に設定されたパラメータ情報を前記ユーザに付与するステップと、
    前記ユーザによって、前記ゲーム上で前記第１行為とは異なる第２行為が実施されたことに応答して、前記パラメータ情報に設定されている値を更新するステップと、
    前記値が、該パラメータ情報に設定されている第１の閾値に到達した場合に、該パラメータ情報に設定されている、前記ゲームで利用可能な第１の報酬を前記ユーザに付与するステップと、
    前記有償アイテムまたは前記ユーザに無償で提供される消費アイテムを消費することにより、前記ゲームにおいて利用可能なゲーム媒体の母集団の中から規則に基づいて選択されたゲーム媒体を、前記ユーザに付与するステップと、を実行させ、
    前記更新するステップでは、前記第２行為として、前記ユーザが、前記選択されたゲーム媒体を付与するステップの実行を指示したことに応答して、前記パラメータ情報に設定されている値を更新し、
    前記更新するステップでは、
    前記消費アイテムと引き換えに前記選択されたゲーム媒体を付与するステップの実行が指示された場合に、前記値を、第３値分更新し、
    前記有償アイテムと引き換えに前記選択されたゲーム媒体を付与するステップの実行が指示された場合に、前記値を、前記第３値よりも大きい第４値分更新し、
    前記第１行為は、前記有償アイテムの購入によって、前記第２行為の実施を可能とするための行為である、ゲームプログラム。
11. ゲームプログラムであって、
    前記ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行されるものであり、
    前記ゲームプログラムは、前記プロセッサに、
    ユーザによって、前記ゲームプログラムに基づくゲームにおいて利用可能な有償アイテムを購入する第１行為が実施されたことに応答して、値が第１値よりも大きい第２値に設定されたパラメータ情報を前記ユーザに付与するステップと、
    前記ユーザによって、前記ゲーム上で前記第１行為とは異なる第２行為が実施されたことに応答して、前記パラメータ情報に設定されている値を更新するステップと、
    前記値が、該パラメータ情報に設定されている第１の閾値に到達した場合に、該パラメータ情報に設定されている、前記ゲームで利用可能な第１の報酬を前記ユーザに付与するステップと、
    前記有償アイテムまたは前記ユーザに無償で提供される消費アイテムを消費することにより、前記ゲームにおいて利用可能なゲーム媒体の母集団の中から規則に基づいて選択されたゲーム媒体を、前記ユーザに付与するステップと、を実行させ、
    前記更新するステップでは、前記第２行為として、前記ユーザが、前記選択されたゲーム媒体を付与するステップの実行を指示したことに応答して、前記パラメータ情報に設定されている値を更新し、
    前記更新するステップでは、
    前記消費アイテムと引き換えに前記選択されたゲーム媒体を付与するステップの実行が指示された場合に、前記値を、第３値分更新し、
    前記有償アイテムと引き換えに前記選択されたゲーム媒体を付与するステップの実行が指示された場合に、前記値を、前記第３値よりも大きい第４値分更新し、
    前記ゲームプログラムは、前記プロセッサに、
    前記ゲームの進行状況が予め定められた条件を満たした場合に、前記ユーザが前記有償アイテムを購入するための支払いを実施せずとも、該有償アイテムを前記ユーザに配布するステップと、
    前記支払いを経て前記ユーザに付与された第１の有償アイテムと、前記支払いを経ずに前記ユーザに配布された第２の有償アイテムとを識別するステップと、を実行させ、
    前記更新するステップでは、
    前記第２の有償アイテムと引き換えに前記選択されたゲーム媒体を付与するステップの実行が指示された場合に、前記値を、第５値分更新し、
    前記第１の有償アイテムと引き換えに前記選択されたゲーム媒体を付与するステップの実行が指示された場合に、前記値を、前記第５値よりも大きい第６値分更新する、ゲームプログラム。
12. 前記パラメータ情報を付与するステップでは、前記第２の有償アイテムが前記ユーザに付与された場合に、前記パラメータ情報を該ユーザに付与しない、請求項１１に記載のゲームプログラム。
13. コンピュータがゲームプログラムを実行する方法であって、
    前記コンピュータは、プロセッサおよびメモリを備え、
    前記プロセッサが請求項１、１０、および１１の何れか１項に記載の各ステップを実行する方法。
14. 情報処理装置であって、
    前記情報処理装置は、
    請求項１、１０、および１１の何れか１項に記載のゲームプログラムを記憶するメモリと、
    該ゲームプログラムを実行することにより、情報処理装置の動作を制御するプロセッサとを備えている、情報処理装置。

Images