(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-06-06
(45)【発行日】2023-06-14
(54)【発明の名称】サーバ装置、及びプログラム
(51)【国際特許分類】
A63F 13/79 20140101AFI20230607BHJP
A63F 13/69 20140101ALI20230607BHJP
A63F 13/35 20140101ALI20230607BHJP
【ＦＩ】
A63F13/79
A63F13/69 520
A63F13/35
【請求項の数】
6
(21)【出願番号】P 2019014793
(22)【出願日】2019-01-30
(65)【公開番号】P2020120942
(43)【公開日】2020-08-13
【審査請求日】2021-11-24
(73)【特許権者】
【識別番号】500033117
【氏名又は名称】株式会社ＭＩＸＩ
(74)【代理人】
【識別番号】100122275
【弁理士】
【氏名又は名称】竹居 信利
(72)【発明者】
【氏名】大沼 純平
【審査官】池田 剛志
(56)【参考文献】
【文献】特開２０１５－１２６７８５（ＪＰ，Ａ）
【文献】特開２０１８－１３４２８４（ＪＰ，Ａ）
【文献】パズドラ[攻略]：売却時のモンスターポイントを紹介，Appliv Games [online]，2015年08月05日，https://games.app-liv.jp/archives/821，<2022年12月8日検索>
【文献】パズル＆ドラゴンズ PUZZLE & DRAGONS，アプリスタイル Ａｎｄｒｏｉｄ ｖｏｌ．１ ，株式会社イースト・プレス，2013年12月26日，第1巻，p.9
【文献】[龍が如くオンライン]同じキャラの使い道，神ゲー攻略[online]，2018年11月29日，https://kamigame.jp/龍が如くONLINE/攻略ガイド/同じキャラの使い道.html，<2022年12月8日検索>
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ａ６３Ｆ １３／００－１３／９８
Ａ６３Ｆ ９／２４
(57)【特許請求の範囲】
【請求項1】
ユーザが操作するユーザ側装置に接続され、ユーザが所持するキャラクタアイテムごとに第１のパラメータと第２のパラメータとを含む複数のパラメータ情報を保持する手段と、
ユーザごとに、第１のポイント所持高の情報と第２のポイントの所持高の情報とを保持する手段と、
合成対象となる前記キャラクタアイテムと、合成素材とを指定した合成要求を前記ユーザ側装置から受けて、前記合成対象となったキャラクタアイテムに係る前記第１のパラメータまたは第２のパラメータの少なくとも一方を更新する更新手段と、
価値交換の対象となる前記キャラクタアイテムの指定と、価値交換の要求とを前記ユーザ側装置から受けて、当該価値交換の対象としたキャラクタアイテムに係る前記第１のパラメータに基づいて第１のポイントの所持高を更新し、当該価値交換の対象としたキャラクタアイテムに係る前記第２のパラメータに基づいて第２のポイントの所持高を更新する交換処理手段と、
を含み、
前記更新手段は、合成対象となる前記キャラクタアイテムと、合成素材となる少なくとも一つの前記キャラクタアイテムとを指定した合成要求を前記ユーザ側装置から受けて、前記合成対象となったキャラクタアイテムに係る前記第１のパラメータを更新し、前記指定された合成対象となるキャラクタアイテムの種類と合成素材となるキャラクタアイテムの種類とが同一であるときに、前記第２のパラメータを更新するサーバ装置。
【請求項2】
請求項１に記載のサーバ装置であって、前記交換処理手段は、前記価値交換の対象となる複数のキャラクタアイテムの指定と、価値交換の要求とを前記ユーザ側装置から受けて、当該価値交換の対象としたキャラクタアイテムの各々を交換した際の第１のポイントの所持高の更新量を累算し、当該累算の結果に基づいて第１のポイントの所持高を更新し、当該価値交換の対象としたキャラクタアイテムの各々を交換した際の第２のポイントの所持高の更新量を累算し、当該累算の結果に基づいて第２のポイントの所持高を更新するサーバ装置。
【請求項3】
請求項１または２に記載のサーバ装置であって、前記キャラクタアイテムには、キャラクタアイテムの種類ごとにレア度の情報が関連付けて設定され、
前記交換処理手段は、前記価値交換の対象としたキャラクタアイテムに係る前記第２のパラメータと、当該キャラクタアイテムの種類に関連付けられたレア度の情報とに基づいて、第２のポイントの所持高を更新するサーバ装置。
【請求項4】
請求項３に記載のサーバ装置であって、前記交換処理手段は、前記価値交換の対象としたキャラクタアイテムの種類に関連付けられたレア度の情報が予め定めた基準を満足しない場合は、第２のポイントの所持高を更新しないよう制御するサーバ装置。
【請求項5】
請求項１から４のいずれか一項に記載のサーバ装置であって、前記価値交換の要求は、指定したキャラクタアイテムを第１のポイントに交換する要求であるサーバ装置。
【請求項6】
ユーザが操作するユーザ側装置に接続されたサーバ装置を、ユーザが所持するキャラクタアイテムごとに第１のパラメータと第２のパラメータとを
含む複数のパラメータ情報を保持する手段と、
ユーザごとに、第１のポイントの所持高の情報と第２のポイントの所持高の情報とを保持する手段と、
合成対象となる前記キャラクタアイテムと、合成素材となる少なくとも一つの前記キャラクタアイテムとを指定した合成要求を前記ユーザ側装置から受けて、前記合成対象となったキャラクタアイテムに係る前記第１のパラメータまたは第２のパラメータの少なくとも一方を更新する更新手段と、
価値交換の対象となる前記キャラクタアイテムの指定と、価値交換の要求とを前記ユーザ側装置から受けて、当該価値交換の対象としたキャラクタアイテムに係る前記第１のパラメータに基づいて第１のポイントの所持高を更新し、当該価値交換の対象としたキャラクタアイテムに係る前記第２のパラメータに基づいて第２のポイントの所持高を更新する交換処理手段と、
として機能させ、
前記更新手段として機能させる際には、前記サーバ装置に、合成対象となる前記キャラクタアイテムと、合成素材となる少なくとも一つの前記キャラクタアイテムとを指定した合成要求を前記ユーザ側装置から受けて、前記合成対象となったキャラクタアイテムに係る前記第１のパラメータを更新させ、前記指定された合成対象となるキャラクタアイテムの種類と合成素材となるキャラクタアイテムの種類とが同一であるときに、前記第２のパラメータを更新させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバ装置、及びプログラムに関する。
【背景技術】
【0002】
ユーザにキャラクタアイテムを配布して提供されるソーシャルゲーム等のサービスがある。ここでキャラクタアイテムには、提供するサービスの内容に応じて、一般に複数のパラメータ情報が関連付けられている。
【0003】
またこのようなサービスでは、キャラクタアイテムが重複したときや、不要となったキャラクタアイテムを整理する際には、「合成」等の処理や「売却」（あるいは放棄）等の処理をユーザに行わせている。さらにこのようなキャラクタアイテムの整理の際、パラメータ情報の更新、他のアイテムとの交換、サービス内でのアイテムと交換可能な、仮想的なポイントへの交換をするようにしているものがある。例えば売却等によってキャラクタアイテムを放棄する場合、いずれかのパラメータ情報に応じてポイントの残高を調整して、あたかもポイントに交換したように演出する例もある。
【0004】
さらに、従来、任意のキャラクタアイテムの合成により第１のパラメータ情報を上昇させ、また、同一の種類のキャラクタアイテムを合成するときには、第１のパラメータ情報とともに第２のパラメータ情報を上昇させる、といったように、パラメータ情報によって上昇の条件を異ならせているものがある。
【先行技術文献】
【特許文献】
【0005】
【文献】特開２０１６－０２２３７７号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
このように、売却・放棄等の方法で、いずれか一つのパラメータ情報（交換可能パラメータ）に基づいて、いずれか一つのポイントへの交換を行っているのがこのようなサービスにおける現状である。また、ポイントとの交換を行い得ないパラメータ情報（交換不能パラメータ）については、当該交換不能パラメータに応じた価値のアイテムとの等価交換を行わせることで、交換不能パラメータを上昇させる動機付けとしている。
【0007】
しかしながら、こうした交換不能パラメータに応じた価値のあるアイテムとの等価交換を行うためにはまず、合成等の処理によって適当な値まで交換不能パラメータを上昇させてから等価交換を行う必要があった。このため、ユーザにとってはキャラクタアイテムの整理を行いにくいという問題があった。
【0008】
本発明は上記実情に鑑みて為されたもので、ユーザのキャラクタアイテムの整理を支援可能なサービスを提供するサーバ装置、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
上記従来例の問題点を解決するための本発明の一態様は、サーバ装置であって、ユーザが操作するユーザ側装置に接続され、ユーザが所持するキャラクタアイテムごとに第１のパラメータと第２のパラメータとを含む複数のパラメータ情報を保持する手段と、ユーザごとに、第１のポイント所持高の情報と第２のポイントの所持高の情報とを保持する手段と、合成対象となる前記キャラクタアイテムと、合成素材とを指定した合成要求を前記ユーザ側装置から受けて、前記合成対象となったキャラクタアイテムに係る前記第１のパラメータまたは第２のパラメータの少なくとも一方を更新する更新手段と、価値交換の対象となる前記キャラクタアイテムの指定と、価値交換の要求とを前記ユーザ側装置から受けて、当該価値交換の対象としたキャラクタアイテムに係る前記第１のパラメータに基づいて第１のポイントの所持高を更新し、当該価値交換の対象としたキャラクタアイテムに係る前記第２のパラメータに基づいて第２のポイントの所持高を更新する交換処理手段と、を含むこととしたものである。
【発明の効果】
【0010】
本発明によると、ユーザのキャラクタアイテムの整理を支援可能なサービスが手供される。
【図面の簡単な説明】
【0011】
【図1】本発明の実施の形態に係るサーバ装置の構成及びその接続態様を表す構成ブロック図である。
【図2】本発明の実施の形態に係るサーバ装置の例を表す機能ブロック図である。
【図3】本発明の実施の形態に係るサーバ装置が利用するキャラクタデータベースの内容例を表す説明図である。
【図4】本発明の実施の形態に係るサーバ装置が利用するユーザデータベースの内容例を表す説明図である。
【図5】本発明の実施の形態に係るサーバ装置に接続される端末の画面例を表す説明図である。
【発明を実施するための形態】
【0012】
本発明の実施の形態について図面を参照しながら説明する。本発明の実施の形態に係るサーバ装置１は、図１に例示するように、制御部１１，記憶部１２，及び通信部１３を含んで構成され、インターネットや携帯電話通信網等の通信手段を介して、ユーザの所持するユーザ側装置としての端末２との間で通信可能に接続されている。
【0013】
サーバ装置１の制御部１１は、ＣＰＵ等のプログラム制御デバイスであり、記憶部１２に格納されたプログラムに従って動作する。本実施の形態では、この制御部１１は、キャラクタアイテムを用いたサービス（ソーシャルゲーム等）を提供するための処理を実行するものであり、本実施の形態では、ユーザごとに、ユーザが所持するキャラクタアイテムを管理しており、また、ユーザが所持するキャラクタアイテムごとに第１のパラメータ（例えばレベル）と第２のパラメータ（例えばラック）とを含む複数のパラメータ情報を保持する。
【0014】
またこの制御部１１は、ユーザごとに、第１のポイント（例えばゴールド）所持高の情報と第２のポイント（例えばラック）の所持高の情報とを保持しており、合成対象となるキャラクタアイテムと、合成素材とを指定した合成要求を、ユーザの端末２から受けて、当該合成対象となったユーザのキャラクタアイテムに係る第１のパラメータまたは第２のパラメータの少なくとも一方を更新する。
【0015】
さらに制御部１１は、価値交換の対象となるキャラクタアイテムの指定と、価値交換の要求とを、ユーザの端末２から受けると、当該価値交換の対象としたユーザのキャラクタアイテムに係る第１のパラメータに基づいて第１のポイントの所持高を更新し、当該価値交換の対象としたユーザのキャラクタアイテムに係る第２のパラメータに基づいて第２のポイントの所持高を更新する処理を行う。この制御部１１の動作については後に詳しく述べる。
【0016】
記憶部１２は、ディスクデバイス等であり、制御部１１が実行するプログラムを保持する。またこの記憶部１２は、制御部１１の処理に必要となる、ユーザごとの、ユーザが所持するキャラクタアイテムや、そのパラメータ（第１のパラメータ及び第２のパラメータを含む）を、キャラクタアイテムデータベースとして格納するほか、制御部１１のワークメモリとしても動作する。
【0017】
また、本実施の形態の一例では、この記憶部１２には、図３に例示するように、キャラクタアイテムの種類ごとに、キャラクタの識別子（ＩＤ）や、キャラクタアイテムの名称、キャラクタアイテムの図柄、付帯的な情報（「属性」等の情報）、初期の（後に説明する合成処理等を行う前の初期状態での）第１のパラメータ（レベル）及び第２のパラメータ（ラック）を含むパラメータ値の情報が互いに関連付けて、キャラクタデータベースとして保持されているものとする。
【0018】
さらにこの記憶部１２には、キャラクタアイテム以外のゲームアイテム（キャラクタアイテムを「強化」する（そのレベルを上昇させる）アイテムなど）のアイテム識別子と、アイテムの名称と、アイテムの図柄と、アイテムに関する付加的な情報等とともに、その価値交換のコスト（ポイント高）の情報が関連付けて保持されている。また、このゲームアイテムの情報には、アイテム識別子に関連付けて、当該ゲームアイテムが合成素材として利用されたときの、合成対象となったキャラクタアイテムの第１のパラメータや第２のパラメータの上昇値（増分量）が設定されていてもよい。
【0019】
ここで価値交換のコストは、ポイントが複数種類ある場合は、第１のポイントのコストと、第２のポイントのコストとを分けて設定しておくこととし、いずれかのポイントでは交換できないという場合には、そのコストの値を、比較処理で用いない値の範囲等に、例えば負の値に、設定しておくものとする。
【0020】
通信部１３は、ネットワークインタフェースであり、制御部１１から入力される指示に従って、ユーザの端末２に対して情報を送出する。またこの通信部１３は、ユーザの端末２から受信した要求等の情報を制御部１１に出力している。
【0021】
次に制御部１１の動作について説明する。本実施の形態の制御部１１は、機能的には、図２に例示するように、サービス提供部２１と、ユーザ情報保持部２２と、合成処理部２３と、交換処理部２４と、ポイント利用処理部２５とを含んで構成される。
【0022】
サービス提供部２１は、キャラクタアイテムを用いたサービスをユーザに提供する。本実施の形態の一例では、このサービス提供部２１は、ユーザによりコンピュータが用意したキャラクタ（以下では敵キャラクタと呼ぶ）とのバトルが行われるゲームサービスを提供するものとする。もっとも本実施の形態においてサービス提供部２１が提供するサービスは、このようなゲームには限られず、キャラクタアイテムを用いるものであれば、どのようなものであってもよい。
【0023】
ここでは説明のため、サービス提供部２１が提供する上記のゲームでは、バトルに際して、ユーザが所持するキャラクタアイテムから、少なくとも一つのキャラクタアイテムをデッキとして選出する。そしてバトル開始時に、これらのキャラクタアイテムの体力ポイント（ＨＰ）を、それぞれのキャラクタアイテムごとに設定された第１のパラメータ（レベル）に応じた値に設定する。
【0024】
バトル開始後は、サービス提供部２１の動作により、バトルごとに用意される敵キャラクタを、上記デッキに含まれるキャラクタアイテムが順次「攻撃」し、当該攻撃したプレイヤキャラクタに設定されている攻撃ポイント（ＢＰ）に基づいて、攻撃された敵キャラクタの体力ポイント（ＨＰ）を減少させる処理が行われる。
【0025】
またその後、一定の回数の「攻撃」が終了すると、コンピュータ側のターンとなって、敵キャラクタが順次、ユーザのデッキに含まれるプレイヤキャラクタを「攻撃」して、上記と同様に、敵キャラクタごとに設定されている攻撃ポイント（ＢＰ）に基づいて、攻撃されたユーザのキャラクタアイテムの体力ポイント（ＨＰ）を減少させる処理が行われる。
【0026】
このように、ユーザのキャラクタアイテムや敵キャラクタの体力ポイントを減少させたときには、減少させた体力ポイントが予め定めた閾値を下回ると、当該キャラクタアイテムまたは敵キャラクタが、デッキやバトルの場から退場し、攻撃等が不能となる、といったようにして進行するものとする。
【0027】
そして、本実施の形態ではサービス提供部２１の動作により、バトルの場に用意された敵キャラクタがすべて退場したこととなり、かつ、その時点でユーザの選出したデッキにキャラクタアイテムが一体でも残っていれば、ユーザ側の勝利ということとして、デッキに含まれる少なくとも一つのキャラクタアイテムに設定された第２のパラメータ（ラック）に応じた報酬（ゲームアイテム等）がユーザ側に提供されるものとする。
【0028】
ユーザ情報保持部２２は、図４に例示するように、ユーザごとに、ユーザの識別情報（ユーザＩＤ）、ユーザの名称（サービス内で利用されるユーザのニックネーム）、認証情報、ユーザが所持するキャラクタアイテムの情報（キャラクタアイテム情報）、ポイント情報、キャラクタアイテム以外のゲームアイテムの情報等を互いに関連付けて、ユーザデータベースとして記憶部１２に保持する。
【0029】
ここでキャラクタアイテムの情報は、ユーザが所持するキャラクタアイテムの識別子（ＩＤ）と、ユーザが所持するキャラクタアイテムごとに固有に割り当てられたキャラクタ所有識別子と、キャラクタアイテムの第１のパラメータや第２のパラメータ等のパラメータ情報等を含む。ここでキャラクタ所有識別子はユーザの所持する各キャラクタアイテムに固有のものであり、例えば同じ識別子のキャラクタアイテムを複数所有する場合でも、それぞれに互いに異なるキャラクタ所有識別子が付与される。
【0030】
またゲームアイテムの情報は、ユーザが所持するゲームアイテムの識別子と、ユーザが所持するゲームアイテムごとに固有に割り当てられたゲームアイテム所有識別子とを互いに関連付けたものである。ここでゲームアイテム所有識別子は、例えば同じ識別子のゲームアイテムを複数所有する場合でも、それぞれに互いに異なるゲームアイテム所有識別子が付与される。
【0031】
またポイント情報は、本実施の形態の例では、第１のポイントと第２のポイントとのそれぞれの値を含む。本実施の形態において第１，第２のポイントは、サーバ装置１が提供するサービスのうちで、通貨のように利用可能なものである。なお、本実施の形態の例では、第１のポイントと第２のポイントとは互いに交換できないものとする。
【0032】
合成処理部２３は、合成処理の開始指示を、いずれかの端末２から受信すると、当該端末２のユーザＩＤを特定する。このユーザＩＤの特定は、通信開始時に固有のセッション識別子を端末２に通知し、ユーザをユーザ名とパスワードと等で認証してから、以降の通信においては端末２から指示や要求とともにセッション識別子を受信するなどの広く知られた方法で行うことができるので、ここでの詳しい説明は省略する。本実施の形態のサーバ装置１におけるその他の処理において端末２のユーザＩＤを特定する場合も同様とする。
【0033】
合成処理部２３は、ユーザ情報保持部２２によって記憶部１２に格納されているユーザデータベースから、上記特定したユーザＩＤに関連付けられた情報を参照し、当該ユーザが所持するキャラクタアイテムの一覧を、当該ユーザの端末２に対して送信する。そして当該端末２から合成の対象となるキャラクタアイテムの選択を受け入れる。
【0034】
次に合成処理部２３は、上記特定したユーザＩＤに関連付けられているキャラクタアイテムであって、上記選択されたキャラクタアイテムとはキャラクタ所有識別子が異なっている、他のキャラクタアイテム、またはゲームアイテムの選択を少なくとも一つ受け入れて、ここで選択されたキャラクタアイテムまたはゲームアイテムを、合成素材として記憶する。
【0035】
そして合成処理部２３は、この端末２から、さらに合成処理の実行指示を受け入れると、当該端末２から合成の対象となるキャラクタアイテムと、合成素材の指定を含む合成要求を受け入れたものとして、合成の処理を実行する。
【0036】
合成の処理では、合成処理部２３は、上記ユーザＩＤに関連付けてユーザデータベースに記録されているキャラクタアイテム（ユーザが所持するキャラクタアイテム）のうち、合成対象として指定されたキャラクタアイテムの識別子に関連付けて記憶部１２に格納されている第１のパラメータまたは第２のパラメータの少なくとも一方を更新する。なお、合成の処理においては、ユーザＩＤに関連付けて記憶される第１のポイント（例えばゴールド）が消費されることとしてもよい。この際、第１のポイントの消費量は、例えば、合成に係るキャラクタアイテムの識別子、及び当該キャラクタアイテムのパラメータ（第１パラメータ、第２パラメータの少なくともいずれかを含む）に基づいて決定されることとしてよい。
【0037】
本実施の形態では、この更新では、合成素材として指定されたキャラクタアイテムのパラメータやゲームアイテムに関連して設定されているパラメータの上昇値の情報を参照して、合成対象となったキャラクタアイテムの各パラメータを上昇させるものとする。
【0038】
一例として、合成の対象となったキャラクタアイテムの、合成前の第１のパラメータが「１００」、第２のパラメータが「１」であるものとし、合成素材としたキャラクタアイテムの第１のパラメータが「５０」、第２のパラメータが「１」であり、合成素材としたゲームアイテムの識別子に関連づけて設定されている第１のパラメータの上昇値が「１００」、第２のパラメータの上昇値が「０」であるとする。この場合、合成処理部２３は、合成対象となったキャラクタアイテムの合成後の第１のパラメータを、
１００＋５０＋１００＝２５０、
第２のパラメータを、
１＋１＋０＝２
に更新する。つまり、本実施の形態では、この合成処理部２３が本発明の更新手段を実現したものとなる。
１００＋５０＋１００＝２５０、
第２のパラメータを、
１＋１＋０＝２
に更新する。つまり、本実施の形態では、この合成処理部２３が本発明の更新手段を実現したものとなる。
【0039】
もっとも、このようなパラメータの更新は一例であり、合成処理の「成功」、「大成功」…を、それぞれ所定の確率で発生させ、「成功」時と、「大成功」時とでパラメータの更新量を異ならせるなどといった処理を行っても構わない。
【0040】
なお、ここでは、キャラクタアイテムの合成により第１のパラメータと第２のパラメータとの双方を上昇させているが、本実施の形態においては、パラメータのいずれか、例えば第２のパラメータについては、合成の対象となったキャラクタアイテムと合成素材との少なくとも一方に関係した所定の更新条件に合致するときにのみ、上昇して更新することとしてもよい。
【0041】
この更新条件は例えば、合成の対象となったキャラクタアイテムの識別子と、合成素材としたキャラクタアイテムの識別子とが一致している（つまり、同種のキャラクタアイテム同士を合成した）との条件であってもよい。
【0042】
この場合、合成処理部２３は、第１のパラメータについては上述と同様に更新するが、第２のパラメータについては、合成素材に含まれるキャラクタアイテムのうち、合成の対象としたキャラクタアイテムと同じ識別子のキャラクタアイテムの第２のパラメータのみを累算して、合成の対象としたキャラクタアイテムに関連付けてユーザデータベースに保持された第２のパラメータに、この累算結果を加算する。
【0043】
従って合成処理部２３は、合成素材に、合成の対象としたキャラクタアイテムと同じ識別子のキャラクタアイテムが含まれなければ、合成の対象としたキャラクタアイテムについての第２のパラメータは更新しない。
【0044】
また合成処理部２３は、ユーザデータベースから、合成要求を行ったユーザのユーザＩＤに関連付けられて記録されている、合成素材としたキャラクタアイテムや、ゲームアイテムを削除してもよい。さらに合成処理部２３は、ここで合成素材をユーザデータベースから削除する代わりに、次のように処理してもよい。
【0045】
例えば、本実施の形態の一例では、サーバ装置１では各キャラクタアイテムの識別子に関連付けて、第１のパラメータの最大値を定めておくものとする。そして一例として当該最大値が「２００」であるキャラクタアイテムを合成の対象として、上述と同様、第１のパラメータが「５０」、第２のパラメータが「１」であるキャラクタアイテムと、第１のパラメータの上昇値が「１００」、第２のパラメータの上昇値が「０」であるゲームアイテムとを合成素材として合成要求が行われたとする。このとき、合成処理部２３は、合成対象となったキャラクタアイテムの合成後の第１のパラメータを、
１００＋５０＋１００＝２５０、
と演算するが、これが最大値の「２００」を超えているので、その差である、２５０－２００＝５０を、「残存分」として、合成素材としたゲームアイテム（指定順序で最後から順に残存分を割り当てればよい）の第１のパラメータの上昇値を「５０」として、ユーザデータベースに記録して、当該ゲームアイテムをユーザデータベースから削除せずに残しておくものとしてもよい。
１００＋５０＋１００＝２５０、
と演算するが、これが最大値の「２００」を超えているので、その差である、２５０－２００＝５０を、「残存分」として、合成素材としたゲームアイテム（指定順序で最後から順に残存分を割り当てればよい）の第１のパラメータの上昇値を「５０」として、ユーザデータベースに記録して、当該ゲームアイテムをユーザデータベースから削除せずに残しておくものとしてもよい。
【0046】
交換処理部２４は、価値交換の対象となるキャラクタアイテムの指定と、価値交換の要求とをユーザの端末２から受け入れて、当該価値交換の対象としたキャラクタアイテムに係る第１のパラメータに基づいて第１のポイントの所持高を更新し、当該価値交換の対象としたキャラクタアイテムに係る第２のパラメータに基づいて第２のポイントの所持高を更新する。また交換処理部２４は、当該価値交換の対象として指定されたキャラクタアイテムをユーザデータベースから削除する。この処理は、いわば、キャラクタアイテムを「売却」して、キャラクタアイテムのバトルにおける「強さ」に相当する価値（第１のパラメータ）を、他のアイテムと交換するための価値（第１のポイント）に引き換える要求に対応する処理に相当する。本実施の形態では、この際、キャラクタアイテムがバトルにおいてデッキに含められていたときに、バトルに勝利した際の報酬の量や質の決定に影響する価値（第２のパラメータ）も、他のアイテムと交換するための価値（第２のポイント）に引き換えられる。
【0047】
具体的にこの交換処理部２４は、交換処理の開始指示を、いずれかの端末２から受信すると、当該端末２のユーザＩＤを特定する。そして交換処理部２４は、ユーザ情報保持部２２によって記憶部１２に格納されている、上記ユーザＩＤに関連付けられた情報を参照し、当該ユーザが所持するキャラクタアイテムの一覧を、当該ユーザの端末２に対して送信する。そして当該端末２から価値交換の対象となるキャラクタアイテムの選択を受け入れる。
【0048】
交換処理部２４は、この端末２から価値交換の要求を受けると、選択されたキャラクタアイテムの第１のパラメータを参照し、ユーザデータベースに、上記特定したユーザＩＤに関連づけて保持されているポイントの情報のうち、第１のポイントの所持高を更新する。具体的には、交換処理部２４は、選択されたキャラクタアイテムの第１のパラメータΠに対して、第１のポイントＰを、現在の第１のポイントをＰ０として、
Ｐ＝［Ｐ０＋α・Π］
と更新する。ここで［ｘ］は、ｘに最も近い整数とし、あるいは切り上げをして整数化することを意味し（以下同じ）、αは予め定めた正の定数である。
Ｐ＝［Ｐ０＋α・Π］
と更新する。ここで［ｘ］は、ｘに最も近い整数とし、あるいは切り上げをして整数化することを意味し（以下同じ）、αは予め定めた正の定数である。
【0049】
また交換処理部２４は、選択されたキャラクタアイテムの第２のパラメータを参照し、ユーザデータベースに、上記特定したユーザＩＤに関連づけて保持されているポイントの情報のうち、第２のポイントの所持高を更新する。つまり交換処理部２４は、選択されたキャラクタアイテムの第２のパラメータΘに対して、第２のポイントＱを、現在の第２のポイントをＱ０として、
Ｑ＝［Ｑ０＋β・Θ］
と更新する。ここでβは予め定めた正の定数である。
Ｑ＝［Ｑ０＋β・Θ］
と更新する。ここでβは予め定めた正の定数である。
【0050】
そして交換処理部２４は、価値交換の対象として選択されたキャラクタアイテムを、ユーザデータベースから削除する。
【0051】
ポイント利用処理部２５は、第１、第２のポイントの一部と、ゲームアイテム、あるいは、キャラクタアイテムとを交換する処理を行う。この処理は、いわば、ポイントを消費して、ゲームアイテム等を「購入」する処理に相当する。
【0052】
本実施の形態の一例では、「購入」の対象となるゲームアイテム等の一覧が、サーバ装置１の管理者、つまりサーバ装置１で提供されるサービスの運営者によって生成される。このリストは、第１のポイントにより「購入」可能なゲームアイテム（あるいは、キャラクタアイテム、以下まとめて「アイテム」と称する）の識別情報と、当該アイテムを「購入」するために必要な第１のポイントの量（価格に相当する）とを関連付けて記録した第１のアイテムリストと、第２のポイントにより「購入」可能なアイテムの識別情報と、当該アイテムを「購入」するために必要な第２のポイントの量（こちらも価格に相当する）とを関連付けて記録した第２のアイテムリストとを含む。これらの第１，第２のアイテムリストは、運営者の操作を受けた制御部１１により、記憶部１２に格納される。
【0053】
第１のアイテムリストに含まれるアイテムと、第２のアイテムリストに含まれるアイテムとには互いに重複があってもよいし、共通するアイテムが第１，第２のアイテムリストに含まれなくてもよい。
【0054】
ポイント利用処理部２５は、ユーザの端末２から第１のポイントを使用したアイテムの「購入」の要求を受けると、当該ユーザのユーザＩＤを特定して、特定したユーザＩＤに関連付けられた第１のポイントの所持高の情報を、ユーザデータベースから取得する。またポイント利用処理部２５は、第１のアイテムリストを取得して、当該第１のアイテムリストに含まれるアイテムの一覧を、当該ユーザの端末２に対して送出して、ユーザに提示させる。
【0055】
ポイント利用処理部２５は、ユーザからアイテムの選択を受けると、選択されたアイテムに関連付けて第１のアイテムリストに記録されている、当該アイテムに必要な第１のポイントの量Ｃを取得し、ユーザデータベースから取得した、上記特定したユーザの第１のポイントの所持高Ｐと比較する。
【0056】
ポイント利用処理部２５は、ここで、特定したユーザＩＤに関連付けてユーザデータベースに記録されている第１のポイントの所持高Ｐが、選択されたアイテムに必要な第１のポイントの量Ｃを下回っているときには、「購入」できないものとして、処理を中断する。
【0057】
一方ここで、ユーザの第１のポイントの所持高Ｐが、選択されたアイテムに必要な第１のポイントの量Ｃ以上であれば、ユーザデータベースに格納された、上記特定したユーザＩＤに関連付けられた第１のポイントの所持高Ｐを、現在の所持高から必要な第１のポイントの量Ｃを差し引いて更新し（Ｐ←Ｐ－Ｃ）、選択されたアイテムに固有の所有識別子（アイテムがキャラクタアイテムであればキャラクタ所有識別子であり、アイテムがゲームアイテムであれば、ゲームアイテム所有識別子）を発行して、ユーザデータベースに、特定したユーザＩＤに関連付けて、当該アイテムの識別子や、発行した所有識別子等を記録する。
【0058】
またポイント利用処理部２５は、ユーザの端末２から第２のポイントを使用したアイテムの「購入」の要求を受けると、第１のポイントに係る上記処理と同様、当該ユーザのユーザＩＤを特定して、特定したユーザＩＤに関連付けられた第２のポイントの所持高の情報を、ユーザデータベースから取得する。そしてポイント利用処理部２５は、第２のアイテムリストを取得して、当該第２のアイテムリストに含まれるアイテムの一覧を、当該ユーザの端末２に対して送出して、ユーザに提示させる。
【0059】
ポイント利用処理部２５は、端末２から、当該提示した第２のアイテムリストに含まれるアイテムの選択を受けると、当該選択されたアイテムに関連付けて第２のアイテムリストに記録されている、当該アイテムに必要な第２のポイントの量Ｃを取得し、ユーザデータベースから取得した、上記特定したユーザの第２のポイントの所持高Ｑと比較する。
【0060】
ポイント利用処理部２５は、ここで、特定したユーザＩＤに関連付けてユーザデータベースに記録されている第２のポイントの所持高Ｑが、選択されたアイテムに必要な第２のポイントの量Ｃを下回っているときには、「購入」できないものとして、処理を中断する。
【0061】
一方ここで、ユーザの第２のポイントの所持高Ｑが、選択されたアイテムに必要な第２のポイントの量Ｃ以上であれば、ユーザデータベースに格納された、上記特定したユーザＩＤに関連付けられた第２のポイントの所持高Ｑを、現在の所持高から必要な第２のポイントの量Ｃを差し引いて更新し（Ｑ←Ｑ－Ｃ）、選択されたアイテムに固有の所有識別子（アイテムがキャラクタアイテムであればキャラクタ所有識別子であり、アイテムがゲームアイテムであれば、ゲームアイテム所有識別子）を発行して、ユーザデータベースに、特定したユーザＩＤに関連付けて、当該アイテムの識別子や、発行した所有識別子等を記録する。
【0062】
［動作］
本実施の形態は、以上の構成を基本的に備えており、次のように動作する。本実施の形態では、サーバ装置１の制御部１１が、キャラクタアイテムを用いたサービスをユーザに提供する。本実施の形態の例では、サーバ装置１が、ユーザごとにユーザの識別情報（ユーザＩＤ）、ユーザの名称、パスワード等の認証情報、ユーザが所持するキャラクタアイテムの情報（キャラクタアイテム情報）、第１、第２のポイントの残高の情報を含むポイント情報、キャラクタアイテム以外のゲームアイテムの情報等を互いに関連付けて、ユーザデータベースとして記憶部１２に保持している。
本実施の形態は、以上の構成を基本的に備えており、次のように動作する。本実施の形態では、サーバ装置１の制御部１１が、キャラクタアイテムを用いたサービスをユーザに提供する。本実施の形態の例では、サーバ装置１が、ユーザごとにユーザの識別情報（ユーザＩＤ）、ユーザの名称、パスワード等の認証情報、ユーザが所持するキャラクタアイテムの情報（キャラクタアイテム情報）、第１、第２のポイントの残高の情報を含むポイント情報、キャラクタアイテム以外のゲームアイテムの情報等を互いに関連付けて、ユーザデータベースとして記憶部１２に保持している。
【0063】
ユーザが端末２を操作してサーバ装置１にアクセスすると、サーバ装置１は、ユーザをユーザ名とパスワード等で認証する。そして認証に成功すると、セッション識別子を発行して、以下、このユーザの端末２との通信を行う際には、セッションの期限が切れるまで（ユーザの端末２との通信が行われなくなってから所定の時間が経過する等によりセッションの期限が切れるまで）は、このセッション識別子を送受することで、サーバ装置１は、どのユーザの端末２からの通信が行われているかを判断する。
【0064】
サーバ装置１は、例えばユーザがバトルゲームを行うことを選択すると、当該ユーザの端末２に対して、ユーザが所持するキャラクタアイテム（当該ユーザの識別情報に関連付けてユーザデータベースに保持されているキャラクタ所持識別子で識別されるキャラクタアイテム）の一覧を提示し、デッキの作成を行わせる。
【0065】
ユーザは、端末２に表示されたキャラクタアイテムの一覧から、少なくとも一体のキャラクタアイテムを選択してデッキを生成し、バトルの開始を指示する。この指示はサーバ装置１に送信される。サーバ装置１は、バトルの開始の指示を受けると、ユーザが生成したデッキに含まれる、各キャラクタアイテムの体力ポイント（ＨＰ）を、それぞれのキャラクタアイテムごとに設定された第１のパラメータ（レベル）に応じた値に設定する。
【0066】
そしてサーバ装置１は、バトルゲームのステージに応じて予め定められた方法で決定した敵キャラクタの図柄や、デッキに含まれるキャラクタアイテムの図柄等を含むゲーム画面を生成して、ユーザの端末２に表示させる。以下、上記デッキに含まれるキャラクタアイテムが順次「攻撃」し、当該攻撃したキャラクタアイテムに設定されている攻撃ポイント（ＢＰ）に基づいて、攻撃された敵キャラクタの体力ポイント（ＨＰ）を減少させる処理等（バトルゲームの処理）が行われる。
【0067】
そしてバトルの場に用意された敵キャラクタがすべて退場すると、サーバ装置１は、ユーザ側の勝利ということとして、デッキに含まれる少なくとも一つのキャラクタアイテムに設定された第２のパラメータ（ラック）に応じて「報酬」を決定する。ここで「報酬」は、ゲームアイテムやキャラクタアイテム等（アイテム）であり、「報酬」となったアイテム等は、当該勝利したユーザの識別情報に関連付けて、ユーザデータベースに記録される。これにより、ユーザに対してアイテムの付与が行われる。
【0068】
このように、本実施の形態の例では、バトルの際の有利・不利は、第１のパラメータによって決定される。そこでユーザは、デッキに含めるキャラクタアイテムを「強化」する（その第１のパラメータを上昇させる）ため、サーバ装置１に、「合成」の処理を行わせることとなる。
【0069】
またバトルに勝利した際の「報酬」は、第２のパラメータに応じて決定されるため、報酬の量あるいは質を上昇させることを希望するユーザは、第２のパラメータを上昇させるために、サーバ装置１に、「合成」の処理を行わせる。なお、ここでは既に述べた例のように、同じ識別子のキャラクタアイテム同士を「合成」しない限り、第２のパラメータは上昇しないものとする。従って、入手しにくいキャラクタアイテムほど、この第２のパラメータの上昇が困難となるように設定されている。換言すれば、第２のパラメータの上昇の難易度は、ここでの例では、キャラクタアイテムの入手のしやすさに応じて変化することとなっている。
【0070】
具体的にユーザが、合成処理の開始指示を送信（例えば端末２に表示されたゲーム画面から「合成」メニューを選択する）と、この指示を受けたサーバ装置１が、当該指示を送信した端末２を操作するユーザのユーザＩＤを特定する。そしてサーバ装置１は、記憶部１２に格納されているユーザデータベースから、ここで特定したユーザＩＤに関連付けられたキャラクタ所持識別子の一覧（キャラクタアイテムの一覧）を取得し、当該キャラクタアイテムの図柄の情報とともに当該ユーザの端末２に対して送信して、所持しているキャラクタアイテムの一覧を端末２に表示させる。
【0071】
ユーザは、端末２の画面から、合成の対象とする（強化する）キャラクタアイテムを選択する。端末２は、当該選択されたキャラクタアイテムのキャラクタ所有識別子をサーバ装置１に送信する。そしてサーバ装置１では、端末２から合成の対象となるキャラクタアイテムの選択を受け入れる。
【0072】
サーバ装置１は、次に合成素材を指定するようユーザに求める表示を端末２に対して行うよう指示する。ユーザは、この指示に従って端末２が表示する画面において、先に選択したキャラクタアイテムとは、キャラクタ所有識別子が異なるキャラクタアイテム（同じ種類、つまり同じ識別子のキャラクタアイテムであっても、キャラクタ所有識別子が異なればよい）、あるいはゲームアイテムの選択を行う。この選択は一つとは限らず、複数選択されてもよい。
【0073】
端末２は、ユーザの選択完了の操作を受けると、当該選択されたアイテムのキャラクタ所有識別子や、ゲームアイテム所有識別子をサーバ装置１に対して送出する。サーバ装置１は、先に特定したユーザＩＤに関連付けられているキャラクタアイテムまたはゲームアイテムであって、端末２が送出したキャラクタ所有識別子または、ゲームアイテム所有識別子に関連付けられたアイテム（合成素材となったアイテム）の情報を、ユーザデータベースから読み出す。
【0074】
またサーバ装置１は、合成対象として指定されたキャラクタアイテムの識別子に関連付けて記憶部１２に格納されている第１のパラメータまたは第２のパラメータを読み出し、合成素材となったキャラクタアイテムのパラメータやゲームアイテムに関連して設定されているパラメータの上昇値の情報を参照して、これら第１のパラメータまたは第２のパラメータの少なくとも一方を更新する。
【0075】
ここで、識別子が「Ｘ」であり、キャラクタ所有識別子が「１」のキャラクタアイテム（「レッドモンスター」）が合成の対象としてユーザにより選択されたものとし、また合成素材として、別のキャラクタ所有識別子「２」が設定された、識別子が「Ｘ」であるキャラクタアイテム（「レッドモンスター」）と、識別子が「Ｙ」であり、キャラクタ所有識別子が「３」であるキャラクタアイテム（「ブルーモンスター」）とが選択されたものとする。なお、識別子「Ｘ」の「レッドモンスター」は、合成等の処理が行われない時点（もともとの）第１のパラメータが「２００」、第２のパラメータが「２」であるものとし、識別子「Ｙ」の「ブルーモンスター」は、合成等の処理が行われない時点（もともとの）第１のパラメータが「１００」、第２のパラメータが「１」であるものとする。
【0076】
そしてここではキャラクタ所有識別子が「１」の「レッドモンスター」については、既に、過去に行われた合成処理の結果、第１のパラメータが「３００」、第２のパラメータが「４」となっているものとする。またキャラクタ所有識別子が「２」の「レッドモンスター」については、既に、過去に行われた合成処理の結果、第１のパラメータが「３００」、第２のパラメータが「２」となっているものとする。
【0077】
サーバ装置１は、この例においては、合成対象となったキャラクタアイテムの合成前の第１のパラメータ「３００」に、合成素材として選択されたアイテムの第１のパラメータの上昇分（ここでは第１のパラメータそのものとするがこれに限られない）を累算し、合成後の第１のパラメータを、
３００＋（３００＋１００）＝７００
（なお、合成素材分の累算が見やすいように、ここでは括弧書きにより累算部分を明示している）と求める。
３００＋（３００＋１００）＝７００
（なお、合成素材分の累算が見やすいように、ここでは括弧書きにより累算部分を明示している）と求める。
【0078】
一方、サーバ装置１は、合成素材として指定されたアイテムのうちから、第２のパラメータに係る更新条件を満足する合成素材を抽出する。ここでは、合成の対象となったキャラクタアイテムの識別子と、合成素材としたキャラクタアイテムの識別子とが一致していることを更新条件としているので、合成の対象であるアイテムの識別子「Ｘ」と同じ識別子「Ｘ」のアイテムを抽出する。そしてサーバ装置１は、抽出したアイテム（抽出できなかった場合はここで合成の処理を終了する）の第２のパラメータの上昇分（ここでは第２のパラメータそのものとするがこれに限られない）を累算して、合成対象となったキャラクタアイテムの合成前の第２のパラメータ「４」に加算し、合成後の第２のパラメータを、
４＋（２）＝６
と求める。
４＋（２）＝６
と求める。
【0079】
サーバ装置１は、ユーザデータベースに格納され、上記特定されたユーザＩＤに関連付けられている、合成の対象となったキャラクタアイテム（キャラクタ所有識別子が「１」のアイテム）の第１のパラメータを、先に求めた値「７００」に設定して更新し、また第２のパラメータを「６」に設定して更新する。
【0080】
そしてサーバ装置１は、ユーザデータベースから、合成要求を行ったユーザのユーザＩＤに関連付けられて記録されている、合成素材としたキャラクタアイテムや、ゲームアイテム（ここでの例では、キャラクタ所有識別子が「２」、「３」のキャラクタアイテム）を削除する。
【0081】
さらにユーザは、不要となったキャラクタアイテムを整理するため、あるいは他のキャラクタアイテムやゲームアイテムの取得のために、キャラクタアイテムを「売却」して、ポイントに交換する、価値交換を行う。本実施の形態では、価値交換の態様として、キャラクタアイテムの第１のパラメータを第１のポイントに交換するとともに、第２のパラメータを第２のポイントに交換する。ここでの交換のレートは１：１ではなく、それぞれ所定の比率で交換が行われるものとする。
【0082】
ユーザが価値交換の処理の開始指示を送信（例えば端末２に表示されたゲーム画面から「売却」メニューを選択する）と、この指示を受けたサーバ装置１が、当該指示を送信した端末２を操作するユーザのユーザＩＤを特定する。そしてサーバ装置１は、記憶部１２に格納されているユーザデータベースから、ここで特定したユーザＩＤに関連付けられたキャラクタ所持識別子の一覧（キャラクタアイテムの一覧）を取得し、当該キャラクタアイテムの図柄の情報とともに当該ユーザの端末２に対して送信して、所持しているキャラクタアイテムの一覧を端末２に表示させる（図５（ａ））。
【0083】
ユーザは、端末２の画面から、価値交換の対象とする（売却する）キャラクタアイテムを少なくとも一つ選択する（図５（ａ）、Ｍのｍ１，ｍ２を選択したとする）。端末２は、当該選択されたキャラクタアイテムのキャラクタ所有識別子をサーバ装置１に送信する。そしてサーバ装置１では、価値交換の対象となるキャラクタアイテムの指定と価値交換の要求とをユーザの端末２から受け入れる。
【0084】
サーバ装置１は、上記特定したユーザＩＤに関連付けられて記録されているキャラクタアイテムのうち、上記指定されたキャラクタ所有識別子（複数指定された場合はそれぞれ）に関連付けられたキャラクタアイテムをユーザデータベースから検索するとともに、上記特定したユーザＩＤに関連付けて保持されている第１，第２のポイントの所持高Ｐ，Ｑを取得する。ここでは、価値交換の対象として指定されたキャラクタ所有識別子が２つあり、それぞれに関連付けられている第１のパラメータ（合成等によって更新されている場合がある）ΠがΠ１＝２００，Π２＝１００であり、第２のパラメータ（こちらも合成等によって更新されている場合がある）ΘがΘ１＝２，Θ２＝５であるものとする。
【0085】
サーバ装置１は、上記特定したユーザＩＤに関連付けて保持されている第１のポイントの所持高Ｐを、
Ｐ←［Ｐ＋α・Σ（Π）］
として更新する。ここでΣ（ｘ）は、ｘを累算することを意味する。具体的にここではα＝０．５であるとし、価値交換時に所持していた第１のポイントの所持高Ｐ＝１０００（図５（ａ）のＰ）であったとすると、サーバ装置１は、
［１０００＋０．５×（２００＋１００）］＝１１５０
を求め、上記特定したユーザＩＤに関連付けて保持されている第１のポイントの所持高Ｐを１１５０に設定して更新する（図５（ｂ）、Ｐ）。
Ｐ←［Ｐ＋α・Σ（Π）］
として更新する。ここでΣ（ｘ）は、ｘを累算することを意味する。具体的にここではα＝０．５であるとし、価値交換時に所持していた第１のポイントの所持高Ｐ＝１０００（図５（ａ）のＰ）であったとすると、サーバ装置１は、
［１０００＋０．５×（２００＋１００）］＝１１５０
を求め、上記特定したユーザＩＤに関連付けて保持されている第１のポイントの所持高Ｐを１１５０に設定して更新する（図５（ｂ）、Ｐ）。
【0086】
またサーバ装置１は、上記特定したユーザＩＤに関連付けて保持されている第２のポイントの所持高Ｑを、
Ｑ←［Ｑ＋β・Σ（Θ）］
として更新する。具体的にここではβ＝１００であるとし、価値交換時に所持していた第２のポイントの所持高Ｑ＝６０００であったとすると（図５（ａ）のＱ）、サーバ装置１は、
［６０００＋１００×（２＋５）］＝６７００
を求め、上記特定したユーザＩＤに関連付けて保持されている第２のポイントの所持高Ｑを６７００に設定して更新する（図５（ｂ）、Ｑ）。
Ｑ←［Ｑ＋β・Σ（Θ）］
として更新する。具体的にここではβ＝１００であるとし、価値交換時に所持していた第２のポイントの所持高Ｑ＝６０００であったとすると（図５（ａ）のＱ）、サーバ装置１は、
［６０００＋１００×（２＋５）］＝６７００
を求め、上記特定したユーザＩＤに関連付けて保持されている第２のポイントの所持高Ｑを６７００に設定して更新する（図５（ｂ）、Ｑ）。
【0087】
そしてサーバ装置１は、価値交換の対象として選択されたキャラクタアイテムのキャラクタ所有識別子と、上記特定されたユーザＩＤとに関連付けられたキャラクタアイテムを、ユーザデータベースから削除する。この結果、端末２にてユーザが所持するキャラクタアイテムの一覧を表示させると、当該価値交換の対象としたキャラクタアイテムは存在しない状態となる（図５（ｂ）、Ｍ）。
【0088】
このように本実施の形態の例によると、ユーザは、売却の処理によって、所持している複数のキャラクタアイテムのそれぞれに設定されている第１のパラメータの累算の結果に応じて（つまりそれぞれを各々個別に売却したときの累算結果によって）第１のポイントの所持高を更新でき、同様に、所持している複数のキャラクタアイテムのそれぞれに設定されている第２のパラメータの累算の結果に応じて（つまりそれぞれを各々個別に売却したときの累算結果によって）第２のポイントの所持高を更新できる。つまり売却の処理において合成の際と同様に各パラメータが累算されるので、売却の対象とするアイテムについては必ずしも事前に合成しておく必要はない。
【0089】
本実施の形態ではこのように価値交換（売却）に際しての手間が簡略化されることで、ユーザのキャラクタアイテムの整理が支援される。そしてユーザは、この売却によって得られた第１，第２のポイントを、後に、他のアイテムの「購入」のために使用できるようになる。
【0090】
［売却条件］
ここまでの例では、価値交換の処理において、特段の条件なく、価値交換の対象としたキャラクタアイテムの第２のパラメータに基づいて、第２のポイントを更新することとしていたが、本実施の形態はこれに限られない。
ここまでの例では、価値交換の処理において、特段の条件なく、価値交換の対象としたキャラクタアイテムの第２のパラメータに基づいて、第２のポイントを更新することとしていたが、本実施の形態はこれに限られない。
【0091】
例えば価値交換の対象としたキャラクタアイテムの第１のパラメータについては無条件に第１のポイントの更新に用いるものの、第２のパラメータについては条件（売却条件）を課してもよい。
【0092】
ここで売却条件は、価値交換の対象とするキャラクタアイテムの第２のパラメータが、予め定めたしきい値を超えていることを条件としてもよい。例えばこのしきい値を「２」としておく場合、価値交換の対象となるキャラクタアイテムが２体あり、そのいずれも識別子が「Ｘ」（同じ種類）であっても、そのうちのキャラクタアイテムの一体については第２のパラメータが上記しきい値を下回る「１」であり、他方は上記しきい値を上回る「３」であったとする。
【0093】
このとき、サーバ装置１は、価値交換を指示したユーザのユーザＩＤに関連付けて保持されている第２のポイントの所持高Ｑを、上述のように
Ｑ←［Ｑ＋β・Σ（Θ）］
で更新するが、この累算の際に、上記しきい値を上回ることを条件とする。従って、ここでの例では、β＝１００であるとし、価値交換時に所持していた第２のポイントの所持高Ｑ＝６０００であったとすると、サーバ装置１は、このユーザの第２のポイントの所持高を、
［６０００＋１００×（３）］＝６３００
として更新する。
Ｑ←［Ｑ＋β・Σ（Θ）］
で更新するが、この累算の際に、上記しきい値を上回ることを条件とする。従って、ここでの例では、β＝１００であるとし、価値交換時に所持していた第２のポイントの所持高Ｑ＝６０００であったとすると、サーバ装置１は、このユーザの第２のポイントの所持高を、
［６０００＋１００×（３）］＝６３００
として更新する。
【0094】
このように、サーバ装置１は、上記しきい値を下回るキャラクタアイテムの第２のパラメータは考慮されないよう制御してもよい。
【0095】
［レアリティ］
また、売却条件はキャラクタアイテムに設定された別の情報に基づいて判断されてもよい。例えば各キャラクタアイテムには、レア度（希少さの程度）を表すパラメータ（レアリティ）が設定されてもよい。このレアリティは、希少さの程度が低いものから順に、「１」から「６」まで設定されているものとする（それぞれ「星１」ないし「星６」と呼ぶ）。
また、売却条件はキャラクタアイテムに設定された別の情報に基づいて判断されてもよい。例えば各キャラクタアイテムには、レア度（希少さの程度）を表すパラメータ（レアリティ）が設定されてもよい。このレアリティは、希少さの程度が低いものから順に、「１」から「６」まで設定されているものとする（それぞれ「星１」ないし「星６」と呼ぶ）。
【0096】
この場合、キャラクタデータベースには、キャラクタアイテムの種類ごとに、当該種類ごとに固有に設定されているキャラクタの識別子と、キャラクタアイテムの名称と、キャラクタアイテムの図柄と、付帯的な情報（「属性」等の情報）と、初期の（合成処理等を行う前の初期状態での）第１のパラメータ（レベル）及び第２のパラメータ（ラック）を含むパラメータ値の情報と、に加え、レアリティの情報が互いに関連付けて保持される。
【0097】
そしてこの場合は、売却条件として既に例示した、第２のパラメータのしきい値に係る条件に代えて、あるいはそれに加えて（加重条件として）、価値交換の対象としたキャラクタのレアリティが予め定めたレアリティしきい値（レアリティの基準、例えば「星３」）を超えている、との条件を課してもよい。
【0098】
この場合、例えばこのレアリティしきい値を「星３」としておく場合、ユーザが指定した、価値交換の対象となるキャラクタアイテムが２体あり、そのうちのキャラクタアイテムの一体については、レアリティが「星２」で上記レアリティしきい値を下回り、第２のパラメータは「３」であり、他方はレアリティが「星４」で上記レアリティしきい値を上回り、第２のパラメータは「２」であったとする。
【0099】
このとき、サーバ装置１は、価値交換を指示したユーザのユーザＩＤに関連付けて保持されている第２のポイントの所持高Ｑを、上述のように
Ｑ←［Ｑ＋β・Σ（Θ）］
で更新するが、この累算の際に、上記レアリティしきい値を上回ることを条件とする。従って、ここでの例では、β＝１００であるとし、価値交換時に所持していた第２のポイントの所持高Ｑ＝６０００であったとすると、サーバ装置１は、このユーザの第２のポイントの所持高を、ここでの例では、「星４」のレアリティを有するキャラクタアイテムの第２のパラメータのみに基づいて、
［６０００＋１００×（２）］＝６３００
として更新する。
Ｑ←［Ｑ＋β・Σ（Θ）］
で更新するが、この累算の際に、上記レアリティしきい値を上回ることを条件とする。従って、ここでの例では、β＝１００であるとし、価値交換時に所持していた第２のポイントの所持高Ｑ＝６０００であったとすると、サーバ装置１は、このユーザの第２のポイントの所持高を、ここでの例では、「星４」のレアリティを有するキャラクタアイテムの第２のパラメータのみに基づいて、
［６０００＋１００×（２）］＝６３００
として更新する。
【0100】
［レアリティに応じた割合］
また、ここまでの説明では、第２のパラメータと第２のポイントとの交換レートβは、定数であるものとしたが、本実施の形態はこれに限られない。例えばこの交換レートβは、価値交換の対象としたキャラクタアイテムのレアリティに応じて調整されてもよい。一例として、
「星１」はβ＝０（売却条件を満足しないことと同義）、
「星２」はβ＝０（売却条件を満足しないことと同義）、
「星３」はβ＝１０、
「星４」はβ＝１００、
…
というようにレアリティが上昇するほど、交換レートを高くするようにしてもよい。あるいは、この逆に、レアリティが上昇するほど交換レートが低くなるようにしてもよい。例えば、
「星１」はβ＝０（売却条件を満足しないことと同義）、
「星２」はβ＝０（売却条件を満足しないことと同義）、
「星３」はβ＝１０００、
「星４」はβ＝１００、
…
としてもよい。レアリティが低いキャラクタアイテムに関連付けられる第２のパラメータが比較的低いものとなる場合は、このような調整が有効な場合もあり得る。
また、ここまでの説明では、第２のパラメータと第２のポイントとの交換レートβは、定数であるものとしたが、本実施の形態はこれに限られない。例えばこの交換レートβは、価値交換の対象としたキャラクタアイテムのレアリティに応じて調整されてもよい。一例として、
「星１」はβ＝０（売却条件を満足しないことと同義）、
「星２」はβ＝０（売却条件を満足しないことと同義）、
「星３」はβ＝１０、
「星４」はβ＝１００、
…
というようにレアリティが上昇するほど、交換レートを高くするようにしてもよい。あるいは、この逆に、レアリティが上昇するほど交換レートが低くなるようにしてもよい。例えば、
「星１」はβ＝０（売却条件を満足しないことと同義）、
「星２」はβ＝０（売却条件を満足しないことと同義）、
「星３」はβ＝１０００、
「星４」はβ＝１００、
…
としてもよい。レアリティが低いキャラクタアイテムに関連付けられる第２のパラメータが比較的低いものとなる場合は、このような調整が有効な場合もあり得る。
【0101】
このように本実施の形態では、サーバ装置１は、価値交換の対象としたキャラクタアイテムに係る第２のパラメータと、当該キャラクタアイテムの種類に関連付けられたレア度の情報とに基づいて、第２のポイントの所持高を更新してもよい。
【0102】
［レアリティが合成等によって変化する場合］
また本実施の形態において、サーバ装置１は、合成処理においてキャラクタアイテムを合成する際、予め定めた条件に基づいて、レアリティの値も更新してもよい。なお、このようにレアリティの値が更新される場合、ユーザデータベースに、キャラクタアイテムのキャラクタ所有識別子に関連付けて、そのキャラクタアイテムのレアリティの情報を記録しておく。
また本実施の形態において、サーバ装置１は、合成処理においてキャラクタアイテムを合成する際、予め定めた条件に基づいて、レアリティの値も更新してもよい。なお、このようにレアリティの値が更新される場合、ユーザデータベースに、キャラクタアイテムのキャラクタ所有識別子に関連付けて、そのキャラクタアイテムのレアリティの情報を記録しておく。
【0103】
この例では、価値交換の際に参照するレアリティの情報は、ユーザデータベースに記録されたレアリティの情報（合成等によって更新されたレアリティの情報）であってもよいし、更新される前のレアリティの情報（キャラクタデータベースに記録されている、もともとのレアリティの情報）であってもよい。
【0104】
後者のように、価値交換の処理の際には、キャラクタデータベースに記録されている、もともとのレアリティの情報を参照する場合であって、レアリティに応じた交換レートを用いる場合、例えばもともとのレアリティが「星２」であったキャラクタアイテムは、ユーザの合成の処理によってレアリティが「星３」となっていても、上記の例のように、…「星２」はβ＝０（売却条件を満足しないことと同義）、「星３」はβ＝１０、…などと設定されていれば、当該キャラクタアイテムについてはβ＝０として（「星２」のキャラクタアイテムであるとして）処理されることとなる。
【0105】
［交換レートをランダムに変化させる場合］
なお、交換レートは、予め指定された範囲内でランダムに決定されてもよい。例えば交換レートβはサーバ装置１が価値変換の処理を行うごとに、「１０」ないし「１０００」の間でランダムに（あるいは「１０」，「１００」，「１０００」のうちからランダムに）決定されてもよい。
なお、交換レートは、予め指定された範囲内でランダムに決定されてもよい。例えば交換レートβはサーバ装置１が価値変換の処理を行うごとに、「１０」ないし「１０００」の間でランダムに（あるいは「１０」，「１００」，「１０００」のうちからランダムに）決定されてもよい。
【0106】
またレアリティごとに交換レートを異ならせる場合は、レアリティごとに範囲を定めることとして、
「星１」はβ＝０（売却条件を満足しないことと同義）、
「星２」はβ＝０（売却条件を満足しないことと同義）、
「星３」はβ＝１０以上９０未満、
「星４」はβ＝１００以上９００未満、
…
などとして定め、サーバ装置１が上記範囲内で、価値変換の処理を行うごとにランダムに（あるいは上述のように所定の段階のうちからランダムに）決定してもよい。
「星１」はβ＝０（売却条件を満足しないことと同義）、
「星２」はβ＝０（売却条件を満足しないことと同義）、
「星３」はβ＝１０以上９０未満、
「星４」はβ＝１００以上９００未満、
…
などとして定め、サーバ装置１が上記範囲内で、価値変換の処理を行うごとにランダムに（あるいは上述のように所定の段階のうちからランダムに）決定してもよい。
【0107】
このようにすると、合成の際とは異なり、価値交換の場合には交換レートが変化することとなるので、娯楽性が向上することとなる。
【符号の説明】
【0108】
１ サーバ装置、２ 端末、１１ 制御部、１２ 記憶部、１３ 通信部、２１ サービス提供部、２２ ユーザ情報保持部、２３ 合成処理部、２４ 交換処理部、２５ ポイント利用処理部。
【図1】
【図2】
【図3】
【図4】
【図5】