技術 ゲームシステム、サーバ、情報処理プログラム、および、情報処理方法

0001

本発明は、端末装置においてゲームアプリケーションを実行するためのゲームシステム、サーバ、情報処理プログラム、および、情報処理方法に関する。

0002

従来、コンテンツをサーバから端末装置へダウンロードして端末装置において利用するシステムがある。

0003

特表２００６−００６２４１号公報

0004

従来、複数のコンテンツが端末装置によって取得される場合、例えばこれら複数のコンテンツを一括して取得する方法のみがユーザに提供されることがあり、コンテンツを取得する選択肢が限定的であることがあった。そのため、これら複数のコンテンツをユーザにとって取得しやすくすることが好ましい。

0005

それ故、本発明の目的は、端末において複数のコンテンツを取得する際の利便性を向上することができるゲームシステム、サーバ、情報処理プログラム、および、情報処理方法を提供することである。

0006

上記の課題を解決すべく、本発明は、以下の（１）〜（１８）の構成を採用した。

0007

（１）
本発明の一例は、複数のコンテンツを含むゲームアプリケーションを実行するためのゲームシステムである。ゲームシステムは、記憶手段と、受付手段と、コンテンツ処理手段と、更新手段と、ゲーム処理手段とを備える。記憶手段は、コンテンツがゲーム処理において使用可能か否かを示す使用可否情報を複数のコンテンツのそれぞれに関連付けて記憶する。受付手段は、複数のコンテンツに含まれる一部のコンテンツを使用可能とするための第１処理、または、複数のコンテンツに含まれる各コンテンツを使用可能とするための第２処理を実行させるためのユーザの選択操作を受け付ける。コンテンツ処理手段は、ユーザの選択操作に基づいて第１処理または第２処理を実行する。更新手段は、第１処理の実行に応じて、一部の使用不可能なコンテンツに関連付けられた使用可否情報を、使用可能であることを示す情報に更新し、第２処理の実行に応じて、使用不可能な各コンテンツに関連付けられた使用可否情報を、使用可能であることを示す情報に更新する。ゲーム処理手段は、更新手段によって使用可否情報が使用可能であることを示す情報に更新されたコンテンツを用いてゲーム処理を実行する。

0008

（２）
更新手段は、第１処理の実行に応じて使用可否情報を更新した後で第２処理の実行に応じて使用可否情報を更新する場合、複数のコンテンツのうちで、当該第１処理に応じて使用可否情報が更新されたコンテンツを除くコンテンツに関連付けられた使用可否情報を更新してもよい。

0009

（３）
更新手段は、第２処理の実行に応じて、複数のコンテンツのうちで使用不可能な全てのコンテンツに関連付けられた使用可否情報を、使用可能であることを示す情報に更新してもよい。

0010

（４）
受付手段は、第１処理を表す第１画像と共に、第２処理を表す第２画像を提示してもよい。コンテンツ処理手段は、第１画像を選択する操作に応じて第１処理を実行し、第２画像を選択する操作に応じて第２処理を実行してもよい。

0011

（５）
受付手段は、第１処理が実行されたことに応じて複数のコンテンツのうちの所定の一部のコンテンツが使用可能となった場合、第１処理を実行するための操作を受け付けない状態で、第２処理を実行するための操作を受け付けてもよい。

0012

（６）
記憶手段は、複数のコンテンツについて設定される順序を示す情報を記憶してもよい。更新手段は、１回の第１処理の実行に応じて、複数のコンテンツのうちで使用不可能なコンテンツであって、順序に従って特定される１つのコンテンツに関連付けられる使用可否情報を、使用可能であることを示す情報に更新してもよい。受付手段は、複数のコンテンツのうちで、順序に従って所定の一部のコンテンツが使用可能となった後は、第１処理を実行するための操作を受け付けない状態で、第２処理を実行するための操作を受け付けてもよい。

0013

（７）
ゲーム処理手段は、所定の一部のコンテンツに関連付けられる使用可否情報が使用不可能であることを示す場合、当該コンテンツを、制限が加えられた状態で用いてゲーム処理を実行してもよい。

0014

（８）
受付手段は、複数のコンテンツが使用不可能である初期状態において選択操作を受け付けるとともに、第１処理の実行によって複数のコンテンツの一部が使用可能となった一部使用可能状態において選択操作を受け付けてもよい。

0015

（９）
受付手段は、初期状態において、第１処理を表す第１画像と共に、第２処理を表す第２画像を提示し、一部使用可能状態において第１画像と共に第２画像を提示してもよい。コンテンツ処理手段は、第１画像を選択する操作に応じて第１処理を実行し、第２画像を選択する操作に応じて第２処理を実行してもよい。

0016

（１０）
コンテンツ処理手段は、第１処理および第２処理として、コンテンツを使用可能とすることに対する対価を取得する取得処理を実行してもよい。

0017

（１１）
複数のコンテンツが使用不可能である初期状態において実行される第２処理において取得する対価を第１の対価とし、初期状態から実行される所定回数の第１処理において取得する対価の合計を第２の対価とし、当該所定回数の第１処理の実行によって複数のコンテンツの一部が使用可能となった一部使用可能状態において実行される第２処理において取得する対価を第３の対価としたとき、コンテンツ処理手段は、第１の対価を、第２の対価と第３の対価との和よりも小さくしてもよい。

0018

（１２）
複数のコンテンツが使用不可能である初期状態から第１の回数だけ第１処理が実行されたことによって生じた一部使用可能状態において実行される第２処理において取得する対価を第４の対価とし、初期状態から第１の回数よりも多い第２の回数だけ第１処理が実行されたことによってて複数のコンテンツの一部が使用可能となった一部使用可能状態において実行される第２処理において取得する対価を第５の対価としたとき、コンテンツ処理手段は、第５の対価を、第４の対価よりも小さくしてもよい。

0019

（１３）
コンテンツ処理手段は、取得処理として、ゲームアプリケーション内においてユーザが所有するポイントを減少させる処理、または、使用可能とされるコンテンツに応じた料金を課金する処理を実行してもよい。

0020

（１４）
記憶手段は、複数のコンテンツについて設定される順序を示す情報を記憶してもよい。更新手段は、複数のコンテンツのうちで使用不可能なコンテンツに関連付けられる使用可否情報を、第１処理が実行される毎に順序に従って１つずつ、使用可能であることを示す情報に更新してもよい。

0021

（１５）
受付手段は、第１処理を選択する選択操作が行われる場合、複数のコンテンツのうちで使用可能とするコンテンツを指定するためのユーザの指定操作を受け付けてもよい。更新手段は、第１処理の実行に応じて、指定操作によって指定されたコンテンツに関連付けられる使用可否情報を、使用可能であることを示す情報に更新してもよい。

0022

（１６）
ゲーム処理手段は、所定のコンテンツについて、当該所定のコンテンツに関連付けられる使用可否情報が使用不可能であることを示す場合、当該所定のコンテンツを、制限が加えられた状態で用いてゲーム処理を実行してもよい。

0023

（１７）
ゲームシステムは、ユーザによって操作される端末装置と、サーバとを含んでもよい。ゲームシステムは、サーバに設けられ、第１処理または第２処理によって使用可否情報が更新されたことを条件として、当該条件を満たしたコンテンツを端末装置において使用可能とするためのデータを当該端末装置へ送信するデータ送信手段をさらに備えてもよい。ゲーム処理手段は、端末装置に設けられ、サーバから受信されたデータに基づいてゲーム処理を実行してもよい。

0024

（１８）
コンテンツは、ゲームにおけるステージのデータであってもよい。ゲーム処理手段は、更新手段によって使用可否情報が使用可能であることを示す情報に更新されたステージのデータを用いたゲーム処理を実行してもよい。

0025

なお、本発明の別の一例は、上記（１）〜（１８）におけるゲームシステムに含まれるサーバまたは端末装置であってもよいし、当該サーバまたは端末装置の各手段として情報処理装置のコンピュータを機能させる情報処理プログラムであってもよい。また、本発明の別の一例は、上記（１）〜（１８）におけるゲームシステムにおいて実行される情報処理方法であってもよい。

0026

本発明によれば、端末において複数のコンテンツを取得する際の利便性を向上することができる

0027

本実施形態における情報処理システムの構成の一例を示すブロック図
サーバの構成の一例を示すブロック図
端末装置の構成の一例を示すブロック図
使用可能なコンテンツに関する端末装置の状態遷移の一例を示す図
ステージモードにおいてコンテンツの購入に関して実行される処理の流れの一例を示す図
ステージモード画像の一例を示す図
購入画像の一例を示す図
バトルモードにおいてコンテンツの購入に関して実行される処理の流れの一例を示す図
バトルモード画像の一例を示す図
端末装置の各状態における課金額の一例を示す図
図１０に示す課金額の一例において、一括購入を行ったタイミングと、そのときの支払総額との関係を示す図
サーバにおいて実行される処理に用いられる各種情報の一例を示す図
端末装置において実行される処理に用いられる各種情報の一例を示す図
端末装置における処理の流れの一例を示すフローチャート
図１４に示すステップＳ２５の購入処理の詳細な流れの一例を示すサブフローチャート
サーバにおける処理の流れの一例を示すフローチャート

0028

［１．システムの全体構成］
以下、本実施形態に係る情報処理システム、サーバ、情報処理装置、情報処理プログラム、および、情報処理方法について説明する。まず、本実施形態に係る情報処理システムの全体構成と、情報処理システムに含まれる端末装置およびサーバの構成とについて説明する。図１は、本実施形態における情報処理システムの構成の一例を示すブロック図である。図１に示すように、情報処理システムは、サーバ１と、端末装置２とを含む。これらのサーバ１または端末装置２は、インターネットおよび／またはモバイル通信網等のネットワーク３に接続可能である。サーバ１および端末装置２は、ネットワーク３を介して互いに通信可能である。

0029

サーバ１は、端末装置２において実行されるアプリケーションに関するサービスを提供するためのサーバである。本実施形態において、サーバ１は、端末装置２においてゲームアプリケーションを実行するためのゲームサーバとしての機能を有する。サーバ１は、端末装置２においてゲームアプリケーションのゲームを実行するための環境を提供する。例えば、サーバ１は、ゲームアプリケーションを実行する端末装置２からの要求に応じて、必要に応じてゲーム処理を実行し、要求に応じたゲームデータを当該端末装置２へ送信する（図１参照）。

0030

端末装置２は、ユーザが有する情報処理装置の一例であり、例えば、スマートフォン、携帯型または据置型のゲーム装置、携帯電話、タブレット端末、あるいは、ウェアラブル端末等である。端末装置２は、サーバ１がサービスを提供するゲームアプリケーションを実行することが可能である。なお、図１においては、端末装置２を１つのみ示しているが、情報処理システムには、複数の端末装置が含まれていてもよい。

0031

（サーバ１の構成の具体例）
図２は、サーバ１の構成の一例を示すブロック図である。図２に示す、サーバ１が備える各構成は、１以上の情報処理装置によって実現される。ここで、本明細書では、「サーバ」とは、１つの情報処理装置（すなわち、サーバ装置）を指す他、そのサーバの機能が複数のサーバ装置によって実現される場合にはサーバ装置群（すなわち、サーバシステム）全体を指す意味である。つまり、「サーバ」とは、サーバ装置であってもよいし、サーバシステムであってもよい。なお、本実施形態におけるサーバ１のハードウェア構成は、従来のサーバのためのハードウェア構成と同様であってもよい。

0032

図２に示すように、サーバ１は、処理部１１および記憶部１２を備える。処理部１１は、サーバ１の各部１２〜１５に電気的に接続される。処理部１１は、プロセッサの一例であるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、メモリとを有する。サーバ１においては、ＣＰＵがメモリを用いて、記憶部１２に記憶されたプログラムを実行することによって各種の情報処理（例えば、図１６に示す処理）が実行される。記憶部１２は、処理部１１がアクセス可能な任意の記憶装置（記憶媒体とも言う）である。記憶部１２は、処理部１１において実行されるプログラム、処理部１１による情報処理に用いられるデータ、および、当該情報処理によって得られたデータ等を記憶する。本実施形態においては、記憶部１２は、端末装置２において実行されるゲーム処理のためにサーバ側で実行されるゲーム処理のためのプログラム（「サーバ側ゲームプログラム」と呼ぶ）を少なくとも記憶する。

0033

サーバ１は、通信部１３を備える。通信部１３は、ネットワーク３に接続し、ネットワーク３を介して他の装置（例えば、端末装置２）と通信を行う機能を有する。また、サーバ１は、入出力インターフェースとして、入力部１４および表示部１５を備える。例えば、サーバ管理者は、サーバ１によってサービスが提供されるゲーム（すなわち、上記サーバ側ゲームプログラム、および／または、端末装置２において実行されるゲームアプリケーション）に更新がある場合、入出力インターフェースを用いて当該更新のための作業を行う。

0034

（端末装置２の構成の具体例）
図３は、端末装置２の構成の一例を示すブロック図である。図３に示すように、端末装置２は、処理部２１および記憶部２２を備える。処理部２１は、端末装置２の各部２２〜２５に電気的に接続される。処理部２１は、プロセッサの一例であるＣＰＵと、メモリとを有する。端末装置２においては、ＣＰＵがメモリを用いて、記憶部２２に記憶されたプログラム（上述のゲームアプリケーションを含む）を実行することによって各種の情報処理が実行される。記憶部２２は、処理部２１において実行されるプログラム、処理部２１による情報処理に用いられるデータ、および、当該情報処理によって得られたデータ等を記憶する。

0035

端末装置２は、入力部２３を備える。入力部２３は、ユーザによる入力を受け付ける任意の入力装置であってよい。本実施形態において、入力部２３は、後述する表示部２４の画面に設けられるタッチパネルを備える。なお、入力部２３は、タッチパネルに加えて（または代えて）、ボタン、および／または、慣性センサ（例えば、加速度センサやジャイロセンサ）等を含んでいてもよい。

0036

端末装置２は、表示部２４を備える。表示部２４は、端末装置２の処理部２１において実行される情報処理によって生成された画像（例えば、ゲーム画像等）を表示する。なお、端末装置２は、スピーカ、マイク、および／または、カメラ等を備えていてもよい。

0037

端末装置２は、通信部２５を備える。本実施形態において、通信部２５は、モバイル通信網（換言すれば、携帯電話通信網）に接続して通信を行う機能を有する。すなわち、端末装置２（具体的には、処理部２１）は、通信部２５を用いて（換言すれば、通信部２５を介して）モバイル通信網を介してネットワーク３に接続し、他の装置（例えば、サーバ１等）と通信を行う。なお、端末装置２がネットワーク３を介した通信を行うための通信部の構成は任意である。通信部２５は、例えばＷｉ−Ｆｉの認証を受けた通信モジュールによって、無線ＬＡＮに接続する機能を有していてもよい。また、通信部２５は、モバイル通信網に接続する機能と、無線ＬＡＮに接続する機能との両方を有していてもよい。

0038

なお、端末装置２は、図３に示す構成に加えて、他の構成を備えていてもよい。例えば、端末装置２は、ＮＦＣによる通信を行う機能、および／または、端末装置２の位置を検出する機能（例えば、ＧＰＳ機能）等を有していてもよい。

0039

［２．情報処理システムにおける処理の概要］
次に、図４〜図１１を参照して、情報処理システムにおいて実行される処理の概要について説明する。本実施形態においては、端末装置２において実行されるゲームアプリケーションが、ゲーム内において、互いに異なる複数のコンテンツを含む場合を例として説明を行う。より具体的には、ゲームアプリケーションが、互いに異なる複数のステージを含む場合を例として説明を行う。

0040

（２−１：コンテンツの購入）
まず、ゲームアプリケーションに含まれるコンテンツの購入方法について説明する。本実施形態においては、ゲームアプリケーションのサービスは、いわゆるフリー・トゥ・プレイ、あるいは、フリーミアムとも呼ばれる、ダウンロード無料型の料金体系によって供される。すなわち、ユーザは、ゲームアプリケーションを端末装置２に無料でダウンロードすることができ、その後、ゲーム内においてコンテンツを購入することができる。ここで、本実施形態においては、購入対象であるコンテンツは、ゲーム内におけるステージである。つまり、ユーザは、ゲームアプリケーションを無料の範囲内でプレイすることができるとともに、（有料コンテンツである）ステージを購入することによって、購入したステージについてゲームをプレイすることができる。

0041

なお、「ステージ」とは、ゲームプレイの単位となるものであり、「エリア」、「面」、あるいは「ワールド」と言うこともある。また、ゲームが複数のシナリオを含む場合、当該シナリオがステージであると言うこともできる。ステージは、典型的には、ユーザがゲームをプレイするために用いられる仮想ゲーム空間である。例えば、ユーザがプレイヤキャラクタを操作する種類のゲーム（例えば、アクションゲーム等）においては、プレイヤキャラクタが登場するゲーム空間（マップとも言う）が、ステージであると言うことができる。また、パズルゲームにおいては、パズル要素が配置されるゲーム空間が、ステージであると言うことができる。

0042

なお、本実施形態においては、ゲームアプリケーションには６つのステージが含まれるものとする。詳細は後述するが、ユーザは、各ステージを個別に購入することも可能であるし、全てのステージを一括して購入することも可能である。このように、本実施形態においては、個別購入と一括購入という２種類の購入方法を提供することによって、コンテンツ購入に関するユーザの利便性の向上を図ることができる。

0043

図４は、使用可能なコンテンツに関する（端末装置の）状態遷移の一例を示す図である。本実施形態においては、ゲームアプリケーションにおいて使用可能なコンテンツに関する状態として、端末装置２は、図４に示す各種の状態を取り得る。

0044

まず、ゲームアプリケーションは、例えばユーザの指示に応じて、サーバ１から端末装置２へダウンロードされて端末装置２にインストールされる。なお、上述のように、本実施形態においては、サーバ１は、アプリケーションのダウンロードに対して課金を行わない。ここで、図４に示すように、端末装置２においてゲームアプリケーションのインストールが行われ、コンテンツ（すなわち、ステージ）の購入が行われてない状態を、「初期状態」と呼ぶ。詳細は後述するが、初期状態では、ユーザは、購入が行われていないステージについて、試用プレイを行うことができる。

0045

初期状態において、ユーザは、６つの各ステージを個別に購入する個別購入と、各ステージを一括して購入する一括購入とを選択的に行うことが可能である。ここで、本実施形態では、ゲームアプリケーションに含まれる６つのステージについては、第１〜第６ステージの順に順序が定められており、ユーザは、この順序で１つずつステージを購入することができる。なお、本実施形態においては、上記順序は、ゲームの進行に沿った順序であり、以下においては上記の順序を「進行順」と呼ぶ。なお、他の実施形態においては、ステージに順序が定められていなくてもよい。また、以下においては、個別購入が行われた結果、ゲームアプリケーションにおけるコンテンツ（すなわち、ステージ）が部分的に使用可能となった状態を、「部分使用状態」と呼ぶ。具体的には、第ｎ（ｎは１〜６の整数）ステージまでのｎ個のステージが使用可能となった状態を、「第ｎ部分使用状態」と呼ぶ。

0046

初期状態において個別購入が行われると、図４に示すように、端末装置２のゲームアプリケーションは第１部分使用状態となる。すなわち、個別購入によって、６つのステージのうちの（最初のステージである）第１ステージが使用可能となる。これによって、ユーザは、第１ステージをプレイすることができる（換言すれば、第１ステージを用いたゲームプレイが可能になる）。本実施形態においては、購入によって使用可能となったステージについては、ユーザは、購入後は無制限にゲームをプレイすることができる。

0047

また、本実施形態においては、ゲームアプリケーションによって提供されるゲームは、ユーザが１人で各ステージをプレイするモード（「ステージモード」と呼ぶ）と、ユーザが他のユーザと対戦形式でゲームをプレイするモード（「バトルモード」と呼ぶ）とを含む。詳細は後述するが、ユーザは、ゲームアプリケーション内においてユーザが所有するバトルチケットと引き替えに（換言すれば、バトルチケットを消費することによって）、バトルモードでのゲームプレイ（以下、「バトルプレイ」と呼ぶ。）を行うことができる。本実施形態においては、ユーザが上記の個別購入を行った場合、所定数（例えば、２０個）のバトルチケットが当該ユーザに付与される。したがって、個別購入が行われた結果、端末装置２のゲームアプリケーションが第１部分使用状態となった場合、ユーザは、（付与されたバトルチケットに応じた回数だけ）バトルプレイが可能になる（図４参照）。

0048

一方、初期状態において一括購入が行われると、図４に示すように、端末装置２は全使用状態となる。全使用状態は、６つの各ステージが使用可能となり、かつ、バトルプレイを無制限に行うことができる状態である。このように、一括購入を行った場合、ユーザは、ゲームアプリケーション（の全体）を購入することと同等の利益を受けることができる。本実施形態においては、一括購入を行った場合、ゲームアプリケーションの利用のためにこれ以上の料金が課せられることはないので、ユーザは、安心してゲームアプリケーションを利用することができる。

0049

また、図４に示すように、本実施形態においては、部分使用状態においても、ユーザは、個別購入を行うことができる。個別購入が行われたことに応じて、端末装置２のゲームアプリケーションは、現在の部分使用状態から、次の部分使用状態（すなわち、使用可能なステージが１つ増加した部分使用状態）へと遷移する。例えば、第１部分使用状態において、個別購入が行われた場合、端末装置２のゲームアプリケーションは第２部分使用状態となる。すなわち、個別購入によって６つのステージのうちの第２ステージが使用可能となり、これによって、第２ステージが使用可能となる。また、部分使用状態において行われる個別購入によっても所定数のバトルチケットがユーザに対して付与される。したがって、各部分使用状態において、ユーザは、（付与されたバトルチケットに応じた回数だけ）バトルプレイが可能になる（図４参照）。

0050

なお、図４では詳細を示していないが、個別購入を繰り返し行うことに応じて、端末装置２のアプリケーションの状態は、第２部分使用状態から、第３部分使用状態、第４部分使用状態、および、第５部分状態を介して第６部分使用状態へと、状態が順次遷移する。これによって、使用可能なステージが１つずつ増えていく。つまり、第ｎ（ｎは１〜６の整数）部分使用状態では、第１から第ｎまでのステージが使用可能となる。なお、第６部分使用状態は、６つのステージが使用可能である一方、（全使用状態とは異なり）バトルプレイを無制限に行うことはできず、付与されたバトルチケットに応じた回数のバトルプレイが可能である。第６部分使用状態において個別購入が行われると、端末装置２は、全使用状態となり、バトルプレイを無制限に行うことが可能となる（図４参照）。

0051

また、図４に示すように、本実施形態においては、部分使用状態においても初期状態と同様に、一括購入を行うことが可能である。つまり、部分使用状態においても初期状態と同様に、ユーザは、個別購入と一括購入とを選択的に行うことができる。したがって、本実施形態においては、いずれの状態においてもユーザは一括購入によって各コンテンツを一括して使用可能とすることができるので、コンテンツ購入の利便性を向上することができる。例えば、初期状態の段階では一括購入を決めかねているユーザは、いくつかのステージを購入してゲームをプレイした後の段階でゲームアプリケーションが気に入れば、その段階で一括購入を行うことができる。

0052

また、本実施形態においては、ユーザは、購入によってステージ（より厳密には、ステージを使用する権利）およびバトルチケットを取得することができる。ここで、ステージは、購入した後は無制限に使用することができる性質を有する非消費型コンテンツであると言うことができる。一方、バトルチケットは、ゲームプレイのためにそれ自身を使用する（換言すれば消費する）性質を有する消費型コンテンツであると言うことができる。つまり、本実施形態においては、購入によって、非消費型コンテンツ（すなわち、ステージ）と、消費型コンテンツ（すなわち、バトルチケット）との組み合わせをユーザに付与する。これによれば、新たなステージの購入意欲が小さいユーザに対しても、購入意欲を継続させることができる。

0053

（一括購入のタイミングに関する変形例）
上記実施形態においては、ユーザは、各部分使用状態のいずれの状態においても個別購入指示を行うことが可能であった（図４）。ここで、他の実施形態においては、ユーザは、所定の部分使用状態においては、一括購入指示のみを行うことが可能であり、個別購入を行うことができないようにしてもよい。例えば、情報処理システムは、初期状態においては、個別購入指示と一括購入指示との両方を受け付け、部分使用状態においては、個別購入指示を受け付けずに、一括購入指示を受け付けるようにしてもよい。つまり、ユーザは、第１ステージについて個別購入が可能であり、第２〜第６ステージについては、個別購入を行うことができない。なお、このとき、端末装置２のアプリケーションは、第１部分使用状態から全使用状態にのみ遷移可能であるので、上記実施形態とは異なり、端末装置２のアプリケーションが第２〜第６部分使用状態となることはない。また、他の実施形態においては、情報処理システムは、初期状態および第ｍ部分使用状態（ｍは、ゲームアプリケーションに含まれるステージの数よりも小さい整数）において、個別購入指示と一括購入指示との両方を受け付け、第（ｍ＋１）部分使用状態においては、一括購入指示を受け付け、個別購入指示を受け付けないようにしてもよい。

0054

なお、上記のように複数のステージのうちの一部のステージについて個別購入が可能である場合、サーバ１は、個別購入が可能なステージについて試用プレイを可能とし、個別購入が不可能なステージについては試用プレイを不可能としてもよい。例えば、第１ステージについてのみ個別購入が可能である場合、第１ステージについて試用プレイが可能であり、他の第２〜第６ステージについては試用プレイが不可能であってもよい。この場合、より具体的には、第１ステージの最初のサブステージＡについて試用プレイが可能であってもよい。これによれば、試用プレイができない第２〜第６ステージをプレイしてみたいとユーザに思わせることによって、一括購入を行う動機付けをユーザに与えることができる。

0055

また、他の実施形態においては、第１ステージについてのみ個別購入が可能である場合であっても、第１〜第６ステージについて試用プレイが可能であってもよい。これによれば、一括購入のみが可能なステージについてもユーザに試用プレイを行わせることができる。

0056

（２−２：情報処理システムにおける処理の流れ）
次に、図５〜図９を参照して、情報処理システムにおいてコンテンツの購入に関して実行される処理の流れの概要について説明する。図５は、ステージモードにおいてコンテンツの購入に関して実行される処理の流れの一例を示す図である。本実施形態においては、所定の条件に応じてステージモードが開始する。所定の条件は任意であるが、例えば、メニュー画像、または、後述するバトルモード画像において、ステージモードへの切り替えがユーザによって指示されたことである。ステージモードが開始されると、端末装置２の表示部２４にステージモード画像が表示される（ステップＳ１）。

0057

図６は、ステージモード画像の一例を示す図である。本実施形態においては、ステージモード画像は、ゲームに含まれる各ステージの構成を表すステージ構成画像３１を含む。ステージ構成画像３１は、６つのステージのステージ構成（すなわち、ステージに含まれるサブステージ、ならびに、ステージおよびサブステージの順序）を表す。なお、図６に示すステージモード画像においては、ステージの番号が丸数字によって表される。

0058

ここで、本実施形態においては、６つのステージはそれぞれ、１つのステージにつき、予め順序が定められた４つのサブステージ（ここでは、サブステージＡ〜Ｄとする）を含む。ユーザは、１つのサブステージをクリアすると、次のサブステージへと進むことができる（つまり、次のサブステージをプレイすることができる。）。１つのステージにおいて、ユーザは、サブステージＡからサブステージＤまで順にサブステージをクリアしていく。サブステージＤをクリアすることによって、当該ステージをクリアしたことになる。上記のステージモードでは、ユーザは、第１ステージから第６ステージまでを上記進行順にクリアしていき、第６ステージ（具体的には、第６ステージのサブステージＤ）をクリアすることを主目的としてゲームプレイを行う。図６に示すように、ステージ構成画像３１は、ステージおよびサブステージをクリアする順序を表している。

0059

なお、他の実施形態においては、ステージおよび／またはサブステージについて、クリアすべき順序は定められていなくてもよい。このとき、プレイするステージ（またはサブステージ）をユーザが自由に選択することができるようにしてもよい。

0060

図６に示すように、ステージ構成画像３１は、サブステージを表すサブステージ画像３２を含む。なお、図６では、合計２４個のサブステージ画像が示されているが、図面を見やすくする目的で、第１ステージのサブステージＤを表すサブステージ画像にのみ参照符号を付している。サブステージ画像３２は、上述した進行順を表すように（図６では、矢印によって接続される態様で）表示される。

0061

また、図６は、第１部分使用状態（すなわち、第１ステージのみが使用可能である状態）におけるステージモード画像を示している。図６においては、使用可能である第１ステージに含まれるサブステージを表すサブステージ画像は、当該サブステージを表すマーク（すなわち、「Ａ」〜「Ｄ」）が付された態様で表示される。一方、使用不可能である第２〜第６ステージに含まれるサブステージを表すサブステージ画像は、上記マークが付されない態様（具体的には、「？」が付された態様）で表示される。これによって、ユーザは、使用可能なステージと使用不可能なステージとを容易に区別して認識することができる。このように、本実施形態においては、ステージ構成画像３１は、使用可能なステージ（およびサブステージ）か否かを区別可能な態様で各ステージを表す。なお、使用可能か否かを区別可能な態様の具体例は、どのようなものであってもよい。例えば、他の実施形態においては、使用可能なサブステージを表すサブステージ画像については着色された態様で表示されてもよい。また例えば、ステージを表す画像（図６では、丸数字の画像）が、使用可能か否かを区別可能な態様で表示されてもよい。

0062

また、ステージ構成画像３１は、現在位置マーク３３を含む。現在位置マーク３３は、ユーザが次にクリアすべきサブステージを表すために表示される。すなわち、現在位置マーク３３は、ユーザが次にクリアすべきサブステージを表すサブステージ画像の位置に表示される。

0063

なお、本実施形態においては、ユーザは、現在位置マーク３３が表すサブステージ以前のサブステージをプレイ可能である。したがって、本実施形態においては、購入によって使用可能となったステージに含まれるサブステージであっても、その時点ではプレイできないサブステージが存在することもある。例えば、図６に示す例においては、第１ステージのサブステージＤは、購入によって使用可能となったサブステージである一方、図６に示す例の時点ではまだプレイできないサブステージである。このように、本明細書では、「コンテンツを使用可能である」とは、ユーザがそのコンテンツを使用する権利を有していることを意味し、ゲーム状況によっては、そのコンテンツを用いたゲームプレイを行うことができないことがあってもよい。なお、他の実施形態においては、使用可能であるステージ（およびサブステージ）は、無条件でプレイ可能であってもよい。例えば、ステージをクリアすべき順序が設定されない場合、あるステージが使用可能となったことのみを条件として、当該あるステージをプレイ可能にしてもよい。

0064

また、詳細は後述するが、本実施形態においては、使用不可能なコンテンツについて、ユーザは、所定の制限下で試用プレイを行うことができる。つまり、「コンテンツを使用可能である」とは、使用不可能なコンテンツを所定の制限下で使用することができる場合において、当該所定の制限無くコンテンツを使用することができることを意味する。

0065

図６に示すように、ステージモード画像は、ゲームのモードを切り替える指示を行うためのモード切替画像３４および３５を含む。具体的には、モード切替画像３４は、ステージモードへの切り替えを表し、モード切替画像３５は、バトルモードへの切り替えを表す。ステージ構成画像３１においては、ステージモードに対応するモード切替画像３４は、現在のモードがステージモードであることを表す態様（図６では、斜線で示される態様）で表示される。また、ステージ構成画像３１においては、バトルモードに対応するモード切替画像３５を指定可能であり、当該モード切替画像３５を指定する操作（すなわち、タッチする操作）に応じて、ゲームのモードがバトルモードに切り替えられる。

0066

図５の説明に戻り、端末装置２においてステージモード画像が表示される状態において、プレイ可能なサブステージを表すサブステージ画像が指定する操作がユーザによって行われた場合、当該サブステージのゲームが開始される（ステップＳ２）。なお、「プレイ可能なサブステージ」とは、次にクリアすべきサブステージ以前のサブステージであり、具体的には、現在位置マーク３３が表すサブステージ以前のサブステージである。なお、本実施形態においては、使用可能なサブステージであっても、プレイ可能でないサブステージを表すサブステージ画像については、ユーザは指定することができない。つまり、端末装置２は、当該サブステージ画像に対する指示を受け付けず、当該サブステージ画像をタッチしてもゲームは開始されない。

0067

一方、使用不可能なサブステージを表すサブステージ画像（すなわち、「？」が付されたサブステージ画像）を指定する操作がユーザによって行われた場合、端末装置２の表示部２４には購入画像が表示される（ステップＳ３）。購入画像は、ステージの個別購入および一括購入を行うための画像である。

0068

図７は、購入画像の一例を示す図である。図７に示すように、本実施形態においては、購入画像は、試用プレイ指示を行うための試用指示画像４１を含む。試用指示画像４１は、試用プレイの対象となるサブステージを表す画像（図７では、第２ステージのサブステージＡを表す「２−Ａ」の画像）を含む。なお、試用プレイの対象となるサブステージは、購入画像への切り替え時に指定されたサブステージであり、換言すれば、購入画像に切り換わる契機となった指定操作によって指定されたサブステージである。なお、全てのサブステージについて試用プレイが可能である必要はない。例えば、他の実施形態においては、各ステージ内の最初のサブステージについてのみ試用プレイが可能であってもよい。

0069

購入画像が表示される状態において、試用指示画像４１を指定する操作がユーザによって行われた場合、指定されたサブステージについて、試用プレイでゲームが開始される（図５に示すステップＳ４）。ここで、試用プレイは、サブステージが使用可能となった場合におけるゲームプレイよりも制限が加えられたゲームプレイである。試用プレイの具体的な内容は任意である。例えば、本実施形態における試用プレイにおいては、サブステージの一部のみがプレイ可能であったり、所定時間のみ（例えば、１５秒間のみ）プレイ可能であったりしてもよい。また、試用プレイにおいては、特定のキャラクタが登場しなかったり、クリアしても次のサブステージに進めなかったり（つまり、クリアしたとみなされない）するという制限が加えられてもよい。例えば、他の実施形態においては、１つのステージのうち最初のサブステージＡについては、サブステージＡの全体を試用プレイ可能としてもよい。これは、試用プレイの態様のうち、ステージの一部のみをプレイ可能とする態様の一例であるということができ、また、クリアしても次のサブステージに進めないという制限が加えられる態様の一例であるということもできる。

0070

また、図７に示すように、購入画像は、個別購入指示を行うための個別購入指示画像４２を含む。本実施形態においては、個別購入指示画像４２は、下記の画像を含む。
・購入対象となるステージ（すなわち、指定されたサブステージを含むステージ。図７では、第２ステージ）を表すステージ画像４２ａ
・購入金額を表す金額画像４２ｂ（図７では、５００円）
・購入に応じて付与されるバトルチケットの量を表す画像（図７では、「バトルチケット ２０プレゼント」のメッセージ）
個別購入指示画像４２によって示されるステージに関する個別購入を行う場合、ユーザは、当該個別購入指示画像４２を指定する操作を行う。

0071

購入画像が表示される状態において、個別購入指示画像４２を指定する操作がユーザによって行われた場合、使用不可能なステージのうちで上記進行順の順序が最も早いステージを使用可能とするように設定が変更される（図５に示すステップＳ５）。したがって、その後、ステージモード画像が表示された場合には、上記ステージに含まれる各サブステージを表すサブステージ画像は、使用可能を表す態様で表示される。また、個別購入指示画像４２を指定する操作がユーザによって行われた場合、所定数（ここでは、２０個）のバトルチケットがユーザに付与される。

0072

また、図７に示すように、購入画像は、一括購入指示を行うための一括購入指示画像４３を含む。本実施形態においては、一括購入指示画像４３は、下記の画像を含む。
・購入対象となるステージ（すなわち、全６ステージ）を表すステージ画像４３ａ
・購入金額を表す金額画像４３ｂ（図７では、２９００円）
・バトルモードでのゲームプレイが無制限になる旨の通知を表す画像（図７では、「バトルし放題！」のメッセージ）
一括購入を行う場合、ユーザは、一括購入指示画像４３を指定する操作を行う。なお、各ステージを表すステージ画像４３ａは、その時点ですでに購入済みであるステージか否かを区別可能な態様で、それぞれのステージを表す。図７に示す例では、第１ステージが購入済みであるので、当該第１ステージについては、ステージを表す画像が半透明（図７では、点線で示す）で表されるとともに、「購入済」と示され、第１ステージ以外のステージについては、ステージを表す画像が（不透明で）表される。なお、他の実施形態においては、ステージ画像４３ａは、購入されていないステージを表す画像のみを含んでいてもよい。

0073

購入画像が表示される状態において、一括購入指示画像４３を指定する操作がユーザによって行われた場合、ゲームに含まれる６つの全てのステージを使用可能とするように設定が変更される（図５に示すステップＳ６）。したがって、その後、ステージモード画像が表示された場合には、全てのステージに含まれる各サブステージを表すサブステージ画像は、使用可能を表す態様で表示される。また、一括購入指示画像４３を指定する操作がユーザによって行われた場合、バトルプレイを無制限に行うことができるように設定が変更される。

0074

なお、上記のように、本実施形態においては、あるステージ（およびサブステージ）は、進行順が当該ステージより前のステージをクリアしていることを条件に、プレイ可能となる。一方、ステージの購入については、ステージをクリアしていることは条件とはならず、あるステージより前のステージをクリアしていなくても、当該あるステージを購入することが可能である。このように、本実施形態においては、ユーザがステージを購入する機会を増やすことによって、ステージの購入を行いやすくしている。

0075

また、図７に示す購入画像に関して、第６部分使用状態では、全てのステージがすでに使用可能となっていることから試用プレイの必要が無いので、第６部分使用状態において表示される購入画像は、試用指示画像４１を含まない。また、第６部分使用状態では、個別購入と一括購入とで購入対象が実質的に同じになる。つまり、購入対象は、どちらも、バトルプレイを無制限に行う権利である。そのため、第６部分使用状態において表示される購入画像は、一括購入指示画像４３を含まない。したがって、第６部分使用状態では、図５に示すステップＳ３とは異なり、例外的に、個別購入指示のみが受け付けられ、試用プレイ指示および一括購入指示は受け付けられない。なお、他の実施形態においては、第６部分使用状態において表示される購入画像は、個別購入指示画像４２を含まず、一括購入指示画像４３を含んでいてもよい。なお、このとき、一括購入指示画像４３が指定された場合に実行される処理は、本実施形態において個別購入指示画像４２が指定された場合に実行される処理と同じである。

0076

図８は、バトルモードにおいてコンテンツの購入に関して実行される処理の流れの一例を示す図である。本実施形態においては、所定の条件に応じてバトルモードが開始する。所定の条件は任意であるが、例えば、メニュー画像、または、上記ステージモード画像において、バトルモードへの切り替えがユーザによって指示されたことである。バトルモードが開始されると、端末装置２の表示部２４にバトルモード画像が表示される（ステップＳ１１）。

0077

図９は、バトルモード画像の一例を示す図である。図９に示すように、バトルモード画像は、自プレイヤ画像５１、対戦プレイヤ画像５２、および、開始指示画像５３を含む。自プレイヤ画像５１は、端末装置２のユーザ（換言すれば、プレイヤ）に関する情報を表し、例えば、ユーザの名前、ユーザが使用するプレイヤキャラクタ、および／または、バトルプレイに関してユーザに設定されたレート等を表す。レートは、例えばユーザの腕前（換言すれば、レベル）を示す指標であり、対戦に勝つと上昇し、対戦に負けると下降するように決定されてもよい。対戦プレイヤ画像５２は、端末装置２のユーザの対戦相手となるユーザ（換言すれば、プレイヤ）に関する情報を表し、例えば、自プレイヤ画像５１と同種の情報を表す。例えば、ユーザは、自プレイヤ画像５１および対戦プレイヤ画像５２を参考に、対戦プレイヤとのゲームプレイを開始するか否かを判断する。また、開始指示画像５３は、バトルゲームプレイを開始するための開始指示を行うための画像である。なお、バトルモード画像は、複数の対戦相手の候補を表す画像を含んでいてもよく、当該複数の候補からユーザが対戦相手を指定することができるようにしてもよい。

0078

また、バトルモード画像は、ステージモード画像と同様、モード切替画像３４および３５を含む（図９参照）。バトルモード画像においては、バトルモードに対応するモード切替画像３５は、現在のモードがバトルモードであることを表す態様（図９では、斜線で示される態様）で表示される。また、バトルモード画像においては、ステージモードに対応するモード切替画像３４が指定可能であり、当該モード切替画像３４を指定する操作に応じて、ゲームのモードがステージモードに切り替えられる。

0079

図８に示すように、バトルモード画像において、上記開始指示が行われた場合、バトルプレイ可能な状態であれば、バトルモードのゲームが開始される（ステップＳ１２）。なお、「バトルプレイ可能な状態」とは、ユーザが（バトルプレイに必要となる数の）バトルチケットを所有している状態、または、バトルプレイの制限が解除された（すなわち、バトルプレイを無制限に行うことができる）状態である。

0080

一方、バトルモード画像において、上記開始指示が行われた場合、バトルプレイ不可能な状態であれば、購入画像が表示される（ステップＳ１３）。なお、「バトルプレイ不可能な状態」とは、バトルプレイの制限が解除されておらず、かつ、ユーザが（バトルプレイに必要となる数の）バトルチケットを所有していない状態である。

0081

ここで、本実施形態においては、バトルプレイに関してはステージモードとは異なり、ユーザは試用プレイを行うことができないものとする。したがって、ステップＳ１３で表示される購入画像は、試用指示画像４１を含まない（かつ、個別購入指示画像４２および一括購入指示画像４３を含む）。つまり、バトルモードにおいて購入画像が表示される状態においては、ユーザは、個別購入指示と一括購入指示とを行うことが可能である。なお、他の実施形態においては、バトルプレイにおいても試用プレイが可能であってもよく、このとき、購入画像は試用指示画像４１を含んでいてもよい。また、他の実施形態においては、初期状態においてバトルチケットが無料で付与されてもよく、これによって、（バトルチケットに応じた回数だけ、バトルモードの試用プレイが可能にされてもよい。

0082

購入画像が表示される状態において、個別購入指示画像４２を指定する操作がユーザによって行われた場合、上記ステップＳ５と同様の設定変更処理が実行される（図８に示すステップＳ１４）。一方、購入画像が表示される状態において、一括購入指示画像４３を指定する操作がユーザによって行われた場合、上記ステップＳ６と同様の設定変更処理が実行される（図８に示すステップＳ１５）。上記ステップＳ１４またはＳ１５の処理によって、端末装置２はバトルプレイ可能な状態となる。したがって、バトルモードにおいては、上記ステップＳ１４またはＳ１５の処理に続けて、バトルモードでのゲームが開始（ステップＳ１２）されてもよい。

0083

なお、バトルモードにおいて表示される購入画像に関してもステージモードにおける購入画像と同様、第６部分使用状態では、一括購入指示画像４３を含まない。つまり、第６部分使用状態では、図８に示すステップＳ１３とは異なり、例外的に、個別購入指示画像４２のみが受け付けられ、一括購入指示は受け付けられない。

0084

（２−３：コンテンツの購入金額）
上記のように、本実施形態においては、初期状態においても部分使用状態においても、ユーザは個別購入と一括購入とを選択的に行うことが可能である。ここで、コンテンツ（すなわち、ステージ）の購入のために課金される料金は、各状態において異なっており、本実施形態においては以下に説明するように設定される。

0085

図１０は、端末装置の各状態（具体的には、初期状態または部分使用状態）における課金額の一例を示す図である。図１０に示すように、初期状態においては、個別購入に対する課金額（すなわち、第１ステージに対する対価）が２００円に設定され、一括購入に対する課金額が３０００円に設定される。また、第１〜第５部分使用状態においては、個別購入に対する課金額（すなわち、第２〜第６ステージのうちの１つに対する対価）が５００円に設定される。また、第１〜第５部分使用状態においては、一括購入に対する課金額が、部分使用状態の段階が進むにつれて（換言すれば、個別購入の回数が増えるにつれて）、次第に安くなるように設定される。具体的には、部分使用状態が１段階進む毎に、一括購入に対する課金額は４００円ずつ安くなる。また、第６部分使用状態においては、個別購入に対する課金額（すなわち、バトルプレイを無制限にすることに対する対価）が１０００円に設定される。

0086

なお、他の実施形態においては、バトルプレイを無制限にすることに対する対価は、無しであってもよい。例えば、第５部分使用状態において個別購入が行われたことに応じて、端末装置２が全使用状態となるようにしてもよい。

0087

上記のように、本実施形態においては、１回目の個別購入に対する対価（すなわち、課金額。具体的には、２００円）が、２回目以降の個別購入に対する対価（具体的には、５００円）よりも小さく設定される。これによれば、初めてコンテンツを購入するユーザに対して、試しにコンテンツを購入する動機付けを与えることができ、コンテンツの使用をユーザに促すことができる。なお、他の実施形態においては、最初から所定回数までの各個別購入に対する対価が、それより後の個別購入に対する対価よりも小さく設定されてもよい。また、他の実施形態においては、第１ステージに対する対価を無しにしてもよい。つまり、第１ステージは無料で使用可能なコンテンツであってもよい。また、他の実施形態においては、１回目の個別購入に対する対価は、２回目以降の個別購入に対する対価と同じであってもよい。

0088

また、他の実施形態においては、個別購入が行われてから所定期間（例えば、１週間）については、次に行われる個別購入および／または一括購入に対する対価を小さくするようにしてもよい。例えば、初期状態から１回目の個別購入が行われた場合、第１部分使用状態において、１回目の個別購入から所定期間、個別購入に対する課金額は５００円から３００円に割引きされてもよく、また、一括購入に対する課金額は２９００円から２８００円に割引きされてもよい。

0089

また、本実施形態においては、一括購入に対する対価は、一括購入が行われるまでに行われた個別購入の回数に応じて変化する。具体的には、当該個別購入の回数が多いほど、一括購入に対する対価が小さくなる。これによれば、何回かの個別購入を行った後でもユーザが一括購入を行う動機付けを与えることができ、全てのコンテンツを使用可能とする動機付けをユーザに与えることができる。

0090

図１１は、図１０に示す課金額の一例において、一括購入を行ったタイミングと、そのときの支払総額との関係を示す図である。図１１に示すように、本実施形態において、初期状態において一括購入が行われた場合、ユーザがそれまでに行った個別購入は０回であるので、端末装置２を全使用状態とするための課金総額（換言すれば、全使用状態となるまでにユーザに対して課金された総額）は、３０００円となる。また、初期状態において一括購入が行われた場合、ユーザがそれまでに行った個別購入は１回であり、当該個別購入に対する課金額は２００円である。また、この場合における一括購入に対する課金額は２９００円であるので、この場合における課金総額は、３１００円となる。上記と同様に課金総額を計算すると、図１１に示すように、部分使用状態において一括購入が行われた場合の課金総額は、第１部分使用状態から第５部分使用状態までの各段階において、１段階につき１００円ずつ高くなる。また、第６部分使用状態において一括購入が行われた場合の課金総額は、第５部分使用状態において一括購入が行われた場合の課金総額よりも２００円高くなり、３７００円となる。

0091

上記のように、本実施形態においては、端末装置２を全使用状態とすることに対する対価は、一括購入が行われたタイミング（換言すれば、個別購入が行われた回数）に応じて変化する。具体的には、一括購入が行われたタイミングが早いほど（換言すれば、個別購入が行われた回数が少ないほど）、端末装置２を全使用状態とすることに対する対価は小さくなる。これによれば、早いタイミングで一括購入を行う動機付けをユーザに与えることができ、早い段階で全てのコンテンツを使用可能とする動機付けをユーザに与えることができる。なお、他の実施形態においては、ある回数の個別購入を行った後で一括購入を行った場合の課金総額は、当該ある回数より１回多く個別購入を行った後で一括購入を行った場合の課金総額と、必ずしも異なる必要はなく、同じであってもよい。例えば、他の実施形態においては、３回の個別購入を行うまでは、端末装置２を全使用状態とすることに対する課金総額が同じになるようにしてもよい。

0092

［３．情報処理システムにおいて実行される処理の具体例］
次に、図１２〜図１６を参照して、情報処理システムにおいて実行される処理の具体例について説明する。図１２は、サーバ１において実行される処理に用いられる各種情報の一例を示す図である。図１２に示す各種情報は、例えば、サーバ１の記憶部１２に記憶される。

0093

図１２に示すように、記憶部１２は、上記ゲームアプリケーションに関するアプリケーション情報を記憶する。アプリケーション情報は、料金情報、および、ステージ情報を含む。

0094

料金情報は、上記コンテンツ（ここでは、ステージ）に対する料金を示す。換言すれば、料金情報は、コンテンツを使用可能とすることに対する対価を示す。具体的には、料金情報は、図１０において示される、一括購入および個別購入に対する課金額を示す情報を含む。

0095

なお、他の実施形態において、料金情報は、所定の条件が満たされたことに応じて変更されてもよい。例えば、上述したように、個別購入が行われてから所定期間が経過するまでの間は、次に行われる個別購入および／または一括購入に対する課金額を割り引く場合、サーバ１は、個別購入が行われたことに応じて、割引き後の金額を示すように、料金情報を変更してもよい。このとき、上記所定期間が経過したことに応じて、サーバ１は、料金情報を元に戻す変更を行ってもよい。また、料金情報が変更される場合、サーバ１は、ユーザ毎に料金情報を設定する（例えば、料金情報をユーザ情報に関連付けて記憶する）ようにしてもよい。

0096

ステージ情報は、上述のステージに関する情報であり、ステージを用いたゲーム処理を実行するために用いられる情報である。本実施形態においては、ステージ情報は、第１〜第６ステージの各ステージにそれぞれに対応する第１〜第６基本ステージ情報を含む。なお、記憶部１２は、基本ステージ情報に関する上述の進行順を特定可能に、第１〜第６基本ステージ情報を記憶する。つまり、記憶部１２は、ステージについて設定される順序を特定可能な情報を記憶している。また、ステージ情報は、第１〜第６基本ステージ情報の各情報にそれぞれ関連付けられる、第１〜第６追加ステージ情報を含む。なお、第ｎ（ｎは１〜６の整数）基本ステージ情報および第ｎ追加ステージ情報は、それぞれ、第ｎステージを用いたゲーム処理を実行するために用いられる。

0097

具体的には、基本ステージ情報は、例えば、ステージのゲーム空間を示す情報、および／または、ステージに登場するキャラクタを示す情報を含む。追加ステージ情報は、例えば、ステージの一部に関する情報であってもよいし、基本ステージ情報が暗号化されている場合、当該暗号化された基本ステージ情報を端末装置２において復号化するために用いられる情報（例えば、鍵情報）であってもよい。また、追加ステージ情報は、ステージの一部に関する情報と、基本ステージ情報を復号化するために用いられる情報との組み合わせであってもよい。詳細は後述するが、本実施形態においては、基本ステージ情報と追加ステージ情報とを用いることで、ステージを用いたゲーム処理が可能となる。

0098

また、図１２に示すように、記憶部１２は、ユーザがプレイするゲームに関するユーザ情報を記憶する。なお、このユーザ情報は、サーバ１が提供するサービス（本実施形態では、ゲームアプリケーションに関するサービス）の提供を受ける者として登録されたユーザに関する情報である。記憶部１２は、登録されたユーザ毎にユーザ情報を記憶する。図１２に示すように、ユーザ情報は、使用可否情報、バトル制限情報、および、残高情報を含む。

0099

使用可否情報は、各ステージが使用可能であるか否かを、ステージ毎に示す情報である。本実施形態においては、使用可否情報は、第１〜第６ステージのそれぞれについて、使用可能であるか否かを示す。

0100

バトル制限情報は、バトルプレイの制限に関する情報であり、例えば、制限の有無、および／または、制限に関する条件を示す。本実施形態においては、バトル制限情報は、チケット数情報、および、バトル制限フラグ情報を含む。チケット数情報は、ゲームにおいてユーザが所有するバトルチケットの数を示す。バトル制限フラグ情報は、バトル制限フラグがオンであるかオフであるかを示す。ここで、バトル制限フラグがオンである状態は、バトルプレイが制限される状態（すなわち、バトルチケットが無ければバトルプレイが不可能な状態）である。また、バトル制限フラグがオフである状態は、バトルプレイが制限されない状態（すなわち、バトルチケットが無くてもバトルプレイが可能な状態）である。

0101

残高情報は、ユーザがサーバ１によって提供されるサービスにおける支払に利用可能な金額の残高を示す情報である。ユーザは、例えば、プリペイドカードあるいはカード決済等の任意の方法で予め入金を行っておくことで、上記残高を追加することができる。なお、ユーザが入金によって残高を追加する方法は任意であり、従来と同様の方法であってもよい。なお、残高情報は、現実の通貨の残高を示すものであってもよいし、上記サービスにおいて利用可能なポイント（換言すれば、仮想通貨）の残高を示すものであってもよい。また、残高情報が示す金額は、上記ゲームアプリケーションに関する支払に利用可能な金額に限らず、サーバ１によってサービスが提供される他のアプリケーションに関する支払についても利用可能な金額であってもよい。

0102

また、ここでは、コンテンツに対する対価である金額をユーザが支払う支払方法の一例として、上記金額を予め入金しておく方法を例示するが、支払方法は、任意であり、従来と同様の方法が用いられてもよい。例えば、本実施形態において、クレジットカードの決済による方法が用いられてもよいし、いわゆるキャリア決済による方法が用いられてもよい。

0103

図１３は、端末装置２において実行される処理に用いられる各種情報の一例を示す図である。図１３に示す各種情報は、例えば、端末装置２の記憶部２２に記憶される。

0104

図１３に示すように、記憶部２２は、上記ゲームアプリケーションに関するアプリケーション情報を記憶する。なお、アプリケーション情報として端末装置２に記憶される内容と、サーバ１に記憶される内容とは、必ずしも一致していなくてもよい。本実施形態においては、端末装置２に記憶されるアプリケーション情報は、基本ステージ情報を含む。端末装置２に記憶される基本ステージ情報は、サーバ１に記憶される基本ステージ情報と同じである。基本ステージ情報は、ゲームアプリケーションのプログラムがサーバ１から端末装置２へダウンロードされる際に、当該プログラムとともにダウンロードされ、ゲームアプリケーションのインストール時に記憶部２２に記憶される。

0105

また、端末装置２に記憶されるアプリケーション情報は、状況によっては追加ステージ情報を含む。端末装置２に記憶される追加ステージ情報は、サーバ１に記憶される追加ステージ情報と同じである。詳細は後述するが、本実施形態においては、初期状態においては追加ステージ情報は端末装置２には記憶されず、ステージが使用可能となる場合に、当該ステージに関する追加ステージ情報がサーバ１から端末装置２へ送信されて端末装置２に記憶される。

0106

なお、図示しないが、サーバ１および端末装置２に記憶されるアプリケーション情報はいずれも、バトルモードにおけるゲーム処理を実行するために用いられる情報（例えば、バトルモードにおけるゲーム空間を示す情報、および、当該ゲーム空間に登場するキャラクタに関する情報等）を含む。端末装置２において、この情報は、基本ステージ情報と同様、ゲームアプリケーションのインストール時に記憶部２２に記憶される。

0107

また、記憶部２２に記憶されるアプリケーション情報は、上述の使用可否情報、バトル制限情報、および、残高情報を含む。これらの各情報は、サーバ１に記憶される使用可否情報、バトル制限情報、および、残高情報と同期するように内容が更新される。

0108

（端末装置２において実行される処理の具体例）
図１４は、端末装置２における処理（「端末処理」と記載する）の流れの一例を示すフローチャートである。なお、図１４に示す一連の処理は、端末装置２においてゲームアプリケーションのプログラムの実行が開始されたことに応じて開始される。なお、本実施形態では、端末装置２の処理部２１（具体的には、ＣＰＵ）が図１４（および図１５）に示す各ステップの処理を実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。

0109

また、図１４に示すフローチャート（後述する図１５および図１６におけるフローチャートについても同様）における各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて（または代えて）別の処理が実行されてもよい。

0110

また、端末装置２またはサーバ１の処理部は、図１４〜図１６に示す各処理を、メモリ（または記憶部）を用いて実行する。すなわち、処理部は、各処理ステップによって得られる情報（換言すれば、データ）をメモリに記憶し、それ以降の処理ステップにおいて当該情報を用いる場合には、メモリから当該情報を読み出して利用する。また、図１４〜図１６に示す各処理において自機から他の装置へ情報を送信する場合、処理部は、通信部を用いて当該情報を送信する（換言すれば、通信部に情報を送信させる）。

0111

図１４に示す端末処理においては、まずステップＳ２１において、処理部２１は、ステージモード画像（図６）を表示部２４に表示する（図５に示すステップＳ１）。ステージモード画像が表示されることによって、使用可能なサブステージのゲームプレイを開始する指示（図５に示すステップＳ２）、購入画像を表示する指示（図５に示すステップＳ３）、および、モード切替指示が受け付けられる。なお、他の実施形態においては、処理部２１は、ゲームアプリケーションの起動後においてまずメニュー画像を表示部２４に表示し、その後、メニュー画像に対してユーザが行ったモード切替指示に応じてステージモード画像を表示部２４に表示してもよい。ステップＳ２１の次に、ステップＳ２２の処理が実行される。

0112

ステップＳ２２において、処理部２１は、ステージモードでのゲームを開始するか否か（換言すれば、使用可能なサブステージのゲームプレイを開始する指示が行われたか否か）を判定する。すなわち、処理部２１は、ステージモード画像に対してサブステージ画像を指定する操作が行われたか否かを判定する第１判定処理を実行する。具体的には、処理部２１は、入力部２３に対する入力を示す入力情報（例えば、ユーザによるタッチ位置を示す情報）を入力部２３から取得する。そして、処理部２１は、取得された入力情報に基づいて、上記操作（例えば、上記サブステージ画像をタッチする操作）が行われたか否かを判定する。

0113

上記第１判定処理において上記操作が行われたと判定された場合、処理部２１は、指定されたサブステージ画像が表すサブステージが、使用可能なステージに含まれるか否かを判定する第２判定処理を実行する。なお、第２判定処理は、指定されたサブステージ画像が表すサブステージを含むステージに対応する追加ステージ情報が、記憶部２２に記憶されているか否かによって行うことができる。また、他の実施形態においては、使用可否情報（図１２）が端末装置２に記憶されてもよく、上記第２判定処理は、この使用可否情報を参照することによって行われてもよい。

0114

第１判定処理および第２判定処理の判定結果が共に肯定となる場合、ステップＳ２２の判定結果は肯定となり、第１判定処理および第２判定処理の判定結果の少なくともいずれかが否定となる場合、ステップＳ２２の判定結果は否定となる。ステップＳ２２の判定結果が肯定である場合、ステップＳ２３の処理が実行される。一方、ステップＳ２２の判定結果が否定である場合、後述するステップＳ２４の処理が実行される。

0115

ステップＳ２３において、処理部２１は、ステージモードにおけるゲームプレイのためのゲーム処理を実行する（図５に示すステップＳ２）。すなわち、処理部２１は、記憶部２２に記憶されている基本ステージ情報および追加ステージ情報を用いて上記ゲーム処理を実行する。これによって、ユーザは、指定したステージ（具体的には、ステージモード画像において指定したサブステージ）のゲームを行うことができる。

0116

なお、端末装置２は、ゲームアプリケーションを起動してから、サーバ１との通信を行わなくても、上記ステップＳ２３のゲーム処理を実行することが可能であってもよい。つまり、端末装置２がサーバ１との通信が可能な環境になくても、ユーザがステージモードにおけるゲームプレイを行うことができるようにしてもよい。本実施形態においては、ユーザは非消費型コンテンツであるステージを使用する権利を購入するので、購入後においては、端末装置２の通信環境にかかわらずステージを使用することができることがユーザにとって便利である。そのため、端末装置２は、サーバ１との通信を条件とせずに、（購入済みの）ステージを用いたゲーム処理を実行することが可能であるようにしてもよい。

0117

上記ステップＳ２３において、ユーザによって指定されたサブステージのゲームが終了した場合（例えば、ユーザがサブステージをクリアしたり、ゲームオーバーとなったり、あるいは、ユーザが終了指示を行ったりした場合）、処理部２１は、ステップＳ２３の処理を終了する。ステップＳ２３の後、ステップＳ２１の処理が再度実行される。

0118

一方、ステップＳ２４において、処理部２１は、購入画像を表示するか否か（換言すれば、購入画像を表示する指示が行われたか否か）を判定する。すなわち、処理部２１は、上記ステップＳ２２の第２判定処理において、指定されたサブステージ画像が表すサブステージが、使用可能なステージに含まれない（換言すれば、使用不可能なステージに含まれる）と判定されたか否かを判定する。ステップＳ２４の判定結果が肯定である場合、ステップＳ２５の処理が実行される。一方、ステップＳ２４の判定結果が否定である場合、後述するステップＳ２６の処理が実行される。

0119

ステップＳ２５において、処理部２１は、購入処理を実行する。購入処理は、表示部２４に購入画像が表示される状態において、ユーザから購入指示を受け付けるための処理である。以下、図１５を参照して、購入処理における処理の詳細について説明する。

0120

図１５は、図１４に示すステップＳ２５の購入処理の詳細な流れの一例を示すサブフローチャートである。購入処理においては、まずステップＳ４１において、処理部２１は、購入画像（図７）を表示部２４に表示する（図５に示すステップＳ３）。これによって、上述の試用プレイ指示、個別購入指示、および、一括購入指示が受け付けられる。ステップＳ４１の次に、ステップＳ４２の処理が実行される。

0121

ステップＳ４２において、処理部２１は、試用プレイ指示が行われたか否かを判定する。すなわち、処理部２１は、上記入力情報を入力部２３から取得し、取得された入力情報に基づいて、試用プレイ指示の操作（すなわち、試用指示画像４１をタッチする操作）が行われたか否かを判定する。ステップＳ４２の判定結果が肯定である場合、ステップＳ４３の処理が実行される。一方、ステップＳ４２の判定結果が否定である場合、後述するステップＳ４４の処理が実行される。

0122

ステップＳ４３において、処理部２１は、試用プレイのためのゲーム処理を実行する（図５に示すステップＳ４）。すなわち、処理部２１は、記憶部２２に記憶されている基本ステージ情報を用いて上記ゲーム処理を実行する。これによって、ユーザは、指定したステージ（具体的には、ステージモード画像において指定したサブステージ）に関する試用プレイを行うことができる。なお、ユーザによって指定されたサブステージの試用プレイでのゲームが終了した場合（例えば、試用プレイが可能なプレイ時間が経過したり、試用プレイが可能なエリアをプレイヤキャラクタがクリアしたり、あるいは、ユーザが終了指示を行ったりした場合）、処理部２１は、ステップＳ４３の処理を終了する。ステップＳ４３の後、処理部２１は、購入処理を終了する。

0123

なお、上記ステップＳ４３において、処理部２１は、追加ステージ情報を用いずに（つまり、基本ステージ情報のみを用いて）上記ゲーム処理を実行する。つまり、試用プレイは、基本ステージ情報のみを用いて実行可能であり、追加ステージ情報は、試用プレイのために必要となる情報を含まない。例えば、試用プレイでは、サブステージの一部のみをプレイ可能である場合、追加ステージ情報は、当該一部とは異なる部分に関する情報を含んでもよい。また、追加ステージ情報が、暗号化された基本ステージ情報を復号化するための鍵情報である場合、基本ステージ情報のうちで試用プレイにおいて用いられる部分は、暗号化されずに記憶されてもよい。

0124

ステップＳ４４において、処理部２１は、購入指示が行われたか否かを判定する。すなわち、処理部２１は、上記入力情報を入力部２３から取得し、取得された入力情報に基づいて、個別購入指示または一括購入指示の操作（すなわち、個別購入指示画像４２または一括購入指示画像４３をタッチする操作）が行われたか否かを判定する。ステップＳ４４の判定結果が肯定である場合、ステップＳ４５の処理が実行される。一方、ステップＳ４４の判定結果が否定である場合、ステップＳ４２の処理が実行される。これ以降、処理部２１は、ステップＳ４２またはＳ４４の判定結果が肯定となるまで、例えば所定時間に１回の割合で、ステップＳ４２およびＳ４４の一連の処理を繰り返し実行する。

0125

ステップＳ４５において、処理部２１は、サーバ１に対して購入要求を行う。すなわち、処理部２１は、購入要求を示す購入要求情報を生成して、通信部２５を介して（換言すれば通信部２５を用いて）サーバ１へ購入要求情報を送信する。なお、購入要求情報は、購入指示が個別購入指示であるか、それとも、一括購入指示であるかを示す情報を含む。また、購入要求情報は、購入要求に係るユーザ（または端末装置２）を識別可能なユーザ識別情報を含む。なお、他の実施形態において、個別購入によって購入するコンテンツをユーザが指定することができる場合、購入要求情報は、購入対象となるコンテンツを示す情報を含む。ステップＳ４５の処理の次に、ステップＳ４６の処理が実行される。

0126

詳細は後述するが、上記ステップＳ４５の処理による購入要求に応じて、サーバ１は、購入要求に対応するステージに関する追加ステージ情報を端末装置２へ送信する（図１６に示すステップＳ５６およびＳ６１）。

0127

ステップＳ４６において、処理部２１は、サーバ１から送信されてくる追加ステージ情報を、通信部２５を介して受信する。また、処理部２１は、受信した追加ステージ情報を記憶部２２に記憶する。これによって、ステップＳ４５における購入要求に対応するステージが使用可能となる。ステップＳ４６の処理の後、処理部２１は、購入処理を終了する。

0128

図１４の説明に戻り、図１５に示す購入処理の後、処理部２１は、ステップＳ２１の処理を再度実行する。つまり、購入画像において購入操作が行われた後、端末装置２の表示部２４にはステージモード画像が表示される。

0129

一方、ステップＳ２６において、処理部２１は、ステージモード画像においてモード切替指示が行われたか否かを判定する。すなわち、処理部２１は、上記入力情報を入力部２３から取得し、取得された入力情報に基づいて、モード切替指示の操作（すなわち、バトルモードを表すモード切替画像３５をタッチする操作）が行われたか否かを判定する。ステップＳ２６の判定結果が肯定である場合、ステップＳ２７の処理が実行される。一方、ステップＳ２６の判定結果が否定である場合、ステップＳ２２の処理が再度実行される。以降、ステップＳ２２〜Ｓ２６のいずれかの判定処理における判定結果が肯定となるまで、例えば所定時間に１回の割合で、ステップＳ２２〜２６の一連の処理が繰り返し実行される。

0130

ステップＳ２７において、処理部２１は、バトルモード画像（図９）を表示部２４に表示する（図８に示すステップＳ１１）。バトルモード画像が表示されることによって、バトルプレイを開始する開始指示、および、モード切替指示が受け付けられる。ステップＳ２７の次に、ステップＳ２８の処理が実行される。

0131

ステップＳ２８において、処理部２１は、バトルプレイのゲームを開始するか否かを判定する。すなわち、処理部２１は、上記入力情報を入力部２３から取得し、取得された入力情報に基づいて、上記開始指示の操作（すなわち、開始指示画像５３をタッチする操作）が行われたか否かを判定する第３判定処理を実行する。また、第３判定処理において上記開始指示の操作が行われたと判定された場合、処理部２１は、バトルプレイ可能な状態（具体的には、ユーザがバトルチケットを所有している状態、または、バトルプレイの制限が解除された状態）であるか否かを判定する第４判定処理を実行する。

0132

上記第４判定処理の具体的な判定方法は任意である。例えば、サーバ１に記憶されるバトル制限情報と同期するようにバトル制限情報が端末装置２においても記憶される場合、処理部２１は、当該バトル制限情報を参照することによって第４判定処理を行うことができる。また例えば、端末装置２は、バトルプレイが可能であるか否かを確認する要求をサーバ１に対して行うようにしてもよい。このとき、サーバ１は、記憶部１２に記憶されているバトル制限情報を参照して、バトルプレイが可能であるか否かを判断し、判断した結果を示す情報を端末装置２へ送信してもよい。当該情報を受信することによって、端末装置２は第４判定処理を行うことができる。

0133

第３判定処理および第４判定処理の判定結果が共に肯定となる場合、ステップＳ２８の判定結果は肯定となり、第３判定処理および第４判定処理の判定結果の少なくともいずれかが否定となる場合、ステップＳ２８の判定結果は否定となる。ステップＳ２８の判定結果が肯定である場合、ステップＳ２９の処理が実行される。一方、ステップＳ２８の判定結果が否定である場合、後述するステップＳ３０の処理が再度実行される。

0134

ステップＳ２９において、処理部２１は、バトルプレイのためのゲーム処理を実行する（図８に示すステップＳ１２）。すなわち、処理部２１は、記憶部２２に記憶されているアプリケーション情報を用いて上記ゲーム処理を実行する。これによって、ユーザは、バトルプレイを行うことができる。なお、バトルプレイが終了した場合（例えば、対戦の制限時間が経過したり、対戦の勝負がついたり、あるいは、ユーザが終了指示を行ったりした場合）、処理部２１は、ステップＳ２９の処理を終了する。ステップＳ２９の後、ステップＳ２７の処理が再度実行される。

0135

なお、図示しないが、バトルプレイのためのゲーム処理が実行される場合、端末装置２は、サーバ１に対して通知を行う。当該通知に応じて、サーバ１は、バトルチケットを減算する処理を実行する。具体的には、サーバ１は、記憶部２２に記憶されている更新前のチケット数情報から所定数（具体的には、１回のバトルプレイに必要なチケット数）を減算した数値を示すようにチケット数情報を更新する。

0136

ステップＳ３０において、処理部２１は、購入画像を表示するか否かを判定する。すなわち、処理部２１は、上記ステップＳ２８の第４判定処理において、バトルプレイ可能な状態でないと判定されたか否かを判定する。ステップＳ３０の判定結果が肯定である場合、ステップＳ３１の処理が実行される。一方、ステップＳ３０の判定結果が否定である場合、後述するステップＳ３２の処理が実行される。

0137

ステップＳ３１において、処理部２１は、購入処理を実行する。ステップＳ３１における購入処理は、バトルモード画像が試用指示画像４１を含まない点（そのため、図１５に示すステップＳ４２およびＳ４３の処理が実行されない点）で、ステップＳ２５の処理と異なる。上記の点以外については、ステップＳ３１における購入処理は、ステップＳ２５の処理と同様である。上記ステップＳ３１の処理によって、バトルモードにおいて購入画像が端末装置２の表示部２４に表示されることとなる（図８に示すステップＳ１３）。ステップＳ３１の後、ステップＳ２７の処理が再度実行される。

0138

なお、上記ステップＳ２５またはＳ３１の購入処理において、端末装置２が第６部分使用状態である場合、個別購入指示のみが受け付けられ、一括購入指示は受け付けられない。したがって、この場合における購入処理においては、ステップＳ４１においては、一括購入指示画像４３を含まない購入画像が表示される。

0139

一方、ステップＳ３２において、処理部２１は、バトルモード画像においてモード切替指示が行われたか否かを判定する。すなわち、処理部２１は、上記入力情報を入力部２３から取得し、取得された入力情報に基づいて、モード切替指示の操作（すなわち、ステージモードを表すモード切替画像３４をタッチする操作）が行われたか否かを判定する。ステップＳ３２の判定結果が肯定である場合、ステップＳ２１の処理が実行される。一方、ステップＳ３２の判定結果が否定である場合、ステップＳ２８の処理が再度実行される。以降、ステップＳ２８〜Ｓ３２のいずれかの判定処理における判定結果が肯定となるまで、例えば所定時間に１回の割合で、ステップＳ２８〜３２の一連の判定処理が繰り返し実行される。

0140

なお、図１４に示す端末処理は、ゲームアプリケーションの実行が終了する指示がユーザによって行われたことに応じて終了する。上記指示は、端末処理の実行中における任意のタイミングで受け付けられてもよく、例えば、図示しないメニュー画像が表示部２４に表示される状態で受け付けられてもよいし、ステージモード画像および／またはバトルモード画像が表示部２４に表示される状態で受け付けられてもよい。また、ゲームアプリケーションは、ステージモードおよびバトルモード以外のゲームモードを含んでいてもよい。このとき、端末処理においては、ゲームモードに応じた処理が実行される。

0141

（サーバ１において実行される処理の具体例）
図１６は、サーバ１における処理（「サーバ処理」と記載する）の流れの一例を示すフローチャートである。なお、図１６に示す一連の処理は、サーバ１の動作中において継続的に実行される。なお、本実施形態では、サーバ１の処理部１１（具体的には、ＣＰＵ）が、上述のサーバ側ゲームプログラムを実行することによって、図１６に示す各ステップの処理を実行する。ただし、他の実施形態においては、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。

0142

図１６に示すサーバ処理においては、まずステップＳ５１において、処理部１１は、端末装置２からの要求を受け付ける。すなわち、処理部１１は、端末装置２からの要求を示す要求情報が通信部１３によって受信されたか否かを確認し、受信された要求情報がある場合は通信部１３から当該要求情報を受け取る。ステップＳ５１の次に、ステップＳ５２の処理が実行される。

0143

ステップＳ５２において、処理部１１は、端末装置２から個別購入要求があったか否かを判定する。すなわち、処理部１１は、ステップＳ５１で受信した要求情報が、個別購入指示を示す購入要求情報であるか否かを判定する。ステップＳ５２の判定処理の結果が肯定である場合、ステップＳ５３の処理が実行される。一方、ステップＳ５２の判定処理の結果が否定である場合、後述するステップＳ５７の処理が実行される。

0144

ステップＳ５３において、処理部１１は、個別購入に関する課金処理を実行する。すなわち、処理部１１は、まず、記憶部２２に記憶されている使用可否情報を参照して、端末装置２の現在の状態（初期状態、および、第１〜第６部分使用状態のいずれか）を特定する。例えば、使用可否情報が第１ステージのみ使用可能であることを示す場合、現在の状態は、第１部分使用状態であると特定することができる。なお、現在の状態を特定する処理は、購入対象となるコンテンツ（本実施形態においては、ステージ、または、バトルプレイを無制限に行う権利）を特定する処理であると言うことができる。

0145

次に、処理部１１は、記憶部２２に記憶されている料金情報を参照して、特定された現在の状態に対応する課金額を特定する。図１０より明らかなように、本実施形態においては、処理部１１は、現在の状態から一義的に、個別購入に対する課金額を特定することができる。続いて、処理部１１は、特定された課金額に応じた課金処理を実行する。具体的には、処理部１１は、記憶部２２に記憶されている残高情報が示す残高から、特定された課金額を減算し、減算後の残高を示すように残高情報を更新する。以上の処理によって、個別購入に対する課金および決済が行われたこととなる。ステップＳ５３の処理の次に、ステップＳ５４の処理が実行される。

0146

ステップＳ５４において、処理部１１は、使用可能に設定変更すべき１つのステージ（換言すれば、ステップＳ５３で特定されたステージ）について、記憶部２２に記憶されている使用可否情報を更新する。すなわち、処理部１１は、上記ステージが使用可能であることを示すように、使用可否情報を更新する。ステップＳ５４の処理の次に、ステップＳ５５の処理が実行される。

0147

ステップＳ５５において、処理部１１は、ユーザに対してバトルチケットを付与する。すなわち、処理部１１は、記憶部２２に記憶されているチケット数情報に対して、予め定められた所定数だけ加算し、加算後の数値を示すようにチケット数情報を更新する。ステップＳ５５の処理の次に、ステップＳ５６の処理が実行される。

0148

なお、ステップＳ５３において特定された現在の状態が第６部分使用状態である場合、ステップＳ５４において、処理部１１は、使用可否情報の更新を行わない。また、この場合、ステップＳ５５において、処理部１１は、記憶部２２に記憶されているバトル制限フラグ情報を、バトル制限フラグがオフであることを示すように、更新する。

0149

ステップＳ５６において、処理部１１は、使用可能に設定変更すべき１つのステージに関する追加ステージ情報を端末装置２へ送信する。すなわち、処理部１１は、記憶部２２に記憶されている各追加ステージ情報のうちで、上記ステージに対応する追加ステージ情報を、通信部１３を介して（換言すれば通信部１３を用いて）端末装置２へ送信する。上述したように、端末装置２は、サーバ１から送信された追加ステージ情報を受信して記憶部２２に記憶する（図１５に示すステップＳ４６）。上記ステップＳ５６の次に、ステップＳ５１の処理が再度実行される。

0150

なお、上記ステップＳ５６の処理において、処理部１１は、追加ステージ情報とともに、上記ステップＳ５３〜Ｓ５５の処理によって更新されたユーザ情報（具体的には、使用可否情報、バトル制限情報、および、残高情報）を、端末装置２へ送信する。上記ユーザ情報を受信した端末装置２の処理部２１は、受信したユーザ情報と同期するように、記憶部２２に記憶されているアプリケーション情報を更新する。これによって、サーバ１側と端末装置２側との間で情報の同期を取ることができる。

0151

以上のステップＳ５４〜Ｓ５６の一連の処理によって、個別購入に応じた設定変更処理（図５に示すステップＳ５、または、図８に示すステップＳ１４）が実行されたこととなる。

0152

一方、ステップＳ５７において、処理部１１は、端末装置２から一括購入要求があったか否かを判定する。すなわち、処理部１１は、ステップＳ５１で受信した要求情報が、一括購入指示を示す購入要求情報であるか否かを判定する。ステップＳ５７の判定処理の結果が肯定である場合、ステップＳ５８の処理が実行される。一方、ステップＳ５７の判定処理の結果が否定である場合、後述するステップＳ６２の処理が実行される。

0153

ステップＳ５８において、処理部１１は、一括購入に関する課金処理を実行する。すなわち、処理部１１は、まず、上記ステップＳ５３の処理と同様に、記憶部２２に記憶されている使用可否情報を参照して、端末装置２の現在の状態を特定する。次に、処理部１１は、記憶部２２に記憶されている料金情報を参照して、特定された現在の状態に対応する課金額を特定する。図１０より明らかなように、本実施形態においては、処理部１１は、現在の状態から一義的に、一括購入に対する課金額を特定することができる。続いて、処理部１１は、上記ステップＳ５３の処理と同様に、特定された課金額に応じた課金処理を実行する。すなわち、処理部１１は、記憶部２２に記憶されている残高情報の内容を課金額に応じて更新する。以上の処理によって、一括購入に対する課金および決済が行われたこととなる。ステップＳ５８の処理の次に、ステップＳ５９の処理が実行される。

0154

ステップＳ５９において、処理部１１は、使用可能に設定変更すべきステージについて、記憶部２２に記憶されている使用可否情報を更新する。すなわち、処理部１１は、各第１〜第６ステージについて使用可能であることを示すように、使用可否情報を更新する。ステップＳ５９の処理の次に、ステップＳ６０の処理が実行される。

0155

ステップＳ６０において、処理部１１は、バトル制限フラグをオフに設定する。すなわち、処理部１１は、記憶部２２に記憶されているバトル制限フラグ情報を、バトル制限フラグがオフであることを示すように、更新する。これによって、端末装置２が全使用状態となる。ステップＳ６０の処理の次に、ステップＳ６１の処理が実行される。

0156

ステップＳ６１において、処理部１１は、使用可能に設定変更される１以上のステージに関する追加ステージ情報を端末装置２へ送信する。ここで、追加ステージ情報が送信されるステージは、直前のステップＳ５９の処理において使用可否情報が、使用可能であることを示すように変更されたステージである。具体的には、処理部１１は、記憶部２２に記憶されている各追加ステージ情報のうちで、上記ステージに対応する追加ステージ情報を、通信部１３を介して端末装置２へ送信する。また、上記ステップＳ５６の処理と同様、処理部１１は、追加ステージ情報とともに、上記ステップＳ５８〜Ｓ６０の処理によって更新されたユーザ情報を端末装置２へ送信する。上述したように、端末装置２は、サーバ１から送信された追加ステージ情報を受信して記憶部２２に記憶する（図１５に示すステップＳ４６）。また、端末装置２は、受信したユーザ情報と同期するように、記憶部２２に記憶されているアプリケーション情報を更新する。上記ステップＳ６１の次に、ステップＳ５１の処理が再度実行される。

0157

なお、上記ステップＳ５９およびＳ６１における、ステージを使用可能とするための処理について、６つの各ステージについて処理を実行してもよいし、その時点で使用不可能であるステージについて処理を実行してもよい。すなわち、処理部１１は、６つの各ステージについて使用可否情報を更新して、当該各ステージに関する各追加ステージ情報を端末装置２へ送信してもよい。また、処理部１１は、６つの各ステージについて使用可能であるか否かをそれぞれ判定し、使用不可能であると判定されたステージについて使用可否情報を更新し、使用不可能であると判定されたステージに関する追加ステージ情報を端末装置２へ送信してもよい。

0158

以上のステップＳ５９〜Ｓ６１の一連の処理によって、一括購入に応じた設定変更処理（図５に示すステップＳ６、または、図８に示すステップＳ１５）が実行されたこととなる。

0159

なお、上記ステップＳ５３〜Ｓ５６の一連の処理、および、上記ステップＳ５８〜Ｓ６１の一連の処理においては、記憶部２２に記憶されるユーザ情報の内容（具体的には、使用可否情報、バトル制限情報、および、残高情報）が更新される。これらの一連の処理において更新されるユーザ情報は、ステップＳ５１で受信された要求情報が示す個別購入指示を行ったユーザ（すなわち、受信した要求情報に含まれるユーザ識別情報が示すユーザ）に関するユーザ情報である。

0160

ステップＳ６２において、処理部１１は、端末装置２からの要求（厳密には、上記購入要求以外の要求）に応じた処理を実行する。ステップＳ６２における処理の具体的な内容は任意である。例えば、端末装置２においてバトルプレイを開始する指示が行われた場合、端末装置２は、バトルプレイの要求をサーバ１に対して行う。バトルプレイの要求に応じて、処理部１１は、バトルの対戦相手を決定する処理を実行する。上記ステップＳ６２の次に、ステップＳ５１の処理が再度実行される。

0161

また、処理部１１は、上記ステップＳ５１〜Ｓ６２における一連の処理を繰り返し実行する。なお、サーバ１に複数の端末装置２からのアクセスがある場合、処理部１１は、上記一連の処理を、ユーザ毎（換言すれば、端末装置毎）に並行して実行する。

0162

［４．本実施形態における作用効果および変形例］
（１）
上記実施形態における情報処理システムは、複数のコンテンツ（例えば、ステージ）を含むゲームアプリケーションを実行するためのゲームシステムであり、以下の手段を備える。
・コンテンツがゲーム処理において使用可能か否かを示す使用可否情報（図１２）を複数のコンテンツのそれぞれに関連付けて記憶する記憶手段（例えば、記憶部１２）
・複数のコンテンツに含まれる一部のコンテンツを使用可能とするための第１処理（例えば、個別購入に対する課金処理。具体的には、ステップＳ５３）、または、複数のコンテンツに含まれる各コンテンツを使用可能とするための第２処理（例えば、一括購入に対する課金処理。具体的には、ステップＳ５８）を実行させるためのユーザの選択操作（例えば、購入画像において個別購入指示または一括購入指示を選択的に行う操作）を受け付ける受付手段（ステップＳ４１）
・ユーザの選択操作に基づいて第１処理または第２処理を実行するコンテンツ処理手段（ステップＳ５３およびＳ５８）
・第１処理の実行に応じて、一部の使用不可能なコンテンツに関連付けられた使用可否情報を、使用可能であることを示す情報に更新し（ステップＳ５４）、第２処理の実行に応じて、使用不可能な各コンテンツに関連付けられた使用可否情報を、使用可能であることを示す情報に更新する（ステップＳ５９）更新手段
・更新手段によって使用可否情報が使用可能であることを示す情報に更新されたコンテンツを用いてゲーム処理を実行するゲーム処理手段（ステップＳ２３）

0163

上記（１）の構成によれば、ユーザは、一部のコンテンツを使用可能とするための第１処理と、各コンテンツを使用可能とするための第２処理とを、選択的に行うことができる。したがって、ユーザは、上記第１処理の実行によって一部のコンテンツを使用可能とすることができるとともに、上記第２処理の実行によって当該複数のコンテンツをまとめて使用可能とすることができる。これによって、複数のコンテンツを取得する（換言すれば、コンテンツを使用する権利を取得する）方法の選択肢の幅が広がるので、コンテンツを取得する際のユーザにとっての利便性を向上することができる。

0164

上記「第１処理」および「第２処理」は、当該処理の実行に応じてコンテンツを使用可能とされる、任意の処理であってよい。上記「第１処理」および「第２処理」は、上記実施形態においては、コンテンツを使用可能とすることに対する料金を課金するための課金処理である。なお、課金処理は、ユーザに対して料金を課す処理であり、上記実施形態のように、ユーザの残高を減算する処理であってもよいし、料金を請求する通知をユーザに対して行う処理であってもよい。

0165

上記「コンテンツ」は、ゲームアプリケーションにおいて使用される任意のコンテンツであってよい。上記実施形態においては、コンテンツは、ゲームにおけるステージであるとしたが、これに限らない。例えば、他の実施形態においては、コンテンツは、ゲームにおいて用いられるオブジェクト（例えば、キャラクタまたはアイテム）であってもよい。つまり、ゲームシステムは、上記第１処理の実行に応じて、ゲームアプリケーションにおいて用いられる複数のオブジェクトのうちの一部のオブジェクトを使用可能とし、上記第２処理の実行に応じて、当該複数のオブジェクトを使用可能とするものであってもよい。

0166

上記「コンテンツを使用可能とする」とは、コンテンツを使用する権利をユーザに付与することを意味する。例えば下記の具体的な処理によって、当該権利をユーザに付与することができる。
・端末装置２にコンテンツのデータ（上記基本ステージ情報の一例と言える）が記憶されている場合、鍵情報（上記追加ステージ情報の一例と言える）をサーバ１から取得する処理
・端末装置２にコンテンツのデータの一部（上記基本ステージ情報の一例と言える）が記憶されている場合、コンテンツの残りのデータ（上記追加ステージ情報の一例と言える）をサーバ１から取得する処理
・（端末装置２にコンテンツのデータが記憶されていない場合において）端末装置２がコンテンツ全体のデータをサーバ１から取得する処理

0167

（２）
上記実施形態においては、更新手段は、第１処理の実行に応じて使用可否情報を更新した後で第２処理の実行に応じて使用可否情報を更新する場合、複数のコンテンツのうちで、当該第１処理に応じて使用可否情報が更新されたコンテンツを除くコンテンツに関連付けられた使用可否情報を更新する（ステップＳ５９）。

0168

上記（２）の構成によれば、使用可否情報の更新を効率良く行うことができる。

0169

（３）
上記実施形態においては、更新手段は、第２処理の実行に応じて、複数のコンテンツのうちで使用不可能な全てのコンテンツに関連付けられた使用可否情報を、使用可能であることを示す情報に更新する（ステップＳ５９）。

0170

上記（３）の構成によれば、使用可否情報の更新を効率良く行うことができる。

0171

（４）
上記実施形態においては、受付手段は、第１処理を表す第１画像（例えば、個別購入指示画像４２）と共に、第２処理を表す第２画像（例えば、一括購入指示画像４３）を提示する。コンテンツ処理手段は、第１画像を選択する操作に応じて第１処理を実行し、第２画像を選択する操作に応じて第２処理を実行する。

0172

上記（４）の構成によれば、第１画像および第２画像がユーザに提示されることによって、第１処理と第２処理との両方が実行可能であることをユーザにわかりやすく通知することができる。また、ユーザは選択操作を容易に行うことができる。

0173

（５）
なお、上記“（一括購入のタイミングに関する変形例）”にて述べたように、受付手段は、第１処理が実行されたことに応じて複数のコンテンツのうちの所定の一部のコンテンツが使用可能となった場合（例えば、第１ステージが使用可能となった場合）、第１処理を実行するための操作を受け付けない状態で、第２処理を実行するための操作を受け付けてもよい。

0174

上記（５）の構成によれば、所定の一部のコンテンツが使用可能となるまでは、コンテンツの取得に関してユーザに複数の選択肢を提示することができるとともに、所定の一部のコンテンツが使用可能となった後は、上記複数のコンテンツ全ての取得を促進することができる。

0175

（６）
また、上記実施形態のように、記憶手段は、複数のコンテンツについて設定される順序を示す情報を記憶してもよい。このとき、上記実施形態のように、更新手段は、１回の第１処理の実行に応じて、複数のコンテンツのうちで使用不可能なコンテンツであって、順序に従って特定される１つのコンテンツに関連付けられる使用可否情報を、使用可能であることを示す情報に更新してもよい。さらに、上記“（一括購入のタイミングに関する変形例）”にて述べたように、受付手段は、複数のコンテンツのうちで、上記順序に従って所定の一部のコンテンツが使用可能となった後（例えば、第１ステージが使用可能となった後）は、第１処理を実行するための操作を受け付けない状態で、第２処理を実行するための操作を受け付けてもよい。

0176

なお、上記「複数のコンテンツについて設定される順序」は、上記実施形態においては、ゲームの進行順、換言すれば、コンテンツが用いられる順序である。ただし、複数のコンテンツについて設定される順序は、任意の順序であってよく、例えば、複数のコンテンツがユーザに提供された時期が異なる場合には、ユーザに対して提供された順序であってもよい。

0177

上記（６）の構成によれば、ユーザは、第１処理の実行の際に、使用可能とするコンテンツを特定する必要がないので、ユーザによる選択操作を容易にすることができる。また、上記順序に従って上記所定の一部のコンテンツが使用可能となった後は、上記複数のコンテンツ全ての取得を促進することができる。

0178

（７）
上記“（一括購入のタイミングに関する変形例）”にて述べたように、ゲーム処理手段は、所定の一部のコンテンツ（例えば、第１ステージ）に関連付けられる使用可否情報が使用不可能であることを示す場合、当該コンテンツを、制限を加えた状態で用いてゲーム処理を実行してもよい。なお、ゲーム処理手段は、複数のコンテンツのうち、上記所定の一部のコンテンツを除くコンテンツについては、制限が加えられた状態で当該コンテンツを用いるゲーム処理を実行しなくてもよい。

0179

上記「制限を加えた状態でコンテンツを用いる」とは、例えば上述した試用プレイのように、使用可能である状態のコンテンツが用いられる場合に対して何らかの制限が加えられた状態でコンテンツを用いることを指す。例えば、上記実施形態においては、コンテンツの一部（のみ）を用いてゲーム処理を実行する態様、あるいは、コンテンツを一時的に用いて（例えば、所定時間だけ）ゲーム処理を実行する態様で、ゲーム処理が実行されてもよい。

0180

上記（７）の構成によれば、ユーザは、使用可否情報が使用不可能であることを示すコンテンツについても、制限的ではあるものの当該コンテンツを使用することができる。これによって、制限が無い状態でコンテンツを使用する動機付けをユーザに与えることができる。また、第１処理の実行に応じて使用可能とすることができるコンテンツ以外の残りのコンテンツ（すなわち、上記所定の一部のコンテンツ以外のコンテンツ）について制限的な使用を不可能とすることによって、当該残りのコンテンツを取得する動機付けをユーザに与えることができる。

0181

（８）
上記実施形態においては、受付手段は、複数のコンテンツが使用不可能である初期状態において選択操作を受け付けるとともに、第１処理の実行によって複数のコンテンツの一部が使用可能となった一部使用可能状態（例えば、第１〜第６部分使用状態）において選択操作を受け付ける（図４）。

0182

上記（８）の構成によれば、ユーザは、初期状態と一部使用可能状態との両方において選択操作を行うことができるので、コンテンツ取得に関するユーザにとっての利便性を向上することができる。

0183

（９）
上記実施形態においては、受付手段は、初期状態において、第１処理を表す第１画像（例えば、個別購入指示画像４２）と共に、第２処理を表す第２画像（例えば、一括購入指示画像４３）を提示し、一部使用可能状態において第１画像と共に第２画像を提示する。コンテンツ処理手段は、第１画像を選択する操作に応じて第１処理を実行し、第２画像を選択する操作に応じて第２処理を実行する。

0184

上記（９）の構成によれば、初期状態と一部使用可能状態との両方において第１画像および第２画像がユーザ提示されるので、第１処理と第２処理との両方が実行可能であることをユーザにわかりやすく通知することができる。また、ユーザは選択操作を容易に行うことができる。

0185

（１０）
上記実施形態においては、コンテンツ処理手段は、第１処理および第２処理として、コンテンツを使用可能とすることに対する対価（例えば、料金）を取得する取得処理（例えば課金処理）を実行する。

0186

上記（１０）の構成によれば、対価と引き替えにコンテンツを取得することが可能なゲームアプリケーションにおいて、複数のコンテンツを取得する際の利便性を向上することができる。

0187

（１１）
上記実施形態においては、コンテンツ処理手段は、第１処理および第２処理として、コンテンツを使用可能とすることに対する対価（すなわち、料金）を取得する取得処理（すなわち、課金処理）を実行する。ここで、第１〜第３の対価を次のように定義する。
・第１の対価：初期状態において実行される第２処理において取得する対価（図１０および図１１に示す例では、３０００円）
・第２の対価：初期状態から実行される所定回数の第１処理において取得する対価の合計（例えば所定回数を２回とした場合、図１０および図１１に示す例では、２００円と５００円の合計、すなわち、７００円）
・第３の対価：当該所定回数の第１処理の実行によって生じた一部使用可能状態（例えば所定回数を２回とした場合、第２部分使用状態）において実行される第２処理において取得する対価（例えば所定回数を２回とした場合、図１０および図１１に示す例では、２５００円）
このとき、コンテンツ処理手段は、第１の対価（上記の例では、３０００円）を、第２の対価と第３の対価との和（上記の例では、３２００円）よりも小さくする。

0188

上記（１１）の構成によれば、第１処理が実行されない初期状態で第２処理が実行された場合の方が、第１処理が実行された後で第２処理が実行された場合よりも、各コンテンツを使用可能とするための対価が小さくなる。これによれば、初期状態で各コンテンツを使用可能とする動機付けをユーザに与えることができる。

0189

（１２）
また、第４および第５の対価を次のように定義する。
・第４の対価：初期状態から第１の回数だけ第１処理が実行されたことによって生じた一部使用可能状態において実行される第２処理において取得する対価（例えば第１の回数を２回とした場合、図１０および図１１に示す例では、２５００円）
・第５の対価：初期状態から第１の回数よりも多い第２の回数だけ第１処理が実行されたことによって生じた一部使用可能状態において実行される第２処理において取得する対価（例えば第２の回数を３回とした場合、図１０および図１１に示す例では、２１００円）
上記実施形態においては、コンテンツ処理手段は、第５の対価を、第４の対価よりも小さくする。

0190

上記（１２）の構成によれば、第１処理を多くの回数実行した場合における、第２処理の対価（すなわち、第５の対価）は、第１処理を少ない回数実行した場合における、第２処理の対価（すなわち、第４の対価）よりも、小さくなる。これによれば、第１処理を多くの回数実行した状態においても、第２処理の実行によって各コンテンツを使用可能とする動機付けをユーザに与えることができる。

0191

（１３）
上記実施形態においては、コンテンツ処理手段は、取得処理として、ゲームアプリケーション内においてユーザが所有するポイントを減少させる処理、または、使用可能とされるコンテンツに応じた料金を課金する処理を実行してもよい。つまり、上記「対価」は、現実の通貨であってもよいし、例えばゲームアプリケーション内で利用可能なポイント（換言すれば、仮想通貨）であってもよい。なお、上記ポイントは、現実の通貨と交換可能であってもよく、例えば、宝石のような有料アイテムの数として表現されてもよい。このように、コンテンツは、現実の通貨と直接交換されるのではなく、有料アイテムを介して間接的に現実の通貨と交換されてもよい。

0192

（１４）
本実施形態においては、記憶手段は、複数のコンテンツについて設定される順序を特定可能な情報を記憶している。更新手段は、複数のコンテンツのうちで使用不可能なコンテンツに関連付けられる使用可否情報を、第１処理が実行される毎に順序に従って１つずつ、使用可能であることを示す情報に更新する（図４）。

0193

上記（１４）の構成によれば、ユーザは、第１処理の実行の際に、使用可能とするコンテンツを特定する必要がないので、ユーザによる選択操作を容易にすることができる。

0194

（１５）
なお、他の実施形態においては、受付手段は、第１処理を選択する選択操作が行われる場合、複数のコンテンツのうちで使用可能とするコンテンツを指定するためのユーザの指定操作を受け付けてもよい。この指定操作は、例えば、上記実施形態におけるステージモード画像に対して、使用可能とするステージを指定する操作であってもよい。更新手段は、第１処理の実行に応じて、指定操作によって指定されたコンテンツに関連付けられる使用可否情報を、使用可能であることを示す情報に更新してもよい。

0195

上記（１５）の構成によれば、ユーザは、使用可能とするコンテンツを指定することができるので、より多くのバリエーションでコンテンツを取得することができる。

0196

（１６）
上記実施形態においては、ゲーム処理手段は、所定のコンテンツについて、当該所定のコンテンツに関連付けられる使用可否情報が使用不可能であることを示す場合、当該所定のコンテンツを、制限を加えた状態で用いてゲーム処理を実行する。

0197

上記（１６）の構成によれば、ユーザは、使用可否情報が使用不可能であることを示すコンテンツについても、制限的ではあるものの当該コンテンツを使用することができる。これによって、制限が無い状態でコンテンツを使用する動機付けをユーザに与えることができる。

0198

（１７）
上記実施形態においては、ゲームシステムは、ユーザによって操作される端末装置２と、サーバ１とを含む（図１）。ゲームシステムは、サーバ１に設けられるデータ送信手段（例えば、ステップＳ５６およびＳ６１を実行する処理部１１および／または通信部１３）を備える。データ送信手段は、第１処理または第２処理によって使用可否情報が更新されたことを条件として、当該条件を満たしたコンテンツを端末装置２において使用可能とするためのデータ（例えば、追加ステージ情報）を当該端末装置２へ送信する。ゲーム処理手段は、端末装置２に設けられ、サーバ１から受信されたデータに基づいてゲーム処理を実行する（ステップＳ２３，Ｓ４６）。

0199

上記「コンテンツを端末装置２において使用可能とするためのデータ」は、上記実施形態における追加ステージ情報のデータに限らず、他のデータであってもよい。例えば、上記実施形態の変形例においては、「コンテンツを端末装置２において使用可能とするためのデータ」は、１つのステージに関するステージ情報全体（すなわち、基本ステージ情報および追加ステージ情報）のデータであってもよい。つまり、ステージの購入が行われるまでは端末装置２には当該ステージに関する情報が記憶されておらず、当該ステージの購入が行われたことに応じて、当該ステージに関する情報（すなわち、基本ステージ情報および追加ステージ情報）がサーバ１から端末装置２へ送信されて端末装置２に記憶されてもよい。

0200

上記（１７）の構成によれば、使用可否情報が更新される前において不正にコンテンツが使用される可能性を低減することができる。

0201

（１８）
上記実施形態においては、コンテンツは、ゲームにおけるステージのデータである。ゲーム処理手段は、更新手段によって使用可否情報が使用可能であることを示す情報に更新されたステージのデータを用いたゲーム処理を実行する。

0202

上記（１８）の構成によれば、複数のステージを含むゲームのゲームアプリケーションにおいて、複数のステージを使用可能とする際の利便性を向上することができる。

0203

（付与される他の種類のコンテンツに関する変形例）
上記実施形態においては、サーバ１は、コンテンツ（すなわち、ステージ）を使用可能とすることに応じて、当該コンテンツとは異なる他の種類のコンテンツ（すなわち、バトルチケット）を付与する処理を実行した（ステップＳ５５）。ここで、上記他の種類のコンテンツの内容は任意である。例えば、他の実施形態においては、バトルチケットに代えて（または、バトルチケットと共に）、キャラクタが付与されてもよい。具体的には、サーバ１は、購入に応じてステージを使用可能とした場合、ユーザが使用可能なキャラクタの種類を増加させるようにゲームの設定を変更してもよい。

0204

また、上記他の種類のコンテンツは、購入以外の方法で取得可能であってもよい。例えば、他の種類のコンテンツは、ゲームに関する所定の条件（例えば、バトルプレイで所定回数勝利したこと、ステージをクリアしたこと、または、ゲームに関するアカウントを登録したこと等）が満たされたことに応じて、所定数のバトルチケットがユーザに付与されてもよい。また、上記他の種類のコンテンツは、購入されるコンテンツ（すなわち、ステージ）とは別に購入することが可能であってもよい。例えば、上記実施形態においては、ステージの購入によってバトルチケットがユーザに付与される一方、ユーザはバトルチケットを単独で（つまり、ステージとは別に）購入することが可能であってもよい。

0205

なお、上記実施形態においては、ステージは、購入以外の方法では使用可能とすることはできないが、他の実施形態においては、ゲームに関する所定の条件が満たされたことに応じて、ステージが使用可能とされてもよい。

0206

（試用プレイに関する変形例）
上記実施形態においては、ゲームアプリケーションに含まれる６つのステージは、それぞれ有料コンテンツであった。ここで、他の実施形態においては、ゲームアプリケーションは、有料コンテンツと同種のコンテンツであって、無料のコンテンツを含んでいてもよい。つまり、ゲームアプリケーションは、上述の第１処理および第２処理の実行を条件とせずに使用可能なコンテンツを含んでいてもよい。例えば、上記実施形態において、ゲームアプリケーションは、初期状態においてユーザがプレイ可能な、チュートリアル用のステージを含んでいてもよい。以上より、上記「第２処理」は、ゲームアプリケーションに含まれる全てのコンテンツを使用可能とする処理でなくてもよい。

0207

（ゲームアプリケーションにコンテンツが追加される変形例）
なお、他の実施形態においては、端末装置２にゲームアプリケーションがインストールされた後で、例えばゲームアプリケーションのアップデートによって、当該ゲームアプリケーションに追加コンテンツ（例えば、追加ステージ）が導入されてもよい。この場合、追加ステージの導入前にすでに一括購入を行っていたユーザに対しては、追加コンテンツが無料で提供されてもよいし、有料で提供されてもよい。すなわち、サーバ１は、追加ステージの導入前に全使用状態となっていた端末装置２のゲームアプリケーションにおいては、さらなる購入指示が無くても当該追加ステージを使用可能としてもよいし、追加ステージの購入指示に応じて当該追加ステージを使用可能としてもよい。以上より、上記「第２処理」は、第２処理が実行される時点でゲームアプリケーションに含まれていないコンテンツを使用可能とする処理でなくてもよい。

0208

（ゲームアプリケーションの種類に関する変形例）
上記実施形態において、ゲームシステムにおいて実行されるゲームアプリケーションの種類は任意である。また、ゲームアプリケーションに含まれるゲームモードについても任意であり、ゲームアプリケーションは、上記実施形態におけるステージモードおよびバトルモードに限らず、１以上の任意のモードを含んでいてもよい。つまり、購入対象となるコンテンツは、上記実施形態においてはステージモードにおけるステージであったが、他の実施形態においては、ステージモードとは異なる他の任意のモードにおいて用いられるコンテンツであってもよい。

0209

（サーバと端末装置とにおける処理に関する変形例）
他の実施形態においては、上記実施形態においてサーバ側において実行された処理の一部は、端末装置側において実行されてもよい。また、他の実施形態においては、上記実施形態において端末装置側において実行された処理の一部は、サーバ側において実行されてもよい。

0210

以上のように、上記実施形態は、端末装置において複数のコンテンツを取得する際の利便性を向上すること等を目的として、例えばゲームシステムに利用することができる。

0211

１サーバ
２端末装置
１１ 処理部
１２ 記憶部
２１ 処理部
２２ 記憶部
２３ 入力部
２４ 表示部
３１ステージ構成画像
４１試用指示画像
４２ 個別購入指示画像
４３一括購入指示画像