JP2002544689A - 通信ネットワークにおける方法及び装置 - Google Patents

Abstract

(57)【要約】 特に多数の参加者間での通信ネットワークのリアルタイム性能が、少なくとも１つのクライアント・ユニットから情報を受信する受信手段を備えたサーバ・ユニットであって、前記情報が、配布されたインタラクティブ・アプリケーションについての状態情報の一部を少なくとも含んでおり、前記サーバ・ユニットが、前記クライアント・ユニットの少なくとも１つから受信したアプリケーションの状態情報を格納する状態情報格納手段と、前記クライアントから受信した状態情報を、ネットワーク内の少なくとも１つの他のノードに送り、前記状態情報格納手段に格納された情報の少なくとも一部を、前記少なくとも１つのクライアントに送信する送信手段と、を備えている、サーバ・ユニットによって改善される。このようにしてアプリケーションの状態の全部が、ネットワーク内の１つ以上のユニットによって保持され得、これは各クライアントが状態全部を格納する必要をなくし、そのため各クライアントについてのメモリ及び帯域幅の要件を低減する。

Description

【発明の詳細な説明】

【０００１】 ［技術分野］ 本発明は通信ネットワークに関し、より詳細には、そのようなネットワークの
アプリケーションのいくつかのユーザ間のリアルタイム通信に関する。

【０００２】 ［従来技術の説明］ マルチユーザ通信のアプリケーションは、例えば、マルチユーザのゲームのた
めに、現在開発されている。このようなゲームは、同じＬＡＮあるいはインター
ネットなどの大きなネットワークの異なった部分に接続された数人のユーザによ
ってプレーされるであろう。そのようなアプリケーションに対しては、３つの主
な同期モデルが使用される。すなわち、クライアント−サーバ同期、ピアツーピ
ア同期あるいはブロードキャスト同期である。インターネット上のいくつかのマ
ルチユーザ・ゲームには、今日１０００００人に達するプレーヤが係わり、その
数千人は同時にプレーすることがある。現在使用される全ての同期方法はかなり
長い遅延を生ずる。従って、現在インターネットによってプレーされるマルチユ
ーザ・ゲームは、速度が重要でないゲームである。例えば、数分の１秒以内に起
こったことにユーザが反応しなければならない、カー・レーシング・ゲームや対
戦ゲームのような高速アクション・ゲームは、あらゆる標準的な同期方法を使用
しても許容できる品質でプレーできない。

【０００３】 ダイヤルイン・ネットワークは通常クライアント−サーバ同期を使用する。こ
の場合、サーバは全てのプレーヤからデータを受信する。サーバは、各プレーヤ
が必要とする情報を理解し送信しなければならない。このシステムでは中央サー
バが明らかにボトルネックとなる。中央クライアント−サーバ型ゲームは、２〜
２５０のプレーヤをサポートできる。サービスする数が増えると更新レートは２
Ｈｚ程度まで遅くなる。中央サーバは、転送距離の増大とサーバ内の処理及びス
ケジューリングの遅延との両方の理由でレイテンシ（待ち時間）を付加する。例
えば、クライアントが米国の西海岸におり、サーバが米国の東海岸にある状況に
ついて考える。クライアント−サーバ・モードの動作により、約８０ｍｓの転送
のレイテンシと少なくとも数１０ｍｓの処理のレイテンシが生じる。

【０００４】 従って、クライアント−サーバ同期は、遅延が重要である多数のプレーヤでの
リアルタイムのアプリケーションに適していない。

【０００５】 ピアツーピア同期は、全てのクライアントが他の全てのクライアントにアプリ
ケーション・データを直接送ることを意味する。このモデルは公共的なインター
ネットによってプレーされるゲームに、しばしば使用される。ゲームの開発者は
、プレーヤがゲームの設定及び実行中のゲームに参加するために集まる、フリー
・アプリケーション・ロビー・サーバを提供する。ゲームは一旦開始すると、ゲ
ーム開発者のサイトからは何のリソースも使用せずに、ピアツーピア・モードで
プレーされる。

【０００６】 ピアツーピア同期は明らかにスケーラビリティに問題がある、なぜならネット
ワークの負荷はプレーヤの数の二乗に比例するからである。すなわち、クライア
ントのアクセス帯域幅とＣＰＵ能力の要件はプレーヤの数に比例する。各パケッ
トのペイロードは１０〜４０バイトであり、これはプロトコルのオーバヘッドが
通常５０％より多いことを意味する。ゲームの小さなパケットはプロトコルのオ
ーバヘッドを大きくする。しかしながら、ヘッダ圧縮方法でこのオーバヘッドは
かなり小さくできる。インターネットによるピアツーピアのゲームは、予期でき
ない遅延及び同期の喪失により頻発する崩壊（collapses）で損なわれる。

【０００７】 続けると、ピアツーピア同期はまた、距離が比較的短くユーザの数が限定され
た通信を行う小さなネットワークに最も良く適合する。

【０００８】 ブロードキャスト同期は、ローカル・エリア・ネットワーク（ＬＡＮ）での限
定された数のプレーヤには使用できるが、大きなネットワークには適していない
。

【０００９】 同期方法によって課せられた制限のため、現在の技術では良好なリアルタイム
特性を有する参加者が多数の通信は実現できない。

【００１０】 各ユーザに一度送信する代わりに、各マルチキャスト・サーバに一度だけ情報
を送信すればよい点で、マルチキャストによりネットワーク内で送信すべき情報
はかなり削減できる。各マルチキャスト・サーバは、情報をコピーしてそれを接
続されたユーザに送信する。各ユーザが受信する必要のある情報が選択されるで
あろう。これはサーバ間及び各サーバとそのユーザ間の両方のトラフィックを減
少するであろう。このような解決策をゲームに適用することが、米国特許番号５
，８４１，９８０に開示されている。

【００１１】 米国特許番号５，８４１，９８０に開示されたシステムでは、各ユーザはユー
ザが現在の状況において関連するゲームの部分に関する情報、例えば、ユーザが
現在いる地理的領域に関する情報だけを有している。状況が変わると、例えば、
ユーザが別の部屋に入ると、新たな状況で重要な情報をユーザは入手できないで
あろう。

【００１２】 ［発明の目的］ 本発明の目的は、通信ネットワーク、特に多数の参加者間での協働的通信にお
けるリアルタイム性能を改善することである。

【００１３】 ［発明の概要］ 上記目的は、通信ネットワークで使用されるサーバ・ユニットによる本発明に
よって達成され、前記サーバ・ユニットは、少なくとも第１のクライアント・ユ
ニットから情報を受信する受信手段を備えており、前記情報が、配布されたイン
タラクティブ・アプリケーションについての状態情報を少なくとも含んでおり、
前記サーバ・ユニットが、 −前記第１及び第２のクライアント・ユニットから受信手段によって受信した
情報に含まれる、アプリケーションの状態情報を格納する状態情報格納手段と、 −前記少なくとも第１のクライアント・ユニットから受信した状態情報を、ネ
ットワーク内の少なくとも１つの他のノードに送る第１の送信手段と、 −前記状態情報格納手段に格納された情報の少なくとも一部を、前記少なくと
も１つのクライアント・ユニットに送信する第２の送信手段と、を備えることを
特徴とする。

【００１４】 これにより、ネットワーク内の１つ以上のユニットのアプリケーションの全て
の状態を保つことが可能となり、これは各クライアントが全体の状態を格納する
必要をなくし、このため各クライアントで必要なメモリ容量と各クライアントで
との通信に必要な帯域幅とが削減される。アプリケーションの状態の各部分が１
つ以上のネットワーク・ノードに格納されれば、バックアップ機能が達成される
。

【００１５】 上記目的は、通信ネットワークの端末で使用されるクライアント・ユニットに
よる本発明によって達成され、該クライアント・ユニットは、配布されたインタ
ラクティブ・アプリケーション・ソフトウェアを備えており、 −前記端末からの入力を読み取る少なくとも１つの入力手段であって、前記入
力は配布されたインタラクティブ・アプリケーションのアプリケーション状態情
報を構成する、入力手段と、 −アプリケーション状態情報をアプリケーション・アクセス・サーバに送信す
る送信手段と、 −前記アプリケーション・アクセス・サーバから配布されたインタラクティブ
・アプリケーションの少なくともアプリケーション状態情報を受信する受信手段
と、 −前記状態情報を表示する手段と、を備えることを特徴とする。

【００１６】 本発明による方法及び装置は、特にリアルタイム通信に係る、配布されたイン
タラクティブ・アプリケーションに有用である。

【００１７】 好ましくは、前記サーバ手段の受信手段は、 −前記第１のクライアントが受信を望む情報について配布されたインタラクテ
ィブ・アプリケーションのオブジェクトを識別するサブスクリプション情報を、
少なくとも前記第１のクライアントから受信し、 −少なくとも１つのクライアント・ユニットに該クライアントユニットから受
信したサブスクリプション情報に応じて情報を送信し、 −前記サーバ・ユニットが前記サブスクリプション情報を格納する少なくとも
１つのクライアント・サブスクリプション・リストを更に備える、ように構成さ
れる。

【００１８】 このため、前記クライアント・ユニットは、入手可能な情報をそこから受信す
べき、配布されたインタラクティブ・アプリケーションの少なくとも１つのオブ
ジェクトを指定する、サブスクリプション情報を設定する手段と、前記サブスク
リプション情報を前記アプリケーション・アクセス・サーバに送信する手段とを
備える。

【００１９】 これにより、各ユーザに送信されるべき情報の量が減少し、このため伝送遅延
が減少し、特定のユーザにとって最も重要な情報だけがそのユーザに示されるの
で、各ユーザが情報を分析するのを助長する。各クライアントはどれが重要なの
かを自身で決定できる。

【００２０】 好適な実施形態では、受信手段は、少なくとも第２のクライアントから前記第
１のクライアントに関する緊急情報を受信するよう構成される。緊急情報が第１
のクライアントに送信されてもよく、あるいは前記第２のクライアントに関する
アプリケーション状態情報が、前記緊急情報に応じて少なくとも前記第１のクラ
イアントに送られてもよい。緊急情報はまた、あるアプリケーション状態情報が
前記第１のクライアントに送られるべきでないことを示すのに使用されてもよい
。緊急情報はクライアントのサブスクリプションを変更するのに使用されてもよ
い。

【００２１】 前記好適な実施形態では、クライアント・ユニットは、該クライアントから状
態情報をできるだけ速く受信すべき、少なくとも１つの他のクライアントを特定
するための、緊急データを設定する手段を更に備える。

【００２２】 有利なことには、アプリケーション状態情報を送信するクライアント・ユニッ
トの送信手段が、パケットがサーバ・ユニットに送信される前に、各パケットが
アプリケーションの一部を構成するオブジェクトに関連するように、オブジェク
ト情報パケット内の情報を配置するように構成され、前記受信手段が、サーバ・
ユニットから受信したパケットから情報を抽出するように構成される。

【００２３】 アプリケーション・アクセス・サーバ・システムは、アプリケーションから独
立しており、そのため広い範囲の異なったアプリケーションをサポートできる。

【００２４】 一緒に動作するアプリケーション・アクセス・サーバ・ユニットは、好ましく
は確保されたあるいは管理された伝送容量を提供する、ネットワークによって通
信するかもしれない。アプリケーションの合計した帯域幅の要件は、ネットワー
ク管理システムによって推定することができ、アプリケーション・アクセス・サ
ーバ・ユニットを接続する確保されたネットワークに、十分なネットワーク・リ
ソースが割り当てられ得る。リソースが利用可能であるときだけ、新たなアプリ
ケーションが許可される。ネットワーク管理は、アプリケーション・アクセス・
サーバの再送及び複製の方針も制御する。マルチキャスト及びリソース予約プロ
トコルを、アプリケーション・アクセス・サーバ間の合計したストリームに使用
できる。このシステムの利点は、プレーヤ・レベルでのリソース予約が必要で無
いことである。アプリケーションのクライアントは通常、全体の統計的性能が良
好であれば、偶発的に失ったパケットを処理する。本発明によるアプリケーショ
ン・アクセス・サーバを使用することは、アプリケーション・アクセス・サーバ
が常にゲームの状態を維持するので、ゲームのクライアントが同期を失うことが
永久にないことを意味する。

【００２５】 ［実施形態の詳細な説明］ 本発明による装置及び方法を、添付図面を参照してより詳細に説明する。

【００２６】 図１は本発明による通信ネットワークの実施形態を示している。本発明によれ
ば、ネットワークは少なくとも１つのアプリケーション・アクセス・サーバを備
えている。図１では、第１（１）、第２（３）及び第３（５）のアプリケーショ
ン・アクセス・サーバが示されており、これらは例えば、確保された電気通信ネ
ットワークなどのネットワーク７によって互いに接続されている。他のあらゆる
タイプのネットワークでも良いが、インターネットなどのネットワーク・リソー
スを確保することができないネットワークでは、負荷が重くなると品質が低下す
るであろう。いくつかのクライアント１１、１２、１３、１４、１５もネットワ
ーク７に接続されている。クライアントはアプリケーション・アクセス・サーバ
１、３、又は５に、以下で詳細に説明するように、当該技術分野で知られている
あらゆる方法で接続することができる。

【００２７】 参加者の多くのメンバーが同時にアプリケーションの状態に影響を及ぼし関与
する、例えば、リアルタイムのマルチユーザ・ゲームなどの、配布されたインタ
ラクティブ・アプリケーションを実行する目的で、クライアントはアプリケーシ
ョン・アクセス・サーバを通して互いに通信する。各クライアントと該クライア
ントと接続されているアプリケーション・アクセス・サーバとの間の接続は、通
常、モデム接続などの容量の小さな接続である。一方、２つのアプリケーション
・アクセス・サーバ間では、大きくかつ可変のネットワーク容量が利用できる。
従って、本発明によるアプリケーション・アクセス・サーバは、各クライアント
にそのクライアントに最も関係のある情報だけを送信することにより、各クライ
アントに送信される情報が減少されるような方法で、アプリケーションの状態に
ついての情報を処理するように構成されている。アプリケーション・アクセス・
サーバ間では、伝送容量は通常問題とならず、そのためアプリケーション・アク
セス・サーバ間でより多くの情報を送信することができる。

【００２８】 それ自体は既知の種類のアプリケーション・ロビー・サーバが、１つ以上ネッ
トワーク内にあってもよい。これらのサーバは、通常、クライアントが、課金機
能などを処理する、特定のタイプのサーバへ登録するのを許可する機能を有して
いる。

【００２９】 本発明によれば、アプリケーションに必要なソフトウェアは、クライアント１
１、１２、１３、１４、１５内にある。従って、本発明による通信機能を使用す
るためには、ユーザは自分が必要とするアプリケーション・ソフトウェアを持っ
ていることを確かめる必要がある。例えば、インターネットからのダウンロード
あるいはＣＤ−ＲＯＭからのインストールなどのこの技術分野で既知のあらゆる
方法で、アプリケーション・ソフトウェアが獲得される。アプリケーションにと
って必要であれば、ユーザはアプリケーションをロビー・サーバに登録する必要
がある。一般に、アプリケーション・ロビー・サーバ２１は、通常はＩＰアドレ
スなどのアドレスと、１つ以上のアプリケーション・アクセス・サーバ１、３、
５のポート番号を提供するが、このアドレスは他のあらゆる方法で獲得されても
よい。

【００３０】 ユーザはこの技術分野で一般的な方法で、通常は１つのアプリケーション・ア
クセス・サーバあるいはアプリケーション・アクセス・サーバのプール（pool）
のＩＰアドレスを入力することによってアプリケーション・アクセス・サーバに
接続する。同じアドレスで識別されるネットワーク内のいくつかのノードの適切
な１つを選択するのに、いくつかのアルゴリズムが存在する。アプリケーション
・アクセス・サーバは、以下でより詳細に説明するように、ユーザから情報を受
信して、ユーザへの情報の送信を開始する。クライアントがアプリケーション・
アクセス・サーバにログインする代わりに、アプリケーション・ロビー・サーバ
がクライアントのネットワーク・アドレスをアプリケーション・アクセス・サー
バに送信することもできる。

【００３１】 アプリケーションが、参加者によって制御されるオブジェクトのセットからな
ると想定する。オブジェクトは、人間の参加者によって制御されるかクライアン
トで生成されるアプリケーションのエンティティであり、例えば、乱数発生器や
他の予測できない計算処理によって制御されて、各アプリケーション・クライア
ントで局所的に再生されるものではない。アプリケーション・オブジェクトは、
参加者が直感的にオブジェクトとして認識するもの、あるいはゲームのフィギュ
アであるが、プレーヤによって制御される環境変数などのバックグランド・デー
タの構成物であってもよい。各オブジェクトは通常、アプリケーションの実行中
に変更され得る、特性のセットと属性を有している。ゲームにおいてこれらの特
性は、キャラクタの強さ及び他の能力、あるいは車の最大速度であり、属性は、
例えば、キャラクタによって制御されるアイテム等であろう。

【００３２】 ユーザから受信した情報は通常、シグナリング・オーバヘッドに加えて３つの
異なったタイプの情報を含み、それらは、状態情報、サブスクリプション情報、
制御データ及び緊急情報である。状態情報は、オブジェクトあるいはユーザによ
って制御されるオブジェクトについての情報であり、アプリケーションの他のユ
ーザにも分配されるべきものである。サブスクリプション情報は、アプリケーシ
ョン・アクセス・サーバによって提供される異なったアプリケーション・オブジ
ェクトに関するユーザの優先度をリストで表わす。例えば、あるオブジェクトの
グループに関する情報は、利用可能となったときに一度に、あるいはできるだけ
頻繁に受信されるべきであるが、別のオブジェクトのグループからの情報は急を
要するものではない。例えば、帯域幅が足りない場合、許容可能な遅延や優先順
位の形式で、いくつかの優先度レベルが設定されるであろう。クライアントによ
って生成される緊急情報は、他のクライアントが自身のサブスクリプションに含
まれていないオブジェクトについての情報を受信するように、別のクライアント
のサブスクリプションを変更あるいはオーバーライドするため、あるいはクライ
アントがある種の情報を受信していないのを確かめるために使用される。３つの
タイプの情報全てについて以下でより詳細に検討する。

【００３３】 例として、多数のユーザによってプレーされるリアルタイムのゲームのアプリ
ケーションを説明する。このようなゲームは現在は、例えば、ローカル・エリア
・ネットワーク（ＬＡＮ）内などの、互いに極めて近くに位置する限定された数
のユーザでプレーされる。広域ネットワークでプレーされれば、そのようなゲー
ムには将来は、通常は大きなゲーム・フィールドあるいは仮想的図形領域にわた
って分布する数千のプレーヤが係わるであろう。上記で検討したように、従来の
技術では、許容できる品質でこれを実現するのは可能ではない。

【００３４】 各プレーヤは、仮想ゲーム領域において彼の近くで起こることによってのみ、
すぐに影響を受ける。遠く離れた別のプレーヤは、このプレーヤより変更が重要
ではない。例えば、プレーヤが第１の敵対するプレーヤと戦うと、仲間のプレー
ヤがが助けに来るかもしれず、第２の敵対するプレーヤが仲間のプレーヤを止め
ようとするかもしれない。同時に、他のプレーヤは後で重要となるかもしれない
ことを行うであろが、プレーヤは戦いを勝ち抜くことに主に専念する。従って、
第１の敵対するプレーヤの動きは、ただちに表示されなければならない。仲間の
プレーヤ及び第２の敵対するプレーヤの動きにも高い優先度を与えるべきであり
、遠く離れて起こることには低い優先度を与えるべきである。

【００３５】 上記で説明した例では、明らかに、別の時点では他のプレーヤ、通常はいずれ
か所与の時点でユーザの近くに位置するプレーヤが最も高い優先度を持つので、
プレーヤの構成は変化するであろう。

【００３６】 アプリケーション・アクセス・サーバは、アプリケーション・クライアントと
の通信を扱う。該サーバは、アプリケーションの状態に影響を与えるクライアン
トの動作に関する情報と他の情報とを受信する。該サーバはまた、他の参加者か
らのアプリケーション状態情報を、参加者のサブスクリプションに従って参加者
に送信する。各アプリケーション・クライアントは、受信するアプリケーション
情報に関するサブスクリプションを設定し、これらサブスクリプションに関する
情報をアプリケーション・アクセス・サーバに送信する。アプリケーション・ア
クセス・サーバは、アプリケーション・アクセス・サーバによってサービスされ
るクライアントのサブスクリプションの記録を格納し更新する。各クライアント
のサブスクリプションは、どのデータをこのクライアントに送信すべきかを決定
するのに使用される。クライアントは、別のクライアントに対するサブスクリプ
ションも設定してもよい。ある一つの動作モードでは、マスター・クライアント
が例えば、他の全てのクライアントのサブスクリプションを設定してもよい。

【００３７】 あるクライアントが関係するアプリケーション・アクセス・サーバは、そのク
ライアントのローカル・アプリケーション・アクセス・サーバであり、そのクラ
イアントは、そのアプリケーション・アクセス・サーバのローカル・クライアン
トと呼ばれる。

【００３８】 アプリケーション・アクセス・サーバはまた、クライアント権限リストを保持
する。各クライアントは、１つ以上のゲーム・オブジェクトの状態を変更する権
利を持っている。クライアント権限リストは、各クライアントに対して１つのエ
ントリを有し、そこにはクライアントによって制御されるオブジェクトの識別子
が格納される。アプリケーション・アクセス・サーバは、クライアントからオブ
ジェクト状態情報を受信する度に権限をチェックする。ゲームの状態は、情報パ
ケット内にある識別子が権限リストのクライアントに対するエントリ内の数と一
致したときだけ更新され、そうでなければその情報は無視される。他アプリケー
ション・アクセス・サーバから来たオブジェクト状態情報は、送信したアプリケ
ーション・アクセス・サーバが権限を既にチェックしたので照合されない。

【００３９】 アプリケーション・アクセス・サーバはまた、アプリケーション状態情報と、
選択的にはそれらに対して集められたサブスクリプションとを送信し、同じタイ
プの情報をそれらから受信する、他のアプリケーション・アクセス・サーバ・ユ
ニットと通信する。通常、他のアプリケーション・アクセス・サーバに送信すべ
き情報は、いずれの方法でも優先順位を付けたり格納されたりせずに、適切なプ
ロトコルに従ってパッケージ化される。ローカル・クライアントのユーザのサブ
スクリプションに応じて、各アプリケーション・アクセス・サーバに送信すべき
情報を選択することももちろん可能であろう。集められたサブスクリプションは
、所与のアプリケーション・アクセス・サーバに属するクライアントからの全て
のアプリケーション・オブジェクト要求の合計である。例えば、アプリケーショ
ン・アクセス・サーバは、他のアプリケーション・アクセス・サーバに対してマ
ルチキャストを使用してもよい。これは各アプリケーション・アクセス・サーバ
・ユニットが必要な全ての更新を受信し、アプリケーション・アクセス・サーバ
によってゲーム状態が効率的に配布されることを保証する。

【００４０】 緊急データは、そのデータが別のクライアントにとって重要であるが、他のク
ライアントがこのことに気付いておらず、従って自身のサブスクリプションを設
定できない場合に、クライアントによって設定される。従って、緊急度は送信す
るクライアントによって定義され、受信するクライアントそれぞれで異なってい
るかもしれない。アプリケーション・アクセス・サーバは、緊急データが待機し
ていれば受信するクライアントに気を配る。緊急情報は、ある種の情報が１つ以
上のクライアントに送られるのを禁止するのにも使用されてもよい。

【００４１】 各アプリケーション・アクセス・サーバはまた、アプリケーション状態の完全
なあるいは部分的なコピーを格納し更新する。それらの間で、通信セッションに
割り当てられたアプリケーション・アクセス・サーバ・ユニットは、完全なアプ
リケーション状態を格納しなければならない。最も単純な場合には、全てのアプ
リケーション・アクセス・サーバが完全なアプリケーション状態を格納するが、
アプリケーション・アクセス・サーバ間で、オーバーラップする情報を持つ又は
持たないように情報を分離することも可能である。そのような解決策は、各アプ
リケーション・アクセス・サーバへの適切なデータの配布を処理するのに、特別
なソフトウェアを必要とする。

【００４２】 アプリケーション・アクセス・サーバは、アプリケーションを設定し、アプリ
ケーションの実行中に参加者を追加しかつ削除し、エラーやネットワークの故障
を処理するために、アプリケーション・ロビー・サーバと通信する。

【００４３】 図２は、本発明の実施形態によるアプリケーション・アクセス・サーバ５０を
その機能的エンティティで示している。このアプリケーション・アクセス・サー
バは、ハードウェアあるいはソフトウェアで実現できる。図２に関しては、概略
的説明だけをする。適切なフォーマット及びプロトコルについては後述する。

【００４４】 アプリケーション・アクセス・サーバは、ネットワーク内の各クライアントか
ら、及び他のアプリケーション・アクセス・サーバなどの他のユニットから、入
力バッファ５１によってデータを受信する。クライアント、リモート・アプリケ
ーション・アクセス・サーバ及びアプリケーション・ロビー・サーバのそれぞれ
には１つの入力バッファがあるが、図２では簡潔にするため１つの入力バッファ
だけが示されている。

【００４５】 ローカルな参加者それぞれの動作は、そのクライアントに関連するアプリケー
ション・アクセス・サーバの入力バッファに到着する、アプリケーション・オブ
ジェクト・パケットのペイロードとして送信される。これらアプリケーション・
オブジェクト・パケットは、参加者によって制御されるアプリケーション・オブ
ジェクトを更新する。アプリケーション・オブジェクト。パケットは、１組の挿
入規則を用いてアプリケーション状態レコードに書き込まれる。

【００４６】 クライアントから受信したデータは、３つのタイプのデータ、すなわち、アプ
リケーションの状態についてのデータ（状態データ）、クライアントのサブスク
リプションについてのデータ（優先度データ）及び他のクライアントの時間基準
状態に対する要求及びシステムからの他の情報などの他の制御情報、を含んでい
てもよい。状態データは、アプリケーション・オブジェクト・パイプライン５３
を通ってアプリケーション状態レコード５５に渡される。アプリケーション状態
レコード５５は、以下でより詳細に説明するように、関連する全てのオブジェク
トに対する全ての状態データを保持する。アプリケーション状態レコードは、上
記で説明した緊急データも保持する。

【００４７】 クライアントのグループが定義されてもよく、このグループは例えば、作業グ
ループの参加者や、ゲームの場合には同じチームの参加者を含んでいる。この場
合、サブスクリプション及び／又は緊急データもまた、個々のユーザについてだ
けではなく、ユーザのグループについて指定されてもよい。

【００４８】 制御データ、特に、アプリケーション・オブジェクトについて追加されるある
いは削除される、リアルタイムで処理される必要のないデータは、入力バッファ
５１からアプリケーション・アクセス・サーバ制御ユニット５７に渡される。ハ
ードウェアによる実施では、制御ユニット５７はマイクロプロセッサであろう。
制御ユニットによって処理される制御データは、例えば、プレーヤ及びオブジェ
クトの生成及び破壊と、プレーヤ及びオブジェクトのグループに関連するもので
あり得る。

【００４９】 サブスクリプションは、アプリケーション優先度制御プロトコル・メッセージ
・パイプライン５９を通って、アプリケーション・アクセス・サーバによってサ
ポートされる各クライアントのサブスクリプションを含んでいる、クライアント
優先度リスト（ＣＰＬ）６１に渡される。サブスクリプションは、クライアント
及びアプリケーション・アクセス・サーバ制御ユニットによって更新され得る。
制御ユニットは、例えば、別のクライアントから受信した緊急メッセージに応じ
て、クライアントのサブスクリプションを更新するのを決定できる。

【００５０】 アプリケーション・アクセス・サーバ・システムを用いるアプリケーション・
クライアントによって、いくつかの異なった優先順位付け方法が用いられてもよ
い。簡単な方法は、アプリケーション・クライアントがオブジェクトを列挙した
リストをＣＰＬ６１に送ることである。この場合、例えば、ラウンドロビン・モ
ードで、リスト上の全てのオブジェクトが更新されたときに、リストに載ってい
ないオブジェクトが更新され得る。例えば、ラウンドロビン・モードでは、リス
トの全てのオブジェクトが更新されたら、残りのオブジェクトが更新され得る。
特定のクライアントのサブスクリプションは、このクライアントによって設定さ
れたサブスクリプションについての全てのオブジェクトのリストを含んでいる。
アプリケーション・アクセス・サーバに格納されたリストに加え、各オブジェク
トについて新たな情報が受信されたかどうかを示すフラグを含んでいるのが好ま
しい。このフラグは、あるオブジェクトについての情報をクライアントに送信す
る必要があるかどうかを判定するのに使用される。情報がクライアントに送信さ
れたとき、フラグはリセットされる。アプリケーション・アクセス・サーバから
オブジェクトについての新たな更新を受信したとき、フラグが再度設定される。

【００５１】 クライアントのサブスクリプションはまた、各オブジェクトに関連した時間間
隔と共に定義され得る。そしてクライアントは、例えば、＜オブジェクト番号＞
，＜オブジェクト優先度＞，＜オブジェクト更新時間間隔＞，＜フラグ＞、とい
うフォーマットで一連の要求を送信する。簡単なリストは、＜オブジェクト番号
＞，＜オブジェクト優先度＞という簡単なフォーマットであってもよい。アプリ
ケーション・アクセス・サーバは、要求内の＜オブジェクト優先度＞フィールド
に従って与えられた優先度で、各時間間隔中に各オブジェクトが少なくとも１度
更新されるように、クライアントに更新を送信する。いくつかのオブジェクトを
全く更新しないように、無限大記号が使用されてもよい。特別な、「新たな完全
なオブジェクト状態の送信」フラグが設定されてもよい。このオプションは、ク
ライアントがオブジェクトに対する更新を長い間隔（数秒）で望むときに使用さ
れる。所望する時間解像度が状態リフレッシュ間隔よりも長いと、増分による更
新の送信は無駄が多くなるだろう。

【００５２】 出力パイプライン６３は、クライアント優先度リスト６１からサブスクリプシ
ョン情報を受信し、上記で説明した適切なアルゴリズムを用いて、当該クライア
ントに送信すべき情報をアプリケーション状態レコード５５から探すために、こ
の情報を使用する。選択された状態情報は、アプリケーション状態レコード５５
から出力パイプライン６３を通って出力バッファ６５に渡され、出力バッファか
らクライアントに渡される。制御ユニット５７は、例えば、クロックを同期させ
るため、あるいはレイテンシの推定値をクライアントに提供するために、制御メ
ッセージをクライアント及びリモード・サーバに送信する。

【００５３】 図２に示したアプリケーション・アクセス・サーバは各タイプのユニットを１
つだけ有するように示されているが、好ましくはアプリケーション・アクセス・
サーバは、アプリケーション・アクセス・サーバが情報を交換するネットワーク
内の各クライアント及び他のサーバ等のそれぞれに対して、１つの入力バッファ
５１、１つのアプリケーション・オブジェクト・パケット入力パイプライン５３
、１つの優先度メッセージ・パイプライン５５、及び１つの出力処理パイプライ
ン６３及び１つの出力バッファ６５を備えている。代替的に、クライアント又は
サーバのグループが、１つの入力バッファ５１、１つのアプリケーション・オブ
ジェクト・パケット入力パイプライン５３、１つの優先度メッセージ・パイプラ
イン５５、及び１つの出力処理パイプライン６３及び１つの出力バッファ６５を
共用してもよい。アプリケーション・アクセス・サーバはまた、各クライアント
、サーバ等に対して、１つのクライアント優先度リスト６１を備えている。

【００５４】 他のアプリケーション・アクセス・サーバから受信したデータは、他のクライ
アントからのオブジェクト状態データを含んでいる。それがまた好ましくは各オ
ブジェクトが優先度リストに１度現れるような方法で集められた、これらクライ
アントからの優先度情報を含んでいてもよい。この場合、各アプリケーション・
アクセス・サーバに対して１つの優先度リストが存在し、すなわち、各アプリケ
ーション・アクセス・サーバがクライアントのように取り扱われるように、情報
がパッケージ化される。別のアプリケーション・アクセス・サーバから受信した
情報は、以下で説明するように、いずれもあるプロトコル処理を実施する必要の
ある入力及び出力バッファ５１、６５を除いて、クライアントから受信した情報
と同様に取り扱われる。代替的には、他のアプリケーション・アクセス・サーバ
からサブスクリプション情報は全く送信されず、この場合、全ての状態情報がこ
れらアプリケーション・アクセス・サーバに送信される。

【００５５】 アプリケーション・アクセス・サーバは、全てのプレーヤが同時に更新される
、オプションのフェアプレイ・モードを処理する（下記参照）。

【００５６】 上述のように、ネットワーク内にはそれ自体は既知の種類の１つ以上のアプリ
ケーション・ロビー・サーバ（図１の２１）が存在している。アプリケーション
・ロビー・サーバは、ゲーム中に構成データを更新するのを受け持ち、アプリケ
ーション・アクセス・サーバに、以下のようなデータを提供する。 ・ゲームに参加する新たなアプリケーション・アクセス・サーバ・ユニットの
ＩＰアドレス又は他のネットワーク・アドレス。 ・アプリケーション・アクセス・サーバによってサービスされる参加者を識別
するネットワーク・アドレスの更新されたリスト。これにより新たな参加者が進
行中のアプリケーションに参加できる。 ・列挙されたゲーム・オブジェクトの更新されたリスト。各オブジェクトに対
して、状態がアプリケーション・アクセス・サーバ間で配布された場合に、どの
アプリケーション・アクセス・サーバがその状態を格納するのを受け持つかが指
定される。状態を更新するのを誰が認可されているのかが指定されていてもよい
。これにより、ゲーム・オブジェクトの生成、破壊及び制御の変更が可能となる
。クライアントもゲーム・オブジェクトの生成及び破壊ができる。 ・新たな完全なあるいは部分的なゲーム状態。これにより、アプリケーション
・アクセス・サーバがゲーム状態を廃棄したとき、ゲームの中断や故障の後の回
復が可能となる。

【００５７】 図３は、本発明によるアプリケーション・アクセス・サーバで使用されるアプ
リケーション状態レコードの例を示している。各アプリケーション・オブジェク
トの状態は、アプリケーション状態レコード内に列挙されたアプリケーション・
オブジェクト状態ＡＯＳ１〜ＡＯＳ４として格納される。各アプリケーション・
オブジェクト状態は、それぞれ一連のアプリケーション・オブジェクト・パケッ
トＡＯＰ１１〜ＡＯＰ１３、ＡＯＰ２１〜ＡＯＰ２４、ＡＯＰ３１及びＡＯＰ４
１〜ＡＯＰ４２からなる。オブジェクト・パケットは、オブジェクト・データ用
の入れ物である。アプリケーションからリモート・アプリケーション・クライア
ント又はサーバに送信された全てのデータは、アプリケーション・アクセス・サ
ーバ・システムによって処理できるように、アプリケーション・オブジェクト・
パッケージに包含される。

【００５８】 アプリケーション・アクセス・サーバによって受信された、接続されている他
の全てのアプリケーション・アクセス・サーバからの情報は、アプリケーション
状態レコード内のアプリケーション・オブジェクト情報を更新するのに使用され
る。好ましくは、２つのタイプのアプリケーション・オブジェクト・パケットが
ある。すなわち、１）オブジェクトについての現在のデータ全てを含む基準アプ
リケーション・オブジェクト・パケット、及び２）参照するＡＰＯのタイムスタ
ンプによって求められる時間から何が変わったかについての情報だけを含む増分
パケット、である。ＡＯＳ内の第１のＡＯＰは基準パケットである必要があり、
その後に増分パケットあるいは基準パケットの組が続くであろう。あるゲームで
は基準パケットだけが生成されるであろう。

【００５９】 アプリケーション状態レコードはまた、他のアプリケーション・アクセス・サ
ーバ・ユニットに配信される必要のあるアプリケーション・オブジェクト・パケ
ットの記録をとる。これは、各要素がフラグのマトリクス、new_cliant_data(i,
k)として実現されるデータ構造、new_cliant_dataを用いて行われる。パラメー
タｉはクライアント番号であり、パラメータｋはアプリケーション・アクセス・
サーバ番号である。アプリケーション・オブジェクト・パケットが、外部のアプ
リケーション・アクセス・サーバに配信されるべきであれば、フラグが設定され
る。

【００６０】 アプリケーション・オブジェクトを表わすのに、アプリケーション・オブジェ
クト状態がどのように使用されるのかの例として、図３は、アプリケーション・
オブジェクト状態ＡＯＳ１を示している。このオブジェクトがレーシング・ゲー
ムにおける乗り物の位置を示しているとする。乗り物の位置（ｘ１，ｙ１）が、
ゲーム時間ｔ１で基準アプリケーション・オブジェクト・パケットＡＯＰ１１の
ゲームのペイロードとして最初に送信される。帯域幅を節約するために、増分ア
プリケーション・オブジェクト・パケットＡＯＰ１２として、ゲーム時間ｔ２で
位置の相対的変化（Δｘ２，Δｙ２）が送信される。増分アプリケーション・オ
ブジェクト・パケットＡＯＰ１２は、基準として基準アプリケーション・オブジ
ェクト・パケットＡＯＰ１１を指し示している。ゲーム時間ｔ３で、新たな増分
位置（Δｘ３，Δｙ３）が第３のアプリケーション・オブジェクト・パケットＡ
ＯＰ１３で送信される。第３のアプリケーション・オブジェクト・パケットＡＯ
Ｐ１３は、基準として第２のアプリケーション・オブジェクト・パケットＡＯＰ
１２を有している。３つのアプリケーション・オブジェクト・パケットＡＯＰ１
１、ＡＯＰ１２、ＡＯ１３の全てを受信した後に、クライアントは時間ｔ３での
乗り物の位置を、（ｘ１＋Δｘ２＋Δｘ３，ｙ１＋Δｙ２＋Δｙ３）によって計
算できる。

【００６１】 特定のオブジェクトに対して新たなアプリケーション・オブジェクト・パケッ
トが受信されたとき、アプリケーション状態レコードは、そのオブジェクトに属
する前のパケット全てを削除し、新たな基準パケットだけを格納してもよい。ゲ
ームのペイロードの構文及び意味は、クライアント端末で実行中のゲームのアプ
リケーションによってのみ理解されることに注意されたい。データの喪失によっ
て生じる長期の中断を避けるために、アプリケーションは基準パケットを頻繁に
送るべきである。

【００６２】 アプリケーションをコーディングする代替的方法は、時間ｔ３でのアプリケー
ション・オブジェクト・パケットＡＯＰ１３を、基準としてアプリケーション・
オブジェクト・パケットＡＯＰ１１を用い、（ｘ１，ｙ１）に対する位置の変化
δｘ，δｙを表わすようにすることであろう。これは、第３のアプリケーション
・オブジェクト・パケットＡＯＰ１３が到着するとすぐに第２のアプリケーショ
ン・オブジェクト・パケットＡＯＰ１２を削除できるので、アプリケーション・
アクセス・サーバのメモリを節約できるだろう。ここでクライアントは、時間ｔ
３での乗り物の位置を、（ｘ１＋δｘ３，ｙ１＋δｙ３）によって計算する。ア
プリケーション・アクセス・サーバはアプリケーション・オブジェクト・パケッ
トのヘッダ内の情報を、前のアプリケーション・オブジェクト・パケットの期限
が切れ削除できるかどうかを判定するのに使用する。図３では、ＡＯＳ２は４つ
のアプリケーション・オブジェクト・パケットＡＯＰ２１、ＡＯＰ２２、ＡＯＰ
２３及びＡＯＰ２４からなり、ここで最初のＡＯＰ２１は基準パケットであり続
く３つのアプリケーション・オブジェクト・パケットＡＯＰ２２、ＡＯＰ２３、
ＡＯ２４は増分パケットである。最後の増分はタイムスタンプｔ８を有している
。このようにＡＯＳ２は、ゲーム時間ｔ８迄のオブジェクト２の状態を記載して
いる。図３のＡＯＳ３は、オブジェクトを記載するのに十分な１つの基準アプリ
ケーション・オブジェクト・パケットＡＯＰ３１からなる。

【００６３】 新たなクライアントが入って来るのを許可する前に、アプリケーション・アク
セス・サーバは、好適な実施形態によれば、必要な地域幅の増加を見積もり、ネ
ットワーク内でこの帯域幅が利用できることを保証するのがよい。このようにす
る方法は当該技術分野では周知である。容量の問題が全く予期されなければ、こ
のステップは必要ではない。

【００６４】 図４は、本発明によるクライアントを実行するコンピュータの実施形態を示し
ている。コンピュータは、例えば、本発明によるアプリケーション・プログラム
１０３などのプログラムが実行される処理ユニット１０１を備えている。処理ユ
ニットはまた、アプリケーション・アクセス・サーバ（不図示）及びもしあれば
ネットワーク内の他のユニットと、通信ソフトウェア１０５によって通信する。
アプリケーション・プログラム１０３は、ネットワーク・アプリケーション・イ
ンタフェース１０７によって通信ソフトウェア１０５と通信する。ネットワーク
・アプリケーション・インタフェースは、アプリケーション・プログラムからの
アプリケーション・データを送信し受信する機能を有している。

【００６５】 コンピュータはまた、参加者が現在関係するゲームの一部の外観などのアプリ
ケーションについてのデータを表示する、画面１０９を備えている。アプリケー
ションにデータを入力するために、例えば、コンピュータにはキーボード１１１
、マウス１１３及び／又はジョイスティック１１５が接続されているのがよく、
それによりゲーム中のオブジェクトを移動させたり他のタイプの変更を入力でき
る。

【００６６】 クライアント・アプリケーション１０３は前記入力を受信し、それを処理して
その結果を画面１０９で、及び／又は例えばスピーカ及び／又は触覚型の（hapt
ic）表示手段によって表わす。またアプリケーションは、アプリケーション状態
データを前記入力に基づいてネットワーク・アプリケーション・インタフェース
１０７に送り、そこから該データはアプリケーション・アクセス・サーバに送ら
れる。

【００６７】 通信ソフトウェア１０５及びネットワーク・アプリケーション・インタフェー
ス１０７によって、アプリケーション１０３は、ゲーム・アクセス・サーバから
他のオブジェクトに関するアプリケーション状態情報も受信し、それを処理して
結果を画面１０９に表示する。

【００６８】 この実施形態では、ネットワーク・アプリケーション・インタフェース１０７
は２つの部分、すなわち、アプリケーション・プログラミング・インタフェース
１０７Ａとアプリケーション・アクセス・インタフェース（ＡＡＩ）１０７Ｂを
含んでいる。このやり方は、以下で検討するように、ネットワークＡＡＩ １０
７Ｂを実現するのに、マイクロソフト DirectPlayなどの標準的プログラム・モ
ジュールの使用を可能とする。

【００６９】 アプリケーション・アクセス・インタフェース（ＡＡＩ）１０７Ｂは、クライ
アント端末のソフトウェア・モジュールである。これはネットワーク・インタフ
ェースとネットワークＡＰＩ １０７Ａとの間の中間モジュールである。アプリ
ケーション・アクセス・インタフェース１０７Ｂは、アプリケーション・オブジ
ェクト・パケットと制御メッセージとを受信して終了し、アプリケーション・オ
ブジェクト・パケットのペイロードがネットワーク・アプリケーション・インタ
フェースに渡される前に、アプリケーション・オブジェクト・パケットのヘッダ
を削除する。該インタフェース１０７Ｂはまた、制御メッセージを解釈してそれ
らをＡＰＩ １０７Ａに渡すか又は直接処理する。ＡＡＩ １０７Ｂは、アプリ
ケーション・アクセス・サーバとの通信に必要であるが、クライアント・アプリ
ケーション・プログラム内では実施しない機能を働かせるよう処理する。従って
、本発明によるアプリケーション・アクセス・サーバとの使用のために開発され
たクライアントにとっては、それは必要ではないだろう。例えば、クライアント
がアプリケーション・オブジェクト・パケットにタイムスタンプを押す機能を有
していなければ、ＡＡＩがタイムスタンプを押すクロックを扱ってもよい。

【００７０】 アップストリーム方向において、ＡＡＩ １０７Ｂは、ＡＰＩ １０７Ａから
メッセージ及びオブジェクトを受信する。クライアントからのアプリケーション
・オブジェクトに関するデータは、アプリケーション・オブジェクト・パケット
形式に変換される。アプリケーション・オブジェクト・パケットは、アプリケー
ション・アクセス・サーバへの通信リンクによって送信される。

【００７１】 ＡＡＩ １０７Ｂはまた、アップストリーム・アプリケーション制御プロトコ
ル・メッセージ、特に、アプリケーション制御プロトコル・サブスクリプション
・メッセージを生成する。サブスクリプション及び他のアプリケーション制御プ
ロトコル・メッセージを設定するのに必要な情報は、ネットワークＡＰＩを介し
てアプリケーションから、及びアプリケーション・アクセス・サーバからの緊急
リスト・メッセージから抽出する必要がある。

【００７２】 物理的クライアント、例えばゲーム・コンソールが、いくつかのゲーム又はホ
スト、同じゲームにおいて数人の人間のプレーヤに関与してもよい。論理的アプ
リケーション・クライアントが、アプリケーション・アクセス・インタフェース
の１つのインスタンスに接続されたアプリケーションの１つのインスタンスに対
応するとき、各物理的アプリケーション・クライアントは、いくつかの論理的ア
プリケーション・クライアントを実行できる。本明細書におけるアプリケーショ
ン・クライアントは、論理的アプリケーション・クライアントに相当する。論理
的アプリケーション・クライアントを指し示すネットワーク・アドレスは、物理
的クライアントのＩＰアドレスにアプリケーション・アクセス・インタフェース
のポート番号を組合せたものとできる。

【００７３】 アプリケーション・プログラムが開発されるときにアプリケーション・アクセ
ス・サーバ・システムが考慮されると、最高の性能が発揮される。そうすれば、
データ受信の好ましい順番を示すサブスクリプションを決定する機能を、アプリ
ケーション・プログラムに含められる。ゲーム内での状況から、受信するプレー
ヤがメッセージの高い優先度を予測できないことが明らかであれば、メッセージ
が高い緊急度でコプレーヤ（co-player）に直接送られてもよい。例えば、ゲー
ムでプレーヤ１がプレーヤ２を追い回す状況を考える。プレーヤ２は何も警告無
しに突然プレーヤ１に攻撃される。プレーヤ２はプレーヤ１からのメッセージに
対して正しい優先度を設定することができないが、プレーヤ１は高い緊急メッセ
ージをプレーヤ２に送信できる。

【００７４】 ネットワークＡＰＩを開発するのに、例えば、マイクロソフト DirectPlay
ＡＰＩを使用してもよい。そしてＡＰＩは、出力をＡＣＰ及びＡＯＰ等にフォー
マットするよう要求され、DirectPlay サービス・プロバイダとして表わされて
もよい。マイクロソフト DirectPlay ＡＰＩを使用して、サブスクリプション
を抽出する異なった方法が、少なくとも２つある。サブスクリプションが、ロー
カルな参加者が列挙されたアプリケーション・オブジェクトについての更新を受
信する優先度を表わすべきものであることに注意されたい。DirectPlayの「プレ
ーヤ」はメッセージの送信及び受信ができるアプリケーション・エンティティで
あるので、本明細書でのアプリケーション・オブジェクトは、DirectPlayの表記
では「プレーヤ」と同様である。DirectPlayの「プレーヤ」は、人間のプレーヤ
によって制御されてもよく、あるいは自立型のゲーム・オブジェクトであっても
よい。

【００７５】 第１の方法では、DirectPlayの受信方法によって得られた情報が使用される。
DPRECEIVE_FROMPLAYERフラグを設定し、lpidFromパラメータを適切に指定するこ
とにより、この方法でlpidFromパラメータによって識別される「プレーヤ」から
の第１のメッセージを回収することができる。この情報はサブスクリプションを
作成するのにアプリケーション・アクセス・インタフェースによって使用され得
る。DirectPlay メッセージのキューに識別された「プレーヤ」からの入手可能
なメッセージが何もなければ、識別されたアプリケーション・オブジェクトを優
先度リストの最上位にすることは合理的であろう。

【００７６】 第２の方法ではDirectPlay送信方法が使用され、idToパラメータがメッセージ
を受信すべき「プレーヤ」又はプレーヤのグループを識別する。頻繁にメッセー
ジを受信する「プレーヤ」が、ローカルなプレーヤが現在対話しているアプリケ
ーション・オブジェクトに関連しているとみなすのが合理的である。

【００７７】 図５は、本発明により使用され得る通信スタックの例を示している。１つの通
信スタックが、図４に示したようなクライアントとアプリケーション・アクセス
・サーバとの間の通信に使用される。クライアント及びアプリケーション・アク
セス・サーバは、基本的に同じタイプのスタックを備えている。クライアントで
は最上位層のスタックが図４のアプリケーション・アクセス・インタフェース層
と通信し、アプリケーション・アクセス・サーバではアプリケーション・アクセ
ス・サーバ・ソフトウェアと通信するスタックが示されている。図５は、アプリ
ケーション・アクセス・サーバとネットワーク内の別のユニットとの間で使用す
る通信スタックも示している。この他のユニットは、例えば、別のアプリケーシ
ョン・アクセス・サーバ、あるいはアプリケーション・ロビー・サーバであり得
る。通信スタックはＯＳＩモデルに適合するように使用される。

【００７８】 クライアントの通信スタックは、クライアント内のアプリケーションプログラ
ミング・インタフェース１０７と通信する。最上位レベルのスタックは、ＡＣＰ
／ＡＯＰ層１０９である。このレベルは、図４のアプリケーション・アクセス・
インタフェース１０７によって処理される。

【００７９】 ＡＣＰ／ＡＯＰ層１０９から、アプリケーション・オブジェクト・データ又は
サブスクリプション情報等の情報を含む、ＡＣＰ／ＡＯＰパケットがリンク層１
１１に配信される。リンク・プロトコルは、例えばＰＰＰであり得る。反対方向
では、ＡＣＰ／ＡＯＰ層１０９は、アプリケーション・アクセス・サーバから受
信した情報パケットからヘッダ情報を削除し、アプリケーション状態をクライア
ント・アプリケーションに送る。ＡＣＰパケットはＡＡＩ内で終結され得る。サ
ブスクリプション自身は、クライアントがサブスクリプションを処理する機能を
有していればクライアント自身で処理される。

【００８０】 最下位の層はチャネル層１１３であり、チャネル・コーディング及び実際の物
理的接続を含んでいる。

【００８１】 アプリケーション・アクセス・サーバは、クライアントとの通信のために基本
的に同じタイプのスタックを含んでおり、チャネル層１１３’はクライアントの
チャネル層に相当する。チャネル層１１３’は、リンク層１１１’によってＡＣ
Ｐ／ＡＯＰ層１０９’に接続されている。

【００８２】 アプリケーション・アクセス・サーバのＡＣＰ／ＡＯＰ層１０９’は、ＡＯＰ
及びＡＣＰ情報を処理するように構成されているアプリケーション・アクセス・
サーバ・ソフトウェアと直接通信する。

【００８３】 アプリケーション・アクセス・サーバは、多くの異なったリンク・プロトコル
に対するインタフェースと共に形成され得る。理想的には、アプリケーション・
アクセス・サーバは、ＵＤＰ、ＴＣＰ及びＲＴＰを含むあらゆるリンク・プロト
コルを処理できるべきである。ＲＴＰは、音声及びビデオ・データの送信のため
に特別に開発されたプロトコルである。

【００８４】 リンク・プロトコルは、アプリケーション・アクセス・サーバからクライアン
トへのリンク上でのオーバヘッドが低く保たれるように設計されるべきである。
これは、例えば、ＩＰ／ＵＤＰ／ＲＴＰが使用されない適切なリンク・プロトコ
ルを用いること、あるいはＩＰ／ＵＤＰ／ＲＴＰヘッダの効率的な圧縮によって
行われ得る。リンク層は、レイテンシをより最小化し、アプリケーション・アク
セス・サーバにリンクの特性の情報を提供する必要がある。そのような情報には
、予期される帯域幅、ビット誤り率及びリンク・レイテンシが含まれる。

【００８５】 ここではアプリケーション転送プロトコルと呼ぶ、適切な転送プロトコル、Ａ
ＴＰがリンクで使用されるべきであるが、アプリケーション・オブジェクト・パ
ケット及びアプリケーション制御パケットが、リンク・プロトコルを介して直接
送信されてもよい。

【００８６】 ２つ以上のアプリケーション・アクセス・サーバ間での通信のために、ＩＰパ
ケットのストリームが、ローカル・アプリケーション・アクセス・サーバの出力
バッファ６５（図２参照）から、実行中のアプリケーションに参加している１つ
以上のリモート・アプリケーション・アクセス・サーバに送信される。ＴＣＰ又
はＵＤＰパケットとＴＣＰ又はＵＤＰペイロードとを含む各ＩＰパケットは、ア
プリケーション転送プロトコル（ＡＴＰ）パケットである。

【００８７】 ２つのアプリケーション・アクセス・サーバ間での通信のための通信スタック
の最上位のプロトコル層は、クライアントの通信スタックで使用されるものと同
様なＡＯＰ／ＡＣＰ層１１７である。アプリケーション・オブジェクト・パケッ
トは、極めて小さい、すなわち、４０バイト以下であるかもしれない。２つのア
プリケーション・アクセス・サーバ間での通信をより効率的にするため、いくつ
かのアプリケーション・オブジェクト・パケットはアプリケーション転送プロト
コル（ＡＴＰ）層に集められる。次の層はＴＣＰ又はＵＤＰ層１２１であり、最
下位層はＩＰ層１２３であるが、１２１、１２３の両方は当技術分野では周知で
ある。ＩＰ層から情報パケットがリモート・アプリケーション・アクセス・サー
バ・ユニットに送信される。出力バッファ・ユニット（図２の６５）は、ＡＴＰ
ペイロードとなるアプリケーション・オブジェクト・パケットを集めるソーティ
ング・バッファの組を有する。これらバッファの構造は、配布の方針によって決
定される。リモートアプリケーション・アクセス・サーバのそれぞれに対して、
１つのソーティング・バッファがあるかもしれない。

【００８８】 アプリケーション・オブジェクト・パケットは、更新すべきクライアントをリ
ストで表わすフィールドを含んでいてもよい。このフィールドは、アプリケーシ
ョン・オブジェクト・パケットを受信すべきアプリケーション・アクセス・サー
バ・ユニットのリストに変換される。アプリケーション・アクセス・サーバは、
クライアント番号をアプリケーション・アクセス・サーバの番号とを突き合わせ
るテーブルを有している。これは、全ての関連するアプリケーション・アクセス
・サーバ・ユニットが、結局は更新されることを意味する。そしてアプリケーシ
ョン・アクセス・サーバ・ユニットは、アプリケーション・オブジェクト・パケ
ットをそれらのローカル・クライアントに発送する。簡単なオプションの動作モ
ードとしては、全てのアプリケーション・アクセス・サーバ・ユニットが全ての
アプリケーション・データを受信する。

【００８９】 ローカル・アプリケーション・アクセス・サーバは、リモート・アプリケーシ
ョン・アクセス・サーバを介してリモート・クライアントに送信する必要がある
、アプリケーション・オブジェクト・パケットを識別する。このため、ローカル
・アプリケーション・アクセス・サーバのアプリケーション状態レシーバがスキ
ャンされ、new_client_dataフラグが設定されたアプリケーション・オブジェク
ト・パケットが見つけられる。アプリケーション・オブジェクト・パケット・ヘ
ッダは、そのアプリケーション・オブジェクト・パケットが送信されるべき１つ
以上のクライアント・アドレスをリストで表わす受信者グループ・フィールドを
含んでいる。この受信者グループ・フィールドが検査される。クライアント・ア
ドレスは、リモート・アプリケーション・アクセス・サーバのアドレスに変換さ
れ、アプリケーション・オブジェクト・パケットのコピーが、受信者であるアプ
リケーション・アクセス・サーバ・ユニットに対応するソーティング・バッファ
に挿入される。受信しているアプリケーション・アクセス・サーバあるいはアプ
リケーション・アクセス・サーバのグループに属する受信者としてのクライアン
トだけが残るように、受信者グループ・フィールドが各アプリケーション・オブ
ジェクト・パケットのコピーに対して変更される。新たなnew_client_dataフラ
グが設定される。

【００９０】 アプリケーション・オブジェクト・パケットは、ゲーム・アプリケーションか
らのペイロードを含んでいる。アプリケーション・アクセス・サーバ・システム
は、内部のゲームのペイロード・フォーマットは読み取れない。従ってこのよう
なメッセージはアプリケーション・オブジェクト・パケット（ＡＯＰ）内に包含
される。ＡＯＰのヘッダは、アプリケーション・アクセス・サーバ・システムで
読み取られる。これはゲーム・ペイロードのタイムリーな配信のために必要な情
報を付加するのに使用される。

【００９１】 ここで検討した実施形態では、ＩＰ、ＴＣＰ、ＵＤＰ及びＲＴＰなどの標準的
インターネット・プロトコルに加え、以下の３つの非標準的プロトコルを使用す
る。 ・アプリケーション・オブジェクト・パケット（ＡＯＰ）は、ゲーム・データ
のコンテナである。ゲーム・アプリケーションからリモート・ゲーム・クライア
ント又はサーバに送信される全てのデータは、アプリケーション・アクセス・サ
ーバ・システムによって処理されるように、ＡＯＰに包含される。 ・アプリケーション制御プロトコル（ＡＣＰ）は、制御メッセージを送信する
のに使用される。制御メッセージは、アプリケーション・アクセス・サーバ・ユ
ニット、クライアント及びアプリケーション・ロビー・サーバの間で送信される
。 ・アプリケーション転送プロトコル（ＡＴＰ）は、アプリケーション・アクセ
ス・サーバ・ユニット間及びオプションとしてアプリケーション・アクセス・サ
ーバとクライアントの間で、集められたゲーム・データを送信するのに使用され
る。

【００９２】 アプリケーション・オブジェクト・パケットは、ゲーム・アプリケーションか
らのメッセージを含んでいる。アプリケーション・アクセス・サーバ・システム
は、ゲームの内部メッセージ・フォーマットは読み取れない。従ってこのような
メッセージは、アプリケーション・オブジェクト・パケット（ＡＯＰ）に包含さ
れる。ＡＯＰのヘッダは、アプリケーション・アクセス・サーバ・システムで読
み取られる。これはゲーム・ペイロードのタイムリーな配信のために必要な情報
を付加するのに使用される。

【００９３】 アプリケーション・メッセージは、アプリケーション・オブジェクトの状態を
完全に定義できるか、そうでなければ基準状態に対するアプリケーション・オブ
ジェクトを表わすことができる。従ってＡＯＰは、基準パケット（ＢＰ）と増分
パケット（ＩＰ）の２つのタイプがある。

【００９４】 アプリケーション・オブジェクト・パケットは、ヘッダと後続するゲームに特
定のペイロードからなり、ＡＯＰで使用されるヘッダ・フィールドは以下を含む
。 １）アプリケーション・オブジェクト番号 ２）ＡＯＰが生成されたときのゲームにおける時願を示すタイムスタンプ ３）オプションのパケット番号。オブジェクト番号及びタイムスタンプと組み
合わされて、パケットにユニークな識別子を形成する。同じゲーム・オブジェク
トに属するいくつかのＡＯＰが、同じタイムスタンプを有するときにだけ、パケ
ット番号が使用される。 ４）例えば、音声及び／又はビデオ情報が送信される場合、パケットがこのタ
イプの情報を含むかどうかを示すフラグが含まれ得る。 ５）ＡＯＰが基準パケットか増分パケットかを示すフラグ ６）ＡＯＰが増分パケットである場合、基準ＡＯＰへのポインタ。このポイン
タは、タイムスタンプと基準ＡＯＰのパケット番号から構成され得る。基準ＡＯ
Ｐは基本ＡＯＰ又は増分ＡＯＰのいずれでもよい。 ７）メッセージを受信すべきクライアントを表わすレコード。これは、クライ
アントをリストで表わすこと、あるいは予め定められたクライアント・グループ
を使用することで行われる。デフォルトでは全てのクライアントがデータを受信
する。緊急フィールドは、各受信クライアントあるいはグループ・クライアント
に関連する。このフィールドは、メッセージが緊急である場合に、受信者を警告
するのに使用される。３つの緊急ビットで十分であろう。 なお、緊急フィールドに設定され得るフラグは、 Forbidden：ＡＯＰはクライアント又はライアント・グループに送信すべき
でない Fair_Play：フェア・プレイ・モードを使用（下記） Very_Urgent：クライアントの優先度をオーバーライド Urgent：クライアントが警告される Normal：クライアントの優先度に従って配信される Not_Urgent：ベスト・エフォートで配信される 簡単なフォーマットとしては、 ＜エントリ数＞＜クライアント１＞＜クライアント１への緊急度＞ ＜クライアント２＞＜クライアント２への緊急度＞… であり、リスト内の後の項目は前の項目をオーバーライドする。 例えば、2,all Forbidden,client_3 Urgent というフィールドは、全てのクライアントはＡＯＰの受信を禁止されるが、
例外としてクライアント番号３はUrgentモードでＡＯＰを得ることを意味する。 ８）ペイロードのサイズ。

【００９５】 アプリケーション制御プロトコル（ＡＣＰ）は、ゲーム・クライアント、アプ
リケーション・アクセス・サーバ・ユニット及びアプリケーション・ロビー・サ
ーバ（ＡＬＳ）の間で制御メッセージを送信するのに使用される。ＡＣＰの概要
をここで説明する。ＡＣＰパケットはヘッダとメッセージ本体からなる。

【００９６】 ＡＣＰメッセージは以下のフィールドを含み得る。 １）ＡＣＰメッセージ・タイプ ２）メッセージが生成されたときのゲームにおける時間を示すタイムスタンプ ３）メッセージのサイズ ４）メッセージ本体 メッセージの送信元は高位のプロトコル・レベルで識別されることに注意され
たい。以下において、ＡＣＰを用いて送信されるメッセージの概要を説明する。

【００９７】 クライアントからアプリケーション・アクセス・サーバへのＡＣＰメッセージ
は以下のものを含み得る。 ・クライアント終了。アプリケーション・アクセス・サーバ管理システムは、
全てのレコードからそのクライアントを削除し、アプリケーション・ロビー・サ
ーバ（ＡＬＳ）に通知する。ゲームをやめていたら、クライアントはＡＬＳへ通
知するのを受け持つ。ＡＬＳは、例えば、最終スコアを送信して他のプレーヤに
通知することによって、終了したクライアントとの接続を終了させるのを受け持
つ。 ・サブスクリプション ・ゲーム・オブジェクト追加。新たなゲーム・オブジェクト番号がアプリケー
ション・アクセス・サーバで生成され、アプリケーション・アクセス・サーバの
メモリがクライアントからオブジェクト状態情報を受信するために割り当てられ
る。 ・ゲーム・オブジェクト削除。更新を受信するリストに記された、全てのクラ
イアント及びアプリケーション・アクセス・サーバ・ユニットが最後の更新を受
信した後に、全てのアプリケーション・アクセス・サーバのメモリからオブジェ
クトが削除される。 ・オブジェクトの推定レイテンシ送信。この要求はオブジェクト番号のリスト
を含む。アプリケーション・アクセス・サーバは、オブジェクトに対してエンド
ツーエンドで推定されたレイテンシを送信することで応答する。クライアント・
アプリケーションは、レイテンシを隠すのに推定値を使用する。 ・オブジェクト・グループの定義。そうでなければＡＯＰフィールド内のクラ
イアントとのリンクによって送信しなければならない、オブジェクト番号の長い
リストに短い名前を付けられるので、オブジェクト・グループは有用である。ア
プリケーション・アクセス・サーバは、クライアント・グループ情報を格納し、
クライアント・グループをクライアントのリストのエイリアス（別名）として扱
う。メッセージのフォーマットは、 メッセージ・タイプ＝クライアント・グループ定義＜クライアント・グルー
プ名＞＜クライアントのリスト＞ などでよい。 ・時間基準送信。このメッセージは、アプリケーション・アクセス・サーバか
ら基準時間をダウンロードするのに使用される。

【００９８】 アプリケーション・アクセス・サーバからクライアントへのＡＣＰメッセージ
は、以下のものを含み得る。 ・緊急リスト。このメッセージは、未読の緊急ＡＯＰが残っている場合、クラ
イアントを警告するのに使用される。アプリケーション・アクセス・サーバは、
ＡＯＰ受信者リスト上に現在のクライアントを有する、全ての未読ＡＯＰをスキ
ャンする。緊急リストのフォーマットは、 ＜緊急クラス １＞＜オブジェクト番号のリスト＞＜緊急クラス ２＞＜オ
ブジェクト番号のリスト＞…以下同様、などでよい。 ・レイテンシ推定。これは以下のようなエントリのセットからなる。すなわち
、 ＜ゲーム・オブジェクト番号＞＜アップストリーム・レイテンシ＞＜アップ
ストリーム・レイテンシ変数＞＜ダウンストリーム・レイテンシ＞＜ダウンスト
リーム・レイテンシ変数＞ である。「不明」の記号を最初以外のフィールドに
使用できる。 ・オブジェクト・グループ番号確認。アプリケーション・アクセス・サーバは
、クライアントから「オブジェクト・グループ定義」メッセージを既に受信して
いる。これでグローバル・オブジェクト番号が割り当てられたのを確認する。メ
ッセージ本体は、 ＜グローバル・オブジェクト・グループ番号＞＜クライアントのオブジェク
ト・グループ名＞ を含むであろう。 オブジェクト番号を割り当てる簡単な方法は以下のようなものである。 合計でＮ個のアプリケーション・アクセス・サーバ・ユニットが動作中であると
想定する。全てのアプリケーション・アクセス・サーバ・ユニットを列挙する。
番号ｋのアプリケーション・アクセス・サーバが新たなオブジェクト番号を要求
したら、｛ｋ，Ｎ＋ｋ，２Ｎ＋ｋ，３Ｎ＋ｋ，…｝から最も小さい未使用のオブ
ジェクト番号を割り当てる。 ・クライアント・グループ番号確認。アプリケーション・アクセス・サーバは
、クライアントから「クライアント・グループ定義メッセージを既に受信してい
る。これでグローバル・クライアント・グループ番号が割り当てられたのを確認
する。メッセージ本体は、 ＜グルーバル・クライアント・グループ番号＞＜クライアントのクライアン
ト・グループ名＞ を含むであろう。 クライアント・グループ番号を割り当てるのに、グローバル・オブジェクト・
グループ番号を割り当てるのと同じアルゴリズムが使用できる。 ・クロック同期。アプリケーション・アクセス・サーバは、以下のフォーマッ
トに従って時間基準を送信する。すなわち、 ＜クライアント時間＞＝＜時間＞＋＜クライアントのクロックのレイテンシ
＞ である。 クライアントは、受信した一連のクロック同期メッセージに従って、ローカル
・クロックを調整するアルゴリズムを有している。

【００９９】 あるアプリケーション・アクセス・サーバから別のサーバへのＡＣＰは以下の
ものを含み得る。 ・集められたサブスクリプション。送信するアプリケーション・アクセス・サ
ーバに属するクライアントが見る必要のあるオブジェクト、すなわち、送信する
アプリケーション・アクセス・サーバに情報が送信されるべきオブジェクト、を
示す集められた優先度リスト。このリストは単純なクライアント優先度リストと
同様なフォーマットである。これは有効なローカル・クライアント優先度リスト
を合算し、重複部分を削除することで組み立てられる。 ・再送要求。このメッセージは、単純な優先度リストと同様なフォーマットで
あり、リストに示されたオブジェクトの状態を再送する要求であると解釈される
。 ・オブジェクト・グループ定義。オブジェクト・グループ定義は、アプリケー
ション・アクセス・サーバ間で配布され得る。オブジェクト番号の長いリストに
対してグローバルな名前を使用することで、トラフィックを削減するのを助長す
る。 ・クライアント・グループ定義。クライアント・グループ定義は、アプリケー
ション・アクセス・サーバ間で配布され得る。

【０１００】 アプリケーション・アクセス・サーバからアプリケーション・ロビー・サーバ
へのＡＣＰメッセージは以下のものを含み得る。 ・クライアントが終了した。このメッセージは、クライアントが自発的にゲー
ムから抜けたときに送信される。 ・クライアントのタイムアウト。クライアントとの通信が長時間ないとき、あ
るいはクライアントへのリンクが閉鎖されたときに、アプリケーション・アクセ
ス・サーバはＡＬＳにメッセージを送信し得る。ＡＬＳは、ゲームからのクライ
アントの削除などの更なる動作を決定する。

【０１０１】 ＡＬＳはクライアントとして動作できる。ＡＬＳは例えば、ゲームのスコアを
維持するゲーム・オブジェクトを制御するかもしれない。ＡＬＳのポートは、Ｔ
ＣＰ／ＩＰなどの「リンク」プロトコルを使用するクライアントとして、ＡＡＳ
に接続される。従ってＡＬＳは、クライアントと同じメッセージを使用できる。
ＡＬＳからＡＡＳへの他のメッセージを以下にリストする。 以下のものを含むアプリケーション設定情報。 ・ＡＬＳを識別するポート番号を含むネットワーク・アドレス ・ゲームをユニークに識別するＵＲＬ ・ゲームに参加している他のアプリケーション・アクセス・サーバ・ユニット
のＩＰアドレス ・オプションとして、列挙されたゲーム・オブジェクトのリスト。各オブジェ
クトに対して、状態を格納するのを受け持つアプリケーション・アクセス・サー
バが指定される。誰が状態を更新するのを認可されたかも指定されてもよい。 ・オプションとして、格納すべき最初のゲーム状態。 ・タイムアウトなどのオプションのデータ指定制御方針。 ・アプリケーション・アクセス・サーバ追加。新たなアプリケーション・アク
セス・サーバのネットワーク・アドレス、番号及びクライアント・リストが指定
される。 ・アプリケーション・アクセス・サーバ削除。削除すべきアプリケーション・
アクセス・サーバの番号が指定される。 ・クライアント追加。これは新たなクライアントのネットワーク・アドレスを
含み、オプションとして、新たなクライアントによって制御される新たなゲーム
・オブジェクトの初期状態も含まれる。 ・クライアント削除。アプリケーション・アクセス・サーバ・システムは、ゲ
ームからクライアントを削除する。 ・クライアント状態変更。このメッセージは、ゲーム・オブジェクトを制御す
るクライアントの権限を変更するか、あるいはクライアントを別のアプリケーシ
ョン・アクセス・サーバと結びつける。フォーマットは、 ＜クライアント番号＞＜アプリケーション・アクセス・サーバ番号＞＜オブ
ジェクト番号＞ などであり得、ここでオブジェクト番号は、クライアントによ
って制御されるゲーム・オブジェクトを示す。

【０１０２】 アプリケーション転送プロトコル（ＡＴＰ）は、アプリケーション・オブジェ
クト・パケット（ＡＯＰ）及びアプリケーション制御プロトコル（ＡＣＰ）メッ
セージを転送するのに使用される。ＡＴＰは、ペイロードに一連のＡＯＰ及びＡ
ＣＰメッセージを有し、アプリケーション・アクセス・サーバ・ユニット間で集
められたデータを送信するのに主に使用される。アプリケーション・アクセス・
サーバ・ユニットは、通常はＩＰ／ＵＰＤ／ＡＴＰのプロトコル・スタックを用
いて通信する。このためＡＴＰはＲＴＰプロトコルと論理レベルが同じである。

【０１０３】 ＡＴＰヘッダは、 ・ゲームを識別するＵＲＬ、 ・ＡＯＰあるいはＡＣＰの最先のタイムスタンプ、 ・ＡＯＰあるいはＡＣＰの最後のタイムスタンプ、 ・ＡＯＰ及びＡＴＰメッセージの数、を含んでいる。

【０１０４】 ＡＴＰは通常、説明したように、アプリケーション・アクセス・サーバ間での
通信にのみ使用される。クライアントとアプリケーション・アクセス・サーバと
の間の接続の帯域幅が十分に大きければ、これらの接続にも使用され得る。

【０１０５】 ＴＣＰ／ＩＰ及び／又はＵＰＤ／ＩＰなどの従来のプロトコルは、アプリケー
ション・ロビー・サーバ及び他のアプリケーション・アクセス・サーバ・ユニッ
トとの通信に使用される。以下に示す理由で、ＴＣＰ／ＩＰはゲームを設定する
のに使用される必要があり、ＵＤＰ／ＩＰはリアルタイムのゲーム・データを送
信するのに使用される必要がある。すなわち、ＴＣＰの再送及び再発注は遅すぎ
てゲーム・アプリケーションには複雑である。ＴＣＰの再発注は、古すぎるデー
タを配信する目的のため、直近の更新の配信が遅延するかもしれない。も早必要
でないデータの再送は明らかに無駄である。アプリケーション・アクセス・サー
バ・ユニットは、正確な優先度を知っており、必要であればいくつかの送信元か
らの再送を要求できる。

【０１０６】 タイムスタンプを送信するのにＲＴＰが使用されてもよいが、ＲＴＰは音声及
びビデオ・ストリームのために設計されておりゲームのストリームには最適では
ない。しかしながらＲＴＰは、ゲームに関連する音声及びビデオ・ストリームを
運ぶのには使用できる。

【０１０７】 「フェアプレイ・モード」をシステムで実施することもできる。このモードで
は、アプリケーション・アクセス・サーバ・ユニットは、重要なアプリケーショ
ン情報の配信を同期させ、そのためこれらの更新は関連する全てのクライアント
で同時に受信される。このモードは競争に使用できる。

【０１０８】 アプリケーション・ロビー・サーバは、アプリケーションを設定する間に、フ
ェアプレイ・モードが利用可能かどうか決定する。フェアプレイ・モードが許可
されたら、送信クライアントは、送信されたＡＯＰそれぞれについて、フェアプ
レイ配信を使用すべきかどうか決定する。これはＡＯＰの緊急フィールド内のFa
ir_Playフラグを設定することにより行われる。アプリケーション・アクセス・
サーバ・システムはここで、ＡＯＰを全てのクライアントに「同時に」配信する
のを受け持つ。この要件は他の全てのクライアント優先度をオーバーライドする
。

【０１０９】 これに対する技術的解決策は、「バケット同期（bucket synchronization）」
方法である。複数のアプリケーション・アクセス・サーバ・ユニットが、クライ
アントを固定の絶対遅延で更新するよう合意する。速く到着した更新は、合意し
たタイムスロットまで待たねばならない。この方法は、システム内の全体の遅延
が増加するという欠点がある。フェアプレイ・モードが、代替的にゲーム・アプ
リケーションで処理されてもよい。このモードでは、クライアント・アプリケー
ションは、合意した絶対遅延を達成するのにパケットをどれだけ遅延させるべき
かを計算するのに各ゲーム・オブジェクトのタイムスタンプを用いて、受信した
ゲーム・データに合意した遅延を適用する。

【０１１０】 図６は、本発明によるアプリケーション・アクセス・サーバ１５０の別の実施
形態を示している。特に言及しない限り、この実施形態は上記で検討したものと
同様である。この実施形態では、アプリケーション・アクセス・サーバの通信機
能は、１つ以上のアプリケーション・ルータ１５２とアプリケーション・サーバ
１５４とに分離されている。アプリケーション・サーバ１５４は、図１に関して
説明したような、アプリケーション状態レコード１５５及びクライアント優先度
リスト１６１を備えている。アプリケーション・ルータ１５２は、以下でより詳
細に説明する、クライアントのアプリケーション・プログラミング・インタフェ
ース（ＡＰＩ）１７２によって１つ以上のクライアントと通信する。各アプリケ
ーション・アクセス・サーバ１５０は、１つ以上のアプリケーション・ルータ１
５２をサービスする１つのアプリケーション・サーバ１５４を備えている。アプ
リケーション・ルータ１５２も、別のアプリケーション・アクセス・サーバ（不
図示）内のアプリケーション・ルータなどのネットワーク内の他のノードと通信
する。好ましくは、アプリケーション・サーバ１５４及びアプリケーション・ル
ータ１５２は、各々をそれらの特定の機能について最適化すべく、別々のハード
ウェアとして実現される。代替的には、それらに割り当てられた別々のプロセッ
サ・リソースを有していてもよい。特に、アプリケーション・ルータは、中断は
クライアント・アプリケーションのリアルタイム性能を悪化させるよう影響する
ので、中断せずに動作することが必要である。

【０１１１】 上記では、あるクライアントに接続されたアプリケーション・アクセス・サー
バをそのクライアントのローカル・アプリケーション・アクセス・サーバとし、
そのクライアントをアプリケーション・アクセス・サーバのローカル・クライア
ントとした。同様に、クライアントをサービスするアプリケーション・サーバ及
びアプリケーション・ルータを、クライアントのローカルなアプリケーション・
サーバ及びアプリケーション・ルータとする。

【０１１２】 アプリケーション・サーバは、クライアントからアプリケーション・ルータを
通じて基本オブジェクト（下記参照）と制御メッセージを含むＡＴＰパケットを
受信する。基本オブジェクトを、例えば、アプリケーション状態データベースに
入れることによって処理する前に、アプリケーション・サーバは送信クライアン
トがそのオブジェクトを更新するのを許可されていることをチェックする。クラ
イアントがオブジェクトを更新するのを認可されていない場合、そのオブジェク
トは拒絶され、送信クライアントはエラー・メッセージを受信するであろう。制
御メッセージを処理する前に、アプリケーション・サーバは、送信クライアント
が示された動作を要求するのを許可されていることをチェックし、そうでなけれ
ば制御メッセージを拒絶し、オプションとしてエラー・メッセージを送信クライ
アントに返す。例えば、送信クライアントがオブジェクト・グループの削除を要
求した場合を考える。このグループはコンテント・サーバによって作成されたも
のかも知れないが、該コンテント・サーバは、ゲーム状態の管理と標準的クライ
アントＡＰＩによるアプリケーション・アクセス・サーバとの通信とを受け持つ
、特別なクライアントである。コンテント・サーバは、ゲーム・アクセス・サー
バにクライアントがオブジェクト・グループを削除するのを禁止する認可規則を
アップロードした。この場合、アプリケーション・サーバは、オブジェクト・グ
ループの削除を要求する制御メッセージを拒絶するであろう。

【０１１３】 この認可チェックは、クライアントが実行を許可された動作の種類を示す、認
可規則のテーブルを用いて実行される。認可テーブルはクライアントあるいは初
期化ファイルを使用する制御ユニットによって設定される。

【０１１４】 もしそのように認可されていれば、クライアントは、オブジェクト・グループ
の作成を要求できる。クライアントはまた、メンバーの追加、メンバーの削除及
びオブジェクト・グループの削除を行える。オブジェクト・グループのメンバー
は、オブジェクトとオブジェクト・グループである。オブジェクト・グループに
ついてのそのような動作の要求は、アプリケーション・ルータからセッションに
参加している全てのアプリケーション・サーバにブロードキャストされる制御メ
ッセージとして、クライアントによって送信される。オブジェクト・グループは
、オブジェクト識別子と同じフォーマットを有する識別子によって識別される。
各アプリケーション・サーバは、各アプリケーション・セッションについて、そ
のセッションの間に作成されたオブジェクト・グループを格納する、オブジェク
ト・グループ・データベース１６２を含んでいる。オブジェクト・グループ・デ
ータベース１６２は、各オブジェクト・グループに対して、少なくとも以下のフ
ィールドを格納する。すなわち、１）オブジェクト・グループ識別子、２）オブ
ジェクト・グループのメンバーのリスト、３）オブジェクト・グループの親のリ
スト、である。オブジェクト・グループＡの親は、メンバーとしてオブジェクト
・グループＡを持つオブジェクト・グループである。オブジェクト・データベー
スは、前の実施形態におけるオブジェクト・データベースとして構築されるが、
各オブジェクトについて、そのオブジェクトに対する親であるオブジェクト・グ
ループのリストがある。

【０１１５】 アプリケーション状態の一部を形成すべき、クライアントから又は他のアプリ
ケーション・アクセス・サーバから受信したオブジェクトは、アプリケーション
・ルータ１５２からアプリケーション・サーバ１５４に送られ、アプリケーショ
ン状態レコード１５５に格納される。クライアントから又は他のアプリケーショ
ン・アクセス・サーバから受信したサブスクリプション情報は、アプリケーショ
ン・サーバ１５４に送られ、クライアント優先度リスト１６１に格納される。

【０１１６】 サイト・マネージャ１７４は、１つ以上のアプリケーション・ルータ１５２及
びアプリケーション・サーバ１５４をそれぞれ備える、１つ以上のアプリケーシ
ョン・アクセス・サーバの機能を、好ましくはアプリケーション・ルータ１５２
への接続を通じて制御する。サイト・マネージャはまた、サイトを制御するのに
標準的プロトコルＳＮＭＰ（簡易網管理プロトコル）を使用できる。

【０１１７】 従って、１つのサイトは、１つのサイト・マネージャと１つのサイト・マネー
ジャによって制御されるいくつかのアプリケーション・アクセス・サーバ１５０
とを備えている。サイト・マネージャ１７４のメイン・タスクは、接続管理、ク
ライアント接続、リソース管理、アプリケーション・サーバ及びルータの構成、
許可制御、クライアントの認可、サイトの時間同期、ネットワーク管理と、負荷
、アプリケーションサーバ及びアプリケーション・ルータの状態の監視である。

【０１１８】 サイト・マネージャはオプションとして、クライアントからの制御メッセージ
を含むアプリケーション転送プロトコル（ＡＴＰ）パケットを受信する。この実
施形態におけるＡＴＰは、以下で説明するが、先の実施形態に関して説明したＡ
ＴＰとは異なっていることに注意されたい。制御メッセージを処理する前に、Ｓ
Ｍは送信クライアントが示された動作を要求するのを許可されていることをチェ
ックし、もしそうでなければ制御メッセージは拒絶され、送信クライアントはオ
プションのエラー・メッセージを受信する。この認可チェックは、クライアント
が行うのを許可された動作の種類を示す、認可規則のテーブルを用いて実行され
る。認可テーブルは、クライアントあるいは初期化ファイルを使用するロビー・
アクセス・サーバ１７８によって設定される。

【０１１９】 アプリケーション・ロビー・サーバ１７６及び１つ以上のロビー・アクセス・
サーバ１７８への接続に、１つ以上のアクセス・ロビー・サーバ１７８が提供さ
れる。アプリケーション・ロビー・サーバは、図２に関して検討した。１つある
いは複数のロビー・アクセス・サーバ１７８は、サイト・マネージャ１７４に接
続されている。ロビー・アクセス・サーバは、ロビー・サーバからのゲーム・セ
ッションを処理し、ゲーム・セッションをアレンジし管理する。これにはロビー
・サーバの登録及び認可並びに清算を含む。該サーバはまた、データベース内に
ゲーム及びロビー・サーバについての情報を保持する。アプリケーション通信シ
ステムの監視及び保全に、中央制御ユニット（不図示）が使用されてもよい。

【０１２０】 アプリケーション通信システムは、１つ以上の相互接続されたサイト及びロビ
ー・アクセス・サーバを備えている。アプリケーション通信システムの監視及び
保全に、中央制御ユニット（不図示）が使用されてもよい。

【０１２１】 ロビー・アクセス・サーバ１７８は、どのアプリケーション・ロビー・サーバ
が、特定のゲームあるいは特定のアプリケーション・アクセス・サーバにクライ
アントを追加するのを許可されているのか、などのネットワーク内にあるアプリ
ケーション・ロビー・サーバについての情報を含む、データベース１８０を備え
ている、あるいはそれに接続されている。アプリケーション・ロビー・サーバ１
７６は、各クライアントについての認可プロファイルなどのクライアント・デー
タを含む、データベース１８２を備えて、あるいはそれに接続されていてもよい
。

【０１２２】 サイト・マネージャと１つ又は複数のアプリケーション・サーバとの間の通信
は、セッションの追加及び削除、セッションについてのクライアントの追加及び
削除を含む制御を行う。サイト・マネージャと１つ又は複数のアプリケーション
・ルータとの間の通信は、上記並びにクライアントに対するログイン許可と同様
である。また、エラー・メッセージは、アプリケーション・サーバ又はアプリケ
ーション・ルータからサイト・マネージャに送信される。

【０１２３】 好ましくは、ローカル・アプリケーション・ルータ１５２は、クライアント、
ネットワーク内の他のアプリケーション・ルータ又は他のユニットから受信した
、ストリーム・オブジェクト及び基本オブジェクトの両方を扱える。クライアン
トは、基本オブジェクトの更新それぞれのコピー１つを、ローカル・アプリケー
ション・アクセス・サーバに送信する。オブジェクトは例えば、プレーヤのアバ
ター（化身）の状態を含んでいる。基本オブジェクトは、セッションに関係する
全てのアプリケーション・サーバに送られる。クライアント又は他のアプリケー
ション・アクセス・サーバからのアプリケーション・ルータによって受信された
基本オブジェクトは、関連するアプリケーション・サーバのアプリケーション状
態レコードに格納される。ストリーム・オブジェクトの受信望むプレーヤは、ロ
ーカル・アプリケーション・サーバにサブスクリプションを発信する。アプリケ
ーション・サーバは、サブスクリプションのパラメータに従って、ローカル・ア
プリケーション状態レコードから一連のオブジェクトの更新を送信する。ストリ
ーム・オブジェクトは、アプリケーション・サーバに格納されていない。基本オ
ブジェクト及びストリーム・オブジェクトについて以下でより詳細に検討する。
アプリケーション・ルータは、アプリケーション転送プロトコル（ＡＴＰ）パケ
ットを、クライアント、ローカル・アプリケーション・サーバ、他のアプリケー
ション・ルータ及びオプションでローカル・サイト・マネージャから受信する。
ＡＴＰパケットは、ＵＤＰ／ＩＰなどの他のネットワーク・プロトコルによって
転送される。他のアプリケーション・ルータは、リモート（リモート・アプリケ
ーション・アクセス・サーバに属している）か、ローカル（アプリケーション・
ルータと同じアプリケーション・アクセス・サーバに属している）のいずれかで
ある。受信されたＡＴＰパケットには異なる３つのタイプがある。すなわち、ア
プリケーション・オブジェクト・パケット（ＡＯＰ）の基本オブジェクト及びス
トリーム・オブジェクト、アプリケーション制御パケット（ＡＣＰ）の制御デー
タ、及びクライアント・メッセージ・パケット（ＣＭＰ）のクライアント・メッ
セージである。ＡＴＰパケットは、ユニキャスト又はマルチキャストによって、
受信クライアント、アプリケーション・ルータ、ローカル・アプリケーション・
サーバあるいはローカル・サイト・マネージャにルーティングされるか又は削除
される。異なったルーティングの場合を表に示す。受信するアプリケーション・
ルータに宛てられた制御パケットは、ルーティングされない。

【０１２４】 アプリケーション・ルータのルーティング・テーブルを以下に示す。

【０１２５】

【０１２６】 ストリーム・オブジェクトは、アプリケーション・サーバには格納されない。
クライアントは通常、それらを仮想世界において移動するアイテムの位置を送信
するのに使用する。それらはネットワークを通じて非常に高速で転送され得る。
ストリーム・オブジェクトの直近のバージョンだけが、受信クライアントにとっ
て重要であると想定される。ストリーム・オブジェクトの処理は、フロー制御の
ためにアプリケーション・ルータによって意図的に抜かされることがあるので、
通常は当てにならない。アプリケーション・ルータによって受信された全てのス
トリーム・オブジェクトは、そのストリーム・オブジェクトを申込んだ全てのロ
ーカル・クライアント、又はそのストリーム・オブジェクトを含むストリーム・
オブジェクト・グループに送られる。以下で検討するように、これらのオブジェ
クトはアプリケーション・サーバで処理されないので、アプリケーション・ルー
タ１５２も、優先度又はサブスクリプション情報を備えている。

【０１２７】 通常、例えば、実行中の特定のマルチプレーヤ・セッションなどのセッション
に加わるのを望むクライアントは、アプリケーション・ロビー・サーバ１７６に
インターネットによって接続する。アプリケーション・ロビー・サーバは、実行
中のアプリケーション・セッションについての情報を提供し、普通はクライアン
トに新たなセッションを作成することを許可し、加入するように他のクライアン
トを招待する。クライアントは、アプリケーション・ロビー・サーバ１７６に、
セッションの作成、削除、加入又はやめる要求を送信できる。アプリケーション
・ロビー・サーバは、そのようなセッション制御要求を受け取ると、その要求を
ロビー・アクセス・サーバ１７８に送る。セッションの作成が要求されると、ロ
ビー・アクセス・サーバ１７８は、アプリケーション・セッション識別子を発信
することにより応答する。セッションを削除したりクライアントの加入又は削除
などの要求に対しては、アプリケーション・ロビー・サーバ１７６は、ロビー・
アクセス・サーバ１７８に送信される要求にアプリケーション・セッション識別
子を含める。ロビー・アクセス・サーバ１７８は、アプリケーション・アクセス
・サーバ・システム内で要求された動作に合うリソースが使用可能であるかを調
査することによって応答する。リソースが使用可能であれば、ロビー・アクセス
・サーバ１７８は要求された動作を実行する。

【０１２８】 セッションの作成が要求されたら、ロビー・アクセス・サーバ１７８は、セッ
ションをサービスするサイトのセットを選択し、関連するサイト・マネージャ１
７４に、セッション識別子を含み、適切なアプリケーション・アクセス・サーバ
１５０でセッションが開始されることを要求する制御メッセージを送信する。

【０１２９】 セッションの削除が要求されたら、ロビー・アクセス・サーバ１７８は、セッ
ションを実行しているサイトのサイト・マネージャ１７４に、セッション識別子
を含み、セッションが削除されることを要求する制御メッセージを送信する。

【０１３０】 クライアントの加入が要求されたら、アプリケーション・ロビー・サーバ１７
６は、少なくともクライアント１７０のネットワーク・アドレス、セッション識
別子、及びオプションとしてサイト識別子を、ロビー・アクセス・サーバ１７８
への制御メッセージに含める。ネットワーク・アドレスは、例えば、クライアン
ト・アプリケーション処理のＩＰアドレス及びポート番号でよい。ロビー・アク
セス・サーバ１７８は、適切なサイトを選択し、サイトのサイト・マネージャ１
７４に、クライアント１７０がゲーム・セッションに加わることを要求する制御
メッセージを送信する。この制御メッセージは、クライアント１７０のネットワ
ーク・アドレスと、サイトのサイト・マネージャ１７４へのセッション識別子と
を少なくとも含んでいる。サイト・マネージャは、適切なアプリケーション・ア
クセス・サーバと、適切なアプリケーション・ルータとを、クライアントをサー
ビスするのを受け持つべきユニット内で選択し、クライアントをゲームに加入す
るよう招待する制御メッセージをクライアントに送信する。クライアントをサー
ビスするアプリケーション・ルータのネットワーク・アドレスとパスワードとが
、そのメッセージには含まれている。クライアント１７０は、パスワードを含む
制御メッセージで関連するアプリケーション・アクセス・サーバ１５０に連絡す
る。アプリケーション・アクセス・サーバ１５０は、ローカル・クライアント・
データベースにクライアント１７０を含め、クライアントはゲームデータを送信
及び受信して処理を続行することができる。

【０１３１】 代替的には、サイト・マネージャ１７４は、ロビー・アクセス・サーバ１７８
にクライアント１７０をサービスするアプリケーション・ルータ１５２のネット
ワーク・アドレスを送信することができ、ロビー・アクセス・サーバ１７８は、
アプリケーション・ロビー・サーバ１７６にネットワーク・アドレスとパスワー
ドとを送る。アプリケーション・ロビー・サーバ１７８は、ネットワーク・アド
レスとパスワードとを、上記で説明したように、関連するアプリケーション・ア
クセス・サーバに接続する、要求クライアントに送る。

【０１３２】 図６には、バッファ、ソフトウェア処理等が何も示されていないが、本発明の
アプリケーション・アクセス・サーバを実現するためにはそれらが必要なことは
当業者には理解できるであろう。

【０１３３】 クライアント１７０、アプリケーション・アクセス・サーバ１５０及びサイト
・マネージャ１７４は、アプリケーション転送プロトコル（ＡＴＰ）を用いて通
信する。ＡＴＰパケットは通常、先の実施形態で検討したように、ＵＤＰパケッ
トのペイロードとして運ばれる。この実施形態で使用されるＡＴＰを以下で説明
する。アプリケーション転送プロトコルは、１）複合（コンパウンド）ＡＴＰパ
ケット、２）標準ＡＴＰパケット２つのプロトコル・レベルを含んでいる。

【０１３４】 複合ＡＴＰパケットは、ソース・ヘッダといくつかの標準ＡＴＰパケットを含
んでいる。ソース・ヘッダは以下のようなフィールドを含んでいる。 １）アプリケーション・セッション識別子、 ２）送信クライアントを含むクライアント識別子、 ３）保証された送信のプロトコルで使用され、確認フィールドとパケット・カ
ウンタを含む、オプション・フィールド。

【０１３５】 標準ＡＴＰパケット（以下では「ＡＴＰパケット」とも呼ぶ）は、ＡＴＰヘッ
ダ、ＡＴＰオプション・ヘッダ、オプションのＡＴＰターゲット・ヘッダ及びＡ
ＴＰコンテント・パケットからなる。

【０１３６】 ＡＴＰヘッダは、以下のフィールドを含み得る。 １）コンテント・パケットのタイプとコンテント・パケット内のオプション。
フィールドの存在を示すフラグのセットである、タイプ・フィールド。コンテン
ト・パケットのタイプは、制御メッセージ、クライアント・メッセージ、基本オ
ブジェクトあるいはストリーム・オブジェクトである。メッセージの意図した受
信者を、タイプ・フィールドに示し得る。 ２）ＡＴＰパケットが信頼できる又は信頼できないモードで送られたのかを示
すフラグ、 ３）ターゲット・ヘッダが存在するかを示すフラグ、 ４）ＡＴＰオプション・ヘッダの存在及び内容を示すフラグのセット、 ５）コンテント・パケットのサイズを示すフラグ。

【０１３７】 ＡＴＰオプション・ヘッダは、以下のオプション・フィールドからなる。 １）セッション識別子、 ２）クライアント識別子、 ３）オブジェクト識別子。

【０１３８】 ＡＴＰオプション・ヘッダは、コンテント・パケットを識別するのに使用され
る。基本オブジェクトに関連するアプリケーション・ペイロードは、例えば、コ
ンテント・パケットで送信されてもよい。ＡＴＰオプション・ヘッダは、以下で
説明する相対アドレッシング・システムを使用する基本オブジェクトを識別する
のに使用される。

【０１３９】 ＡＴＰターゲット・ヘッダＴＨは、ＡＴＰパケットの直接アドレッシングに使
用される。受信者のＡＴＰアドレスは、ＡＴＰターゲット・ヘッダに示されてい
る。ＴＨの最初の位置はＴＨのサイズを保持するバイトである。ＴＨは、メッセ
ージの意図する受信者を示すクライアント識別子のリスト、あるいはストリーム
・オブジェクト・キーのリストのいずれかである、動的アドレス・フィールドの
アレイからなる。キーは、送信者によって送信され得るストリーム・オブジェク
トの属性である。クライアントは、所望するストリーム・オブジェクトのオブジ
ェクト識別子がわからなくても、特定のキーを運ぶ所望するストリーム・オブジ
ェクトを申込むことができる。クェーク（Quake）のようなゲームでは、異なっ
た部屋に属するストリーム・オブジェクトを選択するのにキーを使用できる。ス
トリーム・オブジェクトは、ゲームにおけるアバターの位置を送信するのに使用
される。ゲームの各部屋にキーが割り当てられている。ストリーム・オブジェク
トを送信しているプレーヤは、アバターが位置する部屋に対応するキーを加える
。データを受信しているプレーヤは、彼らが興味を持つ部屋に対応するキーと共
にストリーム・オブジェクトを申込む。ストリーム・オブジェクト・キーは、代
替的に、例えば、危険であるとして、チームを識別したりオブジェクトを分類す
るのに使用され得る。ローカル・アプリケーション・アクセス・サーバのストリ
ーム・オブジェクト・フィルタは、プレーヤのストリーム・オブジェクトに対す
るサブスクリプションを受信して、プレーヤがストリーム・オブジェクトを要求
したキーで得るのを保証する。

【０１４０】 ＡＴＰコンテント・パケット（ＣＰ）は、１）基本オブジェクト、２）ストリ
ーム・オブジェクト、３）制御メッセージ、４）クライアント・メッセージ、の
いずれのタイプでもよい。基本オブジェクト、ストリーム・オブジェクト及びク
ライアント・メッセージのＣＰは、アプリケーション・ペイロードを含んでいる
。制御メッセージは、メッセージ・タイプとメッセージ・パラメータを含んでい
る。アプリケーション制御プロトコルは、メッセージ・タイプ・フィールド及び
各メッセージのパラメータのフォーマットを指定する。

【０１４１】 セッション識別子、クライアント識別子及びオブジェクト識別子は、以下で説
明するような動的アドレス・フィールドである。クライアント・グループ及びオ
ブジェクト・グループは、クライアント及びオブジェクトのそれぞれと識別子の
フォーマットが同じである。

【０１４２】 本明細書においては以下の名前及び定義を使用している。アプリケーション・
オブジェクト・パケットとは、コンテント・パケットにアプリケーション・オブ
ジェクトを含むＡＴＰパケットである。アプリケーション制御プロトコル・パケ
ットとは、コンテント・パケットに制御メッセージを含むＡＴＰパケットである
。基本オブジェクト、ストリーム・オブジェクトあるいはクライアント・メッセ
ージの送信は、常に、適切なタイプのコンテント・パケットを有するＡＴＰパケ
ットが送信されることを意味する。クライアント・メッセージ・パケットとは、
コンテント・パケットに受信者アドレス及びクライアント・メッセージを含むＡ
ＴＰパケットである。

【０１４３】 ＡＴＰ使用例は以下を含む。 Ａ）クライアントは、基本オブジェクトをローカル・アプリケーション・サー
バに送信している。クライアント識別子でなくオブジェクト識別子又はセッショ
ン識別子がＡＴＰオプション・ヘッダに入れられる。ＡＴＰターゲット・ヘッダ
は全く必要ない。オブジェクト・ペイロードはコンテント・パケットに入れられ
る。オプション・ヘッダと動的アドレス・フィールドの使用は、ヘッダ・オーバ
ヘッドが４バイトまで小さくできることを意味する。オブジェクトはしばしば狭
い帯域幅の接続で送られるので、これは重要である。

【０１４４】 Ｂ）クライアントは、クライアント・メッセージを別のクライアントに送信し
ている。オブジェクト識別子と送信クライアントのクライアント識別子がＡＴＰ
オプション・ヘッダに入れられる。セッション識別子は全く必要ない。メッセー
ジ・ペイロードはコンテント・パケットに入れられる。送信側のアプリケーショ
ン・ルータの入力フィルタは、ターゲット・ヘッダにセッション識別子を加える
。受信側のアプリケーション・ルータの出力フィルタは、パケットを受信クライ
アントに送る前にセッション識別子を削除する。

【０１４５】 ＡＴＰは動的アドレス・フィールドを使用する。動的フィールドは可変長プレ
フィクス・コードである。プレフィクス・コードは、前のコード・ワードを参照
せずに、ビット・フィールド内の各コード・フィールドが一意に復号され得るコ
ードである。単純な例は、アルファベット、｛１０，１１０，１１１０，…｝で
ある。ハフマン符号は、シンボルの統計的分布について最適な（最小期待長）プ
レフィクス・コードである。動的アドレス・フィールドの代替的フォーマットは
、動的サイズ整数（dynamic size integer）である。動的サイズ整数は、コンピ
ュータ・サイエンスにおいては周知である。動的サイズ整数は、小さな値が最も
多いときには常に使用されるが、大きな値が可能でなければならない。２バイト
の動的サイズ整数では、最上位ビットは整数のサイズを表し、１は１バイトを意
味し、０は２バイトを意味する。４バイトの動的サイズ整数では、最上位の２ビ
ットは整数のサイズを表し、０１は１バイトを意味し、１０は２バイトを意味し
、１１は３バイトを意味し、００は４バイトを意味する。

【０１４６】 動的アドレス・フィールドは、以下の２つの方法に従って使用できる。 第１の方法では、ＡＴＰは、１）アプリケーション・セッション識別子、２）
クライアント識別子、３）オブジェクト識別子、の３つの異なった識別子のため
のフィールドを有している。アプリケーション・セッション識別子は、グローバ
ルにユニークのものであり、ネット・マネージャあるいはロビー・アクセス・サ
ーバなどの中央機関によって割り当てられる。クライアント、アプリケーション
・ルータ、アプリケーション・サーバ及びオプションとしてサイト・マネージャ
のそれぞれは、クライアント識別子を有し、以下のノード内にある。クライアン
ト・グループ識別子は、クライアント識別子のフォーマットを有している。

【０１４７】 クライアント識別子は、特定のアプリケーション・セッションにおいてのみユ
ニークなものである。ロビー・アクセス・サーバ又は中央制御ユニットなどの中
央機関が、クライアント識別子を割り当てる。アプリケーション・セッション識
別子が既知であるときだけ、クライアント識別子でノードが識別される。ＡＴＰ
は動的フィールドにクライアント識別子を格納する。アプリケーション・セッシ
ョンの各ノードには、クライアント識別子ができるだけ少ないビットで割り当て
られる。頻繁に使用されるクライアント識別子には、例えば、ハフマン符号化手
順に従って、最短のコードが割り当てられるであろう。

【０１４８】 オブジェクト識別子は、所与のセッションで所与のクライアントにユニークで
ある。クライアントがオブジェクト識別子を割り当てる。セッション識別子及び
クライアント識別子が既知であるときだけ、オブジェクト識別子によってオブジ
ェクトが識別される。ＡＴＰはオブジェクト識別子を動的フィールドに格納する
。各オブジェクトには、オブジェクト識別子ができるだけ少ないビットで割り当
てられる。頻繁に使用されるオブジェクト識別子には、例えば、ハフマン符号化
手順に従って、最短のコードが割り当てられるであろう。

【０１４９】 第２の方法は、以下の点を除いて第１の方法と同様である。クライアント識別
子は２つの動的フィールドからなる。第１のフィールドは、クライアントをサー
ビスしているアプリケーション・ルータの識別子である。第２の動的フィールド
は、クライアント・インデックスである。このインデックスは、できるだけ短く
なり、かつアプリケーション・セッション識別子が与えられたときにローカル・
アプリケーション・ルータ・クライアント識別子が既知のクライアントにユニー
クとなるように選択される。ローカル・アプリケーション・サーバのクライアン
ト識別子は、代替的に、ローカル・アプリケーション・ルータのクライアント識
別子の代わりに使用できる。

【０１５０】 上記のような動的アドレス・フィールドと相対的アドレッシングを使用する利
点は、使用する帯域幅と遅延が最小となることである。関連するアドレス・フィ
ールドだけが送信される。この例は以下のようなものである。 １）クライアントは１つのアプリケーション・セッションだけに係わる。クラ
イアントからのオブジェクトを含むＡＴＰパケットは、オブジェクト識別子だけ
を含んでいる。アプリケーション・セッション識別子及びクライアント識別子は
、アプリケーション・ルータは事実上知っているので送信されない。 ２）ローカル・アプリケーション・サーバからクライアントへ送信されたオブ
ジェクトを含むＡＴＰパケットは、オブジェクト識別子とそのオブジェクトを所
有するクライアントのクライアント識別子だけを含んでいればよい。 ３）新たなオブジェクトを作成するクライアントは、すぐにオブジェクト識別
子を割り当てる。グローバルにユニークなオブジェクト識別子の集中的割り当て
は、新たなオブジェクトが作成される前に中央機関との通信を必要とする。

【０１５１】 クライアント・グループ・アドレッシングは、以下に従って処理される。ＡＴ
Ｐのクライアント・グループが、クライアント識別子によって識別される。他の
クライアント識別子についてと同様な方法を用いて識別子が作成される。アプリ
ケーション・セッションの間にクライアントによってクライアント・グループの
裂くせいが要求されるか、あるいはセッションの初期化の一部としてクライアン
ト・グループの作成が実行される。

【０１５２】 各ＡＴＰパケットはＡＴＰヘッダにタイプ・フィールドを含んでいる。タイプ
・フィールドはコンテントの性質を表わしている。タイプ・フィールドの異なっ
たコードは、例えば、コンテントが、基本オブジェクト、ストリーム・オブジェ
クト、制御パケットあるいはクライアント・メッセージであることを示す。アプ
リケーション・ルータは、アドレス・フィールドの読み取りや解析をしないある
種の場合におけるデフォルトのルーティングのために、タイプ・フィールドを使
用できる。タイプ・フィールドに基づいたデフォルトのルーティングの例は以下
のようなものである。 １）全ての基本オブジェクトはローカル・アプリケーション・サーバに送られ
る、２）タイプ・フィールドに特定の１つのコードがある制御パケットは、ロー
カル・アプリケーション・サーバに送られ、タイプ・フィールドに別の特定の１
つのコードがある制御パケットは、ローカル・サイト・マネージャに送られる。

【０１５３】 図７は、図６に関して検討した実施形態で使用されるアプリケーション・ルー
タ１５２と、ＡＴＰパケットがどのようにアプリケーション・ルータを通って行
くのかを示している。アプリケーション・ルータ１５２は、入力フィルタのセッ
ト１９０、１９２と、ルータ・コア１９４と、出力フィルタのセット１９６、１
９８とからなる。アプリケーション・ルータは、通信する各ノードに対して、入
力及び出力フィルタを有している。ルータ・コア１９４は、ＡＴＰパケットのル
ーティングを実行するために、いくつかのルーティング・テーブル１９９を含ん
でいる。

【０１５４】 パケットは３つのタイプの送信源、すなわち、同じアプリケーション・アクセ
ス・サーバのアプリケーション・サーバ及び、例えばサイト・マネージャなどの
他の同様なユニットからと、他のアプリケーション・ルータからと、このアプリ
ケーション・ルータに接続されたアプリケーション・クライアントから来る。別
のアプリケーション・ルータあるいはアプリケーション・クライアントへの全て
の接続に対して、１つの入力フィルタ１９０、１９２と１つの出力フィルタ１９
６、１９８がある。アプリケーション・サーバへの接続に対しては、入力又は出
力フィルタは全く必要ない。フィルタはいくつかのアプリケーション・パケット
の転送パッケージへの組立を実施し、信頼できるパケットの再送も扱う。アプリ
ケーション・クライアント出力フィルタ１９６、１９８は、クライアント回線上
の冗長な情報を削除し、アプリケーション・クライアント１７０へのダウンリン
クについての負荷バランスも取る。

【０１５５】 出力フィルタに接続されたクライアント１７０、あるいは認可されたあらゆる
他のクライアントは、受信クライアントの出力フィルタに、ストリーム・オブジ
ェクト又はストリーム・オブジェクト・キーのサブスクリプションを送信できる
。サブスクリプションは、サブスクリプションのコンテントと受信クライアント
のクライアント識別子を示す制御メッセージとして送信される。出力フィルタは
、アプリケーション・ルータに到着するストリーム・オブジェクトをスキャンす
る。サブスクリプションに合うストリーム・オブジェクトは、おそらくドロップ
レートを適用した後でクライアントに送信される。ストリーム・オブジェクトが
サブスクリプションと合うのは、ストリーム・オブジェクトのオブジェクト識別
子がサブスクリプションにあるオブジェクト識別子と等しい場合、あるいはスト
リーム・オブジェクトで運ばれたストリーム・オブジェクト・キーがサブスクリ
プションにあるストリーム・オブジェクト・キーと合った場合のいずれかである
。

【０１５６】 （出力フィルタに接続された）クライアントが、ストリーム・オブジェクトを
申込み、ストリーム・オブジェクトを送信クライアントから受信するときを考え
る。そのクライアントあるいは他の認可されたあらゆるクライアントは、所与の
ストリーム・オブジェクトに関連してドロップレートを設定できる。このドロッ
プレートはローカル・アプリケーション・ルータに制御メッセージで送信される
。ドロップレートが、０≦Ｒ≦１の値に設定されていれば、出力フィルタはスト
リーム・オブジェクトの比率Ｒを意図的に削除する。例えば、Ｒ＝０．９である
と、到着パケットの１０％だけがクライアントへ渡されるのを許可される。

【０１５７】 出力フィルタは、クライアントに送信される必要のないＡＴＰヘッダ・フィー
ルドを削除する。別のクライアントから直接アドレス指定されたメッセージは、
例えば、アプリケーション・セッション識別子と受信クライアントのクライアン
ト識別子をヘッダに含んでいる。この情報を受信クライアントには有用ではなく
、このためアプリケーション・ルータの出力フィルタで削除される。

【０１５８】 クライアントなどの特定のノードに対する入力フィルタは、ストリーム・オブ
ジェクト、基本オブジェクト、制御メッセージ及び直接アドレス指定されたクラ
イアント・メッセージを含むＡＴＰパケットをノードから受信する。ＡＴＰパケ
ットをルーティング・コアに送信する前に、以下の動作が実行される。 １）入力フィルタは、クライアントがストリーム・オブジェクト又は基本オブ
ジェクトを更新するのを許可されているか、あるいは送信クライアントがメッセ
ージ内に示されるクライアントに直接アドレス指定されたメッセージを送信する
のを許可されているかをチェックする。この認可チェックは、クライアントがど
のような種類の動作の実行を許可されたのかを示す、認可テーブルを参照して実
行される。認可テーブルは、クライアント又は初期化ファイルを使用するサイト
・マネージャを介してＬＡＳによって設定される。 ２）入力フィルタは送信クライアントのアドレスを適切なＡＴＰヘッダに追加
する。このアドレスは、帯域幅を節約するため、送信クライアントとアプリケー
ション・ルータとの間の通信リンクには送信されない。 ３）アプリケーション・ルータはクライアント・グループのリストを格納する
。このようなリストは、クライアント・グループを示すクライアント識別子を、
クライアントを示すクライアント識別子のリストに結びつける。クライアント・
グループのリストは、クライアント又はサイト・マネージャを介してＬＡＳによ
って設定される。受信者のアドレス・フィールド内のクライアント・グループを
有するＡＴＰパケットが入力フィルタに受信されると、以下の３つの代替的オプ
ションの１つを行う。Ａ）クライアント・グループに属するクライアント識別子
のリストを見つける。ＡＴＰパケットのコピーを少なくとも１つ受信すべきアプ
リケーション・ルータの数Ｎを見つける。受信アプリケーション・ルータそれぞ
れに対する出力フィルタに入れるＡＴＰパケットをＮ個コピーする。ＡＴＰヘッ
ダには、コンテントをローカル・クライアントだけに配布し、あらゆるリモート
受信者に配布すべきでないことを示すフラグがある。このフラグは各出力パケッ
トで設定される。これは好ましい動作モードである。 ４）クライアント・グループに属するクライアント識別子のリストを見つける
。ＡＴＰパケットのコピーを少なくとも１つ受信すべきアプリケーション・ルー
タの数Ｎを見つける。受信アプリケーション・ルータそれぞれに対する出力フィ
ルタに入れるＡＴＰパケットをＮ個コピーする。各パケットにおいて、クライア
ント・グループ識別子を、受信アプリケーション・ルータのローカル・クライア
ントであるクライアント・グループのメンバーだけを含む受信クライアントのリ
ストに置き換える。ＡＴＰパケットを複製して、その結果、各複製でクライアン
ト・グループ識別子を、クライアント・グループに関連するクライアント識別子
リスト内のクライアント１つを示す、１つのユニークなクライアント識別子に置
き換える。 ５）そのクライアントが入力フィルタが送信しているクライアントに関連する
として、各ストリーム・オブジェクトについてデフォルト・ヘッダが入力フィル
タによって格納される。このデフォルト・ヘッダは、ストリーム・オブジェクト
に関連したストリーム・オブジェクト・キーを含んでいる。クライアントが明ら
かにストリーム・オブジェクトを含んでいるヘッダを送信したら、このヘッダが
入力フィルタによって格納されたデフォルト・ヘッダに置き換わる。クライアン
トが、ストリーム・オブジェクトを含んでいるヘッダなしにストリーム・オブジ
ェクトを送信したら、入力フィルタはストリームオブジェクトがルータ・コアに
送信される前にデフォルト・ヘッダを追加する。これは送信クライアントが、ス
トリーム・オブジェクトの各コピーと共にストリーム・オブジェクト・キーのコ
ピー１つを送信する必要が無いことを意味する。キーが変わる度とストリーム・
オブジェクトが最初に送信されるときに、ストリーム・オブジェクト・キーを含
んでいるヘッダを送信すれば十分である。

【０１５９】 標準的ＡＴＰパケットは、アプリケーション・オブジェクト（ストリーム又は
基本）、制御メッセージ又はクライアント・メッセージのいずれかであるコンテ
ントを運ぶ。複合ＡＴＰパケットは、オプションの小さな複合ヘッダと、少なく
とも１つで普通はいくつかの標準的ＡＴＰパケットからなる。複合ＡＴＰパケッ
トは、標準的転送プロトコルのペイロードとして送信される。普通は複合ＡＴＰ
パケットはＵＤＰパケットのペイロードとして送信される。

【０１６０】 複合ＡＴＰパケット内に標準的ＡＴＰパケットを集める方法は、帯域幅の効率
と小さなレイテンシとの間の正しいバランスを達成するためには重要である。大
きな複合ＡＴＰパケットは伝送のレイテンシを大きくするが、ヘッダのオーバヘ
ッドを小さくし、そのため帯域幅を効率的に利用する。標準的ＡＴＰパケットの
複合ＡＴＰパケットへの集結は、システムのいくつかのモジュールで行われる。

【０１６１】 ローカル・アプリケーション・ルータに送信するアプリケーション・クライア
ントでの集結には、２つの代替的方法が使用され得る。第１の方法では、集結は
アプリケーション・プログラムの直接制御下にある。標準的ＡＴＰパケットは出
力バッファに送信される。アプリケーション・プログラムが、バッファのコンテ
ントが複合ＡＴＰパケットに入れられて、ローカル・アプリケーション・ルータ
に送信されるときを決定する。第２の方法では、集結はクライアント内の自動的
アルゴリズムによって実行される。標準的ＡＴＰパケットはアプリケーション・
プログラムによって出力バッファに送信される。アルゴリズムが、バッファのコ
ンテントが複合ＡＴＰパケットに入れられて、ローカル・アプリケーション・ル
ータに送信されるときを決定する。好ましいアルゴリズムの例は、バッファ・サ
イズが所与のサイズＳを越えたら複合パケットが送信される。複合パケットの最
後の送信からの時間が所与の時間間隔Ｔを越えたら複合パケットが送信される。
パラメータＳ及びＴはアプリケーション・プログラムによって設定される。

【０１６２】 クライアントに送信するアプリケーション・ルータでの集結には、例えば、上
記第２の方法と同様なアルゴリズムが使用され得る。アプリケーション・ルータ
に送信するアプリケーション・ルータでの集結には、アプリケーション・ルータ
間のリンクは非常に高速であると想定でき、標準的パケットは非常に頻繁に送信
されるので、次のプロトコル・レベル、例えばＵＤＰ、によって許可される最大
サイズのＡＴＰ複合パケットを送信するのが通常は良好に動作する。

【０１６３】 帯域幅が制限されたりＡＴＰパケットがまれにしか送信されなければ、アプリ
ケーション・クライアントでの集結について先に述べた第２の方法と同様なアル
ゴリズムを使用するのを勧める。

【０１６４】 サイズＳ（ビット）は、Ｖがビット／秒で測定した２つのアプリケーション・
ルータ間の通信速度であり、Ｔ０が普通は１〜１０ｍｓの許される伝送のレイテ
ンシであるとき、Ｓ＜Ｖ＊Ｔ０となるように選択される。時間間隔Ｔは１〜１０
ｍｓの間とすべきである。

【０１６５】 クライアントは、基本オブジェクトに対するサブスクリプションを、ローカル
アプリケーション・サーバへの制御メッセージとして送信できる。サブスクリプ
ションは、受信クライアント、サブスクリプションのターゲット及びサブスクリ
プション・パラメータを指定する。サブスクリプションは、アプリケーション・
サーバに対して、一連の基本オブジェクトを受信クライアントに送信させる命令
である。各オブジェクトの一連の更新は、サブスクリプションのパラメータに従
って、かつ基本オブジェクトのソースがどのように変更されたかに応じて送信さ
れる。

【０１６６】 サブスクリプションを送信するクライアントは、通常受信クライアントである
が、クライアントは別のクライアントに代わってサブスクリプションを作成する
かもしれない。サブスクリプションはまた、クライアント・グループに代わって
発行され得る。クライアント・グループの全てのクライアントは、サブスクリプ
ションの結果を受信する。

【０１６７】 サブスクリプションのターゲットは、ＡＴＰプロトコルに従ってオブジェクト
識別子によって識別される基本オブジェクトのセットである。ターゲットは、１
）オブジェクト識別子、２）オブジェクト識別子のセット、３）オブジェクト・
グループ識別子、４）オブジェクト識別子とオブジェクト・グループ識別子の混
ざったセット、５）オペランドとしてのオブジェクト・グループ及びオブジェク
トと論理演算子ＡＮＤ、ＯＲ及びＮＯＴとを含む一般的ブール論理式、で記述さ
れ得る。正しく定義されたターゲットの表現は、オブジェクト・データベース及
びオブジェクト・グループ・データベースの情報を用いて、アプリケーション・
サーバで見積もられる。この見積もりの結果は常に、基本オブジェクトの有限セ
ットとなる。

【０１６８】 サブスクリプション・パラメータは、サブスクリプションのコンテントが、ど
れだけの頻繁で、何回、及びどれだけ長く配信されるのかを特定するのに使用さ
れ得る。これは、オブジェクトの更新されたバージョンが受信されるべき最大レ
ートとして特定され得る。オブジェクトの所有者が低いレートでオブジェクトを
更新すると、新たなバージョン各々は配信されるとすぐに受信されるであろう。
オブジェクトが選択された最大レートより速く更新されると、更新は正に選択さ
れたレートで受信されるであろう。この場合、中間のバージョンのいくつかは受
信されないであろう。

【０１６９】 コンテント・サーバあるいはマスター・クライアントは、ゲームの状態につい
てより多くの情報を持っているであろう。従って、マスター・クライアントがタ
ーゲット・クライアントの代わりに基本オブジェクトを申込むのは好ましいであ
ろう。マスター・クライアントは、システムに対してサブスクリプションを構成
して提出する。ローカル・アプリケーション・アクセス・サーバは、サブスクリ
プションで要求された基本オブジェクトを、ターゲットのクライアント又はクラ
イアント・グループに直接配信する。

【０１７０】 サブスクリプションは、クライアント又はクライアント・グループに帰属する
。サブスクリプションはゲーム・オブジェクトのセットを参照する。このセット
は、オブジェクト・グループ及びオブジェクトを含む一般的ブール論理式で表わ
され得る。

【０１７１】 アプリケーション・アクセス・サーバ（ＡＡＳ）は、オブジェクトをサブスク
リプション周波数で配信しようとする。配信時間は、サブスクリプション周波数
の逆数である。サブスクリプションが発信されるときにデータベース内にあるオ
ブジェクトは、配信時間内に配信される。サブスクリプションが有効である間に
データベース内のオブジェクトが変更されると、ＡＡＳはそれを配信時間内に配
信しようとする。

【０１７２】 サブスクリプション・クラスは正の整数である。サブスクリプション・クラス
に従ってデータを配信する２つの方法をここで説明する。

【０１７３】 方法１：最も大きなクラスのサブスクリプションが、最初に完全に履行される
。次に、ＡＡＳは次に大きなクラスのサブスクリプションを完全に履行しようと
する。これは、小さなクラスのサブスクリプションは、決して履行されないかも
しれないことを意味する。サブスクリプション・クラス内のオブジェクトを要求
された周波数で配信するのに帯域幅が不十分であれば、クライアントへの配信が
容易となるように、ＡＡＳはクラス内の全ての周波数を上げる。

【０１７４】 方法２：３つの異なったクラスが使用される。異なったクラスは、１＝高、２
＝中、３＝低、と呼ばれる。クラス１のオブジェクトは、バッファがフルでレー
トがゼロに落ちるまで、常に最大レートで申込者に送信される。クラス２のオブ
ジェクトの申込者への送信レートは、バッファの負荷に比例する。バッファの容
量が小さくなるとレートが低くなる。クラス３のオブジェクトは、バッファ内に
他のオブジェクトが何も無ければ申込者に送信される。

【０１７５】 １つの特定の実施態様では、アプリケーション・オブジェクト・パケットは、
いくつかの列挙されたペイロードを含み得る。この場合、サブスクリプションは
、オプションの加重パラメータを有している。加重パラメータは整数である。加
重＝ｎは、オブジェクトの最初のｎ個のペイロードが配信されることを意味する
。

【０１７６】 いくつかのオブジェクトは通常の間隔では更新されないかもしれないが、代わ
りに正確な回数だけ更新される。従って、特定のオブジェクトに関して指定数の
更新を要求することができる。アプリケーション・サーバは、そのオブジェクト
に関してカウンタをサブスクリプションで指定された整数値に設定する。オブジ
ェクトが配信される度にカウンタは１づつデクリメントされる。カウンタ＝０と
なるとサブスクリプションは削除される。

【０１７７】 クライアントは、同じ更新が前に送信された場合であっても、要求した周波数
でオブジェクトが送信されるのを要求できる。これは「強制送信」ＦＳフラグを
設定することで行われる。

【０１７８】 また、古いサブスクリプションに関するデータでネットワークが過負荷となる
のを防止するため、サブスクリプションの寿命、あるいは持続期間が設定される
べきである。サブスクリプションの寿命が過ぎた後に、サブスクリプションは削
除される。

【０１７９】 ストリーム・オブジェクトは、アプリケーション・ルータ間で以下の方法の１
つを用いて配布される。 方法１）１つのアプリケーション・ルータによって受信されたストリーム・オ
ブジェクトは、複製されてアプリケーション・セッションに参加している全ての
他のアプリケーション・ルータに送信される。これは、例えば、アプリケーショ
ン・セッションに参加している全てのアプリケーション・ルータを、ＩＰマルチ
キャスト・アドレスに関連付けることによって効率的に行われ得る。 方法２）各アプリケーション・ルータは、ストリーム・オブジェクト及びスト
リーム・オブジェクト・キーに対するサブスクリプションのセットをローカル・
クライアントから受信する。そのようなサブスクリプション全ては、ローカル・
クライアントが申込んでいるストリーム・オブジェクト及びストリーム・オブジ
ェクト・キーを少しの重複もなしにすべて含む、ジョイント・サブスクリプショ
ンに集められる。ローカル・クライアントで生成されたストリーム・オブジェク
ト・キーでなくてストリーム・オブジェクトは、集められたサブスクリプション
から削除される。集められたサブスクリプションは、他の全てのアプリケーショ
ン・ルータに送信される。ローカル・クライアントの中で、別のアプリケーショ
ン・ルータから集められたサブスクリプションを受信し、集められたサブスクリ
プションのストリーム・オブジェクト及びストリーム・オブジェクト・キーに対
するいずれかの発信源を知るアプリケーション・ルータは、申込んでいるアプリ
ケーション・ルータにサブスクリプションの一部を送信する。 方法３）各アプリケーション・ルータは、方法２と同様にサブスクリプション
の集められたセットを用意する。集められたサブスクリプションは、サイト・マ
ネージャに任命された親のアプリケーション・ルータに送信される。親のアプリ
ケーション・ルータは、入手可能であり、最初に親のアプリケーション・ルータ
と任命された親のアプリケーション・ルータに送信された自身の集めたサブスク
リプションの残りを含む、集められたサブスクリプションのサブセットを配信す
る。これは管理システムが、アプリケーション・セッションについてのアプリケ
ーション・ルータの階層を構築したとみなされる。

【０１８０】 基本オブジェクトはアプリケーション・サーバ間で配布される。アプリケーシ
ョン・サーバには、常に関連するローカル・アプリケーション・ルータの１つを
介して届けられる。アプリケーション・サーバが、基本オブジェクトを別のアプ
リケーション・サーバに送信するとき、最初のアプリケーション・サーバは、第
２のアプリケーション・サーバの識別子をＡＴＰパケットの受信アドレス・フィ
ールドに入れて、基本オブジェクトをローカル・アプリケーション・ルータの１
つに送信する。このアプリケーション・ルータは、オブジェクトを第２のアプリ
ケーション・サーバのローカル・アプリケーション・ルータに送信する。第２の
アプリケーション・サーバのローカル・アプリケーション・ルータは、オブジェ
クトを第２のアプリケーション・サーバに送信する。

【０１８１】 基本オブジェクトは、アプリケーション・サーバ間で以下の方法の１つを用い
て配布される。 方法１）１つのアプリケーション・サーバによって受信された基本オブジェク
トは、複製されてアプリケーション・セッションに参加している全ての他のアプ
リケーション・サーバに送信される。これは、オプションとして、例えば、アプ
リケーション・セッションに参加している全てのアプリケーション・サーバを、
ＩＰマルチキャスト・アドレスに関連付けることによって効率的に行われ得る。 方法２）各アプリケーション・サーバは、基本オブジェクトに対するサブスク
リプションのセットをローカル・クライアントから受信する。そのようなサブス
クリプション全ては、ローカル・クライアントが申込んでいる基本オブジェクト
をすべて含んでいるがサブスクリプション・パラメータを含んでいない、ジョイ
ント・サブスクリプションに集められる。集められたサブスクリプションは、他
の全てのアプリケーション・サーバに送信される。ローカル・クライアントの中
で、別のアプリケーション・サーバから集められたサブスクリプションを受信し
、集められたサブスクリプションの基本オブジェクトに対するいずれかの発信源
を知るアプリケーション・サーバは、申込んでいるアプリケーション・サーバに
そのようなオブジェクトをすぐに送信し、サブスクリプションの関連する部分を
格納する。関連するオブジェクトのそれ以降の更新も、申込んでいるアプリケー
ション・サーバにすぐに送信される。 方法３）各アプリケーション・サーバは、方法２と同様にサブスクリプション
の集められたセットを用意する。集められたサブスクリプションは、サイト・マ
ネージャに任命された親のアプリケーション・サーバに送信される。親のアプリ
ケーション・サーバは、入手可能であり、最初に親のアプリケーション・サーバ
と任命された親のアプリケーション・サーバに送信された自身の集めたサブスク
リプションの残りを含む、集められたサブスクリプションのサブセットを配信す
る。これは管理システムが、アプリケーション・セッションについてのアプリケ
ーション・サーバの階層を構築したとみなされる。

【０１８２】 セッションに参加している全てのアプリケーション・アクセス・サーバに配布
される必要のある制御データは、例えば、クライアントの加入及び脱退並びにク
ライアント・グループの作成及び破壊を含んでいる。そのような制御データは、
セッションの全てのアプリケーション・ルータにマルチキャストされるべきであ
る。アプリケーション・ルータは、制御メッセージを終了させるか、それを要求
に応じてローカル・アプリケーション・サーバ又はサイト・マネージャに送る。

【０１８３】 いくつかのクライアントが、観戦者としてアプリケーション・アクセス・サー
バに登録されてもよい。観戦者はアプリケーションの動作を更新することは許可
されないが、ゲーム内での観戦者の視点に応じてサブスクリプションを更新する
ことができる。

【０１８４】 本発明によるアプリケーション・アクセス・サーバは、階層的システムでも使
用できる。図８はそのような構成の例を示しており、ここで高レベルのアプリケ
ーション・アクセス・サーバ２０１は他のアプリケーション・アクセス・サーバ
・ユニット２０３、２０５、２０７をサービスし、そしてこれらはアプリケーシ
ョン・クライアント２０９をサービスする。高レベルのアプリケーション・アク
セス・サーバ２０１は、ＡＴＰパケットをゲームデータ及び集められたサブスク
リプションと共に、「クライアント」とみなされる下流のアプリケーション・ア
クセス・サーバ・ユニットから受信する。高レベルのアプリケーション・アクセ
ス・サーバ２０１は、他のピア・アプリケーション・アクセス・サーバ・ユニッ
ト及びもしあれば階層でより高いレベルのアプリケーション・アクセス・サーバ
・ユニットと通信する。階層的アプリケーション・アクセス・サーバ・システム
は、多数のクライアントが関係するアプリケーションのためのゲーム状態の階層
的分散表示を作成するのに使用される。

【０１８５】 リモート・アプリケーション・アクセス・サーバ・ユニットは、マルチキャス
ト型のツリーに構成されてもよく、その場合、マルチキャスト・グループ毎に１
つのソーティング・バッファがあるであろう。全ての情報が全てのリモート・ア
プリケーション・アクセス・サーバ・ユニットに送信される、簡単な配布方式が
使用されてもよい。この場合バッファはただ１つである。

【０１８６】 アプリケーション・クライアントのセットが、小さなレイテンシをもたらすブ
ロードバンド接続を有していてもよく、その場合はアプリケーション・アクセス
・サーバは全く必要ない。典型的な例としては、全てのプレーヤが同じＬＡＮに
つながっているものである。ゲームのアプリケーションやＡＰＩが依然としてア
プリケーション・アクセス・サーバを予期したものである場合、クライアントの
装置でソフトウェアでアプリケーション・アクセス・サーバ機能を実行すること
が可能であろう。

【０１８７】 アプリケーション・アクセス・サーバ・ユニットは、ネットワーク内のあらゆ
る中間的位置に配置されてもよい。これはクライアントとアプリケーション・ア
クセス・サーバとの間の「リンク」プロトコルが、オプションとしてＵＤＰ／Ｉ
Ｐ又はＴＣＰ／ＩＰであり得ることを意味する。代替的に、ダイヤル・インのゲ
ーム・サービスを実行中の中央のゲーム・サーバが、部品としてアプリケーショ
ン・アクセス・サーバ・ユニットを使用することもできる。ここで中央のサイト
は、アプリケーション・アクセス・サーバ・ユニット及びアプリケーション・ロ
ビー・サーバに接続されたモデム・プールのセットから構成されるだろう。これ
は中央のサイトを構築するのに効率的で規模が変更可能であるが、ゲーム・トラ
フィックを早期に集めるという利点はないだろう。

【図面の簡単な説明】

【図１】 本発明によるネットワークの実施形態を示す図である。

【図２】 本発明の第１の実施形態によるアプリケーション・アクセス・サーバを示す図
である。

【図３】 本発明によるアプリケーション状態レコードの実施形態を示す図である。

【図４】 本発明の実施形態によるアプリケーション・クライアントを示す図である。

【図５】 本発明の実施形態によって使用される通信スタックを示す図である。

【図６】 本発明のアプリケーション・アクセス・サーバの第２の実施形態を示す図であ
る。

【図７】 アプリケーション・アクセス・サーバの第２の実施形態で使用されるアプリケ
ーション・ルータを示す図である。

【図８】 本発明の実施形態で使用されるアプリケーション・アクセス・サーバの階層構
造を表わす図である。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１３年８月７日（２００１．８．７）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正の内容】

【特許請求の範囲】

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ， ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ， ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，Ｋ Ｐ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ， ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，Ｓ Ｇ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 ヨンソン， ヨナス スウェーデン国 エケリュ エス−178 32， ヒョートヴェーゲン 26 (72)発明者 イェンデル， マグヌス スウェーデン国 ウップランズ ヴェスビ ュ エス−194 60， ヴォルヴェーゲン 10 (72)発明者 カールッソン， クリステル スウェーデン国 ストックホルム エス− 112 43， リンドハーゲンスガタン 69 (72)発明者 カールッソン， ロランド スウェーデン国 ストックホルム エス− 117 21， ドラケンベルイスグ． ３ イーヴェ (72)発明者 レンベルイ， エマヌエル スウェーデン国 ウプサラ エス−754 23， ディエクネグ． 19：510 (72)発明者 オスボルネ， ステュアルト スウェーデン国 ヘゲルステン エス− 122 63， セデルグレンスヴ． 27 (72)発明者 ステンホフ， マルティン スウェーデン国 スポンガ エス−163 56， ソルヘムス ハグヴェグ 90 Ｆターム(参考） 5K030 GA02 HA08 HB07 HB17 HB21 HD03 JA10 KA01 KA04 KA06 LA03 LA19 LB18 LC09 LD08 5K047 AA02 BB15 GG57

Claims (29)

【特許請求の範囲】
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. 【請求項２９】 少なくとも１つのアプリケーション・ロビー・サーバと前
    記少なくとも１つのサイト・マネージャとの間のインタフェースを形成するよう
    に構成された、ロビー・アクセス・サーバを更に備えることを特徴とする請求項
    ２８に記載の通信ネットワーク。