(57)【特許請求の範囲】
【請求項１】
同期型トランザクションネットワーク及び非同期型トランザクションネットワークに対応したゲートウェイ装置において、
同期型トランザクションネットワーク対応機器及び非同期型トランザクションネットワーク対応機器と通信する通信手段と、
前記同期型トランザクションネットワークの通信プロトコルであるＨＴＴＰと、前記非同期型トランザクションネットワークの通信プロトコルであるＳＩＰを変換する変換手段と、
前記通信手段により前記同期型トランザクションネットワーク対応機器から受信したＨＴＴＰリクエストを保持する保持手段と、
を備え、
前記変換手段は、
前記通信手段により前記同期型トランザクションネットワーク対応機器から受信した第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーがＮｕｌｌである場合、前記第１のＨＴＴＰリクエストメッセージを前記保持手段に保持し、
前記通信手段により前記同期型トランザクションネットワーク対応機器から受信した第２のＨＴＴＰリクエストメッセージのＨＴＴＰボディーにＳＩＰリクエストメッセージが含まれている場合、ＨＴＴＰボディーがＮｕｌｌである第１のＨＴＴＰレスポンスメッセージを、前記第１のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、さらに、前記ＳＩＰリクエストメッセージを格納した第１のＳＩＰメッセージを前記非同期型トランザクションネットワーク対応機器に送信するとともに、ＨＴＴＰボディーにＯＫメッセージを格納した第２のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、
前記通信手段により、前記非同期型トランザクションネットワーク対応機器から、前記第１のＳＩＰメッセージのレスポンスとして、ＳＩＰレスポンスメッセージを含む第２のＳＩＰメッセージを受信した場合、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーに前記ＳＩＰレスポンスメッセージを格納した第３のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信する、ゲートウェイ装置。
【請求項２】
前記変換手段は、前記非同期型トランザクションネットワーク対応機器から、所定時間以上、前記第２のＳＩＰメッセージを受信しない場合には、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージを用いて、ＨＴＴＰボディーがＮｕｌｌである第４のＨＴＴＰレスポンスメッセージを、前記同期型トランザクションネットワーク対応機器に返信する、請求項１に記載のゲートウェイ装置。
【請求項３】
同期型トランザクションネットワーク及び非同期型トランザクションネットワークに対応したゲートウェイ装置における通信方法であって、
前記同期型トランザクションネットワーク対応機器から受信した第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーがＮｕｌｌである場合、前記第１のＨＴＴＰリクエストメッセージを保持手段に保持するステップと、
前記同期型トランザクションネットワーク対応機器から受信した第２のＨＴＴＰリクエストメッセージのＨＴＴＰボディーにＳＩＰリクエストメッセージが含まれている場合、ＨＴＴＰボディーがＮｕｌｌである第１のＨＴＴＰレスポンスメッセージを、前記第１のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、さらに、前記ＳＩＰリクエストメッセージを格納した第１のＳＩＰメッセージを前記非同期型トランザクションネットワーク対応機器に送信するとともに、ＨＴＴＰボディーにＯＫメッセージを格納した第２のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、
前記非同期型トランザクションネットワーク対応機器から、前記第１のＳＩＰメッセージのレスポンスとして、ＳＩＰレスポンスメッセージを含む第２のＳＩＰメッセージを受信した場合、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーに前記ＳＩＰレスポンスメッセージを格納した第３のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、
を含む、通信方法。
【請求項４】
前記非同期型トランザクションネットワーク対応機器から、所定時間以上、前記第２のＳＩＰメッセージを受信しない場合には、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージを用いて、ＨＴＴＰボディーがＮｕｌｌである第４のＨＴＴＰレスポンスメッセージを、前記同期型トランザクションネットワーク対応機器に返信するステップをさらに含む、請求項３に記載の通信方法。
【請求項５】
同期型トランザクションネットワーク及び非同期型トランザクションネットワークに対応したゲートウェイ装置に、
前記同期型トランザクションネットワーク対応機器から受信した第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーがＮｕｌｌである場合、前記第１のＨＴＴＰリクエストメッセージを保持手段に保持するステップと、
前記同期型トランザクションネットワーク対応機器から受信した第２のＨＴＴＰリクエストメッセージのＨＴＴＰボディーにＳＩＰリクエストメッセージが含まれている場合、ＨＴＴＰボディーがＮｕｌｌである第１のＨＴＴＰレスポンスメッセージを、前記第１のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、さらに、前記ＳＩＰリクエストメッセージを格納した第１のＳＩＰメッセージを前記非同期型トランザクションネットワーク対応機器に送信するとともに、ＨＴＴＰボディーにＯＫメッセージを格納した第２のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、
前記非同期型トランザクションネットワーク対応機器から、前記第１のＳＩＰメッセージのレスポンスとして、ＳＩＰレスポンスメッセージを含む第２のＳＩＰメッセージを受信した場合、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーに前記ＳＩＰレスポンスメッセージを格納した第３のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲートウェイ装置、通信方法及びプログラムに関する。
【背景技術】
【０００２】
インターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を利用して映像コンテンツの配信を行う、いわゆるＩＰＴＶ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｔｅｌｅｖｉｓｉｏｎ）サービスのシステムとしては、米国マイクロソフト社などさまざまなベンダーが開発、商用化している。近年では、ＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）を利用したＩＰＴＶサービスが注目されている。
【０００３】
ＩＭＳは元来、携帯電話の無線通信インフラストラクチャーにおいて、音声による電話サービス以外にも、マルチメディアの付加サービスを提供するための基盤技術として、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で開発されている通信方式である。このＩＭＳは、ＩＰ技術をベースとしており、固定通信系のインターネットのインフラストラクチャーとの親和性が高い。また、ＦＭＣ（Ｆｉｘｅｄ  Ｍｏｂｉｌｅ  Ｃｏｎｖｅｒｇｅｎｃｅ）と呼ばれる有線、無線の通信ネットワークインフラストラクチャーをＩＰにて統合する動向もある中、ＩＭＳをＩＰＴＶに利用することによって、コンテンツ配信のためのＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を実現できるとともに、携帯電話へメッセージを送ったり、チャットなどの通信サービスをＩＰＴＶサービスと連携させて提供したりできる。
【０００４】
図１にＩＭＳを利用したＩＰＴＶシステムのアーキテクチャーを示す。図１に示すように、ＩＭＳは、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）に基づくＣＳＣＦ（Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）２２と呼ばれる機能要素を核として、ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｕｂｓｙｓｔｅｍ）２４、ＡＳ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）２６などの機能要素から構成される。ＳＩＰは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）のＲＦＣ−３２６１（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔ−３２６１）で規定された通信プロトコルである。
【０００５】
かかるＩＭＳの仕組みについて概略的に説明すると、ユーザＩＤが設定されたユーザ端末１０、１２は、ＩＭＳネットワーク２０のＣＳＣＦ２２にアクセスして、ユーザ端末１０の登録、セッションの設定制御を行う。この過程で、ＨＳＳ２４に登録されたユーザプロファイルの設定に従って、必要なサービスに対応するＡＳ２６の処理起動を行う。ＡＳ２６は実際に個々のサービスを提供するための処理を行うサーバである。
【０００６】
例えば、ＩＭＳを利用したサービスの一例であるチャットアプリケーション（ＰｕｓｈＴｏＴａｌｋ）では、例えば携帯電話からなるユーザ端末１２は、携帯電話ネットワーク４０を介して、ＩＭＳネットワーク２０にてＰｕｓｈＴｏＴａｌｋを担当するＡＳ２６と接続する。そして、ユーザ端末１２は、登録済のグループメンバーに対してＡＳ２６から複数メンバーの端末（図示せず。）とのセッションを確立し、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を用いて、中継サーバ経由でメンバー間の通話を行う。
【０００７】
また、ＩＭＳを利用したサービスの別の例として、ＩＭＳのＩＰＴＶシステムでは、ＩＭＳネットワーク２０においてＩＰＴＶサービスのＡＳ２６が提供される。家庭内のユーザ端末１０、例えば、ＳＴＢ（Ｓｅｔ  Ｔｏｐ  Ｂｏｘ）は、同様な手順にて、ＡＳ（ＩＰＴＶ）２６に接続することでＩＰＴＶサービスを受けることができる。ＡＳ（ＩＰＴＶ）２６は、実際にはＩＰＴＶサービス３０を司るＥＰＧサーバ（Ｅｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ  Ｓｅｒｖｅｒ）３２、及び、映像コンテンツを配信するビデオサーバ（Ｖｉｄｅｏ  Ｓｅｒｖｅｒ）３４と連携して、ＩＰＴＶサービス３０を実現する。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、従来のＩＭＳでは、ユーザ端末１２がＳＩＰをサポートすることを想定している。一方、ＩＰＴＶ端末１０にて、ＥＰＧ画面やサービス画面を利用者に提示するユーザインタフェースの技術として、ＨＴＭＬブラウザを利用することで、サービス提供者が画面のデザインをカスタマイズできるなど、様々なアプリケーションをサービス側で実現できる。例えば、図１に示すＥＰＧサーバ３２は、例えば、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サーバで構成されて、ＥＰＧ画面を構成するＨＴＭＬドキュメントを、ブロードバンドＩＰネットワーク４２を介して、ＩＰＴＶ端末１０に提供する。
【０００９】
このアーキテクチャーでは、ＩＰＴＶ端末１０は、直接、ＳＩＰなるプロトコルをサポートしなくても済むように、ユーザ宅１１内に、“ＩＭＳ  Ｇａｔｅｗａｙ”と呼ばれるゲートウェイ（ＧＷ）装置５０を導入する仕組みが考えられる。このＩＭＳゲートウェイ装置５０は、ＩＭＳのＳＩＰ通信のデータを、ＩＰＴＶ端末１０のＨＴＭＬブラウザがサポートするプロトコルであるＨＴＴＰのデータに変換するための変換装置として機能する。
【００１０】
しかしながら、ＨＴＴＰとＳＩＰとでは通信の手順が異なるために、ＩＭＳゲートウェイ装置５０に、かかるプロトコル変換を行うアプリケーションを配置して、ＳＩＰプロトコルをより抽象度の高いハイレベルなインターフェースに変換し、例えば、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）などのメッセージコールをＨＴＴＰにて伝送する必要がある。このため、かかるアプリケーションゲートウェイを実装するために、ＩＭＳゲートウェイ装置５０は、ＣＰＵ、メモリーなどのハードウェア資源を多く必要とするので、ＩＭＳゲートウェイ装置５０が高価になってしまうという問題があった。
【００１１】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、同期型トランザクションネットワークと非同期型トランザクションネットワークとの間で、異なるプロトコル（例えば、ＨＴＴＰとＳＩＰ）のデータを簡単な方式で変換することで、ＣＰＵ、メモリーなどのハードウェア資源を低減することが可能な、新規かつ改良されたゲートウェイ装置、通信方法及びプログラムを提供することにある。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明のある観点によれば、同期型トランザクションネットワーク及び非同期型トランザクションネットワークに対応したゲートウェイ装置において、同期型トランザクションネットワーク対応機器及び非同期型トランザクションネットワーク対応機器と通信する通信手段と、前記同期型トランザクションネットワークの通信プロトコルであるＨＴＴＰと、前記非同期型トランザクションネットワークの通信プロトコルであるＳＩＰを変換する変換手段と、前記通信手段により前記同期型トランザクションネットワーク対応機器から受信したＨＴＴＰリクエストを保持する保持手段と、を備え、前記変換手段は、前記通信手段により前記同期型トランザクションネットワーク対応機器から受信した第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーがＮｕｌｌである場合、前記第１のＨＴＴＰリクエストメッセージを前記保持手段に保持し、前記通信手段により前記同期型トランザクションネットワーク対応機器から受信した第２のＨＴＴＰリクエストメッセージのＨＴＴＰボディーにＳＩＰリクエストメッセージが含まれている場合、ＨＴＴＰボディーがＮｕｌｌである第１のＨＴＴＰレスポンスメッセージを、前記第１のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、さらに、前記ＳＩＰリクエストメッセージを格納した第１のＳＩＰメッセージを前記非同期型トランザクションネットワーク対応機器に送信するとともに、ＨＴＴＰボディーにＯＫメッセージを格納した第２のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、前記通信手段により、前記非同期型トランザクションネットワーク対応機器から、前記第１のＳＩＰメッセージのレスポンスとして、ＳＩＰレスポンスメッセージを含む第２のＳＩＰメッセージを受信した場合、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーに前記ＳＩＰレスポンスメッセージを格納した第３のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信する、ゲートウェイ装置が提供される。
【００１４】
前記変換手段は、前記非同期型トランザクションネットワーク対応機器から、所定時間以上、前記第２のＳＩＰメッセージを受信しない場合には、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージを用いて、ＨＴＴＰボディーがＮｕｌｌである第４のＨＴＴＰレスポンスメッセージを、前記同期型トランザクションネットワーク対応機器に返信するようにしてもよい。

【００１６】
また、上記課題を解決するために、本発明の別の観点によれば、同期型トランザクションネットワーク及び非同期型トランザクションネットワークに対応したゲートウェイ装置における通信方法であって、前記同期型トランザクションネットワーク対応機器から受信した第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーがＮｕｌｌである場合、前記第１のＨＴＴＰリクエストメッセージを保持手段に保持するステップと、前記同期型トランザクションネットワーク対応機器から受信した第２のＨＴＴＰリクエストメッセージのＨＴＴＰボディーにＳＩＰリクエストメッセージが含まれている場合、ＨＴＴＰボディーがＮｕｌｌである第１のＨＴＴＰレスポンスメッセージを、前記第１のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、さらに、前記ＳＩＰリクエストメッセージを格納した第１のＳＩＰメッセージを前記非同期型トランザクションネットワーク対応機器に送信するとともに、ＨＴＴＰボディーにＯＫメッセージを格納した第２のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、前記非同期型トランザクションネットワーク対応機器から、前記第１のＳＩＰメッセージのレスポンスとして、ＳＩＰレスポンスメッセージを含む第２のＳＩＰメッセージを受信した場合、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーに前記ＳＩＰレスポンスメッセージを格納した第３のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、を含む、通信方法が提供される。
【００１８】
さらに、前記非同期型トランザクションネットワーク対応機器から、所定時間以上、前記第２のＳＩＰメッセージを受信しない場合には、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージを用いて、ＨＴＴＰボディーがＮｕｌｌである第４のＨＴＴＰレスポンスメッセージを、前記同期型トランザクションネットワーク対応機器に返信するステップを含むようにしてもよい。

【００２０】
また、上記課題を解決するために、本発明の別の観点によれば、同期型トランザクションネットワーク及び非同期型トランザクションネットワークに対応したゲートウェイ装置に、前記同期型トランザクションネットワーク対応機器から受信した第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーがＮｕｌｌである場合、前記第１のＨＴＴＰリクエストメッセージを保持手段に保持するステップと、前記同期型トランザクションネットワーク対応機器から受信した第２のＨＴＴＰリクエストメッセージのＨＴＴＰボディーにＳＩＰリクエストメッセージが含まれている場合、ＨＴＴＰボディーがＮｕｌｌである第１のＨＴＴＰレスポンスメッセージを、前記第１のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信し、さらに、前記ＳＩＰリクエストメッセージを格納した第１のＳＩＰメッセージを前記非同期型トランザクションネットワーク対応機器に送信するとともに、ＨＴＴＰボディーにＯＫメッセージを格納した第２のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、前記非同期型トランザクションネットワーク対応機器から、前記第１のＳＩＰメッセージのレスポンスとして、ＳＩＰレスポンスメッセージを含む第２のＳＩＰメッセージを受信した場合、前記保持手段に保持された前記第１のＨＴＴＰリクエストメッセージのＨＴＴＰボディーに前記ＳＩＰレスポンスメッセージを格納した第３のＨＴＴＰレスポンスメッセージを、前記第２のＨＴＴＰリクエストメッセージに対するレスポンスとして、前記同期型トランザクションネットワーク対応機器に返信するステップと、を実行させるためのプログラムが提供される。
【００２１】
かかる構成により、同期型トランザクションネットワーク対応機器から、トランザクションリクエストが受信され、当該トランザクションリクエストが保持手段に保持され、非同期型トランザクションネットワーク対応機器からイベントが受信され、前記イベントの受信に応じて、前記保持手段に保持された前記トランザクションリクエストに対するレスポンスとして、前記イベントを含むメッセージが、前記同期型トランザクションネットワーク対応機器に送信される。このため、同期型トランザクションネットワークに対応する第１プロトコル（例えばＳＩＰ）のメッセージを、同期型トランザクションネットワークに対応する第２プロトコル（例えばＨＴＴＰ）のメッセージに簡単に変換して、同期型トランザクションネットワーク対応機器に提供できる。
【発明の効果】
【００２２】
以上説明したように本発明によれば、同期型トランザクションネットワークと非同期型トランザクションネットワークとの間で、異なるプロトコル（例えば、ＨＴＴＰとＳＩＰ）のデータを簡単な方式で変換できるので、ゲートウェイ装置に搭載されるＣＰＵ、メモリーなどのハードウェア資源を低減することができる。
【発明を実施するための最良の形態】
【００２３】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２４】
（第１の実施形態）
以下に、本発明の第１の実施形態にかかるＩＭＳゲートウェイ装置を備えたＩＰＴＶシステムについて説明する。ＩＰＴＶシステムは、図１と同様に、ユーザ宅１１に設けられたホームネットワークを構成するＩＰＴＶ端末及びＩＭＳゲートウェイ装置５０と、ＩＰＴＶサービス３０を提供する各種サーバ３２、３４と、ＩＭＳネットワーク２０を構成するＣＳＣＦ２２、ＨＳＳ２４及びＡＳ２６とから構成される。
【００２５】
まず、図２を参照して、本実施形態にかかるＩＰＴＶシステムの概略構成について説明する。図２は、本実施形態にかかるＩＰＴＶシステムのアーキテクチャーを概略的に示す。
【００２６】
図２に示すように、ユーザ宅に設けられるホームネットワークは、ＩＰＴＶサービスを受信するＩＰＴＶ端末１０と、“ＩＭＳ  Ｇａｔｅｗａｙ”と称されるＩＭＳに対応したゲートウェイ装置５０（以下、「ＩＭＳゲートウェイ５０」という。）と、を備える。
【００２７】
ＩＭＳゲートウェイ５０は、例えば、ＳＩＭカード（Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ  Ｍｏｄｕｌｅ  ｃａｒｄ）を用いてＩＭＳネットワーク２０との認証を行う。その他にも、ＩＭＳゲートウェイ５０は、ＩＭＳのＳＩＰの役割であるＱｏＳのためのセッションセットアップや、ＣＨＡＴなどのＳＩＰを利用したコミュニケーションの機能をＩＰＴＶ端末１０に提供する。ホームネットワークをＩＰネットワークに接続するためのホームルータが必要であるが、通常、ホームルータの機能はＩＭＳゲートウェイ５０に実装される。
【００２８】
ＩＰＴＶ端末１０は、例えば、ＳＴＢ、テレビジョン受像器、パーソナルコンピュータ等のＣＥ機器（Ｃｏｎｓｕｍｅｒ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｄｅｖｉｃｅ）で構成される。ＩＰＴＶ端末１０にはＨＴＭＬブラウザ１３が実装される。以下の説明では、ＨＴＭＬブラウザ１３として、例えば、ＣＥＡ−２０１４規格で規定されたＨＴＭＬブラウザを利用する例について説明する。
【００２９】
ＨＴＭＬブラウザ１３は、ＩＰＴＶサービス３０から提供されるＨＴＭＬドキュメント（例えば、ＥＣＭＡ（Ｅｕｒｏｐｅａｎ  Ｃｏｍｐｕｔｅｒ  Ｍａｎｕｆａｃｔｕｒｅｒ  Ａｓｓｏｃｉａｔｉｏｎ）  ＳＣＲＩＰＴによって記述されたアプリケーションを含む。）を表示する。これにより、ＩＰＴＶ端末１０のユーザが、リモートコントローラなどのユーザインタフェースを用いて、ＨＴＭＬブラウザ１３により表示された画面を操作することによって、ＩＰＴＶサービス３０へのアクセスが実現される。
【００３０】
そのほか、ＨＴＭＬブラウザ１３は、例えば、ＭＰＥＧ２又はＨ．２６４／ＡＶＣなどの所定の圧縮符号化方式で圧縮された映像信号を、ＨＴＭＬ画面の一部に表示する、又は、オーバーレイさせて表示するメディア再生プレイヤーのプラグが実装されている。ＩＰＴＶサービス３０のビデオサーバ３４から提供されるビデオコンテンツは、例えば、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）又はＨＴＴＰなどの通信プロトコルに従って、ＩＰＴＶ端末１０に配信される。そして、当該ビデオコンテンツは、ＩＰＴＶ端末１０の具備する上記メディア再生プレイヤーによって伸張され、描画されることで、ＩＰＴＶ端末１０の表示装置の画面に表示される。
【００３１】
本実施形態にかかるＩＭＳベースのＩＰＴＶシステムでは、ＩＰＴＶ端末１０は、ＩＭＳゲートウェイ５０を経由して、ＩＭＳネットワーク２０のＣＳＣＦ（Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）２２と通信することで、ビデオコンテンツを伝送するネットワークのＱｏＳ管理のためのセッションセットアップ、その他、チャットなどのコミュニケーションアプリケーションを実現できる。
【００３２】
例えば、図２の例では、“ＣＡＬＬＥＲ  ＩＤ”といわれる電話着信をテレビジョン画面に表示させるサービスの例を示している。この場合、電話着信のシグナルは、ＩＭＳネットワーク２０から、ＳＩＰによりＣＳＣＦ２２経由でＩＭＳゲートウェイ５０に通知され、さらに、ＨＴＴＰもしくはＴＣＰによってＨＴＭＬブラウザ１３に通知される必要がある。ＨＴＭＬブラウザ１３に通知された着信シグナルは、ＥＣＭＡ  ＳＣＲＩＰＴによって記述されたアプリケーションにて受信され、そのアプリケーションにて描画指示が行われる。この結果、図２の例のように、ＩＰＴＶ端末１０では、テレビジョン番組の映像７０上に、着信シグナルに記述された電話番号７２がオーバーレイして表示される。
【００３３】
本実施形態では、このようにＩＭＳゲートウェイ５０が、通信対象となる非同期型トランザクションネットワーク（例えばＩＭＳネットワーク２０）で用いられるＳＩＰ（第１のプロトコル）のデータを、同期型トランザクションネットワーク（例えばＩＰネットワーク）で用いられるＨＴＴＰ（第２のプロトコル）のデータに変換する方式に特徴を有する。即ち、本実施形態にかかるＩＭＳゲートウェイ５０は、例えば、ＳＩＰプロトコルのメッセージを、１対１マッピングにより直接的にＨＴＴＰプロトコルのメッセージに載せ換えるだけという、簡単な方式でプロトコル変換することを特徴としている。なお、本実施形態にかかるＩＰＴＶ端末１０は、同期型トランザクションネットワーク対応機器（ＨＴＴＰ通信に対応した機器）に相当し、ＩＭＳネットワーク２０に設置されたＣＳＣＦ２２を有する機器は、非同期型トランザクションネットワーク対応機器（ＳＩＰ通信に対応した機器）に相当する。
【００３４】
図３は、ＳＩＰとＨＴＴＰとの間のプロトコルの相違を示す説明図である。図３に示すように、ＳＩＰは、Ｐｅｅｒ２Ｐｅｅｒ（Ｐ２Ｐ）型の通信に用いられる。ＳＩＰ  ＵＡ５４（ＵＳＥＲ  ＡＧＥＮＴ）は、他者（他のＳＩＰ  ＵＡ５４もしくはＳＩＰプロクシー、例えばＣＳＣＦ２２）にリクエストメッセージを送信し、他者からのリクエストメッセージを受信する。
【００３５】
一方、ＨＴＴＰ（又はＴＣＰ）は、クライアント・サーバ型の通信に用いられる。ＨＴＴＰクライアント１４（例えば、ＤＡＥブラウザ１４ａ、ＯＩＴＦ  Ｅｍｂｅｄｄｅｄ  Ａｐｐｌｉｃａｔｉｏｎｓ１４ｂ等）は、リクエストメッセージの発信者を発信するのみであり、他者（例えば、ＨＴＴＰサーバ）からのリクエストメッセージを受信しない。
【００３６】
ＳＩＰとＨＴＴＰとは、送信したリクエストメッセージに対するレスポンスメッセージを受信することにより、１つのトランザクションがなされるという点では共通している。また、ＳＩＰでは、一連のトランザクションは、“ＤＩＡＬＯＧ”と称されるセッション管理がなされる。一方、ＨＴＴＰのトランザクションは独立しており、クライアント、サーバとも他のトランザクションの状態を保持しないステートレス通信をベースにしている。
【００３７】
例えば、図３の例を利用して、ＨＴＴＰとＳＩＰについてより詳細に説明する。ＨＴＴＰのトランザクションでは、ＩＰＴＶ端末１０（ＨＴＴＰクライアント）が“ＨＴＴＰ  ＧＥＴメソッド”のリクエストを送信する。すると、ＩＭＳゲートウェイ５０（ＨＴＴＰサーバ）は、当該ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、ステータスコード“２００  ＯＫ”と、ＨＴＴＰボディーに要求したリソース（例えば、ＨＴＭＬドキュメント）などを格納したレスポンスメッセージを返信する。これにより、１つのＨＴＴＰトランザクションが完了する。この場合、ＨＴＴＰリクエストは、ＨＴＴＰクライアントからＨＴＴＰサーバへ一方向であり、ＨＴＴＰサーバからＨＴＴＰクライアントにＨＴＴＰリクエストが送信されることはない。また、その次の“ＨＴＴＰ  ＧＥＴ”のＨＴＴＰリクエストと“２００  ＯＫ”のＨＴＴＰレスポンスのトランザクションは、基本的には前回のトランザクションとは独立している。
【００３８】
一方、ＳＩＰでは、例えば、ＩＭＳゲートウェイ５０のＳＩＰ  ＵＡ５４は、ＳＩＰリクエスト（Ｓｕｂｓｃｒｉｂｅ）をＣＳＣＦ２２経由でＡＳ２６に送信し、このＳＩＰリクエストに対するレスポンスとして、ＡＳ２６からＳＩＰレスポンス（２００  ＯＫ）を受信する。このとき、ＳＩＰ  ＵＡ５４は、ＳＩＰリクエストのヘッダーで、“ＣＡＬＬ  ＩＤ”（図３では「ｃｉｄ」と表記する。）と称される任意の値（ｃｉｄ＝１）を指定しておく。ＡＳ２６は、先のＳＩＰリクエスト（Ｓｕｂｓｃｒｉｂｅ）を受けて、ＳＩＰリクエスト（Ｎｏｔｉｆｙ）をＣＳＣＦ２２経由でＳＩＰ  ＵＡ５４に送信する。すると、ＳＩＰ  ＵＡ５４は、当該ＳＩＰリクエスト（Ｎｏｔｉｆｙ）に対してＳＩＰレスポンス（２００  ＯＫ）をＣＳＣＦ２２経由でＡＳ２６に返信する。この場合、上記ＳＩＰリクエスト（Ｎｏｔｉｆｙ）が先のＳＩＰリクエスト（Ｓｕｂｓｃｒｉｂｅ）と一連のＤＩＡＬＯＧであることを示すために、ＡＳ２６は先にＳＩＰ  ＵＡ５４から指定されたＣＡＬＬ  ＩＤと同じ値（ｃｉｄ＝１）をＳＩＰリクエスト（ｎｏｔｉｆｙ）のヘッダーで指定しておく。
【００３９】
このように、ＳＩＰでは、ＩＭＳゲートウェイ５０のＳＩＰ  ＵＡ５４は、リクエストメッセージを発行する場合と、リクエストメッセージを受信する場合とがある。また、各セッションを識別するための情報である“ＣＡＬＬ  ＩＤ”によってセッション管理が行われており、ＣＡＬＬ  ＩＤが異なる場合は、異なるセッション（ＤＩＡＬＯＧ）である。
【００４０】
本実施形態にかかるＩＰＴＶシステムの通信方法は、例えば、ＣＥＡ−２０１４で定義されたＮｏｔｉｆｉｃａｔｉｏｎ方法を利用して、ＨＴＴＰ通信に対応したＩＰＴＶ端末１０と、ＳＩＰに対応した機器とが、ＩＭＳゲートウェイ５０を介して通信することを特徴としている。具体的には、かかる通信方法としては、例えば以下の実装例（１）〜（４）が挙げられる。
【００４１】
（１）ＸＭＬＨＴＴＰＲｅｑｕｅｓｔのみを利用する方法
（２）ＸＭＬＨＴＴＰＲｅｑｕｅｓｔとＮｏｔｉｆＳｏｃｋｅｔを併用する方法
（３）ＸＭＬＨＴＴＰＲｅｕｑｅｓｔと「３ｒｄ  ｐａｒｔｙ  ｍｕｌｔｉｃａｓｔ  ｎｏｔｉｆｉｃａｔｉｏｎ（拡張）」を併用する方法
（４）ＮｏｔｉｆＳｏｃｅｋｔのみを利用する方法
【００４２】
（１）ＸＭＬＨＴＴＰＲｅｑｕｅｓｔのみを利用する方法
ＸＭＬＨＴＴＰＲｅｑｕｅｓｔ（以下「ＸＨＲ」という。）は、ウェブブラウザ搭載のスクリプト言語（ＪａｖａＳｃｒｉｐｔ（登録商標）など）を利用して、サーバとＨＴＴＰ通信を行うために用いられる。このＸＨＲは、ＨＴＭＬブラウザ１３のＥＣＭＡ  ＳＣＲＩＰＴからＨＴＴＰトランザクションを呼び出す仕組みであり、ＣＥＡ−２０１４対応のＨＴＭＬブラウザ１３にて、Ｉｎ  Ｓｅｓｓｉｏｎ  Ｎｏｔｉｆｉｃａｔｉｏｎの仕組みとして利用できる。かかるＸＨＲのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）は、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）標準規格（http://www.w3.org/TR/XMLHttpRequest/）に準じている。ただし、実際の通信プロトコルはＲＦＣ−２６１６規定のＨＴＴＰであるので、この方法（１）はＨＴＴＰとＳＩＰとの間でプロトコル変換する方法である。だだし、この方法（１）では、ＩＭＳゲートウェイ５０の変換機能は、ＳＩＰメッセージ自体の解釈を行わず、ＳＩＰメッセージをＨＴＴＰメッセージに双方向で載せ換えるという簡単な処理を行うだけである。
【００４３】
ただし、上述したように、ＳＩＰはＰ２Ｐ型の通信トランザクションに対応しているのに対し、ＨＴＴＰはクライアント・サーバ型の通信トランザクションに対応している。このため、ＩＰＴＶ端末１０のＨＴＴＰクライアント１４と、ＩＭＳゲートウェイ５０のＨＴＴＰサーバ５４は、図４に示すようにして、リクエストメッセージとレスポンスメッセージを相互に通知する。
【００４４】
また、ＩＰＴＶ端末１０のＨＴＭＬブラウザ１３で実行されるＥＣＭＡ  ＳＣＲＩＰＴは、図５のフローに従って通信を行う。なお、ＩＰＴＶ端末１０のＥｍｂｅｄｄｅｄ  ＡｐｐｌｉｃａｔｉｏｎがＨＴＴＰクライアント１４を利用する場合でも、図５と同様のフローとなる。また、ＩＭＳゲートウェイ５０のＨＴＴＰサーバ５４は、図６のフローに従って通信を行う。
【００４５】
ＨＴＴＰリクエストは、ＥＣＭＡ  ＳＣＲＩＰＴがＸＨＲのＳｅｎｄのＡＰＩをコールすることによって発行されるが、ＳｅｎｄのＡＰＩの入力パラメータには何も指定しない（図ではｎｕｌｌと表記）か、或いは、ＳＩＰメッセージを入力パラメータとしていれる。このときのＨＴＴＰリクエストではＩＭＳゲートウェイ５０が提供するＵＲＬを指定する。例えば、ＩＰＴＶ端末１０は、ＩＭＳゲートウェイ５０からＵＰＮＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ＆Ｐｌａｙ）規格のデバイスディスカバリーによって得られたデバイスディスクリプションから、イベント取得のＵＲＬを知ることができる。
【００４６】
ここで、図５に示すＩＰＴＶ端末１０のＨＴＭＬブラウザ１３のＥＣＭＡ  ＳＣＲＩＰＴの処理フローについて、図４を適宜参照しながら説明する。
【００４７】
図５に示すように、まず、ＩＰＴＶ端末１０のＨＴＭＬブラウザ１３は、ＥＣＭＡ  ＳＣＲＩＰＴにより、ＸＨＲのＳｅｎｄ（ｎｕｌｌ）をＨＴＴＰクライアント１４に送信すると（Ｓ１１）、ＨＴＴＰクライアント１４は、ＩＭＳゲートウェイ５０のＨＴＴサーバ５４にＨＴＴＰリクエストメッセージを送信する（図４のＨＴＴＰ  Ｒｅｑｕｅｓｔ１、３、４、５）。これにより、ＩＰＴＶ端末１０からＩＭＳゲートウェイ５０にセッション開始を通知できる。
【００４８】
次いで、ＨＴＭＬブラウザ１３は、ＨＴＴＰクライアント１４からＸＨＲのｒｅｓｐｏｎｓｅＸＭＬを受信したか否か、つまり、ＩＰＴＶ端末１０がＨＴＴサーバ５４からＨＴＴＰレスポンスメッセージを受信したか否かを判定する（Ｓ１２）。
【００４９】
この結果、ＸＨＲのｒｅｓｐｏｎｓｅＸＭＬを受信していない場合、ＨＴＭＬブラウザ１３は、ＩＭＳネットワーク２０にＳＩＰ送信するリクエストメッセージ（ＳＩＰリクエストメッセージ）があるか否かを判定する（Ｓ１３）。ＳＩＰリクエストメッセージがある場合、ＨＴＭＬブラウザ１３は、ＸＨＲのＳｅｎｄ（ＳＩＰ  ｒｅｑ）をＨＴＴＰクライアント１４に送信し（Ｓ１４）、Ｓ１２に戻る。この結果、ＨＴＴＰクライアント１４は、ＩＭＳゲートウェイ５０のＨＴＴサーバ５４にＨＴＴＰリクエストメッセージを送信する（図４のＨＴＴＰ  Ｒｅｑｕｅｓｔ２、６）。ＨＴＴＰクライアント１４はＣＳＣＦ２２に対して所定のデータの送信を要求した後に、一方、ＳＩＰへのリクエストメッセージがない場合、ＨＴＭＬブラウザ１３は、ＸＨＲのＳｅｎｄ（ＳＩＰ  ｒｅｑ）をＨＴＴＰクライアント１４に送信することなく、Ｓ１２に戻る。
【００５０】
一方、Ｓ１２にて、ＸＨＲのｒｅｓｐｏｎｓｅＸＭＬを受信した場合、ＨＴＭＬブラウザ１３は、受信したｒｅｓｐｏｎｓｅＸＭＬがＮｕｌｌであるか否か、つまり、当該ｒｅｓｐｏｎｓｅＸＭＬにＳＩＰレスポンスメッセージが含まれているか否かを判定する（Ｓ１５）。
【００５１】
この結果、受信したｒｅｓｐｏｎｓｅＸＭＬがＮｕｌｌでなく、ＳＩＰレスポンスメッセージが含まれている場合（図４のＨＴＴＰ  Ｒｅｓｐｏｎｓｅ３、４の場合）、ＨＴＭＬブラウザ１３は、当該ＳＩＰレスポンスメッセージに関する処理を実行した後に（Ｓ１６）、Ｓ１１に戻り、再びＸＨＲのＳｅｎｄ（ｎｕｌｌ）をＨＴＴＰクライアント１４に送信する。一方、Ｓ１５にて、受信したｒｅｓｐｏｎｓｅＸＭＬがＮｕｌｌである場合（図４のＨＴＴＰ  Ｒｅｓｐｏｎｓｅ１、２、５、６の場合）、ＨＴＭＬブラウザ１３は、何ら処理することなく、Ｓ１１に戻り、再びＸＨＲのＳｅｎｄ（ｎｕｌｌ）をＨＴＴＰクライアント１４に送信する。
【００５２】
次に、図６に示すＩＭＳゲートウェイ５０のＨＴＴＰサーバ５４の処理フローについて、図４を適宜参照しながら説明する。
【００５３】
図６に示すように、まず、ＩＭＳゲートウェイ５０のＨＴＴＰサーバ５４は、ＩＭＳゲートウェイ５０に設けられたインターバルタイマー（図示せず。）をリセットして、計時を開始する（Ｓ２１）。
【００５４】
その後、ＨＴＴＰサーバ５４は、ＩＰＴＶ端末１０のＨＴＴＰクライアント１４から、ＨＴＴＰリクエストメッセージを受信したか否かを判定する（Ｓ２２）。さらに、ＨＴＴＰリクエストメッセージを受信した場合、ＨＴＴＰサーバ５４は、受信したＨＴＴＰリクエストメッセージのＨＴＴＰボディーがＮｕｌｌか否かを判定する（Ｓ２３）。
【００５５】
この判定の結果、Ｓ２２で受信したＨＴＴＰリクエストのＨＴＴＰボディーがＮｕｌｌである場合（図４のＨＴＴＰ  Ｒｅｑｕｅｓｔ１、３、４、５の場合）、Ｓ２９に進む。Ｓ２９では、ＨＴＴＰサーバ５４は、当該ＨＴＴＰリクエストを、ＩＭＳゲートウェイ５０に設けられたメモリーなどの保持手段に保持する（Ｓ２９）。詳細にはこのＳ２９では、ＨＴＴＰサーバ５４は、ＩＭＳネットワーク２０からのイベントをＩＰＴＶ端末１０に通知するために、Ｓ２２で受信したＨＴＴＰリクエストメッセージを、メモリー等の保持手段に保存されているイベント待ち行列に、受信順に保存する。
【００５６】
一方、Ｓ２３の判定の結果、Ｓ２２で受信したＨＴＴＰリクエストのＨＴＴＰボディーがＮｕｌｌでなく、ＳＩＰリクエストメッセージが含まれている場合（図４のＨＴＴＰ  Ｒｅｑｕｅｓｔ２、６の場合）、Ｓ２４に進む。Ｓ２４では、ＨＴＴＰサーバ５４は、既に上記Ｓ２９にて待ち行列として保持されているＨＴＴＰリクエストメッセージに対するレスポンスとして、２００  ＯＫでＨＴＴＰボディーをＮｕｌｌにしたＨＴＴＰレスポンスメッセージを、ＨＴＴＰクライアント１４に返信する（図４のＨＴＴＰ  Ｒｅｓｐｏｎｓｅ２、６）。これにより、ＨＴＴＰクライアント１４からＨＴＭＬブラウザ１３にＸＨＲのｒｅｓｐｏｎｓｅＸＭＬ（Ｎｕｌｌ）が送信される。
【００５７】
次いで、Ｓ２５では、ＨＴＴＰサーバ５４は、Ｓ２２で受信したＨＴＴＰリクエストメッセージをＳＩＰメッセージに格納して、ＳＩＰ  ＵＡ５２から、ＩＭＳネットワーク２０のＣＳＣＦ２２に送信する（Ｓ２５）。さらに、ＨＴＴＰサーバ５４は、Ｓ２２で受信したＨＴＴＰリクエストメッセージに対するレスポンスとして、ＨＴＴＰボディーに２００  ＯＫを格納したＨＴＴＰレスポンスメッセージを、ＨＴＴＰクライアント１４に返信する（図４のＨＴＴＰ  Ｒｅｓｐｏｎｓｅ３）。
【００５８】
一方、上記Ｓ２２にて、ＨＴＴＰクライアント１４からＨＴＴＰリクエストメッセージを受信していないと判定された場合、Ｓ２７に進む。Ｓ２７では、ＨＴＴＰサーバ５４は、ＳＩＰ  ＵＡ５２がＣＳＣＦ２２からＳＩＰメッセージを受信したか否かを判定する（Ｓ２７）。ＳＩＰメッセージを受信した場合、ＨＴＴＰサーバ５４は、既に上記Ｓ２９にて待ち行列として保持されているＨＴＴＰリクエストメッセージに対するレスポンスとして、ＨＴＴＰボディーにＳＩＰメッセージを格納したＨＴＴＰレスポンスメッセージを、ＨＴＴＰクライアント１４に返信する（図４のＨＴＴＰ  Ｒｅｓｐｏｎｓｅ４）。これにより、ＨＴＴＰクライアント１４からＨＴＭＬブラウザ１３にＸＨＲのｒｅｓｐｏｎｓｅＸＭＬ（ＳＩＰ  ｒｅｓ）が送信される。なお、上記Ｓ２６、Ｓ２９及びＳ２８の処理後は、Ｓ２２に戻る。
【００５９】
一方、Ｓ２７の判定の結果、ＳＩＰメッセージを受信していない場合、Ｓ３０に進む。Ｓ３０では、ＨＴＴＰサーバ５４は、上記インターバルタイマーで計測した時間が所定の時間（例えば６０秒）を経過したか否かを判定する（Ｓ２７）。この結果、経過していない場合はＳ２２に戻り、経過している場合はＳ３１に進む。
【００６０】
Ｓ３１では、ＨＴＴＰサーバ５４は、既に上記Ｓ２９にて待ち行列として保持されているＨＴＴＰリクエストメッセージに対するレスポンスとして、ＨＴＴＰボディーにＮｕｌｌを格納したＨＴＴＰレスポンスメッセージを、ＨＴＴＰクライアント１４に返信する（図４のＨＴＴＰ  Ｒｅｓｐｏｎｓｅ１、５）。その後、Ｓ２１に戻り、ＨＴＴＰサーバ５４は、再びインターバルタイマーをリセット（Ｓ２１）して、上記と同様な処理Ｓ２２〜Ｓ３１を繰り返す。
【００６１】
（第２の実施形態）
（２）ＸＭＬＨＴＴＰＲｅｑｕｅｓｔとＮｏｔｉｆＳｏｃｋｅｔを併用する方法
図７に示すように、この方法（２）では、ＩＰＴＶ端末１０にＮｏｔｉｆＳｏｃｋｅｔ１８を設ける。そして、ＩＰＴＶ端末１０のＨＴＭＬブラウザ１３のＥＣＭＡ  ＳＣＲＩＰＴからＳＩＰメッセージを送信する場合は、ＸＨＲ（リクエスト＆レスポンス）を利用し、ＩＭＳゲートウェイ５０からのＳＩＰメッセージを受信する場合は、ＮｏｔｉｆＳｏｃｋｅｔ１８を利用する。ＮｏｔｉｆＳｏｃｋｅｔ１８は、ＴＣＰ  Ｃｏｎｎｅｃｔｉｏｎであるので、ＣＳＣＦ２２から送信されたＳＩＰメッセージをそのままの形式で、ＩＭＳゲートウェイ５０からＩＰＴＶ端末１０のブラウザ１３のＥＣＭＡ  ＳＣＲＩＰＴに通知することができる。
【００６２】
（第３の実施形態）
（３）ＸＭＬＨＴＴＰＲｅｕｑｅｓｔと「３ｒｄ  ｐａｒｔｙ  ｍｕｌｔｉｃａｓｔ  ｎｏｔｉｆｉｃａｔｉｏｎ（拡張）」を併用する方法
図８に示すように、この方法（３）では、ＩＰＴＶ端末１０に「３ｒｄ  ｐａｒｔ  ｎｏｔｉｆｉｃａｔｉｏｎ  Ｈａｎｄｅｒ  ｍｕｌｔｉｃａｓｔ  １９」を設ける。ＣＥＡ−２０１４では「３ｒｄ  ｐａｒｔｙ  ｍｕｌｔｉｃａｓｔ  ｎｏｔｉｆｉｃａｔｉｏｎ」の方式が定義されており、ｍｕｌｔｉｃａｓｔにてイベントをブラウザに通知する仕組みがある。しかしながら、ＣＥＡ−２０１４規定ではＵＲＬを通知することになるので、ＳＩＰメッセージをそのままマルチキャストで通知する場合には使用できない。そこで、ＣＥＡ−２０１４のｍｕｌｔｉｃａｓｔ  ｎｏｔｉｆｉｃａｔｉｏｎを拡張し、マルチキャストＵＤＰパケットにＳＩＰリクエストメッセージを格納することで実現できる。
【００６３】
（第４の実施形態）
（４）ＮｏｔｉｆＳｏｃｅｋｔを利用する方法
図９に示すように、この方法（４）では、ＩＰＴＶ端末１０にＮｏｔｉｆＳｏｃｋｅｔ１８を設け、ＩＭＳゲートウェイ５０に、上記ＨＴＴＰサーバ５４に代えて、ＳＩＰのＢ２ＢＵＡ（Ｂａｃｋ  Ｔｏ  Ｂａｃｋ  Ｕｓｅｒ  Ａｇｅｎｔ）５６を設ける。ＣＥＡ−２０１４のＩｎ  ｓｅｓｓｉｏｎ  Ｎｏｔｉｆｉｃａｔｉｏｎの方式であるＮｏｔｉｆＳｏｃｋｅｔ１８は、ＴＣＰ通信をＥＣＭＡ  ＳＣＲＩＰＴから行うことができるＡＰＩである。このため、ＩＰＴＶ端末１０とＩＭＳゲートウェイ５０との間では、ＳＩＰメッセージをそのままＮｏｔｉｆＳｏｃｋｅｔに載せることができる。この場合は、ＩＭＳゲートウェイ５０には、上記ＨＴＴＰサーバ５４が不要であり、ＳＩＰのＢ２ＢＵＡ５６が実装されることになる。
【００６４】
以上、本実施形態にかかるＩＰＴＶシステムにおけるＩＭＳゲートウェイ５０の構成と、これを用いた通信方法について説明した。上述したように、ＨＴＴＰとＳＩＰとの間でプロトコル変換するＩＭＳゲートウェイ５０において、ＳＩＰプロトコルをより抽象度の高いハイレベルなインターフェースに変換するアプリケーションは、ＣＰＵ、メモリーなどのハードウェア資源を多く必要とするため、ＩＭＳゲートウェイ機器が高価なってしまうという問題があった。
【００６５】
これに対し、本実施形態にかかるＩＭＳゲートウェイ５０では、ＳＩＰメッセージをそのままＨＴＴＰプロトコルに載せ換える簡易な変換方式である。従って、上記ＣＰＵ、メモリーなどのハードウェア資源の実装スペックを抑えることができ、ＩＭＳゲートウェイ５０を安価に構築できる。また、ＩＰＴＶ端末１０のアプリケーションもＳＩＰをより直接的に利用できるため、高度なアプリケーションを作成することが可能となる。
【００６６】
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【００６７】
【図１】一般的なＩＭＳを利用したＩＰＴＶシステムの構成を示す概略構成図である。
【図２】本発明の第１の実施形態にかかるＩＭＳを利用したＩＰＴＶシステムの構成を示す概略構成図である。
【図３】同実施形態にかかるＳＩＰとＨＴＴＰとの間のプロトコルの相違を示す説明図である。
【図４】同実施形態にかかる通信方法を示すシーケンス図である。
【図５】同実施形態にかかるＩＰＴＶ端末のブラウザの処理を示すフローチャートである。
【図６】同実施形態にかかるＩＭＳゲートウェイのＨＴＴＰサーバの処理を示すフローチャートである。
【図７】本発明の第２の実施形態にかかる通信方法を示すシーケンス図である。
【図８】本発明の第３の実施形態にかかる通信方法を示すシーケンス図である。
【図９】本発明の第４の実施形態にかかる通信方法を示すシーケンス図である。
【符号の説明】
【００６８】
１０    ＩＰＴＶ端末
１３    ＨＴＭＬブラウザ
１４    ＨＴＴＰクライアント
１８    ＮｏｔｉｆＳｏｃｋｅｔ
２０    ＩＭＳネットワーク
２２    ＣＳＴＦ
２６    ＡＳ（アプリケーションサーバ）
３０    ＩＰＴＶサービス提供システム
３２    ＥＰＧサーバ
３４    ビデオサーバ
５０    ＩＭＳゲートウェイ装置
５２    ＳＩＰ  ＵＡ
５４    ＨＴＴＰサーバ
【図１】
0004623118.tif 000002
【図２】
0004623118.tif 000003
【図３】
0004623118.tif 000004
【図４】
0004623118.tif 000005
【図５】
0004623118.tif 000006
【図６】
0004623118.tif 000007
【図７】
0004623118.tif 000008
【図８】
0004623118.tif 000009
【図９】
0004623118.tif 000010