ＨｉＧＡのＩＭＳサービスプロキシ
本発明は、端末デバイスが第１のタイプか第２のタイプか（ＩＭＳベースか非ＩＭＳベースか）にかわわらず、通信サーバ（ＩＭＳ−Ｓ）が提供する第１のタイプのサービスをホームネットワーク（ＣＰＮ）の端末デバイス（Ｔ１、Ｔ２、…Ｔｎ…ＴＮ）に提供することを可能にする通信システム（ＳＹＳ）、ゲートウェイ装置（ＨｉＧＡ）、および方法に関する。ゲートウェイ装置（ＨｉＧＡ）は、第２のタイプの端末デバイス（Ｔ２）間で使用される制御プレーン（ＳＩＰ）をゲートウェイ装置（ＨｉＧＡ）と通信サーバ（ＩＭＳ−Ｓ）との間で使用される制御プレーン（ＨＴＴＰ）に適応させる１つ以上のサービス固有マッピングアプリケーション（ＡＳ）を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末デバイスが通信システムのサービス提供サーバの提供するサービスにアクセスし使用することを可能にする通信システム、通信方法およびゲートウェイ装置に関する。
【０００２】
特に本発明は、標準端末デバイスが解決できないアプリケーション固有の属性を有するサービスを、サービス提供サーバが提供する状況に関する。すなわち本発明は、サービス提供サーバが第１のタイプで、通信システムが第１のタイプの端末デバイスと第２のタイプの端末デバイスを備えてもよい状況に関する。第１のタイプの端末デバイスは、第１のタイプのサービス提供サーバが提供するサービスに関係する制御データを理解し解決する。しかし、第１のタイプのサービス提供サーバが提供するアプリケーション固有の属性（サービス固有特性）を有するサービスに関係する第１のタイプの制御データを理解し解決することができない、第２のタイプの端末デバイスもある。
【背景技術】
【０００３】
図１ａは、背景技術および本発明が解決すべき問題を説明するための通信システムＳＹＳ示す。図１ａでは、ホームネットワーク（宅内ネットワーク、Customer Premises Network）ＣＰＮは、相当数の端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮを備える。ホームネットワークＣＰＮは、図１ａでＩＭＳ−Ｎで示すサービスネットワークに接続されていてもよい。ホームネットワークＣＰＮまたは接続されたサービスネットワークＩＭＳ−Ｎには、端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮに例えばＩＭＳタイプの通信サービスではＶｏＩＰ、テレビ会議およびＩＰＴＶなどの特定のサービスを提供するサービス提供サーバＩＭＳ−Ｓが用意されている。
【０００４】
アクセス手順および配信手順は、図１ａではＨｉＧＡで示すゲートウェイ装置が提供する。端末デバイス例えばＴ１からゲートウェイ装置ＨｉＧＡへのアクセスメッセージＡＣに応えて、サービス提供サーバＩＭＳ−Ｓは、ゲートウェイ装置ＨｉＧＡが転送する配信メッセージＤＬを用いて要求されたサービスを配信する。普通、サービス提供サーバＩＭＳ−Ｓと端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮが同じ「タイプ」である場合、たとえサービスがサービスに関係するアプリケーション固有の属性も有していても、サービス提供サーバＩＭＳ−Ｓのサービスへのアクセスおよびその提供（配信）に問題はない。しかし、サービス提供サーバＩＭＳ−Ｓが第１のタイプであり、端末デバイスがサービスに関係する固有の第１のタイプの制御データ（アプリケーション固有の属性）を理解できない第２のタイプである場合、サービス提供サーバＩＭＳ−Ｓが提供するサービスだけは、第２のタイプの端末デバイスに配信されることがあるが、サービスに関係する第１のタイプの制御データは、第２のタイプの端末デバイスで復号され使用される可能性はない。以下ではこの様子をさらに説明するために、ＩＭＳサービスに関連し、図１ｂ、１ｃにも関連するより具体的な例について説明する。
【０００５】
図１a、１ｂ、１ｃの例では、ゲートウェイ装置はＨｉＧＡ（ホームＩＭＳゲートウェイ、Home IMS GAteway）で形成され、端末デバイスＴ１（第１のタイプの端末デバイス）はＳＩＰデバイス（ＳＩＰ：セッション開始プロトコル、Session Initiation Protocol）であり、端末デバイスＴ２（第２のタイプの端末デバイス）は非ＳＩＰデバイスである。前に説明したように、ＨｉＧＡは、ホームネットワークＣＰＮ内に在る機能ブロック（ゲートウェイ）であり、例えば、ＳＩＰ端末デバイスおよび非ＳＩＰ端末デバイスが、サービス提供サーバＩＭＳ−Ｓの提供するＩＭＳベースのサービスにアクセスすることを可能にする。ＩＭＳベースのサービスには、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）およびテレビ会議などの通信サービス、ならびに図１ａにやはり示すＩＰＴＶなどの他のマルチメディアサービスを含んでもよい。
【０００６】
ＩＭＳサービスとして提供される例えばＩＰＴＶの特徴の１つは、エンドユーザに配信されるＴＶコンテンツのパーソナル化、例えばユーザのアイデンティティおよび好みに基づきパーソナル化された広告の配信などを可能にすることである。このために、ＨｉＧＡは、図１ｂに示すユーザプロファイルメモリＵＰ−ＭＥＭにユーザプロファイルを保有する。このようなユーザプロファイルは、例えば図１ｃに示すゲートウェイデバイスＨｉＧＡの交換部分ＥＸに格納されてもよい。ユーザプロファイルは、ＩＭＳサービスアイデンティティに関連するあらゆる登録に対して保有される。例えば、図１ｂに示すように各ユーザ・アイデンティティ（ユーザＩＤ）は、特定の好み（制御情報）およびサービス識別表示ＩＭＳ−ＩＤに関連付けられている。例えば、各個別のユーザにユーザのＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）で異なるＴＶプログラムが入手可能であってもよく、図１ｂに示すように、ＩＤ１＝「父親」／制御情報＝「スポーツ」、ＩＤ２＝「息子」／制御情報＝「映画および子供番組」、およびＩＤｎ＝「母親」／制御情報＝「広告」などが入手可能であってもよい。このような特定の好み（制御情報）が示される場合、ＨｉＧＡは、制御情報を用いてパーソナル化されたやり方で要求されたサービスがユーザ（端末デバイス）に確実に配信されるようにする。
【０００７】
例えば、第１のタイプの端末デバイスＴ１がユーザＩＤ＝ＩＤ２を有するサービス配信要求を送信する場合、ＨｉＧＡは、サービス提供サーバＩＭＳ−Ｓからパーソナル化された電子プログラム・ガイドＥＰＧ２を読み出すべきことを知り、サーバＩＭＳ−ＳにＥＰＧ２の要求を送信する。あるいは、サーバＩＭＳ−Ｓが、図１ｃに示すようにユーザ・アイデンティティＩＤと制御情報ＩＭＳ−ＣＴＲＬとをマッピングするユーザ固有の好みマッピングテーブルを有する場合、第１のタイプの端末デバイスＴ１は、ＨｉＧＡを通してサーバＩＭＳ−ＳにそのユーザＩＤであるＩＤ１（第１のテープの制御情報）を単に送信すれば十分であってもよく、サーバＩＭＳ−Ｓは、提供された第１のタイプ（パーソナル化された、すなわちユーザおよびサービス固有）の制御情報ＥＰＧ１を復号し使用する能力がある第１のタイプの端末デバイスＴ１に、第１のタイプの制御情報（制御データ）を返す。端末デバイスとサーバが同じ（第１のタイプの）制御プロトコルを実行するならば、このやり方で、パーソナル化されたコンテンツは特定の登録、それ故特定のユーザに配信され得る。通常、ＩＭＳサーバＩＭＳ−Ｓを有する通信システムでは、端末デバイスＴ１もサーバＩＭＳ−Ｓも、同じＳＩＰ制御プロトコルを実行し、それ故このプロトコルを使用して互いに「話す」ことができる。
【０００８】
ＨｉＧＡがＳＩＰと非ＳＩＰ（例えば、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ））の両方のホームデバイスにＩＭＳ通信サービスを提供するＩＭＳ−ＳＩＰプロキシ（交換）機能を本質的に提供するのに対して、ＩＭＳシステムすなわちホームネットワークＣＰＮまたは相互接続されたサービスネットワークＩＭＳ−ＮのアプリケーションサーバＩＭＳ−Ｓは、図１ａに示すようにＩＰＴＶ、ＶｏＩＰ、テレビ会議等を含む多数のマルチメディアサービスを提供し、通常このようなＩＭＳサービスは、図１ａに示唆するように異なる第２の制御プロトコルを実行する標準端末デバイスＴ２が使用および理解することのできないアプリケーション（サービス）固有の属性（制御情報）を有することができよう。例えばＩＰＴＶサービスは、ＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）およびサービストリガなどのアプリケーション固有の属性を有してもよい。ＶｏＩＰサービスは、特定の広告または音楽に関して特定の属性を有してもよい。終端デバイスもＩＭＳベースの端末デバイスである場合、もちろん（第１のタイプのＳＩＰ）端末デバイスＴ１にこのサービスに関係するアプリケーション（サービス）固有の属性を配信することに問題はない。しかし、端末デバイスが異なるタイプ（第２のタイプ）すなわち非ＩＭＳベースである場合は問題がある。この場合、このＩＭＳベースのサービスに関係するアプリケーション固有の属性（制御情報）を、非ＩＭＳベースの第２のタイプの端末デバイスＴ２の制御プロトコルが「理解」できないからである。この問題は、サーバＩＭＳ−Ｓからのパーソナル化されたコンテンツのより高度な提供に関連するだけでなく、簡単な要求シナリオにさえ関連する。
【０００９】
例えば第１の端末デバイスＴ１は、サービス・プロセッサＳＰ（ＭＰＥＧ２デコーダ）を用いて、配信されたＭＰＥＧ２ストリームを復号する能力があってもよい。しかし第１の端末デバイスＴ１は、このＭＰＥＧ２サービスをサーバＩＭＳ−Ｓに要求するためにＨＴＴＰ（第１のタイプ）の制御プロトコルを使用してもよい。サーバＩＭＳ−Ｓが第２の制御プロトコル例えばＳＩＰを実行する場合、ＩＭＳ ＳＩＰをサポートしていない第１の端末デバイスは、ＨＴＴＰ要求を使用してサーバＩＭＳ−Ｓのメディアにアクセスすることはできない。別の例は、第１の端末デバイスＴ１がアクセス・ネットワークのある帯域幅（あるリソース）を必要とするサービス、例えばビデオストリーミングを要求する場合に、アクセス・ネットワークが必要なリソースを提供できない場合である。第１の制御プロトコルと第２の制御プロトコルは異なるので、端末デバイスは、例えば、ある程度狭い帯域幅でも例えばより低い品質のビデオストリーミングには許容し得ることを、サーバＩＭＳ−Ｓとネゴシエートするなどの能力がないだろう。
【００１０】
例えば簡単な標準セット・トップ・ボックスＳＴＢなどの多くの市販の端末デバイスＴ２は、デバイスに固有のユーザＩＤを割り当てられておらず、簡単な要求メッセージを実行しており、復号またはサービスの実行だけができるが、ユーザ固有の特性を少しも提供できない。すなわち、それらは、「ユーザを認識できず」、ユーザに無関係なやり方でサービスを単に実行する。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
これまで説明したように、サーバＩＭＳの制御プロトコルと第２のタイプの端末デバイスＴ２の制御プロトコルとは異なるので、第２のタイプの端末デバイスＴ２の中には、提供されるサービスに関係する第１のタイプの制御情報（制御データ）をサーバＩＭＳ−Ｓと交換できないものがあるという問題がある。
【００１２】
それ故、本発明の目的は、第１のタイプのサービス提供サーバが提供する第１のタイプの制御情報に関係して、第２のタイプの制御プロトコルを実行する第２のタイプの端末デバイスが、サービスを実行することを可能にする通信システム、通信方法およびゲートウェイ装置を提供することである。
【課題を解決するための手段】
【００１３】
本目的は、ゲートウェイ装置と、複数の端末デバイスと、これらの端末デバイスにアクセス・ネットワークを通してサービスを提供するサービス提供サーバとを備える通信システムによって解決され、前述のサービス提供サーバは、前述の端末デバイスに提供する１つ以上のサービスを格納するサービスメモリと、前述の１つ以上のサービスに関係する第１のタイプの制御データを前述のゲートウェイデバイスに提供する少なくとも１つの第１のタイプの制御プロトコル・デバイスとを備え、前述の端末デバイスのそれぞれは、前述のサービス提供サーバから前述のアクセス・ネットワークを通して提供されたサービスを処理するサービス・プロセッサと、前述のサービス・プロセッサによるサービスの実行に関係して、前述の第１のタイプとは異なる第２のタイプの制御データを前述のゲートウェイデバイスに提供する第２のタイプの制御プロトコル・デバイスとを備え、前述のゲートウェイ装置は、第１のタイプの制御データを前述のサービス提供サーバと交換し、第２のタイプの制御データを前述の端末デバイスと交換する１つ以上のサービス固有マッピング・デバイスを備え、前述のサービス固有マッピング・デバイスは、前述の端末デバイスから受信した第２のタイプの制御データに基づいて、第１のタイプの制御データを前述のサービス提供サーバに提供し、サービス提供サーバの前述の第１のタイプの制御プロトコル・デバイスから第１のタイプの制御データを受信し、前述のサービス固有マッピング・デバイスは、前述のサービス提供サーバから受信した前述の第１のタイプの制御データに基づいて、第２のタイプの制御データを前述の端末デバイスに提供し、前述の端末デバイスの前述の第２のタイプの制御プロトコル・デバイスから前述の第２のタイプの制御データを受信する。
【００１４】
さらに本目的は、複数の端末デバイスと、これらの端末デバイスにアクセス・ネットワークを通してサービスを提供するサービス提供サーバとを有する通信システムのゲートウェイ装置によって解決され、前述のサービス提供サーバは、前述の端末デバイスに提供する１つ以上のサービスを格納するサービスメモリと、前述の１つ以上のサービスに関係する第１のタイプの制御データを前述のゲートウェイデバイスに提供する少なくとも１つの第１のタイプの制御プロトコル・デバイスとを備え、前述の端末デバイスのそれぞれは、前述のサービス提供サーバから前述のアクセス・ネットワークを通して提供されたサービスを処理するサービス・プロセッサと、前述のサービス・プロセッサによるサービスの実行に関係して、第１のタイプの制御データを前述のサービス提供サーバと交換し、第２のタイプの制御データを前述の第２のタイプの端末デバイスと交換する１つ以上のサービス固有マッピング・デバイスを備える前述のゲートウェイデバイスに、前述の第１のタイプとは異なる第２のタイプの制御データを提供する第２のタイプの制御プロトコル・デバイスとを備え、前述のサービス固有マッピング・デバイスは、前述の端末デバイスから受信した第２のタイプの制御データに基づいて、第１のタイプの制御データを前述のサービス提供サーバに提供し、サービス提供サーバの前述の第１のタイプの制御プロトコル・デバイスから第１のタイプの制御データを受信し、前述のサービス固有マッピング・デバイスは、前述のサービス提供サーバから受信した前述の第１のタイプの制御データに基づいて、第２のタイプの制御データを前述の端末デバイスに提供し、前述の端末デバイスの前述の第２のタイプの制御プロトコル・デバイスから前述の第２のタイプの制御データを受信する。
【００１５】
さらに本目的は、ゲートウェイ装置と複数の端末デバイスとこれらの端末デバイスにアクセス・ネットワークを通してサービスを提供する通信システムのサービス提供サーバとの間の通信方法によって解決され、前述のサービス提供サーバは、前述の端末デバイスに提供する１つ以上のサービスを格納するサービスメモリと、前述の１つ以上のサービスに関係して前述のゲートウェイデバイスに第１のタイプの制御データを提供する少なくとも１つの第１のタイプの制御プロトコル・デバイスとを備え、前述の端末デバイスのそれぞれは、前述のサービス提供サーバから前述のアクセス・ネットワークを通して提供されたサービスを処理するサービス・プロセッサと、前述のサービス・プロセッサによるサービスの実行に関係して、前述の第１のタイプとは異なる第２のタイプの制御データを有する第２のタイプの制御プロトコル・デバイスとを備え、前述のゲートウェイ装置は、第１のタイプの制御データ（１ＣＤ）を前述のサービス提供サーバと交換し、第２のタイプの制御データを前述の端末デバイスと交換する１つ以上のサービス固有マッピング・デバイスを備え、方法は以下の、前述の端末デバイスの少なくとも１つから前述のゲートウェイ装置に第２のタイプの制御データを提供する工程と、前述のゲートウェイ装置の前述のサービス固有マッピング・デバイスから前述のサービス提供サーバに、前述の端末デバイスから提供された前述の第２のタイプの制御データに基づいて第１のタイプの制御データを提供する工程と、前述のサービス提供サーバの前述の第１のタイプの制御プロトコル・デバイスから前述のゲートウェイ装置に第１のタイプの制御データを提供する工程と、前述のサービス固有マッピング・デバイスから前述の端末デバイスに、前述のサービス提供サーバから提供された前述の第１のタイプの制御データに基づいて第２のタイプの制御データを提供する工程とを備える。
【００１６】
本発明によれば、例えばＩＭＳベースのアプリケーション（通信）サーバと非ＩＭＳ端末（ホーム）デバイスとの間に、必要なゲートウェイ機能を提供する例えばＨｉＧＡゲートウェイデバイスなどにサービス固有の特性があることには、特別な利点がある。これをもとにして、標準端末デバイスも、ある種のパーソナル化された制御情報を提供されてもよい。
【００１７】
好ましくは、前述のサービス固有マッピング・デバイスは、ＩＰＴＶプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイスを備える。
【００１８】
さらに好ましくは、前述の第２のタイプの制御データは、第２のタイプのサービス要求を構成し、前述のサービス固有マッピング・デバイスは、第１のタイプの制御データとして、前述のアクセス・ネットワークが前述のサービスを端末デバイスに提供するために十分なリソースを有するかどうかをサービス提供サーバに問い合わせる第１のタイプの問い合わせ要求を送信し、前述のサービス提供サーバは、サービス提供サービスが十分なリソースがあることを確かめた場合、サービス提供のために十分なリソースがあることを示す肯定応答メッセージを第１のタイプの制御データとして送信し、サービス提供サーバが十分なリソースがないことを確かめた場合、サービス提供のために十分なリソースがないことを示す否定応答メッセージを第１のタイプの制御データとして送信する。
【００１９】
さらに好ましくは、前述の端末デバイスは、サービス・プロセッサとしてＭＰＥＧ２デコーダを有するセット・トップ・ボックスを備え、前述のサービス提供サーバは、前述のサービスメモリの中にサービスとしてＶｏＤ（ビデオオンデマンド、Video on Demand）サービスを備え、前述のサービス固有マッピング・デバイスは、ＲＴＳＰプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイスを備え、前述の制御プロトコルはＲＴＳＰであり、前述のリソースは前述のアクセス・ネットワークの回線の帯域幅である。
【００２０】
さらに好ましくは、前述のゲートウェイ装置および前述の端末デバイスは、宅内ネットワークの一部である。
【００２１】
さらに好ましくは、前述のゲートウェイ装置は、前述の宅内ネットワークのレジデンシャル・ゲートウェイの中に設置される。
【００２２】
さらに好ましくは、前述のゲートウェイ装置は、前述の端末デバイスから前述の第２のタイプの第１の制御データとしてＥＰＧダウンロード要求を受信し、前述のゲートウェイ装置が提供する前述の第２のタイプの制御データはパーソナル化されたＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）を備える。
【００２３】
さらに好ましくは、前述のゲートウェイ装置は、メモリの中に前述のユーザ・アイデンティティを備える。
【００２４】
さらに好ましくは、前述のユーザ・アイデンティティは、前述のゲートウェイ装置に挿入されたプラグインまたは前述のゲートウェイ装置のメモリの中に挿入されたＵＩＣＣカードに格納される。
【００２５】
さらに好ましくは、前述の端末デバイスは、セット・トップ・ボックス、暖房システム制御装置、住宅監視システム、カメラ、またはインテリジェントハウスの中央住宅制御装置を含むグループから選択された１つ以上のものである。
【００２６】
さらに好ましくは、前述の制御データの前述の第１のタイプはＳＩＰ（セッション開始プロトコル、Session Initiation Protocol）であり、前述の制御データの前述の第２のタイプは、ＨＴＴＰかまたはＵＰｎＰのどちらかである。
【００２７】
さらに好ましくは、前述のゲートウェイ装置は、前述のサービス提供デバイスから第１のタイプの制御データとして前述のダウンロードされる第１のタイプのＥＰＧを受信し、前述の受信したＥＰＧのフォーマットを前述の端末デバイスがサポートするフォーマットに変換する。
【００２８】
さらに好ましくは、前述のゲートウェイ装置は、端末デバイスと前述のサービス提供デバイスとの間のメディア・セッション確立を呼びかける。
【００２９】
さらに好ましくは、前述のメディア・セッション確立はユニキャスト・メディア・セッション確立である。
【００３０】
さらに好ましくは、前述のメディア・セッション確立は、マルチキャスト・メディア・セッション確立である。
【００３１】
さらに好ましくは、前述のゲートウェイ装置は、第１のタイプの制御データとしてＥＰＧ更新メッセージを受信する。
【００３２】
さらに好ましくは、前述のゲートウェイ装置は、第１のタイプの制御データとしてイベント・トリガ・メッセージを受信し、前述のイベント・トリガ・メッセージに基づいて第２のタイプの制御データとして、メディア・セッション確立メッセージを前述の端末デバイスに送信する。
【００３３】
本発明のさらに有利な実施形態および改善については、従属請求項に挙げている。しかし本発明は、請求項、図面および明細書に個別に記載している特徴および工程も備えることに留意すべきである。それ故、本発明は、このような特徴および工程の組み合わせに基づく実施形態も備える。
【００３４】
以下では、本発明について図面を参照して説明する。
【発明を実施するための最良の形態】
【００３５】
以下では、まず本発明の原理について、本発明に従う通信システムＳＹＳのブロック図である図２ａを参照して説明する。通信システムＳＹＳは、ゲートウェイ装置ＨｉＧＡと、複数の端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮと、これらの端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮにアクセス・ネットワークＡＣを通してサービスＳＥＲＶを提供するサービス提供サーバＩＭＳ−Ｓとを備える。
【００３６】
図２ａに示すように、サービス提供サーバＩＭＳ−Ｓは、前述の端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮに提供する１つ以上のサービスＳＥＲ１、ＳＥＲ２、ＳＥＲ３を格納するサービスメモリＳＥＲＭを備える。サーバＩＭＳ−Ｓは、図２ａではＨｉＧＡに単純に接続されているように示されているが、図１ａに示すように別個のサービス提供ネットワークＩＭＳ−Ｎにも配置されてもよい。サービス提供サーバＩＭＳ−Ｓは、制御プロトコル・デバイスが提供する制御プロトコルＩＭＳ−ＣＴＲＬＰを実行する。制御プロトコルの一例はＳＩＰである。このタイプのプロトコルは、「第１のタイプ」のプロトコルと呼び、１つ以上のサービスＳＥＲＶに「関係して」第１のタイプのＳＩＰ制御データＣＳを提供する。サービスメモリＳＥＲＭの中の各サービスは、独自の制御プロトコルを有してもよいし、また全サービスに対して１つの制御プロトコルが提供されてもよい。サービスは、既に図１ａに示し上記したように、例えばＩＰＴＶ提供(IPTV provision)（ＭＰＥＧ２ストリーム提供）、ＶｏＩＰサービス、テレビ会議、ＩＰＴＶでもよい。制御プロトコルの１つはＳＩＰでもよいが、他の制御プロトコルも使用されてもよい。
【００３７】
「関係して」の意味は、以下でさらに詳細を説明する図２ｂの実施例を参照して理解されてもよい。ここでは、サービスはＩＰＴＶであり、制御データ（第１のタイプの制御データ）は、ユーザ固有の電子プログラム・ガイドＥＰＧ１、ＥＰＧ２、…ＥＰＧｎである。しかし、第１のタイプの制御データまたは制御情報は、特定のサービス、ＩＰＴＶに関連するＨＴＭＬページの提供等を実行するための単なるトリガでもよい。それ故、制御プロトコルは、どことなく１つ以上の特定のサービスに「関係」または「関連」している。サービスは、図２ａに示すように、リンクＤＬを通してまたはアクセス・ネットワークＡＣを用いて、第２のタイプの端末デバイスＴ２に直接提供されてもよい。あるいは、サービスの提供を、ゲートウェイ装置ＨｉＧＡ自体を通るように経路指定する実行可能手段もある。
【００３８】
図２ａでは、端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮは、第１のタイプの端末デバイスＴ１、Ｔｎと第２のタイプの端末デバイスＴ２とを備え、これらの端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮのそれぞれは、前述のサービス提供サーバＩＭＳ−Ｓから前述のアクセス・ネットワークＡＣまたは前述のダイレクトリンクＤＬを通して提供されるサービスＳＥＲＶを処理するサービス・プロセッサＳＰを備える。第１のタイプの端末デバイスＴ１、Ｔｎは、このサービス・プロセッサＳＰによるサービスの実行に関係して、第１のタイプの制御データを前述のゲートウェイデバイスＨｉＧＡに提供する第１のタイプの制御プロトコル・デバイスを備えるのに対して、第２のタイプの端末デバイスＴ２は、このサービス・プロセッサＳＰによるサービスの実行に関係して、前述の第１のタイプとは異なる第２のタイプの制御データを前述のゲートウェイデバイスＨｉＧＡに提供する第２のタイプの制御プロトコル・デバイスを備える。この意味することは、第１のタイプの端末デバイスＴ１、Ｔｎは、図１ｃに示すように、サーバＩＭＳ−Ｓと直接実行および通信できることである。
【００３９】
例えば、第１のタイプの端末デバイスＴ１、Ｔｎは、第１のタイプの制御プロトコルに属する制御データの１つであるユーザ・アイデンティティ特性を備えてもよい。他方、第２のタイプの端末デバイスは、例えばＭＰＥＧ２ストリームなどを実行するサービス・プロセッサＳＰを単に備える標準セット・トップ・ボックスＳＴＢでもよい。それ故そのようなものとして、第２のタイプの端末デバイスは第２のタイプのある種の制御データだけを理解するが、サーバＩＭＳ−Ｓの第１のタイプの制御プロトコルからもたらされる第１のタイプの制御情報のどれも「理解しない」だろう。この意味することは、第２のタイプの端末デバイスＴ２は、第１のタイプの制御情報のどれも理解しないことである。例えば、第２の端末デバイスＴ２が単なるセット・トップ・ボックスＳＴＢである場合、ただＴＶサービスを実行するが、制御データとしてパーソナル化された電子プログラム・ガイドを要求する能力または提供される能力を持たない。
【００４０】
図２ａでは、ゲートウェイ装置ＨｉＧＡが第１のタイプの端末Ｔ１、Ｔｎと第２のタイプの端末Ｔ２の両方と通信しているように、通信システムＳＹＳが描かれているが、本発明は、第２のタイプの端末Ｔ２すなわちサービス提供サーバが使用するプロトコルとは異なるプロトコル（デバイス）を使用して動作する端末と通信するために、ＨｉＧＡで必要なそれらの機能に専念することは、理解されるべきである。第１のタイプの端末との通信のためには、第１のタイプの端末がサービス提供サーバと同じプロトコルを実行するので、明らかに本発明の特別の機能は必要ない。
【００４１】
ゲートウェイ装置ＨｉＧＡは、図１ｃまたは１ａと同様に配置され、すなわち、サーバＩＭＳ−Ｓと端末デバイスＴ１、Ｔｎ、Ｔ２との間の一種のプロキシの機能を果たす。しかし本発明に従い、図２ａに示すように、ゲートウェイ装置ＨｉＧＡは、非ＩＭＳホームデバイス上で動作するサービス固有アプリケーションとＩＭＳアプリケーションサーバが提供するサービスとの間の一種のサービス分離層(service abstraction layer)を備える。ゲートウェイ装置ＨｉＧＡのこのアプリケーションスペースＡＳは、１つ以上のサービス固有マッピング・デバイスＡＳ−Ａを備える。この種のアプリケーションスペースは、様々なタイプのサービス固有アプリケーションに対する共通アプリケーション実行環境であることを意図している。アプリケーションスペースのサービス固有アプリケーションは、本質的に、サービス固有制御プレーンを目標の第２の端末デバイスＴ２の固有の制御プレーンに適応させる。アプリケーションスペースは、様々なデバイス（機能セット）およびプロトコルをサポートするプラグインが設置される環境であると言ってもよい。それ故、サーバＩＭＳ−Ｓが提供するサービスＳＥＲＶのそれぞれに対して、ゲートウェイ装置ＨｉＧＡは、サービス固有マッピング・デバイスＡＳ−Ａを備える。
【００４２】
図２ａでは、一実施例としてＩＰＴＶマッピング・デバイスを示す。上に述べたようにゲートウェイデバイスＨｉＧＡは、ＨｉＧＡを本拠地とするアプリケーション固有ロジックのサポートを引き受ける。制御プレーンは、これを第２のタイプの端末デバイスＴ２の固有の制御プレーンにマッピングする機能を有するゲートウェイ装置ＨｉＧＡに終わる。従って、ゲートウェイ装置ＨｉＧＡは、第２の端末デバイスＴ２へのＩＰＴＶサーバプロキシの機能を果たす。ゲートウェイ装置ＨｉＧＡのアプリケーションスペースＡＳは、図２ａに示すようにＩＰＴＶアプリケーションの場合、ＩＭＳ ＩＰＴＶ ＡＳからのアプリケーション固有データを終端するモジュールの収納場所である。図２ａにやはり示すように、ＩＭＳコンテンツサーバＩＭＳ−Ｓからのメディアプレーンは、前に説明したように第２の端末デバイスＴ２に個別に直接終端される。
【００４３】
ゲートウェイ装置ＨｉＧＡは、機能上レジデンシャル・ゲートウェイまたはマスタＳＴＢ（Ｍ ＳＴＢ）に配置できよう。マスタＳＴＢ（Ｍ ＳＴＢ）は、複数のＳＴＢ（スレーブＳＴＢ）のためにＩＭＳ制御プレーンを取り扱う１つのマスタデバイスに接続されるホーム環境の複数のＳＴＢ（スレーブＳＴＢ）の存在を可能にする。ＩＰＴＶアプリケーション環境を考慮すると、一般的に第２の端末デバイスＴ２は、標準セット・トップ・ボックスＳＴＢでもよく、ゲートウェイデバイスＨｉＧＡは、同じ住宅またはレジデンシャル・ゲートウェイに配置されてもよい。
【００４４】
好ましくは、ユーザ・アイデンティティは、ＨｉＧＡのメモリに前もって格納されたほうがよく、このようにしてＩＭＳサーバに提示されたほうがよい。例えば、ユーザＩＤを有する一般携帯電話カード（ＵＩＣＣすなわち汎用ＩＣカード、Universal Integrated Circuit Card）がＨｉＧＡに提示されてもよい。このカードは、ＵＳＩＭまたはＩＳＩＭなどの相当数のアプリケーションを収容する(host)ことができよう。従って、ユーザ・アイデンティティは、携帯電話の加入に関係する一意の番号であり、「携帯電話カード」上で動作するＵＳＩＭ部分の一部であるＩＭＳＩでもやはりよい。また、スマートカードを有するＳＴＢのような最新のデバイスにおいてまさに見られるように、スマートカードが挿入されてもよい。さらに図１ｂに示すように、ＨｉＧＡは、ユーザプロファイルメモリＵＰ−ＭＥＭの中のユーザプロファイルを保有してもよい。このようなユーザプロファイルは、例えば図１ｃに示すゲートウェイデバイスＨｉＧＡの交換部分ＥＸなどに格納されてもよい。ユーザプロファイルは、ＩＭＳサービスアイデンティティに関連するあらゆる登録に対して保有されてもよい。例えば、図１ｂに示すように各ユーザ・アイデンティティ（ユーザＩＤ）は、特定の好み（制御情報）およびサービス識別表示ＩＭＳ−ＩＤに関連付けられている。例えば、各個別のユーザにユーザのＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）で異なるＴＶプログラムが入手可能であってもよく、図１ｂに示すように、ＩＤ１＝「父親」／制御情報＝「スポーツ」、ＩＤ２＝「息子」／制御情報＝「映画および子供番組」、およびＩＤｎ＝「母親」／制御情報＝「広告」などである。このような特定の好み（制御情報）が示される場合、ＨｉＧＡは、制御情報を用いてパーソナル化されたやり方で要求されたサービスがユーザ（端末デバイス）に確実に配信されるようにする。
【００４５】
以下では、サービス固有マッピング・デバイスＡＳ−Ａ（提供される各サービスに対して１つ）を有するアプリケーションスペースＡＳについて、さらに詳細に説明する。図２ａに示すように、マッピング・デバイスＡＳ−Ａの主な機能は、第１のタイプ（例えばＳＩＰ）の制御データをサービス提供サーバＩＭＳ−Ｓとを交換し、第２のタイプ（例えば非ＳＩＰ）の制御データを前述の第２のタイプ（例えば非ＳＩＰ）の端末デバイスＴ２と交換することである。すなわちＨｉＧＡは、第２の端末デバイスＴ２のプロキシとして働き、第１のタイプのサーバ制御プロトコルを使用してサーバＩＭＳ−Ｓと通信し、第２のタイプの制御データを使用して第２の端末デバイスＴ２と通信する。一実施例がこれを説明するはずである。
【００４６】
第２の端末デバイスＴ２は標準セット・トップ・ボックスＳＴＢであると、例えば想定する。標準セット・トップ・ボックスＳＴＢは、例えばサービス・プロセッサ内のＭＰＥＧ２デコーダを用いてＭＰＥＧ２ストリームなどを、実行する能力を有するだろう。標準セット・トップ・ボックスＳＴＢは、ＭＰＥＧ２ストリームまたはＩＰＴＶサービスの実行または要求をするための簡単な要求の作成だけを備えてもよい簡単な「第１のタイプ」の制御プロトコルも有してもよい。さらにＳＴＢは、一般用の電子プログラム・ガイドＥＰＧも受信し得るが、ユーザ固有のやり方でそれを受信したり要求したりできない。ユーザ固有の機能は、ＳＴＢに対するプロキシとして働くＨｉＧＡに受け継がれている。ＨｉＧＡは、ユーザ固有の制御情報例えばパーソナル化された電子プログラム・ガイドＥＰＧを要求し得るし、提供され得る。
【００４７】
ＩＭＳ−Ｓサーバの第１のタイプの制御データと第２の端末デバイスＴ２の第２のタイプの制御データとの「交換」は、第１のタイプの制御情報と第２のタイプの制御情報との間の相互関係またはマッピングも有する。より具体的には、サービス固有マッピング・デバイスＡＳは、前述の第２のタイプの端末デバイスＴ２から受信した第２のタイプすなわち非ＳＩＰの制御データに基づいて、第１のタイプのＳＩＰ制御データをサービス提供サーバＩＭＳ−Ｓに提供し、前述の第１のタイプの制御プロトコル・デバイスＩＭＳ−ＣＴＲＬＰから第１のタイプの制御データを受信する。サービス固有マッピング・デバイスＡＳ−Ａは、それとは反対に、前述のサービス提供サーバＩＭＳ−Ｓから受信した前述の第１のタイプの制御データに基づいて、第２のタイプすなわち非ＳＩＰの制御データを前述の第２のタイプの端末デバイスＴ２に提供し、第２の端末デバイスＴ２の前述の第２のタイプの制御プロトコル・デバイスＴＤ−ＣＰから第２のタイプの制御データを受信する。
【００４８】
従って、端末デバイスＴ２からＩＭＳ−Ｓサーバへの上り方向では、ＨｉＧＡが提供する第１のタイプの制御データは、端末デバイスＴ２から受信した第２のタイプの制御データに基づいていると言ってもよい。それとは反対に、「下り」方向例えばサーバＩＭＳ−Ｓから第２の端末デバイスＴ２では、ＨｉＧＡデバイスが第２の端末デバイスＴ２に提供する第２のタイプの制御データは、サーバＩＭＳ−Ｓから受信した第１のタイプの制御データに基づいている。この関連付け、すなわち「基づく」または第１のタイプの制御データと第２のタイプの制御データの相互関係は、ゲートウェイ装置ＨｉＧＡによって実行されるが、一種の「マッピング」と見なしてもよく、それ故デバイスＡＳ−ＡおよびゲートウェイデバイスＨｉＧＡを、「マッピング・デバイス」と呼ぶ。図２ｂと図２ｃの２つの簡単な実施例は、制御プレーン適合に関する「マッピング」機能をさらに強調するだろう。
【００４９】
図３は、図２ａを参照して上に説明したようにホームネットワークのゲート装置ＨｉＧＡを使用した、本発明の通信方法に従う一実施形態のフローチャートを示す。図３のフローチャートに示すように、一般にＨｉＧＡ内のアプリケーションスペースは、サーバサイドＩＭＳ−Ｓとゲートウェイ装置ＨｉＧＡとの間で、第１のタイプの制御メッセージ１ＣＤを交換するのに対して、第２のタイプの制御メッセージ２ＣＤは、第２のタイプの端末デバイスＴ２とゲートウェイ装置ＨｉＧＡとの間で交換される。
【００５０】
特に、ステップ１：２ＣＤ１で示すように、制御メッセージは、第２のタイプの端末デバイスＴ２からＨｉＧＡに発行されてもよい。メッセージはＨｉＧＡで受信され、ステップ２：１ＣＤ１で第１のタイプの関係する（マッピングされた）要求メッセージが、ＨｉＧＡからサーバサイドＩＭＳ−Ｓに送信される。このメッセージ１ＣＤ１は、上に説明したように、要求メッセージ２ＣＤ１に基づく。例えば、以下で説明するように制御メッセージは、その制御フォーマットまたは制御タイプを適応もしくは変換されてもよい（例えば図４ａのＥＰＧフォーマットのＥＰＧ変換などを参照）。
【００５１】
同様に、ステップ３：１ＣＤ２でＩＭＳ−ＳサーバサイドからＨｉＧＡへ第１のタイプの制御メッセージを送信するとき、ステップ４：２ＣＤ２で第１のメッセージ１ＣＤ２に基づく対応または関係するメッセージが第２の端末デバイスＴ２に提供されてもよい。このようにして、サーバサイドＩＭＳ−ＳとＨｉＧＡとの間の第１のタイプのそれぞれのメッセージ１ＣＤは、ＨｉＧＡと第２の端末デバイスＴ２との間の第２のタイプのメッセージ２ＣＤにそれぞれ基づいている。
【００５２】
図２ａを参照して上に説明したように、ＨｉＧＡの提供、特にＨｉＧＡの中の固有サービスに関連するプロキシ・アプリケーション（サービス固有マッピング・デバイス）の提供により、第２のタイプの市販の標準端末デバイスＴ２が普通は第１のタイプの端末デバイスによってだけ実行できるだろう機能を引き受けることを可能にする。
【００５３】
図２ｂの実施例は、第１の端末デバイスが第１のタイプのサーバＩＭＳ−Ｓと通信しているところを描いている図１ｃに示す実施例に関連する。まさに図１ｃに見られるように、図２ｂは、サービス例としてＩＭＳ−ＳサーバのＩＰＴＶサービスを備える。図２ｂは、第１のタイプの制御情報として、ユーザ・アイデンティティＩＤ１、ＩＤ２、…ＩＤｎに関係するパーソナル化された電子プログラム・ガイドＥＰＧ１、ＥＰＧ２、ＥＰＧ３の例も備える。ゲートウェイ装置ＨｉＧＡは、アイデンティティＩＤ１を有するユーザの例えば住宅に設置されるかまたはアイデンティティＩＤ１を有するユーザプラグインを有するので、ゲートウェイ装置ＨｉＧＡ、より具体的にはＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＩＰＴＶ）を実行するサービス固有マッピング・デバイスは、ユーザ固有の要求（制御情報）をサーバＩＭＳ−Ｓに提供し得る。
【００５４】
端末デバイスＴ２には、ＩＰＴＶサービスを実行するサービス・プロセッサＳＰと、ゲートウェイ装置ＨｉＧＡに要求メッセージ２ＣＤ１としてＥＰＧ要求を単に出力するＥＰＧ要求デバイスＣＰとがある。従って、端末デバイスＴ２は、電子プログラム・ガイドＥＰＧを要求でき、返信メッセージ２ＣＤ２でＥＰＧ情報を提供されるだろう。しかし、端末デバイスＴ２は、ユーザにパーソナル化された制御データを理解できないで、ＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＩＰＴＶ）を実行するマッピング・デバイスの仲介（プロキシ）によってパーソナル化されていることを知らないまま、単に電子プログラム・ガイドＥＰＧを受け入れるだろう。すなわち、ＥＰＧの要求メッセージを受信後、ＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＩＰＴＶ）を実行するマッピング・デバイスは、ゲートウェイ装置ＨｉＧＡまたはユーザ固有のプラグインから挿入されたユーザ・アイデンティティＩＤ１を有する要求メッセージ１ＣＤ１を送信することにより、ＩＤ１のユーザＩＤを有するユーザに対するパーソナル化されたＥＰＧ情報の要求を生成する。従って、要求メッセージ１ＣＤ１（制御情報要求メッセージ）は要求メッセージ２ＣＤ１に基づいていると言ってもよい。要求メッセージ１ＣＤ１（制御情報要求メッセージ）は、まだ概ねＥＰＧ情報要求に関連しており、ユーザ・アイデンティティＩＤ１で品質向上または補足されたよりユーザ固有のやり方になっているだけだからである。
【００５５】
１ＣＤ１に基づいて、サーバＩＭＳ−Ｓは、返信メッセージ１ＣＤ２の中でユーザにパーソナル化された電子プログラム・ガイド情報ＥＰＧ１を返すだろう。第２の端末デバイスＴ２は、返信メッセージ２ＣＤ２の中で返される電子プログラム・ガイド情報ＥＰＧがユーザ固有の電子プログラム・ガイド情報ＥＰＧ１であるとは知らないが、実のところＴ２に提供される電子プログラム・ガイド情報は、確かにユーザにパーソナル化されている。電子プログラム・ガイド情報は、ＨｉＧＡプロキシからＩＭＳ−Ｓサーバにユーザにパーソナル化されたやり方で要求されており、ユーザ固有のやり方でＨｉＧＡに返されたからである。従って、返信メッセージ２ＣＤ２内の返信情報ＥＰＧ１も、電子プログラム・ガイドＥＰＧ１を有する返信メッセージ１ＣＤ２に「基づき」または「相互関係」があり、すなわちマッピングされている。従って、図２ｂの通信シナリオは、それぞれ互いに「基づいて」いる第１のタイプの制御情報と第２のタイプの制御情報の交換を備える。
【００５６】
図２ｃは、ＭＰＥＧ２サービスストリーム提供の実施例に関するマッピング・デバイスの「マッピング機能」の別の例を示す。図２ｃでは、ＭＰＥＧ２ストリームは、サービス・プロセッサＳＰ内のＭＰＥＧ２デコーダによって復号される。図２ｃでは、返信メッセージ２ＣＤ２および１ＣＤ２は、肯定応答ＡＣＫの提供にしか過ぎない。しかし、図２ｃに示すように、第２の端末デバイスＴ２が実行するプロトコルとＩＭＳ−Ｓサーバが実行するプロトコルとは異なる、すなわちサービスプロバイダＩＭＳ−ＳからＭＰＥＧ２サービスを提供してもらうための要求メッセージ２ＣＤ１はＨＴＴＰ要求またはＲＴＳＰ要求であるのに対して、ゲートウェイ装置ＨｉＧＡが発行する要求は、メッセージ１ＣＤ１内のＳＩＰ要求である。従って、図２ｃにおいても、要求メッセージ１ＣＤ１は、メッセージ２ＣＤ１のＨＴＴＰ要求に「基づいて」いる。同様に、返信メッセージ１ＣＤ２（簡単な肯定応答ＡＣＫ）はＳＩＰ肯定応答メッセージであり、ＨＴＴＰ肯定応答メッセージである肯定応答メッセージ２ＣＤ２は、ＳＩＰ肯定応答メッセージ１ＣＤ２に「基づいて」いる。従ってこの場合、例えばＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＭＰＥＧ２）などを実行するマッピング・デバイスは、サーバＩＭＳ−Ｓと第２の端末デバイスＴ２との異なる制御プレーン間の要求メッセージおよび肯定応答メッセージを単に「マッピング」する。
【００５７】
図２ｃは、特定のサービス提供の要求を第２のタイプのＨＴＴＰ端末デバイスＴ２が行う場合、サービス固有のマッピング・デバイスが、リソース要求をサーバＩＭＳ−Ｓとネゴシエートするために、プロキシ・アプリケーションを実行する別の実施例も示す。この実施例は、ＶｏＤ（ビデオオンデマンド）サービスにアクセスし、第２の端末Ｔ２がセット・トップ・ボックスＳＴＢで構成されている場合に関する。（図２ｃの括弧で示すように）セット・トップ・ボックスＳＴＢは、ＲＴＳＰプロトコルを使用してＶｏＤサーバとメディア・セッションを開始している。図１ｃまたは図２ａに示すように、実際のビデオストリーミングは、直通回線ＤＬまたはアクセス・ネットワークＡＣを通して提供されてもよい。重要な側面は、セット・トップ・ボックスに要求されたストリームを配信するために十分なリソースＲＥＳ（例えば、帯域幅）を、アクセス・ネットワークが有するべきことである。サーバＩＭＳ−Ｓの一般的機能は、終端デバイスが必要とするリソースＲＥＳとアクセス・ネットワークＡＣで利用可能なリソースＲＥＳとをネゴシエートできることである。従ってＩＭＳ−Ｓサーバは、一般にＱｏＳ（サービス品質、Quality of Service）プロビジョニングを可能にする。しかし、図１ａ、１ｂ、１ｃの先行技術を参照して説明したように、市販のセット・トップ・ボックスＳＴＢは、このようなリソースＲＥＳをＩＭＳ−Ｓサーバとネゴシエートする能力を持たない。
【００５８】
しかし、図２ｃに示すようにゲートウェイ装置ＨｉＧＡが、ＲＴＳＰプロキシ・アプリケーションＡＳ−Ａ（ＲＴＳＰ）を実行するサービス固有マッピング・デバイスを備える場合、ＱｏＳの知識を全然持たない市販のデバイスが、ＱｏＳ予約システムを有するネットワークでＱｏＳパラメータを要求することができる。簡単な例は、ユーザが５Ｍｂｐｓの帯域幅を必要とする高解像度映画すなわちＨＤＴＶ映画を見たい場合である。アクセス・ネットワークＡＣが３Ｍｂｐｓだけを提供する場合、高解像度映画を市販のセット・トップ・ボックスＳＴＢを有するユーザに全く提供することができないので、問題がある。
【００５９】
ＨｉＧＡのアプリケーションスペースのＲＴＳＰプロキシは、リソースの予約／割り当てをしないで、予約は、実のところＩＭＳ−ＡＳからの依頼に応じてネットワークのリソースマネージャエンティティによって行われる。その結果、ＩＭＳ−ＡＳは、ＲＴＳＰプロキシがトリガするＨｉＧＡ内のＩＭＳ ＩＰＴＶクライアントから要求される。ＩＭＳ ＩＰＴＶクライアントは、まさにＳＩＰをサポートするとともにＩＰＴＶサービスに「気付いている」ＨｉＧＡ内のエンティティである。それ故それは、本当のＨｉＧＡの機能を構成する。従って、ＲＴＳＰクライアント（デバイス内）から、ＲＴＳＰプロキシ（ＨｉＧＡのアプリケーションスペースに置いてある）、ＩＭＳ ＩＰＴＶアプリケーション（ＨｉＧＡの中核機能）、ＩＭＳ ＡＳ、アクセス・ネットワークリソースマネージャを記載の順番で使用して、ユーザのストリーム要件およびアクセス・ネットワークＡＣの能力を前もってネゴシエートすることが可能であり、次いでリソースＲＥＳが十分にあるときはストリームを許可し、またリソースＲＥＳが十分にないときスはトリームを許可しない。
【００６０】
他方、ＲＴＳＰプロキシ自体は実は上記の順番の端にあり、それ自体でリソース予約を行わないことに留意すべきである。リソース予約は、ＩＭＳ ＡＳがデバイスのＩＭＳ ＩＰＴＶアプリケーションから要求を受けるとき、ＩＭＳ ＡＳが（前述の他のネットワークコンポーネントとともに）行う。ＲＴＳＰプロキシは、クライアントからＩＭＳ ＩＰＴＶアプリケーションにＲＴＳＰ要求を単に渡す。さらなる詳細については、好ましい実施例の「パーソナル化されたコンテンツ用のトリガ」を参照して以下に説明する。
【００６１】
要約すると、図２ｃでは第２のタイプの制御データ２ＣＤ１は、ビデオストリーミング提供の簡単なサービス要求を構成し、この要求２ＣＤ１は、ＲＴＳＰプロキシ・アプリケーションＡＳ−Ａ（ＲＴＳＰ）に提供される。次いでＲＴＳＰプロキシ・アプリケーションは、要求されたサービス（ビデオストリーム）を第２のタイプの端末デバイスＳＴＢに提供するために十分なリソースがアクセス・ネットワークＡＣにあるかどうかを問い合わせるために、サーバＩＭＳ−Ｓに問い合わせ／要求メッセージ１ＣＤ１を開始してもよい。次いで要求／問い合わせメッセージ１ＣＤ１の受信に応えて、サーバＩＭＳ−Ｓは、サービス提供のために十分なリソースＲＥＳがあるかどうかをアクセスシステムＡＣとネゴシエートまたはチェックしてもよい。十分なリソースがある場合、肯定応答メッセージ１ＣＤ２＝ＡＣＫがＨｉＧＡのＲＴＳＰプロキシ・アプリケーションに返信され、十分なリソースが見つからない場合、否定応答メッセージ１ＣＤ２＝ＮＡＣＫがＲＴＳＰプロキシ・アプリケーションに提供される。次いで対応する肯定応答／否定応答（ＡＣＫ／ＮＡＣＫ）メッセージが、ＲＴＳＰプロキシ・アプリケーションからセット・トップ・ボックスＳＴＰに提供される。市販のセット・トップ・ボックスＳＴＰは、サービス提供に関して一般的な要求メッセージの送信だけができるが、まずＲＴＳＰプロキシ・アプリケーションは、サービス提供のために必要な帯域幅（リソースＲＥＳ）をチェックし、予約してもよい。このようにして、ユーザ固有ベースで（ＲＴＳＰプロキシ・アプリケーションは、ＨｉＧＡが知っているユーザ・アイデンティティを使用してセット・トップ・ボックス（ＳＴＢ）からの要求をパーソナル化し得るので）、ビデオストリーミング提供を単に拒否または許可することが可能なだけでなく、例えばより狭帯域すなわちＱｏＳの低いビデオサービス提供を許可することも可能である。このようにして、ゲートウェイ装置ＨｉＧＡは、サーバＩＭＳ−ＳとＱｏＳのユーザ固有のネゴシエーションを実行し許可する。例えば、ユーザは、アクセス・ネットワークＡＣのある帯域幅に対してだけ支払っていてもよく、そのＲＴＳＰプロキシ・アプリケーションを有するゲートウェイ装置ＨｉＧＡは、ビデオサービスの提供をユーザが支払ったＱｏＳに「適応」させてもよい。
【００６２】
図２ｂ、２ｃの実施例および図２ａの通信システムＳＹＳの概略ブロック図および図３の通信方法で説明したように、本発明のおかげで従来の第２のタイプの端末デバイスＴ２も、ＨｉＧＡプロキシの仲介によって第１のタイプの制御情報を提供されてもよい。このやり方で、ユーザ固有すなわちパーソナル化されたコンテンツデータも、簡単で標準的な第２の端末デバイスＴ２にも提供されてもよい。
【００６３】
以下ではＩＰＴＶの事例に関連する本発明の特別な実施形態について、図２ｄを参照して、また図４ａ、４ｂ、４ｃ、４ｄ、４ｅも参照して説明する。
【００６４】
図２ｄは、本質的に図２ａのＩＰＴＶサービスアプリケーションの具体的事例に相当する。図２ｄには、アプリケーションスペースおよびその内部のサービス固有アプリケーションならびにＨｉＧＡ経由でＩＭＳサービスにアクセスし得る非ＩＭＳデバイスのセットを示す。ＩＭＳサービスの一例はＩＰＴＶサービスである。非ＩＭＳのＳＴＢ（第２の端末デバイス）と、ＨｉＧＡアプリケーションスペース内のＩＰＴＶサービスアプリケーション（マッピング・デバイス）と、ＩＭＳ ＩＰＴＶ ＡＳとの間の遣り取りを、図４ａ、４ｂ、４ｃ、４ｄ、４ｅに示す。これらの図は、ＩＰＴＶサービスに固有のシグナリング図を示し、サービス実施の一例としてここに示す。一部のメッセージは、ＨｉＧＡ実施の標準的なものであるが、採用されたＩＰＴＶアプリケーションを有するＨｉＧＡアプリケーションスペースの特殊なメッセージについては、本発明の機能を説明するために強調する。他のＩＭＳサービスおよび非ＩＭＳサービスに関しては、提供されるアプリケーション（サービス）に依存するが、図４ａ、４ｂ、４ｃ、４ｄ、４ｅのシーケンス図と同様であろう。
【００６５】
図２ｄに示すように、アプリケーションスペースを有するＨｉＧＡは、ＨｉＧＡ内に配置されるアプリケーション固有ロジックのサポートを引き受ける。制御プレーンは、マッピング・デバイスを用いてこれをＳＴＢ固有の制御プレーンにマッピングするタスクを有するＨｉＧＡに前と同じように終端される。従って、ＨｉＧＡは、前に説明したようにＳＴＢへのＩＰＴＶサーバプロキシとしての機能をこの場合も果たす。このようにしてＨｉＧＡ内のアプリケーションスペースは、ＩＭＳ ＩＰＴＶ ＡＳからのアプリケーション固有データを終端するモジュールの収納場所である。この場合もやはり図２ａに見られるように、ＩＭＳコンテンツサーバＩＭＳ−ＳからのメディアプレーンはＳＴＢに終端される。
【００６６】
上に説明したように、ＨｉＧＡの機能は、レジデンシャル・ゲートウェイまたはマスタＳＴＢ（Ｍ ＳＴＢ）に配置できよう。マスタＳＴＢ（Ｍ ＳＴＢ）は、複数のＳＴＢためにＩＭＳ制御プレーンを処理する１つのマスタデバイスに接続されるホーム環境の複数のＳＴＢ（スレーブＳＴＢ）の存在を可能にする。
【００６７】
図４ａ〜４ｅの全図は、本発明の好ましい形態に関するが、本発明の主要範囲は図２ａおよび図３の図に示されているので、本発明の範囲を限定すると決して見なしてはならないことに留意してもよい。
【００６８】
ＳＴＢのメディア・セッション開始について、図４ａに示す。図４ａには、従来のゲートウェイ装置ＨｉＧＡに既に部分的に組み込まれているメッセージがあることに留意すべきである。本発明の好ましい形態に従う新しいメッセージは、図４ａにおいて（および以下で説明する図４ｂ〜４ｅの他のフローチャートにおいても）それぞれ○印が付いている。図４ａは、図２ｂのＥＰＧダウンロードに関連する本発明のより詳細な実施形態である。
【００６９】
図４ａでは、右側の「メディアサーバ」が図２ａの右側に示すＩＭＳ−Ｓサーバに相当する。セット・トップ・ボックスＳＴＢは、第２のタイプの端末デバイスＴ２に相当する。「：ＨｉＧＡ」／：ＣＳＣＦ（コールセッション制御機能）は、ゲートウェイ装置ＨｉＧＡに配置されている。「：ＩＰＴＶ ＡＳ」はＩＭＳサーバのアプリケーションスペースに相当する。
【００７０】
図４ａの前提条件は、：ＣＳＣＦのトリガがＲＥＧＩＳＴＥＲ時にｓｉｐ：ｆａｍｉｌｙ＠ｏｐ．ｃｏに対して設定されていて、ＳＴＢは電源が切れており、ｓｉｐ：ｆａｍｉｌｙ＠ｏｐ．ｃｏｍはセット・トップ・ボックスＳＴＢのデフォルトのＩＭＳアイデンティティである。図４ａのセット・トップ・ボックスＳＴＢのメディア・セッション初期設定は、ＳＴＢからＨｉＧＡ送信されるメッセージ１：メッセージ電源オンで始まる。メッセージ２：ＲＥＧＩＳＴＥＲで、ＨｉＧＡは家族のアイデンティティを登録する。このステップ２：には、ＨｉＧＡによるセット・トップ・ボックスＳＴＢのアプリケーションスペースＡＳへの登録を含む。ステップ２：は、例えば「Ｒｅｃｈｏｎアーキテクチャ報告（Ｒｅｃｈｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｒｅｐｏｒｔ）ＥＡＢ−０５：０４５６０８、２００５−１２−２２」などに定義されている従来のメッセージである。
【００７１】
ステップ３：では、登録要求が事前設定のトリガに基づきアプリケーションスペースに中継される。ステップ４：では、アプリケーションスペースＡＳが、ユーザプロファイルを有するステップ４：ＭＥＳＳＡＧＥメッセージで応答する。ステップ５：では、ＭＥＳＳＡＧＥをＨｉＧＡに送信する。今度は受信したユーザプロファイルに基づき、ゲートウェイ装置ＨｉＧＡは、ステップ６：ＳＵＢＳＣＲＩＢＥでアプリケーションスペースＡＳにサブスクリプションを実行する。ステップ７：ＳＵＢＳＣＲＩＢＥでは、サブスクリプションメッセージがアプリケーションスペースＡＳに中継される。ステップ８：では、アプリケーションスペース：ＩＰＴＶ ＡＳが、対応するユーザプロファイルに対するＥＰＧのＵＲＬを有するＮＯＴＩＦＹメッセージで応答する。ステップ９：ＮＯＴＩＦＹでは、ＵＲＬを有するＮＯＴＩＦＹメッセージがゲートウェイ装置ＨｉＧＡに中継される。これまでのステップ１：〜９：は従来のものであり、市販の第２の端末デバイスＴ２も、対応するユーザプロファイルに対するＥＰＧのＵＲＬを受信するために、このようなステップを実行し得る。
【００７２】
本発明に従って、ステップ１０：では、ゲートウェイ装置：ＨｉＧＡがメッセージ１０：ＥＰＧデータ読み出しメッセージを：ＩＰＴＶ ＡＳアプリケーションスペースに送信する。このようにして、ステップ１０：では、アプリケーションスペースのＩＰＴＶアプリケーション：ＩＰＴＶ ＡＳが、受信したＵＲＬに指定された場所からＥＰＧを読み出す。ステップ１１：フォーマットＸのＥＰＧでは、ＵＲＬから読み出されたＥＰＧデータがセット・トップ・ボックスＳＴＢが普通サポートしていないフォーマットで受信される、すなわち本質的にＥＰＧは、第１のタイプの制御データフォーマットである（図２ｂも参照）。それ故ステップ１０では、ゲートウェイ装置：ＨｉＧＡは、セット・トップ・ボックスＳＴＢがサポートしている第２のタイプのフォーマットにＥＰＧを変換する。これが行われるのは、ＥＰＧは、セット・トップ・ボックスＳＴＢがサポートするフォーマットと普通必ずしも同じではないからである。すなわち、ＥＰＧフォーマットは、ＳＴＢがサポートするフォーマット例えばＨＴＭＬフォーマットに変換される。ステップ１２：では、第２の制御データタイプ（例えばＨＴＭＬ）に変換されたＥＰＧデータが、セット・トップ・ボックスＳＴＢに中継される。このやり方で、市販のセット・トップ・ボックスＳＴＢは、パーソナル化された電子プログラム・ガイドＥＰＧを受信し得る。
【００７３】
ステップ１３：ＩＮＶＩＴＥでは、トランスポートネットワークのメディアストリームにネットワークリソースを割り当てるために使用されるだろうＳＤＰを有するＩＮＶＩＴＥメッセージが、ＨｉＧＡによって送信される。ステップ１２：の後、すなわちＥＰＧのダウンロード後、：ＨｉＧＡは、図２ｃに示す原理に見られるように、リソースネゴシエーションを実行し得る。このようにして、：ＨｉＧＡは、まずアクセス・ネットワークＡＣに、決まった最大帯域幅例えば５ＭＢ回線を予約してもよい。次いでＳＴＢのそばにいるユーザは、ＩＭＳサーバへの要求としてストリームチャネルを選択してもよい。例えばユーザは、ＨＤＴＶチャネルを要求してもよい。アクセス・ネットワークＡＣが回線を提供できない場合、ＨｉＧＡは、ＮＡＣＫメッセージを返信し、アクセス・ネットワークＡＣが回線を提供できないと伝える（図２ｃも参照）。ＨｉＧＡは、別のストリームを試みたほうがよい、またはより低解像度のチャネルでストリーミングをするように、メッセージでネゴシエートもしてもよい。
【００７４】
ステップ１４：では、招待メッセージＩＮＶＩＴＥがＣＳＣＦ（コールセッション制御機能）から中継される。ステップ１５：では、ユニキャスト・アドレスまたはマルチキャスト・アドレスを有するＯＫメッセージが、アプリケーションスペース：ＩＰＴＶ ＡＳから返信される。ステップ１６：では、ＯＫメッセージは、：ＣＳＣＦから：ＨｉＧＡへ中継される。
【００７５】
ステップ１７：メディア・セッション開始は、従来のシステムでサポートされていない重要なメッセージである。ステップ１７：では、ＨｉＧＡの：ＩＰＴＶアプリケーションスペースが、セット・トップ・ボックスＳＴＢとサービス提供デバイス（メディアサーバ）との間のメディア・セッション確立を呼びかける。このメッセージにより、：ＨｉＧＡがステップ１７におけるメディア・セッション確立を積極的に制御し開始し得るので、これは重要なメッセージである。図４ｂ、４ｃは、この好ましい詳細をさらに示す。
【００７６】
ステップ１８：メディア・セッション確立では、従来のやり方で、図２ａに示すように例えば直通回線ＤＬまたはアクセス・ネットワークＡＣを通して、メディア・セッションがＳＴＢとメディアサーバＩＭＳ−Ｓとの間で確立される。
【００７７】
このようにして、：ＨｉＧＡがユーザ固有ベースで登録を実行するので（図４ａの最初のブロック参照）、ユーザ固有の電子プログラム・ガイドＥＰＧを：ＩＰＴＶ ＡＳから読み出すことが可能であり、この固有の電子プログラム・ガイドＥＰＧは、ステップ１２：の前に変換された後、市販のＳＴＢに中継されてもよい。その後、メディア・セッション確立がトリガされてもよい。このようにして、制御データ（電子プログラム・ガイドＥＰＧ）はユーザにパーソナル化されたやり方でセット・トップ・ボックスに提供されてもよく、これは市販のセット・トップ・ボックスＳＴＢが普通することができないことである。
【００７８】
図４ｂは、図４ａのステップ１７：メディア・セッション開始の説明としてＵＰｎＰプロトコルを使用するユニキャスト・セッション確立を示す。図４ｂの前提条件は、ＳＴＢは電源が入れられておりＨｉＧＡ経由でサーバＩＭＳに登録されている、すなわち図４ａのステップ１：〜９：は、前もって実行されている。図４ｂでは、右側のメディアサーバは、図２ａに示すサーバＩＭＳ−ＳのサービスメモリＳＥＲＭに格納されたサービスＳＥＲＶに相当する。ＨｉＧＡとＵＰｎＰメディアサーバはともに、図２ａに示すＨｉＧＡに配置される。図４ｂの左側のＳＴＢは、図２ａに示す第２の端末Ｔ２に相当する。
【００７９】
図４ｂのステップ１：では、ＵＰｎＰサーバがＨｉＧＡアプリケーションスペースの中にＩＰＴＶアプリケーションとともに配置されていて、メディアサーバに配置されたビデオコンテンツのＵＲＬを渡し、メディア・セッションを開始するようにセット・トップ・ボックスＳＴＢに呼びかける。ＵＰｎＰ ＡＶアーキテクチャ、特に「ＵＰｎＰ ＡＶアーキテクチャ（ＵＰｎＰ ＡＶ ａｒｃｈｉｔｅｃｔｕｒｅ）０．８３」のセクション６．５に記載の非同期プッシュモデルを、好ましくはここで使用できよう。
【００８０】
ステップ２：では、ユニキャスト・セッションの確立があり、その意味するところは、ＳＴＢのＵＰｎＰメディアレンダラが右側のメディアサーバとユニキャスト・ストリームを確立する。図２ｃと同様に、これは、ＲＴＳＰプロトコルで行われてもよい。ステップ３：では、ＲＴＰメディアストリームが、メディアサーバからＳＴＢに送信される。このシナリオでは、セット・トップ・ボックスＳＴＢ固有のアプリケーションは、好ましくは「ＵＰｎＰ ＡＶアーキテクチャ０．８３」に記載のＵＰｎＰメディアレンダラデバイスであることができよう。
【００８１】
重要なステップ１：で述べたように、セット・トップ・ボックスＳＴＢは、メディアサーバに配置されたビデオコンテンツのＵＲＬを渡されて、メディア・セッションを開始するように呼びかけられる。このようにして、：ＨｉＧＡからＳＴＢの積極的な制御が行われてもよい。
【００８２】
図４ｂとは対照的に、図４ｃは、図４ａのステップ１７：で使用されてもよいマルチキャスト・セッション確立を示す。図４ａに示すユニットに加えて、図４ｃは、ゲートウェイ装置ＨｉＧＡと：ＣＳＣＦ（コールセッション制御機能）との間に配置されるレジデンシャル・ゲートウェイＲＧＷも示す。図４ｂと同様に、図４ｃは、：ＨｉＧＡが登録されていて、ＥＰＧがＳＴＢによってダウンロードされているという前提条件に基づいている。
【００８３】
本発明に従う重要なメッセージ：ＩＮＶＩＴＥが備えている中には、マルチキャストされたチャネル（例えば、ブロードキャストされたＴＶチャネル）を受信するように要求するＩＮＶＩＴＥメッセージを、ＨｉＧＡのＩＰＴＶアプリケーションがＣＳＣＦに送信することがある。このようにして、本発明に従って：ＨｉＧＡは、マルチキャストされた特定のチャネルの受信を要求して、第１のタイプの要求メッセージを：ＣＳＣＦに積極的に送信してもよい。本質的にステップ１：ＩＮＶＩＴＥは、ブロードキャストセッションを開始すること、例えばＩＮＶＩＴＥｔｖ＿ａｓ＠ｏｐ．ｃｏｍである。
【００８４】
ステップ２：では、ＩＮＶＩＴＥメッセージは、：ＣＳＣＦによってＩＰＴＶアプリケーションスペース：ＩＰＴＶ ＡＳに中継される。ステップ３：では、サーバＩＭＳ−ＳのアプリケーションスペースＡＳが、ＴＶチャネルのビデオストリームを有するマルチキャスト・グループに関するマルチキャスト・アドレスを有するＯＫメッセージ（例えば２００）で応答する。このマルチキャスト・アドレスは、ステップ３：にＭＣ＿Ｘで示す。ステップ４：では、ＯＫメッセージがゲートウェイ装置ＨｉＧＡに送信される。ステップ２：〜ステップ４：は、要求メッセージをサーバに中継するため、およびこのようなメッセージにサーバが応答するための、従来のメッセージである。
【００８５】
本発明に従ってステップ５：では、ＨｉＧＡアプリケーションスペースのＩＰＴＶアプリケーションスペースが、セット・トップ・ボックスＳＴＢのＩＧＭＰクライアントにマルチキャスト・グループに参加するように呼びかける。さらに本発明に従ってステップ６：では、セット・トップ・ボックスＳＴＢのＩＧＭＰクライアントは、レジデンシャル・ゲートウェイＲＧＷにＩＧＭＰ ＪＯＩＮメッセージを送信し、レジデンシャル・ゲートウェイＲＧＷがそれをトランスポート（アクセス）ネットワークのＩＧＭＰアウェアアクセスノードに送信することにより、新しいマルチキャスト・グループに参加する。
【００８６】
図４ｃのメッセージ１：、５：、６：により、マルチキャストされたチャネル（例えば、ブロードキャストされたＴＶチャネル）の特定のマルチキャスト・グループに参加し得るようなやり方で、第２のタイプの制御データでＳＴＢを制御することが可能になる。従って：ＨｉＧＡは、マルチキャストされたチャネルに関してサーバ：ＩＰＴＶ ＡＳと「ネゴシエーション」を実行し、次いでステップ４：でＯＫメッセージを受信後、マルチキャスト・グループに参加するようにＩＧＭＰクライアントに呼びかけるために、セット・トップ・ボックスＳＴＢに対応する第２のタイプの制御データを送信してもよい。このようなネゴシエーションは、市販のセット・トップ・ボックスＳＴＢでは実行できない。
【００８７】
図４ｄは、電子プログラム・ガイドＥＰＧを更新するために、サーバからセット・トップ・ボックスＳＴＢに制御データを送信する一実施例を示す。図４ｄの前提条件は、セット・トップ・ボックスＳＴＢが電源を入れられており、ＨｉＧＡ経由でＩＭＳサーバに登録されている（基本的に図４ａのステップ１：〜６：が実行されている）。図４ｄの目的は、ＳＴＢの制御データを更新する一例として、基本的に：ＨｉＧＡのＩＰＴＶアプリケーションがＥＰＧの更新を行うことである。しかし、他の種類の制御データも全く同じやり方で更新できることが理解される。
【００８８】
ステップ１：は、サーバサイドＩＰＴＶ ＡＳがＥＰＧ更新メッセージを：ＨｉＧＡに送信する従来のメッセージである。ＨｉＧＡのＩＰＴＶクライアント（ＩＰＴＶプロキシ・アプリケーション）は、ＥＰＧを受信し、ＥＰＧはＳＴＢがサポートするフォーマットに変更される。ＥＰＧのこの変換は既に、図４ａを参照してステップ１２：で説明したように、本発明に従う新しいメッセージの一部である。
【００８９】
図４ｄのステップ２：では、：ＨｉＧＡのＩＰＴＶプロキシ・アプリケーション（クライアント）が、ＥＰＧ更新をセット・トップ・ボックスＳＴＢに送信する。このステップは、セット・トップ・ボックスＳＴＢがサポートするＥＰＧの様式の実装に個別のものである。代替の好ましい形態は、ＳＴＢへのＥＰＧファイル全体または変更だけの送信を含む。しかし、重要なことは、図２ｂと同様に、電子プログラム・ガイドＥＰＧに関する制御データが、サーバ：ＩＰＴＶ ＡＳと：ＨｉＧＡとの間で第１のタイプのフォーマットで交換され、：ＨｉＧＡでＳＴＢがサポートするフォーマットに変換してもらうことにより、セット・トップ・ボックスＳＴＢが、この更新を理解するようになることである。
【００９０】
このようにして、市販のＳＴＢが、変更のない一般のユーザ固有でないＥＰＧだけを受信できるのに対して、本発明の通信システムＳＹＳは、パーソナル化された（ユーザ固有の）ＥＰＧおよびその変更を、市販のＳＴＢにダウンロードすることを可能にする。
【００９１】
図４ａ〜４ｅの上記多数の実施例で説明したように、ＨｉＧＡアプリケーションスペースのＩＰＴＶプロキシ・アプリケーション（クライアント）は、市販のＳＴＢが普通できない機能および変換機能を引き受ける。ＨｉＧＡは、「最新」のＳＴＢが自装置で実行し得る機能を従来のＳＴＢが実行するために、一種のフロントエンドの役割を果たす、と言うこともできよう。
【００９２】
もう１つの重要なシナリオは、基本的に図４ｅに示すように、：ＨｉＧＡアプリケーションスペースのＩＰＴＶプロキシ・アプリケーション（クライアント）の助けで、パーソナル化されたコンテンツをどのようにＳＴＢに配信し得るかである。パーソナル化されたコンテンツの一例は、ユーザの好みまたはユーザプロファイルに合わせた広告である。この広告は、コマーシャル時間中にユーザに見せられるだろう。従って、パーソナル化された電子プログラム・ガイドＥＰＧをダウンロードおよび変換したのと同様に、図４ｅのシナリオは、パーソナル化されたコンテンツの市販のＳＴＢへの提供に関連する。
【００９３】
図４ｅでは、ユニットである：ＳＴＢ、：ＨｉＧＡ、：ＣＳＣＦ、ＩＰＴＶ ＡＳおよび：メディアサーバの位置付けおよび配列は、図４ａのそれぞれのユニットに相当する。図４ｅの前提条件は、ＳＴＢが電源を入れられており、：ＨｉＧＡ経由でサーバＩＭＳに登録されていることである。：ＨｉＧＡは、サーバサイドから送信されるトリガイベントを理解するように、マルチキャスト・チャネル・イベント・トリガに登録する。
【００９４】
図４ｅに示すように、ステップ１：イベントトリガでは、イベントトリガがＨｉＧＡで受信される。これは、コマーシャルの開始などのイベントに関するトリガ、ルーティング用の双方向性トリガ等であることができよう。もちろん、究極的にステップ１：のイベントトリガの目的は、セット・トップ・ボックスＳＴＢに特定の動作を呼びかけることである。このイベントトリガ（第１のタイプの制御データ、図２ａ参照）は、市販のセット・トップ・ボックスＳＴＢが理解できるように、ＨｉＧＡによって第２のタイプの制御データに変換される。一般にイベントトリガの基本機能は、ＳＴＢに特定の動作を呼びかけることである。図４ｅの例では、もちろんイベントトリガの目的は、ＳＴＢにコマーシャルであるメディア・セッションの開始を通知することである。すなわち、もちろん最終的願望は、パーソナル化されたやり方でコマーシャルまたは広告に接続するために、ＳＴＢがサーバサイドとメディア・セッションを開始することである。
【００９５】
それ故ステップ２：では、メディア・セッション確立が開始され、トリガのＵＲＬに基づき、ＨｉＧＡのＩＰＴＶアプリケーション（プロキシ・アプリケーション）が、セット・トップ・ボックスＳＴＢにメディア・セッション確立を呼びかける。このメディア・セッション確立は、ユニキャスト・セッションが確立されるかマルチキャスト・セッションが確立されるかに応じて、図４ｂ、４ｃに示す。
【００９６】
パーソナル化されたコンテンツを配信するためのユニキャスト・セッションの確立（図４ｂ）は、アクセストランスポートネットワークＡＣのネットワークリソースの観点からは高過ぎることがある。このため、広告などのパーソナル化されたコンテンツは、ＣＰＮ（宅内ネットワーク、Customer Premises Network）、例えばＳＴＢ自体かまたは事業者が制御するＮＡＳ（ネットワーク接続ストレージ、Network Attached Storage）などにあらかじめキャッシュできよう。この場合、図４ｅのステップ３：、４：におけるメディアサーバは、あらかじめキャッシュしたコンテンツを有するＣＰＮエンティティ（例えば、ＳＴＢまたはＮＡＳ）であろう。
【００９７】
：ＨｉＧＡは登録プロセスのために（およびその中でユーザ・アイデンティティを格納するために）メッセージをパーソナル化するので、ユーザにパーソナル化されたコマーシャルを実際のメディア・セッションでＳＴＢに提供することは、実現し得る。ＨｉＧＡは、コマーシャル（イベントトリガ開始）が特定のユーザ・アイデンティティ用か否かをチェックするために、どんな種類のイベントトリガが受信されるかのフィルタリングを実行するからである。それが特定のあらかじめ登録されたユーザ・アイデンティティ用である場合だけ、ＨｉＧＡは、このコマーシャルに対してＳＴＢにメディア・セッションを呼びかける。このやり方で、パーソナル化されたコンテンツ例えばコマーシャルが、ユーザにパーソナル化されたやり方でＳＴＢに提供されてもよい。これとは対照的に、従来の市販のセット・トップ・ボックスを使用すると、誰もが広告時間に同じ広告を見なければならないだろう。すなわち本発明に従って、特定の前もって合意されたＵＲＬが特定のコマーシャルストリームを送信しようとしている場合、ＨｉＧＡはトリガを受信するだろう。ＨｉＧＡの中では、ＵＲＬはユーザＩＤに関連付けられており、それ故、コマーシャルが送信されようとしていて、ユーザＩＤが前もってそれに興味を示している場合、ＨＩＧＡは、サーバサイドでの特定のコマーシャルの提供を示す第１のタイプの制御データだけを、ＳＴＢに提供する。その場合、メディア・セッション設定が、このビデオ情報提供のために実行される。
【００９８】
ＶｏＤストリームの呼びかけに関して、ＳＩＰ ＩＮＶＩＴＥメッセージをＩＰＴＶ ＡＳに送信できよう。この達成のために、ＳＴＢのＩＰＴＶアプリケーションは、代替プロトコル（ｚ．Ｂ．ＵＰｎＰ、ＨＴＴＰ、ＳＩＰ等）の１つを通じてＨｉＧＡにメッセージを送信でき、その結果ＨｉＧＡは、サーバのＩＰＴＶ ＡＳと適切なＳＩＰダイアログを開始するだろう。ＳＤＰを運ぶダイアログの最終メッセージは、ネゴシエートしたメディア・セッションの帯域幅要件に従って、アクセストランスポートネットワークＡＣのリソースＲＥＳを予約するために、リソース管理システムをトリガできよう。基本的にリソースネゴシエーションは、図２ｃの実施例で概説したように行われるだろう。
【００９９】
通信システムＳＹＳ、特にゲートウェイ装置ＨｉＧＡを、図２ａのブロック図および図３のフローチャートに示すように構成して、特にゲートウェイ装置ＨｉＧＡを図２ａに示すように市販のセット・トップ・ボックスＳＴＢに対する一種のプロキシ・アプリケーションとしてサービス固有のマッピング・デバイスを有するように構成して、第２の端末デバイスＴ２の制御プロトコルにサービス提供デバイスＩＭＳ−Ｓのサービス制御プレーンを適応、変換および解釈する適切なアプリケーションをＨｉＧＡのアプリケーションスペースＡＳに採用することにより、ゲートウェイ装置ＨｉＧＡは、ＳＴＢなどのＩＭＳを理解しない様々なタイプのホームデバイスに対して、例えばＩＭＳベースのサービスへのアクセスを提供し得る。それゆえ本発明は、非ＩＭＳデバイスとＩＭＳベースのサービスとの間の不適合の問題を解決し、それ故に、事業者が、種々の標準的市販のホームデバイスにＩＭＳを通じて自社のマルチメディアサービスを提供する道を開く。
【０１００】
図２ｂおよび図４ａ〜４ｅに示すように一態様は、標準ＳＴＢがサーバのＩＭＳ ＩＰＴＶ ＡＳに気付く必要なしにその元の機能の維持を可能にする、ＨｉＧＡアプリケーションスペースのＩＰＴＶサポートに関連している。従って標準ＳＴＢは、汎用メディア終端デバイスすなわち市販で購入し得る一般的な第２のタイプの端末デバイスでもよい。
【０１０１】
さらに、ＨｉＧＡのアプリケーションスペースプロキシは、ＨｉＧＡの容易なアップグレードを可能にする。サービスアプリケーションの新バージョンまたは既存のサービスアプリケーションの更新を、ＨｉＧＡのアプリケーションスペースＡＳにダウンロードし得る。これは、機能の点でＨｉＧＡに融通性を加え、サービスプロバイダが遠隔でＨｉＧＡを管理することを可能にする。
【０１０２】
図２ａ、３（原理）、図２ｂ（ＥＰＧ要求）、図２ｃ（要求マッピング／リソース割り当て）ならびにより具体的な実施例である図２ｄ（ＩＭＳサーバシステム）、図４ａ（メディア・セッション開始およびＥＰＧダウンロード）、図４ｂ（ユニキャスト・セッション確立）、図４ｃ（マルチキャスト・セッション確立）、図４ｄ（ＥＰＧ更新）、図４ｅ（トリガに基づくメディア・セッション開始）の本発明の全体にわたる上記実施形態は、上記のシナリオだけで役に立つわけではない。例えば、端末デバイスＴ２は、家庭の暖房システムの制御装置によって、監視カメラによって、家庭用電化製品の制御を実行する住宅制御デバイス（いわゆる「インテリジェントホーム」に見るような）、ＤＶＤもしくはＭＰ３収集メモリ、または実のところ住宅内の他のどの物理ユニットによって構成されてもよいことも想像される。サーバＩＭＳ−Ｓは、携帯電話機などの例えばリモートアクセスデバイスに接続されてもよい。例えばこの場合、携帯電話機は、ユーザ固有のやり方で家の暖房システムの市販の暖房制御装置に遠隔からアクセスするために使用されてもよい。ホームメモリと携帯電話機との間にユーザ固有のメディア・セッションを確立することにより、携帯電話機にＭＰ３ファイルをダウンロードするために、またはホームメモリから携帯電話機へ個人用ＤＶＤのビデオストリーミングを確立するために、携帯電話機は、家のＤＶＤまたはＭＰ３収集メモリにもトリガを送信してもよい。携帯電話機は、特に図４ｅに関して説明したように例えばトリガメッセージを使用することにより、家庭に配置された監視システムの市販のカメラのオン／オフ、アップ／ダウン、またはズームイン／ズームアウト制御にも使用されてもよい。これは、好ましくはＵＰｎＰプロトコルを使用して行われてもよい。このようにサービス属性の適応（マッピング）は、例えば自装置のＩＰアドレスを持たずＳＩＰプロトコル（第１のタイプのプロトコル）を実行しない最終端末が使用される状況などの、市販の家庭電化製品を使用した家庭内の他の多くの実際的な例でも使用されてもよい。
【０１０３】
本発明は、サービス提供側が第１のタイプの制御データに基づいて動作するのに対して、端末デバイスが第２のタイプの制御データに基づいて動作する一般的通信システムに、その適用を見いだす。本発明によるゲートウェイ装置ＨｉＧＡは、必要な相互運用性すなわち第１のタイプの制御プレーンと第２のタイプの制御プレーンの適合機能を提供する。第１のタイプがＳＩＰに関連し、第２のタイプがＨＴＴＰに関連する特別な実施例について説明したが、本発明は、第１のタイプと第２のタイプの２つの異なる制御プロトコルを備える他のどの通信システムＳＹＳでも使用し得る。
【０１０４】
さらに、本発明の変更形態および変形形態は、添付の特許請求項の範囲内で実行し得ることに留意すべきである。
【０１０５】
特許請求項の参照番号は、説明目的だけに役立ち、これらの特許請求項の範囲を限定しない。
【図面の簡単な説明】
【０１０６】
【図１ａ】先行技術に従う通信システムＳＹＳの概観図である。
【図１ｂ】先行技術に従い、特定のユーザＩＤに関連する特定の所要のサービスに対する特定の好みを載せている、ユーザプロファイルメモリＵＰ−ＭＥＭ内のユーザプロファイルを示す図である。
【図１ｃ】先行技術に従い、第１のタイプの端末デバイスＴ１が、サーバＩＭＳ−Ｓにパーソナル化された電子プログラム・ガイドＥＰＧ１の形態のパーソナル化されたコンテンツを要求する場合の要求シナリオを示す図である。
【図２ａ】本発明に従う通信システムＳＹＳのブロック図である。
【図２ｂ】パーソナル化された電子プログラム・ガイドＥＰＧに関連して、ＩＰＴＶの提供に関する第１の特定のサービス提供例を示す図である。
【図２ｃ】第２の端末デバイスＴ２の要求制御プロトコルとサーバＩＭＳ−Ｓの制御プロトコルが異なる場合のＭＰＥＧ２ストリームの提供、特にアクセス・ネットワークＡＣに対するリソースＲＥＳのネゴシエーションにも関する第２の特定のサービス提供例を示す図である。
【図２ｄ】ＩＭＳサーバおよびＩＰＴＶサービス提供の特定の場合に対する通信システムＳＹＳおよびゲートウェイデバイスＨｉＧＡのブロック図である。
【図３】本発明の通信方法のフローチャートである。
【図４ａ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するＳＴＢのメディア・セッション初期設定の例示のフローチャートである。
【図４ｂ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するユニキャスト・セッション確立の例示のフローチャートである。
【図４ｃ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するマルチキャスト・セッション確立の例示のフローチャートである。
【図４ｄ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するＥＰＧ更新の例示のフローチャートである。
【図４ｅ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するパーソナル化されたコンテンツのトリガ例を示す図である。
【技術分野】
【０００１】
本発明は、端末デバイスが通信システムのサービス提供サーバの提供するサービスにアクセスし使用することを可能にする通信システム、通信方法およびゲートウェイ装置に関する。
【０００２】
特に本発明は、標準端末デバイスが解決できないアプリケーション固有の属性を有するサービスを、サービス提供サーバが提供する状況に関する。すなわち本発明は、サービス提供サーバが第１のタイプで、通信システムが第１のタイプの端末デバイスと第２のタイプの端末デバイスを備えてもよい状況に関する。第１のタイプの端末デバイスは、第１のタイプのサービス提供サーバが提供するサービスに関係する制御データを理解し解決する。しかし、第１のタイプのサービス提供サーバが提供するアプリケーション固有の属性（サービス固有特性）を有するサービスに関係する第１のタイプの制御データを理解し解決することができない、第２のタイプの端末デバイスもある。
【背景技術】
【０００３】
図１ａは、背景技術および本発明が解決すべき問題を説明するための通信システムＳＹＳ示す。図１ａでは、ホームネットワーク（宅内ネットワーク、Customer Premises Network）ＣＰＮは、相当数の端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮを備える。ホームネットワークＣＰＮは、図１ａでＩＭＳ−Ｎで示すサービスネットワークに接続されていてもよい。ホームネットワークＣＰＮまたは接続されたサービスネットワークＩＭＳ−Ｎには、端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮに例えばＩＭＳタイプの通信サービスではＶｏＩＰ、テレビ会議およびＩＰＴＶなどの特定のサービスを提供するサービス提供サーバＩＭＳ−Ｓが用意されている。
【０００４】
アクセス手順および配信手順は、図１ａではＨｉＧＡで示すゲートウェイ装置が提供する。端末デバイス例えばＴ１からゲートウェイ装置ＨｉＧＡへのアクセスメッセージＡＣに応えて、サービス提供サーバＩＭＳ−Ｓは、ゲートウェイ装置ＨｉＧＡが転送する配信メッセージＤＬを用いて要求されたサービスを配信する。普通、サービス提供サーバＩＭＳ−Ｓと端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮが同じ「タイプ」である場合、たとえサービスがサービスに関係するアプリケーション固有の属性も有していても、サービス提供サーバＩＭＳ−Ｓのサービスへのアクセスおよびその提供（配信）に問題はない。しかし、サービス提供サーバＩＭＳ−Ｓが第１のタイプであり、端末デバイスがサービスに関係する固有の第１のタイプの制御データ（アプリケーション固有の属性）を理解できない第２のタイプである場合、サービス提供サーバＩＭＳ−Ｓが提供するサービスだけは、第２のタイプの端末デバイスに配信されることがあるが、サービスに関係する第１のタイプの制御データは、第２のタイプの端末デバイスで復号され使用される可能性はない。以下ではこの様子をさらに説明するために、ＩＭＳサービスに関連し、図１ｂ、１ｃにも関連するより具体的な例について説明する。
【０００５】
図１a、１ｂ、１ｃの例では、ゲートウェイ装置はＨｉＧＡ（ホームＩＭＳゲートウェイ、Home IMS GAteway）で形成され、端末デバイスＴ１（第１のタイプの端末デバイス）はＳＩＰデバイス（ＳＩＰ：セッション開始プロトコル、Session Initiation Protocol）であり、端末デバイスＴ２（第２のタイプの端末デバイス）は非ＳＩＰデバイスである。前に説明したように、ＨｉＧＡは、ホームネットワークＣＰＮ内に在る機能ブロック（ゲートウェイ）であり、例えば、ＳＩＰ端末デバイスおよび非ＳＩＰ端末デバイスが、サービス提供サーバＩＭＳ−Ｓの提供するＩＭＳベースのサービスにアクセスすることを可能にする。ＩＭＳベースのサービスには、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）およびテレビ会議などの通信サービス、ならびに図１ａにやはり示すＩＰＴＶなどの他のマルチメディアサービスを含んでもよい。
【０００６】
ＩＭＳサービスとして提供される例えばＩＰＴＶの特徴の１つは、エンドユーザに配信されるＴＶコンテンツのパーソナル化、例えばユーザのアイデンティティおよび好みに基づきパーソナル化された広告の配信などを可能にすることである。このために、ＨｉＧＡは、図１ｂに示すユーザプロファイルメモリＵＰ−ＭＥＭにユーザプロファイルを保有する。このようなユーザプロファイルは、例えば図１ｃに示すゲートウェイデバイスＨｉＧＡの交換部分ＥＸに格納されてもよい。ユーザプロファイルは、ＩＭＳサービスアイデンティティに関連するあらゆる登録に対して保有される。例えば、図１ｂに示すように各ユーザ・アイデンティティ（ユーザＩＤ）は、特定の好み（制御情報）およびサービス識別表示ＩＭＳ−ＩＤに関連付けられている。例えば、各個別のユーザにユーザのＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）で異なるＴＶプログラムが入手可能であってもよく、図１ｂに示すように、ＩＤ１＝「父親」／制御情報＝「スポーツ」、ＩＤ２＝「息子」／制御情報＝「映画および子供番組」、およびＩＤｎ＝「母親」／制御情報＝「広告」などが入手可能であってもよい。このような特定の好み（制御情報）が示される場合、ＨｉＧＡは、制御情報を用いてパーソナル化されたやり方で要求されたサービスがユーザ（端末デバイス）に確実に配信されるようにする。
【０００７】
例えば、第１のタイプの端末デバイスＴ１がユーザＩＤ＝ＩＤ２を有するサービス配信要求を送信する場合、ＨｉＧＡは、サービス提供サーバＩＭＳ−Ｓからパーソナル化された電子プログラム・ガイドＥＰＧ２を読み出すべきことを知り、サーバＩＭＳ−ＳにＥＰＧ２の要求を送信する。あるいは、サーバＩＭＳ−Ｓが、図１ｃに示すようにユーザ・アイデンティティＩＤと制御情報ＩＭＳ−ＣＴＲＬとをマッピングするユーザ固有の好みマッピングテーブルを有する場合、第１のタイプの端末デバイスＴ１は、ＨｉＧＡを通してサーバＩＭＳ−ＳにそのユーザＩＤであるＩＤ１（第１のテープの制御情報）を単に送信すれば十分であってもよく、サーバＩＭＳ−Ｓは、提供された第１のタイプ（パーソナル化された、すなわちユーザおよびサービス固有）の制御情報ＥＰＧ１を復号し使用する能力がある第１のタイプの端末デバイスＴ１に、第１のタイプの制御情報（制御データ）を返す。端末デバイスとサーバが同じ（第１のタイプの）制御プロトコルを実行するならば、このやり方で、パーソナル化されたコンテンツは特定の登録、それ故特定のユーザに配信され得る。通常、ＩＭＳサーバＩＭＳ−Ｓを有する通信システムでは、端末デバイスＴ１もサーバＩＭＳ−Ｓも、同じＳＩＰ制御プロトコルを実行し、それ故このプロトコルを使用して互いに「話す」ことができる。
【０００８】
ＨｉＧＡがＳＩＰと非ＳＩＰ（例えば、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ））の両方のホームデバイスにＩＭＳ通信サービスを提供するＩＭＳ−ＳＩＰプロキシ（交換）機能を本質的に提供するのに対して、ＩＭＳシステムすなわちホームネットワークＣＰＮまたは相互接続されたサービスネットワークＩＭＳ−ＮのアプリケーションサーバＩＭＳ−Ｓは、図１ａに示すようにＩＰＴＶ、ＶｏＩＰ、テレビ会議等を含む多数のマルチメディアサービスを提供し、通常このようなＩＭＳサービスは、図１ａに示唆するように異なる第２の制御プロトコルを実行する標準端末デバイスＴ２が使用および理解することのできないアプリケーション（サービス）固有の属性（制御情報）を有することができよう。例えばＩＰＴＶサービスは、ＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）およびサービストリガなどのアプリケーション固有の属性を有してもよい。ＶｏＩＰサービスは、特定の広告または音楽に関して特定の属性を有してもよい。終端デバイスもＩＭＳベースの端末デバイスである場合、もちろん（第１のタイプのＳＩＰ）端末デバイスＴ１にこのサービスに関係するアプリケーション（サービス）固有の属性を配信することに問題はない。しかし、端末デバイスが異なるタイプ（第２のタイプ）すなわち非ＩＭＳベースである場合は問題がある。この場合、このＩＭＳベースのサービスに関係するアプリケーション固有の属性（制御情報）を、非ＩＭＳベースの第２のタイプの端末デバイスＴ２の制御プロトコルが「理解」できないからである。この問題は、サーバＩＭＳ−Ｓからのパーソナル化されたコンテンツのより高度な提供に関連するだけでなく、簡単な要求シナリオにさえ関連する。
【０００９】
例えば第１の端末デバイスＴ１は、サービス・プロセッサＳＰ（ＭＰＥＧ２デコーダ）を用いて、配信されたＭＰＥＧ２ストリームを復号する能力があってもよい。しかし第１の端末デバイスＴ１は、このＭＰＥＧ２サービスをサーバＩＭＳ−Ｓに要求するためにＨＴＴＰ（第１のタイプ）の制御プロトコルを使用してもよい。サーバＩＭＳ−Ｓが第２の制御プロトコル例えばＳＩＰを実行する場合、ＩＭＳ ＳＩＰをサポートしていない第１の端末デバイスは、ＨＴＴＰ要求を使用してサーバＩＭＳ−Ｓのメディアにアクセスすることはできない。別の例は、第１の端末デバイスＴ１がアクセス・ネットワークのある帯域幅（あるリソース）を必要とするサービス、例えばビデオストリーミングを要求する場合に、アクセス・ネットワークが必要なリソースを提供できない場合である。第１の制御プロトコルと第２の制御プロトコルは異なるので、端末デバイスは、例えば、ある程度狭い帯域幅でも例えばより低い品質のビデオストリーミングには許容し得ることを、サーバＩＭＳ−Ｓとネゴシエートするなどの能力がないだろう。
【００１０】
例えば簡単な標準セット・トップ・ボックスＳＴＢなどの多くの市販の端末デバイスＴ２は、デバイスに固有のユーザＩＤを割り当てられておらず、簡単な要求メッセージを実行しており、復号またはサービスの実行だけができるが、ユーザ固有の特性を少しも提供できない。すなわち、それらは、「ユーザを認識できず」、ユーザに無関係なやり方でサービスを単に実行する。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
これまで説明したように、サーバＩＭＳの制御プロトコルと第２のタイプの端末デバイスＴ２の制御プロトコルとは異なるので、第２のタイプの端末デバイスＴ２の中には、提供されるサービスに関係する第１のタイプの制御情報（制御データ）をサーバＩＭＳ−Ｓと交換できないものがあるという問題がある。
【００１２】
それ故、本発明の目的は、第１のタイプのサービス提供サーバが提供する第１のタイプの制御情報に関係して、第２のタイプの制御プロトコルを実行する第２のタイプの端末デバイスが、サービスを実行することを可能にする通信システム、通信方法およびゲートウェイ装置を提供することである。
【課題を解決するための手段】
【００１３】
本目的は、ゲートウェイ装置と、複数の端末デバイスと、これらの端末デバイスにアクセス・ネットワークを通してサービスを提供するサービス提供サーバとを備える通信システムによって解決され、前述のサービス提供サーバは、前述の端末デバイスに提供する１つ以上のサービスを格納するサービスメモリと、前述の１つ以上のサービスに関係する第１のタイプの制御データを前述のゲートウェイデバイスに提供する少なくとも１つの第１のタイプの制御プロトコル・デバイスとを備え、前述の端末デバイスのそれぞれは、前述のサービス提供サーバから前述のアクセス・ネットワークを通して提供されたサービスを処理するサービス・プロセッサと、前述のサービス・プロセッサによるサービスの実行に関係して、前述の第１のタイプとは異なる第２のタイプの制御データを前述のゲートウェイデバイスに提供する第２のタイプの制御プロトコル・デバイスとを備え、前述のゲートウェイ装置は、第１のタイプの制御データを前述のサービス提供サーバと交換し、第２のタイプの制御データを前述の端末デバイスと交換する１つ以上のサービス固有マッピング・デバイスを備え、前述のサービス固有マッピング・デバイスは、前述の端末デバイスから受信した第２のタイプの制御データに基づいて、第１のタイプの制御データを前述のサービス提供サーバに提供し、サービス提供サーバの前述の第１のタイプの制御プロトコル・デバイスから第１のタイプの制御データを受信し、前述のサービス固有マッピング・デバイスは、前述のサービス提供サーバから受信した前述の第１のタイプの制御データに基づいて、第２のタイプの制御データを前述の端末デバイスに提供し、前述の端末デバイスの前述の第２のタイプの制御プロトコル・デバイスから前述の第２のタイプの制御データを受信する。
【００１４】
さらに本目的は、複数の端末デバイスと、これらの端末デバイスにアクセス・ネットワークを通してサービスを提供するサービス提供サーバとを有する通信システムのゲートウェイ装置によって解決され、前述のサービス提供サーバは、前述の端末デバイスに提供する１つ以上のサービスを格納するサービスメモリと、前述の１つ以上のサービスに関係する第１のタイプの制御データを前述のゲートウェイデバイスに提供する少なくとも１つの第１のタイプの制御プロトコル・デバイスとを備え、前述の端末デバイスのそれぞれは、前述のサービス提供サーバから前述のアクセス・ネットワークを通して提供されたサービスを処理するサービス・プロセッサと、前述のサービス・プロセッサによるサービスの実行に関係して、第１のタイプの制御データを前述のサービス提供サーバと交換し、第２のタイプの制御データを前述の第２のタイプの端末デバイスと交換する１つ以上のサービス固有マッピング・デバイスを備える前述のゲートウェイデバイスに、前述の第１のタイプとは異なる第２のタイプの制御データを提供する第２のタイプの制御プロトコル・デバイスとを備え、前述のサービス固有マッピング・デバイスは、前述の端末デバイスから受信した第２のタイプの制御データに基づいて、第１のタイプの制御データを前述のサービス提供サーバに提供し、サービス提供サーバの前述の第１のタイプの制御プロトコル・デバイスから第１のタイプの制御データを受信し、前述のサービス固有マッピング・デバイスは、前述のサービス提供サーバから受信した前述の第１のタイプの制御データに基づいて、第２のタイプの制御データを前述の端末デバイスに提供し、前述の端末デバイスの前述の第２のタイプの制御プロトコル・デバイスから前述の第２のタイプの制御データを受信する。
【００１５】
さらに本目的は、ゲートウェイ装置と複数の端末デバイスとこれらの端末デバイスにアクセス・ネットワークを通してサービスを提供する通信システムのサービス提供サーバとの間の通信方法によって解決され、前述のサービス提供サーバは、前述の端末デバイスに提供する１つ以上のサービスを格納するサービスメモリと、前述の１つ以上のサービスに関係して前述のゲートウェイデバイスに第１のタイプの制御データを提供する少なくとも１つの第１のタイプの制御プロトコル・デバイスとを備え、前述の端末デバイスのそれぞれは、前述のサービス提供サーバから前述のアクセス・ネットワークを通して提供されたサービスを処理するサービス・プロセッサと、前述のサービス・プロセッサによるサービスの実行に関係して、前述の第１のタイプとは異なる第２のタイプの制御データを有する第２のタイプの制御プロトコル・デバイスとを備え、前述のゲートウェイ装置は、第１のタイプの制御データ（１ＣＤ）を前述のサービス提供サーバと交換し、第２のタイプの制御データを前述の端末デバイスと交換する１つ以上のサービス固有マッピング・デバイスを備え、方法は以下の、前述の端末デバイスの少なくとも１つから前述のゲートウェイ装置に第２のタイプの制御データを提供する工程と、前述のゲートウェイ装置の前述のサービス固有マッピング・デバイスから前述のサービス提供サーバに、前述の端末デバイスから提供された前述の第２のタイプの制御データに基づいて第１のタイプの制御データを提供する工程と、前述のサービス提供サーバの前述の第１のタイプの制御プロトコル・デバイスから前述のゲートウェイ装置に第１のタイプの制御データを提供する工程と、前述のサービス固有マッピング・デバイスから前述の端末デバイスに、前述のサービス提供サーバから提供された前述の第１のタイプの制御データに基づいて第２のタイプの制御データを提供する工程とを備える。
【００１６】
本発明によれば、例えばＩＭＳベースのアプリケーション（通信）サーバと非ＩＭＳ端末（ホーム）デバイスとの間に、必要なゲートウェイ機能を提供する例えばＨｉＧＡゲートウェイデバイスなどにサービス固有の特性があることには、特別な利点がある。これをもとにして、標準端末デバイスも、ある種のパーソナル化された制御情報を提供されてもよい。
【００１７】
好ましくは、前述のサービス固有マッピング・デバイスは、ＩＰＴＶプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイスを備える。
【００１８】
さらに好ましくは、前述の第２のタイプの制御データは、第２のタイプのサービス要求を構成し、前述のサービス固有マッピング・デバイスは、第１のタイプの制御データとして、前述のアクセス・ネットワークが前述のサービスを端末デバイスに提供するために十分なリソースを有するかどうかをサービス提供サーバに問い合わせる第１のタイプの問い合わせ要求を送信し、前述のサービス提供サーバは、サービス提供サービスが十分なリソースがあることを確かめた場合、サービス提供のために十分なリソースがあることを示す肯定応答メッセージを第１のタイプの制御データとして送信し、サービス提供サーバが十分なリソースがないことを確かめた場合、サービス提供のために十分なリソースがないことを示す否定応答メッセージを第１のタイプの制御データとして送信する。
【００１９】
さらに好ましくは、前述の端末デバイスは、サービス・プロセッサとしてＭＰＥＧ２デコーダを有するセット・トップ・ボックスを備え、前述のサービス提供サーバは、前述のサービスメモリの中にサービスとしてＶｏＤ（ビデオオンデマンド、Video on Demand）サービスを備え、前述のサービス固有マッピング・デバイスは、ＲＴＳＰプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイスを備え、前述の制御プロトコルはＲＴＳＰであり、前述のリソースは前述のアクセス・ネットワークの回線の帯域幅である。
【００２０】
さらに好ましくは、前述のゲートウェイ装置および前述の端末デバイスは、宅内ネットワークの一部である。
【００２１】
さらに好ましくは、前述のゲートウェイ装置は、前述の宅内ネットワークのレジデンシャル・ゲートウェイの中に設置される。
【００２２】
さらに好ましくは、前述のゲートウェイ装置は、前述の端末デバイスから前述の第２のタイプの第１の制御データとしてＥＰＧダウンロード要求を受信し、前述のゲートウェイ装置が提供する前述の第２のタイプの制御データはパーソナル化されたＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）を備える。
【００２３】
さらに好ましくは、前述のゲートウェイ装置は、メモリの中に前述のユーザ・アイデンティティを備える。
【００２４】
さらに好ましくは、前述のユーザ・アイデンティティは、前述のゲートウェイ装置に挿入されたプラグインまたは前述のゲートウェイ装置のメモリの中に挿入されたＵＩＣＣカードに格納される。
【００２５】
さらに好ましくは、前述の端末デバイスは、セット・トップ・ボックス、暖房システム制御装置、住宅監視システム、カメラ、またはインテリジェントハウスの中央住宅制御装置を含むグループから選択された１つ以上のものである。
【００２６】
さらに好ましくは、前述の制御データの前述の第１のタイプはＳＩＰ（セッション開始プロトコル、Session Initiation Protocol）であり、前述の制御データの前述の第２のタイプは、ＨＴＴＰかまたはＵＰｎＰのどちらかである。
【００２７】
さらに好ましくは、前述のゲートウェイ装置は、前述のサービス提供デバイスから第１のタイプの制御データとして前述のダウンロードされる第１のタイプのＥＰＧを受信し、前述の受信したＥＰＧのフォーマットを前述の端末デバイスがサポートするフォーマットに変換する。
【００２８】
さらに好ましくは、前述のゲートウェイ装置は、端末デバイスと前述のサービス提供デバイスとの間のメディア・セッション確立を呼びかける。
【００２９】
さらに好ましくは、前述のメディア・セッション確立はユニキャスト・メディア・セッション確立である。
【００３０】
さらに好ましくは、前述のメディア・セッション確立は、マルチキャスト・メディア・セッション確立である。
【００３１】
さらに好ましくは、前述のゲートウェイ装置は、第１のタイプの制御データとしてＥＰＧ更新メッセージを受信する。
【００３２】
さらに好ましくは、前述のゲートウェイ装置は、第１のタイプの制御データとしてイベント・トリガ・メッセージを受信し、前述のイベント・トリガ・メッセージに基づいて第２のタイプの制御データとして、メディア・セッション確立メッセージを前述の端末デバイスに送信する。
【００３３】
本発明のさらに有利な実施形態および改善については、従属請求項に挙げている。しかし本発明は、請求項、図面および明細書に個別に記載している特徴および工程も備えることに留意すべきである。それ故、本発明は、このような特徴および工程の組み合わせに基づく実施形態も備える。
【００３４】
以下では、本発明について図面を参照して説明する。
【発明を実施するための最良の形態】
【００３５】
以下では、まず本発明の原理について、本発明に従う通信システムＳＹＳのブロック図である図２ａを参照して説明する。通信システムＳＹＳは、ゲートウェイ装置ＨｉＧＡと、複数の端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮと、これらの端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮにアクセス・ネットワークＡＣを通してサービスＳＥＲＶを提供するサービス提供サーバＩＭＳ−Ｓとを備える。
【００３６】
図２ａに示すように、サービス提供サーバＩＭＳ−Ｓは、前述の端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮに提供する１つ以上のサービスＳＥＲ１、ＳＥＲ２、ＳＥＲ３を格納するサービスメモリＳＥＲＭを備える。サーバＩＭＳ−Ｓは、図２ａではＨｉＧＡに単純に接続されているように示されているが、図１ａに示すように別個のサービス提供ネットワークＩＭＳ−Ｎにも配置されてもよい。サービス提供サーバＩＭＳ−Ｓは、制御プロトコル・デバイスが提供する制御プロトコルＩＭＳ−ＣＴＲＬＰを実行する。制御プロトコルの一例はＳＩＰである。このタイプのプロトコルは、「第１のタイプ」のプロトコルと呼び、１つ以上のサービスＳＥＲＶに「関係して」第１のタイプのＳＩＰ制御データＣＳを提供する。サービスメモリＳＥＲＭの中の各サービスは、独自の制御プロトコルを有してもよいし、また全サービスに対して１つの制御プロトコルが提供されてもよい。サービスは、既に図１ａに示し上記したように、例えばＩＰＴＶ提供(IPTV provision)（ＭＰＥＧ２ストリーム提供）、ＶｏＩＰサービス、テレビ会議、ＩＰＴＶでもよい。制御プロトコルの１つはＳＩＰでもよいが、他の制御プロトコルも使用されてもよい。
【００３７】
「関係して」の意味は、以下でさらに詳細を説明する図２ｂの実施例を参照して理解されてもよい。ここでは、サービスはＩＰＴＶであり、制御データ（第１のタイプの制御データ）は、ユーザ固有の電子プログラム・ガイドＥＰＧ１、ＥＰＧ２、…ＥＰＧｎである。しかし、第１のタイプの制御データまたは制御情報は、特定のサービス、ＩＰＴＶに関連するＨＴＭＬページの提供等を実行するための単なるトリガでもよい。それ故、制御プロトコルは、どことなく１つ以上の特定のサービスに「関係」または「関連」している。サービスは、図２ａに示すように、リンクＤＬを通してまたはアクセス・ネットワークＡＣを用いて、第２のタイプの端末デバイスＴ２に直接提供されてもよい。あるいは、サービスの提供を、ゲートウェイ装置ＨｉＧＡ自体を通るように経路指定する実行可能手段もある。
【００３８】
図２ａでは、端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮは、第１のタイプの端末デバイスＴ１、Ｔｎと第２のタイプの端末デバイスＴ２とを備え、これらの端末デバイスＴ１、Ｔ２、…Ｔｎ…ＴＮのそれぞれは、前述のサービス提供サーバＩＭＳ−Ｓから前述のアクセス・ネットワークＡＣまたは前述のダイレクトリンクＤＬを通して提供されるサービスＳＥＲＶを処理するサービス・プロセッサＳＰを備える。第１のタイプの端末デバイスＴ１、Ｔｎは、このサービス・プロセッサＳＰによるサービスの実行に関係して、第１のタイプの制御データを前述のゲートウェイデバイスＨｉＧＡに提供する第１のタイプの制御プロトコル・デバイスを備えるのに対して、第２のタイプの端末デバイスＴ２は、このサービス・プロセッサＳＰによるサービスの実行に関係して、前述の第１のタイプとは異なる第２のタイプの制御データを前述のゲートウェイデバイスＨｉＧＡに提供する第２のタイプの制御プロトコル・デバイスを備える。この意味することは、第１のタイプの端末デバイスＴ１、Ｔｎは、図１ｃに示すように、サーバＩＭＳ−Ｓと直接実行および通信できることである。
【００３９】
例えば、第１のタイプの端末デバイスＴ１、Ｔｎは、第１のタイプの制御プロトコルに属する制御データの１つであるユーザ・アイデンティティ特性を備えてもよい。他方、第２のタイプの端末デバイスは、例えばＭＰＥＧ２ストリームなどを実行するサービス・プロセッサＳＰを単に備える標準セット・トップ・ボックスＳＴＢでもよい。それ故そのようなものとして、第２のタイプの端末デバイスは第２のタイプのある種の制御データだけを理解するが、サーバＩＭＳ−Ｓの第１のタイプの制御プロトコルからもたらされる第１のタイプの制御情報のどれも「理解しない」だろう。この意味することは、第２のタイプの端末デバイスＴ２は、第１のタイプの制御情報のどれも理解しないことである。例えば、第２の端末デバイスＴ２が単なるセット・トップ・ボックスＳＴＢである場合、ただＴＶサービスを実行するが、制御データとしてパーソナル化された電子プログラム・ガイドを要求する能力または提供される能力を持たない。
【００４０】
図２ａでは、ゲートウェイ装置ＨｉＧＡが第１のタイプの端末Ｔ１、Ｔｎと第２のタイプの端末Ｔ２の両方と通信しているように、通信システムＳＹＳが描かれているが、本発明は、第２のタイプの端末Ｔ２すなわちサービス提供サーバが使用するプロトコルとは異なるプロトコル（デバイス）を使用して動作する端末と通信するために、ＨｉＧＡで必要なそれらの機能に専念することは、理解されるべきである。第１のタイプの端末との通信のためには、第１のタイプの端末がサービス提供サーバと同じプロトコルを実行するので、明らかに本発明の特別の機能は必要ない。
【００４１】
ゲートウェイ装置ＨｉＧＡは、図１ｃまたは１ａと同様に配置され、すなわち、サーバＩＭＳ−Ｓと端末デバイスＴ１、Ｔｎ、Ｔ２との間の一種のプロキシの機能を果たす。しかし本発明に従い、図２ａに示すように、ゲートウェイ装置ＨｉＧＡは、非ＩＭＳホームデバイス上で動作するサービス固有アプリケーションとＩＭＳアプリケーションサーバが提供するサービスとの間の一種のサービス分離層(service abstraction layer)を備える。ゲートウェイ装置ＨｉＧＡのこのアプリケーションスペースＡＳは、１つ以上のサービス固有マッピング・デバイスＡＳ−Ａを備える。この種のアプリケーションスペースは、様々なタイプのサービス固有アプリケーションに対する共通アプリケーション実行環境であることを意図している。アプリケーションスペースのサービス固有アプリケーションは、本質的に、サービス固有制御プレーンを目標の第２の端末デバイスＴ２の固有の制御プレーンに適応させる。アプリケーションスペースは、様々なデバイス（機能セット）およびプロトコルをサポートするプラグインが設置される環境であると言ってもよい。それ故、サーバＩＭＳ−Ｓが提供するサービスＳＥＲＶのそれぞれに対して、ゲートウェイ装置ＨｉＧＡは、サービス固有マッピング・デバイスＡＳ−Ａを備える。
【００４２】
図２ａでは、一実施例としてＩＰＴＶマッピング・デバイスを示す。上に述べたようにゲートウェイデバイスＨｉＧＡは、ＨｉＧＡを本拠地とするアプリケーション固有ロジックのサポートを引き受ける。制御プレーンは、これを第２のタイプの端末デバイスＴ２の固有の制御プレーンにマッピングする機能を有するゲートウェイ装置ＨｉＧＡに終わる。従って、ゲートウェイ装置ＨｉＧＡは、第２の端末デバイスＴ２へのＩＰＴＶサーバプロキシの機能を果たす。ゲートウェイ装置ＨｉＧＡのアプリケーションスペースＡＳは、図２ａに示すようにＩＰＴＶアプリケーションの場合、ＩＭＳ ＩＰＴＶ ＡＳからのアプリケーション固有データを終端するモジュールの収納場所である。図２ａにやはり示すように、ＩＭＳコンテンツサーバＩＭＳ−Ｓからのメディアプレーンは、前に説明したように第２の端末デバイスＴ２に個別に直接終端される。
【００４３】
ゲートウェイ装置ＨｉＧＡは、機能上レジデンシャル・ゲートウェイまたはマスタＳＴＢ（Ｍ ＳＴＢ）に配置できよう。マスタＳＴＢ（Ｍ ＳＴＢ）は、複数のＳＴＢ（スレーブＳＴＢ）のためにＩＭＳ制御プレーンを取り扱う１つのマスタデバイスに接続されるホーム環境の複数のＳＴＢ（スレーブＳＴＢ）の存在を可能にする。ＩＰＴＶアプリケーション環境を考慮すると、一般的に第２の端末デバイスＴ２は、標準セット・トップ・ボックスＳＴＢでもよく、ゲートウェイデバイスＨｉＧＡは、同じ住宅またはレジデンシャル・ゲートウェイに配置されてもよい。
【００４４】
好ましくは、ユーザ・アイデンティティは、ＨｉＧＡのメモリに前もって格納されたほうがよく、このようにしてＩＭＳサーバに提示されたほうがよい。例えば、ユーザＩＤを有する一般携帯電話カード（ＵＩＣＣすなわち汎用ＩＣカード、Universal Integrated Circuit Card）がＨｉＧＡに提示されてもよい。このカードは、ＵＳＩＭまたはＩＳＩＭなどの相当数のアプリケーションを収容する(host)ことができよう。従って、ユーザ・アイデンティティは、携帯電話の加入に関係する一意の番号であり、「携帯電話カード」上で動作するＵＳＩＭ部分の一部であるＩＭＳＩでもやはりよい。また、スマートカードを有するＳＴＢのような最新のデバイスにおいてまさに見られるように、スマートカードが挿入されてもよい。さらに図１ｂに示すように、ＨｉＧＡは、ユーザプロファイルメモリＵＰ−ＭＥＭの中のユーザプロファイルを保有してもよい。このようなユーザプロファイルは、例えば図１ｃに示すゲートウェイデバイスＨｉＧＡの交換部分ＥＸなどに格納されてもよい。ユーザプロファイルは、ＩＭＳサービスアイデンティティに関連するあらゆる登録に対して保有されてもよい。例えば、図１ｂに示すように各ユーザ・アイデンティティ（ユーザＩＤ）は、特定の好み（制御情報）およびサービス識別表示ＩＭＳ−ＩＤに関連付けられている。例えば、各個別のユーザにユーザのＥＰＧ（電子プログラム・ガイド、Electronic Program Guide）で異なるＴＶプログラムが入手可能であってもよく、図１ｂに示すように、ＩＤ１＝「父親」／制御情報＝「スポーツ」、ＩＤ２＝「息子」／制御情報＝「映画および子供番組」、およびＩＤｎ＝「母親」／制御情報＝「広告」などである。このような特定の好み（制御情報）が示される場合、ＨｉＧＡは、制御情報を用いてパーソナル化されたやり方で要求されたサービスがユーザ（端末デバイス）に確実に配信されるようにする。
【００４５】
以下では、サービス固有マッピング・デバイスＡＳ−Ａ（提供される各サービスに対して１つ）を有するアプリケーションスペースＡＳについて、さらに詳細に説明する。図２ａに示すように、マッピング・デバイスＡＳ−Ａの主な機能は、第１のタイプ（例えばＳＩＰ）の制御データをサービス提供サーバＩＭＳ−Ｓとを交換し、第２のタイプ（例えば非ＳＩＰ）の制御データを前述の第２のタイプ（例えば非ＳＩＰ）の端末デバイスＴ２と交換することである。すなわちＨｉＧＡは、第２の端末デバイスＴ２のプロキシとして働き、第１のタイプのサーバ制御プロトコルを使用してサーバＩＭＳ−Ｓと通信し、第２のタイプの制御データを使用して第２の端末デバイスＴ２と通信する。一実施例がこれを説明するはずである。
【００４６】
第２の端末デバイスＴ２は標準セット・トップ・ボックスＳＴＢであると、例えば想定する。標準セット・トップ・ボックスＳＴＢは、例えばサービス・プロセッサ内のＭＰＥＧ２デコーダを用いてＭＰＥＧ２ストリームなどを、実行する能力を有するだろう。標準セット・トップ・ボックスＳＴＢは、ＭＰＥＧ２ストリームまたはＩＰＴＶサービスの実行または要求をするための簡単な要求の作成だけを備えてもよい簡単な「第１のタイプ」の制御プロトコルも有してもよい。さらにＳＴＢは、一般用の電子プログラム・ガイドＥＰＧも受信し得るが、ユーザ固有のやり方でそれを受信したり要求したりできない。ユーザ固有の機能は、ＳＴＢに対するプロキシとして働くＨｉＧＡに受け継がれている。ＨｉＧＡは、ユーザ固有の制御情報例えばパーソナル化された電子プログラム・ガイドＥＰＧを要求し得るし、提供され得る。
【００４７】
ＩＭＳ−Ｓサーバの第１のタイプの制御データと第２の端末デバイスＴ２の第２のタイプの制御データとの「交換」は、第１のタイプの制御情報と第２のタイプの制御情報との間の相互関係またはマッピングも有する。より具体的には、サービス固有マッピング・デバイスＡＳは、前述の第２のタイプの端末デバイスＴ２から受信した第２のタイプすなわち非ＳＩＰの制御データに基づいて、第１のタイプのＳＩＰ制御データをサービス提供サーバＩＭＳ−Ｓに提供し、前述の第１のタイプの制御プロトコル・デバイスＩＭＳ−ＣＴＲＬＰから第１のタイプの制御データを受信する。サービス固有マッピング・デバイスＡＳ−Ａは、それとは反対に、前述のサービス提供サーバＩＭＳ−Ｓから受信した前述の第１のタイプの制御データに基づいて、第２のタイプすなわち非ＳＩＰの制御データを前述の第２のタイプの端末デバイスＴ２に提供し、第２の端末デバイスＴ２の前述の第２のタイプの制御プロトコル・デバイスＴＤ−ＣＰから第２のタイプの制御データを受信する。
【００４８】
従って、端末デバイスＴ２からＩＭＳ−Ｓサーバへの上り方向では、ＨｉＧＡが提供する第１のタイプの制御データは、端末デバイスＴ２から受信した第２のタイプの制御データに基づいていると言ってもよい。それとは反対に、「下り」方向例えばサーバＩＭＳ−Ｓから第２の端末デバイスＴ２では、ＨｉＧＡデバイスが第２の端末デバイスＴ２に提供する第２のタイプの制御データは、サーバＩＭＳ−Ｓから受信した第１のタイプの制御データに基づいている。この関連付け、すなわち「基づく」または第１のタイプの制御データと第２のタイプの制御データの相互関係は、ゲートウェイ装置ＨｉＧＡによって実行されるが、一種の「マッピング」と見なしてもよく、それ故デバイスＡＳ−ＡおよびゲートウェイデバイスＨｉＧＡを、「マッピング・デバイス」と呼ぶ。図２ｂと図２ｃの２つの簡単な実施例は、制御プレーン適合に関する「マッピング」機能をさらに強調するだろう。
【００４９】
図３は、図２ａを参照して上に説明したようにホームネットワークのゲート装置ＨｉＧＡを使用した、本発明の通信方法に従う一実施形態のフローチャートを示す。図３のフローチャートに示すように、一般にＨｉＧＡ内のアプリケーションスペースは、サーバサイドＩＭＳ−Ｓとゲートウェイ装置ＨｉＧＡとの間で、第１のタイプの制御メッセージ１ＣＤを交換するのに対して、第２のタイプの制御メッセージ２ＣＤは、第２のタイプの端末デバイスＴ２とゲートウェイ装置ＨｉＧＡとの間で交換される。
【００５０】
特に、ステップ１：２ＣＤ１で示すように、制御メッセージは、第２のタイプの端末デバイスＴ２からＨｉＧＡに発行されてもよい。メッセージはＨｉＧＡで受信され、ステップ２：１ＣＤ１で第１のタイプの関係する（マッピングされた）要求メッセージが、ＨｉＧＡからサーバサイドＩＭＳ−Ｓに送信される。このメッセージ１ＣＤ１は、上に説明したように、要求メッセージ２ＣＤ１に基づく。例えば、以下で説明するように制御メッセージは、その制御フォーマットまたは制御タイプを適応もしくは変換されてもよい（例えば図４ａのＥＰＧフォーマットのＥＰＧ変換などを参照）。
【００５１】
同様に、ステップ３：１ＣＤ２でＩＭＳ−ＳサーバサイドからＨｉＧＡへ第１のタイプの制御メッセージを送信するとき、ステップ４：２ＣＤ２で第１のメッセージ１ＣＤ２に基づく対応または関係するメッセージが第２の端末デバイスＴ２に提供されてもよい。このようにして、サーバサイドＩＭＳ−ＳとＨｉＧＡとの間の第１のタイプのそれぞれのメッセージ１ＣＤは、ＨｉＧＡと第２の端末デバイスＴ２との間の第２のタイプのメッセージ２ＣＤにそれぞれ基づいている。
【００５２】
図２ａを参照して上に説明したように、ＨｉＧＡの提供、特にＨｉＧＡの中の固有サービスに関連するプロキシ・アプリケーション（サービス固有マッピング・デバイス）の提供により、第２のタイプの市販の標準端末デバイスＴ２が普通は第１のタイプの端末デバイスによってだけ実行できるだろう機能を引き受けることを可能にする。
【００５３】
図２ｂの実施例は、第１の端末デバイスが第１のタイプのサーバＩＭＳ−Ｓと通信しているところを描いている図１ｃに示す実施例に関連する。まさに図１ｃに見られるように、図２ｂは、サービス例としてＩＭＳ−ＳサーバのＩＰＴＶサービスを備える。図２ｂは、第１のタイプの制御情報として、ユーザ・アイデンティティＩＤ１、ＩＤ２、…ＩＤｎに関係するパーソナル化された電子プログラム・ガイドＥＰＧ１、ＥＰＧ２、ＥＰＧ３の例も備える。ゲートウェイ装置ＨｉＧＡは、アイデンティティＩＤ１を有するユーザの例えば住宅に設置されるかまたはアイデンティティＩＤ１を有するユーザプラグインを有するので、ゲートウェイ装置ＨｉＧＡ、より具体的にはＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＩＰＴＶ）を実行するサービス固有マッピング・デバイスは、ユーザ固有の要求（制御情報）をサーバＩＭＳ−Ｓに提供し得る。
【００５４】
端末デバイスＴ２には、ＩＰＴＶサービスを実行するサービス・プロセッサＳＰと、ゲートウェイ装置ＨｉＧＡに要求メッセージ２ＣＤ１としてＥＰＧ要求を単に出力するＥＰＧ要求デバイスＣＰとがある。従って、端末デバイスＴ２は、電子プログラム・ガイドＥＰＧを要求でき、返信メッセージ２ＣＤ２でＥＰＧ情報を提供されるだろう。しかし、端末デバイスＴ２は、ユーザにパーソナル化された制御データを理解できないで、ＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＩＰＴＶ）を実行するマッピング・デバイスの仲介（プロキシ）によってパーソナル化されていることを知らないまま、単に電子プログラム・ガイドＥＰＧを受け入れるだろう。すなわち、ＥＰＧの要求メッセージを受信後、ＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＩＰＴＶ）を実行するマッピング・デバイスは、ゲートウェイ装置ＨｉＧＡまたはユーザ固有のプラグインから挿入されたユーザ・アイデンティティＩＤ１を有する要求メッセージ１ＣＤ１を送信することにより、ＩＤ１のユーザＩＤを有するユーザに対するパーソナル化されたＥＰＧ情報の要求を生成する。従って、要求メッセージ１ＣＤ１（制御情報要求メッセージ）は要求メッセージ２ＣＤ１に基づいていると言ってもよい。要求メッセージ１ＣＤ１（制御情報要求メッセージ）は、まだ概ねＥＰＧ情報要求に関連しており、ユーザ・アイデンティティＩＤ１で品質向上または補足されたよりユーザ固有のやり方になっているだけだからである。
【００５５】
１ＣＤ１に基づいて、サーバＩＭＳ−Ｓは、返信メッセージ１ＣＤ２の中でユーザにパーソナル化された電子プログラム・ガイド情報ＥＰＧ１を返すだろう。第２の端末デバイスＴ２は、返信メッセージ２ＣＤ２の中で返される電子プログラム・ガイド情報ＥＰＧがユーザ固有の電子プログラム・ガイド情報ＥＰＧ１であるとは知らないが、実のところＴ２に提供される電子プログラム・ガイド情報は、確かにユーザにパーソナル化されている。電子プログラム・ガイド情報は、ＨｉＧＡプロキシからＩＭＳ−Ｓサーバにユーザにパーソナル化されたやり方で要求されており、ユーザ固有のやり方でＨｉＧＡに返されたからである。従って、返信メッセージ２ＣＤ２内の返信情報ＥＰＧ１も、電子プログラム・ガイドＥＰＧ１を有する返信メッセージ１ＣＤ２に「基づき」または「相互関係」があり、すなわちマッピングされている。従って、図２ｂの通信シナリオは、それぞれ互いに「基づいて」いる第１のタイプの制御情報と第２のタイプの制御情報の交換を備える。
【００５６】
図２ｃは、ＭＰＥＧ２サービスストリーム提供の実施例に関するマッピング・デバイスの「マッピング機能」の別の例を示す。図２ｃでは、ＭＰＥＧ２ストリームは、サービス・プロセッサＳＰ内のＭＰＥＧ２デコーダによって復号される。図２ｃでは、返信メッセージ２ＣＤ２および１ＣＤ２は、肯定応答ＡＣＫの提供にしか過ぎない。しかし、図２ｃに示すように、第２の端末デバイスＴ２が実行するプロトコルとＩＭＳ−Ｓサーバが実行するプロトコルとは異なる、すなわちサービスプロバイダＩＭＳ−ＳからＭＰＥＧ２サービスを提供してもらうための要求メッセージ２ＣＤ１はＨＴＴＰ要求またはＲＴＳＰ要求であるのに対して、ゲートウェイ装置ＨｉＧＡが発行する要求は、メッセージ１ＣＤ１内のＳＩＰ要求である。従って、図２ｃにおいても、要求メッセージ１ＣＤ１は、メッセージ２ＣＤ１のＨＴＴＰ要求に「基づいて」いる。同様に、返信メッセージ１ＣＤ２（簡単な肯定応答ＡＣＫ）はＳＩＰ肯定応答メッセージであり、ＨＴＴＰ肯定応答メッセージである肯定応答メッセージ２ＣＤ２は、ＳＩＰ肯定応答メッセージ１ＣＤ２に「基づいて」いる。従ってこの場合、例えばＩＰＴＶプロキシ・アプリケーションＡＳ−Ａ（ＭＰＥＧ２）などを実行するマッピング・デバイスは、サーバＩＭＳ−Ｓと第２の端末デバイスＴ２との異なる制御プレーン間の要求メッセージおよび肯定応答メッセージを単に「マッピング」する。
【００５７】
図２ｃは、特定のサービス提供の要求を第２のタイプのＨＴＴＰ端末デバイスＴ２が行う場合、サービス固有のマッピング・デバイスが、リソース要求をサーバＩＭＳ−Ｓとネゴシエートするために、プロキシ・アプリケーションを実行する別の実施例も示す。この実施例は、ＶｏＤ（ビデオオンデマンド）サービスにアクセスし、第２の端末Ｔ２がセット・トップ・ボックスＳＴＢで構成されている場合に関する。（図２ｃの括弧で示すように）セット・トップ・ボックスＳＴＢは、ＲＴＳＰプロトコルを使用してＶｏＤサーバとメディア・セッションを開始している。図１ｃまたは図２ａに示すように、実際のビデオストリーミングは、直通回線ＤＬまたはアクセス・ネットワークＡＣを通して提供されてもよい。重要な側面は、セット・トップ・ボックスに要求されたストリームを配信するために十分なリソースＲＥＳ（例えば、帯域幅）を、アクセス・ネットワークが有するべきことである。サーバＩＭＳ−Ｓの一般的機能は、終端デバイスが必要とするリソースＲＥＳとアクセス・ネットワークＡＣで利用可能なリソースＲＥＳとをネゴシエートできることである。従ってＩＭＳ−Ｓサーバは、一般にＱｏＳ（サービス品質、Quality of Service）プロビジョニングを可能にする。しかし、図１ａ、１ｂ、１ｃの先行技術を参照して説明したように、市販のセット・トップ・ボックスＳＴＢは、このようなリソースＲＥＳをＩＭＳ−Ｓサーバとネゴシエートする能力を持たない。
【００５８】
しかし、図２ｃに示すようにゲートウェイ装置ＨｉＧＡが、ＲＴＳＰプロキシ・アプリケーションＡＳ−Ａ（ＲＴＳＰ）を実行するサービス固有マッピング・デバイスを備える場合、ＱｏＳの知識を全然持たない市販のデバイスが、ＱｏＳ予約システムを有するネットワークでＱｏＳパラメータを要求することができる。簡単な例は、ユーザが５Ｍｂｐｓの帯域幅を必要とする高解像度映画すなわちＨＤＴＶ映画を見たい場合である。アクセス・ネットワークＡＣが３Ｍｂｐｓだけを提供する場合、高解像度映画を市販のセット・トップ・ボックスＳＴＢを有するユーザに全く提供することができないので、問題がある。
【００５９】
ＨｉＧＡのアプリケーションスペースのＲＴＳＰプロキシは、リソースの予約／割り当てをしないで、予約は、実のところＩＭＳ−ＡＳからの依頼に応じてネットワークのリソースマネージャエンティティによって行われる。その結果、ＩＭＳ−ＡＳは、ＲＴＳＰプロキシがトリガするＨｉＧＡ内のＩＭＳ ＩＰＴＶクライアントから要求される。ＩＭＳ ＩＰＴＶクライアントは、まさにＳＩＰをサポートするとともにＩＰＴＶサービスに「気付いている」ＨｉＧＡ内のエンティティである。それ故それは、本当のＨｉＧＡの機能を構成する。従って、ＲＴＳＰクライアント（デバイス内）から、ＲＴＳＰプロキシ（ＨｉＧＡのアプリケーションスペースに置いてある）、ＩＭＳ ＩＰＴＶアプリケーション（ＨｉＧＡの中核機能）、ＩＭＳ ＡＳ、アクセス・ネットワークリソースマネージャを記載の順番で使用して、ユーザのストリーム要件およびアクセス・ネットワークＡＣの能力を前もってネゴシエートすることが可能であり、次いでリソースＲＥＳが十分にあるときはストリームを許可し、またリソースＲＥＳが十分にないときスはトリームを許可しない。
【００６０】
他方、ＲＴＳＰプロキシ自体は実は上記の順番の端にあり、それ自体でリソース予約を行わないことに留意すべきである。リソース予約は、ＩＭＳ ＡＳがデバイスのＩＭＳ ＩＰＴＶアプリケーションから要求を受けるとき、ＩＭＳ ＡＳが（前述の他のネットワークコンポーネントとともに）行う。ＲＴＳＰプロキシは、クライアントからＩＭＳ ＩＰＴＶアプリケーションにＲＴＳＰ要求を単に渡す。さらなる詳細については、好ましい実施例の「パーソナル化されたコンテンツ用のトリガ」を参照して以下に説明する。
【００６１】
要約すると、図２ｃでは第２のタイプの制御データ２ＣＤ１は、ビデオストリーミング提供の簡単なサービス要求を構成し、この要求２ＣＤ１は、ＲＴＳＰプロキシ・アプリケーションＡＳ−Ａ（ＲＴＳＰ）に提供される。次いでＲＴＳＰプロキシ・アプリケーションは、要求されたサービス（ビデオストリーム）を第２のタイプの端末デバイスＳＴＢに提供するために十分なリソースがアクセス・ネットワークＡＣにあるかどうかを問い合わせるために、サーバＩＭＳ−Ｓに問い合わせ／要求メッセージ１ＣＤ１を開始してもよい。次いで要求／問い合わせメッセージ１ＣＤ１の受信に応えて、サーバＩＭＳ−Ｓは、サービス提供のために十分なリソースＲＥＳがあるかどうかをアクセスシステムＡＣとネゴシエートまたはチェックしてもよい。十分なリソースがある場合、肯定応答メッセージ１ＣＤ２＝ＡＣＫがＨｉＧＡのＲＴＳＰプロキシ・アプリケーションに返信され、十分なリソースが見つからない場合、否定応答メッセージ１ＣＤ２＝ＮＡＣＫがＲＴＳＰプロキシ・アプリケーションに提供される。次いで対応する肯定応答／否定応答（ＡＣＫ／ＮＡＣＫ）メッセージが、ＲＴＳＰプロキシ・アプリケーションからセット・トップ・ボックスＳＴＰに提供される。市販のセット・トップ・ボックスＳＴＰは、サービス提供に関して一般的な要求メッセージの送信だけができるが、まずＲＴＳＰプロキシ・アプリケーションは、サービス提供のために必要な帯域幅（リソースＲＥＳ）をチェックし、予約してもよい。このようにして、ユーザ固有ベースで（ＲＴＳＰプロキシ・アプリケーションは、ＨｉＧＡが知っているユーザ・アイデンティティを使用してセット・トップ・ボックス（ＳＴＢ）からの要求をパーソナル化し得るので）、ビデオストリーミング提供を単に拒否または許可することが可能なだけでなく、例えばより狭帯域すなわちＱｏＳの低いビデオサービス提供を許可することも可能である。このようにして、ゲートウェイ装置ＨｉＧＡは、サーバＩＭＳ−ＳとＱｏＳのユーザ固有のネゴシエーションを実行し許可する。例えば、ユーザは、アクセス・ネットワークＡＣのある帯域幅に対してだけ支払っていてもよく、そのＲＴＳＰプロキシ・アプリケーションを有するゲートウェイ装置ＨｉＧＡは、ビデオサービスの提供をユーザが支払ったＱｏＳに「適応」させてもよい。
【００６２】
図２ｂ、２ｃの実施例および図２ａの通信システムＳＹＳの概略ブロック図および図３の通信方法で説明したように、本発明のおかげで従来の第２のタイプの端末デバイスＴ２も、ＨｉＧＡプロキシの仲介によって第１のタイプの制御情報を提供されてもよい。このやり方で、ユーザ固有すなわちパーソナル化されたコンテンツデータも、簡単で標準的な第２の端末デバイスＴ２にも提供されてもよい。
【００６３】
以下ではＩＰＴＶの事例に関連する本発明の特別な実施形態について、図２ｄを参照して、また図４ａ、４ｂ、４ｃ、４ｄ、４ｅも参照して説明する。
【００６４】
図２ｄは、本質的に図２ａのＩＰＴＶサービスアプリケーションの具体的事例に相当する。図２ｄには、アプリケーションスペースおよびその内部のサービス固有アプリケーションならびにＨｉＧＡ経由でＩＭＳサービスにアクセスし得る非ＩＭＳデバイスのセットを示す。ＩＭＳサービスの一例はＩＰＴＶサービスである。非ＩＭＳのＳＴＢ（第２の端末デバイス）と、ＨｉＧＡアプリケーションスペース内のＩＰＴＶサービスアプリケーション（マッピング・デバイス）と、ＩＭＳ ＩＰＴＶ ＡＳとの間の遣り取りを、図４ａ、４ｂ、４ｃ、４ｄ、４ｅに示す。これらの図は、ＩＰＴＶサービスに固有のシグナリング図を示し、サービス実施の一例としてここに示す。一部のメッセージは、ＨｉＧＡ実施の標準的なものであるが、採用されたＩＰＴＶアプリケーションを有するＨｉＧＡアプリケーションスペースの特殊なメッセージについては、本発明の機能を説明するために強調する。他のＩＭＳサービスおよび非ＩＭＳサービスに関しては、提供されるアプリケーション（サービス）に依存するが、図４ａ、４ｂ、４ｃ、４ｄ、４ｅのシーケンス図と同様であろう。
【００６５】
図２ｄに示すように、アプリケーションスペースを有するＨｉＧＡは、ＨｉＧＡ内に配置されるアプリケーション固有ロジックのサポートを引き受ける。制御プレーンは、マッピング・デバイスを用いてこれをＳＴＢ固有の制御プレーンにマッピングするタスクを有するＨｉＧＡに前と同じように終端される。従って、ＨｉＧＡは、前に説明したようにＳＴＢへのＩＰＴＶサーバプロキシとしての機能をこの場合も果たす。このようにしてＨｉＧＡ内のアプリケーションスペースは、ＩＭＳ ＩＰＴＶ ＡＳからのアプリケーション固有データを終端するモジュールの収納場所である。この場合もやはり図２ａに見られるように、ＩＭＳコンテンツサーバＩＭＳ−ＳからのメディアプレーンはＳＴＢに終端される。
【００６６】
上に説明したように、ＨｉＧＡの機能は、レジデンシャル・ゲートウェイまたはマスタＳＴＢ（Ｍ ＳＴＢ）に配置できよう。マスタＳＴＢ（Ｍ ＳＴＢ）は、複数のＳＴＢためにＩＭＳ制御プレーンを処理する１つのマスタデバイスに接続されるホーム環境の複数のＳＴＢ（スレーブＳＴＢ）の存在を可能にする。
【００６７】
図４ａ〜４ｅの全図は、本発明の好ましい形態に関するが、本発明の主要範囲は図２ａおよび図３の図に示されているので、本発明の範囲を限定すると決して見なしてはならないことに留意してもよい。
【００６８】
ＳＴＢのメディア・セッション開始について、図４ａに示す。図４ａには、従来のゲートウェイ装置ＨｉＧＡに既に部分的に組み込まれているメッセージがあることに留意すべきである。本発明の好ましい形態に従う新しいメッセージは、図４ａにおいて（および以下で説明する図４ｂ〜４ｅの他のフローチャートにおいても）それぞれ○印が付いている。図４ａは、図２ｂのＥＰＧダウンロードに関連する本発明のより詳細な実施形態である。
【００６９】
図４ａでは、右側の「メディアサーバ」が図２ａの右側に示すＩＭＳ−Ｓサーバに相当する。セット・トップ・ボックスＳＴＢは、第２のタイプの端末デバイスＴ２に相当する。「：ＨｉＧＡ」／：ＣＳＣＦ（コールセッション制御機能）は、ゲートウェイ装置ＨｉＧＡに配置されている。「：ＩＰＴＶ ＡＳ」はＩＭＳサーバのアプリケーションスペースに相当する。
【００７０】
図４ａの前提条件は、：ＣＳＣＦのトリガがＲＥＧＩＳＴＥＲ時にｓｉｐ：ｆａｍｉｌｙ＠ｏｐ．ｃｏに対して設定されていて、ＳＴＢは電源が切れており、ｓｉｐ：ｆａｍｉｌｙ＠ｏｐ．ｃｏｍはセット・トップ・ボックスＳＴＢのデフォルトのＩＭＳアイデンティティである。図４ａのセット・トップ・ボックスＳＴＢのメディア・セッション初期設定は、ＳＴＢからＨｉＧＡ送信されるメッセージ１：メッセージ電源オンで始まる。メッセージ２：ＲＥＧＩＳＴＥＲで、ＨｉＧＡは家族のアイデンティティを登録する。このステップ２：には、ＨｉＧＡによるセット・トップ・ボックスＳＴＢのアプリケーションスペースＡＳへの登録を含む。ステップ２：は、例えば「Ｒｅｃｈｏｎアーキテクチャ報告（Ｒｅｃｈｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｒｅｐｏｒｔ）ＥＡＢ−０５：０４５６０８、２００５−１２−２２」などに定義されている従来のメッセージである。
【００７１】
ステップ３：では、登録要求が事前設定のトリガに基づきアプリケーションスペースに中継される。ステップ４：では、アプリケーションスペースＡＳが、ユーザプロファイルを有するステップ４：ＭＥＳＳＡＧＥメッセージで応答する。ステップ５：では、ＭＥＳＳＡＧＥをＨｉＧＡに送信する。今度は受信したユーザプロファイルに基づき、ゲートウェイ装置ＨｉＧＡは、ステップ６：ＳＵＢＳＣＲＩＢＥでアプリケーションスペースＡＳにサブスクリプションを実行する。ステップ７：ＳＵＢＳＣＲＩＢＥでは、サブスクリプションメッセージがアプリケーションスペースＡＳに中継される。ステップ８：では、アプリケーションスペース：ＩＰＴＶ ＡＳが、対応するユーザプロファイルに対するＥＰＧのＵＲＬを有するＮＯＴＩＦＹメッセージで応答する。ステップ９：ＮＯＴＩＦＹでは、ＵＲＬを有するＮＯＴＩＦＹメッセージがゲートウェイ装置ＨｉＧＡに中継される。これまでのステップ１：〜９：は従来のものであり、市販の第２の端末デバイスＴ２も、対応するユーザプロファイルに対するＥＰＧのＵＲＬを受信するために、このようなステップを実行し得る。
【００７２】
本発明に従って、ステップ１０：では、ゲートウェイ装置：ＨｉＧＡがメッセージ１０：ＥＰＧデータ読み出しメッセージを：ＩＰＴＶ ＡＳアプリケーションスペースに送信する。このようにして、ステップ１０：では、アプリケーションスペースのＩＰＴＶアプリケーション：ＩＰＴＶ ＡＳが、受信したＵＲＬに指定された場所からＥＰＧを読み出す。ステップ１１：フォーマットＸのＥＰＧでは、ＵＲＬから読み出されたＥＰＧデータがセット・トップ・ボックスＳＴＢが普通サポートしていないフォーマットで受信される、すなわち本質的にＥＰＧは、第１のタイプの制御データフォーマットである（図２ｂも参照）。それ故ステップ１０では、ゲートウェイ装置：ＨｉＧＡは、セット・トップ・ボックスＳＴＢがサポートしている第２のタイプのフォーマットにＥＰＧを変換する。これが行われるのは、ＥＰＧは、セット・トップ・ボックスＳＴＢがサポートするフォーマットと普通必ずしも同じではないからである。すなわち、ＥＰＧフォーマットは、ＳＴＢがサポートするフォーマット例えばＨＴＭＬフォーマットに変換される。ステップ１２：では、第２の制御データタイプ（例えばＨＴＭＬ）に変換されたＥＰＧデータが、セット・トップ・ボックスＳＴＢに中継される。このやり方で、市販のセット・トップ・ボックスＳＴＢは、パーソナル化された電子プログラム・ガイドＥＰＧを受信し得る。
【００７３】
ステップ１３：ＩＮＶＩＴＥでは、トランスポートネットワークのメディアストリームにネットワークリソースを割り当てるために使用されるだろうＳＤＰを有するＩＮＶＩＴＥメッセージが、ＨｉＧＡによって送信される。ステップ１２：の後、すなわちＥＰＧのダウンロード後、：ＨｉＧＡは、図２ｃに示す原理に見られるように、リソースネゴシエーションを実行し得る。このようにして、：ＨｉＧＡは、まずアクセス・ネットワークＡＣに、決まった最大帯域幅例えば５ＭＢ回線を予約してもよい。次いでＳＴＢのそばにいるユーザは、ＩＭＳサーバへの要求としてストリームチャネルを選択してもよい。例えばユーザは、ＨＤＴＶチャネルを要求してもよい。アクセス・ネットワークＡＣが回線を提供できない場合、ＨｉＧＡは、ＮＡＣＫメッセージを返信し、アクセス・ネットワークＡＣが回線を提供できないと伝える（図２ｃも参照）。ＨｉＧＡは、別のストリームを試みたほうがよい、またはより低解像度のチャネルでストリーミングをするように、メッセージでネゴシエートもしてもよい。
【００７４】
ステップ１４：では、招待メッセージＩＮＶＩＴＥがＣＳＣＦ（コールセッション制御機能）から中継される。ステップ１５：では、ユニキャスト・アドレスまたはマルチキャスト・アドレスを有するＯＫメッセージが、アプリケーションスペース：ＩＰＴＶ ＡＳから返信される。ステップ１６：では、ＯＫメッセージは、：ＣＳＣＦから：ＨｉＧＡへ中継される。
【００７５】
ステップ１７：メディア・セッション開始は、従来のシステムでサポートされていない重要なメッセージである。ステップ１７：では、ＨｉＧＡの：ＩＰＴＶアプリケーションスペースが、セット・トップ・ボックスＳＴＢとサービス提供デバイス（メディアサーバ）との間のメディア・セッション確立を呼びかける。このメッセージにより、：ＨｉＧＡがステップ１７におけるメディア・セッション確立を積極的に制御し開始し得るので、これは重要なメッセージである。図４ｂ、４ｃは、この好ましい詳細をさらに示す。
【００７６】
ステップ１８：メディア・セッション確立では、従来のやり方で、図２ａに示すように例えば直通回線ＤＬまたはアクセス・ネットワークＡＣを通して、メディア・セッションがＳＴＢとメディアサーバＩＭＳ−Ｓとの間で確立される。
【００７７】
このようにして、：ＨｉＧＡがユーザ固有ベースで登録を実行するので（図４ａの最初のブロック参照）、ユーザ固有の電子プログラム・ガイドＥＰＧを：ＩＰＴＶ ＡＳから読み出すことが可能であり、この固有の電子プログラム・ガイドＥＰＧは、ステップ１２：の前に変換された後、市販のＳＴＢに中継されてもよい。その後、メディア・セッション確立がトリガされてもよい。このようにして、制御データ（電子プログラム・ガイドＥＰＧ）はユーザにパーソナル化されたやり方でセット・トップ・ボックスに提供されてもよく、これは市販のセット・トップ・ボックスＳＴＢが普通することができないことである。
【００７８】
図４ｂは、図４ａのステップ１７：メディア・セッション開始の説明としてＵＰｎＰプロトコルを使用するユニキャスト・セッション確立を示す。図４ｂの前提条件は、ＳＴＢは電源が入れられておりＨｉＧＡ経由でサーバＩＭＳに登録されている、すなわち図４ａのステップ１：〜９：は、前もって実行されている。図４ｂでは、右側のメディアサーバは、図２ａに示すサーバＩＭＳ−ＳのサービスメモリＳＥＲＭに格納されたサービスＳＥＲＶに相当する。ＨｉＧＡとＵＰｎＰメディアサーバはともに、図２ａに示すＨｉＧＡに配置される。図４ｂの左側のＳＴＢは、図２ａに示す第２の端末Ｔ２に相当する。
【００７９】
図４ｂのステップ１：では、ＵＰｎＰサーバがＨｉＧＡアプリケーションスペースの中にＩＰＴＶアプリケーションとともに配置されていて、メディアサーバに配置されたビデオコンテンツのＵＲＬを渡し、メディア・セッションを開始するようにセット・トップ・ボックスＳＴＢに呼びかける。ＵＰｎＰ ＡＶアーキテクチャ、特に「ＵＰｎＰ ＡＶアーキテクチャ（ＵＰｎＰ ＡＶ ａｒｃｈｉｔｅｃｔｕｒｅ）０．８３」のセクション６．５に記載の非同期プッシュモデルを、好ましくはここで使用できよう。
【００８０】
ステップ２：では、ユニキャスト・セッションの確立があり、その意味するところは、ＳＴＢのＵＰｎＰメディアレンダラが右側のメディアサーバとユニキャスト・ストリームを確立する。図２ｃと同様に、これは、ＲＴＳＰプロトコルで行われてもよい。ステップ３：では、ＲＴＰメディアストリームが、メディアサーバからＳＴＢに送信される。このシナリオでは、セット・トップ・ボックスＳＴＢ固有のアプリケーションは、好ましくは「ＵＰｎＰ ＡＶアーキテクチャ０．８３」に記載のＵＰｎＰメディアレンダラデバイスであることができよう。
【００８１】
重要なステップ１：で述べたように、セット・トップ・ボックスＳＴＢは、メディアサーバに配置されたビデオコンテンツのＵＲＬを渡されて、メディア・セッションを開始するように呼びかけられる。このようにして、：ＨｉＧＡからＳＴＢの積極的な制御が行われてもよい。
【００８２】
図４ｂとは対照的に、図４ｃは、図４ａのステップ１７：で使用されてもよいマルチキャスト・セッション確立を示す。図４ａに示すユニットに加えて、図４ｃは、ゲートウェイ装置ＨｉＧＡと：ＣＳＣＦ（コールセッション制御機能）との間に配置されるレジデンシャル・ゲートウェイＲＧＷも示す。図４ｂと同様に、図４ｃは、：ＨｉＧＡが登録されていて、ＥＰＧがＳＴＢによってダウンロードされているという前提条件に基づいている。
【００８３】
本発明に従う重要なメッセージ：ＩＮＶＩＴＥが備えている中には、マルチキャストされたチャネル（例えば、ブロードキャストされたＴＶチャネル）を受信するように要求するＩＮＶＩＴＥメッセージを、ＨｉＧＡのＩＰＴＶアプリケーションがＣＳＣＦに送信することがある。このようにして、本発明に従って：ＨｉＧＡは、マルチキャストされた特定のチャネルの受信を要求して、第１のタイプの要求メッセージを：ＣＳＣＦに積極的に送信してもよい。本質的にステップ１：ＩＮＶＩＴＥは、ブロードキャストセッションを開始すること、例えばＩＮＶＩＴＥｔｖ＿ａｓ＠ｏｐ．ｃｏｍである。
【００８４】
ステップ２：では、ＩＮＶＩＴＥメッセージは、：ＣＳＣＦによってＩＰＴＶアプリケーションスペース：ＩＰＴＶ ＡＳに中継される。ステップ３：では、サーバＩＭＳ−ＳのアプリケーションスペースＡＳが、ＴＶチャネルのビデオストリームを有するマルチキャスト・グループに関するマルチキャスト・アドレスを有するＯＫメッセージ（例えば２００）で応答する。このマルチキャスト・アドレスは、ステップ３：にＭＣ＿Ｘで示す。ステップ４：では、ＯＫメッセージがゲートウェイ装置ＨｉＧＡに送信される。ステップ２：〜ステップ４：は、要求メッセージをサーバに中継するため、およびこのようなメッセージにサーバが応答するための、従来のメッセージである。
【００８５】
本発明に従ってステップ５：では、ＨｉＧＡアプリケーションスペースのＩＰＴＶアプリケーションスペースが、セット・トップ・ボックスＳＴＢのＩＧＭＰクライアントにマルチキャスト・グループに参加するように呼びかける。さらに本発明に従ってステップ６：では、セット・トップ・ボックスＳＴＢのＩＧＭＰクライアントは、レジデンシャル・ゲートウェイＲＧＷにＩＧＭＰ ＪＯＩＮメッセージを送信し、レジデンシャル・ゲートウェイＲＧＷがそれをトランスポート（アクセス）ネットワークのＩＧＭＰアウェアアクセスノードに送信することにより、新しいマルチキャスト・グループに参加する。
【００８６】
図４ｃのメッセージ１：、５：、６：により、マルチキャストされたチャネル（例えば、ブロードキャストされたＴＶチャネル）の特定のマルチキャスト・グループに参加し得るようなやり方で、第２のタイプの制御データでＳＴＢを制御することが可能になる。従って：ＨｉＧＡは、マルチキャストされたチャネルに関してサーバ：ＩＰＴＶ ＡＳと「ネゴシエーション」を実行し、次いでステップ４：でＯＫメッセージを受信後、マルチキャスト・グループに参加するようにＩＧＭＰクライアントに呼びかけるために、セット・トップ・ボックスＳＴＢに対応する第２のタイプの制御データを送信してもよい。このようなネゴシエーションは、市販のセット・トップ・ボックスＳＴＢでは実行できない。
【００８７】
図４ｄは、電子プログラム・ガイドＥＰＧを更新するために、サーバからセット・トップ・ボックスＳＴＢに制御データを送信する一実施例を示す。図４ｄの前提条件は、セット・トップ・ボックスＳＴＢが電源を入れられており、ＨｉＧＡ経由でＩＭＳサーバに登録されている（基本的に図４ａのステップ１：〜６：が実行されている）。図４ｄの目的は、ＳＴＢの制御データを更新する一例として、基本的に：ＨｉＧＡのＩＰＴＶアプリケーションがＥＰＧの更新を行うことである。しかし、他の種類の制御データも全く同じやり方で更新できることが理解される。
【００８８】
ステップ１：は、サーバサイドＩＰＴＶ ＡＳがＥＰＧ更新メッセージを：ＨｉＧＡに送信する従来のメッセージである。ＨｉＧＡのＩＰＴＶクライアント（ＩＰＴＶプロキシ・アプリケーション）は、ＥＰＧを受信し、ＥＰＧはＳＴＢがサポートするフォーマットに変更される。ＥＰＧのこの変換は既に、図４ａを参照してステップ１２：で説明したように、本発明に従う新しいメッセージの一部である。
【００８９】
図４ｄのステップ２：では、：ＨｉＧＡのＩＰＴＶプロキシ・アプリケーション（クライアント）が、ＥＰＧ更新をセット・トップ・ボックスＳＴＢに送信する。このステップは、セット・トップ・ボックスＳＴＢがサポートするＥＰＧの様式の実装に個別のものである。代替の好ましい形態は、ＳＴＢへのＥＰＧファイル全体または変更だけの送信を含む。しかし、重要なことは、図２ｂと同様に、電子プログラム・ガイドＥＰＧに関する制御データが、サーバ：ＩＰＴＶ ＡＳと：ＨｉＧＡとの間で第１のタイプのフォーマットで交換され、：ＨｉＧＡでＳＴＢがサポートするフォーマットに変換してもらうことにより、セット・トップ・ボックスＳＴＢが、この更新を理解するようになることである。
【００９０】
このようにして、市販のＳＴＢが、変更のない一般のユーザ固有でないＥＰＧだけを受信できるのに対して、本発明の通信システムＳＹＳは、パーソナル化された（ユーザ固有の）ＥＰＧおよびその変更を、市販のＳＴＢにダウンロードすることを可能にする。
【００９１】
図４ａ〜４ｅの上記多数の実施例で説明したように、ＨｉＧＡアプリケーションスペースのＩＰＴＶプロキシ・アプリケーション（クライアント）は、市販のＳＴＢが普通できない機能および変換機能を引き受ける。ＨｉＧＡは、「最新」のＳＴＢが自装置で実行し得る機能を従来のＳＴＢが実行するために、一種のフロントエンドの役割を果たす、と言うこともできよう。
【００９２】
もう１つの重要なシナリオは、基本的に図４ｅに示すように、：ＨｉＧＡアプリケーションスペースのＩＰＴＶプロキシ・アプリケーション（クライアント）の助けで、パーソナル化されたコンテンツをどのようにＳＴＢに配信し得るかである。パーソナル化されたコンテンツの一例は、ユーザの好みまたはユーザプロファイルに合わせた広告である。この広告は、コマーシャル時間中にユーザに見せられるだろう。従って、パーソナル化された電子プログラム・ガイドＥＰＧをダウンロードおよび変換したのと同様に、図４ｅのシナリオは、パーソナル化されたコンテンツの市販のＳＴＢへの提供に関連する。
【００９３】
図４ｅでは、ユニットである：ＳＴＢ、：ＨｉＧＡ、：ＣＳＣＦ、ＩＰＴＶ ＡＳおよび：メディアサーバの位置付けおよび配列は、図４ａのそれぞれのユニットに相当する。図４ｅの前提条件は、ＳＴＢが電源を入れられており、：ＨｉＧＡ経由でサーバＩＭＳに登録されていることである。：ＨｉＧＡは、サーバサイドから送信されるトリガイベントを理解するように、マルチキャスト・チャネル・イベント・トリガに登録する。
【００９４】
図４ｅに示すように、ステップ１：イベントトリガでは、イベントトリガがＨｉＧＡで受信される。これは、コマーシャルの開始などのイベントに関するトリガ、ルーティング用の双方向性トリガ等であることができよう。もちろん、究極的にステップ１：のイベントトリガの目的は、セット・トップ・ボックスＳＴＢに特定の動作を呼びかけることである。このイベントトリガ（第１のタイプの制御データ、図２ａ参照）は、市販のセット・トップ・ボックスＳＴＢが理解できるように、ＨｉＧＡによって第２のタイプの制御データに変換される。一般にイベントトリガの基本機能は、ＳＴＢに特定の動作を呼びかけることである。図４ｅの例では、もちろんイベントトリガの目的は、ＳＴＢにコマーシャルであるメディア・セッションの開始を通知することである。すなわち、もちろん最終的願望は、パーソナル化されたやり方でコマーシャルまたは広告に接続するために、ＳＴＢがサーバサイドとメディア・セッションを開始することである。
【００９５】
それ故ステップ２：では、メディア・セッション確立が開始され、トリガのＵＲＬに基づき、ＨｉＧＡのＩＰＴＶアプリケーション（プロキシ・アプリケーション）が、セット・トップ・ボックスＳＴＢにメディア・セッション確立を呼びかける。このメディア・セッション確立は、ユニキャスト・セッションが確立されるかマルチキャスト・セッションが確立されるかに応じて、図４ｂ、４ｃに示す。
【００９６】
パーソナル化されたコンテンツを配信するためのユニキャスト・セッションの確立（図４ｂ）は、アクセストランスポートネットワークＡＣのネットワークリソースの観点からは高過ぎることがある。このため、広告などのパーソナル化されたコンテンツは、ＣＰＮ（宅内ネットワーク、Customer Premises Network）、例えばＳＴＢ自体かまたは事業者が制御するＮＡＳ（ネットワーク接続ストレージ、Network Attached Storage）などにあらかじめキャッシュできよう。この場合、図４ｅのステップ３：、４：におけるメディアサーバは、あらかじめキャッシュしたコンテンツを有するＣＰＮエンティティ（例えば、ＳＴＢまたはＮＡＳ）であろう。
【００９７】
：ＨｉＧＡは登録プロセスのために（およびその中でユーザ・アイデンティティを格納するために）メッセージをパーソナル化するので、ユーザにパーソナル化されたコマーシャルを実際のメディア・セッションでＳＴＢに提供することは、実現し得る。ＨｉＧＡは、コマーシャル（イベントトリガ開始）が特定のユーザ・アイデンティティ用か否かをチェックするために、どんな種類のイベントトリガが受信されるかのフィルタリングを実行するからである。それが特定のあらかじめ登録されたユーザ・アイデンティティ用である場合だけ、ＨｉＧＡは、このコマーシャルに対してＳＴＢにメディア・セッションを呼びかける。このやり方で、パーソナル化されたコンテンツ例えばコマーシャルが、ユーザにパーソナル化されたやり方でＳＴＢに提供されてもよい。これとは対照的に、従来の市販のセット・トップ・ボックスを使用すると、誰もが広告時間に同じ広告を見なければならないだろう。すなわち本発明に従って、特定の前もって合意されたＵＲＬが特定のコマーシャルストリームを送信しようとしている場合、ＨｉＧＡはトリガを受信するだろう。ＨｉＧＡの中では、ＵＲＬはユーザＩＤに関連付けられており、それ故、コマーシャルが送信されようとしていて、ユーザＩＤが前もってそれに興味を示している場合、ＨＩＧＡは、サーバサイドでの特定のコマーシャルの提供を示す第１のタイプの制御データだけを、ＳＴＢに提供する。その場合、メディア・セッション設定が、このビデオ情報提供のために実行される。
【００９８】
ＶｏＤストリームの呼びかけに関して、ＳＩＰ ＩＮＶＩＴＥメッセージをＩＰＴＶ ＡＳに送信できよう。この達成のために、ＳＴＢのＩＰＴＶアプリケーションは、代替プロトコル（ｚ．Ｂ．ＵＰｎＰ、ＨＴＴＰ、ＳＩＰ等）の１つを通じてＨｉＧＡにメッセージを送信でき、その結果ＨｉＧＡは、サーバのＩＰＴＶ ＡＳと適切なＳＩＰダイアログを開始するだろう。ＳＤＰを運ぶダイアログの最終メッセージは、ネゴシエートしたメディア・セッションの帯域幅要件に従って、アクセストランスポートネットワークＡＣのリソースＲＥＳを予約するために、リソース管理システムをトリガできよう。基本的にリソースネゴシエーションは、図２ｃの実施例で概説したように行われるだろう。
【００９９】
通信システムＳＹＳ、特にゲートウェイ装置ＨｉＧＡを、図２ａのブロック図および図３のフローチャートに示すように構成して、特にゲートウェイ装置ＨｉＧＡを図２ａに示すように市販のセット・トップ・ボックスＳＴＢに対する一種のプロキシ・アプリケーションとしてサービス固有のマッピング・デバイスを有するように構成して、第２の端末デバイスＴ２の制御プロトコルにサービス提供デバイスＩＭＳ−Ｓのサービス制御プレーンを適応、変換および解釈する適切なアプリケーションをＨｉＧＡのアプリケーションスペースＡＳに採用することにより、ゲートウェイ装置ＨｉＧＡは、ＳＴＢなどのＩＭＳを理解しない様々なタイプのホームデバイスに対して、例えばＩＭＳベースのサービスへのアクセスを提供し得る。それゆえ本発明は、非ＩＭＳデバイスとＩＭＳベースのサービスとの間の不適合の問題を解決し、それ故に、事業者が、種々の標準的市販のホームデバイスにＩＭＳを通じて自社のマルチメディアサービスを提供する道を開く。
【０１００】
図２ｂおよび図４ａ〜４ｅに示すように一態様は、標準ＳＴＢがサーバのＩＭＳ ＩＰＴＶ ＡＳに気付く必要なしにその元の機能の維持を可能にする、ＨｉＧＡアプリケーションスペースのＩＰＴＶサポートに関連している。従って標準ＳＴＢは、汎用メディア終端デバイスすなわち市販で購入し得る一般的な第２のタイプの端末デバイスでもよい。
【０１０１】
さらに、ＨｉＧＡのアプリケーションスペースプロキシは、ＨｉＧＡの容易なアップグレードを可能にする。サービスアプリケーションの新バージョンまたは既存のサービスアプリケーションの更新を、ＨｉＧＡのアプリケーションスペースＡＳにダウンロードし得る。これは、機能の点でＨｉＧＡに融通性を加え、サービスプロバイダが遠隔でＨｉＧＡを管理することを可能にする。
【０１０２】
図２ａ、３（原理）、図２ｂ（ＥＰＧ要求）、図２ｃ（要求マッピング／リソース割り当て）ならびにより具体的な実施例である図２ｄ（ＩＭＳサーバシステム）、図４ａ（メディア・セッション開始およびＥＰＧダウンロード）、図４ｂ（ユニキャスト・セッション確立）、図４ｃ（マルチキャスト・セッション確立）、図４ｄ（ＥＰＧ更新）、図４ｅ（トリガに基づくメディア・セッション開始）の本発明の全体にわたる上記実施形態は、上記のシナリオだけで役に立つわけではない。例えば、端末デバイスＴ２は、家庭の暖房システムの制御装置によって、監視カメラによって、家庭用電化製品の制御を実行する住宅制御デバイス（いわゆる「インテリジェントホーム」に見るような）、ＤＶＤもしくはＭＰ３収集メモリ、または実のところ住宅内の他のどの物理ユニットによって構成されてもよいことも想像される。サーバＩＭＳ−Ｓは、携帯電話機などの例えばリモートアクセスデバイスに接続されてもよい。例えばこの場合、携帯電話機は、ユーザ固有のやり方で家の暖房システムの市販の暖房制御装置に遠隔からアクセスするために使用されてもよい。ホームメモリと携帯電話機との間にユーザ固有のメディア・セッションを確立することにより、携帯電話機にＭＰ３ファイルをダウンロードするために、またはホームメモリから携帯電話機へ個人用ＤＶＤのビデオストリーミングを確立するために、携帯電話機は、家のＤＶＤまたはＭＰ３収集メモリにもトリガを送信してもよい。携帯電話機は、特に図４ｅに関して説明したように例えばトリガメッセージを使用することにより、家庭に配置された監視システムの市販のカメラのオン／オフ、アップ／ダウン、またはズームイン／ズームアウト制御にも使用されてもよい。これは、好ましくはＵＰｎＰプロトコルを使用して行われてもよい。このようにサービス属性の適応（マッピング）は、例えば自装置のＩＰアドレスを持たずＳＩＰプロトコル（第１のタイプのプロトコル）を実行しない最終端末が使用される状況などの、市販の家庭電化製品を使用した家庭内の他の多くの実際的な例でも使用されてもよい。
【０１０３】
本発明は、サービス提供側が第１のタイプの制御データに基づいて動作するのに対して、端末デバイスが第２のタイプの制御データに基づいて動作する一般的通信システムに、その適用を見いだす。本発明によるゲートウェイ装置ＨｉＧＡは、必要な相互運用性すなわち第１のタイプの制御プレーンと第２のタイプの制御プレーンの適合機能を提供する。第１のタイプがＳＩＰに関連し、第２のタイプがＨＴＴＰに関連する特別な実施例について説明したが、本発明は、第１のタイプと第２のタイプの２つの異なる制御プロトコルを備える他のどの通信システムＳＹＳでも使用し得る。
【０１０４】
さらに、本発明の変更形態および変形形態は、添付の特許請求項の範囲内で実行し得ることに留意すべきである。
【０１０５】
特許請求項の参照番号は、説明目的だけに役立ち、これらの特許請求項の範囲を限定しない。
【図面の簡単な説明】
【０１０６】
【図１ａ】先行技術に従う通信システムＳＹＳの概観図である。
【図１ｂ】先行技術に従い、特定のユーザＩＤに関連する特定の所要のサービスに対する特定の好みを載せている、ユーザプロファイルメモリＵＰ−ＭＥＭ内のユーザプロファイルを示す図である。
【図１ｃ】先行技術に従い、第１のタイプの端末デバイスＴ１が、サーバＩＭＳ−Ｓにパーソナル化された電子プログラム・ガイドＥＰＧ１の形態のパーソナル化されたコンテンツを要求する場合の要求シナリオを示す図である。
【図２ａ】本発明に従う通信システムＳＹＳのブロック図である。
【図２ｂ】パーソナル化された電子プログラム・ガイドＥＰＧに関連して、ＩＰＴＶの提供に関する第１の特定のサービス提供例を示す図である。
【図２ｃ】第２の端末デバイスＴ２の要求制御プロトコルとサーバＩＭＳ−Ｓの制御プロトコルが異なる場合のＭＰＥＧ２ストリームの提供、特にアクセス・ネットワークＡＣに対するリソースＲＥＳのネゴシエーションにも関する第２の特定のサービス提供例を示す図である。
【図２ｄ】ＩＭＳサーバおよびＩＰＴＶサービス提供の特定の場合に対する通信システムＳＹＳおよびゲートウェイデバイスＨｉＧＡのブロック図である。
【図３】本発明の通信方法のフローチャートである。
【図４ａ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するＳＴＢのメディア・セッション初期設定の例示のフローチャートである。
【図４ｂ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するユニキャスト・セッション確立の例示のフローチャートである。
【図４ｃ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するマルチキャスト・セッション確立の例示のフローチャートである。
【図４ｄ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するＥＰＧ更新の例示のフローチャートである。
【図４ｅ】図２ｄに示すＩＰＴＶ用のアプリケーション・スペースを有するＨｉＧＡの特別な場合に関する本発明の一実施形態および実施例を示す図であり、ＩＰＴＶサービスに関連するパーソナル化されたコンテンツのトリガ例を示す図である。
【特許請求の範囲】
【請求項１】
ゲートウェイ装置（ＨｉＧＡ）と、複数の端末デバイス（Ｔ２…Ｔｎ…ＴＮ）と、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）にアクセス・ネットワーク（ＡＣ）を通してサービス（ＳＥＲＶ）を提供するサービス提供サーバ（ＩＭＳ−Ｓ）とを備える通信システム（ＳＹＳ）であって、
ａ）前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）に提供される１つ以上のサービス（ＳＥＲ１、ＳＥＲＶ２、ＳＥＲＶ３）を格納するサービスメモリ（ＳＥＲＭ）と、前記１つ以上のサービス（ＳＥＲＶ）に関係して前記ゲートウェイ装置（ＨｉＧＡ）に第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を提供する少なくとも１つの第１のタイプ（ＳＩＰ）の制御プロトコル（ＩＭＳ−ＣＴＲＬＰ）デバイスとを備え、
ｂ）前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）のそれぞれは、前記サービス提供サーバ（ＩＭＳ−Ｓ）から前記アクセス・ネットワーク（ＡＣ）を通して提供される前記サービス（ＳＥＲＶ）を処理するサービス・プロセッサ（ＳＰ）と、前記サービス・プロセッサ（ＳＰ）による前記サービスの実行に関係して前記ゲートウェイ装置（ＨｉＧＡ）に前記第１のタイプ（ＳＩＰ）とは異なる第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を提供する第２のタイプ（非ＳＩＰ）の制御プロトコル（ＴＤ−ＣＰ）デバイスとを備え、
ｃ）前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を前記サービス提供サーバ（ＩＭＳ−Ｓ）と交換し、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を前記端末デバイス（Ｔ２）と交換する１つ以上のサービス固有マッピング・デバイス（ＡＳ−Ａ）を備え、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記端末デバイス（Ｔ２）から受信した第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）に基づいて、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ１）を前記サービス提供サーバ（ＩＭＳ−Ｓ）に提供し、前記サービス提供サーバ（ＩＭＳ−Ｓ）の前記第１のタイプ（ＳＩＰ）の制御プロトコル・デバイス（ＩＭＳ−ＣＴＲＬＰ）から第１のタイプの制御データ（１ＣＤ２）を受信し、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記サービス提供サーバ（ＩＭＳ−Ｓ）から受信した前記第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ２）に基づいて、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ２）を前記端末デバイス（Ｔ２）に提供し、前記端末デバイス（Ｔ２）の前記第２のタイプ（非ＳＩＰ）の制御プロトコル・デバイス（ＴＤ−ＣＰ）から前記第２のタイプの制御データ（２ＣＤ１）を受信する
ことを特徴とする通信システム（ＳＹＳ）。
【請求項２】
前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、ＩＰＴＶプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＩＰＴＶ）、図２ｂ）を備える
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ）。
【請求項３】
前記第２のタイプ（ＨＴＴＰ）の制御データ（２ＣＤ１）は第２のタイプのサービス要求を構成し、前記サービス固有マッピング・デバイス（ＡＳ−Ａ（ＲＴＳＰ））は、第１のタイプの制御データ（１ＣＤ１）として、前記アクセス・ネットワーク（ＡＣ）が前記サービスを前記端末デバイスに提供するために十分なリソース（ＲＥＳ）を有するかどうかを前記サービス提供サーバ（ＩＭＳ−Ｓ）に問い合わせる第１のタイプ（ＳＩＰ）の問い合わせ要求を送信し、
前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービス提供サービス（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）があると判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）があることを示す肯定応答メッセージ（ＡＣＫ）を送信し、前記サービス提供サーバ（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）がないと判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）がないことを示す否定応答メッセージ（ＮＡＣＫ）を送信する
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ｃ）。
【請求項４】
前記端末デバイス（Ｔ２）は、サービス・プロセッサ（ＳＰ）としてＭＰＥＧ２デコーダを有するセット・トップ・ボックス（ＳＴＢ）を備え、前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービスメモリ（ＳＥＲＭ）にサービス（ＳＥＲＶ１、ＳＥＲＶ２、ＳＥＲＶ３）として、ＶｏＤ（ビデオオンデマンド）サービスを備え、前記サービス固有マッピング・デバイス（ＡＳ−Ａ）はＲＴＳＰプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＶｏＤ））を備え、前記制御プロトコル（ＲＴＳＰ）はＲＴＳＰであり、前記リソース（ＲＥＳ）は、前記アクセス・ネットワーク（ＡＣ）の回線の帯域幅（例えば５ＭＢ）である
ことを特徴とする請求項３に記載の通信システム（ＳＹＳ、図２ｃ）。
【請求項５】
前記ゲートウェイ装置（ＨｉＧＡ）および前記端末デバイス（Ｔ２）は、宅内ネットワーク（ＣＰＮ）の一部である
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項６】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記宅内ネットワーク（ＣＰＮ）のレジデンシャル・ゲートウェイ（ＲＧＷ）に配置される
ことを特徴とする請求項５に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項７】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記第２のタイプの第１の制御データ（２ＣＤ１）として前記端末デバイス（Ｔ２）からＥＰＧダウンロード要求を受信し、前記ゲートウェイ装置（ＨｉＧＡ）から提供される前記第２のタイプの制御データ（２ＣＤ２）はパーソナル化されたＥＰＧ（電子プログラム・ガイド）を含む
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ｂ）。
【請求項８】
前記ゲートウェイ装置（ＨｉＧＡ）は、メモリに前記ユーザ・アイデンティティ（ＩＤ１）を含む
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項９】
前記ユーザ・アイデンティティ（ＩＤ１）は、前記ゲートウェイ装置（ＨｉＧＡ）に挿入されたプラグインに格納されるか、または前記ゲートウェイ装置（ＨｉＧＡ）のメモリに挿入されたＵＩＣＣカードに格納される
ことを特徴とする請求項８に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項１０】
前記端末デバイス（Ｔ２）は、セット・トップ・ボックス（ＳＴＢ）、暖房システムの制御装置、住宅監視システム、カメラ、またはインテリジェントハウスの中央住宅制御装置を含むグループから選択された１つ以上のものである
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項１１】
前記制御データ（１ＣＤ１、１ＣＤ２）の前記第１のタイプはＳＩＰ（セッション開始プロトコル）であり、前記制御データ（２ＣＤ１、２ＣＤ２）の前記第２のタイプはＨＴＴＰおよびＵＰｎＰの１つである
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ｄ）。
【請求項１２】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）として、前記サービス提供デバイス（ＩＭＳ−Ｓ）から前記ダウンロードされる第１のタイプのＥＰＧを受信し（図４ａのステップ１０：）、前記受信したＥＰＧのフォーマット（Ｘ）を前記端末デバイス（Ｔ２）がサポートするフォーマットに変換する
ことを特徴とする請求項７に記載の通信システム（ＳＹＳ、図４ａ）。
【請求項１３】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記端末デバイス（Ｔ２）と前記サービス提供デバイス（ＩＭＳ−Ｓ）との間のメディア・セッション確立を呼びかける（図４ａのステップ１７）
ことを特徴とする請求項７に記載の通信システム（ＳＹＳ、図４ａ）。
【請求項１４】
前記メディア・セッション確立は、ユニキャスト・メディア・セッション確立である（図４ｂのステップ１：）
ことを特徴とする請求項１３に記載の通信システム（ＳＹＳ、図４ｂ）。
【請求項１５】
前記メディア・セッション確立は、マルチキャスト・メディア・セッション確立である（図４ｃのステップ１：、５：、６：）
ことを特徴とする請求項１３に記載の通信システム（ＳＹＳ、図４ｃ）。
【請求項１６】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）としてＥＰＧ更新メッセージを受信する（図４ｄのステップ２：）
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図４ｄ）。
【請求項１７】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ２）としてイベント・トリガ・メッセージを受信し（図４ｅのステップ１：）、第２のタイプの制御データ（２ＣＤ２）として前記イベント・トリガ・メッセージ（１ＣＤ２）に基づいて、メディア・セッション確立メッセージを前記端末デバイス（Ｔ２）に送信する（図４ｅのステップ２：）
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図４ｅ）。
【請求項１８】
複数の端末デバイス（Ｔ２…Ｔｎ…ＴＮ）と、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）にアクセス・ネットワーク（ＡＣ）を通してサービス（ＳＥＲＶ）を提供するサービス提供サーバ（ＩＭＳ−Ｓ）とを有する通信システム（ＳＹＳ）のゲートウェイ装置（ＨｉＧＡ）であって、
前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）に提供する１つ以上のサービス（ＳＥＲ１、ＳＥＲＶ２、ＳＥＲＶ３）を格納するサービスメモリ（ＳＥＲＭ）と、前記１つ以上のサービス（ＳＥＲＶ）に関係して前記ゲートウェイ装置（ＨｉＧＡ）に第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を提供する少なくとも１つの第１のタイプ（ＳＩＰ）の制御プロトコル（ＩＭＳ−ＣＴＲＬＰ）デバイスとを備え、
前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）のそれぞれは、前記サービス提供サーバ（ＩＭＳ−Ｓ）から前記アクセス・ネットワーク（ＡＣ）を通して提供される前記サービス（ＳＥＲＶ）を処理するサービス・プロセッサ（ＳＰ）と、前記サービス・プロセッサ（ＳＰ）による前記サービスの実行に関係して前記ゲートウェイ装置（ＨｉＧＡ）に前記第１のタイプとは異なる第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を提供する、第２のタイプ（非ＳＩＰ）の制御プロトコル（ＴＤ−ＣＰ）デバイスとを備え、
前記ゲートウェイ装置（ＨｉＧＡ）は、
ａ）第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を前記サービス提供サーバ（ＩＭＳ−Ｓ）と交換し、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を前記第２のタイプ（非ＳＩＰ）の端末デバイス（Ｔ２）と交換する１つ以上のサービス固有マッピング・デバイス（ＡＳ−Ａ）を備え、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記端末デバイス（Ｔ２）から受信した第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）に基づいて、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ１）を前記サービス提供サーバ（ＩＭＳ−Ｓ）に提供し、前記サービス提供サーバ（ＩＭＳ−Ｓ）の前記第１のタイプ（ＳＩＰ）の制御プロトコル・デバイス（ＩＭＳ−ＣＴＲＬＰ）から第１のタイプの制御データ（１ＣＤ２）を受信し、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記サービス提供サーバ（ＩＭＳ−Ｓ）から受信した前記第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ２）に基づいて、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ２）を前記端末デバイス（Ｔ２）に提供し、前記端末デバイス（Ｔ２）の前記第２のタイプ（非ＳＩＰ）の制御プロトコル・デバイス（ＴＤ−ＣＰ）から前記第２のタイプの制御データ（２ＣＤ１）を受信する
ことを特徴とするゲートウェイ装置（ＨｉＧＡ）。
【請求項１９】
前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、ＩＰＴＶプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＩＰＴＶ）、図２ｂ）を備える
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２０】
前記第２のタイプ（ＨＴＴＰ）の制御データ（２ＣＤ１）は第２のタイプのサービス要求を構成し、前記サービス固有マッピング・デバイス（ＡＳ−Ａ（ＲＴＳＰ））は、第１のタイプの制御データ（１ＣＤ１）として、前記アクセス・ネットワーク（ＡＣ）が前記サービスを前記端末デバイスに提供するために十分なリソース（ＲＥＳ）を有するかどうかを前記サービス提供サーバ（ＩＭＳ−Ｓ）に問い合わせる第１のタイプ（ＳＩＰ）の問い合わせ要求を送信し、
前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービス提供サービス（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）があると判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）があることを示す肯定応答メッセージ（ＡＣＫ）を送信し、前記サービス提供サーバ（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）がないと判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）がないことを示す否定応答メッセージ（ＮＡＣＫ）を送信する
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２１】
前記端末デバイス（Ｔ２）は、サービス・プロセッサ（ＳＰ）としてＭＰＥＧ２デコーダを有するセット・トップ・ボックス（ＳＴＢ）を備え、前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービスメモリ（ＳＥＲＭ）にサービス（ＳＥＲＶ１、ＳＥＲＶ２、ＳＥＲＶ３）として、ＶｏＤ（ビデオオンデマンド）サービスを備え、前記サービス固有マッピング・デバイス（ＡＳ−Ａ）はＲＴＳＰプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＶｏＤ））を備え、前記制御プロトコル（ＲＴＳＰ）はＲＴＳＰであり、前記リソース（ＲＥＳ）は、前記アクセス・ネットワーク（ＡＣ）の回線の帯域幅（例えば５ＭＢ）である
ことを特徴とする請求項２０に記載のゲートウェイ装置（ＨｉＧＡ、図２ｃ）。
【請求項２２】
前記ゲートウェイ装置（ＨｉＧＡ）および前記端末デバイス（Ｔ２）は、宅内ネットワーク（ＣＰＮ）の一部である
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２３】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記宅内ネットワーク（ＣＰＮ）のレジデンシャル・ゲートウェイ（ＲＧＷ）に配置される
ことを特徴とする請求項２２に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２４】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記第２のタイプの第１の制御データ（２ＣＤ１）として前記端末デバイス（Ｔ２）からＥＰＧダウンロード要求を受信し、前記ゲートウェイ装置（ＨｉＧＡ）が提供する前記第２のタイプの制御データ（２ＣＤ２）はパーソナル化されたＥＰＧ（電子プログラム・ガイド）を含む
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ｂ）。
【請求項２５】
前記ゲートウェイ装置（ＨｉＧＡ）は、メモリに前記ユーザ・アイデンティティ（ＩＤ１）を含む
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２６】
前記ユーザ・アイデンティティ（ＩＤ１）は、前記ゲートウェイ装置（ＨｉＧＡ）に挿入されたプラグインに格納されるか、または前記ゲートウェイ装置（ＨｉＧＡ）のメモリに挿入されたＵＩＣＣカードに格納される
ことを特徴とする請求項２５に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２７】
前記端末デバイス（Ｔ２）は、セット・トップ・ボックス（ＳＴＢ）、暖房システムの制御装置、住宅監視システム、カメラ、またはインテリジェントハウスの中央住宅制御装置を含むグループから選択された１つ以上のものである
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２８】
前記制御データ（１ＣＤ１、１ＣＤ２）の前記第１のタイプはＳＩＰ（セッション開始プロトコル）であり、前記制御データ（２ＣＤ１、２ＣＤ２）の前記第２のタイプはＨＴＴＰおよびＵＰｎＰの１つである
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ｄ）。
【請求項２９】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）として、前記サービス提供デバイス（ＩＭＳ−Ｓ）から前記ダウンロードされる第１のタイプのＥＰＧを受信し（図４ａのステップ１０：）、前記受信したＥＰＧのフォーマット（Ｘ）を前記端末デバイス（Ｔ２）がサポートするフォーマットに変換する
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図４ａ）。
【請求項３０】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記端末デバイス（Ｔ２）と前記サービス提供デバイス（ＩＭＳ−Ｓ）との間のメディア・セッション確立を呼びかける（図４ａのステップ１７）
ことを特徴とする請求項２９に記載のゲートウェイ装置（ＨｉＧＡ、図４ａ）。
【請求項３１】
前記メディア・セッション確立は、ユニキャスト・メディア・セッション確立である（図４ｂのステップ１：）
ことを特徴とする請求項３０に記載のゲートウェイ装置（ＨｉＧＡ、図４ｂ）。
【請求項３２】
前記メディア・セッション確立は、マルチキャスト・メディア・セッション確立である（図４ｃのステップ１：、５：、６：）
ことを特徴とする請求項３０に記載のゲートウェイ装置（ＨｉＧＡ、図４ｃ）。
【請求項３３】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）としてＥＰＧ更新メッセージを受信する（図４ｄのステップ２：）
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図４ｄ）。
【請求項３４】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ２）としてイベント・トリガ・メッセージを受信し（図４ｅのステップ１：）、前記イベント・トリガ・メッセージ（１ＣＤ２）に基づいて第２のタイプの制御データ（２ＣＤ２）としてメディア・セッション確立メッセージを前記端末デバイス（Ｔ２）に送信する（図４ｅのステップ２：）
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図４ｅ）。
【請求項３５】
ゲートウェイ装置（ＨｉＧＡ）と、複数の端末デバイス（Ｔ２…Ｔｎ…ＴＮ）と、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）にアクセス・ネットワーク（ＡＣ）を通してサービス（ＳＥＲＶ）を提供する通信システム（ＳＹＳ）のサービス提供サーバ（ＩＭＳ−Ｓ）との間の通信方法（ＳＹＳ）であって、
−前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）に提供する１つ以上のサービス（ＳＥＲ１、ＳＥＲＶ２、ＳＥＲＶ３）を格納するサービスメモリ（ＳＥＲＭ）と、前記１つ以上のサービス（ＳＥＲＶ）に関係して前記ゲートウェイデバイス（ＨｉＧＡ）に第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を提供する少なくとも１つの第１のタイプ（ＳＩＰ）の制御プロトコル（ＩＭＳ−ＣＴＲＬＰ）デバイスとを備え、
−前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）のそれぞれは、前記サービス提供サーバ（ＩＭＳ−Ｓ）から前記アクセス・ネットワーク（ＡＣ）を通して提供される前記サービス（ＳＥＲＶ）を処理するサービス・プロセッサ（ＳＰ）と、前記サービス・プロセッサ（ＳＰ）による前記サービスの実行に関係して前記第１のタイプとは異なる第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を有する第２のタイプ（非ＳＩＰ）の制御プロトコル（ＴＤ−ＣＰ）デバイスとを備え、
−前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を前記サービス提供サーバ（ＩＭＳ−Ｓ）と交換し、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を前記端末デバイス（Ｔ２）と交換する１つ以上のサービス固有マッピング・デバイス（ＡＳ−Ａ）を備え、
少なくとも１つの前記端末デバイス（Ｔ２）から前記ゲートウェイ装置（ＨｉＧＡ）に第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）を提供する工程と、
前記ゲートウェイ装置（ＨｉＧＡ）の前記サービス固有マッピング・デバイス（ＡＳ−Ａ）から前記サービス提供サーバ（ＩＭＳ−Ｓ）に、前記端末デバイス（Ｔ２）から提供された前記第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）に基づいて、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ１）を提供する工程と、
前記サービス提供サーバ（ＩＭＳ−Ｓ）の前記第１のタイプ（ＳＩＰ）の制御プロトコル・デバイス（ＩＭＳ−ＣＴＲＬＰ）から前記ゲートウェイ装置（ＨｉＧＡ）に第１のタイプの制御データ（１ＣＤ２）を提供する工程と、
前記サービス固有マッピング・デバイス（ＡＳ−Ａ）から前記端末デバイス（Ｔ２）に、前記サービス提供サーバ（ＩＭＳ−Ｓ）から提供された前記第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ２）に基づいて、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ２）を提供する工程と
を備えることを特徴とする通信方法（ＳＹＳ）。
【請求項１】
ゲートウェイ装置（ＨｉＧＡ）と、複数の端末デバイス（Ｔ２…Ｔｎ…ＴＮ）と、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）にアクセス・ネットワーク（ＡＣ）を通してサービス（ＳＥＲＶ）を提供するサービス提供サーバ（ＩＭＳ−Ｓ）とを備える通信システム（ＳＹＳ）であって、
ａ）前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）に提供される１つ以上のサービス（ＳＥＲ１、ＳＥＲＶ２、ＳＥＲＶ３）を格納するサービスメモリ（ＳＥＲＭ）と、前記１つ以上のサービス（ＳＥＲＶ）に関係して前記ゲートウェイ装置（ＨｉＧＡ）に第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を提供する少なくとも１つの第１のタイプ（ＳＩＰ）の制御プロトコル（ＩＭＳ−ＣＴＲＬＰ）デバイスとを備え、
ｂ）前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）のそれぞれは、前記サービス提供サーバ（ＩＭＳ−Ｓ）から前記アクセス・ネットワーク（ＡＣ）を通して提供される前記サービス（ＳＥＲＶ）を処理するサービス・プロセッサ（ＳＰ）と、前記サービス・プロセッサ（ＳＰ）による前記サービスの実行に関係して前記ゲートウェイ装置（ＨｉＧＡ）に前記第１のタイプ（ＳＩＰ）とは異なる第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を提供する第２のタイプ（非ＳＩＰ）の制御プロトコル（ＴＤ−ＣＰ）デバイスとを備え、
ｃ）前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を前記サービス提供サーバ（ＩＭＳ−Ｓ）と交換し、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を前記端末デバイス（Ｔ２）と交換する１つ以上のサービス固有マッピング・デバイス（ＡＳ−Ａ）を備え、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記端末デバイス（Ｔ２）から受信した第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）に基づいて、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ１）を前記サービス提供サーバ（ＩＭＳ−Ｓ）に提供し、前記サービス提供サーバ（ＩＭＳ−Ｓ）の前記第１のタイプ（ＳＩＰ）の制御プロトコル・デバイス（ＩＭＳ−ＣＴＲＬＰ）から第１のタイプの制御データ（１ＣＤ２）を受信し、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記サービス提供サーバ（ＩＭＳ−Ｓ）から受信した前記第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ２）に基づいて、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ２）を前記端末デバイス（Ｔ２）に提供し、前記端末デバイス（Ｔ２）の前記第２のタイプ（非ＳＩＰ）の制御プロトコル・デバイス（ＴＤ−ＣＰ）から前記第２のタイプの制御データ（２ＣＤ１）を受信する
ことを特徴とする通信システム（ＳＹＳ）。
【請求項２】
前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、ＩＰＴＶプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＩＰＴＶ）、図２ｂ）を備える
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ）。
【請求項３】
前記第２のタイプ（ＨＴＴＰ）の制御データ（２ＣＤ１）は第２のタイプのサービス要求を構成し、前記サービス固有マッピング・デバイス（ＡＳ−Ａ（ＲＴＳＰ））は、第１のタイプの制御データ（１ＣＤ１）として、前記アクセス・ネットワーク（ＡＣ）が前記サービスを前記端末デバイスに提供するために十分なリソース（ＲＥＳ）を有するかどうかを前記サービス提供サーバ（ＩＭＳ−Ｓ）に問い合わせる第１のタイプ（ＳＩＰ）の問い合わせ要求を送信し、
前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービス提供サービス（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）があると判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）があることを示す肯定応答メッセージ（ＡＣＫ）を送信し、前記サービス提供サーバ（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）がないと判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）がないことを示す否定応答メッセージ（ＮＡＣＫ）を送信する
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ｃ）。
【請求項４】
前記端末デバイス（Ｔ２）は、サービス・プロセッサ（ＳＰ）としてＭＰＥＧ２デコーダを有するセット・トップ・ボックス（ＳＴＢ）を備え、前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービスメモリ（ＳＥＲＭ）にサービス（ＳＥＲＶ１、ＳＥＲＶ２、ＳＥＲＶ３）として、ＶｏＤ（ビデオオンデマンド）サービスを備え、前記サービス固有マッピング・デバイス（ＡＳ−Ａ）はＲＴＳＰプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＶｏＤ））を備え、前記制御プロトコル（ＲＴＳＰ）はＲＴＳＰであり、前記リソース（ＲＥＳ）は、前記アクセス・ネットワーク（ＡＣ）の回線の帯域幅（例えば５ＭＢ）である
ことを特徴とする請求項３に記載の通信システム（ＳＹＳ、図２ｃ）。
【請求項５】
前記ゲートウェイ装置（ＨｉＧＡ）および前記端末デバイス（Ｔ２）は、宅内ネットワーク（ＣＰＮ）の一部である
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項６】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記宅内ネットワーク（ＣＰＮ）のレジデンシャル・ゲートウェイ（ＲＧＷ）に配置される
ことを特徴とする請求項５に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項７】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記第２のタイプの第１の制御データ（２ＣＤ１）として前記端末デバイス（Ｔ２）からＥＰＧダウンロード要求を受信し、前記ゲートウェイ装置（ＨｉＧＡ）から提供される前記第２のタイプの制御データ（２ＣＤ２）はパーソナル化されたＥＰＧ（電子プログラム・ガイド）を含む
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ｂ）。
【請求項８】
前記ゲートウェイ装置（ＨｉＧＡ）は、メモリに前記ユーザ・アイデンティティ（ＩＤ１）を含む
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項９】
前記ユーザ・アイデンティティ（ＩＤ１）は、前記ゲートウェイ装置（ＨｉＧＡ）に挿入されたプラグインに格納されるか、または前記ゲートウェイ装置（ＨｉＧＡ）のメモリに挿入されたＵＩＣＣカードに格納される
ことを特徴とする請求項８に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項１０】
前記端末デバイス（Ｔ２）は、セット・トップ・ボックス（ＳＴＢ）、暖房システムの制御装置、住宅監視システム、カメラ、またはインテリジェントハウスの中央住宅制御装置を含むグループから選択された１つ以上のものである
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ａ）。
【請求項１１】
前記制御データ（１ＣＤ１、１ＣＤ２）の前記第１のタイプはＳＩＰ（セッション開始プロトコル）であり、前記制御データ（２ＣＤ１、２ＣＤ２）の前記第２のタイプはＨＴＴＰおよびＵＰｎＰの１つである
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図２ｄ）。
【請求項１２】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）として、前記サービス提供デバイス（ＩＭＳ−Ｓ）から前記ダウンロードされる第１のタイプのＥＰＧを受信し（図４ａのステップ１０：）、前記受信したＥＰＧのフォーマット（Ｘ）を前記端末デバイス（Ｔ２）がサポートするフォーマットに変換する
ことを特徴とする請求項７に記載の通信システム（ＳＹＳ、図４ａ）。
【請求項１３】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記端末デバイス（Ｔ２）と前記サービス提供デバイス（ＩＭＳ−Ｓ）との間のメディア・セッション確立を呼びかける（図４ａのステップ１７）
ことを特徴とする請求項７に記載の通信システム（ＳＹＳ、図４ａ）。
【請求項１４】
前記メディア・セッション確立は、ユニキャスト・メディア・セッション確立である（図４ｂのステップ１：）
ことを特徴とする請求項１３に記載の通信システム（ＳＹＳ、図４ｂ）。
【請求項１５】
前記メディア・セッション確立は、マルチキャスト・メディア・セッション確立である（図４ｃのステップ１：、５：、６：）
ことを特徴とする請求項１３に記載の通信システム（ＳＹＳ、図４ｃ）。
【請求項１６】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）としてＥＰＧ更新メッセージを受信する（図４ｄのステップ２：）
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図４ｄ）。
【請求項１７】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ２）としてイベント・トリガ・メッセージを受信し（図４ｅのステップ１：）、第２のタイプの制御データ（２ＣＤ２）として前記イベント・トリガ・メッセージ（１ＣＤ２）に基づいて、メディア・セッション確立メッセージを前記端末デバイス（Ｔ２）に送信する（図４ｅのステップ２：）
ことを特徴とする請求項１に記載の通信システム（ＳＹＳ、図４ｅ）。
【請求項１８】
複数の端末デバイス（Ｔ２…Ｔｎ…ＴＮ）と、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）にアクセス・ネットワーク（ＡＣ）を通してサービス（ＳＥＲＶ）を提供するサービス提供サーバ（ＩＭＳ−Ｓ）とを有する通信システム（ＳＹＳ）のゲートウェイ装置（ＨｉＧＡ）であって、
前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）に提供する１つ以上のサービス（ＳＥＲ１、ＳＥＲＶ２、ＳＥＲＶ３）を格納するサービスメモリ（ＳＥＲＭ）と、前記１つ以上のサービス（ＳＥＲＶ）に関係して前記ゲートウェイ装置（ＨｉＧＡ）に第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を提供する少なくとも１つの第１のタイプ（ＳＩＰ）の制御プロトコル（ＩＭＳ−ＣＴＲＬＰ）デバイスとを備え、
前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）のそれぞれは、前記サービス提供サーバ（ＩＭＳ−Ｓ）から前記アクセス・ネットワーク（ＡＣ）を通して提供される前記サービス（ＳＥＲＶ）を処理するサービス・プロセッサ（ＳＰ）と、前記サービス・プロセッサ（ＳＰ）による前記サービスの実行に関係して前記ゲートウェイ装置（ＨｉＧＡ）に前記第１のタイプとは異なる第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を提供する、第２のタイプ（非ＳＩＰ）の制御プロトコル（ＴＤ−ＣＰ）デバイスとを備え、
前記ゲートウェイ装置（ＨｉＧＡ）は、
ａ）第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を前記サービス提供サーバ（ＩＭＳ−Ｓ）と交換し、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を前記第２のタイプ（非ＳＩＰ）の端末デバイス（Ｔ２）と交換する１つ以上のサービス固有マッピング・デバイス（ＡＳ−Ａ）を備え、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記端末デバイス（Ｔ２）から受信した第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）に基づいて、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ１）を前記サービス提供サーバ（ＩＭＳ−Ｓ）に提供し、前記サービス提供サーバ（ＩＭＳ−Ｓ）の前記第１のタイプ（ＳＩＰ）の制御プロトコル・デバイス（ＩＭＳ−ＣＴＲＬＰ）から第１のタイプの制御データ（１ＣＤ２）を受信し、
−前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、前記サービス提供サーバ（ＩＭＳ−Ｓ）から受信した前記第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ２）に基づいて、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ２）を前記端末デバイス（Ｔ２）に提供し、前記端末デバイス（Ｔ２）の前記第２のタイプ（非ＳＩＰ）の制御プロトコル・デバイス（ＴＤ−ＣＰ）から前記第２のタイプの制御データ（２ＣＤ１）を受信する
ことを特徴とするゲートウェイ装置（ＨｉＧＡ）。
【請求項１９】
前記サービス固有マッピング・デバイス（ＡＳ−Ａ）は、ＩＰＴＶプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＩＰＴＶ）、図２ｂ）を備える
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２０】
前記第２のタイプ（ＨＴＴＰ）の制御データ（２ＣＤ１）は第２のタイプのサービス要求を構成し、前記サービス固有マッピング・デバイス（ＡＳ−Ａ（ＲＴＳＰ））は、第１のタイプの制御データ（１ＣＤ１）として、前記アクセス・ネットワーク（ＡＣ）が前記サービスを前記端末デバイスに提供するために十分なリソース（ＲＥＳ）を有するかどうかを前記サービス提供サーバ（ＩＭＳ−Ｓ）に問い合わせる第１のタイプ（ＳＩＰ）の問い合わせ要求を送信し、
前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービス提供サービス（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）があると判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）があることを示す肯定応答メッセージ（ＡＣＫ）を送信し、前記サービス提供サーバ（ＩＭＳ−Ｓ）が十分なリソース（ＲＥＳ）がないと判断した場合、第１のタイプの制御データ（１ＣＤ２）として、前記サービス提供に十分なリソース（ＲＥＳ）がないことを示す否定応答メッセージ（ＮＡＣＫ）を送信する
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２１】
前記端末デバイス（Ｔ２）は、サービス・プロセッサ（ＳＰ）としてＭＰＥＧ２デコーダを有するセット・トップ・ボックス（ＳＴＢ）を備え、前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記サービスメモリ（ＳＥＲＭ）にサービス（ＳＥＲＶ１、ＳＥＲＶ２、ＳＥＲＶ３）として、ＶｏＤ（ビデオオンデマンド）サービスを備え、前記サービス固有マッピング・デバイス（ＡＳ−Ａ）はＲＴＳＰプロキシ・アプリケーションを実行する少なくとも１つのサービス固有マッピング・デバイス（ＡＳ−Ａ（ＶｏＤ））を備え、前記制御プロトコル（ＲＴＳＰ）はＲＴＳＰであり、前記リソース（ＲＥＳ）は、前記アクセス・ネットワーク（ＡＣ）の回線の帯域幅（例えば５ＭＢ）である
ことを特徴とする請求項２０に記載のゲートウェイ装置（ＨｉＧＡ、図２ｃ）。
【請求項２２】
前記ゲートウェイ装置（ＨｉＧＡ）および前記端末デバイス（Ｔ２）は、宅内ネットワーク（ＣＰＮ）の一部である
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２３】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記宅内ネットワーク（ＣＰＮ）のレジデンシャル・ゲートウェイ（ＲＧＷ）に配置される
ことを特徴とする請求項２２に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２４】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記第２のタイプの第１の制御データ（２ＣＤ１）として前記端末デバイス（Ｔ２）からＥＰＧダウンロード要求を受信し、前記ゲートウェイ装置（ＨｉＧＡ）が提供する前記第２のタイプの制御データ（２ＣＤ２）はパーソナル化されたＥＰＧ（電子プログラム・ガイド）を含む
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ｂ）。
【請求項２５】
前記ゲートウェイ装置（ＨｉＧＡ）は、メモリに前記ユーザ・アイデンティティ（ＩＤ１）を含む
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２６】
前記ユーザ・アイデンティティ（ＩＤ１）は、前記ゲートウェイ装置（ＨｉＧＡ）に挿入されたプラグインに格納されるか、または前記ゲートウェイ装置（ＨｉＧＡ）のメモリに挿入されたＵＩＣＣカードに格納される
ことを特徴とする請求項２５に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２７】
前記端末デバイス（Ｔ２）は、セット・トップ・ボックス（ＳＴＢ）、暖房システムの制御装置、住宅監視システム、カメラ、またはインテリジェントハウスの中央住宅制御装置を含むグループから選択された１つ以上のものである
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ａ）。
【請求項２８】
前記制御データ（１ＣＤ１、１ＣＤ２）の前記第１のタイプはＳＩＰ（セッション開始プロトコル）であり、前記制御データ（２ＣＤ１、２ＣＤ２）の前記第２のタイプはＨＴＴＰおよびＵＰｎＰの１つである
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図２ｄ）。
【請求項２９】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）として、前記サービス提供デバイス（ＩＭＳ−Ｓ）から前記ダウンロードされる第１のタイプのＥＰＧを受信し（図４ａのステップ１０：）、前記受信したＥＰＧのフォーマット（Ｘ）を前記端末デバイス（Ｔ２）がサポートするフォーマットに変換する
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図４ａ）。
【請求項３０】
前記ゲートウェイ装置（ＨｉＧＡ）は、前記端末デバイス（Ｔ２）と前記サービス提供デバイス（ＩＭＳ−Ｓ）との間のメディア・セッション確立を呼びかける（図４ａのステップ１７）
ことを特徴とする請求項２９に記載のゲートウェイ装置（ＨｉＧＡ、図４ａ）。
【請求項３１】
前記メディア・セッション確立は、ユニキャスト・メディア・セッション確立である（図４ｂのステップ１：）
ことを特徴とする請求項３０に記載のゲートウェイ装置（ＨｉＧＡ、図４ｂ）。
【請求項３２】
前記メディア・セッション確立は、マルチキャスト・メディア・セッション確立である（図４ｃのステップ１：、５：、６：）
ことを特徴とする請求項３０に記載のゲートウェイ装置（ＨｉＧＡ、図４ｃ）。
【請求項３３】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ）としてＥＰＧ更新メッセージを受信する（図４ｄのステップ２：）
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図４ｄ）。
【請求項３４】
前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプの制御データ（１ＣＤ２）としてイベント・トリガ・メッセージを受信し（図４ｅのステップ１：）、前記イベント・トリガ・メッセージ（１ＣＤ２）に基づいて第２のタイプの制御データ（２ＣＤ２）としてメディア・セッション確立メッセージを前記端末デバイス（Ｔ２）に送信する（図４ｅのステップ２：）
ことを特徴とする請求項１８に記載のゲートウェイ装置（ＨｉＧＡ、図４ｅ）。
【請求項３５】
ゲートウェイ装置（ＨｉＧＡ）と、複数の端末デバイス（Ｔ２…Ｔｎ…ＴＮ）と、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）にアクセス・ネットワーク（ＡＣ）を通してサービス（ＳＥＲＶ）を提供する通信システム（ＳＹＳ）のサービス提供サーバ（ＩＭＳ−Ｓ）との間の通信方法（ＳＹＳ）であって、
−前記サービス提供サーバ（ＩＭＳ−Ｓ）は、前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）に提供する１つ以上のサービス（ＳＥＲ１、ＳＥＲＶ２、ＳＥＲＶ３）を格納するサービスメモリ（ＳＥＲＭ）と、前記１つ以上のサービス（ＳＥＲＶ）に関係して前記ゲートウェイデバイス（ＨｉＧＡ）に第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を提供する少なくとも１つの第１のタイプ（ＳＩＰ）の制御プロトコル（ＩＭＳ−ＣＴＲＬＰ）デバイスとを備え、
−前記端末デバイス（Ｔ２…Ｔｎ…ＴＮ）のそれぞれは、前記サービス提供サーバ（ＩＭＳ−Ｓ）から前記アクセス・ネットワーク（ＡＣ）を通して提供される前記サービス（ＳＥＲＶ）を処理するサービス・プロセッサ（ＳＰ）と、前記サービス・プロセッサ（ＳＰ）による前記サービスの実行に関係して前記第１のタイプとは異なる第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を有する第２のタイプ（非ＳＩＰ）の制御プロトコル（ＴＤ−ＣＰ）デバイスとを備え、
−前記ゲートウェイ装置（ＨｉＧＡ）は、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ）を前記サービス提供サーバ（ＩＭＳ−Ｓ）と交換し、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ）を前記端末デバイス（Ｔ２）と交換する１つ以上のサービス固有マッピング・デバイス（ＡＳ−Ａ）を備え、
少なくとも１つの前記端末デバイス（Ｔ２）から前記ゲートウェイ装置（ＨｉＧＡ）に第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）を提供する工程と、
前記ゲートウェイ装置（ＨｉＧＡ）の前記サービス固有マッピング・デバイス（ＡＳ−Ａ）から前記サービス提供サーバ（ＩＭＳ−Ｓ）に、前記端末デバイス（Ｔ２）から提供された前記第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ１）に基づいて、第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ１）を提供する工程と、
前記サービス提供サーバ（ＩＭＳ−Ｓ）の前記第１のタイプ（ＳＩＰ）の制御プロトコル・デバイス（ＩＭＳ−ＣＴＲＬＰ）から前記ゲートウェイ装置（ＨｉＧＡ）に第１のタイプの制御データ（１ＣＤ２）を提供する工程と、
前記サービス固有マッピング・デバイス（ＡＳ−Ａ）から前記端末デバイス（Ｔ２）に、前記サービス提供サーバ（ＩＭＳ−Ｓ）から提供された前記第１のタイプ（ＳＩＰ）の制御データ（１ＣＤ２）に基づいて、第２のタイプ（非ＳＩＰ）の制御データ（２ＣＤ２）を提供する工程と
を備えることを特徴とする通信方法（ＳＹＳ）。
【図１ａ】
【図１ｂ】
【図１ｃ】
【図２ａ】
【図２ｂ】
【図２ｃ】
【図２ｄ】
【図３】
【図４ａ】
【図４ｂ】
【図４ｃ】
【図４ｄ】
【図４ｅ】
【図１ｂ】
【図１ｃ】
【図２ａ】
【図２ｂ】
【図２ｃ】
【図２ｄ】
【図３】
【図４ａ】
【図４ｂ】
【図４ｃ】
【図４ｄ】
【図４ｅ】
【公表番号】特表２００９−５３９１５８（Ｐ２００９−５３９１５８Ａ）
【公表日】平成２１年１１月１２日（２００９．１１．１２）
【国際特許分類】
【出願番号】特願２００９−５１２４３１（Ｐ２００９−５１２４３１）
【出願日】平成１９年３月２１日（２００７．３．２１）
【国際出願番号】ＰＣＴ／ＥＰ２００７／００２５０３
【国際公開番号】ＷＯ２００７／１４０８３４
【国際公開日】平成１９年１２月１３日（２００７．１２．１３）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２１年１１月１２日（２００９．１１．１２）
【国際特許分類】
【出願日】平成１９年３月２１日（２００７．３．２１）
【国際出願番号】ＰＣＴ／ＥＰ２００７／００２５０３
【国際公開番号】ＷＯ２００７／１４０８３４
【国際公開日】平成１９年１２月１３日（２００７．１２．１３）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]