JP2009533925A - ノード - Google Patents

Abstract

【課題】無線通信ネットワーク内のピアツーピアネットワークサービスを提供するためのノードを提供する。
【解決手段】通信ネットワークにおいてピアツーピアサービスを提供するためのノードであって、ネットワークが少なくとも１つの別のノードを含み、ノードが、少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成された入力と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから少なくとも１つの別のノードの少なくとも１つに送信するよう構成された出力と、を備える。入力が、少なくとも１つの別のノードから少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成され、出力が、ＳＩＰピアツーピア応答を送信するように構成されている。
【選択図】図１

Description

本発明は、ノードに関し、より具体的には、限定ではないが、無線通信ネットワーク内のピアツーピアネットワークサービスを提供するためのノードに関する。

通信システムは、ユーザ装置及び／又は通信システムに関連するノードなど２つ又はそれ以上のエンティティ間の通信セッションを可能にする機構とみなすことができる。通信は、例えば、音声、データ、マルチメディアなどの通信を含むことができる。セッションは、例えば、ユーザ間の通話、多方向会議セッション、又はユーザ装置とアプリケーションサーバ（ＡＳ）（例えばサービスプロバイダサーバ）との間の通信セッションとすることができる。これらのセッションが確立されると、一般に、ユーザに種々のサービスを提供することができるようになる。

通信システムは通常、通信システムに関連する種々のエンティティが許可されること、及びこれをどのように達成すべきかについて記述した所与の標準規格又は仕様に従って動作する。例えば、標準規格又は仕様は、ユーザ、すなわちより正確にはユーザ装置が回路交換サービス及び／又はパケット交換サービスを備えているかどうかを定義することができる。接続に使用されるようにする通信プロトコル及び／又はパラメータも定義することができる。換言すると、通信システムを利用して通信を可能にするために、通信のベースとすることができる特定の「ルール」セットを定義する必要がある。

ユーザ装置に無線通信を提供する通信システムは公知である。無線通信の１つの実施例は、公衆陸上移動ネットワーク（ＰＬＭＮ）であり、別の実施例は、無線ローカルエリアネットワーク（ＷＬＡＮ）である。固定ブロードバンド接続は別のタイプの接続方式である。

上記及び以下で使用される用語「サービス」とは、ユーザが要求し、又は必要とし、或いは備えることができるあらゆるサービス又は商品を広範に対象とすることは理解される。この用語はまた、無料サービスの提供を対象とすることは理解される。詳細には、限定ではないが、用語「サービス」とは、インターネットプロトコルマルチメディアＩＭサービス、会議、電話通信、ゲーム、リッチコール（Ｒｉｃｈ ｃａｌｌｓ）、その他を含むことは理解される。

通信システムへの加入者などのユーザに提供することができるサービスの１つの実施例は、いわゆるマルチメディアサービスである。マルチメディアサービスの提供が可能になった通信システムの一部は、インターネットプロトコル（ＩＰ）マルチメディアサービスとして知られている。ＩＰマルチメディア（ＩＭ）機能は、ＩＰマルチメディアコアネットワーク（ＣＮ）サブシステム、又は略してＩＰマルチメディアサブシステム（ＩＭＳ）を利用して提供することができる。ＩＭＳサービスは、他のサービスの中でも特に、モバイルユーザ装置間のＩＰ接続を提供することが意図されている。

従来のＩＰネットワーク上で動作するピアツーピア（Ｐ２Ｐ）オーバーレイネットワーク（以下ピアツーピアネットワーク又はＰ２Ｐネットワークと呼ばれる）は、リソース材料を共有するために、リソースの完全配信及びピアを支援する中央サーバの介入を最小限にするといった共通の特徴を共有する。Ｐ２Ｐネットワークは通常、ピアとして知られ、インターネットなどパケット交換ネットワークを介して接続される要素のグループ（通常はパーソナルコンピュータ）である。リソースは、どのようなものであってもよく、典型的にはファイル（画像、ビデオクリップ、又はサウンドトラックなど）又はデータストリーム（ビデオストリーム、又はデジタルエンコードされた音声データなど）であり、ピア要素において格納又は生成される。従って、Ｐ２Ｐネットワークは通常、従来のリソースネットワークとは異なり、従来のネットワークが通常リソースの提供に中央サーバを用いるのに対して、Ｐ２Ｐネットワークではネットワークの参加者が他のユーザにリソースを提供する。Ｋａｚａａ、ＷｉｎＭＸ、Ｅｍｕｌｅ、ＢｉｔＴｏｒｒｅｎｔなどの既知のＰ２Ｐネットワークは、ファイル共有ネットワークであり、一方、Ｓｋｙｐｅは電話通信Ｐ２Ｐネットワークである。

Ｐ２Ｐネットワークは、従来のＰＣネットワークにおいて知られているが、無線通信リンク上でのＰ２Ｐネットワークの利用には幾つかの問題がある。

無線通信ネットワーク上でのＰ２Ｐネットワークの利用に関する第１の問題は、ブロードバンド接続を用いる従来のユーザとは異なり、ユーザが連続してネットワークに接続されていないことである。ユーザ装置は、例えば地下鉄又は道路トンネルなど無線受信可能範囲が存在しない場所に一時的に移動する可能性がある。従って、接続が永続しない汎用パケット無線システム（ＧＰＲＳ）通信システム又は無線ローカルエリアネットワーク（ＷＬＡＮ）接続を介して接続しているＩＰユーザは、ユーザがＰ２Ｐネットワークを出入りするときにネットワーク全体においてシグナリングオーバヘッドの有意な量を生成することになる。

第２の問題は、無線通信ネットワーク上で接続されたユーザ装置が通常ネットワークアドレスに変換される点である。換言すると、ＧＰＲＳ又はＷＬＡＮネットワークサーバは、プライベートインターネットプロトコル（ＩＰ）アドレスをノードに与える。このプライベートＩＰアドレスは、インターネットから直接到達可能ではなく、トラフィックは、アドレス変換機構のパブリックＩＰアドレスに配向され、次いで、アドレス変換機構がユーザ装置にパケットをリダイレクトする。このことは、Ｐ２Ｐネットワークを接続するときのＵＥの可用性を制限する。例えば、ＵＥが１つのＧＰＲＳ又はＷＬＡＮネットワークから別のネットワークに移動した場合、ユーザ装置は異なるプライベートＩＰアドレスと異なるパブリックＩＰアドレスとを受け取ることになり、シグナリングオーバヘッドの変更及び増大をＰ２Ｐネットワークに通知することが必要になる。

ＷＯ２００５／４１５３４は、上述のような欠点を有するピュアアドホックネットワークを開示している。

ＵＳ２００３／１２５０６３では、一連のネットワークサーバがユーザ装置上のコンテンツをミラーリングする無線通信Ｐ２Ｐネットワークを開示している。こうしたシステムは、システムが正確に動作するために、ミラーされるコンテンツは最初にユーザ装置からアップロードされ、更にコンテンツはユーザ装置上に現在格納されているものと同じであるよう維持される必要があるので効率的ではない。従って、このシステムは、全データがミラーにアップロードされる必要があるので回線容量が非効率であり、更に、同じリソースが少なくとも２つの別の場所に存在することからリソースが非効率である。

ＵＳ２００４／０２４３６６５及びＵＳ２００４／０２４３５８０は、ピアツーピアサービスのためノードユーザ間の通信を可能にするモバイルユーザシステムを開示している。

Ｍａｔｕｓｚｅｗｓｋｉ， Ｍ．， Ｂｅｉｊａｒ， Ｎ．， Ｌｅｈｔｉｎｅｎ， Ｊ． ａｎｄ Ｈｙｙｒｙｌａｉｎｅｎ， Ｔ． （２００６）「Ｍｏｂｉｌｅ Ｐｅｅｒ− ｔｏ−Ｐｅｅｒ Ｃｏｎｔｅｎｔ Ｓｈａｒｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ」， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＥＥＥ Ｃｏｎｓｕｍｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋｉｎｇ Ｃｏｎｆｅｒｅｎｃｅ， Ｊａｎｕａｒｙでは、Ｐ２Ｐコンテンツ共有サービスの実証を収めているが、こうしたシステムは、単一のスーパーピアノードを用いてモデル化されており、システムに関連するシグナリングの情報を提供するものではない。

Ｂｅｉｊａｒ， Ｎ．， Ｍａｔｕｓｚｅｗｓｋｉ， Ｍ．， Ｌｅｈｔｉｎｅｎ， Ｊ．， ａｎｄ Ｈｙｙｒｙｌａｉｎｅｎ， Ｔ． （２００５） ‘Ｍｏｂｉｌｅ Ｐｅｅｒ− ｔｏ−Ｐｅｅｒ Ｃｏｎｔｅｎｔ Ｓｈａｒｉｎｇ Ｓｅｒｖｉｃｅｓ ｉｎ ＩＭＳ’， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ Ｔｈｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍｓ， Ｍｏｄｅｌｉｎｇ ａｎｄ Ａｎａｌｙｓｉｓ ２００５， Ｎｏｖｅｍｂｅｒではまた、ＩＭＳネットワークに適用することができるＰ２Ｐコンテンツ共有アーキテクチャを含めている。しかしながら、ＩＭＳアーキテクチャ上でＩＭＳシグナリングを備えたＰ２Ｐネットワークを実装する方法は具体的には開示されていない。

ＷＯ２００５／４１５３４公報 ＵＳ２００３／１２５０６３公報 ＵＳ２００４／０２４３６６５公報 ＵＳ２００４／０２４３５８０公報 Ｍａｔｕｓｚｅｗｓｋｉ， Ｍ．， Ｂｅｉｊａｒ， Ｎ．， Ｌｅｈｔｉｎｅｎ， Ｊ． ａｎｄ Ｈｙｙｒｙｌａｉｎｅｎ， Ｔ． （２００６）「Ｍｏｂｉｌｅ Ｐｅｅｒ− ｔｏ−Ｐｅｅｒ Ｃｏｎｔｅｎｔ Ｓｈａｒｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ」， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＥＥＥ Ｃｏｎｓｕｍｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋｉｎｇ Ｃｏｎｆｅｒｅｎｃｅ， Ｊａｎｕａｒｙ Ｂｅｉｊａｒ， Ｎ．， Ｍａｔｕｓｚｅｗｓｋｉ， Ｍ．， Ｌｅｈｔｉｎｅｎ， Ｊ．， ａｎｄ Ｈｙｙｒｙｌａｉｎｅｎ， Ｔ． （２００５） ‘Ｍｏｂｉｌｅ Ｐｅｅｒ− ｔｏ−Ｐｅｅｒ Ｃｏｎｔｅｎｔ Ｓｈａｒｉｎｇ Ｓｅｒｖｉｃｅｓ ｉｎ ＩＭＳ’， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ Ｔｈｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍｓ， Ｍｏｄｅｌｉｎｇ ａｎｄ Ａｎａｌｙｓｉｓ ２００５， Ｎｏｖｅｍｂｅｒ

本発明の実施形態は、上記で開示された問題に対処し、又は少なくとも部分的に軽減することを意図している。

本発明によれば、通信ネットワークにおいてピアツーピアサービスを提供するためのノードであって、ネットワークが少なくとも１つの別のノードを含み、ノードが、少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成された入力と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから前記少なくとも１つの別のノードの少なくとも１つに送信するよう構成された出力とを備え、入力が少なくとも１つの別のノードから少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成され、出力がＳＩＰピアツーピア応答を送信するように構成されていることを特徴とするノードが提供される。

ノード入力は、アクセスネットワークを介してユーザ装置（ＵＥ）から少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成することができる。

ノード出力は、アクセスネットワークを介してユーザ装置（ＵＥ）にＳＩＰピアツーピア応答を送信するよう構成することができる。

ユーザ装置は好ましくはＰ２Ｐ２次ノードである。

ノード入力は、好ましくは、別のノードの少なくとも別の１つから少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている。

ノード出力は、好ましくは、別のノードの少なくとも別の１つにＳＩＰピアツーピア応答を送信するように構成されている。

ノードは、好ましくはＰ２Ｐ一次ノードである。

ピアツーピアリクエストはピアツーピアリソース公開を含むことができる。

少なくとも１つのピアツーピアリソース公開リクエストが第１の情報要素を含むことができる。

ノードは、好ましくはメモリを備え、情報記憶装置内に第１の情報要素を格納するように更に構成することができる。

第１の情報要素は、好ましくは、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースのアドレスのＳＩＰ ＵＲＩ、リソースの端末アドレス、記リソースのタイムスタンプ、ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つである。

少なくとも１つのピアツーピアリソース公開リクエストは、好ましくはＳＩＰ ＰＵＢＬＩＳＨリクエストである。

ＳＩＰピアツーピアリクエストは、好ましくはリクエストされたリソース要素を有するサーチリクエストを含む。

サーチリクエストは、好ましくはＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストである。

ノードがメモリを更に備えることができ、該ノードは、好ましくは、リクエストされたリソース要素と合致するリクエストされたリソースを含む少なくとも１つのノードのアドレスを求めて該メモリをサーチするよう構成されている。

ＳＩＰピアツーピア応答は、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むネットワークノードのアドレスを有することができる。

ＳＩＰピアツーピア応答は、好ましくはＳＩＰ ＮＯＴＩＦＹメッセージを含む。

アドレスは、ＳＩＰ ＵＲＩ、ネットワークノードアドレス、端末アドレス、及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）のうちの少なくとも１つを含むことができる。

応答メッセージはリクエストされたリソース要素を有するリソースを含み、該リソース要素が、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つを含むことができる。

通信ネットワークは、好ましくは、ＩＰマルチメディアサブシステムを含む。

ノードは、好ましくはＳＩＰピアツーピアアプリケーションサーバである。

上述の少なくとも１つのノードは、好ましくは、オーバーレイピアツーピアネットワークに組み込まれる。

本発明の第２の態様によれば、通信ネットワークにおいてピアツーピアサービスを提供するためのノードと通信するよう構成されたユーザ装置であって、ノードが少なくとも１つの別のノードを含むネットワークにおいて使用中のノードであり、ユーザ装置が、少なくとも１つのＳＩＰピアツーピアリクエストをアクセスネットワークを介してノードに送信するよう構成された出力と、少なくとも１つのＳＩＰピアツーピア応答をアクセスネットワークを介してノードから受け取るように構成された入力とを備えるユーザ装置が提供される。

少なくとも１つのＳＩＰピアツーピアリクエストは、好ましくはピアツーピアリソース公開である。

少なくとも１つのピアツーピアリソース公開リクエストは好ましくは第１の情報要素を含む。

第１の情報要素は、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの短い説明、リソースのハッシュ、リソースのアドレスのＳＩＰ ＵＲＩ、リソースの端末アドレス、リソースのタイムスタンプ、ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つとすることができる。

少なくとも１つのピアツーピアリソース公開リクエストは好ましくはＳＩＰ ＰＵＢＬＩＳＨリクエストである。

ＳＩＰピアツーピアリクエストは、リクエストされたリソース要素を好ましくは有するサーチリクエストとすることができる。

サーチリクエストは好ましくはＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストである。

ＳＩＰピアツーピア応答は、好ましくは、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードのアドレスを有する。

ＳＩＰピアツーピア応答は好ましくはＳＩＰ ＮＯＴＩＦＹメッセージである。

アドレスは、好ましくは、ＳＩＰ ＵＲＩ、ネットワークノードアドレス、端末アドレス、及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）のうちの少なくとも１つを含む。

応答メッセージはリクエストされたリソース要素を有するリソースを含むことができ、リソース要素は、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つを含むことができる。

入力は、好ましくは、アクセスネットワークを介してノードから少なくとも１つの別のＳＩＰピアツーピア応答を受け取るように構成されている。

少なくとも１つの別のＳＩＰピアツーピア応答は、好ましくはサーチリクエストサーチ情報要素に合致するリクエストされたリソースを含む別のノードのアドレスを有する。

ユーザ装置は、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードのアドレスを表示するように構成することができる。

ユーザ装置は、好ましくは、リクエストされたリソースにアクセスするためサーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードと通信するよう構成される。

ユーザ装置は、好ましくは、ＳＩＰリクエストを送信することによって、リクエストされたリソースにアクセスするためサーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードと通信を開始するよう構成されている。

本発明の第３の態様によれば、上述のような少なくとも１つのノードと、少なくとも１つのユーザ装置と、少なくとも１つのユーザ装置から送信されたＳＩＰピアツーピアリクエストを受け取るように構成されたアクセスネットワークと、少なくともアクセスネットワーク及び他のＩＰマルチメディアネットワークからＳＩＰピアツーピアリクエストを受け取るように構成されたＩＰマルチメディアネットワークコアとを備え、ノードが、ＩＰマルチメディアネットワークコアからＳＩＰピアツーピアリクエストを受け取るように構成されている通信ネットワークが提供される。

ＩＰマルチメディアネットワークは、好ましくは少なくとも１つのユーザ装置に対してノードから送信されたＳＩＰピアツーピア応答を受け取るよう構成され、更に好ましくは、ＳＩＰピアツーピア応答をアクセスネットワークに転送するよう構成されており、アクセスネットワークは、ＳＩＰピアツーピア応答を少なくとも１つのユーザ装置に転送するよう構成されている。

本発明の第４の態様によれば、通信ネットワーク内でノード間のＳＩＰピアツーピアネットワークを動作させる方法であって、少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから少なくとも１つの他のノードに送信する段階と、少なくとも１つの他のノードからのＳＩＰピアツーピア応答メッセージをノードで受け取る段階と、ＳＩＰピアツーピア応答メッセージをノードからモバイルユーザ装置に送信する段階とを含む方法が提供される。

ＳＩＰピアツーピアリクエストは、好ましくは第１の情報要素を含む公開リクエストである。

本方法は更に、ノードの情報記憶装置内に第１の情報要素を格納する段階を含むことができる。

第１の情報要素は、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの短い説明、リソースのハッシュ、リソースのアドレスのＳＩＰ ＵＲＩ、リソースの端末アドレス、リソースのタイムスタンプ、ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つとすることができる。

公開リクエストは、好ましくはＳＩＰ ＰＵＢＬＩＳＨリクエストである。

ピアツーピアリクエストは、好ましくはサーチ情報要素を有するサーチリクエストである。

サーチリクエストは、好ましくはＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストである。

本方法は更に、サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを求めて情報記憶装置内をサーチする段階を含むことができる。

応答メッセージは、サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを有することができる。

応答メッセージは好ましくはＳＩＰ ＮＯＴＩＦＹリクエストである。

ノードのアドレスは、好ましくは、ＳＩＰ ＵＲＩ、ネットワークノードアドレス、端末アドレス、及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）のうちの少なくとも１つを含む。

応答メッセージは、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含み、該サーチリクエストサーチ情報要素が、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つを含むことができる。

本発明の第５の態様によれば、無線通信ネットワーク内でノード間のピアツーピアネットワークを動作させるためコンピュータ上で動作するよう構成されたコンピュータプログラムであって、少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから少なくとも１つの他のノードに送信する段階と、少なくとも１つの他のノードからの応答メッセージをノードで受け取る段階と、応答メッセージをノードから送信する段階とを含むコンピュータプログラムが提供される。

ここで、本発明をより理解するために、例証として添付図面を参照する。
本発明の実施形態は、特に限定ではないが、ＩＭＳネットワークに関する。本発明の実施形態は他のネットワークに適用することもできる。

３つのオペレータによる３つの別個のドメイン１、２、３操作を示した図１を参照する。明確にするために、オペレータＡによって操作されるネットワークドメイン１だけが詳細に示されている。オペレータＡのネットワークドメイン１は、呼セッション制御機能（ＣＳＣＦ）及びＳＩＰ Ｐ２Ｐアプリケーションサーバ（ＡＳ）などの幾つかのネットワークノードを含むＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークとして図示されている。ＩＰマルチメディア（ＩＭ）機能は、サービスを提供するための種々のエンティティを含むコアネットワーク（ＣＮ）サブシステムを利用して提供することができる。

基地局３１ａ、３１ｂ、３１ｃは、モバイルユーザのモバイルユーザ装置３０ａ、３０ｂ、３０ｃと信号を送受信するよう配置されている。これに対応して、モバイルユーザ装置３０ａ、３０ｂ、３０ｃの各々は、無線インタフェースを介して基地局３１ａ、３１ｂ、３１ｃと信号を送受信することができる。図１の簡略化された表現において、基地局３１ａ及び３１ｂは、第１の無線アクセスネットワークに属し、基地局３１ｃは別個の無線アクセスネットワーク（ＲＡＮ）に属する。図示の構成において、ユーザ装置３０ａ、３０ｂ、３０ｃの各々は、基地局３１ａ、３１ｂ、３１ｃにそれぞれ関連する２つのアクセスネットワークを介してＩＭＳネットワークにアクセスすることができる。明確にするために図１は２つの無線アクセスネットワークだけの基地局を示しているが、典型的な移動体通信ネットワークは通常、幾つかの無線アクセスネットワークを含む。本発明の実施形態において、固定ユーザ装置は、無線アクセスネットワークか、又は非対称型デジタル加入者回線（ＡＤＳＬ）アクセスネットワークなどの１つ又はそれ以上の他のアクセスネットワークのいずれかを介してコアネットワークに接続することができる。

３Ｇ無線アクセスネットワーク（ＲＡＮ）は通常、適切な無線ネットワークコントローラ（ＲＮＣ）により制御される。このコントローラは明確さを高めるために図示されていない。１つのコントローラを各基地局に割り当てることができ、又は１つのコントローラが複数の基地局を制御することもできる。コントローラが個々の基地局と、複数の基地局を制御するために無線アクセスネットワークレベルとの両方に設けられる解決策も公知である。従って、ネットワークコントローラの名称、位置、及び数はシステムに応じて変わることは理解されたい。

モバイルユーザ装置３０ａ、３０ｂ、３０ｃは、ネットワークに接続するためのインターネットプロトコル（ＩＰ）通信に適合されたあらゆる適切なモバイルデバイスを用いることができる。例えば、モバイルユーザ装置３０ａ、３０ｂ、３０ｃは、パーソナルコンピュータ（ＰＣ）、携帯情報端末（ＰＤＡ）、移動局（ＭＳ）などを利用してセルラーネットワークにアクセスすることができる。以下の実施例は移動局との関連において説明されている。

当業者は典型的なユーザ装置３０ａ、３０ｂ、３０ｃの特徴及び動作に精通している。従って、これらの機能についての詳細な説明は必要ではない。通話の発信及び受信、ネットワークとのデータの送受信、及び例えばマルチメディアコンテンツの体験などのタスクのためにユーザ装置３０ａ、３０ｂ、３０ｃを用いることができることに留意すれば十分である。ユーザ装置３０ａ、３０ｂ、３０ｃは通常、これらのタスクを完遂するためのプロセッサ及びメモリ手段を備える。ユーザ装置３０ａ、３０ｂ、３０ｃは、移動体通信ネットワークの基地局と信号を無線で送受信するためのアンテナ手段を含むことができる。ユーザ装置３０ａ、３０ｂ、３０ｃはまた、ユーザ装置３０ａ、３０ｂ、３０ｃのユーザに対して画像及び他のグラフィカル情報を表示するためのディスプレイを備えることができる。スピーカ手段も設けられる。ユーザ装置３０ａ、３０ｂ、３０ｃの動作は、制御ボタン、音声コマンドなどのような適切なユーザインタフェースを用いて制御することができる。

明確にするために図１には３つのユーザ装置３０ａ、３０ｂ、３０ｃだけが示されているが、同時通信において幾つかのユーザ装置３０ａ、３０ｂ、３０ｃが存在することができる。

コアネットワーク（ＣＮ）エンティティは通常、幾つかの無線アクセスネットワークを介した通信を可能にするため、更に単一の通信システムを１つ又はそれ以上の通信システム（他のセルラシステム及び／又は固定回線通信システムなど）とインタフェース接続するための種々の制御エンティティ及びゲートウェイを含む。図１において、サービングＧＰＲＳノード（ＳＧＳＮ）３３ａ及びゲートウェイ側ＧＰＲＳノード（ＧＧＳＮ）３４ａは、ネットワークにおいてＧＰＲＳサービスのサポートを提供するのに使用される。

無線アクセスネットワークコントローラは通常、限定ではないが、サービング汎用パケット無線サービスサポートノード（ＳＧＳＮ）３３ａのような適切な１つ又は複数のコアネットワークエンティティに接続される。図示していないが、各ＳＧＳＮは通常、それぞれのユーザ装置の加入に関連する情報を格納するよう構成された指定加入者データベースにアクセスする。

無線アクセスネットワーク内のユーザ装置３０ａ、３０ｂ、３０ｃは、無線ネットワークコントローラと通信することができる。無線アクセスネットワークコントローラは、適切なインタフェース（例えばＩｕインタフェース上）を介してサービングＧＰＲＳサポートノードと通信状態にある。

サービングＧＰＲＳサポートノード３３ａも同様に通常、ＧＰＲＳバックボーンネットワーク３２ａ、３２ｃを介してゲートウェイ側ＧＰＲＳサポートノード（ＧＧＳＮ）３４ａと通信する。このインタフェースは一般に交換パケットデータインタフェースである。サービングＧＰＲＳサポートノード及び／又はゲートウェイ側ＧＰＲＳサポートノードは、ネットワークにおいてＧＰＲＳサービスに対するサポートを提供するためのものである。

ユーザ装置３０ａ、３０ｂ、３０ｃは、ＧＰＲＳネットワークを介して、一般にＩＭＳに接続されるアプリケーションサーバに接続することができる。

通信システムは、サーバとして知られるネットワークエンティティにより処理されるネットワークの種々の機能を利用してユーザ装置にサービスを提供することができるように開発された。例えば、現在の第３世代（３Ｇ）無線マルチメディアネットワークアーキテクチャにおいて、幾つかの異なるサーバが異なる機能を扱うために使用される。これらは、呼セッション制御機能（ＣＳＣＦ）４９ａ、４９ｃなどの機能を含む。呼セッション制御機能は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）、インテロゲーティング呼セッション制御機能（Ｉ−ＣＳＣＦ）、及びサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）などの種々のカテゴリに分類することができる。ＩＭＳシステムを介してアプリケーションサーバにより提供されるサービスを使用したいと望むユーザは、サービング制御エンティティに登録することが必要となる場合がある。サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）は、通信システムからサービスサービスをリクエストできるようにするために、ユーザが登録される必要のあるエンティティを３ＧのＩＭＳ構成において形成することができる。ＣＳＣＦ４９ａ、４９ｃは、ＵＴＭＳシステムのＩＭＳネットワークを定義することができる。

異なるシステムでは同様の機能は異なる名称で呼ばれることがある点を理解されたい。例えば、特定のアプリケーションでは、ＣＳＣＦ４９ａ、４９ｃは、呼状態制御機能と呼ばれることがある。

本発明の実施形態は移動局などのユーザ装置に関連して説明してきたが、本発明の実施形態は他のあらゆる好適なタイプのユーザ装置に適用可能である点を理解されたい。この実施形態では、用語「端末」とは、上述のユーザ装置の全ての実施例を対象とすることが意図されている。

図１では無線アクセスネットワークを「３Ｇ」無線アクセスネットワークとして示しているが、ユーザ装置は、他の無線アクセスネットワークを介してＩＭＳネットワークに通信できる点は理解されるであろう。更に、無線アクセスネットワークの実施例は、標準規格ＩＥＥＥ８０２ｘファミリー及びブルートゥース（Ｂｌｕｅｔｏｏｔｈ）規格により記述される無線ネットワークのようなＷＬＡＮシステムを含む。更に、ユーザ装置がコアネットワークに接続するために、図１は無線アクセスネットワークを示しているが、ＡＤＳＬ、ＡＤＳＬ２、ＳＤＳＬ、ＶＤＳＬ、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｒａｍｅ Ｒｅｌａｙなどの非無線アクセスネットワークの他のタイプも用いることができる。

図１は複数のＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄを示している。ＳＩＰ Ｐ２Ｐアプリケーションサーバのうちの２つ５１ｂ及び５１ａは、ＣＳＣＦ４９ａ及び４９ｃにそれぞれ接続されて示されている。２つのＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ｃ及び５１ｄは、オペレータＣ及びＢによりそれぞれ操作されるネットワーク内に配置されて示されている。ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂは、オペレータ内Ｐ２Ｐオーバーレイネットワークを形成するよう配置される。ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、オペレータ間ピュアＰ２Ｐオーバーレイネットワーク５３を形成する。各ＳＩＰ Ｐ２Ｐアプリケーションサーバは、外部ソースからデータを受け取るための入力と、他のＳＩＰ Ｐ２Ｐアプリケーションサーバ又はＵＥなどの外部ソースにデータを送信するための出力とを備える。更に、各ＳＩＰ Ｐ２Ｐアプリケーションサーバは、外部ソースから受け取ったデータを記憶するためのメモリを備える。

これらのＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、ＩＭＳ動作に関して標準のアプリケーションサーバとして動作するよう配置されている。加えて、これらのノードは、Ｐ２Ｐ用語により定義される一次ノード又はスーパーノードとして動作するよう配置されている（換言すると、これらのノード間の通信は、ピュアＰ２Ｐオーバーレイネットワーク上で動作し、すなわちＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄの全てが真のピアである）。

従って、各ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、同じネットワークドメイン内（オペレータ内ネットワークを形成するため）又は異なるドメイン内（オペレータ間ネットワークを形成するため）に配置された他のＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄとセッションイニシエーションプロトコル（ＳＩＰ）メッセージを送受信するよう配置される。ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、幾つかの異なる役割を有する。ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、ＵＥ３０ａ、３０ｂ、３０ｃに対してフロントエンドサーバとして動作する。ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、他のスーパーノードが利用可能なネットワークのリソースを活用するよう動作する。ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、ＵＥがリソースのサーチにより得られる結果をＰ２Ｐネットワークから入手し、リソース共有のためＰ２Ｐオーバーレイネットワークを維持するのを支援する。

本発明の幾つかの実施形態では、ネットワークにわたって情報を配信するために、１つよりも多いアルゴリズムが用いられる。例えば、オペレータ間Ｐ２Ｐオーバーレイネットワーク５３は、フラッディングアルゴリズム又は分散ハッシュアルゴリズムなどの異なるＰ２Ｐアルゴリズムを実装することができる。選択アルゴリズムは、情報を配置するための最良のアルゴリズムが適用されるように決定することができる。同様に、オペレータ内Ｐ２Ｐオーバーレイネットワークは、本発明の実施形態において、異なるＰ２Ｐアルゴリズムを実装することができる。

このネットワーク内では、ＵＥ３０ａ、３０ｂ、３０ｃは、二次又は通常Ｐ２Ｐノードとして動作するよう配置される。従って、ＵＥ３０ａ、３０ｂ、３０ｃは、ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄに接続されてこれに依存するように配置される。ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄを用いるように許可されたＵＥ３０ａ、３０ｂ、３０ｃは、ＵＥのユーザがＰ２Ｐサービスを利用したい場合、ＵＥがＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄの１つにルーティングされるように構成される。

このようなネットワークでは、ＵＥ３０ａ、３０ｂ、３０ｃは、共有されるリソースに関する情報を公開すること、並びにリソースのサーチを開始する役割を担う。従って、リソースが格納されている場所をＵＥ３０ａ、３０ｂ、３０ｃが発見すると、ＵＥは、そのリソースに作用する（例えば、ファイルをフェッチする、チャットグループに参加する、コンテンツをストリーミングする、その他）よう発見したサーバ／ＵＥに向けた標準ＳＩＰセッションを開始する。二次ＳＩＰセッションは、いずれのＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄをも横断することはできず、従って、これは、２つのＵＥ間、又はＵＥとサーバ、或いは２つのサーバ間の標準ピアツーピアＳＩＰセッションである。

図１では、ＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄの一部を非ＩＭＳ Ｐ２Ｐネットワークに接続するよう配置することができ、従って、Ｐ２Ｐネットワークの範囲が、オペレータ内ピュアＰ２Ｐオーバーレイネットワーク及びオペレータ間ピュアＰ２Ｐオーバーレイネットワークにより作成されたＩＭＳ Ｐ２Ｐネットワークを超えて延びることが可能になる。

次に、ユーザがリソース情報の公開、サーチ、及び取り出しができるようにするために、本発明の実施形態により実行される信号フローについて以下で説明する。

図２に関して、このリソース情報を他のユーザが使用できるようにリソース情報を公開するための本発明の実施形態により実行される信号フローが示されている。

ステップ１０１〜１０４は、ユーザ装置を起動又は再起動する際に実行される手順を示している。

ステップ１０１はユーザ装置３０ａの電源オンを示している。他の実施形態では、これはユーザ装置３０ａのハード又はソフトリセットとすることができる。

ステップ１０２は、基地局３１ａとして図１に示されている無線アクセスネットワークを介してパケット交換（ＰＳ）ネットワークドメイン３２ａに接続するユーザ装置３０ａを示している。

ＰＳドメイン接続が正常に実行されると、ステップ１０３を実行することができる。ステップ１０３では、ユーザ装置３０ａがパケットデータプロトコル（ＰＤＰ）コンテキストをパケット交換（ＰＳ）ドメイン３２ａと確立する。ＰＤＰコンテキストの確立が正常に完了すると、本方法はステップ１０４に進む。ステップ１０４では、ＵＥ３０ａがＩＭＳに登録を行う。これは、ＣＳＣＦ４９ａ及びＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ｂとして図示されているＩＭＳコアにてＵＥ３０ａが登録されるように示されている。

ステップ１０５〜１０８は、第２のユーザ装置３０ｃが無線アクセスネットワーク３１ｃを介してパケット交換（ＰＳ）ドメイン３２ａに接続し、ＩＭＳネットワーク（ＣＳＣＦ４９ｃ及びＳＩＰ Ｐ２Ｐアプリケーションサーバ５１ａとして図示されている）に登録を行うときに、第２のユーザ装置３０ｃにより実行される同じプロセスを示している。

ステップ１０９〜１１２は、別のユーザ装置により実行される同じプロセスを示している。

ステップ１２０〜１２４は、ＵＥ３０ａがメモリ内に記憶されたＰ２Ｐアプリケーションを起動するときにＵＥ３０ａにより実行されるデータフロー手順を示している。ステップ１２０の前に、ＵＥ３０ａは、公開されることになるリソースを求め１つ又はそれ以上の予め定義されたディレクトリ又はフォルダ内でローカルサーチを実施することができる。上述したように、これらのリソースは、リソースデータとして使用されることになる、画像ファイル、メッセージ、オーディオクリップ、ｍｐ３ファイル、ビデオファイル、又はユーザにより示された他のファイルといったファイルとすることができ、或いは、チャットルーム、ユーザ、サービス、又はストリーミングコンテンツなどの他のタイプのリソースとすることができる。

ステップ１２０では、ユーザ装置３０ａは、パケット交換ドメイン３２ａを介してＣＳＣＦ４９ａにＳＩＰ ＰＵＢＬＩＳＨメッセージを送信する。ＳＩＰ ＰＵＢＬＩＳＨメッセージ内にはｐ２ｐリソース事象が埋め込まれる。ｐ２ｐリソース事象は、他のユーザがサーチ手順中に見出したリソースコンテンツを決定する際に支援する種々のタイプの情報を含む。ｐ２ｐリソース事象内の情報は、種々の実施形態において、ファイル名、リソースのタイプ（リソースコンテンツが、例えば画像又はオーディオファイルであるか）、リソースのサイズ、リソースを表すアイコン（例えば、画像ファイルの場合、リソースのサムネール）、リソースの簡単な説明、ファイルのハッシュ、ＳＩＰ ＵＲＩ（すなわち、ＳＩＰアドレス）並びにファイルが格納されるユーザ及びユーザエージェントの端末アドレス（例えば、グローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）の使用）、リソースに関連するアクセス権、及びリソースに関連する他のメタデータとすることができる。

ステップ１２１において、ＩＭＳコア（ＣＳＣＦ）４９ａにてＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、該リクエストメッセージはユーザにサービスするＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにルーティングされる。

ステップ１２２では、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、リクエストを受け取ると、「２００ ＯＫ」の応答メッセージをＩＭＳコア（ＣＳＣＦにより表される）４９ａに送信する。応答メッセージは、ＩＥＴＦ ＲＦＣ ３９０３に従って、リソースに割り当てられたエンティティタグを含むＳＩＰ−ＥＴａｇヘッダを含む。

この時点では実際のリソース（例えばファイル）はＳＩＰ Ｐ２Ｐ ＡＳ５１ｂに送信されておらず、リソースに関連するメタデータだけが送信されたことを示している必要がある。ＵＥ３０ａにサービスするＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、メタデータ情報を格納する。本発明の他の実施形態において、メタデータの格納は、他のＳＩＰ Ｐ２Ｐ ＡＳ５１ａ、５１ｃ、５１ｄにおいて実施することができる。幾つかの実施形態において、メタデータは、１つよりも多いＳＩＰ Ｐ２Ｐ ＡＳ５１ａ、５１ｂ、５１ｃ、５１ｄ上に格納される。

ステップ１２３において、ＳＩＰ「２００ ＯＫ」応答メッセージは、ＩＭＳコア（ＣＳＣＦ）４９ａ及びパケット交換ドメイン３２ａを介してＵＥ３０ａにルーティングされる。

ステップ１２４では、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、オーバーレイＳＩＰ Ｐ２Ｐネットワークにおいて統合されたスーパーノードとして動作する。ＵＥ３０ａの１つからＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、オーバーレイＳＩＰ Ｐ２Ｐ ネットワークにおいてリソースメタデータ情報を公開する。リソースメタデータの実際の公開は、オーバーレイネットワークで使用される選択ピアツーピアアルゴリズムに依存する。例えば、ＳＩＰ Ｐ２Ｐ分散アルゴリズムがフラッディングに基づいている本発明の第１の実施形態において、ＳＩＰ Ｐ２Ｐ ＡＳは、必ずしも他のＳＩＰ Ｐ２Ｐ ＡＳとコンタクトをとることも、また何らかのリソースメタデータを交換することもしない。ＳＩＰ Ｐ２Ｐ分散アルゴリズムがＣｈｏｒｄアルゴリズムに基づいている本発明の別の実施形態において、ＳＩＰ Ｐ２Ｐ ＡＳは、リソースメタデータを更新して、更に少なくとも１つの別のＳＩＰ Ｐ２Ｐ ＡＳにこれを送信し、該別のＳＩＰ Ｐ２Ｐ ＡＳは、使用される分散ハッシュテーブルアルゴリズムに従って、リソースメタデータを格納する役割を担う。ＳＩＰ Ｐ２Ｐ ＡＳはまた、自己のリソースデータベース内に情報を格納することができる。

ステップ１３１〜１３４は、第２のＵＥ３０ｃがリソース情報を公開するデータフローを示している。ステップ１３１は、第２のＵＥがパケット交換（ＰＳ）ドメイン３２ｃを介してＣＳＣＦ４９にＳＩＰ ＰＵＢＬＩＳＨメッセージを送信する点でステップ１２０に類似する。ステップ１３２は、ユーザにサービスするＳＩＰ Ｐ２Ｐ ＡＳにリクエストメッセージがルーティングされる点でステップ１２１に類似する。ステップ１３３は、ＳＩＰ Ｐ２Ｐ ＡＳがＳＩＰ ＰＵＢＬＩＳＨリクエストを受け取ると、ＳＩＰ−ＥＴａｇ ｚで２００ ＯＫ応答メッセージをＩＭＳコア（ＣＳＣＦにより示される）に送信する点でステップ１２２に類似する。ステップ１３４は、ステップ１２３に類似し、ＳＩＰ「２００ ＯＫ」応答メッセージがＩＭＳコア（ＣＳＣＦ）及びパケット交換ドメインを介してＵＥ３０ｂにルーティングされる。

ステップ１３５は、リソース情報を公開する際に別のＵＥにより実行されるステップを反映した簡略化されたステップである。

ステップ１２５〜１３０は、本発明の実施形態で使用される更新プロセスを示している。このプロセスは、リソース情報の公開後にＵＥにおいてリソースが修正された場合に使用される。

ステップ１２５は、リソース（例えば、画像を表すファイル又はオーディオファイル）がＵＥ３０ａで修正されるステップである。本発明の１つの実施形態のこの修正は、リソースに関連する情報が修正されたとき、例えばリソースに関連するアクセス権が変更された（例えば、ユーザが、あるアクセスグループに対してリソースへのアクセスを制限するよう決定する）ときに行われる。本発明の別の実施形態における修正は、リソース自体が修正されたとき（例えば、例えば「赤目」として知られる効果を抑制するため画像ファイルが編集された場合、又は、例えば無音圧縮するため又は何らかのノイズフィルタを適用するためにオーディオファイルが編集された場合）に行われる。

リース又はリソースに関連する情報のいずれかに対する修正は、メタデータ情報を変更する場合がある。この変更は、例えばリソースがファイルである場合には通常、ファイルのサイズの変更が反映されるが、更にまた通常はファイルのハッシュ値をも変更する。

ステップ１２６においてＵＥ３０ａは、上述のリソースにおける変更、又は新しいコンテンツがサーチされたフォルダ又はディレクトリから付加／削除されたことが検出されたことの変更を検出したときには、新しいＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージをＩＭＳコア（ＣＳＣＦ４９ａにより表されるように）に向けて送信する。ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージは、該メッセージが最後に受信したエンティティタグ値が入っているＳＩＰ−ｉｆ−ｍａｔｃｈヘッダフィールドを含む点で、ステップ１２０で送信されたＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージとは異なる。

ステップ１２７では、ＩＭＳコア（ＣＳＣＦ）４９ａで更新ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、更新ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージは、ユーザにサービスするＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにルーティングされる。

ステップ１２８では、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、更新ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、「２００ ＯＫ」応答メッセージをＩＭＳコア（ＣＳＣＦで表される）４９ａに送信する。ＩＥＴＦ ＲＦＣ３９０３による応答メッセージは、更新応答に割り当てられたエンティティタグを含むＳＩＰ−ＥＴａｇヘッダを含む。

ステップ１２９において、ＳＩＰ ２００−ＯＫ応答メッセージは、ＩＭＳコア（ＣＳＣＦ）４９ａ及びパケット交換ドメイン３２ａを介してＵＥ３０ａにルーティングされる。

ステップ１３０では、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂがＵＥ３０ａの１つから更新ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、更新リソース又は新規に付加されたリソースに関連するオーバーレイＳＩＰ Ｐ２Ｐ ネットワークにおけるリソースメタデータ情報を再公開する。上述のように、リソースメタデータの実際の再公開はｍオーバーレイネットワークで使用される選択ピアツーピアアルゴリズムに依存する。

図３に関して、ネットワーク上でリソース情報をサーチするために本発明の実施形態により実行される信号フローが図示される。

ステップ１４０では、ユーザがＵＥ３０ａにおいてサーチを開始する。本発明の第１の実施形態では、サーチは、ユーザが「キーボード」に入力し、該入力に一致するリソースを求めてサーチするときに開始される。本発明の他の実施形態において、ユーザは、サーチするために他の値を入力し、例えば、入力は、デジタルオーディオファイル又は画像若しくはビデオクリップのフラグメントとすることができる。

ステップ１４１では、ＵＥはＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストメッセージを作成する。入力がない場合、ｐ２ｐリソース事象への加入は、オーバーレイＳＩＰ Ｐ２Ｐネットワークを通じて利用可能な全リソースのメタデータを戻すことができる。ユーザはユーザ入力に関連するリソースにのみ関心があるので、ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストメッセージは、戻される結果をユーザ入力値にリンクされ且つユーザのプロファイルを満たすのに十分なものに制限する（例えば、子供が大人向けの暴力行為を含むビデオクリップなど大人向けのリソースにアクセスするのを防ぐ）フィルタ本体を含む。

ステップ１４２において、ＩＭＳコア（ＣＳＣＦ４９ａで示される）により受け取られたＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストは、ユーザにサービスされるＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにルーティングされる。

ステップ１４２において、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストを受け取り、ステップ１４３において、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、ＩＭＳコア（ＣＳＣＦ４９ａで示される）に「２００ ＯＫ」応答メッセージを送信することによりＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストに応答する。

ステップ１４４において、ＩＭＳコア（ＣＳＣＦ４９ａ）により受け取られた「２００ ＯＫ」応答メッセージパケット交換ドメイン３２ａを介してＵＥ３０ａにルーティングされる。従って、ＵＥ３０ａは、サーチリクエストが受け取られたと判断することができる。

ステップ１４５では、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、そのデータベース内でルックアップを実行し、フィルタで指定されたリソースを保持するサーバ／ＵＥのアドレスをサーチする。このサーチ動作は、ネットワークにわたって実施されるピアツーピアアルゴリズムに依存する。従って、本発明の実施形態に基づくフラッディングアルゴリズムにおいて、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂが入力フィルタ情報で「プッシュ」された場合、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、隣接ＳＩＰ Ｐ２Ｐ ＡＳの各々又はサブセットにＳＵＢＳＣＲＩＢＥリクエストを「エクスプロード」し（すなわち、隣接ＳＩＰ Ｐ２Ｐ ＡＳにリクエストをコピーし）、次いで、これらの隣接ＳＩＰ Ｐ２Ｐ ＡＳは、その隣接するＳＩＰ Ｐ２Ｐ ＡＳにＳＵＢＳＣＲＩＢＥリクエストをエクスプロードし、以下同様である。次に、ＳＵＢＳＣＲＩＢＥリクエストメッセージを受け取るＳＩＰ Ｐ２Ｐ ＡＳの各々は、それぞれのデータベースのサーチを実施し、リソースを保持するサーバ／ＵＥ−すなわちフィルタに関連する事前公開メタデータを有するサーバ／ＵＥのアドレスをサーチする。

Ｃｈｏｒｄアルゴリズムがネットワーク内のピアツーピアアルゴリズムとして実装される本発明の別の実施形態において、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、「フィンガー」テーブル上でルックアップを実行し、そのフィンガーテーブル内のリソースに関連するキーの最直近の前任者に単一のＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストを送信する。先行ＳＩＰ Ｐ２Ｐ ＡＳノードは、別の実施形態において、及びリクエストに応じて、別のＳＩＰ Ｐ２Ｐ ＡＳノード又は他のＰ２Ｐノードにリクエストを転送又はプロキシすることができる。

ステップ１４６において、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂはまた、ＳＩＰ ＮＯＴＩＦＹリクエストをＩＭＳコア（ＣＳＣＦ４９ａ）に送信する。

ステップ１４７において、ＩＭＳコア４９ａは、ＳＩＰ ＮＯＴＩＦＹリクエストを受け取ると、該リクエストをＵＥ３０ａにルーティングする。

本発明の実施形態によれば、ＳＩＰ ＮＯＴＩＦＹリクエストは、サーチされたリソースについての情報の第１の集合（例えば、サーバ／ＵＥアドレス情報）を含むことができる。例えば、このような情報は、（他のＵＥ３０ｂからＳＩＰ Ｐ２Ｐ ＡＳ５１ｂへの公開オペレーションにより、又は前のサーチからキャッシュされた情報により、或いは他のＳＩＰ Ｐ２Ｐ ＡＳからＳＩＰ Ｐ２Ｐ ＡＳにわたされた公開情報により）ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂで既に利用可能である場合である。

しかしながら、通常本発明の実施形態では、ＳＩＰ ＮＯＴＩＦＹリクエストは、サーチされたリソースについての情報を含まない。この事象において、ＳＩＰ ＮＯＴＩＦＹリクエストは、各成功したＳＵＢＳＣＲＩＢＥリクエスト後にプロトコル（ＩＥＴＦ ＲＦＣ ３２６５）が必要とする手順に従うために必要となる。

ステップ１４８では、ＵＥ３０ａは、最初にＩＭＳコア４９ａに「２００ ＯＫ」応答を送信することによってＮＯＴＩＦＹリクエストに応答し（ステップ１４８）、次いで、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにルーティングされる（ステップ１４９）。

ステップ１５０では、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、他のＳＩＰ Ｐ２Ｐ ＡＳからサーチされたリソースについての一連の第１の結果を受け取る。これらのＳＩＰ ＮＯＴＩＦＹ応答が受け取られると、サーチに関する情報が利用可能になる。

ステップ１５１において、本発明の実施形態によれば、ユーザの選好（換言すると、受領した通知の割合、帯域幅使用量、及び事象制限）に従って、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂはＳＩＰ ＮＯＴＩＦＹリクエストメッセージをＩＭＳコア４９ａに送信する。

ステップ１５２において、ＩＭＳコアは、ＳＩＰ ＮＯＴＩＦＹリクエストメッセージをＵＥ３０ａにルーティングする。

ステップ１５１及び１５２に記載されたＳＩＰ ＮＯＴＩＦＹリクエストメッセージは、ｐ２ｐリソース事象パッケージに従ってメッセージの本体にデータを含む。事象パッケージは、各リソースに関連する全メタデータ情報を含む。例えば、リソースがファイルである場合、事象パッケージはファイル名、サイズ、タイプ、アイコン（画像ファイルの場合）、ハッシュ値、タイムスタンプ、ファイルが利用可能なユーザのＳＩＰ ＵＲＩ及び／又はＵＥアドレス（ＧＲＵＵ）を含むことができる。

本発明の幾つかの実施形態において、事象パッケージ本体は、サーチ基準に合致する幾つかのリソース（例えばファイル）についての情報を含む。当業者には理解されるように、幾つかのリソースは、幾つかの理由でサーチ基準に合致することができる。例えば、各リソース（ファイル）は、多重ダウンロード（一般的なファイルの場合）によるＳＩＰ Ｐ２Ｐオーバーレイネットワーク全体を通じた重複の結果とすることができる。

ステップ１５３において、ＵＥ３０ａは、「２００ ＯＫ」応答をＩＭＳコア４９ａに送信することによりＳＩＰ ＮＯＴＩＦＹリクエストの受信に確認応答する。ステップ１５４において、ＳＩＰ「２００ ＯＫ」メッセージはＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにルーティングされる。

ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂがＳＩＰ Ｐ２Ｐオーバーレイネットワークからのサーチに関する情報を受け取る毎に、この情報はＳＩＰ ＮＯＴＩＦＹリクエストにおいてＵＥ３０ａに送信される（通知の割合に関するユーザの選好によりこれらのリクエストを送信可能になる）。これらのＳＩＰ ＮＯＴＩＦＹリクエストメッセージはステップ１５１〜１５４を繰り返す。本発明の実施形態は、別個に受信した各情報要素を転送するので、ＵＥ３０ａのユーザ選好は、受信情報を受信すると直ぐに順次表示し、従って、結果を迅速に表示し且つ表示する前に受信情報の全てを関連付ける必要がないという点でユーザにとって使い勝手の良いシステムを提供するように構成することができ、よって、ユーザがサーチ結果の全てを受け取る前にサーチ結果を迅速に選択できるようになる。これは、同じリソースの複数のコピーがネットワーク上で利用可能な場合に特に有利である。

ステップ１５５〜１５９は、本発明の実施形態によるサーチオペレーションの終了を示している。

ステップ１５５では、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにおいて、サーチの最後の結果がオーバーレイＳＩＰ Ｐ２ＰネットワークからＳＩＰ Ｐ２Ｐ ＡＳ５１ｂが利用可能となったことを判断する。

ステップ１５６において、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは、ＵＥ３０ａをアドレス指定するＩＭＳコア４９ａにＳＩＰ ＮＯＴＩＦＹリクエストを送信する。ＳＩＰ ＮＯＴＩＦＹリクエストは、ｐ２ｐリソース事象内に少なくとも利用可能な結果を含む（何らかの報告すべきことがある場合）。ＳＩＰ ＮＯＴＩＦＹリクエストはまた、Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅヘッダフィールドを「終了」に設定し、このＮＯＴＩＦＹリクエストがサーチオペレーションの終わりであることをＵＥに表示する。

ステップ１５７において、ＳＩＰ ＮＯＴＩＦＹリクエストは、ＩＭＳコア４９ａからＰＳドメイン３２ａを介してＵＥ３０ａにルーティングされる。

ステップ１５８において、ＵＥ３０ａは、ＳＩＰ Ｐ２Ｐ ＡＳをアドレス指定するＩＭＳコアにＳＩＰ「２００ ＯＫ」メッセージを送信することによってＳＩＰ ＮＯＴＩＦＹリクエストの受信に確認応答し、次いで、ＩＭＳコアによりＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにルーティングされる（ステップ１５９）。

別のＵＥ又はネットワーク要素（ノードとも呼ばれる）においてリソースの可用性についての情報を含むＮＯＴＩＦＹリクエストを受信する（例えばステップ１５２、１５７）と、ＵＥ３０ａは、今後の使用のため受信した情報を格納する。

本発明の別の実施形態において、ユーザはまた、ゼロに設定された「期限切れ」ヘッダフィールドを含むＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにＳＩＰ ＮＯＴＩＦＹリクエストを送信するようＵＥ３０ａを構成することにより、サーチオペレーションをキャンセルすることができる。この場合、ＳＩＰ Ｐ２Ｐ ＡＳ５１ｂは自動的にタイムアウトになり、ステップ１５６に続くことができる。

図４に関して、ネットワーク上のリソース情報をフェッチするために本発明の実施形態により実行される信号フローが図示されている。

ステップ１８０において、ユーザは、通常はモバイル装置のユーザインタフェースと相互作用することにより動作することになるリソースを選択する。リソースがファイルの場合、ファイルをフェッチすることができる。リソースがチャットルーム、会議、ユーザ名、又はストリーミングビデオの場合、セッションが当該リソースに向けて開始される。

ステップ１８１において、リソース及び／又は該リソースが格納される１つ又はそれ以上のサーバ／ＵＥのアドレスが選択されると、ＵＥは、リソースが格納される１つ又はそれ以上のサーバ／ＵＥの各々にアドレス指定されたＳＩＰ ＩＮＶＩＴＥリクエストをＩＭＳコア４９ａに送る。リソースが格納されるサーバ／ＵＥのアドレスは、図３で既に説明されたようなサーチオペレーションにおいて学習されている。明確にするために、図４は、リソースが１つの遠隔の位置、具体的には第２のＵＥ３０ｃにだけ格納されるケースを示している。ＳＩＰ ＩＮＶＩＴＥリクエストは、リソース転送オペレーションのリクエストを示すＳＤＰオファーを含む。ＳＤＰオファーはまた、特にファイル転送（例えばリクエストされたファイルのハッシュ）の場合に取り出されることになるリソースを示すのに十分なメタデータを含む。

ステップ１８２において、ＳＩＰ ＩＮＶＩＴＥリクエストは、リソースが格納される第２のＵＥ３０ｃのアドレスに向けてＩＭＳコア内にルーティングされる。ＳＩＰ ＩＮＶＩＴＥリクエスト１８２は、ＵＥ３０ａにサービスするＳＩＰ Ｐ２Ｐ ＡＳ５１ｂにも、第２のＵＥ３０ｃにサービスするＳＩＰ Ｐ２Ｐ ＡＳ５１ａのいずれにもルーティングされる必要がない。しかしながら、オペレータのポリシーは、例えば、適切なアカウンティング又は認可を可能にするためＳＩＰ Ｐ２Ｐ ＡＳ５１ｂ又は５１ａのいずれかを横断する必要がある。或いは、例えば、ＳＩＰ Ｐ２Ｐ ＡＳは、パブリックからプライベートＩＰアドレスへのアドレス変換機能を提供することができる。簡単にするために、図４は、ＳＩＰ ＩＮＶＩＴＥリクエスト１８２がＳＩＰ Ｐ２Ｐ ＡＳ５１ａ又は５１ｂのいずれも横断しない場合の本発明の実施形態を示している。

ステップ１８３において、ＳＩＰ ＩＮＶＩＴＥリクエストは、ＩＭＳコア４９ａから遠隔ＵＥ３０ｃの第２のＩＭＳコアにルーティングされる。

ステップ１８４において、遠隔ＵＥ３０ｃは、ＩＮＶＩＴＥリクエストを受け取り、リクエストをサービスできるかどうかを判断する。例えば、ＵＥの処理能力、利用可能な帯域幅、転送オペレーションの最大数、その他は、ＵＥがこの時点でリクエストをサービスできないと判断することができる。遠隔ＵＥ３０ｃがリクエストを直ちにサービスできない場合には、ステップ１８５から１８７が実施され、そうでない場合、オペレーションはステップ１８８に進み、リクエストをサービスする。

遠隔ＵＥ３０ｃがリソース不足によりリクエストをサービスできない場合、遠隔ＵＥ３０ｃは、ＳＩＰ「１８２待ち行列」応答をリクストしているＵＥ３０ａに送信し、リクエストがローカルキューの待ち行列に入れられる。ＳＩＰ「１８２待ち行列」応答が、ステップ１８５で遠隔ＵＥ３０ｃから遠隔ＩＭＳコア４９ｃに、ステップ１８６で遠隔ＩＭＳコア４９ｃからリクエストしているＩＭＳコア４９ａに、ステップ１８７でリクエストしているＩＭＳコア４９ａからリクエストしているＵＥ３０ａに送信される。

ステップ１８８において、遠隔ＵＥ３０ｃは、リソースを求める受信リクエストをサービスすることができると判断する。次いで、遠隔ＵＥ３０は、ＳＤＰ応答を含むリクエストしているＵＥ３０ａにアドレス指定されたＳＩＰ「２００ ＯＫ」応答メッセージを送信する。本発明の幾つかの実施形態において、ＳＤＰはまた、ファイル関連情報を含む。ＳＩＰ「２００ ＯＫ」応答は、ステップ１８９で遠隔ＵＥ３０ｃから遠隔ＩＭＳコア４９ｃへ、ステップ１９０で遠隔ＩＭＳコア４９ｃからリクエストしているＩＭＳコア４９ａは、ステップ１９１でリクエストしているＩＭＳコア４９ａからリクエストしているＵＥ３０ａへ送信される。

ステップ１９５において、ＳＩＰ Ｐ２Ｐ ＡＳの支援を受けることなく遠隔ＵＥ３０ｃからリクエストしているＵＥ３０ａにリソースを転送するメディアセッションが確立される。メディアセッションは、遠隔ＵＥからリクエストしているＵＥにデータを転送するのに既知の転送プロトコルのいずれかを使用することができるが、１つの好ましい転送プロトコルは、メッセージセッションリレープロトコルである（ＭＳＲＰ、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ− ｍｅｓｓａｇｅ−ｓｅｓｓｉｏｎｓ、策定中）。本発明の実施形態において使用できる他の転送プロトコルには、限定ではないが、ファイル転送プロトコル（ＦＴＰ、ＲＦＣ９５９）、ハイパーテキスト転送プロトコル（ＨＴＴＰ、ＲＦＣ２６１６）、一方向転送のファイル配信（ＦＬＵＴＥ、ＲＦＣ３９２６）がある。

ステップ１９６から２０１では、転送セッションの終わりは、リクエストしているＵＥ３０ａにより信号が送られ確認応答される。メタデータセッションが終わると、遠隔ＵＥ３０ｃは、リクエストしているＵＥ３０ａにアドレス指定されたＳＩＰ ＢＹＥリクエストを送信し、セッションを閉じる。ＳＩＰ ＢＹＥリクエストは、ステップ１９６で遠隔ＵＥ３０ｃから遠隔ＩＭＳコア４９ｃに、ステップ１９７で遠隔ＩＭＳコア４９ｃからリクエストしているＩＭＳコア４９ａに、ステップ１９８でリクエストしているＩＳＭコア４９ａからリクエストしているＵＥ３０ａに送信される。次いで、リクエストしているＵＥ３０ａは、遠隔ＵＥ３０ｃにアドレス指定されたＳＩＰ「２００ ＯＫ」応答を送信することによってリクエストに確認応答する。ＳＩＰ「２００ ＯＫ」応答は、ステップ１９９でリクエストしているＵＥ３０ａからリクエストしているＩＭＳコア４９ａに、ステップ２００でリクエストしているＩＭＳコア４９ａから遠隔ＩＭＳコア４９ｃへ、ステップ２０１で遠隔ＩＭＳコア４９ｃから遠隔ＵＥ３０ｃへ送信される。

本発明の上記の実施形態は、上述の問題を解決する。リソースに関連する情報の配信者としてフロントエンドＰ２Ｐノードを設ける際に、リソースを含むＵＥ又はサーバへの信号伝達が低減され、従って、遠隔ＵＥの断続的な接続性の問題が低減される。関連する情報は、リソースがネットワークと接触した時点で存在するかどうかに関わらず利用可能である。

更に、ＳＩＰ Ｐ２ＰＡＳ自体がインターネットから到達可能なパブリックＩＰアドレスを備えている場合、ネットワークアドレス変換されるＵＥを有する問題が低減される。

また、本発明の実施形態としてのＰ２Ｐネットワークは、ＳＩＰ Ｐ２Ｐ ＡＳを使用してオーバーレイネットワークを提供することにより、既存のＩＭＳネットワークに対して最小限の影響しかもたらさない。従って、ネットワークのオペレータは、既存のネットワークノードを追加のルーティングフィルタと共に用いて、上述のＳＩＰリクエスト及び応答をルーティングすることができる。オペレータはまた、ＳＩＰ Ｐ２Ｐサーバを使用するためにチャージシステムを実装することができる。

上述の本発明の実施形態は、家族間での写真共有のようなリソースを供給するのにユーザが用いることができる。このような実施形態において、特定のメンバー（ファミリーの）及びスーパーノードとして動作する関連するＳＩＰ Ｐ２Ｐ ＡＳを含む閉じたＳＩＰ Ｐ２Ｐオーバーレイネットワークが作成される。メンバーは、例えばＳＩＰ Ｐ２Ｐオーバーレイネットワークに公開されるＵＥを用いて画像を取得することができる。次いで、公開された画像は、家族の他のメンバーにより直ぐにダウンロードされて、他のメンバーのＵＥで閲覧することができる。

閉じたオーバーレイネットワークの他の実施例は、特定の不動産業者又はブローカーにより取得される販売又は賃貸用の不動産の画像及びビデオクリップの公開及び表示に属する。不動産業者は、閉じたオーバーレイネットワークに画像又はビデオクリップを公開することができ、公開されたリソースをサーチするのが許可された可能性のあるクライアントがサーチ及びフェッチすることができる。

使用中のオーバーレイネットワークの別の実施例は、スポーツイベント中に、例えばフットボール中の場合、すなわちイベントを見ている公衆のメンバーにより画像／ビデオクリップを作成できる場合である。これらのクリップは、オーバーレイネットワークに公開され、イベントを見ている公衆の他のメンバーに利用可能にされ、他のメンバーが別の地点で見ることができるようにする。

上記の図１〜４は、各ＵＥが単一のＳＩＰ Ｐ２Ｐ ＡＳに接続するのを示している。しかしながら本発明の他の実施形態では、各ＵＥは、負荷バランシング及び冗長性を利用するために１つよりも多いＳＩＰ Ｐ２Ｐ ＡＳに接続することができる。ＵＥが１つよりも多いＰ２Ｐネットワーク（例えば、ファミリー画像ファイル共有サービス及びび不動産業者ネットワーク）に接続することができる他の場合において、ここでＵＥは１つよりも多いＳＩＰ Ｐ２Ｐ ＡＳに接続され、各ＳＩＰ Ｐ２Ｐ ＡＳは異なるＰ２Ｐオーバーレイネットワークの一部である。

本出願人は、本明細書で説明された特徴又は特徴の組み合わせが本明細書で開示されたあらゆる問題を解決するかどうかに関わらず、且つ請求項の範囲を限定することなく当業者の一般的な知識に照らしてこうした特徴又は組み合わせが本明細書に基づいて全体として実施できる範囲において、こうした各個々の特徴を単独で、及び２つ又はそれ以上のこうした特徴をあらゆる組み合わせで本明細書によって開示した。本出願人は、本発明の態様がこうしたあらゆる個々の特徴又は特徴の組み合わせからなるものとすることができることを指摘する。以上の説明に鑑み、当業者であれば本発明の範囲内で種々の修正を行い得ることは明らかであろう。

本発明の実施形態を特徴として備える通信システムの概略図である。 本発明の実施形態を用いてリソース情報をユーザが公開することができる方法の概略図である。 本発明の実施形態を用いてリソース情報をユーザがサーチすることができる方法の概略図である。 本発明の実施形態を用いてリソース情報をユーザがフェッチすることができる方法の概略図である。

符号の説明

１、２、３ ドメイン
３０ａ、３０ｂ、３０ｃ モバイルユーザ装置
３１ａ、３１ｂ、３１ｃ 基地局
３２ａ、３２ｉ ＧＰＲＳバックボーンネットワーク
３３ａ サービングＧＰＲＳノード（ＳＧＳＮ）
３４ａ ゲートウェイ側ＧＰＲＳノード（ＧＧＳＮ）
４０ 非ＩＭＳ Ｐ２Ｐネットワーク
４９ａ、４９ｃ 呼セッション制御機能（ＣＳＣＦ）部
５１ａ、５１ｂ、５１ｃ、５１ｄ ＳＩＰ Ｐ２Ｐアプリケーションサーバ
５３ オペレータ間ピュアＰ２Ｐオーバーレイネットワーク

Claims (57)

1. 通信ネットワークにおいてピアツーピアサービスを提供するためのノードであって、前記ネットワークが少なくとも１つの別のノードを含み、前記ノードが、
   少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成された入力と、
   前記少なくとも１つのＳＩＰピアツーピアリクエストを前記ノードから前記少なくとも１つの別のノードの少なくとも１つに送信するよう構成された出力と、
   を備え、
   前記入力が、前記少なくとも１つの別のノードから少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成され、前記出力が、前記ＳＩＰピアツーピア応答を送信するように構成されている、
   ことを特徴とするノード。
2. 前記ノード入力が、アクセスネットワークを介してユーザ装置（ＵＥ）から前記少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている、
   請求項１に記載のノード。
3. 前記ノード出力が、前記アクセスネットワークを介して前記ユーザ装置（ＵＥ）に前記ＳＩＰピアツーピア応答を送信するよう構成されている、
   請求項２に記載のノード。
4. 前記ユーザ装置がＰ２Ｐ２次ノードである、
   請求項２又は３に記載のノード。
5. 前記ノード入力が、前記別のノードの少なくとも別の１つから前記少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている、
   請求項１から４に記載のノード。
6. 前記ノード出力が、前記別のノードの少なくとも別の１つに前記ＳＩＰピアツーピア応答を送信するように構成されている、
   請求項５に記載のノード。
7. 前記ノードがＰ２Ｐ一次ノードである、
   請求項１から６に記載のノード。
8. 前記ピアツーピアリクエストがピアツーピアリソース公開を含む、
   請求項１から７に記載のノード。
9. 前記少なくとも１つのピアツーピアリソース公開リクエストが第１の情報要素を含む、
   請求項８に記載のノード。
10. 前記ノードがメモリを備え、情報記憶装置内に前記第１の情報要素を格納するように更に構成されている、
    請求項９に記載のノード。
11. 前記第１の情報要素が、
    リソース名、
    ファイル名、
    リソースタイプ、
    リソースサイズ、
    前記リソースを表すアイコン、
    前記リソースの簡単な説明、
    前記リソースのハッシュ、
    前記リソースのアドレスのＳＩＰ ＵＲＩ、
    前記リソースの端末アドレス、
    前記リソースのタイムスタンプ、
    ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、
    前記リソースに関連するアクセス権、
    及び前記リソースに関連するメタデータ、
    のうちの少なくとも１つである、
    請求項９又は１０に記載のノード。
12. 前記少なくとも１つのピアツーピアリソース公開リクエストがＳＩＰ ＰＵＢＬＩＳＨリクエストである、
    請求項８から１１に記載のノード。
13. 前記ＳＩＰピアツーピアリクエストが、リクエストされたリソース要素を有するサーチリクエストを含む、
    請求項１から１２に記載のノード。
14. 前記サーチリクエストがＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストである、
    請求項１３に記載のノード。
15. メモリを更に備え、前記ノードが、前記リクエストされたリソース要素と合致するリクエストされたリソースを含む少なくとも１つのノードのアドレスを求めて前記メモリをサーチするよう構成されている、
    請求項１３又は１４に記載のノード。
16. 前記ＳＩＰピアツーピア応答が、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むネットワークノードのアドレスを有する、
    請求項１３から１５に記載のノード。
17. 前記ＳＩＰピアツーピア応答がＳＩＰ ＮＯＴＩＦＹメッセージを含む、
    請求項１６に記載のノード。
18. 前記アドレスが、
    ＳＩＰ ＵＲＩ、
    ネットワークノードアドレス、
    端末アドレス、
    及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、
    のうちの少なくとも１つを含む、
    請求項１５から１７に記載のノード。
19. 前記応答メッセージが、リクエストされたリソース要素を有するリソースを含み、前記リソース要素が、
    リソース名、
    ファイル名、
    リソースタイプ、
    リソースサイズ、
    前記リソースを表すアイコン、
    前記リソースの簡単な説明、
    前記リソースのハッシュ、
    前記リソースに関連するアクセス権、
    及び前記リソースに関連するメタデータ、
    のうちの少なくとも１つを含む、
    請求項１３から１８に記載のノード。
20. 前記通信ネットワークがＩＰマルチメディアサブシステムを含む、
    請求項１から１９に記載のノード。
21. 前記ノードが、ＳＩＰピアツーピアアプリケーションサーバである、
    請求項１から２０に記載のノード。
22. 請求項１から２１に記載の少なくとも１つのノードを備えるオーバーレイピアツーピアネットワーク。
23. 通信ネットワークにおいてピアツーピアサービスを提供するためのノードと通信するよう構成されたユーザ装置であって、前記ノードが少なくとも１つの別のノードを含むネットワークにおいて使用中のノードであり、前記ユーザ装置が、
    少なくとも１つのＳＩＰピアツーピアリクエストをアクセスネットワークを介して前記ノードに送信するよう構成された出力と、
    少なくとも１つのＳＩＰピアツーピア応答を前記アクセスネットワークを介して前記ノードから受け取るように構成された入力と、
    を備える、
    ことを特徴とするユーザ装置。
24. 前記少なくとも１つのＳＩＰピアツーピアリクエストがピアツーピアリソース公開である、
    請求項２３に記載のユーザ装置。
25. 前記少なくとも１つのピアツーピアリソース公開リクエストが第１の情報要素を含む、
    請求項２４に記載のユーザ装置。
26. 前記第１の情報要素が、
    リソース名、
    ファイル名、
    リソースタイプ、
    リソースサイズ、
    前記リソースを表すアイコン、
    前記リソースの短い説明、
    前記リソースのハッシュ、
    前記リソースのアドレスのＳＩＰ ＵＲＩ、
    前記リソースの端末アドレス、
    前記リソースのタイムスタンプ、
    ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、
    前記リソースに関連するアクセス権、
    及び前記リソースに関連するメタデータ、
    のうちの少なくとも１つである、
    請求項２５に記載のユーザ装置。
27. 前記少なくとも１つのピアツーピアリソース公開リクエストがＳＩＰ ＰＵＢＬＩＳＨリクエストである、
    請求項２４から２６に記載のユーザ装置。
28. 前記ＳＩＰピアツーピアリクエストが、リクエストされたリソース要素を有するサーチリクエストを含む、
    請求項２３から２７に記載のユーザ装置。
29. 前記サーチリクエストがＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストである、
    請求項２８に記載のユーザ装置。
30. 前記ＳＩＰピアツーピア応答が、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードのアドレスを有する、
    請求項２３から２９に記載のユーザ装置。
31. 前記ＳＩＰピアツーピア応答がＳＩＰ ＮＯＴＩＦＹメッセージを含む、
    請求項３０に記載のユーザ装置。
32. 前記アドレスが、
    ＳＩＰ ＵＲＩ、
    ネットワークノードアドレス、
    端末アドレス、
    及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、
    のうちの少なくとも１つを含む、
    請求項３０に記載のユーザ装置。
33. 前記応答メッセージが、リクエストされたリソース要素を有するリソースを含み、前記リソース要素が、
    リソース名、
    ファイル名、
    リソースタイプ、
    リソースサイズ、
    前記リソースを表すアイコン、
    前記リソースの簡単な説明、
    前記リソースのハッシュ、
    前記リソースに関連するアクセス権、
    及び前記リソースに関連するメタデータ、
    のうちの少なくとも１つを含む、
    請求項３０から３２に記載のユーザ装置。
34. 前記入力が、前記アクセスネットワークを介して前記ノードから少なくとも１つの別のＳＩＰピアツーピア応答を受け取るように構成されている、
    請求項３０から３２に記載のユーザ装置。
35. 前記少なくとも１つの別のＳＩＰピアツーピア応答が、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含む別のノードのアドレスを有する、
    請求項３４に記載のユーザ装置。
36. 前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードの
    アドレスを表示するように構成されている、
    請求項３０から３５に記載のユーザ装置。
37. 前記ユーザ装置が、前記リクエストされたリソースにアクセスするため前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードと通信するよう構成されている、
    請求項３０から３６に記載のユーザ装置。
38. 前記ユーザ装置が、ＳＩＰリクエストを送信することによって、前記リクエストされたリソースにアクセスするため前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含む前記ノードと通信を開始するよう構成されている、
    請求項３７に記載のユーザ装置。
39. 請求項１から１１に記載の少なくとも１つのノードと、
    少なくとも１つのユーザ装置と、
    前記少なくとも１つのユーザ装置から送信されたＳＩＰピアツーピアリクエストを受け取るように構成されたアクセスネットワークと、
    少なくとも前記アクセスネットワーク及び他のＩＰマルチメディアネットワークから前記ＳＩＰピアツーピアリクエストを受け取るように構成されたＩＰマルチメディアネットワークコアと、
    を備え、
    前記ノードが、ＩＰマルチメディアネットワークコアから前記ＳＩＰピアツーピアリクエストを受け取るように構成されている、
    ことを特徴とする通信ネットワーク。
40. 前記ＩＰマルチメディアネットワークが、前記少なくとも１つのユーザ装置に対して前記ノードから送信されたＳＩＰピアツーピア応答を受け取るよう構成され、更に前記ＳＩＰピアツーピア応答を前記アクセスネットワークに転送するよう構成されており、前記アクセスネットワークが、前記ＳＩＰピアツーピア応答を前記少なくとも１つのユーザ装置に転送するよう構成されている、
    請求項３９に記載の通信ネットワーク。
41. 通信ネットワーク内でノード間のＳＩＰピアツーピアネットワークを動作させる方法であって、
    少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、
    前記少なくとも１つのＳＩＰピアツーピアリクエストを前記ノードから少なくとも１つの他のノードに送信する段階と、
    前記少なくとも１つの他のノードからのＳＩＰピアツーピア応答メッセージを前記ノードで受け取る段階と、
    前記ＳＩＰピアツーピア応答メッセージを前記ノードからモバイルユーザ装置に送信する段階と、
    を含む方法。
42. 前記少なくとも１つのＳＩＰピアツーピアリクエストが、アクセスネットワークを介してユーザ装置（ＵＥ）から受け取られる、
    請求項４１に記載の方法。
43. 前記ＳＩＰピアツーピア応答が、前記アクセスネットワークを介して前記ユーザ装置（ＵＥ）に送信される、
    請求項４２に記載の方法。
44. 前記少なくとも１つのＳＩＰピアツーピアリクエストが少なくとも１つの別のノードから受け取られる、
    請求項４１に記載の方法。
45. 前記ＳＩＰピアツーピア応答が前記少なくとも１つの別のノードに送信される、
    請求項４４に記載の方法。
46. 前記ＳＩＰピアツーピアリクエストが、第１の情報要素を含む公開リクエストである、
    請求項４１から４５に記載の方法。
47. 前記ノードの情報記憶装置内に前記第１の情報要素を格納する段階を更に含む、
    請求項４６に記載の方法。
48. 前記第１の情報要素が、
    リソース名、
    ファイル名、
    リソースタイプ、
    リソースサイズ、
    前記リソースを表すアイコン、
    前記リソースの短い説明、
    前記リソースのハッシュ、
    前記リソースのアドレスのＳＩＰ ＵＲＩ、
    前記リソースの端末アドレス、
    前記リソースのタイムスタンプ、
    ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、
    前記リソースに関連するアクセス権、
    及び前記リソースに関連するメタデータ、
    のうちの少なくとも１つである、
    請求項４６から４７に記載の方法。
49. 前記公開リクエストが、ＳＩＰ ＰＵＢＬＩＳＨリクエストである、
    請求項４１から４８に記載の方法。
50. 前記ピアツーピアリクエストが、サーチ情報要素を有するサーチリクエストである、
    請求項４１から４９に記載の方法。
51. 前記サーチリクエストがＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストである、
    請求項５０に記載の方法。
52. サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを求めて情報記憶装置内をサーチする段階を更に含む、
    請求項４１に記載の方法。
53. 前記応答メッセージが、前記サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを有する、
    請求項５２に記載の方法。
54. 前記応答メッセージがＳＩＰ ＮＯＴＩＦＹリクエストである、
    請求項５２に記載の方法。
55. 前記ノードのアドレスが、
    ＳＩＰ ＵＲＩ、
    ネットワークノードアドレス、
    端末アドレス、
    及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、
    のうちの少なくとも１つを含む、
    請求項５４に記載の方法。
56. 前記応答メッセージが、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含み、前記サーチリクエストサーチ情報要素が、
    リソース名、
    ファイル名、
    リソースタイプ、
    リソースサイズ、
    前記リソースを表すアイコン、
    前記リソースの簡単な説明、
    前記リソースのハッシュ、
    前記リソースに関連するアクセス権、
    及び前記リソースに関連するメタデータ、
    のうちの少なくとも１つを含む、
    請求項５３から５５に記載の方法。
57. 無線通信ネットワーク内でノード間のピアツーピアネットワークを動作させるためコンピュータ上で動作するよう構成されたコンピュータプログラムであって、
    少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、
    前記少なくとも１つのＳＩＰピアツーピアリクエストを前記ノードから少なくとも１つの他のノードに送信する段階と、
    前記少なくとも１つの他のノードからの応答メッセージを前記ノードで受け取る段階と、
    前記応答メッセージを前記ノードから送信する段階と、
    を含むコンピュータプログラム。

Images