JP2015092962A - サーバシステム - Google Patents

Abstract

【課題】複数のアイテム交換（アイテムトレード）を組み合わせることで実現される多段階交換（多段階トレード）をより簡単に利用できるゲームを実現すること。
【解決手段】プレーヤ端末１５００で、提供する提供アイテム１６と、入手を希望する希求アイテム１８とを設定操作してトレード要求の内容を決定する。サーバシステム１１００は、プレーヤ端末１５００からトレード要求データ１０を受信し、データベースに要求登録データ５３２を登録する。そして、要求登録データ５３２を個別に取り出して検索依頼元に設定し、他の要求登録データ５３２をマッチングして、検索依頼元の要求登録データ５３２で設定された希求アイテムを得ることができるトレードの組み合わせ（多段階トレード）を自動検索する。検索結果は、プレーヤ端末１５００にて選択可能にプレーヤに提示され、サーバシステム１１００は選択された多段階トレードを実行する。
【選択図】図３

Description

本発明は、サーバシステムに関する。

ビデオゲームにおいて人気がある仕様に、ゲーム内で使用できるアイテムやキャラクタなど（以下、まとめて「アイテム」と呼ぶ）をプレーヤ間で交換する仕様がある。
プレーヤは、ゲーム開始前のログイン抽選やオンラインショッピングによりアイテム等を入手し、所持するアイテムを使ってゲームを楽しむことができる。所持するアイテムの数が増えると、どうしても一人では使い切れないほどに同じアイテムを複数所持するケースや、プレイスタイルによっては持っていても使うことのないアイテムを所持し続けるケースが生じ、どうしても不要なアイテムと欲しいアイテムが生まれる。例えば、好きな種類のプレーヤキャラクタを選択して使うことができるＲＰＧ（ロールプレイングゲーム）であれば、プレーヤキャラクタが１つしか戦闘に使えない剣アイテムを複数本持っていても２つ目以降の同じ剣アイテムは不要である。また、プレーヤキャラクタとして遠距離攻撃タイプを使いたくても、近接攻撃用の剣アイテムしかなければ、遠距離攻撃用のアイテム、例えば弓が欲しくなる。

プレーヤ間でアイテムを交換できる仕様があれば、不要なアイテムを提供して、希望するアイテムをトレードすることが可能となる。例えば、特許文献１には、プレーヤが提供するアイテム（提供する対価データ）と希求のアイテム（希望する対価データ）とを設定して交換要求を登録手続きすると、他のプレーヤの交換要求と適合する組み合わせを見つけ出し、双方の交換を実行する技術が開示されている。

特開２００３−２３６６１号公報

さて、提供するアイテム（提供アイテム）と、希求するアイテム（希求アイテム）とを設定して交換要求（トレード要求）を登録する形式では、ユーザ登録しているプレーヤが多数で、多くのプレーヤが既にある程度ゲームを進めていると、トレード要求の登録数も内容も充実してくるので、特許文献１に示すような需要と供給が適合するトレードの組み合わせも生じ易くなる。逆説的に言えば、トレード要求の登録数や内容が充実するまでは、登録はしてみたものの、一向にアイテム交換（アイテムトレード）が実現されないことになる。

そうした場合に考えられるのが、一度のトレードで希求アイテムを得る事ができなければ、提供アイテムを一旦別のアイテムにトレードし、当該別のアイテムを介して希求アイテムにトレードする多段階トレードである。ところが、特許文献１の技術でもそうした多段階トレードまではサポートされておらず、プレーヤ自身で登録されている多数のトレード要求の内容を確認し、需要と供給の関係を加味して多段階トレードの順番を作り上げ、その順番に従って一つずつ手動でトレードを実施しなければならない。しかも、そうまでして手間をかけたとしても、想定した多段階トレードの順を追って一つずつトレード実行の手続きをしている間に、途中過程のトレードが取り下げられるケースや、他プレーヤのトレードに用いられて既に終了してしまっているケースなどが発生し、想定していた多段階トレードが完成できずに終わるリスクすらあった。

本発明は、こうした背景を元に考案されたものであり、複数のアイテム交換（アイテムトレード）を組み合わせることで実現される多段階交換（多段階トレード）をより簡単に利用できるゲームを実現することを目的とする。

上述した課題を解決するための第１の発明は、各プレーヤの所持アイテムを管理する管理手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、所持アイテム管理部２１２）と、
前記所持アイテムのうちの当該プレーヤが提供可能な提供アイテムと、当該プレーヤが求める希求アイテムとのトレード要求を記憶するトレード要求記憶手段（例えば、図１のＩＣメモリ１１５２、ストレージ１１４０、図１０のサーバ記憶部５００ｓ、トレード要求データベース５３０、図１１のステップＳ１８）と、
特定トレード要求の提供アイテムと希求アイテムとのトレードを、当該提供アイテムを始点として複数のトレード要求を順繰りにトレード実行することで最終的に当該特定トレードの希求アイテムを得ることができる多段階トレードで実現可能な当該多段階トレードを検索する検索手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、トレードルート検索部２３０、図１１のステップＳ４２）と、
前記検索手段により検索された多段階トレードを実行する多段階トレード実行手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、トレード実行制御部２５０、図１２のステップＳ４３４）と、を備えたサーバシステムである。

第１の発明によれば、プレーヤが提供するアイテム（提供アイテム）と、入手を希望するアイテム（希求アイテム）とを設定して、トレード要求を登録すると、複数のトレード要求を順繰りに実行することで希求アイテムが得られるようになるトレード要求の組み合わせ、すなわち多段階トレードが自動的に検索される。つまり、プレーヤ自身が、登録されている多数のトレード要求の内容を確認し、需要と供給の関係を加味して多段階トレードの順番を作り上げる手間は要らない。

そして、該当するトレード要求の組み合わせが検索できたならば、その多段階のトレードを構成するトレード要求を自動的に連続的に実行することができる。つまり、プレーヤは、組み合わされたトレードを順番に従って一つずつ手動で実行する必要はなく、簡単に希求アイテムを入手することができる。

第２の発明は、第１の依頼プレーヤの希求アイテムとトレード上限回数とを設定する第１の設定手段（例えば、図１のプレーヤ端末１５００、制御基板１１５０、通信装置１１５３、図９のトレード要求設定部２７８、図１１のステップＳ１４）を更に備え、
前記検索手段は、前記管理手段により管理されている前記第１の依頼プレーヤの所持アイテムの何れかを提供アイテムとし、前記設定された希求アイテムを得るトレード要求を前記特定トレード要求とした場合に、前記設定されたトレード上限回数までのトレード実行で実現可能な前記多段階トレードを検索する第１の依頼検索手段（例えば、図９の第１依頼検索部２３１、図１１のステップＳ３６）と、
前記第１の依頼検索手段による検索が成功した場合に、前記第１の依頼プレーヤの何れを提供アイテムとする多段階トレードが検索されたかを含む検索結果（例えば、図５のトレード選択画面Ｗ４のリスト表示部５０）を出力する第１の検索結果出力手段（例えば、図１のプレーヤ端末１５００、制御基板１１５０、図９のサーバ処理部２００ｓ、トレード選択制御部２４０、第１検索結果出力制御部２４１、図１４のステップＳ２２６）と、を有する、第１の発明のサーバシステムである。

また、第３の発明は、前記多段階トレード実行手段が、前記第１の依頼検索手段により検索された多段階トレードのうち、前記第１の依頼プレーヤにより選択された一の多段階トレードを実行する、第２の発明のサーバシステムである。

第２又は第３の発明によれば、トレード上限回数以内のトレードを組み合わせることで希求アイテムと交換できる多段階トレードを検索することができる。すなわち、プレーヤは欲しいアイテムと容認できるトレードの回数とを設定すれば、トレードの組み合わせ、すなわち多段階トレードを自動的に得ることができる。
第３の発明であれば、更に複数の多段階トレードが検索された場合に、その何れかをプレーヤが選択して実行させることができる。

第４の発明は、第２の依頼プレーヤの提供アイテムとトレード上限回数とを設定する第２の設定手段（例えば、図１のプレーヤ端末１５００、制御基板１１５０、通信装置１１５３、図９のトレード要求設定部２７８、図１１のステップＳ１４）を更に備え、
前記検索手段は、
前記第２の設定手段により設定された提供アイテムを始点として、前記第２の設定手段により設定されたトレード上限回数までの前記多段階トレードを実行した場合に得ることができる希求アイテムの候補を検索する第２の依頼検索手段（例えば、図９の第１依頼検索部２３１、図１１のステップＳ４０）と、
前記第２の依頼検索手段により検索された希求アイテムの候補を出力する第２の検索結果出力手段（例えば、図１のプレーヤ端末１５００、制御基板１１５０、図９のサーバ処理部２００ｓ、トレード選択制御部２４０、第１検索結果出力制御部２４１、図１５のステップＳ３２６）と、を有する、第１〜第３の何れかの発明のサーバシステムである。

また、第５の発明は、前記多段階トレード実行手段が、前記第２の依頼検索手段の検索結果に基づいて、前記第２の設定手段により設定された提供アイテムを始点として、検索された希求アイテムの候補のうちの前記第２の依頼プレーヤにより選択された一の希求アイテムを求める多段階トレードを実行する、第４の発明のサーバシステムである。

第４又は第５の発明によれば、トレード上限回数以内のトレードを組み合わせることで提供アイテムと交換できる何らかのアイテムに到達する多段階トレードを検索することができる。すなわち、プレーヤは不要なアイテムと交換できる希求アイテムの候補と、その希求アイテムを得るためのトレードの組み合わせ、すなわち多段階トレードを自動的に得ることができる。
第５の発明であれば、更に複数の多段階トレードが検索された場合に、その何れかをプレーヤが選択して実行させることができる。

第６の発明は、前記検索手段により検索された多段階トレードに係るトレード要求を仮押さえ状態に設定する仮押さえ状態設定手段（例えば、図１の制御基板１１５０、図９の仮押さえ状態設定部２２２、図１０の検索対象外リスト５６０、図１３のステップＳ１２４）と、
前記仮押さえ状態の設定から所与の時間が経過した設定を解除する時間経過解除手段（例えば、図１の制御基板１１５０、図９の時間経過解除部２２３、図１２のステップＳ４２０〜Ｓ４２２）と、を更に備え、前記検索手段が、前記仮押さえ状態に設定されていないトレード要求を用いた前記多段階トレードを検索する（例えば、図１３のステップＳ１１０）、第１〜第５の何れかの発明のサーバシステムである。

また、第７の発明は、前記検索手段により複数の多段階トレードが検索され、且つ、当該複数の多段階トレードのうちの一の多段階トレードが前記多段階トレード実行手段により実行された場合に、残余の多段階トレードに係るトレード要求の前記仮押さえ状態の設定を解除する不用トレード解除手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、不要トレード解除部２２４、図１２のステップＳ４３６）、を更に備えた第６の発明のサーバシステムである。

第６又は第７の発明によれば、検索された多段階トレードを構成するトレード要求を、別の多段階トレードの検索の際にその構成に組み込まれないようにできる。よって、検索された多段階トレードを実行する時になって、構成するトレード要求が既に成立していて利用できなくなり、当該多段階トレードを完成できない事態を防ぐことができる。
第７の発明であれば更に、同じ特定トレード要求を満たすべく検索された多段階トレードのうち、実行されなかった多段階トレードを構成するトレード要求の仮押さえ状態を解除することができる。

第８の発明は、前記多段階トレード実行手段が、前記多段階トレードの実行の際に、当該多段階トレードに係るトレード要求が既に実行済みであった場合に、当該トレード要求以外の当該多段階トレードに係るトレード要求を実行することで当該多段階トレードが実行できたとみなす救済実行手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、救済実行部２５２、図１２のステップＳ４３４）を有する、第１〜第７の何れかの発明のサーバシステムである。

第８の発明によれば、多段階トレードを実行するときになって、当該多段階トレードを構成するトレード要求が既にトレードが成立し実行済みとなっていて、当該多段階トレードの組み合わせが破綻する場合でも、残ったトレード要求を実行することにより、多段階トレードが検索されてから実行されるまでの間の途中破綻のリスクを低減できる。

なお、多段階トレードの検索や、多段階トレードの実行に対価を要求することもできる。
すなわち、第９の発明として、前記検索手段による検索、及び／又は、前記多段階トレード実行手段による実行に、所与の対価を課す対価処理手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、対価処理部２４８、図１１のステップＳ１６、図１２のステップＳ４３２）、を更に備えた第１〜第８の何れかの発明のサーバシステムを構成することができる。

更には、サービス内容の多寡に応じて対価を可変するように、第１０の発明として、前記対価処理手段が、少なくとも前記多段階トレード実行手段による実行に対価を課し、実行する多段階トレードに係るトレード要求の数に従って対価を変更する、第９の発明のサーバシステムを構成することもできる。

ゲームシステムの構成の一例を示す図。 プレーヤ端末の構成例を示す正面外観図。 アイテムトレードの概要を説明するための図。 トレード要求の登録について説明するための図。 検索されたトレードルートの選択について説明するための図 提供アイテムにワイルドカードを設定した場合のルート検索を説明するための図。 希求アイテムにワイルドカードを設定した場合のルート検索を説明するための図。 検索外登録仕様について説明するための図。 サーバシステムの機能構成例を示す機能ブロック図。 サーバ記憶部が記憶するプログラムやデータの例を示す図。 多段階トレードを実現するためのサーバシステムにおけるア処理の流れについて説明するためのフローチャート。 図１１より続くフローチャート。 第１ルート検索処理の流れを説明するためのフローチャート。 第２ルート検索処理の流れを説明するためのフローチャート。 第３ルート検索処理の流れを説明するためのフローチャート

〔第１実施形態〕
本発明を適用した第１実施形態について説明する。
図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線Ｎに接続することのできるサーバシステム１１００と、プレーヤ２（２ａ，２ｂ，２ｃ，・・・）毎に用意されるプレーヤ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，・・・）とを備えて構成される。

サーバシステム１１００は、単数又は複数のサーバシステムや記憶装置等を含んで構成される。サーバシステム１１００は、ＳＮＳ（ソーシャルネットワーキングサービス）等の会員登録制のウェブサイトを運営するための各種サービスを提供することができる。
具体的には、会員登録を済ませたユーザにはそれぞれ固有のアカウント（ハンドルネームと読み替えることもできる）を発給し、登録済みユーザに係る情報はサーバシステム１１００がユーザ登録データ５２０で一元的に管理する。そして、ユーザ登録データ５２０に基づいて当該ウェブサイトにおける様々なサービスを提供する。本実施形態のゲームも、登録ユーザへのサービスの一環として提供・実現される。すなわち、各プレーヤ２（２ａ，２ｂ，２ｃ，…）は登録ユーザである。各プレーヤ２（２ａ，２ｂ，２ｃ，…）は、それぞれのプレーヤ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，…）を使用してサーバシステム１１００にアクセスして本実施形態のゲームを楽しむ。

サーバシステム１１００は、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。本体装置１１０１には、制御基板１１５０が搭載されている。制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。

そして、本実施形態のゲームに関する機能として、アカウント登録やログイン／ログアウトに関係する処理を担うアカウント管理機能と、プレーヤ端末１５００にてゲームをプレイするのに必要なデータを随時管理・配信するゲーム管理機能と、を有する。ゲーム内で利用できるアイテム等（アイテムやキャラクタなど）をオンラインショッピングで提供するオンラインショッピング管理機能を更に有するとしてもよい。

図示の例では、サーバシステム１１００は単体として記されているがこれに限らない。たとえば、サーバシステム１１００が複数のブレードサーバを有して構成され、アカウント管理機能やゲーム管理機能などを別々のブレードサーバに分担させ、相互に内部バスを介してデータ通信可能に接続する構成であってもよい。或いは、通信回線Ｎを介して離れた場所に設置された独立した複数のサーバをデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であってもよい。

なお、サーバシステム１１００は通信回線Ｎを通じて、プレーヤ端末１５００以外の装置とも通信をすることができる。例えば、課金処理を担う外部サーバと通信することもできる。

図２は、プレーヤ端末１５００の構成例を示す正面外観図である。
プレーヤ端末１５００は、通信回線Ｎに接続してサーバシステム１１００にアクセスすることができるコンピュータであり電子装置（電子機器）である。本実施形態のプレーヤ端末１５００はいわゆるスマートフォンとして分類される小型コンピュータを想定しているが、携帯型ゲーム装置、据置型家庭用ゲーム装置、据置型家庭用ゲーム装置のゲームコントローラ、業務用ゲーム装置、パソコン、タブレット型コンピュータ、腕時計型やメガネ型等のウェアラブルコンピュータ、などに分類される装置で実現してもよい。

本実施形態におけるプレーヤ端末１５００は、方向入力キー１５０２と、ボタンスイッチ１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、内蔵バッテリー１５０９と、マイク１５１２と、制御基板１５５０と、コンピュータ読み出し可能な記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない電源ボタン、音量調節ボタン等が設けられている。

制御基板１５５０は、ＣＰＵ１５５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサと、ＡＳＩＣ，ＶＲＡＭ，ＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２と、通信回線Ｎに接続する携帯電話基地局や無線ＬＡＮ基地局などと無線通信するための無線通信モジュール１５５３とが搭載されている。その他、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びボタンスイッチ１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置１５４２への信号入出力回路といった所謂Ｉ／Ｆ回路１５５７（インターフェース回路）等が搭載されている。これら制御基板１５５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

制御基板１５５０は、サーバシステム１１００から取得したゲームクライアントプログラムやデータをＩＣメモリ１５５２に一時記憶する。そして、プログラムを実行して演算処理を実行し、方向入力キー１５０２やボタンスイッチ１５０４，タッチパネル１５０６からの操作入力に応じてプレーヤ端末１５００の各部を制御してゲームプレイ可能にする。なお、本実施形態では、プレーヤ端末１５００は必要なプログラムや各種設定データをサーバシステム１１００から取得する構成としているが、別途入手したメモリカード１５４０から読み出す構成としても良い。

なお、通信回線Ｎはデータ通信が可能な通信路を意味する。すなわち、通信回線Ｎとは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

［ゲーム内容の説明］
図１に戻って、ゲーム画面例Ｗ１に示すように、本実施形態のゲームは、プレーヤが好みの種類のキャラクタをプレーヤキャラクタ４として設定し、ゲームステージ（所謂マップ）上で遭遇する敵キャラクタ６（ＮＰＣ：ノンプレーヤキャラクタ）と戦うＲＰＧ（ロールプレイングゲーム）である。プレーヤ２は、アイテム３を、ログイン時に提供される無料抽選や、オンラインショッピング、ゲーム内で宝箱の中身、敵がドロップ、クリアボーナスなどの形で入手によって取得し、そしてゲーム内で使用することができる。

ここで言う「アイテム」とは、ゲームプレイに関連して利用することのできるデータであって、ゲーム内容やゲームプレイの仕組みに応じて適宜設定可能である。本実施形態のゲームはＲＰＧなので、プレーヤキャラクタ４の種類別に用意された武器や防具、爆弾やＨＰの回復薬、用具や薬等の生成や合成するための材料、プレーヤキャラクタ４に習得させるスキル、プレーヤキャラクタ４やアイテムに付与する経験値、ゲームステージのプレイ権、召喚獣、などを適宜設定できる。ゲームプレイの仕組みに関するアイテムとしては、プレイ料金のクーポン、アイテムを取得するための有料抽選に利用する抽選券、などを適宜設定することができる。もし、ゲームカードでデッキを構成してプレイするカードゲームであれば、ゲーム内で使用可能なゲームカードがアイテムに該当する。

プレーヤ２が取得したアイテム３は、サーバシステム１１００が、プレーヤ２のアカウントと対応づけて用意されるユーザ登録データ５２０の所持アイテムリスト５２２に登録され管理される。そして、本実施形態のゲームには、プレーヤ２が所有するアイテムを他プレーヤとの間で物々交換することのできるアイテムトレードの仕様、しかも多段階トレードの仕様が盛り込まれている。

図３は、本実施形態におけるアイテムトレードの概要を説明するための図である。
プレーヤは、プレーヤ端末１５００を用いて、自身が所有するアイテム３のリストから、トレードに提供する提供アイテム１６とトレードで入手を希望する希求アイテム１８とを選択し、更にトレード上限回数１４を選択して、トレード要求の内容を設定することができる。そして、設定したトレード要求を登録することができる。
なお、本実施形態では、提供アイテム１６と希求アイテム１８とを１対１で設定する構成であるが、多対１または１対多、多対多を許容する構成としてもよいのは勿論である。

トレード要求の登録操作をすると、プレーヤ端末１５００からサーバシステム１１００へ、登録リクエストとともにトレード要求データ１０が送信される。トレード要求データ１０には、例えばプレーヤのアカウント１２と、トレード上限回数１４と、提供アイテム１６のアイテムＩＤと、希求アイテム１８のアイテムＩＤとが対応づけて格納されている。

サーバシステム１１００は、トレード要求データベース５３０を記憶し、各プレーヤからのトレード要求を記憶・管理する。トレード要求データベース５３０には、受信したトレード要求データ１０に基づいて作成される要求登録データ５３２が複数登録されている。要求登録データ５３２は、それが示すトレード内容が実行されると消去（又は成立済みに設定：以降は単に“消去”と記載）される。

具体的には、一つの要求登録データ５３２は、登録時に自動付与される固有の要求ＩＤ５３２ａと、当該要求を登録手続きした依頼プレーヤアカウント５３２ｂと、提供アイテム１６の識別情報である提供アイテムＩＤ５３２ｃと、希求アイテム１８の識別情報である希求アイテムＩＤ５３２ｄと、トレード上限回数５３２ｆとを含む。勿論、これら以外のパラメータ値（例えば、有効期限など）を適宜含めることもできる。

サーバシステム１１００は、トレード要求データベース５３０に登録されている要求登録データ５３２を“検索依頼元”する特定トレード要求として個別に選択し、特定トレード要求毎に、それ以外の要求登録データをもとに特定トレード要求で要求されているトレードを実現するトレードの組み合わせを自動的に検索する。換言すると、希求アイテム１８を得るための「多段階トレード」を構成する要求登録データ５３２のマッチングを決定する。なお、ここで言う「多段階」には単段階を含むこととするが、２段階以上としても勿論良い。

本実施形態では、多段階トレードの構成をルート検索問題として解くことで得る。すなわち、“検索依頼元”となった要求登録データ５３２の提供アイテム１６をスタート地点、希求アイテム１８をゴール地点と見なし、且つ、それ以外の要求登録データ５３２をその提供アイテム１６を起点、その希求アイテム１８を終点とする通行路（路線）と見なして、スタート地点からゴール地点までのルート検索問題としてこれを解き、目的とする多段階トレードを構成する。よって、多段階ルートの検索結果は「トレードルート」と言うことができる。

なお、一つのトレード要求において提供アイテム１６および希求アイテム１８について、アイテムの種類と個数とを設定可能とする構成も可能である。その場合、スタート地点側の通行路の終点となる希求アイテム１８と、ゴール地点側の通行路の提供アイテム１６とが同じ種類で、且つ、後者の個数が前者のそれと同じまたは上回る場合に、これらの通行路を連結してルートを構成することができるものとする。

さて、サーバシステム１１００は、トレードルートを検索すると、検索されたルート毎にトレードルートデータ５５０を生成し、検索対象の要求登録データ５３２と対応づけて記憶・管理する。そして、トレードルートデータ５５０をプレーヤ端末１５００に提供する。

プレーヤ端末１５００は、提供されたトレードルートデータ５５０に基づいて、多段階トレードの選択肢をプレーヤが選択可能に表示することができる。そして、プレーヤが、選択可能に提示された何れかの多段階トレードすなわちトレードルートを選択操作し、トレードの実行を承認操作すれば、選択結果等はサーバシステム１１００に送信され、選択された多段階トレードが実行される。

では、トレード要求の設定から多段階トレードの実行までを、プレーヤ端末１５００での表示画面の例を交えながらより具体的に説明する。

図４は、トレード要求の登録について説明する図である。
所定のトレード要求登録の開始操作が検出されると、プレーヤ端末１５００にてトレード要求設定画面Ｗ２が表示される。

トレード要求設定画面Ｗ２は、所持アイテムリスト５２２（図１）に登録されているアイテムを表すアイテムアイコン２１が並べられた所持アイテム一覧表示２０と、提供アイテム１６を指定する提供アイテム設定欄２２と、希求アイテム１８を指定する希求アイテム設定欄２４と、トレード上限回数設定欄２８と、登録操作アイコン４０と、登録済みのトレード要求の末梢を指示するための登録抹消操作アイコン４２と、を含む。

提供アイテム１６は、例えば所持アイテム一覧表示２０からアイテムアイコン２１を提供アイテム設定欄２２へドラッグ・アンド・ドロップ操作することで設定できる。逆にアイテムアイコン２１を欄外にドラッグ・ドロップ操作することで指定を解除できる。なお、所持アイテム一覧表示２０は、スクロール表示に対応しているものとする。

希求アイテム１８は、トレード可能なアイテムのリストを表示させるアイテムリスト表示アイコン２５をタッチ操作することで表示される一覧から選択して指定する。

登録操作アイコン４０は、当該トレード要求の登録手続の開始操作を入力するためのアイコンである。当該アイコンへのタッチ操作を検出すると、プレーヤ端末１５００はトレード要求データ１０を生成し、サーバシステム１１００へ登録リクエストとトレード要求データ１０とを送信する。
サーバシステム１１００は、これらを受信すると受信したトレード要求データ１０に基づいて新たな要求登録データ５３２を生成しトレード要求データベース５３０に登録する（図３参照）。

図５は、検索されたトレードルートの選択について説明するための図である。
サーバシステム１１００がトレードルートを検索し、要求プレーヤのプレーヤ端末１５００へトレードルートデータ５５０を送信する。これを受信したプレーヤ端末１５００は、トレードルート選択画面Ｗ４を表示することができる。トレードルート選択画面Ｗ４は、リスト表示部５０にて、トレードルートデータ５５０の内容のうち、多段階トレードを実現するのに要するトレードの“所要回数”と、トレードの“相手”と、“ルートの概要”とを、ルート別に表示する。

リスト表示部５０での見せ方は適宜設定可能であるが、例えばトレードの相手として、プレーヤのアバターを表示させたりアカウントを表示させてもよい。ルートの概要では、当該ルートに係るアイテム３の種類を示すアイコンをトレードの順に表示するとしてもよい。また、図示の例では２つのトレードルートについて表示しているが、更に多くのトレードルートについて表示する場合には、適宜ページ別にスクロール表示可能に表示するとともに、現在表示されているページをページ表示５１（吹き出し内は、複数ページ用）やスクロールバーで表示するものとする。

そして、リスト表示部５０で何れかの段をタッチ操作すると、対象段に該当するトレードルートが選択状態になり、ルート詳細表示部５２にてその詳細が表示される。

図５の例では、リスト表示部５０の２段目のトレードルートが選択されており選択状態であることを示す選択マーカ５３が２段目に添付表示されている。そして、ルート詳細表示部５２では、多段階ルートを実現するトレードの順に、プレーヤ情報表示５４（例えば、アバターであったり、アカウント）とアイテム情報表示５５（例えば、アイテムの外観を示すアイコンや、アイテム名）とをセットにして、対向配置してトレードの内容を示している。なお、ルート詳細表示部５２での表示形態はこれに限らず適宜設定可能である。

そして、何れかのトレードルートを選択した状態で、トレード許諾アイコン５６をタッチ操作すると、プレーヤ端末１５００は、サーバシステム１１００へ、選択したトレードルートのルートＩＤと、当該ルートを構成するトレードの実行リクエストとを送信する。

サーバシステム１１００は、受信したルートＩＤに対応するトレードルートデータ５５０を参照して、当該ルートを構成する単数又は複数のトレードを順時実行し、トレードに係わる各プレーヤの所持アイテムリスト５２２（図１参照）にトレード結果を反映する。そして、トレードに係わる各プレーヤのプレーヤ端末１５００へトレードが完了した旨を告げる通知を行う。

この通知は、該当するプレーヤがログインしていれば、すなわちゲームプレイ中であればそのゲーム画面内に通知を表示させるとしてもよい。もし、ログインしていなければログイン時に同通知を表示する設定としてもよい。あるいは、ユーザ登録時にＥメールアドレスを登録させることとし、登録されたアドレスに通知を送るとしてもよい。

よって、本実施形態によれば、プレーヤ自身で登録されている交換要求の内容を確認し、多数の需要と供給の関係を加味して多段階の交換の順番を作り上げ、その順番に従って一つずつ手動で交換を実施しなくとも、トレード要求を設定・登録し、自動検索された多段階トレードを選択・許諾するだけで、簡単に希望するアイテムを入手できる。

更に、本実施形態のアイテム交換では、提供アイテム１６と希求アイテム１８とにそれぞれワイルドカード（任意のアイテムを意味する：図４の例でいうところの「？」マークのアイテムアイコンがワイルドカードに相当）を設定することで、アイテムの種類を未定のままトレード要求を設定・登録できる。

図６は、提供アイテム１６にワイルドカードを設定した場合のルート検索を説明するための図である。
提供アイテム１６を未定としてトレード要求を設定し登録手続きすると、検索時点でプレーヤが所持しているアイテム（所持アイテムリスト５２２に登録されているアイテム３）の何れかで、トレード上限回数以内のトレードを組み合わせて希求アイテム１８を入手できるルートを検索することができる。

具体的には、プレーヤが望む希求アイテム１８を提供アイテムとして設定している１つ目の他の要求登録データ５３２（５３２ｃ）を検索し、当該１つ目の他の要求登録データ５３２（５３２ｃ）の希求アイテムをプレーヤが所持しているか判定する。
もし、所持していなければ、当該希求アイテムを提供アイテムとして設定している２つ目の他の要求登録データ５３２（５３２ｂ）を検索し、当該２つ目の他の要求登録データ５３２（５３２ｂ）の希求アイテムをプレーヤが所持していれば、ルート検索を完了とする。
そして、２つ目の他の要求登録データ５３２（５３２ｂ）を第１段階目のトレードとし、１つ目の他の要求登録データ５３２（５３２ｂ）を第２段階目のトレードとするトレードルートデータ５５０を生成する。
もし、２つ目の他の要求登録データ５３２（５２２ｂ）の希求アイテムをプレーヤが所持していなければ、トレード上限回数１４に達するまで他の要求登録データ５３２の検索とプレーヤの所持するアイテムとの照合とを繰り返ことになる。

つまり、提供アイテムを未定のまま欲しいアイテムとトレード上限回数とを設定してトレード要求を登録すると、プレーヤが提供するべきアイテムを持っていれば、希望を叶える多段階トレードが自動的に検索・提示されることになる。

図７は、希求アイテム１８にワイルドカードを設定した場合のルート検索を説明するための図である。
希求アイテム１８を未定としてトレード要求を設定し登録手続きすると、提供アイテム１６の提供を前提としてトレード上限回数以内で組み合わせることができるルートを全て検索する。

具体的には、プレーヤが提供するつもりの提供アイテム１６を希求アイテムとして設定している他の要求登録データ５３２（５３２ｂ）が有れば、当該データを第１の要求登録データ５３２（５３２ｂ）とする１段階のトレードルートデータ５５０（５５０ｂ）を生成する。

トレード回数が上限回数に達していなければ、第１の要求登録データ５３２（５３２ｂ）の提供アイテムを希求アイテムに設定している他の要求登録データ５３２（５３２ｃ）を更に検索し、該当するデータがあれば、当該データを第２の要求登録データ５３２（５３２ｃ）とし、第１の要求登録データ５３２（５３２ｂ）とともに２段階のトレードルートデータ５５０（５５０ｃ）を生成する。以下、トレード回数が上限回数に達するまで繰り返す。図７の例では、トレード回数の上限が「３」であり、第３の要求登録データ５３２（５３２ｄ）が見つかったため、３段階のトレードルートデータ５５０（５５０ｄ）が生成されている。

つまり、希求アイテムを未定のまま不要なアイテムとトレード上限回数とを設定してトレード要求を登録すると、当該不要なアイテムを提供することで入手できる多段階トレードが自動的に提示されることになる。

また、本実施形態では、検索外登録仕様と、ルート欠損時の救済仕様とが盛り込まれている。
検索外登録仕様とは、トレード要求の取り下げによる多段階ルートが中断してしまうリスクを低減するために、検索されたルートに含まれる要求登録データ５３２を、他のトレードルートの検索に使用されないように一時的に検索対象外に指定する、いわば“仮押さえ状態”にする仕様である。
ルート欠損時の救済仕様とは、検索されたルートを構成していたトレードの一部がトレード要求データベース５３０から消えてしまっていてルートが欠損した場合でもトレードルートの実現を保証する仕様である。例えば、当該トレードを要求したプレーヤが自らトレードルートを発見して実行して、当該トレードが消化していた場合、等である。

図８は、検索外登録仕様について説明するための図である。
サーバシステム１１００は、トレード要求データ１０を新たに登録すると（図３，図４）、当該トレード要求データ１０を要求登録データ５３２とするルート管理データ５４０を生成する。そして、ルート管理データ５４０には、対応する要求登録データ５３２の要求ＩＤ５３２ａを格納する検索依頼元要求ＩＤ５４１と、検索結果に応じて生成される単数又は複数のトレードルートデータ５５０とが格納される。

一つのトレードルートデータ５５０は、固有のルートＩＤ５５１と、検索日時５５２と、当該ルートを実現するための所要トレード回数５５３と、トレードの相手となるプレーヤのアカウントリストであるトレード相手リスト５５４と、当該ルートを構成する要求登録データ５３２の要求ＩＤを実施するべきトレードの順に格納したルート構成リスト５５５とを含む。

そして、サーバシステム１１００は、ルート構成リスト５５５に格納された要求ＩＤを検索対象外リスト５６０に登録し、他のルート検索の検索対象外とする。図８の例では、「TRN101」「TRN03」「TRN06」の３つの要求ＩＤが登録されることになる。但し、全てのプレーヤはアイテム交換の機会を平等に得られるべきであるから、検索対象外リスト５６０への登録は所定期間に限った時限性とする。すなわち、サーバシステム１１００は検索日時５５２から所定時間経過したトレードルートを構成する要求登録データ５３２の要求ＩＤを自動的に登録抹消するものとする。

ルート欠損時の救済仕様として、サーバシステム１１００は、トレードルートデータ５５０に基づいてトレードルートを実行する際、実行対象のルートを構成する要求登録データ５３２で、まだトレード要求データベース５３０（図３参照）に残っている要求登録データ５３２については、それぞれの依頼プレーヤアカウント５３２ｂが示すプレーヤの所持アイテムリスト５２２から提供アイテムＩＤ５３２ｃのアイテムを削除して、希求アイテムＩＤ５３２ｄが示すアイテムを登録する。

例えば，図３の例で言えば、要求登録データ５３２（５３２ａ）を検索依頼元として、第１の要求登録データ５３２（５３２ｂ）と第２の要求登録データ５３２（５３２ｃ）とでトレードルートを構成している。当該トレードルートを実行する際に、もし第１の要求登録データ５３２（５３２ｂ）がデータベースから消去（あるいは成立済み状態）になっていても、当該要求登録データ５３２（５３２ｂ）以外を実行することで当該トレードルートを実行（救済）する。すなわち、検索依頼元である要求登録データ５３２（５３２ａ）の依頼プレーヤと、第２の要求登録データ５３２（５３２ｃ）の依頼プレーヤとは、ともに望んだアイテムを得て救済されることになる。換言すると、サーバシステム１１００が、仮想的に第１の要求登録データ５３２（５３２ｂ）が残っているものとして実質的に“肩代わり”を行う。

［サーバシステムの機能構成例の説明］
次に、本実施形態における機能構成例について説明する。
図９は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態におけるサーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、画像表示部３７２ｓと、通信部３７４ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段である。図１の例ではキーボード１１０６が該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、プレーヤ端末１５００から受信したデータに基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。図１の例では制御基板１１５０が該当する。

そして、本実施形態のサーバ処理部２００ｓは、アカウント管理部２０１と、ゲーム管理部２１０と、画像生成部２７２ｓと、通信制御部２７４ｓとを含む。

アカウント管理部２０１は、ユーザ登録手続きに係る処理と、ログインに関する処理とを行う。すなわち、登録手続きを経たユーザすなわちプレーヤに対して固有のアカウントを発給し、ユーザ登録データ５２０（図１０参照）をサーバ記憶部５００ｓに生成・記憶してその管理を行う。

ゲーム管理部２１０は、ゲーム実行に関する各種処理を実行する。
本実施形態では、アイテム提供管理部２１１と、所持アイテム管理部２１２と、トレード要求設定制御部２２０と、トレード要求管理部２２１と、トレードルート検索部２３０と、トレード選択制御部２４０と、対価処理部２４８と、トレード実行制御部２５０と、ゲーム進行制御部２６０と、を有する。

アイテム提供管理部２１１は、アイテム３の提供に係る処理を実行する。例えば、オンラインショッピング機能や、ゲーム世界での物売りのＮＰＣ（ノンプレーヤキャラクタ）による販売、敵キャラクタ６によるドロップ、宝箱の中身としての提供、ステージクリアボーナスなどの各種ボーナスとしての提供、などの制御を行うことができる。

所持アイテム管理部２１２は、プレーヤが入手したアイテム３をプレーヤのアカウントと対応づけて管理する。つまり、各プレーヤの所持アイテムを管理する。具体的には、ユーザ登録データ５２０の所持アイテムリスト５２２の管理処理をする。

トレード要求設定制御部２２０は、トレード要求の設定に係る制御をする。具体的には、プレーヤ端末１５００にて、トレード要求設定画面Ｗ２（図４参照）を表示させ、プレーヤの操作入力に応じてトレード要求データ１０（図３参照）を生成させ、登録操作を検出してトレード要求データ１０をサーバシステム１１００へ送信させる。その他、登録済みのトレード要求の登録抹消に係る処理も行うことができる。

トレード要求管理部２２１は、各プレーヤのトレード要求の記憶管理を行う。例えば、受信したトレード要求データ１０に基づいて新たな要求登録データ５３２を生成してトレード要求データベース５３０に登録する処理や、プレーヤからの削除リクエストに応じて登録済みの要求登録データ５３２を登録抹消する処理、実行されたトレードの要求登録データ５３２を登録抹消する処理を行うことができる。

また、本実施形態のトレード要求管理部２２１は、仮押さえ状態設定部２２２と、時間経過解除部２２３と、不要トレード解除部２２４とを有する。

仮押さえ状態設定部２２２は、トレードルートの構成に組み込まれたトレード要求、すなわち要求登録データ５３２を検索対象外リスト５６０（図８）に登録して、他のルート検索の検索対象外とし、一時的な仮押さえ状態にする。

時間経過解除部２２３は、検索対象外として登録されている要求登録データ５３２を、登録開始からの時間経過に応じて登録解除する。具体的には、検索日時５５２から所定時間経過した要求登録データ５３２を検索対象外リスト５６０から消去する。なお、ここで言う所定時間は、プレーヤの技量に応じて可変としてもよい。例えば、ユーザ登録データ５２０には、プレーヤのプレイ履歴を記憶することとし、当該プレイ履歴に基づいてプレーヤの技量を示すプレーヤレベルを設定して記憶する。そして、プレーヤレベルが高いほど所定時間が短くなるように（あるいは逆に長くなるように）変更する。

不要トレード解除部２２４は、実行されたトレードルートと同じ内容の他のトレードルートに対応する要求登録データ５３２を、検索対象外の登録から解除する。換言すると、複数のトレードルートが検索され、且つ、当該複数のトレードルートのうちの一つが実行された場合に、残余のトレードルートに係るトレード要求の仮押さえ状態の設定を解除する。
具体的には、実行されたトレードルートデータ５５０に対応するルート管理データ５４０に登録されている、他のトレードルートデータ５５０のルート構成リスト５５５に登録されている要求ＩＤを、検索対象外リスト５６０から消去する。

トレードルート検索部２３０は、検索依頼元とする特定トレード要求の提供アイテム１６と希求アイテム１８とのトレードを、当該提供アイテムを始点として複数のトレード要求を順繰りにトレード実行することで最終的に当該特定トレードの希求アイテムを得ることができるトレードの組み合わせを検索する。

具体的には、トレード要求データベース５３０に登録されている一つの要求登録データ５３２を検索依頼元（特定トレード要求）として設定し、他の要求登録データ５３２（但し、検索対象外に登録されていないもの）に基づいてトレードルートの検索処理を行う。そして、検索結果毎にトレードルートデータ５５０を生成し、検索依頼元とした要求登録データ５３２に対応するルート管理データ５４０（図８）へ登録する。なお、検索アルゴリズムは公知の最短経路問題を解くアルゴリズムなどを適宜利用することもできる。

そして、本実施形態のトレードルート検索部２３０は、第１依頼検索部２３１と、第２依頼検索部２３２と、を含む。

第１依頼検索部２３１は、提供アイテム１６にワイルドカードを設定した場合のルート検索を行う。換言すると、所持アイテム管理部２１２により管理されている検索依頼元の依頼プレーヤの所持アイテムの何れかを提供アイテム１６とし、検索依頼元の希求アイテム１８を、検索依頼元のトレード上限回数１４までのトレード実行で実現可能なルートを検索する。具体的には、検索依頼元とする要求登録データ５３２の依頼プレーヤアカウント５３２ｂ（図３）が示すプレーヤの所持アイテムリスト５２２（図１）に登録されているアイテム３を提供アイテム１６として、検索依頼元とする要求登録データ５３２の希求アイテム１８が得られるトレードルートを検索する（図６参照）。

第２依頼検索部２３２は、希求アイテム１８にワイルドカードを設定した場合のルート検索を行う。換言すると、検索依頼元の提供アイテム１６を始点として、検索依頼元のトレード上限回数１４までのトレードで組み合わされるトレードルートを全て検索する（図７参照）。結果的に、各トレードルートにおける組み合わせ最後のトレードの希求アイテム１８を、検索依頼元の提供アイテム１６を始点として入手可能なアイテムの候補すなわち希求アイテムの候補として求めることとなる。

トレード選択制御部２４０は、プレーヤに一つのトレード要求について、何れか一つのトレードルートを実行対象として選択させるための制御を行う。
本実施形態ではトレードルート検索部２３０による検索結果に基づいて、トレードルートデータ５５０を生成する制御と、検索結果をプレーヤ端末１５００にてトレードルート選択画面Ｗ４（図５）を表示させるための制御を行う。そして、プレーヤ端末１５００にて表示されたトレードルート選択画面Ｗ４のリスト表示部５０で選択操作されたトレードルートのルートＩＤを、実行リクエストとともにサーバシステム１１０へ送信させる。

本実施形態のトレード選択制御部２４０は、第１検索結果出力制御部２４１と、第２検索結果出力制御部２４２と、を含む。
第１検索結果出力制御部２４１は、第１依頼検索部２３１による検索が成功した場合に、検索依頼元の依頼プレーヤが所持する何れのアイテムを提供アイテムとしたトレードルートが検索されたかを含む検索結果を出力制御する。
第２検索結果出力制御部２４２は、第２依頼検索部２３２による検索が成功した場合に、検索されたトレードルート、すなわち検索依頼元の提供アイテム１６を始点として入手可能な希求アイテムの候補を出力制御する。

対価処理部２４８は、トレードルートの検索の実行、及び／又はプレーヤにより選択されたトレードルートを構成するトレードの実行に対する対価を課す処理をする。公知の課金処理にて実現するとしても良いし、プレーヤが所持する所定アイテムの消費により実現するとしてもよい。なお、トレードの実行に対する対価については、そのトレードルートを構成するトレードの数が多いほどより対価を大きく設定する。

トレード実行制御部２５０は、プレーヤにより選択されたトレードルートを構成するトレードを実行する。すなわち、トレードルート選択画面Ｗ４のリスト表示部５０で選択操作されたトレードルートのルート構成リスト５５５（図８）に登録されている要求ＩＤの要求登録データ５３２を、当該リストの登録順に実行し、関係するプレーヤの所持アイテムリスト５２２（図１）を変更する。

そして、本実施形態のトレード実行制御部２５０は、救済実行部２５２を有する。
救済実行部２５２は、トレードルートを実行する際に、当該ルート構成するトレード要求の一部に欠損が生じている場合に、この欠損しているトレード要求以外のトレード要求を実行し、実質的にトレードルートの欠損を補完する。

ゲーム進行制御部２６０は、ゲームプレイの進行制御を実行する。本実施形態であればＲＰＧのプレイを実現する。

画像生成部２７２ｓは、サーバシステム１１００の保守に関する画像等を生成し、画像表示部３７２ｓへ出力することができる。

画像表示部３７２ｓは、画像生成部２７２ｓから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１の例ではタッチパネル１１０８が該当する。

通信制御部２７４ｓは、データ通信に係るデータ処理を実行し、通信部３７４ｓを介して外部装置とのデータのやりとりを実現する。

通信部３７４ｓは、通信回線Ｎと接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図１の例では通信装置１１５３が該当する。

なお、本実施形態は、トレード要求の内容（本実施形態ではトレード上限回数１４、提供アイテム１６、希求アイテム１８）を通信接続されたプレーヤ端末１５００から取得する構成なので、通信制御部２７４ｓと通信部３７４ｓとがトレード要求設定部２７８としての機能を果たすことになる。

サーバ記憶部５００ｓは、サーバ処理部２００ｓにサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、サーバ処理部２００ｓが各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１では本体装置１１０１が搭載するＩＣメモリ１１５２やハードディスクなどの記憶媒体、及びストレージ１１４０がこれに該当する。

図１０は、本実施形態におけるサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。サーバ記憶部５００ｓは、サーバシステムプログラム５０１と、アカウント管理プログラム５０３と、ゲーム管理プログラム５０５と、プレーヤ端末１５００へ配信するための配信用ゲームクライアントプログラム５０７とを予め記憶する。また、ゲーム初期設定データ５１０と、ユーザ登録データ５２０と、トレード要求データベース５３０と、ルート管理データ５４０と、検索対象外リスト５６０と、プレイデータ５７０とを記憶する。その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。

サーバシステムプログラム５０１は、サーバ処理部２００ｓが読み出して実行することでサーバシステム１１００にコンピュータとして必要な基本的な入出力機能を実現する為のシステムプログラムである。

アカウント管理プログラム５０３は、サーバ処理部２００ｓが読み出して実行することで、アカウント管理部２０１（図９）としての機能を実現させるためのプログラムである。

ゲーム管理プログラム５０５は、サーバ処理部２００ｓが読み出して実行することで、ゲーム管理部２１０（図９）としての機能を実現させるためのプログラムである。

配信用ゲームクライアントプログラム５０７は、プレーヤ端末１５００へ複製して提供されるゲームクライアントプログラムのオリジナルである。
プレーヤ端末１５００はゲームクライアントプログラムを実行することにより、１）操作入力に応じてサーバシステム１１００へゲームをプレイするための各種リクエスト情報を送信する機能と、２）サーバシステム１１００から受信したデータに基づいて端末上でゲームの進行制御をする機能と、３）ゲーム画面等（例えば，本実施形態では図４のトレード要求設定画面Ｗ２や、図５のトレードルート選択画面Ｗ４）をタッチパネル１５０６に表示させる機能と、を実現できる。
これらの機能は、例えば、専用のプログラムとして実現してもよい。あるいは、本実施形態のゲームをウェブゲームとして実現するならば、ウェブブラウザをベースとしてＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）等を利用して能動的に画面表示を制御するウェブ技術や、Adobe（登録商標） Flashなどのプラグインを用いて実現できる。勿論、その他の方法でもかまわない。

ゲーム初期設定データ５１０は、ゲーム実行に必要な各種初期設定データを格納している。例えば、１）ゲームの舞台となるゲーム空間を構成・表示するための初期設定データ（例えば、仮想３次元空間に配置される背景オブジェクトのモデルデータやテクスチャデータ、配置位置座標等）を格納するステージ初期設定データ５１０ａと、２）ゲームに登場するキャラクタ（例えば、プレーヤキャラクタ４、敵キャラクタ６など）を表示し動作制御するための初期設定データを格納するキャラクタ初期設定データ５１０ｂと、３）アイテム３を表示し、所定の作用効果を発揮させるための各種パラメータ値を格納するアイテム初期設定データ５１０ｃと、を含む。勿論、ゲーム内容に応じてこれら以外の初期設定データも適宜含めることができる。

ユーザ登録データ５２０は、ユーザ登録したプレーヤ毎に用意される。
一つのユーザ登録データ５２０は、アカウント５２１と、所持アイテムリスト５２２と登録済トレード要求ＩＤリスト５２３とを含む。勿論、ゲーム内容に応じてこれら以外のデータも適宜含めることができる。

プレイデータ５７０は、ゲームプレイ毎に用意され、当該ゲームプレイの進行状況を記述する各種データを格納する。

［処理の流れの説明］
図１１〜図１２は、多段階トレードを実現するためのサーバシステム１１００における処理の流れについて説明するためのフローチャートである。
ここで説明する処理の流れは、サーバ処理部２００ｓがサーバシステムプログラム５０１を実行した状態で、アカウント管理プログラム５０３およびゲーム管理プログラム５０５を読み出して実行しており、プレーヤ端末１５００が配信用ゲームクライアントプログラム５０７の複製をダウンロードして実行している状況により実現される。

さて、プレーヤ端末１５００は、サーバシステム１１００へアクセスしてログインした後に所定のトレード要求設定操作が検出されると、サーバシステム１１００へトレード要求設定リクエストを送信する。
サーバシステム１１００は、トレード要求設定リクエストを受信すると（ステップＳ１０のＹＥＳ）、トレード要求設定画面Ｗ２（図４）を表示させる制御、例えば所持アイテムリスト５２２や、アイテムアイコン２１、登録操作アイコン４０等を表示させるためのデータを抽出し、プレーヤ端末１５００へ送信する。

プレーヤ端末１５００は、トレード要求設定画面Ｗ２にてトレード要求の内容が設定操作されたのち登録操作アイコン４０への操作が検出されると、トレード要求データ１０を生成して、登録リクエストとともにサーバシステム１１００へ送信する。なお、提供アイテム１６および希求アイテム１８の両方がワイルドカードに設定されている場合には、登録リクエスト等の送信は行わず、代わりに内容設定のやり直しをプレーヤに要求することとする。

サーバシステム１１００は、登録リクエストとトレード要求データ１０とを受信すると（ステップＳ１４のＹＥＳ）、受信したトレード要求データ１０のトレード上限回数１４に応じた対価処理を実行する（ステップＳ１６）。具体的には、トレード上限回数１４が「１」ならば無料とし、「２」以上ならば上限回数に応じた対価の支払い処理を実行する。勿論、当該ステップを省略した構成も可能である。

次に、サーバシステム１１００は、受信したトレード要求データ１０に基づいて新たな要求登録データ５３２を生成して、トレード要求データベース５３０へ登録する（ステップＳ１８：図３参照）。更に、プレーヤの登録済トレード要求ＩＤリスト５２３へ、生成した要求登録データ５３２の要求ＩＤ５３２ａ（図３）を追加登録し（ステップＳ２０）、新たに生成した要求登録データ５３２に対応するルート管理データ５４０（図８）を生成する（ステップＳ２２）。検索依頼元要求ＩＤ５４１には、新たに生成された要求登録データ５３２の要求ＩＤ５３２ａが設定される。

次に、サーバシステム１１００は、トレード要求データベース５３０に登録されている要求登録データ５３２別にループＡを実行する（ステップＳ３０〜Ｓ４４）。
ループＡでは、処理対象要求登録データに対応するルート管理データ５４０を参照してトレードルートの検索履歴を確認する。そして、ルート管理データ５４０に一つもトレードルートデータ５５０が登録されていない場合、あるいはトレードルートデータ５５０は登録されているがその検索日時５５２（図８）から所定時間が経過している場合には（ステップＳ３２のＹＥＳ）、ルート検索処理を実行する。

具体的には、処理対象要求登録データの提供アイテム１６及び希求アイテム１８の設定に応じて、標準の第１ルート検索処理と、提供アイテム１６が未定の場合の第２ルート検索処理と、希求アイテム１８が未定の場合の第３ルート検索処理とを使い分ける。
より具体的には、処理対象要求登録データの提供アイテム１６としてワイルドカードが設定されている場合には（ステップＳ３４のＹＥＳ）、第２ルート検索処理を実行する（ステップＳ３６）。処理対象要求登録データの希求アイテム１８としてワイルドカードが設定されている場合には（ステップＳ３８のＹＥＳ）、第３ルート検索処理を実行し（ステップＳ４０）、提供アイテム１６と希求アイテム１８の双方ともにアイテム３が設定されていれば（ステップＳ３８のＮＯ）、第１ルート検索処理を実行する（ステップＳ４２）。

図１３は、本実施形態における第１ルート検索処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム１１００は、先ずループＡの処理対象要求登録データの提供アイテム１６を「スタート地点（始点）」に設定し（ステップＳ１０４）、同要求登録データの希求アイテム１８「ゴール地点」に設定する（ステップＳ１０６）。

次いで、検索対象外リスト５６０に登録されておらず、処理対象要求登録データ以外の全ての要求登録データ５３２を抽出し（ステップＳ１１０）、抽出された要求登録データ５３２別に、当該データが定義する提供アイテム１６を「起点」、当該データが定義する希求アイテム１８を「終点」とする「一方通行路」を設定する（ステップＳ１１２）。
そして、当該データが定義するルート上限回数以下の数の一方通行路を使って、スタート地点からゴール地点へ結ぶルートを検索する（ステップＳ１１４）。ルート検索のアルゴリズムは、公知技術を適宜利用することができる。

そして、該当するルートが検索できれば（ステップＳ１２０のＹＥＳ）、サーバシステム１１００は、検索されたルート毎にトレードルートデータ５５０を生成し、処理対象要求登録データに対応するルート管理データ５４０に登録する（ステップＳ１２２）。
この時、トレードルートデータ５５０（図８）には、固有のＩＤを付与されてルートＩＤ５５１に格納される。検索日時５５２には、現在日時を格納する。所要トレード回数５５３には使用した一方通行路の数を格納する。トレード相手リスト５５４には、使用した一方通行路の依頼プレーヤアカウント５３２ｂ（図３）を一方通行路の使用順に格納する。ルート構成リスト５５５には、使用した一方通行路の要求ＩＤ５３２ａ（図３）を一方通行路の使用順に格納する。

次いで、サーバシステム１１００は、生成した各トレードルートデータ５５０のルート構成リスト５５５に格納されている要求ＩＤ５３２ａを検索対象外リスト５６０に格納する（ステップＳ１２４）。そして、生成した各トレードルートデータ５５０を、ループＡの処理対象要求登録データの依頼プレーヤのプレーヤ端末１５００へ送信し、当該端末にてトレードルート選択画面Ｗ４（図５）を表示させ（ステップＳ１２６）、第１ルート検索処理を終了する。

図１４は、本実施形態における第２ルート検索処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム１１００は、先ずループＡの処理対象要求登録データの依頼プレーヤアカウント５３２ｂを参照し、依頼プレーヤの所持アイテムリスト５２２に登録されている各アイテム３（図１）をそれぞれ別々の「スタート地点（始点）」に設定し（ステップＳ２０４）、同要求登録データの希求アイテム１８「ゴール地点」に設定する（ステップＳ２０６）。

次いで、検索対象外リスト５６０に登録されておらず、処理対象要求登録データ以外の全ての要求登録データ５３２を抽出し（ステップＳ２１０）、抽出された要求登録データ５３２別に、当該データが定義する提供アイテム１６を「起点」、当該データが定義する希求アイテム１８を「終点」とする「通行路」を設定する（ステップＳ２１２）。
そして、当該データが定義するルート上限回数以下の数の通行路を使って、ゴール地点から何れかのスタート地点へ逆方向に結ぶルートを検索する（ステップＳ２１４）。ルート検索のアルゴリズムは、公知技術を適宜利用することができる。

そして、該当するルートが検索できれば（ステップＳ２２０のＹＥＳ）、サーバシステム１１００は、検索されたルート毎にトレードルートデータ５５０を生成し、処理対象要求登録データに対応するルート管理データ５４０に登録する（ステップＳ２２２）。次いで、サーバシステム１１００は、生成した各トレードルートデータ５５０のルート構成リスト５５５に格納されている要求ＩＤ５３２ａを検索対象外リスト５６０に格納する（ステップＳ２２４）。

次いで、サーバシステム１１００は、生成した各トレードルートデータ５５０を、ループＡの処理対象要求登録データの依頼プレーヤのプレーヤ端末１５００へ送信し、当該端末にてトレードルート選択画面Ｗ４（図５）を表示させ（ステップＳ２２６）、第２ルート検索処理を終了する。

図１５は、本実施形態における第３ルート検索処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム１１００は、先ずループＡの処理対象要求登録データの提供アイテム１６を「スタート地点（始点）」に設定する（ステップＳ３０６）。
次いで、検索対象外リスト５６０に登録されておらず、処理対象要求登録データ以外の全ての要求登録データ５３２を抽出し（ステップＳ３１０）、抽出された要求登録データ５３２別に、当該データが定義する提供アイテム１６を「起点」、当該データが定義する希求アイテム１８を「終点」とする「通行路」を設定する（ステップＳ３１２）。そして、サーバシステム１１００は、スタート地点から当該データが定義するルート上限回数以下の数の通行路を結んで到達し得る全てのルートを検索する（ステップＳ３１４）。

該当するルートが検索できれば（ステップＳ３２０のＹＥＳ）、サーバシステム１１００は、検索されたルート毎にトレードルートデータ５５０を生成して処理対象要求登録データに対応するルート管理データ５４０に登録する（ステップＳ３２２）。そして、サーバシステム１１００は、生成した各トレードルートデータ５５０のルート構成リスト５５５に格納されている要求ＩＤ５３２ａを検索対象外リスト５６０に格納する（ステップＳ３２４）。

次に、サーバシステム１１００は、生成した各トレードルートデータ５５０を、ループＡの処理対象要求登録データの依頼プレーヤのプレーヤ端末１５００へ送信し、当該端末にてトレードルート選択画面Ｗ４（図５）を表示させ（ステップＳ３２６）、第３ルート検索処理を終了する。

図１２のフローチャートに移って、プレーヤ端末１５００はトレード要求設定画面Ｗ２（図４）にて登録抹消操作アイコン４２の操作を検出すると、サーバシステム１１００へ登録済トレード要求の抹消リクエストを送信する。
サーバシステム１１００は当該リクエストを受信すると（ステップＳ４００のＹＥＳ）、プレーヤ端末１５００にて登録済みのトレード要求の選択画面を表示させるためのデータを送信する（ステップＳ４０２）。具体的には、登録済トレード要求の抹消リクエストを発信したプレーヤ端末１５００を使っているプレーヤの登録済トレード要求ＩＤリスト５２３（図１０）を読み出して送信する。

プレーヤ端末１５００は、これを受信して登録済みのトレード要求の選択画面を表示することができる。そして、当該画面にてプレーヤが抹消対象の選択と、所定の抹消実行操作との入力が検出されると、プレーヤ端末１５００は選択された抹消された登録済みルート要求の要求ＩＤをサーバシステム１１００へ送信する。
サーバシステム１１００はこれを受信し、受信した要求ＩＤに対応する要求登録データ５３２およびルート管理データ５４０を抹消する（ステップＳ４０４）。そして、抹消リクエストを発信したプレーヤ端末１５００のプレーヤの登録済トレード要求ＩＤリスト５２３から受信した要求ＩＤを削除する（ステップＳ４０６）。

次に、サーバシステム１１００は、全てのルート管理データ５４０の中から検索日時５５２（図８）から所定期間が経過しているトレードルートデータ５５０を抽出し（ステップＳ４２０）、抽出されたトレードルートデータ５５０のルート構成リスト５５５に登録されている要求ＩＤを、検索対象外リスト５６０から除外する（ステップＳ４２２）。つまり、仮押さえ状態を解除する。

プレーヤ端末１５００は、トレードルート選択画面Ｗ４のリスト表示部５０に表示された何れかのトレードルートの選択操作とトレード許諾アイコン５６への操作とを検出すると、サーバシステム１１００へトレードの実行リクエストと、選択されたトレードルートのルートＩＤとを送信する。
サーバシステム１１００は、それらを受信すると（ステップＳ２２０のＹＥＳ）、受信したルートＩＤのトレードルートデータ５５０の所要トレード回数５５３（図８）に応じた対価処理を実行する（ステップＳ４３２）。例えば、所要トレード回数５５３が「２」以下ならば無料、それ以上なら回数に比例する対価の支払い処理をする。勿論、当該ステップを省略する構成も可能である。

次に、サーバシステム１１００は、受信したルートＩＤの示すトレードルートを実行、すなわちトレードルートを構成する各トレードを実行する（ステップＳ４３４）。
具体的には、受信したルートＩＤの示すトレードルートデータ５５０を参照し、ルート構成リスト５５５に登録されている要求ＩＤに対応する要求登録データ５３２毎に、依頼プレーヤアカウント５３２ｂ（図３）のプレーヤの所持アイテムリスト５２２（図１）から、提供アイテムＩＤ５３２ｃが示す提供アイテム１６を削除し、代わりに希求アイテムＩＤ５３２ｄが示す希求アイテム１８を登録する。勿論、当該ステップを実行するタイミングで、当該トレードルートを構成しているが、既にトレードが成立してデータベースから抹消された要求登録データ５３２については、処理の対象外となる。すなわち、他トレードルートのトレード実行の前後関係により仮にルートの欠損が生じたとしても、サーバシステム１１００が肩代わりして問題無く関係するトレードを実現し、救済することができる。

次に、サーバシステム１１００は、実行されたトレードに対応する要求ＩＤを検索対象外リスト５６０（図１０）と、登録済トレード要求ＩＤリスト５２３（図１０）から消去する（ステップＳ４３６）。

そして、実行されたトレードの依頼プレーヤアカウント５３２ｂのプレーヤに向けて登録されていたトレードが成立・完了した旨を通知する制御をし（ステップＳ４３８）、実行したトレードルートを格納するルート管理データ５４０と、実行したトレードに対応する要求登録データ５３２と、を消去する（ステップＳ４４０）。
サーバシステム１１００はステップＳ１０に戻り、処理を繰り返す。

このように、本実施形態によれば、複数のアイテム交換を組み合わせることで実現される多段階交換（多段階トレード）をより簡単に利用できるようになる。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、上記に限定されるものではなく適宜構成要素の追加・省略・変更を施すことができる。

［その１］
例えば、上記実施形態ではゲームとしてＲＰＧを例示したが、ゲーム内でアイテム３に相当する設定があるならばその他のジャンルのゲームでもよい。例えば、レースゲームであれば、レーシングカーの強化パーツや、強化燃料、外装パターン、走行できるコースのプレイ権や、チャンピオンシップへの参加券、などをアイテムとして設定すれば良い。また、育成ゲームであれば、生育用具、エサ、栄養、生育場所の増加権、などをアイテムとして設定すればよい。同様にして、スポーツゲームや、パズルゲーム、アクションゲーム、シューティングゲームにも適用できる。

［その２］
また、ゲーム管理部２１０が有する一部の機能をプレーヤ端末１５００で実現する構成も可能である。例えば、ゲーム進行制御部２６０（図９）をプレーヤ端末１５００にて実現する構成が可能である。

［その３］
また、上記実施形態ではトレード上限回数はプレーヤが任意に設定可能な構成としたが、上限回数の最大値を適宜制限する構成も可能である。
例えば、ユーザ登録データ５２０（図１０）が格納するデータとして、プレーヤの技量（プレーヤレベル、ランキングの順位など）や、ログイン累積回数、ログイン頻度、プレイ累積時間、課金頻度、課金累計額、プレーヤキャラクタのレベルやランク、などを含める構成とする。そして、トレード要求設定制御部２２０が、これらのパラメータが高い値であるほどトレード上限回数として設定できる最大値が大きくなるように設定・適用する。

［その４］
また、上記実施形態では、プレーヤ個人個人によるアイテムのトレードを例に挙げたが、チーム間でのアイテムトレードにも同様に適用することができる。その場合、前述のトレード上限回数として設定可能な最大値は、チームメンバー全員または任意抽出されたメンバーのパラメータ値に基づいて設定すればよい。

２…プレーヤ
３…アイテム
４…プレーヤキャラクタ
６…敵キャラクタ
１０…トレード要求データ
１２…アカウント
１４…トレード上限回数
１６…提供アイテム
１８…希求アイテム
２０…所持アイテム一覧表示
２２…提供アイテム設定欄
２４…希求アイテム設定欄
２８…トレード上限回数設定欄
４０…登録操作アイコン
５０…リスト表示部
５２…ルート詳細表示部
５６…トレード許諾アイコン
２００ｓ…サーバ処理部
２１０…ゲーム管理部
２１１…アイテム提供管理部
２１２…所持アイテム管理部
２２０…トレード要求設定制御部
２２１…トレード要求管理部
２２２…仮押さえ状態設定部
２２３…時間経過解除部
２２４…不要トレード解除部
２３０…トレードルート検索部
２３１…第１依頼検索部
２３２…第２依頼検索部
２４０…トレード選択制御部
２４１…第１検索結果出力制御部
２４２…第２検索結果出力制御部
２４８…対価処理部
２５０…トレード実行制御部
２５２…救済実行部
２６０…ゲーム進行制御部
２７８…トレード要求設定部
５００ｓ…サーバ記憶部
５０５…ゲーム管理プログラム
５２０…ユーザ登録データ
５２２…所持アイテムリスト
５２３…登録済トレード要求ＩＤリスト
５３０…トレード要求データベース
５３２…要求登録データ
５３２ｃ…提供アイテムＩＤ
５３２ｄ…希求アイテムＩＤ
５４０…ルート管理データ
５４１…検索依頼元要求ＩＤ
５５０…トレードルートデータ
５５１…ルートＩＤ
５５２…検索日時
５５３…所要トレード回数
５５４…トレード相手リスト
５５５…ルート構成リスト
５６０…検索対象外リスト
５７０…プレイデータ
１１００…サーバシステム
１１４０…ストレージ
１１５０…制御基板
１１５２…ＩＣメモリ
１５００…プレーヤ端末
１５５０…制御基板
Ｗ２…トレード要求設定画面
Ｗ４…トレードルート選択画面

Claims (10)

1. 各プレーヤの所持アイテムを管理する管理手段と、
   前記所持アイテムのうちの当該プレーヤが提供可能な提供アイテムと、当該プレーヤが求める希求アイテムとのトレード要求を記憶するトレード要求記憶手段と、
   特定トレード要求の提供アイテムと希求アイテムとのトレードを、当該提供アイテムを始点として複数のトレード要求を順繰りにトレード実行することで最終的に当該特定トレードの希求アイテムを得ることができる多段階トレードで実現可能な当該多段階トレードを検索する検索手段と、
   前記検索手段により検索された多段階トレードを実行する多段階トレード実行手段と、
   を備えたサーバシステム。
2. 第１の依頼プレーヤの希求アイテムとトレード上限回数とを設定する第１の設定手段を更に備え、
   前記検索手段は、
   前記管理手段により管理されている前記第１の依頼プレーヤの所持アイテムの何れかを提供アイテムとし、前記設定された希求アイテムを得るトレード要求を前記特定トレード要求とした場合に、前記設定されたトレード上限回数までのトレード実行で実現可能な前記多段階トレードを検索する第１の依頼検索手段と、
   前記第１の依頼検索手段による検索が成功した場合に、前記第１の依頼プレーヤの何れを提供アイテムとする多段階トレードが検索されたかを含む検索結果を出力する第１の検索結果出力手段と、
   を有する、
   請求項１に記載のサーバシステム。
3. 前記多段階トレード実行手段は、前記第１の依頼検索手段により検索された多段階トレードのうち、前記第１の依頼プレーヤにより選択された一の多段階トレードを実行する、
   請求項２に記載のサーバシステム。
4. 第２の依頼プレーヤの提供アイテムとトレード上限回数とを設定する第２の設定手段を更に備え、
   前記検索手段は、
   前記第２の設定手段により設定された提供アイテムを始点として、前記第２の設定手段により設定されたトレード上限回数までの前記多段階トレードを実行した場合に得ることができる希求アイテムの候補を検索する第２の依頼検索手段と、
   前記第２の依頼検索手段により検索された希求アイテムの候補を出力する第２の検索結果出力手段と、
   を有する、
   請求項１〜３の何れか一項に記載のサーバシステム。
5. 前記多段階トレード実行手段は、前記第２の依頼検索手段の検索結果に基づいて、前記第２の設定手段により設定された提供アイテムを始点として、検索された希求アイテムの候補のうちの前記第２の依頼プレーヤにより選択された一の希求アイテムを求める多段階トレードを実行する、
   請求項４に記載のサーバシステム。
6. 前記検索手段により検索された多段階トレードに係るトレード要求を仮押さえ状態に設定する仮押さえ状態設定手段と、
   前記仮押さえ状態の設定から所与の時間が経過した設定を解除する時間経過解除手段と、
   を更に備え、
   前記検索手段は、前記仮押さえ状態に設定されていないトレード要求を用いた前記多段階トレードを検索する、
   請求項１〜５の何れか一項に記載のサーバシステム。
7. 前記検索手段により複数の多段階トレードが検索され、且つ、当該複数の多段階トレードのうちの一の多段階トレードが前記多段階トレード実行手段により実行された場合に、残余の多段階トレードに係るトレード要求の前記仮押さえ状態の設定を解除する不用トレード解除手段、
   を更に備えた請求項６に記載のサーバシステム。
8. 前記多段階トレード実行手段は、前記多段階トレードの実行の際に、当該多段階トレードに係るトレード要求が既に実行済みであった場合に、当該トレード要求以外の当該多段階トレードに係るトレード要求を実行することで当該多段階トレードが実行できたとみなす救済実行手段を有する、
   請求項１〜７の何れか一項に記載のサーバシステム。
9. 前記検索手段による検索、及び／又は、前記多段階トレード実行手段による実行に、所与の対価を課す対価処理手段、
   を更に備えた請求項１〜８の何れか一項に記載のサーバシステム。
10. 前記対価処理手段は、少なくとも前記多段階トレード実行手段による実行に対価を課し、実行する多段階トレードに係るトレード要求の数に従って対価を変更する、
    請求項９に記載のサーバシステム。

Images