Ｉｐメディアストリーミングサービスの配信

专利摘要:
ＩＰネットワークに接続されたクライアント端末へのメディアストリームの配信を命令する方法が説明される。本方法は、ユーザ端末（例えば、移動体デバイス）において、前記クライアント端末に対する宛先アドレス情報を特定するステップを含む。前記ユーザ端末は、ＩＰマルチメディア・サブシステム・ネットワークのアプリケーションサーバに対して認証され、前記宛先アドレス情報は、前記ユーザ端末から前記アプリケーションサーバへ送信される。前記メディアストリームは、次いで、前記クライアント端末へ送信される。これにより、前記ユーザ端末の前記認証に基づいてメディアが前記クライアント端末へ配信されることが可能になる。
公开号:JP2011509542A
申请号:JP2010536332
申请日:2007-12-07
公开日:2011-03-24
发明作者:ロベルト スコッグ，；ユスツス ペテション，
申请人:テレフオンアクチーボラゲット エル エム エリクソン（パブル）；
IPC主号:H04L12-56

专利说明:

[0001] 本発明は、ＩＰストリーミングサービスの配信に関し、特に、必ずというわけではないがＩＰＴＶサービスのようなＩＰユニキャストメディアの配信に適用可能である。]
背景技術

[0002] ＩＰテレビ（ＩＰＴＶ）は、ＩＰネットワークを介してテレビを配信可能にするサービスの領域に与えられた名前である。ＩＰネットワークの柔軟な性質が理由で、ＩＰＴＶは、ユニキャストＩＰストリームを介してユーザに配信される情報を伴うユーザに対する更に一層パーソナライズされたサービス（例えば、ビデオ・オン・デマンド）を可能にする。しかしながら、これらのユーザ固有サービスを注文して制御するためには、ユーザは通常、セットトップボックス（ＳＴＢ）／ＴＶの前に座っている間に自分のリモコンを使用することを期待されるであろう。現在、これらのユニキャストストリームを制御する主流の方法は、リアルタイム・ストリーミングプロトコル（ＲＴＳＰ）を使用することである。ＲＴＳＰは伝送プロトコルを指定しないが、例えば、リアルタイム伝送プロトコル（ＲＴＰ）メディアストリームを確立して制御するために使用可能である。ＲＴＳＰは、いろいろな意味で、ウェブを介して情報を要求して交換するために使用されるＨＴＴＰプロトコルに類似しているが、ビデオ及びオーディオのようなストリーミングメディア用にあつらえられている。ＲＴＳＰにより、クライアントは、ストリーミングサーバに対して特定のメディアストリームを要求し、ＰＬＡＹ及びＰＡＵＳＥのようなコマンドを指定することができる。ＲＴＳＰは、従来のセットトップボックスの用途に適している。]
[0003] 予期されることとして、移動体電話のような移動体端末のユーザがＩＰＴＶサービスを利用することを望むことがある。実際、このことは確かに、３Ｇネットワークのような大容量セルラネットワークを現在導入しているネットワークオペレータのビジネスモデルにとって鍵となるものである。セルラネットワーク内では、ＩＰＴＶは、所謂ＩＰマルチメディア・サブシステム（ＩＭＳ）によって促進されるであろうサービスである。ＩＭＳは、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって規定された技術であり、移動体通信ネットワークを介してＩＰマルチメディアサービスを提供するためのものであるが（３ＧＰＰ ＴＳ ２２．２２８， ＴＳ ２３．２１８， ＴＳ ２３．２２８， ＴＳ ２４．２２８， ＴＳ ２４．２２９， ＴＳ ２９．２２８， ＴＳ ２９．２２９， ＴＳ ２９．３２８ 及び ＴＳ ２９．３２９）、ＩＭＳのアーキテクチャは、そのサービスに対して他のインタフェース（例えば、固定アクセスネットワーク）を介してアクセス及び制御できるようになっている。ＩＭＳは、クライアント端末間、又はクライアント端末−アプリケーションサーバ間で呼又はセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述して交渉するために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳによれば、オペレータ及びサービスプロバイダは、サービスに対するユーザのアクセスを制御し、それに応じてユーザに課金することができる。]
[0004] 理解されるであろうこととして、ＩＭＳ及びＲＴＳＰは伝統的に、ユニキャストストリームセッションの確立及び制御のための代替アプローチとして考えられてきた。ＩＭＳはトランスコーダの交渉に加えてＱｏＳ及び課金を制御するためのメカニズムを提供するが、ＲＴＳＰはトリックプレイ及び基本的なビデオ向けのコマンドをサポートする。]
[0005] ユーザがインターネットを介してＳＴＢをリモートで制御することを可能にする多数のシステムが、現在市場に出回っている。これらには、Ｓｏｎｙ ＣｏｒｐｏｒａｔｉｏｎによるＬｏｃａｔｉｏｎＦｒｅｅＴＶＴＭやＳｌｉｎｇ ＭｅｄｉａによるＳｌｉｎｇｂｏｘＴＭが含まれる。これらのシステムは共に、ホームＳＴＢからクライアント端末（例えば、ユーザが滞在中のホテルの部屋にあるＳＴＢ又はテレビ）へのメディアの配信をユーザが命令することを可能にする。]
発明が解決しようとする課題

[0006] ＬｏｃａｔｉｏｎＦｒｅｅＴＶやＳｌｉｎｇｂｏｘのような現在市販されているシステムは、ホームＳＴＢからリモート端末へのメディアの配信を命令するためのリモート端末（例えば、移動体電話、ＰＤＡ、又はラップトップのようなインターネット接続されたデバイス）をユーザに与えるように設計されている。これらは、現在使用中の端末とは異なる何らかの端末（家庭内のものであれ他の場所にあるものであれ）へのメディアの配信をユーザが命令することを可能にするようには設計されていない。仮にこれが可能であったとしても、これは必然的にホームＳＴＢを経由するメディアのルーティングを伴うことになり、サービス品質及び拡張性（スケーラビリティ）の問題を結果としてもたらす。]
[0007] 例えば、ユーザのホテルの部屋又は他の現在地にある端末へのメディアの配信を命令するためにユーザが移動体電話を利用できるようにすることが望ましい。更に、そのような端末がＩＭＳ対応でなくてもそのような端末へのメディアの配信をユーザが命令することが望ましい。]
課題を解決するための手段

[0008] 本発明の一態様によれば、ＩＰネットワークに接続された第２のクライアント端末へのメディアストリームの配信を命令する方法が提供される。本方法は、第１のクライアント端末において、前記第２のクライアント端末に対する宛先アドレス情報を特定するステップを含む。前記第１のクライアント端末はＩＭＳネットワークのアプリケーションサーバに対して認証され、前記宛先アドレス情報は前記第１のクライアント端末から前記アプリケーションサーバへ送信される。前記メディアストリームは前記第２のクライアント端末へ配信される。]
[0009] これが意味するところは、メディアストリームが、アプリケーションサーバに対する第１のクライアント端末の認証及び／又は許可に基づいて第２のクライアント端末へ配信可能であるということである。第１のクライアント端末のユーザは、自分の加入情報（サブスクリプション）を介してメディアに対する支払いをすることができる。第２のクライアント端末は、ＩＭＳ対応である必要がない（とはいえ、理解されるであろうこととして、本発明は第２のクライアント端末がＩＭＳ対応である状況にも適用される）。]
[0010] 宛先アドレス情報は、第２のクライアント端末のＩＰアドレス及びポート番号、及び／又は、第２のクライアント端末がそれ（ゲートウェイ）を介してＩＰネットワークに接続されるＲＧＷのような何らかのゲートウェイのＩＰアドレス及びポート番号を含み得る。]
[0011] アプリケーションサーバに対する第１のクライアント端末の認証は、好ましくは、第１のクライアント端末に関連付けられたユーザＩＤモジュール（例えば、ＳＩＭ／ＵＩＣＣカード）の認証を含む。]
[0012] アプリケーションサーバに対する第１のクライアント端末の認証は、トークンＩＤのハンドシェイクを含み得る。一実施形態では、アプリケーションサーバに対する第１のクライアント端末の認証は、第２のクライアント端末の認証及び／又は許可(authorisation)を含む。第２のクライアント端末がアプリケーションサーバに対して許可されると、第２のクライアント端末は、メディアストリームの配信を直接要求可能であるが、許可は第１のクライアント端末の加入契約から来たものであろう。或いは、メディアストリームは、第１のクライアント端末からアプリケーションサーバへ送信されるＲＴＳＰサービス要求に応えて、第２のクライアント端末へ配信され得る。]
[0013] 一実施形態では、アプリケーションサーバのＲＴＳＰユニフォーム・リソース・ロケータ（ＵＲＬ）が、第１のクライアント端末へ送信され得る。このＲＴＳＰ ＵＲＬは、次いで、第２のクライアント端末へ渡され得る。（アプリケーションサーバによって生成される）セッションＩＤが、第１のクライアント端末から第２のクライアント端末へ渡され、第２のクライアント端末によってメディアストリームの配信を要求するために使用され得る。]
[0014] 例えば、セッションＩＤは、ＲＴＳＰＳＥＴＵＰ手順の結果として、第１のクライアント端末によって特定され得る。このセッションＩＤは、次いで、第２のクライアント端末によってアプリケーションサーバへ送信されるＲＴＳＰＰＬＡＹの中で使用され得る。]
[0015] 更なる代替では、第２のクライアント端末がＩＭＳ対応の場合、ＳＩＰＩＮＶＩＴＥメッセージが、第１のクライアント端末からアプリケーションサーバへ送信されるサービス要求に応えてアプリケーションサーバから第２のクライアント端末へ送信され得る。]
[0016] 第１のクライアント端末は、好ましくは、セルラアクセスネットワークを介してＩＰＷＡＮネットワークに接続され得る。第２のクライアント端末は、固定アクセスネットワークを介してＩＰネットワークに接続され得る。一実施形態では、固定アクセスネットワークを介したメディアストリームの第２のクライアント端末への配信のためのリソースの予約が、第２のクライアント端末からアプリケーションサーバへ送信されるＩＭＳメッセージ（好ましくは、ＳＩＰＩＮＶＩＴＥメッセージ）によって開始される。]
[0017] 好ましくは、第１のクライアント端末は、宛先アドレス情報を特定するために、第２のクライアント端末との通信を確立する。この通信は、ＷＬＡＮやＢｌｕｅｔｏｏｔｈのようなローカル無線ネットワークを使用して確立され得るが、理解されるであろうこととして、他の通信手段（例えば、赤外線、ケーブル）も可能である。]
[0018] メディアは、好ましくは、ＩＰＴＶのようなユニキャストメディアであるが、理解されるであろうこととして、他のメディアも注文されてもよい。例えば、ブロードキャストＴＶやゲームのようなメディアも提供されてもよい。]
[0019] 本発明の他の態様によれば、ＩＰネットワークに接続されたクライアント端末へのメディアの配信を制御するための、ＩＭＳにおいて使用されるアプリケーションサーバが提供される。このアプリケーションサーバは、前記ＩＰマルチメディア・サブシステムの第１のクライアント端末から、前記ＩＰネットワークに接続された第２のクライアント端末に対する宛先アドレス情報を受信する受信機を備える。このアプリケーションサーバはまた、前記第１のクライアント端末を認証する認証手段と、メディア供給源から前記第２のクライアント端末への前記メディアの配信を手配するプロセッサ及び送信機と、を備える。前記メディア供給源はいかなる適切なメディア供給源であってもよく、例えば、ｎＰＶＲ、ビデオ・オン・デマンド・サーバ、等である。]
[0020] 本発明の他の態様によれば、ＩＰマルチメディア・サブシステムのアプリケーションサーバと通信するために使用されるように構成されるユーザ端末が提供される。このユーザ端末は、第２のクライアント端末から宛先アドレス情報を受信する受信機と、前記宛先アドレス情報を前記アプリケーションサーバへ送信し、前記アプリケーションサーバに対して前記ユーザクライアント端末を認証し、前記第２のクライアント端末へのメディアの配信を手配するように前記アプリケーションサーバに対して命令する、送信機／プロセッサ／受信機と、を備える。このユーザ端末は、好ましくは、前記アプリケーションサーバと通信するためのＨＴＴＰインタフェースと、リモート端末と通信するための無線インタフェースと、を備える。]
[0021] 本発明の他の態様によれば、クライアント端末へメディアストリームを配信する方法が提供される。本方法は、アプリケーションサーバに対してユーザ端末を認証するステップと、前記クライアント端末のアドレスの詳細を前記ユーザ端末から前記アプリケーションサーバへ送信するステップと、を備える。]
図面の簡単な説明

[0022] ＩＰＴＶのトポロジ・アーキテクチャを概略的に示す図である。
図１に示すネットワークのＩＰＴＶ ＡＳを概略的に示す図である。
図１のネットワークの移動局を概略的に示す図である。
本発明の第１の実施形態に係る、メディアストリームの配信をリモートで命令する処理を示す図である。
本発明の第２の実施形態に係る、メディアストリームの配信をリモートで命令する処理を示す図である。
図５の処理の単純化されたバージョンを示す図である。] 図１ 図５
実施例

[0023] ＩＰマルチメディア・サブシステム（ＩＭＳ）のアーキテクチャ及び動作に関する簡単な説明は、本発明の実施形態を理解する助けとなろう。]
[0024] 呼セッション制御機能（ＣＳＣＦ）はＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは３種類のＣＳＣＦを定義する。即ち、ＳＩＰクライアント（典型的には、クライアント端末に内蔵されている）にとってのＩＭＳ内での最初の接点であるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び、正しいＳ−ＣＳＣＦを特定し、ＳＩＰ端末からＰ−ＣＳＣＦ経由で受信した要求をそのＳ−ＣＳＣＦに対して転送する役割を担う、インテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。]
[0025] ユーザは、規定されているＳＩＰＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザＩＤに到達可能な（ＩＰ）アドレスをＩＭＳに対してアナウンスするためのメカニズムである。ユーザは、Ｓ−ＣＳＣＦから、ダイアログを開始する際に使用すべき固有のユニフォーム・リソース・アイデンティファイア（ＵＲＩ）を受信する。３ＧＰＰでは、ＳＩＰクライアントが登録を実行する際に、ＩＭＳは（ＡＫＡ手順を使用して）ユーザを認証し、利用可能なＳ−ＣＳＣＦのセットからのＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てる基準については３ＧＰＰで規定されていないが、基準には、負荷分散及びサービス要件が含まれ得る。なお、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスに対するユーザアクセスを制御する（そしてこれに課金する）鍵となるものである。]
[0026] 登録処理の間、Ｉ−ＣＳＣＦの責務は、まだＳ−ＣＳＣＦが選択されていない場合にＳ−ＣＳＣＦを選択することである。Ｉ−ＣＳＣＦは、必要とされるＳ−ＣＳＣＦ能力をホームネットワークのホーム加入者サーバ（ＨＳＳ）から受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。（なお、ユーザが他の当事者によって呼び出され、その時点でユーザにＳ−ＣＳＣＦが割り当てられていない場合にも、Ｓ−ＣＳＣＦの割り当てがＩ−ＣＳＣＦによってユーザのために実行される。）登録されたユーザが続いてセッション要求（例えば、ＳＩＰＩＮＶＩＴＥ）をＩＭＳへ送信する際に、その要求は、Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦのＵＲＩを含むので、Ｐ−ＣＳＣＦはその要求を選択されたＳ−ＣＳＣＦへ転送することができる。このことは、（ＩＭＳの）発信側及び着信側の両方に当てはまる。（着呼については、要求にはＰ−ＣＳＣＦアドレス及びユーザ装置（ＵＥ）アドレスが含まれるであろう。）]
[0027] ＩＭＳサービスネットワーク内には、ＩＭＳサービス機能を実装するためのアプリケーションサーバ（ＡＳ）が備えられる。ＡＳはＩＭＳシステムにおいてエンドユーザにサービスを提供する。ＡＳは、３ＧＰＰで規定されたＭｒインタフェースを介してエンドポイントとして接続されるか、又は、３ＧＰＰで規定されたＩＳＣインタフェースを介してＳ−ＣＳＣＦによって「リンクイン(linked in)」される。後者の場合、ＳＩＰセッション確立中にどのＡＳが「リンクイン」されるべきであるかを決定するために、初期フィルタ基準（ＩＦＣ）がＳ−ＣＳＣＦによって使用される。呼が異なれば、異なるＩＦＣが適用されてもよい。ＩＦＣは、ＩＭＳ登録手順の間に、ユーザのユーザプロファイル（ＵＰ）の一部としてＳ−ＣＳＣＦによってＨＳＳから受信される。ＡＳによっては、加入者ＩＤ（被呼側加入者であれ発呼側加入者であれ、ＡＳを制御するネットワークによって「所有」されているものであれば）に依存した動作を実行するものもある。例えば、呼の転送の場合、適切な（着信）アプリケーションサーバは、所与の加入者に対する呼の転送先である新しい着信側当事者を決定するであろう。]
[0028] ＳＩＰインタフェース（ＩＳＣ又はＭｒ）を持つことと併せて、ＡＳは１以上の非ＳＩＰインタフェースを持つことができる。特に、Ｕｔインタフェースにより、ＡＳは、例えばＲＴＳＰ又はＨＴＴＰプロトコルを使用するクライアント端末と直接通信することができる。]
[0029] 図１は、ＩＰＴＶ／ＩＭＳアーキテクチャの概観を提示し、顧客の敷地内のネットワーク（ＣＰＮ）１（例えば、家庭又はホテルの部屋）の中に備えられる装置／機能と移動局（ＭＳ）２によって備えられる装置／機能とを図示する。ＣＰＮ１及びＭＳ２はそれぞれ、固定アクセスネットワーク４及びセルラアクセスネットワーク５に、そして在圏オペレータのＩＭＳネットワーク６に接続している。セットトップボックス（ＳＴＢ）９に接続するＴＶ１０は、ＣＰＮ１内に位置する。ＳＴＢ９は、直接、又はレジデンシャルゲートウェイ（ＲＧＷ）１３経由で、固定アクセスネットワークと通信する。ホームオペレータは、ＩＰＴＶサービスプロバイダ３及びホームＩＭＳネットワーク１９を提供する。ここで関心のあるネットワークエレメントは、次の通りである。] 図１
[0030] ＭＴＲＸ −メディア送信／受信部７，８。ＳＴＢ９内の「伝統的な」セットトップボックス機能であり、例えば、ＭＰＥＧ２及び／又はＭＰＥＧ４ストリームの受信、及び、そのようなストリームのＴＶ１０への配信のための変換である。ＭＳ２内のＭＴＲＸ８はＩＭＳ対応でなければならない。ＳＴＢ９内のＭＴＲＸ７はＩＰ対応であることだけが必要である。]
[0031] ＩＭＯＤ − ＩＤ及びＩＭＳモジュール１２。基本的なＩＭＳサービスロジック及びＩＳＩＭを含んだＩＭＳ対応セットトップボックスの部分である。ＩＭＯＤはＭＳ内に実装されて、ＴＶサービスに対するリモートアクセスを可能にする。]
[0032] ＷＩＦＩ − ｗｉｆｉアプリケーション２０，２１（例えば、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）又はＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ））は、ＭＳ２がＳＴＢ９と直接通信することを可能にする。]
[0033] ＡＳ −アプリケーションサーバ１４。ＭＳ（及び他のＩＭＳユーザデバイス）とＩＰＴＶビデオサーバとの間で相互にやり取りする(interact)機能である。ＡＳはまた、ＨＴＴＰ及びＲＴＳＰのメッセージを受信して処理し、メディアをＳＴＢ９へ送信する。]
[0034] ビデオストリーミングサーバ− ビデオストリーミングサーバ１５。これは、ユニキャスト（ストリーミング）メディアのソース（供給源）である。]
[0035] ＶｏＤ −ビデオ・オン・デマンド（制御）サーバ１６。このサーバは、分散ビデオユニキャストサーバに対するアクセス、及び分散ビデオユニキャストサーバからの再生を制御する。]
[0036] ｎＰＶＲ −ネットワークベースのパーソナルビデオレコーダ１７。このサーバは、加入者がメディア（例えば、番組）をネットワーク内に格納することを可能にする。再生は、ＩＰＴＶ ＡＳを介して制御される。]
[0037] ＥＰＧ−電子番組表１８。ＥＰＧサーバは、現在利用可能なメディア及び間もなく始まるメディアの詳細を格納する。加入者は一般的に、ＩＰＴＶ ＮＷ ＡＳ経由でＥＰＧをダウンロードし、（ＶｏＤ／ビデオユニキャストサーバにおいて利用可能な）メディア配信を選択又はプログラムするために、これを使用する。]
[0038] ＭＴＲＸエンティティは、ＩＰＴＶサービスにアクセスするために使用されるＳＴＢの中に存在することになる。加えて、図１に示すように、ＭＴＲＸエンティティ８及びＩＭＯＤ１２は、移動局（ＭＳ）２又はクライアント端末（例えば、セルラ電話であってよい）の中に存在する。理解されるであろうとこととして、ＭＳはＩＰＴＶサービスのオペレータではないオペレータのＩＭＳネットワーク６の中に存在してもよい。] 図１
[0039] 図２は、ＩＰＴＶ ＡＳ１４内の機能エレメントを概略的に示す。機能エレメントには、ホームオペレータのＩＭＳネットワーク１９に接続される受信機２２、及び、固定アクセスネットワーク４に接続可能なプロセッサ／送信機２３が含まれる。図３は、ＭＳ２内の機能エレメントを概略的に示し、即ち、ＳＴＢ９と通信するための送受信機２４、ＩＰＴＶ ＡＳに対してサービス要求を送信するための送信機２５、及び、ＩＰＴＶ ＡＳからシグナリング情報を受信するための受信機２６がある。] 図２ 図３
[0040] ここで、ＣＰＮ１に位置する何らかのサードパーティー端末（ＳＴＢ）９へのメディアの配信をＭＳ２のユーザが命令することを可能にするための処理を、図４を参照して説明する。] 図４
[0041] 図４は、本発明の第１の実施形態に係る処理フローを示す。ステップＳ１で、ＭＳ２は、ＳＴＢ９のＩＰアドレス、ポート番号、及び能力を取得する。これは一般的に、例えばＤＬＮＡ又はＵＰｎＰを使用して無線接続を介して実行される。しかしながら、情報の必要な交換を可能にするあらゆる接続が使用可能である。ＳＴＢがＲＧＷ（図４には図示せず）経由で固定アクセスネットワークと通信する場合、ＲＧＷの外部ＩＰアドレス及びポート番号もＭＳ２によって取得される。] 図４
[0042] ステップＳ２で、ＭＳは在圏ＩＭＳネットワーク６経由で自分のホームＩＭＳネットワーク１９にコンタクトする。ＭＳ２は、ホームＩＭＳネットワーク１９によって、そのネットワークにおける加入契約を有するものとして認証される。ステップ２は、ＳＩＰシグナリングを使用して実行される。]
[0043] ステップＳ３で、ＭＳ２はＩＰＴＶサービスプロバイダ３によって認証される。ＳＴＢ９及び／又はＲＧＷ１３のＩＰアドレス及びポート番号がＩＰＴＶサービスプロバイダ３に対して提供可能であり、すると、これらはこの手順において後でＳＴＢによって認証／許可の信用保証情報(credential)として使用可能である。更なる代替では、ＩＰＴＶサービスプロバイダ３は特定のトークンＩＤを生成してローカルに格納してもよい。このトークンＩＤは後に、ＭＳからＳＴＢへと渡され、サービス要求メッセージに応じてＳＴＢが要求されたサービスを受信できるようにする。ステップ２及び３の結果として、ＭＳ２は、ＩＰＴＶサービスプロバイダ３からＳＴＢ９へのメディアの配信をアレンジ（手配）可能であり、ＭＳ２の加入契約を介して、このメディアに対するユーザのホームＩＭＳネットワーク１９への支払いをすることができる。]
[0044] ステップＳ４で、ＭＳ２は、在圏移動体ネットワーク６経由でＩＰＴＶサービスプロバイダ（この時点でＭＳ２はＩＰＴＶサービスプロバイダに対して認証されている）にコンタクトし、最終的にメディアを提供するエンティティのＵＲＬ又はソースＩＰ及びポート番号に関する詳細を要求する。ＭＳ２はまた、ＥＰＧを要求してもよい。ＥＰＧは、ＭＳ２によってユーザに対して表示されてもよいし、或いは、（ステップＳ５で示すように）テレビ１０で表示されるようにＭＳからＳＴＢ９へ転送されてもよい。ＭＳ２はまた、この段階で、ＩＰＴＶサービスプロバイダのＩＰアドレス及びポート番号を、（取得された場合は）ステップＳ３で言及したトークンＩＤと共にＳＴＢ９へ渡してもよい。ステップＳ４は、ＨＴＴＰを使用して実行可能である。]
[0045] ステップＳ６で、ユーザが受信したいＩＰＴＶサービスを選択すると、ＭＳ２は、望まれたＩＰＴＶサービスの配信のために必要なリソースを予約するために在圏移動体ネットワーク５経由でＩＰＴＶサービスプロバイダにコンタクトする。ＭＳ２は、ＳＴＢ９（及び／又はＲＧＷ１３）の外部ＩＰアドレス及びポート番号をＩＰＴＶサービスプロバイダに提供する（このことがステップ３のトークン交換の一部として既に行われたのでなければ）。ステップ５は、ＳＩＰを使用して実行される。]
[0046] この処理の一部として、ステップ７で、固定アクセスネットワークのためのメディアプレーンのセットアップを行うことができる。これは、在圏ＩＭＳネットワークにおいてＲＧＷ１３又はＳＴＢ９の外部ＩＰアドレスによってトリガされ得る。ＩＭＳネットワーク１６は、ＲＧＷ１３へのＩＰデータの配信のために適切な経路は固定アクセスネットワーク４を介するものであると認識し、それに従ってメディアプレーンがセットアップされる。ステップＳ７は、ＳＩＰを使用して実行される。]
[0047] 一実施形態では、ステップＳ６は、ＭＳ２からホームＩＭＳネットワーク１９へ向かって送信されるＳＩＰＲＥＱＵＥＳＴメッセージによって開始される。ＲＥＱＵＥＳＴメッセージはＲＧＷの外部ＩＰアドレスを含み、これは、ステップ７において、必要とされるリソースを固定ネットワーク４上で予約するために在圏ＩＭＳネットワーク６によって使用される。]
[0048] ステップＳ８で、ＭＳ２は、ＳＴＢ９へのＩＰＴＶサービスの配信を要求する。このことは例えば、ＭＳ２からのＳＩＰＩＮＶＩＴＥメッセージによって達成される。ＳＩＰ ＩＮＶＩＴＥメッセージは、ビデオストリーミングサーバへと更に中継（リレー）される前に、ＩＰＴＶサービスプロバイダのネットワーク内のＡＳによってＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージ及びＳＥＴ−ＵＰメッセージへとマッピングされる。次いで、ＲＴＳＰＰＬＡＹがＭＳから送信される。直接の場合であれＲＧＷ１３経由の場合であれ、「シンク」ＩＰアドレス及びポート番号はＳＴＢ９のものである。或いは、ＩＰＴＶサービスの配信は、ＭＳ２及びＳＴＢ９によって合同で要求されてもよい。この場合、ＳＩＰ ＩＮＶＩＴＥメッセージは今説明したようにＭＳ２から送信されるが、ＲＴＳＰ ＰＬＡＹはＳＴＢ９から発信される。]
[0049] ステップＳ９で、ＩＰＴＶサービスプロバイダからＳＴＢ９へと固定アクセスネットワーク４を介してＩＰＴＶサービスが配信される。ユーザは、ホームＩＭＳネットワーク１９に対する加入契約の結果として、サービスに対して支払いをすることになる。]
[0050] 図５は、本発明の代替実施形態を示す。この実施形態では、ＩＰＴＶサービスが選択されると、ステップＳ８’’において純粋にＳＴＢ９からこれが要求される。これは例えば、ＲＴＳＰ ＤＥＳＣＲＩＢＥ、ＳＥＴ−ＵＰ、又はＰＬＡＹメッセージを使用して実行可能である。この例では、ＩＰＴＶサービスに対していなかるリソースも予約されないし、ＩＰＴＶサービスに結合されるチャットやメッセージングのようなインタラクティブなサービス（双方向サービス）が促進されることもないということに気づくであろう。] 図５
[0051] 更なる代替実施形態（不図示）では、ＳＴＢ９又はＴＶ１０もＩＭＳ対応であってもよい。この場合、図４のステップ３においてＭＳ２は、ＳＴＢ９のＩＰアドレス及びポート番号をＩＰＴＶサービスプロバイダに対して特定する。ステップ５で、ＭＳ２は、ＩＰＴＶサービスプロバイダ３に対してサービス要求メッセージを送信し、その結果として、ＩＰＴＶサービスプロバイダはＳＴＢ９に対してＳＩＰＩＮＶＩＴＥメッセージを送信し、メディアの配信をアレンジ（手配）するためにＳＩＰ交渉がＩＰＴＶサービスプロバイダ３とＳＴＢ９との間で直接行われ得る。しかしながら、交渉はホームＩＭＳネットワークに対する最初の認証に従わなければならないので、ユーザは依然として自分の加入契約を介して課金されるであろう。] 図４
[0052] 更なる実施形態では、ＭＳは、ＩＰＴＶサービスプロバイダのＡＳのＲＴＳＰ ＵＲＬを取得する。これは、ＳＴＢ９にも渡され得る。ＲＴＳＰＳＥＴＵＰが実行された後に（即ち、図６に示すＳ５の間）、特定のセッションＩＤがＭＳからＳＴＢへと渡され得る。このセッションＩＤは、次いで、ＩＰＴＶサービスプロバイダに対して送信されるＳＴＢ ＲＴＳＰＰＬＡＹの中に含まれ得る。] 図６
[0053] 図６は、ＩＰＴＶサービスを注文するためにＭＳ２がＩＭＳネットワーク１９内のプロキシ６１経由でＩＰＴＶ ＡＳ１４にコンタクトする、高レベルで単純化された構成を示す。図６は、図４及び図５の組み合わせであり、図４の全ての利益を促進するが、図５のようにＳＴＢが最後のＲＴＳＰＰＬＡＹメッセージを発行することが追加される。イベントのシーケンスは次の通りである。] 図４ 図５ 図６
[0054] ST1. UPnP:ＩＰＴＶ ＳＴＢ９のＩＰアドレス、ポート番号、及び能力を取得
ST2. UPnP: 外部ＩＰアドレス、ポート番号、及びＩＰＴＶアドレスのマッピングを取得
ST3.SIP: INVITE（接続されているＲＧＷ１３のＩＰアドレス及びポート番号）
ST4. SIP: INVITE （接続されているＲＧＷ１３のＩＰアドレス及びポート番号）
ST5.RTSP: DESCRIBE,SET-UP （接続されているＲＧＷ１３のＩＰアドレス及びポート番号）
ST6. UPnP/DLNA: "PLAY" Session ID from IPTV Server
ST7. RTSP: PLAY RTSP URL and Session ID from IPTV Server （シンクＩＰアドレス／ポート番号はＲＧＷ１３のものである。これらはＲＧＷ１３の中でＩＰＴＶへマッピングされる。）
ST8. RTP: メディア配信]
[0055] このように、本発明では、ＩＭＳ交渉及びリソース予約がＭＳとＩＰＴＶサービスプロバイダとの間で行われるので、あらゆるＩＰ対応デバイスへのＩＰＴＶの配信をユーザが命令することが可能になる。サービスは、どこでも、又はいつでも、提供可能である。シグナリングは移動体デバイスによって行われるので、ブロードバンド接続のアップリンクに関する制約が存在しない。以前から知られているソリューションに比べて、メディア配信パスは大きく削減される。ホームネットワークは複雑である必要がない。単にＩＰＴＶサービスを受信するように構成されていればよい。]
[0056] 更に、ＩＭＳベースのＩＰＴＶに関する主要な利点の１つである「インタラクティブ性（双方向性）」が、ＩＰＴＶ画面を介する（ＩＭＳ対応のＳＴＢが使用される場合にはそうなる）代わりにＭＳを介して処理可能である。このことは、図４及び図６に示すシグナリングシーケンスに従う場合に特に、真である。] 図４ 図６
[0057] 当業者には理解されるであろうこととして、本発明の範囲から逸脱すること無しに、上述した実施形態に対する多様な修正を行うことができる。例えば、上述したステップは単純な環境を示したが、ファイアウォール及びネットワークアドレス変換（ＮＡＴ）が関与するもっと複雑な環境に対しても本発明を適用することが不可能であるような理由は、存在しない。これらは、ホームネットワーク内にあってもよいし、オペレータのネットワーク内にあってもよい。]
[0058] 更に、上の実施形態は、セルラネットワークに加入している移動局及び固定アクセスネットワークに加入しているセットトップボックスに関する文脈で説明してきた。他の変形が可能であるということが理解されよう。実際、もっと少ないネットワークしか関与しない場合、複雑さは減少され得る。]
[0059] 加えて、とりわけＩＰＴＶの配信に言及して全ての実施形態を説明してきたが。本発明は、オペレータによって提供又は管理される全てのサービスに等しく適用されるということが理解されよう。他の例には、ブロードキャストＴＶ、ゲーム、及び他の類似したアプリケーションが含まれる。]
[0060] やはり理解されるであろうこととして、チャットやメッセージングのような、メディア配信に結び付けられＩＭＳを介して可能とされる個人対個人のインタラクティブなサービスは、ＩＰＴＶ画面以外のデバイス上で動作させられてもよい。例えば、インタラクティブなサービスは依然としてＭＳの表示画面を介して動作させられてもよい。]

权利要求:

請求項1
ＩＰネットワークに接続された第２のクライアント端末へのメディアストリームの配信を命令する方法であって、第１のクライアント端末において、前記第２のクライアント端末に対する宛先アドレス情報を特定するステップと、ＩＰマルチメディア・サブシステム・ネットワークのアプリケーションサーバに対して前記第１のクライアント端末を認証するステップと、前記第１のクライアント端末から前記アプリケーションサーバへ前記宛先アドレス情報を送信するステップと、前記メディアストリームを前記第２のクライアント端末へ配信するステップと、を備えることを特徴とする方法。
請求項2
前記宛先アドレス情報は、前記第２のクライアント端末のＩＰアドレス及びポート番号を含むことを特徴とする請求項１に記載の方法。
請求項3
前記宛先アドレス情報は、レジデンシャルゲートウェイのＩＰアドレス及びポート番号を含み、前記第２のクライアント端末は、前記レジデンシャルゲートウェイを介して前記ＩＰネットワークに接続されることを特徴とする請求項１又は２に記載の方法。
請求項4
前記アプリケーションサーバに対する前記第１のクライアント端末の前記認証は、前記第１のクライアント端末に関連付けられたユーザＩＤモジュールの認証を含むことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
請求項5
前記アプリケーションサーバに対する前記第１のクライアント端末の前記認証は、トークンＩＤのハンドシェイクを含むことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
請求項6
前記アプリケーションサーバに対する前記第１のクライアント端末の前記認証は、前記アプリケーションサーバに対して前記第２のクライアント端末を許可することを含むことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
請求項7
前記アプリケーションサーバのＲＴＳＰユニフォーム・リソース・ロケータが前記第１のクライアント端末へ送信されることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
請求項8
前記アプリケーションサーバの前記ＲＴＳＰユニフォーム・リソース・ロケータが、前記第１のクライアント端末から前記第２のクライアント端末へ渡されることを特徴とする請求項７に記載の方法。
請求項9
セッションＩＤが、前記アプリケーションサーバにおいて生成され、前記第１のクライアント端末へ送信され、前記第１のクライアント端末から前記第２のクライアント端末へ渡され、前記メディアストリームの配信を制御するために前記第２のクライアント端末によって使用されることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
請求項10
前記メディアストリームは、前記第１のクライアント端末から前記アプリケーションサーバへ送信されるＩＭＳＩＮＶＩＴＥメッセージ及びＲＴＳＰＰＬＡＹメッセージに応えて、前記第２のクライアント端末へ送信されることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
請求項11
前記メディアストリームは、前記第１のクライアント端末から前記アプリケーションサーバへ送信されるＩＭＳＩＮＶＩＴＥメッセージ及び前記第２のクライアント端末から前記アプリケーションサーバへ送信されるＲＴＳＰＰＬＡＹメッセージに応えて、前記第２のクライアント端末へ送信されることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
請求項12
前記メディアストリームは、前記第２のクライアント端末から前記アプリケーションサーバへのＲＴＳＰＤＥＳＣＲＩＢＥ、ＳＥＴ−ＵＰ、及びＰＬＡＹに応えて、記第２のクライアント端末へ送信されることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
請求項13
ＳＩＰＩＮＶＩＴＥメッセージが、前記第１のクライアント端末から前記アプリケーションサーバへ送信されるサービス要求に応えて、前記アプリケーションサーバから前記第２のクライアント端末へ送信されることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
請求項14
前記第１のクライアント端末は、セルラアクセスネットワークを介して前記ＩＰネットワークに接続されることを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
請求項15
前記第１のクライアント端末は、固定アクセスネットワークを介して前記ＩＰネットワークに接続されることを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
請求項16
前記固定アクセスネットワークを介した前記メディアストリームの前記第２のクライアント端末への配信のためのリソースの予約が、前記第２のクライアント端末から前記アプリケーションサーバへ送信されるＩＭＳメッセージによって開始されることを特徴とする請求項１５に記載の方法。
請求項17
前記アプリケーションサーバへ送信される前記ＩＭＳメッセージは、前記宛先アドレス情報を含んだＳＩＰＩＮＶＩＴＥメッセージであることを特徴とする請求項１６に記載の方法。
請求項18
前記第１のクライアント端末が、前記宛先アドレス情報を特定するために、前記第２のクライアント端末との通信を確立することを特徴とする請求項１乃至１７のいずれか１項に記載の方法。
請求項19
前記第１のクライアント端末と前記第２のクライアント端末との間で確立される前記通信は、ローカル無線ネットワークを使用して確立されることを特徴とする請求項１８に記載の方法。
請求項20
前記メディアはＩＰＴＶメディアであることを特徴とする請求項１乃至１９のいずれか１項に記載の方法。
請求項21
ＩＰネットワークに接続されたクライアント端末へのメディアの配信を制御するための、ＩＰマルチメディア・サブシステムにおいて使用されるアプリケーションサーバであって、前記ＩＰマルチメディア・サブシステムの第１のクライアント端末から、前記ＩＰネットワークに接続された第２のクライアント端末に対する宛先アドレス情報を受信する受信機と、前記第１のクライアント端末を認証する認証手段と、メディア供給源から前記第２のクライアント端末への前記メディアの配信を手配するプロセッサ及び送信機と、を備えることを特徴とするアプリケーションサーバ。
請求項22
前記宛先アドレス情報は、前記第２のクライアント端末のＩＰアドレス及びポート番号を含むか、又は、前記第２のクライアント端末がレジデンシャルゲートウェイを介して前記ＩＰネットワークに接続されている場合、前記レジデンシャルゲートウェイのＩＰアドレス及びポート番号を含むことを特徴とする請求項２１に記載のアプリケーションサーバ。
請求項23
前記認証手段は、前記第１のクライアント端末に関連付けられたユーザＩＤモジュールを認証するように構成されることを特徴とする請求項２１又は２２に記載のアプリケーションサーバ。
請求項24
前記認証手段は、トークンＩＤのハンドシェイクを実行するように構成されることを特徴とする請求項２１乃至２３のいずれか１項に記載のアプリケーションサーバ。
請求項25
前記認証手段は、前記第１のクライアント端末の前記認証の結果として前記第２のクライアント端末を許可するように構成されることを特徴とする請求項２１乃至２４のいずれか１項に記載のアプリケーションサーバ。
請求項26
前記受信機は、前記第１のクライアント端末からのＲＴＳＰサービス要求を受信するように構成され、前記プロセッサ及び送信機は、前記ＲＴＳＰサービス要求に応えて前記第２のクライアント端末への前記メディアの配信を手配するように構成されることを特徴とする請求項２１乃至２５のいずれか１項に記載のアプリケーションサーバ。
請求項27
前記プロセッサ及び送信機は、前記第１のクライアント端末から受信したサービス要求に応えて前記第２のクライアント端末に対してＳＩＰＩＮＶＩＴＥメッセージを送信するように構成されることを特徴とする請求項２１乃至２５のいずれか１項に記載のアプリケーションサーバ。
請求項28
前記受信機は、前記第２のクライアント端末からＲＴＳＰＰＬＡＹコマンドを受信するように構成され、前記プロセッサ及び送信機は、前記ＲＴＳＰＰＬＡＹコマンドに応えて前記第２のクライアント端末への前記メディアの配信を手配するように構成されることを特徴とする請求項２５に記載のアプリケーションサーバ。
請求項29
ＩＰマルチメディア・サブシステムのアプリケーションサーバと通信するために使用されるように構成される第１のクライアント端末であって、第２のクライアント端末から宛先アドレス情報を受信する受信機と、前記宛先アドレス情報を前記アプリケーションサーバへ送信し、前記アプリケーションサーバに対して前記第１のクライアント端末を認証し、前記第２のクライアント端末へのメディアの配信を手配するように前記アプリケーションサーバに対して命令する、送信機／プロセッサ／受信機と、を備えることを特徴とする第１のクライアント端末。
請求項30
前記アプリケーションサーバと通信するためのＨＴＴＰインタフェースを更に備えることを特徴とする請求項２９に記載の端末。
請求項31
前記第２のクライアント端末と通信するための無線インタフェースを更に備えることを特徴とする請求項２９又は３０に記載の端末。
請求項32
第２のクライアント端末へメディアストリームを配信する方法であって、アプリケーションサーバに対してユーザ端末を認証するステップと、前記第２のクライアント端末のアドレスの詳細を前記ユーザ端末から前記アプリケーションサーバへ送信するステップと、を備えることを特徴とする方法。