JP4495137B2 - 電気通信クライアントサービス要求をサポートするためのサービスブローカー統合層 - Google Patents

Description

優先権の請求
本出願は、２００５年１０月２８日出願のＥＰＯ特許出願第０５４２５７６４．７号、及び２００５年１０月２８日出願のイタリア特許出願第ＭＩ２００５Ａ００２０７３号に対する優先権の恩典を請求するものであり、これらの両方は、本明細書においてその全内容が引用により組み込まれている。
本発明は、電気通信処理システムアーキテクチャに関する。特に、本発明は、第三者電気通信サービス要求を処理する電気通信システムアーキテクチャ内の層に関する。

データ処理及び電気通信技術の急速な進歩は、消費者が利用可能な広範な通信サービスをもたらした。そのような電気通信サービスは、従来の電話サービス、「インターネット」サービス、ケーブルテレビジョンサービス、セルラー電話サービス、呼び出しサービス、複合音声及びデータ配信サービス、並びに多くの他のサービスを含む。更に、多くのサービスは、無線又は有線のいずれかに基づくものとすることができる。
従来の電気通信サービスプロバイダは、多岐にわたる電気通信製品及びサービスを実施し、確実に供給するために莫大な量の時間、経費、及び先端技術に投資してきた。過去においては、この投資は、電気通信サービスプロバイダに対してのみ主な利益をもたらすものであった。すなわち、電気通信サービスプロバイダは、自身の技術を秘密裏に、かつ自身の使用のために内部的に維持してきた。

高度な電気通信アーキテクチャのこの背景に対して、各電気通信サービスプロバイダ内には、新しい収益チャンネルをもたらす新しい商機を探求して開発するという要望がある。サービスプロバイダアーキテクチャにおける既存の技術は、そのような新しい収益チャンネルを推進することができるであろう。しかし、過去においては、第三者がサービスプロバイダアーキテクチャの潜在的な機能性にアクセスすることを可能にする十分に安全で柔軟性があり、かつ効率的な機構が存在していなかった。
更に、たとえ第三者がサービスプロバイダアーキテクチャの機能性にアクセスできたとしても、第三者のサービス要求を処理するためのサポートするアーキテクチャが存在していなかった。第三者がサービスプロバイダから電気通信サービスを要求できるだけでは十分ではない。サポートする処理アーキテクチャなしでは、第三者の要求には無回答である。

ＥＰＯ特許出願第０５４２５７６４．７号 イタリア特許出願第ＭＩ２００５Ａ００２０７３号

拡張された電気通信サービスプロバイダアーキテクチャに対する必要性が長らく存在している。

拡張された電気通信サービスプロバイダアーキテクチャの確立は、かなりの技術的難問を課している。一例として、同時又はほぼ同時の可能性がある第三者から受信する非常に多くのサービス要求の受信及び編成に技術的困難がある。別の例として、調整された効率的な方法でどのサービス要求を処理するかの判断に技術的困難がある。付加的な技術的難問は、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性のサービス要求処理を提供し、サービス要求処理の性能を最大にすることにある。

本発明の一態様は、電気通信アーキテクチャのためのサービス要求処理システムを提供するサービスブローカー層である。サービス要求処理システムは、サービス要求インタフェース、ディスパッチャーシステム、フェッチャーシステム、及びワークフローエンジンを含む。付加的な又は異なる構成要素をサービス要求処理システムに含めることができる。
サービスブローカーは、サービス配信プラットフォームの一部であり、いくつかの技術的利点を提供する。第１の利点は、ワークフロー、タスク、及びアクションの技術指令管理データベース定義を通じて達成することができる構成可能性である。サービスブローカーは、電気通信サービスプロバイダが既存のビルディングブロックから開始して新しいサービスを作成することを可能にし、かつサービスプロバイダが所定のテンプレートから新しいビルディングブロックを作成することを可能にする。サービスブローカーは、それによって、サービスプロバイダを完全に特別仕様で柔軟性のないインフラストラクチャに制限することなく、サービスプロバイダにサービスを定義する多大な柔軟性を提供する。

第２の利点は制御である。サービスブローカーは、サービスを配信するために実行されるワークフロー（特に非同期ワークフロー）上でエラー処理、記録、及び制御を提供する。サービスブローカーは、エラー管理グラフィックユーザインタフェースを提供する。インタフェースを通じて、経験豊かなオペレータは、サービスを配信するワークフロー処理の終了、再提出、変更、修正、又はそうでなければ訂正を行うことができる。

第３の利点は保守である。一般的に、サービスブローカーは、ワークフロー、メッセージ、及びデータ要素のハードコーディングを避ける。その代わりに、サービスブローカーは、再構成可能ＸＭＬ、並びにメタデータベースのワークフロー、メッセージ、及びデータ要素を用いる。その結果、サービスブローカーの機能性は、ハードコードされた実施と比較して、維持、改訂、拡張、及び改善が遥かに容易である。

更に、サービスブローカーは、同期及び非同期ワークフローの両方を実行する機能を提供する。結果として、拡張した性能が生じる。一部の実施例では、毎秒５００トランザクション又はそれよりも多くを処理することができる。
サービス要求インタフェースは、電気通信サービスに対するサービス要求を外部エンティティから受信する。各サービス要求は、サービス識別子フィールドを含む。サービス識別子フィールドは、サービスブローカーにサービス要求の中で要求さているサービスのタイプを通知する。

サービスブローカー内のディスパッチャーは、各サービス要求を受信する。サービス識別子フィールドに基づいて、ディスパッチャーは、異なるサービス待ち行列の中にサービス要求を分配する。個々のサービス待ち行列は、特定の要求エンティティ及び／又はサービスのタイプに対する要求を独立して待ち行列に入れるように設定することができる。例えば、サービス待ち行列は、メッセージ配信（例えば、「ＳＭＳ」又は「ＭＭＳ」）サービス要求待ち行列、課金サービス要求待ち行列、「サービスアクティブ化」要求待ち行列、又は他のタイプのサービス待ち行列を含むことができる。

サービスブローカーはまた、フェッチャーシステムを含む。フェッチャーシステムは、処理のために個々のサービス待ち行列から待機サービス要求を検索する。一部の実施例では、サービスブローカーは、複数の独立したフェッチャーエンジンを提供する複数のフェッチャーシステムを含むことができる。一組のトラフィック制御パラメータは、フェッチャーシステムによる個々のサービス待ち行列からの待機サービス要求の検索を支配する。
ワークフローエンジンは、検索されたサービス要求を満足させるワークフロー段階のシーケンスを開始する。サービスブローカーは、複数の独立したワークフローエンジンを実行することができる。ワークフローエンジンは、例えば、特定のフェッチャーシステムによって選択されたサービス要求に対して定義されたワークフローを処理することができる。

本発明の付加的な態様は、電気通信サービス要求処理を効率的に順序付けする方法及びシステムを含む。特に、サービスブローカーは、複数のサービス待ち行列を設定し、複数の待機電気通信サービス要求記録をサービス待ち行列の中に分配する。サービスブローカーはまた、サービス要求を検索するために複数のフェッチャーエンジンの同時実行を開始する。
第１のフェッチャーエンジンは、次に、サービス待ち行列に格納された電気通信サービス要求記録（例えば、「技術サービス指令識別子（ＴＳＯ＿ＩＤ））の一部を検索する。サービス要求記録は、外部エンティティによって提出された第１のサービス要求を表すものである。同様に、第２のフェッチャーエンジンは、サービス待ち行列に格納された別の電気通信サービス要求の一部を検索する。このサービス要求記録は、外部エンティティによって提出された第２のサービス要求を表すものである。

サービスブローカーは、次に、第１のサービス要求及び第２のサービス要求を実施するワークフロー実行を開始するための異なるワークフロー要求配信技術を用いる。例えば、サービスブローカーは、ワークフローエンジンが加入しているメッセージ公開／加入システムを通じてワークフロー要求メッセージを公開することにより、第１のワークフロー要求を実施することができる。代替的なワークフロー要求配信技術として、サービスブローカーは、第２のワークフローエンジンを直接呼び出し、第２のサービス要求を指定することができる。

サービスブローカーアーキテクチャは、それによって外部サービス要求の処理に関連する技術的困難を克服する。待ち行列内のサービス要求の分配は、莫大な数の同時又はほぼ同時のサービス要求を受信して編成する技術的困難に対処する。多重フェッチャー及びワークフローエンジンアーキテクチャは、調整された効率的方法でサービス要求を抽出し、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性のサービス要求処理を提供し、サービス要求処理の性能を最大にする際の技術的困難に対処するものである。

本発明の他のシステム、方法、特徴、及び利点は、下記の図及び詳細説明の吟味によって当業者には明らかであろうし、又は明らかになるであろう。全てのそのような付加的なシステム、方法、特徴、及び利点は、本説明に含まれ、本発明の範囲内であり、特許請求の範囲によって保護されるように意図されている。
本発明は、下記の図面及び説明への参照によってより良く理解することができる。図中の構成要素は、必ずしも縮尺通りではなく、代わりに本発明の原理の例示に重点が置かれている。更に、図中、同じ参照番号は、異なる図を通して対応する部分又は要素を指定している。

図１は、第三者１０２と対話する電気通信アーキテクチャ１００を示している。第三者１０２は、形態及び実施例において広範に変化することができる。例えば、第三者１０２は、セルラー電話、携帯情報端末、及びネットワーク（例えば、「インターネット」）通信装置のような加入者装置１０４、「ショートメッセージサービス（ＳＭＳ）」メッセージングアプリケーション、「セッション開始プロトコル（ＳＩＰ）」システム、及び製品及びサービスについて顧客に課金する請求アプリケーションなどの、他のサービスプロバイダによって実施された電気通信サービスアプリケーションのようなアプリケーション１０６、及び他の装置、プログラム、又はエンティティ１０８を含むことができる。

電気通信アーキテクチャ１００は、電気通信製品及びサービスをサポートする機能を実施する。電気通信アーキテクチャ１００は、選択された機能を第三者１０２に公開する。言い換えれば、第三者１０２は、アーキテクチャ１００内に既に置かれている機能を用いるために電気通信アーキテクチャ１００と通信することができる。その結果、第三者１０２は、電気通信アーキテクチャ１００によって既に提供されている機能をローカルに複製するために要求されるリソースを消費する必要がない。

製品及びサービス、並びにそれらの公開された基本的な機能は、実施例間で変わる場合がある。例えば、電気通信アーキテクチャ１００は、「ＳＭＳ」メッセージングサービス（「ＳＭＳ」メッセージを配信し、それに対して課金するため）、「マルチメディアメッセージングシステム（ＭＭＳ）」メッセージングサービス（「ＭＭＳ」メッセージを配信し、それに対して課金するため）、及び「ＳＩＰ」サービス（「ＳＩＰ」呼び出しを設定し、その呼び出しに対して課金するため）を公開することができる。付加的な例として、電気通信アーキテクチャ１００は、「課金」サービス（アカウントに対して課金請求を要求するため）、「インターネットプロトコルテレビジョン（ＩＰＴＶ）」サービス（テレビジョン番組の配信を要求するため）、「ユーザステータス」サービス（「オンライン」、「オフライン」、「話し中」、又は「不在」のような現在のユーザステータスを要求するため）、及びユーザ認証サービス（例えば、モバイルユーザが存在するか否か、及びそのモバイルユーザが「ＩＰＴＶ」サービスのような望ましいサービスを購入するための資格を有するか否かの証明を要求するため）を公開することができる。他の機能は、追加的に又は代替として提供することができる。更に、電気通信アーキテクチャ１００はまた、第三者アクセスゲートウェイ１１０を通じて通信ネットワークサービス（例えば、「インターネット」閲覧サービス）へのアクセスを提供することができる。
電気通信アーキテクチャ１００は、公開されたサービスへのアクセスを保護する。その目的のために、アーキテクチャ１００は、第三者アクセスゲートウェイ１１０を提供する。第三者アクセスゲートウェイ１１０は、第三者１０２に対して公開されたサービスへの単一の点としての役割を達成する。

図１に示すように、第三者アクセスゲートウェイ１１０は、第三者１０２からサービス要求１１２を受信する。それに応答して、第三者アクセスゲートウェイ１１０は、サービス要求が、認証された又は許可された第三者から発せられたものであることを確認する。ネットワーク通信サービス要求の場合は（一例として）、第三者アクセスゲートウェイ１１０は、許可されたサービス要求を処理し、そのサービス要求をサービスプロバイダ１１４に中継する。「ＳＭＳ」、「ＭＭＳ」、及び「ＳＩＰ」サービス要求のような公開されたサービス要求の場合には、第三者アクセスゲートウェイ１１０は、許可されたサービス要求を処理し、サービスブローカー１１６に中継する。

サービスブローカー１１６は、サービス要求を実行する。それを行う際に、サービスブローカー１１６は、電気通信製品及びサービスを作成、配備、管理、及び維持するためにアーキテクチャ１００が実施する「ビジネスサポートシステム（ＢＢＳ）」及び「オペレーションサポートシステム（ＯＳＳ）」１１８と通信することができる。例えば、「ＯＳＳ／ＢＳＳ」システム１１８は、請求システム、ディレクトリ及びプレゼンスシステム、認証システム、サービス提供システム、又は他のサポートシステムを含むことができる。サービス要求の実行において、サービスブローカー１１６は、サービス関連データをサービスブローカー１１６に配信又は返信することができるネットワーク層１２０と追加的に又は選択的に通信することができる。サービスプロバイダ１１４及びサービスブローカー１１６からの応答は、発信元の第三者の要求者への配信のために第三者アクセスゲートウェイ１１０に返信される。

第三者アクセスゲートウェイ１１０は、第三者１０２と電気通信アーキテクチャ１００内に実施される公開された機能性との間にセキュリティ層を提供する。同時に、サービスブローカー１１６は、柔軟かつ効率的に第三者のサービス要求を処理するためのアーキテクチャ層を提供する。すなわち、アーキテクチャ１００は、サービスプロバイダが第三者１０２に向けて核心機能性を公開し、第三者１０２からのサービス要求を安全で標準化かつ制御された方法で処理することを可能にする。

図１はまた、サービスブローカー１１６と通信状態にある顧客関係管理（ＣＲＭ）システム１２２を示している。下記で更に詳述することになるが、「ＣＲＭ」システム１２２もまた、サービスブローカー１１６にサービス要求を公開することができる。例えば、「ＣＲＭ」システム１２２によって提出されるサービス要求は、サービスのアクティブ化、一時停止、再開、又は終了を含むことができる。要求は、電気通信製品及びサービス（例えば、セルラー電話サービス）を確立、一時停止、又は終了するための顧客支援担当者の「ＣＲＭ」システム１２２との対話からもたらすことができる。

各サービス要求は、サービスタイプ識別子フィールド及びサービス要求識別子フィールドを含むことができる。下記の説明において、「ＴＳＯ＿ＬＡＢＥＬ」フィールドは、サービスタイプ識別子フィールドを提供し、「ＴＳＯ＿ＩＤ」フィールドは、サービス要求識別子フィールドを提供する。サービス要求内の「ＴＳＯ＿ＬＡＢＥＬ」は、要求されたサービスのタイプ（例えば、特定の製品又はサービスをアクティブ化する要求）を指定するサービスタイプ識別子である。サービス要求内の「ＴＳＯ＿ＩＤ」は、サービス要求自体の識別子（例えば、固有識別子）を提供するサービス要求識別子である。

図２は、サービスブローカー１１６の一実施例の更に詳細な図を示している。上述のように、サービスブローカー１１６は、サービス要求インタフェース２０１を通じて「ＯＳＳ／ＢＳＳ」システム１１８を含む外部システム、第三者ゲートウェイ１１０、及び「ＣＲＭ」システム１２２に接続する。サービス要求インタフェースは、物理アダプタ、論理アダプタ、又は物理及び論理アダプタの両方を含むことができる。「ＯＳＳ／ＢＳＳ」システムは、物理アダプタ２０２及び論理アダプタ２０８を通じてサービスブローカー１１６に接続し、第三者ゲートウェイは、物理アダプタ２０４及び論理アダプタ２１０を通じてサービスブローカー１１６と接続し、「ＣＲＭ」システムは、物理アダプタ２０６及び論理アダプタ２１２を通じてサービスブローカーと接続する。

物理アダプタ２０２〜２０６は、外部システムとサービスブローカーの間の通信を統御する通信ソフトウエアによって実施することができる。論理アダプタ２０８〜２１２は、サービスブローカーと外部システムの異なるデータモデル間でメッセージマッピングを実行するデータ変換プログラム、マッパー、及び／又はトランスフォーマーを表している。論理アダプタ２０８〜２１２は、外部システムからのメッセージデータが、サービスブローカー１１６が予想する形式でサービスブローカー１１６に到着することを保証する。一実施例では、アダプタ２０８〜２１２は、１つのスキーマによって定義されたフォーマット（例えば、メッセージが第三者ゲートウェイ１１０内に添付するためのＸＭＬスキーマ）から別のスキーマによって定義された別のフォーマット（例えば、サービスブローカー１１６が受信するメッセージのためのＸＭＬスキーマ）へのメッセージ及び／又はメッセージコンテントの変換をサポートする。

メッセージ公開システム２１４は、外部システムとサービスブローカー１１６との間でメッセージを通信するメッセージバスを提供する。更に、メッセージバスは、サービスブローカー１１６自体の構成要素間のメッセージを通信することができる。メッセージ公開システム２１４は、あるトピックに割り当てられたメッセージを受信し、そのトピックに対する加入者にメッセージを公開する。加入者は、処理システム（例えば、システム１１０、１１８、及び１２２）、プログラム、又は他のエンティティとすることができる。しかし、他の実施例では、バッチファイル転送、共有ファイル又はメモリ、又は他の相互処理通信技術を含む、他のメッセージ通信技術を用いることができる。

メッセージ公開システム及びアダプタ２０２〜２１２は、例えば、カリフォルニア州パロアルト所在の「ＴＩＢＣＯ Ｓｏｆｔｗａｒｅ Ｉｎｃ．」から入手可能な「ＴＩＢＣＯアダプタ（登録商標）」及び「ＴＩＢＣＯ Ｒｅｎｄｅｚｖｏｕｓ（登録商標）」メッセージングによって実施することができる。他の実施例では、物理アダプタは、カリフォルニア州サンホゼ所在の「ＢＥＡ ｓｙｓｔｅｍｓ」から入手可能な「ＢＥＡ Ｗｅｂｌｏｇｉｃ」統合制御によって実施することができる。一実施例では、メッセージは、「拡張可能マークアップ言語（ＸＭＬ）」のメッセージであり、アダプタは、「変換用拡張可能スタイルシート言語（ＸＳＬＴ）」のスタイルシートに従って変換を実行する。変換は、「ＸＭＬ」、「ハイパーテキスト伝送プロトコル（ＨＴＴＰ）」、「簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）」、「Ｗｅｂサービス定義言語（ＷＳＤＬ）」、「拡張可能スキームダイアグラム（ＸＳＤ）」、「Ｊａｖａ（登録商標）データベース接続性／オープンデータベース接続性（ＪＤＢＣ／ＯＤＢＣ）」、又は他のメッセージフォーマット、コンテント規格、又は通信プロトコルのうちのいずれかのためのスキーマ間でデータを変換することができる。

サービスブローカー１１６はまた、着信サービス要求をサービス要求待ち行列２１８の中に分配するディスパッチャーシステム２１６を含む。サービス要求待ち行列２１８は、特定タイプのサービス要求に割り当てられた１つ又はそれよりも多くの独立した待ち行列を含むことができる。図２に示されている例では、サービス待ち行列２１８は、第三者ゲートウェイ１１０から受信したサービス要求を待ち行列に入れる１つ又はそれよりも多くの第三者ゲートウェイサービス要求待ち行列２２０、及び「ＣＲＭ」システム１２２からのサービス要求を待ち行列に入れる１つ又はそれよりも多くの顧客関係管理待ち行列２３２を含む。

例えば、第三者ゲートウェイサービス要求待ち行列２２０は、メッセージサービス要求待ち行列２２４（例えば、「ＳＭＳ」又は「ＭＭＳ」メッセージ配信要求を待ち行列に入れるための）、及び「課金」サービス要求待ち行列２２６（例えば、課金要求を待ち行列に入れるための）を含むことができる。待ち行列２２０の付加的な例は、「認証」要求待ち行列及び「ステータス」要求待ち行列を含む。同様に、「ＣＲＭ」待ち行列２２２は、「サービスアクティブ化」要求待ち行列２２８、「サービス終了」要求待ち行列２３０、及び「ＣＲＭ」システム１２２から受信するサービス要求に対する他の待ち行列を含むことができる。待ち行列２２０及び２２２は、上述のタイプ及び個数に限定されてはいない。むしろ、１つ又はそれよりも多くの待ち行列は、いずれか１つ又はそれよりも多くのサービス要求者から受信するいずれか１つ又はそれよりも多くのタイプのサービス要求を待ち行列に入れるように実施し、かつ割り当てることができる。

サービスブローカー１１６は、フェッチャーシステム２３２を含む。トラフィック制御パラメータ２３４の制御下で、フェッチャーシステム２３２は、サービス待ち行列２１８から待機サービス要求を検索する。次に、フェッチャーシステム２３２は、検索済みサービス要求をワークフローシステム２３６に配信する。ワークフローシステム２３６は、サービス要求を実施するために所定の順序でのワークフロー段階の実行を判断して要求するワークフローエンジン（例えば、ワークフローエンジン２３８、２４０、２４２）の実行を開始する。

例えば、「ＳＭＳ」メッセージを配信し、それに対して課金を行うために、ワークフローシステム２３６は、「ＳＭＳ」ワークフローエンジンの実行を開始することができ、このエンジンは、1つの段階として、「ＳＭＳ」メッセージに対して課金するように請求システムに請求要求を出し、別の段階として、そのメッセージを送信するように「ＳＭＳ」システムにメッセージ送信要求を出す。ワークフローシステム２３６は、カリフォルニア州パロアルト所在の「ＴＩＢＣＯ Ｓｏｆｔｗａｒｅ Ｉｎｃ．」から入手可能な「Ｔｉｂｃｏ ＩｎＣｏｎｃｅｒｔ（登録商標）」ワークフローエンジン又は他のワークフローシステムによって実施することができる。

サービスブローカーはまた、技術指令管理（ＴＯＭ）データベース２４０を含む。「ＴＯＭ」データベースは、サービス要求を満足させるワークフローにおいて実行されるべき一組の技術サービス指令段階を定義する構成ルールを格納する。「ＴＯＭ」データベース２４０は、下記で更に詳述される。
図３は、サービスブローカー３０２の代替的な実施例を示している。サービスブローカー３０２は、第２のフェッチャーシステム３０４を含む。第２のフェッチャーシステム３０４も同様に、トラフィック制御パラメータ２３４の制御下でサービス待ち行列２１８からサービス要求を検索する。代替的に、第２のフェッチャーシステム３０４は、独立した一組のトラフィック制御パラメータの制御下で作動することができる。付加的なフェッチャーシステム及びトラフィック制御パラメータの組を提供することができる。

第２のフェッチャーシステム３０４は、フェッチャーシステム２３２とは異なるワークフロー要求配信技術を用いる。特に、第２のフェッチャーシステム３０４は、システム２１４のようなメッセージ公開システムにワークフロー要求メッセージを公開する。次に、メッセージ公開システム２１４は、メッセージ公開システム２１４におけるワークフロー要求メッセージに加入している第２のワークフローシステム３０６にワークフロー要求メッセージを配信することができる。言い換えれば、メッセージ公開システム２１４は、第２のフェッチャーシステム３０４をワークフローシーケンスの直接呼び出しという負担及び問題から解放する。

代わりに、第２のワークフローシステム３０６は、公開されたワークフロー要求メッセージを受信し、サービス要求を実施するためにワークフローの実行を開始する。第２のワークフローシステム３０６は、第１のワークフローシステム２３６と同一の方法で実施される必要はない。図３に示されている例では、第２のワークフローシステム３０６は、インバウンド要求マネージャ３０８、ワークフローエンジン３１０、及び並列タスクマネージャ３１２を含む。アクションマネージャ３２０及びアクションビルダ３２２を含むアクションエンジン３１８は、ワークフロー内のネットワークサービス提供アクションを実行する。各々は、下記で更に詳述される。

第２のワークフローシステム３０６の追加は、いくつかの利益を発生させる。特に、第２のワークフローシステム３０６は、第１のフェッチャーシステム２３２を通じてワークフローシステム２３６を直接呼び出すことによってサービス要求を処理するという潜在的問題の除去に役立つ。更に、第１のフェッチャーシステム２３２及び第２のフェッチャーシステム３０４は、一緒に実行することができ、これは、サービス要求を並列に処理することにより端末間の性能を改善させるだけでなく、サービス要求を処理するための２つの独立したフェッチャー／ワークフローエンジンシステムを提供することによって強力な耐障害性エンジンシステムを達成する。

サービスブローカー３０２又は１１６はまた、ウェブエラー・グラフィカルユーザインタフェース（ＧＵＩ）を含むことができる。図３は、第２のフェッチャーシステム３０４に設けられたウェブエラー「ＧＵＩ」３１４の例を示している。ウェブエラー「ＧＵＩ」３１４は、「ウェブ」サーバ（例えば、カリフォルニア州サンホゼ所在の「ＢＥＡ Ｓｙｓｔｅｍｓ」から入手可能な「Ｗｅｂｌｏｇｉｃアプリケーション」サーバ）を実行する「Ｊａｖａ（登録商標）」サーバページの「ウェブ」アプリケーションとして実施することができる。

ウェブエラー「ＧＵＩ」３１４は、サービス要求処理中に遭遇するあらゆるエラーに関する情報をユーザインタフェースディスプレイに掲載する。ウェブエラー「ＧＵＩ」３１４はまた、入力機構を提供することができ、それによって検閲者は、修正入力（例えば、データを変更するか、又はサービス要求内の欠損データを完成させるか、又はサービス要求又はタスクを修正するためにワークフロータスクをサポートする入力）を与え、サービス要求又はタスクを手動で完成させるか又は処理のためにサービス要求又はタスクを再提出する。

一実施例では、エラーに遭遇した各サービス要求は、ウェブエラー「ＧＵＩ」において説明的なタイトル及びサービス要求特性の付加的な詳細へのハイパーリンクによって表すことができる。ウェブエラー「ＧＵＩ」３１４は、更に検索インタフェースを提供することができる。検索インタフェースは、検索判断基準（例えば、「ＭＳＩＳＤＮ」番号、「ＴＳＯ＿ＩＤ」、データ範囲、サービス要求タイプ、エラーコード、顧客又は他の識別子、又はサービス要求の他のあらゆる特性）を受け入れ、適合するエラー記録の応答的検索及び表示を実行する。ハイパーリンク上のクリックは、ウェブエラー「ＧＵＩ」３１４に選択されたサービス要求に特定のエラー情報、及びそのサービス要求について入手可能な追加特性（例えば、要求タイプ、「ＩＭＳＩ」番号、「ＭＳＩＳＤＮ」番号、送信者、受信者、メッセージテキスト、顧客名及び住所、又は他のあらゆる特性）のディスプレイへの掲載を誘発する。

ウェブエラー「ＧＵＩ」３１４は、検閲者からの修正入力を受け入れる。検閲者は、ウェブエラー「ＧＵＩ」３１４に修正済みサービス、タスク、又はアクションをフェッチャーシステム３０４に再公開するように指示することができる。フェッチャーシステム３０４は、修正済みサービス要求メッセージを受信し、修正済みサービス要求、タスク、又はアクションを元の場所で処理する。この方法で、フェッチャーシステム３０４は、元のサービス要求がエラーに遭遇した点で既にインスタンスが生成されているワークフローを継続することによって貴重な時間と処理リソースを節約する。

同様に別々のウェブエラー「ＧＵＩ」を第１のフェッチャーシステム２３２に対して提供することができる。メッセージ公開システム２１４を用いる他に、第１のフェッチャーシステム２３２に対するウェブエラー「ＧＵＩ」は、ＡＰＩ内に定義された関数呼び出しを通じてエラー情報を通信することができる。関数呼び出しは、「Ｔｉｂｃｏ ＩｎＣｏｎｃｅｒｔ（登録商標）」ワークフローエンジンによって達成することができ、ウェブエラー「ＧＵＩ」３１４について上述したように、このウェブエラー「ＧＵＩ」は、エラー情報を報告し、修正入力を受け入れることができる。

サービスブローカーはまた、ワークフロー「ＧＵＩ」３２４を提供することができる。ワークフロー「ＧＵＩ」３２４は、ワークフロー定義のためにグラフィカルインタフェースを提供し、これは、サービスブローカーに多大な構成可能性を提供する。ワークフロー「ＧＵＩ」３２４は、ドラッグアンドドロップインタフェースを実施し、これを通じてオペレータは、新しいワークフローを作成するためにタスクを選択して順序付けることができる。

図３は、オペレータが４つのタスク３２６，３２８、３３０、及び３３２を順番に配列して新しいワークフロー３３４を形成する一例を示している。サービスプロバイダが望むあらゆる機能に対してサービスブローカーをカスタマイズする新しいワークフローを定義するために、あらゆる個数のタスクをあらゆる順序で配列することができる。ワークフロー「ＧＵＩ」３２４は、「ＴＯＭ」データベース内に定義された所定のワークフロー、タスク、及びアクションの１つ又はそれよりも多くについてワークフロー、タスク、及びアクションのグラフィカルな表現をもたらすことができる。ワークフロー、タスク、及びアクションは、ワークフローテーブル９０２、タスク構成テーブル９０４、及び／又はアクションテーブル９０６内に定義されたワークフロー、タスク、及びアクションを表すことができ、これらは下記に説明される。

拡張「ＴＯＭ」データベース３１６もまた、サービスブローカー３０２内に存在する。拡張「ＴＯＭ」データベース３１６は、第２のワークフローシステム３０６及びウェブエラー「ＧＵＩ」３１４をサポートするために第１の「ＴＯＭ」データベース２４４を拡張する。下記でより詳細に説明することになるが、拡張「ＴＯＭ」データベース３１６は、特定のサービス要求を実施するために取られるべきタスク及びアクションのシーケンスを定義し、ウェブエラー「ＧＵＩ」３１４のために報告テーブルを提供する。

図４は、トラフィック制御パラメータ２３４の例を示している。特に、図４は機能名パラメータ４０２、プールサイズパラメータ４０４，及びポーリング時間パラメータ４０６を示している。図４はまた、提出タイマパラメータ４０８、判断基準パラメータ４１０、及び待機パラメータ４１２を示している。付加的なトラフィック制御パラメータは、待ちパラメータ４１４，制御ロックパラメータ４１６、及びデータパラメータ４１８を含む。

下記の表１は、各トラフィック制御パラメータ２３４に関する説明を提供する。

トラフィック制御パラメータ２３４は、作動時にフェッチャーシステム２３２及び３０４を動的に再構成することができる。この目的のために、トラフィック制御パラメータ２３４は、フェッチャーシステム２３２及び３０４内部のトラフィック制御マネージャ処理と通信することができる（例えば、「ＵＲＬ」内にパラメータを埋め込んだ「ＨＴＴＰ」接続を通じて）。次に、トラフィック制御マネージャは、サービス要求ブロックの次の検索のために新しパラメータによって内部変数を設定することができる。

図５は、ディスパッチャー２１６の実施の例である。ディスパッチャー２１６は、メモリ５０４に連結されたプロセッサ５０２を含むことができる。メモリ５０４は、ディスパッチプログラム５０６を格納する。ディスパッチプログラム５０６は、マルチスレッド処理とすることができる。メモリ５０４はまた、ディスパッチプログラム５０６よる処理に向けたインバウンドメッセージ５０８を保持する。インバウンドメッセージ５０８は、技術サービス指令ラベル（ＴＳＯ＿ＬＡＢＥＬ）フィールド５１０、「ＴＳＯ＿ＩＤ」フィールド５１１、及び更にサービス要求を定義する（例えば、「ＳＭＳ」メッセージデータ、受信者、又はサービス要求をサポートする他のデータを指定することにより）サービス要求メッセージデータ５１２を含む。「ＴＳＯ＿ＬＡＢＥＬ」フィールドは、要求されたサービスを表すサービスタイプ識別子フィールドを提供する。

インバウンドメッセージ５０８は、メッセージ内の各データ要素の周囲に識別タグを含む「拡張可能マークアップ言語（ＸＭＬ）」メッセージとすることができる。ディスパッチプログラム５０６は、インバウンドメッセージ５０８内の「ＸＭＬ」データを吟味し、「ＸＭＬ」データ内のタグが付けられたフィールドに基づいてサービス待ち行列２１８内のサービス要求記録を設定する。特に、サービス識別子フィールドに基づいて（例えば、「ＴＳＯ＿ＬＡＢＥＬ」に基づいて）、ディスパッチプログラム５０６は、「ＴＳＯ＿ＬＡＢＥＬ」５１０に基づいて特定のサービス待ち行列内のサービス要求記録を設定する。言い換えれば、「ＴＳＯ＿ＬＡＢＥＬ」５１０は、ディスパッチプログラム５０６のためにサービス要求のタイプ、従って、サービス要求が存在すべき適切なサービス待ち行列を識別する。

サービス待ち行列２１８は、データベーステーブルとして実施することができる。図５は、サービス待ち行列２１８内で定義することができるサービス要求記録５１４の例を示している。しかし、他のサービス要求記録定義を実施することもできる。サービス要求記録５１４のフィールドは、下記に表２において説明する。

「ＴＳＯ＿ＩＤ」、「ＴＳＯ＿ＬＡＢＥＬ」、及び「ＴＳＯ＿ＤＡＴＥ」は、別々のフィールドに格納される。ディスパッチプログラム５０６がインバウンドメッセージ５０８を受信すると、ディスパッチプログラムは、メッセージ５０８から「ＴＳＯ＿ＩＤ」、「ＴＳＯ＿ＬＡＢＥＬ」、及び「ＴＳＯ＿ＤＡＴＥ」データを別々に抽出し、サービス要求記録５１４内の対応するフィールド内にそのデータを格納することができる。従って、フェッチャーシステム２３２及び３０４は、あらゆるフィールド又はフィールドの組合せによって待ち行列テーブルから列データを抽出することができる。

一実施例では、ディスパッチプログラム５０６がサービス待ち行列テーブル内の列に新しいサービス要求記録５１４を挿入すると、ディスパッチプログラム５０６は、以下のフィールドにデータを挿入する。
ＴＳＯ＿ＩＤ
ＴＳＯ＿ＬＡＢＥＬ
ＴＳＯ＿ＤＡＴＥ
ＸＭＬ＿ＩＮ
ＢＰ＿ＦＬＡＧ＝０
ＡＰ＿ＦＬＡＧ＝０
ＩＮＳ＿ＴＭＳ＝システム日付

図６は、フェッチャーシステム２３２の実施を示している。フェッチャーシステム２３２は、メモリ６０４に連結されたプロセッサ６０２を含む。メモリ６０４は、フェッチャープログラム６０６（例えば、マルチスレッド処理）を格納する。メモリはまた、サービス要求記録列リスト６０８を保持する。サービス要求記録列リスト６０８内のエントリは、サービス待ち行列２１８内のサービス要求を提示している。

トラフィック制御パラメータ２３４に従って、フェッチャープログラム６０６は、サービス待ち行列２１８をポーリングする。フェッチャープログラム６０６は、選択されたサービス要求記録から「ＴＳＯ＿ＩＤ」のプールを検索する。フェッチャープログラム６０６は、サービス待ち行列２１８内のテーブルにアクセスするために、格納された「構造化照会言語（ＳＱＬ）」手順を呼び出すことができる。

格納された手順は、サービス待ち行列２１８内の各列に対して「ＢＰ＿ＦＬＡＧ」を１に設定することができ、これは、フェッチャーシステムによって与えられる検索判断基準を満たすものである。格納された手順は、検索判断基準を満たす列の列リスト６０８をフェッチャーシステム２３２に返信する。列リスト６０８は、各適合したサービス要求記録からの「ＴＳＯ＿ＩＤ」フィールドを含むことができる。

フェッチャープログラム６０６は、格納された手順から列リスト６０８を取得する。次に、フェッチャープログラム６０６は、列リスト６０８をワークフロー呼び出しプログラム６１０に渡す。ワークフロー呼び出しプログラム６１０は、列リスト内で識別される、サービス要求記録内に表された各サービス要求を実施する適切なワークフローの実行を開始するためにワークフローシステム２３６を呼び出す。
より具体的には、ワークフロー呼び出しプログラム６１０は、列リスト６０８を各列について非同期に処理する。ワークフロー呼び出しプログラム６１０は、トラフィック制御パラメータ２３４内で指定される「ＷＡＩＴ」時間の間待っている。「ＷＡＩＴ」時間が満了すると、ワークフロー呼び出しプログラム６１０は、現時点で処理中のサービス要求に対して「ＢＰ＿ＦＬＡＧ」を「２」に設定する。

次に、ワークフロー呼び出しプログラム６１０は、現在の列に関するサービス要求を実施するワークフローを開始するためにワークフローシステム２３６を直接呼び出す。ワークフローを開始するための呼び出しにおいては、ワークフロー呼び出しプログラム６１０は、ワークフローシステム２３６に「ＴＳＯ＿ＩＤ」フィールドを非同期に渡すことができる。次に、ワークフロー呼び出しプログラム６１０は、ワークフローが呼び出されたことを表すために「ＢＰ＿ＦＬＡＧ」を「３」に設定する。

ワークフローシステム２３６では、ワークフローエンジンは、特定のサービス要求を実施するワークフロー段階（例えば、タスク、アクション、及び「ＴＳＯ」）を実行する。サービス要求の実施において、ワークフローエンジンを実行する第１のタスクは待ち行列テーブルから「ＸＭＬ＿ＩＮ」データを検索することである。ワークフローエンジンは、フェッチャーシステム２３２によって与えられる「ＴＳＯ＿ＩＤ」に適合するサービス要求記録から「ＸＭＬ＿ＩＮ」データを検索する。それによってサービスワークフローは、要求されたサービスに対するデータのサポートを含む要求されたサービスの完全な定義を取得する。例えば、「ＳＭＳ」メッセージ配信に関する「ＸＭＬ＿ＩＮ」データは、メッセージテキスト及び受信者の識別子を含むことになる。

「ＴＳＯ＿ＬＡＢＥＬ」フィールドは、要求されたサービスを指定する。ワークフローは、要求されたサービスを実施するタスクを実行する。「ＳＭＳ」メッセージ配信においては、例えば、ワークフローエンジンは、請求システムに課金メッセージを送信することができ、その後「ＳＭＳ」配信サブシステムにメッセージテキストを送信することができる。ワークフローエンジンはまた、サービス要求処理の結果を返信する。例えば、ワークフローは、詳細説明、又はサービス要求処理から生じる他のあらゆる情報を任意的に添えて成功メッセージ又はエラーメッセージを返信することができる。

ワークフローは、適切な「ＴＳＯ＿ＩＤ」に関するサービス要求記録を更新することによって終了する。ワークフローエンジンは、サービス要求記録の中に「ＸＭＬ＿ＯＵＴ」文字列を書き込む。「ＸＭＬ＿ＯＵＴ」文字列は、サービス要求処理の結果を含むことができる。更に、ワークフローエンジンは、ワークフローが終了したことを表すために「ＡＰ＿ＦＬＡＧ」を「１」に設定し、「ＥＮＤ＿ＴＭＳ」を現在のシステム日付に設定する（すなわち、ワークフロー終了の日付／時間）。

ワークフローエンジンは、技術指令管理（ＴＯＭ）データベース２４４を参考にして実行すべきタスク及びアクション、及び実行の順序を判断する。図７は、「ＴＯＭ」データベース２４４に対するデータモデルの一実施例を示している。データモデルは、図７に示されている実施例に限定されてはおらず、むしろデータモデルが用いられる特定の実施例に従って広範に変化する。「ＴＯＭ」データベース２４４は、「サービス技術指令カタログ（ＳＴＯＣ）」テーブル７０２、「アクション」テーブル７０４、及び「ＳＴＯＣ」パラメータテーブル７０６を含む。「ＴＯＭ」データベース２４４は、「「ＣｌａｓｓＢｕｉｌｄ」テーブル７０８、「ＰｕｔＳｅｑｕｅｎｃｅＩｎＣｌａｓｓテーブル」７１０、及び「ＳｅｑｕｅｎｃｅＢｕｉｌｄテーブル」７１２を更に含む。

「ＳＴＯＣ」テーブルは、主要キーとしての「ＳＴＯＣ＿ＩＤ」フィールド７１４、及び追加フィールド７１６を含む。「アクション」テーブルは、主要キーとしての「Ａｃｔｉｏｎ＿ＩＤ」フィールド７１８、及び追加フィールド７２０を含む。「ＳＴＯＣＰａｒａｍ」テーブル７０６は、主要キーとしての「ＳＴＯＣＰａｒａｍ＿ＩＤ」フィールド７２２、及び追加フィールド７２４を含む。「ＣｌａｓｓＢｕｉｌｄ」テーブル７０８は、主要キーとしての「Ｐａｒａｍ＿ＩＤ」フィールド７２６、及び追加フィールド７２８を含む。「ＰｕｔＳｅｑｕｅｎｃｅＩｎＣｌａｓｓ」テーブル７１０は、主要キーとしての「ＰｕｔＳｅｑｕｅｎｃｅ＿ＩＤ」フィールド７３０、及び追加フィールド７３２を含む。「ＳｅｑｕｅｎｃｅＢｕｉｌｄ」テーブル７１２は、主要キーとしての「Ｓｅｑｕｅｎｃｅ＿ＩＤ」フィールド７３４、及び追加フィールド７３６を含む。

「ＳＴＯＣ」テーブル７０２は、サービス要求を統御するための「技術サービス指令（ＴＳＯ）」と呼ばれる、ワークフロー段階のワークフローテンプレートを定義する。「アクション」テーブル７０４は、あらゆる所定のサービス要求を満足させるために実行されるべき「ＴＳＯ」（すなわち、アクション）及びそれらの実行順序を定義し、それらを「ＳＴＯＣ」テーブルに連結して戻す。一部の実施例では、データベース２２８は、「アクション」テーブル７０４と同様な「逆アクション」テーブルを定義することができる。ワークフロー内でのアクションの処理中にエラーが発生すると、関連の「逆アクション」を実行することができる。「逆アクション」は、顧客アカウントステータス、注文ステータス、又は独立した処理システム間の他のデータと同期させることができる。「ＴＯＭ」データベース２４４は、サービス要求者から受信することができるか又はワークフローエンジン自体によって与えることができるアクションに関するパラメータを更に定義する。追加フィールドを含む各テーブル７０２〜７１２は、下記においてより詳細に説明される。

ワークフローシステム２３６は、サービス指令処理を２つのタスクに分割する。第１のタスクは、「ＴＯＭ」データベース２４４内でワークフロー定義を検索することによってサービス要求が「ＴＳＯ」の中に分割される方法を判断することである。第２のタスクは、「ＴＳＯ」を正しいシーケンスで送信し、応答を受信し、エラーを処理することによってこれらの「ＴＳＯ」を管理することである。
「ＴＳＯ＿ＬＡＢＥＬ」及び「ＴＯＭ」データベース２４４内に設定された定義に基づいて、ワークフローシステム２３６は、実行すべき「ＴＳＯ」の組及びそれらの順序を判断する。ワークフローシステム２３６はまた、実行されるべき各「ＴＳＯ」に対して属性リストを構築する。属性は、サービス要求者（例えば、「ＣＲＭ」システム１２２）によって全体を又は部分的に指定することができ、また、「ＴＯＭ」データベース２４４によっても全体を又は部分的に指定することができる。「ＴＳＯ」が実行されると、ワークフローエンジンは、実行すべき現時点の「ＴＳＯ」を提示するインデックスを増分する。

ワークフローエンジンは、「ＴＳＯ」の実行を要求するメッセージを構築する。例えば、メッセージは、全体のサービス要求の実施の一部としてメッセージ内に指定されたアクションを実行するサービス提供システムに対して公開することができる。「ＴＯＭ」データベース２４４は、メッセージ構築をサポートし、「ＴＳＯ」が実行すべき指令、「ＴＳＯ」に関する属性（「ＴＯＭ」データベース２４４内で指定される静的属性、及びサービス要求者によって提出される動的属性）、メッセージが公開されるサブジェクト、及び上述の他のパラメータを提供する。
このように、「ＴＯＭ」データベース２４４は、「ＴＳＯ＿ＬＡＢＥＬ」に関連するサービス要求ワークフローを、サービス要求を実施する一組の「ＴＳＯ」に分割する構成ルールを提供する。それによって「ＴＯＭ」データベース２４４は、ワークフロー、ワークフローを実施する「ＴＳＯ」、及び「ＴＳＯ」を実行する順序を定義するための極めて柔軟で再構成可能な拡張性のある機構を提供する。

図８は、第２のフェッチャーシステム３０４の実施例を示している。フェッチャーシステム３０４は、メモリ８０４に連結されたプロセッサ８０２を含むことができる。メモリ８０４は、フェッチャープログラム８０６（例えば、マルチスレッド処理）を格納する。メモリはまた、サービス要求記録列リスト８０８を保持する。サービス要求記録列リスト８０８内のエントリは、第三者ゲートウェイ１１０、「ＣＲＭ」システム１２２、又は他のあらゆる外部サービス要求者によって提出され、サービス待ち行列２１８内で待機しているサービス要求を提示している。

トラフィック制御パラメータ２３４（又は、フェッチャーシステム３０４に対して設定されたトラフィック制御パラメータの独立した一組）に従って、フェッチャープログラム８０６は、サービス待ち行列２１８をポーリングする。フェッチャープログラム８０６は、適合するサービス要求記録を「ＴＳＯ＿ＩＤ」ブロックから検索する。フェッチャープログラム８０６は、サービス待ち行列２１８内のテーブルへのアクセスのために格納された「構造化照会言語（ＳＱＬ）」手順を実行することができる。
処理されるべき各サービス要求に対して、フェッチャープログラムは、インスタンスマネージャプログラム８１４を呼び出す。インスタンスマネージャプログラムは、「ＴＯＭ」データベース３１６内のテーブルにデータを追加し、サービス要求に対するワークフローテーブルのインスタンスを作成する。「ＴＯＭ」データベーステーブルは、下記で更に詳述される。

フェッチャープログラム８０６は、列リスト８０８をメッセージ公開プログラム８１０に渡す。メッセージ公開プログラム８１０は、第２のワークフローシステム３０６にワークフロー要求メッセージ８１２（サービス要求を指定する）を公開する。すなわち、フェッチャーシステム３０４は、メッセージ公開システム２１４が第２のワークフローシステム３０６にワークフロー要求メッセージを配信することを可能にすることにより、ワークフローエンジンを直接呼び出すという潜在的問題を除去する。ワークフロー要求メッセージは、「ＴＳＯ＿ＩＤ」（「ＴＳＯ＿ＩＤ」フィールド８１４内）及び「ＴＳＯ＿ＬＡＢＥＬ」（「ＴＳＯ＿ＬＡＢＥＬ」フィールド８１６内）を指定することができる。「ＴＳＯ＿ＩＤ」及び「ＴＳＯ＿ＬＡＢＥＬ」は、サービス待ち行列２１８内のサービス記録から得られる。フェッチャーシステム３０４は、各ワークフロー要求メッセージを公開した後にメッセージ公開システム２１４からの応答を待つことができる。
より具体的には、要求／回答メッセージは、下記の表９〜１２に示すように定義することができる。

図９は、第２のフェッチャーシステム３０４をサポートする、「ＴＯＭ」データベース３１６内にある拡張を示している。サービス要求を実施するために取る段階のシーケンスは、「Ｗｏｒｋｆｌｏｗｓ」テーブル９０２、「Ｔａｓｋ＿ｃｆｇ」テーブル９０４、及び「アクション」テーブル９０６によって定義される。特に、「Ｗｏｒｋｆｌｏｗｓ」テーブル９０２は、ワークフローテンプレートを定義し、「Ｔａｓｋ＿ｃｆｇ」テーブル９０４は、ワークフローを実施するタスクを定義し、「アクション」テーブル９０６は、各タスクに関連するアクションを定義する。タスク及びアクションは、例えば、外部「Ｔｉｂｃｏ ＢｕｓｉｎｅｓｓＷｏｒｋｓ（登録商標）」処理システムにおいて実行される処理によって実行することができる。サポートするタスクインスタンステーブル９０８及びサポートするアクションインスタンステーブル９１０もまた存在する。各テーブルは、下記で更に詳述される。

「ＴＡＳＫ＿ＩＮＳＴ」テーブル９０８は、「ＴＡＳＫ＿ＣＦＧ」テーブル９０４と同一のフィールド、及び以下の追加フィールドを含むことができる。

「ＡＣＴＩＯＮ＿ＩＮＳＴ」テーブル９１０は、「アクション」テーブル９０６と同一のフィールド、及び以下の追加フィールドを含むことができる。

更に、拡張「ＴＯＭ」データベース３１６は、ウェブエラー「ＧＵＩ」３１４に対してサポートを提供する。特に、拡張「ＴＯＭ」データベース３１６は、「ＧＵＩユーザ」テーブル９１２、「ＧＵＩ」役割テーブル９１４，及び「ＧＵＩ」ステータステーブル９１６を含む。同じく含まれているのは、「ＧＵＩ」履歴テーブル９１８である。各テーブルは、下記で更に詳述される。

各サービス要求に対して、対応するサービス要求メッセージ公開の前に、インスタンスマネージャプログラム８１４は、「ＴＡＳＫ＿ＩＮＳＴ」テーブル９０８に実行されるべきワークフロータスクを追加する。インスタンスマネージャプログラム８１４はまた、「ＡＣＴＩＯＮ＿ＩＮＳＴ」テーブル９１０に各タスク内のサービス提供アクションを追加する。テーブル９０８及び９１０に加わるデータは、カタログテーブル９０２、９０４、及び９０６内に定義されたテンプレートから得られる。すなわち、処理されるべき各サービス要求は、「ＴＡＳＫ＿ＩＮＳＴ」テーブル９０８及び「ＡＣＴＩＯＮ＿ＩＮＳＴ」９１０において準備が整った、インスタンスが生成されたワークフローを有する。
第２のワークフローシステム３０６は、メッセージ公開システム２１４から公開されたワークフロー要求メッセージを受信する。ワークフローシステム３０６は、最初にインバウンド要求マネージャ３０８を通じてワークフロー要求メッセージを処理する。

図１０は、インバウンド要求マネージャ３０８によって取られたアクション１０００の流れ図の例を示している。インバウンド要求マネージャ３０８は、メッセージ公開システム２１４によって公開された公開済みサービス要求メッセージを受信する（段階１００２）。インバウンド要求マネージャは、サービス要求メッセージから「ＴＳＯ＿ＩＤ」を抽出し（段階１００４）、サービス要求メッセージから「ＴＳＯ＿ＬＡＢＥＬ」を抽出する（段階１００６）。

「ＴＳＯ＿ＩＤ」を用いて、インバウンド要求マネージャ３０８は、「ＴＳＯ＿ＩＤ」によって表されるサービス要求を実施する、インスタンスが生成されたワークフローテンプレートを得るために拡張「ＴＯＭ」データベース３１６を検索する。テンプレートが定義されていない場合には、インバウンド要求マネージャ３０８は、フェッチャーシステム３０４に「否定」応答を返信する（段階１０１０）。そうでなければ、インバウンド要求マネージャ３０８は、フェッチャーシステム３０４に「肯定」応答を返信し（段階１０１２）、この「ＴＳＯ＿ＩＤ」及び「ＴＳＯ＿ＬＡＢＥＬ」を伴って「ワークフロー」エンジン３１０を呼び出す（段階１０１４）。

図１１は、ワークフローマネージャ３１０によって取られるアクション１１００の流れ図の例を示している。ワークフローマネージャ３１０は、インバウンド要求マネージャ３０８から「ＴＳＯ＿ＩＤ」及び「ＴＳＯ＿ＬＡＢＥＬ」を受信する（段階１１０２）。次に、ワークフローエンジン３１０は、「ＴＡＳＫ＿ＩＮＳＴ」テーブル９０８からのワークフローテンプレート内でワークフロータスクを検索する（段階１１０４）。

ワークフロー内に更にいずれかのタスクが存在する場合には、ワークフローエンジン３１０は、順番に次のタスクを実行する（段階１１０６）。そうするために、ワークフローエンジン３１０は、「ＴＡＳＫ＿ＩＮＳＴ」テーブル９０８内のタスクに対して識別されるサブ処理を起動する。シーケンスで起動されるタスクに対して、ワークフローエンジン３１０は、タスクサブ処理を起動し、このサブ処理からの応答を待つ（段階１１０８）。他のタスクと並列して起動することができるタスクに対しては、ワークフローエンジン３１０は、タスクのサブ処理を起動し、待つことなしに次のタスクへと続行する（段階１１１０）。

いくつかのステータスは、タスクに対して定義される。ワークフローエンジン３１０及びウェブエラー「ＧＵＩ」３１４は、タスク実行中にステータスを設定し、維持することができる。タスクに対する初期ステータスは、「Ｉ」（初期）であり、終了ステータスは、「Ｄ」（終了）又は「Ｃ」（強制完了）のいずれかとすることができる。最初は、各タスクは、「Ｉ」に設定されたステータスを有することができる。ワークフローエンジン３１０がタスク実行のためにサブ処理を起動すると、タスクステータスは、「Ｘ」（実行）に変化する。「Ｘ」ステータスは、サブ処理がタスクを実行中であることを示している。

タスクの終了の成功及びサブ処理からの回答の受信は、タスクの「Ｄ」（終了）ステータスへの移行を誘発する。次に、ワークフローシステム３０６内のワークフローエンジン３１０は、ワークフロー内の次のタスクに移動することができる。サブ処理がエラーを伴って回答した場合には、ワークフローエンジン３１０は、タスクステータスを「Ｅ」（エラー）に設定することができる。それに応答して、ワークフローエンジン３１０は、そのタスクをウェブエラー「ＧＵＩ」３１４に渡す。

上述のように、ウェブエラー「ＧＵＩ」３１４は、インタフェースを提供し、これを通じてオペレータは、メッセージコンテントを修正、タスクを省略、又はタスクを（修正を加えて）処理のために再提出することができる。タスクが再提出されると、タスクステータスは、「Ｒ」（再提出）に移行する。ワークフローシステム３０６は、再提出されたタスクを受信し、そのタスクを統御するサブ処理を実行し、タスクステータスを「Ｘ」に設定する。エラーステータス「Ｅ」を伴うタスクに対しては、ワークフローエンジン３１０は、タスク実行を停止する。ウェブエラー「ＧＵＩ」３１４は、タスク処理を要求するためにワークフローシステム３０６に要求／回答メッセージを公開することによってタスクを再開することができる。

ウェブエラー「ＧＵＩ」３１４がタスクを省略する場合には、タスクステータスは、「Ｃ」（完了）に設定される。これに加えて、オペレータは、ウェブエラー「ＧＵＩ」３１４を通じてタスク実行を制御することができる。オペレータは、ウェブエラー「ＧＵＩ」３１４を通じてタスクを即時に完了させる要求を出すことができ（タスクを「Ｃ」ステータスに移行させる）、又はタスクを再提出させることができる（タスクを「Ｒ」ステータスに移行させる）。ワークフローシステム３０６は、「Ｃ」ステータスが最終ステータスであると考え、それに応答してワークフローシーケンス内の次のタスクに移動する。

図１２は、並列タスクマネージャ３１２によって取られる段階１２００の例を示している。ある一定のタスクは、他のタスクと同時に実行することができる並列タスクとして指定することができる。それにも関わらず、一部のタスクは、続行するために他のタスクから得られる結果を必要とする可能性がある。従って、並列タスクマネージャ３１２は、並列タスクを実行しているサブ処理からの応答をモニタし（段階１２０２）、応答を取得し（段階１２０４）、続行することができるようになる前に応答を待っている他のタスクに応答を提供する（例えば、ワークフローエンジン３１０を通じて）（段階１２０６）。それによって並列タスクマネージャ３１２は、入力データを待っている待機状態のタスクの障害を取り除くように作用する。

上述のように、ワークフローシステム３０６はまた、アクションエンジン３１８を含む。アクションエンジン３１８は、個々のタスク内でネットワークサービス提供アクションを実行する。言い換えれば、拡張「ＴＯＭ」データベース３１６がある一定のタスクに対してネットワークサービス提供アクションを指定した場合に、第２のワークフローシステム３０６は、アクションを処理するためにこのアクションエンジン３１８を呼び出すことができる。

アクションエンジン３１８は、２つの層、すなわち、アクションマネージャ３２０及びアクションビルダ３２２を含む。アクションマネージャ３２０は、「ＴＯＭ」データベース３１６内に定義されている正しいシーケンスでのサービス提供アクションの実行を判断して開始する。アクションビルダ３２２は、アクションの実行を要求するためにメッセージ公開システム２１４に対して適切なメッセージを作成して送信し、同様にメッセージ公開システム２１４から応答を受信する。
アクションエンジン３１８は、ワークフローエンジン３１０と同様な方法で実行する（図１１）。より具体的には、アクションエンジン３１８は、ワークフロー内のタスクの処理に対する要求を受信する。それに応答して、アクションマネージャ３２０は、そのタスクに対して実行すべきアクションを「ＡＣＴＩＯＮ＿ＩＮＳＴ」テーブル９１０から検索する。

実行されるべき各アクションに対して、アクションマネージャ３２０は、アクションビルダ３２２を呼び出す。アクションが「デタッチ」されない（すなわち、並列に実行されない）場合には、アクションマネージャ３２０は、アクションビルダ３２２からの応答を待つ。そうでなければ、アクションマネージャ３２０は、アクションビルダ３２２からの応答を待たずにシーケンス内の次のアクションの実行を開始する。ウェブエラー「ＧＵＩ」３１４は、ここでもまた、タスクエラーと同じ方法で、かつ同じステータス移行を伴ってアクション実行中に発生するエラーを管理することができる。

アクションビルダ３２２は、アクションを実行することになるシステム又は処理への配信に向けてアクション要求メッセージを構築し、メッセージ公開システム２１４に送信する。アクションビルダ３２２は、メッセージ公開システム２１４からアクション実行から生じる応答を受信する。アクションビルダ３２２は、この応答をアクションマネージャ３２０に戻す。応答に基づいて、アクションマネージャ３２０は、あらゆるエラーを処理するか（例えば、ウェブエラー「ＧＵＩ」３１４を通じて）、又は存在するならば次のネットワークアクションを実行する。

ワークフロー、タスク、及びアクションは、広範囲なサービス要求について定義することができる。一例として、「ＵＭＴＳ加入者識別モジュール（ＵＳＩＭ）」をアクティブ化するためのワークフローは、「ＡＣＴＩＶＡＴＥ＿ＵＳＭ」の「ＴＳＯ＿ＬＡＢＥＬ」に関連付けることができ、以下のタスクへと分割することができる：コア基本サービスを「アクティブ化」する（例えば、関連の「ＩＭＳＩ」及び「ＭＳＩＳＤＮ」を提供する）、メッセージサービスを「変更」する（例えば、関連のメッセージサービスに「ＭＳＩＳＤＮ」及び顧客名を提供する）、及び警告サービスを「変更」する（例えば、警告サービスに顧客名、誕生日、住所、又は他の顧客情報を提供する）。「ＣＲＭ」システム１２２からのサービス要求に関連するワークフローの付加的な例は、「ＵＳＩＭ」を「変更」し、「ＵＳＩＭ」を「一時停止」し、「ＵＳＩＭ」を「再開」し、「ＭＳＩＳＤＮ」番号を「変更」し、送受話器を「非アクティブ化」し、先払い又は後払い「ＵＳＩＭ」を「事前アクティブ化」し、サービスを「アクティブ化」し、サービスの「終了」し、「ＵＳＩＭ」を「終了」するワークフローを含む。

サービスブローカー１１６は、広範な電気通信サービスに対するサービス要求を処理する。１つの役割では、サービスブローカー１１６は、第三者ゲートウェイ１１０から受信するサービス要求を処理する。一般的に、サービスブローカー１１６は、インバウンドサービス要求を一連の段階（例えば、タスク及びアクション）にマッピングし、サービス要求の実施に導くものである。サービスブローカー１１６は、各段階の実行に対する要求を適切なシステム又は処理に配信し、結果を判断し、この結果に関して第三者ゲートウェイ１１０と通信する。

図１３は、第三者ゲートウェイ１１０から受信した「認証」サービス要求から生じるメッセージフローの例を示している（フロー１３０２）。例えば、ユーザがサービスを購入することができる前に識別される必要がある場合には、第三者ゲートウェイ１１０は、「認証」要求（「ＭＳＩＳＤＮ」及び／又は「ＩＭＳＩ」番号のようなユーザを認識するために用いられる情報を含む）を送信することができる。サービスブローカー１１６は、ユーザプロフィールに対する要求をディレクトリシステムに提出し（フロー１３０４）、ディレクトリシステムは、ユーザプロフィールを返信する（フロー１３０６）。

サービスブローカー１１６は、第三者ゲートウェイ１１０に結果を返信する（フロー１３０８）。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー１１６は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー１１６は、ユーザプロフィールデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、サービスブローカー１１６は、次に、ユーザのサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ（フロー１３１０）、ディレクトリシステムは、そのプロフィールを返信する（フロー１３１２）。

サービスブローカー１１６は、結果を第三者ゲートウェイ１１０に返信する（フロー１３１４）。プロフィール情報が入手不能であった場合には、サービスブローカー１１６は、「非許可」メッセージを第三者ゲートウェイ１１０に返信する。そうでなければ、サービスブローカー１１６は、サービスプロフィールデータと共に「許可」メッセージを返信する。
表２２及び２３は、「認証」サービス要求メッセージ及び応答の例を示している。

図１４は、第三者ゲートウェイ１１０から受信した「課金」サービス要求から生じるメッセージフローの例を示している（フロー１４０２）。第三者ゲートウェイ１１０は、ユーザアカウントにサービス額を課金するために「課金」要求を送信することができる。サービスブローカー１１６は、課金額を含む課金要求を請求システムに提出する（フロー１４０４）。請求システムは、サービスをアカウントに課金し、サービスブローカー１１６に結果ステータスを返信する（フロー１４０６）。サービスブローカー１１６は、結果ステータスを第三者ゲートウェイ１１０に返信する（フロー１４０８）。
表２４及び２５は、「課金」サービス要求メッセージ及び応答の例を示している。

図１５は、第三者ゲートウェイ１１０から受信した「ＳＭＳ」配信サービス要求から生じるメッセージフローの例を示している（フロー１５０２）。第三者ゲートウェイ１１０は、ユーザアカウントに対して課金し、「ＳＭＳ」メッセージを配信するために「ＳＭＳ」要求を送信することができる。サービスブローカー１１６は、サービスについてアカウントに課金するように請求システムに要求し（フロー１５０４）、請求システムから結果ステータスを受信する（フロー１５０６）。サービスブローカー１１６は、結果ステータスを第三者ゲートウェイ１１０に返信する（フロー１５０８）。次に、サービスブローカー１１６は、「ＳＭＳ」を送信するためにネットワークインタフェースを通じて「ＳＭＳ」処理又はシステムを呼び出し（フロー１５１０）、確認応答を受信する（フロー１５１２）。サービスブローカー１１６は、エラー発生時には「ＳＭＳ」メッセージ送信を再試行するように続行することができる。
表２６及び２７は、「ＳＭＳ」サービス要求メッセージ及び応答の例を示している。

図１６は、第三者ゲートウェイ１１０から受信した「ＭＭＳ」配信サービス要求から生じるメッセージフローの例を示している（フロー１６０２）。第三者ゲートウェイ１１０は、ユーザアカウントに対して課金し、「ＭＭＳ」メッセージを配信するために「ＭＭＳ」要求を送信することができる。サービスブローカー１１６は、サービスについてアカウントに課金するように請求システムに要求し（フロー１６０４）、請求システムから結果ステータスを受信する（フロー１６０６）。サービスブローカー１１６は、結果ステータスを第三者ゲートウェイ１１０に返信する（フロー１６０８）。次にサービスブローカー１１６は、「ＭＭＳ」を送信するためにネットワークインタフェースを通じて「ＭＭＳ」処理又はシステムを呼び出し（フロー１６１０）、確認応答を受信する（フロー１６１２）。サービスブローカー１１６は、エラー発生時には「ＭＭＳ」メッセージ送信を再試行するように続行することができる。
表２８及び２９は、「ＭＭＳ」サービス要求メッセージ及び応答の例を示している。

図１７は、第三者ゲートウェイ１１０から受信した「セッション開始プロトコル（ＳＩＰ）」サービス要求から生じるメッセージフローの例を示している（フロー１７０２）。第三者ゲートウェイ１１０は、「ＳＩＰ」呼び出しを設定してアカウントに課金するために「ＳＩＰ」要求を送信することができる。サービスブローカー１１６は、サービスについてアカウントに課金するように請求システムに要求し（フロー１７０４）、請求システムから結果ステータスを受信する（フロー１７０６）。サービスブローカー１１６は、結果ステータスを第三者ゲートウェイ１１０に返信する（フロー１７０８）。次に、サービスブローカー１１６は、「ＳＩＰ」接続を設定するためにネットワークインタフェースを通じて「ＳＩＰ」処理又はシステムを呼び出し（フロー１７１０）、確認応答を受信する（フロー１７１２）。サービスブローカー１１６は、エラー発生時には「ＳＩＰ」接続の設定を再試行するように続行することができる。
表３０及び３１は、「ＳＩＰ」サービス要求メッセージ及び応答の例を示している。

図１８は、第三者ゲートウェイ１１０から受信した「ユーザステータス」サービス要求から生じるメッセージフローの例を示している（フロー１８０２）。第三者ゲートウェイ１１０は、他のユーザのオンライン存在検査を行うために「ステータス」要求を送信することができる。サービスブローカー１１６は、ディレクトリシステムにステータス要求メッセージを送信し（フロー１８０４）、ディレクトリシステムは、ユーザステータスを返信する（フロー１８０６）。サービスブローカー１１６は、ユーザステータスを第三者ゲートウェイ１１０に返信する（フロー１８０８）。
表３２及び３３は、「ステータス」サービス要求メッセージ及び応答の例を示している。

図１９は、第三者ゲートウェイ１１０から受信した「モバイルユーザステータス」認証サービス要求から生じるメッセージフローの例を示している（フロー１９０２）。例えば、ユーザが「インターネットプロトコルテレビジョン（ＩＰＴＶ）」サービスのようなサービスの購入することができる前に識別される必要がある場合、第三者ゲートウェイ１１０は、「認証」要求（「ＭＳＩＳＤＮ」及び／又は「ＩＭＳＩ」番号のようなユーザを認識するために用いられる情報を含む）を送信することができる。サービスブローカー１１６は、ディレクトリシステムにユーザサービスデータ（例えば、ユーザに関するネットワーク特性）に対する要求を提出し（フロー１９０４）、ディレクトリシステムは、ユーザサービスデータを返信する（フロー１９０６）。

サービスブローカー１１６は、第三者ゲートウェイ１１０に結果を返信する（フロー１９０８）。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー１１６は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー１１６は、ユーザプロフィールデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、次に、サービスブローカー１１６は、ユーザのアプリケーションサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ（フロー１９１０）、ディレクトリシステムは、そのプロフィールを返信する（フロー１９１２）。

サービスブローカー１１６は、結果を第三者ゲートウェイ１１０に返信する（フロー１９１４）。アプリケーションサービス情報が入手不能であった場合には、サービスブローカー１１６は「非許可」メッセージを第三者ゲートウェイ１１０に返信する。そうでなければ、サービスブローカー１１６は、アプリケーションサービスデータと共に「許可」メッセージを返信する。
表３４及び３５は、モバイルユーザ認証サービス要求メッセージ及び応答の例を示している。

図２０は、第三者ゲートウェイ１１０から受信した「ＩＰＴＶ」ユーザ認証要求から生じるメッセージフローの例を示している（フロー２００２）。例えば、ユーザがモバイル「ＩＰＴＶ」アプリケーションに接続を試みる場合、第三者ゲートウェイ１１０は、「認証」要求（「ＭＳＩＳＤＮ」及び／又は「ＩＭＳＩ」番号のようなユーザを認識するために用いられる情報を含む）を送信することができる。サービスブローカー１１６は、ディレクトリシステムにユーザサービスデータ（例えば、ユーザに関するネットワーク特性）に対する要求を提出し（フロー２００４）、ディレクトリシステムは、ユーザサービスデータを返信する（フロー２００６）。

サービスブローカー１１６は、第三者ゲートウェイ１１０に結果を返信する（フロー２００８）。ディレクトリシステムがユーザを認証できなかった場合には、サービスブローカー１１６は、第三者ゲートウェイに「非許可」メッセージを返信する。そうでなければ、サービスブローカー１１６は、ユーザサービスデータと共に「許可」メッセージを返信する。ユーザが許可された場合には、次に、サービスブローカー１１６は、ユーザのアプリケーションサービスプロフィールに対する要求という形態でユーザに関する追加情報をディレクトリシステムに要求することができ（フロー２０１０）、ディレクトリシステムは、そのプロフィールを返信する（フロー２０１２）。

サービスブローカー１１６は、結果を第三者ゲートウェイ１１０に返信する（フロー２０１４）。アプリケーションサービス情報が入手不能であった場合には、サービスブローカー１１６は「非許可」メッセージを第三者ゲートウェイ１１０に返信する。そうでなければ、サービスブローカー１１６は、アプリケーションサービスデータと共に「許可」メッセージを返信する。
表３６及び３７は、「ＩＰＴＶ」ユーザ認証サービス要求メッセージ及び応答の例を示している。

上述の説明の全ては、説明された特定の実施例に係わらず、制限的なものではなく本質的に例示的なものである。例えば、実施例の選択された態様、特徴、又は構成要素は、メモリ内に格納されているように示されているが、サービスブローカーと適合するシステム及び方法の全て又は一部は、他の機械可読媒体、例えば、ハードディスク、フレキシブルディスク、及びＣＤ−ＲＯＭのような２次記憶装置、ネットワークから受信する信号、又は現時点で公知であるか又は今後開発されるＲＯＭ又はＲＡＭの他の形態に格納、又はそれらにわたって分配、又はそれらから読み取ることができる。

更に、サービスブローカーアーキテクチャの特定の構成要素が説明されているが、サービスブローカーに適合する方法、システム、及び製造品は、付加的な又は異なる構成要素を含むことができる。例えば、プロセッサは、マイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、個別論理回路、又は他のタイプの回路又は論理回路の組合せとして実施することができる。同様に、メモリは、ＤＲＡＭ、ＳＲＡＭ、フラッシュ、又は他のあらゆるタイプのメモリとすることができる。フラグ、データ、データベース、テーブル、及び他のデータ構造は、別々に格納及び管理することができ、単一のメモリ又はデータベースに組み込むことができ、分配することができ、又は様々な手法で論理的にかつ物理的に編成することができる。プログラムは、単一のプログラムの各部分、又は別々のプログラムとすることができ、又はいくつかのメモリ及びプロセッサにわたって分配することができる。システムは、１つの処理システム内の又は複数の処理システムにわたって分配されたハードウエア、ソフトウエア、又はハードウエアとソフトウエアの組合せで実施することができる。

サービスブローカー層は、外部のサービス要求の処理に関連する技術的困難を克服するものである。待ち行列におけるサービス要求の分配は、莫大な数の同時又はほぼ同時のサービス要求を受信して編成するという技術的困難に対処する。多重フェッチャー及びワークフローエンジンアーキテクチャは、調整された効率的方法でサービス要求を抽出し、抽出されたサービス要求を実行して要求された処理を実際に達成し、耐障害性サービス要求処理を提供し、サービス要求処理の性能を最大にする際の技術的困難に対処するものである。
本発明の様々な実施形態を説明したが、本発明の範囲内で更に多くの実施形態及び実施例が可能であることは当業者には明らかであろう。従って、本発明は、特許請求の範囲及びそれらの均等物に照らしたもの以外は制限されないものとする。

第三者アクセスゲートウェイに接続したサービスブローカーを含む電気通信アーキテクチャの一部分を示す図である。 電気通信アーキテクチャ内のサービスブローカーを示す図である。 電気通信アーキテクチャ内のサービスブローカーの代替的な実施例を示す図である。 サービスブローカー内のフェッチャーシステムのためのトラフィック制御パラメータを例示する図である。 電気通信アーキテクチャ内のサービスブローカーのためのディスパッチャーシステムを例示する図である。 電気通信アーキテクチャ内のサービスブローカーのための第１のフェッチャーシステムを示す図である。 電気通信アーキテクチャ内のフェッチャーシステムのための技術指令管理データベースを例示する図である。 電気通信アーキテクチャ内のサービスブローカーのための第２のフェッチャーシステムを示す図である。 電気通信アーキテクチャ内のフェッチャーシステムのための拡張技術指令管理データベースを例示する図である。 電気通信サービス要求を処理するためにインバウンド要求マネージャが取ることができる作動を示す図である。 電気通信サービス要求を処理するためにワークフローエンジンが取ることができる作動を示す図である。 電気通信サービス要求を処理するために並列タスクマネージャが取ることができる作動を示す図である。 「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。 「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。 「ＳＭＳ」配信及び「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。 「ＭＭＳ」配信及び「課金」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。 「ＳＩＰ」呼び出し要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。 ユーザ「ステータス」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。 モバイルユーザ「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。 「ＩＰＴＶ」ユーザ「認証」要求を処理するためにサービスブローカーを通るメッセージフローを例示する図である。

符号の説明

１００ 電気通信アーキテクチャ
１０２ 第三者
１１２ サービス要求
１１６ サービスブローカー

Claims (20)

1. サービス要求待ち行列、および前記サービス要求を実行するためにディスパッチするディスパッチャーシステム含む、電気通信アーキテクチャのためのサービス要求処理システムであって、
   各サービス要求がサービスタイプ識別子フィールドとサービス要求識別子フィールドとを含む電気通信サービスに対するサービス要求を受信するサービス要求インタフェースと、
   前記サービスタイプ識別子フィールドに基づいて前記サービス要求を異なるサービス要求待ち行列（queues）内に分配し、それによって待機サービス要求記録を確立するディスパッチャーシステムと、
   待機サービス要求記録の前記サービス要求識別子フィールドから、処理するために選択されたサービス要求識別子を取得するフェッチャーシステムと、
   前記フェッチャーシステムの少なくとも１つによる前記待機サービス要求記録の選択を支配するトラフィック制御パラメータと、
   前記選択されたサービス要求識別子に対応する前記待機サービス要求記録中の入力メッセージからサービス要求定義を検索し、前記サービス要求定義にしたがってワークフロー段階を達成し、そして、ワークフローの結果を、前記選択されたサービス要求識別子に対応する前記待機サービス要求記録内のメッセージ出力フィールド内に、書き戻すよう構成されているワークフローシステムと、
   を含むことを特徴とするシステム。
2. 前記異なるサービス要求待ち行列は、
   顧客関係管理サービス要求待ち行列と、
   第三者サービス要求待ち行列と、
   を含む、
   ことを特徴とする請求項１に記載のサービス要求処理システム。
3. 前記第三者サービス要求待ち行列は、
   メッセージサービス要求待ち行列と、
   課金サービス要求待ち行列と、
   を含む、
   ことを特徴とする請求項２に記載のサービス要求処理システム。
4. 前記メッセージサービス要求待ち行列は、ショートメッセージングサービス（ＳＭＳ）要求待ち行列を含むことを特徴とする請求項３に記載のサービス要求処理システム。
5. 前記メッセージサービス要求待ち行列は、マルチメディアメッセージングサービス（ＭＭＳ）要求待ち行列を含むことを特徴とする請求項３に記載のサービス要求処理システム。
6. 前記第三者サービス要求待ち行列は、
   認証要求待ち行列と、
   ステータス要求待ち行列と、
   を含む、
   ことを特徴とする請求項２に記載のサービス要求処理システム。
7. 前記認証要求待ち行列は、モバイルユーザ認証要求待ち行列を含むことを特徴とする請求項６に記載のサービス要求処理システム。
8. 前記顧客関係管理サービス要求待ち行列は、
   サービスアクティブ化要求待ち行列と、
   サービス終了要求待ち行列と、
   を含む、
   ことを特徴とする請求項２に記載のサービス要求処理システム。
9. 前記フェッチャーシステムが、複数の独立したフェッチャーシステムの内の一つであり、前記ワークフローシステムが、複数の独立したワークフローシステムの内の一つであり、前記複数の独立したワークフローシステムの各々が、前記選択されたサービス要求識別子に対応する前記待機サービス要求記録中の入力メッセージからサービス要求定義を検索し、前記サービス要求定義にしたがってワークフロー段階を達成し、そして、ワークフローの結果を、前記選択されたサービス要求識別子に対応する前記待機サービス要求記録内のメッセージ出力フィールド内に、書き戻すよう構成されていることを特徴とする請求項１に記載のサービス要求処理システム。
10. サービス要求をサービス要求待ち行列内に待機し、前記サービス要求を実行のためにディスパッチすることを含む、電気通信サービス要求を処理する方法であって、
    各サービス要求がサービスタイプ識別子フィールドとサービス要求識別子フィールドとを含む電気通信サービスに対するサービス要求を受信する段階と、
    前記サービスタイプ識別子フィールドに基づいて前記サービス要求を異なるサービス要求待ち行列内に送り出し、それによって待機サービス要求記録を確立する段階と、
    前記異なるサービス要求待ち行列からの前記待機サービス要求記録の選択を支配するトラフィック制御パラメータを確立する段階と、
    待機サービス要求記録に対する前記サービス要求識別子フィールドから実行するために選択されたサービス要求識別子を取得するためにフェッチャーシステムの実行を開始する段階と、
    前記選択されたサービス要求識別子に対応する前記待機サービス要求記録中の入力メッセージからサービス要求定義を検索する段階と、
    前記サービス要求定義にしたがってワークフロー段階を達成する段階と、および
    ワークフロー処理結果を、前記選択されたサービス要求識別子に対応する前記待機サービス要求記録内のメッセージ出力フィールド内に書き込む段階と、
    を含むことを特徴とする方法。
11. フェッチャーシステムの実行を開始する前記段階は、
    第１のフェッチャーシステムの実行を開始する段階と、
    第２のフェッチャーシステムの実行を開始する段階と、
    を含み、
    ワークフロー段階を達成する前記段階は、
    前記第１のフェッチャーシステムのための第１のワークフローエンジンに対して、前記選択されたサービス要求識別子の第１のものを通信する段階と、
    前記第２のフェッチャーシステムのための第２のワークフローエンジンに対して、前記選択されたサービス要求識別子の第２のものを通信する段階と、
    を含む、
    ことを特徴とする請求項１０に記載の方法。
12. 送り出す段階は、
    顧客関係管理サービス要求待ち行列と、
    第三者サービス要求待ち行列と、
    の間で前記サービス要求を送り出す段階、
    を含む、
    ことを特徴とする請求項１０に記載の方法。
13. 前記第三者サービス要求待ち行列は、メッセージサービス要求待ち行列を含むことを特徴とする請求項１２に記載の方法。
14. 前記メッセージサービス要求待ち行列は、ショートメッセージングサービス（ＳＭＳ）要求待ち行列を含むことを特徴とする請求項１３に記載の方法。
15. 前記メッセージサービス要求待ち行列は、マルチメディアメッセージングサービス（ＭＭＳ）要求待ち行列を含むことを特徴とする請求項１３に記載の方法。
16. 前記第三者サービス要求待ち行列は、
    認証要求待ち行列と、
    ステータス要求待ち行列と、
    を含む、
    ことを特徴とする請求項１２に記載の方法。
17. 前記認証要求待ち行列は、モバイルユーザ認証要求待ち行列を含むことを特徴とする請求項１６に記載の方法。
18. 前記異なるサービス要求待ち行列は、データベース待ち行列テーブルを含むことを特徴とする請求項１０に記載の方法。
19. 前記データベース待ち行列テーブルは、待ち行列エントリがフェッチされたか否かを示す「処理ステータス」フィールドを含むことを特徴とする請求項１８に記載の方法。
20. 前記データベース待ち行列テーブルは、前記待ち行列エントリの処理が完了したか否かを示す「処理完了」フィールドを含むことを特徴とする請求項１９に記載の方法。

Images