JP6278389B2 - 情報処理装置、情報処理システム、プログラム - Google Patents
情報処理装置、情報処理システム、プログラム Download PDFInfo
- Publication number
- JP6278389B2 JP6278389B2 JP2013257685A JP2013257685A JP6278389B2 JP 6278389 B2 JP6278389 B2 JP 6278389B2 JP 2013257685 A JP2013257685 A JP 2013257685A JP 2013257685 A JP2013257685 A JP 2013257685A JP 6278389 B2 JP6278389 B2 JP 6278389B2
- Authority
- JP
- Japan
- Prior art keywords
- card
- user
- reservation
- identification information
- object identification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000010365 information processing Effects 0.000 title claims description 47
- 238000000034 method Methods 0.000 claims description 209
- 230000008569 process Effects 0.000 claims description 165
- 238000012545 processing Methods 0.000 claims description 131
- 230000008859 change Effects 0.000 claims description 78
- 230000004044 response Effects 0.000 claims description 12
- 230000015572 biosynthetic process Effects 0.000 description 179
- 238000003786 synthesis reaction Methods 0.000 description 179
- 230000006870 function Effects 0.000 description 32
- 238000004891 communication Methods 0.000 description 17
- 230000004048 modification Effects 0.000 description 17
- 238000012986 modification Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 6
- 230000007123 defense Effects 0.000 description 5
- PEDCQBHIVMGVHV-UHFFFAOYSA-N Glycerine Chemical compound OCC(O)CO PEDCQBHIVMGVHV-UHFFFAOYSA-N 0.000 description 4
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 3
- 230000001174 ascending effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 239000007788 liquid Substances 0.000 description 2
- 239000010409 thin film Substances 0.000 description 2
- 101100110018 Arabidopsis thaliana ASK3 gene Proteins 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 210000005155 neural progenitor cell Anatomy 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Description
本発明は、オブジェクトについての情報を処理する情報処理技術に関する。
近年、ソーシャルネットワーキングサービス（ＳＮＳ）において実行されるアプリケーションとして、いわゆるソーシャルゲーム（Social Game）が普及している。このようなソーシャルゲームとして、カードを利用したデジタルカードゲームが知られている。
また、ユーザの所有カードの中からメインカードとサブカードがユーザに選択され、メインカードとサブカードを合成処理することによって、メインカードの能力パラメータを変更するとともに、サブカードをユーザの所有カードから削除するようにしたゲームが知られている（特許文献１、２）。
また、ユーザの所有カードの中からメインカードとサブカードがユーザに選択され、メインカードとサブカードを合成処理することによって、メインカードの能力パラメータを変更するとともに、サブカードをユーザの所有カードから削除するようにしたゲームが知られている（特許文献１、２）。
合成処理では、ベースとなるオブジェクト（ベースオブジェクト；上記メインカードに相当）の合成処理を実現するために、ベースオブジェクトに対応した組合せ条件を満たす複数のオブジェクト（参照オブジェクト；上記サブカードに相当）をユーザが所持していることが要件となる場合がある。その場合、ユーザは合成処理を実行するために、組合せ条件を満たすすべての参照オブジェクトを入手できるまで合成処理の実行を待機しなければならないが、その待機中に誤って、複数の参照オブジェクトのうち既に所持しているオブジェクトを消失させてしまう虞がある。特に、ベースオブジェクトごとに合成処理の組合せ条件を満たす複数の参照オブジェクトが異なる場合には、ベースオブジェクトごとの組合せ条件をユーザが覚えておくのが大変であるため、オブジェクトを誤って消失させてしまう可能性が高くなる。
本発明は上述した観点に鑑みてなされたものであり、その目的は、ユーザが所持しているオブジェクトを、そのオブジェクトの使用目的以外の処理に使用して消失してしまう可能性を低下させることができる情報処理装置、情報処理システム、プログラムを提供することである。
本発明の一態様は、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段と、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段と、
を備えた情報処理装置である。
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段と、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段と、
を備えた情報処理装置である。
本発明の別の態様は、ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、前記ユーザ端末または前記サーバの少なくともいずれかが、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能に構成された情報処理システムであって、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段、
を前記ユーザ端末または前記サーバの少なくともいずれかが備えた、情報処理システムである。
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段、
を前記ユーザ端末または前記サーバの少なくともいずれかが備えた、情報処理システムである。
本発明の別の態様は、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータに、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段、
として機能させるためのプログラムである。
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段、
として機能させるためのプログラムである。
（１）第１の実施形態
（１−１）ゲームシステムの構成
以下、情報処理システムの一実施形態として、ゲームシステム１について説明する。
（１−１）ゲームシステムの構成
以下、情報処理システムの一実施形態として、ゲームシステム１について説明する。
図１は、実施形態のゲームシステム１のシステム構成例を示している。図１に示すように、このゲームシステム１は、ユーザ端末１０ａ，１０ｂ，１０ｃ，…、およびゲームサーバ２０を含む。各ユーザ端末１０ａ，１０ｂ，１０ｃからゲームサーバ２０に対しては、例えばインターネットなどの通信網ＮＷを通してアクセス可能である。ゲームサーバ２０は、情報処理装置の一例である。
各ユーザ端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、フィーチャーフォン、スマートフォン、タブレット端末、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）、通信機能付き携帯ゲーム機などの通信端末である。以下の説明において、各ユーザ端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、ユーザ端末１０と表記する。
各ユーザ端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、フィーチャーフォン、スマートフォン、タブレット端末、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）、通信機能付き携帯ゲーム機などの通信端末である。以下の説明において、各ユーザ端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、ユーザ端末１０と表記する。
ゲームサーバ２０は、ゲームを実行するサーバである。ゲームサーバ２０には、ウェブブラウザによって解釈可能な画像データ（例えばＨＴＭＬ、ＸＭＬなどの形式で記述された画像データのことである。本発明の実施形態では、ＨＴＭＬデータを例として説明する。）を作成可能なプログラムが実装されている。なお、画像データは、出力データの一例である。
ユーザ端末１０は、ゲームサーバ２０によって提供されるＨＴＭＬデータを解釈して表示するウェブブラウザを備えており、ユーザ端末１０によるウェブページ上のユーザの操作に基づく要求を、ネットワークを介してゲームサーバ２０へ送信し、ゲームサーバ２０による処理結果を受信することでゲームの処理を実行する。
通信網ＮＷは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、専用回線、又はこれらの組み合わせによって構成される情報通信ネットワークである。
ユーザ端末１０は、ゲームサーバ２０によって提供されるＨＴＭＬデータを解釈して表示するウェブブラウザを備えており、ユーザ端末１０によるウェブページ上のユーザの操作に基づく要求を、ネットワークを介してゲームサーバ２０へ送信し、ゲームサーバ２０による処理結果を受信することでゲームの処理を実行する。
通信網ＮＷは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、専用回線、又はこれらの組み合わせによって構成される情報通信ネットワークである。
（１−２）ユーザ端末の構成
図２を参照してユーザ端末１０について説明する。
図２に示すように、ユーザ端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、操作入力部１５、表示部１６、通信インタフェース部１７、および、ストレージ１８を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１９が設けられている。
図２を参照してユーザ端末１０について説明する。
図２に示すように、ユーザ端末１０は、ＣＰＵ（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)と対戦する。
なお、以下の説明において、カードの「所持」とは、ユーザが当該カードを、当該カードを用いた処理に利用可能な状態にあることをいう。カードの「未所持」とは、ユーザが当該カードを、当該カードを用いた処理に利用不可能な状態にあることをいう。カードの「入手」とは、当該カードに対して未所持の状態から所持の状態に移行したことをいう。
本実施形態のゲームにおいて、カードの進化合成処理（以下、適宜単に「進化合成」という。）とは、所定の条件を満足する場合に、ユーザが所持するカードを進化させる処理である。カードの進化合成は、本実施形態の例では後述するようにカードＩＤを変更する処理であるが、カードに対応するカードデータ（後述する）の少なくとも一部を変更する処理であってもよい。その場合、カードデータの変更対象は特に問わないが、例えば、カード名やカード画像、レアリティ等のカードパラメータである。カードの進化合成は、オブジェクトを変化させる処理の一例である。
進化合成を実行するには、ユーザは自身が所持するカード（以下、適宜「所持カード」という。）の中から、進化させたいカードとしてベースカードを選択する。ベースカードとして選択されたカードは、選択オブジェクトの一例である。
進化合成では、ベースカードのカードＩＤごとに、そのベースカードを進化させるのに必要な複数のカード（「参照カード」という。）のカードＩＤの組合せ条件（変化条件の一例）が決められている。進化合成が実行されると、その進化合成に使用された参照カードはユーザの所持カードから消失する。
本実施形態において、所持カードは、所持オブジェクトの一例である。
本実施形態のゲームでは、ユーザによってベースカードとして選択されたカードに対応する組合せ条件となる複数の参照カードをユーザが所持していることが、選択されたカードを進化させるための条件である。
本実施形態のゲームシステム１において実行されるゲームは、ユーザがオブジェクトとしてのカードを利用するゲームである。このゲームでは、例えば、ユーザがゲーム上のエリアを探索してカードやアイテムを取得し、あるいはユーザが所持するカードを用いて他のユーザやＮＰＣ(Non-Player Character)と対戦する。
なお、以下の説明において、カードの「所持」とは、ユーザが当該カードを、当該カードを用いた処理に利用可能な状態にあることをいう。カードの「未所持」とは、ユーザが当該カードを、当該カードを用いた処理に利用不可能な状態にあることをいう。カードの「入手」とは、当該カードに対して未所持の状態から所持の状態に移行したことをいう。
本実施形態のゲームにおいて、カードの進化合成処理（以下、適宜単に「進化合成」という。）とは、所定の条件を満足する場合に、ユーザが所持するカードを進化させる処理である。カードの進化合成は、本実施形態の例では後述するようにカードＩＤを変更する処理であるが、カードに対応するカードデータ（後述する）の少なくとも一部を変更する処理であってもよい。その場合、カードデータの変更対象は特に問わないが、例えば、カード名やカード画像、レアリティ等のカードパラメータである。カードの進化合成は、オブジェクトを変化させる処理の一例である。
進化合成を実行するには、ユーザは自身が所持するカード（以下、適宜「所持カード」という。）の中から、進化させたいカードとしてベースカードを選択する。ベースカードとして選択されたカードは、選択オブジェクトの一例である。
進化合成では、ベースカードのカードＩＤごとに、そのベースカードを進化させるのに必要な複数のカード（「参照カード」という。）のカードＩＤの組合せ条件（変化条件の一例）が決められている。進化合成が実行されると、その進化合成に使用された参照カードはユーザの所持カードから消失する。
本実施形態において、所持カードは、所持オブジェクトの一例である。
本実施形態のゲームでは、ユーザによってベースカードとして選択されたカードに対応する組合せ条件となる複数の参照カードをユーザが所持していることが、選択されたカードを進化させるための条件である。
なお、本実施形態のゲームでは、ユーザが自身の所持カードを失う処理の一例として、例えば、通常合成処理と売却処理がある。通常合成処理を実行するには、ユーザは自身の所持カードの中から、成長させたいカードとしてベースカードを選択する。通常合成処理では、ベースカードごとに参照カードの組合せ条件が決められていなくてもよく、ユーザは適宜参照カードを所持カードの中から選択することができる。通常合成処理が実行されると、ベースカードのカードパラメータが変化する（例えば、カードレベルやスキルレベルが増加する）代わりに、参照カードはユーザの所持カードから消失する。
売却処理では、ユーザの所持カードの中から選択されたカード（例えば、ユーザが不要とするカード）を、そのカードに対応する売却価格（例えば、ゲーム上のポイント）をユーザが得る代わりに、売却したカードがユーザの所持カードから消失する。
売却処理では、ユーザの所持カードの中から選択されたカード（例えば、ユーザが不要とするカード）を、そのカードに対応する売却価格（例えば、ゲーム上のポイント）をユーザが得る代わりに、売却したカードがユーザの所持カードから消失する。
本実施形態のゲームにおいて、ユーザが所望のカードを進化合成によって進化させたいが当該カードを進化させるのに必要な参照カードの一部、あるいはすべてをユーザが所持していない場合を考える。この場合、参照カードの組合せ条件を満たすための新しいカード（つまり、残りの参照カード）をユーザが入手できるまで所望のカードの進化合成を実行することを待機する必要がある。しかし、ユーザが、ベースカードや、ベースカードを進化させるために所持している参照カードの一部を誤って消失してしまう場合（例えば、上述した売却処理や通常合成等）がある。特に、進化合成のための組合せ条件を成立させるのに必要となる参照カードが多い場合や、ベースカードごとに組合せ条件が異なる場合は、ユーザは進化合成のための組合せ条件を覚えておくのが大変であり、ベースカードや参照カードを誤って消失させてしまう可能性が高くなる。
そこで、本実施形態では、進化合成させたいベースカード、および、当該ベースカードを進化させるのに必要となる複数の参照カードを、ユーザが当該ベースカードの進化合成のために予約できるようにする。進化合成のために予約されたカードを、以下の説明では「予約済カード」という。予約済カードに対しては、予約の対象となる進化合成以外の処理（例えば、上述した通常合成や売却処理）の実行が制限される。
そこで、本実施形態では、進化合成させたいベースカード、および、当該ベースカードを進化させるのに必要となる複数の参照カードを、ユーザが当該ベースカードの進化合成のために予約できるようにする。進化合成のために予約されたカードを、以下の説明では「予約済カード」という。予約済カードに対しては、予約の対象となる進化合成以外の処理（例えば、上述した通常合成や売却処理）の実行が制限される。
進化合成におけるカードの予約について、図４を参照して具体的に説明する。図４は、進化合成におけるカードの予約を概念的に説明するための図である。
図４において、ユーザがカードＱ，Ａ，Ｒ，Ｄを所持し、カードＱおよびＲをそれぞれ進化させたいと考える場合を想定する。この例では、ここでは、ベースカードＱを進化させるための条件（変化条件）が、ベースカードＱに対応する組合せ条件である複数の参照カードＡ，Ｂ，Ｃをユーザがすべて所持している場合、および、ベースカードＲを進化させるための変化条件が、ベースカードＲに対応する組合せ条件である複数の参照カードＣ，Ｄ，Ｅをユーザがすべて所持している場合である。ユーザは現時点で参照カードＢ，Ｃ，Ｅを所持していないため、カードＱまたはカードＲに対して進化合成を実行することはできない。
このとき、ユーザは、要求に応じて、ベースカードＱの進化合成のために、ベースカードＱ、および、参照カードＡ〜Ｃを予約することができる。また、ユーザは、要求に応じて、ベースカードＲの進化合成のために、ベースカードＲ、および、参照カードＣ〜Ｅを予約することができる。予約を行うことで、予約済カードＡ〜Ｃのうちユーザの所持カードについては、カードＱの進化合成以外の処理（例えば、上述した通常合成や売却）に用いられることが制限される。同様に、予約済カードＣ〜Ｅのうちユーザの所持カードについては、カードＲの進化合成以外の処理に用いられることが制限される。
図４において、ユーザがカードＱ，Ａ，Ｒ，Ｄを所持し、カードＱおよびＲをそれぞれ進化させたいと考える場合を想定する。この例では、ここでは、ベースカードＱを進化させるための条件（変化条件）が、ベースカードＱに対応する組合せ条件である複数の参照カードＡ，Ｂ，Ｃをユーザがすべて所持している場合、および、ベースカードＲを進化させるための変化条件が、ベースカードＲに対応する組合せ条件である複数の参照カードＣ，Ｄ，Ｅをユーザがすべて所持している場合である。ユーザは現時点で参照カードＢ，Ｃ，Ｅを所持していないため、カードＱまたはカードＲに対して進化合成を実行することはできない。
このとき、ユーザは、要求に応じて、ベースカードＱの進化合成のために、ベースカードＱ、および、参照カードＡ〜Ｃを予約することができる。また、ユーザは、要求に応じて、ベースカードＲの進化合成のために、ベースカードＲ、および、参照カードＣ〜Ｅを予約することができる。予約を行うことで、予約済カードＡ〜Ｃのうちユーザの所持カードについては、カードＱの進化合成以外の処理（例えば、上述した通常合成や売却）に用いられることが制限される。同様に、予約済カードＣ〜Ｅのうちユーザの所持カードについては、カードＲの進化合成以外の処理に用いられることが制限される。
なお、予約済カードについて「進化合成以外の処理に用いられることが制限される」とは、予約済カードを用いた、目的とする進化合成以外の処理自体が禁止されることに限られず、予約済カードを用いた、目的とする進化合成以外の処理は実行可能であるが、その処理の実行の手続きをし難くする、あるいは処理の実行手続きを煩雑にすることであってもよい。予約済カードについての「進化合成以外の処理」が、予約済カードをユーザの所持カードから消失させる処理（つまり、予約済カードを未所持とする処理）である場合に、当該処理が制限されることが特に好ましい。
図４に示すように、ベースカードＱ，Ｒに対応する参照カードのうちカードＣについては、ベースカードＱ，Ｒに対して重複した参照カードである。このとき、入手したカードＣについてベースカードＱ，Ｒのいずれの予約済カードとして対応付けるかについて、ユーザの意思とは異なったベースカードに対応付けられると、入手したカードＣについてそのベースカードの進化合成以外の処理が制限されてしまい、結局ユーザが進化合成させたいベースカードの進化合成を早く実行することができなくなる。そこで、本実施形態では、異なるベースカードに対応付けられている予約済カードが重複する場合には、ユーザにその旨を報知し、ユーザの注意を促すようにする。
また、本実施形態では、好ましくは、異なるベースカードに対して重複して対応付けられている予約済カードＣをユーザが入手した場合に、入手したカードＣを対応付けるベースカード（ＱまたはＲ）、あるいは予約の対応付けを示す情報（進化予約１または２）について、ユーザによる操作に基づいて決定される。換言すれば、入手したカードＣを、ベースカードＱ，Ｒのいずれのカードの進化合成以外の処理に用いられることを制限するかについて、ユーザによる操作に基づいて決定される。そのため、複数の進化予約で重複した参照カード（以下、適宜「重複カード」という。）であるカードＣが存在する場合であっても、進化合成を優先的に処理するベースカード（つまり、進化合成のために保護するベースカード）をユーザが自ら指定することができる。
また、本実施形態では、好ましくは、異なるベースカードに対して重複して対応付けられている予約済カードＣをユーザが入手した場合に、入手したカードＣを対応付けるベースカード（ＱまたはＲ）、あるいは予約の対応付けを示す情報（進化予約１または２）について、ユーザによる操作に基づいて決定される。換言すれば、入手したカードＣを、ベースカードＱ，Ｒのいずれのカードの進化合成以外の処理に用いられることを制限するかについて、ユーザによる操作に基づいて決定される。そのため、複数の進化予約で重複した参照カード（以下、適宜「重複カード」という。）であるカードＣが存在する場合であっても、進化合成を優先的に処理するベースカード（つまり、進化合成のために保護するベースカード）をユーザが自ら指定することができる。
（１−５）データテーブルの構成
次に、ゲームサーバ２０のストレージ２５に格納されるカードデータテーブル、進化合成データテーブル、所持カードデータテーブル、および、予約データテーブルについて、図５〜８を参照して順に説明する。ゲームサーバ２０のストレージ２５は、記憶装置の一例である。
次に、ゲームサーバ２０のストレージ２５に格納されるカードデータテーブル、進化合成データテーブル、所持カードデータテーブル、および、予約データテーブルについて、図５〜８を参照して順に説明する。ゲームサーバ２０のストレージ２５は、記憶装置の一例である。
（i）カードデータテーブル
カードデータテーブルには、本実施形態のゲームで使用されるカードのデータが記録されている。図５にカードデータテーブルの構成例を示す。図５に示す例では、カードＩＤごとにカード名、カード画像、および、カードパラメータのデータが含まれる。カードＩＤは、オブジェクト識別情報の一例である。
カード名は、カードに表示されるキャラクタの名称を示す文字列である。カード画像は、カードに表示されるキャラクタの画像である。カードパラメータは、レアリティ、属性、コスト、スキル、売却価格、攻撃力、防御力、および、限定フラグの各データから構成されている。
レアリティは、カードの希少価値を示す指標であり、図５に示す例ではＲ１〜Ｒ５の順にレアリティが高く設定されている。
属性は、カードに表示されるキャラクタの属性であり、図５に示す例ではＮ１〜Ｎ３のいずれかである。
コストは、カードをユーザのカードチームに組み込むときに参照される値である。例えばカードチームによる対戦を行う場合には、カードチームに含まれるカードのコストの総和が所定値以下に制限される。
スキルは、カードを用いてゲームを実行するときに有利となる効果を示す情報であり、図４に示す例では、ＳＫ１〜ＳＫ１２の様々な効果を備えたスキルが各カードに設定されている。なお、すべてのカードがスキルを備えていなくてもよい。
売却価格は、ユーザが自身で所持しているカードを売却するときにユーザが得られるゲーム上のポイントである。
攻撃力および防御力は、カードを対戦で用いるときに参照されるパラメータである。
限定フラグは、期間限定で発行されたカードであるか否かを示すフラグである。図４に示す例では、限定フラグが「１」であるカードは期間限定で発行されたカードであることを意味し、限定フラグが「０」であるカードは期間限定でないカードであることを意味する。
カードデータテーブルには、本実施形態のゲームで使用されるカードのデータが記録されている。図５にカードデータテーブルの構成例を示す。図５に示す例では、カードＩＤごとにカード名、カード画像、および、カードパラメータのデータが含まれる。カードＩＤは、オブジェクト識別情報の一例である。
カード名は、カードに表示されるキャラクタの名称を示す文字列である。カード画像は、カードに表示されるキャラクタの画像である。カードパラメータは、レアリティ、属性、コスト、スキル、売却価格、攻撃力、防御力、および、限定フラグの各データから構成されている。
レアリティは、カードの希少価値を示す指標であり、図５に示す例ではＲ１〜Ｒ５の順にレアリティが高く設定されている。
属性は、カードに表示されるキャラクタの属性であり、図５に示す例ではＮ１〜Ｎ３のいずれかである。
コストは、カードをユーザのカードチームに組み込むときに参照される値である。例えばカードチームによる対戦を行う場合には、カードチームに含まれるカードのコストの総和が所定値以下に制限される。
スキルは、カードを用いてゲームを実行するときに有利となる効果を示す情報であり、図４に示す例では、ＳＫ１〜ＳＫ１２の様々な効果を備えたスキルが各カードに設定されている。なお、すべてのカードがスキルを備えていなくてもよい。
売却価格は、ユーザが自身で所持しているカードを売却するときにユーザが得られるゲーム上のポイントである。
攻撃力および防御力は、カードを対戦で用いるときに参照されるパラメータである。
限定フラグは、期間限定で発行されたカードであるか否かを示すフラグである。図４に示す例では、限定フラグが「１」であるカードは期間限定で発行されたカードであることを意味し、限定フラグが「０」であるカードは期間限定でないカードであることを意味する。
（ii）進化合成データテーブル
進化合成データテーブルには、本実施形態のゲームのカードの進化合成の条件が記録されている。図６に進化合成データテーブルの構成例を示す。図６に示す例では、進化合成の内容を識別するための進化ＩＤごとに、進化前カードＩＤ（つまり、進化前のベースカードとなるカードのカードＩＤ）、進化後カードＩＤ（ベースカードの進化後のカードＩＤ）、および進化合成を実行するために必要となる参照カードのカードＩＤの組合せ条件（Ｃ１〜Ｃ５の欄の５枚の参照カード）が記録されている。例えば、進化ＩＤ：０００２が示す条件では、ユーザが所持カードの中からカードＩＤ：００７２のカードをベースカードとして選択し、ユーザの所持カードの中にカードＩＤ：００２５，００６０，００７０の３枚のカードの組合せが存在する場合には、進化合成を実行することによって、カードＩＤ：００７２のカードをカードＩＤ：９０７２のカードに進化させることができる。すなわち、進化合成データテーブルにおける参照カードＩＤの組合せ条件は、進化前カードＩＤに対応するカードを変化させる変化条件の一例である。
なお、参照カードのカードＩＤの組合せ条件を示すＣ１〜Ｃ５の欄には、少なくともいずれか２つの欄に同一のカードＩＤが記録されていることもある。例えば、ベースカードを進化合成するときに使用する参照カードの組合せ条件に同一の参照カードが２枚以上含まれていてもよい。ベースカードを進化させるための参照カードの組合せ条件が、同一のカードＩＤである参照カードが所定数含まれることである場合には、図６に示したようなデータ形式ではなく、参照カードのカードＩＤとその枚数とからなるデータ形式であってもよい。
進化合成データテーブルには、本実施形態のゲームのカードの進化合成の条件が記録されている。図６に進化合成データテーブルの構成例を示す。図６に示す例では、進化合成の内容を識別するための進化ＩＤごとに、進化前カードＩＤ（つまり、進化前のベースカードとなるカードのカードＩＤ）、進化後カードＩＤ（ベースカードの進化後のカードＩＤ）、および進化合成を実行するために必要となる参照カードのカードＩＤの組合せ条件（Ｃ１〜Ｃ５の欄の５枚の参照カード）が記録されている。例えば、進化ＩＤ：０００２が示す条件では、ユーザが所持カードの中からカードＩＤ：００７２のカードをベースカードとして選択し、ユーザの所持カードの中にカードＩＤ：００２５，００６０，００７０の３枚のカードの組合せが存在する場合には、進化合成を実行することによって、カードＩＤ：００７２のカードをカードＩＤ：９０７２のカードに進化させることができる。すなわち、進化合成データテーブルにおける参照カードＩＤの組合せ条件は、進化前カードＩＤに対応するカードを変化させる変化条件の一例である。
なお、参照カードのカードＩＤの組合せ条件を示すＣ１〜Ｃ５の欄には、少なくともいずれか２つの欄に同一のカードＩＤが記録されていることもある。例えば、ベースカードを進化合成するときに使用する参照カードの組合せ条件に同一の参照カードが２枚以上含まれていてもよい。ベースカードを進化させるための参照カードの組合せ条件が、同一のカードＩＤである参照カードが所定数含まれることである場合には、図６に示したようなデータ形式ではなく、参照カードのカードＩＤとその枚数とからなるデータ形式であってもよい。
（iii）所持カードデータテーブル
所持カードデータテーブルは、ユーザの所持カードの情報（所持情報）が記録されている。図７に所持カードデータテーブルの構成例を示す。図７では１ユーザ分の所持カードデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているユーザ毎に設けられる。
図７に示す所持カードデータテーブルには、カードＩＤごとに、シリアル番号、カードレベル、スキルレベル、および、予約ＩＤの各データが対応付けられて記録されている。シリアル番号は、ユーザにカードが付与された時点で決定される固有の番号である。同一のカードＩＤのカードに対しても異なるシリアル番号が付される。なお、カードが進化した場合には、そのカードの進化前後でシリアル番号を変化させてもよいし、変化させなくてもよい。
カードレベルはカードの育成レベルを示すパラメータであり、例えば上記通常合成を実行することによって増加する。ユーザがカードを取得した時点でのカードレベルの値（初期値）は１であり、ユーザは通常合成を実行することでそのカードを成長（つまり、カードレベルを増加）させることができる。
スキルレベルはカードの育成レベルを示すパラメータであり、特にカードが備えるスキルのレベルを示すパラメータである。ユーザがスキルを備えたカードを取得した時点でのスキルレベルの値（初期値）は１であり、例えば所定の条件を満たすカードを参照カードとした通常合成を行うことによってカードのスキルレベルを増加させることができる。カードのスキルレベルが増加するにつれて、スキルによって発生する効果が増大する。
予約ＩＤは、進化合成のための予約内容を識別するための識別情報である。予約済カードとなっているユーザの所持カードには、予約ＩＤが対応付けられている。例えば、図７に示す例では、カードＩＤ：０５９１，００１０（２枚）、００３３、２００５の５枚のカードが予約済カードであることを示している。所持カードデータテーブルに記録されている予約ＩＤは、後述する予約データテーブルに記録されている予約ＩＤに対応している。
所持カードデータテーブルは、ユーザの所持カードの情報（所持情報）が記録されている。図７に所持カードデータテーブルの構成例を示す。図７では１ユーザ分の所持カードデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているユーザ毎に設けられる。
図７に示す所持カードデータテーブルには、カードＩＤごとに、シリアル番号、カードレベル、スキルレベル、および、予約ＩＤの各データが対応付けられて記録されている。シリアル番号は、ユーザにカードが付与された時点で決定される固有の番号である。同一のカードＩＤのカードに対しても異なるシリアル番号が付される。なお、カードが進化した場合には、そのカードの進化前後でシリアル番号を変化させてもよいし、変化させなくてもよい。
カードレベルはカードの育成レベルを示すパラメータであり、例えば上記通常合成を実行することによって増加する。ユーザがカードを取得した時点でのカードレベルの値（初期値）は１であり、ユーザは通常合成を実行することでそのカードを成長（つまり、カードレベルを増加）させることができる。
スキルレベルはカードの育成レベルを示すパラメータであり、特にカードが備えるスキルのレベルを示すパラメータである。ユーザがスキルを備えたカードを取得した時点でのスキルレベルの値（初期値）は１であり、例えば所定の条件を満たすカードを参照カードとした通常合成を行うことによってカードのスキルレベルを増加させることができる。カードのスキルレベルが増加するにつれて、スキルによって発生する効果が増大する。
予約ＩＤは、進化合成のための予約内容を識別するための識別情報である。予約済カードとなっているユーザの所持カードには、予約ＩＤが対応付けられている。例えば、図７に示す例では、カードＩＤ：０５９１，００１０（２枚）、００３３、２００５の５枚のカードが予約済カードであることを示している。所持カードデータテーブルに記録されている予約ＩＤは、後述する予約データテーブルに記録されている予約ＩＤに対応している。
（iv）予約データテーブル
予約データテーブルは、ユーザの進化合成のための予約済カードの情報が記録されている。図８に予約データテーブルの構成例を示す。図８では１ユーザ分の予約データテーブルを例示するが、予約データテーブルは、ゲームに登録しているユーザ毎に設けられる。
図８において、予約ＩＤは進化合成の予約が行われた順に発行されるＩＤである。図８に示す例では、０１，０２，…といった具合に昇順に番号が記録される。進化ＩＤは、進化合成データテーブルに示した進化ＩＤに対応しており、進化合成の内容を特定するＩＤである。予約ＩＤは、対応付け情報の一例である。
予約済カードのシリアル番号のうち、進化前カードのシリアル番号は、進化合成のベースカードとしてユーザによって選択された所持カードに対応するシリアル番号である。予約済みカードのシリアル番号のうち参照カードのＣ１〜Ｃ５の欄はそれぞれ、進化合成データテーブルの参照カードＩＤの組合せ条件を構成するＣ１〜Ｃ５の欄に対応しており、各欄に対応する参照カードが所持カードである場合には、その参照カードのシリアル番号が記録されている。
参照カードの各欄において、未所持の参照カードに対応する欄には「未所持」を示すデータ（例えば、ＮＵＬＬ）が記録される。
ユーザが所定の操作入力を行うことによって、ベースカードを対象として予約処理が実行された場合には、そのベースカード（進化前カード）と、対応する参照カードの各々に対応する欄に、そのカードに対応するシリアル番号、または「未所持」を示すデータが書き込まれる。
なお、予約データテーブルにおいて「優先順」の欄は、本実施形態において必須ではないが、後の変形例において言及される。
予約データテーブルは、ユーザの進化合成のための予約済カードの情報が記録されている。図８に予約データテーブルの構成例を示す。図８では１ユーザ分の予約データテーブルを例示するが、予約データテーブルは、ゲームに登録しているユーザ毎に設けられる。
図８において、予約ＩＤは進化合成の予約が行われた順に発行されるＩＤである。図８に示す例では、０１，０２，…といった具合に昇順に番号が記録される。進化ＩＤは、進化合成データテーブルに示した進化ＩＤに対応しており、進化合成の内容を特定するＩＤである。予約ＩＤは、対応付け情報の一例である。
予約済カードのシリアル番号のうち、進化前カードのシリアル番号は、進化合成のベースカードとしてユーザによって選択された所持カードに対応するシリアル番号である。予約済みカードのシリアル番号のうち参照カードのＣ１〜Ｃ５の欄はそれぞれ、進化合成データテーブルの参照カードＩＤの組合せ条件を構成するＣ１〜Ｃ５の欄に対応しており、各欄に対応する参照カードが所持カードである場合には、その参照カードのシリアル番号が記録されている。
参照カードの各欄において、未所持の参照カードに対応する欄には「未所持」を示すデータ（例えば、ＮＵＬＬ）が記録される。
ユーザが所定の操作入力を行うことによって、ベースカードを対象として予約処理が実行された場合には、そのベースカード（進化前カード）と、対応する参照カードの各々に対応する欄に、そのカードに対応するシリアル番号、または「未所持」を示すデータが書き込まれる。
なお、予約データテーブルにおいて「優先順」の欄は、本実施形態において必須ではないが、後の変形例において言及される。
以下の説明では、カードＩＤに関連付けられたカード名、カード画像、シリアル番号、および、カードパラメータを総称して、適宜「カードデータ」という。カードデータを構成するカードパラメータは、カードデータテーブルに記録される各カードパラメータや、所持カードデータテーブルに記録されるカードレベル、スキルレベルが含まれる。すなわち、カード名、カード画像、シリアル番号、および、各カードパラメータの中のいずれかのデータが、カードデータに相当する。カードＩＤ、カード名、および、カード画像はそれぞれ、オブジェクト識別情報の一例である。
（１−６）カードの予約および進化合成処理の具体例
以下、本実施形態のゲームのカードの予約および進化合成処理の具体例について、図９〜１２を参照しながら説明する。図９〜１２はそれぞれ、本実施形態のゲームの処理を実行しているときのユーザ端末１０に表示される画面の一例を示す図である。
以下、本実施形態のゲームのカードの予約および進化合成処理の具体例について、図９〜１２を参照しながら説明する。図９〜１２はそれぞれ、本実施形態のゲームの処理を実行しているときのユーザ端末１０に表示される画面の一例を示す図である。
（Ａ）進化合成の予約処理（図９）
図９は、ユーザの所持カードについて進化合成のための予約をするときの一連の表示画面の変化を示している。図９において、画像Ｐ１は、本実施形態のゲームにおいてユーザがモンスターカード（以下、単に「カード」という。）について、処理要求を行うときの画像である。画像Ｐ１には、ユーザの操作対象として、ボタンｂ１（「所持モンスターを見る」）、ボタンｂ２（「チーム編成」）、ボタンｂ３（「通常合成」）、ボタンｂ４（「進化合成」）、ボタンｂ５（「売却」）が設けられる。
ボタンｂ１は、ユーザの所持カードの閲覧処理の要求を行うときに操作されるボタンである。ボタンｂ２は、ユーザが自身の所持カードの中から他のユーザやＮＰＣとの対戦において使用するカードを選択するときに操作されるボタンである。ボタンｂ３は、ユーザが所持カードの中からベースカードとして選択したカードの通常合成の実行要求を行うときに操作されるボタンである。ボタンｂ４は、ユーザが所持カードの中からベースカードとして選択したカードの進化合成の実行要求を行うときに操作されるボタンである。ボタンｂ５は、ユーザが所持カードの中から選択したカードに対して売却処理の要求を行うときに操作されるボタンである。
図９は、ユーザの所持カードについて進化合成のための予約をするときの一連の表示画面の変化を示している。図９において、画像Ｐ１は、本実施形態のゲームにおいてユーザがモンスターカード（以下、単に「カード」という。）について、処理要求を行うときの画像である。画像Ｐ１には、ユーザの操作対象として、ボタンｂ１（「所持モンスターを見る」）、ボタンｂ２（「チーム編成」）、ボタンｂ３（「通常合成」）、ボタンｂ４（「進化合成」）、ボタンｂ５（「売却」）が設けられる。
ボタンｂ１は、ユーザの所持カードの閲覧処理の要求を行うときに操作されるボタンである。ボタンｂ２は、ユーザが自身の所持カードの中から他のユーザやＮＰＣとの対戦において使用するカードを選択するときに操作されるボタンである。ボタンｂ３は、ユーザが所持カードの中からベースカードとして選択したカードの通常合成の実行要求を行うときに操作されるボタンである。ボタンｂ４は、ユーザが所持カードの中からベースカードとして選択したカードの進化合成の実行要求を行うときに操作されるボタンである。ボタンｂ５は、ユーザが所持カードの中から選択したカードに対して売却処理の要求を行うときに操作されるボタンである。
画像Ｐ１においてボタンｂ４（「進化合成」）が指定されると、Ｐ２に示すように画像が変化する。画像Ｐ２では、ユーザの所持カードの中からいずれかのカードをベースカードとして選択するために、複数の所持カードが一覧表示される。なお、好ましくは、進化することができないカード、あるいは既にベースカードとして予約済みのカード（図示する例では、カードＴＯＭ，ＴＥＤ，ＤＳＧ）についてはベースカードとして選択できないように、画像が構成されている。すなわち、画像Ｐ２では、ユーザの所持カードのうち予約済みではない進化可能なカードと、進化不可能であるか、若しくは既にベースカードとして予約済みのカードとをユーザが識別可能な表示形式で示している。ユーザが識別可能な表示形式で示す方法は、図９の画像Ｐ２に示した例に限られない。所持カードの一覧は各カードのカード名の文字列の一覧であってもよく、その場合には、カードの文字列の輝度、サイズ等によって識別できるようにしてもよい。
画像Ｐ２において、例えばカードＫＬＭが選択されると、Ｐ３に示すように画像が変化する。画像Ｐ３には、選択したカードを進化合成のベースカードとして確定させるためのボタンｂ６（「選択する」）と、画像Ｐ２に戻って別のカードをベースカードとして選択するためのボタンｂ７（「戻る」）とが含まれる。
画像Ｐ３においてユーザによってボタンｂ６が指定されると、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしていない（すべての参照カードがユーザの所持カードとして揃っていない）場合には、Ｐ４に示すように画像が更新される。
なお、画像Ｐ３においてユーザがボタンｂ６を指定した時点で、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしている場合には、画像Ｐ４に代えて、カードＫＬＭの進化合成を実行するか否かについてのユーザが指示するための画像（図示せず）が表示される。
画像Ｐ２において、例えばカードＫＬＭが選択されると、Ｐ３に示すように画像が変化する。画像Ｐ３には、選択したカードを進化合成のベースカードとして確定させるためのボタンｂ６（「選択する」）と、画像Ｐ２に戻って別のカードをベースカードとして選択するためのボタンｂ７（「戻る」）とが含まれる。
画像Ｐ３においてユーザによってボタンｂ６が指定されると、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしていない（すべての参照カードがユーザの所持カードとして揃っていない）場合には、Ｐ４に示すように画像が更新される。
なお、画像Ｐ３においてユーザがボタンｂ６を指定した時点で、ベースカードとして選択されたカードＫＬＭが進化するために必要な参照カードの条件を満たしている場合には、画像Ｐ４に代えて、カードＫＬＭの進化合成を実行するか否かについてのユーザが指示するための画像（図示せず）が表示される。
画像Ｐ４では、進化前カード（ここでは、ベースカードであるカードＫＬＭ）と進化後カード（例えば、カードＱＲＳ）とを示す表示領域１０１、進化合成に必要な参照カードとその所持状態（所持、未所持のいずれか）を示す表示領域１０２、および、選択されたベースカードおよびその参照カードを予約するためのボタンｂ８（「予約する」）を含む。画像Ｐ４においてボタンｂ８が指定されると、ベースカードおよび参照カードについて予約が実行され、予約が完了したことを示す画像Ｐ５が表示される。
（Ｂ）予約済カードの売却処理（図１０）
予約済カードが目的とする進化合成以外の処理に用いられる場合の一例として、予約済カードの売却処理について説明する。
図１０は、ユーザが予約済カードを売却するときの処理を実行するときの一連の表示画面の変化を示している。図１０において、画像Ｐ１は図９に示したものと同じである。
画像Ｐ１においてボタンｂ５（「売却」）が指定されると、Ｐ７に示すように画像が変化する。画像Ｐ７では、ユーザの所持カードの一覧が表示される。画像Ｐ７の所持カードの一覧の中からユーザが売却することを希望するカードを選択する。このとき、所持カードの中から予約済カードを売却対象として選択した場合、Ｐ８に示すように画像が変化する。画像Ｐ８は、ユーザが選択したカードが予約済カードであることを通知するためのテキストと、売却処理を続行するか否かを選択させるためのボタンｂ１０（「続ける」）およびｂ１１（「戻る」）を含む。画像Ｐ８においてボタンｂ１０が指定された場合には、予約済カードであっても売却処理が行われ、それによってユーザは当該カードに対応する売却価格のポイントを得るとともに予約済カードを失う。
（Ｂ）予約済カードの売却処理（図１０）
予約済カードが目的とする進化合成以外の処理に用いられる場合の一例として、予約済カードの売却処理について説明する。
図１０は、ユーザが予約済カードを売却するときの処理を実行するときの一連の表示画面の変化を示している。図１０において、画像Ｐ１は図９に示したものと同じである。
画像Ｐ１においてボタンｂ５（「売却」）が指定されると、Ｐ７に示すように画像が変化する。画像Ｐ７では、ユーザの所持カードの一覧が表示される。画像Ｐ７の所持カードの一覧の中からユーザが売却することを希望するカードを選択する。このとき、所持カードの中から予約済カードを売却対象として選択した場合、Ｐ８に示すように画像が変化する。画像Ｐ８は、ユーザが選択したカードが予約済カードであることを通知するためのテキストと、売却処理を続行するか否かを選択させるためのボタンｂ１０（「続ける」）およびｂ１１（「戻る」）を含む。画像Ｐ８においてボタンｂ１０が指定された場合には、予約済カードであっても売却処理が行われ、それによってユーザは当該カードに対応する売却価格のポイントを得るとともに予約済カードを失う。
画像Ｐ８に示すように、予約済カードについて売却処理の実行手続きを煩雑にすることは、予約済カードが進化合成以外の処理に用いられることを制限する一例である。
また、図１０には図示していないが、画像Ｐ７において、ユーザの所持カードの一覧を、予約済カードについては選択できないような態様で表示するようにしてもよい。すなわち、予約済カードが進化合成以外の処理に用いられることをより確実に防止するために、予約済カードの売却処理の実行が禁止されるようにしてもよい。
また、図１０には図示していないが、画像Ｐ７において、ユーザの所持カードの一覧を、予約済カードについては選択できないような態様で表示するようにしてもよい。すなわち、予約済カードが進化合成以外の処理に用いられることをより確実に防止するために、予約済カードの売却処理の実行が禁止されるようにしてもよい。
（Ｃ）新たな進化予約を実行したことで予約済カードが重複した場合の処理（図１１）
図１１の画像Ｐ５ａを参照して、新たな進化予約を実行したことで予約済カードが重複した場合の処理について説明する。この例では、ベースカードＲＩＭ，ＫＬＭと各ベースカードに対応する参照カードとが予約済カードとして記録されている場合（それぞれ、表示領域１１０の進化予約１，表示領域１２０の進化予約２）を考える。ここでは、参照カードＤＳＧが重複カードである。このように重複カードが存在する場合、ユーザに対して、重複カードが存在することが報知される。
なお、画像Ｐ５ａが表示されるタイミングは、例えば、図９の画像Ｐ４のボタンｂ８が指定されたタイミングであってもよい。すなわち、新たな進化予約（この例では、ベースカードＫＬＭの進化合成に対する予約）を実行するタイミングで、その進化予約と、既に実行された進化予約（この例では、ベースカードＲＩＭの進化合成に対する予約）との間で、参照カードＤＳＧが重複することが判断され、重複カードが存在することがユーザに通知される。
図１１の画像Ｐ５ａを参照して、新たな進化予約を実行したことで予約済カードが重複した場合の処理について説明する。この例では、ベースカードＲＩＭ，ＫＬＭと各ベースカードに対応する参照カードとが予約済カードとして記録されている場合（それぞれ、表示領域１１０の進化予約１，表示領域１２０の進化予約２）を考える。ここでは、参照カードＤＳＧが重複カードである。このように重複カードが存在する場合、ユーザに対して、重複カードが存在することが報知される。
なお、画像Ｐ５ａが表示されるタイミングは、例えば、図９の画像Ｐ４のボタンｂ８が指定されたタイミングであってもよい。すなわち、新たな進化予約（この例では、ベースカードＫＬＭの進化合成に対する予約）を実行するタイミングで、その進化予約と、既に実行された進化予約（この例では、ベースカードＲＩＭの進化合成に対する予約）との間で、参照カードＤＳＧが重複することが判断され、重複カードが存在することがユーザに通知される。
（Ｄ）新たなカードを取得したことで予約済カードが重複した場合の処理（図１２）
図１２の画像Ｐ１１を参照して、新たなカードを取得したことで予約済カードが重複した場合の処理について説明する。
図１２において画像Ｐ１０は、ユーザがゲームを実行中に新たなカードＤＳＧを入手した場合に表示される画像の一例である。ここでは、カードＤＳＧが重複カードであって、ベースカードＲＩＭ，ＫＬＭの予約済みの参照カードとして記録されている場合（それぞれ、表示領域１１０の進化予約１，表示領域１２０の進化予約２）を考える。なお、この時点でユーザは、カードＤＳＧを所持していない。
ユーザがゲームを実行中に新たなカードＤＳＧを入手した場合には、画像Ｐ１１に示すように、異なる進化予約について重複カードＤＳＧが存在する場合、ユーザに対して、重複カードが存在することが報知される。
また、好ましくは、入手した重複カードＤＳＧを２以上の進化予約１，２のいずれに対応付けるかユーザが選択するためのボタンｂ２１，ｂ２２が設けられる。ここで、ボタンｂ２２が指定された場合には、入手したカードＤＳＧのシリアル番号が、進化予約２の予約ＩＤに対応して予約データテーブルに書き込まれる。さらに、カードＤＳＧを入手したことによって、進化予約２に対応するベースカードＫＬＭの参照カードの組合せ条件が満たされるようになった（つまり、進化させるのに必要な参照カードがすべて揃った）ため、ベースカードＫＬＭの進化合成が実行可能となったことがユーザに通知される。
ボタンｂ２１が指定された場合には、入手したカードＤＳＧのシリアル番号が、進化予約１の予約ＩＤに対応して予約データテーブルに書き込まれる。この場合、ベースカードＲＩＭに対応する組合せ条件に含まれる参照カードＴＯＭをユーザが所持していないため、未だベースカードＲＩＭを進化させることはできない。一方、カードＤＳＧを入手したことによって、ベースカードＫＬＭ（進化予約２）を進化させるのに必要な参照カードをユーザが所持する状態となったが、カードＤＳＧは、進化予約２に対応付けられたことから、ベースカードＲＩＭ（進化予約１）の進化合成以外の処理である、ベースカードＫＬＭ（進化予約２）の進化合成の処理は制限される。
図１２の画像Ｐ１１を参照して、新たなカードを取得したことで予約済カードが重複した場合の処理について説明する。
図１２において画像Ｐ１０は、ユーザがゲームを実行中に新たなカードＤＳＧを入手した場合に表示される画像の一例である。ここでは、カードＤＳＧが重複カードであって、ベースカードＲＩＭ，ＫＬＭの予約済みの参照カードとして記録されている場合（それぞれ、表示領域１１０の進化予約１，表示領域１２０の進化予約２）を考える。なお、この時点でユーザは、カードＤＳＧを所持していない。
ユーザがゲームを実行中に新たなカードＤＳＧを入手した場合には、画像Ｐ１１に示すように、異なる進化予約について重複カードＤＳＧが存在する場合、ユーザに対して、重複カードが存在することが報知される。
また、好ましくは、入手した重複カードＤＳＧを２以上の進化予約１，２のいずれに対応付けるかユーザが選択するためのボタンｂ２１，ｂ２２が設けられる。ここで、ボタンｂ２２が指定された場合には、入手したカードＤＳＧのシリアル番号が、進化予約２の予約ＩＤに対応して予約データテーブルに書き込まれる。さらに、カードＤＳＧを入手したことによって、進化予約２に対応するベースカードＫＬＭの参照カードの組合せ条件が満たされるようになった（つまり、進化させるのに必要な参照カードがすべて揃った）ため、ベースカードＫＬＭの進化合成が実行可能となったことがユーザに通知される。
ボタンｂ２１が指定された場合には、入手したカードＤＳＧのシリアル番号が、進化予約１の予約ＩＤに対応して予約データテーブルに書き込まれる。この場合、ベースカードＲＩＭに対応する組合せ条件に含まれる参照カードＴＯＭをユーザが所持していないため、未だベースカードＲＩＭを進化させることはできない。一方、カードＤＳＧを入手したことによって、ベースカードＫＬＭ（進化予約２）を進化させるのに必要な参照カードをユーザが所持する状態となったが、カードＤＳＧは、進化予約２に対応付けられたことから、ベースカードＲＩＭ（進化予約１）の進化合成以外の処理である、ベースカードＫＬＭ（進化予約２）の進化合成の処理は制限される。
なお、重複カードが存在するか否か判定し、存在する場合にはその旨をユーザに通知するタイミングは、上記（Ｃ），（Ｄ）の場合に限られず、ユーザの所望のタイミングであってもよい。
（１−７）情報処理装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためにゲームサーバ２０が備える機能について説明する。図１３は、本実施形態のゲームサーバ２０で主要な役割を果たす機能を説明するための機能ブロック図である。図１３において、データテーブル群７０は、前述したように、カードデータテーブル、進化合成データテーブル、所持カードデータテーブル、および、予約データテーブルを含む。なお、図１３に示す機能ブロック図に含まれる手段のすべてが本発明に必須の要素とは限らない。例えば、本発明の一態様では、受付手段５１、出力手段５６、および、対応付け手段５７を備えていればよい。また、条件設定手段６０は、変形例において言及される。
次に、上述した本実施形態のゲームを実現するためにゲームサーバ２０が備える機能について説明する。図１３は、本実施形態のゲームサーバ２０で主要な役割を果たす機能を説明するための機能ブロック図である。図１３において、データテーブル群７０は、前述したように、カードデータテーブル、進化合成データテーブル、所持カードデータテーブル、および、予約データテーブルを含む。なお、図１３に示す機能ブロック図に含まれる手段のすべてが本発明に必須の要素とは限らない。例えば、本発明の一態様では、受付手段５１、出力手段５６、および、対応付け手段５７を備えていればよい。また、条件設定手段６０は、変形例において言及される。
受付手段５１は、ユーザの操作入力に関する情報に基づいてユーザからの各種の要求を受け付ける機能を備える。本実施形態のゲームにおいてユーザからの要求としては、例えば、カードの進化合成処理の要求、進化合成の予約処理の要求、進化合成の実行要求、ユーザの所持カードの売却処理の要求などがある。
進化合成の予約処理の要求は、出力手段５６により画像データが出力されたことに応じて、進化合成におけるベースカード、および、ベースカードに対応する組合せ条件に含まれる複数の参照カードを進化合成のために予約し、当該進化合成以外の処理を制限させる要求である。
受付手段５１の機能を実現するために、ゲームサーバ２０は、通信インタフェース部２４を介して、ユーザ端末１０から画像であるウェブページ内のユーザによるボタンの操作入力に対応する要求を受信する。ゲームサーバ２０のＣＰＵ２１は、受信した要求に含まれる情報に基づいて、要求の内容を判別し、要求の受付処理を行う。受付処理では、要求がＲＡＭ１３に記録される。ＣＰＵ２１は、受け付けられた要求に応じた処理を順に実行する。
進化合成の予約処理の要求は、出力手段５６により画像データが出力されたことに応じて、進化合成におけるベースカード、および、ベースカードに対応する組合せ条件に含まれる複数の参照カードを進化合成のために予約し、当該進化合成以外の処理を制限させる要求である。
受付手段５１の機能を実現するために、ゲームサーバ２０は、通信インタフェース部２４を介して、ユーザ端末１０から画像であるウェブページ内のユーザによるボタンの操作入力に対応する要求を受信する。ゲームサーバ２０のＣＰＵ２１は、受信した要求に含まれる情報に基づいて、要求の内容を判別し、要求の受付処理を行う。受付処理では、要求がＲＡＭ１３に記録される。ＣＰＵ２１は、受け付けられた要求に応じた処理を順に実行する。
ゲーム処理手段５２は、受付手段５１にて受け付けたユーザ端末１０からの要求に基づいて、進化合成以外の様々なゲームの処理を実行する機能を備える。本実施形態のゲームの処理は、適宜設けられてよいが、例えば、ユーザ間の対戦処理、ユーザ対ＮＰＣの対戦処理、ユーザによるクエスト処理、ユーザの所持カードの通常合成の処理、ユーザの所持カードの売却処理である。
対戦処理については詳しく述べないが、例えば、ユーザは、コストの総和が所定の上限値以下となるように予め複数の所持カードからなるチームを編成し、チームによって他のユーザまたはＮＰＣと対戦する。対戦結果は、チームを構成する各カードの攻撃力、防御力、スキルなどのパラメータによって決定される。
クエスト処理は、ユーザがゲーム内のエリアを探索する処理を行うことで、カードやアイテムを入手するための処理である。
対戦処理については詳しく述べないが、例えば、ユーザは、コストの総和が所定の上限値以下となるように予め複数の所持カードからなるチームを編成し、チームによって他のユーザまたはＮＰＣと対戦する。対戦結果は、チームを構成する各カードの攻撃力、防御力、スキルなどのパラメータによって決定される。
クエスト処理は、ユーザがゲーム内のエリアを探索する処理を行うことで、カードやアイテムを入手するための処理である。
ユーザの所持カードの通常合成の処理を実行する場合のゲーム処理手段５２の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ベースカードおよび参照カードについてのユーザの選択結果を含む通常合成の実行要求を受け付けると、所持カードデータテーブルからベースカードおよび参照カードのカードデータを読み出してＲＡＭ２３に展開する。次いでゲームサーバ２０のＣＰＵ２１は、ベースカードおよび参照カードのパラメータに基づいてベースカードのパラメータ（例えば、カードレベルやスキルレベル）を変更し、変更後のベースカードのパラメータを所持カードデータテーブルに書き込むとともに、所持カードデータテーブルから参照カードとした所持カードのカードデータを削除する。なお、ベースカードのカードレベルやスキルレベルは、通常合成を実行する度に常に増加するとは限らない。例えば、通常合成を実行する度にカードに関連付けられた育成パラメータの値を増加させ、その育成パラメータの値が所定値に達した場合にカードレベルを１つ増加させるとともに育成パラメータの値をゼロにリセットするようにしてもよい。
ユーザの所持カードの売却処理を実行する場合のゲーム処理手段５２の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、売却処理の要求を受け付け、売却対象のカードの選択結果を取得すると、所持カードデータテーブルから売却対象のカードのカードデータを削除する。さらにゲームサーバ２０のＣＰＵ２１は、カードデータテーブルから売却対象のカードの売却価格の値（ポイント）を読み出し、読み出したポイントをユーザに付与する処理を行う。ポイントをユーザに付与する処理は、例えば、ユーザデータベース（図示せず）に記録されているユーザの所持ポイントの値を更新する処理である。
第１判定手段５３は、ベースカードに対応する組合せ条件である複数の参照カードがユーザの所持カードに含まれるという条件を満たすか否かを判定する機能を備える。
第１判定手段５３の機能を実現するために、例えば、ゲームサーバ２０のＣＰＵ２１は、予約データテーブルにおいて判定対象とする予約ＩＤに対応する参照カードがすべて揃ったか否か判定する。具体的には、ゲームサーバ２０のＣＰＵ２１は、判定対象とする予約ＩＤに対応する進化ＩＤに対応する各参照カードＩＤ（図６の進化合成データテーブルのＣ１〜Ｃ５の欄に記録されているカードＩＤ）を、進化合成データテーブルから読み出す。さらにＣＰＵ２１は、読み出したＣ１〜Ｃ５の欄のカードＩＤに対応した、予約データテーブルにおける参照カードのＣ１〜Ｃ５のすべての欄に、シリアル番号が記録されているか否か判定する。すべての欄にシリアル番号が記録されている場合には、ベースカードに対応する複数の参照カードの組合せがユーザの所持カードに含まれるという条件を満たしたことになる。
第１判定手段５３の機能を実現するために、例えば、ゲームサーバ２０のＣＰＵ２１は、予約データテーブルにおいて判定対象とする予約ＩＤに対応する参照カードがすべて揃ったか否か判定する。具体的には、ゲームサーバ２０のＣＰＵ２１は、判定対象とする予約ＩＤに対応する進化ＩＤに対応する各参照カードＩＤ（図６の進化合成データテーブルのＣ１〜Ｃ５の欄に記録されているカードＩＤ）を、進化合成データテーブルから読み出す。さらにＣＰＵ２１は、読み出したＣ１〜Ｃ５の欄のカードＩＤに対応した、予約データテーブルにおける参照カードのＣ１〜Ｃ５のすべての欄に、シリアル番号が記録されているか否か判定する。すべての欄にシリアル番号が記録されている場合には、ベースカードに対応する複数の参照カードの組合せがユーザの所持カードに含まれるという条件を満たしたことになる。
変更手段５４は、第１判定手段５３によって条件を満たすと判定された場合に、ベースカードのカードデータを変更する進化合成を実行する機能を備える。進化合成は、カードを変化させる処理の一例である。
本実施形態の例では、変更手段５４の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、進化合成の実行要求を受け付けると、所持カードデータテーブルにおいて、進化前カード（つまり、進化合成のベースカード）のカードデータを消去し、進化後カードのカードデータを新たに書き込む。それによって、ユーザの所持カードのベースカードが進化することになる。なお、進化合成データテーブルに示すように、進化前と進化後とでカードＩＤは異なるため、カード名、カード画像、および、カードパラメータのうち少なくともいずれかが進化合成によって変更される。
本実施形態の例では、変更手段５４の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、進化合成の実行要求を受け付けると、所持カードデータテーブルにおいて、進化前カード（つまり、進化合成のベースカード）のカードデータを消去し、進化後カードのカードデータを新たに書き込む。それによって、ユーザの所持カードのベースカードが進化することになる。なお、進化合成データテーブルに示すように、進化前と進化後とでカードＩＤは異なるため、カード名、カード画像、および、カードパラメータのうち少なくともいずれかが進化合成によって変更される。
第２判定手段５５は、予約データテーブルにおいてユーザに対応付けられた複数のベースカード（進化前カード）あるいは複数の予約ＩＤについて、それぞれに対応する組合せ条件（変化条件の一例）に含まれる複数のカードＩＤの少なくとも１つが重複するか否かを判定する機能を備える。
第２判定手段５５による判定タイミングは特に限定するものではないが、好ましいタイミングとしては、新たな進化予約を実行したタイミング（図１１参照）、新たなカードを取得したタイミング（図１２参照）、および、ユーザからの判定要求によるタイミングである。すなわち、第２判定手段５５による機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０から進化合成の予約処理の要求を受け付けた場合、ユーザが入手するカードを決定した場合、あるいは、ユーザからの判定要求を受け付けた場合等に、予約データテーブルおよび進化合成データテーブルを参照して、複数のカードＩＤの少なくとも１つが重複するか否かを判定する処理を行う。
具体的にはＣＰＵ２１は先ず、ユーザの予約データテーブルの各予約ＩＤの進化前カードのシリアル番号に対応するカードＩＤに対応した複数の参照カードのカードＩＤを進化合成データテーブルから読み出し、異なる予約ＩＤの間で同一のカードＩＤの参照カードが存在するか否かを判定し、同一の（つまり、重複する）カードＩＤの参照カードが存在する場合には、そのすべてを抽出する。
第２判定手段５５による判定タイミングは特に限定するものではないが、好ましいタイミングとしては、新たな進化予約を実行したタイミング（図１１参照）、新たなカードを取得したタイミング（図１２参照）、および、ユーザからの判定要求によるタイミングである。すなわち、第２判定手段５５による機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０から進化合成の予約処理の要求を受け付けた場合、ユーザが入手するカードを決定した場合、あるいは、ユーザからの判定要求を受け付けた場合等に、予約データテーブルおよび進化合成データテーブルを参照して、複数のカードＩＤの少なくとも１つが重複するか否かを判定する処理を行う。
具体的にはＣＰＵ２１は先ず、ユーザの予約データテーブルの各予約ＩＤの進化前カードのシリアル番号に対応するカードＩＤに対応した複数の参照カードのカードＩＤを進化合成データテーブルから読み出し、異なる予約ＩＤの間で同一のカードＩＤの参照カードが存在するか否かを判定し、同一の（つまり、重複する）カードＩＤの参照カードが存在する場合には、そのすべてを抽出する。
出力手段５６は、第２判定手段５５によって複数のカードＩＤの少なくとも１つが重複すると判定された場合には、重複する参照カードのカードＩＤを示す画像データを出力する機能を備える。
出力手段５６の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、異なる予約ＩＤの間で重複するカードＩＤに対応する参照カードをすべて含む画像データを生成して出力する。なお、画像データによって表示される画像には、カードＩＤ自体が表示されている必要はなく、カードＩＤによって特定されるカードの画像、カード名、あるいはそれらの組合せであればよい。
出力手段５６の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、異なる予約ＩＤの間で重複するカードＩＤに対応する参照カードをすべて含む画像データを生成して出力する。なお、画像データによって表示される画像には、カードＩＤ自体が表示されている必要はなく、カードＩＤによって特定されるカードの画像、カード名、あるいはそれらの組合せであればよい。
対応付け手段５７は、進化合成の予約処理の要求を受け付けたことに応じて、ベースカード（進化前カード）とユーザとを対応付ける機能を備える。なお、ベースカードとユーザとの対応付けは、予約ＩＤ（対応付け情報の一例）と関連付けて行われる。
対応付け手段５７の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ベースカードが選択された、進化合成の予約処理の要求を受け付けると、新たな予約ＩＤを発行する。ＣＰＵ２１は、発行した予約ＩＤに対応付けて、ベースカードとして選択されたカードのシリアル番号を「進化前カード」の欄に書き込む。当該ベースカードの組合せ条件に含まれる参照カードをユーザが所持している場合には、ＣＰＵ２１は、その参照カードのシリアル番号を所持カードデータテーブルから読み出し、読み出したシリアル番号を、予約データテーブルにおいて対応する参照カードのカードＩＤの欄（Ｃ１〜Ｃ５の欄のいずれか）に書き込む。ＣＰＵ２１は、上記ベースカードの組合せ条件に含まれる参照カードのうちユーザが所持していない参照カードのカードＩＤの欄（Ｃ１〜Ｃ５の欄のいずれか）には、「未所持」に相当するコードを書き込む。カードの所持あるいは未所持の判定のために、所持カードデータテーブルが参照される。
対応付け手段５７の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ベースカードが選択された、進化合成の予約処理の要求を受け付けると、新たな予約ＩＤを発行する。ＣＰＵ２１は、発行した予約ＩＤに対応付けて、ベースカードとして選択されたカードのシリアル番号を「進化前カード」の欄に書き込む。当該ベースカードの組合せ条件に含まれる参照カードをユーザが所持している場合には、ＣＰＵ２１は、その参照カードのシリアル番号を所持カードデータテーブルから読み出し、読み出したシリアル番号を、予約データテーブルにおいて対応する参照カードのカードＩＤの欄（Ｃ１〜Ｃ５の欄のいずれか）に書き込む。ＣＰＵ２１は、上記ベースカードの組合せ条件に含まれる参照カードのうちユーザが所持していない参照カードのカードＩＤの欄（Ｃ１〜Ｃ５の欄のいずれか）には、「未所持」に相当するコードを書き込む。カードの所持あるいは未所持の判定のために、所持カードデータテーブルが参照される。
なお、予約ＩＤが発行済みである場合には、「進化前カード」の欄にはシリアル番号が既に記録されている。このとき、進化前カードに相当するベースカードに対応する参照カードのいずれかを入手した場合には、その入手カードが重複カードでなければ入手カードのシリアル番号を、予約データテーブルにおいて対応する参照カードのカードＩＤの欄（Ｃ１〜Ｃ５の欄のいずれか）に書き込む。入手カードが重複カードである場合には、ユーザによって指定された予約ＩＤまたは予約済みのベースカードに対応する参照カードのカードＩＤの欄（Ｃ１〜Ｃ５の欄のいずれか）に、入手カードのシリアル番号を書き込む。
特定手段５８は、予約データテーブルにおいて複数の予約ＩＤまたは複数のベースカード（進化前カード）について、それぞれに対応する複数の参照カードＩＤの少なくとも１つが重複する場合に、ユーザによる操作に基づいて、複数の予約ＩＤのいずれか、または、複数のベースカードのいずれかを特定する機能を備える。本実施形態では、予約データテーブルに示すように、予約ＩＤとベースカード（進化前カード）は一意に対応しているため、ベースカードと予約ＩＤのいずれを特定しても特定対象は実質的に同一である。
特定手段５８は、第１特定手段、または、第２特定手段の一例である。
特定手段５８の機能を実現するため、ゲームサーバ２０のＣＰＵ２１は、参照カードＩＤが重複している複数の予約ＩＤのいずれか、または複数のベースカードのいずれかに対するユーザの指定結果を認識する。例えば、図１２の画像Ｐ１１において、ボタンｂ２１，ｂ２２は、進化予約１，２に対応している。また、画像Ｐ１１を作成するときには、進化予約１，２が、それぞれ異なる予約ＩＤに対応付けられているとともに、ベースカードＲＩＭ，ＫＬＭに対応している。そのため、ゲームサーバ２０のＣＰＵ２１は、ユーザによるボタンｂ２１，ｂ２２の指定結果を受け付け、指定結果に対応する予約ＩＤまたは予約済みのベースカードを特定する。
特定手段５８は、第１特定手段、または、第２特定手段の一例である。
特定手段５８の機能を実現するため、ゲームサーバ２０のＣＰＵ２１は、参照カードＩＤが重複している複数の予約ＩＤのいずれか、または複数のベースカードのいずれかに対するユーザの指定結果を認識する。例えば、図１２の画像Ｐ１１において、ボタンｂ２１，ｂ２２は、進化予約１，２に対応している。また、画像Ｐ１１を作成するときには、進化予約１，２が、それぞれ異なる予約ＩＤに対応付けられているとともに、ベースカードＲＩＭ，ＫＬＭに対応している。そのため、ゲームサーバ２０のＣＰＵ２１は、ユーザによるボタンｂ２１，ｂ２２の指定結果を受け付け、指定結果に対応する予約ＩＤまたは予約済みのベースカードを特定する。
制限手段５９は、特定手段５８によって特定された予約ＩＤまたは予約済みのベースカードのカードＩＤに対応する組合せ条件に含まれる複数のカードＩＤによって特定される参照カードがユーザの所持カードである場合、当該所持カードに対して、目的とする進化合成とは異なる処理に用いられることを制限する機能を備える。「目的とする進化合成以外の処理に用いられる」とは、目的とする進化合成に対応付けられて予約済カードとして記録されているカードが、その目的とする進化合成以外の進化合成や通常合成に用いられる場合も含まれる。
制限手段５９による制限方法は様々な方法が考えられる。例えば、制限対象となるカードを、ユーザが目的とする進化合成以外の処理を禁止する方法や、制限対象となるカードが目的とする進化合成以外の処理のために選択されたときに、ユーザに対して警告を行う、あるいは当該処理の続行を確認する処理を行う方法などが挙げられる。
制限手段５９による制限方法は様々な方法が考えられる。例えば、制限対象となるカードを、ユーザが目的とする進化合成以外の処理を禁止する方法や、制限対象となるカードが目的とする進化合成以外の処理のために選択されたときに、ユーザに対して警告を行う、あるいは当該処理の続行を確認する処理を行う方法などが挙げられる。
例えば、ゲームサーバ２０のＣＰＵ２１は、本実施形態のゲームの様々な処理のいずれかの処理の実行要求を受け付けた場合、ユーザの所持カードが処理対象のカードとして選択されたときには、所持カードデータテーブルを参照して、当該選択されたカードのカードＩＤに予約ＩＤが対応付けられているか否かについて判定する。ＣＰＵ２１は、選択されたカードのカードＩＤに予約ＩＤが対応付けられ、かつ実行要求に係る処理が予約ＩＤに対応する進化合成の処理ではない場合には、当該処理を禁止してもよいし、選択されたカードが予約済カードであることをユーザに報知してもよい。あるいは、選択されたカードが予約済カードであることをユーザに報知するとともに、処理を続行するか否かについてユーザに確認してもよい。予約データテーブルには進化ＩＤと予約済カードのシリアル番号が対応付けられているため、ゲームサーバ２０のＣＰＵ２１は、予約済カードに対応した、目的とする進化合成（つまり、特定の進化ＩＤに対応した進化合成）を特定することができる。そのため、ユーザが特定の所持カードを用いて実行しようとする処理が、目的とする進化合成の処理であるか否かを判別することができる。
（１−８）本実施形態のゲームの処理フロー
次に、本実施形態のゲームの処理フローの一例について、図１４Ａ〜図１４Ｂ、図１５Ａ〜図１５Ｂ、図１６Ａ〜図１６Ｂ、図１７のシーケンスチャートを参照して説明する。
図１４Ａおよび図１４Ｂは、進化合成の予約処理を示すシーケンスチャートである。図１５Ａおよび図１５Ｂは、予約済カードの売却処理を示すシーケンスチャートである。図１６Ａおよび図１６Ｂは、カード入手時の処理を示すシーケンスチャートである。図１７は、進化合成処理を示すシーケンスチャートである。
なお、各図において、図９〜１２に示した各画像が表示される処理に各画像の符号を付してある。
次に、本実施形態のゲームの処理フローの一例について、図１４Ａ〜図１４Ｂ、図１５Ａ〜図１５Ｂ、図１６Ａ〜図１６Ｂ、図１７のシーケンスチャートを参照して説明する。
図１４Ａおよび図１４Ｂは、進化合成の予約処理を示すシーケンスチャートである。図１５Ａおよび図１５Ｂは、予約済カードの売却処理を示すシーケンスチャートである。図１６Ａおよび図１６Ｂは、カード入手時の処理を示すシーケンスチャートである。図１７は、進化合成処理を示すシーケンスチャートである。
なお、各図において、図９〜１２に示した各画像が表示される処理に各画像の符号を付してある。
（Ａ）進化合成の予約処理（図１４Ａ，図１４Ｂ）
図１４Ａにおいて、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図９の画像Ｐ１のボタンｂ４）をユーザが指定することによって、ユーザ端末１０のＣＰＵ１１は進化合成処理の要求を受け付け（Ｓ１０）、当該要求をゲームサーバ２０へ送信する（Ｓ１２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの進化合成処理の要求を受け付けると、進化合成データテーブルおよび所持カードデータテーブルを参照して、進化可能なユーザの所持カードを読み出す（Ｓ１４）。すなわち、ゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルからユーザの所持カードのカードデータを読み出し、進化合成データテーブルの進化前カードＩＤ（つまり、進化可能なカードのカードＩＤ）をすべて読み出す。次いでＣＰＵ２１は、ユーザの所持カードの中から進化可能なカード（つまり、ベースカード候補）のカードＩＤに対応するシリアル番号を特定し、ベースカード候補の一覧を含む画像データを生成して（Ｓ１６）、ユーザ端末１０へ送信する（Ｓ１８）。
なお、Ｓ１６で生成される画像データは、図９の画像Ｐ２に示したように、ユーザの所持カードのうち予約済みではない進化可能なカードと、進化不可能であるか、若しくは既にベースカードとして予約済みのカードとをユーザが識別可能な表示形式で生成されることが好ましい。その場合には、予約済みか否かを判定するために、ＣＰＵ２１は、予約データテーブルの進化前カードの欄のシリアル番号を参照する。
図１４Ａにおいて、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図９の画像Ｐ１のボタンｂ４）をユーザが指定することによって、ユーザ端末１０のＣＰＵ１１は進化合成処理の要求を受け付け（Ｓ１０）、当該要求をゲームサーバ２０へ送信する（Ｓ１２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの進化合成処理の要求を受け付けると、進化合成データテーブルおよび所持カードデータテーブルを参照して、進化可能なユーザの所持カードを読み出す（Ｓ１４）。すなわち、ゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルからユーザの所持カードのカードデータを読み出し、進化合成データテーブルの進化前カードＩＤ（つまり、進化可能なカードのカードＩＤ）をすべて読み出す。次いでＣＰＵ２１は、ユーザの所持カードの中から進化可能なカード（つまり、ベースカード候補）のカードＩＤに対応するシリアル番号を特定し、ベースカード候補の一覧を含む画像データを生成して（Ｓ１６）、ユーザ端末１０へ送信する（Ｓ１８）。
なお、Ｓ１６で生成される画像データは、図９の画像Ｐ２に示したように、ユーザの所持カードのうち予約済みではない進化可能なカードと、進化不可能であるか、若しくは既にベースカードとして予約済みのカードとをユーザが識別可能な表示形式で生成されることが好ましい。その場合には、予約済みか否かを判定するために、ＣＰＵ２１は、予約データテーブルの進化前カードの欄のシリアル番号を参照する。
ユーザ端末１０のＣＰＵ１１は、Ｓ１８で送信された画像データを取得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ２０）。Ｓ２０で表示される画像には、図９の画像Ｐ２に例示したように、ベースカード候補となる複数のカードの画像が含まれ、各カードの画像を操作することで各カードのシリアル番号が選択可能となるようにして構成されている。Ｓ２０で表示された複数のベースカード候補の中でいずれかのカードがベースカードとして選択する操作が行われると、ＣＰＵ１１は、ベースカードの選択結果（シリアル番号）を受け付け（Ｓ２２）、その選択結果をゲームサーバ２０へ送信する（Ｓ２４）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からベースカードの選択結果（シリアル番号）を取得すると、進化合成データテーブルを参照し、ユーザによって選択されたベースカードのシリアル番号に対応するカードＩＤと一致する進化前カードＩＤに対応する組合せ条件となる複数の参照カードＩＤ（Ｃ１〜Ｃ５の欄のカードＩＤ）を読み出す（Ｓ２６）。次いでＣＰＵ２１は、所持カードデータテーブルを参照して、Ｓ２６で読み出した各参照カードＩＤに対応するカードに対するユーザの所持状態（未所持または所持）を特定し、その特定結果に基づいて画像データを生成する（Ｓ２８）。
Ｓ２８で生成される画像データは、カードの状態の特定結果によって異なってもよい。
すなわち、Ｓ２６で読み出したすべての参照カードの状態が「所持」である場合には、ベースカードとして選択されたカードの進化合成に必要な参照カードがすべて揃っていることを意味するため、ゲームサーバ２０のＣＰＵ２１は、進化合成を実行するか否かについてのユーザが指示するための画像データを生成する。そして、進化合成を実行することを選択する操作入力が行われた場合、図１７に示す進化合成処理に進む。
一方、ＣＰＵ２１は、Ｓ２６で読み出した少なくともいずれかの参照カードの状態が「未所持」である場合（つまり、ベースカードとして選択されたカードの進化合成に必要な参照カードがすべて揃っていない場合）には、ベースカードとして選択されたカード、および、参照カードを進化合成のために予約するための画像データを生成する。
ここでは、後者の場合（いずれかの参照カードの状態が「未所持」である場合）を想定する。後者の場合、ＣＰＵ２１は、図９の画像Ｐ４に例示したように、各参照カードをカード画像と対応付けることで各参照カードがユーザにとって識別可能な表示形式とするとともに、各参照カードに対してカードの状態の特定結果を対応付けるようにして、画像データを生成する。また、画像データは、ベースカードと、所持状態が関連付けられた参照カードと、進化合成の予約処理の要求を受け付けるためのボタン（例えば、図９の画像Ｐ４のボタンｂ８）が表示されるようにして生成される。
すなわち、Ｓ２６で読み出したすべての参照カードの状態が「所持」である場合には、ベースカードとして選択されたカードの進化合成に必要な参照カードがすべて揃っていることを意味するため、ゲームサーバ２０のＣＰＵ２１は、進化合成を実行するか否かについてのユーザが指示するための画像データを生成する。そして、進化合成を実行することを選択する操作入力が行われた場合、図１７に示す進化合成処理に進む。
一方、ＣＰＵ２１は、Ｓ２６で読み出した少なくともいずれかの参照カードの状態が「未所持」である場合（つまり、ベースカードとして選択されたカードの進化合成に必要な参照カードがすべて揃っていない場合）には、ベースカードとして選択されたカード、および、参照カードを進化合成のために予約するための画像データを生成する。
ここでは、後者の場合（いずれかの参照カードの状態が「未所持」である場合）を想定する。後者の場合、ＣＰＵ２１は、図９の画像Ｐ４に例示したように、各参照カードをカード画像と対応付けることで各参照カードがユーザにとって識別可能な表示形式とするとともに、各参照カードに対してカードの状態の特定結果を対応付けるようにして、画像データを生成する。また、画像データは、ベースカードと、所持状態が関連付けられた参照カードと、進化合成の予約処理の要求を受け付けるためのボタン（例えば、図９の画像Ｐ４のボタンｂ８）が表示されるようにして生成される。
ゲームサーバ２０のＣＰＵ２１は、Ｓ２８で生成した画像データをユーザ端末１０へ送信する（Ｓ３０）。ユーザ端末１０のＣＰＵ１１は、Ｓ３０で送信された画像データを取得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ３２）。ここで、進化合成の予約処理の要求を行うための指示（例えば、画像Ｐ４のボタンｂ８の指定）が行われると、ユーザ端末１０のＣＰＵ１１は、進化合成の予約処理の要求を受け付け（Ｓ３４）、当該要求をゲームサーバ２０へ送信する（Ｓ３６）。
進化合成の予約処理の要求を受け付けると、ゲームサーバ２０のＣＰＵ２１は、予約データテーブルにアクセスし、予約ＩＤを発行した後に（Ｓ３８）、予約ＩＤに対応付けて、Ｓ２２で受け付けた選択結果であるベースカード、および、当該ベースカードに対応する参照カード（以上、総称して適宜「予約対象カード」という。）のシリアル番号を、予約データテーブルに書き込む（Ｓ４０）。このとき、ＣＰＵ２１は、予約データテーブルにおいて予約ＩＤに対応するＣ１〜Ｃ５の欄のうちシリアル番号の書き込みを行わない欄（ユーザが未所持の参照カードに対応する欄）には、「未所持」を示すデータ（例えば、ＮＵＬＬ）を書き込む。次にゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルにおいて、予約対象カードのカードＩＤに対応する「予約ＩＤ」の欄に、Ｓ４０の書き込み対象とした予約ＩＤのデータを書き込む（Ｓ４２）。
次いでＣＰＵ２１は、予約データテーブルおよび進化合成データテーブルを参照して、参照カードＩＤが重複する２以上の予約ＩＤがあるか否か判定する（Ｓ４４）。すなわち、２以上の予約ＩＤにおいて複数のカードＩＤの少なくとも１つが重複するか否か判定する。具体的にはＣＰＵ２１は先ず、ユーザの予約データテーブルの各予約ＩＤの進化前カードのシリアル番号に対応するカードＩＤに対応した複数の参照カードのカードＩＤを進化合成データテーブルから読み出し、異なる予約ＩＤの間で同一のカードＩＤの参照カードが存在するか否かを判定する。
そして参照カードＩＤが重複する２以上の予約ＩＤがない場合には（Ｓ４４：ＮＯ）、ＣＰＵ２１は予約が完了したことを示す画像データを生成する（Ｓ４６）。参照カードＩＤが重複する２以上の予約ＩＤがある場合には（Ｓ４４：ＹＥＳ）、ＣＰＵ２１は、重複する参照カードＩＤごとに、すべての予約ＩＤのデータを読み出し、２以上の進化予約（つまり、２以上の予約ＩＤ）で参照カードが重複することを示す画像データを生成する（Ｓ４８）。ＣＰＵ２１は、Ｓ４６またはＳ４８で生成した画像データをユーザ端末１０へ送信する（Ｓ５０）。ユーザ端末１０のＣＰＵ１１は、Ｓ５０で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図９の画像Ｐ５、または、図１１の画像Ｐ５ａ）を表示部１６に表示する（Ｓ５２）。
そして参照カードＩＤが重複する２以上の予約ＩＤがない場合には（Ｓ４４：ＮＯ）、ＣＰＵ２１は予約が完了したことを示す画像データを生成する（Ｓ４６）。参照カードＩＤが重複する２以上の予約ＩＤがある場合には（Ｓ４４：ＹＥＳ）、ＣＰＵ２１は、重複する参照カードＩＤごとに、すべての予約ＩＤのデータを読み出し、２以上の進化予約（つまり、２以上の予約ＩＤ）で参照カードが重複することを示す画像データを生成する（Ｓ４８）。ＣＰＵ２１は、Ｓ４６またはＳ４８で生成した画像データをユーザ端末１０へ送信する（Ｓ５０）。ユーザ端末１０のＣＰＵ１１は、Ｓ５０で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図９の画像Ｐ５、または、図１１の画像Ｐ５ａ）を表示部１６に表示する（Ｓ５２）。
（Ｂ）予約済カードの売却処理（図１５Ａ，図１５Ｂ）
予約済カードの売却処理は、その予約済カードについて目的とする進化合成以外の処理の一例であって、ここでは売却処理が制限される。
図１５Ａにおいて、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図１０の画像Ｐ１のボタンｂ５）をユーザが指定することによって、ユーザ端末１０のＣＰＵ１１は所持カードの売却処理の要求を受け付け（Ｓ８０）、当該要求をゲームサーバ２０へ送信する（Ｓ８２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの所持カードの売却処理の要求を受け付けると、所持カードデータテーブルから所持カードのカードＩＤを特定し、カードデータテーブルおよび所持カードデータテーブルから所持カードのカードデータを読み出して、所持カードの一覧を含む画像データを生成し（Ｓ８４）、その画像データをユーザ端末１０へ送信する（Ｓ８６）。ユーザ端末１０のＣＰＵ１１は、Ｓ８６で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図１０の画像Ｐ７）を表示部１６に表示する（Ｓ８８）。
Ｓ８８で表示される画像には、図１０の画像Ｐ７に例示したように、整列されたユーザの所持カードの画像が含まれ、各カードの画像を選択することで各カードのシリアル番号が選択可能となるようにして構成されている。Ｓ８８で表示された複数の所持カードの中でいずれかのカードが売却対象カードとして選択する操作が行われると、ユーザ端末１０のＣＰＵ１１は、売却対象カードの選択結果（シリアル番号）を受け付け（Ｓ９０）、その選択結果をゲームサーバ２０へ送信する（Ｓ９２）。
予約済カードの売却処理は、その予約済カードについて目的とする進化合成以外の処理の一例であって、ここでは売却処理が制限される。
図１５Ａにおいて、ユーザ端末１０に表示された画像上で所定のボタン（例えば、図１０の画像Ｐ１のボタンｂ５）をユーザが指定することによって、ユーザ端末１０のＣＰＵ１１は所持カードの売却処理の要求を受け付け（Ｓ８０）、当該要求をゲームサーバ２０へ送信する（Ｓ８２）。
ゲームサーバ２０のＣＰＵ２１は、ユーザ端末１０からの所持カードの売却処理の要求を受け付けると、所持カードデータテーブルから所持カードのカードＩＤを特定し、カードデータテーブルおよび所持カードデータテーブルから所持カードのカードデータを読み出して、所持カードの一覧を含む画像データを生成し（Ｓ８４）、その画像データをユーザ端末１０へ送信する（Ｓ８６）。ユーザ端末１０のＣＰＵ１１は、Ｓ８６で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図１０の画像Ｐ７）を表示部１６に表示する（Ｓ８８）。
Ｓ８８で表示される画像には、図１０の画像Ｐ７に例示したように、整列されたユーザの所持カードの画像が含まれ、各カードの画像を選択することで各カードのシリアル番号が選択可能となるようにして構成されている。Ｓ８８で表示された複数の所持カードの中でいずれかのカードが売却対象カードとして選択する操作が行われると、ユーザ端末１０のＣＰＵ１１は、売却対象カードの選択結果（シリアル番号）を受け付け（Ｓ９０）、その選択結果をゲームサーバ２０へ送信する（Ｓ９２）。
ゲームサーバ２０は、ユーザ端末１０から売却対象カードの選択結果（シリアル番号）を取得すると、その売却対象カードが進化合成のための予約済カードである場合には、ユーザに対して警告を行うために以下の処理を行う。すなわち、ゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルを参照して、売却対象カードのシリアル番号に予約ＩＤが対応付けられているか否かについて判定する（Ｓ９４）。売却対象カードのシリアル番号に予約ＩＤが対応付けられている場合には（Ｓ９４：ＹＥＳ）、警告用の画像データを生成し（Ｓ９６）、その画像データをユーザ端末１０へ送信する（Ｓ９８）。ユーザ端末１０のＣＰＵ１１は、Ｓ９８で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図１０の画像Ｐ８）を表示部１６に表示する（Ｓ１００）。
Ｓ１００で表示される画像には、図１０の画像Ｐ８に例示したように、売却処理を続行するか否かを確認するためのボタンが設けられている。このボタンのユーザによる操作に基づいて、ＣＰＵ１１が売却処理の続行要求を受け付けた場合には（Ｓ１０２：ＹＥＳ）、当該要求をゲームサーバ２０へ送信する（Ｓ１０４）。売却処理の続行要求を受け付けない場合には（Ｓ１０２：ＮＯ）、売却対象カードを選択する画像（例えば、図１０の画像Ｐ７）を再度表示してもよい。
Ｓ１００で表示される画像には、図１０の画像Ｐ８に例示したように、売却処理を続行するか否かを確認するためのボタンが設けられている。このボタンのユーザによる操作に基づいて、ＣＰＵ１１が売却処理の続行要求を受け付けた場合には（Ｓ１０２：ＹＥＳ）、当該要求をゲームサーバ２０へ送信する（Ｓ１０４）。売却処理の続行要求を受け付けない場合には（Ｓ１０２：ＮＯ）、売却対象カードを選択する画像（例えば、図１０の画像Ｐ７）を再度表示してもよい。
ユーザ端末１０から受信した売却処理の続行要求を受け付けた場合、または、売却対象カードのシリアル番号に予約ＩＤが対応付けられていない場合（予約済カードでない場合）には（Ｓ９４：ＮＯ）、ゲームサーバ２０のＣＰＵ２１は、売却対象カードのシリアル番号をＲＡＭ２３に記憶させ、所持カードデータテーブルにおいて当該シリアル番号の行のデータを消去する（Ｓ１０６）。さらに、予約データテーブルの更新を行うため、以下の処理を行う。すなわち、図１５Ｂに示すように、ゲームサーバ２０のＣＰＵ２１は、Ｓ１０６で消去したカード（消去対象カード）についてＲＡＭ２３に記憶させたシリアル番号に基づいて、消去対象カードが、予約済みの参照カードであるか、予約済みのベースカードであるか、またはそれらのいずれでもないか判定する（Ｓ１０８）。
ゲームサーバ２０のＣＰＵ２１は、消去対象カードが予約済みの参照カードである場合には、予約データテーブルに記録されている消去対象カードのシリアル番号をすべて消去する（Ｓ１１０）。消去対象カードが予約済みのベースカード（進化前カード）である場合には、予約データテーブルに記録されている消去対象カード（進化前カード）のシリアル番号に対応する行のデータをすべて消去する（Ｓ１１２）。消去対象カードが予約済カードでない場合には、予約データテーブルに対する処理は行わない。
ゲームサーバ２０のＣＰＵ２１は、消去対象カードが予約済みの参照カードである場合には、予約データテーブルに記録されている消去対象カードのシリアル番号をすべて消去する（Ｓ１１０）。消去対象カードが予約済みのベースカード（進化前カード）である場合には、予約データテーブルに記録されている消去対象カード（進化前カード）のシリアル番号に対応する行のデータをすべて消去する（Ｓ１１２）。消去対象カードが予約済カードでない場合には、予約データテーブルに対する処理は行わない。
上述したように、本実施形態では、進化合成の予約済カードが、進化合成以外の処理である売却処理に用いられる場合には、売却処理が実行されることが制限される。すなわち、予約済カードに対して直ちに売却処理が実行されるのではなく、売却対象カードが予約済カードであることをユーザに警告するための画像が提示され、売却処理の続行要求をユーザ端末から取得するまで待ってから、売却処理が実行される。
なお、警告に限られず、売却処理を中断してもよい。例えば、図１０の画像Ｐ７においていずれかの所持カードが選択されたときに、選択されたカードが予約済カードである場合には、以降の処理を禁止してもよい。また、画像Ｐ７において、予約済カードについては暗転表示して選択できないような態様で表示してもよい。
なお、警告に限られず、売却処理を中断してもよい。例えば、図１０の画像Ｐ７においていずれかの所持カードが選択されたときに、選択されたカードが予約済カードである場合には、以降の処理を禁止してもよい。また、画像Ｐ７において、予約済カードについては暗転表示して選択できないような態様で表示してもよい。
（Ｃ）カード入手時の処理（図１６Ａ，図１６Ｂ）
本実施形態のゲームでは、ユーザが新たにカードを入手した場合に入手したカードが２以上の予約ＩＤで重複して予約されている参照カードであるか否かの判定、および、そのカードを入手したことによって予約データテーブルに記録されているベースカードの進化合成が可能になったか否かの判定が行われる。
本フローチャートの例では、ユーザが新たなカードを入手した時点で、複数の進化予約について重複する参照カード（重複カード）が存在するときのユーザの進化予約の指定を受け入れる。ユーザが重複カードを入手したタイミングは、その入手したカードによって、上記複数の進化予約のいずれかの組合せ条件が成立する可能性があることから、上記進化予約の指定を受け入れるのに好適なタイミングである。
本実施形態のゲームでは、ユーザが新たにカードを入手した場合に入手したカードが２以上の予約ＩＤで重複して予約されている参照カードであるか否かの判定、および、そのカードを入手したことによって予約データテーブルに記録されているベースカードの進化合成が可能になったか否かの判定が行われる。
本フローチャートの例では、ユーザが新たなカードを入手した時点で、複数の進化予約について重複する参照カード（重複カード）が存在するときのユーザの進化予約の指定を受け入れる。ユーザが重複カードを入手したタイミングは、その入手したカードによって、上記複数の進化予約のいずれかの組合せ条件が成立する可能性があることから、上記進化予約の指定を受け入れるのに好適なタイミングである。
図１６Ａにおいて、ゲームサーバ２０のＣＰＵ２１がゲームの処理によってユーザに対してカードを付与する場合に、カードデータテーブルからユーザが入手するカード（「入手カード」という。）のカードＩＤを決定する（Ｓ１２０）。入手カードのカードＩＤを決定するとゲームサーバ２０は、ユーザ端末１０に対して、入手カードのカードデータを含む画像データを生成してユーザ端末１０へ送信する（Ｓ１２２）。ユーザ端末１０のＣＰＵ１１は、Ｓ１２２で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図１２の画像Ｐ１０）を表示部１６に表示する（Ｓ１２４）。
次いでゲームサーバ２０のＣＰＵ２１は、入手カードに対応するシリアル番号を発行し、所持カードデータテーブルに、発行したシリアル番号に対応するデータを書き込む（Ｓ１２６）。このデータの書き込みでは、カードレベルおよびスキルレベルは初期値の「１」が書き込まれる。書き込まれるカードＩＤは、Ｓ１２０で決定されたカードＩＤである。
次いでゲームサーバ２０のＣＰＵ２１は、入手カードに対応するシリアル番号を発行し、所持カードデータテーブルに、発行したシリアル番号に対応するデータを書き込む（Ｓ１２６）。このデータの書き込みでは、カードレベルおよびスキルレベルは初期値の「１」が書き込まれる。書き込まれるカードＩＤは、Ｓ１２０で決定されたカードＩＤである。
次に、ゲームサーバ２０のＣＰＵ２１は、予約データテーブルに記録されている進化ＩＤをすべて特定し、特定した進化ＩＤに対応する組合せ条件を構成する複数の参照カードＩＤを、進化合成データテーブルから読み出す（Ｓ１２８）。図１６ＢにおいてＣＰＵ２１は、進化合成データテーブルから読み出した各参照カードＩＤが、入手カードのカードＩＤ（入手カードＩＤ）と一致するか否か判定する（Ｓ１３０）。入手カードＩＤと一致する参照カードＩＤが存在しなければ（Ｓ１３０：ＮＯ）、入手カードは進化予約の処理とは無関係なカードであるため、カード入手時の処理を終了する。
ＣＰＵ２１は、入手カードＩＤと一致する参照カードＩＤが存在した場合には（Ｓ１３０：ＹＥＳ）、「入手カードＩＤ＝参照カードＩＤ」が成立する参照カードＩＤに対応するシリアル番号が予約データテーブルにおいて未書込みである予約ＩＤの数（ＮＵＭ）によって、処理が異なる。
ＣＰＵ２１は、入手カードＩＤと一致する参照カードＩＤが存在した場合には（Ｓ１３０：ＹＥＳ）、「入手カードＩＤ＝参照カードＩＤ」が成立する参照カードＩＤに対応するシリアル番号が予約データテーブルにおいて未書込みである予約ＩＤの数（ＮＵＭ）によって、処理が異なる。
予約ＩＤの数（ＮＵＭ）がゼロである場合には（ＮＵＭ＝０）は、１個の予約ＩＤに対応して予約され、かつ既にユーザが所持する（つまり、シリアル番号が書き込み済みの）参照カードを、追加でユーザが入手したことを意味するため、予約に関する処理は必要なく、カード入手時の処理を終了する。
予約ＩＤの数（ＮＵＭ）が２以上である場合には（ＮＵＭ≧２）、入手カードは２以上の予約ＩＤの間でユーザが未所持の参照カードと同一のカード（同一のカードＩＤのカード）であることから、入手カードをいずれの予約ＩＤに対応付けるかについてユーザに指定させるため、予約ＩＤ指定用画像データを作成して（Ｓ１３８）、ユーザ端末１０へ送信する（Ｓ１４０）。ユーザ端末１０のＣＰＵ１１は、Ｓ１４０で送信された画像データを取得すると、当該画像データに基づいて画像（例えば、図１２の画像Ｐ１１）を表示部１６に表示する（Ｓ１４２）。Ｓ１４２で表示される画像は、図１２の画像Ｐ１１のボタンｂ２１，ｂ２２に例示するように、予約ＩＤに対応した複数の進化予約の中からいずれかの進化予約をユーザが指定可能に構成されている。ユーザ端末１０のＣＰＵ１１は、予約ＩＤの指定結果を受け付けると（Ｓ１４４）、予約ＩＤの指定結果をゲームサーバ２０へ送信する（Ｓ１４６）。
予約ＩＤの数（ＮＵＭ）が１である場合には（ＮＵＭ＝１）、予約データテーブルの中で入手カードと同一のカードＩＤであって、かつユーザが未所持の参照カードが１つのみであるため、入手カードを対応付ける予約ＩＤが一意に決定される。
以上の処理によって、予約データテーブルにおいて、入手カードに対応するシリアル番号の書込み対象となる予約ＩＤおよび参照カードＩＤに対応する欄（図８のＣ１〜Ｃ５のいずれか）が決定されると、ゲームサーバ２０のＣＰＵ２１は、Ｓ１２８で発行された入手カードのシリアル番号を予約データテーブルに書き込むとともに（Ｓ１４８）、書き込んだシリアル番号に対応する予約ＩＤを読み出す。さらにＣＰＵ２１は、読み出した予約ＩＤを、所持カードデータテーブルにおいて入手カードのシリアル番号に対応付けて書き込む（Ｓ１５０）。
次にゲームサーバ２０は、Ｓ１４８で書き込んだシリアル番号に対応する予約ＩＤに対応する参照カードがすべて揃ったか否か判定する（Ｓ１５２）。具体的には、ゲームサーバ２０のＣＰＵ２１は、入手カードに対応する予約ＩＤに対応する進化ＩＤについての参照カードＩＤの組合せを構成するＣ１〜Ｃ５の欄（進化合成データテーブル参照）の参照カードＩＤに対応した、予約データテーブルにおける参照カードのＣ１〜Ｃ５のすべての欄に、シリアル番号が記録されているか判定することによって、参照カードがすべて揃ったか否か判定する。予約ＩＤに対応する参照カードがすべて揃っていない場合には（Ｓ１５２：ＮＯ）、入手カードによって参照カードの組合せ条件が満たされていないため、カード入手時の処理を終了する。一方、予約ＩＤに対応する参照カードがすべて揃った場合には（Ｓ１５２：ＹＥＳ）、予約ＩＤに対応する参照カードがすべて揃ったことをユーザに通知するための画像データを生成し（Ｓ１５４）、その画像データをユーザ端末１０へ送信する（Ｓ１５６）。ユーザ端末１０のＣＰＵ１１は、Ｓ１５６で送信された画像データを取得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ１５８）。
（Ｄ）進化合成処理（図１７）
例えば、上述したカード入手時の処理を実行した結果、入手したカードによって進化合成に必要な参照カードがすべて揃ったことで進化合成の条件を満たすことになった場合には、ユーザの所定の操作に基づいて進化合成処理が実行される。
図示しないが、ベースカードに対して進化合成に必要な参照カードがすべて揃った場合、例えば図１２の画像Ｐ１１に代えて、あるいは画像Ｐ１１に続いて、そのベースカードが進化合成可能になったことを示すテキスト、および、進化合成の実行要求を行うか否かを確認するためのボタンを含む画像が表示される（図１６ＢのＳ１５８の表示）。このボタンのユーザによる指定に基づいて、ユーザ端末１０のＣＰＵ１１が進化合成の実行要求を受け付けた場合（Ｓ１７０）、当該要求をゲームサーバ２０へ送信する（Ｓ１７２）。
例えば、上述したカード入手時の処理を実行した結果、入手したカードによって進化合成に必要な参照カードがすべて揃ったことで進化合成の条件を満たすことになった場合には、ユーザの所定の操作に基づいて進化合成処理が実行される。
図示しないが、ベースカードに対して進化合成に必要な参照カードがすべて揃った場合、例えば図１２の画像Ｐ１１に代えて、あるいは画像Ｐ１１に続いて、そのベースカードが進化合成可能になったことを示すテキスト、および、進化合成の実行要求を行うか否かを確認するためのボタンを含む画像が表示される（図１６ＢのＳ１５８の表示）。このボタンのユーザによる指定に基づいて、ユーザ端末１０のＣＰＵ１１が進化合成の実行要求を受け付けた場合（Ｓ１７０）、当該要求をゲームサーバ２０へ送信する（Ｓ１７２）。
ゲームサーバ２０のＣＰＵ２１がユーザ端末１０から受信した進化合成の実行要求を受け付けると、ゲームサーバ２０のＣＰＵ２１は、所持カードデータテーブルにおいて、進化前カード（つまり、進化合成のベースカード）のカードデータを消去し（Ｓ１７４）、進化後カードのカードデータを新たに書き込む（Ｓ１７６）。Ｓ１７６では、図１６ＢのＳ１５０の書込み対象となった予約ＩＤに対応して予約データテーブルに記録されている進化ＩＤに基づいて、進化合成データテーブルから進化後カードＩＤを読み出し、この進化後カードＩＤに対応するカードデータを所持カードデータテーブルに書き込む。このとき、カードデータには、例えば、進化後カードＩＤに対応して発行したシリアル番号が含まれる。
次いでゲームサーバ２０のＣＰＵ２１は、進化合成に使用する参照カードのカードデータを所持カードデータテーブルから消去する（Ｓ１７８）。
次いでゲームサーバ２０のＣＰＵ２１は、進化合成に使用する参照カードのカードデータを所持カードデータテーブルから消去する（Ｓ１７８）。
進化合成を実行した後は予約ＩＤに対応付けられたデータを予約データテーブルに記録している必要がないため、ゲームサーバ２０のＣＰＵ２１は、予約データテーブルから、進化合成の対象となる予約ＩＤの行のデータを消去する（Ｓ１８０）。最後にＣＰＵ２１は、進化後カードのカードデータを含む画像データを生成し（Ｓ１８２）、その画像データをユーザ端末１０へ送信する（Ｓ１８４）。ユーザ端末１０のＣＰＵ１１は、Ｓ１８４で送信された画像データを取得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ１８６）。
以上説明したように、本実施形態のゲームシステムでは、ベースカードに対する進化合成の実行は、複数のカードＩＤを含む組合せ条件に基づいて行われる。ユーザが所定の操作を行うことで、当該複数のカードＩＤによって特定される複数の参照カードに対して、目的とする進化合成とは異なる処理に用いられることを制限することの要求（上述した進化合成の予約処理の要求）が受け付け可能となっている。このような制限を行うことで、ベースカードに対応する組合せ条件を満たす前に、ユーザが誤って当該組合せ条件に対応する複数の参照カードのいずれかを目的とする進化合成以外の処理に使用してしまうことを防止するため、ベースカードの進化合成を実行するための基礎となるカードを保護することができる。
進化合成の予約処理の要求が受け付けられた場合には、要求に係るベースカードとユーザとが予約データテーブルにおいて対応付けられる。ユーザからの複数の上記要求を受け付けた場合には、各要求に係るベースカードに対応する組合せ条件に含まれる複数のカードＩＤの少なくとも１つが、複数の要求（つまり、複数の予約ＩＤ、若しくは複数のベースカード）の間で重複することがある。このとき、仮に何らの対処をしないとすれば、重複するカードＩＤによって特定されるカード（重複カード）は、２以上のベースカードについて進化合成の基礎となるため、ユーザが進化合成を優先的に処理することを希望するベースカードに対して、進化合成がユーザの意思に反して優先的に実行されない可能性がある。一方、本実施形態のゲームサーバ２０は、重複するカードＩＤを示す画像データを出力するように構成されているため、ユーザは、重複カードの存在を認識することができる。そのため、進化合成が優先的に実行されない可能性があることについてユーザに注意を促すことができる。
進化合成の予約処理の要求が受け付けられた場合には、要求に係るベースカードとユーザとが予約データテーブルにおいて対応付けられる。ユーザからの複数の上記要求を受け付けた場合には、各要求に係るベースカードに対応する組合せ条件に含まれる複数のカードＩＤの少なくとも１つが、複数の要求（つまり、複数の予約ＩＤ、若しくは複数のベースカード）の間で重複することがある。このとき、仮に何らの対処をしないとすれば、重複するカードＩＤによって特定されるカード（重複カード）は、２以上のベースカードについて進化合成の基礎となるため、ユーザが進化合成を優先的に処理することを希望するベースカードに対して、進化合成がユーザの意思に反して優先的に実行されない可能性がある。一方、本実施形態のゲームサーバ２０は、重複するカードＩＤを示す画像データを出力するように構成されているため、ユーザは、重複カードの存在を認識することができる。そのため、進化合成が優先的に実行されない可能性があることについてユーザに注意を促すことができる。
（２）第２の実施形態
第１の実施形態では、ユーザ端末１０とゲームサーバ２０との間でＨＴＴＰに従った通信が行われ、ユーザ端末１０がゲームサーバ２０から取得するＨＴＭＬ文書を解釈することでゲーム画像を表示する、いわゆるブラウザ形式によって本発明が実現される場合について説明したが、この場合に限られない。ユーザ端末１０がダウンロードしたゲームプログラムを実行することでユーザ端末１０が主体的にゲームの処理を実行し、ユーザ端末１０とゲームサーバ２０の間の送受信処理を抑制した、いわゆるネイティブアプリケーション形式によって実現してもよい。ネイティブアプリケーション形式では、ウェブブラウザを利用せずにユーザ端末１０内で画像データを生成して表示する。
第２の実施形態では、第１の実施形態のゲームをネイティブアプリケーション形式によって実現する場合の一例について説明する。なお、本実施形態のハードウェア構成は、第１の実施形態と同じ構成でよい。本実施形態のネイティブアプリケーションの形式では、処理のほとんどをユーザ端末１０側で行うことを想定しているが、以下で説明しないゲームの処理の一部（例えば、ユーザに抽選によって付与する抽選処理や、ゲーム運営者がユーザにカードを付与するプレゼント処理等）については、ゲームサーバ２０側で処理を実行し、ゲームサーバ２０による処理結果をユーザ端末１０へ送信するように構成してもよい。
本実施形態では、ユーザ端末１０が情報処理装置の一例となる。
第１の実施形態では、ユーザ端末１０とゲームサーバ２０との間でＨＴＴＰに従った通信が行われ、ユーザ端末１０がゲームサーバ２０から取得するＨＴＭＬ文書を解釈することでゲーム画像を表示する、いわゆるブラウザ形式によって本発明が実現される場合について説明したが、この場合に限られない。ユーザ端末１０がダウンロードしたゲームプログラムを実行することでユーザ端末１０が主体的にゲームの処理を実行し、ユーザ端末１０とゲームサーバ２０の間の送受信処理を抑制した、いわゆるネイティブアプリケーション形式によって実現してもよい。ネイティブアプリケーション形式では、ウェブブラウザを利用せずにユーザ端末１０内で画像データを生成して表示する。
第２の実施形態では、第１の実施形態のゲームをネイティブアプリケーション形式によって実現する場合の一例について説明する。なお、本実施形態のハードウェア構成は、第１の実施形態と同じ構成でよい。本実施形態のネイティブアプリケーションの形式では、処理のほとんどをユーザ端末１０側で行うことを想定しているが、以下で説明しないゲームの処理の一部（例えば、ユーザに抽選によって付与する抽選処理や、ゲーム運営者がユーザにカードを付与するプレゼント処理等）については、ゲームサーバ２０側で処理を実行し、ゲームサーバ２０による処理結果をユーザ端末１０へ送信するように構成してもよい。
本実施形態では、ユーザ端末１０が情報処理装置の一例となる。
本実施形態では、ユーザ端末１０がユーザによる所定の操作に基づいて、ゲーム運営者のサーバからゲームプログラムを受信し、受信したゲームプログラムがストレージ１８に格納される。ユーザ端末１０によってゲームが起動されると、ユーザ端末１０とゲームサーバ２０との間で通信が確立されてログイン処理が行われ、ゲームサーバ２０からユーザ端末１０へデータテーブル群（カードデータテーブル、進化合成データテーブル、所持カードデータテーブル）が送信される。ユーザ端末１０に送信されるデータテーブル群は、ユーザ端末１０のストレージ１８内に保持される。この場合、ストレージ１８内のデータテーブル群は、ログインの度に更新される。予約データテーブルは、ユーザ端末１０で生成されてストレージ１８に格納され、予約処理を実行する度に更新される。
所持カードデータテーブルがユーザ端末１０において改竄されることを防止するため、ユーザ端末１０による所定の処理が終了する度、あるいは、ゲームからログアウトする時点で、ユーザ端末１０内の所持カードデータテーブルがゲームサーバ２０へ送信される。ゲームサーバ２０では、受信した所持カードデータテーブルと、ストレージ２５内の所持カードデータテーブルとを比較し、データの改竄が行われていないか確認した後に、ストレージ２５内の所持カードデータテーブルを受信したものに更新する。
所持カードデータテーブルがユーザ端末１０において改竄されることを防止するため、ユーザ端末１０による所定の処理が終了する度、あるいは、ゲームからログアウトする時点で、ユーザ端末１０内の所持カードデータテーブルがゲームサーバ２０へ送信される。ゲームサーバ２０では、受信した所持カードデータテーブルと、ストレージ２５内の所持カードデータテーブルとを比較し、データの改竄が行われていないか確認した後に、ストレージ２５内の所持カードデータテーブルを受信したものに更新する。
図１８Ａおよび図１８Ｂは、本実施形態の進化合成の予約処理を示すシーケンスチャートである。図１８Ａおよび図１８Ｂの各図において、図１４Ａおよび図１４Ｂと同一の処理については、同一の符号を付してある。
本実施形態の進化合成の予約処理（図１８Ａおよび図１８Ｂ）では、例えばログイン時に、ゲームサーバ２０はユーザ端末１０へ、ストレージ２５内のデータテーブル群（カードデータテーブル、進化合成データテーブル、所持カードデータテーブル）を送信する（Ｓ８）。ユーザ端末１０のＣＰＵ１１は、受信したデータテーブル群をストレージ１８に記憶するとともに、操作入力部１５からの操作入力に基づいて、ＲＡＭ１３および表示部１６等と協働してＳ１４〜Ｓ５２の処理を実行する。ユーザ端末１０のＣＰＵ１１は、予約データテーブルを逐次更新して予約処理が終了した後に、予約データテーブルをストレージ１８へ格納する。Ｓ５０の処理が終了した後、あるいはログアウトの時点で、ユーザ端末１０のＣＰＵ１１は、所持カードデータテーブルをゲームサーバ２０へ送信する（Ｓ５４）。
本実施形態の進化合成の予約処理（図１８Ａおよび図１８Ｂ）では、例えばログイン時に、ゲームサーバ２０はユーザ端末１０へ、ストレージ２５内のデータテーブル群（カードデータテーブル、進化合成データテーブル、所持カードデータテーブル）を送信する（Ｓ８）。ユーザ端末１０のＣＰＵ１１は、受信したデータテーブル群をストレージ１８に記憶するとともに、操作入力部１５からの操作入力に基づいて、ＲＡＭ１３および表示部１６等と協働してＳ１４〜Ｓ５２の処理を実行する。ユーザ端末１０のＣＰＵ１１は、予約データテーブルを逐次更新して予約処理が終了した後に、予約データテーブルをストレージ１８へ格納する。Ｓ５０の処理が終了した後、あるいはログアウトの時点で、ユーザ端末１０のＣＰＵ１１は、所持カードデータテーブルをゲームサーバ２０へ送信する（Ｓ５４）。
なお、図示しないが、本実施形態では、カード入手時の処理、および、進化合成処理についても同様にして、ユーザ端末１０が主体的に実行する。
本実施形態では、カードデータテーブル、進化合成データテーブル、所持カードデータテーブルがゲームサーバ２０において保持され、予約データテーブルがユーザ端末１０において保持される場合について説明したが、この場合に限られない。ネイティブアプリケーション形式のゲームでは、各データテーブルの保持分担については適宜設定することが可能であって、ユーザ端末１０、ゲームサーバ２０、または、ユーザ端末１０若しくはゲームサーバ２０からアクセス可能な他の装置の少なくともいずれかに各データテーブルが保持されるようにすればよく、特定の保持態様に限定されるものではない。
本実施形態では、カードデータテーブル、進化合成データテーブル、所持カードデータテーブルがゲームサーバ２０において保持され、予約データテーブルがユーザ端末１０において保持される場合について説明したが、この場合に限られない。ネイティブアプリケーション形式のゲームでは、各データテーブルの保持分担については適宜設定することが可能であって、ユーザ端末１０、ゲームサーバ２０、または、ユーザ端末１０若しくはゲームサーバ２０からアクセス可能な他の装置の少なくともいずれかに各データテーブルが保持されるようにすればよく、特定の保持態様に限定されるものではない。
（３）変形例
以下、上述した各実施形態に共通の変形例について説明する。
以下、上述した各実施形態に共通の変形例について説明する。
（３−１）変形例１
上述した実施形態では、図１２および図１６Ａ，図１６Ｂを参照して、ユーザが複数の進化予約について重複する参照カード（重複カード）を入手したタイミングで、予約ＩＤまたは予約済みのベースカードを指定する機会を付与し、ユーザの指定操作（例えば、図１２のボタンｂ２１，ｂ２２のいずれかの指定操作）に基づいて、特定手段５８が予約ＩＤまたは予約済みのベースカードを特定する場合について説明したが、予約ＩＤまたは予約済みのベースカードを指定するタイミングは、この場合に限られない。
受付手段５１によって進化合成の予約処理の要求を受け付けるタイミング、または、ユーザの所望のタイミング（すなわち、予約済みの複数のベースカードの中からいずれかのベースカードを特定するためのユーザの任意の要求がなされるタイミング）において、予約ＩＤあるいは予約済みのベースカードを特定してもよい。前者の場合には、新たな進化合成の予約処理の要求の結果、複数の進化合成について重複カードが存在する状況が生ずる可能性があるため、予約ＩＤまたは予約済みのベースカードに対するユーザの指定を受け付けるのに好ましいタイミングである。
上述した実施形態では、図１２および図１６Ａ，図１６Ｂを参照して、ユーザが複数の進化予約について重複する参照カード（重複カード）を入手したタイミングで、予約ＩＤまたは予約済みのベースカードを指定する機会を付与し、ユーザの指定操作（例えば、図１２のボタンｂ２１，ｂ２２のいずれかの指定操作）に基づいて、特定手段５８が予約ＩＤまたは予約済みのベースカードを特定する場合について説明したが、予約ＩＤまたは予約済みのベースカードを指定するタイミングは、この場合に限られない。
受付手段５１によって進化合成の予約処理の要求を受け付けるタイミング、または、ユーザの所望のタイミング（すなわち、予約済みの複数のベースカードの中からいずれかのベースカードを特定するためのユーザの任意の要求がなされるタイミング）において、予約ＩＤあるいは予約済みのベースカードを特定してもよい。前者の場合には、新たな進化合成の予約処理の要求の結果、複数の進化合成について重複カードが存在する状況が生ずる可能性があるため、予約ＩＤまたは予約済みのベースカードに対するユーザの指定を受け付けるのに好ましいタイミングである。
（３−２）変形例２
上述した実施形態では、図１２の画像Ｐ１１に例示したように、ユーザの操作による指定対象となるボタンｂ２１，ｂ２２を設け、特定手段５８が、複数の進化予約について重複カードが存在する場合に、ユーザの直接的な指定操作に基づいて予約ＩＤ（対応付け情報の一例）またはベースカード（選択オブジェクトの一例）を特定する場合について説明した。かかるユーザの操作による直接的な指定方法は、ユーザの意思を直接的に反映させることができる点で好ましいが、この場合に限られない。
特定手段５８は、複数の進化予約について重複カードが存在する場合に、予め設定されている優先条件に従って予約ＩＤまたは予約済みのベースカードを特定してもよい。このように特定することで、いったん優先条件が設定されればユーザは、複数の進化予約について重複カードが存在する場合にその都度予約ＩＤまたは予約済みのベースカードを指定する操作を行う必要がないため、ユーザの操作が煩雑にならなくて済む。また、ゲームの内容に応じて優先条件が適切に設定されていれば、ユーザにとって適切な進化予約が特定される可能性が高くなる。優先条件は特に限定されるものではないが、例えば後述する変形例３で例示するものであってよい。
本変形例では、例えば図１２において、複数の進化予約で重複する参照カードを入手した場合には、画像Ｐ１１に代えて、優先条件に従ってゲームサーバ２０が決定した参照カードの進化予約先をユーザに通知する画像（図示せず）となる。
上述した実施形態では、図１２の画像Ｐ１１に例示したように、ユーザの操作による指定対象となるボタンｂ２１，ｂ２２を設け、特定手段５８が、複数の進化予約について重複カードが存在する場合に、ユーザの直接的な指定操作に基づいて予約ＩＤ（対応付け情報の一例）またはベースカード（選択オブジェクトの一例）を特定する場合について説明した。かかるユーザの操作による直接的な指定方法は、ユーザの意思を直接的に反映させることができる点で好ましいが、この場合に限られない。
特定手段５８は、複数の進化予約について重複カードが存在する場合に、予め設定されている優先条件に従って予約ＩＤまたは予約済みのベースカードを特定してもよい。このように特定することで、いったん優先条件が設定されればユーザは、複数の進化予約について重複カードが存在する場合にその都度予約ＩＤまたは予約済みのベースカードを指定する操作を行う必要がないため、ユーザの操作が煩雑にならなくて済む。また、ゲームの内容に応じて優先条件が適切に設定されていれば、ユーザにとって適切な進化予約が特定される可能性が高くなる。優先条件は特に限定されるものではないが、例えば後述する変形例３で例示するものであってよい。
本変形例では、例えば図１２において、複数の進化予約で重複する参照カードを入手した場合には、画像Ｐ１１に代えて、優先条件に従ってゲームサーバ２０が決定した参照カードの進化予約先をユーザに通知する画像（図示せず）となる。
（３−３）変形例３
複数の進化予約について重複カードが存在する場合に、優先条件に従って予約ＩＤまたは予約済みのベースカードを特定する場合、その優先条件の設定方法について、ユーザが選択可能となるように構成してもよい。それによって、ユーザの操作に基づいて優先条件が設定されるため、ユーザの上記優先条件に対する要望をユーザが自ら反映させることができるようになる。
本変形例では、受付手段５１は、ユーザによる操作に基づいて優先条件に関する指示を受け付ける。本変形例では、条件設定手段６０が設けられる（図１３参照）。
条件設定手段６０は、受付手段５１により受け付けられた指示に基づいて、優先条件を設定する機能を備える。優先条件の設定例について、図１９に示す。図１９は、複数の進化予約について重複カードが存在する場合に、ユーザに対して優先条件の設定方法を指定する操作を促すための画像Ｐ２０を示す。画像Ｐ２０は、重複カードが存在する複数の進化予約について現在の優先順を示す表示領域２０１と、優先条件の設定を変更するための４つのボタン、すなわち、ボタンｂ３１（「手動で設定」）、ボタンｂ３２（「未所持の参照カードが少ない順に設定」）、ボタンｂ３３（「未入手の参照カードが少ない順に設定」）、および、ボタンｂ３４（「ベースカードが強くなる順に設定」）が表示される。この例では、受付手段５１は、いずれかのボタンに対する指定結果を受け付ける。ユーザは、進化合成の成立し易さや、進化合成後のベースカードの強さ等を勘案しながら、いずれかの優先条件の設定方法を指定することができる。
複数の進化予約について重複カードが存在する場合に、優先条件に従って予約ＩＤまたは予約済みのベースカードを特定する場合、その優先条件の設定方法について、ユーザが選択可能となるように構成してもよい。それによって、ユーザの操作に基づいて優先条件が設定されるため、ユーザの上記優先条件に対する要望をユーザが自ら反映させることができるようになる。
本変形例では、受付手段５１は、ユーザによる操作に基づいて優先条件に関する指示を受け付ける。本変形例では、条件設定手段６０が設けられる（図１３参照）。
条件設定手段６０は、受付手段５１により受け付けられた指示に基づいて、優先条件を設定する機能を備える。優先条件の設定例について、図１９に示す。図１９は、複数の進化予約について重複カードが存在する場合に、ユーザに対して優先条件の設定方法を指定する操作を促すための画像Ｐ２０を示す。画像Ｐ２０は、重複カードが存在する複数の進化予約について現在の優先順を示す表示領域２０１と、優先条件の設定を変更するための４つのボタン、すなわち、ボタンｂ３１（「手動で設定」）、ボタンｂ３２（「未所持の参照カードが少ない順に設定」）、ボタンｂ３３（「未入手の参照カードが少ない順に設定」）、および、ボタンｂ３４（「ベースカードが強くなる順に設定」）が表示される。この例では、受付手段５１は、いずれかのボタンに対する指定結果を受け付ける。ユーザは、進化合成の成立し易さや、進化合成後のベースカードの強さ等を勘案しながら、いずれかの優先条件の設定方法を指定することができる。
次に、本変形例において、重複カードが存在する複数の進化予約について現在の優先順を変更する処理を、図２０のフローチャートを参照して説明する。
図２０において先ず、ユーザ端末１０のＣＰＵ１１は、ユーザの所定の操作に基づいて、優先条件設定要求を受け付ける（Ｓ２００）。優先条件設定要求を行うタイミングは特に限定されるものではないが、メインメニューに対する所定の操作であってもよいし、新たな進化予約を実行したタイミングであってもよい。
ゲームサーバ２０は、ユーザ端末１０から優先条件設定要求を受信する（Ｓ２０２）。ゲームサーバ２０のＣＰＵ２１は、当該要求を受け付けると、予約データテーブルおよび進化合成データテーブルを参照して、参照カードＩＤが重複する２以上の予約ＩＤがあるか否か判定する（Ｓ２０４）。すなわち、２以上の予約ＩＤにおいて複数のカードＩＤの少なくとも１つが重複するか否か判定する。具体的にはＣＰＵ２１は先ず、ユーザの予約データテーブルの各予約ＩＤの進化前カードのシリアル番号に対応するカードＩＤに対応した複数の参照カードのカードＩＤを進化合成データテーブルから読み出し、異なる予約ＩＤの間で同一のカードＩＤの参照カードが存在するか否かを判定する。
そして参照カードＩＤが重複する２以上の予約ＩＤがない場合には（Ｓ２０４：ＮＯ）、優先順について考慮する必要がないため、例えば、重複カードが存在する複数の進化予約がないことを通知する画像データを生成する（Ｓ２２２）。
図２０において先ず、ユーザ端末１０のＣＰＵ１１は、ユーザの所定の操作に基づいて、優先条件設定要求を受け付ける（Ｓ２００）。優先条件設定要求を行うタイミングは特に限定されるものではないが、メインメニューに対する所定の操作であってもよいし、新たな進化予約を実行したタイミングであってもよい。
ゲームサーバ２０は、ユーザ端末１０から優先条件設定要求を受信する（Ｓ２０２）。ゲームサーバ２０のＣＰＵ２１は、当該要求を受け付けると、予約データテーブルおよび進化合成データテーブルを参照して、参照カードＩＤが重複する２以上の予約ＩＤがあるか否か判定する（Ｓ２０４）。すなわち、２以上の予約ＩＤにおいて複数のカードＩＤの少なくとも１つが重複するか否か判定する。具体的にはＣＰＵ２１は先ず、ユーザの予約データテーブルの各予約ＩＤの進化前カードのシリアル番号に対応するカードＩＤに対応した複数の参照カードのカードＩＤを進化合成データテーブルから読み出し、異なる予約ＩＤの間で同一のカードＩＤの参照カードが存在するか否かを判定する。
そして参照カードＩＤが重複する２以上の予約ＩＤがない場合には（Ｓ２０４：ＮＯ）、優先順について考慮する必要がないため、例えば、重複カードが存在する複数の進化予約がないことを通知する画像データを生成する（Ｓ２２２）。
一方、参照カードＩＤが重複する２以上の予約ＩＤがある場合には（Ｓ２０４：ＹＥＳ）、ＣＰＵ２１は、重複する参照カードＩＤごとに、すべての予約ＩＤのデータを予約データテーブルから読み出し（Ｓ２０６）、画像データを生成する（Ｓ２０８）。Ｓ２０８では、複数の予約データテーブルの優先順のデータに基づいて画像データが生成される。ＣＰＵ２１は、Ｓ２０８で生成した画像データをユーザ端末１０へ送信する（Ｓ２１０）。ユーザ端末１０のＣＰＵ１１は、Ｓ２１０で送信された画像データを取得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ２１２）。Ｓ２１２で表示される画像の一例が図１９の画像Ｐ２０である。
ユーザ端末１０のＣＰＵ１１は、優先条件設定方法のユーザによる指定（例えば、図１９の画像Ｐ２０のボタンｂ３１〜ｂ３４のいずれかのボタンに対する指定）を受け付けると、ユーザによって指定された優先条件設定方法を示すデータをゲームサーバ２０へ送信する（Ｓ２１６）。ゲームサーバ２０のＣＰＵ２１は、ユーザによって指定された優先条件設定方法を認識すると、その優先条件設定方法に従って優先順決定処理を実行する（Ｓ２１８）。Ｓ２１８の優先順決定処理の詳細なフローの一例を図２１に示す。ＣＰＵ２１は、優先順決定処理を実行することで複数の進化予約に対する優先順を決定し、決定した優先順に基づいて画像データを生成する。ここで生成される画像データは、例えば、図１９の画像Ｐ２０の表示領域２０１に表示される各進化予約の優先順が、Ｓ２１８で決定した優先順が反映されたものとなる。
ゲームサーバ２０のＣＰＵ２１は、Ｓ２２２またはＳ２２０で生成した画像データを、ユーザ端末１０へ送信する（Ｓ２２４）。ユーザ端末１０のＣＰＵ１１は、Ｓ２２４で送信された画像データを取得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ２２６）。
ゲームサーバ２０のＣＰＵ２１は、Ｓ２２２またはＳ２２０で生成した画像データを、ユーザ端末１０へ送信する（Ｓ２２４）。ユーザ端末１０のＣＰＵ１１は、Ｓ２２４で送信された画像データを取得すると、当該画像データに基づいて画像を表示部１６に表示する（Ｓ２２６）。
次に、優先順決定処理（図２０のＳ２１８）の一例について、図２１を参照して説明する。
図２１に示す優先順決定処理は、図２０のＳ２１６でユーザによって指定された優先条件設定方法が「未所持の参照カードが少ない順に設定」である場合の一例である。
ゲームサーバ２０のＣＰＵ２１は先ず、Ｓ２０６において重複する参照カードＩＤごとに読み出されたすべての予約ＩＤの各々を対象として、Ｓ３００〜Ｓ３０４の一連の処理を実行する。すなわち、処理対象の予約ＩＤに対応する進化ＩＤを予約データテーブルから読み出す（Ｓ３００）。Ｓ３００で読み出した進化ＩＤに対応する参照カードＩＤの組合せ条件に含まれるすべての参照カードＩＤをすべて、進化合成データテーブルから読み出す（Ｓ３０２）。そして、Ｓ３０２で読み出された参照カードＩＤによって特定される参照カードのうち、ユーザが所持していない参照カードの数（ＮＵＭ）をカウントする（Ｓ３０４）。Ｓ３００〜Ｓ３０６の処理をすべての予約ＩＤについて繰り返すことによって、各予約ＩＤに対して、ユーザが未所持の参照カードの数が得られる。
ＣＰＵ２１は、すべての予約ＩＤの処理が終了すると（Ｓ３０６：ＹＥＳ）、予約ＩＤごとの、ユーザが所持していない参照カードの数（ＮＵＭ）に基づいて、数が少ない順に予約ＩＤごとの優先順を決定する（Ｓ３０８）。最後に、Ｓ３０８で得られた各予約ＩＤの優先順に従って、予約データテーブルの「優先順」の欄の優先順の値を書き込むことで、予約データテーブルを更新する（Ｓ３１０）。以上が、優先条件設定方法が「未所持の参照カードが少ない順に設定」である場合の優先順決定処理のフローである。
本変形例では、複数の進化予約で重複する参照カードを入手した場合には、予約データテーブルの優先順のデータに基づいて、入手カードを対応付ける予約ＩＤが決定される。
図２１に示す優先順決定処理は、図２０のＳ２１６でユーザによって指定された優先条件設定方法が「未所持の参照カードが少ない順に設定」である場合の一例である。
ゲームサーバ２０のＣＰＵ２１は先ず、Ｓ２０６において重複する参照カードＩＤごとに読み出されたすべての予約ＩＤの各々を対象として、Ｓ３００〜Ｓ３０４の一連の処理を実行する。すなわち、処理対象の予約ＩＤに対応する進化ＩＤを予約データテーブルから読み出す（Ｓ３００）。Ｓ３００で読み出した進化ＩＤに対応する参照カードＩＤの組合せ条件に含まれるすべての参照カードＩＤをすべて、進化合成データテーブルから読み出す（Ｓ３０２）。そして、Ｓ３０２で読み出された参照カードＩＤによって特定される参照カードのうち、ユーザが所持していない参照カードの数（ＮＵＭ）をカウントする（Ｓ３０４）。Ｓ３００〜Ｓ３０６の処理をすべての予約ＩＤについて繰り返すことによって、各予約ＩＤに対して、ユーザが未所持の参照カードの数が得られる。
ＣＰＵ２１は、すべての予約ＩＤの処理が終了すると（Ｓ３０６：ＹＥＳ）、予約ＩＤごとの、ユーザが所持していない参照カードの数（ＮＵＭ）に基づいて、数が少ない順に予約ＩＤごとの優先順を決定する（Ｓ３０８）。最後に、Ｓ３０８で得られた各予約ＩＤの優先順に従って、予約データテーブルの「優先順」の欄の優先順の値を書き込むことで、予約データテーブルを更新する（Ｓ３１０）。以上が、優先条件設定方法が「未所持の参照カードが少ない順に設定」である場合の優先順決定処理のフローである。
本変形例では、複数の進化予約で重複する参照カードを入手した場合には、予約データテーブルの優先順のデータに基づいて、入手カードを対応付ける予約ＩＤが決定される。
図２０のＳ２１６でユーザによって指定された優先条件設定方法が「未入手の参照カードが少ない順に設定」や「ベースカードが強くなる順に設定」の場合についても、すべての予約ＩＤの各々に対して、比較可能な数値情報を取得することで、予約ＩＤの優先順を決定することができる。
例えば、ユーザによって指定された優先条件設定方法が「未入手の参照カードが少ない順に設定」の場合、カードデータテーブルのカードＩＤごとにユーザが入手したことがあるか否かを示すフラグ（１：「入手」、０：「未入手」）を設定しておく。そして、各予約ＩＤに対応する参照カードＩＤについてフラグが「０」である参照カードＩＤの数をカウントする。そして、カウント値が少ない予約ＩＤの順に従って予約ＩＤの優先順が決定される。
ユーザによって指定された優先条件設定方法が「ベースカードが強くなる順に設定」の場合、各予約ＩＤに対応する進化ＩＤを特定し、特定した進化ＩＤに対応する進化後カードＩＤを、進化合成データテーブルを参照して特定する。そして、進化後カードＩＤのパラメータ（例えば、攻撃力等）をカードデータテーブルから読み出すことで、パラメータの大きい順に予約ＩＤの優先順が決定される。
また、ユーザによって指定された優先条件設定方法が「手動で設定」の場合には、各進化予約に対付けて優先順をユーザがプルダウンメニューを操作して指定可能な画像を、ユーザに提示してもよい。
例えば、ユーザによって指定された優先条件設定方法が「未入手の参照カードが少ない順に設定」の場合、カードデータテーブルのカードＩＤごとにユーザが入手したことがあるか否かを示すフラグ（１：「入手」、０：「未入手」）を設定しておく。そして、各予約ＩＤに対応する参照カードＩＤについてフラグが「０」である参照カードＩＤの数をカウントする。そして、カウント値が少ない予約ＩＤの順に従って予約ＩＤの優先順が決定される。
ユーザによって指定された優先条件設定方法が「ベースカードが強くなる順に設定」の場合、各予約ＩＤに対応する進化ＩＤを特定し、特定した進化ＩＤに対応する進化後カードＩＤを、進化合成データテーブルを参照して特定する。そして、進化後カードＩＤのパラメータ（例えば、攻撃力等）をカードデータテーブルから読み出すことで、パラメータの大きい順に予約ＩＤの優先順が決定される。
また、ユーザによって指定された優先条件設定方法が「手動で設定」の場合には、各進化予約に対付けて優先順をユーザがプルダウンメニューを操作して指定可能な画像を、ユーザに提示してもよい。
なお、図１９では、優先条件の設定方法として、ユーザの指示入力によって設定する（つまり、手動で設定する）方法、未所持の参照カードが少ない順に設定する方法、未入手の参照カードが少ない順に設定する方法、および、ベースカードが強くなる順に設定する方法の例を挙げたが、これらの例に限られない。
優先条件は、所持情報に関連する条件であってもよく、上述した未所持の参照カードの数のほか、未所持の参照カードの数の、組合せ条件に含まれる参照カードの数に対する割合等に関する条件であってもよい。
優先条件は、履歴情報に関連する条件であってもよく、上記未入手の参照カードの数のほか、未入手の参照カードの数の、組合せ条件に含まれる参照カードの数に対する割合や、参照カードの入手回数に関する条件であってもよい。
優先条件は、ベースカードの如何なるパラメータに関する条件であってもよく、特定のパラメータに限定されない。例えば、ベースカードのレベル、レアリティ、ＨＰ、攻撃力、防御力等のいずれかのパラメータに関する条件であってもよい。
優先条件は、所持情報に関連する条件であってもよく、上述した未所持の参照カードの数のほか、未所持の参照カードの数の、組合せ条件に含まれる参照カードの数に対する割合等に関する条件であってもよい。
優先条件は、履歴情報に関連する条件であってもよく、上記未入手の参照カードの数のほか、未入手の参照カードの数の、組合せ条件に含まれる参照カードの数に対する割合や、参照カードの入手回数に関する条件であってもよい。
優先条件は、ベースカードの如何なるパラメータに関する条件であってもよく、特定のパラメータに限定されない。例えば、ベースカードのレベル、レアリティ、ＨＰ、攻撃力、防御力等のいずれかのパラメータに関する条件であってもよい。
（４）ゲーム以外のアプリケーションへの適用について
上述した実施形態および変形例では、本発明がゲームに適用される場合について説明したが、他のアプリケーションに適用してもよい。例えばインターネット上のショッピングモールで商品を購入する度に複数種類の電子クーポン券を配布している場合、その電子クーポン券を本発明のオブジェクトの一例としてもよい。この場合、例えばベースクーポン券としてのクーポン券Ｑの特典内容をアップグレード（変更処理の一例）するために、クーポン券Ｑに対応する参照クーポン券としてのクーポン券Ａ〜Ｃをユーザが所持し利用することが考えられる。この例において、クーポン券Ｑをアップグレードすること目的として、そのために必要なクーポン券Ａ〜Ｃのいずれかのシリアル番号を予約データテーブルに書き込む。そして、予約データテーブルに記録されているクーポン券は、クーポン券Ｑをアップグレードする処理以外の処理に用いられることが制限される。
その場合に、複数の予約ＩＤに対して参照クーポン券が重複する場合には、当該クーポン券が重複することをユーザに通知するための画像データを、例えばショッピングサーバがユーザ端末に送信するようにしてもよい。また、重複する参照クーポン券をいずれの予約ＩＤに対応付けるかについて、ユーザの操作に基づいて決定される。
上述した例示以外の他のアプリケーションについても適宜適用可能である。
上述した実施形態および変形例では、本発明がゲームに適用される場合について説明したが、他のアプリケーションに適用してもよい。例えばインターネット上のショッピングモールで商品を購入する度に複数種類の電子クーポン券を配布している場合、その電子クーポン券を本発明のオブジェクトの一例としてもよい。この場合、例えばベースクーポン券としてのクーポン券Ｑの特典内容をアップグレード（変更処理の一例）するために、クーポン券Ｑに対応する参照クーポン券としてのクーポン券Ａ〜Ｃをユーザが所持し利用することが考えられる。この例において、クーポン券Ｑをアップグレードすること目的として、そのために必要なクーポン券Ａ〜Ｃのいずれかのシリアル番号を予約データテーブルに書き込む。そして、予約データテーブルに記録されているクーポン券は、クーポン券Ｑをアップグレードする処理以外の処理に用いられることが制限される。
その場合に、複数の予約ＩＤに対して参照クーポン券が重複する場合には、当該クーポン券が重複することをユーザに通知するための画像データを、例えばショッピングサーバがユーザ端末に送信するようにしてもよい。また、重複する参照クーポン券をいずれの予約ＩＤに対応付けるかについて、ユーザの操作に基づいて決定される。
上述した例示以外の他のアプリケーションについても適宜適用可能である。
以上、本発明の実施形態、変形例について詳細に説明したが、本発明は上記実施形態等に限定されない。また、実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態および各変形例に記載された技術的事項は適宜組合せて適用してもよい。
なお、要求の受付方法については上述した場合に限られない。例えば、要求の受付方法は、加速度センサを備えたユーザ端末を振ることによる指示入力、あるいはジェスチャによる指示入力（ジェスチャ入力）によって受け付ける方法であってもよい。ジェスチャ入力では、撮像機能を備えたユーザ端末に対する所定のジェスチャを行うことでユーザ端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能なユーザ端末の場合には、要求の受付方法は、所定の音声による指示入力によって受け付ける方法であってもよい。
なお、要求の受付方法については上述した場合に限られない。例えば、要求の受付方法は、加速度センサを備えたユーザ端末を振ることによる指示入力、あるいはジェスチャによる指示入力（ジェスチャ入力）によって受け付ける方法であってもよい。ジェスチャ入力では、撮像機能を備えたユーザ端末に対する所定のジェスチャを行うことでユーザ端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能なユーザ端末の場合には、要求の受付方法は、所定の音声による指示入力によって受け付ける方法であってもよい。
［発明のまとめ］
以上の記載から本発明は例えば以下のように把握される。
以上の記載から本発明は例えば以下のように把握される。
本発明の一態様は、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置（２５）にアクセス可能な情報処理装置（１０または２０）において、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段（５１）と、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段（５７）と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段（５６）と、
を備えた情報処理装置である。
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段（５１）と、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段（５７）と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段（５６）と、
を備えた情報処理装置である。
「情報処理装置」は、スタンドアローンのゲーム機、あるいはユーザ端末（例えば、携帯端末やパーソナルコンピュータ等）やネットワーク上のサーバなどであってもよい。ゲームの実現形態によって適宜情報処理装置の実体を定義することができる。例えば、ユーザがゲーム機やユーザ端末を操作することで情報処理装置の各部の機能が実現される場合には、ゲーム機やユーザ端末が本発明の情報処理装置に相当する。あるいは、クライアントであるユーザ端末がユーザからの操作入力の受付や画像の表示の機能を有し、情報処理装置の各部の機能が実質的にユーザ端末と通信可能なサーバによって実現される場合には、サーバが本発明の情報処理装置に相当する。
「オブジェクト」は、ユーザが視覚的に認識可能である限り如何なる表示対象であってもよく、本発明の情報処理装置による処理内容に応じて適宜設定することができる。例えば、本発明の情報処理装置がゲームに関する情報を処理する場合、オブジェクトは、ゲーム上のキャラクタやアイテム等を含んでもよい。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
「オブジェクト識別情報」は、オブジェクトをユーザが識別可能となる識別情報、および、当該識別情報と関連付けられた情報である。オブジェクトをユーザが識別可能となる識別情報は、例えば、オブジェクト名やオブジェクト画像等である。オブジェクト名やオブジェクト画像と関連付けられた情報として、オブジェクトＩＤ（例えば、オブジェクトがカードの場合には、カードＩＤ）等も「オブジェクト識別情報」の一例である。
「記憶装置」は、例えばフラッシュメモリやＨＤＤ(Hard Disk Drive)等、如何なる構成のメモリデバイスであってもよい。また、記憶装置は、情報処理装置に内蔵されたものであってもよいし、情報処理装置から有線または無線でアクセス可能に構成された外部の装置であってもよい。
「オブジェクトを変化させる処理とは異なる処理に用いられることを制限する」とは、選択オブジェクトを変化させる処理以外の処理自体が禁止されることに限られず、選択オブジェクトを変化させる処理は実行可能であるが、その処理の実行の手続きをし難くする、あるいは処理の実行手続きを煩雑にすることであってもよい。なお、上述した実施形態の例では、オブジェクトを変化させる処理とは異なる処理に用いられることの制限は、当該オブジェクトの予約によって実現される。例えば上記実施形態では、「予約済カード」は、カードを目的とする進化予約とは異なる処理に用いられることが制限される。
以下の説明において、オブジェクトの「所持」とは、ユーザが当該オブジェクトを、当該オブジェクトを用いた処理に利用可能な状態にあることをいう。オブジェクトの「未所持」とは、ユーザが当該オブジェクトを、当該オブジェクトを用いた処理に利用不可能な状態にあることをいう。オブジェクトの「入手」とは、当該オブジェクトに対して未所持の状態から所持の状態に移行したことをいう。
「オブジェクト」は、ユーザが視覚的に認識可能である限り如何なる表示対象であってもよく、本発明の情報処理装置による処理内容に応じて適宜設定することができる。例えば、本発明の情報処理装置がゲームに関する情報を処理する場合、オブジェクトは、ゲーム上のキャラクタやアイテム等を含んでもよい。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
「オブジェクト識別情報」は、オブジェクトをユーザが識別可能となる識別情報、および、当該識別情報と関連付けられた情報である。オブジェクトをユーザが識別可能となる識別情報は、例えば、オブジェクト名やオブジェクト画像等である。オブジェクト名やオブジェクト画像と関連付けられた情報として、オブジェクトＩＤ（例えば、オブジェクトがカードの場合には、カードＩＤ）等も「オブジェクト識別情報」の一例である。
「記憶装置」は、例えばフラッシュメモリやＨＤＤ(Hard Disk Drive)等、如何なる構成のメモリデバイスであってもよい。また、記憶装置は、情報処理装置に内蔵されたものであってもよいし、情報処理装置から有線または無線でアクセス可能に構成された外部の装置であってもよい。
「オブジェクトを変化させる処理とは異なる処理に用いられることを制限する」とは、選択オブジェクトを変化させる処理以外の処理自体が禁止されることに限られず、選択オブジェクトを変化させる処理は実行可能であるが、その処理の実行の手続きをし難くする、あるいは処理の実行手続きを煩雑にすることであってもよい。なお、上述した実施形態の例では、オブジェクトを変化させる処理とは異なる処理に用いられることの制限は、当該オブジェクトの予約によって実現される。例えば上記実施形態では、「予約済カード」は、カードを目的とする進化予約とは異なる処理に用いられることが制限される。
以下の説明において、オブジェクトの「所持」とは、ユーザが当該オブジェクトを、当該オブジェクトを用いた処理に利用可能な状態にあることをいう。オブジェクトの「未所持」とは、ユーザが当該オブジェクトを、当該オブジェクトを用いた処理に利用不可能な状態にあることをいう。オブジェクトの「入手」とは、当該オブジェクトに対して未所持の状態から所持の状態に移行したことをいう。
上記情報処理装置において、選択オブジェクトを対象としたオブジェクトを変化させる処理（以下、適宜「変化処理」ともいう。）の実行は、複数のオブジェクト識別情報を含む変化条件に基づいて行われる。ユーザが所定の操作を行うことで、当該複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、変化処理とは異なる処理に用いられることを制限することの要求を受け付けるように構成されている。このような制限を行うことで、選択オブジェクトに対応する変化条件を満たす前に、ユーザが誤って、変化条件に対応する複数のオブジェクトのいずれかを選択オブジェクトに対する変化処理以外の処理に使用してしまうことを防止するため、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトを保護することができる。
上記要求が受け付けられた場合には、要求に係る選択オブジェクトとユーザとが対応付けられる。ユーザからの複数の上記要求を受け付けた場合には、各要求に係る選択オブジェクトに対応する変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが、複数の要求の間で（つまり、複数の選択オブジェクトについて）重複することがある。このとき、仮に何らの対処をしないとすれば、重複するオブジェクト識別情報によって特定されるオブジェクト（重複オブジェクト）は、２以上の選択オブジェクトについてオブジェクトを変化させる処理の基礎となるため、ユーザが変化処理を優先的に処理することを希望する選択オブジェクトに対して、変化処理がユーザの意思に反して優先的に実行されない可能性がある。一方、上記情報処理装置は、重複するオブジェクト識別情報を示す出力データを出力するように構成されているため、ユーザは、重複オブジェクトの存在を認識することができる。そのため、変化処理が優先的に実行されない可能性があることについてユーザに注意を促すことができる。
上記要求が受け付けられた場合には、要求に係る選択オブジェクトとユーザとが対応付けられる。ユーザからの複数の上記要求を受け付けた場合には、各要求に係る選択オブジェクトに対応する変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが、複数の要求の間で（つまり、複数の選択オブジェクトについて）重複することがある。このとき、仮に何らの対処をしないとすれば、重複するオブジェクト識別情報によって特定されるオブジェクト（重複オブジェクト）は、２以上の選択オブジェクトについてオブジェクトを変化させる処理の基礎となるため、ユーザが変化処理を優先的に処理することを希望する選択オブジェクトに対して、変化処理がユーザの意思に反して優先的に実行されない可能性がある。一方、上記情報処理装置は、重複するオブジェクト識別情報を示す出力データを出力するように構成されているため、ユーザは、重複オブジェクトの存在を認識することができる。そのため、変化処理が優先的に実行されない可能性があることについてユーザに注意を促すことができる。
前記対応付け手段（５７）は、選択オブジェクトと前記ユーザとの対応付けを対応付け情報と関連付け、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記ユーザによる操作に基づいて、前記複数の選択オブジェクトのいずれかと関連付けられた対応付け情報を特定する第１特定手段（５８）と、
前記第１特定手段（５８）によって特定された対応付け情報と関連付けられた選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定されるオブジェクトが、前記ユーザが所持する所持オブジェクトである場合、当該所持オブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段（５９）と、
をさらに備えてもよい。
ここで、「対応付け情報」は、ユーザからの各要求を受け付ける度に行われる、対応付け手段（５７）による選択オブジェクトとユーザと対応付けを特定する情報である。対応付け情報によって、要求、選択オブジェクトおよびユーザが一意に特定される。
「所持オブジェクト」とは、情報処理上でユーザが所持するオブジェクトとして管理されているオブジェクトであって、ユーザに対応付けて記憶あるいは管理されているオブジェクトを意味する。
この構成では、ユーザの操作に基づいて、オブジェクト識別情報が重複する複数の選択オブジェクトについて、いずれかの選択オブジェクトに関連付けられた対応付け情報が特定される。すなわち、重複オブジェクトが存在する場合であっても、変化処理を優先的に処理する選択オブジェクトをユーザが自ら指定することができる。
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記ユーザによる操作に基づいて、前記複数の選択オブジェクトのいずれかと関連付けられた対応付け情報を特定する第１特定手段（５８）と、
前記第１特定手段（５８）によって特定された対応付け情報と関連付けられた選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定されるオブジェクトが、前記ユーザが所持する所持オブジェクトである場合、当該所持オブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段（５９）と、
をさらに備えてもよい。
ここで、「対応付け情報」は、ユーザからの各要求を受け付ける度に行われる、対応付け手段（５７）による選択オブジェクトとユーザと対応付けを特定する情報である。対応付け情報によって、要求、選択オブジェクトおよびユーザが一意に特定される。
「所持オブジェクト」とは、情報処理上でユーザが所持するオブジェクトとして管理されているオブジェクトであって、ユーザに対応付けて記憶あるいは管理されているオブジェクトを意味する。
この構成では、ユーザの操作に基づいて、オブジェクト識別情報が重複する複数の選択オブジェクトについて、いずれかの選択オブジェクトに関連付けられた対応付け情報が特定される。すなわち、重複オブジェクトが存在する場合であっても、変化処理を優先的に処理する選択オブジェクトをユーザが自ら指定することができる。
前記第１特定手段（５８）は、前記受付手段（５１）によって前記要求を受け付けるタイミング、前記ユーザが前記重複するオブジェクト識別情報によって特定されるオブジェクトを入手したタイミング、または、前記複数の選択オブジェクトの中からいずれかの選択オブジェクトを特定するための前記ユーザの要求を受け付けるタイミングにおいて、対応付け情報を特定してもよい。
これらのいずれかのタイミングに対応付け情報を特定することで、対応付け情報の指定に対するユーザ操作を好適に受け入れることができる。例えば、ユーザが重複オブジェクトを入手したタイミングは、その入手したオブジェクトによって、オブジェクト識別情報が重複する複数の選択オブジェクトのいずれかの選択のオブジェクトに対応する変化条件が成立する可能性があることから、対応付け情報の指定に対するユーザ操作を受け入れるのに適切なタイミングである。
これらのいずれかのタイミングに対応付け情報を特定することで、対応付け情報の指定に対するユーザ操作を好適に受け入れることができる。例えば、ユーザが重複オブジェクトを入手したタイミングは、その入手したオブジェクトによって、オブジェクト識別情報が重複する複数の選択オブジェクトのいずれかの選択のオブジェクトに対応する変化条件が成立する可能性があることから、対応付け情報の指定に対するユーザ操作を受け入れるのに適切なタイミングである。
前記第１特定手段（５８）は、前記ユーザの操作によって指定される対応付け情報を特定してもよい。
すなわち、対応付け情報の１つの特定方法として、ユーザの操作によって直接的に対応付け情報を指定する方法を採ることができる。それによって、対応付け情報の指定に対するユーザの意思を直接的に反映させることができる。
すなわち、対応付け情報の１つの特定方法として、ユーザの操作によって直接的に対応付け情報を指定する方法を採ることができる。それによって、対応付け情報の指定に対するユーザの意思を直接的に反映させることができる。
前記第１特定手段（５８）は、予め設定されている優先条件に従って対応付け情報を特定してもよい。
対応付け情報の他の特定方法として、予め設定されている優先条件に従って間接的に対応付け情報を特定する方法を採ることができる。この構成では、いったん優先条件が設定されればユーザは対応付け情報を都度指定する必要がないため、ユーザの操作が煩雑にならなくて済む。また、ゲームの内容に応じて優先条件が適切に設定されていれば、ユーザにとって適切な対応付け情報が特定される可能性が高い。
対応付け情報の他の特定方法として、予め設定されている優先条件に従って間接的に対応付け情報を特定する方法を採ることができる。この構成では、いったん優先条件が設定されればユーザは対応付け情報を都度指定する必要がないため、ユーザの操作が煩雑にならなくて済む。また、ゲームの内容に応じて優先条件が適切に設定されていれば、ユーザにとって適切な対応付け情報が特定される可能性が高い。
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記ユーザによる操作に基づいて、前記複数の選択オブジェクトのいずれかを特定する第２特定手段（５８）と、
前記第２特定手段（５８）によって特定された選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定されるオブジェクトが、前記ユーザが所持する所持オブジェクトである場合、当該所持オブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段（５９）と、
をさらに備えてもよい。
この構成では、ユーザの操作に基づいて、オブジェクト識別情報が重複する複数の選択オブジェクトについて、いずれかの選択オブジェクトが特定される。すなわち、重複オブジェクトが存在する場合であっても、変化処理を優先的に処理する選択オブジェクトをユーザが自ら指定することができる。
前記第２特定手段（５８）によって特定された選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定されるオブジェクトが、前記ユーザが所持する所持オブジェクトである場合、当該所持オブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段（５９）と、
をさらに備えてもよい。
この構成では、ユーザの操作に基づいて、オブジェクト識別情報が重複する複数の選択オブジェクトについて、いずれかの選択オブジェクトが特定される。すなわち、重複オブジェクトが存在する場合であっても、変化処理を優先的に処理する選択オブジェクトをユーザが自ら指定することができる。
前記第２特定手段（５８）は、前記受付手段（５１）によって前記要求を受け付けるタイミング、前記ユーザが前記重複するオブジェクト識別情報によって特定されるオブジェクトを入手したタイミング、または、前記複数の選択オブジェクトの中からいずれかの選択オブジェクトを特定するための前記ユーザの要求を受け付けるタイミングにおいて、選択オブジェクトを特定してもよい。
これらのいずれかのタイミングに選択オブジェクトを特定することで、選択オブジェクトの指定に対するユーザ操作を好適に受け入れることができる。例えば、ユーザが重複オブジェクトを入手したタイミングは、その入手したオブジェクトによって、オブジェクト識別情報が重複する複数の選択オブジェクトのいずれかの選択のオブジェクトに対応する変化条件が成立する可能性があることから、選択オブジェクトの指定に対するユーザ操作を受け入れるのに適切なタイミングである。
これらのいずれかのタイミングに選択オブジェクトを特定することで、選択オブジェクトの指定に対するユーザ操作を好適に受け入れることができる。例えば、ユーザが重複オブジェクトを入手したタイミングは、その入手したオブジェクトによって、オブジェクト識別情報が重複する複数の選択オブジェクトのいずれかの選択のオブジェクトに対応する変化条件が成立する可能性があることから、選択オブジェクトの指定に対するユーザ操作を受け入れるのに適切なタイミングである。
前記第２特定手段（５８）は、前記ユーザの操作によって指定される選択オブジェクトを特定してもよい。
すなわち、選択オブジェクトの１つの特定方法として、ユーザの操作によって直接的に対応付け情報を指定する方法を採ることができる。それによって、選択オブジェクトの指定に対するユーザの意思を直接的に反映させることができる。
すなわち、選択オブジェクトの１つの特定方法として、ユーザの操作によって直接的に対応付け情報を指定する方法を採ることができる。それによって、選択オブジェクトの指定に対するユーザの意思を直接的に反映させることができる。
前記第２特定手段（５８）は、予め設定されている優先条件に従って選択オブジェクトを特定してもよい。
選択オブジェクトの他の特定方法として、予め設定されている優先条件に従って間接的に対応付け情報を特定する方法を採ることができる。この構成では、いったん優先条件が設定されればユーザは選択オブジェクトを都度指定する必要がないため、ユーザの操作が煩雑にならなくて済む。また、ゲームの内容に応じて優先条件が適切に設定されていれば、ユーザにとって適切な選択オブジェクトを特定することができる。
選択オブジェクトの他の特定方法として、予め設定されている優先条件に従って間接的に対応付け情報を特定する方法を採ることができる。この構成では、いったん優先条件が設定されればユーザは選択オブジェクトを都度指定する必要がないため、ユーザの操作が煩雑にならなくて済む。また、ゲームの内容に応じて優先条件が適切に設定されていれば、ユーザにとって適切な選択オブジェクトを特定することができる。
前記受付手段（５１）は、前記ユーザによる操作に基づいて前記優先条件に関する指示を受け付け、
前記受付手段（５１）により受け付けられた指示に基づいて、前記優先条件を設定する条件設定手段（６０）、をさらに備えてもよい。
この構成によれば、ユーザの操作に基づいて優先条件が設定されるため、ユーザの優先条件に対する要望をユーザが自ら反映させることができるようになる。
前記受付手段（５１）により受け付けられた指示に基づいて、前記優先条件を設定する条件設定手段（６０）、をさらに備えてもよい。
この構成によれば、ユーザの操作に基づいて優先条件が設定されるため、ユーザの優先条件に対する要望をユーザが自ら反映させることができるようになる。
前記優先条件は、選択オブジェクトに対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対する前記ユーザの所持若しくは未所持に関する所持情報、当該複数のオブジェクトに対する前記ユーザの入手履歴に関する履歴情報、および、前記オブジェクトを変化させる処理の前後における選択オブジェクトに関連付けられたパラメータの変化に関する情報のうち、少なくとも１つの情報に関連する条件であってもよい。
選択オブジェクトに対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトは、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトである。
選択オブジェクトに対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトは、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトである。
「所持情報」は、例えば、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトのユーザの所持数、若しくは未所持数、又は、これらのいずれかの数の、変化条件に含まれる複数のオブジェクト識別情報の数に対する比率であってもよい。
「入手履歴」は、未所持の状態から所持の状態に移行したことのユーザの履歴である。
「履歴情報」は、例えば、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトのうちユーザが入手したことがあるオブジェクトの数、若しくはユーザが入手したことがないオブジェクトの数、又は、これらのいずれかの数の、変化条件に含まれる複数のオブジェクト識別情報の数に対する比率であってもよい。あるいは、「履歴情報」は、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトのうちユーザが入手したことがあるオブジェクトについての入手回数であってもよい。
「パラメータ」は、オブジェクトに関連付けられているデータである限り如何なるデータであってもよい。例えば、「パラメータ」は、レベル、レアリティ、あるいはオブジェクトが対戦ゲームで使用されるときのＨＰ、攻撃力、防御力等のデータである。
「入手履歴」は、未所持の状態から所持の状態に移行したことのユーザの履歴である。
「履歴情報」は、例えば、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトのうちユーザが入手したことがあるオブジェクトの数、若しくはユーザが入手したことがないオブジェクトの数、又は、これらのいずれかの数の、変化条件に含まれる複数のオブジェクト識別情報の数に対する比率であってもよい。あるいは、「履歴情報」は、選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトのうちユーザが入手したことがあるオブジェクトについての入手回数であってもよい。
「パラメータ」は、オブジェクトに関連付けられているデータである限り如何なるデータであってもよい。例えば、「パラメータ」は、レベル、レアリティ、あるいはオブジェクトが対戦ゲームで使用されるときのＨＰ、攻撃力、防御力等のデータである。
選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトのユーザの所持数が大きいほど、その選択オブジェクトに対応する変化条件がより早く満足する可能性が高いと考えられるため、そのような選択オブジェクトを優先的に保護してもよい。そのため、優先条件を所持情報に関連する条件とした場合、ユーザにとって好ましい優先順位によって、対応付け情報または選択オブジェクトが特定されうる。
選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトの中でユーザが入手したことがないオブジェクトの数が少ないほど、あるいは、入手したことがあるオブジェクトについての入手回数が多いほど、その選択オブジェクトに対応する変化条件がより早く満足する可能性が高いと考えられるため、そのような選択オブジェクトを優先的に保護してもよい。そのため、優先条件を履歴情報に関連する条件とした場合、ユーザにとって好ましい優先順位によって、対応付け情報または選択オブジェクトが特定されうる。
選択オブジェクトのパラメータの変化が大きいほど、例えば、パラメータとしてのＨＰの増加量が大きいほど、変化処理後の選択オブジェクトをユーザが有利にゲームで使用することができるため、その選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトを優先的に保護してもよい。そのため、優先条件を、選択オブジェクトのパラメータの変化に関する情報に関連する条件とした場合、ユーザにとって好ましい優先順位によって、対応付け情報または選択オブジェクトが特定されうる。
選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトの中でユーザが入手したことがないオブジェクトの数が少ないほど、あるいは、入手したことがあるオブジェクトについての入手回数が多いほど、その選択オブジェクトに対応する変化条件がより早く満足する可能性が高いと考えられるため、そのような選択オブジェクトを優先的に保護してもよい。そのため、優先条件を履歴情報に関連する条件とした場合、ユーザにとって好ましい優先順位によって、対応付け情報または選択オブジェクトが特定されうる。
選択オブジェクトのパラメータの変化が大きいほど、例えば、パラメータとしてのＨＰの増加量が大きいほど、変化処理後の選択オブジェクトをユーザが有利にゲームで使用することができるため、その選択オブジェクトに対して変化処理を実行するための基礎となるオブジェクトを優先的に保護してもよい。そのため、優先条件を、選択オブジェクトのパラメータの変化に関する情報に関連する条件とした場合、ユーザにとって好ましい優先順位によって、対応付け情報または選択オブジェクトが特定されうる。
本発明の別の態様は、ユーザ端末（１０）と、当該ユーザ端末（１０）と通信可能に構成されるサーバ（２０）と、を含み、前記ユーザ端末（１０）または前記サーバ（２０）の少なくともいずれかが、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置（２５）にアクセス可能に構成された情報処理システム（１）であって、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段（５１）、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段（５７）、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段（５６）、
を前記ユーザ端末（１０）または前記サーバ（２０）の少なくともいずれかが備えた、情報処理システムである
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段（５１）、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段（５７）、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段（５６）、
を前記ユーザ端末（１０）または前記サーバ（２０）の少なくともいずれかが備えた、情報処理システムである
本発明の別の態様は、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置（２５）にアクセス可能なコンピュータに、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段（５１）、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段（５７）、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段（５６）、
として機能させるためのプログラムである。
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段（５１）、
前記受付手段（５１）により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段（５７）、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段（５６）、
として機能させるためのプログラムである。
本発明の別の態様は、上記プログラムを格納する、光ディスク、磁気ディスク等の、コンピュータが読み取り可能な記憶媒体であってもよい。
なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係る情報処理装置等が図示の態様に限定されるものではない。
１…ゲームシステム
１０…ユーザ端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１５…操作入力部
１６…表示部
１７…通信インタフェース部
１８…ストレージ
１９…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…通信インタフェース部
２５…ストレージ
２６…バス
５１…受付手段
５２…ゲーム処理手段
５３…第１判定手段
５４…変更手段
５５…第２判定手段
５６…出力手段
５７…対応付け手段
５８…特定手段
５９…制限手段
６０…条件設定手段
７０…データテーブル群
１０…ユーザ端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１５…操作入力部
１６…表示部
１７…通信インタフェース部
１８…ストレージ
１９…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…通信インタフェース部
２５…ストレージ
２６…バス
５１…受付手段
５２…ゲーム処理手段
５３…第１判定手段
５４…変更手段
５５…第２判定手段
５６…出力手段
５７…対応付け手段
５８…特定手段
５９…制限手段
６０…条件設定手段
７０…データテーブル群
Claims (12)
- オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段と、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付けるとともに、前記選択オブジェクトと前記ユーザとの対応付けを対応付け情報と関連付ける対応付け手段と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記ユーザによる操作に基づいて、前記複数の選択オブジェクトのいずれかと関連付けられた対応付け情報を特定する第１特定手段と、
前記第１特定手段によって特定された対応付け情報と関連付けられた選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定されるオブジェクトが、前記ユーザが所持する所持オブジェクトである場合、当該所持オブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段と、
を備えた情報処理装置。 - 前記第１特定手段は、前記受付手段によって前記要求を受け付けるタイミング、前記ユーザが前記重複するオブジェクト識別情報によって特定されるオブジェクトを入手したタイミング、または、前記複数の選択オブジェクトの中からいずれかの選択オブジェクトを特定するための前記ユーザの要求を受け付けるタイミングにおいて、対応付け情報を特定する、
請求項１に記載された情報処理装置。 - 前記第１特定手段は、前記ユーザの操作によって指定される対応付け情報を特定する、
請求項１または２に記載された情報処理装置。 - 前記第１特定手段は、予め設定されている優先条件に従って対応付け情報を特定する、
請求項１または２に記載された情報処理装置。 - オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザによる操作に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する要求を受け付ける受付手段と、
前記受付手段により前記要求を受け付けたことに応じて、前記選択オブジェクトと前記ユーザとを対応付ける対応付け手段と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記重複するオブジェクト識別情報を示す出力データを出力する出力手段と、
前記ユーザに対応付けられた複数の選択オブジェクトについて、それぞれに対応する前記変化条件に含まれる複数のオブジェクト識別情報の少なくとも１つが重複する場合に、前記ユーザによる操作に基づいて、前記複数の選択オブジェクトのいずれかを特定する第２特定手段と、
前記第２特定手段によって特定された選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定されるオブジェクトが、前記ユーザが所持する所持オブジェクトである場合、当該所持オブジェクトに対して、前記オブジェクトを変化させる処理とは異なる処理に用いられることを制限する制限手段と、
を備えた情報処理装置。 - 前記第２特定手段は、前記受付手段によって前記要求を受け付けるタイミング、前記ユーザが前記重複するオブジェクト識別情報によって特定されるオブジェクトを入手したタイミング、または、前記複数の選択オブジェクトの中からいずれかの選択オブジェクトを特定するための前記ユーザの要求を受け付けるタイミングにおいて、選択オブジェクトを特定する、
請求項５に記載された情報処理装置。 - 前記第２特定手段は、前記ユーザの操作によって指定される選択オブジェクトを特定する、
請求項５または６に記載された情報処理装置。 - 前記第２特定手段は、予め設定されている優先条件に従って選択オブジェクトを特定する、
請求項５または６に記載された情報処理装置。 - 前記受付手段は、前記ユーザによる操作に基づいて前記優先条件に関する指示を受け付け、
前記受付手段により受け付けられた指示に基づいて、前記優先条件を設定する条件設定手段、をさらに備えた、
請求項４または８に記載された情報処理装置。 - 前記優先条件は、選択オブジェクトに対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトに対する前記ユーザの所持若しくは未所持に関する所持情報、当該複数のオブジェクトに対する前記ユーザの入手履歴に関する履歴情報、および、前記オブジェクトを変化させる処理の前後における選択オブジェクトに関連付けられたパラメータの変化に関する情報のうち、少なくとも１つの情報に関連する条件である、
請求項４、８または９のいずれかに記載された情報処理装置。 - ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、前記ユーザ端末または前記サーバの少なくともいずれかが、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能に構成された情報処理システムであって、請求項１〜１０のいずれかに記載された情報処理装置の各手段を前記ユーザ端末または前記サーバの少なくともいずれかが備えた、情報処理システム。
- オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理を行う条件であって複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータを、請求項１〜１０のいずれかに記載された情報処理装置の各手段として機能させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013257685A JP6278389B2 (ja) | 2013-12-13 | 2013-12-13 | 情報処理装置、情報処理システム、プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013257685A JP6278389B2 (ja) | 2013-12-13 | 2013-12-13 | 情報処理装置、情報処理システム、プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015112365A JP2015112365A (ja) | 2015-06-22 |
| JP6278389B2 true JP6278389B2 (ja) | 2018-02-14 |
Family
ID=53526731
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013257685A Active JP6278389B2 (ja) | 2013-12-13 | 2013-12-13 | 情報処理装置、情報処理システム、プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6278389B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6075495B1 (ja) * | 2016-05-10 | 2017-02-08 | 株式会社セガゲームス | 情報処理装置及びプログラム |
| JP2017196387A (ja) * | 2016-12-08 | 2017-11-02 | 株式会社セガゲームス | 情報処理装置及びプログラム |
| JP6848438B2 (ja) * | 2017-01-05 | 2021-03-24 | 株式会社セガ | 情報処理装置、プログラム及び情報処理方法 |
| JP2021079216A (ja) | 2021-03-01 | 2021-05-27 | 株式会社セガ | 情報処理装置 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5102406B1 (ja) * | 2012-07-06 | 2012-12-19 | 株式会社 ディー・エヌ・エー | ゲーム管理サーバ装置用プログラム、ゲーム管理サーバ装置、および、端末装置用プログラム |
| JP5086491B1 (ja) * | 2012-08-06 | 2012-11-28 | 株式会社 ディー・エヌ・エー | ゲームプログラム、及び、情報処理装置 |
| JP5153960B1 (ja) * | 2012-08-24 | 2013-02-27 | 株式会社 ディー・エヌ・エー | ゲームプログラム、及び、情報処理装置 |
| JP5296932B1 (ja) * | 2013-02-16 | 2013-09-25 | 春佳 西守 | ゲームプログラム |
| JP6251507B2 (ja) * | 2013-07-31 | 2017-12-20 | 株式会社バンダイナムコエンターテインメント | プログラム及びゲームシステム |
| JP6097970B2 (ja) * | 2013-10-25 | 2017-03-22 | 株式会社コナミデジタルエンタテインメント | 情報処理装置、情報処理システム、プログラム |
-
2013
- 2013-12-13 JP JP2013257685A patent/JP6278389B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2015112365A (ja) | 2015-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6097970B2 (ja) | 情報処理装置、情報処理システム、プログラム | |
| JP6176790B2 (ja) | 情報処理装置、情報処理システム、プログラム | |
| JP6194534B2 (ja) | 情報処理装置、プログラム | |
| JP6260993B2 (ja) | 情報処理装置、プログラム、情報処理システム | |
| JP5838149B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
| JP6278389B2 (ja) | 情報処理装置、情報処理システム、プログラム | |
| JP6005605B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
| JP2023106551A (ja) | プログラム、情報処理装置の制御方法及び情報処理システム | |
| JP6683345B2 (ja) | 情報処理装置、情報処理システム、プログラム | |
| JP6252189B2 (ja) | 情報処理装置、プログラム、情報処理システム | |
| JP6821215B2 (ja) | 情報処理装置のプログラム、情報処理装置、情報処理装置の出力データの出力方法、情報処理システム | |
| JP5393909B1 (ja) | サーバー装置、及び、プログラム | |
| JP6383024B2 (ja) | 情報処理装置、ゲームプログラム | |
| JP6566325B2 (ja) | 情報処理装置、プログラム、情報処理システム | |
| JP7290351B2 (ja) | 情報処理装置、ゲームプログラム | |
| JP6712699B2 (ja) | 情報処理装置、情報処理システム、プログラム | |
| JP6980298B2 (ja) | 情報処理装置、ゲームプログラム | |
| JP5393922B1 (ja) | サーバー装置、及び、プログラム | |
| JP7138966B2 (ja) | 情報処理装置、情報処理システム、プログラム | |
| JP6566327B2 (ja) | 情報処理装置、プログラム、情報処理システム | |
| JP2019193870A (ja) | 情報処理装置、プログラム、情報処理システム | |
| JP2014176602A (ja) | プログラム、及び、情報処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160526 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170116 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170531 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170606 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170711 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20171219 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180110 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6278389 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |