JP7437802B2 - プログラム及び情報処理方法 - 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 Lumin
escence)ディスプレイ等の表示デバイスである。マトリクス状に画素単位で配置された薄
膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタを適用した場合、表示部１
６は、薄膜トランジスタを駆動することでウェブページの画像を表示画面に表示する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (5)

1. ベースオブジェクトを用い、前記ベースオブジェクトを変化させる処理を実行することを含むゲームを、ゲームサーバを介して行うゲーム装置のプロセッサを動作させるためのゲームプログラムであって、
   ユーザが所持するベースオブジェクトの中から当該ユーザによって選択されたベースオブジェクトと対応付けられた、当該ベースオブジェクトを変化させる処理の実行と引き換えに消費される参照オブジェクトの情報を取得する取得手段と、
   前記取得手段が取得した参照オブジェクトの画像を含む提示画像を出力する出力手段と、
   前記提示画像に対する前記ユーザの操作に基づいて指定された参照オブジェクトを、指定オブジェクトとして受け付ける受付手段と、
   を備え、
   前記ゲームは前記参照オブジェクトを入手可能な複数の場所を含み、かつ、前記複数の場所のそれぞれに入手可能な参照オブジェクトが設定されており、
   前記出力手段は、前記複数の場所のいずれかに前記ユーザを誘導するための操作対象を表示する制御であって、前記操作対象を前記指定オブジェクトが入手可能に設定された場所に前記ユーザを誘導するための操作対象のみを操作可能に表示させるための制御を行い、
   前記出力手段による制御は、前記受付手段が前記提示画像に対する前記ユーザの操作に基づいて指定された参照オブジェクトを、指定オブジェクトとして受け付けることによって、実行される、
   ゲームプログラムであって、
   前記提示画像には、前記ベースオブジェクトを変化させる処理の実行後の前記ベースオブジェクトの情報を含む、
   ことを特徴とするプログラム。
   
2. 前記提示画像には、前記参照オブジェクトの所持に関する情報を含む、
   ことを特徴とする請求項１に記載のプログラム。
3. 前記ベースオブジェクトを変化させる処理は、前記ベースオブジェクトのパラメータの変更である、
   ことを特徴とする請求項１または請求項２に記載のプログラム。
4. 前記ベースオブジェクトを変化させる処理は、前記ベースオブジェクトの画像の変更である、
   ことを特徴とする請求項１から請求項３のいずれか１項に記載のプログラム。
5. ベースオブジェクトを用いたゲームを、ゲームサーバを介して行うゲーム装置のプロセッサを動作させるための情報処理方法であって、
   ユーザが所持するベースオブジェクトの中から当該ユーザによって選択されたベースオブジェクトと対応付けられた、当該ベースオブジェクトを変化させる処理の実行と引き換えに消費される参照オブジェクトの情報を取得し、
   取得した参照オブジェクトの画像を含む提示画像を出力し、
   前記提示画像に対する前記ユーザの操作に基づいて指定された参照オブジェクトを、指定オブジェクトとして受け付け、
   前記ゲームは前記参照オブジェクトを入手可能な複数の場所を含み、かつ、前記複数の場所のそれぞれに入手可能な参照オブジェクトが設定されており、
   前記複数の場所のいずれかに前記ユーザを誘導するための操作対象であって、前記操作対象を前記指定オブジェクトが入手可能に設定された場所に前記ユーザを誘導するための操作対象のみを操作可能に表示させるための制御を行い、
   前記制御は、前記提示画像に対する前記ユーザの操作に基づいて指定された参照オブジェクトを、指定オブジェクトとして受け付けることによって、実行される、
   情報処理方法であって、
   前記提示画像には、前記ベースオブジェクトを変化させる処理の実行後の前記ベースオブジェクトの情報を含む、
   ことを特徴とする、情報処理方法。
   

Images