(57)【特許請求の範囲】
【請求項１】
ＩＭＳセッション及び対応するメディア配信を複製するための方法であって、プロセッサ、メモリ及び通信インタフェースを含む第１のノードにおいて、
第１の端末と確立されたＩＭＳセッションと関連づけられた第１のリソース予約に従って、前記メディアを第１の端末へ送信することと、
前記ＩＭＳセッションを転送又はコピーするためのリクエストを受信することと、
前記リクエストを受信した後に、前記第１の端末と関連づけられた第２の端末に前記ＩＭＳセッションが転送又はコピーされることを決定することと、
前記ＩＭＳセッションが転送又はコピーされることを決定した後に、前記第２の端末とのＩＭＳセッションを確立することと関連づけられたリソース予約プロセスをＩＭＳネットワークがバイパスできることを示すセッション転送インジケータ及びコピーインジケータのうちの１つのインジケータをＩＭＳネットワークへ送信することと、
を含み、
前記１つのインジケータを送信するステップは、
前記第１の端末について前記メディアの配信を保留するためのリクエストを送信することによって前記１つのインジケータを暗示的に送信し、続いて前記第２の端末との前記ＩＭＳセッションをセットアップすること
を含み、
前記方法は、プロセッサ、メモリ及び通信インタフェースを含む第２のノードにおいて、
前記メディアを保留するための前記リクエストを受信することと、
前記リクエストと関連づけられたセッション転送識別子が、前記セッション転送識別子を含むセッションの状態とマッチするかを判定することと、
前記セッション転送識別子が前記状態とマッチする場合には、前記リクエストと関連づけられたアクセスポイントに前記セッションが属するかを判定することと、
前記セッションが前記アクセスポイントに属する場合には、前記リソース予約をバイパスすることと、
をさらに含む、方法。
【請求項２】
前記第２の端末は、前記第１の端末と同一である、請求項１に記載の方法。
【請求項３】
前記第２の端末は、前記第１の端末と異なる、請求項１に記載の方法。
【請求項４】
前記第１の端末及び前記第２の端末は、同一のアクセスデバイスの後ろに配置されることによって互いに関連づけられている、請求項１に記載の方法。
【請求項５】
前記メディアを一時停止するためのリクエストを受信すること、
をさらに含む、請求項１に記載の方法。
【請求項６】
前記メディアを前記第２の端末へ送信すること、
をさらに含む、請求項１に記載の方法。
【請求項７】
システムであって、
第１のリソース予約を有するＩＭＳセッションと関連づけられたメディアを受信し、第１の端末へ転送するプロセッサと、
前記ＩＭＳセッションを転送又はコピーするためのリクエストを受信するインタフェースと、
を含む第１のノード
を含み、
前記プロセッサは、前記リクエストの受信後に、前記第１の端末と関連づけられた第２の端末に前記ＩＭＳセッションが転送又はコピーされることを決定し、前記第２の端末とのＩＭＳセッションを確立することと関連づけられたリソース予約プロセスをＩＭＳネットワークがバイパスできることを示すセッション転送インジケータ及びコピーインジケータのうちの１つのインジケータをＩＭＳネットワークへ送信し、
前記プロセッサは、前記第１の端末について前記メディアを保留するためのリクエストを送信することによって、前記１つのインジケータを暗示的に送信し、続いて前記第２の端末との前記ＩＭＳセッションをセットアップし、
前記システムは、
前記メディアを保留するための前記リクエストを受信するプロセッサと、
継続中のＩＭＳセッションの状態を格納するメモリデバイスと、
を含む第２のノード
をさらに含み、
前記第２のノードのプロセッサは、前記リクエストと関連づけられたセッション転送識別子が、前記メモリデバイスに格納された、前記セッション転送識別子を含むセッションの状態とマッチし、前記リクエストと関連付けられたアクセスポイントに前記セッションが属するか、を判定し、前記セッション転送識別子が前記状態とマッチし、且つ前記セッションが前記アクセスポイントに属する場合には、前記ＩＭＳセッションのための前記リソース予約をバイパスする、
システム。
【請求項８】
前記第２の端末は、前記第１の端末と同一である、請求項７に記載のシステム。
【請求項９】
前記第２の端末は、前記第１の端末と異なる、請求項７に記載のシステム。
【請求項１０】
前記第１の端末及び前記第２の端末は、同じアクセスデバイスの後ろに配置されることによって、互いに関連づけられている、請求項７に記載のシステム。
【請求項１１】
前記第１のノードの前記インタフェースは、前記メディアを一時停止するためのリクエストを受信する、請求項７に記載のシステム。
【請求項１２】
前記第１のノードの前記プロセッサは、前記メディアを受信し、前記第２の端末に転送する、請求項７に記載のシステム。
【請求項１３】
前記第１のノードは、ＩＭＳゲートウェイであり、前記第２のノードは、プロキシコールセッションコントロールファンクション（Ｐ−ＣＳＣＦ）である、請求項７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願書類は、一般的に、同一の又は異なるエンドユーザ端末装置上でマルチメディアセッションを再開、転送、又はコピーするための方法及びシステムに関する。
【背景技術】
【０００２】
ＩＰテレビジョン（ＩＰＴＶ）に基づくインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）は、現在ＩＭＳネットワークのサービスレイヤに導入されている新たなサービスである。ＩＭＳ仕様“３ＧＰＰ  ＴＳ  ２３．２２８  ｖ７．４．０（２００６−０６）’第三世代パートナーシッププロジェクト；技術仕様グループサービス及びシステム面；ＩＰマルチメディアサブシステム（ＩＭＳ）ステージ２（リリース７）”は、ＩＭＳコアネットワークのためのサービス記述を提供している。ＩＭＳコアネットワークは、ＩＰマルチメディアサービスをサポートするために必要な要素を順に含んでいる。もうひとつのＩＭＳ仕様“３ＧＰＰ  ＴＳ  ３３．２０３  ｖ７．２．０（２００６−０６）’第三世代パートナーシッププロジェクト；技術仕様グループサービス及びシステム面；３Ｇセキュリティ；ＩＰベースサービスのためのアクセスセキュリティ（リリース７）”は、ＩＰＴＶのようなマルチメディアサービスを得るために端末から受信されるリクエストの有効性を確認するために有用な認証メカニズムを提供する。
【０００３】
図１は、ＩＰＴＶ及び他のマルチメディアアプリケーションをサポートするための典型的なＩＭＳネットワークアーキテクチャの高レベルビューを示している。エンドユーザがＩＰＴＶ及び他のマルチメディアコンテンツを楽しむために用いることができる第１の端末１１０及び第２の端末１２０を含むサービスネットワーク１００が示されている。コンテンツは、コンテンツサーバ１３０によって端末１１０，１２０に提供される。コンテンツサーバ１３０は、情報のアグリゲータとして機能し、ビデオ、オーディオ、ゲーム、写真、テキストなどを有することができる。これらの異なるタイプのメディアは、一般的にコンテンツサーバ１３０のハードドライブに記憶される。サービスネットワーク１００中において、コンテンツは、コンテンツサーバ１３０によってリアルタイムストリーミングプロトコル（ＲＴＳＰ）メディアフロー１４０を用いて送信される。ＳＩＰがセッションセットアップのために用いられている間、ＲＴＳＰは、メディア操作及び制御のためにこの一例としてのアーキテクチャで使用される。ＲＴＳＰは、”リクエストフォーコメンツ（ＲＦＣ）２３２６'リアルタイムストリーミングプロトコル（ＲＴＳＰ）’１９９８年4月”中のインターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって定義されている。マルチメディアセッションは、アプリケーションサーバ１５０を使用することにより、端末１１０、１２０及びコンテンツサーバ１３０間でセットアップされる。アプリケーションサーバ（ＡＳ）１５０は、端末１１０，１２０及びコンテンツサーバ１３０間のセッションのセットアップを制御するソフトウェア機能を実行する。例えば、ＡＳ１５０は、ＲＴＳＰセッションのセットアップのための適切なＲＴＳＰメッセージにＳＩＰをマッピングする。さらにとりわけ、ＡＳ１５０は、ユーザの認証、セッションの序列（ｂｉｌｌｉｎｇ）、いくつかのコンテンツサーバ１３０のうちの１つのパフォーマンスパラメータに基づいた選択、などを処理してもよい。セッションのセットアップは、シグナリングリンク１６０上で交換されるＳＩＰメッセージを用いて行われる。ＩＥＴＦは、ＳＩＰメッセージを”ＲＦＣ３２６１‘ＳＩＰ：セッションイニシエーションプロトコル’，２００２年６月”中において定義している。
【０００４】
図１に示される、システムの予想される１つの使用状況は、１つの端末から他の端末へのマルチメディアセッションの転送が含まれる。例えば、ユーザがビデオオンデマンド（ＶＯＤ）プログラムを端末１１０上で彼又は彼女のリビングルームで視聴していて、食事の準備をするためにキッチンへ移動し、同じＶＯＤプログラムを端末１２０上で視聴し続けたい場合を考えてみよう。その場合には、ＶＯＤプログラムをサーバ側で一時停止し、ユーザがＶＯＤプログラムを一時停止した時点において再開できるマルチメディアセッションを端末１２０上で提供するための仕組みを有することが望ましい。
【０００５】
このような状況に対処するための１つの解決策は、米国特許出願公開Ｎｏ．２００８／００８４８６７に記載されている。この開示を参照することによって本明細書に組み込まれる。そこで図２（ここで複製される）中には、第１の端末１１０から第２の端末１２０へセッションを転送するための方法を描くシーケンス図が描かれる。この一例としてのシーケンス図中において、セッションは、サービスネットワーク１００によって第１の端末１１０及びコンテンツサーバ１３０中のコンテンツサービングファンクション（ＣＳＦ）１３２間でセットアップされる。セッションのセットアップのとき、セッション識別子が第１の端末１１０中に格納される。
【０００６】
上述の通り、ＶＯＤプログラム（又はいくつかの他のコンテンツ）がＣＳＦ１３２から第１の端末１１０へステップ２００において転送され、そしてエンドユーザはそのセッションを第２の端末１２０に転送したいと仮定しよう。ステップ２０２において、ユーザ入力に応じて第１の端末１１０は一時停止メッセージをＣＳＦ１３２に向かって送信する。一時停止メッセージは、セッション識別子を含むことが望ましいだろう。ＣＳＦ１３２は、ステップ２０４において、同一のユーザについて現在１以上のセッションがアクティブであるときに明確に１つのセッションを一時停止するためにセッション識別子を用いてメディアストリームの送信を一時停止する。第１の端末はそしてステップ２０６において、現在一時停止されているセッションのセッションＩＤを含むコリレーションメッセージをＡＳＦ１５２に対して送信する。ステップ２０８において、ＡＳＦ１５２は、もしＡＳＦ１５２に既に知られていないときセッションＩＤを格納する。そして、セッションは、インアクティブにセットされたセッションステータスを格納することによって現在一時停止されていることに留意する。同一のユーザについて現在１以上のセッションがアクティブであるとき、コリレーションメッセージ中で受信されるセッションＩＤはＡＳＦ１５２によって一時停止されるセッションを明確に示すために用いられる。
【０００７】
その後、ユーザからの入力に応じて、第２の端末１２０は、ＡＳＦ１５２に対してステップ２１０においてコンテキストリクエストメッセージを送信する。ＡＳＦ１５２はステップ２１２において、１又は２以上のセッションＩＤを含むコンテキストレスポンスメッセージを第２の端末１２０に対して送信することによって応答する。ステップ２１０において、ＡＳＦ１５２は、第１及び第２の端末１２０のユーザのための１又は複数のセッションと対応するセッションＩＤを有することができる。それぞれのセッションは、ステップ２０２−２０８に示した方法と似た方法によって一時停止されている。そのような場合において、ステップ２１２において送信されるコンテキストレスポンスメッセージは、ユーザと関係する全てのセッションについてのセッションＩＤを含んでもよい。ステップ２１４において、ユーザは、必要に応じて一時停止されたセッションを再開することを第２の端末１２０から選択することができる。このステップは、ユーザが再開する１又は複数のセッションをコンテキストレスポンスメッセージ中に受信されるセッション情報に基づいて選択することを含んでもよい。ステップ２１６において、第２の端末は、再開メッセージをＣＳＦ１３２に対して送信する。再開メッセージは、ユーザによって選択された又は第２の端末１２０によって自動的に選択された１又は複数のセッションについてのＲＴＳＰセッションＩＤを含む。ステップ２１８において、ＣＳＦ１３２は、第２の端末１２０に対するコンテンツの送信を再開する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】米国特許第２００８／００８４８６７号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００９】
この米国特許出願公開において記述される解決策に加えて、マルチメディアセッションをＩＭＳゲートウェイに接続された、或いはＩＭＳソフトウェアスタックを有する端末間で送信すること、又は上記端末においてマルチメディアセッションを再開することがさらにできることが望ましい。
【課題を解決するための手段】
【００１０】
一実施形態によれば、ＩＭＳセッションと対応するメディア配信を再開する方法は、メディアを第１の端末に対して送信することと、再開のリクエストを受信することと、ＩＭＳセッションを転送又はコピーすることと、ＩＭＳセッションが再開され、又は第１の端末と関連づけられた第２の端末に転送若しくはコピーされることを、決定することと、セッション転送インジケータとコピーインジケータとのいずれか１つのインジケータをＩＭＳネットワークに対して送信することと、を含む。
【００１１】
別の一実施形態によれば、システムは、第１のノードを含む。当該第１のノードは、ＩＭＳセッションと関連づけられたメディアを受信し、第１の端末に対して転送するためのプロセッサと、再開のリクエストを受信し、ＩＭＳセッションを転送又はコピーするためのインタフェースとを含む。上記プロセッサは、ＩＭＳセッションが再開され、又は上記第１の端末と関連づけられた第２の端末に転送若しくは又はコピーされることを決定し、セッション転送インジケータ及びコピーインジケータのうちの１つであるインジケータをＩＭＳネットワークへ送信する。
【００１２】
また別の一実施形態によれば、メディアセッションを複製する方法は、メディアセッションと関連づけられた、第１のセッション識別子、コンテンツ識別子、及びタイムリファレンスを格納することと、メディアセッションの複製コマンドを受信することと、メディアセッションと関連づけられたコンテンツを前に供給したコンテンツサーバと、新たなコンテンツサーバとのうちの１つを選択し、メディアセッションを複製することと、コンテンツ識別子とタイムリファレンスとを含む複製メッセージを、メディアセッションと関連づけられたコンテンツを前に供給したコンテンツサーバと新たなコンテンツサーバとのうち選択されたいずれかに対して送信し、選択されたサーバにメディアセッションの複製を知らせることと、を含む。
【００１３】
また別の一実施形態によれば、システムは、メディアセッションと関連づけられた、第１のセッション識別子、コンテンツ識別子、及びタイムリファレンスを格納するメモリデバイスと、メディアセッションを複製するコマンドを受信し、メディアセッションと関連づけられたコンテンツを前に供給したコンテンツサーバと新たなコンテンツサーバとのいずれかを選択してメディアセッションを複製し、コンテンツ識別子及びタイムリファレンスを含む複製メッセージを、メディアセッションと関連づけられたコンテンツを前に供給したコンテンツサーバと新たなコンテンツサーバのいずれか選択されたコンテンツサーバに対して送信し、選択されたサーバにメディアセッションの複製を知らせるプロセッサとを有する第１のノードを含む。
【図面の簡単な説明】
【００１４】
添付の図面は、本発明の一実施形態を描いている。
【図１】図１は、共通の場所に配置された２つの端末と、それに接続されたコンテンツ供給システムとを有する従来のアーキテクチャを描く。
【図２】図２は、図１の２つの端末間のセッションの転送と関連する従来のシグナリングを描くシグナリング図である。
【図３】図３は、コンテンツオンデリバリー（ＣＯＤ）セッションの初期セットアップを描くシグナリング図である。
【図４】図４は、一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図５】図５は、一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図６】図６は、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図７ａ】図７ａは、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図７ｂ】図７ｂは、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図７ｃ】図７ｃは、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図８】図８は、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図９ａ】図９ａは、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図９ｂ】図９ｂは、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図９ｃ】図９ｃは、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図１０】図１０は、他の一実施形態にかかる、セッションの再開又は転送と関連するシグナリングを描く。
【図１１】図１１は、一実施形態にかかる、ＩＭＳセッションの再開又は転送のための方法を描くフローチャートである。
【図１２】図１２は、一実施形態にかかる通信ノードである。
【図１３】図１３は、他の一実施形態にかかるメディアセッションを再開、転送、又はコピーする方法を描くフローチャートである。
【発明を実施するための形態】
【００１５】
以下の本発明の詳細な説明は、添付の図面を参照する。異なる図面中の同じ符号は同じ又は類似の要素を示す。また、以下の詳細な説明は本発明を限定するものではない。代わりに、本発明の範囲は、添付の請求項により定義される。
【００１６】
本明細書中において、一実施形態またはある実施形態の参照は、実施形態とともに記述される、特定の特徴、構造、又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。従って、本明細書を通して様々な箇所における「一実施形態において」又は「ある実施形態において」という表現の登場は、必ずしも全て同じ実施形態を指しているとは限らない。さらに、特定の特徴、構造、又は特性は、１又は複数の実施形態において適切な方法で組み合わされてもよい。
【００１７】
一実施形態の議論のためのいくつかの背景を提供するために、ＩＭＳ通信ネットワーク中において、一例としてのＶＯＤコネクション、又はより一般的ないかなるコンテンツオンデマンド（ＣＯＤ）コネクションを確立するために用いられ得るシグナリングが、図３中に描かれる。ここでは、ステップ３０１により示されるように、まずユーザはユーザデバイス３００例えばオープンＩＰＴＶターミナルファンクション（ＯＩＴＦ）を介していくつかのコンテンツを選択する。ＯＩＴＦ１  ３００は、セッション記述プロトコル（ＳＤＰ）の提供（ｏｆｆｅｒ）をするために、例えば、メディア配信及び／又はロケータのためのＩＰアドレス及びポートを含む必要な情報を取得する。ＯＩＴＦ１  ３００は、この情報を、選択されたメディア又はコンテンツストリームへの接続をリクエストする、ＨＴＴＰセッションセットアップリクエスト３０３（ＰＯＳＴメッセージ）をＩＭＳゲートウェイ（ＩＧ）３０２に対して送信するために用いる。例えばユーザの家に設置されたゲートウェイデバイスであるＩＧ３０２は、受信したＨＴＴＰリクエスト３０３を、ＩＭＳネットワークと通信するユーザに適した、対応するセッションイニシエーションプロトコル（ＳＩＰ）ＩＮＶＩＴＥメッセージに変換する。ＩＧ３０２は、そしてこのＩＮＶＩＴＥシグナル３０５を、図３中において認証及びセッション管理（ＡＳＭ）エンティティ３０４によって示されるＩＭＳネットワークに送信する。
【００１８】
当業者により理解されるように、ＩＭＳは、ＩＰマルチメディアサービスをエンドユーザに配信するために利用されるアーキテクチャのフレームワークである。ＩＭＳアーキテクチャは、異種システムのコンバージェンスメカニズムを提供するために、ＩＰプロトコル、例えばＳＩＰシグナリングを用いるサービスに依存しないトポロジに進化してきた。部分的には、これは、アクセスネットワークをサービスレイヤから分離する水平制御レイヤのプロビジョンを介して行われる。とりわけ、ＩＭＳアーキテクチャは、ＩＰＴＶシステムやサービスを展開するために有用なプラットフォームを提供するかもしれない。一般的なＩＭＳアーキテクチャ及びＳＩＰシグナリングに関するより詳細は、第三世代パートナーシッププロジェクト（３ＧＰＰ）技術仕様書（ＴＳ）２３．２２８バージョン８２００７年３月付け、及びリクエストフォーコメンツ（ＲＦＣ）３２６１  ２００２年６月付け中でそれぞれ見つけることができるだろう。このような一実施形態において、セッションが転送又はコピーされる、或いはセッションが再開される、エンドユーザデバイス３００又はＯＩＴＦはそれぞれ、ＩＭＳゲートウェイ３０２に接続されているか、或いは、例えばＩＭＳソフトウェアスタックを有するＩＭＳ機能をあるモバイルデバイスのように、それ自身がＩＭＳの機能を有する。
【００１９】
従って、ＡＳＭエンティティ３０４は、リソース予約フェーズ３０７により示されるように、リソース及びアドミッション制御（ＲＡＣ）エンティティ３０６との組合せによって、ＩＭＳセッションを受信したＳＩＰ  ＩＮＶＩＴＥメッセージ３０５に応じて確立する。当業者によって理解されるように、ＲＡＣエンティティ３０６は、例えばアクセスリソース、アドミッション制御機能（Ａ−ＲＡＣＦ）、及びサービスベースのポリシー決定機能（ＳＰＤＦ）を含むことができる。ＲＡＣエンティティ３０６は、コントロールサービス、例えば特定のアプリケーションのための所定時間におけるリソース予約を転送するためのインタフェースを提供することができる。ＳＰＤＦは論理ポリシー決定要素であり、リソースリクエスト情報の受信及びチェックのような機能を実行するのに対して、より具体的には、Ａ−ＲＡＣＦは、アドミッション制御とネットワークポリシーのアセンブリをサポートする。
【００２０】
ＩＭＳセッションがＯＩＴＦ１  ３００とＩＭＳネットワークとの間で確立されると、ＡＳＭエンティティ３０４は、ＳＩＰ  ＩＮＶＩＴＥ３０９メッセージをＩＰＴＶ制御部３０８に送信し、所望のメディアをリクエストする。ＩＰＴＶ制御部３０８は、リクエストを検証し、検証が成功したとすると、リクエストされたメディアを提供するために適切なコンテンツデリバリーネットワークコントローラ（ＣＤＮＣ）３１０を選択する。この情報は、そのリクエストを、ＳＩＰ  ＩＮＶＩＴＥメッセージ３１３を介して、選択されたＣＤＮＣ３１０に向かわせるＳＩＰ  ＩＮＶＩＴＥメッセージ３１１としてＡＳＭエンティティ３０４に中継される。ＣＤＮＣ３１０は、続いて、リクエストされたメディアをクラスタコントローラ３１２に流す指示を含む、ＳＩＰ  ＩＮＶＩＴＥメッセージを送信する。クラスタコントローラ（ＣＣ）３１２は、リクエストされたメディアが実際に格納されている（ブロック３１７）コンテンツデリバリー機能（ＣＤＦ）３１４により示されるサーバを選択し、リアルタイムストリーミングプロトコル（ＲＳＴＰ）セッション３１９をそのＣＤＦ３１４でセットアップする。これは例えば、ＣＣ３１２によるメディアデリバリーのセッションセットアップの観点のためのＳＩＰからＲＴＳＰへの変換を含むだろう。
【００２１】
ＲＴＳＰセッションが、リクエストされたメディアの配信をサポートするようにＣＤＦ３１４でセットアップされると、ＣＤＦ３１４は、生成されたＲＴＳＰセッションと関連づけられる識別子を含む確認応答メッセージを返す。ＣＣ３１２は、ＣＣ３１２がＣＤＦ３１４から受信したＲＴＳＰ  ＩＤを、例えば自身のステートメモリ（図示せず。）中に格納し、自身のＲＴＳＰ  ＩＤを続く確認応答シグナリング中でＯＩＴＦ１  ３００に返す。ＣＣ３１２は、２つのＲＴＳＰ  ＩＤ、即ち、ＣＤＦ３１４から受信した第１のＲＴＳＰ  ＩＤの値、及び、選択し、ネットワークを介してＯＩＴＦ１  ３００へ転送するＲＴＳＰ  ＩＤの値の間の結合を確立する。多くの場合において、この第２のＲＴＳＰ  ＩＤは、ＯＩＴＦ１  ３００が再開されたプログラムを最初に見たときのＲＴＳＰ  ＩＤの値であるだろう。以下に記述される一実施形態によれば、ＣＣ３１２のこの機能は、ＯＩＴＦ１  ３００が、再開されるプログラムをみるときに、前に用いられていたＲＴＳＰ  ＩＤを使い続けることができるように用いられうる。その上、再開されるプログラムを供給し、新たなＲＴＳＰを、ＣＣ３１２がＯＩＴＦ１  ３００に返すＲＴＳＰ  ＩＤに後ほどバインドできる新しいセッションＩＤで生成するＣＤＦ３１４を（任意的に）変更する柔軟性を有するＣＣ３１２を提供する
【００２２】
この確認応答（第２のＲＴＳＰ  ＩＤ値を含む）は、ネットワークを通ってＣＤＮＣ３１０に（シグナル３２３を介して）公布され、そしてＡＳＭ３０４に（シグナル３２５を介して）公布され、そしてＩＰＴＶ制御部３０８に（シグナル３２７を介して）公布される。この時点で、ＩＰＴＶ制御部３０８は、ＩＭＳネットワークに、デリバリーネットワークがリクエストされたコンテンツを配信する準備ができたことをシグナル３２９を介して信号伝達し、ＩＭＳネットワークは、リソースコミットフェーズ３３１に入る。例えば、ＡＳＭ３０４は、ＲＡＣエンティティ３０６に（シグナル３３３を介して）、前にこのコネクションのためにリソース予約フェーズ３０７の間予約されていたリソース（例えば、ＤＳＬＡＮ（図示せず）とＯＩＴＦ１  ３００が居住する家庭との間の通信リンク上の帯域）をコミットしたいことを信号伝達する。ＲＡＣエンティティ３０６は、続いて、ＩＧ３０２に（シグナル３３５を介して）この帯域がＯＩＴＦ１  ３００がリクエストされたメディアを提供するために割当てられたことを信号伝達する。ＩＧ３０２は、ＩＭＳセッションと関連づけられるＳＩＰセッションＩＤ、及び、メディア配信セッションと関連付けられるＲＴＳＰセッションＩＤを含む、ＨＴＴＰセッションセットアップ応答メッセージ３３７をＯＩＴＦ１  ３００に送信する。ＯＩＴＦ１  ３００は、ＲＴＳＰプレイメッセージ３３９をネットワークを通じてＣＤＦ３１４に送信し、リクエストされたコンテンツ又はメディアを矢印３４１で示されるように配信する。
【００２３】
上述の通り、ＶＯＤサービスについての関心（ｉｎｔｅｒｅｓｔ）の１つの使用状況などは、ユーザが１つの端末上で実行しているＶＯＤプログラムを一時停止し、家の中の他の部屋に移動し、そこで彼または彼女が同じプログラムを一時停止した時点から他の端末上で視聴を再開したい状況を含む。この端末は、ユーザが彼又は彼女が一時停止したセッションを再開したい端末として登録されていれば、同じ家の他の部屋にあってよく、異なる場所であってよく、又は携帯端末であってもよい。これは、ここにマルチメディアセッションの転送として記述されている。例えば、図３に示されるように、ユーザがプログラムを一時停止するためにリモートコントロールデバイスを操作するのに応じて、ＯＩＴＦ１  ３００は、ＲＴＳＰ一時停止メッセージ３４３をネットワークノードを通してＣＤＦ３１４に対して送信することができる。ＣＣ３１２は、一時停止されたプログラムの状態を格納するために、シグナル３４５及び３４７を介して、現在時刻の値又はプログラムのカウンター値についてＣＤＦ３１４にクエリーを行うことができる。続く一実施形態は、一時停止されたＶＯＤプログラム又は同様のものを他の端末で再開するための様々なメカニズム及びシグナリングを描く。しかしながら、これらの一実施形態は、以下に詳述されるように、セッションを一時停止してそれを同じ端末上で再開する場合にも、第１の端末上で一時停止せずに、第２の端末にセッションをコピーする場合にも等しく適用することができる。
【００２４】
第１の一実施形態によれば、一時停止されたメディア又はコンテンツの再開は、ＩＭＳセッションを第２の新たな端末にプルメカニズムを用いて転送することによって達成され得る。この第１の一実施形態によれば、変更は、ＩＧ３０２によるシグナリングリクエストに挿入され得るセッション転送インジケータを提供するＩＭＳ仕様によりなされる。このセッション転送インジケータは、ＡＳＭエンティティ３０４（及びより具体的にはプロキシコールセッション制御機能（Ｐ−ＣＳＣＦ））が、ＩＭＳセッションが第２の端末に転送されることを明確に検知することを可能にする。新たな端末は、セッションの「ｐｕｌｌｉｎｇ」が引き起こされる第１の古い端末と同じ家の中に位置する。これは、次に、Ｐ−ＣＳＣＦが、インジケータを含む、対応するＳＩＰ  ＩＮＶＩＴＥメッセージを受信するとき、ＩＭＳリソース予約をバイパスすることを可能にし、また代わりに、オリジナルセッションが終了された後、対応する２００  ＯＫ確認応答メッセージが受信されたとき、リソース割り当てを後ほど実行することを可能にする。
【００２５】
図４は、この「ｐｕｌｌ」実施形態と関連する一例としてのシグナリングをハイレベルで描く。より詳細なバージョンが図５を参照して以下に記述される。図４及び５において、エンティティ３００，３０２，３０４，３０６，３０８，３１０，３１２，及び３１４は、それらエンティティのうちのいくつかの間で異なるシグナリングが起こるけれども、図３を参照しながら上記されたものと同一である。第２のＯＩＴＦ２  ３０１は、ＯＩＴＦ１  ３００において最初に視聴され（そして潜在的に一時停止される）矢印４００により示されるプログラムが再開され得る他の端末デバイスを示すために図４及び５に加えられる。ステップ４０２により示されるように、ユーザは初め例えばＶＯＤプログラムをＯＩＴＦ１  ３００上で視聴しており、セッションをＯＩＴＦ２  ３０１に移動させたい。そのユーザは、例えばＯＩＴＦ２  ３０１から彼又は彼女が現在登録している（そのうちのいくつか又は全ては一時停止されているだろう）全てのアクティブなＩＭＳセッションのリストをステップ４０４においてリクエストすることができる。これは、固定装置又はモバイル端末と関連づけられたセッションを含むことができる。ユーザはそしてリストからセッションのうちの１つを選択し、そのセッションの転送をステップ４０６においてリクエストする。この一実施形態によれば、ＩＧ３０２は、転送されるために選択されたセッションが、デバイスすなわちこの例におけるＯＩＴＦ１  ３００に属することを検出する。ＯＩＴＦ１  ３００は、転送が実行され、そして転送セッションインジケータを、ステップ４０８においてネットワークを通って転送する転送リクエストに付加するデバイスとして同じ家庭内にある。新たなＩＭＳセッションがＯＩＴＦ２  ３０２とステップ４１０において確立され、そしてＩＰＴＶサーバは進行中のセッションをステップ４１２においてブックマークする。この文脈において、「ブックマーク」という単語は、それによってＩＰＴＶサーバがスケジュールされたコンテンツサービス又はコンテンツオンデマンドサービスから、コンテンツアイテムを再生する間の特定の時点をマーク又は識別することができるメカニズムを言う。コンテンツアイテムの識別子とコンテンツアイテムの再生と関連づけられた特定の時点とのこの組合せは、ここで「ブックマーク」と言う。第１のセッション、すなわちユーザがＯＩＴＦ１  ３００上で視聴していて、一時停止された或いは一時停止されていないセッションは、そしてステップ４１４のように解放されてよい。
【００２６】
図５は、この一実施形態に関するシグナリングをより詳細に描く。ここでユーザは、セッション再開オプションを彼又は彼女の端末装置（ＯＩＴＦ２  ３０１）上で、例えば、ユーザインタフェースオプション及び／又はリモートコントロールデバイスを介して選択する。この再開オプションは、そのＩＭＳユーザと対応するＩＰＴＶ制御部３０８からフェッチされたユーザのためのアクティブなセッションのリストをもたらす。このリストは、例えば、ＯＩＴＦ２  ３０１によってエンドユーザによるセッションのうちの１つの選択を受付けるために表示される。選択されたセッションは、そしてＨＴＴＰ  ＰＯＳＴシグナル５０４をＯＩＴＦ２からＩＧ３０２へ送信することによって、ＯＩＴＦ２  ３０１に転送されるようにリクエストされる。シグナル５０４は、選択されたセッションを識別するセッション転送リクエストを含む。この一実施形態によれば、ＩＧ３０２は、転送されるセッションを識別するセッション転送識別子と、ＩＭＳネットワーク（及び特にＰ−ＣＳＣＦ）に転送されるセッションが現在同じ家庭に、それに対して転送されるＯＩＴＦ２  ３０１として存在することを知らせる転送リクエストインジケータとを含むＳＩＰ  ＩＮＶＩＴＥメッセージ５０６をＡＳＭエンティティ３０４に送信する。リストから選択された転送されるセッションが、もし現在同じ家庭においてアクティブなセッションと対応していないとき、転送リクエストインジケータは除外される、または異なる値を有してもよいことは特筆すべきである。ＩＧ３０２が家庭内の全てのＯＩＴＦｓ３００，３０１から全てのＩＭＳセッションの状態を追跡すると仮定すると、ＩＧ３０２は、転送すべきセッションが同じ家庭内のＯＩＴＦに属するか否かを判定し、固有の（ｐｒｏｐｅｒ）情報をＳＩＰ  ＩＮＶＩＴＥメッセージ５０６に挿入することができる。
【００２７】
この例において、ＩＮＶＩＴＥシグナル５０６は、転送リクエストインジケータを本当に含むので、（又は転送されるセッションを有する同じ家庭のデバイスに関連するセッション転送リクエストをＩＭＳネットワークに知らせる値を有する転送リクエストインジケータを含むため）ＡＳＭ３０４は、転送されようとしているセッションのための帯域を予約するために、ＲＡＣエンティティ３０６にコンタクトする必要はない。代わりに、ＡＳＭ３０４は、ＳＩＰ  ＩＮＶＩＴＥメッセージ５０８を介して識別されたセッションと関連づけられたＩＰＴＶ制御部３０８とコンタクトすることによって転送されるセッションのセットアップを進める。ネットワークのＩＰＴＶ部は、セッションが今コンテンツをストリーミングするための新たなデバイスＯＩＴＦ２と通信しているという事実を反映するために、ＣＣに対してＩＭＳセッションを更新する。そしてＣＣは順にＲＴＳＰセッションを更新する。ＩＭＳセッション更新は、これらのシグナルのそれぞれは個々に説明されないが、図５に示されたようなシグナル５１０−５２２を介して、シグナル３１１−３２９について上述されたのと同じ方法で、ＲＴＳＰコネクションをセットアップする。例えば、ここで留意すべきはＳＩＰ  ＵＰＤＡＴＥ又はｒｅ−ＩＮＶＩＴＥメッセージはその目的のために用いられ得ることである。加えてこの一実施形態において留意すべきは、ＣＤＦ３１４は、古い（すなわちアクティブなセッションと関連する）セッションナンバーを含むＲＴＳＰセットアップメッセージ５１６を扱うことができることである。もし、ＣＤＦ３１４がこのタイプのＲＴＳＰセットアップメッセージを扱うことができなければ、図１０を参照して以下に記述されるように代わりのシグナリングが実行されるだろう。しかしながら、ＣＣ３１２がＵＰＤＡＴＥシグナル５１４中において提供される情報に応じて、新たなＣＤＦ３１４を選択し、新たなＲＴＳＰセッションを確立するであろうことに留意すべきである。そのようなケースにおいて、ＣＣ３１２は、ＯＩＴＦ１  ３００により用いられ、ＯＩＴＦ２  ３０１により用いられるであろうＲＴＳＰ  ｓｅｓｓｉｏｎ  ｉｄをＲＴＳＰセッションセットアップ手順から返されるであろう新たなＲＴＳＰ  ｓｅｓｓｉｏｎ  ｉｄと結びつける。
【００２８】
ネットワークのメディア部分が転送されるだろうＩＭＳセッションのためのＲＴＳＰコネクションのセットアップを終わらせると、ＩＭＳネットワーク３０４は、ブロック５２６により示されるように、ＩＰＴＶ制御部３０８にＳＩＰ  ＩＮＶＩＴＥメッセージ５２４を介して、順にＯＩＴＦ１  ３００のセッションをブックマークしてＶＯＤ（又は他のコンテンツ）プログラムの時間的な状態を維持することを知らせることができる。そして、ＩＭＳネットワークは、ブロック５２８により示されるように、現在のＯＩＴＦ１  ３００のためのＩＭＳセッションを終わらせ、ＯＩＴＦ２のための新たなＩＭＳセッションを確立するためのリソースを用いることができる。この情報は、ＲＴＳＰセッションＩＤと共に、２００  ＯＫシグナル５２９及び５３０を介してＩＧ３０２に通信され、続いて、ＨＴＴＰ２００  ＯＫシグナル５３１を介してＯＩＴＦ２  ３０１に知らせる。ＯＩＴＦ２  ３０１は、そしてメディアが再開されることをＣＣ３１２に送信されるＲＴＳＰ  Ｐｌａｙシグナル５３２を介してリクエストし、シグナル５３４−５３８を介してメディアストリームの再開を完了し、その後ＣＤＦ３１４は、メディア５４０をネットワークを介して端末３０１に供給することができる。上述されるように、この例は、第１の端末３００と異なる第２の端末３０１上でのメディア５４０の再開という状況において記述されるが、同じ又は類似のシグナリングが、メディア又はセッションが一時停止された端末と同じ端末上でメディアを再開するために用いられてもよい。
【００２９】
上述の通り、転送リクエストインジケータの供給は、ＩＭＳシステムがＩＭＳセッションを同じアクセスを共有する端末、例えば同じ家庭内の端末間で転送するために予め割当てられた待機を必要としないことを認識させる。しかしながら、そのようなインジケータを供給するためには、そのようなインジケータは今日存在しないため、現在策定されているＩＭＳ仕様の変更を余儀なくさせる。このような問題を取り扱うための他の実施形態にかかるもうひとつの選択肢は、転送リクエストインジケータなしで、ＩＮＶＩＴＥシグナル５０６を送信することである。代わりに、ＡＳＭエンティティ３０４が、セッション転送識別子と共にＩＮＶＩＴＥシグナル５０６を受信するとき、Ｐ−ＣＳＣＦは、そのようなセッション転送識別子を含むセッションの状態を有するか否か、そしてもしそうならば、セッションは同じアクセスポイントであるかどうか（例えばＩＰアドレスをチェックすることによって）を確認するだろう。
【００３０】
もしそうならば、Ｐ−ＣＳＣＦは、そして上述の方法で、上述の一実施形態における、転送リクエストインジケータの追加を課すＩＭＳ仕様の変更を要することなく、ＩＭＳリソース予約フェーズをバイパスすることができる。このタイプの実施形態は、送信される明示的なインジケーションを提供する、前の一実施形態に対して、セッションのセットアップのために帯域を初めに予約する必要のないネットワークへのインジケーションの暗示的な送信といわれる。
【００３１】
かくして、もうひとつの一実施形態によれば、ＩＭＳ仕様の修正が必要な信号を用いない、ＩＭＳ端末間のプルセッション転送メカニズムが提供される。一実施形態が、図６及び７を参照して説明されるだろう。この一実施形態をより高いレベルで描く図６から続けて、初めの４つのステップ６００−６０６は、図４のステップ４００−４０６と同様である。しかしながら、ステップ４０８においては転送セッションインジケータを含む代わりに、ステップ６０８においてＩＧ３０２は、ＯＩＴＦ１  ３００の入力（ｉｎｃｏｍｉｎｇ）メディアを、同じ家庭内に位置するデバイスに転送されるであろうセッションを検出したとき保留する。システムのメディア配信部は、そしてステップ６１０において、セッションが保留になるときからセッションをブックマークし、ＩＧは、そしてＯＩＴＦ１  ３００のためのリソースをステップ６１２においてリリースすることができる。新たなセッションは、そしてＯＩＴＦ２  ３０１のためにステップ６１４において確立される。そしてＯＩＴＦ１  ３００のためのＩＭＳセッションは、ステップ６１６においてリリースされうる。再開されるメディア例えばＶＯＤプログラムは、第２の端末ＯＩＴＦ２  ３０１に矢印６１８により示されるように提供される。
【００３２】
より詳細に、しかしまた一例として、図６の実施形態を実行するために用いられ得るシグナリング図が図７（ａ）のように提供される。ここで、シグナリングは、最初のＩＭＳセッションが確立され、ユーザが第２のＯＩＴＦ２  ３０１に転送するセッションを選択した後の時点において開始する。ＯＩＴＦ２  ３０１は、ＨＴＴＰ  ＰＯＳＴメッセージ７００をＩＧ３０２に対して送信することによって、このセッションを転送したいことを示す。ＩＭＳゲートウェイ３０２は、続いて、同じ家庭内のデバイスに属する選択されたセッションを特定すると、ＳＩＰ  ＵＰＤＡＴＥシグナル７０２を、リクエストをＩＰＴＶ制御サーバ３０８に転送するＡＳＭエンティティ３０４に送信することによって、既存のセッションを保留する。既存のＯＩＴＦ１  ３００とのセッションを保留するためにリクエストを受信することによって、ネットワークのメディア配信部は、その端末に配信された対応するメディアコンテンツの時間的な状態を維持するために、そのセッションを（ブロック７０６により示されるように）ブックマークするだろう。セッションが保留されているシグナル７０８及び７１０を介して確認応答を受信した後、ＩＧ３０２は、ＯＩＴＦ１  ３００のためのリソースを解放し、それらを（シグナル７１２−７２０を介して）それらのリソースをＯＩＴＦ２  ３０１のための新たなセッションのために予約するより前に、ＯＩＴＦ２が利用することができるようにする。
【００３３】
ＩＧ３０２は、そして転送されるセッションのセッション識別子を含むＳＩＰ  ＩＮＶＩＴＥメッセージ７２２を送信することによって、リソース予約フェーズ７２４を開始する。このフェーズ７２４は、それぞれ、これらの図７（ａ）中のシグナルの個々に合わせて記述がここで繰り返されないように、図５及びシグナル５０８−５２６を参照して上記に説明されたシグナリングと同一の（又は実質上同一の）シグナリング７２６−７４４を含む。そのとき、ブロック７４６及び７４８によりそれぞれ示されるように、リソースは、ＯＩＴＦ３  ３０１への新たなセッションのためにコミットされ、ＯＩＴＦ１  ３００に対する古いセッションは終了され得る。ＯＩＴＦ２  ３０１は、新たなセッションが準備できたことをシグナル７５０及び７５２を介して知らされ得る。そして再開されるセッションと関連づけられたメディアは、シグナル７５４−７６２により示されるように、ＯＩＴＦ２  ３０１に送信され得る。初めに述べられたように、この後者の一実施形態は、システムが帯域を不要に予約することを避け、既存のＩＭＳ仕様を変更することなく、ＩＭＳセッションを再開し、対応するコンテンツを配信するメカニズムを提供する。この一実施形態によれば、もしＯＩＴＦ１  ３００が出力するコンテンツを切らす（例えば、メディアが保留されている間）ても、ＯＩＴＦ１  ３００は、もしＯＩＴＦ２  ３０１への転送が失敗しても、この再開されるセッションを許可するために、ＲＴＳＰ  Ｐａｕｓｅコマンドを発行することができる。代わりに、以上説明された他の一実施形態は、ＯＩＴＦ１  ３００がＲＴＳＰ  ｐａｕｓｅを発行してこの状況を避けることを確認するために、ＩＧ３０２がメディア保留メッセージをＯＩＴＦ１  ３００に送信することにより利用することができる。
【００３４】
もうひとつの一実施形態によれば、ＩＧ３０２は、メディアをＯＩＴＦ１  ３００及びＣＤＦ３１４の両方のために保留する。ＯＩＴＦ１  ３００がメディア保留更新シグナルを受信するとき、ユーザへのストリームの出力が一時停止される。この一実施形態と関連づけられた一例としてのシグナリング図が、図７（ｂ）及び７（ｃ）に示される。そこで、図７（ａ）の一実施形態を参照して上記に説明されたシグナリングと同一又は類似のシグナリングは数え切れず、説明を単純にするためにここでは記述されていない。しかしながら、興味のある読者は、これらのシグナルの説明のための前のテキストが参照される。もし再開のために選択されるセッションが例えば同じ家庭に属するならば、ＩＧ３０２は、ネットワーク及びネットワークにおけるセッションのブックマークの副作用を有し、ＯＩＴＦ１  ３００にＲＴＳＰ  ｐａｕｓｅメッセージ７６３を送信させる、この一実施形態にかかるＯＩＴＦ１  ３００の両方においてメディアを保留する。ネットワークは、古いデバイスにメッセージ７６４，７６６、及び７６８を介した継続中の転送を助言するために、通知を送信する。ＩＧ３０２は、そしてＯＩＴＦ１  ３００がリソースをＯＩＴＦ２  ３０１が利用できるようにするためにリソースをリリースする（ブロック７６９）。図７（ｃ）に引き続き存在し、メディアがステップ７７０においてＯＩＴＦ２  ３０１に配信されるまで継続する、以下のリリースリソースフェーズブロックに描かれるシグナルは、図７（ａ）において記述される対応するシグナル及びステップと類似する。ブロック７７２は、転送失敗と関連する一例としてのシグナリングを描き、シグナル７６４などの代わりに、そのような失敗のイベント中において実行される。ここで留意すべきは、図７（ａ）の一実施形態のように、図７（ｂ）及び７（ｃ）の一実施形態もまた現在策定されているＩＭＳ仕様のいかなる変更も必要としないことである。
【００３５】
これらの後者の一実施形態は、ＩＭＳセッション及び対応するメディア配信の家庭内の同じ又は異なる端末における再開のためのプルメカニズムを記述する。プッシュメカニズムと似た機能を提供する、すなわち、第１の端末がそのセッションを第２の端末にプッシュするというよりむしろ、第２の端末がセッションを第１の端末からプルするもうひとつの一実施形態が、図８及び９（ａ）−９（ｃ）を参照しながら記述されるだろう。前の一実施形態と同様に、この一例としてのプッシュメカニズムは、まず図８においてより高いレベルで描かれ、メディアコンテンツ８００のＯＩＴＦ１  ３００により示される第１の端末へのメディアコンテンツ８００の送信から開始する。上記の一例としてのプルメカニズムとは異なって、この一実施形態において、ユーザは、ユーザが登録されたＯＩＴＦまたは他のＩＭＳデバイスのリストを第１のＯＩＴＦ１  ３００を介してステップ８０２においてリクエストする。彼または彼女が例えば第１の端末装置上のＯＩＴＦ１  ３００により表示されるユーザインタフェースオブジェクトによってこのリストを参照すると、彼又は彼女は、ステップ８０６において、リストされたセッションのうちのひとつのＯＩＴＦ２  ３０１への転送を選択することができる。この転送を実行するために、例えば、ＩＭＳネットワークにリソース割り当てが遅れ得ることを示すために明示的な転送リクエストインジケータが用いられること、又はステップ８０８により一般的に示されるように、リクエストされたメディアを保留することによりこれを暗示的に示すことなど、様々なシグナリングメカニズムを用いることができる。ネットワークのメディア配信部は、そしてユーザセッションがＯＩＴＦ２  ３０１に転送されるだろうことをステップ８１０において知らせ、セッションのブックマーク及びステップ８１２における古いセッションの消去をもたらす。ステップ８１４においてメディアパスは更新され、そして矢印８２０により示されるように、第２の端末３０１へのメディアの配信のための方法を準備するためにオープンされる（ステップ８１６及び８１８）。
【００３６】
図８のプッシュの一実施形態と関連するより詳細なシグナリング図が図９（ａ）−９（ｃ）に見られる。ここで、第１のＩＭＳセッションと関連づけられたメディアは、矢印９００により示されるように、最初ネットワークを通ってＯＩＴＦ１  ３００に送信されている。ＯＩＴＦ１は、ユーザが登録している他のＩＭＳデバイスのリストを、ブロック９０２において取得する。ＨＴＴＰ  Ｐｅｎｄｉｎｇ  Ｒｅｑｕｅｓｔシグナル９０４（シグナル９０８及び９１６と同様のシグナルもまた）は、ＩＧ３０２がこの一実施形態にかかるＨＴＴＰリクエストを初期化できないときから、ＩＧ３０２及びＯＩＴＦ３００，３０１へのいかなる入力情報も適切なＯＩＴＦへ送信されることを確認するために、ＩＧ３０２とＯＩＴＦｓとの間でＨＴＴＰプロトコルの適切な動作を提供する。それでＯＩＴＦ３００又は３０１は、ＯＩＴＦ３００又は３０１についてのいかなる非同期情報もそれに対する反応として送信され得るために、ＨＴＴＰ  Ｐｅｎｄｉｎｇ  Ｒｅｑｕｅｓｔを送信する。ブロック９０６中に描かれる一例としてのシグナルは、既存のセッションをＯＩＴＦ２  ３０１に転送することをリクエストするために用いられ得る。ブロック９１０のシグナルは、ステップ８０８に関して上記に述べられた２つの選択肢と関連するシグナリングを描く。
【００３７】
より具体的に、ＨＴＴＰ  ＰＯＳＴリクエストがＯＩＴＦ２  ３０１から受信されると、ＩＧ３０２は、ＩＭＳネットワークに新たなセッションが最初セッションのための帯域を予約することなく確立されるべきであることを知らせるために、（これらの一実施形態によれば）ブロック９１２において示されるシグナリングを実行することもできるし、ブロック９１４において示されるシグナリングを実行することもできる。ブロック９１２及び９１４は、図７（ａ）および５を参照しながらそれぞれ上記に説明された、明示的及び暗示的な一実施形態と関連するシグナリングを示す。しかしながら、図７（ｂ）及び７（ｃ）を参照して上に記述された、ネットワークとＯＩＴＦ１  ３００との両方においてメディアを保留することと関連する選択肢は、同様にブロック９１２及び９１４の選択肢として実行され得る。ＲＡＣ３０６への続くシグナリングは、図を単純にするために、図９（ａ）から除外される。図８のステップ８１０，８１２，８１４を実行するための一例としてのシグナリングが図９（ｂ）のブロック９１８，９２０，９２２中にそれぞれ描かれる。
【００３８】
上述の一実施形態は、例えばＩＰＴＶサービスプロバイダが既存のサービスセッションを他のＩＴＦに複製するための様々なメカニズムをサポートする。ＩＴＦ間のサービスセッション複製のために、この方法は、主にＶｏＤ又はＣｏＤタイプのプログラムに適用することができる。家庭外のデバイスへのサービスセッション複製のために、これはスケジュールされたコンテンツにも適用することができる。当業者にとって、様々な確認応答シグナルなどがシグナリング図を単純にするために除外されている。場合によっては、ユーザは、もうひとつの端末へセッションを転送する前に、一時停止が要求されず、第１の端末においてメディアストリームを一時停止するかもしれない。
【００３９】
上述の一実施形態は、古いＲＴＳＰセッションナンバーを再利用することによって、ＲＴＳＰセットアップが転送されるセッションのために実行されるシグナリングを示す。代わりに、ＣＣ３１２は、新たなＣＤＦ３１４を選択し、真新しいＲＴＳＰセッションを確立してもよい。また他の選択肢は、図１０の一実施形態中に示される。この例において、転送されるＩＭＳセッションのためのＲＴＳＰセッションの確立より前のシグナリングは、図を単純にするために省略される。コールフローは、ＣＣ３１２が、ＳＩＰ  ＵＰＤＡＴＥメッセージ９８０を受信して、転送ストリームを更新しようとして、（ＯＩＴＦ１においてプログラムと関連づけられた）古いセッションナンバーを用いてＲＴＳＰセットアップメッセージ１０００を送信する時点に続く。このケースにおいて、せっとあぷは、エラーメッセージ１００２により示されるように失敗する。なぜならばＣＤＦ３１４は、転送ストリームの変更機能をサポートしていないからである。かくして、ＣＣ３１２は、シグナル１００４及び１００６を介して新たなＲＴＳＰセッションをセットアップする。ＣＣ３１２は、新たなセッションとＯＩＴＦ２  ３０１に対するＲＴＳＰセッションとの間の結合を維持する。ＣＣ３１２はまた、古いＲＴＳＰセッションをクリアするが、レンジ及び他の関連情報をセッションをクリアする前にコピーする（コピーするステップはフローにおいて示されない）。続いて、ＣＣ３１２は、ＵＰＤＡＴＥに応答を返し、コールフローはセッションが無事確立されるまでレジュームする。最後に、ＯＩＴＦ２  ３０１は、ＲＴＳＰレジュームシグナル１００８をＣＣ３１２に発行する。ＣＣ３１２は、プログラムが適切な時点において、リクエストをＣＤＦ３１４に転送する前に、再開されるように、ＲＴＳＰレジュームシグナルに範囲の値を挿入する。前の一実施形態と異なり、この一実施形態は、メディアがＯＩＴＦ２  ３０１に提供された後、（矢印１０１０により示されるように）古いセッションの終了を提供する。
【００４０】
上述の一実施形態は、視聴されるコンテンツがある端末において一時停止又は停止され、そして第２の端末において視聴するために再開される、ある端末から他の端末へのセッション転送を記述する。そのような例において、転送が起こった後、古いセッションはクリアされる。しかしながら、簡潔に上述されたように、他の一実施形態は、第１の端末から第２の端末へ視聴される同一のセッションのコピーの提供をサポートするために、類似の技術及びコールフローを用いることができる。例えば、もしユーザがＶｏＤプログラムを彼又は彼女のリビングルームにおいて、あるテレビ上で友人のグループと共に視聴していて、食事の準備をするためにキッチンに移動し、彼又は彼女はリビングルームのテレビ上で再生を続けながら、キッチンのテレビにセッションをコピーしたいかもしれない。そのような実施形態において、古いセッションはセッションが第２の端末にコピーされたあともクリアされない。
【００４１】
上述のように、ＩＰＴＶ制御サーバ３０８は、セッション転送が実行されるときに第１のセッションをクリアするノードである。この実施形態によれば、情報は、セッションが多の端末に転送される（セッションをクリアして）か、又はセッションが他の端末にコピーされる（セッションはクリアせずに）かどうかを知らせるＩＰＴＶ制御サーバ３０８に渡される。上述の一実施形態の状況において、セッションのコピーは、下記のようにセッション転送に加えられ得る。
【００４２】
例えば、図５の一実施形態について、ステップ又はシグナル５０４は、セッション転送インジケータ（古いセッションを新たなセッションに置き換えることを意味する）又はコピーインジケータ（古いセッションが維持されるべきであることを意味する）を含むように修正されてもよい。インジケータは、ＳＩＰ  ＩＮＶＩＴＥメッセージ５０６中において運ばれ、図示されるようにシステムを通って前方に広められる。もしインジケータがコピーインジケータであれば、Ｐ−ＣＳＣＦは、インジケータがＩＰＴＶ制御サーバ３０８に到達するとき、既存のセッションを終了する必要がないので、終了フェーズ５２８を省略して、通常通り動作するだろう。
【００４３】
図７（ａ）の一実施形態に関していえば、この実施形態はまた、ステップ／シグナル７００においてセッション転送インジケータ（置き換え）又はコピーインジケータ（及びまたＳＩＰ  ＩＮＶＩＴＥメッセージ７２２）を運ぶことによって、セッション転送又はセッションコピーの両方を許可するように修正されてよい。もしインジケータがセッション転送インジケータ（置き換え）であれば、コールフローの残りを図７（ａ）中において示されるように維持する。もし、インジケータがコピーインジケータであれば、ＩＧ３０２の挙動は少し変わる。より具体的には、シグナル７０２−７１０が図７（ａ）中において示されるように実行され、しかしＩＧ３０２はその後、メディアを再開するためにステップ７０２から７１０と同じステップを再び繰り返すことによって、メディアをオープンする必要がある（しかしながらこのケースにおいてはブックマークは必要とされない）。ステップ／シグナル７１２−７２０は、そしてインジケータがコピーインジケータであるときには省略され、Ｐ−ＣＳＣＦはコピーインジケータを無視する。コピーインジケータは、ブロック７４８が省略されるようにセッションをクリアしないことを知るＩＰＴＶ制御サーバ３０８に運ばれる。
【００４４】
図７（ｂ）及び７（ｃ）の一実施形態に関していえば、この実施形態はまた、イニシャル（番号が付けられていない）ＨＴＴＰ  ＰＯＳＴシグナルを運ぶことによって、セッション転送又はコピーの両方を許可するように修正されてよい。このインジケータは、ＳＩＰ  ＩＮＶＩＴＥメッセージ中において運ばれる。もしインジケータがセッション転送インジケータ（置き換え）であった場合、コールフローの残りは、これらの図面中において示されるように継続される。もしインジケータがコピーインジケータであった場合には、ＩＧ３０２の挙動は少し変わる。前のパラグラフ中の図７（ａ）の実施形態の変形バージョンのように、ＩＧ３０２は、セッションをブックマークしないで、メディアフローをオープンするために用いられるステップを２度繰り返す必要があるだろう。さらに、Ｐ−ＣＳＣＦは、ＩＰＴＶ制御サーバにセッションをクリアしないことを知るために、コピーインジケータを無視するだろう。類似の変形が図９の一実施形態に対して行うことができる。
【００４５】
上記の内容から、セッションが、（同じ又は異なる端末上で）再開され、（異なる端末に）転送され、又は最初の端末上においても継続されながら（異なる端末に）コピーされ得ることが理解されるだろう。セッションマネジメントのこれらの３つのタイプの全てを包含するための包括的な（ｇｅｎｅｒｉｃ）用語が必要とされる限りにおいて、「ｒｅｐｌｉｃａｔｅ」、「ｒｅｐｌｉｃａｔｉｎｇ」、「ｒｅｐｌｉｃａｔｉｏｎ」及び同類のものは、本明細書において、セッションを、同じ端末及び異なる端末を含めて、前述の一実施形態のいずれかに記述された方法で、再開し、転送し、又はコピーすることを意味する。
【００４６】
前述の例に基づいて、一実施形態に従ったＩＭＳセッション及び対応するメディア配信を再開し、転送し、またはコピーするための方法は、図１１のフローチャート中に描かれるように表現され得る。ここでステップ１１００において、ＩＭＳゲートウェイを介して開始されるＩＭＳセッションと関連づけられたメディアは、第１の端末に対して送信される。リクエストは、ＩＭＳゲートウェイによって、ＩＭＳセッションを再開、転送、又はコピーするためにステップ１１０２において受信される。ＩＭＳゲートウェイは、ステップ１１０４において、第１の端末と関連づけられる第２の端末に、ＩＭＳセッションが再開され、転送され、又はコピーされることを決定する。ステップ１１０６において、ＩＭＳゲートウェイはセッション転送インジケータ又はコピーインジケータのいずれかのインジケータをＩＭＳネットワークに対して送信する。かくして、一実施形態はまた、ソフトウェア、例えばコンピュータに読取り可能なメディアに格納されたプログラムコード又は命令（ｉｎｓｔｒｕｃｔｉｏｎｓ）であって、コンピュータ、プロセッサなどにより読み込まれたとき、上記の情報シグナルの送信と関連する所定のステップを実行するプログラムコード又は命令に関する。
【００４７】
さらに、本発明の一実施形態にかかるデータを処理するためのシステム及び方法が、メモリデバイス中に含まれる命令のシーケンスを実行する１または複数のプロセッサによって実行され得る。そのような命令は、セカンダリデータストレージデバイスのような、他のコンピュータに読取り可能なメディアから、メモリデバイスに読み込まれてよい。メモリデバイスに含まれる命令のシーケンスの実行は、プロセッサに例えば上述のように処理させる。代わりの実施形態において、本発明を実装するために、配線回路がソフトウェア命令の代わり又はソフトウェア命令と組合せて用いられてよい。例えば、図１２はこれらの一実施形態を実装するために用いられるノード、例えばＩＭＳゲートウェイ又は他のノードを描く。ここで、ノード１２００はプロセッサ１２０２（又はマルチプルプロセッサコア）と、メモリ１２０４と、１又は複数のセカンダリストレージデバイス１２０６と、自身とネットワークの残りとの通信を手助けする通信インタフェース１２０８と、を含むことができる。プロセッサ１２０２及びインタフェース１２０８は、様々な機能と、セッション確立及び上述の選択的な帯域予約のためのシグナリングを実行することもまたできる。図１２のノードは、例えばコンテンツコントローラ３１２を示すこともまたできる。そのような実装において、メモリ１２０４は、第１のセッション識別子、例えばメディアセッションと関連づけられるＲＴＳＰ識別子と、コンテンツ識別子、例えば一時停止されるＶｏＤプログラムの識別と、タイムリファレンス、例えば一時停止されるＶｏＤプログラム中の時点の識別を格納するために用いられ得る。もし、プログラムが再開される第２の端末が第１の端末と異なる昨日を有するために、異なるＲＴＳＰセッションがプログラムの再開をサポートするためにセットアップされることが必要であるならば、第２のセッション識別子は、メモリ１２０４中において２つの識別子間のつながりを格納することによって、第１のセッションと関連づけられてよい。
【００４８】
この後者の実施形態に関していえば、メディアセッションを再開するための方法が、図１３のフローチャート中に示されるように記述され得る。ここで、ステップ１３００において、第１のセッション識別子、コンテンツ識別子及びメディアセッションと関連づけられたタイムリファレンスが、例えばコンテンツコントローラ３１２のメモリ部中に格納される。このアイテムのストレージは、様々な時間例えば後に再開されるコンテンツの最初の再生の間、様々な時点において発生してもよい。セッションを複製するコマンドは、受信するノードが、ステップ１３０４により示されるように、古いコンテンツサーバ、すなわち、前にメディアセッションをサポートしたサーバと、メディアセッションの複製をサポートする新たなコンテンツサーバとのうちいずれかを選択するとすぐに、ステップ１３０２において受信される。コンテンツ識別子とタイムリファレンスを含む複製メッセージは、ステップ１３０６において、選択されたサーバに送信される。セッション識別子、例えばＲＴＳＰセッション識別子もまた、複製メッセージに含まれてよい、或いは、上述のように、ノードが２つのセッション識別子間のつながり又は関係を格納するケースにおいて、新たなセッション識別子が用いられてよい。
【００４９】
当然ながら、これらの一実施形態に従ってこれらの間でセッションが再開される端末は、ＩＭＳ機能を自身が有する又はＩＭＳゲートと接続を介してＩＭＳ機能を有する限り、同じ家庭内に位置することができ、１又は２以上のモバイル端末を含むことができ、或いは、異なる送り先に位置していてもよい。
【００５０】
前述の一実施形態の多くのバリエーションが考えられる。上述の一実施形態は、本発明を限定するのではなく、むしろ全ての観点において例示することを意図している。かくして本発明は、詳細な実装において、当業者にとってここに含まれる記述から派生しうる多くのバリエーションをとることが可能である。全てのそのようなバリエーション及び変形は、続く特許請求の範囲により定義されるような本発明の範囲及び思想の範疇と考えられる。本明細書中の記述において用いられる要素、動作、又は命令は、明示的にそう記述されていない限り、本発明に重要である又は本質的であると解釈すべきではない。また、ここで用いられる冠詞「ａ」は、１又は複数のアイテムを含むことを意図する。
【図１】
0005647133.tif 000002
【図２】
0005647133.tif 000003
【図３】
0005647133.tif 000004
【図４】
0005647133.tif 000005
【図５】
0005647133.tif 000006
【図６】
0005647133.tif 000007
【図７ａ】
0005647133.tif 000008
【図７ｂ】
0005647133.tif 000009
【図７ｃ】
0005647133.tif 000010
【図８】
0005647133.tif 000011
【図９ａ】
0005647133.tif 000012
【図９ｂ】
0005647133.tif 000013
【図９ｃ】
0005647133.tif 000014
【図１０】
0005647133.tif 000015
【図１１】
0005647133.tif 000016
【図１２】
0005647133.tif 000017
【図１３】
0005647133.tif 000018