JP6972272B2 - サーバシステム及びプログラム - Google Patents

Description

本発明は、課金要素を含むゲームの実行に当たり、ユーザのマッチングを行うサーバシステム等に関する。

定員数のプレーヤ（登録ユーザ）が同時に参加してプレイするマルチプレイオンラインゲームでは、参加を希望するユーザの中から定員を自動で組み合わせるいわゆるマッチングが行われるのが一般的である（例えば、特許文献１を参照）。

また、近年のオンラインゲームに係る収益構造においては広告や課金要素がつきものである。課金要素については、例えばゲームプレイの対価や、アイテムの購入、有料抽選などがそれにあたる。そして、課金要素の支払方法としては、クレジットカードによる電子決済による支払い、予めユーザがそれらの電子決済等を経て購入した仮想通貨やアイテムを原資としてそこから支払う方法などがある。課金要素の利用履歴をプレーヤの識別情報（例えば、ユーザアカウント）と紐づけて管理し、広告表示の制御に利用する技術も知られるところである（例えば、特許文献２を参照）。

特開２０１５−１６３２６２号公報 特開２０１５−８９８８号公報

近年、課金にまつわる問題が指摘されるところである。例えば、欲しいアイテムが得られるまで延々と有料抽選を繰り返し実行して過度に大きな課金をしてしまうユーザが存在するといった問題がその１つである。こうした問題に対応する単純な対策としては、例えば月当たりの課金額（課金要素の利用合計、原資の消費合計）に上限を設定し、課金上限閾値に到達して以降は課金要素（例えば有料抽選）などを実行不可能にしてしまう方策が考えられる。

しかし、その場合、課金上限閾値に到達したユーザ（以降「閾値到達ユーザ」と言う。）は、翌月になるまで課金要素に係るゲームの興趣（例えば、有料抽選によって得られるスペシャルレアリティのアイテム収集や、有料アイテムを利用することによる高度な能力・パワーを駆使したゲームプレイなど）を楽しめなくなる。閾値到達ユーザにしてみれば「こんなにお金を使ったのにこれ以上楽しめない」「こんなにもお金を使ったのにその分の満足感が得られない」といった不満を抱き得る。そうすると、閾値到達ユーザのゲーム離れが心配されるところである。

また、閾値到達ユーザは、沢山のアイテムを保有し、高額で強力なアイテムをプレーヤキャラクタに装備させている可能性が高かったり、ゲームに習熟しておりプレーヤレベルが高く設定されている可能性が高い。一方で、課金上限閾値に到達していないユーザ（以降「閾値未達ユーザ」と言う。）は、それほどアイテムを購入していないので、保有アイテムも少なく、無料で入手可能な比較的能力の低いアイテムしかプレーヤキャラクタに装備させていないケースが多い。閾値未達ユーザは、ゲームに習熟しきれていないユーザである場合が多いとも言える。

当然のことながら、閾値到達ユーザと閾値未達ユーザとではプレイスタイルも異なり、同じゲームステージをプレイするとしても進行度合が異なる。よって、単に参加希望しているからといって両者をランダムにマッチングすると、プレイスタイルの違いにより両者にとって好ましくない状況が起こり得る。例えば、閾値到達ユーザからすれば、閾値未達ユーザは貧弱な装備で脚を引っ張るだけの存在に見えるかもしれない。逆に、閾値未達ユーザからすれば、金にモノを言わせて自分だけ有利にゲームを進める好感の持てない存在に見えるかもしれない。そして、こうした状況は、ゲームプレイの満足感を損なう要素として、できるだけ排除したいところである。

本発明は、課金要素を有するマルチプレイゲームにおいて、ユーザとして閾値到達ユーザと閾値未達ユーザとが存在する場合の新たなマッチング技術を提供するために考案されたものである。

上述した課題を解決するための第１の発明は、課金要素を含むゲームの実行に当たり、ユーザのマッチングを行うサーバシステムであって、
ユーザ毎の前記課金要素に係る課金を管理する課金管理手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ユーザ管理部２０２、課金履歴管理部２０４、図１２の保有原資管理データ６０３）と、
ユーザ毎に、課金の会計締め切り日時（以下単に「会計締め日」という）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が所与の閾値に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定する判定手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ユーザ管理部２０２、判定部２０６、図１３のマッチング待機リスト６３０、閾値到達判定結果６３５、図１６のステップＳ６）と、
前記閾値到達ユーザに対して、前記課金要素の使用を制限する課金制限手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ユーザ管理部２０２、課金制限部２０８）と、
前記マッチングを希望するユーザが前記閾値到達ユーザであるか前記閾値未達ユーザであるかに基づくマッチングを行うマッチング手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ゲーム管理部２２０、マッチング部２２２、図１６のステップＳ８〜Ｓ２６）と、を備えたサーバシステムである。

また、第２の発明は、前記マッチング手段が、前記閾値到達ユーザ同士、又は、前記閾値未達ユーザ同士を優先的にマッチングさせる、第１の発明のサーバシステムである。

第１又は第２の発明によれば、マッチングを希望するユーザが閾値到達ユーザであるか閾値未達ユーザであるかを判定し、その結果に応じてマッチングを調整できる。よって、課金要素を有するマルチプレイゲームにおいて、閾値到達ユーザが課金要素を利用できない状態でもゲームプレイへのモチベーションを維持し易くし、閾値未達ユーザと閾値未達ユーザとの好ましくないマッチングを出来る限り抑止することができる。

第３の発明は、前記マッチング手段が、前記閾値到達ユーザ同士、又は、前記閾値未達ユーザ同士のマッチングが成立しない場合に、前記閾値到達ユーザと前記閾値未達ユーザとを混合したヘテロマッチングを行う、第２の発明のサーバシステムである。

第３の発明によれば、どうしても閾値到達ユーザのみ、又は閾値未達ユーザのみでマッチングが成立しない場合には、マッチングを希望するユーザを長々と待たせなくて済む。

但し、発明の主旨として、閾値未達ユーザと閾値未達ユーザとがマッチングされたことにより生じる好ましくない状況をできるだけ回避するようにマッチングを調整するのが好適である。

具体的には、第４の発明として、前記マッチング手段が、前記ヘテロマッチングを行う場合、マッチングされる前記閾値到達ユーザの数が、前記閾値未達ユーザの数以下となるようにマッチングする、第３の発明のサーバシステムを構成すると好適である。

また、やむを得ない処置とはいえあえてヘテロマッチングをするので、閾値到達ユーザに向けて何らかの特典を設けると好適である。

具体的には、第５の発明として、前記マッチングが前記ヘテロマッチングであるか否かに応じて、前記マッチングされたゲームによって前記閾値到達ユーザが獲得可能な成果を変更するゲーム成果変更手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ゲーム管理部２２０、ゲーム成果変更部２２７、図１８のステップＳ１０４〜Ｓ１１６）、を更に備える第３又は第４の発明のサーバシステムを構成すると好適である。

更に、閾値到達ユーザがそれ以上課金要素を利用できない点に着目した特典を付与し得ることとすると、閾値到達ユーザが課金要素を利用できない状態でもゲームプレイへのモチベーションを維持し易くできるので好適である。

具体的には、第６の発明として、前記ゲーム成果変更手段は、前記ヘテロマッチングである場合に、前記閾値到達ユーザが獲得可能な成果を、前記課金要素で取得可能なアイテムとする、第５の発明のサーバシステムを構成すると好適である。

また、第７の発明として、前記ゲーム成果変更手段は、前記成果をパラメータ値とし、前記ヘテロマッチングである場合に、前記ヘテロマッチングでない場合に比べて、多くのパラメータ値を前記閾値到達ユーザが獲得可能とする、第５の発明のサーバシステムを構成するとしてもよいだろう。

もし、対戦ゲームとしてデザインする場合には、戦利品を敗者から獲得する要素を追加すると、閾値到達ユーザが課金要素を利用できない状態でもゲームプレイへのモチベーションを維持し易くできるので好適である。

具体的には、第８の発明として、前記ゲームは対戦ゲームであり、前記ヘテロマッチングによる前記ゲームの結果、閾値到達ユーザが勝者となり、閾値未達ユーザが敗者となった場合に、当該敗者である閾値未達ユーザが所有するアイテムの中から、前記課金要素で入手可能なアイテムを当該勝者である閾値到達ユーザへ戦利品として付与する戦利品付与手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ゲーム管理部２２０、ゲーム成果変更部２２７、図１８のステップＳ１０４〜Ｓ１１６）、を更に備えた第３〜第７の何れかの発明のサーバシステムを構成すると好適である。

また、ヘテロマッチング時における閾値到達ユーザと閾値未達ユーザとの人数構成を適宜変更可能な仕組みを導入してもよい。

具体的には、第９の発明として、前記マッチングは、３人以上のユーザのマッチングであり、前記マッチング手段は、前記ヘテロマッチングにおいて、前記閾値到達ユーザと前記閾値未達ユーザとの混合比率を変更する混合比率変更手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ゲーム管理部２２０、マッチング部２２２，混合比率変更部２２３、図１６のステップＳ２２）、を有する、第３〜第８の何れかの発明のサーバシステムを構成すると好適である。

より好ましくは、第１０の発明として、前記混合比率変更手段は、マッチングするユーザのレベルに応じて前記混合比率を変更する、第９の発明のサーバシステムを構成するとよい。

例えば、レベルの高い閾値到達ユーザを多数、レベルの低い閾値未達ユーザを少数とすると、閾値未達ユーザが閾値到達ユーザのパワープレイに置いて行かれて萎縮する可能性が高い。しかし、逆にレベルの低い多数の閾値未達ユーザの中に、極少数（例えば、一人）のレベルの高い閾値到達ユーザを混合させると、閾値到達ユーザのパワープレイが良い刺激・参考となる。

そして、ヘテロマッチングが成立した場合には、マッチングされたユーザ内に閾値到達ユーザと閾値未達ユーザとが混在していることをプレイ開始前に通知することで、双方にプレイスタイルの違いが生じる可能性を予告し、心構えさせることができるので好適である。

具体的には、第１１の発明として、前記ヘテロマッチングがなされた場合に、当該マッチングされたユーザに、当該マッチングがヘテロマッチングである旨を報知するマッチング識別報知手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ゲーム管理部２２０、マッチング識別情報報知制御部２２４、図１６のステップＳ３４）、を更に備えた第３〜第１０の何れかの発明のサーバシステムを構成すると好適である。

また、やむを得ない処置とはいえあえてヘテロマッチングをするので、閾値未達ユーザに向けても何らかの特典を付与することとしてもよい。

具体的には、第１２の発明として、前記マッチング手段によりマッチングされたユーザの中に前記閾値到達ユーザが含まれている場合に、前記閾値到達ユーザが含まれていることを選択条件とするステージを、当該マッチングされたユーザがプレイするステージとして選択するステージ選択手段（例えば、図１の制御基板１１５０、図９のサーバ処理部２００ｓ、ゲーム管理部２２０、ステージ選択制御部２２５、図１７のステップＳ６２〜Ｓ６６）、を更に備えた第１〜第１１の何れかの発明のサーバシステムを構成すると好適である。

第１３の発明は、課金要素を含むゲームの実行に当たり、ユーザのマッチングを行うコンピュータシステムを、ユーザ毎の前記課金要素に係る課金を管理する課金管理手段（例えば、図９のサーバ処理部２００ｓ、ユーザ管理部２０２、課金履歴管理部２０４、図１２の保有原資管理データ６０３）、
ユーザ毎に、課金の会計締め切り日時（以下単に「会計締め日」という）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が所与の閾値に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定する判定手段（例えば、図９のサーバ処理部２００ｓ、ユーザ管理部２０２、判定部２０６、図１３のマッチング待機リスト６３０、閾値到達判定結果６３５、図１６のステップＳ６）、
前記閾値到達ユーザに対して、前記課金要素の使用を制限する課金制限手段（例えば、図９のサーバ処理部２００ｓ、ユーザ管理部２０２、課金制限部２０８）、
前記マッチングを希望するユーザが前記閾値到達ユーザであるか前記閾値未達ユーザであるかに基づくマッチングを行うマッチング手段（例えば、図９のサーバ処理部２００ｓ、ゲーム管理部２２０、マッチング部２２２、図１６のステップＳ８〜Ｓ２６）、として機能させるためのプログラムである。

第１３の発明によれば、ユーザのマッチングを行うコンピュータシステムに、第１の発明と同様の作用効果を発揮させることができる。

ゲームシステムの構成の一例を示す図。 ユーザ端末の構成例を示す正面図。 ゲームの概要を説明するための図。 閾値到達ユーザのみによるホモマッチングについて説明するとともに、当該ホモマッチング時に表示されるマッチング識別情報報知画面の例を示す図。 閾値未達ユーザのみによるホモマッチングについて説明するとともに、当該ホモマッチング時に表示されるマッチング識別情報報知画面の例を示す図。 ヘテロマッチングについて説明するとともに、閾値未達ユーザのユーザ端末にて表示されるマッチング識別情報報知画面の例を示す図。 ヘテロマッチングされた閾値到達ユーザのユーザ端末にて表示されるマッチング識別情報報知画面の例を示す図。 ヘテロマッチングされた場合のボーナスアイテムの分配について説明するための図。 サーバシステムの機能構成例を示す機能ブロック図。 サーバ記憶部が記憶するプログラムやデータの例を示す図。 ゲームステージ初期設定データのデータ構成例を示す図。 ユーザ管理データのデータ構成例を示す図 マッチング待機リストのデータ構成例を示す図。 プレイデータのデータ構成例を示す図。 ユーザ端末の機能構成例を示す機能ブロック図。 マッチング処理の流れを説明するためのフローチャート。 ゲーム実行処理の流れを説明するためのフローチャート。 図１７よりつづくフローチャート。 ゲーム実行処理の流れの変形例を説明するためのフローチャートであって、図１８に相当する部分のフローチャート。

以下、本発明を適用した実施形態の一例を説明するが、本発明を適用可能な形態が以下の実施形態に限られないことは勿論である。

本実施形態の例として、「課金要素」を含むゲームであって、アクションＲＰＧタイプのマルチプレイオンラインゲームを実行する場合の例を説明する。

「課金要素」とは、ゲームプレイに利用可能な「プレイ媒体」等を原資とし、ユーザが対価の支払いを承認することにより対価分のプレイ媒体が原資から消費されて、対象の商品又は役務が得られる仕組みである。プレイ媒体としては、現金、クレジット、仮想通貨、或いはこれらで購入可能なゲーム内ポイントやアイテム等とすることができる。

課金要素のより具体的な例を挙げると、特別なイベントやゲームステージのプレイ対価の支払い、希少なアイテム（ゲームオブジェクト）が景品に含まれる有料抽選（有料の合成要素の一例）の実行対価の支払い、プレーヤキャラクタとして利用可能なキャラクタやアイテムといったゲームオブジェクトの購入対価の支払い、などがこれに該当する。

図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステム１０００は、通信回線９に接続することで相互にデータ通信が可能なサーバシステム１１００と、単数又は複数のユーザ端末１５００（１５００ａ，１５００ｂ，…）とを含むコンピュータシステムである。

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

サーバシステム１１００は、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを有し、本体装置１１０１には制御基板１１５０を搭載するコンピュータシステムである。

制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。なお、制御基板１１５０の一部又は全部は、ＡＳＩＣ（Application Specific Integrated Circuit）や、ＦＰＧＡ（field-programmable gate array）、ＳｏＣ（System on a Chip）により実現するとしてもよい。

そして、サーバシステム１１００は、制御基板１１５０が所定のプログラム及びデータに基づいて演算処理することにより、１）ユーザ登録等に係るユーザ管理機能と、２）プレーヤであるユーザ２（２ａ，２ｂ，…）がユーザ端末１５００（１５００ａ，１５００ｂ，…）でゲームプレイするのに必要なデータを提供してユーザ端末１５００（１５００ａ，１５００ｂ，…）でのゲームの実行制御を管理するゲーム管理機能と、３）ゲームで利用可能な様々なアイテムをオンラインでユーザに販売するオンラインショッピング機能と、を実現する。つまり、本実施形態におけるゲームは、一種のクライアント・サーバ型のオンラインゲームとして実現される。

なお、サーバシステム１１００は単体として記しているが、各機能を分担する複数のブレードサーバを搭載して相互に内部バスを介してデータ通信可能に接続した構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを、通信回線９を介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

ユーザ端末１５００（１５００ａ，１５００ｂ，…）は、プレーヤであるユーザ２（２ａ，２ｂ，…）がゲームプレイのために個別に使用するコンピュータシステムであって、通信回線９を介してサーバシステム１１００にアクセスしてオンラインゲームを実行できる電子装置（電子機器）である。本実施形態のユーザ端末１５００は、いわゆるスマートフォンと呼ばれる装置であるが、携帯型ゲーム装置や、ゲームコントローラ、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータ、業務用ゲーム装置などでもよい。

図２は、本実施形態におけるユーザ端末１５００の構成例を示す正面図である。
ユーザ端末１５００は、方向入力キー１５０２と、ボタンスイッチ１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、内蔵バッテリー１５０９と、マイク１５１２と、制御基板１５５０と、コンピュータ読み出し可能な記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない電源ボタン、音量調節ボタン等が設けられている。また、ゲームプレイの対価の支払いが可能なＩＣカード型のクレジットカードやプリペイドカードに対して非接触にデータの読み書きが行えるＩＣカード読取装置などを設けるとしてもよい。

制御基板１５５０は、ＣＰＵ１５５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサ、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２、通信回線９に接続する携帯電話基地局や無線ＬＡＮ基地局などと無線通信するための無線通信モジュール１５５３、インターフェース回路１５５７などを搭載する。

インターフェース回路１５５７には、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びボタンスイッチ１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置１５４２への信号入出力回路、などが含まれている。

制御基板１５５０に搭載されているこれらの要素は、バス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。なお、制御基板１５５０の一部又は全部をＡＳＩＣやＦＰＧＡ、ＳｏＣにて構成してもよい。そして、制御基板１５５０は、本実施形態のゲームのユーザ端末としての機能を実現させるためのプログラムや各種データをＩＣメモリ１５５２に記憶する。

なお、本実施形態では、ユーザ端末１５００はクライアントプログラムや各種設定データをサーバシステム１１００からダウンロードする構成としているが、別途入手したメモリカード１５４０などの記憶媒体から読み出す構成としても良い。

［ゲームの説明］
本実施形態のゲームは、プレーヤである各ユーザ２（２ａ，２ｂ，…）がプレーヤキャラクタ４（４ａ，４ｂ…）を使用して協力プレイするマルチプレイ対応のステージクリア型アクションＲＰＧである。勿論、シングルプレイでゲームプレイをすることもできる。図１の例では、第１のユーザ２ａが第１のプレーヤキャラクタ４ａを操作し、第２のユーザ２ｂが第２のプレーヤキャラクタ４ｂを操作し、第３のユーザ２ｃが第２のプレーヤキャラクタ４ｃを操作する、ことを示している。

図３は、本実施形態におけるゲームの概要を説明するための図である。
ゲーム画面Ｗ２は、ユーザ端末１５００のタッチパネル１５０６に表示され、プレーヤであるユーザ２は、タッチパネル１５０６への各種のタッチ操作をしてプレイする。本実施形態のゲーム画面Ｗ２には、主表示部２１と、購入操作アイコン２２と、有料抽選操作アイコン２４と、アイテム使用操作アイコン２６と、装備変更操作アイコン２８とを有する。勿論、ゲーム内容に応じてこれら以外の内容の操作アイコンやタブ、メニュー表示なども適宜ゲーム画面Ｗ２に表示させることができる。

主表示部２１では、プレーヤキャラクタ４（４ａ、４ｂ、…）が敵キャラクタ６と闘う様子が表示される。

プレーヤキャラクタ４（４ａ、４ｂ、…）は、プレーヤのゲーム世界における分身であり、各種アイテム７（７ａ，７ｂ，…）を装備させることで攻撃力や防御力を高めることができる。

アイテム７は、ゲームで使用可能なゲームオブジェクトであって様々な種類が用意されている。アイテム７には、レアリティ（希少度・レア度）が設定されており、レアリティが高いほどより高い能力が設定されており、レアリティが高いアイテムをプレーヤキャラクタ４に装備させる或いは使用させることでプレーヤは有利にゲームを進めることができる。アイテム７は、敵キャラクタ６によるドロップや、アイテム購入（本実施形態における課金要素の１つ）により入手できる。

プレーヤキャラクタ４（４ａ，４ｂ，…）は、ゲーム進行の成果に応じて能力が変化する。能力は、経験値や、当該キャラクタの成長の度合を示すレベル、攻撃力、防御力、移動力、回復力、スキルなどに代表されるパラメータで管理される。勿論、これら以外のパラメータも適宜含めることができる。そして、プレーヤキャラクタ４（４ａ，４ｂ，…）にアイテム７を装備・使用すると、アイテム７の効果設定に応じてそれらのパラメータの値が向上される。

購入操作アイコン２２は、ゲームプレイ中にオンラインショッピング（本実施形態の課金要素の１つ）を利用してアイテム７等のゲームオブジェクトを購入する操作を入力するためのアイコンである。

有料抽選操作アイコン２４は、有料抽選（本実施形態の課金要素の１つ）の実行操作を入力するためのアイコンである。本実施形態の有料抽選は、オンラインショッピングでは購入できないようなレアイティの高いアイテム７が景品に含まれる特別な抽選とされる。

アイテム使用操作アイコン２６は、プレーヤであるユーザ２が保有しているアイテムの使用操作を入力するためのアイコンである。

装備変更操作アイコン２８は、プレーヤキャラクタ４に装備させる、或いは使用させるアイテム７の変更操作を入力するためのアイコンである。

なお、アイテム購入を初めとする各種課金要素の支払いは、プレーヤであるユーザ２が保有するゲームプレイに利用可能なプレイ媒体原資（以下「保有原資」と言う）の消費により行われる。保有原資は、現金やクレジット、デビットカード、仮想通貨、ショッピングポイントの消費と引き換えにゲーム管理者側から購入できるものであり、購入によって保有原資は増額・チャージされる。例えば、仮想通貨や通貨に相当するアイテム等が保有原資に当たる。

保有原資の残高は、ユーザ２のアカウントに紐付けられてサーバシステム１１００にて管理されている。例えば、ユーザ端末１５００にてプレーヤがアイテム購入操作をして購入の支払い承認操作をすると、サーバシステム１１００へアイテム購入のリクエストが送信される。サーバシステム１１００は、承認された支払い額を保有原資から減額し、購入されたアイテム７をプレーヤへ付与する制御を行う。

図４〜図６は、本実施形態におけるマッチングについて説明するための概念図である。
本実施形態では、ユーザ２（２ａ，２ｂ，…）毎に、課金の会計締め切り日時（以下単に「会計締め日」という）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が課金上限閾値に達した閾値到達ユーザであるか、閾値未達ユーザであるかが判定され、閾値到達ユーザである場合、当該ユーザについては現在の単位会計期間における課金要素の利用が制限される。そして、本実施形態では、この閾値到達ユーザであるか閾値未達ユーザであるかの判定結果を利用してマッチングを行う。

具体的には、先ず第１優先として、図４に示すように、閾値到達ユーザ同士を優先的にマッチングさせる。同種ユーザのマッチングの意味として、これを「ホモマッチング」と呼ぶ。図４の例では、定員４名のマッチングにおいて、マッチング待機中の６人のうち閾値到達ユーザ２ａ，２ｂ，２ｃ，２ｄの４人を優先してホモマッチングさせている。なお、マッチングの定員数は４名に限らず適宜設定可能である。

ホモマッチングされた閾値到達ユーザ２ａ，２ｂ，２ｃ，２ｄのユーザ端末１５００では、マッチング識別情報報知画面Ｗ４が表示される。当該画面では、例えばマッチングされた各ユーザのプレーヤキャラクタ４（４ａ，４ｂ，…）に対応づけて、ユーザ情報表示３０が表示される。

ユーザ情報表示３０は、ユーザアカウントや、ユーザレベル、当該ユーザが閾値到達ユーザであるか閾値未達ユーザであるかの判定結果通知３２を対応づけて表示する。図４の判定結果通知３２の例は、全員について、閾値到達ユーザであることを示す所定の表示体が表示されている。ホモマッチングされた閾値到達ユーザ２ａ，２ｂ，２ｃ，２ｄは、全員のユーザ情報表示３０に閾値到達ユーザであることを示す所定の表示体が表示されていることを視認することで、自分たちがホモマッチングされたことを知ることができる。

閾値到達ユーザ同士でマッチングすることにより、閾値到達ユーザと閾値未達ユーザとを混成してマッチングした場合に心配されるプレイスタイルの違いにより両者にとって好ましくない状況を回避できる。

また、閾値到達ユーザ同士なので、お互いにこれ以上アイテムを購入することはできないことは重々承知しているので、手持ちのアイテムを使っていかにゲームをクリアするか、状況認識が共通している分プレイし易くなる。例えば、強力なアイテムを使ってのパワープレイも、お互い相手に気兼ねなく存分に楽しめる。こうした、マッチングの妙により生まれる新しい楽しさは、翌月になるまで課金要素に係るゲームの興趣を楽しめなくなった閾値到達ユーザにしてみれば新たなゲームプレイへの魅力となるであろう。

次に、マッチングにおける第２優先として、図５に示すように、閾値未達ユーザ同士を優先的にマッチングさせる。これもホモマッチングの一つである。図５の例では、定員４名のマッチングにおいて、マッチング待機中が６人いる。閾値到達ユーザのみではマッチングができないので、閾値未達ユーザ２ｅ，２ｆ，２ｇ，２ｈの４人を優先してマッチングさせている。なお、マッチングの定員数は４名に限らず適宜設定可能である。

マッチングされた閾値未達ユーザ２ｅ，２ｆ，２ｇ，２ｈのユーザ端末１５００では、マッチング識別情報報知画面Ｗ６が表示される。当該画面では、例えばマッチングされた各ユーザのプレーヤキャラクタ４（４ａ，４ｂ，…）に対応づけて、ユーザ情報表示３０が表示される。図５の判定結果通知３２の例は、全員について、閾値未達ユーザであることを示す所定の表示体で表示されている。ホモマッチングされた閾値未達ユーザ２ｅ，２ｆ，２ｇ，２ｈは、全員のユーザ情報表示３０に閾値未達ユーザであることを示す所定の表示体が表示されていることを視認することで、自分たちがホモマッチングされたことを知ることができる。

閾値未達ユーザのみでマッチングすることにより、閾値到達ユーザと閾値未達ユーザとを混成してマッチングした場合に心配されるプレイスタイルの違いにより両者にとって好ましくない状況を回避できる。

また、閾値未達ユーザのみなので、それほどアイテムを保有している可能性は低くなる。そうしたユーザのみで協力プレイすると、アイテムが不足する。そして、やむなく購入に至る可能性が高くなり、課金要素の利用促進が期待できる。事実、ゲームは、適度にアイテム購入をすることにより、想定した１００％の楽しさを味わうことができるように設計されているので、アイテム購入を適度に促すことはゲーム本来の楽しさに誘うことになり、ゲーム運営者とユーザ双方にとって好ましい。

次に、マッチングにおける第３優先として、図６に示すように、ホモマッチングが成立しない場合には、閾値到達ユーザと閾値未達ユーザとを混合させてマッチングさせる。これを「ヘテロマッチング」と呼ぶ。図６の例では、定員４名のマッチングにおいて、マッチング待機中が６人いる。閾値到達ユーザのみ、或いは閾値未達ユーザのみではマッチングができない状況において、マッチング待機状態の継続時間が基準値を超えると、閾値到達ユーザと閾値未達ユーザとを混合させてヘテロマッチングさせる。

但し、ヘテロマッチングを行う場合は、マッチングされる閾値到達ユーザの数が、閾値未達ユーザの数以下となるようにマッチングする。そして、その際の閾値到達ユーザと閾値未達ユーザとの混合比率は、マッチングされる閾値到達ユーザのユーザレベルと、閾値未達ユーザのユーザレベルとに基づいて決定される。具体的には、閾値到達ユーザのユーザレベルと閾値未達ユーザのユーザレベルとのレベル差が大きいほど、閾値到達ユーザの混合比率が小さくなるように設定される。なお、レベルは、対象ユーザが複数の場合はその平均値などの統計値を利用するものとする。

図６の例では、定員４名のマッチングにおいて、マッチング待機中が６人いる。閾値到達ユーザのみ或いは閾値未達ユーザのみではマッチングができないので、閾値到達ユーザ２ａと、閾値未達ユーザ２ｅ，２ｇ，２ｈの３人とでヘテロマッチングさせている。なお、マッチングの定員数は４名に限らず適宜設定可能である。

ヘテロマッチングされたユーザのうち、閾値未達ユーザ２ｅ，２ｇ，２ｈのユーザ端末１５００では、マッチング識別情報報知画面Ｗ８が表示される。当該画面には、閾値未達ユーザ向け特典情報通知３４が追加表示される。

「閾値未達ユーザ向け特典」は、本来、閾値到達ユーザと閾値未達ユーザとがマッチングされた場合に想定される好ましくない状況が起こることに対して何らかの特典を付与する意味で用意されている。当該特典の内容は、ゲーム内容などを考慮して適宜設定可能である。本実施形態では、閾値未達ユーザのみのホモマッチングではプレイできないゲームステージが利用可能になる。換言すると、本来、閾値到達ユーザに限定されるゲーム要素が、マッチングされたパーティにたまたま閾値到達ユーザが居ることで、閾値未達ユーザであっても利用可能になる。

一方、ヘテロマッチングされたユーザのうち、閾値到達ユーザ２ａのユーザ端末１５００には、図７に示すようなヘテロマッチング時の閾値到達ユーザ向けマッチング通知画面Ｗ１０が表示される。当該画面では、プレーヤキャラクタ４と対応づけられたユーザ情報表示３０に加えて、閾値到達ユーザ向け特典情報通知３６が追加表示される。

「閾値到達ユーザ向け特典」は、本来、閾値到達ユーザと閾値未達ユーザとがマッチングされた場合に想定される閾値到達ユーザが抱く不平感や、アイテム購入ができずにプレイしなければならない閾値到達ユーザの不満感などを補償する意味で用意されている。当該特典の内容は、ゲーム内容などを考慮して適宜設定可能である。本実施形態では、図８に示すように、ステージクリア時などで付与されるボーナスアイテム４０（４０ａ，４０ｂ，…）の内、課金要素でしか入手できない種類のボーナスアイテム４０ａを、閾値到達ユーザのプレーヤキャラクタ４ａが優先的に獲得できる。また、ゲーム成績に応じた経験値などの能力パラメータ値の変更においては、閾値到達ユーザのみのホモマッチングで同じゲーム成績を上げた場合よりも、変更量が増加される。

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

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

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

そして、本実施形態のサーバ処理部２００ｓは、ユーザ管理部２０２と、オンラインショッピング管理部２１０と、ゲーム管理部２２０と、計時部２８０ｓと、音生成部２９０ｓと、画像生成部２９２ｓと、通信制御部２９４ｓとを含む。勿論、これら以外の機能部も適宜含めることができる。

ユーザ管理部２０２は、ユーザ登録手続きに係る処理及びアカウント（ユーザＩＤ）に紐付けられるデータの記憶管理を行う。本実施形態では、１）登録ユーザにアカウントの付与を制御するアカウント付与と、２）アカウント別に個人情報を登録管理する登録情報管理と、３）保有原資をアカウントに紐付けて管理する保有原資管理と、４）ログイン／ログアウトの履歴を管理するプレイ履歴管理と、の各機能を有する。勿論、これら以外のアカウントに紐付けられるデータの管理機能も適宜含めることもできる。

そして、本実施形態のユーザ管理部２０２は、課金履歴管理部２０４と、判定部２０６と、課金制限部２０８と、を有する。

課金履歴管理部２０４は、ユーザ毎の課金要素に係る課金履歴（利用履歴）を管理する。

判定部２０６は、ユーザ毎に、課金の会計締め切り日時（本実施形態では会計締め日）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が所与の閾値（本実施形態では上限閾値：課金上限額）に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定する。

課金制限部２０８は、閾値到達ユーザに対して課金要素の使用を制限する制御を行う。

オンラインショッピング管理部２１０は、課金要素のうちオンラインショッピングに関する制御を担う。公知のオンラインショッピング技術を適宜流用できる。

ゲーム管理部２２０は、ゲームの実行管理に係る各種処理を行う。本実施形態のゲームは、クライアント・サーバ型のオンラインゲームなので、本実施形態のゲーム管理部２２０は、ユーザ端末１５００と通信を行いながらゲームプレイに必要なデータを提供する制御を行う。

具体的には、ゲーム管理部２２０は、マッチング部２２２と、マッチング識別情報報知制御部２２４と、ステージ選択制御部２２５と、ゲーム進行制御部２２６と、ゲーム成果変更部２２７と、を有する。勿論、これら以外の機能部も適宜含めることができる。

マッチング部２２２は、マッチングを希望するユーザが閾値到達ユーザであるか閾値未達ユーザであるかに基づくマッチングを行う。
具体的には、マッチング部２２２は、閾値到達ユーザ同士、又は、閾値未達ユーザ同士を優先的にマッチングさせるホモマッチングを行うことができる。また、マッチング部２２２は、閾値到達ユーザ同士、又は、閾値未達ユーザ同士のマッチングが成立しない場合に、閾値到達ユーザと閾値未達ユーザとを混合したヘテロマッチングを行うことができる。

そして、マッチング部２２２は、混合比率変更部２２３を有し、ヘテロマッチングを行う場合には、マッチングされる閾値到達ユーザの数が、閾値未達ユーザの数以下となるように、閾値到達ユーザと閾値未達ユーザとの混合比率をマッチングするユーザのレベルに応じて変更してマッチングすることができる。

マッチング識別情報報知制御部２２４は、ヘテロマッチングがなされた場合に、当該マッチングされたユーザに、当該マッチングがヘテロマッチングである旨を報知する制御を行う。本実施形態では、マッチング識別情報報知画面Ｗ８（図６参照）及びマッチング識別情報報知画面Ｗ１０（図７参照）の表示制御がこれに該当する。

ステージ選択制御部２２５は、マッチングされたユーザの中に閾値到達ユーザが含まれている場合に、閾値到達ユーザが含まれていることを選択条件とするステージを、当該マッチングされたユーザがプレイするステージとして選択受け付けする。換言すると、ステージ選択制御部２２５は、ヘテロマッチングされた閾値未達ユーザ向けに特典を付与する閾値未達ユーザ向けヘテロマッチング特典付与制御部として機能する。

ゲーム進行制御部２２６は、マルチプレイゲームの進行制御に関する処理を実行する。本実施形態では、アクションＲＰＧ（ロールプレイングゲーム）なので、ゲーム管理部２２０は、１）仮想３次元空間に背景等のオブジェクトを配置して、プレイ前に選択されたゲームステージのゲーム空間を形成する処理、２）ゲーム空間にマッチングされたユーザ２のプレーヤキャラクタ４と敵キャラクタ６と仮想カメラとを配置する処理、３）仮想カメラの自動制御処理、４）ユーザ端末１５００における操作入力に応じて各プレーヤキャラクタ４の行動を制御する処理、５）敵キャラクタ６の自動制御処理、６）攻撃のヒット判定とダメージ反映に関する処理、７）ゲーム成績の算出処理、８）仮想カメラで撮影したゲーム空間の画像の生成処理、などを行うことができる。また、これらに伴ってゲームプレイの制御に必要な各種データをサーバ記憶部５００ｓに記憶させることができる。

ゲーム成果変更部２２７は、マッチングタイプがヘテロマッチングであるか否かに応じて、マッチングされたゲームによって閾値到達ユーザが獲得可能な成果を変更制御する。
本実施形態のゲームは協力プレイ型のマルチプレイゲームなので、ゲーム成果変更部２２７は、ヘテロマッチングである場合に、閾値到達ユーザが獲得可能な成果を、課金要素で取得可能なアイテムとする（図８参照）。また、成果をパラメータ値とし、ヘテロマッチングである場合に、ヘテロマッチングでない場合に比べて、多くのパラメータ値を閾値到達ユーザが獲得可能とすることができる。換言すると、ゲーム成果変更部２２７は、戦利品をユーザに付与する戦利品付与部や、ヘテロマッチングされた閾値到達ユーザ向けに特典を付与する閾値到達ユーザ向けヘテロマッチング特典付与制御部として機能する。

計時部２８０ｓは、システムクロックを利用して現在日時や制限時間等の計時を行う。

音生成部２９０ｓは、音声データの生成やデコードをするＩＣやソフトウェアの実行により実現され、サーバシステム１１００のシステム管理やゲームプレイに係る操作音やＢＧＭなどの音声データを生成或いはデコードする。そして、システム管理に関する音声信号は音出力部３９０ｓへ出力する。

音出力部３９０ｓは、音声信号を放音する。図１の例では本体装置１１０１やタッチパネル１１０８が備えるスピーカ（非図示）がこれに該当する。

画像生成部２９２ｓは、サーバシステム１１００のシステム管理に関する画像や、ゲーム画像（又はゲーム画像をユーザ端末１５００で表示させるためのデータ）等を生成することができる。そして、システム管理に関する画像は画像表示部３９２ｓへ出力することができる。

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

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

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

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

図１０は、本実施形態におけるサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。本実施形態におけるサーバ記憶部５００ｓは、サーバシステムプログラム５０１と、サーバプログラム５０３と、配信用ゲームクライアントプログラム５０５と、アイテム販売初期設定データ５１０と、購入専用アイテムリスト５１２と、有料抽選初期設定データ５１４と、有料抽選専用アイテムリスト５１６と、ヘテロマッチング混合比率設定データ５１８と、ゲーム初期設定データ５２０と、を予め記憶する。

また、サーバ記憶部５００ｓは、逐次生成・管理されるデータとして、ユーザ管理データ６００と、マッチング待機リスト６３０と、プレイデータ７００と、現在日時８００と、を記憶する。その他、タイマや、カウンタ、各種フラグなどの情報を適宜記憶できる。

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

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

配信用ゲームクライアントプログラム５０５は、ユーザ端末１５００へ提供されるゲームクライアントプログラムのオリジナルである。

アイテム販売初期設定データ５１０は、本実施形態における課金要素に係る定義データであって、オンラインショッピングにより購入可能なアイテム毎に用意され、当該アイテムを販売するための初期設定を格納する。例えば、固有のアイテムＩＤ（アイテム種類を示す）と、販売対価と、を対応づけて格納する。

そして、本実施形態では、ボーナスアイテムとして付与される以外にオンラインショッピングでのみ購入・入手可能なアイテムが用意されており、そうしたアイテムのアイテムＩＤが、購入専用アイテムリスト５１２にリストアップされている。なお、販売対象には、プレーヤキャラクタ４として使用可能なキャラクタも適宜含めることができる。

有料抽選初期設定データ５１４は、本実施形態における課金要素に係る定義データであって、有料抽選の種類毎に用意され、抽選の内容を定義する各種データを格納する。例えば、有料抽選ＩＤと、抽選対価と、景品アイテムリストと、を格納する。

そして、本実施形態では、ボーナスアイテムとして付与される以外に有料抽選でのみ獲得可能なアイテムが用意されており、そうしたアイテムのアイテムＩＤが、有料抽選専用アイテムリスト５１６にリストアップされている。なお、抽選景品には、プレーヤキャラクタ４として使用可能なキャラクタも適宜含めることができる。

なお、課金要素として、アイテム購入や有料抽選以外の追加課金要素を含む構成では、追加課金要素別に、こうした初期設定データと専用アイテムリストを用意するものとする。

ヘテロマッチング混合比率設定データ５１８は、ヘテロマッチングされるユーザのうち、閾値到達ユーザの人数と閾値未達ユーザの人数との比率を決定するための基礎データである。本実施形態では、マッチングが予定される閾値到達ユーザのユーザレベルの統計値（具体的には、平均値だが、最高値や中央値、最小値などでも可）と、同じくマッチングが予定される閾値未達ユーザのユーザレベルの統計値を変数として、混合比率を導く関数が設定されている。そして、当該関数では、両統計値の差が大きいほど、閾値到達ユーザの人数がより少なくなるように設定されている。なお、ヘテロマッチング混合比率設定データ５１８は、関数でなはなく両統計値の差と混合比率とを対応づけたテーブルデータでもよい。

ゲーム初期設定データ５２０は、ゲーム進行制御に必要な各種初期設定データを格納する。本実施形態では、ゲームステージ初期設定データ５３０と、アイテム初期設定データ５６０と、プレーヤキャラクタ候補初期設定データ５７０と、ＮＰＣ初期設定データ５７２と、を含む。勿論、これら以外のデータも適宜含めることができる。

ゲームステージ初期設定データ５３０は、ゲームステージ毎に用意され、当該ステージに係る各種初期設定データを格納する。
一つのゲームステージ初期設定データ５３０は、例えば図１１に示すように、固有のステージＩＤ５３２と、ステージ選択可能要件５４０と、ゲーム空間初期設定データ５５０と、敵キャラクタ出現初期設定データ５５２と、ドロップアイテムリスト５５４と、ボーナスアイテムリスト５５６と、を含む。勿論、これら以外のデータも適宜含めることができる。

ステージ選択可能要件５４０は、当該ゲームステージをプレイするために満たすべき条件を定義している。例えば、事前にクリアしておくべきゲームステージを定義する要クリアステージリスト５４２と、マルチプレイするユーザのユーザレベルの最低基準を示す最低プレーヤレベル５４４と、当該ステージが閾値到達ユーザ向けであることを示す閾値到達ユーザ専用ステージフラグ５４６と、を格納する。勿論、これら以外のデータも適宜含めることができる。

敵キャラクタ出現初期設定データ５５２は、どの種類の敵キャラクタ６をどのタイミングで出現させるかを定義するデータである。

ドロップアイテムリスト５５４は、当該ゲームステージをプレイする間に、敵キャラクタ６によるドロップは、マップ内での発見等により入手できるアイテムのリストである。

ボーナスアイテムリスト５５６は、当該ゲームステージをクリアした場合や、特定の敵キャラクタ６を攻略した場合などにボーナスとして付与されるアイテムのリストである。

図１０に戻って、プレーヤキャラクタ候補初期設定データ５７０は、ユーザ２が自分のプレーヤキャラクタ４として使用することができるキャラクタの種類毎に用意され、当該キャラクタの各種初期設定データを格納する。例えば、キャラクタ種類、キャラクタモデルデータ、モーションデータ、各種能力パラメータ値（例えば、キャラクタレベル、攻撃力、防御力、移動力、初期スキル、属性など）の初期値などを対応づけて格納する。

ＮＰＣ初期設定データ５７２は、ゲーム中に登場するＮＰＣ（本実施形態では敵キャラクタ６もこれに該当）の種類毎に用意され、当該ＮＰＣの各種初期設定データを格納する。

ユーザ管理データ６００は、登録ユーザ毎に用意され、固有の識別情報であるアカウントと紐付けられる各種データを格納する。本実施形態では、図１２に示すように、１つのユーザ管理データ６００には、固有のアカウント６０１と、課金要素の対価支払いに使用される原資に係る保有原資管理データ６０３と、プレイ履歴データ６０５と、ゲームセーブデータ６１０と、を含む。勿論、これら以外のデータも適宜含めることができる。

保有原資管理データ６０３は、保有原資の収支記録である。例えば、更新日時と、更新事由と、変更量と、保有原資残高と、を対応づけて時系列に格納する。謂わば、帳簿であって、保有原資の購入や配付、支払毎に更新される。

プレイ履歴データ６０５は、過去に何時ゲームプレイしたかを記述するデータを、プレイした時系列に格納するデータであって、ログイン／ログアウトのタイミングで自動的に更新される。

ゲームセーブデータ６１０は、前回のゲームプレイ時までのゲーム進行の状態を記述する各種データを格納する。本実施形態では、過去のゲーム成績に応じて自動的に付与されるユーザレベル６１２と、保有キャラクタ管理データ６１４と、保有アイテム管理データ６１６とを格納する。勿論、これら以外のデータも適宜格納することができる。

保有キャラクタ管理データ６１４は、プレーヤキャラクタ４として使用することができるキャラクタ毎に用意され、当該キャラクタの状態を記述するデータセーブ時点における各種データを格納する。一つの保有キャラクタ管理データ６１４は、固有のキャラクタＩＤ毎に、当該キャラクタの種類や、データセーブ時における能力パラメータ値リスト、などを格納する。勿論、これら以外のデータも適宜格納することができる。

図１０に戻って、マッチング待機リスト６３０は、マッチングを希望するユーザのアカウントのリストである。マッチング待機リスト６３０は、例えば図１３に示すように、登録日時６３１と、アカウント６３３と、閾値到達判定結果６３５と、ユーザレベル６３７と、を対応づけて格納する。閾値到達判定結果６３５は、当該ユーザが閾値到達ユーザであるか閾値未達ユーザであるかを示す。当該リストに登録した際に判定されて、その判定結果に設定される。

図１０に戻って、プレイデータ７００は、ゲームプレイ毎、換言するとマッチングされたパーティ毎に用意され、マルチプレイのゲーム進行状況を記述する各種データや、各キャラクタの制御データ、ゲーム画面の表示等に関する各種情報を格納する。

１つのプレイデータ７００は、例えば図１４に示すように、固有のプレイＩＤ７０１と、プレイ開始日時７０２と、マッチングされたユーザ２のアカウントを格納するマッチングリスト７１０と、ゲーム進行制御データ７２０と、を含む。勿論、これら以外のデータも適宜含めることができる。

マッチングリスト７１０には、マッチングされたユーザのアカウント７１２と対応づけて、閾値到達判定結果７１４と、ユーザレベル７１６とを格納する。これらの情報は、マッチング待機リスト６３０（図１３参照）からコピーされる。

ゲーム進行制御データ７２０は、１）ゲームプレイされるゲームステージを示すプレイステージＩＤ７２１と、２）ゲーム空間を構成する各種背景オブジェクトの制御データであるゲーム空間制御データ７２２と、３）プレーヤキャラクタ４別の制御データであるプレーヤキャラクタ制御データ７２３と、４）敵キャラクタ６別の制御データである敵キャラクタ制御データ７２４と、５）ゲーム成績データ７２５と、を含む。プレーヤキャラクタ制御データ７２３には、ゲーム開始時にプレーヤのゲームセーブデータ６１０（図１２参照）が反映される。

図１５は、本実施形態におけるユーザ端末１５００の機能構成の一例を示す機能ブロック図である。本実施形態のユーザ端末１５００は、操作入力部１００と、端末処理部２００と、音出力部３９０と、画像表示部３９２と、通信部３９４と、端末記憶部５００とを備える。

操作入力部１００は、プレーヤによる各種の操作入力に応じて操作入力信号を端末処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ＣＣＤモジュール、などによって実現できる。図２の方向入力キー１５０２や、ボタンスイッチ１５０４、タッチパネル１５０６がこれに該当する。

端末処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や端末記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、サーバシステム１１００から受信した各種データに基づいて各種の演算処理を実行して、ユーザ端末１５００の動作を制御する。図２の制御基板１５５０がこれに該当する。そして、本実施形態における端末処理部２００は、ユーザ端末演算部２６０と、計時部２８０と、音生成部２９０と、画像生成部２９２と、通信制御部２９４と、を備える。

ユーザ端末演算部２６０は、操作信号送信制御部２６１と、ゲーム画面表示制御部２６２とを含む。

操作信号送信制御部２６１は、操作入力部１００に為された操作に応じて、各種データやリクエストをサーバシステム１１００へ送信するための処理を実行する。

ゲーム画面表示制御部２６２は、サーバシステム１１００から受信した各種データに基づいてゲーム画面を表示するための制御を行う。当該構成では、ゲーム空間画像（例えば、３ＤＣＧ画像など）をサーバシステム１１００にて生成する構成とするが、ゲーム空間画像をユーザ端末１５００で生成する構成も可能である。その場合、ゲーム画面表示制御部２６２は、例えば３ＤＣＧを生成するための仮想３次元空間に配置されたオブジェクトの制御を含むこととなる。

音生成部２９０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイル再生可能なオーディオコーデック等によって実現され、ゲーム画面表示制御部２６２による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３９０に出力する。

音出力部３９０は、音生成部２９０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１５１０がこれに該当する。

画像生成部２９２は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。

そして、画像生成部２９２は、サーバシステム１１００から受信した各種データに基づいて１フレーム時間（例えば１／６０秒）で１枚のゲーム画面の画像を生成し、生成したゲーム画面の画像信号を画像表示部３９２に出力する。

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

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

端末記憶部５００は、端末処理部２００にユーザ端末１５００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、端末処理部２００の作業領域として用いられ、端末処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御基板１５５０が搭載するＩＣメモリ１５５２やメモリカード１５４０がこれに該当する。

本実施形態の端末記憶部５００は、端末システムプログラム５０２と、ゲームクライアントプログラム５０４と、を記憶する。勿論、これら以外のデータも適宜記憶することができる。

端末システムプログラム５０２は、ユーザ端末１５００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。

ゲームクライアントプログラム５０４は、端末処理部２００が読み出して実行することによってユーザ端末演算部２６０としての機能を実現させるためのアプリケーションソフトウェアであるが、端末システムプログラム５０２の一部として組み込まれた構成であっても良い。本実施形態では、サーバシステム１１００から提供される配信用ゲームクライアントプログラム５０５（図１０参照）のコピーとする。

なお、ゲームクライアントプログラム５０４は、オンラインゲームを実現する技術手法に応じて専用のクライアントプログラムであっても良いし、ウェブブラウザプログラム及びインタラクティブな画像表示を実現するプラグインなどにより構成するとしても良い。

［動作の説明］
次に、サーバシステム１１００における処理の流れについて説明する。ここで説明する処理の流れは、サーバ処理部２００ｓがサーバシステムプログラム５０１とサーバプログラム５０３とを実行することにより実行される。

図１６は、本実施形態のサーバシステム１１００におけるマッチング処理の流れを説明するためのフローチャートである。サーバシステム１１００は、マッチング処理を周期的に繰り返し実行している。

同処理において、サーバシステム１１００は、ユーザ端末１５００からのログインリストを受け付けるとログイン処理を実行し、ログインユーザをマッチング待機リスト６３０に新規登録する（ステップＳ２；図１３参照）。そして、当該ログインユーザの保有原資管理データ６０３を参照して、現在の単位会計期間における合計課金額が所与の上限閾値（月内課金上限額）に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定し、判定結果に応じて閾値到達判定結果６３５を設定する。

次に、サーバシステム１１００は、マッチング待機リスト６３０に登録されているユーザ２を、閾値到達ユーザ同士、又は閾値未達ユーザ同士によるホモマッチングをトライする（ステップＳ８）。

もし、ホモマッチングが成立しなければ（ステップＳ２０のＮＯ）、サーバシステム１１００は、ヘテロマッチング混合比率設定データ５１８を参照して混合比を決定し（ステップＳ２２）、当該混合比を実現するヘテロマッチングをトライする（ステップＳ２４）。
もし、ヘテロマッチングでも成立しなければ（ステップＳ２６のＮＯ）、ステップＳ４に戻る。

ホモマッチングが成立した場合（ステップＳ２０のＹＥＳ）、又はヘテロマッチングが成立した場合（ステップＳ２６のＹＥＳ）、サーバシステム１１００は、マッチングされたユーザ２をマッチング待機リスト６３０から抹消する（ステップＳ３０）。

そして、新たにプレイデータ７００（図１４参照）を作成して、マッチングされたユーザ２のゲームセーブデータ６１０（図１２参照）を反映させる（ステップＳ３２）。
具体的には、固有のプレイＩＤ７０１を設定して、プレイ開始日時７０２に現在日時８００を格納する。マッチングリスト７１０には、マッチング待機リスト６３０からマッチングされたユーザ２の情報をコピーする。ゲーム進行制御データ７２０のうち、プレイステージＩＤ７２１は、未定を示す所定値を設定する。ゲーム空間制御データ７２２はまだ作成しなくてもよい。プレーヤキャラクタ制御データ７２３は、マッチングされた各ユーザ２のゲームセーブデータ６１０が反映されて作成される。敵キャラクタ制御データ７２４，ゲーム成績データ７２５もまだ作成しなくてもよい。これで、マッチングされたユーザはプレーヤとなる。

そして、サーバシステム１１００は、新たにマッチングされたユーザ２それぞれのユーザ端末１５００へ、当該ユーザが閾値到達ユーザであるか閾値未達ユーザで有るかに応じて、対応するマッチング識別情報報知画面Ｗ４〜Ｗ１０（図４〜７参照）の何れかを表示させる（ステップＳ３４）。

マッチング処理により、マッチング毎にプレイデータ７００が作成され、マッチングされたユーザ２の情報がマッチングリスト７１０に登録され、ゲーム開始の準備ができたことになる。

図１７〜図１８は、本実施形態のサーバシステム１１００におけるゲーム実行処理の流れを説明するためのフローチャートである。ゲーム実行処理も所定の周期で繰り返し実行される。

同処理において、サーバシステム１１００は、プレイステージ未定のプレイデータ７００毎に、プレイするステージの選択受け付けを行うループＡを実行する（ステップＳ６０〜Ｓ６８）。

すなわち、処理対象プレイデータのマッチングが、閾値未達ユーザのみの編成である場合（ステップＳ６２のＹＥＳ）、閾値到達ユーザ専用ステージフラグ５４６（図１１参照）が「１（専用）」に設定されているゲームステージを除いたゲームステージをユーザに提示して、プレイするステージの選択を受け付ける（ステップＳ６４）。選択結果は、プレイデータ７００のプレイステージＩＤ７２１に格納される（図１４参照）。

一方、処理対象プレイデータのマッチングが、閾値到達ユーザが含まれている場合（ステップＳ６２のＮＯ）、閾値到達ユーザ専用ステージフラグ５４６（図１１参照）が「１（専用）」に設定されているゲームステージを含むゲームステージをユーザに提示して、プレイするステージの選択を受け付ける（ステップＳ６６）。選択結果は、プレイデータ７００のプレイステージＩＤ７２１に格納される。

ループＡを終了すると、サーバシステム１１００は、プレイするゲームステージが決まっているプレイデータ７００毎に、ループＢを実行してマッチングそれぞれについてゲームの開始から終了まで、そしてゲーム成績に応じた成果付与までの制御を実行する（ステップＳ８０〜Ｓ１２２；図１８）。

ループＢにおいて、サーバシステム１１００は、処理対象プレイデータについて、ゲーム進行制御を開始する（ステップＳ８２）。すなわち、プレイステージＩＤ７２１で示されたゲームステージのゲーム空間初期設定データ５５０（図１１参照）に従って、ゲーム空間制御データ７２２（図１４参照）を作成して、ゲーム空間の制御を開始する。また、敵キャラクタ出現初期設定データ５５２（図１１参照）に従って、敵キャラクタ制御データ７２４（図１４参照）を作成して、敵キャラクタ６の自動制御を開始する。そして、各ユーザ２のユーザ端末１５００からの操作入力信号に従って、各プレーヤキャラクタ４を動作制御する。本実施形態では、プレーヤキャラクタ４と敵キャラクタ６との戦闘が繰り広げられ、ゲーム成績データ７２５が逐次更新される。

本実施形態では、プレーヤキャラクタ４、敵キャラクタ６共に、相手からの攻撃を受けると耐久値がダメージ分だけ減らされ、耐久値が「０」になると行動不能となる。そして、全てのプレーヤキャラクタ４、又は全ての敵キャラクタ６が行動不能になると、ゲーム進行制御が終了する（ステップＳ８４）。なお、ゲーム進行制御の終了は、ゲーム内容によって適宜設定可能である。

ゲーム進行制御が終了すると、サーバシステム１１００はゲーム成績に応じた成果の付与を行う。すなわち、ゲーム進行が終了し、ゲーム成績が「ステージクリア」すなわち全ての敵キャラクタ６が行動不能になってゲーム進行が終了した場合には（ステップＳ１００のＹＥＳ）、処理対象プレイゲームのマッチングリスト７１０に登録されているユーザ２のユーザ端末１５００にて、所定のステージクリア通知を行う（ステップＳ１０２）。

図１８に移って、ゲーム成績が「ステージクリア」の場合は更に続けて、サーバシステム１１００は、プレイしているゲームステージのボーナスアイテムリスト５５６（図１１参照）を読み出してゲーム成績に応じてボーナスアイテムを用意し（ステップＳ１０４）、これをユーザ２に配分する（ステップＳ１０６）。

配分にあたっては、用意されたボーナスのうち、ボーナスアイテム又は課金要素でしか入手できないアイテムを優先的に閾値到達ユーザに配分する。
具体的には、ボーナスアイテムを、購入専用アイテムリスト５１２及び有料抽選専用アイテムリスト５１６（図１０参照）と照合し、該当するアイテムを優先配分の対象とする。そして、マッチングリスト７１０（図１４参照）のうち、閾値到達ユーザを配分先とする。配分先の閾値到達ユーザ数が配分対象のアイテムより多ければ、配付先をランダム選択して決定する。

次に、サーバシステム１１００は、ゲーム成績に応じた成果の一つとして、各ユーザ２のプレーヤキャラクタ４の能力パラメータ値を変更する。
すなわち、マッチングタイプがヘテロである場合には（ステップＳ１１０のヘテロ）、サーバシステム１１００は、処理対象プレイゲームのマッチングリスト７１０に登録されている閾値未達ユーザのプレーヤキャラクタ４の能力パラメータ値を、ゲーム成績に応じて決まる標準値だけ変更する（ステップＳ１１２）。なお、変更対象とする能力パラメータ値の種類は、適宜設定可能である。単数種、複数種どちらでもよい。標準値も適宜設定可能である。

更に、サーバシステム１１００は、処理対象プレイゲームのマッチングリスト７１０に登録されている閾値到達ユーザのプレーヤキャラクタ４の能力パラメータ値を、ゲーム成績に応じて決まる標準値に所定の倍率を乗じて嵩上げした分だけ変更する（ステップＳ１１４）。つまり、ヘテロマッチングされた閾値到達ユーザへの特典付与を行う。倍率は適宜設定可能である。本実施形態では、１．２倍とするが、倍率を、閾値到達ユーザのユーザレベルの統計値と閾値未達ユーザのユーザレベルの統計値との差が大きいほど倍率を高くする、或いは逆に低くするとしてもよい。

一方、マッチングタイプがホモである場合には（ステップＳ１１０のホモ）、サーバシステム１１００は、処理対象プレイゲームのマッチングリスト７１０に登録されている各ユーザのプレーヤキャラクタ４の能力パラメータ値を、ゲーム成績に応じて決まる標準値だけ変更する（ステップＳ１１６）。

ゲーム成績に応じた成果の付与を終えたサーバシステム１１００は、処理対象プレイゲームのマッチングリスト７１０に登録されている各ユーザのゲームセーブデータ６１０（図１２参照）を更新して（ステップＳ１２０）、ループＢを終了する（ステップＳ１２２）。

なお、ゲーム進行が終了し、ゲーム成績が「ゲームオーバ」すなわち全てのプレーヤキャラクタ４が行動不能になってゲーム進行が終了した場合には（ステップＳ１００のＹＥＳ；図１７）、処理対象プレイゲームのマッチングリスト７１０に登録されているユーザ２のユーザ端末１５００にて、所定のゲームオーバ通知を行う（ステップＳ１１８）。
そして、成果の付与をスキップして、各ユーザのゲームセーブデータ６１０を更新して（ステップＳ１２０）、ループＢを終了する（ステップＳ１２２）。

以上、本実施形態によれば、課金要素を有するマルチプレイゲームにおいて、閾値到達ユーザが課金要素を利用できない状態でもゲームプレイへのモチベーションを維持し易くし、閾値未達ユーザと閾値未達ユーザとの好ましくないマッチングを抑止するといった新たなマッチング技術を実現することができる。

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

［その１］
例えば、上記実施形態では、マッチングからゲーム進行制御、ゲーム成績に応じた成果の付与までを一貫して、クライアント・サーバ型のコンピュータシステムにてオンラインゲームとして実現する例を挙げたがこれに限らない。

例えば、複数のユーザ端末１５００をピアツーピア（Ｐ２Ｐ）接続可能なコンピュータシステムにおいて実現するとしてもよい。その場合、サーバシステム１１００が、マッチングされたユーザ端末１５００にプレイデータ７００を提供した後に、当該ユーザ端末同士で改めてＰ２Ｐ接続を実現する。そして、何れかのユーザ端末１５００に、第１実施形態のゲーム管理部２２０のゲーム進行制御部２２６とゲーム成果変更部２２７との機能を担わせる。或いは、複数のユーザ端末１５００でそれらの機能を分担して担う構成としてもよい。

［その２］
また、例えば、上記実施形態ではゲームジャンルを一例としてアクションＲＰＧとしたが、マッチングと課金要素とを有するゲームであればゲームジャンルはこれに限らず適宜設定可能である。例えば、パズルゲーム、戦術シミュレーションゲーム、シューティングゲーム、恋愛ゲーム、育成ゲーム、レースゲーム、パズルゲーム、アクションゲーム、音楽ゲーム、スポーツゲーム、などに本実施形態を適用することもできる。

[その３]
また、上記実施形態ではゲームの内容を、協力プレイ型としたが対戦型のゲームであってもよい。もし対戦ゲームとしてデザインした場合には、ゲーム成果変更部２２７を、ヘテロマッチングによるゲームの結果、閾値到達ユーザが勝者となり、閾値未達ユーザが敗者となった場合に、当該敗者である閾値未達ユーザが所有するアイテムの中から、課金要素で入手可能なアイテムを当該勝者である閾値到達ユーザへ戦利品として付与する戦利品付与制御部として機能させればよい。

具体的には、例えば図１９に示すように、第１実施形態におけるボーナスアイテム付与に係るステップＳ１０４〜Ｓ１０６を、敗者が保有するアイテムを、勝者へ戦利品（対戦ゲームにおけるボーナスアイテム）として付与するステップ（ステップＳ１０８）に置き換える。そして、戦利品の付与にあたって、閾値到達ユーザが勝者で、閾値未達ユーザが敗者の場合には、ボーナスアイテムの付与を除けば課金要素でしか入手できないアイテムを優先的に付与すればよい。

２…ユーザ
４…プレーヤキャラクタ
７…アイテム
３０…ユーザ情報表示
３２…判定結果通知
３４…閾値未達ユーザ向け特典情報通知
３６…閾値到達ユーザ向け特典情報通知
４０…ボーナスアイテム
２００ｓ…サーバ処理部
２０２…ユーザ管理部
２０４…課金履歴管理部
２０６…判定部
２０８…課金制限部
２１０…オンラインショッピング管理部
２２０…ゲーム管理部
２２２…マッチング部
２２３…混合比率変更部
２２４…マッチング識別情報報知制御部
２２５…ステージ選択制御部
２２６…ゲーム進行制御部
２２７…ゲーム成果変更部
５００ｓ…サーバ記憶部
５０３…サーバプログラム
５１８…ヘテロマッチング混合比率設定データ
５２０…ゲーム初期設定データ
５３０…ゲームステージ初期設定データ
５３２…ステージＩＤ
５４０…ステージ選択可能要件
５４６…閾値到達ユーザ専用ステージフラグ
５５０…ゲーム空間初期設定データ
５５６…ボーナスアイテムリスト
５６０…アイテム初期設定データ
６００…ユーザ管理データ
６０１…アカウント
６０３…保有原資管理データ
６１０…ゲームセーブデータ
６１２…ユーザレベル
６１６…保有アイテム管理データ
６３０…マッチング待機リスト
６３５…閾値到達判定結果
６３７…ユーザレベル
７００…プレイデータ
７１０…マッチングリスト
７２０…ゲーム進行制御データ
７２１…プレイステージＩＤ
７２２…ゲーム空間制御データ
７２３…プレーヤキャラクタ制御データ
７２５…ゲーム成績データ
１０００…ゲームシステム
１１００…サーバシステム
１１５０…制御基板
１５００…ユーザ端末
Ｗ２…ゲーム画面
Ｗ４〜Ｗ１０…マッチング通知画面

Claims (14)

1. 課金要素を含むゲームの実行に当たり、ユーザのマッチングを行うサーバシステムであって、
   ユーザ毎の前記課金要素に係る課金を管理する課金管理手段と、
   ユーザ毎に、課金の会計締め切り日時（以下単に「会計締め日」という）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が所与の閾値に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定する判定手段と、
   前記マッチングを希望するユーザのうち、前記閾値到達ユーザ同士、又は、前記閾値未達ユーザ同士を優先的にマッチングさせるマッチング手段と、
   を備えたサーバシステム。
2. 前記マッチング手段は、前記閾値到達ユーザ同士、又は、前記閾値未達ユーザ同士のマッチングが成立しない場合に、前記閾値到達ユーザと前記閾値未達ユーザとを混合したヘテロマッチングを行う、
   請求項１に記載のサーバシステム。
3. 前記マッチング手段は、前記ヘテロマッチングを行う場合、マッチングされる前記閾値到達ユーザの数が、前記閾値未達ユーザの数以下となるようにマッチングする、
   請求項２に記載のサーバシステム。
4. 前記マッチングが前記ヘテロマッチングであるか否かに応じて、前記マッチングされたゲームによって前記閾値到達ユーザが獲得可能な成果を変更するゲーム成果変更手段、
   を更に備える請求項２又は３に記載のサーバシステム。
5. 前記ゲーム成果変更手段は、前記ヘテロマッチングである場合に、前記閾値到達ユーザが獲得可能な成果を、前記課金要素で取得可能なアイテムとする、
   請求項４に記載のサーバシステム。
6. 前記ゲーム成果変更手段は、前記成果をパラメータ値とし、前記ヘテロマッチングである場合に、前記ヘテロマッチングでない場合に比べて、多くのパラメータ値を前記閾値到達ユーザが獲得可能とする、
   請求項４に記載のサーバシステム。
7. 前記ゲームは対戦ゲームであり、
   前記ヘテロマッチングによる前記ゲームの結果、閾値到達ユーザが勝者となり、閾値未達ユーザが敗者となった場合に、当該敗者である閾値未達ユーザが所有するアイテムの中から、前記課金要素で入手可能なアイテムを当該勝者である閾値到達ユーザへ戦利品として付与する戦利品付与手段、
   を更に備えた請求項２〜６の何れか一項に記載のサーバシステム。
8. 前記マッチングは、３人以上のユーザのマッチングであり、
   前記マッチング手段は、前記ヘテロマッチングにおいて、前記閾値到達ユーザと前記閾値未達ユーザとの混合比率を変更する混合比率変更手段を有する、
   請求項２〜７の何れか一項に記載のサーバシステム。
9. 前記混合比率変更手段は、マッチングするユーザのレベルに応じて前記混合比率を変更する、
   請求項８に記載のサーバシステム。
10. 前記ヘテロマッチングがなされた場合に、当該マッチングされたユーザに、当該マッチングがヘテロマッチングである旨を報知するマッチング識別報知手段、
    を更に備えた請求項２〜９の何れか一項に記載のサーバシステム。
11. 前記マッチング手段によりマッチングされたユーザの中に前記閾値到達ユーザが含まれている場合に、前記閾値到達ユーザが含まれていることを選択条件とするステージを、当該マッチングされたユーザがプレイするステージとして選択するステージ選択手段、
    を更に備えた請求項１〜１０の何れか一項に記載のサーバシステム。
12. 課金要素を含むゲームの実行に当たり、ユーザのマッチングを行うサーバシステムであって、
    ユーザ毎の前記課金要素に係る課金を管理する課金管理手段と、
    ユーザ毎に、課金の会計締め切り日時（以下単に「会計締め日」という）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が所与の閾値に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定する判定手段と、
    前記マッチングを希望するユーザが前記閾値到達ユーザであるか前記閾値未達ユーザであるかに基づくマッチングを行うマッチング手段と、
    前記マッチング手段によりマッチングされたユーザが前記閾値到達ユーザのみのときに選択される特別ステージを、前記閾値到達ユーザと前記閾値未達ユーザとが含まれているマッチングがなされた場合に選択するステージ選択手段と、
    を備えたサーバシステム。
13. 課金要素を含むゲームの実行に当たり、ユーザのマッチングを行うコンピュータシステムを、
    ユーザ毎の前記課金要素に係る課金を管理する課金管理手段、
    ユーザ毎に、課金の会計締め切り日時（以下単に「会計締め日」という）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が所与の閾値に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定する判定手段、
    前記マッチングを希望するユーザのうち、前記閾値到達ユーザ同士、又は、前記閾値未達ユーザ同士を優先的にマッチングさせるマッチング手段、
    として機能させるためのプログラム。
14. 課金要素を含むゲームの実行に当たり、ユーザのマッチングを行うコンピュータシステムを、
    ユーザ毎の前記課金要素に係る課金を管理する課金管理手段、
    ユーザ毎に、課金の会計締め切り日時（以下単に「会計締め日」という）で区切られた単位会計期間のうちの現在の単位会計期間における合計課金額が所与の閾値に達した閾値到達ユーザであるか、閾値未達ユーザであるかを判定する判定手段、
    前記マッチングを希望するユーザが前記閾値到達ユーザであるか前記閾値未達ユーザであるかに基づくマッチングを行うマッチング手段、
    前記マッチング手段によりマッチングされたユーザが前記閾値到達ユーザのみのときに選択される特別ステージを、前記閾値到達ユーザと前記閾値未達ユーザとが含まれているマッチングがなされた場合に選択するステージ選択手段、
    として機能させるためのプログラム。

Images