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

Abstract

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

Description

本発明は、マッチングサーバ及びネットワークゲーム基盤システムに関し、特に、グループにて実行されるネットワークゲームに参加するユーザの所属グループを決定するマッチングを、当該ネットワークゲームが低遅延で実行されるように行うマッチングサーバ、及び当該マッチングサーバを含むネットワークゲーム基盤システムに関する。

本発明の従来技術として、複数ユーザのマッチングを行うネットワークゲームが該当する。このマッチングとは、ネットワークゲームにおいて、互いに対戦して勝敗を競うユーザや、ゲーム内で一緒に行動するユーザを、決定することである。１つ（１種類）のネットワークゲームにおいて、複数のグループが作成され、各グループに所属するユーザ同士で当該ネットワークゲームが実行される。一般には、グループの最大人数は決まっている。従来のマッチングでは、ユーザ自身がグループを選択する方式や、人数が最大数に達していないグループから順にユーザを割り当てていく方式などが採用されている。

また、標準化機関であるIETF（Internet Engineering Task Force）では、P2P（ピアツーピア）配信などのアプリケーションに対して、ISP(Internet Service Provider)が持つ情報を提供することで、アプリケーションの品質向上やISP内のトラヒック制御などを実現するフレームワークの標準化を行っている。当該標準化に関しては、以下の非特許文献１（IETF ALTO WG [WG：Working Group]）に開示されている。

IETF ALTO WG http://tools.ietf.org/wg/alto/

従来のネットワークゲームにおけるマッチングでは、ユーザのネットワーク性能や、ネットワーク性能を実現する上でのユーザ間の相性（例えば各ユーザの所属ネットワーク）などが考慮されていなかったため、ネットワークゲームが求めるネットワーク性能に対して、ユーザのネットワーク性能が追い付かないという状況が発生していた。また、ユーザのネットワーク性能に関する情報を予め把握する手段もなかったため、ユーザのネットワーク性能に応じてネットワークゲームとしての通信手段を最適化することも難しかった。

すなわち例えば、図８に示すように、ネットワークＮ１，Ｎ２，Ｎ３の接続構成がN1−Ｎ２−Ｎ３と、Ｎ２を介してＮ１とＮ３が離れて接続している構成において、N1に属するユーザＵ１，Ｕ２と、Ｎ３に属するユーザＵ３と、の３ユーザ参加によるネットワークゲームを、Ｎ１に属するゲームサーバＧ１の元で実行する、というようなことが起きていた。この場合例えば、Ｇ１とＵ１，Ｕ２間の通信と、Ｇ１とＵ３間の通信との同時最適化が困難であった。さらに、各ユーザＵ１乃至Ｕ３のユーザ端末（PC又はゲーム端末など）の性能バラツキによっても、当該最適化は困難であった。

このため、従来技術によるマッチングで、ネットワークゲームを実行した場合、遅延が大きくなる、という事態が一般的であった。例えば、東京と九州のユーザが通信する場合、伝搬遅延やルータでのキューイング遅延を含め、ネットワーク部分だけで、例えば30〜50ミリ秒の遅延が発生しうる。さらにアクセス回線がADSL（Asymmetric Digital Subscriber Line、非対称デジタル加入者線）のユーザや、低スペックなPCを持つユーザが混在している場合、全体として発生しうるネットワーク遅延が数100ミリ秒のオーダになることが予測される。また、これらの情報が既知でないため、アプリケーションとして、遅延が何ミリ秒程度であるかということを考慮した最適な設計がしにくいという問題もあった。

本発明の目的は、上記した従来技術の課題を解決し、好ましいネットワーク性能の、特に、低遅延なネットワークゲームを実行可能とするマッチングサーバ及びネットワークゲーム基盤システムを提供することにある。

前記目的を達成するため、本発明は、グループにて実行されるネットワークゲームに参加するユーザの所属グループを決定するマッチングを行うマッチングサーバであって、当該ネットワークゲームの行われるネットワークをセグメントに分けて識別する情報を含むネットワーク情報を保持するネットワーク情報提供サーバより、前記ネットワーク情報の一部である部分ネットワーク情報を受信して保持する受信・保持手段と、当該ネットワークゲームに参加中である、又は当該ネットワークゲームの開始待機中である各ユーザの情報と、該各ユーザの所属グループの情報と、を含むマッチング情報を管理するマッチング手段とを備え、該マッチング手段は、当該ネットワークゲームに参加しようとするユーザからマッチング要求を受信した場合、前記部分ネットワーク情報を参照して求められる当該要求ユーザの所属セグメントと、前記マッチング情報と、に基づいて当該要求ユーザの所属グループを決定して当該要求ユーザに通知することを特徴とする。

また、前記目的を達成するため、本発明は、前記マッチングサーバにより所属グループを決定されたユーザ同士にて実行するネットワークゲームでの通信を支援するネットワークゲーム基盤システムであって、前記マッチングサーバと、当該所属グループに属するユーザの存在する前記セグメント内に配置される通信制御サーバとを備え、該通信制御サーバが、当該所属グループ内で実行されるネットワークゲームでの通信を支援することを特徴とする。

本発明のマッチングサーバによれば、ネットワークゲームに参加しようとマッチング要求をするユーザに対して、当該ユーザのネットワーク内の所属セグメントに基づいて所属グループが決定されるので、ネットワーク距離が所定の範囲内に収まるユーザ同士のグループにより、低遅延なネットワークゲームを実行可能となる。

また本発明のネットワークゲーム基盤システムによれば、前記マッチングサーバによるグループ分けがなされたグループにてネットワークゲームを実行するに際しての通信を、当該グループのユーザが所属するセグメント内に配置される通信制御サーバによって支援するので、低遅延なネットワークゲームが実行可能となる。

本発明のマッチングサーバを含むシステムのブロック図である。 図１におけるマッチングサーバ内の機能ブロックを更に示す図である。 （Ａ）ISP内のネットワークが物理的に複数のセグメントで構成されることと、（Ｂ）当該セグメント内でそれぞれグループが作成されることと、（Ｃ）そのようなセグメントに基づくグループが作成される場合のネットワーク情報と、を例示する図である。 第２実施例と第３実施例との両者を適用した場合のマッチング情報の例を示す図である。 マッチング情報が更新される処理を示すフローチャートである。 マッチングサーバにより決定された各グループの属するセグメント毎に、通信制御サーバを配置することを説明する図である。 本発明のネットワークゲーム基盤システムのブロック図である。 従来技術のマッチングにより、ネットワーク性能が考慮されないネットワークゲームのグループが作成される例を示す図である。

以下に、図面を参照して本発明を詳細に説明する。図１は、本発明のマッチングサーバ１を含むブロック図であり、特にユーザ及びネットワーク情報提供サーバ２との応答部分にフォーカスした構成の図である。ネットワーク情報提供サーバ２は、ネットワーク情報2aを保持し、マッチングサーバ１からのネットワーク情報要求に応じて、自身が保持するネットワーク情報の一部であり、当該要求を受けた部分である、部分ネットワーク情報を返信する。

マッチングサーバ１は、当該返信により更新される部分ネットワーク情報1aとマッチング情報1bとを保持する。また、ネットワークゲームを開始しようとするユーザからのマッチング要求を受信して、当該要求ユーザにとって最適なグループを決定して通知する。さらに、ネットワークゲームを終了するユーザから、ゲームを終了する旨の通知を受信する。マッチングサーバ１は、ユーザよりこれらゲーム開始／終了のいずれの通知を受けた場合も、マッチング情報1b内の、当該ユーザのゲーム参加状態の情報を更新する。

次に、ネットワーク情報提供サーバ２にて保持される、ネットワーク情報2aの内容について説明する。ネットワーク情報2aとは、ユーザプロファイル情報、ネットワークドメイン情報など、一般にISPが有する情報の総称である。ユーザプロファイルの情報には、ユーザのIPアドレス、ユーザの所属地域（固定回線のユーザの場合、自宅住所の所属地域など、携帯電話ユーザの場合、位置情報など）、契約サービス（固定か移動か、帯域、など）、通信品質実績などが存在する。ネットワークドメイン情報には、アドレス空間とネットワークとの対応付けの情報などが存在する。

部分ネットワーク情報1aは、ネットワーク情報提供サーバ２への頻繁な問い合わせを避けるために、マッチングサーバ１が、ネットワーク情報2aの一部をユーザからの要求が発生する前に取得したり、あるいは、先に取得したネットワーク情報2aの一部を、次回以降のユーザからの問い合わせに備えてキャッシュとして残しておくものである。

図２にマッチングサーバ１の機能ブロック図を示し、当該キャッシュの説明と、後述のマッチングサーバ１の各種動作詳細の説明をする。マッチングサーバ１は、部分ネットワーク情報1aを前述のように受信・保持する受信・保持手段１０と、マッチング情報1bを前述のようにユーザ通知を反映させて管理すると共にユーザへのグループ通知を行うマッチング手段１１とを備える。

キャッシュの場合は、まず、ユーザからのマッチング要求をマッチング手段１１が受信し、当該ユーザを例えばユーザＡとして受信パケットの情報などによって識別する。そして、受信・保持手段１０からネットワーク情報提供サーバ２に対して、ユーザＡのネットワーク情報を部分ネットワーク情報1a（の更新すべき部分）として送信するよう要求する。当該情報を受信して、部分ネットワーク情報1aを更新する。さらに、マッチング手段１１は、更新された部分ネットワーク情報1aにおけるユーザＡの情報により、マッチング情報1bを参照することで、所属グループを決定してユーザＡに通知し、マッチング情報1bにおいてユーザＡの情報を更新する。

以降、所定期間が経過するまでは、ユーザＡから追加でマッチング要求があった場合は、ネットワーク情報提供サーバ２にはアクセスせず、部分ネットワーク情報1aにおけるユーザＡの情報を参照して、グループを通知する。なおまた、キャッシュ更新のタイミングの別実施形態として、上記のように所定期間経過後で且つユーザからマッチングを要求したときではなく、所定期間毎に受信・保持手段１０が自動で行うようにしてもよい。

また、別実施形態では、キャッシュを用いず、ユーザからマッチング要求がある度にネットワーク情報提供サーバ２にアクセスして、当該ユーザに関する部分ネットワーク情報を取得してもよい。この場合、頻繁にネットワークの構成変更がある場合においても、最新のネットワーク情報を取得してマッチングに反映できるという効果がある。

次に、本発明を適用する最もシンプルな実施例（第１実施例）を示す。その後、第１実施例を応用した第２、第３実施例を説明するが、これら各実施例は、部分ネットワーク情報1aとマッチング情報1bとで、どのような基準でユーザをグループ分け（マッチング）するか、という区別に基づくものである。

[第１実施例]
ISP内のネットワークは、図３の（Ａ）に示すように、物理的に複数のセグメント（セグメント＃１，＃２，＃３，…）で構成されており、セグメント内の遅延は小さく、セグメント間の遅延は大きいものとする。すなわち、同一セグメント内の端末間ではネットワーク的な距離が所定範囲内であり、異なるセグメントに属する端末間ではネットワーク的な距離が所定範囲を越える。ISPは、ネットワーク情報提供サーバ２におけるネットワーク情報2aとして、各セグメントに割り当てるIPアドレス空間の集合をプレフィクスにより管理する。すなわち図３（Ａ）に示すように、例えば、セグメント＃１にはプレフィクス10.0.0.0/24，10.0.1.0/24，…が、セグメント＃２にはプレフィクス11.0.0.0/24，11.0.1.0/24，…が、セグメント＃１にはプレフィクス12.0.0.0/24，12.0.1.0/24，…が、属するものとして、ネットワーク情報提供サーバ２にて管理される。

ユーザは自身が所属する地域に応じて、いずれかのセグメントよりIPアドレスの払い出しを受ける。マッチングサーバ１は、前述のキャッシュを用いない実施形態であれば、マッチング手段１１にてユーザよりマッチング要求を受信した際、受信・保持手段１０より当該ユーザのIPアドレスがマッチ（周知の最長一致[longest match]）するセグメントをネットワーク情報提供サーバ２に問い合わせ、セグメントIDを受信する。またキャッシュを用いる実施形態であれば、図３（Ａ）に示すようなセグメントとアドレス空間に関するネットワーク情報2aを予めネットワーク情報提供サーバ２より受信しておく。当該キャッシュのための受信は、マッチングサーバ１にアクセスするユーザに関する部分の情報のみであってもよいし、当該ISP内の全セグメントを把握できる情報であってもよい。

上記のようにして、キャッシュ使用有無のいずれの実施形態においても、受信・保持手段１０の部分ネットワーク情報1aによって当該要求ユーザの所属セグメントを調査できるようになる。マッチング手段１１は当該要求ユーザの所属セグメントを調査し、セグメントが同じユーザがグループ化されるようにマッチングを行う。従って、各グループの情報としてはユーザのリストに加えて、セグメントＩＤが管理される。当該第１実施例においては、この仕組みにより、同一セグメントのユーザが自動的にマッチングされ、グループ内のユーザ間で低遅延の通信環境を実現することができる。

当該第１実施例における、グループの作成される例を図３の（Ｂ）に示す。これは同図（Ａ）に示すようなネットワーク構成における場合における例であり、セグメント＃１にグループ＃１，＃３が、セグメント＃２にグループ＃２が、セグメント＃３にグループ＃４が作成されている。当該ゲームが最大４人で実行されるゲームであるとすると、グループ＃１，＃２は最大人数に達している。またグループ＃３，＃４は最大人数に達していないので、さらにグループ内に参加ユーザの追加が可能である。

また、図３（Ｂ）の例に対応するマッチング情報1bの例を図３（Ｃ）に示す。マッチング情報1bは、グループＩＤと、セグメントＩＤと、所属ユーザのユーザリストとを対応付けて並べたテーブル形式によって与えられる。セグメントＩＤ=1のセグメント内のIPアドレスは同図（Ａ）に示すように、プレフィクス10.0.0.0/24，10.0.1.0/24，…に属するアドレスである。よって当該プレフィクスにマッチするユーザにより、最大人数４人に達したグループ１（所属ユーザ10.0.0.24, 10.0.1.3, 10.0.1.8, 10.0.0.154）と、最大人数４人には達していないグループ３（所属ユーザ10.0.0.55, 10.0.1.39）とが管理されている。同様にしてセグメントＩＤ＝２のセグメント内のグループ２（所属ユーザ11.0.0.177, 11.0.1.31, 11.0.0.10, 11.0.0.131で最大人数に達している）と、セグメントＩＤ＝３のセグメント内のグループ４（所属ユーザ12.0.1.143, 12.0.1.79, 12.0.0.8で最大人数には達していない）と、が管理されている。

このように第１実施例では、ユーザの所属セグメントによってグループ分けを行うことにより、低遅延の、又は発生しうる遅延が想定しえる範囲内に収まる、すなわちネットワーク性能のよい、又はネットワーク性能が所定範囲内である、グループを決定することができるという効果がある。

[第２実施例]
ユーザのアクセス回線の速度も通信の速度に影響する。この点に注目し、第２実施例では、マッチング情報1bにおいて、第１実施例におけるユーザリスト、セグメント情報に対して、さらにアクセス回線情報を追加してグループを管理する。

例えば、FTTH(Fiber To The Home、光ファイバー)回線のユーザだけでグループを作成することで、より遅延の小さい通信環境を実現することが可能である。ISPが、アクセス回線毎にセグメントを分けて運用している場合には、上記の第１実施例と同じ手法で、本目的（例えばFTTH回線ならば、FTTH回線のユーザだけでグループを作成）を実現することが可能である。アクセス回線の区別が、セグメント分けの区別自体に含まれているからである。

一方、アクセス回線とセグメント分けとが連動していない場合には、ユーザの契約情報などとの照合が必要となる。このような契約情報なども、前述のとおりネットワーク情報提供サーバ２のネットワーク情報2aに含まれるので、これをマッチングサーバ１において部分ネットワーク情報1aとして利用する。すなわち、ユーザからのマッチング要求を受信した際、マッチングサーバ１はユーザのアクセス回線をネットワーク情報提供サーバ２に問い合わせ、その結果と自身が有するマッチング情報1bとを用いて、グループを決定する。また、前述の通り、毎回ネットワーク情報提供サーバに問い合わせるのではなく、キャッシュを利用してもよい。

以上のように、第２実施例では、ユーザの所属セグメントと、さらにアクセス回線と、によってグループ分けを行うことで、ネットワークゲームを実行するに際して、ネットワーク性能のよいグループを決定することができる。

[第３実施例]
ユーザ端末（PC又はゲーム端末など）の性能も、通信の遅延に影響する。この点に注目し、第３実施例では、マッチング情報1bにおいて、第１実施例における情報に追加して、ユーザ品質実績に関わる情報を含めてグループを管理する。

例えば、品質実績がよいユーザだけでグループを作成することで、より遅延の小さい通信環境を実現することが可能である。なお、品質実績は速度実績により評価するものとする。例えば、品質実績がよいと判断する基準として、通信速度が、上りX Mbps以上、下りY Mbps以上（X、Yは所定値）であること、を基準とする。ユーザからのマッチング要求が来た際、マッチングサーバ１は当該ユーザの品質実績情報をネットワーク情報提供サーバ２に問い合わせ、又はキャッシュとして保存している品質実績情報に基づき、その情報と自身が有するマッチング情報1bとを用いて、グループを決定する。

なお、ネットワークゲームの性質に応じて、通信品質がよいユーザだけでグループ化させることや、通信品質のバランスを考えて（１グループが６人のゲームにおいて、良いユーザを３人、悪いユーザを３人としてグループを作るなど）グループ化させることなどが可能である。

通信品質実績の収集には、専用の測定サーバを設置し、ユーザのマッチング要求後のマッチング開始前に測定サーバへの送受信トラヒックを発生させて測定すればよい。すなわち、当該所定のサーバへのトラヒック上り速度又は下り速度の少なくとも一方を測定して、測定結果が前述の例（上りX Mbps以上、下りY Mbps以上、など。X、Yは所定値）のような、所定範囲にあるか否かをマッチング手段１１にて判定して、グループを決定する。

所定ユーザに対して上述の専用測定サーバによる測定結果を一度求めれば、所定期間の間、部分ネットワーク情報1aにて当該結果を保存しておいて、キャッシュを利用することもできる。またネットワーク情報提供サーバ２のネットワーク情報2aにて各ユーザの通信品質実績の情報が獲得できるならば、第１実施例及び第２実施例と同様の流れで通信品質実績の情報を獲得してもよい。なお、上記のように、専用測定サーバを用いるなどしてマッチング要求時に品質実績を評価することで、当該ユーザが実際にネットワークゲームを実行するときの品質実績に近い評価が得られる傾向が強まる、という効果がある。

以上のように、第３実施例では、ユーザの所属セグメントと、さらにユーザの端末の性能（通信品質実績）情報と、によってグループ分けを行うことで、ネットワークゲームを実行するに際して、ネットワーク性能のよいグループを決定することができる。

第２実施例と第３実施例とは、組み合わせて実施することも可能であり、この場合のマッチング情報1bの例を図４に示す。すなわち、マッチング要求ユーザが各グループに振り分けられるに際して、セグメントＩＤ、アクセス回線種別及び通信速度実績（上り速度、下り速度に対する制限条件）に基づいて、所属グループが決定される。この例では、アクセス回線の種別はFTTH又はADSLであり、FTTH回線の場合、さらに、通信速度実績が上り速度10Mbps以上且つ下り速度20Mbps以上を満たすユーザと、当該条件を満たさないユーザとを分けるようになっている。例えばFTTH回線のユーザで且つ上記通信速度条件を満たすユーザのグループが２つ（グループID1及び２のグループ）存在し、FTTH回線のユーザで且つ上記通信速度条件を満たさない（図中では、上り速度、下り速度共に「制約なし」として表記）ユーザのグループが１つ（グループIDが５のグループ）存在している。

なお、図４の例は、「上り速度」および「下り速度」の欄が存在しないものとすれば第２実施例におけるマッチング情報1bの例となり、「回線種別」の欄が存在しないものとすれば第３実施例におけるマッチング情報1bの例となる。

以上、第１乃至第３実施例を用いてマッチング情報1bの各実施例を説明した。マッチングサーバ１のマッチング手段１１が、このようなマッチング情報1bを随時更新して管理するフローチャートを図５に示す。マッチング情報1bが更新されるのは、ユーザよりマッチング要求を受信した場合、又はゲーム参加／待機中のユーザよりゲームを終了する通知を受信した場合、である。更新フローを開始し、最初のステップS１では、ユーザからの受信の種類がこのいずれであるかによって場合分けを行う。まず、マッチング要求を受信したものとし、この場合から説明する。この場合はステップS2へと進む。

ステップS2では、マッチング手段１１が、マッチング情報1bと、部分ネットワーク情報1aを参照して得られる当該要求ユーザの所属セグメントなどと、に基づいて、当該要求ユーザの所属グループを決定する。当該グループ決定においては前述の通り、第１実施例では所属セグメントに基づいて決定され、第２，第３実施例ではさらにそれぞれ利用アクセス回線、通信速度実績に基づいて決定される。また前述の通り、部分ネットワーク情報1aとしてキャッシュを用いない場合は、受信・保持手段１０に対してネットワーク情報提供サーバ２より当該要求ユーザに関連する部分ネットワーク情報を送信させ、受信・保持手段１０における部分ネットワーク情報1aを更新してから、決定する。

なお、グループを決定するにあたっては、全ての条件（所属セグメントなど）に合致し、且つ最大人数には達していないグループをマッチング情報1bの中から選択することで、決定される。該当するグループが存在しない場合には、当該条件のグループをグループＩＤと対応づけて新たに作成し、決定グループとする。

ステップS3では、当該決定したグループを要求ユーザに通知する。当該ユーザはグループ通知を受けると、所定のゲームサーバにログインするなどして、当該決定グループに所属することでネットワークゲームを開始する、又はネットワークゲーム開始を待機する状態に移る。基本的には、所属グループがネットワークゲームにて設定される最大人数に達すればゲームを開始し、達していなければ、別ユーザがマッチング後に当該グループに加入して、グループ人数が最大人数に達するまで待機する。しかし、ゲームの種類や設定によっては、最大人数に達していなくても、既にグループに所属しているユーザのみでゲームを実行するようにしてもよい。このような、既にゲームを実行中のグループにマッチングしたユーザは、当該ゲームに途中から参加することとなる。

ステップS4に進み、上記のステップS3におけるユーザの状態の遷移（ゲームに参加していない状態から、ゲーム参加又は待機の状態に移る）があるという前提のもと、当該ステップS２におけるユーザの所属グループ決定を、マッチング情報1bに反映させて更新する。すなわち当該ユーザを当該グループのユーザリストに追加する。新たに作成したグループであれば、当該グループ自体を登録して、且つそのユーザリストに当該ユーザを最初のユーザとして登録することで、マッチング情報1bを更新する。

なお、ユーザがゲーム参加／待機状態に移ったことを確認するために、ユーザより当該状態に移った旨の通知をマッチング手段１１にて受けてからステップS4を実行するようにしてもよい。

上記のステップS4の説明（また後述のステップS5の説明）より明らかなように、図３（C）や図４で例を示したようなマッチング情報1bにおけるユーザリストに、あるユーザが載っている、すなわち登録されているということは、当該ユーザが対応するグループに所属して、ゲームに参加又はゲーム開始を待機している状態にあることを意味している。前述の第１乃至第３実施例ではグループ振り分け基準にフォーカスして説明したので、マッチング情報1bのこのような性質に関して強調して説明していなかったが、マッチング情報1bはこのような性質を有するものである。

また、ステップS1に戻り、ユーザからゲーム終了通知を受信した場合の説明をする。この場合はステップS5へ進む。ユーザがゲームを終了する場合は、自動的にマッチング手段１１が終了通知を受信するよう、ゲームサーバなどに設定しておいてもよい。当該ゲーム終了通知に関しても、上記と同様の理由で、前述の第１乃至第３実施例では説明していないが、これらの例においてもステップS５は適宜、実施されている。

ステップS5では、ゲームを終了するユーザを、マッチング情報1b内のユーザリストから除外する。当該終了ユーザはユーザリストに載っていない状態となるので、マッチング情報1bにおいて、ゲームに参加／開始待機の状態にあるユーザではない、として管理される。削除の結果、ユーザリストが空の状態となったグループは、空のままでマッチング情報1b内に残しておいてもよいし、グループのエントリ自体をマッチング情報1bから削除してもよい。

なお、注意点として、当該終了ユーザがユーザリストから削除されても、マッチング情報1bとは別に存在する部分ネットワーク情報1aにおいては、当該終了ユーザの情報はそのまま残っている。よって、当該終了ユーザが再度ゲームを開始するためにマッチング要求を送信してきた場合に、前述の部分ネットワーク情報1aにおけるキャッシュなどを利用することはできる。

なおまた、ゲームの種類や設定によって、グループ所属のユーザが最大数に達してからゲーム開始する場合もそうでない場合もあったように、ゲーム終了も、グループ全員が同時に終了する場合も、各ユーザ毎に終了する場合もある。

以上のような、図５のフローによってマッチング情報1bが更新される具体例を説明する。当該例においては、前述の第１実施例を想定する。すなわち所属グループはユーザの所属セグメントに基づいて決定されるものとする。そしてマッチング情報1bとして、図３（Ｃ）に示す、グループＩＤ＝１、セグメントＩＤ＝１のグループの情報が更新される例を説明する。

ある年月日（XX年YY月ZZ日）の時刻20:00においてマッチング情報1bは空であったとする。すなわち、図３（Ｃ）に示すようなグループＩＤ、セグメントＩＤ、ユーザリストの欄があるものの、全て空欄であったとする。

同日の時刻20:01にユーザ10.0.0.24がマッチング要求を出してきたとすると、当該アドレスは図３（Ａ）のセグメント＃１内の10.0.0.0/24にマッチするので、まずセグメント＃１に属するユーザのグループとして、グループＩＤ＝１の新規グループが作成され、当該ユーザがユーザリストに登録される（ユーザリストは{10.0.0.24}）。ユーザ10.0.0.24はゲーム開始を待機する。

時刻20:03にユーザ10.0.1.3がマッチング要求を出してくると、当該アドレスも図３（Ａ）のセグメント＃１内の10.0.0.1/24にマッチするので、現時点で最大人数に達していないグループＩＤ＝１のグループに追加登録され、ユーザリストは{10.0.0.24, 10.0.1.3,}となる。ユーザ10.0.0.24, 10.0.1.3はゲーム開始を待機する。

時刻20:05にユーザ10.0.1.8がマッチング要求を出してくると、同様にグループＩＤ＝１のグループに追加登録され、ユーザリストは{10.0.0.24, 10.0.1.3, 10.0.1.8}となり、所属３ユーザはゲーム開始を待機する。

時刻20:06にユーザ10.0.0.154がマッチング要求を出してくると、同様にグループＩＤ＝１のグループに追加登録され、ユーザリストは{10.0.0.24, 10.0.1.3, 10.0.1.8, 10.0.0.154}となり、最大人数４人に達したので、当該４ユーザでネットワークゲームを実行する。すなわち、図３（Ｃ）に示されているグループＩＤ＝１、セグメントＩＤ＝１のユーザリストの状態は、例えばこのような経緯の後の状態を示している。

その後、例えば時刻21:30に当該グループＩＤ＝１のグループにおけるネットワークゲームが終了して、全ユーザが終了通知を出したとすると、当該グループＩＤ＝１のグループはユーザリストが空の状態になる、又は当該グループＩＤ＝１のグループ自体がマッチング情報1bのエントリから削除される。

次に、以上のような第１乃至第３実施例によるグループ振り分けと、図５のフローによるマッチング情報1b更新と、による本発明のマッチングサーバ１の各種の運用形態について説明する。

図６に、マッチングサーバ１の部分ネットワーク情報1a（又はネットワーク情報提供サーバ２のネットワーク情報2a）により区別された、ＩＳＰ内のネットワーク５内の各セグメント（セグメント＃１，＃２，＃３，…）を示す。同図に示すように、各セグメント内には、マッチングサーバ１により所属グループを決定された各ユーザからなるグループが存在する。そして、このようなグループが存在する各セグメント内に、通信制御サーバ３を配置する。そして、各セグメントに属するグループでネットワークゲームを実行するに際しては、各セグメントに配置された通信制御サーバ３を利用する。

例えば、セグメント＃１内のグループ＃１、グループ＃３の各ユーザがネットワークゲームを実行する場合、セグメント＃１内の通信制御サーバ３を利用する。セグメント＃２内のグループ＃２のユーザがネットワークゲームを実行する場合、セグメント＃２内の通信制御サーバ３を利用する。

通信制御サーバ３の役割は、いわばローカルのゲームサーバの役割であり、次の通りである。一般にネットワークゲームでは、ゲームの実行開始前や実行途中に、ゲーム会社が提供するデータサーバ又はゲームサーバから定期的にデータやプログラムなどをダウンロードするが、通信制御サーバ３の１つの役割として、これらのデータやプログラムのキャッシュを持つことで、ユーザの近くのサーバ、すなわち図６に示すように、各ユーザの所属セグメント内に配置された通信制御サーバ３からダウンロードさせるようにする、という役割がある。すなわち、ゲーム会社のサーバとユーザとの間の通信を支援する役割である。これにより、ダウンロードに関わるスループットを向上させることができる。

また通信制御サーバ３のもう一つの役割として、同一セグメント内のグループで実行されるネットワークゲームにおけるユーザ間の通信を担う役割がある。当該通信により、ゲーム進行にあたって必要なデータをグループ内で同期する。また、必要に応じてゲーム内で特定ユーザ間での通信が可能となる。特に、同一グループ内の双方のユーザがNAT(Network Address Translation、ネットワークアドレス変換)配下などの理由で、ユーザ間が直接コネクションを確立できない場合には、通信制御サーバ３が中継する（NAT越え支援する）ことで、セグメント内に閉じた１ホップの通信を可能とする。グループ全体で同期すべきデータも、同様にセグメント内に閉じた通信で効率的に各ユーザに共有される。

このような通信制御サーバ３を用いる場合は、図７に示すように、マッチングサーバ１と通信制御サーバ３とを備えて、本願発明のネットワークゲーム基盤システム４が構成される。すなわち、同図に示すように、ネットワーク情報提供サーバ２でのネットワーク情報2aにより把握されているＩＳＰ内のネットワーク５内に、ネットワークゲーム基盤システム４が存在する。そして、図６に示すような当該ＩＳＰ内のネットワーク５内の、マッチングサーバ１により決定されるグループが存在する各セグメントに、通信制御サーバ３を導入する。

図７に示すネットワークゲーム基盤システム４は、マッチングサーバ１により所属グループを決定されたユーザ同士のネットワークゲームを実行するための基盤システムであって、当該ネットワークゲームに関するユーザ間の通信を通信制御サーバ３が担うことで、低遅延なゲームを可能とする。なお基盤システムと呼ぶのは、当該システムの主な役割が、ネットワークゲームの娯楽としての内容の部分を担うことではなく、ゲーム実行に必要な通信を補助することにあるためである。

通信制御サーバ３が前述のようなNAT越え支援を行うに際しては、支援するユーザの情報をマッチングサーバ１の部分ネットワーク情報1a、又はネットワーク情報提供サーバ２のネットワーク情報2aより得ることで、支援を行う。

また、このような通信制御サーバ３を介してネットワークゲームを実行する場合で、且つ前述の第３実施例を適用する場合には、品質実績を測定する専用サーバとして当該通信制御サーバ３を用いるのが好ましい。

以上のような、図１，図２，図７などに示した本発明のネットワーク情報提供サーバ２とマッチングサーバ１との間の通信インタフェースとしては、IETFで標準化が進められているALTOの仕組みを利用することができる。この場合、マッチングサーバ１，ネットワーク情報提供サーバ２は、それぞれ、ALTOクライアント、ALTOサーバに相当する。ネットワーク情報全体を取得するには、Map Service(Network Map)が使用可能である。あるユーザのプロファイルを取得するには、Endpoint Property Serviceが使用可能である。

本発明に関わるビジネスモデルとしては、以下の形態（１）〜（４）などがある。

（１）ネットワーク情報提供サーバ２はISPが運用し、マッチングサーバ１はゲーム会社が運用する。ゲーム会社は、ISPから部分ネットワーク情報1aを得るための対価を支払う。料金として、月額固定の料金や、ネットワーク情報提供サーバ２への通信量に比例した料金などが考えられる。
（２）（１）と同様の運用形態であるが、ISPはネットワーク情報2aを無償で提供する。
（３）ネットワーク情報提供サーバ２だけでなく、マッチングサーバ１についてもＩＳＰが運用する。ゲーム会社には、マッチングサーバＡＰＩ（Application Programming Interface）を提供し、マッチング要求、グループ問い合わせなどの機能を提供する。
（４）通信制御サーバ３は、SaaS(Software as a Service)型のクラウドサーバとしてISPがゲーム会社に提供する。クラウドサーバの機能としては、キャッシュ機能、NAT接続支援機能などが存在し、リソース使用状況に応じた料金体系とする。

１…マッチングサーバ、２…ネットワーク情報提供サーバ、１０…受信・保持手段、１１…マッチング手段

Claims (10)

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

Images