JP5799452B1 - ゲームサーバ、ゲーム制御方法、ゲームプログラム、ゲームプログラム記録媒体及び端末装置 - Google Patents

Abstract

【課題】仮想ユーザ間でのアイテムの交換に対して、工夫した施策を打つことで、ゲームをいっそう楽しむことが可能なゲームサーバを提供する。【解決手段】インターネット２を介して接続された端末３から、仮想空間内に形成された仮想ユーザを操作する操作データを受信する操作データ受信部１１ａと、受信した操作データから得られる情報に基づいて、仮想空間で仮想ユーザが所有可能なアイテムの中から、一の仮想ユーザが入札するのに適したアイテムを推測するアイテム推測部５１１と、所定の入札条件を提示することでアイテムを落札可能なオークションに、一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する出品判断部５１２と、一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、一の仮想ユーザを操作する端末に送信する入札提案部５１３と、を備える。【選択図】図５

Description

本発明は、通信ネットワークを介して接続された各端末からの操作データによって、仮想空間に存在する仮想ユーザの動作を管理するゲームサーバ、ゲームサーバで提供するゲームの進行を制御するゲーム制御方法、ゲームプログラム、ゲームプログラム記録媒体及び端末装置に関するものである。

近年、スマートフォンに代表される高機能な携帯端末の普及に伴い、ソーシャルネットワーキングサービス（ＳＮＳ）を利用して提供されるゲームとしてソーシャルネットワークゲーム（以下、ソーシャルゲームという。）が普及している。ソーシャルゲームは、端末を操作する実ユーザが、通信ネットワークを介して、ゲームサーバによって構築された仮想空間に存在する仮想ユーザを操作することによって、同一の仮想空間に存在する他の仮想ユーザとのコミュニケーションを取りながらオンラインでプレイするゲームである。

このようなソーシャルゲームの一態様として、仮想ユーザの行動やストーリーなどに基づき、例えばクエストパート、バトルパート、強化パート、ガチャパート、などの複数のゲームパートが組み合わさって一つのシナリオが成立し、一つのゲームが構成されるものがある（例えば、特許文献１参照）。

また、ソーシャルゲームにおいては、ユーザ同士の持つアイテム等を交換する「トレード」という機能がある。一般的に、「トレード」においては、ユーザが自主的に参加し、欲しいアイテム等と、不要なアイテム等を設定し、サーバがこの組み合わせに合致する他のユーザを選出し、自動的にトレードが成立する処理が行われている。

他方、ユーザがより積極的に参加し、ゲーム内通貨や不要なアイテム等を使い、欲しいアイテム等を競り落とすことができるオークション形式でのトレードも行われている。

特開２０１２−２４２４８号公報

しかしながら、「トレード」という行為自体は、欲しいアイテム等を獲得するための一つの手段に過ぎず、多くのユーザにとってはトレードに参加する必要性を強く感じないために、トレードが活発に行われることは少なかった。

本発明は、上述した課題に鑑みてなされたものであり、仮想ユーザ間でのアイテムの交換に対して、工夫した施策を打つことで、ゲームをいっそう楽しむことが可能なゲームサーバ、ゲームサーバで提供するゲームの進行を制御するゲーム制御方法、ゲームプログラム、ゲームプログラムを記録したゲームプログラム記録媒体、ゲームシステム及び端末装置を提供することを目的とする。

上述した従来の課題を解決するため、本発明は、以下の手段を有する。

（１）本発明の第１の態様に係るゲームサーバは、通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信する操作データ受信部と、複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するアイテム推測部と、所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する出品判断部と、前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信する入札提案部と、前記入札提案データにより提案されたアイテムを、前記一の仮想ユーザが所定期間内に入札しなかった場合には、当該一の仮想ユーザに対して、当該アイテムを用いない限り進捗不可能であって当該アイテムを用いることで進捗可能になるイベントを発生させるイベント発生部と、を備えることを特徴とする。

上記態様において、操作データから得られる情報とは、例えば過去に仮想ユーザが獲得したアイテムの種類、当該種類の偏り、仮想ユーザのレベル、ゲームプレイ時間、アイテム数、仮想ユーザが敵との対戦で発揮する対戦能力値、対戦履歴（勝敗数）、仮想通貨の所有量などである。このような情報を利用して、アイテム推測部は、例えば、仮想ユーザが過去に獲得したアイテムの種類（武器、防具）などに偏りがある場合には、まだ獲得したことのない種類のアイテムを、実ユーザが欲しいと思うようなアイテム、つまり仮想ユーザが入札するのに適したアイテムと推測する。また、上記態様において、オークションとは、例えば入札額となる仮想通貨の通貨量を提示したり、他の仮想ユーザにとって不要なアイテムを入札用アイテムとして提示するなどの、所定の入札条件を提示することで、当該他の仮想ユーザが出品したアイテムを落札するアイテム交換形式をいう。

上記態様によれば、仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを端末に送信する。入札提案データを端末に送信することで、オークションの参加実績が少ないが、アイテムの獲得手段として潜在的にオークションに参加する意欲がありそうな仮想ユーザに対して、オークションへの参加を促すことができる。つまり、何ら提案しなければ欲しいアイテムが出品されていても入札することがない仮想ユーザに対して、オークションの参加を促すことができる。
さらに、上記態様によれば、例えば４８時間以内など所定期間内に一の仮想ユーザが提案されたアイテムを入札しなかった場合には、当該アイテムを一の仮想ユーザが装備しない限り倒すことができない敵を出現させるなど、当該アイテムを用いることで進捗可能になるイベントを発生させる。このようなイベントを発生させることで、単に入札提案するだけではなかなか入札に参加しないような仮想ユーザに対して、オークションの参加を強く促すことができる。

（２）本発明の第２の態様に係るゲームサーバは、通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信する操作データ受信部と、複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するアイテム推測部と、所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する出品判断部と、前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信する入札提案部と、前記入札提案データにより提案したアイテムを前記一の仮想ユーザが落札した場合に、落札したアイテムの所有権を前記一の仮想ユーザに設定する落札アイテム所有権設定部と、前記設定されたアイテムの所有権が所定期間内に消滅したか否かを判断する所有権判断部と、前記所定期間内に消滅したと判断した場合には、前記一の仮想ユーザのゲーム進行に所定の不利益条件を設定する不利益条件設定部と、をさらに備えることを特徴とする。

上記態様によれば、入札提案を受けて一の仮想ユーザが落札したアイテムを所定期間内（例えば４８時間以内）に売却やトレードなどをして、当該アイテムの所有権が消滅した場合には、単なる転売目的、言い換えればリアルマネートレードなどの不正の目的による所有権の消滅とみなして、不利益条件を設定する。具体的には、入札するのに適さないアイテムを今後提案したり、一の仮想ユーザの所有通貨量を超える額まで落札額を意図的につり上げて落札不能にしたり、そもそも入札提案をしないなど、不利益条件を設定することで、入札提案データを悪用したアイテムの入札を防止し、不正な行為がなされない健全なゲーム環境を実現することができる。
（３）本発明の第３の態様に係るゲームサーバは、上記第１又は第２の態様において、前記仮想ユーザには、前記仮想空間で進捗可能な行動が設定されており、前記入札提案部は、前記仮想ユーザに適したアイテムが前記オークションに出品され、かつ、前記行動が所定の進捗条件を満たしている場合、当該アイテムの入札を提案する提案表示データを、前記端末に送信することを特徴とする。
上記態様において、仮想空間で進捗可能な行動とは、例えば、ゲーム上に作られたダンジョン、城、森などをモチーフとしたステージを仮想ユーザが冒険することで、経験値を上げたりレベルアップしたりする行動のこと（ソーシャルゲームでは、いわゆる「任務」や、「クエスト」、「お仕事」など）をいう。また、行動が所定の進捗条件を満たしているとは、例えば特定のステージに潜む敵を倒したり、経験値又はレベルが所定値以上になったことをいう。
上記態様によれば、行動が所定の進捗条件を満たしている場合に限ってアイテムの入札を提案することにより、多数の仮想ユーザがオークションに殺到することを防ぐことができる。より具体的には、上記態様によれば、同一のアイテムを欲しいと思うような複数の仮想ユーザのうち、優先的に取得するべきと考えられるような特定の仮想ユーザのみにオークションへの参加を促すことができる。このように特定の仮想ユーザに限定してオークションへの参加を促すことで、進捗状況に見合ったアイテムを適時獲得することが可能となり、継続的にゲームへの参加を喚起することができる。

（４）以上のような本発明は、いずれの態様においても、上記ゲームサーバの発明を、そのゲームサーバで提供するゲームの進行を制御するゲーム制御方法、ゲームプログラム、ゲームプログラムを記録した記録媒体及び端末装置として捉えることも可能である。

本発明によれば、仮想ユーザ間で行われるアイテムの交換に対して、工夫した施策を打つことで、ゲームをいっそう楽しむことが可能なゲームサーバ、ゲームサーバで提供するゲームの進行を制御するゲーム制御方法、ゲームプログラム、ゲームプログラムを記録したゲームプログラム記録媒体及び端末装置を提供することができる。

本発明が適用されたゲームシステムのシステム構成を示す図である。 本発明が適用されたゲームサーバが提供するソーシャルゲームの構成について説明するための図である。 本発明が適用されたゲームサーバのハードウェア構成を示す図である。 本発明が適用されたゲームサーバが実行する各処理部の構成を示す図である。 第１の実施形態に係るトレードパート処理部の全体構成について説明するための図である。 アイテムデータテーブルの具体例について説明するための図である。 所有アイテムデータテーブルの具体例について説明するための図である。 仮想ユーザ属性データテーブルの具体例について説明するための図である。 アイテムの入札を提案するためのゲーム画面の具体例について説明するための図である。 第１の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第１の実施形態の変形例に係るトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第２の実施形態のトレードパート処理部の全体構成について説明するための図である。 第２の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第３の実施形態のトレードパート処理部の全体構成について説明するための図である。 第３の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第４の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 仲間関係にある他の仮想ユーザからの借入を提案するためのゲーム画面の具体例について説明するための図である。 第４の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第５の実施形態のトレードパート処理部の全体構成について説明するための図である。 第５の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第６の実施形態のトレードパート処理部の全体構成について説明するための図である。 第６の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第７の実施形態のトレードパート処理部の全体構成について説明するための図である。 第７の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。 第８の実施形態のトレードパート処理部の全体構成について説明するための図である。 第８の実施形態のトレードパート処理部で行われる処理の全体的なフローについて説明するための図である。

本発明を実施するための形態（以下、本実施形態という。）について具体例を示して説明する。本実施形態は、ゲームサーバと通信ネットワークを介して接続された端末にゲームを提供するゲームシステムに関する。具体的には、図１に示すように、本実施形態のゲームシステムＧは、実ユーザにゲームを提供するゲームサーバ１と、ゲームサーバ１と通信ネットワークであるインターネット２を介して接続された端末３ａ、３ｂ、３ｃ、・・・（以下、総称して端末３ともいう。）と、を備える。

以下では、まず、実施形態の説明に先立って、本実施形態において用いる用語の定義を明確にし、さらに本実施形態において扱うソーシャルゲームの概要について説明した後、ゲームシステムＧの構成及び処理内容について具体的に説明する。

（１）用語の定義
本実施形態において用いる用語の定義は以下の通りである。

「仮想空間」とは、ゲームの内容に基づいてゲーム中に形成される仮想の世界を示し、物理空間とは異なる空間を指す。端末３のディスプレイ（表示部）に表示される「仮想空間」は２次元であるが、他の端末３との繋がりも加わって形成される観念的空間は、２次元空間に限られない。

「実ユーザ」とは、端末を操作する実体、すなわち人に当たるものをいう。一方、この実体である「実ユーザ」の端末におけるボタンやタッチ操作によって、仮想空間において、ユーザに成り代わった、またはユーザの趣向や好みに応じて形成された仮想実体を「仮想ユーザ」という。この「仮想ユーザ」には、例えば、旧来の将棋ゲームや麻雀ゲームのプレイヤのように、その仮想実体はゲーム上視認できないが、「実ユーザ」に成り代わった存在として駒や牌を仮想空間内で操作する場合も含まれる。「仮想ユーザ」には、また、ロールプレイングゲームや対戦ゲームにおいてゲーム上で表示され、移動やアクションを起こす視認可能な特定のキャラクタも含まれる。さらに「仮想ユーザ」には、ＳＮＳにおけるアバターとして表示される仮想実体も含まれる。このように、本実施形態における「仮想ユーザ」は、仮想空間における仮想実体を広く表す用語として用い、それがゲーム上で具現化された仮想実体であるか、具現化されない影として機能する仮想実体であるかは問わない。

（２）ソーシャルゲームの概要
続いて、ゲームサーバ１からインターネット２を介して接続された端末３に提供されるソーシャルゲーム２０について、その概要を、図２を参照して説明する。

一般にソーシャルゲーム２０は、実ユーザによる端末３の操作に応じた動作を行う仮想ユーザを介して、仮想空間内において、例えば、数百種類など多種類のキャラクタが付された仮想的なカード（以下、単にカードという。）の中から、所定枚数からなるカードのアイテムリスト（以下、デッキともいう。）を作成するゲームである。より具体的には、デッキに搭載したカードのレベルアップやグループの選択を行いつつ、仮想空間上で出現する敵とカード同士で対戦したり、他の仮想ユーザとカードのトレードを行うなどして、カードを強化、収集していくものである。カード同士の対戦では、デッキを構成する各カードの攻撃力や防御力、所定のカードの組合せにより一定の効力を得るスキル（カードゲームや麻雀でいうところの「役」に当たる。）などに基づいて、敵に与えるダメージや勝敗が決する。

ソーシャルゲーム２０は、複数のゲームパート（以下、単に「パート」ともいう）が有機的に組み合わさることにより、一つのストーリーやキャラクタが完成し、全体として一つのゲームとして成立する。例えば、ソーシャルゲーム２０は、図２に示すように、クエストパート２１と、バトルパート２２と、ガチャパート２３と、強化パート２４と、トレードパート２５と、を備える。

クエストパート２１は、「探索、探求、冒険」などの意義を有する「クエスト」という言葉が表す通り、仮想ユーザが仮想空間を探索して、探索中に出現する敵と対戦したり、新たなカードを獲得したり、仮想ユーザのレベル向上を行うことにより、進捗するゲームを構成する一部分である。クエストパート２１では、仮想ユーザに所定のクエスト用ポイントが与えられ、仮想ユーザの移動、アイテムの獲得やレベルの向上などは、このクエスト用ポイントを消費することで行われる。また、クエストパート２１では、バトル用ポイントを消費して仮想ユーザが所有するカードを用いることで、出現した敵と対戦が行われる。

バトルパート２２は、仮想ユーザが所有するカードが組み込まれたデッキを用いて、他の仮想ユーザを敵として対戦するパートであり、上述したデッキを構成する各カードの攻撃力及び防御力に基づいて勝敗が決する。また、バトルパート２２は、一対一の仮想ユーザ同士のバトルを実現する以外に、いわゆる集団型のバトルを実現しても良い。つまり、バトルパート２２は、仲間関係にある仮想ユーザが同一の集団に所属して、当該集団に所属する個々の仮想ユーザが、自己が所有するアイテムを用いて、他の集団に所属する仮想ユーザを敵としてバトルするという、ゲーム進行を実現してもよい。

ガチャパート２３は、硬貨を自動販売機に投入してカプセルに包装されたおもちゃであるカプセルトイが出てくる様子を表した「ガチャガチャ」（登録商標）に由来するものであり、例えば、仮想ユーザが、硬貨の代わりに仮想的に与えられるガチャ用ポイントやガチャ用の権限を用いて、カードごとの出現率に基づいてランダムにカードを取得するパートである。

強化パート２４は、仮想ユーザが所有しているカードを合成してカードの強さを表すレベルを上げることで、デッキに組み込まれた時に、敵に与える攻撃力や、敵からの攻撃を防御する防御力などを強化するパートである。

トレードパート２５は、仮想ユーザ同士が所有するアイテムを交換（つまり、トレード）することを題材としたゲームパートである。トレードパート２５では、実ユーザは端末３を通した操作により、仮想ユーザが所有するアイテムを、他の仮想ユーザとトレードすることで、実ユーザが欲しいと思うようなアイテムを、仮想ユーザに取得させることができる。

以上のような複数のパートから構成されるソーシャルゲーム２０は、各パート単体が他のゲームパートから独立したものではなく、上述したように、各パートが互いに関係し合い、組み合わさることで、ゲーム全体としての意義を有するものとなっている。したがって、ソーシャルゲーム２０では、仮想ユーザが各ゲームパートを有効に進捗させることで、全体として一つのゲームを進行させることができる。

（３）基本的なハードウェア構成
（３−１）端末の構成
以上のようなソーシャルゲーム２０の定義に基づき、本実施形態のゲームシステムＧを実現するためのハードウェア構成について説明する。

図１に示すように、端末３は、例えば、無線通信部３１と、表示部３２と、操作部３３と、を備える携帯型無線通信端末により構成される。無線通信部３１は、携帯電話回線や無線ＬＡＮ回線を用いてインターネット２に接続し、ウェブブラウザ上でゲームサーバ１とデータ通信を行う。表示部３２は、ゲームサーバ１から受信したウェブブラウザの画面を表示する。操作部３３は、例えば、表示部３２の画面上の表示に従って実ユーザからの操作入力を受け付けるタッチパネルから構成される。このようにして実ユーザから受け付けられた操作入力は、無線通信部３１によりゲームサーバ１に送信される。

このようなハードウェア構成を有する端末３では、例えば、予め登録したユーザＩＤと所定のパスワードとの組合せにより、端末の個体認証処理を行う。そして、端末３は、ゲームサーバ１との間での認証が完了すると、ゲームサーバ１からゲームを進行するのに必要なデータを受信するとともに、操作部３３における操作データをゲームサーバ１に送信する。

なお、端末３は、通信ネットワークであるインターネット２を介してゲームサーバ１と通信可能な通信装置であれば、携帯電話機、ＰＤＡ、パーソナルコンピュータなどであってもよい。また、操作部３３の例としてタッチパネルを挙げたが、もちろん物理的なキー操作によってカーソルなどを移動させて選択操作を行い、情報の入力を行うような構成を採用してもよい。

（３−２）ゲームサーバの概略構成
端末３と通信可能に接続されるゲームサーバ１は、例えば図３に示すような汎用的なハードウェア構成を有するコンピュータにより実現される。すなわち、ゲームサーバ１は、図３に示すように、インターネット２を介して端末３と通信する通信インタフェース部１１と、キーボードやマウスなどのユーザからの操作入力を受ける操作入力部１２とを備える。また、ゲームサーバ１は、各種演算処理を行うＣＰＵなどの演算処理部１３と、演算処理データを一時的に記憶するＳＲＡＭやＤＲＡＭなどのメインメモリ１４と、アプリケーションプログラム及び各種データが記憶されたハードディスクなどの記憶装置１５と、演算処理結果を表示するディスプレイ１６とを備える。

（４）第１の実施形態
第１の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ａという。）は、上述したようなソーシャルゲーム２０をユーザに提供するためのプログラムを記憶装置１５にインストールすることで、図４に示すような機能ブロックが実現される。

すなわち、第１の実施形態に係るゲームサーバ１ａでは、例えば図４に示すような、操作データ受信部１１ａと、ゲームデータ処理部１００と、ゲームデータを管理するゲームデータ記憶部２００とからなる機能が実現される。

操作データ受信部１１ａは、インターネット２を通じて、端末３から送られてくる操作データを受信する手段である。ゲームデータ処理部１００は、クエストパート処理部１０１とバトルパート処理部１０２とガチャパート処理部１０３と強化パート処理部１０４と、トレードパート処理部１０５ａと、を有する。

ここで、クエストパート処理部１０１は、クエストパート２１のデータ処理を行う。また、バトルパート処理部１０２は、バトルパート２２のデータ処理を行う。ガチャパート処理部１０３は、ガチャパート２３のデータ処理を行う。強化パート処理部１０４は、強化パート２４のデータ処理を行う。トレードパート処理部１０５ａは、トレードパート２５のデータ処理を行う。

以下では、第１の実施形態で特有の構成を有するトレードパート処理部１０５ａにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図５等を参照して説明する。まず、ゲームデータ記憶部２００の構成について説明する。

（４−１）ゲームデータ記憶部の構成
ゲームデータ処理部１００で用いるデータとして、ゲームデータ記憶部２００は、図５に示すように、アイテムデータテーブル２０１と、所有アイテムデータテーブル２０２と、仮想ユーザ属性データテーブル２０３と、を有する。

（アイテムデータテーブル２０１：図６）
アイテムデータテーブル２０１は、図６に示すように、ゲーム内で使用可能なアイテムについて一覧で管理したものである。各アイテムには、固有の数字やアルファベットなどのテキストデータからなるアイテムＩＤ６１が与えられている。

また、アイテムＩＤ６１により識別可能な各アイテムには、武器や防具の名称を表したアイテム名６２が与えられている。

また、アイテムには、短刀、薙刀、鉄砲、弓などの武器の種類６３と、当該アイテムに初期設定された初期設定攻撃力６４と、当該アイテムを強化パート２４により強化可能な最大攻撃力６５とが与えられている。ここで、初期設定攻撃力６４とは、強化パート２４によりアイテムの強化を行う前の初期状態の攻撃力、すなわち予め設定されている攻撃力の固有値である。また、最大攻撃力６５は、アイテムを強化パート２４により強化可能な最大の攻撃力である。すなわち、アイテムの攻撃力は、仮想ユーザの所有アイテムとなった時は初期設定攻撃力６４であるが、その後アイテム自体の強化を繰り返すことで最大攻撃力６５まで上昇させることができる。

以上のように、アイテムデータテーブル２０１は、アイテムＩＤ６１で識別可能なアイテムごとに、アイテム名６２、種類６３、初期設定攻撃力６４、及び、最大攻撃力６５を管理している。図６では、例えばアイテムＩＤ６１が「０００１」で識別可能なアイテムについて、アイテム名６２が「○○の短刀」であり、種類６３が「短刀」であり、初期設定攻撃力６４が「１８７０」であり、最大攻撃力６５が「９８７６」であることを示している。

（所有アイテムデータテーブル２０２：図７）
所有アイテムデータテーブル２０２は、ゲームサーバ１ａが管理する個々の仮想ユーザが所有するアイテムを一覧で管理したものである。所有アイテムデータテーブル２０２は、仮想ユーザごとに、所有アイテムに設定された順番を示す所有アイテム番号７１、アイテムデータテーブル２０１で管理されるアイテムＩＤ７２（図６中のアイテムＩＤ６１に相当する。）、当該アイテムの種類７３（図６中の種類６３に相当する。）、及び当該アイテムの現在の攻撃力７４から構成される。ここで、現在の攻撃力７４は、強化前であれば初期設定攻撃力と一致し、強化後であれば強化に応じた値となる。図７では、例えば、所有アイテム番号７１が「１」を示すアイテムについて、アイテムＩＤ７２が「０３５４」であり、種類７３が「短刀」であり、現在の攻撃力７４が「４８５７」であることを示している。

（仮想ユーザ属性データテーブル２０３：図８）
仮想ユーザ属性データテーブル２０３は、ゲームサーバ１ａが管理する個々の仮想ユーザに関する情報を管理するテーブルであって、ユーザＩＤ８１、レベル８２、装備アイテム８３、攻撃力８４、及び討伐ポイント８５から構成される。

ユーザＩＤ８１は、ゲームサーバ１ａが仮想ユーザを識別するための番号である。レベル８２は、ゲーム内での仮想ユーザの進捗度を表す数値である。仮想通貨８３は、例えば敵との対戦で勝利するなど、ゲーム進行に応じて仮想ユーザが獲得可能なゲーム上で流通する「お金」である。仮想ユーザが獲得した仮想通貨８３は、当該仮想ユーザがアイテムを購入したり、オークションに出品されているアイテムを入札するのに用いられる。装備アイテム８４は、所有アイテムの中からバトルパート２２で使用するアイテムの所有番号を管理したものである。攻撃力８５は、仮想ユーザの装備アイテム８４の攻撃力の総和であって、例えば攻撃力が高いほど対戦に優位であるなどバトルパート２２のゲーム進行の優位性を示す。討伐ポイント８６は、バトルパート２２の進行結果に応じて仮想ユーザに付与されるポイントである。

図８に示す具体例では、例えばユーザＩＤ８１が「１０００１」で識別可能なユーザＩＤについて、レベル８２が「２５」であり、仮想通貨８３が「５２５８４」であり、装備アイテム８４が所有番号で「１２」、「２４」であり、攻撃力８５が「４２５４８」であり、討伐ポイント８６が「４５００」であることを示している。

（４−２）トレードパート処理部１０５ａの構成
トレードパート処理部１０５ａは、例えば最高入札額の仮想通貨を提示するなど、所定の入札条件を満たすことで落札可能なオークションを行う処理部であって、具体的には、図５に示すように、オークション進行部５０と、アイテム推測部５１１と、出品判断部５１２と、入札提案部５１３と、を有する。

オークション進行部５０は、出品受付部５０１と、入札受付部５０２と、落札処理部５０３と、を有する。

出品受付部５０１は、任意の仮想ユーザからオークションに出品するアイテムの情報、つまりユーザＩＤとユーザＩＤに紐付いた所有アイテム番号などの情報を受け付ける。

入札受付部５０２は、出品されたアイテムの中から、一の仮想ユーザが欲しいアイテムを入札する入札額、つまり仮想通貨の通貨量を受け付ける。

落札処理部５０３は、例えば入札に参加した仮想ユーザの参加数が所定数に達した場合、あるいは予め決められた入札受付締切時刻になると、入札受付した仮想ユーザの中から、例えば最高入札額で入札した仮想ユーザをアイテムの落札者に決定する。また、落札処理部５０３は、落札アイテム所有権設定部５０３ａを有し、落札アイテム所有権設定部５０３ａにより、落札者である仮想ユーザに、出品したアイテムの所有権を設定し、当該設定に応じて所有アイテムデータテーブル２０２を更新する。

アイテム推測部５１１は、操作データ受信部１１ａが過去に受信した操作データから得られる情報に基づいて、仮想ユーザが入札するのに適したアイテムを推測する。具体的に、操作データから得られる情報とは、例えば過去に仮想ユーザが獲得したアイテムの種類、当該種類の偏り、仮想ユーザのレベル、ゲームプレイ時間、アイテム数、仮想ユーザが敵との対戦で発揮する対戦能力値、対戦履歴（勝敗数）、仮想通貨の所有量などである。このような情報を利用して、アイテム推測部５１１は、例えば、一の仮想ユーザが過去に獲得したアイテムの種類（武器、防具）などに偏りがある場合には、まだ獲得したことのない種類のアイテムを、実ユーザが欲しいと思うような仮想ユーザが取得するのに適したアイテムと推測する。一例として、所有アイテムデータ２０２にアクセスして、一の仮想ユーザが「槍」に分類されるアイテムを取得していなかった場合、アイテム推測部５１１は、「槍」に分類されるアイテムを、入札するのに適したアイテムと推測する。

出品判断部５１２は、一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する。仮想ユーザが入札するのに適したアイテムが「槍」に分類されるアイテムであれば、出品判断部５１２は、出品受付部５０１により受け付けた出品中のアイテムを検索して、「槍」に分類されるアイテムが出品中であるか否かを判断する。

入札提案部５１３は、仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムを落札可能な入札を提案する入札提案データを、一の仮想ユーザを操作する端末３に送信する。具体的に、入札提案部５１３は、一の仮想ユーザを操作する端末３の実ユーザに入札を提案するべく、図９に示すような画面を表示する画面情報９００を端末３に送信する。画面情報９００で表示される画面は、図９に示すように、一の仮想ユーザ（図中の「Ａさん」）が入札するのに適したアイテム、つまり「○○の槍」のアイテムが出品されていることを通知する通知画像９０１と、当該アイテムのインデックスを表示するインデックス画像９０２と、入札額を入力する入力画像９０３と、入札額の確定操作をするアイコン９０４と、から構成される。

（４−３）ゲームサーバ１ａにおける処理
本実施形態のゲームサーバ１ａにおける処理の一例として、図１０に示すようなトレードパート処理部１０５ａの処理について説明する。

ステップＳ１００１において、出品受付部５０１は、任意の仮想ユーザを操作する端末から、オークション出品用のアイテムを受け付けて、ステップＳ１００２に進む。

ステップＳ１００２において、アイテム推測部５１１は、所有アイテムデータ２０２にアクセスして、一の仮想ユーザの所有アイテムの情報を読み出して、ステップＳ１００３に進む。

ステップＳ１００３において、アイテム推測部５１１は、所有アイテムの情報に基づいて、一の仮想ユーザが入札するに適したアイテムを推測する。具体的には、上述した通り、一の仮想ユーザが「槍」に分類されるアイテムを所有していなければ、アイテム推測部５１１は、一の仮想ユーザの入札するのに適したアイテムとして、「槍」に分類されるアイテムを推測して、ステップＳ１００４に進む。

ステップＳ１００４において、出品判断部５１２は、推測したアイテムが、ステップＳ１００１による受け付け処理によって出品されているか否かを判断する。例えば、出品判断部５１２は、「槍」に分類されるアイテムが出品されているか否かを判断する。そして、出品されている場合（Ｓ１００４：Ｙｅｓ）にはステップＳ１００５に進み、出品されていない場合（Ｓ１００４：Ｎｏ）にはステップＳ１００５に進まず、つまり一の仮想ユーザを操作する端末３の実ユーザに入札を提案することなくステップＳ１００６に進む。

ステップＳ１００５において、入札提案部５１３は、一の仮想ユーザを操作する端末３に入札を提案する入札提案データを送信する。つまり、入札提案部５１３は、一の仮想ユーザを操作する端末３に、図９の画面情報９００を送信して、ステップＳ１００６に進む。

ステップＳ１００６において、オークション進行部５０の入札受付部５０２は、一の仮想ユーザから、ステップＳ１００３により推測したアイテムの入札情報を受け付けたか否かを判断する。上記図９の例に当てはめれば、入札受付部５０２は、「○○の槍」を入札する入札額を示す入札情報を受け付けたか否かを判断する。入札情報を受け付けた場合（Ｓ１００６：Ｙｅｓ）にはステップＳ１００７に進み、入札情報を受け付けなかった場合（Ｓ１００６：Ｎｏ）にはステップＳ１００７に進むことなく、図１０に示す処理を終了する。なお、推定したアイテムが出品されていない場合（Ｓ１００４：Ｎｏ）も、端末３からアイテムを入札する操作がなされる場合がある。このため、推定したアイテムが出品されていない場合（Ｓ１００４：Ｎｏ）も本ステップにおいて、入札受付部５０２は、一の仮想ユーザから入札を受け付けたか否かを判断し、判断結果に応じてステップＳ１００７に進むか、図１０に示す処理を終了する。

ステップＳ１００７において、落札処理部５０３は、一の仮想ユーザが入札したアイテムの落札処理を行って、図１０に示す処理を終了する。具体的には、一の仮想ユーザの入札額が最高額であった場合には、当該一の仮想ユーザを落札者に決定する。一の仮想ユーザの入札額が最高額でなかった場合には、入札した他の仮想ユーザを落札者に決定する。そして、落札処理部５０３は、落札アイテム所有権設定部５０３ａにより、オークションの対象となったアイテムの所有権を、落札者の仮想ユーザに設定し、当該設定に応じて所有アイテムデータ２０２を更新する。

上記図１０に示す処理によれば、ステップＳ１００４及びＳ１００５により、仮想ユーザに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを端末に送信する。このような入札を提案することで、オークションの参加実績が少ないが、アイテムの獲得手段として潜在的にオークションに参加する意欲がありそうな仮想ユーザに対して、オークションへの参加を促すことができる。つまり、ステップＳ１００５による提案しなければ入札することがない仮想ユーザに対して、オークションの参加を促すことができる。

（変形例）
次に、変形例として、トレードパート処理部１０５ａで行われる処理内容について、図１１に示すフローチャートを参照して具体的に説明する。

ステップＳ１１０１において、出品受付部５０１は、任意の仮想ユーザを操作する端末３から、オークション出品用のアイテムを受け付けて、ステップＳ１１０２に進む。

ステップＳ１１０２において、アイテム推測部５１１は、所有アイテムデータ２０２にアクセスして、一の仮想ユーザの所有アイテムの情報を読み出して、ステップＳ１１０３に進む。

ステップＳ１１０３において、アイテム推測部５１１は、所有アイテムの情報に基づいて、一の仮想ユーザが入札するに適したアイテムを推測して、ステップＳ１１０４に進む。

ステップＳ１１０４において、出品判断部５１２は、推測したアイテムが、ステップＳ１１０１による受け付け処理によって出品されて、かつ、一の仮想ユーザのレベルが所定レベル以上であるという条件を満たしたか否かを判断する。当該条件を満たす場合（Ｓ１１０４：Ｙｅｓ）にはステップＳ１１０５に進み、当該条件を満たさない場合（Ｓ１１０４：Ｎｏ）にはステップＳ１１０５に進まず、つまり一の仮想ユーザを操作する端末３の実ユーザに入札を提案することなくステップＳ１１０６に進む。

ステップＳ１１０５において、入札提案部５１３は、一の仮想ユーザを操作する端末３に入札を提案する入札提案データを送信して、ステップＳ１１０６に進む。

ステップＳ１１０６において、オークション進行部５０の入札受付部５０２は、一の仮想ユーザから、ステップＳ１１０３により推測したアイテムの入札情報を受け付けたか否かを判断する。なお、ステップＳ１１０４の判断条件を満たしていない場合（Ｓ１１０４：Ｎｏ）も、端末３からアイテムを入札する操作がなされる場合がある。このため、ステップＳ１１０４の判断条件を満たしていない場合（Ｓ１１０４：Ｎｏ）も本ステップにおいて、入札受付部５０２は、一の仮想ユーザから入札を受け付けたか否かを判断する。入札情報を受け付けた場合（Ｓ１１０６：Ｙｅｓ）にはステップＳ１１０７に進み、入札情報を受け付けなかった場合（Ｓ１１０６：Ｎｏ）にはステップＳ１１０７に進むことなく、図１１に示す処理を終了する。

ステップＳ１１０７において、落札処理部５０３は、一の仮想ユーザが入札したアイテムに対する落札処理を行って、図１１に示す処理を終了する。

上記図１１に示した処理によれば、一の仮想ユーザのレベルが所定レベル以上である場合に限って入札を提案することにより、多数の他の仮想ユーザが殺到して入札するという事態を防ぐことができる。より具体的に、上記図１１に示した処理によれば、仮想ユーザの進捗状況に見合ったアイテムを所有していない場合に、継続的にゲームの参加を喚起するため、同一のアイテムを欲しいと思うような仮想ユーザのうち、優先的に取得するべきと考えられるような仮想ユーザのみにオークションへの参加を促すことができる。

なお、上記図１１に示す例ではレベルが所定レベル以上であるか否かを判断対象としたが、これに限定されず、仮想ユーザに対して設定された進捗可能な任務が所定の進捗条件を満たしているか否かを判断対象としてもよい。ここで、仮想空間で進捗可能な任務とは、例えば仮想ユーザがゲーム上に作られたダンジョン、城、森などをモチーフとしたステージを冒険することで、経験値を上げたりレベルアップしたりすることをいう。また、任務が所定の進捗条件を満たしているとは、例えば特定のステージに潜む敵を倒したり、経験値又はレベルが所定値以上になったことをいう。

（５）第２の実施形態
次に第２の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ｂという。）について説明する。具体的には、第２の実施形態で特有の構成を有するトレードパート処理部１０５ｂと、このトレードパート処理部１０５ｂにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図１２等を参照して説明する。まず、操作データ受信部１１ａ及びゲームデータ記憶部２００の構成については、第１の実施形態と同様なので、同様の符号を付し、その説明を省略する。

（５−１）トレードパート処理部１０５ｂの構成
トレードパート処理部１０５ｂは、第１の実施形態と同様にオークション進行部５０と、アイテム推測部５１１と、出品判断部５１２と、入札提案部５１３と、を有し、これらに加えてイベント発生部５１４を有する。ここで、トレードパート処理部１０５ｂについては、イベント発生部５１４以外の構成がトレードパート処理部１０５ａと同様なので、その構成の説明を省略する。

イベント発生部５１４は、入札提案データにより提案されたアイテムを、一の仮想ユーザが所定期間内に入札しなかった場合には、一の仮想ユーザに対して、当該アイテムを用いることで進捗可能になるイベントを発生させる。具体的には、例えば４８時間以内など所定期間内に一の仮想ユーザが提案されたアイテムを入札しなかった場合には、当該アイテムを一の仮想ユーザが装備しない限り倒すことができない敵を出現させるなど、当該アイテムを用いることで進捗可能になるイベントを発生させる。

（５−２）ゲームサーバ１ｂにおける処理
本実施形態のゲームサーバ１ｂにおける処理の一例として、図１３に示すようなトレードパート処理部１０５ｂの処理について説明する。

ステップＳ１３０１において、出品受付部５０１は、任意の仮想ユーザを操作する端末３から、オークション出品用のアイテムを受け付けて、ステップＳ１３０２に進む。

ステップＳ１３０２において、アイテム推測部５１１は、所有アイテムデータ２０２にアクセスして、一の仮想ユーザの所有アイテムの情報を読み出して、ステップＳ１３０３に進む。

ステップＳ１３０３において、アイテム推測部５１１は、所有アイテムの情報に基づいて、一の仮想ユーザが入札するに適したアイテムを推測して、ステップＳ１３０４に進む。

ステップＳ１３０４において、出品判断部５１２は、推測したアイテムが、ステップＳ１３０１による受け付け処理によって出品されているか否かを判断する。出品されていると判断した場合（Ｓ１３０４：Ｙｅｓ）にはステップＳ１３０５に進み、出品されていないと判断した場合（Ｓ１３０４：Ｎｏ）にはステップＳ１３０５に進まず、つまり一の仮想ユーザを操作する端末３の実ユーザに入札を提案することなくステップＳ１３０６に進む。

ステップＳ１３０５において、入札提案部５１３は、一の仮想ユーザを操作する端末３に入札を提案する入札提案データを送信して、ステップＳ１３０６に進む。

ステップＳ１３０６において、オークション進行部５０の入札受付部５０２は、一の仮想ユーザから、ステップＳ１３０３により推測したアイテムの入札情報を受け付けたか否かを判断する。なお、推定したアイテムが出品されていない場合（Ｓ１３０４：Ｎｏ）も、端末３からアイテムを入札する操作がなされる場合がある。このため、推定したアイテムが出品されていない場合（Ｓ１３０４：Ｎｏ）も本ステップにおいて、入札受付部５０２は、一の仮想ユーザから入札を受け付けたか否かを判断する。入札情報を受け付けた場合（Ｓ１３０６：Ｙｅｓ）にはステップＳ１３０７に進み、入札情報を受け付けなかった場合（Ｓ１３０６：Ｎｏ）にはステップＳ１３０８に進む。

ステップＳ１３０７において、落札処理部５０３は、一の仮想ユーザが入札したアイテムに対する落札処理を行って、図１３に示す処理を終了する。

ステップＳ１３０８において、イベント発生部５１４は、現在時刻が、ステップＳ１３０５により入札提案をした時から４８時間経過したか否かを判断する。４８時間経過した場合（Ｓ１３０８：Ｙｅｓ）にはステップＳ１３０９に進み、４８時間経過していない場合（Ｓ１３０８：Ｎｏ）にはステップＳ１３０９に進まずステップＳ１３０６に戻る。

ステップＳ１３０９において、イベント発生部５１４は、一の仮想ユーザに対して、所定のイベントを発生させ、ステップＳ１３０６に戻る。ここで、所定のイベントとは、ステップＳ１３０３により推測したアイテムを用いることで進捗可能になるイベントである。具体的には、一の仮想ユーザの入札するのに適したアイテム（「槍」に分類されるアイテム）がステップＳ１３０３で推測した場合には、「槍」に分類されるアイテムを装備しない限り倒せない敵を、一の仮想ユーザに対して出現させる。

上記図１３に示す処理によれば、例えば４８時間以内など所定期間内に一の仮想ユーザが提案されたアイテムを入札しなかった場合には、当該アイテムを一の仮想ユーザが装備しない限り倒すことができない敵を出現させるなど、当該アイテムを用いることで進捗可能になるイベントを発生させる。このようなイベントを発生させることで、単に入札提案するだけではなかなか入札に参加しないような仮想ユーザに対して、オークションへの参加を強く促すことができる。

（６）第３の実施形態
次に第３の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ｃという。）について説明する。具体的には、第３の実施形態で特有の構成を有するトレードパート処理部１０５ｃと、このトレードパート処理部１０５ｃにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図１４等を参照して説明する。まず、操作データ受信部１１ａ及びゲームデータ記憶部２００の構成については、第１の実施形態と同様なので、同様の符号を付し、その説明を省略する。

（６−１）トレードパート処理部１０５ｃの構成
トレードパート処理部１０５ｃは、第１の実施形態と同様にオークション進行部５０と、アイテム推測部５１１と、出品判断部５１２と、入札提案部５１３と、を有し、さらに所有権消滅判断部５１５と、不利益条件設定部５１６とを有する。ここで、トレードパート処理部１０５ｃについては、所有権消滅判断部５１５及び不利益条件設定部５１６以外の構成がトレードパート処理部１０５ａと同様なので、その構成の説明を省略する。

所有権消滅判断部５１５は、入札提案データにより提案したアイテムについて、一の仮想ユーザに設定された所有権が、所定期間内に消滅したか否かを判断する。言い換えれば、所有権消滅判断部５１５は、入札提案を受けて一の仮想ユーザが落札したアイテムを所定期間内（例えば４８時間以内）に売却やトレードなどをして、当該アイテムの所有権が消滅したか否かを判断する。

不利益条件設定部５１６は、入札提案を受けて一の仮想ユーザが落札したアイテムの所有権が、落札から所定期間内に消滅したと判断された場合に、一の仮想ユーザのゲーム進行に所定の不利益条件を設定する。具体的に、所定の不利益条件とは、入札するのに適さないアイテムを今後提案したり、一の仮想ユーザの所有通貨量を超える額まで落札額を意図的につり上げて落札不能にしたり、そもそも入札提案をしないなどの条件である。

（６−２）ゲームサーバ１ｃにおける処理
本実施形態のゲームサーバ１ｃにおける処理の一例として、図１５に示すようなトレードパート処理部１０５ｃの処理について説明する。

ステップＳ１５０１において、トレードパート処理部１０５ｃは、第１の実施形態と同様の処理、つまり、図１０に示したステップＳ１００１乃至Ｓ１００７の処理を実行して、ステップＳ１５０２に進む。

ステップＳ１５０２において、所有権消滅判断部５１５は、ステップＳ１００７による落札処理によって、入札提案したアイテムの落札者が、一の仮想ユーザであるか否かを判断する。落札者が一の仮想ユーザである場合（Ｓ１５０２：Ｙｅｓ）にはステップＳ１５０３に進み、落札者が一の仮想ユーザではない場合（Ｓ１５０２：Ｎｏ）にはステップＳ１５０３乃至Ｓ１５０５に進むことなく、図１５に示す処理を終了する。

ステップＳ１５０３において、所有権消滅判断部５１５は、入札提案したアイテムの落札時から、４８時間以内であるか否かを判断する。４８時間以内である場合（Ｓ１５０３：Ｙｅｓ）にはステップＳ１５０４に進む。一方、４８時間以内ではない場合（Ｓ１５０３：Ｎｏ）、言い換えれば、入札提案したアイテムの所有権を一の仮想ユーザが保持したまま４８時間を経過している場合には、ステップＳ１５０４乃至Ｓ１５０５に進むことなく、図１５に示す処理を終了する。

ステップＳ１５０４において、所有権消滅判断部５１５は、入札提案に応じて一の仮想ユーザが落札したアイテムを、一の仮想ユーザが売却又はトレードすることで、一の仮想ユーザに設定された当該アイテムの所有権が消滅したか否かを判断する。所有権が消滅した場合（Ｓ１５０４：Ｙｅｓ）にはステップＳ１５０５に進み、所有権が消滅していない場合（Ｓ１５０４：Ｎｏ）にはステップＳ１５０５に進むことなくステップＳ１５０３に戻る。

ステップＳ１５０５において、不利益条件設定部５１６は、一の仮想ユーザが、単なる転売目的、言い換えればリアルマネートレードなどの不正の目的によって、アイテムを売約又はトレードして、当該アイテムの所有権が消滅したとみなして、不利益条件を設定する。具体的に、不利益条件設定部５１６は、不利益条件として、入札するのに適さないアイテムを今後提案したり、一の仮想ユーザの所有通貨量を超える額まで落札額を意図的につり上げて落札不能にしたり、そもそも入札提案をしないなど、不利益条件を設定して、ステップＳ１５０３に戻る。

上記図１５に示す処理によれば、入札提案を受けて一の仮想ユーザが落札したアイテムを所定期間内（例えば４８時間以内）に売却やトレードなどをして、当該アイテムの所有権が消滅した場合には、単なる転売目的、言い換えればリアルマネートレードなどの不正の目的による所有権の消滅とみなして、不利益条件を設定する。具体的には、入札するのに適さないアイテムを今後提案したり、一の仮想ユーザの所有通貨量を超える額まで落札額を意図的につり上げて落札不能にしたり、そもそも入札提案をしないなど、不利益条件を設定することで、入札提案データを悪用したアイテムの入札を防止し、不正な行為がなされない健全なゲーム環境を実現することができる。

（７）第４の実施形態
次に、第４の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ｄという。）について説明する。具体的には、第４の実施形態で特有の構成を有するトレードパート処理部１０５ｄと、このトレードパート処理部１０５ｄにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図１６等を参照して説明する。まず、操作データ受信部１１ａ及びゲームデータ記憶部２００の構成については、第１の実施形態と同様なので、同様の符号を付し、その説明を省略する。

（７−１）トレードパート処理部１０５ｄの構成
トレードパート処理部１０５ｄは、オークション進行部５０と、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３と、を有する。ここで、オークション進行部５０については、上述した第１の実施形態と同様の構成を有するので、その説明を省略する。

獲得希望アイテム受付部５２１は、出品受付部５０１で受け付けた出品中のアイテムから、操作データに応じて、一の仮想ユーザが獲得を希望する獲得希望アイテムを受け付ける。本実施形態において以下の説明では、「○○の弓」を獲得希望アイテムとして説明する。

通貨量推測部５２２は、一の仮想ユーザが、獲得希望アイテム（「○○の弓」）を落札可能な仮想通貨を所有しているか否かを推測する。具体的には、過去に出品された「○○の弓」の平均落札額と、一の仮想ユーザの仮想通貨の所有量とを比較して、一の仮想ユーザ仮想通貨の所有量が上回っている場合には、アイテム名「○○の弓」のアイテムを落札可能な仮想通貨を所有していると推測する。

借入提案部５２３は、獲得希望アイテムを落札可能な仮想通貨を所有していないと推測された場合、一の仮想ユーザと仲間関係にある他の仮想ユーザから仮想通貨の借入を提案する借入提案データを、端末３に送信する。具体的に、借入提案部５２３は、一の仮想ユーザを操作する端末３の実ユーザに対して、仮想ユーザと仲間関係にある他の仮想ユーザから仮想通貨の借入を提案するべく、図１７に示すような画面を表示する画面情報１７００を端末３に送信する。画面情報１７００で表示される画面は、図１７に示すように、入札対象となったアイテム「○○の弓」の平均落札額を通知する通知画像１７０１と、当該アイテムのインデックスを表示するインデックス画像１７０２と、一の仮想ユーザと仲間関係にある他の仮想ユーザ（仲間Ｄ）から仮想通貨の借入して入札の操作を行うアイコン１７０３と、借り入れせずに入札の操作を行うアイコン１７０４と、から構成される。

（７−２）ゲームサーバ１ｄにおける処理
本実施形態のゲームサーバ１ｄにおける処理の一例として、図１８に示すようなトレードパート処理部１０５ｄの処理について説明する。

ステップＳ１８０１において、出品受付部５０１は、任意の仮想ユーザを操作する端末３から、オークション出品用のアイテムを受け付けて、ステップＳ１８０２に進む。

ステップＳ１８０２において、獲得希望アイテム受付部５２１は、一の仮想ユーザを操作する端末３から、当該端末３の実ユーザが獲得を希望する獲得希望アイテム（例えば「○○の弓」）を受け付けたか否かを判断する。獲得希望アイテムを受け付けた場合（Ｓ１８０２：Ｙｅｓ）にはステップＳ１８０３に進み、獲得希望アイテムを受け付けていない場合（Ｓ１８０２：Ｎｏ）にはステップＳ１８０２を繰り返し行う。

ステップＳ１８０３において、通貨量推測部５２２は、一の仮想ユーザが獲得希望アイテムを落札可能な通貨量を所有しているか否かを推測する。例えば、獲得希望アイテムである「○○の弓」の過去の平均落札額が「１３４５３」であれば次のように推測する。つまり、通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、「１３４５３」以上であれば落札可能な通貨量を所有していると推測して（Ｓ１８０３：Ｙｅｓ）ステップＳ１８０４乃至ステップＳ１８０６に進まずにステップＳ１８０７に進む。一方、通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、「１３４５３」未満であれば落札可能な通貨量を所有していないと推測して（Ｓ１８０３：Ｎｏ）ステップＳ１８０４に進む。

ステップＳ１８０４において、借入提案部５２３は、一の仮想ユーザを操作する端末３に、他の仮想ユーザ（仲間Ｄ）への仮想通貨の借入を提案する借入提案データを送信する。つまり、借入提案部５２３は、一の仮想ユーザを操作する端末３に、図１７の画面情報１７００を送信して、ステップＳ１８０５に進む。

ステップＳ１８０５において、借入提案部５２３は、一の仮想ユーザを操作する端末３から仮想通貨の借入要求を受け付けたか否かを判断する。具体的には、図１７の画面情報１７００で示されるアイコン１７０３が実ユーザによってタップ操作されると、借入要求を受け付けたと判断して（Ｓ１８０５：Ｙｅｓ）ステップＳ１８０６に進む。一方、図１７の画面情報１７００で示されるアイコン１７０４が実ユーザによってタップ操作されると、借入要求を受け付けなかったと判断して（Ｓ１８０５：Ｎｏ）ステップＳ１８０７に進む。

ステップＳ１８０６において、借入提案部５２３は、仲間関係にある他の仮想ユーザからの借入に応じて、一の仮想ユーザの仮想通貨の所有量を更新する。例えば、更新前の一の仮想ユーザの仮想通貨の所有量が「１２９５４」、他の仮想ユーザからの借入額が「１０００」であれば、借入提案部５２３は、一の仮想ユーザの仮想通貨の所有量を「１３９５４」に更新して、ステップＳ１８０７に進む。

ステップＳ１８０７において、オークション進行部５０は、「○○の弓」のオークションを進行して、図１８に示す処理を終了する。具体的には、オークション進行部５０は、入札受付部５０２により一の仮想ユーザから入札額を受け付け、落札処理部５０３により落札処理を実行して、図１８に示す処理を終了する。

上記図１８に示す処理によれば、一の仮想ユーザがアイテムを落札可能な仮想通貨を所有していない場合には、積極的に入札したとしても落札ができないという事態が生じるため、一の仮想ユーザがオークションに参加する意欲が低いものとして、他の仮想ユーザから仮想通貨の借入を提案する。このような借入の提案を行うことにより、アイテムを落札ができないことによってオークションへの参加意欲が減退することを防ぐことができる。

（８）第５の実施形態
次に、第５の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ｅという。）について説明する。具体的には、第５の実施形態で特有の構成を有するトレードパート処理部１０５ｅと、このトレードパート処理部１０５ｅにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図１９等を参照して説明する。まず、操作データ受信部１１ａ及びゲームデータ記憶部２００の構成については、第１の実施形態と同様なので、同様の符号を付し、その説明を省略する。

（８−１）トレードパート処理部１０５ｅの構成
トレードパート処理部１０５ｅは、オークション進行部５０と、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３と、親交度算出部５２４と、を有する。ここで、オークション進行部５０については、上述した第１の実施形態と同様の構成を有するので、その説明を省略する。また、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３とについては、上述した第４の実施形態と同様なので、その説明を省略する。

親交度算出部５２４は、一の仮想ユーザの操作履歴に基づいて、仲間関係にある他の仮想ユーザとの親交度を算出する。具体的には、親交度算出部５２４は、例えば過去一週間のメッセージ交換回数に基づいて、一の仮想ユーザから見た他の仮想ユーザとの親しさを数値化した値を、親交度として算出する。

（８−２）ゲームサーバ１ｅにおける処理
本実施形態のゲームサーバ１ｅにおける処理の一例として、図２０に示すようなトレードパート処理部１０５ｅの処理について説明する。

ステップＳ２００１において、出品受付部５０１は、任意の仮想ユーザを操作する端末３から、オークション出品用のアイテムを受け付けて、ステップＳ２００２に進む。

ステップＳ２００２において、獲得希望アイテム受付部５２１は、一の仮想ユーザを操作する端末３から、当該端末３の実ユーザが獲得を希望する獲得希望アイテム（例えば「○○の弓」）を受け付けたか否かを判断する。獲得希望アイテムを受け付けた場合（Ｓ２００２：Ｙｅｓ）にはステップＳ２００３に進み、獲得希望アイテムを受け付けていない場合（Ｓ２００２：Ｎｏ）にはステップＳ２００２を繰り返し行う。

ステップＳ２００３において、通貨量推測部５２２は、一の仮想ユーザが獲得希望アイテムを落札可能な通貨量を所有しているか否かを推測する。通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、獲得希望アイテムを落札可能な通貨量を所有していると推測した場合（Ｓ２００３：Ｙｅｓ）ステップＳ２００４乃至ステップＳ２００８に進まずにステップＳ２００９に進む。一方、通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、獲得希望アイテムを落札可能な通貨量を所有していないと推測した場合（Ｓ２００３：Ｎｏ）ステップＳ２００４に進む。

ステップＳ２００４において、親交度算出部５２４は、一の仮想ユーザとその仲間仮想ユーザ（仲間Ｄ）との過去一週間のメッセージ交換回数に基づいて、一の仮想ユーザと仲間Ｄとの親しさを数値化した親交度を算出して、ステップＳ２００５に進む。例えば、メッセージ交換回数が「１０回」、「１５回」、「１８回」であった場合には、親交度として算出される値は、それぞれ「１０」、「１５」、「１８」となる。

ステップＳ２００５において、借入提案部５２３は、ステップＳ２００４で算出した進行度に応じて、一の仮想ユーザが仲間仮想ユーザ（仲間Ｄ）から借り入れ可能な通貨量を設定して、ステップＳ２００６に進む。例えば、一の仮想ユーザと仲間Ｄとの親交度が「１０」、「１５」、「１８」であった場合、借り入れ可能な通貨量として設定される額は、それぞれ「１０００」、「１５００」、「１８００」となる。

ステップＳ２００６において、借入提案部５２３は、一の仮想ユーザを操作する端末３に、他の仮想ユーザ（仲間Ｄ）への仮想通貨の借入を提案する借入提案データを送信して、ステップＳ２００７に進む。

ステップＳ２００７において、借入提案部５２３は、一の仮想ユーザを操作する端末３から仮想通貨の借入要求を受け付けたか否かを判断する。借入要求を受け付けた場合（Ｓ２００７：Ｙｅｓ）にはステップＳ２００８に進む。一方、借入要求を受け付けなかった場合（Ｓ２００７：Ｎｏ）にはステップＳ２００８に進まずにステップＳ２００９に進む。

ステップＳ２００８において、借入提案部５２３は、仲間関係にある他の仮想ユーザからの借入に応じて、一の仮想ユーザの仮想通貨の所有量を更新して、ステップＳ２００９に進む。

ステップＳ２００９において、オークション進行部５０は、獲得希望アイテムに関するオークションを進行して、図２０に示す処理を終了する。具体的には、オークション進行部５０は、入札受付部５０２により一の仮想ユーザから入札額を受け付け、落札処理部５０３により落札処理を実行して、図２０に示す処理を終了する。

上記図２０に示す処理によれば、親交度が高いほど仲間仮想ユーザからの借入額が増加するなど、親交度に応じて借り入れ可能な仮想通貨の通貨量を設定する。このような設定を行い、仲間仮想ユーザと親密な一の仮想ユーザにインセンティブを与えることで、一の仮想ユーザと仲間仮想ユーザとの間での交流を促進することができる。

（９）第６の実施形態
次に、第６の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ｆという。）について説明する。具体的には、第５の実施形態で特有の構成を有するバトルパート処理部１０２と、トレードパート処理部１０５ｆと、バトルパート処理部１０２及びトレードパート処理部１０５ｆにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図２１等を参照して説明する。まず、操作データ受信部１１ａ及びゲームデータ記憶部２００の構成については、第１の実施形態と同様なので、同様の符号を付し、その説明を省略する。

（９−１）バトルパート処理部１０２について
本実施形態において、バトルパート処理部１０２は、仮想ユーザが同一の集団で行動することにより集団行動を実現する集団行動実現部の一態様である。具体的に、バトルパート処理部１０２は、仲間関係にある仮想ユーザが同一の集団に所属して、当該集団に所属する個々の仮想ユーザが、自己が所有するアイテムを用いて、他の集団に所属する仮想ユーザを敵としてバトルするという、ゲーム進行を実現する。

（９−２）トレードパート処理部１０５ｆの構成
トレードパート処理部１０５ｆは、オークション進行部５０と、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３と、貢献度算出部５２５と、を有する。ここで、オークション進行部５０については、上述した第１の実施形態と同様の構成を有するので、その説明を省略する。また、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３とについては、上述した第４の実施形態と同様なので、その説明を省略する。

貢献度算出部５２５は、一の仮想ユーザの過去の集団行動に基づいて、一の仮想ユーザが所属する集団に対する貢献度を算出する。具体的に、貢献度算出部５２５は、集団同士で行われる対戦において、一の仮想ユーザが参加した参加回数や攻撃回数等に基づいて集団での貢献度合いを数値化し、貢献度として算出する。

（９−３）ゲームサーバ１ｆにおける処理
本実施形態のゲームサーバ１ｆにおける処理の一例として、図２２に示すようなトレードパート処理部１０５ｆの処理について説明する。

ステップＳ２２０１において、出品受付部５０１は、任意の仮想ユーザを操作する端末３から、オークション出品用のアイテムを受け付けて、ステップＳ２２０２に進む。

ステップＳ２２０２において、獲得希望アイテム受付部５２１は、一の仮想ユーザを操作する端末３から、当該端末３の実ユーザが獲得を希望する獲得希望アイテム（例えば「○○の弓」）を受け付けたか否かを判断する。獲得希望アイテムを受け付けた場合（Ｓ２２０２：Ｙｅｓ）にはステップＳ２２０３に進み、獲得希望アイテムを受け付けていない場合（Ｓ２２０２：Ｎｏ）にはステップＳ２２０２を繰り返し行う。

ステップＳ２２０３において、通貨量推測部５２２は、一の仮想ユーザが獲得希望アイテムを落札可能な通貨量を所有しているか否かを推測する。通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、獲得希望アイテムを落札可能な通貨量を所有していると推測した場合（Ｓ２２０３：Ｙｅｓ）にはステップＳ２２０４乃至ステップＳ２２０８に進まずにステップＳ２２０９に進む。一方、通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、獲得希望アイテムを落札可能な通貨量を所有していないと推測した場合（Ｓ２２０３：Ｎｏ）にはステップＳ２２０４に進む。

ステップＳ２２０４において、貢献度算出部５２４は、過去一週間において一の仮想ユーザが集団同士のバトルに参加した回数に基づいて、一の仮想ユーザが所属する集団に貢献した貢献度を算出して、ステップＳ２２０５に進む。例えば、バトルに参加した回数が「２回」、「４回」、「６回」であった場合には、貢献度として算出される値は、それぞれ「２」、「４」、「６」となる。

ステップＳ２２０５において、借入提案部５２３は、ステップＳ２２０４で算出した進行度が所定値（例えば４）以上であるか否かを判断して、所定値以上であれば（Ｓ２２０５：Ｙｅｓ）ステップＳ２２０６に進み、所定値未満であれば（Ｓ２２０５：Ｎｏ）ステップＳ２２０６乃至Ｓ２００８に進まずにステップＳ２２０９に進む。

ステップＳ２２０６において、借入提案部５２３は、一の仮想ユーザを操作する端末３に、その所属する集団に属する他の仮想ユーザへの仮想通貨の借入を提案する借入提案データを送信して、ステップＳ２２０７に進む。

ステップＳ２２０７において、借入提案部５２３は、一の仮想ユーザを操作する端末３から仮想通貨の借入要求を受け付けたか否かを判断する。借入要求を受け付けた場合（Ｓ２２０７：Ｙｅｓ）にはステップＳ２２０８に進む。一方、借入要求を受け付けなかった場合（Ｓ２２０７：Ｎｏ）にはステップＳ２２０８に進まずにステップＳ２２０９に進む。

ステップＳ２２０８において、借入提案部５２３は、同一の集団に所属して仲間関係にある他の仮想ユーザからの借入に応じて、一の仮想ユーザの仮想通貨の所有量を更新して、ステップＳ２２０９に進む。

ステップＳ２２０９において、オークション進行部５０は、獲得希望アイテムに関するオークションを進行して、図２２に示す処理を終了する。具体的には、オークション進行部５０は、入札受付部５０２により一の仮想ユーザから入札額を受け付け、落札処理部５０３により落札処理を実行して、図２２に示す処理を終了する。

上記図２２に示す処理によれば、例えば、一定以上対戦に参加して敵集団と戦っているなど、貢献度が所定値以上の場合のみ、一の仮想ユーザと同一の集団に所属する他の仮想ユーザから仮想通貨の借入を提案する。このようにして仮想通貨の借り入れ条件を制限することで、例えば仮想通貨を借りるだけに集団に所属するような悪意の仮想ユーザの存在を無意味化して、不正な行為がなされない健全なゲーム環境を実現することができる。

（１０）第７の実施形態
次に、第７の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ｇという。）について説明する。具体的には、第７の実施形態で特有の構成を有するトレードパート処理部１０５ｇと、このトレードパート処理部１０５ｇにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図２３等を参照して説明する。まず、操作データ受信部１１ａ及びゲームデータ記憶部２００の構成については、第１の実施形態と同様なので、同様の符号を付し、その説明を省略する。

（１０−１）トレードパート処理部１０５ｇの構成
トレードパート処理部１０５ｇは、オークション進行部５０と、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３と、適合判断部５２６と、を有する。ここで、オークション進行部５０については、上述した第１の実施形態と同様の構成を有するので、その説明を省略する。また、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３とについては、上述した第４の実施形態と同様なので、その説明を省略する。

適合判断部５２６は、一の仮想ユーザの操作履歴に基づいて、獲得希望アイテムが一の仮想ユーザの所有アイテムに適しているかを判断する。具体的には、適合判断部５２６は、例えば、獲得希望したアイテムである武器が、その時点の一の仮想ユーザの経験値やレベルに見合ってたり、一の仮想ユーザが所有している武器と比べて攻撃力が非常に高かったりする場合には、一の仮想ユーザの所有アイテムに適していないと判断する。

（１０−２）ゲームサーバ１ｇにおける処理
本実施形態のゲームサーバ１ｇにおける処理の一例として、図２４に示すようなトレードパート処理部１０５ｇの処理について説明する。

ステップＳ２４０１において、出品受付部５０１は、任意の仮想ユーザを操作する端末３から、オークション出品用のアイテムを受け付けて、ステップＳ２４０２に進む。

ステップＳ２４０２において、獲得希望アイテム受付部５２１は、一の仮想ユーザを操作する端末３から、当該端末３の実ユーザが獲得を希望する獲得希望アイテム（例えば「○○の弓」）を受け付けたか否かを判断する。獲得希望アイテムを受け付けた場合（Ｓ２４０２：Ｙｅｓ）にはステップＳ２４０３に進み、獲得希望アイテムを受け付けていない場合（Ｓ２４０２：Ｎｏ）にはステップＳ２４０２を繰り返し行う。

ステップＳ２４０３において、通貨量推測部５２２は、一の仮想ユーザが獲得希望アイテムを落札可能な通貨量を所有しているか否かを推測する。通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、獲得希望アイテムを落札可能な通貨量を所有していると推測した場合（Ｓ２４０３：Ｙｅｓ）ステップＳ２２０４乃至ステップＳ２００７に進まずにステップＳ２４０８に進む。一方、通貨量推測部５２２は、一の仮想ユーザが所有する仮想通貨の所有通貨量が、獲得希望アイテムを落札可能な通貨量を所有していないと推測した場合（Ｓ２４０３：Ｎｏ）ステップＳ２４０４に進む。

ステップＳ２４０４において、適合判断部５２６は、一の仮想ユーザが所有するアイテムの中から最も最大攻撃力が高いアイテムを抽出し、抽出したアイテムと獲得希望アイテムとを最大攻撃力で比較し、当該比較結果に基づいて、獲得希望アイテムが一の仮想ユーザに適合しているか否かを判断する。具体例として、抽出したアイテムの最大攻撃力が「７５００」で、獲得希望アイテムの最大攻撃力が「１００００」であった場合、格差が「５０００」未満であるため、獲得希望アイテムが一の仮想ユーザに適合していると判断する。一方、抽出したアイテムの最大攻撃力が「７５００」で、獲得希望アイテムの最大攻撃力が「２００００」であった場合、格差が「５０００」以上であるため、獲得希望アイテムが一の仮想ユーザに適合していないと判断する。

当該ステップにおいて、適合していると判断した場合（Ｓ２４０４：Ｙｅｓ）にはステップＳ２４０５に進み、適合していないと判断した場合（Ｓ２４０４：Ｎｏ）にはステップＳ２４０５乃至Ｓ２４０７に進まずステップＳ２４０８に進む。

ステップＳ２４０５において、借入提案部５２３は、一の仮想ユーザを操作する端末３に、他の仮想ユーザ（仲間Ｄ）への仮想通貨の借入を提案する借入提案データを送信して、ステップＳ２４０６に進む。

ステップＳ２４０６において、借入提案部５２３は、一の仮想ユーザを操作する端末３から仮想通貨の借入要求を受け付けたか否かを判断する。借入要求を受け付けた場合（Ｓ２４０６：Ｙｅｓ）にはステップＳ２４０７に進む。一方、借入要求を受け付けなかった場合（Ｓ２４０６：Ｎｏ）にはステップＳ２４０７に進まずステップＳ２４０８に進む。

ステップＳ２４０７において、借入提案部５２３は、仲間関係にある他の仮想ユーザからの借入に応じて、一の仮想ユーザの仮想通貨の所有量を更新して、ステップＳ２４０８に進む。

ステップＳ２４０８において、オークション進行部５０は、獲得希望アイテムに関するオークションを進行して、図２４に示す処理を終了する。具体的には、オークション進行部５０は、入札受付部５０２により一の仮想ユーザから入札額を受け付け、落札処理部５０３により落札処理を実行して、図２４に示す処理を終了する。

上記図２４に示す処理によれば、適合判断部５２６は、上述したように、獲得希望したアイテムが、一の仮想ユーザが所有している最も強いアイテムと比べて最大攻撃力が「５０００」以上など、所有アイテムに対して相対的に獲得希望アイテムが非常にゲーム進行上有利な場合には、一の仮想ユーザの所有アイテムに適していないと判断する。このような判断を行って、獲得希望アイテムが一の仮想ユーザの所有アイテムに適している場合に限って借入提案を行う。これにより、仮想通貨の借り入れに所定の制限を設けることで、著しくゲームバランスが崩れる事態を防止する、つまり、仮想ユーザの能力値が変化する（攻撃力が高くなる）ことを防止することができる。

（１１）第８の実施形態
次に、第８の実施形態に係るゲームサーバ１（以下、他の実施形態と区別するためゲームサーバ１ｈという。）について説明する。具体的には、第８の実施形態で特有の構成を有するトレードパート処理部１０５ｈと、このトレードパート処理部１０５ｈにおける処理を実現するための記憶領域となるゲームデータ記憶部２００の具体的な構成について図２５等を参照して説明する。まず、操作データ受信部１１ａ及びゲームデータ記憶部２００の構成については、第１の実施形態と同様なので、同様の符号を付し、その説明を省略する。

（１１−１）トレードパート処理部１０５ｈの構成
トレードパート処理部１０５ｈは、オークション進行部５０と、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３と、行動制限部５２７と、を有する。ここで、オークション進行部５０については、上述した第１の実施形態と同様の構成を有するので、その説明を省略する。また、獲得希望アイテム受付部５２１と、通貨量推測部５２２と、借入提案部５２３とについては、上述した第４の実施形態と同様なので、その説明を省略する。

行動制限部５２７は、借入提案データに応じて一の仮想ユーザが借り入れた場合に、借り入れた仮想通貨を他の仮想ユーザに返済した残額に応じて、一の仮想ユーザが進行可能な行動を制限する。具体的には、行動制限部５２７は、借入提案に従ってアイテムを落札した後、借り入れた仮想通貨を返済するまでは、一の仮想ユーザが所属する集団を離脱できずに当該集団に拘束されるなど、一の仮想ユーザの行動を制限する。なお、完済した場合に限らず、借入額の３／４を返済した場合に集団を離脱可能にしてもよい。

（１１−２）ゲームサーバ１ｈにおける処理
本実施形態のゲームサーバ１ｈにおける処理の一例として、図２６に示すようなトレードパート処理部１０５ｈの処理について説明する。

ステップＳ２６０１において、トレードパート処理部１０５ｈは、第１の実施形態と同様の処理、つまり、図１８に示したステップＳ１８０１乃至Ｓ１８０７の処理を実行して、ステップＳ２６０２に進む。

ステップＳ２６０２において、行動制限部５２７は、ステップＳ１８０７による落札処理によって、入札提案したアイテムの落札者が、一の仮想ユーザであるか否かを判断する。一の仮想ユーザである場合（Ｓ２６０２：Ｙｅｓ）にはステップＳ２６０３に進み、一の仮想ユーザである場合（Ｓ２６０２：Ｎｏ）にはステップＳ２６０３乃至Ｓ２６０４に進むことなく、ステップＳ２６０５に進む。

ステップＳ２６０３において、行動制限部５２７は、一の仮想ユーザが借り入れた仮想通貨を完済したか否かを判断し、完済した場合（Ｓ２６０３：Ｙｅｓ）にはステップＳ２６０５に進み、完済していない場合（Ｓ２６０５：Ｎｏ）にはステップＳ２６０４に進む。

ステップＳ２６０４において、行動制限部５２７は、一の仮想ユーザに対して現在の所属集団からの脱退を不可能にして、ステップＳ２６０３に戻る。

ステップＳ２６０５において、行動制限部５２７は、一の仮想ユーザに対して現在の所属集団からの脱退を可能にして、図２６に示す処理を終了する。

上記図２６に示す処理によれば、例えば、借り入れた仮想通貨を返済するまでは、一の仮想ユーザが所属する集団を離脱できずに当該集団に拘束されるなど、一の仮想ユーザの行動を制限することで、仮想通貨の返済を促すことができ、例えば仮想通貨をなかなか返さないなどの不正な行為がなされない健全なゲーム環境を実現することができる。

（１２）その他
本発明は、上記の実施形態に限定されず、第１乃至第３の実施形態を組み合わせたり、第４乃至第８の実施形態を組み合わせることが可能である。また、本発明は、上述したゲームサーバ１で行われるトレードパート処理部の機能を、端末装置（端末３）側で行うようにしてもよい。具体的には、端末装置は、ゲームサーバとゲーム進行に関するデータを送受信して、トレードパート処理部１０５ａ乃至１０５ｈのいずれか一の機能を実現してもよい。また、本発明は、上記の実施形態の機能を実現するソフトウェアのプログラムが記録された非一時的な記録媒体をシステム又は装置に提供し、当該システム又は装置のコンピュータ、すなわちＣＰＵ又はＭＰＵに、当該非一時的な記録媒体に記録されたプログラムを読み出して実行させることによって実現してもよい。

この場合、当該非一時的な記録媒体から読み出されたプログラムは、上述の実施形態の機能を実現する。したがって、当該プログラム及び当該プログラムが記録された非一時的な記録媒体も、本発明の一態様である。

当該プログラムを提供する非一時的な記録媒体は、例えばフレキシブルディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷなどの光ディスク、磁気テープ、不揮発性メモリカード、及びＲＯＭを含む。或いは、当該プログラムは、通信ネットワークであるインターネットを介してダウンロード可能であってもよい。

さらに、上記の実施形態の機能は、コンピュータが当該プログラムを読み出して実行するだけではなく、コンピュータ上で動作するＯＳ（operating system）等に、当該プログラムの指示に基づき実際の操作の一部又はすべてを実行させることによって実現してもよい。

さらに、上記の実施形態の機能は、非一時的な記録媒体から読み出されたプログラムを、コンピュータに挿入された拡張ボードに設けられたメモリ、又は、コンピュータに接続された拡張装置に設けられたメモリに書き込み、拡張ボード又は拡張装置に設けられたＣＰＵ等に、プログラムの指示に基づき実際の処理のすべて又は一部を実行させることによって実現されてもよい。

典型的な実施形態を参照して本発明を説明したが、本発明は、ここに開示する典型的な態様に限定されないことはもちろんである。特許請求の範囲は、このような変更と、同等の構造及び機能とをすべてを含むように最も広く解釈することが可能である。

Ｇ ゲームシステム
１、１ａ、１ｂ、１ｃ、１ｄ、１ｅ、１ｆ、１ｇ、１ｈ ゲームサーバ
１１ａ 操作データ受信部
５０１ 出品受付部
５０２ 入札受付部
５０３ 落札処理部
５１１ アイテム推測部
５１２ 出品判断部
５１３ 入札提案部
５２１ 獲得希望アイテム受付部
５２２ 通貨量推測部
５２３ 借入提案部
２ インターネット
３、３ａ、３ｂ、３ｃ 端末

Claims (11)

1. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信する操作データ受信部と、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するアイテム推測部と、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する出品判断部と、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信する入札提案部と、
   前記入札提案データにより提案されたアイテムを、前記一の仮想ユーザが所定期間内に入札しなかった場合には、当該一の仮想ユーザに対して、当該アイテムを用いない限り進捗不可能であって当該アイテムを用いることで進捗可能になるイベントを発生させるイベント発生部と、を備えることを特徴とするゲームサーバ。
2. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信する操作データ受信部と、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するアイテム推測部と、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する出品判断部と、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信する入札提案部と、
   前記入札提案データにより提案したアイテムを前記一の仮想ユーザが落札した場合に、落札したアイテムの所有権を前記一の仮想ユーザに設定する落札アイテム所有権設定部と、
   前記落札したアイテムを仮想通貨又は他のアイテムに交換するための操作データの受信の有無に基づいて、当該アイテムの所有権が前記一の仮想ユーザから所定期間内に消滅したか否かを判断する所有権消滅判断部と、
   前記所定期間内に消滅したと判断した場合には、前記入札提案データに代えて前記一の仮想ユーザが入札するに適したアイテム以外のアイテムの入札を提案するデータを前記一の仮想ユーザを操作する端末に送信する第１不利益条件、前記オークションで前記一の仮想ユーザの所有通貨量を超える額まで落札額をつり上げて落札不能にする第２不利益条件条件、前記一の仮想ユーザを操作する端末に前記入札提案データを送信しない第３不利益条件のうち、少なくとも一つの不利益条件を設定する不利益条件設定部と、を備えることを特徴とするゲームサーバ。
3. 前記仮想ユーザには、前記仮想空間で進捗可能な行動が設定されており、
   前記入札提案部は、前記仮想ユーザが入札するのに適したアイテムが前記オークションに出品され、かつ、前記行動が所定の進捗条件を満たしている場合、当該アイテムの入札を提案する入札提案データを、前記端末に送信することを特徴とする請求項１又は２記載のゲームサーバ。
4. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信するステップと、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するステップと、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断するステップと、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信するステップと、
   前記入札提案データにより提案されたアイテムを、前記一の仮想ユーザが所定期間内に入札しなかった場合には、当該一の仮想ユーザに対して、当該アイテムを用いない限り進捗不可能であって当該アイテムを用いることで進捗可能になるイベントを発生させるステップと、を通信ネットワークに接続されたコンピュータが実行するゲーム制御方法。
5. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信するステップと、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するステップと、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断するステップと、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信するステップと、
   前記入札提案データにより提案したアイテムを前記一の仮想ユーザが落札した場合に、落札したアイテムの所有権を前記一の仮想ユーザに設定するステップと、
   前記落札したアイテムを仮想通貨又は他のアイテムに交換するための操作データの受信の有無に基づいて、当該アイテムの所有権が前記一の仮想ユーザから所定期間内に消滅したか否かを判断するステップと、
   前記所定期間内に消滅したと判断した場合には、前記入札提案データに代えて前記一の仮想ユーザが入札するに適したアイテム以外のアイテムの入札を提案するデータを前記一の仮想ユーザを操作する端末に送信する第１不利益条件、前記オークションで前記一の仮想ユーザの所有通貨量を超える額まで落札額をつり上げて落札不能にする第２不利益条件条件、前記一の仮想ユーザを操作する端末に前記入札提案データを送信しない第３不利益条件のうち、少なくとも一つの不利益条件を設定するステップと、を通信ネットワークに接続されたコンピュータが実行するゲーム制御方法。
6. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信するステップと、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するステップと、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断するステップと、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信するステップと、
   前記入札提案データにより提案されたアイテムを、前記一の仮想ユーザが所定期間内に入札しなかった場合には、当該一の仮想ユーザに対して、当該アイテムを用いない限り進捗不可能であって当該アイテムを用いることで進捗可能になるイベントを発生させるステップと、を通信ネットワークに接続されたコンピュータに実行させるためのゲームプログラム。
7. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信するステップと、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するステップと、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断するステップと、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信するステップと、
   前記入札提案データにより提案したアイテムを前記一の仮想ユーザが落札した場合に、落札したアイテムの所有権を前記一の仮想ユーザに設定するステップと、
   前記落札したアイテムを仮想通貨又は他のアイテムに交換するための操作データの受信の有無に基づいて、当該アイテムの所有権が前記一の仮想ユーザから所定期間内に消滅したか否かを判断するステップと、
   前記所定期間内に消滅したと判断した場合には、前記入札提案データに代えて前記一の仮想ユーザが入札するに適したアイテム以外のアイテムの入札を提案するデータを前記一の仮想ユーザを操作する端末に送信する第１不利益条件、前記オークションで前記一の仮想ユーザの所有通貨量を超える額まで落札額をつり上げて落札不能にする第２不利益条件条件、前記一の仮想ユーザを操作する端末に前記入札提案データを送信しない第３不利益条件のうち、少なくとも一つの不利益条件を設定するステップと、を通信ネットワークに接続されたコンピュータに実行させるためのゲームプログラム。
8. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信するステップと、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するステップと、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断するステップと、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信するステップと、
   前記入札提案データにより提案されたアイテムを、前記一の仮想ユーザが所定期間内に入札しなかった場合には、当該一の仮想ユーザに対して、当該アイテムを用いない限り進捗不可能であって当該アイテムを用いることで進捗可能になるイベントを発生させるステップと、を通信ネットワークに接続されたコンピュータに実行させるためのゲームプログラムを記録したコンピュータに読み取り可能なゲームプログラム記録媒体。
9. 通信ネットワークを介して接続された端末から、仮想空間内に形成された仮想ユーザを操作する操作データを受信するステップと、
   複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づいて、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するステップと、
   所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断するステップと、
   前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案データを、前記一の仮想ユーザを操作する端末に送信するステップと、
   前記入札提案データにより提案したアイテムを前記一の仮想ユーザが落札した場合に、落札したアイテムの所有権を前記一の仮想ユーザに設定するステップと、
   前記落札したアイテムを仮想通貨又は他のアイテムに交換するための操作データの受信の有無に基づいて、当該アイテムの所有権が前記一の仮想ユーザから所定期間内に消滅したか否かを判断するステップと、
   前記所定期間内に消滅したと判断した場合には、前記入札提案データに代えて前記一の仮想ユーザが入札するに適したアイテム以外のアイテムの入札を提案するデータを前記一の仮想ユーザを操作する端末に送信する第１不利益条件、前記オークションで前記一の仮想ユーザの所有通貨量を超える額まで落札額をつり上げて落札不能にする第２不利益条件条件、前記一の仮想ユーザを操作する端末に前記入札提案データを送信しない第３不利益条件のうち、少なくとも一つの不利益条件を設定するステップと、を通信ネットワークに接続されたコンピュータに実行させるためのゲームプログラムを記録したコンピュータに読み取り可能なゲームプログラム記録媒体。
10. 通信ネットワークを介して接続されたゲームサーバとの間で、仮想空間内に形成された一の仮想ユーザがゲームを進行するためのデータを通信するデータ通信部と、
    実ユーザから、前記一の仮想ユーザの操作入力を受け付ける操作入力部と、
    複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するアイテム推測部と、
    所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する出品判断部と、
    前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案画面を表示する入札提案部と、
    前記入札提案画面により提案されたアイテムを、前記一の仮想ユーザが所定期間内に入札しなかった場合には、当該一の仮想ユーザに対して、当該アイテムを用いない限り進捗不可能であって当該アイテムを用いることで進捗可能になるイベントを発生させるイベント発生部と、を有することを特徴とする端末装置。
11. 通信ネットワークを介して接続されたゲームサーバとの間で、仮想空間内に形成された一の仮想ユーザがゲームを進行するためのデータを通信するデータ通信部と、
    実ユーザから、前記一の仮想ユーザの操作入力を受け付ける操作入力部と、
    複数に分類された各種類ごとに対応付けて前記仮想空間内に形成された複数のアイテムの中で、過去に一の仮想ユーザが獲得したアイテムの種類を示す情報に基づき、前記一の仮想ユーザが取得していない種類に分類されるアイテムが、前記一の仮想ユーザが入札するのに適したアイテムであると推測するアイテム推測部と、
    所定の入札条件を提示することでアイテムを落札可能なオークションに、前記一の仮想ユーザが入札するのに適したアイテムが出品されているか否かを判断する出品判断部と、
    前記一の仮想ユーザが入札するのに適したアイテムが出品されている場合、当該アイテムの入札を提案する入札提案画面を表示する入札提案部と、
    前記入札提案画面により提案したアイテムを前記一の仮想ユーザが落札した場合に、落札したアイテムの所有権を前記一の仮想ユーザに設定する落札アイテム所有権設定部と、
    前記落札したアイテムを仮想通貨又は他のアイテムに交換するための操作入力の受け付けの有無に基づいて、当該アイテムの所有権が前記一の仮想ユーザから所定期間内に消滅したか否かを判断する所有権消滅判断部と、
    前記所定期間内に消滅したと判断した場合には、前記入札提案画面に代えて前記一の仮想ユーザが入札するに適したアイテム以外のアイテムの入札を提案する画面を表示する第１不利益条件、前記オークションで前記一の仮想ユーザの所有通貨量を超える額まで落札額をつり上げて落札不能にする第２不利益条件条件、前記一の仮想ユーザを操作する端末に前記入札提案画面を表示しない第３不利益条件のうち、少なくとも一つの不利益条件を設定する不利益条件設定部と、を有することを特徴とする端末装置。

Images