JP2004531110A

JP2004531110A - Ｓｉｐのユーザエージェントの機能をプロキシにアウトソーシングするシステムおよび方法

Info

Publication number: JP2004531110A
Application number: JP2002561707A
Authority: JP
Inventors: エル．モイヤースタンレイ; ジェイ．マープルズデイビッド; ツァンシモン
Original assignee: テルコーディアテクノロジーズインコーポレイテッド
Priority date: 2001-01-31
Filing date: 2002-01-31
Publication date: 2004-10-07
Also published as: US20020103850A1; EP1356386A1; WO2002061604A1; EP1356386A4; CA2434521A1

Abstract

ＳＩＰはＮＡ３４０との通信に用いられる。ＳＩＰを採用したシステムにおいて、ＵＡＣ（user agent client）は、ＳＩＰプロキシサーバ３２０により、アプライアンス３４０にあるＵＡＳ（user agent server）例えばクライアントのホームに、メッセージをInternetを介して送信する。この通信チャネルにより、クライアントは、当該アプライアンスをコントロールすることができ、当該アプライアンスのステータスを判定することができる。当該ＵＡＣと複数のＵＡＳプロセッサとの間のＳＩＰプロキシサーバ３２０は、当該ＵＡＳプロセッサから、当該ＵＡＳプロセッサに接続されたＳＩＰプロキシサーバ３２０にアウトソーシングされた、アドレスマッピング、認証、オーソライゼーション、および／または変換の機能を有する。

Description

【技術分野】
【０００１】
本願は、本願と同時に出願され、本出願の出願人に譲渡された、発明の名称を「System and Method For using Session Initiation Protocol (SIP) to Communicate with Networked Appliances」とする特許文献１に関連する。
【０００２】
本発明は、ネットワークデバイスの操作を行うため、ネットワークを介して制御信号およびステータス信号を通信することに関し、具体的には、複数のネットワーク化された装置との通信を改良するためのＳＩＰ（session initiation protocol）の使用に関する。
【背景技術】
【０００３】
ＩＥＴＦ（Internet Engineering Task Force）は、幾つかの異なるモードの通信に対応することができるＳＩＰという通信プロトコルを開発した。提案された標準ＲＦＣ２５４３によると、ＳＩＰは、１つ以上の関係者間のインタラクティブ通信セッションを作成し、修正し、終了するアプリケーション層のコントロールおよびシグナリングのプロトコルである。ＳＩＰはＨＴＴＰおよびＳＭＴＰと同様のテキストベースのプロトコルである。このセッションには、音声、ビデオ、チャット、インタラクティブゲーム、およびバーチャルリアリティ、例えば、Internetマルチメディア会議、Internet電話のコール（call）、及びマルチメディア配信を含めることができる。セッションのメンバーは、マルチキャストを介するか、もしくはユニキャストリレーション（unicast relations）のメッシュを介するか、あるいはこれらを組み合せたものを介して、通信することができる。
【０００４】
ＳＩＰインビテーション（すなわちＳＩＰメソッドＩＮＶＩＴＥ）は、セッションを作成するために使用される。このインビテーションは、参加者が互換性のあるメディアタイプのセットに同意することができるセッション記述を搬送することができる。ＳＩＰはユーザのモビリティ（mobility）をサポートするが、これは、要求を代理として受け（proxy）、ユーザの現在の場所（ユーザが登録できる）にリダイレクト（redirect）することにより行なわれる。ＳＩＰは、どの特定の会議コントロールプロトコルにもタイ（tie）しないが、下層のトランスポートプロトコルに依存しないように設計される。
【０００５】
ＳＩＰアーキテクチャには、ユーザエージェントが含まれ、このユーザエージェントは、デバイスであって、ＵＡＣ（user agent client、ユーザエージェントクライアント）およびＵＡＳ（user agent server、ユーザエージェントサーバ）としてアクト（act）できるアプリケーションプログラムをラン（run）する。クライアントは、ＳＩＰ要求を送信するアプリケーションプログラムである。クライアントは、ヒューマンユーザ（human user）と直接インタラクト（interact）しても良いし、しなくても良い。
【０００６】
サーバは、アプリケーションプログラムであって、クライアントからの要求に対してサービスを提供するため、クライアントからの要求を受け付け、それらの要求に対して応答する。したがって、ＵＡＳは、サーバアプリケーションであって、ＳＩＰ要求を受信したときユーザと接触し、ユーザに代わって応答する。その応答は、要求を受け付けるか、拒絶するか、またはリダイレクトする。
【０００７】
加えて、ユーザエージェントではないサーバが存在する。これらのサーバは、プロキシサーバ、リダイレクトサーバ、またはレジストラ（registrar）サーバとすることができる。プロキシサーバは、他のクライアントに代わって要求するため、サーバおよびクライアントの両方として機能する仲介プログラムである。要求は、内部でプロキシサーバによってサービスされるか、または、おそらくは変換した後、このプロキシサーバから他のサーバに渡される。プロキシサーバは、要求メッセージを解釈し、必要であれば書き直してから転送する。Internetのコンテクストでは、このプロキシサーバは、異なるＵＲＬを有するホストにダイレクト（direct）される場合であっても、ＵＡＣから要求を受け取る。処理後、このプロキシサーバはその要求をデスティネーションＵＲＬに送信する。
【０００８】
リダイレクトサーバは、ＳＩＰ要求を受け付け、アドレスを、ゼロ個以上の新しいアドレスにマッピングし、それらのアドレスをクライアントに戻すサーバである。リダイレクトサーバは、ＵＡＣと異なり、それ自身のＳＩＰ要求は開始しない。リダイレクトサーバは、ＵＡＣと異なり、コールを受け付けない。
【０００９】
レジストラサーバは、REGISTER要求を受け付けるサーバである。このレジストラサーバは、登録されたアドレスであって、そのエリア内のＵＡＳデバイスのために、このレジストラサーバが受け取るアドレスのリストを保持しており、典型的には、プロキシサーバまたはリダイレクトサーバと同一ロケーションに配置されているから、それらのサーバと情報をシェア（share）することができる。
【００１０】
ＳＩＰコンフィギュレーションにおいては、このＵＡＣは、１つ以上のプロキシサーバを介して、ＵＡＳに要求を送信する。典型的には、１つのＵＡＣが、複数のＵＡＳをアドレシング（addressing）することができるか、またはアドレシングする能力を有する。さらに、標準ＳＩＰアーキテクチャにおいては、エンドポイント（endpoint）、すなわちＵＡＳは、常に、直接、相互に通信することができる。この構造を典型的なマルチメディア会議に適用すると、コントロールアプリケーションは、コールを開始するか、または他の者を会議に誘うＵＡＣとしてアクトし、またインビテーションを受け付けるＵＡＳとしてアクトする。ＵＡＣおよびＵＡＳの役割は、プロキシサーバおよびリダイレクトサーバと同様に、要求ごとに規定される。例えば、コールを開始するユーザエージェントは、最初のＩＮＶＩＴＥ要求を送信するとき、ＵＡＣとしてアクトし、コールされたデバイスからＢＹＥ要求を受信するとき、ＵＡＳとしてアクトする。同様に、同一のソフトウェアが、要求に対して、プロキシサーバとしてアクトしたり、リダイレクトサーバとしてアクトしたりすることができる。ＳＩＰＵＡＳは、典型的には、ＳＩＰ電話機、ＰＣ、およびＰＤＡにエンベッド（embed）される。これらのＵＡＳデバイスは、メッセージの発信元を認証し、ついで、要求されたオペレーションをパフォームするため（典型的にはアクセスコントロールリストにコンサルト（consult）して）、当該エンティティがオーソライズ（authorize）されているか否かを判定する役割を担っている。
【００１１】
ネットワーク化された複数のアプライアンスをリモートコントロールすることは、新規なことであり、関心を集めている領域である。典型的な実施形態においては、ホーム（home）においては、それらアプライアンスの全て又は多くを、ネットワークに接続させることができる。このようなシステムにあっては、ホーム所有者は、オフィスを離れる前であっても、ネットワークにアクセスし、車庫に通じる道の照明をつけ、コーヒメーカを開始させ、ホーム内の温度を上げたり下げたりすることができる。冷蔵庫が食料品の在庫を管理し、必要であれば、追加注文（re-order）することもできる。時計は、ユーザのアジェンダ（agenda）をコーディネート（coordinate）するか、またはアプライアンスをターンオン（turn on）することができる。これらを機能させるためには、例えばアラームクロックにより、寝室の照明をターンオンさせることができるように、これらのアプライアンスが相互に通信する必要があることは、明白である。
【００１２】
ＮＡ（networked appliance）は、少なくとも１つのネットワーク化されたプロセッサを含む専用のコンシューマデバイスである。これに代えて、リモートメッセージを受け付け、所望の方法でアプライアンスをコントロールするアプライアンスコントローラに、慣用のアプライアンスを接続することができる。その結果として、各コントローラにおいては、実質的なコンピューティングパワーが必要になる。
【００１３】
ＮＡシステムにおいては、ホーム外における通信を考慮するとき適応させる必要のある次の点を考慮することができる。
・セキュリティ− インホーム（in-home）通信においては、ホーム外からの任意のアクセスが許可されるとき失われる物理的セキュリティのレベルが利用される。
・認証− ホームにエンタしようしているエンティティは、アクセスを許可する前に明確に識別する必要がある。
・信頼性− エクストラホーム（extra-home）アクセスにはワイドエリア（wide area）という性質があるため、障害発生時点が多くなる。当該ホームは、外部システムとの通信が失われたとき、その外部システムに依存せずに、引き続きオペレートするべきである。
・スケーリング− 非常に多くのホームが存在する。
・プロトコルの独立性− 単一のホーム内においては、インタデバイス（inter-device）通信のために、多くの異なるプロトコルを使用することが許容されるが、ワイドエリアであるため、はるかにプロトコルに依存しないアプローチが必要となる。なぜなら、インホームネットワークを備えているデバイスの正確な詳細は、外部世界から知ることができないからである。
・ネーミングおよびロケーション− ホーム内におけるデバイスは、明確に名前を付ける必要があり、しかもそのロケーションをホーム外から識別する必要がある。
【００１４】
当該外部世界からホーム内のデバイスをコントロールできる技術が開発されており、その最も顕著な例は、ＯＳＧｉ（Open Services Gateway Initiative）によるものである。ＯＳＧｉについては、www.osgi.orgを参照されたい。しかしながら、この従来のシステムは、なおワイドエリアでのアクセスとセキュリティの一般的な問題に対処しておらず、上述のその他の課題に対処していない。これらのシステムは、Internetを介した通信のための一定のプロトコルを提供していない。加えて、これらのシステムは、コントロール可能な各アプライアンスか、またはＮＡに接続された別個のアプライアンスコントローラにおいて、莫大な数の機能を必要とする。
【００１５】
ＳＩＰアーキテクチャには、ＮＡとの通信にとっておそらく有用であることを示唆する特徴があるが、ロケーションのフェーズ（phase）と、通信（またはアクション）のフェーズとが単一のアクティビティにマージされた、ネットワーク化されたデバイスに、一般的に、適用可能である。具体的には、ＳＩＰにより、モビリティが許容される。すなわち、受信側デバイスが新しいロケーションにおいて再度登録される限り、この受信側デバイスを移動させることができる。
【００１６】
ＳＩＰは、一時的な（transactional）サービスであって、共通のコンテクスト（Call-ＩＤによって識別される）における要求−応答トランザクションのシーケンスからなる。これは、ＮＡコネクションにも適用できる。このＮＡコネクションにおいては、会話（セッション）が、第１のメッセージによって開始され、これら応答とその他のメッセージがグループ化される。さらに、ＳＩＰは、コンテントを搬送するため、ＭＩＭＥを使用している。したがって、当該コンテントの意味と目的は、要求メソッドとコンテントタイプとに依存する。ＳＩＰは、通信に関わるユーザを識別するため、多数のヘッダフィールドを使用する。この機能は、ＮＡコネクションにおいて有用である。さらに、ＳＩＰは、リモートアクセスが可能なＮＡシステムに必要な認証ツールとセキュリティ機構を有する。
【００１７】
重要なことは、ホーム外からアクセスがあるＮＡシステムにおいては、要求元エージェントは、名前付きオブジェクトに対してアクトするための命令を、メッセージとして、送信しなければならないことである。このメッセージは、アクションの対象であるオブジェクトの名前をそのアドレスとして含み、アクション自体をペイロードとして含む。このメッセージは、エージェントからエージェントへルーティングされ、順次、名前を解決していく。例えば、「Dave宅のマスタベッドルームの照明をスイッチオンする」とのコマンドは、まず、Dave宅のロケーションを知るサーバに、ルーティングされる。そして、そのメッセージは、Dave宅のファイヤウォールデバイスにルーティングされ、そのファイヤウォールデバイスにおいて、アクセスがコントロールされ、認証が行われる。仮にアクセスのコントロールと認証とが正しく終了した場合には、要求されたアクションを行うため、当該メッセージのペイロードがデバイスに供給される。
【００１８】
ＳＩＰにおいては、名前ファンクションによるこのルーティングは、INVITEプロセスにおいて行なわれる。具体的には、INVITEは、まず、その名前のため、エージェントまたはプロキシに送られる。このプロキシは、その名前を書き換え、INVITEを中継し、このメッセージの最終のデスティネーションに近づいていき、そして一度到達すると、ペイロードを（慣用的には、ＳＤＰ（session description protocol）により）供給することができる。このメッセージの宛先となる受信側を突き止めるプロセスと、要求されるアクションとは、同一のプロシージャで、組み合わされる。加えて、ＳＩＰのセキュリティアーキテクチャにより、これら高レベルの名前に基づいて、ベリファイすることができる。
【特許文献１】
米国特許出願公開第２００２／０１０３８９８号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかしながら、ＳＩＰの能力と、ＮＡとの通信のための識別される要件とには、本質的な相違点が２つある。第１に、ＳＩＰロケーション情報は、InternetのＤＮＳ（Domain Name Server）アドレスであるＵＲＬの形態のものである。しかしながら、全てのＮＡがＩＰアドレスを有しているわけではない（例えば、アプライアンスコントローラの背後にあるX.10デバイス）。第２に、ＳＩＰのINVITEメッセージがパフォームできる唯一のアクションは、ＳＤＰ（または、他のＭＩＭＥタイプ、例えば、ISUP/QSIG）を使用して、関係付けされたベアラー（bearer）とのセッションをセットアップすることである。したがって、INVITEメッセージは、テレビ会議をセットアップすることはできるが、デバイスをコントロールするメッセージを伝送するようには設計されていない。
【００２０】
従来のＮＡシステムは、ホーム外からのアクセス、イベント、およびメディアストリーミングには、セキュリティを提供しない。したがって、ＳＩＰその他のシステムが、デバイスをコントロールするメッセージを伝送するのに適合できるのであれば、都合が良い。
【００２１】
特許文献１においては、これらの問題を解決するため、ＳＩＰを修正する方法が開示されている。具体的には、ＳＩＰフォーマットを使用して、ＮＡとのコマンドおよびケリーの通信を可能にするため、ＤＯという新しいメソッド、すなわち新しいＭＩＭＥタイプとアドレシング方式が、作成され、ＳＩＰに適用される。さらに、SUBSCRIBEおよびNOTIFYというメソッドは、ＳＩＰを拡張するため、インスタントメッセージングのために、他のものによって作成されたものであるが、これらメソッドは、ＮＡにコントロールメッセージを送信し、そのアプライアンスからステータス情報を受信するため、特許文献１において使用されている。特許文献１を付して本明細書の一部とする。
【課題を解決するための手段】
【００２２】
本発明は、一般には、ＳＩＰの改良に関し、具体的には、修正したＳＩＰネットワークを使用したＮＡのリモートコントロールに関する。
【００２３】
本発明の好ましい実施形態においては、特定のアクトをＳＩＰユーザエージェントからＳＩＰプロキシサーバ（ネットワークベースまたはゲートウェイベース）に移す。そのアクトには、アドレスマッピング、認証、オーソライゼーション、および変換が含まれる。その結果、エージェントサーバにおける処理とメモリ記憶の要件が軽減され、リモートデバイスのコンピューティング要件が全体的に軽減される。これには、各ＵＡＳのアクセスコントロール情報をＳＩＰプロキシサーバにおいて提供することが必要になる。仮にＳＩＰメッセージが、ＵＡＣからＵＡＳへエンドツーエンド（end-to-end）暗号化される場合には、（１）ＳＩＰプロキシサーバの暗号鍵で、当該メッセージを暗号化しなければならず、当該ＵＡＳは当該ＳＩＰプロキシサーバに自分の暗号鍵を提供しなければならないか、または（２）当該ＵＡＳが当該メッセージを解読し、それを認証およびオーソライズするため、当該ＳＩＰプロキシサーバに戻さなければならない。当該ＳＩＰプロキシサーバの暗号鍵の伝送は、ＳＩＰのREGISTERメッセージで行なわれる。当該ＳＩＰプロキシサーバが認証されオーソライズされた後、認証が成功した場合には、当該メッセージが当該ＵＡＳにホワードされることになる。
【００２４】
認証およびオーソライゼーションのアクトをＳＩＰプロキシサーバに移すのに加えて、本発明をＮＡに対して使用する場合には、ＮＡをコントロールするためＳＩＰを使用するとき、アドレスマッピングアクトもＳＩＰプロキシサーバに移動する。その結果、当該ＵＡＳは、そのアドレスを認識するだけでよく、アドレスをさらにマッピングする必要はない。仮に当該メッセージが当該ＵＡＳに向けられたものでない場合には、当該ＵＡＳはメッセージを受け取らず、ＳＩＰプロキシサーバが、メッセージを正しいデスティネーションに送信する。さらに、同様にして、プロトコル変換アクトも当該ＵＡＳから当該ＳＩＰプロキシサーバに移される。
【００２５】
本発明の上述その他の特徴は、以下の詳細な説明と本発明の実施形態の図面からより容易に明らかになるであろう。
【発明を実施するための最良の形態】
【００２６】
本発明によれば、ＳＩＰは、リモートアプライアンスのコントロールをインプリメントするための基本アーキテクチャとして使用される。しかしながら、このＳＩＰをその目的で使用する前に、一定の変更をしなければならない。具体的には、ＳＩＰにおいては、「To:」フィールドと、「From:」フィールドとに見られる名前は、ＵＲＬ（Universal Resource Locator）としてエンコードされる。現在のインプリメンテーションは、ＳＩＰとPHONE URLをサポートしている。しかし、このプロトコルの性質を変えることなく、ＮＡシステムのために、新しいタイプのＵＲＬを定義しなければならない。この新しいＵＲＬタイプによれば、アプライアンスアドレスを「ユーザフレンドリー」に発見することができる。ＲＦＣ２６０９で定義されたサービスＵＲＬシンタックスを使用するが、（既にＳＩＰルーティングにより判定されている）ロケーション情報を用いず、しかも「sip:」プレフィクスを用いない例においては、
d=lamp,r=bedroom
となる。
【００２７】
このＵＲＬをbase64でエンコードする（しかも、ドメインに含まれるデバイスタイプに関する情報が漏れるのを防止するために暗号化することも可能である）ことにより、このＵＲＬをＳＩＰＵＲＬの一部として構造化することが可能である。
sip:a458fauzu3k3z@stan.home.net
【００２８】
したがって、種々のアプライアンスに対応するように拡張したときでも、＜エンティティ＞＠＜ロケーション＞という現行の構造が維持される。
【００２９】
ＳＩＰは、当初から、コールセットアップ（call set-up）を念頭に置いて作成されていた。ＳＩＰは、２つのエンドポイント間でオンゴーイングベアラーパス（ongoing bearer path）を確立できるように、これら２つのエンドポイント間において関係（relationship）またはセッションを確立するために設計されている。この構造は、仮にＳＩＰのコネクション確立フェーズが除去され、ＳＩＰペイロードが一般化された場合に、「short-lived」コネクションのために一般化することができる。ＳＩＰが使用される現行の方法と、本発明による修正との相違点は、多くの点で、ＴＣＰ及びＵＤＰその他のセッション／データグラムプロトコルとの相違点と、類似している。
【００３０】
インスタントメッセージングのためにＳＩＰを使用するイニシアチブの一部として、現在、新しいメソッドが定義されている。このメソッドは、ＤＯというが、ＮＡシステムの要件を満たしており、ＳＤＰ（Session Description Protocol）を除くペイロード、すなわち、ＳＩＰ INVITEメッセージにとって典型的なＭＩＭＥペイロードを搬送することができる。通信情報を搬送する標準ＳＩＰボディすなわちペイロードと違って、ＤＯタイプには、ＮＡからのステータス情報をダイレクトし受信するために特化されたコントロールコマンドおよびケリーコマンドが含まれる。任意のＭＩＭＥタイプは、ＳＩＰコマンドのペイロードとして使用することができ、特定クラスのＮＡのためのコマンドまたはケリー（アクション言語）のために新しいＭＩＭＥタイプを容易に定義することができる。この新しいＭＩＭＥタイプの一例としては、ＤＭＰ（Device Messaging Protocol）がある。ＤＭＰは、ＵＰｎＰデバイスコントロールプロトコル（Universal Plug 'n Play's Device Control Protocol）に類似のＸＭＬベースの仕様である。ＵＰｎＰデバイスコントロールプロトコルについては、www.upnp.orgを参照されたい。したがって、ＤＯメッセージによれば、ターゲットアプライアンスに適したコマンド例えば「照明をターンオンする」が搬送されるか、「温度は何度か」のようなケリーが搬送される。このコマンドは、その結果を示す単一の応答をトリガし、この単一の応答は、標準ＳＩＰ応答メカニズムによって搬送される。
【００３１】
加えて、デバイスが（REGISTERメッセージを介して）ＳＩＰプロキシサーバに登録されるとき、そのデバイスの記述を搬送しなければならない。これは、この情報を搬送するＤＤＰ（device description protocol）によって行なわれる。このＤＤＰも、ＤＭＰと同様に、ＸＭＬベースである。
【００３２】
ＤＯタイプ要求の要求ＵＲＬは、そのメッセージがダイレクトされる当事者を識別する通常のＳＩＰＵＲＬである。慣用のＳＩＰでもそうであったが、事前に、セッションまたはコネクションを確立する必要はない。送信側は、所望の受信側のＵＲＬを必須の「To」フィールドに入れる。「From」フィールドは、メッセージの発信側を識別する。このメッセージは、Call-ＩＤも含んでいなくてはならない。ＳＩＰにおいて、このCall-ＩＤは、要求のグループを同一セッションに関係付けする。
【００３３】
各メッセージには、Ｃｓｅｑが含まれるが、このＣｓｅｑは、シーケンス番号であり、当該要求のメソッドの名前でもある。このＣｓｅｑは、当該セッションにおける各メッセージを一意に識別し、メッセージごとに増大する。ＤＯタイプは、それぞれ「Ｖｉａヘッダ」も搬送する。Ｖｉａヘッダには、当該要求がトラバースした当該システムのＩＰアドレスまたはＦＱＤＮのトレースが含まれる。要求が受信側に向かってプロキシからプロキシへ移動するとき、各プロキシはそれれぞれアドレスを付加し、すなわち、スタックの操作と同様にして、アドレスをヘッダに「プッシュ」する。アドレスがスタックされると、これが当該応答に反映され、各ＳＩＰプロキシサーバはトップ（top）にあるアドレスを「ポップ（pop）」し、このポップしたアドレスを使用して、当該応答をどこに送信するかを判定する。このＤＯ拡張を使用するクライアントは、当該要求に「Contact」ヘッダを挿入しなければならない（Contactは、当該要求を逆方向に、すなわち、オリジナルメッセージのターゲットからオリジナルメッセージのイニシエータへ、ルーティングするために使用される）。当該メッセージには、ボディも含まれる。このボディには、受信側によってレンダリングされるメッセージが含まれる。ＳＩＰは、コンテントを識別する標準的なＭＩＭＥヘッダ（Content-Type、Content-Length、およびContent-Encoding）を使用する。当該要求は、ＵＤＰまたはＴＣＰまたはＳＣＴＰによるトランスポートを使用して送信することができる。信頼性はＵＤＰにより保証され、コンジェスチョンは単に再送を行うことによりコントロールされる。
【００３４】
ＳＩＰのＤＯタイプは、次のフォーマットと９つの部分を有する。
DO sip:user2@domain.com SIP/2.0
(1) Via: [SIP/2.0/UPD user1pc.domain.com]
(2) From: [sip: user1@domain.com]
(3) To: [sip: user2 @ domain.com]
(4) Contact: [sip: user1 @user1pc.domain.com]
(5) Call-ID: [asd88asd77a@ 1.2.3.4]
(6) Cseq:[1 MESSAGE]
(7) Content-Type: [text/plain]
(8) Content-Length:[18]
(9) Body [例えば、"Watson, come here."]
角括弧内は、コンテントの例を示す。
【００３５】
この構造により、ＮＡとの同期通信が確立される。しかしながら、この構造は、非同期通信を確立するために必要である。例えば、自宅でアラームが鳴ったとき、ある温度に達したとき、あるいは玄関の呼び鈴が鳴ったとき、これらを知らせるため、当該システムにおいては非同期通信ができなければならない。
【００３６】
ＳＩＰインスタントメッセージングシステムは、２つの新しいプリミティブ、すなわち非同期通信を行うために使用できるＳＵＢＳＣＲＩＢＥとＮＯＴＩＦＹを定義する。これら２つのメソッドは、ここに提案したアドレッシングスキームと、デバイスメッセージングプロトコルＭＩＭＥタイプと協働して使用されるときは、ＮＡからのイベント通知と、ＮＡ間のイベント通知とが可能になる。
【００３７】
ＮＡをハンドルするためのＳＩＰの修正の詳細については、特許文献１の番号を付して本明細書の一部とする。
【００３８】
図１は典型的な従来技術のＳＩＰアーキテクチャを示す。かかる構成においては、Internet電話コールの意図された受信側として関係付けすることができる１つ以上のＵＡＳ（user agent server）とのＳＩＰ通信を開始するため、クライアント例えばInternet電話ユーザは、クライアントとしてオペレートするＳＩＰユーザエージェントアプリケーション、すなわちＳＩＰＵＡＣ１００を採用している。このシステムは、ネットワークデバイスとのリモート通信を可能にする３つの異なるタイプのアーキテクチャをサポートしている。実際のインプリメンテーションにおいては、これら３つのアーキテクチャを組み合せたものを使用することができる。
【００３９】
第１の構成においては、クライアントアプリケーションＵＡＣ１００は、幾つかのＵＡＳデバイス１１０、１１２、１１６、および１１８のうちのいずれかと直接に連絡（contact）し、インタラクトすることができる。この場合においては、当該クライアントは、パス１３０を介して受信側のＵＡＳ１１０と直接の連絡（contact）を確立する。第２のアーキテクチャにおいては、ネットワークデバイス例えばInternet電話と通信するため、クライアントアプリケーションに、InternetのＳＩＰプロキシ１０４とインタラクトさせる。第２のアーキテクチャにおいては、別のＳＩＰプロキシ１０４が、ＵＡＣ１００から、種々のＳＩＰＵＡＳデバイスの１つ、例えばＵＡＳに、パス１３２を介して、通信を渡す。
【００４０】
第３の構成においては、慣用のＳＩＰメッセージまたは要求は、まず、ＵＡＣ１００からInternetＳＩＰプロキシサーバ１０４にルーティングされ、ＳＩＰプロキシサーバ１０４において、その要求が処理され、ＳＩＰプロキシサーバ１０８に送信される。ついで、ＳＩＰプロキシサーバ１０８は、自分自身に関係付けされた幾つかのＵＡＳ１１０、１１２、１１４、１１６、１１８のうちの１つに、要求を送信する。これらＵＡＳは、個別のロケーション、例えばメッセージを受信するために選択された個人のホームに、位置させることができ、しかも、電話機のようなデバイスにエンベッドされるか付加されている。当該要求がＳＩＰＵＡＳ１１６に関係付けされたホームに対するものであると仮定すると、当該メッセージはＵＡＳ１１６に配信され、ＵＡＳ１１６に付加されたデバイスに配信される。当該メッセージに基づいて、ＵＡＳ１１６はメッセージに従ってデバイスをオペレートする。矢印すなわちパス１３４、１３６、１３８、１４０で示すように、ＵＡＳデバイスは、それぞれ、互いに、直接、通信することができる。
【００４１】
ＵＡＳ１１６は、当該メッセージを処理し、デバイスに命令を送信する前に、当該メッセージがＵＡＳ１１６にダイレクトされるものであるかを判定しなければならず、オーソライズされた個人によって送信されたものであるかを判定しなければならない。したがって、ＵＡＳ１１６と、他の全てのＵＡＳとは、当該メッセージのデスティネーションアドレスをチェックし、当該メッセージが、オーソライズされており、当該ＵＡＳが解釈できるフォーマットであることを確認しなければならない。さらに、当該ＵＡＳは、付加されたデバイスが理解し応答できるフォーマットに、当該メッセージを変換することができなくてはならない。
【００４２】
仮に、ＳＩＰプロトコルが、ＤＯ、ＳＵＢＳＣＲＩＢＥ、およびＮＯＴＩＦＹメソッドを含むように拡張された場合には、種々のＳＩＰアーキテクチャを使用してＮＡと通信することができる。このようなシステムのアーキテクチャを図２に示す。このアーキテクチャにより、クライアントアプリケーションは、ホームドメイン２００のＮＡとインタラクトすることができる。ＷＡＮ（wide area network）３００、例えばInternetを使用して、ＳＩＰＵＡＣ１００のクライアントアプリケーションから、（例えばＮＡサーバプロバイダのネットワークにある）外部のＳＩＰプロキシサーバ１０８に、当該メッセージが搬送される。このＳＩＰプロキシサーバ１０８は、ホームファイヤウォール／ＮＡＴ（network address translator）の形態で、数多くのＲＧＷ（redidential gateway）と通信している。ＲＧＷには、プロキシサーバ１１６が含まれるが、プロキシサーバ１１６はＵＡＳとすることができ、あるいは他のＵＡＳデバイスへ導くことができる。一度認証されると、これらメッセージはファイヤウォールを通過できる。ホームドメイン２００の内部においては、メッセージは、ホームＬＡＮ２０１を介して、適正なＮＡに搬送される。当該デバイスは、「ＩＰ対応」、すなわち到達したＳＩＰメッセージ自体を処理することができるもの、例えばデバイス２０２か、あるいはアプライアンス２０６のようなＩＰ非対応アプライアンスかのいずれかとすることができる。ＩＰ非対応アプライアンスは、ＳＩＰコントロール要求を、当該アプライアンスに特有のプロトコルに変換するため、アプライアンスコントローラ２０４を必要とする。
【００４３】
プロキシサーバとホームファイヤウォール／ＮＡＴとの間の全ての通信は、セキュアであるものと仮定する。図２に示す例において、当該プロキシサーバは、物理的に、ホームドメインのゲートウェイデバイス１１６に位置させてある。このプロキシサーバは、次の機能を含む数多くの機能を提供することができる。
・各メッセージ／要求の認証およびオーソライゼーション
・ホームドメイン内のＮＡのアドレスマッピング／解決
・外部世界との通信のためのホームファイヤウォール／ＮＡＴ（ＲＧＷ）のセキュリティ
・ＮＡのモビリティおよびトラッキングサービス
・クライアントアプリケーションの当該メッセージプロトコルマッピング。このアプローチをとることにより、ＮＡをリモートコントロールするために、種々のクライアントアプリケーションをサポートすることができる。
・サービスのためのチャージポイント
当該プロキシがゲートウェイデバイスに存在する場合には、当該プロキシが数多くの機能を必要とするから、当該ゲートウェイデバイスは、パフォーマンス、メモリ等の要件に、負担を付着させる（onerous）ことができる。これらゲートウェイデバイスが、上述したプロキシの能力をサポートするのに必要なリソースを有することができないから、当該能力の多くを、サービスプロバイダプロキシに移すことができる。仮にＳＩＰプロキシサーバ１０８とゲートウェイプロキシ１１６′との間に、セキュアなコネクション（例えばＩＰｓｅｃトンネル）が存在する場合には、当該ゲートウェイプロキシは、当該ＳＩＰメッセージを適正なＵＡにホワードする点においてのみ必要とされることになる。ゲートウェイプロキシにおいて、能力を分割する上で、「オール・オア・ナッシング（all or nothing）」の決定をする必要はなく、２つのプロキシ間で、均等（又は不均等）に分割することができる。このアプローチについては次のような利点がある。
・ＳＩＰプロキシの管理が中央で（centrally）行われ、分散システムの課題が回避される。ＳＩＰプロキシサーバ１０８ムとのローカルリンクにおいて障害が生じたとしても、能力は、サービスプロバイダのＳＩＰプロキシサーバ１０８を介して、ＷＡＮ３００から利用可能であり、例えば当該システムは、当該メッセージを別のホームにリダイレクトすることができる。
・ＩＰｓｅｃトンネルを作成するような制限的な構成をパフォームすることは、依然として必要であるが、ＲＧＷは最小構成される。
・サービスプロバイダの障害をトレラントにするコストを、複数のホームにおいて償却することができる。
【００４４】
図２の構成においては、ＳＩＰＵＡＳ（図１に示す）は、ホーム用ゲートウェイ（ＲＧＷ）と考えられている。しかしながら、代替実施形態においては、Internet対応アプライアンス２０２とアプライアンスコントローラ２０４とを、ＲＧＷをプロキシサーバとするＳＩＰＵＡＳデバイスと考えることができる。しかしながら、仮に例えばコントローラ２０４が２以上のアプライアンスをコントロールしない場合には、この構成においては、ＵＡＳデバイスはアドレスマッピング能力を必要としない。
【００４５】
このＳＩＰアーキテクチャは、特許文献１において上述したように修正したものであるが、ＮＡに適用した場合には幾つかの欠点がある。具体的には、現行のＳＩＰアーキテクチャにおいては、必要であれば、認証およびオーソライゼイション機能と、アドレス確認およびマッピング機能と、プロトコル変換機能を、ＳＩＰＵＡＳにパフォームさせることができる。これに伴う問題は、小型でエンベッドされたデバイスであって、処理およびメモリ記憶のための制限されたリソースを有するデバイスにおいて、当該エイジェントがディプロイ（deploy）されていることにある。加えて、このエージェントが分散されているので、これらの機能をマネジメント（management）し管理（administration）することが困難であり、各エージェントにおいて繰り返さなければならない。
【００４６】
図２に示すように、ＮＡシステムがインプリメントされており、このＮＡシステムにおいては、クライアント、すなわちホームオーナ（homeowner）は、ＳＩＰ（session initiation protocol）アーキテクチャを使用して、Internetを介して、ホームにコントロール信号を送信することにより、当該ホームにおいて、アプライアンスをリモートコントロールする。ホームドメイン１００外からそのドメイン内の任意のアプライアンスへの全コントロール通信は、サービスプロバイダのＳＩＰプロキシサーバ１０８を通過しなければならない。しかしながら、図１および図２に示すホームドメイン内のＵＡＳデバイスの形態のアプライアンスは、ホームＬＡＮ２０１を介して相互に通信することができる。しかし、本発明に係るシステムが、図１および図２に示す従来技術のＳＩＰシステムと異なる点は、ＵＡＳ１１０〜１１８間の通信パス（すなわちパス１３４〜１４０）を除いた点である。したがって、ホームドメイン１００内のＵＡＳデバイス間の全てのＵＡＳ通信は、図３に示すように、ホームプロキシサーバ１１６′を通過しなければならない。ホームドメイン外からこれらＵＡＳデバイスと通信するためには、全て、サービスプロバイダネットワークのＳＩＰプロキシサーバ１０８を介して、行わなければならない。加えて、図３においては、認証機能およびオーソライゼーション機能は、ＵＡＳから、ＳＩＰプロキシサーバ１１６′またはサービスプロバイダネットワークのＳＩＰプロキシサーバ１０８に移してある。このため、各ＵＡＳのためのアクセスコントロール情報を、ＳＩＰプロキシサーバ１１６′または１０８に位置させる必要がある。
【００４７】
図３は、本発明により修正されたＮＡをサポートするためのＳＩＰアーキテクチャの機能を表す図である。このアーキテクチャは、プロキシアーキテクチャによるメッセージングに基づく。図３においては、ＮＡの操作を求める要求か、ＮＡのステータスを求める要求は、発信元クライアントアプリケーション（発信元アプリケーション）において、ＳＩＰＵＡＣ１００から開始する。ＳＩＰＵＡＣ１００は、アプライアンスメッセージ（ＤＯ）を生成し、サービスプロバイダ又はホームＲＧＷのいずれかによってホストされるＳＩＰプロキシサーバ１０８に送信するため、発信元アプリケーションによって使用されている。サービスプロバイダドメインにおけるＳＩＰプロキシサーバ１０８は、ロケーションデータベース１４６でルックアップして、通信するアプライアンス（適正なホームドメインＲＧＷを含む）のアドレスを解決する。当該ＳＩＰプロキシサーバは、アプライアンスメッセージを、クライアントＳＩＰＵＡ１００から、ホームドメインＲＧＷのＳＩＰプロキシサーバ１１６′に転送するか、あるいはセキュアなコネクションを介して、ターゲットデバイスのＳＩＰＵＡＳに直接転送する。
【００４８】
ロケーションデータベース１４６には、ホームドメイン内の全ての登録されたアプライアンスに対するロケーション情報が含まれる。このデータベースは、登録プロシージャにおいて、サービスプロバイダのＳＩＰプロキシサーバ１０８によって収集された情報がポピュレート（populate）されている。具体的には、クライアントおよび各アプライアンスのロケーションを登録するため、ＲＥＧＩＳＴＥＲメッセージがＳＩＰプロキシサーバ１０８に送信される。アプライアンスの場合には、この登録は、単にそのアプライアンスがホームドメイン２００内に存在するとの登録とすることができる。さらに、これすら登録できない場合には、ホームドメイン２００のＩＰアドレスだけが登録される。その場合、どのアプライアンスが自分のホームドメインで利用可能かを、当該ユーザが知るであろうことが期待されている。当該ドメインにおける特定のアプライアンスに宛てたメッセージは、プロキシにおいてアドレスマッピングすることにより、当該アプライアンスにルーティングされる。従来技術においては、このことはプロキシ１１６′において行なわれる。しかしながら、本発明によれば、これは、ＳＩＰプロキシサーバ１０８において行なわれる。図示していないが、ＳＩＰプロキシサーバ１０８は、種々のホームドメイン２００をコントロールする複数のＵＡＳデバイス１１６′に接続されている。
【００４９】
当該ホームドメインのＲＧＷのＳＩＰプロキシサーバ１１６′（ＵＡＳとしてオペレートしている）は、ホームドメイン内のアプライアンスと、ワイドエリア内のエンティティとの間に、ゲートウェイを提供する。他のＲＧＷ機能、例えばファイヤウォールやＮＡＴは、ＲＧＷＳＩＰプロキシサーバ１１６′と同一のロケーションに配置することができる。ＳＩＰアプライアンスまたはアプライアンスコントローラは、発信元アプリケーションＳＩＰＵＡＣ１００からのＳＩＰアプライアンスメッセージを終了する。しかしながら、これらデバイスのアドレッシング情報は、ＳＩＰプロキシサーバ１０８にマッピングされる。非ＩＰアプライアンス２０６の場合には、ＳＩＰメッセージからのメッセージング情報は、コントローラ２０４に接続したラインに、デバイス１１６′を介して渡され、しかもインタワーキングユニット２０８に渡される。インタワーキングユニット２０８は、アプライアンスメッセージを変換してアプライアンスの使用可能なフォームにし、当該アプライアンスからのステータス情報を、当該ネットワークの使用可能なフォームに変換する。しかしながら、当該アプライアンスの言語によるアプライアンスメッセージの変換は、ＳＩＰプロキシサーバ１０８において行うこともできる。したがって、インタワーキングユニット２０８は、本発明によれば、排除することができるが、当該アプライアンスからステータス情報を提供する場合には、排除されない。
【００５０】
ＩＰ対応アプライアンス２０２は、発信元アプリケーションＳＩＰＵＡＣ１００からのＳＩＰアプライアンスコントロールメッセージを終了し、しかもアプライアンスアプリケーションのアプライアンスコントロールステータス情報を取り出し、インタワーキングユニット２０６を介入させずに直接に、このアプライアンスコントロールステータス情報に対してアクトし、あるいは非ＩＰアプライアンスに必要となる可能性のあるアプライアンスコントローラ２０４を必要とせずに、このアプライアンスコントロールステータス情報に対してアクトする。
【００５１】
図４は、認証、オーソライゼーション、変換、およびアドレスマッピング機能の、ＵＡＳデバイスからサービスプロバイダＳＩＰプロキシサーバ１０８へのアウトソーシングを示す図である。具体的には、メッセージが特定のＵＡＳ３１０に送信されると、ＳＩＰプロキシサーバ３２０は、当該メッセージが、信頼できるソース、例えばホームオーナからのものであることを確認する。この確認は、ＵＡＳにストアされる代わりにＳＩＰプロキシサーバにストアされ、しかもＳＩＰプロキシサーバによってチェックされるパスワードにより行うことができる。当該ソースが確認（authentic）できるものであるとしても、要求されるアクションは、当該個人にオーソライズされたアクションとすることができない。例えば、親は任意の機能をコントロールすることをオーソライズできるが、親は当該システムをセットアップして、子供に対して、照明をターンオンすることをオーライズするが、温度を調節することはオーソライズしないようにできる。そこで、当該ＳＩＰプロキシサーバは、オーソライズされた個人からのメッセージをチェックして、その個人が当該デバイスをコントロールする権限を有するか否かを確認する。この機能をパフォームするのに必要なコンピュテーションパワーは、ここでは、ＵＡＳ３１０からＳＩＰプロキシサーバ３２０に移されている。この結果、これらＵＡＳをより小さくして、消費電力を軽減させ、必要とするメモリおよびコンピューティングパワーを低減させることができる。この結果として、これらＵＡＳの機能をＳＩＰプロキシサーバで効率的に行うことができるので、ＵＡＳを増加させると、当該システムには過度の負担がかからない。
【００５２】
仮に当該ＳＩＰプロキシサーバが、認証およびオーソライゼーションが正しいと判断した場合には、当該コントロールメッセージはＵＡＳ３１０に送信される。ついで、当該コントロールメッセージはＵＡＳ３１０によりアプライアンスコントローラ３３０に配信され、コントローラ３３０は、要求されるオペレーション、すなわち照明３４０をターンオンすることができる。
【００５３】
さらに、図４にも示すように、認証およびオーソライゼーション機能に加えて、アドレスマッピングおよびプロトコル変換の機能も、ＵＡＳ３１０からＳＩＰプロキシサーバ３２０にリロケート（relocate）される。ＳＩＰプロキシサーバが、このアドレスマッピングを行い、プロトコル変換を行うためには、当該ＳＩＰプロキシサーバは、（１）アドレスマッピングテーブル − これは、ＳＩＰＲＥＧＩＳＴＥＲメッセージを使用して、デバイスごとにストアできる。（２）種々のデバイスプロトコルに対する変換「ルール」 − これは、事前に「プロビジョン（provision）」する必要がある。具体的には、デバイスが、REGISTERメッセージをＳＩＰプロキシサーバに発行するとき、当該デバイスは、（デバイス記述プロトコルＭＩＭＥタイプを使用した当該メッセージのペイロードに）、（１）当該デバイスが使用するデバイスプロトコルのタイプの記述と、（２）物理的なデバイスアドレスと、を含んでいなければならない。
【００５４】
当該メッセージに対する外部アドレス、例えば「light1@UAS.home.net」は、ＳＩＰプロキシサーバ３２０によって、ホームＬＡＮアドレスＡ２に変換され、そこで、ＵＡＳ３１０は変換を行う必要がない。さらに、コマンド「Turn On」は、アプライアンスコントローラ３３０が理解し応答できるX.10コードＢＯＮに変換される。
【００５５】
この構成においては、アドレス変換とプロトコルマッピングとをパフォームしなければならないのに代えて、ＵＡＳ３１０は、ＳＩＰプロキシサーバからＵＡＳに送信されるメッセージから、アドレスとプロトコルメッセージとを抽出（すなわちパース（parse））することができる。パースは、オペレーションにおいて、アドレスマッピングおよびプロトコル変換に比べてはるかにライトウェイト（lightweight）である。
【００５６】
従前のソリューションにおいては、これら機能は、全て、エンドポイント（endpoint）デバイスに配置しなければならなかった。これは、利用率を非常に低くできるとしても、あらゆるエンドポイントが、必要な全ての処理を行うだけの処理機能を有していなければならない、ことを意味する。本発明によれば、多数のエンドポイントにおいて、ソースを統計的に多重化することができる、全体的なコストを軽減することかできる。さらに、この技術をもってすれば、市場可能性（market possibilities）もある。あるネットワークインフラストラクチャに対して益々依存するということは、ユーザ（顧客、ホームオーナ等）が、このプロバイダに固定される可能性が高くなる、ことを意味する。これは、ネットワークオーナの観点から見て好ましい。
【００５７】
加えて、この構成によれば、ネットワークにおいて、使用及びチャージ／請求（billing）記録を収集することができるポイントも提供される。このアプローチに基づくと、一部の日用アプライアンス（例えば照明、冷蔵庫等）のコントロールに対しては、均一料金を請求するが、他の（高級）デバイス（例えばハイエンドＴＶ、ＤＶＤプレーヤ）のコントロールに対しては、チャージする、ことが可能である。
【００５８】
本発明は、従来技術のＳＩＰアーキテクチャの幾つかの基本概念とは異なる。本発明においては、ＳＩＰエンドポイントが相互に直接通信するのではなく、常にサービスプロバイダＳＩＰプロキシサーバを介して通信するように、ＳＩＰエンドポイントが構成されているものもある。このように変更すると、サービスプロバイダはアクセスをコントロールすることができ、価値を付加したサービスを、ホームネットワークに提供することができる。
【００５９】
上述したように、本発明は、ＮＡに適用することができる。しかしながら、認証およびオーソライゼーション要素をアウトソーシングすることは、Voice over ＩＰに対するＳＩＰに適用可能であり、インスタントメッセージングに対するＳＩＰに適用可能であり、その他のサービスに対するＳＩＰに適用可能である。さらに、この機能は、ＳＩＰプロキシサーバによって行われるメディア変換、例えばオーディオに変換されるテキストメッセージ、および／またはテキストに変換されるメッセージのために使用することができる。この機能は、ＳＩＰプロトコルをサポートするコールエージェント／Softswitch製品（Telcordia（登録商標）から販売されるような）に導入することができる。
【００６０】
新しく提案したＤＯ、SUBSCRIBE、およびNOTIFYメッセージによるＳＩＰであって、新しいＭＩＭＥタイプを加えたものと、サービス情報を「To:」フィールドにエンコードする新しいメカニズムとにより、ＷＡＮからのＮＡとの通信に必要なサポートを提供することができる。そうすると、ＮＡという新たな問題領域に対して、現行のＳＩＰインフラストラクチャと能力（例えばホップバイホップルーティングやセキュリティ）とレバレッジすることができる。さらに、幾つかのＵＡＳ機能をＳＩＰプロキシサーバにアウトソーシングすることにより、当該システムをコストイフェクティブ（cost effective）にすることができ、マーケティングの機会がシステムオーナに提供される。
【００６１】
以上、本発明について、本発明の好ましい実施形態を示し記述したが、本発明の精神および範囲から逸脱しない限り、形式および詳細を種々に変更することができる、ことは当業者にとって当然のことである。
【図面の簡単な説明】
【００６２】
【図１】従来技術のＳＩＰアーキテクチャを示す図である。
【図２】本発明によりホームＮＡシステムとの通信を実現するように修正したＳＩＰアーキテクチャの実施形態を示す図である。
【図３】相互に直接通信することができないＵＡＳデバイスを示す機能ネットワークアーキテクチャを示す図である。
【図４】本発明のさらなる態様によって、認証、オーソライゼーション、アドレスマッピング、およびプロトコル変換をＳＩＰプロキシサーバにアウトソーシングしたＳＩＰＮＡシステムを示す図である。

Claims

クライアントと少なくとも１つのネットワーク対応アプライアンスとの間の通信のためのＳＩＰシステムにおいて、
前記アプライアンスに接続したＵＡＳプロセッサであって、コマンドを前記アプライアンスに中継し、該アプライアンスからステータス情報を受信するＵＡＳプロセッサと、
前記アプライアンスに対するＳＩＰコマンドメッセージを、通信ネットワークを介して前記ＵＡＳプロセッサに送信し、前記アプライアンスに対するステータス情報メッセージを前記ＵＡＳプロセッサから前記通信ネットワークを介して受信する機能を有するＵＡＣプロセッサであって、受信したＳＩＰコマンドを前記アプライアンスによって認識されるコマンドに変換し、前記通信ネットワークを介して前記ＵＡＣプロセッサに伝送するために、前記アプライアンスから提供された情報をＳＩＰステータスメッセージに変換するＵＡＣプロセッサと、
前記ＵＡＣと前記ＵＡＳとの間に位置し、該ＵＡＣ及び該ＵＡＳとの間で情報を受信し伝達するネットワークアプライアンスシステムプロキシサーバと
を備え、
前記ＵＡＳプロセッサは、アドレスマッピング機能を使用して、前記アプライアンスへのメッセージと、前記アプライアンスからのメッセージの少なくとも一部とをハンドルし、
前記ネットワークアプライアンスシステムプロキシサーバは、前記少なくとも一部のメッセージを、当該メッセージの宛先とするアプライアンスに、適正なＵＡＳプロセッサを介してダイレクトするアドレスマッピング機能を有する
ことを特徴とするシステム。
クライアントと少なくとも１つのネットワーク対応アプライアンスとの間の通信のためのＳＩＰシステムにおいて、
前記アプライアンスに接続されたＵＡＳプロセッサであって、コマンドを前記アプライアンスに中継し、前記アプライアンスからステータス情報を受信するＵＡＳプロセッサと、
前記アプライアンスに対するＳＩＰコマンドメッセージを、前記ＵＡＳプロセッサに通信ネットワークを介して送信し、前記アプライアンスについてのステータス情報メッセージを前記ＵＡＳプロセッサから前記通信ネットワークを介して受信する機能を有するＵＡＣプロセッサであって、受信したＳＩＰコマンドを前記アプライアンスによって認識されるコマンドに変換し、前記通信ネットワークを介して前記ＵＡＣプロセッサに伝送するため、前記アプライアンスから提供された情報をＳＩＰステータスメッセージに変換するＵＡＣプロセッサと、
前記ＵＡＣと前記ＵＡＳの間に位置し、該ＵＡＣ及び該ＵＡＳとの間で情報を受信し伝達するネットワークアプライアンスシステムプロキシサーバと
を備え、
前記ＵＡＳプロセッサは、少なくとも一部のメッセージ認証機能を使用せず、
前記ネットワークアプライアンスシステムプロキシサーバは、該ネットワークアプライアンスシステムプロキシサーバに接続された前記ＵＡＳプロセッサに接続されたアプライアンスに対する認証機能であって、あるアプライアンスにダイレクトされるメッセージが、オーソライズされたクライアントからのものであることを保証するためにアクトする認証機能を有する
ことを特徴とするシステム。
請求項１において、前記ＵＡＳプロセッサは、少なくとも一部のメッセージ認証機能を使用せず、
前記ネットワークアプライアンスシステムプロキシサーバは、前記ＵＡＳサーバによって前記ネットワークアプライアンスシステムプロキシサーバに接続されたアプライアンスのための認証機能であって、あるアプライアンスにダイレクトされるメッセージが、真正のクライアントからのものであることを保証するためにアクトする認証機能を有する
ことを特徴とするＳＩＰシステム。
請求項１において、前記ＵＡＳプロセッサは、少なくとも一部のメッセージ認証機能を使用せず、
前記ネットワークアプライアンスシステムプロキシサーバは、前記ＵＡＳサーバによって前記プロキシに接続されたアプライアンスのためのオーソライゼーション機能であって、あるアプライアンスにダイレクトされた前記メッセージ中のコマンドが前記クライアントの権限内にあることを保証するためにアクトするオーソライゼーション機能を有する
ことを特徴とするＳＩＰシステム。
請求項１において、前記ＵＡＳプロセッサは、少なくとも一部のメッセージ変換機能を使用せず、
前記ネットワークアプライアンスシステムプロキシサーバは、前記ＵＡＳサーバによって前記プロキシに接続されたアプライアンスのための変換機能であって、あるアプライアンスにダイレクトされた前記メッセージ中のコマンドが、前記アプライアンスが解釈できる形態であることを保証するためにアクトする変換機能を有する
ことを特徴とするＳＩＰシステム。
請求項２において、前記ＵＡＳプロセッサは、少なくとも一部のアドレスマッピング機能を使用せず、
前記ネットワークアプライアンスシステムプロキシサーバは、前記ＵＡＳサーバによって前記プロキシに接続されたアプライアンスのためのアドレスマッピング機能であって、あるメッセージが適正なアプライアンスにダイレクトされることを保証するためにアクトするアドレスマッピング機能を有する
ことを特徴とするＳＩＰシステム。
請求項２において、前記ＵＡＳプロセッサは、少なくとも一部の変換機能を使用し、
前記ネットワークアプライアンスシステムプロキシサーバは、前記ＵＡＳサーバによって前記プロキシに接続されたアプライアンスのための変換機能であって、あるアプライアンスにダイレクトされた前記メッセージ中のコマンドが、前記アプライアンスが解釈できる形態であることを保証するためにアクトする変換機能を有する
ことを特徴とするＳＩＰシステム。
請求項２において、前記ＵＡＳプロセッサと前記アプライアンスとの間に位置するアプライアンスコントローラであって、
前記プロキシからのコマンドを、前記アプライアンスのオペレーションを制御する信号に変換し、前記アプライアンスからのステータス信号を、前記プロキシによって解釈できる信号に変換するアプライアンスコントローラをさらに含むことを特徴とするＳＩＰシステム。
請求項２において、複数のアプライアンスが、１つの地理的な場所にあって、単一のＵＡＳプロセッサにネットワーク化されており、
前記コマンドメッセージは、該コマンドメッセージがアドレスされるアプライアンスを識別し、
前記ネットワークアプライアンスシステムプロキシサーバは、前記メッセージを、該メッセージの宛先とする適正なアプライアンスに到達するように符号化された適正なＵＡＳプロセッサに、ダイレクトする
ことを特徴とするＳＩＰシステム。
請求項９において、前記複数のアプライアンスからのステータス情報は、それぞれ、その情報の発信元であるアプライアンスを識別し、
前記ネットワークアプライアンスシステムプロキシサーバは、前記ＵＡＣに送信されるステータスメッセージ中に前記アプライアンスのＩＤを含める
ことを特徴とするＳＩＰシステム。
クライアントと少なくとも１つのネットワーク対応アプライアンスとの間でＳＩＰを使用して通信を行う方法において、
ＵＡＣプロセッサを使用して、前記アプライアンスに宛てたＳＩＰコマンドメッセージを、通信ネットワークを介して、プロキシサーバに送信するステップと、
前記プロキシサーバで前記コマンドメッセージを受信するステップと、
前記プロキシサーバのアドレスマッピング機能を使用して、前記アプライアンスに関係付けされているＵＡＳプロセッサに、少なくとも一部のメッセージを導くステップと、
前記アプライアンスに関係付けをした前記ＵＡＳプロセッサにおいて前記プロキシサーバからのメッセージを受信するステップと、
前記ＵＡＳプロセッサを使用して、受信したＳＩＰコマンドを、前記アプライアンスによって認識されるコマンドに変換するステップと
を備えたことを特徴とする通信方法。
請求項１１において、前記コマンドはケリーであり、
本通信方法は、
前記ＵＡＳプロセッサにおいて、前記アプライアンスのステータス情報を受信するステップと、
前記ＵＡＳプロセッサを使用して、前記ステータス情報をＳＩＰプロトコルに変換するステップと、
前記ＵＡＳステータス情報をＳＩＰプロトコルにより前記プロキシを介して前記ＵＡＣプロセッサに伝送するステップと、
前記ＵＡＣプロセッサにおいて、前記ステータス情報を表示するステップと
を含むことを特徴とする通信方法。
クライアントと少なくとも１つのネットワーク対応アプライアンスとの間でＳＩＰを使用して通信を行う方法において、
ＵＡＣプロセッサを使用して、前記アプライアンスに宛てたＳＩＰコマンドメッセージを、通信ネットワークを介してプロキシサーバに送信するステップと、
前記プロキシサーバにおいて、前記コマンドメッセージを受信するステップと、
前記プロキシサーバの認証機能を使用して、あるアプライアンスに宛てた前記メッセージが、真正のクライアントからのものであることを保証するステップと、
前記アプライアンスに関係付けされているＵＡＳプロセッサにおいて前記プロキシサーバからのメッセージを受信するステップと、
前記ＵＡＳプロセッサを使用して、受信されたＳＩＰコマンドを、前記アプライアンスによって認識されるコマンドに変換するステップと
を備えたことを特徴とする通信方法。
クライアントと少なくとも１つのネットワーク対応アプライアンスとの間でＳＩＰを使用したて通信を行う方法において、
ＵＡＣプロセッサを使用して、前記アプライアンスに宛てたＳＩＰコマンドメッセージを、通信ネットワークを介してプロキシサーバに送信するステップと、
前記プロキシサーバにおいて、前記コマンドメッセージを受信するステップと、
前記プロキシサーバの認証機能を使用して、あるアプライアンスに宛てた前記メッセージが、前記クライアントのためにオーソライズされたコマンドを含むことを保証するステップと、
前記アプライアンスに関係付けされた前記ＵＡＳプロセッサにおいて、オーソライズされたメッセージのみを前記プロキシサーバから受信するステップと、
前記ＵＡＳプロセッサを使用して、受信されたＳＩＰコマンドを、前記アプライアンスによって認識されるコマンドに変換するステップと
を備えたことを特徴とする通信方法。
クライアントと少なくとも１つのネットワーク対応アプライアンスとの間でＳＩＰを使用して通信を行う方法において、
ＵＡＣプロセッサを使用して、前記アプライアンスに宛てたＳＩＰコマンドメッセージを、通信ネットワークを介してプロキシサーバに送信するステップと、
前記プロキシサーバにおいて前記コマンドメッセージを受信するステップと、
前記プロキシサーバの変換機能を使用して、あるアプライアンスに宛てた前記メッセージ中のコマンドが、前記アプライアンスの解釈できる形態であることを保証するステップと、
前記アプライアンスに関係付けされたＵＡＳプロセッサにおいて、前記プロキシサーバからメッセージを受信するステップと、
前記ＵＡＳプロセッサを使用して、受信されたＳＩＰコマンドを、前記アプライアンスによって認識されるコマンドに変換するステップと
を備えたことを特徴とする通信方法。
請求項１５において、前記プロキシサーバは、直列に接続された少なくとも第１および第２のプロキシサーバであり、
アドレスマッピング、認証、許可、および変換機能のうちの１つの一部は、少なくとも部分的に、前記ＵＡＳプロセッサから前記第１および第２のプロキシサーバの少なくとも１つにアウトソーシングされる
ことを特徴とする通信方法。