ＩＭＳアーキテクチャ・ネットワークにおけるＩＰサービスに渡ってテレビジョンにアクセスするためのシステム
サービスにより提供されるテレビ・チャンネルに加入しているユーザの端末（１０）からＩＭＳアーキテクチャ・ネットワーク（２）におけるＩＰに渡るテレビ（ＩＰＴＶ）サービスを活性化するシステムに関する。該システムは、ＩＭＳアーキテクチャ・ネットワーク内に、ユーザをチャンネルに関連させる加入情報と、チャンネルのために必要な受信容量に関する情報とを含み、端末は、受信容量情報を含んでテレビ・サービスの活性化を要求するメッセージをサーバ（２３）に送るための手段を含む。サーバは、端末から受信された受信容量情報及びチャンネルのために必要とされる受信容量情報間の両立性をチェックし、両立性が確認されたならば、活性化要求メッセージに応答してメッセージを端末に送り、応答メッセージは、チャンネルのＩＰアドレスを含む。本発明は、視聴覚データがＩＭＳにおいて同報通信されるのを可能とするＩＰネットワークに適用可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにログされたユーザの端末からＩＭＳ（ＩＰマルチメディア・サブシステム）アーキテクチャを有するＩＰ（インターネット・プロトコル）ネットワークにおけるサービスを活性化するための技術に関する。
【０００２】
本発明は、３ＧＰＰ（第三世代パートナーシップ・プロジェクト）及びＴＩＳＰＡＮ（進歩したネットワーキングのためのテレコミュニケーション及びインターネット集中サービス及びプロトコル）の標準化機構によって限定されるＩＰマルチメディア・サブシステムにおける視聴覚データを同報通信するためのＩＰネットワークにおいて特に有利な応用を発見する。
【背景技術】
【０００３】
ＩＭＳネットワーク・アーキテクチャは、移動性のネットワークのために３ＧＰＰによってもたらされ、かつ次に固定のネットワークのためにＴＩＳＰＡＮによって採用された。それは、２人のクライアント間のマルチメディア・セッションの動的セットアップ及び監視を提供し、かつメディア・ストリーム・トランスポート・ネットワーク・レベルにおけるリソースの予約（リザベーション：reservation）を提供する。それは、また、サービスの対話（相互作用）も管理する。
【０００４】
現在においては、ＩＭＳは、電話、テレビ電話、プレゼンス（presence）、及びインスタント・メッセージング・サービスに対してのみのアクセスを提供する。
【０００５】
インターネット・プロトコルに渡るテレビジョン（ＩＰＴＶ）サービスは、テレビジョン・チャンネルが、ＩＰネットワークにおいて受信されるのを可能とする。ＩＰＴＶサービスを提供することは、ユーザが加入しているチャンネルのアドレスを端末が得ることを必要とする。
【０００６】
このサービスを提供するための現在の解決法は、普通、私有の解決法である。これらの解決法は、ユーザ端末が、固定または移動のネットワークにおけるＩＰＴＶ専用のプラットフォームを介して、“サービス・プラン”と称する認可されたチャンネルのＩＰアドレスのリストを回収する（recover）ことを可能とする。このリストは、ＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル）を用いて回収され得、サービス・プランは、該プロトコルによって運ばれるデータ内に含まれている。対照的に、チャンネルのリストと関連したリソースの予約は限定されず、それは、柔軟性をもたずに、しばしば静的である。
【０００７】
ＩＭＳアーキテクチャの欠点は、それが、固定のまたは移動のネットワークにおけるＩＰＴＶサービスの履行を提供しないということである。ＩＭＳにおいて提供されるメカニズムは、マルチメディア・サービスのための一般的な手続きを限定するけれども、ＩＰＴＶサービスの一体化の仕方を限定しない。特に、規格の現在のバージョンにおいては、サービス・プラン、すなわち、ユーザが加入するチャンネル及び対応のＩＰアドレス、を回収するための規定がない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、ＩＰＴＶサービスが固定または移動のＩＰネットワークのためのＩＭＳアーキテクチャに一体化されるのを可能とし、かつユーザと関連したサービス・プランが回収されるのを可能とするシステムを限定する技術に対する必要性がある。
【課題を解決するための手段】
【０００９】
本発明は、前記ネットワークにログされたユーザ端末からＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスするためのシステムを提案することによって、上記必要性を取り扱うものである。
【００１０】
本発明によれば、前記サービスは、ＩＰサービスに渡るテレビジョンであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、そして前記システムは、前記端末によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記選択された少なくとも１つのチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末に送るために、
活性化される手段を含むアプリケーション・サーバを含む。
【００１１】
このように、ＩＭＳアーキテクチャは、ＩＭＳにおける端末を登録するときにＩＰＴＶサービスの一体化を可能とする。本発明により、ＩＰＴＶサービスは、従って、ＩＭＳの長所、すなわち固定／移動の一体化、相互化、及びサービスのための汎用機構、サービスの相互作用、ネットワーク・リソースの予約、相互化された取扱高、等を享受することができ、このことは、従来技術におけるＩＰＴＶサービスに対して使用された技術においては可能ではなかった。さらに、視聴覚サービスを履行することは、ＩＭＳサービスの提供を質的に非常に向上させる。
【００１２】
本発明の利点は、本発明が、ＩＰＴＶサービスをＩＭＳアーキテクチャに一体化することが可能となるように、ユーザと関連したサービス・プランの回収を可能とするＩＭＳアーキテクチャのフレームワークにおける新しい手順を提案したことである。
【００１３】
この手順は、特に、サービスと関連したデータベースにおけるＩＰＴＶアプリケーション・サーバによるユーザの権利の認証に依存しており、かつ、ユーザが加入するチャンネルのリストから１つまたは２つ以上のチャンネルの該サーバによる選択に依存している。この選択は、端末によって提供される受信容量が任意の特定のテレビジョン・チャンネルに対して必要とされる受信容量と両立し得るということを前以って確認することに依存している。
【００１４】
本発明は、また、サービス・アクセス要求のために、及び（ＩＰＴＶアプリケーション・サーバによって採用されていた、ユーザが加入しているチャンネルに関する情報の、特にＩＰトランスポート・ネットワークにおけるＴＶチャンネルの名称及びアドレスの）端末による回収のために、例えばＳＩＰ（セッション開始プロトコル）タイプの報知プロトコルに連結される手順をも用いる。このため、ＳＩＰアクセス要求メッセージの受信時に、ＩＰＴＶアプリケーション・サーバは、ＳＩＰ応答メッセージのＳＤＰ（セッション記述プロトコル）パラメータにおける加入されたチャンネルのリストに受信情報を挿入し、そして該情報を応答メッセージと共にユーザ端末に送る。
【００１５】
端末によって送られるサービス・アクセス要求は、サービスの初期活性化のための要求（例えば、視聴覚端末のスイッチ・オン時の）、またはサービスを変更するための要求（例えば、端末が、例えば考慮されるチャンネルのようなすでにアクセスしたサービスのパラメータの或るものを変更しようとしている場合に）であることができる。
【００１６】
このような要求は、従って、端末によって要求されるサービスに関するパラメータ、例えば、それが考慮するよう追求しているチャンネルの識別子またはサービスの要求されたレベルを含み得る。
【００１７】
一実施形態の一つの長所的特徴によれば、本発明のシステムは、また、前記端末が前記選択された少なくとも１つのチャンネルを受信するために必要なトランスポート・ネットワークのリソースを予約するための手段をも含む。
【００１８】
インターネット・プロトコル・システムに渡る従来技術のテレビジョンにおいては設けられていないこのようなリソースの予約は、考慮されるべきテレビジョン・チャンネルと関連したストリームのユーザ端末による良好な受信を可能とするという点において特に有益である。しかしながら、充分なリソースを有するトランスポート・ネットワークにおいては、このような予約は、厳密には必要でない。
【００１９】
これらのリソース予約手段は、ＩＭＳアーキテクチャ・ネットワークのプロキシ・サーバにおいて履行されることができ、そしてプロキシ・サーバが端末からサービス・アクセス要求に対するＩＰＴＶアプリケーション・サーバからの応答を受信するときにトリガされる。
【００２０】
従って、最終的な分析において、本発明のシステムは、ＩＰＴＶサービスが、特に以下の点において、ＩＭＳアーキテクチャ・ネットワークの多くの利点を享受するのを可能とする：
・ ＴＶチャンネルを受信するために必要なＩＰトランスポート・ネットワークにおけるリソースを予約するためのＩＭＳに固有のメカニズム；
・ ＩＭＳサービス間の相互作用に関するＩＭＳエンティティにおいて限定されるメカニズム；
・ ＩＭＳにおいて限定されるチャージング・メカニズム；そして
・ それ故、ＩＭＳサービスの提供は、視聴覚サービスの提供により質的に向上され得る。
【００２１】
本発明の一つの長所的な特徴によれば、前記端末によって提供される前記受信容量は、
・ 前記サービス・アクセス要求に含まれる受信容量情報、及び／または
・ 前記端末の型、
に基づいて決定される。
【００２２】
例えば、サービスにアクセスするために端末によって送られるＩＮＶＩＴＥメッセージに示され得るこのタイプは、端末によって提供される受信容量の良好な指示を構成し、従って、端末が考慮することを認可されるテレビジョン・チャンネルを選択するためにＩＰＴＶアプリケーション・サーバによって用いられることができる。
【００２３】
サービス・アクセス要求に含まれる受信容量情報は、ネットワークへの端末の接続のためのパラメータにリンクされた容量情報（例えば、ユーザが彼等の加入の関数として権利付与される最大のビット・レート）、または、端末によって必要とされるサービスのレベルに関する情報（例えば、端末が標準限定（ＳＤ）または高限定（ＨＤ）におけるテレビジョン・チャンネルを受信することが必要であるか否か）に対応することができる。
【００２４】
前記受信情報は、長所的には、
・ 前記選択されたチャンネルの識別子、
・ 前記選択されたチャンネルのアドレス、
・ 前記選択されたチャンネルに対して必要とされる受信容量、または例えばビット・レートのようなチャンネルの一層総括的なネットワーク特徴、及び
・ 例えば親制御の文脈において用いられ得る、前記選択されたチャンネルの内容を表す情報、
を含むグループに属する。
【００２５】
本発明のもう１つの態様によれば、前記ＩＭＳアーキテクチャ・ネットワークは、前記ユーザ端末を前記アプリケーション・サーバの１つに関連させる情報へのアクセスを有しかつ前記端末に関連した前記アプリケーション・サーバへの前記サービス・アクセス要求をルーティングするための手段を含むルーティング・サーバを含む。
【００２６】
この実施形態においては、登録中及びＩＭＳとの端末の認可中に、Ｓ−ＣＳＣＦ（サービング−コール・セッション・コントロール・ファンクション）サーバとしてＩＭＳにおいて知られているルーティング・サーバは、ユーザが加入するサービスのセットの検出点についてユーザのプロフィルを含むデータベースからＩＰＴＶサービスと関連したＩＦＣ（初期フィルタ規準）検出点を回収する。ユーザ・プロフィルを含むデータベースは、ＴＩＳＰＡＮによって限定されるものとしてＵＰＳＦ（ユーザ・プロフィル・サーバ・ファンクション）データベース、または、３ＧＰＰによって限定されるものとしてＨＳＳ（ホーム加入者サーバ）データベースのいずれかである。
【００２７】
ＩＰＴＶサービス・アクセス要求の受信時に、メッセージにおいてユーザを識別したＳ−ＣＳＣＦサーバは、ユーザのデータベースから関連の検出点、及び特にＩＰＴＶアプリケーション・サーバに対応するもの、を回収する。従って、それは、端末によって送られるアクセス要求についてそれがトリガしなければならないＩＰＴＶアプリケーション・サーバ・ルーティングを識別する。
【００２８】
本発明の異なった実施形態においては、端末によって送られるサービス・アクセス要求は、アプリケーション・サーバのアドレス、すなわちＩＭＳアーキテクチャ・ネットワークにおけるテレビジョン・サーバのルーティング識別子を含む。
【００２９】
該識別子は、ＳＩＰユニフォーム・リソース識別子（ＵＲＩ）であり得る。
【００３０】
ＩＰＴＶサービスのメッセージを要求する活性化は、次に、単にルータとして働くＳ−ＣＳＣＦサーバを介してＩＰＴＶアプリケーション・サーバに直接ルーティングされる。
【００３１】
本発明のもう１つの長所的特徴によれば、前記ユーザ端末は、前記選択されたチャンネルのための前記受信情報を処理するための手段と、前記チャンネルに対応するストリームを受信するための手段とを含む。例えば、端末は、受信情報から、それが考慮することを追及するテレビジョン・チャンネルのＩＰアドレスを抽出し、そしてトランスポート・ネットワークを介してＴＶソースから該チャンネルと関連したストリームを得るために該ＩＰアドレスを用いる。
【００３２】
本発明の一つの長所的な実施形態においては、前記アプリケーション・サーバは、また、前記端末によって送られる前記アクセス要求に含まれるセッション識別子を決定するための手段と、前記セッション識別子が前記端末との進行中にすでにセッションに対応するか否かを確認するための手段とを含む。
【００３３】
端末とのセッションがすでに進行中であるということをＩＰＴＶアプリケーション・サーバが検出したならば、セッション識別子は、同じ端末から受信された先の要求に対して変化されないので、それは、受信された要求が初期設定要求でなく、むしろサービス要求の変化であると推論する。それは、次に、現在のセッションを維持し、そしてユーザ端末からの新しい要求に応答するために、端末に応答を送るためのその手段を活性化して、その応答メッセージ内に、その先の応答メッセージと比較される変化した受信情報を挿入する。
【００３４】
本発明は、また、ＩＰネットワークにログされるユーザ端末からＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスするためのシステムのアプリケーション・サーバにも関する。本発明によれば、前記サーバは、ＩＰＴＶサーバであり、かつ、前記端末によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記少なくとも１つの選択されたチャンネルの受信に関する少なくとも情報を含む、前記要求に対する応答を、前記ユーザ端末に送るために、
活性化される手段を含む。
【００３５】
本発明は、さらに、ＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスするための端末に関し、該端末は、前記ＩＭＳアーキテクチャ・ネットワークのＩＰアプリケーション・サーバを渡ってテレビジョンにＩＰＴＶサービス・アクセス要求を送るための手段を含み、前記端末のユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、そして前記アクセス要求は、前記端末によって提供される受信容量に関する情報を含み、
前記端末は、前記アプリケーション・サーバによって送られる前記要求に対する応答を処理するための、そして前記アプリケーション・サーバによって前記リストにおいて選択されたチャンネルの受信に関する情報を含むための手段を含み、そして
前記端末は、前記少なくとも１つの選択されたチャンネルに対応するストリームを受信するための手段を含む。
【００３６】
本発明は、さらに、ＩＰネットワークにログされるユーザ端末からＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスする方法に関する。本発明によれば、前記サービスは、ＩＰＴＶサービスであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、
当該方法は、
前記端末によって送られるサービス・アクセス要求を受信するステップと、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルを受信するために必要な容量に関する情報を決定するステップと、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するステップと、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するステップと、
少なくとも１つの選択されたチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末に送るステップと、
を含む。
【００３７】
最後に、本発明は、サービスにアクセスする上述の方法のステップを実行するためのプログラム・コード命令を含むコンピュータ・プログラムに関する。
【００３８】
非制限的な例として提供される添付図面を参照して行われる以下の説明は、本発明が何に存するか及びそれが実行されるために如何に減少され得るかを明瞭に説明している。
【発明を実施するための最良の形態】
【００３９】
図１は、ＩＰトランスポート・ネットワーク１上のＩＰＴＶサービスを活性化するためのシステムを示しており、ここに、該ＩＰトランスポート・ネットワーク１は、端末１０のユーザがオペレータまたは関連の第三者プロバイダによって提供される１つまたは２つ以上のテレビジョン・チャンネルに前以って加入していたときに、該ＩＰトランスポート・ネットワーク１を介して、端末１０がＴＶソース２０によって提供されるメディア・ストリームを受信することができるものである。
【００４０】
端末１０は、固定または移動の端末であり、視聴覚コンテントを再生するための手段、及びＳＩＰ報知（signaling）手段を含む。本発明の文脈において、端末１０は、従来技術の視聴覚端末（テレビジョンのような）、及び、例えば、２つの要素を物理的に分離することができるまたは同じユニットに一体化されることができる、ＳＩＰクライアントであって良い。従って、端末１０は、スクリーンを有した移動電話であって良く、または、セット・トップ・ボックス及びディスプレイ・スクリーン、等を一体化することができる。
【００４１】
図１に示されるように、ＩＰＴＶサービスは、以下のものを含むＩＭＳアーキテクチャ・ネットワーク２において端末１０から活性化される：
・ ＩＭＳネットワークにおけるユーザ加入者の端末１０との第１の接触点であり、ＩＰトランスポート・ネットワーク１のリソースとの対話を管理する、Ｐ−ＣＳＣＦ（プロキシ−コール・サーバ・コントロール・ファンクション）プロキシ・サーバ２１：
・ ＩＭＳネットワークにおける、かつユーザが加入するサーバへの特定のトリガ点（検出点またはＩＦＣとしても知られている）における加入者を管理するＳ−ＣＳＣＦルーティング・サーバ２２であって；該Ｓ−ＣＳＣＦサーバ２２は、ＩＭＳネットワークでの端末１０の登録中に、図示しないＩ−ＣＳＣＦ（問い合わせ（interrogating）ＣＳＣＦ）サーバによってユーザに割当てられる；
・ 従来技術のＩＭＳアーキテクチャと比較される本発明のＩＭＳアーキテクチャの新しい要素である、ＩＰに渡るテレビジョン・アプリケーション・サーバ（ＩＰＴＶ ＡＳ）２３であって；それは、以下に詳細に記載される手順に従って、サービスを活性化するためのユーザによる要求に続いて、ユーザが加入するものから１つまたは２つ以上のチャンネルをユーザに割り付けるためのＳＩＰサーバであり；ＩＰＴＶアプリケーション・サーバ２３は、サービスのオペレータによって、または加入されたチャンネルのような関連の第３者プロバイダによって供給されるユーザの加入に関する情報、及び、受信容量及び各チャンネルのＩＰアドレスのようなトランスポート・ネットワーク１に関する情報を含む；そして
・ 加入されたサービスについて、ここでは特に、ユーザが加入することを望むテレビジョン・チャンネルによって限定されるＩＰＴＶサービスについて、ユーザのプロフィルを含むＵＰＳＦまたはＨＳＳデータベース２４であって；このデータベース２４には、また、ユーザがウェブページを介してまたは電話によって加入を取った後、サービス・オペレータまたは関連の第３者プロバイダによってデータが供給され；それは、ユーザと関連した検出点、特に、ＩＰＴＶアプリケーション・サーバ２３のもの、を含み；Ｓ−ＣＳＣＦ及びＩ−ＣＳＣＦ ＳＩＰのプロキシは、ユーザ端末の登録中にデータベース２４に質問する。
【００４２】
上述したＩＭＳアーキテクチャ・ネットワーク２において、Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、及びＩ−ＣＳＣＦ ＳＩＰのプロキシ・サーバの対または３つのすべては同じ設備内で結合され得る。
【００４３】
ＩＰＴＶサービスへの加入の後にユーザがそれを活性化することを望むとき、ＩＭＳネットワーク登録の段階は、そのようなものとして、活性化またはアクセス段階に先行する。
【００４４】
登録段階は、自動的に行われるか、または、特にＩＭＳネットワーク２における加入者の識別子を含む登録メッセージ、例えばＳＩＰレジスタ・メッセージ、を送る端末１０によって行われる。レジスタ・メッセージは、Ｐ−ＣＳＣＦプロキシ・サーバ２１に達し、該サーバ２１は、それを、端末１０にＳ−ＣＳＣＦサーバ２２を割当てる、図示しないＩ−ＣＳＣＦサーバに送る。
【００４５】
第１の実施形態においては、Ｓ−ＣＳＣＦサーバ２２は、ＵＰＳＦまたはＨＳＳデータベース２４から、ＩＰＴＶサービスを活性化するためのＩＰＴＶアプリケーション・サーバ２３の検出点を含む関連の検出点を回収する。
【００４６】
もう１つの実施形態においては、オペレータは、以下に説明されるＳＩＰ Ｉｎｖｉｔｅサービスに、ＩＰＴＶアプリケーション・サーバ２３のルーティング識別子ＳＩＰ ＵＲＩを含めるよう選択することができる。ＩＰＴＶサービスに関しては、Ｓ−ＣＳＣＦサーバ２２は、ＩｎｖｉｔｅメッセージをＩＰＴＶアプリケーション・サーバ２３にルーティングするためのルータとしてのみ動作する。
【００４７】
この方法でＩＭＳネットワーク２で登録されて、端末１０は、図２を参照して以下に説明されるサービス活性化手順を用いてＩＰＴＶサービスにアクセスすることができる。
【００４８】
ＩＭＳネットワーク２での登録後に、ユーザは、登録された状態Ａにあり、そして例えばそれらの固定テレビジョンをスイッチ・オンすることにより、またはそれらの移動電話上でＴＶアプリケーションを活性化することにより、端末１０からＩＰＴＶサービスの活性化をトリガする。
【００４９】
固定のまたは移動の端末は、ステップＥ１においてＩＰＴＶサービスへのアクセスを要求するＳＩＰ ＩｎｖｉｔｅメッセージＭ１を、Ｐ−ＣＳＣＦサーバ２１に送る。このメッセージは、チャンネル、例えば、支援されるコーデックと、端末（“ｚａｐｐｉｎｇ”）上のチャンネルの選択を可能とする制御プロトコルのデスクリプション、例えば、ＩＧＭＰ（インターネット・グループ・マネージメント・プロトコル）とを受信するよう、その容量に関する、端末によって提供される情報に特に関係するＳＤＰデータを含む。
【００５０】
Ｐ−ＣＳＣＦサーバ２１は、ステップＥ２においてユーザを管理するＳ−ＣＳＣＦサーバ２２に、ＩｎｖｉｔｅメッセージＭ２を送る。
【００５１】
登録中、検出点またはＩＦＣ（Ｉｎｉｔｉａｌ Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉｏｎ）は、ＩＰＴＶサービスに関係するレジスタ・メッセージの受信時に、Ｓ−ＣＳＣＦサーバ２２にセットされていた。Ｓ−ＣＳＣＦサーバ２２は、（Ｂ）この検出点を認識し、そしてＩｎｖｉｔｅメッセージをＩＰＴＶアプリケーション・サーバ２３に送る。もちろん、上に示したように、ＩＰＴＶアプリケーション・サーバ２３に関するあて先ＵＲＩがＩｎｖｉｔｅメッセージ内に直接示されるならば、このことは必須ではない。
【００５２】
メッセージの受信時、Ｓ−ＣＳＣＦサーバ２２は、活性化要求Ｍ３をＩＰＴＶアプリケーション・サーバ２３に送る（ステップＥ３）。
【００５３】
それがＩｎｖｉｔｅメッセージを受信したとき、ＩＰＴＶアプリケーション・サーバ２３は、サービスに関連したデータベースにおいて加入者の権利を確認し、そして加入されたチャンネルのリストから１つまたは２つ以上のチャンネルを抽出する。サービス・プランとしても知られているこのチャンネルのリストは、（Ｃ）各チャンネルを受信するために必要とされる容量に関する情報と、例えば、ＳＤＰに示される容量から来るかまたはＩｎｖｉｔｅメッセージに示される端末の型から来ることができる端末の受信容量に関する情報と、の両立性（compatibility）を確認することによって決定される。このリストは、加入されたチャンネルの全リストを重複することができる。選択されたチャンネルのリストは、各チャンネルごとに、以下を含む：
・ チャンネル識別子、例えばその名称；
・ チャンネルＩＰアドレス；及び
・ 適切な場合には、必要とされるビット・レートのような、トランスポート・ネットワーク１におけるチャンネルの特性。
【００５４】
ＩＰＴＶアプリケーション・サーバ２３によって送られる応答Ｍ４（ステップＥ４）は、ＳＤＰパラメータに挿入される、選択されたチャンネルのリストを含む。この応答は、成功の場合には、ＳＩＰ ２００ ＯＫメッセージであることができ、もう１つのＳＩＰメッセージは、他の中間交渉交換または失敗メッセージをトリガする。
【００５５】
アプリケーション・サーバによって特定されるチャンネルのＩＰアドレスは、以下であり得る：
・ マルチキャスト・グループ・アドレス；及び
・ ユニキャスト・アドレス。
【００５６】
チャンネルのリストは、ＳＤＰパラメータにおいて運ばれる。用いられるトランスポート・プロトコル、例えば、ＭＰＥＧ２−ＴＳまたはＲＴＰ（実時間プロトコル）、に依存して、特定のチャンネルが、１つまたは２つ以上のＳＤＰ媒体パラメータに記述され得る。媒体記述は、チャンネルがどのストリームに対応するのかを端末１０が見つけ出すのを可能とするチャンネルの識別子を含まなければならない。この識別子は、また、同じチャンネルに関する媒体の相関を可能とする。例えば、それは、チャンネルの名称、及びそれが同報通信されるバンドルを含み得る。ＳＤＰ媒体タイトル・パラメータｉは、チャンネルを指定するために用いられ得る。媒体は、また、例えばフィールドｃ（接続情報）においてチャンネルのＩＰアドレスを含まなければならない。このＩＰアドレスは、端末１０が、選択（ｚａｐｐｉｎｇ）プロトコルによって要求されたチャンネルを受信するのを可能とする。例えば、固定のＡＤＳＬアクセスに渡るＩＰＴＶに対して、もしチャンネルがマルチキャスト・モードにおいて同報通信されるならば、このアドレスは、チャンネルが同報通信されるマルチキャスト・アドレスである。
【００５７】
ＳＩＰ応答メッセージの受信時、Ｐ−ＣＳＣＦサーバ２１は、選択されたチャンネルを同報通信するために必要なトランスポート・ネットワーク１のリソースの予約（Ｄ）を活性化し、そして、また、端末１０上で選択されなかったチャンネルを選択するユーザを除外する（bar）ポリシ（政策）をインストールすることもできる。
【００５８】
リソースの予約は、３ＧＰＰ及びＴＩＳＰＡＮ仕様に従う。ＴＶチャンネルの数は、媒体パラメータの形態でＳＤＰパラメータに存在し得る。ＳＤＰ内に存在する種々のチャンネルは、単一のリソース予約の主題であることができなければならない。１つのチャンネルだけが一度に観察され得るということが与えられると、すべてのチャンネルに対して別々にリソースを予約することは必要でない。ＩＰＴＶアプリケーション・サーバ２３は、これを、ＲＦＣ３３８８（媒体グループ化）及びＲＦＣ３５２４（各媒体ストリームに対するリソースの予約）に示された方法を用いて、ＳＤＰにおいて特定することができる。
【００５９】
移動電話に対して、３ＧＰＰによって限定されるように、Ｐ−ＣＳＣＦサーバ２１は、ＰＤＦ（ポリシ決定機能）と相対させてリソースを予約する。必要ならば、端末は、次に、チャンネル選択（ｚａｐｐｉｎｇ）プロトコル及び選択されたＴＶチャンネルを搬送するための１つまたは２つ以上のＰＤＰ（パケット・データグラム・プロトコル）の文脈を創設するための責任がある。
【００６０】
固定された端末に対しては、ＴＩＳＰＡＮグループによって限定されるように、Ｐ−ＣＳＣＦサーバ２１は、トランスポート・ネットワーク１のためのルール及びリソースを創設するための責任があるリソース及びアドミッション制御サブシステム（ＲＡＣＳ）に、リソースのための要求を創設する。
【００６１】
Ｐ−ＣＳＣＦサーバ２１は、応答Ｍ５を端末１０に送る（ステップＥ５）。後者の端末は、次に、許可されたチャンネル及びそれらの関連のアドレスのリストを有する。端末は、チャンネルを受信して、特に移動ネットワークのためのチャンネル選択（ｚａｐｐｉｎｇ）コマンドを伝達するために、リソースのための要件に対応する１つまたは２つ以上の特定のチャンネルを開始することができる。
【００６２】
最後に、メッセージＭ６によって、端末１０は、ＩＰＴＶアプリケーション・サーバ２３からの応答の受信通知をする（ステップＥ６）。
【００６３】
ユーザが端末１０上のチャンネルを変化させるならば、どんな方法によってでも、該チャンネルの変化は、ＳＩＰメッセージ、例えば、Ｐｕｂｌｉｓｈメッセージを送ることによって報知される（signaled）ことができ、該ＳＩＰメッセージは、ＩＰＴＶアプリケーション・サーバ２３に中継されて、特に聴衆サーベイを行うために用いられる。このＳＩＰメッセージは、チャンネルの各変化時に送られることができるか、または、例えばユーザが選択されたチャンネル上に１０秒以上留まるならば、チャンネルの変化及び時間遅延に続いて送られることができる。このメカニズムは、現存する要素、またはプレゼンス管理のためのＩＭＳアーキテクチャにおいて限定される要素の再使用を可能とする。
【００６４】
受信されたＴＶストリームを制御するためのチャンネル選択（ｚａｐｐｉｎｇ）プロトコルは、例えば、マルチキャスト・ストリームによって同報通信されるチャンネルのためのＩＧＭＰであることができる。応答メッセージのＳＤＰパラメータは、次に、各チャンネルごとの対応のマルチキャスト・グループ・アドレスを含む。同じチャンネルに対してＩＰＴＶアプリケーション・サーバ２３によって戻されたグループ・アドレスは、端末１０の容量及びその型に従って異なり得る。
【００６５】
端末１０からのチャンネルを選択するためのこのプロトコルは、また、ＲＴＳＰ（リアル・タイム・ストリーミング・プロトコル）であることもできる。
【００６６】
トランスポート・ネットワーク１のための結果を有するＩＰＴＶサービス・レベルの変化は、サービス活性化段階に対して記載されたＳＩＰメカニズムを使用することができる。それは、彼等が最初に活性化したものとは異なるＩＰＴＶサービスにユーザがアクセスすることを望む場合に（例えば、ユーザが考慮することを望むチャンネルまたは該チャンネルの限定レベルを変化させる場合に）端末１０においてトリガされる。端末は、次に、上述の手順を開始するが、同じＩＭＳセッションに対しては、すなわち現在のセッションと同じセッション識別子の場合には、その結果は、必要に応じて、リソース予約を変化させるべきである。
【００６７】
１つの特に適切な使用は、チャンネルの限定レベルを変化させること：ＳＤ（標準限定）からＨＤ（高限定）に変化させることである。リソース予約は、次に、チャンネルの１つのセットからもう１つのセットで異なる。
【００６８】
一層詳細には、端末は、ＩＰＴＶアプリケーション・サーバ２３に、現在のセッション及び必要とされる限定レベルのＩＭＳセッション識別子及び／または要求されたチャンネルの識別子を含むアクセス要求を送る。ＩＰＴＶアプリケーション・サーバ２３は、次に、ＩＭＳセッション識別子が変化しなかったということを検出し、そしてすでに開いているセッションに対応する。従って、現在のセッションに対して変更されなければならない受信情報をＳＤＰメッセージにおいてそれに単に送ることにより、ＩＭＳセッションを変化させることなく、それは、端末１０からの要求に応答する。
【００６９】
従って、もし、端末１０のユーザが、ＳＤモードにおいて同報通信された識別子ＣＨ１を有するチャンネルを使用し、そしてＨＤモードにおいてのみ同報通信される識別子ＣＨ２を有するもう１つのチャンネルに“飛ばす（ｚａｐ）”ことを望むならば、端末１０は、現在のＩＭＳセッションの識別子及び彼等が考慮することを望むチャンネルの識別子ＣＨ２を含むＩＰＴＶアプリケーション・サーバ２３に要求を送る。ＩＰＴＶアプリケーション・サーバ２３は、ＩＭＳセッション識別子が変化しなかったこと、及び従って現在のセッションが続かなければならないこと、を検出する。それは、端末１０の受信容量、及びＨＤモードにおいて同報通信されるチャンネルＣＨ２を受信するために必要とされる受信容量の両立性を確認する（例えば、それは、端末がＨＤストリームを受信することができて、例えばＳＤストリームを受信することに制限しないということを確認する）。もし、両立性が確認されるならば、それは、端末１０に応答メッセージを送るためのその手段を活性化し、該メッセージ内には、それが、端末１０が必要とするＣＨ２に関する受信情報、例えば、チャンネルＣＨ２のＩＰアドレスを挿入する。
【００７０】
ＩＰＴＶサービスを終了することは、トランスポート・ネットワーク１におけるリソースの解放（リリース）をトリガするＳＩＰメッセージＢｙｅを送ることに対応する。サービス終了段階中のＳＩＰ交換の運動力学が、図３に示されている。
【００７１】
端末１０のユーザは、例えば、移動電話上のＴＶアプリケーションをスタンドバイするまたはシャット・ダウンするためにテレビジョンをスイッチングする、ＩＰＴＶサービスを出ることを決定した。それは、ＢｙｅメッセージＭ７をＰ−ＣＳＣＦサーバ２１に送る（ステップＦ１）。移動電話に対しては、端末１０は、１つまたは２つ以上のＰＤＰ文脈の非活性化を開始することができる。
【００７２】
Ｐ−ＣＳＣＦサーバ２１は、ＩＰＴＶサービスに割付けられたトランスポート・ネットワーク１のリソースを自由にする（Ｅ）。
【００７３】
Ｐ−ＣＳＣＦサーバ２１は、ＢｙｅメッセージＭ８をＳ−ＣＳＣＦサーバ２２に送る（ステップＦ２）。
【００７４】
Ｓ−ＣＳＣＦサーバ２２は、ＢｙｅメッセージＭ９を、ＳＩＰメッセージに応答するＩＰＴＶアプリケーション・サーバ２３に送る。
【００７５】
ＳＩＰ応答メッセージＭ１０は、Ｓ−ＣＳＣＦサーバ２２及びＰ−ＣＳＣＦサーバ２１を介して端末１０に送られる（ステップＦ４）。
【００７６】
本発明は、また、上述したサービス・アクセス方法のステップを実行するためのプログラム・コード命令を含むコンピュータ・プログラムをも提供する。
【００７７】
プログラムまたはソフトウェア・モジュール・コード命令は、データ媒体に記憶されるまたはデータ媒体によって送信されることができ、該データ媒体は、物質の記憶媒体、例えば、ＣＤ−ＲＯＭ、磁気ディスクまたはハードディスクであることができ、もしくは、電気、光または無線信号のような送信可能な媒体であることができ、もしくは遠隔通信ネットワークの送信媒体であることができる。
【図面の簡単な説明】
【００７８】
【図１】ＩＰＴＶサービスを活性化するための本発明のネットワーク・アーキテクチャを示す図である。
【図２】テレビジョン・サービスの活性化段階を示す図である。
【図３】テレビジョン・サービスの遮断段階を示す図である。
【符号の説明】
【００７９】
１ ＩＰトランスポート・ネットワーク
２ ＩＭＳアーキテクチャ・ネットワーク
１０ 端末
２０ ＴＶソース
２１ Ｐ−ＣＳＣＦプロキシ・サーバ
２２ Ｓ−ＣＳＣＦルーティング・サーバ
２３ ＩＰＴＶアプリケーション・サーバ
２４ ＵＰＳＦまたはＨＳＳデータベース
【技術分野】
【０００１】
本発明は、ネットワークにログされたユーザの端末からＩＭＳ（ＩＰマルチメディア・サブシステム）アーキテクチャを有するＩＰ（インターネット・プロトコル）ネットワークにおけるサービスを活性化するための技術に関する。
【０００２】
本発明は、３ＧＰＰ（第三世代パートナーシップ・プロジェクト）及びＴＩＳＰＡＮ（進歩したネットワーキングのためのテレコミュニケーション及びインターネット集中サービス及びプロトコル）の標準化機構によって限定されるＩＰマルチメディア・サブシステムにおける視聴覚データを同報通信するためのＩＰネットワークにおいて特に有利な応用を発見する。
【背景技術】
【０００３】
ＩＭＳネットワーク・アーキテクチャは、移動性のネットワークのために３ＧＰＰによってもたらされ、かつ次に固定のネットワークのためにＴＩＳＰＡＮによって採用された。それは、２人のクライアント間のマルチメディア・セッションの動的セットアップ及び監視を提供し、かつメディア・ストリーム・トランスポート・ネットワーク・レベルにおけるリソースの予約（リザベーション：reservation）を提供する。それは、また、サービスの対話（相互作用）も管理する。
【０００４】
現在においては、ＩＭＳは、電話、テレビ電話、プレゼンス（presence）、及びインスタント・メッセージング・サービスに対してのみのアクセスを提供する。
【０００５】
インターネット・プロトコルに渡るテレビジョン（ＩＰＴＶ）サービスは、テレビジョン・チャンネルが、ＩＰネットワークにおいて受信されるのを可能とする。ＩＰＴＶサービスを提供することは、ユーザが加入しているチャンネルのアドレスを端末が得ることを必要とする。
【０００６】
このサービスを提供するための現在の解決法は、普通、私有の解決法である。これらの解決法は、ユーザ端末が、固定または移動のネットワークにおけるＩＰＴＶ専用のプラットフォームを介して、“サービス・プラン”と称する認可されたチャンネルのＩＰアドレスのリストを回収する（recover）ことを可能とする。このリストは、ＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル）を用いて回収され得、サービス・プランは、該プロトコルによって運ばれるデータ内に含まれている。対照的に、チャンネルのリストと関連したリソースの予約は限定されず、それは、柔軟性をもたずに、しばしば静的である。
【０００７】
ＩＭＳアーキテクチャの欠点は、それが、固定のまたは移動のネットワークにおけるＩＰＴＶサービスの履行を提供しないということである。ＩＭＳにおいて提供されるメカニズムは、マルチメディア・サービスのための一般的な手続きを限定するけれども、ＩＰＴＶサービスの一体化の仕方を限定しない。特に、規格の現在のバージョンにおいては、サービス・プラン、すなわち、ユーザが加入するチャンネル及び対応のＩＰアドレス、を回収するための規定がない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、ＩＰＴＶサービスが固定または移動のＩＰネットワークのためのＩＭＳアーキテクチャに一体化されるのを可能とし、かつユーザと関連したサービス・プランが回収されるのを可能とするシステムを限定する技術に対する必要性がある。
【課題を解決するための手段】
【０００９】
本発明は、前記ネットワークにログされたユーザ端末からＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスするためのシステムを提案することによって、上記必要性を取り扱うものである。
【００１０】
本発明によれば、前記サービスは、ＩＰサービスに渡るテレビジョンであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、そして前記システムは、前記端末によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記選択された少なくとも１つのチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末に送るために、
活性化される手段を含むアプリケーション・サーバを含む。
【００１１】
このように、ＩＭＳアーキテクチャは、ＩＭＳにおける端末を登録するときにＩＰＴＶサービスの一体化を可能とする。本発明により、ＩＰＴＶサービスは、従って、ＩＭＳの長所、すなわち固定／移動の一体化、相互化、及びサービスのための汎用機構、サービスの相互作用、ネットワーク・リソースの予約、相互化された取扱高、等を享受することができ、このことは、従来技術におけるＩＰＴＶサービスに対して使用された技術においては可能ではなかった。さらに、視聴覚サービスを履行することは、ＩＭＳサービスの提供を質的に非常に向上させる。
【００１２】
本発明の利点は、本発明が、ＩＰＴＶサービスをＩＭＳアーキテクチャに一体化することが可能となるように、ユーザと関連したサービス・プランの回収を可能とするＩＭＳアーキテクチャのフレームワークにおける新しい手順を提案したことである。
【００１３】
この手順は、特に、サービスと関連したデータベースにおけるＩＰＴＶアプリケーション・サーバによるユーザの権利の認証に依存しており、かつ、ユーザが加入するチャンネルのリストから１つまたは２つ以上のチャンネルの該サーバによる選択に依存している。この選択は、端末によって提供される受信容量が任意の特定のテレビジョン・チャンネルに対して必要とされる受信容量と両立し得るということを前以って確認することに依存している。
【００１４】
本発明は、また、サービス・アクセス要求のために、及び（ＩＰＴＶアプリケーション・サーバによって採用されていた、ユーザが加入しているチャンネルに関する情報の、特にＩＰトランスポート・ネットワークにおけるＴＶチャンネルの名称及びアドレスの）端末による回収のために、例えばＳＩＰ（セッション開始プロトコル）タイプの報知プロトコルに連結される手順をも用いる。このため、ＳＩＰアクセス要求メッセージの受信時に、ＩＰＴＶアプリケーション・サーバは、ＳＩＰ応答メッセージのＳＤＰ（セッション記述プロトコル）パラメータにおける加入されたチャンネルのリストに受信情報を挿入し、そして該情報を応答メッセージと共にユーザ端末に送る。
【００１５】
端末によって送られるサービス・アクセス要求は、サービスの初期活性化のための要求（例えば、視聴覚端末のスイッチ・オン時の）、またはサービスを変更するための要求（例えば、端末が、例えば考慮されるチャンネルのようなすでにアクセスしたサービスのパラメータの或るものを変更しようとしている場合に）であることができる。
【００１６】
このような要求は、従って、端末によって要求されるサービスに関するパラメータ、例えば、それが考慮するよう追求しているチャンネルの識別子またはサービスの要求されたレベルを含み得る。
【００１７】
一実施形態の一つの長所的特徴によれば、本発明のシステムは、また、前記端末が前記選択された少なくとも１つのチャンネルを受信するために必要なトランスポート・ネットワークのリソースを予約するための手段をも含む。
【００１８】
インターネット・プロトコル・システムに渡る従来技術のテレビジョンにおいては設けられていないこのようなリソースの予約は、考慮されるべきテレビジョン・チャンネルと関連したストリームのユーザ端末による良好な受信を可能とするという点において特に有益である。しかしながら、充分なリソースを有するトランスポート・ネットワークにおいては、このような予約は、厳密には必要でない。
【００１９】
これらのリソース予約手段は、ＩＭＳアーキテクチャ・ネットワークのプロキシ・サーバにおいて履行されることができ、そしてプロキシ・サーバが端末からサービス・アクセス要求に対するＩＰＴＶアプリケーション・サーバからの応答を受信するときにトリガされる。
【００２０】
従って、最終的な分析において、本発明のシステムは、ＩＰＴＶサービスが、特に以下の点において、ＩＭＳアーキテクチャ・ネットワークの多くの利点を享受するのを可能とする：
・ ＴＶチャンネルを受信するために必要なＩＰトランスポート・ネットワークにおけるリソースを予約するためのＩＭＳに固有のメカニズム；
・ ＩＭＳサービス間の相互作用に関するＩＭＳエンティティにおいて限定されるメカニズム；
・ ＩＭＳにおいて限定されるチャージング・メカニズム；そして
・ それ故、ＩＭＳサービスの提供は、視聴覚サービスの提供により質的に向上され得る。
【００２１】
本発明の一つの長所的な特徴によれば、前記端末によって提供される前記受信容量は、
・ 前記サービス・アクセス要求に含まれる受信容量情報、及び／または
・ 前記端末の型、
に基づいて決定される。
【００２２】
例えば、サービスにアクセスするために端末によって送られるＩＮＶＩＴＥメッセージに示され得るこのタイプは、端末によって提供される受信容量の良好な指示を構成し、従って、端末が考慮することを認可されるテレビジョン・チャンネルを選択するためにＩＰＴＶアプリケーション・サーバによって用いられることができる。
【００２３】
サービス・アクセス要求に含まれる受信容量情報は、ネットワークへの端末の接続のためのパラメータにリンクされた容量情報（例えば、ユーザが彼等の加入の関数として権利付与される最大のビット・レート）、または、端末によって必要とされるサービスのレベルに関する情報（例えば、端末が標準限定（ＳＤ）または高限定（ＨＤ）におけるテレビジョン・チャンネルを受信することが必要であるか否か）に対応することができる。
【００２４】
前記受信情報は、長所的には、
・ 前記選択されたチャンネルの識別子、
・ 前記選択されたチャンネルのアドレス、
・ 前記選択されたチャンネルに対して必要とされる受信容量、または例えばビット・レートのようなチャンネルの一層総括的なネットワーク特徴、及び
・ 例えば親制御の文脈において用いられ得る、前記選択されたチャンネルの内容を表す情報、
を含むグループに属する。
【００２５】
本発明のもう１つの態様によれば、前記ＩＭＳアーキテクチャ・ネットワークは、前記ユーザ端末を前記アプリケーション・サーバの１つに関連させる情報へのアクセスを有しかつ前記端末に関連した前記アプリケーション・サーバへの前記サービス・アクセス要求をルーティングするための手段を含むルーティング・サーバを含む。
【００２６】
この実施形態においては、登録中及びＩＭＳとの端末の認可中に、Ｓ−ＣＳＣＦ（サービング−コール・セッション・コントロール・ファンクション）サーバとしてＩＭＳにおいて知られているルーティング・サーバは、ユーザが加入するサービスのセットの検出点についてユーザのプロフィルを含むデータベースからＩＰＴＶサービスと関連したＩＦＣ（初期フィルタ規準）検出点を回収する。ユーザ・プロフィルを含むデータベースは、ＴＩＳＰＡＮによって限定されるものとしてＵＰＳＦ（ユーザ・プロフィル・サーバ・ファンクション）データベース、または、３ＧＰＰによって限定されるものとしてＨＳＳ（ホーム加入者サーバ）データベースのいずれかである。
【００２７】
ＩＰＴＶサービス・アクセス要求の受信時に、メッセージにおいてユーザを識別したＳ−ＣＳＣＦサーバは、ユーザのデータベースから関連の検出点、及び特にＩＰＴＶアプリケーション・サーバに対応するもの、を回収する。従って、それは、端末によって送られるアクセス要求についてそれがトリガしなければならないＩＰＴＶアプリケーション・サーバ・ルーティングを識別する。
【００２８】
本発明の異なった実施形態においては、端末によって送られるサービス・アクセス要求は、アプリケーション・サーバのアドレス、すなわちＩＭＳアーキテクチャ・ネットワークにおけるテレビジョン・サーバのルーティング識別子を含む。
【００２９】
該識別子は、ＳＩＰユニフォーム・リソース識別子（ＵＲＩ）であり得る。
【００３０】
ＩＰＴＶサービスのメッセージを要求する活性化は、次に、単にルータとして働くＳ−ＣＳＣＦサーバを介してＩＰＴＶアプリケーション・サーバに直接ルーティングされる。
【００３１】
本発明のもう１つの長所的特徴によれば、前記ユーザ端末は、前記選択されたチャンネルのための前記受信情報を処理するための手段と、前記チャンネルに対応するストリームを受信するための手段とを含む。例えば、端末は、受信情報から、それが考慮することを追及するテレビジョン・チャンネルのＩＰアドレスを抽出し、そしてトランスポート・ネットワークを介してＴＶソースから該チャンネルと関連したストリームを得るために該ＩＰアドレスを用いる。
【００３２】
本発明の一つの長所的な実施形態においては、前記アプリケーション・サーバは、また、前記端末によって送られる前記アクセス要求に含まれるセッション識別子を決定するための手段と、前記セッション識別子が前記端末との進行中にすでにセッションに対応するか否かを確認するための手段とを含む。
【００３３】
端末とのセッションがすでに進行中であるということをＩＰＴＶアプリケーション・サーバが検出したならば、セッション識別子は、同じ端末から受信された先の要求に対して変化されないので、それは、受信された要求が初期設定要求でなく、むしろサービス要求の変化であると推論する。それは、次に、現在のセッションを維持し、そしてユーザ端末からの新しい要求に応答するために、端末に応答を送るためのその手段を活性化して、その応答メッセージ内に、その先の応答メッセージと比較される変化した受信情報を挿入する。
【００３４】
本発明は、また、ＩＰネットワークにログされるユーザ端末からＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスするためのシステムのアプリケーション・サーバにも関する。本発明によれば、前記サーバは、ＩＰＴＶサーバであり、かつ、前記端末によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記少なくとも１つの選択されたチャンネルの受信に関する少なくとも情報を含む、前記要求に対する応答を、前記ユーザ端末に送るために、
活性化される手段を含む。
【００３５】
本発明は、さらに、ＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスするための端末に関し、該端末は、前記ＩＭＳアーキテクチャ・ネットワークのＩＰアプリケーション・サーバを渡ってテレビジョンにＩＰＴＶサービス・アクセス要求を送るための手段を含み、前記端末のユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、そして前記アクセス要求は、前記端末によって提供される受信容量に関する情報を含み、
前記端末は、前記アプリケーション・サーバによって送られる前記要求に対する応答を処理するための、そして前記アプリケーション・サーバによって前記リストにおいて選択されたチャンネルの受信に関する情報を含むための手段を含み、そして
前記端末は、前記少なくとも１つの選択されたチャンネルに対応するストリームを受信するための手段を含む。
【００３６】
本発明は、さらに、ＩＰネットワークにログされるユーザ端末からＩＭＳアーキテクチャを有するＩＰネットワークにおけるサービスにアクセスする方法に関する。本発明によれば、前記サービスは、ＩＰＴＶサービスであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、
当該方法は、
前記端末によって送られるサービス・アクセス要求を受信するステップと、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルを受信するために必要な容量に関する情報を決定するステップと、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するステップと、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するステップと、
少なくとも１つの選択されたチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末に送るステップと、
を含む。
【００３７】
最後に、本発明は、サービスにアクセスする上述の方法のステップを実行するためのプログラム・コード命令を含むコンピュータ・プログラムに関する。
【００３８】
非制限的な例として提供される添付図面を参照して行われる以下の説明は、本発明が何に存するか及びそれが実行されるために如何に減少され得るかを明瞭に説明している。
【発明を実施するための最良の形態】
【００３９】
図１は、ＩＰトランスポート・ネットワーク１上のＩＰＴＶサービスを活性化するためのシステムを示しており、ここに、該ＩＰトランスポート・ネットワーク１は、端末１０のユーザがオペレータまたは関連の第三者プロバイダによって提供される１つまたは２つ以上のテレビジョン・チャンネルに前以って加入していたときに、該ＩＰトランスポート・ネットワーク１を介して、端末１０がＴＶソース２０によって提供されるメディア・ストリームを受信することができるものである。
【００４０】
端末１０は、固定または移動の端末であり、視聴覚コンテントを再生するための手段、及びＳＩＰ報知（signaling）手段を含む。本発明の文脈において、端末１０は、従来技術の視聴覚端末（テレビジョンのような）、及び、例えば、２つの要素を物理的に分離することができるまたは同じユニットに一体化されることができる、ＳＩＰクライアントであって良い。従って、端末１０は、スクリーンを有した移動電話であって良く、または、セット・トップ・ボックス及びディスプレイ・スクリーン、等を一体化することができる。
【００４１】
図１に示されるように、ＩＰＴＶサービスは、以下のものを含むＩＭＳアーキテクチャ・ネットワーク２において端末１０から活性化される：
・ ＩＭＳネットワークにおけるユーザ加入者の端末１０との第１の接触点であり、ＩＰトランスポート・ネットワーク１のリソースとの対話を管理する、Ｐ−ＣＳＣＦ（プロキシ−コール・サーバ・コントロール・ファンクション）プロキシ・サーバ２１：
・ ＩＭＳネットワークにおける、かつユーザが加入するサーバへの特定のトリガ点（検出点またはＩＦＣとしても知られている）における加入者を管理するＳ−ＣＳＣＦルーティング・サーバ２２であって；該Ｓ−ＣＳＣＦサーバ２２は、ＩＭＳネットワークでの端末１０の登録中に、図示しないＩ−ＣＳＣＦ（問い合わせ（interrogating）ＣＳＣＦ）サーバによってユーザに割当てられる；
・ 従来技術のＩＭＳアーキテクチャと比較される本発明のＩＭＳアーキテクチャの新しい要素である、ＩＰに渡るテレビジョン・アプリケーション・サーバ（ＩＰＴＶ ＡＳ）２３であって；それは、以下に詳細に記載される手順に従って、サービスを活性化するためのユーザによる要求に続いて、ユーザが加入するものから１つまたは２つ以上のチャンネルをユーザに割り付けるためのＳＩＰサーバであり；ＩＰＴＶアプリケーション・サーバ２３は、サービスのオペレータによって、または加入されたチャンネルのような関連の第３者プロバイダによって供給されるユーザの加入に関する情報、及び、受信容量及び各チャンネルのＩＰアドレスのようなトランスポート・ネットワーク１に関する情報を含む；そして
・ 加入されたサービスについて、ここでは特に、ユーザが加入することを望むテレビジョン・チャンネルによって限定されるＩＰＴＶサービスについて、ユーザのプロフィルを含むＵＰＳＦまたはＨＳＳデータベース２４であって；このデータベース２４には、また、ユーザがウェブページを介してまたは電話によって加入を取った後、サービス・オペレータまたは関連の第３者プロバイダによってデータが供給され；それは、ユーザと関連した検出点、特に、ＩＰＴＶアプリケーション・サーバ２３のもの、を含み；Ｓ−ＣＳＣＦ及びＩ−ＣＳＣＦ ＳＩＰのプロキシは、ユーザ端末の登録中にデータベース２４に質問する。
【００４２】
上述したＩＭＳアーキテクチャ・ネットワーク２において、Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、及びＩ−ＣＳＣＦ ＳＩＰのプロキシ・サーバの対または３つのすべては同じ設備内で結合され得る。
【００４３】
ＩＰＴＶサービスへの加入の後にユーザがそれを活性化することを望むとき、ＩＭＳネットワーク登録の段階は、そのようなものとして、活性化またはアクセス段階に先行する。
【００４４】
登録段階は、自動的に行われるか、または、特にＩＭＳネットワーク２における加入者の識別子を含む登録メッセージ、例えばＳＩＰレジスタ・メッセージ、を送る端末１０によって行われる。レジスタ・メッセージは、Ｐ−ＣＳＣＦプロキシ・サーバ２１に達し、該サーバ２１は、それを、端末１０にＳ−ＣＳＣＦサーバ２２を割当てる、図示しないＩ−ＣＳＣＦサーバに送る。
【００４５】
第１の実施形態においては、Ｓ−ＣＳＣＦサーバ２２は、ＵＰＳＦまたはＨＳＳデータベース２４から、ＩＰＴＶサービスを活性化するためのＩＰＴＶアプリケーション・サーバ２３の検出点を含む関連の検出点を回収する。
【００４６】
もう１つの実施形態においては、オペレータは、以下に説明されるＳＩＰ Ｉｎｖｉｔｅサービスに、ＩＰＴＶアプリケーション・サーバ２３のルーティング識別子ＳＩＰ ＵＲＩを含めるよう選択することができる。ＩＰＴＶサービスに関しては、Ｓ−ＣＳＣＦサーバ２２は、ＩｎｖｉｔｅメッセージをＩＰＴＶアプリケーション・サーバ２３にルーティングするためのルータとしてのみ動作する。
【００４７】
この方法でＩＭＳネットワーク２で登録されて、端末１０は、図２を参照して以下に説明されるサービス活性化手順を用いてＩＰＴＶサービスにアクセスすることができる。
【００４８】
ＩＭＳネットワーク２での登録後に、ユーザは、登録された状態Ａにあり、そして例えばそれらの固定テレビジョンをスイッチ・オンすることにより、またはそれらの移動電話上でＴＶアプリケーションを活性化することにより、端末１０からＩＰＴＶサービスの活性化をトリガする。
【００４９】
固定のまたは移動の端末は、ステップＥ１においてＩＰＴＶサービスへのアクセスを要求するＳＩＰ ＩｎｖｉｔｅメッセージＭ１を、Ｐ−ＣＳＣＦサーバ２１に送る。このメッセージは、チャンネル、例えば、支援されるコーデックと、端末（“ｚａｐｐｉｎｇ”）上のチャンネルの選択を可能とする制御プロトコルのデスクリプション、例えば、ＩＧＭＰ（インターネット・グループ・マネージメント・プロトコル）とを受信するよう、その容量に関する、端末によって提供される情報に特に関係するＳＤＰデータを含む。
【００５０】
Ｐ−ＣＳＣＦサーバ２１は、ステップＥ２においてユーザを管理するＳ−ＣＳＣＦサーバ２２に、ＩｎｖｉｔｅメッセージＭ２を送る。
【００５１】
登録中、検出点またはＩＦＣ（Ｉｎｉｔｉａｌ Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉｏｎ）は、ＩＰＴＶサービスに関係するレジスタ・メッセージの受信時に、Ｓ−ＣＳＣＦサーバ２２にセットされていた。Ｓ−ＣＳＣＦサーバ２２は、（Ｂ）この検出点を認識し、そしてＩｎｖｉｔｅメッセージをＩＰＴＶアプリケーション・サーバ２３に送る。もちろん、上に示したように、ＩＰＴＶアプリケーション・サーバ２３に関するあて先ＵＲＩがＩｎｖｉｔｅメッセージ内に直接示されるならば、このことは必須ではない。
【００５２】
メッセージの受信時、Ｓ−ＣＳＣＦサーバ２２は、活性化要求Ｍ３をＩＰＴＶアプリケーション・サーバ２３に送る（ステップＥ３）。
【００５３】
それがＩｎｖｉｔｅメッセージを受信したとき、ＩＰＴＶアプリケーション・サーバ２３は、サービスに関連したデータベースにおいて加入者の権利を確認し、そして加入されたチャンネルのリストから１つまたは２つ以上のチャンネルを抽出する。サービス・プランとしても知られているこのチャンネルのリストは、（Ｃ）各チャンネルを受信するために必要とされる容量に関する情報と、例えば、ＳＤＰに示される容量から来るかまたはＩｎｖｉｔｅメッセージに示される端末の型から来ることができる端末の受信容量に関する情報と、の両立性（compatibility）を確認することによって決定される。このリストは、加入されたチャンネルの全リストを重複することができる。選択されたチャンネルのリストは、各チャンネルごとに、以下を含む：
・ チャンネル識別子、例えばその名称；
・ チャンネルＩＰアドレス；及び
・ 適切な場合には、必要とされるビット・レートのような、トランスポート・ネットワーク１におけるチャンネルの特性。
【００５４】
ＩＰＴＶアプリケーション・サーバ２３によって送られる応答Ｍ４（ステップＥ４）は、ＳＤＰパラメータに挿入される、選択されたチャンネルのリストを含む。この応答は、成功の場合には、ＳＩＰ ２００ ＯＫメッセージであることができ、もう１つのＳＩＰメッセージは、他の中間交渉交換または失敗メッセージをトリガする。
【００５５】
アプリケーション・サーバによって特定されるチャンネルのＩＰアドレスは、以下であり得る：
・ マルチキャスト・グループ・アドレス；及び
・ ユニキャスト・アドレス。
【００５６】
チャンネルのリストは、ＳＤＰパラメータにおいて運ばれる。用いられるトランスポート・プロトコル、例えば、ＭＰＥＧ２−ＴＳまたはＲＴＰ（実時間プロトコル）、に依存して、特定のチャンネルが、１つまたは２つ以上のＳＤＰ媒体パラメータに記述され得る。媒体記述は、チャンネルがどのストリームに対応するのかを端末１０が見つけ出すのを可能とするチャンネルの識別子を含まなければならない。この識別子は、また、同じチャンネルに関する媒体の相関を可能とする。例えば、それは、チャンネルの名称、及びそれが同報通信されるバンドルを含み得る。ＳＤＰ媒体タイトル・パラメータｉは、チャンネルを指定するために用いられ得る。媒体は、また、例えばフィールドｃ（接続情報）においてチャンネルのＩＰアドレスを含まなければならない。このＩＰアドレスは、端末１０が、選択（ｚａｐｐｉｎｇ）プロトコルによって要求されたチャンネルを受信するのを可能とする。例えば、固定のＡＤＳＬアクセスに渡るＩＰＴＶに対して、もしチャンネルがマルチキャスト・モードにおいて同報通信されるならば、このアドレスは、チャンネルが同報通信されるマルチキャスト・アドレスである。
【００５７】
ＳＩＰ応答メッセージの受信時、Ｐ−ＣＳＣＦサーバ２１は、選択されたチャンネルを同報通信するために必要なトランスポート・ネットワーク１のリソースの予約（Ｄ）を活性化し、そして、また、端末１０上で選択されなかったチャンネルを選択するユーザを除外する（bar）ポリシ（政策）をインストールすることもできる。
【００５８】
リソースの予約は、３ＧＰＰ及びＴＩＳＰＡＮ仕様に従う。ＴＶチャンネルの数は、媒体パラメータの形態でＳＤＰパラメータに存在し得る。ＳＤＰ内に存在する種々のチャンネルは、単一のリソース予約の主題であることができなければならない。１つのチャンネルだけが一度に観察され得るということが与えられると、すべてのチャンネルに対して別々にリソースを予約することは必要でない。ＩＰＴＶアプリケーション・サーバ２３は、これを、ＲＦＣ３３８８（媒体グループ化）及びＲＦＣ３５２４（各媒体ストリームに対するリソースの予約）に示された方法を用いて、ＳＤＰにおいて特定することができる。
【００５９】
移動電話に対して、３ＧＰＰによって限定されるように、Ｐ−ＣＳＣＦサーバ２１は、ＰＤＦ（ポリシ決定機能）と相対させてリソースを予約する。必要ならば、端末は、次に、チャンネル選択（ｚａｐｐｉｎｇ）プロトコル及び選択されたＴＶチャンネルを搬送するための１つまたは２つ以上のＰＤＰ（パケット・データグラム・プロトコル）の文脈を創設するための責任がある。
【００６０】
固定された端末に対しては、ＴＩＳＰＡＮグループによって限定されるように、Ｐ−ＣＳＣＦサーバ２１は、トランスポート・ネットワーク１のためのルール及びリソースを創設するための責任があるリソース及びアドミッション制御サブシステム（ＲＡＣＳ）に、リソースのための要求を創設する。
【００６１】
Ｐ−ＣＳＣＦサーバ２１は、応答Ｍ５を端末１０に送る（ステップＥ５）。後者の端末は、次に、許可されたチャンネル及びそれらの関連のアドレスのリストを有する。端末は、チャンネルを受信して、特に移動ネットワークのためのチャンネル選択（ｚａｐｐｉｎｇ）コマンドを伝達するために、リソースのための要件に対応する１つまたは２つ以上の特定のチャンネルを開始することができる。
【００６２】
最後に、メッセージＭ６によって、端末１０は、ＩＰＴＶアプリケーション・サーバ２３からの応答の受信通知をする（ステップＥ６）。
【００６３】
ユーザが端末１０上のチャンネルを変化させるならば、どんな方法によってでも、該チャンネルの変化は、ＳＩＰメッセージ、例えば、Ｐｕｂｌｉｓｈメッセージを送ることによって報知される（signaled）ことができ、該ＳＩＰメッセージは、ＩＰＴＶアプリケーション・サーバ２３に中継されて、特に聴衆サーベイを行うために用いられる。このＳＩＰメッセージは、チャンネルの各変化時に送られることができるか、または、例えばユーザが選択されたチャンネル上に１０秒以上留まるならば、チャンネルの変化及び時間遅延に続いて送られることができる。このメカニズムは、現存する要素、またはプレゼンス管理のためのＩＭＳアーキテクチャにおいて限定される要素の再使用を可能とする。
【００６４】
受信されたＴＶストリームを制御するためのチャンネル選択（ｚａｐｐｉｎｇ）プロトコルは、例えば、マルチキャスト・ストリームによって同報通信されるチャンネルのためのＩＧＭＰであることができる。応答メッセージのＳＤＰパラメータは、次に、各チャンネルごとの対応のマルチキャスト・グループ・アドレスを含む。同じチャンネルに対してＩＰＴＶアプリケーション・サーバ２３によって戻されたグループ・アドレスは、端末１０の容量及びその型に従って異なり得る。
【００６５】
端末１０からのチャンネルを選択するためのこのプロトコルは、また、ＲＴＳＰ（リアル・タイム・ストリーミング・プロトコル）であることもできる。
【００６６】
トランスポート・ネットワーク１のための結果を有するＩＰＴＶサービス・レベルの変化は、サービス活性化段階に対して記載されたＳＩＰメカニズムを使用することができる。それは、彼等が最初に活性化したものとは異なるＩＰＴＶサービスにユーザがアクセスすることを望む場合に（例えば、ユーザが考慮することを望むチャンネルまたは該チャンネルの限定レベルを変化させる場合に）端末１０においてトリガされる。端末は、次に、上述の手順を開始するが、同じＩＭＳセッションに対しては、すなわち現在のセッションと同じセッション識別子の場合には、その結果は、必要に応じて、リソース予約を変化させるべきである。
【００６７】
１つの特に適切な使用は、チャンネルの限定レベルを変化させること：ＳＤ（標準限定）からＨＤ（高限定）に変化させることである。リソース予約は、次に、チャンネルの１つのセットからもう１つのセットで異なる。
【００６８】
一層詳細には、端末は、ＩＰＴＶアプリケーション・サーバ２３に、現在のセッション及び必要とされる限定レベルのＩＭＳセッション識別子及び／または要求されたチャンネルの識別子を含むアクセス要求を送る。ＩＰＴＶアプリケーション・サーバ２３は、次に、ＩＭＳセッション識別子が変化しなかったということを検出し、そしてすでに開いているセッションに対応する。従って、現在のセッションに対して変更されなければならない受信情報をＳＤＰメッセージにおいてそれに単に送ることにより、ＩＭＳセッションを変化させることなく、それは、端末１０からの要求に応答する。
【００６９】
従って、もし、端末１０のユーザが、ＳＤモードにおいて同報通信された識別子ＣＨ１を有するチャンネルを使用し、そしてＨＤモードにおいてのみ同報通信される識別子ＣＨ２を有するもう１つのチャンネルに“飛ばす（ｚａｐ）”ことを望むならば、端末１０は、現在のＩＭＳセッションの識別子及び彼等が考慮することを望むチャンネルの識別子ＣＨ２を含むＩＰＴＶアプリケーション・サーバ２３に要求を送る。ＩＰＴＶアプリケーション・サーバ２３は、ＩＭＳセッション識別子が変化しなかったこと、及び従って現在のセッションが続かなければならないこと、を検出する。それは、端末１０の受信容量、及びＨＤモードにおいて同報通信されるチャンネルＣＨ２を受信するために必要とされる受信容量の両立性を確認する（例えば、それは、端末がＨＤストリームを受信することができて、例えばＳＤストリームを受信することに制限しないということを確認する）。もし、両立性が確認されるならば、それは、端末１０に応答メッセージを送るためのその手段を活性化し、該メッセージ内には、それが、端末１０が必要とするＣＨ２に関する受信情報、例えば、チャンネルＣＨ２のＩＰアドレスを挿入する。
【００７０】
ＩＰＴＶサービスを終了することは、トランスポート・ネットワーク１におけるリソースの解放（リリース）をトリガするＳＩＰメッセージＢｙｅを送ることに対応する。サービス終了段階中のＳＩＰ交換の運動力学が、図３に示されている。
【００７１】
端末１０のユーザは、例えば、移動電話上のＴＶアプリケーションをスタンドバイするまたはシャット・ダウンするためにテレビジョンをスイッチングする、ＩＰＴＶサービスを出ることを決定した。それは、ＢｙｅメッセージＭ７をＰ−ＣＳＣＦサーバ２１に送る（ステップＦ１）。移動電話に対しては、端末１０は、１つまたは２つ以上のＰＤＰ文脈の非活性化を開始することができる。
【００７２】
Ｐ−ＣＳＣＦサーバ２１は、ＩＰＴＶサービスに割付けられたトランスポート・ネットワーク１のリソースを自由にする（Ｅ）。
【００７３】
Ｐ−ＣＳＣＦサーバ２１は、ＢｙｅメッセージＭ８をＳ−ＣＳＣＦサーバ２２に送る（ステップＦ２）。
【００７４】
Ｓ−ＣＳＣＦサーバ２２は、ＢｙｅメッセージＭ９を、ＳＩＰメッセージに応答するＩＰＴＶアプリケーション・サーバ２３に送る。
【００７５】
ＳＩＰ応答メッセージＭ１０は、Ｓ−ＣＳＣＦサーバ２２及びＰ−ＣＳＣＦサーバ２１を介して端末１０に送られる（ステップＦ４）。
【００７６】
本発明は、また、上述したサービス・アクセス方法のステップを実行するためのプログラム・コード命令を含むコンピュータ・プログラムをも提供する。
【００７７】
プログラムまたはソフトウェア・モジュール・コード命令は、データ媒体に記憶されるまたはデータ媒体によって送信されることができ、該データ媒体は、物質の記憶媒体、例えば、ＣＤ−ＲＯＭ、磁気ディスクまたはハードディスクであることができ、もしくは、電気、光または無線信号のような送信可能な媒体であることができ、もしくは遠隔通信ネットワークの送信媒体であることができる。
【図面の簡単な説明】
【００７８】
【図１】ＩＰＴＶサービスを活性化するための本発明のネットワーク・アーキテクチャを示す図である。
【図２】テレビジョン・サービスの活性化段階を示す図である。
【図３】テレビジョン・サービスの遮断段階を示す図である。
【符号の説明】
【００７９】
１ ＩＰトランスポート・ネットワーク
２ ＩＭＳアーキテクチャ・ネットワーク
１０ 端末
２０ ＴＶソース
２１ Ｐ−ＣＳＣＦプロキシ・サーバ
２２ Ｓ−ＣＳＣＦルーティング・サーバ
２３ ＩＰＴＶアプリケーション・サーバ
２４ ＵＰＳＦまたはＨＳＳデータベース
【特許請求の範囲】
【請求項１】
ＩＰネットワーク（２）のユーザ端末（１０）からＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスするためのシステムであって、
前記サービスは、ＩＰサービスに渡るテレビジョンであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、
前記システムは、前記端末（１０）によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記選択された少なくとも１つのチャンネルの受信に関する少なくとも情報を含む、前記要求に対する応答を、前記ユーザ端末（１０）に送るために、
活性化される手段を含むアプリケーション・サーバ（２３）を含むことを特徴とするシステム。
【請求項２】
前記端末（１０）が前記選択された少なくとも１つのチャンネルを受信するために必要なトランスポート・ネットワーク（１）のリソースを予約するための手段をも含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記端末によって提供される前記受信容量は、
・ 前記サービス・アクセス要求に含まれる受信容量情報、及び／または
・ 前記端末の型、
に基づいて決定されることを特徴とする請求項１または２に記載のシステム。
【請求項４】
前記受信情報は、
・ 前記選択されたチャンネルの識別子、
・ 前記選択されたチャンネルのアドレス、
・ 前記選択されたチャンネルに対して必要とされる受信容量、及び
・ 前記選択されたチャンネルの内容を表す情報、
を含むグループに属することを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
【請求項５】
前記ネットワーク（２）は、前記ユーザ端末を前記アプリケーション・サーバ（２３）の１つに関連させる情報へのアクセスを有しかつ前記端末（１０）に関連した前記アプリケーション・サーバ（２３）への前記サービス・アクセス要求をルーティングするための手段を含むルーティング・サーバを含むことを特徴とする請求項１乃至４のいずれか１項に記載のシステム。
【請求項６】
前記端末によって送られる前記サービス・アクセス要求は、前記アプリケーション・サーバのアドレスを含むことを特徴とする請求項１乃至４のいずれか１項に記載のシステム。
【請求項７】
前記ユーザ端末は、前記選択されたチャンネルのための前記受信情報を処理するための手段と、前記チャンネルに対応するストリームを受信するための手段とを含むことを特徴とする請求項１乃至６のいずれか１項に記載のシステム。
【請求項８】
前記アプリケーション・サーバ（２３）は、また、前記端末によって送られる前記アクセス要求に含まれるセッション識別子を決定するための手段と、前記セッション識別子が前記端末（１０）との進行中にすでにセッションに対応するか否かを確認するための手段とを含むことを特徴とする請求項１乃至７のいずれか１項に記載のシステム。
【請求項９】
ＩＰネットワーク（２）にログされるユーザ端末（１０）からＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスするためのシステムのアプリケーション・サーバ（２３）であって、
前記サーバは、ＩＰＴＶサーバであり、かつ、前記端末（１０）によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記少なくとも１つの選択されたチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末に送るために、
活性化される手段を含むことを特徴とするアプリケーション・サーバ（２３）。
【請求項１０】
ＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスするためのアクセス端末（１０）であって、
前記ＩＭＳアーキテクチャ・ネットワークのＩＰアプリケーション・サーバを渡ってテレビジョンにＩＰＴＶサービス・アクセス要求を送るための手段と、前記端末のユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、そして前記アクセス要求は、前記端末によって提供される受信容量に関する情報を含み、
前記アプリケーション・サーバによって送られる前記要求に対する応答を処理するための、そして前記アプリケーション・サーバによって前記リストにおいて選択された少なくとも１つのチャンネルの受信に関する少なくとも情報を含むための手段と、
前記少なくとも１つの選択されたチャンネルに対応するストリームを受信するための手段と、
を含むことを特徴とするアクセス端末（１０）。
【請求項１１】
ＩＰネットワーク（２）にログされるユーザ端末（１０）からＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスする方法であって、
前記サービスは、ＩＰＴＶサービスであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、
当該方法は、
前記端末（１０）によって送られるサービス・アクセス要求を受信するステップと、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルを受信するために必要な容量に関する情報を決定するステップと、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するステップと、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するステップと、
少なくとも１つの選択されたチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末（１０）に送るステップと、
を含むことを特徴とする方法。
【請求項１２】
請求項１１に記載のサービス・アクセス方法のステップを実行するためのプログラム・コード命令を含むコンピュータ・プログラム。
【請求項１】
ＩＰネットワーク（２）のユーザ端末（１０）からＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスするためのシステムであって、
前記サービスは、ＩＰサービスに渡るテレビジョンであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、
前記システムは、前記端末（１０）によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記選択された少なくとも１つのチャンネルの受信に関する少なくとも情報を含む、前記要求に対する応答を、前記ユーザ端末（１０）に送るために、
活性化される手段を含むアプリケーション・サーバ（２３）を含むことを特徴とするシステム。
【請求項２】
前記端末（１０）が前記選択された少なくとも１つのチャンネルを受信するために必要なトランスポート・ネットワーク（１）のリソースを予約するための手段をも含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記端末によって提供される前記受信容量は、
・ 前記サービス・アクセス要求に含まれる受信容量情報、及び／または
・ 前記端末の型、
に基づいて決定されることを特徴とする請求項１または２に記載のシステム。
【請求項４】
前記受信情報は、
・ 前記選択されたチャンネルの識別子、
・ 前記選択されたチャンネルのアドレス、
・ 前記選択されたチャンネルに対して必要とされる受信容量、及び
・ 前記選択されたチャンネルの内容を表す情報、
を含むグループに属することを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
【請求項５】
前記ネットワーク（２）は、前記ユーザ端末を前記アプリケーション・サーバ（２３）の１つに関連させる情報へのアクセスを有しかつ前記端末（１０）に関連した前記アプリケーション・サーバ（２３）への前記サービス・アクセス要求をルーティングするための手段を含むルーティング・サーバを含むことを特徴とする請求項１乃至４のいずれか１項に記載のシステム。
【請求項６】
前記端末によって送られる前記サービス・アクセス要求は、前記アプリケーション・サーバのアドレスを含むことを特徴とする請求項１乃至４のいずれか１項に記載のシステム。
【請求項７】
前記ユーザ端末は、前記選択されたチャンネルのための前記受信情報を処理するための手段と、前記チャンネルに対応するストリームを受信するための手段とを含むことを特徴とする請求項１乃至６のいずれか１項に記載のシステム。
【請求項８】
前記アプリケーション・サーバ（２３）は、また、前記端末によって送られる前記アクセス要求に含まれるセッション識別子を決定するための手段と、前記セッション識別子が前記端末（１０）との進行中にすでにセッションに対応するか否かを確認するための手段とを含むことを特徴とする請求項１乃至７のいずれか１項に記載のシステム。
【請求項９】
ＩＰネットワーク（２）にログされるユーザ端末（１０）からＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスするためのシステムのアプリケーション・サーバ（２３）であって、
前記サーバは、ＩＰＴＶサーバであり、かつ、前記端末（１０）によって送られるサービス・アクセス要求の受信時に、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルに対して必要な受信容量に関する情報を決定するために、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するために、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するために、そして
前記少なくとも１つの選択されたチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末に送るために、
活性化される手段を含むことを特徴とするアプリケーション・サーバ（２３）。
【請求項１０】
ＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスするためのアクセス端末（１０）であって、
前記ＩＭＳアーキテクチャ・ネットワークのＩＰアプリケーション・サーバを渡ってテレビジョンにＩＰＴＶサービス・アクセス要求を送るための手段と、前記端末のユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、そして前記アクセス要求は、前記端末によって提供される受信容量に関する情報を含み、
前記アプリケーション・サーバによって送られる前記要求に対する応答を処理するための、そして前記アプリケーション・サーバによって前記リストにおいて選択された少なくとも１つのチャンネルの受信に関する少なくとも情報を含むための手段と、
前記少なくとも１つの選択されたチャンネルに対応するストリームを受信するための手段と、
を含むことを特徴とするアクセス端末（１０）。
【請求項１１】
ＩＰネットワーク（２）にログされるユーザ端末（１０）からＩＭＳアーキテクチャを有するＩＰネットワーク（２）におけるサービスにアクセスする方法であって、
前記サービスは、ＩＰＴＶサービスであり、前記ユーザは、前記サービスの少なくとも１つのテレビジョン・チャンネルのリストに加入しており、
当該方法は、
前記端末（１０）によって送られるサービス・アクセス要求を受信するステップと、
前記リストへの前記ユーザの加入に関する情報及び前記少なくとも１つのチャンネルを受信するために必要な容量に関する情報を決定するステップと、
前記少なくとも１つのチャンネルに対して必要な受信容量及び前記端末によって提供される受信容量に関する前記情報の両立性を確認するステップと、
前記両立性の確認の関数として前記リストから少なくとも１つのチャンネルを選択するステップと、
少なくとも１つの選択されたチャンネルの受信に関する情報を含む、前記要求に対する応答を、前記ユーザ端末（１０）に送るステップと、
を含むことを特徴とする方法。
【請求項１２】
請求項１１に記載のサービス・アクセス方法のステップを実行するためのプログラム・コード命令を含むコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００９−５４０６４３（Ｐ２００９−５４０６４３Ａ）
【公表日】平成２１年１１月１９日（２００９．１１．１９）
【国際特許分類】
【出願番号】特願２００９−５１３７３６（Ｐ２００９−５１３７３６）
【出願日】平成１９年６月１日（２００７．６．１）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５１３６６
【国際公開番号】ＷＯ２００７／１４１４５０
【国際公開日】平成１９年１２月１３日（２００７．１２．１３）
【出願人】（５９１０３４１５４）フランス・テレコム (290)
【Ｆターム（参考）】
【公表日】平成２１年１１月１９日（２００９．１１．１９）
【国際特許分類】
【出願日】平成１９年６月１日（２００７．６．１）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５１３６６
【国際公開番号】ＷＯ２００７／１４１４５０
【国際公開日】平成１９年１２月１３日（２００７．１２．１３）
【出願人】（５９１０３４１５４）フランス・テレコム (290)
【Ｆターム（参考）】
[ Back to top ]