説明

マッチングサーバ及びネットワークゲーム基盤システム

【課題】ネットワークゲームにおいて、ネットワーク性能を考慮したマッチングを行う。
【解決手段】マッチングサーバ1は、ネットワーク情報提供サーバ2の有するネットワーク情報を部分ネットワーク情報1aとして受信し、当該情報におけるネットワークのセグメント分けに基づいて、各ユーザのゲーム参加グループを管理・更新するマッチング情報1bを保持する。マッチングサーバ1はユーザからのマッチング要求に対して、マッチング情報1bと、部分ネットワーク情報1aを参照して調べられる当該ユーザの所属セグメントと、に基づいて所属グループを決定して通知すると共に、マッチング情報1bを更新する。またユーザからのゲーム終了通知時にも、マッチング情報1bを更新する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、マッチングサーバ及びネットワークゲーム基盤システムに関し、特に、グループにて実行されるネットワークゲームに参加するユーザの所属グループを決定するマッチングを、当該ネットワークゲームが低遅延で実行されるように行うマッチングサーバ、及び当該マッチングサーバを含むネットワークゲーム基盤システムに関する。
【背景技術】
【0002】
本発明の従来技術として、複数ユーザのマッチングを行うネットワークゲームが該当する。このマッチングとは、ネットワークゲームにおいて、互いに対戦して勝敗を競うユーザや、ゲーム内で一緒に行動するユーザを、決定することである。1つ(1種類)のネットワークゲームにおいて、複数のグループが作成され、各グループに所属するユーザ同士で当該ネットワークゲームが実行される。一般には、グループの最大人数は決まっている。従来のマッチングでは、ユーザ自身がグループを選択する方式や、人数が最大数に達していないグループから順にユーザを割り当てていく方式などが採用されている。
【0003】
また、標準化機関であるIETF(Internet Engineering Task Force)では、P2P(ピアツーピア)配信などのアプリケーションに対して、ISP(Internet Service Provider)が持つ情報を提供することで、アプリケーションの品質向上やISP内のトラヒック制御などを実現するフレームワークの標準化を行っている。当該標準化に関しては、以下の非特許文献1(IETF ALTO WG [WG:Working Group])に開示されている。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】IETF ALTO WG http://tools.ietf.org/wg/alto/
【発明の概要】
【発明が解決しようとする課題】
【0005】
従来のネットワークゲームにおけるマッチングでは、ユーザのネットワーク性能や、ネットワーク性能を実現する上でのユーザ間の相性(例えば各ユーザの所属ネットワーク)などが考慮されていなかったため、ネットワークゲームが求めるネットワーク性能に対して、ユーザのネットワーク性能が追い付かないという状況が発生していた。また、ユーザのネットワーク性能に関する情報を予め把握する手段もなかったため、ユーザのネットワーク性能に応じてネットワークゲームとしての通信手段を最適化することも難しかった。
【0006】
すなわち例えば、図8に示すように、ネットワークN1,N2,N3の接続構成がN1−N2−N3と、N2を介してN1とN3が離れて接続している構成において、N1に属するユーザU1,U2と、N3に属するユーザU3と、の3ユーザ参加によるネットワークゲームを、N1に属するゲームサーバG1の元で実行する、というようなことが起きていた。この場合例えば、G1とU1,U2間の通信と、G1とU3間の通信との同時最適化が困難であった。さらに、各ユーザU1乃至U3のユーザ端末(PC又はゲーム端末など)の性能バラツキによっても、当該最適化は困難であった。
【0007】
このため、従来技術によるマッチングで、ネットワークゲームを実行した場合、遅延が大きくなる、という事態が一般的であった。例えば、東京と九州のユーザが通信する場合、伝搬遅延やルータでのキューイング遅延を含め、ネットワーク部分だけで、例えば30〜50ミリ秒の遅延が発生しうる。さらにアクセス回線がADSL(Asymmetric Digital Subscriber Line、非対称デジタル加入者線)のユーザや、低スペックなPCを持つユーザが混在している場合、全体として発生しうるネットワーク遅延が数100ミリ秒のオーダになることが予測される。また、これらの情報が既知でないため、アプリケーションとして、遅延が何ミリ秒程度であるかということを考慮した最適な設計がしにくいという問題もあった。
【0008】
本発明の目的は、上記した従来技術の課題を解決し、好ましいネットワーク性能の、特に、低遅延なネットワークゲームを実行可能とするマッチングサーバ及びネットワークゲーム基盤システムを提供することにある。
【課題を解決するための手段】
【0009】
前記目的を達成するため、本発明は、グループにて実行されるネットワークゲームに参加するユーザの所属グループを決定するマッチングを行うマッチングサーバであって、当該ネットワークゲームの行われるネットワークをセグメントに分けて識別する情報を含むネットワーク情報を保持するネットワーク情報提供サーバより、前記ネットワーク情報の一部である部分ネットワーク情報を受信して保持する受信・保持手段と、当該ネットワークゲームに参加中である、又は当該ネットワークゲームの開始待機中である各ユーザの情報と、該各ユーザの所属グループの情報と、を含むマッチング情報を管理するマッチング手段とを備え、該マッチング手段は、当該ネットワークゲームに参加しようとするユーザからマッチング要求を受信した場合、前記部分ネットワーク情報を参照して求められる当該要求ユーザの所属セグメントと、前記マッチング情報と、に基づいて当該要求ユーザの所属グループを決定して当該要求ユーザに通知することを特徴とする。
【0010】
また、前記目的を達成するため、本発明は、前記マッチングサーバにより所属グループを決定されたユーザ同士にて実行するネットワークゲームでの通信を支援するネットワークゲーム基盤システムであって、前記マッチングサーバと、当該所属グループに属するユーザの存在する前記セグメント内に配置される通信制御サーバとを備え、該通信制御サーバが、当該所属グループ内で実行されるネットワークゲームでの通信を支援することを特徴とする。
【発明の効果】
【0011】
本発明のマッチングサーバによれば、ネットワークゲームに参加しようとマッチング要求をするユーザに対して、当該ユーザのネットワーク内の所属セグメントに基づいて所属グループが決定されるので、ネットワーク距離が所定の範囲内に収まるユーザ同士のグループにより、低遅延なネットワークゲームを実行可能となる。
【0012】
また本発明のネットワークゲーム基盤システムによれば、前記マッチングサーバによるグループ分けがなされたグループにてネットワークゲームを実行するに際しての通信を、当該グループのユーザが所属するセグメント内に配置される通信制御サーバによって支援するので、低遅延なネットワークゲームが実行可能となる。
【図面の簡単な説明】
【0013】
【図1】本発明のマッチングサーバを含むシステムのブロック図である。
【図2】図1におけるマッチングサーバ内の機能ブロックを更に示す図である。
【図3】(A)ISP内のネットワークが物理的に複数のセグメントで構成されることと、(B)当該セグメント内でそれぞれグループが作成されることと、(C)そのようなセグメントに基づくグループが作成される場合のネットワーク情報と、を例示する図である。
【図4】第2実施例と第3実施例との両者を適用した場合のマッチング情報の例を示す図である。
【図5】マッチング情報が更新される処理を示すフローチャートである。
【図6】マッチングサーバにより決定された各グループの属するセグメント毎に、通信制御サーバを配置することを説明する図である。
【図7】本発明のネットワークゲーム基盤システムのブロック図である。
【図8】従来技術のマッチングにより、ネットワーク性能が考慮されないネットワークゲームのグループが作成される例を示す図である。
【発明を実施するための形態】
【0014】
以下に、図面を参照して本発明を詳細に説明する。図1は、本発明のマッチングサーバ1を含むブロック図であり、特にユーザ及びネットワーク情報提供サーバ2との応答部分にフォーカスした構成の図である。ネットワーク情報提供サーバ2は、ネットワーク情報2aを保持し、マッチングサーバ1からのネットワーク情報要求に応じて、自身が保持するネットワーク情報の一部であり、当該要求を受けた部分である、部分ネットワーク情報を返信する。
【0015】
マッチングサーバ1は、当該返信により更新される部分ネットワーク情報1aとマッチング情報1bとを保持する。また、ネットワークゲームを開始しようとするユーザからのマッチング要求を受信して、当該要求ユーザにとって最適なグループを決定して通知する。さらに、ネットワークゲームを終了するユーザから、ゲームを終了する旨の通知を受信する。マッチングサーバ1は、ユーザよりこれらゲーム開始/終了のいずれの通知を受けた場合も、マッチング情報1b内の、当該ユーザのゲーム参加状態の情報を更新する。
【0016】
次に、ネットワーク情報提供サーバ2にて保持される、ネットワーク情報2aの内容について説明する。ネットワーク情報2aとは、ユーザプロファイル情報、ネットワークドメイン情報など、一般にISPが有する情報の総称である。ユーザプロファイルの情報には、ユーザのIPアドレス、ユーザの所属地域(固定回線のユーザの場合、自宅住所の所属地域など、携帯電話ユーザの場合、位置情報など)、契約サービス(固定か移動か、帯域、など)、通信品質実績などが存在する。ネットワークドメイン情報には、アドレス空間とネットワークとの対応付けの情報などが存在する。
【0017】
部分ネットワーク情報1aは、ネットワーク情報提供サーバ2への頻繁な問い合わせを避けるために、マッチングサーバ1が、ネットワーク情報2aの一部をユーザからの要求が発生する前に取得したり、あるいは、先に取得したネットワーク情報2aの一部を、次回以降のユーザからの問い合わせに備えてキャッシュとして残しておくものである。
【0018】
図2にマッチングサーバ1の機能ブロック図を示し、当該キャッシュの説明と、後述のマッチングサーバ1の各種動作詳細の説明をする。マッチングサーバ1は、部分ネットワーク情報1aを前述のように受信・保持する受信・保持手段10と、マッチング情報1bを前述のようにユーザ通知を反映させて管理すると共にユーザへのグループ通知を行うマッチング手段11とを備える。
【0019】
キャッシュの場合は、まず、ユーザからのマッチング要求をマッチング手段11が受信し、当該ユーザを例えばユーザAとして受信パケットの情報などによって識別する。そして、受信・保持手段10からネットワーク情報提供サーバ2に対して、ユーザAのネットワーク情報を部分ネットワーク情報1a(の更新すべき部分)として送信するよう要求する。当該情報を受信して、部分ネットワーク情報1aを更新する。さらに、マッチング手段11は、更新された部分ネットワーク情報1aにおけるユーザAの情報により、マッチング情報1bを参照することで、所属グループを決定してユーザAに通知し、マッチング情報1bにおいてユーザAの情報を更新する。
【0020】
以降、所定期間が経過するまでは、ユーザAから追加でマッチング要求があった場合は、ネットワーク情報提供サーバ2にはアクセスせず、部分ネットワーク情報1aにおけるユーザAの情報を参照して、グループを通知する。なおまた、キャッシュ更新のタイミングの別実施形態として、上記のように所定期間経過後で且つユーザからマッチングを要求したときではなく、所定期間毎に受信・保持手段10が自動で行うようにしてもよい。
【0021】
また、別実施形態では、キャッシュを用いず、ユーザからマッチング要求がある度にネットワーク情報提供サーバ2にアクセスして、当該ユーザに関する部分ネットワーク情報を取得してもよい。この場合、頻繁にネットワークの構成変更がある場合においても、最新のネットワーク情報を取得してマッチングに反映できるという効果がある。
【0022】
次に、本発明を適用する最もシンプルな実施例(第1実施例)を示す。その後、第1実施例を応用した第2、第3実施例を説明するが、これら各実施例は、部分ネットワーク情報1aとマッチング情報1bとで、どのような基準でユーザをグループ分け(マッチング)するか、という区別に基づくものである。
【0023】
[第1実施例]
ISP内のネットワークは、図3の(A)に示すように、物理的に複数のセグメント(セグメント#1,#2,#3,…)で構成されており、セグメント内の遅延は小さく、セグメント間の遅延は大きいものとする。すなわち、同一セグメント内の端末間ではネットワーク的な距離が所定範囲内であり、異なるセグメントに属する端末間ではネットワーク的な距離が所定範囲を越える。ISPは、ネットワーク情報提供サーバ2におけるネットワーク情報2aとして、各セグメントに割り当てるIPアドレス空間の集合をプレフィクスにより管理する。すなわち図3(A)に示すように、例えば、セグメント#1にはプレフィクス10.0.0.0/24,10.0.1.0/24,…が、セグメント#2にはプレフィクス11.0.0.0/24,11.0.1.0/24,…が、セグメント#1にはプレフィクス12.0.0.0/24,12.0.1.0/24,…が、属するものとして、ネットワーク情報提供サーバ2にて管理される。
【0024】
ユーザは自身が所属する地域に応じて、いずれかのセグメントよりIPアドレスの払い出しを受ける。マッチングサーバ1は、前述のキャッシュを用いない実施形態であれば、マッチング手段11にてユーザよりマッチング要求を受信した際、受信・保持手段10より当該ユーザのIPアドレスがマッチ(周知の最長一致[longest match])するセグメントをネットワーク情報提供サーバ2に問い合わせ、セグメントIDを受信する。またキャッシュを用いる実施形態であれば、図3(A)に示すようなセグメントとアドレス空間に関するネットワーク情報2aを予めネットワーク情報提供サーバ2より受信しておく。当該キャッシュのための受信は、マッチングサーバ1にアクセスするユーザに関する部分の情報のみであってもよいし、当該ISP内の全セグメントを把握できる情報であってもよい。
【0025】
上記のようにして、キャッシュ使用有無のいずれの実施形態においても、受信・保持手段10の部分ネットワーク情報1aによって当該要求ユーザの所属セグメントを調査できるようになる。マッチング手段11は当該要求ユーザの所属セグメントを調査し、セグメントが同じユーザがグループ化されるようにマッチングを行う。従って、各グループの情報としてはユーザのリストに加えて、セグメントIDが管理される。当該第1実施例においては、この仕組みにより、同一セグメントのユーザが自動的にマッチングされ、グループ内のユーザ間で低遅延の通信環境を実現することができる。
【0026】
当該第1実施例における、グループの作成される例を図3の(B)に示す。これは同図(A)に示すようなネットワーク構成における場合における例であり、セグメント#1にグループ#1,#3が、セグメント#2にグループ#2が、セグメント#3にグループ#4が作成されている。当該ゲームが最大4人で実行されるゲームであるとすると、グループ#1,#2は最大人数に達している。またグループ#3,#4は最大人数に達していないので、さらにグループ内に参加ユーザの追加が可能である。
【0027】
また、図3(B)の例に対応するマッチング情報1bの例を図3(C)に示す。マッチング情報1bは、グループIDと、セグメントIDと、所属ユーザのユーザリストとを対応付けて並べたテーブル形式によって与えられる。セグメントID=1のセグメント内のIPアドレスは同図(A)に示すように、プレフィクス10.0.0.0/24,10.0.1.0/24,…に属するアドレスである。よって当該プレフィクスにマッチするユーザにより、最大人数4人に達したグループ1(所属ユーザ10.0.0.24, 10.0.1.3, 10.0.1.8, 10.0.0.154)と、最大人数4人には達していないグループ3(所属ユーザ10.0.0.55, 10.0.1.39)とが管理されている。同様にしてセグメントID=2のセグメント内のグループ2(所属ユーザ11.0.0.177, 11.0.1.31, 11.0.0.10, 11.0.0.131で最大人数に達している)と、セグメントID=3のセグメント内のグループ4(所属ユーザ12.0.1.143, 12.0.1.79, 12.0.0.8で最大人数には達していない)と、が管理されている。
【0028】
このように第1実施例では、ユーザの所属セグメントによってグループ分けを行うことにより、低遅延の、又は発生しうる遅延が想定しえる範囲内に収まる、すなわちネットワーク性能のよい、又はネットワーク性能が所定範囲内である、グループを決定することができるという効果がある。
【0029】
[第2実施例]
ユーザのアクセス回線の速度も通信の速度に影響する。この点に注目し、第2実施例では、マッチング情報1bにおいて、第1実施例におけるユーザリスト、セグメント情報に対して、さらにアクセス回線情報を追加してグループを管理する。
【0030】
例えば、FTTH(Fiber To The Home、光ファイバー)回線のユーザだけでグループを作成することで、より遅延の小さい通信環境を実現することが可能である。ISPが、アクセス回線毎にセグメントを分けて運用している場合には、上記の第1実施例と同じ手法で、本目的(例えばFTTH回線ならば、FTTH回線のユーザだけでグループを作成)を実現することが可能である。アクセス回線の区別が、セグメント分けの区別自体に含まれているからである。
【0031】
一方、アクセス回線とセグメント分けとが連動していない場合には、ユーザの契約情報などとの照合が必要となる。このような契約情報なども、前述のとおりネットワーク情報提供サーバ2のネットワーク情報2aに含まれるので、これをマッチングサーバ1において部分ネットワーク情報1aとして利用する。すなわち、ユーザからのマッチング要求を受信した際、マッチングサーバ1はユーザのアクセス回線をネットワーク情報提供サーバ2に問い合わせ、その結果と自身が有するマッチング情報1bとを用いて、グループを決定する。また、前述の通り、毎回ネットワーク情報提供サーバに問い合わせるのではなく、キャッシュを利用してもよい。
【0032】
以上のように、第2実施例では、ユーザの所属セグメントと、さらにアクセス回線と、によってグループ分けを行うことで、ネットワークゲームを実行するに際して、ネットワーク性能のよいグループを決定することができる。
【0033】
[第3実施例]
ユーザ端末(PC又はゲーム端末など)の性能も、通信の遅延に影響する。この点に注目し、第3実施例では、マッチング情報1bにおいて、第1実施例における情報に追加して、ユーザ品質実績に関わる情報を含めてグループを管理する。
【0034】
例えば、品質実績がよいユーザだけでグループを作成することで、より遅延の小さい通信環境を実現することが可能である。なお、品質実績は速度実績により評価するものとする。例えば、品質実績がよいと判断する基準として、通信速度が、上りX Mbps以上、下りY Mbps以上(X、Yは所定値)であること、を基準とする。ユーザからのマッチング要求が来た際、マッチングサーバ1は当該ユーザの品質実績情報をネットワーク情報提供サーバ2に問い合わせ、又はキャッシュとして保存している品質実績情報に基づき、その情報と自身が有するマッチング情報1bとを用いて、グループを決定する。
【0035】
なお、ネットワークゲームの性質に応じて、通信品質がよいユーザだけでグループ化させることや、通信品質のバランスを考えて(1グループが6人のゲームにおいて、良いユーザを3人、悪いユーザを3人としてグループを作るなど)グループ化させることなどが可能である。
【0036】
通信品質実績の収集には、専用の測定サーバを設置し、ユーザのマッチング要求後のマッチング開始前に測定サーバへの送受信トラヒックを発生させて測定すればよい。すなわち、当該所定のサーバへのトラヒック上り速度又は下り速度の少なくとも一方を測定して、測定結果が前述の例(上りX Mbps以上、下りY Mbps以上、など。X、Yは所定値)のような、所定範囲にあるか否かをマッチング手段11にて判定して、グループを決定する。
【0037】
所定ユーザに対して上述の専用測定サーバによる測定結果を一度求めれば、所定期間の間、部分ネットワーク情報1aにて当該結果を保存しておいて、キャッシュを利用することもできる。またネットワーク情報提供サーバ2のネットワーク情報2aにて各ユーザの通信品質実績の情報が獲得できるならば、第1実施例及び第2実施例と同様の流れで通信品質実績の情報を獲得してもよい。なお、上記のように、専用測定サーバを用いるなどしてマッチング要求時に品質実績を評価することで、当該ユーザが実際にネットワークゲームを実行するときの品質実績に近い評価が得られる傾向が強まる、という効果がある。
【0038】
以上のように、第3実施例では、ユーザの所属セグメントと、さらにユーザの端末の性能(通信品質実績)情報と、によってグループ分けを行うことで、ネットワークゲームを実行するに際して、ネットワーク性能のよいグループを決定することができる。
【0039】
第2実施例と第3実施例とは、組み合わせて実施することも可能であり、この場合のマッチング情報1bの例を図4に示す。すなわち、マッチング要求ユーザが各グループに振り分けられるに際して、セグメントID、アクセス回線種別及び通信速度実績(上り速度、下り速度に対する制限条件)に基づいて、所属グループが決定される。この例では、アクセス回線の種別はFTTH又はADSLであり、FTTH回線の場合、さらに、通信速度実績が上り速度10Mbps以上且つ下り速度20Mbps以上を満たすユーザと、当該条件を満たさないユーザとを分けるようになっている。例えばFTTH回線のユーザで且つ上記通信速度条件を満たすユーザのグループが2つ(グループID1及び2のグループ)存在し、FTTH回線のユーザで且つ上記通信速度条件を満たさない(図中では、上り速度、下り速度共に「制約なし」として表記)ユーザのグループが1つ(グループIDが5のグループ)存在している。
【0040】
なお、図4の例は、「上り速度」および「下り速度」の欄が存在しないものとすれば第2実施例におけるマッチング情報1bの例となり、「回線種別」の欄が存在しないものとすれば第3実施例におけるマッチング情報1bの例となる。
【0041】
以上、第1乃至第3実施例を用いてマッチング情報1bの各実施例を説明した。マッチングサーバ1のマッチング手段11が、このようなマッチング情報1bを随時更新して管理するフローチャートを図5に示す。マッチング情報1bが更新されるのは、ユーザよりマッチング要求を受信した場合、又はゲーム参加/待機中のユーザよりゲームを終了する通知を受信した場合、である。更新フローを開始し、最初のステップS1では、ユーザからの受信の種類がこのいずれであるかによって場合分けを行う。まず、マッチング要求を受信したものとし、この場合から説明する。この場合はステップS2へと進む。
【0042】
ステップS2では、マッチング手段11が、マッチング情報1bと、部分ネットワーク情報1aを参照して得られる当該要求ユーザの所属セグメントなどと、に基づいて、当該要求ユーザの所属グループを決定する。当該グループ決定においては前述の通り、第1実施例では所属セグメントに基づいて決定され、第2,第3実施例ではさらにそれぞれ利用アクセス回線、通信速度実績に基づいて決定される。また前述の通り、部分ネットワーク情報1aとしてキャッシュを用いない場合は、受信・保持手段10に対してネットワーク情報提供サーバ2より当該要求ユーザに関連する部分ネットワーク情報を送信させ、受信・保持手段10における部分ネットワーク情報1aを更新してから、決定する。
【0043】
なお、グループを決定するにあたっては、全ての条件(所属セグメントなど)に合致し、且つ最大人数には達していないグループをマッチング情報1bの中から選択することで、決定される。該当するグループが存在しない場合には、当該条件のグループをグループIDと対応づけて新たに作成し、決定グループとする。
【0044】
ステップS3では、当該決定したグループを要求ユーザに通知する。当該ユーザはグループ通知を受けると、所定のゲームサーバにログインするなどして、当該決定グループに所属することでネットワークゲームを開始する、又はネットワークゲーム開始を待機する状態に移る。基本的には、所属グループがネットワークゲームにて設定される最大人数に達すればゲームを開始し、達していなければ、別ユーザがマッチング後に当該グループに加入して、グループ人数が最大人数に達するまで待機する。しかし、ゲームの種類や設定によっては、最大人数に達していなくても、既にグループに所属しているユーザのみでゲームを実行するようにしてもよい。このような、既にゲームを実行中のグループにマッチングしたユーザは、当該ゲームに途中から参加することとなる。
【0045】
ステップS4に進み、上記のステップS3におけるユーザの状態の遷移(ゲームに参加していない状態から、ゲーム参加又は待機の状態に移る)があるという前提のもと、当該ステップS2におけるユーザの所属グループ決定を、マッチング情報1bに反映させて更新する。すなわち当該ユーザを当該グループのユーザリストに追加する。新たに作成したグループであれば、当該グループ自体を登録して、且つそのユーザリストに当該ユーザを最初のユーザとして登録することで、マッチング情報1bを更新する。
【0046】
なお、ユーザがゲーム参加/待機状態に移ったことを確認するために、ユーザより当該状態に移った旨の通知をマッチング手段11にて受けてからステップS4を実行するようにしてもよい。
【0047】
上記のステップS4の説明(また後述のステップS5の説明)より明らかなように、図3(C)や図4で例を示したようなマッチング情報1bにおけるユーザリストに、あるユーザが載っている、すなわち登録されているということは、当該ユーザが対応するグループに所属して、ゲームに参加又はゲーム開始を待機している状態にあることを意味している。前述の第1乃至第3実施例ではグループ振り分け基準にフォーカスして説明したので、マッチング情報1bのこのような性質に関して強調して説明していなかったが、マッチング情報1bはこのような性質を有するものである。
【0048】
また、ステップS1に戻り、ユーザからゲーム終了通知を受信した場合の説明をする。この場合はステップS5へ進む。ユーザがゲームを終了する場合は、自動的にマッチング手段11が終了通知を受信するよう、ゲームサーバなどに設定しておいてもよい。当該ゲーム終了通知に関しても、上記と同様の理由で、前述の第1乃至第3実施例では説明していないが、これらの例においてもステップS5は適宜、実施されている。
【0049】
ステップS5では、ゲームを終了するユーザを、マッチング情報1b内のユーザリストから除外する。当該終了ユーザはユーザリストに載っていない状態となるので、マッチング情報1bにおいて、ゲームに参加/開始待機の状態にあるユーザではない、として管理される。削除の結果、ユーザリストが空の状態となったグループは、空のままでマッチング情報1b内に残しておいてもよいし、グループのエントリ自体をマッチング情報1bから削除してもよい。
【0050】
なお、注意点として、当該終了ユーザがユーザリストから削除されても、マッチング情報1bとは別に存在する部分ネットワーク情報1aにおいては、当該終了ユーザの情報はそのまま残っている。よって、当該終了ユーザが再度ゲームを開始するためにマッチング要求を送信してきた場合に、前述の部分ネットワーク情報1aにおけるキャッシュなどを利用することはできる。
【0051】
なおまた、ゲームの種類や設定によって、グループ所属のユーザが最大数に達してからゲーム開始する場合もそうでない場合もあったように、ゲーム終了も、グループ全員が同時に終了する場合も、各ユーザ毎に終了する場合もある。
【0052】
以上のような、図5のフローによってマッチング情報1bが更新される具体例を説明する。当該例においては、前述の第1実施例を想定する。すなわち所属グループはユーザの所属セグメントに基づいて決定されるものとする。そしてマッチング情報1bとして、図3(C)に示す、グループID=1、セグメントID=1のグループの情報が更新される例を説明する。
【0053】
ある年月日(XX年YY月ZZ日)の時刻20:00においてマッチング情報1bは空であったとする。すなわち、図3(C)に示すようなグループID、セグメントID、ユーザリストの欄があるものの、全て空欄であったとする。
【0054】
同日の時刻20:01にユーザ10.0.0.24がマッチング要求を出してきたとすると、当該アドレスは図3(A)のセグメント#1内の10.0.0.0/24にマッチするので、まずセグメント#1に属するユーザのグループとして、グループID=1の新規グループが作成され、当該ユーザがユーザリストに登録される(ユーザリストは{10.0.0.24})。ユーザ10.0.0.24はゲーム開始を待機する。
【0055】
時刻20:03にユーザ10.0.1.3がマッチング要求を出してくると、当該アドレスも図3(A)のセグメント#1内の10.0.0.1/24にマッチするので、現時点で最大人数に達していないグループID=1のグループに追加登録され、ユーザリストは{10.0.0.24, 10.0.1.3,}となる。ユーザ10.0.0.24, 10.0.1.3はゲーム開始を待機する。
【0056】
時刻20:05にユーザ10.0.1.8がマッチング要求を出してくると、同様にグループID=1のグループに追加登録され、ユーザリストは{10.0.0.24, 10.0.1.3, 10.0.1.8}となり、所属3ユーザはゲーム開始を待機する。
【0057】
時刻20:06にユーザ10.0.0.154がマッチング要求を出してくると、同様にグループID=1のグループに追加登録され、ユーザリストは{10.0.0.24, 10.0.1.3, 10.0.1.8, 10.0.0.154}となり、最大人数4人に達したので、当該4ユーザでネットワークゲームを実行する。すなわち、図3(C)に示されているグループID=1、セグメントID=1のユーザリストの状態は、例えばこのような経緯の後の状態を示している。
【0058】
その後、例えば時刻21:30に当該グループID=1のグループにおけるネットワークゲームが終了して、全ユーザが終了通知を出したとすると、当該グループID=1のグループはユーザリストが空の状態になる、又は当該グループID=1のグループ自体がマッチング情報1bのエントリから削除される。
【0059】
次に、以上のような第1乃至第3実施例によるグループ振り分けと、図5のフローによるマッチング情報1b更新と、による本発明のマッチングサーバ1の各種の運用形態について説明する。
【0060】
図6に、マッチングサーバ1の部分ネットワーク情報1a(又はネットワーク情報提供サーバ2のネットワーク情報2a)により区別された、ISP内のネットワーク5内の各セグメント(セグメント#1,#2,#3,…)を示す。同図に示すように、各セグメント内には、マッチングサーバ1により所属グループを決定された各ユーザからなるグループが存在する。そして、このようなグループが存在する各セグメント内に、通信制御サーバ3を配置する。そして、各セグメントに属するグループでネットワークゲームを実行するに際しては、各セグメントに配置された通信制御サーバ3を利用する。
【0061】
例えば、セグメント#1内のグループ#1、グループ#3の各ユーザがネットワークゲームを実行する場合、セグメント#1内の通信制御サーバ3を利用する。セグメント#2内のグループ#2のユーザがネットワークゲームを実行する場合、セグメント#2内の通信制御サーバ3を利用する。
【0062】
通信制御サーバ3の役割は、いわばローカルのゲームサーバの役割であり、次の通りである。一般にネットワークゲームでは、ゲームの実行開始前や実行途中に、ゲーム会社が提供するデータサーバ又はゲームサーバから定期的にデータやプログラムなどをダウンロードするが、通信制御サーバ3の1つの役割として、これらのデータやプログラムのキャッシュを持つことで、ユーザの近くのサーバ、すなわち図6に示すように、各ユーザの所属セグメント内に配置された通信制御サーバ3からダウンロードさせるようにする、という役割がある。すなわち、ゲーム会社のサーバとユーザとの間の通信を支援する役割である。これにより、ダウンロードに関わるスループットを向上させることができる。
【0063】
また通信制御サーバ3のもう一つの役割として、同一セグメント内のグループで実行されるネットワークゲームにおけるユーザ間の通信を担う役割がある。当該通信により、ゲーム進行にあたって必要なデータをグループ内で同期する。また、必要に応じてゲーム内で特定ユーザ間での通信が可能となる。特に、同一グループ内の双方のユーザがNAT(Network Address Translation、ネットワークアドレス変換)配下などの理由で、ユーザ間が直接コネクションを確立できない場合には、通信制御サーバ3が中継する(NAT越え支援する)ことで、セグメント内に閉じた1ホップの通信を可能とする。グループ全体で同期すべきデータも、同様にセグメント内に閉じた通信で効率的に各ユーザに共有される。
【0064】
このような通信制御サーバ3を用いる場合は、図7に示すように、マッチングサーバ1と通信制御サーバ3とを備えて、本願発明のネットワークゲーム基盤システム4が構成される。すなわち、同図に示すように、ネットワーク情報提供サーバ2でのネットワーク情報2aにより把握されているISP内のネットワーク5内に、ネットワークゲーム基盤システム4が存在する。そして、図6に示すような当該ISP内のネットワーク5内の、マッチングサーバ1により決定されるグループが存在する各セグメントに、通信制御サーバ3を導入する。
【0065】
図7に示すネットワークゲーム基盤システム4は、マッチングサーバ1により所属グループを決定されたユーザ同士のネットワークゲームを実行するための基盤システムであって、当該ネットワークゲームに関するユーザ間の通信を通信制御サーバ3が担うことで、低遅延なゲームを可能とする。なお基盤システムと呼ぶのは、当該システムの主な役割が、ネットワークゲームの娯楽としての内容の部分を担うことではなく、ゲーム実行に必要な通信を補助することにあるためである。
【0066】
通信制御サーバ3が前述のようなNAT越え支援を行うに際しては、支援するユーザの情報をマッチングサーバ1の部分ネットワーク情報1a、又はネットワーク情報提供サーバ2のネットワーク情報2aより得ることで、支援を行う。
【0067】
また、このような通信制御サーバ3を介してネットワークゲームを実行する場合で、且つ前述の第3実施例を適用する場合には、品質実績を測定する専用サーバとして当該通信制御サーバ3を用いるのが好ましい。
【0068】
以上のような、図1,図2,図7などに示した本発明のネットワーク情報提供サーバ2とマッチングサーバ1との間の通信インタフェースとしては、IETFで標準化が進められているALTOの仕組みを利用することができる。この場合、マッチングサーバ1,ネットワーク情報提供サーバ2は、それぞれ、ALTOクライアント、ALTOサーバに相当する。ネットワーク情報全体を取得するには、Map Service(Network Map)が使用可能である。あるユーザのプロファイルを取得するには、Endpoint Property Serviceが使用可能である。
【0069】
本発明に関わるビジネスモデルとしては、以下の形態(1)〜(4)などがある。
【0070】
(1)ネットワーク情報提供サーバ2はISPが運用し、マッチングサーバ1はゲーム会社が運用する。ゲーム会社は、ISPから部分ネットワーク情報1aを得るための対価を支払う。料金として、月額固定の料金や、ネットワーク情報提供サーバ2への通信量に比例した料金などが考えられる。
(2)(1)と同様の運用形態であるが、ISPはネットワーク情報2aを無償で提供する。
(3)ネットワーク情報提供サーバ2だけでなく、マッチングサーバ1についてもISPが運用する。ゲーム会社には、マッチングサーバAPI(Application Programming Interface)を提供し、マッチング要求、グループ問い合わせなどの機能を提供する。
(4)通信制御サーバ3は、SaaS(Software as a Service)型のクラウドサーバとしてISPがゲーム会社に提供する。クラウドサーバの機能としては、キャッシュ機能、NAT接続支援機能などが存在し、リソース使用状況に応じた料金体系とする。
【符号の説明】
【0071】
1…マッチングサーバ、2…ネットワーク情報提供サーバ、10…受信・保持手段、11…マッチング手段

【特許請求の範囲】
【請求項1】
グループにて実行されるネットワークゲームに参加するユーザの所属グループを決定するマッチングを行うマッチングサーバであって、
当該ネットワークゲームの行われるネットワークをセグメントに分けて識別する情報を含むネットワーク情報を保持するネットワーク情報提供サーバより、前記ネットワーク情報の一部である部分ネットワーク情報を受信して保持する受信・保持手段と、
当該ネットワークゲームに参加中である、又は当該ネットワークゲームの開始待機中である各ユーザの情報と、該各ユーザの所属グループの情報と、を含むマッチング情報を管理するマッチング手段とを備え、
該マッチング手段は、
当該ネットワークゲームに参加しようとするユーザからマッチング要求を受信した場合、前記部分ネットワーク情報を参照して求められる当該要求ユーザの所属セグメントと、前記マッチング情報と、に基づいて当該要求ユーザの所属グループを決定して当該要求ユーザに通知することを特徴とするマッチングサーバ。
【請求項2】
前記マッチング手段は、当該ネットワークゲームに参加しようとするユーザからマッチング要求を受信して当該要求ユーザの所属グループを前記決定した場合、当該決定に基づいて前記マッチング情報に当該要求ユーザを登録して更新し、当該ネットワークゲームを終了する旨の通知をユーザより受信した場合、当該終了通知に基づいて前記マッチング情報から当該終了ユーザを除外して更新することを特徴とする請求項1に記載のマッチングサーバ。
【請求項3】
前記ネットワーク情報が各セグメントを、当該セグメントに属するIPアドレス空間の集合として識別する情報を含み、
前記マッチング手段は、前記マッチング要求を受信した場合、前記部分ネットワーク情報を参照して求められる当該要求ユーザのIPアドレスの所属セグメントに基づいて当該要求ユーザの所属グループを決定することを特徴とする請求項1または2に記載のマッチングサーバ。
【請求項4】
前記マッチング手段は、前記マッチング要求を受信する都度、前記受信・保持手段をして当該要求ユーザに関する情報を含む部分ネットワーク情報を受信して保持せしめ、当該受信して保持された部分ネットワーク情報を参照して、当該要求ユーザの所属グループを決定することを特徴とする請求項1ないし3のいずれかに記載のマッチングサーバ。
【請求項5】
前記受信・保持手段が、所定期間毎のみに前記部分ネットワーク情報を受信して保持することを特徴とする請求項1ないし3のいずれかに記載のマッチングサーバ。
【請求項6】
前記ネットワーク情報が各ユーザの利用するアクセス回線の情報を含み、
前記マッチング手段は、前記マッチング要求を受信した場合、前記部分ネットワーク情報を参照して求められる当該要求ユーザの所属セグメントと利用アクセス回線とに基づいて当該要求ユーザの所属グループを決定することを特徴とする請求項1ないし5のいずれかに記載のマッチングサーバ。
【請求項7】
前記マッチング手段は、前記マッチング要求を受信した場合、所定の測定サーバをして当該要求ユーザの通信速度実績を測定せしめ、当該測定された通信速度実績と、前記部分ネットワーク情報を参照して求められる当該要求ユーザの所属セグメントを含む情報と、に基づいて当該要求ユーザの所属グループを決定することを特徴とする請求項1ないし6のいずれかに記載のマッチングサーバ。
【請求項8】
請求項1ないし7のいずれかに記載のマッチングサーバにより所属グループを決定されたユーザ同士にて実行するネットワークゲームでの通信を支援するネットワークゲーム基盤システムであって、
前記マッチングサーバと、
当該所属グループに属するユーザの存在する前記セグメント内に配置される通信制御サーバとを備え、
該通信制御サーバが、当該所属グループ内で実行されるネットワークゲームでの通信を支援することを特徴とする、ネットワークゲーム基盤システム。
【請求項9】
前記ネットワーク情報提供サーバがISP(Internet Service Provider)に運用され、前記マッチングサーバがゲーム会社に運用されることを特徴とする請求項8に記載のネットワークゲーム基盤システム。
【請求項10】
前記ネットワーク情報提供サーバと前記マッチングサーバとがISP(Internet Service Provider)に運用されることを特徴とする請求項8に記載のネットワークゲーム基盤システム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate