IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ミクシィの特許一覧

特許7307352情報処理装置、情報処理方法、及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-04
(45)【発行日】2023-07-12
(54)【発明の名称】情報処理装置、情報処理方法、及びプログラム
(51)【国際特許分類】
   A63F 13/79 20140101AFI20230705BHJP
   A63F 13/58 20140101ALI20230705BHJP
   G06Q 30/06 20230101ALI20230705BHJP
【FI】
A63F13/79 520
A63F13/58
G06Q30/06
【請求項の数】 16
(21)【出願番号】P 2020206578
(22)【出願日】2020-12-14
(65)【公開番号】P2022093864
(43)【公開日】2022-06-24
【審査請求日】2022-07-26
【早期審査対象出願】
(73)【特許権者】
【識別番号】500033117
【氏名又は名称】株式会社MIXI
(74)【代理人】
【識別番号】100152984
【弁理士】
【氏名又は名称】伊東 秀明
(74)【代理人】
【識別番号】100149401
【弁理士】
【氏名又は名称】上西 浩史
(72)【発明者】
【氏名】小牧 信貴
【審査官】柳 重幸
(56)【参考文献】
【文献】特開2002-360933(JP,A)
【文献】特開2010-075433(JP,A)
【文献】特開2013-202111(JP,A)
【文献】特開2015-126785(JP,A)
【文献】特開2016-131767(JP,A)
【文献】特開2017-136255(JP,A)
【文献】特許第6781298(JP,B1)
(58)【調査した分野】(Int.Cl.,DB名)
A63F 13/00-13/98
G06Q 30/06
(57)【特許請求の範囲】
【請求項1】
第1ユーザがゲームにて成長させる第1ゲーム媒体の成長パラメータについて、前記第1ユーザから譲渡の申し出を受け付け、且つ、第2ユーザから譲受の申し出を受け付ける受付部と、
前記受付部が前記第1ユーザ及び前記第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、前記第2ユーザが前記ゲームにて成長させる第2ゲーム媒体の成長パラメータを、前記第2ユーザが前記第1ユーザから譲受した成長パラメータに応じて変更するパラメータ変更部と、を備え
前記成長パラメータの譲受の対価に応じた量の価値を、前記第2ユーザの前記価値の所持量から減じ、前記第1ユーザの前記価値の所持量に加算することにより前記所定の条件が成立する、情報処理装置。
【請求項2】
前記受付部が前記第1ユーザ及び前記第2ユーザからの申し出を受け付けて前記所定の条件が成立した場合に、前記パラメータ変更部が、前記第2ユーザが前記第1ユーザから譲受した成長パラメータに応じて前記第2ゲーム媒体の成長パラメータを上げ、且つ、前記第1ユーザが前記第2ユーザに譲渡した成長パラメータに応じて前記第1ゲーム媒体の成長パラメータを下げる、請求項1に記載の情報処理装置。
【請求項3】
前記第1ゲーム媒体の成長パラメータについての前記第2ユーザからの譲受の申し出が、前記第1ゲーム媒体と対応付けられた申し出受付条件を満たす場合に、前記受付部によって、前記第2ユーザからの譲受の申し出が受け付け可能となる、請求項1又は2に記載の情報処理装置。
【請求項4】
各ユーザが前記ゲームにて成長させるゲーム媒体の状態を、前記各ユーザの操作に応じて変える状態変更部を備え、
前記第1ゲーム媒体の成長パラメータについて前記受付部が前記第1ユーザから譲渡の申し出を受け付けてから前記所定の条件が成立するまでの間、前記状態変更部は、前記第1ゲーム媒体の状態を変えない、請求項1乃至3のいずれか一項に記載の情報処理装置。
【請求項5】
各ユーザのゲーム媒体の使用に応じて前記ゲームを進行させるゲーム進行部を備え、
前記第1ゲーム媒体の成長パラメータについて前記受付部が前記第1ユーザから譲渡の申し出を受け付けてから前記所定の条件が成立するまでの間、前記ゲーム進行部は、前記第1ゲーム媒体の成長パラメータを維持したまま、前記第1ユーザの前記第1ゲーム媒体の使用に応じて前記ゲームを進行させる、請求項1乃至4のいずれか一項に記載の情報処理装置。
【請求項6】
前記所定の条件が成立した時点で前記第1ユーザが前記ゲームにて前記第1ゲーム媒体を使用している場合、前記パラメータ変更部は、前記第1ユーザの前記第1ゲーム媒体の使用が終了するまで前記第1ゲーム媒体の成長パラメータを変えず、前記第1ユーザの前記第1ゲーム媒体の使用が終了した際に、前記第1ゲーム媒体の成長パラメータを変更する、請求項1乃至5のいずれか一項に記載の情報処理装置。
【請求項7】
各ユーザがゲーム媒体を使用して前記ゲームを進行させる間において、前記パラメータ変更部は、前記各ユーザが前記ゲーム内のイベントをクリアすることで前記ゲーム媒体に対して加算される経験値の累計値に応じて、前記ゲーム媒体の成長パラメータを変更し、
前記第1ゲーム媒体の成長パラメータについて、前記受付部が前記第1ユーザ及び前記第2ユーザから申し出を受け付けて前記所定の条件が成立した場合に、前記パラメータ変更部は、前記第2ユーザが前記第1ユーザから譲受した成長パラメータに基づいて変わる前記第2ゲーム媒体の前記経験値の累計値に応じて、前記第2ゲーム媒体の成長パラメータを変更させる、請求項1乃至6のいずれか一項に記載の情報処理装置。
【請求項8】
各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部と、
前記第1ゲーム媒体の成長パラメータについて前記受付部が前記第1ユーザから譲渡の申し出を受け付けた場合に、前記第1ゲーム媒体の前記パラメータ変更履歴に基づき、これまでに前記第1ゲーム媒体に費やされたコストに応じて、前記第1ゲーム媒体の成長パラメータについての譲受条件を設定する条件設定部と、をさらに備え、
前記第1ゲーム媒体の成長パラメータについて、前記第2ユーザからの譲受の申し出が前記譲受条件を満たす場合に、前記受付部は、前記第2ユーザからの譲受の申し出を受け付ける、請求項1乃至7のいずれか一項に記載の情報処理装置。
【請求項9】
各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部と、
前記第1ゲーム媒体の成長パラメータについて前記受付部が前記第1ユーザから譲渡の申し出を受け付けた場合に、前記第1ゲーム媒体の前記パラメータ変更履歴に基づき、これまでに前記第1ゲーム媒体に費やされたコストが所定値以上である場合には、前記第1ゲーム媒体の成長パラメータについて、前記第1ユーザからの譲渡の申し出を拒否する拒否部と、をさらに備える請求項1乃至7のいずれか一項に記載の情報処理装置。
【請求項10】
前記コストは、これまでに前記第1ゲーム媒体の成長パラメータの変更に費やされたコストである、請求項8又は9に記載の情報処理装置。
【請求項11】
前記第1ゲーム媒体の成長パラメータについて、前記受付部は、前記第1ゲーム媒体の成長パラメータに対して設定された譲渡範囲内での譲受の申し出を前記第2ユーザから受け付ける、請求項1乃至10のいずれか一項に記載の情報処理装置。
【請求項12】
前記譲渡範囲が互いに異なる複数の小範囲に分かれている場合に、前記受付部は、複数の前記小範囲のうち、前記譲渡範囲の上限に最も近い前記小範囲から順に、前記小範囲における成長パラメータの譲受の申し出を前記第2ユーザから受け付ける、請求項11に記載の情報処理装置。
【請求項13】
前記譲渡範囲の下限が、前記第1ユーザが入手した時点での前記第1ゲーム媒体の成長パラメータを下回らないように、前記譲渡範囲が設定される、請求項11又は12に記載の情報処理装置。
【請求項14】
各ユーザが前記ゲームにて成長させるゲーム媒体の成長パラメータには、前記ゲームの進行に応じて変化する可変値を含み、
前記各ユーザが前記ゲームにて前記ゲーム媒体を使用している間に特定の成長条件が成立した場合に、前記パラメータ変更部は、予め定められた確率に応じて前記ゲーム媒体の前記可変値を増やし、
前記受付部は、前記第1ゲーム媒体の前記可変値について、前記第1ユーザから譲渡の申し出を受け付け、且つ、前記第2ユーザから譲受の申し出を受け付ける、請求項1乃至13のいずれか一項に記載の情報処理装置。
【請求項15】
コンピュータが、第1ユーザがゲームにて成長させる第1ゲーム媒体の成長パラメータについて、前記第1ユーザから譲渡の申し出を受け付け、且つ、第2ユーザから譲受の申し出を受け付け、
前記第1ユーザ及び前記第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータが、前記第2ユーザが前記ゲームにて成長させる第2ゲーム媒体の成長パラメータを、前記第2ユーザが前記第1ユーザから譲受した成長パラメータに応じて変更し、
前記成長パラメータの譲受の対価に応じた量の価値を、前記第2ユーザの前記価値の所持量から減じ、前記第1ユーザの前記価値の所持量に加算することにより前記所定の条件が成立する、情報処理方法。
【請求項16】
コンピュータに、第1ユーザがゲームにて成長させる第1ゲーム媒体の成長パラメータについて、前記第1ユーザから譲渡の申し出を受け付けさせ、且つ、第2ユーザから譲受の申し出を受け付けさせ、
前記第1ユーザ及び前記第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータに、前記第2ユーザが前記ゲームにて成長させる第2ゲーム媒体の成長パラメータを、前記第2ユーザが前記第1ユーザから譲受した成長パラメータに応じて変更させ
前記成長パラメータの譲受の対価に応じた量の価値を、前記第2ユーザの前記価値の所持量から減じ、前記第1ユーザの前記価値の所持量に加算することにより前記所定の条件が成立する、プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法、及びプログラムに関する。
【背景技術】
【0002】
ゲームをプレイするユーザの間で、ゲーム内で使用可能なキャラクタやアイテム等のようなゲーム媒体を交換したり売買したりすることは、既に知られている(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2014-8365号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ユーザ間の取引として、これまでに行われてきたゲーム媒体の取引以外に、新たな形態の取引が可能となれば、ユーザ間での交流を活性化させることができ、結果として、より多くのユーザをゲームに誘導することができるものと期待される。
【0005】
そこで、本発明は、ゲームのユーザ間で新たな形態の取引を可能とする情報処理装置、情報処理方法、及びプログラムを提供することを課題とする。
【課題を解決するための手段】
【0006】
本発明者の一態様に係る情報処理装置は、第1ユーザがゲームにて成長させる第1ゲーム媒体の成長パラメータについて、第1ユーザから譲渡の申し出を受け付け、且つ、第2ユーザから譲受の申し出を受け付ける受付部と、受付部が第1ユーザ及び第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、第2ユーザがゲームにて成長させる第2ゲーム媒体の成長パラメータを、第2ユーザが第1ユーザから譲受した成長パラメータに応じて変更するパラメータ変更部と、を備えることを特徴とする。
【発明の効果】
【0007】
本発明の一態様によれば、ゲーム媒体の成長パラメータをユーザ間で取り引きすることができるので、ユーザの間での新たな形態の取引を実現することができる。
【図面の簡単な説明】
【0008】
図1】装備品の成長パラメータについての説明図である。
図2】ユーザ間での成長パラメータの取引についての説明図である。
図3】本発明の一実施形態に係る情報処理装置及び各ユーザの端末を含むシステム全体を示す概念図である。
図4】ユーザ端末の機能についての説明図である。
図5】本発明の一実施形態に係る情報処理装置に備えられた複数の機能部を示すブロック図である。
図6】記憶部に記憶されるユーザデータの一例を示す図である。
図7】記憶部に記憶される装備品データの一例を示す図である。
図8】記憶部に記憶される取引データの一例を示す図である。
図9】記憶部に記憶されるレベル強化用データの一例を示す図である。
図10】記憶部に記憶されるランク値強化用データの一例を示す図である。
図11】ゲーム進行フローの流れを示す図であり、装備品のレベル又はランク値を変更させる流れを示す。
図12A】パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがレベルである場合の流れを示す(その1)。
図12B】パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがレベルである場合の流れを示す(その2)。
図13A】パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがランク値である場合の流れを示す(その1)。
図13B】パラメータ取引フローの流れを示す図であり、取り引きされる成長パラメータがランク値である場合の流れを示す(その2)。
図14】第1の変形例に係る情報処理装置の機能を示す図である。
図15A】第1の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す(その1)。
図15B】第1の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す(その2)。
図16A】第2の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す(その1)。
図16B】第2の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す(その2)。
【発明を実施するための形態】
【0009】
以下、本発明の情報処理装置、情報処理方法及びプログラムについて具体的な実施形態を挙げて説明する。ただし、以下に説明する実施形態は、本発明の理解を容易にするために挙げた一例にすぎず、本発明を限定するものではない。すなわち、本発明は、その趣旨を逸脱しない限りにおいて、以下に説明する実施形態から変更又は改良され得る。また、当然ながら、本発明には、その等価物が含まれる。
【0010】
また、以下の説明の中で参照される図面が示す画面例も一例に過ぎず、画面の構成例、表示される情報の内容、及びGUI(Graphical User Interface)等は、システム設計の仕様及びユーザの好み等に応じて自由に設計することができ、また適宜変更し得る。
【0011】
さらに、本明細書において、「装置」とは、単独で所定の機能を発揮する一つの装置のみ、互いに分離されているものの所定の機能を発揮するために協働する複数の装置をも含むものとする。
【0012】
さらにまた、本明細書において、「ユーザ」とは、本発明の情報処理装置のユーザであり、具体的には、本発明の情報処理装置によって提供されるサービスの利用者である。なお、ユーザは、特に断る場合を除き、個人であることとするが、複数人のグループであってもよい。
【0013】
[本発明の一実施形態に係るゲームについて]
本発明の一実施形態(以下、本実施形態という。)に係る情報処理装置の説明に先立ち、当該情報処理装置のユーザがプレイ可能なゲームについて説明する。
【0014】
ゲームは、ユーザがゲームプレイ用の端末を操作してプレイするコンテンツであり、詳しくは、データ通信を利用したオンラインゲームである。オンラインゲームは、ウェブブラウザを利用したブラウザゲーム、SNS(Social Networking Service)上で提供されるソーシャルゲーム、及び、ストリーミング配信されるクラウドゲーム等が含まれ得る。また、モバイルゲーム等のように専用のアプリケーションソフトをダウンロードしてプレイ可能なゲームもオンラインゲームに含まれ得る。さらに、オンラインゲームには、プレイバイウェブ(PBW)等の定期更新型オンラインゲームも含まれ得る。
【0015】
なお、ゲームは、複数人のユーザが同時に同じゲームをプレイすることが可能な多人数参加型のゲームでもよく、あるいは一個人が単独プレイする形式のゲームでもよい。また、ゲームは、後述するゲーム媒体のパラメータがゲームの進行具合に応じて変化する内容のものであればよく、その種類(ジャンル)は特に限定されない。
【0016】
ユーザは、ゲーム内のイベント(以下では、ゲーム内イベントともいう。)をプレイすることでゲームを進行させることができる。ゲーム内イベントは、ゲーム中でプレイ可能な要素であり、例えば、敵又は対戦相手との勝負、クリアすることが目的でプレイされるステージやクエスト、及び、アイテムを入手するための抽選等である。
【0017】
ユーザは、ゲームを進行させる上でゲーム媒体を使用する。ゲーム媒体は、ユーザがゲーム内で使用可能なキャラクタ、アイテム、及び装備品等である。キャラクタは、ゲーム内においてユーザによって操作され、又はユーザの指示に応じてゲーム内で動作するプレイングキャラクタ、及び、プレイングキャラクタを支援するサポートキャラクタを含む。アイテムは、ゲームを有利に進める等の目的のためにゲーム内で使用される物資であり、使用によって、その種類に応じた効果が付与される。装備品は、アイテムの一例であり、キャラクタに装着されることでキャラクタの能力値を変化させることができる。
【0018】
なお、「ゲーム媒体を使用する」とは、入手したゲーム媒体をゲーム内で使用してゲームを進行させることを意味する。ゲーム媒体がキャラクタである場合には、ゲーム内で当該キャラクタを操作したり、当該キャラクタに対して指示又は命令を与えて、その指示又は命令に従った行動を当該キャラクタに行わせたりすることが「使用」に該当する。また、ゲーム媒体がアイテムである場合には、ゲーム内で当該アイテムを使用(消費)することにより、その効果をゲーム内で発動させることが「使用」に該当する。また、ゲーム媒体が装備品である場合には、当該装備品をキャラクタ(具体的には、ユーザが操作するキャラクタ)に装着させ、そのキャラクタを操作してゲームを進めることが「使用」に該当する。
【0019】
上述した各種のゲーム媒体の使用権限は、ゲーム内で各ゲーム媒体を入手したユーザに対して設定される。ユーザは、使用権限を有するゲーム媒体をゲーム内で使用することができる。なお、以下では、ゲーム媒体の使用権限を保有することを、便宜的に「ゲーム媒体を所持する」と表現することとする。
【0020】
ユーザがゲーム媒体を新たに入手する手段は、特に限定されず、例えば、ゲーム内の店舗でゲーム内通貨を支払って購入すること、所定の敵を倒したり所定のクエストをクリアしたりした場合の報酬として一定の確率で獲得すること、及び、抽選にて当選した際の景品として獲得すること等が挙げられる。また、ユーザは、不要なゲーム媒体をゲーム内で売却又は廃棄することができる。さらに、ユーザは、所持するキャラクタや装備品に対して進化用のアイテムを利用する等して、そのゲーム媒体を進化させることができる。進化とは、あるキャラクタや装備品を別の種類のゲーム媒体に変貌させることである。売却又は廃棄され、あるいは進化させたゲーム媒体の使用権限は、消失し、当該ゲーム媒体の使用が不可能となる。
【0021】
本実施形態において、ゲームには複数種類のゲーム媒体が用意されており、各ゲーム媒体は、その種類に応じた区分によって分類される。区分は、例えば、ゲーム媒体のレア度に基づいて設定され、レア度は、ゲームにおけるゲーム媒体の入手困難性を表す指標であり、ゲーム内で所定のイベントをクリアした場合に入手することができる確率(ドロップ率)に応じて決められる。各ゲーム媒体は、区分1~区分X(Xは2以上の自然数)のいずれかに分類され、区分の番号が大きいゲーム媒体であるほど、レア度が高いゲーム媒体であることを意味する。
【0022】
また、各ユーザは、ゲームにて、自分が所持するゲーム媒体を成長させることができる。成長とは、ゲーム媒体の性能や能力、サイズや外観、及び運気や人気その他のステータスを向上、強化、良化及び生育させることであり、具体的には後述の成長パラメータを上げることである。また、成長には、一時的に成長パラメータが下がるケースが含まれる。
なお、以下では、「成長」の一態様として、ゲーム媒体を強化させるケースを例に挙げて説明することとする。
【0023】
ゲーム媒体には、その性質及び能力等に応じた成長パラメータが設定されている。例えば、ゲーム媒体である装備品には、図1に示すように、レベル及びランク値が成長パラメータとして設定されている。図1は、装備品のレベル及びランク値の現在値を示す画面例である。
【0024】
レベル及びランク値は、ゲーム内で強化する(成長させる)ことにより上昇し、これらのパラメータが上昇するほど、装備品の性能(強化度)が増加し、使用する装備品の強化度が高いほど、ユーザは、ゲームを有利に進めることができる。装備品の強化度は、レベルに応じた強化度に、ランク値に応じた強化度を合算した値である。なお、レベル及びランク値は、整数値で表されて離散的に(例えば+1ずつ)上昇する値でもよく、あるいは、連続量で表されて数値ゲージのように連続的に上昇する値でもよい。
【0025】
装備品のレベルは、その入手時点では初期値(例えば、レベル1)に設定されており、装備品に対して付与される経験値の累計値に応じて上昇する。経験値は、ユーザがゲーム内イベントをクリアすることで装備品に対して加算される。例えば、装備品を使用してゲーム内に出現する敵を倒したり、あるいは装備品を使用した状態で所定のステージを通過したりする等と、倒した敵や通過したステージ等に応じた経験値が当該装備品に対して加算される。そして、経験値の累計値がレベル毎に設定された条件値(以下、レベル用条件値という。)に到達すると、装備品のレベルが、到達したレベル用条件値と対応する値まで上昇する。なお、レベルが高くなるほど、レベル用条件値がより大きい値になる。
【0026】
装備品のランク値は、ゲームの進行に応じて変化する可変値であり、例えばm~n(m<n)の範囲で変化する。mは、入手時点での装備品のランク値、すなわちランク値の初期値であり、正又は負の整数、あるいは0である。nは、装備品のランク値の上限値であり、正の整数であり、装備品の種類に応じて決められている。また、装備品のランク値の最大値は、装備品が属する区分(換言すると、装備品のレア度)によって異なる。
【0027】
ユーザは、自分の装備品をゲーム内で強化すると、その装備品のランク値を上げる(増やす)ことができる。つまり、装備品のランク値は、各ユーザが装備品を使用してゲームをプレイしている間に強化条件が成立した場合に上がる。強化条件は、特定の成長条件に相当し、ユーザがゲームをプレイしるときの操作内容(プレイ内容)に応じて条件の成否が決まる。具体的に説明すると、例えば、ランク値を上げたい装備品に対してランク値上昇用のアイテムを使用したり、あるいは、ランク値を上げたい装備品を使用した状態で所定のイベントをクリアしたりすること等が強化条件に該当する。
【0028】
また、本実施形態では、強化条件が成立すると、ランク値が、予め定められた確率に応じて上がる。ランク値が上がる確率は、ランク値を上げるために使用したアイテムの種類やクリアしたイベントの内容に応じて変化し、通常の場合には、ランク値が上がるほど確率は低下する。例外として、例えば特別なアイテムを使用したり、特別なイベントをクリアしたりした場合には、ランク値の現在値に関わらず、所定の確率(具体的には、100%)で対象装備品のランク値を上げる(増やす)ことができる。
【0029】
また、本実施形態では、装備品のレベル又はランク値を上げる際にコストが掛かる場合がある。つまり、各ユーザは、自己の装備品のレベル又はランク値を上げる際にコストを費やすことがある。コストを費やすとは、例えば、有料のアイテムを使用すること、あるいは、有料のゲーム内イベントをプレイすること等が挙げられる。なお、有料とは、現実空間において現金や電子マネー等の金銭的価値の支払いを要することであり、また、有料には、ユーザが金銭的価値を支払って取得したゲーム内通貨をゲーム内で消費することが含まれ得る。
【0030】
[ユーザ間でのパラメータの取引について]
本実施形態では、ゲーム媒体の成長パラメータとして、装備品のレベル及びランク値をユーザ間で取り引きすることが可能である。例えば、あるユーザAは、図2に示すように、自分が所持する装備品のレベル又はランク値を他のユーザBに譲渡することができる。他方、ユーザBは、ユーザAから譲受したレベル又はランク値に応じて、ユーザBが所持する装備品のレベル又はランク値を変更、詳しくは上昇させることができる。図2は、ユーザ間でのパラメータの取引についての説明図である。
【0031】
本実施形態において、ユーザ間での成長パラメータの取引(以下、単にパラメータ取引ともいう。)は、金銭又はそれに相当する価値の出納を伴う有料の取引、すなわち売買取引である。つまり、本実施形態では、第1ユーザが第1ユーザの装備品のレベル又はランク値を販売し、販売されたレベル又はランク値を第2ユーザが第1ユーザから購入する。そして、第2ユーザの装備品のレベル又はランク値は、第2ユーザが購入したレベル又はランク値に応じて上がる。他方、レベル又はランク値を販売した第1ユーザの装備品については、販売された分だけ、レベル又はランク値が下がる。
【0032】
ここで、第1ユーザは、レベル又はランク値を譲渡(販売)する方のユーザであり、第2ユーザは、レベル又はランク値を譲受(購入)する方のユーザである。また、第1ユーザが所持する装備品は、第1ゲーム媒体に該当し、第2ユーザが所持する装備品は、第2ゲーム媒体に該当する。
【0033】
以上のように本実施形態では、装備品のレベル又はランク値をユーザ間で取り引きする(売買する)ことができる。そして、上記の取引は、装備品の移譲を伴わない。つまり、第1ユーザの装備品のレベル又はランク値が販売されて第2ユーザによって購入された場合、その後も、第1ユーザは、レベル又はランク値が販売された装備品を引き続きゲーム内で使用することができる。これにより、取引に対する第1ユーザの意欲を喚起させることができる。
【0034】
具体的に説明すると、従来のユーザ間での取引は、ゲーム媒体自体(キャラクタ又はアイテム)を対象として行われ、とりわけ、レア度が高いゲーム媒体を対象とする取引が行われていた。しかし、レア度が高いゲーム媒体を販売することは、当該ゲーム媒体を手放すことになるため、その所持者であるユーザにとって取引の実施を決断するのが難しい。そのため、従来のユーザ間での取引では、取引に対するユーザの意欲を喚起させ難く、取引を通じたユーザ間の交流を活性化させることが困難であった。
【0035】
これに対して、本実施形態では、ユーザ間での取引として、使用権限の移譲を伴わない形でのゲーム媒体の成長パラメータの取引が可能である。つまり、本実施形態において、第1ユーザは、成長パラメータが取り引きされたゲーム媒体を取引後にも引き続き使用することができる。これにより、本実施形態では、従来に比べて、ユーザ、特に第1ユーザの取引に対する意欲を喚起させ易くなっている。これにより、取引を通じたユーザ間の交流が活性化され、その結果、ゲーム自体を盛り上げることができ、具体的には各ユーザのゲームプレイ時間、及びゲームをプレイするユーザ数等が増えることが期待される。
【0036】
また、第1ユーザは、自分が所持するゲーム媒体の成長パラメータ、詳しくは装備品のレベル又はランク値を販売して得た利益(利潤)を享受することができる。このように本実施形態では、第1ユーザがゲームの中で上昇させた装備品のレベル又はランク値を販売することができるので、ゲームに投じた労力(具体的には、ゲームのプレイ時間等)を一種の商材として取り扱うことができる。
【0037】
なお、パラメータ購入時に第2ユーザが第1ユーザに支払う対価は、現金、電子マネー又は仮想通貨、あるいはゲーム内で使用可能な通貨(ゲーム内通貨)でもよく、若しくは、これら以外の価値であってもよい。ゲーム内通貨は、換金性を有する価値でもよく、あるいは、ゲーム内でのみ使用することができ換金不可の価値でもよい。
【0038】
また、本実施形態において、パラメータ取引の対象となる装備品は、課金又は有料でプレイできる抽選等を通じて入手することができる有料(換言すると、入手コストを要する)の装備品である。この場合には、装備品のパラメータ取引が行われた後に当該装備品を引き続き使用することができるという効果が、より有意義なものとなる。ただし、これに限定されるものではなく、ゲームの総プレイ回数が所定回数に達した場合やゲームの初回プレイ時に特典として無料でユーザに付与されたりする無料の装備品であってもよい。
【0039】
また、成長パラメータの購入額(支払額)については、オークションでの入札形式で決めてもよく、第1ユーザ又は第2ユーザが自らの意志に基づいて任意の額に決めてもよく、あるいは、ゲームの運営会社が所定のルールに則り、販売される成長パラメータの種類や量等に応じて決めてもよい。
【0040】
取引に伴う対価の支払いや入金等に関する処理(具体的には、金銭等の出納処理)については、ユーザ間での取引において従来から採用されてきた公知の情報処理技術を利用することが可能である。また、本実施形態では、例えば、換金性を有するゲーム内通貨が取引用の価値(以下、取引用通貨という。)として利用され、ユーザ間での取引が確定すると、第2ユーザから取引用通貨が支払われ、支払い量に応じた量の取引用通貨が第1ユーザに付与される。具体的には、パラメータ取引が確定すると、ゲーム内通貨について、第2ユーザの所持量を取引額に応じた量だけ減少させ、第1ユーザのゲーム内通貨の所持量を取引量に応じた量だけ増加させる。なお、取引用通貨として利用可能なゲーム内通貨は、ゲーム内でのみ使用することができる換金性のないゲーム内通貨でもよい。
【0041】
なお、取引に伴う価値の入出処理については、上記の内容に限定されない。例えば、各ユーザのゲーム用アカウントに銀行口座の情報又はクレジットカード情報等が紐付けられており、パラメータ取引が確定すると、第2ユーザの銀行口座情報又はクレジットカード情報を通じて第2ユーザ宛に対価の支払いを請求し、対価に応じた量の金銭が第1ユーザの銀行口座等に振り込まれてもよい。
【0042】
[本実施形態の情報処理装置及び各ユーザの端末について]
次に、本実施形態に係る情報処理装置及び各ユーザの端末について、図3を参照しながら説明する。図3は、本実施形態に係る情報処理装置及び各ユーザの端末を含むシステム全体を示す概念図である。
【0043】
なお、以下では、ユーザAを第1ユーザとし、ユーザBを第2ユーザとし、ユーザA、Bの間で成長パラメータの取引、すなわち売買取引が行われるケースを例に挙げて説明することとする。また、以下では、ユーザAがゲーム内で所持する装備品のうち、レベル又はランク値が取引対象として譲渡される装備品を「取引対象品」と呼び、ユーザBがゲーム内で所持する装備品のうち、ユーザAから譲受したレベル又はランク値によって強化される(つまり、レベル又はランク値が上がる)装備品を「被強化品」と呼ぶこととする。
【0044】
ユーザA、Bの各々は、ゲームプレイ用の端末としてユーザ端末11、12を保有する。つまり、各ユーザは、ゲームをプレイするために各自のユーザ端末11、12を操作し、パラメータの売買取引を実施しようとする場合にはゲーム中に所定の操作を行う。
【0045】
各ユーザのユーザ端末11、12は、例えば、パソコン、スマートフォン、携帯電話、タブレット端末、通信対応型のゲーム機、情報の送受信が可能なテレビ受像機、又はウェアラブル端末等によって構成される。つまり、ユーザ端末11、12は、オンライン形式でゲームをプレイするために用いられた従来の端末と同様のハードウェア構成であり、図3に示すようにプロセッサ13、メモリ14、通信用インタフェース15、入力デバイス16、及びディスプレイ等の出力デバイス17等を備える。また、各々のユーザ端末11、12には、端末用のソフトウェアとして、ゲームプレイ用のプログラムがインストールされている。
【0046】
また、各ユーザのユーザ端末11、12は、それぞれ、図3に示すように通信用ネットワークNTを介してサーバ10と通信可能に接続されている。通信用ネットワークNTは、例えばインターネット又はモバイル通信ネットワークからなる通信回線網であり、LAN(Local Area Network)、WAN(Wide Area Network)、イントラネット及びイーサネット(登録商標)等を含むものであってもよい。
【0047】
サーバ10は、本発明の「情報処理装置」の一例であり、本実施形態では、ゲーム進行に必要なデータの生成及び送受信等、並びにゲーム進行に関する各種の情報処理を実行するゲーム配信用のコンピュータによって構成される。サーバ10が送受信するデータには、ユーザ間でのパラメータの取引に必要なデータが含まれ、サーバ10が実行する情報処理には、ユーザ間でのパラメータの取引に関する処理が含まれる。
【0048】
本実施形態において、サーバ10を構成するコンピュータは、ゲームの運営会社によって管理されるものであるが、これに限定されず、運営会社とは別の企業若しくは機関によって管理されてもよい。なお、サーバ10は、1台のコンピュータで構成されてもよく、並列分散された複数台のコンピュータによって構成されてもよい。また、サーバ10は、ASP(Application Service Provider)、SaaS(Software as a Service)、PaaS(Platform as a Service)又はIaaS(Infrastructure as a Service)用のサーバコンピュータであってもよい。この場合、ゲーム進行に関する一連の情報の工程(ただし、情報の入力及び表示を除く)がサーバ10によって実行されるため、各ユーザ端末11、12側では、サーバ10に引き渡す情報の入力、及びサーバ10から配信される情報の表示等を行えばよいことになる。
【0049】
サーバ10は、ハードウェア機器として、図3に示すように、プロセッサ10A、メモリ10B、通信用インタフェース10C、及びストレージ10Dを有し、これらがバスを介して電気的に接続されている。プロセッサ10Aは、CPU(Central Processing Unit)、MPU(Micro-Processing Unit)、MCU(Micro Controller Unit)、GPU(Graphics Processing Unit)、DSP(Digital Signal Processor)、TPU(Tensor Processing Unit)又はASIC(Application Specific Integrated Circuit)等によって構成されるとよい。
【0050】
メモリ10Bは、ROM(Read Only Memory)及びRAM(Random Access Memory)等の半導体メモリによって構成されるとよい。
通信用インタフェース10Cは、例えばネットワークインタフェースカード、又は通信インタフェースボード等によって構成されるとよい。通信用インタフェース10Cによるデータ通信の規格については、特に限定されるものではなく、Wi-fi(登録商標)に基づく無線LANによる通信、3G~5G若しくはそれ以降の世代の移動通信システムによる通信、又はLTE(Long Term Evolution)に基づく通信等が挙げられる。
【0051】
ストレージ10Dは、フラッシュメモリ、HDD(Hard Disc Drive)、SSD(Solid State Drive)、FD(Flexible Disc)、MOディスク(Magneto-Optical disc)、CD(Compact Disc)、DVD(Digital Versatile Disc)、SDカード(Secure Digital card)、又はUSBメモリ(Universal Serial Bus memory)等によって構成されるとよい。また、ストレージ10Dは、サーバ10内に内蔵されてもよく、外付け形式でサーバ本体に取り付けてもよい。さらに、ストレージ10Dは、サーバ本体と通信可能に接続された外部コンピュータ(例えば、データベースサーバ)等によって構成されてもよい。さらにまた、各種のデータを記録する技術としては、不正なデータ改竄等を回避する目的からブロックチェーンのような分散型台帳技術を用いてもよい。特に、各ユーザの取引用通貨の所持量については、ブロックチェーンによる管理及び記録が適している。
【0052】
また、サーバ10には、ソフトウェアとして、オペレーティングシステム(OS)用のプログラム、及び、ゲーム進行用の情報処理プログラムがインストールされている。これらのプログラムは、本発明の「プログラム」に相当し、プロセッサ10Aによって実行されることで、サーバ10が本発明の情報処理装置としての機能を発揮する。
【0053】
具体的に説明すると、例えばユーザA、Bがゲームをプレイしている間、サーバ10は、上記のプログラムの実行により、ゲームプレイ画面の表示データを生成して各ユーザのユーザ端末11、12に向けて送信する。また、ユーザA、Bがユーザ端末11、12を通じてゲーム進行用の操作を行うと、当該操作の内容を示すデータがユーザ端末11、12からサーバ10に向けて送信され、サーバ10は、ユーザ端末11、12から受信したデータに基づいて、ユーザ操作に応じてゲームを進行させる情報処理を実行する。
【0054】
さらに、ユーザAは、自分が所持する装備品のうち、取引対象品のレベル又はランク値を譲渡(販売)しようとする場合にユーザ端末11を通じて譲渡の申し出を行い、サーバ10は、ユーザ端末11との通信を介してユーザAから譲渡の申し出を受け付ける。他方、ユーザBは、ユーザAが販売したレベル又はランク値を譲受(購入)しようとする場合にユーザ端末12を通じて譲受の申し出を行い、サーバ10は、ユーザ端末12との通信を介してユーザBから譲受の申し出を受け付ける。
【0055】
そして、サーバ10がユーザA及びユーザBの各々から申し出を受け付けて取引条件が成立すると、サーバ10は、パラメータ取引に関する一連の情報処理を実行する。これにより、ユーザBが所持する装備品のうち、被強化品のレベル又はランク値が上昇し、その一方で、ユーザAが所持する取引対象品のレベル又はランク値が低下する。
【0056】
取引条件は、所定の条件に相当し、具体的には、パラメータ取引の成立を確定させる条件、換言すると、取引対象品のレベル又はランク値の譲渡及び譲受を確定させるための条件である。取引条件としては、例えば、パラメータ取引が確定したことを示すデータを記憶すること(詳しくは、後述の取引データの成否フラグを取引確定の値に切り替えること)、あるいは、ユーザBがパラメータ譲渡の対価を支払うこと(詳しくは、後述の決済処理を実行すること)等が挙げられる。また、パラメータ取引がオークション形式で行われる場合には、最高額が提示された入札があった状態で入札可能期間が経過することを取引条件としてもよい。
【0057】
なお、サーバ10にインストールされるプログラムは、コンピュータが読み取り可能な記録媒体(メディア)から読み込むことで取得してもよく、あるいは、インターネット又はイントラネット等のネットワークを介して取得(ダウンロード)してもよい。
【0058】
次に、各ユーザのユーザ端末11、12及びサーバ10の各々について、図4及び5を参照しながら、各機器の構成を機能面から改めて説明することとする。図4は、ユーザ端末11、12の機能を示し、図5は、サーバ10に備えられた機能(換言すると、複数の機能部)を示す。
【0059】
(ユーザ端末の機能について)
ユーザ端末11、12は、図4に示すように、端末側受付部21、端末側送受信部22、端末側記憶部23、及び表示実行部24を備える。これらの機能部の各々は、ユーザ端末11、12を構成するハードウェア機器と、ユーザ端末11、12にインストールされたソフトウェア(具体的には、ゲームプレイ用のプログラム)との協働によって実現される。
【0060】
端末側受付部21は、ゲーム進行用の操作及びパラメータ取引用の操作等、ユーザがゲームプレイ中に行う操作(ゲーム用操作)を受け付ける。
端末側送受信部22は、サーバ10又は他のユーザ端末から送られてくるデータを受信し、また、サーバ10又は他のユーザに向けてデータを送信する。端末側送受信部22がサーバ10に向けて送信するデータの中には、端末側受付部21が受け付けたゲーム用操作の内容に応じたデータが含まれ、例えば下記の(a)~(f)のデータが含まれる。
(a)ユーザが所持する装備品等の使用の有無に関するデータ
(b)ゲーム内イベントにおけるプレイ内容に関するデータ
(c)ユーザが所持する装備品等を売却又は廃棄するための指示データ
(d)ユーザが所持する装備品等を強化又は進化させるための指示データ
(e)パラメータ譲渡の申し出に関するデータ
(f)パラメータ譲受の申し出に関するデータ
【0061】
データ(a)~(d)は、ユーザが行ったゲーム進行用の操作に応じたデータである。
データ(a)は、ユーザがゲーム内で装備品を使用する場合に生成され、例えば、ユーザID、使用される装備品の識別情報、及び、どのキャラクタに対して使用されるのか等を示す。
データ(b)は、ユーザがゲーム内イベントをプレイする場合に生成され、例えば、ユーザID、プレイするイベントの識別情報、イベント内で使用するキャラクタ及び装備品等の各々の識別情報、及び、イベント中におけるキャラクタに対する指示や命令等(具体的には、キャラクタの移動方向、又は攻撃又は防御等の動作に関する命令等)を示す。
データ(c)は、ユーザがゲーム内で所持する装備品を売却又は廃棄する場合に生成され、例えば、ユーザID、及び、売却又は廃棄する装備品の識別情報等を示す。
データ(d)は、ユーザがゲーム内で所持する装備品を強化又は進化させる場合に生成され、例えば、ユーザID、強化又は進化させる装備品の識別情報、並びに、強化用又は進化用のアイテムを用いるケースでは当該アイテムの識別情報及び使用個数等を示す。
【0062】
データ(e)及び(f)は、ユーザが行うパラメータ取引用の操作に応じたデータである。データ(e)は、第1ユーザ(つまり、ユーザA)が取引対象品のレベル又はランク値の譲渡を申し出る場合に生成され、例えば、ユーザID、取引対象品の識別情報、及び、譲渡されるレベル又はランク値の範囲(譲渡範囲)等を示し、また、第1ユーザが指定した希望譲渡額(販売額)等を更に含んでもよい。
データ(f)は、第2ユーザ(つまり、ユーザB)が取引対象品のレベル又はランク値の譲受を申し出る場合に生成され、例えば、ユーザID、取引対象品の識別情報、譲渡範囲、及び、譲受したレベル又はランク値によって強化される被強化品の識別情報等を示し、また、第2ユーザが指定した希望譲受額(購入額)等を更に含んでもよい。
【0063】
端末側記憶部23は、ゲームにおいて必要なデータを記憶し、例えば、表示データ等のようにサーバ10から送られてくるデータを記憶する。
表示実行部24は、サーバ10から受信した表示データを展開し、表示データが示すゲーム画面(ゲームプレイ中の画面)をユーザ端末11、12の出力デバイス17、より詳しくはディスプレイを表示する。
【0064】
(サーバの機能について)
サーバ10は、図5に示すように、ゲーム進行用受付部31、ゲーム進行部32、サーバ側記憶部33、取引用受付部34、コスト算出部35、取引処理部36、及び拒否部37を備える。これらの機能部の各々は、サーバ10を構成するハードウェア機器と、サーバ10にインストールされたソフトウェアとしてのプログラム(すなわち、本発明のプログラム)との協働によって実現される。
【0065】
ゲーム進行用受付部31は、ユーザ端末11、12との通信を通じてユーザのゲーム内操作、特にゲーム進行用の操作を受け付け、具体的には、ゲーム進行用のデータを、通信用ネットワークNTを介してユーザ端末11、12から受信する。ゲーム進行用受付部31が受信するデータは、ユーザが行ったゲーム進行用の操作に応じたデータであり、例えば上記のデータ(a)~(d)が該当する。
【0066】
ゲーム進行部32は、ユーザがゲームをプレイしている期間中、ゲーム進行用受付部31が受信したゲーム進行用のデータに応じてゲームを進行させる。ゲーム進行用のデータには、前述したようにデータ(a)、すなわち装備品等の使用の有無に関するデータが含まれる。このため、ゲーム進行部32は、各ユーザの装備品等の使用に応じて、各ユーザがプレイするゲームを進行させる。また、ゲーム進行部32は、上述のデータ(b)、すなわちゲーム内イベントにおけるプレイ内容に関するデータに応じてゲームを進行させ、具体的には、例えばユーザの指示や命令に従ってキャラクタを動かしてゲーム内イベントを進める。
【0067】
また、本実施形態において、ゲーム進行部32は、図5に示すように、状態変更部41と経験値付与部42を含み、状態変更部41は、パラメータ変更部43を含む。
状態変更部41は、ゲーム進行用受付部31が受け付けたゲーム内操作に応じて、厳密にはユーザ端末11、12から受信したゲーム進行用のデータ、特に上述のデータ(a)、(c)及び(d)に応じて装備品の状態を変更させる。装備品の状態は、装備品の現在のステータス及びパラメータの現在値等である。ステータスは、例えば、装備品が現時点で使用されているか否か、装備品が既に売却又は廃棄されているか否か、及び、装備品が進化前及び進化後のいずれであるか等を示す情報であり、パラメータは、レベル及びランク値である。
【0068】
経験値付与部42は、ユーザが装備品を使用してゲーム内で所定のイベントをクリアした場合に、使用された装備品に対して、クリアしたイベントに応じた経験値を付与する。付与された経験値は、これまでに上記の装備品に対して付与された経験値の累計値に加算される。
【0069】
パラメータ変更部43は、状態変更部41の一機能を担うものであり、ユーザが所持する装備品の成長パラメータ、具体的にはレベル又はランク値を変更させる。具体的に説明すると、パラメータ変更部43は、各ユーザの各装備品に付与された経験値の累計値を特定し、累計値がレベル用条件値に到達した装備品のレベルを、そのレベル用条件値と対応する値まで上昇させる。
【0070】
また、例えば、ゲーム進行用受付部31が上述のデータ(d)、厳密には装備品を強化させるための指示データを受け付けた場合、パラメータ変更部43は、指示データが示す情報等に基づいて前述の強化条件の成否を判定し、強化条件が成立する場合には、強化対象の装備品のランク値を変更する。この際、パラメータ変更部43は、予め定められた確率に応じて当該装備品のランク値を上げる(増やす)。
【0071】
さらに、ユーザA、Bの間でパラメータ取引が行われた場合、パラメータ変更部43は、ユーザAが所持する装備品中の取引対象品、及び、ユーザBが所持する装備品中の被強化品のそれぞれのレベル又はランク値を、取引内容に応じてレベルを変更する。具体的には、パラメータ変更部43は、取引条件の成立をトリガーとして、ユーザAの取引対象品のレベル又はランク値を、ユーザAが譲渡(販売)した量に応じて減少させ、且つ、ユーザBの被強化品のレベル又はランク値を、ユーザBが譲受(購入)した量に応じて上げる。
【0072】
サーバ側記憶部33は、記憶部に相当し、ゲームの進行及びユーザ間でのパラメータの取引に必要な各種のデータを記憶し、具体的には、図6に示すユーザデータ、図7に示す装備品データ、図8に示す取引データ、図9に示すレベル強化用データ、及び、図10に示すランク値強化用データを記憶する。図6~10の各図は、サーバ側記憶部33に記憶されるデータの一例を示す。
【0073】
ユーザデータは、ゲームをプレイするユーザ、つまりゲーム用のアカウントを有するユーザに関するデータであり、ユーザ毎にサーバ側記憶部33に記憶される。ユーザデータは、図6に示すように、ユーザID、所持するキャラクタ、アイテム及び装備品の識別情報、ゲーム進行用通貨の所有量、及び取引用通貨の所有量等を含む。ゲーム進行用及び取引用通貨は、いずれも、課金や購入又はゲーム内イベントのプレイ等によって入手可能なゲーム内通貨である。ゲーム進行用通貨は、主としてゲーム内でアイテムや装備品等を購入する等、ゲームを進行させるために利用され、取引用通貨は、主としてユーザ間でのパラメータの取引のために利用される。
なお、ユーザデータは、図6に示された内容以外のデータを含んでもよく、例えば、ユーザがゲーム内通貨の購入代金の支払いに利用する銀行口座又はクレジットカードの情報等が含まれてもよい。
【0074】
装備品データは、各ユーザが所持する装備品に関するデータであり、各ユーザが所持する装備品毎に記憶される。装備品データは、図7に示すように、装備品の識別情報、装備品の所持者であるユーザのユーザID、区分、レベル及びランク値のそれぞれの初期値と現在値、これまでに付与された経験値の累計値、使用状態、レベル又はランク値のそれぞれの変更履歴、及び、取引対象であるか否かを示す該否フラグ等を含む。
【0075】
レベル又はランク値のそれぞれの変更履歴は、パラメータ変更履歴に該当し、レベル又はランク値が初期値から現在値に至るまでの経緯として、各時点で装備品に対して費やされたコスト、つまり、これまでの装備品の強化(パラメータ変更)に関するコストを示す。より詳しく説明すると、変更履歴は、図7に示すように、各段階のレベル又はランク値において、装備品に対して使用されたパラメータ強化用アイテムの種類、消費個数、及びアイテム購入時に支払った通貨量(金額)、並びに、装備品を使用してプレイされたパラメータ強化用のイベントの種類、プレイ回数、及びイベントプレイ時に支払った通貨量(金額)等を表す。
なお、装備品データは、図7に示された内容以外のデータを含んでもよく、例えば、これまでに取引対象となった回数(つまり、成長パラメータが譲渡された回数)等が含まれてもよい。
【0076】
取引データは、パラメータ取引に関するデータであり、取引毎に記憶される。取引データは、図8に示すように、取引の識別情報、取引に関与するユーザ(すなわち、第1ユーザ及び第2ユーザ)のユーザID、取引対象品に該当する装備品の識別情報、譲渡されるパラメータの種類(レベル及びランク値のいずれであるか)、パラメータの譲渡範囲、パラメータがレベルである場合には譲渡範囲から変換された経験値、第1ユーザが指定した譲渡額(販売額)、第2ユーザが指定した譲受額(購入額)、被強化品に該当する装備品の識別情報、及び、取引が確定したか否かを示す成否フラグ等を含む。
なお、取引データは、図8に示された内容以外のデータを含んでもよく、例えば、取引に対して設定された制限時間等が含まれてもよい。制限時間が設定された取引については、制限時間内に成立しなかった場合に当該取引をキャンセルにしてもよい。
【0077】
レベル強化用データ及びランク値強化用データの各々は、ユーザが装備品の強化を指示した場合に、パラメータ変更部43によって参照されるデータである。レベル強化用データは、図9に示すように、各装備品のレベルを1段階ずつ上昇させるに必要な経験値の累計値、すなわちレベル用条件値を段階毎に規定したデータであり、装備品の種類毎に記憶される。
【0078】
ランク値強化用データは、図10に示すように、各装備品のランク値を1段階ずつ上昇させるために満たすことが必要となる強化条件を段階毎に規定したデータであり、装備品の種類毎に記憶される。強化条件は、ランク値を上げるために必要なアイテムの種類及び使用個数、あるいは、ランク値を上げるためにプレイすることが必要なイベントの種類及びプレイ回数である。また、ランク値強化用データには、図10に示すように、各段階のランク値において強化条件が成立した場合に一つ上のランク値に上がることができる確率が含まれる。
【0079】
取引用受付部34は、受付部に相当し、ユーザ間でのパラメータの取引に関するユーザの操作を受け付け、具体的には、パラメータ取引用のデータを、通信用ネットワークNTを介してユーザ端末11、12から受信する。取引用受付部34が受信するデータは、ユーザが行ったパラメータ取引用の操作に応じたデータであり、例えば上述のデータ(e)及び(f)が該当する。つまり、取引用受付部34は、第1ユーザであるユーザAが所持する装備品中の取引対象品のレベル又はランク値について、ユーザAから譲渡(販売)の申し出を受け付けるとともに、第2ユーザであるユーザBから譲受(購入)の申し出を受け付ける。
【0080】
また、本実施形態において、取引用受付部34は、取引対象品のレベル又はランク値についてのユーザBからの譲受の申し出が申し出受付条件を満たすことを条件として、ユーザBからの譲受の申し出を受け付ける。申し出受付条件は、ゲーム進行上におけるユーザ間の不平等を是正して公平な取引を実現する理由によって設定された条件である。申し出受付条件は、取引対象品と対応付けられて設定され、例えば取引対象品の属性(例えば、区分等)、又は取引時点でのレベル又はランク値等に基づいて設定される。
【0081】
申し出受付条件の具体的な内容は、特に制限されていないが、本実施形態では、ユーザBが取引対象品と同じ区分の装備品を所持していることを申し出受付条件としている。つまり、本実施形態では、ユーザBが取引対象品と同じ区分の装備品を所持する場合に限り、ユーザBからの譲受の申し出が受け付け可能となり、ユーザBは、ユーザAが譲渡した取引対象品のレベル又はランク値を譲受(購入)することができる。ただし、このような制限が設けられていなくてもよく、ユーザBが取引対象品と同じ区分の装備品を所持していない場合であっても、ユーザBによる取引対象品のレベル又はランク値の譲受(購入)を許可してもよい。
【0082】
コスト算出部35は、取引対象品のレベル又はランク値について取引用受付部34がユーザAから譲渡の申し出を受け付けた場合に、これまでに取引対象品に費やされたコスト、特に、これまでの取引対象品の強化に費やされたコスト(以下、強化コストという。)を算出する。コスト算出部35は、強化コストの算出に際して取引対象品の装備品データをサーバ側記憶部33から読み出し、同データが示すレベル又はランク値の変更履歴に基づき、強化コストを算出する。より具体的に説明すると、これまでに取引対象品に対して使用されたパラメータ強化用アイテムのうちの有料アイテムについて、その購入金額と消費個数とから、アイテム使用による強化コストを算出する。また、これまでに取引対象品を使用してプレイされたパラメータ強化用のイベントのうちの有料イベントについて、そのプレイ料金とプレイ回数とから、イベントプレイによる強化コストを算出する。
【0083】
取引処理部36は、パラメータ取引が確定した場合に、その取引に関する処理として、取り引きされた成長パラメータの対価についての決済処理等を実行する。決済処理では、成長パラメータの譲受額(購入額)に応じた量の取引用通貨を、ユーザBの取引用通貨の所持量から減らし、ユーザBから減じた量(支払額)に応じた量の取引用通貨を、ユーザAの取引用通貨の所持量に加算する。ここで、成長パラメータの譲受額に応じた量は、譲受額に相当する量でもよいし、若しくは譲受額に一定の手数料を加えた額に相当する量でもよい。また、支払額に応じた量は、支払額に相当する量でもよいし、若しくは支払額から一定の手数料を減じた額に相当する量でもよい。
【0084】
拒否部37は、ユーザAの取引対象品が特定の条件(以下、拒否条件という。)を満たした場合に、取引対象品のレベル又はランク値について、ユーザAからの譲渡の申し出を拒否する。本実施形態では、例えば、コスト算出部35により算出された取引対象品の強化コストが所定値以上であることが、拒否条件に該当する。
取引対象品のレベル又はランク値について、ユーザAからの譲渡の申し出が拒否されると、当然ながら、取引対象品のレベル又はランク値についての取引がキャンセルとなる。
【0085】
[本実施形態に係る情報処理フロー]
次に、本実施形態に係る情報処理フローとして、ゲーム進行フロー及びパラメータ取引フローについて説明する。以下に説明する各フローは、本発明の情報処理方法を採用しており、フロー中の各ステップは、本発明の情報処理方法の構成要素に該当する。
なお、以下に説明する各フローは、あくまでも一例であり、本発明の趣旨を逸脱しない範囲において不要なステップを削除したり、新たなステップを追加したり、ステップの実施順序を入れ替えてもよい。
【0086】
<ゲーム進行フロー>
ゲーム進行フローでは、ユーザが自己のユーザ端末を使用してゲームをプレイすることにより、サーバ10が、そのプレイ内容に応じてゲームを進行させる。以下では、ゲーム進行フローとして、ユーザがゲーム内で使用する装備品のレベル又はランク値をゲームの進行度合いに応じて変更する流れについて、図11を参照しながら説明することとする。図11は、ゲーム進行フローの流れを示し、具体的には、装備品のレベル又はランク値を変更させる流れを示している。
なお、以下では、ユーザAが装備品Uを使用してゲームをプレイするケースを想定することとする。
【0087】
ユーザAが装備品Uを使用した状態でゲームをプレイすると(S001)、コンピュータであるサーバ10が、ユーザAによるゲーム進行用の操作を受け付け、具体的には、ゲーム進行用のデータをユーザ端末11から受信する(S002)。サーバ10は、受信したデータに基づいて、ユーザAがプレイしているゲームを進行させる(S003)。
【0088】
また、ユーザAが装備品Uを使用した状態でゲーム内イベントをクリアすると(S004)、サーバ10は、ユーザAの装備品Uに対して経験値を付与する(S005)。具体的には、サーバ10は、装備品Uの装備品データをサーバ側記憶部33から読み出し、読み出したデータが示す経験値の累計値に対して、ステップS003にて付与された経験値を加算する。そして、加算後の経験値の累計値が、装備品Uについて設定されたレベル用条件値に到達している場合(S006)、サーバ10は、装備品Uのレベルを到達したレベル用条件値と対応する値まで上昇させる(S007)。
【0089】
なお、本実施形態では、装備品Uを使用してゲーム内イベントをクリアした場合に経験値が装備品Uに対して付与されるが、例えば、装備品Uに対してレベルアップ用のアイテムを使用した場合にも、当該アイテムに応じた量の経験値が装備品Uに対して付与されてもよい。
【0090】
ユーザAが装備品Uに対してランク値上昇用のアイテムを使用する等、ゲーム中において強化条件を満たした場合(S008)、サーバ10は、その時点での装備品Uのランク値やアイテム使用数等に応じて決まる確率に従って、装備品Uのランク値を一つ上のランク値に上げる(S009)。
なお、強化条件が満たされたとしても、上記の確率に基づき、ランク値の上昇が実施されない場合があり、その場合にはランク値が現在値のまま維持されてもよく、あるいは低下してもよい。また、強化時に特定のアイテムを使用することにより、ランク値の上昇が見送られた場合にランク値の低下を回避することができるようにしてもよい。
【0091】
装備品Uのレベル又はランク値を上げた場合には、サーバ10が、装備品Uの装備品データが示すレベル又はランク値の現在値を上昇後のレベル又はランク値に更新する。
以上までに説明した一連のステップS002~S009は、ユーザAがゲームをプレイしている間繰り返し実施され、ユーザAがゲームを終了した時点で(S010)、ゲーム進行フローが終了する。
【0092】
なお、図11には特に図示していないが、ユーザAは、ゲームプレイ中に装備品Uをゲーム内で売却したり廃棄したりすることができ、また、進化によって装備品Uを別の装備品に変化させることができる。サーバ10は、装備品Uの売却、廃棄又は進化に伴い、ユーザAが保有する装備品Uの使用権限を消失させる。
【0093】
<パラメータ取引フロー>
パラメータ取引フローでは、パラメータ取引が行われた場合に、サーバ10が、取引に関する処理として、取引対象品及び被強化品の各々の成長パラメータを変更する処理を実行する。また、成長パラメータにはレベルとランク値が含まれ、処理の流れは、取り引きされる成長パラメータがレベルである場合と、取り引きされる成長パラメータがランク値である場合とで異なる。以下では、それぞれの場合でのパラメータ取引フローの流れについて、図12A、12B及び図13A、13Bを参照しながら説明することとする。図12A、12B及び図13A、13Bは、パラメータ取引フローの流れを示す図であり、図12A、12Bは、取り引きされる成長パラメータがレベルである場合の流れを示し、図13A、13Bは、取り引きされる成長パラメータがランク値である場合の流れを示す。
なお、以下では、ユーザAが所持する装備品Uの成長パラメータについて、ユーザAとユーザBとの間で取引を行うケースを想定することとする。
【0094】
<<取り引きされる成長パラメータがレベルである場合>>
ユーザAが装備品Uのレベルを譲渡(販売)する場合、ユーザAは、ユーザ端末11を操作してパラメータ譲渡の申し出を行う(S021)。ステップS021において、ユーザAは、取引対象品として装備品Uを選択するとともに、レベルの譲渡範囲についての指定操作を行う。
【0095】
ユーザ端末11は、ユーザAの指定操作に基づき、装備品Uのレベルについての譲渡範囲を設定する(S022)。この際、譲渡範囲の下限が、ユーザAが入手した時点での装備品Uのレベル(すなわち、レベルの初期値)を下回らないようにし、且つ、譲渡範囲の上限が装備品Uのレベルの現在値と一致するように譲渡範囲が設定される。例えば、装備品Uのレベルの初期値が1(Lv1)であり、現在値が5(Lv5)であるとすると、譲渡範囲は、最大で「Lv5→Lv1」に設定することができ、あるいは「Lv5→Lv2」、「Lv5→Lv3」若しくは「Lv5→Lv4」に設定することもできる。
【0096】
また、ステップS021において、ユーザAは、レベルの譲渡額についての指定操作を行ってもよい。その場合には、ユーザ端末11は、ユーザAの指定操作に基づき、レベルの譲渡範囲ともに譲渡額(販売額)を設定することになる。なお、レベルの譲渡範囲及び譲渡額は、ユーザAの指定操作に基づいてサーバ10側で設定されてもよい。
【0097】
その後、ユーザ端末11は、パラメータ(詳しくは、レベル)の譲渡に関するデータを生成してサーバ10に向けて送信する。サーバ10は、ユーザ端末11から送られてくるデータを受信することで、装備品Uのレベルについて、ユーザAからの譲渡の申し出を受け付ける(S023)。サーバ10は、ユーザAが譲渡を申し出た装備品Uのレベルについて、その譲渡範囲に相当するレベル変更量を経験値に換算する(S024)。そして、サーバ10は、装備品Uのレベルについての譲渡の申し出、及び、換算された経験値等を示す取引データをサーバ側記憶部33に記録する(S025)。以降、その取引データは、各ユーザによって検索可能な状態で蓄積される。
【0098】
サーバ10は、装備品UのレベルについてユーザAから譲渡の申し出を受け付けると、その時点でユーザAが装備品Uを使用してゲームをプレイしている最中であるか否かを判定する(S026)。ユーザAが装備品Uを使用してゲームをプレイしている最中であると判定した場合(S026でYes)、サーバ10は、装備品UのレベルについてユーザAから譲渡の申し出を受け付けてから取引条件が成立するまでの間(以下、待機期間という。)、装備品Uのレベルを現在値に維持したまま、ユーザAの装備品Uの使用に応じてゲームを進行させる(S027)。
【0099】
また、ステップS027を実施する場合、サーバ10は、待機期間中には装備品Uの状態を変えず、具体的には装備品Uの売却、廃棄、強化及び進化を禁止(ロック)する(S028)。これらの手続きは、装備品Uの帰属及びレベル等を変える操作であり、装備品Uのレベルについての取引に対して影響を与え得るからである。
【0100】
なお、ステップS027を実施する場合、待機期間中にユーザAが装備品Uを使用してゲームを進めることで獲得した経験値は、一時的にストックすることとする。そして、装備品UのレベルについてユーザBから譲受の申し出がないまま取引が終了した場合には、ストックしておいた経験値を装備品Uに付与してもよい。
【0101】
ステップS026に戻って説明すると、ユーザAが装備品Uを使用してゲームをプレイしていないと判定した場合(S026でNo)、上記のステップS027及びS028は実施されず、以降のステップに移行する。
【0102】
ユーザBは、入手可能な経験値及び譲渡額等をキーとして取引データを検索する。検索の結果、装備品UのレベルについてユーザAが申し出た譲渡の内容(具体的には、入手可能な経験値及び譲渡額等)がユーザBにとって好適である場合、ユーザBは、そのレベルについてパラメータ譲受(購入)の申し出を行う(S029)。ステップS029において、ユーザBは、ユーザ端末12を通じて、レベルを譲受する対象(取引対象品)として装備品Uを選択するとともに、レベルの譲受額(購入額)についての指定操作を行う。また、ユーザBは、ステップS029において、ユーザBが所持する装備品のうち、譲受したレベルによって強化される対象となるもの(被強化品)を選択する。
【0103】
その後、ユーザ端末12は、パラメータ(詳しくは、レベル)の譲受に関するデータを生成してサーバ10に向けて送信し、サーバ10は、ユーザ端末12から送られてくるデータを受信することで、装備品Uのレベルについて、ユーザBからの譲受の申し出を受け付ける(S031)。
【0104】
本実施形態では、サーバ10がユーザBから譲受の申し出を受け付けるにあたり、取引対象品である装備品Uと同じ区分に分類される装備品がユーザBによって所持されているかどうかを判定する(S030)。そして、装備品Uと同じ区分に分類される装備品をユーザBが所持していると判定された場合に限り(S030でYes)、サーバ10は、装備品UのレベルについてユーザBからの譲渡の申し出を受け付ける。つまり、本実施形態において、サーバ10は、装備品UのレベルについてユーザAから譲渡の申し出を受け付けた場合に、装備品Uと同じ区分に分類される装備品を所持するユーザ(第2ユーザ)のみから、譲受の申し出を受け付ける。
なお、ステップS030における判定は、サーバ10が行ってもよいし、あるいはユーザB側(具体的には、ユーザBのユーザ端末12)にて行われてもよい。
【0105】
サーバ10は、装備品UのレベルについてユーザA及びユーザBの各々から申し出を受け付けると、ステップS025でサーバ側記憶部33に記録された取引データの成否フラグを「0(取引未確定)」から「1(取引確定)」に切り替える。これにより、取引条件が成立する(S034)。なお、図12A、12Bには特に図示していないが、装備品Uのレベルについて、ユーザAの指定操作に基づいて譲渡額(販売額)が設定された場合には、ユーザBによって指定された譲受額(購入額)が譲渡額以上であれば、取引条件成立としてもよい。また、装備品Uのレベルについて、譲受を申し出たユーザが複数存在する場合には、最高の譲受額を指定したユーザとユーザAとの間で取引を確定し、その他のユーザについては取引中止としてもよい。
【0106】
その後、サーバ10は、ユーザBがユーザAから譲受したレベルに応じて、ユーザBが被強化品として選択した装備品のレベルを変更させる。より詳しく説明すると、サーバ10は、ユーザBが譲受したレベルを経験値に変換し、変換された経験値を被強化品の経験値の累計値に加算する(S033)。このステップS032にて加算される経験値は、ステップS024にて算出された経験値と同じ値である。そして、サーバ10は、加算後の経験値の累計値がレベル用条件値に到達している場合には(S034)、到達したレベル用条件値と対応する値まで被強化品のレベルを上げる(S035)。
【0107】
以上のように、本実施形態では、レベルが経験値に変換されて被強化品に付与されるため、被強化品のレベルに関わらず、ユーザ間でのレベルの取引を行うことが可能である。ただし、これに限定されるものではなく、ユーザAから譲受したレベルに応じて強化される被強化品を、一定のレベルに到達した装備品、あるいは一定のレベルに達していない装備品に制限してもよい。
【0108】
また、サーバ10は、取引条件の成立時点にてユーザAが装備品Uを使用してゲームをプレイしているか否かを判定する(S036)。ユーザAが装備品Uを使用してゲームをプレイしていないと判定した場合(S036でNo)、サーバ10は、ユーザAがユーザBに譲渡したレベルに応じて、装備品Uのレベルを下げる(S037)。この結果、ステップS022にて設定されたレベルの譲渡範囲に相当する変更量だけ、装備品Uのレベルが下がる。
【0109】
他方、ステップS034において、ユーザAが装備品Uを使用してゲームをプレイしていると判定した場合(S036でYes)、サーバ10は、ユーザAが装備品Uを使用し続ける間、装備品Uのレベルを変えずに現在値に維持したまま、ユーザAの装備品Uの使用に応じてゲームを進行させる(S037)。つまり、装備品UのレベルについてユーザBから譲受の申し出を受け付けた時点でユーザAが装備品Uをゲーム内で使用している場合には、一時的に、装備品Uのレベルが取引前の値に維持され、ユーザBの被強化品のレベルが取引後(すなわち、強化後)の値になる。
【0110】
そして、ユーザAが装備品Uの使用を終了すると(例えば、ユーザAがゲームを終了すると)、サーバ10は、ステップS037を実施して装備品Uのレベルを下げる。
【0111】
なお、図12A、12Bには示していないが、パラメータ取引に関する一つの処理として、サーバ10は、装備品Uのレベルについて前述の決済処理を実行する。すなわち、サーバ10は、ユーザBが指定した譲受額(購入額)に応じた量の取引用通貨を、ユーザBの取引用通貨の所持量から減らすとともに、ユーザBから減らした量(支払額)に応じた量の取引通貨量を、ユーザAの取引用通貨の所持量に加算する。決済処理の実行タイミングは、取引条件の成立直後(つまり、パラメータ取引の確定時点)でもよく、あるいは、ステップS036においてユーザAが装備品Uを使用していると判断された後にユーザAが装備品Uの使用を終了した時点でもよい。
【0112】
以上までに説明した一連のステップが終了すると、その時点で、装備品Uのレベルについての取引に係る情報処理フロー(パラメータ取引フロー)が終了する。
【0113】
<<取り引きされる成長パラメータがランク値である場合>>
ユーザAが装備品Uのランク値を譲渡(販売)する場合、ユーザAは、ユーザ端末11を操作してパラメータ譲渡の申し出を行う(S041)。ステップS041において、ユーザAは、取引対象品として装備品Uを選択するとともに、ランク値の譲渡範囲についての指定操作を行う。
【0114】
ユーザ端末11は、ユーザAの指定操作に基づき、装備品Uのランク値についての譲渡範囲を設定する(S042)。この際、譲渡範囲の下限が、ユーザAが入手した時点での装備品Uのランク値(すなわち、ランク値の初期値)を下回らないようにし、且つ、譲渡範囲の上限が装備品Uのランク値の現在値と一致するように譲渡範囲が設定される。例えば、装備品Uのランク値の初期値が+1であり、現在値が+4であるとすると、譲渡範囲は、最大で「+4→+1」とすることができ、あるいは「+4→+2」若しくは「+4→+3」とすることもできる。
【0115】
また、ステップS041において、ユーザAは、ランク値の譲渡額についての指定操作を行ってもよい。その場合には、ユーザ端末11は、ユーザAの指定操作に基づき、ランク値の譲渡範囲ともに譲渡額(販売額)を設定することになる。なお、ランク値の譲渡範囲及び譲渡額等は、ユーザAの指定操作に基づいてサーバ10側で設定されてもよい。
【0116】
その後、ユーザ端末11は、パラメータ(詳しくは、ランク値)の譲渡に関するデータを生成してサーバ10に向けて送信する。サーバ10は、ユーザ端末11から送られてくるデータを受信することで、装備品Uのランク値について、ユーザAからの譲渡の申し出を受け付ける(S043)。
【0117】
サーバ10は、装備品Uのランク値についてユーザAからの譲渡の申し出を受け付けると、これまでの装備品Uの強化(ランク値の上昇)に費やしたコスト、すなわち強化コストを算出する(S044)。その後、サーバ10は、算出した強化コストが所定値以上(例えば1円以上)であるか否かを判定する(S045)。強化コストが所定値以上である場合(S045でYes)、サーバ10は、ユーザAから受け付けた装備品Uのランク値についての譲渡の申し出を拒否する(S046)。かかる場合には、ステップS046を実施した時点で、パラメータ取引フローが終了する。
【0118】
他方、強化コストが所定値未満である場合には(S045でNo)、ステップS047へ移行する。ステップS047では、サーバ10が、装備品Uのランク値についての譲渡の申し出、及びランク値の譲渡範囲等を示す取引データをサーバ側記憶部33に記録する。以降、その取引データは、各ユーザによって検索可能な状態で蓄積される。
【0119】
以降の流れ(すなわち、S048~S058)は、図13A、13Bに示すように、装備品Uのレベルを取り引きする場合の流れ(S026~S038)と概ね共通する。
【0120】
具体的に説明すると、装備品Uのランク値についてサーバ10がユーザAから譲渡の申し出を受け付けた時点でユーザAが装備品Uを使用してゲームをプレイしていたとする(S048でYes)。この場合、サーバ10は、装備品Uのランク値についてユーザAから譲渡の申し出を受け付けてから取引条件が成立するまでの間、すなわち待機期間中には、装備品Uのランク値を現在値に維持したまま、ユーザAの装備品Uの使用に応じてゲームを進行させる(S049)。また、サーバ10は、待機期間中には装備品Uの状態を変えないように装備品Uの売却、廃棄、強化及び進化を禁止(ロック)する(S050)。
【0121】
また、ユーザBがランク値の譲渡範囲及び譲渡額等をキーとして取引データを検索した結果、装備品Uのランク値についてユーザAが申し出た譲渡の内容がユーザBにとって好適である場合、ユーザBは、そのランク値に対してパラメータ譲受(購入)の申し出を行う(S051)。この際、ユーザBは、取引対象品として装備品Uを選択するとともに、ランク値の譲受額(購入額)を指定し、さらに、ユーザBが所持する装備品の中から、譲受したランク値によって強化される被強化品を選択する。
【0122】
その後、ユーザ端末12により、パラメータ(詳しくは、ランク値)の譲受に関するデータが生成され、サーバ10は、当該データをユーザ端末12から受信することで、装備品Uのランク値について、ユーザBからの譲受の申し出を受け付ける(S053)。
【0123】
なお、ステップS053の実施にあたり、取引対象品である装備品Uと同等の装備品をユーザBが所持しているかどうかが判定される(S052)。装備品Uと同等の装備品とは、装備品Uと同じ区分に分類され、且つ、ランク値の現在値が装備品Uのランク値の譲渡範囲における下限と一致する装備品である。そして、装備品Uと同等の装備品をユーザBが所持する場合に限り(S052でYes)、サーバ10は、装備品Uのランク値についてユーザBからの譲渡の申し出を受け付ける。
【0124】
サーバ10は、装備品Uのランク値についてユーザA及びユーザBの各々から申し出を受け付けると、ステップS047でサーバ側記憶部33に記録された取引データの成否フラグを「0(取引未確定)」から「1(取引確定)」に切り替える。これにより、取引条件が成立する(S054)。なお、図13A、13Bには特に図示していないが、装備品Uのランク値について、ユーザAの指定操作に基づいて譲渡額(販売額)が設定された場合に、ユーザBによって指定された譲受額(購入額)が譲渡額以上であれば、取引条件成立としてもよい。また、装備品Uのランク値について、譲受を申し出たユーザが複数存在する場合には、最高の譲受額を指定したユーザとユーザAとの間で取引を確定し、その他のユーザについては取引中止としてもよい。
【0125】
その後、サーバ10は、取引条件の成立をトリガーとして、ユーザBがユーザAから譲受したランク値に応じて、ユーザBが被強化品として選択した装備品のランク値を上昇させる(S055)。ここで、被強化品となる装備品は、取引対象品である装備品Uの区分と同じ区分に分類される装備品、又は区分の番号が装備品Uの区分より小さい区分に分類される装備品に限定されてもよい。
【0126】
サーバ10は、ユーザAがユーザBに譲渡したランク値に応じて、装備品Uのランク値を下げ、詳しくは、ステップS042にて設定された譲渡範囲に相当する変更量だけ下げる(S057)。なお、取引条件の成立時点でユーザAが装備品Uを使用してゲームをプレイしている場合には(S056でYes)、サーバ10は、ユーザAが装備品Uを使用し続ける間は装備品Uのランク値を変えずに現在値に維持したまま、ユーザAの装備品Uの使用に応じてゲームを進行させる(S058)。その後、ユーザAが装備品Uの使用を終了した時点で、サーバ10は、ステップS057を実施して装備品Uのランク値を下げる。
【0127】
なお、図13A、13Bには示していないが、取引条件の成立に伴い、サーバ10は、装備品Uのランク値について決済処理を実行する。すなわち、サーバ10は、ユーザBが指定した譲受額(購入額)に応じた量の取引用通貨を、ユーザBの取引用通貨の所持量から減らすとともに、ユーザBから減らした量(支払額)に応じた量の取引通貨量を、ユーザAの取引用通貨の所持量に加算する。決済処理の実行タイミングは、取引条件の成立直後(つまり、パラメータ取引の確定時点)でもよく、あるいは、ステップS056においてユーザAが装備品Uを使用していると判断された後にユーザAが装備品Uの使用を終了した時点でもよい。
【0128】
以上までに説明した一連のステップが終了すると、その時点で、装備品Uのランク値についての取引に係る情報処理フロー(パラメータ取引フロー)が終了する。
【0129】
[第1の変形例について]
上記の実施形態では、装備品Uのランク値についてユーザAからの譲渡の申し出を受け付けると、これまでの装備品Uの強化に要した強化コストを算出し、強化コストが所定値以上である場合には、ユーザAからの譲渡の申し出を拒否することとした。ただし、本発明は、このような実施形態に限られず、別の形態(以下、第1の変形例という。)が考えられる。以下に、第1の変形例について、図14、15A、15Bを参照しながら説明する。図14は、第1の変形例に係る情報処理装置であるサーバ10Xの機能を示す。図15A、15Bは、第1の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す。
なお、以下では、第1の変形例のうち、上記の実施形態と相違する点を主として説明し、上記の実施形態と共通する点については、説明を省略することとする。
【0130】
第1の変形例に係る情報処理装置は、サーバ10Xによって構成されている。サーバ10Xの構成及び機能は、上記の実施形態(本実施形態)に係るサーバ10と概ね同様であるが、図14に示すように拒否部37の代わりに条件設定部38を有する点でサーバ10と相違する。条件設定部38は、サーバ10Xのハードウェア機器とソフトウェアとの協働により実現される機能(つまり、サーバ10Xが備える一つの機能部)である。条件設定部38は、取引対象品である装備品Uのパラメータについての譲受条件、具体的には最低譲受額(最低購入額)を設定する。この際、条件設定部38は、コスト算出部35により算出された強化コストに応じて最低譲受額を設定する。
【0131】
そして、第1の変形例では、装備品Uのパラメータについて、ユーザB(第2ユーザ)からの譲受の申し出が譲受条件を満たす場合、具体的には、ユーザBが指定した譲受額が最低譲受額以上である場合に限り、ユーザBからの譲受の申し出を受け付けることになっている。
【0132】
次に、第1の変形例に係るパラメータ処理フローとして、取り引きされる成長パラメータがランク値である場合の流れを説明する。第1の変形例に係るパラメータ処理フローの各ステップ(具体的には、S061~S064、S066~S071、S073、S075~S079)は、図15A、15Bから分かるように、上記の実施形態に係るパラメータ処理フローの各ステップと概ね共通している。
【0133】
一方、第1の変形例では、図15A、15Bに示すように、サーバ10Xが、これまでに装備品Uの強化に費やされた強化コストを算出した後に、算出した強化コストに応じて最低譲受額を設定する(S065)。最低譲受額は、強化コストに相当する額又はそれ以上の額に設定されるのが好ましい。
【0134】
また、第1の変形例では、装備品Uのランク値について、サーバ10XがユーザAから譲渡の申し出を受け付けた後にユーザBが譲受の申し出を行うと、サーバ10Xが、ユーザBによって指定された譲受額(販売額)が最低譲受額以上であるかを判定する(S072)。そして、ユーザBによって指定された譲受額が最低譲受額以上である場合、サーバ10Xは、装備品Uのランク値についてユーザBからの譲渡の申し出を受け付ける(S073)。
【0135】
一方、ユーザBによって指定された譲受額が最低譲受額を下回る場合には、サーバ10Xは、ユーザBからの譲渡の申し出を受け付けない。この場合、ユーザAから譲渡の申し出を受け付けてから所定時間が経過するまでの間に(S074)、最低譲受額以上の譲受額を指定している申し出がなければ、その時点でパラメータ取引フローが終了する。このような手順によれば、ユーザAは、これまでにコストを費やして上げてきた装備品Uのランク値が最低譲受額を下回る額にて譲渡(販売)される事態を回避することができるので、ユーザAに対して取引上の損失を与えないようにすることができる。
【0136】
なお、上記の状況でパラメータ取引フローが終了した場合(S074でYesのケース)においては、ゲームの運営会社等が、最低譲受額と同額又はそれ以上の額にて装備品Uのランク値を買い取ってもよい。
【0137】
また、上述した第1の変形例に係るパラメータ取引フローは、取り引きされる成長パラメータがランク値である場合に限定されず、取り引きされる成長パラメータがレベルである場合にも適用することができる。
【0138】
[第2の変形例について]
上記の実施形態では、装備品Uのランク値について、設定された譲渡範囲のランク値を一括して取引(売買)し、パラメータの譲受を申し出た一人のユーザが譲渡範囲のランク値をすべて譲受(購入)することとした。ただし、本発明は、このような実施形態に限られず、別の形態(以下、第2の変形例という。)が考えられる。以下に、第2の変形例について、図16A、16Bを参照しながら説明する。
図16A、16Bは、第2の変形例に係るパラメータ取引フローを示し、取り引きされる成長パラメータがランク値である場合の流れを示す。
【0139】
第2の変形例では、装備品Uの成長パラメータについて譲渡範囲が設定されると、その譲渡範囲が複数の小範囲に分けられる。複数の小範囲は、それぞれの上限及び下限が互いに異なる範囲である。そして、第2の変形例では、譲渡範囲のランク値が複数の小単位に分けて譲渡(販売)され、換言すると、譲渡されたランク値を小範囲毎に譲受(購入)することができる。これにより、第2ユーザであるユーザBは、譲渡範囲のランク値全てを購入する必要がなく、希望する範囲(小範囲)のランク値を購入すればよいので、より合理的且つ経済的にランク値を購入することができる。また、譲渡範囲のランク値を複数の小単位に分けて譲渡(販売)するため、複数のユーザに対してランク値を小単位毎に譲渡することができる。
【0140】
なお、譲渡範囲を複数の小範囲に分ける場合の手順については、特に制限はなく、例えば、各小範囲の上限及び下限等は、任意の値に決めてもよい。また、複数の小範囲は、ランク値を譲渡するユーザAが決めてもよく、あるいはランク値を譲受するユーザB及びその他のユーザが決めてもよく、あるいはサーバ10側で自動的に決めてもよい。
【0141】
また、第2の変形例では、譲渡されたランク値を小範囲毎に譲受する際、譲渡範囲の上限に最も近い(つまり、上限が最も大きい)小範囲から順に、それぞれの小範囲のランク値を譲受することになっており、換言すると、譲渡範囲の上限に最も近い小範囲から順に譲受の申し出を受け付ける。具体例を挙げて説明すると、「+3→0」に設定された譲渡範囲が「+3→+2」、「+2→+1」及び「+1→0」の小範囲に分けられた場合には、この順で、各小範囲のランク値が譲受(購入)される。
【0142】
次に、第2の変形例に係るパラメータ処理フローとして、取り引きされる成長パラメータがランク値である場合の流れを説明する。なお、以下では、ランク値を譲受するユーザ(すなわち、第2ユーザ)がユーザB以外にも存在するケースを想定し、これらのユーザをまとめて「ユーザB等」と呼ぶこととする。
【0143】
第2の変形例に係るパラメータ処理フローの各ステップは、図16A、16Bから分かるように、第1の変形例に係るパラメータ処理フローの各ステップと概ね共通している。すなわち、第2の変形例においても、先ず、第1ユーザであるユーザAが装備品Uのランク値について譲渡の申し出を行い(S081)、ランク値についての譲渡範囲が設定される(S082)。第2の変形例では、その後、例えばユーザAのユーザ端末11にて、ユーザAの操作に基づき、譲渡範囲が複数の小範囲に分けられる(S083)。なお、以下では、装備品Uのランク値の譲渡範囲が「+3→0」に設定され、「+3→+2」、「+2→+1」及び「+1→0」の小範囲に分かれることとする。
【0144】
サーバ10は、装備品Uのランク値について、譲渡範囲及び複数の小範囲等を示すデータをユーザ端末11から受信することでユーザAからの譲渡の申し出を受け付ける(S084)。その後、サーバ10は、装備品Uのランク値の変更履歴に基づき、これまでに装備品Uの強化に費やされた強化コストを算出する(S085)。この際、強化コストは、譲渡範囲を分けた複数の小範囲の各々について算出される。すなわち、サーバ10は、ランク値が「0→+1」に上がる際に費やされた強化コスト、ランク値が「+1→+2」に上がる際に費やされた強化コスト、及び、ランク値が「+2→+3」に上がる際に費やされた強化コストをそれぞれ算出する。
【0145】
また、サーバ10は、小範囲毎に算出された強化コストに応じて、各小範囲のランク値についての最低譲受額を設定する(S086)。つまり、サーバ10は、ランク値についての譲受条件である最低譲受額を小範囲毎に設定する。その後、装備品Uのランク値についての譲渡範囲及び複数の小範囲、並びに、各小範囲のランク値に対して設定された最低譲受額等を示す取引データがサーバ側記憶部33に記録されて蓄積される(S087)。続くステップS088~S090は、上述した実施形態に係るパラメータ取引フローのステップS048~S050やステップS067~S069と同様である。
【0146】
一方、ユーザB等の各ユーザは、取引データを検索し、装備品Uのランク値についてユーザAが申し出た譲渡の内容がユーザBにとって好適である場合には、そのランク値に対してパラメータ譲受(購入)の申し出を行う(S091)。この際、ユーザB等の各ユーザは、一つの小範囲を取引単位とし、当該小範囲に該当するランク値について譲受の申し出を行う。譲受の申し出は、上限が最も大きい小範囲から順に受け付け可能であり、具体的には「+3→+2」、「+2→+1」、「+1→0」の順に受け付けられる。
【0147】
サーバ10は、ユーザB等の各ユーザから譲受の申し出を受け付けるにあたり、各ユーザが装備品Uと同等の装備品を所持しているか否か、及び、各ユーザが指定した譲受額が最低譲受額以上であるか否かを判定する(S092、S093)。ここで、装備品Uと同等の装備品とは、装備品Uと同じ区分に分類される装備品であって、そのランク値の現在値が、譲渡を申し出た小範囲の下限と一致する装備品である。
【0148】
上記の判定S092、S093は、小範囲毎に行われる。そして、ある一つの小範囲(以下、取引小範囲)のランク値について譲受を申し出たユーザが装備品Uと同等の装備品を所持していない場合(S092でNo)、その時点で当該取引小範囲についてのパラメータ取引フローが終了する。
また、ユーザAから譲渡の申し出を受け付けてから所定時間が経過するまでの間に、取引小範囲について最低譲受額以上の譲受額を指定した譲受の申し出がない場合(S093でNo、且つS094でYes)にも、当該取引小範囲についてのパラメータ取引フローが終了する。この場合には、ゲームの運営会社等が、最低譲受額と同額又はそれ以上の額にて当該小範囲のランク値を買い取ってもよい。
【0149】
その後のステップS095~S099は、上述した実施形態に係るパラメータ取引フローのステップ(具体的には、ステップS054~S058、ステップS075~S079)と同様である。
【0150】
そして、第2の変形例では、ユーザB等の各人が譲受の申し出を行ってからの一連のステップS091~S099が小範囲毎に実施され、換言すると、複数の小範囲のうち、ランク値の取引が未確定である小範囲が残っている場合には(S0100)、ステップS091~S099が繰り返される。そして、すべての小範囲について取引が確定し、各小範囲のランク値に対する取引処理(譲渡及び譲受)が完了した時点で(S100でYes)、第2の変形例に係るパラメータ取引フローが終了する。
【0151】
なお、上述のフローでは、複数の小範囲の各々について強化コストを算出し、小範囲毎に算出された強化コストに応じて、各小範囲のランク値についての最低譲受額を設定し、最低譲受額以上の譲受額を指定したユーザに対して当該ランク値を譲渡することとした。ただし、これに限定されるものではなく、複数の小範囲のうち、強化コストが所定値以上である小範囲については、譲渡不可(販売不可)とし、強化コストが所定値未満である小範囲のランク値のみを譲渡できるようにしてもよい。あるいは、複数の小範囲の中に、強化コストが所定値以上である小範囲が一つ以上存在する場合には、複数の小範囲のすべて、つまり譲渡範囲全体に亘って譲渡不可としてもよい。
【0152】
また、上述した第2の変形例に係るパラメータ取引フローは、取り引きされる成長パラメータがランク値である場合に限定されず、取り引きされる成長パラメータがレベルである場合にも適用することができる。
【0153】
[その他の実施形態]
以上までに、本発明の情報処理装置、情報処理方法、及びプログラムに関して、具体例を挙げて説明してきたが、上述した実施形態は、あくまでも一例に過ぎず、他の実施形態も考えられ得る。
【0154】
上記の実施形態では、サーバコンピュータ(サーバ10、10X)が本発明の情報処理装置の機能を発揮することとしたが、上記サーバコンピュータが有する機能のうちの一部、例えばパラメータ変更部43が第2ユーザのユーザ端末12に備わってもよい。その場合には、ユーザ端末12が、第2ユーザが所持するゲーム媒体の成長パラメータを、第2ユーザが第1ユーザから譲受した成長パラメータに応じて変更してもよい。
【0155】
また、上記の実施形態では、取引(売買)される成長パラメータが、装備品のレベル又はランク値であることとしたが、これに限定されず、装備品以外のゲーム媒体、例えばゲーム内のキャラクタの成長パラメータであってもよく、具体的には、キャラクタの能力、体力、知力、運気、人気及びその他のステータス値であってもよい。
【0156】
また、成長パラメータは、レベル及びランク値のような数値によって表されるものに限られない。すなわち、取り引きされる成長パラメータは、ゲーム媒体の優劣順位又は品質の高低を表すものであって、ゲームの進行具合に応じて変化(詳しくは上下)するものであればよく、例えば「A、B、C・・・」や「金、銀、銅・・・」のような文字や記号によって表されるものであってもよい。また、ゲーム媒体のレア度(入手困難性)及びレア度に基づく区分を成長させることができるゲームでは、レア度を成長パラメータとして取引を行ってもよい。
【0157】
また、本実施形態では、成長パラメータの値が大きい(上がる)ほど、その成長パラメータを有するゲーム媒体の性能又は能力が高く優れていることとしたが、これに限定されるものではない。成長パラメータは、成長に応じて初期値から減少する(下がる)値であってもよい。その場合には、成長パラメータが小さい(下がる)ほど、その成長パラメータを有するゲーム媒体の性能又は能力が高く優れていることになる。
【0158】
また、上記の実施形態では、ユーザ間で成長パラメータが有料で取り引きされることとしたが、これに限定されず、成長パラメータの取引(つまり、パラメータの譲渡及び譲受)が無料で実施されてもよい。
【0159】
また、上記の実施形態では、第2ユーザが第1ユーザから成長パラメータ(具体的には、レベルに相当する経験値やランク値)を譲受すると、それを契機として、第2ユーザが所持するゲーム媒体の成長パラメータを、譲受した成長パラメータに応じて変更することとした。ただし、これに限定されるものではなく、例えば、第2ユーザが第1ユーザから譲受した成長パラメータを一時的にストックすることができてもよい。この場合、パラメータ譲受後、任意の時間に第2ユーザが強化対象のゲーム媒体を指定し、そのゲーム媒体の成長パラメータを、ストックしておいた成長パラメータに応じて変化させてもよい。また、ストックした成長パラメータを第2ユーザのゲーム媒体の強化に利用できる権限(利用回数)が設定され、利用回数だけ、第2ユーザが、ストックした成長パラメータを用いて強化するゲーム媒体を入れ替えることができるようにしてもよい。
【0160】
[まとめ]
本発明では、以下に示す構成によって奏する効果が得られる。
[1] 本発明の情報処理装置は、第1ユーザがゲームにて成長させる第1ゲーム媒体の成長パラメータについて、第1ユーザから譲渡の申し出を受け付け、且つ、第2ユーザから譲受の申し出を受け付ける受付部と、受付部が第1ユーザ及び第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、第2ユーザがゲームにて成長させる第2ゲーム媒体の成長パラメータを、第2ユーザが第1ユーザから譲受した成長パラメータに応じて変更するパラメータ変更部と、を備える。
上記の構成によれば、第1ユーザは、これまでのゲーム内で強化してきたゲーム媒体の成長パラメータを譲渡し、第2ユーザは、第1ユーザが譲渡した成長パラメータを譲受して、自分のゲーム媒体の成長パラメータを変更させるのに利用することができる。このようにゲーム媒体の成長パラメータを対象としてユーザ間で取引を実施することができれば、ユーザ間の交流が活性化され、これにより、ゲームプレイの促進を図ることができる。
【0161】
[2] また、本発明の情報処理装置において、受付部が第1ユーザ及び第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、パラメータ変更部が、第2ユーザが第1ユーザから譲受した成長パラメータに応じて第2ゲーム媒体の成長パラメータを上げ、且つ、第1ユーザが第2ユーザに譲渡した成長パラメータに応じて第1ゲーム媒体の成長パラメータを下げてもよい。
上記の構成によれば、ユーザ間でパラメータ取引が行われた場合に、その取引内容をゲームに適切に反映させることができる。つまり、パラメータ取引を行った第1ユーザ及び第2ユーザの各々のゲーム媒体(詳しくは、取引対象品及び被強化品)については、取引によって成長パラメータが変更されるため、各ユーザがゲームを公平にプレイすることができる。また、パラメータ取引に伴う使用権限の移譲はなく、第1ゲーム媒体の使用権限は取引後にも第1ユーザに残るので、第1ユーザのパラメータ取引に対する意欲を喚起することができる。
【0162】
[3] また、本発明の情報処理装置において、第1ゲーム媒体の成長パラメータについての第2ユーザからの譲受の申し出が、第1ゲーム媒体と対応付けられた申し出受付条件を満たす場合に、受付部によって、第2ユーザからの譲の申し出が受け付け可能となってもよい。
上記の構成によれば、第2ユーザからの譲の申し出に対して申し出受付条件を設定することで、ゲーム進行上におけるユーザ間の不平等を是正して公平な取引を実現することができる。例えば、レア度が低い区分のゲーム媒体の成長パラメータを譲受(購入)し、譲受した成長パラメータを利用して、レア度が高い区分のゲーム媒体を成長させることは、ゲームの進行上の公正さを欠くため、好ましい行為ではない。そこで、取引対象のゲーム媒体と同じ区分に属するゲーム媒体を第2ユーザが所持することを申し出受付条件に設定することにより、ゲームの公正なプレイをユーザに順守させることができる。
【0163】
[4] また、本発明の情報処理装置は、各ユーザがゲームにて成長させるゲーム媒体の状態を各ユーザの操作に応じて変える状態変更部を備えてもよい。この場合、第1ゲーム媒体の成長パラメータについて受付部が第1ユーザから譲渡の申し出を受け付けてから所定の条件が成立するまでの間、状態変更部は、第1ゲーム媒体の状態を変えないと、好適である。
上記の構成では、第1ゲーム媒体の成長パラメータについて第1ユーザから譲渡の申し出があった場合に、取引成立前に第1ゲーム媒体の状態が変更するために取引内容に影響が及んでしまう事態を回避することができる。
【0164】
[5] また、本発明の情報処理装置は、各ユーザのゲーム媒体の使用に応じてゲームを進行させるゲーム進行部を備えてもよい。この場合、第1ゲーム媒体の成長パラメータについて受付部が第1ユーザから譲渡の申し出を受け付けてから所定の条件が成立するまでの間、ゲーム進行部は、第1ゲーム媒体の成長パラメータを維持したまま、第1ユーザの第1ゲーム媒体の使用に応じてゲームを進行させると、好適である。
上記の構成では、第1ユーザが第1ゲーム媒体を使用してゲームをプレイしている場合、第1ユーザが第1ゲーム媒体の成長パラメータについて譲渡の申し出を行ってから第2ユーザから譲受の申し出があるまでの間は、第1ゲーム媒体の成長パラメータが維持される。これにより、第1ゲーム媒体を使用してゲームをプレイしている間のパラメータ変更による不利益(例えば、パラメータ変更に伴ってゲーム難易度が変わる等)を、第1ユーザに対して与えないようにすることができる。
【0165】
[6] また、本発明の情報処理装置において、所定の条件が成立した時点で第1ユーザがゲームにて第1ゲーム媒体を使用している場合、パラメータ変更部は、第1ユーザの第1ゲーム媒体の使用が終了するまで第1ゲーム媒体の成長パラメータを変えず、第1ユーザの第1ゲーム媒体の使用が終了した際に、第1ゲーム媒体の成長パラメータを変更するとよい。
上記の構成では、第1ユーザが第1ゲーム媒体を使用してゲームをプレイしている場合、第1ユーザが第1ゲーム媒体の使用を終了するまでは、第1ゲーム媒体のパラメータが維持される。これにより、第1ゲーム媒体の使用中におけるパラメータ変更による不利益を、第1ユーザに与えないようにすることができる。
【0166】
[7] また、本発明の情報処理装置において、各ユーザがゲーム媒体を使用してゲームを進行させる間において、パラメータ変更部は、各ユーザがゲーム内のイベントをクリアすることでゲーム媒体に対して加算される経験値の累計値に応じて、ゲーム媒体の成長パラメータを変更してもよい。この場合、第1ゲーム媒体の成長パラメータについて、受付部が第1ユーザ及び第2ユーザから申し出を受け付けて所定の条件が成立した場合に、パラメータ変更部は、第2ユーザが第1ユーザから譲受した成長パラメータに基づいて変わる第2ゲーム媒体の経験値の累計値に応じて、第2ゲーム媒体の成長パラメータを変更させると好適である。
上記の構成によれば、第2ユーザが第1ユーザから譲受した成長パラメータを経験値に換算し、換算された経験値に応じて、第2ゲーム媒体の成長パラメータを変更する。この場合には、第2ゲーム媒体の成長パラメータの現在値に関わらず、第1ユーザから譲受した成長パラメータを、第2ゲーム媒体の成長のために有効に利用することができる。
【0167】
[8] また、本発明の情報処理装置は、各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部と、第1ゲーム媒体の成長パラメータについて受付部が第1ユーザから譲渡の申し出を受け付けた場合に、第1ゲーム媒体のパラメータ変更履歴に基づき、これまでに第1ゲーム媒体に費やされたコストに応じて、第1ゲーム媒体の成長パラメータについての譲受条件を設定する条件設定部と、をさらに備えてもよい。この場合に、第1ゲーム媒体の成長パラメータについて、第2ユーザからの譲受の申し出が譲受条件を満たす場合に、受付部は、第2ユーザからの譲受の申し出を受け付けてもよい。
上記の構成では、第1ゲーム媒体に費やされたコストに応じて設定される譲受条件を満たす場合に限り、第2ユーザからのパラメータ譲受の申し出を受け付ける。これにより、コストに見合った譲受の申し出が第2ユーザからなされるので、パラメータ取引にて第1ユーザがコストとの関係で損失を被る事態を回避することができる。
【0168】
[9] また、本発明の情報処理装置は、各ゲーム媒体に対して費やされたコストの情報を含むパラメータ変更履歴を、ゲーム媒体毎に記憶する記憶部を備えてもよい。この場合において、本発明の情報処理装置は、第1ゲーム媒体の成長パラメータについて受付部が第1ユーザから譲渡の申し出を受け付けた場合に、第1ゲーム媒体のパラメータ変更履歴に基づき、これまでに第1ゲーム媒体に費やされたコストが所定値以上である場合には、第1ゲーム媒体の成長パラメータについて、第1ユーザからの譲渡の申し出を拒否する拒否部と、をさらに備えてもよい。
上記の構成では、第1ゲーム媒体に費やされたコストが所定値を超える場合、第1ユーザからのパラメータ譲渡の申し出を拒否する。これにより、コストとの関係で第1ユーザにとって不利となるパラメータ取引をキャンセルし、そのような取引によって第1ユーザが損失を被る事態を回避することができる。
【0169】
[10] また、上記の構成において、コストは、これまでに第1ゲーム媒体の成長パラメータの変更に費やされたコストであるとよい。この場合には、第1ゲーム媒体の成長に費やされたコストとの関係で第1ユーザにとって不利となる(損失を被る)事態を回避することができる。
【0170】
[11] また、本発明の情報処理装置において、第1ゲーム媒体の成長パラメータについて、受付部は、第1ゲーム媒体の成長パラメータに対して設定された譲渡範囲内での譲受の申し出を第2ユーザから受け付けてもよい。
上記の構成によれば、第1ゲーム媒体の成長パラメータについて、当該成長パラメータに対して設定された譲渡範囲内で第2ユーザが譲受を申し出ることになる。これにより、第1ゲーム媒体の成長パラメータの取引(ユーザ間での取引)が譲渡範囲内で適切になされるようになる。
【0171】
[12] また、本発明の情報処理装置において、譲渡範囲が互いに異なる複数の小範囲に分かれている場合に、受付部は、複数の小範囲のうち、譲渡範囲の上限に最も近い小範囲から順に、小範囲における成長パラメータの譲受の申し出を第2ユーザから受け付けてもよい。
上記の構成によれば、第1ゲーム媒体の成長パラメータに対して設定された譲渡範囲を複数の小範囲に分け、第2ユーザは、小範囲を単位として成長パラメータを譲受することができる。すなわち、第2ユーザは、譲渡範囲全体の成長パラメータをまとめて譲受する必要がなく、所望の範囲(小範囲)にある成長パラメータを効率よく譲受することができる。
【0172】
[13] また、本発明の情報処理装置において、譲渡範囲の下限が、第1ユーザが入手した時点での第1ゲーム媒体の成長パラメータを下回らないように、譲渡範囲が設定されてもよい。
上記の構成では、取引後の第1ゲーム媒体の成長パラメータが入手時点でのパラメータ(初期値)を下回らないようにすることができる。これにより、第1ユーザは、パラメータ取引の実施後にも第1ゲーム媒体を適切な状態(具体的には、成長パラメータが正常な範囲にある状態)で使用することができる。
【0173】
[14] また、本発明の情報処理装置において、各ユーザがゲームにて成長させるゲーム媒体の成長パラメータには、ゲームの進行に応じて変化する可変値を含み、各ユーザがゲームにてゲーム媒体を使用している間に特定の成長条件が成立した場合に、パラメータ変更部は、予め定められた確率に応じてゲーム媒体の可変値を増やしてもよい。この場合において、受付部は、第1ゲーム媒体の可変値について、第1ユーザから譲渡の申し出を受け付け、且つ、第2ユーザから譲受の申し出を受け付けると好適である。
上記の構成では、取引される成長パラメータが、予め定められた確率で増える可変値である場合、その成長パラメータは、所定の条件を満たした場合に確実に増える成長パラメータと比較して取引性が高い(パラメータ取引に対するユーザの意欲を喚起させ易い)。したがって、上記の可変値を取引対象とすることで、ユーザ間でのパラメータ取引の活性化をより一層促すことができる。
【0174】
[15] また、本発明の情報処理方法は、コンピュータが、第1ユーザがゲームにて成長させる第1ゲーム媒体の成長パラメータについて、第1ユーザから譲渡の申し出を受け付け、且つ、第2ユーザから譲受の申し出を受け付け、第1ユーザ及び第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータが、第2ユーザがゲームにて成長させる第2ゲーム媒体の成長パラメータを、第2ユーザが第1ユーザから譲受した成長パラメータに応じて変更することを特徴とする。
上記の方法によれば、ゲーム媒体の成長パラメータを対象としてユーザ間で取引を実施することができれば、新たな形態での取引が実現されるので、ユーザ間の交流が活性化され、ゲームプレイの促進を図ることができる。
【0175】
[16] また、本発明のプログラムは、コンピュータに、第1ユーザがゲームにて成長させる第1ゲーム媒体の成長パラメータについて、第1ユーザから譲渡の申し出を受け付けさせ、且つ、第2ユーザから譲受の申し出を受け付けさせ、第1ユーザ及び第2ユーザからの申し出を受け付けて所定の条件が成立した場合に、コンピュータに、第2ユーザがゲームにて成長させる第2ゲーム媒体の成長パラメータを、第2ユーザが第1ユーザから譲受した成長パラメータに応じて変更させるプログラムである。このプログラムをコンピュータに実行させることで、ユーザ間での取引として、ゲーム媒体の成長パラメータを対象とする新たな形態の取引が実現される。これにより、ユーザ間の交流が活性化され、ゲームプレイの促進を図ることができる。
【符号の説明】
【0176】
10,10X サーバ(情報処理装置、コンピュータ)
10A プロセッサ
10B メモリ
10C 通信用インタフェース
10D 出力デバイス
11,12 ユーザ端末
13 プロセッサ
14 メモリ
15 通信用インタフェース
16 入力デバイス
17 出力デバイス
21 端末側受付部
22 端末側送受信部
23 端末側記憶部
24 表示実行部
31 ゲーム進行用受付部
32 ゲーム進行部
33 サーバ側記憶部(記憶部)
34 取引用受付部(受付部)
35 コスト算出部
36 取引処理部
37 拒否部
38 条件設定部
41 状態変更部
42 経験値付与部
43 パラメータ変更部
NT 通信用ネットワーク
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12A
図12B
図13A
図13B
図14
図15A
図15B
図16A
図16B