JP2001087560A - ビデオ・ゲームのネットワーク処理システムおよび方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 複数のゲーム・ユニットが同じゲームに参加
するためのネットワーク管理システムまたは方法を提
供。 【解決手段】 電子ゲーム・ユニットのネットワーク処
理システムは、複数の位置の各々において１つ以上のゲ
ーム・ユニットと結合してあり、更に通信リソースに結
合してあり、１つ以上のゲーム・ユニットとの双方向情
報交換を支援するアーケード・ルータを含む。第１ルー
タは、通信資源の第１グループと結合してあり、ゲーム
・ユニットの対応する第１グループとの双方向情報交換
を支援する。第１サーバは、第１ルータと結合してあ
り、双方向データ交換を制御し、異なる位置における複
数のゲーム・ユニットによる対話型プレーを支援する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】数個のビデオ・ゲームを一緒
にネットワーク処理し、対話型プレー用マルチ・システ
ム・ゲームを形成する方法およびシステムについて記載
する。本発明は、ここでは「状態同期方法」（State Sy
nc. Method）と呼ぶ同期方法を含む。また、本発明は、
このようなネットワークのための帯域幅管理方法および
システムも含む。

【０００２】

【従来の技術】本願は、１９９８年９月２４日に出願し
た係属中の仮特許出願第６０／１０１，９２３号（弁理
士整理番号第ＷＭＳＭ０１４ＰＺ１号）の利益を主張す
る。 用語の定義 以下の用語は、ここで用いる場合、次の意味を有するも
のとする。

【０００３】ゲーム・ユニットまたはビデオ・ゲーム・
ユニット−娯楽目的のために用いるソフトウエアを実行
する計算機器のあらゆる単体（piece）であり、ビデオ
・ゲーム機器またはビデオ・ゲーム・ソフトウエアを走
らせる汎用コンピュータを含むが、これらには限定しな
い。

【０００４】ゲーム−ビデオ・ゲーム上でのプレーの体
験。ゲームは、単一の単体ゲーム・ユニットまたは２台
以上のゲーム・ユニット上でプレー可能である。マルチ・システム・ゲーム −２台以上のビデオ・ゲーム
・ユニット上でプレーするゲーム。

【０００５】状態同期方法−多数のゲーム・ユニットに
おけるプレーヤをマルチ・プレーヤ・マルチ・システム
・ゲームに参加させる手段。この方法については、以下
で更に詳しく定義する。

【０００６】ゲーム状態または状態−ゲーム状態とは、
ゲームの結果を制御するパラメータの所与の時点におけ
る値のことを言う。ゲーム状態パラメータの例には、画
面上にある物体および画面上にない物体の位置、キャラ
クタの強さ、キャラクタの健康、および富がある。

【０００７】状態値−所与の状態ｓｔａｔｅ＿ｎについ
て、ｓｔａｔｅ＿ｎの値は、ゲームの結果に影響を与え
る全てのゲーム・パラメータを定義する。状態遷移 −状態遷移は周期的に発生する。新たなゲーム
状態は、現ゲーム状態および現入力の関数となる。

【０００８】状態同期−ゲーム・プレーの間、ゲーム状
態は周期的に変化しつつある。状態変化は、典型的に、
毎秒３０ないし６０回発生する。多数のゲーム・ユニッ
トにおいて、各ゲーム・ユニット上で発生するゲーム状
態シーケンスが同一である場合、それらの状態が同期し
ていると言う。状態遷移は同時に発生する必要はない。
また、全てのゲーム・ユニットが所与の状態に同じ時間
量だけ留まる必要もない。

【０００９】グループ−グループという用語は、ネット
ワークに共に接続し、状態同期を維持する必要がある、
ゲーム・ユニットの部分集合を意味するために用いる。
グループ内のゲーム・ユニットは、マルチ・システム・
ゲームに参加していると言う。

【００１０】システム−コンピュータ機器のあらゆる単
体。この用語は、ここでは、場合によってはゲーム・ユ
ニットと同義で用いる。入力 −この用語は、状態遷移に影響を及ぼし得る、また
はゲームの結果に影響を及ぼし得る、ゲームまたはグル
ープ外部の影響によって生ずるあらゆるイベントのこと
を言う。これは、ボタンの押下、あるいはジョイスティ
ックの移動またはその他の入力デバイスの作動（actuat
ion）を含み、これらには限定されない。

【００１１】

【発明が解決しようとする課題】いずれかのデータ通信
ネットワークまたはいずれかの直接電気接続によって接
続してある２台以上の物理的に独立したゲーム・ユニッ
トは、異なる地理的位置にいるプレーヤが同じゲームに
参加する場合、何らかの種類のネットワーク管理システ
ムまたは方法を必要とする。本発明は、このようなシス
テムまたは方法を提供する。

【００１２】一般に、ビデオ・ゲーム・プログラムは、
一連の状態遷移を基本とする。典型的に、これらの遷移
は、通常、当該ゲーム・システムに対するビデオ・フレ
ーム・レートに関係する周期的間隔で行われる。状態遷
移の一部または全ては入力値によって左右される。マル
チ・システム・ゲームのためにネットワークを通じて結
合してある多数のゲーム・ユニットは、何らかの状態同
期方法を必要とする。本発明はこのような方法を提供す
る。

【００１３】

【課題を解決するための手段】本発明の一態様によれ
ば、異なる位置にいる２人以上のプレーヤにリアル・タ
イム対話型ゲームで交戦（engage）させる、ビデオ・ゲ
ームのネットワーク処理方法およびシステムを提供す
る。

【００１４】本発明の別の態様によれば、ネットワーク
によってリンクしてある異なる位置にある２台以上のゲ
ーム・ユニットを同期させ、各ゲーム・ユニット上にお
いて同じゲーム状態のシーケンスが発生するようにする
同期方法を提供する。

【００１５】本発明の更に別の態様によれば、使用可能
なネットワーク帯域幅を監視し、対戦を調整し、所定の
プレーヤ基準に基づいて、プレーヤのネットワーク・レ
ベルの階層へのアクセスを制御する帯域幅管理システム
および方法を提供する。

【００１６】本発明の状態同期方法は、各ゲーム・ユニ
ットが、ネットワークに接続したビデオ・ゲーム・ユニ
ットのグループ内における他のあらゆるゲーム・ユニッ
トとの状態同期を維持することを保証する。これは、グ
ループ内の各ゲーム・ユニットが、当該グループ内の他
のあらゆるゲーム・ユニットが動作するのと同じ入力ス
トリーム上で動作することを保証することによって達成
する。本発明の帯域管理方法およびシステムは、ネット
ワーク容量およびユーザの見込み（user expectation
s）と一致するように、使用可能なネットワーク帯域へ
のユーザ・アクセスを規制する方式を実施する。

【００１７】本発明の別の態様によれば、電子ゲーム・
ユニットのネットワーク処理システムは、複数の位置の
各々において１つ以上のゲーム・ユニットと結合してあ
り、更に対応する通信リソースに結合してあり、前記１
つ以上のゲーム・ユニットとの双方向情報交換を支援す
るアーケード・ルータと、前記通信資源の第１グループ
と結合してあり、前記複数の位置における前記１つ以上
のゲーム・ユニットとの双方向情報交換を支援する第１
ルータと、前記第１ルータと結合してあり、前記双方向
データ交換を制御し、前記複数の場所の内異なる場所に
おける複数のゲーム・ユニットによる対話型プレーを支
援する第１サーバとを備える。

【００１８】本発明の別の態様によれば、対話型プレー
のために互いにリンクしてある複数のゲーム・ユニット
間の情報交換を同期させ、前記ゲーム・ユニットの各々
が、実質的に同じ着信情報シーケンス上で動作するよう
にする状態同期システムを提供する。

【００１９】本発明の更に別の態様によれば、対話型プ
レーのためにネットワークにリンク可能な複数のゲーム
・ユニットのための帯域幅マネージャを提供する。この
帯域幅マネージャは、ネットワークの各通信リソース上
で使用可能な帯域幅を判定する手段と、ネットワークへ
のアクセスを要求する各ゲーム・ユニットに関連するプ
レーヤの習熟度を判定する手段と、ネットワークへのア
クセスを要求する全てのプレーヤの平均技能レベルを判
定する手段と、平均技能レベルおよび使用可能な帯域幅
に基づいて推奨スレシホルドを確定する手段と、プレー
ヤの技能レベルが推奨スレシホルドを超過する場合、ネ
ットワークへのアクセスをプレーヤに付与する手段とを
含む。

【００２０】本発明の更に別の態様によれば、対話型プ
レーのために互いにリンクしてある複数のゲーム・ユニ
ット間の情報交換を同期させ、前記ゲーム・ユニットの
各々に、実質的に同じ着信情報シーケンス上で動作させ
る状態同期方法を提供する。この状態同期方法は、マル
チ・システム・ゲームに参加するゲーム・ユニットの数
を判定する手段と、第１状態において、前記ゲーム・ユ
ニットの各々の入力データを判定する手段と、前記第１
状態における前記マルチ・システム・ゲーム内の他の各
ゲーム・ユニットからの入力データを前記マルチ・シス
テム・ゲーム内の他の各ゲームに送信し終えるまで、前
記ゲーム・ユニットの各々が次の状態に遷移するのを防
止し、前記マルチ・システム・ゲーム内のゲーム・ユニ
ット全てが、次の状態に遷移する前に、各状態において
前記入力データの同一集合上で動作するようにする手段
とを含む。

【００２１】

【発明の実施の形態】１．システムの概要 図１ないし図３を参照すると、まず図１において、本発
明によるビデオ・ゲーム・ネットワークの一例を示す。
図１に示す形式のネットワークの一例のことを、以下で
はウエーブネット（ＷａｖｅＮｅｔ）と呼ぶことにす
る。図２および図３は、異なる位置にあるビデオ・ゲー
ム・ユニットをリンクする２種類の「従来技術の」シス
テムを示す。

【００２２】図１を参照すると、本発明では、異なる位
置にある２台以上のゲーム・ユニット１６をリンクし、
リアル・タイムの対話型ゲームを行うことができる。こ
れらのゲーム・ユニットは、複数のアーケード１０のグ
ループの各々からの１つ以上のゲーム・ユニットを含む
ことも可能である。ここでは、アーケードを、アーケー
ド１，１ないしアーケード１，ｎおよびアーケードｎ，
１ないしアーケードｎ，ｎで示す。アーケード・グルー
プ１のアーケードは、それぞれＴ−１本のラインを通じ
て、第１の即ちメトロ・ハブ１２にリンクしてある。こ
こでは、メトロ・ハブ１２をサンフランシスコ（ＳＦ）
ハブとして示す。同様に、グループｎのアーケード１０
は、Ｔ−１本のラインを通じて、ここではロスアンゼル
ス（ＬＡ）ハブとして示す、他の第１の即ちメトロ・ハ
ブにリンクしてある。各アーケードは、複数のゲーム・
ユニット１６を含み、これらはアーケード・ルータ
（Ｒ）１８と動作的に結合してある。本発明から逸脱す
ることなく、追加のメトロ・ハブに結合した追加のアー
ケード・グループを追加することも可能である。

【００２３】多数のメトロ・ハブ１２，１４等は、Ｔ−
１本の通信回線を通じて、地域センタ２０に結合するこ
とができる。同様に、１箇所以上のこのような地域セン
タ２０は、Ｔ−１本のラインを通じて、広域センタ（su
per-regional center）２２に結合することができ、更
に１箇所以上の広域センタ２２は、Ｔ−１本のラインを
通じて全国センタ（national center）２４に結合する
ことができる。本発明から逸脱することなく、好ましく
はＴ−１本またはそれよりも高い容量の光ファイバある
いはその他の広帯域資源のような、Ｔ−１本のライン以
外の通信資源も使用可能である。

【００２４】各メトロ・ハブ１２およびセンタ２０，２
２，２４の各々は、ルータ（Ｒ）３０およびサーバ
（Ｓ）３２を含むという点で類似する。サーバ３２は、
この後に更に詳しく説明するように、帯域幅管理を実行
する。一般的に言うと、メトロ・ハブ１２，１４におけ
るサーバ３２の各々は、メトロ・ハブ１２，１４と当該
ハブにＴ−１本のラインを通じてリンクしてある種々の
アーケード１０との間のこれらＴ−１本のライン上にお
けるの帯域幅使用状況を監視する。このことを、ここで
は下流帯域幅管理と呼ぶことにする。上流帯域幅管理で
は、サーバ３２は、図１に示すように、関連するルータ
と次に高いレベルとの間のＴ−１本のライン上における
帯域幅使用状況を監視し、各Ｔ−１本のラインに対する
アクセスを制御する。これは、上流帯域幅管理として知
られている。

【００２５】図１に示すルータおよびサーバの配列は、
いずれのアーケードにおける個々のゲーム・ユニット１
６のプレーヤも、同じアーケード内であれ異なるアーケ
ード内であれ、他の位置にいる他のゲーム・ユニットの
他のゲーム・プレーヤとリアル・タイムの対話型プレー
で対戦することが可能であるという利点がある。これら
のプレーヤは、同じメトロ・ハブが担当する異なるアー
ケード内にいてもよく、または仲介するセンタやハブを
介して、最終的には領域、超領域または全国センタによ
ってリンクされている位置にいてもよい。本発明の帯域
管理および状態同期という特徴（aspect）は、リアル・
タイムの対話型ゲームを可能とし、個々のプレーヤは実
質的に同時プレーとして知覚するという利点がある。こ
うするには、数人のプレーヤが、各プレーヤの位置には
無関係に、本質的に、他のプレーヤと同じ位置またはア
ーケード内で直接互いに隣接して位置しているかのよう
に知覚させるようにする。

【００２６】ここではアーケード内のビデオ・ゲーム・
ユニットを参照しながら本発明を説明するが、本発明
は、他の形式のゲーム・ユニットにも同様に適用可能で
あることは理解されよう。例えば、本発明のネットワー
クを利用して、家庭用ビデオ・ゲーム、通常のＴＶ受像
機にリンクするゲーム・コントローラを通じた単体ユニ
ット上でプレーするものや、パーソナル・コンピュータ
（ＰＣ）上でプレーするゲームであっても、リンクする
ことが可能である。これらのゲーム・ユニットは、ネッ
トワーク対応処理を行う適切なハードウエアおよびソフ
トウエアを備えていれば、そのいずれもが、図１を参照
して先に説明したネットワークにリンクすることができ
る。

【００２７】手短かに図２を参照し、プレーヤが互いに
対話的に競わない、最高得点更新システム (high score
to date system)と呼ぶ従来技術のトーナメント・シス
テムの一種を示す。この種のシステムの１つが、Thache
r et al.（サッチャーその他）の米国特許第５，０８
３，２７１号に示されている。ここでは、トーナメント
で対戦する全てのプレーヤが彼らのゲームを個々にプレ
ーし、終了時に、彼らの得点を中央サーバに送信する。
したがって、このシステムでは、個々のゲーム・ユニッ
ト各々は、モデム２６を介して、中央サーバ２９の協働
するモデム２８にリンクしてある。そして、この中央サ
ーバ２９が多数のゲーム・ユニット１６から一度に１つ
ずつ個々の得点を受信する。ゲーム・ユニット１６は、
そのモデム２８を用い、何らかの予め選択してある順序
で、例えば、サーバ２９による種々のゲーム・ユニット
・モデム２６のポーリングによって、順次相互接続す
る。サーバ２９が所与のゲーム・ユニット１６をポール
している間、サーバとそのゲーム・ユニットとの間で情
報交換が行われ、それまでトーナメントに参加しゲーム
を競っていた他のプレーヤのプレーヤ得点を示し、個々
のプレーヤは彼の得点を、それまでに終了しているゲー
ムの他の得点と比較できるようにしている。したがっ
て、このようなシステムには通常「最高得点更新」とい
う名称を与えている。

【００２８】図３は、更に別の従来技術のシステムを示
し、ここでは、サーバ３９が、各々モデム２６を有する
２台のゲーム・ユニット１６のみの間での対話型ゲーム
のために、相互接続を簡便化する。サーバ３９は、個々
のゲーム・ユニットのモデム２６と通信するモデム（図
示せず）も含むことができる。そのプロセスは、図３に
おいて矢印１，２および３で示すように、３ステップ・
プロセスである。第１ステップにおいて、２台のゲーム
・ユニット１６からの２つのモデム２６が同時にまたは
順次サーバにアドレスし、彼らがリンク・プレー（link
ed play）を行うことの可能性を示す。第２ステップで
は、サーバが、このような要求を行った第１プレーヤ
に、第２プレーヤとプレー可能であること(availabilit
y)を示し、第２プレーヤの電話番号またはｅメール・ア
ドレスを送信する。第２プレーヤとの交戦に興味がある
場合、第１プレーヤは、ステップ３に示すように、彼の
電話機またはｅメール・アドレスを用いることによって
第２プレーヤと接触し、２人のプレーヤ間で直接プレー
を開始する。サーバ３９は、２人のプレーヤ間の実際の
プレーの間は関与せず、最初に相手のプレーヤを探し出
す作業を簡便化するに過ぎない。

【００２９】図２および図３に示すシステムには多くの
欠点(limitation)がある。例えば、図３のシステムは、
対話型プレーのために３人以上のプレーヤをリンクする
場合には使用できず、図２のシステムの場合のように、
トーナメント・プレーを簡便化するためには利用できな
い。一方、図２の最高得点更新トーナメント・システム
は、種々のプレーヤ間のリアル・タイムの対話型プレー
に対応することはできず、単に得点を比較し、得られた
得点情報を個々のプレーヤに伝達するだけに過ぎない。 ＩＩ． 状態同期 本発明の状態同期方法を用いる場合、グループの各シス
テムは、ゲーム・ユニットが初期状態からゲーム終了時
の最終状態まで進む際に、各ゲーム状態の値が一致して
いなければならない。最初の状態を、マルチ・システム
・ゲームが開始するときのゲーム・ユニットが置かれて
いる状態とし、ｓｔａｔｅ＿１で示すことにする。ゲー
ム・ユニットは、ｓｔａｔｅ＿１の間種々の入力（例え
ば、ユーザのボタン押下およびジョイスティックの移
動）に作用し、新たな状態ｓｔａｔｅ＿２に進む。任意
状態の値をｓｔａｔｅ＿ｎと呼ぶことにする。ここで、
ｎは、ゲームを構成する一連の状態において当該状態が
発生したときを示す。ｓｔａｔｅ＿ｎの値は、直前の状
態の（ｓｔａｔｅ＿ｎ−１）の値、およびｓｔａｔｅ＿
ｎ以前にサンプルされた入力の値の関数である。

【００３０】本発明は、あらゆる所与の状態において
も、グループ内の各システムが、当該所与の状態におい
て、グループ内の他の各システムが動作する同じ入力集
合に対して、当該システムが動作している場合にのみ、
ある状態遷移を発生させることを保証する方法を含む。

【００３１】これを行うために、グループ内の各ゲーム
・ユニットは、必要な入力データ全てをグループ内の全
ゲーム・ユニットに送信し、各ゲームにおける状態遷移
が同じ入力データに基づくことを確保しなければならな
い。

【００３２】例えば、システム１が以下の入力、Ｉ
（１，１）、Ｉ（１，２）、Ｉ（１，３）、Ｉ（１，
４）、Ｉ（１，５）をサンプルすると仮定する。Ｉ
（ｎ，ｍ）は、ｎ番目のシステムが得た入力のｍ番目の
サンプルであり、システム２はＩ（２，１）、Ｉ（２，
２）、Ｉ（２，３）、Ｉ（２，４）、およびＩ（２，
５）をサンプルする。本発明の特徴の１つは、ｘ個のシ
ステムから成るグループにおけるいずれかのシステムが
入力Ｉ（１，１）上で動作する場合、グループ内の全シ
ステムの入力Ｉ（２，１），ｉ（３，１），．．．Ｉ
（ｘ，１）上でも動作すること、およびグループの各シ
ステムが、ｓｔａｔｅ＿ｎにある間、全入力Ｉ（１，
ｎ）、Ｉ（２，ｎ），．．．Ｉ（ｘ，ｎ）上で動作する
ことを保証する方法に関係する。

【００３３】本発明のこの特徴によれば、あるゲーム・
ユニットが所与の状態に必要な全入力を受信していない
場合、そのゲーム・ユニットは、グループ内の各ゲーム
・ユニットから必要なデータ全てを受信するまで、状態
遷移を行うことを延期させなければならない。

【００３４】本発明の特徴の１つを、その動作について
以下の例との関連で説明する。この例では、４つの物理
的ゲーム・ユニットで参加する４人のプレーヤ・グルー
プ（即ち、４人のプレーヤがゲームを行う）について記
載する。本発明は、（４台よりも）多いゲーム・ユニッ
トでも少ないゲーム・ユニットでも適用可能であり、以
下に示すのは１組の例に過ぎない。

【００３５】例１は、４台のコンピュータ・システムに
４組の入力を保持するバッファを示す。このバッファ
は、４台のゲーム・ユニットの各々で用いる。この例に
おけるゲーム・ユニット１のバッファを見ることにす
る。

【００３６】

【表１】

【００３７】「第１入力」と示す列は、ユーザ入力をサ
ンプルする第１時間間隔中に検出した全入力を示す。こ
の場合、「入力」とはプッシュボタン、ジョイスティッ
ク等のようなゲーム・ユニット・エレメントのプレーヤ
によるいずれかの活性化、またはあるプレーヤが行った
または開始した何らかのアクションに応答して、ゲーム
・ユニットが発生したその他の信号を意味する。「第Ｎ
入力」は、ユーザの入力をサンプルしている第Ｎ時間間
隔中に検出した全入力を表わす。ローカル・システム
（即ち、ゲーム・ユニット１）において入力をサンプル
しつつ、これらをバッファ内に格納し、更にグループ内
の他の各システム（ゲーム・ユニット）にも送信する。
ゲーム・ユニットの状態遷移機能性には、各システムか
らの入力が必要であり、グループ内の各システムから１
組の入力が得られるまで、当該入力には作用しない。

【００３８】以下の例は、４つの別個のシステム（ゲー
ム・ユニット）を状態同期させておくバッファリング技
法の使用法を示す。システム１は、その第１ユーザ入力
を得て、例２に示すように、バッファ・セル（システム
１，第１入力）、即ち、Ｉ（１，１）にそれらを格納す
る。また、これらの入力をグループ内の各システムに送
信する。

【００３９】

【表２】

【００４０】システム１がその第２ユーザ入力集合を得
た場合、それらをセル（システム１，第２入力）に格納
する。また、例３に示すように、これらの新たな入力を
グループ内の各システムに転送する。

【００４１】

【表３】

【００４２】システム１がグループ内の他のシステムか
らユーザ入力を受信し始めると、バッファの適切なセル
にそれらを格納する。例えば、システム１がシステム３
の第１入力を受信した場合、バッファは例４で表わすよ
うになる。

【００４３】

【表４】

【００４４】システム１がその第３入力集合をサンプル
し終え、続いてシステム２からその第１入力集合、およ
びシステム３から第２入力集合を受信したとき、バッフ
ァは例５で表わすようになる。

【００４５】

【表５】

【００４６】この時点まで、バッファ自体の状態を除い
て、プログラムのいずれの部分の状態にも影響を与える
ような動作を、入力には全く行っていない。一旦最後の
ユーザ入力集合が到達すると、プログラムは全ての入力
Ｉ（ｘ，１）上で動作することが可能になる。バッファ
は、一時的に例６に示すようになる。

【００４７】

【表６】

【００４８】ここでシステム１は、第１入力集合（第１
入力）全体に作用することができる。次に、バッファか
らこれらの入力を破棄し、次に動作する対象は第２入力
集合となる。同様に、グループ内の他の各システム（ゲ
ーム・ユニット）は、一旦グループ内の全システムから
第１入力全てを受信したなら、第１入力集合に作用す
る。

【００４９】システム１が第１入力上で動作した後、バ
ッファは例７に示すようになる。

【００５０】

【表７】

【００５１】システム１は、全システムから第２入力デ
ータ全てを受信するまで、ユーザ入力上での動作を続け
ない。この方法の使用により、各システムにおいて発生
する各状態遷移が、同じ入力集合を用いて旧状態から新
状態に遷移することを保証する。これは、遷移後の新状
態の値が、各機械上で同一となることを保証する。

【００５２】各システムが同時に入力データ上で動作す
る必要はなく、各システムは同じ入力データ・シーケン
ス上で動作しさえすればよいことを注記しておく。これ
までのことを要約すると、いずれかのゲーム・ソフトウ
エアの初期状態をｓｔａｔｅ＿１と呼び、ｓｔａｔｅ＿
１はゲーム・ユニットがいずれかのユーザ入力上で動作
する直前のゲーム・ユニットの状態とする。更に、入力
ｉ（ｘ，１）上で動作した後のゲーム・ユニットの状態
をｓｔａｔｅ＿２と呼ぶと、全てを同期状態に止めるた
めに行わなければならないことは次の通りである。

【００５３】１．ｓｔａｔｅ ｎにおいて、グループ内
の全ゲーム・ユニットは、全ゲーム・ユニットから入力
Ｉ（ｘ，ｎ）、即ち、ｘの全ての値を受信しなければな
らない。

【００５４】２．各ゲーム・ユニットは、ｓｔａｔｅ＿
ｎ＋１に進む前に、全入力集合Ｉ（ｘ，ｎ）上で動作し
なければならない。端的に言えば、前述の状態同期方法
は、動作中、前述のように定義したマルチ・プレーヤ・
ゲームまたはマルチ・システム・ゲームにおいて、シス
テムによってリンクした各プレーヤが、ゲームの各状態
において、各プレーヤ自身およびその他の各プレーヤが
取ったあらゆるアクション（場合によっては取らなかっ
たアクション）について把握していることを目的とす
る。実施形態の一例では、ゲーム状態は６０ヘルツ・レ
ートで遷移する。即ち、毎秒６０回であり、これはこの
ようなシステムにリンクするビデオ・ゲーム・ユニット
の典型的なフレーム・レートでもある。したがって、例
えば、１人以上のプレーヤが「動作が遅く」、ある数の
状態にわたって何のアクションも取らない場合、このア
クションがないことが「入力」を構成し、特定のマルチ
・システム・ゲームにおいてシステムがリンクする他の
全ゲーム・ユニット全てにこの入力を配信する。一方、
１人のプレーヤの入力（即ち、アクティビティ（activi
ties）またはアクション（action））が、ネットワーク
の種々の部分を接続する伝送線上等におけるネットワー
クにおける何らかの遅延のために遅れた場合、所与の状
態に対応する１人以上のプレーヤからの入力がないと、
入力全てを受信するまで、他のゲームも次の状態への遷
移が遅れることになる。

【００５５】これは、例えば、コントローラがプレーヤ
の入力全てを監視し、次の状態を決定する単一または単
体のゲーム・ユニットとは対照的である。ここでは、マ
ルチ・システム・ゲームにおけるプレーヤ全員からの入
力を受信し終えるまで、次の状態を完全に決定すること
はできない。図示の実施形態では、状態同期方法を実行
するソフトウエアは個々のゲーム・ユニット各々のＣＰ
Ｕまたはその他の中央制御ユニット内に位置する。即
ち、本発明のネットワークによってリンクする各ゲーム
・ユニットには、ルータ１８を介してネットワークにリ
ンクするため、および前述の状態同期方法を実行するた
めの双方に適したネットワーク処理ハードウエアおよび
ソフトウエアを装備してある。 ＩＩＩ．帯域幅管理前置き ルータ３０は、例えば、Ｓｉｓｋｏ（シスコ社）または
Ｂａｙ Ｎｅｔｗｏｒｋｓ（ベイ・ネットワークス社）
から入手可能な形式の、市販のルータでよい。サーバ
は、Ｈｅｗｌｅｔｔ Ｐａｃｋａｒｄ（ヒューレット・
パッカード社）、Ｃｏｍｐａｑ（コンパック社）等のよ
うな種々の製造会社から、サーバと称して市販されてい
るＰＣまたはＰＣ型コンピュータ・コンポーネントでよ
い。これらのハードウエア・サーバも、多くの場合同様
に「サーバ」または「論理サーバ」ソフトウエアと呼ば
れているソフトウエアを走らせる。この論理サーバ・ソ
フトウエアは、図示の実施形態では、図４に概略的に示
すように、少なくとも３つの基本エレメントを含む。

【００５６】これらのエレメントの内第１エレメント
を、リンク・サーバ４０（以下、場合によってはリンク
サーブまたは同様の用語で呼ぶこともある）と呼ぶ。リ
ンク・サーバ４０は、Ｔ−１本の回線上でルータを介し
て受信した全メッセージを処理する。これらの回線はゲ
ーム・ユニットから発し、必要な場合に、帯域幅マネー
ジャ（ＢＷＭ）４２にこれらのメッセージを転送する
（forward）。帯域幅マネージャは、ソフトウエア即ち
論理サーバの別のエレメントである。ＢＷＭ４２は、ゲ
ーム・ユニットのメッセージをそれ自体の対戦サーバ４
４（以下で定義する）または「上流リンク・サーバ」、
即ち、地域、広域、または全国のような次に高いレベル
またはセンタにある論理リンク・サーバ４０のどちらに
送信すべきか判断を下す。送信した先で、そのリンク・
サーバ４０が再びプロセスを開始する。

【００５７】帯域幅マネージャ（ＢＷＭ）４２は、発見
法（heuristic）を実行し、図１に示すネットワーク・
システムにおける各階層レベルに対するプレーヤのアク
セス即ち「推奨」（promotion）を判定する論理サーバ
である。したがって、アーケード１０内のゲーム１６か
らのプレー要求は、最初にルータ３０によってその対応
するメトロ・ハブ１２，１４等において処理し、メトロ
・ハブ・サーバ３２の対応するリンク・サーバ４０が適
切な情報を関連する帯域幅マネージャ４２に中継し、そ
の要求をメトロ・ハブの対戦サーバ４４において処理す
べきか、あるいはこのプロセスの繰り返しのために地域
レベル２０におけるリンク・サーバ４０に転送すべきか
について判断を下す。

【００５８】対戦サーバ即ちｃｏｍｐｓｅｒｖｅｒ（ｃ
ｏｍｐｓｅｒｖｅ）４４は、本質的に、種々のゲーム・
ユニットから送られて来る要求を「突き合わせ」、これ
らの要求のどれが対話型プレーのためにリンクするのに
適しているかについて判定を行う。ゲーム形式のような
種々の基準が使用可能であり、同様のまたは適合性のあ
る形式のゲームのみを対話型ゲームのためにリンクする
ことを可能にする。例えば、リンクさせるためには、２
人以上のプレーヤが、レーシング・ゲームにおける同じ
レース・トラックのような、同じ「世界」でのプレーを
要求していなければならない。図示の実施形態では、ｃ
ｏｍｐｓｅｒｖｅｒ４４は、プレーヤの技能レベルも参
考にして、プレーヤの技能レベル全体またはより広い範
囲内でプレーヤの技能レベルを一層近づけるようにする
ことも可能である。以下で更に詳しく説明するが、技能
レベルがネットワークの階層レベルへの割り当てを決定
する。また、対戦サーバ４４は、要求の世界も考慮す
る。即ち、例えば、ロード・レーシング・ゲームでは、
同じトラック上でのレースを要求する全プレーヤのみを
対話型プレーにリンクすることができる。異なるトラッ
ク上のように、異なる「世界」でのプレーを望むプレー
ヤの要求は、同じ「世界」でのプレーを要求する追加の
プレーヤの要求も同じ対戦サーバで受信されるまで待た
なければならない。加えて、図示の実施形態では、ｃｏ
ｍｐ ｓｅｒｖｅｒ４４は、対戦を待っている他のプレ
ーヤから「一致しない」要求がある場合、個々のゲーム
に通知を送り、システムが有するマルチ・システム・ゲ
ームにおける対話型ゲーム内にリンクする容量のプレー
ヤ数まで、マルチ・ゲーム対戦に他の者が加わるように
招くことも可能である。

【００５９】ここでは「サーバ・スイート」（server s
uite）と言う場合、特定のハードウエア・サーバ３２内
に含まれる論理サーバ集合（前述した通り）を意味する
こととする。ここでは、親サーバまたは「子」サーバと
言う場合、図１のネットワーク階層上の位置を示し、親
は子に対して高いレベルにあるものとする。「ローカ
ル」論理サーバと言う場合、同じサーバ・スイート内に
位置する論理サーバを意味するものとする。

【００６０】帯域幅マネージャ（ＢＷＭ）は、図１を参
照して先に説明したネットワークの１機能（feature）
であり、サーバ３２によって実現し、マルチ・プレー
ヤ、マルチ・ゲーム・ユニット、および多レベル対戦に
対応する。

【００６１】ＢＷＭの主要なジョブは、使用可能なネッ
トワーク帯域幅を監視し、多レベル対戦サービスの調整
および追跡を行うことである。十分なインバウンドおよ
びアウトバウンド帯域幅があり、プレーヤが適切な技能
レベルを有するのであれば、ＢＷＭは、当該プレーヤに
ＷｅｖｅＮｅｔ階層における次のレベルへのアクセスを
保証する。

【００６２】ＢＷＭには２つのタスクがある。第１に、
階層におけるサーバのあるレベルと次に高いレベルとの
間の接続上での帯域幅の監視を担当する上流バラエティ
（ＵＳＢＷＭ：upstream variety）がある。各レベル毎
に、この種のＢＷＭを１つ配置してある。全ての「推
奨」基準を満たす場合、「対戦要求」（したがって、プ
レーヤ）を、階層内の次のレベルの親サーバ・スイート
に転送（「推奨」）し、ここで「推奨」プロセスを新た
に開始する。いずれのレベルでも「推奨」基準を満たさ
ない場合、当該レベルのサーバにおいて、最終的な調整
のためにメッセージを保持する。

【００６３】他の種類のＢＷＭは、メトロ・レベルでの
み見られる下流バラエティ（ＤＳＢＷＭ：downstream v
ariety）である。このＢＷＭは、メトロ・レベルのサー
バ・スイートとアーケードとの間の帯域幅監視を担当す
る。これを精度高く行うために、各アーケードには別個
のＢＷＭを割り当ててある。したがって、ＤＳＢＷＭは
アーケードと他のサーバとの初期リンクとなる。つま
り、ゲーム・ユニットからサーバへのメッセージは全て
ＤＳＢＷＭを通過する。非対戦サービス・メッセージ
（non-competition service message）は、手をつけぬ
まま、メトロ・レベルのリンク・サーバに送出する。対
戦サービス・メッセージは別個に扱う。ＵＳＢＷＭで用
いる同じ発見法によって、プレーヤにネットワークＷａ
ｖｅＮｅｔへのアクセスを付与するか否かについて判定
を行う。アクセスを付与する場合、メッセージをＵＳＢ
ＷＭに送出し、更に処理を進める。付与しない場合、メ
ッセージを削除する。これは、ネットワーク・プレーを
支える十分な帯域幅が、これ以上のプレーヤのためには
現在使用できないと判断した場合である。ゲームは、時
間切れになるか、あるいはこのような帯域幅が使用可能
になるまで、１秒毎に１回の割合で要求を送信し続け
る。

【００６４】実際にあるＢＷＭは、１種類だけである。
ＤＳＢＷＭはメトロ・ハブに配置してあっても、論理的
にアーケードに位置すると考えることができる。この模
範の下では、これはＵＳＢＷＭにもなり、アーケードか
らメトロ・サーバ・スイートへの接続を管理する。帯域
使用およびアクセス権利（推奨）は同様に扱う。異なる
のは、ＢＷＭの数、およびどのようにメッセージを処理
し送出するかについてである。以下の説明では、ＢＷＭ
サービスについて言う場合、双方のバラエティに共通の
ものを意味するものとする。必要な場合、相違を注記す
る。設計命名（design nomenclature） ＢＷＭは、ネットワークＷａｖｅＮｅｔの論理サーバで
ある。論理サーバは、ネットワークＷａｖｅＮｅｔのサ
ービスを提供する。ゲームはクライアントと見なす。ク
ライアントは、常に、この模範（paradigm）において
は、制御側エージェントであり、サービス要求を開始す
る役割を担う。しかしながら、サーバは、要請されなく
とも通知を送り、クライアントからの要求をトリガする
ことも可能である。サーバが実行しているハードウエア
をホストと呼ぶ。

【００６５】ＢＷＭは、背景で走り、開いているファイ
ルの記述子を全て閉じ、ファイル作成マスクをリセット
し、その親プロセス・グループからの関連を絶ち、制御
側端末からの関連を絶つ。

【００６６】メッセージおよびデータ・フローの考察
（view）は、ＢＷＭを中心とする。メッセージに関して
論ずる場合は、ＢＷＭに関して考察すべきである（例え
ば、インバウンドはＢＷＭに向かう方向である）。サー
バのメッセージ・フローを記述する場合、通信の終点
は、ゲーム・ユニットまたはサーバのいずれかとして示
す。終点間のサービスには多数のレベルがあり得る（即
ち、ＮＳＳおよびＬｉｎｋＳｅｒｖｅｒを経由するフロ
ー）が、簡略化および明確化のためには、レベルを無視
する場合もある。

【００６７】

【表８】

【００６８】ネットワーク帯域管理の概念 ＢＷＭは、親サーバ・スイート（ＵＳＢＷＭ）またはア
ーケード（ＤＳＢＷＭ）へのネットワーク接続上におい
て、現在使用中のインバウンドおよびアウトバウンド上
流帯域幅を追跡する役割を果たす。ＤＳＢＷＭは論理的
にアーケードに位置することを思い出されたい。サーバ
・スイートおよびゲーム・ユニット間トラフィックは双
方共、このネットワーク接続を用いる。

【００６９】ＢＷＭが対戦要求を受信すると、最初に、
現在の上流帯域幅使用率をチェックする。帯域幅が使用
可能であり、プレーヤがアクセス権利を有する場合（以
下の「プレーヤ・アクセス権利および推奨発見法」の章
を参照のこと）、ＢＷＭはこのプレーヤのために帯域幅
を予約し獲得するプロセスを開始する。

【００７０】ＵＳＢＷＭ−プレーヤに使用可能な帯域幅
がない場合（帯域幅が最大限使用されているか、あるい
はプレーヤに十分な技能レベルがない場合）、ＵＳＢＷ
Ｍはメッセージをローカル対戦サーバに送出する。

【００７１】ＤＳＢＷＭ−プレーヤに使用可能な帯域幅
がない場合、ＤＳＢＷＭは単にそのメッセージを削除す
る。対戦を支援するために使用可能な帯域幅が十分にな
い場合、これ以上できることはない。ゲーム・ユニット
は、時間切れになるか帯域が使用可能になるまで、１秒
に１回の割合で対戦要求を送信し続ける。

【００７２】この章の残りでは、要求時に対戦を支援す
るのに十分な帯域幅が存在すると仮定する。その場合、
ＢＷＭは、そのジョブを行うために２つの外部情報片を
必要とする。即ち、ゲーム・ユニットの帯域要件を決定
するためのゲーム形式、および対戦に可能なプレーヤの
最大人数である。ゲーム・ユニットの帯域幅要件（ＧＢ
Ｒ）は、ゲーム・ユニットが獲得する必要がある帯域幅
の最大量である。ゲーム・ユニットが必要とする帯域幅
は、インバウンドおよびアウトバウンド・チャネルに関
して対称的であると仮定する。ＢＷＭが対戦要求を受信
した時点では、その対戦に参加すると思われるプレーヤ
数に関して、先験的知識を有していない。したがって、
対戦は最大数で行われ、最大量の帯域幅を確保すると仮
定しなければならない。例えば、あるゲームの対戦限度
が８プレーヤである場合、ＢＷＭは各プレーヤに１アウ
トバウンドＧＢＲを確保し、７つの対応するインバウン
ドＧＢＲを他の７人のプレーヤに確保する。プレーヤの
状態を作成し、帯域幅を確保し、使用率を再度計算し、
プレーヤの要求を適切なサーバ・スイートに送出する。
ゲーム・ユニットからのこれ以降の対戦要求では、帯域
幅確保を行わない。

【００７３】また、ＢＷＭは、対戦を形成し、調整し、
閉じた後、使用を再調節しなければならない。一旦閉じ
たなら、対戦には固定数のプレーヤがいる。最悪の事態
を想定したので（即ち、可能な最大プレーヤ数）、最初
の対戦要求時点では、実際に必要であったよりも多くの
帯域幅を確保した可能性がある。帯域幅調節を管理する
インフラストラクチャは、ＢＷＭ＿ＡＤＪＵＳＴメッセ
ージのコールバック・チェーンである。ＣＯＭＰ＿ＣＬ
ＯＳＥＤを同報通信した直後に、選択した対戦サーバが
ＢＷＭ＿ＡＤＪＵＳＴメッセージを各ゲーム・ユニット
に、プレーヤの推奨を担当した全ＢＷＭを介して返送す
る。このメッセージの中には、対戦に関与した全ゲーム
・ユニットのＩＰ（インターネット・プロトコル。また
は適用可能であればそれ以外のプロトコル）アドレスを
カプセル化してある。１つのインバウンドＧＢＲは、Ｂ
ＷＭが以前に推奨した各ゲーム・ユニット（プレーヤ）
毎（即ち、ＢＷＭは当該プレーヤの状態を有する）に、
矯正する（reclaim）。これは、インバウンド・トラフ
ィックの初期仮定を最大数の対戦者から行うために必要
となる。技能レベルが低い方のプレーヤ（「プレーヤ・
アクセス権利および推奨発見法」参照）は、上流回線上
にインバウンド・トラフィックを発生しない。対戦に関
する状態は、ＢＷＭにおいて作成し、システムが対戦毎
に１回だけ矯正することを保証する。矯正の後使用率を
調節し、子ＢＷＭがある場合、ＢＷＭ＿ＡＤＪＵＳＴメ
ッセージを下流側に中継する。ＢＷＭ＿ＡＤＪＵＳＴメ
ッセージは、対戦内の各プレーヤ毎に送る。ＢＷＭ＿Ａ
ＤＪＵＳＴメッセージが失われるという稀な場合、これ
は破局的ではない。起こるのは、帯域幅使用度が下方に
調整されず、誤って高いままにまたは過剰使用状態のま
ま残るだけである。この「過剰使用」は、控えめ（cons
ervative side）であるので、システムは安全である。
即ち、その限度内にある。この異常が発生した場合、Ｃ
ＯＭＰ＿ＯＶＥＲ＿ＡＣＫコールバック・シーケンスま
たは「ガーベージ・コレクション」がそれに対処する。

【００７４】一旦対戦が終わったなら、ゲーム・ユニッ
トはＣＯＭＰ＿ＯＶＥＲまたはＣＯＭＰ＿ＣＯＮＴＩＮ
ＵＥのいずれかを送る。ＢＷＭおよびコンプサーバはこ
のメッセージ（即ち、メッセージからのＡＣＫ）を用い
て、プレーヤおよび対戦に関連するあらゆる状態を一掃
する。ＢＷＭは、その一掃の一部として、対戦に割り当
てた全帯域幅（インバウンドおよびアウトバウンド双
方）を矯正しなければならない。対戦における各ゲーム
は、これらのメッセージの一方を送る。同じＢＷＭが対
戦内の２人以上のプレーヤを推奨した場合、ＢＷＭは矯
正のために多数の要求を受信することになる。対戦に対
する矯正は全て、最初のＣＯＭＰ＿ＯＶＥＲ＿ＡＣＫま
たはＣＯＭＰ＿ＣＯＮＴＩＮＵＥ＿ＡＣＫの受信時に行
われる。その後のメッセージは、単に下流側に中継する
だけである。

【００７５】ＧＢＲ値は、サーバ・スイート・コンフィ
ギュレーション・ファイル内における各ゲームのセクシ
ョン内に位置するゲーム毎に同調可能な型（per-game-t
ypetunable）である。同調可能は、帯域＿消費型（band
width#consumed）と呼ばれ、例えば、前述の８プレーヤ
・ゲームの例では、ｋビット／秒の単位を有する。

【００７６】

【表９】

【００７７】プレーヤ・アクセス権利および推奨発見法 ＢＷＭは、より高いレベルの対戦へのアクセスを付与で
きる程プレーヤが「優れている」か否かについて判定す
る役割を担う。アクセス権利は、現在の平均技能レベル
および現在の帯域使用度に関係するので、プレーヤの技
能レベルを基本とする。プレーヤの技能レベルは、ゲー
ム・ユニットが判定し、対戦要求メッセージ内にカプセ
ル化する。現在の帯域幅使用度は、インバウンドまたは
アウトバウンド上流帯域幅使用度のいずれか大きい方で
ある（システムは、常に双方に接続されているので、悪
い方を選択する）。

【００７８】帯域幅は、収容度（commodity）と見なす
ことができ、そしてその点で貴重なものと見なすことが
できる。この収容度の値は、直接使用可能量に関係す
る。十分に使用可能である場合（即ち、ネットワークが
アイドル状態）、得るのは比較的「安価」であり、だれ
でもそれを消費する機会が得られる。逆に、ネットワー
クがかなり使用されている場合、残りの帯域は「高価」
となり、獲得するのは困難である。この消費者の市場通
貨単位は、技能レベルである。その考えは、現在対戦を
要求している最良のプレーヤを推奨するためである。

【００７９】プレーヤには全帯域幅（１００％）が使用
可能になる訳ではない。サーバ、ルータ等が、オーバー
ヘッドとして使用するために、その内のある割合を確保
する。この割合をオーバーヘッド確保率（ＯＲＰ：Over
head Reserved Percentage）と呼び、サーバ・スイート
・コンフィギュレーション・ファイルを通じて同調可能
（tunable）である。一旦ＯＲＰに達すると、ＢＷＭ
は、十分な帯域が得られるようになるまで、全ての推奨
を保留にする。

【００８０】プレーヤの技能レベルは変数内に収容して
あり、技能範囲は０ないし２５５である。０は完全に無
能であり、２５５は最高の技能レベルである。スレシホ
ルドを設定して、習熟度の高いプレーヤから、平凡な習
熟度のプレーヤを分離する。このスレシホルドを、熟達
プレーヤ・スレシホルド（ＳＰＴ：Skilled Player Thr
eshold）と呼ぶ。ＳＰＴは、習熟度の高いプレーヤに確
保しておく少量の帯域幅を規制するために用いる。確保
しておく帯域幅は、熟達プレーヤ確保率（ＳＲＰ：Skil
led-player ReservedPercentage）によって管理し、Ｓ
ＲＰからＯＲＰまでの帯域幅となる。一旦プレーヤの技
能レベルがＳＰＴを超過すると、プレーヤは、確保帯域
幅に対して常にアクセス可能となる。このようにして、
最良のプレーヤには最良の推奨の機会を与えることを保
証する。ＳＰＴおよびＳＲＰは、サーバ・スイート・コ
ンフィギュレーション・ファイルを通じて同調可能であ
る。図４を参照のこと。

【００８１】プレーヤの推奨を判断する際に、２つの異
なるメトリックを用いる。その相違は、現在使用中の帯
域幅の量に関係する。使用中の帯域幅が自由アクセス率
（ＦＡＰ：Free Access Percentage）または自由推奨ス
レシホルド（ＦＰＴ：Free Promotion Threshold）未満
である場合、プレーヤの技能レベルには無関係に、彼ま
たは彼女にアクセスを付与し推奨する。これによって、
「ポンプに呼び水を差し」（ネットワークにプレーヤを
送り込み）、推奨したレベルで彼らに対戦させ続けるこ
とができる。これは、単にネットワークを通じてプレー
する楽しみがあるばかりでなく、ネットワーク運営者に
とっても利益が大きくなることは言うまでもない。ＦＡ
Ｐは、サーバ・スイート・コンフィギュレーション・フ
ァイルを通じて同調可能である。その値は、未習熟のプ
レーヤや平均的なプレーヤを過剰にネットワークに許可
しないことを保証するために、十分に低く設定しなけれ
ばならない。

【００８２】一旦ＦＡＰに達したなら、第２の推奨メト
リックを用いる。プレーヤにアクセスを付与する毎に、
現在推奨中のプレーヤ全員の技能レベル・リストに当該
プレーヤの技能レベルを追加する。次に、平均技能レベ
ル（ＡＳＬ）を計算し、線グラフを作成する。この線の
一方の終点をＦＡＰに固定し、他方は固定のＳＲＰＸ−
値（図５参照）に沿って０からＳＰＴまで変化する。変
化する終点のＹ値は、丁度計算したばかりのＡＳＬであ
る。この情報を装備し、線の傾きを以下の式で計算す
る。

【００８３】

【数４】

【００８４】傾きおよび現在の帯域幅使用度が得られた
なら、ＢＷＭはプレーヤの技能レベルを現在の平均技能
レベルと比較することができる。ｘを現在使用中の帯域
幅の割合とすると、ｙは推奨スレシホルド（ＰＴ）とな
る。

【００８５】

【数５】

【００８６】一旦ｙを計算したなら、プレーヤのアクセ
ス権利を決定するために必要な全ては、単純な比較だけ
である。プレーヤの技能レベルがＰＴ線よりも上に位置
する場合、プレーヤには推奨のためのアクセスを付与す
る。

【００８７】ＵＳＢＷＭ−プレーヤがＰＴ線の下に位置
する場合、調整のために要求をローカル対戦サーバに転
送する。 ＤＳＢＷＭ−プレーヤの習熟度が線の下に位置する場
合、ＤＳＢＷＭは単にメッセージを削除する。プレーヤ
は、現在の帯域幅使用度では不十分な技能を有するに過
ぎない。ゲームは、時間切れになるかあるいはＡＳＬ減
少のためにプレーヤに帯域幅が使用可能になるまで、１
秒毎に１回の割合で、対戦要求を送信し続ける。

【００８８】プレーヤが彼らの対戦を完了した際に（ま
たはガーベージ・コレクションが古いエントリを一掃す
る際に）、使用可能な帯域幅および平均技能レベルを調
節する。プレーヤの技能レベル値は、現在の技能リスト
から、時間遅れ式に（time-delayed manner）減少す
る。これは、プレーヤの技能エントリを技能レベル・リ
スト上に置くことによって行う。少量の時間の後、リス
ト内の値をＡＳＬ値に再度組み込む。この方式は、ＡＳ
Ｌを実際よりも高めに一時的に維持することにより、継
続するプレーヤをより良く管理する。対戦の後技能レベ
ルが向上した継続プレーヤは、次回帯域幅を得る機会が
多くなる。

【００８９】図５ないし図７は、推奨発見法の例を３つ
示す。斜線部分は、推奨領域を表わす。図５は、消費さ
れている帯域がＦＡＰ未満であり、したがってＢＷＭは
全プレーヤを推奨する例を示す。図６および図７は、帯
域幅の６０％が使用中である例および、現在の平均技能
レベル（ＡＳＬ）の例を２つ示す。図６では、ＡＳＬは
かなり低く、したがって、推奨に必要な技能レベル（Ｐ
Ｔ）も対応して低い。図７は、ＡＳＬがＳＰＴの上限に
達した例を示す。６０％という同一帯域幅の下では、図
７では推奨に必要な技能レベル（ＰＴ）は遥かに高くな
る。

【００９０】推奨発見法に関連するＢＷＭチューナブル
（BWM tunable）は５つある。（チューナブルに関する
更なる詳細については、表５−「ＢＷＭ同調可能」を参
照のこと。）

【００９１】

【表１０】

【００９２】他のゲーム形式では、本システムは正規化
機構を組み込んで、技能レベルを考慮することができ
る。何故なら、異なるゲーム形式は異なる技能レベル・
パターンを有する場合もあるからである。静的または動
的な訂正も必要となることもあり得る。しかしながら、
全てのゲーム・ユニットが同じ帯域幅を競うのであるか
ら、使用する帯域幅は同一のままである。メッセージ型分析 共通サーバ管理メッセージに加えて、ＢＷＭは以下の４
つのメッセージ型、ＣＯＭＰ＿ＲＥＱ、ＣＯＭＰ＿ＯＶ
ＥＲ、ＣＯＭ＿ＣＯＮＴＩＮＵＥ、ＣＯＭＰ＿ＯＶＥＲ
＿ＡＣＫ、およびＢＷＭ＿ＡＤＪＵＳＴを扱う。

【００９３】

【表１１】

【００９４】ＢＷＭは、ＣｏｍｐＳｅｒｖｅｒが対戦を
閉鎖するまで、各秒毎に各ゲームからＣＯＭＰ＿ＲＥＱ
を受信する。要求に対してＢＷＭが最初に行うことは、
メッセージｈｏｐカウンタの増分である。ｈｏｐカウン
タは、メッセージのゲームからの距離を暗示的に示す。
サーバは、この情報を活用して（leverage）、これらが
階層内のどこに位置するのか推論する。

【００９５】次に、ＢＷＭはその内部状態表を参照し、
プレーヤに次のレベルへのアクセスを既に付与したか否
か確かめる。付与した場合、推奨のために要求をクリア
する。ユーザがプレーの世界を選択した場合、ＢＷＭは
それ自体のＩＰアドレスおよびポート番号をメッセージ
に添付する。アドレスを添付することによって、対戦に
近い時刻にＢＷＭ＿ＡＤＪＵＳＴコールバックが発生
し、帯域幅使用度を調節できることを保証する（これ以
上の情報については、「ＢＷＭ＿ＡＤＪＵＳＴ」の章を
参照のこと）。

【００９６】ＵＳＢＷＭ−次に、次のレベルのサーバ・
スイート（ＬＩＮＫＳｅｒｖｅｒ）にＣＯＭＰ＿ＲＥＱ
を転送する。 ＤＳＢＷＭ−次に、更に推奨を検討するために、ローカ
ル・レベルのＵＳＢＷＭにＣＯＭＰ＿ＲＥＱを転送す
る。

【００９７】状態が存在しない場合、メッセージをチェ
ックして、対戦ｉｄ、ｃｉｄの値を見ることにより、そ
れが新たな対戦かまたは既に調整済みの対戦かについて
確かめる。ｃｉｄが０の場合、ゲームは新たな対戦を要
求していることになる。そうでなければ、ｃｉｄの値
は、既に調整済みのローカル対戦のそれであり、メッセ
ージを処理のためにローカルＣｏｍｐＳｅｒｖｅｒに送
出する。

【００９８】新たな対戦に対して、ＢＷＭは次にプレー
ヤを推奨に検討すべきかについて判定を行う。「ネット
ワーク帯域幅管理概要」および「プレーヤ・アクセス権
利および推奨発見法」という章には、推奨基準について
の詳細な説明がある。プレーヤが推奨に適格であると仮
定すると、ＢＷＭはそのプレーヤの要求に対して状態を
作成し、現在の平均技能レベルおよび帯域幅使用度を調
節する。ユーザがプレーの世界を選択している場合、Ｂ
ＷＭはそれ自体のＩＰアドレスおよびポート番号をメッ
セージに添付する。

【００９９】ＵＳＢＷＭ−次に、ＣＯＭＰ＿ＲＥＱを次
のレベルのサーバ・スイート（LinkServer）に転送す
る。 ＤＳＢＷＭ−次に、更に推奨を検討するために、ローカ
ルのＵＳＢＷＭにＣＯＭＰ＿ＲＥＱを転送する。

【０１００】逆に、推奨基準を満たさず、階層内に次の
レベルがない場合、ＢＷＭは休眠状態となる。即ち、推
奨ロジックをディスエーブルしておく。プレーヤには状
態を作成しない。

【０１０１】ＵＳＢＷＭ−調整のためにＣＯＭＰ＿ＲＥ
Ｑをローカルの対戦サーバに転送する。 ＤＳＢＷＭ−ＣＯＭＰ＿ＲＥＱメッセージを削除する。

【０１０２】ＣＯＭＰ＿ＲＥＱフローチャートについて
は、図８−１０を参照のこと。

【０１０３】

【表１２】

【０１０４】プレーヤが継続しないことを選択した場
合、ネットワーク対戦の終了時に、ゲームはＣＯＭＰ＿
ＯＶＥＲメッセージを発生する。プレーヤが継続するこ
とを決定した場合、ゲームは代わりにＣＯＭＰ＿ＣＯＮ
ＴＩＮＵＥメッセージを送る。双方のメッセージの内容
は同一であり、ヘッダ内の動作フィールドのみが異なる
だけである。メッセージは、ゲームが最終的にＡＣＫを
受信するまで、各秒毎にゲームから送る。ＡＣＫは、ど
ちらの動作が要求されたのかに応じて、ＣＯＭＰ＿ＯＶ
ＥＲ＿ＡＣＫまたはＣＯＭＰ＿ＣＯＮＴＩＮＵＥ＿ＡＣ
Ｋのいずれかとなる。

【０１０５】要求に対してＢＷＭが最初に行うことは、
メッセージｈｏｐカウンタの増分である。ｈｏｐカウン
タは、メッセージのゲームからの距離を暗示的に示す。
サーバは、この情報を活用して、これらが階層内のどこ
に位置するのか推論する。

【０１０６】次に、ＢＷＭはその内部状態表を参照し、
プレーヤに次のレベルへのアクセスを既に付与したか否
か確かめる。付与した場合、ＢＷＭはそれ自体のＩＰア
ドレスおよびポート番号をメッセージに添付する。アド
レスを添付することによって、復路上でＢＷＭには自動
的にＡＣＫが渡される。

【０１０７】ＵＳＢＷＭ−次に、ＣＯＭＰ＿ＯＶＥＲ／
ＣＯＭＰ＿ＣＯＮＴＩＮＵＥを次のレベルのサーバ・ス
イート（LinkServer）に転送する。 ＤＳＢＷＭ−次に、ＣＯＭＰ＿ＯＶＥＲ／ＣＯＭＰ＿Ｃ
ＯＮＴＩＮＵＥをローカル・レベルのＵＳＢＷＭに転送
する。

【０１０８】ＣＯＭＰ＿ＯＶＥＲ／ＣＯＭＰ＿ＣＯＮＴ
ＩＮＵＥメッセージは、プレーヤのアクセス権利に関連
する状態を除去しないことに注意されたい。これは、Ａ
ＣＫの受信時に行う。

【０１０９】プレーヤに状態がない場合、対戦がローカ
ルであったか、あるいはその状態が既に以前のＡＣＫに
よって一掃されていることになる。いずれの場合でも、
更に処理するためにメッセージをローカルのＣｏｍｐＳ
ｅｒｖｅｒに受け渡す。

【０１１０】図１１は、ＣＯＭＰ＿ＯＶＥＲ、ＣＯＭＰ
＿ＣＯＮＴＩＮＵＥメッセージ処理のフローチャートで
ある。

【０１１１】

【表１３】

【０１１２】ＣｏｍｐＳｅｒｖｅｒは、ＣＯＭＰ＿ＯＶ
ＥＲまたはＣＯＭＰ＿ＣＯＮＴＩＮＵＥに応答して、Ｃ
ＯＭＰ＿ＯＶＥＲ＿ＡＣＫまたはＣＯＭＰ＿ＣＯＮＴＩ
ＮＵＥ＿ＡＣＫをそれぞれ最初に発生する。ＢＷＭは、
ＣＯＭＰ＿ＯＶＥＲメッセージがＣｏｍｐＳｅｒｖｅｒ
まで浸透する（percolate）際、そのアドレスおよびポ
ートをこのメッセージに予め添付しておいたことを思い
出されたい。

【０１１３】ＡＣＫメッセージの目的は２つある。第１
に、ＢＷＭはこのメッセージを用いて、プレーヤに代わ
って作成したあらゆる状態を一掃し始める。第２に、ゲ
ームは、サーバがプレーヤとの処理を完了し、ゲームは
今や解放され別のＷａｖｅＮｅｔの対戦のために使用可
能となっていることの指示として、このメッセージを扱
う。

【０１１４】ＢＷＭがＡＣＫメッセージを受信すると、
対戦に対する状態があるか否か確認するためにチェック
する。ある場合、対戦に割り当てた全ての帯域幅を一掃
し、対戦状態エントリを除去する。この方法により、帯
域幅は一層容易に使用可能となる。

【０１１５】次に、プレーヤを既に推奨したか否かにつ
いて確認するためにチェックを行う。推奨した場合、ゲ
ームの状態エントリを除去する。ゲームに割り当てた帯
域幅の矯正を未だ終了していない場合、これも行う。最
後にＡＳＬを調節する。

【０１１６】次に、メッセージをイニシエータ（initia
tor）に受け渡す。このように、ＡＣＫは全ての推奨レ
ベルを通じて次々に自動的に返送されるので、対戦の作
成に関連する状態は、各レベルにおいて適正に破棄され
る。この設計は非常にきれいで、しかも非常に拡張性が
高い。

【０１１７】同じＢＷＭが対戦内の２人以上のプレーヤ
を推奨された場合、ＢＷＭはその同一対戦に対する矯正
のために多数の要求を受信することになる。対戦に対す
る矯正は全て、最初のＡＣＫの受信時に１回行われる。
その後のメッセージは、単に下流側に中継するだけであ
る。

【０１１８】図１２は、ＣＯＭＰ＿ＯＶＥＲ＿ＡＣＫ、
ＣＯＭＰ＿ＣＯＮＴＩＮＵＥ＿ＡＣＫメッセージ処理の
フローチャートである。

【０１１９】

【表１４】

【０１２０】ＣｏｍｐＳｅｒｖｅｒは、対戦を閉鎖した
直後に、ＢＷＭ＿ＡＤＪＵＳＴメッセージを発生する。
これは、最初に推奨プロセスの一部としてプレーヤに状
態を作成した際に確保した帯域幅を調節するために用い
る。メッセージおよびその作用の説明については、「ネ
ットワーク帯域幅管理の概要」という章を参照のこと。
図１３は、ＢＷＭ＿ＡＤＪＵＳＴメッセージ処理を示す
フローチャートである。メッセージ・フローの分析 図１４−１６、図１７および図１８の３つのメッセージ
のフロー図またはチャートは、対戦の調整および一掃に
関係するメッセージの詳細な分析を示す。最初のフロー
チャート、図１４−１６は、対戦を調整する２台のゲー
ム・ユニットの例を示す。対戦の開始に関連する全ての
メッセージ型および対戦状態が含まれる。状態はＣｏｍ
ｐＳｅｒｖｅｒに対する適用性の方が高い。図１７およ
び図１８は、対戦が完了したときに送るメッセージを示
す。この図には、ＢＷＭおよびＣｏｍｐＳｅｒｖｅｒが
どのようにして、以前に失ったメッセージを処理するか
に関する例が含まれている。

【０１２１】図１５を参照すると、右上角において、ゲ
ーム・ユニットは毎秒対戦要求を送信する。参照番号１
２０１において、推奨基準を満たした場合、状態を作成
し、帯域幅を確保し、プレーヤを推奨する。図１４−１
６の例では、対戦要求を受信するまで、対戦状態は初期
状態ではアイドルになっている。ゲーム・ユニットは、
最初に、要求世界（requested world）を指定せずに、
対戦要求を送り、保有中の対戦に関する情報を突き止め
る。１２０２に示すように、プレーヤが世界を選択する
まで、ＣＯＭＰステータス・メッセージを返送する。こ
の時点で、対戦状態は保留となる。即ち、選択した世界
を伴う第１のＣＯＭＰ要求の受信時に、対戦を作成し状
態を保留に変更するが、ＣＯＭＰステータス・メッセー
ジは未だ返送させる。

【０１２２】参照番号１２０３において、他のゲーム・
ユニットにおける第２のプレーヤが、第１のプレーヤが
選択した同じ世界の対戦に加わる。ここで、対戦はステ
ージング状態（staging state）に入り、ステージ待ち
タイマを初期化し、ＣＯＭＰ開始メッセージを対戦内の
全ゲームに返送する。この状態では、ＣＯＭＰ開始メッ
セージが各対戦要求に応答する。一旦各ＢＷＭまたは状
態待ちタイミングが過ぎた場合、状態を閉鎖に変更し、
閉鎖待ちタイマを初期化し、対戦中の全ゲームにＣＯＭ
Ｐ＿ＣＬＯＳＥメッセージを返送する。この時点では、
ＣＯＭＰ＿ＣＬＯＳＥメッセージが新たな対戦要求に応
答する。ＢＷＭ＿ＡＤＪＵＳＴは、対戦を閉鎖した後発
生する。対戦状態は、閉鎖待ちタイマが終了した後アク
ティブになる。参照番号１２０４は、メッセージが失わ
れた場合の接続解除を示し、ゲーム・ユニットは対戦要
求を再度送信する。

【０１２３】図１７を参照すると、１３０１において、
プレーヤにアクセス権利を付与し、プレーヤをＵＳＢＷ
Ｍに渡す。１３０２において、ＵＳＢＷＭは推奨を追跡
し、ＣＯＭＰ＿ＯＶＥＲメッセージを次のレベルに渡
す。参照番号１３０３において、ＣｏｍｐＳｅｒｖｅｒ
は、一旦データが安定になったなら、ＣＯＭＰ＿ＯＶＥ
Ｒ承認を開始する。１３０４において、対戦破棄（comp
etition teardown）が全ての推奨レベルを通じて遡って
行き（cascade back）、適正な一掃を確保する。

【０１２４】図１８において、参照番号１４０１は、Ｃ
ＯＭＰ＿ＯＶＥＲ＿ＡＣＫメッセージを失った場合の接
続解除を示す。ゲーム・ユニットはＣＯＭＰ＿ＯＶＥＲ
メッセージを再度送信する。１４０２において、未確認
または未知の対戦から別のＣＯＭＰ＿ＯＶＥＲメッセー
ジを受信する。全く同様に、ＣＯＭＰ＿ＯＶＥＲ＿ＡＣ
Ｋ回答を発生する。ＢＷＭチューナブル

【０１２５】

【表１５】

【０１２６】ＢＷＭの突出した特徴のまとめ ゲーム、ルータ、サーバ等の間のネットワーク接続は、
１．５Ｍビット／ｓのＴ−１本の回線とする。

【０１２７】ステートフル（stateful）。ＢＷＭは、以
前にアクセス権利を付与したプレーヤを追跡しなければ
ならない。この情報は、動的なアクセス権利表に保持し
ておく。この表は、以下のエレメントを含む。ゲームＩ
Ｐアドレスおよびポート番号、プレーヤの技能レベル、
プレーヤのゲームが消費する帯域幅、エントリのエポッ
ク（作成時刻）、エントリの最終アクセス時刻、および
対戦エントリへのポインタ。

【０１２８】ＵＳＢＷＭは、階層レベルに関して対称的
である。これは、ＵＳＢＷＭが、階層のどこに位置する
かには無関係に、同じ機能を実行することを示唆する。
ＤＳＢＷＭはメトロ・レベルに固有である。メトロ・サ
ーバ・スイートと通信する各アーケードを管理する別個
のＤＳＢＷＭがある。これを行うために、ＤＳＢＷＭは
適切なファイルを読み込み、一意のドメイン（アーケー
ド）毎に、サーバを活性化する。これは、サーバの呼び
出し時に行われる。

【０１２９】ＤＳＢＷＭは、プレーヤにアクセスを与え
た場合には、常にローカルＵＳＢＷＭに連絡し（rout
e）、それ以外では、使用可能な資源が不十分なためメ
ッセージを削除する。

【０１３０】上流および下流ＢＷＭ双方に同じ二進数を
用いる。ユーザは、サーバの呼び出し時に、「スイッ
チ」を供給し、方向を示さなければならない。−ｄはＤ
ＳＢＷＭを指定し、−ｕはＵＳＢＷＭを指定する。

【０１３１】インバウンドおよびアウトバウンド双方の
帯域幅使用度を監視する。ＢＷＭが帯域幅使用度を比較
する場合、これはインバウンドまたはアウトバウンド値
のいずれか大きな方との比較を暗示する。システムは、
双方に常に接続されているので、悪い方の場合を選択す
る。

【０１３２】技能レベルおよび使用可能帯域幅は、プレ
ーヤのアクセス権利を決定するために用いるコンポーネ
ントである。アクセスを付与する場合、プレーヤを階層
内の次のレベルに推奨する。推奨発見法は同調可能なの
で、コードを再コンパイルする必要なく、スレシホルド
を調節することができる。発見法は性質上動的であり、
現在帯域幅を消費しているプレーヤ集合に基づいて変動
する。

【０１３３】ＵＳＢＷＭは、その推奨ロジックの一部と
して、メッセージを階層内の別のレベルに導出すること
を許されている数個のサーバの１つである。これは、非
常に簡単に行われる。推奨の結果、対戦要求が、階層レ
ベル内の次のレベルにおける親サーバ・スイート（Link
Server）に渡される（次のレベルがあるものとする）。
このインターフェースによって、システムはあらゆる深
さにも容易に拡張（scale）可能となる。

【０１３４】ＢＷＭは、起動時、固定時間量だけ（デフ
ォルトでは、例えば、５分）休眠状態に留まる。これ
は、アクセス権利を付与し帯域が消費される前に、ネッ
トワークを既知の状態に整定させるためである。

【０１３５】推奨ロジックをディスエーブルし、プレー
ヤの推奨を事実上停止することも可能である。これは、
ＷａｖｅＮｅｔサーバ・ツールが送るコマンドによって
行う。休眠時間は、このツールによって調節可能であ
る。

【０１３６】ＵＳＢＷＭは、親ＬｉｎｋＳｅｒｖｅｒの
ＩＰアドレスおよびポート番号を要求する。これらの値
は、ローカル・サーバ・スイート・コンフィギュレーシ
ョン・ファイルから得られる。次の新たなセクションお
よびトークンを作成する。

【０１３７】

【表１６】

【０１３８】各ＢＷＭには別個のコンフィギュレーショ
ン・ファイル・セクションがある。これによって、より
良い同調粒度（tuning granularity）を可能にする。Ｕ
ＳＢＷＭのセクションを［ＵＳＢＷＭ］と呼び、ＤＳＢ
ＷＭのセクションを［ＤＳＢＷＭ］と呼ぶ。メトロ・レ
ベルよりも高いレベルに対するコンフィギュレーション
・ファイルは、ＤＳＢＷＭエントリを有さない。

【０１３９】周期的な「ガーベージ・コレクション・サ
ービス」を提供し、古いサーバ状態や、確保してあるあ
らゆる帯域幅エントリを一掃する。陳腐化したエントリ
が、ネットワーク／サーバ障害のために生ずる場合があ
る。各メッセージの終了時に「タイマ」をチェックし、
「ポップ」している場合、「ガーベージ・コレクション
・サービス」を呼び出す。タイマをＢＷＭ＿ＣＯＬＬＥ
ＣＴ＿ＧＡＲＢＡＧＥ秒の値にセットする。ＢＷＭ＿Ａ
ＧＥ＿ＯＬＤ秒後、エントリは古いと見なす。これらの
値は、ここに記載中の実施形態では、同調可能ではな
い。

【０１４０】また、ガーベージ・コレクションは、ＳＥ
ＲＶＥＲ＿ＣＯＬＬＥＣＴ＿ＧＡＲＢメッセージをＢＷ
Ｍに送ることによってもトリガすることができる。周期
的な一貫性チェックを行い、平均技能レベル（ＡＳＬ）
および帯域幅使用率を検証する。これを行うには、全プ
レーヤおよび対戦状態を、ＡＳＬおよび帯域幅使用度を
維持するために用いる動的な値と比較する。ＢＷＭ＿Ｃ
ＯＬＬＥＣＴ＿ＧＡＲＢＡＧＥタイマと概念が似ている
タイマを保持する。ここに記載中の実施形態では、この
値は同調可能ではない。 ＩＶ．アーキテクチャＷａｖｅＮｅｔ サーバの共通性 全てのサーバは、１組の共通サーバ管理メッセージ（Ｃ
ＳＭＭ）に対応する。ＢＷＭはこの要件に従う。ＣＳＭ
Ｍメッセージは、ＢＷＭの内部機能性を制御する。動作
種別は次の通りである。

【０１４１】１．サーバ冗漫レベル（server verbosity
level）（ＳＥＲＶＥＲ＿ＶＥＲＢＯＳＥ）［ＬＯＧ＿
ＣＲＩＴ（０）−ＬＯＧ＿ＤＥＢＵＧ（７）］ ２．ＢＷＭがエラー時に終了することの許可（ＳＥＲＶ
ＥＲ＿ＥＸＩＴ＿ＹＥＳ）または不許可（ＳＥＲＶＥＲ
＿ＥＸＩＴ＿ＮＯ） ３．終了時におけるコア・ファイルの生成（または無生
成）（ＳＥＲＶＥＲ＿ＥＸＩＴ＿ＹＥＳ／ＳＥＲＶＥＲ
＿ＥＲＲ＿ＣＯＲＥ） ４．サーバ・コンフィギュレーション・ファイル（ＳＥ
ＲＶＥＲ＿ＨＵＰ）の再読み込み、ＢＷＭ状態の再初期
化 ５．ピング・メッセージ（ping message）の受信／Ａｃ
ｋ（ＳＥＲＶＥＲ＿ＰＩＮＧ） ６．ＢＷＭを死なせ、コア・ファイルを生成させる（Ｓ
ＥＲＶＥＲ＿ＦＯＲＣＥ＿ＣＯＲＥ） ７．ＢＷＭ特定−強制ガーベージ・コレクション（ＳＥ
ＲＶＥＲ＿ＣＯＬＬＥＣＴ＿ＧＡＲＢ）ＷａｖｅＮｅｔ制御プロトコル・ヘッダ（ＷＮＣＰ） ゲーム・ユニット（複数のゲーム・ユニット）、ＮＳＳ
およびサーバ間を通過するメッセージは全て、共通ヘッ
ダが前に付くパケット内にカプセル化する。メッセージ
・ヘッダおよびデータは、パックし（バイト毎に位置合
わせする）、ネットワーク・バイト順に通過させる。Ｗ
ａｖｅＮｅｔサーバ・メッセージ・ヘッダは以下の構造
を有する。

【０１４２】

【表１７】

【０１４３】ゲームからサーバへの着信メッセージは全
て、ＷＮＣＰヘッダ直後にゲーム型およびゲーム・バー
ジョンを含む。サーバの多くは、ゲーム型間で識別する
必要があり、したがってこの必要条件を固守しなければ
ならない。ゲーム・ユニットからサーバへのメッセージ
は全て、次のフォーマットで始まる。

【０１４４】

【表１８】

【０１４５】本発明は種々の変更や代替形態が可能であ
るが、一例としてここには具体的な実施形態を示しかつ
説明した。しかしながら、開示した特定の形態に本発明
を限定することを意図する訳ではないことは理解されよ
う。逆に、本発明は、添付の特許請求の範囲に規定して
ある本発明の精神および範囲に該当する変更、同等およ
び代替物全てを包含するものとする。

【図面の簡単な説明】

【図１】本発明によるビデオ・ゲームのネットワーク処
理システムを示す図である、

【図２】従来技術のこれまでの最高得点更新型のトーナ
メント・システムの動作を示す簡略図である。

【図３】従来技術のシステムにおける、異なる位置にい
る２人のプレーヤのみの間での対話型プレー動作の簡略
化ブロック図である。

【図４】本発明の論理サーバの構成の簡略化した概略図
である。

【図５】本発明による帯域管理の例を示す概略図であ
る。

【図６】本発明による帯域管理の例を示す概略図であ
る。

【図７】本発明による帯域管理の例を示す概略図であ
る。

【図８】本発明の帯域管理の様々な特徴を示すフローチ
ャートである。

【図９】本発明の帯域管理の様々な特徴を示すフローチ
ャートである。

【図１０】本発明の帯域管理の様々な特徴を示すフロー
チャートである。

【図１１】本発明の帯域管理の様々な特徴を示すフロー
チャートである。

【図１２】本発明の帯域管理の様々な特徴を示すフロー
チャートである。

【図１３】本発明の帯域管理の様々な特徴を示すフロー
チャートである。

【図１４】本発明による帯域管理の更に別の特徴を示す
フローチャートである。

【図１５】本発明による帯域管理の更に別の特徴を示す
フローチャートである。

【図１６】本発明による帯域管理の更に別の特徴を示す
フローチャートである。

【図１７】本発明による帯域管理の更に別の特徴を示す
フローチャートである。

【図１８】本発明による帯域管理の更に別の特徴を示す
フローチャートである。

【符号の説明】

１０ 複数のアーケード １２ メトロ・ハブ １６ ゲーム・ユニット １８ アーケード・ルータ ２０ 地域センタ ２２ 広域センタ ２４ 全国センタ ２６ モデム ２８ モデム ２９ 中央サーバ ３０ ルータ ３２ サーバ ３９ サーバ ４０ リンク・サーバ ４２ 帯域幅マネージャ ４４ 対戦サーバ

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１１年１２月２８日（１９９９．１２．
２８）

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図２】

【図３】

【図４】

【図８】

【図１４】

【図１】

【図５】

【図６】

【図７】

【図９】

【図１０】

【図１１】

【図１２】

【図１７】

【図１３】

【図１５】

【図１８】

【図１６】

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジェフリー・エル・アレン アメリカ合衆国イリノイ州60618−5899, シカゴ，ノース・カリフォルニア・アベニ ュー 3401，ミッドウェイ・アミューズメ ント・ゲームズ・エルエルシー内 Ｆターム(参考） 2C001 AA00 AA11 AA17 BB00 BB05 BC00 BC10 CB00 CB01 CB08 CC02 5B089 GA11 GA23 GA31 GB03 JA09 KA18 KC52 5K030 GA16 HA08 HB02 HB21 HC01 HC14 HD03 HD06 JT04 JT10 LA15 LB02 LC07 LC08 9A001 BB04 CC08 HH34 JJ05 JJ76 KK31 KK45 KK62

Claims (30)

【特許請求の範囲】
1. 【請求項１】 電子ゲーム・ユニットのネットワーク処
   理システムであって、 複数の位置の各々において１つ以上のゲーム・ユニット
   と結合してあり、更に通信リソースに結合してあり、前
   記１つ以上のゲーム・ユニットとの双方向情報交換を支
   援するアーケード・ルータと、 前記通信資源の第１グループと結合してあり、前記１つ
   以上のゲーム・ユニットの対応する第１グループとの双
   方向情報交換を支援する第１ルータと、 前記第１ルータと結合してあり、前記双方向データ交換
   を制御し、前記複数の場所の内異なる場所における複数
   のゲーム・ユニットによる対話型プレーを支援する第１
   サーバと、を備えることを特徴とするシステム。
2. 【請求項２】 請求項１記載のシステムであって、更
   に、１つ以上の通信資源によって２つ以上の前記第１ル
   ータに結合してある少なくとも１つの追加ルータと、前
   記追加ルータと結合してあり、前記２つ以上の第１ルー
   タ間の双方向情報交換を制御し、通信資源を介して前記
   ２つ以上の第１ルータと結合してあるゲーム・ユニット
   のために対話型プレーを支援する少なくとも１つの追加
   サーバとを含むことを特徴とするシステム。
3. 【請求項３】 請求項２記載のシステムにおいて、前記
   少なくとも１つの追加ルータおよびサーバが、通信資源
   を介して２つ以上の第１ルータと結合してあるゲーム・
   ユニットのために対話型プレーを支援する１つ以上の地
   域ルータおよびサーバと、通信資源および第１ルータを
   介して２つ以上の前記地域ルータおよびサーバと結合し
   てあるゲーム・ユニットのために対話型プレーを支援す
   る少なくとも１つの広域ルータおよびサーバと、通信資
   源、第１ルータおよび地域ルータを介して、２つ以上の
   前記広域ルータに結合してあるゲーム・ユニットのため
   に対話型プレーを支援する全国ルータおよびサーバとを
   備えることを特徴とするシステム。
4. 【請求項４】 請求項１記載のシステムであって、更
   に、対話型プレーにおいて交戦するゲーム・ユニット間
   での情報交換を同期させ、前記ゲーム・ユニットの各々
   が実質的に同じ着信情報シーケンス上で動作するように
   する状態同期システムを含むことを特徴とするシステ
   ム。
5. 【請求項５】 請求項２記載のシステムであって、更
   に、対話型プレーにおいて交戦するゲーム・ユニット間
   での情報交換を同期させ、前記ゲーム・ユニットの各々
   が実質的に同じ着信情報シーケンス上で動作するように
   する状態同期システムを含むことを特徴とするシステ
   ム。
6. 【請求項６】 請求項１記載のシステムにおいて、前記
   第１サーバが、更に、使用可能な帯域幅および各ゲーム
   ・ユニットに関連するプレーヤの技能レベルに基づい
   て、各ゲーム・ユニットの前記ネットワークへのアクセ
   スを制御する帯域幅マネージャを含むことを特徴とする
   システム。
7. 【請求項７】 請求項２記載のシステムにおいて、前記
   サーバが、使用可能な帯域幅およびゲーム・ユニットに
   関連するプレーヤの技能レベルに基づいて、当該ゲーム
   ・ユニットの前記ネットワークへのアクセスを制御する
   帯域幅マネージャを含むことを特徴とするシステム。
8. 【請求項８】 請求項６記載のシステムにおいて、前記
   帯域幅マネージャが、 使用可能な帯域幅を判定する手段と、 前記ネットワークへのアクセスを要求する各ゲーム・ユ
   ニットに関連するプレーヤの習熟度を判定する手段と、 前記ネットワークへのアクセスを要求する全てのプレー
   ヤの平均技能レベル（ＡＳＬ）を判定する手段と、 前記平均技能レベルおよび前記使用可能な帯域幅に基づ
   いて、推奨スレシホルド（ＰＴ）を確定する手段と、 前記プレーヤの技能レベルが前記推奨スレシホルドを超
   過する場合、ネットワークへのアクセスをプレーヤに付
   与する手段と、を含むことを特徴とするシステム。
9. 【請求項９】 請求項７記載のシステムにおいて、前記
   帯域幅マネージャが、 使用可能な帯域幅を判定する手段と、 前記ネットワークへのアクセスを要求する各ゲーム・ユ
   ニットに関連するプレーヤの習熟度を判定する手段と、 前記ネットワークへのアクセスを要求する全てのプレー
   ヤの平均技能レベル（ＡＳＬ）を判定する手段と、 前記平均技能レベルおよび前記使用可能な帯域幅に基づ
   いて、推奨スレシホルド（ＰＴ）を確定する手段と、 前記プレーヤの技能レベルが前記推奨スレシホルドを超
   過する場合、ネットワークへのアクセスをプレーヤに付
   与する手段と、を含むことを特徴とするシステム、
10. 【請求項１０】 請求項９記載のシステムにおいて、前
    記帯域幅マネージャが、更に、前記帯域幅の所定比率を
    自由アクセス率（ＦＡＰ）として割り当てる手段を含
    み、前記帯域幅の前記自由アクセス率が得られる限り、
    プレーヤの習熟度には無関係にアクセスを付与すること
    を特徴とするシステム。
11. 【請求項１１】 請求項７記載のシステムにおいて、前
    記帯域幅マネージャが、更に、プレーヤのアクセスには
    使用不可能な、前記帯域幅のオーバーヘッド確保率を確
    定する手段を含むことを特徴とするシステム。
12. 【請求項１２】 請求項１０記載のシステムにおいて、
    前記帯域幅マネージャが、更に、前記帯域幅の熟達プレ
    ーヤ確保率（ＳＲＰ）と、熟達プレーヤ・スレシホルド
    技能レベルとを確定する手段を含み、前記熟達プレーヤ
    ・スレシホルド技能レベルより上では、前記技能プレー
    ヤ確保率の前記帯域幅へのアクセスをゲーム・ユニット
    に付与することを特徴とするシステム。
13. 【請求項１３】 請求項１２記載のシステムにおいて、
    前記帯域幅の前記自由アクセス率が使用中の場合、プレ
    ーヤの技能レベルが、以下の式 【数１】 にしたがって決定する推奨スレシホルドを超過する場
    合、ネットワーク・アクセスを付与し、 ここで、ｘ軸は現在使用中の帯域幅の比率を表わし、ｙ
    軸はプレーヤの技能レベルを表わし、ｙの値が推奨スレ
    シホルドを構成し、 ＡＳＬは平均技能レベル、ＳＲＰは熟達プレーヤ確保
    率、よびＦＡＰは自由アクセス率であること、を特徴と
    するシステム。
14. 【請求項１４】 請求項４記載のシステムにおいて、前
    記同期手段が、更に、マルチ・システム・ゲームに参加
    するゲーム・ユニット数を判定する手段と、複数の状態
    の各々において、前記ゲーム・ユニットの各々から他の
    各ゲーム・ユニットに入力データを送信する手段と、直
    前の状態における前記マルチ・システム・ゲーム内の他
    の各ゲーム・ユニットから前記入力データを受信し終え
    るまで、各ゲーム・ユニットが次の状態に遷移するのを
    防止し、前記マルチ・システム・ゲーム内のゲーム・ユ
    ニット全てが、次の状態に遷移する前に、各状態におい
    て前記入力データの同一集合上で動作するようにする手
    段とを含むことを特徴とするシステム。
15. 【請求項１５】 ゲームの最中に複数の状態を通過して
    遷移し、双方向プレーにおいて交戦する複数のゲーム・
    ユニット間の情報交換を同期させ、前記ゲーム・ユニッ
    トの各々が、実質的に同じ着信情報シーケンス上で動作
    するようにすることを特徴とする状態同期システム。
16. 【請求項１６】 請求項１５記載のシステムであって、
    更に、マルチ・システム・ゲームに参加するゲーム・ユ
    ニット数を判定する手段と、各状態において、前記ゲー
    ム・ユニットの各々から他の各ゲーム・ユニットに入力
    データを送信する手段と、直前の状態における前記マル
    チ・システム・ゲーム内の他の各ゲーム・ユニットから
    前記入力データを受信し終えるまで、各ゲーム・ユニッ
    トが次の状態に遷移するのを防止し、前記マルチ・シス
    テム・ゲーム内のゲーム・ユニット全てが、次の状態に
    遷移する前に、各状態において前記入力データの同一集
    合上で動作するようにする手段とを含むことを特徴とす
    るシステム。
17. 【請求項１７】 対話型プレーのために複数のゲーム・
    ユニットをリンクするネットワークの帯域幅マネージャ
    であって、使用可能な帯域幅と、各ゲーム・ユニットに
    関連するプレーヤの技能レベルとに基づいて、各ゲーム
    ・ユニットの前記ネットワークへのアクセスを制御する
    ことを特徴とする帯域幅マネージャ。
18. 【請求項１８】 請求項１７記載の帯域幅マネージャで
    あって、更に、 使用可能な帯域幅を判定する手段と、 前記ネットワークへのアクセスを要求する各ゲーム・ユ
    ニットに関連するプレーヤの習熟度を判定する手段と、 前記ネットワークへのアクセスを要求する全てのプレー
    ヤの平均技能レベル（ＡＳＬ）を判定する手段と、 前記平均技能レベルおよび前記使用可能な帯域幅に基づ
    いて、推奨スレシホルド（ＰＴ）を確定する手段と、 前記プレーヤの技能レベルが前記推奨スレシホルドを超
    過する場合、ネットワークへのアクセスをプレーヤに付
    与する手段と、を含むことを特徴とする帯域幅マネージ
    ャ。
19. 【請求項１９】 請求項１７記載の帯域幅マネージャに
    おいて、前記ネットワークが多数のレベルを有し、該帯
    域幅マネージャが更に、 前記ネットワークの各レベルにおいて使用可能な帯域幅
    を判定する手段と、 前記ネットワークへのアクセスを要求する各ゲーム・ユ
    ニットに関連するプレーヤの技能レベルを判定する手段
    と、 前記ネットワークへのアクセスを要求する全てのプレー
    ヤの平均技能レベル（ＡＳＬ）を判定する手段と、 前記ネットワークの各レベル毎に、前記平均技能レベル
    および前記使用可能な帯域幅に基づいて、推奨スレシホ
    ルド（ＰＴ）を確定する手段と、 前記プレーヤの技能レベルが前記ネットワークの所与の
    レベルに対する前記推奨スレシホルドを超過する場合、
    前記ネットワークの当該レベルへのアクセスをプレーヤ
    に付与する手段と、を含むことを特徴とする帯域幅マネ
    ージャ。
20. 【請求項２０】 請求項１８記載の帯域幅マネージャで
    あって、更に、前記帯域幅の所定比率を自由アクセス率
    （ＦＡＰ）として割り当てる手段を含み、前記帯域幅の
    前記自由アクセス率が得られる限り、プレーヤの習熟度
    には無関係にアクセスを付与することを特徴とする帯域
    幅マネージャ。
21. 【請求項２１】 請求項２０記載の帯域幅マネージャで
    あって、更に、前記帯域幅の熟達プレーヤ確保率（ＳＲ
    Ｐ）と、熟達プレーヤ・スレシホルド技能レベルとを確
    定する手段を含み、前記熟達プレーヤ・スレシホルド技
    能レベルより上では、前記技能プレーヤ確保率の前記帯
    域幅へのアクセスをゲーム・ユニットに付与することを
    特徴とする帯域幅マネージャ。
22. 【請求項２２】 請求項２１記載の帯域幅マネージャに
    おいて、前記帯域幅の前記自由アクセス率が使用中の場
    合、プレーヤの技能レベルが、以下の式 【数２】 にしたがって決定する推奨スレシホルドを超過する場
    合、ネットワーク・アクセスを付与し、 ここで、ｘ軸は、現在使用中の帯域幅の比率を表わし、
    ｙ軸はプレーヤの技能レベルを表わし、ｙの値が推奨ス
    レシホルドを構成し、 ＡＳＬは平均技能レベル、ＳＲＰは熟達プレーヤ確保
    率、よびＦＡＰは自由アクセス率であること、を特徴と
    する帯域幅マネージャ。
23. 【請求項２３】 ゲームの最中に複数の状態を通過して
    遷移し、双方向プレーにおいて交戦する複数のゲーム・
    ユニット間の情報交換を同期させ、前記ゲーム・ユニッ
    トの各々を実質的に同じ着信情報シーケンス上で動作さ
    せることを特徴とする状態同期方法。
24. 【請求項２４】 請求項２３記載の方法であって、更
    に、 マルチ・システム・ゲームに参加するゲーム・ユニット
    数を判定するステップと、 各状態において、前記ゲーム・ユニットの各々から他の
    各ゲーム・ユニットに入力データを送信するステップ
    と、 直前の状態における前記マルチ・システム・ゲーム内の
    他の各ゲーム・ユニットから前記入力データを受信し終
    えるまで、各ゲーム・ユニットが次の状態に遷移するの
    を防止し、前記マルチ・システム・ゲーム内のゲーム・
    ユニット全てが、次の状態に遷移する前に、各状態にお
    いて前記入力データの同一集合上で動作するようにする
    ステップと、を含むことを特徴とする方法。
25. 【請求項２５】 ネットワークにおいて対話型プレーの
    ために複数のゲーム・ユニットをリンクする帯域幅管理
    方法であって、使用可能な帯域幅と、各ゲーム・ユニッ
    トに関連するプレーヤの技能レベルとに基づいて、各ゲ
    ーム・ユニットの前記ネットワークの通信資源へのアク
    セスを制御することを特徴とする方法。
26. 【請求項２６】 請求項２５記載の方法であって、更
    に、 各通信資源上において使用可能な帯域幅を判定するステ
    ップと、 前記ネットワークへのアクセスを要求する各ゲーム・ユ
    ニットに関連するプレーヤの習熟度を判定するステップ
    と、 前記ネットワークへのアクセスを要求する全てのプレー
    ヤの平均技能レベル（ＡＳＬ）を判定するステップと、 前記平均技能レベルおよび前記使用可能な帯域幅に基づ
    いて、推奨スレシホルド（ＰＴ）を確定するステップ
    と、 前記プレーヤの技能レベルが前記推奨スレシホルドを超
    過する場合、ネットワークへのアクセスをプレーヤに付
    与するステップと、を含むことを特徴とする方法。
27. 【請求項２７】 請求項２５記載の方法において、前記
    ネットワークが多数のレベルを有し、更に、 各通信資源上において使用可能な帯域幅を判定するステ
    ップと、 前記ネットワークへのアクセスを要求する各ゲーム・ユ
    ニットに関連するプレーヤの技能レベルを判定するステ
    ップと、 前記ネットワークへのアクセスを要求する全てのプレー
    ヤの平均技能レベル（ＡＳＬ）を判定するステップと、 前記ネットワークの各レベル毎に、前記平均技能レベル
    および前記使用可能な帯域幅に基づいて、推奨スレシホ
    ルド（ＰＴ）を確定するステップと、 前記プレーヤの技能レベルが前記ネットワークの所与の
    レベルに対する前記推奨スレシホルドを超過する場合、
    前記ネットワークの当該レベルへのアクセスをプレーヤ
    に付与するステップと、を含むことを特徴とする方法、
28. 【請求項２８】 請求項２６記載の方法であって、更
    に、前記帯域幅の所定比率を自由アクセス率（ＦＡＰ）
    として割り当てるステップを含み、前記帯域幅の前記自
    由アクセス率が得られる限り、プレーヤの習熟度には無
    関係にアクセスを付与することを特徴とする方法。
29. 【請求項２９】 請求項２６記載の方法であって、更
    に、前記帯域幅の熟達プレーヤ確保率（ＳＲＰ）と、熟
    達プレーヤ・スレシホルド技能レベルとを確定するステ
    ップを含み、前記熟達プレーヤ・スレシホルド技能レベ
    ルより上では、前記習熟プレーヤ確保率の前記帯域幅へ
    のアクセスをゲーム・ユニットに付与することを特徴と
    する方法。
30. 【請求項３０】 請求項２６記載の方法において、前記
    帯域幅の前記自由アクセス率が使用中の場合、プレーヤ
    の技能レベルが、以下の式 【数３】 にしたがって決定する推奨スレシホルドを超過する場
    合、ネットワーク・アクセスを付与し、 ここで、ｘ軸は、現在使用中の帯域幅の比率を表わし、
    ｙ軸はプレーヤの技能レベルを表わし、ｙの値が推奨ス
    レシホルドを構成し、 ＡＳＬは平均技能レベル、ＳＲＰは熟達プレーヤ確保
    率、よびＦＡＰは自由アクセス率であること、を特徴と
    する方法。