JP5576882B2 - ドメインおよび加入をこえてセッションを転送するシステムおよび方法 - Google Patents

Description

本発明は、一般的には、ＩＰＴＶ環境でのセッションの転送に関する。

ＩＰＴＶは、ストリームされたコンテンツをユーザに提供するために、パケットベースの配信メカニズムを採用する。典型的に、ＩＰＴＶネットワークは、視聴者端末とコンテンツソースとの間のセッションを生成するのに用いられるシグナリングプロトコルとしてＳＩＰを利用する。ＳＩＰの使用は、視聴者とコンテンツソースとの間のセッションを生成するための、ＩＰＴＶ制御サーバのような中間ノードを許容する。このとき、ＩＰＴＶ制御サーバは、ユーザ認証および権限を与える機能を集中化しうる。加えて、ＩＰＴＶ制御サーバによって生成されたレコードを用いて、課金が処理されうる。

ＩＰＴＶコンテクストにおけるＣＯＤ（Content On Demand）配信システムは、知られた技術である。同様に、あるユーザ端末と別のものとの間のセッションの転送も、知られた技術である。それは、ユーザがＣＯＤセッションを一時停止し、セッションを別の端末に転送することをＩＰＴＶ管理サーバにリクエストすることを可能にするための常識であり、知られた技術である。このことは、例えば、ユーザが家のある部屋で映像の視聴を開始し、それから家の別の部屋に映像を転送することを可能にする。ＩＰＴＶ制御サーバにとって、それぞれのセットトップボックス、またはオープンＩＰＴＶ端末機能（ＯＩＴＦ：Open IPTV Terminal Function）は分離したエンティティであり、コンテンツが最初の端末に配信されることをユーザがリクエストすることは、必ずしもコンテンツが別の端末に自動的に配信されるべきことを意味しない。セッション転送は、エンドユーザに有用な機能を提供し、ユーザ体験を向上させる。

しかしながら、知られた技術であるセッション転送メカニズムは、あるＯＩＴＦから他のものにセッションを転送するＩＰＴＶ制御サーバを中心に展開するものであり、両方のＯＩＴＦは同じＩＰＴＶ制御サーバによってサービスを提供されている。多くの場合このことは問題ではないが、いくらかの柔軟性をユーザに与えないものである。例えば、ユーザが家でＣＯＤプログラムを開始したが、それからプログラムをモバイルデバイスに転送したいと思っても、その２つの端末が異なるＩＰＴＶ制御サーバによってサービスを提供されていれば可能ではないであろう。論理的な観点から、異なるＩＭＳ（Internet Multimedia System）への加入は、異なるＩＰＴＶ制御サーバと何ら相違しないことを当業者は理解するであろう。以下の考察では独立したＩＰＴＶ制御サーバが参照されるが、２つの異なる加入（subscription）を可能にする１つのサーバはその均等物である。

同じＩＰＴＶ制御サーバによってサービスを提供されていない端末の間で（または、上記のように同じ物理サーバでの２つの異なる加入の間で）セッションを転送することに関しては多くの技術的困難がある。同じＩＰＴＶ制御サーバによってサービスを提供される（および同じ加入の下の）端末の間での転送は、ＩＰＴＶ制御サーバがコンテンツソースにコンテンツストリームの新たな行き先を指示するようにすることで簡単に実行されうるが、転送の行き先の端末が同じＩＰＴＶ制御サーバによってサービスを提供されていない場合これは可能ではない。ＩＰＴＶ制御サーバは、典型的には２つのシグナリングセッションを生成し、第１のセッションはＩＰＴＶ制御サーバを端末エンドポイントに接続し、第２のセッションはＩＰＴＶ制御サーバをコンテンツソースに接続する。

セッションがＩＰＴＶ制御サーバによって生成され、第１のセッションが典型的にはＩＰＴＶ制御サーバを端末に接続し、第２のセッションがＩＰＴＶ制御サーバをコンテンツソースに接続して、ＩＰＴＶ制御サーバがＳＩＰのようなプロトコルを用いてセッション情報を監視および制御するサードパーティーコールコントロールとして動作することが可能になる。所望の受信者端末に関連付けられたＩＰＴＶ制御サーバは、第１のＩＰＴＶ制御サーバによって認識されているセッション情報を有していない。而して、第２のＩＰＴＶ制御サーバは同じようにしてセッションを制御することはできない。従って、従来および公知の方法を用いるセッション転送は、複数のＩＰＴＶ制御サーバにまたがることが可能ではない。

そこで、同じＩＰＴＶ制御サーバによってサービスを提供されない端末の間のセッション転送のためのメカニズムを提供することが望まれている。

本発明の目的は、先行技術の不利な点の少なくとも１つを除去または軽減するメカニズムを提供することである。

本発明の第１の観点では、ネットワークアドレスを有するインターネットプロトコルテレビジョン（ＩＰＴＶ：Internet Protocol Television）制御サーバが提供される。制御サーバは、ダウンストリームインターフェース、アップストリームインターフェース、制御サーバインターフェース、およびプロセッサを含む。ダウンストリームインターフェースは、ＩＰＴＶ端末とのセッションを初期化し、セッション初期化の間にネットワークアドレスを端末に送信する。アップストリームインターフェースは、端末とコンテンツプロバイダとの間のセッション初期化し、端末とプロバイダとのセッションについての状態情報を受信する。制御サーバインターフェースは、別の制御サーバと通信する。プロセッサは、セッション転送のために制御サーバインターフェースを通じて受信された別の制御サーバからのリクエストに応じて、アップストリームを通じて状態情報をリクエストし、セッション転送のためのリクエストに応じて別の制御サーバに状態情報を提供する。

本発明の第１の観点の実施形態において、ダウンストリームインターフェースは中間ノードを通じてＩＰＴＶ端末と通信し、付加的に、ＩＰＴＶ端末はオープンＩＰＴＶ端末機能である。別の実施形態において、ダウンストリームインターフェース、アップストリームインターフェース、および制御サーバは共通のネットワークインターフェースに統合される。

さらなる実施形態において、プロセッサはセッションに関するブックマーク情報を生成し、該ブックマーク情報はセッションにおけるＩＰＴＶ端末の位置を識別する。付加的に、ブックマーク情報は別の制御サーバに提供されるセッション転送情報の一部であり、システムは生成されたブックマーク情報を格納するデータベースをさらに含んでもよい。

別の実施形態において、プロセッサは制御サーバインターフェースを通じてセッション転送のリクエストを発行する。付加的に、プロセッサはリクエストに応じて制御サーバインターフェースを通じてセッション転送情報を受信し、さらに、受信されたセッション転送情報において特定されるパラメータに従って、ＩＰＴＶ端末とセッション転送情報によって特定されるコンテンツソースとの間のセッションをイニシエートする。さらなる実施形態において、サーバは受信されたセッション転送情報を格納するデータベースをさらに含む

本発明の第２の観点では、インターネットプロトコルテレビジョン（ＩＰＴＶ）制御サーバによって管理されるセッションを転送する方法が提供され、該セッションはコンテンツソースとＩＰＴＶ端末とを接続する。方法は、ＩＰＴＶ制御サーバにおいて別のＩＰＴＶ制御サーバからセッションの転送管理のリクエストを受信するステップと、受信したリクエストに応じて別のＩＰＴＶ制御サーバにセッションに関するセッション転送情報を送信するステップとを含む。

本発明の第２の観点の実施形態において、方法は、いくつかの実施形態では送信するステップに続いて、ＩＰＴＶ端末がセッションを一時停止することをリクエストするステップをさらに含む。別の実施形態において、方法はセッションのためのブックマークを生成するステップをさらに含み、該ブックマークはセッションプレイバック処理でのＩＰＴＶ端末の現在位置を記録する。代替的な実施形態において、ブックマークは、別のＩＰＴＶ制御サーバに送信されるセッション転送情報に含まれる。

第２の観点のさらなる実施形態において、セッション転送情報は、セッションに関するコンテンツ配信ノードを特定する情報を含む。別の実施形態において、方法はセッション転送情報の送信後にセッションをティアダウンすることをリクエストするステップをさらに含む。

本発明の第３の観点では、第１のインターネットプロトコルテレビジョン（ＩＰＴＶ）制御サーバによって管理されるセッションを第２のＩＰＴＶ制御サーバに転送する方法が提供され、該セッションはコンテンツソースとＩＰＴＶ端末とを接続する。方法は、第２のＩＰＴＶ制御サーバにおいて第１のＩＰＴＶ制御サーバからのセッションの転送を開始する指示、該セッション転送指示は第１のＩＰＴＶ制御サーバに関するネットワークアドレスを含む、をＩＰＴＶ端末から受信するステップと、セッションの管理制御を転送するリクエストを第１のＩＰＴＶ制御サーバに送信するステップと、送信されたリクエストに応じてセッションに関するセッション転送情報を受信するステップと、転送をする指示がそこから受信されたＩＰＴＶ端末とセッション転送情報において特定されるコンテンツソースとの間のセッションをイニシエートするステップとを含む。

本発明の第３の観点の実施形態において、転送をする指示がそこから受信されるＩＰＴＶ端末は、転送されるセッションに参加するＩＰＴＶ端末とは異なる。別の実施形態において、転送をリクエストする指示は、転送されるセッションに関するセッション転送情報を含み、付加的に、セッション転送情報はブックマークを含む。さらなる実施形態において、リクエストを送信するステップはブックマーク情報のリクエストを送信することを含み、付加的に、受信されたセッション転送情報はリクエストされたブックマーク情報を含む。

本発明の他の観点および特徴は、添付図面とともに以下の発明の詳細な実施形態の説明を参照すれば当業者には明らかであろう。

本発明の実施形態が、これより、以下の添付図面を参照して、あくまでも例として説明される。

本発明の処理の初期化の例示的な一実施形態で用いられるメッセージフローを表すメッセージフロー図を示す。 本発明の例示的な一実施形態で用いられるメッセージフローを表すメッセージフロー図を示す。 本発明の例示的な実施形態で用いられるメッセージフローを表すメッセージフロー図を示す。 本発明の別の例示的な実施形態を示すメッセージフロー図を示す。 本発明の例示的な方法を示すフローチャートである。 本発明の例示的な方法を示すフローチャートである。 本発明の例示的な方法を示すフローチャートである。 本発明の例示的な方法を示すフローチャートである。 本発明のシステムの例示的な論理実装を示すブロック図である。

本発明は、ＩＰＴＶセッションをある端末から別のものに転送するシステムおよび方法に適する。このシステムおよび方法は、端末のそれぞれが異なるＩＰＴＶ制御サーバによってサービスを提供される場合、または２つの端末がそれぞれ異なるＩＭＳ加入に属する場合に生じる転送を可能にする。

上記のように、ＩＰＴＶネットワークにおけるノード間のセッション転送は、一般的には同じＩＰＴＶ制御サーバによってサービスを提供される、および一般的には同じＩＭＳ加入に属する２つの端末ノードの間でセッションを転送することに限定される。以下の説明の簡単のために、独立したＩＰＴＶ制御サーバの参照は、異なるＩＭＳ加入の下にあるＯＩＴＦノードをサポートする単一の物理ＩＰＴＶ制御サーバの論理的に類似した状況をも含むことが、当業者には理解されるであろう。異なる制御サーバによってサービスを提供される２つのノードの間でセッションを転送することに関する多くの問題は、先行技術によっては対処されていない。異なる制御サーバによってサービスを提供される２つのノードに間でセッションを転送することに関する問題に払われる注意が欠けていた理由の１つは、異なる制御サーバによってサービスを提供される端末または異なる加入の下の端末の間でセッションを転送するというアイディア全体にほとんど注意が払われてこなかったことである。

当業者には理解されるように、オープンＩＰＴＶ端末機能（ＯＩＴＦ）は、ＩＰＴＶ制御サーバ（ＩＰＴＶ ＣＳ：IPTV Control Server）とのシグナリングセッションを生成する。一方、ＩＰＴＶ制御サーバは、ＣＤＮＣ（Content Delivery Network Controller）、ＣＣ（Cluster Controller）、およびＣＤＦ（Contents Delivery Function）のような、アップストリームコンテンツ配信ノードとのシグナリングセッションを形成する。本実施形態では、シグナリングセッションはＳＩＰ（Session Initialization Protocol）を採用するが、この出願の請求の範囲だけによって定義される本発明の範囲から逸脱することなく、ＳＩＰに代えて他のシグナリングプロトコルが採用され、他のプロトコルの追加のシグナリングコンポーネントが用いられうることは、当業者には理解されるであろう。ＳＩＰシグナリングセッションは、ＯＩＴＦとアップストリームコンテンツ配信ノードとの間の制御チャネルを生成するのに用いられる。２つのシグナリングセッションの間にあることで、ＩＰＴＶ ＣＳは、「中間者（man-in-the-middle）」の役割を果たすことが可能であり、これらのノードの間で中継される情報を観察する。ＩＰＴＶ ＣＳは、このポジションを、コンテンツのソースと行き先とをユニークに特定してユーザセッションの特性を特定するセッション情報、および当業者には明らかであろう他のさまざまな情報のセットを生成するために用いうる。セッション情報は、一般的には、制御サーバによってサービスを提供される第１のＯＩＴＦから第２のＯＩＴＦへとセッションが転送される場合に用いられる。

２つのＩＰＴＶ制御サーバが要求される場合、第２のＩＰＴＶ制御サーバは第１の制御サーバによって生成されたセッション情報へのアクセスを有さないため、転送はより困難になる。２つの制御サーバは互いへの保障された関係を有さないため、第１のＩＰＴＶ ＣＳは、それを通してデータネットワークのどのＩＰＴＶ ＣＳにセッション情報を転送すべきかを特定するためのメカニズムを必ずしも有さない。異なるＩＰＴＶ ＣＳによってサポートされるセッションの転送を受信する場合、元のＩＰＴＶ ＣＳは、受信するＯＩＴＦまたはそれにサービスを提供する何らかのインフラストラクチャーノードの情報を必ずしも有さず、同様に、ＩＰＴＶ ＣＳはどこにセッション情報が転送されるかを認識しておらず、従って、そのような転送をするためのメカニズムは欠落している 同様に、転送を受信する端末も、それにサービスを提供するＩＰＴＶ ＣＳに似て、データネットワークのどのＩＰＴＶ ＣＳが関連するセッション情報を有するかを判定するメカニズムを有さない。２つの端末は同じＩＰＴＶ ＣＳによってサービスを提供されていないため端末は互いにどうやってアクセスするか認識しておらず、セッションの転送をイニシエートするために一方の端末が他方にコンタクトするようにすることは困難である。これらの問題、およびセッション転送に関するその他の問題は、以下で概説される方法のような方法を用いることによって対処されうる。その最も基本的な形態において本発明の方法が上記で概説した先行技術の問題のすべてには対処しないであろうことを当業者は理解するであろう セッション転送に関する先行技術のソリューションの不利な点の少なくとも１つを除去または軽減することを意図しているものである。

以下では、添付図面に従ってナンバリングされた個々の要素が参照されるであろう。以下の説明は、本質的に例示的なものと捉えられるべきであり、本発明の範囲を限定するように捉えられるべきではない。本発明の範囲は請求の範囲によって定義され、当業者には理解されるように、要素を均等な機能要素と置き換えることによって変更されうる、以下で説明される実装の詳細によって限定されるものと考えられるべきではない。

図１〜３は、まとめて、異なるＩＰＴＶ制御サーバによってサービスを提供される、または上記のように異なるＩＭＳ加入の下にある２つのＯＩＴＦ端末の間でセッションを転送する方法を示す。メッセージパッシング図によって概説される方法は単に本発明の方法の例示的な実施形態であり、本発明のステップの網羅的な列挙として扱われるべきではないことが理解されるであろう。このメッセージパッシング図のセットに概説される多くのステップは、本発明の範囲から逸脱することなく、同じ結果を達成するための他のステップと結合されうることを当業者は理解するであろう。

図１は、本発明の例示的な方法においてノード間で交換されるメッセージのフローを示す。この例において採用されるノードは、第１のオープンＩＰＴＶ端末機能（ＯＩＴＦ１）１００であり、データネットワークを通じてＡＳＭ（Authentication and Session Management node）１０２に接続される。このデータネットワークを通じて、ＯＩＴＦ１ １００は、ＩＰＴＶ制御サーバ、この場合は第１のＩＰＴＶ制御サーバ（ＩＰＴＶ ＣＳ１）１０４にも接続される。ＩＰＴＶ ＣＳ１ １０４からのアップストリームは、ＣＤＮＣ／ＣＣ（Content Delivery Network Controller/Cluster Controller）１０６およびコンテンツ配信機能（ＣＤＦ：content delivery function）１０８である。セッション転送の行き先は第１のＯＩＴＦ（ＯＩＴＦ２）１１４であり、第２のＩＰＴＶ制御サーバ（ＩＰＴＶ ＣＳ２）１１０によってサービスを提供される。図１に示されていないのは、ＯＩＴＦ２にサービスを提供する第２のＡＳＭである。

ステップ１１６において、ＯＩＴＦ１は、ＣＤＦ１０８からコンテンツを受信するためのオンデマンドセッションを生成する。このセッションの生成は、多かれ少なかれ、介在するノードのそれぞれを含むものとして当業者には理解されるであろう。セッションは、当業者には知られているであろうシグナリングセッションのセットによって制御した。シグナリングセッションは、ＩＰＴＶ ＣＳ１ １０４に影響しこのノードがセッションに関する情報（以下、セッション情報）を保持することを可能にする。ステップ１１６の間、ＩＰＴＶ ＣＳ１ １０４は、外部アクセス可能なアドレスをＯＩＴＦ１ １００に中継するであろう。このアドレス転送は、ユーザについてユニークであり、セッションのセットアップ時にユーザに割り振られ、セッションの持続時間の間ＩＰＴＶ ＣＳ１ １０４によって保持され、そしてその後は破棄されるＰＳＩ（public service identity）を含む多くの形をとりうる（ワイルドカードされたＰＳＩのアプリケーション）。従来のいくつかの実装では、ＯＩＴＦ１ １００がＩＰＴＶ ＣＳ１ １０４のアドレスに解決されるドメイン名だけを取得し、このドメイン名はデータネットワークの特定のサブセットの外部にあるノードによるアドレスを解決しないことを当業者は理解するであろう。ＩＰＴＶ ＣＳ１ １０４のアドレスは、後の処理において用いられるであろう。

図１〜３において示される方法において、ＯＩＴＦ１のユーザは、セッションがＯＩＴＦ２ １１４に転送されるべきことを決定し、ＯＩＴＦ１から処理をイニシエートする。このプッシュ処理をイニシエートするために、ＯＩＴＦ１ １００は、ＯＩＴＦ２のアドレスを取得するためのメカニズムを有さなければならない。これはステップ１１８でなされる。ＯＩＴＦ１ １００が一般的にはセッションが転送される端末のネットワークアドレスを認識していないことを当業者は理解するであろう。最初のセッションが転送された後、端末がユーザの定義した記述とともに行き先の端末アドレスを格納することは可能であるが、端末は静的なアドレスを有することを保証されていないため、このアプローチは成功を保証されない。ＳＩＰ（Session Initialization Protocol）ベースのシグナリングチャネルを採用するシステムにおいて、ＯＩＴＦ１ １００は、メッセージ１２０に示されるように、ユーザ名（ユーザ２として示される）に向けてＳＵＢＳＣＲＩＢＥメッセージを発行しうる。ＯＩＴＦ２ １１４に関連付けられたユーザ（ユーザ２）は、２００ ＯＫメッセージ１２２によってＳＵＢＳＣＲＩＢＥをアクノリッジしうる。ＳＵＢＳＣＲＩＢＥメッセージは、特定の端末ではなく、ユーザに向けたものであり、それゆえユーザが接続されているどのノードでも応答し、ユーザ２に関連付けられたノードのリストをＯＩＴＦ１に供給しうる。一般的には、ＳＵＢＳＣＲＩＢＥメッセージは、ユーザ２がサインインしているすべてのノードが通知を受けることを確実にするために、プレゼンスサーバ（図示せず）を通じてルーティングされうる。ＯＩＴＦ２ １１４は、次に、セッションが転送されるべき、ユーザ２に関連付けられた特定のノード（この場合はＯＩＴＦ２ １１４）を特定するＧＲＵＵ（Globally Routable User agent Universal resource indicator）を含むＮＯＴＩＦＹメッセージ１２４を発行しうる。この通知メッセージ１２４は、２００ ＯＫメッセージ１２６によってアクノリッジされる。処理は図２に続く。

図２に示されるように、ＡＳＭ１によってサービスを提供されるものとは別のネットワークセグメントにサービスを提供するＡＳＭ、ＡＳＭ２ １１２を加えて、同じネットワークノードが用いられる。単一のＡＳＭを採用することが可能であり、それは２つのＯＩＴＦが１つの物理ＩＰＴＶ ＣＳによってサービスを提供されるが異なる加入を有し、それらが単一のＡＳＭによってサービスを提供される場合にありうることを当業者は理解するであろう。ステップ１２８において、ユーザは、ステップ１１８においてアドレスが取得されたＯＩＴＦ２にセッションが転送されるべきことを決定する。転送の決定は、ＯＩＴＦ１ １００とＡＳＭ１ １０２との両方によって確立され実行されるルールに従ってなされる。

ステップ１３０において、セッション転送がイニシエートされ、ＯＩＴＦ１ １００はＩＰＴＶ ＣＳ１ １０４のアドレスをＯＩＴＦ２ １１４に中継する（例示的な一実施形態において、ＩＰＴＶ ＣＳ１ １０４のアドレスは、ＲＥＦＥＲのボディにおいて中継される）。例示的な一実施形態において、ＲＥＦＥＲメッセージ１３２は、ＯＩＴＦ１ １００からＡＳＭ１ １０２に送信される。ＲＥＦＥＲメッセージは、ＲＥＦＥＲメッセージをメッセージ１３６としてＡＳＭ２ １１２を介してＯＩＴＦ２ １１４に転送するＩＰＴＶ ＣＳ２を通じてＯＩＴＦ２ １１４へと中継される１３４。ＲＥＦＥＲメッセージは、好ましくは、転送されるセッションのＳＴＩ（session transfer information）、ＩＰＴＶ ＣＳ１の外部アクセス可能なアドレスおよびブックマーク情報（ＯＩＴＦ１ １００がセッションをブックマークした場合にＲＥＦＥＲのボディにおいて転送され、そうでなければ厳密には要求されない）、ならびに転送に関係するであろう他の情報を含む。この外部アクセス可能なアドレスは、数字のネットワークアドレス（ＩＰアドレスのような）または外部的に解決可能なドメイン名でありうる。ＩＰＴＶ ＣＳ２ １１０を通じてＲＥＦＥＲメッセージ１３４を中継することで、ＩＰＴＶ ＣＳ２ １１０は、ＯＩＴＦ２ １１４が来るべきセッション転送リクエストのためのセッションイニシエートリクエストを発行することを予測することが可能である。一連のＲＥＦＥＲメッセージに応じて、一連の２０２ ＯＫ（）メッセージがレスポンスで送信され、最初はそのセッション転送を実行することの認容を示すＯＩＴＦ２ １１４からＩＰＴＶ ＣＳ２ １１０への１３８で、次はＩＰＴＶ ＣＳ２ １１０からＡＳＭ１ １０２への１４０で、最後はＡＳＭ１ １０２からＯＩＴＦ１ １００への１４２である。２０２ ＯＫレスポンスは、ＲＥＦＥＲメッセージと同じシグナリングパスに続く。

処理のこの時点で、ＯＩＴＦ２ １１４は転送を認容し、ＩＮＶＩＴＥメッセージ１４４をＡＳＭ２ １１２に送信する。図２に示されるように、ＩＮＶＩＴＥメッセージはメッセージ１３６を通じて受信されたセッション転送情報と、コンテンツオンデマンドセッションのダウンストリーム終端としてＯＩＴＦ１ １００をＯＩＴＦ２ １１４で置き換える指示とを含む。ＡＳＭ２ １１２は、ＯＩＴＦ２ １１４の必要とされるすべての認証を実行し、認証が成功するとＩＮＶＩＴＥメッセージをメッセージ１４６としてＩＰＴＶ ＣＳ２ １１０に転送する。ＩＰＴＶ ＣＳ１ １０４とＩＰＴＶ ＣＳ２ １１０とは、いずれも端末ノードを含む交換のシグナリングパスに残っているため、それが図２に明示されないとしてもすべての交換についてステートフルであり続ける。而して、ＩＰＴＶ ＣＳ１ １０４は、ユーザがセッションを転送する権限を有さないと断定した場合には、ＲＥＦＥＲメッセージを拒絶しうる。かかる拒絶は、転送を終了させる。同様に、何らかの理由で転送が開始されるべきでないと判定された場合、ＩＰＴＶ ＣＳ１ １０４は、ＩＰＴＶ ＣＳ２ １１０にセッション情報を転送しないことを決定し、ＩＰＴＶ ＣＳ２ １１０もまた転送を抑制する。

先行技術におけるセッション転送の実装では、ＩＰＴＶ ＣＳ２ １１０がＩＰＴＶ ＣＳ１ １０４にコンタクト可能なメカニズムがないために、問題が生じていた。ＩＰＴＶ ＣＳ１ １０４にコンタクトしなければ、ＩＰＴＶ ＣＳ２ １１０は、ＯＩＴＦ２ １１４から取得されるセッション転送情報に依存せねばならず、転送を遂行する能力はなくセッションを複製することが可能なだけである。ＲＥＦＥＲメッセージ１３２、１３４、および１３６のカスケードにおいて、ＯＩＴＦ１ １００によって保持されるセッション識別情報、およびステップ１１６のコンテンツオンデマンドセッションのセットアップで提供されるＩＰＴＶ ＣＳ１ １０４のアドレスの両方が、ＯＩＴＦ２ １１４に提供される。ＩＮＶＩＴＥメッセージが１４４および１４６を通じてＩＰＴＶ ＣＳ２ １１０に送信される場合、それはＩＰＴＶ１ ＣＳ１ １０４のアドレスを含むセッション転送情報を含む。このことが、ＩＰＴＶ ＣＳ２ １１０がＩＰＴＶ ＣＳ１ １０４に直接コンタクトすることを可能にし、処理を単純にする。

ＲＥＦＥＲメッセージ１３４からＩＰＴＶ ＣＳ１ １０４へのアドレスを抽出し、ＩＮＶＩＴＥメッセージ１４６を受信して、ＩＰＴＶ ＣＳ２ １１０は、ＩＰＴＶ ＣＳ１ １０４にＳＩＰ ＩＮＦＯメッセージ１４８を送信する。メッセージ１４８は、ブックマークをリクエストし、それがＯＩＴＦ２ １１４によって受信されず、操作がセッション複製ではなくセッション転送である場合にはコンテンツオンデマンドセッションを保留することを要求する。

ステップ１５０において、ＩＰＴＶ ＣＳ１ １０４は、付加的に、ＣＤＮＣ／ＣＣ１０６およびＣＤＦ１０８（アップストリームコンテンツノード）とインタラクトしてセッションブックマークを生成する。このブックマーク情報は、他のセッション情報をとともに、ＳＩＰ ２００ ＯＫメッセージ１５２においてＩＰＴＶ ＣＳ２ １１０に返送される。メッセージ１５２は、ブックマーク情報が送信されないかどうかにかかわらず、ＳＩＰ ＩＮＦＯメッセージ１４８に応じて送信される ブックマーク情報は、ＩＰＴＶ ＣＳ２ １１０が、ＯＩＴＦ１ １００からセッション転送が開始した時点から、ＯＩＴＦ２ １１４でＣＯＤセッションを再開することを可能にする。

メッセージ１５４および１５６を用いて、ＩＰＴＶＣＳ１ １０４は、ＯＩＴＦ１ １００にＰＡＵＳＥコマンドを発行するよう指示する。本実施形態では、ＯＩＴＦ１ １００は、アップストリームデータノードとのメディアコントロールセッションを有する。ＩＰＴＶ ＣＳ１は、このセッションの参加者ではなく、それゆえＯＩＴＦ１ １００がメディアチャネルにＰＡＵＳＥを伝えるための指示を提供するのにシグナリング制御セッションに依存する。メッセージ１５４は、好ましくはＯＩＴＦ１ １００にメディアセッションを保留するよう指示するＳＩＰ ＵＰＤＡＴＥ（）メッセージである。このメッセージは、メッセージ１５６としてＯＩＴＦ１ １００にＵＰＤＡＴＥを中継するＡＳＭ １０２で終わる。ＯＩＴＦ１ １００は、次に、例えばＲＴＳＰ ＰＡＵＳＥメッセージ１６４を用いて、ＣＯＤセッションを一時停止する。セッションを一時停止する指示を受信すると、ＣＤＦ１０８は、リクエストを２００ ＯＫ １６６でアクノリッジする。

ＯＩＴＦ１ １００がステップ１６４および１６６でストリーミングセッションを一時停止するのに続いて、受信および指示を受けての動作をアクノリッジするために、ＯＩＴＦ１ １００は、ＩＰＴＶ ＣＳ１ １０４にアクノリッジメッセージを送信する。ＯＩＴＦ１ １００は、ＡＳＭ１ １０２へのＳＩＰ ２００ ＯＫメッセージ１５８を用い、これはＡＳＭ１ １０２からＩＰＴＶ ＣＳ１ １０４への２００ ＯＫ １６０として中継される。

ＣＯＤセッションがＯＩＴＦ１ １００によって一時停止されると、ＩＰＴＶ ＣＳ２ １１０はＣＯＤセッション初期化処理１６２を開始する。転送されたセッションの初期化が成功すると、ステップ１６８において、ＩＰＴＶ ＣＳ２ １１０はＩＰＴＶ ＣＳ１ １０４に元のセッションをティアダウンするように指示する。図３の例示的な実施形態において、この処理は、以前に送信されたセッション転送情報を用いてティアダウンすべきセッションを特定するＳＩＰ ＩＮＦＯメッセージ１７０の使用を通じてなされうる。ＩＰＴＶ ＣＳ１ １０４は、ティアダウン指示の受信を確認するためにＳＩＰ ２００ ＯＫメッセージ１７２で応答する。ステップ１７４において、ＯＩＴＦ１ １００およびＩＰＴＶ ＣＳ１ １０４は、それらのセッションをティアダウンする。なお、ＯＩＴＦ１ １００とのセッションをティアダウンする前に、ステップ１６２において転送されたセッションの初期化が成功すると、この好適な実施形態では、ＯＩＴＦ２がＳＩＰ ＮＯＴＩＦＹをＯＩＴＦ１に送信し、ステップ１６２においてセッション転送が成功裏に完了されたことを報告する。簡単のために、これは図示されていない。このメッセージは、ＯＩＴＦ１が進捗メッセージを表示することを可能にするため、ユーザは転送の進捗を知ることができる。

図１〜３は、ＯＩＴＦ１ １００によってイニシエートされるセッション転送のための例示的なデータフローを示す。これは、セッションがＯＩＴＦ１ １００からＯＩＴＦ２ １１４へとプッシュされるプッシュ転送の例である。図４は、ＯＩＴＦ２がセッションをＯＩＴＦ１ １００からプルし、セッション転送イニシエータとして動作する代替的な実施形態を示す。

上述の例のように、ステップ１１６において、ＯＩＴＦ１ １００は、ＣＯＤセッションを初期化した。セッションセットアップ１１６の間に（または当業者には明らかであろう他の時点で）、ＯＩＴＦ１ １００は、ステップ１１６において初期化されたＣＯＤセッションに関連付けられたＩＰＴＶ ＣＳであるＩＰＴＶ ＣＳ１ １０４の外部的に解決可能なアドレスを取得する。ステップ１７６において、ＯＩＴＦ２ １１４は、ＯＩＴＦ１ １００からセッション情報をプルする。ステップ１７６におけるセッション情報のプルの後は、処理が、ＯＩＴＦ２ １１４からＡＳＭ２ １１２に送信されるメッセージ１４４に始まる図１〜３で概説されたのと同じステップに従いうることを、当業者は理解するであろう。プッシュモードと同様に、ＩＰＴＶ ＣＳ１ １０４およびＩＰＴＶ ＣＳ２ １１０は、セッション転送の間のすべてのシグナリング交換のシグナリングパスの中にある。それゆえに、ＯＩＴＦ１ １００がセッションの転送の権限を有していなければ、ステップ１７８のＳＵＢＳＣＲＩＢＥはＯＩＴＦ１ １００には届かない。それはシグナリングパスにあるＩＰＴＶ ＣＳ１ １０４によって拒絶される。

図４の概略的な例において、ステップ１７６は、ＯＩＴＦ１ １００へのＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージ１７８を発行するＯＩＴＦ２によって実行されうる。このｓｕｂｓｃｒｉｂｅメッセージ１７８は、ステップ１１６においてＣｏＤセッションのためにユーザ１によって用いられたセッションを特定する情報を引き出す。ＯＩＴＦ１ １００は、２００ ＯＫ１８０によってＳＵＢＳＣＲＩＢＥ１７８に答える。続いて、ＯＩＴＦ１ １００は、セッション情報およびＩＰＴＶ ＣＳ１ １０４の外部的に解決可能なアドレスを含むＮＯＴＩＦＹメッセージ１８２を発行する。ＯＩＴＦ２ １１４は、２００ ＯＫメッセージ１８４によってＮＯＴＩＦＹメッセージ１８２に返答し、この情報の受信を確認する。

上記で説明され、図１〜４に示されるように、確立されたＩＰＴＶベースのセッションの第１のＯＩＴＦから第２のＯＩＴＦへの転送は、それぞれのＯＩＴＦが異なるＩＰＴＶ ＣＳに接続される場合、所定の役割を果たし特定のステップを実行する、転送に関連するそれぞれのノードに影響する。以下の図５〜８のフローチャートの説明は、プッシュおよびプルの両方のモデルに共通のステップを示す。

ＯＩＴＦ１は、元の端末、つまり転送されるべきコンテンツを受信している端末である。ＯＩＴＦ２は、ターゲット端末、つまりセッションが転送される先の端末である。図５は、転送時にＯＩＴＦ１で実行される方法を示す。ステップ１９０において、ＯＩＴＦ１は、サービスを提供しているＩＰＴＶ ＣＳのアドレスを受信する。現在の例では、サービスを提供しているＩＰＴＶ ＣＳは、ＩＰＴＶ ＣＳ１である。このアドレス情報は、一般的にはＣｏＤセッションセットアップ処理の中でＯＩＴＦ１に提供される。ＩＰＴＶ ＣＳ１のアドレスは、外部的にアクセス可能であり、解決可能であり、そのユーザについてユニークである。一般的に、ＩＰＴＶ ＣＳのアドレスは、ＩＰＴＶ ＣＳがサービスを提供するＩＭＳネットワークの外にあるノードにとってはアクセス可能ではなかった。このことが、ＩＰＴＶ ＣＳが外部ノードからアクセスされることを防いである種のセキュリティを提供する一方、当座のＩＭＳネットワークの外にあるノードへの接続が可能であることによって達成されうる機能性を制約している。ステップ１９２において、ＯＩＴＦ１は、（ステップ１９０において）受信したＩＰＴＶ ＣＳ１のネットワークアドレスを、ターゲットノードに送信する。ステップ１９２は、一般的にはセッション転送初期化フェーズで実行される。プッシュ転送では、ＯＩＴＦ２を発見して接続するための探索オペレーションを実行するＯＩＴＦ１に先行されることを当業者は理解するであろう。ステップ１９２におけるアドレスの送信は、また、セッション転送を始めるために指示に取り込まれていてもよい。プル転送の場合、ステップ１９２は、図４において概説されたように、ターゲットＯＩＴＦによる転送されるセッションの詳細のプルによって達成されてもよい。

図６は、ターゲット端末ＯＩＴＦ２で実行される方法を示す。ステップ１９４において、ＯＩＴＦ２は、ステップ１９２においてＯＩＴＦ１によって送信されたネットワークアドレスを受信する。ステップ１９６において、セッション転送を開始する指示がＩＰＴＶ ＣＳ２を通じて発行される。これらの指示は、一般的には受信されたＩＰＴＶ ＣＳ１アドレスを含み、ＩＰＴＶ ＣＳ２がＩＰＴＶ ＣＳ１に直接接続して転送をネゴシエートすることを可能にする。ステップ１９８において、ＩＰＴＶ ＣＳ１とＩＰＴＶ ＣＳ２との間で転送がネゴシエートされた後、ＯＩＴＦ２は、セッション転送情報に従ってコンテンツオンデマンドセッションをイニシエートする。図５の説明と同様に、図６において概説されるステップはプッシュおよびプルの実施形態に共通である。プッシュシナリオでは、ＩＰＴＶ ＣＳ１アドレスは、転送をイニシエートする用いられるセッション転送情報とともにステップ１９４で受信される。プルシナリオでは、ステップ１９４は、ＯＩＴＦ２がセッション転送情報を特定することを可能にする探索プロセスの中で明示的に実行される。

図７は、セッションの転送を遂行するためにソースＩＰＴＶ ＣＳで実行される方法を示す。ステップ２００において、ＩＰＴＶ ＣＳは、転送されるセッションに関するリクエストを受信する。リクエストは、行き先ＩＰＴＶ ＣＳを通じてルーティングされるが、ターゲットノードを始点としている。ステップ２０２において、ソースＩＰＴＶ ＣＳは、付加的に、セッションをブックマークし、ブックマークをセッションに関するセッション転送情報に含める。ステップ２００で受信されたリクエストに応じて、ＩＰＴＶ ＣＳは、ステップ２０４で、欠落した（missing）セッション転送情報（ブックマークのような）を送信する。この情報は、一般的にはターゲット端末へと送信されるが、転送リクエストが行き先のＩＰＴＶ ＣＳのアドレスを含んでいればセッション転送情報は行き先のＩＰＴＶ ＣＳに直接に送信されうる。ステップ２０６において、ＩＰＴＶ ＣＳは、転送されるセッションを一時停止することをセッションオーナーにリクエストする指示を発行する。

図８は、行き先のＩＰＴＶ ＣＳ（ＩＰＴＶ ＣＳ２）で実行されうる本発明の例示的な実施形態の方法を示す。ステップ２０８において、ＩＰＴＶ ＣＳ２は、セッション転送を開始する指示をターゲットから受信する。ステップ２１０において、ＩＰＴＶ ＣＳ２は、ＩＰＴＶ ＣＳ１に、転送されるべきセッションで動作するように指示し、付加的にこの指示にセッションのブックマークのリクエストを含める。ステップ２１２において、ソースＩＰＴＶ ＣＳからのアクノリッジが受信される。このアクノリッジは、ブックマークを含んでいてもよい。ステップ２１４において、セッション転送情報は、アップストリームコンテンツノードとターゲット端末との間のコンテンツオンデマンドセッションをイニシエートするのに用いられる。

図９は、論理ノードを用いる本発明のＩＰＴＶ ＣＳおよびの例示的な実施形態を示すブロック図を提供する。ＩＰＴＶ ＣＳ２２０は、それを通じてサービスを提供されるＯＩＴＦへの接続が作成されるＩＭＳネットワークへの接続に用いられるダウンストリームインターフェース２２２を含む。これはＯＩＴＦインターフェースとして説明されているが、ＯＩＴＦへの接続は直接でなくてもよく、代わりにＩＭＳネットワークを通じた間接的な接続が一般的に採用されることが理解されるであろう。インターフェース２２２を通じて、セッション初期化情報、ＩＰＴＶ ＣＳアドレス情報、およびセッション制御情報が、ＯＩＴＦと間で交換される。コンテンツ配信ネットワークへのアップストリームインターフェース２２４は、ＩＰＴＶ ＣＳがＣＤＮＤ／ＣＣおよびＣＤＦのようなノードに接続することを可能にする。このインターフェースを通じて、ＩＰＴＶ ＣＳ２２０は、アップストリームノードからセッションについての情報（セッションを識別する情報、コンテンツ配信に関わるアップストリームノード、およびセッションの転送に関係すると当業者が理解するであろう他の情報を含む）を取得することが可能である。図９においてこれはセッション情報として示され、ＯＩＴＦインターフェース２２２を通じてＯＩＴＦから取得された情報と合わせて、このセッション情報は、セッションが別のＩＰＴＶ ＣＳに転送されるときに送信されるセッション転送情報を生成するのに用いられる。ＩＰＴＶ ＣＳインターフェース２２６は、他のＩＰＴＶ ＣＳノードへの接続を可能にする。ＩＰＴＶ ＣＳインターフェース２２６は、それを通じて別のＩＰＴＶ ＣＳとの間でセッション転送情報が交換され、転送の指示もまた交換される、論理的な接続ポイントである。上記のように、セッション転送情報は、インターフェース２２４を通じてアップストリームノードから受信されたセッション情報、インターフェース２２２を通じてＯＩＴＦから受信された情報の組み合わせであり、プロセッサ２２８がアクセス可能な他の情報をも含みうる。ＩＰＴＶ ＣＳインターフェース２２６からのこれらのデータフローは、ＩＰＴＶ ＣＳ２２０がセッション転送のソースおよび行き先の両方でありうるために双方向になっている。プロセッサ２２８は、インターフェース２２２、２２４、および２２６の動作を制御する。上記のように、プロセッサ２２８は、ＯＩＴＦインターフェース２２２およびコンテンツ配信ネットワークインターフェース２２４によって交換されたセッション情報に従って、セッションのためのセッション転送情報（ＳＴＩ：session transfer information）を組み立て、このＳＴＩをセッション情報データベース２３０に格納する。セッションを送信転送するリクエストが、ＩＰＴＶ ＣＳインターフェース２２６を通して受信されると、プロセッサ２３０は、データベース２３０に格納された関連するＳＴＩをアップデートし、このＳＴＩをＩＰＴＶ ＣＳインターフェース２２６を通じて送信して元のＯＩＴＦに一時停止を指示し、最終的にはダウンストリームインターフェース２２２を通してセッションをティアダウンする。プロセッサ２２８がセッションを受信転送するリクエストを受信する場合、それは一般的にはダウンストリームインターフェース２２２を通じてＯＩＴＦから受信され、セッション転送リクエストがＩＰＴＶ ＣＳインターフェース２２６を通じて発行される。プロセッサ２２８は、また、ダウンストリームインターフェース２２２およびアップストリームインターフェース２２４の両方を用いて、ＯＩＴＦとアップストリームコンテンツノードとの間のセッションの確立を支援する。

実装では、すべてのインターフェース２２２、２２４、および２２６が単一のネットワークインターフェースによって提供されうることを、当業者は理解するであろう。それらは、説明を明りょうにするために、上記の例では別々の要素として示されている。

初期化においてＯＩＴＦに外部的にアクセス可能なアドレスを提供することで、ＩＰＴＶ ＣＳは、他のＩＰＴＶ ＣＳが直接接続し、そしてセッション転送情報が交換されることを可能にする。先行技術のソリューションとは対照的に、異なるＩＭＳネットワーク上にあり異なるＯＩＴＦにサービスを提供する２つのＩＰＴＶ ＣＳの間の直接通信が、２つのＯＩＴＦにすべての通信において通過点となる（serve as waypoints）ことを要求することなくセッション情報が正しく複製されることを可能にする橋渡しが形成されることを許容する。このことは、転送プロセスを簡単にし、信頼性および転送のスピードを増加させる。これはＩＰＴＶ ＣＳがネットワーク上のより広い範囲のデバイス群にとってアクセス可能であることを要求するが、当業者には理解されるであろうように適切に管理され保護されれば、サーバの安全性および安定性に直接的な影響はないであろう。

本発明の実施形態は、機械読み取り可能な媒体（コンピュータ読み取り可能な媒体、プロセッサ読み取り可能な媒体、またはコンピュータ読み取り可能なコードが収録されたコンピュータ利用可能な媒体としても言及される）に格納されるソフトウェアプロダクトとしても具現されうる。機械読み取り可能な媒体は、フレキシブルディスク、ＣＤ−ＲＯＭ（compact disk read only memory）、ＤＶＤ−ＲＯＭ（digital versatile disc read only memory）メモリデバイス（揮発性または不揮発性）、または同様の記憶機構を含む磁気、光学、または電子記憶媒体を含む適切ないかなる有形の媒体でもありうる。機械読み取り可能な媒体は、実行されるとプロセッサに本発明の実施形態に係る方法におけるステップを実行させる、さまざまな命令のセット、コードシーケンス、設定情報、または他のデータを含む。記述された発明を実装するために必要な他の指示およびオペレーションもまた機械読み取り可能な媒体に格納されうることを、当業者は理解するであろう。機械読み取り可能な媒体から起動するソフトウェアは、記述されたタスクを実行するために回路構成と連動する。

上述の本発明の実施形態は、例にすぎないことを意図されている。代替、変更、および変形が、当業者によって、ここに添付する請求の範囲だけによって定義される本発明の範囲から逸脱しない範囲で、詳細な実施形態にもたらされうる。

Claims (23)

1. ネットワークアドレスを有する、インターネットプロトコルテレビジョン（ＩＰＴＶ）制御サーバであって、
   ＩＰＴＶ端末である第１の端末とのセッションを初期化し、前記セッションの初期化の間に前記ネットワークアドレスを前記第１の端末に送信するダウンストリームインターフェースと、
   前記第１の端末とコンテンツプロバイダとの間のセッションを初期化し、前記第１の端末とコンテンツプロバイダとのセッションについての状態情報を受信するアップストリームインターフェース、
   予めは前記セッションに関連付けられない、前記第１の端末と異なる第２の端末に接続される別の制御サーバと通信する制御サーバインターフェースと、
   セッション転送のために前記制御サーバインターフェースを通して受信される前記別の制御サーバからのリクエストに応じて前記アップストリームインターフェースを通じて前記状態情報をリクエストし、前記セッション転送のために前記リクエストに応じて前記別の制御サーバに状態情報を提供するプロセッサと
   を備え、
   前記制御サーバ及び前記別の制御サーバは、ＳＵＢＳＣＲＩＢＥ−ＮＯＴＩＦＹ手続を通じて識別される、
   制御サーバ。
2. 前記ダウンストリームインターフェースは、中間ノードを通じて前記第１の端末と通信する、請求項１に記載の制御サーバ。
3. 前記ＩＰＴＶ端末は、オープンＩＰＴＶ端末機能である、請求項１に記載の制御サーバ。
4. 前記ダウンストリームインターフェース、前記アップストリームインターフェース、および前記制御サーバインターフェースは、共通のネットワークインターフェースに統合されている、請求項１に記載の制御サーバ。
5. 前記プロセッサは、前記セッションに関するブックマーク情報を生成し、該ブックマーク情報は前記セッションにおける前記第１の端末の位置を識別する、請求項１に記載の制御サーバ。
6. 前記ブックマーク情報は、前記別の制御サーバに提供されるセッション転送情報の一部である、請求項５に記載の制御サーバ。
7. 前記生成されたブックマーク情報を格納するデータベースをさらに含む、請求項５に記載の制御サーバ。
8. 前記プロセッサは、前記制御サーバインターフェースを通じてセッション転送のリクエストを発行する、請求項１に記載の制御サーバ。
9. 前記プロセッサは、前記リクエストに応じて前記制御サーバインターフェースを通じてセッション転送情報を受信し、前記受信されたセッション転送情報において特定されるパラメータに従って前記第１の端末と前記セッション転送情報によって特定されるコンテンツソースとの間のセッションをイニシエートする、請求項８に記載の制御サーバ。
10. 受信されたセッション転送情報を格納するデータベースをさらに含む、請求項９に記載の制御サーバ。
11. インターネットプロトコルテレビジョン（ＩＰＴＶ）制御サーバによって管理されるセッションを転送する方法であって、該セッションはコンテンツソースとＩＰＴＶ端末である第１の端末との間で初期化され、
    前記ＩＰＴＶ制御サーバにおいて、予めは前記セッションに関連付けられない、前記第１の端末と異なる第２の端末に接続される別のＩＰＴＶ制御サーバから、前記セッションの転送管理のリクエストを受信することと、
    前記受信されたリクエストに応じて前記別のＩＰＴＶ制御サーバに前記セッションに関するセッション転送情報を送信することと、
    を含み、
    前記制御サーバ及び前記別の制御サーバは、ＳＵＢＳＣＲＩＢＥ−ＮＯＴＩＦＹ手続を通じて識別される、
    方法。
12. 前記第１の端末が前記セッションを一時停止することをリクエストするステップをさらに含む、請求項１１に記載の方法。
13. 前記リクエストするステップは、前記送信するステップの後に続く、請求項１２に記載の方法。
14. 前記セッションのためのブックマークを生成するステップをさらに含み、該ブックマークはセッションプレイバック処理での前記第１の端末の現在位置を記録する、請求項１１に記載の方法。
15. 前記ブックマークは、前記別のＩＰＴＶ制御サーバに送信されるセッション転送情報に含まれる、請求項１４に記載の方法。
16. 前記セッション転送情報は、前記セッションに関するコンテンツ配信ノードを特定する情報を含む、請求項１１に記載の方法。
17. 前記セッション転送情報の送信後に前記セッションをティアダウンすることをリクエストするステップをさらに含む、請求項１１に記載の方法。
18. 第１のインターネットプロトコルテレビジョン（ＩＰＴＶ）制御サーバによって管理されるセッションを第２のＩＰＴＶ制御サーバに転送する方法であって、該セッションはコンテンツソースとＩＰＴＶ端末である第１の端末との間で初期化され、
    前記第２のＩＰＴＶ制御サーバは、前記第１の端末と異なる第２の端末に接続され、
    前記第２のＩＰＴＶ制御サーバにおいて、前記第１のＩＰＴＶ制御サーバからの前記セッションの転送を開始する前記第２の端末からの指示を受信し、該セッションは予めは前記第２のＩＰＴＶ制御サーバに関連付けられず、当該指示は前記第１のＩＰＴＶ制御サーバに関連付けられたネットワークアドレスを含むことと、
    前記セッションの管理制御を転送するリクエストを前記第１のＩＰＴＶ制御サーバに送信することと、
    前記送信されたリクエストに応じてセッションに関するセッション転送情報を受信することと、
    前記転送を開始する指示がそこから受信された前記第２の端末と前記セッション転送情報において特定されるコンテンツソースとの間のセッションをイニシエートすることと、
    を含み、
    前記第１のＩＰＴＶ制御サーバ及び前記第２のＩＰＴＶ制御サーバは、ＳＵＢＳＣＲＩＢＥ−ＮＯＴＩＦＹ手続を通じて識別される、
    方法。
19. 前記転送を開始する指示がそこから受信された前記第２の端末が、転送される前記セッションに参加する前記第１の端末と異なる、請求項１８に記載の方法。
20. 前記転送をリクエストする指示は、転送される前記セッションに関するセッション転送情報を含む、請求項１８に記載の方法。
21. 前記セッション転送情報は、ブックマークを含む、請求項２０に記載の方法。
22. 前記リクエストを送信するステップは、ブックマーク情報のリクエストを送信することを含む、請求項１８に記載の方法。
23. 前記受信されたセッション転送情報は、前記リクエストされたブックマーク情報を含む、請求項２２に記載の方法。

Images