(57)【特許請求の範囲】
【請求項１】
複数のデバイスを含む複数のサブネットを備えるネットワークシステムであって、
前記複数のデバイスは、
複数のサービスを提供するサービスデバイスと、
前記サービスデバイスと異なるサブネットに属する制御デバイスと、
前記サービスデバイスと同じサブネットに属するサービス中継デバイスと、
前記サービス中継デバイスと接続され、前記制御デバイスと同じサブネットに属する制御中継デバイスとを含み、
前記サービスデバイスは、
前記サービスの所在を示すサービス所在情報を宛先情報として含むサービスメッセージを、前記サービス中継デバイスに送信するサービスメッセージ送信手段を備え、
前記サービス中継デバイスは、
前記サービスメッセージ送信手段から送信されたサービスメッセージを受信し、受信したサービスメッセージを前記制御中継デバイスに送信する手段を備え、
前記制御中継デバイスは、
前記サービス中継デバイスから送信されたサービスメッセージ内の宛先情報を、前記サービス所在情報から、自身の所在を示す制御中継所在情報に変更する変換手段と、
前記サービス所在情報を逆変換情報として前記サービスメッセージに残す維持手段と、
前記変更された宛先情報及び前記逆変換情報を含むサービスメッセージを前記制御デバイスに送信する手段とを備え、
前記制御デバイスは、
前記サービスメッセージに基づいて、前記宛先情報と前記逆変換情報とを含む要求メッセージを作成する要求メッセージ作成手段と、
前記要求メッセージ内の前記宛先情報によって特定される前記制御中継デバイスに、前記要求メッセージを送信する手段とを備え、
前記制御中継デバイスは、
前記要求メッセージを受けたとき、前記要求メッセージ内の宛先情報を、前記制御中継所在情報から、前記逆変換情報であるサービス所在情報に変更する逆変換手段と、
変更された宛先情報を含む前記要求メッセージを前記サービス中継デバイスに送信する手段とを備え、
前記サービス中継デバイスは、
前記送信された要求メッセージの宛先情報によって特定されるサービスデバイス内の前記サービスに、前記要求メッセージを送信する手段を備え、
前記サービスメッセージ送信手段は、複数種類のサービスメッセージを送信し、
前記サービスメッセージは複数のパラメータを含み、
前記制御中継デバイスはさらに、
前記サービスメッセージの複数のパラメータのうち、前記宛先情報を含むパラメータを示すテーブルを備え、
前記変換手段は、前記テーブルに基づいて、前記サービスメッセージ内の宛先情報を特定することを特徴とするネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムであって、
前記サービス中継デバイスは、
前記サービスデバイスから送信された前記サービスメッセージを分割して複数のパケットを作成し、前記作成された複数のパケットを前記制御中継デバイスに送信するパケット送信手段を備え、
前記変換手段は、前記送信された複数のパケットから前記分割されたサービスメッセージを取り出して復元した後、サービスメッセージ内の宛先情報を、前記サービス所在情報から、前記制御中継所在情報に変更することを特徴とするネットワークシステム。
【請求項３】
複数のサービスを提供するサービスデバイスと、前記サービスデバイスと異なるサブネットに属する制御デバイスと、前記サービスデバイスと同じサブネットに属するサービス中継デバイスと、前記制御デバイスと同じサブネットに属する制御中継デバイスとを含むネットワークシステムの前記制御中継デバイスであって、
前記サービス中継デバイスから、前記サービスデバイス内のサービスの所在に関するサービス所在情報を含むサービスメッセージを受信したとき、前記サービスメッセージ内の宛先情報を、前記サービス所在情報から、自身の所在を示す中継所在情報に変更する変換手段と、
前記サービス所在情報を逆変換情報として前記サービスメッセージに残す維持手段と、
前記変更された宛先情報及び前記逆変換情報を含むサービスメッセージを前記制御デバイスに送信する手段と、
前記制御デバイスから、前記宛先情報と前記逆変換情報とを含む要求メッセージを受信したとき、前記要求メッセージ内の宛先情報を、前記中継所在情報から、前記逆変換情報であるサービス所在情報に変更する逆変換手段と、
変更された宛先情報を含む前記要求メッセージを、前記サービス中継デバイスに送信する手段とを備え、
前記変換手段は、複数種類のサービスメッセージを受信し、
前記サービスメッセージは複数のパラメータを含み、
前記制御中継デバイスはさらに、
前記サービスメッセージの複数のパラメータのうち、前記宛先情報を含むパラメータを示すテーブルを備え、
前記変換手段は、前記テーブルに基づいて、前記サービスメッセージ内の宛先情報を特定することを特徴とする中継デバイス。
【請求項４】
複数のサービスを提供するサービスデバイスと、前記サービスデバイスと異なるサブネットに属する制御デバイスと、前記サービスデバイスと同じサブネットに属するサービス中継デバイスと、前記制御デバイスと同じサブネットに属する制御中継デバイスとを含むネットワークシステムの前記制御中継デバイスに実行させる中継プログラムであって、
前記サービス中継デバイスから、前記サービスデバイス内のサービスの所在に関するサービス所在情報を含むサービスメッセージを受信したとき、前記サービスメッセージ内の宛先情報を、前記サービス所在情報から、自身の所在を示す中継所在情報に変更するステップと、
前記サービス所在情報を逆変換情報として前記サービスメッセージに残すステップと、
前記変更された宛先情報及び前記逆変換情報を含むサービスメッセージを前記制御デバイスに送信するステップと、
前記制御デバイスから、前記宛先情報と前記逆変換情報とを含む要求メッセージを受信したとき、前記要求メッセージ内の宛先情報を、前記中継所在情報から、前記逆変換情報であるサービス所在情報に変更するステップと、
変更された宛先情報を含む前記要求メッセージを、前記サービス中継デバイスに送信するステップとを前記中継デバイスに実行させ、
前記変更するステップは、複数種類のサービスメッセージを受信し、
前記サービスメッセージは複数のパラメータを含み、
前記変更するステップは、前記サービスメッセージの複数のパラメータのうち、前記宛先情報を含むパラメータを示すテーブルに基づいて、前記サービスメッセージ内の宛先情報を特定することを特徴とする中継プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム、中継デバイス及び中継プログラムに関し、さらに詳しくは、複数のサブネットを含むネットワークシステム、所定のサブネットに属し、他の異なるサブネットとのデータのやり取りを中継する中継デバイス及びそのプログラムに関する。
【背景技術】
【０００２】
最近、家庭内のパーソナルコンピュータやＡＶ（Audio Visual）機器を相互に接続するためのプロトコルであるＵＰｎＰ（Universal Plug and Play：ユニバーサルプラグアンドプレイ）に基づくネットワークＡＶシステムが登場している。ＵＰｎＰプロトコルに基づくネットワークＡＶシステムでは、コントロールポイントと呼ばれるＵＰｎＰデバイスが、映像や音楽といったコンテンツを蓄積するメディアサーバや、コンテンツを再生するメディアレンダラといったＵＰｎＰデバイスを制御する。たとえば、コントロールポイントは、メディアサーバが蓄積する複数のコンテンツに関する情報を取得し、所望のコンテンツを再生するようメディアレンダラに指示する。メディアレンダラは、メディアサーバに所望のコンテンツを要求する。メディアサーバは、要求に応じて所望のコンテンツをストリーミング配信し、メディアレンダラは、ストリーミング配信されたコンテンツを再生する。
【０００３】
上述のＵＰｎＰデバイスは、ネットワークに参加するときに動的にＩＰアドレスを取得する。そして、取得したＩＰアドレスを利用して、ネットワーク上の他のＵＰｎＰに自身が起動した旨を通知したり、自身が提供するサービスに関する情報を通知したり、他のＵＰｎＰデバイスの情報を取得することができる。
【０００４】
しかしながら、ＵＰｎＰデバイスは、同一ネットワーク内の他のＵＰｎＰデバイスと通信したり、制御したりできるが、異なるサブネットのデバイスと通信したり、制御したりすることはできない。
【０００５】
このような問題を解決する技術が特開２００５−３１１７７３号公報（特許文献１）に開示されている。この文献によれば、各サブネットに属するＵＰｎＰデバイスプロキシ装置は、異なるサブネットに属する各ＵＰｎＰデバイスを仮想ＵＰｎＰデバイスとして管理する。具体的には、異なるサブネットに属するＵＰｎＰデバイスの固有の識別子ごとにポートを割り当て、メッセージが到達したポートによってメッセージの送信先を決定する。
【０００６】
しかしながらこの場合、各ＵＰｎＰデバイスプロキシ装置は、異なるサブネットに属する全てのＵＰｎＰデバイスを管理しなければならない。さらに、メッセージ内にサービスやファイルの所在に関する位置情報が含まれる場合、メッセージを受けたＵＰｎＰデバイスは、メッセージ内の位置情報を利用して新たなメッセージを送信できない。なぜなら、異なるサブネットから送信されるメッセージ内に含まれる位置情報は、ローカルアドレスであるため、メッセージの送信元のＵＰｎＰデバイスが属するサブネット上でのみ有効だからである。したがって、位置情報を利用して新たなメッセージを作成しても、そのメッセージは所望のＵＰｎＰデバイスには届かない場合がある。
【特許文献１】特開２００５−３１１７７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、異なるサブネットに属するデバイスを制御することができるネットワークシステムを提供することである。
【課題を解決するための手段及び発明の効果】
【０００８】
本発明によるネットワークシステムは、複数のデバイスを含む複数のサブネットを備える。複数のデバイスは、サービスデバイスと、制御デバイスと、サービス中継デバイスと、制御中継デバイスとを備える。サービスデバイスは、複数のサービスを提供する。制御デバイスは、サービスデバイスと異なるサブネットに属する。サービス中継デバイスは、サービスデバイスと同じサブネットに属する。制御中継デバイスは、サービス中継デバイスと接続され、制御デバイスと同じサブネットに属する。
サービスデバイスは、サービスメッセージ送信手段を備える。サービスメッセージ送信手段は、サービスの所在を示すサービス所在情報を宛先情報として含むサービスメッセージを、サービス中継デバイスを経由して制御中継デバイスに送信する。制御中継デバイスは、変換手段と、維持手段とを備える。変換手段は、送信されたサービスメッセージ内の宛先情報を、サービス所在情報から、自身の所在を示す制御中継所在情報に変更する。維持手段は、サービス所在情報を逆変換情報としてサービスメッセージに残す。制御中継デバイスはさらに、変更された宛先情報及び逆変換情報を含むサービスメッセージを制御デバイスに送信する。制御デバイスは、サービスメッセージに基づいて、宛先情報と逆変換情報とを含む要求メッセージを作成する要求メッセージ作成手段と、要求メッセージ内の宛先情報によって特定される制御中継デバイスに、要求メッセージを送信する手段とを備える。制御中継デバイスは、要求メッセージを受けたとき、要求メッセージ内の宛先情報を、制御中継所在情報から、逆変換情報であるサービス所在情報に変更する逆変換手段と、変更された宛先情報を含む要求メッセージをサービス中継デバイスに送信する手段とを備える。サービス中継デバイスは、送信された要求メッセージの宛先情報によって特定されるサービスデバイス内のサービスに、要求メッセージを送信する手段を備える。
【０００９】
本発明によるネットワークシステムでは、制御中継デバイスが、異なるサブネットから送信されたサービスメッセージ内の宛先情報を自身の所在を示す制御所在情報に変更する。そのため、サービスメッセージを受けた制御デバイスが、サービスメッセージに基づいて要求メッセージを送信するとき、制御所在情報を宛先情報とすることができる。
【００１０】
制御中継デバイスはさらに、サービスメッセージ内にサービス所在情報を残しておき、制御デバイスは、要求メッセージにサービス所在情報を含めて送信する。そして、要求メッセージを受けた制御中継デバイスは、要求メッセージの宛先情報をサービス所在情報に変更する。そのため、制御中継デバイスは、要求メッセージをサービスデバイスに送信することができ、異なるサブネットでの通信を可能にする。
【００１１】
さらに、メッセージ内に逆変換情報を含めることにより、制御中継デバイスは、サービス所在情報を保管しておく必要がない。
【００１２】
好ましくは、サービスメッセージ送信手段は、複数種類のサービスメッセージを送信する。サービスメッセージは複数のパラメータを含む。制御中継デバイスはさらに、サービスメッセージの複数のパラメータのうち、宛先情報を含むパラメータを示すテーブルを備える。変換手段は、テーブルに基づいて、サービスメッセージ内の宛先情報を特定する。
【００１３】
この場合、テーブルにより検索すべきパラメータを容易に特定できるため、処理負荷を軽減できる。
【００１４】
好ましくは、サービス中継デバイスは、パケット送信手段を備える。パケット送信手段は、サービスデバイスから送信されたサービスメッセージを分割して複数のパケットを作成し、作成された複数のパケットを制御中継デバイスに送信する。変換手段は、送信された複数のパケットから分割されたサービスメッセージを取り出して復元した後、サービスメッセージ内の宛先情報を、サービス所在情報から、制御中継所在情報に変更する。
【００１５】
本発明による中継デバイスは、複数のサービスを提供するサービスデバイスと、サービスデバイスと異なるサブネットに属する制御デバイスと、一方がサービスデバイスと同じサブネットに属し、他方が制御デバイスと同じサブネットに属する複数の中継デバイスとを含むネットワークシステムの中継デバイスである。中継デバイスは、同じサブネットに属するサービスデバイスから、サービスデバイス内のサービスの所在に関するサービス所在情報を含むサービスメッセージを受けたとき、制御デバイスと同じサブネットに属する当該他の中継デバイスにサービスメッセージを送信する手段と、異なるサブネットに属する当該他の中継デバイスからサービスメッセージを受信したとき、サービスメッセージ内の宛先情報を、サービス所在情報から、自身の所在を示す中継所在情報に変更する変換手段と、サービス所在情報を逆変換情報としてサービスメッセージに残す維持手段と、変更された宛先情報及び逆変換情報を含むサービスメッセージを制御デバイスに送信する手段と、同じサブネットに属する制御デバイスから、宛先情報と逆変換情報とを含む要求メッセージを受信したとき、要求メッセージ内の宛先情報を、中継所在情報から、逆変換情報であるサービス所在情報に変更する逆変換手段と、変更された宛先情報を含む要求メッセージを、異なるサブネットに属する当該他の中継デバイスに送信する手段と、異なるサブネットに属する当該他の中継デバイスから要求メッセージを受けたとき、送信された要求メッセージの宛先情報によって特定されるサービスデバイス内のサービスに、要求メッセージを送信する手段を備える。本発明による中継プログラムは、上述の中継デバイスに実行させるプログラムである。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。
【００１７】
［全体構成］
図１を参照して、ネットワークシステムは、ホームネットワーク１０と、ホームネットワーク１０とインターネット３０で接続される外部ネットワーク２０とを含む。ホームネットワーク１０はたとえば、ネットワークシステムを利用するユーザが家庭内で構築しているネットワークであり、外部ネットワーク２０はユーザが外出先で利用するネットワークである。
【００１８】
ホームネットワーク１０は、メディアサーバ１１とホーム中継器１２とを備える。これらは、いずれもＵＰｎＰプロトコルに準拠したＵＰｎＰデバイスである。
【００１９】
ＵＰｎＰデバイスは、提供可能な複数のサービスを含む。これらのサービスの詳細は、サービスディスクリプションに記述されている。また、各サービスディスクリプションの格納場所に関する情報（ＵＲＬ）は、デバイスディスクリプションに含まれる。サービスディスクリプション及びデバイスディスクリプションはＵＰｎＰデバイス内の記憶装置に記憶される。
【００２０】
ＵＰｎＰデバイスの１つであるメディアサーバ１１は、映像データや、静止画データ、音声データ等の複数のコンテンツを蓄積する。メディアサーバ１１は、コンテンツリストの送信サービスや選択されたコンテンツの配信サービスといった複数のサービスを持つ。
【００２１】
ホーム中継器１２は、インターネット３０と接続されており、ホームネットワーク１０内から外部へ送信されるデータや、外部からホームネットワーク１０内に送信されるデータを中継する。
【００２２】
なお、図１では、ホームネットワーク１０には２つのＵＰｎＰデバイスしか示されていないが、ホームネットワーク１０に３つ以上のＵＰｎＰデバイスが存在してもよい。
【００２３】
外部ネットワーク２０は、外部中継器２１と、コントロールポイント２２とを備える。これらは、いずれもＵＰｎＰデバイスである。ホームネットワーク１０と同様に、外部ネットワーク２０も、外部中継器２１及びコントロールポイント２２以外の他のＵＰｎＰデバイス、たとえばメディアレンダラ等を含んでもよい。
【００２４】
コントロールポイント２２は、ＵＰｎＰに基づいて、同一サブネット内の複数のＵＰｎＰデバイスを制御する。たとえば、同一サブネット内の図示しないメディアレンダラに所望のコンテンツの再生を指示したり、コンテンツの再生停止を指示したりする。
【００２５】
コントロールポイント２２はさらに、異なるサブネットに属するＵＰｎＰデバイスを制御できる。具体的には、コントロールポイント２２は、ホームネットワーク１０内のメディアサーバ１１を制御できる。制御方法については後述する。
【００２６】
外部中継器２１は、インターネット３０と接続されており、外部ネットワーク２０から外部に送信されるデータや、外部から外部ネットワーク２０内に送信されたデータを中継する。
【００２７】
外部中継器２１及びホーム中継器１２はさらに、コントロールポイント２２が、異なるサブネットに属する他のＵＰｎＰデバイスであるメディアサーバ１１を制御できるように、コントロールポイント２２やメディアサーバ１１から送信される種々のメッセージを必要に応じて加工する。
【００２８】
［中継器の構成］
ホーム中継器１２及び外部中継器２１（以下、これらを総称して単に「中継器」とも称する）の構成を説明する
図２を参照して、中継器は、中央処理装置（ＣＰＵ）２２と、メモリ２３と、ハードディスクドライブ（ＨＤＤ）２５と、同一サブネット内の他のＵＰｎＰデバイス又はインターネット３０とデータの送受信を行うための通信部２４とを備える。
【００２９】
ＨＤＤ２５は、ＵＰｎＰ機能を実現するためのＵＰｎＰプロトコルモジュール２６を蓄積する。ＵＰｎＰプロトコルモジュール２６は、周知のＵＰｎＰプロトコルスタックを構成する。ＵＰｎＰプロトコルスタックは、ベースとなるＴＣＰ／ＩＰプロトコルスイートと、ＨＴＴＰと、ＨＴＴＰＵと、ＨＴＴＰＭＵと、ＳＳＤＰ(Simple Service Discovery Protocol)と、ＧＥＮＡ(Generic Event Notification Architecture)と、ＳＯＡＰ(Simple Object Access Protocol)とを含む。
【００３０】
ＨＤＤ２５はさらに、通信モジュール２７を蓄積する。通信モジュール２７がメモリ２３にロードされ、ＣＰＵ２２で実行されることにより、中継器は、コントロールポイント２２又はメディアサーバ１１から送信されるメッセージを加工する。これにより、コントロールポイント２２は、異なるサブネットのＵＰｎＰデバイス（メディアサーバ）を制御できる。以下、各サブネットに中継器を含むネットワークシステムの動作を説明する。
【００３１】
［動作］
［ディスカバリ］
コントロールポイント２２は、外部ネットワーク２０に接続されたとき、ネットワーク上の他のＵＰｎＰデバイスを検出する。本実施の形態ではさらに、コントロールポイント２２は、外部ネットワーク２０と異なるサブネットであるホームネットワーク１０内のＵＰｎＰデバイスを検出する。この動作をディスカバリと呼ぶ。以下、ディスカバリ動作の詳細を説明する。
【００３２】
図３を参照して、コントロールポイント２２が外部ネットワーク２０に接続されたとき、コントロールポイント２２は、検出メッセージ（Ｍ−Ｓｅａｒｃｈ）を作成する。図４に示すように、検出メッセージは、検出対象となるＵＰｎＰデバイスのタイプ情報を登録するためのフィールドを持つ。ここでは、検出対象となるＵＰｎＰデバイスのタイプ情報を「メディアサーバ」とする。なお、各ＵＰｎＰデバイスは、自身のタイプに関する情報を予め記憶している。
【００３３】
コントロールポイント２２は、作成された検出メッセージを外部ネットワーク２０内にマルチキャストで送信する（Ｓ１）。このとき、検出メッセージは分割され、分割された検出メッセージはカプセル化される。そして、自身のローカルＩＰと、メッセージの種類を示すメッセージタイプ情報とを含むヘッダをカプセル化された分割メッセージデータに付与した複数のパケットを作成する。ここでは、メッセージタイプとして検出メッセージの識別子が記録される。
【００３４】
作成された複数のパケットは、マルチキャストされ、外部中継器２１にも送信される。検出メッセージの作成及び通信には、ＳＳＤＰが利用される。
【００３５】
外部中継器２１は、マルチキャストされた検出メッセージのパケットを受信する（Ｓ２）。このとき、外部中継器２１は、パケットヘッダに含まれるコントロールポイント２２のローカルＩＰをメモリ２３に記憶する。
【００３６】
続いて、外部中継器２１は、パケットヘッダ内のメッセージタイプを参照する（Ｓ３）。ここで、メッセージタイプは「検出メッセージ」であるため、パケットのデータ部分を加工することなく、インターネット３０経由でホーム中継器１２に送信する（Ｓ３）。ここでは、ＴＣＰ／ＩＰプロトコルが利用される。外部中継器２１は、ホーム中継器１２のグローバルＩＰを予め取得してメモリ２３に格納している。ステップＳ３で外部中継器２１は、メモリ２３に格納されたホーム中継器１２のグローバルＩＰを利用して、宛先情報としてホーム中継器１２のグローバルＩＰが記述され、送信元情報として外部中継器２１のグローバルＩＰが記述されたヘッダを作成する。ヘッダにはさらに、上述のメッセージタイプを含める。そして、作成されたヘッダを含むパケットを送信する。パケット内のデータ部分は分割された検出メッセージの断片である。
【００３７】
ホーム中継器１２は、外部中継器２１からパケットを受信したとき（Ｓ４）、パケットヘッダに含まれる外部中継器２１のグローバルＩＰをメモリ２３に記憶する。さらに、パケットヘッダ内のメッセージタイプを参照する（Ｓ４）。メッセージタイプが「検出メッセージ」であるため、ホーム中継器１２は、受信した検出メッセージをマルチキャストする。具体的には、外部中継器２１から受信したパケットをホームネットワーク１０内にマルチキャストする（Ｓ５）。
【００３８】
ホームネットワーク１０内の全てのＵＰｎＰデバイスは、検出メッセージのパケットを受信する（Ｓ６）。各ＵＰｎＰデバイスは、パケットのデータ部分にカプセル化された検出メッセージの断片を取り出し、復元する。そして、復元された検出メッセージ内のタイプ情報を参照し、自身のタイプと一致するか否か判断する。
【００３９】
メディアサーバ１１は、検出メッセージ内のタイプ情報が自身のタイプ情報と一致すると判断し、検出応答メッセージ（Ｎｏｔｉｆｙメッセージ）を作成する。検出応答メッセージは、図５に示すように、自身のタイプ情報を登録するためのフィールドと、自身が属するホームネットワーク１０内での自身のローカルＩＰ（ＵＲＬｍｓ）を登録するためのＬｏｃａｔｉｏｎフィールドとを含む。メディアサーバ１１は、検出メッセージをマルチキャストしたホーム中継器１２に対して、パケット化された検出応答メッセージを送信する（Ｓ７）。このとき、送信されるパケットのヘッダには、メッセージタイプ情報として「検出応答メッセージ」の識別子を含む。
【００４０】
ホーム中継器１２は、パケット化された検出応答メッセージを受信したとき（Ｓ８）、パケットヘッダ内のメッセージタイプ情報を確認し、パケットのデータ部分のメッセージが検出応答メッセージであると認識する（Ｓ８）。そのため、ホーム中継器１２は、パケットのデータ部分を加工することなく、パケットをインターネット３０を介して外部中継器２１に送信する（Ｓ９）。
【００４１】
外部中継器２１は、ホーム中継器１２から送信された検出応答メッセージのパケットを受信する（Ｓ１０）。このとき、外部中継器２１は、受信したパケットのヘッダに含まれるメッセージタイプ情報を確認し、受けたパケットが検出応答メッセージに関するものであると認識する。
【００４２】
そこで、外部中継器２１は、受信したパケットをそのままコントロールポイント２２に送信せず、検出応答メッセージを加工する。検出応答メッセージ内のＬｏｃａｔｉｏｎフィールドには、メディアサーバ１１の宛先情報としてローカルＩＰが記述されている。検出応答メッセージ内のＬｏｃａｔｉｏｎフィールドに登録された情報は、次工程のディスクリプション動作で、ディスクリプション要求メッセージの宛先に利用される。ところで、メディアサーバ１１のローカルＩＰは、ホームネットワーク１０内におけるメディアサーバ１１のＩＰであり、外部ネットワーク２０では利用できない。したがって、検出応答メッセージをそのままコントロールポイント２２に送信すれば、Ｌｏｃａｔｉｏｎフィールドの情報がそのままディスクリプション要求メッセージ内の宛先情報として利用されてしまう。そうなれば、ディスクリプション要求メッセージはいずれのデバイスにも届かない。
【００４３】
そこで、外部中継器２１は、検出応答メッセージ内のＬｏｃａｔｉｏｎフィールドに、メディアサーバ１１のローカルＩＰの代わりに自身のローカルＩＰ（ＵＲＬｅｘ）を記述する。以下、このようなメッセージの宛先情報の加工をＵＲＬ変換処理という。以下、ＵＲＬ変換処理を詳述する（Ｓ１１及びＳ１２）。
【００４４】
外部中継器２１はまず、パケットから検出応答メッセージを復元する。具体的には、パケットのデータ部分から、分割された検出応答メッセージの断片を取り出し、復元する。そして、復元された検出応答メッセージ内のＬｏｃａｔｉｏｎフィールドを特定する（Ｓ１１）。
【００４５】
外部中継器２１は、Ｌｏｃａｔｉｏｎフィールドに記載されたメディアサーバ１１のローカルＩＰ（ＵＲＬｍｓ）を削除し、自身のローカルＩＰ（ＵＲＬｅｘ）を記述する。さらに、検出応答メッセージ内に逆変換フィールドを設け、逆変換フィールドに削除されたメディアサーバ１１のローカルＩＰ（ＵＲＬｍｓ）を記述する（Ｓ１２）。ＵＲＬ変換処理された検出応答メッセージを図６に示す。
【００４６】
ＵＲＬ変換処理が完了した後、外部中継器２１は、変換された検出応答メッセージをパケット化してコントロールポイント２２に送信する（Ｓ１３）。このとき、予めメモリ２３に記憶したコントロールポイント２２のローカルＩＰ（ＵＲＬｃｐ）を利用して、パケットをコントロールポイント２２に送信する。
【００４７】
コントロールポイント２２は、検出応答メッセージのパケットを受信し、検出応答メッセージを復元する（Ｓ１４）。そして、検出応答メッセージ内のＬｏｃａｔｉｏｎフィールドに登録されたデータ、つまり、外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）を検出されたデバイス（メディアサーバ）の宛先情報としてメモリ２３に記憶する（Ｓ１４）。さらに、検出応答メッセージの付属データとして、逆変換フィールドに登録されたデータ、つまり、メディアサーバ１１のローカルＩＰ（ＵＲＬｍｓ）をメモリ２３に記憶する（Ｓ１４）。
【００４８】
以上の工程により、メディアサーバの検出メッセージを送信したコントロールポイント２２は、外部中継器２１がメディアサーバであると認識する。つまり、外部中継器２１は、ホーム中継器１２から送信された検出応答メッセージをＵＲＬ変換することにより、メディアサーバ１１の代理として、以降のディスクリプション要求メッセージを受け付ける。また、外部中継器２１は、ＵＲＬ変換前にＬｏｃａｔｉｏｎフィールドに登録されていたメディアサーバ１１のローカルＩＰ（ＵＲＬｍｓ）を自身が保持するのではなく、逆変換情報としてＵＲＬ変換処理後の検出応答メッセージに加える。つまり、外部中継器２１は、異なるサブネットのＵＰｎＰデバイスの宛先情報を管理しない。
【００４９】
［ディスクリプション動作］
コントロールポイント２２は、ディスカバリ動作によりメディアサーバ１１を検出したものの、メディアサーバ１１がどのようなサービスを提供可能であるかについてまだ知らない。そこで、コントロールポイント２２は、ディスカバリ動作により、メディアサーバ１１に関する情報であるデバイスディスクリプションドキュメント（以下、単にデバイスディスクリプションという）を取得する。
【００５０】
デバイスディスクリプションには、デバイス（ここではメディアサーバ１１）のメタデータがＸＭＬ形式で記述されている。具体的には、図７に示すように、デバイスのモデル名、シリアル番号、製造元名等が記述されている。デバイスディスクリプションはさらに、サービスリストを含む。サービスリストには、デバイスが提供可能な各サービスの詳細に関する情報（サービスディスクリプション）の格納場所（ＵＲＬｓ１〜）が列挙されている。ここでいうサービスとは、たとえば、コンテンツリストの提供や、コンテンツの配信である。
【００５１】
コントロールポイント２２はさらに、デバイスディスクリプションに列挙されたサービスのうち、所望のサービスの詳細に関する情報であるサービスディスクリプションを取得する。
【００５２】
初めに、デバイスディスクリプションの取得動作について説明する。図８を参照して、コントロールポイント２２は、メディアサーバ１１のデバイスディスクリプションの要求メッセージを作成する（Ｓ２１）。このとき、メディアサーバ１１は、ＨＴＴＰプロトコルのＧＥＴメソッドを用いて、要求メッセージを作成する。さらに、ディスカバリ動作で取得した応答メッセージのＬｏｃａｔｉｏｎフィールドに格納された宛先情報を、デバイスディスクリプション要求メッセージの宛先情報とする。つまり、図９に示すように、ステップＳ２１で作成される要求メッセージの宛先情報は外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）である。コントロールポイント２２はさらに、ディスカバリ動作で逆変換情報として取得したメディアサーバ１１のローカルＩＰをディスクリプション要求メッセージに含める。
【００５３】
コントロールポイント２２は、作成された要求メッセージ内の宛先情報、つまり、外部中継器２１に対してデバイスディスクリプション要求メッセージをパケット化して送信する（Ｓ２１）。このとき、コントロールポイント２２は、作成されたパケットのパケットヘッダに、メッセージタイプ情報としてデバイスディスクリプション要求メッセージの識別子を含める。
【００５４】
外部中継器２１は、デバイスディスクリプション要求メッセージのパケットを受信する。そして、受信したパケットのパケットヘッダからメッセージタイプ情報を読み出し、受信したメッセージがデバイスディスクリプション要求メッセージであると認識する。デバイスディスクリプション要求メッセージは宛先情報を含むため、宛先情報の変換処理が必要である。そこで、外部中継器２１は、ＵＲＬ逆変換処理を実行する（Ｓ２３及びＳ２４）。
【００５５】
ＵＲＬ逆変換処理ではまず、外部中継器２１は、ステップＳ２２で受信したパケットからデバイスディスクリプション要求メッセージを復元する（Ｓ２３）。続いて、復元されたデバイスディスクリプション内の外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）を削除し、逆変換情報として含まれるメディアサーバ１１のローカルＩＰ（ＵＲＬｍｓ）を新たな宛先情報とする（Ｓ２４）。つまり、外部中継器２１は、メディアサーバ１１の代理としてコントロールポイント２２からデバイスディスクリプション要求メッセージを受けた場合、そのメッセージをメディアサーバ１１に送信できるよう、逆変換情報を用いてメッセージ内の宛先情報を変更する。
【００５６】
外部中継器２１は、ＵＲＬ逆変換処理が施されたデバイスディスクリプション要求メッセージを分割し、パケット化する。このとき、パケットヘッダに、メッセージタイプ情報を含める。パケット化されたデバイスディスクリプション要求メッセージは、インターネット３０を介してホーム中継器１２に送信される（Ｓ２５）。
【００５７】
ホーム中継器１２は、パケット化されたデバイスディスクリプション要求メッセージを受信する（Ｓ２６）。そして、パケットヘッダ内のメッセージタイプ情報を読み出し、送信されたメッセージがデバイスディスクリプション要求メッセージであると認識する（Ｓ２６）。
【００５８】
この場合、ホーム中継器１２は、パケットからデバイスディスクリプション要求メッセージを復元し、復元された要求メッセージ内に記述された宛先情報を確認する（Ｓ２７）。ここでは、メディアサーバ１１のローカルＩＰ（ＵＲＬｍｓ）が宛先情報として記述されている。そこで、ホーム中継器１２は、ＨＴＴＰプロトコルを用いて、メディアサーバ１１にデバイスディスクリプション要求メッセージを送信する（Ｓ２９）。
【００５９】
以上のとおり、コントロールポイント２２がディスクリプション要求メッセージを送信したとき、外部中継器２１で要求メッセージ内の宛先情報がＵＲＬｅｘからＵＲＬｍｓに変換される。そのため、ホーム中継器１２は、コントロールポイント２２の代理として、要求メッセージをメディアサーバ１１に送信できる。
【００６０】
なお、ホーム中継器１２はキャッシュ機能を有するため、ステップＳ２９でデバイスディスクリプション要求メッセージを送信する前に、要求メッセージ内の宛先情報のＵＰｎＰデバイス（つまり、ここではメディアサーバ１１）のデバイスディスクリプションを既にキャッシュメモリに格納しているか否かを確認する（Ｓ２８）。キャッシュメモリに所望のデバイスディスクリプションが既に格納されている場合、ステップ３３に進んで、キャッシュメモリに格納されたデバイスディスクリプションを外部中継器２１に送信する（Ｓ３４）。
【００６１】
一方、キャッシュメモリにメディアサーバ１１のデバイスディスクリプションが格納されていない場合、メディアサーバ１１は、ホーム中継器１２から要求メッセージを受信し（Ｓ３０）、図７に示したデバイスディスクリプションをホーム中継器１２に送信する（Ｓ３１）。
【００６２】
ホーム中継器１２は、メディアサーバ１１からデバイスディスクリプションを受信し（Ｓ３２）、キャッシュメモリに格納する（Ｓ３３）。そして、デバイスディスクリプションをパケット化して外部中継器２１に送信する（Ｓ３４）。このとき、パケットヘッダにメッセージタイプ情報として、デバイスディスクリプションの識別子を付与する。
【００６３】
外部中継器２１は、パケット化されたデバイスディスクリプションを受信する（Ｓ３５）。そして、パケットヘッダ内のメッセージタイプ情報を読み出して、受け取ったメッセージの種類を判別する（Ｓ３６）。判別の結果、受け取ったメッセージがデバイスディスクリプションである場合（Ｓ３６でＹＥＳ）、受信したパケットからデバイスディスクリプションを復元する（Ｓ３７）。
【００６４】
外部中継器２１は、復元されたデバイスディスクリプション内のサービスリストを加工する（Ｓ３８〜Ｓ４０）。外部中継器２１は、デバイスディスクリプションドキュメント内のサービスリストを特定する。そして、特定されたサービスリストから各サービスディスクリプションの格納場所（ＵＲＬｓ１〜ＵＲＬｓｎ（ｎは自然数））を読み出し（Ｓ３８）、読み出された格納場所を全て外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）に変換する（Ｓ３９）。外部中継器２１はさらに、逆変換情報として、ステップＳ３８で読み出された各サービスディスクリプションのＵＲＬｓ１〜ＵＲＬｓｎを各サービスディスクリプションに対応して追加する。つまり、外部中継器２１は、図１０に示すように、自身のローカルＩＰを各サービスディスクリプションの宛先情報とし、各サービスディスクリプションの格納場所（ＵＲＬｓ１〜ＵＲＬｓｎ）を逆変換情報としてサービスリストに埋め込む。外部中継器２１は、サービスリスト内の全てのサービスディスクリプションの宛先情報を変換するまで（Ｓ４０）、ＵＲＬ変換処理を繰り返す。全てのサービスディスクリプションのＵＲＬ変換が完了したとき（Ｓ４０でＹＥＳ）、変換されたデバイスディスクリプションをコントロールポイント２２に送信する（Ｓ４１）。
【００６５】
コントロールポイント２２は、外部中継器２１からデバイスディスクリプションドキュメントを受信し、メモリに記憶する（Ｓ４２）。
【００６６】
以上の処理により、コントロールポイント２２は、メディアサーバ１１のサービスディスクリプションの格納場所を外部中継器２１のローカルＩＰと認識する。これにより、外部中継器２１は、メディアサーバ１１の代理としてサービスディスクリプション要求メッセージを受ける。そして、ＵＲＬ逆変換処理により、サービスディスクリプション要求メッセージ内の宛先情報を、サービスディスクリプションの格納場所（ＵＲＬｓ１〜）に変更する。以下、コントロールポイント２２がサービスディスクリプションを取得するときの処理を説明する。
【００６７】
［サービスディスクリプションの取得］
サービスディスクリプションの取得動作は、上述のデバイスディスクリプションの取得動作とほぼ同じである。
【００６８】
コントロールポイント２２は、デバイスディスクリプションに基づいて、所望のサービスディスクリプション（ここではサービスディスクリプションＩＤ＝サービスＳ１のものとする）を要求する。このとき、コントロールポイント２２は、図１１に示す要求メッセージを作成する（Ｓ２１）。図１１に示すように、要求メッセージの宛先情報は外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）である。また、逆変換情報としてサービスＳ１の格納場所（ＵＲＬｓ１）も含まれる。
【００６９】
コントロールポイント２２は、作成された要求メッセージ内の宛先情報、つまり、外部中継器２１に対して要求メッセージをパケット化して送信する（Ｓ２１）。外部中継器２１は、ＵＲＬ逆変換処理を行い（Ｓ２３及びＳ２４）、要求メッセージの宛先情報をサービスＳ１の格納場所（ＵＲＬｓ１）とする。これにより、サービスディスクリプション要求メッセージをメディアサーバ１１に送信でき、サービスＳ１のサービスディスクリプションを取得できる。
【００７０】
ステップＳ３５で外部中継器２１がサービスディスクリプションのパケットを受け取ったとき、パケットヘッダ内のメッセージタイプ情報を読み出し、確認する。このとき、メッセージタイプ情報として、サービスディスクリプションの識別子が記述されている。そのため、外部中継器２１は、受け取ったメッセージはデバイスディスクリプションではないと判断し（Ｓ３６でＮＯ）、受け取ったパケットをコントロールポイント２２に送信する。サービスディスクリプションは、変換すべき宛先情報を含まないため、外部中継器２１はＵＲＬ変換処理を行う必要がないからである。
【００７１】
以上の動作により、コントロールポイント２２は、異なるサブネットのＵＰｎＰデバイスからデバイスディスクリプション及びサービスディスクリプションを取得できる。
［コントロール］
所望のサービスのサービスディスクリプションを取得した後、コントロールポイント２２は、メディアサーバ１１を制御するために、アクション要求メッセージをサービスＳ１に送信する。
【００７２】
アクション要求メッセージは、ＳＯＡＰを用いてＸＭＬ形式で記述される。サービスは、アクション要求メッセージに応答して、アクション固有の応答メッセージやエラーコードを送信する。サービスが送信する複数の応答メッセージの中には、宛先情報を含むものがある。そのため、応答メッセージが宛先情報を含む場合、その宛先情報をＵＲＬ変換する必要がある。
【００７３】
外部中継器２１は、応答メッセージの宛先情報の変換を容易にするために、図１２に示す宛先情報変換テーブルをＨＤＤ２５に予め記憶する。宛先情報変換テーブルには、サービス名と、宛先情報の変換が必要な応答メッセージを取得するためのアクションの種類と、応答メッセージ内で宛先情報が記述されているパラメータ位置と、宛先情報の記述言語とが登録される。
【００７４】
外部中継器２１は、アクション要求メッセージに対する応答メッセージを受信したとき、宛先情報変換テーブルを用いて、応答メッセージ内の宛先情報を変換する。以下、コントロールポイント２２がＣｏｎｔｅｎｔ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ（以下、ＣＤＳと称する）のサービスディスクリプションを取得し、Ｂｒｏｗｓｅアクションを要求した場合の、コントロール動作の詳細を説明する。
【００７５】
図１３を参照して、コントロールポイント２２は、ＳＯＡＰを用いてＢｒｏｗｓｅアクション要求メッセージをＸＭＬ形式で作成する（Ｓ５１）。Ｂｒｏｗｓｅアクション要求メッセージは、図１４に示すとおり、アクションタイプと、宛先情報と、逆変換情報とを含む。宛先情報及び逆変換情報は、上述のディスクリプション動作で取得したデバイスディスクリプションのサービスリスト内のＣＤＳに対応したものであり、宛先情報は外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）であり、逆変換情報は、ＣＤＳのサービスディスクリプションの格納場所（ＵＲＬｃｄｓとする）である。
【００７６】
コントロールポイント２２は、作成された要求メッセージ内の宛先情報、つまり、外部中継器２１に対してアクション要求メッセージをパケット化して送信する（Ｓ５１）。このとき、パケットヘッダには、アクション要求メッセージの識別子をメッセージタイプ情報として付与する。
【００７７】
外部中継器２１はアクション要求メッセージのパケットを取得し、メッセージタイプ情報を確認する（Ｓ２２）。このとき、メッセージタイプはアクション要求メッセージであり、宛先情報を含むメッセージである。そのため、外部中継器２１は、パケットからアクション要求メッセージを復元し（Ｓ２３）、アクション要求メッセージの宛先情報をＣＤＳのサービスディスクリプションの格納場所（ＵＲＬｃｄｓ）に変更する（Ｓ２４）。これにより、外部中継器２１は、アクション要求メッセージをメディアサーバ１１内のＣＤＳに送信できる。変更されたアクション要求メッセージは、パケット化されてホーム中継器１２に送信される（Ｓ２５）。
【００７８】
ホーム中継器１２は、外部中継器２１からパケットを受信する（Ｓ５２）。そして、パケットヘッダのメッセージタイプ情報を読み出し、アクション要求メッセージであると認識する。
【００７９】
そこで、ホーム中継器１２は、Ｂｒｏｗｓｅアクション要求メッセージの断片を復元する（Ｓ５３）。そして、ホーム中継器１２は、復元されたＢｒｏｗｓｅアクション要求メッセージ内の宛先情報を抽出し、ＵＰｎＰプロトコルに基づいて、抽出された宛先情報が示すデバイス（ここでは、メディアサーバ１１）がホームネットワーク１０上に存在しているか否かを確認する（Ｓ５４）。
【００８０】
メディアサーバ１１がネットワーク上に存在しているのを確認した後、ホーム中継器１２は、指定された宛先情報に対してＢｒｏｗｓｅアクション要求メッセージを送信する（Ｓ５５）。
【００８１】
メディアサーバ１１は、Ｂｒｏｗｓｅアクション要求メッセージを受信する（Ｓ５６）。そして、アクションに応じた応答メッセージを作成する（Ｓ５７）。応答メッセージの一例を図１５に示す。応答メッセージは、サービス名を登録するためのフィールドと、アクション名を登録するためのフィールドと、その応答メッセージ固有のメタデータを登録するためのフィールドとを備える。ここでは、Ｂｒｏｗｓｅアクションの応答メッセージは、コンテンツリストを含む。コンテンツリストは、メディアサーバ１１が蓄積するコンテンツを列挙する。具体的には、コンテンツリストは、各コンテンツのタイトルやアルバム名等のコンテンツＩＤと、そのコンテンツの格納場所であるコンテンツＵＲＬとを含む。メディアサーバ１１は作成した応答メッセージをホーム中継器１２に送信する（Ｓ５７）。
【００８２】
ホーム中継器１２は、応答メッセージを受信し、応答メッセージをパケット化して外部中継器２１に送信する（Ｓ５８）。このとき、パケットヘッダには、Ｂｒｏｗｓｅアクション要求メッセージに対する応答メッセージ識別子がメッセージタイプ情報として付与される。
【００８３】
外部中継器２１は、応答メッセージのパケットを受信する（Ｓ５９）。そして、パケットヘッダに付与されたメッセージタイプ情報を読み出す。メッセージタイプがアクション要求メッセージに対する応答メッセージであるため、外部中継器２１は、応答メッセージを復元する（Ｓ５９）。
【００８４】
外部中継器２１は、復元された応答メッセージを解析し、ＵＲＬを含むものについては、加工する（Ｓ６０〜Ｓ６３）。外部中継器２１はまず、受信した応答メッセージが宛先情報の変換対象となっているか否かを判断する（Ｓ６０）。外部中継器２１は、応答メッセージ内のサービス名及びアクション名を抽出し、抽出されたサービス名及びアクション名を図１２に示した宛先情報変換テーブルで検索する。サービス名及びアクション名が検索できない場合（Ｓ６０でＮＯ）、応答メッセージには宛先情報が含まれていないため、応答メッセージの内容を変更することなくそのままコントロールポイント２２に送信する（Ｓ６３）。
【００８５】
一方、図１５に示す応答メッセージを受け取った場合、サービス名及びアクション名が宛先情報変換テーブルから検索される（Ｓ６０でＹＥＳ）。このとき、外部中継器２１は、宛先情報変換テーブル内の検索されたサービス名（ＣＤＳ）及びアクション名（Ｂｒｏｗｓｅ）に対応するパラメータ位置を参照する。図１２では、パラメータ位置が「１」となっているため、外部中継器２１は、応答メッセージ内の先頭（１番目）のパラメータを抽出し、パラメータ内の宛先情報を特定する（Ｓ６１）。ここでは、コンテンツリストに列挙されたコンテンツＩＤ１及びＩＤ２の宛先情報（ＵＲＬｃｏｎ１及びＵＲＬｃｏｎ２）が特定される。そして、外部中継器２１は、特定された宛先情報（ＵＲＬｃｏｎ１及びＵＲＬｃｏｎ２）を外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）に変換する（Ｓ６２）。外部中継器２１はさらに、特定されたコンテンツＩＤ１及びＩＤ２の所在を示すＵＲＬｃｏｎ１及びＵＲＬｃｏｎ２をコンテンツリストの該当するコンテンツに対応付けて逆変換情報として記述する。つまり、外部中継器２１は、図１６に示すように、自身のローカルＩＰ（ＵＲＬｅｘ）を宛先情報とし、メディアサーバ１１のローカルＩＰを逆変換情報としてコンテンツリストに埋め込む。
【００８６】
図１７にステップＳ５９で復元された応答メッセージの具体例を示す。この場合、１番目のパラメータは、ＤＩＤＬ−Ｌｉｔｅタグで囲まれたエレメント（以下、ＤＩＤＬ−Ｌｉｔｅエレメントと称する）である。そのため、外部中継器２１は、ＤＩＤＬ−Ｌｉｔｅエレメントを抽出し、現在宛先情報となっているコンテンツの所在ＵＲＬ（図中下線を示す）を特定する。そして、図１８に下線で示すように、宛先情報として外部中継器２１のローカルＩＰを記述し、逆変換情報として、宛先情報の後ろに、各コンテンツの所在ＵＲＬを記述する。
【００８７】
外部中継器２１はステップＳ６２で加工された応答メッセージをコントロールポイント２２に送信し（Ｓ６３）、コントロールポイント２２は、応答メッセージを受信して記憶する（Ｓ６４）。
【００８８】
以上の動作により、コントロール動作でもＵＲＬ逆変換処理を行うことで、コントロールポイント２２は、アクション要求メッセージを異なるサブネットのＵＰｎＰデバイスに送信でき、異なるサブネットのＵＰｎＰデバイスから応答メッセージを受けることができる。さらに、受けた応答メッセージが宛先情報を含む場合、ＵＲＬ変換を実効する。これにより、応答メッセージに基づいて新たなアクション要求メッセージを送信するときも、アクション要求メッセージに逆変換情報を埋め込むことができる。そのため、外部中継器２１にＵＲＬ逆変換処理を実行させ、異なるサブネットのＵＰｎＰデバイスにメッセージを送信できる。
【００８９】
［イベンティング］
コントロールポイント２２がメディアサーバ１１内の所望のサービスに対してイベントのＳｕｂｓｃｒｉｂｅを要求するときのネットワークシステムの動作（イベンティング）を説明する。イベンティングは、サービスディスクリプションで記述されている状態変数が変更されたとき、Ｓｕｂｓｃｒｉｂｅを要求したＵＰｎＰデバイス（以下、サブスクライバともいう）にイベントを発行して状態の変更を通知する処理である。動作処理の基本は、上述の各処理（ディスカバリ、ディスクリプション、コントロール）と同じく、宛先情報を含むメッセージに対してＵＲＬ変換又はＵＲＬ逆変換を施すことにより、異なるサブネットのＵＰｎＰデバイス同士の通信を可能としている。
【００９０】
図１９を参照して、コントロールポイント２２は、ＧＥＮＡを用いてＳｕｂｓｃｒｉｂｅ要求メッセージを作成し、送信する（Ｓ７１）。作成されたＳｕｂｓｃｒｉｂｅ要求メッセージのデータ構造を図２０に示す。Ｓｕｂｓｃｒｉｂｅ要求メッセージは、Ｓｕｂｓｃｒｉｂｅを要求するサービスの所在を登録するための宛先情報を含む。ここで、サービスの宛先情報は、取得されたデバイスディスクリプション内の所望のサービスＩＤに対応する宛先情報であり、外部中継器２１のローカルＩＰ（ＵＲＬｅｘ）である。さらに、サービスの真の所在（ここでは、ＵＲＬｓ１とする）を逆変換情報として記述する。
【００９１】
Ｓｕｂｓｃｒｉｂｅ要求メッセージはさらに、Ｓｕｂｓｃｒｉｂｅの要求元（つまり、サブスクライバ）であるコントロールポイント２２の所在（ローカルＩＰ）をＣＡＬＬＢＡＣＫ情報として記述する。Ｓｕｂｓｃｒｉｂｅ要求を受け付けたサービスがイベントの送信先を知るためである。
【００９２】
コントロールポイント２２は、Ｓｕｂｓｃｒｉｂｅ要求メッセージ内の宛先情報に（つまり、外部中継器２１に）、作成されたＢｒｏｗｓｅアクション要求メッセージを送信する（Ｓ７１）。つまり外部中継器２１が所望のサービスの代理としてＳｕｂｓｃｒｉｂｅ要求メッセージを受け取る。以降、外部中継器２１がＵＲＬ逆変換を行う処理は、上述のステップＳ２１〜Ｓ２５のとおりである。
【００９３】
ホーム中継器１２は、外部中継器２１から送信されたパケットを受信する（Ｓ７２）。このとき、パケットヘッダには、メッセージタイプ情報として、Ｓｕｂｓｃｒｉｂｅ要求メッセージの識別子が含まれる。
【００９４】
ホーム中継器１２は、メッセージタイプ情報を読み出し、Ｓｕｂｓｃｒｉｂｅ要求メッセージを受けたと判断する（Ｓ７２）。そこで、パケットからＳｕｂｓｃｒｉｂｅ要求メッセージを復元する（Ｓ７３）。
【００９５】
復元されたＳｕｂｓｃｒｉｂｅ要求メッセージは、ＣＡＬＬＢＡＣＫ情報として、コントロールポイント２２のローカルＩＰ（ＵＲＬｃｐ）が登録されている。このままＳｕｂｓｃｒｉｂｅ要求メッセージをメディアサーバ１１に送信すれば、メディアサーバ１１内のサービスは、イベントをコントロールポイント２２に送信できない。なぜなら、ＣＡＬＬＢＡＣＫ情報として記述されたコントロールポイント２２のＵＲＬｃｐは、メディアサーバ１１が属するホームネットワーク１０のローカルＩＰではなく、ホームネットワーク１０と異なるサブネットである外部ネットワーク２０のローカルＩＰであるためである。したがって、ホーム中継器１２は、メディアサーバ１１のサービスが発行するイベントをコントロールポイント２２に中継するために、メディアサーバ１１のサービスに対してホーム中継器１２自身がサブスクライバであると認識させ、イベントを送信してもらう処理を行う。
【００９６】
ホーム中継器１２は、図２１に示すように、Ｓｕｂｓｃｒｉｂｅ要求メッセージ内のＣＡＬＬＢＡＣＫ情報として自身のローカルＩＰ（ＵＲＬｈｏ）を記述する。そして、コントロールポイント２２のローカルＩＰ（ＵＲＬｃｐ）を逆変換情報として記述する。つまり、ホーム中継器１２は、ＵＲＬ変換処理を実行する（Ｓ７４）。ホーム中継器１２は、変換されたＳｕｂｓｃｒｉｂｅ要求メッセージをメディアサーバ１１に送信する（Ｓ７５）。
【００９７】
メディアサーバ１１内のサービスは、Ｓｕｂｓｃｒｉｂｅ要求メッセージを受信する（Ｓ７６）。そして、サブスクライバの宛先情報及び逆変換情報を記憶する。
【００９８】
続いて、メディアサーバ１１は、Ｓｕｂｓｃｒｉｂｅ応答メッセージを作成し、送信する（Ｓ７７）。Ｓｕｂｓｃｒｉｂｅ応答メッセージとは、Ｓｕｂｓｃｒｉｂｅを受理した旨を示すメッセージであり、宛先情報を含まない。そのため、ホーム中継器１２は受けた応答メッセージをそのまま外部中継器２１に送信する（Ｓ７８）。そして、外部中継器２１も応答メッセージを受け（Ｓ７９）、そのままコントロールポイント２２に送信する（Ｓ８０）。コントロールポイント２２は、応答メッセージを受け、Ｓｕｂｓｃｒｉｂｅが受理されたと認識する（Ｓ８１）。
【００９９】
以上の動作により、メディアサーバ１１は、コントロールポイント２２からＳｕｂｓｃｒｉｂｅ要求を受けるとき、ホーム中継器１２のローカルＩＰを宛先情報として蓄積し、コントロールポイント２２のローカルＩＰを逆変換情報として蓄積する。
【０１００】
イベントメッセージを送信するときのメディアサーバ１１の動作はコントロールポイント２２のデバイスディスクリプション要求メッセージを送信するときと同じであり、イベントメッセージを受けるホーム中継器１２の動作は、デバイスディスクリプション要求メッセージを受ける外部中継器２１の動作と同じである。つまり、ホーム中継器１２がＵＲＬ逆変換処理を行うため、メディアサーバ１１は、イベントメッセージを、異なるサブネットのコントロールポイント２２に送信することができる。
【０１０１】
以上、本実施の形態では、ＵＰｎＰデバイスをメディアサーバ１１としたが、ＵＰｎＰデバイスはメディアサーバ１１以外の他の機器でもよい。たとえば、プリンタやテレビ、レコーダ等でもよい。
【０１０２】
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
【図面の簡単な説明】
【０１０３】
【図１】本発明の実施の形態によるネットワークシステムの構成を示す機能ブロック図である。
【図２】図１に示した中継器の構成を示す図である。
【図３】図１に示したネットワークシステムのディスカバリ処理の詳細を示すフロー図である。
【図４】図３中で作成される検出メッセージの一例を示す図である。
【図５】図３中で作成される検出応答メッセージの一例を示す図である。
【図６】図３中で宛先情報が変換された検出応答メッセージの一例を示す図である。
【図７】図１中のメディアサーバが持つデバイスディスクリプションの一例を示す図である。
【図８】図１に示したネットワークシステムのディスクリプション処理の詳細を示すフロー図である。
【図９】図８中で作成されるデバイスディスクリプション要求メッセージの一例を示す図である。
【図１０】図８中で外部中継器により変更されたデバイスディスクリプションの一例を示す図である。
【図１１】図８中で作成されるサービスディスクリプションの一例を示す図である。
【図１２】図１に示した外部中継器が持つ宛先情報変換テーブルの一例を示す図である。
【図１３】図１に示したネットワークシステムのコントロール処理の詳細を示すフロー図である。
【図１４】図１３中で作成されるアクション要求メッセージの一例を示す図である。
【図１５】図１４に示したアクション要求メッセージに対応して作成される応答メッセージの一例を示す図である。
【図１６】図１３中で外部中継器により変更された応答メッセージの一例を示す図である。
【図１７】図１５に示す応答メッセージの他の一例を示す図である。
【図１８】図１６に示す応答メッセージの他の一例を示す図である。
【図１９】図１に示したネットワークシステムのイベンティング処理の詳細を示すフロー図である。
【図２０】図１９中で作成される要求メッセージの一例を示す図である。
【図２１】図１９中のホーム中継器で変更された要求メッセージの一例を示す図である。
【符号の説明】
【０１０４】
１０  ホームネットワーク
１１  メディアサーバ
１２  ホーム中継器
２０  外部ネットワーク
２１  外部中継器
２２  コントロールポイント
【図１】
0004900169.tif 000002
【図２】
0004900169.tif 000003
【図３】
0004900169.tif 000004
【図４】
0004900169.tif 000005
【図５】
0004900169.tif 000006
【図６】
0004900169.tif 000007
【図７】
0004900169.tif 000008
【図８】
0004900169.tif 000009
【図９】
0004900169.tif 000010
【図１０】
0004900169.tif 000011
【図１１】
0004900169.tif 000012
【図１２】
0004900169.tif 000013
【図１３】
0004900169.tif 000014
【図１４】
0004900169.tif 000015
【図１５】
0004900169.tif 000016
【図１６】
0004900169.tif 000017
【図１７】
0004900169.tif 000018
【図１８】
0004900169.tif 000019
【図１９】
0004900169.tif 000020
【図２０】
0004900169.tif 000021
【図２１】
0004900169.tif 000022