JP2009540920A - ゲーム機間のフィーチャー配信 - Google Patents

Abstract

ゲーム機同士を接続する方法を開示する。この方法によれば、異なるフィーチャーを備えるゲーム機同士が参加してゲームを行うことができる。ゲーム機は、幾つかのゲーム機からデータを受信し、どのフィーチャーをどのゲーム機が必要しているかを判断する。必要とされるフィーチャーとは、当該ゲーム機が所持していないフィーチャーであって、他のゲーム機が所持しているフィーチャーである。そして、各ゲーム機が必要としているフィーチャーに関するコードを、当該ゲーム機に送信する。

Description

本発明は、複数人参加型のゲームにおいて、ゲーム機同士を接続する方法に関する。

ゲームプレーヤが、ネットワーク上で他のゲームプレーヤとゲームを行うことを可能にするゲーム機（例えば、Ｘｂｏｘ３６０（登録商標））が開発されている。ゲームを作動させるソフトウエアは個々のゲーム機に存在するが、典型的には、ゲームはサーバによって制御される。ゲームプレーヤのグループがネットワークを介して一緒にゲームをするために（これはライブゲームと呼ばれたり、オンラインゲームと呼ばれたりする）、各ゲームプレーヤは当該ゲームのライセンスを持たなければならない（ライセンスは、例えば、当該ゲームがディスクとして購入されたとき、あるいは、ダウンロードされたときに得られる）と共に、各ゲームプレーヤは、当該ゲームについて同じフィーチャー（ｆｅａｔｕｒｅｓ：特徴、特徴部、特徴要素、特長）を有さなければならない。ゲームプレーヤが異なるフィーチャーセットを有すると、ゲームプレーヤはオンラインゲームを一緒にプレーすることができない。なぜなら、理解できないデータをゲームコンソールが受信することになるからである。この問題は、ゲームプレーヤの購入能力（ゲームの別のレベルや武器などを購入する能力）が増大することにより（例えば、マイクロペイメント（micropayment）により購入する）、更に悪化している。

以下の説明は、本出願の開示内容の概要を示すものであり、明細書読者に基本的な理解を与えるためのものである。この概要は、本出願の開示内容の全てを説明したものではなく、また、本発明の重要な／不可欠な要素・要件を特定するものでもないし、本発明の範囲の外延を示したものでもない。その唯一の目的は、本明細書に開示されている幾つかの思想を簡単な形で示すことである。この概要は、後に記載される詳細な説明の前書きとして提示される。

ゲーム機同士を接続する方法が説明される。この方法によれば、異なるフィーチャーセットを有するゲーム機を使用する複数の参加者が、ゲームに参加することができる。ある装置が幾つかのゲーム機からデータを受信し、各ゲーム機がどのフィーチャーを必要としているのかを判断する。必要とされるフィーチャーは、特定のゲーム機が持っていないフィーチャーで、且つ他の１つ若しくは複数のゲーム機が持っているフィーチャーである。次いで、各ゲーム機により必要とされる特定のフィーチャーに関するコードは、各ゲーム機に転送される。

本発明は、以下の詳細な説明を添付図面に照らして読むことにより、より良く理解されるだろう。

複数のゲーム機によって構成されるネットワークの概略図である。 サーバの動作の例示的フロー図である。 図２のフロー図の１つのステップを詳細に示した例示的フロー図である。 図２のフロー図の１つのステップを詳細に示した例示的フロー図である。 ゲーム世界における多くのキャラクタの仮想位置を示す図である。 フィーチャーの転送を制限する方法の例示的フロー図である。 図２のフロー図の１つのステップを詳細に示した例示的フロー図である。 ゲーム機の概要図である。 データを消去するための例示的フロー図である。 サーバの概要図である。 複数のゲーム機によって構成される別のネットワークの概要図である。

添付図面においては、同じ参照符号は同じ要素や部品を示すために使用される。

添付図面とともに説明される下記の詳細な説明は、本発明の実施例を説明するものであり、本発明の実施例を構築したり使用したりする場合の限定的な例を示すものではない。下記の詳細な説明は、実施例の機能を説明し、実施例を構築して操作する方法の一連のステップを説明する。しかしながら、同じ若しくは均等な機能や一連のステップは、異なる実施例によっても達成できるであろう。

上記したように、異なるフィーチャーセットを有するゲームプレーヤ（gamer）は、同時に、オンラインゲームで一緒にプレーすることはできない。その理由は、ゲーム機が理解できないデータを受信してしまうからである。フィーチャーのミスマッチという問題は、ゲームプレーヤが追加のフィーチャー（例えば、新しいレベル、武器等）を購入できるようになればなるほど大きな問題となり、ゲームプレーヤが自己仕様のフィーチャー（例えば、アバター、カスタムビークル、カスタムランドスケープ等）を作成できるようになればなるほど大きな問題となる。追加のソフトウエアフィーチャーを購入することに加えて、ゲームプレーヤは、ゲーム機の周辺機器（例えば、銃等）も購入することがある。

図１は、複数のゲーム機を含むネットワーク１００の概略図である。このネットワークは、４つのゲーム機１０１（例えば、Ｘｂｏｘ３６０（登録商標））を含んでいる。当該４つのゲーム機１０１は、サーバ１０２（例えば、ＸｂｏｘＬｉｖｅ（登録商標）サーバ）を介して相互接続されている。各ゲーム機は、コンソール１０３と、ディスプレイ１０４と、コントローラ１０５を有している。接続は有線若しくは無線で、直接的に若しくは間接的に（例えば、インターネットを介して）なされる。ネットワークは、図示したゲーム機より少ない若しくは多い数のゲーム機を含んでもよく、各ゲーム機は１つ若しくは複数のコントローラを備えていてもよい。複数のコントローラを備える場合、異なるゲームプレーヤが異なるコントローラを用いて、同じゲームをプレーする。サーバ１０２の動作は、図２とともに説明することができる。サーバは、各ゲーム機１０３からゲームに参加するためのリクエストを受信し（ステップ２０１）、当該リクエストに応じて、サーバは各ゲーム機に対して当該ゲームに関する属性情報を尋ねる（ポーリングする）（ステップ２０２）。属性情報には、レベル、武器、アバター、及びゲームのその他のフィーチャーについての詳細が含まれる。サーバは、属性情報を受信すると、各ゲーム機が持っているフィーチャーセットの相違を判定し（ステップ２０３）、必要とされるフィーチャーを各コンソールに送り、各ゲーム機が共通のフィーチャーセットを有するようにする（ステップ２０４）。各ゲーム機が同じフィーチャーセットを有するようになったら、ゲームを開始することができる（図２には示されていない）。

一実施例では、共通のスクリプト語を用いてフィーチャーを転送するようにしてもよい。別の例においては、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋ−ｕｐ ｌａｎｇｕａｇｅ）をインターフェースとして用いて、ゲーム機間で属性情報が共有されるようにしてもよい。

場合によっては、例えば、ゲームプレーヤが自分自身のフィーチャー（例えば、新しい個別のアバター）を作った場合や、ゲームプレーヤがサードパーティ製のソフトウエア又はハードウエア（例えば、ガン、ハンドル、ステアリングホイール）を購入した場合、サーバは必要なコードを持っていないので、コードを所持していないゲーム機に当該コードを配信することができないこともある。このような場合、（図３及び図４に示されているように）サーバはまず、相違点を特定し（ステップ２０３ａ）、どんなコードをゲーム機が持っていないのかを特定する（ステップ２０３ｂ）。どんなコードが必要なのかを特定すると（ステップ２０３ｂ）、サーバは、サーバが所持していないコードを、所持しているゲーム機からアップロードし（ステップ２０４ａ）、前述のとおり、当該コードを必要としている全てのゲーム機にその相違点を送信する（ステップ２０４ｂ）。フィーチャーがゲームプレーヤにより作成されている場合、当該フィーチャーは標準ライブラリから得たサブフィーチャーによって作られたものであるか、または、全く新しいものであり、（アバターやその他のビジュアル情報についてのＪＰＥＧなどの）標準データフォーマットを有している。よって、それらフィーチャーをゲームにインポートすることができる。ゲームプレーヤにより新しいハードウエアが購入された場合、コードは新しいフィーチャーの表示（例えば、ガン用の画像）に関連していることもあるし、ハードウエアに関する他のパラメータに関連していることもある。また、コードは、ハードウエアのための制御情報、ドライバ若しくはエミュレータを含むこともあり、これらにより、他のゲームプレーヤが当該ハードウエアの機能を有することができるようになる。但し、限定された機能だけを有することになると思われる。これは、ゲームプレーヤが代替的な互換性のあるハードウエア（例えば、異なるガン等の代替周辺装置）を有する場合に言えることである。

このようにして、異なるフィーチャーセットを備える複数のゲーム機を相互接続することを可能にし、ゲームプレーヤは、複数人参加型のゲーム（multi-party game）に参加することができる。相違点のみを配信することにより、データ送信を最小にすることができ、その結果、ホストとゲーム機との間の伝送に起因する遅延を最小にすることができる。また、この方法は、カスタムフィーチャー又はサードパーティ製のフィーチャーを、ゲーム機間で共有することも可能にする。

この方法では、ゲームを開始する前にフィーチャーをゲーム機に送信することにより、ゲーム機とサーバとの間の低データレート接続により引き起こされることのある問題を回避することができる。もし、必要とされるとき（例えば、複数のゲーム機のうちの１つだけが新しいレベル又は武器に関して必要な属性を有している場合に、新しいレベルに入るときや新しい武器が使用されるとき）に、相違フィーチャーがサーバによってゲーム機へダウンロードされると、不十分な（poor）ネットワーク接続は、コンソールによって正しい表示をするのに遅延を生じさせてしまうだろう。

新しいゲーム機が、既に開始されているゲームに接続したいというリクエストを出した場合（つまり、図２に示したような相違点の初期配信の後）、または、当初から接続しているゲーム機の１つが接続を解除した後に再接続のリクエストを出した場合（例えば、接続解除が意図したものでは無い場合）、サーバは、接続しようとするゲーム機だけを（ステップ２０２のように）ポーリングし、データと他のゲーム機用に確定された共通フィーチャーセットとを比較する（ステップ２０２−２０４）。次いで、サーバは、接続しようとするゲーム機と共通フィーチャーセットとの間の相違点を特定し、必要なコードの全てを接続しようとするゲーム機に配信する。接続しようとするゲーム機が共通フィーチャーセットに含まれていないフィーチャーを有している場合は、そのコードを他の全てのゲーム機に配信する。

ゲーム機に対するポーリング（ステップ２０２）は、ゲーム中に周期的に繰り返されてもよい（例えば、５分毎に、若しくは、トリガに応じて）。このようなポーリングにより、追加のフィーチャーを獲得したゲーム機が存在するかどうかを判断する。この場合、コード配信は、新たな相違点が見つかった場合にのみ行われる（ステップ２０３）。

場合によっては、ゲーム機とサーバとの間の帯域幅が制限されてしまい、追加フィーチャー情報の全てをゲーム機に送信できないこともある。このような場合、あるフィーチャー（例えば、新しい武器）に関するコードは、小さいサイズのファイルによって置き換えられる。この小さいサイズのファイルは、そのフィーチャーに関する基本的な記述的属性を含んでいる（例えば、ポリゴンモデル、アニメーション、テクスチャ等は、その全部が送信されるわけではない）。このようにすると、オブジェクトの機能は損なわれずに維持され、所有者はいつもと同じようにそのフィーチャーを使用したり参照したりすることができる。その一方で、他のゲーム機が当該フィーチャーを使用する場合は、当該フィーチャーの簡素化したバージョン、または、標準的なグラフィフィックスしか表示することができない。

一実施例では、同一のオブジェクト（または他のフィーチャー）のいくつかの異なるクオリティモデル（quality model）が存在することができ、各モデルは、フィーチャーに関して異なるレベルの詳細（ＬＯＤ：ｌｅｖｅｌ ｏｆ ｄｅｔａｉｌ）を提供する。例えば、ビークル（vehicle）は３回モデリング（model）することができ、１つは、間近で見るための非常に詳細な（high detail）モデル、１つは、中間の詳細度の（medium detail）モデル、１つは、遠くから見るための低い詳細度の（low detail）モデルである。よって、より低い詳細度のモデルは、高クオリティのモデルよりも、ポリゴンの数、テクスチャの数、アニメーションの数が少なく、全体的な詳細度も低い。中間のクオリティのモデルは、上記２つのモデルの間に位置する。従って、低クオリティのモデルは小さなデータブロックであり、ネットワークを介して他のゲーム機に非常に容易に送信することができる。どのフィーチャーコードをゲーム機とゲーム機の間で送信する必要があるのかを判断すると（ステップ２０３）、サーバは、各ゲーム機に対して利用可能な帯域幅を評価し（ステップ２０４の一部）、フィーチャーコードを最高クオリティで許容時間フレーム内に（例えば、最大遅れ時間が予め設定される）送信できるかどうかを判断する。高ＬＯＤモデルが許容時間内に送信できない場合、サーバは、中間ＬＯＤコードを送信できるかどうかを判定する。もし送信できない場合には、サーバは、低ＬＯＤフィーチャーコードをゲーム機に送信する。この場合、サーバとの接続は限定された帯域幅で行われる。尚、各フィーチャーについては、３より多い若しくは少ないＬＯＤレベルがあってもよい。また、フィーチャーのＬＯＤレベルの数は当該フィーチャーの特性に依存してもよい。例えば、ナイフは小さいので、１つのＬＯＤだけでよいかも知れない（なぜなら、ナイフは間近でしか見ないから）。一方、飛行機の場合、例えば、５個のＬＯＤが必要になるかもしれない（色々な距離から見る必要があるので）。異なるＬＯＤを送信することにより、フィーチャーの元々の所有者は当該フィーチャーを使用し続けることができ、その表示は通常のとおりである。一方、他のゲーム機は新しいフィーチャーを理解すること及び表示することができ、ゲームプレーヤは新しいフィーチャーと対話することができるようになる。但し、新しいフィーチャーの表示（グラフィックス）グレードは下がることもある。

低いクオリティのフィーチャーがゲーム機に送信される場合、背景に高いクオリティのＬＯＤを送信することにより自動的に低いクオリティのフィーチャーをアップグレードするようにしてもよい。このアップグレードは、例えば、ゲーム進行中に行われる。このようにすると、全てのゲーム機が最終的には各フィーチャーの最高クオリティのＬＯＤ（各ゲーム機が要求しているならば）を受信することになると共に、接続について周波数帯域制限があるときでも直ちに使用できるというクイック（ｑｕｉｃｋ）ソリューションを与えることができる。

場合によっては、例えば、ゲームが多数のゲームプレーヤにより行われる場合（例えば、ＭＭＯＲＰＧ：massively multiplayer online role-playing game：多人数同時参加型オンラインＲＰＧ）、ゲームがスタートする前若しくはゲーム中の小休止時に（例えば、カーレーシングのシミュレーションゲームにおいて新しいレースが始まる前に）全てのフィーチャーを配信することは不可能である。なぜなら、ゲームに参加してくる者は常に存在するし、ゲームから離れていく者も常に存在するからである。また、多数のゲームプレーヤがいる場合、各ゲーム機が保持している属性の相違が非常に大きなものとなることもある（例えば、何百万人ものゲームプレーヤの一人ひとりが、それぞれ自分用にカスタマイズしたアバターを有する場合があり得る）。このような場合、ゲーム機間のフィーチャー配信を、所定のパラメータに基づいて制限することができる。制限方法の例を、図５を参照して以下に説明する。

図５は、ゲーム世界における多くのキャラクタ５０１−５０４の仮想位置（virtual position）を示している。各キャラクタは、ゲーム機によってコントロールされる。ゲーム機間の属性の相違点を判断してその相違点を特定のゲーム機に配信する場合（ステップ２０３および２０４）、ゲーム世界における特定のゲーム機のゲームキャラクタに近いキャラクタを有するゲーム機に関連する相違点だけが、当該ゲーム機に転送される。図５に示された例では、エリア５０５が、第１のゲーム機によりコントロールされる特定のキャラクタ５０１の位置の周囲に画定されている。第１のゲーム機と、エリア５０５内の他のキャラクタをコントロールするゲーム機との間のフィーチャーの相違点に関するコードは、第１のゲーム機に配信される。しかし、第１のゲーム機と他のゲーム機（エリア５０５の外のキャラクタをコントロールしているゲーム機）との間の相違点に関するコードは、第１のゲーム機に配信されない。第２のエリア５０６は、第２のゲーム機によりコントロールされる別のキャラクタ５０２の位置の周囲に画定されている。第２のゲーム機と、第２のエリア５０６内のキャラクタをコントロールする他のゲーム機との間のフィーチャーの相違点に関するコードは、第２のゲーム機に配信される。

上記方法のフロー図の例が、図６に示されている。サーバは、あるゲームに参加している全てのゲーム機にポーリングして、属性情報を得る（ステップ６０１）。次いで、サーバは、各ゲーム機ごとに、ゲーム機に関連しているゲーム機のサブセット（グループ）を特定する（ステップ６０２）。例えば、図５の例では、第１のゲーム機に関連しているゲーム機のサブセットは、エリア５０５内に位置しているキャラクタをコントロールする全てのゲーム機によって構成される。サーバは、特定のゲーム機とサブセット内の他のメンバ（ゲーム機）との間の属性の相違点を特定する（ステップ６０３）。これら２つのステップ（ステップ６０２及び６０３）は、各ゲーム機に対して繰り返し行われ、サーバは各ゲーム機にコードを配信する（ステップ６０４）。配信されるコードは、ゲーム機と、サブセット内の他のゲーム機との間で特定されたフィーチャーの相違点（ステップ６０３から得られたもの）に関連したコードである。

尚、上記方法のステップの順序は、単なる一例であり、例えば、サーバは、ゲームに参加している１つのゲーム機と他のゲーム機との間の全ての相違点を特定し、サブセット等に基づいてその相違点をフィルタリングしてもよいことに留意されたい。

上記方法は、サーバによって周期的に（例えば、３０秒ごとに）実行されてもよい。あるいは、上記方法は、キャラクタがゲーム内で動き、特定のゲーム機に関連するゲーム機のサブセットが変わると、必ず実行されるようにしてもよい。このようにすると、上記方法は、ほぼ連続した形でサーバにより実行されることになる。その際、小量のコードがほぼ連続して各ゲーム機に配信される。

１つのゲーム機が２つ以上のキャラクタをコントロールする場合、ゲーム機に関連しているサブセットは、複数のサブセットの集合からなり、各キャラクタに関連している各サブセットがコントロールされる。

上述した方法によれば、（キャラクタ５０１をコントロールしている）第１のゲーム機がフィーチャーセットＡ、Ｂ及びＣを有し、（キャラクタ５０２をコントロールしている）第２のゲーム機がフィーチャーセットＡ、Ｂ、Ｃ及びＤを有するとすると、フィーチャーＤに関するコードは、サーバによって第１のゲーム機に配信される。しかし、（キャラクタ５０３をコントロールしている）第３のゲーム機がフィーチャーセットＡ、Ｂ、Ｃ及びＥを有しているとすると、フィーチャーＥに関するコードは、サーバによって第２のゲーム機に配信され（なぜならキャラクタ５０３がエリア５０６内にあるから）、第１のゲーム機には配信されない（なぜならキャラクタ５０３はエリア５０５内に無いから）。その結果、第１のゲームと第２のゲーム機により保持されるフィーチャーのミスマッチが大きくなる。しかし、それでも第１のゲーム機は適切に動作することができる。その理由は、キャラクタ５０３がキャラクタ５０１の近くに位置していないので、第１のゲーム機がキャラクタ５０３を表示する必要が無いからである。あるいは、その場合、第１のゲーム機は、第３のゲーム機が保持しているフィーチャーを使うだろう。よって、ゲーム機間でのフィーチャー配信（例えば、ステップ６０４において）は、１つ若しくは複数のパラメータ（例えば、特定のフィーチャーの所有権及び／若しくは制御権）により制限される。これについては以下において詳述する。

同じゲームに参加しているゲーム機同士の間の情報送信を制限することによって、ゲーム機とサーバとの間の不十分なネットワーク接続に起因する遅延は、最小化することができる。

（上記したような）ゲーム機のサブセットを特定するために使用されるエリアのサイズは、所定の１つまたは複数のパラメータに基づいて変化してもよい。エリアのサイズは、特定のゲーム機については固定してもよいし、ダイナミックに変化させてもよい。一例においては、エリアのサイズは、特定のゲーム機とサーバとの間の接続データレートに基づいて変化させてもよい。ゲーム機が、サーバに対して高データレート接続を有している場合、ゲーム機のエリアはより大きくすることができる。他の例では、エリアのサイズは、ゲームプレーヤによって料金が支払われたサービスレベルに依存してもよい（例えば、高い料金を要求する高いサービスレベルであれば、大きなエリアが提供される）。更に別の例では、エリアのサイズは、配信されるべきデータの量に依存してもよい。この場合、サーバからゲーム機にデータを配信するための目標データレートが存在する。目標データレートが存在する場合、エリアのサイズは、配信されるべきフィーチャーコードの量に基づいて変わる（例えば、新しいフィーチャーを有するキャラクタの密度に基づいて変わる）。目標データレートを使用すると、サーバとゲーム機との間のリンクの使用効率を上げることができる。別の例では、所定の数のゲーム機（例えば、１０個のゲーム機）についてのフィーチャーセットが比較できるように、エリアが変化する。尚、キャラクタとゲーム機との間に１対１の関係がない場合もある。なぜなら、１つのゲーム機が複数のコントローラを有し、各コントローラが異なるゲームプレーヤによって使用され、ゲーム世界において異なるキャラクタをコントロールする場合があるからである。

他の例においては、２つ以上のエリアを各キャラクタの周囲に画定して、各ゲーム機に関連する複数のゲーム機サブセットを決定する。例えば、（キャラクタ５０１をコントロールする）第１のゲーム機は、第１のエリア５０５内のキャラクタをコントロールする全てのゲーム機を含む第１の関連サブセットを有すると共に、第１のエリア５０５内に無く第２のエリア５０７内にあるキャラクタをコントロールする全てのゲーム機を含む第２の関連サブセットを有する。第１のゲーム機へのフィーチャーの配信（当該ゲーム機と第１の関連サブセット及び第２の関連サブセットのゲーム機との間の相違点に基づく）は、異なるパラメータによって制限される。例えば、第１のゲーム機と第１の関連サブセットのゲーム機との間の相違点に関する全てのコードは第１のゲーム機に配信されるが、第１のゲーム機と第２の関連サブセットのゲーム機との間のアバター（若しくは他の表示）の相違点に関するコードだけしか第１のゲーム機に配信されない。こうすることにより、第１のゲーム機は、第２のエリア５０７にある（第１のエリア５０５には無い）各キャラクタ（若しくは各アイテム）を正確に表示することができるが、他の相違点（例えば、所有しているレベルの相違点、武器の相違点、強さの相違点等）を受信しない。他の例では、低解像度のアバターコードは第２のエリア５０７内のキャラクタに関連して配信されるが、高解像度アバターコードは第１のエリア５０５内のキャラクタに関連して配信される。プログレッシブダウンロード技術は、まず低クオリティの画像をダウンロードし、続いて、更なるデータを連続ダウンロードする場合、及び表示画像のクオリティを向上させる場合に使用される。

更に別の例においては、上記したように、フィーチャーコードは複数の異なるクオリティのバージョンで存在してもよい。例えば、高ＬＯＤコードは第１のエリア５０５内にあるフィーチャーに関連して配信することができ、低ＬＯＤコードは第２のエリア５０７内にあるフィーチャーに関連して配信することができる。さらに、接続において利用可能なキャパシティがあれば、プログレッシブダウンロード技術または他の技術を使用して、エリア５０７内のフィーチャーのために高ＬＯＤコードを引き続きダウンロードすることができる。

他の例においては、複数のエリアを画定することができ、各エリアは、フィーチャーを配信する異なる所定のルールを有することができる。所定のルールとは、例えば、詳細度のレベル、フィーチャーのタイプ等である。

上記の説明においては、配信されるべきフィーチャーセットは、キャラクタの位置に基づいて決定された（図５に示されているように）。これに加えて（または、これに代えて）、フィーチャーは、フィーチャーの有効性レベル（ＬＯＥ：ｌｅｖｅｌ ｏｆ ｅｆｆｅｃｔ）に基づいて配信されてもよい。ＬＯＥは、（上述した）ＬＯＤに似ているが、コードのサイズではなく、オブジェクトの有効性のレベル（若しくは程度）をカバーする。例えば、３つの異なる武器のタイプ（ナイフ、戦車、爆弾）について検討する。ナイフは小さなオブジェクトであり、クローズアップしないと見えない。また、ナイフの有効性レベルは小さい。つまり、ナイフは局所的にしか使用できない。一方、戦車は大きなオブジェクトであり、遠くから見ることができるし、音を聞くこともできる。また、戦車は高い有効性レベルを有している。なぜなら、戦車は遠くから物を攻撃することができるからである。爆弾は物理的には小さなフィーチャーであるが、大きなＬＯＥを持つ。なぜなら、爆弾は非常に遠くにあっても（見えないほど遠くにあっても）、キャラクタに影響を与えることができるからである。高ＬＯＥを有するゲーム機は、当該ゲーム機のフィーチャーコードの配信を必要とする。この配信は、たとえ当該ゲーム機が、（フィーチャーコードを配信する必要がない）低ＬＯＥを有するゲーム機よりもキャラクタから離れた所に位置していても行われなければならない。従って、図５に示された例では、（キャラクタ５０１をコントロールする）第１のゲーム機は、第１のエリア５０５内のキャラクタをコントロールする全てのゲーム機を含む第１の関連サブセットを有することができると共に、第１のエリアよりかなり大きなエリア（例えば、第２のエリア５０７）内に位置する高ＬＯＥフィーチャーをコントロールする全てのゲーム機を含む第２の関連サブセットを有することができる。

別の例においては、（上記したような）画定される複数のエリアは、（上記したＬＯＤ及び／若しくはＬＯＥの使用に加えて若しくは代えて）フィーチャーのサイズに基づいて、（後続のフィーチャーの配信のために）ゲーム機のサブセットを決定するために使用することができる。例えば、上記したナイフ等の小さなフィーチャーは、第１のエリア５０５に関連している場合にのみ配信され、遠くから見ることができる大きな装置は、第２のエリア５０７内に存在するならば、そのフィーチャーコードを配信する。

ゲーム機間におけるフィーチャー配信は、配信されるべきフィーチャーのタイプに基づいて、優先順位が付けられる。このように優先順位を付けることは、本明細書に記載された他の技術とは独立して行われてもよいし、それらの技術に関連付けて行われてもよい。例えば、配信すべき優先順位が最も高いフィーチャーのデータは、キャラクタが、二本足の人間型ロボット（bipedal humanoid）か、４本足の物か、装甲車か、鳥などである。次に優先順位が高いのは、上記フィーチャーのデータと同様な情報であり、オブジェクトの基本的な機能性は当該キャラクタにより保持される。次に優先順位が高いのは、当該キャラクタの特別な動きのためのアニメーションである。これに続くのは、低ＬＯＤテクスチャ、高レベルのモデルの詳細、高ＬＯＤテクスチャである。このような優先順位を使用することにより、受信ゲーム機はまず、ゲームのオブジェクトに関する最も重要なフィーチャー情報を得て、その後、アニメーションやオブジェクトの詳細に関するより重要度が低い情報を得る。

上述した方法では、１つ若しくは複数のゲーム機が特定のフィーチャーを保持する場合に、フィーチャーに関するコードがサーバ若しくは１つのゲーム機と、他のゲーム機との間で配信される。こうすることにより、異なるフィーチャーセットを有するゲームプレーヤ同士が一緒にゲームに参加することができるが、受信ゲーム機によって、配信されたフィーチャーのその後の使用をコントロールする必要があるかもしれない。特に、フィーチャーに対して料金を払っている場合や、何らかの行為によって当該フィーチャーを獲得している場合、フィーチャーの使用のコントロールが必要になる場合がある。多くの新しい武器を購入したゲームプレーヤは、そのような武器を購入していない他のゲームプレーヤが後に無料で当該武器を使用できるようになるのであれば（例えば、当該武器を購入したゲームプレーヤに対して料金を支払わない場合）、当該他のゲームプレーヤと一緒にゲームをしようとは思わないであろう。従って、フィーチャーに所有者情報のタグを付けることができれば都合が良いだろう。

フィーチャーに関するコードに所有者情報のタグを付ける方法は多数ある。第１の例においては、コードは、当該コードに組み込まれた所有者情報を含み、当該所有者情報は暗号化されてもよい。所有者情報は、ゲームプレーヤに関連する識別子（例えば、ゲームプレーヤタグ、アカウント番号／加入者番号等）、または、ゲーム機に関連する識別子（例えば、特定のゲーム機のための独自のＩＤ）、または、ゲームプレーヤのグループ若しくはカテゴリに関連する識別子を含むことができる。場合によっては、フィーチャーは、識別された所有者がゲームに参加しているときにだけ、（サーバ若しくはゲーム機によって）使用可能とされてもよい。これは、暗号化されたコードがゲーム機間で送信され、暗号化キーが所有者により保持されるとこにより実現できる。この場合、ゲーム機の使用は、受信ゲーム機が暗号化キーにアクセスできる場合に限定される。別の例では、所有者情報は所有者の詳細情報を全く含まず、代わりに、所有者の更なる変更は認められない旨を表示する（例えば、フィーチャーはローン支払い中であり、ボラタイルな資産（ｖｏｌａｔｉｌｅ ａｓｓｅｔ）であることを表示する）。このように、所有者のプライバシーを守りつつ、フィーチャーコードを他のゲーム機に送信することができる。このように所有者情報に印を付けた（flagged）場合、その後、フィーチャーコードを捨てることができ、フィーチャーコードはゲームの終了まで（若しくは、別の適切な時まで）ずっと保持されないこともある。暗号化及び／若しくはデジタル署名を使用すると、所有者情報の改竄を防止することができる。デジタル著作権管理（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）方法を用いて、コードのコピーを防止することができる。

第２の例においては、各ゲームプレーヤ若しくは各ゲーム機は、当該ゲームプレーヤ若しくはゲーム機が所有するフィーチャーの一覧表（inventory）を有している。各フィーチャーは独自のＩＤを有し、このＩＤはオブジェクトに安全な形態で付けられるか、オブジェクト内において暗号化される。このＩＤを使用して、フィーチャーを一覧表にリンクさせることができる。一覧表は、ゲーム機、または、サーバに保存することができる。また、一覧表を暗号化して、改竄を防止することができる。さらに、サーバ若しくはゲーム機は、保存された一覧表を参照してフィーチャーをチェックすることにより、ゲームに参加しているいずれのプレーヤにも所有されていないフィーチャーが使用されることを防止することができる。

第３の例においては、サーバが、ゲームのフィーチャーのための所有者情報用中央レジスタ（central ownership register）を保持する。フィーチャーがゲーム機にダウンロードされる（例えば、ステップ２０４若しくはステップ６０４）前に、レジスタはサーバとゲーム機によってチェックされる。このような中央レジスタを使用すると、より安全になるので、好ましい。レジスタは、所有権の移転も全て記録することができる。レジスタをこのように使用することにより、（例えば、全ての所有者の履歴、及び／または、フィーチャーの寿命の間（lifespan）の主な出来事（key event）のリストを記憶することによって）保有されるデータの量が拡張されてしまうことがあるが、この拡張は、フィーチャーデータの実際のサイズを拡張することなく行うことができる。従って、データをゲーム機間で送信するときに、多くのデータを送信することができるようになる。別の例においては、中央レジスタと、ゲームプレーヤ／ゲーム機に関連する個々の一覧表とを使用することができる。

オブジェクト若しくは他のフィーチャーの所有権の移転は、（後述するように）ゲーム内で起こるか、または、（例えば、ウェブ上での販売／オークションサイトを介して）ゲーム外で起こる。移転がゲーム外で起きる場合、ゲームプレーヤ同士がゲーム世界で会う場合にのみ当該移転は有効となる。この時点で、所有者タグ（または他の所有者情報：例えば、レジスタ内にある所有者情報）が更新される。

サーバ及び／またはゲーム機は、識別子が改竄された場合若しくは間違った識別子がフィーチャーデータに挿入された場合に、フィーチャーまたはオブジェクトを拒絶するように構成されてもよい。さらに、オブジェクトは、他の状況や条件に基づいて、自動的に除去されたり追加されたりしてもよい。一実施例において、オブジェクトがウェブ上の売買サイトを介して別人に売られた場合、販売者と購入者がゲーム世界において会うと、そのオブジェクトは自動的に追加される。オブジェクトは販売者と購入者との間の取引（transaction）の後、一時的に除去状態／停止状態にされている。別の例においては、アイテム／フィーチャーの所有権が移転された後に購入者が支払いをしない場合、販売者は、購入者との話し合いが解決するまで、フィーチャーのコントロールの除去をリクエストすることができる。別の例においては、ゲーム中にアイテムが盗まれることもあり（盗み許容範囲を超えた盗み）、その場合には、状況が適正化されるまで、アイテムを停止状態、または使用不能状態にする必要がある（例えば、モデレータによって行われる）。他の例においては、理由がどうであろうと、不完全になってしまったアイテム若しくは汚染されてしまったアイテムは、全てが除去されるか、若しくは修正されるまで停止状態にされる。更に別の例においては、ゲーム世界に入ったがゲームプレーヤ、モデレータ若しくは他のコントロールエンティティによって「望まれないもの」とみなされたアイテムは、停止状態にされるか、削除されるか、または、ゲームから除去される。

上記したように、ゲーム機間におけるフィーチャー配信は、幾つかの場合において（例えば、ステップ６０４において）１つ以上のパラメータによって（例えば、特定のフィーチャーの所有者がだれなのかによって）制限される。図７は、そのような制限を組み込んだ場合のステップ２０２の詳細を例示したフロー図である。ゲーム機をポーリングして属性情報を得る（ステップ２０２ａ）。次いで、属性情報において見つけられた各フィーチャー毎に、そのフィーチャーの所有者をチェックする（ステップ２０２ｂ）。受信した属性情報は、その後、フィルタリングされ（ステップ２０２ｃ）、属性情報発信元であるゲーム機若しくはゲーム機にログインした（若しくは他の方法によりゲーム機に関連してきた）ゲームプレーヤによって所有されていないフィーチャーへの参照を除去する。よって、後続のステップ（例えば、図２若しくは図６のステップ）において、相違点の比較はゲーム機／ゲームプレーヤによって所有されている属性にのみ関係することになる。従って、フィーチャーに関するコードの配信（ステップ２０４またはステップ６０４）は同様に制限される。

図５に関連して上述した特定の例においては、（キャラクタ５０１をコントロールする）第１のゲーム機はフィーチャーＡ、Ｂ及びＣを所有し、（キャラクタ５０２をコントロールする）第２のゲーム機はフィーチャーＡ、Ｂ、Ｃ及びＤを所有し、（キャラクタ５０３をコントロールする）第３のゲーム機はフィーチャーＡ、Ｂ、Ｃ及びＥを所有する。よって、フィーチャーＤに関するコードはサーバによって第１のゲーム機へ配信され、フィーチャーＥに関するコードはサーバによって第２のゲーム機へ配信される。これにより、第１のゲーム機はフィーチャーＡ−Ｃしか所有（own）していないが、フィーチャーＡ−Ｄを所持（hold）するようになる。また、第２のゲーム機はフィーチャーＡ−Ｄしか所有していないが、フィーチャーＡ−Ｅを所持するようになる。第１のゲーム機及び第２のゲーム機によって所持されるフィーチャーは同一ではないが、フィーチャーを更に配信する必要はない。なぜなら、第１のゲーム機は第２のゲーム機が所有しているフィーチャーを全て所持しているし（第２のゲーム機は第１のゲーム機に関連しているエリア５０５内にある）、逆のことも言える（第１のゲーム機は第２のゲーム機に関連しているエリア５０６内にある）からである。

上記の説明はゲーム内におけるキャラクタについてなされたが、本発明の方法は、ゲーム内の他の制御可能なオブジェクト（例えば、ビークル、若しくは、建造物や風景等のユーザが作ったオブジェクト）に対しても適用可能である。

上述した例では、フィーチャーコードの配信がエリアおよび所有者によって制限されたが、これら２つのフィルタは独立して使用されてもよいし（例えば、所有者だけに基づいてフィルタリングする）、フィーチャーコードの配信はＬＯＤ、ＬＯＥ等を含む任意の適切なパラメータを使用してフィルタリングされてもよい。

所有者情報のタグをフィーチャーに付けること（例えば、上述したようにコード内で、若しくは、一覧表／レジスタを利用して）に加え、他の情報のタグをフィーチャーに付けても良い（例えば、使用範囲、タイムスタンプ等）。他の情報は、一時的な情報であり、例えば、コントロールするゲーム機／ゲームプレーヤ（所有者とは異なる）を特定する。例えば、フィーチャーには、どのゲーム機がフィーチャーを制限時間だけ使用できるのかを示す情報のタグが付けられる。これを利用することにより、フィーチャーのコントロールをゲーム中に、そのフィーチャーを所有しているゲーム機（例えば、所有者若しくは、所有権がゲーム機にリンクしているのではなくゲームプレーヤにリンクしている場合の所有者が関連しているゲーム機）から他のゲーム機へ移すことができる（例えば、新しい武器がゲーム世界において別のキャラクタによって獲得された場合）。この例について、以下に詳細に説明をする。フィーチャーには、上述したように所有者情報と同じように、あるいは異なる方法で、他の情報のタグを付けることができる。その情報が一時的なものであり、将来におけるある時点で無効なものになる場合には、特に、その情報を暗号化する必要はない。なぜなら、改竄について、あまり心配する必要がないからである。コントロールエンティティとオーナーエンティティが異なる場合、サーバは次のことをチェックする必要がある。即ち、サーバは、指定された時間内に、オーナーエンティティが特定のフィーチャーを使用していないかどうかをチェックする必要がある。このような例では、フィーチャーコードの配信は所有権とコントロールとによって制限される（特に、エリアによっても制限される場合）。

上記した方法を使用してゲーム機に配信されたフィーチャーは、次のゲームにおいて、色々な形態でゲーム機によって用いられる。第１の例では、フィーチャーコードを用いて、表示が受信ゲーム機において正確になされるようにすることができる（例えば、別のゲームプレーヤにより購入された新しい武器の画像を正しく表示されるようにする）。別の例では、ゲーム機は、ゲーム中に受信したすべてのフィーチャーを使用することができる。例えば、新しい武器が別のゲームプレーヤによって購入され、関連コードがゲーム機に配信された場合、その新しい武器は、ゲームに参加している全てのゲーム機により使用可能となる。新しいフィーチャーが新しいハードウエア（例えば、ガン）に関連している場合、そのコードを用いることにより、他のゲーム機が、既存のコントローラ若しくは周辺機器を利用してそのハードウエアをエミュレートできるようにする。フィーチャーの使用方法は、サーバによって指定するか、または、フィーチャーコード内で指定することができる。

フィーチャーが全てのゲーム機によって完全に使用できるものではない場合、フィーチャーのコントロールをゲーム中に変更してもよい（例えば、キャラクタがアイテムを盗む／借りる／ローンで購入する場合）。このような状況では、そのフィーチャーに関連したコントロールタグが変更され、別のゲーム機がそのフィーチャーを（限定された時間だけ）完全に使用できるようにし、フィーチャーを所有しているゲーム機はそのフィーチャーを完全には使用できなくなる。上記したように、コントロール（及び所有者）を記録するために、コントロールタグに加えて若しくはその代わりに、一覧表または中央レジスタを使用してもよい。従って、コントロールの移転は、一覧表、レジスタ若しくは他の適切な手段に記録されることもある。このようなコントロールの移転が行われると、オーナーとゲーム機のコントロールを取得するゲームプレーヤとの間でマイクロペイメント（小額決済）が取り交わされる。また、ゲーム世界の中でフィーチャーを販売したり交換したりすることもできる。例えば、マイクロペイメント若しくは他のフィーチャーと引き換えに、フィーチャーの販売や交換を行うことができる。このような場合、（例えば、所有者タグ、一覧表、レジスタ等において）所有者情報が更新される。

ゲーム内でのフィーチャーの使用は、広告／販売ウインドウとリンクしている場合がある。第１のゲーム機によりコントロールされるキャラクタが、異なるフィーチャー（例えば、新しい武器）を所有するキャラクタによって攻撃／接近されると、ウインドウが現れて異なるフィーチャーの詳細を提示する（例えば、「あなたは今、武器Ｘにより攻撃されました」とか、「あなたは今、新しい技Ｙを持つキャラクタによって攻撃されました」等）。その詳細は、フィーチャーの説明とそのフィーチャーを購入する（例えば、マイクロペイメントにより購入する）ためのリンク／ボタンとを含んでもよい。そのリンク／ボタンによって、フィーチャーを、店舗から（例えば、サーバによって管理されている店舗から）、または、現在の所有者から（例えば、「あなたは今、武器Ｘを使用して攻撃されました。武器Ｘを購入しますか？」）購入することができる。

各ゲームプレーヤが所有するフィーチャーセットの相違点に関する情報は、例えば、アップグレード（またはフィーチャー）リストとして、各ゲームプレーヤに対して表示することができる。これにより、ゲームプレーヤは同じゲームに参加している他のプレーヤが保持しているフィーチャーをレビューすることができ、ゲームプレーヤは、アップグレードすべきか、ゲームを続けるべきか等を判断することができる。このリストは所定のリンクを含んでもよく、リンクによってフィーチャーを購入することや、例えば、トライアルとして、所定時間だけフィーチャーを借りることができる。一覧表情報は、（ステップ２０２のように）全てのゲーム機にポーリングを行うことによってサーバにより収集される。この収集は、（例えば、ゲームに参加したいというリクエストを受信する前に）ゲーム機がサーバに接続したときに行われる。そうすることにより、ゲームプレーヤがゲーム参加を決定する前に、情報をゲームプレーヤに表示することができる。

上述した例のおいては、色々なゲーム機によって保持されているフィーチャーセットの相違点がゲーム機に配信され、共通のフィーチャーセットを与えている。しかし、別の例においては、いずれのゲーム機によっても所有されていないフィーチャーがサーバにより各ゲーム機に配信されてもよい。例えば、所定数のゲーム（例えば、１つのゲーム）に対してだけ、若しくは所定時間（例えば、２４時間）だけ、そのフィーチャーを無料トライアルの一部として配信してもよい。このような場合、広告／販売用のウインドウ（上述したもの）を、ゲーム機のディスプレイを介してゲームプレーヤに提示してもよく（例えば、ゲームの終了時に、または、２４時間のトライアル時間の終了間近に）、ゲームプレーヤがトライアル時間の間または終了時に素早く且つ簡単にそのフィーチャーを購入する方法を提供する。

ゲーム機はサーバから受信したフィーチャーの全てを使用できるが、そのフィーチャーを所有していない場合、または、ゲーム機が所有権を持たないフィーチャーのコントロールを獲得した場合、そのフィーチャーの本当の所有者がゲーム参加を止めても、ゲームに参加している他のゲーム機に対してはゲームが終了するまでそのフィーチャーを使用できるようにしてもよい。ゲーム機が意図せずに接続解除された（そして短時間内に再接続する）場合、上記のようにすれば、フィーチャーのチャーン（ｃｈｕｒｎ）を低減することができ（チャーンは、ゲームで得られる経験内容を低下させる）、フィーチャーコードの配信を最小限にすることができる。別の例では、フィーチャーの所有者が外れるとすぐに、サーバが全ゲーム機に信号を送り、そのフィーチャーの使用を無効にしてもよい。

追加のフィーチャーデータを受信すると、上記したように、そのデータはゲーム機に保存される（例えば、コンソール１０３内のメモリ８０１（図８）に、若しくは外部メモリに保存される）。図８は、コンソール１０３の詳細を示した図である。このコンソールは、メモリ８０１に接続されたプロセッサ８０２と、ディスプレイＩ／Ｏ８０３と、コントローラＩ／Ｏ８０４と、ネットワークインターフェース８０５を有する。メモリ８０１はプロセッサ８０２用の命令を記憶するために設けられている。この命令により、プロセッサ８０２は上記した方法のステップの幾つか若しくは全てを実行する。メモリは、受信したフィーチャーデータ（上述したもの）を記憶するために使用してもよい。受信したフィーチャーデータ（ネットワークインターフェース８０５を介してネットワークから受信される）は、ユーザにより入力されたコマンドに対応して消去されるまで、ゲーム機により保持される（つまり、手動消去であり、例えば、コントローラＩ／Ｏ８０４を介して受信された信号により消去される）か、自動的に消去される。ダウンロードされたフィーチャーは、ゲーム終了時に消去されるか、セッション終了時に消去されるか、ゲーム機の電源ＯＦＦ時に（若しくはスタンバイ状態にされると）消去されるか、所定時間後に（例えば、フィーチャー不使用時間が２４時間を超えると）消去されるか、またはこれら以外の適切な時点で消去される。他の例では、フィーチャーの所有者が外れる（drop out）と信号をサーバから受信し、この信号により関連フィーチャーの自動消去が開始される（信号がトリガとなる）。トリガは、別の例においては、フィーチャーを所有しているゲーム機から受信する。他の例では、ゲーム機に付随しているメモリ（内部メモリであっても外部メモリであってもよい）の占有量が一杯になるか、または閾値に達すると（例えば、メモリが９０％使用状態になるか、メモリ残量が１００ＭＢになったときに）、コードを消去してもよい。

データを消去するときのフロー図の一例が図９に示されている。メモリを消去するためのトリガが、ゲーム機によって受信される（ステップ９０１）。このトリガは、ゲーム機の外部（例えば、サーバ若しくは別のゲーム機）から受信されてもよいし、ゲーム機内で生成するようにしてもよい（例えば、メモリ占有量が閾値を超えると生成される、または、コントローラへの入力があると生成される等）。次いで、コードがゲーム機に保存されているがフィーチャーがそのゲーム機（若しくはそのゲームプレーヤ）により所有されていない場合、ゲーム機はゲームの全フィーチャーを特定する（ステップ９０２）。特定されたフィーチャーのうち、現在のゲームにおいて誰にも所有されていないフィーチャーの全てが特定され（ステップ９０３）、このように残っているフィーチャーに関連するコードが消去される（ステップ９０４）。ゲームがすでにストップしている場合、ステップ９０３ではフィーチャーをフィルタリング除去しない。なぜなら、現時点でゲームにゲーム機／ゲームプレーヤは存在しないからである。

上記の説明は、図１、およびより詳細には図１０に示されているように、サーバ１０２によって接続された複数のゲーム機１０１で構成されるネットワークに関連している。サーバ１０２は、プロセッサ１００１、メモリ１００２及びネットワークインターフェース１００３を備える。メモリ１００２は、ゲームのフィーチャーに関連したコード及び／または、プロセッサに上記方法の１つまたは複数のステップを実行させる命令を保存するように構成されている。しかし、上記方法は、ゲーム機１０１からなるネットワーク１１００にも適用可能である。このネットワークでは、図１１に示されているように、サーバにより管理されることなく、ゲーム機同士が相互接続されている。ゲーム機は、互いに直接接続されてもよいし（例えば、ネットワークを介して接続されたり、直接リンクを介して接続されたり）、他の中間装置（例えば、他のゲーム機）を介して、例えばピアトゥピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）ネットワークで相互に接続されてもよい。このようなネットワークにあっては、複数のゲーム機のうちの１つのゲーム機がホストとして動作し、フィーチャーの配信を制御する（例えば、ステップ２０２−２０４を実施する）。１つのゲーム機がランダムに特定されてホストとして動作してもよいし、あるいは、ホストは所定の条件に基づいて選択されてもよい（例えば、最初にゲームに参加したものを選択してもよいし、最初にゲーム参加リクエストを出したものを選択してもよいし、最も大きなフィーチャーセットを有しているものを選択してもよいし、他のゲーム機と比較して最も大きな相違点を有しているものを選択してもよい）。指定されたホストが接続解除したり、ゲーム参加を止めたりした場合、他のゲーム機のうちの１つがホストになる。ゲーム機がホストとして動作する場合、ホストは必ずしも全てのフィーチャーのコードを保持しないことがあり、よって、ホストは他のゲーム機からコードをアップロードする必要がある（図３及び図４に示したように）。

上記の方法では、相違点の計算はホスト（例えば、サーバまたはゲーム機）によって集中的に行われた。しかし、上記方法は、（サーバが存在しようとしまいと）分散方式で行われてもよい。その場合、各ゲーム機が、当該ゲーム機にとってどんなフィーチャーデータが必要なのかを決め、適切なコードを保持しているゲーム機に対してそのフィーチャーをリクエストする（例えば、各ゲーム機がステップ２０２−２０４を実施する）か、サーバに対してそのフィーチャーをリクエストする（もしサーバが存在すれば）。

別の例においては、図１１に示されたゲーム機１０１は、ピアトゥピア形式（１つのゲーム機が支配するような形式ではない）で動作する。各ゲーム機は、標準的なピアトゥピア技術を使用して、ゲーム機間の通信を行い、ゲーム機間において複雑なパラレルネットワークメッシュでフィーチャーデータを配信することができる。実際の例においては、第１のゲーム機がフィーチャーセットのリストをコンパイルし、リストを次のゲーム機に送信する。次のゲーム機は、そのリストを解析して、どんなフィーチャーがゲーム機によって保持されているかをそのリストに記載し、且つ前のゲーム機のフィーチャーのうちのどれをゲーム機が保持していないのかをそのリストに記載する。このリストは、各ゲーム機に順次送信され、各受信ゲーム機は上記したようにリストに注釈を付ける。全てのゲーム機によって注釈が付けられると、リストは第１のゲーム機に返送される。この時点で、システム内の各ゲーム機は、他のゲーム機がどんなフィーチャーを保持しているかを知り、自分が保持しているフィーチャーデータをどのゲーム機が必要としているかを知る。そして、各ゲーム機は、他のゲーム機が必要としているフィーチャーデータを他のゲーム機に提供する。

このピアトゥピア形式の他の例では、各ゲーム機は、自分が持っているフィーチャーのリストをネットワーク内の他のゲーム機のそれぞれに送信する。ネットワーク内の他のゲーム機のそれぞれからリストを受信すると、全てのゲーム機は、どのゲーム機が自分が保持しているコードを送ってほしいのかを知ることができる。次いで、コードはそのフィーチャーを要求する他のゲーム機に提供される。あるいは、ゲーム機は受信したリストを使用して、ネットワーク内の特定の他のゲーム機からフィーチャーデータを得るためのリクエストをすることができる（つまり、自分からリクエストをしないでフィーチャーデータが提供されるのではない）。フィーチャーセットに関するデータをピアトゥピアネットワークのゲーム機間で共有し、フィーチャーセットの相違点に関するコードがゲーム機間で配信できるようにする方法は、上記した方法以外にもあるだろう。

上述した例においては、ゲームに関するコードはゲーム機上で実行される。しかし、コードがサーバ上で実行される場合でも、上記の方法を適用することができる。この場合、サーバは各ゲーム機に関連している属性（若しくは一覧表）をチェックする。そして、サーバは、相違点をゲーム機にダウンロードする代わりに、ゲームに参加している全てのゲーム機が、特定のゲーム機に接続されている全ゲーム機により所有されているフィーチャーの全てにアクセスできるようにする。

上述した例は、同じゲームに参加している複数のゲーム機に関するものであるが、上記方法は、別々のオンラインゲームゲーム世界（ｇａｍｉｎｇ ｗｏｒｌｄ）を統合する場合にも使用できる。一例においては、２つの別々のゲーム世界において、オブジェクト／フィーチャー／アップグレードの幾つかにオーバーラップする部分があることがある。例えば、ゲーム世界Ａは、ガンとナイフを有し、ゲーム世界Ｂは、ガンと爆弾を有することがある。従って、ナイフと爆弾のコンセプトは、それぞれのゲーム世界においてのみ知られているが、ガンは双方で知られている。従って、２つのゲーム世界が接続された場合、ガンについては意味のある配信ができる。このような場合、ＸＭＬを使用して、ゲーム世界若しくはそのデータ（ガン、ナイフ、または爆弾のデータ）をエクスポートし、受信側のゲーム世界は、受信側のゲーム世界で理解することができるオブジェクトに関するデータをエクスポートされてきたものから取ることができる。よって、上述した例の場合、ゲーム世界Ａは全てのガンとナイフの詳細情報を含むＸＭＬを配信するが、ゲーム世界Ｂは受信ＸＭＬデータからガンのデータだけを取り、ナイフのデータは無視する。ＸＭＬは利用可能なメカニズムの単なる一例にすぎず、他の方式を採用してもよい。

上記の説明において、フィーチャーは、特定のゲームプレーヤ、または、ゲームプレーヤが関連しているゲーム機に関連して特定される。別の例においては、識別子を使用して、その識別子をゲームプレーヤのグループ、または、ゲームプレーヤのカテゴリに関連させることができる。このように、ゲームプレーヤグループまたはゲームプレーヤカテゴリに関連している識別子を使用すると、例えば、ゲーム世界若しくはゲームコミュニティにおける特定のチーム、ランク若しくは到達レベルにフィーチャーを関連させることができる。フィーチャーは、ゲームプレーヤの特定のグループやゲームプレーヤの特定のカテゴリに関連する特権を含んでもよい。

上記の例は、ゲーム機により構成されるネットワークで実施されるように説明されたが、上記したシステムは単なる一例であり、これに限定されない。当業者であれば、上記の例は、複数のゲーム機を有する色々な種類のネットワークに適用することができることは理解できるであろう。ネットワークは、ゲーム専用のものである必要はなく、ゲーム機は多くの他の機能を有していてもよい（後述するように）。

本明細書に記載された方法は、記憶媒体に機械読み取り可能な形態で記憶されたソフトウエアにより実行されてもよい。このソフトウエアは、パラレルプロセッサまたはシリアルプロセッサ上で実行されるのに適しているソフトウエアとすることができ、上記方法のステップを、任意の適切な順序で、または同時に実行することができる。

このことは、ソフトウエアが価値のある且つ分離売買可能な商品であることを示している。データ処理機能を備えない端末装置（ｄｕｍｂ）若しくは標準的なハードウエアで実行されたり、制御を行ったりするソフトウエアであって、所望の機能を実行するためのソフトウエアは、上記ソフトウエアに含まれる。従って、ソフトウエアは、実質的にレジスタの機能を決定することになるので、（たとえソフトウエアが標準的なハードウエアに組み込まれる前であっても）レジスタと称することができる。同様な理由により、ハードウエアの構成を記述したり定義したりするソフトウエア（例えば、ＨＤＬ（ｈａｒｄｗａｒｅ ｄｅｓｃｒｉｐｔｉｏｎ ｌａｎｇｕａｇｅ：ハードウエア記述言語）ソフトウエア）も、所望の機能を実行するための上記ソフトウエアに含まれる。これは、シリコンチップを設計するときに使用されたり、ユニバーサルプログラマブルチップ（ｕｎｉｖｅｒｓａｌ ｐｒｏｇｒａｍｍａｂｌｅ ｃｈｉｐｓ）を構成したりするときに使用される。

当業者であれば、プログラム命令を記憶するために使用される記憶装置を、ネットワーク全体に分散してもよいことが理解できるであろう。例えば、リモートコンピュータは、ソフトウエアとして説明されたプロセスの一例を記憶してもよい。ローカルコンピュータまたはターミナルコンピュータがリモートコンピュータにアクセスし、ソフトウエアの一部若しくは全部をダウンロードして、プログラムを実行してもよい。あるいは、ローカルコンピュータがソフトウエアのうちの必要な部分をダウンロードしてもよいし、ローカルターミナルにおいてソフトウエアの命令の一部を実行し、且つリモートコンピュータ（若しくはコンピュータネットワーク）においてソフトウエアの命令の一部を実行してもよい。当業者であれば、当該技術分野で当業者に知られている従来の技術を使用することにより、ソフトウエアの命令の全部若しくは一部を専用回路（例えば、ＤＳＰ、プログラマブルロジックアレイ（デバイス）等）によって実行させてもよいことが理解できるであろう。

本明細書において「ゲーム機」及び「ゲームコンソール」という用語は、ユーザがゲームをすることができる任意の装置を意味する。任意の装置とは、例えば、専用のゲームコンソール（Ｘｂｏｘ（登録商標）、Ｘｂｏｘ３６０（商標）等）、コンピュータ、ＰＤＡ、携帯電話等であるが、これらに限定されるわけではない。上記において説明されたゲーム機は、コンソール、ディスプレイ及びコントローラを有しているが、これは単なる例示であり、上記した機能の幾つか／全ては統合されてもよいし（例えば、手持ち型のゲーム機の中に一体化する）、ゲーム機は全ての機能を有していなくてもよい（例えば、コンソールはテレビに接続されてもよい。テレビはゲームを表示するために使用されるが、ゲーム機自体の一部ではない）。

本明細書において「フィーチャー（ｆｅａｔｕｒｅ）」という用語は、ゲームにおける任意の（全ての）アスペクトを意味する。例えば、フィーチャーは、アイテム（例えば、武器、所持品、乗り物等）、背景／環境（例えば、建造物、内装、地形等）、音楽、アバター、モデル、テクスチャ、アニメーション、その他の能力／手段、ゲームレベル、アップグレード等をあらわすが、これらに限定されるわけではない。能力／手段は、戦術のコマンド、動き等を含み、訓練、経験、購入、借用、盗み、昇格等によって獲得される。能力／手段が、経験、訓練若しくは昇格によって獲得された場合、能力／手段は、ゲームプレーヤのグループに関連する（上述したとおり）。

本明細書において「コンピュータ」という用語は、命令を実行することができる処理能力を備えた装置を意味する。当業者であれば、このような処理能力が多くの異なる装置に組み込まれていることが理解できるであろうし、従って、「コンピュータ」という用語はＰＣ、サーバ、携帯電話、ＰＤＡ及びその他の多くの装置を含むことが理解できるであろう。

上記において説明された複数の方法におけるアイデア及び個々のアスペクト（態様、特徴、構成）は、個別に使用することもできるし、任意の組み合わせで使用することもできる。上記した複数の例がアイデアを組み合わせで使用している場合、それは単なる一例であって、アイデアの使用の形態を限定するものではない。

ここで示された範囲や装置の数は、当初予定されていた効果を失うことなく、拡張若しくは変更できることは、当業者には明らかであろう。

本明細書で説明された方法のステップは任意の適切な順序で実施することができるし、（それが適正であるなら）同時に実施してもよい。方法においてステップを繰り返し行うこと（例えば、図６においてステップ６０３からステップ６０２へ戻るループ）は、例示として示されただけであり、他の形で実施してもよい（例えば、ステップ６０４からステップ６０２へ戻るループにする）。

好適な実施例の上記説明は、単なる例示であり、当業者であれば色々な変更をすることができるであろう。上記した説明、実施例及びデータは、本発明の例示的実施形態の構造及び使用に関する十分な説明を提示している。本発明の種々の実施形態がある程度の詳細度をもって上述され、あるいは、１つ以上の実施形態を参照して説明されたが、当業者であれば本発明の趣旨若しくは範囲から離れることなく、開示された実施形態に多くの変更をなすことができるであろう。

Claims (19)

1. ゲーム機（１０１）同士を接続して、複数人参加型のゲームを可能にする方法であって、
   複数のゲーム機からデータを受信するステップであって、前記データは、前記複数のゲーム機の各々に関連するゲームのフィーチャーの詳細を示すステップと、
   前記複数のゲーム機のうちの第１のゲーム機に関連する１つ以上の必要とされるフィーチャーを決定する決定ステップであって、前記必要とされるフィーチャーは、前記複数のゲーム機の１つに関連し、且つ前記複数のゲーム機の前記第１のゲーム機には関連しないフィーチャーを備えるステップと、
   前記必要とされるフィーチャーに関するコードを、前記複数のゲーム機の第１のゲーム機に送信する送信ステップと、
   前記複数のゲーム機の各々について、前記決定ステップと前記送信ステップを繰り返すステップと
   を含むことを特徴とする方法。
2. 前記コードを送信する送信ステップの前に、
   前記ゲームの前記フィーチャーに関するコードの記憶部にアクセスするステップ（８０１、８０２）と、
   前記必要とされるフィーチャーの各々に関するコードが前記記憶保存部に記憶されているかどうかを判断するステップと、
   記憶されていなければ、前記コードを前記複数のゲーム機の１つから得るためのリクエストをするステップと
   をさらに含むことを特徴とする請求項１記載の方法。
3. 前記必要とされるフィーチャーに関するコードを前記複数のゲーム機の前記第１のゲーム機に送信するステップは、
   所定のパラメータに基づいて前記必要とされるフィーチャーをフィルタリングするステップと、
   フィルタリングされた前記必要とされるフィーチャーに関するコードを、前記複数のゲーム機の第１のゲーム機に送信するステップと
   を含むことを特徴とする請求項１または２に記載の方法。
4. 前記必要とされるフィーチャーを所定のパラメータに基づいてフィルタリングするステップは、
   所定のパラメータに基づいて前記複数のゲーム機の第１のゲーム機に関連する前記複数のゲーム機のサブセットを特定するステップと、
   前記必要とされるフィーチャーをフィルタリングして、フィルタリングされた前記必要とされるフィーチャーが、前記複数のゲーム機の前記サブセットの１つに関連し、且つ前記複数のゲーム機の前記第１のゲーム機に関連しない１つ以上のフィーチャーを含むようにするステップと
   を含むことを特徴とする請求項３記載の方法。
5. 前記複数のゲーム機の前記第１のゲーム機に関連関連する前記複数のゲーム機のサブセットを特定するステップは、
   前記複数のゲーム機の各々によってコントロールされるゲームにおけるオブジェクトのゲームポジションを判断するステップと、
   所定のパラメータに基づいて、前記複数のゲーム機の前記第１のゲーム機によってコントロールされるオブジェクトのゲームポジションの周りにエリアを画定するステップと、
   前記エリア内に配置されたオブジェクトを特定するステップと、
   前記特定されたオブジェクトをコントロールする前記複数のゲーム機のうちの１つ以上のゲーム機を判断するステップと
   を含むことを特徴とする請求項４記載の方法。
6. 前記所定のパラメータは、前記複数のゲーム機の第１のゲーム機への接続のデータレートと、前記複数のゲーム機の第１のゲーム機への目標データ配信レートとのうちの、一つ以上を含むことを特徴とする請求項４または５記載の方法。
7. 前記必要とされるフィーチャーを所定のパラメータに基づいてフィルタリングするステップは、
   前記必要とされるフィーチャーの各々についての所有者情報を判断するステップと、
   前記必要とされるフィーチャーをフィルタリングして、前記複数のゲーム機の１つのゲーム機、または、前記複数のゲーム機の１つのゲーム機に関連するゲームプレーヤによって所有されていないフィーチャーを除去するステップと
   を含むことを特徴とする請求項３記載の方法。
8. 前記必要とされるフィーチャーに関するコードは、所有者情報を含むことを特徴とする請求項１乃至７のいずれかに記載の方法。
9. 前記所有者情報は、ゲーム機、ゲームプレーヤ若しくはゲームプレーヤグループを特定することを特徴とする請求項８記載の方法。
10. 前記複数のゲーム機からデータを受信するステップの前に、
    前記複数のゲーム機の各々からゲームに参加したいというリクエストを受信するステップと、
    前記複数のゲーム機の各々からデータを得るためのリクエストをするステップであって、前記データは、前記複数のゲーム機の各々に関連するゲームのフィーチャーの詳細を示すステップと
    をさらに含むことを特徴とする請求項１乃至９のいずれか１に記載の方法。
11. 所定のルールに基づいて前記複数のゲーム機の１つのゲーム機を受信することによって、前記必要とされるフィーチャーの使用を可能にするステップをさらに含むことを特徴とする請求項１乃至１０のいずれかに記載の方法。
12. 複数のステップを実行するための装置実施可能命令を有する１つ以上の装置読み取り可能媒体であって、前記複数のステップは、
    複数のゲーム機（１０１）からデータを受信するステップであって、前記データは、前記複数のゲーム機の各々に関連するゲームのフィーチャーの詳細を示すステップと、
    前記複数のゲーム機のうちの第１のゲーム機に関連する１つ以上の必要とされるフィーチャーを決定する決定ステップであって、前記必要とされるフィーチャーは、前記複数のゲーム機の１つに関連し、且つ前記複数のゲーム機の前記第１のゲーム機に関連しないフィーチャーを含むステップと、
    前記必要とされるフィーチャーに関するコードを、前記複数のゲーム機の前記第１のゲーム機に送信する送信ステップと、
    前記複数のゲーム機の各々について、前記決定ステップと前記送信ステップを繰り返すステップと
    を含むことを特徴とする装置読み取り可能媒体。
13. 複数のゲーム機（１０１）を接続して、複数人参加型のゲームを可能にする方法であって、該方法は、前記複数のゲーム機の第１のゲーム機において、
    前記複数のゲーム機の第１のゲーム機に関連するゲームのフィーチャーの詳細を示すデータを、リモートデバイスに送信するステップと、
    必要とされるフィーチャーのセットに関するコードを受信するステップであって、前記必要とされるフィーチャーは、前記複数のゲーム機の１つのゲーム機に関連し、前記複数のゲーム機の第１のゲーム機に関連しないフィーチャーを含むステップと、
    前記受信したコードを記憶するステップと
    を含むことを特徴とする方法。
14. 前記ゲームのフィーチャーの詳細を示すデータを送信するステップの前に、
    前記ゲームに参加するためのリクエストを、前記リモートデバイスに送信するステップと、
    前記リモートデバイスからデータ要求リクエストを受信するステップであって、前記データは、前記複数のゲーム機の前記第１のゲーム機に関連しているゲームのフィーチャーの詳細を示すステップと
    をさらに含むことを特徴とする請求項１３記載の方法。
15. 受信したコードを消去するためのトリガを受信するステップと、
    前記必要とされるフィーチャーの各々について所有者情報を判断するステップと、
    前記リモートデバイスに接続されたゲーム機、または、前記リモートデバイスに接続されたゲーム機に関連するゲームプレーヤによって所有されていない前記必要とされるフィーチャーに関する受信コードを削除するステップと
    をさらに含むことを特徴とする請求項１３または１４に記載の方法。
16. 前記必要とされるフィーチャーのセットに関するコードは、前記リモートデバイスから受信されることを特徴とする請求項１３乃至１５のいずれかに記載の方法。
17. 前記必要とされるフィーチャーのセットに関するコードは、前記複数のゲーム機の１つ以上から受信されることを特徴とする請求項１３乃至１６のいずれかに記載の方法。
18. 前記リモートデバイスは、前記複数のゲーム機の１つであることを特徴とする請求項１７に記載の方法。
19. 前記リモートデバイスは、サーバ（１０２）を含むことを特徴とする請求項１３乃至１８のいずれかに記載の方法。

Images