(57)【要約】   異なるプロトコル（例えばセッション開始プロトコル（ＳＩＰ）およびＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ））を用いて作成された異なるメッセージ間の、多面的で動的で調整されたメッセージ変換が記述される。調整対象ピア間の各メッセージパタンについてかまたはメッセージのセットについて、変換セッションが確立される。着信メッセージが各自それぞれの変換セッションに相関されることにより、特定のセッションの中でメッセージを変換するために変換規則の共通のセットを用いることができるようにする。
2011524029.tif 000002
【特許請求の範囲】
【請求項１】
第１のメッセージタイプを第２のメッセージタイプに変換するシステムであって、
ピアの仕様を使用して複数の着信メッセージを処理するメッセージ受信機と、
セッション相関規則を使用して前記複数の着信メッセージをセッションにマッピングし、かつ、新しいセッションを生成するセッション相関器と、
照合規則及び現在のセッション情報を使用して前記複数の着信メッセージのうちの１つを発信メッセージに変換するために実行すべき動作のセットを判定する条件照合器と、
動作仕様を使用して複数の発信メッセージを生成する動作実行器と、
前記複数の発信メッセージを送信する送信機と、
を備えることを特徴とするシステム。
【請求項２】
前記システムは、着信セッション開始プロトコル（ＳＩＰ）メッセージを発信Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）メッセージに変換し、着信ＳＯＡＰメッセージを発信ＳＩＰメッセージに変換する
ことを特徴とする請求項１に記載のシステム。
【請求項３】
（１）前記ピアの仕様、（２）前記セッション相関規則、（３）前記照合規則、及び（４）前記動作仕様のセットを複数含むレポジトリを更に備える
ことを特徴とする請求項１に記載のシステム。
【請求項４】
複数のメッセージ変換セッションを格納するセッションレポジトリを更に備え、
各セッションはピアのセット、変換規則のセット、及び少なくとも１つの着信メッセージに関連付けられる
ことを特徴とする請求項１に記載のシステム。
【請求項５】
前記ピアのセットは、当該セットに関連付けられる任意の数のピアを有し、
前記少なくとも１つの着信メッセージは、任意の数のメッセージである
ことを特徴とする請求項４に記載のシステム。
【請求項６】
複数のプロトコル間でメッセージを送信する方法であって、
第１のプロトコルを使用する第１の着信メッセージを受信するステップと、
前記第１の着信メッセージを結合セッションに相関させるステップと、
前記第１の着信メッセージを、前記第１のプロトコルとは異なる第２のプロトコルを使用する第１の発信メッセージに変換するステップと、
前記第１の発信メッセージを送信するステップと、
前記第２のプロトコルを使用する第２の着信メッセージを受信するステップと、
前記第２の着信メッセージを前記結合セッションに相関させるステップと、
前記第２の着信メッセージを、前記第１のプロトコルを使用する第２の発信メッセージに変換するステップと、
前記第２の発信メッセージを送信するステップと、
を備えることを特徴とする方法。
【請求項７】
前記第１のプロトコルはセッション開始プロトコル（ＳＩＰ）であり、前記第２のプロトコルはＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）である
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記第１の着信メッセージを結合セッションに相関させる前記ステップは、更に、前記第１の着信メッセージを既存の結合セッションに合わせるステップを備える
ことを特徴とする請求項６に記載の方法。
【請求項９】
前記第１の着信メッセージを結合セッションに相関させる前記ステップは、更に、新しい結合セッションを生成するステップと、前記第１の着信メッセージを当該新しい結合セッションに割り当てるステップと、を備える
ことを特徴とする請求項６に記載の方法。
【請求項１０】
前記した最初の４つの受信するステップ、相関させるステップ、変換するステップ、及び送信するステップは、前記セッションの間に複数回実行される
ことを特徴とする請求項６に記載の方法。
【請求項１１】
前記した２番目の４つの受信するステップ、相関させるステップ、変換するステップ、及び送信するステップは、前記セッションの間に複数回実行される
ことを特徴とする請求項６に記載の方法。
【請求項１２】
命令を含んだコンピュータ読み取り可能な媒体であって、当該命令はプロセッサによって実行された場合に、
変換規則の複数の異なるセットのうちの１つに基づいて、受信したセッション開始プロトコル（ＳＩＰ）メッセージを対応するＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）メッセージに変換するステップと、
変換規則の前記複数の異なるセットのうちの前記１つに基づいて、受信したＳＯＡＰメッセージを対応するＳＩＰメッセージに変換するステップと、
を実行することを特徴とするコンピュータ読み取り可能な媒体。
【請求項１３】
前記受信したＳＩＰメッセージ及び前記受信したＳＯＡＰメッセージを既存の結合セッションに関連付けるステップ
を更に備えることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１４】
前記受信したＳＩＰメッセージが既存の結合セッションに相関されないと判断するステップと、
新しい結合セッションを生成するステップと、
前記受信したＳＩＰメッセージ及び前記受信したＳＯＡＰメッセージを当該新しく生成された結合セッションに関連付けるステップと、
を更に備えることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１５】
前記受信したＳＩＰメッセージ及び前記受信したＳＯＡＰメッセージに関連するセッション関連情報を格納するステップ
を更に備えることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１６】
変換規則の前記複数の異なるセットは、動的に適応可能である
ことを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に通信に関し、詳細には、通信システムにおいてメッセージを変換するための方法、デバイスおよびシステムに関する。
【背景技術】
【０００２】
通信システムは成長と進化を続けている。例えばインターネットプロトコル（ＩＰ）や接続ベースの音声通信などのような、異なるタイプの通信システムの間の変換が、急速に進歩している。最近、この進化に関連する各種の活動について述べるのに「Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ（ＮＧＮ）」という言葉が使われることがある。国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｕｎｉｏｎ（ＩＴＵ））の定義によれば、ＮＧＮは、パケットに基づくネットワークであって、（通信サービスを含む）サービスを提供することができ、そして、複数の広帯域のＱｏＳ対応トランスポート技術を利用することができ、そして、そこでは、サービス関連機能は、底流を成すトランスポート関連技術に依存しない。また、ＮＧＮは、異なるサービスプロバイダに対する無制限のアクセスをユーザに提供するであろうし、一般的な移動性をサポートするであろうし、それが次には、エンドユーザに対して一貫性のあるサービス提供をもたらすであろう。
【０００３】
いわゆる「ウェブサービス」は、ＮＧＮでは当たり前となる可能性がある、もう１つの機能である。ウェブサービスは、例えば、異なるインフラストラクチャ上に存在し、かつ、異なる会社によって運用されてもよいソフトウェアエンティティ間の相互接続性についてのメカニズムを提供する。ウェブサービスは、典型的には、例えば、Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ）、Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）およびＵｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）という一揃いの標準(standard suite)を用いて分散サービスを提供すると定義される。興味のある読者のために、ＷＳＤＬの記述がオンラインで、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００４／ＷＤ−ｗｓｄｌ２０−２００４０８０３／に「Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ）Ｖｅｒｓｉｏｎ２．０  Ｐａｒｔ  １：Ｃｏｒｅ  Ｌａｎｇｕａｇｅ，Ｗ３Ｃ  Ｗｏｒｋｉｎｇ  Ｄｒａｆｔ３，Ａｕｇｕｓｔ  ２００４」として記載されており、その開示を参照により本願に援用する。同様に、ＳＯＡＰの記述がオンラインで、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｏａｐ１２−ｐａｒｔ０／に「ＳＯＡＰ  Ｖｅｒｓｉｏｎ１．２  Ｐａｒｔ０：Ｐｒｉｍｅｒ（Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ），Ｗ３Ｃ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  ２７  Ａｐｒｉｌ  ２００７」として記載されており、その開示を参照により本願に援用する。加えて、ＵＤＤＩについては、「ＵＤＤＩ  Ｖｅｒｓｉｏｎ  ３．０．２  ＵＤＤＩ  Ｓｐｅｃ  Ｔｅｃｈｎｉｃａｌ  Ｃｏｍｍｉｔｔｅｅ  Ｄｒａｆｔ，  Ｄａｔｅｄ  ２００４１０１９」と題された標準文書が、ｈｔｔｐ：／／ｕｄｄｉ．ｏｒｇ／ｐｕｂｓ／ｕｄｄｉ＿ｖ３．ｈｔｍに記載されている。
【０００４】
ウェブサービスは、相互動作可能な機械対機械（Ｍ２Ｍ）の対話をネットワーク上でサポートするように考えられたソフトウェアシステムとして特徴付けられてもよく、そして、Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ（ＲＰＣ）のために、そして、Ｓｅｒｖｉｃｅ  Ｏｒｉｅｎｔｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＳＯＡ）システムのビルディングブロックとして、最も一般的に用いられる。ウェブサービスの手法は、ＷＳＤＬを用いてＳＯＡＰメッセージング（それは、次には、ネットワーク上でＸＭＬメッセージを交換するために用いられるプロトコルである）を記述するのだが、典型的にはトランスポートプロトコルとしてＨＴＴＰを用いる。しかし、もっと最近になって、セッション開始プロトコル（ＳＩＰ）をＳＯＡＰメッセージ用のトランスポートプロトコルとして用いることが提案されるようになってきた。ＳＩＰは、セッションを作成し、維持し、終了させるために通信分野において広く使われるプロトコルである。
【０００５】
ＳＩＰとＳＯＡＰとの人気が高まり、大手企業による標準／技術両方への投資が進展することによって、個別のプロトコル領域の境界を越えるような変換アプリケーションの作成に関連する、興味深い機会が生じるであろう。例えば、ＳＩＰとＳＯＡＰとの間の変換によって、例えば、受信されたＳＯＡＰメッセージに基づいてＳＩＰマルチメディアセッションが開始されるようなＷｅｂ  ｓｅｒｖｉｃｅｓ  ｉｎｉｔｉａｔｅｄ  ｍｕｌｔｉｍｅｄｉａ  ｓｅｓｓｉｏｎｓ（ウェブサービスが開始するマルチメディアセッション）や、ＳＩＰを通じて機能性を提供するセンサネットワークがウェブサービスとして露出されうるようなＳｅｎｓｏｒ  ｎｅｔｗｏｒｋ  ｉｎｔｅｇｒａｔｉｏｎ  ａｐｐｌｉｃａｉｔｏｎｓ（センサネットワーク統合アプリケーション）や、特定の電話番号への呼を受信した時点でＳＯＡＰサービスが起動されるようなＤｉａｌ  ｔｏ  ｓｅｒｖｉｃｅアプリケーションのようなアプリケーションが可能になる。ＳＩＰとＷｅｂ  Ｓｅｒｖｉｃｅｓ（ＳＯＡＰ）とを同時に利用する既存の解決策も存在する。しかし、これらの解決策では、とりわけ、ＳＩＰプロトコルとＳＯＡＰプロトコルとの間の統制された変換および調整（コーディネート）ができない。
【０００６】
例えば、Ｔｈｅ  ２００２  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｕｌｔｉｃｏｎｆｅｒｅｎｃｅ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅ  ａｎｄ  Ｃｏｍｐｕｔｅｒ  Ｅｎｇｉｎｅｅｒｉｎｇ，Ｉｎｔｅｒｎｅｔ  Ｃｏｍｐｕｔｉｎｇ（ＩＣ’０２），Ｊｕｎｅ  ２００２，Ｌａｓ  ＶｅｇａｓでのＧｅｏｆｆｒｅｙ  Ｆｏｘ、Ｗｅｎｊｕｎ  Ｗｕ、Ａｈｍｅｔ  Ｕｙａｒ、Ｈａｓａｎ  Ｂｕｌｕｔによる「Ａ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  Ｃｏｌｌａｂｏｒａｔｉｏｎ  ａｎｄ  Ａｕｄｉｏ／Ｖｉｄｅｏｃｏｎｆｅｒｅｎｃｉｎｇ」と題された記事の中に述べられたＸＭＬ  Ｇｌｏｂａｌ  Ｓｅｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＸＧＳＰ）は、異なるプロトコル（例えばＨ．３２３とＳＩＰとＡｃｃｅｓｓＧｒｉｄ）を用いる複数のテレビ会議クライアントおよびサーバを調整（コーディネート）する。しかし、これらのクライアントおよびサーバのすべてがＳＯＡＰを用いるわけではない。従って、ＸＧＳＰは、ＳＩＰからＳＯＡＰへ、あるいはＳＯＡＰからＳＩＰへの変換を提供せず、また、複数のＳＩＰ／ＳＯＡＰメッセージの調整も扱わない。その代わり、ＸＧＳＰは、異種のプロトコル（すなわちＸ．３２３およびＳＩＰ）を用いたクライアント−サーバ間の通信を可能にするために、ＳＯＡＰを用いる。
【０００７】
ＩＢＭ  Ｃｏｒｐｏｒａｔｉｏｎは、同社がＩＭＳ  ＳＯＡＰ  Ｇａｔｅｗａｙサーバと呼ぶ製品を提供しており、それについてはｈｔｔｐ：／／ｗｗｗ−３０６．ｉｂｍ．ｃｏｍ／ｓｏｆｔｗａｒｅ／ｄａｔａ／ｉｍｓ／ｓｏａｐ／に記述されている。ＩＢＭによるこの製品の説明によれば、ＩＭＳ  ＳＯＡＰ  Ｇａｔｅｗａｙは、ＳＯＡＰ要求がＳＩＰのアプリケーションと機能性とに到達できるようにする。クライアントアプリケーションからＳＯＡＰメッセージを受信すると、ゲートウェイは、それをＳＩＰメッセージに変換して、そのＳＩＰメッセージを，ＳＩＰネットワークにある指定されたアプリケーションまたは機能性に向かって送信する。次いでゲートウェイは、ＳＩＰからのＳＩＰ出力メッセージを受信し、それをＳＯＡＰメッセージに変換し、そしてそれがクライアントへ返信される。ＳＯＡＰメッセージのＳＩＰメッセージへの変換は、ゲートウェイによって用いられる相関器ファイルの中に記述される。しかし、このゲートウェイの中でＳＩＰメッセージのＳＯＡＰメッセージへの変換を規定する可能性は、明らかに存在しない。さらに、ＩＭＳ  ＳＯＡＰ  Ｇａｔｅｗａｙが一度にサービス提供できるアプリケーションの数は、相関器ファイルおよびバックエンドＳＩＰアプリケーションの数によって規定される。
【０００８】
Ａｖａｙａ  Ｉｎｃ．は、各種の製品を提供しているが、例えば、ｈｔｔｐ：／／ｗｗｗ．ａｖａｙａ．ｃｏｍ／に記述されているように、Ａｖａｙａ  ＳＯＡ、Ａｖａｙａ  ＳＩＰ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ、  Ａｖａｙａ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｐｒｏｃｅｓｓ  Ｍａｎａｇｅｒなどがあり、それらはウェブサービス（ＳＯＡＰ）を通じて通信のインフラストラクチャおよび機能性へのアクセスを可能にする。これらの解決策には、明らかに、ＳＩＰプロトコルを用いて通信インフラと通信する多数のサービスが含まれている。また、これらのサービスは、開発者らがＳＯＡＰ要求を用いて通信インフラにアクセスすることを可能にするウェブサービスとして一括で扱われることもある。しかし、これらのＡｖａｙａの製品には、明らかに、ＳＩＰとＳＯＡＰとの間の一般化された変換のための解決策が含まれていない。
【０００９】
従って、例えばＳＩＰからＳＯＡＰへの、および、ＳＯＡＰからＳＩＰへの、動的適応的な複数方向のメッセージ変換のためのシステムおよび方法を提供することが望ましいであろう。
【発明の概要】
【課題を解決するための手段】
【００１０】
例示的な一実施形態によれば、第１のメッセージタイプを第２のメッセージタイプに変換するシステムは、ピアの仕様を使用して複数の着信メッセージを処理するメッセージ受信機と、セッション相関規則を使用して前記複数の着信メッセージをセッションにマッピングし、かつ、新しいセッションを生成するセッション相関器と、照合規則及び現在のセッション情報を使用して前記複数の着信メッセージのうちの１つを発信メッセージに変換するために実行すべき動作のセットを判定する条件照合器と、動作仕様を使用して複数の発信メッセージを生成する動作実行器と、前記複数の発信メッセージを送信する送信機と、を備える。
【００１１】
別の例示的実施形態によれば、複数のプロトコル間でメッセージを送信する方法は、第１のプロトコルを使用する第１の着信メッセージを受信するステップと、前記第１の着信メッセージを結合セッションに相関させるステップと、前記第１の着信メッセージを、前記第１のプロトコルとは異なる第２のプロトコルを使用する第１の発信メッセージに変換するステップと、前記第１の発信メッセージを送信するステップと、前記第２のプロトコルを使用する第２の着信メッセージを受信するステップと、前記第２の着信メッセージを前記結合セッションに相関させるステップと、前記第２の着信メッセージを、前記第１のプロトコルを使用する第２の発信メッセージに変換するステップと、前記第２の発信メッセージを送信するステップと、を備える。
【００１２】
更に別の例示的実施形態によれば、コンピュータ読み取り可能な媒体は命令を含み、当該命令はプロセッサによって実行された場合に、変換規則の複数の異なるセットのうちの１つに基づいて、受信したセッション開始プロトコル（ＳＩＰ）メッセージを対応するＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）メッセージに変換するステップと、変換規則の前記複数の異なるセットのうちの別の１つに基づいて、受信したＳＯＡＰメッセージを対応するＳＩＰメッセージに変換するステップと、を実行する。
【００１３】
添付の図面は、例示的な実施形態を図示する。
【図面の簡単な説明】
【００１４】
【図１】例示する一実施形態によるＳＩＰ領域とＳＯＡＰ領域との間に配置された統合システムを示す図である。
【図２】例示する一実施形態による統合システムを示す図である。
【図３】例示する一実施形態によるセッション相関の方法を図示するフローチャートである。
【図４】別の例示する実施形態による仕様と、アプリケーションと、セッションとの間の関係を示す図である。
【図５】例示する一実施形態による例示するＰＣＣＬ仕様を示す図である。
【図６】例示する一実施形態による２つのピア間のメッセージ変換を示す図である。
【図７】例示する別の実施形態による複数のピアデバイス間のメッセージ変換を示す図である。
【図８】例示する一実施形態によるメッセージ変換の方法を図示するフローチャートである。
【発明を実施するための形態】
【００１５】
例示的な実施形態の下記の詳細記述は、添付の図面を参照する。異なる図面における同じ参照番号は、同じかまたは類似する要素を識別する。また、下記の詳細記述は、本発明を限定するものではない。そうではなく、本発明の範囲は、添付の請求項によって定義される。
【００１６】
ＳＩＰ−ＳＯＡＰの境界を越境するアプリケーションは、使いやすい統合技術を提供するために解決される必要のあるいくつかの問題に直面する。第１に、ＳＩＰ−ＳＯＡＰ統合システムは、ＳＩＰ−ＳＯＡＰ変換を達成するために、ＳＩＰプロトコルとＳＯＡＰプロトコルとの複数方向の(multi-way)変換および調整をサポートすべきである。この複数方向の変換および調整という特性は、例えば図１に概念的に示すように複数のＳＩＰおよびＳＯＡＰ当事者間のメッセージの交換を調整するという、例示的な実施形態によるＳＩＰ−ＳＯＡＰ統合システムの能力のことを言う。そこでは、ＩＭＳ（ＳＩＰ）領域１２で動作している複数のデバイス１０は、メッセージにＳＩＰ／ＳＯＡＰ統合／変換システム１８を通過させることによって、企業（ＳＯＡＰ）領域１６で動作している複数の他のデバイス１４と容易に通信することができる。加えて、複数方向の変換および調整のためのこれらの例示的なシステムおよび技術によって、ＳＩＰメッセージとＳＯＡＰメッセージとのいずれか一方によって開始されることになるメッセージの調整が可能になる。以下に詳細に記述されるであろうが、開始側のＳＩＰまたはＳＯＡＰメッセージを受信した後で、変換アプリケーションのセッションが開始され、そして、ＳＩＰおよびＳＯＡＰメッセージのセットが、これらの例示的な実施形態によってそのセッションの中で調整され変換される。
【００１７】
これらの例示的な実施形態によるシステムおよび方法に関連して動作するＳＩＰ−ＳＯＡＰ変換アプリケーションは、急速に実装される必要があることがあり、また、頻繁に修正される必要があることがある（例えば、オリンピック大会の企業インフラへのＳＩＰベースのアクセスを可能にする変換アプリケーションを考えていただきたい）。従って、これらの例示的な実施形態によるＳＩＰ−ＳＯＡＰ統合の方法およびシステムは、必ずというわけではないが、できれば動的に適応可能であることも望ましい。例示的な実施形態によるＳＩＰ−ＳＯＡＰ統合システムおよび方法のこの動的な適応可能性という特性は、複数のＳＩＰ−ＳＯＡＰ変換アプリケーションを、例えば同時に、管理するために同一の統合システムを使用できるという能力のことを指す。加えて、場合によっては、ＳＩＰ−ＳＯＡＰ変換アプリケーションの要件は、変換アプリケーションが実行されている間に変化することがある。従って、一部の例示的な実施形態は、実行中のＳＩＰ−ＳＯＡＰ変換アプリケーションを、例えばオンザフライで、動的に修正するための選択肢を有する統合システムおよび方法を提供する。
【００１８】
従って、例示的な実施形態によれば、統合システム１８によって、ＳＩＰおよびＳＯＡＰメッセージの両方向の、統制された動的な調整および変換が可能になり、それによって、さらに、統合システム１８を用いて動作する変換アプリケーションの構築が可能になる。特に、統合システム１８は、着信ＳＩＰおよびＳＯＡＰメッセージを受信することと、ＳＩＰおよびＳＯＡＰメッセージを既存のセッションまたは新たに構築されたセッションに結合することと、ＳＩＰおよびＳＯＡＰメッセージを発信ＳＩＰおよびＳＯＡＰメッセージに翻訳することと、そして、発信ＳＩＰおよびＳＯＡＰメッセージを送信することとを可能にする。さらに、システムは、ＳＩＰピアとＳＯＡＰピア(例えばクライアントおよび／またはサーバ）との間のＳＩＰおよびＳＯＡＰメッセージのセットの交換の調整を可能にする。一部の例示的な実施形態によれば、メッセージを変換して調整するための規則は、形式的な記述（言語）として規定される。変換規則および調整規則は、システム１８にプラグインされ、それが後に、言語の中に規定された規則に従ってメッセージの変換および調整を実行する。
【００１９】
図２は、例示的な実施形態による統合システムまたはデバイス１８を図示する図である。そこでは、図の左端で始まるＰｒｏｔｏｃｏｌ  Ｃｏｎｖｅｒｓｉｏｎ  ａｎｄ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＰＣＣＬ）仕様２００が、変換および調整プロセスを支配する規則を含む。この例示的な実施形態によれば、ＰＣＣＬ仕様２００は、４つのセクション、すなわち（１）調整されるピアの仕様２０２と、（２）メッセージのＰＣＣＬセッション（本書では「結合セッション」とも呼ばれる）との相関を可能にするセッション相関規則のセット２０４と、（３）メッセージ変換のために行う必要がある動作を支配する各種の条件を照合するための規則のセット２０６と、そして、（４）動作そのものの仕様２０８とを有する。これらの各セクションについて、「例示的なＰＣＣＬ仕様」の項目で以下にもっと相当詳しく記述する。加えて、当業者には理解されるであろうが、ＰＣＣＬという名前と、そのような形式的な記述／言語の使用はどちらも、これらの例示的な実施形態による統合システムと方法とを実装するための純粋に例示的なメカニズムである。
【００２０】
ＰＣＣＬ仕様は、ＰＣＣＬコンパイラ２１０によって実行可能な形式にコンパイル（あるいは他のやり方で翻訳）されるが、その形式を本書では「ＰＣＣＬアプリケーション」と呼び、それはＰＣＣＬアプリケーションレポジトリ２１２に記憶される。ＰＣＣＬアプリケーションレポジトリ２１２は、例えば、統合システム１８の中ですべて同時に実行される複数のアプリケーション２１４を含むことができる。例示的な一実施形態によれば、各ＰＣＣＬアプリケーション２１４は、ＰＣＣＬ仕様２００と同じ規則を含むけれども、統合システム１８のモジュールにプラグインされうる形式になっており、この統合システム１８は、図では「ＳＩＰ−ＷＳゲートウェイ」とも呼ばれる。各ＰＣＣＬアプリケーション２１４は、多くのメッセージ交換を同時に処理することができる。例えば、同じＰＣＣＬアプリケーション２１４が、多数のクライアントについて同時に実行されることができる。このため、この例示的実施形態による各ＰＣＣＬアプリケーション２１４は、ＰＣＣＬセッションの中でＳＩＰとＳＯＡＰとの間のメッセージ交換を調整する。統合システム（ゲートウェイ）１８は、ＳＩＰまたはＳＯＡＰメッセージを受信する度に、適切なセッションがまだ開始されていないならばＰＣＣＬアプリケーション２１４の定義を用いてＰＣＣＬセッションを作成し、あるいは、ＰＣＣＬセッションレポジトリ２２６を用いてすでにアクティブなＰＣＣＬセッションにメッセージを相関させる。従って、ＰＣＣＬアプリケーション２１４は、特に、既存のＰＣＣＬセッションにメッセージを相関させるためかまたは新たなＰＣＣＬセッションを作成するために用いられるメッセージ交換パタンとして考えることができる。ＰＣＣＬセッションを作成してメッセージを既存のセッションに相関させるためにセッション相関器２２０によって行われる例示的な手順について、図３に関して以下に記述する。
【００２１】
また、今から記述するように、ＰＣＣＬアプリケーション２１４に記憶された調整規則および変換規則が、ＳＩＰ−ＷＳゲートウェイ１８の他のモジュールによっても用いられる。例えば、メッセージ受信機２１６およびメッセージ送信機２１８は、ＰＣＣＬアプリケーション２１４を用いてその中に記憶された調整ピアの仕様を入手するインタフェースである。メッセージ受信機２１６は、受信されることになる（すなわち、Ｗｅｂ  ＳｅｒｖｉｃｅｓのＷＳＤＬ記述に関連する）ＳＯＡＰメッセージの形式（フォーマット）が自分に分かるように、この情報を用いる。メッセージ送信機２１８は、自分が送信することになるＳＯＡＰメッセージの形式と、メッセージ送信機２１８の通信相手になることになるＳＯＡＰピアおよびＳＩＰピアの位置（ＵＲＬ）とが自分に分かるように、この情報を用いる。例えば、以下に述べる着信メッセージと発信メッセージとの各種のカテゴリを考えていただきたい。
【００２２】
ＳＩＰピアから着信するＳＩＰメッセージ
これらのメッセージは新たな結合セッションを開始することができる。ゲートウェイシステム１８は、必要なすべての知識は受信されたメッセージ(ピアアドレス）に含まれているのだから、これらのメッセージについてのピアの知識をまったく必要としない。メッセージ受信機２１６がＳＩＰメッセージを受信するアドレスは、他のやり方で指定することができる。
【００２３】
ＳＩＰピアに対して発信されるＳＩＰメッセージ
これらは、ゲートウェイシステム１８が一部のＳＩＰピアに対して、例えば何らかのＰＣＣＬアプリケーションの一部として送信するメッセージである。一部のピアについては、ゲートウェイ１８は、メッセージの送信先であるアドレスを知る必要がある（例えば、この知識は、ゲートウェイ１８がＳＩＰピアとの通信を開始する、すなわち最初のメッセージをピアに送信する場合に限って必要である）。メッセージ送信機２１８は、この知識を用いて、メッセージを適切なアドレスに方向付ける。
【００２４】
ＳＯＡＰクライアントから着信するＳＯＡＰ要求メッセージ
ゲートウェイシステム１８は、受信されることになる（ＷＳＤＬ仕様を介して指定される）ＳＯＡＰメッセージの正確な形式（フォーマット）を知る必要がある。ＳＯＡＰメッセージについてのメッセージ受信機２１６は、この形式情報を用いて、受信したメッセージを解析（パース）／アンパックする。さらに、ゲートウェイシステム１８は、どのアドレス（すなわちＵＲＬ）でＳＯＡＰメッセージを受信すべきかを知る必要がある。この知識に基づいて、ゲートウェイ１８は、着信メッセージを聴取する（待ち受ける）ためにＳＯＡＰメッセージ受信機２１６を適切なＵＲＬで起動することができる。
【００２５】
ＳＯＡＰクライアントに対して発信されるＳＯＡＰ「応答」メッセージ
これらのメッセージは、上記のようにＳＯＡＰクライアントからゲートウェイシステム１８に着信するＳＯＡＰ要求メッセージへの応答である。ゲートウェイシステム１８は、応答メッセージを適切にフォーマットできるように、そして呼を発したクライアントにＳＯＡＰ応答を送信できるように、（サービスのＷＳＤＬを介して提供された）メッセージの正確な形式を知る必要がある。クライアントのアドレスは、受信したメッセージから判断できるため、必要ない。
【００２６】
ＳＯＡＰサーバ（ウェブサービスサーバ）に対して発信されるＳＯＡＰ「要求」メッセージ
ゲートウェイシステム１８は、（ＷＳＤＬ仕様を介して指定された）送信されることになるＳＯＡＰメッセージの正確な形式を知る必要がある。ＳＯＡＰ送信者はこの情報を用いて、発信メッセージを適切にパック／フォーマッティングする。さらに、メッセージ送信者がメッセージを適切なアドレスに方向付けることができるように、ウェブサービスを提供するサーバのアドレス（ＵＲＬ）も提供されるべきである。
【００２７】
ＳＯＡＰサーバから着信するＳＯＡＰ「応答」メッセージ
これらのメッセージは、上記のようにゲートウェイシステム１８からＳＯＡＰサーバへ送信されたＳＯＡＰ要求メッセージに対する応答である。これらのメッセージを構成するため、ゲートウェイシステム１８は、（サービスのＷＳＤＬを介して提供された）メッセージの正確な形式を知る必要があり、その他のデータは知る必要がない。上記のように、一部のピアは暗示的に決定されうるので（例えばメッセージ交換プロセス全体を呼び出すピアは、明示的に指定されなくてもよい）、すべてのピアがＰＣＣＬアプリケーション２１４のピア仕様部分の中に指定される必要はないということに留意されたい。
【００２８】
セッション相関器２２０は、上記のように、ＰＣＣＬアプリケーション２１４からの規則を用いて、交換されるメッセージと特定のＰＣＣＬセッション（すなわち結合セッション）との間のマッピングを判断する。記述された規則によって、新たな結合セッションの構築と、メッセージの既存のセッションへのマッピングとが可能になる。留意すべきだが、例示する実施形態によれば、ＰＣＣＬ（結合）セッションは、ＳＩＰセッションでもないし、いずれかの種類のＳＯＡＰセッションでもない。そうではなく、結合セッションは、複数のＳＩＰセッションとＳＯＡＰセッションとを相関させるためのメカニズムを統合システム１８に提供する。従って、異なるＳＩＰセッションおよびＳＯＡＰセッションに属するメッセージを、同じＰＣＣＬ（結合）セッションに結合することができる（例えば、複数のＳＩＰおよびＳＯＡＰのクライアントおよびサーバを、同じＰＣＣＬ（結合）セッションに結合することができ、それによって、異なるＳＩＰセッションとＳＯＡＰセッションとの間のデータ共有および調整が可能になる）。進行中のＰＣＣＬ（結合）セッションは、セッションレポジトリ２２６に記憶されるが、これも、セッションデータを記憶してフェッチするための機能性を提供する。ここで、セッション相関器２２０によって行われうる、詳細ではあるが純粋に例示的なプロセスについて、図３に関して記述しよう。
【００２９】
図３は、特定のＳＩＰメッセージまたはＳＯＡＰメッセージ４００をＰＣＣＬアプリケーション２１４とセッション３００（図４に示す）とに相関させ、また、ＰＣＣＬセッション３００を必要に応じて作成する例示的なプロセスを図示する。判断ブロック４０２で示すように、図３の例示的な方法には、図示される２つの異なる場合が存在する。第１の場合（判断ブロック４０２から右方向に出る分岐）には、メッセージ４００が到着したときにアクティブであるＰＣＣＬセッション３００は存在しない。この場合、新たなＰＣＣＬセッション３００を作成することが必要である。これは、図３に示すようにステップ４０３、４０４、４０６、４０８、４１０を反復することによって達成される。この反復プロセスの目標は、セッション相関規則および条件照合規則が受信したメッセージ４００に適用可能であるようなＰＣＣＬアプリケーション２１４を全て発見し、そして、これらのＰＣＣＬアプリケーション２１４について新たなセッションを作成することである。ステップ４０３では、すべてのＰＣＣＬアプリケーション２１４が、チェックされていない。次いで、ステップ４０４で、チェックされていない１つのＰＣＣＬアプリケーション２１４が、試行セッションおよび条件照合プロセス用に選択される。ステップ４０６で、新たなセッション３００が作成され（すなわち、選択されたＰＣＣＬアプリケーション２１４からインスタンスとして作成され）、そして、選択されたＰＣＣＬアプリケーション２１４の条件照合規則を受信したメッセージ４００に適用することによって、その新たなセッションがテストされる。受信したメッセージ４００が規則に合致しない場合には、ステップ４０８が、新たに作成されたセッション３００を削除し、それが検討済みであることを示すために、選択されたＰＣＣＬアプリケーション２１４をチェック（マーク）する。そうでない場合は、新たに作成されたセッション３００は維持される。ステップ４１０は、ＰＣＣＬアプリケーションレポジトリからのすべてのＰＣＣＬアプリケーション２１４が、受信したメッセージ４００と合致する可能性があるものとして検討されることを保証する。
【００３０】
他方、メッセージ４００を受信したときにすでにいくつかのＰＣＣＬセッション３００が存在する場合には、処理フローはブロック４０２を左方向に出る経路をたどる。その場合、ステップ４２０乃至４２８を含むループで示すように、既存のＰＣＣＬセッション３００のＰＣＣＬアプリケーション２１４が、それらが受信したメッセージ４００を認識できるかどうか判断するためにチェックされる。メッセージ４００が特定のセッション３００に属すると（すなわち、受信したＳＩＰヘッダまたはＳＯＡＰメッセージの内容に基づいて）認識される場合には、そのメッセージ４００が特定のＰＣＣＬセッション３００とステップ４３０で相関される。すべてのＰＣＣＬセッション３００が、ループ４２０乃至４２８を介して相関が見つかるまで（そのとき、フローはブロック４１９へ進む）かまたは、それ以上チェックされるＰＣＣＬセッションがなくなるまで、チェックされる。受信したメッセージ４００が既存のＰＣＣＬセッション３００のいずれとも相関できない場合には、フローは、あたかも既存のセッションがまったくないかのようにメッセージ４００を処理するために、すなわち、既存のＰＣＣＬアプリケーション２１４に基づいて新たなセッションを作成するために、ブロック４０４へと進む。
【００３１】
図２に示す例示する統合システム１８に戻ると、条件照合器２２２は、ＰＣＣＬアプリケーション２１４の条件照合規則を用いて、例えばＳＩＰからＳＯＡＰへ、またはＳＯＡＰからＳＩＰへといった特定の変換を行うために実行されることになる動作セットについて決定を行う。ＰＣＣＬアプリケーション２１４の中の対応するセクションによって提供される照合規則は、メッセージの内容とセッションレポジトリ２２６とに対してチェックされる条件を指定する。動作実行器２２４は、ＰＣＣＬアプリケーション２１４からの動作規則を用いて、動作を実行する（すなわち、実際に変換を行う）。ＰＣＣＬアプリケーション２１４の対応するセクションによって提供される動作規則は、例えば、（１）何らかのデータをメッセージから抽出して、それらをセッションレポジトリ２２６に記憶するための動作と、（２）何らかのデータをセッションレポジトリ２２６から入手して、それを発信メッセージに入力するための動作と、（３）発信ＳＩＰメッセージおよび／またはＳＯＡＰメッセージを生成するための動作と、そして、（４）特定のＰＣＣＬ（結合）セッションを明確に終了させる動作とのような、少なくとも４つのタイプの動作をサポートしてもよい。図２に示す諸要素間の相互作用をよりよく理解するために、特定の（しかし純粋に例示的な）例示するメッセージ変換のセットを、以下の「例示的なメッセージ変換」という題の見出しに続いて提供する。
【００３２】
例示的なＰＣＣＬ仕様
前述したように、例示的な実施形態によれば、統合システム１８および対応する方法が、Ｐｒｏｔｏｃｏｌ  Ｃｏｎｖｅｒｓｉｏｎ  ａｎｄ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＰＣＣＬ）を用いて、ＳＩＰメッセージをＳＯＡＰウェブサービスのメッセージに変換し、その逆方向の動作も同様に行うようなシステムを作成することができる。さらに、そのような言語は、複数のＳＩＰメッセージおよびＳＯＡＰメッセージを所定のメッセージ交換パタンへと調整することを可能にする。言語は、受信したＳＩＰメッセージからＳＯＡＰメッセージを作成して起動するための、かつ、その逆方向の動作も同様に行うための規則を定義することによって、この機能性を提供する。また、これらの例示的な実施形態によれば、ＰＣＣＬは、例えばアクティブなセッションデータを指定することによって、ＳＩＰのステートフルネスとＳＯＡＰのステートレスネスとの間のギャップの橋渡しをすることにも責任を持つ。例示的な一実施形態によれば、ＰＣＣＬ言語は、ＸＭＬに基づいているが、それは、ＸＭＬが普及しており、解析が容易で、かつ、人間が読むことができるからである。ＰＣＣＬは、ＳＩＰメッセージとＳＯＡＰメッセージとを、それらのヘッダと本体とから特定のデータを抽出して新たなＳＩＰメッセージとＳＯＡＰメッセージとを例えば「ｉｆ  ｃｏｎｄｉｔｉｏｎ  ｔｈｅｎ  ａｃｔｉｏｎ（条件が満たされれば動作を実行する）」規則を用いて作成することによって、処理する。
【００３３】
例示的な実施形態によって用いられうるＰＣＣＬをよりよく理解するために、表１は、例示的なＰＣＣＬ仕様２００の概要を示す。前述のように、この例示的な実施形態によるＰＣＣＬ仕様２００は、４つのセクション、すなわち、「Ｃｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓ（調整対象ピア）」と、「Ｓｅｓｓｉｏｎ（セッション）」と、「Ｃｏｎｄｉｔｉｏｎｓ（条件）」と、「Ａｃｔｉｏｎｓ（動作）」とを含み、それらは、＜ＰＣＣＬ＞のタグに中に含まれる。これらのＰＣＣＬセクションの各々について、以下でさらに記述する。
【００３４】
【表１】
2011524029.tif 000003
【００３５】
図４は、ＰＣＣＬ仕様２００とアプリケーション２１４とセッションとの間の例示的な関係を示す。前述のように、ＰＣＣＬ仕様２００は、ＰＣＣＬ言語を用いたＳＩＰプロトコルとＳＯＡＰプロトコルとの間の変換および調整について記述するものであり、ＰＣＣＬアプリケーション２１４は、ＰＣＣＬ仕様２００をコンパイルした形式である。ＰＣＣＬセッション３００は、現在実行中のＰＣＣＬアプリケーションのインスタンスである。同じＰＣＣＬアプリケーション２１４のＰＣＣＬセッション３００は、典型的には、同じアプリケーションロジック、すなわち、同じ「Ｃｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓ」と、「Ｓｅｓｓｉｏｎ」と、「Ｃｏｎｄｉｔｉｏｎｓ」と、「Ａｃｔｉｏｎｓ」とのセクションを共有する一方で、各ＰＣＣＬセッション３００は、典型的には、異なるセッションデータ（例えば、セッションの内部状態を保持する変数としてのデータ）を有する。例えば、図３のＰＣＣＬセッション１−１は、その寿命（メッセージ変換）の終点に近くてもよいだろうし、他方、ＰＣＣＬセッション１−２は、まさに開始されたところであってもよいだろう。従って、例示的な一実施形態によれば、各ＰＣＣＬ仕様２００に関連する１つのＰＣＣＬアプリケーション２１４が存在し、各ＰＣＣＬアプリケーション２１４についてゼロ個以上のＰＣＣＬセッション３００が存在しうる。
【００３６】
このように、例示的な実施形態によれば、ＰＣＣＬセッション３００は一般に、複数のＳＩＰメッセージおよびＳＯＡＰメッセージを１つのＰＣＣＬアプリケーション（メッセージ交換パタン）に相関させるために用いられる。ＰＣＣＬセッション３００は必ずしもＳＩＰセッションに直接関連しないが、ＳＩＰの中で用いられるセッション識別メカニズムの一部を使ってもよい。例えば、ＰＣＣＬセッション３００は、セッション相関プロセスを行う際にＣａｌｌ−ＩＤ  ＳＩＰヘッダを利用してもよい。他方、ＳＯＡＰは、固有のセッションサポートをまったく有していない。しかしＳＯＡＰは、要求メッセージと対応する応答メッセージとを相関させる要求−応答アーキテクチャを用いる。ＰＣＣＬセッション３００は、ＰＣＣＬ仕様２００のセッションのセクションに規定されている規則に基づいて識別される。規則は、ＰＣＣＬセッション３００を識別するために、ＳＩＰメッセージヘッダ（すなわちＣａｌｌ−ＩＤ）とＳＯＡＰメッセージパラメータとを用いる。ここで、例示的なＰＣＣＬ仕様２００またはＰＣＣＬアプリケーション２１４の中の４つのセクションの各々について、以下に例を挙げて詳細に記述しよう。
【００３７】
上記のように、Ｃｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓのセクションは、ＰＣＣＬアプリケーション２１４の中で調整されるピアを定義する。この文脈では、ピアは、ＳＩＰメッセージおよび／またはＳＯＡＰメッセージを用いてＳＩＰ−ＷＳゲートウェイ（統合システム１８）と通信する外部システムである。表２は、例示的なＣｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓセクションの概要を示す。
【００３８】
【表２】
2011524029.tif 000004
【００３９】
ＳＩＰピアは、例えば、ＳＩＰクライアントでもＳＩＰサーバでもよいし、場合によっては、Ｃｏｏｒｄｉｎａｔｅｄ  ＰｅｅｒｓセクションからＳＩＰクライアントに関する情報を検索取得することも不要である。例えば、統合システム１８が最初のアプリケーションメッセージをＳＩＰクライアントから受信するとき、送信者のアドレスがメッセージ自身に含まれていることから、統合システム１８には自動的に送信者のアドレスが分かる。しかし、着信ＳＩＰメッセージを事前に受信することなく発信ＳＩＰメッセージが作成されるとき（すなわち、ＳＯＡＰメッセージを受信した時点でＳＩＰメッセージを作成するとき）、典型的には、Ｃｏｏｒｄｉｎａｔｅｄ  ＰｅｅｒｓのセクションからＳＩＰピア情報が必要とされるであろう。
【００４０】
表３は、例示的実施形態によるＳＩＰピアの定義を示す。ＳＩＰピアは、ピアの名前と、ＳＩＰピアのアドレスと、そのピアのＳＩＰ聴取ポートとを定義する。ピアの名前は、ＰＣＣＬ仕様２１４の残りのセクションの中でピアの参照として用いられる。
【００４１】
【表３】
2011524029.tif 000005
【００４２】
同様に、ＳＯＡＰピアは、典型的には、ＳＯＡＰクライアントまたはＳＯＡＰサービスである。アプリケーションが通信するＳＯＡＰクライアントおよびサービスは、ＰＣＣＬアプリケーション２１４のＣｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓセクションの中で定義されるべきである。これは、ＳＯＡＰが各ＳＯＡＰメッセージの完全なメッセージ内容を定義するのではないからである。そうではなく、ＳＯＡＰは、メッセージの内容についてのホルダを定義する。特定のＳＯＡＰメッセージの正確な内容は、ＷＳＤＬによって定義される。従って、外部のＳＯＡＰサービスについては、Ｃｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓセクションが、アドレスと、送信されたＳＯＡＰメッセージの実際の内容を記述するＷＳＤＬとを定義する。さらに、ＳＯＡＰクライアントについては、Ｃｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓのセクションは、適切なＳＯＡＰメッセージをクライアントが作成することができるようにするために統合システム１８が実装するサービスのＷＳＤＬを定義する。表４は、例示する一実施形態によるウェブサービスインタフェースを定義するＳＯＡＰピアを示す。各ウェブサービスの定義は名前と、ＷＳＤＬの位置と、サービスの位置と、ウェブサービスのホストのアドレスとを有する。ウェブサービスの名前は、ＰＣＣＬ仕様２１４の残りのセクションの中で参照として用いられる。
【００４３】
【表４】
2011524029.tif 000006
【００４４】
図２に関して上述したように、ＰＣＣＬアプリケーション２１４のＣｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓのセクションによって提供されるピアの定義は、例えば、ＳｅｓｓｉｏｎとＣｏｎｄｉｔｉｏｎｓとＡｃｔｉｏｎｓとのセクションの中で用いられる。Ａｃｔｉｏｎｓのセクションは、ＳＩＰピアの定義を用いて、発信ＳＩＰメッセージを作成する。ＳｅｓｓｉｏｎのセクションとＣｏｎｄｉｔｉｏｎｓのセクションとは、ＳＯＡＰピアの定義を用いて、メッセージを処理することになるＰＣＣＬアプリケーションとセッションとを識別し、他方、Ａｃｔｉｏｎｓのセクションは、ＳＯＡＰピアの定義を用いて、発信ＳＯＡＰメッセージを作成する。ＰＣＣＬ仕様２００（およびＰＣＣＬアプリケーション２１４）では、調整対象ピアの定義が、名前の参照として用いられる。例えば、ピアＰ１を指定した後、特定のメッセージがピアＰ１から来る必要があることをセッション相関規則の中に記述することもできるであろう。他方、ピアの同じ定義が、セッション相関器２２０と、条件照合器２２２と、動作実行器２２４との中で、実際のメッセージ変換タスクをどのように実行するかに関する命令として用いられてもよい。
【００４５】
上述のように、ＳｅｓｓｉｏｎのセクションはＰＣＣＬセッション３００の定義を含み、これには例えば、ＳＩＰメッセージとＳＯＡＰメッセージとからのデータを記憶する変数と、任意で、セッション状態を維持する追加の変数とが含まれる。表５は、例示的な一実施形態による例示的なＳｅｓｓｉｏｎのセクションの概要を示す。
【００４６】
【表５】
2011524029.tif 000007
【００４７】
セッション状態に関連する追加の変数に関して、下記の例を考えてみよう。ゲートウェイシステム１８によって処理されているメッセージ交換パタンが、１２個のメッセージ（ＳＩＰおよび／またはＳＯＡＰ）を含んでいると仮定しよう。このメッセージ交換パタンの調整の間、ゲートウェイシステム１８は、何個のメッセージがすでに受信されたかということと、次に受信されることになるメッセージのＩＤとを知る必要があるであろう。このタイプの情報を、「ｓｅｓｓｉｏｎＳｔａｔｅ」と呼ばれる追加のＰＣＣＬセッション変数の中に記憶することができる。交換パタンの第１のメッセージを受信した後、ゲートウェイシステム１８は「ｓｅｓｓｉｏｎＳｔａｔｅ＝ｆｉｒｓｔＲｅｃｅｉｖｅｄ」を設定することができ、第２のメッセージを送信した後、ゲートウェイシステム１８は「ｓｅｓｓｉｏｎＳｔａｔｅ＝ｓｅｃｏｎｄＳｅｎｔ」を設定することができ、以下同様である。このセッション変数を、行われるべき動作のセットを判断するための条件照合プロセスの一部として、後で用いることができる。また、この例から分かるように、セッション変数「ｓｅｓｓｉｏｎＳｔａｔｅ」は、メッセージを介して受信したデータをまったく記憶せず、それよりむしろ、メッセージ交換パタンの全体的な状態を示すデータを保持する。もちろん、もっと複雑なメッセージ交換パタンでは、もっと多くの状態変数が存在しうるであろう。
【００４８】
以下の表６は、Ｓｅｓｓｉｏｎのセクションの一例を示す。例示的な一実施形態によれば、Ｓｅｓｓｉｏｎのセクションは名前を持ち、その名前は、セッションデータにアクセスするときの名前空間の参照としてＰＣＣＬ仕様２００の残りの中で用いられる。Ｓｅｓｓｉｏｎのセクションの中の各変数は、名前とタイプとによって識別される。変数がＰＣＣＬセッション識別子として用いられる場合には、ＳＩＰメッセージまたはＳＯＡＰメッセージの中の識別子の位置が提供される。ＳＩＰメッセージに基づく識別子は、ＳＩＰヘッダの名前だけを必要とするが、ＳＯＡＰメッセージに基づく識別子は、ウェブサービス名とオペレーションと（ＷＳＤＬを通じてＣｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓのセクションの中に定義される）ＳＯＡＰメッセージのタイプとが必要である。
【００４９】
【表６】
2011524029.tif 000008
【００５０】
ＰＣＣＬ仕様２００またはＰＣＣＬアプリケーション２１４のＣｏｎｄｉｔｉｏｎｓのセクションは、動作を起動させるための「ｉｆ  ｃｏｎｄｉｔｉｏｎ  ｔｈｅｎ  ａｃｔｉｏｎ」規則の条件部分を定義する。以下の表７は、Ｃｏｎｄｉｔｉｏｎｓのセクションの概要を示す。この例示的な実施形態によれば、Ｃｏｎｄｉｔｉｏｎｓのセクションは、２つのプロトコルブロックを含む。一方のプロトコルブロックは、ＳＩＰメッセージについての照合を定義し、他方は、ＳＯＡＰメッセージについての照合を定義する。
【００５１】
【表７】
2011524029.tif 000009
【００５２】
Ｃｏｎｄｉｔｉｏｎｓのセクションの中の各プロトコルブロックは、メッセージブロックを含む。メッセージブロックは、メッセージに適用される規則を含む。例えば、以下の表８に示す例示的なメッセージブロックは、すべてのＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージに合致する照合規則を定義する。ＳＩＰメッセージブロックの別の部分要素は、追加の照合要件を指定する。例えば、１つの部分要素は、ＳＩＰ  Ｅｘｐｉｒｅｓヘッダの内容が１より大きい場合に限って受信メッセージ４００が特定のメッセージブロックに合致することを指定できるであろう。
【００５３】
【表８】
2011524029.tif 000010
【００５４】
例示的な実施形態によれば、ＳＯＡＰメッセージブロックは、Ｃｏｎｄｉｔｉｏｎｓのセクションの中でＳＩＰメッセージブロックとは異なるかたちで示されてもよい。例えば、ＳＯＡＰメッセージブロックは、Ｃｏｏｒｄｉｎａｔｅｄ  Ｐｅｅｒｓのセクションの中で定義されるウェブサービス名と、動作の名前と、メッセージタイプとを含む。ＳＯＡＰメッセージブロックの一例を、以下の表９に示す。
【００５５】
【表９】
2011524029.tif 000011
【００５６】
ＰＣＣＬシンタックスによって、ＳＩＰおよび／またはＳＯＡＰメッセージの部分を、セッションデータの中に記憶されている固定値と比較可能なような照合規則の定義が可能になる。ＰＣＣＬ仕様２００およびＰＣＣＬアプリケーション２１４のＣｏｎｄｉｔｉｏｎｓのセクションの中に提供されるメッセージブロックのもう１つの部分要素は、メッセージがメッセージブロックに一致する場合に実行されるべき動作のセットである。例えば、以下の表１０に示すＣｏｎｄｉｔｉｏｎｓのセクションの例では、受信メッセージがサービスｗｓｌおよびオペレーションｇｅｔＳｅｎｓｏｒＤａｔａについてのＳＯＡＰ応答メッセージであって、かつ、セッション状態変数が、「ＯＴＳ」という文字列を含む場合には、動作、すなわち、ａｃｔｉｏｎ００２とａｃｔｉｏｎ００３とが実行される。
【００５７】
【表１０】
2011524029.tif 000012
【００５８】
Ａｃｔｉｏｎｓのセクションは、ＰＣＣＬアプリケーション２１４の動作を定義する。この動作には例えば、ＳＩＰおよびＳＯＡＰメッセージからのデータを抽出して、抽出されたデータをセッションデータとして記憶することと、新たなＳＩＰおよび／またはＳＯＡＰメッセージを作成することとが含まれる。表１１は、Ａｃｔｉｏｎｓのセクションの例示的な概要を提示する。
【００５９】
【表１１】
2011524029.tif 000013
【００６０】
Ａｃｔｉｏｎｓのセクションは、動作（ａｃｔｉｏｎ）ブロックを含む。各動作ブロックは、その名前でＣｏｎｄｉｔｉｏｎｓセクションの中で参照される動作に対応する。表１２は、動作ブロックの例示的な概要を提示する。
【００６１】
【表１２】
2011524029.tif 000014
【００６２】
動作ブロックは、例えば、ＧＥＴ、ＳＥＴおよびＳＥＮＤのメソッドのセットを含むことができる。動作ブロックのメソッドは、順次実行することができ、かつ、セッションおよびローカル変数を用いて相互に通信することができる。ローカル変数は、セッション変数と同様に処理されるが、単一の動作の範囲内に限って可視である。ＧＥＴメソッドによって、ＳＩＰおよび／またはＳＯＡＰメッセージからのデータを抽出することと、その抽出されたデータをセッション変数およびローカル変数に記憶することとが可能になる。ＳＥＴメソッドによって、定数をＰＣＣＬセッション変数およびローカル変数に記憶することが可能になり、他方、ＳＥＮＤメソッドによって、発信ＳＩＰおよびＳＯＡＰメッセージを作成することと送信することとが可能になる。
【００６３】
表１３は、例示的な一実施形態によるＧＥＴメソッドの一例を示すが、それは例えば、ＰＣＣＬ仕様２００またはＰＣＣＬアプリケーション２１４のＡｃｔｉｏｎｓのセクションの一部であってもよい。その中で、ＧＥＴの方法は、抽出されるデータの位置およびタイプと、データを記憶することになる変数の名前とを定義する。加えて、データは、データが部分的にだけ抽出されるように、正規表現を通じて処理することができる。表１３のＧＥＴメソッドは、ＳＩＰメッセージからＣａｌｌ−ＩＤヘッダの値を抽出して、それをＰＣＣＬセッションの中に定義されたｃａｌｌ−ｉｄ変数の中に記憶する。
【００６４】
【表１３】
2011524029.tif 000015
【００６５】
表１４は、例示的な実施形態によるＳＥＴメソッドの一例を示すが、それは例えば、ＰＣＣＬ仕様２００またはＰＣＣＬアプリケーション２１４のＡｃｔｉｏｎｓのセクションの一部であってもよい。その中で、ＳＥＴメソッドは、変数の名前と、変数のタイプとその値とを定義する。
【００６６】
【表１４】
2011524029.tif 000016
【００６７】
ＳＥＮＤの動作は、送信されるメッセージのタイプと、そのメッセージの内容とを定義する。ＳＥＮＤメソッドは、ＳＩＰメッセージとＳＯＡＰメッセージとで異なる。例えば、表１５は、Ａｃｔｉｏｎのセクションで用いられうるＳＩＰメッセージについてのＳＥＮＤメソッドの一例を示す。ＳＩＰメッセージについてのＳＥＮＤメソッドは、ＳＩＰメッセージのタイプを定義し、さらに、ＳＩＰメッセージのヘッダと、ＳＩＰメッセージのボディの内容とを定義することができる。ヘッダの値は、定数とセッション変数とローカル変数とから抽出することができる。
【００６８】
【表１５】
2011524029.tif 000017
【００６９】
表１６は、ＳＯＡＰメッセージについてのＳＥＮＤメソッドの一例を示す。ＳＯＡＰメッセージについてのＳＥＮＤメソッドは、呼び出されるサービスの名前と、呼び出される動作と、メッセージのタイプ（すなわち、要求か応答か）とを定義する。ＳＯＡＰメッセージ変数の値は、セッション変数と、ローカル変数とから提供されるかまたは定数として入力される。
【００７０】
【表１６】
2011524029.tif 000018
【００７１】
表１７は、Ａｃｔｉｏｎｓのセクション全体の一例を提示する。この例は、２つの動作ブロックを定義する。第１の動作ブロックは、ＧＥＴメソッドを１つと、ＳＥＴメソッドを１つと、ＳＥＮＤメソッドを２つ含む。第２の動作ブロックは、ＧＥＴメソッドとＳＥＮＤメソッドとを含む。
【００７２】
【表１７】
2011524029.tif 000019
【００７３】
ＰＣＣＬ仕様２００またはＰＣＣＬアプリケーション２１４の異なるセクションのこれらの各種の例をすべて一緒に結合するため、完全な例を図５に示す。
【００７４】
例示的なメッセージ変換
これまで、統合システム１８の概要および対応する方法の両方と、更には例示的なＰＣＣＬとを記述してきたので、上記のシステムとデバイスと方法とを用いて行いうる特定の（しかし純粋に例示的な）エンド・ツー・エンドのメッセージ変換の例について、ここで図６から記述しよう。その中で、統合システム１８は、ＳＩＰクライアントデバイス６００とＳＯＡＰクライアントデバイス６０２との間に配置される。ＳＩＰメッセージ（ｍｓｇ．１）が、ＳＩＰクライアントデバイス６００から統合システム１８へ送信され、そこで、対応するＳＯＡＰメッセージ（ｍｓｇ．２）へ翻訳されてＳＯＡＰクライアント６０２に転送される。逆方向では、ＳＯＡＰメッセージ（ｍｓｇ．３）が、ＳＯＡＰクライアント６０２から統合システム１８へ送信され、そこで、対応するＳＩＰメッセージ（ｍｓｇ．４）へ翻訳されてＳＩＰクライアント６００に転送される。これらの翻訳はすべて、この目的で統合システムの中に備えられている（そして以下に提供する）ＰＣＣＬ仕様２００に従って行われる。加えて、図６に示す４つのメッセージはすべて、上記のように統合システム１８によって管理される単一のＰＣＣＬ(結合）セッション３００に相関される。以下は、ＰＣＣＬ仕様２００（またはＰＣＣＬアプリケーション２１４）、および、図６に示す４つのメッセージの各々の例である。
【００７５】
2011524029.tif 000020
2011524029.tif 000021
2011524029.tif 000022
【００７６】
ＳＩＰ→ＳＯＡＰの変換例
2011524029.tif 000023
2011524029.tif 000024
【００７７】
ＳＯＡＰ→ＳＩＰの変換例
2011524029.tif 000025
2011524029.tif 000026
【００７８】
図６に関して上述した例示的な実施形態は、ゲートウェイ１８を介して２つのクライアントデバイス間で変換された４つのメッセージの相互交換を示す。しかし、当業者なら理解するであろうが、本発明は、それに限定されない。実際、例示的な実施形態は、いかなる数のピアまたはクライアントデバイス間でのいかなる数のメッセージであっても、それらを受信することと、セッションに結合することと、変換することと、送信することとが可能である。最初のメッセージを受信した後では、特定のセッションに関連する着信メッセージと発信メッセージとの順序および数には、それらがＰＣＣＬアプリケーション２１４の変換および調整規則に従う限り、制限はない。例えば、図７に示す例示的な実施形態では、単一のＰＣＣＬアプリケーション２１４が、１つのＰＣＣＬセッションで４つの異なるピア７００、７０２、７０４、７０６に関連する１１個のメッセージ（例えば、ＳＩＰ／ＳＯＡＰ、着信／発信、要求／応答）を結合することになる交換パタンを指定することができる。また、図７は、メッセージの例示的な交換パタン（すなわち、メッセージが交換されるべき順序）も明示する。
【００７９】
従って、上述の例示的な実施形態は、特に、（ＰＣＣＬ言語として具現化された）調整規則および変換規則の正式仕様を提供するソフトウェアと、方法と、システムと、デバイスとを提供する。この規則のセットによって、下記の機能の一部または全部が可能になる。すなわち（１）ＰＣＣＬアプリケーション２１４により調整されるピアを指定することと、（２）調整されるピアのインタフェースを指定することと、（３）受信メッセージを既存の結合セッション（ＰＣＣＬセッション３００）に相関させることを可能にする規則を指定することと、（４）新たなＰＣＣＬセッション３００を作成する規則を指定することと、（５）特定の条件に合致するときに行うべき動作を判断する条件照合規則を指定することと、（６）例えば、セッション情報をセッションレポジトリに記憶してそこから検索すること、特定のＳＩＰメッセージおよびＳＯＡＰメッセージを作成すること、および特定のＰＣＣＬ（結合）セッションを終了させることとを含めた、行われることが必要な動作を指定することと、（７）着信ＳＩＰメッセージまたは着信ＳＯＡＰメッセージから情報を入手し、かつ、その情報をセッションレポジトリに記憶するためのクエリ（そのようなクエリは、例えば、正規表現またはＸ−Ｐａｔｈポインタを使って行うことができる）を指定することと、そして、（８）情報をセッションレポジトリから入手し、かつ、その情報を発信ＳＩＰメッセージまたは発信ＳＯＡＰメッセージに入れるためのクエリ（そのようなクエリは、例えば正規表現またはＸ−Ｐａｔｈポインタを使って行うことができる）を指定することとである。加えて、そのようなソフトウェアと方法とシステムとデバイスとは、変換メカニズムにおいて下記の特徴の一部または全部を提供する。すなわち、（１）複数のアプリケーションを同時に実行する能力と、（２）現在実行中の複数のアプリケーションを記憶するアプリケーションレポジトリと、そして、（３）システムを実行する間に（例えば、調整規則および変換規則に関する新たなＰＣＣＬ仕様によって）新たなアプリケーションを展開する（従って、シャットダウンの必要がない）能力とである。
【００８０】
加えて、これらの例示的な実施形態は、一連のメッセージの変換に関連する（例えば、ＰＣＣＬセッション３００として具現化される）結合セッションを提供する。結合セッションは、ＳＩＰ／ＷＳゲートウェイ（統合システム１８）上で実行されるＰＣＣＬアプリケーション２１４のセッションである。これは、ＳＩＰメッセージかＳＯＡＰメッセージかいずれか一方を受信した時点でそのような結合セッションを開始する能力と、複数のＳＩＰおよび／またはＳＯＡＰセッションを１つの結合セッションの中に結合する能力とを含む。そのような例示的な実施形態の動的側面は、例えば図３のフローチャートに示すように、これらの結合セッションがどのように作成されるかを述べる規則を指定する能力の中に見ることができる。
【００８１】
例示的な一実施形態によれば、統合システム１８は、それらの動作を管理する外部規則を用いる５つのモジュールを含む。メッセージ受信機２１６は、着信メッセージを処理するためにシステムによって必要とされるメッセージングインタフェース（例えばＳＩＰおよびＳＯＡＰ）を実装することができるようにするため、ピアの仕様を用いる。セッション相関器２２０は、セッション相関規則を用いて着信メッセージをセッションにマッピングし、新たなセッションを作成する。条件照合器２２２は、照合規則と現行セッション情報とを用いて、特定の着信メッセージを特定の発信メッセージに変換する目的で行う必要がある動作のセットを判断する。動作実行器２２４は、動作仕様を用いて発信メッセージを作成し、および／または、セッション情報をセッションレポジトリ２２６の中に記憶する。最後に、メッセージ送信機２１８は、メッセージを発信ピアへ送信する。
【００８２】
別の例示的な実施形態によれば、図８のフローチャートに示すように、メッセージを変換する方法が、プロセッサまたはコンピュータで実行されるソフトウェアによって行われうるのだが、この方法は、受信したセッション開始プロトコル（ＳＩＰ）メッセージを、複数の異なる変換規則のセットのうちの１つに基づいて、対応するＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）メッセージに変換するステップ（ステップ８００）と、受信したＳＯＡＰメッセージを、複数の異なる変換規則のセットのうちの同じ１つに基づいて、対応するＳＩＰメッセージに変換するステップ（ステップ８０２）とを含む。
【００８３】
前述の、およびその他の、例示的な通信のシステムおよび方法は、メモリデバイスの中に含まれた命令のシーケンスを実行する１つ以上のプロセッサによって実装されうる。そのような命令は、他のコンピュータ可読媒体、例えば二次的なデータ記憶デバイスからメモリデバイスへと読み込まれてもよい。メモリデバイスに含まれた一連の命令の実行が、プロセッサに、例えば、上記のようにＳＩＰ／ＳＯＡＰメッセージを送受信するように動作させる。別の実施形態では、ハードワイヤードの回路構成が、これらの例示的な実施形態を実装するために、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて、用いられてもよい。
【００８４】
上記の例示的な実施形態は、あらゆる点で、本発明を限定するのではなく例示することが意図されている。従って、本発明は、当業者によって本書に含まれる記述から導出されうる詳細な実装として多くの変形形態が可能である。例えば、上記のＰＣＣＬ言語の構文が変形されてもよく、また、異なる構文が異なる実施形態で用いられてもよいだろう。加えて、コンパイラは必要ない。そうではなく、システムの他の実施形態は、コンパイラなしで、例えば言語から定義を直接入手して、実行されうるであろう。それらの変形形態および修正形態はすべて、以下の請求項によって定義される本発明の範囲と精神の中にあると考えられる。本願の記述で用いられる要素、動作または命令はいずれも、明示的にそのように記述されない限り、本発明に不可欠であるとか必須であると解釈されるべきではない。また、本書では、冠詞「ａ」は、１つ以上の項目を含むことが意図されている。
【図１】
2011524029.tif 000027
【図２】
2011524029.tif 000028
【図３】
2011524029.tif 000029
【図４】
2011524029.tif 000030
【図５】
2011524029.tif 000031
【図６】
2011524029.tif 000032
【図７】
2011524029.tif 000033
【図８】
2011524029.tif 000034
【手続補正書】
【提出日】平成21年11月18日(2009.11.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１のメッセージタイプを第２のメッセージタイプに変換するシステムであって、
ピアの仕様を使用して複数の着信メッセージを処理するメッセージ受信機と、
セッション相関規則を使用して前記複数の着信メッセージをセッションにマッピングし、かつ、新しいセッションを生成するセッション相関器と、
照合規則の複数の異なるセット及び現在のセッション情報を使用して前記複数の着信メッセージのうちの１つを発信メッセージに変換するために実行すべき動作のセットを判定する条件照合器と、
動作仕様を使用して複数の発信メッセージを生成する動作実行器と、
前記複数の発信メッセージを送信する送信機と、
を備えることを特徴とするシステム。
【請求項２】
前記システムは、着信セッション開始プロトコル（ＳＩＰ）メッセージを発信Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）メッセージに変換し、着信ＳＯＡＰメッセージを発信ＳＩＰメッセージに変換する
ことを特徴とする請求項１に記載のシステム。
【請求項３】
（１）前記ピアの仕様、（２）前記セッション相関規則、（３）前記照合規則、及び（４）前記動作仕様のセットを複数含むレポジトリを更に備える
ことを特徴とする請求項１に記載のシステム。
【請求項４】
複数のメッセージ変換セッションを格納するセッションレポジトリを更に備え、
各セッションはピアのセット、変換規則のセット、及び少なくとも１つの着信メッセージに関連付けられる
ことを特徴とする請求項１に記載のシステム。
【請求項５】
前記ピアのセットは、当該セットに関連付けられる任意の数のピアを有し、
前記少なくとも１つの着信メッセージは、任意の数のメッセージである
ことを特徴とする請求項４に記載のシステム。
【請求項６】
複数のプロトコル間でメッセージを送信する方法であって、
第１のプロトコルを使用する第１の着信メッセージを受信するステップと、
前記第１の着信メッセージを結合セッションに相関させるステップと、
規則の複数の異なるセットのうちの１つを使用することにより、前記第１の着信メッセージを、前記第１のプロトコルとは異なる第２のプロトコルを使用する第１の発信メッセージに変換するステップと、
前記第１の発信メッセージを送信するステップと、
前記第２のプロトコルを使用する第２の着信メッセージを受信するステップと、
前記第２の着信メッセージを前記結合セッションに相関させるステップと、
前記第２の着信メッセージを、前記第１のプロトコルを使用する第２の発信メッセージに変換するステップと、
前記第２の発信メッセージを送信するステップと、
を備えることを特徴とする方法。
【請求項７】
前記第１のプロトコルはセッション開始プロトコル（ＳＩＰ）であり、前記第２のプロトコルはＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）である
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記第１の着信メッセージを結合セッションに相関させる前記ステップは、更に、前記第１の着信メッセージを既存の結合セッションに合わせるステップを備える
ことを特徴とする請求項６に記載の方法。
【請求項９】
前記第１の着信メッセージを結合セッションに相関させる前記ステップは、更に、新しい結合セッションを生成するステップと、前記第１の着信メッセージを当該新しい結合セッションに割り当てるステップと、を備える
ことを特徴とする請求項６に記載の方法。
【請求項１０】
前記した最初の４つの受信するステップ、相関させるステップ、変換するステップ、及び送信するステップは、前記セッションの間に複数回実行される
ことを特徴とする請求項６に記載の方法。
【請求項１１】
前記した２番目の４つの受信するステップ、相関させるステップ、変換するステップ、及び送信するステップは、前記セッションの間に複数回実行される
ことを特徴とする請求項６に記載の方法。
【請求項１２】
命令を含んだコンピュータ読み取り可能な媒体であって、当該命令はプロセッサによって実行された場合に、
変換規則の複数の異なるセットのうちの１つに基づいて、受信したセッション開始プロトコル（ＳＩＰ）メッセージを対応するＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）メッセージに変換するステップと、
変換規則の前記複数の異なるセットのうちの前記１つに基づいて、受信したＳＯＡＰメッセージを対応するＳＩＰメッセージに変換するステップと、
を実行することを特徴とするコンピュータ読み取り可能な媒体。
【請求項１３】
前記受信したＳＩＰメッセージ及び前記受信したＳＯＡＰメッセージを既存の結合セッションに関連付けるステップ
を更に備えることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１４】
前記受信したＳＩＰメッセージが既存の結合セッションに相関されないと判断するステップと、
新しい結合セッションを生成するステップと、
前記受信したＳＩＰメッセージ及び前記受信したＳＯＡＰメッセージを当該新しく生成された結合セッションに関連付けるステップと、
を更に備えることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１５】
前記受信したＳＩＰメッセージ及び前記受信したＳＯＡＰメッセージに関連するセッション関連情報を格納するステップ
を更に備えることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１６】
変換規則の前記複数の異なるセットは、動的に適応可能である
ことを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【国際調査報告】
2011524029.tif 000035
2011524029.tif 000036
2011524029.tif 000037
2011524029.tif 000038