(57)【特許請求の範囲】
【請求項１】
複数のプロセスを備えるインテリジェントネットワークにおいて、該プロセスの動作シーケンスが正しいことを検証する方法であって、
複数の状態を保持しイベントの入力に応じて所定の状態遷移を行う有限状態マシンに基づいてそれぞれの処理を実行するプロセスの集合を選択するステップと、
前記選択されたプロセスの集合に含まれる各プロセスにイベントを入力して、プロセスごとにその動作を検証するステップとを備え、
前記選択するステップにおいては、互いに包含関係にある複数の前記有限状態マシンに基づいてそれぞれ処理を実行するプロセスの集合であって、該プロセスがインタフェースで結ばれているものを選択する
ことを特徴とする、方法。
【請求項２】
前記プロセスの集合を選択するステップは、
前記プロセスのいずれかが、プロセスとイベントとの関係を定義する予め定められた情報に適合するか否かに基づいて前記プロセスの集合を選択する、請求項１に記載の方法。
【請求項３】
いずれかのプロセスが前記イベントを受取った場合、前記プロセスの集合を選択するステップが完了するまで、該プロセスにおける処理を待機させるステップを更に備える、請求項１又は２に記載の方法。
【請求項４】
前記プロセスの集合を選択するステップは、
前記検証するステップにおいてその動作が検証された第１の組のプロセスを選択するステップと、
該第１の組のプロセスに関係するプロセスの動作についての予備的な処理を行うステップと、
前記予備的な処理の結果に基づいて第２の組のプロセスを選択するステップと、を備える、請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記第２の組のプロセスを選択するステップは、相互に影響を及ぼす複数のプロセスが衝突しないように、他のプロセスのイベントに影響を与えるアクションを選択するステップを備える、請求項４に記載の方法。
【請求項６】
前記動作を検証するステップは、受取ったイベントの処理が終了するまでは、次のイベントの処理を行わず該次のイベントをキューに格納して待合わせさせる、ステップを備える、請求項１から５のいずれか１項に記載の方法。
【発明の詳細な説明】
この発明は、ネットワークプロトコルにおける手順を確認（ｖａｌｉｄａｔｉｏｎ）する方法に関する。特に、この発明は、欧州電気通信標準ＥＴＳ３００３７４に定義されるケイパビリティセット１（ＣＳ１）の支援に必要なインテリジェントネットワークアプリケーションプロトコル（ＩＮＡＰ）の様なネットワークプロトコルに関する。
ＩＮＡＰ  ＣＳ１の様なプロトコルにおいては、特定のタスクを遂行するため実施される幾つかの正しい手順又は動作のシーケンスが存在する。しかし、可能な手順の数が大きいので、その正しい手順は直接には定義されずに、むしろ一組の規則により定義される。これらの規則に違反しないいかなる手順又は動作のシーケンスも、そこで正しい手順と考えられる。
先行技術においては、これらの規則は、各エンティティ、及び各インタフェースに関して有限状態マシン（ｆｉｎｉｔｅ  ｓｔａｔｅ  ｍａｃｈｉｎｅ）（ＦＳＭ）を定義することにより記述することが出来、インタフェースは２つのエンティティの間の境界である。このＦＳＭは、そこで一つのプロセスの行動に対するモデルとして作用する。一つのＦＳＭは、複数の状態から成り、これらは相互に接続出来る。一つのプロセスは、いかなる１つの時においても１つの状態にあることだけが出来るが、一つの事象の結果として１つの状態から接続された一つの状態へ移動出来る。１つの状態からもう１つの状態への移行に当たり、幾つかのアクションが行われる、この様なシステムは、ＫＡＫＵＤＡ等の「特徴相互作用の動的解決方法及びその発展」、電気通信システムにおける特徴相互作用ＩＩＩ、第３特徴相互作用ワークショップにおいて提供された頁（ＦＩＷ′９，ＫＹＯＴＯ，ＪＰ，Ｏｃｔ．１１−１３，１９９５）に記載されている。
ネットワークプロトコルにおいて、手順を確認するため一つのＦＳＭを使用する時、そのＦＳＭを制御する事象がそれならそのプロトコルにおいて定義された動作であり、又は呼出し（ｃａｌｌ）プロセスの様な他のプロセスから来る他の事象がこれである。
ＩＮＡＰ  ＣＳ１の様なネットワークプロトコルにおいて正しい手順を定義するこれらの規則は、単一アソシエーション制御機能（ＳＡＣＦ）規則及び多数アソシエーション制御機能（ＭＡＣＦ）規則である。ＳＡＣＦ規則は、単一のアソシエーション（結合）がある場合に適用し、ＭＡＣＦ規則は数個の関係するアソシエーションがある場合に適用し、一つのアソシエーションは一つの信号チャネルであり、一つの特定のインタフェースを使用し、これが２つのエンティティの間の通信を可能にする。
ＳＡＣＦ規則は、単一のアソシエーション（結合）がある場合に適用し、ＭＡＣＦ規則は数個の関係するアソシエーションがある場合に適用し、一つのアソシエーションは一つの信号チャネルであり、一つの特定のインタフェースを使用し、これが２つのエンティティの間の通信を可能にする。
不幸にして、ＳＡＣＦ規則及びＭＡＣＦ規則の全部を単一のＦＳＭで正式に記述するには、一つの過度に複雑なＦＳＭが要求される。この結果は、全部のＭＡＣＦ手順を含む多くの手順は依然として自然言語で定義される。この様式の手順、即ち、アソシエーション当たり単一のＦＳＭにより特定出来ない手順に対して規則を確認する仕組みはない。
本発明は、それら規則を多数のＦＳＭにより特定することを認めることにより手順を確認する方法に関する。具体的には、各々が一つの特定のＦＳＭを走行させている数個のプロセスが、単一の事象の確認において含まれることが許される。
一つの事象の確認は、２つのフェーズで行われる。第一に、特定の判定基準を満たすかどうかを評価することにより関連するプロセスが選択される。第二の処理フェーズにおいて、選択されたプロセスの全部がその事象を処理する。
これは、一つの事象がプロセスのどれかにより処理される前に、関係するプロセスの全部が一つの安定した状態にあるという利点がある。
本発明をより良く理解するため、例として、付随する図面を参照する。
図１は、一つのコンテナ（ｃｏｎｔａｉｎｅｒ）インタフェースを共有する２つのＦＳＭの表示である。
図２は、Ａを走行させているプロセスＡｘが、Ｂを走行させている２つのプロセスＢｘ及びＢｙを含む状況を表す。
図３は、それ自身が幾つかの他のＦＳＭから成る一つのＦＳＭを表す。
図４は、セションビュー（ｓｅｓｓｉｏｎ−ｖｉｅｗ）のためのＦＳＭを表す。
図５は、呼出しビュー（ｃａｌｌ−ｖｉｅｗ）のためのＦＳＭを表す。
図６は、Ｃｐ又はＡｐのためのＦＳＭを表す。
本発明に従えば、手順の確認は、数個のプロセスを含み、この確認の第一のフェーズは、この確認に関係すべきプロセスの選択を含む。
プロセスの選択は、それぞれのエンティティ及びインタフェースを表すＦＳＭの特性及び相互関係に基づく判定基準を使用する。
第一に、ＦＳＭのどれかが「コンテナインタフェース」を共有するかどうかが決定される。図１は、一つのコンテナインタフェースを共有する２つのＦＳＭ、Ａ及びＢの表示である。２つのＦＳＭがこの形式のインタフェースを共有するときは、一方が他方に含まれると言い、今度は他方が最初のものを含む。図１のこの例において、ＦＳＭ、ＡはＦＳＭ、Ｂを含み、またＦＳＭ、ＢはＦＳＭ、Ａに含まれる。第二のＦＳＭに含まれる第一のＦＳＭは、定義により、第二のＦＳＭを含むどの第三のＦＳＭにも含まれる。即ち、もしＡがＢに含まれ、ＢがＣに含まれると、定義によりＡはＣにも含まれる。Ａは間接的にＣに含まれると言うことが出来る。別のことが述べられなければ、ここで用いられる用語「含まれる」は、直接に及び間接に含まれる両方を意味し、従って２つより多くのＦＳＭの間の関係を特定出来る。コンテナインタフェース上のアソシエーション経由するプロセス間の相互作用は、他の形式の相互作用とは異なって取扱われる。
インタフェースは、もし次のことが両方のＦＳＭに適用されればコンテナインタフェースとして分類出来る。
一つのＦＳＭが１つの他方のＦＳＭに直接に含まれるだけである。
一つのＦＳＭがそれ自身に含まれない。
一つのＦＳＭを走行させているプロセスが、最初のＦＳＭが直接含まれるＦＳＭを走行させている１つのプロセスより多くのアソシエーションを持たない。
図１に戻ると、従って、ＦＳＭ、Ｂを走行させているプロセスは、ＦＳＭ、Ａを走行させる最大１つのプロセスとアソシエーションを持つだけである。ＦＳＭ、Ａを走行させているプロセスは、しかしＦＳＭ、Ｂを走行させる数個のプロセスとアソシエーションを持つことが出来る（これらのアソシエーションは従ってＦＳＭ、Ａを走行させているプロセスにおいて関係付けられている）。Ａ又はＢは、他の（コンテナでない）インタフェースを持つことも出来る。図１において、ＦＳＭ、Ｂは１つの他のインタフェースＩ１を持つように示される。
包含関係の詳細は、ツリー（ｔｒｅｅ）の形式でシステムの中に記憶することが出来、以後ＦＳＭツリーと呼ぶ。ＦＳＭツリーの根は、どの他のＦＳＭにも含まれない一つのＦＳＭである。ＦＳＭツリーの複数の葉は、どの他のＦＳＭも包含しない複数のＦＳＭである。
包含の概念は、夫々のプロセスにも適用する：１つのプロセスはもう１つのプロセスに含まれるが、これはもし第一により走行されるＦＳＭが、第二により走行されるＦＳＭに含まれるならばである。更に、２つのプロセスは、直接か又は間接かどちらかにより、これら両方が（直接に又は間接に）結合（ａｓｓｏｃｉａｔｅｄ）している一つのプロセスを経由して結合されなければならない。例えば、図２は、Ａを走行させているプロセスＡｘが、Ｂを走行させている２つのプロセスＢｘ及びＢｙを含む状況を表す。
ＦＳＭと同様に、これらの包含関係の詳細はツリーの形式で容易にシステムの中に記憶することが出来、以後プロセスツリーと呼ぶ。プロセスツリーを走査する時、別個のデータ構造が使用出来るか、プロセス間のアソシエーションが使用出来るかのいずれかである。同一のプロセスツリー内にある一組のプロセスは、選択プロセスのための１つの根拠を形成する。
プロセスのための選択判定基準を定義するのに使用される第二の特性は、「コンテナ文脈（Ｃｏｎｔａｉｎｅｒ  Ｃｏｎｔｅｘｔ）」であり、これは一組の予め定義された値であり、確認されるべき一つに事象の異なる可能な文脈を識別している。同一のアソシエーションを使用する異なる事象は、従って異なる文脈を持つことができる。例えば、ＣＳ１において、幾つかの動作は、その呼出しに関与する単一パーテイの文脈内にある。
複数プロセスには、一つのコンテナ文脈が割当られてもよい。この場合、これが、一つの事象と一つの特定のプロセスの間の関係を識別する。
従って、一つの事象（「現行の事象」）が確認されるべき時には、現行の事象のコンテナ文脈に整合する一組のプロセスを識別することが可能である。
コンテナ文脈の割当は、各ＦＳＭに一組のコンテナ文脈、Ｆｘ＝｛ＣＣ１、ＣＣ２、．．．、ＣＣｎ｝を割当てることにより実行される。一つのコンテナ文脈は、もし一つのＦＳＭが、それが含む又はそれが含まれる一つのＦＳＭに既に割当られていれば、そのＦＳＭには割当られることは出来ない。このことはコンテナ文脈がＦＳＭに割当られる時にシステムにより検査されるべきである。一つの事象には単一のコンテナ文脈が割当られることが出来る。このコンテナ文脈は、次に現行事象にも割当られ、「現行コンテナ文脈」と呼ばれる。あるインタフェース上に到着出来る一組の事象が与えられると仮定すれば、その一組の事象のための全部の可能なコンテナ文脈は、そのインタフェースを共有するＦＳＭを含む又はそれに含まれる一つのＦＳＭに割当られたに違いない。
プロセスツリーにおける各プロセスには、Ｆｘから一つのコンテナ文脈が割当られ、これにより同一ＦＳＭを走行させる夫々異なるプロセス、及び同じプロセスツリーの一部には、夫々異なるコンテナ文脈が割当られる。
例えば、一つのプロトコルにおいて、各々がコンテナ文脈として使用できる３０個の可能なレグ−ｉｄ（ｌｅｇ−ｉｄｓ）があるかも知れない。幾つかの動作は、全体の呼出し（例えば、解除呼出し（ＲｅｌｅａｓｅＣａｌｌ））に適用し、これらはその呼出しをコンテナ文脈として持つであろう。パラメタとして一つのレグ−ｉｄを持つことの出来る一つの動作は、３０の別個の事象（各可能なレグ−ｉｄに対して１つ）として見える。これは、その動作を３０の可能性ある事象の１つへマップするためにその動作の解析を必要とする（即ち、レグ−ｉｄパラメタ、又は省略（ｄｅｆａｕｌｔ）レグ−ｉｄ値、が動作から事象へのマッピングを決定する）。
プロセスに対する選択判定基準を定義するのに使用される第三の特性は、「コンテナ作用（Ｃｏｎｔａｉｎｅｒ  Ａｃｔｉｏｎ）」であり、これは一つのＦＳＭにおける状態移行において特定できる特別な一組の作用である。これらの作用は、他のプロセスによる現行事象の処理に影響するかも知れない。例えば、これらは、もう１つのプロセスが、たとえそうする様に指定されとしてもその事象を処理しないようにさせる。
各システムは、定義された幾つかのコンテナ作用を持つであろう。コンテナ作用は他のプロセスに影響することがあるので、数個のプロセスが、相互に影響を及ぼす複数のコンテナ作用を実行する時は衝突が生じるかも知れない。システムは、これらのコンテナ作用の間の特定された明瞭な相互作用を持たねばならない。例えば、より高い優先を持つコンテナ作用は、より低い優先（現行事象に対して）を持つ全部のコンテナ作用を排除する。これらの相互作用を定義するために用いられる原理は、ここではさらに説明しない、システムは、一組のコンテナ作用が与えられると、許されるであろう小組（ｓｕｂ−ｓｅｔ）のコンテナ作用を識別することが出来ると仮定する。この小組は、以後現行「コンテナ作用」と呼ぶ。
システムが、異なるプロセスからの異なるコンテナ作用を調整出来るために、一つの事象の処理に先立って２つの段階が必要である。
第一に、その事象を処理できる一組のプロセスが与えられると、これらのプロセスが、一旦これらがその事象を処理すると実行するであろうコンテナ作用が収集される。これは、関係するプロセスによる一つの事象の予備処理が必要である：結果として生じる状態移行が決定され（これらは遂行されるであろう作用を決定するので）、しかし遂行はされない。
第二に、収集されたコンテナ作用、及びシステムにおいてそれらの間に定義された優先に基づいて、システムは、現行コンテナ作用を創作する。
一つの事象が一組のプロセスにより処理されるべき時には、同じ作用が２回実行されるのを回避するため、それらプロセスのコンテナ作用は調整されなければならない。
上の述べた様に、確認の第一のフェーズは、上述の特性に基づく判定基準を使用して、確認に関係するプロセスを選択することが含まれる。
たとえその事象をアソシエーションを経由して初期に受取るプロセスがあるとしても、その事象はそのプロセスによって直ちに処理はされないであろう。その受取るプロセスは、選択フェーズの結果として常に選択されるであろうが、それはそのプロセスがその事象を処理してよいとして選択された時だけである。
この選択フェーズの一部として、現行コンテナ文脈があるかどうかが決定される。もし現行コンテナ文脈がなければ、そのときはその事象を受取ったプロセスだけが選択される。もし現行コンテナ文脈があれば、そのときは２つの次の判定基準を満たすいかなるプロセスも選択されるであろう。第一は、そのプロセスは、コンテナ文脈を保持する一つのプロセスを保持するか、包含し、又はコンテナ文脈を保持する一つのプロセスに含まれるかのいずれかでなければならず、このことは入れ代わって、その事象を受け取ったプロセスを包含するか、又はそれに含まれなければならない。第二に、そのプロセスは、現行コンテナ作用の１つ以外にどのコンテナ作用も実行してはならない。
この選択フェーズは、その事象を受取ったプロセスを検査することにより開始する。そこから、プロセスツリーは、根の方へ及び葉の方へ走査される。走査されるあらゆるプロセスに対して、それがコンテナ文脈に整合するかどうかが調べられる。各整合するプロセスは選択に加えられる。幾つかの最適化を適用する。第一に、もし整合するプロセスが、その事象を受取ったプロセスを包含するならば、そのときはいかなる他の整合するプロセスも存在しないであろう。この理由は、もし一つのＦＳＭが、一つのコンテナ文脈が割当てられた一つのＦＳＭを既に包含するか、又はそれに含まれるならば、そのコンテナ文脈はそのＦＳＭに割当てられることは出来ないからである。第二に、もし一つの整合するプロセスが発見されていると、そのときはその同一ＦＳＭを走行させるいかなる他の整合するプロセスも存在しないであろう。
これは、少なくとも１つの整合するプロセスを与え、また、発見されたあらゆる整合するプロセスに対して、プロセスツリーは、根の方へ及び葉の方へ再び走査される。各整合するプロセスは、それが前に選択されていなければ、今や選択に加えられる。
次に、前述のように、その事象は、選択されたプロセスの全部により予備処理される。これは、現行コンテナ作用を生じる結果となり、これは代わって選択における最終の組のプロセスを決定する。
選択プロセスが正しく働くためには、あたかも完全なプロセスツリーが最初の事象が確認される前に利用出来るように見えなければならない。このことは、あらゆるＦＳＭに対して、それに割当られたいかなるコンテナ文脈に対しても一つのプロセスがプロセスツリーに存在しなければならないことを意味する（たとえそれが状態”アイドル”にあっても）。これが与えることがあるオーバヘッドは、いかなるシステムにとっても受入られない。次の方法は、要求あり次第プロセスを創作するために使用出来る。
もし、選択プロセス中にツリーの端に到達し（そのプロセスは、今後最後のプロセスと呼ぶ）、しかしこの最後のプロセスにより走行するＦＳＭ（今後最後のＦＳＭと呼ぶ）が、対応するＦＳＭツリーの根又は葉でなければ、それなら、
−根の方に走査している時、最後のＦＳＭが直接に含まれるＦＳＭに対して１つのプロセスが創作されるが、これは、もしそのＦＳＭが、現行事象に対してアイドルからの状態移行を特定した一つのＦＳＭであるか又はこれに含まれる場合であり、「アクション無し（ｎｏ  ａｃｔｉｏｎ）」以外の一つのアクションを伴う。
−葉の方に走査している時、最後のＦＳＭが直接に含まれる各ＦＳＭに対して１つ又はそれより多くのプロセスが創作され、それは現行事象に対してアイドルからの状態移行を特定した一つのＦＳＭであるか又はこれ包含し、「アクション無し」以外の一つのアクションを伴う。１つのプロセスがそのＦＳＭに対して創作されるが、これはもしそのＦｘが一つの数として現行コンテナ文脈を持つか、又はもしそのＦｘが空のときである。さもなければ、ＦＳＭのＦｘの各数に対して１つのプロセスが創作される。アソシエーションが次に各プロセスと確立され、この後に追跡が継続する。
システムは、もし状態“アイドル”において受取ったならば、各ＦＳＭに対して、どの事象に対して「アクション無し」以外のアクションを特定するかを知らなければならない。
それが状態“アイドル”にあり、またそれがいかなる他のプロセスも含まない時は、プロセスは除去されることが出来、またそれが持つコンテナインタフェース上のどのアソシエーションも解除することが出来る。プロセスが状態“アイドル”にはないが、最早いかなるアソシエーションも持たず、即ち、プロセスがぐずぐずしている状況が生じるかも知れない。システムは、これを検出出来るが、なぜならプロセスはその時は根は勿論葉だけであるからである。システムは、その場合特別の事象を発生し、例えば、「孤児にする（ｏｒｐｈａｎｅｄ）」であり、これに基づいてプロセスはアイドルに行くべきである（そうでなければ、それは誤りと考えられる）。
選択フェーズが完了し、また一群のプロセスが選択された後、各選択されたプロセスは、他の選択されたプロセスとは無関係にその事象を処理する。その事象はそれで確認されることが出来る。
複数事象は夫々異なるアソシエーションの上に到着するかも知れず、また一つの引き続く事象は、一つの前の事象が処理されて終うまでは処理出来ないので、待合せ（キューイング）が必要になる。一つの事象は、もし既に複数の事象が待合せしているか、又はもし既に一つの現行事象があれば、待合せさせられる。事象は、事象を受取ったプロセスの根の処理に対して待合せさせられる。どれくらい多くの異なる優先があるかに依存して異なる待合せが適用する。コンテナインタフェースを経由して受取られる事象は、他の様式のインタフェースを経由して受取られる事象よりも高い優先を持つ。従って、これらの事象に対する待合せは、一つの事象がもう１つの待合せから取出されることが出来る前は、空でなければならない。このことは、全部の関係するプロセスに、確認されるべき次の事象が受取られる前に相互に更新する機会を与える。
この発明は、幾つかのＦＳＭにより記述されているＩＮのためのエリクソン（Ｅｒｉｃｓｓｏｎ）ＣＳ１＋ＩＮＡＰプロトロルから取った特定の例への応用を参照してより詳細に説明する。これらＦＳＭの１つはＳＳＦ−ＦＳＭで、これはそれ自身図３に示す様に幾つかのＦＳＭから成る。
従って、セションビューＦＳＭは、呼出しビューＦＳＭを含み、これは次にＣｐ及びＡｐＦＳＭを含む。このＣｐ及びＡｐＦＳＭは、一つのインタフェースを共有するが、これはコンテナインタフェースではない。
呼出しビューＦＳＭは、呼出し及びＳＣＦ（サービス制御機能）と外部インタフェースを持つ。ＳＡＣＦ規則及びＭＡＣＦ規則に対して確認されなければならない事象が到着出来るのはこれらのインタフェース上である。
以下のコンテナ作用が識別される（優先順序に提供される）：
バッファ事象。事象は、バッファされる（バッファ機構それ自身はここでは説明されない）。誤り手順は、これに続かない。
拒否事象。事象は、拒否される。誤り手順が、これに続く。
図４は、セションビューのためのＦＳＭを表し、これはＩＮＡＰのためのＭＡＣＦ規則を特定する。そこには１つのＭＡＣＦ規則があり、数個のＳＣＦに対する数個のアソシエーションが同時に存在してもよいが、１つだけが呼出しを制御出来る。
コンテナ文脈としてセションビューを持つ動作はない。セションビューは、全部の他のＦＳＭを含むので、セションビューは常にあらゆる事象の確認に関係する。
ＳＣＦとの新しいアソシエーションは、セションビューに対するＦＳＭが状態“アイドル”、又は“監視関係”（Ｍｏｎｉｔｏｒｉｎｇ  Ｒｅｌａｔｉｏｎ）にある時だけ許される。それゆえ、セションビューに対するＦＳＭが状態“監視関係”にあると、動作“初期ＤＰ”（ＩｎｉｔｉａｌＤＰ）（これはＳＣＦとの新しいアソシエーションを開始させる）は拒否される。動作はそれで無視される。
図５は、呼出しビュープロセスのためのＦＳＭを表し、これはＳＣＦ、及び呼出しとのアソシエーションのためのＳＡＣＦ規則を特定する。ＳＣＦとのアソシエーション当たり１つの呼出しビュープロセスがある。このＦＳＭは、単一のＳＣＦプロセスから分かるように、一つの呼出しの構成を表す。
コンテナ文脈として呼出しビューを持つ少数の動作があり、例えば“解除呼出”し（ＲｅｌｅａｓｅＣａｌｌ）である。
状態：セットアップ、未定中、及び活動中は、ＢＣＳＭにおける状態に対応する。セットアップにある間は、ＳＣＦは、依然として通常のＣＣＦ手順（動作“収集情報”）を使用してユーザから数字を収集することが出来る。一旦未定中になると、最早出来ない（“収集情報”拒否される）。活動中においては、ＳＣＦは、呼出しを経路決め出来ない（“接続”は拒否される）。その呼出しは、呼出しからの一定の事象により未定中へ戻れるだけである。
一旦“代理”（Ｓｕｒｒｏｇａｔｅ）に入ると、呼出しを開始したパーテイは、その呼出しを放棄している。それでＳＣＦにとっては最早その呼出しを経路決めすることは出来ない（ＦＳＭを活動中から未定中へ移行させた呼出しからの事象は、今やアクション無しで同じ状態へ状態移行を生じさせる）。一旦“監視関係”になると、ＳＣＦは最早その呼出しを制御出来ないが、その呼出しにおいて起っている事象を監視出来る（全部の制御動作は拒否される）。注目すべきことは、“監視関係”状態に入ると、一つの事象がこのＦＳＭから発生し、セションビューへ送られる（“監視関係”への状態移行を生じさせるため）。
図６は、Ｃｐ又はＡｐのためのＦＳＭを表す。ＣｐとＡｐは、全く同一の状態を持つ。一つの呼出しビュー内においては、１つのＣｐビューだけがあり得るが、数個のＡｐビューがあってもよい。Ｃｐ又はＡｐは、Ｃｐ又はＡｐが関係する動作のために、ＳＣＦ、及び呼出しとのアソシエーションのためのＳＡＣＦ規則を特定する。
このＦＳＭは、ＳＳＦとＳＣＦとの間の同期化手順、及び呼出しパーテイと相互作用するための手順を表す（通常のＣＣＦ手順を使用する以外）。
コンテナ文脈としてＣｐ又はＡｐを持つ動作はない。ビューのうちのどちらが含まれるかは、レグ（ｌｅｇ）であるＣｐ及びＡｐに含まれるＦＳＭにより決定される。
図３に示す様に、ＣｐとＡｐの間にはインタフェースがあり、これはレグを１つのビューからもう１つへ移動させるのに使用される（事実上、それはレグに対して含まれるプロセスは解除され、新しいものが他方の側で開始されることを意味する）。
ＦＳＭにおける状態“ＷＦＩ”において、もしユーザが電話を切ると同期化は破られるかも知れないが、Ｃｐプロセス又はＡｐプロセスは、ＳＣＦと同期している（事象はＣＬＳＭプロセスから到来する）。注目すべきは、ぞれぞれ異なるＡｐプロセスはこの結果一緒に同期しておらず、またＣｐプロセスと同期しない：同期化は完全な呼出しには適用しない。
ユーザ相互作用が進行している間（ＦＳＭは状態“ユーザ相互作用ＷＦＩ”、又は“ユーザ相互作用処理”にある）、全部の動作は、“切断前方向接続”（Ｄｉｓｓｃｏｎｎｅｃｔ  Ｆｏｒｗａｒｄ  Ｃｏｎｎｅｃｔｉｏｎ）を除いてＣｐによりバッファされるであろう。このバッファは、ＦＳＭがＷＦＩ又は処理に移行して戻る時に解除される。Ａｐは、“解除呼出”しをバッファするだけであり、これは局地的に、即ち、他のＦＳＭに影響することなくバッファされるだけである。従って、Ａｐは、これのためにコンテナ作用を使用しない。
ＦＳＭが状態“処理”にあると、ＳＳＦとＳＣＦは、同時に走行し、即ち、これらは同期化されない。
Ｃｐ及びＡｐにおけるレグのための夫々のＦＳＭは、全部の状態移行、作用等を含み全く同一である。これらのＦＳＭは、アイドル状態と活動状態だけを持つ。これらのＦＳＭは、夫々の動作に対してコンテナ文脈としての役目をする。Ｃｐ及びＡｐにおける夫々のレグは全く同じであるので、また各々は１つの状態（アイドルの他に）を持つだけであるので、レグプロセスは、現存するプロセスを活動中からアイドルへ移行させ、また新しいもの（ターゲットビューにおける）をアイドルから活動中へ移行させることにより、ＡｐからＣｐへ「移動」させることが出来、この逆も可能である。
レグの位置は、従って、Ｃｐビュー、又はＡｐビューが含まれようとしているかどうかを決定する。「レグ」の概念は、呼出しにおける単一のパーテイに割当られるネットワーク資源を表す。Ａｐにおいては１つのレグだけがあり得るが、Ｃｐにおいては数個のレグがあっても良い。
これに基づいて、確認中に一つの事象を処理すべき複数プロセスの選択に使用される判定基準を決定することが可能である。
注目すべきは、コンテナインタフェースの概念は、一般に、外部トリガ（即ち、他のシステムから来たり、同じシステムの一部から来たりする）に対する一つのシステム、又は一つのシステムの一部の行動を説明するのに使用されることである。
【図１】
0004279353.tif 000002
【図２】
0004279353.tif 000003
【図３】
0004279353.tif 000004
【図４】
0004279353.tif 000005
【図５】
0004279353.tif 000006
【図６】
0004279353.tif 000007