(57)【要約】【課題】無線通信ネットワーク内のピアツーピアネットワークサービスを提供するためのノードを提供する。【解決手段】通信ネットワークにおいてピアツーピアサービスを提供するためのノードであって、ネットワークが少なくとも１つの別のノードを含み、ノードが、少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成された入力と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから少なくとも１つの別のノードの少なくとも１つに送信するよう構成された出力と、を備える。入力が、少なくとも１つの別のノードから少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成され、出力が、ＳＩＰピアツーピア応答を送信するように構成されている。【選択図】図１
2009533925.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークにおいてピアツーピアサービスを提供するためのノードであって、前記ネットワークが少なくとも１つの別のノードを含み、前記ノードが、
少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成された入力と、
前記少なくとも１つのＳＩＰピアツーピアリクエストを前記ノードから前記少なくとも１つの別のノードの少なくとも１つに送信するよう構成された出力と、
を備え、
前記入力が、前記少なくとも１つの別のノードから少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成され、前記出力が、前記ＳＩＰピアツーピア応答を送信するように構成されている、
ことを特徴とするノード。
【請求項２】
前記ノード入力が、アクセスネットワークを介してユーザ装置（ＵＥ）から前記少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている、
請求項１に記載のノード。
【請求項３】
前記ノード出力が、前記アクセスネットワークを介して前記ユーザ装置（ＵＥ）に前記ＳＩＰピアツーピア応答を送信するよう構成されている、
請求項２に記載のノード。
【請求項４】
前記ユーザ装置がＰ２Ｐ２次ノードである、
請求項２又は３に記載のノード。
【請求項５】
前記ノード入力が、前記別のノードの少なくとも別の１つから前記少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている、
請求項１から４に記載のノード。
【請求項６】
前記ノード出力が、前記別のノードの少なくとも別の１つに前記ＳＩＰピアツーピア応答を送信するように構成されている、
請求項５に記載のノード。
【請求項７】
前記ノードがＰ２Ｐ一次ノードである、
請求項１から６に記載のノード。
【請求項８】
前記ピアツーピアリクエストがピアツーピアリソース公開を含む、
請求項１から７に記載のノード。
【請求項９】
前記少なくとも１つのピアツーピアリソース公開リクエストが第１の情報要素を含む、
請求項８に記載のノード。
【請求項１０】
前記ノードがメモリを備え、情報記憶装置内に前記第１の情報要素を格納するように更に構成されている、
請求項９に記載のノード。
【請求項１１】
前記第１の情報要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの簡単な説明、
前記リソースのハッシュ、
前記リソースのアドレスのＳＩＰ  ＵＲＩ、
前記リソースの端末アドレス、
前記リソースのタイムスタンプ、
ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つである、
請求項９又は１０に記載のノード。
【請求項１２】
前記少なくとも１つのピアツーピアリソース公開リクエストがＳＩＰ  ＰＵＢＬＩＳＨリクエストである、
請求項８から１１に記載のノード。
【請求項１３】
前記ＳＩＰピアツーピアリクエストが、リクエストされたリソース要素を有するサーチリクエストを含む、
請求項１から１２に記載のノード。
【請求項１４】
前記サーチリクエストがＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストである、
請求項１３に記載のノード。
【請求項１５】
メモリを更に備え、前記ノードが、前記リクエストされたリソース要素と合致するリクエストされたリソースを含む少なくとも１つのノードのアドレスを求めて前記メモリをサーチするよう構成されている、
請求項１３又は１４に記載のノード。
【請求項１６】
前記ＳＩＰピアツーピア応答が、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むネットワークノードのアドレスを有する、
請求項１３から１５に記載のノード。
【請求項１７】
前記ＳＩＰピアツーピア応答がＳＩＰ  ＮＯＴＩＦＹメッセージを含む、
請求項１６に記載のノード。
【請求項１８】
前記アドレスが、
ＳＩＰ  ＵＲＩ、
ネットワークノードアドレス、
端末アドレス、
及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、
のうちの少なくとも１つを含む、
請求項１５から１７に記載のノード。
【請求項１９】
前記応答メッセージが、リクエストされたリソース要素を有するリソースを含み、前記リソース要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの簡単な説明、
前記リソースのハッシュ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つを含む、
請求項１３から１８に記載のノード。
【請求項２０】
前記通信ネットワークがＩＰマルチメディアサブシステムを含む、
請求項１から１９に記載のノード。
【請求項２１】
前記ノードが、ＳＩＰピアツーピアアプリケーションサーバである、
請求項１から２０に記載のノード。
【請求項２２】
請求項１から２１に記載の少なくとも１つのノードを備えるオーバーレイピアツーピアネットワーク。
【請求項２３】
通信ネットワークにおいてピアツーピアサービスを提供するためのノードと通信するよう構成されたユーザ装置であって、前記ノードが少なくとも１つの別のノードを含むネットワークにおいて使用中のノードであり、前記ユーザ装置が、
少なくとも１つのＳＩＰピアツーピアリクエストをアクセスネットワークを介して前記ノードに送信するよう構成された出力と、
少なくとも１つのＳＩＰピアツーピア応答を前記アクセスネットワークを介して前記ノードから受け取るように構成された入力と、
を備える、
ことを特徴とするユーザ装置。
【請求項２４】
前記少なくとも１つのＳＩＰピアツーピアリクエストがピアツーピアリソース公開である、
請求項２３に記載のユーザ装置。
【請求項２５】
前記少なくとも１つのピアツーピアリソース公開リクエストが第１の情報要素を含む、
請求項２４に記載のユーザ装置。
【請求項２６】
前記第１の情報要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの短い説明、
前記リソースのハッシュ、
前記リソースのアドレスのＳＩＰ  ＵＲＩ、
前記リソースの端末アドレス、
前記リソースのタイムスタンプ、
ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つである、
請求項２５に記載のユーザ装置。
【請求項２７】
前記少なくとも１つのピアツーピアリソース公開リクエストがＳＩＰ  ＰＵＢＬＩＳＨリクエストである、
請求項２４から２６に記載のユーザ装置。
【請求項２８】
前記ＳＩＰピアツーピアリクエストが、リクエストされたリソース要素を有するサーチリクエストを含む、
請求項２３から２７に記載のユーザ装置。
【請求項２９】
前記サーチリクエストがＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストである、
請求項２８に記載のユーザ装置。
【請求項３０】
前記ＳＩＰピアツーピア応答が、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードのアドレスを有する、
請求項２３から２９に記載のユーザ装置。
【請求項３１】
前記ＳＩＰピアツーピア応答がＳＩＰ  ＮＯＴＩＦＹメッセージを含む、
請求項３０に記載のユーザ装置。
【請求項３２】
前記アドレスが、
ＳＩＰ  ＵＲＩ、
ネットワークノードアドレス、
端末アドレス、
及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、
のうちの少なくとも１つを含む、
請求項３０に記載のユーザ装置。
【請求項３３】
前記応答メッセージが、リクエストされたリソース要素を有するリソースを含み、前記リソース要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの簡単な説明、
前記リソースのハッシュ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つを含む、
請求項３０から３２に記載のユーザ装置。
【請求項３４】
前記入力が、前記アクセスネットワークを介して前記ノードから少なくとも１つの別のＳＩＰピアツーピア応答を受け取るように構成されている、
請求項３０から３２に記載のユーザ装置。
【請求項３５】
前記少なくとも１つの別のＳＩＰピアツーピア応答が、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含む別のノードのアドレスを有する、
請求項３４に記載のユーザ装置。
【請求項３６】
前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードの
アドレスを表示するように構成されている、
請求項３０から３５に記載のユーザ装置。
【請求項３７】
前記ユーザ装置が、前記リクエストされたリソースにアクセスするため前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードと通信するよう構成されている、
請求項３０から３６に記載のユーザ装置。
【請求項３８】
前記ユーザ装置が、ＳＩＰリクエストを送信することによって、前記リクエストされたリソースにアクセスするため前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含む前記ノードと通信を開始するよう構成されている、
請求項３７に記載のユーザ装置。
【請求項３９】
請求項１から１１に記載の少なくとも１つのノードと、
少なくとも１つのユーザ装置と、
前記少なくとも１つのユーザ装置から送信されたＳＩＰピアツーピアリクエストを受け取るように構成されたアクセスネットワークと、
少なくとも前記アクセスネットワーク及び他のＩＰマルチメディアネットワークから前記ＳＩＰピアツーピアリクエストを受け取るように構成されたＩＰマルチメディアネットワークコアと、
を備え、
前記ノードが、ＩＰマルチメディアネットワークコアから前記ＳＩＰピアツーピアリクエストを受け取るように構成されている、
ことを特徴とする通信ネットワーク。
【請求項４０】
前記ＩＰマルチメディアネットワークが、前記少なくとも１つのユーザ装置に対して前記ノードから送信されたＳＩＰピアツーピア応答を受け取るよう構成され、更に前記ＳＩＰピアツーピア応答を前記アクセスネットワークに転送するよう構成されており、前記アクセスネットワークが、前記ＳＩＰピアツーピア応答を前記少なくとも１つのユーザ装置に転送するよう構成されている、
請求項３９に記載の通信ネットワーク。
【請求項４１】
通信ネットワーク内でノード間のＳＩＰピアツーピアネットワークを動作させる方法であって、
少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、
前記少なくとも１つのＳＩＰピアツーピアリクエストを前記ノードから少なくとも１つの他のノードに送信する段階と、
前記少なくとも１つの他のノードからのＳＩＰピアツーピア応答メッセージを前記ノードで受け取る段階と、
前記ＳＩＰピアツーピア応答メッセージを前記ノードからモバイルユーザ装置に送信する段階と、
を含む方法。
【請求項４２】
前記少なくとも１つのＳＩＰピアツーピアリクエストが、アクセスネットワークを介してユーザ装置（ＵＥ）から受け取られる、
請求項４１に記載の方法。
【請求項４３】
前記ＳＩＰピアツーピア応答が、前記アクセスネットワークを介して前記ユーザ装置（ＵＥ）に送信される、
請求項４２に記載の方法。
【請求項４４】
前記少なくとも１つのＳＩＰピアツーピアリクエストが少なくとも１つの別のノードから受け取られる、
請求項４１に記載の方法。
【請求項４５】
前記ＳＩＰピアツーピア応答が前記少なくとも１つの別のノードに送信される、
請求項４４に記載の方法。
【請求項４６】
前記ＳＩＰピアツーピアリクエストが、第１の情報要素を含む公開リクエストである、
請求項４１から４５に記載の方法。
【請求項４７】
前記ノードの情報記憶装置内に前記第１の情報要素を格納する段階を更に含む、
請求項４６に記載の方法。
【請求項４８】
前記第１の情報要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの短い説明、
前記リソースのハッシュ、
前記リソースのアドレスのＳＩＰ  ＵＲＩ、
前記リソースの端末アドレス、
前記リソースのタイムスタンプ、
ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つである、
請求項４６から４７に記載の方法。
【請求項４９】
前記公開リクエストが、ＳＩＰ  ＰＵＢＬＩＳＨリクエストである、
請求項４１から４８に記載の方法。
【請求項５０】
前記ピアツーピアリクエストが、サーチ情報要素を有するサーチリクエストである、
請求項４１から４９に記載の方法。
【請求項５１】
前記サーチリクエストがＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストである、
請求項５０に記載の方法。
【請求項５２】
サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを求めて情報記憶装置内をサーチする段階を更に含む、
請求項４１に記載の方法。
【請求項５３】
前記応答メッセージが、前記サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを有する、
請求項５２に記載の方法。
【請求項５４】
前記応答メッセージがＳＩＰ  ＮＯＴＩＦＹリクエストである、
請求項５２に記載の方法。
【請求項５５】
前記ノードのアドレスが、
ＳＩＰ  ＵＲＩ、
ネットワークノードアドレス、
端末アドレス、
及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、
のうちの少なくとも１つを含む、
請求項５４に記載の方法。
【請求項５６】
前記応答メッセージが、前記サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含み、前記サーチリクエストサーチ情報要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの簡単な説明、
前記リソースのハッシュ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つを含む、
請求項５３から５５に記載の方法。
【請求項５７】
無線通信ネットワーク内でノード間のピアツーピアネットワークを動作させるためコンピュータ上で動作するよう構成されたコンピュータプログラムであって、
少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、
前記少なくとも１つのＳＩＰピアツーピアリクエストを前記ノードから少なくとも１つの他のノードに送信する段階と、
前記少なくとも１つの他のノードからの応答メッセージを前記ノードで受け取る段階と、
前記応答メッセージを前記ノードから送信する段階と、
を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ノードに関し、より具体的には、限定ではないが、無線通信ネットワーク内のピアツーピアネットワークサービスを提供するためのノードに関する。
【背景技術】
【０００２】
通信システムは、ユーザ装置及び／又は通信システムに関連するノードなど２つ又はそれ以上のエンティティ間の通信セッションを可能にする機構とみなすことができる。通信は、例えば、音声、データ、マルチメディアなどの通信を含むことができる。セッションは、例えば、ユーザ間の通話、多方向会議セッション、又はユーザ装置とアプリケーションサーバ（ＡＳ）（例えばサービスプロバイダサーバ）との間の通信セッションとすることができる。これらのセッションが確立されると、一般に、ユーザに種々のサービスを提供することができるようになる。
【０００３】
通信システムは通常、通信システムに関連する種々のエンティティが許可されること、及びこれをどのように達成すべきかについて記述した所与の標準規格又は仕様に従って動作する。例えば、標準規格又は仕様は、ユーザ、すなわちより正確にはユーザ装置が回路交換サービス及び／又はパケット交換サービスを備えているかどうかを定義することができる。接続に使用されるようにする通信プロトコル及び／又はパラメータも定義することができる。換言すると、通信システムを利用して通信を可能にするために、通信のベースとすることができる特定の「ルール」セットを定義する必要がある。
【０００４】
ユーザ装置に無線通信を提供する通信システムは公知である。無線通信の１つの実施例は、公衆陸上移動ネットワーク（ＰＬＭＮ）であり、別の実施例は、無線ローカルエリアネットワーク（ＷＬＡＮ）である。固定ブロードバンド接続は別のタイプの接続方式である。
【０００５】
上記及び以下で使用される用語「サービス」とは、ユーザが要求し、又は必要とし、或いは備えることができるあらゆるサービス又は商品を広範に対象とすることは理解される。この用語はまた、無料サービスの提供を対象とすることは理解される。詳細には、限定ではないが、用語「サービス」とは、インターネットプロトコルマルチメディアＩＭサービス、会議、電話通信、ゲーム、リッチコール（Ｒｉｃｈ  ｃａｌｌｓ）、その他を含むことは理解される。
【０００６】
通信システムへの加入者などのユーザに提供することができるサービスの１つの実施例は、いわゆるマルチメディアサービスである。マルチメディアサービスの提供が可能になった通信システムの一部は、インターネットプロトコル（ＩＰ）マルチメディアサービスとして知られている。ＩＰマルチメディア（ＩＭ）機能は、ＩＰマルチメディアコアネットワーク（ＣＮ）サブシステム、又は略してＩＰマルチメディアサブシステム（ＩＭＳ）を利用して提供することができる。ＩＭＳサービスは、他のサービスの中でも特に、モバイルユーザ装置間のＩＰ接続を提供することが意図されている。
【０００７】
従来のＩＰネットワーク上で動作するピアツーピア（Ｐ２Ｐ）オーバーレイネットワーク（以下ピアツーピアネットワーク又はＰ２Ｐネットワークと呼ばれる）は、リソース材料を共有するために、リソースの完全配信及びピアを支援する中央サーバの介入を最小限にするといった共通の特徴を共有する。Ｐ２Ｐネットワークは通常、ピアとして知られ、インターネットなどパケット交換ネットワークを介して接続される要素のグループ（通常はパーソナルコンピュータ）である。リソースは、どのようなものであってもよく、典型的にはファイル（画像、ビデオクリップ、又はサウンドトラックなど）又はデータストリーム（ビデオストリーム、又はデジタルエンコードされた音声データなど）であり、ピア要素において格納又は生成される。従って、Ｐ２Ｐネットワークは通常、従来のリソースネットワークとは異なり、従来のネットワークが通常リソースの提供に中央サーバを用いるのに対して、Ｐ２Ｐネットワークではネットワークの参加者が他のユーザにリソースを提供する。Ｋａｚａａ、ＷｉｎＭＸ、Ｅｍｕｌｅ、ＢｉｔＴｏｒｒｅｎｔなどの既知のＰ２Ｐネットワークは、ファイル共有ネットワークであり、一方、Ｓｋｙｐｅは電話通信Ｐ２Ｐネットワークである。
【０００８】
Ｐ２Ｐネットワークは、従来のＰＣネットワークにおいて知られているが、無線通信リンク上でのＰ２Ｐネットワークの利用には幾つかの問題がある。
【０００９】
無線通信ネットワーク上でのＰ２Ｐネットワークの利用に関する第１の問題は、ブロードバンド接続を用いる従来のユーザとは異なり、ユーザが連続してネットワークに接続されていないことである。ユーザ装置は、例えば地下鉄又は道路トンネルなど無線受信可能範囲が存在しない場所に一時的に移動する可能性がある。従って、接続が永続しない汎用パケット無線システム（ＧＰＲＳ）通信システム又は無線ローカルエリアネットワーク（ＷＬＡＮ）接続を介して接続しているＩＰユーザは、ユーザがＰ２Ｐネットワークを出入りするときにネットワーク全体においてシグナリングオーバヘッドの有意な量を生成することになる。
【００１０】
第２の問題は、無線通信ネットワーク上で接続されたユーザ装置が通常ネットワークアドレスに変換される点である。換言すると、ＧＰＲＳ又はＷＬＡＮネットワークサーバは、プライベートインターネットプロトコル（ＩＰ）アドレスをノードに与える。このプライベートＩＰアドレスは、インターネットから直接到達可能ではなく、トラフィックは、アドレス変換機構のパブリックＩＰアドレスに配向され、次いで、アドレス変換機構がユーザ装置にパケットをリダイレクトする。このことは、Ｐ２Ｐネットワークを接続するときのＵＥの可用性を制限する。例えば、ＵＥが１つのＧＰＲＳ又はＷＬＡＮネットワークから別のネットワークに移動した場合、ユーザ装置は異なるプライベートＩＰアドレスと異なるパブリックＩＰアドレスとを受け取ることになり、シグナリングオーバヘッドの変更及び増大をＰ２Ｐネットワークに通知することが必要になる。
【００１１】
ＷＯ２００５／４１５３４は、上述のような欠点を有するピュアアドホックネットワークを開示している。
【００１２】
ＵＳ２００３／１２５０６３では、一連のネットワークサーバがユーザ装置上のコンテンツをミラーリングする無線通信Ｐ２Ｐネットワークを開示している。こうしたシステムは、システムが正確に動作するために、ミラーされるコンテンツは最初にユーザ装置からアップロードされ、更にコンテンツはユーザ装置上に現在格納されているものと同じであるよう維持される必要があるので効率的ではない。従って、このシステムは、全データがミラーにアップロードされる必要があるので回線容量が非効率であり、更に、同じリソースが少なくとも２つの別の場所に存在することからリソースが非効率である。
【００１３】
ＵＳ２００４／０２４３６６５及びＵＳ２００４／０２４３５８０は、ピアツーピアサービスのためノードユーザ間の通信を可能にするモバイルユーザシステムを開示している。
【００１４】
Ｍａｔｕｓｚｅｗｓｋｉ，  Ｍ．，  Ｂｅｉｊａｒ，  Ｎ．，  Ｌｅｈｔｉｎｅｎ，  Ｊ．  ａｎｄ  Ｈｙｙｒｙｌａｉｎｅｎ，  Ｔ．  （２００６）「Ｍｏｂｉｌｅ  Ｐｅｅｒ−  ｔｏ−Ｐｅｅｒ  Ｃｏｎｔｅｎｔ  Ｓｈａｒｉｎｇ  Ａｐｐｌｉｃａｔｉｏｎ」，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＩＥＥＥ  Ｃｏｎｓｕｍｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｎｅｔｗｏｒｋｉｎｇ  Ｃｏｎｆｅｒｅｎｃｅ，  Ｊａｎｕａｒｙでは、Ｐ２Ｐコンテンツ共有サービスの実証を収めているが、こうしたシステムは、単一のスーパーピアノードを用いてモデル化されており、システムに関連するシグナリングの情報を提供するものではない。
【００１５】
Ｂｅｉｊａｒ，  Ｎ．，  Ｍａｔｕｓｚｅｗｓｋｉ，  Ｍ．，  Ｌｅｈｔｉｎｅｎ，  Ｊ．，  ａｎｄ  Ｈｙｙｒｙｌａｉｎｅｎ，  Ｔ．  （２００５）  ‘Ｍｏｂｉｌｅ  Ｐｅｅｒ−  ｔｏ−Ｐｅｅｒ  Ｃｏｎｔｅｎｔ  Ｓｈａｒｉｎｇ  Ｓｅｒｖｉｃｅｓ  ｉｎ  ＩＭＳ’，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  Ｔｈｅ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍｓ，  Ｍｏｄｅｌｉｎｇ  ａｎｄ  Ａｎａｌｙｓｉｓ  ２００５，  Ｎｏｖｅｍｂｅｒではまた、ＩＭＳネットワークに適用することができるＰ２Ｐコンテンツ共有アーキテクチャを含めている。しかしながら、ＩＭＳアーキテクチャ上でＩＭＳシグナリングを備えたＰ２Ｐネットワークを実装する方法は具体的には開示されていない。
【００１６】
【特許文献１】ＷＯ２００５／４１５３４公報
【特許文献２】ＵＳ２００３／１２５０６３公報
【特許文献３】ＵＳ２００４／０２４３６６５公報
【特許文献４】ＵＳ２００４／０２４３５８０公報
【非特許文献１】Ｍａｔｕｓｚｅｗｓｋｉ，  Ｍ．，  Ｂｅｉｊａｒ，  Ｎ．，  Ｌｅｈｔｉｎｅｎ，  Ｊ．  ａｎｄ  Ｈｙｙｒｙｌａｉｎｅｎ，  Ｔ．  （２００６）「Ｍｏｂｉｌｅ  Ｐｅｅｒ−  ｔｏ−Ｐｅｅｒ  Ｃｏｎｔｅｎｔ  Ｓｈａｒｉｎｇ  Ａｐｐｌｉｃａｔｉｏｎ」，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＩＥＥＥ  Ｃｏｎｓｕｍｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｎｅｔｗｏｒｋｉｎｇ  Ｃｏｎｆｅｒｅｎｃｅ，  Ｊａｎｕａｒｙ
【非特許文献２】Ｂｅｉｊａｒ，  Ｎ．，  Ｍａｔｕｓｚｅｗｓｋｉ，  Ｍ．，  Ｌｅｈｔｉｎｅｎ，  Ｊ．，  ａｎｄ  Ｈｙｙｒｙｌａｉｎｅｎ，  Ｔ．  （２００５）  ‘Ｍｏｂｉｌｅ  Ｐｅｅｒ−  ｔｏ−Ｐｅｅｒ  Ｃｏｎｔｅｎｔ  Ｓｈａｒｉｎｇ  Ｓｅｒｖｉｃｅｓ  ｉｎ  ＩＭＳ’，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  Ｔｈｅ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍｓ，  Ｍｏｄｅｌｉｎｇ  ａｎｄ  Ａｎａｌｙｓｉｓ  ２００５，  Ｎｏｖｅｍｂｅｒ
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明の実施形態は、上記で開示された問題に対処し、又は少なくとも部分的に軽減することを意図している。
【課題を解決するための手段】
【００１８】
本発明によれば、通信ネットワークにおいてピアツーピアサービスを提供するためのノードであって、ネットワークが少なくとも１つの別のノードを含み、ノードが、少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成された入力と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから前記少なくとも１つの別のノードの少なくとも１つに送信するよう構成された出力とを備え、入力が少なくとも１つの別のノードから少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成され、出力がＳＩＰピアツーピア応答を送信するように構成されていることを特徴とするノードが提供される。
【００１９】
ノード入力は、アクセスネットワークを介してユーザ装置（ＵＥ）から少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成することができる。
【００２０】
ノード出力は、アクセスネットワークを介してユーザ装置（ＵＥ）にＳＩＰピアツーピア応答を送信するよう構成することができる。
【００２１】
ユーザ装置は好ましくはＰ２Ｐ２次ノードである。
【００２２】
ノード入力は、好ましくは、別のノードの少なくとも別の１つから少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている。
【００２３】
ノード出力は、好ましくは、別のノードの少なくとも別の１つにＳＩＰピアツーピア応答を送信するように構成されている。
【００２４】
ノードは、好ましくはＰ２Ｐ一次ノードである。
【００２５】
ピアツーピアリクエストはピアツーピアリソース公開を含むことができる。
【００２６】
少なくとも１つのピアツーピアリソース公開リクエストが第１の情報要素を含むことができる。
【００２７】
ノードは、好ましくはメモリを備え、情報記憶装置内に第１の情報要素を格納するように更に構成することができる。
【００２８】
第１の情報要素は、好ましくは、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースのアドレスのＳＩＰ  ＵＲＩ、リソースの端末アドレス、記リソースのタイムスタンプ、ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つである。
【００２９】
少なくとも１つのピアツーピアリソース公開リクエストは、好ましくはＳＩＰ  ＰＵＢＬＩＳＨリクエストである。
【００３０】
ＳＩＰピアツーピアリクエストは、好ましくはリクエストされたリソース要素を有するサーチリクエストを含む。
【００３１】
サーチリクエストは、好ましくはＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストである。
【００３２】
ノードがメモリを更に備えることができ、該ノードは、好ましくは、リクエストされたリソース要素と合致するリクエストされたリソースを含む少なくとも１つのノードのアドレスを求めて該メモリをサーチするよう構成されている。
【００３３】
ＳＩＰピアツーピア応答は、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むネットワークノードのアドレスを有することができる。
【００３４】
ＳＩＰピアツーピア応答は、好ましくはＳＩＰ  ＮＯＴＩＦＹメッセージを含む。
【００３５】
アドレスは、ＳＩＰ  ＵＲＩ、ネットワークノードアドレス、端末アドレス、及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）のうちの少なくとも１つを含むことができる。
【００３６】
応答メッセージはリクエストされたリソース要素を有するリソースを含み、該リソース要素が、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つを含むことができる。
【００３７】
通信ネットワークは、好ましくは、ＩＰマルチメディアサブシステムを含む。
【００３８】
ノードは、好ましくはＳＩＰピアツーピアアプリケーションサーバである。
【００３９】
上述の少なくとも１つのノードは、好ましくは、オーバーレイピアツーピアネットワークに組み込まれる。
【００４０】
本発明の第２の態様によれば、通信ネットワークにおいてピアツーピアサービスを提供するためのノードと通信するよう構成されたユーザ装置であって、ノードが少なくとも１つの別のノードを含むネットワークにおいて使用中のノードであり、ユーザ装置が、少なくとも１つのＳＩＰピアツーピアリクエストをアクセスネットワークを介してノードに送信するよう構成された出力と、少なくとも１つのＳＩＰピアツーピア応答をアクセスネットワークを介してノードから受け取るように構成された入力とを備えるユーザ装置が提供される。
【００４１】
少なくとも１つのＳＩＰピアツーピアリクエストは、好ましくはピアツーピアリソース公開である。
【００４２】
少なくとも１つのピアツーピアリソース公開リクエストは好ましくは第１の情報要素を含む。
【００４３】
第１の情報要素は、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの短い説明、リソースのハッシュ、リソースのアドレスのＳＩＰ  ＵＲＩ、リソースの端末アドレス、リソースのタイムスタンプ、ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つとすることができる。
【００４４】
少なくとも１つのピアツーピアリソース公開リクエストは好ましくはＳＩＰ  ＰＵＢＬＩＳＨリクエストである。
【００４５】
ＳＩＰピアツーピアリクエストは、リクエストされたリソース要素を好ましくは有するサーチリクエストとすることができる。
【００４６】
サーチリクエストは好ましくはＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストである。
【００４７】
ＳＩＰピアツーピア応答は、好ましくは、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードのアドレスを有する。
【００４８】
ＳＩＰピアツーピア応答は好ましくはＳＩＰ  ＮＯＴＩＦＹメッセージである。
【００４９】
アドレスは、好ましくは、ＳＩＰ  ＵＲＩ、ネットワークノードアドレス、端末アドレス、及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）のうちの少なくとも１つを含む。
【００５０】
応答メッセージはリクエストされたリソース要素を有するリソースを含むことができ、リソース要素は、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つを含むことができる。
【００５１】
入力は、好ましくは、アクセスネットワークを介してノードから少なくとも１つの別のＳＩＰピアツーピア応答を受け取るように構成されている。
【００５２】
少なくとも１つの別のＳＩＰピアツーピア応答は、好ましくはサーチリクエストサーチ情報要素に合致するリクエストされたリソースを含む別のノードのアドレスを有する。
【００５３】
ユーザ装置は、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードのアドレスを表示するように構成することができる。
【００５４】
ユーザ装置は、好ましくは、リクエストされたリソースにアクセスするためサーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードと通信するよう構成される。
【００５５】
ユーザ装置は、好ましくは、ＳＩＰリクエストを送信することによって、リクエストされたリソースにアクセスするためサーチリクエストサーチ情報要素に合致するリクエストされたリソースを含むノードと通信を開始するよう構成されている。
【００５６】
本発明の第３の態様によれば、上述のような少なくとも１つのノードと、少なくとも１つのユーザ装置と、少なくとも１つのユーザ装置から送信されたＳＩＰピアツーピアリクエストを受け取るように構成されたアクセスネットワークと、少なくともアクセスネットワーク及び他のＩＰマルチメディアネットワークからＳＩＰピアツーピアリクエストを受け取るように構成されたＩＰマルチメディアネットワークコアとを備え、ノードが、ＩＰマルチメディアネットワークコアからＳＩＰピアツーピアリクエストを受け取るように構成されている通信ネットワークが提供される。
【００５７】
ＩＰマルチメディアネットワークは、好ましくは少なくとも１つのユーザ装置に対してノードから送信されたＳＩＰピアツーピア応答を受け取るよう構成され、更に好ましくは、ＳＩＰピアツーピア応答をアクセスネットワークに転送するよう構成されており、アクセスネットワークは、ＳＩＰピアツーピア応答を少なくとも１つのユーザ装置に転送するよう構成されている。
【００５８】
本発明の第４の態様によれば、通信ネットワーク内でノード間のＳＩＰピアツーピアネットワークを動作させる方法であって、少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから少なくとも１つの他のノードに送信する段階と、少なくとも１つの他のノードからのＳＩＰピアツーピア応答メッセージをノードで受け取る段階と、ＳＩＰピアツーピア応答メッセージをノードからモバイルユーザ装置に送信する段階とを含む方法が提供される。
【００５９】
ＳＩＰピアツーピアリクエストは、好ましくは第１の情報要素を含む公開リクエストである。
【００６０】
本方法は更に、ノードの情報記憶装置内に第１の情報要素を格納する段階を含むことができる。
【００６１】
第１の情報要素は、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの短い説明、リソースのハッシュ、リソースのアドレスのＳＩＰ  ＵＲＩ、リソースの端末アドレス、リソースのタイムスタンプ、ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つとすることができる。
【００６２】
公開リクエストは、好ましくはＳＩＰ  ＰＵＢＬＩＳＨリクエストである。
【００６３】
ピアツーピアリクエストは、好ましくはサーチ情報要素を有するサーチリクエストである。
【００６４】
サーチリクエストは、好ましくはＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストである。
【００６５】
本方法は更に、サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを求めて情報記憶装置内をサーチする段階を含むことができる。
【００６６】
応答メッセージは、サーチリクエストサーチ情報要素に合致するリソースを含むノードのアドレスを有することができる。
【００６７】
応答メッセージは好ましくはＳＩＰ  ＮＯＴＩＦＹリクエストである。
【００６８】
ノードのアドレスは、好ましくは、ＳＩＰ  ＵＲＩ、ネットワークノードアドレス、端末アドレス、及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）のうちの少なくとも１つを含む。
【００６９】
応答メッセージは、サーチリクエストサーチ情報要素に合致するリクエストされたリソースを含み、該サーチリクエストサーチ情報要素が、リソース名、ファイル名、リソースタイプ、リソースサイズ、リソースを表すアイコン、リソースの簡単な説明、リソースのハッシュ、リソースに関連するアクセス権、及びリソースに関連するメタデータのうちの少なくとも１つを含むことができる。
【００７０】
本発明の第５の態様によれば、無線通信ネットワーク内でノード間のピアツーピアネットワークを動作させるためコンピュータ上で動作するよう構成されたコンピュータプログラムであって、少なくとも１つのＳＩＰピアツーピアリクエストをあるノードで受け取る段階と、少なくとも１つのＳＩＰピアツーピアリクエストをノードから少なくとも１つの他のノードに送信する段階と、少なくとも１つの他のノードからの応答メッセージをノードで受け取る段階と、応答メッセージをノードから送信する段階とを含むコンピュータプログラムが提供される。
【発明を実施するための最良の形態】
【００７１】
ここで、本発明をより理解するために、例証として添付図面を参照する。
本発明の実施形態は、特に限定ではないが、ＩＭＳネットワークに関する。本発明の実施形態は他のネットワークに適用することもできる。
【００７２】
３つのオペレータによる３つの別個のドメイン１、２、３操作を示した図１を参照する。明確にするために、オペレータＡによって操作されるネットワークドメイン１だけが詳細に示されている。オペレータＡのネットワークドメイン１は、呼セッション制御機能（ＣＳＣＦ）及びＳＩＰ  Ｐ２Ｐアプリケーションサーバ（ＡＳ）などの幾つかのネットワークノードを含むＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークとして図示されている。ＩＰマルチメディア（ＩＭ）機能は、サービスを提供するための種々のエンティティを含むコアネットワーク（ＣＮ）サブシステムを利用して提供することができる。
【００７３】
基地局３１ａ、３１ｂ、３１ｃは、モバイルユーザのモバイルユーザ装置３０ａ、３０ｂ、３０ｃと信号を送受信するよう配置されている。これに対応して、モバイルユーザ装置３０ａ、３０ｂ、３０ｃの各々は、無線インタフェースを介して基地局３１ａ、３１ｂ、３１ｃと信号を送受信することができる。図１の簡略化された表現において、基地局３１ａ及び３１ｂは、第１の無線アクセスネットワークに属し、基地局３１ｃは別個の無線アクセスネットワーク（ＲＡＮ）に属する。図示の構成において、ユーザ装置３０ａ、３０ｂ、３０ｃの各々は、基地局３１ａ、３１ｂ、３１ｃにそれぞれ関連する２つのアクセスネットワークを介してＩＭＳネットワークにアクセスすることができる。明確にするために図１は２つの無線アクセスネットワークだけの基地局を示しているが、典型的な移動体通信ネットワークは通常、幾つかの無線アクセスネットワークを含む。本発明の実施形態において、固定ユーザ装置は、無線アクセスネットワークか、又は非対称型デジタル加入者回線（ＡＤＳＬ）アクセスネットワークなどの１つ又はそれ以上の他のアクセスネットワークのいずれかを介してコアネットワークに接続することができる。
【００７４】
３Ｇ無線アクセスネットワーク（ＲＡＮ）は通常、適切な無線ネットワークコントローラ（ＲＮＣ）により制御される。このコントローラは明確さを高めるために図示されていない。１つのコントローラを各基地局に割り当てることができ、又は１つのコントローラが複数の基地局を制御することもできる。コントローラが個々の基地局と、複数の基地局を制御するために無線アクセスネットワークレベルとの両方に設けられる解決策も公知である。従って、ネットワークコントローラの名称、位置、及び数はシステムに応じて変わることは理解されたい。
【００７５】
モバイルユーザ装置３０ａ、３０ｂ、３０ｃは、ネットワークに接続するためのインターネットプロトコル（ＩＰ）通信に適合されたあらゆる適切なモバイルデバイスを用いることができる。例えば、モバイルユーザ装置３０ａ、３０ｂ、３０ｃは、パーソナルコンピュータ（ＰＣ）、携帯情報端末（ＰＤＡ）、移動局（ＭＳ）などを利用してセルラーネットワークにアクセスすることができる。以下の実施例は移動局との関連において説明されている。
【００７６】
当業者は典型的なユーザ装置３０ａ、３０ｂ、３０ｃの特徴及び動作に精通している。従って、これらの機能についての詳細な説明は必要ではない。通話の発信及び受信、ネットワークとのデータの送受信、及び例えばマルチメディアコンテンツの体験などのタスクのためにユーザ装置３０ａ、３０ｂ、３０ｃを用いることができることに留意すれば十分である。ユーザ装置３０ａ、３０ｂ、３０ｃは通常、これらのタスクを完遂するためのプロセッサ及びメモリ手段を備える。ユーザ装置３０ａ、３０ｂ、３０ｃは、移動体通信ネットワークの基地局と信号を無線で送受信するためのアンテナ手段を含むことができる。ユーザ装置３０ａ、３０ｂ、３０ｃはまた、ユーザ装置３０ａ、３０ｂ、３０ｃのユーザに対して画像及び他のグラフィカル情報を表示するためのディスプレイを備えることができる。スピーカ手段も設けられる。ユーザ装置３０ａ、３０ｂ、３０ｃの動作は、制御ボタン、音声コマンドなどのような適切なユーザインタフェースを用いて制御することができる。
【００７７】
明確にするために図１には３つのユーザ装置３０ａ、３０ｂ、３０ｃだけが示されているが、同時通信において幾つかのユーザ装置３０ａ、３０ｂ、３０ｃが存在することができる。
【００７８】
コアネットワーク（ＣＮ）エンティティは通常、幾つかの無線アクセスネットワークを介した通信を可能にするため、更に単一の通信システムを１つ又はそれ以上の通信システム（他のセルラシステム及び／又は固定回線通信システムなど）とインタフェース接続するための種々の制御エンティティ及びゲートウェイを含む。図１において、サービングＧＰＲＳノード（ＳＧＳＮ）３３ａ及びゲートウェイ側ＧＰＲＳノード（ＧＧＳＮ）３４ａは、ネットワークにおいてＧＰＲＳサービスのサポートを提供するのに使用される。
【００７９】
無線アクセスネットワークコントローラは通常、限定ではないが、サービング汎用パケット無線サービスサポートノード（ＳＧＳＮ）３３ａのような適切な１つ又は複数のコアネットワークエンティティに接続される。図示していないが、各ＳＧＳＮは通常、それぞれのユーザ装置の加入に関連する情報を格納するよう構成された指定加入者データベースにアクセスする。
【００８０】
無線アクセスネットワーク内のユーザ装置３０ａ、３０ｂ、３０ｃは、無線ネットワークコントローラと通信することができる。無線アクセスネットワークコントローラは、適切なインタフェース（例えばＩｕインタフェース上）を介してサービングＧＰＲＳサポートノードと通信状態にある。
【００８１】
サービングＧＰＲＳサポートノード３３ａも同様に通常、ＧＰＲＳバックボーンネットワーク３２ａ、３２ｃを介してゲートウェイ側ＧＰＲＳサポートノード（ＧＧＳＮ）３４ａと通信する。このインタフェースは一般に交換パケットデータインタフェースである。サービングＧＰＲＳサポートノード及び／又はゲートウェイ側ＧＰＲＳサポートノードは、ネットワークにおいてＧＰＲＳサービスに対するサポートを提供するためのものである。
【００８２】
ユーザ装置３０ａ、３０ｂ、３０ｃは、ＧＰＲＳネットワークを介して、一般にＩＭＳに接続されるアプリケーションサーバに接続することができる。
【００８３】
通信システムは、サーバとして知られるネットワークエンティティにより処理されるネットワークの種々の機能を利用してユーザ装置にサービスを提供することができるように開発された。例えば、現在の第３世代（３Ｇ）無線マルチメディアネットワークアーキテクチャにおいて、幾つかの異なるサーバが異なる機能を扱うために使用される。これらは、呼セッション制御機能（ＣＳＣＦ）４９ａ、４９ｃなどの機能を含む。呼セッション制御機能は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）、インテロゲーティング呼セッション制御機能（Ｉ−ＣＳＣＦ）、及びサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）などの種々のカテゴリに分類することができる。ＩＭＳシステムを介してアプリケーションサーバにより提供されるサービスを使用したいと望むユーザは、サービング制御エンティティに登録することが必要となる場合がある。サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）は、通信システムからサービスサービスをリクエストできるようにするために、ユーザが登録される必要のあるエンティティを３ＧのＩＭＳ構成において形成することができる。ＣＳＣＦ４９ａ、４９ｃは、ＵＴＭＳシステムのＩＭＳネットワークを定義することができる。
【００８４】
異なるシステムでは同様の機能は異なる名称で呼ばれることがある点を理解されたい。例えば、特定のアプリケーションでは、ＣＳＣＦ４９ａ、４９ｃは、呼状態制御機能と呼ばれることがある。
【００８５】
本発明の実施形態は移動局などのユーザ装置に関連して説明してきたが、本発明の実施形態は他のあらゆる好適なタイプのユーザ装置に適用可能である点を理解されたい。この実施形態では、用語「端末」とは、上述のユーザ装置の全ての実施例を対象とすることが意図されている。
【００８６】
図１では無線アクセスネットワークを「３Ｇ」無線アクセスネットワークとして示しているが、ユーザ装置は、他の無線アクセスネットワークを介してＩＭＳネットワークに通信できる点は理解されるであろう。更に、無線アクセスネットワークの実施例は、標準規格ＩＥＥＥ８０２ｘファミリー及びブルートゥース（Ｂｌｕｅｔｏｏｔｈ）規格により記述される無線ネットワークのようなＷＬＡＮシステムを含む。更に、ユーザ装置がコアネットワークに接続するために、図１は無線アクセスネットワークを示しているが、ＡＤＳＬ、ＡＤＳＬ２、ＳＤＳＬ、ＶＤＳＬ、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｒａｍｅ  Ｒｅｌａｙなどの非無線アクセスネットワークの他のタイプも用いることができる。
【００８７】
図１は複数のＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄを示している。ＳＩＰ  Ｐ２Ｐアプリケーションサーバのうちの２つ５１ｂ及び５１ａは、ＣＳＣＦ４９ａ及び４９ｃにそれぞれ接続されて示されている。２つのＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ｃ及び５１ｄは、オペレータＣ及びＢによりそれぞれ操作されるネットワーク内に配置されて示されている。ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂは、オペレータ内Ｐ２Ｐオーバーレイネットワークを形成するよう配置される。ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、オペレータ間ピュアＰ２Ｐオーバーレイネットワーク５３を形成する。各ＳＩＰ  Ｐ２Ｐアプリケーションサーバは、外部ソースからデータを受け取るための入力と、他のＳＩＰ  Ｐ２Ｐアプリケーションサーバ又はＵＥなどの外部ソースにデータを送信するための出力とを備える。更に、各ＳＩＰ  Ｐ２Ｐアプリケーションサーバは、外部ソースから受け取ったデータを記憶するためのメモリを備える。
【００８８】
これらのＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、ＩＭＳ動作に関して標準のアプリケーションサーバとして動作するよう配置されている。加えて、これらのノードは、Ｐ２Ｐ用語により定義される一次ノード又はスーパーノードとして動作するよう配置されている（換言すると、これらのノード間の通信は、ピュアＰ２Ｐオーバーレイネットワーク上で動作し、すなわちＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄの全てが真のピアである）。
【００８９】
従って、各ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、同じネットワークドメイン内（オペレータ内ネットワークを形成するため）又は異なるドメイン内（オペレータ間ネットワークを形成するため）に配置された他のＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄとセッションイニシエーションプロトコル（ＳＩＰ）メッセージを送受信するよう配置される。ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、幾つかの異なる役割を有する。ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、ＵＥ３０ａ、３０ｂ、３０ｃに対してフロントエンドサーバとして動作する。ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、他のスーパーノードが利用可能なネットワークのリソースを活用するよう動作する。ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄは、ＵＥがリソースのサーチにより得られる結果をＰ２Ｐネットワークから入手し、リソース共有のためＰ２Ｐオーバーレイネットワークを維持するのを支援する。
【００９０】
本発明の幾つかの実施形態では、ネットワークにわたって情報を配信するために、１つよりも多いアルゴリズムが用いられる。例えば、オペレータ間Ｐ２Ｐオーバーレイネットワーク５３は、フラッディングアルゴリズム又は分散ハッシュアルゴリズムなどの異なるＰ２Ｐアルゴリズムを実装することができる。選択アルゴリズムは、情報を配置するための最良のアルゴリズムが適用されるように決定することができる。同様に、オペレータ内Ｐ２Ｐオーバーレイネットワークは、本発明の実施形態において、異なるＰ２Ｐアルゴリズムを実装することができる。
【００９１】
このネットワーク内では、ＵＥ３０ａ、３０ｂ、３０ｃは、二次又は通常Ｐ２Ｐノードとして動作するよう配置される。従って、ＵＥ３０ａ、３０ｂ、３０ｃは、ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄに接続されてこれに依存するように配置される。ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄを用いるように許可されたＵＥ３０ａ、３０ｂ、３０ｃは、ＵＥのユーザがＰ２Ｐサービスを利用したい場合、ＵＥがＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄの１つにルーティングされるように構成される。
【００９２】
このようなネットワークでは、ＵＥ３０ａ、３０ｂ、３０ｃは、共有されるリソースに関する情報を公開すること、並びにリソースのサーチを開始する役割を担う。従って、リソースが格納されている場所をＵＥ３０ａ、３０ｂ、３０ｃが発見すると、ＵＥは、そのリソースに作用する（例えば、ファイルをフェッチする、チャットグループに参加する、コンテンツをストリーミングする、その他）よう発見したサーバ／ＵＥに向けた標準ＳＩＰセッションを開始する。二次ＳＩＰセッションは、いずれのＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄをも横断することはできず、従って、これは、２つのＵＥ間、又はＵＥとサーバ、或いは２つのサーバ間の標準ピアツーピアＳＩＰセッションである。
【００９３】
図１では、ＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａ、５１ｂ、５１ｃ、５１ｄの一部を非ＩＭＳ  Ｐ２Ｐネットワークに接続するよう配置することができ、従って、Ｐ２Ｐネットワークの範囲が、オペレータ内ピュアＰ２Ｐオーバーレイネットワーク及びオペレータ間ピュアＰ２Ｐオーバーレイネットワークにより作成されたＩＭＳ  Ｐ２Ｐネットワークを超えて延びることが可能になる。
【００９４】
次に、ユーザがリソース情報の公開、サーチ、及び取り出しができるようにするために、本発明の実施形態により実行される信号フローについて以下で説明する。
【００９５】
図２に関して、このリソース情報を他のユーザが使用できるようにリソース情報を公開するための本発明の実施形態により実行される信号フローが示されている。
【００９６】
ステップ１０１〜１０４は、ユーザ装置を起動又は再起動する際に実行される手順を示している。
【００９７】
ステップ１０１はユーザ装置３０ａの電源オンを示している。他の実施形態では、これはユーザ装置３０ａのハード又はソフトリセットとすることができる。
【００９８】
ステップ１０２は、基地局３１ａとして図１に示されている無線アクセスネットワークを介してパケット交換（ＰＳ）ネットワークドメイン３２ａに接続するユーザ装置３０ａを示している。
【００９９】
ＰＳドメイン接続が正常に実行されると、ステップ１０３を実行することができる。ステップ１０３では、ユーザ装置３０ａがパケットデータプロトコル（ＰＤＰ）コンテキストをパケット交換（ＰＳ）ドメイン３２ａと確立する。ＰＤＰコンテキストの確立が正常に完了すると、本方法はステップ１０４に進む。ステップ１０４では、ＵＥ３０ａがＩＭＳに登録を行う。これは、ＣＳＣＦ４９ａ及びＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ｂとして図示されているＩＭＳコアにてＵＥ３０ａが登録されるように示されている。
【０１００】
ステップ１０５〜１０８は、第２のユーザ装置３０ｃが無線アクセスネットワーク３１ｃを介してパケット交換（ＰＳ）ドメイン３２ａに接続し、ＩＭＳネットワーク（ＣＳＣＦ４９ｃ及びＳＩＰ  Ｐ２Ｐアプリケーションサーバ５１ａとして図示されている）に登録を行うときに、第２のユーザ装置３０ｃにより実行される同じプロセスを示している。
【０１０１】
ステップ１０９〜１１２は、別のユーザ装置により実行される同じプロセスを示している。
【０１０２】
ステップ１２０〜１２４は、ＵＥ３０ａがメモリ内に記憶されたＰ２Ｐアプリケーションを起動するときにＵＥ３０ａにより実行されるデータフロー手順を示している。ステップ１２０の前に、ＵＥ３０ａは、公開されることになるリソースを求め１つ又はそれ以上の予め定義されたディレクトリ又はフォルダ内でローカルサーチを実施することができる。上述したように、これらのリソースは、リソースデータとして使用されることになる、画像ファイル、メッセージ、オーディオクリップ、ｍｐ３ファイル、ビデオファイル、又はユーザにより示された他のファイルといったファイルとすることができ、或いは、チャットルーム、ユーザ、サービス、又はストリーミングコンテンツなどの他のタイプのリソースとすることができる。
【０１０３】
ステップ１２０では、ユーザ装置３０ａは、パケット交換ドメイン３２ａを介してＣＳＣＦ４９ａにＳＩＰ  ＰＵＢＬＩＳＨメッセージを送信する。ＳＩＰ  ＰＵＢＬＩＳＨメッセージ内にはｐ２ｐリソース事象が埋め込まれる。ｐ２ｐリソース事象は、他のユーザがサーチ手順中に見出したリソースコンテンツを決定する際に支援する種々のタイプの情報を含む。ｐ２ｐリソース事象内の情報は、種々の実施形態において、ファイル名、リソースのタイプ（リソースコンテンツが、例えば画像又はオーディオファイルであるか）、リソースのサイズ、リソースを表すアイコン（例えば、画像ファイルの場合、リソースのサムネール）、リソースの簡単な説明、ファイルのハッシュ、ＳＩＰ  ＵＲＩ（すなわち、ＳＩＰアドレス）並びにファイルが格納されるユーザ及びユーザエージェントの端末アドレス（例えば、グローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）の使用）、リソースに関連するアクセス権、及びリソースに関連する他のメタデータとすることができる。
【０１０４】
ステップ１２１において、ＩＭＳコア（ＣＳＣＦ）４９ａにてＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、該リクエストメッセージはユーザにサービスするＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにルーティングされる。
【０１０５】
ステップ１２２では、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、リクエストを受け取ると、「２００  ＯＫ」の応答メッセージをＩＭＳコア（ＣＳＣＦにより表される）４９ａに送信する。応答メッセージは、ＩＥＴＦ  ＲＦＣ  ３９０３に従って、リソースに割り当てられたエンティティタグを含むＳＩＰ−ＥＴａｇヘッダを含む。
【０１０６】
この時点では実際のリソース（例えばファイル）はＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂに送信されておらず、リソースに関連するメタデータだけが送信されたことを示している必要がある。ＵＥ３０ａにサービスするＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、メタデータ情報を格納する。本発明の他の実施形態において、メタデータの格納は、他のＳＩＰ  Ｐ２Ｐ  ＡＳ５１ａ、５１ｃ、５１ｄにおいて実施することができる。幾つかの実施形態において、メタデータは、１つよりも多いＳＩＰ  Ｐ２Ｐ  ＡＳ５１ａ、５１ｂ、５１ｃ、５１ｄ上に格納される。
【０１０７】
ステップ１２３において、ＳＩＰ「２００  ＯＫ」応答メッセージは、ＩＭＳコア（ＣＳＣＦ）４９ａ及びパケット交換ドメイン３２ａを介してＵＥ３０ａにルーティングされる。
【０１０８】
ステップ１２４では、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、オーバーレイＳＩＰ  Ｐ２Ｐネットワークにおいて統合されたスーパーノードとして動作する。ＵＥ３０ａの１つからＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、オーバーレイＳＩＰ  Ｐ２Ｐ  ネットワークにおいてリソースメタデータ情報を公開する。リソースメタデータの実際の公開は、オーバーレイネットワークで使用される選択ピアツーピアアルゴリズムに依存する。例えば、ＳＩＰ  Ｐ２Ｐ分散アルゴリズムがフラッディングに基づいている本発明の第１の実施形態において、ＳＩＰ  Ｐ２Ｐ  ＡＳは、必ずしも他のＳＩＰ  Ｐ２Ｐ  ＡＳとコンタクトをとることも、また何らかのリソースメタデータを交換することもしない。ＳＩＰ  Ｐ２Ｐ分散アルゴリズムがＣｈｏｒｄアルゴリズムに基づいている本発明の別の実施形態において、ＳＩＰ  Ｐ２Ｐ  ＡＳは、リソースメタデータを更新して、更に少なくとも１つの別のＳＩＰ  Ｐ２Ｐ  ＡＳにこれを送信し、該別のＳＩＰ  Ｐ２Ｐ  ＡＳは、使用される分散ハッシュテーブルアルゴリズムに従って、リソースメタデータを格納する役割を担う。ＳＩＰ  Ｐ２Ｐ  ＡＳはまた、自己のリソースデータベース内に情報を格納することができる。
【０１０９】
ステップ１３１〜１３４は、第２のＵＥ３０ｃがリソース情報を公開するデータフローを示している。ステップ１３１は、第２のＵＥがパケット交換（ＰＳ）ドメイン３２ｃを介してＣＳＣＦ４９にＳＩＰ  ＰＵＢＬＩＳＨメッセージを送信する点でステップ１２０に類似する。ステップ１３２は、ユーザにサービスするＳＩＰ  Ｐ２Ｐ  ＡＳにリクエストメッセージがルーティングされる点でステップ１２１に類似する。ステップ１３３は、ＳＩＰ  Ｐ２Ｐ  ＡＳがＳＩＰ  ＰＵＢＬＩＳＨリクエストを受け取ると、ＳＩＰ−ＥＴａｇ  ｚで２００  ＯＫ応答メッセージをＩＭＳコア（ＣＳＣＦにより示される）に送信する点でステップ１２２に類似する。ステップ１３４は、ステップ１２３に類似し、ＳＩＰ「２００  ＯＫ」応答メッセージがＩＭＳコア（ＣＳＣＦ）及びパケット交換ドメインを介してＵＥ３０ｂにルーティングされる。
【０１１０】
ステップ１３５は、リソース情報を公開する際に別のＵＥにより実行されるステップを反映した簡略化されたステップである。
【０１１１】
ステップ１２５〜１３０は、本発明の実施形態で使用される更新プロセスを示している。このプロセスは、リソース情報の公開後にＵＥにおいてリソースが修正された場合に使用される。
【０１１２】
ステップ１２５は、リソース（例えば、画像を表すファイル又はオーディオファイル）がＵＥ３０ａで修正されるステップである。本発明の１つの実施形態のこの修正は、リソースに関連する情報が修正されたとき、例えばリソースに関連するアクセス権が変更された（例えば、ユーザが、あるアクセスグループに対してリソースへのアクセスを制限するよう決定する）ときに行われる。本発明の別の実施形態における修正は、リソース自体が修正されたとき（例えば、例えば「赤目」として知られる効果を抑制するため画像ファイルが編集された場合、又は、例えば無音圧縮するため又は何らかのノイズフィルタを適用するためにオーディオファイルが編集された場合）に行われる。
【０１１３】
リース又はリソースに関連する情報のいずれかに対する修正は、メタデータ情報を変更する場合がある。この変更は、例えばリソースがファイルである場合には通常、ファイルのサイズの変更が反映されるが、更にまた通常はファイルのハッシュ値をも変更する。
【０１１４】
ステップ１２６においてＵＥ３０ａは、上述のリソースにおける変更、又は新しいコンテンツがサーチされたフォルダ又はディレクトリから付加／削除されたことが検出されたことの変更を検出したときには、新しいＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージをＩＭＳコア（ＣＳＣＦ４９ａにより表されるように）に向けて送信する。ＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージは、該メッセージが最後に受信したエンティティタグ値が入っているＳＩＰ−ｉｆ−ｍａｔｃｈヘッダフィールドを含む点で、ステップ１２０で送信されたＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージとは異なる。
【０１１５】
ステップ１２７では、ＩＭＳコア（ＣＳＣＦ）４９ａで更新ＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、更新ＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージは、ユーザにサービスするＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにルーティングされる。
【０１１６】
ステップ１２８では、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、更新ＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、「２００  ＯＫ」応答メッセージをＩＭＳコア（ＣＳＣＦで表される）４９ａに送信する。ＩＥＴＦ  ＲＦＣ３９０３による応答メッセージは、更新応答に割り当てられたエンティティタグを含むＳＩＰ−ＥＴａｇヘッダを含む。
【０１１７】
ステップ１２９において、ＳＩＰ  ２００−ＯＫ応答メッセージは、ＩＭＳコア（ＣＳＣＦ）４９ａ及びパケット交換ドメイン３２ａを介してＵＥ３０ａにルーティングされる。
【０１１８】
ステップ１３０では、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂがＵＥ３０ａの１つから更新ＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、更新リソース又は新規に付加されたリソースに関連するオーバーレイＳＩＰ  Ｐ２Ｐ  ネットワークにおけるリソースメタデータ情報を再公開する。上述のように、リソースメタデータの実際の再公開はｍオーバーレイネットワークで使用される選択ピアツーピアアルゴリズムに依存する。
【０１１９】
図３に関して、ネットワーク上でリソース情報をサーチするために本発明の実施形態により実行される信号フローが図示される。
【０１２０】
ステップ１４０では、ユーザがＵＥ３０ａにおいてサーチを開始する。本発明の第１の実施形態では、サーチは、ユーザが「キーボード」に入力し、該入力に一致するリソースを求めてサーチするときに開始される。本発明の他の実施形態において、ユーザは、サーチするために他の値を入力し、例えば、入力は、デジタルオーディオファイル又は画像若しくはビデオクリップのフラグメントとすることができる。
【０１２１】
ステップ１４１では、ＵＥはＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストメッセージを作成する。入力がない場合、ｐ２ｐリソース事象への加入は、オーバーレイＳＩＰ  Ｐ２Ｐネットワークを通じて利用可能な全リソースのメタデータを戻すことができる。ユーザはユーザ入力に関連するリソースにのみ関心があるので、ＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストメッセージは、戻される結果をユーザ入力値にリンクされ且つユーザのプロファイルを満たすのに十分なものに制限する（例えば、子供が大人向けの暴力行為を含むビデオクリップなど大人向けのリソースにアクセスするのを防ぐ）フィルタ本体を含む。
【０１２２】
ステップ１４２において、ＩＭＳコア（ＣＳＣＦ４９ａで示される）により受け取られたＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストは、ユーザにサービスされるＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにルーティングされる。
【０１２３】
ステップ１４２において、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、ＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストを受け取り、ステップ１４３において、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、ＩＭＳコア（ＣＳＣＦ４９ａで示される）に「２００  ＯＫ」応答メッセージを送信することによりＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストに応答する。
【０１２４】
ステップ１４４において、ＩＭＳコア（ＣＳＣＦ４９ａ）により受け取られた「２００  ＯＫ」応答メッセージパケット交換ドメイン３２ａを介してＵＥ３０ａにルーティングされる。従って、ＵＥ３０ａは、サーチリクエストが受け取られたと判断することができる。
【０１２５】
ステップ１４５では、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、ＳＩＰ  ＰＵＢＬＩＳＨリクエストメッセージを受け取ると、そのデータベース内でルックアップを実行し、フィルタで指定されたリソースを保持するサーバ／ＵＥのアドレスをサーチする。このサーチ動作は、ネットワークにわたって実施されるピアツーピアアルゴリズムに依存する。従って、本発明の実施形態に基づくフラッディングアルゴリズムにおいて、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂが入力フィルタ情報で「プッシュ」された場合、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、隣接ＳＩＰ  Ｐ２Ｐ  ＡＳの各々又はサブセットにＳＵＢＳＣＲＩＢＥリクエストを「エクスプロード」し（すなわち、隣接ＳＩＰ  Ｐ２Ｐ  ＡＳにリクエストをコピーし）、次いで、これらの隣接ＳＩＰ  Ｐ２Ｐ  ＡＳは、その隣接するＳＩＰ  Ｐ２Ｐ  ＡＳにＳＵＢＳＣＲＩＢＥリクエストをエクスプロードし、以下同様である。次に、ＳＵＢＳＣＲＩＢＥリクエストメッセージを受け取るＳＩＰ  Ｐ２Ｐ  ＡＳの各々は、それぞれのデータベースのサーチを実施し、リソースを保持するサーバ／ＵＥ−すなわちフィルタに関連する事前公開メタデータを有するサーバ／ＵＥのアドレスをサーチする。
【０１２６】
Ｃｈｏｒｄアルゴリズムがネットワーク内のピアツーピアアルゴリズムとして実装される本発明の別の実施形態において、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、「フィンガー」テーブル上でルックアップを実行し、そのフィンガーテーブル内のリソースに関連するキーの最直近の前任者に単一のＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストを送信する。先行ＳＩＰ  Ｐ２Ｐ  ＡＳノードは、別の実施形態において、及びリクエストに応じて、別のＳＩＰ  Ｐ２Ｐ  ＡＳノード又は他のＰ２Ｐノードにリクエストを転送又はプロキシすることができる。
【０１２７】
ステップ１４６において、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂはまた、ＳＩＰ  ＮＯＴＩＦＹリクエストをＩＭＳコア（ＣＳＣＦ４９ａ）に送信する。
【０１２８】
ステップ１４７において、ＩＭＳコア４９ａは、ＳＩＰ  ＮＯＴＩＦＹリクエストを受け取ると、該リクエストをＵＥ３０ａにルーティングする。
【０１２９】
本発明の実施形態によれば、ＳＩＰ  ＮＯＴＩＦＹリクエストは、サーチされたリソースについての情報の第１の集合（例えば、サーバ／ＵＥアドレス情報）を含むことができる。例えば、このような情報は、（他のＵＥ３０ｂからＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂへの公開オペレーションにより、又は前のサーチからキャッシュされた情報により、或いは他のＳＩＰ  Ｐ２Ｐ  ＡＳからＳＩＰ  Ｐ２Ｐ  ＡＳにわたされた公開情報により）ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂで既に利用可能である場合である。
【０１３０】
しかしながら、通常本発明の実施形態では、ＳＩＰ  ＮＯＴＩＦＹリクエストは、サーチされたリソースについての情報を含まない。この事象において、ＳＩＰ  ＮＯＴＩＦＹリクエストは、各成功したＳＵＢＳＣＲＩＢＥリクエスト後にプロトコル（ＩＥＴＦ  ＲＦＣ  ３２６５）が必要とする手順に従うために必要となる。
【０１３１】
ステップ１４８では、ＵＥ３０ａは、最初にＩＭＳコア４９ａに「２００  ＯＫ」応答を送信することによってＮＯＴＩＦＹリクエストに応答し（ステップ１４８）、次いで、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにルーティングされる（ステップ１４９）。
【０１３２】
ステップ１５０では、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、他のＳＩＰ  Ｐ２Ｐ  ＡＳからサーチされたリソースについての一連の第１の結果を受け取る。これらのＳＩＰ  ＮＯＴＩＦＹ応答が受け取られると、サーチに関する情報が利用可能になる。
【０１３３】
ステップ１５１において、本発明の実施形態によれば、ユーザの選好（換言すると、受領した通知の割合、帯域幅使用量、及び事象制限）に従って、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂはＳＩＰ  ＮＯＴＩＦＹリクエストメッセージをＩＭＳコア４９ａに送信する。
【０１３４】
ステップ１５２において、ＩＭＳコアは、ＳＩＰ  ＮＯＴＩＦＹリクエストメッセージをＵＥ３０ａにルーティングする。
【０１３５】
ステップ１５１及び１５２に記載されたＳＩＰ  ＮＯＴＩＦＹリクエストメッセージは、ｐ２ｐリソース事象パッケージに従ってメッセージの本体にデータを含む。事象パッケージは、各リソースに関連する全メタデータ情報を含む。例えば、リソースがファイルである場合、事象パッケージはファイル名、サイズ、タイプ、アイコン（画像ファイルの場合）、ハッシュ値、タイムスタンプ、ファイルが利用可能なユーザのＳＩＰ  ＵＲＩ及び／又はＵＥアドレス（ＧＲＵＵ）を含むことができる。
【０１３６】
本発明の幾つかの実施形態において、事象パッケージ本体は、サーチ基準に合致する幾つかのリソース（例えばファイル）についての情報を含む。当業者には理解されるように、幾つかのリソースは、幾つかの理由でサーチ基準に合致することができる。例えば、各リソース（ファイル）は、多重ダウンロード（一般的なファイルの場合）によるＳＩＰ  Ｐ２Ｐオーバーレイネットワーク全体を通じた重複の結果とすることができる。
【０１３７】
ステップ１５３において、ＵＥ３０ａは、「２００  ＯＫ」応答をＩＭＳコア４９ａに送信することによりＳＩＰ  ＮＯＴＩＦＹリクエストの受信に確認応答する。ステップ１５４において、ＳＩＰ「２００  ＯＫ」メッセージはＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにルーティングされる。
【０１３８】
ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂがＳＩＰ  Ｐ２Ｐオーバーレイネットワークからのサーチに関する情報を受け取る毎に、この情報はＳＩＰ  ＮＯＴＩＦＹリクエストにおいてＵＥ３０ａに送信される（通知の割合に関するユーザの選好によりこれらのリクエストを送信可能になる）。これらのＳＩＰ  ＮＯＴＩＦＹリクエストメッセージはステップ１５１〜１５４を繰り返す。本発明の実施形態は、別個に受信した各情報要素を転送するので、ＵＥ３０ａのユーザ選好は、受信情報を受信すると直ぐに順次表示し、従って、結果を迅速に表示し且つ表示する前に受信情報の全てを関連付ける必要がないという点でユーザにとって使い勝手の良いシステムを提供するように構成することができ、よって、ユーザがサーチ結果の全てを受け取る前にサーチ結果を迅速に選択できるようになる。これは、同じリソースの複数のコピーがネットワーク上で利用可能な場合に特に有利である。
【０１３９】
ステップ１５５〜１５９は、本発明の実施形態によるサーチオペレーションの終了を示している。
【０１４０】
ステップ１５５では、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにおいて、サーチの最後の結果がオーバーレイＳＩＰ  Ｐ２ＰネットワークからＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂが利用可能となったことを判断する。
【０１４１】
ステップ１５６において、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは、ＵＥ３０ａをアドレス指定するＩＭＳコア４９ａにＳＩＰ  ＮＯＴＩＦＹリクエストを送信する。ＳＩＰ  ＮＯＴＩＦＹリクエストは、ｐ２ｐリソース事象内に少なくとも利用可能な結果を含む（何らかの報告すべきことがある場合）。ＳＩＰ  ＮＯＴＩＦＹリクエストはまた、Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅヘッダフィールドを「終了」に設定し、このＮＯＴＩＦＹリクエストがサーチオペレーションの終わりであることをＵＥに表示する。
【０１４２】
ステップ１５７において、ＳＩＰ  ＮＯＴＩＦＹリクエストは、ＩＭＳコア４９ａからＰＳドメイン３２ａを介してＵＥ３０ａにルーティングされる。
【０１４３】
ステップ１５８において、ＵＥ３０ａは、ＳＩＰ  Ｐ２Ｐ  ＡＳをアドレス指定するＩＭＳコアにＳＩＰ「２００  ＯＫ」メッセージを送信することによってＳＩＰ  ＮＯＴＩＦＹリクエストの受信に確認応答し、次いで、ＩＭＳコアによりＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにルーティングされる（ステップ１５９）。
【０１４４】
別のＵＥ又はネットワーク要素（ノードとも呼ばれる）においてリソースの可用性についての情報を含むＮＯＴＩＦＹリクエストを受信する（例えばステップ１５２、１５７）と、ＵＥ３０ａは、今後の使用のため受信した情報を格納する。
【０１４５】
本発明の別の実施形態において、ユーザはまた、ゼロに設定された「期限切れ」ヘッダフィールドを含むＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにＳＩＰ  ＮＯＴＩＦＹリクエストを送信するようＵＥ３０ａを構成することにより、サーチオペレーションをキャンセルすることができる。この場合、ＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂは自動的にタイムアウトになり、ステップ１５６に続くことができる。
【０１４６】
図４に関して、ネットワーク上のリソース情報をフェッチするために本発明の実施形態により実行される信号フローが図示されている。
【０１４７】
ステップ１８０において、ユーザは、通常はモバイル装置のユーザインタフェースと相互作用することにより動作することになるリソースを選択する。リソースがファイルの場合、ファイルをフェッチすることができる。リソースがチャットルーム、会議、ユーザ名、又はストリーミングビデオの場合、セッションが当該リソースに向けて開始される。
【０１４８】
ステップ１８１において、リソース及び／又は該リソースが格納される１つ又はそれ以上のサーバ／ＵＥのアドレスが選択されると、ＵＥは、リソースが格納される１つ又はそれ以上のサーバ／ＵＥの各々にアドレス指定されたＳＩＰ  ＩＮＶＩＴＥリクエストをＩＭＳコア４９ａに送る。リソースが格納されるサーバ／ＵＥのアドレスは、図３で既に説明されたようなサーチオペレーションにおいて学習されている。明確にするために、図４は、リソースが１つの遠隔の位置、具体的には第２のＵＥ３０ｃにだけ格納されるケースを示している。ＳＩＰ  ＩＮＶＩＴＥリクエストは、リソース転送オペレーションのリクエストを示すＳＤＰオファーを含む。ＳＤＰオファーはまた、特にファイル転送（例えばリクエストされたファイルのハッシュ）の場合に取り出されることになるリソースを示すのに十分なメタデータを含む。
【０１４９】
ステップ１８２において、ＳＩＰ  ＩＮＶＩＴＥリクエストは、リソースが格納される第２のＵＥ３０ｃのアドレスに向けてＩＭＳコア内にルーティングされる。ＳＩＰ  ＩＮＶＩＴＥリクエスト１８２は、ＵＥ３０ａにサービスするＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂにも、第２のＵＥ３０ｃにサービスするＳＩＰ  Ｐ２Ｐ  ＡＳ５１ａのいずれにもルーティングされる必要がない。しかしながら、オペレータのポリシーは、例えば、適切なアカウンティング又は認可を可能にするためＳＩＰ  Ｐ２Ｐ  ＡＳ５１ｂ又は５１ａのいずれかを横断する必要がある。或いは、例えば、ＳＩＰ  Ｐ２Ｐ  ＡＳは、パブリックからプライベートＩＰアドレスへのアドレス変換機能を提供することができる。簡単にするために、図４は、ＳＩＰ  ＩＮＶＩＴＥリクエスト１８２がＳＩＰ  Ｐ２Ｐ  ＡＳ５１ａ又は５１ｂのいずれも横断しない場合の本発明の実施形態を示している。
【０１５０】
ステップ１８３において、ＳＩＰ  ＩＮＶＩＴＥリクエストは、ＩＭＳコア４９ａから遠隔ＵＥ３０ｃの第２のＩＭＳコアにルーティングされる。
【０１５１】
ステップ１８４において、遠隔ＵＥ３０ｃは、ＩＮＶＩＴＥリクエストを受け取り、リクエストをサービスできるかどうかを判断する。例えば、ＵＥの処理能力、利用可能な帯域幅、転送オペレーションの最大数、その他は、ＵＥがこの時点でリクエストをサービスできないと判断することができる。遠隔ＵＥ３０ｃがリクエストを直ちにサービスできない場合には、ステップ１８５から１８７が実施され、そうでない場合、オペレーションはステップ１８８に進み、リクエストをサービスする。
【０１５２】
遠隔ＵＥ３０ｃがリソース不足によりリクエストをサービスできない場合、遠隔ＵＥ３０ｃは、ＳＩＰ「１８２待ち行列」応答をリクストしているＵＥ３０ａに送信し、リクエストがローカルキューの待ち行列に入れられる。ＳＩＰ「１８２待ち行列」応答が、ステップ１８５で遠隔ＵＥ３０ｃから遠隔ＩＭＳコア４９ｃに、ステップ１８６で遠隔ＩＭＳコア４９ｃからリクエストしているＩＭＳコア４９ａに、ステップ１８７でリクエストしているＩＭＳコア４９ａからリクエストしているＵＥ３０ａに送信される。
【０１５３】
ステップ１８８において、遠隔ＵＥ３０ｃは、リソースを求める受信リクエストをサービスすることができると判断する。次いで、遠隔ＵＥ３０は、ＳＤＰ応答を含むリクエストしているＵＥ３０ａにアドレス指定されたＳＩＰ「２００  ＯＫ」応答メッセージを送信する。本発明の幾つかの実施形態において、ＳＤＰはまた、ファイル関連情報を含む。ＳＩＰ「２００  ＯＫ」応答は、ステップ１８９で遠隔ＵＥ３０ｃから遠隔ＩＭＳコア４９ｃへ、ステップ１９０で遠隔ＩＭＳコア４９ｃからリクエストしているＩＭＳコア４９ａは、ステップ１９１でリクエストしているＩＭＳコア４９ａからリクエストしているＵＥ３０ａへ送信される。
【０１５４】
ステップ１９５において、ＳＩＰ  Ｐ２Ｐ  ＡＳの支援を受けることなく遠隔ＵＥ３０ｃからリクエストしているＵＥ３０ａにリソースを転送するメディアセッションが確立される。メディアセッションは、遠隔ＵＥからリクエストしているＵＥにデータを転送するのに既知の転送プロトコルのいずれかを使用することができるが、１つの好ましい転送プロトコルは、メッセージセッションリレープロトコルである（ＭＳＲＰ、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−  ｍｅｓｓａｇｅ−ｓｅｓｓｉｏｎｓ、策定中）。本発明の実施形態において使用できる他の転送プロトコルには、限定ではないが、ファイル転送プロトコル（ＦＴＰ、ＲＦＣ９５９）、ハイパーテキスト転送プロトコル（ＨＴＴＰ、ＲＦＣ２６１６）、一方向転送のファイル配信（ＦＬＵＴＥ、ＲＦＣ３９２６）がある。
【０１５５】
ステップ１９６から２０１では、転送セッションの終わりは、リクエストしているＵＥ３０ａにより信号が送られ確認応答される。メタデータセッションが終わると、遠隔ＵＥ３０ｃは、リクエストしているＵＥ３０ａにアドレス指定されたＳＩＰ  ＢＹＥリクエストを送信し、セッションを閉じる。ＳＩＰ  ＢＹＥリクエストは、ステップ１９６で遠隔ＵＥ３０ｃから遠隔ＩＭＳコア４９ｃに、ステップ１９７で遠隔ＩＭＳコア４９ｃからリクエストしているＩＭＳコア４９ａに、ステップ１９８でリクエストしているＩＳＭコア４９ａからリクエストしているＵＥ３０ａに送信される。次いで、リクエストしているＵＥ３０ａは、遠隔ＵＥ３０ｃにアドレス指定されたＳＩＰ「２００  ＯＫ」応答を送信することによってリクエストに確認応答する。ＳＩＰ「２００  ＯＫ」応答は、ステップ１９９でリクエストしているＵＥ３０ａからリクエストしているＩＭＳコア４９ａに、ステップ２００でリクエストしているＩＭＳコア４９ａから遠隔ＩＭＳコア４９ｃへ、ステップ２０１で遠隔ＩＭＳコア４９ｃから遠隔ＵＥ３０ｃへ送信される。
【０１５６】
本発明の上記の実施形態は、上述の問題を解決する。リソースに関連する情報の配信者としてフロントエンドＰ２Ｐノードを設ける際に、リソースを含むＵＥ又はサーバへの信号伝達が低減され、従って、遠隔ＵＥの断続的な接続性の問題が低減される。関連する情報は、リソースがネットワークと接触した時点で存在するかどうかに関わらず利用可能である。
【０１５７】
更に、ＳＩＰ  Ｐ２ＰＡＳ自体がインターネットから到達可能なパブリックＩＰアドレスを備えている場合、ネットワークアドレス変換されるＵＥを有する問題が低減される。
【０１５８】
また、本発明の実施形態としてのＰ２Ｐネットワークは、ＳＩＰ  Ｐ２Ｐ  ＡＳを使用してオーバーレイネットワークを提供することにより、既存のＩＭＳネットワークに対して最小限の影響しかもたらさない。従って、ネットワークのオペレータは、既存のネットワークノードを追加のルーティングフィルタと共に用いて、上述のＳＩＰリクエスト及び応答をルーティングすることができる。オペレータはまた、ＳＩＰ  Ｐ２Ｐサーバを使用するためにチャージシステムを実装することができる。
【０１５９】
上述の本発明の実施形態は、家族間での写真共有のようなリソースを供給するのにユーザが用いることができる。このような実施形態において、特定のメンバー（ファミリーの）及びスーパーノードとして動作する関連するＳＩＰ  Ｐ２Ｐ  ＡＳを含む閉じたＳＩＰ  Ｐ２Ｐオーバーレイネットワークが作成される。メンバーは、例えばＳＩＰ  Ｐ２Ｐオーバーレイネットワークに公開されるＵＥを用いて画像を取得することができる。次いで、公開された画像は、家族の他のメンバーにより直ぐにダウンロードされて、他のメンバーのＵＥで閲覧することができる。
【０１６０】
閉じたオーバーレイネットワークの他の実施例は、特定の不動産業者又はブローカーにより取得される販売又は賃貸用の不動産の画像及びビデオクリップの公開及び表示に属する。不動産業者は、閉じたオーバーレイネットワークに画像又はビデオクリップを公開することができ、公開されたリソースをサーチするのが許可された可能性のあるクライアントがサーチ及びフェッチすることができる。
【０１６１】
使用中のオーバーレイネットワークの別の実施例は、スポーツイベント中に、例えばフットボール中の場合、すなわちイベントを見ている公衆のメンバーにより画像／ビデオクリップを作成できる場合である。これらのクリップは、オーバーレイネットワークに公開され、イベントを見ている公衆の他のメンバーに利用可能にされ、他のメンバーが別の地点で見ることができるようにする。
【０１６２】
上記の図１〜４は、各ＵＥが単一のＳＩＰ  Ｐ２Ｐ  ＡＳに接続するのを示している。しかしながら本発明の他の実施形態では、各ＵＥは、負荷バランシング及び冗長性を利用するために１つよりも多いＳＩＰ  Ｐ２Ｐ  ＡＳに接続することができる。ＵＥが１つよりも多いＰ２Ｐネットワーク（例えば、ファミリー画像ファイル共有サービス及びび不動産業者ネットワーク）に接続することができる他の場合において、ここでＵＥは１つよりも多いＳＩＰ  Ｐ２Ｐ  ＡＳに接続され、各ＳＩＰ  Ｐ２Ｐ  ＡＳは異なるＰ２Ｐオーバーレイネットワークの一部である。
【０１６３】
本出願人は、本明細書で説明された特徴又は特徴の組み合わせが本明細書で開示されたあらゆる問題を解決するかどうかに関わらず、且つ請求項の範囲を限定することなく当業者の一般的な知識に照らしてこうした特徴又は組み合わせが本明細書に基づいて全体として実施できる範囲において、こうした各個々の特徴を単独で、及び２つ又はそれ以上のこうした特徴をあらゆる組み合わせで本明細書によって開示した。本出願人は、本発明の態様がこうしたあらゆる個々の特徴又は特徴の組み合わせからなるものとすることができることを指摘する。以上の説明に鑑み、当業者であれば本発明の範囲内で種々の修正を行い得ることは明らかであろう。
【図面の簡単な説明】
【０１６４】
【図１】本発明の実施形態を特徴として備える通信システムの概略図である。
【図２】本発明の実施形態を用いてリソース情報をユーザが公開することができる方法の概略図である。
【図３】本発明の実施形態を用いてリソース情報をユーザがサーチすることができる方法の概略図である。
【図４】本発明の実施形態を用いてリソース情報をユーザがフェッチすることができる方法の概略図である。
【符号の説明】
【０１６５】
１、２、３  ドメイン
３０ａ、３０ｂ、３０ｃ  モバイルユーザ装置
３１ａ、３１ｂ、３１ｃ  基地局
３２ａ、３２ｉ  ＧＰＲＳバックボーンネットワーク
３３ａ  サービングＧＰＲＳノード（ＳＧＳＮ）
３４ａ  ゲートウェイ側ＧＰＲＳノード（ＧＧＳＮ）
４０  非ＩＭＳ  Ｐ２Ｐネットワーク
４９ａ、４９ｃ  呼セッション制御機能（ＣＳＣＦ）部
５１ａ、５１ｂ、５１ｃ、５１ｄ  ＳＩＰ  Ｐ２Ｐアプリケーションサーバ
５３  オペレータ間ピュアＰ２Ｐオーバーレイネットワーク
【図１】
2009533925.tif 000003
【図２】
2009533925.tif 000004
【図３】
2009533925.tif 000005
【図４】
2009533925.tif 000006
【手続補正書】
【提出日】平成20年10月14日(2008.10.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信ネットワークにおいてピアツーピアサービスを提供するように構成されたサーバであって、前記ネットワークが少なくとも１つの別のサーバを含み、前記サーバが、
少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成された入力と、
前記少なくとも１つのＳＩＰピアツーピアリクエストを前記サーバから前記少なくとも１つの別のサーバの少なくとも１つに送信するように構成された出力と、
を備え、
前記少なくとも１つの別のサーバがピアツーピアアルゴリズムに基づいて選択され、前記入力が、前記少なくとも１つの別のサーバから少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成され、前記ＳＩＰピアツーピア応答を送信するように構成されている、
ことを特徴とするサーバ。
【請求項２】
前記サーバ入力が、アクセスネットワークを介してユーザ装置（ＵＥ）から前記少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている、
請求項１に記載のサーバ。
【請求項３】
前記サーバ出力が、前記アクセスネットワークを介して前記ユーザ装置（ＵＥ）に前記ＳＩＰピアツーピア応答を送信するよう構成されている、
請求項２に記載のサーバ。
【請求項４】
前記ユーザ装置がＰ２Ｐ２次ノードである、
請求項２又は３に記載のサーバ。
【請求項５】
前記サーバ入力が、前記少なくとも１つの別のサーバから前記少なくとも１つのＳＩＰピアツーピアリクエストを受け取るように構成されている、
請求項１に記載のサーバ。
【請求項６】
前記ノード出力が、前記少なくとも１つの別のサーバに前記ＳＩＰピアツーピア応答を送信するように構成されている、
請求項５に記載のサーバ。
【請求項７】
前記サーバがピアツーピア一次ノードである、
請求項１から６に記載のサーバ。
【請求項８】
前記ピアツーピアリクエストがピアツーピアリソース公開を含む、
請求項１から７に記載のサーバ。
【請求項９】
前記少なくとも１つのピアツーピアリソース公開リクエストが第１の情報要素を含む、
請求項８に記載のサーバ。
【請求項１０】
前記サーバがメモリを備え、該メモリ内に前記第１の情報要素を格納するように更に構成されている、
請求項９に記載のサーバ。
【請求項１１】
前記第１の情報要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの簡単な説明、
前記リソースのハッシュ、
前記リソースのアドレスのＳＩＰ  ＵＲＩ、
前記リソースの端末アドレス、
前記リソースのタイムスタンプ、
ファイルが格納されるユーザのグローバルにルーティング可能なユーザエージェントＵＲＩ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つである、
請求項９又は１０に記載のサーバ。
【請求項１２】
前記少なくとも１つのピアツーピアリソース公開リクエストがＳＩＰ  ＰＵＢＬＩＳＨリクエストである、
請求項８から１１に記載のサーバ。
【請求項１３】
前記ＳＩＰピアツーピアリクエストが、リクエストされたリソース要素を有するサーチリクエストを含む、
請求項１から７に記載のサーバ。
【請求項１４】
前記サーチリクエストがＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストである、
請求項１３に記載のサーバ。
【請求項１５】
メモリを更に備え、前記ノードが、前記リクエストされたリソース要素と合致するリソースを含む少なくとも１つのノードのアドレスを求めて前記メモリをサーチするよう構成されている、
請求項１３又は１４に記載のサーバ。
【請求項１６】
前記ＳＩＰピアツーピア応答が、前記サーチリクエストサーチ情報要素に合致するリソースを含むネットワークノードのアドレスを有する、
請求項１３から１５に記載のサーバ。
【請求項１７】
前記アドレスが、
ＳＩＰ  ＵＲＩ、
ネットワークノードアドレス、
端末アドレス、
及びグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、
のうちの少なくとも１つを含む、
請求項１５又は１６に記載のサーバ。
【請求項１８】
前記リクエストされたリソース要素が、
リソース名、
ファイル名、
リソースタイプ、
リソースサイズ、
前記リソースを表すアイコン、
前記リソースの簡単な説明、
前記リソースのハッシュ、
前記リソースに関連するアクセス権、
及び前記リソースに関連するメタデータ、
のうちの少なくとも１つを含む、
請求項１３から１７に記載のサーバ。
【請求項１９】
前記ＳＩＰピアツーピア応答がＳＩＰ  ＮＯＴＩＦＹメッセージを含む、
請求項１から１８に記載のサーバ。
【請求項２０】
移動体通信ネットワークがＩＰマルチメディアサブシステムを含む、
請求項１から１９に記載のサーバ。
【請求項２１】
前記サーバがＳＩＰピアツーピアアプリケーションサーバである、
請求項１から２０に記載のサーバ。
【請求項２２】
請求項１から２１に記載のサーバを備えるオーバーレイピアツーピアネットワーク。
【請求項２３】
移動体通信ネットワークにおいてピアツーピアサービスを提供するように構成された第１のサーバ及び少なくとも１つの第２のサーバであって、
前記第１のサーバが、
リクエストされたリソース要素を含む少なくとも１つのＳＩＰピアツーピアサーチリクエストを受け取るように構成された入力と、
前記少なくとも１つのＳＩＰピアツーピアリクエストを前記第１のサーバから前記少なくとも１つの第２のサーバの少なくとも１つに送信するよう構成された出力と、
を備え、
前記少なくとも１つの第２のサーバが、
前記少なくとも１つのＳＩＰピアツーピアサーチリクエストを受け取るように構成された入力と、
前記少なくとも１つの第２のサーバが、前記リクエストされたリソース要素に合致するリソースを含む少なくとも１つのノードの少なくとも１つのアドレスを求めてサーチするよう構成されているメモリと、
前記少なくとも１つのアドレスの少なくとも１つを有するＳＩＰピアツーピア応答を送信するよう構成された出力と、
を備え、
前記第１のサーバの入力が、前記少なくとも１つの第２のサーバから前記少なくとも１つのＳＩＰピアツーピア応答を受け取るように更に構成されており、
前記第１のサーバの出力が、前記少なくとも１つのアドレスの少なくとも１つを有するＳＩＰピアツーピア応答を送信するよう構成されている、
ことを特徴とする第１のサーバ及び少なくとも１つの第２のサーバ。
【請求項２４】
移動体通信ネットワークにおいてピアツーピアサービスを提供するよう構成されたサーバであって、
リクエストされたリソース要素を含む少なくとも１つのＳＩＰピアツーピアサーチリクエストを受け取るように構成された入力と、
前記サーバが、前記リクエストされたリソース要素に合致するリソースを含む少なくとも１つのノードの少なくとも１つのアドレスを求めてサーチするよう構成されているメモリと、
前記少なくとも１つのアドレスの少なくとも１つを有するＳＩＰピアツーピア応答を送信するよう構成された出力と、
を備えることを特徴とするサーバ。
【請求項２５】
移動体通信ネットワークにおいてピアツーピアサービスを提供するよう構成されたサーバであって、
第１の情報要素を有する少なくとも１つのＳＩＰピアツーピアリソース公開リクエストを受け取るように構成された入力と、
前記サーバが前記第１の情報要素をその内部に格納するよう構成されたメモリと、
を備えることを特徴とするサーバ。
【国際調査報告】
2009533925.tif 000007
2009533925.tif 000008
2009533925.tif 000009