JP6194534B2 - 情報処理装置、プログラム - Google Patents

Description

本発明は、オブジェクトについての情報を処理する情報処理技術に関する。

近年、ソーシャルネットワーキングサービス（ＳＮＳ）において実行されるアプリケーションとして、いわゆるソーシャルゲーム（Social Game）が普及している。このようなソーシャルゲームとして、カードを利用したデジタルカードゲームが知られている。
また、ユーザの所有カードの中からメインカードとサブカードがユーザに選択され、メインカードとサブカードを合成処理することによって、メインカードの能力パラメータを変更するとともに、サブカードをユーザの所有カードから削除するようにしたゲームが知られている（特許文献１、２）。

特許５０８６４９１号公報 特許５１５３９６０号公報

合成処理では、ベースオブジェクト（上記メインカードに相当）の合成処理を実現するために、ベースオブジェクトに対応する組合せ条件を満たす複数の参照オブジェクト（上記サブカードに相当）をユーザが所持していることが要件となる場合がある。その場合、ユーザは合成処理を実行するために、組合せ条件を満たすすべての参照オブジェクトを所持する必要がある。

このとき、ユーザが所持していない参照オブジェクトの入手が、当該ユーザにとって不可能または困難である場合がある。しかし、当該参照オブジェクトの入手条件を知らないユーザは、当該参照オブジェクトの入手が不可能または困難であることを、当該参照オブジェクトを入手するための処理を実行するか否かを決断する時点で認識できない。このような場合、ユーザは、実際には参照オジェクトの入手が不可能または困難かもしれないという不安を抱えたまま、当該参照オブジェクトを入手するための処理を実行することになる。

本発明は上述した観点に鑑みてなされたものであり、その目的は、少なくとも複数のオブジェクトを示す情報を含む変化条件を満たした場合に実行される、オブジェクトを変化させる処理に必要な参照オブジェクトを入手するための処理においてユーザが感じる不安を解消するようにした情報処理装置、プログラム、情報処理システムを提供することである。

本発明の一態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データを出力する出力手段と、
前記出力手段により前記第１出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段と、を備え、
前記出力手段は、さらに、前記受付手段により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第２出力データを出力する、
情報処理装置である。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトと、前記複数のオブジェクトのうちユーザが所持していないオブジェクトの入手条件と、をユーザにそれぞれ識別可能な表示形式で表示させるための出力データを出力する出力手段
を備える、情報処理装置である。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データを出力する出力手段と、
前記出力手段により前記第１出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段と、を備え、
前記出力手段は、さらに、前記受付手段により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持したことがない場合、当該指定オブジェクトの入手難易度を表示させるための第２出力データを出力する、
情報処理装置である。

本発明の別の態様は、
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理システムであって、
前記ユーザ端末、および、前記サーバのいずれかが、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データを出力する出力手段と、
前記出力手段により前記第１出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段と、を備え、
前記出力手段は、さらに、前記受付手段により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第２出力データを出力する、
情報処理システムである。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータを、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データを出力する手段、
前記第１出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける手段、
前記受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第２出力データを出力する手段、
として機能させるためのプログラムである。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第１出力データを出力する第１出力手段と、
前記第１出力手段により前記第１出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第１指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第１受付手段と、
前記第１受付手段により前記要求が受け付けられたことに応じて、前記第１指定オブジェクトに対して、前記処理に用いられることを制限する第１制限手段と、
を備える、情報処理装置である。

本発明の別の態様は、
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理システムであって、
前記ユーザ端末、および、前記サーバのいずれかが、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第１出力データを出力する第１出力手段と、
前記第１出力手段により前記第１出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第１指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第１受付手段と、
前記第１受付手段により前記要求が受け付けられたことに応じて、前記第１指定オブジェクトに対して、前記処理に用いられることを制限する第１制限手段と、
を備える、情報処理システムである。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータを、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第１出力データを出力する手段、
前記第１出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第１指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける手段、
前記要求が受け付けられたことに応じて、前記第１指定オブジェクトに対して、前記処理に用いられることを制限する手段、
として機能させる、プログラムである。

第１の実施形態のゲームシステムの基本構成を示す図。 第１の実施形態のユーザ端末の構成を示すブロック図。 第１の実施形態のゲームサーバの構成を示すブロック図。 第１の実施形態の参照カードの入手条件の提示を概念的に説明するための図。 第１の実施形態のカードデータテーブルの構成例を示す図。 第１の実施形態の進化合成データテーブルの構成例を示す図。 第１の実施形態のクエストデータテーブルの構成例を示す図。 第１の実施形態の所持カードデータテーブルの構成例を示す図。 第１の実施形態の予約データテーブルの構成例を示す図。 第１の実施形態の所持履歴データテーブルの構成例を示す図。 第１の実施形態のカード流通データテーブルの構成例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第１の実施形態のゲームサーバの機能ブロック図。 第１の実施形態の入手条件の提示処理の一例を示すシーケンスチャート。 第１の実施形態の入手条件の提示処理の一例を示すシーケンスチャート。 第１の実施形態の進化合成処理の一例を示すシーケンスチャート。 第２の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第２の実施形態のクエスト処理の一例を示すシーケンスチャート。 第３の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第３の実施形態の進化合成の予約処理の一例を示すシーケンスチャート。 第４の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第４の実施形態の入手条件の提示処理の一例を示すシーケンスチャート。 第５の実施形態の参照カードの予約登録およびお気に入り登録を概念的に説明するための図。 第５の実施形態の所持カードデータテーブルの構成例を示す図。 第５の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第５の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第５の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第５の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。 第５の実施形態の登録の処理の一例を示すシーケンスチャート。 第６の実施形態の入手条件の提示処理の一例を示すシーケンスチャート。 第６の実施形態の入手条件の提示処理の一例を示すシーケンスチャート。

（１）第１の実施形態
（１−１）ゲームシステムの構成
以下、情報処理システムの一実施形態として、ゲームシステム１について説明する。

図１は、実施形態のゲームシステム１のシステム構成例を示している。図１に示すように、このゲームシステム１は、ユーザ端末１０ａ，１０ｂ，１０ｃ，…、および、ゲームサーバ２０を含む。各ユーザ端末１０ａ，１０ｂ，１０ｃからゲームサーバ２０に対しては、例えばインターネットなどの通信網ＮＷを通してアクセス可能である。ゲームサーバ２０は、情報処理装置の一例である。
各ユーザ端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、フィーチャーフォン、スマートフォン、タブレット端末、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）、通信機能付き携帯ゲーム機などの通信端末である。以下の説明において、各ユーザ端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、ユーザ端末１０と表記する。

ゲームサーバ２０は、ゲームを実行するサーバである。ゲームサーバ２０には、ウェブブラウザによって解釈可能な画像データ（例えばＨＴＭＬ、ＸＭＬなどの形式で記述された画像データのことである。本発明の実施形態では、ＨＴＭＬデータを例として説明する。）を作成可能なプログラムが実装されている。
ユーザ端末１０は、ゲームサーバ２０によって提供されるＨＴＭＬデータを解釈して表示するウェブブラウザを備えており、ユーザ端末１０によるウェブページ上のユーザの操作に基づく要求を、ネットワークを介してゲームサーバ２０へ送信し、ゲームサーバ２０による処理結果を受信することでゲームの処理を実行する。
通信網ＮＷは、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、専用回線、または、これらの組み合わせによって構成される情報通信ネットワークである。

（１−２）ユーザ端末の構成
図２を参照してユーザ端末１０について説明する。
図２に示すように、ユーザ端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、操作入力部１５、表示部１６、通信インタフェース部１７、および、ストレージ１８を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１９が設けられている。

ＣＰＵ１１は、ＲＯＭ１２に格納されているプログラムやデータを読み出して、ユーザ端末１０内の各部との制御信号やデータ信号のタイミング処理等、ユーザ端末１０内の全体の動作を制御する。ＣＰＵ１１はまた、ストレージ１８に記憶されているプログラムや、プログラムの実行に必要な各種データを読み出してＲＡＭ１３に展開し、プログラムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。ＲＡＭ１３は、ＣＰＵ１１による演算処理、判定処理等のために一時的にデータを記憶する。

例えば、ＣＰＵ１１は、ストレージ１８内に格納されているウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、操作入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を、通信インタフェース部１７を介して取得し、ウェブブラウザを実行してＨＴＭＬデータを解釈する。なお、ユーザ端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてもよい。そのようなプラグインの一例は、米国のアドビシステムズ社によるフラッシュプレイヤである。あるいは、本実施形態でのＨＴＭＬデータを、動画および音声の再生機能を備えたＨＴＭＬ５形式としてもよい。

ウェブブラウザは、ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、ユーザによる操作入力部１５の操作によってウェブページ上のＵＲＬ(Uniform Resource Locator)または操作対象（例えば、ソフトウェアボタン（以下、単に「ボタン」と表記する。）等）が選択されると、ウェブページの更新のために、その選択結果を含むＨＴＴＰリクエストをゲームサーバ２０に送信する。ウェブブラウザは、ＨＴＴＰレスポンスとしてゲームサーバ２０からＨＴＭＬデータを取得し、解釈して、ウェブページを表示部１６に表示する。

表示部１６は、たとえば、ＬＣＤ(Liquid Cristal Display)や有機ＥＬ(Electro Luminescence)ディスプレイ等の表示デバイスである。マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタを適用した場合、表示部１６は、薄膜トランジスタを駆動することでウェブページの画像を表示画面に表示する。

ユーザ端末１０が釦入力方式のユーザ端末である場合、操作入力部１５は、例えば、ユーザの操作入力を受け入れるための方向指示釦、決定釦、テンキーなどの複数の指示入力釦を備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。
ユーザ端末１０がタッチパネル入力方式のユーザ端末である場合、操作入力部１５は、主として表示画面に指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。

ストレージ１８は、例えばフラッシュメモリあるいはＨＤＤ(Hard Disk Drive)によって構成される記憶装置である。

（１−３）ゲームサーバの構成
図３を参照してゲームサーバ２０の構成について説明する。
図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、通信インタフェース部２４、および、ストレージ２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のネットワークサーバと同一の構成をとることができる。

ＣＰＵ２１は、ＲＯＭ２２に格納されているプログラムやデータを読み出して、ゲームサーバ２０内の各部との制御信号やデータ信号のタイミング処理等、ゲームサーバ２０内の全体の動作を制御する。ＣＰＵ２１はまた、ストレージ２５に記憶されているプログラムや、プログラムの実行に必要な各種データを読み出してＲＡＭ２３に展開し、プログラムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。ＲＡＭ２３は、ＣＰＵ２１による演算処理、判定処理等のために一時的にデータを記憶する。

例えば、ストレージ２５には、クライアントであるユーザ端末１０のウェブブラウザとの間でＨＴＴＰに従った通信を行ってウェブサービスを提供するプログラムが格納されている。ＣＰＵ２１は、ストレージ２５に格納されているプログラムをＲＡＭ２３に展開して、プログラムを実行する。プログラムの実行に伴ってＣＰＵ２１は、通信インタフェース部２４を介してユーザ端末１０からＨＴＴＰリクエストを取得し、当該ＨＴＴＰリクエストに応じた処理を実行し、その実行結果を含むＨＴＭＬデータ（後述する画像データの一例）をＨＴＴＰレスポンスとしてユーザ端末１０へ返す。

ストレージ２５は、例えばフラッシュメモリあるいはＨＤＤ(Hard Disk Drive)によって構成される情報記録装置であり、上述したプログラムに加え、データテーブル群７０を格納する。データテーブル群７０（後述する）は、カードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、予約データテーブル、所持履歴データテーブル、および、カード流通データテーブルを含む。各データテーブルは、適宜ＣＰＵ２１からデータの読み書きのためにアクセスされる。

（１−４）本実施形態のゲームのカードの入手条件の提示
本実施形態のゲームシステム１において実行されるゲームは、ユーザがオブジェクトとしてのカードを利用して実行するゲームである。このゲームでは、例えば、ユーザがゲーム上のエリアを探索してカードやアイテムを取得し、あるいはユーザが所持するカードを用いて他のユーザやＮＰＣ(Non-Player Character)と対戦するゲームである。
本実施形態のゲームにおいて、カードの進化合成処理（以下、適宜単に「進化合成」という。）とは、所定の条件を満足する場合に、ユーザが所持するカードを進化させる処理である。カードの進化合成は、本実施形態の例では後述するようにカードＩＤを変更する処理であるが、カードに対応するカードデータ（後述する）の少なくとも一部を変更する処理であってもよい。その場合、カードデータの変更対象は特に問わないが、例えば、カード名やカード画像、レアリティ等のカードパラメータである。カードの進化合成は、オブジェクトを変化させる処理の一例である。
進化合成を実行するには、ユーザは自身が所持するカード（以下、適宜「所持カード」という。）の中から、進化させたいカード（つまり、カードデータを変化させる処理の対象とするカード）としてベースカードを選択する。ベースカードとして選択されたカードは、選択オブジェクトの一例である。
進化合成では、ベースカードごとに、そのベースカードを進化させるのに必要な複数のカード（「参照カード」という。）の組合せ条件が決められている。進化合成が実行されると、その進化合成に使用された参照カードはユーザの所持カードから消失する。
本実施形態のゲームでは、ユーザによってベースカードとして選択されたカードに対応する組合せ条件となる複数の参照カードのすべてをユーザが所持していることが、選択されたカードを進化させるための条件（変化条件の一例）である。

なお、本実施形態のゲームでは、ユーザが自身の所持カードを失う処理として、例えば、通常合成処理と売却処理が設けられる。通常合成処理を実行するには、ユーザは自身の所持カードの中から、成長させたいカードとしてベースカードを選択する。通常合成処理では、カードを変化させる処理（例えば、進化合成処理）を行うための条件が定義された変化条件がベースカードごとに決められておらず、ユーザは適宜参照カードを所持カードの中から選択することができる。通常合成処理が実行されると、ベースカードのカードパラメータが変化する（例えば、カードレベルやスキルレベルが増加する）代わりに、参照カードはユーザの所持カードから消失する。
売却処理では、ユーザの所持カードの中から選択されたカード（例えば、ユーザが不要とするカード）を、そのカードに対応する売却価格（例えば、ゲーム上のポイント）をユーザが得る代わりに、売却したカードはユーザの所持カードから消失する。

本実施形態のゲームにおいて、ユーザが所望のカードを進化合成によって進化させたいが当該カードを進化させるのに必要な参照カードの一部、あるいはすべてをユーザが所持していない場合を考える。この場合、参照カードの組合せの条件を満たすための新しいカード（つまり、残りの参照カード）をユーザが入手できるまで所望のカードの進化合成を実行することを待機する必要がある。しかし、ユーザが、残りの参照カードを入手するための条件（以下「入手条件」という）を忘れてしまった場合、当該参照カードの入手は難しくなる。特に、入手したカードの数が多くなればなるほど、カード毎の入手条件を忘れてしまう可能性が高くなる。
そこで、本実施形態では、ベースカードを進化させるのに必要となる複数の参照カードのうち、ユーザが所持していない参照カード（未所持カードまたは未知カード）の入手条件を提示できるようにする。なお、未所持カードとは、ユーザにより所持されたことがあり、かつ、ベースカードを選択した時点でユーザが所持していないカードである。一方、未知カードとは、ユーザにより所持されたことがないカードである。

参照カードの入手条件の提示について、図４を参照して具体的に説明する。図４は、参照カードの入手条件の提示を概念的に説明するための図である。
図４において、ユーザが自身の所持カードであるカードＱを進化させたい場合を考える。ここでは、カードＱを進化させるために、複数の参照カードとしてのカードＡ，Ｂ，Ｃの組合せが必要となる場合を想定する。ユーザは現時点でカードＢを所持していないため、カードＱに対して進化合成を実行することはできない。また、ユーザは、カードＢの入手条件を忘れてしまったため、カードＢを入手することも難しい。その場合に、本実施形態では、ユーザがカードＢを容易に入手できるように、カードＢの入手条件の提示の要求に応じて、カードＢの入手条件がユーザに提示される。その結果、ユーザは、カードＢを容易に入手できる。

（１−５）データテーブルの構成
次に、ゲームサーバ２０のストレージ２５に格納されるカードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、予約データテーブル、所持履歴データテーブル、および、カード流通データテーブルについて、図５〜１１を参照して順に説明する。

（i）カードデータテーブル
カードデータテーブルには、本実施形態のゲームで使用されるカードのデータが記録されている。図５にカードデータテーブルの構成例を示す。図５に示す例では、カードＩＤごとにカード名、カード画像、および、カードパラメータのデータが含まれる。
カードＩＤは、オブジェクトの一例であるカードを特定する識別情報である。カードＩＤは、カードごとに一意に付される。カードＩＤによって、複数のカードの中から１つのカードが特定される。つまり、カードＩＤは、オブジェクトを特定するオブジェクト識別情報の一例である。
カード名は、カードに表示されるキャラクタの名称を示す文字列である。カード画像は、カードに表示されるキャラクタの画像である。カードパラメータは、レアリティ、属性、コスト、スキル、売却価格、攻撃力、防御力、および、限定フラグの各データから構成されている。
レアリティは、カードの希少価値を示す指標であり、図５に示す例ではＲ１〜Ｒ５の順にレアリティが高く設定されている。
属性は、カードに表示されるキャラクタの属性であり、図５に示す例ではＮ１〜Ｎ３のいずれかである。
コストは、カードをユーザのカードチームに組み込むときに参照される値である。例えばカードチームによる対戦を行う場合には、カードチームに含まれるカードのコストの総和が所定値以下に制限される。
スキルは、カードを用いてゲームを実行するときに有利となる効果を示す情報であり、図４に示す例では、ＳＫ１〜ＳＫ１２の様々な効果を備えたスキルが各カードに設定されている。なお、すべてのカードがスキルを備えていなくてもよい。
売却価格は、ユーザが自身で所持しているカードを売却するときにユーザが得られるゲーム上のポイントである。
攻撃力および防御力は、カードを対戦で用いるときに参照されるパラメータである。
限定フラグは、期間限定で発行されたカードであるか否かを示すフラグである。図４に示す例では、限定フラグが「１」であるカードは期間限定で発行されたカードであることを意味し、限定フラグが「０」であるカードは期間限定でないカードであることを意味する。

（ii）進化合成データテーブル
進化合成データテーブルには、本実施形態のゲームのカードの進化合成の条件が記録されている。図６に進化合成データテーブルの構成例を示す。図６に示す例では、進化合成の内容を識別するための進化ＩＤごとに、進化前カードＩＤ（つまり、進化前のベースカードとなるカードのカードＩＤ）、進化後のカードＩＤ（ベースカードの進化後のカードＩＤ）、および、進化合成を実行するために必要となる参照カードのカードＩＤの変化条件（Ｃ１〜Ｃ５の欄の５枚の参照カード）が記録されている。例えば、進化ＩＤ：０００２が示す条件では、ユーザが所持カードの中からカードＩＤ：００７２のカードをベースカードとして選択し、ユーザの所持カードの中にカードＩＤ：００２５，００６０，００７０の３枚のカードの組合せが存在する場合には、進化合成を実行することによって、カードＩＤ：００７２のカードをカードＩＤ：９０７２のカードに進化させることができる。
ここでは、オブジェクトを変化させる処理の一例として、オブジェクトの一例であるカードの進化合成の処理について説明する。上述した通り、カードＩＤは、オブジェクト識別情報の一例である。つまり、図６は、オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報が変化条件に含まれることを示している。
なお、参照カードのカードＩＤの組合せを示すＣ１〜Ｃ５の欄には、少なくともいずれか２つの欄に同一のカードＩＤが記録されていることもある。例えば、ベースカードを進化合成するときに使用する参照カードの組合せに同一の参照カードが２枚以上含まれていてもよい。ベースカードを進化させるための参照カードの組合せ条件が、同一のカードＩＤである参照カードが所定数含まれることである場合には、図６に示したようなデータ形式ではなく、参照カードのカードＩＤとその枚数とからなるデータ形式であってもよい。

（iii）クエストデータテーブル
クエストデータテーブルには、本実施形態のゲームで実施されるイベントの１つであるクエストのデータが記録されている。クエストは、カードやアイテムを入手するために、ユーザがゲーム内のエリアを探索して、所定のクエスト条件を達成することを目的とするイベントである。図７にクエストデータテーブルの構成例を示す。図７に示す例では、クエストＩＤごとにエリア名、消費体力、入手可能なカードに関する情報（カードＩＤおよび入手率）、入手可能なアイテムに関する情報（アイテムＩＤおよび入手率）、ボスＩＤ、および、クエストＵＩデータが含まれる。
エリア名は、クエストで使用されるエリアの名称を示す文字列である。
消費体力は、クエストを実施するときに参照される値である。クエストを実施するには、ユーザのパラメータの１つである体力の値が消費体力の値以上である必要がある。クエストを実施すると、ユーザの体力の値が消費体力の値の分だけ消費される。
入手可能なカードに関する情報（入手カードデータ１，２…）は、カードＩＤおよび入手率から構成されている。カードＩＤは、クエスト条件を達成したときに入手可能なカードの識別情報である。入手率は、クエスト条件を達成したときにカードを入手できる確率を示す数値である。
入手可能なアイテムに関する情報（入手アイテムデータ１…）は、アイテムＩＤおよび入手率から構成されている。アイテムＩＤは、クエスト条件を達成したときに入手可能なアイテムの識別情報である。入手率は、クエスト条件を達成したときにアイテムを入手できる確率を示す数値である。
ボスＩＤは、クエスト内の対戦相手となるＮＰＣ（例えば、ボスキャラクタ）の識別情報である。クエスト条件は、例えばボスキャラクタとの対戦に勝利することにより達成される。
クエストＵＩデータは、クエストで使用されるユーザインタフェースのデータ（例えば、クエストで使用される画像データ）である。

（iv）所持カードデータテーブル
所持カードデータテーブルは、ユーザの所持カードの情報が記録されている。図８に所持カードデータテーブルの構成例を示す。図８では１ユーザの分の所持カードデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているすべてのユーザに対応して設けられる。
図８に示す所持カードデータテーブルには、カードＩＤごとに、シリアル番号、カードレベル、スキルレベル、および、予約ＩＤの各データが対応付けられて記録されている。
シリアル番号は、ユーザにカードが付与された時点で決定される固有の番号である。同一のカードＩＤのカードに対しても異なるシリアル番号が付される。なお、カードが進化した場合には、そのカードの進化前後でシリアル番号を変化させてもよいし、変化させなくてもよい。
カードレベルはカードの育成レベルを示すパラメータであり、例えば上記通常合成を実行することによって増加する。ユーザがカードを取得した時点でのカードレベルの値（初期値）は１であり、ユーザは通常合成等を実行することでそのカードを成長（つまり、カードレベルを増加）させることができる。
スキルレベルはカードの育成レベルを示すパラメータであり、特にカードが備えるスキルのレベルを示すパラメータである。ユーザがスキルを備えたカードを取得した時点でのスキルレベルの値（初期値）は１であり、例えば所定の条件を満たすカードを参照カードとした通常合成を行うことによってカードのスキルレベルを増加させることができる。カードのスキルレベルが増加するにつれて、スキルによって発生する効果が増大する。
予約ＩＤは、進化合成のための予約内容を識別するための識別情報である。予約済カードとなっているユーザの所持カードは、予約ＩＤが対応付けられている。例えば、図８に示す例では、カードＩＤ：０５９１，００１０（２枚）、００３３、２００５の５枚のカードが予約済カードであることを示している。所持カードデータテーブルに記録されている予約ＩＤは、後述する予約データテーブルに記録されている予約ＩＤに対応している。

（v）予約データテーブル
予約データテーブルは、ユーザの進化合成のための予約済カードの情報が記録されている。図９に予約データテーブルの構成例を示す。図９では１ユーザの分の予約データテーブルを例示するが、予約データテーブルは、ゲームに登録しているすべてのユーザに対応して設けられる。
図９において、予約ＩＤは進化合成の予約が行われた順に発行されるＩＤである。図９に示す例では、０１，０２，…といった具合に昇順に番号が記録される。進化ＩＤは、進化合成データテーブルに示した進化ＩＤに対応しており、進化合成の内容を特定するＩＤである。
予約済カードのシリアル番号のうち、進化前カードのシリアル番号は、進化合成のベースカードとしてユーザによって選択された所持カードのシリアル番号である。予約済みカードのシリアル番号のうち参照カードのＣ１〜Ｃ５の欄は、それぞれ、進化合成データテーブルの参照カードＩＤの組合せを構成するＣ１〜Ｃ５の欄に対応する。
予約済みの参照カードが所持カードである場合、当該参照カードのカードＩＤに対応する欄に所持カードデータのシリアル番号が記録される。予約済みの参照カードが未所持カードである場合、当該参照カードのカードＩＤに対応する欄に仮のシリアル番号（例えば、「００００００００」）が記録され、当該参照カードが所持カードになった（つまり、当該参照カードのカードＩＤおよびシリアル番号によって特定される所持カードデータが追加された）後に、仮のシリアル番号が当該参照カードのシリアル番号に書き換えられる。予約済みでない参照カードのカードＩＤに対応する欄には、「予約無し」を示すデータ（例えば、ＮＵＬＬ）が記録される。
なお、以下では、予約データテーブルを設ける場合について説明するが、予約データテーブルを独立して設けることは必須ではない。進化合成のための予約の管理方法として、予約データテーブルに記録すべきデータを、所持カードデータテーブルに記録してもよい。その場合には、所持カードデータテーブルにおいて、予約済カードのカードＩＤに対応付けて、予約ＩＤ、進化ＩＤ、Ｃ１〜Ｃ５のいずれかの文字列（進化合成データテーブルのＣ１〜Ｃ５の欄に対応する文字列であれば何でもよい。）が記録される。

（vi）所持履歴データテーブル
所持履歴データテーブルには、ユーザが所持したことのあるカードの情報が記録されている。図１０に所持履歴データテーブルの構成例を示す。図１０では１ユーザの分の所持履歴データテーブルを例示するが、所持履歴データテーブルは、ゲームに登録しているすべてのユーザに対して設けられる。
図１０に示す所持履歴テーブルには、カードＩＤごとに入手回数が対応付けられて記録されている。入手回数は、ゲーム内でユーザがカードを入手した回数を示す値である。入手回数が０回のカードは、未知カードである。

（vii）カード流通データテーブル
カード流通データテーブルには、ゲーム内で流通しているカードに関する情報が記憶されている。図１１にカード流通データテーブルの構成例を示す。図１１に示す例では、カード流通データテーブルは、カードＩＤごとに、流通数および平均取引価格が記録されている。
流通数は、ゲーム内でユーザが取引（例えば、売買）の対象のカードとして設定したカードの総数を示す値である。流通数が多いほど、カードの入手難易度が低いことを意味する。
平均取引価格は、ユーザ間でカードを取引するときの価格の平均値である。平均取引価格が高いほど、カードの入手難易度が高いことを意味する。

以下の説明では、カードデータテーブル、クエストデータテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブルにおいてカードＩＤに対応付けられた情報（例えば、カード名、カード画像、カードパラメータ、クエストＩＤ、エリア名、消費体力、入手率、ボスＩＤ、クエストＵＩデータ、シリアル番号、カードレベル、スキルレベル、予約ＩＤ、入手回数、流通数、および、平均取引価格）を総称して、適宜「カードデータ」という。カードデータは、オブジェクトを示す情報の一例である。

（１−６）入手条件の提示処理および進化合成処理の具体例
以下、本実施形態のゲームのカードの入手条件の提示処理および進化合成処理の具体例について、図１２Ａ、図１２Ｂ、図１３Ａ、図１３Ｂ、および、図１４を参照しながら説明する。図１２Ａ、図１２Ｂ、図１３Ａ、図１３Ｂ、および、図１４はそれぞれ、本実施形態のゲームの処理を実行しているときのユーザ端末１０に表示される画面の一例を示す図である。

（１−６−１）入手条件の提示処理
（１−６−１−１）未所持カードの入手条件の提示処理（図１２Ａおよび図１２Ｂ）
図１２Ａおよび図１２Ｂは、未所持カードの入手条件を提示するための入手条件の提示処理の一連の表示画面の変化を示している。図１２Ａにおいて、画像Ｐ１は、本実施形態のゲームにおいてユーザがモンスターカード（以下、単に「カード」という。）について、処理の要求を行うときの画像である。画像Ｐ１には、ユーザの操作対象として、ボタンｂ１（「所持モンスターを見る」）、ボタンｂ２（「チーム編成」）、ボタンｂ３（「通常合成」）、ボタンｂ４（「進化合成」）、ボタンｂ５（「売却」）が設けられる。
ボタンｂ１は、ユーザの所持カードの閲覧処理の要求を行うときに操作されるボタンである。ボタンｂ２は、ユーザが自身の所持カードの中から他のユーザやＮＰＣとの対戦において使用するカードを選択するときに操作されるボタンである。ボタンｂ３は、ユーザが所持カードの中からベースカードとして選択したカードの通常合成処理の要求を行うときに操作されるボタンである。ボタンｂ４は、ユーザが所持カードの中からベースカードとして選択したカードの進化合成処理の要求を行うときに操作されるボタンである。ボタンｂ５は、ユーザが所持カードの中から選択したカードに対して売却処理の要求を行うと
きに操作されるボタンである。

画像Ｐ１においてボタンｂ４（「進化合成」）が操作されると、Ｐ２に示すように画像が変化する。画像Ｐ２では、ユーザの所持カードの中からいずれかのカードをベースカードとして選択するために、複数の所持カードが一覧表示される。なお、進化することができないカード（図示する例では、カードＴＯＭ，ＴＥＤ，ＤＳＧ）についてはベースカードとして選択できないように、画像が構成されている。すなわち、画像Ｐ２では、ユーザの所持カードのうち進化可能なカードと進化不可能なカードとをユーザが識別可能な表示形式で示している。進化可能なカードと進化不可能なカードとをユーザが識別可能な表示形式で示す方法は、図１２Ａの画像Ｐ２に示した例に限られない。所持カードの一覧は各カードのカード名の文字列の一覧であってもよく、その場合には、進化可能なカードと進化不可能なカードとを文字列の輝度、サイズ等によって識別できるようにしてもよい。
画像Ｐ２において、進化可能ないずれかのカードとして例えばカードＫＬＭが選択されると、Ｐ３に示すように画像が変化する。画像Ｐ３には、選択したカードを進化合成のベースカードとして確定させるためのボタンｂ６（「選択する」）と、画像Ｐ２に戻って別のカードをベースカードとして選択するためのボタンｂ７（「戻る」）とが含まれる。
画像Ｐ３においてボタンｂ６が操作されると、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしていない場合には、Ｐ４に示すように画像が更新される。画像Ｐ４は、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードのうち未所持カードの入手条件の提示を要求するための画像である。なお、画像Ｐ３においてユーザがボタンｂ６を選択した時点で、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしている場合には、カードＫＬＭの進化合成の実行を要求するための画像（図示せず）が表示される。

画像Ｐ４には、進化前カード（ここでは、ベースカードであるカードＫＬＭ）と進化後カード（例えば、カードＱＲＳ）とを示す表示領域１０１、進化合成に必要な参照カードとその状態（所持、未所持、予約済、未知のいずれか）を示す表示領域１０２、および、参照カードの入手条件の提示を要求するためのボタンｂ８（「入手条件を表示する」）が含まれる。画像Ｐ４において、入手条件を表示すべき参照カード（ここでは、表示領域１０２に「未所持」の状態が示されたカードＤＳＧ）が選択され、且つ、ボタンｂ８が操作されると、図１２Ｂに示すように、ユーザによって選択された参照カードの入手条件を示す画像Ｐ５が表示される。
なお、当該ユーザによって選択された参照カードは、「ユーザによって指定された参照カード」ともいう。また、参照カードは、オブジェクトの一例であるので、「ユーザによって指定された参照カード」は、ユーザによって指定されたオブジェクトである「指定オブジェクト」の一例である。

図１２Ｂの画像Ｐ５には、ユーザによって選択された参照カード（ここでは、カードＤＳＧ）、ならびに、当該参照カードのカード画像、カード名、および、レアリティを示す表示領域１０３と、当該参照カードの入手条件を示す表示領域１０４と、を含む。表示領域１０４には、入手難易度に関する情報１０４ａ（ここでは、入手回数、流通数、および、平均取引価格）、および、入手経路に関する情報１０４ｂ（ここでは、入手可能エリア）が示される。

（１−６−１−２）未知カードの入手条件の提示処理（図１３Ａおよび図１３Ｂ）
図１３Ａおよび図１３Ｂは、未知カードの入手条件を提示するための入手条件の提示処理の一連の表示画面の変化を示している。図１３Ａの画像Ｐ１〜Ｐ３は、それぞれ図１２Ａの画像Ｐ１〜Ｐ３と同様である。
図１３Ａの画像Ｐ４は、表示領域１０２に未知カードが示されている点において、図１２Ａの画像Ｐ４と異なる。未知カードとは、未所持カードのうち、ユーザが１回も所持したことがない（例えば、所持履歴データテーブルにおける「入手回数」の値が０回である）カードである。画像Ｐ４において、入手条件を表示すべき参照カード（ここでは、表示領域１０２に「未知」の状態が示されたカード）が選択され、且つ、ボタンｂ８が操作されると、図１３Ｂに示すように、ユーザによって選択された参照カードの入手条件を示す画像Ｐ５が表示される。

図１３Ｂの画像Ｐ５は、表示領域１０３に、ユーザによって選択された参照カードが当該ユーザにとって未知カードであることを示す画像が示されており、且つ、表示領域１０４に、当該参照カードの入手条件のうち入手難易度に関する情報１０４ｂ（ここでは、入手回数および流通数）のみが示されている（つまり、図１２Ｂの画像Ｐ５における入手経路に関する情報１０４ａがマスクされている）点において、図１２Ｂの画像Ｐ５と異なる。

（１−６−２）進化合成処理（図１４）
図１４は、ユーザの操作に基づいて進化合成処理を実行するときの一連の表示画面の変化を示している。図１４において画像Ｐ１０は、ユーザがゲームを実行中に新たなカードＤＳＧを入手した場合に表示される画像の一例である。
この新たなカードＤＳＧを入手したことで、予約済みの進化合成の変化条件が満たされるようになった場合には、新たなカードの入手によって、当該変化条件が満たされるようになったことをユーザに通知することが好ましい。より好ましくは、Ｐ１１に示すように進化合成を実行するための画像を表示することが好ましい。
画像Ｐ１１は、進化前カード（カードＫＬＭ）と進化後カード（カードＱＲＳ）とを示す表示領域１０１、進化合成に必要な参照カードとその状態（ここでは、所持）を示す表示領域１０２、および、進化合成を実行するか否かの要求を受け付けるためのボタンｂ２０（「はい」）およびボタンｂ２１（「いいえ」）が表示される。
画像Ｐ１１においてボタンｂ２０が操作されると、Ｐ１２に示すように画像が変化する。画像Ｐ１２の例では、進化後カードのカード画像、カード名、および、パラメータの少なくとも一部が表示される。

（１−７）情報処理装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためにゲームサーバ２０が備える機能について説明する。図１５は、本実施形態のゲームサーバ２０で主要な役割を果たす機能を説明するための機能ブロック図である。図１５において、データテーブル群７０は、前述したように、カードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、予約データテーブル、所持履歴データテーブル、および、カード流通データテーブルを含む。なお、図１５に示す機能ブロック図に含まれる手段のすべてが本発明に必須の要素とは限らない。

受付手段５１は、ユーザの操作入力に関する情報に基づいてユーザからの各種の要求を受け付ける機能を備える。本実施形態のゲームにおいてユーザからの要求としては、例えば、カードの入手条件の提示処理の要求、進化合成処理の要求、クエスト処理の要求、進化合成の予約処理の要求、進化合成の実行要求、ユーザの所持カードの閲覧処理の要求、ユーザの所持カードの売却処理の要求などがある。
入手条件の提示処理の要求は、出力手段５６により画像データが出力されたことに応じて、ベースカードの進化合成に必要な参照カードの入手条件を提示させる要求である。
進化合成の予約処理の要求は、出力手段５６により画像データが出力されたことに応じて、進化合成におけるベースカード、および、ベースカードに対応する複数の参照カードうち少なくともいずれかのカードを進化合成のために予約し、当該カードをユーザの所持カードから消失させることを条件として実行される処理のうち当該進化合成以外の処理（例えば、当該カードの売却処理、または、当該カードを他のユーザに譲渡する処理）に用いられることを制限させる要求である。進化合成の予約処理の要求には、予約の対象となる参照カードのカードＩＤが含まれる。
受付手段５１の機能を実現するために、ゲームサーバ２０は、通信インタフェース部２４を介して、ユーザ端末１０から画像であるウェブページ内のユーザによるボタンの操作入力に対応する要求を受信する。ゲームサーバ２０のＣＰＵ２１は、受信した要求に含まれる情報に基づいて、要求の内容を判別し、要求の受付処理を行う。受付処理では、要求がＲＡＭ１３に記録される。ＣＰＵ２１は、受け付けられた要求に応じた処理を順に実行する。

ゲーム処理手段５２は、受付手段５１にて受け付けたユーザからの要求および指示に基づいて、進化合成以外の様々なゲームの処理を実行する機能を備える。本実施形態のゲームの処理は、適宜設けられてよいが、例えば、ユーザ間の対戦処理、ユーザ対ＮＰＣの対戦処理、ユーザによるクエスト処理、ユーザの所持カードの通常合成の処理、ユーザの所持カードの売却処理である。
対戦処理については詳しく述べないが、例えば、ユーザは、コストの総和が所定の上限値以下となるように予め複数の所持カードからなるチームを編成し、チームによって他のユーザまたはＮＰＣと対戦する。対戦結果は、チームを構成する各カードの攻撃力、防御力、スキルなどのパラメータによって決定される。

クエスト処理を実行する場合のゲーム処理手段５２の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、クエストＩＤを含むクエスト処理の要求を受け付けると、クエストデータテーブルから、当該クエストＩＤに対応付けられたクエストデータ（エリア名、消費体力、入手カードデータ（カードＩＤおよび入手率）、入手アイテムデータ（アイテムＩＤおよび入手率）、ボスＩＤ、および、クエストＵＩデータ）を読み出してＲＡＭ２３に展開する。次いでＣＰＵ２１は、クエストＵＩデータに基づいてクエストの実行画面を表示させるとともに、ユーザの操作に応じてクエストを進行させる。クエストが所定レベルまで進行すると、ＣＰＵ２１は、ボスＩＤに対応付けられたボスキャラクタとユーザとの対戦を実行する。ユーザが当該対戦において勝利条件を満たすと、ＣＰＵ２１は、クエストＩＤに対応付けられた「入手率」の値に応じてカードを付与する処理を実行する。カードを付与する処理では、ＣＰＵ２１は、クエストＩＤに対応付けられたカードＩＤを所持カードデータテーブルに書き込むとともに、所持履歴データテーブルにおいて当該カードＩＤに対応付けられた「入手回数」の値を増加させる。
なお、ユーザが当該対戦において勝利条件を満たした場合、アイテムを付与する処理も、カードを付与する処理と同様に実行される。

ユーザの所持カードの通常合成の処理を実行する場合のゲーム処理手段５２の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ベースカードおよび参照カードについてのユーザの選択結果を含む通常合成の実行要求を受け付けると、所持カードデータテーブルからベースカードおよび参照カードのカードデータを読み出してＲＡＭ２３に展開する。次いでＣＰＵ２１は、ベースカードおよび参照カードのパラメータに基づいてベースカードのパラメータ（例えば、カードレベルやスキルレベル）を変更し、変更後のベースカードのパラメータを所持カードデータテーブルに書き込むとともに、所持カードデータテーブルから参照カードとした所持カードのカードデータを削除する。なお、ベースカードのカードレベルやスキルレベルは、通常合成を実行する度に常に増加するとは限らない。例えば、通常合成を実行する度にカードに対応付けられた育成パラメータの値を増加させ、その育成パラメータの値が所定値に達した場合にカードレベルを１つ増加させるとともに育成パラメータの値をゼロにリセットするようにしてもよい。

ユーザの所持カードの売却処理を実行する場合のゲーム処理手段５２の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、売却処理の要求を受け付け、売却対象のカードの選択結果を受け付けると、所持カードデータテーブルから売却対象のカードのカードデータを削除する。次いでＣＰＵ２１は、カードデータテーブルから売却対象のカードの売却価格の値（ポイント）を読み出し、読み出したポイントをユーザに付与する処理を行う。ポイントをユーザに付与する処理は、例えば、ユーザデータベース（図示せず）に記録されているユーザの所持ポイントの値を更新する処理である。

カードデータ変更手段５４は、変化条件を満たす複数の参照カードの全てがユーザの所持カードに含まれる場合に、ベースカードのカードデータを変更する進化合成を実行する機能を備える。
本実施形態の例では、カードデータ変更手段５４の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、進化合成の実行要求を受け付けると、所持カードデータテーブルにおいて、進化前カード（つまり、進化合成のベースカード）のカードデータを消去し、進化後カードのカードデータを新たに書き込む。それによって、ユーザの所持カードのベースカードが進化することになる。なお、進化合成データテーブルに示すように、進化前と進化後とでカードＩＤは異なるため、カード名、カード画像、および、カードパラメータのうち少なくともいずれかが進化合成によって変更されることになる。

取得手段５５は、ユーザによって選択されたベースカード（選択オブジェクトの一例）に対応する参照カードの組合せ条件（変化条件の一例）である複数の参照カードＩＤを、進化合成データテーブルから取得する機能を備える。また、取得手段５５は、ユーザによって選択された参照カードが所持カードでない（例えば、未所持カードまたは未知カードである）場合に、当該参照カードのカードデータを、クエストデータテーブル、所持履歴データテーブル、および、カード流通データテーブルから取得する機能を備える。また、取得手段５５は、進化合成のためにカードの予約をするに当たって、ユーザの操作入力に
基づいて、ユーザの所持カードの中のいずれかのカードのシリアル番号（オブジェクトを示す情報の一例）を取得する機能を備える。
取得手段５５が参照カードの組合せ条件である複数の参照カードＩＤを取得する場合、ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からベースカードの選択結果を取得したことに応じて、進化合成データテーブルを参照して、ベースカードに対応する組合せ条件を構成する複数の参照カードＩＤを読み出す。
取得手段５５がユーザによって選択された参照カードのカードデータを取得する場合、ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０から参照カードの選択結果を取得したことに応じて、クエストデータテーブル、所持履歴データテーブル、および、カード流通データテーブルを参照して、当該参照カードのカードデータを読み出す。
取得手段５５がカードのシリアル番号を取得する場合、ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０から進化合成の予約処理の要求を受け付けると、進化合成の対象となるベースカード、および、当該ベースカードに対応する複数の参照カードの中から、予約済みでない所持カードを、所持カードデータテーブルを参照して特定し、特定したカードのシリアル番号を読み出す。

出力手段５６は、取得手段５５によって取得された変化条件に含まれる複数の参照カードのカードデータを用いて、当該複数の参照カードをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データ（例えば、画像データ）を出力する機能（以下「第１出力機能」という。）を備える。
本実施形態の例では、出力手段５６の第１出力機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、例えばユーザによってベースカードが選択されたときに、そのベースカードを進化させるために必要となる複数の参照カードＩＤの組合せを進化合成データテーブルから読み出し、各参照カードについて、所持カードデータテーブル、予約データテーブル、および、所持履歴データテーブルに記憶された情報に基づいて、カードの状態（「予約済」、「所持」、「未所持」、および、「未知」のいずれかの状態）を特定する。また、ＣＰＵ２１は、各参照カードの状態をユーザに識別可能な表示形式で表示させるための第１出力データを生成する。
例えば、図９の予約データテーブルにおいて、ベースカードに対応する進化ＩＤに対応付けられたＣ１〜Ｃ５の欄に所持カードデータに含まれるシリアル番号または仮のシリアル番号が記録されている場合には、該当する欄に対応するカードＩＤによって特定される参照カードの状態が「予約済」として特定される。
例えば、カードの状態が「予約済」以外のカードについて、図６の進化合成データテーブルにおいて、ベースカードに対応する進化ＩＤに対応付けられたＣ１〜Ｃ５の欄のカードＩＤが図８の所持カードデータテーブルの「カードＩＤ」の欄に含まれている場合には、当該カードＩＤによって特定される参照カードの状態が「所持」として特定される。
例えば、カードの状態が「予約済」および「所持」以外のカードについて、図１０の所持履歴データテーブルにおいて、当該カードＩＤに対応する「入手回数」の欄が０でない場合には、当該カードＩＤによって特定される参照カードの状態が「未所持」として特定され、当該カードＩＤに対応する「入手回数」の欄が０である場合には、当該カードＩＤによって特定される参照カードの状態が「未知」として特定される。
第１出力データには、特定された参照カードの状態が示される。

また、出力手段５６は、取得手段５５によって取得された参照カードＩＤに対応する参照カード（未所持カードまたは当該未知カード）の入手条件を提示するための第２出力データ（例えば、画像データ）を出力する機能（以下「第２出力機能」という。）を備える。
本実施形態の例では、出力手段５６の第２出力機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、例えば取得手段５５によって参照カードＩＤが取得されたときに、取得された参照カードＩＤに基づいてクエストデータテーブル、所持履歴データテーブル、および、カード流通データテーブルを参照し、当該参照カードＩＤに対応する参照カードの入手条件を特定し、当該入手条件を提示するための第２出力データを生成する。
例えば、図７のクエストデータテーブルにおいて、「入手カード」の「カードＩＤ」の欄に取得された参照カードＩＤが含まれるクエストＩＤに対応する「エリア名」の欄の情報が、入手可能エリアとして特定される。
図１０の所持履歴テーブルにおいて、取得された参照カードＩＤに対応する「入手回数」の欄の値が、入手回数として特定される。
図１１のカード流通データテーブルにおいて、取得された参照カードＩＤに対応する「流通数」および「平均取引価格」の欄の値が、それぞれ流通数および平均取引価格として特定される。
第２出力データには、特定された入手可能エリア、入手回数、流通数、および、平均取引価格の少なくとも１つが示される。

記録手段５７は、進化合成の予約処理の要求を受け付けたことに応じて、取得手段５５によって取得されたシリアル番号をストレージ２５内の予約データテーブルに予約済カードとして記録する機能を備える。本実施形態の例では、予約対象カードは、選択されたベースカードの進化合成以外の処理に用いられることが制限されるカードである。

記録手段５７の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、進化合成の予約処理の要求を受け付けると、予約データテーブルにアクセスし、予約対象カードのシリアル番号を書き込む。より具体的には、予約対象カードのうちベースカードとして選択されたカードのシリアル番号が予約データテーブルに記録されていない場合には、新たな予約ＩＤを発行する。ＣＰＵ２１は、発行した予約ＩＤに対応付けて、ベースカードとして選択されたカードのシリアル番号を「進化前カード」の欄に書き込む。さらに、予約対象カードのうち参照カードのシリアル番号に対応するカードＩＤと同一の「参照カードＩＤ」の欄（Ｃ１〜Ｃ５の欄のいずれか）を特定し、特定した欄に予約対象カードのうち参照カードのシリアル番号を書き込む。
一方、予約ＩＤが発行済みである場合には、「進化前カード」の欄にはシリアル番号が既に記録されているため、ＣＰＵ２１は、予約対象カードのうち参照カードのシリアル番号の書き込みのみを行う。

制限手段５８は、予約データテーブルに予約済カードとして記録されているカードが、目的とする進化合成以外の処理に用いられることを制限する機能を備える。「目的とする進化合成以外の処理に用いられる」とは、目的とする進化合成に対応付けられて予約済カードとして記録されているカードが、その目的とする進化合成以外の進化合成や通常合成に用いられる場合も含まれる。
制限手段５８による制限方法は様々な方法が考えられる。例えば、制限対象となるカードを、ユーザが目的とする進化合成以外の処理を禁止する方法や、制限対象となるカードが目的とする進化合成以外の処理のために選択されたときに、ユーザに対して、当該処理の続行を確認する処理を行う方法などである。
なお、予約済カードについて「処理に用いられることを制限する」とは、予約済カードを用いた、目的とする進化合成以外の処理自体が禁止されることに限られず、予約済カードを用いた、目的とする進化合成以外の処理は実行可能であるが、その処理の実行の手続をし難くする、あるいは処理の実行手続を煩雑にすることであってもよい。予約済カードについての「進化合成以外の処理」が、予約済カードをユーザの所持カードから消失させることを条件として実行される処理（つまり、予約済カードを未所持カードとすることを条件として実行される処理）である場合に、当該処理が制限されることが特に好ましい。

例えば、ゲームサーバ２０のＣＰＵ２１は、本実施形態のゲームの様々な処理のいずれかの処理の実行要求を受け付けた場合、ユーザの所持カードが処理対象のカードとして選択されたときには、所持カードデータテーブルを参照して、当該選択されたカードのカードＩＤに予約ＩＤが対応付けられているか否かについて判定する。ＣＰＵ２１は、選択されたカードのカードＩＤに予約ＩＤが対応付けられ、かつ実行要求に係る処理が予約ＩＤに対応する進化合成処理ではない場合には、当該処理を禁止してもよいし、選択されたカードが予約済カードであることをユーザに報知してもよい。あるいは、選択されたカードが予約済カードであることをユーザに報知するとともに、処理を続行するか否かについてユーザに確認してもよい。予約データテーブルには進化ＩＤと予約済カードのシリアル番号が対応付けられているため、ゲームサーバ２０のＣＰＵ２１は、予約済カードに対応した、目的とする進化合成（つまり、特定の進化ＩＤに対応した進化合成）を特定することができる。そのため、ユーザが特定の所持カードを用いて実行しようとする処理が、目的とする進化合成の処理であるか否かを判別することができる。

記録手段５７および制限手段５８を設けることは必須ではないが、記録手段５７および制限手段５８を設けることで、例えば、進化合成に必要となる複数の参照カードのうち一部の参照カードを進化合成の実行前に予約し、残りの参照カードを入手するまで進化合成を待機しているユーザが、所持カードを誤って進化合成以外の処理に使用してしまうことを防止できる。

（１−８）本実施形態のゲームの処理フロー
次に、本実施形態のゲームの処理フローの一例について、図１６Ａ、図１６Ｂ、および、図１７のシーケンスチャートを参照して説明する。
図１６Ａおよび図１６Ｂは、入手条件の提示処理を示すシーケンスチャートである。図１７は、進化合成処理を示すシーケンスチャートである。
なお、各図において、図１２Ａ、図１２Ｂ、図１３Ａ、図１３Ｂ、および、図１４に示した各画像Ｐ１〜Ｐ５、および、Ｐ１０〜Ｐ１２が表示されるステップに各画像の符号を付してある。

（１−８−１）入手条件の提示処理（図１６Ａ〜図１６Ｂ）
以下で説明する入手条件の提示処理では、一例として、ユーザが、ベースカードと、当該ベースカードを進化合成させるための複数の参照カードの一部とを所持している場合に、未所持または未知の参照カードの入手条件の提示を要求する場合を想定する。

図１６Ａにおいて、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図１２Ａまたは図１３Ａの画像Ｐ１のボタンｂ４）をユーザが操作することによって、ユーザ端末１０のＣＰＵ１１は進化合成処理の要求を受け付け（Ｓ１０）、当該要求をゲームサーバ２０へ送信する（Ｓ１２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの入手条件の提示処理の要求を受け付けると、進化合成データテーブルおよび所持カードデータテーブルを参照して、進化可能なユーザの所持カードを読み出す（Ｓ１４）。すなわち、ＣＰＵ２１は、所持カードデータテーブルからユーザの所持カードのカードデータを読み出し、進化合成データテーブルの進化前カードＩＤ（つまり、進化可能なカードのカードＩＤ）をすべて読み出す。次いでＣＰＵ２１は、ユーザの所持カードの中から進化可能なカード（つまり、ベースカード候補）を特定し、ベースカード候補のカードデータを含む画像データを生成し（Ｓ１６）、当該画像データをユーザ端末１０へ送信する（Ｓ１８）。
なお、Ｓ１６で生成される画像データは、図１２Ａまたは図１３Ａの画像Ｐ２に示したように、ユーザの所持カードのうち進化可能なカードの画像と進化不可能なカードの画像とが異なる表示態様となるようにして生成されることが好ましい。

ユーザ端末１０のＣＰＵ１１は、Ｓ１８で送信された画像データを受け付けると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ２０）。Ｓ２０で表示される画像には、図１２Ａまたは図１３Ａの画像Ｐ２に例示したように、ベースカード候補となる複数のカードの画像が含まれ、各カードの画像を操作することで各カードのシリアル番号が選択可能となるようにして構成されている。Ｓ２０で表示された複数のベースカード候補の中でいずれかのカードがベースカードとして選択する操作がユーザにより行われると、ＣＰＵ１１は、ベースカードの選択結果（シリアル番号）を受け付け（Ｓ２２）、当該選
択結果をゲームサーバ２０へ送信する（Ｓ２４）。

ゲームサーバ２０のＣＰＵ２１は、Ｓ２４で送信された選択結果（シリアル番号）を受け付けると、進化合成データテーブルを参照し、ユーザによって選択されたベースカードのシリアル番号に対応付けられたカードＩＤと一致する進化前カードＩＤに対応する複数の参照カードＩＤ（Ｃ１〜Ｃ５の欄のカードＩＤ）を読み出す（Ｓ２６）。次いでＣＰＵ２１は、所持カードデータテーブルおよび予約データテーブルを参照して、Ｓ２６で読み出した各参照カードＩＤに対応するカードの状態（未所持、所持、予約済、および、未知のいずれか）を特定し、当該特定結果に基づいて画像データを生成する（Ｓ２８）。

Ｓ２８では、ゲームサーバ２０のＣＰＵ２１は以下のようにして各参照カードＩＤに対応するカードの状態を特定する。
ＣＰＵ２１は、予約データテーブルの「予約済カードのシリアル番号」の欄に記録されているシリアル番号を読み出し、所持カードデータテーブルを参照して、当該シリアル番号に対応付けられたカードＩＤを特定する。Ｓ２６で読み出した参照カードＩＤと特定したカードＩＤとが一致する場合、または、当該シリアル番号が仮のシリアル番号である場合には、当該カードＩＤによって特定されるカードの状態を「予約済」として特定する。
ＣＰＵ２１は、「予約済」として特定したカード以外の参照カードについて、所持カードデータテーブルに記録されているカードＩＤの中に当該参照カードの参照カードＩＤが含まれている場合には、当該参照カードＩＤによって特定されるカードの状態を「所持」として特定する。
ＣＰＵ２１は、「予約済」および「所持」以外のカードについて、所持履歴データテーブルの「入手回数」欄の参照カードＩＤに対応付けられた値が０でない場合、当該参照カードＩＤによって特定されるカードの状態を「未所持」として特定し、所持履歴データテーブルの「入手回数」欄の参照カードＩＤに対応付けられた値が０である場合、当該参照カードＩＤによって特定されるカードの状態を「未知」として特定する。

Ｓ２８では、ゲームサーバ２０のＣＰＵ２１は、Ｓ２６で読み出したすべての参照カードの状態が「所持」または「予約済」である場合には、カードＫＬＭの進化合成を実行するか否かをユーザが指示するための画像データを生成する。ＣＰＵ２１は、Ｓ２６で読み出した少なくともいずれかの参照カードの状態が「未所持」または「未知」である場合には、「未所持」または「未知」の状態の参照カードの入手条件を提示するための画像データを生成する。ここでは、図１２Ａまたは図１３Ａの画像Ｐ４の元になる画像データが生成された場合を想定する。

次いでゲームサーバ２０のＣＰＵ２１は、Ｓ２８で生成した画像データをユーザ端末１０へ送信する（Ｓ３０）。ユーザ端末１０のＣＰＵ１１は、Ｓ３０で送信された画像データを受け付けると、当該画像データに基づく画像を表示部１６に表示する（Ｓ３２）。

Ｓ３２で表示される画像は、図１２Ａまたは図１３Ａの画像Ｐ４に示したように、Ｓ２２で選択されたベースカードを進化合成するために必要となる複数の参照カードをユーザが識別できるように表示している。図１２Ａまたは図１３Ａの画像Ｐ４は、各々の参照カードの状態が参照カードに対応付けて表示されるとともに、未所持カードまたは未知カードの入手条件の提示処理の要求を受付可能に構成されている。ここで、図１２Ａまたは図１３Ａの画像Ｐ４が表示された後に、入手条件の提示処理の要求を行うための操作（例えば、図１２Ａまたは図１３Ａの画像Ｐ４のボタンｂ８の操作）がユーザによって行われると、ユーザ端末１０のＣＰＵ１１は、当該操作に対応するユーザの指示に基づいて、入手条件の提示処理の要求を受け付け（Ｓ３４）、当該要求をゲームサーバ２０へ送信する（Ｓ３６）。Ｓ３６でユーザ端末１０からゲームサーバ２０へ送信された要求には、ユーザによって選択された未所持カードまたは未知カード（つまり、入手条件の提示処理において入手条件を提示すべきカード）のカードＩＤが含まれる。
上述した通り、ユーザによって選択された参照カードは、ユーザによって指定されたオブジェクトである指定オブジェクトの一例である。つまり、Ｓ３４およびＳ３６の処理は、ユーザの指示に基づいて、複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける処理の一例である。

ゲームサーバ２０のＣＰＵ２１は、Ｓ３６で送信された入手条件の提示処理の要求を受け付けると、カードデータテーブル、クエストデータテーブル、および、カード流通データテーブルから、ユーザによって選択された参照カードのカードデータを取得する（Ｓ３８）。カード名、カード画像、および、レアリティはカードデータテーブルから取得される。クエストＩＤおよび入手可能エリアのエリア名は、クエストデータテーブルから取得される。入手回数は、所持履歴テーブルから取得される。流通数および平均取引価格は、カード流通データテーブルから取得される。

Ｓ２８で特定されたカードの状態が「未知」である場合には（Ｓ４０：ＹＥＳ）、Ｓ４２へ進み、Ｓ２８で特定されたカードの状態が「未知」でない場合には（Ｓ４０：ＮＯ）、Ｓ４４へ進む。
ここでは、カードの状態が「未知」でない場合（つまり、未知カード）の一例として、カードの状態が「未所持」である場合（つまり、未所持カード）の例を説明する。なお、「未知」および「未所持」は、いずれも、ユーザがカードを所持していない（つまり、カードＩＤが所持カードデータテーブルに含まれていない）状態を示す点で共通する。

Ｓ４２では、ゲームサーバ２０のＣＰＵ２１は、Ｓ３８で取得したカードデータによって示されるカードに関する情報のうち、入手難易度に関する情報（ここでは、入手回数、流通数、および、平均取引価格）以外の情報（ここでは、カード名、カード画像、レアリティ、および、入手可能エリア）が表示されないように、画像に対してマスク処理を適用する。
なお、本実施形態において、未知カードの入手難易度に関する情報以外の情報が表示されないようにする目的は、ゲーム（特に、未知カードを入手すること）に対する期待感をユーザに与え、かつ、ゲームの趣向性を向上させることにある。

Ｓ４４では、ＣＰＵ２１は、Ｓ３８で取得した参照カードのカードデータに基づいて、当該参照カードの入手条件（但し、Ｓ４０において「未知」であると判定された場合には、入手難易度に関する情報）をユーザに提示するための画像データ（図１２Ｂまたは図１３Ｂの画像Ｐ５の元になる画像データ）を生成し、当該画像データをユーザ端末１０へ送信する（Ｓ４６）。

ユーザ端末１０のＣＰＵ１１は、Ｓ４６で送信された画像データを受け付けると、当該画像データに基づく画像を表示部１６に表示する（Ｓ４８）。
Ｓ４０で「未知」でない（例えば、「未所持」である）と判定された場合、図１２Ｂの画像Ｐ５に示すように、カード画像、カード名、レアリティ、入手回数、流通数、平均取引価格、および、入手可能エリアが表示される。
一方、Ｓ４０で「未知」であると判定された場合、図１３Ｂの画像Ｐ５に示すように、入手回数、流通数、および、平均取引価格は表示されるが、カード画像、カード名、レアリティ、および、入手可能エリアは表示されない。
換言すると、未知カードの入手条件として表示される情報は、未所持カードの入手条件として表示される情報より制限される。つまり、Ｓ４８は、指定オブジェクトが、ユーザが所持したことがないオブジェクトである未知オブジェクトである場合、指定オブジェクトが未所持オブジェクトである場合に比べて、入手条件として表示される情報が制限される処理の一例である。

以上の通り、本実施形態では、ユーザによって選択された参照カードをユーザが所持していない場合（当該参照カードが未知カードまたは未所持カードの場合）、当該参照カードの入手条件を表示する例を説明した。これは、指定されたオブジェクトである指定オブジェクトをユーザが所持していない場合、指定オブジェクトの入手条件を表示する処理の一例である。

（１−８−２）進化合成処理（図１７）
例えば、ユーザが新たに入手したカードによって進化合成における参照カードの変化条件を満たすことになった場合には、進化合成処理が実行可能になる。
図１７において、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図１４の画像Ｐ１１のボタンｂ２０）をユーザが操作することによって、ユーザ端末１０のＣＰＵ１１は、進化合成の実行要求を受け付け（Ｓ１５０）、当該要求をゲームサーバ２０へ送信する（Ｓ１５２）。

ゲームサーバ２０のＣＰＵ２１は、Ｓ１５２で送信された要求を受け付けると、所持カードデータテーブルにおいて、進化前カード（つまり、進化合成のベースカード）のカードデータを消去し（Ｓ１５４）、進化後カードのカードデータを新たに書き込む（Ｓ１５６）。
次いでゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルにおいて、進化合成に使用する参照カードのカードデータを消去する（Ｓ１５８）。

次にゲームサーバ２０のＣＰＵ２１は、進化後カードのカードデータを含む画像データ（図１４の画像Ｐ１２の元になる画像データ）を生成し（Ｓ１６０）、当該画像データをユーザ端末１０へ送信する（Ｓ１６２）。ユーザ端末１０のＣＰＵ１１は、Ｓ１６２で送信された画像データを受け付けると、当該画像データに基づく画像（例えば、図１４の画像Ｐ１２）を表示部１６に表示する（Ｓ１６４）。

以上説明したように、本実施形態のゲームシステムでは、オブジェクトを変化させる処理の一例であるカードの進化合成を実行するためには、進化合成の対象となるベースカードと、それに対応する複数の参照カードのすべてをユーザが所持していることが要件となる。従って、例えば、その複数の参照カードのうち一部の参照カードを所持していない場合には、ベースカードの進化合成を実行することができない。このとき、ユーザが所持していない参照カードの入手が、当該ユーザにとって不可能または困難である場合がある。しかし、当該参照カードの入手条件を知らないユーザは、当該参照カードの入手が不可能または困難であることを、当該参照カードを入手するための処理（例えば、クエスト処理）を実行するか否かを決断する時点で認識できない。このような場合、ユーザは、実際には参照オジェクトの入手が不可能または困難かもしれないという不安を抱えたまま、当該参照カードを入手するための処理を実行することになる。
本実施形態のゲームサーバ２０は、ユーザによる要求に応じて、ユーザが所持していない参照カードの入手条件を提示する。そのため、進化合成の対象となるベースカードに対応する複数の参照カードの中に、ユーザにとって入手が不可能または困難な参照カードがあったとしても、ユーザは、当該参照カードの入手が不可能または困難であることを認識した上で、当該参照カードを入手するための処理を実行するか否かを決断できる。その結果、当該参照カードを入手するための処理を実行するユーザに安心感を与えることができる。

また、未所持カードの入手条件としては、入手経路および入手難易度のうち少なくとも１つが提示されることが好ましい。この場合、ユーザは、当該未所持カードを入手するための処理（例えば、クエスト処理）を実行するユーザに安心感を与えることができる。

また、未知カードの入手条件としては、入手難易度は表示されるが、入手経路は提示されない（すなわち、未知カードの入手条件として表示される情報は、未所持カードの入手条件として表示される情報に比べて制限される）ことが好ましい。この場合、ゲームの難易度を適切なレベルに保ちながら、当該未知カードを入手するための処理（例えば、クエスト処理）を実行するユーザに安心感を与えることができる。

（１−９）本実施形態の変形例
以下、本実施形態の変形例について説明する。なお、以下の変形例は適宜組合せ可能である。

（１−９−１）第１の変形例
図１２Ａまたは図１３Ａの画像Ｐ４では、それぞれ、参照カードのカード画像のみを表示する表示形式を示しているが、本実施形態の表示形式はこれに限られるものではない。
例えば、カード画像のみを表示する表示形式に代えて、カード名のみを表示する表示形式であってもよいし、カード画像とカード名との組合せを表示する表示形式であってもよい。
つまり、本実施形態の表示形式は、参照カードをユーザにそれぞれ識別可能に表示する形式であれば、どのようなものでもよい。

（１−９−２）第２の変形例
上述の実施形態では、図１６ＢのＳ４２において、Ｓ３８で取得したカードデータのうち入手難易度に関する情報以外の情報が表示されないようにするために、画像に対してマスク処理を適用する例について説明したが、当該情報が表示されないようにするための処理はこれに限られない。
例えば、マスク処理を適用する代わりに、入手難易度に関する情報以外の情報を削除してもよいし、当該情報を所定の記号に置き換えてもよい。

（１−９−３）第３の変形例
上述の実施形態では、図１６ＢのＳ４２において、カード名、カード画像、レアリティ、および、入手可能エリアが表示されないようにする例について説明したが、本実施形態はこれに限られない。
例えば、カード画像と入手可能エリアを表示されないようにし、カード名とレアリティは表示するようにしてもよい。
また、表示されないようにする情報は、ユーザが任意に設定できるようにしてもよい。

（１−９−４）第４の変形例
上述の実施形態では、図１６ＢのＳ４２において、Ｓ３８で取得したカードデータによって示されるカードに関する情報のうち、入手難易度に関する情報以外の情報が表示されないようにする例について説明したが、Ｓ４２は省略可能である。
Ｓ４２を省略した場合、Ｓ３８で取得したカードデータ（つまり、入手条件が提示された参照カードに関する情報）のすべてが表示されるので、ユーザに対して、当該参照カードを入手できる可能性がある、という期待感を与えることができる。

（１−９−５）第５の変形例
ユーザが過去に所持したことがあり、且つ、ユーザが現在所持していない参照カードである未所持カードが入手条件を提示すべきカードとして選択された場合、当該カードの入手可能エリアおよび入手難易度に関する情報の少なくとも１つを入手条件として表示することが望ましい。
これは、指定オブジェクトが、ユーザが過去に所持したことがあり、且つ、ユーザが現在所持していないオブジェクトである未所持オブジェクトである場合、入手条件として、指定オブジェクトの入手経路および入手難易度の少なくとも１つを表示する処理の一例である。
本変形例によれば、ユーザは当該カードの入手難易度を容易に知ることができる。

（１−９−６）第６の変形例
上述の実施形態では、未所持カードの入手条件を表示する例を示したが、未所持カード以外のカードの入手条件を表示してもよい。
一例として、所持カードの入手条件を表示してもよい。例えば、所持カードが多い場合、ある所持カードの入手条件をユーザが忘れていることがある。この場合、当該所持カードの入手条件を表示することにより、ユーザは、当該所持カードの入手難易度を再認識できる。仮に、ユーザが、当該所持カードの入手難易度が高いと認識した場合、当該所持カードの用途（例えば、どのベースカードの進化合成の処理の参照カードとして用いるか）を慎重に考えさせることのきっかけを与えることができる。一方、ユーザが、当該所持カードの入手難易度が低いと認識した場合、当該所持カードを気軽に使わせることのきっかけを与えることができる。

（１−９−７）第７の変形例
上述の実施形態では、ベースカードに対応するすべての参照カードを所持している場合に変化条件を満たす例を説明したが、当該すべての参照カードを所持していることに加えて、所定の追加条件が成立する場合に変化条件が満たされてもよい。
例えば、追加条件は、すべての参照カードのカードレベルが最大レベルに達している場合に成立してもよいし、所定量のゲーム上のポイントをユーザが所有している場合に成立してもよい。

（２）第２の実施形態
第１の実施形態では、未所持カードの入手条件を示す画像を表示する場合について説明したが、第２の実施形態では、当該入手条件に加えて、未所持カードの入手経路にユーザを誘導するための操作対象を含む画像を表示する場合の一例について説明する。なお、第１実施形態と同様の説明については適宜省略する。

（２−１）入手条件の提示処理およびクエスト処理の具体例
以下、本実施形態のゲームのカードの入手条件の提示処理の具体例について、図１８を参照しながら説明する。図１８は、本実施形態のゲームの処理を実行しているときのユーザ端末１０に表示される画面の一例を示す図である。

（２−１−１）入手条件の提示処理（図１８）
第１の実施形態の図１２Ａの画像Ｐ４において、入手条件を表示すべき参照カード（ここでは、表示領域１０２に「未所持」の状態が示されたカードＤＳＧ）が選択され、且つ、ボタンｂ８が操作されると、図１８に示すように、ユーザによって選択された参照カードの入手条件を示す画像Ｐ５が表示される。

図１８の画像Ｐ５は、表示領域１０３および１０４に加えて、ボタンｂ９（「入手可能エリアへ行く」）を含む点において、第１の実施形態（図１２Ｂの画像Ｐ５）と異なる。ボタンｂ９は、ユーザが未所持カードを入手するためのクエスト処理を要求するときに操作されるボタンである。
なお、ボタンｂ９は、ユーザを入手経路に誘導するための操作対象の一例である。

（２−１−２）クエスト処理（図１８）
画像Ｐ５においてボタンｂ９（「入手可能エリアへ行く」）が操作されると、Ｐ６に示すように画像が変化する。画像Ｐ６では、クエストの実行画面が示される。ユーザは、画像Ｐ６において所定の操作を行うことで、クエストで使用されるエリア（ここでは、エリア１）を探索することができる。クエスト条件が達成されると、ユーザは、クエストデータテーブルの「入手率」の値に応じた確率に基づいて、未所持カードを入手することができる。

（２−２）本実施形態のゲームの処理フロー
次に、本実施形態のゲームの処理フローの一例について、図１９のシーケンスチャートを参照して説明する。
図１９は、クエスト処理を示すシーケンスチャートである。なお、図１９において、図１８に示した各画像Ｐ５〜Ｐ６が表示されるステップに各画像の符号を付してある。

（２−２−１）入手条件の提示処理
本実施形態では、Ｓ４４（図１６Ａ）で、ゲームサーバ２０のＣＰＵ２１が、Ｓ３８で取得した参照カードのカードデータに加えて、当該参照カードの入手経路（ここでは、入手可能エリア）へユーザを誘導するための操作対象を提示するための画像データ（図１８の画像Ｐ５の元になる画像データ）を生成する点において、第１実施形態と異なる。

（２−２−２）クエスト処理（図１９）
図１９において、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図１８の画像Ｐ５のボタンｂ９）が操作されると、ユーザ端末１０のＣＰＵ１１は、クエスト処理の要求を受け付け（Ｓ７０）、当該要求をゲームサーバ２０へ送信する（Ｓ７２）。

ゲームサーバ２０のＣＰＵ２１は、Ｓ７２で送信された要求を受け付けると、クエストデータテーブルから、Ｓ３８で取得したクエストＩＤに対応付けられたクエストデータ（エリア名、消費体力、入手カードデータ（カードＩＤおよび入手率）、入手アイテムデータ（アイテムＩＤおよび入手率）、ボスＩＤ、および、クエストＵＩデータ）に基づいて、クエスト処理の画像データ（図１８の画像Ｐ６の元になる画像データ）を生成し（Ｓ７４）、当該画像データをユーザ端末１０へ送信する（Ｓ７６）。

ユーザ端末１０のＣＰＵ１１は、Ｓ７６で送信された画像データを受け付けると、当該画像データに基づく画像（例えば、図１８の画像Ｐ６）を表示部１６に表示する（Ｓ７８）。

その後、ユーザ端末１０のＣＰＵ１１は、ユーザの操作に応じた指示をゲームサーバ２０へ送信する。ゲームサーバ２０のＣＰＵ２１は、送信された指示に基づいて、クエストを進行させる。クエストが所定レベルまで進行すると、ＣＰＵ２１は、ボスＩＤに対応付けられたボスキャラクタとユーザとの対戦を実行する。ユーザが当該対戦において勝利条件を満たすと、ＣＰＵ２１は、クエストＩＤに対応付けられた「入手率」の値に応じてカードを付与する処理を実行する。カードを付与する処理では、ＣＰＵ２１は、クエストＩＤに対応付けられたカードＩＤを所持カードデータテーブルに書き込むとともに、所持履歴データテーブルにおいて当該カードＩＤに対応付けられた「入手回数」の値を増加させる。これにより、ユーザは、第１の実施形態の図１２Ａの画像Ｐ４において選択したカード（入手条件を表示すべき参照カード）を入手することができる。

以上説明したように、本実施形態のゲームサーバ２０は、ユーザが所持していない参照カードの入手条件と共に、当該参照カードの入手経路へユーザを誘導するための操作対象を提示することで、ユーザは、上記操作対象を操作するだけでオブジェクトを入手するための処理の実行を要求できるため、当該処理の実行を要求するときの操作性を向上させることができる。

（３）第３の実施形態
第２の実施形態では、未所持カードの入手経路にユーザを誘導するための操作対象を含む画像を表示する場合について説明したが、第３の実施形態では、未所持カードの入手経路にユーザを誘導するための操作対象に加えて、未所持カードの入手経路にユーザを誘導し、且つ、当該ユーザが当該未所持カードを入手した後に進化合成の予約処理を実行するための操作対象も含む画像を表示する場合の一例について説明する。なお、上述の実施形態と同様の説明については適宜省略する。

（３−１）入手条件の提示処理、クエスト処理、および、進化合成の予約処理の具体例 以下、本実施形態のゲームのカードの入手条件の提示処理、クエスト処理、および、進化合成の予約処理の具体例について、図２０を参照しながら説明する。図２０は、本実施形態のゲームの処理を実行しているときのユーザ端末１０に表示される画面の一例を示す図である。

（３−１−１）入手条件の提示処理（図２０）
第１の実施形態の図１２Ａの画像Ｐ４において、入手条件を表示すべき参照カード（ここでは、表示領域１０２に「未所持」の状態が示されたカードＤＳＧ）が選択され、且つ、ボタンｂ８が操作されると、図２０に示すように、ユーザによって選択された参照カードの入手条件を示す画像Ｐ５が表示される。
図２０の画像Ｐ５は、表示領域１０３および１０４に加えて、ボタンｂ１０（「予約しない／入手可能エリアへ行く」）と、ボタンｂ１１（「予約する／入手可能エリアへ行く」）と、を含む点において、第１の実施形態（図１２Ｂの画像Ｐ５）と異なる。ボタンｂ１０は、ユーザが未所持カードを入手するためのクエスト処理を要求するときに操作されるボタンである。ボタンｂ１１は、当該クエスト処理および進化合成の予約処理の両方を要求するときに操作されるボタンである。

（３−１−２）クエスト処理（図２０）
画像Ｐ５においてボタンｂ１０（「予約しない／入手可能エリアへ行く」）が操作されると、Ｐ６に示すように画像が変化する。画像Ｐ６は、第２実施形態（図１８の画像Ｐ６）と同様である。

（３−１−３）進化合成の予約処理（図２０）
画像Ｐ５においてボタンｂ１１（「予約する／入手可能エリアへ行く」）が操作されると、クエスト処理とともに、ユーザが所持している参照カードについて予約処理が実行され、予約処理が完了したことを示す画像Ｐ７が表示される。

（３−２）本実施形態のゲームの処理フロー（図２１）
次に、本実施形態のゲームの処理フローの一例について、図２１のシーケンスチャートを参照して説明する。なお、本実施形態の入手条件の提示処理およびクエスト処理は、第２の実施形態と同様に実行される。
図２１は、進化合成の予約処理を示すシーケンスチャートである。なお、図２１において、図２０に示した各画像Ｐ５〜Ｐ７が表示されるステップに各画像の符号を付してある。

以下で説明する予約処理では、一例として、ユーザが、ベースカードを進化合成させるための複数の参照カードのうち、ベースカードの進化合成のために未所持の参照カードを予約する場合を想定する。

図２１において、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図２０の画像Ｐ５のボタンｂ１１）をユーザが操作することによって、ユーザ端末１０のＣＰＵ１１は、進化合成の予約処理の要求を受け付け（Ｓ５０）、当該要求をゲームサーバ２０へ送信する（Ｓ５２）。当該要求には、図２０の表示領域１０３に表示された未所持の参照カードを特定するカードＩＤが含まれる。
なお、Ｓ５２は、ユーザによる操作に基づいて、指定オブジェクトに対して、選択オブジェクトを変化させる処理以外の処理に用いられることを制限させるための要求を受け付ける処理の一例である。

ゲームサーバ２０のＣＰＵ２１は、進化合成の予約処理の要求を受け付けると、予約データテーブルにアクセスし、Ｓ２４（図１６Ａ）で取得したベースカードのシリアル番号に対応する予約ＩＤが発行済みであるか（つまり、「進化前カード」の欄に同一のシリアル番号が記録されているか）否か判定する（Ｓ５４）。
予約ＩＤが発行済みである場合には（Ｓ５４：ＹＥＳ）、Ｓ５８へ進み、予約ＩＤが発行済みでない場合には（Ｓ５４：ＮＯ）、予約ＩＤを発行した後に（Ｓ５６）、Ｓ５８へ進む。Ｓ５８では、ＣＰＵ２１は、予約データテーブルに、当該予約ＩＤに対応付けて仮のシリアル番号を書き込む。このとき、ＣＰＵ２１は、予約ＩＤを新たに発行した場合には、予約対象カードのうちベースカードのシリアル番号を「進化前カード」の欄に書き込み、かつ、その予約ＩＤに対応するＣ１〜Ｃ５の欄のうち、予約対象カードではないカードのカードＩＤに対応する欄に、予約対象カードではないことを示すデータ（例えば、ＮＵＬＬ）を書き込む。

次に、ゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルにおいて、予約対象カードのカードＩＤに対応する「予約ＩＤ」の欄に、Ｓ５８の書き込み対象とした予約ＩＤを書き込む（Ｓ６０）。
なお、Ｓ６０は、指定オブジェクトに対して、選択オブジェクトを変化させる処理以外の処理に用いられることを制限する処理の一例である。

次に、ＣＰＵ２１は、予約が完了したことを示す画像データを生成し（Ｓ６２）、当該画像データをユーザ端末１０へ送信する（Ｓ６４）。ユーザ端末１０のＣＰＵ１１は、Ｓ６６で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図２０の画像Ｐ７）を表示部１６に表示する（Ｓ６６）。

その後、予約対象カードをユーザが入手すると（つまり、当該ユーザの所持カードデータに予約対象カードのカードＩＤおよびシリアル番号が対応付けて記録されると）、ＣＰＵ２１は、Ｓ５８で予約データテーブルに書き込んだ仮のシリアル番号を、所持カードデータに含まれるシリアル番号に書き換える。

なお、図２１において、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図２０の画像Ｐ５のボタンｂ１０）が操作されると、第２実施形態と同様のクエスト処理（図１９）が行われる。

以上説明したように、本実施形態のゲームサーバ２０は、ユーザが所持していない参照カードの入手条件と共に、当該参照カードの入手経路へユーザを誘導し、且つ、当該参照カードを予約する処理を要求するための操作対象を提示することで、予約済カードが目的とする進化合成以外の処理に用いられることを制限可能にする。そのため、ユーザの所持していない残りの参照カードを入手するまでの待機期間において、ユーザが所持しているカードを誤って目的とする進化合成以外の別の処理に使用してしまうことを防止できる。

（４）第４の実施形態
上述の実施形態では、参照カードの入手条件の提示を要求するためのボタンをユーザが操作したときに当該入手条件を示す画像を表示する場合について説明したが、第４の実施形態では、選択したカードを進化合成のベースカードとして確定させるためのボタンをユーザが操作したときに当該ベースカードの進化合成の変化条件を満たすための参照カードの入手条件を示す画像を表示する場合の一例について説明する。なお、上述の実施形態と同様の説明については適宜省略する。

（４−１）入手条件の提示処理の具体例
以下、本実施形態のゲームのカードの入手条件の提示処理の具体例について、図２２を参照しながら説明する。図２２は、本実施形態のゲームの処理を実行しているときのユーザ端末１０に表示される画面の一例を示す図である。

・入手条件の提示処理（図２２）
図２２は、未所持カードの入手条件を提示するための入手条件の提示処理の一連の表示画面の変化を示している。図２２の画像Ｐ１〜Ｐ３は、それぞれ第１の実施形態の図１２Ａの画像Ｐ１〜Ｐ３と同様である。

画像Ｐ３においてボタンｂ６が操作されると、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしていない場合には、Ｐ４に示すように画像が更新される。画像Ｐ４は、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードのうちユーザが所持していないカードの入手条件を提示するための画像である。なお、画像Ｐ３においてユーザがボタンｂ６を選択した時点で、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしている場合には、カードＫＬＭの進化合成を実行するか否かをユーザが指示するための
画像（図示せず）が表示される。

図２２の画像Ｐ４は、表示領域１０２において、進化合成に必要な参照カードおよびその状態（所持、未所持、予約済、未知のいずれか）に加えて、未所持カードまたは未知カードの入手条件が示される点が、第１〜第３の実施形態（図１２Ａ、図１３Ａ、および、図２１Ａの画像Ｐ４）と異なる。表示領域１０２には、一例として、未所持カードの入手経路を示す情報（ここでは、エリア名「エリア１」）が示されている。

（４−２）本実施形態のゲームの処理フロー（図２３）
次に、本実施形態のゲームの処理フローの一例について、図２３のシーケンスチャートを参照して説明する。図２３は、入手条件の提示処理を示すシーケンスチャートである。
なお、図２３において、図２２に示した各画像Ｐ１〜Ｐ４が表示されるステップに各画像の符号を付してある。また、図２３において、図１６Ａおよび図１６Ｂと同一の処理については、同一の符合を付してある。

以下で説明する入手条件の提示処理では、一例として、ユーザが、ベースカードと、当該ベースカードを進化合成させるための複数の参照カードの一部とを所持している場合に、未所持の参照カードの入手条件の提示を要求する場合を想定する。

第１の実施形態のＳ２６（図１６Ａ）が実行された後、ゲームサーバ２０のＣＰＵ２１は、Ｓ２６で読み出した複数の参照カードＩＤに基づいて、カードデータテーブル、クエストデータテーブル、および、カード流通データテーブルから、参照カードのカードデータ（カード名、カード画像、レアリティ、クエストＩＤ、入手可能エリアのエリア名、入手回数、流通数、および、平均取引価格）を取得する（Ｓ３８）。カード名、カード画像、および、レアリティはカードデータテーブルから取得される。クエストＩＤおよび入手可能エリアのエリア名は、クエストデータテーブルから取得される。入手回数は、所持履歴テーブルから取得される。流通数および平均取引価格は、カード流通データテーブルから取得される。

次いで、ゲームサーバ２０のＣＰＵ２１は、Ｓ４０〜Ｓ４２を、それぞれ、第１の実施形態のＳ４０〜Ｓ４２（図１６Ｂ）と同様に実行した後、Ｓ３８で取得した参照カードのカードデータに基づいて、当該参照カードの入手条件をユーザに提示するための画像データ（図２２の画像Ｐ４の元になる画像データ）を生成し（Ｓ４４）、当該画像データをユーザ端末１０へ送信する（Ｓ４６）。

ユーザ端末１０のＣＰＵ１１は、Ｓ４６で送信された画像データを受け付けると、当該画像データに基づいて画像（例えば、図２２の画像Ｐ４）を表示部１６に表示する（Ｓ４８）。

以上説明したように、本実施形態のゲームサーバ２０は、ユーザが所持しておらず、かつ、目的とする進化合成に必要な参照カードの入手条件を、進化合成の対象となるベースカードを選択するユーザの操作に応じて提示することで、ベースカードの進化合成に必要な参照カードの入手条件を提示させる操作の操作性を向上させることができる。

（５）第５の実施形態
上述の実施形態では、未所持カードの入手条件を提示する画面を表示する例について説明したが、本実施形態では、所持カードの入手条件を提示する画面を表示し、かつ、当該画面において、ユーザが指定したカードが何らかの処理に用いられることで消失することを防ぐための処理の例について説明する。

（５−１）本実施形態のゲームのカードの予約登録およびお気に入り登録（図２４）
本実施形態のゲームにおいて、ユーザが所望のベースカードを進化合成によって進化させたいが当該ベースカードを進化させるのに必要な参照カードの一部、あるいはすべてをユーザが所持していない場合を考える。この場合、参照カードの組合せの条件を満たすための新しいカード（つまり、残りの参照カード）をユーザが入手できるまで当該ベースカードの進化合成を実行することを待機する必要がある。しかし、ユーザが、残りの参照カードを入手する前に所持している参照カードを当該ベースカードの進化とは別の用途で使用することで消失させてしまい、かつ、当該参照カードの入手条件を満たすことが困難である場合、当該ベースカードを進化させることが難しくなる。例えば、進化合成を実行する前にユーザが操作を誤って参照カードを消失（一例として、売却）してしまったケースにおいて、当該参照カードを入手できる確率が低い場合、または、当該参照カードを入手できる期間が限られている場合、ユーザは所望のベースカードを進化させることが難しくなる。
そこで、本実施形態では、所望のベースカードを進化させるのに必要となる参照カードを、ユーザの意図に反して消失させてしまうことを確実に防げるようにする。

参照カードの予約登録およびお気に入り登録について、図２４を参照して具体的に説明する。図２４は、参照カードの予約登録およびお気に入り登録を概念的に説明するための図である。
図２４において、ユーザが自身の所持カードであるカードＱを進化させたい場合を考える。ここでは、カードＱを進化させるために、複数の参照カードとしてカードＡ，Ｂ，Ｃの組合せが必要となる場合を想定する。ユーザは現時点でカードＢを所持していないため、カードＱに対する進化合成を実行することはできない。また、カードＡの入手条件を満たすことが困難である場合、ユーザが、カードＡをカードＱの進化以外の用途で使用することによって所持カードから消失させてしまうと、カードＱを進化させることが難しくなる。そのため、本実施形態では、ユーザがカードＡを意図せずに所持カードから消失させてしまうことを防ぐために、カードＡの入手条件の提示をした上で、カードＡに対して、予約登録またはお気に入り登録を受け付ける。
予約登録とは、カードＡを、所持カードから消失させることを条件として実行される処理のうち、ベースカードとして選択されたカードＱの進化合成以外の処理に用いることを制限する状態にすることである。
お気に入り登録とは、カードＡを、所持カードから消失させることを条件として実行される処理（ベースカードとして選択されたカードＱの進化合成も含む）に用いることを制限する状態にすることである。
なお、予約登録及びお気に入り登録は、ユーザによって指定されたオブジェクトである指定オブジェクトに対して、所定の処理に用いられることを制限させる処理の一例である。「所定の処理」とは、指定オブジェクトを所持オブジェクトから消失させることを条件として実行される処理である。つまり、ユーザが所持しているオブジェクトである所持オブジェクトの中から指定されたオブジェクトが、予約登録及びお気に入り登録による制限の対象となるオブジェクトになる。

このように、カードＡの入手条件を提示した上で、カードＡに対する予約登録またはお気に入り登録を受け付けることにより、ユーザは、提示された入手条件からカードＡが入手困難なカードであると認識した直後に、カードＡが所持カードから消失させる処理に用いられることを制限するための要求を行うことができるようになる。したがって、カードＡの意図に反する消失を確実に防ぐことができる。

（５−２）データテーブルの構成
次に、ゲームサーバ２０のストレージ２５に格納される所持カードデータテーブルについて、図２５を参照して順に説明する。

所持カードデータテーブルは、ユーザの所持カードの情報が記録されている。図２５に所持カードデータテーブルの構成例を示す。図２５では１ユーザの分の所持カードデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているすべてのユーザに対応して設けられる。
図２５の所持カードデータテーブルは、カードＩＤごとに登録種別のデータが対応付けられて記録されている点において、図８の所持カードデータテーブルと異なる。
登録情報は、所持カードデータに対して行われた登録の種別（予約登録またはお気に入り登録）と、当該登録の要求が行われた画面の種別（入手条件を提示する画面（以下「入手条件提示画面」という）またはベースカード毎の進化合成に必要な参照カード一覧画面」という））との組合せを示すデータである。図２５の例では、入手条件提示画面を経由して予約登録が行われたカードについては登録情報に「１」が記録され、入手条件提示画面を経由してお気に入り登録が行われたカードについては登録情報に「２」が記録され、覧画面を経由してお気に入り登録が行われたカードについては登録情報に「４」が記録され、予約登録およびお気に入り登録のいずれも行われていないカードには「Ｎ／Ａ」が記録される。

（５−３）本実施形態のゲームの表示処理の具体例
（５−３−１）本実施形態のゲームの入手条件提示画面の表示処理の具体例（図２６）
第１の実施形態の図１２Ａの画像Ｐ４において、入手条件を表示すべき参照カードが選択され、且つ、ボタンｂ８が操作されると、図２６に示すように、ユーザによって選択された参照カードの入手条件提示画面に相当する画像Ｐ５が表示される。

図２６の画像Ｐ５は、ボタンｂ１２（「予約登録」）およびボタンｂ１３（「お気に入り登録」）を含む点において、第１の実施形態（図１２Ｂの画像Ｐ５）と異なる。
ボタンｂ１２（「予約登録」）は、ユーザが所持カードの予約登録を要求するときに操作されるボタンである。
ボタンｂ１３（「お気に入り登録」）は、ユーザが所持カードのお気に入り登録を要求するときに操作されるボタンである。

画像Ｐ５においてボタンｂ１２（「予約登録」）が操作されると、Ｐ２１に示すように画像が変化する。画像Ｐ２１では、予約登録の処理の実行結果が示される。
画像Ｐ５においてボタンｂ１３（「お気に入り登録」）が操作されると、Ｐ２２に示すように画像が変化する。画像Ｐ２２では、お気に入り登録の処理の実行結果が示される。

（５−３−２）本実施形態のゲームの変化条件一覧画面の表示処理の具体例（図２７Ａ〜図２７Ｃ）
第１の実施形態の図１２Ａの画像Ｐ１において、ボタンｂ４（「進化合成」）が操作されると、図２７Ａに示すように、本実施形態の変化条件一覧画面に相当する画像Ｐ２３ａが表示される。画像Ｐ２３ａは、変化条件一覧画面ともいう。

画像Ｐ２３ａは、表示領域１０５と、ボタンｂ１２（「予約登録」）と、ボタンｂ１３（「お気に入り登録」）とを含む。ボタンｂ１２（「予約登録」）およびボタンｂ１３（「お気に入り登録」）は、図２６の画像Ｐ５と同様である。
表示領域１０５には、ベースカードおよび参照カードのカード画像およびカード名が、ベースカードと参照カードの組合せ毎に表示される。換言すると、表示領域１０５には、ベースカード毎の参照カードが表示される。図２７Ａの例では、カードＫＬＭの進化合成に必要な参照カードがカードＶＩＣ、ＤＳＧ、および、ＭＩＴであり、カードＳＡＭの進化合成に必要な参照カードがカードＭＩＴ、ＫＡＹ、および、ＴＥＤである。
表示領域１０５では、参照カードについて、所持カードと未所持カードが識別可能に表示される。図２７Ａの例では、カードＶＩＣ、ＤＳＧ、ＭＩＴ、および、ＫＡＹが所持カードであることを示す実線で表示され、かつ、カードＴＥＤが未所持カードであることを示す破線で表示される。
また、表示領域１０５には、入手条件提示画面を経由して行われた予約登録の対象となったカードのカード画像上にマークｍ１が表示される。マークｍ１は、所持カードから消失させることを条件として実行される処理のうち、ベースカードの進化合成以外の処理に用いることが制限された状態にあるカードのカード画像上に表示されるマーク（「記号」、「印」などともいう。）である。図２７Ａの例では、カードＫＬＭのカード画像上、および、カードＤＳＧのカード画像上にマークｍ１が表示されている。つまり、図２７Ａは、カードＤＳＧが、カードＤＳＧを所持カードから消失させることを条件に実行される処理のうち、カードＫＬＭの進化合成以外の処理に用いることが制限された状態にあることを示している。
また、表示領域１０５には、覧画面を経由して行われたお気に入り登録の対象となったカードのカード画像上にマークｍ２が表示される。マークｍ２は、所持カードから消失させることを条件として実行される処理（ベースカードの進化合成も含む）に用いることが制限された状態にあるカードのカード画像上に表示されるマークである。図２７Ａの例では、カードＫＡＹのカード画像上にマークｍ２が表示されている。つまり、図２７Ａは、カードＫＡＹが、カードＫＡＹを所持カードから消失させることを条件に実行される処理の全て（例えば、カードＳＡＭの進化合成の処理、および、カードＫＡＹの売却処理）に用いることが制限された状態にあることを示している。
ユーザは、カード画像を選択することにより、当該カード画像に対応するカードを選択状態にするができる。図２７Ａの例では、カード画像ｂ１４が選択された場合、カードＫＬＭの進化合成に必要な参照カードとしてのカードＭＩＴが選択状態になり、カード画像ｂ１５が選択された場合、カードＳＡＭの進化合成に必要な参照カードとしてのカードＭＩＴが選択状態になる。
ユーザは、カードを選択状態にした上でボタンｂ１２（「予約登録」）またはボタンｂ１３（「お気に入り登録」）を操作すると、選択状態にあるカードに対する予約登録またはお気に入り登録を要求できる。図２７Ａの例では、カード画像ｂ１４を選択した上でボタンｂ１２（「予約登録」）またはボタンｂ１３（「お気に入り登録」）を操作すると、カードＫＬＭの進化合成に必要な参照カードとしてのカードＭＩＴに対する予約登録またはお気に入り登録が要求される。

画像Ｐ２３ａにおいて、ユーザがカード画像ｂ１４を選択した上でボタンｂ１２（「予約登録」）を操作すると、画像Ｐ２３ｂに変化する。画像Ｐ２３ｂは、マークｍ３が、カードＫＬＭの進化合成に必要な参照カードとしてのカードＭＩＴのカード画像上に表示されている点において、画像Ｐ２３ａと異なる。マークｍ３は、変化条件一覧画面を経由して行われた予約登録の対象となった参照カードを示すマークである。
カードＳＡＭの進化合成に必要な参照カードとしてのカードＭＩＴのカード画像上には、マークｍ４が表示される。マークｍ４は、他のベースカード（カードＫＬＭ）の進化合成に必要な参照カードとして予約登録が行われたことを示すマークである。
図２７Ｂの例では、カードＫＬＭの進化合成に必要な参照カードとしてのカードＭＩＴのカード画像上に、マークｍ３が表示され、かつ、カードＳＡＭの進化合成に必要な参照カードとしてのカードＭＩＴのカード画像上に、マークｍ４が表示されている。この場合、カードＭＩＴに対して、カードＭＩＴを所持カードから消失させることを条件に実行される処理のうち、カードＫＬＭの進化合成以外の処理に用いることが制限される。つまり、カードＭＩＴは、カードＫＬＭの進化合成の処理に用いることはできるが、カードＳＡＭの進化合成の処理や売却処理に用いることはできなくなる。

画像Ｐ２３ａにおいて、ユーザがカード画像ｂ１４を選択した上でボタンｂ１３（「お気に入り登録」）を操作すると、画像Ｐ２３ｃに変化する。画像Ｐ２３ｃは、マークｍ５がカードＭＩＴのカード画像上に表示されている点において、画像Ｐ２３ａと異なる。マークｍ５は、変化条件一覧画面を経由して行われたお気に入り登録の対象となった参照カードを示すマークである。
図２７Ｂの例では、カードＫＬＭの進化合成に必要な参照カードとしてのカードＭＩＴのカード画像、および、カードＳＡＭの進化合成に必要な参照カードとしてのカードＭＩＴのカード画像上に、マークｍ５が表示されている。この場合、カードＭＩＴに対して、カードＭＩＴを所持カードから消失させることを条件に実行される処理の全てに用いることが制限される。つまり、カードＭＩＴは、カードＫＬＭの進化合成の処理、カードＳＡＭの進化合成の処理、および、売却処理のいずれにも用いることはできなくなる。

画像Ｐ２３ａ〜Ｐ２３ｃにおいて、マークｍ１〜ｍ５は、互いに識別可能な形状、パターン、または、それらの組合せにより表示される。これにより、ユーザは、入手条件提示画面を経由して行われた予約登録の対象となった参照カード、入手条件提示画面を経由して行われたお気に入り登録の対象となった参照カード、変化条件一覧画面を経由して行われた予約登録の対象となった参照カード、および、変化条件一覧画面を経由して行われたお気に入り登録の対象となった参照カードを容易に識別できるようになる。
具体的には、マークｍ１〜ｍ５については、登録の種類（予約登録またはお気に入り登録）がマークの形状により識別され、かつ、登録の要求が行われた画面（入手条件提示画面、または、変化条件一覧画面）がマークのパターンにより識別される。

（５−４）本実施形態の登録の処理の処理フロー（図２８）
次に、本実施形態のゲームの処理フローの一例について、図２８のシーケンスチャートを参照して説明する。図２８は、登録の処理を示すシーケンスチャートである。
なお、図２８において、図２６に示した各画像Ｐ５、Ｐ２１、および、Ｐ２２が表示されるステップに各画像の符号を付してある。また、図２８において、図１６Ｂと同一の処理については、同一の符合を付してある。

以下で説明する登録の処理では、ユーザにより指定されたオブジェクトである指定オブジェクトに対して、所定の処理に用いられることを制限するための処理の一例として、予約登録の処理またはお気に入り登録の処理を要求する場合を想定する。

第１の実施形態のＳ４８（図１６Ｂ）が実行された後、ゲームサーバ２０のＣＰＵ２１は、図２６の画像Ｐ５上に表示されたボタンｂ１２（「予約登録」）またはボタンｂ１３（「お気に入り登録」）に対するユーザの操作に基づいて、予約登録の処理の要求またはお気に入り登録の処理の要求を受け付け（Ｓ１７０）、当該要求をゲームサーバ２０に送信する（Ｓ１７１）。
なお、図２６の画像Ｐ５は、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための出力データの一例である。
予約登録の処理の要求には、ユーザＩＤと、ベースカードのシリアル番号と、参照カードのシリアル番号と、予約登録の処理の要求が行われたときに表示されていた画像の種類（例えば、図２６の画像Ｐ５または図２７Ａの画像Ｐ２３ａ）を特定する情報（つまり、予約登録の処理の要求を行うために経由した画面の種類を特定する情報）と、予約登録の処理の要求であることを特定する情報とが含まれる。
お気に入り登録の処理の要求には、ユーザＩＤと、参照カードのシリアル番号と、お気に入り登録の処理の要求が行われたときに表示されていた画像の種類（例えば、図２６の画像Ｐ５または図２７Ａの画像Ｐ２３ａ）を特定する情報（つまり、お気に入り登録の処理の要求を行うために経由した画面の種類を特定する情報）と、お気に入り登録の処理の要求であることを特定する情報とが含まれる。
予約登録の処理の要求およびお気に入り登録の処理の要求は、ユーザにより指定されたオブジェクトである指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求の一例である。

ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０から要求を受け付けると、当該要求に応じた登録（予約登録、または、お気に入り登録）の処理を実行する（Ｓ１７２）。
なお、Ｓ１７２の処理は、指定オブジェクトに対して、所定の処理に用いられることを制限する処理の一例である。

Ｓ１７０で受け付けられた要求が予約登録の処理の要求である場合、ＣＰＵ２１は、当該要求に含まれる参照カードのシリアル番号によって特定される所持カードデータに対して、入手条件提示画面を経由して行われた予約登録の対象となるカードであることを示す登録情報（図２５の登録情報「１」）を記録する。また、ＣＰＵ２１は、当該要求に含まれるベースカードのシリアル番号によって特定される予約データに対して、Ｃ１〜Ｃ５のうち当該参照カードのカードＩＤに対応する欄に、当該参照カードのシリアル番号を記録する。これにより、予約登録の対象となる参照カードのシリアル番号について、当該予約登録の対象となるベースカードのシリアル番号以外のシリアル番号によって特定される予約データに記録する（つまり、当該参照カードを、当該ベースカード以外のベースカードの進化合成のために予約する）こと、および、所持カードデータから削除すること（つまり、当該参照カードを所持カードから消失させる（例えば、売却処理を実行する）こと）が制限される。
一方、Ｓ１７０で受け付けられた要求がお気に入り登録の処理の要求である場合、ＣＰＵ２１は、当該要求に含まれる参照カードのシリアル番号によって特定される所持カードデータに対して、入手条件提示画面を経由して行われたお気に入り登録の対象となるカードであることを示す登録情報（図２５の登録情報「２」）を記録する。これにより、お気に入り登録の対象となる参照カードのシリアル番号について、予約データテーブルに対してシリアル番号を記録すること、および、所持カードデータから削除すること（つまり、当該参照カードを所持カードから消失させること）が制限される。

次いで、ＣＰＵ２１は、登録の処理の実行結果をユーザ端末１０に送信する（Ｓ１７３）。

ユーザ端末１０のＣＰＵ１１は、ゲームサーバ２０から登録の処理の実行結果を受け付けると、当該実行結果に基づく画面を表示する（Ｓ１７４）。これにより、ユーザ端末１０の表示部１６に、図２６の画像Ｐ２１またはＰ２２が表示される。
なお、Ｓ１７４は、予約登録による制限の対象となっているオブジェクトと、お気に入り登録による制限の対象となっているオブジェクトとを、ユーザにそれぞれ識別可能な表示形式で表示させるためのデータを出力する処理の一例である。

図２５の登録情報を用いることで、図２７Ａ〜図２７Ｃに示すように、マークｍ１〜ｍ５を用いて、登録の種類と、登録の要求が行われたときに表示されていた画面の種類とを、ユーザが識別できるように表示することができる。例えば、ユーザが、図１２Ａの画像Ｐ１のボタンｂ４（「進化合成」）を操作すると、表示部１６には、Ｓ１７２において予約登録の処理が実行された場合、図２７Ｂの画像Ｐ２３ｂが表示され、Ｓ１７２においてお気に入り登録の処理が実行された場合、図２７Ｃの画像Ｐ２３ｃが表示される。

以上説明したように、本実施形態のゲームサーバ２０は、入手条件提示画面において、所持している参照カードに対して、ベースカードの進化合成以外の処理に用いられることを制限するための予約登録の処理の要求、または、所持カードから消失させることを条件として実行される処理（ベースカードの進化合成の処理を含む）に用いられることを制限するためのお気に入り登録の処理の要求を受け付ける。
これにより、ユーザは、入手条件提示画面において、所持している参照カードの入手が困難であることを認識した直後に、当該参照カードが意図に反して消失しない状態にすることができるようになる。
特に、ベースカードとなるカードおよび当該ベースカードの進化合成に用いられる参照カードの所持数が多くなるほど、ユーザにとって、どの参照カードをどのベースカードの進化合成に使うべきかを管理することが困難になる。その結果、ユーザが、操作ミスや参照カードの用途の忘却により、ユーザの意図に反して参照カードを消失させてしまう虞が生じる。
これに対して、本実施形態では、ユーザが入手条件提示画面から入手が困難な参照カードであることを認識した直後に、当該参照カードに対して、当該参照カードを消失させることを条件として実行される処理に用いられることを制限するための要求を行うことができる。したがって、ユーザの意図に反する当該参照カードの消失を確実に防ぐことができる。

また、本実施形態では、ユーザは、２種類の登録（予約登録およびお気に入り登録）の要求を行うことができる。したがって、ユーザは、目的に応じて登録を使い分ける（つまり、参照カードに対してかける制限の範囲を選択する）ことができる。例えば、参照カードを、特定のベースカードの進化合成で使用したいユーザは、予約登録の要求を行うことにより、特定のベースカードの進化合成以外の処理を実行することによる参照カードの消失を防ぐことができる。また、参照カードを用いて進化させるベースカードを決めずに、当該参照カードが消失することを防ぎたいユーザは、お気に入り登録の要求を行うことにより、当該参照カードの消失を確実に防ぐことができる。したがって、ユーザは、参照カードの用途を、柔軟に管理できるようになる。

また、本実施形態のゲームサーバ２０は、変化条件一覧画面において、変化条件一覧画面を経由して行われた予約登録の対象となった参照カードと、入手条件提示画面を経由して行われたお気に入り登録の対象となった参照カードとを、識別可能に表示する。
さらに、本実施形態のゲームサーバ２０は、予約登録の対象となったベースカードおよび参照カードの組合せを識別可能に表示する。
さらに、本実施形態のゲームサーバ２０は、予約登録の対象となった参照カードと、お気に入り登録の対象となった参照カードとを識別可能に表示する。
これにより、ユーザは、所持カードの用途（具体的には、特定のベースカードの進化合成に使用すること、または、用途は未定であるものの保持しておくこと）を視覚的に把握できるようになる。

（５−５）本実施形態の変形例
以下、本実施形態の変形例について説明する。なお、以下の変形例は、適宜組合せ可能である。
（５−５−１）第１の変形例
本実施形態では、登録（予約登録、または、お気に入り登録）の対象となる参照カードが所持カードである場合について説明した。しかし、本実施形態は、登録の対象となる参照カードは、未所持カードであってもよい。
例えば、変化条件一覧画面を、予約登録の要求、または、お気に入り登録の要求を受付可能に構成する。変化条件一覧画面を経由して当該要求が受け付けられた場合、当該要求の対象となるカードをユーザが入手した（つまり、当該カードのカードＩＤおよびシリアル番号が所持カードデータテーブルに記録された）後に、当該カードについて、予約登録の処理、または、お気に入り登録の処理を実行する。

（５−５−２）第２の変形例
本実施形態では、変化条件一覧画面にマークｍ１〜ｍ５を表示する例を説明したが、変化条件一覧画面以外の画面にマークｍ１〜ｍ５を表示してもよい。

一例として、入手条件提示画面（例えば、予約登録の処理の実行結果が示される画像Ｐ２１、または、お気に入り登録の処理の実行結果が示される画像Ｐ２２）にマークｍ１〜ｍ５を表示してもよい。

別の例として、所持カードの一覧を示す画面（以下「所持カード一覧画面」という）にマークｍ１〜ｍ５を表示してもよい。
具体的には、画像Ｐ１においてボタンｂ１（「所持モンスターを見る」）が操作されると、所持カード一覧画面が表示される。所持カード一覧画面には、図２７Ａ〜図２７Ｃの変化条件一覧画面のように、所持カードに関する情報（例えば、カード画像およびカード名）が一覧表示される。所持カードのうち、予約登録またはお気に入り登録の対象となったカードのカード画像には、マークｍ１〜ｍ５のいずれかが表示される。

（５−５−３）第３の変形例
本実施形態では、選択状態にあるカードに対する予約登録またはお気に入り登録の要求を受け付ける例について説明したが、当該カードに対する登録の解除の要求を受け付けてもよい。

例えば、図２７Ａ〜図２７Ｃのマークｍ１〜ｍ５のいずれかが表示されているカード画像がユーザによって選択された場合、選択されたカード画像に対応するカード（つまり、予約登録またはお気に入り登録された状態にあるカード）に対する予約登録またはお気に入り登録の解除の要求を受け付ける。具体的には、図２７Ａにおいて、マークｍ１が表示されているカード画像が選択された場合、予約登録がなされたカードＤＳＧが選択状態になり、かつ、登録の解除の要求を行うときに指定されるボタンが表示される。このとき、ユーザによって当該ボタンが操作されると、カードＤＳＧに対してなされた予約登録が解除され、カード画像に表示されていたマークｍ１が消える。これにより、当該カードＤＳＧは、何らの登録もなされていない状態（つまり、全ての処理に用いることができる状態）になる。

本変形例によれば、用途が決まっていないときに行ったお気に入り登録の対象となる参照カードに対して、当該お気に入り登録を解除し、かつ、予約登録を行うことができる。また、特定のベースカードに対する進化合成に用いるという用途が決まっているときに行った予約登録の対象となる参照カードに対して、当該予約登録を解除し、かつ、お気に入り登録を行うことができる。したがって、ユーザは、参照カードの用途と当該参照カードにかける制限の範囲を、柔軟に管理できるようになる。

（５−５−４）第４の変形例
本実施形態では、図２６、および、図２７Ａ〜図２７Ｃに示すように、ボタンｂ１２（「予約登録」）と、ボタンｂ１３（「お気に入り登録」）とを並べて表示する例について説明したが、これらの２つのボタンについては、何れか一方のみを表示してもよい。

（５−５−５）第５の変形例
本実施形態では、図２６の画像Ｐ５に示すような入手条件提示画面を経由して予約登録またはお気に入り登録の処理の要求が行われる例について説明したが、図２７の画像Ｐ２３ａに示すような変化条件一覧画面を経由して当該要求が行われてもよい。以下、変化条件一覧画面を経由して当該要求が行われる場合の登録の処理の例を、図２８を参照して説明する。

具体的には、画像Ｐ２３ａのカード画像ｂ１４が選択された状態でボタンｂ１２（「予約登録」）またはボタンｂ１３（「お気に入り登録」）に対するユーザの操作が行われると、ユーザ端末１０のＣＰＵ１１は、当該操作に基づいて、予約登録の処理の要求またはお気に入り登録の処理の要求を受け付け（Ｓ１７０）、当該要求をゲームサーバ２０に送信する（Ｓ１７１）。

ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０から要求を受け付けると、当該要求に応じた登録（予約登録、または、お気に入り登録）の処理を実行し（Ｓ１７２）、登録の処理の実行結果をユーザ端末１０に送信する（Ｓ１７３）。

ユーザ端末１０のＣＰＵ１１は、ゲームサーバ２０から登録の処理の実行結果を受け付けると、当該実行結果に基づく画面を表示する（Ｓ１７４）。これにより、ユーザ端末１０の表示部１６に、図２７Ｂの画像Ｐ２３ｂまたは図２７Ｃの画像Ｐ２３ｃが表示される。

以上の通り、本変形例における登録の処理は、４種類の登録（入手条件提示画面を経由して行われた予約登録、入手条件提示画面を経由して行われたお気に入り登録、変化条件一覧画面を経由して行われた予約登録、および、変化条件一覧画面を経由して行われたお気に入り登録）の処理を含む。各画面には、当該４種類の登録をユーザが識別できるような表示形式で、カードに関する情報が表示される。

（６）第６の実施形態
上述の実施形態では、ユーザ端末１０とゲームサーバ２０との間でＨＴＴＰに従った通信が行われ、ユーザ端末１０がゲームサーバ２０から取得するＨＴＭＬ文書を解釈することでゲーム画像を表示する、いわゆるブラウザ形式によって本発明が実現される場合について説明したが、この場合に限られない。ユーザ端末１０がダウンロードしたゲームプログラムを実行することでユーザ端末１０が主体的にゲームの処理を実行し、ユーザ端末１０とゲームサーバ２０の間の送受信処理を抑制した、いわゆるネイティブアプリケーション形式によって実現してもよい。ネイティブアプリケーション形式では、ウェブブラウザを利用せずに、ユーザ端末１０のＣＰＵ１１が画像データを生成することで、表示部１６に画像を表示する。
本実施形態では、上述の実施形態のゲームをネイティブアプリケーション形式によって実現する場合の一例について説明する。なお、本実施形態のハードウエア構成は、第１の実施形態と同じ構成でよい。本実施形態のネイティブアプリケーション形式では、処理のほとんどをユーザ端末１０側で行うことを想定しているが、以下で説明しないゲームの処理の一部（例えば、ユーザに抽選によって付与する抽選処理や、ゲーム運営者がユーザにカードを付与するプレゼント処理等）については、ゲームサーバ２０側で処理を実行し、ゲームサーバ２０による処理結果をユーザ端末１０へ送信するように構成してもよい。

本実施形態では、ユーザ端末１０がユーザによる所定の操作に基づいて、ゲーム運営者のサーバからゲームプログラムを受信し、受信したゲームプログラムがストレージ１８に格納される。ユーザ端末１０によってゲームが起動されると、ユーザ端末１０とゲームサーバ２０との間で通信が確立されてログイン処理が行われ、ゲームサーバ２０からユーザ端末１０へデータテーブル群（カードデータテーブル、進化合成データテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブル）が送信される。ユーザ端末１０に送信されるデータテーブル群は、ユーザ端末１０のストレージ１８内に保持される。この場合、ストレージ１８内のデータテーブル群は、ログインの度に更新される。
所持カードデータテーブルがユーザ端末１０において改竄されることを防止するため、ユーザ端末１０による所定の処理が終了する度、あるいは、ゲームからログアウトする時点で、ユーザ端末１０内の所持カードデータテーブルがゲームサーバ２０へ送信される。ゲームサーバ２０では、受信した所持カードデータテーブルと、ストレージ２５内の所持カードデータテーブルとを比較し、データの改竄が行われていないことを確認した後に、受信した所持カードデータテーブルに基づいて、ストレージ２５内の所持カードデータテーブルを更新する。

図２９Ａおよび図２９Ｂは、本実施形態の入手条件の提示処理を示すシーケンスチャートである。図２９Ａおよび図２９Ｂの各図において、図１６Ａおよび図１６Ｂと同一の処理については、同一の符合を付してある。
本実施形態の進化合成の予約処理（図２９Ａおよび図２９Ｂ）では、例えばログイン時に、ゲームサーバ２０はユーザ端末１０へ、ストレージ２５内のデータテーブル群（カードデータテーブル、進化合成データテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブル）を送信する（Ｓ８）。ユーザ端末１０のＣＰＵ１１は、受信したデータテーブル群をストレージ１８に記憶するとともに、操作入力部１５からの操作入力に基づいて、ＲＡＭ１３および表示部１６等と協働してＳ１４〜Ｓ４８の処理を実行する。
なお、図示しないが、本実施形態では、進化合成処理、クエスト処理、および、進化合成の予約処理についても同様にして、ユーザ端末１０が主体的に実行する。
本実施形態では、カードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブルがゲームサーバ２０において保持され、予約データテーブルがユーザ端末１０において保持される場合について説明したが、この場合に限られない。ネイティブアプリケーション形式のゲームでは、各データテーブルの保持分担については適宜設定することが可能であって、ユーザ端末１０およびゲームサーバ２０の少なくともいずれかに保持されるようにすればよく、特定の保持態様に限定されるものではない。ゲームサーバ２０にいずれかのデータテーブルが保持される場合には、ゲームの実行時にゲームサーバ２０に保持されるデータテーブルがユーザ端末１０へ送信され、ユーザ端末１０内で行われるゲームの処理に利用される。

（７）全ての実施形態に共通する変形例
（７−１）ゲーム以外のアプリケーションへの適用に関する変形例
上述した実施形態および変形例では、本発明がゲームに適用される場合について説明したが、他のアプリケーションに適用してもよい。例えばインターネット上のショッピングモールで商品を購入する度に複数種類の電子クーポン券を配布している場合、その電子クーポン券を本発明のオブジェクトの一例としてもよい。この場合、例えばベースオブジェクトとしてのクーポン券Ｑの特典内容をアップグレード（オブジェクトを変化させる処理の一例）するために、クーポン券Ｑに対応する参照オブジェクトとしてのクーポン券Ａ〜Ｃをユーザが所持し利用することが考えられる。この例において、クーポン券Ｑをアップグレードすること目的として、そのために必要なクーポン券Ａ〜Ｃのうち、ユーザが所持していないクーポン券（例えば、クーポン券Ｂ）の入手条件を提示する。
上述した例示以外の他のアプリケーションについても適宜適用可能である。

（７−２）操作入力の方式に関する変形例
上述した実施形態では、ユーザ端末に対する所定の操作入力は、ユーザ端末に対する所定の指示釦の押下操作の入力や、タッチパネル機能を備えたユーザ端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えたユーザ端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えたユーザ端末に対する所定のジェスチャを行うことでユーザ端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能なユーザ端末の場合には、操作入力は、音声を入力することにより行われてもよい。

（７−３）ユーザＩＤの取扱に関する変形例
上述した実施形態では、ユーザ端末１０からゲームサーバ２０に送信される要求にユーザＩＤが含まれている（つまり、ゲームサーバ２０は、ユーザ端末１０から送信される要求に基づいて、処理の要求を行ったユーザを特定できる）ことを前提に説明したが、ゲームサーバ２０が処理の要求を行ったユーザを特定する方法はこれに限られない。
例えば、ユーザ端末１０とゲームサーバ２０との間でユーザＩＤに基づくセッションが確立された場合、ゲームサーバ２０は、当該ユーザＩＤによって、当該セッション以降の処理の要求を行うユーザを特定してもよい。この場合、ユーザ端末１０からゲームサーバ２０に送信される要求にユーザＩＤを含めなくてよい（つまり、ユーザ端末１０からゲームサーバ２０にユーザＩＤを送信しなくてよい）。

（７−４）操作対象に関する変形例
上述した実施形態では、画像上に表示されたボタンをユーザによる操作対象の一例として示したが、ユーザによる操作が可能な形式であればどのような形式であってもよい。

［発明のまとめ］
以上の記載から本発明は例えば以下のように把握される。

本発明の一態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データを出力する出力手段（５６）と、
前記出力手段（５６）により前記第１出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段（５１）と、を備え、
前記出力手段（５６）は、さらに、前記受付手段（５１）により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第２出力データを出力する、
情報処理装置。

「情報処理装置」は、スタンドアローンのゲーム機、あるいはユーザ端末（例えば、携帯端末やパーソナルコンピュータ等）やネットワーク上のサーバなどであってもよい。ゲームの実現形態によって適宜情報処理装置の実体を定義することができる。例えば、ユーザがゲーム機やユーザ端末を操作することで情報処理装置の各部の機能が実現される場合には、ゲーム機やユーザ端末が本発明の情報処理装置に相当する。あるいは、クライアントであるユーザ端末がユーザからの操作入力の受付や画像の表示の機能を有し、情報処理装置の各部の機能が実質的にユーザ端末と通信可能なサーバによって実現される場合には、サーバが本発明の情報処理装置に相当する。
「記憶装置」は、例えばフラッシュメモリやＨＤＤ(Hard Disk Drive)等、如何なる構成のメモリデバイスであってもよい。また、記憶装置は、情報処理装置に内蔵された装置であってもよいし、情報処理装置から有線または無線でアクセス可能に構成された外部の装置であってもよい。
「入手条件」とは、主体的条件（例えば、オブジェクトを所持しているユーザに関する情報）、時期的条件（例えば、オブジェクトの入手可能期間）、内容的条件（例えば、平均取引価格、第１オブジェクト（例えば、カード）の入手に必要な第２オブジェクト（例えば、アイテム）、または、それらの組合せ）、場所的条件（例えば、入手可能なエリア）、または、それらの組合せであってもよい。

上記情報処理装置において、選択オブジェクトを変化させる処理の実行は、少なくとも複数のオブジェクトを示す情報を含む変化条件と、ユーザの所持情報とに基づいて行われる。そのため、例えば変化条件を満たさない場合には、選択オブジェクトを変化させる処理の実行を実行することができない。このとき、ユーザが所持していない指定オブジェクトの入手が、当該ユーザにとって不可能または困難である場合がある。しかし、指定オブジェクトの入手条件を知らないユーザは、指定オブジェクトの入手が不可能または困難であることを、指定オブジェクトを入手するための処理（例えば、クエスト処理）を実行するか否かを決断する時点で認識できない。このような場合、ユーザは、実際には参照オジェクトの入手が不可能または困難かもしれないという不安を抱えたまま、指定オブジェクトを入手するための処理を実行することになる。
上記情報処理装置では、ユーザからの要求に応じて、ユーザが所持していない参照オブジェクトの入手条件を提示する。そのため、選択オブジェクトに対応する複数の参照カードの中に、ユーザにとって入手が不可能または困難な指定オブジェクトがあったとしても、ユーザは、指定オブジェクトの入手が不可能または困難であることを認識した上で、指定オブジェクトを入手するための処理を実行するか否かを決断できる。その結果、指定オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。

前記受付手段（５１）は、さらに、前記出力手段（５６）により前記第２出力データが出力されたことに応じて、前記ユーザによる操作に基づいて、前記指定オブジェクトに対して、前記選択オブジェクトを変化させる処理以外の処理に用いられることを制限させるための要求を受け付け、
前記受付手段（５１）により前記要求が受け付けられたことに応じて、前記指定オブジェクトに対して、前記選択オブジェクトを変化させる処理以外の処理に用いられることを制限する制限手段（５８）をさらに備えてもよい。
「選択オブジェクトを変化させる処理とは異なる処理に用いられることを制限する」とは、選択オブジェクトを変化させる処理以外の処理自体が禁止されることに限られず、選択オブジェクトを変化させる処理は実行可能であるが、その処理の実行の要求に必要な要件を増やす、あるいは処理の実行の要求に必要な操作を煩雑にすることであってもよい。
これによって、ユーザからの要求に応じて、選択オブジェクトを変化させる処理以外の処理に指定オブジェクトが用いられることが制限される。そのため、変化条件を満たす前に、ユーザが誤って、選択オブジェクトを変化させる処理以外の処理に指定オブジェクトを使用してしまうことを防止できる。

前記入手条件は、前記指定オブジェクトの入手経路であってもよい。
「入手経路」は、例えば、指定オブジェクトの入手可能エリアであってもよいし、ユーザ間でオブジェクトを取引可能なエリア（例えば、ゲーム内のショップ）であってもよい。
また、「入手経路」は、時期的条件と場所的条件の組合せ（例えば、指定オブジェクトが期間限定で発行されたものか否かを示す情報（一例として、限定フラグ）、期間限定の入手可能エリアの開催期間（一例として、期間限定クエストが開催される曜日）、または、それらの組合せ）であってもよい。
これによって、指定オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。特に、「入手経路」が時期的条件と場所的条件の組合せである場合には、ユーザが選択オブジェクトを変化させる処理の実行要求を行うときに、指定オブジェクトの入手が不可能または困難であるか否かをより正確に判断するための情報が提示されるので、特に有益である。

前記第２出力データは、ユーザを前記入手経路に誘導するための操作対象を含んでもよい。
これによって、指定オブジェクトを入手するための処理の実行を要求するときの操作性を向上させることができる。

前記第２出力データは、前記指定オブジェクトが、前記ユーザにより所持されたことがあり、且つ、前記取得手段（５５）によって指定オブジェクトを示す情報が取得された時点で前記ユーザにより所持されていない、未所持オブジェクトである場合、前記指定オブジェクトの入手経路および入手難易度の少なくとも１つを含んでもよい。
これによって、未所持オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。

前記入手条件として表示される情報は、前記指定オブジェクトが前記ユーザにより所持されたことがない未知オブジェクトである場合、前記指定オブジェクトが前記未所持オブジェクトである場合に比べて制限されてもよい。
これによって、ゲームの難易度を適切なレベルに保ちながら、未知オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。

本発明の別の態様は、
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理システムであって、
前記ユーザ端末、および、前記サーバのいずれかが、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データを出力する出力手段（５６）と、
前記出力手段（５６）により前記第１出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段（５１）と、を備え、
前記出力手段（５６）は、さらに、前記受付手段（５１）により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第２出力データを出力する、
情報処理システムである。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータを、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第１出力データを出力する手段（５６）、
前記第１出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける手段（５１）、
前記受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第２出力データを出力する手段（５６）、
として機能させるためのプログラムである。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第１出力データを出力する第１出力手段と、
前記第１出力手段により前記第１出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第１指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第１受付手段と、
前記第１受付手段により前記要求が受け付けられたことに応じて、前記第１指定オブジェクトに対して、前記処理に用いられることを制限する第１制限手段と、
を備える、情報処理装置である。

これによって、ユーザは、入手条件を提示する画面において参照カードの入手が困難であることを認識した直後に、当該参照カードが消失しない状態にすることができるようになる。したがって、参照カードの意図に反する消失を確実に防ぐことができる。

また、複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための
第２出力データを出力する第２出力手段と、
前記第２出力手段により前記第２出力データが出力されたことに応じて、前記複数のオブジェクトのうちユーザに指定されたオブジェクトである第２指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第２受付手段と、
前記第２受付手段により前記要求が受け付けられたことに応じて、前記第２指定オブジェクトに対して、前記処理に用いられることを制限する第２制限手段と、をさらに備え、
前記第１出力データおよび前記第２出力データの少なくとも１つは、前記第１制限手段による制限の対象となっているオブジェクトと、前記第２制限手段による制限の対象となっているオブジェクトとを、ユーザにそれぞれ識別可能な表示形式で表示させるためのデータであってもよい。

また、前記制限の対象とするオブジェクトは、前記ユーザが所持しているオブジェクトである所持オブジェクトの中から指定されたオブジェクトであり、
前記所定の処理は、前記指定されたオブジェクトを前記所持オブジェクトから消失させることを条件として実行される処理であってもよい。

「前記指定されたオブジェクトを前記所持オブジェクトから消失させることを条件として実行される処理」とは、当該処理を実行した場合、指定されたオブジェクトが所持オブジェクトから消失する（つまり、指定されたオブジェクトが未所持オブジェクトになる）、処理である。

また、前記第１受付手段によって受け付けられた要求または前記第２受付手段によって受け付けられた要求の少なくともいずれか一方は、前記制限の対象とするオブジェクトに対して、前記所持オブジェクトから消失させることを条件として実行される処理に用いられることを制限させるための第１要求と、前記所持オブジェクトから消失させることを条件として実行される処理のうち前記選択オブジェクトを変化させる処理以外の処理に用いられることを制限させるための第２要求とを含んでもよい。

「選択オブジェクトを変化させる処理」および「選択オブジェクトを変化させる処理以外の処理」は、いずれも、「所持オブジェクトから消失させることを条件として実行される処理」の一態様である。
「第１要求」とは、第１指定オブジェクトを所持オブジェクトから消失させることを条件として実行される処理の全てに対する制限の要求である。
「第２要求」とは、第１指定オブジェクトを所持オブジェクトから消失させることを条件として実行される処理のうち、選択オブジェクトを変化させる処理以外の処理の全てに対する制限（換言すると、選択オブジェクトを変化させる処理のみを許可すること）の要求である。

また、前記第２出力データは、前記第１要求の対象となっているオブジェクトと、前記第２要求の対象となっているオブジェクトとを、ユーザにそれぞれ識別可能な表示形式で表示させるためのデータであってもよい。

「前記第１要求の対象となっているオブジェクト」とは、所持オブジェクトから消失させることを条件として実行される処理の全てに対する利用が制限されているオブジェクト（つまり、所持オブジェクトから消失し得ない状態に置かれたオブジェクト）である。
「前記第２要求の対象となっているオブジェクト」とは、選択オブジェクトを変化させる処理以外の処理に対する利用が制限されている（つまり、選択オブジェクトを変化させる処理への利用のみが許可されている）オブジェクトである。

本発明の別の態様は、
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理システムであって、
前記ユーザ端末、および、前記サーバのいずれかが、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第１出力データを出力する第１出力手段と、
前記第１出力手段により前記第１出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第１指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第１受付手段と、
前記第１受付手段により前記要求が受け付けられたことに応じて、前記第１指定オブジェクトに対して、前記処理に用いられることを制限する第１制限手段と、
を備える、情報処理システムである。

本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータを、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第１出力データを出力する手段、
前記第１出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第１指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける手段、
前記要求が受け付けられたことに応じて、前記第１指定オブジェクトに対して、前記処理に用いられることを制限する手段、
として機能させる、プログラムである。

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係る情報処理装置等が図示の態様に限定されるものではない。

１…ゲームシステム
１０…ユーザ端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１５…操作入力部
１６…表示部
１７…通信インタフェース部
１８…ストレージ
１９…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…通信インタフェース部
２５…ストレージ
２６…バス
５１…受付手段
５２…ゲーム処理手段
５４…カードデータ変更手段
５５…取得手段
５６…出力手段
５７…記録手段
５８…制限手段
７０…データテーブル群

Claims (9)

1. ベースオブジェクト及び参照オブジェクトを用いてオブジェクト合成を行う情報処理装置であって、
   予め関連付けられた１以上の参照オブジェクトがベースオブジェクトに対応付けて設定されたオブジェクト情報を記憶するオブジェクト情報記憶部と、
   ユーザの所持するオブジェクトを含むユーザ情報を記憶するユーザ情報記憶部と、
   参照オブジェクトを含む複数のオブジェクトのうちのいずれかをユーザに付与し所持させる付与部と、
   付与された参照オブジェクトの入手時に、付与された前記参照オブジェクトが対応付けられたベースオブジェクト及び当該ベースオブジェクトに対応付けられた１以上の参照オブジェクトを抽出し、抽出された前記ベースオブジェクト及び前記１以上の参照オブジェクトの関連性に関する通知を前記ユーザに対して行なう通知部と、
   を備えたことを特徴とする情報処理装置。
2. 請求項１に記載された情報処理装置であって、
   前記通知部は、前記ベースオブジェクト及び前記参照オブジェクトの関連性に関する通知を行なう際に、抽出された前記１以上の参照オブジェクトそれぞれに対する前記ユーザの所持状態を通知する、
   ことを特徴とする情報処理装置。
3. 請求項２に記載された情報処理装置であって、
   ユーザの所持するオブジェクトのうち、ベースオブジェクト及び当該ベースオブジェクトに対応付けられた１以上の参照オブジェクトを合成させる合成処理を制御する合成処理部を備え、
   前記通知部は、前記ベースオブジェクトに対応付けられた前記１以上の参照オブジェクトすべてを前記ユーザが所持していることを条件として、前記合成処理へ誘導する通知を行なう、
   ことを特徴とする情報処理装置。
4. 請求項１−３のいずれか１項に記載された情報処理装置であって、
   前記オブジェクト情報記憶部には、オブジェクトと当該オブジェクトが入手可能なイベントの種別に関する情報が関連付けられて記憶されており、
   前記通知部は、前記ベースオブジェクト及び前記参照オブジェクトの関連性に関する通知を行なう際に、当該参照オブジェクトを入手できるイベントの種別に関する通知を行なう、
   ことを特徴とする情報処理装置。
5. 請求項４に記載された情報処理装置であって、
   前記ユーザ情報記憶部には、前記イベントの実行に必要なパラメータがユーザに関連付けられて記憶されており、
   前記通知部は、前記参照オブジェクトを入手できるイベントの種別に関する通知を行なう際に、当該イベントを実行する処理へ誘導する通知を行なう、
   ことを特徴とする情報処理装置。
6. 請求項１−５のいずれか１項に記載された情報処理装置であって、
   前記通知部は、前記ベースオブジェクト及び前記参照オブジェクトの関連性に関する通知を行なう際に、所定条件を満たすオブジェクトを、当該所定条件を満たさないオブジェクトとは異なる通知態様にて通知する、
   ことを特徴とする情報処理装置。
7. ２以上のオブジェクトを用いてオブジェクト合成を行う情報処理装置であって、
   複数のオブジェクトのうちの２以上のオブジェクトが対応付けて設定されたオブジェクト情報を記憶するオブジェクト情報記憶部と、
   ユーザの所持するオブジェクトを含むユーザ情報を記憶するユーザ情報記憶部と、
   前記複数のオブジェクトのうちのいずれかをユーザに付与し所持させる付与部と、
   付与されたオブジェクトの入手時に、付与された前記オブジェクトに対応付けられた１以上のオブジェクトを抽出し、付与された前記オブジェクト及び抽出された前記１以上のオブジェクトの関連性に関する通知を前記ユーザに対して行なう通知部と、
   を備えたことを特徴とする情報処理装置。
8. ベースオブジェクト及び参照オブジェクトを用いてオブジェクト合成を行うプログラムであって、
   コンピュータを、
   予め関連付けられた１以上の参照オブジェクトがベースオブジェクトに対応付けて設定されたオブジェクト情報を記憶するオブジェクト情報記憶手段、
   ユーザの所持するオブジェクトを含むユーザ情報を記憶するユーザ情報記憶手段、
   参照オブジェクトを含む複数のオブジェクトのうちのいずれかをユーザに付与し所持させる付与手段、
   付与された参照オブジェクトの入手時に、付与された前記参照オブジェクトが対応付けられたベースオブジェクト及び当該ベースオブジェクトに対応付けられた１以上の参照オブジェクトを抽出し、抽出された前記ベースオブジェクト及び前記１以上の参照オブジェクトの関連性に関する通知を前記ユーザに対して行なう通知手段、
   として機能させるためのプログラム。
9. ２以上のオブジェクトを用いてオブジェクト合成を行うプログラムであって、
   コンピュータを、
   複数のオブジェクトのうちの２以上のオブジェクトが対応付けて設定されたオブジェクト情報を記憶するオブジェクト情報記憶手段、
   ユーザの所持するオブジェクトを含むユーザ情報を記憶するユーザ情報記憶手段、
   前記複数のオブジェクトのうちのいずれかをユーザに付与し所持させる付与手段、
   付与されたオブジェクトの入手時に、付与された前記オブジェクトに対応付けられた１以上のオブジェクトを抽出し、付与された前記オブジェクト及び抽出された前記１以上のオブジェクトの関連性に関する通知を前記ユーザに対して行なう通知手段、
   として機能させるためのプログラム。