JP5452821B2 - デバイス間のメディアおよび／またはメディア移転を実装するためのシステムおよび方法 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６１／１７５，３９４号（２００９年５月４日出願、本願と同名称）に基づく優先権を主張し、該出願は、参照により本明細書に引用される。

（技術分野）
本開示は、概して、移動通信システムにおけるセッションのためのメディアおよび／または制御機能管理に関し、より具体的には、デバイス間のメディアおよび／または制御機能移転を実装するためのシステムおよび方法に関する。

本明細書で使用される場合、「デバイス」という用語は、固定および携帯電話、携帯情報端末、手持ち式またはラップトップコンピュータ、スマートフォン、プリンタ、ファクス機、テレビ、セットトップボックス、および他のビデオ表示デバイス等の電子デバイス、家庭用音響機器および他の家庭用娯楽システム、家庭用監視および制御システム（例えば、家庭監視、アラームシステム、および気候制御システム）、コンピュータ化された冷蔵庫等の進化型家庭用電化製品、およびネットワーク通信能力を有する同様のデバイスを含むことができる、「移動局」（ＭＳ）、「ユーザエージェント」、または「ユーザ機器」（ＵＥ）という用語を指すことができる。いくつかの構成では、ＵＥは、移動無線デバイスを指し得る。移動無線デバイスである、そのようなＵＥは、デバイスの内部にあるか、または取り外すことができる、メモリモジュールを含んでも含まなくてもよく、例は、加入者識別モジュール（ＳＩＭ）、またはおそらくＩＳＩＭアプリケーション、コンパクトフラッシュ（登録商標）、マイクロＳＤ、Ｒ−ＵＩＭ等を含む、ＵＩＣＣカード等であるが、それらに限定されない。ＳＩＭ／ＵＩＣＣ機能性はまた、ソフトウェアダウンロード可能なＳＩＭ／ＵＩＣＣセキュリティソフトウェアによって提供され得る。該用語はまた、デスクトップコンピュータ、セットトップボックス、ＴＶ、ＩＰＴＶ、またはネットワークノード等の、同様の能力を有するが容易に運搬可能ではないデバイスを指し得る。デバイスという用語はまた、固定型または移動性であり得る、ＳＩＰユーザエージェント（ＵＡ）という用語も対象とする。ＵＡがネットワークノードである時、ネットワークノードは、ＵＡまたは固定回線デバイス等の別の機能に代わって作用し、ＵＡまたは固定回線デバイスをシミュレートまたはエミュレートすることができる。例えば、いくつかのＵＡについて、典型的にはデバイス上に常駐するＩＭＳ ＩＰクライアントは、実際にネットワーク内に常駐し、最適化されたプロトコルを使用して、デバイスにＳＩＰメッセージ情報を中継する。言い換えれば、伝統的にＵＡによって実行された、いくつかの機能は、遠隔ＵＡの形態で分布することができ、その場合、遠隔ＵＡは、ネットワーク内のＵＡを表す。「ＵＡ」という用語はまた、ＳＩＰセッションを含むことができるが、それに限定されない通信セッションを終了させることができる、任意のハードウェアまたはソフトウェア構成要素も指すことができる。また、「ユーザエージェント」、「ＵＡ」、「ユーザ機器」、「ＵＥ」、および「ノード」という用語は、本明細書中で同義的に使用される場合がある。当業者であれば、これらの用語を本願内で交換可能に使用できることを理解するであろう。

ＵＥは、高速データ通信を提供する無線通信ネットワーク内で動作し得る。例えば、ＵＥは、グローバルシステムフォーモバイルコミュニケーションズ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ／ＧＳＭ（登録商標））および汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ／ＧＰＲＳ）技術に従って動作し得る。現在、そのようなＵＥはさらに、ＧＳＭ（登録商標）進化型高速データレート（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ（登録商標） Ｅｖｏｌｕｔｉｏｎ／ＥＤＧＥ）、または進化型ＧＰＲＳ（Ｅｎｈａｎｃｅｄ ＧＰＲＳ／ＥＧＰＲＳ）あるいは進化型ＧＰＲＳフェーズ２（Ｅｎｈａｎｃｅｄ ＧＰＲＳ Ｐｈａｓｅ ２／ＥＧＰＲＳ２）に従って動作し得る。ＵＥが動作し得る他の無線ネットワークは、ＣＤＭＡ、ＵＭＴＳ、Ｅ−ＵＴＲＡＮ、ＷｉＭａｘ、およびＷＬＡＮ（例えば、８０２．１１）を含むが、それらに限定されない。ＵＥはまた、ｘＤＳＬ、ＤＯＣＳＩＳケーブルネットワーク、イーサネット（登録商標）、または他の光ネットワーク等の固定ネットワーク環境内で動作し得る。いくつかのＵＥは、ある時に単一のアクセスネットワーク上、または同時に複数のアクセス技術を使用するいくつかのデバイスにおいて、２以上のアクセスネットワーク技術で動作することができるマルチモード動作が可能であり得る。

ＥＤＧＥ／ＥＧＰＲＳ／ＥＧＰＲＳ２は、増加したデータ伝送速度および向上したデータ伝送信頼性を可能にする、デジタル移動通信技術の例である。ネットワークはしばしば、２．７５Ｇネットワーク技術として分類される。ＥＤＧＥは、最初は北米で、約２００３年以来、世界中でＧＳＭ（登録商標）ネットワークに導入されてきた。ＥＤＧＥ／ＥＧＰＲＳ／ＥＧＰＲＳ２は、インターネット接続を伴うもの等の任意のパケット交換用途で使用され得る。ビデオおよび他のマルチメディアサービス等の高速データ用途は、ＥＧＰＲＳの増加したデータ容量から利益を得る。ＵＥはまた、Ｗｉｍａｘ、Ｗｉｆｉ等であるがそれらに限定されない、他の無線技術で動作し得る。

通信ネットワークがますます複雑になるにつれて、ネットワークインフラストラクチャは、単一の電話回線、携帯電話、または他のＵＥに一意的にマップする、電話番号等の単一の識別という電話ベースの概念から離れつつある。例えば、セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）および他の関連インターネットベースの通信技術は、ネットワークへの複数のデバイスの登録をサポートし、各デバイスは、同じユーザ識別（例えば、ＳＩＰまたは電話ユニフォームリソース識別子（Ｔｅｌ Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ／ＵＲＩ）、または重複あるいは同一の識別群を共有する。この識別群は、暗示的登録セット（Ｉｍｐｌｉｃｉｔ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｓｅｔ／ＩＲＳ）と呼ばれる。通信ネットワークの進化と一致して、ＳＩＰはまた、ネットワークとＵＥとの間に確立された同じセッション内で、テキスト、アプリケーション用のデータ、音声およびビデオ等を含むが、それらに限定されない種々のメディア種類をサポートすることも可能である。当業者であれば、デバイス／ＳＩＰ ＵＡは、ビデオをサポートする小型スクリーンまたはＨＤＴＶをサポートするＩＰＴＶ等の異なる能力を有することができると理解するであろう。したがって、ビデオおよび音声構成要素を有した小型画面上で開始された２つ以上のデバイス／ＳＩＰ ＵＡの間のセッションが、ユーザがそれの近くにいた場合に、そのビデオ構成要素をＨＤＴＶに移動させた可能性があれば、有利となるであろう。この能力は、ＵＥ間移転（Ｉｎｔｅｒ ＵＥ Ｔｒａｎｓｆｅｒ／ＩＵＴ）と呼ばれ、３ＧＰＰ ＴＳ ２３．２３７および３ＧＰＰ ＴＳ ２４．２９２で定義されている。

ＩＵＴ、ＰＮＭ、またはＢｌａｃｋＢｅｒｒｙ Ｕｎｉｔｅのような他のサービスにおいてネットワークおよび関連デバイスの効果的な動作を提供するために、いくつかのネットワークは、デバイス、または、それぞれネットワークサーバと関連する標的ＵＥ群内で送達することができるセッションを管理する能力を有する管理者またはコントローラＵＥを含む。その場合、管理者またはコントローラＵＥは、１つ以上の他のＵＥを介して利用可能となる種々の特徴／パラメータの動作を管理するように構成され得る。場合によっては、コントローラ機能は、コントローラＵＥから、コントローラ機能性を提供する能力を有する別のＵＥに移転され得る。場合によっては、複数のＵＥがコントローラの役割を果たし得る。場合によっては、コントローラＵＥは、パーソナルネットワーク管理（Ｐｅｒｓｏｎａｌ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ／ＰＮＭ）コントローラ機能性を実装し得る。場合によっては、ＵＥは、アクセスネットワークにつき１つ、複数のユーザエージェントを有する。同様に、管理者またはコントローラＵＡは、１つ以上の他のＵＡを介して利用可能となる種々の特徴またはパラメータの動作を管理するように構成され得る。管理者またはコントローラＵＡはまた、管理者またはコントローラＵＥであり得る。以下では、ＵＥおよびＵＡという用語はしばしば、文脈から明白ではない限り、交換可能に使用される。

ＳＩＰは、ＵＥが、送信者の識別に応じて、どのＵＥに通信がアドレス指定されるかに基づいて、通信フィルタリングおよびサービスの転換を通知され得るように構成されることを可能にする。例えば、ユーザは、ユーザの携帯電話において直接ユーザに連絡するよう、特定の公衆ユーザ識別（家庭用電話番号またはＥメールアドレス等）が家族に提供されることを可能にするように電話／通信転送サービスを構成し得、友人または家族が、個人用音声メールに転送され得る一方で、同僚は、最終的に企業用音声メールに転送するオフィス用電話に転送される。

そのようなものとして、ＳＩＰは、ユーザが複数のＵＥにわたって一貫した識別を有することを可能にし、ＵＥは、家庭用電話、個人用携帯電話、仕事用電話、企業用携帯電話、別荘用電話、ラップトップコンピュータボイスオーバーＩＰ（ＶｏＩＰ）クライアント、ファクス機等を含み得る。一貫した公衆ユーザ識別はまた、現在、いずれのＵＥをユーザが偶然使用していようと、ユーザが連絡可能となることを可能にする。この融通性は、アドレス帳の中の各ユーザを識別するために、デバイス指向の連絡先の広範なリストを維持すること、通信を確立しようとする場合に、どのデバイスが最良であるかを決定しなければならないことの必要性を最小限化し、各ユーザ（および全ての関連携帯電話、家庭用電話、コンピュータ等）が、単一の識別によって識別され得る。従って、ネットワークおよび／または終端ユーザに関する単一の識別のみを使用して、その個人に連絡する際に使用するための最も適切なＵＥを決定し、誰かと通信することが可能である。

ＳＩＰを実装し、管理者またはコントローラＵＥを有するネットワークでは、種々のメディア種類を含み得る、コンテンツを処理する最良の能力を有するＵＥに対して、新しいセッションが確立されることを確実にすることが望ましい。例えば、ビデオコンテンツを表示するための手段を持たない、またはテレビあるいはコンピュータ画面／モニタがユーザによる使用のために利用可能である時に非常に小さいビデオ画面を有する、従来のオフィス用電話上でビデオコンテンツを含むメディアを受け入れることは、最も適切ではないであろう。さらに、ＵＥが、１つ以上のメディア種類を使用するセッションにすでに関与しており、ＵＥがセッションに１つ以上のメディア種類を追加または修正する招待を受信すると、ユーザが、新しいメディア種類をサポートし、処理またはレンダリングすることができる異なるＵＥに、新しいメディア種類を移転するように要求することができるように、コントローラＵＥが識別されるべきである。例えば、ユーザがユーザの携帯電話上で音声セッションに従事し、ユーザが別のデバイス上で追加されたビデオストリーミングメディアを受け入れることを希望する場合、コントローラＵＥは、デバイス能力およびユーザ選好等に基づいて、追加されたビデオストリーミングメディアを受信し、表示するために、ラップトップＰＣ等の別のデバイスを選択する能力をユーザに提供する。

加えて、ユーザは、セッションの時間中に、セッションのコントローラに異なるデバイスを使用し得る。例えば、ユーザは、外の庭で、セッションまたはセッションの１つ以上のメディア構成要素を携帯電話上で受け入れ、次いで、家の中に移動し、音声およびビデオ構成要素の両方をデスクトップコンピュータに移転し得、ここでユーザは、デスクトップコンピュータからセッションを制御することを希望するため、携帯電話からデスクトップコンピュータにセッションの制御も移転する。最後に、コントローラとしての機能性は、コントローラデバイスとなることが可能である一定のメンバーＵＥ間でのみ移転され（例えば、基本的なテレビは、ユーザと相互作用してコントローラ機能性を果たす能力を有する可能性が低い）、ネットワークによってコントローラ機能を受け取るための権限を与えられるべきである。したがって、異なる加入者（例えば、家庭用電話およびテレビ等の共有デバイス）によって潜在的に使用することができる一式のＵＥの間で、セッション、メディア、およびコントローラ機能性の移転要求を配信し、処理するように、確実な機構を提供することが重要である。

本開示は、移動通信システムにおけるメディアおよび／または制御機能管理のためのシステムおよび方法、より具体的には、デバイス間のメディア移転および／または制御機能移転を実装するためのシステムおよび方法を提供することによって、前述の欠点を克服する。

一実施例では、第１のユーザ機器（ＵＥ）から、おそらく同じ団体に属する第２のＵＥにコントローラ機能を移転する方法は、第１のＵＥと第３のＵＥとの間でメディアコンテンツを伝達するためのセッションを確立することを含む。第１のＵＥは、最初に、セッションに対するコントローラ機能が割り当てられる。方法は、セッションに対するコントローラ機能の少なくとも一部を第２のＵＥに移転するための要求を第１のＵＥから受信することと、コントローラ機能を実装するための第２のＵＥの能力を決定することとを含む。第２のＵＥがコントローラとして動作する能力を有する場合に、方法は、セッションに対するコントローラ機能の少なくとも一部を第２のＵＥに割り当てることと、セッションに対するコントローラ機能の少なくとも一部を移転するための要求に応答して、第１のＵＥにセッションを解放するように通知することとを含む。

別の実施例では、第１のユーザ機器（ＵＥ）から第２のＵＥにコントローラ機能を移転する方法は、第１のＵＥと第３のＵＥとの間でメディアコンテンツを伝達するためのセッションを確立することを含む。第１のＵＥは、最初に、セッションに対するコントローラ機能が割り当てられ、第１のＵＥは、インターフェースを含む。方法は、第１のＵＥインターフェースを介して、第２のＵＥにセッションに対するコントローラ機能を移転するための要求を受信することと、セッションコントローラ機能移転要求をアプリケーションサーバに伝送することと、アプリケーションサーバから移転応答を受信することとを含む。第１のＵＥがセッションコントローラ機能を解放するべきであると移転応答が示す場合に、方法は、セッションコントローラ機能を解放することを含む。

別の実施例では、第１のユーザ機器（ＵＥ）と第３のＵＥとの間でメディアコンテンツを伝達するためのセッションを移転する方法は、第１のＵＥにセッションに対するコントローラ機能を割り当てることと、メディアコンテンツを伝達するためのセッションを第２のＵＥに移転するための要求を第１のＵＥから受信することと、メディアコンテンツを伝達するためのセッションを受信するための第２のＵＥの能力を決定することとを含む。第２のＵＥがメディアコンテンツを伝達するためのセッションを受信する能力を有する場合に、方法は、メディアコンテンツを伝達するためのセッションを第２のＵＥに移転することと、メディアコンテンツを伝達するためのセッションを第２のＵＥに移転するための要求に応答して、第１のＵＥにセッションを解放するように通知することとを含む。

ここで、本開示のより完全な理解のために、添付の図面および発明を実施するための形態と関連して、以下の簡単な説明を参照し、類似参照数字は、類似部品を表す。
図１は、ネットワークと関連付けられたＵＥの間でメディアおよびＩＵＴコントローラ機能を移転するフロー例を図示する。 図２は、ネットワークに接続されたＵＥの間でＩＵＴメディアおよび／またはコントローラ機能を果たすために本システムを実装するための例示的な通信ネットワークを図示する。 図３は、ＵＥをＩＭＳネットワークに登録してＳＣＣ ＡＳへの登録を引き起こすためのフロー例を図示する。 図４は、コントローリＵＥ、またはコントローラＵＥおよびコントローリＵＥの両方を含む、１つ以上のＩＵＴ可能ＵＥを識別するための例示的な許容ＩＵＴリスト管理オブジェクトを図示する。 図５ａおよび５ｂは、図４に示された例示的な許容ＩＵＴリストＭＯのパラメータおよびＤＤＦを図示する。 図５ａおよび５ｂは、図４に示された例示的な許容ＩＵＴリストＭＯのパラメータおよびＤＤＦを図示する。 図５ａおよび５ｂは、図４に示された例示的な許容ＩＵＴリストＭＯのパラメータおよびＤＤＦを図示する。 図６は、承認が単一のコントローラＵＥのみから要求される、ＩＵＴコントローラ機能をＵＥに提供するためのフロー例を図示する。 図７は、承認が１つより多くのコントローラＵＥのみから要求される、ＩＵＴコントローラ機能をＵＥに提供するためのフロー例を図示する。 図８は、ＩＵＴコントローラＵＥによって要求されるように、メディアＡおよびコントローラ機能をＵＥに移転するためのフロー例を図示する。 図９は、ＵＥ−１からＵＥ−２にメディアＡおよびコントローラ機能を移転するためのフロー例を図示し、着信セッション要求は、コントローラ機能識別子を含み、Ｇｍ参照点上で送達され、メディアＡは、回路交換ネットワークを介して伝送される。 図１０は、ＵＥ−１からＵＥ−２にメディアＡおよびコントローラ機能を移転するためのフロー例を図示し、着信セッション要求は、コントローラ機能識別子を含み、Ｉ１参照点上で送達され、メディアＡは、ＣＳネットワークを介して伝送される。 図１１は、ユーザと関連付けられた複数のＵＥを図示し、協調セッションがＵＥの一部の間で確立されている。 図１２ａおよび１２ｂは、セッション招待要求を受信する時に協調セッション確立を終了させるためのフロー例を図示する。 図１２ａおよび１２ｂは、セッション招待要求を受信する時に協調セッション確立を終了させるためのフロー例を図示する。 図１３は、第１のＰＳ ＵＥから第２のＰＳ ＵＥにＩＵＴコントローラ機能性を移転するためのフロー例を図示し、第１および第２のＵＥは、同じベアラまたは異なるベアラを使用し得る。 図１４は、Ｇｍ参照点を使用した、協調セッション内の別のＵＥへのメディア／コントローラ機能性移転のための代替メッセージフローの説明図である。 図１５は、Ｉ１参照点を使用した、協調セッション内の別のＵＥへのメディア／コントローラ機能性移転のための代替メッセージフローの説明図である。 図１６は、コントローラが開始した進行中セッション情報移転のための代替メッセージフローの説明図である。 図１７は、ユーザエージェントの実施形態を含む、無線通信システムを図示する。 図１８は、デジタル信号プロセッサ（ＤＳＰ）およびメモリを含む、ユーザエージェントのブロック図を示す。 図１９は、ユーザエージェントのプロセッサによって実装され得る、ソフトウェア環境を図示する。 図２０は、ネットワーク間のセッション遷移の機会を提供する方法を実装するために好適な処理構成要素を含む、システムの実施例を図示する。 図２１は、関連コントローラおよびコントローリＵＥを表すネットワーク内で情報を記憶するための例示的な構造の説明図である。 図２２は、ＨＳＳ内等のネットワークに記憶された例示的な情報の説明図である。 図２３は、参照ビット値位置を伴う指標例の説明図である。

ここで、付属の図面を参照して本開示の種々の側面を説明し、類似数字は、全体を通して類似または対応する要素を指す。しかしながら、図面およびそれに関する詳細な説明は、請求された主題を開示される特定の形態に限定することを目的としていないことを理解されたい。むしろ、請求された主題の精神および範囲に入る全ての修正、同等物、および代替案の全てを対象とすることを意図する。

本明細書で使用される場合、「構成要素」、「システム」等の用語は、コンピュータ関連エンティティ、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアを指すことを目的としている。例えば、構成要素は、プロセッサ上で作動するプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／またはコンピュータであり得るが、それらに限定されない。例証として、コンピュータ上で作動するアプリケーションおよびコンピュータの両方が、構成要素であり得る。１つ以上の構成要素がプロセスおよび／または実行のスレッド内に常駐し得、１つの構成要素が、１つのコンピュータ上に限局され、および／または２つ以上のコンピュータ間に分布され得る。

「例示的な」という言葉は、実施例、例、例証としての機能を果たすことを意味するために、本明細書で使用される。「例示的な」として本明細書で説明される任意の側面または設計は、必ずしも他の側面または設計と比べて好ましい、または有利として解釈されるわけではない。

さらに、開示された主題は、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを生産して、本明細書で詳述される側面を実装するようにコンピュータまたはプロセッサベースのデバイスを制御するために、標準プログラミングおよび／または工学技法を使用して、システム、方法、装置、または製造品として実装され得る。本明細書で使用されるような「製造品」（または代替として、「コンピュータプログラム製品」）という用語は、コンピュータ可読デバイス、キャリア、またはメディアからアクセス可能なコンピュータプログラムを包含することを目的としている。例えば、コンピュータ可読媒体は、磁気記憶デバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気帯、および同等物）、光ディスク（例えば、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）、および同等物）、スマートカード、およびフラッシュメモリデバイス（例えば、カード、スティック、および同等物）を含むことができるが、それらに限定されない。加えて、電子メールを送受信する際に、またはインターネットあるいはローカルエリアネットワーク（ＬＡＮ）等のネットワークにアクセスする際に使用されるデータ等の、コンピュータ可読電子データを搬送するために、搬送波を採用できることを理解されたい。当然ながら、当業者であれば、請求された主題の範囲または精神から逸脱することなく、多くの修正がこの構成に行われ得ることを認識するであろう。

本システムは、通信ネットワークと関連付けられたデバイス間でメディア移転または制御機能移転を実装するためのメディアおよび／または制御機能管理を提供する。１つの実装では、システムは、１つ以上のコントローラＳＩＰ ＵＡまたはＵＥから、１つ以上のコントローリＳＩＰ ＵＡまたはＵＥへ、セッションの１つ以上のメディア構成要素、またはいくつかあるいは全てのメディアフロー、および／またはコントローラ機能（ＩＵＴコントローラ）を移転するために、３ＧＰＰ ＴＳ ２３．２３７によるＵＥ間移転（ＩＵＴ）を行う。システムは、種々の通信ネットワークで実装され得、ＵＥは、単一の共有識別（例えば、Ｔｅｌ ＵＲＩ、ＳＩＰ ＵＲＩ、ＭＳＩＳＤＮ、Ｃ−ＭＳＩＳＤＮ、ＧＲＵＵ（Ｇｌｏｂａｌｌｙ Ｒｏｕｔａｂｌｅ Ｕｓｅｒ Ａｇｅｎｔ ＵＲＩ：グローバルにルーティング可能なユーザエージェントＵＲＩ）等）が割り当てられるか、またはネットワークと関連付けられた他のＵＥと重複する識別情報を有するように構成される。ネットワーク内では、各ＵＥは、種々の通信セッションを開始し得、各セッションは、アプリケーション用のデータ（メディア種類アプリケーション）、声、テキスト、ビデオ（種々の符号化スキームを含む）、および音声等であるが、それらに限定されない複数のメディア種類を含み得る、データの通信を伴う。

１つの構成では、システムは、ＳＩＰをサポートし、非コントローラまたはコントローリＳＩＰ ＵＡあるいはＵＥに加えて、種々の管理者またはコントローラＳＩＰ ＵＡあるいはＵＥを有する、ネットワークを介して実装される。コントローラ機能は、それらに限定されないが、ネットワーク規則、操作者方針、ユーザ選好、または他のシステム要件に応じで、第１のコントローラＵＥから別のＵＥに移動されられ得る。場合によっては、コントローラまたはコントローリ機能を有するＵＥは、ネットワークを介して提供され得、コントローリＵＥは、同様の機能的能力およびシステム設計を有するコントローラＵＥと同様に構成される。ＵＥの中の１つのＵＥが最初にネットワークに登録されると、無線サーバに登録されたコントローラ機能性をサポートする第１のＵＥは、自動的に管理者またはコントローラＵＥとして指定され得る。場合によっては、ネットワークが、コントローラ機能性をサポートするＵＥによって送信された協調セッションに対する初期移転要求を受信すると、ＵＥは、自動的に管理者またはコントローラＵＥとして指定され得る。しかしながら、ＵＥの集合の中の予備コントローラＵＥを決定するために、他のアルゴリズムが採用され得る。ネットワークに接続した後、ユーザは、随意で、ユーザによる、または他の関連ユーザによる制御下で、第１の登録されたＵＥから他の登録されたＵＥのうちの１つにコントローラ指定を変更し得る。

本システムを使用して、それぞれ共通の識別を共有する、複数のＵＥを伴うユーザに役立つネットワークは、種々のメディア種類を含むセッションに参加する招待を受信し得る。招待を受信した後、ネットワークは、招待に説明されたメディア種類、ユーザによって特定された好ましいＵＥ、またはコントローラＵＥあるいはネットワークに利用可能な他の情報に従って、セッション招待（例えば、ＳＩＰ ＩＮＶＩＴＥ、またはＳＩＰ Ｒｅ−ＩＮＶＩＴＥ）をユーザのＵＥに移転、転送、または送信する。ユーザが、種々のメディア種類を使用したセッションにすでに関与し、申し入れ（例えば、セッション記述プロトコル（ＳＤＰ ＯＦＦＥＲ））が、１つ以上のメディア種類を追加、削除、または修正する同じセッションに対して受信された場合、新しいメディア種類およびセッション制御機能を異なるＵＥに移転するコントローラＵＥが識別され得る。

１つの実装では、ＵＥ（例えば、ＩＣＳ ＵＥ）が、ＩＰベアラを使用してセッションを確立するためのＳＤＰを含むＳＩＰ ＩＮＶＩＴＥ要求を受信すると、ＩＣＳ ＵＥは、３ＧＰＰ ＴＳ ２４．２２９に従うが、以下の明細に従ってセッションを確立する。第１に、ＳＩＰ ＩＮＶＩＴＥ要求が、ＩＣＳ ＵＥと、サービス一貫性および連続性アプリケーションサーバ（ＳＣＣ ＡＳ）との間の既存のダイアログ（または確立されつつあるダイアログ）に対応する、ダイアログパラメータを含むＴａｒｇｅｔ−Ｄｉａｌｏｇヘッダを含む場合、ＩＣＳ ＵＥは、Ｔａｒｇｅｔ−Ｄｉａｌｏｇヘッダに含まれたダイアログパラメータによって識別されるダイアログと同じセッションの一部である、別のダイアログとしてＳＩＰ ＩＮＶＩＴＥ要求を扱う。第２に、ＳＩＰ ＩＮＶＩＴＥ要求が、Ｔａｒｇｅｔ−Ｄｉａｌｏｇヘッダを含まないが、ＩＣＳ ＵＥとＳＣＣ ＡＳとの間に既存のダイアログ（または確立されつつあるダイアログ）がある場合、ＳＣＣ ＡＳは、この要求に対するダイアログパラメータが、ＩＣＳ ＵＥとＳＣＣ ＡＳとの間の既存のダイアログ（または確立されつつあるダイアログ）上で受信されるＴａｒｇｅｔ−Ｄｉａｌｏｇヘッダの中で受信されるダイアログパラメータに対応するかどうかをチェックすることができ、もしそうであれば、ＩＣＳ ＵＥは、Ｔａｒｇｅｔ−Ｄｉａｌｏｇヘッダが受信されたダイアログと同じセッションの一部である、別のダイアログとしてＳＩＰ ＩＮＶＩＴＥ要求を扱うことができる。この第２の明細は、要求が送信された順番外で着信する可能性を対象とし得る。

本システムに従ってＩＵＴを実装するように構成されるコントローラＵＥは、異なるＵＥ上で新しいアクセスレッグを作成することによって１つ以上のメディアフローをセッションに追加すること、異なるＵＥ上の既存のアクセスレッグ上で１つ以上のメディアフローをセッションに追加すること、異なるＵＥ上のアクセスレッグ上でセッションから１つ以上のメディアフローを除去すること、異なるＵＥ上でＭＭＴｅｌサービス制御にメディアを提供すること（例えば、３ＧＰＰ ＴＳ ２２．１７３参照）、および異なるＵＥ上でメディア特性の更新を提供することといった、１つ以上を行うように構成され得る。したがって、各コントローラＵＥは、ＳＣＣ ＡＳ等の特定のネットワークエンティティまたはノードと固着された１つ以上のセッションを提供する、協調セッションを確立および／または解放するように構成され得る。進行中の協調セッションを維持しながら、各コントローラＵＥは、協調セッションのメディアフローを標的ＵＥに移転し得る。さらに、各コントローラＵＥは、協調セッションを確立して、または確立せずに、利用可能な１つ以上のメディアフローの全てまたはいくつかを標的ＵＥに移転するように構成され得る。全てのメディアフローを標的ＵＥに移転する場合、コントローラＵＥ上の既存のセッションが解放され得る。

１つのシステム実装例では、ＵＥ間移転（ＩＵＴ）を実装するためには、ＳＣＣ ＡＳは、ＵＥ間移転の実行のためにＳ−ＣＳＣＦに向けたＩＳＣ参照点を使用する。例えば、ＩＵＴの使用可能性および実行のために、ＳＣＣ ＡＳは、最初に、以下で説明されるようなＵＥ間移転に必要とされる情報を分析し、操作者方針およびユーザ選好に基づいて、どのアクセスネットワークが実行されるべきかを決定し得る。次いで、ＳＣＣ ＡＳは、操作者方針と整合しなければＵＥ間移転を拒絶し得る。ＳＣＣ ＡＳは、登録後に、ホーム加入者サーバ（ＨＳＳ）から、ＨＳＳの中のユーザプロファイルに記憶されたＩＭＳプライベートユーザ識別に結びつけられたＣ ＭＳＩＳＤＮを回収し、第三者登録後に、ＨＳＳから、ＨＳＳの中のユーザプロファイルに記憶されたＩＭＳプライベートユーザ識別に結びつけられた、ＵＥ間移転のためのコントローラ機能性を回収し得る。ＳＣＣ ＡＳはまた、ＵＥが許可され、ＵＥ間移転のためのコントローラ機能性が可能であるかどうかを決定し、着信ＳＩＰ ＩＮＶＩＴＥまたは着信ＵＥ間移転要求の中で提供される情報を使用して、ＵＥ間移転要求を固着セッションと相関させ、同じまたは異なるアクセスネットワークを介して接続された同じＩＭＳサブスクリプションに属する異なるＵＥ間でＩＭＳ ＵＥ間移転を実行し得る。ＳＣＣ ＡＳはまた、ＩＵＴ移転特有の課金データを提供し、コントローラＵＥに移転可能なＵＥの情報を提供し、種々のサービス連続性関連入力因子の分析に基づいて、ＵＥ間移転のための設定された操作者方針を更新するかどうかを決定し得る。ＳＣＣ ＡＳはまた、ＯＭＡ ＤＭを介して操作者方針（進行中のセッションのためのＵＥ間移転手順を開始するためにも使用することができる操作者方針とユーザ選好との間の優先順位を含む）をＵＥに送信することによって、ＵＥ間移転のための操作者方針を生成して更新し、および、終端コントローラＵＥがＵＥ間移転を開始することができるように、リモートパーティからの受信された着信セッション招待をコントローラＵＥに送信するかどうかを決定し得る。

概して、ＳＣＣ ＡＳは、セッション移転、セッション終了のために必要に応じて、あるいはセッションの設定中に追加のアクセスネットワーク上でメディアフローを追加するためのＵＥによる要求に応じて、あるいは１つ以上のアクセスネットワーク上で既存のセッションに対するメディアフローを追加および／削除するＵＥによる要求に応じて、１つ以上のアクセスネットワーク上でメディアフローを組み合わせるため、および／または分割するための機能性を提供する。

ＩＭＳセッションのメディアフローを処理する場合に、ＳＣＣ ＡＳは、セッションと関連付けられたサービスを考慮し得る。

特定のアクセスレッグ上でＳＩＰ ＭＥＴＨＯＤ（ＳＩＰ ＩＮＶＩＴＥ等）を送るために、そのアクセスレッグに対応する特定の登録フローを識別することが必要である。

Ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｏｕｔｂｏｕｎｄは、要求がＵＡまたはＵＥに到達に到達することができる複数の登録フロー上で、どのようにしてＳＩＰ ＵＡまたはＵＥが登録できるかを説明する。３ＧＰＰ ＩＭＳでサポートされているように、ＵＥは、異なるアクセスネットワーク上で異なるフローを使用して登録するために、Ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｏｕｔｂｏｕｎｄで定義される機構を使用する。異なるアクセスネットワーク上の各フローは、Ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｏｕｔｂｏｕｎｄで定義されるように、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中に異なる「ｒｅｇ−ｉｄ」コンタクトヘッダパラメータを含み得る。登録する場合に、ＵＥは、３ＧＰＰ ＴＳ ２４．２２９で説明されているように、ＳＩＰ ＲＥＧＩＳＴＥＲ要求にＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダを含む。３ＧＰＰ ＴＳ ２４．２２９による拡張Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダフィールドの構文例が、表１に示されている。

Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏの構文から分かるように、ａｃｃｅｓｓ−ｔｙｐｅは、ＳＩＰ ＲＥＧＩＳＴＥＲ要求が送られるネットワークによって使用されるアクセスネットワーク技術を示す。しかしながら、「ｒｅｇ−ｉｄ」パラメータは登録フローを一意的に識別するが、特定の登録フロー上でＳＩＰ ＩＮＶＩＴＥ等のＳＩＰ ＭＥＴＨＯＤが方向付けられることを、ネットワークが指図することを可能にする現在の機構はない。これを可能にするためには、登録フローを識別するメディア特徴タグを定義し、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダに含むことが可能である（「ｒｅｇ−ｉｄ」パラメータはメディア特徴タグではない）。以下は、そのようなメディア特徴タグの２つの可能な実施形態の実施例である。当業者であれば、ＳＩＰ ＵＡ／ＵＥから同じ意味を伝えるために、適切な英数字の任意の構成を使用できることを理解するであろう。

表２に示された第１の実施例では、文字列がフローを識別するメディア特徴タグに含まれることを可能にする、特徴タグｇ．３ｇｐｐ．ｉｃｓｆｌｏｗが定義されている。この文字列は、「ｒｅｇ−ｉｄ」パラメータと同じ識別子値（例えば、ｇ．３ｇｐｐ．ｉｃｓｆｌｏｗ＝［ｒｅｇｉｄ］）を含むことができ、または何らかの他の文字列を含むことができるが、１つの実装では、文字列は、各登録フローに対して異なる必要がある。ユーザが、メディア移転を行う場合に、どのアクセスレッグにメディア種類を移転することを希望をするかを示す（例えば、「ｉｎｔｅｒｎｅｔ」、「ｃａｂｌｅＴｖ」、「ｃｅｌｌｕｌａｒ」、「ＷＬＡＮ」）ために、これらの標識を使用する必要があり得るため、ＵＥは、ユーザが、メディア特徴タグで使用される文字列に人間が理解可能な標識を定義することを可能にすることができる。

表３に示された別の実施例では、登録が直接携帯電話からであるか、またはネットワークノードからであるかを示し、また、どの登録フローが使用されているかを示すように、既存のｇ．３ｇｐｐ．ｉｃｓメディア特徴タグが強化されている。

ＵＥは、登録する場合に、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中に、上記で説明されるようなフローの一意的な識別子を含む、メディア特徴タグとともに、ＳＩＰ ＲＥＧＩＳＴＥＲ要求の中に、そのアクセスレッグ上で使用されるアクセス技術の識別を含む、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダを含む。

ＳＣＣ ＡＳまたは別のネットワークノードは、ＲＦＣ ３８６０または強化された第三者登録手順（例えば、第三者ＳＩＰ ＲＥＧＩＳＴＥＲ要求の本文に含まれる着信ＳＩＰ ＲＥＧＩＳＴＥＲ要求）の通りに、登録イベントパッケージに登録することによって、メディア特徴タグを取得することができる。Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダはまた、第三者ＳＩＰ ＲＥＧＩＳＴＥＲ要求からＳＣＣ ＡＳによって取得することもできる。

ＳＣＣ ＡＳはまた、例えば、３ＧＰＰ ＴＳ ２４．２２９で特定されるような任意の受信された第三者ＲＥＧＩＳＴＥＲ要求（例えば、第三者ＲＥＧＩＳＴＥＲ要求の本文に含まれる情報を含む）、３ＧＰＰ ＴＳ ２４．２２９で特定されるような任意の受信されたｒｅｇイベントパッケージ、または３ＧＰＰ ＴＳ ２９．３２８および３ＧＰＰ ＴＳ ２９．３２９で特定されるようなＳｈインターフェースからのＩＭＳ集中サービス（ＩＭＳ Ｃｅｎｔｒａｌｉｚｅｄ Ｓｅｒｖｉｃｅｓ／ＩＣＳ）特有の要件を実装するために必要とする、登録状態情報を取得し得る。これらの機構を使用して、ＳＣＣ ＡＳは、特定のＩＰ−ＣＡＮに対応する特定のフロー上で要求を送ることができるために、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダから、アクセス種類（ａｃｃｅｓｓ−ｔｙｐｅ）および存在する場合はアクセスクラス（ａｃｃｅｓｓ−ｃｌａｓｓ）値、ならびにｇ．３ｇｐｐ．ｉｃｓｆｌｏｗメディア特徴タグの値を取得し、アクセス種類（ａｃｃｅｓｓ−ｔｙｐｅ）および存在する場合はアクセスクラス（ａｃｃｅｓｓ−ｃｌａｓｓ）値を、ｇ．３ｇｐｐ．ｉｃｓｆｌｏｗメディア特徴タグの値と関連付けることができる。

ＳＣＣ ＡＳまたは別のネットワークノードは、メディア特徴タグから取得されたアクセスレッグ／フロー識別子と関連して、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダから取得されたアクセス種類および／またはアクセスクラス情報（おそらく関連位置情報を含む）を記憶する。Ｐ−ＣＳＣＦはまた、ネットワークによって検証され、「ｎｐ」（ネットワーク提供）パラメータを含むこと等によって示されるようなアクセスクラスおよびアクセス種類を含むＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダに、追加のアクセス種類またはアクセスクラス値を含むこともできることに留意されたい。可用性および操作者の方針に基づいて、ＵＥ提供Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダまたはネットワーク提供Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ、あるいは両方からのアクセス種類および／またはアクセスクラスは、メディア特徴タグから取得されたアクセスレッグ／フローと関連して記憶され得る。

ある提供されたメディア種類を含む要求が、あるアクセスレッグ上で送られることを、操作者方針またはユーザ選好あるいはユーザ構成に基づいて、ＳＣＣ ＡＳ（または別のネットワークノード）が決定する場合に、ＳＣＣ ＡＳ（または別のネットワークノード）は、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダからのアクセス種類および／またはアクセスクラスと関連して記憶されるメディア特徴タグから以前に取得された、アクセスレッグ／フロー識別子を取得する。次いで、ＳＣＣ ＡＳ（または別のネットワークノード）は、要求が送られるアクセスレッグに対するアクセス種類および／またはアクセスクラスと関連付けられたアクセスレッグ／フロー識別子に設定された値を有するメディア特徴タグ（例えば、ｇ．３ｇｐｐ．ｉｃｓｆｌｏｗ）を含む、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを要求の中に含める。「ｒｅｑｕｉｒｅ」および「ｅｘｐｌｉｃｉｔ」というパラメータもまた、随意で、アクセスレッグ／フロー識別子を含むメディア特徴タグと関連付けられたＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれ得る。結果として、要求は、ＲＦＣ ３８４１で説明されている機構を使用した所望のアクセスレッグを使用して、ＵＥに送られ、それに対応して、要求が受け入れられた場合、そのアクセスレッグを使用してメディアも確立される。

いくつかの実装では、ネットワーク操作者の方針は、操作者によってネットワーク内で設定され、例えば、初期プロビジョニング中に、またはＯＭＡデバイス管理を介して、ＵＥに伝達することができる。操作者方針は、方針が操作者によって更新される時はいつでも、ＯＭＡデバイス管理を介して、ＵＥに伝達され得る。

操作者方針は、それぞれのサポートされたメディアの種類、またはメディア群について、開始セッションおよびセッション移転に制限されるアクセスネットワークのリスト、開始セッションおよびセッション移転に対してＳＣ能力を有するＵＥによって使用されるべき好ましいネットワーク（優先順位での）のリスト、いつアクセスネットワークが利用可能になり、セッション移転が可能であるか、および、標的アクセスネットワークが利用可能になり、セッション移転が可能である場合に、ＳＣ能力を伴うＵＥが、現在のアクセスネットワークよりも高い優先順位を伴う標的アクセスネットワークにメディアフローを移転し始める「べきである（ｓｈａｌｌ）」／「はずである（ｓｈｏｕｌｄ）」／「得る（ｍａｙ）」かどうかを示し得る。「べきである（ｓｈａｌｌ）」を示すことによって、操作者は、可能な限り早く、ホーム操作者の好ましいアクセスネットワークのリストに従って、セッション移転を開始するようにＵＥに通告する。「はずである（ｓｈｏｕｌｄ）」を示すことによって、ローカル動作環境情報（Ｌｏｃａｌ Ｏｐｅｒａｔｉｎｇ Ｅｎｖｉｒｏｎｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）を考慮した後にセッション移転が可能であり、望ましい場合、操作者は、ホーム操作者の好ましいアクセスネットワークのリストに従って、セッション移転を開始するようにＵＥに推奨する。「得る（ｍａｙ）」を示すことによって、ローカル動作環境情報を考慮した後にセッション移転が可能であり、望ましい場合、操作者は、（構成されている時に）ユーザ選好に従って、セッション移転を開始するか否かをＵＥに自由に決定させる。ユーザ選好が構成されない時はいつでも、ＵＥは、ホーム操作者の好ましいアクセスネットワークのリストを考慮し得る。操作者方針はまた、部分的セッション移転の場合に、移転不可能なメディアフローを保持するか撤回するかを示し得る。概して、セッション移転のための操作者方針は、Ｔ−ＡＤＳのための操作者方針と一致する。

ユーザ選好は、例えば、好ましいアクセスを指示し得る。ローカル動作環境情報は、実装特異的であり得、無線環境情報、ＩＰ接続の質（ジッター、遅延、およびパケット損失）、用途特有の要件、メモリ考察、電力考察等の項目を備え得る。ＵＥは、どのアクセスを進行中のセッションに使用するかを決定する場合に、またはセッション移転を開始することを考慮する前に、操作者方針、ユーザ選好、およびローカル動作環境情報を考慮し得る。概して、アクセス移転のためのユーザ選好は、ネットワークに移転されない。

ＩＵＴについて、ＵＥは、Ｕｔインターフェースを介して、以下のユーザ選好をＳＣＣ ＡＳに示し得、ＳＣＣ ＡＳは、ＵＥがコントローラの役割を果たすことを許可され、そうすることができるかどうかを決定する場合、および、どのネットワークを着信セッションに使用するか、どのメディア種類をあるＵＥ上で伝送するか、およびリモートパーティからの着信セッション招待をコントローラＵＥに送信するかどうかを決定するために、コントローラＵＥの役割を果たす好ましいＵＥ、着信セッションのための好ましいアクセスネットワーク種類、ユーザの特定のＵＥ上で受信される好ましいメディア種類、およびコントローラＵＥ上でリモートパーティからの着信セッション招待を受信する選好といった、操作者方針およびユーザ選好を考慮し得る。

さらに、ＩＵＴについて、ＵＥは、概して、ＩＵＴコントローラまたはコントローリ機能性をサポートするように構成される。終端ＵＥの場合、ＵＥは、遠隔末端がセッション招待を送信する場合に、進行中セッションに対してＩＵＴを適用するために、コントローラＵＥになるように構成され得る。

メディア移転を行う場合に、メディアセッションが特定のアクセスレッグ上で１つ以上のメディア種類について確立されることをユーザが通告することを希望する場合、ユーザは、コントローラＵＥ上で、特定のメディア種類に使用することを希望するアクセスレッグを選択することによって、これを示すことができる。ユーザが、メディア移転を行う場合に、どのアクセスレッグにメディア種類を移転することを希望をするかを示す（例えば、「ｉｎｔｅｒｎｅｔ」、「ｃａｂｌｅＴｖ」、「ｃｅｌｌｕｌａｒ」、「ＷＬＡＮ」）ために、これらの標識を使用することができるように、ＵＥは、ユーザが、メディア特徴タグで使用される文字列に人間が理解可能な標識を定義することを可能にすることができる。代替として、デバイスは、アクセス種類を登録する場合に、ユーザが読み取ることができる人間に可読なアクセス種類と、デバイスがサポートするアクセス種類との間に、マッピングを提供する。実施形態例は以下であるが、当業者であれば、マッピングは、制約が多く、または少なくなり得ることを理解し、その場合、人間に可読な英数字の文字列は、いくつかの可能なＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダアクセス種類値に対してマッピングされるという構想である。

例えば、ＷＬＡＮ ＝ ”ＩＥＥＥ−８０２．１１” ／ ”ＩＥＥＥ−８０２．１１ａ” ／ ”ＩＥＥＥ−８０２．１１ｂ” ／ ”ＩＥＥＥ−８０２．１１ｇ” ／ ”ＩＥＥＥ−８０２．１１ｎ”
ＤＳＬ ＝ ”ＡＤＳＬ” ／ ”ＡＤＳＬ２” ／ ”ＡＤＳＬ２＋” ／ ”ＲＡＤＳＬ” ／ ”ＳＤＳＬ” ／ ”ＨＤＳＬ” ／ ”ＨＤＳＬ２” ／ ”Ｇ．ＳＨＤＳＬ” ／ ”ＶＤＳＬ” ／ ”ＩＤＳＬ”
Ｃｅｌｌｕｌａｒ ＝ ”３ＧＰＰ−ＧＥＲＡＮ” ／ ”３ＧＰＰ−ＵＴＲＡＮ−ＦＤＤ” ／ ”３ＧＰＰ−ＵＴＲＡＮ−ＴＤＤ” ／ ”３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＦＤＤ” ／ ”３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＴＤＤ”
ＣａｂｌｅＴＶ ＝ ”ＤＯＣＳＩＳ”。

例えば、ユーザが、ＷＬＡＮおよびＣｅｌｌｕｌａｒ（例えば、ＥＤＧＥ／ＵＭＴＳ／ＬＴＥ）アクセスの両方を同時にサポートする、マルチモード対応携帯電話を有する場合、ユーザは、音声および音響メディア種類にＣｅｌｌｕｌａｒ接続を使用しながら、帯域幅の効率、費用の効率、またはより良好な画質という理由で、ビデオメディア種類がＷＬＡＮアクセス上で受信されることを希望し得る。こうするために、ＵＥは、移転されたメディア種類が送られる、ユーザが選択したアクセスレッグに対するアクセスレッグ／フロー識別子に設定された値を有するメディア特徴タグ（例えば、ｇ．３ｇｐｐ．ｉｃｓｆｌｏｗ）を含むＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを、メディア移転を要求するために使用される要求（例えば、ＳＩＰ ＲＥＦＥＲ要求）の中に含める。「ｒｅｑｕｉｒｅ」および「ｅｘｐｌｉｃｉｔ」というパラメータもまた、随意で、アクセスレッグ／フロー識別子を含むメディア特徴タグと関連付けられたＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれ得る。Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダは、その値とともに、ＳＩＰ ＲＥＦＥＲ要求の場合、Ｒｅｆｅｒ−Ｔｏヘッダ内に埋め込むことができる。ＳＣＣ ＡＳ（または別のネットワークノード）は、メディア移転要求を受信する場合に、次いで、メディアが移転されるＵＥに送信される要求の中に、メディア移転要求からのその値とともに、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを含む。これは、ＲＦＣ ３８４１で説明されている機構を使用した所望のアクセスレッグを使用して、要求をＵＥに送らせ、それに対応して、要求が受け入れられた場合、そのアクセスレッグを使用してメディアも確立される。メディアが移転されるＵＥは、（上記の実施例等の）場合によっては、メディア移転要求を送信するコントローラＵＥの役割を果たす同じＵＥであり得ることに留意されたい。

図１は、ネットワークと関連付けられたＳＩＰ ＵＡまたはＵＥの間でメディアおよび／またはＩＵＴコントローラ機能を移転するように、本システムによって実装され得る、通信フロー例を図示する。フローは、第１のコントローラＵＥ（ＵＥ−１）から第２のコントローリＵＥ（ＵＥ−２）へ、２つのメディア構成要素を含むセッションのサービス制御を移転することを可能にする。第１および第２のＵＥの両方は、例えば、同じＳＩＰ ＵＲＩまたはＴｅｌ ＵＲＩを共有すること、あるいは暗示的登録セット（Ｉｍｐｌｉｃｉｔ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｓｅｔ／ＩＲＳ）によって定義される重複または同一公衆ユーザ識別を有することによって、同じ公衆ユーザ識別を共有し得る。しかしながら、それらは、ＩＭＳプライベート識別、ＩＭＳＩ、ＭＩＮ等であるが、それらに限定されない、一意のプライベート識別を有する。この実施例では、ＵＥ−１は、そのセッションがＳＣＣ ＡＳで固着される、遠隔ＵＥとの確立されたマルチメディアセッションを有する。ＵＥ−１は、最初に、協調セッション制御を促進する。

図１に示されるように、マルチメディアセッションは、２つのメディア構成要素（メディアＡおよびメディアＢ）を含み、ＵＥ−１は、ＩＵＴを介して、協調セッション制御およびメディア構成要素のうちの１つ（メディアＡ）をＵＥ−２に移転することを望む。図示されるように、ステップ１０１では、ＵＥ−１は、移転要求をＳＣＣ ＡＳに伝達または送信することによって、協調セッション制御およびメディア種類（メディアＡ）をＵＥ−２に移転するプロセスを開始する。移転要求は、協調セッション制御およびメディア種類（メディアＡ）がＵＥ−２に移転されることを示す。移転要求は、移転されるメディア種類を含むＳＤＰ（おそらくＳＩＰ ＲＥＦＥＲ要求のＲｅｆｅｒ−Ｔｏヘッダに埋め込まれる）を含み得る。代替として、メディア種類は、移転要求の中で適切な特徴タグ等を信号伝達することによって示され得る。ＵＥ−２は、ＧＲＵＵ、ＳＩＰ ＵＲＩ、Ｔｅｌ ＵＲＩ等によって識別され得るが、それらに限定されない。ステップ１０２では、ＳＣＣ ＡＳは、要求を識別し、検証プロセスを行う。検証プロセスは、ＵＥ−１がＩＵＴを行うことを許可されているという検証を含み得、ＵＥ−２識別、この実施例では、ＵＥ−２のＧＲＵＵが、ＳＣＣ ＡＳ（有効なＲＥＧＩＳＴＲＡＴＩＯＮが存在する）に記憶され、そのＧＲＵＵに対して、ＵＥ−１からの要求の中で受信されたものに合致するメディア特徴タグが記憶される。ＵＥ−２のＧＲＵＵが存在しない、または特徴タグが合致しない場合には、要求が拒絶され得る。代替として、検証プロセスは、ＳＣＣ ＡＳが承認されたＵＥのＴｅｌ ＵＲＩ、ＳＩＰ ＵＲＩを回収することを含み得る。回収されたＴｅｌ ＵＲＩ、ＳＩＰ ＵＲＩが、ＵＥ−１が使用できるものに合致する場合には、ＳＣＣ ＡＳは、回収されたＴｅｌ ＵＲＩ、 ＳＩＰ ＵＲＩに合致する別の標的ＵＥを識別し得る。次いで、ＳＣＣ ＡＳは、ａｃｃｅｐｔ ｃｏｎｔａｃｔヘッダの中の特徴タグ、ならびにｅｘｐｌｉｃｉｔおよびｒｅｑｕｉｒｅｄパラメータが、要求を実施するものに対する代替的連絡先を選択するように設定されることを確実にする。

ＵＥ−１が、ＵＥ−２への協調セッション制御およびメディアＡの移転を要求することを許可されている場合、ＳＣＣ ＡＳは、協調セッション制御およびメディアＡがＵＥ−２に移転されることを示す要求を、ＵＥ−２に伝達または送信し得る。例えば、ＳＩＰ ＭＥＴＨＯＤ（例えば、ＳＩＰ ＩＮＶＩＴＥ）は、協調セッション制御（ＩＵＴコントローラ機能）を示すメディア特徴タグとともに、ＵＥ−２のＧＲＵＵを標的として含み得る。ＳＩＰ ＭＥＴＨＯＤは、「Ｅｘｐｌｉｃｉｔ」および「Ｒｅｑｕｉｒｅｄ」を伴う必要なメディア特徴タグを、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダの中に含み得る。代替として、移転されるメディア種類を含む、ＳＤＰが含まれる。ステップ１０３では、システムは、ＵＥ−２とＳＣＣ ＡＳとの間に協調セッション制御を確立する。この時点で、ＵＥ−２は、協調セッションのためのコントローラＵＥになる（ＩＵＴコントローラ機能を示すメディア特徴タグを受信することに基づく）。しかしながら、別の実装では、ＵＥ−１は、ＵＥ−１上で協調セッションを保持しながら、移転されるメディアを含む移転要求を送信し得る。この場合、移転要求は、協調セッション制御（ＩＵＴコントローラ機能）の指示、識別子、トークン、フラグ、またはメディア特徴タグを含まない。

１つの実装では、協調セッションは、おそらく、単一のＩＭＳセッションとして遠隔レッグ上で提示されるＳＣＣ ＡＳの中で固着される同じＩＭＳサブスクリプションを共有する、２つ以上のＵＥの上で、論理的な一式の１つ以上のＩＰマルチメディアサブシステム（ＩＭＳ）セッションを含む。遠隔レッグは、加入者の視点から見られるように、ＳＣＣ ＡＳとリモートパーティとの間の呼び出し制御レッグであり得る（追加の実施例については、回路交換メディアを使用するＩＭＳセッションのための遠隔レッグの定義に対する３ＧＰＰ ＴＳ ２３．２９２を参照されたい）。

ステップ１０４では、ＵＥ−２とＳＣＣ ＡＳとの間でメディアＡを搬送するセッションが確立される。この時点で、システムは、随意で、ＵＥ−２との新しいセッションの確立に従って、ＳＣＣ ＡＳとリモートパーティとの間の遠隔レッグを更新し得る。例えば、遠隔レッグは、ビデオコーデック調整または変更を実装するように構成され得る（例えば、ＩＰＴＶデバイスによって、またはそうでなければメディアを再交渉するために変更が必要とされるため）。ＵＥ−２への協調セッション制御の確立およびメディアＡの移転の成功後、ＳＣＣ ＡＳは、ステップ１０５で、移転応答をＵＥ−１に返送する（例えば、ＲＦＣ ３５１５の通りの最終応答に対するＳＩＰ ＮＯＴＩＦＹ要求）。移転応答を受信した後、ステップ１０６で、ＵＥ−１上でメディアＡを搬送する以前のセッションが解放され得、協調セッションが解放される。協調セッション制御の成功した移転後、ＵＥ−１は、協調セッションの一部としてのコントローリＵＥ（セッション制御のためのコントローラＵＥより下位にありながら、メディアフロー（メディアＢ）を受信および／または伝送するＵＥ）となり、ＵＥ−２は、コントローラＵＥの役割を担う。メディア種類（メディアＡ）は、ＵＥ−２とリモートパーティとの間で伝達され、メディア種類（メディアＢ）は、ＵＥ−１とリモートパーティとの間で伝達され続ける。移転が成功しなかった場合、ＳＣＣ ＡＳは、移転の失敗を示すメッセージをＵＥ−１に返送する。メッセージは、ＳＩＰ ４８８（Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ／受諾不可能）応答を含むことができるが、それらに限定されない。失敗の理由を示す応答に、警告が含まれ得る。移転の失敗を示すＵＥ−１へのメッセージは、ＵＥ−２からの応答のＳＩＰｆｒａｇを本文に含む、ＳＩＰ ＮＯＴＩＦＹ要求に含まれ得る。

図１に図示された通信フローは、ＵＥ間のメディアおよび協調セッション制御の移転を可能にする。メディアおよび協調セッション制御移転に加えて、上記のフローはまた、１つ以上のコントローラＵＥが標的ＵＥにコントローラ機能を与えることを承認した後、ＵＥ間でコントローラ機能を移転し得る。

１つの実装では、（例えば、ＩＭＳサービス連続性のために）セッション移転を促進するために、ＵＥは、セッション移転のための（例えば、上記で説明されるような）操作者方針を記憶し、適用するように構成され得る。ＵＥはまた、現在の操作者方針、ユーザ選好、およびローカル動作環境情報を含むトリガ基準に基づいて、セッション移転手順を開始し、セッション移転動作を行うための必要な詳細をＳＣＣ ＡＳに提供し得る。ＵＥはまた、ＩＵＴに対するコントローラまたはコントローリ機能性をサポートする能力を提供し、現在の操作者方針およびユーザ選好に基づいて、ＩＵＴ手順を開始し、ＩＵＴを行うための必要な詳細をＳＣＣ ＡＳに提供し得る。

ＵＥは、おそらく異なるアクセスネットワークを使用して、複数の登録コンテンツを有することができる。ＵＥは、ネットワークまたはアプリケーションサーバ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ／ＡＳ）におけるＩＵＴ方針および実装に応じて、いくらかまたは全てのメディア伝送に異なるネットワークを使用するように構成され得る。例えば、ＵＥは、何らかの所定のユーザ選好またはネットワーク／操作者方針に従って、適切な性質を有するビデオ種類メディア伝送に、無線ローカルエリア（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ／ＷＬＡＮ）無線または何らかの他のアクセスネットワークを使用し得る。

性質または標的ＵＥあるいは特定の標的ＵＥを示す指標も、（例えば、同じデバイスによってサポートされる）アクセス技術を識別することが可能であり得る。上で説明される手順を使用した特定のアクセス技術を使用する、特定のアクセスレッグ上で、要求を送ることができる。

他のシステム実装では、コントローラＵＥ機能性はまた、セットトップボックス等の物理的なボックスの中でホストされ得るか、またはパーソナルコンピュータ、メディアサーバ、ホームノードＢ、またはユーザによって物理的に操作されない他のデバイス上でホストされる、実行可能なソフトウェアであり得る。一実施例では、ユーザは、メディアシンクまたはコントローリＵＥによって包囲される。メディアシンクは、コントローラＵＥまたは他のメディアコントローラデバイスとの相互作用を可能にするか、またはそれを補完し得る。例えば、ＴＶのリモコンが、停止および巻き戻しまたは他の機能を提供し、それらがメディアシンクまたはＴＶによって傍受され、種々の機能を処理するように構成されるデバイスまたはＵＥに転送され得る。いくつかの実装では、単一のボックスが、異なる外部の物理的デバイスに対する複数のＳＩＰ ＵＡをサポートし得る。例えば、ホームサーバまたはセットトップボックスは、基本ＴＶ、レガシー固定回線電話、および非ＳＩＰ使用可能家庭用娯楽システム等の他の接続された非ＳＩＰ対応デバイスのための複数のＳＩＰ ＵＡを実装し得る。

ここで図２を参照すると、ＩＵＴを行うために本システムを実装するための例示的な通信ネットワークが図示されている。ネットワーク２１２は、通信ネットワークであり、基地局、ＳＣＣ ＡＳ、Ｐ（Ｐｒｏｘｙ／プロキシ）−ＣＳＣＦ、Ｓ（Ｓｅｒｖｉｎｇ／サービング）−ＣＳＣＦ、およびＩ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ／問い合わせ）−ＣＳＣＦ等の呼び出しセッション制御機能（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ／ＣＳＣＦ）、移動交換センター（ＭＳＣ）サーバ、ＩＭＳ集中サービス（ＩＭＳ Ｃｅｎｔｒａｌｉｚｅｄ Ｓｅｒｖｉｃｅ／ＩＣＳ）のＭＳＣ進化型、および／または、デバイス能力、ユーザ選好、ＩＵＴのためのコントローラＵＥおよびコントローリＵＥのリスト、デバイスごとのセッションレッグマッピング情報、および本システムを実装する際に使用される他の規則または制限を記憶するための種々のデータ記憶システム等の種々の構成要素を含む。ネットワーク２１２と通信することによって、ＵＥは、ネットワークと関連（例えば、ＲＥＧＩＳＴＥＲＥＤ）し、ネットワーク２１２を通して、他の関連ＵＥ、またはネットワーク２１２を介して通信するように構成される他のデバイスと通信することができる。ユーザ２１４は、いくつかのＵＥ２１６、２１８、および２２０を有する。ＵＥ２１６、２１８、および２２０は、例えば、ＩＲＳセットＡにおいて、Ｔｅｌ ＵＲＩまたはＳＩＰ ＵＲＩによって定義され得る、単一の識別２３０を共有する。ユーザ２２２は、同様にネットワーク２１２に接続される、ＵＥ２２４および２２６を有する。ＵＥ２２４および２２６はまた、例えば、ＩＲＳ Ｂによって、識別を共有する。

図２では、ユーザ２１４のＵＥは、いくつかの異なるデバイスを含む。ＵＥ２１６は、ビデオ能力を持たない携帯電話であり、ＵＥ２１８は、ボイスオーバーＩＰ（ＶｏＩＰ）およびビデオ会議能力を有するラップトップであり、ＵＥ２２０は、ネットワーク２１２と通信するように構成されるが、最小限のユーザ入力能力を有する、テレビである。本実施例では、テレビ２２０は、ネットワーク２１２と通信するためのプロキシ２２１への配線接続によって接続される。プロキシ２２１は、ホームゲートウェイ、ケーブルボックス、セットトップボックス、またはネットワーク２１２と通信するための他のシステムを含み得る。プロキシ２２１は、無線で、または配線接続を介して、ネットワーク２１２と通信し得る。しかしながら、当業者であれば、プロキシ２２１のうちのいくらかまたは全てが、テレビ２２０に組み込まれ得ることを理解するであろう。ＵＥ２１６、２１８、および２２０のそれぞれが、ネットワーク２１２との接続を確立すると、ＩＵＴコントローラ機能は、ユーザ２１４と関連付けられたＵＥのうちの１つ以上に割り当てられ得る。ＩＵＴコントローラ機能は、ＵＥの機能的能力、ユーザ選好、ネットワーク要件、またはユーザ２１４、ネットワーク２１２、あるいは通信ネットワーク２１２内の任意の他のエンティティを介して利用可能となる他のデータの任意の組み合わせを評価する、規則に基づいて、割り当てられ得る。本実施例では、ＵＥ２１６（携帯電話）が、最初にＩＵＴコントローラ機能を割り当てられる。そして、ＵＥ２１６が、進行中のセッション上のあるメディアの移転要求をＵＥ２１８および２２０のうちのいずれか１つに送信し得る。移転プロセスの一部として、ＵＥ２１６はまた、ＩＵＴコントローラ機能をＵＥ２１８および２２０のうちのいずれかに移転するネットワーク２１２への要求を発行し得る。場合によっては、ネットワーク定義およびユーザ定義された規則に応じて、メディアおよびＩＵＴコントローラ機能の一部または全てが、ユーザ２２２に属するＵＥ２２４および２２６に移転され得る。

図２を参照すると、ユーザ２１４は、携帯電話２１６を使用して、ユーザ２３０に属するＵＥ２３２への通話を開始し得る。携帯電話２１６がビデオをサポートしないため、確立されたセッションは、ビデオを伴わずに音声のみを含む。しかしながら、ユーザ２３０のＵＥ２３２がビデオをサポートし、ユーザ２３０がビデオをセッションに追加することを希望する場合、ユーザ２３０は、ビデオをセッションに追加する要求または招待をユーザ２１４に発行し得る。携帯電話２１６がビデオを処理することができないため、ユーザ２１４が、ビデオを処理することができるＵＥにリダイレクトするようにＵＥ２１６に通告しない限り、ビデオをセッションに追加することはできない。この実施例では、ビデオを進行中のセッションに追加する要求を受信すると、ユーザ２１４は、ビデオ会議能力を有するラップトップ２１８にビデオ種類を伴う要求をリダイレクトするようにＵＥ２１６に通告し得る。ラップトップ２１８にビデオを伴う要求をリダイレクトするためには、携帯電話２１６は、ネットワーク２１２にビデオ種類を伴う要求をリダイレクトするために、ＳＩＰ ３ｘｘ非最終応答等のメッセージを生成する（仮に、ＳＩＰ ３ｘｘ応答等の最終ＳＩＰ応答が使用された場合、セッション全体がリダイレクトされ得る）。システム実装に応じて、リモートパーティから新しいメディア種類を追加する要求を受信すると、ネットワーク（例えば、ＳＣＣ ＡＳ）は、例えば、デバイス能力、ユーザ選好、またはネットワーク規則に基づいて、標的ＵＥへの招待を自動的に開始し得る。代替として、携帯電話２１８によって提供されるユーザインターフェースは、ユーザ２１４が、メッセージをラップトップ２１８にリダイレクトするように携帯電話２１８に通告することを可能にし得る。ネットワーク２１２（例えば、ＳＣＣ ＡＳ）が、要求をリダイレクトする要求を受信した後、ネットワーク２１２（例えば、ＳＣＣ ＡＳ）は、ラップトップ２１８がビデオ種類メディアをサポートできることを検証する。これは、ラップトップ２１８のＳＩＰ ＲＥＧＩＳＴＲＡＴＩＯＮの一部としてＳＣＣ ＡＳ２１２に渡され、ＲＥＧＩＳＴＲＡＴＩＯＮラップトップ２１８のＧＲＵＵメディア特徴タグに対してＳＣＣ ＡＳ２１２に記憶された、メディア特徴タグを、ＳＣＣ ＡＳ２１２が調べることから成る。

ＳＣＣ ＡＳ２１２は、携帯電話２１６が出力先変更を要求する能力を有し、そのような要求を行う権限を与えられていることを検証する。これらの要件が満たされた場合、ＳＣＣ ＡＳ２１２は、コントローラからのＳＩＰ ＭＥＴＨＯＤ（例えば、ＳＩＰ ＩＮＶＩＴＥ）に含まれた特徴タグが、メディアがリダイレクトされるＳＩＰ Ｃｏｎｔａｃｔに対して記憶されているかどうかをチェックし得る。メディア特徴タグが存在する場合、ＳＣＣ ＡＳは、メディアタイプを含むＳＤＰを伴う招待要求（例えば、ＳＩＰ ＩＮＶＩＴＥ）を送信することによって、要求をラップトップ２１８にリダイレクトする。ＳＣＣ ＡＳはまた、ＲＦＣ ３８４１による「Ｅｘｐｌｉｃｉｔ」および「Ｒｅｑｕｉｒｅｄ」を設定して、正しい標的がＳ−ＣＳＣＦにおいて選択されることを確実にする。出力先変更および協調セッション確立が成功すると、携帯電話２１６は、ラップトップ２１８へのＩＵＴコントローラ機能の移転を要求し得る。

本実施例では、ＩＵＴコントローラ機能性がラップトップ２１８に移転される。そして、ラップトップ２１８は、ユーザ２１４にアクセス可能な他のＵＥへのビデオ会議セッションを再び有するというオプションを有する。例えば、より多くの人々の集団による進行中のビデオ会議の閲覧を促進するために、ユーザ２１４は、ネットワーク２１２を介して通信するように構成されるラップトップ２１８上でビデオ会議を保持しながら、ビデオ会議上のメディアのいくらかまたは全てをテレビ２２０に複製することを希望し得る。この実施例では、テレビ２２０は、マイクロホンを含まない。そして、ユーザ２１４は、（ＩＵＴコントローラの状態を有する）ラップトップ２１８を使用して、進行中のビデオ会議セッションのビデオ部分のみをテレビ２２０に複製するようにネットワーク２１２に通告する。ＳＣＣ ＡＳが、移転後に、移転されたレッグからメディア種類を解放する１つの実装では、複製が要求されることを信号伝達する必要がある。複製は、新しいメディア特徴タグ、ＳＤＰ変数、パラメータ、および／またはＳＩＰヘッダを使用して、信号伝達され得る。移転するＵＥが、移転後に、移転されたレッグからメディア種類を解放する別の実装では、要求される複製の信号伝達は必要とされない。複製を承認すると、ＳＣＣ ＡＳ２１２は、ビデオメディア種類を伴うセッション招待（ＳＩＰ ＩＮＶＩＴＥ）等のメッセージをテレビ２２０に送信して、閲覧を促進する。しかしながら、セッションの音声部分は、ユーザ２１４がユーザ２３０と通信し続けることができるように、ラップトップ２１８にとどまる。この実施例では、テレビ２２０はまた、追加のメディア移転を開始するためのユーザ入力を受信するためのユーザインターフェースを持たない。したがって、ＩＵＴコントローラの状態は、ユーザ２１４がテレビ２２０から別のデバイスへビデオ会議のビデオ部分を移転し得るように、ラップトップ２１８にとどまる。ＩＵＴコントローラの状態がレガシーテレビ２２０に移転された場合、レガシーテレビ２２０が、そのような移転を開始するための適切なユーザインターフェースを提供することができないため、セッションを別のデバイスに移転する機構がない場合があり、セッションのビデオ部分はレガシーテレビ２２０にとどまったままとなる。

システム実装に応じて、種々の方針または制限が、各ユーザに対して確立され得るＵＥの数および組み合わせに適用され得る。例えば、ネットワークは、１つだけのＩＵＴコントローラ対応ＵＥがＩＵＴコントローラになることができることを定める制限を実装し得、また、複数のＩＵＴコントローラ対応ＵＥが任意の協調セッションのためのＩＵＴコントローラになることができ、複数のＩＵＴコントローラ対応ＵＥが、全ての協調セッションに対して複数のＵＥを伴うＩＵＴコントローラになることができるが、同じ協調セッションにつき１つのＩＵＴコントローラＵＥのみでくあることを定める制限を実装し得る。さらに、好ましいベアラ（例えば、回路交換またはパケット交換）が、ネットワーク規則、ユーザ選好、または任意の組み合わせによって特定され得る。例えば、好ましいベアラ設定は、例えば、発話メディア種類セッションについては回路交換、およびビデオ種類セッションについてはパケット交換であり、メディア種類およびデバイス能力に依存し得る。

ネットワーク（例えば、ＳＣＣ ＡＳ）はまた、課金目的で、どのＵＥがＩＵＴコントローラであるかという指示、ＩＵＴコントローラ機能を果たすＵＥ識別、一式のＵＥが同じサブスクリプションに属することを示すＩＵＴに対するサブスクリプションセット指示、およびベアラ指示（使用されているベアラに応じて、異なる課金があり得る）といった指示を使用し得る。

本システムでは、各ＵＥは、（例えば、ＳＣＣ ＡＳまたは通信ネットワークの別の構成要素を介して）ネットワークと通信して、ＵＥがＩＵＴコントローラ機能性をサポートする能力を有するかどうかに関して、ネットワーク、この場合ではＳＣＣ ＡＳに通告するように構成し得る。一実装では、ＵＥは、ＳＩＰ ＲＥＧＩＳＴＥＲ、ＳＩＰ ＰＵＢＬＩＳＨ、ＳＩＰ ＳＵＢＳＣＲＩＢＥ、ＳＩＰ ＮＯＴＩＦＹ、ＳＩＰ ＩＮＶＩＴＥ、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥ、ＳＩＰ ＵＰＤＡＴＥ、ＳＩＰ ＯＰＴＩＯＮＳ、およびＳＩＰ ＲＥＦＥＲ等のＳＩＰ ＭＥＴＨＯＤ、または、例えば、ＳＯＡＰあるいはＨＴＴＰを使用した、構成アクセスプロトコル（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ／ＸＣＡＰ）あるいはウェブサービスベースである、ＳＩＰ応答（ＳＩＰ Ｒｅｓｐｏｎｓｅ）あるいはエクステンシブルマークアップランゲージ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を含む、ＳＩＰメッセージ等を使用して、その能力をＳＣＣ ＡＳに伝送する。ＵＥがその能力をＳＣＣ ＡＳに伝送するための１つの方法は、メディア特徴タグ、例えば、Ｃｏｎｔａｃｔヘッダの中のｇ．３ｇｐｐ．ｉｕｔを使用することである。例えば、Ｃｏｎｔａｃｔヘッダを含む、ＳＩＰ ＲＥＧＩＳＴＥＲ、ＳＩＰ ＳＵＢＳＣＲＩＢＥ、ＳＩＰ ＮＯＴＩＦＹ、ＳＩＰ ＩＮＶＩＴＥ、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥ、ＳＩＰ ＵＰＤＡＴＥ、ＳＩＰ ＯＰＴＩＯＮＳ、ＳＩＰ ＰＵＢＬＩＳＨ、およびＳＩＰ ＲＥＦＥＲ等のＳＩＰ ＭＥＴＨＯＤは、ＩＵＴコントローラ機能性のための特定のＵＥのサポートを示すＩＵＴコントローラメディア特徴タグを含むように構成され得る。代替として、ＳＩＰ ２００ ＯＫ等のＳＩＰ応答も、ＵＥのコントローラ能力を示すように構成され得る、Ｃｏｎｔａｃｔヘッダを含むことができる。

Ｃｏｎｔａｃｔヘッダを使用して実装されると、ＩＵＴコントローラ特徴タグは、例えば、３つの可能な値を含み得る（システムが種々の名前および属性を有する他の値を使用し得るため、例示的な値のみを説明する）。第１に、値「Ａｃｔｉｖｅ（能動）」は、ＩＵＴコントローラ特徴タグと関連付けられた連絡先アドレスを伴うＵＥが、セッションのためのＩＵＴコントローラとしての役割を現在果たしていることを示し得る。第２に、値「Ｉｎａｃｔｉｖｅ（非能動）」は、ＩＵＴコントローラ特徴タグと関連付けられた連絡先アドレスを伴うＵＥが、セッションのためのＩＵＴコントローリ（すなわち、アクティブＩＵＴコントローラではなく）としての役割を現在果たしているが、ＩＵＴコントローラ役割を割り当てられることが可能であることを示し得る。第３に、値「Ｐａｓｓｉｖｅ（受動）」は、ＩＵＴコントローラ特徴タグと関連付けられた連絡先アドレスを伴うＵＥが、セッションのためのＩＵＴコントローリとしての役割を現在果たしており、ＩＵＴコントローラ役割を受け入れることが不可能であるか、または進んで受け入れようとしないことを示し得る。受動はまた、デバイスがコントローリとしての役割を果たすことができるが、コントローラ機能性を持たないことを意味することもできる。

いくつかの実装では、ＩＵＴコントローラ指示は、特定のＵＥ上で、（Ａｃｔｉｖｅ，Ｉｎａｃｔｉｖｅ）または（Ａｃｔｉｖｅ，Ｐａｓｓｉｖｅ）等の２つの特定の値を含み得る。値の定義例は、ｇ．３ｇｐｐ．ｉｕｔｃｏｎｔｒｏｌｌｅｒ＝”ａｃｔｉｖｅ”、またはｇ．３ｇｐｐ．ｉｕｔｃｏｎｔｒｏｌｌｅｒ＝”ｐａｓｓｉｖｅ”を含み得る。場合によっては、ＩＵＴコントローラ値は、バージョン指標が付与される。例えば、ＩＵＴコントローラ値は、「ａｃｔｉｖｅＸ」であり得、Ｘは、ＵＥによってサポートされるＩＵＴのバージョンを示す、０または１からＹまでの値であり得る。別の実施例は、ｇ．３ｇｐｐ．ｉｕｔ＝［ｃａｐａｂｉｌｉｔｙ］であり、それにより、能力は、「コントローラ」または「コントローリ」等であるＩＵＴデバイスの能力を示す。コントローラは、「ａｃｔｉｖｅｃｏｎｔｒｏｌｌｅｒ」または「ｐａｓｓｃｏｎｔｒｏｌｌｅｒ」となるように拡張することができる。Ａｃｔｉｖｅｃｏｎｔｒｏｌｌｅｒは、ＳＩＰ ＵＡ／ＵＥがセッションのためのコントローラ活動を行っていることを意味し、ｐａｓｓｃｏｎｔｒｏｌｌｅｒは、ＳＩＰ ＵＡ／ＵＥがコントローラ能力を有するが、コントローラとしての役割を果たしていないことを意味する。特徴タグの定義例が、以下の表４で提供されるが、当業者であれば、ＳＩＰ ＵＡ／ＵＥから同じ意味を伝えるために、適切な英数字の任意の構築を使用できることを理解するであろう。

他の実装では、ＩＵＴコントローラ機能をサポートするＵＥは、ＳＩＰ、ＸＣＡＰ等を使用して、ユーザ選好に基づいてＩＵＴコントローラ設定を有効または無効にするように、ユーザによって構成することができる。ＩＵＴコントローラＵＥまたはコントローリＵＥの有効化または無効化設定は、例えば、ＳＩＰまたはＸＣＡＰメッセージのＸＭＬ ＭＩＭＥ本文の中へ配置され得る。ＩＵＴコントローラ設定がＵＥ上で有効にされる場合には、ＵＥは、ＩＵＴコントローラＵＥとしての役割を果たす。ＩＵＴコントローラ設定がＵＥ上で無効にされる場合には、ＵＥは、ＩＵＴコントローリＵＥとしての役割を果たす。以下は、ＸＭＬにおいて特定のＵＥに対するＩＵＴコントローラ機能性を設定する実施例である。

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ＵＴＦ−８”？＞
＜ｉｕｔｃｏｎｔ−ｓｅｔｔｉｎｇｓ ｘｍｌｎｓ＝”ｕｒｎ：３ｇｐｐ：ｐａｒａｍｓ：ｘｍｌ：ｎｓ：ｉｍｓ：ｉｕｔｃｏｎｔ−ｓｅｔｔｉｎｇｓ”
ｘｍｌｎｓ：ｘｓｉ＝ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ−ｉｎｓｔａｎｃｅ
ｘｓｉ：ｓｃｈｅｍａＬｏｃａｔｉｏｎ＝”ｕｒｎ：３ｇｐｐ：ｐａｒａｍｓ：ｘｍｌ：ｎｓ：ｉｍｓ：ｉｕｔｃｏｎｔ−ｓｅｔｔｉｎｇｓ ”＞
＜ｅｎｔｉｔｙ ｉｄ＝”ｄｏ３９ｓ８ｚｋｓｎ２ｄ９８ｘ”＞
＜ｉｕｔｃｏｎｔ−ｓｅｔｔｉｎｇｓ＞
＜ｉｎｔｅｒｕｅｔｒａｎｓｆｅｒ−ｃｏｎｔｒｏｌｌｅｒ ａｃｔｉｖｅ＝”ｔｒｕｅ” ／＞
＜／ｉｕｔｃｏｎｔ−ｓｅｔｔｉｎｇｓ＞。

特定のＵＥがコントローラＵＥとしての役割を果たす能力を有し、かつそのように役割を果たすことが好まれるかどうかについて、ネットワークに通知することに加えて、本システムは、複数のベアラをサポートするＵＥが、ＵＥ能力およびユーザ選好等の情報を記憶するネットワークに、ユーザによって好ましいベアラを示すように構成されることを可能にする。ＵＥに応じて、ＵＥは、例えば、回路交換、パケット交換通信プロトコル、または両方を使用して、ネットワークと通信する能力を有し得る。複数のベアラをサポートするＵＥについて、ＳＩＰ、ＸＣＡＰ、または他の符号化スキームを介したユーザ選好を通して、好ましいベアラが特定され得る。１つの実装では、好ましいベアラは、特定のメディア種類および／またはデバイス能力に従って特定される。例えば、特定のベアラは、特定の能力を有するデバイス上の特定のメディア種類に特定され得る。代替として、メディア種類および／またはデバイス能力にかかわらず、一般的なベアラ選好が全てのＵＥに特定され得る。ベアラ選好は、例えば、ＳＩＰまたはＸＣＡＰメッセージのＸＭＬ ＭＩＭＥ本文の中で特定され得る。以下は、ＸＭＬにおける例示的なコーディングを示す。

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ＵＴＦ−８”？＞
＜ｉｕｔｃｏｎｔ−ｓｅｔｔｉｎｇｓ ｘｍｌｎｓ＝”ｕｒｎ：３ｇｐｐ：ｐａｒａｍｓ：ｘｍｌ：ｎｓ：ｉｍｓ：ｉｕｔｃｏｎｔ−ｓｅｔｔｉｎｇｓ”
ｘｍｌｎｓ：ｘｓｉ＝ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ−ｉｎｓｔａｎｃｅ
ｘｓｉ：ｓｃｈｅｍａＬｏｃａｔｉｏｎ＝”ｕｒｎ：３ｇｐｐ：ｐａｒａｍｓ：ｘｍｌ：ｎｓ：ｉｍｓ：ｂｅａｒｅｒ−ｓｅｔｔｉｎｇｓ ”＞
＜ｅｎｔｉｔｙ ｉｄ＝”ｄｏ３９ｓ８ｚｋｓｎ２ｄ９８ｘ”＞
＜ｂｅａｒｅｒ−ｓｅｔｔｉｎｇｓ＞
＜ｐｒｅｆｅｒｒｅｄ−ｂｅａｒｅｒ＞ＰＳ＜／ｐｒｅｆｅｒｒｅｄ−ｂｅａｒｅｒ＞
＜／ｂｅａｒ−ｓｅｔｔｉｎｇｓ＞。

ＵＥの能力、および随意でＵＥに対する好ましいベアラに関するユーザ選好を示すメッセージを受信すると、基地局、Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、およびＩ−ＣＳＣＦのような呼び出しセッション制御機能、移動交換センター（ＭＳＣ）サーバ、ＩＣＳ用のＭＳＣ進化型、またはＳＣＣ ＡＳ等の１つ以上のネットワーク構成要素は、ＩＵＴコントローラ機能がＵＥ上でサポートされることと、コントローラとしてＵＥを使用する選好とをメッセージが含む場合、ＵＥがコントローラとしての役割を果たすことを許可され、かつそのような役割を果たすことができることを検証し得る。一実施形態では、ＳＣＣ ＡＳはまた、受信されたメッセージが、サポートされたベアラ種類および／または特定のベアラ種類を使用する選好を含む場合に、ＵＥが特定のベアラをサポートし、それを登録していることを検証し得る。

検証中に、ＳＣＣ ＡＳは、例えば、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中のＩＵＴコントローラメディア特徴タグを調べることによって、どのＵＥがコントローラであるべきかを決定する。１つの実装では、ＳＣＣ ＡＳは、サブスクリプション登録イベントパッケージまたは強化された第三者登録手順（第三者ＳＩＰ ＲＥＧＩＳＴＥＲ要求の本文に含まれる着信ＳＩＰ ＲＥＧＩＳＴＥＲ要求）を使用して、メディア特徴タグを取得する。ＳＣＣ ＡＳはまた、登録ＵＥに使用することができるベアラを決定し得る。ネットワークの方針の中の好ましい／サポートされたベアラ値が、受信されたメッセージのものとは異なる場合、ネットワーク方針によって定義される好ましい／サポートされたベアラ値が優先し得る。要求は、上記で説明される手順を使用した特定のアクセス技術を使用する、特定のアクセスレッグまたは好ましいベアラ上で送ることができる。

ＵＥがコントローラ機能の割当および／または特定のベアラ割当のある要件を満たすことを検証するために、ネットワークは、ユーザの公衆ユーザ識別、例えば、Ｔｅｌ ＵＲＩ、ＳＩＰ ＵＲＩ等、ユーザのプライベートユーザ識別、例えば、ＩＭＳプライベートユーザ識別、ＩＭＳＩ等、どのＵＥ（例えば、インスタンスＩＤ、ＩＭＥＩ、ＭＩＮ、またはＧＲＵＵ）が同じサブスクリプションセットに属するか、どのＵＥが同じＩＵＴに属するか、どのＵＥがＩＵＴコントローラ機能が可能であるか、インスタンスＩＤ、ＩＭＥＩ、ＭＩＮ、グローバルにルーティング可能なユーザエージェントＵＡ ＵＲＩ（Ｇｌｏｂａｌｌｙ Ｒｏｕｔａｂｌｅ ＵＡ ＵＲＩ／ＧＲＵＵ）等のデバイス識別、各デバイスへのデバイスニックネームマッピング、各デバイスと接続されたセッションレッグマッピング情報、各ＵＥ上のサポートされた好ましいベアラまたは無線アクセス技術（ＲＡＴ）、複数のＰＳアクセス技術または複数のサブスクリプションあるいはピアツーピア（Ｐ２Ｐ）サービスをサポートし、ＲＡＴまたはサブスクリプションあるいはＰ２Ｐサービスにつき少なくとも１つのＵＡを有する、ＵＥまたは中間物に対するＲＡＴあたりの各ＵＡを識別するアドレス、別のＵＥがコントローラ機能を取得することを可能にする承認規則、およびＵＥを説明するか、またはＵＥと関連付けられた他の情報を記憶する、データベースを維持する。このデータベースは、ＨＳＳに記憶され、Ｓｈインターフェースを使用してＳＣＣ ＡＳによってアクセスされ得、または情報は、登録の結果としてＳ−ＣＳＣＦから受信され得る。データベースは、ネットワーク内の他のエンティティ内に記憶することができる。おそらく、ＳＣＣ ＡＳの内部またはそれらの組み合わせである。１つの実装では、登録活動を行うために、ネットワークは、データベースの中のＵＥのＩＲＳをチェックして、登録を要求するＵＥが、承認ＵＥと同じＩＲＳセットを有することを確認し得る。要求ＵＥが、データベースに記憶された承認ＵＥと同じＩＲＳセットを使用する場合、ＩＲＳセットは、ＩＭＳプライベートＩＤによって表される特定の能力、およびＵＥがコントローラまたはコントローリであり得るかを示し得る。さらに、ＩＲＳセットは、ＵＥが制御され得るのみかどうか、およびＵＥがサービスの内外で登録できるかどうかを示し得る。

本システムの動作中、ネットワークノードは、ＩＵＴ ＵＥのＵＲＩまたは識別のリスト（すなわち、ＩＵＴ移転を要求するか、または移転されることができるＩＵＴ ＵＥのＵＲＩまたは識別のリスト、あるいは同じＩＵＴセットに属するコントローラおよびコントローリＵＥの一式のＵＲＩ）を、コントローラＵＥまたは一式のＩＵＴ ＵＥに配信し、どのＵＥがコントローラまたはコントローリであるか、どのＵＥがＩＵＴコントローラ機能をサポートするか、およびどのＵＥがＩＵＴコントローラ機能を移転されることができるかという識別を可能にする。ＩＵＴ ＵＥのＵＲＩまたは識別のリストは、デバイスニックネーム、ＵＲＩあたりのサポートされたメディア種類、または各ＩＵＴ ＵＥの識別等の情報を含み得る。

ＵＥがネットワークに登録する場合に、ＵＥは、上で説明される特徴タグを含む。ＵＥのＧＲＵＵは、登録プロセスの一部として記憶される。次いで、このＧＲＵＵは、ＵＲＩとして全ての潜在的なコントローラＵＥに伝達される。送信される情報はまた、ＧＲＵＵによって識別されるＵＥがＩＵＴコントローラ、コントローラ（受動役割）およびコントローリ、コントローリ対応、またはレガシー対応である場合、適格性を含むこともできる。サポートされるメディア種類、登録されたＲＡＴ等も、ＵＥがコントローラとしての役割を果たす場合にＵＥを支援するように伝達され得る。デバイスが再登録を行い、メディアタグ（例えば、登録されたＲＡＴを含む）が変化した場合には、これは、ＩＵＴコントローラ対応ＵＥに送信される情報の更新を引き起こし得る。

図３に図示されるように、ＵＥは、ＳＣＣ ＡＳへの登録を引き起こす、ステップ３０１で、ＩＭＳネットワークに登録する。ＳＣＣ ＡＳは、登録したデバイスがＩＵＴセットの一部であるかどうかを決定する必要がある。これは、同じＩＲＳにおいてＩＵＴ対応である１つから多くのＵＥがすでにあることをＳＣＣ ＡＳが認識することによって決定され得、ＳＣＣ ＡＳが、ステップ３０２におけるＹで、この決定を行うことができる場合には、ＳＣＣ ＡＳはステップ３０３でＯＭＡ ＤＭサーバと通信する。ＳＣＣ ＡＳは、ステップ３０４で、必要なデバイス、または情報を必要とする他のデバイスに情報を伝達することができるように、ＯＭＡ ＤＭサーバに必要な識別を含むことができる。これは、インスタンスＩＤ、機器識別のリストを含み得る。これらは、登録プロセスで取得されているであろう。場合によっては、登録を行う前に、ＩＣＳ ＵＥがＩＭＥＩを有する場合、ＩＣＳ ＵＥは、３ＧＰＰ ＴＳ ２３．００３で定義されるようなそのＩＭＥＩに基づいて、インスタンスＩＤを生成する。

ＵＥが登録する時に送信される、何らかの形態のＩＵＴグループ識別子（表５の実施例を参照）があり得る、別の実装では、この識別子は、異なるＩＲＳからの加入者が同じＩＵＴグループの中にいることを可能にするＩＵＴグループを識別する。この場合、次いで、ＳＣＣ ＡＳは、ＵＥが登録する時に、ＵＥがＩＵＴセットの一部であるかどうかをチェックする。ＩＵＴグループ識別子についての可能な実施形態は、新しいメディア特徴タグ、または以前に定義されたものの拡張であり得る。例えば、３．ｇｐｐ．ｉｕｔｇｒｏｕｐ＝［ｖａｒｉａｂｌｅ］である。

一実装では、ＩＵＴ ＵＥのＵＲＩまたは識別のリストを配信する場合に、サービングＳＣＣ ＡＳのアドレスも含まれ、オープンモバイルアライアンスデバイス管理（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ／ＯＭＡ ＤＭ）、クライアントプロビジョニング（Ｃｌｉｅｎｔ Ｐｒｏｖｉｓｉｏｎｉｎｇ）、または他のデバイス管理およびプロビジョニングプロトコルを介して提供され得る。ＩＵＴ ＵＥのＵＲＩまたは識別のリストを配信するために、ネットワークは、非構造補足サービスデータ（Ｕｎｓｔｒｕｃｔｕｒｅｄ Ｓｕｐｐｌｅｍｅｎｔａｒｙ Ｓｅｒｖｉｃｅ Ｄａｔａ／ＵＳＳＤ）、ショートメッセージサービス（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ／ＳＭＳ）、マルティメディアブロードキャストマルチキャストサービス（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ／ＭＢＭＳ）、セルブロードキャスト（ＣｅｌｌＢｒｏａｄｃａｓｔ）、ＧＥＲＡＮ、ＵＴＲＡＮ、ＬＴＥ、ＷＬＡＮ、ＷｉＭａｘ、またはＣＤＭＡ２０００上においてＧＰＲＳ上で作動するＩＰパイプ等であるが、それらに限定されない無線輸送機構を使用し得る。識別ＵＲＩは、ＴＥＬ ＵＲＩ（Ｅ．１６４ ｎｕｍｂｅｒｓ）、公衆ユーザ識別を含むＳＩＰ ＵＲＩ、またはグローバルにルーティング可能なユーザエージェントＵＲＩ（Ｇｌｏｂａｌｌｙ Ｒｏｕｔａｂｌｅ Ｕｓｅｒ Ａｇｅｎｔ ＵＲＩ／ＧＲＵＵ）であり得る。リストはまた、ＵＳＩＭ、ＳＩＭ、Ｒ−ＵＩＭ、ＵＩＣＣ、またはコンパクトフラッシュ（登録商標）であり得るが、それらに限定されない、リムーバルメモリモジュールで設定され得る。代替として、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｃｏｎｆｉｇ−ｆｒａｍｅｗｏｒｋで表されるようなＳＩＰ ＣＯＮＦＩＧ ＦＲＡＭＥＷＯＲＫ等の、他の構成管理機構を使用することができる。

ＩＵＴ ＵＥのＵＲＩまたは識別のリストは、リストを再放送、送信、または伝達すること、リストが変更および更新された際のみ更新を放送すること、あるいは各コントローラＵＥが更新されたリストを要求することによって、周期的または非周期的に更新され得る。代替として、リストは、例えば、ユーザインターフェースを介して、更新された情報を各ＵＥに直接伝達することによって、または更新されたリストを含む物理的メディアをＵＥに提供することによって、更新され得る。ＵＥ上のＵＲＩのリストは、ＩＲＳセットを使用し得る同じＩＵＴグループに属する他のＵＥが登録または登録解除する場合に、更新される。ＩＵＴ ＵＥのＵＲＩまたは識別のリストを更新することは、Ｓ−ＣＳＣＦ、ＨＳＳ、またはＳＣＣ ＡＳ等のサービングネットワーク内のＨＳＳ、Ｓ−ＣＳＣＦ、ＳＣＣ ＡＳ等のサービングネットワークエンティティへ／から、ＵＥが常に追加（あるいは登録）または除去（あるいは登録解除）され得るため、重要であり得る。更新は、上記で説明されるようなエントリの削除、追加、または修正を含み得る。ＳＣＣ ＡＳ、ＤＭサーバ等のネットワークノードは、ＩＵＴ ＵＥのＵＲＩまたは識別のリストを提供する。

図４は、１つ以上のＩＵＴ ＵＥを識別するための例示的な許容ＩＵＴリスト管理オブジェクトを図示する。ＭＯ４４０は、固定ノードに対するゼロまたは１つのアカウントのプレースホルダとしての役割を果たし得る、ルートノード４４２を含む。許容ＩＵＴエントリ内部ノード４４４は、サブスクリプションセットＩＤのリストへの参照を提供するために使用され得、１つ以上のサブスクリプションセットＩＤのプレースホルダとしてランタイムノード４４６を含み得る。ランタイムノード４４６は、１つ以上のＩＵＴ ＵＥに対するＵＲＩまたは識別、デバイスニックネーム、および／またはメディアトークンのリストへの参照を含み得る。追加のランタイムノード４５０は、ＩＵＴ＿ＵＲＩ（すなわち、各ＩＵＴ ＵＥのＵＲＩまたは識別）、デバイスニックネーム、およびメディアトークンデータセットのプレースホルダとして使用され得る。ランタイムノード４５０は、ＩＵＴ＿ＵＲＩ、デバイスニックネーム、メディアトークン、または他のデータを記憶するためのリーフ４５２、４５４、および４５６を含み得る。

ＵＥに対して１つだけのサブスクリプションセットがある場合には、図示されたノードがＭＯに存在しなくてもよい。図示されたノードは、例えば、ユーザがＩＵＴ ＵＥに対する複数のサブスクリプションセットを有する場合、拡張可能性の目的で追加され得る。ＩＵＴ ＵＲＩ（すなわち、ＩＵＴ ＵＥのＵＲＩまたは識別）ノード、またはＩＵＴ ＵＲＩに対応するデバイスニックネームノード、あるいはＭＯの中の両方等であるが、それらに限定されない、ＭＯ内に含まれる種々のノードがあり得る（それらは強制的ではない）。デバイスに対するメディアトークンノードも、ＭＯに含まれ得る。図５ａおよび５ｂは、図４に示された許容ＩＵＴリストＭＯのパラメータおよびＤＤＦの詳細を図示する。ＩＵＴ ＵＥのＵＲＩまたは識別のリストを配信するために、基本ファイルも使用され得る。例示的な基本ファイル（Ｅｌｅｍｅｎｔａｒｙ Ｆｉｌｅ／ＥＦ）は、以下で規定れ、許容ＩＵＴリスト（ＥＦＡＩＵＴＬ）、ＩＵＴデバイスニックネーム（ＥＦＩＵＴＤＮ）、ＩＵＴメディアトークン（ＥＦＩＵＭＴ）、およびＩＵＴコントローラ指示（ＥＦＩＵＴＣＯＮＴＩ）定義を提供するために使用することができる。このようにしてＥＦを使用する場合に、ＥＦは、例えば、ＵＳＩＭ、ＳＩＭ、Ｒ−ＵＩＭ、ＵＩＣＣ、またはコンパクトフラッシュ（登録商標）のうちのいずれかの上に含まれ得る。

第１の例示的なＥＦは、ＥＦ_{ＡＩＵＴＬ}（Ａｌｌｏｗｅｄ ＩＵＴ Ｌｉｓｔｓ／許容ＩＵＴリスト）を含み、表６で図示されている。ＥＦは、ＵＥのＩＵＴ ＵＲＩ、すなわち、許容ＩＵＴリストに属するＩＵＴ ＵＥのＵＲＩまたは識別（あるいはデバイスニックネーム）に対するコーディングを含み得る。さらに、リストの中の各ＩＵＴ ＵＲＩ（またはデバイスニックネーム）について、対応するデバイスニックネーム（またはＩＵＴ ＵＲＩ）、メディアトークン、およびＩＵＴコントローラ指示へのリンクが提供され得る。許容ＩＵＴリストＴＬＶオブジェクトは、１つまたはいくつかのＩＵＴリストＴＬＶを含み得、各ＩＵＴリストＴＬＶは、ＴＥＬ ＵＲＩ、ＳＩＰ ＵＲＩ、ＧＲＵＵ、インスタンスＩＤ、ＩＭＥＩ等の中の１つ以上と関連付けられる。例示的な許容ＩＵＴリスト情報が、以下の表７で図示されている。

表７では、ＩＵＴリストタグ’８０’のコンテンツは、このＴＬＶの値フィールドの中で提供される、ＴＥＬ ＵＲＩ、ＳＩＰ ＵＲＩ、ＧＲＵＵ、インスタンスＩＤ、ＩＭＥＩ等の中の１つ以上に適用可能である、ＩＵＴサブスクリプションセットあたりの許容ＩＵＴリストを含み得る。

ＩＵＴリストタグ’８０’のコーディング例が図８に示されている。この実施例では、未使用のバイトを’ＦＦ’という値に設定することができる。

別の例示的なＥＦは、図９に示されたＥＦ_{ＩＵＴＤＮ}（ＩＵＴ Ｄｅｖｉｃｅ Ｎｉｃｋｎａｍｅ／ＩＵＴデバイスニックネーム）を含む。ＥＦは、ＩＵＴデバイスニックネームを含むように構成され得る。この実施例では、ＩＵＴ ＵＲＩと対応するデバイスニックネームとの間の関連は、ＥＦ_{ＡＩＵＴＬ}において提供される。概して、この実施例では、コーディングは、ＴＳ ３１．１０１で定義されるようなＵＣＳ２コードオプションのうちの１つを使用して行われ得る。

別の例示的なＥＦは、図１０に示されたＥＦ_{ＩＵＴＭＴ}（ＩＵＴ Ｍｅｄｉａ Ｔｏｋｅｎ／ＩＵＴメディアトークン）を含む。ＥＦは、ＩＵＴメディアトークンを含む。この実施例では、ＩＵＴデバイスＵＲＩと対応するメディアトークンとの間の関連は、ＥＦ_{ＡＩＵＴＬ}において提供される。

このＥＦについて、ＩＵＴメディアトークンタグ例が表１１に示されている。

このＥＦについて、ＩＵＴメディアトークン情報例が表１２に示されている。

表１２に示されたこの実施例では、ＩＵＴメディアトークンタグ’８０’は、ＩＵＴメディアトークンのコンテンツ、例えば、テキスト、ビデオ、音声等を有し得、コーディングは、例えば、ＴＳ ３１．１０１で定義されるようなＵＣＳ２コードオプションのうちの１つを使用して行われる。

別の例示的なＥＦは、図１３に示されたＥＦ_{ＩＵＴＣＯＮＴＩ}（ＩＵＴ Ｃｏｎｔｒｏｌｌｅｒ Ｉｎｄｉｃａｔｉｏｎ／ＩＵＴコントローラ指示）を含む。ＥＦは、ＩＵＴコントローラ指示を含み得る。ＩＵＴ ＵＲＩと対応するＩＵＴコントローラ指示との間の関連は、ＥＦ_{ＡＩＵＴＬ}において提供される。ＩＵＴコントローラ指示は、テキスト形式で、またはアイコンで提供され得る。

このＥＦでは、各指標種類に対する指標状態は、長さ１ビットであり得て、以下のように符号化または設定され得る。ビット値が１に等しい場合、指示をａｃｔｉｖｅに設定する。しかしながら、ビット値が０に等しい場合、指示をｉｎａｃｔｉｖｅに設定する。例えば、図２３は、参照ビット値位置を伴う指標例の説明図である。

ＩＵＴ ＵＥのＵＲＩまたは識別以外の追加の役立つ情報を伴わずに、ＩＵＴ ＵＥのＵＲＩまたは識別のリストを定義し、利用可能にすると、ＩＵＴ ＵＥは、他の識別されたＵＥに関する情報を収集するか、またはＳＣＣ ＡＳ、あるいはネットワークの他の構成要素と通信することによって、リストを修正するように一方的に作用することができる。一実施例では、ＩＵＴコントローラＵＥは、（例えば、２００ ＯＫ応答の中の受信されたＩＵＴコントローラ特徴タグを使用することによって）他のＩＵＴ ＵＥの能力を決定するように、およびどれが現在利用可能であり、ＩＵＴ対応であり、ＩＵＴコントローラ機能をＵＥに移転させることができるかを発見するように、リストの中で識別されるＵＥにＳＩＰ ＯＰＴＩＯＮＳを送信する。ＩＵＴコントローリＵＥは、ＳＩＰ ＯＰＴＩＯＮＳ要求等のメッセージに応答して返信される２００（ＯＫ）応答等のメッセージを介して、ＩＵＴコントローラ／コントローリ機能性のサポートを示すメディア特徴タグを含む、他のＵＥの能力を取得することができる。

ＩＵＴ ＵＥのＵＲＩまたは識別のリストを決定し、随意で、そのリストへの更新を有すると、例えば、ＳＣＣ ＡＳ、ＨＳＳ等に記憶されたネットワーク内のデータベースは、コントローラＵＥおよびコントローリＵＥを識別する情報を記憶し得る。情報は、コンピュータデータベースまたは他の電子記憶媒体等の任意の好適な媒体に記憶され得る。データベースは、システム要件に従って任意の適切なテーブル構造を含み得る。図２１は、（例えば、ホーム加入者サーバ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ／ＨＳＳ）内の）関連コントローラおよびコントローリＵＥを表すネットワーク内で情報を記憶するための例示的な構造の説明図である。図２１では、ユーザＡは、ＩＵＴセットに属する３つのデバイスを有し、デバイスＩは、ＩＵＴコントローラである。残りのデバイスは、ＩＵＴコントローリとして動作する。

図２２は、ＨＳＳ内等のネットワークに記憶された例示的な情報の説明図である。図２２は、それぞれ同じサブスクリプションメンバーセットの下にある、３人のユーザに対するデータを示す。ユーザＡおよびユーザＢが、ＩＵＴコントローラ機能を有し、ＩＵＴ承認規則を設定し得る一方で、ユーザＣは、以下のテーブルの中のＩＵＴコントローリとしての役割を果たす。

テーブル内で、サブスクリプションセットは、ローミング同意に従う同じサブスクリプションまたは異なるサブスクリプションに基づくＩＵＴ目的に対する、同じユーザの一式のＵＥである。サブスクリプションメンバーセットは、ＵＥ間移転を行うことが許可され、ローミング同意に従う同じ操作者のサブスクリプションまたは異なる操作者のサブスクリプションに属し得るメンバー間の一式のＵＥである。テーブル内で、ＩＵＴ ＵＥセットについて、各ＵＥは、ＩＵＴコントローラＵＥまたはＩＵＴコントローリＵＥとして区別される。各ＵＥは、ニックネーム（例えば、「ベッドルームＴＶ」、「私の携帯電話」等）でマッピングされ得る、ＧＲＵＵ、インスタンスＩＤ、またはＩＭＥＩ等のデバイスＩＤを有する。さらに、各ＵＥについて、テーブルは、そのＵＥに対して、あるメディア種類および形式をサポートする能力を定義する。

システム実装に応じて、コントローラおよびコントローリＵＥを表す情報は、種々のネットワーク構成要素に記憶され得、例えば、承認規則は、ＸＤＭＳに記憶され得、ＸＤＭＳに記憶された承認規則への文書リンクは、サブスクリプションデータベースに記憶され得る。一実施例では、各デバイスに対するメディアトークンのリンク、またはＩＵＴ制御のための種々の承認規則は、データベースまたは別のネットワークエンティティに記憶される。

ネットワークは、ＩＵＴを実装するためのサブスクリプションセット結合を行い得る。サブスクリプションセットは、操作者間同意（ネットワーク間で加入者情報および加入者のデバイス情報を交換する）に応じて、同じ操作者、または異なる操作者間のものであり得る。システムは、同じサブスクリプションセットに対するＩＵＴをサポートし得る。同じ加入者セットは、ネットワーク上のＩＵＴに対する「サブスクリプションセット指示」として示されるべきであり、指示は、同じサブスクリプションセットのメモリ（例えば、ＭＥ、ＵＳＩＭ、またはＩＳＩＭ）の中のＵＥに設定され得る。

ネットワークはまた、「最後の好ましい構成」を記憶する能力も有するべきである。例えば、最初の呼び出しで、ユーザが２つのＵＥの間でビデオ呼び出しセッションを分割した場合（ＩＤ Ｉを有するデバイス上のビデオ、およびＩＤ ＩＩを有するデバイス上のビデオ）、ネットワークは、この構成を後続のビデオ呼び出しのために持続させ、複数のＵＥ上の呼び出し結果をもたらすように設定することができる。

ネットワークはまた、「コントローラとしての役割を果たした最後のＵＥ」を記憶する能力も有するべきである。例えば、最初の通信で、協調セッションのために、ＵＥ−１は、ＩＵＴコントローラ機能としての役割を果たし、ＵＥ−２は、ＩＵＴコントローリＵＥとしての役割を果たしている。新しい協調セッションの最初の通信および確立の終了後、以前にコントローラＵＥとしての役割を果たしたＵＥ−１は、以前の通信の終了後に後続の新しい通信のために、この最後のコントローラＵＥ構成を持続させるように設定されたネットワーク内の情報に基づいて、コントローラＵＥになる。

ＵＥがネットワークに登録する場合に、ＵＥは、ＵＥを識別する情報をネットワークに伝送する。登録情報は、ＵＥがネットワーク内でコントローラ機能を割り当てられるという要求を含み得る。一実施例では、ＵＥは、識別目的で、ＩＭＳプライベート識別、ＩＭＳ公衆ユーザ識別、およびＵＥのインスタンスＩＤをネットワークに提供し、ＵＥがＩＵＴコントローラ対応であるという以前に識別されたような特徴タグを提供する。登録情報は、登録情報を調査することができるＳＣＣ ＡＳに提供され得る。次いで、ＳＣＣ ＡＳは、ＵＥおよびその加入者情報を記憶するデータベースに問い合わせをして、加入者および／またはＵＥの組み合わせがコントローラになることを許可されているかどうかを決定し得る。データベースは、ローカルまたは外部にあり得る。外部データベース例は、ＨＳＳ、およびＳＣＣ ＡＳの中の内部データベースを含む。登録情報は、ＳｈインターフェースまたはＣｘインターフェースを介したＳｅｒｖｉｃｅＩｎｆｏフィールドを使用して伝送され得る。

上で記載される識別情報の組み合わせをチェックすることによって、ＳＣＣ ＡＳは、ＵＥがコントローラとなる権限を与えられているか否かを決定することができる。したがって、ＳＣＣ ＡＳは、プライベートＩＤをチェックし得、この場合、全てのデバイスがコントローラになることを許可される。ＳＣＣ ＡＳは、プライベートＩＤおよびＩＭＥＩをチェックし得、この場合、このプライベートＩＤとともに使用されているデバイスのみがコントローラであり得る。または、ＳＣＣ ＡＳは、プライベートＩＤ、ＩＭＥＩ、および公衆ＩＤをチェックし得、この場合、登録されているデバイス（ＩＭＥＩ）および公衆ユーザＩＤと組み合わせたプライベートＩＤがコントローラであり得る。

いくつかの実装では、ＵＥが登録された後、ＳＣＣ ＡＳは、ＵＥがコントローラとして承認されていることを識別するために後続のＳＩＰ方法で使用される、トークン、フラグ、または指示をＵＥに提供する。トークンまたは指示は、特徴タグ、新しいＰヘッダ、またはＸＭＬ本文に含まれ得る。代替として、ＳＣＣ ＡＳは、コントローラＵＥとなることが可能であるものとして、ＳＣＣ ＡＳの中のＵＥの登録記録をマークし得る。したがって、ＵＥがＩＮＶＩＴＥまたは別のＳＩＰ ＭＥＴＨＯＤを送信する場合に、ＳＣＣ ＡＳは、その結合をチェックして、ＵＥがコントローラ機能性を果たすことができるかどうかを決定し得る。

システムはまた、追加のチェックを行って、システムの中のデバイスがすでにコントローラとしての役割を果たしているかどうかを決定し得、別のデバイスがコントローラ機能性を要求する場合、システムは、要求を拒絶し、指示をデバイスに提供するか（指示は、帯域外信号伝達機構を含み得る）、または上で説明される規則によって要求を受け入れ得る。

特定のＵＥに対するコントローラ機能は、コントローラＵＥと関連付けられた同じユーザによって操作される他のＵＥを制御することに限定され得る。しかしながら、本システムのいくつかの実装では、１人のユーザの特定のコントローラＵＥは、特定のコントローラＵＥおよび他のＵＥが同じサブスクリプションメンバーシップの下にある場合、他のユーザに属する他のＵＥ上でコントローラ機能を有し得る。その場合、特定のＵＥは、コントローラ機能を果たすために要求した標的ＵＥによってコントローラ機能を果たすことができることを許可するために、ユーザが承認規則を設定することを可能にする機構を提供し得、ＳＣＣ ＡＳまたはＸＤＭＳ等のネットワークは、承認規則を処理し、標的ＵＥがコントローラ機能を果たすことを可能にするかどうかを決定し得る。コントローラ機能を果たすために、ＵＥが、既存のコントローラＵＥからの同意、またはコントローラＵＥが指定した１つ以上の標的ＵＥの同意を取得することが必要であり得る。場合によっては、無線サーバの中の任意の標的ＵＥが、コントローラ機能を果たす権限を与えられ得る。ＵＥは、時間的制限、機能的制限（例えば、特定のメディア種類の移転のみを可能にする）に基づいてコントローラ機能を果たし得、または永続的であり得る。コントローラ機能を他のユーザによって操作されるＵＥに移転するために、任意のコントローラＵＥが、時間的、機能的、または他の許可規則を設定することを割り当てられ得る。

図６は、承認が単一のコントローラＵＥのみから要求される場合、ＩＵＴコントローラ機能をＵＥに提供するためのフロー例を図示する。ステップ６０１では、コントローリＵＥは、ＩＵＴコントローラ機能を受信するように、要求メッセージをネットワークに送信する。ステップ６０２では、サーバ（例えば、Ｓ−ＣＳＣＦまたはＳＣＣ ＡＳを使用する）は、サーバ自体に、またはコントローラＵＥによって設定されるＸＤＭＳのような別のネットワークエンティティに記憶された承認規則を調べ、ＩＵＴコントローラ機能の割当に適用する時間的、機能的、または他の制限がないこと、ならびにＩＵＴコントローラ割当のための承認がコントローラＵＥによって承認されることのみが必要であることを発見する。ステップ６０３では、ネットワークは、コントローラ機能を受信する標的コントローリＵＥを承認または承諾するように、要求メッセージをメッセージコントローラＵＥに送信する。ステップ６０４では、コントローラＵＥは、コントローラＵＥのユーザが要求を受け入れた場合にＯＫ応答を送信する。このステップでは、コントローラＵＥのユーザは、一時的／永久的許可を設定し得る。場合によっては、一時的／永久的許可へのこれらの制限は、ネットワーク内で事前定義される。ステップ６０５では、サーバは、コントローラ機能をコントローリＵＥに与えるために、ＯＫ応答を送信する。ステップ６０４でのＯＫ応答は、ステップ６０５のものとは異なり得る。サーバは、この応答に、ａ）一時的または永久的パスワード、およびｂ）トークン、識別子、または証明書を含み、標的コントローリＵＥがコントローラ機能を得ることを可能にし得る。標的ＵＥが、ＩＵＴコントローラとしての役割を果たす一時的許可のみを受信した場合、現在のセッションを解放または退出するか、あるいはコントローリＵＥ上のいくつかの設定またはパラメータを変更するためのユーザインターフェースを提供するプログラムを終了すると、一時的パスワードが無効になり得、したがって、標的ＵＥはＩＵＴコントローラ機能を保持しない。

図７は、承認または同意が１つより多くのコントローラＵＥから要求される場合、ＩＵＴコントローラ機能をＵＥに提供するためのフロー例を図示する。ステップ７０１では、コントローリＵＥは、ＩＵＴコントローラ機能を受信するように要求メッセージをサーバに送信する。ステップ７０２では、サーバは、既存のＩＵＴコントローラ機能を有するＵＥを識別し、識別されたコントローラによって設定された承認規則を調べ、サーバがＩＵＴコントローラ機能を有する１つ以上のユーザ（またはユーザのＵＥ）による承認または同意を必要とすることを発見する。ユーザは、自分自身および／またはコントローラ機能を有する他のユーザを指定し得る。ステップ７０３では、ネットワークは、ＩＵＴコントローラ機能を受信する権限を標的コントローリＵＥに与えるように、要求メッセージをコントローラＵＥに送信する。ステップ７０４では、指定されたユーザが要求を受け入れた場合、指定されたユーザのＵＥがＯＫ応答を送信する。指定されたコントローラＵＥは、ＩＵＴコントローラ機能の提供を承認する時に種々の許可または制限を設定し得る。代替として、種々の時間的、機能的、または永久的制限が、コントローラＵＥを伴うユーザによって定義され、ネットワーク内で伝送され得る。ステップ７０５では、サーバは、全ての指定されたユーザがコントローラ機能を与えることを承認した場合、ＯＫ応答を送信する。ステップ７０４のＯＫ応答は、ステップ７０５のものとは異なり得る。コントローラＵＥがＩＵＴコントローラ機能の提供に許可または他の制限を設定した場合、ネットワークは、標的コントローラＵＥに承認を発行する場合に、これらの制限を含める。標的ＵＥが、ＩＵＴコントローラとしての役割を果たす一時的許可のみを受信した場合、現在のセッションを解放または退出するか、あるいはコントローリＵＥ上のいくつかの設定またはパラメータを変更するようにユーザインターフェースを提供するプログラムを終了すると、一時的パスワードが無効になり得、したがって、標的ＵＥはＩＵＴコントローラ機能を保持しない。

システム実装に応じて、ＩＵＴコントローラＵＥは、セッション確立前、セッション確立中、または特定のセッションが確立された後に決定され得る。場合によっては、ＩＵＴコントローラ機能性をサポートする能力を有し、初期移転要求を送信するＵＥは、最初にＩＵＴコントローラＵＥとして割り当てられる。ＩＵＴコントローラＵＥがセッション確立前に決定される場合、ＵＥは、ＩＵＴコントローラＵＥとして動作するＵＥの能力および関連ユーザ選好に基づいて、ＩＵＴコントローラ機能の割当を要求し得る。ＵＥは、ユーザが、ＩＵＴ ＵＥの利用可能なＵＲＩまたは識別のリストから、能動ＩＵＴコントローラとして１つのＵＥを割り当てることのみを可能にし得る。異なるＩＵＴコントローラ設定を同じユーザに対する異なるＵＥに設定することができる。ＩＵＴコントローラがセッション確立時に割り当てられる場合、ＵＥは、例えば、上記で説明されるような「Ａｃｔｉｖｅ」に設定されたＩＵＴコントローラ特徴タグを伴うＳＩＰ ＩＮＶＩＴＥ、ＳＩＰ ｒｅ−ＩＮＶＩＴＥ、またはＳＩＰ ＲＥＦＥＲ要求等のセッション設定要求を送信し得る。

場合によっては、ＳＣＣ ＡＳは、ＲＦＣ ３８４１に従うＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダの中にＩＵＴコントローラを示すメディア特徴タグを含むことによって、セッションへの全ての終端招待がＩＵＴコントローラであるＵＥに送られることを確実にし得る。

場合によっては、任意の進行中のセッションに対する単一のＩＵＴコントローラＵＥを割り当てることが望ましくてもよい。したがって、システムが単一のＩＵＴコントローラＵＥを割り当てるのみであることを確実にするために、特定のＵＥにＩＵＴコントローラ機能が割り当てられるという要求を受信した後、ネットワークは、要求ＵＥがＩＵＴ制御が可能であること、例えば、ＩＵＴコントローラ能力を示すメディア特徴タグがｃｏｎｔａｃｔヘッダの中に存在すること、要求ＵＥがＩＵＴコントローラとなる権限を与えられていること（コントローラ機能性が上記で説明されるように許可されているかどうかを確認するように、このＵＥの登録と関連付けられたＩＭＳプライベートユーザＩＤをチェックすることによって、承認が達成され得る）、ネットワークノードからの方針、例えば、１つだけのＵＥが任意の進行中のセッションのためのＩＵＴコントローラになるべきであるというＳＣＣ ＡＳまたは方針データベースからの方針があること、および同じユーザに対して他の割り当てられたＩＵＴコントローラＵＥが存在しないことを検証し得る。これら全ての条件が満たされた場合、ネットワークは、要求ＵＥがＩＵＴコントローラとなるものであるという肯定的応答を送信する。ネットワークは、（例えば、ＧＲＵＵを使用する）どのＵＥにＩＵＴコントローラ機能が割り当てられているかを特定する指示を他のＩＵＴ ＵＥに送信し得る。これは、通知に登録しているＵＥによって達成さ得、コントローラが割り当てられている時には、通知がコントローラのＧＲＵＵを含むＵＥに送信される。上記の条件のうちの１つ以上が満たされない場合、ネットワークは要求を拒絶し得る。要求を拒絶する際に、ネットワークは、要求を拒絶する理由を説明する理由コードを含み得る。

特定のＵＥをコントローラとして登録する場合に、承認されたユーザおよび／または承認されたＵＥのみにコントローラ機能が割り当てられることを確実にするように認証または承認機構を提供することが重要であり得る。一実施例では、ＩＵＴサブスクリプションは、ユーザサブスクリプションの他に家族サブスクリプションである。家族サブスクリプションは、父親、母親、および子供のサブスクリプションを含み得る。この実施例では、家庭サブスクリプション間の特定のＵＥが、コントローラＵＥになることを許可されていることを検証するために、ネットワーク内の承認機能が使用され得る。１つのネットワーク実装例は、２つの別個のレベルの承認を提供する。

第１に、ネットワークは、加入されているデバイスが、同じサブスクリプションメンバーに属することを許可されているかどうかを決定する。これは、フィルタ基準の結果であり得るが、次いで再度、ＳＣＣ ＡＳがこれを行っているものであるため、他のフィルタ基準がＳＩＰ方法をＡＳに送信し得る。これがＳＩＰ ＲＥＧＩＳＴＲＡＴＩＯＮを行うＵＥの結果としてＩＵＴ対応であるかどうかを示す、ＳＣＣ ＡＳまで透過的に進むＨＳＳからのＳｅｒｖｉｃｅ Ｉｎｆｏフィールドの中の何かがあり得る。例えば、場合によっては、加入されているデバイスがコントローラ機能を果たすことが可能であるかどうかを決定する情報がＳＣＣ ＡＳにあり得る。代替として、情報は、ＩＭＳＩまたはプライベート識別を介して提供され得る。例えば、全ての家族は同じ個人ネットワークに属するが、父親のみが、母親および子供の他のデバイス上でコントローラとしてデバイスを設定する能力を有する。

第２に、ＳＣＣ ＡＳは、登録ＵＥが、ＩＵＴコントローラになることを許可されているかどうかを決定する。これは、登録されているＵＥのＧＲＵＵ情報をチェックすることによって行われ得る。この情報は再度、ＨＳＳまたはＳＣＣ ＡＳ内に記憶され得、それにより、加入者は、どのデバイスがコントローラになり得るかを示す。代替として、ＵＥが登録する時にプライベートＩＤがあるという点で、情報全体を登録メッセージにリンクすることが可能であり得る。プライベートＩＤは、ＵＥがＩＵＴを使用する能力を有するか否かを決定するために使用され得る。「コントローラを割り当てる（ａｓｓｉｇｎ ｃｏｎｔｒｏｌｌｅｒ）」または「制御される（ｂｅ ｃｏｎｔｒｏｌｌｅｄ）」であり得る、ＩＭＳＩプライベートＩＤ等の能力があり得る。よって、「コントローラを割り当てる」を伴うプライベートユーザＩＤに由来する任意のＵＥは、そのＵＥをコントローラとして設定することを許可される。

ＩＲＳにアクセスすることができるＩＭＳプライベートＩＤは、あるプロファイルを有することができ、例えば、家庭サブスクリプションは、父親、母親、および２人の子供といった４つのＩＭＳプライベートＩＤを含み得る。父親は、コントローラを割り当てることを許可されている唯一のものである。これらは、サブスクリプションメンバーセットと呼ばれ得る全て同じサブスクリプションメンバーである。

２つのＩＭＳプライベートＩＤが、グループに対するコントローラを割り当てることができると仮定すると、権限を無効にしなければならず、またはコントローラになることを許可されている場合、別のＵＥがコントローラになるかどうかを通知される。現在コントローラである場合、変更を拒否するか、または変更を許可することができる。これは、ネットワーク内の状態の通知に登録することを必要とし、ネットワークが特定の方針を有するという通知を受信すると、制御能力を変更することができるかどうかを他のコントローラに尋ねることを必要とする。

ＩＵＴコントローラＵＥは、セッション確立前、セッション確立中、または別のＵＥへのＩＵＴコントローラ移転機能を要求する時に決定することができる。セッション確立前にＩＵＴコントローラＵＥを決定する場合に、ＵＥは、ＵＥの能力およびユーザ選好に基づいてＩＵＴコントローラ機能を有するための要求を送信する。ＵＥは、ユーザが、ＩＵＴ ＵＥに対するＵＲＩまたは識別から、１つより多くのＵＥを能動ＩＵＴコントローラにすることを可能にし得る。セッション確立中にＩＵＴコントローラＵＥを決定する場合、および任意のＩＵＴコントローラ対応ＵＥによって別のＵＥへのＩＵＴコントローラ機能移転を要求する場合に、ＵＥは、ＩＵＴコントローラ機能を示すメディア特徴タグを伴うＳＩＰ ＩＮＶＩＴＥ、ＳＩＰ ｒｅ−ＩＮＶＩＴＥ、またはＳＩＰ ＲＥＦＥＲ要求等の要求を送信する。メディア特徴タグは、移転されるＩＵＴコントローラ機能を識別する、ＩＭＳ通信サービス識別子（ＩＭＳ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｅｒ／ＩＣＳＩ）値またはＩＭＳアプリケーション参照識別子（ＩＭＳ Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｉｄｅｎｔｉｆｉｅｒ／ＩＡＲＩ）であり得る。ネットワークが要求を受信すると、ネットワークは、要求ＵＥがＩＵＴコントローラになることが可能であること、要求ＵＥがＩＵＴコントローラとなる権限を与えられていること（コントローラ機能性が許可されているかどうかを確認するように、このＵＥの登録と関連付けられたＩＭＳプライベートユーザＩＤをチェックすることによって、承認が達成される）、および複数のＵＥが任意の進行中のセッションまたは同じ協調セッションのためのＩＵＴコントローラになるものであるという（例えば、方針データベースからの）方針があることをチェックする。

これら全ての条件が満たされた場合、ネットワークは、要求ＵＥがＩＵＴコントローラとなるものであるという肯定的応答を送信する。ネットワークは、（例えば、ＧＲＵＵを使用する）どのＵＥがＩＵＴコントローラであるかという指示を他のＩＵＴ ＵＥに送信し得る。上の条件のうちの１つまたは１つより多くが満たされない場合、ネットワークは要求を拒絶し、随意で、要求が拒絶された理由を説明する理由コードを提供し得る。

ＩＵＴコントローラＵＥとして確立されると、コントローラＵＥは、メディア種類をあるコントローリＵＥに移転するように、またはＩＵＴコントローラ機能を他のＵＥに移転するように、ネットワークに要求を発行し得る。ＩＵＴコントローラＵＥがメディアおよび／またはコントローラ機能をコントローリＵＥに移転するために、ＩＵＴコントローラＵＥは、ＳＩＰ ＲＥＦＥＲ要求等のメッセージを、ネットワーク、例えば、ＳＣＣ ＡＳに送信する。ＳＩＰ ＲＥＦＥＲ要求は、ＳＣＣ ＡＳがＲｅｆｅｒ−Ｔｏヘッダの中のＵＲＩによって識別されるコントローリＵＥに送信することになるＳＩＰ ＩＮＶＩＴＥ要求またはＳＩＰ Ｒｅ−ＩＮＶＩＴＥ要求のＳＩＰヘッダおよび／またはＳＤＰコンテンツのうちの少なくともいくつか等の、ＲＥＦＥＲ−ＴＯヘッダの中のＵＲＩ内に埋め込まれた別のメッセージを含み得る。コントローリＵＥに送信されるＳＩＰ ＩＮＶＩＴＥ要求またはＳＩＰ ＲＥ−ＩＮＶＩＴＥ要求は、コントローリＵＥに移転されるメディア種類を識別するデータを含み得る。制御がそれに移転されているとコントローリＵＥが決定することを可能にするために、ＳＩＰ ＩＮＶＩＴＥ要求はまた、ＩＵＴコントローラ機能を識別する識別子も含む。この識別子は、ａ）ＳＩＰヘッダフィールドの中のＩＵＴコントローラ機能を識別するＵＲＩ、ｂ）Ｒｅｑｕｅｓｔ−ＵＲＩの中またはＴＯヘッダ内のＵＲＩの中の新規ＳＩＰ ＵＲＩパラメータ（すなわち、ＩＵＴコントローラＵＲＩパラメータ）、ｃ）（ＲＦＣ ３８４１の通りに）Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれるＩＵＴコントローラを示すメディア特徴タグ、ｄ）Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれる「ｇ．３ｇｐｐ．ａｐｐ＿ｒｅｆ」特徴等の、移転されるべきＩＵＴコントローラ機能を識別するＩＭＳ通信サービス識別子（ＩＭＳ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｅｒ／ＩＣＳＩ）値またはＩＭＳアプリケーション参照識別子（ＩＭＳ Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｉｄｅｎｔｉｆｉｅｒ／ＩＡＲＩ）（ＵＥは、以前の登録場合に、ＲＦＣ ３８４０の通りにＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中にメディア特徴タグを登録しているであろうことに留意されたい）、またはｅ）ＩＵＴコントローラ機能が移転されることを示す新規ＳＩＰヘッダフィールド（例えば、ＲＦＣ ３４２７に従ったＰヘッダ）を含み得る。別の実装では、３．ｇｐｐ．ｉｕｔ特徴タグは、コントローラ機能が移転されていることを識別するように、追加のオプションを伴って拡張することができる。実施形態例が以下の表１４に含まれる。

他の実施例はまた、ＵＥがコントローラ機能性を移転するための要求を行う場合に、ＵＥがメディア特徴タグをコントローリ（ｃｏｎｔｒｏｌｌｅｅ）に設定することも含むことができる。ＳＣＣ ＡＳが要求を受信すると、ＳＣＣ ＡＳは、メッセージが受信されたＵＥの状態をチェックする。ＵＥの状態がコントローラとして割り当てられている場合、ＵＥは、ＵＥがコントローラ機能性をメッセージの中で識別された標的デバイスに伝達したがっていることを知る。ＳＣＣ ＡＳがメッセージを標的デバイスに送信する場合に、メッセージは、コントローラ機能性がＵＥに割り当てられていることを識別するトークンまたは識別子を含み得る。

図８の以下の実施例は、ＩＵＴコントローラＵＥによって要求されるように、第１のコントローラから別のＵＥにＩＵＴコントローラ機能および／またはメディア種類を移転するためのフロー例を図示する。実施例では、ＵＥ−１は、ＳＣＣ ＡＳにおいて固着されるリモートパーティとの確立されたマルチメディアセッションを有する。マルチメディアセッションは、２つのメディア構成要素（メディアＡおよびメディアＢ）を含み、ＵＥ−１は、協調セッション制御およびメディア種類のうちの１つ（メディアＡ）を別のＵＥ−２に移転することを希望する。実施例では、ＵＥ−１およびＵＥ−２は、同じアクセスネットワークベアラまたは異なるネットワークアクセスベアラを使用して、登録していてもよい。ＵＥ−１およびＵＥ−２は、異なるネットワーク間インターネットプロトコル接続（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｃｏｎｎｅｃｔｉｏｎ Ａｃｒｏｓｓ Ｎｅｔｗｏｒｋ／ＩＰ−ＣＡＮ）、例えば、ＵＥ−１上で３ＧＰＰ ＩＰ−ＣＡＮ、ＵＥ−２上で非３ＧＰＰ ＩＰ−ＣＡＮを使用し得る。固着されたＳＣＣ ＡＳまたは別のネットワークエンティティは、各ＵＥにどのようなベアラを使用するかを決定し得る。ＵＥ−１およびＵＥ−２が同じ加入者に属することが仮定される。

ＵＥがＩＰ ＣＡＮを介してＩＰ接続を獲得する時はいつでも、ＵＥは、ＴＳ ２３．２２８で定義されているようにＩＭＳに登録することができる。その場合、ユーザプロファイルは、ＩＭＳプライベートユーザ識別に結びつけられるＣ ＭＳＩＳＤＮを含む。Ｓ−ＣＳＣＦは、ＳＣＣ ＡＳに向けた第三者登録を行うために、ＴＳ ２３．２１８で定義された手順に従い得る。メディアにＣＳアクセスを使用する場合、ＵＥは、ＴＳ ２３．２９２で定義されているようにＩＭＳに登録され得る。ＴＳ ２３．２２８で定義されているようにＩＭＳに登録する場合に、ＵＥは、ＩＵＴに対するコントローラまたはコントローリ機能性をサポートするための能力を示し得る。Ｓ−ＣＳＣＦがＳＣＣ ＡＳに向けた第三者登録を行うためのＳＩＰ ＲＥＧＩＳＴＥＲ要求例が、以下の表１５に示される。

図８は、ＩＵＴコントローラＵＥによって要求されるように、ＩＵＴコントローラ機能をＵＥに移転するためのフローを図示する。ステップ８０１では、ＵＥ−１は、協調セッション制御およびメディア種類（メディアＡ）をＵＥ２に移転することを決定する。ＵＥ−１は、要求をＳＣＣ ＡＳに送信し、現在の協調セッション制御およびメディア種類（メディアＡ）がＵＥ−２に移転されることを示す。ステップ８０２では、ＳＣＣ ＡＳ（または任意の他のネットワーク構成要素）は、移転要求を識別し、ＵＥ−２がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、ＵＥ−２が、適切な能力、例えば、ＲＦＣ ３８４０の通りの特徴タグを登録していることを検証し、デバイス能力、ユーザ選好、および／またはネットワークの中の方針に基づいて、ＵＥ−２にどのようなベアラを使用するかを決定し、選択されたベアラがＵＥ−２によって登録されているかどうかを決定する。ステップ８０３では、ＳＣＣ ＡＳは、ＧｍまたはＩ１参照点、あるいは協調セッション制御およびメディア種類（メディアＡ）が移転されるものであることを示す他のデータ移転方法を使用して、セッション確立要求メッセージを生成し、ＵＥ−２に送信する。ステップ８０４では、協調セッション制御がＵＥ−２とＳＣＣ ＡＳとの間で確立される。ＵＥ−２は、確立された協調セッションのためのコントローラＵＥになる。ステップ８０５では、ＵＥ−２とリモートパーティとの間でメディア種類（メディアＡ）を伝達するためのセッションが確立される。この場合に、遠隔レッグがそれに応じて更新される。ＵＥ−２上での協調セッション制御およびメディア種類（メディアＡ）の確立の成功後、ＳＣＣ ＡＳは、ステップ８０６で、移転要求メッセージへの応答メッセージまたは移転要求メッセージの結果をＵＥ−１に通知する別のメッセージ（例えば、ＲＦＣ ３５１５の通りにＳＩＰ ＲＥＦＥＲ要求の結果として受信された最終応答に対して送信される、ＳＩＰ ＮＯＴＩＦＹ要求）をＵＥ−１に送信する。最終的に、ステップ８０７では、ＵＥ−１上の以前のメディア種類（メディアＡ）セッションが解放され得、協調セッション制御が解放される。この場合に、ＵＥ−１がコントローリＵＥになる。

図９は、ＵＥ−１からＵＥ−２にＩＵＴコントローラ機能性を移転するためのフロー例を図示し、着信セッション要求は、Ｇｍ参照点上で送達され、メディアは、回路交換ネットワークを介して伝送される。ＭＳＣサーバ進化型ＩＣＳは、図示されたフローを実装するための相互作用エンティティの例示的なエンティティであり得る。代替として、相互作用エンティティは、レガシーＭＳＣサーバおよびＭＧＣＦから成り得る。相互作用エンティティがＭＳＣサーバおよびＭＧＣＦに対応する場合に、ＣＳベアラ設定手順は、ＴＳ ２３．２９２の図７．４．２．２．２−２のステップ１１−１７に従う。

図９を参照すると、ステップ９０１および９０２では、ＵＥ−１は、協調セッション制御およびメディアＡをＵＥ−２に移転することを決定する。したがって、ＵＥ−１は、ＩＭＳエンティティを介して要求をＳＣＣ ＡＳに送信し、現在の協調セッション制御およびメディアＡがＵＥ−２に移転されることを示す。この実施例では、ＩＵＴコントローラＵＥは、１）ソースＵＥ（Ｆｒｏｍヘッダフィールド、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダフィールド、またはＰ−Ｓｅｒｖｅｄ−Ｕｓｅｒヘッダフィールド内に含まれ得る）、２）標的ＵＥ（Ｒｅｆｅｒ−Ｔｏヘッダフィールド内に含まれ得る）、３）ＩＵＴコントローラ移転指示（Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダフィールド内に含まれ得、例えば、ＩＮＶＩＴＥ要求に埋め込まれるか、またはＲｅｆｅｒ−Ｔｏヘッダフィールドに埋め込まれる）、４）Ｔａｒｇｅｔ−Ｄｉａｌｏｇ−ＩＤ（標的ＵＥがすでに協調セッションの一部である場合に、既存のダイアログ識別子を含むＴａｒｇｅｔ−Ｄｉａｌｏｇヘッダフィールド内に埋め込まれ得、これが標的ＵＥに対する新しいセッションである時には、Ｔａｒｇｅｔ−Ｄｉａｌｏｇ−ＩＤがない）、および５）メディア種類（例えば、音声、ビデオ、ファイル等）（例えば、Ｒｅｆｅｒ−Ｔｏヘッダフィールドに含まれる）といった、情報を有する要求を伝送することによって、ＳＩＰ ＲＥＦＥＲ等を介して移転要求を開始することができる。

ステップ９０５では、ＳＣＣ ＡＳは、要求（例えば、ＳＩＰ ＲＥＦＥＲ要求）を識別し、ＵＥ−２がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、ＵＥ−２が、適切な能力、例えば、ＲＦＣ ３８４０の通りの特徴タグを登録していること、デバイス能力、ユーザ選好、および／またはネットワークの中の方針に基づいて、ＵＥ−２にどのようなベアラを使用するか、選択されたベアラがＵＥ−２によって登録されているかどうかを検証する。ＵＥ−２がコントローラとしての役割を果たすことを許可されていない場合、ＳＣＣ ＡＳは要求を拒絶し得る。ＵＥ−２が協調セッション制御移転を拒絶する場合、拒絶を示す好適な応答が送信される。応答は、移転を拒絶する理由を示し得る。そのような応答は、提供されるメディア種類またはコーデックが受諾不可能である場合に、ＳＩＰ ４８８（Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ／受諾不可能）であり得る。失敗の理由を示す応答に、警告が含まれ得る。移転の失敗を示すＵＥ−１へのメッセージは、ＵＥ−２からの応答のＳＩＰｆｒａｇを本文に含む、ＳＩＰ ＮＯＴＩＦＹ要求に含まれ得る（例えば、ＳＩＰ ４８８（Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ／受諾不可能）応答）。

ステップ９０６および９０７では、ステップ９０５で受信されたメッセージが、音声またはビデオに対するメディア移転を含む場合には、ＳＣＣ ＡＳは、セッション確立要求メッセージを生成し、ＵＥ−２に送信する。ＳＩＰ ＩＮＶＩＴＥ要求、またはＳＩＰ ＲＥＦＥＲを受信した後に送信されるＳＩＰ ｒｅ−ＩＮＶＩＴＥ等のセッション確立要求メッセージは、１）ソースＵＥ（Ｒｅｆｅｒｒｅｄ−ＢｙヘッダフィールドおよびＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダフィールド、Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダフィールド、またはＰ−Ｓｅｒｖｅｄ−Ｕｓｅｒヘッダフィールド内に含まれ得る）、２）標的ＵＥ（ＴｏヘッダフィールドおよびＲｅｑｕｅｓｔ−ＵＲＩフィールドに含まれ得る）、３）ＩＵＴコントローラ移転指示（Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダフィールドに含まれ得る）、４）Ｔａｒｇｅｔ−Ｄｉａｌｏｇ−ＩＤ（標的ＵＥがすでに協調セッションの一部である場合に、既存のダイアログ識別子を含むＴａｒｇｅｔ−Ｄｉａｌｏｇヘッダフィールド内に埋め込まれ得、これが標的ＵＥに対する新しいセッションである時には、Ｔａｒｇｅｔ−Ｄｉａｌｏｇ−ＩＤがない）、および５）メディア種類（例えば、音声、ビデオ、ファイル等）（例えば、ＩＮＶＩＴＥ要求に埋め込まれたＳＤＰに含まれ得る）といった、情報を含む。要求はまた、このセッションを識別するＣＳ呼び出しセットに使用される、ＰＳＩ ＤＮを含み得る。ＳＤＰが、ベアラがＣＳ上で設定されることを可能にするＭ線を含む場合には、ステップ９１０では、ＵＥ−２は、Ｂ番号としてＰＳＩ ＤＮを使用して、ＣＳ呼び出し設定メッセージを相互作用エンティティに送信する。ステップ９１１では、ＩＣＳ用の進化型ＭＳＣサーバ等の相互作用エンティティは、呼び出し続行メッセージで応答し、ＣＳベアラ制御信号伝達経路を設定し始める。ステップ９１２および９１３では、相互作用エンティティは、ＩＭＳエンティティを介してＳＣＣ ＡＳに向けてＳＩＰ ＩＮＶＩＴＥを送信する。ＳＣＣ ＡＳがステップ９１３でＩＮＶＩＴＥを受信する場合に、ＳＣＣ ＡＳは、セッション情報を回収するためにＰＳＩ ＤＮを使用し得、ステップ９１６では、相互作用エンティティがＩＭＳエンティティを介してＳＣＣ ＡＳからＳＩＰ ２００ ＯＫを受信する場合に、相互作用エンンティティは、受信されたＳＩＰ ２００ ＯＫ応答をＣＯＮＮＥＣＴメッセージにマップし、それをＵＥ−２に送信する。ステップ９１７では、ＣＯＮＮＥＣＴメッセージを受信する場合に、ＵＥ−２は、ＣＯＮＮＥＣＴ ＡＣＫメッセージを相互作用エンティティに送信する。ステップ９２０では、ＵＥ−２、相互作用エンティティ、およびＳＣＣ ＡＳは、ＣＳベアラ制御信号伝達経路の設定を完了する。ＵＥ−２とＳＣＣ ＡＳとの間の協調セッション制御が確立される。ＵＥ−２は、確立された協調セッションのためのコントローラＵＥになる。ステップ９２１では、ＵＥ−２とリモートパーティとの間のメディア種類（メディアＡ）通信の交換が確立される。この場合に、ＳＤＰ情報が変更される必要があれば、それに応じて遠隔レッグが更新される。ステップ９２２および９２３では、ＵＥ−２上での協調セッション制御およびメディア種類（メディアＡ）の確立の成功後、ＳＣＣ ＡＳは、移転要求メッセージへの応答メッセージまたはＳＩＰ ＮＯＴＩＦＹ等を使用して移転要求メッセージの結果をＵＥ−１に通知する別のメッセージをＵＥ−１に送信する。最終的に、ステップ９２６では、ＵＥ−１上の以前のメディア種類（メディアＡ）セッションが解放され得、協調セッション制御が解放される。ＵＥ−１は、コントローリＵＥになる。上記の実施例では、従来の確認メッセージの通信を伴うステップは説明されていないことに留意されたい。ＵＥ−１からＵＥ−２上で全てのメディアフローを移転する場合、ＵＥ−１上の既存のセッションは解放され得る。

図１０は、ＵＥ−１からＵＥ−２にコントローラ機能性およびメディアを移転するためのフローを図示し、着信セッション要求は、Ｉ１参照点上で送達され、メディアは、ＣＳネットワークを介して伝送される。１つの実装では、ＭＳＣサーバ進化型ＩＣＳは、相互作用エンティティの例示的なエンティティであり得る。代替として、相互作用エンティティは、レガシーＭＳＣサーバおよびＭＧＣＦから成り得る。相互作用エンティティがＭＳＣサーバおよびＭＧＣＦに対応する場合に、ＣＳベアラ設定手順は、ＴＳ ２３．２９２の図７．４．２．２．２−２のステップ１０１１−１０１７に従う。

ステップ１００１および１００２では、ＵＥ−１は、協調セッション制御およびメディアＡをＵＥ−２に移転することを決定する。したがって、ＵＥ−１は、ＩＭＳエンティティを介して要求をＳＣＣ ＡＳに送信し、現在の協調セッション制御およびメディアＡがＵＥ−２に移転されることを示す。１つの実装では、ＵＥ−１は、１）ソースＵＥ（ヘッダフィールド、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダフィールド、またはＰ−Ｓｅｒｖｅｄ−Ｕｓｅｒヘッダフィールド内に含まれ得る）、２）標的ＵＥ（Ｒｅｆｅｒ−Ｔｏヘッダフィールドに含まれ得る）、３）ＩＵＴコントローラ移転指示（Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダフィールド内に含まれ得、例えば、ＩＮＶＩＴＥ要求に埋め込まれるか、またはＲｅｆｅｒ−Ｔｏヘッダフィールドに埋め込まれる）、４）Ｔａｒｇｅｔ−Ｄｉａｌｏｇ（標的ＵＥがすでに協調セッションの一部である場合に、既存のダイアログ識別子を含むＴａｒｇｅｔ−Ｄｉａｌｏｇヘッダフィールド内に含まれ得、これが標的ＵＥに対する新しいセッションである時には、Ｔａｒｇｅｔ−Ｄｉａｌｏｇがない）、および５）メディア種類（例えば、音声、ビデオ、ファイル等）（例えば、Ｒｅｆｅｒ−Ｔｏヘッダフィールドに含まれる）といった情報を用いて、ＳＩＰ ＲＥＦＥＲ方法等を介していそう要求を送信する。

ステップ１００５では、ＳＣＣ ＡＳは、要求（例えば、ＳＩＰ ＲＥＦＥＲ要求）を識別する。ＵＥ−２がＳＣＣ ＡＳにおいてＳＩＰ登録される場合、ＳＣＣ ＡＳは、ＵＥ−２がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、ＵＥ−２が、適切な能力、例えば、ＲＦＣ ３８４０の通りの特徴タグを登録していることを検証し、デバイス能力、ユーザ選好、および／またはネットワークの中の方針に基づいて、ＵＥ−２にどのようなベアラを使用するかを決定し、選択されたベアラがＵＥ−２によって登録されているかどうかを決定する。ＵＥ−２がコントローラとしての役割を果たすことを許可されていない場合、ＳＣＣ ＡＳは要求を拒絶し得る。ＵＥ−２が協調セッション制御移転を拒絶する場合、拒絶を示す好適な応答、随意で拒絶の理由が送信される。

ステップ１００６では、ＳＣＣ ＡＳは、ＵＥ−２がＧｍ参照点によって到達可能ではないことを決定している。これは、例えば、ＵＥが能動ＳＩＰ登録を有さないためであり、別の実施例では、ＵＥ−２は、ＳＩＰ登録され得るが、ＳＣＣ ＡＳは、Ｇｍ参照点が利用可能ではないことを、Ｉ１プロトコルを介して知らされているからである。ステップ１００２で受信されたメッセージが、音声またはビデオ用のＳＤＰ線を含む場合、次いで、ＳＣＣ ＡＳは、着呼要求メッセージを生成し、Ｉ１参照点を介してＵＥ−２に送信し、着呼要求メッセージは、ＩＵＴコントローラ機能性の指示、および、ＵＥ−２が選択されたベアラをまだ確立していない場合、ＵＳＳＤ、ＳＭＳ、ＭＢＭＳ、ＣｅｌｌＢｒｏａｄｃａｓｔ、ＧＥＲＡＮ においてＧＰＲＳ上で作動するＩＰパイプ、ＵＴＲＡＮ、ＬＴＥ、ＷＬＡＮ、ＷｉＭａｘ、またはＣＤＭＡ２０００等であるが、それらに限定されない輸送機構を使用して、ＩＵＴコントローラ機能性の指示およびベアラ設定を確立するようにＵＥ−２に誘起する指示を含む。

ステップ１００７では、ＵＥ−２は、ＣＳ呼び出し設定メッセージを相互作用エンティティに送信し、ステップ１００８では、相互作用エンティティは、呼び出し続行メッセージで応答し、ＣＳベアラ制御信号伝達経路を設定し始める。ステップ１００９および１０１０では、相互作用エンティティは、ＩＭＳエンティティを介してＳＣＣ ＡＳに向けてＳＩＰ ＩＮＶＩＴＥを送信する。ステップ１０１３では、相互作用エンティティがＩＭＳエンティティを介してＳＣＣ ＡＳからＳＩＰ ２００ ＯＫを受信する場合に、相互作用エンンティティは、受信されたＳＩＰ ２００ ＯＫ応答をＣＯＮＮＥＣＴメッセージにマップし、それをＵＥ−２に送信する。

ステップ１０１４では、ＣＯＮＮＥＣＴメッセージを受信する場合に、ＵＥ−２は、ＣＯＮＮＥＣＴ ＡＣＫメッセージを相互作用エンティティに送信し、ステップ１０１７では、ＵＥ−２、相互作用エンティティ、およびＳＣＣ ＡＳは、ＣＳベアラ制御信号伝達経路の設定を完了する。この場合に、ＵＥ−２とＳＣＣ ＡＳとの間の協調セッション制御が確立される。ＵＥ−２は、確立された協調セッションのためのコントローラＵＥになる。

ステップ１０１８では、ＵＥ−２とリモートパーティとの間のメディア種類（メディアＡ）が確立される。この場合に、遠隔レッグがそれに応じて更新される。ステップ１０１９および１０２０では、ＵＥ−２上での協調セッション制御およびメディア種類（メディアＡ）の確立の成功後、ＳＣＣ ＡＳは、移転要求メッセージへの応答メッセージ、またはＳＩＰ ＮＯＴＩＦＹメッセージ等を使用して移転要求メッセージの結果をＵＥ−１に通知する別のメッセージをＵＥ−１に送信する。ステップ１０２３では、ＵＥ−１上の以前のメディアＡが解放され得、協調セッション制御が解放される。この場合に、ＵＥ−１はコントローリＵＥになる。上記の実施例では、従来の確認メッセージの通信を伴うステップは説明されていないことに留意されたい。ＵＥ−１からＵＥ−２上で全てのメディアフローを移転する場合、ＵＥ−１上の既存のセッションは解放され得る。

上記の実施例は、的確なコントローラ対応ＵＥへのＩＵＴコントローラ機能またはメディアの移転の成功をもたらすフローを説明する。しかしながら、移転が成功しなかった場合、システムは、なぜ移転が失敗したのかという説明を提供する、種々のメッセージ応答理由コードまたは指示を要求ＵＥに送信し得る。応答理由コードまたは指示例は、ＩＵＴコントローラ能力がないこと（よって、そのＵＥによって、コントローラの状態の正当な要求を行うことができない）、セッションのためのＩＵＴコントローラＵＥがすでにあること（例えば、単一のＵＥのみがＩＵＴコントローラであり得る場合）、ＵＥが同じサブスクリプションの下にないこと、ＩＵＴコントローラの最大限度、利用不可能（登録されていない、バッテリがない等）、ＩＵＴコントローラとなる権限が与えられていない、サポートされていないメディア種類、サポートされていないメディア形式、同時セッションの最大数に達していないため、新規セッションを確立することが許可されていない、使用中である等を含む。応答理由コードまたは指示は、応答に含まれるＳＩＰ Ｗａｒｎｉｎｇヘッダ内に含まれ得る。場合によっては、拒絶応答および関連理由コードまたは指示は、ＳＣＣ ＡＳまたは他のネットワークノードにおいて受信される応答メッセージのＳＩＰｆｒａｇ包含部分内等のＳＩＰ ＮＯＴＩＦＹ要求の本文に含まれ得る。

本システムの動作中、ＩＵＴコントローラＵＥは、特定のＵＥまたはユーザと関連付けられた全てのＵＥ上の進行中のセッションを説明する、通知を受信するように登録し得る。通知は、種々の進行中のセッション、ならびにそれらの関連コントローリおよび／またはコントローラＵＥを識別し得る。一実施例では、ユーザＡが２つのセッションを開始しており、１つはユーザＣおよびユーザＤとのセッション、もう１つはユーザＢとのセッションである。ユーザＣおよびＤとのセッションを参照すると、ユーザＡは、自分のＩＵＴコントローラＵＥセットに対する３つのセッションを有する（すなわち、デバイス１、２、および３）。ユーザＢとの会話のために、ユーザＡは、自分のＩＵＴ ＵＥセット上に２つのセッションを有する（すなわち、デバイス２および３）。この実施例では、ユーザＡは、ユーザのＩＵＴ ＵＥと関連付けられた現在進行中のセッションを説明する、情報を知ることを希望し得る。その場合、ユーザＡは、要求（例えば、ＳＩＰ ＳＵＢＳＣＲＩＢＥ）を送信し得、ＲＦＣ ４２３５で説明されているようなダイアログイベントパッケージを使用して、Ｔａｒｇｅｔ−Ｄｉａｌｏｇごとに以下の情報セットをともなう応答（例えば、ＳＩＰ ＮＯＴＩＦＹ）を得る。

−Ｔａｒｇｅｔ−Ｄｉａｌｏｇ
−参加ユーザのＩＤ（ＳＩＰ ＵＲＩ、ＴＥＬ ＵＲＩ、またはニックネーム）
−ＩＵＴデバイスＩＤ／ニックネーム
−ＩＵＴコントローラデバイスＩＤ／ニックネーム
−セッションごとのメディア種類またはファイル（すなわち、特定の協調セッションのためのユーザＡのデバイス上に３つの異なるセッションがあるという通知）。

図１１に示された実施例で図示されるように、複数のＵＥが、全ての進行中のセッションのためにユーザＡに存在し得る。ユーザＡのデバイス６０は、ユーザＣのデバイス６８または７０との通信を伴う協調セッションＸに対する移転要求をユーザＡのデバイス６４に発行しており、ユーザＡのデバイス６２は、ユーザＢのデバイス６６との通信を伴う協調セッションＹに対する移転要求をユーザＡのデバイス６４に送信している。新規メディア種類の新規招待がユーザＡのデバイス６２上で受信された場合、新規招待をユーザＡのデバイス６４に移転するために、ユーザＡのデバイス６０を使用して、メディア移転要求またはリダイレクト要求を送信することが可能である。メディア移転要求またはリダイレクト要求の受諾が成功した場合、成功通知が、ユーザＡのデバイス６０および６２である、セッションのためのコントローラＵＥまたは全てのＩＵＴコントローラＵＥに移転される。ユーザ選好およびデバイス能力に応じて、ユーザは、全てのコントローラＵＥ上で通知を受信するか、または全てのコントローラＵＥへの通知を受信するよりもむしろ、複数のコントローラＵＥの中で、どのコントローラＵＥが通知を受信するかを割り当てるように構成し得る。図１１に示されるように、複数のＵＥがユーザＡに存在する場合、１つだけのＩＵＴコントローラＵＥが各協調セッションに存在する。そのようなものとして、特定の協調セッションのためのコントローラＵＥのみが、セッション状態がその特定の協調セッション上で変化した時に通知を受信する。

いくつかの実装では、任意のコントローラＵＥに伝送されるのに適格である、相当量の通知トラフィックがあり得る。フィルタリング機構は、制御ＵＥに伝送されている通知トラフィックの量を最適化するように、ネットワークおよび／または各個別ＵＥ上の通知機構内で実装され得る。

セッションを終了するために、本システムの１つの実装では、最初にセッション確立の要求を受信し、セッション確立要求を受け入れることができるどんなＵＥにも、コントローラ機能が割り当てられ得る（そうでなければ、セッションを受け入れたＵＥがセッション上にとどまり、移転要求をユーザの別のＵＥに送信する能力を持たない）。リモートパーティから最初のセッション確立要求（例えば、ＳＩＰ ＩＮＶＩＴＥ、ＳＩＰ ｒｅ−ＩＮＶＩＴＥ、またはＳＩＰ ＵＰＤＡＴＥ）を受信すると、ネットワークは、コントローラである、および／またはコントローラ機能をサポートするＵＥに要求が送られることを確実にする必要があり得る。セッションが確立されると、終端ユーザは、協調セッション制御を同じユーザの別のＵＥに移転することを望み得る。標的ＵＥがＩＵＴコントローラ能力を持たず、ＩＵＴコントローラ ＵＥではない場合には、標的ＵＥは、他のＵＥへの移転要求を行うことができない。しかしながら、場合によっては、移転は、依然として行われ得る。例えば、ＵＥは、ユーザがネットワーク上でリダイレクト設定を提供することを可能にし得、すなわち、招待要求が終端側に到達する場合に、ユーザによって割り当てられたコントローラＵＥ等の特定のＵＥに要求をリダイレクトすることを可能にし得る。加えて、ＵＥは、ユーザがユーザ選好を設定することを可能にして、おそらくメディア種類およびデバイス能力の組み合わせとして、セッション確立にどのベアラを使用すべきかを示し得る。例えば、２つのＵＥを有するユーザは、ＵＥ−１上の発話種類セッションにパケット交換ベアラを使用するように、およびＵＥ−２上のビデオ種類セッションに回路交換ベアラを使用するように、ユーザ選好を設定し得る。

代替として、リダイレクト設定がない場合、終端ネットワークが招待要求を受信した場合、ネットワークは、ＵＥ上で招待を受諾するか、または別のＵＥ（すなわち、コントローラＵＥ）にリダイレクトするかをユーザに尋ねる要求を送信する。ユーザが別のＵＥ（コントローラＵＥである）にリダイレクトすることを決定した場合には、ネットワークは、移転されるＵＥ識別を含む応答を終端ネットワークに送信し、終端ネットワークは、招待要求をユーザによって割り当てられたＵＥに送信する。

代替として、リダイレクト設定がない場合、終端ネットワークが招待要求を受信した場合、ＵＥは、招待を受諾するか、または別のＵＥにリダイレクトするかをユーザに尋ねる。ユーザが別のＵＥ（すなわち、コントローラＵＥ）にリダイレクトすることを決定した場合には、ネットワークは、リダイレクト要求を終端ネットワークに送信する。その場合、終端ネットワークは、招待要求をユーザによって割り当てられたＵＥに送信する。終端ネットワークが（例えば、ＳＣＣ ＡＳを介して）招待メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ、ＳＩＰ ｒｅ−ＩＮＶＩＴＥ、またはＳＩＰ ＵＰＤＡＴＥ）を受信すると、終端ネットワークは、デバイス能力、ユーザ選好および／または方針、および終端ＵＥにどのベアラを使用するかに基づいて、どの終端ＵＥがＩＵＴコントローラになるかを決定する。ネットワークは、終端ＵＥが識別されたベアラに登録しているかどうかをチェックする。そうでなければ、ネットワークは、ベアラ登録を開始するように、指示を終端ＵＥに送信し得る。ベアラ登録の成功後、ネットワークは、セッション制御およびあるメディア種類が標的終端ＵＥに提示されることを示す、招待要求メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）を（例えば、ＳＣＣ ＡＳを介して）送信する。ＡｃｋまたはＯＫ応答メッセージを受信すると、ＳＣＣ ＡＳは、メディアストリームが異なるＵＥにリダイレクトされているという指示をリモートパーティに送信し得る。

図１２ａおよび１２ｂは、リモートパーティがセッション招待要求を送信した時に協調セッション確立を終了するためのフロー例を図示する。１つの実装では、ＭＳＣサーバ進化型ＩＣＳは、相互作用エンティティの例示的なエンティティであり得る。代替として、相互作用エンティティは、レガシーＭＳＣサーバおよびＭＧＣＦから成り得る。フロー例は、ＵＥ−１が、ＩＵＴコントローラであるため、およびビデオ種類を用いたセッション確立にＰＳベアラを使用するために、デバイス能力／ユーザ選好を設定していることを仮定する。ＵＥ−２は、発話メディア種類を用いたセッション確立にＣＳベアラを使用するために、デバイス能力／ユーザ選好を設定している。図１２ａは、以下のような高レベルフローを示す。ステップ１１０１では、終端ネットワーク（例えば、ＳＣＣ ＡＳ）が、招待メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥまたはＳＩＰ ｒｅ−ＩＮＶＩＴＥ）を受信する。ステップ１１０２では、ＳＣＣ ＡＳは、デバイス能力、ユーザ選好および／または方針に基づいて、どの終端ＵＥがＩＵＴコントローラになるか、ならびに、デバイス能力、ユーザ選好および／または方針に基づいて、終端ＵＥにどのベアラを使用するかを決定する。実施例では、ＳＣＣ ＡＳは、ＵＥ−１がＩＵＴコントローラとしての役割を果たし、ビデオメディア種類とともにＰＳベアラを使用する一方で、ＵＥ−２が発話メディア種類とともにＣＳベアラを使用することを決定する。ステップ１１０３および１１０４では、ＳＣＣ ＡＳは、ＵＥ−２に向けた協調セッションを確立するために、ＩＭＳを介して招待要求メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）を相互作用エンティティに送信する。ステップ１１０５では、相互作用エンティティは、ＣＳ呼び出し設定メッセージをＵＥ−２に送信する。ステップ１１０６では、ＵＥ−２、相互作用エンティティ、およびＳＣＣ ＡＳは、ＣＳベアラ制御信号伝達経路の設定を完了し、ＳＣＣ ＡＳおよびリモートパーティは、遠隔レッグ確立を完了する。ＵＥ−２とＳＣＣ ＡＳとの間の発話メディア種類を用いた協調セッション制御が確立され、ＳＣＣ ＡＳとリモートパーティの間の遠隔レッグが確立される。

ステップ１１０７および１１０８では、ＳＣＣ ＡＳは、ＩＭＳを介して招待要求メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）をＵＥ−１に送信する。ステップ１１０９では、ＵＥ−１とＳＣＣ ＡＳとリモートパーティの間のビデオメディア種類を用いた協調セッション制御が確立され、ＳＣＣ ＡＳとリモートパーティの間の遠隔レッグが更新される。ＵＥ−１は、ＩＵＴ移転要求を適用することを可能にする、協調セッション制御を得る。

図１２ａに図示されたステップでは、１つの実装において、ＵＥ−１およびＵＥ−２が同じ加入者（すなわち、同じサブスクリプションセット）に属し、ＳＣＣ ＡＳが、ＵＥ−２上のＣＳネットワーク上で、および協調セッション制御を保持するＵＥ−１上のＰＳネットワーク上で、協調セッションを確立すると決定すると仮定される。場合によっては、相互作用エンティティがＭＳＣサーバおよびＭＧＣＦに対応する場合に、ＣＳベアラ設定手順は、ＴＳ ２３．２９２の図７．４．２．２．２−２のステップ１１−１７に従う。

図１２ｂは、以下のように図１２ａよりも詳細なフローを図示する。ステップ１２０１では、終端ネットワーク（例えば、ＳＣＣ ＡＳ）は、招待メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥまたはＳＩＰ ｒｅ−ＩＮＶＩＴＥ）を受信する。ステップ１２０２では、ＳＣＣ ＡＳは、デバイス能力、ユーザ選好および／または方針に基づいて、どの終端ＵＥがＩＵＴコントローラになるか、ならびに、デバイス能力、ユーザ選好および／または方針に基づいて、終端ＵＥにどのベアラを使用するかを決定する。実施例では、ＳＣＣ ＡＳは、ＵＥ−１がＩＵＴコントローラとしての役割を果たし、ビデオメディア種類とともにＰＳベアラを使用する一方で、ＵＥ−２が発話メディア種類とともにＣＳベアラを使用することを決定する。ステップ１２０３および１２０４では、ＳＣＣ ＡＳは、ＵＥ−２に向けた協調セッションを確立するために、ＩＭＳを介して招待要求メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）を相互作用エンティティに送信する。ステップ１２０５および１２０６では、相互作用エンティティは、ＣＳ呼び出し設定メッセージをＵＥ−２に送信し、ＣＳ呼び出し接続メッセージを受信する。ステップ１２０７から１２０９では、ＳＩＰ ２００ ＯＫ応答メッセージが、ＩＭＳエンティティおよびＳＣＣ ＡＳを介してリモートパーティに送信される。リモートパーティは、ステップ１２１０から１２１２で、相互作用エンティティに向けてＳＩＰ ＡＣＫを送信し、相互作用エンティティは、ＣＯＮＮＥＣＴ応答メッセージをＵＥ−２に送信する。ステップ１２１４では、ＵＥ−２とリモートパーティの間の発話メディア種類を用いたセッション制御が確立される。

ステップ１２１５から１２１７では、ＳＣＣ ＡＳは、ビデオメディア種類を用いたセッションを確立するように、招待要求メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）を終端ＵＥ−１に送信する。この時点で、ＳＣＣ ＡＳを用いた協調セッション制御が確立され、終端ＵＥ−１がＩＵＴコントローラになる。ステップ１２１８から１２２０で示されるように、相互作用エンティティおよびＩＭＳエンティティを介してＵＥ−２からＳＩＰ ２００ ＯＫ応答を受信すると、ＳＣＣ ＡＳは、ステップ１２２１で遠隔レッグを更新するように、ＳＩＰ ＵＰＤＡＴＥをリモートパーティに送信する。ステップ１２２２から１２２５におけるＳＩＰ応答の成功後、ステップ１２２６では、ＵＥ−１とＳＣＣ ＡＳとの間のビデオメディア種類を用いたセッション制御が確立される。ＳＣＣ ＡＳとリモートパーティとの間の遠隔レッグが更新される。上記の実施例では、従来の確認メッセージの通信を伴うステップは完全には説明されていないことに留意されたい。

図１３は、ＰＳ ＵＥ−１からＰＳ ＵＥ−２にＩＵＴコントローラ機能性を移転するためのフロー例を図示する。ＵＥ−１およびＵＥ−２は、同じベアラまたは異なるベアラを使用し得る。たとえＵＥ−１およびＵＥ−２上でパケット交換ベアラを使用しても、ＵＥ−１上で３ＧＰＰ ＩＰ−ＣＡＮを、ＵＥ−２上で非３ＧＰＰ ＩＰ−ＣＡＮを使用することが可能であり得る。ステップ１３０１および１３０２では、ＵＥ１は、協調セッション制御およびメディアＡをＵＥ２に移転することを決定する。したがって、ＵＥ−１は、ＩＭＳエンティティを介して要求をＳＣＣ ＡＳに送信し、現在のサービス制御およびメディア種類（メディアＡ）がＵＥ２に送信されることを示す。ステップ１３０５では、ＳＣＣ ＡＳは、要求、例えば、ＳＩＰ ＲＥＦＥＲ要求を識別し、ＵＥ−２がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、デバイス能力、ユーザ選好、および／またはネットワークの中の方針に基づいて、ＵＥ−２に使用されるＰＳベアラを決定する。

ステップ１３０６および１３０７では、ＳＣＣ ＡＳは、協調セッション制御およびメディア種類（メディアＡ）を示す、ＳＩＰ ＩＮＶＩＴＥ要求（またはＳＩＰ ｒｅ−ＩＮＶＩＴＥ）等のセッション確立要求メッセージを生成し、送信する。セッション確立要求は、上で説明されるＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダの中のフロー識別子メディア特徴タグを使用して、所望のアクセスレッグ（ベアラ）上で送ることができる。ステップ１３１２では、ＵＥ２とＳＣＣ ＡＳとの間の協調セッション制御が確立される。ＵＥ ２は、確立された協調セッションのためのコントローラＵＥになる。ステップ１３１３では、ＵＥ２とリモートパーティとの間のメディア種類（メディアＡ）通信が確立される。遠隔レッグは、それに応じて更新される。ステップ１３１４および１３１５では、ＵＥ−２上での協調セッション制御およびメディア種類（メディアＡ）の確立の成功後、ＳＣＣ ＡＳは、移転要求メッセージへの応答メッセージまたはＳＩＰ ＮＯＴＩＦＹメッセージ等の移転要求メッセージの結果を通知するメッセージをＵＥ−１に送信する。ステップ１３１８では、ＵＥ−１上の以前のメディア種類（メディアＡ）および協調セッション制御が解放され得る。ＵＥ−１は、コントローリＵＥになる。上記の実施例では、従来の確認メッセージの通信を伴うステップは説明されていないことに留意されたい。

本システムおよび方法は、ＩＵＴコントローラ移転アプリケーションを提供するために使用され得る。本システムによって実装される方法例は、ＩＵＴコントローラ機能を果たせること、およびＩＵＴコントローラ機能を果たせないことの少なくとも１つを示す。方法は、セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）メッセージにおいて、ＩＵＴ：コントローラ機能をサポートできるという指示を提供するステップと、セッション初期化プロトコル（ＳＩＰ）メッセージにおいて、ＩＵＴ：コントローラ機能をサポートできないという指示を提供するステップとを含む。ＩＵＴコントローラ機能を果たせること、およびＩＵＴ：コントローラ機能をサポートできないことの少なくとも１つの指示は、メディア特徴タグを使用して示され得る。メディア特徴タグは、ＩＵＴコントローラとしての役割を果たすことができ、協調セッションのためのＩＵＴコントローラとしての役割を現在果たしていることを示す「Ａｃｔｉｖｅ（能動）」、ＩＵＴコントローラとしての役割を果たすことができるが、協調セッションのためのＩＵＴコントローラとしての役割を現在果たしていないことを示す「Ｉｎａｃｔｉｖｅ（非能動）」、および協調セッションのためのＩＵＴコントローラとしての役割を果たすことができないことを示す「Ｐａｓｓｉｖｅ（受動）」といった値のうちの少なくとも１つを示し得る。

実装に応じて、メディア特徴タグは、Ｃｏｎｔａｃｔヘッダ内に含まれ得る。セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）メッセージは、ＳＩＰ ＲＥＧＩＳＴＥＲ要求、ＳＩＰ ＩＮＶＩＴＥ要求、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥ要求、ＳＩＰ ＵＰＤＡＴＥ要求、ＳＩＰ ＰＲＡＣＫ要求、ＳＩＰ ＲＥＦＥＲ要求、ＳＩＰ ＰＵＢＬＩＳＨ要求、ＳＩＰ ＭＥＳＳＡＧＥ要求、ＳＩＰ ＳＵＢＳＣＲＩＢＥ要求、ＳＩＰ ＮＯＴＩＦＹ要求、ＳＩＰ ＯＰＴＩＯＮＳ要求、およびＳＩＰ ＩＮＦＯ要求のうちの１つを含み得る。

１つのデバイスから別のデバイスにＩＵＴコントローラ機能を移転する方法例は、セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）メッセージにおいて、ＩＵＴ：コントローラ機能の移転の指示を提供するステップを含み得る。ＩＵＴ：コントローラ機能の移転の指示は、メディア特徴タグを使用して示され得る。メディア特徴タグは、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれ得る。セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）メッセージは、ＳＩＰ ＩＮＶＩＴＥ要求、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥ要求、ＳＩＰ ＵＰＤＡＴＥ要求、ＳＩＰ ＰＲＡＣＫ要求、ＳＩＰ ＲＥＦＥＲ要求、ＳＩＰ ＰＵＢＬＩＳＨ要求、ＳＩＰ ＭＥＳＳＡＧＥ要求、ＳＩＰ ＳＵＢＳＣＲＩＢＥ要求、ＳＩＰ ＮＯＴＩＦＹ要求、ＳＩＰ ＯＰＴＩＯＮＳ要求、およびＳＩＰ ＩＮＦＯ要求のうちの１つを含み得る。メディア特徴タグは、それ自体がＲｅｆｅｒ−Ｔｏヘッダ内に含まれる、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれ得る。

方法は、それに応じて、Ｓｕｃｃｅｓｓｆｕｌ ＩＵＴ Ｔｒａｎｓｆｅｒ（ＩＵＴ移転の成功）またはＵｎｓｕｃｃｅｓｓｆｕｌ ＩＵＴ Ｔｒａｎｓｆｅｒ（ＩＵＴ移転の不成功）のうちの１つの指示を受信するステップを含み得る。指示は、ＳＩＰ応答、ＳＩＰ ＵＰＤＡＴＥ要求、ＳＩＰ ＰＲＡＣＫ要求、ＳＩＰ ＮＯＴＩＦＹ要求、ＳＩＰ ＰＵＢＬＩＳＨ要求、ＳＩＰ ＭＥＳＳＡＧＥ要求、ＳＩＰ ＯＰＴＩＯＮＳ要求、またはＳＩＰ ＩＮＦＯ要求を含み得る。代替として、指示は、Ｃｏｎｔａｃｔヘッダの中にある、ＳＩＰ要求またはＳＩＰ応答の本文内にある、ＳＩＰ要求またはＳＩＰ応答の本文中のＳＩＰｆｒａｇ内にある、またはＸＭＬ形式で符号化される、メディア特徴タグのうちの１つであり得る。

代替として、方法は、１つの付着点から別の付着点にＩＵＴコントローラ機能を移転するステップを提供し得る。付着点技術は、ＩＥＥＥ−８０２．１１、ＩＥＥＥ−８０２．１１ａ、ＩＥＥＥ−８０２．１１ｂ、ＩＥＥＥ−８０２．１１ｇ、ＩＥＥＥ−８０２．１１ｎ、３ＧＰＰ−ＧＥＲＡＮ、３ＧＰＰ−ＵＴＲＡＮ−ＦＤＤ、３ＧＰＰ−ＵＴＲＡＮ−ＴＤＤ、３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＦＤＤ、３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＴＤＤ、ＡＤＳＬ、ＡＤＳＬ２、ＡＤＳＬ２＋、ＲＡＤＳＬ、ＳＤＳＬ、ＨＤＳＬ、ＨＤＳＬ２、Ｇ．ＳＨＤＳＬ、ＶＤＳＬ、ＩＤＳＬ、３ＧＰＰ２−１Ｘ、３ＧＰＰ２−１Ｘ−ＨＲＰＤ、３ＧＰＰ２−ＵＭＢ、ＤＯＣＳＩＳ、ＩＥＥＥ−８０２．３、ＩＥＥＥ−８０２．３ａ、ＩＥＥＥ−８０２．３ｅ、ＩＥＥＥ−８０２．３ｉ、ＩＥＥＥ−８０２．３ｊ、ＩＥＥＥ−８０２．３ｕ、ＩＥＥＥ−８０２．３ａｂ、ＩＥＥＥ−８０２．３ａｅ、ＩＥＥＥ−８０２．３ａｋ、ＩＥＥＥ−８０２．３ａｑ、ＩＥＥＥ−８０２．３ａｎ、ＩＥＥＥ−８０２．３ｙ、ＩＥＥＥ−８０２．３ｚ、ＩＥＥＥ−８０２．３ｙ、３ＧＰＰ−ＧＥＲＡＮ、３ＧＰＰ−ＵＴＲＡＮ、３ＧＰＰ−Ｅ−ＵＴＲＡＮ、３ＧＰＰ−ＷＬＡＮ、３ＧＰＰ−ＧＡＮ、または３ＧＰＰ−ＨＳＰＡを含み得る。しかしながら、場合によっては、他のアクセス技術、クラス、または種類が採用され得る。

１つのデバイスから別のデバイスにＩＵＴコントローラ機能を移転する別の方法例は、セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）メッセージにおいて、ＩＵＴ：コントローラ機能の移転の指示を受信するステップを含む。ＩＵＴ：コントローラ機能の移転の指示は、メディア特徴タグを使用して示され得る。メディア特徴タグは、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれ得る。セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）メッセージは、ＳＩＰ ＩＮＶＩＴＥ要求、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥ要求、ＳＩＰ ＵＰＤＡＴＥ要求、ＳＩＰ ＰＲＡＣＫ要求、ＳＩＰ ＲＥＦＥＲ要求、ＳＩＰ ＰＵＢＬＩＳＨ要求、ＳＩＰ ＭＥＳＳＡＧＥ要求、ＳＩＰ ＳＵＢＳＣＲＩＢＥ要求、ＳＩＰ ＮＯＴＩＦＹ要求、ＳＩＰ ＯＰＴＩＯＮＳ要求、およびＳＩＰ ＩＮＦＯ要求のうちの１つ以上を含み得る。メディア特徴タグは、それ自体がＲｅｆｅｒ−Ｔｏヘッダ内に含まれる、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれ得る。方法は、それに応じて、Ｓｕｃｃｅｓｓｆｕｌ ＩＵＴ Ｔｒａｎｓｆｅｒ（ＩＵＴ移転の成功）またはＵｎｓｕｃｃｅｓｓｆｕｌ ＩＵＴ Ｔｒａｎｓｆｅｒ（ＩＵＴ移転の不成功）のうちの１つの指示を送信するステップを含み得る。指示は、ＳＩＰ応答、ＳＩＰ ＵＰＤＡＴＥ要求、ＳＩＰ ＰＲＡＣＫ要求、ＳＩＰ ＮＯＴＩＦＹ要求、ＳＩＰ ＰＵＢＬＩＳＨ要求、ＳＩＰ ＭＥＳＳＡＧＥ要求、ＳＩＰ ＯＰＴＩＯＮＳ要求、またはＳＩＰ ＩＮＦＯ要求のうちの１つに含まれ得る。指示は、Ｃｏｎｔａｃｔヘッダの中にある、ＳＩＰ要求またはＳＩＰ応答の本文内にある、ＳＩＰ要求またはＳＩＰ応答の本文中のＳＩＰｆｒａｇ内にある、またはＸＭＬ形式で符号化される、メディア特徴タグのうちの１つであり得る。方法は、協調セッションのための能動ＩＵＴコントローラ機能を果たすステップを含み得る。

本システムはさらに、特定のアクセスアプリケーション上でＳＩＰ ＲＥＱＵＥＳＴを方向付けるように構成され得る。アクセスネットワーク上で登録フローを識別する方法例は、セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）ＲＥＧＩＳＴＥＲ要求のＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダにおいて、ＲＥＧＩＳＴＥＲ要求が輸送されるアクセスネットワークのアクセス種類を識別する、識別子を提供するステップと、セッション初期化プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダにおいて、同じデバイスによる他の登録全体にわたり登録フローを一意的に識別する、メディア特徴タグを提供するステップとを含む。メディア特徴タグは、ＳＩＰ ＲＥＧＩＳＴＥＲ要求に含まれる「ｒｅｇ−ｉｄ」ｃｏｎｔａｃｔヘッダパラメータから導出される値を含み得る。メディア特徴タグは、テキスト文字列である値を含み得る。メディア特徴タグは、ユーザによって入力されるテキスト文字列である値を含む。アクセスネットワーク上で登録フローを識別する方法例は、セッション初期化プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／ＳＩＰ）ＲＥＧＩＳＴＥＲ要求のＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダから、ＲＥＧＩＳＴＥＲ要求が輸送されるアクセスネットワークのアクセス種類を識別する、識別子を取得するステップと、セッション初期化プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダから、同じデバイスによる他の登録全体にわたり登録フローを一意的に識別する、メディア特徴タグを取得するステップと、アクセス種類またはアクセスクラスを、メディア特徴タグからの値と関連付けるステップとを含む。セッション初期化プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲ要求のコンテンツは、受信された第３者ＲＥＧＩＳＴＥＲ要求の本文、受信された第３者ＲＥＧＩＳＴＥＲ要求の中のＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ、およびＳＩＰ ＮＯＴＩＦＹ要求の本文内の登録イベントパッケージのうちの少なくとも１つを使用して、取得され得る。方法は、ＳＩＰ要求を受信するか、またはＳＩＰ要求を生成するステップと、ＳＩＰ要求が、アクセス種類またはアクセスクラス値によって識別される特定のアクセスレッグ上で送られるべきことを決定するステップと、アクセス種類またはアクセスクラス値と関連付けられたメディア特徴タグ値を回収するステップと、Ａｃｃｅｐｔ−ＣｏｎｔａｃｔヘッダのＳＩＰ要求の中に、回収されたメディア特徴タグ値を含むステップとを含み得る。ＳＩＰ要求は、ＳＩＰ ＩＮＶＩＴＥ要求、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥ要求、ＳＩＰ ＵＰＤＡＴＥ要求、ＳＩＰ ＰＲＡＣＫ要求、ＳＩＰ ＲＥＦＥＲ要求、ＳＩＰ ＰＵＢＬＩＳＨ要求、ＳＩＰ ＭＥＳＳＡＧＥ要求、ＳＩＰ ＳＵＢＳＣＲＩＢＥ要求、ＳＩＰ ＯＰＴＩＯＮＳ要求、およびＳＩＰ ＩＮＦＯ要求のうちの１つであり得る。

要求が送信されるアクセスネットワーク上で登録フローを識別する方法例は、ＳＩＰ要求のＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダにおいて、デバイスの登録フローを一意的に識別する値を含む、メディア特徴タグを提供するステップを含む。メディア特徴タグは、テキスト文字列である値を含み得る。メディア特徴タグは、ユーザによって入力されるテキスト文字列である値を含み得る。ＳＩＰ要求は、ＳＩＰ ＩＮＶＩＴＥ要求、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥ要求、ＳＩＰ ＵＰＤＡＴＥ要求、ＳＩＰ ＰＲＡＣＫ要求、ＳＩＰ ＲＥＦＥＲ要求、ＳＩＰ ＰＵＢＬＩＳＨ要求、ＳＩＰ ＭＥＳＳＡＧＥ要求、ＳＩＰ ＳＵＢＳＣＲＩＢＥ要求、ＳＩＰ ＯＰＴＩＯＮＳ要求、およびＳＩＰ ＩＮＦＯ要求のうちの１つであり得る。メディア特徴タグは、それ自体がＲｅｆｅｒ−Ｔｏヘッダ内に含まれる、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに含まれ得る。

図１４は、Ｇｍ参照点を使用した、協調セッション内の別のＵＥへのメディア／コントローラ機能性移転のための代替メッセージフローの説明図である。図１４に図示されたメッセージフローは、ＵＥ−１からＵＥ−２にメディアおよびＩＵＴコントローラ機能性を移転する方法例を示し、着信セッションは、Ｇｍ参照点上で送達され、メディアは、ＣＳネットワークを介して確立される。実施例では、ＵＥ−１およびＵＥ−２が同じ加入者（すなわち、同じサブスクリプションセット）に属し、相互作用エンティティがＩＣＳ用のＭＳＣ進化型に対応し、ＴＳ ２３．２９２に示されている、Ｇｍ参照点を使用するＣＳメディアを用いた終了手順に従うことが仮定される。この実施例では、相互作用エンティティがＭＳＣサーバおよびＭＧＣＦに対応する場合に、ＣＳベアラ設定手順は、ＴＳ ２３．２９２の図７．４．２．２．２−２のステップ１１−１７に従い得る。

図１４を参照すると、ステップ１４０１では、ＵＥ１は、メディアＡおよび協調セッション制御をＵＥ２に移転することを決定し、現在の協調セッション制御およびメディアＡがＵＥ−２に移転されることを示す、移転要求をＩＭＳエンティティに送信する。ステップ１４０２では、ＩＭＳエンティティは、移転要求をＳＣＣ ＡＳに転送し、ステップ１４０３では、ＳＣＣ ＡＳは、移転要求を識別し、ＵＥ−２がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、ＵＥ−２の能力、ユーザ選好、および／またはネットワークの中の方針に基づいて、Ｔ−ＡＤＳを行い、メディアＡの設定のためのＣＳドメインを選択する。ＵＥ−２がコントローラとしての役割を果たすことを許可されていないか、または移転要求をうまく行うことができない場合、ＳＣＣ ＡＳは、理由とともに要求を拒絶し、以下のステップ後に停止する。

依然として図１４を参照すると、ステップ１４０４では、ＳＣＣ ＡＳは、メディアＡおよび協調セッション制御と、ＴＳ ２３．２９２で示されるようなＣＳベアラ確立手順を開始するＵＥ−２とを示す、ＩＮＶＩＴＥ要求を生成し、ＩＭＳエンティティに送信する。ステップ１４０５では、ＩＭＳエンティティは、受信されたＩＮＶＩＴＥ要求をＵＥ−２に転送し、ステップ１４０６では、ＵＥ−２は、ＣＳ呼び出し設定メッセージを相互作用エンティティに送信する。ステップ１４０７では、相互作用エンティティは、呼び出し続行メッセージで応答し、ＣＳベアラ制御信号伝達経路を設定し始め、ステップ１４０８および１４０９では、相互作用エンティティは、ＩＭＳエンティティを介してＳＣＣ ＡＳに向けてＩＮＶＩＴＥを送信する。ステップ１４１０では、ＵＥ−２、相互作用エンティティ、およびＳＣＣ ＡＳは、ＣＳベアラ制御信号伝達経路の設定を完了する。ＵＥ−２とＳＣＣ ＡＳとの間の協調セッション制御が確立される。ＵＥ−２は、確立された協調セッションのためのコントローラＵＥになる。ステップ１４１１では、ＵＥ−２とリモートパーティとの間のメディアＡが確立される。遠隔レッグが、それに応じて更新される。ステップ１４１２では、ＵＥ−２上での協調セッション制御およびメディアＡの確立の成功後、ＳＣＣ ＡＳは、ＩＵＴ移転結果メッセージをＩＭＳエンティティに送信し、ステップ１４１３では、ＩＭＳエンティティは、ＩＵＴ移転結果メッセージをＵＥ−１に転送する。最終的に、ステップ１４１４では、以前のメディアＡおよび協調セッション制御が解放される。ＵＥ１はコントローリＵＥになる。

図１５は、Ｉ１参照点を使用した、協調セッション内の別のＵＥへのメディア／コントローラ機能性移転のための代替メッセージフローの説明図である。図１５に図示されたメッセージフローは、ＵＥ−１からＵＥ−２にＩＵＴコントローラ機能性を移転する方法例を示し、着信セッションは、Ｉ１参照点上で送達され、メディアは、ＣＳネットワークを介して確立される。実施例では、ＵＥ−１およびＵＥ−２が同じ加入者（すなわち、同じサブスクリプションセット）に属し、相互作用エンティティがＩＣＳ用のＭＳＣ進化型に対応し、ＴＳ ２３．２９２に示されている、Ｉ１参照点を使用するＣＳメディアを用いた終了手順に従うことが仮定される。この実施例では、相互作用エンティティがＭＳＣサーバおよびＭＧＣＦに対応する場合に、ＣＳベアラ設定手順は、ＴＳ ２３．２９２の図７．４．２．２．２−２のステップ１１−１７に従い得る。

図１５を参照すると、ステップ１５０１では、ＵＥ１は、メディアＡおよび協調セッション制御をＵＥ２に移転することを決定し、現在の協調セッション制御およびメディアＡがＵＥ−２に移転されることを示す、移転要求をＩＭＳエンティティに送信する。ステップ１５０２では、ＩＭＳエンティティは、移転要求をＳＣＣ ＡＳに転送し、ステップ１５０３では、ＳＣＣ ＡＳは、移転要求を識別し、ＵＥ−２がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、ＵＥ−２の能力、ユーザ選好、および／またはネットワークの中の方針に基づいて、Ｔ−ＡＤＳを行い、メディアＡの設定のためのＣＳドメインを選択する。ＵＥ−２がコントローラとしての役割を果たすことを許可されていないか、または移転要求をうまく行うことができない場合、ＳＣＣ ＡＳは、理由とともに要求を拒絶し、以下のステップ後に停止する。ステップ１５０４では、ＳＣＣ ＡＳは、ＣＳベアラ確立手順を開始するＵＥ−２と、ＴＳ ２３．２９２で示されるようにＵＥ−２に移転される協調セッション制御およびメディアＡおよびとを示す、着呼要求を生成し、Ｉ１参照点を介してＵＥ−２に送信する。

依然として図１５を参照すると、ステップ１５０５では、ＵＥ−２は、ＣＳ呼び出し設定メッセージを相互作用エンティティに送信し、ステップ１５０６では、相互作用エンティティは、呼び出し続行メッセージで応答し、ＣＳベアラ制御信号伝達経路を設定し始める。ステップ１５０７および１５０８では、相互作用エンティティは、ＩＭＳエンティティを介してＳＣＣ ＡＳに向けてＩＮＶＩＴＥを送信し、ステップ１５０９では、ＵＥ−２、相互作用エンティティ、およびＳＣＣ ＡＳは、ＣＳベアラ制御信号伝達経路の設定を完了する。ＵＥ−２とＳＣＣ ＡＳとの間の協調セッション制御が確立される。ＵＥ−２は、確立された協調セッションのためのコントローラＵＥになる。ステップ１５１０では、ＵＥ−２とリモートパーティとの間のメディアＡが確立される。遠隔レッグが、それに応じて更新される。ステップ１５１１では、ＵＥ−２上での協調セッション制御およびメディアＡの確立の成功後、ＳＣＣ ＡＳは、ＩＵＴ移転結果メッセージをＩＭＳエンティティに送信する。ステップ１５１２では、ＩＭＳエンティティは、ＩＵＴ移転結果メッセージをＵＥ−１に転送し、ステップ１５１３では、以前のメディアＡおよび協調セッション制御が解放される。ＵＥ１はコントローリＵＥになる。

図１６は、コントローラが開始した進行中セッション情報移転のための代替メッセージフローの説明図である。図１６に示された実施例では、ＵＥ−１、ＵＥ−２、およびＵＥ−３は、同じユーザサブスクリプションの下にあり得る。ＵＥ−２とリモートパーティとの間のメディアＡを用いた１つのセッション、およびＵＥ−３とリモートパーティとの間のメディアＢを用いた別のセッションがある。図１６は、ユーザのＩＵＴ ＵＥに対する全ての進行中セッション状態情報を要求する、ＵＥ−１の情報フローを提示する。

図１６を参照すると、ステップ１６０１では、ＵＥ−１は、ユーザのＩＵＴ ＵＥに対する進行中セッション状態情報についての要求をＳＣＣ ＡＳに送信する。要求は、どのような情報が応答の中で取得されるかを含み得る。情報は、ユーザのＩＵＴ ＵＥに対する進行中のセッション、進行中のセッションあたりのメディア種類、および／または進行中のセッションあたりのソースＵＥおよび標的ＵＥを含み得る。ステップ１６０２では、ＳＣＣ ＡＳは、ユーザのＩＵＴ ＵＥに対する全ての進行中のセッションをチェックし、要求された情報をフィルタにかけ、すなわち、ＵＥ−２とリモートパーティとの間のメディアＡを用いた１つのセッションＡ、およびＵＥ−３とリモートパーティとの間のメディアＢを用いた別のセッションＢがある。ステップ１６０３では、ＳＣＣ ＡＳは、ＵＥ−２およびＵＥ−３上の進行中セッション状態情報についての応答をＵＥ−１に送信する。

ＳＣＣ ＡＳが終端ＩＣＳ ＵＥに役立ち、初期フィルタ基準による初期ＳＩＰ ＩＮＶＩＴＥ要求を受信し、Ｔ−ＡＤＳがＰＳドメイン中でメディアを送達することを選択する結果となる、本システムの実装では、ＳＣＣ ＡＳは、Ｂ２ＢＵＡとしての役割を果たすことができる。複数の連絡先がＰＳドメインで登録され、Ｔ−ＡＤＳが異なるＩＰ−ＣＡＮを使用して異なるメディア種類を確立することを選択する場合、ＳＣＣ ＡＳは、それぞれの選択されたＰＳドメインＩＰ−ＣＡＮについて、３ＧＰＰ ＴＳ２４．２２９に従ってＳＩＰ ＩＮＶＩＴＥ要求を作成することができる。ＳＩＰ ＩＮＶＩＴＥ要求は、ｉ）選択されたＰＳドメインＩＰ−ＣＡＮのアクセス種類またはアクセスクラスと登録時に関連付けられた値を含む、メディア特徴タグｇ．３ｇｐｐ．ｉｃｓｆｌｏｗと、パラメータ「ｒｅｑｕｉｒｅ」および「ｅｘｐｌｉｃｉｔ」とともに値「ｐｒｉｎｃｉｐａｌ」を含む、メディア特徴タグｇ．３ｇｐｐ．ｉｃｓとを含むＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダ、およびｉｉ）このセッションのための既存のレッグがすでに存在するか、または異なるＩＰ−ＣＡＮを使用してＳＣＣ ＡＳとＩＣＳ ＵＥとの間で確立されている過程にある場合、ＳＣＣ ＡＳとＩＣＳ ＵＥとの間のその既存のダイアログに対するダイアログパラメータを含む、Ｔａｒｇｅｔ−Ｄｉａｌｏｇヘッダ（ＳＣＣ ＡＳは、ＩＣＳ ＵＥが同じセッションの一部として異なる要求を相関させることができるように、ＳＩＰ ＩＮＶＩＴＥ要求にＴａｒｇｅｔ−Ｄｉａｌｏｇヘッダを含み得る）、およびｉｉｉ）このＩＰ−ＣＡＮを使用して確立されるように選択される、メディア種類に対するＳＤＰを含み得る。

複数の連絡先がＰＳドメインで登録され、Ｔ−ＡＤＳが同じＩＰ−ＣＡＮ上で全てのメディア種類を確立することを選択する場合、ＳＣＣ ＡＳは、３ＧＰＰ ＴＳ２４．２２９に従ってＳＩＰ ＩＮＶＩＴＥ要求を作成し得、要求の中に、ｉ）選択されたＰＳドメインＩＰ−ＣＡＮのアクセス種類またはアクセスクラスと登録時に関連付けられた値を含む、メディア特徴タグｇ．３ｇｐｐ．ｉｃｓｆｌｏｗと、パラメータ「ｒｅｑｕｉｒｅ」および「ｅｘｐｌｉｃｉｔ」とともに値「ｐｒｉｎｃｉｐａｌ」を含む、メディア特徴タグｇ．３ｇｐｐ．ｉｃｓとを含むＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダ、ｉｉ）このセッションのための既存のレッグがすでに存在するか、または異なるＩＰ−ＣＡＮを使用してＳＣＣ ＡＳとＩＣＳ ＵＥとの間で確立されている過程にある場合、ＳＣＣ ＡＳとＩＣＳ ＵＥとの間のその既存のダイアログに対するダイアログパラメータを含む、Ｔａｒｇｅｔ−Ｄｉａｌｏｇヘッダ（ＳＣＣ ＡＳは、ＩＣＳ ＵＥが同じセッションの一部として異なる要求を相関させることができるように、ＳＩＰ ＩＮＶＩＴＥ要求にＴａｒｇｅｔ−Ｄｉａｌｏｇヘッダを含み得る）、およびｉｉｉ）初期ＳＩＰ ＩＮＶＩＴＥ要求に含まれる全てのメディア種類に対するＳＤＰを含み得る。

単一の連絡先のみがＰＳドメインで登録される場合、ＳＣＣ ＡＳは、３ＧＰＰ ＴＳ２４．２２９に従ってＳＩＰ ＩＮＶＩＴＥ要求を作成し得、要求の中に、ｉ）パラメータ「ｒｅｑｕｉｒｅ」および「ｅｘｐｌｉｃｉｔ」とともに値「ｐｒｉｎｃｉｐａｌ」を含む、メディア特徴タグｇ．３ｇｐｐ．ｉｃｓを含むＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダ、およびｉｉ）初期ＳＩＰ ＩＮＶＩＴＥ要求に含まれる全てのメディア種類に対するＳＤＰを含み得る。

ここで図１７を参照すると、例示的なＵＥ１７００の実施形態を含む、無線通信システムが図示されている。ＵＥは、本開示の側面を実装するために動作可能であるが、本開示は、これらの実装に限定されるべきではない。携帯電話として図示されているが、ＵＥは、無線ハンドセット、ポケットベル、携帯用情報端末（ＰＤＡ）、携帯用コンピュータ、タブレットコンピュータ、ラップトップコンピュータ、スマートフォン、プリンタ、ファクス機、テレビ、セットトップボックス、および他のビデオ表示デバイス、家庭用音響機器および他の家庭用娯楽システム、家庭用監視および制御システム（例えば、家庭監視、アラームシステム、および気候制御システム）、およびコンピュータ化された冷蔵庫等の進化型家庭用電化製品を含む、種々の形態を成し得る。多くの好適なデバイスは、これらの機能のうちのいくつかはまた全てを組み合わせる。本開示のいくつかの実施形態では、ＵＥ１７００は、携帯用、ラップトップ、またはタブレットコンピュータのような汎用コンピュータデバイスではないが、むしろ、携帯電話、無線ハンドセット、ポケットベル、ＰＤＡ、または車載電気通信デバイス等の特殊用途通信デバイスである。ＵＥ１７００はまた、デバイスであり得、デバイスを含み得、または、同様の機能を有するが、デスクトップコンピュータ、セットトップボックスまたはネットワークノード等の運搬可能ではないデバイスに含まれ得る。ＵＥ１７００は、ゲーム、在庫管理、ジョブ制御、および／またはタスク管理機能等の、特殊活動をサポートし得る。

ＵＥ１７００は、ディスプレイ７０２を含む。ＵＥ１７００はまた、ユーザによる入力のために、概して７０４と呼ばれる、タッチセンサ式表面、キーボード、または他の入力キーも含む。キーボードは、ＱＷＥＲＴＹ、Ｄｖｏｒａｋ、ＡＺＥＲＴＹ、および逐次タイプ等の、完全または縮小英数字キーボード、または電話キーパッドと関連するアルファベット文字を伴う従来の数字キーパッドであり得る。入力キーは、さらなる入力機能を提供するように内向きに押下され得る、トラックホイール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能キーを含み得る。ＵＥ１７００は、ユーザが選択するためのオプション、ユーザが作動させるための制御、および／またはユーザが指図するためのカーソルあるいは他の指標を提示し得る。

ＵＥ１７００はさらに、ダイヤルする番号、またはＵＥ１７００の動作を構成するための種々のパラメータ値を含む、ユーザからのデータ入力を受け取り得る。ＵＥ１７００はさらに、ユーザコマンドに応じて、１つ以上のソフトウェアまたはファームウェアアプリケーションを実行し得る。これらのアプリケーションは、ユーザ相互作用に応じて種々のカスタマイズされた機能を果たすようにＵＥ１７００を構成し得る。加えて、ＵＥ１７００は、例えば、無線基地局、無線アクセスポイント、またはピアＵＥ１７００から、無線でプログラムおよび／または構成され得る。

ＵＥ１７００によって実行可能な種々のアプリケーションの中には、ディスプレイ７０２がウェブページを表示することを可能にするウェブブラウザがある。ウェブページは、無線ネットワークアクセスノード、携帯電話の基地局、ピアＵＥ１７００、または任意の他の無線通信ネットワークあるいはシステム１７０２との無線通信を介して、取得され得る。ネットワーク１７０２は、インターネット等の有線ネットワーク１７０４に連結される。無線リンクおよび有線ネットワークを介して、ＵＥ１７００は、サーバ１７０６等の種々のサーバ上の情報にアクセスできる。サーバ１７０６は、ディスプレイ７０２上に示され得る、コンテンツを提供し得る。代替として、ＵＥ１７００は、中継型またはホップ型の接続において、中間物としての役割果たすピアＵＥ１７００を通してネットワーク１７０２にアクセスし得る。

図１８は、ＵＥ１７００のブロック図を示す。ＵＡ１７００の種々の既知の構成要素が描写されているが、実施形態では、記載された構成要素の一部および／または記載されていない追加の構成要素が、ＵＥ１７００に含まれ得る。ＵＥ１７００は、デジタル信号プロセッサ（ＤＳＰ）１８０２と、メモリ１８０４とを含む。示されるように、ＵＥ１７００はさらに、アンテナおよびフロントエンドユニット１８０６と、無線周波数（ＲＦ）送受信機１８０８と、アナログベースバンド処理ユニット１８１０と、マイクロホン１８１２と、イヤホンスピーカ１８１４と、ヘッドセットポート１８１６と、入力／出力インターフェース１８１８と、可撤性メモリカード１８２０と、ユニバーサルシリアルバス（ＵＳＢ）ポート１８２２と、短距離無線通信サブシステム１８２４と、アラート１８２６と、キーパッド１８２８と、タッチセンサ式表面を含み得る液晶ディスプレイ（ＬＣＤ）１８３０と、ＬＣＤコントローラ１８３２と、電荷結合素子（ＣＣＤ）カメラ１８３４と、カメラコントローラ１８３６と、グローバルポジショニングシステム（ＧＰＳ）センサ１８３８とを含み得る。実施形態では、ＵＥ１７００は、タッチセンサ式画面を提供しない、別の種類のディスプレイを含み得る。実施形態では、ＤＳＰ１８０２は、入力／出力インターフェース１８１８を通過せずに、メモリ１８０４と直接通信し得る。

ＤＳＰ１８０２または何らかの他の形態のコントローラあるいは中央処理ユニットは、メモリ１８０４に記憶された、またはＤＳＰ１８０２自体内に含まれるメモリに記憶された、組み込みソフトウェアまたはファームウェアに従って、ＵＥ１７００の種々の構成要素を制御するように動作する。組み込みソフトウェアまたはファームウェアに加えて、ＤＳＰ１８０２は、メモリ１８０４に記憶された、または、可撤性メモリカード１８２０のような携帯用データ記憶メディア等の情報担体媒体を介して、あるいは有線または無線ネットワーク通信を介して利用可能となった、他のアプリケーションを実行し得る。アプリケーションソフトウェアは、所望の機能性を提供するようにＤＳＰ１８０２を構成する、コンパイルされた一式の機械可読命令を備え得、または、アプリケーションソフトウェアは、ＤＳＰ１８０２を間接的に構成するようにインタープリタまたはコンパイラによって処理される、高次ソフトウェア命令であり得る。

アンテナおよびフロントエンドユニット１８０６は、無線信号と電気信号との間で変換するように提供され得、ＵＥ１７００が、セルラーネットワークまたは何らかの他の利用可能な無線通信ネットワークから、あるいはピアＵＥ１７００から、情報を送受信することを可能にする。実施形態では、アンテナおよびフロントエンドユニット１８０６は、ビーム形成および／または多重入出力（ＭＩＭＯ）動作をサポートするように、複数のアンテナを含み得る。当業者に公知であるように、ＭＩＭＯ動作は、困難なチャネル条件を克服するために、および／またはチャネルスループットを増加させるために使用することができる、空間的多様性を提供し得る。アンテナおよびフロントエンドユニット１８０６は、アンテナ同調および／またはインピーダンス整合構成要素、ＲＦ電力増幅器、および／または低雑音増幅器を含み得る。

ＲＦ送受信機１８０８は、周波数偏移を提供し、受信したＲＦ信号をベースバンドに変換し、ベースバンド伝送信号をＲＦに変換する。いくつかの説明では、無線送受信機またはＲＦ送受信機は、変調／復調、符号化／復号、インターリービング／デインターリービング、拡散／逆拡散、逆高速フーリエ変換（ＩＦＦＴ）／高速フーリエ変換（ＦＦＴ）、周期的接頭辞添付／除去、および他の信号処理機能等の、他の信号処理機能性を含むと理解され得る。簡単にする目的で、ここでの説明は、ＲＦおよび／または無線段階から、この信号処理の説明を分離し、その信号処理を、アナログベースバンド処理ユニット１８１０および／またはＤＳＰ１８０２あるいは他の中央処理ユニットに概念的に割り当てる。いくつかの実施形態では、ＲＦ送受信機１８０８、アンテナおよびフロントエンド１８０６の複数部分、およびアナログベースバンド処理ユニット１８１０が、１つ以上の処理ユニットおよび／または特定用途向け集積回路（ＡＳＩＣ）に組み入れられ得る。

アナログベースバンド処理ユニット１８１０は、入力および出力の種々のアナログ処理、例えば、マイクロホン１８１２およびハンドセット１８１６からの入力ならびにイヤホン１８１４およびハンドセット１８１６への出力のアナログ処理を提供し得る。そのためには、アナログベースバンド処理ユニット１８１０は、ＵＥ１７００が携帯電話として使用されることを可能にする、内蔵マイクロホン１８１２およびイヤホンスピーカ１８１４に接続するためのポートを有し得る。アナログベースバンド処理ユニット１８１０はさらに、ヘッドセットまたは他のハンズフリーマイクロホンおよびスピーカ構成に接続するためのポートを含み得る。アナログベースバンド処理ユニット１８１０は、１つの信号方向にデジタル・アナログ変換を、反対の信号方向にアナログ・デジタル変換を提供し得る。いくつかの実施形態では、アナログベースバンド処理ユニット１８１０の機能性の少なくとも一部が、デジタル処理構成要素によって、例えば、ＤＳＰ１８０２によって、または他の中央処理ユニットによって提供され得る。

ＤＳＰ１８０２は、変調／復調、符号化／復号、インターリービング／デインターリービング、拡散／逆拡散、逆高速フーリエ変換（ＩＦＦＴ）／高速フーリエ変換（ＦＦＴ）、周期的接頭辞添付／除去、および無線通信と関連する他の信号処理機能を行い得る。実施形態では、例えば、符号分割多重アクセス（ＣＤＭＡ）技術用途で、伝送器機能のために、ＤＳＰ１８０２は、変調、符号化、インターリービング、および拡散を行い得、受信機機能のために、ＤＳＰ１８０２は、逆拡散、デインターリービング、復号、および復調を行い得る。別の実施形態では、例えば、直交周波数分割多重アクセス（ＯＦＤＭＡ）技術用途で、伝送器機能のために、ＤＳＰ１８０２は、変調、符号化、インターリービング、逆高速フーリエ変換、および周期的接頭辞添付を行い得、受信機機能のために、ＤＳＰ１８０２は、周期的接頭辞除去、高速フーリエ変換、デインターリービング、復号、および復調を行い得る。他の無線技術用途では、さらに他の信号処理機能、および信号処理機能の組み合わせが、ＤＳＰ１８０２によって行われ得る。

ＤＳＰ１８０２は、アナログベースバンド処理ユニット１８１０を介して無線ネットワークと通信し得る。いくつかの実施形態では、通信は、インターネット接続を提供し得、ユーザがインターネット上のコンテンツへのアクセスを獲得することと、Ｅメールおよびテキストメッセージを送受信することとを可能にする。入力／出力インターフェース１８１８は、ＤＳＰ１８０２ならびに種々のメモリおよびインターフェースを相互接続する。メモリ１８０４および可撤性メモリカード１８２０は、ＤＳＰ１８０２の動作を構成するように、ソフトウェアおよびデータを提供し得る。インターフェースの中には、ＵＳＢインターフェース１８２２および短距離無線通信サブシステム１８２４があり得る。ＵＳＢインターフェース１８２２は、ＵＥ１７００に課金するために使用され得、また、ＵＥ１７００が周辺デバイスとして機能し、パーソナルコンピュータまたは他のコンピュータシステムと情報を交換することを可能にし得る。短距離無線通信サブシステム１８２４は、赤外線ポート、Ｂｌｕｅｔｏｏｔｈ（登録商標）インターフェース、ＩＥＥＥ８０２．１１に準拠する無線インターフェース、あるいは、ＵＥ１７００が他の近くの携帯デバイスおよび／または無線基地局と無線通信することを可能にし得る、任意の他の短距離無線通信サブシステムを含み得る。

入力／出力インターフェース１８１８はさらに、誘起されると、例えば、ベルを鳴らす、メロディを再生する、または振動することによって、ＵＥ１７００にユーザへ通知を提供させる、アラート１８２６にＤＳＰ１８０２を接続し得る。アラート１８２６は、無音で振動することによって、または特定の架電者に対して特定の事前に割り当てられたメロディを再生することによって、着信電話、新しいテキストメッセージ、および予約のリマインダ等の種々のイベントのうちのいずれかをユーザに警告するための機構としての機能を果たし得る。

キーパッド１８２８は、インターフェース１８１８を介してＤＳＰ１８０２に連結し、ユーザが選択を行い、情報を入力し、別様に入力をＵＥ１７００に提供するための１つの機構を提供する。キーボード１８２８は、ＱＷＥＲＴＹ、Ｄｖｏｒａｋ、ＡＺＥＲＴＹ、および逐次タイプ等の、完全または縮小英数字キーボード、または電話キーパッドと関連するアルファベット文字を伴う従来の数字キーパッドであり得る。入力キーは、さらなる入力機能を提供するように内向きに押下され得る、トラックホイール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能キーを含み得る。別の入力機構は、タッチスクリーン能力を含み、また、ユーザにテキストおよび／またはグラフィックを表示し得る、ＬＣＤ１８３０であり得る。ＬＣＤコントローラ１８３２は、ＤＳＰ１８０２をＬＣＤ１８３０に連結する。

ＣＣＤカメラ１８３４は、装備された場合、ＵＥ１７００がデジタル写真を撮ることを可能にする。ＤＳＰ１８０２は、カメラコントローラ１８３６を介してＣＣＤカメラ１８３４と通信する。別の実施形態では、電荷結合素子カメラ以外の技術に従って動作するカメラが採用され得る。ＧＰＳセンサ１８３８は、グローバルポジショニングシステム信号を復号するようにＤＳＰ１８０２に連結され、それにより、ＵＥ１７００がその位置を決定することを可能にする。種々の他の周辺機器もまた、追加の機能、例えば、ラジオおよびテレビ受信を提供するように含まれ得る。

図１９は、ＤＳＰ１８０２によって実装され得る、ソフトウェア環境１９０２を図示する。ＤＳＰ１８０２は、残りのソフトウェアが動作するプラットフォームを提供する、オペレーティングシステムドライバ１９０４を実行する。オペレーティングシステムドライバ１９０４は、アプリケーションソフトウェアにアクセス可能である標準化インターフェースを伴うＵＡハードウェアに対するドライバを提供する。オペレーティングシステムドライバ１９０４は、ＵＥ１７００上で作動するアプリケーション間で制御を移転する、アプリケーション管理サービス（「ＡＭＳ」）１９０６を含む。図１９には、ウェブブラウザアプリケーション１９０８、メディアプレーヤアプリケーション１９１０、およびＪａｖａ（登録商標）アプレット１９１２も示される。ウェブブラウザアプリケーション１９０８は、ウェブブラウザとして動作するようにＵＥ１７００を構成し、ユーザが書式に情報を入力し、リンクを選択してウェブページを読み出し、閲覧することを可能にする。メディアプレーヤアプリケーション１９１０は、音声または視聴覚媒体を読み出し、再生するようにＵＥ１７００を構成する。Ｊａｖａ（登録商標）アプレット１９１２は、ゲーム、ユーティリティ、および他の機能性を提供するようにＵＥ１７００を構成する。構成要素１９１４は、本明細書で説明される機能性を提供する場合がある。

ＵＥ１７００、アクセスデバイス、および上記で説明される他の構成要素は、上記で説明される措置に関係する命令を実行することが可能である、処理構成要素を含む場合がある。図２０は、本明細書で開示される１つ以上の実施形態を実装するために好適な処理構成要素２０１０を含む、システム２０００の実施例を図示する。プロセッサ２０１０（中央処理装置（ＣＰＵまたはＤＳＰ）と呼ばれ得る）に加えて、システム２０００は、ネットワーク接続デバイス２０２０、ランダムアクセスメモリ（ＲＡＭ）２０３０、読み出し専用メモリ（ＲＯＭ）２０４０、２次記憶装置２０５０、および入出力（Ｉ／Ｏ）デバイス２０６０を含む場合がある。いくつかの実施例では、最小数のＨＡＲＱプロセスＩＤの決定を実装するためのプログラムが、ＲＯＭ２０４０に記憶され得る。場合によっては、これらの構成要素のうちのいくつかが存在しなくてもよく、または相互と、または示されていない他の構成要素と種々の組み合わせで組み合わせられ得る。これらの構成要素は、単一の物理的実体に、または１つより多くの物理的実体に位置する場合がある。プロセッサ２０１０によって講じられるものとして本明細書で説明される、任意の措置は、プロセッサ２０１０によって単独で、または、図面に示されている、あるいは示されていない１つ以上の構成要素と併せて、プロセッサ２０１０によって講じられる場合がある。

プロセッサ２０１０は、それがネットワーク接続デバイス２０２０、ＲＡＭ２０３０、ＲＯＭ２０４０、または２次記憶装置２０５０（ハードディスク、フロッピー（登録商標）ディスク、または光ディスク等の、種々のディスクベースのシステムを含む場合がある）からアクセスする場合がある、命令、コード、コンピュータプログラム、またはスクリプトを実行する。１つだけのプロセッサ２０１０が示されているが、複数のプロセッサが存在し得る。したがって、命令は、プロセッサによって実行されるものとして論議され得るが、命令は、同時に、連続的に、または別様に、１つまたは複数のプロセッサによって実行され得る。プロセッサ２０１０は、１つ以上のＣＰＵチップとして実装され得る。

ネットワーク接続デバイス２０２０は、モデム、モデムバンク、イーサネット（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイス、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））無線送受信機デバイス等の無線送受信機デバイス、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ）デバイス、および／またはネットワークに接続するための他の周知のデバイスの形態を成し得る。これらのネットワーク接続デバイス２０２０は、プロセッサ２０１０が情報を受信する場合がある、またはプロセッサ２０１０が情報を出力する場合がある、インターネットまたは１つ以上の電気通信ネットワーク、あるいは他のネットワークと、プロセッサ２０１０が通信することを可能にし得る。

ネットワーク接続デバイス２０２０はまた、無線周波数信号またはマイクロ波周波数信号等の電磁波の形態で、データを無線で伝送および／または受信することが可能な１つ以上の送受信機構成要素２０２５も含む場合がある。代替として、データは、導電体の表面の中または上、同軸ケーブルの中、導波管の中、光ファイバ等の光媒体の中、あるいは他の媒体の中を伝播し得る。送受信機構成要素２０２５は、別個の受信および伝送ユニット、または単一の送受信機を含む場合がある。送受信機２０２５によって伝送または受信される情報は、プロセッサ２０１０によって処理されたデータ、またはプロセッサ２０１０によって実行される命令を含み得る。そのような情報は、例えば、コンピュータデータベースバンド信号または搬送波で具現化される信号の形態で、ネットワークから受信され、かつネットワークへ出力され得る。データは、データを処理または生成するか、あるいはデータを伝送または受信するために望ましい異なる順序に従って、順序付けられ得る。ベースバンド信号、搬送波に組み込まれた信号、または、現在使用されている、あるいは今後開発される他の種類の信号が、伝送媒体と呼ばれ、当業者に周知のいくつかの方法に従って生成され得る。

ＲＡＭ２０３０は、揮発性データを記憶するため、およびおそらくプロセッサ２０１０によって実行される命令を記憶するために使用される場合がある。ＲＯＭ２０４０は、典型的には２次記憶装置２０５０のメモリ容量よりも小さいメモリ容量を有する、不揮発性メモリデバイスである。ＲＯＭ２０４０は、命令、およびおそらく命令の実行中に読み出されるデータを記憶するために使用される場合がある。ＲＡＭ２０３０およびＲＯＭ２０４０の両方へのアクセスは、典型的には、２次記憶装置２０５０へのアクセスよりも速い。２次記憶装置２０５０は、典型的には、１つ以上のディスクドライブまたはテープドライブから成り、ＲＡＭ２０３０が全作業データを保持するほど十分に大きくない場合に、データの不揮発性記憶のために、またはオーバーフローデータ記憶デバイスとして使用される場合がある。２次記憶装置２０５０は、ＲＡＭ２０３０にロードされるプログラムが実行のために選択されると、そのようなプログラムを記憶するために使用され得る。

Ｉ／Ｏデバイス２０６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カード読取装置、紙テープ読取装置、プリンタ、ビデオモニタ、または他の周知の入力デバイスを含み得る。また、送受信機２０２５は、ネットワーク接続デバイス２０２０の構成要素であるかわりに、またはそれに加えて、Ｉ／Ｏデバイス２０６０の構成要素と見なされる場合がある。Ｉ／Ｏデバイス２０６０のうちのいくつかまたは全ては、ディスプレイおよび入力等のＵＥ１７００の以前に説明された図面に描写される種々の構成要素と実質的に同様であり得る。

いくつかの実施形態を本開示で提供したが、開示されたシステムおよび方法は、本開示の精神または範囲から逸脱することなく、多くの他の具体的形態で具現化され得ることを理解されたい。本実施例は、制限的ではなく例証的と見なされるものであり、本明細書で与えられる詳細に制限されることを意図するものではない。例えば、種々の要素または構成要素が組み合わされるか、または別のシステムに統合され得、または、ある特徴が省略されるか、あるいは実装されなくてもよい。

また、個別または別個のものとして種々の実施形態で説明および例証される、技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わされるか、あるいは統合され得る。相互に連結される、または直接連結される、あるいは通信するものとして示される、または論議される他の項目は、電気的であろうと、機械的であろうと、または別の方法であろうと、何らかのインターフェース、デバイス、または中間構成要素を通して、間接的に連結されるか、または通信し得る。変更、置換、および改変の他の実施例が、当業者によって究明可能であり、本明細書で開示される精神および範囲から逸脱することなく行うことができる。

本発明は、例えば、以下の項目を提供する。
（項目１）
セッション制御を起動する方法であって、
協調セッションの制御を起動するための要求を受信することと、
該協調セッションの制御を起動するための要求の受諾を決定することと、
該起動要求を受信することに応答して、指示を送信することと
を含み、
該指示は、決定された受諾を示す、
方法。
（項目２）
前記応答の中の前記指示は、受諾を示す、項目１に記載の方法。
（項目３）
受諾を示す前記応答の中の前記指示は、「Ａｃｔｉｖｅ（能動）」に設定されたＵＥ間移転コントローラである、項目２に記載の方法。
（項目４）
前記応答の中の前記指示が受諾を示す場合に、イベントパッケージに登録することをさらに含む、項目１に記載の方法。
（項目５）
前記応答の中の前記指示は、拒絶を示す、項目１に記載の方法。
（項目６）
受諾を示す前記応答の中の前記指示は、「Ｐａｓｓｉｖｅ（受動）」に設定されたＵＥ間移転コントローラである、項目５に記載の方法。
（項目７）
前記指示は、ＸＭＬ要素である、項目２に記載の方法。
（項目８）
前記指示は、ＸＭＬ要素である、項目６に記載の方法。
（項目９）
前記指示は、特徴タグである、項目２に記載の方法。
（項目１０）
前記指示は、特徴タグである、項目６に記載の方法。
（項目１１）
前記協調セッションの制御を起動するため要求は、メディアの移転を要求することも含む、項目１に記載の方法。
（項目１２）
プロセッサを備え、該プロセッサは、
協調セッションの制御を起動するための要求を受信することと、
該協調セッションの制御を起動するための要求の受諾を決定することと、
該起動要求を受信することに応答して、指示を送信することであって、該指示は、決定された受諾を示す、ことと
を行うように構成されている、
ネットワークノード。
（項目１３）
前記応答の中の前記指示は、受諾を示す、項目１２に記載のネットワークノード。
（項目１４）
受諾を示す前記応答の中の前記指示は、「Ａｃｔｉｖｅ（能動）」に設定されたＵＥ間移転コントローラである、項目１３に記載のネットワークノード。
（項目１５）
前記プロセッサは、前記応答の中の前記指示が受諾を示す場合に、イベントパッケージに登録するように構成されている、項目１２に記載のネットワークノード。
（項目１６）
前記応答の中の前記指示は、拒絶を示す、項目１２に記載のネットワークノード。
（項目１７）
受諾を示す前記応答の中の前記指示は、「Ｐａｓｓｉｖｅ（受動）」に設定されたＵＥ間移転コントローラである、項目１６に記載のネットワークノード。

Claims (14)

1. 協調セッションの制御を割り当てる方法であって、該方法は、
   ＳＩＰ ＩＮＶＩＴＥ要求およびＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの１つを受信し、該協調セッションの制御をユーザ機器（ＵＥ）において割り当てることと、
   該協調セッションの制御を受諾するかどうかを決定することと、
   該協調セッションの制御を割り当てるようにという該ＳＩＰ ＩＮＶＩＴＥ要求および該ＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの該１つを受信することに応答して、ＳＩＰ応答のコンタクトヘッダフィールドに含まれているメディア特徴タグの中の指示を送信することであって、該指示は、該協調セッションの該制御の受諾を示す、ことと
   を含む、方法。
2. 前記ＳＩＰ応答の中の前記指示は、前記協調セッションのアクティブコントローラであるという指示である、請求項１に記載の方法。
3. 前記ＳＩＰ ＩＮＶＩＴＥ要求および前記ＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの前記１つは、該ＳＩＰ ＩＮＶＩＴＥ要求および該ＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの該１つのＸＭＬボディに含まれている前記協調セッションの制御を割り当てるようにという指示を含む、請求項２に記載の方法。
4. 前記協調セッションの制御を割り当てるようにという前記指示は、ＸＭＬ要素内に含まれている、請求項３に記載の方法。
5. 前記協調セッションの制御を割り当てるようにという前記ＳＩＰ ＩＮＶＩＴＥ要求および前記ＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの前記１つは、該協調セッションのメディアタイプを識別するＳＤＰも含む、請求項１に記載の方法。
6. プロセッサを備えたネットワークノードであって、
   該プロセッサは、
   ＳＩＰ ＩＮＶＩＴＥ要求およびＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの１つを受信し、協調セッションの制御をユーザ機器（ＵＥ）において割り当てることと、
   該協調セッションの制御を受諾するかどうかを決定することと、
   該協調セッションの制御を割り当てるようにという該ＳＩＰ ＩＮＶＩＴＥ要求および該ＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの該１つを受信することに応答して、ＳＩＰ応答のコンタクトヘッダフィールドに含まれるメディア特徴タグにおける指示を送信することであって、該指示は、該協調セッションの該制御の受諾を示す、ことと
   を行うように構成されている、ネットワークノード。
7. 前記ＳＩＰ応答の中の前記指示は、前記協調セッションのアクティブコントローラであるという指示である、請求項６に記載のネットワークノード。
8. 前記メディア特徴タグの中の前記指示は、「Ａｃｔｉｖｅ（能動）」の値を有する、請求項６に記載のネットワークノード。
9. 前記ＳＩＰ応答は、ＳＩＰ ２００ ＯＫ応答である、請求項６に記載のネットワークノード。
10. 前記ＳＩＰ ＩＮＶＩＴＥ要求および前記ＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの前記１つは、該ＳＩＰ ＩＮＶＩＴＥ要求および該ＳＩＰ ｒｅ−ＩＮＶＩＴＥ要求のうちの該１つのＸＭＬボディに含まれている前記協調セッションの制御を割り当てるようにという指示を含む、請求項６に記載のネットワークノード。
11. 前記協調セッションの制御を割り当てるようにという前記指示は、ＸＭＬ要素内に含まれている、請求項１０に記載のネットワークノード。
12. 協調セッションの制御を割り当てるようにという前記要求は、該協調セッションのメディアタイプを識別するＳＤＰも含む、請求項６に記載のネットワークノード。
13. 前記メディア特徴タグの中の前記指示は、「Ａｃｔｉｖｅ（能動）」の値を有する、請求項１に記載の方法。
14. 前記ＳＩＰ応答は、ＳＩＰ ２００ ＯＫ応答である、請求項１に記載の方法。

Images