コントローラが常に含まれているわけではない協調セッションのためのメディアフローの継続性を維持するためのシステムおよび方法
【課題】コントローラが利用可能でない場合に、協調セッションの継続性をサポートするための方法を提供する。
【解決手段】コントローラがセッション内に常に含まれるわけではない特殊なケースにおいて、アプリケーションサーバが制御管理に関する決定を下すための方法であって、特殊ケースの制御管理プリファレンスとして規則を送るステップと、あるトリガポイントにおいて、規則に基づいて、制御／課金を移転、維持、または解放することを決定するステップと、プリファレンス規則およびＵＥ機能に基づいて、必要な場合は、制御および／または課金を移転するのに適切なエンティティを選択するステップと、を含む。
【解決手段】コントローラがセッション内に常に含まれるわけではない特殊なケースにおいて、アプリケーションサーバが制御管理に関する決定を下すための方法であって、特殊ケースの制御管理プリファレンスとして規則を送るステップと、あるトリガポイントにおいて、規則に基づいて、制御／課金を移転、維持、または解放することを決定するステップと、プリファレンス規則およびＵＥ機能に基づいて、必要な場合は、制御および／または課金を移転するのに適切なエンティティを選択するステップと、を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換通信ネットワークにおける電気通信の分野に関する。より詳細には、本発明は、ＩＰマルチメディアシステムにおけるセッション制御に関する。
【背景技術】
【０００２】
ますます多くのデバイスがネットワーク機能を獲得するようになったため、ユーザがこれらの複数のデバイスを管理する必要が生じている。そのような作業項目は、３ＧＰＰでは、協調セッション管理（ｃｏｌｌａｂｏｒａｔｉｖｅ ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）の範囲の中で扱われている。協調セッション管理では、ＩＭＳサービスに登録している多くのユーザデバイスは、異なるメディアフローを有するセッションにおいて、互いに協力することができる。協調セッションとは、複数のＵＥが含まれ、互いに協調する、マルチメディアセッションのことである。コントローラＵＥが、アプリケーションサーバと対話することによって、コントローラ上のメディアを管理する。コントローラからのいかなる要求も、アクションを起こす前に、コントローラによって認可されなければならない。通常、１つのメディアフローは、ただ１つのコントローラによって制御される。
【０００３】
協調セッションにおいて（特定のフローについて）単一コントローラ構成であることにより、ＵＥ故障、バッテリ消耗、カバレージ圏外のＵＥ、不安定な信号などの制御不能な理由でコントローラが失われた場合、問題がある。コントローラが自らを受動制御モード（ｐａｓｓｉｖｅ−ｃｏｎｔｒｏｌ ｍｏｄｅ）に移行させたい状況、または一時的に協調セッションから離脱したい状況もある。これらのケースは、コントローラが変化を起こすたびに中断されることをコントローラが望まない場合、または長い間にわたってコントローラがいかなる要求も申し込まない場合に生じることがある。ここで、受動制御モードとは、コントローラＵＥが自動制御モードにあることを選択すること、または制御を一時的にアプリケーションサーバに渡すことを意味する。すなわち、コントローラＵＥは、あるトリガシナリオにおいて決定を下す規則を設定することによって、またはアプリケーションサーバもしくはコントローラＵＥなどの他のノードに責任を移譲することによって、受動的であり続ける。
【０００４】
最新の３ＧＰＰ ＴＳ２３．２３７では、コントローラが失われた場合に、ＳＣＣ ＡＳが、協調セッションに参加しているすべてのアクセスレグ（Ａｃｃｅｓｓ Ｌｅｇ）を解放することが示されている。
【０００５】
この手法の問題は、コントローラは、何が起こったのかを知ることなく、セッションを終了するように常に強制され、コントローラは、ユーザが続行を望み、支払いをする意思がある場合でも、続行または再開することができないことである。
【０００６】
別の可能な手法は、コントローラが失われた場合に、ＳＣＣ ＡＳが、協調セッション制御を、協調セッションに含まれ、同じサブスクリプションに属する別のＵＥに移転できるようにすることである［非特許文献４］。
【０００７】
この方法は、この問題を解決する一歩となるが、後継コントローラをどのように選択すべきか、他のＵＥが異なるサブスクリプションに属する場合に何が起きるかを規定していない。明らかに、コントローラが受動制御モードに移行することを望む場合の問題を解決するために、何らかのより優れたソリューションが必要とされており、通信事業者が協調セッションサービスを展開する場合、それは不可避である。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】３ＧＰＰ ＴＳ ２３．２３７ ｖ９．２．０、「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ （ＩＭＳ） Ｓｅｒｖｉｃｅ Ｃｏｎｔｉｎｕｉｔｙ」
【非特許文献２】３ＧＰＰ ＴＳ ２４．２３７ ｖ９．０．０、「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ （ＩＭＳ） Ｓｅｒｖｉｃｅ Ｃｏｎｔｉｎｕｉｔｙ」
【非特許文献３】３ＧＰＰ ＴＲ ２３．８３８ ｖ９．０．０、「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ （ＩＭＳ） ｓｅｒｖｉｃｅ ｃｏｎｔｉｎｕｉｔｙ ｅｎｈａｎｃｅｍｅｎｔｓ； Ｓｅｒｖｉｃｅ， ｐｏｌｉｃｙ ａｎｄ ｉｎｔｅｒａｃｔｉｏｎ」
【非特許文献４】３ＧＰＰ ＴＳＧ ＳＡ ＷＧ２ Ｍｅｅｔｉｎｇ ＃７６、２００９年１１月１６〜２０日、Ｓａｎ Ｊｏｓｅ Ｄｅｌ Ｃａｂｏ、Ｍｅｘｉｃｏ ＴＤ Ｓ２−０９６７６７、「Ｒｅｑｕｉｒｅｍｅｎｔ ｏｆ Ｃｏｎｔｒｏｌ ｔｒａｎｓｆｅｒ ｕｐｏｎ ｌｏｓｔ ｏｆ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ」
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、上述の問題、短所、および不完全性に対処することである。特に、本発明は、コントローラが利用可能でない場合に、協調セッションの継続性をサポートするための方法を提供することを目的とする。
【００１０】
本発明の別の目的は、アプリケーションサーバと、リリース、サブスクリプション、および機能に制限を設けないＵＥとを含む、コントローラ喪失に耐性のある堅牢なシステムを提供することである。システムにおいて、協調セッションは、単一または複数のコントローラを用いて確立される。各コントローラは、あるメディアフローを制御する独自の責任を有する。すべての端末ＵＥは、互いに、またアプリケーションサーバと協力して、コントローラが事故で失われた場合、またはコントローラが離脱した場合に、セッション中断を回避する。
【課題を解決するための手段】
【００１１】
一態様では、制御プリファレンス情報（ｃｏｎｔｒｏｌ−ｐｒｅｆｅｒｅｎｃｅ ｉｎｆｏｒｍａｔｉｏｎ）が、アプリケーションサーバに送られる。コントローラが失われた場合、または受動モードに移行する場合、新しいコントローラを、リファレンスを参照することによって決定することができ、またはデフォルト規則によって決定することができる。その後のアクションが、制御を別のデバイスに移転することができ、別のデバイスは、制御および課金を引き継ぐ意思があるかどうかを尋ねられる。
【００１２】
別の態様では、プリファレンスは、１つまたは複数のリストを含む。これらのリストは、現在のコントローラが失われた場合に、後継コントローラを指定するために、後継者をどのように選択すべきかに関する規則を提供するために、メディア管理に制限を設けるために、およびセッション解放のためのトリガポイントを設定するために使用される。
【００１３】
また別の態様では、端末は、アプリケーションサーバに要求して、制御を受動制御モードに移行させることが可能である。受動制御中は、メディア解像度変更などの通常の決定は、セッション開始時またはＩＭＳ登録時に設定されたプリファレンス制御規則を通して、アプリケーションサーバによって自動的に行われる。アプリケーションサーバからの問い合わせを受け取る場合、端末は、問い合わせを処理し、それに応答する機能を有する。その機能は、問い合わせを理解できない場合であっても、依然として「不明」メッセージを用いて応答する。これらの追加機能は、セッション制御を、自動制御および緊急ケースに拡張する。
【００１４】
別の態様では、アプリケーションサーバは、異なるタイプのプリファレンスを識別し、将来の使用のためにそれを処理できる、プリファレンス処理機能を含む。アプリケーションサーバは、コントローラ喪失を検出するための、コントローラ喪失検出機能も有する。アプリケーションサーバは、コントローラがある期間応答しない場合にプリファレンスを参照する、制御移転決定機能をさらに有する。
【００１５】
別の態様では、制御は、セッションの認可とメディアフローの課金の両方に拡張される。コントローラは、制御するメディアフローの変更について決定を下す責任を負い、コントローラは、制御するメディアフローについて課金されるエンティティでもある。コントローラからのプリファレンスは、コントローラが失われた場合に、課金エンティティをどのように再割り当てすべきかを示している。制御移転および課金移転は、別々の決定であるが、コントローラおよびアプリケーションサーバは、プリファレンスおよび決定において、それらを一体化することを選択することができる。
【００１６】
これらのソリューションを用いることで、コントローラが離脱した場合に、セッションを継続できる可能性がより高まる。コントローラとＳＣＣ ＡＳの両方が、制御移転の決定に参加することができる。サブスクリプションは、もはや制限とはならない。
【図面の簡単な説明】
【００１７】
【図１】セッション制御能力を有する、または有さない、例えば１０１および１０５などのいくつかのＵＥ端末と、セッション端末を調整するアプリケーションサーバ（１０２）と、ＩＭＳシグナリングサポートを提供するＩＭＳコアネットワーク（１０３）と、ＵＥとのセッションを有するリモートパーティ（１０４）とから成る、全体的なシステムを示す図である。
【図２】協調セッションにおいて特にコントローラ（１０１）として機能する端末デバイスの構造の図である。
【図３】セッション全体を管理するアプリケーションサーバの構造の図である。
【図４】コントローラまたはコントローラである、協調セッションにおいて他のユーザ機器として機能する端末デバイス（１０５）の構造の図である。
【図５】コントローラが予告なしに失われた場合、またはコントローラが受動モードに移行する場合に、アプリケーションサーバがどのように制御移転の決定を下すかを示すフローチャート図である。
【図６】異なるタイプの規則がツリー上に示された、コントローラによって生成され、アプリケーションサーバ内に記憶されるプリファレンスの構造を示す図である。
【図７】ＵＥとアプリケーションサーバの間での信号交換を用いて、コントローラが受動制御モードに移行する場合の例示的な動作シーケンスを示す図である。
【図８】コントローラが失われた後、いつセッションを解放すべきかに関するコントローラ設定のプリファレンスを有する、コントローラ喪失ソリューションのための代替的な動作シーケンスを示す図である。
【図９】コントローラが後継者を指名する、または後継コントローラをどのように選択すべきかに関する設定プリファレンスを有する、コントローラ喪失ソリューションのための別の代替的な動作シーケンスを示す図である。
【図１０】アプリケーションサーバが、セッション内のＵＥに対してブロードキャストを行い、ＵＥの能力および制御を引き継ぐ意思について尋ねる、コントローラ喪失ソリューションのための異なる動作シーケンスを示す図である。
【図１１】アプリケーションサーバが、コントローラ喪失のせいでＵＥにおいて終了するメディアの課金を引き継ぐかどうかを影響を受けるＵＥに問い合わせる、コントローラ喪失ソリューションのための別の動作シーケンスを示す図である。
【発明を実施するための形態】
【００１８】
本発明の例示的な実施形態についての以下の詳細な説明では、本明細書の一部を形成し、例として示される添付の図面、本発明を実施できる特定の例示的な実施形態が参照される。各実施形態は、当業者が本発明を実施できるように、十分な詳細さで説明されるが、本発明の主旨または範囲から逸脱することなく、実施形態を利用することができ、他の変更を施すことができることを理解されたい。したがって、以下の詳細な説明は、限定的な意味で解釈されるべきではなく、本発明の範囲は、添付の特許請求の範囲のみによって定められる。以下の説明では、説明の目的で、本発明の完全な理解を提供するために、具体的な数、回数、構造、プロトコル、および他のパラメータが説明される。しかし、これらの具体的な細部を伴わなくても、本発明を実施できることは、当業者には明らかであろう。
【００１９】
図１は、協調セッションを制御するコントローラＵＥ １０１と、制御権をもたずにセッションに参加する通常のＵＥ １０５と、ＵＥとリモートパーティの間のセッションを調整するアプリケーションサーバ１０２と、セッションにＩＭＳシグナリングおよびルーティング機能を提供するＩＭＳコアネットワーク１０３と、ＵＥとのセッションを有するリモートパーティ１０４とから成る、本発明をサポートするシステムを示している。コントローラまたはコントローラであるすべてのＵＥは、標準的なＩＭＳ手順を通して、アプリケーションサーバと通信する。本発明では、コントローラからアプリケーションサーバへの通信１１０は、標準的な要素のほかに追加情報を有し、セッション制御のためのユーザプリファレンスを含み、通常のＵＥからアプリケーションサーバへの通信１１３は、標準的な要素のほかに追加情報を有し、ＵＥ能力パラメータを含む。コントローラＵＥ １０１だけが、制御プリファレンスを送ることを求められ、他のユーザ１０５は、能力パラメータを送るか、それとも送らないかを選択することができる。１０１からのユーザ制御プリファレンスは、協調／対話的セッションセットアップ時に、またはＩＭＳ登録時に送ることができる。制御プリファレンスは、アプリケーションサーバ１０２によって理解可能な任意のフォーマットを取ることができる。制御プリファレンスは、コントローラが予告したうえで離脱する場合に、どのように制御を実行すべきか、またコントローラが予告なしに接続を失った場合に、どのようにセッションを管理すべきかについて、アプリケーションサーバに命令するために使用される。ＵＥ能力パラメータは、アプリケーションサーバによって理解可能な任意のフォーマットで送ることができる。ＵＥ能力パラメータは、例えば、ＵＥの制御能力、バッテリレベル、ＩＭＳリリースバージョンなどを含む。この追加情報は、コントローラがセッションを離脱した場合、または接続を失った場合に、決定を下すために、アプリケーションサーバによって使用される。本発明では、アプリケーションサーバ１０２は、制御プリファレンスに基づいてセッション制御を引き継ぐ追加機能、およびセッションに属するＵＥへの制御移転を決定する追加機能を有する。しかし、アプリケーションサーバ１０２は、決してセッションについての課金を引き継ぐことはない。したがって、アプリケーションサーバは、認可においてはコントローラを代理するが、課金においては決してコントローラを代理せずに、セッションを制御する。課金は、ＵＥに割り当てるよう求められる。アプリケーションサーバとＩＭＳ ＣＮの間の接続１１１、およびＩＭＳ ＣＮとリモートパーティの間の接続１１２は、標準的なＩＭＳ手順を使用し、ＩＭＳにおいて定義された標準的な情報を伝送する。
【００２０】
図２は、制御機能を有する通信デバイスである。通信デバイスは、セッションのコントローラとしての機能を果たすことができる。ユーザ機器の従来の機能のほかに、通信デバイスは、プリファレンス生成対話のためのＧＵＩブロック２０１と、ＧＵＩに接続されたユーザプリファレンス生成器２０２と、通信デバイスがセッションのコントローラである場合に、伝送レイヤ機能２０５を介してプリファレンスを送るユーザプリファレンス伝送機能２０４と、受動制御モードに移行することを要求する信号を発信できる受動制御機能２０３も含む。プリファレンスは、１つまたは複数のリストを含む。これらのリストは、現在のコントローラが接続を失った場合に、後継コントローラを指定するために、後継者をどのように選択すべきかに関する規則を提供するために、メディア管理に制限を設けるために、およびセッション解放のためのトリガポイントを設定するために使用される。例えば、プリファレンスを使用して、「Ｓｅｓｓｉｏｎ Ｔｅｒｍｉｎａｔｉｏｎ： １０ｍｉｎ」ということを示すことができる。その場合、通信デバイスがセッションを離脱すると、セッションは、通信デバイスが離脱してから１０分後に解放される。別の例は、「Ａｄｄ ｍｅｄｉａ： Ｒｅｊｅｃｔ； Ｍｏｄｉｆｙ ｍｅｄｉａ： Ａｇｒｅｅ」などのメディア管理規則を含むことができる。コントローラがこのプリファレンスを残して離脱した場合、アプリケーションサーバは、コントローラからのすべてのメディア追加要求を拒絶し、すべてのメディア変更要求に合意する。
【００２１】
端末のための別の新しい機能は、端末自体を受動制御モードに移行させるための要求を、アプリケーションサーバに送ることである。受動制御中は、メディア解像度変更などの通常の決定は、セッション開始時もしくはＩＭＳ登録時に設定され、または任意のＩＭＳ手順を使用して更新されるプリファレンス制御規則を通して、アプリケーションサーバによって自動的に行われる。ユーザプリファレンスを生成するため、ユーザプリファレンス生成器２０２は、質問を準備し、ＧＵＩ ２０１を介してユーザに問い合わせる。質問に対するユーザの回答は、ユーザプリファレンス生成器２０２において記憶され、処理され、それによって、プリファレンスファイルが、アプリケーションサーバ１０２によって理解可能なフォーマットで生成される。このプリファレンスファイルが、例えば、記憶カード、インターネットを介したダウンロード、Ｂｌｕｅｔｏｏｔｈ（登録商標）を介した別の端末からの転送など、異なる手段を介して端末にロードできることは当業者には明らかである。
【００２２】
端末がコントローラとして登録されている場合、プリファレンスを送り出すために、ユーザプリファレンス伝送機能２０４がトリガされる。プリファレンスは、コントローラが接続を失った場合に、制御ハンドオーバ問題を解決することを目標としている。プリファレンスは、コントローラが意図的に受動制御モードに移行する場合に、自動制御を実行するための１組の規則も含むことができる。コントローラではない端末の場合、ユーザプリファレンス生成器２０２は、登録時にユーザプリファレンスを生成する手順をスキップすることができる。プリファレンスは、後の任意の時に、端末がコントローラになる前に、生成できることは当業者には明らかである。加えて、プリファレンスは、セッションに変更が発生した場合は、セッション中に更新することができる。
【００２３】
図３は、協調セッションを管理するアプリケーションサーバ１０２のための例示的な構造を示している。新しい機能が、アプリケーションサーバに導入される。アプリケーションサーバは、制御プリファレンスを他の登録情報からふるい分けるプリファレンス受け取り機能３０１と、受け取った制御プリファレンスを分析するプリファレンス処理機能３０３と、コントローラの利用可能性を定期的にチェックするコントローラ喪失検出機能３０２と、アプリケーションサーバ内に記憶されたデフォルト規則、またはプリファレンス処理機能３０３から渡された制御プリファレンスに基づいて、コントローラが含まれない場合に、制御（および／または課金）移転を決定する制御移転決定機能３０４と、コントローラが受動制御モードに移行する場合、またはコントローラが失われた後にセッション解放手順が活動化された場合に制御を行う受動制御機能３０５とを含む。
【００２４】
アプリケーションサーバが、セッション内の他のＵＥの能力パラメータを有さない場合、アプリケーションサーバは、そのような情報を決定するために、ＵＥに問い合わせを行う必要がある。ＵＥ問い合わせ機能３０６が、この目的を遂行する。十分な情報を獲得した後、制御移転決定機能３０４は、制御移転を実行するか、それともセッションを解放するかを決定する。
【００２５】
アプリケーションサーバによって制御を引き継ぐ必要がある場合、アプリケーションサーバは、ユーザプリファレンスに基づいて制御を行うために、受動制御機能３０５を活動化する。これらの機能を用いて、アプリケーションサーバは、コントローラが失われた場合、または離脱した場合に、別のＵＥを選択し、別のＵＥに制御を移転させることによって、セッションを救うことができ、または自ら制御を引き継ぐことさえできる、インテリジェントなエージェントとして動作する。プリファレンス処理機能３０３は、端末とアプリケーションサーバの間で合意された任意のフォーマットで書かれた制御プリファレンスを説明し、分類する責任を負う。例えば、プリファレンスは、ＸＭＬを用いて書くことができ、プリファレンスは、同じサブスクリプションに属する後継コントローラのみを選択できることを示す。処理の後、このプリファレンスは、制御移転決定機能３０４に渡される。コントローラ喪失検出機能３０２が、タイマまたは他のベアラモニタを通して、コントローラ喪失を検出した場合、制御移転決定機能３０４は、それまでのコントローラと同じサブスクリプションに属する端末のみを、後継コントローラであると見なす。失われたコントローラと同じサブスクリプションに属する端末ＵＥが存在しない場合、アプリケーションサーバは、それを、プリファレンスなしのケースとして扱うべきである。それを扱うために、そのケースのための本発明の他の動作シーケンスを利用することができる。
【００２６】
図４は、制御機能を有する、または有さない、通常の通信デバイスである端末デバイス４００についての例示的なアーキテクチャを示している。端末デバイスは、協調セッションにおいてコントローラまたはコントローラとして動作するが、接続を失う、または受動制御モードに移行する、ターゲットコントローラではない。通常のユーザ機器の従来の機能のほかに、端末デバイスは、アプリケーションサーバ１０２からの問い合わせを処理し、それに応答できる、追加機能ブロックも含む。本発明では、アプリケーションサーバは、端末の制御機能と、制御および課金を引き継ぐ意思について、端末に問い合わせることができる。問い合わせ受け取り機能４０１および問い合わせ処理機能４０２は、そのようなメッセージを受け取り、それらを処理するために使用される。処理された問い合わせは、アプリケーションサーバ１０２に返される応答を生成するために、問い合わせ応答機能４０３に渡される。
【００２７】
ＵＥ構成／ステータス記録機能４０４は、データベースのような機能を果たす。ＵＥ構成／ステータス記録機能は、ＵＥのパラメータおよびステータスを提供し、問い合わせ応答機能４０３がアプリケーションサーバへの応答を生成するのを支援する。
【００２８】
問い合わせを、問い合わせ処理機能４０２が理解できない場合、問い合わせ応答機能４０３は、問い合わせ処理機能が不明な問い合わせを受け取ったことを示す、アプリケーションサーバ１０２への応答を生成する。
【００２９】
２００、３００、４００の間で交換されるすべてのシグナリングメッセージは、例えば、ＴＣＰチャネルまたは再送機構を有するＵＤＰチャネルを介して、通常のＩＭＳ機構上でトランスポートすることができる。ユーザプリファレンスは、ＩＭＳ登録中にＳＩＰ信号と一緒に送られ、または協調セッション確立中に、もしくはＵＥがコントローラＵＥになったときに、別個のパケットで送られる。ユーザは、端末デバイス２００上のＧＵＩを介して、いくつのプリファレンスを生成すべきかを決定する。すべての生成されたプリファレンスは、コントローラＵＥからアプリケーションサーバ３００に送られる。
【００３０】
図５は、主要な管理および意思決定デバイスである、アプリケーションサーバ１０２のための例示的なロジックのフローチャートである。コントローラ喪失または受動制御問題に対するソリューションが、このフローチャートに要約されている。
【００３１】
図は、主要な２つのブランチから成る。一方は、アプリケーションサーバが制御を引き継ぐ必要がある状況である。他方は、アプリケーションサーバが制御を引き継ぐ必要はない。第２のケースは、２つのブランチにさらに分割される。一方は、コントローラプリファレンスが利用可能であり、決定を下すことが可能である。他方は、プリファレンスが利用可能ではなく、または現在の状況と対立するせいで、既存のプリファレンスを適用することができない。
【００３２】
アプリケーションサーバ１０２が、コントローラ喪失を検出した場合、またはコントローラが受動制御モードに移行することを示す信号を受け取った場合、アプリケーションサーバは、対応するユーザプリファレンスが利用可能であるかどうかをチェックするステップ５０２を実行する。プリファレンスが利用可能である場合、アプリケーションサーバは、ステップ５０３に進み、アプリケーションサーバが制御を引き継ぐ必要があるかどうかをチェックする。
【００３３】
アプリケーションサーバ１０２が制御を引き継ぐ必要がある、２つの状況がある。１つの状況では、コントローラが受動制御モードに移行し、コントローラ上で制御関連の質問を処理する代わりに、アプリケーションサーバに質問に回答するように要求する。他の状況では、コントローラが予告なしに接続を失い、アプリケーションサーバ１０２が、事前設定されたプリファレンスに従って、例えば、あるトリガの後でセッションを解放する、異なるコントローラを選択して制御を移転するなど、セッションを扱う責任を負う。
【００３４】
アプリケーションサーバが制御を引き継ぐ必要がない場合、アプリケーションサーバは、現在のセッションステータスパラメータをチェックするために、さらにステップ５０５に進む。ステップ５０６は、ユーザプリファレンスを現在のセッションステータスと照合するチェック手順である。現在のセッションステータスは、現在のセッションに関連するすべての情報を含む。例えば、セッションに含まれるＵＥのＩＤ、各ＵＥのサブスクリプション、各ＵＥにおけるメディア終了の数などである。プリファレンスとセッションステータスの照合は、双方からの文字列または値を比較することである。例えば、トムが後継者であることを、プリファレンスが示している場合、トムは、機能３０３によってトムのＵＥのＩＤに変換され、ステップ５０６は、このＩＤを、セッションに参加しているすべてのＵＥのＩＤと比較する。最大数のメディアフローを有するＵＥが制御を引き継ぐことを、プリファレンスが示している場合、ステップ５０６は、最大数のメディアフローを所有するＵＥが存在するかどうかをチェックする。プリファレンス基準を満たすＵＥがセッション内に存在する場合、現在のセッションステータスは、ユーザプリファレンスと一致すると言われる。
【００３５】
現在のセッションステータスがユーザプリファレンスと一致しない場合、意思決定手順は、プリファレンスが利用可能ではない場合のブランチである、ステップ５１１に向かう。不一致の一例は、以下のようなものである。ユーザプリファレンスは、ジョンが現在のコントローラの後継者であることを示している。しかし、コントローラが失われたとき、ジョンはすでにセッションを離脱している。この例は、セッション内で何かが変化した場合は常に、アプリケーションサーバが、制御プリファレンスを更新するためのトリガをコントローラＵＥに送ることができるならば、回避することができる。しかし、そのような種類のトリガがない場合は、不一致が発生することがある。
【００３６】
現在のセッションステータスとユーザプリファレンスの間で不一致が発生しない場合、ステップ５０７において、後継者が決定され、ステップ５０８において、選択された後継者は、新しいコントローラになることを了承するかどうかを尋ねられる。選択された端末（後継者）が、制御が可能であり、引き継ぎに合意した場合、制御は、選択された端末に移転されるが、選択された端末が、申入れを拒絶した場合、または制御を実行することが可能でない場合は、例えば、セッションを解放するなど、ステップ５１０において、他の動作が取られる。複数の端末がユーザプリファレンス基準を満たす場合、セッションを解放する前に、選択−問い合わせ−応答手順を繰り返すことができる。
【００３７】
プリファレンスなしに、コントローラが失われた場合、アプリケーションサーバ１０２は、制御を移転するとも、制御を引き継ぐとも決定することができない。ステップ５１２において、アプリケーションサーバは、影響を受けるユーザが自らのメディアフローの課金を引き継ぐ意思があるかどうかをチェックすることによって、影響を受けるセッションを救おうと試みることができるにすぎない。引き継ぐ意思がある場合は、ステップ５１３において、影響を受けるユーザに課金が移転されるが、引き継ぐ意思がない場合は、ステップ５１０において、制御とメディアの両方が解放される。影響を受けるユーザが協調セッションにおける最後のＵＥである場合は、課金移転後は、協調セッションはもはやないことに留意されたい。影響を受けるユーザは、通常のＩＭＳセッションに移行し、リモートパーティ１０４との自らのメディアフローを継続する。
【００３８】
図６は、プリファレンスの構造を示している。本発明におけるソリューションに基づいて、６組の規則が提示されている。後継コントローラの優先順位のリスト５５１は、サブスクリプション情報５６２、ユーザ名５６３、ＵＥ識別番号５６１など、排他的な同一性を使用して後継コントローラを指定する、１組の規則である。後継コントローラの優先順位のリストは、コントローラが失われた場合に、アプリケーションサーバが誰を最初に選択すべきか分かるように、これらの潜在的な後継者の優先順位も指定する。例えば、プリファレンスは、後継者の序列が、トム−マリー−ジョンであることを示す。その場合、アプリケーションサーバは、コントローラ喪失の場合、最初にトムに制御を引き継ぐように依頼する。トムが要求を拒絶した場合、マリーが依頼を受ける。そのようなプリファレンスは、ＵＥがセッションに参加する都度、またはセッションから離脱する都度、更新される。
【００３９】
コントローラが後継者を明示的に指定したくない場合、後継コントローラ選択規則５５２を使用して、アプリケーションサーバが後継者を選択するための基準を設定することができる。例えば、後継者は、コントローラがセッションに参加した順序５６８に従って選択される。アプリケーションサーバは、コントローラの参加順序を記録し、それに基づいて選択する。別の基準は、ＵＥ能力５７１である。ＵＥ能力は、ＵＥの制御能力、ＵＥのバッテリレベル、ＵＥの信号安定性などを含む。規則５５９は、同じサブスクリプションとなるように後継コントローラを選択する基準である。このケースでは、アプリケーションサーバは、失われたコントローラと同じサブスクリプションに属するＵＥ内から後継コントローラを選択するために、デフォルト規則５９０を参照することができる。
【００４０】
終了規則５５３は、コントローラの喪失後、セッションを終了するためのトリガイベントを決定する規則セットである。終了規則は、現在のセッションのためのタイムアウト５７５を設定することができ、コントローラによって消費されるバイト５７６を制限することができ、メディアのあるタイプ５７７（例えばビデオフロー５９６など）のみを終了することができ、コントローラが失われて以降に課金可能な最大金額５７８を設定することができる。
【００４１】
メディア管理規則５５４は、特に受動制御モードに対して使用される。アプリケーションサーバは、コントローラを代理して、これらの規則に基づいて制御決定を下すことができる。課金移転規則５５５は、課金を制御と一緒に移転するか、それとも制御から切り離して移転するかを決定する。制御移転から切り離される場合、プリファレンスは、誰に課金を移転するかを指定する明示的な規則５９７を与える。これらの規則は、後継コントローラ選択の規則に類似していることがあるが、コントローラが失われた場合、制御移転から切り離して実行する必要がある。
【００４２】
デフォルト規則５５６は、アプリケーションサーバに記憶され、コントローラプリファレンスが制御／課金移転のため特定の候補を与えない場合、またはコントローラプリファレンスがコントローラ要求に対して特定の回答を与えない場合に、バックアップ規則としての役割を果たす。例えば、コントローラプリファレンスは、後継コントローラは、同じサブスクリプションに属するＵＥの中から選択されるべきであることしか指定しない。その場合、アプリケーションサーバは、デフォルト規則５９０を使用して、ただ１つの候補を選択する。別の例は、メディアフローの１つの構成要素を変更するためのコントローラ要求であり、コントローラは、受動制御モードに移行する前に、この要求のための規則をメディア管理規則５５４において与えていない。このケースでは、アプリケーションサーバは、コントローラを代理して、要求を拒絶するために、デフォルト規則５９１を使用する。
【００４３】
図７は、提示されたソリューションの例示的な動作シーケンスを示している。図７は、コントローラが受動制御モードに移行する場合のソリューションを示している。このソリューションは、コントローラ６０１と、コントローラ６０２と、アプリケーションサーバ６０３と、リモートパーティ６０４とを含む。
【００４４】
ステップ６１０において、協調セッションが、プリファレンスを伴って確立される。アプリケーションサーバ６０３は、ステップ６１１にあるように、プリファレンスを処理する。ステップ６１２において、コントローラ６０１がメディアを追加することを要求した場合、アプリケーションサーバは、要求を了承し、ステップ６１３において、メディア追加を実行する。これらのステップの後、協調セッションは、コントローラからの制御（６１４）と、コントローラとリモートパーティの間のメディアフロー（６１５）とを用いて活動化される。
【００４５】
その後、ステップ６１６において、コントローラは、受動制御モードに移行することを要求する。アプリケーションサーバは、肯定応答を返し、ステップ６１７において、ユーザプリファレンスをロードする。プリファレンスのロードが成功した後、協調セッションは、受動制御モードに移行する（ステップ６２１）。受動制御モードにおいて、何らかの要求がコントローラから来た場合（６１９）、アプリケーションサーバ６０３は、プリファレンス内の制御規則を調べ（６２０）、決定を下し、その決定を実行する（６２１）。しばらくして、コントローラ６０１は、能動制御モードに復帰することを要求することができる（６２３）。このメッセージを受け取った時点で、アプリケーションサーバは、その受動制御機能６０５を非活動化し、通常モードに戻る必要がある（６２５）。
【００４６】
図８は、本ソリューションの別の動作シーケンスを示している。図８は、コントローラが、その喪失時にセッションを終了する基準を設定するソリューションを示している。このソリューションは、コントローラ６５１と、コントローラ６５２と、アプリケーションサーバ６５３と、リモートパーティ６５４とを含む。
【００４７】
セッションの開始時に、ステップ６６０から６６１において、プリファレンスが送られ、アプリケーションサーバにおいて処理される。このプリファレンスは、後継コントローラを選択するための規則を含んでいないが、コントローラが失われた場合に、セッションをいつ終了させるべきかについての基準を含む。例えば、プリファレンスは、コントローラ喪失の検出から開始すべきタイマを指定する。タイマが満了したとき、全セッションが解放される。
【００４８】
ステップ６６３において、アプリケーションサーバ（６５３）は、コントローラ喪失を検出し、受動制御機能３０５によって、セッション終了制御を自動的に開始する。アプリケーションサーバは、ステップ６６５にあるように、影響を受けるコントローラに信号を送り、ある時間の後にセッションが終了することを、それらに通知することができる。この信号は、セッションが強制的に解放される前に、コントローラが最も重要な会話を完了するのに役立つ。プリファレンスに示されるように終了イベントが発生したとき（６６６）、ステップ６６７および６６８において、全セッションが終了する。
【００４９】
図９は、コントローラが接続を失った場合に、コントローラが後継者を指名する、または後継者をどのように選択すべきかに関する基準を設定する、本発明の別の動作シーケンスを示している。このソリューションは、コントローラ７０１と、ＵＥ−１ ７０２およびＵＥ−２ ７０３と、アプリケーションサーバ７０４と、リモートパーティ７０５とを含む。ＵＥ−１およびＵＥ−２は、セッション内における他のコントローラとすることができ、またはコントローラとすることができる。
【００５０】
このソリューションでは、アプリケーションサーバは、ステップ７１０および７１１の後に、プリファレンスを獲得する。アプリケーションサーバ（７０４）が、ステップ７１２にあるように、コントローラ喪失を検出した場合、アプリケーションサーバは、ステップ７１３にあるように、プリファレンスをロードし、ステップ７１４において、指定された後継者または後継者選択基準を現在のステータスと照合する。
【００５１】
選択されたＵＥは、ステップ７１５にあるように、制御を引き継ぐ意思があるかどうかについて問い合わせを受ける。選択されたＵＥが要求を了承した場合、ステップ７２０にあるように、制御がこのＵＥに移転される。選択されたＵＥが要求を拒絶した場合、アクションが取られる。例えば、ステップ７３０において、全セッションが解放される。
【００５２】
図１０は、プリファレンスがＩＭＳ登録時または協調セッション確立時に設定されない、本ソリューションのまた別の動作シーケンスを示している。このソリューションは、コントローラ７５１と、ＵＥ−１ ７５２およびＵＥ−２ ７５３と、アプリケーションサーバ７５４と、リモートパーティ７５５とを含む。ＵＥ−１およびＵＥ−２は、セッション内における他のコントローラとすることができ、またはコントローラとすることができる。
【００５３】
このソリューションでは、アプリケーションサーバ（７５４）がコントローラ喪失を検出したとき、プリファレンスは、ステップ７６０において提供されていない。進行中のメディアフローを救うため、アプリケーションサーバは、ステップ７６２において、制御能力を有するＵＥに、制御を引き継ぐ意思を問い合わせる要求をブロードキャストする。（ステップ７６３にあるように）要求を了承した第１のＵＥが、新しいコントローラとして選択される。誰も制御を引き継ぐことを望まない場合、ある時間の後、セッションは解放される。
【００５４】
図１１は、セッションの前にコントローラによって設定されたプリファレンスが存在しない場合の、ソリューションの別の動作を示している。図１１は、コントローラの喪失によって影響を受ける端末に重点を置いている。このソリューションは、コントローラ−１ ８０１と、コントローラ−２ ８０２と、ＵＥ ８０３、アプリケーションサーバ８０４と、リモートパーティ８０５とを含む。コントローラ−１は、メディア−Ａを制御し、失われることになるコントローラであり、コントローラ−２は、異なるメディア（メディア−Ｂ）を制御する、セッション内の別のコントローラである。ＵＥ ８０３は、リモートパーティ８０５とともにメディア−Ａを有するコントローラである。
【００５５】
コントローラ−１ ８０１が失われたことを、アプリケーションサーバ（８０４）が検出した場合、ＵＥ ８０３においてメディア−Ａが終了するので、アプリケーションサーバは、課金移転についての問い合わせ８１４を、影響を受けるＵＥ ８０３に送る。ＵＥ ８０３が移転を了承した場合、８２０内のステップが行われ、ＵＥ ８０３は、リモートパーティ８０５とのメディアを継続する。ＵＥ ８０３が課金移転を拒絶した場合、メディアフローは、８３０内のステップのように、切断することができる。コントローラ−２ ８０２によって制御されるメディア−Ｂは、影響されない。
【技術分野】
【０００１】
本発明は、パケット交換通信ネットワークにおける電気通信の分野に関する。より詳細には、本発明は、ＩＰマルチメディアシステムにおけるセッション制御に関する。
【背景技術】
【０００２】
ますます多くのデバイスがネットワーク機能を獲得するようになったため、ユーザがこれらの複数のデバイスを管理する必要が生じている。そのような作業項目は、３ＧＰＰでは、協調セッション管理（ｃｏｌｌａｂｏｒａｔｉｖｅ ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）の範囲の中で扱われている。協調セッション管理では、ＩＭＳサービスに登録している多くのユーザデバイスは、異なるメディアフローを有するセッションにおいて、互いに協力することができる。協調セッションとは、複数のＵＥが含まれ、互いに協調する、マルチメディアセッションのことである。コントローラＵＥが、アプリケーションサーバと対話することによって、コントローラ上のメディアを管理する。コントローラからのいかなる要求も、アクションを起こす前に、コントローラによって認可されなければならない。通常、１つのメディアフローは、ただ１つのコントローラによって制御される。
【０００３】
協調セッションにおいて（特定のフローについて）単一コントローラ構成であることにより、ＵＥ故障、バッテリ消耗、カバレージ圏外のＵＥ、不安定な信号などの制御不能な理由でコントローラが失われた場合、問題がある。コントローラが自らを受動制御モード（ｐａｓｓｉｖｅ−ｃｏｎｔｒｏｌ ｍｏｄｅ）に移行させたい状況、または一時的に協調セッションから離脱したい状況もある。これらのケースは、コントローラが変化を起こすたびに中断されることをコントローラが望まない場合、または長い間にわたってコントローラがいかなる要求も申し込まない場合に生じることがある。ここで、受動制御モードとは、コントローラＵＥが自動制御モードにあることを選択すること、または制御を一時的にアプリケーションサーバに渡すことを意味する。すなわち、コントローラＵＥは、あるトリガシナリオにおいて決定を下す規則を設定することによって、またはアプリケーションサーバもしくはコントローラＵＥなどの他のノードに責任を移譲することによって、受動的であり続ける。
【０００４】
最新の３ＧＰＰ ＴＳ２３．２３７では、コントローラが失われた場合に、ＳＣＣ ＡＳが、協調セッションに参加しているすべてのアクセスレグ（Ａｃｃｅｓｓ Ｌｅｇ）を解放することが示されている。
【０００５】
この手法の問題は、コントローラは、何が起こったのかを知ることなく、セッションを終了するように常に強制され、コントローラは、ユーザが続行を望み、支払いをする意思がある場合でも、続行または再開することができないことである。
【０００６】
別の可能な手法は、コントローラが失われた場合に、ＳＣＣ ＡＳが、協調セッション制御を、協調セッションに含まれ、同じサブスクリプションに属する別のＵＥに移転できるようにすることである［非特許文献４］。
【０００７】
この方法は、この問題を解決する一歩となるが、後継コントローラをどのように選択すべきか、他のＵＥが異なるサブスクリプションに属する場合に何が起きるかを規定していない。明らかに、コントローラが受動制御モードに移行することを望む場合の問題を解決するために、何らかのより優れたソリューションが必要とされており、通信事業者が協調セッションサービスを展開する場合、それは不可避である。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】３ＧＰＰ ＴＳ ２３．２３７ ｖ９．２．０、「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ （ＩＭＳ） Ｓｅｒｖｉｃｅ Ｃｏｎｔｉｎｕｉｔｙ」
【非特許文献２】３ＧＰＰ ＴＳ ２４．２３７ ｖ９．０．０、「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ （ＩＭＳ） Ｓｅｒｖｉｃｅ Ｃｏｎｔｉｎｕｉｔｙ」
【非特許文献３】３ＧＰＰ ＴＲ ２３．８３８ ｖ９．０．０、「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ （ＩＭＳ） ｓｅｒｖｉｃｅ ｃｏｎｔｉｎｕｉｔｙ ｅｎｈａｎｃｅｍｅｎｔｓ； Ｓｅｒｖｉｃｅ， ｐｏｌｉｃｙ ａｎｄ ｉｎｔｅｒａｃｔｉｏｎ」
【非特許文献４】３ＧＰＰ ＴＳＧ ＳＡ ＷＧ２ Ｍｅｅｔｉｎｇ ＃７６、２００９年１１月１６〜２０日、Ｓａｎ Ｊｏｓｅ Ｄｅｌ Ｃａｂｏ、Ｍｅｘｉｃｏ ＴＤ Ｓ２−０９６７６７、「Ｒｅｑｕｉｒｅｍｅｎｔ ｏｆ Ｃｏｎｔｒｏｌ ｔｒａｎｓｆｅｒ ｕｐｏｎ ｌｏｓｔ ｏｆ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ」
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、上述の問題、短所、および不完全性に対処することである。特に、本発明は、コントローラが利用可能でない場合に、協調セッションの継続性をサポートするための方法を提供することを目的とする。
【００１０】
本発明の別の目的は、アプリケーションサーバと、リリース、サブスクリプション、および機能に制限を設けないＵＥとを含む、コントローラ喪失に耐性のある堅牢なシステムを提供することである。システムにおいて、協調セッションは、単一または複数のコントローラを用いて確立される。各コントローラは、あるメディアフローを制御する独自の責任を有する。すべての端末ＵＥは、互いに、またアプリケーションサーバと協力して、コントローラが事故で失われた場合、またはコントローラが離脱した場合に、セッション中断を回避する。
【課題を解決するための手段】
【００１１】
一態様では、制御プリファレンス情報（ｃｏｎｔｒｏｌ−ｐｒｅｆｅｒｅｎｃｅ ｉｎｆｏｒｍａｔｉｏｎ）が、アプリケーションサーバに送られる。コントローラが失われた場合、または受動モードに移行する場合、新しいコントローラを、リファレンスを参照することによって決定することができ、またはデフォルト規則によって決定することができる。その後のアクションが、制御を別のデバイスに移転することができ、別のデバイスは、制御および課金を引き継ぐ意思があるかどうかを尋ねられる。
【００１２】
別の態様では、プリファレンスは、１つまたは複数のリストを含む。これらのリストは、現在のコントローラが失われた場合に、後継コントローラを指定するために、後継者をどのように選択すべきかに関する規則を提供するために、メディア管理に制限を設けるために、およびセッション解放のためのトリガポイントを設定するために使用される。
【００１３】
また別の態様では、端末は、アプリケーションサーバに要求して、制御を受動制御モードに移行させることが可能である。受動制御中は、メディア解像度変更などの通常の決定は、セッション開始時またはＩＭＳ登録時に設定されたプリファレンス制御規則を通して、アプリケーションサーバによって自動的に行われる。アプリケーションサーバからの問い合わせを受け取る場合、端末は、問い合わせを処理し、それに応答する機能を有する。その機能は、問い合わせを理解できない場合であっても、依然として「不明」メッセージを用いて応答する。これらの追加機能は、セッション制御を、自動制御および緊急ケースに拡張する。
【００１４】
別の態様では、アプリケーションサーバは、異なるタイプのプリファレンスを識別し、将来の使用のためにそれを処理できる、プリファレンス処理機能を含む。アプリケーションサーバは、コントローラ喪失を検出するための、コントローラ喪失検出機能も有する。アプリケーションサーバは、コントローラがある期間応答しない場合にプリファレンスを参照する、制御移転決定機能をさらに有する。
【００１５】
別の態様では、制御は、セッションの認可とメディアフローの課金の両方に拡張される。コントローラは、制御するメディアフローの変更について決定を下す責任を負い、コントローラは、制御するメディアフローについて課金されるエンティティでもある。コントローラからのプリファレンスは、コントローラが失われた場合に、課金エンティティをどのように再割り当てすべきかを示している。制御移転および課金移転は、別々の決定であるが、コントローラおよびアプリケーションサーバは、プリファレンスおよび決定において、それらを一体化することを選択することができる。
【００１６】
これらのソリューションを用いることで、コントローラが離脱した場合に、セッションを継続できる可能性がより高まる。コントローラとＳＣＣ ＡＳの両方が、制御移転の決定に参加することができる。サブスクリプションは、もはや制限とはならない。
【図面の簡単な説明】
【００１７】
【図１】セッション制御能力を有する、または有さない、例えば１０１および１０５などのいくつかのＵＥ端末と、セッション端末を調整するアプリケーションサーバ（１０２）と、ＩＭＳシグナリングサポートを提供するＩＭＳコアネットワーク（１０３）と、ＵＥとのセッションを有するリモートパーティ（１０４）とから成る、全体的なシステムを示す図である。
【図２】協調セッションにおいて特にコントローラ（１０１）として機能する端末デバイスの構造の図である。
【図３】セッション全体を管理するアプリケーションサーバの構造の図である。
【図４】コントローラまたはコントローラである、協調セッションにおいて他のユーザ機器として機能する端末デバイス（１０５）の構造の図である。
【図５】コントローラが予告なしに失われた場合、またはコントローラが受動モードに移行する場合に、アプリケーションサーバがどのように制御移転の決定を下すかを示すフローチャート図である。
【図６】異なるタイプの規則がツリー上に示された、コントローラによって生成され、アプリケーションサーバ内に記憶されるプリファレンスの構造を示す図である。
【図７】ＵＥとアプリケーションサーバの間での信号交換を用いて、コントローラが受動制御モードに移行する場合の例示的な動作シーケンスを示す図である。
【図８】コントローラが失われた後、いつセッションを解放すべきかに関するコントローラ設定のプリファレンスを有する、コントローラ喪失ソリューションのための代替的な動作シーケンスを示す図である。
【図９】コントローラが後継者を指名する、または後継コントローラをどのように選択すべきかに関する設定プリファレンスを有する、コントローラ喪失ソリューションのための別の代替的な動作シーケンスを示す図である。
【図１０】アプリケーションサーバが、セッション内のＵＥに対してブロードキャストを行い、ＵＥの能力および制御を引き継ぐ意思について尋ねる、コントローラ喪失ソリューションのための異なる動作シーケンスを示す図である。
【図１１】アプリケーションサーバが、コントローラ喪失のせいでＵＥにおいて終了するメディアの課金を引き継ぐかどうかを影響を受けるＵＥに問い合わせる、コントローラ喪失ソリューションのための別の動作シーケンスを示す図である。
【発明を実施するための形態】
【００１８】
本発明の例示的な実施形態についての以下の詳細な説明では、本明細書の一部を形成し、例として示される添付の図面、本発明を実施できる特定の例示的な実施形態が参照される。各実施形態は、当業者が本発明を実施できるように、十分な詳細さで説明されるが、本発明の主旨または範囲から逸脱することなく、実施形態を利用することができ、他の変更を施すことができることを理解されたい。したがって、以下の詳細な説明は、限定的な意味で解釈されるべきではなく、本発明の範囲は、添付の特許請求の範囲のみによって定められる。以下の説明では、説明の目的で、本発明の完全な理解を提供するために、具体的な数、回数、構造、プロトコル、および他のパラメータが説明される。しかし、これらの具体的な細部を伴わなくても、本発明を実施できることは、当業者には明らかであろう。
【００１９】
図１は、協調セッションを制御するコントローラＵＥ １０１と、制御権をもたずにセッションに参加する通常のＵＥ １０５と、ＵＥとリモートパーティの間のセッションを調整するアプリケーションサーバ１０２と、セッションにＩＭＳシグナリングおよびルーティング機能を提供するＩＭＳコアネットワーク１０３と、ＵＥとのセッションを有するリモートパーティ１０４とから成る、本発明をサポートするシステムを示している。コントローラまたはコントローラであるすべてのＵＥは、標準的なＩＭＳ手順を通して、アプリケーションサーバと通信する。本発明では、コントローラからアプリケーションサーバへの通信１１０は、標準的な要素のほかに追加情報を有し、セッション制御のためのユーザプリファレンスを含み、通常のＵＥからアプリケーションサーバへの通信１１３は、標準的な要素のほかに追加情報を有し、ＵＥ能力パラメータを含む。コントローラＵＥ １０１だけが、制御プリファレンスを送ることを求められ、他のユーザ１０５は、能力パラメータを送るか、それとも送らないかを選択することができる。１０１からのユーザ制御プリファレンスは、協調／対話的セッションセットアップ時に、またはＩＭＳ登録時に送ることができる。制御プリファレンスは、アプリケーションサーバ１０２によって理解可能な任意のフォーマットを取ることができる。制御プリファレンスは、コントローラが予告したうえで離脱する場合に、どのように制御を実行すべきか、またコントローラが予告なしに接続を失った場合に、どのようにセッションを管理すべきかについて、アプリケーションサーバに命令するために使用される。ＵＥ能力パラメータは、アプリケーションサーバによって理解可能な任意のフォーマットで送ることができる。ＵＥ能力パラメータは、例えば、ＵＥの制御能力、バッテリレベル、ＩＭＳリリースバージョンなどを含む。この追加情報は、コントローラがセッションを離脱した場合、または接続を失った場合に、決定を下すために、アプリケーションサーバによって使用される。本発明では、アプリケーションサーバ１０２は、制御プリファレンスに基づいてセッション制御を引き継ぐ追加機能、およびセッションに属するＵＥへの制御移転を決定する追加機能を有する。しかし、アプリケーションサーバ１０２は、決してセッションについての課金を引き継ぐことはない。したがって、アプリケーションサーバは、認可においてはコントローラを代理するが、課金においては決してコントローラを代理せずに、セッションを制御する。課金は、ＵＥに割り当てるよう求められる。アプリケーションサーバとＩＭＳ ＣＮの間の接続１１１、およびＩＭＳ ＣＮとリモートパーティの間の接続１１２は、標準的なＩＭＳ手順を使用し、ＩＭＳにおいて定義された標準的な情報を伝送する。
【００２０】
図２は、制御機能を有する通信デバイスである。通信デバイスは、セッションのコントローラとしての機能を果たすことができる。ユーザ機器の従来の機能のほかに、通信デバイスは、プリファレンス生成対話のためのＧＵＩブロック２０１と、ＧＵＩに接続されたユーザプリファレンス生成器２０２と、通信デバイスがセッションのコントローラである場合に、伝送レイヤ機能２０５を介してプリファレンスを送るユーザプリファレンス伝送機能２０４と、受動制御モードに移行することを要求する信号を発信できる受動制御機能２０３も含む。プリファレンスは、１つまたは複数のリストを含む。これらのリストは、現在のコントローラが接続を失った場合に、後継コントローラを指定するために、後継者をどのように選択すべきかに関する規則を提供するために、メディア管理に制限を設けるために、およびセッション解放のためのトリガポイントを設定するために使用される。例えば、プリファレンスを使用して、「Ｓｅｓｓｉｏｎ Ｔｅｒｍｉｎａｔｉｏｎ： １０ｍｉｎ」ということを示すことができる。その場合、通信デバイスがセッションを離脱すると、セッションは、通信デバイスが離脱してから１０分後に解放される。別の例は、「Ａｄｄ ｍｅｄｉａ： Ｒｅｊｅｃｔ； Ｍｏｄｉｆｙ ｍｅｄｉａ： Ａｇｒｅｅ」などのメディア管理規則を含むことができる。コントローラがこのプリファレンスを残して離脱した場合、アプリケーションサーバは、コントローラからのすべてのメディア追加要求を拒絶し、すべてのメディア変更要求に合意する。
【００２１】
端末のための別の新しい機能は、端末自体を受動制御モードに移行させるための要求を、アプリケーションサーバに送ることである。受動制御中は、メディア解像度変更などの通常の決定は、セッション開始時もしくはＩＭＳ登録時に設定され、または任意のＩＭＳ手順を使用して更新されるプリファレンス制御規則を通して、アプリケーションサーバによって自動的に行われる。ユーザプリファレンスを生成するため、ユーザプリファレンス生成器２０２は、質問を準備し、ＧＵＩ ２０１を介してユーザに問い合わせる。質問に対するユーザの回答は、ユーザプリファレンス生成器２０２において記憶され、処理され、それによって、プリファレンスファイルが、アプリケーションサーバ１０２によって理解可能なフォーマットで生成される。このプリファレンスファイルが、例えば、記憶カード、インターネットを介したダウンロード、Ｂｌｕｅｔｏｏｔｈ（登録商標）を介した別の端末からの転送など、異なる手段を介して端末にロードできることは当業者には明らかである。
【００２２】
端末がコントローラとして登録されている場合、プリファレンスを送り出すために、ユーザプリファレンス伝送機能２０４がトリガされる。プリファレンスは、コントローラが接続を失った場合に、制御ハンドオーバ問題を解決することを目標としている。プリファレンスは、コントローラが意図的に受動制御モードに移行する場合に、自動制御を実行するための１組の規則も含むことができる。コントローラではない端末の場合、ユーザプリファレンス生成器２０２は、登録時にユーザプリファレンスを生成する手順をスキップすることができる。プリファレンスは、後の任意の時に、端末がコントローラになる前に、生成できることは当業者には明らかである。加えて、プリファレンスは、セッションに変更が発生した場合は、セッション中に更新することができる。
【００２３】
図３は、協調セッションを管理するアプリケーションサーバ１０２のための例示的な構造を示している。新しい機能が、アプリケーションサーバに導入される。アプリケーションサーバは、制御プリファレンスを他の登録情報からふるい分けるプリファレンス受け取り機能３０１と、受け取った制御プリファレンスを分析するプリファレンス処理機能３０３と、コントローラの利用可能性を定期的にチェックするコントローラ喪失検出機能３０２と、アプリケーションサーバ内に記憶されたデフォルト規則、またはプリファレンス処理機能３０３から渡された制御プリファレンスに基づいて、コントローラが含まれない場合に、制御（および／または課金）移転を決定する制御移転決定機能３０４と、コントローラが受動制御モードに移行する場合、またはコントローラが失われた後にセッション解放手順が活動化された場合に制御を行う受動制御機能３０５とを含む。
【００２４】
アプリケーションサーバが、セッション内の他のＵＥの能力パラメータを有さない場合、アプリケーションサーバは、そのような情報を決定するために、ＵＥに問い合わせを行う必要がある。ＵＥ問い合わせ機能３０６が、この目的を遂行する。十分な情報を獲得した後、制御移転決定機能３０４は、制御移転を実行するか、それともセッションを解放するかを決定する。
【００２５】
アプリケーションサーバによって制御を引き継ぐ必要がある場合、アプリケーションサーバは、ユーザプリファレンスに基づいて制御を行うために、受動制御機能３０５を活動化する。これらの機能を用いて、アプリケーションサーバは、コントローラが失われた場合、または離脱した場合に、別のＵＥを選択し、別のＵＥに制御を移転させることによって、セッションを救うことができ、または自ら制御を引き継ぐことさえできる、インテリジェントなエージェントとして動作する。プリファレンス処理機能３０３は、端末とアプリケーションサーバの間で合意された任意のフォーマットで書かれた制御プリファレンスを説明し、分類する責任を負う。例えば、プリファレンスは、ＸＭＬを用いて書くことができ、プリファレンスは、同じサブスクリプションに属する後継コントローラのみを選択できることを示す。処理の後、このプリファレンスは、制御移転決定機能３０４に渡される。コントローラ喪失検出機能３０２が、タイマまたは他のベアラモニタを通して、コントローラ喪失を検出した場合、制御移転決定機能３０４は、それまでのコントローラと同じサブスクリプションに属する端末のみを、後継コントローラであると見なす。失われたコントローラと同じサブスクリプションに属する端末ＵＥが存在しない場合、アプリケーションサーバは、それを、プリファレンスなしのケースとして扱うべきである。それを扱うために、そのケースのための本発明の他の動作シーケンスを利用することができる。
【００２６】
図４は、制御機能を有する、または有さない、通常の通信デバイスである端末デバイス４００についての例示的なアーキテクチャを示している。端末デバイスは、協調セッションにおいてコントローラまたはコントローラとして動作するが、接続を失う、または受動制御モードに移行する、ターゲットコントローラではない。通常のユーザ機器の従来の機能のほかに、端末デバイスは、アプリケーションサーバ１０２からの問い合わせを処理し、それに応答できる、追加機能ブロックも含む。本発明では、アプリケーションサーバは、端末の制御機能と、制御および課金を引き継ぐ意思について、端末に問い合わせることができる。問い合わせ受け取り機能４０１および問い合わせ処理機能４０２は、そのようなメッセージを受け取り、それらを処理するために使用される。処理された問い合わせは、アプリケーションサーバ１０２に返される応答を生成するために、問い合わせ応答機能４０３に渡される。
【００２７】
ＵＥ構成／ステータス記録機能４０４は、データベースのような機能を果たす。ＵＥ構成／ステータス記録機能は、ＵＥのパラメータおよびステータスを提供し、問い合わせ応答機能４０３がアプリケーションサーバへの応答を生成するのを支援する。
【００２８】
問い合わせを、問い合わせ処理機能４０２が理解できない場合、問い合わせ応答機能４０３は、問い合わせ処理機能が不明な問い合わせを受け取ったことを示す、アプリケーションサーバ１０２への応答を生成する。
【００２９】
２００、３００、４００の間で交換されるすべてのシグナリングメッセージは、例えば、ＴＣＰチャネルまたは再送機構を有するＵＤＰチャネルを介して、通常のＩＭＳ機構上でトランスポートすることができる。ユーザプリファレンスは、ＩＭＳ登録中にＳＩＰ信号と一緒に送られ、または協調セッション確立中に、もしくはＵＥがコントローラＵＥになったときに、別個のパケットで送られる。ユーザは、端末デバイス２００上のＧＵＩを介して、いくつのプリファレンスを生成すべきかを決定する。すべての生成されたプリファレンスは、コントローラＵＥからアプリケーションサーバ３００に送られる。
【００３０】
図５は、主要な管理および意思決定デバイスである、アプリケーションサーバ１０２のための例示的なロジックのフローチャートである。コントローラ喪失または受動制御問題に対するソリューションが、このフローチャートに要約されている。
【００３１】
図は、主要な２つのブランチから成る。一方は、アプリケーションサーバが制御を引き継ぐ必要がある状況である。他方は、アプリケーションサーバが制御を引き継ぐ必要はない。第２のケースは、２つのブランチにさらに分割される。一方は、コントローラプリファレンスが利用可能であり、決定を下すことが可能である。他方は、プリファレンスが利用可能ではなく、または現在の状況と対立するせいで、既存のプリファレンスを適用することができない。
【００３２】
アプリケーションサーバ１０２が、コントローラ喪失を検出した場合、またはコントローラが受動制御モードに移行することを示す信号を受け取った場合、アプリケーションサーバは、対応するユーザプリファレンスが利用可能であるかどうかをチェックするステップ５０２を実行する。プリファレンスが利用可能である場合、アプリケーションサーバは、ステップ５０３に進み、アプリケーションサーバが制御を引き継ぐ必要があるかどうかをチェックする。
【００３３】
アプリケーションサーバ１０２が制御を引き継ぐ必要がある、２つの状況がある。１つの状況では、コントローラが受動制御モードに移行し、コントローラ上で制御関連の質問を処理する代わりに、アプリケーションサーバに質問に回答するように要求する。他の状況では、コントローラが予告なしに接続を失い、アプリケーションサーバ１０２が、事前設定されたプリファレンスに従って、例えば、あるトリガの後でセッションを解放する、異なるコントローラを選択して制御を移転するなど、セッションを扱う責任を負う。
【００３４】
アプリケーションサーバが制御を引き継ぐ必要がない場合、アプリケーションサーバは、現在のセッションステータスパラメータをチェックするために、さらにステップ５０５に進む。ステップ５０６は、ユーザプリファレンスを現在のセッションステータスと照合するチェック手順である。現在のセッションステータスは、現在のセッションに関連するすべての情報を含む。例えば、セッションに含まれるＵＥのＩＤ、各ＵＥのサブスクリプション、各ＵＥにおけるメディア終了の数などである。プリファレンスとセッションステータスの照合は、双方からの文字列または値を比較することである。例えば、トムが後継者であることを、プリファレンスが示している場合、トムは、機能３０３によってトムのＵＥのＩＤに変換され、ステップ５０６は、このＩＤを、セッションに参加しているすべてのＵＥのＩＤと比較する。最大数のメディアフローを有するＵＥが制御を引き継ぐことを、プリファレンスが示している場合、ステップ５０６は、最大数のメディアフローを所有するＵＥが存在するかどうかをチェックする。プリファレンス基準を満たすＵＥがセッション内に存在する場合、現在のセッションステータスは、ユーザプリファレンスと一致すると言われる。
【００３５】
現在のセッションステータスがユーザプリファレンスと一致しない場合、意思決定手順は、プリファレンスが利用可能ではない場合のブランチである、ステップ５１１に向かう。不一致の一例は、以下のようなものである。ユーザプリファレンスは、ジョンが現在のコントローラの後継者であることを示している。しかし、コントローラが失われたとき、ジョンはすでにセッションを離脱している。この例は、セッション内で何かが変化した場合は常に、アプリケーションサーバが、制御プリファレンスを更新するためのトリガをコントローラＵＥに送ることができるならば、回避することができる。しかし、そのような種類のトリガがない場合は、不一致が発生することがある。
【００３６】
現在のセッションステータスとユーザプリファレンスの間で不一致が発生しない場合、ステップ５０７において、後継者が決定され、ステップ５０８において、選択された後継者は、新しいコントローラになることを了承するかどうかを尋ねられる。選択された端末（後継者）が、制御が可能であり、引き継ぎに合意した場合、制御は、選択された端末に移転されるが、選択された端末が、申入れを拒絶した場合、または制御を実行することが可能でない場合は、例えば、セッションを解放するなど、ステップ５１０において、他の動作が取られる。複数の端末がユーザプリファレンス基準を満たす場合、セッションを解放する前に、選択−問い合わせ−応答手順を繰り返すことができる。
【００３７】
プリファレンスなしに、コントローラが失われた場合、アプリケーションサーバ１０２は、制御を移転するとも、制御を引き継ぐとも決定することができない。ステップ５１２において、アプリケーションサーバは、影響を受けるユーザが自らのメディアフローの課金を引き継ぐ意思があるかどうかをチェックすることによって、影響を受けるセッションを救おうと試みることができるにすぎない。引き継ぐ意思がある場合は、ステップ５１３において、影響を受けるユーザに課金が移転されるが、引き継ぐ意思がない場合は、ステップ５１０において、制御とメディアの両方が解放される。影響を受けるユーザが協調セッションにおける最後のＵＥである場合は、課金移転後は、協調セッションはもはやないことに留意されたい。影響を受けるユーザは、通常のＩＭＳセッションに移行し、リモートパーティ１０４との自らのメディアフローを継続する。
【００３８】
図６は、プリファレンスの構造を示している。本発明におけるソリューションに基づいて、６組の規則が提示されている。後継コントローラの優先順位のリスト５５１は、サブスクリプション情報５６２、ユーザ名５６３、ＵＥ識別番号５６１など、排他的な同一性を使用して後継コントローラを指定する、１組の規則である。後継コントローラの優先順位のリストは、コントローラが失われた場合に、アプリケーションサーバが誰を最初に選択すべきか分かるように、これらの潜在的な後継者の優先順位も指定する。例えば、プリファレンスは、後継者の序列が、トム−マリー−ジョンであることを示す。その場合、アプリケーションサーバは、コントローラ喪失の場合、最初にトムに制御を引き継ぐように依頼する。トムが要求を拒絶した場合、マリーが依頼を受ける。そのようなプリファレンスは、ＵＥがセッションに参加する都度、またはセッションから離脱する都度、更新される。
【００３９】
コントローラが後継者を明示的に指定したくない場合、後継コントローラ選択規則５５２を使用して、アプリケーションサーバが後継者を選択するための基準を設定することができる。例えば、後継者は、コントローラがセッションに参加した順序５６８に従って選択される。アプリケーションサーバは、コントローラの参加順序を記録し、それに基づいて選択する。別の基準は、ＵＥ能力５７１である。ＵＥ能力は、ＵＥの制御能力、ＵＥのバッテリレベル、ＵＥの信号安定性などを含む。規則５５９は、同じサブスクリプションとなるように後継コントローラを選択する基準である。このケースでは、アプリケーションサーバは、失われたコントローラと同じサブスクリプションに属するＵＥ内から後継コントローラを選択するために、デフォルト規則５９０を参照することができる。
【００４０】
終了規則５５３は、コントローラの喪失後、セッションを終了するためのトリガイベントを決定する規則セットである。終了規則は、現在のセッションのためのタイムアウト５７５を設定することができ、コントローラによって消費されるバイト５７６を制限することができ、メディアのあるタイプ５７７（例えばビデオフロー５９６など）のみを終了することができ、コントローラが失われて以降に課金可能な最大金額５７８を設定することができる。
【００４１】
メディア管理規則５５４は、特に受動制御モードに対して使用される。アプリケーションサーバは、コントローラを代理して、これらの規則に基づいて制御決定を下すことができる。課金移転規則５５５は、課金を制御と一緒に移転するか、それとも制御から切り離して移転するかを決定する。制御移転から切り離される場合、プリファレンスは、誰に課金を移転するかを指定する明示的な規則５９７を与える。これらの規則は、後継コントローラ選択の規則に類似していることがあるが、コントローラが失われた場合、制御移転から切り離して実行する必要がある。
【００４２】
デフォルト規則５５６は、アプリケーションサーバに記憶され、コントローラプリファレンスが制御／課金移転のため特定の候補を与えない場合、またはコントローラプリファレンスがコントローラ要求に対して特定の回答を与えない場合に、バックアップ規則としての役割を果たす。例えば、コントローラプリファレンスは、後継コントローラは、同じサブスクリプションに属するＵＥの中から選択されるべきであることしか指定しない。その場合、アプリケーションサーバは、デフォルト規則５９０を使用して、ただ１つの候補を選択する。別の例は、メディアフローの１つの構成要素を変更するためのコントローラ要求であり、コントローラは、受動制御モードに移行する前に、この要求のための規則をメディア管理規則５５４において与えていない。このケースでは、アプリケーションサーバは、コントローラを代理して、要求を拒絶するために、デフォルト規則５９１を使用する。
【００４３】
図７は、提示されたソリューションの例示的な動作シーケンスを示している。図７は、コントローラが受動制御モードに移行する場合のソリューションを示している。このソリューションは、コントローラ６０１と、コントローラ６０２と、アプリケーションサーバ６０３と、リモートパーティ６０４とを含む。
【００４４】
ステップ６１０において、協調セッションが、プリファレンスを伴って確立される。アプリケーションサーバ６０３は、ステップ６１１にあるように、プリファレンスを処理する。ステップ６１２において、コントローラ６０１がメディアを追加することを要求した場合、アプリケーションサーバは、要求を了承し、ステップ６１３において、メディア追加を実行する。これらのステップの後、協調セッションは、コントローラからの制御（６１４）と、コントローラとリモートパーティの間のメディアフロー（６１５）とを用いて活動化される。
【００４５】
その後、ステップ６１６において、コントローラは、受動制御モードに移行することを要求する。アプリケーションサーバは、肯定応答を返し、ステップ６１７において、ユーザプリファレンスをロードする。プリファレンスのロードが成功した後、協調セッションは、受動制御モードに移行する（ステップ６２１）。受動制御モードにおいて、何らかの要求がコントローラから来た場合（６１９）、アプリケーションサーバ６０３は、プリファレンス内の制御規則を調べ（６２０）、決定を下し、その決定を実行する（６２１）。しばらくして、コントローラ６０１は、能動制御モードに復帰することを要求することができる（６２３）。このメッセージを受け取った時点で、アプリケーションサーバは、その受動制御機能６０５を非活動化し、通常モードに戻る必要がある（６２５）。
【００４６】
図８は、本ソリューションの別の動作シーケンスを示している。図８は、コントローラが、その喪失時にセッションを終了する基準を設定するソリューションを示している。このソリューションは、コントローラ６５１と、コントローラ６５２と、アプリケーションサーバ６５３と、リモートパーティ６５４とを含む。
【００４７】
セッションの開始時に、ステップ６６０から６６１において、プリファレンスが送られ、アプリケーションサーバにおいて処理される。このプリファレンスは、後継コントローラを選択するための規則を含んでいないが、コントローラが失われた場合に、セッションをいつ終了させるべきかについての基準を含む。例えば、プリファレンスは、コントローラ喪失の検出から開始すべきタイマを指定する。タイマが満了したとき、全セッションが解放される。
【００４８】
ステップ６６３において、アプリケーションサーバ（６５３）は、コントローラ喪失を検出し、受動制御機能３０５によって、セッション終了制御を自動的に開始する。アプリケーションサーバは、ステップ６６５にあるように、影響を受けるコントローラに信号を送り、ある時間の後にセッションが終了することを、それらに通知することができる。この信号は、セッションが強制的に解放される前に、コントローラが最も重要な会話を完了するのに役立つ。プリファレンスに示されるように終了イベントが発生したとき（６６６）、ステップ６６７および６６８において、全セッションが終了する。
【００４９】
図９は、コントローラが接続を失った場合に、コントローラが後継者を指名する、または後継者をどのように選択すべきかに関する基準を設定する、本発明の別の動作シーケンスを示している。このソリューションは、コントローラ７０１と、ＵＥ−１ ７０２およびＵＥ−２ ７０３と、アプリケーションサーバ７０４と、リモートパーティ７０５とを含む。ＵＥ−１およびＵＥ−２は、セッション内における他のコントローラとすることができ、またはコントローラとすることができる。
【００５０】
このソリューションでは、アプリケーションサーバは、ステップ７１０および７１１の後に、プリファレンスを獲得する。アプリケーションサーバ（７０４）が、ステップ７１２にあるように、コントローラ喪失を検出した場合、アプリケーションサーバは、ステップ７１３にあるように、プリファレンスをロードし、ステップ７１４において、指定された後継者または後継者選択基準を現在のステータスと照合する。
【００５１】
選択されたＵＥは、ステップ７１５にあるように、制御を引き継ぐ意思があるかどうかについて問い合わせを受ける。選択されたＵＥが要求を了承した場合、ステップ７２０にあるように、制御がこのＵＥに移転される。選択されたＵＥが要求を拒絶した場合、アクションが取られる。例えば、ステップ７３０において、全セッションが解放される。
【００５２】
図１０は、プリファレンスがＩＭＳ登録時または協調セッション確立時に設定されない、本ソリューションのまた別の動作シーケンスを示している。このソリューションは、コントローラ７５１と、ＵＥ−１ ７５２およびＵＥ−２ ７５３と、アプリケーションサーバ７５４と、リモートパーティ７５５とを含む。ＵＥ−１およびＵＥ−２は、セッション内における他のコントローラとすることができ、またはコントローラとすることができる。
【００５３】
このソリューションでは、アプリケーションサーバ（７５４）がコントローラ喪失を検出したとき、プリファレンスは、ステップ７６０において提供されていない。進行中のメディアフローを救うため、アプリケーションサーバは、ステップ７６２において、制御能力を有するＵＥに、制御を引き継ぐ意思を問い合わせる要求をブロードキャストする。（ステップ７６３にあるように）要求を了承した第１のＵＥが、新しいコントローラとして選択される。誰も制御を引き継ぐことを望まない場合、ある時間の後、セッションは解放される。
【００５４】
図１１は、セッションの前にコントローラによって設定されたプリファレンスが存在しない場合の、ソリューションの別の動作を示している。図１１は、コントローラの喪失によって影響を受ける端末に重点を置いている。このソリューションは、コントローラ−１ ８０１と、コントローラ−２ ８０２と、ＵＥ ８０３、アプリケーションサーバ８０４と、リモートパーティ８０５とを含む。コントローラ−１は、メディア−Ａを制御し、失われることになるコントローラであり、コントローラ−２は、異なるメディア（メディア−Ｂ）を制御する、セッション内の別のコントローラである。ＵＥ ８０３は、リモートパーティ８０５とともにメディア−Ａを有するコントローラである。
【００５５】
コントローラ−１ ８０１が失われたことを、アプリケーションサーバ（８０４）が検出した場合、ＵＥ ８０３においてメディア−Ａが終了するので、アプリケーションサーバは、課金移転についての問い合わせ８１４を、影響を受けるＵＥ ８０３に送る。ＵＥ ８０３が移転を了承した場合、８２０内のステップが行われ、ＵＥ ８０３は、リモートパーティ８０５とのメディアを継続する。ＵＥ ８０３が課金移転を拒絶した場合、メディアフローは、８３０内のステップのように、切断することができる。コントローラ−２ ８０２によって制御されるメディア−Ｂは、影響されない。
【特許請求の範囲】
【請求項１】
コントローラがセッション内に常に含まれるわけではない特殊なケースにおいて、アプリケーションサーバが制御管理に関する決定を下すための方法であって、
特殊ケースの制御管理プリファレンスとして規則を送るステップと、
あるトリガポイントにおいて、規則に基づいて、制御／課金を移転、維持、または解放することを決定するステップと、
プリファレンス規則およびＵＥ機能に基づいて、必要な場合は、制御および／または課金を移転するのに適切なエンティティを選択するステップと
を含む方法。
【請求項２】
前記特殊なケースが、制御不能な理由でコントローラが失われることを意味する、請求項１に記載の方法。
【請求項３】
前記特殊なケースが、コントローラが協調セッションの制御に能動的に係わることを望まないことでもあり得る、請求項１に記載の方法。
【請求項４】
前記プリファレンスが、登録パケットと一緒に、または登録パケットとは別に送られる、請求項１に記載の方法。
【請求項５】
前記プリファレンスが、以下の情報の、すなわち、潜在的な後継者のリスト、前記後継者を選択するための１組の規則、デフォルト制御決定を下すための１組の規則、コントローラの喪失後にセッション解放をトリガする１組のイベントのすべてまたは一部を含む、請求項１に記載の方法。
【請求項６】
前記プリファレンス規則が、ＩＭＳサービスの登録時、ＵＥ間移転サービスの登録時、またはセッション中のいずれかに送られる、請求項１に記載の方法。
【請求項７】
前記プリファレンス規則が、マスタアプリケーションサーバまたは任意の同等のエージェントに送られる、請求項１に記載の方法。
【請求項８】
前記プリファレンスが提供されない場合に、デフォルト規則が使用される、請求項１に記載の方法。
【請求項９】
前記デフォルト規則が、アプリケーションサーバにおいて記憶され、どのセッション内に含まれるどのＵＥによっても変更可能ではない、請求項８に記載の方法。
【請求項１０】
前記コントローラによって提供されたプリファレンスが適用可能ではない場合、または十分ではない場合に、デフォルト規則が使用される、請求項１に記載の方法。
【請求項１１】
１つのトリガポイントが、前記現在のコントローラが予告なしにセッションを離脱したときである、請求項１に記載の方法。
【請求項１２】
別のトリガポイントが、前記現在のコントローラが、セッション制御に一定の期間係わる意思のないことを示す信号を送ったときである、請求項１に記載の方法。
【請求項１３】
前記トリガポイントが、終了パラメータ値が、規則によって設定された終了基準に一致したときであることもできる、請求項１に記載の方法。
【請求項１４】
前記終了基準が、コントローラの喪失後、どれだけの時間にわたってセッションを継続すべきかを決定することであって、それが、ユーザプリファレンスによって設定される、請求項１３に記載の方法。
【請求項１５】
適切なエンティティが、失われたコントローラと同じ協調セッション内のＵＥ、または前記アプリケーションサーバ自体である、請求項１に記載の方法。
【請求項１６】
ＵＥの前記機能が、ＵＥがセッションに参加したとき、またはセッション中に制御移転決定を下すことが必要になったときに、アプリケーションサーバによって獲得される、請求項１に記載の方法。
【請求項１７】
決定を下すためにＵＥの機能が必要な場合、アプリケーションサーバが、ＵＥの機能を前記ＵＥに明示的に要求する必要がある、請求項１６に記載の方法。
【請求項１８】
前記ＵＥ機能は、制御機能、電力機能、信号安定性または処理機能を含む、請求項１に記載の方法。
【請求項１９】
コントローラがセッション内に常に含まれるわけではない場合に、協調セッションの制御割り当てを決定する、協調セッションのためのシステムであって、
前記プリファレンスを準備し、前記協調セッションを管理するマスタアプリケーションサーバまたは同等のエージェントにプリファレンスを送ることができる端末と、
セッションを制御し、プリファレンス規則に基づいて制御および／または課金を別のＵＥに移転することができるアプリケーションサーバと、
前記アプリケーションサーバからの問い合わせを処理し、それに応答することができる非コントローラ端末と
を備えるシステム。
【請求項２０】
前記プリファレンスを準備し、それを送る前記端末が、セッション内のコントローラになろうとしているＵＥである、請求項１９に記載のシステム。
【請求項２１】
前記プリファレンスを準備し、それを送ることができる前記端末が、プリファレンス生成器機能と、プリファレンス送信機能と、受動制御機能と、ユーザ干渉機能とを含む、請求項１９に記載のシステム。
【請求項２２】
前記アプリケーションサーバが、コントローラ喪失検出機能と、プリファレンス処理機能と、コントローラ移転決定機能と、受動制御機能とをさらに含む、請求項１９に記載のシステム。
【請求項２３】
前記プリファレンス処理機能が、コントローラからの規則を処理し、それを分類する、請求項２２に記載のシステム。
【請求項２４】
前記制御移転決定機能が、ＵＥ問い合わせ機能と、後継コントローラ選択機能とをさらに備える、請求項２２に記載のシステム。
【請求項２５】
前記ＵＥ問い合わせ機能が、ターゲットＵＥに、その機能と、制御を引き継ぐ意思とを尋ねる、請求項２４に記載のシステム。
【請求項２６】
前記受動制御機能が、対応する受動コントローラからのプリファレンスと、マスタアプリケーションサーバデフォルト規則とに基づいて、制御決定を実行する、請求項２２に記載のシステム。
【請求項２７】
前記コントローラ移転決定機能が、ＵＥ機能を問い合わせることなく、ＵＥを選択し、コントローラ移転を試みることができる、請求項２２に記載のシステム。
【請求項２８】
前記コントローラ移転決定機能が、課金移転決定を下すことにも責任を負う、請求項２２に記載のシステム。
【請求項２９】
前記非コントローラ端末が、問い合わせ処理機能と、問い合わせ応答機能とをさらに含む、請求項１９に記載のシステム。
【請求項３０】
前記問い合わせ処理機能が、前記マスタアプリケーションサーバからの問い合わせを処理する、請求項２９に記載のシステム。
【請求項３１】
前記問い合わせ応答機能が、不明な問い合わせであっても、問い合わせに対する回答を取得し、前記マスタアプリケーションサーバに送り返す、請求項２９に記載のシステム。
【請求項１】
コントローラがセッション内に常に含まれるわけではない特殊なケースにおいて、アプリケーションサーバが制御管理に関する決定を下すための方法であって、
特殊ケースの制御管理プリファレンスとして規則を送るステップと、
あるトリガポイントにおいて、規則に基づいて、制御／課金を移転、維持、または解放することを決定するステップと、
プリファレンス規則およびＵＥ機能に基づいて、必要な場合は、制御および／または課金を移転するのに適切なエンティティを選択するステップと
を含む方法。
【請求項２】
前記特殊なケースが、制御不能な理由でコントローラが失われることを意味する、請求項１に記載の方法。
【請求項３】
前記特殊なケースが、コントローラが協調セッションの制御に能動的に係わることを望まないことでもあり得る、請求項１に記載の方法。
【請求項４】
前記プリファレンスが、登録パケットと一緒に、または登録パケットとは別に送られる、請求項１に記載の方法。
【請求項５】
前記プリファレンスが、以下の情報の、すなわち、潜在的な後継者のリスト、前記後継者を選択するための１組の規則、デフォルト制御決定を下すための１組の規則、コントローラの喪失後にセッション解放をトリガする１組のイベントのすべてまたは一部を含む、請求項１に記載の方法。
【請求項６】
前記プリファレンス規則が、ＩＭＳサービスの登録時、ＵＥ間移転サービスの登録時、またはセッション中のいずれかに送られる、請求項１に記載の方法。
【請求項７】
前記プリファレンス規則が、マスタアプリケーションサーバまたは任意の同等のエージェントに送られる、請求項１に記載の方法。
【請求項８】
前記プリファレンスが提供されない場合に、デフォルト規則が使用される、請求項１に記載の方法。
【請求項９】
前記デフォルト規則が、アプリケーションサーバにおいて記憶され、どのセッション内に含まれるどのＵＥによっても変更可能ではない、請求項８に記載の方法。
【請求項１０】
前記コントローラによって提供されたプリファレンスが適用可能ではない場合、または十分ではない場合に、デフォルト規則が使用される、請求項１に記載の方法。
【請求項１１】
１つのトリガポイントが、前記現在のコントローラが予告なしにセッションを離脱したときである、請求項１に記載の方法。
【請求項１２】
別のトリガポイントが、前記現在のコントローラが、セッション制御に一定の期間係わる意思のないことを示す信号を送ったときである、請求項１に記載の方法。
【請求項１３】
前記トリガポイントが、終了パラメータ値が、規則によって設定された終了基準に一致したときであることもできる、請求項１に記載の方法。
【請求項１４】
前記終了基準が、コントローラの喪失後、どれだけの時間にわたってセッションを継続すべきかを決定することであって、それが、ユーザプリファレンスによって設定される、請求項１３に記載の方法。
【請求項１５】
適切なエンティティが、失われたコントローラと同じ協調セッション内のＵＥ、または前記アプリケーションサーバ自体である、請求項１に記載の方法。
【請求項１６】
ＵＥの前記機能が、ＵＥがセッションに参加したとき、またはセッション中に制御移転決定を下すことが必要になったときに、アプリケーションサーバによって獲得される、請求項１に記載の方法。
【請求項１７】
決定を下すためにＵＥの機能が必要な場合、アプリケーションサーバが、ＵＥの機能を前記ＵＥに明示的に要求する必要がある、請求項１６に記載の方法。
【請求項１８】
前記ＵＥ機能は、制御機能、電力機能、信号安定性または処理機能を含む、請求項１に記載の方法。
【請求項１９】
コントローラがセッション内に常に含まれるわけではない場合に、協調セッションの制御割り当てを決定する、協調セッションのためのシステムであって、
前記プリファレンスを準備し、前記協調セッションを管理するマスタアプリケーションサーバまたは同等のエージェントにプリファレンスを送ることができる端末と、
セッションを制御し、プリファレンス規則に基づいて制御および／または課金を別のＵＥに移転することができるアプリケーションサーバと、
前記アプリケーションサーバからの問い合わせを処理し、それに応答することができる非コントローラ端末と
を備えるシステム。
【請求項２０】
前記プリファレンスを準備し、それを送る前記端末が、セッション内のコントローラになろうとしているＵＥである、請求項１９に記載のシステム。
【請求項２１】
前記プリファレンスを準備し、それを送ることができる前記端末が、プリファレンス生成器機能と、プリファレンス送信機能と、受動制御機能と、ユーザ干渉機能とを含む、請求項１９に記載のシステム。
【請求項２２】
前記アプリケーションサーバが、コントローラ喪失検出機能と、プリファレンス処理機能と、コントローラ移転決定機能と、受動制御機能とをさらに含む、請求項１９に記載のシステム。
【請求項２３】
前記プリファレンス処理機能が、コントローラからの規則を処理し、それを分類する、請求項２２に記載のシステム。
【請求項２４】
前記制御移転決定機能が、ＵＥ問い合わせ機能と、後継コントローラ選択機能とをさらに備える、請求項２２に記載のシステム。
【請求項２５】
前記ＵＥ問い合わせ機能が、ターゲットＵＥに、その機能と、制御を引き継ぐ意思とを尋ねる、請求項２４に記載のシステム。
【請求項２６】
前記受動制御機能が、対応する受動コントローラからのプリファレンスと、マスタアプリケーションサーバデフォルト規則とに基づいて、制御決定を実行する、請求項２２に記載のシステム。
【請求項２７】
前記コントローラ移転決定機能が、ＵＥ機能を問い合わせることなく、ＵＥを選択し、コントローラ移転を試みることができる、請求項２２に記載のシステム。
【請求項２８】
前記コントローラ移転決定機能が、課金移転決定を下すことにも責任を負う、請求項２２に記載のシステム。
【請求項２９】
前記非コントローラ端末が、問い合わせ処理機能と、問い合わせ応答機能とをさらに含む、請求項１９に記載のシステム。
【請求項３０】
前記問い合わせ処理機能が、前記マスタアプリケーションサーバからの問い合わせを処理する、請求項２９に記載のシステム。
【請求項３１】
前記問い合わせ応答機能が、不明な問い合わせであっても、問い合わせに対する回答を取得し、前記マスタアプリケーションサーバに送り返す、請求項２９に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１３−５２００３３（Ｐ２０１３−５２００３３Ａ）
【公表日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１２−５３３４００（Ｐ２０１２−５３３４００）
【出願日】平成２２年２月１０日（２０１０．２．１０）
【国際出願番号】ＰＣＴ／ＪＰ２０１０／０００８３９
【国際公開番号】ＷＯ２０１１／０９９０６８
【国際公開日】平成２３年８月１８日（２０１１．８．１８）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公表日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２２年２月１０日（２０１０．２．１０）
【国際出願番号】ＰＣＴ／ＪＰ２０１０／０００８３９
【国際公開番号】ＷＯ２０１１／０９９０６８
【国際公開日】平成２３年８月１８日（２０１１．８．１８）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]