特許 5832446 既存のコールにＳＩＰ通信デバイスを参加させるための方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5832446

(24)【登録日】2015年11月6日

(45)【発行日】2015年12月16日

(54)【発明の名称】既存のコールにＳＩＰ通信デバイスを参加させるための方法

(51)【国際特許分類】

   H04M 3/56 20060101AFI20151126BHJP

   H04N 7/15 20060101ALI20151126BHJP

【ＦＩ】

   H04M3/56 A

   H04N7/15 610

【請求項の数】10

【全頁数】17

(21)【出願番号】特願2012-543131(P2012-543131)

(86)(22)【出願日】2010年11月17日

(65)【公表番号】特表2013-513334(P2013-513334A)

(43)【公表日】2013年4月18日

(86)【国際出願番号】US2010056941

(87)【国際公開番号】WO2011071665

(87)【国際公開日】20110616

【審査請求日】2012年8月6日

【審判番号】不服2015-3324(P2015-3324/J1)

【審判請求日】2015年2月23日

(31)【優先権主張番号】12/654,019

(32)【優先日】2009年12月8日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】100094112

【弁理士】

【氏名又は名称】岡部 讓

(74)【代理人】

【識別番号】100106183

【弁理士】

【氏名又は名称】吉澤 弘司

(72)【発明者】

【氏名】テヴォニアン，グレゴリー，ビー．

【合議体】

【審判長】 大塚 良平

【審判官】 山中 実

【審判官】 山本 章裕

(56)【参考文献】

【文献】 特開２００１−３５９１７４（ＪＰ，Ａ）

【文献】 特開２００７−１５８７３７（ＪＰ，Ａ）

【文献】 特開２００５−２０２８６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

H04M 3/56, H04M 3/42, H04N 7/15

(57)【特許請求の範囲】

【請求項1】

サーバにおいて、コールを行っている通信デバイスからの着信コールを受信するステップ（Ｓ１００）と、
前記サーバによって、外部の通信デバイスにアクセスするために該サーバを経由する少なくとも二つの通信デバイスを含む、関連する通信デバイスの組を決定するステップと、
前記サーバによって、前記関連する通信デバイスの組に、前記着信コールがある旨を通知するステップと、
前記サーバによって、前記コールを行っている通信デバイスと、前記関連する通信デバイスの組の中の少なくとも１つの関連する通信デバイスとの間で、接続を確立するステップ（Ｓ３００）と、
前記サーバによって、前記関連する通信デバイスの組の中の各々の通信デバイスに関する固有の識別子を判定するステップと、
前記関連する通信デバイスの組の中の各々の通信デバイスの前記固有の識別子に基づき、前記サーバによって、前記接続について、前記関連する通信デバイスの組の中の各々の通信デバイスに通知するステップ（Ｓ４００）と、
少なくとも１つの接続されていなかった通信デバイスがアクティブにされるのに応じて、前記サーバによって、会議プロシージャを実行するステップ（Ｓ５００）であり、該実行するステップは、多方向会議接続である新しい接続を確立することにより、並びに、前記コールを行っている通信デバイス、前記少なくとも１つの関連する通信デバイス、及び前記少なくとも１つの接続されていなかった通信デバイスの各々を、前記多方向会議接続に招待することにより、実行される、実行するステップと、
を備える、通知方法。

【請求項2】

前記確立するステップは、
前記少なくとも１つの関連する通信デバイスからの応答確認を受信するステップと、
前記コールを行っている通信デバイスが、前記少なくとも１つの関連する通信デバイスとの前記接続を確立するように、前記応答確認を前記コールを行っている通信デバイスに対して転送するステップと
を含む、請求項１に記載の方法。

【請求項3】

前記通知するステップは、
コール通知を前記少なくとも１つの接続されていなかった通信デバイスに対して送信するステップと、
前記通知の肯定応答を受信するステップと
を含み、前記コール通知は、前記少なくとも１つの接続されていなかった通信デバイスに、共用の回線が現在前記少なくとも１つの関連する通信デバイスに割り付けられていることを通知する、請求項１に記載の方法。

【請求項4】

前記実行するステップは、
前記少なくとも１つの接続されていなかった通信デバイスがアクティブにされることを示す参加コール要求を前記少なくとも１つの接続されていなかった通信デバイスから受信するステップと、
前記少なくとも１つの接続されていなかった通信デバイスと、前記少なくとも１つの関連する通信デバイスと、前記コールを行っている通信デバイスとを前記参加コール要求を受信するステップに応じて会議コールに参加させるステップと
を含む、請求項１に記載の方法。

【請求項5】

前記参加させるステップは、
メディア・リソース機能に対して、前記参加コール要求を受信するとすぐに、前記メディア・リソース機能が、前記少なくとも１つの接続されていなかった通信デバイスを前記会議コールに追加するように、前記少なくとも１つの接続されていなかった通信デバイスに対応する識別情報を有する第１の招待を送信するステップと、
前記メディア・リソース機能が、前記少なくとも１つの関連する通信デバイスを前記会議コールに追加するように、前記少なくとも１つの関連する通信デバイスに対応する識別情報を有する第２の招待を送信するステップと、
前記メディア・リソース機能が、前記コールを行っている通信デバイスを前記会議コールに追加するように、前記コールを行っている通信デバイスに対応する識別情報を有する第３の招待を送信するステップと、
を含む、請求項４に記載の方法。

【請求項6】

前記サーバによって、前記コールを行っている通信デバイスと、前記少なくとも１つの関連する通信デバイスと、前記少なくとも１つの接続されていなかった通信デバイスとのうちの少なくとも１つについての前記多方向会議接続を終了させるステップ、
をさらに備える、請求項５に記載の方法。

【請求項7】

前記終了させるステップは、
前記コールを行っている通信デバイスと、前記少なくとも１つの関連する通信デバイスと、前記少なくとも１つの接続されていなかった通信デバイスとの間の会議コールを終わらせるステップと、
アイドル通知を関連する通信デバイスの組のそれぞれに対して送信するステップと
を含む、請求項６に記載の方法。

【請求項8】

前記アイドル通知は、共用の回線が現在では使用可能であることを関連する通信デバイスの前記組に通知する、請求項７に記載の方法。

【請求項9】

アプリケーション・サーバ（１１５）を備える通知装置であって、該アプリケーション・サーバが、
コールを行っている通信デバイスからの着信コールを受信し、
外部の通信デバイスにアクセスするために前記アプリケーション・サーバを経由する少なくとも二つの通信デバイスを含む、関連する通信デバイスの組を決定し、
前記関連する通信デバイスの組に、前記着信コールがある旨を通知し、
前記コールを行っている通信デバイスと、前記関連する通信デバイスの組の中の少なくとも１つの関連する通信デバイスとの間で接続を確立し、
前記関連する通信デバイスの組の中の各々の通信デバイスに関する固有の識別子を判定し、
少なくとも１つの接続されていなかった通信デバイスの前記固有の識別子に基づき、前記接続について、前記関連する通信デバイスの組の中の前記少なくとも１つの接続されていなかった通信デバイスに通知し、
前記少なくとも１つの接続されていなかった通信デバイスがアクティブにされるのに応じて、会議プロシージャを実行し、該会議プロシージャは、多方向会議接続である新しい接続を確立することにより、並びに、前記コールを行っている通信デバイス、前記少なくとも１つの関連する通信デバイス、及び前記少なくとも１つの接続されていなかった通信デバイスの各々を、前記多方向会議接続に招待することにより、実行され、
共用の回線が使用可能であるときに、アイドル通知を関連する通信デバイスの前記組のそれぞれに対して送信する、
ように構成された、通知装置。

【請求項10】

前記コールを行っている通信デバイスと、前記少なくとも１つの関連する通信デバイスと、前記少なくとも１つの接続されていなかった通信デバイスとを含む会議コールを確立する際に、前記アプリケーション・サーバと対話するように構成されたメディア・リソース機能（１１３）
をさらに備える、請求項９に記載の通知装置。

【発明の詳細な説明】

【背景技術】

【0001】

本発明は、既存のコールにＳＩＰ通信デバイスを参加させるための方法に関する。

【技術分野】

【0002】

従来のインターネット・プロトコル・マルチメディア・サブシステム（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）（ＩＭＳ）ネットワークは、インターネット・プロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）（ＩＰ）サービスを配信するためのアーキテクチャ・フレームワーク（ａｒｃｈｉｔｅｃｔｕｒａｌ ｆｒａｍｅｗｏｒｋ）である。従来のＩＭＳネットワークは、シグナリング・プロトコル（ｓｉｇｎａｌｉｎｇ ｐｒｏｔｏｃｏｌ）を実装して、様々な形態の通信を確立し、修正し、かつ／または終了することができる。１タイプのシグナリング・プロトコルは、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＳＩＰ）とすることができる。

【0003】

従来のＩＭＳ／ＳＩＰネットワークにおいては、１組のユーザ装置（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔｓ）（ＵＥ）は、ＳＩＰを使用し、また共用の電話番号を有することができる。共用の電話番号を有する従来のＵＥの組のうちのそれぞれを区別するために、従来のＵＥの組は、登録プロシージャに着手することもできる。登録プロシージャにより、各ＵＥは、固有の連絡アドレスを割り当てられることができるようになる可能性がある。従来のＵＥの組が同時に鳴るように、共用の電話番号に対して着信コールが存在するときに、従来のＩＭＳ／ＳＩＰネットワークにおけるネットワーク要素は、固有の連絡アドレスを使用して、従来の各ＵＥに対して招待要求（ＩＮＶＩＴＥ ｒｅｑｕｅｓｔ）を送信することができる。これにより、加入者は、従来のＵＥのうちの任意のＵＥにおいて、その着信コールに応答することができるようになる。

【0004】

それにもかかわらず、従来のＩＭＳ／ＳＩＰネットワークの欠点は、両方の従来のＵＥが共用の電話番号を有するという事実にもかかわらず、ひとたび着信コールが、第１の従来のＵＥにおいて第１の人によって応答された後には、第２の人は、第２の従来のＵＥを単にピックアップして、コールに参加することができないということである。その代わりに、第２の人は、第２の従来のＵＥからの特別なアクセス・コードをダイアルして、コールに参加しなければならない。この欠陥は、伝統的な公衆交換電話網（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）（ＰＳＴＮ）電話サービスと対照をなしており、この公衆交換電話網電話サービスの場合には、第２の人は、共用の電話番号を有する他の任意の電話においてハンドセットをピックアップして、直ちにコールに参加することができる。従来のＩＭＳ／ＳＩＰネットワークにおける電話技術デバイスによるオペレーションにおけるそのような違いは、ＰＳＴＮからＶｏＩＰへと移行するときにフィーチャー・トランスペアレンシー（ｆｅａｔｕｒｅ ｔｒａｎｓｐａｒｅｎｃｙ）を期待する電気通信プロバイダとエンド・ユーザとにより、致命的な欠陥と見なされてしまう可能性がある。

【発明の概要】

【課題を解決するための手段】

【0005】

実施形態の例は、ＳＩＰ通信デバイスを既存のコールに参加させることができる方法および／またはネットワーク要素を提供している。一例の実施形態によれば、ネットワーク要素は、コールを行っている通信デバイスからの着信コールを受信すること、および関連する通信デバイスの組の中の、コールを行っている通信デバイスと、少なくとも１つの関連する通信デバイスとの間で接続を確立することにより、ＳＩＰ通信デバイスを参加させることができる。関連する通信デバイスの組は、その接続について通知されることが可能であり、また会議プロシージャは、多方向の会議接続が、コールを行っている通信デバイスと、少なくとも１つの関連する通信デバイスと、少なくとも１つの接続されていなかった通信デバイスとの間で確立されるように、接続されていなかった通信デバイスがアクティブにされるのに応じて実行されることが可能である。

【0006】

さらなる実施形態の例によれば、通知装置は、アプリケーション・サーバを含むことができる。アプリケーション・サーバは、コールを行っている通信デバイスからの着信コールを受信すること、関連する通信デバイスの組の中の、コールを行っている通信デバイスと、少なくとも１つの関連する通信デバイスとの間で接続を確立すること、その接続について少なくとも１つの接続されていなかった通信デバイスに通知すること、多方向の会議接続が、コールを行っている通信デバイスと、少なくとも１つの関連する通信デバイスと、少なくとも１つの接続されていなかった通信デバイスとの間で確立されるように、接続されていなかった通信デバイスがアクティブにされるのに応じて会議プロシージャを実行すること、および共用の回線が使用可能であるときに、関連する通信デバイスの組のうちのそれぞれにアイドル通知を送信することを行うように構成されることが可能である。

【0007】

添付の図面は、実施形態の例についてのさらなる理解を提供するために含められ、また本明細書に組み込まれ、また本明細書の一部分を構成する。

【図面の簡単な説明】

【0008】

【図1】一例の実施形態によるＩＭＳネットワークを示す図である。

【図2】一例の実施形態による、既存のコールにＳＩＰ通信デバイスを参加させる方法を示す図である。

【図3】一例の実施形態による、図２のステップＳ１００をさらに定義する信号フロー図である。

【図4】一例の実施形態による、図２のステップＳ２００をさらに定義する信号フロー図である。

【図5】一例の実施形態による、図２のステップＳ３００をさらに定義する信号フロー図である。

【図6】一例の実施形態による、図２のステップＳ４００をさらに定義する信号フロー図である。

【図7A】一例の実施形態による、図２のステップＳ５００をさらに定義する信号フロー図である。

【図7B】一例の実施形態による、図２のステップＳ５００をさらに定義する信号フロー図である。

【図8A】一例の実施形態による、図２のステップＳ６００をさらに定義する信号フロー図である。

【図8B】一例の実施形態による、図２のステップＳ６００をさらに定義する信号フロー図である。

【図9】一例の実施形態による、図２のステップＳ７００をさらに定義する信号フロー図である。

【発明を実施するための形態】

【0009】

以下の説明においては、説明の目的のために、また限定しない目的のために、実施形態の例の完全な理解を提供するために、特定のアーキテクチャ、インターフェース、技法など、特定の詳細が、説明される。しかしながら、開示された主題は、これらの特定の詳細を逸脱した他の例示の実施形態の中で実行されることが可能であることが当業者には明らかであろう。いくつかの例においては、よく知られているデバイスおよび／または方法の詳細な説明は、不必要な詳細を有する説明をあいまいにしないように省略される。すべての原理、態様、および実施形態、ならびにその特定の例は、本開示の主題についての構造的な同等物と、機能的な同等物との両方を包含するように意図される。さらに、そのような同等物は、現在知られている同等物と、同様に将来において開発される同等物との両方を含むことも、意図される。

【0010】

第１、第２などの用語を本明細書において使用して、様々な要素を説明することができるが、これらの要素は、これらの用語によって限定されるべきでないことが、理解されるであろう。これらの用語を使用して、ある要素を別の要素から区別するだけである。例えば、実施形態の例の範囲を逸脱することなく、第１の要素は、第２の要素と名づけられることが可能であり、また同様に、第２の要素は、第１の要素と名づけられることも可能である。本明細書において使用されるように、用語「および／または（ａｎｄ／ｏｒ）」は、関連するリストアップされたアイテムのうちの任意のものと、関連するリストアップされたアイテムのうちの１つまたは複数についてのすべての組合せとを含む。

【0011】

いくつかの代替的実装形態においては、指摘される機能／動作は、図面の中で指摘される順序から外れて起こり得ることにも注意すべきである。例えば、連続して示される２つの図は、実際には、実質的に同時に実行されることが可能であり、または時には、関与する機能／動作に応じて逆の順序で実行されることも可能である。

【0012】

本明細書において使用されるように、用語「ユーザ装置（ＵＥ）」は、モバイル・ユーザ、ユーザ、加入者、ワイヤレス端末、および／またはリモート局に対する同義語とすることができ、またワイヤレス通信ネットワークにおけるワイヤレス・リソースのリモート・ユーザを説明することができる。

【0013】

以下の説明は、３ＧＰＰ技術および／または関連技術に基づいたネットワークに関する。しかしながら、本明細書において示され、また説明される実施形態の例は、例示的にすぎず、またいかなる形でも限定することがないように意図されていることに注意すべきである。したがって、様々な修正は、上記以外の技術に基づいた通信システムまたはネットワークに対するアプリケーションについて、当業者には明らかになり、これらの技術は、開発の様々な段階にあり、また上記のネットワークまたはシステムについての将来の置き換え、あるいは上記のネットワークまたはシステムを伴う使用のために意図される可能性がある。

【0014】

現在のネットワーク・アーキテクチャは、モバイル／ユーザ・デバイスと、アクセス・ポイント／基地局との間の区別を考慮することができるが、以降に説明される実施形態の例は、例えば、アド・ホック・アーキテクチャ（ａｄ ｈｏｃ ａｒｃｈｉｔｅｃｔｕｒｅ）および／またはメッシュ・ネットワーク・アーキテクチャなど、その区別がそれほど明確でない場合のアーキテクチャに対して一般的に適用可能とすることができる。

【0015】

図１は、一例の実施形態によるＩＭＳネットワーク１００を示すものである。例示の目的のために、図１は、３つのＵＥ（１０１、１０３、および１０５）を含んでいる。第１のユーザ装置（ＵＥ−１ １０１）は、コールを行っている通信デバイスとすることができるのに対して、第２のユーザ装置（ＵＥ−２ １０３）と、第３のユーザ装置（ＵＥ−３ １０５）とは、共用の識別子によって互いに関連づけられることが可能である。共用の識別子は、それだけには限定されないが、共用の電話番号および／または共用のユニフォーム・リソース・アイデンティファイア（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）（ＵＲＩ）フィールドとすることができる。関連するＵＥ（ＵＥ−２ １０３およびＵＥ−３ １０５）は、それぞれ個別にＩＭＳネットワーク１００に登録することができる。

【0016】

それらのＵＥは、ＳＩＰを使用して、コール・セッション制御機能（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）（ＣＳＣＦ）１０９と通信する。ＣＳＣＦ１０９は、ＩＭＳネットワーク１００においてＳＩＰシグナリング・パケットを処理するために使用されるＳＩＰのサーバおよび／またはプロキシの集まりとすることができる。ＣＳＣＦは、プロキシ−ＣＳＣＦ（Ｐ−ＣＳＣＦ）と、サービング−ＣＳＣＦ（Ｓ−ＣＳＣＦ）と、問い合わせ−ＣＳＣＦ（Ｉ−ＣＳＣＦ）とを含むことができる。Ｐ−ＣＳＣＦは、連絡の第１のポイントとすることができる。ＩＭＳネットワーク１００においてＵＥによって送信されるメッセージおよび／または受信されるメッセージは、Ｐ−ＣＳＣＦを通して伝搬する。Ｓ−ＣＳＣＦは、ＳＩＰシグナリング・プレーンにおける中心ノードとすることができる。Ｉ−ＣＳＣＦは、問い合わせ機能とすることができる。着信コール（例えば、ＳＩＰ招待要求（ＳＩＰ ＩＮＶＩＴＥ ｒｅｑｕｅｓｔｓ））は、Ｉ−ＣＳＣＦを通して伝搬する。簡単にするために、Ｓ−ＣＳＣＦだけが、より詳細に考察されることになる。ＩＭＳネットワーク１００において、ＣＳＣＦ１０９は、Ｓ−ＣＳＣＦ１１１を含んでいる。Ｓ−ＣＳＣＦ１１１とのＵＥの通信は、下記でさらに考察される。

【0017】

ＵＥと、Ｓ−ＣＳＣＦ１１１との間の通信は、様々なネットワーク要素１０７を横切る。しかしながら、様々なネットワーク要素１０７を構成する各中間要素は、明確さを向上するために示されてはいない。様々なネットワーク要素１０７は、それだけには限定されないが、（ｉ）アクセス・ネットワーク（例えば、デジタル加入者回線アクセス・マルチプレクサなど）と、（ｉｉ）ゲートウェイ（例えば、境界ゲートウェイ、ＩＭＳゲートウェイ、シグナリング・ゲートウェイ、メディア・ゲートウェイなど）と、（ｉｉｉ）他の任意の中間のＩＭＳ要素（ネットワーク・アタッチメント・サブシステム（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｍｅｎｔ Ｓｕｂｓｙｓｔｅｍ）、オートメーション構築システム（Ｂｕｉｌｄｉｎｇ Ａｕｔｏｍａｔｉｏｎ Ｓｙｓｔｅｍ）、アクセス・リソースおよびアドミッション機能、ポリシー決定機能、サービス・ベースのポリシー決定機能など）とを含むことができる。

【0018】

Ｓ−ＣＳＣＦ１１１は、ＳＩＰを利用して、アプリケーション・サーバ（ＡＳ）１１５と、メディア・リソース機能（Ｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ）（ＭＲＦ）１１３と通信する。ＡＳ１１５は、ＵＥに対して提供される様々なサービスを実行するＳＩＰエンティティとすることができる。ＡＳ１１５はまた、関連するＵＥ（ＵＥ−２ １０３およびＵＥ−３ １０５）が、共用の識別子を有することを知っていることもできる。ＡＳ１１５は、関連するＵＥが、ＩＭＳネットワーク１００に登録する場合に、またはそのときに、この事実を知るようになることができる。他方、ＭＲＦ１１３は、メディアに関連した機能（例えば、多方向会議接続、メディア操作、アナウンスメントなど）を提供することができる。ＭＲＦ１１３は、メディア・リソース機能コントローラ（Ｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）（ＭＲＦＣ）と、メディア・リソース機能プロセッサ（Ｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ）（ＭＲＦＰ）とを含むことができる。ＭＲＦＣは、Ｓ−ＣＳＣＦ１１１に対するＳＩＰユーザ・エージェントとしての機能を果たすことができる。ＭＲＦＰは、実際のメディアに関連した機能を実装することができる。

【0019】

図２は、一例の実施形態による、既存のコールにＳＩＰ通信デバイスを参加させる方法を示すものである。説明の目的のために、図２に説明される方法は、図１に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されることはない。したがって、図１からの参照番号は、必ずしも図２において使用されるとは限らない。

【0020】

ステップＳ１００において、コールを行っているＵＥからの着信コールが、受信される。コールは、ＡＳによって受信されることが可能である。ひとたび、コールが受信された後に、関連するＵＥは、ステップＳ２００を通じて、着信コールが、到着していることを警告される。次に、ステップＳ３００において、コールを行っているＵＥと、少なくとも１つの関連するＵＥとの間の接続が、確立される。ステップＳ３００は、接続されていなかった関連するＵＥとのコール・セッションを終了することを含むこともできる。ひとたび、接続が確立された後に、関連するＵＥは、ステップＳ４００を通じて接続について通知される。ステップＳ５００において、会議プロシージャは、接続されていなかったＵＥがアクティブにされるのに応じて、実行される。会議プロシージャは、コールを行っているＵＥと、関連する少なくとも１つの接続されたＵＥと、最初に接続されていなかったＵＥとを多方向会議コールに自動的に追加することができる。多方向会議コールが、終了するときに、コールは、ステップＳ６００を通じて終了されることが可能である。最後に、ステップＳ７００において、関連するＵＥは、もう一度、回線がアイドル状態であることを通知される。

【0021】

図３は、一例の実施形態による、図２のステップＳ１００をさらに定義する信号フロー図である。説明の目的のために、図３において説明される方法は、図１に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されてはいない。したがって、図１からの参照番号は、必ずしも図３において使用されるとは限らない。

【0022】

図３において、コールを行っているＵＥ（ＵＥ−１）は、ステップＳ１０１において招待要求をＳ−ＣＳＣＦに対して送信する。招待要求は、着信コールとすることができる。招待要求の宛先アドレスは、共用の識別子とすることができる。次に、ステップＳ１０３において、Ｓ−ＣＳＣＦは、招待要求をＡＳに対して転送する。図１を考察するときに上記で示されるように、共用の識別子を有する関連するＵＥ（ＵＥ−２およびＵＥ−３）は、ＡＳに登録することができる。したがって、関連するＵＥのそれぞれは、固有公共識別情報（ｕｎｉｑｕｅ ｐｕｂｌｉｃ ｉｄｅｎｔｉｔｙ）を割り当てられることが可能である。固有公共識別情報はまた、ＵＲＩフィールドとすることもできる。それに応じて、ステップＳ１０５において、ＡＳは、関連するＵＥ−２によって受信されるように意図されるＳ−ＣＳＣＦに対して招待要求を転送することができる。招待要求は、ＵＥ−２に対応する固有公共識別情報を含むことができる。Ｓ−ＣＳＣＦは、招待要求が、固有公共識別情報に基づいてＵＥ−２に進むように意図されることを知っていることができる。それゆえに、Ｓ−ＣＳＣＦは、ステップＳ１０７を通じて、招待要求を関連するＵＥ−２に対して転送する。同様に、ステップＳ１０９において、ＡＳは、関連するＵＥ−３要求に対応する固有公共識別情報を含む招待要求をＳ−ＣＳＣＦに対して転送する。Ｓ−ＣＳＣＦは、ステップＳ１１１を通じて、招待要求を関連するＵＥ−３に対して転送する。ステップＳ１０５、Ｓ１０７、Ｓ１０９、およびＳ１１１は、同時に実行され得ることに注意すべきである。また、次いで、ＡＳは、関連するＵＥ（ＵＥ−２およびＵＥ−３）に送信される顕著な招待要求を追跡することができる。

【0023】

図４は、一例の実施形態による、図２のステップＳ２００をさらに定義する信号フロー図である。説明の目的のために、図４において説明される方法は、図１に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図１からの参照番号は、必ずしも図４において使用されるとは限らない。

【0024】

ひとたび、関連するＵＥが、図３において上記で考察されるように招待要求を受信した後に、関連するＵＥは、リンギング警報（ｒｉｎｇｉｎｇ ａｌｅｒｔｓ）をＡＳに対して送信することができる。より詳細には、関連するＵＥ−２は、ステップＳ２０１において、リンギング警報をＳ−ＣＳＣＦに対して送信する。Ｓ−ＣＳＣＦは、このリンギング警報をＡＳに対して転送する。ひとたび、ＡＳによって受信された後に、ＡＳは、ステップＳ２０５に示されるように、関連するＵＥ−２のリンギング警報をＳ−ＣＳＣＦに対して転送する。ＡＳによって転送されるリンギング警報は、ステップＳ２０７を通じて、コールを行っているＵＥ−１によって受信されるように意図される。次いで、このプロセスは、関連するＵＥ−３に関して反復されることが可能である。より詳細には、ステップＳ２０９において、関連するＵＥ−３は、それ自体のリンギング・アナウンスメントをＳ−ＣＳＣＦに対して送信する。リンギング・アナウンスメントは、ステップＳ２１１を通じて、Ｓ−ＣＳＣＦからＡＳへと転送される。次いで、ＡＳは、リンギング・アナウンスメントをＵＥ−１（図示されず）へと転送することができる。

【0025】

図５は、一例の実施形態による、図２のステップＳ３００をさらに定義する信号フロー図である。説明の目的のために、図５において説明される方法は、図１に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図１からの参照番号は、必ずしも図５において使用されるとは限らない。

【0026】

最終的には、リンギング警報が、関連するＵＥによって送信された後に、加入者は、少なくとも１つの関連するＵＥをアクティブにする（例えば、コールに応答する）ことになる。ステップＳ３０１において、関連するＵＥ−２は、コールに応答し、また応答確認をＳ−ＣＳＣＦに対して送信する。図５において、応答確認は、「ＯＫ」メッセージである。ＯＫメッセージは、ストリーミング・メディア初期化パラメータ（例えば、セッション記述プロトコル応答（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ ａｎｓｗｅｒ）を記述するためのフォーマットにおける応答を含むことができる。Ｓ−ＣＳＣＦは、ステップＳ３０３において、ＯＫメッセージをＡＳに対して転送する。ステップＳ３０５において、ＡＳは、ＵＥ−２識別子を有するＯＫメッセージをＳ−ＣＳＣＦに対して転送する。ＵＥ−２識別子は、ＵＥ−２からのＳＤＰ応答を含むことができる。ステップＳ３０７において、Ｓ−ＣＳＣＦは、ＵＥ−２識別子と一緒に、ＯＫメッセージをＵＥ−１に対して転送する。上記で述べられるように、ＵＥ−１は、コールを行っているＵＥである。それに応じて、ＵＥ−１と、ＵＥ−２との間の接続が、ステップＳ３０９を通じて、その後に確立される。

【0027】

また、関連するＵＥ−３（接続されていなかった関連するＵＥ）を伴うコール・セッションも終了されることが可能である。より詳細には、ＡＳは、接続されていなかった関連するＵＥ−３を伴う顕著な招待（ＩＮＶＩＴＥ）をキャンセルすることができる。ステップＳ３１１において、ＡＳは、キャンセル・メッセージ（ｃａｎｃｅｌｌａｔｉｏｎ ｍｅｓｓａｇｅ）をＳ−ＣＳＣＦに対して送信する。キャンセル・メッセージは、ＳＩＰキャンセル・メッセージ（ＳＩＰ ＣＡＮＣＥＬ ｍｅｓｓａｇｅ）とすることができる。キャンセル・メッセージは、ステップ３１３において、Ｓ−ＣＳＣＦによりＵＥ−３に対して転送される。それに応じて、接続されていなかった関連するＵＥ−３は、ステップＳ３１５を通じて、キャンセルの肯定応答（ＡＣＫ）をＳ−ＣＳＣＦに対して返信する。キャンセルの肯定応答は、ＳＩＰ ＯＫキャンセル・メッセージ（ＳＩＰ ＯＫ ＣＡＮＣＥＬ ｍｅｓｓａｇｅ）とすることができる。Ｓ−ＣＳＣＦは、ステップＳ３１７においてキャンセルをＡＳに対して転送する。また、接続されていなかった関連するＵＥ−３は、ステップＳ３１９を通じて、同様にセッション終了メッセージ（ｓｅｓｓｉｏｎ ｔｅｒｍｉｎａｔｉｏｎ ｍｅｓｓａｇｅ）をＳ−ＣＳＣＦに対して送信する。セッション終了メッセージは、顕著な招待に対応するセッションが、終了されることを確認することができる。ステップＳ３２１において、Ｓ−ＣＳＣＦは、セッション終了メッセージをＡＳに対して転送する。次いで、ＡＳは、ＡＣＫをＳ−ＣＳＣＦに対して返信すること（ステップＳ３２３）によって応答し、Ｓ−ＣＳＣＦは、このＡＣＫを接続されていなかった関連するＵＥ−３に対して転送する（ステップＳ３２５）。図６は、一例の実施形態による、図２のステップＳ４００をさらに定義する信号フロー図である。説明の目的のために、図６に説明される方法は、図１に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけには限定されていない。したがって、図１からの参照番号は、必ずしも図６において使用されるとは限らない。

【0028】

ひとたび、コールが、図５を通じて応答された後に、ＡＳは、コールを行っているＵＥ−１と、関連するＵＥ−２との間の接続についてすべての関連するＵＥに通知することができる。図６は、この通知するプロシージャを示すものである。より詳細には、ステップＳ４０１において、ＡＳは、コール通知メッセージ（ｃａｌｌ ｎｏｔｉｆｉｃａｔｉｏｎ ｍｅｓｓａｇｅ）をＳ−ＣＳＣＦに対して送信する。コール通知メッセージは、ＳＩＰ通知要求（ＳＩＰ ＮＯＴＩＦＹ ｒｅｑｕｅｓｔ）とすることができる。コール通知メッセージは、回線が、込んでおり、かつ／またはアクティブであることを加入者に通知するために、接続されていなかったＵＥ−３によって使用されることも可能である。例えば、コール通知メッセージを使用して、従来のＰＳＴＮ電話に類似した光源および／または何らかの他のコンピュータ化された形態の加入者通知（例えば、「使用中」の光、または「コールが進行中」の光）をアクティブにすることができる。

【0029】

ステップＳ４０３において、Ｓ−ＣＳＣＦは、コール通知メッセージを接続されていなかった関連するＵＥ−３に対して転送する。しかしながら、ＡＳは、コール通知メッセージを接続された関連するＵＥ−２（図示されず）に対して転送することもできる。それに応じて、ステップＳ４０５において、接続されていなかったＵＥ−３は、確認ＯＫ通知メッセージ（ｃｏｎｆｉｒｍａｔｉｏｎ ＯＫ ＮＯＴＩＦＹ ｍｅｓｓａｇｅ）をＳ−ＣＳＣＦに対して送信する。Ｓ−ＣＳＣＦは、ステップＳ４０７を通じて、ＯＫ通知メッセージをＡＳに対して転送する。

【0030】

図７Ａ〜７Ｂは、一例の実施形態による、図２のステップＳ５００をさらに定義する信号フロー図である。説明の目的のために、図７Ａ〜７Ｂにおいて説明される方法は、図１において説明されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図１からの参照番号は、必ずしも図７Ａ〜７Ｂにおいて使用されるとは限らない。

【0031】

ひとたび、接続されていなかったＵＥ−３が、コール通知メッセージを受信した後に、接続されていなかったＵＥ−３は、アクティブにされることが可能である（例えば、ユーザは、ＵＥ−３のハンドセットをピックアップする）。会議プロシージャは、ＵＥ−３がアクティブにされた後に、自動的に開始されることが可能である。図７Ａにおいて、ステップＳ５０１は、接続されていなかったＵＥ−３によりＳ−ＣＳＣＦに対して送信されている参加コール要求（ｊｏｉｎ ｃａｌｌ ｒｅｑｕｅｓｔ）を示している。参加コール要求は、ユーザおよび／または加入者によってピックアップされているＵＥ−３に応じて送信される。参加コール要求は、ＳＩＰ招待要求とすることができる。また、ＳＩＰ招待要求は、ＳＩＰ ＵＲＩフィールドの中に特別な値を含むこともできる。次いで、Ｓ−ＣＳＣＦは、ステップＳ５０３において、参加コール要求をＡＳに対して転送する。

【0032】

ＡＳが、参加コール要求を受信する場合、またはそのときに、ＡＳは、コールを行っているＵＥ−１と、共用の識別子を有するすべての関連するＵＥとを参加させる会議プロシージャをアクティブにすることができる。会議は、すべてのパーティが、参加させられ得るような多方向会議接続とすることができる。パーティは、ＭＲＦを使用して参加させられることが可能である。図７ＡのステップＳ５０５において、招待メッセージは、ＡＳからＭＲＦへと送信される。招待メッセージは、ＵＥ−３識別子を有する、会議接続に参入すべき提案を含んでいる。その提案は、ＵＥ−３からのＳＤＰ提案とすることができる。ＭＲＦは、招待メッセージの確認を送信することにより応答することができる。図７Ａにおいて、確認は、ステップＳ５０７を通じて、ＡＳに対して送信されるＯＫ招待メッセージ（ＯＫ ＩＮＶＩＴＥ ｍｅｓｓａｇｅ）である。ＯＫ招待は、ＭＲＦからのＳＤＰ応答を含むことができる。次に、ステップＳ５０９において、ＡＳは、ＭＲＦからＳ−ＣＳＣＦへとＯＫ招待を転送する。Ｓ−ＣＳＣＦは、ステップＳ５１１を通じて、ＯＫ招待を接続されていなかった関連するＵＥ−３に対して転送する。接続されていなかった関連するＵＥ−３は、ＡＣＫをＳ−ＣＳＣＦに対して返信すること（ステップＳ５１３）により応答し、次いでこのＡＣＫは、ＡＳに対して転送される（ステップＳ５１５）。ステップＳ５１７において、ＡＳは、ＡＣＫをＭＲＦに対して転送する。その結果として、以前には接続されていなかったＵＥ−３は、今や、ステップＳ５１９を通じて、多方向会議接続に参加させられる。

【0033】

次に、コールを行っているＵＥ−１と、接続された関連するＵＥ−２とはまた、図７Ｂに示されるように、多方向会議接続に参加させられることも可能である。より詳細には、ＡＳは、ステップＳ５２１を通じて、再招待メッセージ（ＲＥＩＮＶＩＴＥ ｍｅｓｓａｇｅ）をＳ−ＣＳＣＦに対して送信する。再招待メッセージは、ＳＤＰメッセージを含んでいなくてもよい。ステップＳ５２３において、Ｓ−ＣＳＣＦは、再招待メッセージを接続された関連するＵＥ−２に対して転送する。ＵＥ−２は、再招待メッセージの確認を送信することにより応答することができる。図７Ｂにおいて、確認は、ステップＳ５２５に示されるように、Ｓ−ＣＳＣＦに対して送信されるＯＫ再招待メッセージ（ＯＫ ＲＥＩＮＶＩＴＥ ｍｅｓｓａｇｅ）である。ＯＫ再招待は、ＳＤＰ提案を含むことができる。次いで、Ｓ−ＣＳＣＦは、ステップＳ５２７を通じて、ＯＫ再招待をＡＳに対して転送する。次に、ステップＳ５２９において、ＡＳは、接続された関連するＵＥ−２からの提案を有する招待メッセージをＭＲＦに対して送信する。ＭＲＦは、ステップＳ５３１に示されるように、ＡＳに対して送信されるＯＫ招待メッセージを用いて応答することにより招待を確認する。その後に、ＡＳは、ＡＣＫをＳ−ＣＳＣＦに対して送信し（ステップＳ５３３）、このＡＣＫは、Ｓ−ＣＳＣＦにより、接続された関連するＵＥ−２に対して転送される（ステップＳ５３５）。ＡＳはまた、ステップＳ５３７を通じて、ＡＣＫをＭＲＦに対して送信する。このようにして、接続された関連するＵＥ−２はまた、ステップＳ５３９に示されるように、以前には接続されていなかった関連するＵＥ−３と一緒に、多方向会議接続に参加させられる。

【0034】

コールを行っているＵＥ−１は、接続された関連するＵＥ−２の方法と同じ方法で、多方向会議接続に参加させられることが可能である。ステップＳ５４１において、ＡＳは、再招待メッセージをＳ−ＣＳＣＦに対して送信し、この再招待メッセージは、その後にステップＳ５４３において、Ｓ−ＣＳＣＦにより、コールを行っているＵＥ−１に対して転送される。再招待メッセージは、ＳＤＰメッセージを含んでいなくてもよい。再招待メッセージの受信のすぐ後に、コールを行っているＵＥ−１は、ＯＫ再招待メッセージをＳ−ＣＳＣＦに対して送信すること（ステップＳ５４５）によって応答し、このＯＫ再招待メッセージは、Ｓ−ＣＳＣＦによりＡＳに対して転送される（ステップＳ５４７）。次に、ステップＳ５４９において、ＡＳは、コールを行っているＵＥ−１からの提案を有する招待メッセージをＭＲＦに対して送信する。ＭＲＦは、ステップＳ５５１に示されるようにＡＳに対して送信されるＯＫ招待メッセージを用いて応答することにより招待を確認する。ＡＳは、ＡＣＫをＳ−ＣＳＣＦに対して送信し（ステップＳ５５３）、このＡＣＫは、Ｓ−ＣＳＣＦにより、接続された関連するＵＥ−２に対して転送される（ステップＳ５５５）。ＡＳはまた、ステップＳ５５７を通じて、ＡＣＫをＭＲＦに対して送信する。このようにして、コールを行っているＵＥ−１はまた、ステップＳ５５９に示されるように、接続された関連するＵＥ−２と、以前には接続されていなかった関連するＵＥ−３と一緒に多方向会議接続に参加させられる。

【0035】

図８Ａ〜８Ｂは、一例の実施形態による、図２のステップＳ６００をさらに定義する信号フロー図である。説明の目的のために、図８Ａ〜８Ｂにおいて説明される方法は、図１において示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図１からの参照番号は、必ずしも図８Ａ〜８Ｂにおいて使用されるとは限らない。

【0036】

上記に説明される多方向会議接続の終了時に、次いで多方向会議接続は、終了されることが可能である。関連するＵＥのそれぞれは、同時に、または異なる間隔で接続を切ることができる。例えば、接続されたＵＥ−２は、多方向会議接続からの接続を切ることができるが、コールを行っているＵＥ−１と、以前には接続されていなかったＵＥ−３とは、多方向会議接続に留まることができる。代替的な一実施形態においては、コールを行っているＵＥ−１と、以前には接続されていなかったＵＥ−３とは、接続されたＵＥ−２が、接続を切るときに多方向会議接続以外の接続に対して転送されることも可能である。

【0037】

図８Ａは、コールを行っているＵＥ−１と、以前には接続されていなかったＵＥ−３とが、多方向会議接続の中に留まる間に、多方向会議接続からの接続を切る、接続されたＵＥ−２についての一例の実施形態を示している。より詳細には、接続された関連するＵＥ−２（今や終了しようとしている関連するＵＥ−２）は、受話器を置き、ステップＳ６０１に示されるように、さようならメッセージ（ＢＹＥ ｍｅｓｓａｇｅ）が、関連するＵＥ−２からＳ−ＣＳＣＦへと送信されるようにしている。ステップＳ６０３において、Ｓ−ＣＳＣＦは、さようならメッセージをＡＳに対して転送する。ＡＳは、終了しようとしている関連するＵＥ−２が、多方向会議接続からの接続を切るように意図していることを通知されて、ステップＳ６０５に示されるように、さようならメッセージをＭＲＦに対して転送する。さようならメッセージは、終了しようとしている関連するＵＥ−２に対応する情報を含むことができる。図８Ａにおいて、対応する情報は、終了しようとしている関連するＵＥ−２からＭＲＦへのダイアログ（ｄｉａｌｏｇ）である。ＭＲＦは、ステップＳ６０７において、確認ＯＫさようならメッセージ（ｃｏｎｆｉｒｍａｔｉｏｎ ＯＫ ＢＹＥ ｍｅｓｓａｇｅ）をＡＳに対して送信することにより、応答し、ＡＳは、ステップＳ６０９においてこの確認ＯＫさようならメッセージをＳ−ＣＳＣＦに対して転送する。Ｓ−ＣＳＣＦは、ステップＳ６１１において、同様に、終了しようとしている関連するＵＥ−２に対して確認ＯＫさようならメッセージを転送する。確認ＯＫさようならメッセージの受信のすぐ後に、終了しようとしている関連するＵＥ−２は、ステップＳ６１３に示されるように、コールを行っているＵＥ−１と、以前には接続されていなかった関連するＵＥ−３とだけが、多方向会議接続に留まるように、多方向会議接続からの接続を切られる。それに応じて、多方向会議接続は依然として存在するので、すべての接続されていなかった関連するＵＥは、依然として回線がアクティブのままであることを通知されることが可能である。

【0038】

最終的に、多方向会議接続は、多方向会議接続の中の残りのＵＥによって完全に終了させられることが可能である。図８Ｂにおいて、以前には接続されていなかったＵＥ−３（今や終了しようとしている関連するＵＥ−３）は、ステップ６１５において、受話器を置き、さようならメッセージが、Ｓ−ＣＳＣＦに対して送信されるようにしている。Ｓ−ＣＳＣＦは、ステップＳ６１７に示されるように、さようならメッセージをＡＳに対して転送する。次いで、ＡＳは、ステップＳ６１９に示されるように、終了しようとしている関連するＵＥ−３からのダイアログと一緒に、さようならメッセージをＭＲＦに対して転送する。ＭＲＦは、ステップＳ６２１において、確認ＯＫさようならメッセージをＡＳに対して送信することによって応答し、ＡＳは、ステップＳ６２３において、この確認ＯＫさようならメッセージをＳ−ＣＳＣＦに対して転送する。Ｓ−ＣＳＣＦは、ステップＳ６２７において、同様に、終了しようとしている関連するＵＥ−３に対して確認ＯＫさようならメッセージを転送する。確認ＯＫさようならメッセージの受信のすぐ後に、終了しようとしている関連するＵＥ−３は、ステップＳ６２９に示されるように多方向会議接続からの接続を切られる。

【0039】

コールを行っているＵＥ−１は、上記に説明される終了しようとしている関連するＵＥと同様なやり方で、多方向会議接続からの接続を切られることが可能である。しかしながら、コールを行っているＵＥ−１は、多方向会議接続において最後に残っているＵＥであるので、ＡＳは、終了プロセスを開始することができる。より詳細には、ＡＳは、ステップＳ６３１に示されるように、コールを行っているＵＥ−１からのダイアログを有するさようならメッセージをＭＲＦに対して送信する。ＭＲＦは、ステップＳ６３３において、確認ＯＫさようならメッセージをＡＳに対して送信することによって応答する。ＡＳは、コールを行っているＵＥ−１に関して、コール終了プロセスを開始したので、ステップＳ６３５において、ＡＳは、Ｓ−ＣＳＣＦに対してさようならメッセージを送信し、Ｓ−ＣＳＣＦは、ステップＳ６３７において、コールを行っているＵＥ−１に対してこのさようならメッセージを転送する。さようならメッセージの受信のすぐ後に、コールを行っているＵＥ−１は、ステップＳ６３９において、それ自体の確認ＯＫさようならメッセージをＳ−ＣＳＣＦに対して送信し、Ｓ−ＣＳＣＦは、ステップＳ６４３において、この確認ＯＫさようならメッセージをＡＳに対して転送する。コールを行っているＵＥ−１はまた、ステップＳ６４１において、多方向会議接続が、終了されるように、多方向会議接続からの接続を切る。

【0040】

図９は、一例の実施形態による、図２のステップＳ７００をさらに定義する信号フロー図である。説明の目的のために、図９において説明される方法は、図１に示されるネットワーク・アーキテクチャの中で実装されることが可能であるが、この実装だけに限定されていない。したがって、図１からの参照番号は、必ずしも図９において使用されるとは限らない。

【0041】

ＵＥ接続（例えば、多方向会議接続）が、切り離された後に、関連するＵＥは、共用の電話番号に対応する回線が、アイドル状態であることを通知されることが可能である。例えば、図９のステップＳ７０１において、ＡＳは、回線−アイドル通知（ｌｉｎｅ−ｉｄｌｅ ｎｏｔｉｆｉｃａｔｉｏｎ）をＳ−ＣＳＣＦに対して送信し、ステップＳ７０３において、Ｓ−ＣＳＣＦは、この回線−アイドル通知を関連するＵＥ−２に対して転送する。図８Ａに関して上記で考察されるように、次いで、現在アイドル状態である関連するＵＥ−２は、確認メッセージを用いて応答することができる。例えば、図９において、関連するＵＥ−２は、ステップＳ７０５において、ＯＫ通知メッセージ（ＯＫ ＮＯＴＩＦＹ ｍｅｓｓａｇｅ）をＳ−ＣＳＣＦに対して送信することによって応答する。次いで、Ｓ−ＣＳＣＦは、ステップＳ７０７を通じて、ＯＫ通知メッセージをＡＳに対して転送する。

【0042】

やはり現在はアイドル状態である関連するＵＥ−３に通知する同じプロセスが、反復されることも可能である。より詳細には、ステップＳ７０９において、ＡＳは、回線−アイドル通知をＳ−ＣＳＣＦに対して送信し、ステップＳ７１１において、Ｓ−ＣＳＣＦは、この回線−アイドル通知を関連するＵＥ−３に対して転送する。ステップＳ７１３において、関連するＵＥ−３は、ＯＫ通知メッセージをＳ−ＣＳＣＦに対して送信することによって応答し、次いで、Ｓ−ＣＳＣＦは、ステップＳ７１５を通じてこのＯＫ通知メッセージをＡＳに対して転送する。それに応じて、すべての関連するものは、共用の電話番号に対応する回線がアイドル状態であることを通知される。

【0043】

実施形態の例が、このようにして説明されており、同じことが、多数のやり方で変化させられ得ることが、明らかであろう。そのような、変形形態は、開示された主題からの逸脱と見なされるべきではなく、またすべてのそのような修正形態は、本開示の主題の範囲内に含められるように意図される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8A】

【図8B】

【図9】