(57)【要約】  異なるローカル・ネットワークにわたるサービスの遠隔での発見を実行するための方法と装置。一方のローカル・ネットワーク（２０２）内のサービス発見ゲートウェイ（２０２ｂ）は、反対側のローカル・ネットワーク（２００）内のサービスに関する発見情報の要求を、ＩＭＳネットワーク（２０４）を介してプレゼンス購買メッセージの中に埋め込んで発行する。その後、発見情報は、ＩＭＳネットワークを介してプレゼンス通知メッセージの中に埋め込まれて、ジェネリック・フォーマットで受信される。受信された発見情報は、第１のローカル・ネットワーク内のローカル・サービス発見プロトコルを使用して、第１のローカル・ネットワーク内のサービス発見ゲートウェイによって収集されていたものである。受信された発見情報は、第２のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを使用して、第２のローカル・ネットワーク内のデバイスに報知される。これにより、ローカル・ネットワークの中ではデバイスに特化した異なるサービス発見プロトコルが使用されている場合でも、ローカル・サービスが異なるローカル・ネットワークにわたって提供され利用されることができる。
2010515338.tif 000002
【特許請求の範囲】
【請求項１】
第２のローカル・ネットワーク内の場所から第１のローカル・ネットワークにおける複数のサービス及び複数のデバイスの遠隔での発見を行なう方法であって、
ＩＭＳネットワークを介してプレゼンス購読メッセージに埋め込まれて送信される要求であって、前記第１のローカル・ネットワークにおける複数のデバイスの発見情報に対する前記要求を発行するステップと、
前記第１のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを使用する発見処理において前記第１のローカル・ネットワークのサービス発見ゲートウェイによって収集される発見情報であって、前記要求に応じて前記ＩＭＳネットワークを介してプレゼンス通知メッセージに埋め込まれたジェネリック・フォーマットの前記発見情報を受信するステップと、
前記第２のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを用いて、前記第２のローカル・ネットワーク内の少なくとも１つのデバイスに受信した前記発見情報を報知するステップと
を前記第２のローカル・ネットワークにおけるサービス発見ゲートウェイによって実行することを特徴とする方法。
【請求項２】
前記発見情報は、前記第２のローカル・ネットワークにおいて報知される前に、前記ジェネリック・フォーマットから該第２のローカル・ネットワークによってサポートされるローカル・フォーマットに変換されることを特徴とする請求項１に記載の方法。
【請求項３】
前記発見情報に対する要求は、前記第１のローカル・ネットワークの前記サービス発見ゲートウェイに送信され、
前記発見情報は、前記サービス発見ゲートウェイからの応答として、受信されることを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記発見情報に対する要求は、前記ＩＭＳネットワークにおいてプレゼンスサーバに送信され、
前記発見情報は、前記プレゼンスサーバからの応答として、受信されることを特徴とする請求項１又は２に記載の方法。
【請求項５】
前記プレゼンスサーバは、前記第１のローカル・ネットワークの前記サービス発見ゲートウェイからのプレゼンス公開メッセージにおいて前記収集された発見情報を受信することを特徴とする請求項４に記載の方法。
【請求項６】
前記第２のローカル・ネットワークは、アドホックネットワークであり、
前記第２のローカル・ネットワークの前記サービス発見ゲートウェイは、前記アドホックネットワークの他のデバイスの代わりに前記ＩＭＳネットワークにアクセスするために、マルチメディア・ゲートウェイとして動作するユーザデバイスに実装されることを特徴とする請求項１乃至５の何れか１項に記載の方法。
【請求項７】
携帯ＩＭＳゲートウェイＰＩＧＡが前記ユーザデバイスに実装されることを特徴とする請求項６に記載の方法。
【請求項８】
第２のローカル・ネットワークに接続され、該第２のローカル・ネットワーク内の場所から第１のローカル・ネットワークにおける複数のサービス及び複数のデバイスの遠隔での発見を行なうサービス発見ゲートウェイ（６０２）であって、
ＩＭＳネットワークを介してプレゼンス購読メッセージに埋め込まれて送信される要求であって、前記第１のローカル・ネットワークにおける複数のデバイスの発見情報に対する前記要求を発行し、前記第１のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを使用する前記第１のローカル・ネットワークのサービス発見ゲートウェイによって収集される発見情報であって、前記要求に応じて前記ＩＭＳネットワークを介してプレゼンス通知メッセージに埋め込まれた前記発見情報を受信するプレゼンス・ウオッチャ部（６０２ａ）と、
前記第２のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを用いて、前記第２のローカル・ネットワーク内の少なくとも１つのデバイスに受信した前記発見情報を報知する報知部（６０２ｃ）と
を備えることを特徴とするサービス発見ゲートウェイ（６０２）。
【請求項９】
前記第２のローカル・ネットワークにおいて報知される前に、前記発見情報を、ジェネリック・フォーマットから該第２のローカル・ネットワークによってサポートされるローカル・フォーマットに変換する変換部（６０２ｂ）をさらに備えることを特徴とする請求項８に記載のサービス発見ゲートウェイ（６０２）。
【請求項１０】
前記プレゼンス・ウオッチャ部は、さらに、前記発見情報に対する前記要求を、前記第１のローカル・ネットワークの前記サービス発見ゲートウェイに送信し、前記サービス発見ゲートウェイからの応答として、前記発見情報を受信することを特徴とする請求項８又は９に記載のサービス発見ゲートウェイ（６０２）。
【請求項１１】
前記プレゼンス・ウオッチャ部は、さらに、前記発見情報に対する前記要求を、前記ＩＭＳネットワークのプレゼンスサーバに送信し、前記プレゼンスサーバからの応答として、前記発見情報を受信することを特徴とする請求項８又は９に記載のサービス発見ゲートウェイ（６０２）。
【請求項１２】
前記第２のローカル・ネットワークは、アドホックネットワークであり、
前記第２のローカル・ネットワークの前記サービス発見ゲートウェイは、前記アドホックネットワークの他のデバイスの代わりに前記ＩＭＳネットワークにアクセスするために、マルチメディア・ゲートウェイとして動作するユーザデバイスに実装されることを特徴とする請求項８乃至１１の何れか１項に記載のサービス発見ゲートウェイ（６０２）。
【請求項１３】
携帯ＩＭＳゲートウェイＰＩＧＡが前記ユーザデバイスに実装されることを特徴とする請求項１２に記載のサービス発見ゲートウェイ（６０２）。
【請求項１４】
第２のローカル・ネットワーク内の場所から第１のローカル・ネットワークにおける複数のサービス及び複数のデバイスの遠隔での発見を行なう方法であって、
前記第１のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを使用する発見処理において前記第１のローカル・ネットワークの前記複数のサービス及び前記複数のデバイスの発見情報を収集するステップと、
ＩＭＳネットワークを介してプレゼンス・メッセージに埋め込まれたジェネリック・フォーマットの前記収集された発見情報を提供することにより、前記第２のローカル・ネットワークのサービス発見ゲートウェイによって、前記第２のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを用いて、前記第２のローカル・ネットワーク内の少なくとも１つのデバイスに前記発見情報を報知させるステップと
を前記第１のローカル・ネットワークのサービス発見ゲートウェイによって実行することを特徴とする方法。
【請求項１５】
前記収集された発見情報は、ローカル・フォーマットで得られ、前記ＩＭＳネットワークを介して提供される前に、前記ジェネリック・フォーマットに変換されることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記プレゼンス・メッセージは、プレゼンス通知メッセージとして、前記第２のローカル・ネットワークの前記サービス発見ゲートウェイに送信されることを特徴とする請求項１４又は１５に記載の方法。
【請求項１７】
前記プレゼンス・メッセージは、プレゼンス公開メッセージとして、前記ＩＭＳネットワークのプレゼンスサーバに送信されることを特徴とする請求項１４又は１５に記載の方法。
【請求項１８】
第１のローカル・ネットワークに接続され、第２のローカル・ネットワーク内の場所から前記第１のローカル・ネットワークにおける複数のサービス及び複数のデバイスの遠隔での発見を行なうサービス発見ゲートウェイ（６００）であって、
前記第１のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを使用する発見処理において前記第１のローカル・ネットワークの前記複数のサービス及び前記複数のデバイスの発見情報を収集する発見部（６００ａ）と、
ＩＭＳネットワークを介してプレゼンス・メッセージに埋め込まれたジェネリック・フォーマットの前記収集された発見情報を提供することにより、前記第２のローカル・ネットワークのサービス発見ゲートウェイによって、前記第２のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを用いて、前記第２のローカル・ネットワーク内の少なくとも１つのデバイスに前記発見情報を報知させるプレゼンス・プレゼンティティ部（６００ｃ）と
を備えることを特徴とするサービス発見ゲートウェイ（６００）。
【請求項１９】
ローカル・フォーマットで得られた前記発見情報を、前記ＩＭＳネットワークを介して提供する前に、前記ジェネリック・フォーマットに変換する変換部（６００ｂ）をさらに備えることを特徴とする請求項１８に記載のサービス発見ゲートウェイ（６００）。
【請求項２０】
前記プレゼンス・プレゼンティティ部（６００ｃ）は、さらに、前記プレゼンス・メッセージを、プレゼンス通知メッセージとして、前記第２のローカル・ネットワークの前記サービス発見ゲートウェイに送信することを特徴とする請求項１８又は１９に記載のサービス発見ゲートウェイ（６００）。
【請求項２１】
前記プレゼンス・プレゼンティティ部（６００ｃ）は、前記プレゼンス・メッセージを、プレゼンス公開メッセージとして、前記ＩＭＳネットワークのプレゼンスサーバに送信することを特徴とする請求項１８又は１９に記載のサービス発見ゲートウェイ（６００）。
【請求項２２】
第２のローカル・ネットワーク内の場所から第１のローカル・ネットワークにおける複数のサービス及び複数のデバイスの遠隔での発見を行なうためのＩＭＳネットワークのプレゼンスサーバであって、
前記第１のローカル・ネットワークに接続されたサービス発見ゲートウェイからのプレゼンス公開メッセージに埋め込まれたジェネリック・フォーマットで、前記第１のローカル・ネットワークの前記複数のデバイスの発見情報を受信するイベント状態合成部（８０４ａ）と、
プレゼンス購買メッセージに埋め込まれ、前記第２のローカル・ネットワークに接続されたサービス発見ゲートウェイからの前記発見情報に対する要求を受信し、前記要求に応じて、プレゼンス通知メッセージに埋め込まれた前記発見情報を、前記第２のローカル・ネットワークの前記サービス発見ゲートウェイに送信することにより、前記第２のローカル・ネットワークのサービス発見ゲートウェイによって、前記第２のローカル・ネットワーク内で有効なローカル・サービス発見プロトコルを用いて、前記第２のローカル・ネットワーク内の少なくとも１つのデバイスに前記発見情報を報知させるプレゼンス・エージェント（８０４ｃ）と
を備えることを特徴とするプレゼンスサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、異なるローカル・ネットワークにわたるサービスと通信デバイスの遠隔での発見を可能にし、１つのローカル・ネットワーク内のデバイスとの通信を、別の反対側のローカル・ネットワークのデバイスから行うことを可能にするための方法と装置に関するものである。
【背景技術】
【０００２】
ＩＰ（インターネット・プロトコル）を使用する、パケットを基本としたマルチメディア通信のために、多くの種々の異なる通信端末が開発されてきた。これらは、単に「デバイス」と呼ばれることもある。マルチメディアサービスでは、典型的に、ＩＰネットワークを介して、異なるフォーマット及び組み合わせでメディアを伝送することが必要になる。例えば、ＩＰイネーブルの移動端末は、ビデオ及び／又はオーディオ情報等のメディアを、別のＩＰイネーブルの移動端末と交換することができる。或いは、インターネットを介してコンテンツサーバからメディアをダウンロードすることができる。
【０００３】
ＩＰマルチメディアサブシステム（ＩＭＳ）と呼ばれるネットワークアーキテクチャは、マルチメディアサービス及びセッションを扱い、かつ制御するためのプラットフォームとして、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）によって開発された。これは一般に、ＩＭＳネットワークと呼ばれている。したがって、ＩＭＳネットワークは、使用されているアクセス技術に係わらず、種々のアクセスネットワークに接続されたＩＭＳ可能な端末に対してマルチメディア・セッションを開始し、また、制御することができる。ＩＭＳの概念は、主として、移動ＩＰ端末に対してマルチメディアサービスを可能にするものとして考えられているが、固定のＩＰ端末にも使用することができる。
【０００４】
ＩＭＳネットワークにおいて、マルチメディア・セッションは、例えば、Ｐ−ＣＳＣＦ（プロキシ呼セッション制御機能）ノード、Ｓ−ＣＳＣＦ（在圏呼セッション制御機能）ノード、Ｉ−ＣＳＣＦ（問い合わせ呼セッション制御機能）ノード等の、特定のセッション制御ノードによって扱われる。さらに、ＩＭＳネットワークでは、購読データ及び認証データを記憶するために、データベースノードＨＳＳ（ホーム購読サーバ）が使用される。ＩＭＳネットワークはまた、プレゼンスサービス等の種々の異なるマルチメディアサービスを提供するために、種々のアプリケーションサーバを含むことができる。ここでは、端末ユーザは、購読して他のユーザに関する種々の公開された情報を得ることができる。
【０００５】
ＩＭＳプラットフォームによれば、ＳＩＰ（セッション開始プロトコル）と呼ばれる制御プロトコルを利用して、マルチメディア・セッションの開始、操作、終了を行うことができる。したがって、ＩＰ端末又はデバイスは、セッション開始メッセージ「ＳＩＰ＿ｉｎｖｉｔｅ」及び共通応答メッセージ「ＳＩＰ＿２００＿ＯＫ」等の標準ＳＩＰメッセージを使用して、マルチメディア・セッションを確立することができる。
【０００６】
ＳＩＰでは、「セッション記述プロトコル」もまた使用することができ、ＳＩＰメッセージの中に自己包含する実体として埋め込まれて、これから行うべきマルチメディア・セッションに必要な種々の異なる通信パラメータを規定する。このプロトコルは、一般に、例えば、この技術分野で公知の、デバイス機能、メディアのプロパティ、現在使用されているＩＰアドレス等の、セッション設定の手順に必要な情報を提供するのに使用される。
【０００７】
住宅ネットワークやオフィスネットワーク等のＩＰに基づく限定されたローカル・ネットワークやプライベート・ネットワークの中にあるデバイスに対してもまた、ＩＭＳに基づいたサービスを一般に提供することが望ましい。これらはまた、ＬＡＮ（ローカル・エリア・ネットワーク）又はＰＡＮ（プライベート・エリア・ネットワーク）と呼ばれている。本明細書の記載の中では、任意のこのようなネットワークを表すのに「ローカル・ネットワーク」という一般用語を使用する。そして、ローカル・ネットワークの中でＩＰ通信が可能な任意の端末を表すのに、「デバイス」という用語を使用する。このようなローカル・ネットワークでは、ネットワーク内で通信を行うために、ローカルＩＰアドレスがそれぞれのデバイスに対して割り当てられる。しかし、これらは、そのネットワークの外において、ルーティングメッセージ及びデータに対しては使用することができない。
【０００８】
ローカル・ネットワークにおけるデバイスは、固定電話機及び無線電話機、コンピュータ、メディアプレーヤ、サーバ、及び、テレビジョンボックス（これは、セットトップボックスＳＴＢと呼ばれることもある。）を含むことができる。ローカル・ネットワークにおけるデバイスにＩＭＳサービスを提供するために、「ＨＩＧＡ（ホームＩＭＳゲートウェイ）」と呼ばれるマルチメディア・ゲートウェイが規定されている。ＨＩＧＡは、ローカル・ネットワークからＩＭＳネットワークへのＩＭＳ端末をエミュレートして、ローカル・ネットワークにおける任意のデバイスを代表して、ＩＭＳサービスにアクセスすることができる。
【０００９】
ＵＰｎＰ（ユニバーサル・プラグ・アンド・プレイ）は、種々の異なるアクセス技術、オペレーティングシステム、プログラム言語、フォーマット標準、及び、通信プロトコルを使用して、ローカル・ネットワークにおける異なるＩＰデバイスの間の通信を行うための標準デバイスプロトコルを確立するために、ＵＰｎＰフォーラムと呼ばれるマルチベンダ協同制作で開発されたアーキテクチャである。ＵＰｎＰは、デバイスにおける機能、要求条件、利用可能なサービスを含むデバイスプロファイルを記述し交換する標準化した方法を提供する。
【００１０】
ＵＰｎＰはまた、「発見（ｄｉｓｃｏｖｅｒｙ）（又はペアリング（ｐａｉｒｉｎｇ））」と呼ばれる処理をサポートする。この処理では、デバイスがローカル・ネットワークに接続して、ローカルＩＰアドレスを取得し、その名前とＩＰアドレスとを報知し、ネットワーク内の他のデバイスと機能及びサービスの交換を行う。以下の記述では、「発見情報」という用語は、発見処理の間にデバイスの間で通信が行われる、名前、識別子、ローカルＩＰアドレス、記憶されたメディアコンテンツに対するＵＲＩ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）、デバイス機能、及び、利用可能なサービス等の、任意の情報を表す。発見処理はまた、一時的に構成されたアドホックネットワークの中で、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信を使用して行うことができる。
【００１１】
Ｂｌｕｅｔｏｏｔｈ（登録商標）に対しては、発見処理の中でデバイスとそれらのサービスとを発見するために、ＳＤＰ（サービス発見プロトコル）が標準化されている。デバイス機能と利用可能なサービスとは、ＳＤＰによって利用されるＳＤＡＰ（サービス発見アプリケーション・プロトコル）の中で規定することができる。ＺｉｇＢｅｅやＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）等の、他の通信プロトコルを使用するネットワークに対しては、同様のデバイスプロファイルとサービス発見メカニズムが規定されている。
【００１２】
ＤＬＮＡ（デジタル・リビング・ネットワーク・アライアンス）は、ローカル・ネットワークにおけるデバイスからのディジタル・メディア・コンテンツを取得し、記憶し、アクセスするための相互動作のガイドラインを開発している標準化機構である。ＵＰｎＰプロトコルは、ローカル・ネットワーク内のデバイス間で通信を行うための基盤的プロトコルとして、ＤＬＮＡによって利用さていれる。
【００１３】
また、遠隔アクセスを可能とするためのアーキテクチャが規定されるであろう。そこでは、ローカル・ネットワークの外部に位置した遠隔の「ＵＰｎＰデバイス」は、ネットワーク内部のデバイスとメディアを通信することができる。特許文献１（Ｎｏｋｉａ）では、このような遠隔ＵＰｎＰアクセスを行うための、データ／メディア転送チャネルとして、例えば、ＩＰＳｅｃ（ＩＰ  Ｓｅｃｕｒｉｔｙ）を使用して、ＶＰＮ（仮想プライベート・ネットワーク）トンネルを設定するための解決策が記述されている。しかしながら、この解決策は、プライベート・ネットワークの中でのダイナミックＤＮＳ（ドメイン名システム）クライアントへのアクセストともに、ＩＰアドレス分析とＤＮＳ技術を使用する必要がある。
【００１４】
図１は、１つのローカル・ネットワーク１００を示す。このローカル・ネットワークは、家庭用の住宅又はオフィスであり、その中には種々の異なるデバイスがある。これらのデバイスは、図に示されているように、無線電話機、固定電話機、ＴＶ装置、ラップトップコンピュータ、及び、メディアサーバを含む。ネットワーク１００はまた、従来のゲートウェイ１０２を含む。ゲートウェイ１０２は、外部のアクセスネットワーク１０４に接続されて、デバイスに対して他のネットワークへの通信リンクを提供する。これは、「住宅ゲートウェイ（ＲＧＷ）」と呼ばれる。ＲＧＷ１０２は、典型的に、デバイスにローカルＩＰアドレスを割り当てる、ＮＡＴ（ネットワーク・アドレス変換）機能及びローカルＤＨＣＰ（動的ホスト構成プロトコル）サーバを含む。これは本技術分野では公知である。
【００１５】
ローカル・ネットワーク１００は、ＩＭＳネットワーク１０８への接続を行うＨＩＧＡ１０６をさらに含む。ＩＭＳネットワーク１０８の中にはＨＳＳ１１０が示されている。ＨＩＧＡ１０６は、ネットワーク１００の中にある異なるデバイスに対する適切なインタフェースを有し、デバイスに適応したプロトコルを使用する。ＨＩＧＡ１０６は、ＲＧＷ１０２の中に統合することができる。しかし、本記載の中では、論理的に、別個の機能部であると考えられるであろう。
【００１６】
ＨＩＧＡ１０６は、ＩＭＳ＿Ｓｕｂｓｃｒｉｂｅ（購読）及びユーザ／サービスプロファイルに関連したＩＭＳ識別情報１１２を保持する。ＩＭＳ識別情報１１２は、それを使用してＩＭＳネットワーク１０８にアクセスすることができ、対応する購読情報１１４はＨＳＳノード１１０の中に記憶されている。したがって、ユーザは、ＨＩＧＡ１０６を使用することにより、ローカル・ネットワーク１００の中で使用している、ある特定のデバイスから、ＩＭＳネットワークにログオンすることができる。そして、その使用しているデバイスのローカルＩＰアドレスは、ユーザプロファイルに関連づけられるであろう。特許文献２（Ｅｒｉｃｓｓｏｎ）には、ローカル・ネットワークにおけるデバイスが、ＨＩＧＡを使用して、いかにしてＩＭＳサービスを得ることができるかが記述されている。
【００１７】
ＨＩＧＡ１０６が、デバイスに特化したインタフェース／プロトコルを使用してネットワーク１００内のデバイスから、マルチメディアサービスに対する要求を受信するときには、ＨＩＧＡ１０６は、デバイスに代わって、そのサービス要求を有効なＩＭＳ要求（例えば、ＳＩＰ＿Ｉｎｖｉｔｅ）に変換し、それに従って、ＩＭＳネットワーク１０８と適切なＳＩＰメッセージを通信することにより、デバイスに対するセッションを設定する。同様に、ＩＭＳセッションは、ネットワーク１００におけるデバイスと通信するために入力される要求に対して、そのデバイスに関連したＩＭＳ識別子１１２を使用することにより、ＨＩＧＡ１０６によって設定することができる。いずれの場合も、通信されるメディアは、セッション中に、デバイスから又はデバイスへ、ＲＧＷ１０２及びアクセスネットワーク１０４を介してルーティングされる。これらは図の双方向の矢印で示されている。
【００１８】
図１は、さらに、ローカルデバイス１００ａがネットワーク１００の外部に移動し、遠隔デバイス１００ａ’になることを図示している。したがって、遠隔デバイス１００ａ’は、ＩＭＳネットワーク１０８を介してＨＩＧＡ１０６にＳＩＰ＿Ｉｎｖｉｔｅメッセージを送信して、ネットワーク１００内の残ったデバイスの内の１つとメディア通信を開始することができる。したがって、遠隔デバイスは、ＩＭＳネットワークにアクセスするための有効なＩＭＳ識別子を有していなければならない。
【００１９】
１つのローカル・ネットワークの外部に位置する遠隔デバイスから、そのローカル・ネットワーク内のデバイスに通信を行うためには、発見処理の間に、遠隔デバイスは、最初に他方のデバイスに関する知識を取得し、またその逆操作が行われなければならない。デバイスは、ローカル・ネットワークの中で発見処理を実行すると、そのネットワーク内の他のデバイスのローカルＩＰアドレス、名前、及び、機能／サービスに関する知識を有することになる。したがって、デバイスは、ネットワークの中ではメディアコンテンツの交換を行うことができるが、ネットワークの外ではそれができない。これは、ネットワークの外ではそのローカルＩＰアドレスを使用することができないからである。したがって、デバイスがローカル・ネットワークの外に移動して、いずれか他のネットワークに接続したとすれば、当該様式によってでは、もはや最初のネットワーク内のローカルデバイスとは相互に働きかけることができず、発見（ｄｉｓｃｏｖｅｒｙ）メッセージを遠隔で交換することはできない。
【００２０】
さらに、第１のローカル・ネットワークに属するデバイスが、第２のローカル・ネットワークに移動して、第２のネットワークの中で通信を行うために割り当てられたローカルＩＰアドレスを使用する場合には、第１のローカル・ネットワーク内のデバイスと遠隔での発見処理を実行することができない。したがって、遠隔デバイスは、第２のローカル・ネットワークの中に位置するときには、第１のローカル・ネットワーク内のデバイス及びサービスを発見することができず、第１のネットワークに対して自分自身及び自分のサービスを報知することもできない。
【００２１】
遠隔ネットワークにおいてサービスに関する情報を取得して使用し、また、現在接続されているネットワークにおけるローカル・サービスを発見し、そしてさらに、遠隔ネットワークへそのローカル・サービスに関する発見情報を提供するというアプリケーションを、単一のデバイスの上に実現することは複雑でかつ困難なことであろう。現在、異なるサービス発見プロトコル（ＳＤＰ）を使用する、異なるローカル・ネットワークにわたって、サービスを発見して利用するための解決策は得られていない。これは、異なるＳＤＰは互いに互換性がないからである。例えば、サービスの発見のためにＵＰｎＰに基づくＳＤＰをサポートするだけのデバイスは、別のデバイスによって提供されるいずれのＢｌｕｅｔｏｏｔｈ（登録商標）サービスをも利用することができない。これは、別のローカル・ネットワークから遠隔に行う場合も、同一のネットワークの中にいてローカルに行う場合も不可能である。
【００２２】
例えば、サービス受益者がそのネットワークの中で行うであろう様式と基本的に同じ様式で、遠隔ネットワークにおけるデバイス（例えば、メディアサーバ）のサービスを利用するためには、遠隔ネットワークにおけるサービス及びデバイスを、別のローカル・ネットワークの中に位置するデバイス（例えば、移動ＩＭＳ電話機）から発見できることが望ましいであろう。現在のローカル・ネットワークの中で発見されたサービス及びデバイスに関する情報を遠隔のローカル・ネットワークに提供して、遠隔のネットワーク内のサービス受益者からそのローカル・サービスを利用できるようにすることができれば、これも望ましいことであろう。
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】国際公開第２００６／０７９８９１号パンフレット
【特許文献２】国際公開第２００６／０４５７０６号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【００２４】
本発明の目的は、上記で概観した課題の少なくともいくつかを検討することである。さらなる目的は、異なるローカル・ネットワークにわたってデバイス及び／又はサービスの発見を行うための解決策を提供し、マルチメディア・セッションを可能にすることである。これら及びその他の目的は、以下に添付した独立請求項に従った方法と装置とを提供することにより得ることができる。
【課題を解決するための手段】
【００２５】
一の形態によれば、第２のローカル・ネットワーク内の場所から第１のローカル・ネットワーク内の複数のサービス及び複数のデバイスの遠隔での発見を、第２のローカル・ネットワークのサービス発見ゲートウェイによって行なう方法が提供される。本方法では、第１のローカル・ネットワークにおける複数のデバイスの発見情報に対する要求が発行される。この要求は、ＩＭＳネットワークを介して、プレゼンス購買メッセージの中に埋め込まれて送信される。要求に応答して、発見情報が、ＩＭＳネットワークを介して、プレゼンス通知メッセージの中に埋め込まれたジェネリック・フォーマットで受信される。受信された発見情報は、第１のローカル・ネットワークで有効なローカル・サービス発見プロトコルを使用する発見処理において、第１のローカル・ネットワーク内のサービス発見ゲートウェイによって収集されたものである。次に、受信された発見情報は、第２のローカル・ネットワークの中で有効なローカル・サービス発見プロトコルを用いて、第２のローカル・ネットワーク内の少なくとも１つのデバイスに報知される。
【００２６】
別の形態によれば、第２のローカル・ネットワーク内の場所から第１のローカル・ネットワーク内の複数のサービス及び複数のデバイスの遠隔での発見を実行するためのサービス発見ゲートウェイが提供される。サービス発見ゲートウェイは、第２のローカル・ネットワークに接続される。サービス発見ゲートウェイは、第１のローカル・ネットワーク内の複数のデバイスの発見情報に対する要求を発行するプレゼンス・ウオッチャ部を備える。当該要求は、ＩＭＳネットワークを介して、プレゼンス購買メッセージの中に埋め込まれて送信される。プレゼンス・ウオッチャ部は、要求に応答して、ＩＭＳネットワークを介して、プレゼンス通知メッセージの中に埋め込まれた発見情報を受信する。受信された発見情報は、第１のローカル・ネットワークで有効なローカル・サービス発見プロトコルを使用して、第１のローカル・ネットワーク内の対応するサービス発見ゲートウェイによって収集されたものである。第２のローカル・ネットワークのサービス発見ゲートウェイは、報知部をさらに備え、報知部は、第２のローカル・ネットワークの中で有効なローカル・サービス発見プロトコルを使用して、第２のローカル・ネットワーク内の少なくとも１つのデバイスに受信した発見情報を報知する。
【００２７】
第２のローカル・ネットワークのサービス発見ゲートウェイは、変換部をさらに備えることができる。変換部は、第２のローカル・ネットワークにおいて報知を行う前に、発見情報を、ジェネリック・フォーマットから第２のローカル・ネットワークによってサポートされるローカル・フォーマットに変換する。
【００２８】
上記方法と第２のローカル・ネットワークのサービス発見ゲートウェイとにおいては、異なる実施形態が可能である。例えば、発見情報は、第２のローカル・ネットワークにおいて報知を行う前に、ジェネリック・フォーマットから第２のローカル・ネットワークによってサポートされるローカル・フォーマットにさらに変換することができる。
【００２９】
発見情報に対する要求は、第１のローカル・ネットワークの中にあるサービス発見ゲートウェイに送信することができ、発見情報は、そのサービス発見ゲートウェイからの応答として受信される。或いは、発見情報に対する要求は、ＩＭＳネットワークにおけるプレゼンスサーバに送信することができ、発見情報は、そのプレゼンスサーバからの応答として受信される。後者の場合では、プレゼンスサーバは、第１のローカル・ネットワーク内のサービス発見ゲートウェイから、収集された発見情報をプレゼンス公開メッセージの中で受信することができる。
【００３０】
実際には、第２のローカル・ネットワークは、アドホックネットワークであってもよいであろう。そして、第２のローカル・ネットワーク内のサービス発見ゲートウェイは、マルチメディア・ゲートウェイとして動作し、アドホックネットワーク内の他のデバイスの代わりにＩＭＳネットワークにアクセスする、ユーザデバイスに備えられてもよいであろう。その場合には、ユーザデバイスの中に、可搬ＩＭＳゲートウェイ「ＰＩＧＡ」を備えることもできる。
【００３１】
さらに別の形態によれば、第２のローカル・ネットワーク内の場所から第１のローカル・ネットワークの複数のサービス及び複数のデバイスの遠隔での発見を、第１のローカル・ネットワークのサービス発見ゲートウェイによって実行する方法が提供される。本方法では、第１のローカル・ネットワークにおける複数のサービス及び複数のデバイスの発見情報は、第１のローカル・ネットワークで有効なローカル・サービス発見プロトコルを使用して、発見処理の間に収集される。次に、収集された発見情報は、ＩＭＳネットワークを介して、プレゼンス・メッセージの中に埋め込まれてジェネリック・フォーマットで供給される。それにより、第２のローカル・ネットワーク内のサービス発見ゲートウェイは、第２のローカル・ネットワークで有効なローカル・サービス発見プロトコルを使用して、第２のローカル・ネットワーク内の少なくとも１つのデバイスに発見情報を報知することが可能となる。
【００３２】
さらに別の形態によれば、第２のローカル・ネットワーク内の位置から第１のローカル・ネットワーク内の複数のサービス及び複数のデバイスの遠隔での発見を行なうサービス発見ゲートウェイが提供される。サービス発見ゲートウェイは、第１のローカル・ネットワークに接続される。第１のローカル・ネットワークのサービス発見ゲートウェイは、発見部を備え、発見部は、第１のローカル・ネットワークの中で有効なローカル・サービス発見プロトコルを使用して、発見処理の間に、第１のローカル・ネットワークにおける複数のサービス及び複数のデバイスの発見情報を収集する。サービス発見ゲートウェイは、さらにプレゼンス・プレゼンティティ部を備え、プレゼンス・プレゼンティティ部は、ＩＭＳネットワークを介して、プレゼンス・メッセージの中に埋め込んでジェネリック・フォーマットで、収集された発見情報を提供する。それにより、第２のローカル・ネットワーク内のサービス発見ゲートウェイは、発見情報を、第２のローカル・ネットワークで有効なローカル・サービス発見プロトコルを使用して、第２のローカル・ネットワーク内の少なくとも１つのデバイスに報知することが可能となる。
【００３３】
第１のローカル・ネットワークのサービス発見ゲートウェイは、変換部をさらに備えることができる。変換部は、ＩＭＳネットワークを介して発見情報を供給する前に、ローカル・フォーマットで得られた発見情報をジェネリック・フォーマットに変換するよう適合される。
【００３４】
上記方法と第１のローカル・ネットワークのサービス発見ゲートウェイとにおいては、異なる実施形態が可能である。例えば、プレゼンス・メッセージは、反対側の第２のローカル・ネットワーク内のサービス発見ゲートウェイに、プレゼンス通知メッセージとして送信することができる。或いは、プレゼンス・メッセージは、プレゼンス公開メッセージとして、ＩＭＳネットワーク内のプレゼンスサーバに送信することができる。
【００３５】
さらに別の形態によれば、第２のローカル・ネットワーク内の位置から第１のローカル・ネットワーク内のサービス及びデバイスの遠隔での発見を可能とするために、プレゼンスサーバがＩＭＳネットワークに提供される。プレゼンスサーバは、イベント状態合成部を備える。イベント状態合成部は、第１のローカル・ネットワークに接続されたサービス発見ゲートウェイから、第１のローカル・ネットワーク内のデバイスについての発見情報を、プレゼンス公開メッセージの中に埋め込まれてジェネリック・フォーマットで受信する。プレゼンスサーバは、プレゼンス・エージェントをさらに備える。プレゼンス・エージェントは、第２のローカル・ネットワークに接続されたサービス発見ゲートウェイから、プレゼンス購買メッセージの中に埋め込まれた、発見情報に対する要求を受信する。プレゼンス・エージェントは、その要求に応答して、プレゼンス通知メッセージに埋め込まれた発見情報を、第２のローカル・ネットワーク内のサービス発見ゲートウェイへ送信する。これにより、第２のローカル・ネットワーク内のサービス発見ゲートウェイは、第２のローカル・ネットワークで有効なローカル・サービス発見プロトコルを使用して、発見情報を、第２のローカル・ネットワーク内の少なくとも１つのデバイスに報知することが可能になる。
【００３６】
本発明のさらに可能な特徴と利益とは、下記の詳細なる記述で説明される。
【００３７】
本発明は、好適な実施形態と添付の図面とを参照することにより、より詳細に説明される。
【図面の簡単な説明】
【００３８】
【図１】従来技術に係る遠隔デバイスがネットワークの外部の場所から当該ネットワークにアクセスする場合のローカル・ネットワークを示す図である。
【図２】種々の異なる実施形態に係る２つの異なるローカル・ネットワークにわたって複数のサービス及び複数のデバイスの発見を行うための手順を示す、ネットワーク外観を示す図である。
【図３】一実施形態に係る２つの反対側のローカル・ネットワークにわたって遠隔での発見を可能にするための手順を示すフローチャートである。
【図４】別の実施形態に係るピア・ツー・ピアの場合に本発明による解決策をどのように実施できるかを示すシグナリングダイヤグラムである。
【図５】さらに別の実施形態に係るＩＭＳセントリックの場合に本発明による解決策をどのように実施できるかを示すシグナリングダイヤグラムである。
【図６】さらに別の実施形態に係る遠隔での発見に対してピア・ツー・ピアの方法を使用する場合に、２つの反対側のネットワークにおける２つのサービス発見ゲートウェイを示すブロック図である。
【図７】さらに別の実施形態に係る遠隔での発見に対してＩＭＳセントリックの方法を使用する場合に、２つの反対側のネットワークにおける２つのサービス発見ゲートウェイを示すブロック図である。
【図８】さらに別の実施形態に係るサービス発見ゲートウェイを示すブロック図である。
【発明を実施するための形態】
【００３９】
簡単に説明すれば、本発明を使用することにより、１つのローカル・ネットワーク内に位置するデバイスから、もう１つの反対側のローカル・ネットワーク内の複数のサービス及び／又は複数のデバイスの遠隔での発見と利用とが可能になる。２つのローカル・ネットワークは、異なる内部サービス発見プロトコルを使用して、それぞれのネットワーク内で発見情報を通信することができる。この場合に、これらの内部サービス発見プロトコルは互換性がなくとも十分によい。
【００４０】
この解決策では、発見処理は、１つのネットワーク内の１つのデバイスと他方の反対側のネットワーク内の複数のデバイスとの間で実行することができる。この場合、ＩＭＳネットワークにおけるプレゼンス・サービスに対する現行の通信フレームワークを使用して、発見情報を、２つのネットワークの間の「サービス・プレゼンス情報」としてジェネリック・フォーマットで伝達する。
【００４１】
従来から、プレゼンスサービスは、ある特定のクライアントに関する情報を、他のクライアントで利用可能にしたものである。したがって、プレゼンスデータは、プレゼンスサーバの中に記憶され、当該データは購読しているクライアントに提供される。そして、あるアクセス権が、異なるクライアントに対しても課せられる。クライアントのプレゼンスデータは、典型的に、自身の、状態、デバイス機能、地理的位置、及び、興味、職業、スキル、特性、ムード等の他の情報に関することができる。
【００４２】
そして、当該情報は、クライアントに対するプレゼンスデータが、導入、更新、変更、又は削除される毎にクライアント又はアクセスネットワークから受信して、それを公開することを基本として、プレゼンスサーバに記憶される。プレセンスサービスの分野の共通の用語に従えば、プレゼンスデータに購読している、又はプレゼンスデータを要求するクライアントは、「ウォッチャ（Ｗａｔｃｈｅｒ）」と呼ばれる。また、プレゼンスデータを公開するクライアントは、「プレゼンティティ（Ｐｒｅｓｅｎｔｉｔｙ）」と呼ばれる。
【００４３】
「ＳＩＰのためのプレゼンス・イベント・パッケージ」及び「プレゼンスのための共通プロファイル（ＣＰＰ）」は、ＳＩＰへの拡張であり、上記で記述したように、クライアントがプレゼンス情報の公開と受信を行うことを可能にする。さらに、ＳＩＰプレゼンス・イベント・パッケージは、ＩＭＳシステムの中で使用するために、「オープン・モバイル・アライアンス（ＯＭＡ）」及び３ＧＰＰによって採用されている。
【００４４】
従来からプレゼンスコンテキストの中で使用されているＳＩＰメッセージは、プレゼンティティがプレゼンスデータを公開するためにプレゼンスサーバに送信するときの「ＳＩＰ＿Ｐｕｂｌｉｓｈ（公開）」、ウォッチャがプレゼンスデータに購読するときの「ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅ（購読）」、及び、プレゼンスサーバが購読しているウォッチャにプレゼンスデータを送信するときの「ＳＩＰ＿Ｎｏｔｉｆｙ（通知）」を含む。
【００４５】
従って、本解決策は、プレゼンス・フレームワークを利用し、上記で述べたプレゼンス・メッセージは、発見情報を、１つのローカル・ネットワークから別のローカル・ネットワークへ、新しい様式を使用して伝達することができる。したがって、サービス・プレゼンス情報は、通常プレゼンスデータを通信するために使用される、正規のプレゼンス情報データフォーマット（ＰＩＤＦ）に従ってフォーマットすることができ、それが望ましい。
【００４６】
発見処理の間に、２つのローカル・ネットワークの間でＩＭＳネットワークを介して発見情報を伝達するために、ぞれぞれのローカル・ネットワークは、ゲートウェイノードを備える。このゲートウェイノードは、プレゼンス・フレームワークを使用してＩＭＳネットワークを介して反対側のゲートウェイノードと発見情報を通信する。このゲートウェイノードは、以下の記述では、「サービス発見ゲートウェイ（ＳＤＧ）」と呼ぶことにする。例えば、上記で挙げたＳＩＰプレゼンス・イベント・パッケージは、サービス発見ゲートウェイの間で発見情報を伝達するためのフレームワークとして使用することができる。
【００４７】
片方又は両方のサービス発見ゲートウェイは、いかなるローカル・サービス発見プロトコルがローカル・ネットワークの中で使用されていても、両者の間の発見メッセージを変換するようさらに適合されることが望ましい。そして、この場合は、ジェネリック・サービス発見フォーマットはプレゼンス・フレームワークの中に埋め込まれる。本明細書の記載では、「ジェネリック・フォーマット」という用語は、当該フォーマットが両方のサービス発見ゲートウェイによって理解されてサポートされるということを示す。
【００４８】
それぞれのローカル・ネットワーク内のサービス発見ゲートウェイは、ＩＭＳネットワークを介して、発見情報をジェネリック・サービス発見フォーマットで通信するようさらに適合される。ここで、発見情報（例えば、サービス記述とデバイス機能）は、プレゼンス・フレームワークの正規メッセージの中に埋め込まれる。したがって、それぞれのサービス発見ゲートウェイは、それぞれのローカル・ネットワークの中で使用されるサービス発見プロトコルに依存せずに、またＩＭＳを通した通信に対するプレゼンス・メッセージ（例えば、ＳＩＰに従った）に依存せずに、事実上、それらの間のゲートウェイとして動作する。
【００４９】
例えば、正規のプレゼンス・メッセージ「ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅ」は、それを使用して、１つのローカル・ネットワークから、反対側のローカル・ネットワーク内のデバイスに関する発見情報の要求を伝達し、取得することができる。さらに、正規のプレゼンス・メッセージ「ＳＩＰ＿Ｎｏｔｉｆｙ」は、それを使用して、１つのローカル・ネットワーク内の１つ以上のデバイスに関して報知された発見情報を、他方の反対側のローカル・ネットワークに伝達することができる。さらに、プレゼンス・フレームワークによって発見情報の収集と配信とを行うために、ＩＭＳネットワークの中でプレゼンスサーバが使用される場合には、正規のプレゼンス・メッセージ「ＳＩＰ＿Ｐｕｂｌｉｓｈ」を使用して、公開された発見情報をプレゼンスサーバに伝達することができる。
【００５０】
従って、プレゼンスという立場からすると、事実上、双方のローカル・ネットワークにおけるサービス発見ゲートウェイは、反対側のネットワークに発見情報を提供するときには、プレゼンティティとして動作し、反対側のネットワークに発見情報を要求し、それを取得するときには、ウォッチャとして動作するであろう。
【００５１】
それぞれのローカル・ネットワークの中では、ローカル・ネットワークにおける複数のデバイス及び複数のサービスの型に依存した１つ以上のサービス発見プロトコルが使用される。したがって、同一のローカル・ネットワークの中における異なるデバイスに対して、複数のサービス発見プロトコルが使用されることがある。ここでは、サービス発見ゲートウェイがそれらのサービス発見プロトコルのそれぞれをジェネリック・フォーマットに、及びその逆に、変換することができる。ローカル・ネットワーク内の２つのサービス発見ゲートウェイは、基本的に、論理的に同一の様式で構成することができる。すなわち、双方とも、発見情報を遠隔から供給及び取得することができる。しかし、実際には異なった様式で実施することもできる。
【００５２】
一例として、サービス発見ゲートウェイは、住宅ローカル・ネットワークの中で、ＨＩＧＡ又はＲＧＷの中で実施することができる（例えば、ＵＰｎＰ、Ｚｉｇｂｅｅ、又はＩｒＤＡに基づいたサービス発見プロトコルを使用して）。一方、反対側のネットワークの他のサービス発見ゲートウェイは、ローカル・アドホックネットワークに一時的に存在する移動ユーザ端末の中で実施することができるであろう（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）に基づいたサービス発見プロトコルを使用して）。その場合、移動ユーザ端末は、サービス発見ゲートウェイとして動作し、ＩＭＳネットワークと通信を行うためには、ＩＭＳクライアントとサービス発見プロトコルの間の変換を行うための機能とを含まなければならない。
【００５３】
従って、移動ユーザ端末は、ＩＭＳでないデバイスを代表してアドホックネットワークの中でＩＭＳセッションを設定するために、ＨＩＧＡの機能を有することができる。これは、「ＰＩＧＡ、Ｐｏｒｔａｂｌｅ  ＩＭＳ  Ｇａｔｅｗａｙ」と呼ばれる。移動端末にＰＩＧＡとサービス発見ゲートウェイとを備えることにより、このようなアドホックネットワークにおいてサービス及びデバイスを発見すること、遠隔のサービス発見ゲートウェイに、又はＩＭＳセントリック・プレゼンスサーバに情報を提供すること、また、このようなサービスを公開して他のローカル・ネットワークで利用可能にすることも可能になるであろう。
【００５４】
１つのローカル・ネットワークにおけるウォッチング・サービス発見ゲートウェイは、取得した発見情報を使用して反対側のローカル・ネットワーク内のデバイスとサービス利用セッションを確立することができる。双方のノードは、サービス情報を利用するためには、ジェネリック・サービス記述フォーマットをサポートしなければならない。２つの反対側にあるローカル・ネットワークにおける２つのデバイスの間のメディアセッションに対するサービス利用プロトコル（例えば、ＨＴＴＰストリーミング、ＲＴＳＰストリーミング、ＦＴＰ等）は、特定のサービス及び／又はアプリケーションに依存する。そして、そのプロトコルは双方のデバイスによってサポートされなければならない。
【００５５】
図２には、第１のローカル・ネットワーク２００内のデバイスと反対側の第２のローカル・ネットワーク２０２内のデバイスとの間で発見情報を伝達するための典型的なシナリオと処理とが示されている。発見情報の伝達は、いずれかのローカル・ネットワークにおけるサービス発見ゲートウェイを使用して、ＩＭＳネットワーク２０４を介してプレゼンス・フレームワークによって行われる。この例では、第２のネットワーク２０２の中にあるメディアプレーヤ２０２ａは、第２のネットワークでメディアを提示するために、第１のネットワーク内のメディアサーバ２００ａに記憶されているメディアを取り出してくるであろう。
【００５６】
ローカル・ネットワーク２００とローカル・ネットワーク２０２とは、限定されたサービスの「島」であると考えることができる。ここでは、個々のローカルデバイスで利用可能な異なるサービスは、それぞれのサービスの島の中にあるローカルデバイスの間で共有することができる。本明細書の記載では、ローカル・ネットワークとはこのようなサービスの島を意味する。
【００５７】
従って、第１のネットワーク２００は、ネットワーク２００の外部とメディアの通信を行うための、第１のサービス発見ゲートウェイ２００ｂと、可能ならば、ＲＧＷ２００ｃとを備える。一方、第２のネットワーク２０２は、同様に、第２のサービス発見ゲートウェイ２０２ｂと、可能ならば、ＲＧＷ２０２ｃとを備える。ネットワーク２００及びネットワーク２０２のそれぞれはまた、ＩＭＳネットワーク２０４を介して通信を行うために、例えば、ＨＩＧＡ又はＩＭＳユーザ端末内のＩＭＳクライアントへの接続を有していなければならない。ただし、ここでは、ＩＭＳクライアントは論理的に、図示されたサービス発見ゲートウェイ２００ｂ及びサービス発見ゲートウェイ２０２ｂに存在すると仮定されている。
【００５８】
図に示すように、第１のローカル・ネットワーク２００は、発見手順を実行するために、ネットワーク２００で有効な１つ以上の内部サービス発見プロトコルＳＤＰ１及びＳＤＰ２を使用する。一方、第２のローカル・ネットワーク２０２は、ネットワーク２０２で有効な別の内部サービス発見プロトコルＳＤＰ３を使用する。内部サービス発見プロトコルＳＤＰ３は、第１のネットワーク２００で使用されるものと比較して異なっていても、互換性がなくともよい。しかし必ずしもそうでなくともよい。発見手順は、２つのローカル・ネットワーク２００及び２０２にわたって実行することができ、これに関しては下記で記述する。
【００５９】
第２のネットワークのサービス発見ゲートウェイ２０２ｂは、アドレスｓｄｇ２＠ｙｙｙ．ｃｏｍを使用して、反対側のネットワーク２００からの発見情報に対する要求を、プレゼンス・フレームワークの中に埋め込んで発行することができる。発見情報要求は、ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージの形で送信することができる。これは、事実上は、ネットワーク２００のサービス発見ゲートウェイ２００ｂからの「サービス・プレゼンス・イベント」にＳｕｂｓｃｒｉｂｅすることになる。ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージは以下のように設定することができるであろう。
【００６０】
メッセージ例１
ＳＵＢＳＣＲＩＢＥ  ｓｉｐ：ｓｄｇ１＠ｘｘｘ．ｃｏｍ  ＳＩＰ／２．０
Ｆｒｏｍ：＜ｓｉｐ：ｓｄｇ２＠ｙｙｙ．ｃｏｍ＞
Ｔｏ：＜ｓｉｐ：ｓｄｇ１＠ｘｘｘ．ｃｏｍ＞
Ｅｖｅｎｔ：ｐｒｅｓｅｎｃｅ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
このメッセージの中には、さらなる実体を含む必要はない。ただし、要求したサービス・プレゼンス情報に対する任意選択（オプション）のフィルタがこのメッセージの中に規定されてもよい。そして、上記のＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージは、アドレスｓｄｇ１＠ｘｘｘ．ｃｏｍを使用して、反対側のネットワーク２００のサービス発見ゲートウェイ２００ｂに向けて送信される。したがってほぼ直接的に行われる。
【００６１】
上述したように、ＩＭＳネットワークに中間プレゼンスサーバを設けて、種々のローカル・ネットワークの間で、サービス・プレゼンス情報を収集及び配信することも可能である。したがって、ＩＭＳネットワークにおけるプレゼンスサーバを使用することにより、基本的には、単に２つのローカル・ネットワークだけではなく、それ以上の数のローカル・ネットワークにわたる発見手順が可能になるであろう。この場合には、プレゼンスサーバ２０４ａは、アドレスｓｐｓ＠ｘｙｚ．ｃｏｍを有する。また、サービス発見ゲートウェイ２０２ｂからの、プレゼンスサーバ２０４ａに対するＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージは、以下のように構成することができるであろう。
【００６２】
メッセージ例２
ＳＵＢＳＣＲＩＢＥ  ｓｉｐ：ｓｐｓ＠ｘｙｚ．ｃｏｍ  ＳＩＰ／２．０
Ｆｒｏｍ：＜ｓｉｐ：ｓｄｇ２＠ｙｙｙ．ｃｏｍ＞
Ｔｏ：＜ｓｉｐ：ｓｐｓ＠ｘｙｚ．ｃｏｍ＞
Ｅｖｅｎｔ：ｐｒｅｓｅｎｃｅ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
上記のＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージは、このように、プレゼンスサーバ２０４ａに向けて送信され、従って、発見処理は「ＩＭＳセントリック」であると考えることができる。ピア・ツー・ピアの場合と同様に、このメッセージの中にはさらなる実体を含む必要はない。
【００６３】
さらに、ＩＭＳセントリックの解決策が使用される場合には、第１のネットワーク２００内のサービス発見ゲートウェイ２００ｂは、発見処理の間にネットワーク２００の中でローカルに発見情報を取得した後に、ＳＩＰ＿Ｐｕｂｌｉｓｈメッセージをプレゼンスサーバ２０４ａに送信することにより、ネットワーク２００の複数のデバイスに関する発見情報を公開することができる。最初に、サービス発見ゲートウェイ２００ｂは、ローカルに取得した発見情報を、ローカル・サービス記述フォーマットから、必要に応じて、双方のサービス発見ゲートウェイ２００ｂ及び２０２ｂが理解する、ジェネリック・サービス記述フォーマットに変換する。しかしながら、いくつかの場合には、ローカル発見情報は、既に、双方のネットワークが理解するサービス記述フォーマット（すなわち、ジェネリック・フォーマット）になっていて、変換を行う必要がなければ、変換せずにプレゼンス・メッセージの中に埋め込むことができる。したがって、ＩＭＳセントリックの場合におけるサービス発見ゲートウェイ２００ｂからのＳＩＰ＿Ｐｕｂｌｉｓｈメッセージは、以下のように構成できるであろう。
【００６４】
メッセージ例３
ＰＵＢＬＩＳＨ  ｓｉｐ：ｓｐｓ＠ｘｙｚ．ｃｏｍ  ＳＩＰ／２．０
Ｆｒｏｍ：＜ｓｉｐ：ｓｄｇ１＠ｙｙｙ．ｃｏｍ＞
Ｔｏ：＜ｓｉｐ：ｓｐｓ＠ｘｙｚ．ｃｏｍ＞
Ｅｖｅｎｔ：ｐｒｅｓｅｎｃｅ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｅｎｔｉｔｙ−ｂｏｄｙ−ｌｅｎｇｔｈ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｐｉｄｆ＋ｘｍｌ
＜ｘｍｌ  ｖｅｒｓｉｏｎ＝“１．０”＞
ＸＭＬ（拡張マークアップ言語）フォーマットのこの例では、上記のあとに、ジェネリック・サービス発見フォーマットに従った、公開された発見情報を含む実体が続く。このように、発見情報は、プレゼンス・フレームワークに従って、特に、ＳＩＰに対してはプレゼンス・イベント・パッケージに従って、サービス・プレゼンス情報として扱われる。サービス・プレゼンス情報は、従って、プレゼンス情報データフォーマット（ＰＩＤＦ）に整合するようフォーマットされる。
【００６５】
そして、上記のＳＩＰ＿Ｐｕｂｌｉｓｈメッセージは、このように、ＩＭＳネットワーク２０４内のプレゼンスサーバ２０４ａに向けて送信される。プレゼンスサーバ２０４ａは、ＳＩＰ＿Ｎｏｔｉｆｙメッセージを、第２のネットワーク２０２内のＳｕｂｓｃｒｉｂｅ（購読）しているサービス発見ゲートウェイ２０２ｂにさらに送信することにより、公開された発見情報を配信するであろう。したがって、ＩＭＳセントリックの場合におけるプレゼンスサーバ２０４ａからのＳＩＰ＿Ｎｏｔｉｆｙメッセージは、以下のように構成することができるであろう
メッセージ例４
ＮＯＴＩＦＹ  ｓｉｐ：ｓｄｇ２＠ｘｘｘ．ｃｏｍ  ＳＩＰ／２．０
Ｆｒｏｍ：＜ｓｉｐ：ｓｐｓ＠ｘｙｚ．ｃｏｍ＞
Ｔｏ：＜ｓｉｐ：ｓｄｇ２＠ｘｘｘ．ｃｏｍ＞
Ｅｖｅｎｔ：ｐｒｅｓｅｎｃｅ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｅｎｔｉｔｙ−ｂｏｄｙ−ｌｅｎｇｔｈ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｐｉｄｆ＋ｘｍｌ
＜ｘｍｌ  ｖｅｒｓｉｏｎ＝“１．０”＞
上記のあとに、ジェネリック発見情報として、ＸＭＬフォーマットの発見情報を含む実体が続く。
【００６６】
一方、もし、ピア・ツー・ピアの解決策が使用されるならば、すなわち、プレゼンスサーバ２０４ａが関与しなければ、第１のネットワーク２００内のサービス発見ゲートウェイ２００ｂは、上記例１のＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージの受信に応答して、そして、ネットワーク２００の中でローカルに発見情報を取得した後に、発見情報を含むＳＩＰ＿Ｎｏｔｉｆｙメッセージを、Ｓｕｂｓｃｒｉｂｅ（購読）しているサービス発見ゲートウェイ２０２ｂに直接に送信することができる。したがって、ピア・ツー・ピアの場合におけるサービス発見ゲートウェイ２００ｂからのＳＩＰ＿Ｎｏｔｉｆｙメッセージは以下のように構成できるであろう。
【００６７】
メッセージ例５
ＮＯＴＩＦＹ  ｓｉｐ：ｓｄｇ２＠ｘｘｘ．ｃｏｍ  ＳＩＰ／２．０
Ｆｒｏｍ：＜ｓｉｐ：ｓｄｇ１＠ｙｙｙ．ｃｏｍ＞
Ｔｏ：＜ｓｉｐ：ｓｄｇ２＠ｘｘｘ．ｃｏｍ＞
Ｅｖｅｎｔ：ｐｒｅｓｅｎｃｅ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｅｎｔｉｔｙ−ｂｏｄｙ−ｌｅｎｇｔｈ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｐｉｄｆ＋ｘｍｌ
＜ｘｍｌ  ｖｅｒｓｉｏｎ＝“１．０”＞
この場合も同様に、上記のあとに、ジェネリック発見情報として、ＸＭＬフォーマットの発見情報を含む実体が続く。
【００６８】
いずれの場合も、サービス発見ゲートウェイ２０２ｂは、第１のネットワーク２００内のデバイスに関する発見情報を、反対側のサービス発見ゲートウェイ２００ｂから直接に、又はプレゼンスサーバ２０４ａから、最終的に受信したことになる。そして、この情報は、例えば、ジェネリック・フォーマットで受信した発見情報を、必要に応じて、いずれかの有効なローカル・サービス発見プロトコルに変換した後に、ローカル発見処理の中で第２のネットワーク２０２内の任意のデバイスに提供することができる。さらに、ネットワーク２００の中でサービスの状態が変化した場合には、サービス発見ゲートウェイ２００ｂ（プレゼンティティ）は、例えば、サービス発見ゲートウェイ２０２ｂが購読しているイベントに従って、「サービス・プレゼンス・イベント」として、その変化に関してサービス発見ゲートウェイ２０２ｂ（ウォッチャ）に通知することができる。
【００６９】
第１のローカル・ネットワーク内の複数のサービス及び複数のデバイスを、第２のローカル・ネットワーク内の場所から遠隔で発見することを可能にする手順について、図３のフローチャートを参照して説明を行う。図示されたステップは、第２のローカル・ネットワーク内のサービス発見ゲートウェイによって実行される。
【００７０】
第１のステップ３００では、第１のローカル・ネットワーク内の複数のデバイス及び複数のサービスに関する発見情報に対する要求が、ＩＭＳネットワークを介して、プレゼンス・フレームワークを使用して第２のローカル・ネットワーク内のサービス発見ゲートウェイから発行される。発見情報要求は、図２に対して上述したように、ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージとして送信することができる。これは、プレゼンス・フレームワークに従ってサービス・プレゼンス情報及びイベントにＳｕｂｓｃｒｉｂｅ（購読）するために、反対側の第１のローカル・ネットワーク内の対応するサービス発見ゲートウェイに対して直接的に、又は、ＩＭＳネットワーク内の中間プレゼンスサーバに送信することができる。
【００７１】
次のステップ３０２では、発見情報は、発見情報要求に応答して、ＩＭＳネットワークを介してジェネリック・フォーマットで受信される。図２に対して上述したように、発見情報は、ピア・ツー・ピアの場合には、第１のローカル・ネットワーク内のサービス発見ゲートウェイから直接的に受信することができる。又は、ＩＭＳセントリックの場合には、ＩＭＳネットワーク内のプレゼンスサーバから受信することができる。発見情報要求は、図２に対して上述したように、ＳＩＰ＿Ｎｏｔｉｆｙメッセージとして受信されてもよい。
【００７２】
さらにステップ３０４では、受信した発見情報を、ジェネリック・フォーマットから、サービス発見手順に対して第２のネットワークにおいて使用されているローカル・サービス発見プロトコルに従ったローカル・サービス記述フォーマットに変換する必要があるかどうかが判定される。もし必要であれば、発見情報は次のステップ３０６において、最初に、第２のネットワーク内の少なくとも１つのデバイスでローカル発見手順を実行するために有効なローカル・サービス記述フォーマットに変換される。そして、変換された発見情報は、ステップ３０８における正規のローカル発見手順の間に、第１のローカル・ネットワーク内のデバイスに最終的に提供される。ステップ３０４において、ジェネリック・フォーマットで受信した発見情報の変換の必要がなければ、処理は、第１のローカル・ネットワーク内のデバイスに発見情報を提供するステップ３０８に直接的に移動することができる。
【００７３】
複数のサービス及び複数のデバイスの遠隔での発見に対する典型的なメッセージフローに関し、図４のシグナリングダイヤグラムを参照して説明を行う。ここでは、上述したピア・ツー・ピアの方法に基づいて、第１のローカル・ネットワーク内の複数のサービス及び複数のデバイスを反対側の第２のローカル・ネットワークの場所から遠隔で発見する。当業者には、図中に示されるそれぞれのシグナリングステップが、使用するプロトコルに従って相互に転送する１つ以上の特定のメッセージを表すと理解されるであろう、という点に注意を要する。
【００７４】
第１のステップ４：１では、発見処理（Ｄｉｓｃｏｖｅｒｙ）は、第１のネットワーク４００で何回か実行され、複数のデバイス及び複数のサービス４００ａとサービス発見ゲートウェイ４００ｂとに関わる。その結果、サービス発見ゲートウェイ４００ｂは、複数のデバイス及び複数のサービス４００ａに関する発見情報を取得又は収集する。発見処理では、ローカル・サービス発見プロトコルが使用され、サービス発見ゲートウェイ４００ｂによって取得された発見情報は、反対側のネットワーク４０２では理解されない可能性がある。
【００７５】
第２のローカル・ネットワーク４０２は、少なくとも１つのデバイス４０２ａと別のサービス発見ゲートウェイ４０２ｂとを備える。次のステップ４：２において、サービス発見ゲートウェイ４０２ｂは、第１のローカル・ネットワーク４００内の複数のデバイス及び複数のサービスに関する発見情報の要求として、プレゼンス・フレームワークに従ったＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージ（ＳＩＰ購読メッセージ）を、サービス発見ゲートウェイ４００ｂに直接送信する。必要に応じて、サービス発見ゲートウェイ４００ｂは、ステップ４：３において変換（Ｔｒａｎｓｌａｔｅ）を行う。ステップ４：１で取得された発見情報は、サービス発見ゲートウェイ４００ｂ及び４０２ｂの双方が理解するジェネリック・フォーマットに変換される。
【００７６】
そして、サービス発見ゲートウェイ４００ｂは、次のステップ４：４で、ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージに応答して、変換された発見情報を含むＳＩＰ＿Ｎｏｔｉｆｙメッセージ（ＳＩＰ通知メッセージ）を送信する。
【００７７】
さらに示されるステップ４：５では、どのくらいか遅れて第１のネットワーク４００の中で別の発見処理（Ｄｉｓｃｏｖｅｒｙ）が生ずるかもしれないことを示している。例えば、ある所定のスキームに従って、又は、いずれかのデバイス及びサービスが、加えられ、取り除かれ、又は変更されて、発見情報が更新されるごとに別の発見処理が生ずる可能性がある。サービス発見ゲートウェイ４０２ｂは、ネットワーク４００のサービス発見情報にＳｕｂｓｃｒｉｂｅ（購読）しているので、さらなるステップ４：６で、サービス発見ゲートウェイ４００ｂは新しく取得した発見情報を変換（Ｔｒａｎｓｌａｔｅ）することになる。そして、変換されて更新された発見情報は、更なるステップ４：７においてサービス発見ゲートウェイ４０２ｂに送信（Ｎｏｔｉｆｙ）されることになる。
【００７８】
ステップ４：４又はステップ４：７のどちらかのステップの後に、サービス発見ゲートウェイ４０２ｂは、ネットワーク４０２の中でローカルに発見処理を実行し、受信した発見情報を、第２のローカル・ネットワーク４０２で有効なローカル・サービス発見プロトコルを使用して、第２のローカル・ネットワーク内の少なくとも１つのデバイスに提供することができる。したがって、サービス発見ゲートウェイ４０２ｂは、ステップ４：８に示すように、最後に示したステップ４：９においてネットワーク４０２内の少なくとも１つのデバイスに関わる発見処理を実行する以前に、受信した発見情報を、ジェネリック・フォーマットから、ネットワーク４０２内で有効なローカル・サービス記述フォーマットに変換（Ｔｒａｎｓｌａｔｅ）する必要があるかもしれない。
【００７９】
以上のように、図４の例は、「サービス・プレゼンス・イベント」は、上述したピア・ツー・ピアの方法に基づき、プレゼンスサーバ等の任意のＩＭＳネットワーク機能には関わりなく、サービス発見ゲートウェイ４００ｂ及びサービス発見ゲートウェイ４０２ｂの間で扱われる。したがって、プレゼンスの立場からすると、サービス発見ゲートウェイ４００ｂは、「サービス・プレゼンス・イベント・ハンドラ」として動作する。しかしながら、サービス発見ゲートウェイ４００ｂとサービス発見ゲートウェイ４０２ｂとの間のＳＩＰシグナリングは、当然のことながら、ＩＭＳネットワーク内の適切なセッション制御ノード（図示せず）に渡されるであろう。特に、ＩＭＳネットワークは、エンド・ツー・エンドＳＩＰメッセージのアドレス指定及びモビリティ・サポートと共に、識別、認証、アクセス制御に使用することができる。
【００８０】
サービス及びデバイスの遠隔での発見に対する、上述したＩＭＳセントリックの方法に基づいた別の典型的な手順とメッセージフローは、図５におけるシグナリングダイヤグラムを参照して以下で説明される。再び、図中に示すいずれのシグナリングステップも、使用されるプロトコルに依存して、１つ以上の特定のメッセージを表現することができる。
【００８１】
従って、それぞれ、第１のローカル・ネットワークＡ及び第２のローカル・ネットワークＢ内の、２つの反対側のサービス発見ゲートウェイ５００及びサービス発見ゲートウェイ５０２は、どちらも、プレゼンス・フレームワークに従ったＳＩＰシグナリングを使用して、ＩＭＳネットワークにおけるプレゼンスサーバ５０４と通信を行うよう適合され、双方のサービス発見ゲートウェイ５００及び５０２が理解するジェネリック・フォーマットで発見情報を伝達する。この例では、図示された処理は、２つの平行した部分を有すると見ることができる。すなわち、１つは「ａ」と表記され、公開された発見情報を、プレゼンスサーバ５０４が第１のネットワークＡから利用可能とするためのものであり、もう一方は、「ｂ」と表記され、第２のネットワークＢに発見情報を提供するためのものである。
【００８２】
図中の双方向矢印Ｄは、一般的に、それぞれ、ローカル・ネットワークＡ及びローカル・ネットワークＢの中でローカルに実行される発見処理を表す。第１のステップ５：１ａでは、サービス発見ゲートウェイ５００は、発見処理Ｄの間に取得した発見情報を、ジェネリック・フォーマットに変換（Ｔｒａｎｓｌａｔｅ）し、引き続くステップ５：２ａで、変換された発見情報を含むＳＩＰ＿Ｐｕｂｌｉｓｈメッセージ（ＳＩＰ公開メッセージ）を、プレゼンスサーバ５０４に送信する。発見Ｄに引き続くステップ、すなわち、変換のステップ５：３ａ及びＳＩＰ＿Ｐｕｂｌｉｓｈメッセージを送信するステップ５：４ａは、基本的には、発見情報が更新される毎に行われる、これまでのステップの繰り返しである。このように、プレゼンスサーバ５０４は、第１のローカル・ネットワークに関する、更新された最新の発見情報を保持するであろう。
【００８３】
処理の他方の部分「ｂ」は、サービス発見ゲートウェイ５０２が、ステップ５：１ｂにおいて、ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージ（ＳＩＰ購読メッセージ）をプレゼンスサーバ５０４に送信し、事実上、第１のローカル・ネットワーク内のデバイス及びサービスに関する発見情報を要求するステップを含む。サービス発見ゲートウェイ５００が、これまでに、いずれかの発見情報を公開している場合には、プレゼンスサーバ５０４は、ステップ５：２ｂにおいて、例えば、上記に挙げたメッセージ例４に従って、現在の発見情報を含むＳＩＰ＿Ｎｏｔｉｆｙメッセージ（ＳＩＰ通知メッセージ）を、ジェネリック・フォーマットで送信するであろう。
【００８４】
その後の適宜な時間に、プレゼンスサーバ５０４は、ステップ５：３ｂ及び５：５ｂで例示したように、さらなるＳＩＰ＿Ｎｏｔｉｆｙメッセージを送信することができる。この送信は、サービス発見ゲートウェイ５００からのＳＩＰ＿Ｐｕｂｌｉｓｈメッセージをステップ５：２ａ及び５：４ａにおいて受信することにより発見情報が更新される毎に行われる。第２のローカル・ネットワークＢの中で発見処理を実行するために、サービス発見ゲートウェイ５０２は、その結果、ステップ５：４ｂに示すように、サービス発見手順のために第２のネットワークＢにおいて使用されているローカル・サービス発見プロトコルに従って、取得した発見情報をローカル・サービス記述フォーマットに変換することになるであろう。その後、ローカル発見手順Ｄは、第２のネットワークＢの中で実行することができる。これは双方向の矢印で示されている。
【００８５】
発見Ｄ内の部分「ａ」における処理、すなわち、変換（ステップ５：１ａ及びステップ５：３ａ）とＳＩＰ＿Ｎｏｔｉｆｙメッセージの送信（ステップ５：２ａ及びステップ５：４ａ）とは、基本的に、部分「ｂ」における活動に関わりなく実行することができる、すなわち、いつ発見情報が更新されるかという点だけに依存して実行することができる、ということに注意を要する。しかしながら、ＳＩＰ＿Ｎｏｔｉｆｙメッセージ（例えば、ステップ５：３ｂ及びステップ５：５ｂ）は、ＳＩＰ＿Ｐｕｂｌｉｓｈメッセージ（例えば、ステップ５：２ａ及びステップ５：４ａ）の受信に応答して、プレゼンスサーバ５０４から送信することができる。したがって、ステップ５：５ｂの後に、サービス発見ゲートウェイ５０２の中で、さらなる変換ステップ（図示せず）を実行し、引き続いて別の発見処理等を実行することができる。
【００８６】
このように、図５の事例は、上記したＩＭＳセントリックの方法に基づいており、「サービス・プレゼンス・イベント」の管理は、プレゼンスサーバ５０４によって行われ、プレゼンスサーバ５０４は、事実上、ＩＭＳネットワークにおける「サービス・プレゼンス・イベント・ハンドラ」又は「サービス・プレゼンス・イベント管理サーバ」として動作する。
【００８７】
遠隔での発見に対して中間プレゼンスサーバを使用する１つの利点は、一般的に、１つのプレゼンティティ・ローカル・ネットワークの公開された発見情報を、現行のプレゼンス処理機能を使用して、他の任意の数のウォッチャ・ローカル・ネットワークから、容易に利用できるようにするという点である。正規のプレゼンス手順の場合と同様の様式で、異なるウォッチャに対して、異なるフィルタを適用することも可能である。さらに、ＩＭＳネットワークにおけるプレゼンスサーバは、一般的に、処理及び記憶容量に関して、典型的に小さいローカル・ネットワークにおける資源が限定的なゲートウェイ及びデバイスと比較して、より強力であると考えられる。
【００８８】
次に、２つのサービス発見ゲートウェイがあり、これらのサービス発見ゲートウェイは、それぞれ反対側のローカル・ネットワークの中にあって、基本的に上述した様式で遠隔での発見を実行するよう適合されている場合に関して詳しい説明を行う。説明は、図６に示したブロック図を参照して行う。図６は、純粋に論理的に、異なる機能部を示したものであることに注意を要する。当業者は、例えばハードウェア及びソフトウェアを使用して、実際には任意の適切な様式により、これらの機能を実施することができるであろう。上述したこれまでの事例のように、第１のローカル・ネットワークの第１のサービス発見ゲートウェイ６００は、プレゼンティティとして動作し、ウォッチャとして動作する第２のローカル・ネットワークの第２のサービス発見ゲートウェイ６０２に、ＩＭＳネットワークを介して、プレゼンス・フレームワークのメッセージを使用して、発見情報を遠隔から提供する。
【００８９】
第１のサービス発見ゲートウェイ６００は、自分のローカル・ネットワーク（図示せず）の中で発見処理Ｄを実行することにより発見情報を取得するサービス及びデバイス発見部６００ａを備える。変換部６００ｂは、サービス及びデバイス発見部６００ａによって取得された発見情報を、必要に応じて、第１のネットワークの中で使用されているローカル・サービス記述フォーマットから、双方のサービス発見ゲートウェイ６００及び６０２が理解するジェネリック・フォーマットに変換する。
【００９０】
サービス発見ゲートウェイ６００は、「プレゼンス・プレゼンティティ」と呼ばれる機能部６００ｃをさらに備える。プレゼンス・プレゼンティティ６００ｃは、プレゼンス・フレームワークに従って、変換された発見情報を送信する。この発見情報は、ＳＩＰ＿Ｎｏｔｉｆｙメッセージの中で、反対側のサービス発見ゲートウェイ６０２へ直接に送信されるか（ピア・ツー・ピアの場合）、又は、ＳＩＰ＿Ｐｕｂｌｉｓｈメッセージの中で、ＩＭＳネットワークにおける中間プレゼンスサーバ６０４に送信される（ＩＭＳセントリックの場合）。
【００９１】
さらに、第２のサービス発見ゲートウェイ６０２は、「プレゼンス・ウオッチャ」と呼ばれる機能部６０２ａを備える。プレゼンス・ウオッチャ６０２ａは、ＳＩＰ＿Ｎｏｔｉｆｙメッセージの中にあるジェネリック・フォーマットの発見情報を受信する。この発見情報は、反対側のサービス発見ゲートウェイ６００のプレゼンス・プレゼンティティ６００ｃから直接的に受信されるか（ピア・ツー・ピアの場合）、又は、プレゼンスサーバ６０４から受信される（ＩＭＳセントリックの場合）。変換部６０２ｂは、プレゼンス・ウオッチャ６０２ａによって受信された発見情報を、必要に応じて、ジェネリック・フォーマットから第２のローカル・ネットワークの中で使用されているローカル・サービス記述フォーマットに変換する。
【００９２】
第２のサービス発見ゲートウェイ６０２は、サービス及びデバイス報知部６０２ｃをさらに備える。サービス及びデバイス報知部６０２ｃは、第２のローカル・ネットワーク（図示せず）の中で発見処理Ｄを実行することにより、取得した発見情報を１つ以上のローカルデバイスに報知する。図示した機能部を介しての発見情報の転送、すなわち、サービス及びデバイス発見部６００ａから始まり、最終的にサービス及びデバイス報知部６０２ｃに至る機能部を介しての転送は、一般に、図６内の矢印で示されている。
【００９３】
２つの対向するサービス発見ゲートウェイ６００及び６０２における上記で記述した機能は、本明細書においては、発見情報が第１のローカル・ネットワークから第２のローカル・ネットワークに提供される場合に対してのみ示されている。しかしながら、それぞれのサービス発見ゲートウェイ６００及び６０２は、実際には、ここに示された全ての機能部を備えることができ、発見情報を、もう一方の方向に、すなわち、第２のローカル・ネットワークから第１のローカル・ネットワークに提供し、それにより両方の方向から遠隔でのサービスの発見が可能になる。
【００９４】
図７及び図８は、上述した場合における機能フローの、可能な実施形態の例を示す。それぞれ、図７は、ピア・ツー・ピアの方法を使用した場合であり、図８はＩＭＳセントリックの方法を使用した場合である。図７においては、第１のローカル・ネットワーク内の第１のサービス発見ゲートウェイ７００は、発見情報を、第２のローカル・ネットワークの中にある反対側の第２のサービス発見ゲートウェイ７０２に直接提供する。最初に示されたステップ７．１では、第２のサービス発見ゲートウェイ７０２内のプレゼンス・ウオッチャ７０２ａは、ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージ（ＳＩＰ購読メッセージ）を反対側のサービス発見ゲートウェイ７００に送信し、発見情報を要求する。
【００９５】
次のステップ７．２では、プレゼンス・エージェント７００ｃはＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージを受信する。プレゼンス・エージェント７００ｃは即座に応答し、ＳＩＰ＿Ｎｏｔｉｆｙメッセージ（ＳＩＰ通知メッセージ）をプレゼンス・ウオッチャ７０２ａに返送することができる。ＳＩＰ＿Ｎｏｔｉｆｙメッセージは、第２のローカル・ネットワークの中でこれまでに取得した任意の発見情報を含む。このように、プレゼンス・エージェント７００ｃは、プレゼンス・フレームワークのプレゼンス・メッセージを、プレゼンス・ウオッチャ７０２ａと通信するよう適合される。
【００９６】
さらにステップ７．３では、発見手順は第１のローカル・ネットワークの中で実行される。第１のサービス発見ゲートウェイ７００内のサービス発見部７００ａは、ローカル・サービス・ノード７０４から発見情報を取得する。この実施形態では、サービス発見部７００ａはまた、それぞれのローカル・サービス・ノードによって使用されているサービス記述フォーマットを、反対側のサービス発見ゲートウェイ７０２が理解するジェネリック・サービス記述フォーマットに変換する。ただし、この図では別個のステップとしては示されていない。
【００９７】
ステップ７．４において、発見処理により得られたサービス情報は、その後、サービス発見部７００ａから、サービス発見ゲートウェイ７００内のプレゼンス・ユーザ・エージェント７００ｂに伝達される。プレゼンス・ユーザ・エージェント７００ｂは、現行の標準規格に従って、プレゼンティティを代表してプレゼンス情報を準備し操作する。この場合、プレゼンティティは、事実上、サービス発見部７００ａであり、そしてプレゼンス情報は、サービスの記述（ＳＤＰフォーマットで）である。例えば、プレゼンス・ユーザ・エージェント７００ｂによる操作は、このサービス情報がＰＩＤＦに従うフォーマットに変換されることを助けることができる。
【００９８】
従って、さらなるステップ７．５において、プレゼンス・ユーザ・エージェント７００ｂは準備したプレゼンス情報をプレゼンス・エージェント７００ｃに伝達する。最後に、最後のステップ７．６において、プレゼンス・エージェント７００ｃは、新しいサービス・プレゼンス情報のこのイベントに起動されて、ジェネリック・フォーマットで発見情報を含むＳＩＰ＿Ｎｏｔｉｆｙメッセージを、プレゼンス・ウオッチャ７０２ａを含む任意の購読者（すなわち、プレゼンス・ウオッチャ）に、ＩＭＳネットワークを介して、プレゼンス・フレームワークを使用して送信する。
【００９９】
図８に示されるＩＭＳセントリックの場合では、第１のローカル・ネットワーク内の第１のサービス発見ゲートウェイ８００は、第２のローカル・ネットワーク内の反対側の第２のサービス発見ゲートウェイ８０２に、直接にではなく、プレゼンスサーバ８０４を経由して発見情報を提供する。この場合は、第１のサービス発見ゲートウェイ８００はプレゼンス・エージェント７００ｃを省いており、その代わりに、公開されたサービス・プレゼンス情報をプレゼンスサーバ８０４に送信するイベント公開エージェント８００ａを備える。第１のサービス発見ゲートウェイ８００はまた、以前の例と全く同様に、サービス発見部とプレゼンス・ユーザ・エージェントとを備える。ただし、本明細書では説明を容易にするために示していない。したがって、ローカル発見手順Ｄにおいて取得された発見情報は、図７の例におけるプレゼンス・エージェント７００ｃの場合と同じ様式で、イベント公開エージェント８００ａに提供されると仮定している。したがって、これに関する記述はここでは繰り返さない。
【０１００】
最初に示すステップ８．１において、第２のサービス発見ゲートウェイ８０２内のプレゼンス・ウオッチャ８０２ａは、ＳＩＰ＿Ｓｕｂｓｃｒｉｂｅメッセージ（ＳＩＰ購読メッセージ）をプレゼンスサーバ８０４のプレゼンス・エージェント８０４ｃに送信する。次のステップ８．２において、プレゼンス・エージェント８０４ｃは、即座にＳＩＰ＿Ｎｏｔｉｆｙメッセージ（ＳＩＰ通知メッセージ）をプレゼンス・ウオッチャ８０２ａに返送する。これは、図７におけるステップ７．１及びステップ７．２と同様である。したがって、プレゼンス・エージェント８０４ｃは、プレゼンス・ウオッチャ８０２ａとプレゼンス・メッセージを通信するよう適合される。
【０１０１】
さらなるステップ８．３では、発見手順は第１のローカル・ネットワークの中で実行される。第１のサービス発見ゲートウェイ８００内のサービス発見部（図示せず）は、発見情報をローカル・サービス・ノード８０６から取得する。続いて、ステップ８．４において、イベント公開エージェント８００ａは、サービス発見部によって取得され、変換（必要に応じて）された発見情報をプレゼンス・ユーザ・エージェントから受信し、その発見情報を、サービス・プレゼンス情報としてＳＩＰ＿Ｐｕｂｌｉｓｈメッセージ（ＳＩＰ公開メッセージ）でプレゼンスサーバ８０４に送信する。このステップにおいて、公開されたサービス・プレゼンス情報は、プレゼンスサーバ内のイベント状態合成部８０４ａによって受信される。イベント状態合成部８０４ａは、指定されたプレゼンスサービスにおいて、受信された公開プレゼンス情報を記憶する。したがって、次のステップ８．５においては、受信された発見情報は、更新されたプレゼンス情報として、プレゼンスサーバ８０４内のプレゼンスサービス部８０４ｂに記憶される。
【０１０２】
ステップ８．６において、プレゼンスサービス部８０４ｂは、プレゼンス・エージェント８０４ｃにプレゼンス状態が変化したことを通知する。最後に、最後のステップ８．７において、プレゼンス・エージェント８０４ｃは、更新された発見情報を含むＳＩＰ＿Ｎｏｔｉｆｙメッセージを、第２のサービス発見ゲートウェイ８０２内のプレゼンス・ウオッチャ８０２ａに送信する。
【０１０３】
サービス発見ゲートウェイにおける上述した機能は、例えば、ローカル・ネットワークにおける任意の型のデバイス上で動作する特定のアプリケーションによって、いくつかの様式で利用することができる。例で言えば、サービス発見ゲートウェイ「上で」実施することが可能な、２つの異なる利用形態を以下で説明する。ただし、他の利用形態も本発明の範囲の中で可能である。
【０１０４】
第１の例においては、サービス発見ゲートウェイＳＤＧは、移動電話機又はＳＴＢ等の、ローカル・ネットワークにおける単一のユーザデバイス内のサービス制御アプリケーションと統合することができる。例えば、ＳＤＧ機能は、ＨＩＧＡ機能も有するローカルデバイス（すなわち、ＰＩＧＡ）の中で実施することができる。ＳＤＧデバイス上のアプリケーション（専用ロジックとグラフィカル・ユーザ・インタフェース（ＧＵＩ）とを有することが望ましい）は、上述したＳＤＧ機能を利用することができ、ユーザは、ローカル・サービスと遠隔サービスの両方の発見と利用とを積極的に制御することができる。これにより、デバイスのユーザは、訪問先ローカル・ネットワークに位置するときに、遠隔ローカル・ネットワーク（例えば、旅行中におけるユーザのホームネットワーク）のアドレスを選択し、遠隔ネットワークにおけるサービス（例えば、メディアサーバ内のコンテンツ）を発見することができる。さらに、ユーザは、訪問先ローカル・ネットワーク環境下で、デバイス（例えば、適切なメディアプレーヤ）の探索を行うことができる。そして、選択したローカルデバイスは、上述したＳＤＧ機能を使用して、遠隔ネットワークにおけるデバイスとのサービス利用セッション（例えば、遠隔メディアサーバとローカルメディアプレーヤとの間のメディア・ストリーミング・セッション）を開始することができる。
【０１０５】
第２の例では、第１のローカル・ネットワーク内のＳＤＧ１は、第２のローカル・ネットワーク内のＳＤＧ２に向うプレゼンス・ウオッチャとして動作する。これにより、ＳＤＧ１は、事実上、第１のローカル・ネットワーク内のデバイスに透過的に接続された、第２のローカル・ネットワークからのサービス２Ａの「仮想」サービスプロバイダとして動作する。ＧＵＩを使用する制御アプリケーションは、例えば、第１のローカル・ネットワーク内のサービス１Ｂによって提供することができるであろう。そして、ＳＤＧ１は、ＳＤＧ２からのサービス・プレゼンス情報を利用することにより、サービス２Ａと見えることであろう。
【０１０６】
別の例として、第１のローカル・ネットワーク内のサービス１Ａ（これは、制御ＧＵＩを備えたメディア供給サービスであることも可能であろう）は、第１のローカル・ネットワーク内の利用可能なメディアクライアントを探索することができ、ＳＤＧ１は、第２のローカル・ネットワークからの仮想サービス２Ａ（メディアクライアントであろう）として、透過的に見えることも可能であろう。したがって、遠隔メディアクライアント（すなわちネットワーク２におけるサービス２Ａ）は、あたかもそれが同一のローカル・ネットワークの中に存在するかのように、サービス１Ａによって利用されることもできるであろう。
【０１０７】
上述したサービス発見ゲートウェイＳＤＧにおける機能は、建物の遠隔制御及び管理の場合にも利用することができる。将来は、個人の建物の中では種々の装置がローカルホームネットワークに接続され、それらは、例えば、暖房、換気、空調、照明、及び監視カメラ等をサポートすることになるであろう。ＰＩＧＡの中に設けられた遠隔制御クライアントを、ＩＭＳ通信基盤を介してその建物のローカル・ネットワーク内のＳＤＧ（ＨＩＧＡの中に設備する）に接続することにより、建物を遠隔から制御することができる。
【０１０８】
上述した実施形態のいずれかに従った本発明を使用することにより、下記に示す利点と改善とを得ることができる。
【０１０９】
ＩＭＳのネットワーク基盤とプレゼンス・フレームワークとを、遠隔発見に対するジェネリック転送手段として使用することにより、異なるローカル・ネットワーク内のサービスの島をまたがって、ローカル・サービスを提供し、利用することができる。これは、そのローカル・ネットワークの中で、デバイスに特化した種々の異なるサービス発見プロトコルが使用される場合においても可能である。これにより、多くの利用形態及び適用形態を、柔軟でかつ拡張性のある様式でサポートすることができる。
【０１１０】
遠隔発見におけるプレゼンスイベントの管理のためにＩＭＳセントリック・プレゼンスサーバを使用する場合には、ＳＤＰトラフィック（特に、ＩＭＳネットワークとプレゼンティティＳＤＧとの間）を最適化することができ、ウォッチャＳＤＧとプレゼンティティＳＤＧとの間のエンド・ツー・エンド・トラフィックを最小にすることができる。さらに、サービス記述のためのジェネリック・フォーマットは、メタデータを含むことができる。メタデータは、頻度高く使用される情報等を、プレゼンスサーバがキャッシュすることを可能にするものである。
【０１１１】
さらに、上述した様式でプレゼンス・フレームワークを利用する場合には、ローカル・ネットワーク内のサービス及びコンテンツの所有者は、そのローカル・ネットワーク内の特定のサービス及びコンテンツに関して、他のローカル・ネットワークにいる場合のユーザ又はユーザグループに対しては、特定のアクセス権を規定することができる。
また、基盤にあるＩＭＳ識別と認可のメカニズムとを使用して、サービス及びコンテンツに対するアクセスを制御することができる。
【０１１２】
正規のＳＩＰメッセージとして「ＳＩＰのためのプレゼンス・イベント・パッケージ」を使用して、ＩＭＳ基盤を介して発見情報を交換する場合には、ＩＭＳ／ＳＩＰに固有なアドレス指定及びモビリティ・サポートもまた利用することができる。
【０１１３】
本発明は、特定の典型的な実施形態を参照して記述されてきたが、本記述は、一般的に、発明の概念を説明するだけの目的でなされたものであり、本発明の範囲を限定するものであると理解されてはならない。上記の実施形態を記述するときには、ＩＭＳ、ＨＩＧＡ、ＵＰｎＰ、及び、ＳＤＰという概念が使用されてきたが、基本的には、任意の他の同様な適切な標準規格及びネットワーク要素を使用して、本明細書に記述されたように、複数のローカル・ネットワークにわたる発見処理を可能にすることができる。本発明は、一般に、下記の独立請求項によって定義される。
【図１】
2010515338.tif 000003
【図２】
2010515338.tif 000004
【図３】
2010515338.tif 000005
【図４】
2010515338.tif 000006
【図５】
2010515338.tif 000007
【図６】
2010515338.tif 000008
【図７】
2010515338.tif 000009
【図８】
2010515338.tif 000010
【国際調査報告】
2010515338.tif 000011
2010515338.tif 000012
2010515338.tif 000013