JP5483508B1 - サーバ装置、および、方法 - Google Patents

Abstract

【課題】ネットワークゲームに参加するユーザそれぞれが主体的に積極性を持つようにマッチング処理を行うことによって、より興趣性を向上させることができるサーバ装置を提供する。
【解決手段】サーバ装置は、通信回線を介して、ネットワークゲームに対する参加要求を受け付けＳ１０、参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成しＳ１２，Ｓ１４、参加要求を受け付けたそれぞれの端末装置に対して、生成したマッチング情報を通知するＳ１３。マッチング情報は、参加要求の順序にかかわらず、通知先の端末装置がもっとも早く参加要求をしたかのごとく示されるように、通知先の端末装置ごとに異ならせる。
【選択図】図１４

Description

本発明は、ネットワークを通じて複数のユーザが参加するソーシャルゲームの処理技術に関する。

近年、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）を利用し、ネットワークを通じて複数のユーザが参加するソーシャルゲームが広まっており、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）端末や携帯端末等の情報処理装置を用いてゲームサーバと通信を行うことにより互いの情報を交換し合いコミュニケーションを行うネットワークゲームが提供されている。

このようなネットワークゲームのうち、いわゆるネットワーク対戦ゲームは、たとえばユーザ同士が互いにバトルを行い、あるいは、ユーザ同士がチームを編成して敵対するチームや仮想の敵との間でバトルを行うものなどが存在する。

たとえば、特許文献１には、異なるチーム同士が同一のネットワーク対戦ゲームを行い、ゲームに参加申請したユーザをいずれかのマッチングルームに割り当て、割り当てられたユーザの情報を順次マッチングルーム画像として表示する技術が開示されている。

特開２０１２−５５４３５号公報

しかしながら、ネットワークゲームに新たに参加する際に、他のユーザがすでに入っているマッチングルームに割り当てられると、マッチングルーム画像には他のユーザが存在することとなる。そうすると、他のユーザに先んじられて遅れて参加するユーザにおいては、自分が後から参加したゲストであるという心証が形成され、そのチームに対して主体的に積極性を持って貢献しようという意識が阻害され、ネットワークゲームが白熱しづらくなるといった課題があった。このような白熱しづらいネットワークゲームが増えてくると、ネットワークゲーム業界の隆盛に陰りを落としかねないといった懸念があった。

本発明はかかる課題に鑑みてなされたものであり、その目的は、ネットワークゲームに参加するユーザそれぞれが主体的に積極性を持つようにマッチング処理を行うことによって、より興趣性を向上させることができるサーバ装置、および、方法を提供することにある。

本発明のある態様は、サーバ装置に関する。このサーバ装置は、通信回線を介して、複数のユーザが使用する端末装置のそれぞれから、１以上のユーザが参加可能なネットワークゲームに対する参加要求を受け付ける受付部と、受付部により参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成し、参加要求を受け付けたそれぞれの端末装置に対して、生成したマッチング情報を通知するマッチング処理部と、を備える。マッチング処理部により通知されるべきマッチング情報は、参加要求の順序にかかわらず、通知先の端末装置がもっとも早く参加要求をしたかのごとく示されるように、通知先の端末装置ごとに異ならせる。

このような態様によると、通知されるマッチング情報は、参加要求の順序にかかわらず、通知先の端末装置がもっとも早く参加要求をしたかのごとく示されるため、ゲームに参加するそれぞれのユーザに対して、自らがゲーム参加表明の一番手であると認識させることができる。これにより、そのチームに対して主体的に積極性を持って貢献することを促せるためゲームが白熱しやすく、興趣性を向上させることができ、もって、ネットワークゲーム業界を盛り上げることができる。

また、マッチング処理部は、通知先のユーザごとに、通知先ユーザのユーザ情報のみが含まれた第１マッチング情報と、通知先ユーザ以外のユーザ情報が少なくとも含まれた第２マッチング情報とを生成するマッチング情報生成部と、マッチング情報生成部によって生成されたうちの第１マッチング情報を通知し、その後に、第２マッチング情報を通知するマッチング情報送信部と、を含んでもよい。また、マッチング情報生成部は、第１マッチング情報を生成し、その後に、第２マッチング情報を生成してもよい。

このような態様によると、通知先ユーザのユーザ情報のみが含まれた第１マッチング情報と、通知先ユーザ以外のユーザ情報が少なくとも含まれた第２マッチング情報とを順次生成し、通知することによって、ユーザの端末の表示画面には、まず、自分が第１の参加者である旨が表示されて、その後に他のゲーム参加者が表示される。これにより、ゲームに参加するユーザは必ず自分がマッチングルームに最初に入ったように感じさせることができる。

また、受付部は、前記ネットワークゲームを進行させるための探索要求を受け付けてもよい。また、マッチング情報生成部は、受付部が探索要求を受け付けたことを契機として、第２マッチング情報を生成してもよい。

このような態様によると、ユーザからの探索要求を受け付けたことを契機として、第２マッチング情報を生成することによって、当該ユーザにかかる第１マッチング情報は、第２マッチング情報より先に生成、通知されることとなり、自らがゲーム参加表明の一番手であると認識させることができる。また、マッチング情報に基づき生成されるユーザの端末の画面上には探索ボタンが表示され、端末装置において操作を行うことによりマッチングが完了するまでの待機時間にミッションゲームを進行することができ、ユーザを退屈させることなく、ゲームへの興味を促進させることができる。

マッチング情報生成部は、第２マッチング情報を生成する際に、通知先のユーザ端末のユーザとの間で親和度の高い他のユーザのユーザ情報が優先的に含まれるようにマッチング情報を生成してもよい。

このような態様によると、マッチング情報に他のユーザの情報が含まれる際には、親和度の高い他のユーザから優先的に含められるため、ユーザの高揚感を向上させることができ、もって、ネットワークゲームの興趣性を向上することができる。

また、ユーザ情報は、ユーザ識別情報、ユーザ名、アバター、および、ユーザが入力したコメントのうちのいずれか１つ以上を含めてもよい。また、受付部は、参加要求を受け付けたユーザ端末ごとにコメント情報を受け付けてもよい。マッチング情報生成部は、同時期に開始された同一のネットワークゲームに参加しているそれぞれのユーザ端末に通知すべきマッチング情報として、受付部によって受け付けたコメント情報を含めてもよい。

このような態様によると、ユーザの情報に基づきマッチング情報を生成する際にユーザ名、アバター、ユーザが入力したコメントの何れか一つ又はこれらの組み合わせであるため、これらが含まれるマッチング情報に基づきマッチング画像を生成することで、グラフィカルで視認性のよいマッチング画像によりユーザの高揚感を向上させることができる。

また、マッチング処理部は、マッチング情報に対して、通知先の端末のユーザ情報を第１位とした参加順位情報を含め、第２位以降を通知先以外の端末のうち参加順序の早い順にユーザ情報を含めてもよい。

このような態様によるとマッチング情報に対して、通知先の端末のユーザ情報を第１位とした参加順位情報を含め、第２位以降を通知先以外の端末のうち参加順序の早い順にユーザ情報を含めることによって、端末での表示順序を指し示すことが可能になり、ゲームに参加するそれぞれのユーザに対して、自らがゲーム参加表明の一番手であると認識させることができる。

また、本発明の別の態様は、方法である。この方法は、複数のユーザが使用する端末装置のそれぞれから、１以上のユーザが参加可能なネットワークゲームに対する参加要求を受け付けるステップと、参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成し、参加要求を受け付けたそれぞれの端末装置に対して、生成したマッチング情報を通知するステップと、を含む。マッチング情報は、参加要求の順序にかかわらず、通知先の端末装置がもっとも早く参加要求をしたかのごとく示されるように、通知先の端末装置ごとに異ならせる。

また、本発明の別の態様は、プログラムである。複数のユーザが使用する端末装置のそれぞれから、１以上のユーザが参加可能なネットワークゲームに対する参加要求を受け付けるステップと、参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成し、参加要求を受け付けたそれぞれの端末装置に対して、生成したマッチング情報を通知するステップと、を含む。マッチング情報は、参加要求の順序にかかわらず、通知先の端末装置がもっとも早く参加要求をしたかのごとく示されるように、通知先の端末装置ごとに異ならせる。

なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によると、ネットワークゲームにおけるマッチング処理を適切に行うことによって、ゲームに参加する複数のユーザ全ての興趣性を向上させることができる。

本発明の実施例を説明する前に、まず、本発明の概要を述べる。本発明は、ネットワークを介して行われる複数ユーザによるネットワークゲームにおいて、同時に開始されるゲームにおけるチームを決める際のマッチング処理に関するものである。

従来のマッチング処理においては、ゲームへの参加表明が他の参加ユーザより遅かった場合、その参加ユーザはそれを認識してしまうことにより、そのゲームに対して主体的に積極性を持って貢献しようという意識が阻害され、ゲームが白熱しづらくなるといった課題があった。

本発明においては、以上の課題を解消しており、ゲームへの参加表明の先後にかかわらず、最初に参加を表明したユーザであるとしてマッチング処理を行うことによって、それぞれの参加ユーザの興趣性を高めるものであり、もって、白熱したネットワークゲーム環境を提供できるものである。

以下、本発明をネットワークゲーム、特にソーシャルゲームに適用した例を用いて説明する。

ここで、ソーシャルゲームについて簡単に説明する。ソーシャルゲームとは、一般的にＳＮＳ情報を用いてウェブブラウザ上で動作するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）等のプラットフォームを用い、これを基盤として動作するアプリケーションゲームソフトを言う。以下では、単にブラウザゲームと称する。

また、ソーシャルゲームには、ＳＮＳ情報を用いるが、ユーザが操作する各端末装置にアプリケーションプログラムをダウンロードし、各端末装置内でアプリケーションプログラムが実行され、各端末装置とサーバ装置との間では各種のパラメータを送受信して行うものもある。以下では、単にアプリゲームと称する。

なお、本発明の一例である以下の処理は、ブラウザゲームとしてゲームを提供するサーバ装置において処理することも可能であるし、アプリゲームとして端末装置側で実行されるプログラムにて処理することも可能である。また、以下で説明する例は、本発明の理解のためのものであり、本発明の技術的範囲がこれに限定されるものではない。

まず、実施例１について説明する。図１は、本発明の実施例１にかかるソーシャルゲームシステム１００を示す図である。ソーシャルゲームシステム１００は、サーバ装置１０と、サーバ装置１０と基地局４０とを有線回線で接続するネットワーク３０と、基地局４０で代表される第１基地局４０ａ〜第３基地局４０ｃと、モバイル端末５０で代表される第１モバイル端末５０ａ〜第３モバイル端末５０ｃと、ＰＣ端末７０とを含む。

なお、図示の都合上、基地局４０、モバイル端末５０は共に３台のみ図示したが、これにかぎらず、それ以上の基地局４０、モバイル端末５０が存在してもよい。ＰＣ端末７０についても同様である。また、第１モバイル端末４０ａ〜第３モバイル端末４０ｃは、それぞれ異なる基地局４０と接続されるとして図示しているが、これにかぎらず、１つの基地局４０に複数のモバイル端末５０が接続されていても、本発明が適用可能であることは言うまでもない。

サーバ装置１０は、ソーシャルゲームサービスを実施、提供するための装置である。サーバ装置１０は、ネットワーク３０と基地局４０とを介して、モバイル端末５０やＰＣ端末７０との間で、ゲーム処理のための通信処理を実行する。なお、以下においては、説明を簡易にするため、単に、「サーバ装置１０とモバイル端末４０ないしＰＣ端末７０との間で通信処理を実行する」などと表現し、ネットワーク３０および基地局４０を介する点については記載を省略する。また、以下においては、モバイル端末５０やＰＣ端末７０を総称して、ユーザ端末と表現することもある。また、サーバ装置１０とは、ネットワークゲームにかかるサービスを提供するプラットフォームであってもよいし、あるいは、ネットワークゲームのアプリケ―ションを提供するサーバであってもよい。

図２は、図１のサーバ装置１０の構成例を示す図である。このサーバ装置１０は、サーバ通信部１２と、ユーザ情報管理部１３と、ゲーム管理部１４と、マッチング処理部１５と、画像生成部１６と、サーバメモリ１７とを含む。

サーバ通信部１２は、ネットワーク３０を介して外部のＳＮＳサーバ装置やユーザ端末等と通信する。なお、ＳＮＳサーバ装置は、サーバ装置１０が兼ねてもよいこととし、ＳＮＳサーバ装置を不図示としている。

ユーザ情報管理部１３は、ＳＮＳに登録されたユーザ情報をＳＮＳサーバ装置から取得するとともにソーシャルゲームに登録したユーザの情報をサーバメモリ１７にて管理する。また、ユーザ情報管理部１３は、ＳＮＳサーバ装置から取得した情報を含むユーザの情報をサーバメモリ１７にアップロードする。サーバメモリ１７は、ユーザの情報のほかカードを用いたネットワークゲームで使用されるカード管理データなどを記憶する。

ユーザの情報は、ユーザ識別情報、ユーザ名、アバター、ユーザが入力したコメントの何れか一つ又はこれらの組み合わせとなる。これらのユーザの情報は、後述する画像生成部１６においてマッチングルームの画像を生成する際に用いられて、一のユーザが他のユーザを視認しやすく臨場感を高めることができるような画像が生成されることとなる。

図３は、図２のサーバメモリ１７において管理されるユーザ管理データの一例を示す図である。図３に例示するごとく、ユーザ情報管理部１３は、サーバメモリ１７においてテーブル状のデータを有するようにしてもよい。ここで、ユーザ名は、ＳＮＳ上のユーザ名を用いられてもよいし、また、ゲームごとに設定されたユーザの名前でもよい。

また、ユーザ識別情報は、ユーザを識別するためのユニークコードである。また、レベルは、ゲームに参加した回数や得られた経験ポイントに基づき順次増加するユーザのレベルである。また、進行状況は、各ユーザがどこまでゲームを進行させているかを示す情報である。また、保有カード識別情報は、チームバトル等で用いるキャラクタカード等各種のカード識別情報である。

図４は、図２のサーバメモリ１７において管理しているカード管理データの一例を示す図である。図４に例示するごとく、サーバメモリ１７は、カード管理データとしてテーブル状のデータを有するようにしてもよい。ここで、図４中、名称は、カード自体、あるいはカードに表示されたキャラクタの名称を示す。レアリティ値は、そのカードの希少価値の度合いを示し、例えば、コモン、アンコモン、レア、スーパーレアのように段階的に希少度が上がるようにランク分けされている。初期攻撃値は、チームバトルにおけるキャラクタの初期の攻撃値であり、初期体力値はチームバトルにおけるキャラクタの体力の初期値である。これらは初期値であるため、バトルを繰り返し、キャラクタが進化、強化されるごとに値が変化する。

図２に戻る。ゲーム管理部１４は、ソーシャルゲームの進行、クエストの管理等各種の処理・管理を行う。ゲーム管理部１４は、ゲームの進行を制御し、サーバメモリ１７に記憶されたユーザ情報やカード管理データにアクセスし、所定の処理を実行する。

マッチング処理部１５は、ユーザ端末からクエストが選択されチームバトルへの参加要求がなされた際に、選択されたクエストに基づきユーザのチーム割り当てを行うとともに、マッチング情報を生成する。マッチング処理部１５は、サーバ通信部１２経由で参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成する。さらに、マッチング処理部１５は、サーバ通信部１２を介して、参加要求を受け付けたそれぞれのユーザ端末に対して、生成したマッチング情報を通知する。

このとき、各ユーザ端末に送信されるマッチング情報は、参加要求をしたユーザ端末毎に異なったものとなる。たとえば、複数のユーザ端末において、同時期に開始される同一のネットワークゲームに参加要求をしたような場合、マッチング処理部１５は、参加要求の順序にかかわらず、通知先のユーザ端末がもっとも早く参加要求をしたかのごとく示されるように、通知先の端末装置ごとに異ならせて、マッチング情報を生成する。「もっとも早く参加要求をしたかのごとく示される」とは、本来の参加順序にかかわらず、１番目の参加者として示すことを含む。たとえば、参加順位情報を強制的に１番に設定してもよく、また、マッチング情報内のユーザ情報の並び順が常に先頭になるように設定してもよい。

また、このマッチング情報を２段階に分けて生成あるいは通知することによって、ユーザ端末における参加ユーザの情報の表示にタイミング差を設けてもよい。このような態様により、それぞれの参加ユーザの各々に対して、それぞれの参加タイミングによらず、自らが最初の参加ユーザであると認識させることができる。詳細は後述することとする。

また、マッチング処理部１５は、マッチング情報に対して、通知先の端末のユーザ情報を第１位とした参加順位情報を含め、第２位以降を通知先以外の端末のうち参加順序の早い順にユーザ情報を含めてもよい。この参加順位情報は、端末での表示順序を指し示してもよい。これにより、複数回にわたってマッチング情報を送信せずとも、参加順位情報が含まれたマッチング情報を１回のみ送信することで、前述と同様の効果を奏することができる。

また、マッチング情報は、マッチングされたユーザの情報からなり、マッチング画像そのものであってもよいが、本実施例では、別途画像生成部１６を用いてマッチング画像として待合室を想定したマッチングルームの画像を生成するようにしている。マッチング処理部１５は、マッチング情報を画像生成部１６に出力する。

画像生成部１６は、マッチング処理部１５から出力されたマッチング情報に基づいたマッチング画像としてマッチングルーム画像を生成する。生成したマッチングルーム画像は、サーバ通信部１２を経由して各ユーザ端末に送信される。

ここで、各ユーザ端末では、ウェブブラウザのＡＰＩを用いてマッチングルーム画像を表示する。マッチング処理部１５がマッチング情報をダイレクトにサーバ通信部１２を経由して各ユーザ端末に出力した場合、端末側でＡＰＩを用いてマッチングルーム画像を生成するようにしてもよい。この場合は、マッチングルーム画像そのものをネットワーク３０上に送信せず、パラメータ情報を中心にデータ通信を行うこととなり、ネットワークの帯域が狭い環境において好適である。

サーバ通信部１２は、各ユーザ端末からの信号を受信し、所定の復調処理を実施して、ユーザ情報管理部１３、ゲーム管理部１４、マッチング処理部１５、画像生成部１６に復調された信号を送る。また、ユーザ情報管理部１３、ゲーム管理部１４、マッチング処理部１５、画像生成部１６から送られた信号に対して所定の変調処理を実施して、各ユーザ端末に送信する。なお、サーバ通信部１２における変復調処理は、従来用いられている変復調技術が用いられてよく、このような態様であったとしても、本発明を適用することができることは当業者に理解されるところである。

つぎに、図５を用いて、マッチング処理部１５について説明する。図５は、図２のマッチング処理部１５の構成例を示す図である。マッチング処理部１５は、受付部２１０と、マッチング振分部２１１、マッチング情報生成部２１２とを含む。

受付部２１０は、通信回線およびサーバ通信部１２を介して、複数のユーザが使用するユーザ端末のそれぞれから、１以上のユーザが参加可能なネットワークゲームに係るチームバトルへの参加要求を受け付ける。要求には、どのクエストに対するチームバトルへの参加要求であるか、ユーザは誰であるか、どの端末からの要求であるか、等のパラメータを抽出し、サーバメモリ１７に格納するとともに、当該要求をマッチング振分部２１１に出力する。

さらに、受付部２１０は、 参加要求を受け付けたユーザ端末ごとにコメント情報を受け付け、また、ネットワークゲームを進行させるためにエネミーを探索する探索要求を受け付ける。詳細は後述する。

ここで、図６および図７を用いて簡単な説明を行う。図６は、図１のユーザ端末の第１の画面表示例６１０を示す図である。図７は、図１のユーザ端末の第２の画面表示例６２０を示す図である。なお、理解を容易とするためにユーザ端末の画面表示を用いているが、これらの画面表示は、サーバ装置１０のゲーム管理部１４、マッチング処理部１５の指示のもとで画像生成部１６により生成されて、ユーザ端末の画面に表示させたものである。端末の構成や動作については後述するが、画面がタッチパネルによる入力操作を想定して以下の実施の形態を説明するが、マウス操作等による操作であっても構わないものとする。

第１の画面表示例６１０には、ソーシャルゲームの基本画面である、ユーザ固有のマイページ画面３０１と、ゲームを終了する際に用いる戻るボタン３０２と、各種メニューボタン３０３と、他のユーザのアバター３０４と、アバター３０４に対応するコメント欄３０５と、バトルを開始するトリガーとなるハントボタン３０６が表示されている。また、第２の画面表示例６２０には、第１の画面表示例６１０の画面に重畳されるように、クエスト選択画面３０７、アバター３０８、クエスト選択ボタン３０９が表示される。

第１の画面表示例６１０が表示されているときにユーザがハントボタン３０６へ入力操作を行うと、図７に示す第２の画面表示例６２０に画面が遷移して、ハントモードとなり、クエスト選択画面３０７が現れる。ここで、ハントとは、バトルゲーム開始するためのトリガーとなっている。

ハントモードになると、クエスト選択画面３０７には、ハントボタン３０６を入力操作したユーザの情報として、アバター３０８、ユーザ名、ランク、次のランクまでのポイント、残りＬＰ値（Ｌｉｆｅ Ｐｏｉｎｔ）、ＬＰ値ゲージ等が表示される。また、クエスト選択ボタン３０９が複数現れ、ユーザはそのうちの一つを選択する。

なお、クエストは、それぞれ参加人数上限、難易度、獲得報酬等が異なっている。ユーザは、自身のステータスやデッキの強さ等を考慮して、適当なクエストを選択するように入力操作を行う。なお、クエスト選択ボタン３０９には、難易度、獲得報酬等が表示されるようになっている。クエストでは、複数のユーザからなるチームを編成し、エネミーキャラクタと戦うチームバトルが行われる。

クエスト選択ボタン３０９が入力操作されたことをトリガーとして、ユーザ端末は、サーバ装置１０と通信を行い、受付部２１０に参加要求が伝えられることとなる。

図５に戻る。マッチング振分部２１１は、クエスト選択ボタン３０９に入力操作がされたことに応じて、参加要求を行った各ユーザをチームに割り振る処理を行い、その情報をサーバメモリ１７にアップロードするとともに、マッチング情報生成部２１２にも出力する。このような操作は各クエストの参加人数上限に達するまで継続されることとなる。

マッチング情報生成部２１２は、マッチング振分部２１１からの出力と、サーバメモリ１７の情報に基づき、各ユーザ端末に送信するマッチングルーム画像を生成するためのマッチング情報をユーザ端末毎にそれぞれ生成する。具体的には、以下のような例が挙げられる。

・マッチング情報
ユーザ１の情報
ユーザ３の情報
ユーザ２の情報

上記においては、同じクエストに参加要求を行ったユーザの情報を上から参加要求順に記載している。ここで、ユーザ３が２番目に参加要求を行った場合、ユーザ３よりも先にユーザ１の情報がマッチング情報に含まれることとなる。そして、マッチング情報に基づくマッチングルーム画像を生成すると、先にユーザ１のアバターが含まれてしまい、ユーザ３は、後からチームにゲスト参加したという印象を拭えない。そこで、本実施の形態では、上記の順にユーザが参加要求を行った場合であっても、ユーザ３の端末へ最初に送信するマッチングルーム画面を生成するためのマッチング情報を以下のように生成する。

マッチング情報は、クエストに参加するユーザの情報、参加順位を示す情報、過去のクエスト実績などが含まれてもよい。ユーザの情報には、ユーザＩＤやユーザ氏名、あるいは、過去にマッチングされたユーザのＩＤなどが含まれてもよい。クエスト実績には、累積ポイント、勝利回数、参加回数、レベル情報、カード情報などが含まれてもよい。

・マッチング情報（最初）
ユーザ３の情報

つまり、各ユーザの端末に最初に送信するマッチング情報には必ず自身のユーザの情報のみが含まれ、他のユーザの情報は除外するようにしている。

また、ユーザ３のユーザ端末へ２番目に送信するマッチングルーム画面を生成するためのマッチング情報は、例えば、以下の通りとなる。

・マッチング情報（２番目）
ユーザ３の情報
ユーザ１の情報

また、ユーザ３の端末へ３番目に送信するマッチングルーム画面を生成するためのマッチング情報は、例えば、以下の通りとなる。

・マッチング情報（３番目）
ユーザ３の情報
ユーザ１の情報
ユーザ２の情報

上記は、ユーザ３に送信するためのマッチング情報であるが、ユーザ２に送信するためのマッチング情報は、以下のとおりとなる。

・マッチング情報
ユーザ２の情報
ユーザ１の情報
ユーザ３の情報

すなわち、マッチング情報におけるユーザ情報の順序は、通知先の端末のユーザ情報を第１位とし、第２位以降を通知先以外の端末のうち参加順序の早い順となる。なお、マッチング情報におけるユーザ情報の順序は、通知先の端末のユーザ情報を第１位とすれば、第２位以降はランダムにしても良い。

以上のように、本実施の形態においては、端末の操作を行うユーザの情報を優先的にマッチング情報に含め、次のマッチング情報を生成する際に、参加要求順にかかわらず一人ずつユーザの情報を追加していく構成としている。

しかしながらこれにかぎらず、先に送信したマッチング情報との差分のユーザ情報のみが含まれるようにしてもよい。また、２番目以降のマッチング情報は、後述する探索要求を受付部２１０が受け付けたことを契機として生成されてもよい。また、前述した１番目〜３番目のマッチング情報を生成するたびに送信するのではなくて、参加ユーザの数が定員に達した後に生成されたマッチング情報のみを生成してもよい。このような態様であっても、通知先のユーザ端末がもっとも早く参加要求をしたかのごとく示すことができる。これにより、ゲームに参加するそれぞれのユーザに対して、自らがゲーム参加表明の一番手であると認識させることができ、もって、そのチームに対して主体的に積極性を持って貢献することを促せるためゲームが白熱しやすくなる。

上記のようなユーザ端末毎にマッチング情報の生成を行うことにより、各ユーザは自身が最初にマッチングルームに入ったように感じ、主体性が芽生え、ゲームを盛り上げようとすることとなり、全体として白熱したゲームを楽しむことが可能となる。

また、他のユーザの情報が一度に追加されず、一人ずつ徐々に追加されることにより、ゲームへの期待感が徐々に高まり、ユーザは高揚感を感じゲームの興趣性を向上させることができる。

ここで、マッチング情報に含める第２位以降のユーザの情報を追加する際の優先順位について工夫を行ってもよい。以下、簡単に説明する。サーバ装置１０のサーバメモリ１７には、各ユーザ同士の相関を図ることができる過去の履歴情報を有している。例えば、一緒にチームを組んだ回数、直近でチームを組んだ日時からのカウント時間の短さ、ＳＮＳ上のつながり度合、キャラクタ族種、属性、レベル等の相関等に基づき、親和度の高低を判定し、親和度の高いユーザを優先的にマッチング情報に追加するようにしている。このような工夫を行う場合、まず、あるクエストに対して参加要求を行ったユーザのユーザ情報をプールし、その中から、上記の各ユーザ同士の相関を図ることができる過去の履歴情報に基づき、ユーザ同士のマッチングを行う。

親和度の高いユーザの情報が優先的に追加されることにより、端末を操作するユーザにとっては、親しいユーザが急いで集まってきてくれたように感じ、高揚感を高めゲームの興趣性を向上させることができる。また、親和度の高いユーザ同士が同じチームとしてマッチングされるため、ユーザ間で交流が行われる可能性が高まり、ユーザ間の交流をより活性化させることができる。

ここで、図８、図９を用いて、マッチング情報生成部２１２によって生成されたマッチング情報がユーザ端末に通知された際の画面について説明する。図８は、図１のユーザ端末の第３の画面表示例６３０を示す図である。図９は、図１のユーザ端末の第４の画面表示例６４０を示す図である。第３の画面表示例６３０、第４の画面表示例６４０は、参戦アナウンス欄３１５と、タイマー欄３１６と、ユーザ情報の表示欄４０１と、マッチングルーム画像４０２が表示される。

マッチングルーム画像４０２の表示欄４０１には、チームバトルへ参加要求を行い同じチームに割り振られたユーザの情報として、アバター、および、コメントと共に表示される。ここで、マッチングルーム画像４０２には、直近で追加されたユーザの情報に基づき、ユーザ名が表示される参戦アナウンス欄３１５と、チームバトルへの参加締切残り時間を表示するタイマー欄３１６とが表示されている。

図９の第４の画面表示例６４０に示すように、表示欄４０１にユーザの情報が順次表示され、アバタ―画像やコメントが増えていく。つまり、タイマー欄３１６に示された「残り時間３分」における第３の画面表示例６３０では、自身のユーザの情報のみが表示されているだけであったのが、「残り時間２分」における第４の画面表示例６４０では、他のユーザの情報が追加されている。これは、ユーザの参加要求順がいかなる場合であれ、このような順での表示となる。なお、マッチングルーム画面４０２を閲覧するユーザ自身のユーザ情報は不要である場合も多く、その場合は、積極的に自身のユーザの情報をマッチングルーム画面４０２に表示する必要はない。本実施の形態はそれをも内包するものであることは言うまでもない。

つぎに、ユーザ端末において、図７に示した第２の画面表示例６２０におけるクエストボタン３０９が入力操作された後の処理について、図１０を用いて説明する。図１０は、図１のユーザ端末の第５の画面表示例６５０を示す図である。第５の画面表示例６５０には、メニュー画像３１０と、メンバ選択ボタン３１１と、入力欄３１２と、再選択ボタン３１３が表示される。

図７に示した第２の画面表示例６２０のクエストボタン３０９が入力操作された後、第５の画面表示例６５０に画面表示が遷移して、メンバ選択及びコメント入力メニュー画像３１０が表示され、メニュー画像３１０にはチームを編成するメンバの限定をセレクトするメンバ選択ボタン３１１が表示される。

第５の画面表示例６５０においては、メンバ選択ボタン３１１としては２つ表示され、ＳＮＳにおける「友達に限定する」、あるいは、「誰でもＯＫ」のいずれかのモードを選択できる。また、あいさつ文を入力することができる入力欄３１２があり、挨拶コメントを入力することで他のユーザと親交を深めることができる。なお、クエストを選びなおす処理を行うための再選択ボタン３１３も表示される。再選択ボタン３１３が入力操作された場合には、図７に示すクエスト選択画面３０７へ戻る操作が行われる。

ここで、メンバ選択ボタン３１１で「誰でもＯＫ」モードが選択された場合、所定の時間内に同じクエスト選択ボタン３０９を選択したユーザ同士が同じチームに割り振られることとなる。ただし、チームバトルへの参加要求者がそのクエストのチーム上限定員に達すると、チーム割り振りは終了し、チームバトルゲームが進行する。また、チームバトルへの参加上限に到達しないまま、参加締切時間となった場合には、一般のユーザではなく、いわゆるＮＰＣ（Ｎｏｎ Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）を補充してゲームを進めるようにしてもよい。欠員が出た状態では、チームの戦闘力が低下しゲームの進行に支障をきたしたり、ユーザの高揚感が阻害されてしまう恐れがあるからである。

つぎに、ユーザ端末において、メンバ選択ボタン３１１、入力欄３１２へのコメントの入力操作がなされると、当該チームバトルに参加しているそれぞれのユーザ端末において図８の第３の画面表示例６３０、図９の第４の画面表示例６４０に示すようなマッチングルーム画像４０２、あるいは、後述する図１１のコメントスクロール欄３１７において、コメントを入力したユーザ端末に対応するアバタ―画像に対応する態様で当該コメントが表示されることとなる。

マッチングルーム画像４０２は、探索ボタン３１４等のチームバトル用のボタンが複数表示され、入力操作が可能となっている。ユーザは、マッチングルームにおいて、探索ボタン３１４を入力操作することにより、最終的にはエネミーを発見し、編成されたチームによってバトルゲームに突入することとなる。

なお、図８、図９に示す第２の画像表示例６２０、第３の画像表示例６３０は、図１１に示す第３の画像表示例４１０とは、異なる態様のものである。いずれもマッチングルーム画像４０２を表しているが、第２の画像表示例６２０、第３の画像表示例６３０では、チームバトルへ参加要求を行ったユーザの情報が、例えばアバターやコメントが組合わされて整列するように配置されている。

図１１は、ユーザ端末の第６の画面表示例６６０を示す図である。第６の画面表示例６６０には、コメントスクロール欄３１７、３１８、アバター４０３、チームメンバ表示欄４０４が表示される。

具体的には、チームバトルへ参加要求を行ったユーザの情報が、例えばアバター４０３としてチームメンバ表示欄４０４に順次表示され、コメントがコメントスクロール欄３１７、３１８に表示され自動的にスクロールするようにされている。コメントが表示される際には、当該コメントを入力したユーザ端末に対応するアバターが点滅するなどの処理がなされてもよい。以上により、マッチングルーム画像４０２にオーバレイ表示したコメントが流れていくこととなり演出効果が高まる。

チームバトルが開始される前の待ち時間の間、ユーザはマッチングルームにおいて、コメントを用いたチャットを行いながら他のユーザと会話を楽しむことで各ユーザに待ち時間で退屈させないような態様としてもよい。

ここで、具体的に、マッチングルームで待機中のユーザが行うアクションについて説明する。ユーザは、探索ボタン３１４を入力操作することにより、例えばフィールドを探索するミッションゲームを行うことができる。チームバトルを開始するまでの時間を使った余興を行い、ユーザを退屈させないためである。このようなミッションゲームにおいて、ユーザは、経験値、ゲーム内通貨、カードやアイテム等の各種ゲーム媒体を得ることができる。ユーザは、探索ボタン３１４を入力操作する毎に他のユーザが徐々にチームに加わってくることとなる。

なお、このような余興は、ミッションゲームには限定されず、クイズゲームやシューティングゲームであってもよい。また、ミッションゲーム等を行っている際に、「分析中・・・」、「分析結果：敵のデータは・・・弱点は・・・」のようにこれから戦う敵の情報を事前に教えるような表示を出してもよい。このような処理を行うことで、マッチングルーム画面での待ち時間がより有意義なものとなり、ユーザのゲームへの興味関心を高めることができる。

つぎに、チームバトルモードに突入した場合について、図１２を用いて説明する。図１２は、図１のユーザ端末の第７の画面表示例６７０を示す図である。第７の画面表示例６７０は、エネミー５０１、バトル画像５０２、攻撃ボタン５０３が表示された例である。

チームバトルモードでは、バトル画像５０２の欄にエネミー５０１が表示される。第７の画面表示例６７０は、マッチングルーム画面とは異なり、探索ボタン３１４が存在せず、代わりにエネミーに対して攻撃を開始するための攻撃ボタン５０３が表示されている。各ユーザは攻撃ボタン５０３を入力操作することによりエネミーへ攻撃を行う等、バトルを進めて行くこととなる。

つぎに、ユーザ端末側の構成について、図１３を用いて説明する。図１３は、図１のモバイル端末５０あるいはＰＣ端末７０における構成例を示す図である。ここでは、説明の都合上、モバイル端末５０の構成として説明するが、ＰＣ端末７０においても同様の構成となる。

モバイル端末５０は、端末通信部５２と、端末制御部５４と、ユーザインタフェース５６と、端末メモリ５８とを備える。端末通信部５２は、サーバ装置１０からダウンロードしたアプリや、サーバ装置１０から送信される各種情報を受信する。

端末制御部５４は、ユーザインタフェース５６を介してユーザからの指示を受け付けて、端末メモリ５８にアクセスしながら、アプリのインストール制御や、ソーシャルゲームのＡＰＩ制御などを行う。

また、ユーザインタフェース５６は、ユーザへのメッセージ、ソーシャルゲームマッチングルーム画面等の各種画面を表示するための画面インタフェースと、キーボードやタッチパネルなどのユーザからの入力を受け付ける入力インタフェースと、カメラなどの画像撮像手段を含む。

ユーザインタフェース５６は、ユーザからのクエストの選択すなわちチームバトル参加要求、あるいは、各種のコメント入力、アクションボタン操作等を受け付けて、端末制御部５４に伝える。

端末メモリ５８は、アプリ提供プラットフォームからアプリゲームをダウンロードした際に、そのアプリプログラムを格納することに用いられる。また、ブラウザゲームにおいても、キャッシュメモリや、画像データの一時保管等に用いられる。

以下、ユーザＡがチームバトルへ参加要求を行った場合の動作の一例として、ブラウザゲームを想定したユーザ端末の総括的な動作を説明する。

ユーザＡが、ウェブブラウザを立ち上げ、ソーシャルゲームサイトを選択すると端末制御部５４は、端末通信部５２を用いてサーバ装置１０と通信を行いウェブブラウザ上で動作する形でソーシャルゲームのデータを受信しこれを実行する。

ユーザインタフェース５６には、ソーシャルゲームへのログイン手続きを行う案内が表示される場合があるが、ここでは簡略のため説明を省略し、ソーシャルゲームが開始されたものとして説明する。

ユーザインタフェース５６には、図６に示す、第１の画面表示例６１０が表示され、ユーザＡが、ハントボタン３０６へ入力操作を行う。端末制御部５４は、端末通信部５２を用いてサーバ装置１０と通信を行い図７に示すクエスト選択画面３０７をダウンロードし、端末メモリ５８に格納し、クエスト選択画面３０７をユーザインタフェース５６に表示する。

つぎに、ユーザＡが、クエスト選択ボタン３０９へ入力操作を行う。端末制御部５４は、端末通信部５２を用いてサーバ装置１０と通信を行いクエスト選択ボタン３０９が入力されたこと、すなわちチームバトルへの参加要求をサーバ装置１０に送信するとともに、サーバ装置１０から図１０に示すメニュー画面３１０をダウンロードし、端末メモリ５８に格納し、メニュー画面３１０をユーザインタフェース５６に表示する。

つぎに、ユーザＡが、コメント入力欄３１２にコメント入力操作を行い、メンバ選択ボタン３１１へ入力操作を行う。端末制御部５４は、端末通信部５２を用いてサーバ装置１０と通信を行い、入力されたコメント情報とメンバ選択情報をサーバ装置１０に送信するとともに、サーバ装置１０から図８に示すマッチングルーム画像４０２をダウンロードし、端末メモリ５８に格納し、マッチングルーム画像４０２をユーザインタフェース５６に表示する。

ここで、サーバ装置１０では、マッチングルーム画像４０２を生成するに際して、ユーザＡの端末からチームバトルへの参加要請を受け付けた段階で、同じクエストを選択した他のユーザが存在した場合であっても他のユーザの情報はマッチングルーム画像４０２には含めないようにしてユーザ端末に送信している。

つぎに、ユーザＡが、マッチングルーム画像４０２が表示され、探索ボタン３１４へ入力操作を行う。端末制御部５４は、端末通信部５２を用いてサーバ装置１０と通信を行い、探索ボタン３１４に対応するミッションゲームに応じた画像等をサーバ装置１０からダウンロードし、端末メモリ５８に格納し、ミッションゲームに応じた画像をユーザインタフェース５６に表示する。

つぎに、ユーザＡが、マッチングルーム画像４０２が表示された状態で、サーバ装置１０に対して同じクエストへの参加要求をした他のユーザの情報が存在する場合に、サーバ装置１０では、マッチングルーム画像４０２を生成するに際して、図９に示すように、ユーザＡとともに他のユーザの情報をマッチングルーム画像４０２に含めてユーザ端末に送信してもよい。

つぎに、端末制御部５４は、端末通信部５２を用いてサーバ装置１０と通信を行い、サーバ装置１０から図９に示すマッチングルーム画像４０２をダウンロードし、端末メモリ５８に格納し、マッチングルーム画像４０２をユーザインタフェース５６に表示する。

つぎに、サーバ装置１０は、チームバトルへの参加要求の受付時間が経過すると、ユーザ端末にエネミー５０１やチームバトルに参加するユーザの情報を含めたバトル画像５０２を送信する。

つぎに、端末制御部５４は、端末通信部５２を用いてサーバ装置１０と通信を行い、サーバ装置１０から図１２に示すエネミー５０１がダウンロードされ、端末メモリ５８に格納し、エネミー５０１をユーザインタフェース５６に表示する。

つぎに、ユーザＡが、攻撃ボタン５０３へ入力操作を行うと、サーバ装置１０に攻撃をする旨の情報を通信し、バトル処理がサーバ装置１０内で進行する。以後、バトルが終了するまでユーザＡの操作に基づき動作が繰り返され、サーバ装置１０は、エネミー５０１の画像やエネミーの体力消耗を含めたバトル画像５０２をユーザ端末に送信する。

図１４は、図２のマッチング処理部１５の処理手順例を示すフローチャートである。このフローチャートは、ユーザ端末から本ソーシャルゲームを開始する旨の操作が行われたことを契機として開始されてもよい。

まず、マッチング処理部１５は、サーバ通信部１２を介して、ユーザ端末からユーザＡや他のユーザのチームバトルへの参加要求を受け付ける（Ｓ１０）。参加要求は、先にも述べたとおり、クエスト選択ボタン３０９の操作によりなされるものである。参加要求があった場合には、サーバメモリ１７へ、ユーザの情報や端末の情報とともに記憶される。

ここで、参加要求を受け付けたユーザＡにこのクエストにおけるマッチング情報またはマッチングルーム画像を送るのが最初であるかをサーバメモリ１７の記録より判断し、最初である場合（Ｓ１１のＹｅｓ）には、他のユーザの情報を含めずにマッチング情報を生成する（Ｓ１２）。一方、最初でない場合（Ｓ１１のＮｏ）には、チームバトルへの参加要求を行っている他のユーザのうち、例えば一番先に参加要求を行ったユーザの情報を一人分含めてマッチング情報を生成する（Ｓ１４）。このとき、各ユーザ同士の相関を図ることができる過去の履歴情報を用いて、チームバトルへの参加要求を行っている他のユーザのうち、ユーザＡと親和度の高いユーザを抽出し、その中のユーザの情報を一人分含めてマッチング情報を生成してもよい。

つぎに、生成されたマッチング情報をユーザＡのユーザ端末に送信する（Ｓ１３）。ここで、マッチング情報に基づきマッチングルーム画像を生成してユーザ端末に送信することも可能であることは上述で説明したとおりである。

最後に、マッチング処理部１５は、マッチング時間が終了したか、チームバトルへの参加人数が上限に達したか等、マッチングを終了すべき状態にあるかを判断し、終了であれば（Ｓ１５のＹｅｓ）処理を終え、終了でなければ（Ｓ１５のＮｏ）、終了条件になるまでフローを繰り返す処理を行う。

図１５は、図１３の端末制御部５４の処理手順例を示すフローチャートである。このフローチャートは、ユーザ端末にゲームアプリケーションプログラムをインストールするアプリゲームに適用した場合において、ユーザ端末から本ソーシャルゲームを開始する旨の操作が行われたことを契機として開始される。

まず、端末制御部５４は、ユーザインタフェース５６からユーザＡのチームバトルへの参加要求の操作を受け付ける端末通信部５２を介してサーバ装置１０に参加要求情報を送信する（Ｓ２０）。参加要求は、先にも述べたとおり、クエスト選択ボタン３０９の操作によりなされるものである。

つぎに、端末制御部５４は、端末通信部５２を介して、サーバ装置１０からその時点で同じクエストに参加要求を行っているすべてのユーザの情報を取得する（Ｓ２１）。上述では、サーバ装置１０にてマッチング情報の加工を行っているが、アプリゲームの場合は端末側でその処理を行うことができるためすべてのユーザの情報を取得しても問題はない。本実施の形態における一つの変形例である。

ここで、端末制御部５４は、参加要求を受け付けたユーザＡにこのクエストにおけるマッチング情報またはマッチングルーム画像を生成するのが最初であるかを判断し、最初である場合（Ｓ２２のＹｅｓ）には、他のユーザの情報を含めずにマッチング情報を生成しこれに基づくマッチングルーム画像を生成する（Ｓ２３）。一方、最初でない場合（Ｓ２２のＮｏ）には、チームバトルへの参加要求を行っている他のユーザのうち、例えば一番先に参加要求を行ったユーザの情報を一人分含めてマッチング情報を生成する（Ｓ２５）。このとき、各ユーザ同士の相関を図ることができる過去の履歴情報を用いて、チームバトルへの参加要求を行っている他のユーザのうち、ユーザＡと親和度の高いユーザを抽出し、その中のユーザの情報を一人分含めてマッチング情報を生成しこれに基づくマッチングルーム画像を生成してもよい。なお、親和度を判断するパラメータは端末側で保持しているものを使ってもよいし、サーバ装置１０と通信を行い取得するなどいずれの方法を用いてよい。

つぎに、端末制御部５４は、生成したマッチングルーム画像をユーザインタフェース５６に表示する（Ｓ２４）。

最後に、端末制御部５４は、マッチング時間が終了したか、チームバトルへの参加人数が上限に達したか等、マッチングを終了すべき状態にあるかを判断し、終了であれば（Ｓ２６のＹｅｓ）処理を終え、終了でなければ（Ｓ２７のＮｏ）、終了条件になるまでフローを繰り返す処理を行う。なお、マッチングを終了すべき状態にあるか否かを判断するパラメータの取得は、参加要求情報の取得（Ｓ２１）において適宜行えばよい。

以上のように、各態様に応じて説明を行ったが、マッチング処理を行うに際して、チームのマッチング状況を示すマッチング情報もしくは端末側で表示されるマッチング画像（マッチングルーム画像）に、それぞれのユーザにとって自身が一番最初にチームに参加したと感じさせることで、ユーザのソーシャルゲームへの主体性を大きく向上させ、各ユーザがこのソーシャルゲームに積極的に参加することとなり、ゲーム全体が白熱して面白くなるといった効果を得ることができる。

以上、本発明を実施例をもとに説明した。本発明は上述した実施例並びに各実施例の内容に限定されるものではなく、本発明の要旨の範囲内において種々に変形して実施をすることが可能である。上記実施例は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施例１にかかるソーシャルゲームシステムの構成例を示す図である。 図１のサーバ装置の構成例を示す図である。 図２のユーザ情報管理部において管理されるユーザ管理データの一例を示す図である。 図２のユーザ情報管理部において管理されるカード管理データの一例を示す図である。 図２のマッチング処理部の構成例を示す図である。 図１のユーザ端末の第１の画面表示例を示す図である。 図１のユーザ端末の第２の画面表示例を示す図である。 図１のユーザ端末の第３の画面表示例を示す図である。 図１のユーザ端末の第４の画面表示例を示す図である。 図１のユーザ端末の第５の画面表示例を示す図である。 図１のユーザ端末の第６の画面表示例を示す図である。 図１のユーザ端末の第７の画面表示例を示す図である。 図１のモバイル端末あるいはＰＣ端末における構成例を示す図である。 図２のマッチング処理部の処理手順例を示すフローチャートである。 図１３の端末制御部の処理手順例を示すフローチャートである。

１０ サーバ装置、 １２ サーバ通信部、 １３ ユーザ情報管理部、１４ ゲーム管理部、 １５ マッチング処理部、 １６ 画像生成部、 １７ サーバメモリ、 ３０ ネットワーク、 ４０ 基地局、 ４０ａ 第１基地局、 ４０ｂ 第２基地局、 ４０ｃ 第３基地局、 ５０ モバイル端末、 ５０ａ 第１モバイル端末、 ５０ｂ 第２モバイル端末、 ５０ｃ 第３モバイル端末、 ５２ 端末通信部、 ５４ 端末制御部、 ５６ ユーザインタフェース、 ５８ 端末メモリ、 ７０ ＰＣ端末、 １００ ソーシャルゲームシステム、 ２１０ 受付部、 ２１１ マッチング振分部、 ２１２ マッチング情報生成部、 ３０１ マイページ画面、 ３０２ 戻るボタン、 ３０３ メニューボタン、 ３０４ アバター、 ３０５ コメント欄、 ３０６ ハントボタン、 ３０７ クエスト選択画面、 ３０８ アバター、 ３０９ クエスト選択ボタン、 ３１０ メニュー画像、 ３１１ メンバ選択ボタン、 ３１２ 入力欄、 ３１３ 再選択ボタン、 ３１４ 探索ボタン、 ３１５ 参戦アナウンス欄、 ３１６ タイマー欄、 ４０１ 表示欄、 ４０２ マッチングルーム画像、 ４０３ アバター、 ４０４ チームメンバ表示欄、 ５０１ エネミー、 ５０２ バトル画像、 ５０３ 攻撃ボタン、 ６１０ 第１の画面表示例、 ６２０ 第２の画面表示例、 ６３０ 第３の画面表示例、 ６４０ 第４の画面表示例、 ６５０ 第５の画面表示例、 ６６０ 第６の画面表示例、 ６７０ 第７の画面表示例。

Claims (8)

1. 通信回線を介して、複数のユーザが使用する端末装置のそれぞれから、１以上のユーザが参加可能なネットワークゲームに対する参加要求を受け付ける受付部と、
   前記受付部により参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成し、参加要求を受け付けたそれぞれの端末装置に対して、生成したマッチング情報を通知するマッチング処理部と、
   を備え、
   前記マッチング処理部は、
   通知先のユーザごとに、通知先ユーザのユーザ情報のみが含まれた第１マッチング情報と、通知先ユーザ以外のユーザ情報が少なくとも含まれた第２マッチング情報とを生成するマッチング情報生成部と、
   前記マッチング情報生成部によって生成されたうちの第１マッチング情報を通知し、その後に、第２マッチング情報を通知するマッチング情報送信部と、
   を備えたサーバ装置。
2. 前記マッチング情報生成部は、第１マッチング情報を生成し、その後に、第２マッチング情報を生成する
   ことを特徴とする請求項１に記載のサーバ装置。
3. 前記受付部は、前記ネットワークゲームを進行させるための探索要求を受け付け、
   前記マッチング情報生成部は、前記受付部が探索要求を受け付けたことを契機として、第２マッチング情報を生成すること
   を特徴とする請求項１または２に記載のサーバ装置。
4. 前記マッチング情報生成部は、第２マッチング情報を生成する際に、通知先の端末装置のユーザとの間で親和度の高い他のユーザのユーザ情報が優先的に含まれるようにマッチング情報を生成すること
   を特徴とする請求項１から３のいずれかに記載のサーバ装置。
5. 前記受付部は、参加要求を受け付けた端末装置ごとにコメント情報を受け付け、
   前記マッチング情報生成部は、同時期に開始される同一のネットワークゲームに参加するそれぞれの端末装置に通知すべきマッチング情報として、前記受付部によって受け付けたコメント情報を含めること
   を特徴とする請求項１から４のいずれかに記載のサーバ装置。
6. 前記マッチング処理部は、マッチング情報に対して、通知先の端末装置のユーザ情報を第１位とした参加順位情報を含め、第２位以降を通知先以外の端末装置のうち参加順序の早い順にユーザ情報を含める
   ことを特徴とする請求項１から５のいずれかに記載のサーバ装置。
7. 前記ユーザ情報は、ユーザ識別情報、ユーザ名、アバター、および、ユーザが入力したコメントのうちのいずれか１つ以上を含むこと
   を特徴とする請求項１から６のいずれかに記載のサーバ装置。
8. 複数のユーザが使用する端末装置のそれぞれから、１以上のユーザが参加可能なネットワークゲームに対する参加要求をサーバ装置が受け付けるステップと、
   サーバ装置が、参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成し、参加要求を受け付けたそれぞれの端末装置に対して、生成したマッチング情報を通知するステップと、
   を含み、
   前記通知するステップは、
   通知先のユーザごとに、通知先ユーザのユーザ情報のみが含まれた第１マッチング情報と、通知先ユーザ以外のユーザ情報が少なくとも含まれた第２マッチング情報とをサーバ装置が生成するステップと、
   サーバ装置が、生成されたうちの第１マッチング情報を通知し、その後に、第２マッチング情報を通知するステップと、
   を含む
   ことを特徴とする方法。

Images