(57)【要約】  さまざまな実施形態に従って、パイプライン処理をＳＣＩＭに組入れるシステムおよび方法が提供される。このようなシステムは、１つ以上のアプリケーションサーバ上で実行する複数のアプリケーションを含むことができる。各アプリケーションサーバは、１つ以上のマイクロプロセッサ上で動作する。システムは、さらに、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能なＳＣＩＭを含むことができる。各アプリケーションチェーンは、２つ以上のバックツーバックアプリケーションを備えるパイプラインブロックを含むことができる。各パイプラインブロック内の２つ以上のアプリケーションは、前進方向および後進方向に沿って同様の順番で起動することができる。
2015525938.tif 000002
【特許請求の範囲】
【請求項１】
パイプライン処理をＳＣＩＭ（サービス制御対話管理）に組入れるシステムであって、
１つ以上のアプリケーションサーバ上で実行する複数のアプリケーションを含み、各アプリケーションサーバは、１つ以上のマイクロプロセッサ上で動作し、
ＳＣＩＭを含み、前記ＳＣＩＭは、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能であり、
前記各アプリケーションチェーンは、パイプラインブロックを含むことができ、
各パイプラインブロックは、２つ以上のバックツーバックアプリケーションを含み、
前記１つのパイプラインブロック内の前記２つ以上のバックツーバックアプリケーションは、前進方向および後進方向に沿って同様の順番で起動させられる、システム。
【請求項２】
前記ＳＣＩＭは、初期フィルタ基準「ＩＦＣ」を含み、
前記ＩＦＣは、前記複数のアプリケーションが実行される順番を決定するロジックを定義し、さらに前記パイプラインブロック内にグループ化される前記アプリケーションを定義する、請求項１に記載のシステム。
【請求項３】
前記ＩＦＣは、アプリケーションサーバ要素において、前記１つのパイプラインブロックに関連付けられ、前記パイプラインブロック内にグループ化されているアプリケーションが前進方向および後進方向に沿って同様の順番で実行されることを示す一方向性グループ拡張要素を含む、請求項２に記載のシステム。
【請求項４】
前記各アプリケーションチェーンは、複数の異なるパイプラインブロックを含むことができる、請求項１から３のいずれか１項に記載のシステム。
【請求項５】
前記１つのパイプラインブロック内の前記複数のアプリケーションの各アプリケーションは、バックツーバックアプリケーションである、請求項１から４のいずれか１項に記載のシステム。
【請求項６】
前記１つのパイプラインブロック内のアプリケーションが切断をトリガーしたときに、切断メッセージが前記１つ以上のアプリケーションチェーンのうち１つのアプリケーションチェーンの左側レッグおよび右側レッグに送信される、請求項１から５のいずれか１項に記載のシステム。
【請求項７】
パイプライン処理をＳＣＩＭ（サービス制御対話管理）に組入れる方法であって、
１つ以上のアプリケーションサーバ上で実行する複数のアプリケーションを提供するステップを含み、各アプリケーションサーバは、１つ以上のマイクロプロセッサ上で動作し、
ＳＣＩＭを提供するステップを含み、前記ＳＣＩＭは、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能であり、
１つ以上のパイプラインブロックを前記１つ以上のアプリケーションチェーンのうち少なくとも１つのアプリケーションチェーンに含ませるステップを含み、前記１つ以上のパイプラインブロックの各々は、２つ以上のバックツーバックアプリケーションを備え、
前記１つのパイプラインブロック内の前記２つ以上のアプリケーションを前進方向および後進方向に沿って同様の順番で起動させるステップを含む、方法。
【請求項８】
方法は、初期フィルタ基準「ＩＦＣ」を前記ＳＣＩＭに含ませるステップをさらに含み、
前記ＩＦＣは、前記複数のアプリケーションが実行される順番を決定するロジックを定義し、さらに前記パイプラインブロック内にグループ化される前記アプリケーションを定義する、請求項７に記載の方法。
【請求項９】
前記ＩＦＣは、前記１つのパイプラインブロックに関連付けられ、前記パイプラインブロック内にグループ化されているアプリケーションが前進方向および後進方向に沿って同様の順番で実行されることを示す一方向性グループ拡張要素を含む、請求項８に記載の方法。
【請求項１０】
複数の異なるパイプラインブロックを単一のアプリケーションチェーンに含ませるステップをさらに含む、請求項７から９のいずれか１項に記載の方法。
【請求項１１】
前記パイプラインブロック内の前記複数のアプリケーションの各々は、バックツーバックアプリケーションである、請求項７から１０のいずれか１項に記載の方法。
【請求項１２】
パイプライン中のアプリケーションにより、切断をトリガーするステップと、切断メッセージを前記アプリケーションチェーンの左側レッグおよび右側レッグに送信するステップとをさらに含む、請求項７から１１のいずれか１項に記載の方法。
【請求項１３】
コンピュータプログラム製品であって、
指令を含み、これらの指令がコンピュータによって実行されるとき、請求項７から１２のいずれか１項に記載の方法を前記コンピュータに実行させる、コンピュータプログラム製品。
【請求項１４】
前記指令を記憶する非一時的なコンピュータ可読記憶媒体を含む、請求項１３に記載のコンピュータプログラム製品。
【請求項１５】
その中に格納された指令を含む非一時的なコンピュータ可読記憶媒体であって、これらの指令は、コンピュータによって実行されると、コンピュータに
１つ以上のアプリケーションサーバ上で実行する複数のアプリケーションを提供するステップを実行させ、各アプリケーションサーバは、１つ以上のマイクロプロセッサ上で動作し、
ＳＣＩＭ（サービス制御対話管理）を提供するステップを実行させ、前記ＳＣＩＭは、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能であり、
１つ以上のパイプラインブロックを前記１つ以上のアプリケーションチェーンのうち少なくとも１つのアプリケーションチェーンに含ませるステップを実行させ、前記１つ以上のパイプラインブロックの各々は、２つ以上のバックツーバックアプリケーションを備え、
前記パイプラインブロック内の前記２つ以上のアプリケーションを前進方向および後進方向に沿って同様の順番で起動させるステップを実行させる、非一時的なコンピュータ可読記憶媒体。
【請求項１６】
非一時的なコンピュータ可読記憶媒体は、前記ＳＣＩＭにおいて、初期フィルタ基準「ＩＦＣ」を含み、
前記ＩＦＣは、前記複数のアプリケーションが実行される順番を決定するロジックを定義し、さらに前記パイプラインブロック内にグループ化される前記アプリケーションを定義すし、
前記ＩＦＣは、前記パイプラインブロックに関連付けられ、前記パイプラインブロック内にグループ化されているアプリケーションが前進方向および後進方向に沿って同様の順番で実行されることを示す一方向性グループ拡張要素を含む、請求項１３に記載の非一時的なコンピュータ可読記憶媒体。
【請求項１７】
単一のアプリケーションチェーンにおいて、複数の異なるパイプラインブロックを含む、請求項１３または１４に記載の非一時的なコンピュータ可読記憶媒体。
【請求項１８】
前記パイプラインブロック内の前記複数のアプリケーションの各々は、バックツーバックアプリケーションである、請求項１３から１５のいずれか１項に記載の非一時的なコンピュータ可読記憶媒体。
【請求項１９】
パイプライン中のアプリケーションによって、切断をトリガーするステップと、切断メッセージを前記アプリケーションチェーンの左側レッグおよび右側レッグに送信するステップとをさらに含む、請求項１３から１６のいずれか１項に記載の非一時的なコンピュータ可読記憶媒体。
【請求項２０】
請求項７から１２のいずれか１項に記載の方法を１つ以上のコンピュータに実施させるためのプログラム。
【請求項２１】
パイプライン処理をＳＣＩＭに組入れるシステムであって、
複数のアプリケーションを実行させる１つ以上のアプリケーションサーバと、
ＳＣＩＭとを含み、前記ＳＣＩＭは、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能であり、
前記各アプリケーションチェーンは、パイプラインブロックを含むことができ、
各パイプラインブロックは、２つ以上のバックツーバックアプリケーションを含み、
前記パイプラインブロック内の前記２つ以上のバックツーバックアプリケーションは、前進方向および後進方向に沿って同様の順番で起動させられる、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
著作権表示
この特許文書の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、特許商標庁の特許ファイルまたは記録に掲載された特許文書または特許開示の複製に対しては異議がないが、その他すべての著作権を留保する。
【０００２】
発明の分野
本発明は、統合エンジンを用いたアプリケーション統合化に関し、具体的には、パイプライン処理のためのＩＭＳ初期フィルタ基準（ＩＦＣ）を有するようにＳＣＩＭ／サービスブローカー処理を拡張するためのシステムおよび方法に関する。
【背景技術】
【０００３】
背景：
サービス制御対話管理（ＳＣＩＭ）のような統合エンジンは、ユーザを特定のベンダーに限定することなく、すべてのアプリケーションおよびサービスに対してカスタムソリューションを作成するために、複数のベンダーからの複数のアプリケーションを使用する可能性をユーザに与える。標準的なＳＣＩＭは、初期リクエストに応じて、アプリケーションチェーンを構築する。現在では、ＳＣＩＭは、初期リクエストに従い、ネットワーク方向におけるシグナリングトラフィックに応じて、アプリケーションを処理することに限定され、アプリケーションを前進方向および後進方向の両方に同様の順番で起動させるパイプライン方式をサポートしない。しかしながら、ユーザは、アプリケーションを（ネットワーク方向に応じて）次々に連鎖する能力、および（ネットワーク方向に関わらず）パイプライン方式で動作するように、チェーンにおいて特定のアプリケーションのサブセットを定義する能力が必要である。
【０００４】
これらの特性を提供する以前の試みは、必要とされた機能をすべて含む単独の大規模なアプリケーションを創出したが、ＳＣＩＭを用いて小さなアプリケーションを連鎖する目的を打消している。代替的な解決案として、アプリケーションが両方向に所望の順番で実行されるように、これらのアプリケーションをチェーンに複数回追加することができるが、この解決案は、拡張できない。
【発明の概要】
【課題を解決するための手段】
【０００５】
概要：
さまざまな実施形態に従って、パイプライン処理をＳＣＩＭに組入れるシステムおよび方法が提供される。このようなシステムは、１つ以上のアプリケーションサーバ上で実行する複数のアプリケーションを含むことができる。各アプリケーションサーバは、１つ以上のマイクロプロセッサ上で動作する。システムは、さらに、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能であるＳＣＩＭを含むことができる。各アプリケーションチェーンは、２つ以上の連続アプリケーションを備えるパイプラインブロックを含むことができる。各パイプラインブロック内の２つ以上のアプリケーションは、前進方向および後進方向に沿って同様の順番で起動することができる。
【０００６】
一実施形態において、システムは、複数のアプリケーションを実行する１つ以上のアプリケーションサーバと、ＳＣＩＭとを含み、ＳＣＩＭは、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能であり、各アプリケーションチェーンは、パイプラインブロックを含むことができ、各パイプラインブロックは、２つ以上のバックツーバックアプリケーションを含み、パイプラインブロック内の２つ以上のバックツーバックアプリケーションは、前進方向および後進方向に沿って同様の順番で起動させられる。
【図面の簡単な説明】
【０００７】
【図１】サービス制御対話管理（ＳＣＩＭ）／サービスブローカーを示す図である。
【図２】サービスブローカーによるアプリケーションの統合例を示す図である。
【図３】本発明の実施形態に従った、パイプラインにおける前進メッセージのレッグのマッピング例を示す図である。
【図４】本発明の実施形態に従った、パイプラインにおけるアプリケーションの切断例を示す図である。
【図５】標準的なＳＣＩＭ処理のフローチャートを示す図である。
【図６】本発明の実施形態に従った、ＳＣＩＭを用いたパイプライン処理のフローチャートを示す図である。
【図７】本発明の実施形態に従った、パイプライン処理を統合エンジンに組入れる方法を示す図である。
【発明を実施するための形態】
【０００８】
詳細な説明
以下の説明において、本発明は、添付図面の図面に限定されず、例として説明される。本開示におけるさまざまな実施形態を言及する際に、必ずしも同じ実施形態を示すのではなく、少なくとも１つの実施形態を意味する。特定の実装を説明する際に、これらの実装は、例示の目的のみで提供されることを理解すべきである。当業者は、本発明の範囲および主旨から逸脱することなく、他の構成要素および他の構成を使用できることを認識するであろう。
【０００９】
さらに、特定の場合において、本発明を完全に説明するために、多数の特定の詳細が記載される。しかしながら、本発明がこれらの特定の詳細なしで実施できることは、当業者にとって明らかであろう。他の場合において、本発明を明瞭にするために、周知の特徴が必要以上に詳しく記載されない。
【００１０】
図１は、サービス制御対話管理（ＳＣＩＭ）／サービスブローカー１００を示している。ＳＣＩＭ１００は、異なるアプリケーションサーバ１０８〜１１２に亘って実装された複数のアプリケーション１０２〜１０６を統合するまたは連鎖させることができる。複数のアプリケーションサーバの各々は、複数のアプリケーションを含むことができる。ＳＣＩＭ統合は、ネットワークからのシグナリングに応じて行われる。
【００１１】
図２は、サービスブローカーによるアプリケーションの統合例を示している。図２に示すように、ユーザ１  ２０４とユーザ２  ２０６との間の通信を容易にするために、２つのアプリケーションＡ  ２００とアプリケーションＢ  ２０２は、統合される。アプリケーションＡは、第１アプリケーションサーバ、すなわちアプリケーションサーバＡ  ２０８上で実行することができる。アプリケーションＢは、第２アプリケーションサーバ、すなわちアプリケーションサーバＢ  ２１０上で実行することができる。アプリケーション間の情報のフローは、ネットワークのフローに従う。
【００１２】
発信側、この例ではユーザ１  ２０４からのメッセージは、前進メッセージ２１２と呼ばれ、アプリケーションＡ  ２００からアプリケーションＢ  ２０２に流れる。
【００１３】
終端側、この例ではユーザ２  ２０６からのメッセージは、後進メッセージ２１４と呼ばれ、アプリケーションＢ  ２０２からアプリケーションＡ  ２００に流れる。
【００１４】
しかしながら、常に同様の順番で処理を行うことが望まれる場合がある。たとえば、メッセージがいずれかの方向に送信されるとき、このメッセージがアプリケーションＡ  ２００に処理されてから、アプリケーションＢ  ２０２に処理される。情報を常に同様の順番で処理するイベント処理方法は、パイプラインと呼ばれる。パイプライン処理において、アプリケーションをブロックにグループ化することができ、処理方向に関係なく、これらのアプリケーションを同様の順番で実行することができる。パイプラインに追加されたアプリケーションは、バックツーバック（Ｂ２Ｂ）アプリケーションと呼ばれる。Ｂ２Ｂアプリケーションの特徴は、受信したものをそのまま送り出すことである。Ｂ２Ｂアプリケーションの一例としては、トラフィックロガーが挙げられる。トラフィックロガーは、受信したものを（以下でより詳細に説明する追加のレッグを開かず）そのまま送り返す。
【００１５】
このような例として、パイプライン手法を挙げる。パイプライン手法は、課金の際に好まれる。この場合、パイプラインは、位置標準化（たとえば、ユーザがローミングしているか否かを判断する）、課金（たとえば、ユーザがどのくらい話せるかまたはユーザの口座に残高がどのくらい残っているか）、および通知書（たとえば、残高不足の通知をユーザに送付する）を含むだろう。いずれかの場合、シグナリング（前進メッセージまたは後進メッセージ）の順番は、同様である。
【００１６】
ＳＣＩＭ／サービスブローカーは、アプリケーションの間にシグナリングトラフィックを統合および分散する手段を与えるが、パイプライン手法を利用しない。以下の２つの解決案は、基準を利用する。
【００１７】
１つ目の解決案は、すべてのロジック（本願の場合、標準化、課金および通知書）を含む単一のアプリケーションを作成することである。しかしながら、このやり方は、ＳＣＩＭが追加されたのは、すべての処理ロジックを単一のアプリケーションに含ませるではなく、アプリケーションを連鎖させるという目的に反する。
【００１８】
別の解決案としては、アプリケーションをチェーンに２回追加して、シグナリングの特定の方向に沿って機能させることができる（たとえば本願の場合、場所（１）、通知書（２）、課金（１，２）、通知書（１）、場所（２）。前進方向の場合、アプリケーション（１）が動作し、後進方向の場合、アプリケーション（２）が動作する）。しかしながら、この解決案は、拡張できない。
【００１９】
これらの問題を対処するために、本発明の一実施形態によれば、統合エンジン（たとえば、ＳＣＩＭ／サービスブローカー）は、アプリケーションのグループ定義をサポートするように、初期フィルタ基準（ＩＦＣ）の拡張と、アプリケーションチェーンを作成する方法と、アプリケーションチェーンに情報を転送する方法とを含むように拡張することができる。以下では、これらの各々を順番で説明する。
【００２０】
ＩＦＣの拡張
本発明の実施形態によれば、初期フィルタ基準（ＩＦＣ）は、（グループＩＤを有する）一方向性グループと呼ばれる新たな要素を用いて拡張することができる。ＩＦＣは、どのアプリケーションを起動すべき基準（たとえば、統合ロジック）を定義するＸＭＬフォーマットである。ＩＦＣ内の拡張ポイントを用いて、特定セットの連続アプリケーションを一方向性グループに指定することができる。よって、このグループは、パイプラインで処理される。一方向性グループ拡張は、グループＩＤを含む。このグループＩＤは、どのアプリケーションがどのグループの構成メンバーであるかを識別するために使用される。グループ内のアプリケーションは、ＩＦＣにリストされた順番で順次に実行される。
【００２１】
アプリケーションを連鎖する
図３は、本発明の実施形態に従った、パイプラインレッグのマッピング例を示している。典型的には、ＳＣＩＭ／サービスブローカー３００は、バックツーバック（Ｂ２Ｂ）レッグの対を用いて、アプリケーション（アプリ１  ３０４、アプリ２  ３０６、およびアプリＮ  ３０８）からなるブロック３０２を統合する。各初期着信イベントに対し、ＳＣＩＭ３００は、そのブロックに属しているメッセージを処理するレッグを作成する。その後、ＳＣＩＭ３００は、メッセージを目標アプリケーションにルーティングするように、次のアプリケーションを探し、特定の対話のために、目標アプリケーションから来るイベントおよび目標アプリケーションに行くイベントを処理するＢ２Ｂレッグのピアレッグを作成する。
【００２２】
図３に示すように、パイプラインの統合には、複数の左側レッグ３１０，３１２，３１４，３１６、および複数の右側レッグ３１８，３２０，３２２，３２４が存在する。ブロックの左側レッグ３１０は、パイプライン統合を始動させるレッグであり、ブロックの右側レッグ３２４は、パイプライン内の最後のアプリケーションのために作成されたピアレッグである。各左側レッグは、新しく作成されたＢ２Ｂレッグ（Ｂ２Ｂ右側レッグ）にマッピングされる。たとえば、レッグ３１０は、レッグ３１８にマッピングされ、レッグ３１２は、レッグ３２０にマッピングされ、レッグ（Ｎ＊２）＋１は、レッグ（Ｎ＊２）＋２にマッピングされる。
【００２３】
右側レッグの場合、レッグ（ｉ）は、レッグ（（ｉ＋３）ｍｏｄ  Ｍ）にマッピングされる。式中、Ｍ：パイプラインに追加されたレッグ（パイプラインの左側レッグおよびパイプラインの右側レッグを含む）の数であり、ｉ：レッグのＩＤである。
【００２４】
レッグのマッピングは、トラフィックをルーティングするために使用される、すなわち、情報が１つのレッグによって受信された場合、マッピングは、トラフィックをどのレッグに転送すべくことを示す。図３に示した例では、パイプラインの統合において、レッグのマッピングは、以下の通りである。
【００２５】
左側レッグのマッピング：
３１０→３１８
３１２→３２０
３１４→３２２
３１６→３２４
右側レッグのマッピング：
３２４→３１２
３１８→３１４
３２０→３１６
３２２→３１０
上記によれば、前進方向の場合（左側レッグのマッピングに従い）、トラフィックは、各連続するレッグ対を介して、１つのアプリケーションから次のアプリケーションに流れる。後進方向の場合、トラフィックは、ブロック内の次のアプリケーションの「後進」レッグにルーティングされる。たとえば、アプリ１がレッグ３１８に沿って後進方向にメッセージを送信した場合、そのメッセージは、ブロック内の次のアプリケーション、本願の場合はアプリ２に送信される。前進方向の場合、メッセージは、レッグ３２０に沿ってアプリ２に送信されるが、この場合、メッセージは、後進方向に伝播するため、レッグ３１４に沿って送信される。同様に、後進方向の他のトラフィックは、上記に示した右側レッグのマッピングに従って、ルーティングされる。
【００２６】
代替的には、非パイプラインの統合（たとえば、正規ＳＣＩＭモード）では、マッピングが対称である。すなわち、前進方向および後進方向におけるトラフィックルーティングは、鏡面対称である。
【００２７】
左側レッグのマッピング：
３１０→３１８
３１２→３２０
３１４→３２２
３１６→３２４
右側レッグのマッピング：
３２４→３１６
３２２→３１４
３２０→３１２
３１８→３１０
図４は、本発明の実施形態に従った、パイプラインにおけるアプリケーションの切断例を示している。パイプライン中間のアプリケーションが切断リクエストをトリガーしたときに、たとえばアプリ３  ４００、ブロックの左側レッグ４０２およびブロックの右側レッグ４０４を切断する必要がある。切断リクエストがアプリ３の右側レッグ４０６で受信された場合、切断メッセージ４０８は、ブロックの右側レッグ４０４に送信することができる。切断リクエストがアプリ３の左側レッグ４１０で受信された場合、切断リクエスト４１２，４１４および４１６は、最も左側のアプリケーションを始め、ブロック内の各アプリケーションの右側レッグ（４１２，４１４，４１６）に伝送することができる。伝送中に、切断アプリケーションのレッグがスキップされる。一旦アプリ４からの切断イベントが受信されると、切断イベントがブロックの左側レッグ４０２に逆ルーティングされる。
【００２８】
アプリケーションチェーンにおける情報の転送
図５は、標準的なＳＣＩＭ処理のフローチャートを示している。図５に示すように、第１ユーザＡ  ５００は、第２ユーザＢ  ５０２をコールする。ユーザＡ  ５００から送信したＩＮＶＩＴＥメッセージ５０４がＳＣＩＭ５０６に受信されたときから、処理が始まる。その後、ＳＣＩＭ５０６は、４つのアプリケーション（アプリ１  ５０８、アプリ２  ５１０、アプリ３  ５１２およびアプリ４  ５１４）を介してメッセージを統合する。５１６において、ＩＮＶＩＴＥメッセージは、ＳＣＩＭ５０６によってアプリ１  ５０８に送信される。その後、アプリ１  ５０８は、このメッセージをＳＣＩＭ５０６に返送する。この統合ロジックによれば、５１８において、ＳＣＩＭ５０６は、メッセージを次のアプリケーション、すなわちアプリ２  ５１０に送信する。アプリ２  ５１０は、このメッセージをＳＣＩＭ５０６に返送する。同様に、ＳＣＩＭ５０６は、その後、５２０および５２２において、このメッセージをアプリ３  ５１２およびアプリ４  ５１４に各々送信し、最終的には、５２４においてこのメッセージをユーザＢ  ５０２に送信する。フローチャート内の５１６から５２４までの要素は、ユーザＡ  ５００からユーザＢ  ５０２までの接続のセットアップを表している。ユーザＢ  ５０２がコールに応答すると、ＯＫメッセージがユーザＡ  ５００に返送される。この図は、標準的なＳＣＩＭの処理フローを示しているため、処理は、アプリケーションを介して後方へ進む。すなわち、ＯＫメッセージは、５２６においてＳＣＩＭに送信され、その後、このＯＫメッセージは、５２８においてアプリ４  ５１４に送信され、５３０においてアプリ３  ５１２に送信され、５３２においてアプリ２  ５１０に送信され、５３４においてアプリ１  ５０８に送信される。アプリケーションが処理を完了すると、ＯＫメッセージは、５３６において、ユーザＡ  ５００に最終的に返送される。
【００２９】
図６は、本発明の実施形態による、ＳＣＩＭを用いたパイプライン処理のフローチャートを示している。図６に示すように、アプリ２  ６００およびアプリ３  ６０２は、グループ６０４にグループ化されているため、パイプラインブロックとして処理される。前進方向６０６に沿って、ＩＮＶＩＴＥメッセージをユーザ６０８からユーザＢ  ６１０に送信する処理は、図５に示すように進行することができる。しかしながら、このパイプラインブロックにより、後進方向では、処理の進行は異なる。６１２において、ＯＫメッセージは、ユーザＢ  ６１０からＳＣＩＭに送信される。６１４において、ＳＣＩＭは、ＯＫメッセージをアプリ４に送信し、アプリ４は、このＯＫメッセージをＳＣＩＭに返送する。その後、６１６において、処理は、アプリ２−アプリ３のブロックに到達する。図５において、アプリ３  ６０２が起動され、その次にアプリ２  ６００が起動される場合と異なり、図６において、パイプラインブロック内のアプリケーションは、前進方向の場合と同様の順番で起動される。したがって、６１８において、アプリ２  ６００が起動され、続いて、６２０において、アプリ３  ６０２が起動される。このようにして、アプリ３  ６０２は、アプリ２  ６００により生成された情報を必要とする場合、その情報を利用することができる。パイプラインブロックの後、処理は、以前と同様に進行する。すなわち、６２２において、アプリ１は起動され、ＯＫメッセージは、６２４においてユーザＡに返送される。
【００３０】
パイプライン処理をＳＣＩＭに組込むことによって、以前では互換性のない新たなアプリケーションを統合することができる。以前のシステムの環境下、第１アプリケーションが第２アプリケーションによって生成された特定の情報を必要とする場合、第２アプリケーションからの情報が利用できる保証がなかったため、第１アプリケーションは、システムと互換性がない可能性がある。しかしながら、図６に示すように、本発明の実施形態は、パイプライン処理を可能にするようにＳＣＩＭを拡張したため、拡張性のある解決案を提供するとともに、アプリケーションを特定の順番で起動させることを保証する。
【００３１】
上記の実施例において、特定のアプリケーションチェーンには単一のパイプラインブロックがあると示されているが、ＳＣＩＭは、任意のアプリケーションチェーンにおいて、複数のパイプラインブロックをインターリーブするように使用することができる。
【００３２】
図７は、本発明の実施形態に従った、パイプライン処理を統合エンジンに組入れる方法を示している。ステップ７００において、１つ以上のアプリケーションサーバ上で実行する複数のアプリケーションが提供される。各アプリケーションサーバは、１つ以上のマイクロプロセッサを含む。ステップ７０２において、ＳＣＩＭが提供される。このＳＣＩＭは、１つ以上のアプリケーションチェーン内の複数のアプリケーションの起動を管理するように動作可能である。ステップ７０４において、少なくとも１つのアプリケーションチェーンが提供される。少なくとも１つのアプリケーションチェーンは、１つ以上のパイプラインブロックを含む。各ブロックは、２つ以上のアプリケーションを含む。ステップ７０６において、パイプラインブロック内の２つ以上のアプリケーションは、前進方向および後進方向に沿って同一の順番で起動させられる。
【００３３】
図７に示す方法は、初期フィルタ基準「ＩＦＣ」を前記ＳＣＩＭに含ませるステップをさらに含み、このＩＦＣは、複数のアプリケーションが実行される順番を決定するロジックを定義し、さらにパイプラインブロック内にグループ化されるアプリケーションを定義する。また、各アプリケーションチェーンは、複数の異なるパイプラインブロックを含むことができ、ブロック内の複数のアプリケーションの各々は、バックツーバックアプリケーションである。さらに、パイプライン内のアプリケーションが切断をトリガーしたときに、切断メッセージがアプリケーションチェーンの左側レッグおよび右側レッグに送信される。
【００３４】
当業者にとって容易に分かるように、適切なソフトウェアコーディングは、本開示の教示に基づいて、熟練したプログラマによって容易に調製することができる。また、当業者にとって容易に分かるように、本発明は、特定用途向け集積回路を準備することによって、または従来の要素回路を適切なネットワークに相互接続することによって実現することができる。
【００３５】
さまざまな実施形態は、汎用または専用のコンピュータプロセッサ／コンピュータ装置を本明細書において開示された特徴のいずれかを実行するようにプログラムするために使用され得る指令を有するコンピュータプログラム製品を含む。このコンピュータプログラム製品は、たとえば、指令をその上に／中に記憶させる記憶媒体を含むことができる。この記憶媒体は、フロッピーディスク（登録商標）、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、光磁気ディスク、ホログラフィック記憶、ＲＯＭ、ＲＡＭ、ＰＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気または光カード、（分子メモリＩＣを含む）ナノシステムを含む任意種類の物理的媒体、紙または紙系の媒体、または指令および／または情報の格納に適した任意種類の媒体またはデバイスを含むことができるが、これらに限定されない。このコンピュータプログラム製品は、１つ以上のパブリックおよび／またはプライベートネットワークを介して、全体的または部分的に伝送されることができる。その伝送は、本明細書において開示された特徴のいずれかを実行するように、１つ以上のプロセッサに使用できる指令を含む。伝送は、複数の独立した伝送を含んでもよい。しかしながら、特定の実施形態によれば、指令を含むコンピュータ記憶媒体は、一時的なものではなく（すなわち、伝送中に存在するものではない）、物理デバイス上に永続化されたものである。
【００３６】
本発明の上記説明は、例示および説明のために提供されている。本発明を網羅的であることにまたは開示された形態に厳密に限定することを意図するものではない。多くの修正および変更は、当業者にとって明らかであろう。実施形態は、本発明の原理およびその実際の応用を説明するために選択され説明された。よって、当業者がさまざまな実施形態により本発明を理解し、考えられる特定の用途に適したさまざまな修正をできるようになる。なお、本発明の範囲が添付の特許請求の範囲およびその等価物によって定義されることが意図される。
【図１】
2015525938.tif 000003
【図２】
2015525938.tif 000004
【図３】
2015525938.tif 000005
【図４】
2015525938.tif 000006
【図５】
2015525938.tif 000007
【図６】
2015525938.tif 000008
【図７】
2015525938.tif 000009
【国際調査報告】
2015525938.tif 000010
2015525938.tif 000011
2015525938.tif 000012