JP7289216B2 - サーバシステムおよびゲームシステム - 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 (17)

1. ゲームをプレイするためのマッチングリクエストを受け付けたユーザ同士のマッチング処理を実行するサーバシステムであって、
   前記マッチングリクエストには、マッチングに関する当該ユーザの希望条件指定が含まれ、
   前記ユーザのユーザ端末からの閲覧要求に応じて、当該ユーザ端末で所与の広告を閲覧させるために、当該広告を当該ユーザ端末に表示させる制御を行う広告表示制御手段と、
   各ユーザの広告閲覧情報を管理する広告閲覧情報管理手段と、
   前記マッチングリクエストを受け付けたユーザの前記広告閲覧情報に基づいて、当該マッチングリクエストに含まれる前記希望条件指定から選択することでマッチング条件を設定するマッチング条件設定手段と、
   前記マッチングリクエストを受け付けたユーザについて、当該ユーザの前記マッチング条件に基づいて前記マッチング処理を実行するマッチング実行手段と、
   を備えたサーバシステム。
2. 前記広告表示制御手段は、前記マッチング処理が完了するまでの待機中に前記広告を表示させる制御を行う、
   請求項１に記載のサーバシステム。
3. 前記広告閲覧情報管理手段は、前記マッチングリクエストを受け付けてから前記マッチング処理が完了するまでの間の前記閲覧要求のあったタイミングを前記広告閲覧情報に含めて管理し、
   前記マッチング条件設定手段は、前記広告閲覧情報に含まれるタイミングと前記マッチングリクエストの受け付けタイミングとの時間差に基づいて、前記マッチング条件の設定を行う、
   請求項２に記載のサーバシステム。
4. 前記広告閲覧情報管理手段は、前記広告の閲覧時間を前記広告閲覧情報に含めて管理し、
   前記マッチング条件設定手段は、前記広告閲覧情報に含まれる前記閲覧時間に基づいて、前記マッチング条件の設定を行う、
   請求項２に記載のサーバシステム。
5. 前記広告表示制御手段は、前記マッチングリクエストを受け付けてからの経過時間に応じて時間長が異なる広告の閲覧候補を前記ユーザに提示し、当該ユーザによって選択された広告を前記ユーザ端末に表示させる制御を行う、
   請求項２～４の何れか一項に記載のサーバシステム。
6. 前記広告表示制御手段は、前記マッチングリクエストの受け付け前に、前記広告を表示させる制御を行う、
   請求項１に記載のサーバシステム。
7. 前記広告は、前記ゲームで使用可能なアイテムに関する広告であり、
   前記広告表示制御手段によって広告表示がなされた前記ユーザ端末の前記ユーザが、前記アイテムを購入したか否かを判定する購入是非判定手段、
   を更に備え、
   前記マッチング条件設定手段は、前記マッチングリクエストを受け付けたユーザの前記広告閲覧情報と、当該ユーザに関する前記購入是非判定手段の判定結果とに基づいて、前記マッチング条件の設定を行う、
   請求項６に記載のサーバシステム。
8. 前記アイテムには、アイテム属性が定められ、
   前記ゲームには、ステージ属性が異なる複数のゲームステージがあり、
   前記ユーザそれぞれが操作するプレーヤキャラクタには、キャラクタ属性が定められており、
   前記購入是非判定手段により購入したと判定された場合、購入したユーザの前記希望条件指定に、１）購入したアイテムのアイテム属性に対して、予め好相性として設定されたステージ属性のゲームステージでゲームプレイすること、および／又は、２）購入したアイテムのアイテム属性に対して、予め好相性として設定されたユーザとゲームプレイすること、を追加設定する希望条件指定追加設定手段、
   を更に備えた請求項７に記載のサーバシステム。
9. 前記広告は、前記ゲームで使用可能なアイテムに関する広告であり、
   前記広告表示制御手段によって広告表示がなされた前記ユーザ端末の前記ユーザが、前記アイテムを使用したか否かを判定する使用是非判定手段、
   を更に備え、
   前記マッチング条件設定手段は、前記マッチングリクエストを受け付けたユーザの前記広告閲覧情報と、当該ユーザに関する前記使用是非判定手段の判定結果とに基づいて、前記マッチング条件の設定を行う、
   請求項６～８の何れか一項に記載のサーバシステム。
10. 前記広告閲覧情報管理手段は、前記ユーザが閲覧した閲覧広告の種類を前記広告閲覧情報に含めて管理し、
    前記マッチング条件設定手段は、前記広告閲覧情報に含まれる前記閲覧広告の種類に基づいて、前記マッチング条件の設定を行う、
    請求項１～９の何れか一項に記載のサーバシステム。
11. 前記希望条件指定は、前記ユーザのプレイレベルに基づくレベル差条件を含む、
    請求項１～１０の何れか一項に記載のサーバシステム。
12. 前記希望条件指定は、前記ユーザによって指定された条件を含む、
    請求項１～１１の何れか一項に記載のサーバシステム。
13. 前記広告表示制御手段によって表示制御される広告を、閲覧対象のユーザのゲームプレイ情報および／又は前記希望条件指定に基づいて決定する閲覧可能広告決定手段、
    を更に備えた請求項１～１２の何れか一項に記載のサーバシステム。
14. 前記広告は、前記ゲームに関する広告である、
    請求項１～１３の何れか一項に記載のサーバシステム。
15. 前記マッチング実行手段は、
    前記マッチングリクエストを受け付けたユーザを受付時刻と関連づけて順番に待ち行列に登録する順番登録ステップと、
    前記受付時刻から所与の猶予時間が経過したユーザについては、当該ユーザの前記マッチング条件を緩和した条件に更新する条件更新ステップと、
    前記待ち行列の順番に従って前記マッチング条件を満足するようなユーザ同士のマッチングを試行するマッチング試行ステップと、
    前記試行によりマッチングされたユーザ同士のなかに、前記マッチング条件の前記更新がなされた条件更新ユーザが含まれていない場合に、マッチング完了と判断して当該ユーザ同士を前記待ち行列から削除する第１の試行後処理ステップと、
    前記試行によりマッチングされたユーザ同士のなかに前記条件更新ユーザが含まれている場合に、当該条件更新ユーザに当該マッチングを許容するか否かの問合せ制御を行って、許容する旨の回答が得られたときには、マッチング完了と判断して当該ユーザ同士を前記待ち行列から削除し、許容する旨の回答が得られないときには、当該条件更新ユーザのユーザ端末に所与の代償広告を表示させる制御を行った上で、当該条件更新ユーザに係る前記待ち行列の順番を維持すること、前記更新を取り消して更新前の前記マッチング条件に戻すこと、および、当該条件更新ユーザに係る前記受付時刻をリセットすること、を実行する第２の試行後処理ステップと、
    を行う、
    請求項１～１４の何れか一項に記載のサーバシステム。
16. ゲームをプレイするためのマッチングリクエストを受け付けたユーザ同士のマッチング処理を実行するサーバシステムであって、
    前記マッチングリクエストには、マッチングに関する当該ユーザの希望条件指定が含まれ、
    前記マッチングリクエストを受け付けたユーザの前記希望条件指定をマッチング条件として、当該ユーザを、受付時刻および当該マッチング条件と関連づけて順番に待ち行列に登録する順番登録手段と、
    前記受付時刻から所与の猶予時間が経過したユーザについては、当該ユーザの前記マッチング条件を緩和した条件に更新する条件更新手段と、
    前記待ち行列の順番に従って前記マッチング条件を満足するようなユーザ同士のマッチングを試行するマッチング試行手段と、
    前記試行によりマッチングされたユーザ同士のなかに、前記マッチング条件の前記更新がなされた条件更新ユーザが含まれていない場合に、マッチング完了と判断して当該ユーザ同士を前記待ち行列から削除する第１の試行後処理手段と、
    前記試行によりマッチングされたユーザ同士のなかに前記条件更新ユーザが含まれている場合に、当該条件更新ユーザに当該マッチングを許容するか否かの問合せ制御を行って、許容する旨の回答が得られたときには、マッチング完了と判断して当該ユーザ同士を前記待ち行列から削除し、許容する旨の回答が得られないときには、当該条件更新ユーザのユーザ端末に所与の広告を表示させる制御を行った上で、当該条件更新ユーザに係る前記待ち行列の順番を維持すること、前記更新を取り消して前記マッチング条件を前記希望条件指定に戻すこと、および、当該条件更新ユーザに係る前記受付時刻をリセットすること、を実行する第２の試行後処理手段と、
    を備えたサーバシステム。
17. ユーザ端末と、
    請求項１～１６の何れか一項に記載のサーバシステムと、
    を具備するゲームシステム。

Images