JP2000508097A - サーバおよび通信リンクの属性に基づいてクライアントを選択するためのネットワークマッチメーカ - Google Patents

Abstract

(57)【要約】 マッチしたマルチユーザネットワークアプリケーションユーザの組を作成するネットワークマッチ方法である。各ユーザは、ネットワークに接続されたクライアントコンピュータのクライアントプログラム（ＣＬ１）に関連付けられる。これらのクライアントのユーザ、クライアント、サーバおよび／または通信リンクの属性に基づいて、これらのクライアントをマッチした複数の組に選別する。ネットワークマッチメーカサーバプログラム（ＭＭ）は、ピアツーピア、複数クライアント対単一サーバ、および複数クライアント対複数サーバの、３つの異なるネットワークアプリケーション形態で動作する。

Description

【発明の詳細な説明】 サーバおよび通信リンクの属性に基づいてクライアントを選択するための ネットワークマッチメーカ 関連仮出願（provisional application）へのクロスリファレンス 本特許出願は、1996年3月21日出願の米国仮出願第60/013,812号の利益を請求 する。 発明の背景 コンピュータネットワークは、情報を通信し共有するために多数のコンピュー タシステムを相互に接続するために広く用いられている。コンピュータネットワ ークはまた、多数のユーザがコンピュータプログラムの動作に加わることを可能 にするマルチユーザアプリケーションを実現するために用いることができる。一 般的な例としては、ビデオおよび遠隔地間での会議のアプリケーション、多数の ユーザが一緒にゲームをすることを可能にするオンラインマルチプレーヤーゲー ム、およびオンラインチャット環境がある。そのようなマルチユーザネットワー クアプリケーションのすべてに共通の課題は、ユーザのグループを集めて、マル チユーザアプリケーションの実行に参加させる効率的な方法を提供することであ る。今日、既知の解決策は、ユーザがどの人とマッチされたいか、などのユーザ の要求にしか対処していない。これらの解決策は、ユーザが、マッチされたい他 のユーザを選択するための手動による方法しか提供していない。これは、全ユー ザのプールの中で適切な数のユーザが存在する場合にしか実行できない。多数の ユーザが存在し、アプリケーションが、そのアプリケーションを実現するために 使用されるクライアントおよび／またはサーバコンピュータシステムのネットワ ーク性能または能力に対して特別な要求を有する場合には実行できなくなる。 多数のクライアントのためのネットワーク化されたアプリケーションは、３つ の形態で存在する。ピアツーピア（peer-to-peer）アプリケーションは、サーバ を必要とせずに多数のクライアントコンピュータによって実行される。このアプ リケーションの実行中のすべての通信トラフィックは、クライアント間に向けら れる。その他の多数のクライアントのネットワーク化されたアプリケーションは 、１つのサーバシステムを使用する。サーバは、すべてのクライアントによって 共有されるアプリケーションのうちのある部分を実行し得る。アプリケーション の残りの部分は、クライアントにおいて実行される。サーバはまた、通信コレク ションポイントとしての役割を果たすことができる。通信トラフィックのうちの 幾らかあるいはそのすべては、クライアントの各々とサーバとの間である。クラ イアントはさらに、必要に応じて、互いに通信し得る。最後に、マルチクライア ントアプリケーションでは、多数のサーバが使用され得る。１つのサーバの場合 と同様に、アプリケーションのうちの一部分は、サーバにおいて実行され得る。 多数のサーバはまた、クライアントのための通信コレクションポイントを与え得 る。 発明の要旨 本発明では、ネットワークマッチメーキングシステムを用いて、マルチユーザ ネットワーク化アプリケーションのユーザのマッチされた組を作る。各ユーザは 、ネットワークに接続されたクライアントコンピュータに関連する。また、ネッ トワーク上には、ネットワークマッチメーカであるソフトウェアプロセスを実行 するサーバコンピュータがある。実現例の中には、ネットワーク化アプリケーシ ョンを支持するためにも使用される１つまたはそれ以上の別のサーバがあるもの もある。クライアントは、そのユーザ、クライアント、アプリケーションの分類 およびインスタンスの属性、サーバの属性、ならびにクライアント−クライアン ト間、およびクライアント−サーバ間の通信リンクの特性に基づいて選択され、 マッチされた組にされる。ネットワークマッチメーカは、３つの形態のネットワ ークアプリケーションの実現、即ち、ピアツーピア、多数のクライアント対１つ のサーバ、および多数のクライアント対多数のサーバの形態で動作する。 本発明は、先行技術における上記問題点を解決し、且つ、ネットワーク化アプ リケーションについてユーザが互いにマッチされるための自動化された手段を提 供するネットワークマッチメーキングシステムを与える。ネットワークマッチメ ーカは、ユーザの好みおよび属性だけではなく、クライアントコンピュータ、ア プリケーション、およびアプリケーションにより必要とされる任意のオプション としてのサーバの属性、ならびにクライアント間およびクライアントと任意のオ プションとしてのサーバとの間の通信リンクの特性も考慮に入れる。 本発明の上記およびその他の特徴および利点は、以下に示す本発明の詳細な説 明および添付の図面から明らかになる。 図面の簡単な説明 図１は、本発明による第１のクライアントとマッチメーカとの間のインタラク ションを示すフローチャートである。 図２は、本発明による第２のクライアントとマッチメーカとの間のインタラク ションを示すフローチャートである。 図３は、本発明による、クライアントと図１および図２のマッチメーカとの間 のインタラクションを示すフローチャートである。 図４は、本発明による通信属性の測定を示すフローチャートである。 図５は、本発明によるマッチングのステップを示すフローチャートである。 図６および図７は、本発明による終了（termination）方法を示すフローチャ ートである。 図８は、本発明による、クライアント、サーバおよびマッチメーカのインタラ クションを示すフローチャートである。 図９および図１０は、本発明による通信属性の使用を示すフローチャートであ る。 図１１は、図８のマッチメーカのマッチング動作を示すフローチャートである 。 発明の詳細な説明 本発明は、マルチユーザアプリケーションについて、クライアントによって使 用されるネットワーク上のサーバシステムにおいて動作するネットワークマッチ メーキングプロセスに関する。このクライアントは、マッチによりクライアント のマッチされた組にされる。ネットワーク化アプリケーションが、そのアプリケ ーションによって使用され得る多数のサーバを有するネットワーク化されたシス テムにおいて動作する場合、ネットワークマッチメーカはまた、サーバを、クラ イアントのマッチされた組にマッチする。本発明の背景にあるキーとなるアイデ アは、クライアントおよびサーバがユーザの属性だけではなく、クライアント、 サーバおよびアプリケーションの属性、ならびに、帯域幅、待ち時間（latency ）、およびパケット損失などのネットワーク性能特性にも基づいてマッチされる ことである。 属性 ネットワークマッチメーカは、ユーザ、クライアントおよびサーバの属性と、 それらの間のネットワークリンクの特性とを、アプリケーションの要求と比較す ることによって、クライアントおよびサーバをマッチし、マッチされた組にする 。クライアントおよびユーザ属性 ユーザ属性には、ネットワーク上のアプリケーションに関するユーザの明白な 特性が含まれる。幾つかの例には、技術レベル、年齢、ユーザがマッチしたくな い人などのものが含まれる。より明確な議論のために、ユーザ属性およびクライ アント属性を１つの集団にまとめ、「クライアント属性」と呼ぶ。クライアント 属性は、クライアントコンピュータシステムの能力を説明する。クライアントコ ンピュータの性能、そのネットワークリンクのタイプならびに性能、およびイン ストールされるネットワーク上のアプリケーションのタイプならびにバージョン は全て、クライアント属性の適当な例である。 アプリケーション属性 アプリケーション属性とは、ネットワーク上のアプリケーションの要件である 。これらの要件の例には、クライアントのタイプならびに性能、任意の必要なサ ーバのタイプならびに性能、およびクライアント間ならびにクライアントとサー バとの間のネットワークリンクの必要な特性が含まれる。アプリケーション属性 は、２つの形態、すなわちクラスおよびインスタンスの形態をとる。アプリケー ションのクラス属性は、アプリケーションの任意のインスタンスに適用される。 ネッ トワーク上のマッチメーカは、それぞれのアプリケーションの多数のインスタン スが存在する環境で操作する。アプリケーションのインスタンスが作成されると 、さらなるインスタンス属性も適用され得る一方で、そのインスタンスがクラス 属性を受け継ぐ。これらのインスタンス属性は、インスタンスによって受け継が れたクラス属性の幾つかを簡単に覆し得るが、その他はアプリケーションインス タンスにのみ特有のものであり得る。 サーバ属性 静的サーバ属性の例には、サーバシステムのタイプならびに性能、およびサー バにインストールされる任意のネットワーク上のアプリケーションソフトウェア のタイプならびにバージョンが含まれる。動的属性には、サーバへの現在の負荷 が含まれる。アプリケーションインスタンスをサーバに割り当てるときに、サー バへの現在の負荷を考慮することが、複合サーバシステムにおけるサーバで動的 負荷釣り合いを行う方法である。 通信属性 通信属性とは、２つのコンピュータシステム間のネットワークリンクの特性で ある。これらには、クライアント間のリンクおよびクライアントとサーバとの間 のリンクが含まれる。ネットワークリンクの特性には、利用可能な帯域幅、待ち 時間、およびパケット損失レートが含まれる。多くのネットワーク上のアプリケ ーションは、一定の帯域幅に関する最低要件と、待ち時間に関する最大要件とを 有する。同様に使用可能な２つのコンピュータシステム間の通信リンクの特性の 価値のある尺度（measures）であり得る、通信性能の他の測定基準が存在する。 マッチ（Matches）のタイプ ネットワークマッチメーカは、ユーザを自動的にマッチされた組（matched se t）にマッチさせる、または、完全なマッチされた組が完成するまで他のユーザ が目を通して参加することを選択し得るマッチオファーをユーザに形成させるこ とによって、ユーザのマッチされた組を形成する。これらの場合の両方において 、 マッチメーカは、複数のサーバが利用可能であり且つネットワーク上のアプリケ ーションがサーバを必要とするならば、マッチされた組用のサーバを選択する。 自動的なマッチは、ユーザ作成マッチオファーの単純な変形であるので、ユーザ 作成マッチオファーが最初に論じられる。 これらのマッチタイプの両方において、仲裁者の概念がある。仲裁者とは、マ ッチオファーのインスタンス属性を選択する代理人である。マッチオファーが形 成されると、それがアプリケーションのクラス属性を受け継ぐ。次いで、仲裁者 が属性を改変してマッチオファーインスタンス属性を形成し得る。アプリケーシ ョンがマッチオファー用に起動されるときには、マッチオファーのインスタンス 属性を使用して起動する。ユーザ作成マッチオファーでは、最も単純な場合は、 オファーを形成したユーザが伸裁者である場合である。自動的なマッチでは、マ ッチメーカ自身が仲裁者である。他の可能性は存在する。マッチオファーにおけ るユーザの幾らかまたは全てが仲裁者の能力を共有することか可能である。それ らは、属性の最後の設定が勝つように、互いの属性選択を覆すことが可能であり 得る。または、仲裁者の能力を共有するユーザの間に投票の図式が存在し得る。 マッチメーカおよびユーザ仲裁者の能力の混合を画像化することも可能である。 インスタンス属性の幾つかは、マッチメーカおよびマッチオファーに参加する１ 人以上のユーザによる他者によって、設定され得る。 ユーザ作成マッチオファー ユーザは、マッチする他のユーザに対するユーザ自身に特有のオファーを形成 し得る。これらは、マッチオファーと呼ばれる。マッチオファーを形成するため には、ユーザは、１つのアプリケーションを選択し、そのアプリケーション用に マッチオファーを形成する。オファーはアプリケーションのクラス属性を受け継 ぐが、ユーザは、自分に特有のマッチオファーに関するさらなるインスタンス属 性を付加し得る。オリジナルのマッチオファーを形成したユーザは、そのオファ ーの仲裁者と見なされ、マッチオファーのインスタンス属性を選択することが可 能な唯一の人物となる。他のユーザは、これらのマッチオファーに目を通し、そ の属性を調べ、受け入れ可能と分かるオファーを選択し、そしてそのオファーに 参加しようと試みる。マッチメーカは、クライアント属性と、必要なインスタン ス属性に関連する任意の通信リンクの通信属性とを比較する。それらがマッチオ ファーの必要な属性にマッチしない場合には、マッチメーカは、ユーザがマッチ オファーに参加するのを妨げる。マッチする場合には、新しいクライアントがオ ファーに参加し、そのオファーに関連するクライアントのマッチされた組に加え られる。クライアントがそのマッチオファーに参加しようと試みると、マッチメ ーカは、同様にクライアントの属性を他のクライアントの属性と比較して、クラ イアントがマッチオファーに参加することを許される前に、ユーザ属性がマッチ することを確認する。一度十分なクライアントがマッチオファーに参加すると、 仲裁者は、アプリケーションの起動を選択することが可能になる。 任意の関連通信リンクの特性が、どのクライアントがマッチオファーに参加す ることが可能であるかということにどれほどの影響を及ぼすかを、ネットワーク マッチメーカがどのように決定するかは、ネットワーク上のアプリケーションの 構成に依存し、そして以下の段落で説明される。 ピアツーピア（Peer-to-peer） クライアントがマッチオファーへの参加を要求すると、ネットワークマッチメ ーカは、新しいクライアントに、新しいクライアントと、既にマッチオファーの メンバーである既存のクライアントの全てとの間の通信リンクの特性を測定する ように要請する。新しいクライアントとマッチオファーのメンバーである既存の クライアントとの間の通信リンクの特性は、ネットワーク特性のベクトルでマッ チメーカに戻される。これらの特性は、マッチオファーに関するインスタンス属 性の要件と比較される。アプリケーションは、アプリケーションを実行すること を必要とされる対等者（peer）間のネットワークリンクの通信特性に関する、ア プリケーション自体のクラス属性を有する。マッチオファーの創造者は、これら の属性を覆して、対等者間の通信リンクの特性に関するインスタンス属性を形成 し得る。クライアント属性および通信リンクの属性がアプリケーションインスタ ンスの要件にマッチする場合には、新しいクライアントがマッチオファーに参加 する。 多クライアントツー単一サーバ この場合には、サーバは、アプリケーションの必要な部分を取り仕切るために 必要な特性のすべてを有すると仮定される。ピアツーピアの場合のように、クラ イアントがマッチオファーに参加したいと要求すると、ネットワークマッチメー カはこの新しいクライアントに、新しいクライアントと既にマッチオファーのメ ンバーである現在のすべてのクライアントとの間の通信リンクの特性を測定する ように求め得る。これらの特性は通信特性のベクトルとしてマッチメーカに戻さ れ、これは、クライアントツークライアントリンクの通信特性のためのアプリケ ーションインスタンス属性の要件と比較され得る。この場合には、ネットワーク マッチメーカはまた、新しいクライアントに、新しいクライアントと単一のサー バとの間の通信リンクの特性を測定するように求め得る。このリンクの特性はま た、クライアントツーサーバリンクの通信特性のためのインスタンス属性と比べ られる。すべてが適切に一致すると、新しいクライアントはマッチオファーに参 加することが許される。単一サーバを用いる多くの多ユーザネットワークアプリ ケーションでは、クライアントツークライアント通信のすべてはサーバを通して 行われ、このため、直接のクライアントツークライアント通信は行われない。こ れらの場合には、クライアントからサーバへの通信リンクの特性のみが関連し得 る。 多クライアントツー多サーバ 多サーバシステムでは状況はもっと複雑である。システムは、クライアントと 多サーバとの間の通信リンクの特性を考慮するだけではなく、さらにサーバシス テムの属性も考慮しなければならない。ネットワークマッチメーカはクライアン トをマッチさせてマッチされた組に組み込むだけではなく、多サーバシステムの うちのいずれを各クライアントマッチされた組に関連させるかを決定しなければ ならない。本明細書では、マッチメーカは最終的にはマッチオファーに関連する 各クライアントマッチされた組にマッチする単一サーバを選択すると仮定する。 本明細書で概略を述べる方法は、多ユーザアプリケーションを走らせるとき多サ ーバを用いることが必要なアプリケーションをサポートするように容易に一般化 され得る。しかし、ネットワークマッチメーカがマッチオファーのための特定の サーバを選択するために使用し得るサーバ選択方法には、早期サーバ結合(early server binding)および晩期サーバ結合(late server binding)の２つがある。 クライアントが特定のアプリケーションのためのマッチオファーに参加するこ とを求めると、ネットワークマッチメーカはクライアントに、クライアント自身 と、マッチオファーに関連するマッチされた組のメンバーである他のすべてのク ライアントと、そのアプリケーションで利用可能なサーバシステムのすべてとの 間の通信リンクの特性を測定するように求める。そのアプリケーションで利用可 能なサーバは、サーバの属性およびそのマッチオファーインスタンスのためのサ ーバ要件の属性に基づくサーバすべての部分集合である。クライアントがマッチ オファーを作成するときは、アプリケーションのクラス属性を上書きするかまた はこれに追加されるアプリケーションのインスタンス属性を特定し得る。これに より、アプリケーションをサポートし得るサーバシステムの部分集合がさらに限 定され得る。新しいクライアントがマッチオファーに参加したいと要求すると、 ネットワークマッチオファーはクライアントの属性をマッチオファーの必要な属 性と比較し得る。これらがマッチすると、ネットワークマッチオファーは次に、 関連する通信リンクの特性を特定のマッチオファーの要件と比較し得る。 早期サーバ結合では、ネットワークマッチメーカは、マッチオファーの作成者 と有資格サーバとの間の通信リンクの特性のみを使用するサーバよりなる有資格 部分集合からサーバを選択する。多サーバがマッチオファーの要件を満たすマッ チオファーの作成者への通信リンクを有する場合は、ネットワークマッチメーカ はいくつかの規定された基準に基づいて１つを選択し得る。妥当な基準を用いる ことが最良であり得るが、他の基準も可能であり得る。新しいクライアントがマ ッチオファーに参加しようとすると、マッチメーカはクライアント属性、ならび に新しいクライアントとマッチオファーの現在のメンバーとの間の、および新し いクライアントから選択されたサーバへの通信リンクの特性を比較する。これら の属性および通信特性のすべてがマッチオファーの要件を満たす場合は、クライ アントは参加を許される。早期サーバ結合は最も簡単なサーバ選択方法であるが 、 これはいつでもすべてのクライアントにとって最良のサーバの選択を提供すると は限らず、クライアントによっては、異なるサーバを選択しておれば参加できた かもしれないマッチオファーに参加できなくなる場合もある。ネットワーク待ち 時間がネットワークリンクの重要な特性の１つである場合が明らかにこれに当て はまる。早期結合では、マッチオファーを作成しているクライアントにとって通 信待ち時間が最も短い有資格サーバが選択され得る。この待ち時間は、マッチオ ファーによって必要とされる待ち時間よりはるかに短い。マッチオファーの待ち 時間要件により、選択されたサーバの回りに仮想「球体」が形成される。選択さ れたサーバの回りの待ち時間球体の範囲内にあるマッチオファーの属性にマッチ するクライアントが、そのマッチオファーに参加することができる。他の有資格 サーバおよび他のクライアントの待ち時間「スペース」内の位置によっては、別 のサーバを選択する方が、最初のサーバ選択より、マッチオファーの作成者のみ ではなくもっと多くのクライアントに可能な最良の選択であり得る。 サーバ晩期結合はこの問題は取り除かれるが、もっと複雑である。サーバ晩期 結合では、ネットワークマッチメーカはマッチオファーのための有資格サーバの 簡潔リストを維持する。クライアントは通常の方法でマッチオファーに参加する 。新しいクライアントの属性は、先ずマッチオファーの属性と比較される。これ らがマッチする場合は、ネットワークリンクの特性が比較される。マッチメーカ は、新しいクライアントとマッチオファーのメンバークライアントとの間のネッ トワークリンクの特性を、マッチオファーのインスタンス属性と比較する。これ らがマッチする場合は、クライアントとサーバ簡潔リストとの間のネットワーク リンクの特性がマッチオファーのインスタンス属性と比較される。新しいクライ アントとサーバ簡潔リストとの間の通信リンクのうちの１つ以上がマッチオファ ーの要件を満たす場合は、クライアントはこれに参加することが許される。ネッ トワークマッチメーカは次に、このマッチオファーに関連するサーバリストを整 理し、これによって新しいクライアントからサーバへの通信リンクの特性がマッ チオファーのインスタンス属性を満たさないものを取り除く。これにより、マッ チオファーのメンバーである現在のクライアントが依然としてマッチオファーの 要件を満たすことが保障される。調整者が最終的にゲームの開始を選択するとき 、簡潔 サーバリストには１つより多いサーバが存在し得る。ネットワークマッチメーカ は選択する選択基準を用いて最終サーバを選択し得る。典型的には、この選択基 準により、マッチオファーのメンバーであるクライアントすべてにとって最良の 全体的な通信特性を有するサーバが選択され得る。多くのネットワークアプリケ ーションでは、クライアント間では直接の通信は行われない。クライアントとサ ーバとの間の通信が存在するだけである。この場合には、クライアント間の通信 リンクの特性を測定する必要はなく、従ってこれはマッチメーキングプロセスの 一部を構成しない。 自動マッチ 自動マッチは、ユーザがマッチメーカにユーザとマッチさせるための自動マッ チオファーを作成するように求めることを除いては、ユーザ作成マッチオファー と非常に類似している。ユーザは走らせるアプリケーションを特定し、自動マッ チを要求する。ネットワークマッチメーカは、同じアプリケーションの自動マッ チを要求しているユーザを調べ、これらを組織してマッチされた組を形成しよう と企てる。マッチメーカは、クライアントとマッチする自動マッチオファーを作 成する。自動マッチの作成の一部として、ユーザには、アプリケーションの自動 マッチオファーインスタンスの属性への修正を特定する能力が与えられ得る。１ つの例としては、ユーザは熟練プレーヤーのみとのゲームに対して自動マッチを 求めてもよい。 クライアントが自動マッチを要求すると、マッチメーカは、クライアントの属 性および現存する自動マッチオファーの属性に適用可能なような依頼者の通信特 性を比較する。クライアントの属性およびクライアントの適用可能な通信特性が 自動マッチオファーにマッチすると、クライアントは、マッチオファーに関連す るマッチされたクライアントの組に入れられる。クライアントの属性および適用 可能な通信特性が自動マッチオファーのインスタンス属性にマッチしなければ、 マッチメーカは、次の自動マッチオファーに移る。これは、クライアントがある 自動マッチオファーにマッチされるまで、またはそれ以上の自動マッチオファー が存在しなくなるまで続く。新しいクライアントが自動マッチオファーの何れに もマッチしなかった場合には、ネットワークマッチメーカは、新しい自動マッチ オファーを作成し、新しいクライアントをそれに参加させる。ある特定の自動マ ッチオファーが、属性が必要とするようなクライアントを十分に持っていれば、 マッチメーカは、アプリケーションのインスタンスの実行を生じさせる。ネット ワークマッチメーカはまた、自動マッチオファーの実行のための適当なタイムア ウト期間をサポートする。 ピアツーピア、単一のサーバに対して複数のクライアント、および複数のサー バに対して複数のクライアントという特定のケースは、ユーザ作成マッチオファ ーを有しているのでこの枠組内で全て処理される。自動マッチオファーの最後の 詳細は、マッチオファーを手動で走査検索（browsing）するユーザも自動マッチ オファーを見て、参加できることである。 通信属性の例 最も重要な通信属性は、帯域幅、待ち時間、およびパケット損失レートである 。通信ネットワークの他の属性が、あるアプリケーションにおいては重要であり 得るが、これらは、最も広く重要な属性である。これらの属性が、クライアント およびサーバをマッチオファーにマッチさせるマッチメーカによってどのように 使用されるかの例を以下に示す。これらの例のために、ここでの考察は、通信属 性がマッチングを行うプロセスでどのように使用されるかのみに関連する。他の クライアントおよびサーバの属性は無視される。 帯域幅は、ある特定のネットワークリンクによってサポートされ得るデータ率 である。ネットワーク化されたアプリケーションは、クライアント間またはクラ イアントとサーバとの間に送信する必要があるというデータ率に関する要件を有 する。例として、クライアント間の音声通信と共に、または音声通信なしで動作 するアプリケーションを考えよ。デジタル音声と共に使用された場合には、音声 データは、多大な量のデータ帯域幅を消費する。さらに、アプリケーションがサ ーバの必要がないピアツーピアアプリケーションである場合を考えよ。この例で は、ユーザが、このアプリケーションのためのマッチオファーを作成し、音声通 信を可能とするためにこのマッチオファーのインスタンス属性を設定する。新し いクライアントが、マッチオファーに参加することを要求すると、マッチメーカ は、新しいクライアントに対して、新しいクライアントとすでにそのマッチオフ ァーのメンバーであるクライアント全員との帯域幅を測定することを要求する。 新しいクライアントと、マッチオファーの現存するいずれかのメンバーとの間の 帯域幅が、音声が使用可能である時のアプリケーションの帯域幅要件を支持する には低すぎる場合には、マッチメーカは、現存するクライアントの一人に対する 通信帯域幅のクライアント属性が、クライアント対クライアントの通信帯域幅に 関するマッチオファーのインスタンス属性にマッチしないと考える。従って、新 しいクライアントが、そのマッチオファーに参加することが阻止される。同じク ライアントは、このマッチオファーインスタンスがクライアント対クライアント の音声が使用可能でないことを特定する場合に、同じアプリケーションのマッチ オファーに参加することを許可され得る。このことは、クライアント対クライア ントの帯域幅に関するマッチオファーインスタンス属性が、新しいクライアント から、そのマッチオファーの現存するクライアントメンバーの各々への帯域幅以 下である場合に当てはまる。 待ち時間は、別の重要な通信属性である。待ち時間は、通信データが、あるシ ステムから別のシステムへとネットワークリンク上を移動する時間である。対話 型アプリケーションの多くが、通信待ち時間に関する厳密な要件が満たされない 場合にはアプリケーションが正しく動作することを阻止する通信待ち時間に関す る厳密な要件を有する。通信リンク上の待ち時間合計は、長距離にわたる信号の 伝搬時間を含む多くの要素の合計である。他の要素は、一般的に最小限にされ得 る、または低減され得るが、伝搬遅延は、物理法則によって設定される。サーバ を介した複数のクライアント間で行われる高度対話型のゲームを想像せよ。ゲー ムインスタンスにおける各クライアントが、サーバを介して他のクライアントに 対して通信データを送信および受信する。この例において、このゲームをする可 能性のあるクライアントプールが、広い地理的領域に広がり、同じ領域に広がる 複数のサーバも存在することも考慮せよ。このゲーム例は、クライアントとゲー ムインスタンスに使用されるサーバとの間の通信遅延に関する厳密な待ち時間要 件を有する。クライアントとサーバとの間の待ち時間がこれを越えると、このゲ ームインスタンスにおける１人のクライアントまたはクライアント全員に対する ゲームプレイの質が容認不可能となり得る。この例では、マッチメーカは、クラ イアントをマッチされた組へと共にマッチしなければならないだけでなく、クラ イアントの各マッチされた組を特定のサーバにマッチしなければならない。上記 のように、サーバをクライアントのグループにマッチさせるための２つの方法が ある、すなわち、早期サーバ結合および晩期サーバ結合である。早期サーバ結合 を使用した場合には、マッチメーカは、マッチオファーにおける最初のクライア ントに対して測定された最短待ち時間を有するサーバを選択する。新しいクライ アントの各々がマッチオファーに参加しようと試みる際に、マッチメーカは、そ のマッチオファーに対して選択されたサーバに対する待ち時間を測定することを クライアントに要求する。測定された待ち時間が、待ち時間に対するマッチオフ ァーインスタンスの要件を満たす場合には、新しいクライアントは、参加を許可 される。最終結果は、そのマッチオファーに参加するクライアント全員が、マッ チオファーインスタンスの待ち時間に関する要件を満たすことである。サーバ晩 期結合を使用した場合には、マッチオファーが最初に作成される時に、マッチメ ーカが、マッチオファーのインスタンス属性の全てにマッチするサーバ全員のリ ストを作成する。クライアントがマッチオファーに参加する際に、マッチメーカ は、リスト中のサーバの各々に対する待ち時間を測定することをクライアントに 要求する。新しいクライアントは、この測定された待ち時間のベクトルをマッチ メーカに提供する。このベクトルにおける各待ち時間は、マッチオファーの待ち 時間属性要件と比較される。１つ以上の待ち時間ベクトルエレメントが、マッチ オファーの待ち時間要件を満たす場合には、新しいクライアントの参加が許可さ れる。次に、マッチメーカは、マッチオファーに関連するサーバリストから、新 しいクライアントに対する対応の待ち時間ベクトルエレメントがマッチオファー の要件を満たさなかったサーバを取り除く。一旦望ましいクライアント全員がマ ッチオファーに参加すると、除去済みのリスト中に１つを越えるサーバが存在し 得る。マッチメーカは、次に、単一のサーバを選択するためにある基準を用いる 。基準の１つは、サーバとクライアント全員との間の平均待ち時間が最小限であ ったサーバを選択することである。別の基準は、各クライアントとサーバとの間 の 待ち時間の差を最小限にすることである。 よく管理されたネットワークにおいて、ネットワーク中の２つの地点間の待ち 時間のほとんどが、ネットワーク伝搬時間に起因する。早期および晩期サーバ結 合の両方のケースにおいて、これは、クライアントが、ネットワーク中で近くに 位置するサーバにマッチされる傾向があることを意味する。ネットワークがネッ トワーク接続の距離を最小限にする傾向があれば、これにより、地理的に近接し たサーバにマッチされたクライアントが生じる。 パケット損失レートは、データがネットワークにおける送信中に失われる率で ある。ネットワークのほとんどは、パケットまたはフレームと呼ばれる個別単位 でデータを送信する。ＵＤＰなどのあるネットワークプロトコルは、保証された データの引き渡しを提供せず、従って、伝送損失に耐性のあること、またはデー タを再送信するための手段を提供することは、アプリケーション次第である。Ｔ ＣＰ／ＩＰ等の他のネットワークプロトコルは、保証された引き渡しを提供する 。しかし、パケットが失われた場合には、このことを送信者に知らせ、送信が再 試行されなければならない。残念なことに、これは時間がかかり、失われたパッ ケージが回復され得る前に多大な遅延を導入する。あるアプリケーションにおい ては、この遅延は、データの損失より多くの問題を引き起こす。従って、対話型 アプリケーションの多くは、最大許容パケット損失レートに関する要件を有する 。次にこれは、アプリケーションが、あるマッチオファーに対するマッチしたク ライアントおよびマッチしたクライアントの組に対するサーバの一部としてマッ チメーカを考慮することを望み得るというネットワークリンクの重要な属性とな る。この属性は他のネットワーク属性と同様に使用される。 本発明の概略 クライアント−サーバアプリケーションについて上述したが、これは、単一の サーバである場合またはマッチメーカが、多数のサーバから単一のサーバを選択 し、マッチオファーとマッチさせる場合のみを考慮している。多数のサーバが存 在する場合には、アプリケーションが多数のサーバを必要とし得ることも可能で ある。ネットワークを通して送信される２つの形式のデータを有するアプリケー ションについて考えよ。例えば、プレイヤー間での言語通信をサポートする対話 型ゲームについて考えてみよう。このゲームでは、ゲーム情報およびユーザ言語 データが送信され、このデータは、２つの個別のデータストリームに分割され、 クライアントと２つの異なるサーバとの間で流れる。１つのサーバがゲームデー タを取り扱っている間に、他のサーバは言語データを取り扱う。これによって、 言語データを扱っているサーバには、言語データ処理専用の特別な能力が当てら れ、その後、言語データは、受信先のクライアントに転送される。 この配置では、アプリケーションは、各サーバが特有の属性を有する２つのサ ーバを必要とする。ゲームデータおよび言語データは、異なる帯域幅、待ち時間 、およびパケット損失要件を有するため、アプリケーションは、２つのデータス トリームのそれぞれについて異なる要件を有する。このことは、クライアントと サーバとの間に、ネットワークリンクの特性に関して２組のアプリケーション属 性が存在することを意味する。本実施例のマッチメーキングプロセスでは、マッ チメーカは、マッチオファーへの参加を要求するクライアントに、クライアント から２つのサーバのそれぞれまでのネットワークリンクの特性を測定するように 要求する。クライアントがマッチオファーへの参加を許可されるためには、両組 のネットワーク特性が、クライアントから２つのサーバまでのネットワークリン クのそれぞれに対するアプリケーション要件について、マッチオファーのインス タンス属性とマッチしていなければならない。 上記の議論では、一旦十分な数のクライアントが、あるアプリケーション対す るマッチオファーに参加すると、そのアプリケーションは、そのマッチオファー にうまく参加したすべてのクライアントで開始されると想定していた。この開始 は、ユーザが作成したマッチオファーにおける調整器によって引き起こされ得る か、または、十分なクライアントが自動マッチオファーとマッチしたときには、 マッチメーカによって引き起こされ得る。 持続的なアプリケーションには他の重要な事例がある。これは、動作中にクラ イアントが参加および辞退することが可能なアプリケーションである。この場合 、ゲームは、単一のクライアントまたはマッチメーカによって自動的に開始され 得る。この場合、実行中のアプリケーションもまた、マッチオファーを具体化（ em body）する。アプリケーションが単一のサーバまたは複数のサーバを必要とする 場合、サーバは、アプリケーションが開始された時点で選択される。サーバは、 その属性およびアプリケーションに必要な属性に基づいて選択される。クライア ントが実行中のアプリケーションへの参加を要求すると、クライアントの属性は 、アプリケーションに必要な属性と比較される。適切なネットワークリンクの特 性が測定され、アプリケーションに必要なネットワーク属性とマッチされる。す べてがマッチする場合、新しいクライントは、実行中のアプリケーションに参加 することができる。後に、クライアントはアプリケーションから辞退することも 可能である。この状況は、クライアントが、早期のサーバ結合でマッチオファー に参加している場合と同一である。 本発明の実施態様の説明 本発明に関する上記の説明は、特に当業者に対する本発明の一般的な実施可能 性および本実施態様の実施可能性に集中して行われている。しかし、本発明をよ り迅速に理解するためには、本発明の比較的小さな部分のみを含み、比較的説明 が簡単で、さらに、比較的迅速かつ容易に理解される実施態様を詳細に考慮する ことが有用である。 本実施態様は、ピアツーピアーゲーム（即ち、サーバを用いずにプレイされる ゲームのことで、マッチメーカ自体が少なくとも１つのサーバとして実行される ）に対するマッチメーキングに関する。この特定の実施態様が用いるネットワー クは、周知のインターネットであり、このインターネットはまた周知のインター ネットプロトコル（例えば、ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰ）を用いる。さら に、簡単のため、本実施態様は、上記の発明によってのみ説明するが、この特定 の実施態様は、可能な代替を比較的ほんのわずかしか含んでいない。 用語「コンピュータプログラム」は、明細書全体にわたって、「プログラム」 と省略して示す。マッチメーカサーバプログラムが用いられ、このプログラム（ 「ＭＭ」と省略される）の実行インスタンスは、サーバコンピュータ上にある。 サーバコンピュータおよびプログラムの実行インスタンスの概念は、コンピュー タ技術において周知である。各コンピュータユーザ（本実施態様では、「ユー ザ」と省略される）は、ユーザ自身のコンピュータ上でクライアントコンピュー タプログラムのインスタンスを開始し、その間このコンピュータはクライアント コンピュータとなる。 図１を参照する。ステップ１１において、クライアントプログラム（ＣＬ１） のインスタンスは、要求をＭＭに送信する。インターネット通信によってメッセ ージ交換を用い要求を送信することは、データ通信およびコンピュータ技術にお いて周知である。要求は、ＭＭにゲームオファーを作成するように要求する。こ の要求は、要求されたタイプのゲームの固有(intrinsic)の属性およびユーザの コンピュータでインストールされているハードウェアおよびソフトウェアの属性 と共に、様々なゲームの属性およびユーザによって選択されるマッチ優先を含む 。ゲームの固有の属性は、ユーザのコンピュータ間のリンクの通信属性について の制限値を含む。ステップ１２において、ＭＭは、この要求を受け取る。ＭＭに 要求を送信するためにＣＬ１によって用いられるインターネットプロトコル（Ｉ Ｐ）の周知の固有特性は、以下の通りである。すべてのメッセージは、インター ネットプロトコルアドレス（ＩＰａｄｄｒ）の形式で返信ユニークネットワーク アドレスを搬送し、このアドレスを用いて、ＭＭはＣＬ１に返信データメッセー ジを送信し得る。これによって、ＣＬ１は、他のタイプのネットワークまたはリ ンクでは必要とされ得るような、要求内にアドレスを埋め込む必要がなくなる。 ステップ１３では、ＭＭは、要求からの属性およびＣＬ１の返信ユニークネット ワークアドレスを含むゲームオファー（ＧＯＲ１）を示すレコードを作成する。 レコード、レコードセット、およびこれらを作成および維持する技術は、コンピ ュータプログラム技術において周知である。ステップ１４において、ＭＭは、応 答をＣＬ１に送信し、ＣＬ１にマッチがまだ完了していないことを知らせる。ス テップ１５において、ＣＬ１は、ＭＭからの要求を待つ。このようにして、ＣＬ １は、まだ完了していないゲームマッチの第１のメンバーになる。ステップ１６ において、ＭＭは、他の潜在的なユーザにゲームオファーレコードの内容が利用 できるようにする。ステップ１７において、ＭＭは、他のクライアントからのさ らなる要求を待つ。 図２を参照する。ステップ２１において、ＣＬ１からの異なるユーザのコンピ ュータおよびＭＭからの異なるコンピュータで実行されるクライアントプログラ ム（ＣＬ２）の他のインスタンスは、ゲームオファーのリストに対する要求をＭ Ｍに送信する。ステップ２２において、ＭＭは、この要求を受け取る。ステップ ２３において、ＭＭは、ステップ１３で作成されたＧＯＲ１から得られた情報で 応答する。ステップ２４において、ＣＬ１は、ＧＯＲ１からのゲームオファー情 報を含むＭＭからの応答を受け取る。 図３を参照する。ステップ３１において、ＣＬ２は、ＭＭにＧＯＲ１によって 示されるオファーにマッチすべき要求を送る。ステップ３２において、ＭＭは、 この要求を受け取る。ステップ３３において、ＭＭは、ＣＬ２によって送信され た最新の要求における属性と、ＧＯＲ１における属性とを比較し、これらが、Ｍ Ｍが用いるようにプログラムされたいかなる基準によってもマッチしない場合に は、ＭＭはＣＬ２にメッセージを送信し、ＧＯＲ１によって示されるオファーに 少なくともこの時点では参加することができないことをＣＬ２に知らせる（ステ ップ３４）。要件および要件の組をマッチさせるためにプログラムされた基準を 用いることは、コンピュータプログラム技術において周知である。属性がマッチ すると想定すると、ステップ３５において、ＭＭは、ＣＬ１とＣＬ２との間の通 信属性を測定するための要求をＣＬ２に送信する。 図４を参照して、ステップ４１において、ＣＬ２は最後に書かれた要求をＭＭ から受信する。ステップ４２において、この要求が、通信属性を測定する要求な のか、あるいは拒否(rejection)なのかについての判定をＭＭが行う。ステップ ４３において、ＣＬ２は、ＣＬ２およびＣＬ１間のデータ通信リンクの通信属性 を測定する。通信属性を測定する方法は当該分野において周知である。全ての通 信属性が互いに直交しているわけではないが、待ち時間、帯域幅およびパケット 損失レートの特に重要なものは実質的に直交である。例えば、ＣＬ２は、データ スループットレート属性を直接測定することも可能であるし、あるいは、待ち時 間、帯域幅およびパケット損失レートを別々に測定して、その後、データ通信分 野において周知の方法でこれらの３つの属性から妥当な精度（中でも測定精度に より制限される）でデータスループットレートを計算することも可能である。も う１つの通信属性は、１キロバイトの大きさのメッセージの最良の往復時間であ る。この属性は待ち時間と、帯域幅と、２次的な影響であるコンピュータのスピ ードとの関数であるが、パケット損失レートからは全く独立している。往復時間 および往復時間の測定方法も当該分野において周知である。ステップ４４におい て、ＣＬ２は、ＣＬ２およびＣＬ１間のデータ通信リンクの属性の測定結果をＭ Ｍに報告する。ステップ４５において、ＭＭは、通信属性測定結果を報告するメ ッセージを受信する。 図５を参照して、ステップ５１において、ＭＭは、通信属性を、ＧＯＲ１に記 録されたゲームの通信属性の制限値(limiting value)（または、ＧＯＲ１には無 い通信属性についてのあらゆる制限値の所定のデフォルト値）と比較し、もし（ ステップ５２）、プログラムされた基準に照らして、通信属性が、ＧＯＲ１にお いて指定された通信属性の制限値のいずれか（または、それが無い場合には所定 のデフォルト）を上回る場合、ステップ５３において、ＭＭはＣＬ２がゲームオ ファーに参加することが許可されたことをＣＬ２に知らせ、ＣＬ２に関連する既 知の属性の全てを記録するために、さらなるゲームオファーレコード（ＧＯＲ２ ）を作成する。そうでない場合（ステップ５４）、ＧＯＲ１によって示されたオ ファーにＣＬ２が参加できないことをＣＬ２に知らせるメッセージがＭＭからＣ Ｌ２に送信される（ステップ５５）。 図６を参照して、ＭＭは次にゲームマッチ(game match)が完了しているかどう かを判定しなければならない。１つの重要な基準は、十分な数のプレーヤーがゲ ームオファーに参加しているかどうかである（ステップ６１）。本実施形態では 、自動マッチアプローチを用いており、十分な数のクライアントプログラムのイ ンスタンスが参加している場合、３０秒等の所定の時間のタイムアウトタイマを スタートさせる（ステップ６２）。この間、最大許容プレーヤー数に達していな ければ、さらにクライアントがゲームに参加することができる（ステップ６３） 。タイムアウトタイマは、コンピュータプログラミングの分野においては周知で ある。まだ十分な数のプレーヤーが参加していなければ、タイムアウトタイマを スタートさせずに、ＭＭはさらなるクライアントを待つ（ステップ６４）。 タイムアウトタイマが時間切れになるまでの間は、さらなるクライアントプロ グラムのインスタンス（ＣＬ３、ＣＬ４等）が、ＣＬ２と同じ交渉によって、こ のゲームオファーに参加することができる。この３番目以降のクライアント（Ｃ Ｌｎ）は、そのクライアントプログラムの候補インスタンスと、既に参加してい るクライアント（ＣＬ１〜ＣＬ（ｎ−１））の全てとの間の通信属性を測定およ び報告するようにＭＭによって要求されることが予想される。 図７を参照して、ステップ７１において、タイムアウトタイマが時間切れにな るとＭＭはゲームがマッチしたとみなして、ゲームマッチが首尾良く完了したこ とを知らせるメッセージをクライアント（ＣＬ１〜ＣＬｎ）のそれぞれに送信す る。そうでない場合、ＭＭはタイムアウトタイマに関して特に何もしない（ステ ップ７２）。ゲームマッチが首尾良く完了したことを知らせるメッセージを受信 すると、各プレーヤーのコンピュータは、ゲームプログラムの命令の実行を開始 し、ユーザの各コンピュータ間でピアツーピアでゲームデータメッセージを交換 する。この時点では、クライアントと（サーバである）ＭＭとの通信はもはや必 要不可欠ではなくなり、ゲームが進行する。 本発明の別の実施形態の説明 さらなる説明としての本実施形態は、本発明の概要のサブセットの一例である 。このサブセットは、早期サーバ結合によって、単一サーバに対して複数のクラ イアントを使用するゲームの場合のマッチメーキング(matchmaking)に関する。 本実施形態において使用するネットワークもやはり、周知のインターネットであ る。上記本発明の概要は、一般に本発明を完全に実施可能にするものであるとと もに、当業者にとって本実施形態を完全に実施可能にするものである。 マッチメーカサーバプログラムを用いる。このプログラムを実行しているイン スタンス（ＭＭと略す）はサーバコンピュータに常駐している。各コンピュータ ユーザ（本実施形態においてはユーザと略す）は、そのコンピュータ上でクライ アントコンピュータプログラムのインスタンスを起動する。すると、そのコンピ ュータがクライアントコンピュータとなる。 図８を参照して、ステップ１０１において、クライアントプログラム（ＣＬ１ ０）のインスタンスはＭＭに要求を送信。この要求は、ＭＭにゲームオファーを 作成することを要求するものであり、ユーザが選択した様々なゲームおよびマッ チプレファレンスの属性を含むとともに、要求されたゲームの種類の固有の属性 、およびユーザのコンピュータ上にインストールされたハードウェアおよびソフ トウェアの属性を含む。ゲームの固有の属性は、クライアントおよびゲームサー バ（ＧＳ）間のリンクの通信属性の制限値を含む。ステップ１０２において、Ｍ Ｍはこの要求を受信する。ステップ１０３において、ＭＭはゲームオファーレコ ード（ＧＯＲ１０）を作成する。ゲームオファーレコードは、要求からの属性お よびＣＬ１０の返信ユニークネットワークアドレスを含む。ステップ１０４にお いて、ＭＭは、ＧＯＲ１０に記録された属性を、ゲームサーバ（ＧＳ）が既にＭ Ｍに自発的に報告し、ＭＭがこの目的のために作成されたレコード内に保持して おいた属性（もしあれば）とマッチさせる。このゲームサーバ（ＧＳ）属性をＧ ＯＲ１０内に記録された属性に対してマッチさせた結果、プログラムされた基準 に照らして適切にＧＯＲ１０にマッチする属性のＧＳであると特定されなかった 場合（ステップ１０５）、ＧＯＲ１０が示すオファーにＣＬ１０が参加できない ことをＣＬ１０に知らせるメッセージがＭＭからＣＬ１０に送信される（ステッ プ１０６）。 図９を参照して、ステップ１１１において、上記ステップ１０４においてＭＭ が特定した適合する可能性がある全てのＧＳのユニークネットワークアドレスに よって特定されるコンピュータの候補リストのそれぞれとＣＬ１０との間の通信 属性を測定する要求を、ＭＭがＣＬ１０に送信する。 図１０を参照して、ステップ１２１において、ＭＭからの最後に書かれた要求 の１つをＣＬ１０が受信する。ステップ１２３において、ＣＬ１０は、ＣＬ１０ と候補リストに記載されたＧＳとの間のデータ通信リンクのそれぞれについての 通信属性を測定する。ステップ１２４において、ＣＬ１０は、様々な通信属性の 測定結果をＭＭに報告する。ステップ１２５において、ＭＭはこの報告を受信す る。 図１１を参照して、ステップ１３１において、ＭＭは、（ＣＬ１０と報告され たＧＳのそれぞれとの間の経路についての）通信属性を、ＧＯＲ１０内の制限値 （または、ＧＯＲ１０には無い通信属性についての所定のデフォルト値）と比較 し、もし（ステップ１３２）ＧＯＲ１０において指定されたプログラムされた基 準に照らして、通信属性が制限値、または、それが無い場合には所定のデフォル トを上回る場合、ステップ１３３において、ＣＬ１０が、ＧＯＲ１０内の基準を 満たしたサーバの１つのユニークネットワークアドレスを記録することによって 有効なゲームオファーを作成することが許可される。これを、早期サーバ結合と 呼ぶ。このようにして選ばれたサーバ（ステップ１３３）を、早期結合ゲームサ ーバ(early bound game server)（ＥＢＧＳ）と呼ぶ。基準を満たすサーバが全 く見つからない場合、ＭＭがゲームオファーを作成できないことをＣＬ１０に知 らせるメッセージがＭＭからＣＬ１０に送信され（ステップ１３５）、ＧＯＲ１ ０は破棄される（ステップ１３６）。レコードを破棄する方法は当該分野におい て周知である。 さらなるクライアントがＧＯＲ１０によって表されるゲームオファーに参加し ようとすると、これらのクライアントはＭＭによって、それ自体とＥＢＧＳとの 間のみの通信属性を測定することを要求される。これらの通信属性がＭＭに報告 されると、上記で確立されたプログラムされた基準に従って、これらの属性が制 限値を越えるか否かに関する決定がなされ、それによりクライアントはゲームオ ファーに参加することを許可され得る。 本実施形態は、自動マッチアプローチを用いない。従って、ＭＭは、各クライ アントが参加する毎に、マッチの進行をＣＬ１０に伝える。ＣＬ１０のユーザは 、十分な数のプレーヤーがマッチに参加したと満足すると、ＣＬ１０を刺激する ことにより、マッチを完了したものとして取り扱うことをＭＭに命ずるメッセー ジを送信する。（例えば）キーボードまたはコンピュータマウスなどの手段を介 した、ユーザによるプログラムの刺激は、コンピュータプログラミングの分野に おいて周知である。ＭＭはその後、マッチの完了をクライアントに伝えるメッセ ージを各クライアントに送信する。 各プレーヤーのコンピュータは、ゲームマッチの首尾よい完了を伝えるメッセ ージを受信すると、ゲームプログラム命令の実行を開始し、各ユーザのコンピュ ータとＥＢＧＳとの間のゲームデータメッセージ交換を行う。この時点で、クラ イアントとＭＭとの間の通信は、もはや必要不可欠ではなく、ゲームプレイが進 行する。 本発明のさらなる実施形態の説明 さらなる説明として、本実施形態は、本発明の概要のさらなるサブセットの一 例である。このサブセットは、晩期サーバ結合により、複数のサーバに対して複 数のクライアントを用いるゲーム用のマッチメーキングに向けられている。この 特定の実施形態が用いるネットワークもまた、周知のインターネットである。上 記の概要は、全体として、当業者が概して本発明、そして特に本実施形態を実施 することを可能にする。 マッチメーカサーバプログラムが用いられる。このプログラム（ＭＭ）の実行 インスタンスはサーバコンピュータに常駐している。各コンピュータユーザ（ユ ーザ）は、クライアントコンピュータプログラムのインスタンスを自分自身のコ ンピュータで起動し、そのコンピュータがクライアントコンピュータとなる。 クライアントプログラムのインスタンス（ＣＬ２０）は、ＭＭに要求を送信す る。要求は、ＭＭに、ゲームオファーを作成することを依頼する。要求は、要求 されたタイプのゲームに固有の属性ならびにユーザのコンピュータにインストー ルされているハードウェアおよびソフトウェアの属性と共に、様々なゲームの属 性と、ユーザによって選択されたマッチプレファランスの属性とを含む。ゲーム 固有の属性は、クライアントとゲームサーバ（ＧＳ）との間のリンクの通信属性 に対する制限値を含む。次に、ＭＭがこの要求を受け取る。ＭＭは、要求からの 属性とＣＬ２０の返信ユニークネットワークアドレスとを含むゲームオファーレ コード（ＧＯＲ２０）を作成する。その後、ＭＭは、ＧＯＲ２０内に記録された 属性を、ゲームサーバ（ＧＳ）が自発的に既にＭＭに報告しており且つＭＭがこ の目的のために作成されたレコードに保存している属性（そのような属性がある 場合には）にマッチさせる。ＧＯＲ２０内に記録された属性に対するゲームサー バ（ＧＳ）属性のマッチングにより、プログラムされた基準に従って属性がＧＯ Ｒ２０に適切にマッチするＧＳを、十分な数だけ（必要数は、ＣＬ２０によって ＭＭにパスされた属性のうちの１つである）特定できない場合、ＭＭからＣＬ２ ０に、ＭＭはＧＯＲ２０によって表されるオファーに参加できないことをＣＬ２ ０に伝えるメッセージが送信される。 次に、ＭＭは、ＣＬ２０と、ＭＭによって以前に特定された適合する可能性の ある全ＧＳのユニークネットワークアドレスによって特定されたコンピュータの 候補リストの各々との間の通信属性を測定するようにという要求を、ＣＬ２０に 送信する。 その後、ＣＬ２０は、最も最後に書かれた要求をＭＭから受け取る。ＣＬ２０ は、ＣＬ２０と候補リストに挙げられたＧＳとの間のデータ通信リンクの各々の 通信属性を測定する。ＣＬ２０は、様々な通信属性の測定結果をＭＭに報告する 。 ＭＭは、通信属性（ＣＬ２０と報告されたＧＳの各々との間の各経路に関する ）を、ＧＯＲ２０内の制限値（または、ＧＯＲ２０にない通信属性用のいくつか の所定のデフォルト値）と比較する。ＧＯＲ２０内で特定されたプログラムされ た基準（またはそれが無い場合には、所定のデフォルト）によると通信属性が制 限値を越えている場合、ＭＭはＣＬ２０用に、ＧＯＲ２０内の資格のある全サー バの全ユニークネットワークアドレスを記録することにより、有効なゲームオフ ァーを作成する。 ユニークネットワークアドレスの上記リスト内のネットワークアドレスは、必 ず、上述のショートリストのサブセットである。 本実施形態は晩期サーバ結合を用いるため、マッチに結合されるべきサーバは 、まだ選択されていない。 十分な数の資格のあるサーバが見つからない場合、ＭＭからＣＬ２０に、ＭＭ がゲームオファーを作成することができずＧＯＲ２０が破棄されることをＣＬ２ ０に伝えるメッセージが送信される。 さらなるクライアントが、ＧＯＲ２０によって表されるゲームオファーに参加 しようとすると、これらのクライアントは、ＭＭによって、それ自体と、ＧＯＲ ２０内に資格を有するものとしてリストアップされている全サーバとの間の通信 属性を測定することを要求される。 これらの通信属性がＭＭに報告されると、上記で確立されたプログラムされた 基準に従って、これらの属性が十分な数のサーバに関して制限値を越えるか否か に関する決定がなされ、それによりクライアントはゲームオファーに参加するこ とを許可され得る。クライアントがゲームオファーに参加することを許可される と、さらなるクライアントの通信属性が基準を満たせないサーバが、ＧＯＲ２０ 内の資格のあるサーバのリストから除去される。このようにして、より多くのク ライアントがゲームオファーに参加するにつれて、資格のあるサーバのリストは 、より小さくなる。 本実施形態は、自動マッチアプローチを用いない。従って、ＭＭは、各クライ アントが参加する毎に、マッチの進行をＣＬ２０に伝える。ＣＬ２０のユーザは 、十分な数のプレーヤーがマッチに参加したと満足すると、ＣＬ２０を刺激する ことにより、マッチを完了したものとして取り扱うことをＭＭに命ずるメッセー ジを送信し得る。この段階で、ＭＭは、マッチに結合されるべきＧＳを選択する 。良好なゲームプレイという結果になる可能性の最も高いサーバが、プログラム された基準および報告された全通信属性を含む他のファクタに従って選択される 。これは、晩期サーバ結合として知られている。ＭＭは、各サーバに、マッチが 完了したという通知を、選択されたサーバのアドレスのリストと共に送信する。 各プレーヤーのコンピュータは、ゲームマッチの首尾よい完了を伝えるメッセ ージを受信すると、ゲームプログラム命令の実行を開始し、各ユーザのコンピュ ータと結合された各サーバとの間のゲームデータメッセージ交換を行う。この時 点で、クライアントとＭＭとの間の通信は、もはや必要不可欠ではなく、ゲーム プレイが進行する。 本発明の数多くの実施形態および利点を上記の明細書中に記載したが、上記の 開示は、例としてのみであり、本発明の広い原理内において詳細に関する改変が 更になされ得ることが理解される。従って、本発明は、添付の請求の範囲によっ てのみ限定される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ， ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，Ｇ Ｂ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，Ｎ Ｏ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ， ＵＺ，ＶＮ，ＹＵ (72)発明者 ロスチャイルド，ジェフリー ジャッキー ル アメリカ合衆国 カリフォルニア 95030, ロス ガトス，オールド ランチ ロード 15560 (72)発明者 グリム，ステファン エム. アメリカ合衆国 カリフォルニア 94043, マウンテン ビュウ，シェルランド アベ ニュー 173 (72)発明者 ウォルフ，マイケル エイ. アメリカ合衆国 カリフォルニア 94043, マウンテン ビュウ，フリン アベニュー 324

Claims (1)

1. 【特許請求の範囲】 １．マッチメーカコンピュータプログラムによって、クライアントコンピュータ プログラムのインスタンスを実行している複数の既存コンピュータの中の少なく とも１つに、クライアントコンピュータプログラムのインスタンスを実行してい るさらなるコンピュータをマッチさせる方法であって、該既存のコンピュータ上 で実行している該インスタンスは、クライアントコンピュータプログラムの他の インスタンスとマッチする希望を該マッチメーカに予め伝えてあり、該さらなる コンピュータと該既存のコンピュータとはそれぞれ通信リンクによってリンクさ れ、該さらなるコンピュータおよび該既存のコンピュータ上で実行している該イ ンスタンスのそれぞれは１組の属性を有し、 （ａ）該さらなるコンピュータ上の該インスタンスからの、該既存コンピュー タ上の該インスタンスの１つとマッチする要求を該マッチメーカコンピュータプ ログラムが受信するステップと、 （ｂ）該要求に応答して、該さらなるコンピュータ上の該インスタンスに命令 を送信するステップと、 （ｃ）該命令に応答して、該さらなるコンピュータ上の該インスタンスが、該 さらなるコンピュータ上の該インスタンスと該既存コンピュータ上の該インスタ ンスのそれぞれとの間における１組の通信属性を測定するステップであって、該 測定ステップは、該さらなるコンピュータから該既存コンピュータに信号を送信 するステップを含み、該１組の通信属性は、待ち時間、パケット損失レートおよ び帯域幅からなる群より選択される少なくとも１つのパラメータに関する、ステ ップと、 （ｄ）該１組の通信属性の少なくとも１つが最低性能要件を上回る場合に、該 １組の属性および１組の通信属性に基づいて、該さらなるコンピュータ上の該イ ンスタンスに対するマッチとして該既存コンピュータの該インスタンスの少なく とも１つを選択するステップと、 （ｅ）該１組の通信属性のいずれもが該最低性能要件を満たさない場合に、さ らなる要求を待つステップと、 を包含する、方法。 ２．前記通信リンクはインターネットプロトコルを用いるネットワークを含む、 請求項１に記載の方法。 ３．前記既存コンピュータ上の前記インスタンスのそれぞれはユニークネットワ ークアドレスを有し、前記マッチメーカは、該既存コンピュータ上の各インスタ ンスについて前記１組の属性および該ユニークネットワークアドレスを含むレコ ードを作成する、請求項２に記載の方法。 ４．前記さらなるコンピュータの前記インスタンスはユニークネットワークアド レスを有し、前記待ちステップは、該さらなるコンピュータの該インスタンスの 前記１組の属性および該ネットワークアドレスを前記レコードに加えるステップ を包含する、請求項３に記載の方法。 ５．前記最低性能要件は所定のデフォルトである、請求項１に記載の方法。 ６．マッチメーカによって、サーバコンピュータおよびクライアントコンピュー タをマッチさせる方法であって、該マッチメーカ、該サーバおよび該クライアン トコンピュータは１つのデータ通信ネットワークに接続され、該サーバコンピュ ータのそれぞれは１組の属性に関連付けられたサーバプログラムのインスタンス を実行しており、該クライアントコンピュータのそれぞれは１組の属性に関連付 けられたクライアントプログラムのインスタンスを実行しており、 （ａ）複数の該クライアントプログラムのインスタンスから複数のクライアン ト要求を該マッチメーカが受信するステップであって、該クライアント要求のそ れぞれは、対応する該クライアントプログラムのインスタンスに関連付けられた 該１組の属性を含む、ステップと、 （ｂ）複数の該サーバプログラムのインスタンスから複数のサーバ要求を該マ ッチメーカが受信するステップであって、該サーバ要求のそれぞれは、対応する 該サーバプログラムのインスタンスに関連付けられた該１組の属性を含む、ステ ップと、 （ｃ）該クライアント要求および該サーバ要求に含まれる複数組の該属性に基 づいて、該複数の該クライアントプログラムのインスタンスの中の少なくとも２ つと、該複数の該サーバプログラムのインスタンスの中の少なくとも１つとを選 択するステップと、 （ｄ）該選択された該クライアントプログラムおよび該サーバプログラムのイ ンスタンスを実行している該クライアントコンピュータおよび該サーバコンピュ ータを接続するステップと、 を包含する、方法。 ７．第１の組のコンピュータオブジェクトを作成する方法であって、該第１の組 のコンピュータオブジェクトは、複数のクライアントコンピュータプログラムの インスタンスと、第１の組のサーバコンピュータプログラムのインスタンスから 選択される少なくとも１つのサーバコンピュータプログラムのインスタンスとを 含み、該第１の組のサーバコンピュータプログラムのインスタンスのそれぞれお よび該複数のクライアントコンピュータプログラムのインスタンスのそれぞれは あるユニークネットワークアドレスに関連付けられており、該第１の組のサーバ コンピュータプログラムのインスタンスのそれぞれおよび該複数のクライアント コンピュータプログラムのインスタンスのそれぞれはさらに１組の属性に関連付 けられており、 （ａ）第１の組のレコードを構築するステップであって、該第１の組のレコー ドのそれぞれのレコードは、該第１の組のサーバコンピュータプログラムのイン スタンスの１つに関連付けられた１つのネットワークアドレスおよび１組の属性 を含む、ステップと、 （ｂ）該第１の組のコンピュータオブジェクトに参加する第１の要求を第１の クライアントコンピュータプログラムのインスタンスから受信するステップであ って、該第１の要求はあるユニークネットワークアドレスおよび１組の属性を含 み、該第１の要求の該ユニークネットワークアドレスは該第１の該クライアント コンピュータプログラムのインスタンスに関連付けられており、該第１の要求の 該１組の属性もまた該第１の該クライアントコンピュータプログラムのインスタ ンスに関連付けられている、ステップと、 （ｃ）該第１の要求の該１組の属性を参照して該第１の組のレコードのそれぞ れを評価することにより、該第１の要求に応答して、該第１の組のレコードの第 １のサブセット(subset)を選択するステップと、 （ｄ）該第１の該クライアントコンピュータプログラムのインスタンスからな る該第１の組のコンピュータオブジェクトを作成するステップと、 （ｅ）少なくとも１つの該クライアントコンピュータプログラムのさらなるイ ンスタンスを用いて、該第１の組のコンピュータオブジェクトを増大するステッ プであって、 （ｉ）該少なくとも１つの該クライアントコンピュータプログラムのさらな るインスタンスから、該第１の組のコンピュータオブジェクトに参加するさらな る要求を受信するステップであって、該さらなる要求はあるユニークネットワー クアドレスおよび１組の属性を含み、該さらなる要求の該ユニークネットワーク アドレスは該クライアントコンピュータプログラムの該さらなるインスタンスに 関連付けられており、該さらなる要求の該１組の属性もまた該クライアントコン ピュータプログラムのさらなるインスタンスに関連付けられているステップ、 （ｉｉ）該さらなる要求の該１組の属性を参照して該第１の組のレコードの 該第１のサブセットのそれぞれを評価することにより、該さらなる要求に応答し て、該第１の組のレコードの該第１のサブセットから該第１の組のレコードのさ らなるサブセットを排除するステップ、および （ｉｉｉ）該クライアントコンピュータプログラムのさらなるインスタンス を該第１の組のコンピュータオブジェクトに加えるステップ、 を包含するステップと、 （ｆ）該第１の組のレコードの該第１のサブセット内にネットワークアドレス がある、該第１の組のサーバコンピュータプログラムのインスタンスを選択する ことによって、第２の組のサーバコンピュータプログラムのインスタンスを構築 するステップと、 （ｇ）該第１の組のコンピュータオブジェクトのそれぞれの該属性を参照して 該第２の組のサーバコンピュータプログラムのインスタンスのそれぞれを評価す ることによって、該第２の組のサーバコンピュータプログラムのインスタンスの 少なくとも１つを該第１の組のコンピュータオブジェクトに加えるステップと、 を包含する方法。 ８．前記第１の前記クライアントコンピュータプログラムのインスタンスおよび 前記さらなるクライアントコンピュータプログラムのインスタンスの１つに関連 付けられた前記１組の属性は、該第１の該クライアントコンピュータプログラム のインスタンスおよび該さらなるクライアントコンピュータプログラムのインス タンスの該１つを実行するコンピュータシステムの能力に関連する属性を含む、 請求項１に記載の方法。 ９．前記第１の前記クライアントコンピュータプログラムのインスタンスおよび 前記さらなるクライアントコンピュータプログラムのインスタンスの１つに関連 付けられた前記１組の属性は、該第１の該クライアントコンピュータプログラム のインスタンスおよび該さらなるクライアントコンピュータプログラムのインス タンスの該１つを使用する少なくとも１つのユーザの特性に関連する属性を含む 、請求項１に記載の方法。 １０．前記第１の前記クライアントコンピュータプログラムのインスタンスおよ び前記さらなるクライアントコンピュータプログラムのインスタンスの１つに関 連付けられた前記１組の属性は、該第１の該クライアントコンピュータプログラ ムのインスタンスおよび該さらなるクライアントコンピュータプログラムのイン スタンスの該１つを実行するコンピュータシステムに関連付けられたネットワー クリンクの通信属性を含む、請求項１に記載の方法。 １１．前記通信属性の１つは、前記ネットワークリンクの帯域幅である、請求項 ４に記載の方法。 １２．前記通信属性の１つは、前記ネットワークリンクの待ち時間である、請求 項４に記載の方法。 １３．前記通信属性の１つは、前記ネットワークリンクのパケット損失レートで ある、請求項４に記載の方法。 １４．前記第１の組のサーバコンピュータプログラムのインスタンスの１つに関 連付けられた前記１組の属性は、該１つのインスタンスを実行するコンピュータ システムの能力に関連する属性を含む、請求項１に記載の方法。 １５．前記第１の組のサーバコンピュータプログラムのインスタンスの１つに関 連付けられた前記１組の属性は、該１つを実行するコンピュータシステムの現在 の負荷に関連する属性を含む、請求項１に記載の方法。 １６．前記第１の組のコンピュータオブジェクトから、該第１の組のコンピュー タオブジェクトに属するサーバコンピュータプログラムのインスタンスとクライ アントコンピュータプログラムのインスタンスとの間の平均待ち時間を最小化す るサーバコンピュータプログラムのインスタンスを見つけるステップをさらに包 含する、請求項１に記載の方法。 １７．前記増大ステップは、所定の数までの前記クライアントコンピュータプロ グラムのインスタンスを前記第１の組のコンピュータオブジェクトに加える、請 求項１に記載の方法。 １８．前記増大ステップは、所定の時間間隔の間、前記クライアントコンピュー タプログラムのインスタンスを前記第１の組のコンピュータオブジェクトに加え る、請求項１に記載の方法。 １９．前記第１のクライアントコンピュータプログラムのインスタンスおよび前 記さらなるクライアントコンピュータプログラムのインスタンスに関連付けられ た前記１組の属性の１つは、１組のマルチプレーヤゲーム属性である、請求項１ に記載の方法。 ２０．前記１組のゲーム属性を構築するモデレータ(moderator)を提供するステ ップをさらに包含する、請求項１３に記載の方法。