(57)【要約】【課題】端末の属するセグメントのみを考慮したマッチングでは必ずしも十分に低遅延なオンラインゲーム環境を実現できない。【解決手段】マッチングサーバ１において、部分ネットワーク品質情報取得手段１０がネットワーク品質情報提供サーバ２よりユーザ端末間のネットワークトラヒックに基づく部分ネットワーク品質情報を取得し、当該情報を用いてユーザ管理手段３０が端末間のマッチング距離を算出し、参加中ユーザ及びグループの情報をマッチング情報として管理するマッチング手段２０が、マッチング要求ユーザと参加中との間のマッチング距離に基づいて要求ユーザの所属グループを決定し、マッチングを行うことで、超低遅延なオンラインゲーム環境を実現する。【選択図】図３
2013013027.tif 000002
【特許請求の範囲】
【請求項１】
グループ単位にて実行されるオンラインゲームに参加するユーザの所属するグループを決定するマッチングサーバにおいて、
ユーザ端末間で送受信されるネットワークトラヒックに基づいて算出される当該ユーザ端末間の通信品質に関する情報を含む部分ネットワーク品質情報を取得する部分ネットワーク品質情報取得手段と、
前記部分ネットワーク品質情報に基づいてユーザ端末間のマッチング距離を算出し、ユーザ管理情報として管理するユーザ管理手段と、
当該オンラインゲームの実行されている状態を把握するために、当該オンラインゲームに参加中である各ユーザの情報と、該各ユーザの所属するグループの情報とを互いに対応づけたマッチング情報を管理するマッチング手段とを備え、
該マッチング手段は、当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信した場合、当該要求ユーザと前記マッチング情報を参照して得られる当該オンラインゲーム実行中の各グループに所属するユーザとの間の、前記ユーザ管理情報を参照して得られるマッチング距離の各グループ間での比較に基づいて当該要求ユーザの所属するグループを決定することを特徴とするマッチングサーバ。
【請求項２】
前記部分ネットワーク品質情報取得手段が、
前記部分ネットワーク品質情報の一種としてユーザ端末間のパケット遅延を取得するパケット遅延取得手段と、
前記部分ネットワーク品質情報の一種としてユーザ端末間で送受信されるパケットの棄却率を取得するパケット棄却率取得手段と、
前記部分ネットワーク品質情報の一種としてユーザ端末間の物理的距離を取得する物理的距離取得手段とのうち少なくとも一つを含むことを特徴とする請求項１に記載のマッチングサーバ。
【請求項３】
前記マッチング手段が、当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信した場合、当該要求ユーザと前記マッチング情報を参照して得られる当該オンラインゲーム参加中ユーザのうち各グループを代表する代表ユーザとの間の、前記ユーザ管理情報を参照して得られるマッチング距離の前記代表ユーザにより代表される各グループ間での比較に基づいて当該要求ユーザの所属するグループを決定することを特徴とする請求項１または２に記載のマッチングサーバ。
【請求項４】
前記マッチング手段が、前記各グループを代表する代表ユーザを、前記ユーザ管理情報を参照して得られるマッチング距離の、各グループ内における他のユーザとの総和が最小となるユーザとして定めることを特徴とする請求項３に記載のマッチングサーバ。
【請求項５】
前記部分ネットワーク品質情報取得手段が、前記部分ネットワーク品質情報の一種として各ユーザ端末の所属する、IPアドレス空間の割り当てに対応したセグメントを取得するセグメント取得手段を含み、
前記マッチング手段は、異なるセグメントに属するユーザ同士が同一グループに所属することがないよう、セグメント毎に分割して前記マッチング情報を管理し、当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信した場合、当該要求ユーザの所属するセグメントに対応するマッチング情報を参照して当該要求ユーザの所属するグループを決定することを特徴とする請求項１ないし４のいずれかに記載のマッチングサーバ。
【請求項６】
前記部分ネットワーク品質情報取得手段が、当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信した場合にその都度当該要求ユーザに関連する前記部分ネットワーク品質情報を取得する、または当該オンラインゲームに参加することが既知の所与のユーザに関連する前記部分ネットワーク品質情報を所定期間毎に取得することを特徴とする請求項１ないし５のいずれかに記載のマッチングサーバ。
【請求項７】
ユーザ端末間で送受信されるネットワークトラヒックを測定し当該ユーザ端末間の通信品質に関する情報を含むネットワーク品質情報を保持するネットワーク品質情報提供サーバと、
グループ単位にて実行されるオンラインゲームに参加するユーザの所属するグループを決定するマッチングサーバとを含むオンラインゲームシステムにおいて、
前記マッチングサーバが、
前記ネットワーク品質情報提供サーバの保持するネットワーク品質情報の一部として部分ネットワーク品質情報を取得する部分ネットワーク品質情報取得手段と、
前記部分ネットワーク品質情報に基づいてユーザ端末間のマッチング距離を算出し、ユーザ管理情報として管理するユーザ管理手段と、
当該オンラインゲームの実行されている状態を把握するために、当該オンラインゲームに参加中である各ユーザの情報と、該各ユーザの所属するグループの情報とを互いに対応づけたマッチング情報を管理するマッチング手段とを備え、
該マッチング手段は、当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信した場合、当該要求ユーザと前記マッチング情報を参照して得られる当該オンラインゲーム実行中の各グループに所属するユーザとの間の、前記ユーザ管理情報を参照して得られるマッチング距離の各グループ間での比較に基づいて当該要求ユーザの所属するグループを決定し、
前記マッチングサーバ及びネットワーク品質情報管理サーバがそれぞれゲーム会社及びISP（インターネットサービスプロバイダ）に運用される、または前記マッチングサーバ及びネットワーク品質情報管理サーバが共にISPに運用されることを特徴とするオンラインゲームシステム。
【請求項８】
グループ単位にて実行されるオンラインゲームに参加するユーザの所属するグループを決定するマッチング方法において、
ユーザ端末間で送受信されるネットワークトラヒックに基づいて算出される当該ユーザ端末間の通信品質に関する情報を含む部分ネットワーク品質情報を取得するステップと、
前記部分ネットワーク品質情報に基づいてユーザ端末間のマッチング距離を算出し、ユーザ管理情報として管理するステップと、
当該オンラインゲームの実行されている状態を把握するために、当該オンラインゲームに参加中である各ユーザの情報と、該各ユーザの所属するグループの情報とを互いに対応づけたマッチング情報を管理するステップと、
当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信してから、当該要求ユーザと前記マッチング情報を参照して得られる当該オンラインゲーム実行中の各グループに所属するユーザとの間の、前記ユーザ管理情報を参照して得られるマッチング距離の各グループ間での比較に基づいて当該要求ユーザの所属するグループを決定するステップとを備えることを特徴とするマッチング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はオンラインゲームに参加するユーザの所属グループを決定するマッチングに関し、特に、ユーザ間のネットワークトラヒックを考慮したマッチングを行うことで低遅延なオンラインゲーム環境を実現することのできる、マッチングサーバ及び方法並びにオンラインゲームシステムに関する。
【背景技術】
【０００２】
本発明の従来技術として、ISPが所有するネットワークに基づくユーザのネットワークプロファイル情報（IPアドレスに紐づく所属地域情報やアクセス回線情報）を用いたマッチングが該当する。当該従来技術は特許文献１に記載されている。ここでのマッチングとは、オンラインゲームにおいて、互いに対戦して勝敗を競うユーザや、ゲーム内で行動を共にするユーザをグループとして決定するものである。一般には1つのオンラインゲームにおいて複数のグループが作成され、各グループ内で通信が行われながらオンラインゲームが実行される。従来技術では、遅延の小さいゲーム環境を提供することを目的とした、同じ地域に所属するユーザ同士でグループを作成する方式や、高速なアクセス回線を有するユーザ同士でグループを作成する方式などが提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特願２０１０−２１５１９７号
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ユーザのネットワークプロファイルは、ゲームへの参加人数の規模やユーザの状態に依存する情報ではない。そのため、従来技術を用いたマッチングでは、例えば同一地域でグループを作成した場合などにおいて、地域内でユーザ毎に通信品質が大きく異なり更なるマッチングが必要な状況や、地域をまたぐユーザ間でも通信品質がほとんど変わらない場合などにおいて、必ずしも最適なマッチングが実現できるとは限らず、要求するユーザの数や状態を反映してグループを作成することが難しかった。また、従来技術ではユーザ間の定量的な通信実績を考慮していないので、実際の通信実績として裏付けられた低遅延環境を実現することも難しく、低遅延なオンラインゲーム環境を提供するためのマッチングにおいてさらなる改善の余地があった。
【０００５】
本発明の目的は、上記の従来技術の課題を解決し、オンラインゲームに参加しようとするユーザに対して、ユーザ端末間で送受信されるネットワークトラヒック等を考慮して当該ユーザの所属グループを決定することにより、超低遅延なオンラインゲーム環境を実現するマッチングサーバ及び方法並びにオンラインゲームシステムを提供することにある。
【課題を解決するための手段】
【０００６】
上記の従来技術の課題を解決するため、本発明は、グループ単位にて実行されるオンラインゲームに参加するユーザの所属するグループを決定するマッチングサーバにおいて、ユーザ端末間で送受信されるネットワークトラヒックに基づいて算出される当該ユーザ端末間の通信品質に関する情報を含む部分ネットワーク品質情報を取得する部分ネットワーク品質情報取得手段と、前記部分ネットワーク品質情報に基づいてユーザ端末間のマッチング距離を算出し、ユーザ管理情報として管理するユーザ管理手段と、当該オンラインゲームの実行されている状態を把握するために、当該オンラインゲームに参加中である各ユーザの情報と、該各ユーザの所属するグループの情報とを互いに対応づけたマッチング情報を管理するマッチング手段とを備え、該マッチング手段は、当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信した場合、当該要求ユーザと前記マッチング情報を参照して得られる当該オンラインゲーム実行中の各グループに所属するユーザとの間の、前記ユーザ管理情報を参照して得られるマッチング距離の各グループ間での比較に基づいて当該要求ユーザの所属するグループを決定することを特徴とする。
【０００７】
また本発明は、前記部分ネットワーク品質情報取得手段においては、ユーザ端末間で送受信されるネットワークトラヒックを測定し当該ユーザ端末間の通信品質に関する情報を含むネットワーク品質情報を保持するネットワーク品質情報提供サーバより、前記ネットワーク品質情報の一部として前記部分ネットワーク品質情報を取得し、前記ネットワーク品質情報提供サーバと前記マッチングサーバとを含むオンラインゲームシステムであることを特徴とする。
【０００８】
さらに本発明は、グループ単位にて実行されるオンラインゲームに参加するユーザの所属するグループを決定するマッチング方法において、ユーザ端末間で送受信されるネットワークトラヒックに基づいて算出される当該ユーザ端末間の通信品質に関する情報を含む部分ネットワーク品質情報を取得するステップと、前記部分ネットワーク品質情報に基づいてユーザ端末間のマッチング距離を算出し、ユーザ管理情報として管理するステップと、当該オンラインゲームの実行されている状態を把握するために、当該オンラインゲームに参加中である各ユーザの情報と、該各ユーザの所属するグループの情報とを互いに対応づけたマッチング情報を管理するステップと、当該オンラインゲームに参加しようとする要求ユーザからマッチング要求を受信してから、当該要求ユーザと前記マッチング情報を参照して得られる当該オンラインゲーム実行中の各グループに所属するユーザとの間の、前記ユーザ管理情報を参照して得られるマッチング距離の各グループ間での比較に基づいて当該要求ユーザの所属するグループを決定するステップとを備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ユーザ端末間で送受信されるネットワークトラヒック等に基づく部分ネットワーク品質情報を用いてユーザ端末間のマッチング距離を算出し、ユーザ端末間のネットワーク状態等が反映された当該マッチング距離に基づいてマッチングを行い要求ユーザの所属グループを決定するので、超低遅延なオンラインゲーム環境を実現することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の構成を示す図である。
【図２】マッチング情報の更新フローチャートである。
【図３】マッチングサーバの機能ブロック図である。
【図４】マッチングの詳細のフローチャートである。
【図５】第１実施例においてユーザ管理情報が更新される例を示す図である。
【図６】第１実施例においてマッチング情報が更新される例を示す図である。
【図７】マッチングを説明するために、各ユーザを模式的に距離空間に配置して、図５の例におけるユーザ管理情報における各ユーザ間のマッチング距離を表現した図である。
【図８】第２実施例におけるユーザ管理情報の例を示す図である。
【図９】第３実施例を説明するための図である。
【図１０】オンラインゲームシステムの構成図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して本発明を詳細に示す。図１に、本発明の構成を示す。マッチングサーバ１は、各ユーザからのマッチング要求を受けて、マッチングを行う。マッチングとは、グループにて実行されるオンラインゲームに参加しようとするユーザの所属グループを決定することであり、マッチングを行ったマッチングサーバ１は、当該ユーザに決定した所属グループを通知する。当該ユーザは当該グループに所属してオンラインゲームを楽しむ。当該オンラインゲームの実行に関しては、図１に不図示のゲーム管理サーバ等に管理させ、ゲームプログラムのユーザ端末へのダウンロードや実際のゲームの進行制御等を行わせる。
【００１２】
マッチングサーバ１は、部分ネットワーク品質情報１ａ及びマッチング情報１ｂを保持する。部分ネットワーク品質情報１aとは、ネットワーク品質情報提供サーバ２が保持するネットワーク品質情報２aのうち、マッチングを行うために必要な一部分をマッチングサーバ１が取り寄せ、ネットワーク品質情報提供サーバ２への頻繁な問い合わせを避けるためにキャッシュとして保持しているものである。
【００１３】
マッチング情報１ｂとは、その内容を１０ｂに概念的に示すように、マッチングサーバ１により所属グループが決定されてオンラインゲームに参加している各ユーザ（図中、○として示す）とその所属グループ（グループ１、グループ２等と図示）とを対応づけた情報である。すなわち、マッチング情報１ｂはオンラインゲームの参加ユーザと所属グループなどの特定により、オンラインゲームの実行されている状態を把握するための情報である。
【００１４】
ユーザがマッチング情報１ｂにてあるグループに所属するものとして記載されていれば、当該ユーザは当該グループに所属してオンラインゲームに参加中であり、記載されていなければ参加していない。また、マッチング情報１０ｂには各グループの参加人数n及び参加可能上限人数mの情報が含まれる。よってn=mかn<mであるかの区別により、マッチング情報１ｂには各グループにオンラインゲームのユーザを追加可能か否かの情報も含まれる。
【００１５】
ネットワーク品質情報２aは、その内容を２０aに概念的に示すように、ユーザ端末間で送受信されるネットワークトラヒックより得られる、通信品質に関する情報を含む。ユーザ端末間で試験パケットを送受信させた測定結果等を用いて、ネットワーク品質情報提供サーバ２がネットワーク品質情報２aを作成する。測定項目としては例えば、エンドツーエンドのパケット遅延やパケット廃棄率などが挙げられる。当該ネットワーク品質情報２aの作成には、例えばユーザ端末側にトラヒック計測用プログラムを予めインストールして実行させる等の手法を採用することができる。
【００１６】
図２に、マッチング情報１ｂの更新される手順のフローチャートを示す。マッチング情報１ｂの更新は、マッチングサーバ１がユーザより（１）オンラインゲームへの参加要求すなわちマッチング要求、又は（２）オンラインゲームの終了通知、を受けた場合に行われる。ステップS1では、（１）（２）のいずれの場合であるかにより場合分けが行われる。（１）の場合から説明することとする。この場合ステップS2に進み、マッチングサーバ１が当該参加要求ユーザの所属するグループの決定すなわちマッチングを行う。当該ステップS2の詳細については後述する。
【００１７】
ステップS3では、マッチングサーバ１は決定した所属グループを要求ユーザに通知する。当該通知後の不図示のステップで、要求ユーザは当該グループに所属してオンラインゲームに参加する状態となる。よってステップS4において、マッチングサーバ１は当該要求ユーザが決定されたグループに所属してオンラインゲーム参加中である旨をマッチング情報１ｂに反映させることで、マッチング情報１ｂを更新する。
【００１８】
なお、ステップＳ３の通知は、当該オンラインゲームが各グループが定員に達してから実行可能となる種類のゲームであれば、各グループが定員に達するのを待ってから当該グループの全員に一度に所属グループを通知するようにしてもよいし、まず所属グループを通知しておき、ユーザはグループが満員となってゲームが開始されるのを待つようにしてもよい。全員に一度に通知する場合、要求ユーザが現れる毎にステップＳ２が実行されて、ステップＳ３でグループ毎に定員待ちが行われることとなる。
【００１９】
一方、ステップＳ１で（２）の場合にはステップＳ５へ進み、マッチングサーバ１はオンラインゲームの終了通知をしてきたユーザをマッチング情報１ｂから削除することで、マッチング情報１ｂを更新する。当該終了通知してきたユーザはステップＳ５の後の不図示のステップで、オンラインゲームを終了する。
【００２０】
以上のような図２のマッチング情報１ｂの更新フローにより、マッチング情報１ｂにおいては、マッチングサーバ１を利用してオンラインゲームに参加中のユーザの情報がその所属グループの情報と共に最新の状態で管理されることとなる。
【００２１】
図３に、マッチングサーバ１の機能ブロック図を示す。マッチングサーバ１は、部分ネットワーク品質情報取得手段１０、マッチング手段２０及びユーザ管理手段３０を備える。部分ネットワーク品質情報取得手段１０は、パケット遅延取得手段１１、パケット棄却率取得手段１２、物理的距離取得手段１３、セグメント取得手段１４及び部分ネットワーク品質情報１aを含む。マッチング手段２０はマッチング情報１ｂを含む。ユーザ管理手段３０はユーザ管理情報１ｃを含む。
【００２２】
パケット遅延取得手段１１ないしセグメント取得手段１４は、ネットワーク品質情報提供サーバ２の管理するネットワーク品質情報２aのうち、本発明に好適な各種類の情報をそれぞれ個別に取得して、部分ネットワーク品質情報１aを構成する各種類の情報として保存する。パケット遅延取得手段１１は、ユーザ端末間のパケット遅延を部分ネットワーク品質情報１aの一種として取得する。パケット棄却率取得手段１２は、ユーザ端末間で送受信されるパケットの棄却率を部分ネットワーク品質情報１aの一種として取得する。
【００２３】
物理的距離取得手段１３は、ユーザ端末間の物理的距離を部分ネットワーク品質情報１aの一種として取得する。セグメント取得手段１４は、各ユーザ端末の所属するネットワーク内のセグメントを、部分ネットワーク品質情報１aの一種として取得する。当該物理的距離取得手段１３及びセグメント取得手段１４の各取得情報は、ネットワーク品質情報提供サーバ２が例えばISP（インターネットサービスプロバイダ）に運用されるサーバであれば、ネットワーク品質情報１aを参照して取得することができる。
【００２４】
例えば、物理的距離に関してはユーザのIPアドレスに紐付いた位置情報を用いて、もしくはGPS等の情報を参照して得られる緯度・経度などを用いて、２端末間での値を求めることができる。セグメントに関しては、ユーザのIPアドレスに割り当てられたIPアドレス空間などから求めることができる。
【００２５】
なお、セグメント取得手段１４の取得するセグメントは単一のユーザ端末毎に取得されるという点で、パケット遅延取得手段１１ないし物理的距離取得手段１３の取得するユーザ端末のペアに対して定義される情報とは異なる。当該各取得される情報の利用については後述する。
【００２６】
マッチング手段２０は、図２のフローで説明したようにマッチング情報１ｂを管理して更新する。すなわち、マッチング手段２０はマッチング要求を受けた場合には、当該要求ユーザと参加中ユーザとの間のユーザ管理情報１ｃ及びマッチング情報１ｂを参照することで当該要求ユーザの所属グループを決定して当該要求ユーザに通知すると共に、マッチング情報１ｂを更新する。マッチング手段２０は終了通知を受けた場合には、当該終了ユーザを削除することでマッチング情報１ｂを更新する。
【００２７】
ユーザ管理手段３０は、ユーザ管理情報１ｃを管理する。ユーザ管理情報１ｃとは、部分ネットワーク品質情報１aを用いてユーザ管理手段３０が算出するユーザ端末間のマッチング距離の情報である。各ユーザ端末間のマッチング距離を列挙した情報として、ユーザ管理情報１ｃは構成される。当該ユーザ管理情報１ｃを参照して得られるマッチング距離を用いて、マッチング手段２０はマッチングを行う。
【００２８】
図４に、図２のステップＳ２すなわちマッチングの詳細なフローチャートを示す。ステップS２１では、部分ネットワーク品質情報取得手段１０が、要求ユーザと参加中ユーザとに関連する部分ネットワーク品質情報を新たに取得し、部分ネットワーク品質情報１aを更新する。なお、当該図４のフローと図２のフローとの全体より明らかとなるように、既に参加中のユーザに関連する部分ネットワーク品質情報は既に取得されている。ステップS２１では、当該既に取得済みの情報に新規取得情報を加えることで、部分ネットワーク品質情報１aが更新される。
【００２９】
ステップS２２では、部分ネットワーク品質情報１aのうちステップS２１で新規取得された情報に基づいて、ユーザ管理手段３０が要求ユーザと参加中ユーザとの間のマッチング距離を算出し、ユーザ管理情報１ｃを更新する。部分ネットワーク品質情報１aと同様に、ユーザ管理情報１ｃも既に参加中のユーザ同士の間でのマッチング距離については既に算出されており、要求ユーザに関連する部分が新規に算出され追加されることで更新される。
【００３０】
ステップS２３では、ユーザ管理情報１ｃとマッチング情報１ｂとを参照して、マッチング部２０が要求ユーザの所属グループを決定する。当該決定については、以下説明する各実施例にて具体的に説明する。
【００３１】
なお、図２に戻り、ステップS２〜S4（ステップＳ２は図４の各詳細ステップを含む）では部分ネットワーク品質情報１a、マッチング情報１ｂ及びユーザ管理情報１ｃが更新される。これに対してステップＳ５では、少なくともマッチング情報１ｂが更新される。ステップＳ５において、部分ネットワーク品質情報１a及びユーザ管理情報１ｃについては、（１）マッチング情報１ｂと同じく更新して、ゲーム終了ユーザの部分の情報を削除してもよいし、（２）更新せずに、ゲーム終了ユーザの部分の情報をそのまま残しておいてもよい。
【００３２】
（１）の場合は、終了ユーザが再度要求ユーザとしてマッチング要求を行う場合、要求ユーザに関連するネットワーク品質情報１a及びユーザ管理情報１ｃが再度取得及び算出され、マッチング要求の都度最新の状態に更新される。よって、当該最新状態に即したマッチングが可能になるという効果がある。
【００３３】
（２）の場合は、終了ユーザが再度要求ユーザとしてマッチング要求を行う場合に、要求ユーザに関連するネットワーク品質情報１a及びユーザ管理情報１ｃはキャッシュとして保持されている。当該キャッシュの利用により、図４で説明したフローに負荷の少ない別実施形態を適用することができる。
【００３４】
すなわち、当該キャッシュの利用により、ステップS２１においてネットワーク品質情報提供サーバ２への問い合わせが不要となり、ネットワーク品質情報提供サーバ２における問い合わせ応答の負荷を抑える効果がある。また当該ステップS２１における問い合わせと、ステップS２２における算出を省略してよいので、マッチングサーバ１における処理負荷も低減される。
【００３５】
（２）において上記のようにキャッシュを利用する場合も、オンラインゲームに参加することが想定されるユーザ全体に対して、所定期間毎に定期的に部分ネットワーク品質情報取得手段１０が当該ユーザに対応する部分ネットワーク品質情報１aを取得しておき、ユーザ管理手段３０がユーザ管理情報１ｃも対応させて更新することで、適宜最新の状態に追随したマッチングを可能とすることができる。なお、オンラインゲームへの参加が想定されるユーザの情報は、ゲーム管理サーバなどにおける参加履歴情報から抽出する、またはマッチングサーバ１を利用したことのあるユーザの情報を当該マッチングサーバ１内に保存しておくなどによって、既知の情報とすることができる。
【００３６】
以下、本発明を適用した各実施例を説明し、図４の各ステップ等を具体的に説明する。各実施例は上記（１）のキャッシュを利用しない場合につき説明するが、上記（２）のキャッシュを利用する場合も同様に実施可能である。第１実施例では、部分ネットワーク品質情報１aを取得するためにパケット遅延取得手段１１のみを利用し、パケット棄却率取得手段１２ないしセグメント取得手段１４は利用しない場合を例として説明する。
【００３７】
[第１実施例]
図５は、当該第１実施例においてユーザ管理情報１ｃが更新される例である。ここでは、ユーザa〜gが既にオンラインゲームに参加中であり、ある時点で新規にユーザｎがマッチング要求を行うものとする。図５の（A）が更新前であり、（B）が更新後である。
また、図６は、当該参加中ユーザa〜g及び新規参加要求ユーザnに対してマッチング情報１ｂが更新される例であり、同じく（A）が更新前を、（B）が更新後を示す。
【００３８】
第１実施例においては、図５の（A）に例を示すように、参加中のユーザa〜gに対するユーザ管理情報１ｃは、各ユーザ間における部分ネットワーク品質情報１aとしてパケット遅延取得手段１１が取得した遅延を、ユーザ管理手段３０が単位（ms）を含めそのままの値でマッチング距離として採用する。すなわち、ユーザa-b間のマッチング距離はその遅延の値5msであり、ユーザa-c間のマッチング距離は30msであり、などといったように、各ユーザa〜g間のマッチング距離を与えることでユーザ管理情報１ｃが得られている。
【００３９】
ここでは遅延をマッチング距離として採用するに際して、ユーザの組み合わせに対して対称となるようにして利用することとする。よって遅延は上り下りなど考慮せずいずれか一方を用いて、あるいは上り下りの平均を用いるなどして定義することとする。こうして、図５では重複する下三角部分を省略したテーブル形式で、ユーザ管理情報が得られている。また自身から自身への遅延は無意味であるので、たとえばa-aの欄は空欄(−)としてある。
【００４０】
また、図５の(A)におけるマッチング距離の関係にあるユーザa〜gに対してマッチングで決定されたグループ分けが図６の(A)であり、マッチング距離の近いユーザ同士が同じグループに所属する結果となっている。すなわち、図６の（Ａ）におけるグループ１，２，３の所属ユーザ同士の図５の（Ａ）におけるマッチング距離（遅延値）を見ると、グループ１内では距離(a-b)=9ms、グループ２内では(c-d)=9ms、(c-e)=10ms、(d-e)＝6ms、グループ３内では(f-g)=8msと全て10ms以内の近さであるのに対し、別グループに属するユーザ同士は例えば(a-c)=30msといったように、全て20msよりも遠い結果となっている。こうしたグループ分けを可能とする手順を、新規ユーザnが参加する場合を用いて説明する。
【００４１】
図５及び図６それぞれの(A)の状態となっているある時点で、新規ユーザnがマッチング要求を行ったとする。ステップS２１で、要求ユーザnと参加中ユーザa〜gとの間で定まる部分ネットワーク品質情報が、パケット遅延取得手段１１によって遅延の値として新規に取得される。ステップS２２で、当該遅延の値をそのままマッチング距離として採用することで、ユーザ管理手段３０がユーザ管理情報の新規追加部分を求め、ユーザ管理情報１ｃを更新する。
【００４２】
当該更新されたユーザ管理情報１ｃが、図５の（Ｂ）に示されている。すなわち（Ａ）の状態に対して、新規ユーザnと参加中ユーザa〜gとの間のマッチング距離の情報が追加されることで、ユーザ管理情報１ｃが更新されている。
【００４３】
ステップＳ２３では、当該時点での図５の（Ｂ）に示す更新されたユーザ管理情報１ｃと、当該時点での参加中ユーザa〜gにつき定義された図６の（Ａ）に示す更新前のマッチング情報１ｂとを用いて、マッチング手段２０が新規ユーザnのマッチングを行う。
【００４４】
図７は、図５の（Ｂ）のユーザ管理情報におけるマッチング距離をおいて存在するユーザa〜g及びnを模式的に距離空間に配置した図である。図７では、当該時点での図６の（Ａ）に示すマッチング情報１ｂにて設定されている、既に参加中のユーザa〜gの所属グループ情報も記載してある。図７を用いてステップＳ２３のマッチングを説明する。マッチングは以下の手順（手順１）〜（手順３）により行われる。
【００４５】
（手順１）
当該新規の参加要求ユーザからのマッチング距離（遅延値）が所定の閾値Tth以下となる参加中ユーザを全て選びだす。
【００４６】
すなわち、図７では（手順１）にてTth=20msとした例が示されている。すなわち、図６の（A）を参照することにより、要求ユーザnからマッチング距離が半径20ms以内に存在する参加中ユーザ端末は、a,b,f及びgとなる。これらのユーザが選出される。
【００４７】
（手順２）
マッチング情報をもとに、要求ユーザからのマッチング距離（遅延値）が当該閾値Tth以下となるユーザのみで構成され且つユーザ追加参加可能なグループを、（手順１）の選出ユーザの属するグループの中からさらに選出し、当該グループのうちでグループ内で要求ユーザnから最も遠いユーザとのマッチング距離（遅延値）が最小のグループを要求ユーザの所属グループとして決定する。
【００４８】
すなわち、図６の（A）のマッチング情報より、（手順１）で選出されたユーザa,b,f及びgはグループ1(a及びb)とグループ3(g及びf)に所属している。当該グループ1及び3はそれぞれ所属ユーザの全てが閾値Tth=20ms以下の範囲に存在し、且つ当該オンラインゲームの各グループ上限人数は例えば5人であり、両グループ共に新規ユーザを追加可能な状態にある。よってグループ1及び3が選出される。グループ1及び3のユーザのうち、要求ユーザnから最も遠いユーザはそれぞれ、b及びgであって、マッチング距離（遅延）はbが19ms、gが12msであるので、最小値を与えるgの属するグループ3を要求ユーザnの所属グループとして決定する。
【００４９】
（手順３）
上記（手順２）における条件を満たすグループが存在しなかった場合には、当該要求ユーザを要素とするグループを新規に作成する。
【００５０】
例えば、上記（手順１）及び（手順２）の説明例では閾値Tth=20msとすることで要求ユーザnはグループ3に所属が決定されたが、仮に閾値Tth=10msとするとそもそも（手順１）で選出されるユーザが存在しないので（手順３）が適用され、要求ユーザnは例えば新規グループ4に所属することとなる。仮にTth=11msとすると、（手順１）ではユーザfが選出されるが、当該fの属するグループ3の全ユーザ(f及びg)がTth=11ms以内に存在するわけではないので、（手順２）でグループ選出されず、同様に（手順３）が適用される。
【００５１】
なおまた、オンラインゲーム参加中のユーザ人数がゼロの場合、マッチング情報は空欄のテーブル等で与えられ、自動的に（手順３）が適用されることとなる。以降参加ユーザが増加するにつれ、（手順２）が適用される場合も生じてくることとなる。
【００５２】
以上のように（手順１）〜（手順３）で構成されるステップＳ２３のマッチングが行われると、当該マッチングの結果に基づいてステップＳ４でマッチング情報１ｂが更新される。図６の（Ｂ）は上記（手順１）〜（手順３）の説明で閾値Tth=20msとした例におけるマッチング情報１ｂの更新後を示してあり、要求ユーザnはグループ3に所属するユーザとして登録されている。
【００５３】
[第２実施例]
第２実施例は、第１実施例を変形したものである。第１実施例では、ユーザ管理情報１ｃがオンラインゲーム参加中のユーザ数の２乗に比例して増加するため、ユーザの増加につれてマッチングサーバ１におけるマッチング処理の負荷が過大となる可能性がある。第２実施例は、以下に説明する各グループを代表する代表ユーザを導入することにより、当該負荷を低減するという効果を奏する。第１実施例の説明例として図５〜図７で用いた参加中ユーザa〜g及び要求ユーザnを再度、第２実施例の説明に利用する。
【００５４】
第２実施例では、図５のようにユーザ管理情報１ｃをオンラインゲーム参加中の全ユーザのペアに対して構成するのではなく、グループ毎に所属ユーザの中から代表ユーザを決定して、当該代表ユーザのペアのみと、各グループ内でのユーザのペアのみとに分けてユーザ管理情報１ｃを構成する。図５の場合に対応する、第２実施例でのユーザ管理情報１ｃの例を図８に示す。
【００５５】
図８の（Ａ）は、各グループの代表ユーザ同士のペアに対してマッチング距離（遅延値）によって定義されたユーザ管理情報で、図５の（Ａ）に対応する例を示している。ここでは、図６の（Ａ）に示したグループ1(ユーザa及びbで構成)の代表ユーザがa、グループ2(ユーザc,d及びeで構成)の代表ユーザがd、グループ3(ユーザf及びgで構成)の代表ユーザがfとして、代表ユーザによるユーザ管理情報を示している。
【００５６】
また、各グループ1〜3内でも、各グループ所属ユーザ同士のマッチング距離（遅延値）でグループ内のユーザ管理情報が定義され、それぞれ図８の（Ａ１）〜（Ａ３）に示す通りである。第２実施例ではこのように、（Ａ）に示すグループ毎の代表ユーザによるユーザ管理情報と、（Ａ１）〜（Ａ３）に示す各代表ユーザに対応するグループ内でのユーザ管理情報とに分けて、ユーザ管理情報１ｃが管理される。こうした管理を行うための具体的な手順を、新規ユーザnを追加する場合を例に、第１実施例との差異の部分について説明する。
【００５７】
ステップＳ２１及びＳ２２並びにステップＳ２３の（手順１）における「参加中ユーザ」を、図８の（Ａ）に示す代表ユーザのみに限定して実行する。すなわち、第１実施例では新規ユーザnと参加中の全ユーザa〜gとの7つのペアについて処理が必要であったが、第２実施例では新規ユーザnと代表ユーザa,d及びfとの3つのペアのみを処理対象とすればよい。こうした点が、第２実施例における代表ユーザ導入による負荷低減の効果であり、全ユーザ数が多いほど効果は顕著となる。求まるマッチング距離（遅延値）は、ユーザn-a間が19ms、n-d間が40ms、n-f間が11msとなる。
【００５８】
（手順２）では、要求ユーザとのマッチング距離（遅延値）が閾値Tth以下となる代表ユーザに対応するグループのうち、参加人数が上限に達しておらず新規ユーザ追加可能なグループであって、且つ当該マッチング距離が最小となる代表ユーザに対応するグループを要求ユーザの所属グループとして決定する。すなわち、閾値Tth=20msであれば、当該閾値の半径内部の代表ユーザがa及びfであって、対応する両グループはユーザ追加可能であり、そのうちマッチング距離（遅延値）が最小となる代表ユーザfに対応するグループ3が、nの所属グループとして決定される。
【００５９】
（手順３）では、上記（手順２）における条件を満たすグループが存在しなかった場合に、当該要求ユーザを要素且つ代表ユーザとするグループを新規に作成する。
【００６０】
また、第２実施例では第１実施例との差異として、ユーザ管理情報の更新は次のようにすればよい。当該更新によって、代表ユーザも決定される。更新タイミングはステップＳ２２ではなく、所属グループが決定するステップＳ２３となる。当該ステップＳ２３における代表ユーザの決定には次の（１）（２）の場合がある。
【００６１】
（１）前記（手順３）が適用された場合すなわち、当該グループが新規作成グループである場合、唯一のメンバーである新たに参加したユーザが代表ユーザとなる。
【００６２】
（２）既存のグループに新たにユーザが所属することとなった場合、グループ内で各ユーザとのマッチング距離（遅延値）の総和が最も小さいユーザが代表ユーザとして決定される。なお、ユーザ数１人のグループがユーザ数２人となった場合には、昔から参加しているユーザを代表ユーザとしておけばよい。
【００６３】
なお、上記（２）の総和を計算するために、ステップＳ２３では新規ユーザの所属グループ内において、新規ユーザと参加中ユーザとの間の部分ネットワーク品質情報及びユーザ管理情報（ネットワーク距離）を、それぞれ部分ネットワーク品質情報取得手段１０及びユーザ管理手段３０が取得及び算出する。
【００６４】
なおまた、代表ユーザをマッチング距離の総和最小ユーザとして決定することで、図７に示したような距離空間において各グループの中心付近に存在し、代表ユーザとして適切なユーザを簡易に選択することができる。
【００６５】
以上のような代表ユーザの決定によりステップＳ２３では、当該決定された代表ユーザの情報と、追加されたユーザを含む当該グループ内の全ユーザ間のマッチング距離の情報とによって、当該グループに対するユーザ管理情報が更新される。さらに、当該グループにおいて決定された代表ユーザが以前の代表ユーザと異なる場合、又は新規グループが当該グループ内の新規代表ユーザと共に作成された場合には、図８の（Ｂ）に説明を示すように、代表ユーザ同士に対するユーザ管理情報もマッチング距離を新たな代表ユーザに対する値に書き換えて更新される。なお当該書き換えるマッチング距離はステップＳ２２で算出済みであり、更新には当該値を利用すればよい。
【００６６】
例えば、前記（手順２）で閾値Tth=20msとして代表ユーザfのグループ3にnが追加された場合であれば、当該グループ3のユーザ管理情報は図８の（Ａ３）から更新されて（Ｂ３）のようになる。当該グループ3内で各ユーザとのマッチング距離の総和は、
ユーザf：[f-g]＋[f-n]=8+11=19ms
ユーザg：[g-f]+[g-n]=8+12=20ms
ユーザn：[n-f]+[n-g]=11+12=23ms
であり、ユーザfに対する総和が最小となるので、（Ｂ３）に示すようにグループ3において代表ユーザの変更はなくfのままである。よって、代表ユーザ間のユーザ管理情報は（Ａ）に示した状態のままである。仮に例えばグループ3の代表ユーザがnとなった場合には、（Ａ）はユーザa,d及びfに対してではなく、ユーザa,d及びnに対する情報として、マッチング距離の値を含めて（Ｂ）に記載しているように更新されることとなる。
【００６７】
[第３実施例]
第３実施例は、第１又は第２実施例それぞれにおいて追加処理として実施可能であり、部分ネットワーク品質情報取得手段１０内のセグメント取得手段１４が追加的に利用される。図９は、第３実施例を説明するための図である。
【００６８】
ISP内のネットワークが、図９の（Ａ）に示すように地理的に複数のセグメントで構成されており、セグメント内での遅延は小さく、セグメント間での遅延は大きいと考えられる場合において、（Ｂ）に示すように各セグメント内のユーザでグループを作成し、異なるセグメントに属するユーザ同士が同一グループに所属しないようにすることで、第３実施例ではよりネットワーク的な効率の高いグループ化を実現することができる。
【００６９】
一般に、ISPは地理的なセグメントに対して図９の（Ａ）に示すようにIPアドレス空間を割り当て、ユーザは自身が所属する地域に応じていずれかのセグメントよりIPアドレスの払い出しを受ける。セグメント取得手段１４はステップＳ２１における追加処理として、ネットワーク品質情報提供サーバ２に問い合わせ、要求ユーザのセグメントとアドレス空間に関する情報を取得する。ステップＳ２２では、その結果を用いることでユーザをセグメント毎に区別し、セグメント毎にユーザ管理情報を作成する。また、ステップＳ２３では、当該セグメント毎に区別されたユーザ管理情報を用いて（Ｃ）に示すようにマッチング情報もセグメント区別を設けて運用し、セグメント毎に所属グループを決めることで、セグメント内に閉じてグループが作成される。
【００７０】
すなわち、第３実施例では、上記のようにセグメントによるユーザ管理情報及びマッチング情報の区切りを設けたうえで、各セグメント内では第１実施例又は第２実施例における手法をそのまま採用する。
【００７１】
なお、第１〜第３実施例では、マッチング距離としてパケット遅延取得手段１１の取得する遅延をそのまま利用する場合に限定して説明したが、より一般に、次のようなマッチング距離を採用してもよい。すなわち、あるユーザ端末間に対してステップＳ２１においてパケット遅延取得手段１１が遅延値xを取得し、さらに、パケット棄却率取得手段１２が棄却率yを取得し、物理的距離取得手段１３が物理的距離zを取得する。こうして、ユーザ管理手段３０は、ステップＳ２２においてマッチング距離f(x, y, z)を、
f(x, y, z) ＝ ax ＋ by ＋ cz
などによって算出することができる。ここでa,b,cは各取得パラメータx,y,zに重みを付与するための非負の定数であり、x,y,zは適宜規格化するなどして無次元化しておくものとする。
【００７２】
このように、パケット遅延取得手段１１ないし物理的距離取得手段１３のうちの少なくとも一つを用いてマッチング距離を求めてもよい。取得したパラメータのx,y,zのうち利用しないパラメータがある場合には、定数a,b,cのうち対応するものをゼロに設定すればよい。f(x, y, z)には上記とは別のその他の関数を利用してもよい。
【００７３】
なお特に、遅延値x及びパケット棄却率yは試験パケット等の送受信し、それを測定することで得られる情報である。本発明では特にこれらx及び／又はyを用いてマッチングを行うことで、ユーザ端末間での定量的な通信実績に裏付けられた低遅延なオンラインゲーム環境を実現することができる。なお、これらx,yは必ずしもネットワーク品質情報提供サーバ２のネットワーク品質情報１aとして保存されている値を利用せずに、値を求めるステップS２１などの時点で直接的に部分ネットワーク品質情報取得手段１０が両ユーザ端末にアクセス又は依頼して値を測定するようにしてもよい。
【００７４】
図１０は本発明のオンラインゲームシステムの構成図である。オンラインゲームシステム３は、マッチングサーバ１及びネットワーク品質情報提供サーバ２を含み、各ユーザは以上説明したようにマッチングサーバ１とやりとりする。本発明の、このようなオンラインゲームシステム３におけるビジネスモデルには、以下（１）（２）に示す形態などがある。
【００７５】
（１）ネットワーク品質情報提供サーバ２はISPが運用し、マッチングサーバ１はゲーム会社が運用する。ゲーム会社は、ISPからネットワーク品質情報を得るための対価を支払う。料金体系として、月額固定や、ネットワーク品質情報提供サーバ２への通信量に比例した料金などが考えられる。
【００７６】
（２）ネットワーク品質情報提供サーバ２及びマッチングサーバ１の両者を、ISPが運用する。この場合には、ISPがゲーム会社に対してマッチングサーバ１を利用するAPI(アプリケーションプログラミングインタフェース)を提供し、マッチング要求、グループ問い合わせなどの機能を提供する。このとき、ゲーム会社は独自のポリシーに従う自社で運用されるマッチングサーバを別途保持していてもよい。その際には、機能拡張のためにISPがマッチングAPIを提供する形態となる。
【符号の説明】
【００７７】
１…マッチングサーバ、２…ネットワーク品質情報提供サーバ、３…オンラインゲームシステム、１０…部分ネットワーク品質情報取得手段、２０…マッチング手段、３０…ユーザ管理手段
【図１】
2013013027.tif 000003
【図２】
2013013027.tif 000004
【図３】
2013013027.tif 000005
【図４】
2013013027.tif 000006
【図５】
2013013027.tif 000007
【図６】
2013013027.tif 000008
【図７】
2013013027.tif 000009
【図８】
2013013027.tif 000010
【図９】
2013013027.tif 000011
【図１０】
2013013027.tif 000012