コールの継続中の機能競合の検出と解決
【課題】コールの継続中の機能競合を検出し、解決する技術を開示する。特に、有限状態機械とそれに関連する方法によって、コールの継続中に呼び出された機能が、既に活性化されている別の機能と競合するときに検出し、両方の機能を同時に活性化しないように保証する。
【解決手段】解決のための３通りの異なる技術を開示する。第１の技術では、後からの機能の活性化を常に拒絶する。第２の技術では、前からの機能を常に非活性化にして、後からの機能をその後で活性化する。第３の技術では、２つの機能のうちの１つを、機能に割り付けられた優先度に基づき、活性化する機能として選択し、それらの機能をそれぞれ活性化または非活性化する。
【解決手段】解決のための３通りの異なる技術を開示する。第１の技術では、後からの機能の活性化を常に拒絶する。第２の技術では、前からの機能を常に非活性化にして、後からの機能をその後で活性化する。第３の技術では、２つの機能のうちの１つを、機能に割り付けられた優先度に基づき、活性化する機能として選択し、それらの機能をそれぞれ活性化または非活性化する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には通信に関し、特に、コールの継続中(mid-call)の機能競合（feature interaction)の検出と解決に関する。
【背景技術】
【０００２】
長年の間、広汎な通信の多様な機能が開発されてきた。例えば、コール転送、三者間コール、保留時音楽（hold on music)など。しかし複数の機能が電話のコールに採用されると、機能間の競合が、妨げられるべき方針を許可することやコールを失敗させることのような、予期しないまたは希望しない動作を引き起こすことがある。
【０００３】
例えば、ミートミー（meet me)会議機能を介してコールがセットアップされ、その後に保留時音楽機能がそのコールの継続中に活性化されたと想定すると、もし、そのコールの一人の参加者が保留状態になった場合、その他の全てのコール参加者もその音楽を聞くことになる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
通常、テレフォニープラットホームの供給者は設計の時点で機能競合を予期しようと試みる。しかし、設計時点の技術の限界として、プラットホーム供給者の設計の範囲を越えて、サードパーティが新しい機能を付加して発生するであろう、機能競合を予期することは困難である。一方で、ランタイムの機能競合の検知や解決の技術は、通常、分散化したネットワーク環境の中で維持することが難しく、コールのセットアップ間に処理するのが不可能な計算のオーバーヘッドを必要とする、詳細なモデルに頼っている。
【課題を解決するための手段】
【０００５】
本発明はコールの継続中の機能競合の検出と解決の技術を提供する。例示の実施形態では、有限状態機械とそれに相応する方法により、コールの継続中に呼び出された機能が、別のそれ以前に活性化された機能と競合している時には、それを検出し、両方の機能が同時に活性化されないことを保証する。
【０００６】
例示の実施形態の最初の技術では、後の機能の活性化を常に拒否する。一方、第２の技術では、前の機能を常に拒否する。第３の技術では、２つの機能の一つを活性化された機能として選択し、それらの機能は、それに応じて、活性化または非活性化される。例示の実施形態では、第３の技術は、機能の優先度によって、２つの機能のどちらが支配的かを決定する。
【０００７】
その例示の実施形態は、本発明の第１の例示の実施形態の方法を含む、機能競合の検出の異なる方法と組合わせて用いられる。更に、第２の例示の実施形態は、様々なネットワークトポロジーの中のＶｏＩＰ(Voice Over Internet Protocol) コールのためのコールの継続中検出を提供するための、第３の例示の実施形態の技術と組み合わせて用いられる。
【０００８】
その例示の実施形態は、第１の機能が活性化されることを示す第１の信号を受け取ること、コールの継続中に第２の機能が呼び出されることを示す第２の信号を受け取ること、そのコールの継続中に第１の機能と第２の機能が競合するかどうかを決定することを含む。
【図面の簡単な説明】
【０００９】
【図１】本発明の第１の例示の実施形態での、複数参加者(multi-party)またはブリッジド・アピアランス(bridged-appearance)コールのための機能競合を検出し、解決する方法に関するフローチャート。
【図２】本発明の第２の例示の実施形態での、コールの継続中の機能競合を検出し解決するための、有限状態機械。
【図３】本発明の第２の例示の実施形態での、図２に示される有限状態機械２００に関する方法のフローチャート。
【図４】本発明の第２の例示の実施形態での、図３に示されるタスク３５０を遂行するための第１の技術のフローチャート。
【図５】本発明の第２の例示の実施形態での、タスク３５０を遂行するための第２の技術のフローチャート。
【図６】本発明の第２の例示の実施形態での、タスク３５０を遂行するための第３の技術のフローチャート。
【図７】本発明の第３の例示の実施形態での、複数のレグのシグナリングパス(signaling path)を持つコールのための機能競合を検出し解決する、第１の方法のフローチャート。
【図８】本発明の第３の例示の実施形態での、複数のレグのシグナリングパスを持つコールのための機能競合を検出し解決する、第２の方法のフローチャート。
【図９】本発明の第４の例示の実施形態での、透過型のＢ２ＢＵＡ(Back to back user agent)から構成される、例示のシグナリングパス。
【発明を実施するための形態】
【００１０】
用語「コール」は通信端末ユーザーを巻き込む相互のコミュニケーションと定義する。コールは、従来の音声電話コール、ＶｏＩＰコール、ＳＩＰ(Session Initiation Protocol)セッション、インスタントメッセージ・セッション、テレビ会議、その他である。
【００１１】
本発明の、第１の例示の実施形態では、機能競合を検出し、解決するために、５個の基本規則を用いる。その各々は、複数参加者コールのための１変数と、ブリッジド・アピアランスを持つコールのための１変数を有する。これらの規則のいくつかは、「トリートメント」について取り扱う。「トリートメント」とは、コールの継続中のある状態（即ち、コールがさえぎられた状態、コールがブロックされた状態）を取り扱うために、ネットワークによって発せられるアナウンスまたはトーンである。潜在的には、ある特定のコールにかかわる複数のトリートメントがあり得る。例えば、ひとつの機能は、コールの継続中にある参加者をビジートリートメントに接続し、一方、第２の機能は、同じコールの継続中に、ある参加者（同じ参加者または別の参加者）をネットワーク使用不可トリートメントに接続する。
【００１２】
第１の例示の実施形態では、機能の挙動を詳細に表現するために、表現法を用いる。それは自動的な規則マッチングを容易にする付加的利益を有する。この表現法の例として、機能「コール転送」略して「ＣＦＵ」はこの表現法で以下のように表現される。
ＣＦＵ： ＴＰ：Ｃ； Ａ，Ｃ → Ａ，Ｂ
ここで
・「ＴＰ：Ｃ」は、エンドポイントＣがトリガーを発する参加者（すなわち、機能が活性化されるエンドポイント）を意味する。
・矢印の左手側の「Ａ，Ｃ」は エンドポイントＡとエンドポイントＣの間に元の接続（即ち、機能を活性化する前からのＡとＣの間の接続）があったことを意味する。「元の接続」を特許請求の範囲では、「旧接続」と称する。
・矢印の右手側の「Ａ，Ｂ」は、エンドポイントＡとエンドポイントＢの間が、結果として得られた接続（すなわちその機能が活性化された後でＡとＢの間が接続）されたことを意味する。「結果としての接続」を特許請求の範囲では、「新接続」と称する。
【００１３】
別の例では、機能「複数参加者コールへの加入」略して「ＣｏｎｆＪｏｉｎ」は、この表現法で以下のように表現される。
ＣｏｎｆＪｏｉｎ： ＴＰ：Ａ；[Ａ，Ｃ]Ａ，Ｂ → Ａ，Ｂ，Ｃ
ここで
・「ＴＰ：Ａ」は、エンドポイントＡがトリガーを発する参加者を意味し、
・矢印の左手側の「[Ａ，Ｃ]」は エンドポイントＡとエンドポイントＣの間に元の接続があり、ホールド状態になっていることを意味し、
・矢印の左手側の「Ａ，Ｂ」は エンドポイントＡとエンドポイントＢの間に元の接続があったことを意味し、
・矢印の右手側の「Ａ，Ｂ，Ｃ」は、エンドポイントＡ，Ｂ，Ｃの間が結果として接続された（すなわち、ＡとＢ、ＡとＣ、ＢとＣの間が結果として接続された）ことを意味する。
【００１４】
「複数参加者コール」
複数参加者コールの規則１ａ
ＩＦ
機能１及び機能２が、同一のトリガーを発する参加者を有する
ＡＮＤ
（機能１の結果としての接続＝機能２の結果としての接続
ＯＲ
機能１の元の接続＝機能２の元の接続）
ＴＨＥＮ
機能１と機能２は競合する。
【００１５】
複数参加者コールの規則２ａ
ＩＦ
機能１の元の接続＝機能２の結果としての接続
ＡＮＤ
機能２の元の接続＝機能１の結果としての接続
ＴＨＥＮ
機能１と機能２は競合する。
【００１６】
複数参加者コールの規則３ａ
ＩＦ
機能２がトリートメントに接続し、
ＡＮＤ
｛機能１の結果としての接続｝∩｛機能２の結果としての接続｝
≠φ
ＡＮＤ
∃Ｘ∈｛機能１の元の接続｝
∃Ｙ∈｛機能１の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］
ＯＲ
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］
ＴＨＥＮ
機能１と機能２は競合する。
【００１７】
複数参加者コールの規則４ａ
ＩＦ
｛機能１の結果としての接続｝∩｛機能２の元の接続｝
≠φ
ＡＮＤ
［∃Ｘ∈｛機能１の元の接続｝
∃Ｙ∈｛機能１の結果としての接続｝?
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］］
ＯＲ
［∃Ｘ∈｛機能２の元の接続｝
∃Ｙ∈｛機能２の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００１８】
複数参加者コールの規則５ａ
ＩＦ
機能１の元の接続＝機能２の元の接続
≠φ
ＡＮＤ
［∃Ｘ∈｛機能１の元の接続｝
∃Ｙ∈｛機能１の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する参加者（機能１）］］
ＯＲ
［∃Ｘ∈｛機能２の元の接続｝
∃Ｙ∈｛機能２の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する参加者（機能２）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００１９】
「ブリッジド・アピアランス（ＢＡｓ）」
もしエンドポイントＡがエンドポイントＢをコールし、Ｂが既にエンドポイントＣとブリッジド・アピアランスの状態の場合、Ａは、Ｂと、更にＣとも接続させられる。同様に、もしエンドポイントＢがエンドポイントＡをコールし、Ｂが既にエンドポイントＣとブリッジド・アピアランスの状態の場合は、発呼者と被呼者を逆にして同じ接続が結果として得られる。表記法を用いて、第１のケースを次のように表現する。
ＢＡ：ＴＰ：Ｂ；Ａ，Ｂ， → Ａ，Ｂ−Ｃ
ここで「Ｂ−Ｃ」はＢがＣとブリッジド・アピアランスの状態であることを示す。第２のケースを次のように表現する。
ＢＡ：ＴＰ：Ｂ；Ｂ，Ａ， → Ｂ−Ｃ，Ａ
【００２０】
以下の規則は、ブリッジド・アピアランスが既に存在するコールでの、２つの機能競合をを検出することができる。言い換えると、これらの規則はＢＡ機能の活性化の後で適用される２つの機能の間の競合がある場合に、それを検出する。
【００２１】
１以上のＢＡを有するコールに関する規則１ｂ：規則１ａと同一
ＩＦ
機能１及び機能２が同じトリガーを発する参加者を有する
ＡＮＤ
（機能１の結果としての接続＝機能２の結果としての接続
ＯＲ
機能１の元の接続＝機能２の元の接続）
ＴＨＥＮ
機能１と機能２は競合する。
【００２２】
１以上のＢＡを有するコールに関する規則２ｂ：規則２ａと同一
ＩＦ
機能１の元の接続＝機能２の結果としての接続
ＡＮＤ
機能２の元の接続＝機能１の結果としての接続
ＴＨＥＮ
機能１と機能２は競合する。
【００２３】
１以上のＢＡを有するコールに関する規則３ｂ
ＩＦ
機能２がトリートメントに接続し、
ＡＮＤ
｛ＢＡ上の参加者を含み、機能１の結果としての接続｝∩
｛ＢＡ上の参加者を含み、機能２の結果としての接続｝
≠φ
ＡＮＤ
∃Ｘ∈｛ＢＡ上の参加者を含み、機能１の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能１の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］
ＯＲ
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］
ＴＨＥＮ
機能１と機能２は競合する。
【００２４】
１以上のＢＡを有するコールに関する規則４ｂ
ＩＦ
｛ＢＡ上の参加者を含み、機能１の結果としての接続｝∩
｛ＢＡ上の参加者を含み、機能２の元の接続｝
≠φ
ＡＮＤ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能１の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能１の結果としての接続｝?
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］］
ＯＲ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能２の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能２の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００２５】
１以上のＢＡを有するコールに関する規則５ｂ
ＩＦ
機能１の元の接続＝機能２の元の接続
≠φ
ＡＮＤ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能１の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能１の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する者（機能１）］］
ＯＲ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能２の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能２の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する者（機能２）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００２６】
図１は、本発明の第１の例示の実施形態での、複数参加者またはブリッジド・アピアランスコールのための機能競合を検出し、解決する方法のフローチャートを表している。図１に表わしたどのタスクが、同時に、または表わされているのとは異なる順序で、実行され得るかは、この技術分野の当業者には、この技術開示を読んだ後では自明となる
であろう。
【００２７】
タスク１１０で、機能ｆ１は、３以上のエンドポイント、１以上のブリッジド・アピアランス、またはその両方を有するコールに関する第１の機能へと初期化される。
【００２８】
タスク１２０で、機能ｆ２はコールＣに関する第２の機能へと初期化される。
【００２９】
タスク１３０は、機能ｆ１及びｆ２が規則１ａ−５ａ及び規則１ｂ−５ｂのいずれかに合致するかどうかを決定する。この技術分野の当業者には理解できるであろうが、そのような決定を実施するのに、本分野でよく知られた様々な方法がある。例えばエクスパートシステムの規則マッチングエンジン、論理プログラム、制約充足システム、単純な網羅的探索法、など。そして、タスク１３０を実施できる本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００３０】
もしタスク１３０が機能ｆ１と機能ｆ２について規則が合致しないと決定した場合は、実行はタスク１４０に進み、そうでない場合には、実行はタスク１５０で続行される。
【００３１】
タスク１４０では、よく知られたやり方で、機能ｆ１と機能ｆ２の両方が活性化される。タスク１４０の後で、図１の方法の実行は終了する。
【００３２】
タスク１５０では、機能ｆ１と機能ｆ２の、双方ではなく一方が、よく知られたやり方で、活性化される。この技術分野の当業者には理解できるであろうが、タスク１５０が２つの機能のうちの１つを活性化のために選択する（すなわちタスク１５０が機能競合の解決を行う）方法は、種々存在する。例えば本発明のある実施形態の中で、タスク１５０が決定論的に最初に呼び出された機能を選択するかもしれないし、一方、本発明の別のある実施形態ではタスク１５０が決定論的に最後に呼び出された機能を選択するかもしれないし、更に、別のある実施形態では解決の別の方法、すなわち、以下に述べるような、そして第２の例示の実施形態と、図２から図６に関わるような別の方法が実施されるかもしれない。どんなケースでも、タスク１５０を実施することができる本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００３３】
タスク１５０の後で、図１の方法の実行は終了する。
【００３４】
この技術分野の当業者には理解できるであろうが、図１の方法は、種々のテレフォニープラットホームとプロトコル（例えばＳＩＰを基盤としたＶｏＩＰテレフォニー、公衆電話網を介した従来からの回線交換テレフォニーなど）と共同して履行され得るし、そのようなプラットホームやプロトコルのためのこの方法に基づく本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００３５】
「コールの継続中の機能競合検出・解決」
本発明の第２の例示の実施形態は、コールの継続中の機能競合の検出と解決（すなわち、コールの継続中機能競合検出・解決）を可能とする。第２の例示の実施形態の技術は、複数参加者コールやブリッジド・アピアランスを持つコールのためのコールの継続中機能競合検出・解決を提供するために、第１の例示の実施形態の技術と組み合わせることができる。
【００３６】
図２は、本発明の第２の例示の実施形態での、コールの継続中の機能競合を検出し、解決するための有限状態機械（ＦＳＭ）２００を表している。図２に示すように、有限状態機械（ＦＳＭ）２００は状態２０１から２０６で構成されている。ここで、状態２０１は開始状態であり、状態２０５及び２０６は最終状態である。有限状態機械（ＦＳＭ）２００の中の、各々の孤（または指示された端）は、最初の状態から第２の状態への正当な遷移を示し、孤上のラベルは遷移の記述を与える。
【００３７】
開始状態２０１では、機能ｆ１が活性化される。本発明のある実施形態では、開始状態２０１へはコールセットアップの前に入るであろうし、また、一方、他のある実施形態ではコールのセットアップ中に入り、更に他のある実施形態ではコールセットアップの後でコールの継続中に入る。
【００３８】
機能ｆ２がコールの継続中に呼び出された場合には、有限状態機械（ＦＳＭ）２００は、開始状態２０１を離れて状態２０２に入る。
【００３９】
状態２０２では、機能ｆ１とｆ２に関する競合のチェックが行われる。もし競合があれば、有限状態機械（ＦＳＭ）２００は状態２０２を離れ、状態２０３に入る。
【００４０】
状態２０３は、機能ｆ１または機能ｆ２がより高い優先度を有するかどうかによって、状態２０４、２０５、２０６のいずれかに遷移する。（機能の優先度、及び、機能ｆ１とｆ２の一つを選択する解決の技術については、図３から図６を参照しながら以下に詳細に記述する。）もし、機能ｆ１が機能ｆ２に対して優先であれば、状態２０３は状態２０６に遷移する。もし、機能ｆ２が機能ｆ１に対して優先であり、かつ、機能ｆ２が条件付きであれば、状態２０３は状態２０４に遷移する。もし、機能ｆ２が機能ｆ１に対して優先であり、かつ、機能ｆ２が条件なしであれば、状態２０３は状態２０５に遷移する。
【００４１】
状態２０４では、機能ｆ２が使用されているかどうかのチェックがなされる。もし、使用されていれば状態２０４は状態２０５に遷移し、そうでなければ状態２０４は状態２０６に遷移する。
【００４２】
最終状態２０５では、コールは機能ｆ１なしで繰り返される。
【００４３】
最終状態２０６では、次の機能が処理される。
【００４４】
図３は、本発明の第２の例示の実施形態での、有限状態機械（ＦＳＭ）２００に関連した方法についてのフローチャートを表している。図３の中に表現されているどのタスクが、同時に、または表現されている順序とは異なる順序で、実行され得るかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００４５】
タスク３１０では、よく知られたやり方で、機能ｆ１が活性化されたことを示す最初の信号が受け取られる。この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、この最初の信号は、スイッチによって受信され、別のある実施形態ではＰＢＸ(構内交換機)で受信され、更に別の実施形態では別のデータ処理システムから受信される。更に、この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、機能ｆ１は特定コールをかける前に、タスク３１０で活性化され、別のある実施形態では、特定コールの間に機能ｆ１が活性化される。どの場合でも、タスク３１０の実行を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００４６】
タスク３２０では、第２の信号がコールの継続中に受け取られる。その第２の信号はコールの間に機能ｆ２が呼び出されたことを示している。
【００４７】
タスク３３０は、コールの間に、機能ｆ１とｆ２が競合しているかどうかを決定する。この技術分野の当業者には理解できるであろうが、機能競合を検出する種々の方法がある。例えば、本発明のある実施形態では、機能競合は第１の例示の実施形態の規則の組から決定され、一方、別のある実施形態では、機能競合の検知は代替の技術により実施される。どんな場合でも、タスク３３０の実行を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００４８】
タスク３４０はタスク３３０の決定に基づき、分岐を行う。タスク３３０で機能ｆ１とｆ２が競合していないと決定された場合は、実行はタスク３５０に進み、そうでない場合は、実行はタスク３６０で続けられる。
【００４９】
タスク３５０では、機能ｆ２が、よく知られたやり方で活性化される。タスク３５０の後は、図３の方法の実行は終了する。
【００５０】
タスク３６０では、機能競合は解決される。この技術分野の当業者には理解できるであろうが、機能競合を解決する種々の方法がある。例えば、本発明のある実施形態では、機能競合を解決するために、以下に記述され、図４から図６に関連する、技術の一つが用いられ、別の実施形態では、機能競合を解決するために別の技術が用いられる。どんな場合でも、タスク３６０の実施が可能な本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００５１】
タスク３６０の後で、図３の方法の実行は終了する。
【００５２】
図４は、本発明の第２の例示の実施形態での、タスク３６０を実施するための第１の技術のフローチャートを表している。この第１の技術では、より早く活性化された機能（すなわち、機能ｆ１）に、他の考慮（例えば、機能ｆ１とｆ２の特性、機能ｆ１の活性化と機能ｆ２の要求の間の経過時間など）をせずに、不変の優先度が与えられる。
【００５３】
タスク４１０では、機能ｆ２の活性化は拒絶される。この技術分野の当業者には理解できるであろうが、ある実施形態では、拒絶は、なぜ機能ｆ２が活性化されなかったのかという、ある形式の通知または説明が付属するが、別の実施形態では、活性化は付属するアクションなしで拒絶される。
【００５４】
タスク４１０が完了すると、図４の技術と図３の方法は終了する。
【００５５】
図５は、本発明の第２の例示の実施形態での、タスク３６０を遂行するための第２の技術のフローチャートを表している。この第２の技術では、後に活性化された機能（すなわち機能ｆ２）は、他のことを考慮せずに、不変の優先度が与えられる。図５に表わされているどのタスクが、同時に、または表わされているのと違った順番で遂行されるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００５６】
タスク５１０で、機能ｆ１は、よく知られたやり方で、非活性化される。
【００５７】
タスク５２０で、機能ｆ２は、よく知られたやり方で、活性化される。
【００５８】
この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、タスク５１０とタスク５２０には、これらのアクションに関するある形式の通告や説明が付属するが、ある別の実施形態では、どんな通告や説明も付属しない。
【００５９】
タスク５２０が完了した後で、図５の技術及び図３の方法は終了する。
【００６０】
図６は、本発明の第２の例示の実施形態に従って、タスク３６０を遂行するための第３の技術のフローチャートを表している。この第３の技術では、機能の優先度合は、機能に付与された「優先度」によって決定される。図６に表現されているどのタスクが、同時に、または表現されているのと違った順番で遂行されるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００６１】
タスク６１０は、機能ｆ２が機能ｆ１より高い優先度を有するかどうかをチェックする。もし、有しなければ、実行はタスク６２０に進み、そうでない場合は、実行はタスク６３０で続行される。
【００６２】
タスク６２０では、機能ｆ２の活性化は拒絶される。この技術分野の当業者には理解できるであろうが、ある実施形態では、拒絶は、なぜ機能ｆ２が活性化されなかったのかという、ある形式の通知または説明が付属するが、別の実施形態では、活性化は付属するアクションなしで拒絶される。
【００６３】
タスク６２０が完了した後で、図６の技術及び図３の方法は終了する。
【００６４】
タスク６３０では、機能ｆ１は、よく知られたやり方で、非活性化される。
【００６５】
タスク６４０では、機能ｆ２は、よく知られたやり方で、活性化される。
【００６６】
この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、タスク６３０とタスク６４０には、これらのアクションに関するある形式の通告や説明が付属するが、別の実施形態では、どんな通告や説明も付属しない。
【００６７】
タスク６４０が完了した後で、図６の技術及び図３の方法は終了する。
【００６８】
この技術分野の当業者には理解できるであろうが、本発明の別の態様では、機能１と機能２の間の優先度における「同点」は、機能１よりも機能２を選択して破られることもある。そのような代替の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００６９】
この技術分野の当業者には理解できるであろうが、図３から図６の方法は、種々のテレフォニープラットホームとプロトコル（例えばＳＩＰを基盤としたＶｏＩＰテレフォニー、公衆電話網を介した従来からの回線交換テレフォニーなど）と共同して履行され得るし、そのようなプラットホームやプロトコルのためのこの方法に基づく本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７０】
「複数レグのシグナリングパスを持つコールのためのコールの継続中検出」
本発明の第３の例示の実施形態は、複数レグのシグナリングパスを持つコールのための機能競合の検出と解決を可能にする。第３の例示の実施形態の技術は、複数のエンドポイント及び／またはブリッジド・アピアランスを持つ複数レグコールについてのコールの継続中機能競合を検出し、解決するために、第１及び第２の例示の実施形態の技術と組み合わせることができる。
【００７１】
図７は、本発明の、第３の例示の実施形態での、複数レグのシグナリングパスを持つコールの機能競合を検知し、解決する第１の方法のフローチャートを表している。図７に表わされているどのタスクが、同時に、または表わされているのと違った順番で実施されるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７２】
タスク７１０では、よく知られたやり方で、複数レグのシグナリングパスを持つコールのレグＬのために、一つの機能が呼び出されることを示す信号が受け取られる。
【００７３】
タスク７２０では、レグＬに関する機能状態情報がそれに応じて更新され、ネットワークの適切なノードにストアされる。この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、機能状態情報は、第４の例示の実施形態を参考にして以下に記述するように、１以上のＢ２ＢＵＡにストアされ、一方、別の実施形態では、機能状態情報は、別のタイプのノード、例えばスイッチ、サーバー、ＰＢＸなどにストアされる。どの場合でも、タスク７２０の実施を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７４】
タスク７３０では、よく知られたやり方で、更新された機能状態情報が、そのコールのシグナリングパスにそって伝送される。
【００７５】
タスク７４０では、必要に応じて、シグナリングパスのレグをクロスするアドレスマッピング(Address Mapping)が行われる。例えば、シグナリングパスにそったシグナリング要素が、そのパスの一部分にそったシグナリング要素のアドレスを削除する。このアドレス情報は通常シグナリング情報で搬送される。シグナリング要素は、別のシグナリング要素及びエンドポイントのためのアドレス情報を変更することもできる。このアドレス情報も通常シグナリング情報で搬送される。そのようなマッピングと変形(transformation)を用いて、内部のシグナリングトポロジーの詳細を外部のシグナリング要素及びエンドポイントから隠し、エンドポイントには見えないシグナリングパスへと変更することを許容する。タスク７４０でのアドレスマッピングは、機能競合検出の規則に、実際にそのコールでのエンドポイントであるという矛盾のない見方を与える。
【００７６】
タスク７５０は、呼び出された機能が、（ｉ）そのコールのシグナリングパスの異なるレグのための機能か、（ｉｉ）レグＬのための別の機能かのいずれかと、競合するかどうかをチェックする。 もし、競合していれば、実行はタスク７６０に進み、そうでなければ実行はタスク７７０で継続される。
【００７７】
タスク７６０では、よく知られたやり方で、その機能が活性化される。タスク７６０の後で、図７の方法の実行は終了する。
【００７８】
タスク７７０では、機能競合が解決される。この技術分野の当業者には理解できるであろうが、機能競合を解決する種々の手段がある。例えば、本発明のある実施形態では、図４から６を参考にして上に述べた技術の１つが、機能競合を解決するために用いられ、一方、本発明の別の実施形態では、機能競合を解決するために、別の技術が用いられる。どんな場合でも、タスク７７０の実施を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７９】
タスク７７０の後で、図７の方法の実行は終了する。
【００８０】
図８は、本発明の第３の例示の実施形態に従って、複数レグのシグナリングパスを有するコールに関する機能競合を検出し解決するための第２の方法に関するフローチャートを表している。 図８のどのタスクが同時に、あるいは表したのと異なる順序で、遂行されうるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００８１】
タスク８１０では、新たなレグがコールに追加されるべきか、または、新たなレグが既にコールに追加されているか、を示す信号が受け取られる。
【００８２】
タスク８２０では、よく知られたやり方で、新たなレグのための機能状態情報がそのコールのシグナリングパスにそって伝送される。
【００８３】
タスク８３０では、必要に応じて、シグナリングパスのレグをクロスするアドレスマッピングが行われる。例えば、シグナリングパスにそったシグナリング要素が、別の方法でシグナリング情報の中で伝送されるであろう、そのパスの一部分にそったシグナリング要素のアドレスを削除する。そのようなシグナリング要素は、別の方法でシグナリング情報の中で伝送されるであろう、別のシグナリング要素及びエンドポイントのためのアドレス情報を変更することもできる。そのようなマッピングと変形は、内部のシグナリングトポロジーの詳細を外部のシグナリング要素及びエンドポイントから隠すために、また、１以上のエンドポイントには見えないシグナリングパスへと変更することを許容するために、使用される。タスク８３０でのアドレスマッピングは、機能競合検出の規則に、実際にそのコールでのエンドポイントであるという矛盾のない見方を与える。
【００８４】
タスク８４０は、新たなレグのどんな機能状態情報が、そのコールのどの現存するレグのどの機能と競合するかどうかをチェックする。もし競合するならば、実行はタスク８５０に進み、そうでなければ実行はタスク８６０で続行する。
【００８５】
タスク８５０では、よく知られたやり方で、機能が活性化される。タスク８５０の後で、図８の方法の実行は終了する。
【００８６】
タスク８６０では、機能競合が解決される。この技術分野の当業者には理解できるであろうが、機能競合を解決する種々の手段がある。例えば、本発明のある実施形態では、図４から６を参考にして上に述べた技術の１つが、機能競合を解決するために用いられ、一方、本発明の別の実施形態では、機能競合を解決するために、別の技術が用いられる。どんな場合でも、タスク８６０を実施することができる本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００８７】
タスク８６０の後で、図８の方法の実行は終了する。
【００８８】
この技術分野の当業者には理解できるであろうが、図７及び図８の方法は、種々のテレフォニープラットホームとプロトコル（例えばＳＩＰを基盤としたＶｏＩＰテレフォニー、公衆電話網を介した従来からの回線交換テレフォニーなど）と共同して履行され得るし、そのようなプラットホームやプロトコルのためのこの方法に基づく本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００８９】
「Ｂ２ＢＵＡを使ったＶｏＩＰのための実現方法」
第４の例示の実施形態は、上に述べた第１、第２、第３の例示の実施形態に従って、タスクを遂行することを可能とするＶｏＩＰコールのための実現方法を用意する。 このように第４の例示の実施形態は、コールの継続中機能競合検出・解決、複数レグのシグナリングパスを有するコール、複数参加者コール、及び、ブリッジド・アピアランスを有するコールを取り扱うことが可能である。
【００９０】
第４の例示の実施形態へのアプローチは、分散され、それがＶｏＩＰテレフォニー及びＳＩＰへの適用を容易にする。活性化された各々の機能が、ＳＩＰメッセージの中に、「トリガーを発する参加者」と「接続のタイプ」を含める。もし既にメッセージの中に１以上の記入事項があれば、それらは、現在の機能の記述に対してチェックされる。このように、必要ならどこでもアルゴリズムが実行され、中央の機能マネージャーは必要とされない。このことはそのアプローチを高度にスケラブル（拡張可能）にする。
【００９１】
ＳＩＰについては、標準のＳＩＰヘッダーは十分な詳細を提供していない。それゆえ要求される情報を伝達する追加のヘッダーが定義され、そのヘッダーはＳＩＰメッセージに含まれることができる。２つのプライベートなヘッダーが、このアプローチに必要とする情報を伝達するために定義された。 Ｐ−ＣｏｎＴｙｐｅとＰ−Ｆｏｒｗａｒｄｅｄ−Ｔｏである。Ｐ−ＣｏｎＴｙｐｅヘッダーは現在のセッションで活性化されている機能の説明を含んでおり、Ｐ−Ｆｏｒｗａｒｄｅｄ−ＴｏヘッダーはＩＮＶＩＴＥリクエストが別の参加者にリダイレクトされたときの、インバイトされた参加者のためのＩＤを含んでいる。
【００９２】
機能シークエンスの間に、現在のＳＩＰメッセージはＰ−ＣｏｎＴｙｐｅヘッダーに関してチェックされる。そのようなヘッダーが見つからない場合は、どんな別の機能も以前に活性化されておらず、従って機能競合は起こりえない。そのような場合は、新たなＰ−ＣｏｎＴｙｐｅヘッダーが、現在の機能を記述するメッセージに挿入される。例えば、転送機能に関しては、ヘッダーは次のようになる。
P-ConType: ID=Forward; TP=sip:bob@d254203.com;
OrigFrom=chris@discus.com;OrigTo=bob@d254203com;
FinalFrom=chris@discus.com;FinalTo=alice@d254203.com
【００９３】
そのヘッダーは、ＩＤのフィールド、トリガーを発した参加者、及び接続タイプを含む。ＩＤはヘッダーの中に記述される機能を特定する。ＴＰは、トリガーを発する参加者を含み、残る４つのフィールドは、接続タイプの４つのフィールドに対応する。
【００９４】
第４の例示の実施形態では、Ｂ２ＢＵＡは、機能状態とコールレグに関するシグナリング情報をストアし、保持する。また、シグナリングパスにそってこの情報を伝送する。この技術分野の当業者には理解できるであろうが、Ｂ２ＢＵＡはＳＩＰコールの両端へのユーザーエージェントとして機能し、コールの両端の間の全てのＳＩＰシグナリングを、コールの確立から終了まで、処理する責任を持つ。ＳＩＰのクライアントにとって、Ｂ２ＢＵＡは一面では、ユーザーエージェントサーバーとして機能し、他面ではユーザーエージェントクライアントとして機能する。Ｂ２ＢＵＡは、コールマネージメント（例えば、課金、自動コール切断、コール転送など）、ネットワーク相互作用（たぶんプロトコルの適応を伴う）、 ネットワーク内部の秘匿（個人アドレス、ネットワークトポロジーなど）、２コールレグ間のコーデック変換などの追加の機能も提供する。 この技術分野の当業者には理解できるであろうが、Ｂ２ＢＵＡは、透過型Ｂ２ＢＵＡであったり、監視型Ｂ２ＢＵＡであったり、または、セッションボーダーコントローラー（ＳＢＣ）として機能したりする。
【００９５】
「透過型Ｂ２ＢＵＡ」
透過型Ｂ２ＢＵＡには２つのケースがある。第１のケースは、透過型Ｂ２ＢＵＡは、Ｐ−ＣｏｎＴｙｐｅヘッダーを指示通り転送し、かつ、競合により機能が実行不可であることを送り返すことができる。これはヘッダーに何の情報変更もなく行われる。
【００９６】
第２のケースでは、透過型Ｂ２ＢＵＡはいくつかのヘッダーで情報を変更する。このことは機能競合のアプローチにインパクトを与え得る。例えば、Ｆｒｏｍ／Ｔｏ／ＲｅｑｕｅｓｔＵＲＩ内での変更を通してエンドポイントのアイデンティティを変更することにより、これらのヘッダー間のマッピング及びＰ−ＣｏｎＴｙｐｅヘッダーに含まれる情報が破壊される。その上、Ｐ−ＣｏｎＴｙｐｅヘッダーは、参加者の「以前の」アイデンティティを開示するかもしれない。そのため、Ｂ２ＢＵＡは、変更されたＳＩＰヘッダー内と同じようにＰ−ＣｏｎＴｙｐｅヘッダー内の値の上に、同じアドレスマッピングを実施する必要がある。このマッピングは上方へのメッセージ及び下方へのメッセージのいずれにも発生する。
【００９７】
図９は、本発明の第４の例示の実施形態での、第２のケースの、説明のためのＳＩＰのシグナリングパス９００を表している。図９に示すようにシグナリングパス９００はユーザーエージェント９０１−１、９０１−２、サーバー９０２−１、９０２−２、及び透過型Ｂ２ＢＵＡ９０３を含み、それらは図示するように接続され、更に２つのコールレグ９０４−１、９０４−２を含む。
【００９８】
この技術分野ではよく知られたように、ユーザーエージェント９０１−１、９０１−２は、ＳＩＰのエンドポイントである。
【００９９】
この技術分野ではよく知られたように、サーバー９０２−１、９０２−２は、ＳＩＰサーバーである。
【０１００】
上記のように、透過型Ｂ２ＢＵＡ９０３は、Ｐ−ＣｏｎＴｙｐｅヘッダー及び他のＳＩＰヘッダー上に、アドレスマッピングを実施する。 ユーザーエージェント９０１−１、９０１−２、サーバー９０２−１、９０２−２及びＢ２ＢＵＡ９０３の間のＳＩＰメッセージは、シグナリングパス９００の下に、よく知られた書き方で示されている。シグナリングパスが２以上の透過型Ｂ２ＢＵＡ（すなわち鎖状Ｂ２ＢＵＡ）で構成されている場合は、マッピングはそれぞれのＢ２ＢＵＡで発生する。このようにこの技術分野の当業者には理解できるであろうが、鎖状Ｂ２ＢＵＡの挙動は、単一Ｂ２ＢＵＡの場合の連続として見ることができる。
【０１０１】
「監視型Ｂ２ＢＵＡ」
セッションの監視は、不可視（例えばＬａｗｆｕｌ Ｉｎｔｅｒｃｅｐｔのような機能を通して）か可視（例えばＳｅｓｓｉｏｎ Ｒｅｃｏｒｄｉｎｇのような機能を通して）である。不可視の監視は、そのコールの別のエンドポイントでは検知できないようにすべきである。それゆえ監視しているエンドポイントからのシグナリングは、他のエンドポイントから秘匿される必要がある。Ｂ２ＢＵＡはこの機能を提供することができるが、Ｐ−ＣｏｎＴｙｐｅヘッダーで妥協して解決されるべきプライバシーの問題がある。
【０１０２】
監視されるコールより高い優先度を持つことで、監視が不可視な場合には、 Ｌａｗｆｕｌ ＩｎｔｅｒｃｅｐｔまたはＳｕｐｅｒｖｉｓｏｒ Ｍｏｎｉｔｏｒｉｎｇなどの機能はいかなる機能競合問題よりも優先度を持つべきである。
別の言い方では、監視は、このことが監視を原因とする競合は取り扱わないことを意味したとしても、不可視に維持されるべきである。このようなシナリオの例は、監視している参加者（以下、監視者）が、監視されているコールの一参加者のスクリーニングリストにあったときである。そのようなシナリオでは、監視者に関する機能からのＰ−ＣｏｎＴｙｐｅヘッダーが、別の参加者のコールに送信されない。また、コールのセットアップは、これが別のエンドポイントで検出されて監視を開示することになるので、機能競合（機能の１つが不能）という理由で、決して繰り返されない。その代わり、そのような競合は、監視者の機能に優先度を与えることにより解決される。
【０１０３】
監視者が監視されているコールと等しいか、より低い優先度で不可視な場合には、監視は不可能である。そのようなシナリオの例は、監視が、あるコールにおいて活性化されており、しかも、コールの監視を許さない機能（例えばＣｈｉｅｆ Ｅｘｅｃｕｔｉｖｅ Ｏｆｆｉｃｅｒなど）を有する参加者がコールに参加するときである。
【０１０４】
監視が可視なときには、プライバシーの問題は適用されない。それゆえ、Ｐ−ＣｏｎＴｙｐｅヘッダーは通常の様式でメッセージに含まれ得る。更に、機能競合の解決は、発呼端または終端としてＢ２ＢＵＡを持つコールレグについて、そのコールレグ内での機能競合がそのＢ２ＢＵＡで解決されるという追加の条件付きで、以前の例示の実施形態で記述したように実施することができる。
【０１０５】
整合させることができない複数参加者コールのコールレグをまたいでの機能競合を持つことは可能であることに注意すべきである。そのような場合には、機能競合は異なるレグで非対称に分析されるべきである。
【０１０６】
「セッションボーダーコントローラー（ＳＢＣｓ）」
ＳＢＣの主な役割は、ドメインルーティング及びエンドポイントアイデンティティを外部のエンドポイント及びシグナリング要素から秘匿することである。当然に、この役割は第４の例示の実施形態の機能競合検出のアプローチと矛盾する。特にＳＢＣは、Ｐ−ＣｏｎＴｙｐｅヘッダーの情報を転送しない。なぜならそのようにするとアイデンティティ及びそれらのアイデンティティで使用されている機能を開示するからである。
【０１０７】
しかしながら、１ドメイン内での機能競合分析は、各ドメイン内に機能競合の論理を隔離することで可能である。これは１ドメイン内で使用されるサービスの間の競合を解決するが、異なるドメインからのサービスを含むような競合を捕らえることはできない。
【０１０８】
代案として、ＳＢＣは、内部のトポロジーまたはシグナリングを開示しないやり方で機能競合のフィードバックをマッピングすることができる。例えば、ドメインの外部からの可視性を防止するために、Ｐ−ＣｏｎＴｙｐｅヘッダーからフィルターされた、隠れた機能のリストがあり得る。別の例では、公衆のエンドポイントのみがドメインの外部から可視とされる。当然ながら、そのようなアプローチのどれも、プライバシーの増加という利益と交換で、競合を取り扱う能力に影響を与えるという、トレードオフがある。この技術分野の当業者には理解できるであろうが、用いられる特定のポリシー（例えば、全てのＰ−ＣｏｎＴｙｐｅヘッダーの削除、あるＰ−ＣｏｎＴｙｐｅヘッダーのみの削除、ローカルドメイン内のみの機能競合を取り扱うこと、など）は、特定のドメインのプライバシー要求に基づく遂行決定であり、それゆえ、そのようなポリシーが、設定可能（コンフィギュラブル）であることは利点がある。
【０１０９】
この技術分野の当業者には理解できるであろうが、第４の例示の実施形態の重要なタスク（例えば、機能状態情報の維持と伝達、アドレスマッピングなど）が、１以上のＢ２ＢＵＡによって遂行されるとしても、別の実施形態ではこれらのタスクのいくつかまたは全てが１以上の別のデータ処理システム（例えば、交換機、サーバー、ＰＢＸなど）で遂行されることもあり、本発明のかかる実施形態をいかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。更に、この技術分野の当業者には理解できるであろうが、第４の例示の実施形態はＶｏＩＰテレフォニー及びＳＩＰを背景として開示されているが、第４の例示の実施形態の技術は、他の形式のテレフォニープラットホームやプロトコルにも適用可能であり、そのような、本発明の代替の実施形態をいかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【０１１０】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。「Ａを有する」は、Ａ以外のものを排除する意ではない。
【符号の説明】
【０１１１】
１１０ ｆ１：２以上のエンドポイント及び／またはブリッジド・アピアランスを有するコールＣに関する第１の機能
１２０ ｆ２：コールＣに関する第２の機能
１３０ ｆ１とｆ２は、規則１ａ−５ａまたは１ｂ−５ｂのどれかにマッチするか？
１４０ ｆ１、ｆ２両方を活性化する
１５０ ｆ１、ｆ２の両方ではなく、どちらか一つを活性化する
２０１ ｆ１が活性化される
２０２ ｆ２が呼び出される
２０３ ｆ２とｆ１が競合する
２０４ ｆ２が使用されるか？
２０５ ｆ１なしでコールを繰り返す
２０６ 次の機能
３１０ 機能ｆ１が活性化されたことを示す第一の信号を受け取る
３２０ コールの継続中に、機能ｆ２が呼び出されたことを示す第２の信号を受け取る
３３０ コールの継続中に、機能ｆ１とｆ２が競合するかどうかを決定する
３４０ 競合するか？
３５０ ｆ２を活性化する
３６０ 競合を解決する
４１０ 機能ｆ２の活性化を拒絶する
５１０ 機能ｆ１を非活性化する
５２０ 機能ｆ２を活性化する
６１０ ｆ２はｆ１より高い優先度を持つか？
６２０ 機能ｆ２の活性化を拒絶する
６３０ 機能ｆ１を非活性化する
６４０ 機能ｆ２を活性化する
７１０ コールのレグＬに関して機能が呼び出されたことを示す信号を受け取る
７２０ それに応じてレグＬに関する機能状態情報を更新する
７３０ コールのシグナリングパスにそって更新した機能状態情報を伝える
７４０ 必要に応じシグナリングパスのレグをまたいだアドレスマッピングを実施する
７５０ 機能は、同一のまたは異なるコールレグでの別の機能と競合するか？
７６０ 機能を活性化する
７７０ 競合を解決する
８１０ 次のどちらかを示す信号を受け取る。
−新たなレグがコールに追加される
−新たなレグが既にコールに追加されている
８２０ コールのシグナリングパスにそって新たなレグに関する機能状態情報を伝える
８３０ 必要に応じシグナリングパスのレグをまたいだアドレスマッピングを実施する
８４０ 既存のコールレグのどれかの機能と新たなレグのどれかの機能は競合するか？
８５０ 機能を活性化する
８６０ 競合を解決する
９０１−１ ユーザーエージェント
９０１−２ ユーザーエージェント
９０２−１ サーバー
９０２−２ サーバー
９０３ Ｂ２ＢＵＡ
【技術分野】
【０００１】
本発明は、一般的には通信に関し、特に、コールの継続中(mid-call)の機能競合（feature interaction)の検出と解決に関する。
【背景技術】
【０００２】
長年の間、広汎な通信の多様な機能が開発されてきた。例えば、コール転送、三者間コール、保留時音楽（hold on music)など。しかし複数の機能が電話のコールに採用されると、機能間の競合が、妨げられるべき方針を許可することやコールを失敗させることのような、予期しないまたは希望しない動作を引き起こすことがある。
【０００３】
例えば、ミートミー（meet me)会議機能を介してコールがセットアップされ、その後に保留時音楽機能がそのコールの継続中に活性化されたと想定すると、もし、そのコールの一人の参加者が保留状態になった場合、その他の全てのコール参加者もその音楽を聞くことになる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
通常、テレフォニープラットホームの供給者は設計の時点で機能競合を予期しようと試みる。しかし、設計時点の技術の限界として、プラットホーム供給者の設計の範囲を越えて、サードパーティが新しい機能を付加して発生するであろう、機能競合を予期することは困難である。一方で、ランタイムの機能競合の検知や解決の技術は、通常、分散化したネットワーク環境の中で維持することが難しく、コールのセットアップ間に処理するのが不可能な計算のオーバーヘッドを必要とする、詳細なモデルに頼っている。
【課題を解決するための手段】
【０００５】
本発明はコールの継続中の機能競合の検出と解決の技術を提供する。例示の実施形態では、有限状態機械とそれに相応する方法により、コールの継続中に呼び出された機能が、別のそれ以前に活性化された機能と競合している時には、それを検出し、両方の機能が同時に活性化されないことを保証する。
【０００６】
例示の実施形態の最初の技術では、後の機能の活性化を常に拒否する。一方、第２の技術では、前の機能を常に拒否する。第３の技術では、２つの機能の一つを活性化された機能として選択し、それらの機能は、それに応じて、活性化または非活性化される。例示の実施形態では、第３の技術は、機能の優先度によって、２つの機能のどちらが支配的かを決定する。
【０００７】
その例示の実施形態は、本発明の第１の例示の実施形態の方法を含む、機能競合の検出の異なる方法と組合わせて用いられる。更に、第２の例示の実施形態は、様々なネットワークトポロジーの中のＶｏＩＰ(Voice Over Internet Protocol) コールのためのコールの継続中検出を提供するための、第３の例示の実施形態の技術と組み合わせて用いられる。
【０００８】
その例示の実施形態は、第１の機能が活性化されることを示す第１の信号を受け取ること、コールの継続中に第２の機能が呼び出されることを示す第２の信号を受け取ること、そのコールの継続中に第１の機能と第２の機能が競合するかどうかを決定することを含む。
【図面の簡単な説明】
【０００９】
【図１】本発明の第１の例示の実施形態での、複数参加者(multi-party)またはブリッジド・アピアランス(bridged-appearance)コールのための機能競合を検出し、解決する方法に関するフローチャート。
【図２】本発明の第２の例示の実施形態での、コールの継続中の機能競合を検出し解決するための、有限状態機械。
【図３】本発明の第２の例示の実施形態での、図２に示される有限状態機械２００に関する方法のフローチャート。
【図４】本発明の第２の例示の実施形態での、図３に示されるタスク３５０を遂行するための第１の技術のフローチャート。
【図５】本発明の第２の例示の実施形態での、タスク３５０を遂行するための第２の技術のフローチャート。
【図６】本発明の第２の例示の実施形態での、タスク３５０を遂行するための第３の技術のフローチャート。
【図７】本発明の第３の例示の実施形態での、複数のレグのシグナリングパス(signaling path)を持つコールのための機能競合を検出し解決する、第１の方法のフローチャート。
【図８】本発明の第３の例示の実施形態での、複数のレグのシグナリングパスを持つコールのための機能競合を検出し解決する、第２の方法のフローチャート。
【図９】本発明の第４の例示の実施形態での、透過型のＢ２ＢＵＡ(Back to back user agent)から構成される、例示のシグナリングパス。
【発明を実施するための形態】
【００１０】
用語「コール」は通信端末ユーザーを巻き込む相互のコミュニケーションと定義する。コールは、従来の音声電話コール、ＶｏＩＰコール、ＳＩＰ(Session Initiation Protocol)セッション、インスタントメッセージ・セッション、テレビ会議、その他である。
【００１１】
本発明の、第１の例示の実施形態では、機能競合を検出し、解決するために、５個の基本規則を用いる。その各々は、複数参加者コールのための１変数と、ブリッジド・アピアランスを持つコールのための１変数を有する。これらの規則のいくつかは、「トリートメント」について取り扱う。「トリートメント」とは、コールの継続中のある状態（即ち、コールがさえぎられた状態、コールがブロックされた状態）を取り扱うために、ネットワークによって発せられるアナウンスまたはトーンである。潜在的には、ある特定のコールにかかわる複数のトリートメントがあり得る。例えば、ひとつの機能は、コールの継続中にある参加者をビジートリートメントに接続し、一方、第２の機能は、同じコールの継続中に、ある参加者（同じ参加者または別の参加者）をネットワーク使用不可トリートメントに接続する。
【００１２】
第１の例示の実施形態では、機能の挙動を詳細に表現するために、表現法を用いる。それは自動的な規則マッチングを容易にする付加的利益を有する。この表現法の例として、機能「コール転送」略して「ＣＦＵ」はこの表現法で以下のように表現される。
ＣＦＵ： ＴＰ：Ｃ； Ａ，Ｃ → Ａ，Ｂ
ここで
・「ＴＰ：Ｃ」は、エンドポイントＣがトリガーを発する参加者（すなわち、機能が活性化されるエンドポイント）を意味する。
・矢印の左手側の「Ａ，Ｃ」は エンドポイントＡとエンドポイントＣの間に元の接続（即ち、機能を活性化する前からのＡとＣの間の接続）があったことを意味する。「元の接続」を特許請求の範囲では、「旧接続」と称する。
・矢印の右手側の「Ａ，Ｂ」は、エンドポイントＡとエンドポイントＢの間が、結果として得られた接続（すなわちその機能が活性化された後でＡとＢの間が接続）されたことを意味する。「結果としての接続」を特許請求の範囲では、「新接続」と称する。
【００１３】
別の例では、機能「複数参加者コールへの加入」略して「ＣｏｎｆＪｏｉｎ」は、この表現法で以下のように表現される。
ＣｏｎｆＪｏｉｎ： ＴＰ：Ａ；[Ａ，Ｃ]Ａ，Ｂ → Ａ，Ｂ，Ｃ
ここで
・「ＴＰ：Ａ」は、エンドポイントＡがトリガーを発する参加者を意味し、
・矢印の左手側の「[Ａ，Ｃ]」は エンドポイントＡとエンドポイントＣの間に元の接続があり、ホールド状態になっていることを意味し、
・矢印の左手側の「Ａ，Ｂ」は エンドポイントＡとエンドポイントＢの間に元の接続があったことを意味し、
・矢印の右手側の「Ａ，Ｂ，Ｃ」は、エンドポイントＡ，Ｂ，Ｃの間が結果として接続された（すなわち、ＡとＢ、ＡとＣ、ＢとＣの間が結果として接続された）ことを意味する。
【００１４】
「複数参加者コール」
複数参加者コールの規則１ａ
ＩＦ
機能１及び機能２が、同一のトリガーを発する参加者を有する
ＡＮＤ
（機能１の結果としての接続＝機能２の結果としての接続
ＯＲ
機能１の元の接続＝機能２の元の接続）
ＴＨＥＮ
機能１と機能２は競合する。
【００１５】
複数参加者コールの規則２ａ
ＩＦ
機能１の元の接続＝機能２の結果としての接続
ＡＮＤ
機能２の元の接続＝機能１の結果としての接続
ＴＨＥＮ
機能１と機能２は競合する。
【００１６】
複数参加者コールの規則３ａ
ＩＦ
機能２がトリートメントに接続し、
ＡＮＤ
｛機能１の結果としての接続｝∩｛機能２の結果としての接続｝
≠φ
ＡＮＤ
∃Ｘ∈｛機能１の元の接続｝
∃Ｙ∈｛機能１の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］
ＯＲ
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］
ＴＨＥＮ
機能１と機能２は競合する。
【００１７】
複数参加者コールの規則４ａ
ＩＦ
｛機能１の結果としての接続｝∩｛機能２の元の接続｝
≠φ
ＡＮＤ
［∃Ｘ∈｛機能１の元の接続｝
∃Ｙ∈｛機能１の結果としての接続｝?
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］］
ＯＲ
［∃Ｘ∈｛機能２の元の接続｝
∃Ｙ∈｛機能２の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００１８】
複数参加者コールの規則５ａ
ＩＦ
機能１の元の接続＝機能２の元の接続
≠φ
ＡＮＤ
［∃Ｘ∈｛機能１の元の接続｝
∃Ｙ∈｛機能１の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する参加者（機能１）］］
ＯＲ
［∃Ｘ∈｛機能２の元の接続｝
∃Ｙ∈｛機能２の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する参加者（機能２）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００１９】
「ブリッジド・アピアランス（ＢＡｓ）」
もしエンドポイントＡがエンドポイントＢをコールし、Ｂが既にエンドポイントＣとブリッジド・アピアランスの状態の場合、Ａは、Ｂと、更にＣとも接続させられる。同様に、もしエンドポイントＢがエンドポイントＡをコールし、Ｂが既にエンドポイントＣとブリッジド・アピアランスの状態の場合は、発呼者と被呼者を逆にして同じ接続が結果として得られる。表記法を用いて、第１のケースを次のように表現する。
ＢＡ：ＴＰ：Ｂ；Ａ，Ｂ， → Ａ，Ｂ−Ｃ
ここで「Ｂ−Ｃ」はＢがＣとブリッジド・アピアランスの状態であることを示す。第２のケースを次のように表現する。
ＢＡ：ＴＰ：Ｂ；Ｂ，Ａ， → Ｂ−Ｃ，Ａ
【００２０】
以下の規則は、ブリッジド・アピアランスが既に存在するコールでの、２つの機能競合をを検出することができる。言い換えると、これらの規則はＢＡ機能の活性化の後で適用される２つの機能の間の競合がある場合に、それを検出する。
【００２１】
１以上のＢＡを有するコールに関する規則１ｂ：規則１ａと同一
ＩＦ
機能１及び機能２が同じトリガーを発する参加者を有する
ＡＮＤ
（機能１の結果としての接続＝機能２の結果としての接続
ＯＲ
機能１の元の接続＝機能２の元の接続）
ＴＨＥＮ
機能１と機能２は競合する。
【００２２】
１以上のＢＡを有するコールに関する規則２ｂ：規則２ａと同一
ＩＦ
機能１の元の接続＝機能２の結果としての接続
ＡＮＤ
機能２の元の接続＝機能１の結果としての接続
ＴＨＥＮ
機能１と機能２は競合する。
【００２３】
１以上のＢＡを有するコールに関する規則３ｂ
ＩＦ
機能２がトリートメントに接続し、
ＡＮＤ
｛ＢＡ上の参加者を含み、機能１の結果としての接続｝∩
｛ＢＡ上の参加者を含み、機能２の結果としての接続｝
≠φ
ＡＮＤ
∃Ｘ∈｛ＢＡ上の参加者を含み、機能１の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能１の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］
ＯＲ
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］
ＴＨＥＮ
機能１と機能２は競合する。
【００２４】
１以上のＢＡを有するコールに関する規則４ｂ
ＩＦ
｛ＢＡ上の参加者を含み、機能１の結果としての接続｝∩
｛ＢＡ上の参加者を含み、機能２の元の接続｝
≠φ
ＡＮＤ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能１の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能１の結果としての接続｝?
［発呼者（Ｘ）＝被呼者（Ｙ）∧
発呼者（Ｙ）＝被呼者（Ｘ）］］
ＯＲ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能２の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能２の結果としての接続｝?
［発呼者（Ｘ）＝発呼者（Ｙ）∧
被呼者（Ｘ）≠被呼者（Ｙ）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００２５】
１以上のＢＡを有するコールに関する規則５ｂ
ＩＦ
機能１の元の接続＝機能２の元の接続
≠φ
ＡＮＤ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能１の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能１の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する者（機能１）］］
ＯＲ
［∃Ｘ∈｛ＢＡ上の参加者を含み、機能２の元の接続｝
∃Ｙ∈｛ＢＡ上の参加者を含み、機能２の結果としての接続｝?
［被呼者（Ｙ）＝トリートメント ∧
発呼者（Ｘ）＝トリガーを発する者（機能２）］］
ＴＨＥＮ
機能１と機能２は競合する。
【００２６】
図１は、本発明の第１の例示の実施形態での、複数参加者またはブリッジド・アピアランスコールのための機能競合を検出し、解決する方法のフローチャートを表している。図１に表わしたどのタスクが、同時に、または表わされているのとは異なる順序で、実行され得るかは、この技術分野の当業者には、この技術開示を読んだ後では自明となる
であろう。
【００２７】
タスク１１０で、機能ｆ１は、３以上のエンドポイント、１以上のブリッジド・アピアランス、またはその両方を有するコールに関する第１の機能へと初期化される。
【００２８】
タスク１２０で、機能ｆ２はコールＣに関する第２の機能へと初期化される。
【００２９】
タスク１３０は、機能ｆ１及びｆ２が規則１ａ−５ａ及び規則１ｂ−５ｂのいずれかに合致するかどうかを決定する。この技術分野の当業者には理解できるであろうが、そのような決定を実施するのに、本分野でよく知られた様々な方法がある。例えばエクスパートシステムの規則マッチングエンジン、論理プログラム、制約充足システム、単純な網羅的探索法、など。そして、タスク１３０を実施できる本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００３０】
もしタスク１３０が機能ｆ１と機能ｆ２について規則が合致しないと決定した場合は、実行はタスク１４０に進み、そうでない場合には、実行はタスク１５０で続行される。
【００３１】
タスク１４０では、よく知られたやり方で、機能ｆ１と機能ｆ２の両方が活性化される。タスク１４０の後で、図１の方法の実行は終了する。
【００３２】
タスク１５０では、機能ｆ１と機能ｆ２の、双方ではなく一方が、よく知られたやり方で、活性化される。この技術分野の当業者には理解できるであろうが、タスク１５０が２つの機能のうちの１つを活性化のために選択する（すなわちタスク１５０が機能競合の解決を行う）方法は、種々存在する。例えば本発明のある実施形態の中で、タスク１５０が決定論的に最初に呼び出された機能を選択するかもしれないし、一方、本発明の別のある実施形態ではタスク１５０が決定論的に最後に呼び出された機能を選択するかもしれないし、更に、別のある実施形態では解決の別の方法、すなわち、以下に述べるような、そして第２の例示の実施形態と、図２から図６に関わるような別の方法が実施されるかもしれない。どんなケースでも、タスク１５０を実施することができる本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００３３】
タスク１５０の後で、図１の方法の実行は終了する。
【００３４】
この技術分野の当業者には理解できるであろうが、図１の方法は、種々のテレフォニープラットホームとプロトコル（例えばＳＩＰを基盤としたＶｏＩＰテレフォニー、公衆電話網を介した従来からの回線交換テレフォニーなど）と共同して履行され得るし、そのようなプラットホームやプロトコルのためのこの方法に基づく本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００３５】
「コールの継続中の機能競合検出・解決」
本発明の第２の例示の実施形態は、コールの継続中の機能競合の検出と解決（すなわち、コールの継続中機能競合検出・解決）を可能とする。第２の例示の実施形態の技術は、複数参加者コールやブリッジド・アピアランスを持つコールのためのコールの継続中機能競合検出・解決を提供するために、第１の例示の実施形態の技術と組み合わせることができる。
【００３６】
図２は、本発明の第２の例示の実施形態での、コールの継続中の機能競合を検出し、解決するための有限状態機械（ＦＳＭ）２００を表している。図２に示すように、有限状態機械（ＦＳＭ）２００は状態２０１から２０６で構成されている。ここで、状態２０１は開始状態であり、状態２０５及び２０６は最終状態である。有限状態機械（ＦＳＭ）２００の中の、各々の孤（または指示された端）は、最初の状態から第２の状態への正当な遷移を示し、孤上のラベルは遷移の記述を与える。
【００３７】
開始状態２０１では、機能ｆ１が活性化される。本発明のある実施形態では、開始状態２０１へはコールセットアップの前に入るであろうし、また、一方、他のある実施形態ではコールのセットアップ中に入り、更に他のある実施形態ではコールセットアップの後でコールの継続中に入る。
【００３８】
機能ｆ２がコールの継続中に呼び出された場合には、有限状態機械（ＦＳＭ）２００は、開始状態２０１を離れて状態２０２に入る。
【００３９】
状態２０２では、機能ｆ１とｆ２に関する競合のチェックが行われる。もし競合があれば、有限状態機械（ＦＳＭ）２００は状態２０２を離れ、状態２０３に入る。
【００４０】
状態２０３は、機能ｆ１または機能ｆ２がより高い優先度を有するかどうかによって、状態２０４、２０５、２０６のいずれかに遷移する。（機能の優先度、及び、機能ｆ１とｆ２の一つを選択する解決の技術については、図３から図６を参照しながら以下に詳細に記述する。）もし、機能ｆ１が機能ｆ２に対して優先であれば、状態２０３は状態２０６に遷移する。もし、機能ｆ２が機能ｆ１に対して優先であり、かつ、機能ｆ２が条件付きであれば、状態２０３は状態２０４に遷移する。もし、機能ｆ２が機能ｆ１に対して優先であり、かつ、機能ｆ２が条件なしであれば、状態２０３は状態２０５に遷移する。
【００４１】
状態２０４では、機能ｆ２が使用されているかどうかのチェックがなされる。もし、使用されていれば状態２０４は状態２０５に遷移し、そうでなければ状態２０４は状態２０６に遷移する。
【００４２】
最終状態２０５では、コールは機能ｆ１なしで繰り返される。
【００４３】
最終状態２０６では、次の機能が処理される。
【００４４】
図３は、本発明の第２の例示の実施形態での、有限状態機械（ＦＳＭ）２００に関連した方法についてのフローチャートを表している。図３の中に表現されているどのタスクが、同時に、または表現されている順序とは異なる順序で、実行され得るかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００４５】
タスク３１０では、よく知られたやり方で、機能ｆ１が活性化されたことを示す最初の信号が受け取られる。この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、この最初の信号は、スイッチによって受信され、別のある実施形態ではＰＢＸ(構内交換機)で受信され、更に別の実施形態では別のデータ処理システムから受信される。更に、この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、機能ｆ１は特定コールをかける前に、タスク３１０で活性化され、別のある実施形態では、特定コールの間に機能ｆ１が活性化される。どの場合でも、タスク３１０の実行を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００４６】
タスク３２０では、第２の信号がコールの継続中に受け取られる。その第２の信号はコールの間に機能ｆ２が呼び出されたことを示している。
【００４７】
タスク３３０は、コールの間に、機能ｆ１とｆ２が競合しているかどうかを決定する。この技術分野の当業者には理解できるであろうが、機能競合を検出する種々の方法がある。例えば、本発明のある実施形態では、機能競合は第１の例示の実施形態の規則の組から決定され、一方、別のある実施形態では、機能競合の検知は代替の技術により実施される。どんな場合でも、タスク３３０の実行を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００４８】
タスク３４０はタスク３３０の決定に基づき、分岐を行う。タスク３３０で機能ｆ１とｆ２が競合していないと決定された場合は、実行はタスク３５０に進み、そうでない場合は、実行はタスク３６０で続けられる。
【００４９】
タスク３５０では、機能ｆ２が、よく知られたやり方で活性化される。タスク３５０の後は、図３の方法の実行は終了する。
【００５０】
タスク３６０では、機能競合は解決される。この技術分野の当業者には理解できるであろうが、機能競合を解決する種々の方法がある。例えば、本発明のある実施形態では、機能競合を解決するために、以下に記述され、図４から図６に関連する、技術の一つが用いられ、別の実施形態では、機能競合を解決するために別の技術が用いられる。どんな場合でも、タスク３６０の実施が可能な本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００５１】
タスク３６０の後で、図３の方法の実行は終了する。
【００５２】
図４は、本発明の第２の例示の実施形態での、タスク３６０を実施するための第１の技術のフローチャートを表している。この第１の技術では、より早く活性化された機能（すなわち、機能ｆ１）に、他の考慮（例えば、機能ｆ１とｆ２の特性、機能ｆ１の活性化と機能ｆ２の要求の間の経過時間など）をせずに、不変の優先度が与えられる。
【００５３】
タスク４１０では、機能ｆ２の活性化は拒絶される。この技術分野の当業者には理解できるであろうが、ある実施形態では、拒絶は、なぜ機能ｆ２が活性化されなかったのかという、ある形式の通知または説明が付属するが、別の実施形態では、活性化は付属するアクションなしで拒絶される。
【００５４】
タスク４１０が完了すると、図４の技術と図３の方法は終了する。
【００５５】
図５は、本発明の第２の例示の実施形態での、タスク３６０を遂行するための第２の技術のフローチャートを表している。この第２の技術では、後に活性化された機能（すなわち機能ｆ２）は、他のことを考慮せずに、不変の優先度が与えられる。図５に表わされているどのタスクが、同時に、または表わされているのと違った順番で遂行されるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００５６】
タスク５１０で、機能ｆ１は、よく知られたやり方で、非活性化される。
【００５７】
タスク５２０で、機能ｆ２は、よく知られたやり方で、活性化される。
【００５８】
この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、タスク５１０とタスク５２０には、これらのアクションに関するある形式の通告や説明が付属するが、ある別の実施形態では、どんな通告や説明も付属しない。
【００５９】
タスク５２０が完了した後で、図５の技術及び図３の方法は終了する。
【００６０】
図６は、本発明の第２の例示の実施形態に従って、タスク３６０を遂行するための第３の技術のフローチャートを表している。この第３の技術では、機能の優先度合は、機能に付与された「優先度」によって決定される。図６に表現されているどのタスクが、同時に、または表現されているのと違った順番で遂行されるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００６１】
タスク６１０は、機能ｆ２が機能ｆ１より高い優先度を有するかどうかをチェックする。もし、有しなければ、実行はタスク６２０に進み、そうでない場合は、実行はタスク６３０で続行される。
【００６２】
タスク６２０では、機能ｆ２の活性化は拒絶される。この技術分野の当業者には理解できるであろうが、ある実施形態では、拒絶は、なぜ機能ｆ２が活性化されなかったのかという、ある形式の通知または説明が付属するが、別の実施形態では、活性化は付属するアクションなしで拒絶される。
【００６３】
タスク６２０が完了した後で、図６の技術及び図３の方法は終了する。
【００６４】
タスク６３０では、機能ｆ１は、よく知られたやり方で、非活性化される。
【００６５】
タスク６４０では、機能ｆ２は、よく知られたやり方で、活性化される。
【００６６】
この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、タスク６３０とタスク６４０には、これらのアクションに関するある形式の通告や説明が付属するが、別の実施形態では、どんな通告や説明も付属しない。
【００６７】
タスク６４０が完了した後で、図６の技術及び図３の方法は終了する。
【００６８】
この技術分野の当業者には理解できるであろうが、本発明の別の態様では、機能１と機能２の間の優先度における「同点」は、機能１よりも機能２を選択して破られることもある。そのような代替の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００６９】
この技術分野の当業者には理解できるであろうが、図３から図６の方法は、種々のテレフォニープラットホームとプロトコル（例えばＳＩＰを基盤としたＶｏＩＰテレフォニー、公衆電話網を介した従来からの回線交換テレフォニーなど）と共同して履行され得るし、そのようなプラットホームやプロトコルのためのこの方法に基づく本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７０】
「複数レグのシグナリングパスを持つコールのためのコールの継続中検出」
本発明の第３の例示の実施形態は、複数レグのシグナリングパスを持つコールのための機能競合の検出と解決を可能にする。第３の例示の実施形態の技術は、複数のエンドポイント及び／またはブリッジド・アピアランスを持つ複数レグコールについてのコールの継続中機能競合を検出し、解決するために、第１及び第２の例示の実施形態の技術と組み合わせることができる。
【００７１】
図７は、本発明の、第３の例示の実施形態での、複数レグのシグナリングパスを持つコールの機能競合を検知し、解決する第１の方法のフローチャートを表している。図７に表わされているどのタスクが、同時に、または表わされているのと違った順番で実施されるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７２】
タスク７１０では、よく知られたやり方で、複数レグのシグナリングパスを持つコールのレグＬのために、一つの機能が呼び出されることを示す信号が受け取られる。
【００７３】
タスク７２０では、レグＬに関する機能状態情報がそれに応じて更新され、ネットワークの適切なノードにストアされる。この技術分野の当業者には理解できるであろうが、本発明のある実施形態では、機能状態情報は、第４の例示の実施形態を参考にして以下に記述するように、１以上のＢ２ＢＵＡにストアされ、一方、別の実施形態では、機能状態情報は、別のタイプのノード、例えばスイッチ、サーバー、ＰＢＸなどにストアされる。どの場合でも、タスク７２０の実施を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７４】
タスク７３０では、よく知られたやり方で、更新された機能状態情報が、そのコールのシグナリングパスにそって伝送される。
【００７５】
タスク７４０では、必要に応じて、シグナリングパスのレグをクロスするアドレスマッピング(Address Mapping)が行われる。例えば、シグナリングパスにそったシグナリング要素が、そのパスの一部分にそったシグナリング要素のアドレスを削除する。このアドレス情報は通常シグナリング情報で搬送される。シグナリング要素は、別のシグナリング要素及びエンドポイントのためのアドレス情報を変更することもできる。このアドレス情報も通常シグナリング情報で搬送される。そのようなマッピングと変形(transformation)を用いて、内部のシグナリングトポロジーの詳細を外部のシグナリング要素及びエンドポイントから隠し、エンドポイントには見えないシグナリングパスへと変更することを許容する。タスク７４０でのアドレスマッピングは、機能競合検出の規則に、実際にそのコールでのエンドポイントであるという矛盾のない見方を与える。
【００７６】
タスク７５０は、呼び出された機能が、（ｉ）そのコールのシグナリングパスの異なるレグのための機能か、（ｉｉ）レグＬのための別の機能かのいずれかと、競合するかどうかをチェックする。 もし、競合していれば、実行はタスク７６０に進み、そうでなければ実行はタスク７７０で継続される。
【００７７】
タスク７６０では、よく知られたやり方で、その機能が活性化される。タスク７６０の後で、図７の方法の実行は終了する。
【００７８】
タスク７７０では、機能競合が解決される。この技術分野の当業者には理解できるであろうが、機能競合を解決する種々の手段がある。例えば、本発明のある実施形態では、図４から６を参考にして上に述べた技術の１つが、機能競合を解決するために用いられ、一方、本発明の別の実施形態では、機能競合を解決するために、別の技術が用いられる。どんな場合でも、タスク７７０の実施を可能にする本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００７９】
タスク７７０の後で、図７の方法の実行は終了する。
【００８０】
図８は、本発明の第３の例示の実施形態に従って、複数レグのシグナリングパスを有するコールに関する機能競合を検出し解決するための第２の方法に関するフローチャートを表している。 図８のどのタスクが同時に、あるいは表したのと異なる順序で、遂行されうるかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００８１】
タスク８１０では、新たなレグがコールに追加されるべきか、または、新たなレグが既にコールに追加されているか、を示す信号が受け取られる。
【００８２】
タスク８２０では、よく知られたやり方で、新たなレグのための機能状態情報がそのコールのシグナリングパスにそって伝送される。
【００８３】
タスク８３０では、必要に応じて、シグナリングパスのレグをクロスするアドレスマッピングが行われる。例えば、シグナリングパスにそったシグナリング要素が、別の方法でシグナリング情報の中で伝送されるであろう、そのパスの一部分にそったシグナリング要素のアドレスを削除する。そのようなシグナリング要素は、別の方法でシグナリング情報の中で伝送されるであろう、別のシグナリング要素及びエンドポイントのためのアドレス情報を変更することもできる。そのようなマッピングと変形は、内部のシグナリングトポロジーの詳細を外部のシグナリング要素及びエンドポイントから隠すために、また、１以上のエンドポイントには見えないシグナリングパスへと変更することを許容するために、使用される。タスク８３０でのアドレスマッピングは、機能競合検出の規則に、実際にそのコールでのエンドポイントであるという矛盾のない見方を与える。
【００８４】
タスク８４０は、新たなレグのどんな機能状態情報が、そのコールのどの現存するレグのどの機能と競合するかどうかをチェックする。もし競合するならば、実行はタスク８５０に進み、そうでなければ実行はタスク８６０で続行する。
【００８５】
タスク８５０では、よく知られたやり方で、機能が活性化される。タスク８５０の後で、図８の方法の実行は終了する。
【００８６】
タスク８６０では、機能競合が解決される。この技術分野の当業者には理解できるであろうが、機能競合を解決する種々の手段がある。例えば、本発明のある実施形態では、図４から６を参考にして上に述べた技術の１つが、機能競合を解決するために用いられ、一方、本発明の別の実施形態では、機能競合を解決するために、別の技術が用いられる。どんな場合でも、タスク８６０を実施することができる本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００８７】
タスク８６０の後で、図８の方法の実行は終了する。
【００８８】
この技術分野の当業者には理解できるであろうが、図７及び図８の方法は、種々のテレフォニープラットホームとプロトコル（例えばＳＩＰを基盤としたＶｏＩＰテレフォニー、公衆電話網を介した従来からの回線交換テレフォニーなど）と共同して履行され得るし、そのようなプラットホームやプロトコルのためのこの方法に基づく本発明の実施形態を、いかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【００８９】
「Ｂ２ＢＵＡを使ったＶｏＩＰのための実現方法」
第４の例示の実施形態は、上に述べた第１、第２、第３の例示の実施形態に従って、タスクを遂行することを可能とするＶｏＩＰコールのための実現方法を用意する。 このように第４の例示の実施形態は、コールの継続中機能競合検出・解決、複数レグのシグナリングパスを有するコール、複数参加者コール、及び、ブリッジド・アピアランスを有するコールを取り扱うことが可能である。
【００９０】
第４の例示の実施形態へのアプローチは、分散され、それがＶｏＩＰテレフォニー及びＳＩＰへの適用を容易にする。活性化された各々の機能が、ＳＩＰメッセージの中に、「トリガーを発する参加者」と「接続のタイプ」を含める。もし既にメッセージの中に１以上の記入事項があれば、それらは、現在の機能の記述に対してチェックされる。このように、必要ならどこでもアルゴリズムが実行され、中央の機能マネージャーは必要とされない。このことはそのアプローチを高度にスケラブル（拡張可能）にする。
【００９１】
ＳＩＰについては、標準のＳＩＰヘッダーは十分な詳細を提供していない。それゆえ要求される情報を伝達する追加のヘッダーが定義され、そのヘッダーはＳＩＰメッセージに含まれることができる。２つのプライベートなヘッダーが、このアプローチに必要とする情報を伝達するために定義された。 Ｐ−ＣｏｎＴｙｐｅとＰ−Ｆｏｒｗａｒｄｅｄ−Ｔｏである。Ｐ−ＣｏｎＴｙｐｅヘッダーは現在のセッションで活性化されている機能の説明を含んでおり、Ｐ−Ｆｏｒｗａｒｄｅｄ−ＴｏヘッダーはＩＮＶＩＴＥリクエストが別の参加者にリダイレクトされたときの、インバイトされた参加者のためのＩＤを含んでいる。
【００９２】
機能シークエンスの間に、現在のＳＩＰメッセージはＰ−ＣｏｎＴｙｐｅヘッダーに関してチェックされる。そのようなヘッダーが見つからない場合は、どんな別の機能も以前に活性化されておらず、従って機能競合は起こりえない。そのような場合は、新たなＰ−ＣｏｎＴｙｐｅヘッダーが、現在の機能を記述するメッセージに挿入される。例えば、転送機能に関しては、ヘッダーは次のようになる。
P-ConType: ID=Forward; TP=sip:bob@d254203.com;
OrigFrom=chris@discus.com;OrigTo=bob@d254203com;
FinalFrom=chris@discus.com;FinalTo=alice@d254203.com
【００９３】
そのヘッダーは、ＩＤのフィールド、トリガーを発した参加者、及び接続タイプを含む。ＩＤはヘッダーの中に記述される機能を特定する。ＴＰは、トリガーを発する参加者を含み、残る４つのフィールドは、接続タイプの４つのフィールドに対応する。
【００９４】
第４の例示の実施形態では、Ｂ２ＢＵＡは、機能状態とコールレグに関するシグナリング情報をストアし、保持する。また、シグナリングパスにそってこの情報を伝送する。この技術分野の当業者には理解できるであろうが、Ｂ２ＢＵＡはＳＩＰコールの両端へのユーザーエージェントとして機能し、コールの両端の間の全てのＳＩＰシグナリングを、コールの確立から終了まで、処理する責任を持つ。ＳＩＰのクライアントにとって、Ｂ２ＢＵＡは一面では、ユーザーエージェントサーバーとして機能し、他面ではユーザーエージェントクライアントとして機能する。Ｂ２ＢＵＡは、コールマネージメント（例えば、課金、自動コール切断、コール転送など）、ネットワーク相互作用（たぶんプロトコルの適応を伴う）、 ネットワーク内部の秘匿（個人アドレス、ネットワークトポロジーなど）、２コールレグ間のコーデック変換などの追加の機能も提供する。 この技術分野の当業者には理解できるであろうが、Ｂ２ＢＵＡは、透過型Ｂ２ＢＵＡであったり、監視型Ｂ２ＢＵＡであったり、または、セッションボーダーコントローラー（ＳＢＣ）として機能したりする。
【００９５】
「透過型Ｂ２ＢＵＡ」
透過型Ｂ２ＢＵＡには２つのケースがある。第１のケースは、透過型Ｂ２ＢＵＡは、Ｐ−ＣｏｎＴｙｐｅヘッダーを指示通り転送し、かつ、競合により機能が実行不可であることを送り返すことができる。これはヘッダーに何の情報変更もなく行われる。
【００９６】
第２のケースでは、透過型Ｂ２ＢＵＡはいくつかのヘッダーで情報を変更する。このことは機能競合のアプローチにインパクトを与え得る。例えば、Ｆｒｏｍ／Ｔｏ／ＲｅｑｕｅｓｔＵＲＩ内での変更を通してエンドポイントのアイデンティティを変更することにより、これらのヘッダー間のマッピング及びＰ−ＣｏｎＴｙｐｅヘッダーに含まれる情報が破壊される。その上、Ｐ−ＣｏｎＴｙｐｅヘッダーは、参加者の「以前の」アイデンティティを開示するかもしれない。そのため、Ｂ２ＢＵＡは、変更されたＳＩＰヘッダー内と同じようにＰ−ＣｏｎＴｙｐｅヘッダー内の値の上に、同じアドレスマッピングを実施する必要がある。このマッピングは上方へのメッセージ及び下方へのメッセージのいずれにも発生する。
【００９７】
図９は、本発明の第４の例示の実施形態での、第２のケースの、説明のためのＳＩＰのシグナリングパス９００を表している。図９に示すようにシグナリングパス９００はユーザーエージェント９０１−１、９０１−２、サーバー９０２−１、９０２−２、及び透過型Ｂ２ＢＵＡ９０３を含み、それらは図示するように接続され、更に２つのコールレグ９０４−１、９０４−２を含む。
【００９８】
この技術分野ではよく知られたように、ユーザーエージェント９０１−１、９０１−２は、ＳＩＰのエンドポイントである。
【００９９】
この技術分野ではよく知られたように、サーバー９０２−１、９０２−２は、ＳＩＰサーバーである。
【０１００】
上記のように、透過型Ｂ２ＢＵＡ９０３は、Ｐ−ＣｏｎＴｙｐｅヘッダー及び他のＳＩＰヘッダー上に、アドレスマッピングを実施する。 ユーザーエージェント９０１−１、９０１−２、サーバー９０２−１、９０２−２及びＢ２ＢＵＡ９０３の間のＳＩＰメッセージは、シグナリングパス９００の下に、よく知られた書き方で示されている。シグナリングパスが２以上の透過型Ｂ２ＢＵＡ（すなわち鎖状Ｂ２ＢＵＡ）で構成されている場合は、マッピングはそれぞれのＢ２ＢＵＡで発生する。このようにこの技術分野の当業者には理解できるであろうが、鎖状Ｂ２ＢＵＡの挙動は、単一Ｂ２ＢＵＡの場合の連続として見ることができる。
【０１０１】
「監視型Ｂ２ＢＵＡ」
セッションの監視は、不可視（例えばＬａｗｆｕｌ Ｉｎｔｅｒｃｅｐｔのような機能を通して）か可視（例えばＳｅｓｓｉｏｎ Ｒｅｃｏｒｄｉｎｇのような機能を通して）である。不可視の監視は、そのコールの別のエンドポイントでは検知できないようにすべきである。それゆえ監視しているエンドポイントからのシグナリングは、他のエンドポイントから秘匿される必要がある。Ｂ２ＢＵＡはこの機能を提供することができるが、Ｐ−ＣｏｎＴｙｐｅヘッダーで妥協して解決されるべきプライバシーの問題がある。
【０１０２】
監視されるコールより高い優先度を持つことで、監視が不可視な場合には、 Ｌａｗｆｕｌ ＩｎｔｅｒｃｅｐｔまたはＳｕｐｅｒｖｉｓｏｒ Ｍｏｎｉｔｏｒｉｎｇなどの機能はいかなる機能競合問題よりも優先度を持つべきである。
別の言い方では、監視は、このことが監視を原因とする競合は取り扱わないことを意味したとしても、不可視に維持されるべきである。このようなシナリオの例は、監視している参加者（以下、監視者）が、監視されているコールの一参加者のスクリーニングリストにあったときである。そのようなシナリオでは、監視者に関する機能からのＰ−ＣｏｎＴｙｐｅヘッダーが、別の参加者のコールに送信されない。また、コールのセットアップは、これが別のエンドポイントで検出されて監視を開示することになるので、機能競合（機能の１つが不能）という理由で、決して繰り返されない。その代わり、そのような競合は、監視者の機能に優先度を与えることにより解決される。
【０１０３】
監視者が監視されているコールと等しいか、より低い優先度で不可視な場合には、監視は不可能である。そのようなシナリオの例は、監視が、あるコールにおいて活性化されており、しかも、コールの監視を許さない機能（例えばＣｈｉｅｆ Ｅｘｅｃｕｔｉｖｅ Ｏｆｆｉｃｅｒなど）を有する参加者がコールに参加するときである。
【０１０４】
監視が可視なときには、プライバシーの問題は適用されない。それゆえ、Ｐ−ＣｏｎＴｙｐｅヘッダーは通常の様式でメッセージに含まれ得る。更に、機能競合の解決は、発呼端または終端としてＢ２ＢＵＡを持つコールレグについて、そのコールレグ内での機能競合がそのＢ２ＢＵＡで解決されるという追加の条件付きで、以前の例示の実施形態で記述したように実施することができる。
【０１０５】
整合させることができない複数参加者コールのコールレグをまたいでの機能競合を持つことは可能であることに注意すべきである。そのような場合には、機能競合は異なるレグで非対称に分析されるべきである。
【０１０６】
「セッションボーダーコントローラー（ＳＢＣｓ）」
ＳＢＣの主な役割は、ドメインルーティング及びエンドポイントアイデンティティを外部のエンドポイント及びシグナリング要素から秘匿することである。当然に、この役割は第４の例示の実施形態の機能競合検出のアプローチと矛盾する。特にＳＢＣは、Ｐ−ＣｏｎＴｙｐｅヘッダーの情報を転送しない。なぜならそのようにするとアイデンティティ及びそれらのアイデンティティで使用されている機能を開示するからである。
【０１０７】
しかしながら、１ドメイン内での機能競合分析は、各ドメイン内に機能競合の論理を隔離することで可能である。これは１ドメイン内で使用されるサービスの間の競合を解決するが、異なるドメインからのサービスを含むような競合を捕らえることはできない。
【０１０８】
代案として、ＳＢＣは、内部のトポロジーまたはシグナリングを開示しないやり方で機能競合のフィードバックをマッピングすることができる。例えば、ドメインの外部からの可視性を防止するために、Ｐ−ＣｏｎＴｙｐｅヘッダーからフィルターされた、隠れた機能のリストがあり得る。別の例では、公衆のエンドポイントのみがドメインの外部から可視とされる。当然ながら、そのようなアプローチのどれも、プライバシーの増加という利益と交換で、競合を取り扱う能力に影響を与えるという、トレードオフがある。この技術分野の当業者には理解できるであろうが、用いられる特定のポリシー（例えば、全てのＰ−ＣｏｎＴｙｐｅヘッダーの削除、あるＰ−ＣｏｎＴｙｐｅヘッダーのみの削除、ローカルドメイン内のみの機能競合を取り扱うこと、など）は、特定のドメインのプライバシー要求に基づく遂行決定であり、それゆえ、そのようなポリシーが、設定可能（コンフィギュラブル）であることは利点がある。
【０１０９】
この技術分野の当業者には理解できるであろうが、第４の例示の実施形態の重要なタスク（例えば、機能状態情報の維持と伝達、アドレスマッピングなど）が、１以上のＢ２ＢＵＡによって遂行されるとしても、別の実施形態ではこれらのタスクのいくつかまたは全てが１以上の別のデータ処理システム（例えば、交換機、サーバー、ＰＢＸなど）で遂行されることもあり、本発明のかかる実施形態をいかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。更に、この技術分野の当業者には理解できるであろうが、第４の例示の実施形態はＶｏＩＰテレフォニー及びＳＩＰを背景として開示されているが、第４の例示の実施形態の技術は、他の形式のテレフォニープラットホームやプロトコルにも適用可能であり、そのような、本発明の代替の実施形態をいかに実現し使用するかは、この技術分野の当業者には、この技術開示を読んだ後では自明となるであろう。
【０１１０】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。「Ａを有する」は、Ａ以外のものを排除する意ではない。
【符号の説明】
【０１１１】
１１０ ｆ１：２以上のエンドポイント及び／またはブリッジド・アピアランスを有するコールＣに関する第１の機能
１２０ ｆ２：コールＣに関する第２の機能
１３０ ｆ１とｆ２は、規則１ａ−５ａまたは１ｂ−５ｂのどれかにマッチするか？
１４０ ｆ１、ｆ２両方を活性化する
１５０ ｆ１、ｆ２の両方ではなく、どちらか一つを活性化する
２０１ ｆ１が活性化される
２０２ ｆ２が呼び出される
２０３ ｆ２とｆ１が競合する
２０４ ｆ２が使用されるか？
２０５ ｆ１なしでコールを繰り返す
２０６ 次の機能
３１０ 機能ｆ１が活性化されたことを示す第一の信号を受け取る
３２０ コールの継続中に、機能ｆ２が呼び出されたことを示す第２の信号を受け取る
３３０ コールの継続中に、機能ｆ１とｆ２が競合するかどうかを決定する
３４０ 競合するか？
３５０ ｆ２を活性化する
３６０ 競合を解決する
４１０ 機能ｆ２の活性化を拒絶する
５１０ 機能ｆ１を非活性化する
５２０ 機能ｆ２を活性化する
６１０ ｆ２はｆ１より高い優先度を持つか？
６２０ 機能ｆ２の活性化を拒絶する
６３０ 機能ｆ１を非活性化する
６４０ 機能ｆ２を活性化する
７１０ コールのレグＬに関して機能が呼び出されたことを示す信号を受け取る
７２０ それに応じてレグＬに関する機能状態情報を更新する
７３０ コールのシグナリングパスにそって更新した機能状態情報を伝える
７４０ 必要に応じシグナリングパスのレグをまたいだアドレスマッピングを実施する
７５０ 機能は、同一のまたは異なるコールレグでの別の機能と競合するか？
７６０ 機能を活性化する
７７０ 競合を解決する
８１０ 次のどちらかを示す信号を受け取る。
−新たなレグがコールに追加される
−新たなレグが既にコールに追加されている
８２０ コールのシグナリングパスにそって新たなレグに関する機能状態情報を伝える
８３０ 必要に応じシグナリングパスのレグをまたいだアドレスマッピングを実施する
８４０ 既存のコールレグのどれかの機能と新たなレグのどれかの機能は競合するか？
８５０ 機能を活性化する
８６０ 競合を解決する
９０１−１ ユーザーエージェント
９０１−２ ユーザーエージェント
９０２−１ サーバー
９０２−２ サーバー
９０３ Ｂ２ＢＵＡ
【特許請求の範囲】
【請求項１】
（Ａ）第１機能が活性化されていることを示す第１信号を受領するステップと、
（Ｂ)コールの継続中、第２機能が要求されていることを示す第２信号を受領するステップと、
（Ｃ)前記コールの継続中、前記第１機能と前記第２機能が競合しているか否かを決定するステップと
を有する
ことを特徴とする方法。
【請求項２】
（Ｄ)前記第１機能と前記第２機能が競合していないと決定した時のみ、前記第２機能を活性化するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項３】
（Ｅ)前記第１機能と前記第２機能が競合していないと決定した時に、前記第２機能を活性化するステップと
ことを特徴とする請求項１記載の方法。
【請求項４】
（Ｆ)前記第１機能と前記第２機能が競合していると決定した時に、前記第２機能を活性化することを拒否するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項５】
前記第１機能と前記第２機能が競合していると決定したが時に、
（Ｇ)前記第１機能を非活性化するステップと、
（Ｈ)前記第２機能を活性化するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項６】
（Ｉ)前記第１機能が前記第２機能と少なくとも同じ程度に高い優先度を有する時に、前記第２機能を活性化するのを拒否するステップと、
（Ｊ)それ以外の場合に、
（ｉ)前記第１機能を非活性化するステップと、
（ｉｉ)前記第２機能を活性化するステップと
を有する
ことを特徴とする請求項１記載の方法。
【請求項７】
→請求項６
ことを特徴とする請求項１記載の方法。
【請求項８】
前記第１機能は、前記コールを設定する前に、活性化する
ことを特徴とする請求項１記載の方法。
【請求項９】
前記第１機能は、前記コールを設定する前に、活性化し、
前記第１信号を前記コールの設定前に受領する
ことを特徴とする請求項１記載の方法。
【請求項１０】
前記第１機能は、前記コールを設定する前に、活性化し、
前記第１信号を前記コールの設定中に受領する
ことを特徴とする請求項１記載の方法。
【請求項１】
（Ａ）第１機能が活性化されていることを示す第１信号を受領するステップと、
（Ｂ)コールの継続中、第２機能が要求されていることを示す第２信号を受領するステップと、
（Ｃ)前記コールの継続中、前記第１機能と前記第２機能が競合しているか否かを決定するステップと
を有する
ことを特徴とする方法。
【請求項２】
（Ｄ)前記第１機能と前記第２機能が競合していないと決定した時のみ、前記第２機能を活性化するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項３】
（Ｅ)前記第１機能と前記第２機能が競合していないと決定した時に、前記第２機能を活性化するステップと
ことを特徴とする請求項１記載の方法。
【請求項４】
（Ｆ)前記第１機能と前記第２機能が競合していると決定した時に、前記第２機能を活性化することを拒否するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項５】
前記第１機能と前記第２機能が競合していると決定したが時に、
（Ｇ)前記第１機能を非活性化するステップと、
（Ｈ)前記第２機能を活性化するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項６】
（Ｉ)前記第１機能が前記第２機能と少なくとも同じ程度に高い優先度を有する時に、前記第２機能を活性化するのを拒否するステップと、
（Ｊ)それ以外の場合に、
（ｉ)前記第１機能を非活性化するステップと、
（ｉｉ)前記第２機能を活性化するステップと
を有する
ことを特徴とする請求項１記載の方法。
【請求項７】
→請求項６
ことを特徴とする請求項１記載の方法。
【請求項８】
前記第１機能は、前記コールを設定する前に、活性化する
ことを特徴とする請求項１記載の方法。
【請求項９】
前記第１機能は、前記コールを設定する前に、活性化し、
前記第１信号を前記コールの設定前に受領する
ことを特徴とする請求項１記載の方法。
【請求項１０】
前記第１機能は、前記コールを設定する前に、活性化し、
前記第１信号を前記コールの設定中に受領する
ことを特徴とする請求項１記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１０−１６６５５５（Ｐ２０１０−１６６５５５Ａ）
【公開日】平成２２年７月２９日（２０１０．７．２９）
【国際特許分類】
【出願番号】特願２００９−２７７３８１（Ｐ２００９−２７７３８１）
【出願日】平成２１年１２月７日（２００９．１２．７）
【出願人】（５０８２１４０１９）アバイア インク． (75)
【Ｆターム（参考）】
【公開日】平成２２年７月２９日（２０１０．７．２９）
【国際特許分類】
【出願日】平成２１年１２月７日（２００９．１２．７）
【出願人】（５０８２１４０１９）アバイア インク． (75)
【Ｆターム（参考）】
[ Back to top ]