JP7307352B2 - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Description

本発明は、情報処理装置、情報処理方法、及びプログラムに関する。

ゲームをプレイするユーザの間で、ゲーム内で使用可能なキャラクタやアイテム等のようなゲーム媒体を交換したり売買したりすることは、既に知られている（例えば、特許文献１参照）。

特開２０１４－８３６５号公報

ユーザ間の取引として、これまでに行われてきたゲーム媒体の取引以外に、新たな形態の取引が可能となれば、ユーザ間での交流を活性化させることができ、結果として、より多くのユーザをゲームに誘導することができるものと期待される。

そこで、本発明は、ゲームのユーザ間で新たな形態の取引を可能とする情報処理装置、情報処理方法、及びプログラムを提供することを課題とする。

本発明者の一態様に係る情報処理装置は、第１ユーザがゲームにて成長させる第１ゲーム媒体の成長パラメータについて、第１ユーザから譲渡の申し出を受け付け、且つ、第２ユーザから譲受の申し出を受け付ける受付部と、受付部が第１ユーザ及び第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、第２ユーザがゲームにて成長させる第２ゲーム媒体の成長パラメータを、第２ユーザが第１ユーザから譲受した成長パラメータに応じて変更するパラメータ変更部と、を備えることを特徴とする。

本発明の一態様によれば、ゲーム媒体の成長パラメータをユーザ間で取り引きすることができるので、ユーザの間での新たな形態の取引を実現することができる。

装備品の成長パラメータについての説明図である。 ユーザ間での成長パラメータの取引についての説明図である。 本発明の一実施形態に係る情報処理装置及び各ユーザの端末を含むシステム全体を示す概念図である。 ユーザ端末の機能についての説明図である。 本発明の一実施形態に係る情報処理装置に備えられた複数の機能部を示すブロック図である。 記憶部に記憶されるユーザデータの一例を示す図である。 記憶部に記憶される装備品データの一例を示す図である。 記憶部に記憶される取引データの一例を示す図である。 記憶部に記憶されるレベル強化用データの一例を示す図である。 記憶部に記憶されるランク値強化用データの一例を示す図である。 ゲーム進行フローの流れを示す図であり、装備品のレベル又はランク値を変更させる流れを示す。 パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがレベルである場合の流れを示す（その１）。 パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがレベルである場合の流れを示す（その２）。 パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがランク値である場合の流れを示す（その１）。 パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがランク値である場合の流れを示す（その２）。 第１の変形例に係る情報処理装置の機能を示す図である。 第１の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す（その１）。 第１の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す（その２）。 第２の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す（その１）。 第２の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す（その２）。

以下、本発明の情報処理装置、情報処理方法及びプログラムについて具体的な実施形態を挙げて説明する。ただし、以下に説明する実施形態は、本発明の理解を容易にするために挙げた一例にすぎず、本発明を限定するものではない。すなわち、本発明は、その趣旨を逸脱しない限りにおいて、以下に説明する実施形態から変更又は改良され得る。また、当然ながら、本発明には、その等価物が含まれる。

また、以下の説明の中で参照される図面が示す画面例も一例に過ぎず、画面の構成例、表示される情報の内容、及びＧＵＩ（Graphical User Interface）等は、システム設計の仕様及びユーザの好み等に応じて自由に設計することができ、また適宜変更し得る。

さらに、本明細書において、「装置」とは、単独で所定の機能を発揮する一つの装置のみ、互いに分離されているものの所定の機能を発揮するために協働する複数の装置をも含むものとする。

さらにまた、本明細書において、「ユーザ」とは、本発明の情報処理装置のユーザであり、具体的には、本発明の情報処理装置によって提供されるサービスの利用者である。なお、ユーザは、特に断る場合を除き、個人であることとするが、複数人のグループであってもよい。

［本発明の一実施形態に係るゲームについて］
本発明の一実施形態（以下、本実施形態という。）に係る情報処理装置の説明に先立ち、当該情報処理装置のユーザがプレイ可能なゲームについて説明する。

ゲームは、ユーザがゲームプレイ用の端末を操作してプレイするコンテンツであり、詳しくは、データ通信を利用したオンラインゲームである。オンラインゲームは、ウェブブラウザを利用したブラウザゲーム、ＳＮＳ（Social Networking Service）上で提供されるソーシャルゲーム、及び、ストリーミング配信されるクラウドゲーム等が含まれ得る。また、モバイルゲーム等のように専用のアプリケーションソフトをダウンロードしてプレイ可能なゲームもオンラインゲームに含まれ得る。さらに、オンラインゲームには、プレイバイウェブ（ＰＢＷ）等の定期更新型オンラインゲームも含まれ得る。

なお、ゲームは、複数人のユーザが同時に同じゲームをプレイすることが可能な多人数参加型のゲームでもよく、あるいは一個人が単独プレイする形式のゲームでもよい。また、ゲームは、後述するゲーム媒体のパラメータがゲームの進行具合に応じて変化する内容のものであればよく、その種類（ジャンル）は特に限定されない。

ユーザは、ゲーム内のイベント（以下では、ゲーム内イベントともいう。）をプレイすることでゲームを進行させることができる。ゲーム内イベントは、ゲーム中でプレイ可能な要素であり、例えば、敵又は対戦相手との勝負、クリアすることが目的でプレイされるステージやクエスト、及び、アイテムを入手するための抽選等である。

ユーザは、ゲームを進行させる上でゲーム媒体を使用する。ゲーム媒体は、ユーザがゲーム内で使用可能なキャラクタ、アイテム、及び装備品等である。キャラクタは、ゲーム内においてユーザによって操作され、又はユーザの指示に応じてゲーム内で動作するプレイングキャラクタ、及び、プレイングキャラクタを支援するサポートキャラクタを含む。アイテムは、ゲームを有利に進める等の目的のためにゲーム内で使用される物資であり、使用によって、その種類に応じた効果が付与される。装備品は、アイテムの一例であり、キャラクタに装着されることでキャラクタの能力値を変化させることができる。

なお、「ゲーム媒体を使用する」とは、入手したゲーム媒体をゲーム内で使用してゲームを進行させることを意味する。ゲーム媒体がキャラクタである場合には、ゲーム内で当該キャラクタを操作したり、当該キャラクタに対して指示又は命令を与えて、その指示又は命令に従った行動を当該キャラクタに行わせたりすることが「使用」に該当する。また、ゲーム媒体がアイテムである場合には、ゲーム内で当該アイテムを使用（消費）することにより、その効果をゲーム内で発動させることが「使用」に該当する。また、ゲーム媒体が装備品である場合には、当該装備品をキャラクタ（具体的には、ユーザが操作するキャラクタ）に装着させ、そのキャラクタを操作してゲームを進めることが「使用」に該当する。

上述した各種のゲーム媒体の使用権限は、ゲーム内で各ゲーム媒体を入手したユーザに対して設定される。ユーザは、使用権限を有するゲーム媒体をゲーム内で使用することができる。なお、以下では、ゲーム媒体の使用権限を保有することを、便宜的に「ゲーム媒体を所持する」と表現することとする。

ユーザがゲーム媒体を新たに入手する手段は、特に限定されず、例えば、ゲーム内の店舗でゲーム内通貨を支払って購入すること、所定の敵を倒したり所定のクエストをクリアしたりした場合の報酬として一定の確率で獲得すること、及び、抽選にて当選した際の景品として獲得すること等が挙げられる。また、ユーザは、不要なゲーム媒体をゲーム内で売却又は廃棄することができる。さらに、ユーザは、所持するキャラクタや装備品に対して進化用のアイテムを利用する等して、そのゲーム媒体を進化させることができる。進化とは、あるキャラクタや装備品を別の種類のゲーム媒体に変貌させることである。売却又は廃棄され、あるいは進化させたゲーム媒体の使用権限は、消失し、当該ゲーム媒体の使用が不可能となる。

本実施形態において、ゲームには複数種類のゲーム媒体が用意されており、各ゲーム媒体は、その種類に応じた区分によって分類される。区分は、例えば、ゲーム媒体のレア度に基づいて設定され、レア度は、ゲームにおけるゲーム媒体の入手困難性を表す指標であり、ゲーム内で所定のイベントをクリアした場合に入手することができる確率（ドロップ率）に応じて決められる。各ゲーム媒体は、区分１～区分Ｘ（Ｘは２以上の自然数）のいずれかに分類され、区分の番号が大きいゲーム媒体であるほど、レア度が高いゲーム媒体であることを意味する。

また、各ユーザは、ゲームにて、自分が所持するゲーム媒体を成長させることができる。成長とは、ゲーム媒体の性能や能力、サイズや外観、及び運気や人気その他のステータスを向上、強化、良化及び生育させることであり、具体的には後述の成長パラメータを上げることである。また、成長には、一時的に成長パラメータが下がるケースが含まれる。
なお、以下では、「成長」の一態様として、ゲーム媒体を強化させるケースを例に挙げて説明することとする。

ゲーム媒体には、その性質及び能力等に応じた成長パラメータが設定されている。例えば、ゲーム媒体である装備品には、図１に示すように、レベル及びランク値が成長パラメータとして設定されている。図１は、装備品のレベル及びランク値の現在値を示す画面例である。

レベル及びランク値は、ゲーム内で強化する（成長させる）ことにより上昇し、これらのパラメータが上昇するほど、装備品の性能（強化度）が増加し、使用する装備品の強化度が高いほど、ユーザは、ゲームを有利に進めることができる。装備品の強化度は、レベルに応じた強化度に、ランク値に応じた強化度を合算した値である。なお、レベル及びランク値は、整数値で表されて離散的に（例えば＋１ずつ）上昇する値でもよく、あるいは、連続量で表されて数値ゲージのように連続的に上昇する値でもよい。

装備品のレベルは、その入手時点では初期値（例えば、レベル１）に設定されており、装備品に対して付与される経験値の累計値に応じて上昇する。経験値は、ユーザがゲーム内イベントをクリアすることで装備品に対して加算される。例えば、装備品を使用してゲーム内に出現する敵を倒したり、あるいは装備品を使用した状態で所定のステージを通過したりする等と、倒した敵や通過したステージ等に応じた経験値が当該装備品に対して加算される。そして、経験値の累計値がレベル毎に設定された条件値（以下、レベル用条件値という。）に到達すると、装備品のレベルが、到達したレベル用条件値と対応する値まで上昇する。なお、レベルが高くなるほど、レベル用条件値がより大きい値になる。

装備品のランク値は、ゲームの進行に応じて変化する可変値であり、例えばｍ～ｎ（ｍ＜ｎ）の範囲で変化する。ｍは、入手時点での装備品のランク値、すなわちランク値の初期値であり、正又は負の整数、あるいは０である。ｎは、装備品のランク値の上限値であり、正の整数であり、装備品の種類に応じて決められている。また、装備品のランク値の最大値は、装備品が属する区分（換言すると、装備品のレア度）によって異なる。

ユーザは、自分の装備品をゲーム内で強化すると、その装備品のランク値を上げる（増やす）ことができる。つまり、装備品のランク値は、各ユーザが装備品を使用してゲームをプレイしている間に強化条件が成立した場合に上がる。強化条件は、特定の成長条件に相当し、ユーザがゲームをプレイしるときの操作内容（プレイ内容）に応じて条件の成否が決まる。具体的に説明すると、例えば、ランク値を上げたい装備品に対してランク値上昇用のアイテムを使用したり、あるいは、ランク値を上げたい装備品を使用した状態で所定のイベントをクリアしたりすること等が強化条件に該当する。

また、本実施形態では、強化条件が成立すると、ランク値が、予め定められた確率に応じて上がる。ランク値が上がる確率は、ランク値を上げるために使用したアイテムの種類やクリアしたイベントの内容に応じて変化し、通常の場合には、ランク値が上がるほど確率は低下する。例外として、例えば特別なアイテムを使用したり、特別なイベントをクリアしたりした場合には、ランク値の現在値に関わらず、所定の確率（具体的には、１００％）で対象装備品のランク値を上げる（増やす）ことができる。

また、本実施形態では、装備品のレベル又はランク値を上げる際にコストが掛かる場合がある。つまり、各ユーザは、自己の装備品のレベル又はランク値を上げる際にコストを費やすことがある。コストを費やすとは、例えば、有料のアイテムを使用すること、あるいは、有料のゲーム内イベントをプレイすること等が挙げられる。なお、有料とは、現実空間において現金や電子マネー等の金銭的価値の支払いを要することであり、また、有料には、ユーザが金銭的価値を支払って取得したゲーム内通貨をゲーム内で消費することが含まれ得る。

［ユーザ間でのパラメータの取引について］
本実施形態では、ゲーム媒体の成長パラメータとして、装備品のレベル及びランク値をユーザ間で取り引きすることが可能である。例えば、あるユーザＡは、図２に示すように、自分が所持する装備品のレベル又はランク値を他のユーザＢに譲渡することができる。他方、ユーザＢは、ユーザＡから譲受したレベル又はランク値に応じて、ユーザＢが所持する装備品のレベル又はランク値を変更、詳しくは上昇させることができる。図２は、ユーザ間でのパラメータの取引についての説明図である。

本実施形態において、ユーザ間での成長パラメータの取引（以下、単にパラメータ取引ともいう。）は、金銭又はそれに相当する価値の出納を伴う有料の取引、すなわち売買取引である。つまり、本実施形態では、第１ユーザが第１ユーザの装備品のレベル又はランク値を販売し、販売されたレベル又はランク値を第２ユーザが第１ユーザから購入する。そして、第２ユーザの装備品のレベル又はランク値は、第２ユーザが購入したレベル又はランク値に応じて上がる。他方、レベル又はランク値を販売した第１ユーザの装備品については、販売された分だけ、レベル又はランク値が下がる。

ここで、第１ユーザは、レベル又はランク値を譲渡（販売）する方のユーザであり、第２ユーザは、レベル又はランク値を譲受（購入）する方のユーザである。また、第１ユーザが所持する装備品は、第１ゲーム媒体に該当し、第２ユーザが所持する装備品は、第２ゲーム媒体に該当する。

以上のように本実施形態では、装備品のレベル又はランク値をユーザ間で取り引きする(売買する)ことができる。そして、上記の取引は、装備品の移譲を伴わない。つまり、第１ユーザの装備品のレベル又はランク値が販売されて第２ユーザによって購入された場合、その後も、第１ユーザは、レベル又はランク値が販売された装備品を引き続きゲーム内で使用することができる。これにより、取引に対する第１ユーザの意欲を喚起させることができる。

具体的に説明すると、従来のユーザ間での取引は、ゲーム媒体自体（キャラクタ又はアイテム）を対象として行われ、とりわけ、レア度が高いゲーム媒体を対象とする取引が行われていた。しかし、レア度が高いゲーム媒体を販売することは、当該ゲーム媒体を手放すことになるため、その所持者であるユーザにとって取引の実施を決断するのが難しい。そのため、従来のユーザ間での取引では、取引に対するユーザの意欲を喚起させ難く、取引を通じたユーザ間の交流を活性化させることが困難であった。

これに対して、本実施形態では、ユーザ間での取引として、使用権限の移譲を伴わない形でのゲーム媒体の成長パラメータの取引が可能である。つまり、本実施形態において、第１ユーザは、成長パラメータが取り引きされたゲーム媒体を取引後にも引き続き使用することができる。これにより、本実施形態では、従来に比べて、ユーザ、特に第１ユーザの取引に対する意欲を喚起させ易くなっている。これにより、取引を通じたユーザ間の交流が活性化され、その結果、ゲーム自体を盛り上げることができ、具体的には各ユーザのゲームプレイ時間、及びゲームをプレイするユーザ数等が増えることが期待される。

また、第１ユーザは、自分が所持するゲーム媒体の成長パラメータ、詳しくは装備品のレベル又はランク値を販売して得た利益（利潤）を享受することができる。このように本実施形態では、第１ユーザがゲームの中で上昇させた装備品のレベル又はランク値を販売することができるので、ゲームに投じた労力（具体的には、ゲームのプレイ時間等）を一種の商材として取り扱うことができる。

なお、パラメータ購入時に第２ユーザが第１ユーザに支払う対価は、現金、電子マネー又は仮想通貨、あるいはゲーム内で使用可能な通貨（ゲーム内通貨）でもよく、若しくは、これら以外の価値であってもよい。ゲーム内通貨は、換金性を有する価値でもよく、あるいは、ゲーム内でのみ使用することができ換金不可の価値でもよい。

また、本実施形態において、パラメータ取引の対象となる装備品は、課金又は有料でプレイできる抽選等を通じて入手することができる有料（換言すると、入手コストを要する）の装備品である。この場合には、装備品のパラメータ取引が行われた後に当該装備品を引き続き使用することができるという効果が、より有意義なものとなる。ただし、これに限定されるものではなく、ゲームの総プレイ回数が所定回数に達した場合やゲームの初回プレイ時に特典として無料でユーザに付与されたりする無料の装備品であってもよい。

また、成長パラメータの購入額（支払額）については、オークションでの入札形式で決めてもよく、第１ユーザ又は第２ユーザが自らの意志に基づいて任意の額に決めてもよく、あるいは、ゲームの運営会社が所定のルールに則り、販売される成長パラメータの種類や量等に応じて決めてもよい。

取引に伴う対価の支払いや入金等に関する処理（具体的には、金銭等の出納処理）については、ユーザ間での取引において従来から採用されてきた公知の情報処理技術を利用することが可能である。また、本実施形態では、例えば、換金性を有するゲーム内通貨が取引用の価値（以下、取引用通貨という。）として利用され、ユーザ間での取引が確定すると、第２ユーザから取引用通貨が支払われ、支払い量に応じた量の取引用通貨が第１ユーザに付与される。具体的には、パラメータ取引が確定すると、ゲーム内通貨について、第２ユーザの所持量を取引額に応じた量だけ減少させ、第１ユーザのゲーム内通貨の所持量を取引量に応じた量だけ増加させる。なお、取引用通貨として利用可能なゲーム内通貨は、ゲーム内でのみ使用することができる換金性のないゲーム内通貨でもよい。

なお、取引に伴う価値の入出処理については、上記の内容に限定されない。例えば、各ユーザのゲーム用アカウントに銀行口座の情報又はクレジットカード情報等が紐付けられており、パラメータ取引が確定すると、第２ユーザの銀行口座情報又はクレジットカード情報を通じて第２ユーザ宛に対価の支払いを請求し、対価に応じた量の金銭が第１ユーザの銀行口座等に振り込まれてもよい。

［本実施形態の情報処理装置及び各ユーザの端末について］
次に、本実施形態に係る情報処理装置及び各ユーザの端末について、図３を参照しながら説明する。図３は、本実施形態に係る情報処理装置及び各ユーザの端末を含むシステム全体を示す概念図である。

なお、以下では、ユーザＡを第１ユーザとし、ユーザＢを第２ユーザとし、ユーザＡ、Ｂの間で成長パラメータの取引、すなわち売買取引が行われるケースを例に挙げて説明することとする。また、以下では、ユーザＡがゲーム内で所持する装備品のうち、レベル又はランク値が取引対象として譲渡される装備品を「取引対象品」と呼び、ユーザＢがゲーム内で所持する装備品のうち、ユーザＡから譲受したレベル又はランク値によって強化される（つまり、レベル又はランク値が上がる）装備品を「被強化品」と呼ぶこととする。

ユーザＡ、Ｂの各々は、ゲームプレイ用の端末としてユーザ端末１１、１２を保有する。つまり、各ユーザは、ゲームをプレイするために各自のユーザ端末１１、１２を操作し、パラメータの売買取引を実施しようとする場合にはゲーム中に所定の操作を行う。

各ユーザのユーザ端末１１、１２は、例えば、パソコン、スマートフォン、携帯電話、タブレット端末、通信対応型のゲーム機、情報の送受信が可能なテレビ受像機、又はウェアラブル端末等によって構成される。つまり、ユーザ端末１１、１２は、オンライン形式でゲームをプレイするために用いられた従来の端末と同様のハードウェア構成であり、図３に示すようにプロセッサ１３、メモリ１４、通信用インタフェース１５、入力デバイス１６、及びディスプレイ等の出力デバイス１７等を備える。また、各々のユーザ端末１１、１２には、端末用のソフトウェアとして、ゲームプレイ用のプログラムがインストールされている。

また、各ユーザのユーザ端末１１、１２は、それぞれ、図３に示すように通信用ネットワークＮＴを介してサーバ１０と通信可能に接続されている。通信用ネットワークＮＴは、例えばインターネット又はモバイル通信ネットワークからなる通信回線網であり、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、イントラネット及びイーサネット（登録商標）等を含むものであってもよい。

サーバ１０は、本発明の「情報処理装置」の一例であり、本実施形態では、ゲーム進行に必要なデータの生成及び送受信等、並びにゲーム進行に関する各種の情報処理を実行するゲーム配信用のコンピュータによって構成される。サーバ１０が送受信するデータには、ユーザ間でのパラメータの取引に必要なデータが含まれ、サーバ１０が実行する情報処理には、ユーザ間でのパラメータの取引に関する処理が含まれる。

本実施形態において、サーバ１０を構成するコンピュータは、ゲームの運営会社によって管理されるものであるが、これに限定されず、運営会社とは別の企業若しくは機関によって管理されてもよい。なお、サーバ１０は、１台のコンピュータで構成されてもよく、並列分散された複数台のコンピュータによって構成されてもよい。また、サーバ１０は、ＡＳＰ（Application Service Provider）、ＳａａＳ（Software as a Service）、ＰａａＳ（Platform as a Service）又はＩａａＳ（Infrastructure as a Service）用のサーバコンピュータであってもよい。この場合、ゲーム進行に関する一連の情報の工程（ただし、情報の入力及び表示を除く）がサーバ１０によって実行されるため、各ユーザ端末１１、１２側では、サーバ１０に引き渡す情報の入力、及びサーバ１０から配信される情報の表示等を行えばよいことになる。

サーバ１０は、ハードウェア機器として、図３に示すように、プロセッサ１０Ａ、メモリ１０Ｂ、通信用インタフェース１０Ｃ、及びストレージ１０Ｄを有し、これらがバスを介して電気的に接続されている。プロセッサ１０Ａは、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＭＣＵ（Micro Controller Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＴＰＵ（Tensor Processing Unit）又はＡＳＩＣ（Application Specific Integrated Circuit）等によって構成されるとよい。

メモリ１０Ｂは、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）等の半導体メモリによって構成されるとよい。
通信用インタフェース１０Ｃは、例えばネットワークインタフェースカード、又は通信インタフェースボード等によって構成されるとよい。通信用インタフェース１０Ｃによるデータ通信の規格については、特に限定されるものではなく、Ｗｉ－ｆｉ（登録商標）に基づく無線ＬＡＮによる通信、３Ｇ～５Ｇ若しくはそれ以降の世代の移動通信システムによる通信、又はＬＴＥ（Long Term Evolution）に基づく通信等が挙げられる。

ストレージ１０Ｄは、フラッシュメモリ、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）、ＦＤ（Flexible Disc）、ＭＯディスク（Magneto-Optical disc）、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＳＤカード（Secure Digital card）、又はＵＳＢメモリ（Universal Serial Bus memory）等によって構成されるとよい。また、ストレージ１０Ｄは、サーバ１０内に内蔵されてもよく、外付け形式でサーバ本体に取り付けてもよい。さらに、ストレージ１０Ｄは、サーバ本体と通信可能に接続された外部コンピュータ（例えば、データベースサーバ）等によって構成されてもよい。さらにまた、各種のデータを記録する技術としては、不正なデータ改竄等を回避する目的からブロックチェーンのような分散型台帳技術を用いてもよい。特に、各ユーザの取引用通貨の所持量については、ブロックチェーンによる管理及び記録が適している。

また、サーバ１０には、ソフトウェアとして、オペレーティングシステム（ＯＳ）用のプログラム、及び、ゲーム進行用の情報処理プログラムがインストールされている。これらのプログラムは、本発明の「プログラム」に相当し、プロセッサ１０Ａによって実行されることで、サーバ１０が本発明の情報処理装置としての機能を発揮する。

具体的に説明すると、例えばユーザＡ、Ｂがゲームをプレイしている間、サーバ１０は、上記のプログラムの実行により、ゲームプレイ画面の表示データを生成して各ユーザのユーザ端末１１、１２に向けて送信する。また、ユーザＡ、Ｂがユーザ端末１１、１２を通じてゲーム進行用の操作を行うと、当該操作の内容を示すデータがユーザ端末１１、１２からサーバ１０に向けて送信され、サーバ１０は、ユーザ端末１１、１２から受信したデータに基づいて、ユーザ操作に応じてゲームを進行させる情報処理を実行する。

さらに、ユーザＡは、自分が所持する装備品のうち、取引対象品のレベル又はランク値を譲渡（販売）しようとする場合にユーザ端末１１を通じて譲渡の申し出を行い、サーバ１０は、ユーザ端末１１との通信を介してユーザＡから譲渡の申し出を受け付ける。他方、ユーザＢは、ユーザＡが販売したレベル又はランク値を譲受（購入）しようとする場合にユーザ端末１２を通じて譲受の申し出を行い、サーバ１０は、ユーザ端末１２との通信を介してユーザＢから譲受の申し出を受け付ける。

そして、サーバ１０がユーザＡ及びユーザＢの各々から申し出を受け付けて取引条件が成立すると、サーバ１０は、パラメータ取引に関する一連の情報処理を実行する。これにより、ユーザＢが所持する装備品のうち、被強化品のレベル又はランク値が上昇し、その一方で、ユーザＡが所持する取引対象品のレベル又はランク値が低下する。

取引条件は、所定の条件に相当し、具体的には、パラメータ取引の成立を確定させる条件、換言すると、取引対象品のレベル又はランク値の譲渡及び譲受を確定させるための条件である。取引条件としては、例えば、パラメータ取引が確定したことを示すデータを記憶すること（詳しくは、後述の取引データの成否フラグを取引確定の値に切り替えること）、あるいは、ユーザＢがパラメータ譲渡の対価を支払うこと（詳しくは、後述の決済処理を実行すること）等が挙げられる。また、パラメータ取引がオークション形式で行われる場合には、最高額が提示された入札があった状態で入札可能期間が経過することを取引条件としてもよい。

なお、サーバ１０にインストールされるプログラムは、コンピュータが読み取り可能な記録媒体（メディア）から読み込むことで取得してもよく、あるいは、インターネット又はイントラネット等のネットワークを介して取得（ダウンロード）してもよい。

次に、各ユーザのユーザ端末１１、１２及びサーバ１０の各々について、図４及び５を参照しながら、各機器の構成を機能面から改めて説明することとする。図４は、ユーザ端末１１、１２の機能を示し、図５は、サーバ１０に備えられた機能（換言すると、複数の機能部）を示す。

（ユーザ端末の機能について）
ユーザ端末１１、１２は、図４に示すように、端末側受付部２１、端末側送受信部２２、端末側記憶部２３、及び表示実行部２４を備える。これらの機能部の各々は、ユーザ端末１１、１２を構成するハードウェア機器と、ユーザ端末１１、１２にインストールされたソフトウェア（具体的には、ゲームプレイ用のプログラム）との協働によって実現される。

端末側受付部２１は、ゲーム進行用の操作及びパラメータ取引用の操作等、ユーザがゲームプレイ中に行う操作（ゲーム用操作）を受け付ける。
端末側送受信部２２は、サーバ１０又は他のユーザ端末から送られてくるデータを受信し、また、サーバ１０又は他のユーザに向けてデータを送信する。端末側送受信部２２がサーバ１０に向けて送信するデータの中には、端末側受付部２１が受け付けたゲーム用操作の内容に応じたデータが含まれ、例えば下記の（ａ）～（ｆ）のデータが含まれる。
（ａ）ユーザが所持する装備品等の使用の有無に関するデータ
（ｂ）ゲーム内イベントにおけるプレイ内容に関するデータ
（ｃ）ユーザが所持する装備品等を売却又は廃棄するための指示データ
（ｄ）ユーザが所持する装備品等を強化又は進化させるための指示データ
（ｅ）パラメータ譲渡の申し出に関するデータ
（ｆ）パラメータ譲受の申し出に関するデータ

データ（ａ）～（ｄ）は、ユーザが行ったゲーム進行用の操作に応じたデータである。
データ（ａ）は、ユーザがゲーム内で装備品を使用する場合に生成され、例えば、ユーザＩＤ、使用される装備品の識別情報、及び、どのキャラクタに対して使用されるのか等を示す。
データ（ｂ）は、ユーザがゲーム内イベントをプレイする場合に生成され、例えば、ユーザＩＤ、プレイするイベントの識別情報、イベント内で使用するキャラクタ及び装備品等の各々の識別情報、及び、イベント中におけるキャラクタに対する指示や命令等（具体的には、キャラクタの移動方向、又は攻撃又は防御等の動作に関する命令等）を示す。
データ（ｃ）は、ユーザがゲーム内で所持する装備品を売却又は廃棄する場合に生成され、例えば、ユーザＩＤ、及び、売却又は廃棄する装備品の識別情報等を示す。
データ（ｄ）は、ユーザがゲーム内で所持する装備品を強化又は進化させる場合に生成され、例えば、ユーザＩＤ、強化又は進化させる装備品の識別情報、並びに、強化用又は進化用のアイテムを用いるケースでは当該アイテムの識別情報及び使用個数等を示す。

データ（ｅ）及び（ｆ）は、ユーザが行うパラメータ取引用の操作に応じたデータである。データ（ｅ）は、第１ユーザ（つまり、ユーザＡ）が取引対象品のレベル又はランク値の譲渡を申し出る場合に生成され、例えば、ユーザＩＤ、取引対象品の識別情報、及び、譲渡されるレベル又はランク値の範囲（譲渡範囲）等を示し、また、第１ユーザが指定した希望譲渡額（販売額）等を更に含んでもよい。
データ（ｆ）は、第２ユーザ（つまり、ユーザＢ）が取引対象品のレベル又はランク値の譲受を申し出る場合に生成され、例えば、ユーザＩＤ、取引対象品の識別情報、譲渡範囲、及び、譲受したレベル又はランク値によって強化される被強化品の識別情報等を示し、また、第２ユーザが指定した希望譲受額（購入額）等を更に含んでもよい。

端末側記憶部２３は、ゲームにおいて必要なデータを記憶し、例えば、表示データ等のようにサーバ１０から送られてくるデータを記憶する。
表示実行部２４は、サーバ１０から受信した表示データを展開し、表示データが示すゲーム画面（ゲームプレイ中の画面）をユーザ端末１１、１２の出力デバイス１７、より詳しくはディスプレイを表示する。

（サーバの機能について）
サーバ１０は、図５に示すように、ゲーム進行用受付部３１、ゲーム進行部３２、サーバ側記憶部３３、取引用受付部３４、コスト算出部３５、取引処理部３６、及び拒否部３７を備える。これらの機能部の各々は、サーバ１０を構成するハードウェア機器と、サーバ１０にインストールされたソフトウェアとしてのプログラム（すなわち、本発明のプログラム）との協働によって実現される。

ゲーム進行用受付部３１は、ユーザ端末１１、１２との通信を通じてユーザのゲーム内操作、特にゲーム進行用の操作を受け付け、具体的には、ゲーム進行用のデータを、通信用ネットワークＮＴを介してユーザ端末１１、１２から受信する。ゲーム進行用受付部３１が受信するデータは、ユーザが行ったゲーム進行用の操作に応じたデータであり、例えば上記のデータ（ａ）～（ｄ）が該当する。

ゲーム進行部３２は、ユーザがゲームをプレイしている期間中、ゲーム進行用受付部３１が受信したゲーム進行用のデータに応じてゲームを進行させる。ゲーム進行用のデータには、前述したようにデータ（ａ）、すなわち装備品等の使用の有無に関するデータが含まれる。このため、ゲーム進行部３２は、各ユーザの装備品等の使用に応じて、各ユーザがプレイするゲームを進行させる。また、ゲーム進行部３２は、上述のデータ（ｂ）、すなわちゲーム内イベントにおけるプレイ内容に関するデータに応じてゲームを進行させ、具体的には、例えばユーザの指示や命令に従ってキャラクタを動かしてゲーム内イベントを進める。

また、本実施形態において、ゲーム進行部３２は、図５に示すように、状態変更部４１と経験値付与部４２を含み、状態変更部４１は、パラメータ変更部４３を含む。
状態変更部４１は、ゲーム進行用受付部３１が受け付けたゲーム内操作に応じて、厳密にはユーザ端末１１、１２から受信したゲーム進行用のデータ、特に上述のデータ（ａ）、（ｃ）及び（ｄ）に応じて装備品の状態を変更させる。装備品の状態は、装備品の現在のステータス及びパラメータの現在値等である。ステータスは、例えば、装備品が現時点で使用されているか否か、装備品が既に売却又は廃棄されているか否か、及び、装備品が進化前及び進化後のいずれであるか等を示す情報であり、パラメータは、レベル及びランク値である。

経験値付与部４２は、ユーザが装備品を使用してゲーム内で所定のイベントをクリアした場合に、使用された装備品に対して、クリアしたイベントに応じた経験値を付与する。付与された経験値は、これまでに上記の装備品に対して付与された経験値の累計値に加算される。

パラメータ変更部４３は、状態変更部４１の一機能を担うものであり、ユーザが所持する装備品の成長パラメータ、具体的にはレベル又はランク値を変更させる。具体的に説明すると、パラメータ変更部４３は、各ユーザの各装備品に付与された経験値の累計値を特定し、累計値がレベル用条件値に到達した装備品のレベルを、そのレベル用条件値と対応する値まで上昇させる。

また、例えば、ゲーム進行用受付部３１が上述のデータ（ｄ）、厳密には装備品を強化させるための指示データを受け付けた場合、パラメータ変更部４３は、指示データが示す情報等に基づいて前述の強化条件の成否を判定し、強化条件が成立する場合には、強化対象の装備品のランク値を変更する。この際、パラメータ変更部４３は、予め定められた確率に応じて当該装備品のランク値を上げる（増やす）。

さらに、ユーザＡ、Ｂの間でパラメータ取引が行われた場合、パラメータ変更部４３は、ユーザＡが所持する装備品中の取引対象品、及び、ユーザＢが所持する装備品中の被強化品のそれぞれのレベル又はランク値を、取引内容に応じてレベルを変更する。具体的には、パラメータ変更部４３は、取引条件の成立をトリガーとして、ユーザＡの取引対象品のレベル又はランク値を、ユーザＡが譲渡（販売）した量に応じて減少させ、且つ、ユーザＢの被強化品のレベル又はランク値を、ユーザＢが譲受（購入）した量に応じて上げる。

サーバ側記憶部３３は、記憶部に相当し、ゲームの進行及びユーザ間でのパラメータの取引に必要な各種のデータを記憶し、具体的には、図６に示すユーザデータ、図７に示す装備品データ、図８に示す取引データ、図９に示すレベル強化用データ、及び、図１０に示すランク値強化用データを記憶する。図６～１０の各図は、サーバ側記憶部３３に記憶されるデータの一例を示す。

ユーザデータは、ゲームをプレイするユーザ、つまりゲーム用のアカウントを有するユーザに関するデータであり、ユーザ毎にサーバ側記憶部３３に記憶される。ユーザデータは、図６に示すように、ユーザＩＤ、所持するキャラクタ、アイテム及び装備品の識別情報、ゲーム進行用通貨の所有量、及び取引用通貨の所有量等を含む。ゲーム進行用及び取引用通貨は、いずれも、課金や購入又はゲーム内イベントのプレイ等によって入手可能なゲーム内通貨である。ゲーム進行用通貨は、主としてゲーム内でアイテムや装備品等を購入する等、ゲームを進行させるために利用され、取引用通貨は、主としてユーザ間でのパラメータの取引のために利用される。
なお、ユーザデータは、図６に示された内容以外のデータを含んでもよく、例えば、ユーザがゲーム内通貨の購入代金の支払いに利用する銀行口座又はクレジットカードの情報等が含まれてもよい。

装備品データは、各ユーザが所持する装備品に関するデータであり、各ユーザが所持する装備品毎に記憶される。装備品データは、図７に示すように、装備品の識別情報、装備品の所持者であるユーザのユーザＩＤ、区分、レベル及びランク値のそれぞれの初期値と現在値、これまでに付与された経験値の累計値、使用状態、レベル又はランク値のそれぞれの変更履歴、及び、取引対象であるか否かを示す該否フラグ等を含む。

レベル又はランク値のそれぞれの変更履歴は、パラメータ変更履歴に該当し、レベル又はランク値が初期値から現在値に至るまでの経緯として、各時点で装備品に対して費やされたコスト、つまり、これまでの装備品の強化（パラメータ変更）に関するコストを示す。より詳しく説明すると、変更履歴は、図７に示すように、各段階のレベル又はランク値において、装備品に対して使用されたパラメータ強化用アイテムの種類、消費個数、及びアイテム購入時に支払った通貨量（金額）、並びに、装備品を使用してプレイされたパラメータ強化用のイベントの種類、プレイ回数、及びイベントプレイ時に支払った通貨量（金額）等を表す。
なお、装備品データは、図７に示された内容以外のデータを含んでもよく、例えば、これまでに取引対象となった回数（つまり、成長パラメータが譲渡された回数）等が含まれてもよい。

取引データは、パラメータ取引に関するデータであり、取引毎に記憶される。取引データは、図８に示すように、取引の識別情報、取引に関与するユーザ（すなわち、第１ユーザ及び第２ユーザ）のユーザＩＤ、取引対象品に該当する装備品の識別情報、譲渡されるパラメータの種類（レベル及びランク値のいずれであるか）、パラメータの譲渡範囲、パラメータがレベルである場合には譲渡範囲から変換された経験値、第１ユーザが指定した譲渡額（販売額）、第２ユーザが指定した譲受額（購入額）、被強化品に該当する装備品の識別情報、及び、取引が確定したか否かを示す成否フラグ等を含む。
なお、取引データは、図８に示された内容以外のデータを含んでもよく、例えば、取引に対して設定された制限時間等が含まれてもよい。制限時間が設定された取引については、制限時間内に成立しなかった場合に当該取引をキャンセルにしてもよい。

レベル強化用データ及びランク値強化用データの各々は、ユーザが装備品の強化を指示した場合に、パラメータ変更部４３によって参照されるデータである。レベル強化用データは、図９に示すように、各装備品のレベルを１段階ずつ上昇させるに必要な経験値の累計値、すなわちレベル用条件値を段階毎に規定したデータであり、装備品の種類毎に記憶される。

ランク値強化用データは、図１０に示すように、各装備品のランク値を１段階ずつ上昇させるために満たすことが必要となる強化条件を段階毎に規定したデータであり、装備品の種類毎に記憶される。強化条件は、ランク値を上げるために必要なアイテムの種類及び使用個数、あるいは、ランク値を上げるためにプレイすることが必要なイベントの種類及びプレイ回数である。また、ランク値強化用データには、図１０に示すように、各段階のランク値において強化条件が成立した場合に一つ上のランク値に上がることができる確率が含まれる。

取引用受付部３４は、受付部に相当し、ユーザ間でのパラメータの取引に関するユーザの操作を受け付け、具体的には、パラメータ取引用のデータを、通信用ネットワークＮＴを介してユーザ端末１１、１２から受信する。取引用受付部３４が受信するデータは、ユーザが行ったパラメータ取引用の操作に応じたデータであり、例えば上述のデータ（ｅ）及び（ｆ）が該当する。つまり、取引用受付部３４は、第１ユーザであるユーザＡが所持する装備品中の取引対象品のレベル又はランク値について、ユーザＡから譲渡（販売）の申し出を受け付けるとともに、第２ユーザであるユーザＢから譲受（購入）の申し出を受け付ける。

また、本実施形態において、取引用受付部３４は、取引対象品のレベル又はランク値についてのユーザＢからの譲受の申し出が申し出受付条件を満たすことを条件として、ユーザＢからの譲受の申し出を受け付ける。申し出受付条件は、ゲーム進行上におけるユーザ間の不平等を是正して公平な取引を実現する理由によって設定された条件である。申し出受付条件は、取引対象品と対応付けられて設定され、例えば取引対象品の属性（例えば、区分等）、又は取引時点でのレベル又はランク値等に基づいて設定される。

申し出受付条件の具体的な内容は、特に制限されていないが、本実施形態では、ユーザＢが取引対象品と同じ区分の装備品を所持していることを申し出受付条件としている。つまり、本実施形態では、ユーザＢが取引対象品と同じ区分の装備品を所持する場合に限り、ユーザＢからの譲受の申し出が受け付け可能となり、ユーザＢは、ユーザＡが譲渡した取引対象品のレベル又はランク値を譲受（購入）することができる。ただし、このような制限が設けられていなくてもよく、ユーザＢが取引対象品と同じ区分の装備品を所持していない場合であっても、ユーザＢによる取引対象品のレベル又はランク値の譲受（購入）を許可してもよい。

コスト算出部３５は、取引対象品のレベル又はランク値について取引用受付部３４がユーザＡから譲渡の申し出を受け付けた場合に、これまでに取引対象品に費やされたコスト、特に、これまでの取引対象品の強化に費やされたコスト（以下、強化コストという。）を算出する。コスト算出部３５は、強化コストの算出に際して取引対象品の装備品データをサーバ側記憶部３３から読み出し、同データが示すレベル又はランク値の変更履歴に基づき、強化コストを算出する。より具体的に説明すると、これまでに取引対象品に対して使用されたパラメータ強化用アイテムのうちの有料アイテムについて、その購入金額と消費個数とから、アイテム使用による強化コストを算出する。また、これまでに取引対象品を使用してプレイされたパラメータ強化用のイベントのうちの有料イベントについて、そのプレイ料金とプレイ回数とから、イベントプレイによる強化コストを算出する。

取引処理部３６は、パラメータ取引が確定した場合に、その取引に関する処理として、取り引きされた成長パラメータの対価についての決済処理等を実行する。決済処理では、成長パラメータの譲受額（購入額）に応じた量の取引用通貨を、ユーザＢの取引用通貨の所持量から減らし、ユーザＢから減じた量（支払額）に応じた量の取引用通貨を、ユーザＡの取引用通貨の所持量に加算する。ここで、成長パラメータの譲受額に応じた量は、譲受額に相当する量でもよいし、若しくは譲受額に一定の手数料を加えた額に相当する量でもよい。また、支払額に応じた量は、支払額に相当する量でもよいし、若しくは支払額から一定の手数料を減じた額に相当する量でもよい。

拒否部３７は、ユーザＡの取引対象品が特定の条件（以下、拒否条件という。）を満たした場合に、取引対象品のレベル又はランク値について、ユーザＡからの譲渡の申し出を拒否する。本実施形態では、例えば、コスト算出部３５により算出された取引対象品の強化コストが所定値以上であることが、拒否条件に該当する。
取引対象品のレベル又はランク値について、ユーザＡからの譲渡の申し出が拒否されると、当然ながら、取引対象品のレベル又はランク値についての取引がキャンセルとなる。

［本実施形態に係る情報処理フロー］
次に、本実施形態に係る情報処理フローとして、ゲーム進行フロー及びパラメータ取引フローについて説明する。以下に説明する各フローは、本発明の情報処理方法を採用しており、フロー中の各ステップは、本発明の情報処理方法の構成要素に該当する。
なお、以下に説明する各フローは、あくまでも一例であり、本発明の趣旨を逸脱しない範囲において不要なステップを削除したり、新たなステップを追加したり、ステップの実施順序を入れ替えてもよい。

＜ゲーム進行フロー＞
ゲーム進行フローでは、ユーザが自己のユーザ端末を使用してゲームをプレイすることにより、サーバ１０が、そのプレイ内容に応じてゲームを進行させる。以下では、ゲーム進行フローとして、ユーザがゲーム内で使用する装備品のレベル又はランク値をゲームの進行度合いに応じて変更する流れについて、図１１を参照しながら説明することとする。図１１は、ゲーム進行フローの流れを示し、具体的には、装備品のレベル又はランク値を変更させる流れを示している。
なお、以下では、ユーザＡが装備品Ｕを使用してゲームをプレイするケースを想定することとする。

ユーザＡが装備品Ｕを使用した状態でゲームをプレイすると（Ｓ００１）、コンピュータであるサーバ１０が、ユーザＡによるゲーム進行用の操作を受け付け、具体的には、ゲーム進行用のデータをユーザ端末１１から受信する（Ｓ００２）。サーバ１０は、受信したデータに基づいて、ユーザＡがプレイしているゲームを進行させる（Ｓ００３）。

また、ユーザＡが装備品Ｕを使用した状態でゲーム内イベントをクリアすると（Ｓ００４）、サーバ１０は、ユーザＡの装備品Ｕに対して経験値を付与する（Ｓ００５）。具体的には、サーバ１０は、装備品Ｕの装備品データをサーバ側記憶部３３から読み出し、読み出したデータが示す経験値の累計値に対して、ステップＳ００３にて付与された経験値を加算する。そして、加算後の経験値の累計値が、装備品Ｕについて設定されたレベル用条件値に到達している場合（Ｓ００６）、サーバ１０は、装備品Ｕのレベルを到達したレベル用条件値と対応する値まで上昇させる（Ｓ００７）。

なお、本実施形態では、装備品Ｕを使用してゲーム内イベントをクリアした場合に経験値が装備品Ｕに対して付与されるが、例えば、装備品Ｕに対してレベルアップ用のアイテムを使用した場合にも、当該アイテムに応じた量の経験値が装備品Ｕに対して付与されてもよい。

ユーザＡが装備品Ｕに対してランク値上昇用のアイテムを使用する等、ゲーム中において強化条件を満たした場合（Ｓ００８）、サーバ１０は、その時点での装備品Ｕのランク値やアイテム使用数等に応じて決まる確率に従って、装備品Ｕのランク値を一つ上のランク値に上げる（Ｓ００９）。
なお、強化条件が満たされたとしても、上記の確率に基づき、ランク値の上昇が実施されない場合があり、その場合にはランク値が現在値のまま維持されてもよく、あるいは低下してもよい。また、強化時に特定のアイテムを使用することにより、ランク値の上昇が見送られた場合にランク値の低下を回避することができるようにしてもよい。

装備品Ｕのレベル又はランク値を上げた場合には、サーバ１０が、装備品Ｕの装備品データが示すレベル又はランク値の現在値を上昇後のレベル又はランク値に更新する。
以上までに説明した一連のステップＳ００２～Ｓ００９は、ユーザＡがゲームをプレイしている間繰り返し実施され、ユーザＡがゲームを終了した時点で（Ｓ０１０）、ゲーム進行フローが終了する。

なお、図１１には特に図示していないが、ユーザＡは、ゲームプレイ中に装備品Ｕをゲーム内で売却したり廃棄したりすることができ、また、進化によって装備品Ｕを別の装備品に変化させることができる。サーバ１０は、装備品Ｕの売却、廃棄又は進化に伴い、ユーザＡが保有する装備品Ｕの使用権限を消失させる。

＜パラメータ取引フロー＞
パラメータ取引フローでは、パラメータ取引が行われた場合に、サーバ１０が、取引に関する処理として、取引対象品及び被強化品の各々の成長パラメータを変更する処理を実行する。また、成長パラメータにはレベルとランク値が含まれ、処理の流れは、取り引きされる成長パラメータがレベルである場合と、取り引きされる成長パラメータがランク値である場合とで異なる。以下では、それぞれの場合でのパラメータ取引フローの流れについて、図１２Ａ、１２Ｂ及び図１３Ａ、１３Ｂを参照しながら説明することとする。図１２Ａ、１２Ｂ及び図１３Ａ、１３Ｂは、パラメータ取引フローの流れを示す図であり、図１２Ａ、１２Ｂは、取り引きされる成長パラメータがレベルである場合の流れを示し、図１３Ａ、１３Ｂは、取り引きされる成長パラメータがランク値である場合の流れを示す。
なお、以下では、ユーザＡが所持する装備品Ｕの成長パラメータについて、ユーザＡとユーザＢとの間で取引を行うケースを想定することとする。

＜＜取り引きされる成長パラメータがレベルである場合＞＞
ユーザＡが装備品Ｕのレベルを譲渡（販売）する場合、ユーザＡは、ユーザ端末１１を操作してパラメータ譲渡の申し出を行う（Ｓ０２１）。ステップＳ０２１において、ユーザＡは、取引対象品として装備品Ｕを選択するとともに、レベルの譲渡範囲についての指定操作を行う。

ユーザ端末１１は、ユーザＡの指定操作に基づき、装備品Ｕのレベルについての譲渡範囲を設定する（Ｓ０２２）。この際、譲渡範囲の下限が、ユーザＡが入手した時点での装備品Ｕのレベル（すなわち、レベルの初期値）を下回らないようにし、且つ、譲渡範囲の上限が装備品Ｕのレベルの現在値と一致するように譲渡範囲が設定される。例えば、装備品Ｕのレベルの初期値が１（Ｌｖ１）であり、現在値が５（Ｌｖ５）であるとすると、譲渡範囲は、最大で「Ｌｖ５→Ｌｖ１」に設定することができ、あるいは「Ｌｖ５→Ｌｖ２」、「Ｌｖ５→Ｌｖ３」若しくは「Ｌｖ５→Ｌｖ４」に設定することもできる。

また、ステップＳ０２１において、ユーザＡは、レベルの譲渡額についての指定操作を行ってもよい。その場合には、ユーザ端末１１は、ユーザＡの指定操作に基づき、レベルの譲渡範囲ともに譲渡額（販売額）を設定することになる。なお、レベルの譲渡範囲及び譲渡額は、ユーザＡの指定操作に基づいてサーバ１０側で設定されてもよい。

その後、ユーザ端末１１は、パラメータ（詳しくは、レベル）の譲渡に関するデータを生成してサーバ１０に向けて送信する。サーバ１０は、ユーザ端末１１から送られてくるデータを受信することで、装備品Ｕのレベルについて、ユーザＡからの譲渡の申し出を受け付ける（Ｓ０２３）。サーバ１０は、ユーザＡが譲渡を申し出た装備品Ｕのレベルについて、その譲渡範囲に相当するレベル変更量を経験値に換算する（Ｓ０２４）。そして、サーバ１０は、装備品Ｕのレベルについての譲渡の申し出、及び、換算された経験値等を示す取引データをサーバ側記憶部３３に記録する（Ｓ０２５）。以降、その取引データは、各ユーザによって検索可能な状態で蓄積される。

サーバ１０は、装備品ＵのレベルについてユーザＡから譲渡の申し出を受け付けると、その時点でユーザＡが装備品Ｕを使用してゲームをプレイしている最中であるか否かを判定する（Ｓ０２６）。ユーザＡが装備品Ｕを使用してゲームをプレイしている最中であると判定した場合（Ｓ０２６でＹｅｓ）、サーバ１０は、装備品ＵのレベルについてユーザＡから譲渡の申し出を受け付けてから取引条件が成立するまでの間（以下、待機期間という。）、装備品Ｕのレベルを現在値に維持したまま、ユーザＡの装備品Ｕの使用に応じてゲームを進行させる（Ｓ０２７）。

また、ステップＳ０２７を実施する場合、サーバ１０は、待機期間中には装備品Ｕの状態を変えず、具体的には装備品Ｕの売却、廃棄、強化及び進化を禁止（ロック）する（Ｓ０２８）。これらの手続きは、装備品Ｕの帰属及びレベル等を変える操作であり、装備品Ｕのレベルについての取引に対して影響を与え得るからである。

なお、ステップＳ０２７を実施する場合、待機期間中にユーザＡが装備品Ｕを使用してゲームを進めることで獲得した経験値は、一時的にストックすることとする。そして、装備品ＵのレベルについてユーザＢから譲受の申し出がないまま取引が終了した場合には、ストックしておいた経験値を装備品Ｕに付与してもよい。

ステップＳ０２６に戻って説明すると、ユーザＡが装備品Ｕを使用してゲームをプレイしていないと判定した場合（Ｓ０２６でＮｏ）、上記のステップＳ０２７及びＳ０２８は実施されず、以降のステップに移行する。

ユーザＢは、入手可能な経験値及び譲渡額等をキーとして取引データを検索する。検索の結果、装備品ＵのレベルについてユーザＡが申し出た譲渡の内容（具体的には、入手可能な経験値及び譲渡額等）がユーザＢにとって好適である場合、ユーザＢは、そのレベルについてパラメータ譲受（購入）の申し出を行う（Ｓ０２９）。ステップＳ０２９において、ユーザＢは、ユーザ端末１２を通じて、レベルを譲受する対象（取引対象品）として装備品Ｕを選択するとともに、レベルの譲受額（購入額）についての指定操作を行う。また、ユーザＢは、ステップＳ０２９において、ユーザＢが所持する装備品のうち、譲受したレベルによって強化される対象となるもの（被強化品）を選択する。

その後、ユーザ端末１２は、パラメータ（詳しくは、レベル）の譲受に関するデータを生成してサーバ１０に向けて送信し、サーバ１０は、ユーザ端末１２から送られてくるデータを受信することで、装備品Ｕのレベルについて、ユーザＢからの譲受の申し出を受け付ける（Ｓ０３１）。

本実施形態では、サーバ１０がユーザＢから譲受の申し出を受け付けるにあたり、取引対象品である装備品Ｕと同じ区分に分類される装備品がユーザＢによって所持されているかどうかを判定する（Ｓ０３０）。そして、装備品Ｕと同じ区分に分類される装備品をユーザＢが所持していると判定された場合に限り（Ｓ０３０でＹｅｓ）、サーバ１０は、装備品ＵのレベルについてユーザＢからの譲渡の申し出を受け付ける。つまり、本実施形態において、サーバ１０は、装備品ＵのレベルについてユーザＡから譲渡の申し出を受け付けた場合に、装備品Ｕと同じ区分に分類される装備品を所持するユーザ（第２ユーザ）のみから、譲受の申し出を受け付ける。
なお、ステップＳ０３０における判定は、サーバ１０が行ってもよいし、あるいはユーザＢ側（具体的には、ユーザＢのユーザ端末１２）にて行われてもよい。

サーバ１０は、装備品ＵのレベルについてユーザＡ及びユーザＢの各々から申し出を受け付けると、ステップＳ０２５でサーバ側記憶部３３に記録された取引データの成否フラグを「０（取引未確定）」から「１（取引確定）」に切り替える。これにより、取引条件が成立する（Ｓ０３４）。なお、図１２Ａ、１２Ｂには特に図示していないが、装備品Ｕのレベルについて、ユーザＡの指定操作に基づいて譲渡額（販売額）が設定された場合には、ユーザＢによって指定された譲受額（購入額）が譲渡額以上であれば、取引条件成立としてもよい。また、装備品Ｕのレベルについて、譲受を申し出たユーザが複数存在する場合には、最高の譲受額を指定したユーザとユーザＡとの間で取引を確定し、その他のユーザについては取引中止としてもよい。

その後、サーバ１０は、ユーザＢがユーザＡから譲受したレベルに応じて、ユーザＢが被強化品として選択した装備品のレベルを変更させる。より詳しく説明すると、サーバ１０は、ユーザＢが譲受したレベルを経験値に変換し、変換された経験値を被強化品の経験値の累計値に加算する（Ｓ０３３）。このステップＳ０３２にて加算される経験値は、ステップＳ０２４にて算出された経験値と同じ値である。そして、サーバ１０は、加算後の経験値の累計値がレベル用条件値に到達している場合には（Ｓ０３４）、到達したレベル用条件値と対応する値まで被強化品のレベルを上げる（Ｓ０３５）。

以上のように、本実施形態では、レベルが経験値に変換されて被強化品に付与されるため、被強化品のレベルに関わらず、ユーザ間でのレベルの取引を行うことが可能である。ただし、これに限定されるものではなく、ユーザＡから譲受したレベルに応じて強化される被強化品を、一定のレベルに到達した装備品、あるいは一定のレベルに達していない装備品に制限してもよい。

また、サーバ１０は、取引条件の成立時点にてユーザＡが装備品Ｕを使用してゲームをプレイしているか否かを判定する（Ｓ０３６）。ユーザＡが装備品Ｕを使用してゲームをプレイしていないと判定した場合（Ｓ０３６でＮｏ）、サーバ１０は、ユーザＡがユーザＢに譲渡したレベルに応じて、装備品Ｕのレベルを下げる（Ｓ０３７）。この結果、ステップＳ０２２にて設定されたレベルの譲渡範囲に相当する変更量だけ、装備品Ｕのレベルが下がる。

他方、ステップＳ０３４において、ユーザＡが装備品Ｕを使用してゲームをプレイしていると判定した場合（Ｓ０３６でＹｅｓ）、サーバ１０は、ユーザＡが装備品Ｕを使用し続ける間、装備品Ｕのレベルを変えずに現在値に維持したまま、ユーザＡの装備品Ｕの使用に応じてゲームを進行させる（Ｓ０３７）。つまり、装備品ＵのレベルについてユーザＢから譲受の申し出を受け付けた時点でユーザＡが装備品Ｕをゲーム内で使用している場合には、一時的に、装備品Ｕのレベルが取引前の値に維持され、ユーザＢの被強化品のレベルが取引後（すなわち、強化後）の値になる。

そして、ユーザＡが装備品Ｕの使用を終了すると（例えば、ユーザＡがゲームを終了すると）、サーバ１０は、ステップＳ０３７を実施して装備品Ｕのレベルを下げる。

なお、図１２Ａ、１２Ｂには示していないが、パラメータ取引に関する一つの処理として、サーバ１０は、装備品Ｕのレベルについて前述の決済処理を実行する。すなわち、サーバ１０は、ユーザＢが指定した譲受額（購入額）に応じた量の取引用通貨を、ユーザＢの取引用通貨の所持量から減らすとともに、ユーザＢから減らした量（支払額）に応じた量の取引通貨量を、ユーザＡの取引用通貨の所持量に加算する。決済処理の実行タイミングは、取引条件の成立直後（つまり、パラメータ取引の確定時点）でもよく、あるいは、ステップＳ０３６においてユーザＡが装備品Ｕを使用していると判断された後にユーザＡが装備品Ｕの使用を終了した時点でもよい。

以上までに説明した一連のステップが終了すると、その時点で、装備品Ｕのレベルについての取引に係る情報処理フロー（パラメータ取引フロー）が終了する。

＜＜取り引きされる成長パラメータがランク値である場合＞＞
ユーザＡが装備品Ｕのランク値を譲渡（販売）する場合、ユーザＡは、ユーザ端末１１を操作してパラメータ譲渡の申し出を行う（Ｓ０４１）。ステップＳ０４１において、ユーザＡは、取引対象品として装備品Ｕを選択するとともに、ランク値の譲渡範囲についての指定操作を行う。

ユーザ端末１１は、ユーザＡの指定操作に基づき、装備品Ｕのランク値についての譲渡範囲を設定する（Ｓ０４２）。この際、譲渡範囲の下限が、ユーザＡが入手した時点での装備品Ｕのランク値（すなわち、ランク値の初期値）を下回らないようにし、且つ、譲渡範囲の上限が装備品Ｕのランク値の現在値と一致するように譲渡範囲が設定される。例えば、装備品Ｕのランク値の初期値が＋１であり、現在値が＋４であるとすると、譲渡範囲は、最大で「＋４→＋１」とすることができ、あるいは「＋４→＋２」若しくは「＋４→＋３」とすることもできる。

また、ステップＳ０４１において、ユーザＡは、ランク値の譲渡額についての指定操作を行ってもよい。その場合には、ユーザ端末１１は、ユーザＡの指定操作に基づき、ランク値の譲渡範囲ともに譲渡額（販売額）を設定することになる。なお、ランク値の譲渡範囲及び譲渡額等は、ユーザＡの指定操作に基づいてサーバ１０側で設定されてもよい。

その後、ユーザ端末１１は、パラメータ（詳しくは、ランク値）の譲渡に関するデータを生成してサーバ１０に向けて送信する。サーバ１０は、ユーザ端末１１から送られてくるデータを受信することで、装備品Ｕのランク値について、ユーザＡからの譲渡の申し出を受け付ける（Ｓ０４３）。

サーバ１０は、装備品Ｕのランク値についてユーザＡからの譲渡の申し出を受け付けると、これまでの装備品Ｕの強化（ランク値の上昇）に費やしたコスト、すなわち強化コストを算出する（Ｓ０４４）。その後、サーバ１０は、算出した強化コストが所定値以上（例えば1円以上）であるか否かを判定する（Ｓ０４５）。強化コストが所定値以上である場合（Ｓ０４５でＹｅｓ）、サーバ１０は、ユーザＡから受け付けた装備品Ｕのランク値についての譲渡の申し出を拒否する（Ｓ０４６）。かかる場合には、ステップＳ０４６を実施した時点で、パラメータ取引フローが終了する。

他方、強化コストが所定値未満である場合には（Ｓ０４５でＮｏ）、ステップＳ０４７へ移行する。ステップＳ０４７では、サーバ１０が、装備品Ｕのランク値についての譲渡の申し出、及びランク値の譲渡範囲等を示す取引データをサーバ側記憶部３３に記録する。以降、その取引データは、各ユーザによって検索可能な状態で蓄積される。

以降の流れ（すなわち、Ｓ０４８～Ｓ０５８）は、図１３Ａ、１３Ｂに示すように、装備品Ｕのレベルを取り引きする場合の流れ（Ｓ０２６～Ｓ０３８）と概ね共通する。

具体的に説明すると、装備品Ｕのランク値についてサーバ１０がユーザＡから譲渡の申し出を受け付けた時点でユーザＡが装備品Ｕを使用してゲームをプレイしていたとする（Ｓ０４８でＹｅｓ）。この場合、サーバ１０は、装備品Ｕのランク値についてユーザＡから譲渡の申し出を受け付けてから取引条件が成立するまでの間、すなわち待機期間中には、装備品Ｕのランク値を現在値に維持したまま、ユーザＡの装備品Ｕの使用に応じてゲームを進行させる（Ｓ０４９）。また、サーバ１０は、待機期間中には装備品Ｕの状態を変えないように装備品Ｕの売却、廃棄、強化及び進化を禁止（ロック）する（Ｓ０５０）。

また、ユーザＢがランク値の譲渡範囲及び譲渡額等をキーとして取引データを検索した結果、装備品Ｕのランク値についてユーザＡが申し出た譲渡の内容がユーザＢにとって好適である場合、ユーザＢは、そのランク値に対してパラメータ譲受（購入）の申し出を行う（Ｓ０５１）。この際、ユーザＢは、取引対象品として装備品Ｕを選択するとともに、ランク値の譲受額（購入額）を指定し、さらに、ユーザＢが所持する装備品の中から、譲受したランク値によって強化される被強化品を選択する。

その後、ユーザ端末１２により、パラメータ（詳しくは、ランク値）の譲受に関するデータが生成され、サーバ１０は、当該データをユーザ端末１２から受信することで、装備品Ｕのランク値について、ユーザＢからの譲受の申し出を受け付ける（Ｓ０５３）。

なお、ステップＳ０５３の実施にあたり、取引対象品である装備品Ｕと同等の装備品をユーザＢが所持しているかどうかが判定される（Ｓ０５２）。装備品Ｕと同等の装備品とは、装備品Ｕと同じ区分に分類され、且つ、ランク値の現在値が装備品Ｕのランク値の譲渡範囲における下限と一致する装備品である。そして、装備品Ｕと同等の装備品をユーザＢが所持する場合に限り（Ｓ０５２でＹｅｓ）、サーバ１０は、装備品Ｕのランク値についてユーザＢからの譲渡の申し出を受け付ける。

サーバ１０は、装備品Ｕのランク値についてユーザＡ及びユーザＢの各々から申し出を受け付けると、ステップＳ０４７でサーバ側記憶部３３に記録された取引データの成否フラグを「０（取引未確定）」から「１（取引確定）」に切り替える。これにより、取引条件が成立する（Ｓ０５４）。なお、図１３Ａ、１３Ｂには特に図示していないが、装備品Ｕのランク値について、ユーザＡの指定操作に基づいて譲渡額（販売額）が設定された場合に、ユーザＢによって指定された譲受額（購入額）が譲渡額以上であれば、取引条件成立としてもよい。また、装備品Ｕのランク値について、譲受を申し出たユーザが複数存在する場合には、最高の譲受額を指定したユーザとユーザＡとの間で取引を確定し、その他のユーザについては取引中止としてもよい。

その後、サーバ１０は、取引条件の成立をトリガーとして、ユーザＢがユーザＡから譲受したランク値に応じて、ユーザＢが被強化品として選択した装備品のランク値を上昇させる（Ｓ０５５）。ここで、被強化品となる装備品は、取引対象品である装備品Ｕの区分と同じ区分に分類される装備品、又は区分の番号が装備品Ｕの区分より小さい区分に分類される装備品に限定されてもよい。

サーバ１０は、ユーザＡがユーザＢに譲渡したランク値に応じて、装備品Ｕのランク値を下げ、詳しくは、ステップＳ０４２にて設定された譲渡範囲に相当する変更量だけ下げる（Ｓ０５７）。なお、取引条件の成立時点でユーザＡが装備品Ｕを使用してゲームをプレイしている場合には（Ｓ０５６でＹｅｓ）、サーバ１０は、ユーザＡが装備品Ｕを使用し続ける間は装備品Ｕのランク値を変えずに現在値に維持したまま、ユーザＡの装備品Ｕの使用に応じてゲームを進行させる（Ｓ０５８）。その後、ユーザＡが装備品Ｕの使用を終了した時点で、サーバ１０は、ステップＳ０５７を実施して装備品Ｕのランク値を下げる。

なお、図１３Ａ、１３Ｂには示していないが、取引条件の成立に伴い、サーバ１０は、装備品Ｕのランク値について決済処理を実行する。すなわち、サーバ１０は、ユーザＢが指定した譲受額（購入額）に応じた量の取引用通貨を、ユーザＢの取引用通貨の所持量から減らすとともに、ユーザＢから減らした量（支払額）に応じた量の取引通貨量を、ユーザＡの取引用通貨の所持量に加算する。決済処理の実行タイミングは、取引条件の成立直後（つまり、パラメータ取引の確定時点）でもよく、あるいは、ステップＳ０５６においてユーザＡが装備品Ｕを使用していると判断された後にユーザＡが装備品Ｕの使用を終了した時点でもよい。

以上までに説明した一連のステップが終了すると、その時点で、装備品Ｕのランク値についての取引に係る情報処理フロー（パラメータ取引フロー）が終了する。

［第１の変形例について］
上記の実施形態では、装備品Ｕのランク値についてユーザＡからの譲渡の申し出を受け付けると、これまでの装備品Ｕの強化に要した強化コストを算出し、強化コストが所定値以上である場合には、ユーザＡからの譲渡の申し出を拒否することとした。ただし、本発明は、このような実施形態に限られず、別の形態（以下、第１の変形例という。）が考えられる。以下に、第１の変形例について、図１４、１５Ａ、１５Ｂを参照しながら説明する。図１４は、第１の変形例に係る情報処理装置であるサーバ１０Ｘの機能を示す。図１５Ａ、１５Ｂは、第１の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す。
なお、以下では、第１の変形例のうち、上記の実施形態と相違する点を主として説明し、上記の実施形態と共通する点については、説明を省略することとする。

第１の変形例に係る情報処理装置は、サーバ１０Ｘによって構成されている。サーバ１０Ｘの構成及び機能は、上記の実施形態（本実施形態）に係るサーバ１０と概ね同様であるが、図１４に示すように拒否部３７の代わりに条件設定部３８を有する点でサーバ１０と相違する。条件設定部３８は、サーバ１０Ｘのハードウェア機器とソフトウェアとの協働により実現される機能（つまり、サーバ１０Ｘが備える一つの機能部）である。条件設定部３８は、取引対象品である装備品Ｕのパラメータについての譲受条件、具体的には最低譲受額（最低購入額）を設定する。この際、条件設定部３８は、コスト算出部３５により算出された強化コストに応じて最低譲受額を設定する。

そして、第１の変形例では、装備品Ｕのパラメータについて、ユーザＢ（第２ユーザ）からの譲受の申し出が譲受条件を満たす場合、具体的には、ユーザＢが指定した譲受額が最低譲受額以上である場合に限り、ユーザＢからの譲受の申し出を受け付けることになっている。

次に、第１の変形例に係るパラメータ処理フローとして、取り引きされる成長パラメータがランク値である場合の流れを説明する。第１の変形例に係るパラメータ処理フローの各ステップ（具体的には、Ｓ０６１～Ｓ０６４、Ｓ０６６～Ｓ０７１、Ｓ０７３、Ｓ０７５～Ｓ０７９）は、図１５Ａ、１５Ｂから分かるように、上記の実施形態に係るパラメータ処理フローの各ステップと概ね共通している。

一方、第１の変形例では、図１５Ａ、１５Ｂに示すように、サーバ１０Ｘが、これまでに装備品Ｕの強化に費やされた強化コストを算出した後に、算出した強化コストに応じて最低譲受額を設定する（Ｓ０６５）。最低譲受額は、強化コストに相当する額又はそれ以上の額に設定されるのが好ましい。

また、第１の変形例では、装備品Ｕのランク値について、サーバ１０ＸがユーザＡから譲渡の申し出を受け付けた後にユーザＢが譲受の申し出を行うと、サーバ１０Ｘが、ユーザＢによって指定された譲受額（販売額）が最低譲受額以上であるかを判定する（Ｓ０７２）。そして、ユーザＢによって指定された譲受額が最低譲受額以上である場合、サーバ１０Ｘは、装備品Ｕのランク値についてユーザＢからの譲渡の申し出を受け付ける（Ｓ０７３）。

一方、ユーザＢによって指定された譲受額が最低譲受額を下回る場合には、サーバ１０Ｘは、ユーザＢからの譲渡の申し出を受け付けない。この場合、ユーザＡから譲渡の申し出を受け付けてから所定時間が経過するまでの間に（Ｓ０７４）、最低譲受額以上の譲受額を指定している申し出がなければ、その時点でパラメータ取引フローが終了する。このような手順によれば、ユーザＡは、これまでにコストを費やして上げてきた装備品Ｕのランク値が最低譲受額を下回る額にて譲渡（販売）される事態を回避することができるので、ユーザＡに対して取引上の損失を与えないようにすることができる。

なお、上記の状況でパラメータ取引フローが終了した場合（Ｓ０７４でＹｅｓのケース）においては、ゲームの運営会社等が、最低譲受額と同額又はそれ以上の額にて装備品Ｕのランク値を買い取ってもよい。

また、上述した第１の変形例に係るパラメータ取引フローは、取り引きされる成長パラメータがランク値である場合に限定されず、取り引きされる成長パラメータがレベルである場合にも適用することができる。

［第２の変形例について］
上記の実施形態では、装備品Ｕのランク値について、設定された譲渡範囲のランク値を一括して取引（売買）し、パラメータの譲受を申し出た一人のユーザが譲渡範囲のランク値をすべて譲受（購入）することとした。ただし、本発明は、このような実施形態に限られず、別の形態（以下、第２の変形例という。）が考えられる。以下に、第２の変形例について、図１６Ａ、１６Ｂを参照しながら説明する。
図１６Ａ、１６Ｂは、第２の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す。

第２の変形例では、装備品Ｕの成長パラメータについて譲渡範囲が設定されると、その譲渡範囲が複数の小範囲に分けられる。複数の小範囲は、それぞれの上限及び下限が互いに異なる範囲である。そして、第２の変形例では、譲渡範囲のランク値が複数の小単位に分けて譲渡（販売）され、換言すると、譲渡されたランク値を小範囲毎に譲受（購入）することができる。これにより、第２ユーザであるユーザＢは、譲渡範囲のランク値全てを購入する必要がなく、希望する範囲（小範囲）のランク値を購入すればよいので、より合理的且つ経済的にランク値を購入することができる。また、譲渡範囲のランク値を複数の小単位に分けて譲渡（販売）するため、複数のユーザに対してランク値を小単位毎に譲渡することができる。

なお、譲渡範囲を複数の小範囲に分ける場合の手順については、特に制限はなく、例えば、各小範囲の上限及び下限等は、任意の値に決めてもよい。また、複数の小範囲は、ランク値を譲渡するユーザＡが決めてもよく、あるいはランク値を譲受するユーザＢ及びその他のユーザが決めてもよく、あるいはサーバ１０側で自動的に決めてもよい。

また、第２の変形例では、譲渡されたランク値を小範囲毎に譲受する際、譲渡範囲の上限に最も近い（つまり、上限が最も大きい）小範囲から順に、それぞれの小範囲のランク値を譲受することになっており、換言すると、譲渡範囲の上限に最も近い小範囲から順に譲受の申し出を受け付ける。具体例を挙げて説明すると、「＋３→０」に設定された譲渡範囲が「＋３→＋２」、「＋２→＋１」及び「＋１→０」の小範囲に分けられた場合には、この順で、各小範囲のランク値が譲受（購入）される。

次に、第２の変形例に係るパラメータ処理フローとして、取り引きされる成長パラメータがランク値である場合の流れを説明する。なお、以下では、ランク値を譲受するユーザ（すなわち、第２ユーザ）がユーザＢ以外にも存在するケースを想定し、これらのユーザをまとめて「ユーザＢ等」と呼ぶこととする。

第２の変形例に係るパラメータ処理フローの各ステップは、図１６Ａ、１６Ｂから分かるように、第１の変形例に係るパラメータ処理フローの各ステップと概ね共通している。すなわち、第２の変形例においても、先ず、第１ユーザであるユーザＡが装備品Ｕのランク値について譲渡の申し出を行い（Ｓ０８１）、ランク値についての譲渡範囲が設定される（Ｓ０８２）。第２の変形例では、その後、例えばユーザＡのユーザ端末１１にて、ユーザＡの操作に基づき、譲渡範囲が複数の小範囲に分けられる（Ｓ０８３）。なお、以下では、装備品Ｕのランク値の譲渡範囲が「＋３→０」に設定され、「＋３→＋２」、「＋２→＋１」及び「＋１→０」の小範囲に分かれることとする。

サーバ１０は、装備品Ｕのランク値について、譲渡範囲及び複数の小範囲等を示すデータをユーザ端末１１から受信することでユーザＡからの譲渡の申し出を受け付ける（Ｓ０８４）。その後、サーバ１０は、装備品Ｕのランク値の変更履歴に基づき、これまでに装備品Ｕの強化に費やされた強化コストを算出する（Ｓ０８５）。この際、強化コストは、譲渡範囲を分けた複数の小範囲の各々について算出される。すなわち、サーバ１０は、ランク値が「０→＋１」に上がる際に費やされた強化コスト、ランク値が「＋１→＋２」に上がる際に費やされた強化コスト、及び、ランク値が「＋２→＋３」に上がる際に費やされた強化コストをそれぞれ算出する。

また、サーバ１０は、小範囲毎に算出された強化コストに応じて、各小範囲のランク値についての最低譲受額を設定する（Ｓ０８６）。つまり、サーバ１０は、ランク値についての譲受条件である最低譲受額を小範囲毎に設定する。その後、装備品Ｕのランク値についての譲渡範囲及び複数の小範囲、並びに、各小範囲のランク値に対して設定された最低譲受額等を示す取引データがサーバ側記憶部３３に記録されて蓄積される（Ｓ０８７）。続くステップＳ０８８～Ｓ０９０は、上述した実施形態に係るパラメータ取引フローのステップＳ０４８～Ｓ０５０やステップＳ０６７～Ｓ０６９と同様である。

一方、ユーザＢ等の各ユーザは、取引データを検索し、装備品Ｕのランク値についてユーザＡが申し出た譲渡の内容がユーザＢにとって好適である場合には、そのランク値に対してパラメータ譲受（購入）の申し出を行う（Ｓ０９１）。この際、ユーザＢ等の各ユーザは、一つの小範囲を取引単位とし、当該小範囲に該当するランク値について譲受の申し出を行う。譲受の申し出は、上限が最も大きい小範囲から順に受け付け可能であり、具体的には「＋３→＋２」、「＋２→＋１」、「＋１→０」の順に受け付けられる。

サーバ１０は、ユーザＢ等の各ユーザから譲受の申し出を受け付けるにあたり、各ユーザが装備品Ｕと同等の装備品を所持しているか否か、及び、各ユーザが指定した譲受額が最低譲受額以上であるか否かを判定する（Ｓ０９２、Ｓ０９３）。ここで、装備品Ｕと同等の装備品とは、装備品Ｕと同じ区分に分類される装備品であって、そのランク値の現在値が、譲渡を申し出た小範囲の下限と一致する装備品である。

上記の判定Ｓ０９２、Ｓ０９３は、小範囲毎に行われる。そして、ある一つの小範囲（以下、取引小範囲）のランク値について譲受を申し出たユーザが装備品Ｕと同等の装備品を所持していない場合（Ｓ０９２でＮｏ）、その時点で当該取引小範囲についてのパラメータ取引フローが終了する。
また、ユーザＡから譲渡の申し出を受け付けてから所定時間が経過するまでの間に、取引小範囲について最低譲受額以上の譲受額を指定した譲受の申し出がない場合（Ｓ０９３でＮｏ、且つＳ０９４でＹｅｓ）にも、当該取引小範囲についてのパラメータ取引フローが終了する。この場合には、ゲームの運営会社等が、最低譲受額と同額又はそれ以上の額にて当該小範囲のランク値を買い取ってもよい。

その後のステップＳ０９５～Ｓ０９９は、上述した実施形態に係るパラメータ取引フローのステップ（具体的には、ステップＳ０５４～Ｓ０５８、ステップＳ０７５～Ｓ０７９）と同様である。

そして、第２の変形例では、ユーザＢ等の各人が譲受の申し出を行ってからの一連のステップＳ０９１～Ｓ０９９が小範囲毎に実施され、換言すると、複数の小範囲のうち、ランク値の取引が未確定である小範囲が残っている場合には（Ｓ０１００）、ステップＳ０９１～Ｓ０９９が繰り返される。そして、すべての小範囲について取引が確定し、各小範囲のランク値に対する取引処理（譲渡及び譲受）が完了した時点で（Ｓ１００でＹｅｓ）、第２の変形例に係るパラメータ取引フローが終了する。

なお、上述のフローでは、複数の小範囲の各々について強化コストを算出し、小範囲毎に算出された強化コストに応じて、各小範囲のランク値についての最低譲受額を設定し、最低譲受額以上の譲受額を指定したユーザに対して当該ランク値を譲渡することとした。ただし、これに限定されるものではなく、複数の小範囲のうち、強化コストが所定値以上である小範囲については、譲渡不可（販売不可）とし、強化コストが所定値未満である小範囲のランク値のみを譲渡できるようにしてもよい。あるいは、複数の小範囲の中に、強化コストが所定値以上である小範囲が一つ以上存在する場合には、複数の小範囲のすべて、つまり譲渡範囲全体に亘って譲渡不可としてもよい。

また、上述した第２の変形例に係るパラメータ取引フローは、取り引きされる成長パラメータがランク値である場合に限定されず、取り引きされる成長パラメータがレベルである場合にも適用することができる。

［その他の実施形態］
以上までに、本発明の情報処理装置、情報処理方法、及びプログラムに関して、具体例を挙げて説明してきたが、上述した実施形態は、あくまでも一例に過ぎず、他の実施形態も考えられ得る。

上記の実施形態では、サーバコンピュータ（サーバ１０、１０Ｘ）が本発明の情報処理装置の機能を発揮することとしたが、上記サーバコンピュータが有する機能のうちの一部、例えばパラメータ変更部４３が第２ユーザのユーザ端末１２に備わってもよい。その場合には、ユーザ端末１２が、第２ユーザが所持するゲーム媒体の成長パラメータを、第２ユーザが第１ユーザから譲受した成長パラメータに応じて変更してもよい。

また、上記の実施形態では、取引（売買）される成長パラメータが、装備品のレベル又はランク値であることとしたが、これに限定されず、装備品以外のゲーム媒体、例えばゲーム内のキャラクタの成長パラメータであってもよく、具体的には、キャラクタの能力、体力、知力、運気、人気及びその他のステータス値であってもよい。

また、成長パラメータは、レベル及びランク値のような数値によって表されるものに限られない。すなわち、取り引きされる成長パラメータは、ゲーム媒体の優劣順位又は品質の高低を表すものであって、ゲームの進行具合に応じて変化（詳しくは上下）するものであればよく、例えば「Ａ、Ｂ、Ｃ・・・」や「金、銀、銅・・・」のような文字や記号によって表されるものであってもよい。また、ゲーム媒体のレア度（入手困難性）及びレア度に基づく区分を成長させることができるゲームでは、レア度を成長パラメータとして取引を行ってもよい。

また、本実施形態では、成長パラメータの値が大きい（上がる）ほど、その成長パラメータを有するゲーム媒体の性能又は能力が高く優れていることとしたが、これに限定されるものではない。成長パラメータは、成長に応じて初期値から減少する（下がる）値であってもよい。その場合には、成長パラメータが小さい（下がる）ほど、その成長パラメータを有するゲーム媒体の性能又は能力が高く優れていることになる。

また、上記の実施形態では、ユーザ間で成長パラメータが有料で取り引きされることとしたが、これに限定されず、成長パラメータの取引（つまり、パラメータの譲渡及び譲受）が無料で実施されてもよい。

また、上記の実施形態では、第２ユーザが第１ユーザから成長パラメータ（具体的には、レベルに相当する経験値やランク値）を譲受すると、それを契機として、第２ユーザが所持するゲーム媒体の成長パラメータを、譲受した成長パラメータに応じて変更することとした。ただし、これに限定されるものではなく、例えば、第２ユーザが第１ユーザから譲受した成長パラメータを一時的にストックすることができてもよい。この場合、パラメータ譲受後、任意の時間に第２ユーザが強化対象のゲーム媒体を指定し、そのゲーム媒体の成長パラメータを、ストックしておいた成長パラメータに応じて変化させてもよい。また、ストックした成長パラメータを第２ユーザのゲーム媒体の強化に利用できる権限（利用回数）が設定され、利用回数だけ、第２ユーザが、ストックした成長パラメータを用いて強化するゲーム媒体を入れ替えることができるようにしてもよい。

［まとめ］
本発明では、以下に示す構成によって奏する効果が得られる。
[１] 本発明の情報処理装置は、第１ユーザがゲームにて成長させる第１ゲーム媒体の成長パラメータについて、第１ユーザから譲渡の申し出を受け付け、且つ、第２ユーザから譲受の申し出を受け付ける受付部と、受付部が第１ユーザ及び第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、第２ユーザがゲームにて成長させる第２ゲーム媒体の成長パラメータを、第２ユーザが第１ユーザから譲受した成長パラメータに応じて変更するパラメータ変更部と、を備える。
上記の構成によれば、第１ユーザは、これまでのゲーム内で強化してきたゲーム媒体の成長パラメータを譲渡し、第２ユーザは、第１ユーザが譲渡した成長パラメータを譲受して、自分のゲーム媒体の成長パラメータを変更させるのに利用することができる。このようにゲーム媒体の成長パラメータを対象としてユーザ間で取引を実施することができれば、ユーザ間の交流が活性化され、これにより、ゲームプレイの促進を図ることができる。

[２] また、本発明の情報処理装置において、受付部が第１ユーザ及び第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、パラメータ変更部が、第２ユーザが第１ユーザから譲受した成長パラメータに応じて第２ゲーム媒体の成長パラメータを上げ、且つ、第１ユーザが第２ユーザに譲渡した成長パラメータに応じて第１ゲーム媒体の成長パラメータを下げてもよい。
上記の構成によれば、ユーザ間でパラメータ取引が行われた場合に、その取引内容をゲームに適切に反映させることができる。つまり、パラメータ取引を行った第１ユーザ及び第２ユーザの各々のゲーム媒体（詳しくは、取引対象品及び被強化品）については、取引によって成長パラメータが変更されるため、各ユーザがゲームを公平にプレイすることができる。また、パラメータ取引に伴う使用権限の移譲はなく、第１ゲーム媒体の使用権限は取引後にも第１ユーザに残るので、第１ユーザのパラメータ取引に対する意欲を喚起することができる。

[３] また、本発明の情報処理装置において、第１ゲーム媒体の成長パラメータについての第２ユーザからの譲受の申し出が、第１ゲーム媒体と対応付けられた申し出受付条件を満たす場合に、受付部によって、第２ユーザからの譲受の申し出が受け付け可能となってもよい。
上記の構成によれば、第２ユーザからの譲受の申し出に対して申し出受付条件を設定することで、ゲーム進行上におけるユーザ間の不平等を是正して公平な取引を実現することができる。例えば、レア度が低い区分のゲーム媒体の成長パラメータを譲受（購入）し、譲受した成長パラメータを利用して、レア度が高い区分のゲーム媒体を成長させることは、ゲームの進行上の公正さを欠くため、好ましい行為ではない。そこで、取引対象のゲーム媒体と同じ区分に属するゲーム媒体を第２ユーザが所持することを申し出受付条件に設定することにより、ゲームの公正なプレイをユーザに順守させることができる。

[４] また、本発明の情報処理装置は、各ユーザがゲームにて成長させるゲーム媒体の状態を各ユーザの操作に応じて変える状態変更部を備えてもよい。この場合、第１ゲーム媒体の成長パラメータについて受付部が第１ユーザから譲渡の申し出を受け付けてから所定の条件が成立するまでの間、状態変更部は、第１ゲーム媒体の状態を変えないと、好適である。
上記の構成では、第１ゲーム媒体の成長パラメータについて第１ユーザから譲渡の申し出があった場合に、取引成立前に第１ゲーム媒体の状態が変更するために取引内容に影響が及んでしまう事態を回避することができる。

[５] また、本発明の情報処理装置は、各ユーザのゲーム媒体の使用に応じてゲームを進行させるゲーム進行部を備えてもよい。この場合、第１ゲーム媒体の成長パラメータについて受付部が第１ユーザから譲渡の申し出を受け付けてから所定の条件が成立するまでの間、ゲーム進行部は、第１ゲーム媒体の成長パラメータを維持したまま、第１ユーザの第１ゲーム媒体の使用に応じてゲームを進行させると、好適である。
上記の構成では、第１ユーザが第１ゲーム媒体を使用してゲームをプレイしている場合、第１ユーザが第１ゲーム媒体の成長パラメータについて譲渡の申し出を行ってから第２ユーザから譲受の申し出があるまでの間は、第１ゲーム媒体の成長パラメータが維持される。これにより、第１ゲーム媒体を使用してゲームをプレイしている間のパラメータ変更による不利益（例えば、パラメータ変更に伴ってゲーム難易度が変わる等）を、第１ユーザに対して与えないようにすることができる。

［６］ また、本発明の情報処理装置において、所定の条件が成立した時点で第１ユーザがゲームにて第１ゲーム媒体を使用している場合、パラメータ変更部は、第１ユーザの第１ゲーム媒体の使用が終了するまで第１ゲーム媒体の成長パラメータを変えず、第１ユーザの第１ゲーム媒体の使用が終了した際に、第１ゲーム媒体の成長パラメータを変更するとよい。
上記の構成では、第１ユーザが第１ゲーム媒体を使用してゲームをプレイしている場合、第１ユーザが第１ゲーム媒体の使用を終了するまでは、第１ゲーム媒体のパラメータが維持される。これにより、第１ゲーム媒体の使用中におけるパラメータ変更による不利益を、第１ユーザに与えないようにすることができる。

[７] また、本発明の情報処理装置において、各ユーザがゲーム媒体を使用してゲームを進行させる間において、パラメータ変更部は、各ユーザがゲーム内のイベントをクリアすることでゲーム媒体に対して加算される経験値の累計値に応じて、ゲーム媒体の成長パラメータを変更してもよい。この場合、第１ゲーム媒体の成長パラメータについて、受付部が第１ユーザ及び第２ユーザから申し出を受け付けて所定の条件が成立した場合に、パラメータ変更部は、第２ユーザが第１ユーザから譲受した成長パラメータに基づいて変わる第２ゲーム媒体の経験値の累計値に応じて、第２ゲーム媒体の成長パラメータを変更させると好適である。
上記の構成によれば、第２ユーザが第１ユーザから譲受した成長パラメータを経験値に換算し、換算された経験値に応じて、第２ゲーム媒体の成長パラメータを変更する。この場合には、第２ゲーム媒体の成長パラメータの現在値に関わらず、第１ユーザから譲受した成長パラメータを、第２ゲーム媒体の成長のために有効に利用することができる。

[８] また、本発明の情報処理装置は、各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部と、第１ゲーム媒体の成長パラメータについて受付部が第１ユーザから譲渡の申し出を受け付けた場合に、第１ゲーム媒体のパラメータ変更履歴に基づき、これまでに第１ゲーム媒体に費やされたコストに応じて、第１ゲーム媒体の成長パラメータについての譲受条件を設定する条件設定部と、をさらに備えてもよい。この場合に、第１ゲーム媒体の成長パラメータについて、第２ユーザからの譲受の申し出が譲受条件を満たす場合に、受付部は、第２ユーザからの譲受の申し出を受け付けてもよい。
上記の構成では、第１ゲーム媒体に費やされたコストに応じて設定される譲受条件を満たす場合に限り、第２ユーザからのパラメータ譲受の申し出を受け付ける。これにより、コストに見合った譲受の申し出が第２ユーザからなされるので、パラメータ取引にて第１ユーザがコストとの関係で損失を被る事態を回避することができる。

[９] また、本発明の情報処理装置は、各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部を備えてもよい。この場合において、本発明の情報処理装置は、第１ゲーム媒体の成長パラメータについて受付部が第１ユーザから譲渡の申し出を受け付けた場合に、第１ゲーム媒体のパラメータ変更履歴に基づき、これまでに第１ゲーム媒体に費やされたコストが所定値以上である場合には、第１ゲーム媒体の成長パラメータについて、第１ユーザからの譲渡の申し出を拒否する拒否部と、をさらに備えてもよい。
上記の構成では、第１ゲーム媒体に費やされたコストが所定値を超える場合、第１ユーザからのパラメータ譲渡の申し出を拒否する。これにより、コストとの関係で第１ユーザにとって不利となるパラメータ取引をキャンセルし、そのような取引によって第１ユーザが損失を被る事態を回避することができる。

[１０] また、上記の構成において、コストは、これまでに第１ゲーム媒体の成長パラメータの変更に費やされたコストであるとよい。この場合には、第１ゲーム媒体の成長に費やされたコストとの関係で第１ユーザにとって不利となる（損失を被る）事態を回避することができる。

[１１] また、本発明の情報処理装置において、第１ゲーム媒体の成長パラメータについて、受付部は、第１ゲーム媒体の成長パラメータに対して設定された譲渡範囲内での譲受の申し出を第２ユーザから受け付けてもよい。
上記の構成によれば、第１ゲーム媒体の成長パラメータについて、当該成長パラメータに対して設定された譲渡範囲内で第２ユーザが譲受を申し出ることになる。これにより、第１ゲーム媒体の成長パラメータの取引（ユーザ間での取引）が譲渡範囲内で適切になされるようになる。

[１２] また、本発明の情報処理装置において、譲渡範囲が互いに異なる複数の小範囲に分かれている場合に、受付部は、複数の小範囲のうち、譲渡範囲の上限に最も近い小範囲から順に、小範囲における成長パラメータの譲受の申し出を第２ユーザから受け付けてもよい。
上記の構成によれば、第１ゲーム媒体の成長パラメータに対して設定された譲渡範囲を複数の小範囲に分け、第２ユーザは、小範囲を単位として成長パラメータを譲受することができる。すなわち、第２ユーザは、譲渡範囲全体の成長パラメータをまとめて譲受する必要がなく、所望の範囲（小範囲）にある成長パラメータを効率よく譲受することができる。

[１３] また、本発明の情報処理装置において、譲渡範囲の下限が、第１ユーザが入手した時点での第１ゲーム媒体の成長パラメータを下回らないように、譲渡範囲が設定されてもよい。
上記の構成では、取引後の第１ゲーム媒体の成長パラメータが入手時点でのパラメータ（初期値）を下回らないようにすることができる。これにより、第１ユーザは、パラメータ取引の実施後にも第１ゲーム媒体を適切な状態（具体的には、成長パラメータが正常な範囲にある状態）で使用することができる。

[１４] また、本発明の情報処理装置において、各ユーザがゲームにて成長させるゲーム媒体の成長パラメータには、ゲームの進行に応じて変化する可変値を含み、各ユーザがゲームにてゲーム媒体を使用している間に特定の成長条件が成立した場合に、パラメータ変更部は、予め定められた確率に応じてゲーム媒体の可変値を増やしてもよい。この場合において、受付部は、第１ゲーム媒体の可変値について、第１ユーザから譲渡の申し出を受け付け、且つ、第２ユーザから譲受の申し出を受け付けると好適である。
上記の構成では、取引される成長パラメータが、予め定められた確率で増える可変値である場合、その成長パラメータは、所定の条件を満たした場合に確実に増える成長パラメータと比較して取引性が高い（パラメータ取引に対するユーザの意欲を喚起させ易い）。したがって、上記の可変値を取引対象とすることで、ユーザ間でのパラメータ取引の活性化をより一層促すことができる。

[１５] また、本発明の情報処理方法は、コンピュータが、第１ユーザがゲームにて成長させる第１ゲーム媒体の成長パラメータについて、第１ユーザから譲渡の申し出を受け付け、且つ、第２ユーザから譲受の申し出を受け付け、第１ユーザ及び第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータが、第２ユーザがゲームにて成長させる第２ゲーム媒体の成長パラメータを、第２ユーザが第１ユーザから譲受した成長パラメータに応じて変更することを特徴とする。
上記の方法によれば、ゲーム媒体の成長パラメータを対象としてユーザ間で取引を実施することができれば、新たな形態での取引が実現されるので、ユーザ間の交流が活性化され、ゲームプレイの促進を図ることができる。

[１６] また、本発明のプログラムは、コンピュータに、第１ユーザがゲームにて成長させる第１ゲーム媒体の成長パラメータについて、第１ユーザから譲渡の申し出を受け付けさせ、且つ、第２ユーザから譲受の申し出を受け付けさせ、第１ユーザ及び第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータに、第２ユーザがゲームにて成長させる第２ゲーム媒体の成長パラメータを、第２ユーザが第１ユーザから譲受した成長パラメータに応じて変更させるプログラムである。このプログラムをコンピュータに実行させることで、ユーザ間での取引として、ゲーム媒体の成長パラメータを対象とする新たな形態の取引が実現される。これにより、ユーザ間の交流が活性化され、ゲームプレイの促進を図ることができる。

１０，１０Ｘ サーバ（情報処理装置、コンピュータ）
１０Ａ プロセッサ
１０Ｂ メモリ
１０Ｃ 通信用インタフェース
１０Ｄ 出力デバイス
１１，１２ ユーザ端末
１３ プロセッサ
１４ メモリ
１５ 通信用インタフェース
１６ 入力デバイス
１７ 出力デバイス
２１ 端末側受付部
２２ 端末側送受信部
２３ 端末側記憶部
２４ 表示実行部
３１ ゲーム進行用受付部
３２ ゲーム進行部
３３ サーバ側記憶部（記憶部）
３４ 取引用受付部（受付部）
３５ コスト算出部
３６ 取引処理部
３７ 拒否部
３８ 条件設定部
４１ 状態変更部
４２ 経験値付与部
４３ パラメータ変更部
ＮＴ 通信用ネットワーク

Claims (16)

1. 第１ユーザがゲームにて成長させる第１ゲーム媒体の成長パラメータについて、前記第１ユーザから譲渡の申し出を受け付け、且つ、第２ユーザから譲受の申し出を受け付ける受付部と、
   前記受付部が前記第１ユーザ及び前記第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、前記第２ユーザが前記ゲームにて成長させる第２ゲーム媒体の成長パラメータを、前記第２ユーザが前記第１ユーザから譲受した成長パラメータに応じて変更するパラメータ変更部と、を備え、
   前記成長パラメータの譲受の対価に応じた量の価値を、前記第２ユーザの前記価値の所持量から減じ、前記第１ユーザの前記価値の所持量に加算することにより前記所定の条件が成立する、情報処理装置。
2. 前記受付部が前記第１ユーザ及び前記第２ユーザからの申し出を受け付けて前記所定の条件が成立した場合に、前記パラメータ変更部が、前記第２ユーザが前記第１ユーザから譲受した成長パラメータに応じて前記第２ゲーム媒体の成長パラメータを上げ、且つ、前記第１ユーザが前記第２ユーザに譲渡した成長パラメータに応じて前記第１ゲーム媒体の成長パラメータを下げる、請求項１に記載の情報処理装置。
3. 前記第１ゲーム媒体の成長パラメータについての前記第２ユーザからの譲受の申し出が、前記第１ゲーム媒体と対応付けられた申し出受付条件を満たす場合に、前記受付部によって、前記第２ユーザからの譲受の申し出が受け付け可能となる、請求項１又は２に記載の情報処理装置。
4. 各ユーザが前記ゲームにて成長させるゲーム媒体の状態を、前記各ユーザの操作に応じて変える状態変更部を備え、
   前記第１ゲーム媒体の成長パラメータについて前記受付部が前記第１ユーザから譲渡の申し出を受け付けてから前記所定の条件が成立するまでの間、前記状態変更部は、前記第１ゲーム媒体の状態を変えない、請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 各ユーザのゲーム媒体の使用に応じて前記ゲームを進行させるゲーム進行部を備え、
   前記第１ゲーム媒体の成長パラメータについて前記受付部が前記第１ユーザから譲渡の申し出を受け付けてから前記所定の条件が成立するまでの間、前記ゲーム進行部は、前記第１ゲーム媒体の成長パラメータを維持したまま、前記第１ユーザの前記第１ゲーム媒体の使用に応じて前記ゲームを進行させる、請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記所定の条件が成立した時点で前記第１ユーザが前記ゲームにて前記第１ゲーム媒体を使用している場合、前記パラメータ変更部は、前記第１ユーザの前記第１ゲーム媒体の使用が終了するまで前記第１ゲーム媒体の成長パラメータを変えず、前記第１ユーザの前記第１ゲーム媒体の使用が終了した際に、前記第１ゲーム媒体の成長パラメータを変更する、請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 各ユーザがゲーム媒体を使用して前記ゲームを進行させる間において、前記パラメータ変更部は、前記各ユーザが前記ゲーム内のイベントをクリアすることで前記ゲーム媒体に対して加算される経験値の累計値に応じて、前記ゲーム媒体の成長パラメータを変更し、
   前記第１ゲーム媒体の成長パラメータについて、前記受付部が前記第１ユーザ及び前記第２ユーザから申し出を受け付けて前記所定の条件が成立した場合に、前記パラメータ変更部は、前記第２ユーザが前記第１ユーザから譲受した成長パラメータに基づいて変わる前記第２ゲーム媒体の前記経験値の累計値に応じて、前記第２ゲーム媒体の成長パラメータを変更させる、請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部と、
   前記第１ゲーム媒体の成長パラメータについて前記受付部が前記第１ユーザから譲渡の申し出を受け付けた場合に、前記第１ゲーム媒体の前記パラメータ変更履歴に基づき、これまでに前記第１ゲーム媒体に費やされたコストに応じて、前記第１ゲーム媒体の成長パラメータについての譲受条件を設定する条件設定部と、をさらに備え、
   前記第１ゲーム媒体の成長パラメータについて、前記第２ユーザからの譲受の申し出が前記譲受条件を満たす場合に、前記受付部は、前記第２ユーザからの譲受の申し出を受け付ける、請求項１乃至７のいずれか一項に記載の情報処理装置。
9. 各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部と、
   前記第１ゲーム媒体の成長パラメータについて前記受付部が前記第１ユーザから譲渡の申し出を受け付けた場合に、前記第１ゲーム媒体の前記パラメータ変更履歴に基づき、これまでに前記第１ゲーム媒体に費やされたコストが所定値以上である場合には、前記第１ゲーム媒体の成長パラメータについて、前記第１ユーザからの譲渡の申し出を拒否する拒否部と、をさらに備える請求項１乃至７のいずれか一項に記載の情報処理装置。
10. 前記コストは、これまでに前記第１ゲーム媒体の成長パラメータの変更に費やされたコストである、請求項８又は９に記載の情報処理装置。
11. 前記第１ゲーム媒体の成長パラメータについて、前記受付部は、前記第１ゲーム媒体の成長パラメータに対して設定された譲渡範囲内での譲受の申し出を前記第２ユーザから受け付ける、請求項１乃至１０のいずれか一項に記載の情報処理装置。
12. 前記譲渡範囲が互いに異なる複数の小範囲に分かれている場合に、前記受付部は、複数の前記小範囲のうち、前記譲渡範囲の上限に最も近い前記小範囲から順に、前記小範囲における成長パラメータの譲受の申し出を前記第２ユーザから受け付ける、請求項１１に記載の情報処理装置。
13. 前記譲渡範囲の下限が、前記第１ユーザが入手した時点での前記第１ゲーム媒体の成長パラメータを下回らないように、前記譲渡範囲が設定される、請求項１１又は１２に記載の情報処理装置。
14. 各ユーザが前記ゲームにて成長させるゲーム媒体の成長パラメータには、前記ゲームの進行に応じて変化する可変値を含み、
    前記各ユーザが前記ゲームにて前記ゲーム媒体を使用している間に特定の成長条件が成立した場合に、前記パラメータ変更部は、予め定められた確率に応じて前記ゲーム媒体の前記可変値を増やし、
    前記受付部は、前記第１ゲーム媒体の前記可変値について、前記第１ユーザから譲渡の申し出を受け付け、且つ、前記第２ユーザから譲受の申し出を受け付ける、請求項１乃至１３のいずれか一項に記載の情報処理装置。
15. コンピュータが、第１ユーザがゲームにて成長させる第１ゲーム媒体の成長パラメータについて、前記第１ユーザから譲渡の申し出を受け付け、且つ、第２ユーザから譲受の申し出を受け付け、
    前記第１ユーザ及び前記第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータが、前記第２ユーザが前記ゲームにて成長させる第２ゲーム媒体の成長パラメータを、前記第２ユーザが前記第１ユーザから譲受した成長パラメータに応じて変更し、
    前記成長パラメータの譲受の対価に応じた量の価値を、前記第２ユーザの前記価値の所持量から減じ、前記第１ユーザの前記価値の所持量に加算することにより前記所定の条件が成立する、情報処理方法。
16. コンピュータに、第１ユーザがゲームにて成長させる第１ゲーム媒体の成長パラメータについて、前記第１ユーザから譲渡の申し出を受け付けさせ、且つ、第２ユーザから譲受の申し出を受け付けさせ、
    前記第１ユーザ及び前記第２ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータに、前記第２ユーザが前記ゲームにて成長させる第２ゲーム媒体の成長パラメータを、前記第２ユーザが前記第１ユーザから譲受した成長パラメータに応じて変更させ、
    前記成長パラメータの譲受の対価に応じた量の価値を、前記第２ユーザの前記価値の所持量から減じ、前記第１ユーザの前記価値の所持量に加算することにより前記所定の条件が成立する、プログラム。
    

Images