(57)【要約】本発明は、通信ネットワークにおける分散型のマルチユーザアプリケーション用のサーバユニットに関する。サーバユニットは１つのアプリケーションセッション中にアプリケーションアイテムに対してアプリケーションセッション内でのみ使用されるアプリケーション名を記憶するためと、通信ネットワークにおいてアプリケーションデータを送信するためにアプリケーションデータユニット用に適合化されたタグ値を記憶するための、少なくとも１つの記憶手段と、アプリケーション名の少なくとも１つをタグ値の少なくとも１つにマッピングするためのマッピング手段とを備える。本発明はまた、サーバユニットを有する通信ネットワークにおけるシステムと、サーバユニット用の方法と、サーバユニット用のコンピュータプログラムに関する。【選択図】図１
2004512622.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワーク（１）における分散型の少なくとも１つのマルチユーザアプリケーションを対象とする、アプリケーション名をタグ値にマッピングするためのサーバ（７）用の方法であって、タグ値が、通信ネットワーク（１）においてアプリケーションデータを送信するためにアプリケーションデータユニット（１３）をアドレッシングおよびルーティングするために使用される方法であって、
アプリケーションセッション用にタグ値を少なくとも１つの記憶手段に記憶するステップと、
アプリケーションセッション中にアプリケーションアイテムに対して使用するための少なくとも１つのアプリケーション名を受信するステップと、
少なくとも１つのアプリケーション名をタグ値の少なくとも１つにマッピングするステップと、
少なくとも１つのアプリケーション名を少なくとも１つの記憶手段に記憶するステップと、
タグ値の少なくとも１つを通信ネットワーク（１）内の少なくとも１つの受信ノードに送信するステップと
を備えることを特徴とする方法。
【請求項２】
タグ値のそれぞれを少なくとも１つの記憶手段に含まれる少なくとも１つのデータベース（２４）内の個別のレコードに記憶することを特徴とする請求項１に記載の方法。
【請求項３】
少なくとも１つのアプリケーション名を、少なくとも１つのアプリケーション名がマッピングされているタグ値の少なくとも１つと同じレコード内のアプリケーション名フィールド（２６）に記憶することを特徴とする請求項２に記載の方法。
【請求項４】
少なくとも１つのアプリケーション名は、アプリケーションセッションに参加することのできるアプリケーションクライアント（６）から受信されることを特徴とする請求項１〜３のいずれか１つに記載の方法。
【請求項５】
少なくとも１人のユーザが少なくとも１つのアプリケーション名を知っているときに、少なくとも１つのアプリケーション名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答する、または、少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、タグ値の少なくとも１つから少なくとも１つのアプリケーション名へのマッピングについての少なくとも１人のユーザからの問合せに応答するステップを備えることを特徴とする請求項１〜４のいずれか１つに記載の方法。
【請求項６】
少なくとも１つのアプリケーション名の所有者の所有者名を受信するステップと、
所有者名をタグ値の少なくとも１つにマッピングするステップと、
所有者名を少なくとも１つの記憶手段に記憶するステップと
を備えることを特徴とする請求項１〜５のいずれか１つに記載の方法。
【請求項７】
少なくとも１人のユーザが所有者名を知っているときに、所有者名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答する、または、少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、タグ値の少なくとも１つから所有者名へのマッピングについての少なくとも１人のユーザからの問合せに応答するステップを備えることを特徴とする請求項６に記載の方法。
【請求項８】
通信ネットワーク（１）における分散型の少なくとも１つのマルチユーザアプリケーション用システムであって、
ユーザ端末（５）と、
アプリケーションデータの記憶と受信を行うためと、アプリケーションデータユニット（１３）をユーザ端末（５）に配信するための、少なくとも１つの第１サーバユニット（２）と、
アプリケーションセッションのコンテンツを生成し、前記コンテンツの少なくとも一部をユーザ端末の少なくとも１つに送信するための少なくとも１つの第２サーバユニット（４）と
を備えるシステムであって、
少なくとも１つの第３サーバユニット（７）を備え、第３サーバユニットが少なくとも、
１つのアプリケーションセッション中にアプリケーションアイテムに対してアプリケーションセッション内で使用されるアプリケーション名を記憶するためと、通信ネットワーク（１）においてアプリケーションデータを送信するためにアプリケーションデータユニット（１３）用に適合化されたタグ値を記憶するための、１つの記憶手段と、
タグ値の少なくとも１つをアプリケーション名の少なくとも１つにマッピングするためのマッピング手段（３０）と
を有することを特徴とするシステム。
【請求項９】
アプリケーションデータユニット（１３）それぞれによって伝えられるアプリケーションタグに応じてアプリケーションデータユニット（１３）をルーティングするためのルータ（３）を有することを特徴とする請求項８に記載のシステム。
【請求項１０】
アプリケーションセッションを確立することを目的としかつユーザが登録する少なくとも１つの第４サーバユニット（８）を有することを特徴とする請求項８または９に記載のシステム。
【請求項１１】
アプリケーションセッションを制御および管理するためと、アプリケーションセッションデータおよび／またはアプリケーションデータユニット用の記憶手段を確保するための、少なくとも１つの第５サーバユニット（９）を有することを特徴とする請求項８〜１０のいずれか１つに記載のシステム。
【請求項１２】
ユーザ端末は、それぞれ少なくとも１つのアプリケーションクライアント（６）を処理するための手段を有し、そこでは、少なくとも１つのアプリケーションクライアント（６）が、タグの付いたアプリケーションデータユニット（１３）をサブスクライブ、受信、および処理し、かつタグの付いたアプリケーションデータユニット（１３）を送信するための手段を有することを特徴とする請求項８〜１１のいずれか１つに記載のシステム。
【請求項１３】
ユーザ端末（５）それぞれは、ユーザからの入力エントリを受信するための手段と、グラフィック、ビデオ、音声、または感覚的な出力としての出力アプリケーションデータを表示するための手段とを備えることを特徴とする請求項８〜１２のいずれか１つに記載のシステム。
【請求項１４】
通信ネットワーク（１）における分散型のマルチユーザアプリケーション用のサーバユニット（７）であって、
１つのアプリケーションセッション中にアプリケーションアイテムに対してアプリケーションセッション内でのみ使用されるアプリケーション名を記憶するためと、通信ネットワーク（１）においてアプリケーションデータを送信するためにアプリケーションデータユニット（１３）用に適合化されたタグ値を記憶するための、少なくとも１つの記憶手段と、
アプリケーション名の少なくとも１つをタグ値の少なくとも１つにマッピングするためのマッピング手段（３０）と
を有することを特徴とするサーバユニット（７）。
【請求項１５】
マッピング手段（３０）はアプリケーション名の１つをタグ値の１つにマッピングすることを特徴とする請求項１４に記載のサーバユニット（７）。
【請求項１６】
マッピング手段（３０）は複数のアプリケーション名をタグ値の１つにマッピングすることを特徴とする請求項１４に記載のサーバユニット（７）。
【請求項１７】
マッピング手段（３０）はアプリケーション名の１つを複数のタグ値にマッピングすることを特徴とする請求項１４に記載のサーバユニット（７）。
【請求項１８】
アプリケーションアイテムは、人間のユーザまたは人工知能用のキャラクターであり；一部は人工知能によって一部は人によってコントロールされるキャラクター；ユーザの間で交替できるゲーム内の固定的な役割；仮想環境内のオブジェクト；オブジェクトとキャラクターの特性；キャラクターのグループとチーム；オブジェクトのグループ；グループのグループ；仮想環境における位置；またはメディアストリームまたはメディアストリームの集合であることを特徴とする請求項１４〜１７のいずれか１つに記載のサーバユニット（７）。
【請求項１９】
アプリケーションセッションは、マルチユーザコンピュータゲームのゲームセッションであることを特徴とする請求項１８に記載のサーバユニット（７）。
【請求項２０】
アプリケーションセッションは、マルチパートビデオ会議であることを特徴とする請求項１８に記載のサーバユニット（７）。
【請求項２１】
記憶手段に記憶されかつタグ値とアプリケーション名とを有する少なくとも１つのデータベース（２４）を有することを特徴とする請求項１４〜２０のいずれか１つに記載のサーバユニット（７）。
【請求項２２】
マッピング手段（３０）はアプリケーションセッション用のデータベース管理システムであることを特徴とする請求項１４〜２１のいずれか１つに記載のサーバユニット（７）。
【請求項２３】
少なくとも１つの記憶手段はアプリケーション名の少なくとも１つの所有者の少なくとも１つの所有者名を記憶するように適合化されていて、かつ、マッピング手段（３０）は少なくとも１つの所有者名をタグ値の少なくとも１つにマッピングするように適合化されていることを特徴とする請求項１４〜２２のいずれか１つに記載のサーバユニット（７）。
【請求項２４】
通信ネットワーク（１）における分散型のマルチユーザアプリケーション用のコンピュータプログラムであって、
サーバユニット（７）にアプリケーションセッション中にアプリケーションアイテムに対して使用するための少なくとも１つのアプリケーション名を受信させるためのコンピュータ読取可能コード手段と、
サーバユニット（７）に少なくとも１つのアプリケーション名を、サーバユニット（７）内の少なくとも１つの記憶手段に記憶されていてかつ通信ネットワーク（１）においてアプリケーションデータを送信するためにアプリケーションデータユニット（１３）用に適合化された複数のタグ値の少なくとも１つにマッピングさせるためのコンピュータ読取可能コード手段と、
サーバユニット（７）に少なくとも１つのアプリケーション名を少なくとも１つの記憶手段に記憶させるためのコンピュータ読取可能コード手段と
を有することを特徴とするコンピュータプログラム。
【請求項２５】
サーバユニット（７）にタグ値の少なくとも１つを通信ネットワーク内の少なくとも１つの受信ノード（５）に送信させるためのコンピュータ読取可能コード手段を有することを特徴とする請求項２４に記載のコンピュータプログラム。
【請求項２６】
サーバユニット（７）に少なくとも１つのアプリケーション名を、少なくとも１つの記憶手段に含まれる少なくとも１つのデータベース（２４）に記憶させるためのコンピュータ読取可能コード手段を有することを特徴とする請求項２４または２５に記載のコンピュータプログラム。
【請求項２７】
サーバユニット（７）に少なくとも１つのアプリケーション名を、少なくとも１つのデータベース（２４）内の少なくとも１つのレコード内の少なくとも１つのアプリケーション名フィールド（２６）に記憶させるためのコンピュータ読取可能コード手段であって、少なくとも１つのレコードが、少なくとも１つのアプリケーション名がマッピングされているタグ値の少なくとも１つのためのタグ値フィールド（２５）を有する、コンピュータ読取可能コード手段を有することを特徴とする請求項２６に記載のコンピュータプログラム。
【請求項２８】
少なくとも１人のユーザが少なくとも１つのアプリケーション名を知っているときに、サーバユニット（７）に少なくとも１つのアプリケーション名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段と、
少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、サーバユニット（７）にタグ値の少なくとも１つから少なくとも１つのアプリケーション名へのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段と
を有することを特徴とする請求項２４〜２７のいずれか１つに記載のコンピュータプログラム。
【請求項２９】
サーバユニット（７）に少なくとも１つのアプリケーション名の所有者の所有者名を受信させるためのコンピュータ読取可能コード手段と、
サーバユニット（７）に所有者名をタグ値の少なくとも１つにマッピングさせるためのコンピュータ読取可能コード手段と、
サーバユニット（７）に所有者名を少なくとも１つの記憶手段に記憶させるためのコンピュータ読取可能コード手段と
を有することを特徴とする請求項２４〜２８のいずれか１つに記載のコンピュータプログラム。
【請求項３０】
少なくとも１人のユーザが所有者名を知っているときに、サーバユニット（７）に所有者名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段と、
少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、サーバユニット（７）にタグ値の少なくとも１つから所有者名へのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段と
を有することを特徴とする請求項２９に記載のコンピュータプログラム。
【請求項３１】
コンピュータ使用可能媒体と、請求項２４に記載の、コンピュータ使用可能媒体に記録されているコンピュータプログラムとを備えるコンピュータプログラム製品（１９）。
【発明の詳細な説明】
【０００１】
技術分野
本発明は、通信ネットワークにおける分散型の少なくとも１つのマルチユーザアプリケーション用システムに関する。また、本発明は、ネットワークに含まれるサーバユニットにも関する。さらに、本発明は、サーバユニット用の方法およびコンピュータプログラムに関する。
【０００２】
関連技術の説明
ネットワーク型仮想環境においては、広範囲に分散された複数のユーザがリアルタイムまたはほぼリアルタイムで対話する。このようなアプリケーションは、仮想世界における現実的な感覚と、より深い体験とを目的とする。これらのアプリケーションは、軍隊または企業チームの訓練、共同での設計／エンジニアリング、複数のプレイヤーのゲーム、バーチャルショッピング、バーチャル会議、顧客の遠隔サポート、遠隔教育に使用される。以下の説明および請求項においては、ネットワーク型仮想環境を処理する分散型コンピュータプログラムのことをアプリケーションと呼ぶ。
【０００３】
ＰＣＴ特許出願ＰＣＴ／ＳＥ００／００９３２には、マルチユーザアプリケーションに関する先行技術の解決策における問題が扱われている。この文書は本文書に参考文献として組み込まれる。例えば、マルチユーザゲーム、すなわちインターネット上で２人以上のユーザが同時にプレイできるゲームは、通常ではスピードはそれほど重要でないゲームである。これに対して、例えばカーレーシング・ゲームや格闘ゲームなどの高速アクションゲームにおいては、ユーザは画面の状況に瞬時に反応する必要があり、これらのゲームは、クライアントサーバ同期モードまたはピアツーピア同期モード、すなわちアプリケーションのすべてのクライアントが必要時にアプリケーションデータを他のすべてのクライアントに直接送るモードを使用したときに、満足できるクォリティでプレイすることは通常ではできない。
【０００４】
以下の説明および請求項においては、アプリケーションセッションは、ネットワーク型仮想環境を処理する分散型コンピュータプロセスとして定義される。この仮想環境には、人間のユーザにとって意味のあるアプリケーションアイテムが含まれる。例えば、人によってコントロールされるキャラクター、人工知能（ＡＩ）によってコントロールされるキャラクター、一部は人によって一部はＡＩによってコントロールされるキャラクター、ユーザの間で交替できるゲーム内の固定的な役割（例えば王様、戦士、スポーツ選手、審判）、仮想環境内のオブジェクト、オブジェクトとキャラクターの特性、キャラクターのグループとチーム、オブジェクトのグループ、グループのグループ、仮想環境における位置、メディアストリーム（例えば音声とビデオ）、メディアストリームの集合などである。この場合のキャラクターとは、一般にはアプリケーションの中でのユーザを表す人物や形態であり、通常はグラフィックアイコンとして表示される。通常、ユーザは、クライアントを介してアプリケーションに入ると、いくつもの空想上のキャラクターから選ぶことができる。高度な３Ｄのキャラクター、例えばゲームのキャラクターやインターネット上の３Ｄチャットサイト内のキャラクターは、その動作と目的に応じて形を変えることさえできる。アプリケーションにおけるアプリケーションアイテムには名前が付くことがあり（以下、アプリケーション名と呼ぶ）、アプリケーション名は、アプリケーションアイテムを呼ぶ目的でユーザおよび／またはアプリケーションによって使用される。アプリケーション名は、非常に長いことも多い。分散型アプリケーションにおいては、セッション内でアプリケーション名が一意である必要がある。セッション全体を通じて一意のアプリケーション名を生成するためのアルゴリズムの結果として、アプリケーション名が長くなる。また、場合によっては、アプリケーション名が人にとって意味のあることも重要である。短いコードは、通常は長いアプリケーション名よりも意味的な度合いが小さい。
【０００５】
本発明の目的
本発明の目的は、通信ネットワークにおける帯域幅を節約することである。
【０００６】
本発明の他の目的は、中央サーバを用意する必要のないピアツーピア同期モードにおける世界規模のマルチユーザセッションを可能にすることである。
【０００７】
本発明の概要
本発明は、通信ネットワークにおける分散型の少なくとも１つのマルチユーザアプリケーション用システムであって、
ユーザ端末と、
アプリケーションデータの記憶と受信を行うためと、アプリケーションデータユニットをユーザ端末に配信するための、少なくとも１つの第１サーバユニットと、
アプリケーションセッションのコンテンツを生成し、前記コンテンツの少なくとも一部をユーザ端末の少なくとも１つに送信するための少なくとも１つの第２サーバユニットと、
少なくとも１つの第３サーバユニットであって、少なくとも、
１つのアプリケーションセッション中にアプリケーションアイテムに対してアプリケーションセッション内でのみ使用されるアプリケーション名を記憶するためと、通信ネットワークにおいてアプリケーションデータを送信するためにアプリケーションデータユニット用に適合化されたタグ値を記憶するための、１つの記憶手段と、
タグ値の少なくとも１つをアプリケーション名の少なくとも１つにマッピングするためのマッピング手段とを有する第３サーバユニットとを備えるシステムに関する。
これにより、アプリケーションデータユニット、すなわちアプリケーションセッション中に使用されるアプリケーション情報を含むパケットを参加者と各種サーバとに送信するときに、短いコード、すなわち人にとって意味がないかまたは読みにくいタグ値が使用されるのと同時に、アプリケーションセッション中に人間のユーザにとって意味のある長いアプリケーション名を使用できることが達成される。また、アプリケーションアイテムを参照するための名前として、通信ネットワークにおいて使用される通信プロトコルのタイプに依存せずに内部的なアプリケーション名のみを使用して、アプリケーションを書くことができることが達成される。この場合のタグ値は、アプリケーションタグを表す英数字である。アプリケーションタグは、転送されるアプリケーションアイテムをルーティングするため、または記憶されているアプリケーションアイテムを見つけるためのコードである。アプリケーションタグは、アプリケーションデータユニットのヘッダ内のフィールドでよいが、他の任意のデータグラムまたは通信プロトコルパケットのヘッダ内のフィールドでもよい。従って、アプリケーションタグは、一連のビットで構成される。アプリケーションタグにはタイプがあり、このタイプは、プロトコルにおける対応するフィールドの位置によって識別されるか、またはアプリケーションタグのタイプを示すプロトコルにおけるフラグによって識別される。アプリケーションタグが一般的な通信プロトコルにおけるフィールドである代替の方法においては、アプリケーションタグは、ネットワークアドレス、マルチキャストアドレス、またはポート番号でよい。上記に引用されている参考文献においては、アプリケーションタグは、オブジェクト識別子、クライアント識別子、グループ識別子、またはストリームオブジェクトキーである。アプリケーションタグは、通信ネットワークにおいてアプリケーションに必要な帯域幅をできる限り小さく維持するために、できる限り短くするが、このアプリケーションタグの長さは、例えばアプリケーションのタイプや、アプリケーションによって同時にサポートされるユーザの数に依存する。
【０００８】
望ましくは、システムは、アプリケーションデータユニットそれぞれによって伝えられるアプリケーションタグに応じてアプリケーションデータユニットをルーティングするための個別のルータを有する。
【０００９】
好適な特徴として、システムは、アプリケーションセッションを確立することを目的としかつユーザが登録する先の少なくとも１つの第４サーバユニットと、アプリケーションセッションを制御および管理するためと、アプリケーションセッションデータおよび／またはアプリケーションデータユニット用の記憶手段を確保するための、少なくとも１つの第５サーバユニットとを有する。
【００１０】
有利な特徴として、ユーザ端末は、それぞれ少なくとも１つのアプリケーションクライアントを処理するための手段を有し、そこでは、少なくとも１つのアプリケーションクライアントが、タグの付いたアプリケーションデータユニットをサブスクライブ、受信、および処理し、かつタグの付いたアプリケーションデータユニットを送信するための手段を有する。これによって、各ポイントにおける各ユーザが、例えば仮想環境の現在のビューを表示するために必要なアプリケーションデータのみを、最小の通信帯域幅を使用して正しいタイミングで受信することが達成される。
【００１１】
好適な特徴として、ユーザ端末それぞれは、ユーザからの入力エントリを受信するための手段と、グラフィック、ビデオ、音声、または感覚的な出力としての出力アプリケーションデータを表示するための手段とを有する。これによって、アプリケーションセッションにおける参加者への出力が異なる、タイプの異なる多数のマルチユーザアプリケーション用にシステムを使用できる。
【００１２】
本発明は、通信ネットワークにおける分散型のマルチユーザアプリケーション用のサーバユニットであって、
１つのアプリケーションセッション中にアプリケーションアイテムに対してアプリケーションセッション内でのみ使用されるアプリケーション名を記憶するためと、通信ネットワークにおいてアプリケーションデータを送信するためにアプリケーションデータユニット用に適合化されたタグ値を記憶するための、少なくとも１つの記憶手段と、
アプリケーション名の少なくとも１つをタグ値の少なくとも１つにマッピングするためのマッピング手段とを備えるサーバユニットにも関する。
【００１３】
サーバユニットの第１実施例においては、マッピング手段はアプリケーション名の１つをタグ値の１つにマッピングする。
【００１４】
サーバユニットの第２実施例においては、マッピング手段は複数のアプリケーション名をタグ値の１つにマッピングする。
【００１５】
サーバユニットの第３実施例においては、マッピング手段はアプリケーション名の１つを複数のタグ値にマッピングする。
【００１６】
好適な特徴として、アプリケーションアイテムは、人間のユーザまたは人工知能用のキャラクターであり、アプリケーションセッションは、マルチユーザコンピュータゲームのゲームセッションである。これに代えて、アプリケーションセッションは、マルチパートビデオ会議であり、キャラクターはユーザと場合によってはＡＩを表す。
【００１７】
望ましくは、サーバユニットは、記憶手段に記憶されかつタグ値とアプリケーション名とを有する少なくとも１つのデータベースを有する。本明細書および請求項においては、データベースは、マッピング手段が必要なデータを選択できるように編成された情報の集合として定義される。
【００１８】
有利な特徴として、マッピング手段はアプリケーションセッション用のデータベース管理システムである。
【００１９】
好適な特徴として、少なくとも１つの記憶手段はアプリケーション名の少なくとも１つの所有者の少なくとも１つの所有者名を記憶するように適合化されていて、かつ、マッピング手段は少なくとも１つの所有者名をタグ値の少なくとも１つにマッピングするように適合化されている。
【００２０】
さらに、本発明は、通信ネットワークにおける分散型の少なくとも１つのマルチユーザアプリケーションを対象とする、アプリケーション名をタグ値にマッピングするためのサーバ用の方法であって、タグ値が、通信ネットワークにおいてアプリケーションデータを送信するためにアプリケーションデータユニットをアドレッシングおよびルーティングするために使用される方法にも関する。該方法は、
アプリケーションセッション用にタグ値を少なくとも１つの記憶手段に記憶するステップと、
アプリケーションセッション中にアプリケーションアイテムに対して使用するための少なくとも１つのアプリケーション名を受信するステップと、
少なくとも１つのアプリケーション名をタグ値の少なくとも１つにマッピングするステップと、
少なくとも１つのアプリケーション名を少なくとも１つの記憶手段に記憶するステップと、
タグ値の少なくとも１つを通信ネットワーク内の少なくとも１つの受信ノードに送信するステップとを備える。
【００２１】
有利な特徴として、方法は、少なくとも１人のユーザが少なくとも１つのアプリケーション名を知っているときに、少なくとも１つのアプリケーション名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答する、または、少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、タグ値の少なくとも１つから少なくとも１つのアプリケーション名へのマッピングについての少なくとも１人のユーザからの問合せに応答するステップをさらに備える。
【００２２】
望ましくは、タグ値のそれぞれは、少なくとも１つの記憶手段に含まれる少なくとも１つのデータベース内の個別のレコードに記憶される。
【００２３】
好適な特徴として、少なくとも１つのアプリケーション名は、少なくとも１つのアプリケーション名がマッピングされているタグ値の少なくとも１つと同じレコード内のフィールドに記憶される。
【００２４】
有利な特徴として、少なくとも１つのアプリケーション名は、アプリケーションセッションに参加することのできるアプリケーションクライアントから受信される。アプリケーションクライアントについては、本文の中に定義されている。
【００２５】
また、方法は、少なくとも１つのアプリケーション名の所有者の所有者名を受信するステップと、
所有者名をタグ値の少なくとも１つにマッピングするステップと、
所有者名を少なくとも１つの記憶手段に記憶するステップとを備えることができる。
【００２６】
好適な特徴として、方法は、少なくとも１人のユーザが所有者名を知っているときに、所有者名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答する、または、少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、タグ値の少なくとも１つから所有者名へのマッピングについての少なくとも１人のユーザからの問合せに応答するステップを備える。
【００２７】
さらに、本発明は、通信ネットワークにおける分散型のマルチユーザアプリケーション用のコンピュータプログラムであって、
サーバユニットにアプリケーションセッション中にアプリケーションアイテムに対して使用するための少なくとも１つのアプリケーション名を受信させるためのコンピュータ読取可能コード手段と、
サーバユニットに少なくとも１つのアプリケーション名を、サーバユニット内の少なくとも１つの記憶手段に記憶されていてかつ通信ネットワークにおいてアプリケーションデータを送信するためにアプリケーションデータユニット用に適合化された複数のタグ値の少なくとも１つにマッピングさせるためのコンピュータ読取可能コード手段と、
サーバユニットに少なくとも１つのアプリケーション名を少なくとも１つの記憶手段に記憶させるためのコンピュータ読取可能コード手段とを備えるコンピュータプログラムに関する。
【００２８】
望ましくは、コンピュータプログラムは、
サーバユニットにタグ値の少なくとも１つを通信ネットワーク内の少なくとも１つの受信ノードに送信させるためのコンピュータ読取可能コード手段と、
サーバユニットに少なくとも１つのアプリケーション名を、少なくとも１つの記憶手段に含まれる少なくとも１つのデータベースに記憶させるためのコンピュータ読取可能コード手段と備える。
【００２９】
好適な特徴として、コンピュータプログラムは、
サーバユニットに少なくとも１つのアプリケーション名を、少なくとも１つのデータベース内の少なくとも１つのレコード内の少なくとも１つのフィールドに記憶させるためのコンピュータ読取可能コード手段であって、少なくとも１つのレコードが、少なくとも１つのアプリケーション名がマッピングされているタグ値の少なくとも１つのためのフィールドを有する、コンピュータ読取可能コード手段を備える。
【００３０】
望ましくは、コンピュータプログラムは、
少なくとも１人のユーザが少なくとも１つのアプリケーション名を知っているときに、サーバユニットに少なくとも１つのアプリケーション名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段と、
少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、サーバユニットにタグ値の少なくとも１つから少なくとも１つのアプリケーション名へのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段とを備える。
【００３１】
有利な特徴として、コンピュータプログラムは、
サーバユニットに少なくとも１つのアプリケーション名の所有者の所有者名を受信させるためのコンピュータ読取可能コード手段と、
サーバユニットに所有者名をタグ値の少なくとも１つにマッピングさせるためのコンピュータ読取可能コード手段と、
サーバユニットに所有者名を少なくとも１つの記憶手段に記憶させるためのコンピュータ読取可能コード手段とを備える。
【００３２】
好適な特徴として、コンピュータプログラムは、
少なくとも１人のユーザが所有者名を知っているときに、サーバユニットに所有者名からタグ値の少なくとも１つへのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段と、
少なくとも１人のユーザがタグ値の少なくとも１つを知っているときに、サーバユニットにタグ値の少なくとも１つから所有者名へのマッピングについての少なくとも１人のユーザからの問合せに応答させるためのコンピュータ読取可能コード手段とを備える。
【００３３】
本発明は、コンピュータ使用可能媒体と、コンピュータ使用可能媒体に記録されているコンピュータプログラムとを有するコンピュータプログラム製品にも関する。このコンピュータプログラム製品は、ハードディスク、ＣＤ（コンパクトディスク）、ＤＶＤ、ディスク、テープ、フラッシュメモリなどであることができる。
【００３４】
図面の簡単な説明
本発明の目的、利点、効果、特徴は、望ましい方法と実施例についての以下の詳細な説明を、添付されている図面を参照しながら読むことにより、より容易に理解されるであろう。
図１は、本発明による通信ネットワークの実施例を示す。
図２は、アプリケーションデータユニットが含まれるパケットを示す。
図３は、本発明によるサーバの線図を示す。
図４は、サーバ内のデータベースの中のレコードを示す。
図５は、特定のアプリケーションタグの名前を取得する操作のフローチャートを示す。
図６は、本発明による別の可能な操作のフローチャートを示す。
【００３５】
実施形態の詳細説明
本発明は、さまざまな変更と代替の構造もその範囲とするが、本発明の望ましい実施例が図面に示されていて、以下にこれらの実施例について詳細に説明する。しかしながら、以下の説明と添付の図面は、開示されている固有の形式に本発明を制限することを意図するものではない。逆に、請求されている本発明の範囲には、添付されている請求項に記載されている本発明の精神および範囲に含まれる変更および代替方法すべてと、それらと同等の方法すべてとが含まれるものとする。
【００３６】
本出願において図示および説明されているユニットと要素の一部は、同時出願中の出願ＳＥ−．．．とＳＥ−．．．に、より詳細に説明されている。これらの出願文書は、目的を問わず、その全体が参考文献として本文書に組み込まれる。
【００３７】
図１は、本発明の第１実施例によるアプリケーションネットワークを提供するための、パケット指向型の通信ネットワーク（例えばインターネット）１を線図的に示す。この通信ネットワーク１には、通信リンクと、汎用の通信プロトコル（インターネットプロトコルなど）用のルータとが含まれる。これらのリンクおよびルータと、本発明に関与しないサーバは、本発明を理解しやすくするため図には示されていない。この通信ネットワークには、ネットワーク型マルチユーザ環境におけるアプリケーションセッションをサポートするため、いくつかのノードが含まれる。
【００３８】
第１ノードは、アプリケーションデータを記憶および受信するアプリケーションサーバ（ＡＳ）の形式における第１サーバユニット２を有する。このＡＳは、問合せ、要求、またはサブスクリプションに従ってアプリケーションデータをアプリケーションクライアントに配信する。このような問合せ、要求、またはサブスクリプションは、アプリケーションタグを伝えるアプリケーションデータユニットのサブスクリプションの形式で表すことができ、これについては後述する。
【００３９】
第２ノードは、アプリケーションルータ（ＡＲ）３を有する。ＡＲ３は、アプリケーションデータユニットをルーティングする、すなわちアプリケーションデータユニットをそれぞれの送信先に転送する。このルーティングは、各アプリケーションデータユニットによって伝えられるアプリケーションタグに応じて行われる。ＡＲ３は、アプリケーションデータユニットを含むパケットを通信ネットワーク１から受信する。また、ＡＲ３は、アプリケーションデータユニットのアプリケーションタグを読み取り、そのアプリケーションデータユニットを、アプリケーションタグおよびオプションとしてクライアントのサブスクリプションとによって決まるネットワークアドレスを使用して、通信ネットワーク１を介して再送信する。
【００４０】
第３ノードは、アプリケーションコンテンツ生成サーバ（ＡＣＧＳ）の形式における第２サーバユニット４を有する。このＡＣＧＳは、アプリケーションセッションのコンテンツを生成する。一例としてのみ使用される第１実施例においては、ＡＣＧＳは、マルチプレイヤー・ゲームにおけるゲームサーバであり、殺人、衝突、ダメージに関する決定を行う。また、キャラクターを動かす処理を担当する。アプリケーションのシステムに入ると、多数のキャラクターを選ぶことができる。また、ＡＣＧＳは、人によってコントロールされるように見えるが実際にはＡＩによって管理されるキャラクターを動かす処理も担当させることができる。ＡＣＧＳは、アプリケーションデータユニットを受信および処理し、アプリケーションタグを伝えるアプリケーションデータユニットを送信する。
【００４１】
第４ノードは、ゲームコンソールまたはパーソナルコンピュータ（ＰＣ）などのユーザ端末の形式におけるユーザ端末５であり、アプリケーションクライアント（ＡＣ）６を介して通信ネットワークに接続されている。ＡＣ６は、ネットワーク型仮想環境をシミュレートするコンピュータプロセス（例えばＷｉｎｄｏｗｓ（登録商標）／ＵＮＩＸ（登録商標）のプロセスまたはスレッド）のローカルインスタンスである。１つのコンピュータプロセスは、１または複数のＡＣ６を実行できる。従って、ＡＣ６は、ゲームまたはシミュレーションの論理インスタンスであり、特定のコンピュータプロセス、スレッド、プログラム、またはマシンと必ずしも同一ではない。例えば、ＡＣ６を実行するコンピュータまたはゲームコンソールには、ユーザからの入力を受信するためと、アプリケーションの出力を感覚的な表現として、すなわち触覚、グラフィック、ビデオ、または音声の出力として表示するための手段が含まれる。ＡＣ６は、タグの付いたアプリケーションデータユニットをサブスクライブ、受信、および処理し、タグの付いたアプリケーションデータユニットを送信することができる。クライアントマシン、すなわちユーザ端末５に含まれるネットワークインタフェースソフトウェアには、アプリケーション名とアプリケーションタグの間の変換を行い、かつ、対応するタグ値を別のＡＣ６、ＡＳ、ＡＲ、ＡＣＧＳ、および後述するその他のサーバに送信するための、コンピュータ読み取り可能コード手段が含まれる。さらに、ネットワークインタフェースソフトウェアには、ユーザ端末５が必要時に第３サーバユニット７（後述する）と通信できるようにし、かつ、アプリケーションタグを伝えるアプリケーションデータユニットを含むパケットを通信ネットワーク１を介して送信するための、コンピュータ読取可能コード手段が含まれる。
【００４２】
第５ノードは、通信ネットワークに接続されるアプリケーションセッション名サーバ（ＡＳＮＳ）の形式における第３サーバユニット７を有する。このＡＳＮＳは、アプリケーション名をアプリケーションタグにマッピングし、すなわちアプリケーション名からアプリケーションタグへの、およびこの逆の関係付けを行い、名前の設定、名前の削除、名前の照会などの操作に応答する。これについては、後から詳細に説明する。アプリケーションデータベース用のメモリと処理リソースは、アプリケーションセッション用にはセッションプロファイルに従って、ＡＣ６用にはクライアントプロファイルに従って、それぞれ確保される。クライアントプロファイルは、一連のアプリケーションネットワークパラメータで構成され、クライアントグループがアプリケーションセッションに参加する前に、プログラム可能なアプリケーションネットワークとユーザ端末を初期化および準備するのに使用される。しかしながら、クライアントプロファイルは本発明の一部ではなく、同時出願中の特許出願ＳＥ−．．．に詳細に説明されている。セッションプロファイルは、アプリケーションセッションに有効な一連のアプリケーションネットワークパラメータで構成され、アプリケーションセッションが開始される前に、プログラム可能なアプリケーションネットワークを初期化および準備するのに使用される。セッションプロファイルも本発明の一部ではなく、同時出願中の特許出願ＳＥ−．．．に詳細に説明されている。ＡＳＮＳは、いくつかの異なるアプリケーションをサポートできるように汎用的なインタフェースを使用する。従って、ＡＳＮＳを使用することは、望ましいことに汎用的なコンポーネントを有するシステムが構築されることを意味し、当然ながら、異なるアプリケーション用に個別にシステムを構築する場合よりも経済的である。アプリケーションは、通信プロトコルに関係なく任意の名前形式を使用できる。これにより、新しいアプリケーションを開発すること、特に既存のアプリケーションを新しい通信サービスに移植することが容易になる。アプリケーションの通信プロトコルは古いタグ形式を使用することができ、しかも新しい世代のアプリケーションに対しても有用である。
【００４３】
第６ノードは、アプリケーションセッションを確立するためのアプリケーションロビーサーバ（ＡＬＳ）の形式における第４サーバユニット８を有する。参加者は、このＡＬＳに登録を行い、アプリケーションセッションの開始をネゴシエートする。サービスプロバイダは、このＡＬＳを使用して、参加者の認証と課金処理を行うことができる。このＡＬＳは、アプリケーションセッションのタイプに応じてオプションである。
【００４４】
第７ノードには、オプションのアプリケーションネットワーク管理システム（ＡＮＭＳ）の形式における第５サーバユニット９が含まれる。このＡＮＭＳは、ＡＬＳにおいてネゴシエートされたアプリケーションセッションを制御および管理するのに使用される。また、ＡＮＭＳは、オプションとして通信ネットワークの中と、ＡＳ、ＡＲ、ＡＣＧＳ、およびＡＳＮＳの各ノード内のリソースを確保するためにも使用される。さらに、ＡＮＭＳは、エラー条件の処理にも使用できる。このＡＮＭＳは、セッションプロファイルとクライアントプロファイルを使用して、通信ネットワーク１の少なくとも一部であるプログラム可能なアプリケーションネットワークの構成を行う。
【００４５】
図１には、本発明を理解しやすいように、上述したサーバ２、４、７、８、９の１つをそれぞれ有するノードが一例としてのみ示されているが、１つのノードにこれらの複数のサーバが存在してもよい。また、応答時間を向上させるためと、ハードウェアまたはソフトウェアの障害に起因してノードの１つが動作を停止した場合にバックアップする目的で、上述されているサーバ２、４、７、８、９それぞれが通信ネットワーク１の中に複数存在してもよい。
【００４６】
通信ネットワーク１は、一般には、いくつかのパケットベースの通信プロトコル（例えばＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなどのＩＰプロトコル）を使用する。通信ネットワーク１は、送信元から受信先にパケット１０を伝える。このパケットの１つが図２に示されている。パケット１０は、一般には、ヘッダ１１とペイロード１２とを有する。ヘッダ１１には、パケット１０を受信先に送信するために通信ネットワーク１内のルータによって使用される１つまたは複数のネットワークアドレスを含めることができる。プロトコルは複数の層で構成されるため、１つのプロトコル層のペイロードに次のプロトコル層の１つ以上のパケットを含めることができる。アプリケーションデータユニット１３は、パケット１０などのネットワークプロトコルのパケット内のペイロードとして伝えられる。
【００４７】
オプションとして、アプリケーションに自身の通信プロトコルを含めることができる。アプリケーションデータユニットは、ヘッダ１５とペイロード１４とで構成される。ヘッダには、１つ以上のアプリケーションタグが含まれる。ペイロード１４は、位置、キャラクターの特性、符号化された音声データなど、アプリケーションに固有なデータで構成される。
【００４８】
次に、ＡＳＮＳを有するノードの一例について、図３を参照しながら説明する。ＣＰＵ（中央処理装置）１６は、通信ポート１７と第１バス１８とを介して通信ネットワーク１に接続されている。また、ＣＰＵ１６は、第１ＲＯＭ（読取専用メモリ）１９として具体化されている記憶手段にも、第２バス２０を介して接続されている。この例においては、ＡＳＮＳは２つのアプリケーションセッションをサポートしているが、１つのアプリケーションセッションのみ、または３つ以上のアプリケーションセッションをサポートすることもできる。各アプリケーションセッションごとにデータベースが存在し、この実施例においてはこれをアプリケーションセッションデータベース（ＡＳＤＢ）２１と呼ぶ。このデータベースは、ハードディスクとして具体化される第２記憶手段に記憶される。このため、ＣＰＵ１６は、２つのＡＳＤＢ２１にも、それぞれ第３バス２２と第４バス２３を介して接続され、このことは、各ＡＳＤＢ２１が異なるハードディスクに記憶されることを意味する。各ＡＳＤＢ２１は、ソフトウェアと２つのサブデータベース（この実施例においてはこれをアプリケーションタグデータベース（ＡＴＤＢ）２４と呼ぶ）の形式におけるセッション識別手段を有する。各ＡＳＤＢ２１に対して２つのみのＡＴＤＢ２４が示されているが、各ＡＳＤＢ２１が、１つのみ、または３つ以上のＡＴＤＢ２４を有してもよいことが理解されるであろう。各ＡＴＤＢ２４は、１つの特定のタイプのアプリケーションタグを処理する。図４は、１つのＡＴＤＢ２４中のテーブル内のレコードを示し、このレコードは以下のフィールドを有する。
・タグ値フィールド２５。このフィールドは、対応するアプリケーションタグフィールドの有効な値を表すかまたは符号化した一連のビットである。
・アプリケーション名フィールド２６。このフィールドには、アプリケーションが有効なアプリケーション名として解釈できる例えばバイトの文字列として、任意のアプリケーション名が記憶される。このアプリケーション名フィールド２６の長さは、特定の最大長に設定でき、これにより、入力されたアプリケーション名がこの最大長より長い場合、そのアプリケーション名は無効とみなされ、従ってそのアプリケーション名を設定しようとすると拒否されるようにできる。これに代わる第１の方法は、アプリケーション名フィールド２６の長さの値を、アプリケーション名と一緒に記憶することである。これにより、クライアントユーザは任意の長さのアプリケーション名を選択できる。第２の代替方法は、アプリケーション名の最後を所定の記号によって示すことであり、この所定の記号は、アプリケーション名の中で使用することが許可されない文字である。第３の代替方法は、長さが各セッションの初期化パラメータであり、アプリケーション名の最大許容長は、例えば承認されたクライアントまたはアプリケーションサービスプロバイダによって設定される初期化パラメータである。
・レコード所有者フィールド２７。所有者とは、このレコード内の特定の選択されたフィールド内のコンテンツを作成した特定のユーザ、クライアントアプリケーション、アプリケーション名、またはアプリケーションアカウントを指す。このレコード所有者フィールドはオプションである。
・時刻参照フィールド２８。このフィールドは、例えばレコードが作成または変更された時刻を示す。時刻参照フィールド２８の中の値は、地球上の時刻またはセッション上の時刻に対応させることができる。このフィールドはオプションである。
・タイムアウトフィールド２９。このフィールドは、レコードがＡＴＤＢ２４に記憶されている時間長を示す。アプリケーションによっては、このタイムアウトフィールドは、アプリケーションセッションに参加していられる時間を示すこともできる。このフィールドもオプションである。
【００４９】
各種のアプリケーションに適合する他のオプションのフィールドも、ＡＴＤＢ２１に含めることができる。
【００５０】
この実施例においては、ＲＯＭ１９は、マッピング手段３０に含まれるコードを保持し、このコードは、この実施例においてはデータベース管理システム（ＤＢＭＳ）、すなわちＡＴＤＢ２４とＡＳＤＢ２１中のデータの編成、記憶、検索、およびオプションとしてセキュリティと整合性とを制御するコンピュータプログラムである。ＡＴＤＢ２４は、データベース管理システム（ＤＢＭＳ）３０とネットワークオペレーティングシステム（ＮＯＳ）３１（これもＲＯＭにインストールされている）を通じて、アプリケーションからの要求を受理し、ネットワークオペレーティングシステム（ＮＯＳ）３１に適切なアプリケーションデータを転送するように命令する。ＤＢＭＳ３０は、ＲＯＭ１９の中に示されているが、当然ながら、ＡＳＤＢ２１を含むハードディスクの１つに記憶することもできる。
【００５１】
上述されているフィールドとマッピング手段によって、少なくとも次の操作のサポートが可能になる。すなわち、特定のタグ値に対してアプリケーション名を設定する、特定のアプリケーション名に対してタグ値を設定する、特定のタグ値に関連付けられているアプリケーション名の問合せの結果を特定の受信者に送信する、特定のアプリケーション名に関連付けられているタグ値の問合せの結果を特定の受信者に送信する、フィールドまたはレコードを無効にする、操作である。
【００５２】
ＡＴＤＢ２４は、次のオプションの操作もサポートする。すなわち、特定のタグ値の所有者を設定する、特定のアプリケーション名の所有者を設定する、特定のアプリケーション名の所有者を取得する、特定のタグ値の所有者を取得する、特定の所有者に属すレコードを発見する、特定の所有者に属す全レコードを削除する、所有者のないタグ値を発見する、アプリケーション名と所有者を設定してタグ値を送信者に戻す、特定のレコードのタイムアウトフィールドを設定する、特定のレコードの時刻参照フィールドを設定する、任意のオプションのレコードを更新する、操作である。
【００５３】
上記に開示した１５個の操作のうち２つの操作について、以下に詳細に説明する。当業者には、これら２つの操作の説明とそのあとの本文から、開示された残りの操作についても明らかになるであろう。
【００５４】
図５は、特定のタグ値に関連付けられているアプリケーション名の問合せの結果を受信者に送信する操作を示す。いま、クライアントが、アプリケーションデータユニット１３と新しいアプリケーションタグとをＡＣ６を介して受信し、その新しいアプリケーションタグに属すアプリケーション名を知りたいとする。ステップＳ１００において、ＡＣ６は、新しいアプリケーションタグのアプリケーション名についての問合せをＡＳＮＳに送信する。ステップＳ１０１において、ＡＳＮＳは、この問合せを受信する。次に、ＡＳＮＳは、その新しいアプリケーションタグに対応するタグ値フィールド２５内のタグ値を検索する。この検索は、ステップＳ１０２において、ＡＴＤＢ２４を検索することによって行われる。タグ値が見つかると、同じレコードの中のアプリケーション名がコピーされ、ステップＳ１０３において、この問合せを送信したＡＣ６に戻される。名前を受信したＡＣ６は、ユーザ端末５にそのアプリケーション名を表示できる。
【００５５】
次に、所有者のないタグ値を見つけて、アプリケーション名と所有者を設定し、タグ値を送信者に戻す操作の一例について、図６を参照しながら説明する。ステップＳ２００において、ＡＣ６は、所有者のないアプリケーションタグの要求を送信する。この要求には、アプリケーション名と所有者識別子とが含まれる。ステップＳ２０１において、ＡＳＮＳは、この要求を受信し、ユーザ端末５のネットワークアドレスを登録する。次に、ステップＳ２０２において、ＡＳＮＳは、空のレコード所有者フィールドがないか、ＡＴＤＢ２４の中のレコード所有者フィールド２７を検索する。最初に見つかった空のレコード所有者フィールド２７のレコードが使用されて、対応するタグ値フィールド２５の中のタグ値が取得される。これは、ステップＳ２０３において行われる。ステップＳ２０４において、ＡＳＮＳは、問合せからアプリケーション名と所有者識別子を検索する。このアプリケーション名と所有者は、それぞれ、アプリケーション名フィールド２６とレコード所有者フィールド２７に記憶される。ステップＳ２０５において、ＡＳＮＳは、先の利用可能なタグ値を、要求元のＡＣ６に送信する。利用可能なタグ値がない場合、ＡＳＮＳは、メッセージ（例えばそのアプリケーションセッションにはそれ以上の参加者が許可されない）をＡＣ６に送信する。操作が成功すると、そのタグ値は所有者によって使用される。ステップＳ２０６において、ＡＳＮＳは、別のＡＣと、アプリケーションに使用されている別のサーバにもそのタグ値を送信できる。
【００５６】
アプリケーションによっては、ＤＢＭＳ３０によって未使用のタグ値にマッピングできるアプリケーション名が１つのみであることがある。例えば、ユーザが望むアプリケーション名「Ｂｌａｃｋ＿Ｋｉｎｇ」を、ＡＴＤＢ２４中の未使用のタグ値にマッピングするには、アプリケーション名フィールド２７が「空である」レコードのアプリケーション名フィールド２７にこのアプリケーション名を記憶する。これは、例えば次に示すＳＱＬ（構造化照会言語）コードを使用して行われる。
ＩＮＳＥＲＴ　ＩＮＴＯ　ＴａｂｌｅＮａｍｅ　（ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ）　ＶＡＬＵＥＳ　（“ＢＬＡＣＫ＿ＫＩＮＧ”）　ＷＨＥＲＥ　ＴａｇＶａｌｕｅ　＝　（ＳＥＬＥＣＴ　ＴａｇＶａｌｕｅ　ＦＲＯＭ　ＴａｂｌｅＮａｍｅ　ｗｈｅｒｅ　ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ　＝　“”）
【００５７】
ＡＳＮＳは、オプションとして、アプリケーションタグの各タイプについて各タグ値が１つのアプリケーション名のみに結合されるようにする。これに違反する操作が行われようとした場合、例えばＡＣ６にエラーが報告される。これに代わる方式として、ＡＳＮＳは、特定のタグ値に対していくつかのアプリケーション名が結合されることを許可する。その場合、クライアントはアプリケーション名の別名を割り当てる。
【００５８】
ユーザが望む２つのアプリケーション名を１つの未使用のタグ値にマッピングするためのＳＱＬコードの例を次に示す。
ＩＮＳＥＲＴ　ＩＮＴＯ　ＴａｂｌｅＮａｍｅ　（ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ１）　ＶＡＬＵＥＳ　（“ＢＬＡＣＫ＿ＫＩＮＧ”）　ＷＨＥＲＥ　ＴａｇＶａｌｕｅ　＝　（ＳＥＬＥＣＴ　ＴａｇＶａｌｕｅ　ＦＲＯＭ　ＴａｂｌｅＮａｍｅ　ｗｈｅｒｅ　ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ　＝　“”）
ＩＮＳＥＲＴ　ＩＮＴＯ　ＴａｂｌｅＮａｍｅ　（ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ２）　ＶＡＬＵＥＳ　（“Ｔｈｅ＿ＫＩＮＧ”）　ＷＨＥＲＥ　ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ１　＝　“ＢＬＡＣＫ＿ＫＩＮＧ”
【００５９】
第２の代替方法においては、ＡＳＮＳは、いくつかのアプリケーションタグが１つのアプリケーション名に割り当てられることを許可する。この場合、アプリケーション名は、ネットワークリソースのクラスタ、例えば通信ネットワーク１における利用可能なユーザ端末５に結合される。
【００６０】
オプションとして、アプリケーションタグの各タイプについて各名前を１回のみ使用できるようにすることができる。これに違反する操作が行われようとした場合、エラーが報告される。
【００６１】
本発明の１つの実施例においては、ＡＳＮＳの操作を実行するための許可が制御される。クライアントごとに異なる権限を持たせることができ、特に、アプリケーション名を変更または無効にできるのが、アプリケーション名の所有者のみとなるように設定できる。
【００６２】
図１に示されているように、１つのセッションに関与するＡＳＮＳは１つのみでよい。このことの利点は、更新するための手段が必要ないことである。これに代わる方式として、１つのセッションに複数のＡＳＮＳが存在してもよく、この場合、異なるＡＳＮＳの間で確実に更新を行うための手段と方法が必要になる。この場合、分散型データベースを更新状態に維持するための一般的な方法を使用できるが、この方法は本発明には属さない。従って、この更新方法については、これ以上説明しない。
【００６３】
オプションとして、ＡＳＮＳをいくつかの場所に分割して、ＡＴＤＢ２４の異なる部分が異なるサーバユニットまたはノードに配置されるようにできる。
【００６４】
さらに、１つの単純な方法は、アプリケーション名は設定のみでき変更はできないようにすることである。このことは、設定されたアプリケーション名すべてをＡＴＤＢ２４のすべてのインスタンスに確実に伝える必要があることを意味する。
【００６５】
次に、本発明の利点とオプションをよく理解できるように、ＡＳＮＳを使用できるアプリケーションセッションの例をいくつか説明する。
【００６６】
アプリケーションセッションの最初の例は、プレイヤーの別名の使用に関する。いわゆるリアルタイムアクションゲームなどのマルチプレイヤーゲームでは、プレイヤーはアプリケーションセッション中にゲームに参加したり抜けることができる。各プレイヤーは、「Ｈｅｌｌｆｉｒｅ」や「Ｅｖｉｌ＿Ｒｅａｐｅｒ」などの別名を持つ。プレイヤーを表すキャラクターは、プレイヤーの別名が付けられ、この別名は点数と殺人のリストにおいても使用される。各別名は、いくつかのバイトとして符号化される文字列である。「Ｈｅｌｌｆｉｒｅ」と「Ｅｖｉｌ＿Ｒｅａｐｅｒ」は、例えばそれぞれ９バイト、１２バイトを必要とする。
【００６７】
アプリケーションデータユニットは、各キャラクターの位置、武器、ダメージなどを伝えるＵＤＰ　（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）パケットである。各アプリケーションデータユニット１３には、該当するプレイヤーを識別するアプリケーションタグが付く。最大２５６人のプレイヤーが参加するゲームにおいては、アプリケーションタグは１バイトで構成できる。各プレイヤーは、８ビットの一意の組合せによって表される。
【００６８】
ＡＳＮＳは、プレイヤーの別名とタグ値とを結合するのに使用される。セッションに参加するプレイヤーは、図６を参照して上述されている「所有者のないアプリケーションタグを検索し、名前と所有者を設定し、タグ値を送信者に戻す」操作により、ゲームサーバまたはＡＳＮＳから未使用のタグ値を取得する。プレイヤーは、自分の別名に対応する名前を設定し、この名前は未使用のタグ値に結合される。その後、プレイヤーは、自分のキャラクターの特性をＡＣ６とユーザ端末５とを通じて他のプレイヤーに送信する。
【００６９】
他のユーザ端末５は、新しいアプリケーションタグの付いたアプリケーションデータユニット１３を受信すると、図５を参照して上述されている「特定のタグ値に関連付けられているアプリケーション名の問合せの結果を特定の受信者に送信する」操作を使用して、そのアプリケーションタグに属す名前についてＡＳＮＳに問合せを行う。これにより、アプリケーションは新しいキャラクターを表示させることができる。他のクライアントは、アプリケーションデータの中に新しい別名を見つけることもある。その場合、他のクライアントは、別名に対応するタグ値を、ＡＳＮＳを介して発見し、そのタグ値に対応する通信チャネルをサブスクライブできる。
【００７０】
ゲームから抜けるクライアントは、別名に対応するＡＳＮＳレコードを無効にし、これによりタグ値を解放できる。ゲームを抜けるクライアントがレコードを無効にしなかった場合でも、対応するレコード内のタイムアウトフィールド２９などのタイムアウトメカニズムを使用することで、タグ値を解放できる。時刻参照フィールド２８は、例えば、サービスプロバイダの課金システムによって使用できる。
【００７１】
ＡＳＮＳの使用が有利であるアプリケーションセッションの第２の例は、ピアツーピア方式のフライトシミュレーションゲームである。この場合、ユーザ端末６の１つがフライトコントロールのＡＩを実行する。フライトコントロールの命令と情報は、タグの付いた通信チャネルを介して配信される。フライトコントロールの機能のコーディングに属すアプリケーションタグは、その時点でフライトコントロールのＡＩを実行中のクライアントが所有する。いま、このクライアントが、ＡＳＮＳの中の該当するアプリケーションタグに対する名前として、例えばＦＬＩＧＨＴ＿ＣＯＮＴＲＯＬと定義したとする。例えば心拍を描いたアプリケーションアイテムが、このタグの付いたチャネルを使用して送信され、フライトコントロールが動作可能であることが示される。新しいクライアントは、名前ＦＬＩＧＨＴ＿ＣＯＮＴＲＯＬを認識し、対応するアプリケーションタグをＡＳＮＳに求め、次いでそれをサブスクライブする。
【００７２】
いま、フライトコントロールを実行するクライアントが突然にゲームを抜けるとする。ＡＴＤＢ２４の中のＦＬＩＧＨＴ＿ＣＯＮＴＲＯＬのレコードは、ゲームを抜けるクライアントがこれを無効にすることによって自動的に削除されるか、またはＡＴＤＢ２４の中のタイムアウトフィールド２９に記憶されているタイムアウトの設定値がＡＴＤＢ２４から読み取られることによって自動的に削除される。クライアントが抜けた後、残りのクライアントは、フライトコントロールからの心拍が停止したことに気づく。残りの各クライアントは、それぞれ任意の時間だけ待った後、ＡＳＮＳのタグ値の定義を、アプリケーション名ＦＬＩＧＨＴ＿ＣＯＮＴＲＯＬを使用して設定しようと試みる。このタグ値は任意であり、ＡＳＮＳは、この名前が未定義になった以降に最初に到着した定義を受理する。それ以降にこのアプリケーション名を設定しようとする試みは拒否される。各クライアントは一定の時間だけ待った後、アプリケーション名ＦＬＩＧＨＴ＿ＣＯＮＴＲＯＬを持つタグ値をＡＳＮＳに求める。ＡＳＮＳは、このアプリケーション名をすべてのクライアントに配信し、このオブジェクトを所有するクライアントが、フライトコントロールの処理を開始し、フライトコントロールのデータの送信を続ける。ゲームの管理者が必要な、またはオプションとして含まれるアプリケーションにおいては、ゲームの管理者の役割を果たすクライアントを使用することによって、これと同じ機能を達成できる。
【００７３】
本発明の使用が有利であるアプリケーションセッションの第３の例は、制限のない世界におけるピアツーピア方式のゲームであり、この例においては、地理的に制限のない仮想世界におけるピアツーピア方式のコンピュータゲーム（例えば宇宙戦略ゲーム）である。ゲームに参加するチームは、自分たちの惑星を示す地図を所持する。惑星及びその他のサイトが戦闘において破壊されることがある。地理上の新しいサイトすべて（惑星、都市、建物、船）には、地図の設計者によって名前が付けられ、サイトの数はプレイヤーよりずっと多い。
【００７４】
ゲームデータは、一連のチャネルを介して配信される。各チャネルには、一意のアプリケーションタグが付く。各アプリケーションタグは、ゲームの世界における特定のサイトに対応する。特定のサイトに位置するキャラクターをクライアントがコントロールするときに、対応するアプリケーションタグが例えばその位置を示すデータユニットに付加される。クライアントは、同じアプリケーションタグの付いたデータもサブスクライブする。すなわち、クライアントはそのサイトにおける全キャラクターについてのデータを選択的に受信する。
【００７５】
利用できるアプリケーションタグの数には上限があり、アプリケーションタグの数は、ゲーム内のアプリケーション名や地理的な場所の数よりもずっと少ない。数の制限されたアプリケーションタグを地理的なサイトに動的に割り当てるために、ＡＳＮＳが使用される。例えばＬＡＢＡＮと呼ばれる無人の惑星に最初に到着したプレイヤーは、ＬＡＢＡＮに対応するタグ値をＡＳＮＳに求める。この惑星には誰もいないため、プレイヤーは未使用のアプリケーションタグを選択し、アプリケーション名を設定する。その次にＬＡＢＡＮに着陸したプレイヤーは、定義済みのアプリケーション名を見つけ、そのアプリケーションタグの付いたアプリケーションデータをサブスクライブできる。ＬＡＢＡＮを離れる最後のプレイヤーは、最初のプレイヤーにアプリケーションタグを解放すべきことを知らせる。この後、このアプリケーションタグの付いたパケットにおいて送信されるアプリケーションデータのサブスクリプションすべてが自動的に取り消される。
【図面の簡単な説明】
【図１】
本発明による通信ネットワークの実施例を示す。
【図２】
アプリケーションデータユニットが含まれるパケットを示す。
【図３】
本発明によるサーバの線図を示す。
【図４】
サーバ内のデータベースの中のレコードを示す。
【図５】
特定のアプリケーションタグの名前を取得する操作のフローチャートを示す。
【図６】
本発明による別の可能な操作のフローチャートを示す。
【図１】
2004512622.tif 000003
【図２】
2004512622.tif 000004
【図３】
2004512622.tif 000005
【図４】
2004512622.tif 000006
【図５】
2004512622.tif 000007
【図６】
2004512622.tif 000008
【国際公開パンフレット】
2004512622.tif 000009
2004512622.tif 000010
2004512622.tif 000011
2004512622.tif 000012
2004512622.tif 000013
2004512622.tif 000014
2004512622.tif 000015
2004512622.tif 000016
2004512622.tif 000017
2004512622.tif 000018
2004512622.tif 000019
2004512622.tif 000020
2004512622.tif 000021
2004512622.tif 000022
2004512622.tif 000023
2004512622.tif 000024
2004512622.tif 000025
2004512622.tif 000026
2004512622.tif 000027
2004512622.tif 000028
2004512622.tif 000029
2004512622.tif 000030
2004512622.tif 000031
2004512622.tif 000032
2004512622.tif 000033
2004512622.tif 000034
2004512622.tif 000035
2004512622.tif 000036
2004512622.tif 000037
2004512622.tif 000038
2004512622.tif 000039
【国際調査報告】
2004512622.tif 000040
2004512622.tif 000041