(57)【要約】その機器がファイアウォール（１１６）、ネットワークアドレストランスレータ、あるいは直接の終端間通信を妨げるその他のエンティティの背後にある場合でも、セッション開始プロトコル（ＳＩＰ）を使用して、機器と直接通信するＳＩＰ機能を活用することにより、ネットワーク対応機器と通信する。遠隔のユーザエージェントクライアント（ＵＡＣ）（１００）は、インターネットを通じ、プロキシサーバ（１１６）を介して、例えばクライアントの住宅など、機器の場所にあるユーザエージェントサーバ（２０４）にメッセージを送信する。この通信チャネルは、クライアントが機器を制御し、機器のステータスを判定することを可能にする。この操作を可能にするために、従来のＳＩＰメッセージを、他の形でＳＩＰメッセージ中に明示される位置情報を含まないユニバーサルリソースロケータ（ＵＲＬ）と、ネットワーク対応機器に固有のコントロールおよび／またはクエリー指示を含む汎用化されたペイロード本体とを含むＤＯメッセージに拡張する。コマンドメッセージがＳＩＰ  ＩＮＶＩＴＥタイプである場合、そのメッセージは機器の記述を含む。
2004523828.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと少なくとも１つのネットワーク対応機器との間の通信のためのセッション開始プロトコル（ＳＩＰ）システムであって、
前記機器にコマンドを中継し、前記機器からのステータス情報を受信するように前記機器に接続されたユーザエージェントサーバ（ＵＡＳ）プロセッサと、
通信ネットワークを通じて、前記ＵＡＳプロセッサに前記機器を対象とするＳＩＰコマンドメッセージを送信し、かつ、前記機器についてのステータス情報メッセージを前記ＵＡＳプロセッサから受信する機能を有するユーザエージェントクライアント（ＵＡＣ）プロセッサであって、前記ＵＡＳプロセッサは、受信したＳＩＰコマンドを機器によって認識されるコマンドに変換し、かつ、前記機器から提供される情報を、前記通信ネットワークを通じて前記ＵＡＣプロセッサに伝送するＳＩＰステータスメッセージに変換するユーザエージェントクライアント（ＵＡＣ）プロセッサとを備え、
前記ＳＩＰコマンドメッセージは、前記ＳＩＰメッセージに他の形で指示される位置情報を含まないユニバーサルリソースロケータ（ＵＲＬ）を含み、前記コマンドメッセージは、機器に固有のコントロールおよびクエリー命令の少なくとも１つを含む汎用化されたペイロード本体を有する
ことを特徴とするセッション開始プロトコル（ＳＩＰ）システム。
【請求項２】
前記コマンドメッセージは、確立段階を除去した接続を有するＳＩＰメッセージタイプであることを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項３】
前記コマンドメッセージはＳＩＰ ＤＯタイプであることを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項４】
前記コマンドメッセージのペイロードは、デバイスメッセージングプロトコル（ＤＭＰ）ＭＩＭＥタイプであることを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項５】
前記コマンドメッセージがＳＩＰ  ＩＮＶＩＴＥタイプのとき、そのコマンドメッセージは前記機器の記述を含むことを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項６】
前記機器はＳＩＰ対応型であり、前記ＵＡＳプロセッサからの信号を直接解釈することができるようにしたことを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項７】
前記ＵＡＳプロセッサと前記機器の間に位置する機器コントローラをさらに含み、前記コントローラは、前記ＵＡＳプロセッサからのコマンドを前記機器の動作を制御する信号に変換し、かつ、前記機器からのステータス信号を前記ＵＡＳプロセッサによって変換できる信号に変換することを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項８】
クライアントと、１つの地理的範囲内にある複数のネットワーク対応機器の少なくとも１つとの間の通信のためのセッション開始プロトコル（ＳＩＰ）システムであって、
ローカルエリアネットワークにより前記機器の少なくとも２つに接続されたユーザエージェントサーバ（ＵＡＳ）プロセッサであって、前記ＵＡＳプロセッサは、前記少なくとも２つの機器の選択された少なくとも１つにコマンドを導いて前記少なくとも１つの機器からステータス情報を受信するようにアドレスマッピング機能を有するプロセッサと、
通信ネットワークを通じて、前記ＵＡＳプロセッサに前記少なくとも１つの機器を対象とするＳＩＰコマンドメッセージを送信し、かつ、前記少なくとも１つの機器についてのステータス情報メッセージを前記ＵＡＳプロセッサから受信する機能を有するユーザエージェントクライアント（ＵＡＣ）プロセッサであって、前記ＵＡＳプロセッサは、受信したＳＩＰコマンドを機器によって認識されるコマンドに変換し、かつ、前記少なくとも１つの機器から提供される情報を、前記通信ネットワークを通じて前記ＵＡＣプロセッサに伝送するＳＩＰステータスメッセージに変換するユーザエージェントクライアント（ＵＡＣ）プロセッサとを備え、
前記ＳＩＰコマンドメッセージは、前記ＳＩＰメッセージに他の形で指示される位置情報を含まないユニバーサルリソースロケータ（ＵＲＬ）を含み、前記コマンドメッセージは前記メッセージが宛先とする機器を識別し、かつ、前記コマンドメッセージは、機器に固有のコントロールおよびクエリー命令の少なくとも１つを含む汎用化されたペイロード本体を有する
ことを特徴とするセッション開始プロトコル（ＳＩＰ）システム。
【請求項９】
前記複数の機器それぞれからのステータス情報は、そのステータス情報が発信された機器を識別し、かつ、前記ＵＡＳプロセッサのアドレスマッピングは、前記ＵＡＣに送信される前記ＳＩＰステータスメッセージ中の機器の識別を含むことを特徴とする請求項８に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１０】
複数の位置があり、各位置に複数のネットワーク対応機器があり、かつ、各位置は、その位置にある複数の機器に接続された異なるＵＡＳによってサービスされることを特徴とする請求項８に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１１】
前記ＵＡＣプロセッサと前記複数のＵＡＳプロセッサの間を通る信号は、少なくとも１つのプロキシサーバを通過することを特徴とする請求項１０に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１２】
複数の地理的位置があり、各位置に複数のネットワーク対応機器があり、
それぞれが前記位置の別々の１つにサービスし、かつ、その位置にある前記複数の機器に接続された複数のＵＡＳプロセッサがあり、ある位置の前記ネットワーク機器は、付随するＵＡＳプロセッサだけに接続され、互いの機器とは接続されておらず、
前記ＵＡＳプロセッサは、前記機器へのメッセージおよび前記機器からのメッセージを処理するアドレスマッピング機能を備えず、かつ、
前記ＵＡＳプロセッサの少なくとも２つに接続された少なくとも１つのプロキシサーバをさらに含み、前記プロキシサーバは、適切なＵＡＳプロセッサを通じてメッセージの宛先である機器にメッセージを導くアドレスマッピング機能を有する
ことを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１３】
インスタントメッセージングのために識別されるＳＩＰ  ＩＮＶＩＴＥ、ＳＵＢＳＣＲＩＢＥ、およびＮＯＴＩＦＹメッセージタイプをさらに利用することを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１４】
ＳＩＰ  ＲＥＧＩＳＴＥＲメッセージタイプをさらに含むことを特徴とする請求項１３に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１５】
登録情報は暗号化されることを特徴とする請求項１４に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１６】
コマンドメッセージが認証されることを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１７】
前記認証は、前記メッセージのＴｉｍｅｓｔａｍｐ：フィールドおよびＣｓｅｑ：フィールドの１つをそれまでに記憶されたメッセージと比較することによる、反復されるメッセージのチェックを用いて行われることを特徴とする請求項１６に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１８】
前記認証は、前記Ｔｉｍｅｓｔａｍｐフィールドを現在のシステム時刻と比較して行われることを特徴とする請求項１６に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項１９】
コマンドメッセージは暗号化されることを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項２０】
コマンドメッセージは公開鍵で暗号化されることを特徴とする請求項１９に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項２１】
コマンドメッセージは、秘密鍵とパスワードの１つで暗号化されることを特徴とする請求項１９に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項２２】
コマンドメッセージは、そのＵＲＬ部分を暗号化して＠の左側に有することを特徴とする請求項１に記載のセッション開始プロトコル（ＳＩＰ）システム。
【請求項２３】
クライアントと少なくとも１つのネットワーク対応機器との間の通信の方法であって、
少なくとも１つのＳＩＰコマンドメッセージを形成するステップであって、前記ＳＩＰコマンドメッセージは、前記ＳＩＰメッセージ中に他の形で指示される位置情報を含まないユニバーサルリソースロケータ（ＵＲＬ）と、機器に固有のコントロールおよびクエリー命令の少なくとも１つを含む汎用化されたペイロード本体とを含むステップと、
ユーザエージェントクライアント（ＵＡＣ）プロセッサを用いて、通信ネットワークを通じて前記機器に付随するユーザエージェントサーバ（ＵＡＳ）プロセッサに前記ＳＩＰコマンドメッセージを送信するステップと、
前記ＵＡＳプロセッサで、前記機器を対象とする前記コマンドメッセージを受信するステップと、
受信したＳＩＰコマンドを前記機器によって認識される命令に変換するステップと、
前記命令を前記機器に送信するステップと
を含むことを特徴とする方法。
【請求項２４】
前記コマンドメッセージはクエリーであり、さらに、
コマンドメッセージクエリーに応答して、前記ＵＡＳプロセッサで前記機器からのステータス情報を受信するステップと、
前記ステータス情報をＳＩＰプロトコルステータスメッセージに変換するステップと、
前記通信ネットワークを通じて前記プロトコルステータスメッセージを前記ＵＡＣプロセッサに伝送するステップと、
前記ステータスを前記ＵＡＣプロセッサで表示するステップと
を含むことを特徴とする請求項２３に記載のクライアントと少なくとも１つのネットワーク対応機器との間の通信の方法。
【請求項２５】
前記送信するステップおよび伝送するステップは、少なくとも１つのプロキシサーバを通じた通信を介することを特徴とする請求項２４に記載のクライアントと少なくとも１つのネットワーク対応機器との間の通信の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、本願と同時に出願され、本発明の譲受人に譲渡された「System and Method For Out-Sourcing The Functionality of Session Initiation Protocol (SIP) User Agent to Proxies」という名称の米国特許出願０９／７７４，９６４（整理番号ＡＰＰ１３００）に関連する。本願は、本願と同時に出願され、本発明の譲受人に譲渡された「Smart Appliance Network System and Communication Protocol」という名称の米国特許出願０９/７７５，０００（整理番号ＡＰＰ１２５７）にも関連する。
【０００２】
本発明は、ネットワーク対応機器の操作を行うためのネットワークを通じたコントロール信号およびステータス信号の通信に関し、より詳細には、複数のネットワーク対応機器との通信を改良するためのセッション開始プロトコルの使用に関する。
【背景技術】
【０００３】
共にネットワーク化された機器のリモートコントロールは、新しく、成長しつつある対象領域である。典型的な実施形態では、住宅ではそこに備わる機器のすべてまたは多くをネットワークに接続することができる。そのようなシステムを備えると、住宅の所有者は、オフィスを出る前であっても、ネットワークにアクセスし、車庫に通じる道の照明をつけ、コーヒーメーカーを開始させ、住宅内の温度を上げ下げすることができる。また、冷蔵庫が食料品の在庫品を管理し、必要なときには再注文することもできる。時計はユーザの予定を調整し、あるいはある機器のスイッチを入れることができる。この機能を実現するには、例えば目覚まし時計が寝室の照明をつけることができるように、それらの機器が相互に通信する必要があることが明白である。
【０００４】
ネットワーク対応機器（ＮＡ）は、少なくとも１つのネットワーク化されたプロセッサを含む専用の消費者デバイスである。代替法として、従来の機器を、リモートメッセージを受け付け、所望の方式で機器を制御する機器コントローラに接続することができる。その結果、各コントローラで相当量のコンピューティング力が必要とされる。
【０００５】
ネットワーク対応機器システムには、住居外部での通信を検討する際に対応する必要がある次のような考慮事項がある。
・セキュリティ−  住宅内通信では、その外部からの任意のアクセスが許可されると失われる、あるレベルの物理的セキュリティを使用する。
・認証−  住宅内に入ろうとするエンティティは、アクセスを許可する前に明確に識別する必要がある。
・信頼性−  住宅外アクセスはその性質として広範囲にわたるために障害の地点も増す。住宅は、外部システムとの通信が失われたときにその外部システムに依存せずに動作を続けるべきである。
・スケーリング−  非常に多くの住宅が存在する。
・プロトコルの独立性−  単一の住宅内では、デバイス間の通信に多くの異なるプロトコルを使用することが許容されるが、住宅内ネットワークを構成するデバイスの正確な詳細は外部世界から知ることができないので、広域には、はるかにプロトコル非依存型の方式が必要とされる。
・ネーミングおよび場所−  住宅内のデバイスは、明確に名前をつけ、その場所を住宅の外部から識別する必要がある。
外部世界から住宅内のデバイスの制御を行えるようにするための技術が開発されつつあり、最も顕著な例はオープンサービスゲートウェイイニシアチブ（ＯＳＧｉ）によるものである。ｗｗｗ．ｏｓｇｉ．ｏｒｇのＯＳＧｉを参照されたい。しかし、この従来のシステムはなお広域でのアクセスとセキュリティの一般的な問題、並びに上述のその他の課題に対処していない。これらのシステムは、インターネットを通じた通信のための一律のプロトコルを提供しない。
【０００６】
インターネットエンジニアリングタスクフォース（「ＩＥＴＦ」）は、いくつかの異なる通信モードに対応することができる、セッション開始プロトコル（「ＳＩＰ」）と称する通信プロトコルを開発した。提案される標準ＲＦＣ２５４３によると、ＳＩＰは、１つまたは複数の関係者間に双方向の通信セッションを作成し、修正し、終了する、アプリケーション層のコントロールおよびシグナリングプロトコルである。ＳＩＰは、ＨＴＴＰおよびＳＭＴＰ同様のテキストベースのプロトコルである。このセッションは、音声、ビデオ、チャット、双方向ゲーム、およびインターネットマルチメディア会議や、インターネット電話の呼出し、マルチメディア配布などのバーチャルリアリティを含むことができる。セッションのメンバーは、マルチキャスト、ユニキャスト関係のメッシュ、あるいはこれらの組合せを介して通信することができる。
【０００７】
ＳＩＰインビテーション（すなわちＳＩＰメソッドＩＮＶＩＴＥ）を使用してセッションを作成する。このインビテーションは、関係者が互換性のある媒体タイプに同意することを可能にするセッション記述を搬送することができる。ＳＩＰは、代理として要求を受け、ユーザが登録することができるユーザの現在の場所に要求をリダイレクトすることによりユーザの可動性をサポートする。ＳＩＰは、どの特定の会議コントロールプロトコルにも結び付けられず、より低層のトランスポートプロトコルに依存しないように設計される。
【０００８】
ＳＩＰアーキテクチャはユーザエージェントを含み、ユーザエージェントは、ユーザエージェントクライアント（「ＵＡＣ」）およびユーザエージェントサーバ（「ＵＡＳ」）の両方として機能することができるアプリケーションプログラムを実行するデバイスである。クライアントは、ＳＩＰ要求を送信するアプリケーションプログラムである。クライアントは、人間のユーザと直接対話してもしなくともよい。
【０００９】
サーバは、要求にサービスするためにクライアントから要求を受け付け、その要求に対する応答を送り返すアプリケーションプログラムである。したがって、ＵＡＳは、ＳＩＰ要求を受信した際にユーザに接触し、ユーザに代わって応答を戻すサーバアプリケーションである。応答は、要求を受け付けるか、拒絶するか、またはリダイレクトする。
【００１０】
また、ユーザエージェントではないサーバがある。このサーバは、プロキシサーバ、リダイレクトサーバ、またはレジストラサーバである。プロキシサーバは、他のクライアントに代わって要求を行うためにサーバおよびクライアントの両方として機能する中間プログラムである。要求はプロキシサーバによって内部でサービスされるか、または可能性としては変換した後にプロキシサーバによって他のサーバに渡される。プロキシサーバは、要求メッセージを解釈し、必要な場合は書き直してから転送する。インターネットのコンテクストでは、異なるＵＲＬを有するホストに向けられるものであってもプロキシサーバがＵＡＣからの要求を受信する。処理後、プロキシサーバはその要求を宛先ＵＲＬに送信する。
【００１１】
リダイレクトサーバは、ＳＩＰ要求を受け付け、ゼロ個またはそれ以上の新しいアドレス中にアドレスをマッピングし、そのアドレスをクライアントに戻すサーバである。プロキシサーバと異なり、リダイレクトサーバはそれ自体のＳＩＰ要求は開始しない。ＵＡＳと異なり、リダイレクトサーバは呼出しを受け付けない。
【００１２】
レジストラサーバは、ＲＥＧＩＳＴＥＲ要求を受け付けるサーバである。レジストラサーバは、そのエリア内のＵＡＳデバイスについてそれが受け取る登録されたアドレスのリストを保持し、通例はプロキシサーバまたはリダイレクトサーバと同じ場所に置かれ、それらと情報を共有することができる。
【００１３】
ＳＩＰコンフィギュレーションでは、ＵＡＣは、１つまたは複数のプロキシサーバを介してＵＡＳに要求を送信する。通例、１つのＵＡＣは、複数のＵＡＳをアドレス指定してよく、あるいはアドレス指定する機能を持つ。さらに、標準的なＳＩＰアーキテクチャでは、エンドポイント、すなわちＵＡＳは常に相互と直接通信することができる。この構造を典型的なマルチメディア会議に適用すると、コントロールアプリケーションは、呼出しを開始し、他者を会議に誘うＵＡＣとして機能し、誘いを受けるＵＡＳとして機能する。ＵＡＣおよびＵＡＳの役割はプロキシサーバおよびリダイレクトサーバと同様に、要求単位で定義される。例えば、呼出しを開始するユーザエージェントは、最初のＩＮＶＩＴＥ要求を送信する際にはＵＡＣとして機能し、呼び出されたデバイスからＢＹＥ要求を受信する際にはＵＡＳとして機能する。同様に、同じソフトウェアが、ある要求についてはプロキシサーバとして機能し、次の要求についてはリダイレクトサーバとして機能することができる。ＳＩＰ  ＵＡＳは、通例、ＳＩＰ電話機、ＰＣ、およびＰＤＡに埋め込まれる。これらのＵＡＳデバイスは、メッセージの発信者を認証し、次いでそのエンティティが要求される動作を行うことを許可されているかどうかを（通例はアクセスコントロールリストを調べることにより）判定する役割を担う。
【００１４】
ＳＩＰアーキテクチャの特定の特性は、場所の面と通信（または動作）の面が単一のアクティビティに併合された任意のネットワークデバイスに対するより一般的な適用可能性があれば、ネットワーク対応機器との通信に有用である可能性があることを示唆する。詳細には、ＳＩＰは可動性を可能にし、すなわち新しい場所で再度登録するのであれば受信側デバイスを移動することができる。
【００１５】
ＳＩＰは、共通のコンテクスト（Ｃａｌｌ−ＩＤによって識別される）における要求−応答トランザクションのシーケンスからなるトランザクションサービスである。これは、会話（セッション）が第１のメッセージによって開始され、応答とその他のメッセージを共にグループ化するネットワーク対応機器接続にも当てはまる。さらに、ＳＩＰは、内容の搬送にＭＩＭＥを使用する。したがって、内容の意味と目的は要求メソッドと内容タイプに依存する。ＳＩＰは、通信に関わるユーザの識別に多数のヘッダフィールドを使用する。この機能は、ネットワーク対応機器接続で有用であると思われる。さらに、ＳＩＰは、リモートアクセスが可能なネットワーク対応機器システムに必要な認証ツールとセキュリティ機構を備える。
【００１６】
重要なのは、住宅外部からのアクセスを備えるネットワーク対応機器システムでは、要求元エージェントは、名前のつけられたオブジェクトに動作を行うための命令をメッセージで送信しなければならないことである。このメッセージは、動作を行うべきオブジェクトの名前をそのアドレスとして、また動作自体をペイロードとして含む。このメッセージは、エージェントからエージェントへとルーティングされ、名前を解決しながら進行する。例えば、「デーブの自宅の主寝室のランプのスイッチを入れる」というコマンドは、まずデーブの自宅の場所を知るサーバにルーティングされる。そして、メッセージはデーブの自宅のファイアウォールデバイスへとルーティングされ、そこでアクセスコントロールと認証が行われる。アクセスコントロールと認証が成功すると、次いでメッセージペイロードがデバイスに伝達されて要求される動作を行う。
【００１７】
ＳＩＰでは、名前機能によるこのルーティングはＩＮＶＩＴＥプロセスで実現される。詳細には、ＩＮＶＩＴＥはまずその名前のついてのエージェント、またはプロキシに送られる。プロキシは、名前を書き換え、ＩＮＶＩＴＥを中継し、メッセージの最終的な宛先に近づき、到着するとペイロード（従来はセッション記述プロトコル（ＳＤＰ）による）を伝達することができる。ロケーションおよびアクション（Location and Action）プロセスは、同じ手順で組み合わされる。また、ＳＩＰのセキュリティアーキテクチャは、これらの高レベルの名前に基づいた検証を可能にする。
【００１８】
【特許文献１】
米国特許出願公開第２００２／０１０３８５０号明細書
【特許文献２】
米国特許出願公開第２００３／００１８７０３号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかし、ＳＩＰの能力と、ネットワーク対応機器との通信のための識別される要件には基本的な２つの違いがある。第１に、ＳＩＰの位置情報は、インターネットドメイン名サーバ（ＤＮＳ）アドレスであるＵＲＬの形態である。しかし、すべてのネットワーク対応機器がＩＰアドレスを備えるわけではない（例えば機器コントローラの背後にあるＸ．１０デバイス）。第２に、ＳＩＰのＩＮＶＩＴＥメッセージが行うことができる唯一の動作は、ＳＤＰ（またはＩＳＵＰ／ＱＳＩＧなど何らかの他のＭＩＭＥタイプ）を使用して、関連付けられたベアラー（bearer）とのセッションをセットアップすることである。したがって、ＩＮＶＩＴＥメッセージはテレビ会議をセットアップすることはできるが、デバイスを制御するメッセージを伝送するようには設計されていない。
【００２０】
また、従来のネットワーク対応機器システムは、住宅外部からのアクセス、イベント、およびメディアストリーミングにセキュリティを提供しない。したがって、ネットワーク対応機器システムのすべての必要性を満たすようにＳＩＰまたは何らかの他のシステムを適合できると有用であると思われる。
【課題を解決するための手段】
【００２１】
本発明は、ネットワークを通じたメッセージのリモート通信を対象とし、より詳細には、ＳＩＰネットワークを使用したネットワーク機器の改良されたリモートコントロールを対象とする。これを実現するためには、ＳＩＰの一部の態様を修正しなければならない。詳細には、ＳＩＰコマンドメッセージは、位置情報が削除されたユニバーサルリソースロケータ（「ＵＲＬ」）を含む。この情報は、ＳＩＰメッセージの別の部分で他の形で指定する。さらに、「ＤＯ」と称する新しいコマンドメッセージを含むようにＳＩＰを拡張しなければならない。このＤＯタイプは、「接続確立段階」が除去されており、メッセージペイロードが汎用化されている。また、コマンドメッセージペイロードは、デバイスメッセージングプロトコル（ＤＭＰ）のＭＩＭＥタイプを有する。コマンドメッセージがＳＩＰ  ＩＮＶＩＴＥタイプである場合、メッセージは機器の記述を含む。
【００２２】
好ましい実施形態では、新しいＤＯタイプを扱うようにＳＩＰユーザエージェントおよびプロキシを修正する。そして、ＳＩＰユーザエージェントクライアントにより典型的なＳＩＰアーキテクチャを使用して、例えば住宅の所有者がオフィスからログインし、自宅の機器にメッセージを送信する。このメッセージは、何らかの形態のコマンドまたはステータスに対する要求であり、新しいＤＯメッセージの一部として伝送される。信号は、ユーザのオフィスの近くのアウトバウンドプロキシに渡され、プロキシは、ＳＩＰのチャレンジ−応答機構を用いて信号がそのユーザからのものであると認証する。アウトバウンドプロキシは、ＤＯメッセージのヘッダを読んで、メッセージを他のプロキシに渡していき、最終的にメッセージはユーザの自宅のファイアウォールまたは住宅用ゲートウェイに到達する。ＳＩＰ機能を使用して、ゲートウェイで要求を認証する。次いで、メッセージはユーザの自宅内のＬＡＮに渡され、ＬＡＮ内でターゲット機器に渡される。機器または機器に接続されたコントローラは、メッセージの受信をユーザに通知し、要求される動作を行い、またそのメッセージセッションをセットアップしたＣａｌｌ−ＩＤと同じＣａｌｌ−ＩＤでユーザにステータス情報を戻すことができる。
【００２３】
配置に応じて、ゲートウェイまたは個々の機器のユーザエージェントサーバ（ＵＡＳ）は、メッセージが所有者からのものであることだけでなく、要求される動作が許可されることも認証しなければならない。例えば、ユーザの子供は、照明をつけることは許可されるが、コーヒーメーカーのスイッチを入れることは許されない場合がある。したがって、認証と許可は、行う必要がある別個の動作である。さらに、ゲートウェイまたはＵＡＳは、メッセージのターゲットであるＬＡＮ上の特定デバイスを見つけるアドレスマッピング機能を備えなければならない。そして、ＵＡＳは、標準的なＳＩＰフォーマットから機器が理解できる形態にメッセージを変換することを必要とされる場合がある。
【００２４】
さらに、完全な機能性を備えるために、ネットワーク対応機器システムは、必要に応じてＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹメッセージを使用する。これらについては、Ａｄａｍ  Ｒｏａｃｈ「SIP Event Notification」に記載される。この文献のコピーはhttp://www.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-02.txt）で得ることができる。
【００２５】
本発明の上述およびその他の特徴は、以下の詳細な説明と本発明の例証的実施形態の図面からより容易に明らかになろう。
【発明を実施するための最良の形態】
【００２６】
本発明によると、ＳＩＰを基本アーキテクチャとして使用してリモート機器の制御を実施する。ただし、ＳＩＰをその目的で使用する前に一定の変更を行わなければならない。詳細には、ＳＩＰでは、「Ｔｏ」フィールドおよび「Ｆｒｏｍ」フィールドにある名前はユニバーサルリソースロケータ（ＵＲＬ）として符号化される。現在の実装はＳＩＰおよびＰＨＯＮＥ  ＵＲＬをサポートしている。しかし、このプロトコルの性質を変えることなく、ネットワーク対応機器システムのために新しいタイプのＵＲＬを定義しなければならない。この新しいＵＲＬタイプは、機器アドレスの「ユーザフレンドリー」な発見を可能にする。ＲＦＣ２６０９で定義されるサービスＵＲＬシンタックスを使用し、しかし位置情報（すでにＳＩＰルーティングを介して判定されている）を用いず、また「ｓｉｐ：」プレフィクスを用いない一例は、
d=lamp,r=bedroom
となる。
【００２７】
このＵＲＬをｂａｓｅ６４で符号化する（また可能性としては、ドメインに含まれるデバイスタイプに関する情報が漏れるのを防止するために暗号化する）ことにより、このＵＲＬをＳＩＰ  ＵＲＬの一部として構造化することが可能である；
a458fauzu3k3z@stan.home.net
【００２８】
このように、様々な機器に対応するように拡張した際でも、＜エンティティ＞＠＜場所＞という既存の構造が維持される。ただし、この提案するタイプのアドレス指定方式を使用することは必須ではない。平文（例えばtoaster@stan.home.net）、または＠記号の左側の部分を暗号化した（例えばa3245dsfs234@stan.home.net）標準的なＳＩＰ  ＵＲＬアドレス指定方式も、機能する有効なアドレスである。標準的なＳＩＰアドレス指定では、例えばlamp.bedroom@stann.home.netなど、階層的なアドレス指定さえ使用することができる。
【００２９】
ＳＩＰは当初呼出しのセットアップを念頭に置いて作成された。ＳＩＰは、２つの終端間に作動中のベアラーパスを確立できるように、２つの終端間に関係またはセッションを確立するものである。この構造は、ＳＩＰの接続の確立段階を除去し、ＳＩＰペイロードを汎用化すれば、「短命の」接続向けに汎用化することができる。現在のＳＩＰの使用方式と本発明による修正の違いは、多くの点でＴＣＰとＵＤＰまたは他のセッション／データグラムプロトコルとの違いに類似する。
【００３０】
インスタントメッセージングにＳＩＰを使用するイニシアチブの一部として現在新しいメソッドが定義されている。ＤＯと称するこのメソッドは、ネットワーク対応機器システムの要件を満たし、ＳＩＰ  ＩＮＶＩＴＥメッセージの典型的なＭＩＭＥペイロードであるセッション記述プロトコル（ＳＤＰ）以外のペイロードを搬送することができる。通信情報を搬送する標準的なＳＩＰの本体すなわちペイロードと異なり、ＤＯタイプは、ネットワーク対応機器からのステータス情報を導き、受信するために特有のコントロールコマンドおよびクエリーコマンドを含む。任意のＭＩＭＥタイプをＳＩＰコマンドのペイロードとして使用することができ、特定クラスのネットワーク対応機器のコマンドまたはクエリー（アクション言語）のために新しいＭＩＭＥタイプを容易に定義することができる。この新しいＭＩＭＥタイプの一例は、デバイスメッセージングプロトコル（ＤＭＰ）である。ＤＭＰは、ユニバーサルプラグアンドプレイデバイスコントロールプロトコルに同様のＸＭＬベースの仕様である。ｗｗｗ．ｕｐｎｐ．ｏｒｇのＵＰｎＰデバイスコントロールプロトコルを参照されたい。このように、ＤＯメッセージは、「照明のスイッチを入れる」などターゲット機器に適したコマンド、または「温度は何度か」などのクエリーを搬送する。コマンドは、その結果を示す単一の応答をトリガし、応答は標準的なＳＩＰ応答機構によって搬送される。
【００３１】
また、（ＲＥＧＩＳＴＥＲメッセージを介して）デバイスがプロキシに登録する際には、そのデバイスの記述を伝達しなければならない。これは、この情報を搬送するデバイス記述プロトコル（ＤＤＰ）によって実現される。ＤＭＰと同様にＤＤＰもＸＭＬベースである。
【００３２】
ＤＯタイプ要求の要求ＵＲＩは、そのメッセージが対象とする当事者を識別する通常のＳＩＰ  ＵＲＬである。従来のＳＩＰでそうであるように事前にセッションまたは接続を確立する必要はない。送信者は、所望の受信者のＵＲＬを必須の「Ｔｏ」フィールドに入れる。「Ｆｒｏｍ」フィールドは、メッセージの発信者を識別する。メッセージはＣａｌｌ−ＩＤも含まなくてはならない。ＳＩＰでは、Ｃａｌｌ−ＩＤを使用して要求の群を同一セッションに関連付ける。
【００３３】
各メッセージはＣｓｅｑを含み、これはシーケンス番号と要求のメソッドの名前を合わせたものである。Ｃｓｅｑは、セッション中の各メッセージを一意に識別し、続くメッセージごとに増加する。各ＤＯタイプは、「Ｖｉａヘッダ」も搬送する。Ｖｉａヘッダは、要求がトラバースしたシステムのＩＰアドレスまたはＦＱＤＮのトレースを含む。要求が受信者に向かってプロキシからプロキシへと移動する際には、スタックの操作と同じように、各プロキシは各自のアドレスを付加し、そのアドレスをヘッダ中に「プッシュ」する。アドレスのスタックは、応答中に反映され、各プロキシは一番上のアドレスを「ポップ」して取り除き、そのアドレスを使用してその応答をどこに送信するかを判定する。ＤＯ拡張を使用するクライアントは、要求に「Ｃｏｎｔａｃｔ」ヘッダを挿入しなければならない（Ｃｏｎｔａｃｔは、元のメッセージのターゲットから元のメッセージの開始者へと、要求を反対方向にルーティングするために使用される）。メッセージは本体も含む。本体は、受信者によってレンダリングされるメッセージを含む。ＳＩＰは、内容を識別する標準的なＭＩＭＥヘッダ（Content-Type、Content-Length、およびContent-Encoding）を使用する。要求は、ＵＤＰまたはＴＣＰまたはＳＣＴＰによる搬送を使用して送信しなければならない。ＵＤＰを通じて信頼性が保証され、単純な再送を通じて輻輳の制御が提供される。
【００３４】
ＳＩＰのＤＯタイプは、次のフォーマットと９つの部分を有する。
2004523828.tif 000003
角括弧内の部分は、内容の例を示す。
【００３５】
この構造は、ネットワーク対応機器との同期通信を確立する。ただし非同期通信を確立することも必要である。例えば、自宅でアラームが鳴り出した際、ある温度に達した際、あるいは誰かがドアベルを鳴らした際に通知されるように、システムは非同期通信が可能でなくてはならない。
【００３６】
ＳＩＰインスタントメッセージングシステムは、非同期通信を実現するために使用できるＳＵＢＳＣＲＩＢＥとＮＯＴＩＦＹの２つの新しいプリミティブを定義する。ここに提案するアドレッシング方式およびデバイスメッセージングプロトコルＭＩＭＥタイプと併せてこれら２つのメソッドを使用すると、ネットワーク対応機器からの、およびネットワーク対応機器間のイベント通知が可能になる。
【００３７】
図１に、典型的な従来技術のＳＩＰアーキテクチャを示す。この配置では、例えばインターネット電話ユーザなどのクライアントは、クライアント、すなわちＳＩＰ  ＵＡＣ１００として動作するＳＩＰユーザエージェントアプリケーションを使用して、インターネット電話呼出しの企図される受信者に関連付けることができる１つまたは複数のユーザエージェントサーバ（ＵＡＳ）とのＳＩＰ通信を開始する。このシステムは、ネットワークデバイスとのリモート通信を可能にする３つの異なるタイプのアーキテクチャをサポートする。実際の実装には、この３つのアーキテクチャの任意の組合せを使用することができる。
【００３８】
第１の配置では、クライアントアプリケーションＵＡＣ１００は、いくつかのＵＡＳデバイス１１０、１１２、１１６、および１１８の１つに直接接続し、対話することができる。この場合、クライアントはパス１３０を介して受信者のＵＡＳ１１０と直接接触を確立する。第２のアーキテクチャでは、クライアントアプリケーションが、例えばインターネット電話などのネットワークデバイスと通信するために、インターネット中のＳＩＰプロキシ１０４と対話する。第２のアーキテクチャでは、別のＳＩＰプロキシ１０４がＵＡＣ１００から、パス１３２を介して、例えばＵＡＳなど各種のＳＩＰ  ＵＡＳデバイスの１つに通信を渡す。
【００３９】
第３の配置では、初めに従来のＳＩＰメッセージまたは要求をＵＡＣ１００からインターネットＳＩＰプロキシサーバ１０４にルーティングし、プロキシサーバ１０４はその要求を処理し、ＳＩＰプロキシサーバ１０８に送信する。プロキシサーバ１０８は、例えばインターネット電話サービスなど特定のサービスに関連付けられる。このプロキシ１０８は次いで、それに関連付けられたいくつかのＵＡＳ１１０、１１２、１１４、１１６、１１８の１つに要求を送信する。各ＵＡＳは、例えばメッセージを受信するために選択された個人の住宅など別々の場所にあってよく、電話機などのデバイスに埋め込まれるか、または取り付けられる。要求がＳＩＰ  ＵＡＳ１１６に関連付けられた住宅に対するものであると仮定すると、メッセージはＵＡＳ１１６およびそれに取り付けられたデバイスに配信される。メッセージに基づいて、ＵＡＳ１１６はメッセージに従ってデバイスを操作する。
【００４０】
ＵＡＳ１１６は、メッセージを処理しデバイスに命令を送信する前に、メッセージがＵＡＳ１１６に向けたものであることと、許可された個人によって送信されたことを判定しなければならない。したがって、ＵＡＳ１１６、および他のすべてのＵＡＳは、メッセージの宛先アドレスを調べ、メッセージが許可されており、そのＵＡＳが解釈できるフォーマットであることを確認しなければならない。さらに、ＵＡＳは、取り付けられたデバイスが理解し、応答できるフォーマットにメッセージを変換することができなくてはならない。
【００４１】
本発明によりＤＯメソッドを含み、ＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹメソッドを利用するようにＳＩＰプロキシを拡張すると、各種のＳＩＰアーキテクチャを使用してネットワーク対応機器を制御することができる。３つの例の最も単純なアーキテクチャを図２に示し、このアーキテクチャではクライアントアプリケーションがホームドメイン２００中のネットワーク対応デバイスに直接接続し、対話することができる。例えばインターネットなどのワイドエリアネットワーク３００を使用して、ＳＩＰ  ＵＡＣ１００のクライアントアプリケーションから、ホームファイアウォール／ネットワークアドレストランスレータ（ＮＡＴ）の形態の住宅用ゲートウェイ（ＲＧＷ）であるＳＩＰ  ＵＡＳ１１６にメッセージを搬送する。認証されると、それらのメッセージはファイアウォールを通過することを許可される。ホームドメイン２００の内部では、ホームＬＡＮ２０１を通じて該当するネットワーク対応機器にメッセージが搬送される。デバイスは、デバイス２０２など、「ＩＰ対応」、すなわち入ってくるＳＩＰメッセージ自体を処理することができるか、あるいは機器２０６などＩＰ非対応機器であってもよい。ＩＰ非対応機器は、ＳＩＰコントロール要求をその機器に特有のプロトコルに変換する機器コントローラ２０４を必要とする。
【００４２】
多くの場合、クライアントアプリケーションがユーザのネットワーク対応機器に直接アクセスし、制御できるようにすることは可能でないか、または望ましくない。この状況は、以下を含むいくつかの理由により生じる可能性がある。
・機器がネットワークアドレストランスレータ（ＮＡＴ）の背後にあるために、機器のＩＰアドレスを判定することができない。
・機器がＩＰアドレスを持たない。
・住宅内のデバイスの可視性を最小限に維持することが求められる。
・セキュリティ上の理由から、ホームＵＡＳ（すなわちファイアウォール／ＮＡＴ）が、知られないソースからの通信をフィルタし、拒絶することが求められる。
・より精度の高いセキュリティ（すなわちデバイス／メッセージ単位の認証およびアクセスコントロール）が求められる。
【００４３】
この場合、ＵＡＣクライアントアプリケーションからのコントロールメッセージは、まず住宅内への可視性を持つ「信頼される」プロキシに送信しなければならない。このアーキテクチャは、クライアントアプリケーションと住宅用ゲートウェイ（ＲＧＷ）の間にプロキシサーバが提供される点を除いて、図２と同じである。プロキシサーバとホームファイアウォール／ＮＡＴ間のすべての通信は、セキュアであると想定する。図３に示す事例では、プロキシサーバは物理的にホームドメインのゲートウェイデバイス１１６’中に位置する。このプロキシサーバは、以下を含むいくつかの機能を提供することができる。
・各メッセージ／要求の認証および許可
・ホームドメイン内のネットワーク対応機器のアドレスマッピング／解決
・外部世界との通信のためのホームファイアウォール／ＮＡＴ（ＲＧＷ）のセキュリティ
・ネットワーク対応機器の可動性および追跡サービス
・クライアントアプリケーションのメッセージプロトコルマッピング。この方式をとることにより、ネットワーク対応機器をリモートコントロールするために各種のクライアントアプリケーションをサポートすることができる。
・サービスの課金ポイント
【００４４】
先のケース（すなわちゲートウェイデバイス中にプロキシがある）は、プロキシに多くの機能を必要とし、それによりパフォーマンス、メモリなどの点でゲートウェイデバイスに負担となる要件を課す可能性がある。ゲートウェイデバイスは、上述のプロキシ機能をサポートするのに必要とされるリソースを備えない場合があるので、機能の多くを（例えばネットワーク対応機器サービスプロバイダのネットワーク内の）外部プロキシ１０８に移すことができる。この外部プロキシ１０８は、先の項で述べた機能をすべて提供することができ、外部プロキシ１０８とゲートウェイプロキシ１１６’の間にセキュアな接続（例えばＩＰｓｅｃトンネル）が存在する場合には、ゲートウェイプロキシにはＳＩＰメッセージを適切なＵＡに転送することだけが求められる。ゲートウェイプロキシの機能の分割は、「すべてか無か」の決定である必要はなく、２つのプロキシ間で等しく（または不均等に）分割することができる。このアーキテクチャを図４に示す。この方式の利点は以下である。
・ＳＩＰプロキシの管理が中央で行われ、分散システムの問題が回避される。
・住宅へのローカルリンクに障害が起こったとしても、ワイドエリア３００からはサービスプロバイダプロキシ１０８を通じてなお機能を利用することができ、したがって、例えばシステムは別の住宅にメッセージをリダイレクトすることができる。
・ＲＧＷの構成が最小限に維持される。ただし、ＩＰｓｅｃトンネルの作成など何らかの制限された設定を行うことがなお必要である場合もある。
・サービスプロバイダを耐障害性にするコストを複数の住宅にわたって償却することができる。
【００４５】
図２〜図３の配置では、図１に示したＳＩＰ  ＵＡＳは住宅用ゲートウェイ（ＲＧＷ）であると考えられてきた。ただし、代替実施形態では、インターネット対応機器２０２および機器コントローラ２０４を、それらのプロキシサーバとしてのＲＧＷを備えるＳＩＰ  ＵＡＳデバイスと考えることもできる。ただし、この配置では、例えばコントローラ２０４が複数の機器を制御しないのであれば、ＵＡＳデバイスはアドレスマッピング機能を必要としない。
【００４６】
図５は、ネットワーク対応機器をサポートするためのＳＩＰアーキテクチャの機能図である。このアーキテクチャは、図３および図４のプロキシアーキテクチャを介したメッセージングに基づく。機能エンティティは、異なる物理的なネットワーク要素（図６参照）に分散することができる。上記の通り、ネットワーク対応機器の操作またはそのステータスを求める要求は、ＳＩＰ  ＵＡＣ１００の発信元クライアントアプリケーション（発信元アプリケーション）で開始する。発信元アプリケーションはＳＩＰ  ＵＡＣ１００を使用して機器メッセージ（ＤＯ）を生成し、サービスプロバイダまたはホームＲＧＷによってホストされるＳＩＰプロキシ１０８に送信する。サービスプロバイダドメイン中のＳＩＰプロキシ１０８は、位置データベース１４０で検索することにより、通信しようとする機器のアドレス（該当するホームドメインＲＧＷを含む）を解決する。ＳＩＰプロキシは、クライアントＳＩＰ  ＵＡ１００からホームドメインＲＧＷ中のＳＩＰプロキシ１１６’に機器メッセージを転送するか、またはセキュアな接続を介してターゲットデバイス中のＳＩＰ  ＵＡＳに直接転送する。
【００４７】
位置データベース１４０は、ホームドメイン内のすべての登録された機器の位置情報を含む。このデータベースには、登録手順中にサービスプロバイダのＳＩＰプロキシ１０８によって収集された情報が格納される。詳細には、ＲＥＧＩＳＴＥＲメッセージがプロキシ１０８に送信されてクライアントおよび各機器の位置を登録する。機器の場合、この登録は単にその機器がホームドメイン２００内にあるということでよい。さらに、これすら登録できない場合には、ホームドメイン２００のＩＰアドレスだけでよい。その場合、ユーザはホームドメイン中で利用できる機器を知っていることを求められる。そのドメインを宛先とする場合、メッセージは、プロキシ１１６’におけるアドレスマッピングによりその機器にアドレス指定される。
【００４８】
ホームドメインの住居ゲートウェイ中のＳＩＰプロキシ１１６’は、ホームドメイン内の機器と、ワイドエリアネットワーク３００内のエンティティとの間のゲートウェイを提供する。ファイアウォールやＮＡＴなどの他のＲＧＷ機能は、ＲＧＷ  ＳＩＰプロキシ１１６’と同じ場所に置くことができる。ＳＩＰ  ＵＡＳは、発信元アプリケーションＳＩＰ  ＵＡＣ１００からのＳＩＰ機器メッセージを終了する。ＳＩＰ  ＵＡＳは、ＳＩＰメッセージからメッセージング情報を取り出し、その情報をインターワーキング装置２０８に渡す。このＳＩＰ  ＵＡＳは、スタンドアロン装置でよく、図５に示すようにＲＧＷ１１６または機器コントローラ２０４に常駐する。ＳＩＰ  ＵＡＣと機器コントローラとの論理的マッピングは１：Ｎであり、Ｎは、発信元プログラムがネットワークを通じて到達できるコントローラの数である。
【００４９】
インターワーキング装置２０８は、ＳＩＰメッセージのペイロードで搬送される機器メッセージを、機器固有のプロトコルにマッピングする。このプロトコルは、非ＩＰ機器２０６によって解釈できる形態であり、したがって、非ＩＰ機器２０６は、発信元のクライアントアプリケーションと通信／対話するために、インターワーキング装置２０８の使用を通じて機器コントローラ２０４によって制御される。
【００５０】
ＳＩＰ  ＵＡＳ（ＩＰ対応機器）２０２は、ＩＰ（ＳＩＰ）対応ネットワーク対応機器内に常駐する。ＳＩＰ  ＵＡＳは、発信元アプリケーションＳＩＰ  ＵＡＣ１００からのＳＩＰ機器コントロールメッセージを終了し、機器アプリケーションの機器コントロールステータス情報を取り出し、非ＩＰ機器に必要とされる仲介のインターワーキング装置２０８または機器コントローラ２０４を必要とせずに、その情報に直接作用する。
【００５１】
図５の主要インタフェースは、（１）ＳＩＰネットワーク対応機器、（２）機器の登録および位置、および（３）機器固有のインタフェースである。ＳＩＰ機器インタフェースは、ネットワーク対応機器と通信するためのＤＯメソッドを備えるＩＥＴＦ  ＳＩＰに相当する。機器の登録および位置のインタフェースは、任意の適切なデータベース更新と、位置データベース１４０にアクセスするのに使用する検索プロトコルによって実現される。そのようなプロトコルの例は、ＬＤＡＰおよびＳＬＰである。さらに、機器固有のインタフェースは、現在利用できる数多くのホームネットワーキング技術である。ＳＩＰから、ターゲット機器の固有の技術のプロトコルへのマッピングは、インターワーキング装置２０８の機能である。
【００５２】
図５の機能システムの物理的な実現を図６に示し、ここでは発信元ＳＩＰ  ＵＡＣ１００がユーザのオフィスのＰＣ１０１にある。このマシンからメッセージを発信して、例えばビデオカメラ２１０や照明２１２など住宅内のオブジェクトを操作する。このメッセージは、本発明により修正した標準的なＳＩＰ技術を使用して、その住宅を担当するサービスプロバイダシステム１０９（ＳＩＰプロキシ１０８を含む）に転送される。プロバイダ１０９は、メッセージをセットトップボックス（ＳＴＢ）１１７に送信するが、ＳＴＢ１１７は、ＲＧＷ、ケーブルモデム、ＡＤＳＬモデム、または展開された住宅技術の適切な他のエッジを含むことができる。ＳＴＢ１１７は、ＳＩＰ対応デバイス（ビデオカメラ２１０や家庭用ＡＶ機器などより高機能のデバイスである傾向がある）に直接メッセージを送信するか、または機器コントローラの一部とすることができるインターワーキング装置２０８を介して間接的に送信する。この物理的実現では、ユーザは、自分たちのために行われている通信のレベルおよび精度（sophistication）を意識する必要がない。
【００５３】
以下の例で、本発明によりＤＯタイプを含むように修正したＳＩＰ符号化を機器のドメイン間ネットワーキングに使用する方式を例示する。この説明では、すべてのＳＩＰメッセージヘッダフィールドを含めてはいない（例えばＣｓｅｑ、Ｃａｌｌ−ＩＤ、およびＣｏｎｔｅｎｔ−ｌｅｎｇｔｈなど）。説明を簡潔にするために、特に対象となるヘッダフィールドだけを含めている。また、デバイスメッセージングプロトコル（ＤＭＰ）はまだ標準化されておらず、ＤＭＰの例は、例証だけを目的とすると考えるべきことにも留意されたい。
【００５４】
図７に示すシナリオでは、ユーザは、オフィスのＰＣ１０１から自宅のランプのスイッチをつけたい。住宅内のネットワーク対応機器（例えばランプ）の（例えばオフィスからの）リモートコントロールのためのＳＩＰメッセージについて以下で説明する。実際の応用例でのＳＬＰ  ＵＲＬ情報は、符号化され、任意でプライバシーのために暗号化されるが、分かりやすいように角括弧内では暗号化せずに示すことに留意されたい。この例では、ｓｔａｎ．ｈｏｍｅ．ｎｅｔに位置する例えばセットトップボックス１１７などのユーザエージェントは、ｓｔａｎ．ｈｏｍｅ．ｎｅｔに登録され、その情報がｈｏｍｅ．ｎｅｔに伝達されている。下記の番号「１」のメッセージは、ＰＣとアウトバウンドプロキシｃｏ．ｃｏｍ間のものである。図７ではこれを円内の「１」として示している。
2004523828.tif 000004
【００５５】
ｃｏ．ｃｏｍプロキシは、［ｄ＝ｌａｍｐ，ｒ＝ｂｅｄｒｏｏｍ，ｕ＝ｓｔａｎｍ］＠ｈｏｍｅ．ｎｅｔについてＤＮＳでＳＲＶ検索を行って、宛先ドメインのＳＩＰサーバの名前を見つけ、ｈｏｍｅ．ｎｅｔの値を入手する。これは、ＳＲＶレコードがあるサービスプロバイダのプロキシを指すときには、ユーザ／サービス名がそのサービスプロバイダのドメイン内で一意でなければならないことを意味する。
【００５６】
図７のメッセージ「２」は、以下のようにｃｏ．ｃｏｍからｈｏｍｅ．ｎｅｔへのものである。
2004523828.tif 000005
【００５７】
ｈｏｍｅ．ｎｅｔからｓｔａｎ．ｈｏｍｅ．ｎｅｔ（セットトップボックス１１７など）へのメッセージは次である。
2004523828.tif 000006
【００５８】
セットトップボックス１１７からインターワーキング装置２０８へのメッセージは次である。
2004523828.tif 000007
【００５９】
そして、インターワーキング装置は、次のようにランプ２１２に動作メッセージを送信して、ランプのスイッチを入れる。
5. <Action!!!>上記のシナリオは失敗のシナリオを説明するためにも使用することができる。ランプは、メッセージを受信すると、電球が「切れて」（壊れて）いることに気付く可能性があり、それに応答して次のようなものを送信する。
2004523828.tif 000008
【００６０】
図８に示すケースでは、ｓｔａｎ．ｈｏｍｅ．ｎｅｔにあったランプを一時的にｓｉｍｏｎ．ｈｏｍｅ．ｎｅｔに移動している。この変化に対応するために、ｈｏｍｅ．ｎｅｔプロキシにリダイレクトを付加する。このシナリオのＳＩＰ  ＭＥＳＳＡＧＥを下に示す。この例では、ｓｔａｎ．ｈｏｍｅ．ｎｅｔのランプは、ｓｔａｎ．ｈｏｍｅ．ｎｅｔおよびｈｏｍｅ．ｎｅｔの両方に登録されておらず、ｓｉｍｏｎ．ｈｏｍｅ．ｎｅｔ内のユーザエージェントは適切な登録を行っている。
2004523828.tif 000009
ランプは現在Ｓｉｍｏｎの家にあるにもかかわらず、このメッセージはなおｓｔａｎ．ｈｏｍｅに向けられることに気付かれたい。
2004523828.tif 000010
ｈｏｍｅ．ｎｅｔのプロキシは検索を行い、Ｓｉｍｏｎの寝室のランプが現在Ｓｉｍｏｎの予備室にあることに気付く。したがって、Ｒｅｑｕｅｓｔ−ＵＲＬは、今度はＳｉｍｏｎの自宅の予備室をポイントする。
2004523828.tif 000011
【００６１】
図９のシナリオでは、Ｓｔａｎが自分のＰＣ１０１で仕事をしており、自宅の２ゾーン式冷暖房システムの下階ゾーンの温度を調べたい。Ｓｔａｎは、自宅を希望の温度にするために、上階と下階のサーモスタット設定の適切な組合せを求めようとしている。Ｓｔａｎはエンジニアである。
【００６２】
ＤＯメッセージは、「ｌａｍｐ」の代わりに、この場合はＳｔａｎの自宅の「ｄｏｗｎｓｔａｉｒｓ」「ｔｈｅｒｍｏｓｔａｔ」を指定する。また、本体中の動作は「ｃｏｍｍａｎｄ」ではなく「ｑｕｅｒｙ」になる。
2004523828.tif 000012
2004523828.tif 000013
6．現在の温度の読み取りがＵＡに戻される。
2004523828.tif 000014
このメッセージはａｎｙｐｃ．ｃｏ．ｃｏｍの要求発信元に転送される。
【００６３】
この例と先の例の主な違いは以下である。
・照明をつけるコマンドの代わりに、温度を求めるクエリーを発行するための異なる本体
・「ｒｅｎｄｅｒ」はＤＯメソッドのＣｏｎｔｅｎｔ−ｆｕｎｃｔｉｏｎヘッダフィールドのデフォルト値なので、このヘッダフィールドが除去される（これは任意選択であり、残しておくこともできる）。
温度を受け取ると、Ｓｔａｎは、所望の温度に設定するための別のコマンドを発行することができる。これには、異なる本体内容を備える同様のＤＯメッセージを使用する。Ｓｔａｎとサーモスタットの間を行き来するこれらのメッセージは、単一のＳＩＰセッションの一部であり、電話の呼出しやテレビ会議の代わりに、機器コマンドおよびステータス情報が交換される。
【００６４】
図１０の例では、Ｓｔａｎは、ＤａｖｅとともにＤａｖｅの車に乗っており、サービスマンが皿洗い機の修理に来る予定であったことを思い出し、そして自分のＷｅｂ電話を持っていない。Ｓｔａｎは、Ｄａｖｅの電話を借り、誰かがドアベルを「鳴らし」たら通知するように自分のサービスプロバイダ１０９にメッセージを送信する。Ｓｔａｎは、そのように指示されるとサービスプロバイダに認証コードを送信する。このコードは、メッセージに付加されて、ホームドメインへのアクセスを要求しているのがＤａｖｅではなくＳｔａｎであることを証明する。
【００６５】
サービスマンがドアベルを「鳴らす」（そして自分のＩＤバッジで、またはそのためのキーパッドにパスワードを入力して自身を認証する）と、メッセージがＳｔａｎのためにＤａｖｅのＷｅｂ電話に送信され、サービスマンが来ていることを知らせる。その者が実際に正しい会社から来た者であることを検証すると、Ｓｔａｎは、表玄関の鍵を開け、サービスマンを中に入れるコマンドを発行する。
【００６６】
このシナリオでは、Ｓｔａｎ．ｈｏｍｅ．ｎｅｔのプロキシにアウトバウンドメッセージを送信するようにデバイスコントローラＵＡ２０８を構成し、ｍｏｂｉｌｅ．ｎｅｔのプロキシにアウトバウンドメッセージを送信するようにＤａｖｅのＵＡ１０２を構成すると想定する。メッセージは、ｍｏｂｉｌｅ．ｎｅｔに接続するためにＤＯではなくＳＵＢＳＣＲＩＢＥで始まる。また、表玄関がメッセージ中に表記される。
2004523828.tif 000015
2004523828.tif 000016
5．（ドアベルが鳴る！クリデンシャルが確立される）
【００６７】
Ｓｔａｎは、ドアベルが鳴ったら通知するように要求しているので、ＵＡは、ベルを検出すると、Ｄａｖｅの車の中にいるＳｔａｎのためにＳＩＰ  ＮＯＴＩＦＹメッセージを形成する。
2004523828.tif 000017
【００６８】
Ｓｔａｎは、今度はサービスマンが来ていることを通知されている。Ｓｔａｎは、ドアの鍵を開けることを決め、ドアの鍵にＤＯコマンドを送信してドアの鍵を開ける。
2004523828.tif 000018
2004523828.tif 000019
【００６９】
図７および図８の先の応用シナリオでは、セッションの外側での通信を必要とした。しかし、ネットワーク対応機器とのセッションを確立することが必要な場合もある。例えば、その時の天気、道路、および交通の状態に基づいて起床時間を調整するインターネット目覚まし時計サービスを考えられたい。ネットワークベースの目覚まし時計サービスのプロバイダが、自分の起床時間を調整した場合にはその理由を知りたいはずである。そのため、目覚まし時計サービスのプロバイダが、目覚まし時計とのオーディオセッションを確立し、起床時間が調整された理由を含む（そして、あるいは現在の天気、トップニュースなどを含む）メッセージを「再生」すると利便である。このシナリオ（図１１に示す）のメッセージフローは次のようになる。
2004523828.tif 000020
次いで、目覚まし時計のＲＴＰパラメータを含む応答が目覚まし時計サービスのプロバイダに戻され、オーディオＲＴＰストリームが開始される（目覚まし時計に送信される）。
【００７０】
次のシナリオでは、ＷａｌｌｙのＶＣＲが数日前に壊れたと想定する。今日は土曜日であり、Ｗａｌｌｙは、アニメ番組「ザシンプソンズ」を録画したい。Ｗａｌｌｙは、会社の同僚であるＤｉｌｂｅｒｔのところに行くと、Ｄｉｌｂｅｒｔは、番組の録画に自分のＶＣＲを使うことを許してくれる。Ｗａｌｌｙは、ＤｉｌｂｅｒｔのＶＣＲがＳｏｎｙ製であることは知っているが、それが、予めプログラムされた録画の停止と再開（コマーシャル広告を避けるため）をサポートするかどうかは分からない。図１２の配置では、Ｗａｌｌｙは、オフィスのＰＣ１０１から、Ｄｉｂｅｒｔの自宅のＵＡ２０８に接続されたＶＣＲに照会して、その機能セットを判断する。Ｗａｌｌｙは、その特定のＶＣＲがサポートするビデオパッケージと、そのＶＣＲについてのより詳細な情報を知らせる応答をＶＣＲから受け取る。
【００７１】
このネットワーク対応機器の機能のクエリーを実現するには次のＳＩＰメッセージを送信する。
2004523828.tif 000021
＜そのＶＣＲにダウンロードされたビデオコントロールパッケージをより詳細に記述するＸＭＬタグで囲まれた本体＞
2004523828.tif 000022
＜そのＶＣＲにダウンロードされたビデオコントロールパッケージをより詳細に記述するＸＭＬタグで囲まれた本体＞
2004523828.tif 000023
＜そのＶＣＲにダウンロードされたビデオコントロールパッケージをより詳細に記述するＸＭＬタグで囲まれた本体＞
【００７２】
図１３に示すさらなるシナリオでは、Ｃａｌｖｉｎが、オフィスで自分のＰＣ１０１から文書を印刷しようとしている。Ｃａｌｖｉｎの文書を印刷することが可能な３つのプリンタ５０２、５０４、５０６が別々のフロアにある。Ｃａｌｖｉｎは、デフォルトプロキシサーバ５００に接触し、サーバ５００はその要求を様々なプリンタに分配（fork）する。利用可能なプリンタが応答し、Ｃａｌｖｉｎは、他の保留中の要求をＣＡＮＣＥＬする。この例では、Ｃａｌｖｉｎは、利用可能なプリンタとのセッションを確立したく、確認を受信するとそのプリンタにデータを送信すると想定する。このメッセージは次のようになる。
2004523828.tif 000024
2004523828.tif 000025
次いでプロキシは、すべての他の保留中の要求をＣＡＮＣＥＬする。
【００７３】
ＳＩＰは、個人用デバイスおよびグループデバイスの識別も可能にする。例えば、ＳＩＰを使用して、Ｈａｇａｒのホームドメイン内のエアコンを「クールボーイ」というニックネームでアドレス指定することができ、同時に「エアコン」のカテゴリとしても知ることができる。これは２要素の目的に役立ち、すなわち、所有者は自分のデバイスに個体性（personality）を割り当てることができ、また必要な場合にはデバイスのニックネームに関係なくあるグループをアドレス指定することができる。例えば、「クールボーイ」の温度を２５℃に設定するには、Ｈａｇａｒは次を送信することができる。
2004523828.tif 000026
同時に、自宅内のすべてのエアコンのスイッチを切りたい場合には、Ｈａｇａｒは次のコマンドをマルチキャストまたはブロードキャストすることができる。
2004523828.tif 000027
【００７４】
すべてのネットワーク認識デバイスは、あるグループの一部になるように構成することができる。例えば、様々なエアコンのベンダは、各自の内的なネーミング方式を備えることができるが、それらのエアコンが「ａｃ−グループ」のデバイスに属することを全ベンダが知っている。したがって、そのようなメッセージが到着したときに、デバイスがそのグループの一部であることが分かる。あるいは、中央のプロキシまたは機器コントローラを、住宅内のデバイスグループのユーザまたはベンダによって設定し、そのようなメッセージがプロキシ／コントローラに到着すると、そのプロキシ／コントローラがそのグループの各デバイスに適切なＤＯコマンドを送信することも可能である。
【００７５】
特にこのシステムは個々のユーザの住宅内に配置することを企図するので、セキュリティは主要な関心事である。ここに記載するプロトコルにあてはまり、このプロトコルのどの実装においても考慮しなければならないセキュリティの脅威は様々である。これには、ユーザの住宅の物理的セキュリティおよびその他の従来のセキュリティ問題が含まれる。ただし、このシステムは、インターネットを介して攻撃者がＳＩＰメッセージを盗聴し、ＳＩＰメッセージを偽造し、ＳＩＰメッセージを修正する可能性がある点で新たなセキュリティ問題ももたらす。これらはすべてユーザの住宅内で重大な影響を与える可能性がある。
【００７６】
セキュリティ問題は、住宅へのリモートアクセスを可能にするシステムを設計する際には最優先しなければならない。偽造された（一般的な）ＳＩＰメッセージは、通常は単なる迷惑に過ぎないが、他人の住宅内の機器のスイッチを入れる偽造コマンドは惨事につながる可能性もある。したがって、遠隔からのホームアクセスが可能システムでは、メッセージの真正性を検証する方法を提供しなければならない。詳細には、住宅へのすべての（ＳＩＰ）通信は、ホームＲＧＷ／ファイアウォールによって認証し、許可された個人（図３のようにユーザから住宅への直接の通信の場合）か、または許可されたサービスプロバイダプロキシ（図４のようにプロキシを介した通信の場合）から発信されたことを検証しなければならない。第２のケースでは、サービスプロバイダプロキシは、住宅との通信を許可された個人によって通信が発信されたことも検証しなければならない。
特にメッセージは住宅内の機器の存在と使用についての情報を含むことから、プライバシーも多くのユーザにとって問題となる。したがって、実装は、プライベートな（すなわち暗号化された）通信のための方法を提供しなければならない。
【００７７】
メッセージ応答のセキュリティも重要である。これらの応答は、最終的にはステータス情報（すなわち住宅の現在の温度）を含む可能性があり、偽の標準１００および２００タイプの応答メッセージも問題を生じさせる可能性がある。
【００７８】
一般に、ユーザは、受動的な盗聴者がメッセージ内容を判定できることを望まない。これは、メッセージの本体（実行すべきコマンドを含む）だけではなく、ある者が所有するデバイスについての情報を漏洩しうるヘッダフィールドにもあてはまる。例えば、「Ｔｏ：」ヘッダフィールドは、デバイスのタイプと位置を示すアドレス指定されたエンティティのＵＲＬを含む。ユーザは、自分がテレビを所有しているかどうかを誰にも知られたくない場合があり、またそのテレビが置いてある部屋は確実に誰にも知られたくない。
【００７９】
実装される基礎アーキテクチャが、ホームドメインの直接の制御を提供する場合は、該当するフィールドを適切に暗号化することができるので、中間プロキシを（プライバシーに関しては）信頼する必要がない。ただし、基礎となるアーキテクチャがプロキシを介した通信である（図４）場合には、仲介役のサービスプロバイダプロキシへの信頼の前提が必然となる。
【００８０】
住宅の外側のネットワークで登録が行われる場合（プロキシを介した通信の場合（図４）など）は、ＲＥＧＩＳＴＥＲメッセージも暗号化を必要とする場合がある。
【００８１】
ユーザの視点からさらに重要な問題は、ＳＩＰメッセージの正確な認証である。両方向（ユーザから住宅へ、または住宅からユーザへ）のメッセージに認証が必要とされることに留意されたい。住宅内部で特定の動作を行うメッセージがあるので、ユーザから住宅へのメッセージに対する認証の必要性は明白である。しかし、実際には元のメッセージが受信されていないときに攻撃者が偽の肯定応答または確認済みのメッセージを挿入しないように、住宅からユーザへの１００および２００タイプの応答メッセージも認証しなければならない。また、応答は、最終的には、住宅の温度や警報システムがオンになっているかどうかなどのステータス情報を含む可能性がある。
【００８２】
ＤＯタイプメッセージの認証に加えて、ＲＥＧＩＳＴＥＲタイプのメッセージも認証を必要とする可能性がある。ただし、ホームＲＧＷへの登録が行われている場合（直接の通信（図３）を想定する場合）は、暗号による解決は必要でない（ホームネットワークの物理的セキュリティにより）。登録がネットワークの外側で行われる場合（プロキシを介した通信を使用する場合など）は、それらのメッセージは認証しなければならない。
【００８３】
メッセージの認証は、偽造、修正、およびなりすまし（masquerading）を防止する。認証によって直接解決されない問題はリプレイ攻撃である。リプレイ攻撃は、２つの方式で防御することができる。これを行う１つの単純な方式は、反復されるメッセージがないかチェックすることである。これは、例えばＴｉｍｅｓｔａｍｐ：フィールドまたはＣｓｅｑ：フィールドをそれまでに記憶されているメッセージに照らしてチェックすることによって行うことができる。しかし、記憶しておくことができる以前に使用されたＴｉｍｅｓｔａｍｐの数には制限があり、そのため（非常に）古いメッセージをリプレイする可能性が残る。より堅固な解決策は、Ｔｉｍｅｓｔａｍｐフィールドと現在のシステム時刻を比較することにより古いメッセージがないかチェックするものである。Ｔｉｍｅｓｔａｍｐフィールドは、ここで使用する、想定されるメッセージ認証により、悪意をもって修正することができないことに留意されたい。ただし、この場合にはいくらかのクロック同期が想定される。
【００８４】
（汎用的な）ＳＩＰメッセージのプライバシーおよび認証を実現する方法が、M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg「SIP: session initiation protocol」ＲＦＣ（提案される標準）２５４３、Internet Engineering Task Force,１９９９年３月に記載され、一般的に、これらの方法は、ネットワーク対応機器（ＮＡ）をアドレス指定する事例にも応用される。ただし、一般的なＳＩＰセキュリティと遠隔からのホームアクセスの特有の事例にはいくつかの重要な違いがある。
【００８５】
一般的なＳＩＰセキュリティについては、Ｈａｎｄｌｅｙ他の提案に従って何らかの形態の公開鍵技術を用いて、セキュリティを提供しなければならない。しかし、住宅内のＮＡへのリモートアクセスの場合には、共有される秘密を使用してプライバシーと認証を提供することができる。この違いには２つの主要な理由がある。第１に、一般的なＳＩＰ通信は、可能性としては任意の２つのパーティ間で行われるのに対して、住宅へのリモートアクセスの場合は、許可されたユーザと、そのユーザが通信する住宅との間に１対１（または数対１）の対応関係が存在する。第２に、一般的なＳＩＰ通信は、しばしば、それまでに接触がなく、したがって共有される秘密を生成する機会がなかったパーティ間で行われる。ただし、ホームアクセスの場合、ユーザは、住宅との通信で使用する共有秘密を指定する機会を有する。秘密は、住宅のＲＧＷ／ファイアウォールと共有する（図１のようにユーザから住宅への直接の通信の場合）か、またはサービスプロバイダプロキシ（図４のようにプロキシを介した通信の場合）と共有することができる。
【００８６】
一般に、秘密鍵方式は、公開鍵方式に比べてセキュリティレベルが高く、効率性が高いことの両方から、公開鍵方式よりも好ましい。事例によっては公開鍵方式が好ましい場合もある。両方についての実装を提供することが有利である可能性がある。実装の詳細は、サービスプロバイダの要件、最初の設定、課金、記録の保持、サポートされるリモートアクセス方法、および将来のアップグレード可能性を含む外部の要因に依存する。
【００８７】
Ｈａｎｄｌｅｙ他の提案のＳＩＰ  ＲＦＣは、終端間の暗号化またはホップバイホップの暗号化の２つのプライバシー実現法を記載する。詳細には、住宅へのリモートアクセスの特定の設定では、終端間の暗号化が好まれる。終端間の暗号化は、確実により効率的であり、ユーザとホームＲＧＷ／ファイアウォール（またはサービスプロバイダプロキシ）が秘密鍵を共有する場合は、ホップバイホップの暗号化に依存する必要がない。さらに、ホップバイホップの暗号化では、メッセージパスにあるすべてのプロキシへの信頼が必要とされるのに対して、終端間の暗号化では、解読を行う最後のＵＡ（ホームＲＧＷ／ファイアウォールまたはサービスプロバイダプロキシ中）への信頼だけが必要とされる。
【００８８】
第１に、図３のように、解読および真正性の検証がホームＲＧＷ／ファイアウォールによって行われる、ユーザから住宅への直接の通信があることが考えられる。この場合、ユーザからの元のメッセージは、ユーザと住宅に共有される秘密鍵を使用して暗号化および認証することができる。
【００８９】
図４のような第２のケースでは、通信はサービスプロバイダプロキシを介する。このシナリオでは、ユーザからのメッセージは、ユーザとサービスプロバイダプロキシの間で共有される鍵を使用して初めに暗号化し、認証する。メッセージを受信すると、サービスプロバイダプロキシは、メッセージの真正性を検証し、メッセージを解読する。そして、サービスプロバイダプロキシと住宅の間で共有される鍵を使用してメッセージを認証、暗号化し、住宅に転送する（このステップは、サービスプロバイダプロキシと住宅間のセキュアなＩＰＳｅｃトンネルの確立によって扱うこともできる）。転送されたメッセージは、ホームＲＧＷ／ファイアウォールによって（サービスプロバイダプロキシから来たものと）認証され、解読された後に住宅内に入ることが許可される。
【００９０】
この提案とＨａｎｄｌｅｙ他の提案の大きな違いは、「Ｔｏ：」ヘッダフィールドが、暗号化すべき潜在的に機密性のある情報（デバイス名や位置など）を含むことである。メッセージの本体（および該当するヘッダフィールド）は、Ｈａｎｄｌｅｙ他による提案で詳細に述べられるように暗号化すべきである（ただし可能性としては秘密鍵の技術を使用して）。「Ｔｏ：」フィールドの暗号化は、メッセージ本体の暗号化とは別に行うべきである。Ｔｏ：フィールドの全体的な内容は、暗号化することができない（この情報はルーティングに使用される）ので、「＠」の左側の部分（エンティティ情報）だけを暗号化すべきである。
【００９１】
ルーティングはＴｏ：フィールドに含まれるエンティティ情報に基づいて行われるので、一見するとこれは問題があるように思われる。しかし、この問題は容易に回避される。実際には、ルーティングは、Ｔｏ：フィールドの２つの構成部分、すなわちエンティティ名（「＠」の左に現れる）と位置（「＠」の右に現れる）に基づいて行われる。位置の構成部分についての情報（通例はドメイン名）は、ネットワーク中のすべてのプロキシが入手することができる。一方、特定エンティティについての情報は、（通例は）選択された数個のプロキシしか入手することができない（詳細には、ユーザから住宅への直接の通信を想定する場合はホームＲＧＷ／ファイアウォール、またはプロキシを介した通信を想定する場合はサービスプロバイダプロキシ）。したがって、大半のプロキシにとっては、ルーティングはＴｏ：フィールドの位置の構成部分だけに基づき、したがってそれらのプロキシはエンティティの構成部分を調べる必要がない。一方、エンティティ構成部分の内容を調べる必要があるプロキシは、そのプロキシが利用できる解読鍵を有する（暗号化は該当する共有鍵で行われているため）。したがって、ルーティングは、メッセージがそのドメイン中の特定のデバイスに関する情報へのアクセス権を有するプロキシに到達するまで、位置の構成部分を介して進行する。このプロキシは、構造上、メッセージを解読（および認証）するための正しい鍵へのアクセス権も有することになる。メッセージ、具体的にはＴｏ：フィールドのエンティティ構成部分を解読すると、プロキシは、その追加情報を使用してメッセージを正しくルーティングすることができる。
【００９２】
ＳＩＰを、新しくここで提案するＤＯタイプ、並びにインスタントメッセージングのために開発されたＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹメッセージ、そして新しいＭＩＭＥタイプ、およびサービス情報を「Ｔｏ：」フィールドに符号化する新しい機構と組み合わせると、ワイドエリアネットワークからのネットワーク対応機器との通信に必要なサポートを提供することができる。これにより、ネットワーク対応機器という新たな課題領域に対して、既存のＳＩＰインフラストラクチャおよび機能（例えばホップバイホップルーティングやセキュリティ）を活用することが可能になる。
【００９３】
好ましい実施形態を参照して本発明を具体的に示し、説明したが、当業者には、本発明の精神および範囲から逸脱することなく形態および詳細の様々な変更を本発明に加えられることが理解されよう。
【図面の簡単な説明】
【００９４】
【図１】従来技術のＳＩＰアーキテクチャの図である。
【図２】本発明によりホームネットワーク対応機器システムとの直接の通信を実現するように修正したＳＩＰアーキテクチャの例証実施形態の図である。
【図３】本発明によるクライアントアプリケーションから直接ゲートウェイプロキシを介したネットワーク対応機器システムへの通信のための修正したＳＩＰアーキテクチャの例証実施形態の図である。
【図４】本発明によるクライアントアプリケーションおよびゲートウェイプロキシサーバからネットワーク対応機器システムへの通信のための修正したＳＩＰアーキテクチャの例証実施形態の図である。
【図５】本発明の一実施形態による図４の配置における機能関係の例証実施形態の図である。
【図６】本発明の一実施形態による図５の配置における機能関係の物理的実現の例証実施形態の図である。
【図７】本発明の一実施形態による職場のコンピュータからのユーザによるホームネットワーク対応機器システムへの単純なアクセスを伴うシナリオにおけるメッセージフローの図である。
【図８】本発明の一実施形態によるリダイレクトを含むメッセージフローの図である。
【図９】本発明の一実施形態による、温度の状況を調べるメッセージフローの図である。
【図１０】本発明の一実施形態による、車内のユーザから自宅の玄関に応答するメッセージフローの図である。
【図１１】本発明の一実施形態によるネットワークベースの目覚まし時計サービスのメッセージフローの図である。
【図１２】ネットワーク対応機器機能のクエリーを示す本発明の例証実施形態の図である。
【図１３】サービスを分配するのに利用する本発明の図である。
【図１】
2004523828.tif 000028
【図２】
2004523828.tif 000029
【図３】
2004523828.tif 000030
【図４】
2004523828.tif 000031
【図５】
2004523828.tif 000032
【図６】
2004523828.tif 000033
【図７】
2004523828.tif 000034
【図８】
2004523828.tif 000035
【図９】
2004523828.tif 000036
【図１０】
2004523828.tif 000037
【図１１】
2004523828.tif 000038
【図１２】
2004523828.tif 000039
【図１３】
2004523828.tif 000040
【国際公開パンフレット】
2004523828.tif 000041
2004523828.tif 000042
2004523828.tif 000043
2004523828.tif 000044
2004523828.tif 000045
2004523828.tif 000046
2004523828.tif 000047
2004523828.tif 000048
2004523828.tif 000049
2004523828.tif 000050
2004523828.tif 000051
2004523828.tif 000052
2004523828.tif 000053
2004523828.tif 000054
2004523828.tif 000055
2004523828.tif 000056
2004523828.tif 000057
2004523828.tif 000058
2004523828.tif 000059
2004523828.tif 000060
2004523828.tif 000061
2004523828.tif 000062
2004523828.tif 000063
2004523828.tif 000064
2004523828.tif 000065
2004523828.tif 000066
2004523828.tif 000067
2004523828.tif 000068
2004523828.tif 000069
2004523828.tif 000070
2004523828.tif 000071
2004523828.tif 000072
2004523828.tif 000073
2004523828.tif 000074
2004523828.tif 000075
2004523828.tif 000076
2004523828.tif 000077
2004523828.tif 000078
2004523828.tif 000079
2004523828.tif 000080
2004523828.tif 000081
2004523828.tif 000082
2004523828.tif 000083
2004523828.tif 000084
2004523828.tif 000085
2004523828.tif 000086
2004523828.tif 000087
2004523828.tif 000088
2004523828.tif 000089
2004523828.tif 000090
2004523828.tif 000091
2004523828.tif 000092
2004523828.tif 000093
2004523828.tif 000094
【国際調査報告】
2004523828.tif 000095
2004523828.tif 000096