JP4927879B2 - Ｉｐｔｖのための、ｉｍｓ対応のコントロールチャネル - Google Patents

Description

本発明は、必須ではないが好ましくはセットトップボックス（ＳＴＢ）を活用したＩＰＴＶサービスのための、ＩＰマルチメディアサブシステム（ＩＭＳ）対応のコントロールチャネルの提供に関する。

ＩＰマルチメディアサービスは、同一のセッションにおいて、音声、動画、メッセージング、データ等の動的な組み合わせを提供する。組み合わせ可能な基本アプリケーションとメディアの数を増やすことで、エンドユーザに提供できるサービスの数を増やすことができ、人同士のコミュニケーション・エクスペリエンスを豊かにすることができる。これは、以下詳しく見ていく、いわゆる「コンビネーショナル・ＩＰ・マルチメディア」サービスを含む、次世代の、パーソナライズされた、豊かなマルチメディアコミュニケーションサービスにつながると思われる。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって、移動通信ネットワーク上でのＩＰマルチメディアサービスを提供するために定義された技術である。(3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328及びTS 29.329 リリース５から７)ＩＭＳは、標準化されたＩＭＳサービス・イネーブラの利用を通して、エンドユーザの人対人のコミュニケーション・エクスペリエンスを豊かにする、という重要な特徴を提供する。ＩＭＳサービス・イネーブラは、ＩＰベースのネットワーク上での、新しい豊かな人対人（クライアント対クライアント）コミュニケーションサービスと、人対コンテンツ（クライアント対サーバ）サービスの双方を、促進する。ＩＭＳは、ユーザ端末同士の間の（あるいは、ユーザ端末とアプリケーションサーバとの間の）呼またはセッションを、セットアップし、コントロールするために、セッション開始プロトコル（ＳＩＰ）を利用する。ＳＩＰシグナリングによって運ばれる、セッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述し、ネゴシエートするために使われる。ＳＩＰがユーザ対ユーザのプロトコルとして作られたのに対し、ＩＭＳはオペレータとサービスプロバイダに対し、サービスに対するユーザのアクセスをコントロールし、それに従ってユーザに料金を請求することを可能とする。

テレコミュニケーション・オペレータと、テレビ・オペレータと、インターネット・サービス・プロバイダとが提供するサービスの間の境界は消えつつある。そういった企業はみな、これらの３つのサービスを顧客に提供している（いわゆる「トリプルプレイ」）。ＴＶサービスを提供したいテレコミュニケーション・オペレータにとっての、人気のある選択が、いわゆるＩＰＴＶを利用することである。ＩＰＴＶは、ＴＶサービスを、ＩＰと利用者のブロードバンド接続（例えば、ＡＤＳＬ、ＶＤＳＬ、パブリック・イーサネット（登録商標）等）とを介して提供する。

ｘＤＳＬモデムと、ブロードバンドアクセス（ＤＳＬＡＭ）とからの、ブロードバンドアクセスの「ファーストマイル」では、ＩＰＴＶが自由に使える帯域幅は限られている。リニア・コンテンツ・デリバリー、すなわち申し込んでいるすべてのチャンネル（「プログラム・パッケージ」）が同時にセットトップボックス（ＳＴＢ）へ送信されることは、帯域幅が限られているために、ＩＰＴＶには適していない。使用されているＤＳＬのバージョンと、「ファーストマイル」の距離によって、ｘＤＳＬの接続容量は異なる。ＡＤＳＬは３から８Ｍｂｐｓの容量を提供する。それに対して、ＡＤＳＬ２は下り最高２５Ｍｂｐｓを提供することを約束し、ＶＤＳＬのデータレートは３０Ｍｂｐｓを超える。標準的な品質のＭＰＥＧ２コンテンツは、１チャンネルにつき２Ｍｂｐｓを必要とする。ＨＤＴＶは１チャンネルにつき８−１０Ｍｂｐｓを必要とするだろう。幸運なことに、新しいＭＰＥＧ４スタンダードは、ＭＰＥＧ２でコーディングされたコンテンツと同等の品質を保ちながら、必要な帯域幅を半分にまで落とすだろう。それでもなお、利用可能な帯域幅は少ない資源であり、ＩＰＴＶソリューションは、「ファーストマイル」を通して送信されるチャンネルの数を制限する必要がある。

既存のタイムシフト／追いかけ再生に関するソリューションは、プロプライエタリなネットワークテクノロジ、または家庭内のＰＶＲに基づいたものである。ここで説明するソリューションは、ファーストマイル接続を通って家庭へと送信されるトラフィックを制限するために、標準化された、ＩＭＳコミュニケーションシステムと、そのネットワーアーキテクチャとを、また、ネットワーク内に存在するＰＶＲを、利用する。

ＩＰＴＶサービスとＩＭＳインフラストラクチャとの収斂によって、ＴＶセットを使うエンドユーザに対して、新しい大量の可能性が開かれる。ビデオ会議、インタラクティブゲーム、パーソナライズされた広告や、視聴者のフィードバックを伴うインタラクティブ・テレビ・プログラムといったものが現実となる。それらは、ＩＭＳを使うことで、容易に実現可能である。しかしながら、これらのアプリケーションの多くが、ＳＴＢと、様々なアプリケーションサーバとの間の、広範な通信を必要とする。そのため、既存のＩＰＴＶシステムを使っているユーザエクスペリエンスに、新しいサービスが加えられることが必要な時（例えば、ユーザがビデオ会議の呼び出しをテレビを見ているときに受けた時）には毎回、異なったコントロールチャンネルをセットアップすることと、必要な情報を受信することと、に関連したセットアップディレイが生じる。

ＩＰＴＶサービスのためのＩＭＳ対応のコントロールチャネルを提供することが、本発明の目的である。

本発明の第１の側面により、ＩＰＴＶサービスのためのＩＭＳ対応のコントロールチャネルの提供方法が提供される。この方法は、
サービング呼状態制御機能（Ｓ−ＣＳＣＦ）において、発信側のユーザを特定するセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲメッセージを受信する工程と、
前記発信側のユーザにおいて、当該発信側のユーザが許可されたことを示す前記Ｓ−ＣＳＣＦからの応答を受信する工程と、
選択されたＩＰＴＶアプリケーションサーバ（ＡＳ）とのオープン・チャネル・コネクションを確立するために、ＳＩＰ ＩＮＶＩＴＥメッセージを、前記Ｓ−ＣＳＣＦから送信する工程と、
前記オープン・チャネル・コネクションを介して、制御メッセージ又は情報メッセージを送信すること及び受信することの少なくとも一方を行う工程と、
を備えることを特徴とする。

ＩＰＴＶ ＡＳとのオープン・コントロール・チャネルを維持することにより、この発明は、様々なアプリケーションに対するセットアップ遅延時間を実質的に削減し、また、ＳＴＢとコンタクトするために使われることができる、特有の共通制御データチャネルを提供する。これにより、ＩＰＴＶ ＡＳは、ＳＴＢへの「共通ゲートウェイ」となる。

この方法でＳＴＢとＩＰＴＶ ＡＳとの間の持続的なコントロールチャネルをセットアップするためにＩＭＳ機構を利用することと、すべての必要とされる制御情報をＳＴＢからＩＰＴＶ ＡＳへ、またＩＰＴＶ ＡＳからＳＴＢへ送信するためにこのコントロールチャネルを利用することとは、使用するときに特別な利益を提供する。特にこのことは、ＴＶに表示される可能性のある様々なアプリケーションで使われる、全ての様々な制御情報のために、１つだけのコントロールチャネルが使われることを可能とする。また、コントロールチャネルをセットアップしてこれらのアプリケーションをコントロールする全てのＩＭＳインフラストラクチャのために、１つだけのコントロールチャネルが使われることも可能にする。コントロールチャネルは、メディアを流す用途で使われることは決してないだろう。

本発明は、ＩＰＴＶセットトップボックス（ＳＴＢ）に、ＩＭＳ対応のコントロールチャネルを提供することが可能である。このコントロールチャネルは、標準ＩＭＳ手順を用いてセットアップされることができ、後に、再生開始、録画開始、再生終了等のための、ＳＴＢの制御メッセージをＩＰＴＶアプリケーションサーバに送るために使われることができる。また、例えば広告、投票に対する応答、パーソナライズされた投票のトリガ、あるいはターゲットを特定するインタラクティブなイベントのような、パーソナライズされたコンテンツを送るための制御メッセージを送るためにも使われることができる。

本発明は、ＡＳに接続されているＳＴＢのうち、選択された１つによって送信又は受信されることだけが要求される制御コマンドと特定の情報アイテムとの送受信を可能にする、パーソナライズされたＳＴＢとＩＰＴＶ ＡＳとのインタラクションに対するソリューションを提供する。

以下に述べる本発明の好適な実施形態によれば、「常にオン」のコントロールチャネルが、そのようなＩＰＴＶ ＡＳとのインタラクションのためのセットアップ・レイテンシを削減する。それは、常に様々な必要メッセージを送受信する用意ができている、暗号化されたＴＣＰによりコントロールされたデータパイプを提供することにより実現される。コントロールチャネルは、ＩＰＴＶ ＡＳに、様々なＩＰＴＶサブスクリプションの長さと接続状況をコントロールするための手段を提供し、また、容易にアクセス可能な、ソフトウェア更新のためのセキュアなチャネルも提供する。

本発明は、ＩＰＴＶサービスと、ＩＭＳコミュニケーションサービスと、パーソナライズされた情報サービスとの融合を可能にする。

本発明の他の側面により、本発明の第１の側面の方法を実行するための、コンピュータプログラムコードが提供される。

本願発明がより完全に理解されるように、添付の図面を参照して、本願発明に係る好適な実施形態をこれより説明する。

好適な実施形態に対する背景として、以下で、ＩＰマルチメディア・サブシステム（ＩＭＳ）が、ＧＰＲＳ／ＰＳアクセスネットワークの事例において、いかにしてモバイル・ネットワーク・アーキテクチャに適合するかを、簡単に述べる。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内でＳＩＰプロキシとして働く。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを定義している。プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＳＩＰ端末にとっての、ＩＭＳ内での最初の接点であり、サービングＣＳＣＦ（Ｓ−ＣＳＣＦ）は、ユーザが申し込んでいるサービスをユーザに提供し、インテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）は、正しいＳ−ＣＳＣＦを特定し、そのＳ−ＣＳＣＦに、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受け取った要求を転送する役割を持つ。

ユーザは、仕様にあるＳＩＰ ＲＥＧＩＳＴＥＲメソッドを用いて、ＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザアイデンティティに到達可能なアドレスをＩＭＳに知らせるためのメカニズムである。ユーザは、ダイアログを開始するときに使うための、一意なユニフォーム・リソース・アイデンティファイア（ＵＲＩ）を、Ｓ−ＣＳＣＦから受け取る。３ＧＰＰでは、ＳＩＰ端末が登録を行うときには、ＩＭＳはユーザを認証し、利用可能なＳ−ＣＳＣＦの中から１つをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰによっては指定されていないが、その基準には負荷分散とサービスが必要とする要件とが含まれるであろう。Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスへのユーザのアクセスの制御（及び、ユーザのアクセスに対する料金の請求）をする上で鍵となることに留意されたい。オペレータは、直接のユーザ対ユーザのＳＩＰセッションを防止するメカニズムを提供してもよい。さもなければ、直接のユーザ対ユーザのＳＩＰセッションは、Ｓ−ＣＳＣＦを回避してしまうだろう。

登録プロセスの間は、もしＳ−ＣＳＣＦがまだ選択されていない場合、それを選択する責任はＩ−ＣＳＣＦにある。Ｉ−ＣＳＣＦは必要とされるＳ−ＣＳＣＦの能力を、ホームネットワークのホーム・サブスクライバ・サーバ（ＨＳＳ）から受け取り、適切なＳ−ＣＳＣＦを、受け取った能力に基づいて選択する。（ユーザが他の当事者からの呼を受けており、その時点でＳ−ＣＳＣＦを割り当てられていない場合にも、ユーザに対するＳ−ＣＳＣＦの割り当てがＩ−ＣＳＣＦによって行われることに留意されたい。）登録されたユーザが続けてセッション要求（例えば、ＳＩＰ ＩＮＶＩＴＥ）をＩＭＳに送る時は、その要求はＰ−ＣＳＣＦとＳ−ＣＳＣＦのＵＲＩを含んでいるだろう。これにより、Ｐ−ＣＳＣＦは、選択されたＳ−ＣＳＣＦに、要求を転送することが可能になる。このことは、（ＩＭＳの）発信側と着信側の双方に当てはまる。（着信呼の場合は、要求はＰ−ＣＳＣＦのアドレスとユーザ装置（ＵＥ）のアドレスを含んでいるだろう。）

ＩＭＳサービスネットワーク中では、アプリケーションサーバ（ＡＳ）は、ＩＭＳサービス機能を実現するために提供されている。ＡＳは、ＩＭＳシステム中のエンドユーザにサービスを提供し、３ＧＰＰの規定するＭｒインタフェース上でのエンドポイントとして、あるいは３ＧＰＰの規定するＩＳＣインタフェース上でＳ−ＣＳＣＦによって「結合」されて、接続されうる。後者の場合には、ＳＩＰセッション確立中に、どのＡＳが「結合」されるべきか判断するために、Ｓ−ＣＳＣＦによって初期フィルタ条件（ＩＦＣ）が使われる。異なったＩＦＣが、異なった呼の場合に適用されることがある。ＩＦＣは、ＩＭＳ登録手順において、ユーザのユーザプロファイル（ＵＰ）の一部として、Ｓ−ＣＳＣＦによって、ＨＳＳから取得される。特定のＡＳは、契約者のアイデンティティに従って動作を行うだろう（被呼側の契約者のアイデンティティであれ発呼側の契約者のアイデンティティであれ、ＡＳをコントロールしているネットワークによって「所有」されている）。例えば、呼の転送の場合には、適切な（着信側の）アプリケーションサーバが、ある契約者への呼が転送されるであろう、新しい着信側の当事者を決定するだろう。

以下で述べる好適な実施の形態は、ＩＰＴＶのセットトップボックス（ＳＴＢ）のための、ＩＭＳ対応のコントロールチャネルに関するものである。このコントロールチャネルは、標準的なＩＭＳ手順を用いてセットアップされ、その後、ＩＰＴＶアプリケーションサーバにコントロールメッセージを送るために使われる。また、広告、投票に対する応答、パーソナライズされた投票のトリガ、ターゲットを特定するインタラクティブなイベント、のようなパーソナライズされたコンテンツを送るためにも使われる。この観点において、コントロールチャネルのセットアップは、ユーザ自身のＳＴＢによって直接行われてもよいし、あるいは他のＩＤを用いて他のＳＴＢによってリモートに行われてもよいということを理解することが重要である。

「Rechon Architecture」(EAB-05:045608, Rev A, 2005-12-22.)で使われているように、「ホーム・ライン・ＩＭＳ・サブスクリプション」と同じでもよいＩＭＳ・プライベート・アイデンティティを持っているＩＰＴＶサブスクリプションは、１つだけ存在する。ＩＰＴＶサブスクリプションは、いくつかのＩＭＳ・パブリック・ＩＤ（ＩＭＰＵ）を持ち、それぞれのＳＴＢに対して１つのＩＭＰＵになる。より正確には、ＩＭＰＵはＭＴＲＸに対して割り当てられる。そのために、例えば、個人ユーザ（ファミリーメンバ）がＭＴＲＸにログオンしていない場合には、そのＩＭＰＵがＭＴＲＸにとってのデフォルトとして用いられる（例えば、sip:tv1_subscr17525@imsop.com）。ＩＰＴＶサブスクリプションと関連付けられ、それぞれが一人のユーザを示す、追加のパブリック・アイデンティティが、０、１、または複数存在する。これらは、ユーザがＳＴＢにログオンすると、パーソナライズされたサービスのために用いられる（例えば、sip:sickan@imsop.com）。別の独立のプライベート・アイデンティティ（ＰＩ）を持つユーザに対する、ＩＰＴＶ ＩＳＩＭからのものではないＩＭＰＵであるパブリック・アイデンティティの追加（例えば、sip:sickan_mob@imsop2.com）も可能である。これらは、ユーザがこの外部アイデンティティでＩＰＴＶサービスにログオンするときに用いられる。ＳＴＢが起動すると、まず、ＩＭＳネットワークに登録する。このとき、Ｉｄｅｎｔｉｔｙ＆ＩＭＳモジュール（ＩＭＯＤ）のＩＭＳプライベートＩＤ（ＩＭＰＩ − ＳＴＢのプライベートアドレス）が許可ヘッダの中で用いられる。また、デフォルトの「ファミリーＳＴＢ」のパブリックアドレスが「Ｆｒｏｍ」と「Ｔｏ」ヘッダの中で（通常のＳＩＰ ＲＥＧＩＳＴＥＲメッセージと同様に）用いられる。メディア・トランスミッタ・レシーバ（ＭＴＲＸ）を示すＩＭＰＵと、ユーザを示すＩＭＰＵの双方が登録されることがある。サービスのパーソナライズ化のために、図１に示す、「ＩＰＴＶ ＭＷ ＡＳへのユーザコネクション」を使用するルーチンが実行される。１つのＭＴＲＸについて、一度には最大でも１人のユーザしか、ＡＳに接続できない。（新しいユーザが接続する時には、ＡＳは新規接続を拒否するか、古いユーザを新しいユーザで置き換える。）これらのすべてのサブユースルーチンは、アクセスが移動電話からか、有線接続のＳＴＢからかに関わらず、同じように働くだろう。

図１に関して、「ＩＰＴＶ ＭＷ ＡＳへのユーザコネクション」を使用するルーチンは、以下のプロセス・ステップ（図中の数字を参照する）を備える。

１．ＭＴＲＸは起動され、その通知を、ＩＰアドレスを保持するＩＭＯＤに送る。

２．ＩＭＯＤは、Ｐ−ＣＳＣＦにＳＩＰ ＲＥＧＩＳＴＥＲメッセージを送る。ＭＴＲＸのＩＭＰＵは、「Ｔｏ」ヘッダの中で用いられる。ホームネットワーク・ドメインネームの、ホーム・ＳＩＰ ＵＲＩは、Ｒｅｑｕｅｓｔ−ＵＲＩの中に含まれる。ＩＭＯＤのＩＭＰＩは、「Ａｕｔｈｏｒｉｚａｔｉｏｎ」ヘッダに含まれる。コンタクト・ヘッダは、ＩＭＯＤのＩＰアドレスを含む。アクセス・ネットワーク・プロバイダとＩＭＳオペレータが同じ場合は、Ｐ−ＣＳＣＦ・ディスカバリは、（既存のＩＭＳスタンダードのように）ＤＨＣＰ手順によって行われる。そうでない場合は、Ｐ−ＣＳＣＦ・ディスカバリは、ＩＭＳ ＳＩＭ（ＩＳＩＭ）コンフィギュレーションによって行われ得る。ＩＳＩＭは、Ｐ−ＣＳＣＦのアドレスが保持されるＥＦを含んでいる。このため、Ｐ−ＣＳＣＦのアドレスはＩＳＩＭがユーザに配布される前に、オペレータによって設定される。

３．Ｐ−ＣＳＣＦは、ホームネットワークへのエントリ・ポイント（例えば、Ｉ−ＣＳＣＦ）を発見するために、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージで「ホーム・ドメイン・ネーム」を使う。Ｐ−ＣＳＣＦは、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージ（Ｐ−ＣＳＣＦアドレス／名前、パブリック・ユーザ・アイデンティティ、プライベート・ユーザ・アイデンティティ、Ｐ−ＣＳＣＦネットワーク識別子、ＩＭＯＤ ＩＰアドレス）を、Ｉ−ＣＳＣＦに送る。名前−アドレス解決メカニズムが、ホーム・ドメイン・ネームから、ホームネットワークのアドレスを決定するために用いられる。Ｐ−ＣＳＣＦネットワーク識別子は、ホームネットワークにおいて、Ｐ−ＣＳＣＦが存在するネットワークを特定する文字列である。例えば、既存のＩＭＳスタンダードによれば、Ｐ−ＣＳＣＦネットワーク識別子は、Ｐ−ＣＳＣＦネットワークのドメインネームであり得る。

４．Ｉ−ＣＳＣＦは、既存のＩＭＳスタンダードにより、Ｃｘ−Ｑｕｅｒｙ／Ｃｘ−Ｓｅｌｅｃｔ−Ｐｕｌｌデータ（パブリック・ユーザ・アイデンティティ、プライベート・ユーザ・アイデンティティ、Ｐ−ＣＳＣＦネットワーク識別子）をＨＳＳに送信する。ＨＳＳは、ユーザがすでに登録されているかどうかを確認する。ＨＳＳは、既存のＩＭＳスタンダードによって、存在するのであれば、ユーザ・サブスクリプションとオペレータの制限／制約（Ｃｘ−Ｑｕｅｒｙ Ｒｅｓｐ／Ｃｘ−Ｓｅｌｅｃｔ−Ｐｕｌｌ Ｒｅｓｐ／Ｃｘ−ＡＶ−Ｒｅｓｐ）に従って、ユーザがそのＰ−ＣＳＣＦネットワーク（Ｐ−ＣＳＣＦネットワーク識別子によって特定される）での登録を認められているかを示す。

５．Ｃｘ−Ｑｕｅｒｙ Ｒｅｓｐ／Ｃｘ−Ｓｅｌｅｃｔ−Ｐｕｌｌ Ｒｅｓｐデータは、ＨＳＳからＩ−ＣＳＣＦに送られる。このデータは、ＨＳＳが知っているのであれば、Ｓ−ＣＳＣＦの名前を含み、また、新しいＳ−ＣＳＣＦを選ぶ必要があるのなら、Ｓ−ＣＳＣＦの能力を含む。応答がＳ−ＣＳＣＦの名前と能力の双方を含んでいる時は、Ｉ−ＣＳＣＦは新しい割り当てを行うことができる。Ｓ−ＣＳＣＦの能力だけが返された時は、Ｉ−ＣＳＣＦは、返されたＳ−ＣＳＣＦの能力に基づき、新しいＳ−ＣＳＣＦを選択する機能を実行する。もしＨＳＳによるチェックが否定的な結果を与えた場合は、Ｃｘ−Ｑｕｅｒｙ Ｒｅｓｐは、既存のＩＭＳスタンダードにより、登録試行を却下する。

６．Ｉ−ＣＳＣＦは、Ｓ−ＣＳＣＦの名前を用い、名前−アドレス解決メカニズムを通して、Ｓ−ＣＳＣＦのアドレスを決定する。Ｉ−ＣＳＣＦは次に、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージ（Ｐ−ＣＳＣＦアドレス／名前、パブリック・ユーザ・アイデンティティ、プライベート・ユーザ・アイデンティティ、Ｐ−ＣＳＣＦネットワーク識別子、ＩＭＯＤ ＩＰアドレス）を、選択したＳ−ＣＳＣＦに送信する。ホームネットワーク・コンタクト・ポイントは、セッション開始メッセージをホームネットワークに転送するために、Ｐ−ＣＳＣＦによって用いられる。Ｓ−ＣＳＣＦは、在圏ネットワークによって与えられた、Ｐ−ＣＳＣＦアドレス／名前を保存する。これは、ＩＭＯＤへの続いてのターミネーティング・セッション・シグナルで、ホームネットワークが転送するアドレス／名前を示す。Ｓ−ＣＳＣＦは、既存のＩＭＳスタンダードによって、Ｐ−ＣＳＣＦのネットワークＩＤ情報を保存する。

７．Ｓ−ＣＳＣＦは、既存のＩＭＳスタンダードにより、認証ベクトルをリクエストするために、Ｃｘ−Ａｖ−Ｒｅｑリクエストを、ＨＳＳに送信する。

８．既存のＩＭＳスタンダードにより、Ｃｘ−Ａｖ−Ｒｅｓｐの中で、認証ベクトルが受け取られる。

９．Ｓ−ＣＳＣＦは、既存のＩＭＳスタンダードにより、認証ベクトルを伴った４０１ Ｕｎａｕｔｈｏｒｉｚｅｄレスポンスを返す。

１０．Ｉ−ＣＳＣＦは、既存のＩＭＳスタンダードにより、４０１ Ｕｎａｕｔｈｏｒｉｚｅｄレスポンスで、認証ベクトルをＰ−ＣＳＣＦに転送する。

１１．Ｐ−ＣＳＣＦは、チャレンジ（認証ベクトルのＲＡＮＤパート）と、ネットワーク認証トークン（ＡＵＴＮ）と、を伴った４０１ ＵｎａｕｔｈｏｒｉｚｅｄレスポンスをＩＭＯＤへと送信する。ＩＭＯＤは、ＡＵＴＮが正しいことを確認し、ネットワークに送る応答を計算する。このステップでＩＭＯＤは、ＣＫとＩＫとのキーペアと既知のアルゴリズム（このアルゴリズムは公開されていて、ＩＭＯＤとＩＰＴＶ ＭＷ ＡＳの双方が知っている）に基づき、キー・マテリアルを計算することができる。

図２は、このルーチンに続く先の処理を概略的に図示している（図の番号を参照する）。

１．既存のＩＭＳスタンダードにより、チャレンジへの応答として、今回はチャレンジ・レスポンスを含めて、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージが、ＩＭＯＤからＰ−ＣＳＣＦへ送信される。

２．既存のＩＭＳスタンタードにより、チャレンジ・レスポンスを含むＳＩＰ ＲＥＧＩＳＴＥＲメッセージが、Ｐ−ＣＳＣＦからＩ−ＣＳＣＦへ送信される。

３．既存のＩＭＳスタンタードにより、チャレンジ・レスポンスを含むＳＩＰ ＲＥＧＩＳＴＥＲメッセージが、Ｉ−ＣＳＣＦからＳ−ＣＳＣＦへ送信される。

４．既存のＩＭＳスタンダードにより、Ｓ−ＣＳＣＦによる確認作業により、チャレンジ・レスポンスが正しいことが確認され、Ｃｘ−Ｐｕｔ／Ｃｘ−Ｐｕｌｌ（パブリック・ユーザ・アイデンティティ、プライベート・ユーザ・アイデンティティ、Ｓ−ＣＳＣＦの名前）データがＨＳＳに送信される。

５．ＨＳＳに、このユーザに対応するＳ−ＣＳＣＦの名前が格納され、Ｓ−ＣＳＣＦにＣｘ−Ｐｕｔ Ｒｅｓｐ／Ｃｘ−Ｐｕｌｌ Ｒｅｓｐ（ユーザ情報）データが返される。ＨＳＳからＳ−ＣＳＣＦへと送信されるユーザ情報（初期フィルタ条件）は、ユーザがこのＳ−ＣＳＣＦに登録されている間、サービスコントロールに使われるプラットフォームにアクセスするために使われうる、名前とアドレスとの情報を含む。Ｓ−ＣＳＣＦは、指定されたユーザの情報を保存する。

６．Ｓ−ＣＳＣＦによって、２００ ＯＫレスポンスが返される。

７．Ｉ−ＣＳＣＦによって、２００ ＯＫレスポンスが転送される。

８．Ｐ−ＣＳＣＦによって、２００ ＯＫレスポンスが転送される。

９．ＩＭＯＤからＭＴＲＸに、「Ｒｅｇｉｓｔｅｒｅｄ」メッセージが送られる。

一度ＳＴＢが登録されると、ＳＴＢはＳＩＰ ＩＮＶＩＴＥを用いて、ＩＰＴＶ ＡＳとの間に、セキュアなＴＣＰ／ＴＬＳコネクションを確立する。その処理は、図３で概略的に示される以下のようなものである（図の番号を参照する）。

１．ＭＴＲＸ（ＳＴＢのメディア・エンド・ポイント）が、ＩＭＯＤ（ＳＴＢの認証部／ＩＳＩＭ保持部）に対し、ＩＰＴＶ ＭＷ ＡＳへの接続が確立されるべきだと示す。ＩＭＯＤとＭＴＲＸとの区別は任意的なものであり、ＳＴＢの内部の具現化としてとらえることができる。この区別のないＳＴＢでも、ＩＭＳネットワークとの関係では同じように働くだろう。

２．ＩＭＯＤは、Ｐ−ＣＳＣＦにＳＩＰ ＩＮＶＩＴＥを送る。ＩＰＴＶ ＭＷ ＡＳのパブリック・サービス・アイデンティティは、ＩＰＴＶ ＭＷ ＡＳを宛先とするために使われ、ＩＳＩＭ内にあらかじめ設定されていてよい。または、デバイス管理手順によって設定されていてもよい。ＴＬＳ／ＴＣＰセッションのＳＤＰデスクリプションが含まれている。他の手順としては、ＭＳＲＰのように、ピュアＴＣＰ／ＴＬＳチャネル上でアプリケーション・フレーミング・プロトコルを使う手順があるだろう。この場合、ＳＤＰデスクリプションは、単なるＴＬＳ／ＴＣＰの代わりに、ＭＳＲＰ／ＴＬＳ／ＴＣＰを含む。

３．ＳＩＰ ＩＮＶＩＴＥは、Ｉ−ＣＳＣＦに転送される。３ＧＰＰ ２３．２２８では、着信側での、代替ＰＳＩルーティングについて詳述されている。すなわち、ａ．Ｉ−ＣＳＣＦがＨＳＳに問い合わせを行い、ＨＳＳは各ＰＳＩを一人の「ユーザ」として扱ってＰＳＩを表すエンドポイントへのルーティング指示を返す。ｂ．Ｉ−ＣＳＣＦがＨＳＳに問い合わせを行い、ＨＳＳは、Ｓ−ＣＳＣＦに割り当てられているユーザを返す。Ｓ−ＣＳＣＦは、「ＰＳＩ−加入者」ごとに保存されているＩＦＣ情報に従って、ＰＳＩによって宛先指定されたＩｎｖｉｔｅをルーティングする。「ＰＳＩ−加入者」が、Ｓ−ＣＳＣＦに割り当てられる。ｃ．Ｉ−ＣＳＣＦ内で、サブドメインルーティングが行われる。そこでは、Ｉ−ＣＳＣＦは、ＰＳＩを、ＰＳＩを表すエンドポイントを示すＩＰアドレスへと解決するためにＤＮＳを用いる。このソリューションは、ｂの代替法を必要とする。

４．Ｉ−ＣＳＣＦは、パブリック・サービス・アイデンティティを今回このユーザを扱う実際のサーバのＩＰアドレスに翻訳するために、ＤＮＳを用いる（負荷分散はここで適用可能である）。そして、Ｓ−ＣＳＣＦはＳＩＰ ＩＮＶＩＴＥを、選択されたＩＰＴＶ ＭＷ ＡＳに送る。そして、ＩＰＴＶ ＭＷ ＡＳは「ユーザデータ取得」サブシーケンスを続けて行う。

５．ＩＰＴＶ ＭＷ ＡＳは、２００ ＯＫレスポンスを返す。ユーザのＴＶサービスポータルのＵＲＬは、例えば、ＳＴＢには理解されるが、途中のノードには理解されないようなＸＭＬボディとして、ＳＤＰに含められる。

６．Ｓ−ＣＳＣＦは、２００ ＯＫレスポンスを転送する。

７．Ｐ−ＣＳＣＦは、２００ ＯＫレスポンスを転送する。

８．ＩＭＯＤは、ユーザのデフォルトのＴＶサービスポータル（すなわち、ＭＴＲＸのＩＭＰＵと関連づけられたポータル）のＵＲＬを受け取る。それは、ＳＤＰに含まれている。この情報は２００ ＯＫメッセージの中にＸＭＬボディとして含まれていてもよいが、他の手段も可能である。

９．ＩＭＯＤは、ＳＩＰ ＡＣＫレスポンスを送る。

１０．Ｐ−ＣＳＣＦは、ＳＩＰ ＡＣＫレスポンスを転送する。

１１．Ｓ−ＣＳＣＦは、ＳＩＰ ＡＣＫレスポンスを転送する。

１２．ＩＭＯＤは、ＩＰＴＶ ＭＷ ＡＳとのＴＬＳ／ＴＣＰコネクションを、サーバ側の証明書を用いてセットアップする。

そのとき、ＴＬＳ／ＴＣＰコネクションを、専用の「常にオンの」コントロールチャネルとして、ＳＴＢとＩＰＴＶ ＡＳとの間で送信されるすべての必要なコントロールメッセージとインフォメーションメッセージのために用いることが可能になる。このインフォメーションメッセージは、ネットワーク・インフラストラクチャのどこかにある共有データベースに保存されている、パーソナライズされたコンテンツを組み入れていてもよい。このコンテンツは、ＨＳＳや他の「ユーザ・プロファイル・データベース」に保管されているユーザのプロファイル情報によってフィルタされ、ＩＰＴＶ ＡＳに届けられるだろう。（また、代替法として、ＩＰＴＶ ＡＳ自体が、フィルタに従って、コンテンツを管理してもよい。）コンテンツは、コントロールチャネルを経由して、ＩＰＴＶ ＡＳからＳＴＢへと与えられる。異なったＣＳＣＦは、暗号化されたチャネルのコンテンツを見ることはできない。実際、コンテンツは他のＩＭＳノードを通ることはない。コントロールチャネルは、ＳＴＢとＩＰＴＶ ＡＳとの間のエンド・トゥ・エンド・コネクションである。

この手順は、もしシステム中のサービスの保護が、コンテンツ・ストリームを暗号化することに基づいているのならば、サービス保護（コンディショナル・アクセスとしても知られている）のためのキーを配布することを付け加えるように拡張されうる。このことは、先述した最後のステップの後に、例えばキーがＨＴＴＰを介して取得されうるような、追加のステップを伴うだろう。もし異なったユーザが異なったチャネル・バンドルを持っているならば、「ユーザコネクション、ローカルユーザ」手順の後にも、そのようなステップが必要とされるだろう。

この手順は、「必要なときに」の原則に従ってのみ、実行されてもよい（すなわち、登録の時には接続は自動的にセットアップされず、ＩＰＴＶ ＡＳへのアクセスが必要となったときにだけ行われる）。しかし、ＳＴＢ／ＭＳ登録の後、すぐに接続を確立することも、好適な他の形態である。これにより、ＩＰＴＶ ＭＷ ＡＳとのやりとりが必要になった時に、この接続のセットアップにかかる遅延を避けることができる。

新しいコントロールチャネルは、ＩＭＯＤと接続されることになるそれぞれのＭＴＲＸに対して確立される。これは、「ＩＭＳ ＩＰＴＶ アーキテクチャ・スタディ」（「Ｒｅｃｈｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ」， ＥＡＢ−０５：０４５６０８， Ｒｅｖ Ａ， ２００５−１２−２２）に詳述されている。

先述のコントロールチャネルは、ＩＰＴＶ ＳＴＢのリモートコントロールのような、多数の機能を可能とする。これは、「ＩＭＳ ＩＰＴＶ アーキテクチャ・スタディ」（ＥＡＢ−０６：００１７２１， Ｒｅｖ Ａ， ２００６−０２−０８）、に詳述されている。また、次のセクションで述べるユーザ・ケースも可能にする。

先に言及した、後に続く「ユーザデータ取得」サブシーケンスは、Ｓ−ＣＳＣＦから、ＣＫとＩＫとのキーペア（登録手順中に、ＩＭＳ ＡＫＡ認証により生成される）に基づくキー・マテリアルを取得するために、ＩＰＴＶ ＭＳ ＡＳによって用いられる。このキー・マテリアルは、ＣＫとＩＫから導出されてもよいし、あるいは何らかの他の方法から導出されてもよい。実際の導出は、Ｓ−ＣＳＣＦ以外のノードで行われても良い。その場合、Ｓ−ＣＳＣＦと、キーを導出するノード（不図示）との間で、追加の情報伝達を必要とするだろう。このことは、既存のＩＭＳスタンダードには存在しない。そのため、このことは、製品とスタンダードに影響を及ぼすだろう。他の可能性として、ＩＮＶＩＴＥを転送するときに、Ｓ−ＣＳＣＦが認証ベクトルをＡＳへと送信することもあり得る。

この手順は、図４で概略的に示されるが、次の通りである(図の番号を参照する)。

１．ＩＰＴＶ ＡＳのネットワーク・アプリケーション・ファンクション（ＮＡＦ）は、「キー・マテリアル取得」リクエストを、Ｓ−ＣＳＣＦに発行する。

２．Ｓ−ＣＳＣＦのブートストラッピング・サーバ・ファンクション（ＢＳＦ）は、キー・マテリアルを取得するために、ダイアメータ・プロキシ（Ｄ−Ｐｒｏｘｙ）とコンタクトする。

３．Ｄ−Ｐｒｏｘｙは、ＳＴＢのホームドメインにあるＳ−ＣＳＣＦのＢＳＦとコンタクトする。

４．ＳＴＢのホームドメインにあるＢＳＦは、キー・マテリアルをＩＰＴＶ ＡＳのドメインにあるＤ−Ｐｒｏｘｙに送信する。

５．Ｄ−Ｐｒｏｘｙは、キー・マテリアルをＳ−ＣＳＣＦに送信し、続けてＳ−ＣＳＣＦはＩＰＴＶ−ＡＳに送信する。

６．キー・マテリアルと、既知のプロトコル／アルゴリズム（例えばダイジェスト認証のように、このプロトコル／アルゴリズムは公開されていて、ＩＭＯＤとＩＰＴＶ ＭＷ ＡＳの双方が知っている）とに基づいて、ＩＭＯＤは認証される。ＩＭＯＤは、ＩＰＴＶ ＭＷ ＡＳが、先のＩＮＶＩＴＥ手順で受け取ったキー・マテリアルと、同じものを取得することができることに留意すべきである。

他の実装として、ＢＳＦをＳ−ＣＳＣＦとは分離することも可能である。この場合、ＳＴＢとＩＰＴＶ ＡＳからそれぞれのＢＳＦへの、明示的なＧＡＡ／ＧＢＡシグナリングが要求される。

一度コントロールチャネルが確立されると、電子番組表（ＥＰＧ）が、セキュアな接続を利用してＩＰＴＶ ＡＳから取得されうる。このＥＰＧは、現在ログインしているユーザの特定のサブスクリプションに応じてカスタマイズすることができるし、ＳＴＢが保持するサブスクリプションの種類に対応した、デフォルトのＥＰＧとすることもできる。図５に図示されるこの手順は、以下の通りである（図の数字を参照する）。

１．ＭＴＲＸは、ＩＭＯＤからの、ユーザ向けのＥＰＧを要求する。

２．ＩＭＯＤのユーザは、ＥＰＧリストを、ＨＴＭＬページとして要求する。これは、前もってセットアップされたＩＰＴＶ ＭＷ ＡＳとのセキュアな接続を用いてなされる。

３．ＩＰＴＶ ＭＷ ＡＳは、ＥＰＧサーバからのＥＰＧデータを要求する。

４．ＥＰＧサーバは、ＥＰＧのＸＭＬデータを、ＩＰＴＶ ＭＷ ＡＳへと送信する。

５．ＩＰＴＶ ＭＷ ＡＳは、現在ログオン中のユーザに対して有効な情報を伴うＨＴＭＬページを生成し、ＩＭＯＤに送信する。

６．ＩＭＯＤは、ユーザ向けのＥＰＧをＭＴＲＸへと返す。

ユーザが、自分のパーソナルＥＰＧ等にアクセスするためにＴＶサービスに「ログオン」したい時は、リモートコントローラのパーソナライゼーションボタンが押される。すると、新しいユーザのＩＭＰＵを用いた、ＩＭＯＤでの新規登録が引き起こされる。もし、そのＭＴＲＸについて、他のユーザがすでに登録されているなら、ＩＭＯＤは、そのユーザとのＴＬＳ／ＴＣＰセッションを閉じ、ユーザ登録を解除する。

そして、ＩＭＯＤは、ＰＳＩを用いて、ＩＰＴＶ ＭＷ ＡＳをインバイトする。Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙは、「ブルー」ユーザのＩＭＰＵにセットされる。ＴＬＳ／ＴＣＰセッションの、ＳＤＰデスクリプションが含まれる。残りの手順は、一般的な場合に従う。

あらかじめ定められた間隔で、現在のユーザのパーソナライズされたフィルタに従った広告のセットが、ＭＴＲＸとのコントロールチャネルを介して与えられる。これらの広告は、ユーザがテレビを見ている間に、スクリーンのある領域に表示されるように設定されうるし、テレビにフルスクリーン表示させられるための特定のトリガを受け取るのを待つこともできる。パーソナライズされた広告のためのフィルタは、（ＨＳＳ他の）様々なＩＭＳデータベースに保存されているプロファイル情報に、また、特定のユーザが何を見ているのかという情報に、基づく。

ＳＴＢコントロールチャネルは、ＩＰＴＶ ＡＳが、接続されているそれぞれのＳＴＢの「健康」状態を知ることを可能にする。適切なキープ・アライブ・メカニズム、これはチャネルが常にオンの状態であるゆえに非常に少ないリソースしか消費しないだろうが、これを設定することにより、ソフトアェアの更新をＳＴＢに供給することとサブスクリプションの更新やオペレータからのＩＳＩＭとのインタラクションのような、サーバにより開始される何らかの機能を実行することとが可能になる。

本発明は、パーソナライズされた、ＳＴＢとＩＰＴＶ ＡＳとのインタラクションに対するソリューションを提供する。これは、コントロールコマンドを送受信することと、ＡＳに接続しているすべてのＳＴＢの中から選ばれた１つのＳＴＢだけにより送受信されるべきである、あらゆる特定の情報アイテムを届けることと、のために使われうる。

「常にオン」のコントロールチャネルは、ＩＰＴＶ ＡＳとのすべてのインタラクションについて、常に様々な必要メッセージを送受信する準備ができている、暗号化された、ＴＣＰによりコントロールされたデータパイプを提供することにより、セットアップ・レイテンシを削減する。コントロールチャネルはまた、ＩＰＴＶ ＡＳに、様々なＩＰＴＶサブスクリプションの、長さとコネクションステータスをコントロールするための手段を提供する。同時に、容易に利用可能な、ソフトウェアの更新のためのセキュアなチャネルも提供する。

本発明は、ＩＰＴＶサービス、ＩＭＳコミュニケーションサービスと、パーソナライズされた情報サービスの融合を提供する。

本発明の範囲を逸脱することなく、上記実施形態に対する様々な修正がなされてもよいということは、当業者によって、理解されるだろう。

ＳＴＢの登録シーケンスを示す概略図である。 ＳＴＢの登録における後続のシーケンスを示す概略図である。 セキュアなＴＣＰ／ＴＬＳコネクションの確立を示す概略図である。 「ユーザデータ取得」シーケンスを示す概略図である。 電子番組表（ＥＰＧ）の確立を示す、概略図である。

Claims (13)

1. ＩＰＴＶサービスのためのＩＭＳ対応のコントロールチャネルを提供する方法であって、
   サービング呼状態制御機能（Ｓ−ＣＳＣＦ）において、発信側のユーザを特定するセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲメッセージを受信する工程と、
   前記発信側のユーザにおいて、当該発信側のユーザが許可されたことを示す前記Ｓ−ＣＳＣＦからの応答を受信する工程と、
   選択されたＩＰＴＶアプリケーションサーバ（ＡＳ）とのオープン・チャネル・コネクションを確立するために、ＳＩＰ ＩＮＶＩＴＥメッセージを、前記Ｓ−ＣＳＣＦから送信する工程と、
   前記オープン・チャネル・コネクションを介して、制御メッセージ又は情報メッセージを送信すること及び受信することのうちの少なくとも一方を行う工程と、
   を備えることを特徴とする方法。
2. 前記コントロールチャネルが、標準ＩＭＳ手順を用いてセットアップされることを特徴とする、請求項１に記載の方法。
3. 前記制御メッセージ又は情報メッセージが、前記ＩＰＴＶ ＡＳへのＩＭＳメッセージを含むことを特徴とする、請求項１又は２に記載の方法。
4. 前記制御メッセージ又は情報メッセージが、例えば広告、投票に対する応答、パーソナライズされた投票のトリガ、又はターゲットを特定するインタラクティブなイベントのような、パーソナライズされたコンテンツを含むことを特徴とする、請求項１乃至３の何れか１項に記載の方法。
5. 前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージが、Ｉｄｅｎｔｉｔｙ＆ＩＭＳモジュール（ＩＭＯＤ）から受信され、当該メッセージが前記ＩＭＯＤのＩＰアドレスを含むことを特徴とする、請求項１乃至４の何れか１項に記載の方法。
6. 前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージが、メディア・トランスミッタ・レシーバ（ＭＴＲＸ）からの、当該ＭＴＲＸのＩＰアドレスを含むパワーオンメッセージの受信に応答して、送信されることを特徴とする、請求項１乃至５の何れか１項に記載の方法。
7. 前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージを選択されたＳ−ＣＳＣＦへと送るために、当該ＳＩＰ ＲＥＧＩＳＴＥＲメッセージをインテロゲーティング呼状態制御機能（Ｉ−ＣＳＣＦ）へと転送するプロキシ呼状態制御機能（Ｐ−ＣＳＣＦ）によって当該ＳＩＰ ＲＥＧＩＳＴＥＲメッセージが受信されることを特徴とする、請求項１乃至６の何れか１項に記載の方法。
8. 前記Ｓ−ＣＳＣＦが、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの受信に応答して、認証メッセージを返すことを特徴とする、請求項１乃至７の何れか１項に記載の方法。
9. 前記Ｓ−ＣＳＣＦが、認証メッセージ送信への応答として、チャレンジ・レスポンスを含むＳＩＰ ＲＥＧＩＳＴＥＲメッセージを受信することを特徴とする、請求項１乃至８の何れか１項に記載の方法。
10. 前記Ｓ−ＣＳＣＦが、前記チャレンジ・レスポンスの検証を行い、肯定的検証結果の場合には、接続を可能にするメッセージを送信することを特徴とする、請求項９に記載の方法。
11. 確立されるセキュアな前記コネクションは、ＴＬＳ／ＴＣＰコネクション、又はＭＳＲＰ／ＴＬＳ／ＴＣＰコネクションであることを特徴とする、請求項１乃至１０の何れか１項に記載の方法。
12. ユーザデータ取得サブシーケンスが、ＩＰＴＶ ＡＳにより前記ＳＩＰ ＩＮＶＩＴＥメッセージが受信されると開始されることを特徴とする、請求項１乃至１１の何れか１項に記載の方法。
13. 請求項１乃至１２の何れか１項に記載の方法を実行するためのコンピュータプログラム。