JP2013101676A - マルチフォーマットのメッセージをパースする動的パース／ビルド・エンジン - Google Patents

Abstract

【課題】マルチフォーマットのメッセージをパースする動的パース／ビルド・エンジンを提供すること。
【解決手段】マルチフォーマットの財務メッセージを処理することができるパース／ビルドエンジン。このエンジンは、異なるフォーマットのメッセージを共通のフォーマットに変換し、その後、共通のフォーマットは、ビジネスサービスアプリケーションによって処理される。パーサは、メッセージを調べ、受信したメッセージの特定のフォーマットに適切なスキーマを決定する。スキーマは、受信したフォーマット用の文法構造と、該文法構造（「文法」は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意・必須フィールド等を含むことができる）を用いて、メッセージの様々なフィールドを内部メッセージフォーマットに変換するためのハンドラへのポインタとを含む、スキーマレジストリ内のデータ構造である。ハンドラは、個々にコンパイルされる。
【選択図】図１１

Description

（関連出願の引用）
本出願は、同時に出願された「ＡＤＡＰＴＩＶＥ ＦＲＯＮＴ ＥＮＤ ＧＡＴＥＷＡＹ ＦＯＲ ＳＷＩＴＣＨＩＮＧ ＴＲＡＮＳＡＣＴＩＯＮＳ ＡＮＤ ＤＡＴＡ ＯＮ ＵＮＲＥＬＩＡＢＬＥ ＮＥＴＷＯＲＫＳ ＵＳＩＮＧ ＣＯＮＴＥＸＴ−ＢＡＳＥＤ ＲＵＬＥＳ」と題する米国特許出願第＿＿＿＿＿号（代理人事件Ｎｏ．１６２２２Ｕ−０２０２００ＵＳ）と関連し、該出願はあらゆる目的において参照により本明細書に引用される。

本発明は、全体としてパース／ビルドエンジンに関し、より具体的には、マルチフォーマットのメッセージストリームを内部メッセージフォーマットに翻訳し、処理を施して、内部メッセージフォーマットをマルチフォーマットのメッセージストリームに逆翻訳することができ、翻訳することができるフォーマットをパース／ビルドエンジンに動的に追加することができる、高性能でなおかつ極めて柔軟なパース／ビルドエンジンに関する。

タスクを実行する際に、アプリケーションは、他の異種システムと通信する必要がある。これらの異種システムは、ホストアプリケーションの内部フォーマットとは異なるフォーマットのデータを用いているかもしれない。異なるデータフォーマットで受信した情報を処理できるためには、ホストアプリケーションは、外部データフォーマットをホストアプリケーション独自の内部データフォーマットにパースする必要があるかもしれない。その後、ホストアプリケーションは、パースされた情報を内部データフォーマットで処理することができる。その結果、ソフトウェアアプリケーションは、その後、該ソフトウェアアプリケーションによって用いられる内部データフォーマットとは異なるデータフォーマットのデータを処理する外部異種システムと効果的に通信することができる。

通常、パース／ビルドエンジンは、上述のパースステップおよびビルドステップに用いられる。これらのエンジンは、一般に、インタプリタベースのパース／ビルドエンジンおよびコンパイル済みパース／ビルドエンジンの２種類のうちの１つである。

インタプリタベースのパース／ビルドエンジンは、多数のデータフォーマットを処理することができる。インタプリタベースのパース／ビルドエンジンは、特定のメッセージのセットを翻訳するために用いられる、大型の文法辞書を含む。従って、多数のデータフォーマットを処理することができるが、この文法辞書の使用には非常に手間がかかることが多く、またこれを用いてメッセージを翻訳することによって性能が低下するため、性能が犠牲となる。インタプリタベースのパース／ビルドエンジンの別の欠点は、それらが文法辞書に含まれる特定のメッセージのセットしか翻訳できない点にある。追加の定義を文法辞書に加える必要がある場合、このエンジンは通常、新たな定義をこの文法辞書に対して用いるために、再コンパイルする必要がある。

コンパイル済みパース／ビルドエンジンは、データフォーマットの固定セットに対して高性能となるようにカスタマイズされている。しかしながら、コンパイル済みパース／ビルドエンジンは、新たなデータフォーマットに動的に対応することができない。それらは、新たなビジネス要件に対応するのに必要となるかもしれない新たなデータフォーマットを組み込むのに、コード変更を必要とする。その後、コード変更を再コンパイルしなければならない。従って、コンパイル済みパース／ビルドエンジンは、新たなメッセージタイプを動的に処理する必要があり、また再コンパイルのために停止することができないシステムに対してはうまく適合しない。

本発明は、マルチフォーマットのメッセージを処理することができるパース／ビルドエンジンを提供する。このエンジンは、異なるフォーマットのメッセージを共通のフォーマットに変換し、次いで、共通のフォーマットのメッセージが、ビジネスサービスアプリケーションによって処理される。共通のフォーマットは、本明細書において内部メッセージフォーマットと呼ばれる標準メッセージフォーマットである。パーサは、メッセージを調べ、受信したメッセージの特定のフォーマットに適切なスキーマを決定する。スキーマは、受信したフォーマットの文法構造と、該文法構造（「文法」は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意・必須フィールド、等を含むことができる）を用いて、メッセージの様々なフィールドを内部メッセージフォーマットに変換するためのハンドラへのポインタとを含む、スキーマレジストリ内のデータ構造である。ハンドラは、個々にコンパイルされる。従って、システム全体をコンパイルせずに、ハンドラが別個にコンパイルされ、エンジンの他の要素に支障を来たすことなく容易にアップグレードすることができるモジュラーシステムを保持しながら、コンパイルされたソフトウェアの速度を速めている。新たなスキーマおよびハンドラをロードすることにより、フォーマットが変化する際に、新たなフォーマットまたは旧フォーマットに対する変更を、パース／ビルドエンジンに動的に追加することができる。

一実施形態では、パーサは、ＩＳＯ８５８３財務メッセージのような、検出したメッセージのフォーマットに対応するルートスキーマをロードすることができる。ルートスキーマは、どのタイプのメッセージが受信されたか（例えば、承認メッセージ、調整メッセージ等）を判断するハンドラをポイントする。次いで、パーサが、特定されたメッセージタイプ用のスキーマをロードし、次いで、該スキーマが、特定の文法を提供し、当該のメッセージタイプ用のハンドラをポイントする。従って、全タイプの財務メッセージ用に全文法および全ハンドラをロードする必要がなく、実際に必要なサブセットのみをロードすればよく、その結果、必要メモリを抑え、性能を向上させる。さらに、各メッセージタイプ用に、実際に存在するフィールドに対してのみスキーマおよびハンドラがロードされ、呼び出される。これは、本発明のモジュール構造および反復アプローチによって可能となる。

一実施形態では、実際に必要なスキーマ、文法、およびハンドラのみをロードすることに加え、本パース／ビルドエンジンは、内部メッセージフォーマットに対し、高速索引付けシステムを用いる。この索引付けシステムは、受信したフォーマットで用いられている各フィールドに対して、内部メッセージフォーマットの対応するフィールドを指し示す（をポイントする）、スキーマ内の符号化オブジェクトＩＤを用いる。用いられていない内部メッセージフォーマットのフィールドはポイントされず、従って、アクセスする必要はない。索引によって、階層構造内の数層下にあるフィールドをポイントすることができる。全フィールドを順次処理するのではなく、索引を用いることにより、速度の利点が提供される。

一実施形態では、ビジネスサービスアプリケーションは、内部メッセージフォーマットのメッセージを処理する。処理の結果として、ビジネスサービスアプリケーションは、フィールドを更新または追加することができる（例えば、タイムスタンプ、リスクスコアの算出のような再処理タスク等）。変更されたメッセージは、次いで、パース動作の逆、ビルド動作を受ける。ビルド動作は、同様に、スキーマおよびハンドラを用いて、メッセージを、発信者へ返信するため、または処理のために別の宛先へ転送するための所望の外部フォーマットにビルドする。ビジネスサービスアプリケーションは、パースビルドエンジンから分離しており、従って、パースビルドエンジンに対する変更は、ビジネスサービスアプリケーションに影響を与えないで済む。

本明細書に開示した本発明の性質および利点の更なる理解は、本明細書の残りの部分および添付の図面を参照することによって実現することができる。
本発明は、例えば、以下を提供する。
（項目１）
メッセージを内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信する工程と、
複数のハンドラを準備する工程であって、該ハンドラの各々が該フィールド用の文法を用いて該フィールドのうちの少なくとも１つをパースするためのコードであり、該ハンドラの各々が別個にコンパイルされる、工程と、
該メッセージの該フィールド用の１つ以上のスキーマを決定する工程であって、各スキーマが該ハンドラのうちの１つをポイントし、かつ１つ以上のフィールド用の文法定義を含む、工程と、
該ハンドラを用いて、該メッセージの該１つ以上のフィールドを該内部メッセージフォーマットに翻訳する工程と
を含む、方法。
（項目２）
上記内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含み、上記パーシングは、上記メッセージ内の上記フィールドに対してのみ行われ、該内部メッセージフォーマットの対応するフィールドのみが埋め込みされる、項目１に記載の方法。
（項目３）
上記スキーマ内に含まれる各メッセージフィールドは、上記内部メッセージフォーマット内の特定の場所をポイントする索引であるオブジェクトＩＤによって識別される、項目１に記載の方法。
（項目４）
他のスキーマおよびハンドラを再コンパイルすることなく、上記１つ以上のスキーマを動的にロードする工程をさらに含む、項目１に記載の方法。
（項目５）
上記翻訳から後続のスキーマを決定し、上記メッセージに対して、項目１の上記プロセスを、該後続のスキーマに対して反復する工程をさらに含む、項目１に記載の方法。
（項目６）
ビジネスサービスアプリケーションによって、上記内部メッセージフォーマットの上記メッセージを処理する工程をさらに含む、項目１に記載の方法。
（項目７）
上記ビジネスサービスアプリケーションによる上記処理は、上記フィールド内の値を変更する工程を含む、項目６に記載の方法。
（項目８）
上記処理後、上記内部メッセージフォーマットの上記メッセージを外部メッセージフォーマットにビルドするために、第２の１つ以上のスキーマのセットを決定する工程と、
該メッセージ内に含まれる上記１つ以上のフィールドに対応する該第２の１つ以上のスキーマのセットにおけるフィールド定義およびハンドラを決定する工程と、
該ハンドラを用いて、該外部メッセージフォーマットの１つ以上のフィールドをビルドする工程と
をさらに含む、項目７に記載の方法。
（項目９）
上記メッセージは、財務トランザクションを含む、項目１に記載の方法。
（項目１０）
上記メッセージ内の上記１つ以上のフィールド以外の全ての必要なフィールドを決定する工程であって、該必要なフィールドは出力メッセージに必須である、工程と、
該必要なフィールドが決定された場合、該メッセージ内の該１つ以上のフィールド以外の該必要なフィールドを、該内部メッセージのオブジェクトに追加する工程とを
さらに含み、
該内部メッセージオブジェクトにおいて、該１つ以上のフィールドおよび該必要なフィールドだけが埋め込みされ内包されたフィールドである、項目１に記載の方法。
（項目１１）
メッセージをパース／ビルドするように設定されているエンジンであって、該エンジンは、
複数のハンドラであって、各ハンドラがフィールド用の文法を用いて受信メッセージのフィールドのうちの少なくとも１つをパースするためのコードであり、該ハンドラの各々が別個にコンパイルされる、複数のハンドラと、
様々なタイプのメッセージ用の複数のスキーマであって、各スキーマが該ハンドラのうちの１つをポイントし、メッセージの１つ以上のフィールド用の文法定義を含む、複数のスキーマと
を備えている、エンジン。
（項目１２）
内部メッセージフォーマットオブジェクトをさらに備え、上記ハンドラは、該内部メッセージフォーマットオブジェクトを、上記メッセージ内で見出されたフィールド、および／または必須フィールドについてだけ埋め込みするように設定されている、項目１１に記載のエンジン。
（項目１３）
上記内部メッセージフォーマットの上記メッセージを処理するように設定されたビジネスサービスモジュールをさらに備える、項目１１に記載のエンジン。
（項目１４）
上記エンジンは、上記内部メッセージフォーマットからメッセージをビルドするように設定されており、該エンジンは、
第２の１つ以上のスキーマのセットであって、該第２の１つ以上のスキーマのセットは、メッセージ内のフィールドを該内部メッセージフォーマットから外部メッセージフォーマットにパースするのに使用可能なフィールド定義を含む、第２の１つ以上のスキーマのセットと、
該第２のスキーマのセット用の１つ以上のハンドラであって、該ハンドラは、該第２のスキーマのセット内の該フィールド定義を用いて、該メッセージ内のフィールドを、該内部メッセージフォーマットから該外部メッセージフォーマットにパースするように設定された、該第２のスキーマのセット用の１つ以上のハンドラと
を備えている、項目１３に記載のエンジン。

図１は、本発明の一実施形態による、トランザクションを処理するシステムを示している。 図２は、本発明の一実施形態による、ゲートウェイのより詳細な実施形態を示している。 図３は、本発明の一実施形態による、トランザクションを処理する方法の略フローチャートを示している。 図４は、本発明の一実施形態による、トランザクション処理装置によって提示されるサービスに対する設定情報を生成するための略フローチャートを示している。 図５は、本発明の一実施形態による、サービスに加入する方法の略フローチャートを示している。 図６は、本発明の一実施形態による、複数のゲートウェイの分散化システムを示している。 図７は、本発明の一実施形態による、ゲートウェイをフロントエンドゲートウェイとして示すシステムを示している。 図８は、本発明の一実施形態による、ゲートウェイがインターネットゲートウェイであるシステムを示している。 図９は、本発明の一実施形態による、ゲートウェイが無線ゲートウェイとして用いられているシステムを示している。 図１０は、本発明の一実施形態による、ＩＳＯ８５８３トランザクションを処理するシステムを示している。 図１１は、本発明の一実施形態による、メッセージをパースするシステムを示している。 図１２は、本発明の実施形態による、ゲートウェイの一実施形態を開示している。 図１３Ａは、本発明の一実施形態による、ＩＭＦオブジェクトに対する構造を示している。 図１３Ｂは、本発明の一実施形態による、メッセージ定義用属性を示している。 図１４Ａ、図１４Ｂ、および図１４Ｃは、本発明の一実施形態による、あり得るメッセージ、オブジェクトＩＤコードを有する階層フォーマット、およびメッセージに対するＩＭＦオブジェクトを示している。 図１４Ａ、図１４Ｂ、および図１４Ｃは、本発明の一実施形態による、あり得るメッセージ、オブジェクトＩＤコードを有する階層フォーマット、およびメッセージに対するＩＭＦオブジェクトを示している。 図１４Ａ、図１４Ｂ、および図１４Ｃは、本発明の一実施形態による、あり得るメッセージ、オブジェクトＩＤコードを有する階層フォーマット、およびメッセージに対するＩＭＦオブジェクトを示している。 図１５は、本発明の一実施形態による、パースビルドエンジンを初期設定してメッセージストリームを処理する方法の略フローチャートを示している。 図１６は、本発明の一実施形態による、パースビルドエンジン内にスキーマを動的に追加または更新する方法の略フローチャートを示している。 図１７は、本発明の一実施形態による、入力メッセージをパースする方法の略フローチャートを示している。 図１８は、本発明の一実施形態による、ＩＭＦオブジェクトからの出力メッセージをビルドする方法の略フローチャートを示している。

本発明の実施形態は、メッセージのパース（ｐａｒｓｅ）／ビルド（ｂｕｉｌｄ）に関する。本発明の一実施形態によるパース／ビルドエンジンを組み込むことができるゲートウェイを最初に説明する。その後、このパース／ビルドエンジンをより詳細に説明する。

（ゲートウェイ）
（処理の概要）
一実施形態では、トランザクションのインテリジェントな切り替えを提供する。トランザクションは、クレジットカード承認でも、デビットカードトランザクションでも、電子小切手トランザクションでもよい。トランザクションの他の例には、賞プログラムにおけるポイントまたは他の報酬の授与、Ｖｉｓａ認証サービス用パスワードのチェック、送金の実行、Ｖｉｓａ Ｂｕｘｘカードまたは給与カードのようなプリペイドカードからの支払金の引き落とし、携帯電話、ページャ、ＰＤＡ等からの近接支払、健康保険、自動車保険、または他の保険等の補償範囲の判定が含まれる。クライアントは、トランザクションをゲートウェイに送信する。その後、ゲートウェイは、該トランザクションをサービスプロバイダのトランザクション処理装置へインテリジェントに切り替えるように設定される。クライアントは、ＰＯＳ、ＰＯＳ装置またはＥＣＲ（電子式金銭登録機）にネットワーク接続している商人のコンピュータ、キオスク（例えばクーポンまたは送金に対する）、インターネットのウェブサイトサーバ等とすることができる。

ゲートウェイは、アプリケーションレベルのトランザクションの内容、移送環境の現況、および／または動的ルールに基づいて、アプリケーションレベルで切り替え判断を行うように設定されている。アプリケーションレベルの内容は、トランザクションを処理する際にトランザクション処理装置によって処理または用いられる情報とすることができる。一実施形態では、情報は、ＯＳＩ第７層の情報とすることができる。この層は、トランザクション処理装置またはエンドユーザに直接的に対応する。この層は、クレジットカード承認、デビットカードトランザクションアプリケーション等のようなアプリケーションを含む。例示的なアプリケーション層プロトコルは、ＦＴＰ（ファイル転送プロトコル）、ＮＦＳ（ネットワークファイルシステム）、ＣＩＦＳ（共通インターネットファイルシステム）、ＨＴＴＰ（ハイパーテキストトランスファープロトコル）、データベースクエリ、ＳＱＬ（標準クエリ言語）、およびＸＭＬ（拡張可能なマーク付け言語）である。例えばクレジットカード承認では、アプリケーションレベルの内容は、クレジットカード番号、個人アカウント番号（ＰＡＮ）、顧客アカウント番号、トランザクションに対する合計金額等を含むことができる。トランザクション処理装置は、この情報を用いてトランザクションを処理することができる。

移送環境の現況は、トランザクションを移送することができるネットワークおよび該トランザクションを処理することができるトランザクション処理装置と関連付けられた、リアルタイムの情報を含む。リアルタイムの情報は、ネットワークまたはトランザクション処理装置の調子、ネットワークまたはトランザクション処理装置の使用可能度、トランザクション処理装置のアプリケーション処理速度等を含むことができる。

動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するために用いられる情報とすることができる。これらのルールは、アプリケーションレベルの内容および移送環境の現況に応じてトランザクションを切り替えるために用いられる。例えば、これらのルールは、特定のアプリケーションレベルの内容および移送環境の現況に応じて、サービスプロバイダによって提供される特定のサービスを選択すべきであると指定することができる。さらに、これらのルールは、サービスプロバイダがトランザクションを処理するためのトランザクション処理装置を選択するために用いることができる。例えば、特定の国は、国内のトランザクションに対する局所処理を必要とし、従って、地域の処理センタへのルーティングを必要とするかもしれない。これらのルールは、選択を行うための、ネットワークコスト、サービスコスト等のような静的情報を考慮することができる。これらのルールは、ゲートウェイを停止することなく、動的に変化することができる。

ゲートウェイは、ルールに従って、トランザクションに対してサービスを行うこともできる。サービスは、アプリケーションレベルの内容の処理を含むことができる。例えば、トランザクション処理装置は、異なるフォーマットのトランザクションを処理するように設定することができる。選択されたトランザクション処理装置は、現在トランザクション中のアプリケーションレベルの内容と異なるフォーマットのアプリケーションレベルの内容を処理するように設定することができる。従って、ゲートウェイは、アプリケーションレベルの内容を新たなフォーマットに変更することができ、それにより、選択されたトランザクション処理装置は、それを処理することができる。従って、ゲートウェイは、トランザクション内の情報を、アプリケーションレベルで変更することができる。これは、パケットレベルで情報を見直すこととは異なる。通常、トランザクションは、パケットに分割することができる。ルータは、パケット内の情報を見て、該パケットをしかるべくルーティングすることはできる。しかしながら、パケットレベルで情報を見るので、ルータは、アプリケーションレベルの内容を用いてトランザクションに対するサービスを行うことはできない。例えば、トランザクション全体に関してアプリケーションレベルの内容を見ることによって、トランザクションに適切なサービスを適用し、トランザクションをインテリジェントにルーティングすることができる。トランザクションに関する情報を搬送する個々のパケットが個別に処理された場合には、全体としてのアプリケーションレベルの内容は処理されない。

従って、アプリケーションレベルの内容、移送環境の現況、および／または動的ルールに基づいて、アプリケーションレベルでトランザクションをインテリジェントに切り替えるゲートウェイを提供する。ゲートウェイは、切り替え判断に基づいて適用されたサービスを提供することもできる。

（システムの概要）
図１は、本発明の一実施形態によるトランザクションを処理するシステム１００を示している。図に示すように、システム１００は、１つ以上のクライアント１０２と、１つ以上のゲートウェイ１０４と、１つ以上のネットワーク１０６と、１つ以上のトランザクション処理装置１０８とを含む。以下の説明では、単一のゲートウェイ１０４に関して説明するが、多数のゲートウェイ１０４を備えて、以下に説明する全ての機能を実行できることを理解されたい。また、ゲートウェイをクライアントに隣接して示しているが、ゲートウェイは、トランザクション処理装置に隣接して、トランザクション処理装置とネットワーク１０６との間に配備することもできる。

クライアント１０２は、トランザクションを送信するようになっている何らかのシステムを含む。例えば、クライアント１０２は、ユーザとトランザクションを行うコンピュータ処理装置のシステムを含むことができる。一例では、クライアント１０２は、クレジットカード承認、チェックカードトランザクション等に対して、クレジットカード情報、暗証番号、氏名等のようなユーザ情報を受信する店舗販売時点情報管理（ＰＯＳ）装置を含むことができる。クライアントはまた、ポイントまたはクーポンの情報をチェックするための店舗内キオスクであっても、送金のためのキオスクであっても、携帯電話または他の装置からの無線ユーザ入力を受信するためのノードであっても、ウェブサイトサーバ等であってもよい。クライアントはまた、ＰＯＳ装置をネットワークに接続している商人のサーバであってもよい。

クライアント（例えばＰＯＳ装置）は、次いで、トランザクション処理装置１０８からのトランザクションサービスを要求するトランザクションを送信することができる。トランザクションサービスは、トランザクション処理装置１０８によって実行することができるどのような行為でもよい。一実施形態では、これらのトランザクションサービスは、クライアント１０２によって実行されているトランザクションに対して付加価値を付ける。トランザクションサービスの例には、クレジットカード承認、デビットカードトランザクション、電子小切手トランザクション等の促進が含まれる。トランザクションサービスは、トランザクションの処理、またはデータの交換を含むこともできる。

ゲートウェイ１０４は、クライアント１０２からのトランザクションを受信し、ネットワーク１０６を経由して該トランザクションをトランザクション処理装置１０８にルーティングするように設定されたシステムを含む。一実施形態では、ゲートウェイ１０４は、ネットワーク１０６の縁部上に位置している。例えば、ゲートウェイ１０４は、クライアント１０２に対するアクセスポイントにあっても、クライアント１０２の構内にあってもよい。ネットワーク１０６の縁部は、ネットワーク１０６を経由してルーティングするようにトランザクションを設定することができる点である。例えば、ゲートウェイ１０４は、トランザクション処理装置１０８を選択し、次に、要求をネットワーク１０６のルータに送信することができる。トランザクションは、いくつかのパケットに分割することができる。次いで、ルータは、ネットワーク１０６を通じてトランザクションのために、パケットをトランザクション処理装置１０６にルーティングする。

ネットワーク１０６は、データを転送するようになっているどのようなネットワークでもよい。例えば、ネットワーク１０６は、何らかのパケットベースのネットワーク、公衆交換電話網（ＰＳＴＮ）、無線ネットワーク、インターネット、民間金融ネットワーク等を含むことができる。

一実施形態では、ネットワーク１０６は、異種および／または低信頼ネットワークであってもよい。これらのネットワークは、それらを、異なる事業体によって制御することができる点、異なるプロトコルおよびフォーマットを用いてデータをルーティングすることができる点、異なる転送方法を用いてデータをルーティングすることができる点等で異種である。例えば、ネットワーク１０６は、異なる事業体によって制御することができる。一例では、第１のインターネットサービスプロバイダ（ＩＳＰ）は、ネットワーク１０６−１を保持することができ、第２のインターネットサービスプロバイダは、ネットワーク１０６−２を保持することができる。一実施形態では、トランザクションは、ネットワーク１０６−１またはネットワーク１０６−２を経由してルーティングすることができる。

また、ネットワーク１０６は、異なる種類のものであってもよい。例えば、ネットワーク１０６−１は、データのパケットをルーティングする非同期転送モード（ＡＴＭ）ネットワークであってもよい。別のネットワーク１０６−２は、無線でデータを伝送する無線ネットワークであってもよい。さらに、別のネットワーク１０６は、ＶｉｓａＮｅｔネットワークのような、一事業体用のプライベートネットワークであってもよい。２つのネットワーク１０６のみを示しているが、さらに多くのネットワーク１０６を備えることができることを理解されたい。また、トランザクションは多数のネットワーク１０６を経由してルーティングすることができることを理解されたい。例えば、トランザクションは、ネットワーク１０６−１を、次いでネットワーク１０６−２を経由し、その後トランザクション処理装置１０８にルーティングすることができる。

ネットワーク１０６はまた、低信頼ネットワークであってもよい。ネットワークの性質により、ネットワークは、いかなる時点においても、機能しなくなる可能性がある。従って、トランザクション処理における途絶を回避するために、フェイルオーバ処理が必要となる。

サービスプロバイダは、クライアント１０２に提供することができるサービスを登録および公開することができる。クライアント１０２は、サービスに対して登録を行い、トランザクションをサービスプロバイダへ切り替えてもらうことができる。サービスプロバイダは、クライアント１０２にサービスを提供するように設定されたトランザクション処理装置１０８をいくつでも有することができる。一実施形態では、トランザクション処理装置１０８は、金融トランザクションを処理する。例えば、トランザクション処理装置１０８は、イシュア、アクワイアラ、商人、またはいずれかの他のサービスプロバイダと関連付けることができる。一例では、トランザクション処理装置１０８は、クレジットカードトランザクションの認証を促進する。

サービスは、１つより多いトランザクション処理装置１０８によって提供することができる。例えば、サービスプロバイダは、クライアント１０２にサービスを提供することができる多くのデータセンタを有することができる。従って、サービスに対するトランザクションは、該サービスを提供することができるトランザクション処理装置１０８のうちのいずれかに切り替えればよい。トランザクション処理装置１０８は、全てが動的に変化している可能性がある、アプリケーションレベルの内容、移送環境に関する状況情報、および／または動的ルールに基づいて、ゲートウェイ１０４によって選択することができる。

アプリケーションレベルのサービスは、動的に変化する可能性がある。利用可能なサービスは、修正、別のプロセッサへの移動があるかもしれず、メンテナンスまたは障害により利用不能となるかもしれない。

移送環境に関する状況情報も、動的に変化している可能性がある。従って、ゲートウェイ１０４は、トランザクションを切り替える方法を決定する際に、移送環境に関する状況情報を判断する。例えば、ネットワーク１０６の調子の現況、ネットワーク１０６の可用性、トランザクション処理装置１０８の可用性、ネットワーク１０６を経由してデータが転送されている速度、ネットワーク１０６を経由してトランザクションを転送するコスト、トランザクションを処理するコスト、アプリケーションレベルでトランザクションを処理するのにアプリケーションが要する時間等が判断されるかもしれない。

移送環境に関する状況情報を提供する動的情報に加え、特定の比較的静的な情報が判断されるかもしれない。例えば、静的情報は、トランザクションのコスト、トランザクション処理装置１０８がトランザクションを処理するのに必要なフォーマット等とすることができる。ゲートウェイ１０６は、トランザクションをルーティングする方法を決定する際に、動的情報および静的情報を用いることができる。

動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するために用いられる情報とすることができる。これらのルールは、動的にロードされ得る。例えば、サービスプロバイダは、ゲートウェイ１０４上に動的にロードされる、サービスに対するルールを登録することができる。また、クライアントは、サービスおよびプロバイダのルールに加入して、クライアントのトランザクションをサービスプロバイダへ切り替えることができる。これらのルールも、ゲートウェイ１０４上に動的にロードすることができる。

従って、ゲートウェイ１０４は、サービスに対して、トランザクションを処理することができるトランザクション処理装置１０８を動的に選択することができる。選択された処理装置１０８が、それを処理することができるようにトランザクションをフォーマット化するなど、選択されたトランザクション処理装置に特有のビジネスサービスも、トランザクション上で実行することができる。その後、トランザクションを、選択されたネットワーク１０６を経由して、選択されたトランザクション処理装置１０８へ送信することができる。トランザクション処理装置１０８および／またはネットワーク１０６を動的に選択することにより、ゲートウェイ１０４は、クライアント１０２を、トランザクション処理装置１０８および／またはネットワーク１０６のあらゆる障害から防護する。従って、これにより、極めて高度なサービス可用性が提供される。ゲートウェイ１０４は、トランザクション処理装置１０８に対してダウンタイムを生じさせるかもしれない、行う必要のあるあらゆる変更から、クライアント１０２を防護する。

（ゲートウェイ１０４の概要）
図２は、本発明の一実施形態によるゲートウェイ１０４のより詳細な説明を示している。図に示すように、ゲートウェイ１０４は、１つ以上の要求ハンドラ２０２と、インバウンドメッセージストリームパーサ２０４と、セキュリティマネージャ２０６と、適応型ルートセレクタ２０８と、フローハンドラ２１０と、アウトバウンドメッセージストリームビルダ２１２と、メッセージディスパッチャ２１４と、コーディネータ２１６と、管理モジュール２１８と、設定ローダ２２０と、ルールデータベース２２２と、状況情報データベース２２４と、動的情報監視装置２２６とを含む。

要求ハンドラ２０２は、クライアント１０２からトランザクションを受信するように設定されている。クライアント１０２は、トランザクションを、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、拡張可能なマーク付け言語（ＸＭＬ）、ＩＳＯ８５８３標準等のような、様々なプロトコルおよびフォーマットで送信することができる。要求ハンドラ２０２は、種々のプロトコルおよびフォーマットで送信されたトランザクション用のインタフェースとなり、トランザクションをインバウンドメッセージストリームパーサ２０４に供給する。例えば、ＩＳＯメッセージハンドラは、クライアント１０２からＩＳＯ８５８３要求を受信し、それらをインバウンドメッセージストリームパーサ２０４に渡すように設定されている。また、ＸＭＬメッセージハンドラ、ＨＴＴＰ要求ハンドラ、ならびにＦＴＰ要求ハンドラは、ＸＭＬ、ＨＴＴＰ、およびＦＴＰによるメッセージおよび／または要求を処理することができる。従って、要求ハンドラ２０２によって、ゲートウェイ１０４は、様々なプロトコルおよびフォーマットのメッセージを受信することができる。上述のフォーマットおよびプロトコルを記載しているが、当業者には、要求ハンドラ２０２によって処理することができる他のフォーマットおよびプロトコルがあることを理解されたい。

インバウンドメッセージストリームパーサ２０４は、要求ハンドラ２０２からトランザクションを受信し、要求を標準形に変換するように設定されている。インバウンドメッセージストリームパーサ２０４は、様々なフォーマットのメッセージを受信し、それらの要求を、次にゲートウェイ１０４の他の構成要素によって処理することができる標準形に処理する。従って、多くの異なるフォーマットのトランザクション要求を、ゲートウェイ１０４によって処理することができる。インバウンドメッセージストリームパーサ２０４は、新たなフォーマットをゲートウェイ１０４によって処理して使用可能にすることができるという点で拡張可能な構造も提供する。新たなフォーマットが追加される場合、新たなフォーマットから標準形への翻訳が、インバウンドメッセージストリームプロセッサ１０４に追加される。従って、標準形が用いられるため、新たなフォーマットが追加される際に、ゲートウェイ１０４内の全ての構成要素を変更する必要はない。むしろ、インバウンドメッセージストリームパーサ２０４は、要求をゲートウェイ１０４の他の構成要素によって処理することができる標準形にパースするように設定されている。インバウンドメッセージストリームパーサ２０４のさらなる詳細は、以下に見出すことができる。

セキュリティマネージャ２０６は、トランザクションに対してセキュリティ機能を提供するように設定されている。例えば、プラグ可能認証および認証、役割ベースアクセス制御（ＲＢＡＣ）、暗号化、ファイル保全等のようなセキュリティ機能を提供することができる。プラグ可能認証および認証機能は、認証および許可用の標準インタフェースとなり、従って、既存の方法に影響を及ぼすことなく、より新しい認証およびアクセス制御の方法を追加することが可能となる。当業者は、トランザクションに追加することができる他のセキュリティ機能が分かるであろう。

適応型ルートセレクタ２０８は、ネットワーク１０６を経由して、トランザクションをトランザクション処理装置１０８に切り替えるように設定されている。適応型ルートセレクタ２０８は、アプリケーションレベルの内容、移送環境の現況、および／または動的ルールに基づいて、トランザクションを切り替える。

適応型ルートセレクタ２０８は、ルールデータベース２２２内で見出したルール、および状況情報データベース２２４内で見出した動的状況情報を用いて、トランザクションをルーティングする。上に述べたように、状況情報は、状況情報データベース２２４に格納することができる。一実施形態では、状況情報は動的であってもよい。動的情報監視装置２２６は、状況情報を監視および判断する。次いで動的情報は、状況情報データベース２２４に格納される。状況情報の例には、ネットワーク１０６の可用性、トランザクション処理装置１０８の調子、１トランザクション当たりのコスト、アプリケーションレベルで全トランザクションを処理するためにアプリケーションに対して要する時間等が含まれる。一実施形態では、動的情報監視装置２２６は、トランザクションが受信される際に、ランタイムで動的状況情報を判断することができる。別の実施形態では、動的情報監視装置２２６は、ある時間間隔で動的状況情報を判断することができる。

トランザクション処理装置１０８によって実行される各異なるサービスは、動的情報監視装置２２６によって実行することができるプローブを指定することができる。プローブが送信され、トランザクション処理装置１０８および／またはネットワーク１０６の状態に基づいて、情報の収集が可能となる。例えば、動的情報監視装置２２６は、ネットワークが利用可能であるかどうかを判断するために、ネットワークにテスト送信して応答を求めることができる。トランザクション処理装置１０８またはネットワーク１０６に対する応答が得られなかった場合、それは、利用不能と考えることができ、状態の情報は、状況情報データベース２２４に反映される。サービスに対する全てのトランザクション処理装置１０８に対して応答が得られなかった場合、同サービスは、利用不能と考えることができる。ゲートウェイ１０４は、この場合に同サービスを提供する別のサービスプロバイダを決定することができる。また、トランザクションを処理するためにトランザクション処理装置１０８上でアプリケーションに要する時間を測定することもできる。例えば、クレジットカード承認を許可するためにアプリケーションが要する時間が測定される。この測定値によって、トランザクションを切り替えるために用いることができるアプリケーションレベルの状況がもたらされる。

ルールデータベース２２２は、トランザクションを処理するネットワーク１０６および処理装置１０８に加えて、トランザクションに対するサービスを決定するためのルールをも含む。ルールは、クライアントの基準も示すことができる。例えば、サービスが選択されるためには、特定の状況情報およびアプリケーションレベルの内容がルールを満たしている必要がある。クライアントは、トランザクションに対するサービスを選択するために用いることができるクライアント固有のルールを提供することができる。一例では、クライアント１０２のトランザクションが受信される際に、適応型ルートセレクタ２０８がクライアントの固有の選択ルールを判断し、該トランザクションに対応することができるサービスを決定することができる。同サービスを提供するサービスプロバイダへトランザクションを切り替えるために、トランザクションからアプリケーションレベルの内容が判断され、かつ／または状況情報データベース２２４から動的状況情報が判断される。アプリケーションレベルの内容および／または状況情報がルールに適用され、ルールに従ってトランザクションを処理することができるサービスプロバイダが決定される。例えば、コストのような特定の要因に基づいて、クライアント１０２は、最も安価なサービスを最初に選択するように、しかしながら、それを利用できない場合、２番目のより費用のかかるサービスを選択するように指定することができる。また、アカウント番号のようなアプリケーションレベルの内容に基づいて、トランザクションを特定のクレジットカードサービスに切り替えることができる。例えば、指定されたアカウント番号によって、クレジットまたはデビットカードを指示するか、または特定のポイントもしくは賞システムを適用する。他のアカウント番号またはフィールドは、送金またはパスワード確認（例えば、Ｖｉｓａ認証サービス）のような、他のサービスの必要性を示すことができる。また、アプリケーションレベルの内容は、トランザクションを局所的に処理するか、または異なる国の処理ルーチン１０８に送信する必要があるかどうかを示す、クライアントの位置、およびいずれかの地域もしくは国ごとの規則を含むことができる。

サービスは、サービスのルールを明記したサービス明細書も含むことができる。例えば、ルールは、トランザクションに要するメッセージフォーマット、サービスを提供するトランザクション処理装置１０８のネットワークアドレス、トランザクションをトランザクション処理装置１０８に切り替えるためのプリファレンス、サービスを得るのに適格であるアカウント番号の範囲等を特定することができる。以下により詳細に論じるように、これらのルールは、登録と同時にサービスプロバイダによって提供される。サービスプロバイダは、ルールをゲートウェイ１０４上に直接ロードすることができ、次いで、ゲートウェイ１０４が、該ルールを他の関与するゲートウェイに公開する。

ルールは、トランザクションを処理することができるフローを指定することができる。フローは、トランザクション処理装置１０８に送信するためのトランザクションの処理を取り扱う。メッセージは、次いで、選択されたフローハンドラ２１０に送信される。トランザクション処理装置１０８およびネットワーク１０６が選択された後、フローハンドラ２１０は、トランザクションに対してビジネスサービスを実行することができる。例えば、異なるトランザクション処理装置１０８は、異なるフォーマットのトランザクションを処理し得る。フローハンドラ２１０は、選択されたトランザクション処理装置１０８に適切なフォーマットを決定し、該トランザクションを、同フォーマットにフォーマット化する。他のビジネスサービスには、通貨換算、保護必要フィールドの暗号化、特定の閾値を下回る取引額のクライアント側での代理処理等が含まれる。

フローハンドラ２１０は、複数のフローを含むことができる。各フローが、一群のメッセージを処理する一組のビジネスサービスを取り扱う。各フローが、該フロー内の全てのビジネスサービスを調整するフローハンドラを含む。フロー内の一連のサービスは、設定ローダ２２０を用いてランタイムでロードすることができるフロー明細によって指定されている。フロー明細は、入力メッセージを処理する方法を確定する一連のサービスである。各サービスは、特定の機能を実行するソフトウェアアプリケーションコードである。新たなサービスおよびフロー明細は、ゲートウェイ１０４に動的にロードすることができる。

フローハンドラ２１０がフロー内でトランザクションを処理した後、メッセージは、アウトバウンドメッセージストリームビルダ２１２に送信される。ビルダ２１２は、決定されたトランザクション処理装置１０８が要求するメッセージ形に基づいて、標準形からアウトバウンドメッセージをビルドするように設定されている。従って、ビルダ２１２は、標準メッセージフォーマットに基づいて、どのようなメッセージフォーマットも生成するように設定されている。アウトバウンドメッセージストリームビルダ２１２については、以下により詳細に説明する。

メッセージディスパッチャ２１２は、トランザクションをトランザクション処理装置１０８に送信するように設定されている。ディスパッチャ２１４は、トランザクションが選択されたトランザクション処理装置１０８へ確実に到達するようにすることができる。ディスパッチャ２１４は、種々のトランザクション処理装置１０８への接続を管理し、接続に失敗したトランザクション処理装置１０８への再接続を試みることができ、またトランザクション処理装置１０８およびネットワーク１０６の状態を動的情報監視装置２２６に提供することもできる。一実施形態では、トランザクションをパケット化、すなわち、一連のパケットに分割して、ルータに送信することができる。ルータは、ネットワーク１０６を経由して、パケットをトランザクション処理装置１０８へルーティングすることができる。

コーディネータ２１６は、ゲートウェイ１０４の処理を調整し、かつトランザクションが必ず適切に処理されるようにするために備えられている。また、コーディネータ２１６は、アプリケーション管理機能、ソフトウェア配布機能、システム監視機能、およびフェイルオーバ機能に対するサービスをゲートウェイ１０４に提供する。アプリケーション管理機能は、アプリケーションおよびサービスの開始ならびに停止に局所および遠隔で対応する。コーディネータ２１６はまた、新たなアプリケーションおよびサービスをゲートウェイ１０４に追加するのを可能にする。ソフトウェア配布機能は、ゲートウェイ１０４上にインストールすることになるソフトウェアの更新を有効にし、かつ必要な場合、繰り下げ更新への対応を含む。システム監視サービスは、メモリ、ＣＰＵ、ネットワークインタフェース、および処理のようなシステム構成要素の主要パラメータを監視し、設定されたパラメータが閾値から逸脱した場合には、アラートを発生する。システム監視サービスはまた、それが処理の故障を検出した場合に、処理を再開始する。コーディネータ２１６は、ハートビートメカニズムを用いて（マルチゲートウェイクラスタ配備の場合）、ピアゲートウェイ１０４の調子も監視し、ピアゲートウェイ１０４が故障した場合に、ピアゲートウェイ１０４の処理負荷を引き受ける。

（ルールの動的ロード）
サービスの新規登録後（以下に説明する）、ゲートウェイ１０４によって実行されるルールおよびビジネスサービスを動的に変更することができる。管理モジュール２１８および設定ローダ２２０は、ルールデータベース２２２およびフローハンドラ２１０に対する変更を動的にロードするように設定されている。

設定ローダ２２０は、設定変更、ルーティングルール、新たなフロー明細等を、ランタイムでルールデータベース２２２内にロードするように設定されている。従って、設定ローダ２２０は、ルールデータベース２２２内のルーティングルールの動的再設定を可能にする。ルールベースは、ルールオブジェクトの多数のバージョンを保持しており、ルールベースの現行バージョンへの同期参照を有する。設定ローダ２２０が更新をルールベースにロードする前に、設定ローダ２２０は、アクティブルールベースのシャドウコピーを生成し、アクティブルールベースを改版する。次いで、更新される各オブジェクトに対し、設定ローダ２２０は、オブジェクトの新たなインスタンスを生成し、ルールベースの新版内の参照を更新する。全ての更新が完了した時点で、設定ローダ２２０は、ルールベースの新バージョンをポイントするように、参照を変更する。

管理モジュール２１８は、管理行為を実行することを可能にするように設定されている。管理モジュール２１８は、１つ以上のゲートウェイ１０４を管理するために、ユーザの代理人が用いることができる。例えば、管理モジュール２１８は、おそらく、新たなルールをルールデータベース２２２内に定義するため、またはルーティングルールを動的に変更するために用いられる。また、管理モジュール２１８は、フローハンドラ２１０用の新たなフロー明細をロードおよびアンロードするため、ビジネスサービスを開始および停止するため、また設定をロードおよびアンロードするためにも用いることができる。次いで、設定ローダ２２０は、変更を実行するように設定される。

サービスのモジュール化とフロー（例えば、上述のフローの説明を参照されたい）を介したメッセージ処理サービスのランタイム起動との組み合わせにより、本発明の実施形態の動的変更が可能となる。新たなトランザクションが適応型ルートセレクタ２０８によって受信されると、適応型ルートセレクタ２０８は、ルールベースの現行バージョンを読み取り、該ルールを適用して、適切なフローを選択する。フローハンドラ２１０は、トランザクションの全存続期間に対してフローの特定バージョンを用い、各フロー明細は、サービス、フロー、およびルールの特定のバージョンを参照する。従って、更新は既存のトランザクションによって現在用いられているバージョンではなく、異なるバージョンにおいて成立するので、フローハンドラ２１０および各フロー明細は、その時点で存在するトランザクションを妨害することなく更新することができる。

（トランザクションの処理）
図３は、本発明の一実施形態によるトランザクションを処理する方法のフローチャート３００を示している。ステップ３０２で、クライアント１０２からのトランザクションが受信される。トランザクションは、例えばクレジットカード承認、チェックカードトランザクション等のような、どのような種類のトランザクションでもよい。

ステップ３０４で、トランザクションに対して、アプリケーションレベルの内容が判断される。上に述べたように、アプリケーションレベルの内容は、トランザクションを処理するために用いられる。例えば、アプリケーションレベルの内容は、クレジットカード番号、暗証番号、加盟銀行の名称（アクワイアラまたはイシュア）等かもしれない。アプリケーションレベルの内容は、全体として検討することができる。例えば、トランザクションがいくつかのパケットにパケット化されていた場合、アプリケーションレベルの内容は、多数のパケットのペイロード内で見つけることができる。この情報は、トランザクションのために、アプリケーションレベルの内容に再構築することができる。

ステップ３０６で、移送環境の現況が判断される。例えば、サービスを提供することができるトランザクション処理装置の調子が判断される。さらに、トランザクションをルーティングすることができるネットワーク１０６に対するネットワークの調子も判断することができる。この情報は、移送環境の現況を提供するために、リアルタイムで判断することができる。

ステップ３０８で、ルールがアプリケーションレベルの情報および／または移送環境の現況に適用され、サービスが決定される。例えば、特定のクライアント１０２は、特定のサービスと関連付けることができる。Ｖｉｓａのようなプロセッサのホストは、そのトランザクションが、Ｖｉｓａが所有するトランザクション処理装置に切り替えられることを所望するかもしれない。さらに、他のプロセッサのホストは、それらのトランザクションが、Ｖｉｔａｌのような二次トランザクション処理装置に切り替えられることを所望するかもしれない。

ステップ３１０で、サービスに対するトランザクションを切り替えるべきトランザクション処理装置および／またはネットワーク１０６を決定するために、ルールが提供される。この決定は、ルールに適用されたアプリケーションレベルの内容および／または移送環境の現況に基づいて判断することができる。例えば、トランザクションを処理するサービスが決定される。次いで、ネットワークの可用性に基づいて、適用可能なトランザクション処理装置１０８が決定される。

また、サービスは、種々のトランザクション処理装置１０８およびネットワーク１０６と関連付けることもできる。例えば、クレジットカード承認は、指定されたトランザクション処理装置１０８に送信されるように設定することができる。さらに、チェックカードトランザクションは、第２の組のトランザクション処理装置１０８に送信するように設定することができる。これらのルールは、クライアントおよび／またはトランザクションサービスに対して決定される。

ステップ３１２で、必要に応じて、アプリケーションレベルで、あらゆるビジネスサービスをトランザクションに対して実行することができる。例えば、トランザクションを、選択されたトランザクション処理装置１０８が要求するフォーマットにフォーマット化することも、アプリケーションレベルの何らかの情報をトランザクションに追加することも、何らかの他のビジネスサービスを実行することもできる。

ステップ３１４で、トランザクションを、ネットワーク１０６を経由して、選択されたトランザクション処理装置１０８に切り替えることができる。

代案として、別の実施形態では、ゲートウェイ１０４は、トランザクションをサービスプロバイダに切り替えることなく、トランザクションを処理するように設定されている。サービスプロバイダは、特定の基準が満たされればゲートウェイ１０４がトランザクションを処理することができると明記したルールを指定することができる。例えば、トランザクションが特定の額を下回る場合である。一例では、閾値額未満のクレジットカードトランザクションは、銀行に出向いて承認を求める必要がないばかりでなく、ネットワーク１０６を介してクレジットカード会社に連絡する必要もなく承認することができる。これは、トランザクションをネットワークの縁部で処理することができるので、多くの利点を提供する。これによって、ネットワークのボトルネックが排除され、分散処理システムが提供される。

（サービスの生成および申し込み）
上に述べたように、ルールは、ルールデータベース２２２内に動的にロードすることができる。図４は、本発明の一実施形態による、トランザクション処理装置１０８によって提示されたサービスに対して、ゲートウェイ１０４内にルールをロードするための略フローチャート４００を示している。ステップ４０２で、サービス生成要求が受信される。例えば、サービスプロバイダは、該サービスプロバイダが提示しているサービスを特定したサービス生成要求を送信することによって、サービスの登録を試みることができる。あるいは、トランザクション処理装置または他のサービスプロバイダと関連付けられたゲートウェイ１０４が、新たなサービスを動的に広告してもよく、クライアントと関連付けられたゲートウェイは、それらの新たなサービスに対する登録を開始するか否かを決定することができる。新たなサービスは、送金サービス、新たなポイントプログラム等であるかもしれない。

ステップ４０４で、サービスに対するルールが受信される。例えば、ルールは、同サービスを処理することができるトランザクション処理装置１０８のアドレスを指定することができる。ネットワークアドレスは、ＩＰアドレスでも、トランザクション処理装置１０８にトランザクションをルーティングするために用いることができる任意の他の識別子でもよい。さらに、要求をトランザクション処理装置１０８にルーティングするために用いることができるネットワーク１０６の情報も受信することができる。ルールは、サービスを利用するための基準を指定することもできる。例えば、受け入れられるために求められるフォーマットメッセージを指定する基準、サービスを利用するコスト（固定コストおよび１トランザクション当たりコストの両方）、サービスを利用するためのどのような他の基準も受信することができる。ルールは、サービスに対して、いずれの種類のカード、またはいずれの種類のアカウントもしくはアカウント番号範囲を適格とするかまたは登録するかを指定することができる。

ステップ４０６で、設定ローダ２２０を用い、管理モジュール２１８によって、サービスに対するルールがルールデータベース２２２内に動的にロードされる。さらに、サービスに対するトランザクションを処理するために必要な全てのフロー明細をフローハンドラ２０２内にロードすることができる。

従って、サービスが生成および公開された場合、クライアント１０８は、該サービスに加入することができる。図５は、本発明の一実施形態による、サービスに加入する方法の略フローチャート５００を示している。ステップ５０２で、生成されたサービスへの加入要求がクライアント１０８から受信される。要求は、ウェブポータルまたは何らかの他の方法を通じて受信することができる。クライアント１０２は、ゲートウェイ１０４に直接コンタクトしアクセスを行うことができる。

ステップ５０４で、サービスを利用するためのルールまたは基準に対する指定がクライアント１０８から受信される。この指定は、クライアント１０８から受信したトランザクションに対するサービスを選択するために必要な基準を含むことができる。基準は、クライアントに固有のものであっても、多くのクライアント１０８全体にわたって（例えば、ある事業体用の全てのＰＯＳ装置に対して）一定のものであってもよい。また、指定は、クライアント１０８が加入した各サービスの優先順位の形であってもよい。例えば、クライアントは、トランザクションに対して、第１のサービスが選択されること、しかしながら、そのサービスが稼働していない場合には、第２のサービスを選択すること等を指定することができる。基準は、より複雑であってもよく、ネットワークコスト、サービスコスト等を織り込んだ、より複雑なルールを含んでいてもよい。

ステップ５０６で、サービス要求をルーティングするためのルールが生成される。これらのルールは、サービスが選択されるように、アプリケーションレベルの内容および／またはネットワーク移送環境の現況に基づいて、満たす必要のある基準を指定することができる。

ステップ５０８で、これらのルールを、ルールデータベース２２２内に動的にロードすることができる。従って、サービスは、該サービスに加入するクライアント１０８に対して、直ちに利用可能とすることができる。

ステップ５１０で、サービス用のフロー定義が生成される。フロー定義は、サービスに対応するように設定することができる。一実施形態では、サービス用のフロー定義は、すでに存在していてもよく、生成する必要がなくてもよい。しかしながら、特化されたビジネスサービスをクライアント１０８に対して実行する必要がある場合、新たなフロー定義を生成することができる。

ステップ５１２で、ステップ５１０において生成されたフロー定義を、設定ローダ２２０によって、動的にロードすることができる。

一実施形態では、ルールは、トランザクションが送信される前に、クライアント１０２から受信することができる。例えば、クライアント１０２は、サービスに加入して、該サービスを利用するためのルールを提供することができる。別の実施形態では、ルールは、トランザクション送信の直前または直後に送信することができる。例えば、クライアント１０２は、トランザクションの前または後に送信したメッセージにおいて、利用するためのルールを指定することができる。ルールは、その後、ゲートウェイ１０４上に動的にロードされる。これにより、クライアント１０２は、ゲートウェイ１０４をランタイムで動的に設定することが可能となる。

（サービスに対するルールの分散化）
複数のゲートウェイ１０４をシステム内に配備することができる。各ゲートウェイ１０４は、それが接続されているクライアント１０２に、ゲートウェイ１０４独自のサービスを提供することができる。ゲートウェイ１０４は、ネットワークの縁部、クライアントのアクセスポイント、および、おそらくはクライアント１０２の物理的構内に配置することができる。一実施形態では、ゲートウェイ１０４は、ゲートウェイ１０４によって提示されるサービスに関する情報を格納しているだけである。異なるゲートウェイ１０４が、異なる一組のサービスに関する情報を有することができる。従って、サービスプロバイダによって登録されたかまたはクライアント１０２が加入した種々のサービスを提供するための情報は、全ゲートウェイ１０４の各々に分散することができるか、または分散化されている。情報の分散化のため、ゲートウェイ１０４は、情報の問い合わせを行うか、またはサービスに関する情報を提供するために、他のゲートウェイ１０４にコンタクトするように設定されている。

図６は、本発明の一実施形態によるゲートウェイ１０４の分散化システムを表したシステム５５０を示している。図に示すように、複数のクライアント１０２およびゲートウェイ１０４が示されている。ゲートウェイ１０４は、１つ以上のネットワーク１０６の縁部上に配置されている。

各ゲートウェイ１０４は、１つ以上のクライアント１０２に接続することができる。論述の目的で、ゲートウェイ１０４に接続された単一のクライアント１０２を示しているが、多くのクライアント１０２をゲートウェイ１０４に接続することができることを理解されたい。また、ゲートウェイ１０４はクライアント１０２の代わりにトランザクション処理装置１０８に接続してもよいことを理解されたい。

ゲートウェイ１０４は、それがネットワーク１０６の縁部で接続されているクライアント１０２に対するトランザクションを処理するように設定されている。例えば、ゲートウェイ１０４−１は、クライアント１０２−１に対するトランザクションを処理するように設定され、ゲートウェイ１０４−２は、クライアント１０４−２に対するトランザクションを処理するように設定されている。ゲートウェイ１０４−１は、クライアント１０２−１に提示されたサービスに関する情報を格納し、また、クライアント１０２−１のプリファレンスに関する情報も格納する。他のゲートウェイ１０４およびクライアント１０２も同様である。

ゲートウェイ１０４は、サービスに関する情報の分散を促進するために、他のゲートウェイ１０４に対するコンタクト情報を保持している。例えば、第１のゲートウェイ１０４が、現在第１のゲートウェイ１０４によって提示されていないサービスに関する情報を必要とする場合、第１のゲートウェイ１０４は、該サービスを提示する第２のゲートウェイ１０４にコンタクトを取り、該サービスに対するルールのような情報を、第１のゲートウェイ１０４に送信させることができる。別の実施形態では、第１のゲートウェイ１０４は、サービスに対するトランザクションを第２のゲートウェイ１０４に送信してもよく、そこで、第２のゲートウェイ１０４が、該トランザクションを処理することができる。この場合、第２のゲートウェイ１０４は、トランザクションをトランザクション処理装置１０８に切り替え、応答を受信し、次いで、該応答を第１のゲートウェイ１０４に返送することができる。

コンタクト情報は、サービスに関する情報を他のゲートウェイ１０４に分散するために用いることもできる。例えばサービスプロバイダは、第１のゲートウェイ１０４上に、新たなサービスをアップロードすることができる。次いで、サービスに対するルールが他のゲートウェイ１０４に分散される。例えば、縁部でクライアント１０２に接続されたゲートウェイは、クライアント１０２がサービスに関心を有する場合、そのルールを送信される。クライアント１０２は、クライアント１０２独自のルールをアップロードすることもできる。

各クライアントは、それが所望するサービスに対するルールのみをロードし、必要なメモリおよび更新を少なくすることができ、かつゲートウェイの処理速度を向上させることができる。例えば、ホテルのクライアントは、ポイントまたは賞のサービスを望むかもしれないが、送金サービスは望まないかもしれない。所望のサービスのみをロードすることにより、ホテルは、性能に影響を及ぼすことなく、ゲートウェイ上でより多くの情報を得ることができる。例えば、ポイントプログラム内にあるアカウント番号、またはアカウント番号の範囲は、ゲートウェイ上に格納することができ、従って、ユーザがポイントに対して適格であるかどうかを判断する処理を局所的に行うことができる。一方で、ウェブサイトクライアントは、Ｖｉｓａ認証サービスにより関心があるかもしれない。同様に、カード会員が申し込んだか否か、またパスワードを有するか否かのようなＶｉｓａ認証サービスに特有の情報およびルールを局所的に格納することができ、ユーザが加入者かどうかを決定するためにネットワークの外へ行く必要なくして、パスワードに対するプロンプティングを可能にする。いくつかの法人を有する多くのビジネスを行う特定の商人は、Ｖｉｓａビジネスカードにより関心があり、当該の特定の商人からの購入を承認されたパーチャスカードのアカウント番号の局所リストを望んでいるかもしれない。

この方法で、クライアント１０２と被送信プロバイダは、ゲートウェイ１０４で直接対話し、サービスをロードまたは要求することができる。これは、ゲートウェイを当該クライアントのニーズに合わせることができるので、クライアント１０２にとってはおそらく有利であろう。さらに、ゲートウェイ１０４をクライアントの場所に保持することができるため、容易にかつ遅延なくゲートウェイ１０４にアクセスすることができる。

従って、分散化された一組のサービスが、システム５５０によって提供される。中央処理装置を有するのではなく、処理は、ネットワークの縁部に分散される。これがボトルネックを排除し、かつフェイルオーバ保護を提供する。例えば、通常、中央処理装置を用い、それが故障した場合、システム全体のトランザクション処理に影響が及ぶ恐れがある。しかしながら、あるゲートウェイ１０４が故障しても、システム５５０全体に対する処理に支障はなく、トランザクションを他のゲートウェイ１０４に再送すればよい。

（配備のシナリオ）
ゲートウェイ１０４は、多くの異なるシナリオで配備することができる。例えば、ゲートウェイ１０４は、プライベートネットワーク上のフロントエンドとして、インターネットゲートウェイとして、かつ／または無線ゲートウェイとして配備することができる。図７は、本発明の一実施形態による、フロントエンドゲートウェイとしてのゲートウェイ１０４を表したシステム６００を示している。システム６００は、異種ネットワーク１０６を跨いで、１つ以上のクライアント１０２を１つ以上のトランザクション処理装置１０８に接続する。トランザクション処理装置１０８は、クライアント１０２からのトランザクションを処理することができるどのようなシステムでもよい。例えば、Ｖｉｓａ、ＭａｓｔｅｒＣａｒｄ等は、クレジットカードトランザクションおよびデビットカードトランザクション用のトランザクションプロセッサを所有することができ、加盟銀行（アクワイアラ／イシュア）は、クライアント１０２であり得る。

クライアントデータセンタ６０２は、クライアント１０２からのトランザクションを受信することができる。トランザクションは、クレジットカード承認でも、デビットカードトランザクションでもよい。データセンタは、例えば、クライアントのプライベートネットワークを介して多数のＰＯＳ装置に接続された中央コンピュータであってもよい。ゲートウェイ１０４は、トランザクションを処理し、該トランザクションを、トランザクション処理装置データセンタ１０８にインテリジェントに切り替える。例えば、トランザクションがＶｉｓａトランザクションである場合、トランザクション処理装置データセンタＡおよびＢをＶｉｓａと関連付けることができる。トランザクションがＭａｓｔｅｒＣａｒｄである場合、処理装置データセンタＣがＭａｓｔｅｒＣａｒｄと関連付けられているため、処理装置データセンタＣを選択することができる。

ゲートウェイ１０４は、適切なトランザクション処理装置１０８、および該トランザクションをルーティングするネットワーク１０６を決定する。次いで、トランザクションがルータ６０４に送信され、次いでルータ６０４が、該トランザクションをルーティングすることができる。一実施形態では、ルータ６０４は、パケットを、ネットワーク１０６を経由して選択されたトランザクション処理装置１０８にルーティングすることができる。

図８は、本発明の一実施形態による、ゲートウェイ１０４がインターネットゲートウェイであるシステム７００を示している。インターネットクライアント７０２は、クライアント１０２を含む。クライアント１０２は、インターネット７０４を経由して、トランザクションをゲートウェイ１０４に送信することができる。ゲートウェイ１０４は、通常のクレジットカード承認、パスワード認証（Ｖｉｓａ認証サービス）、賞またはポイント処理等のような、オンラインショッピングに必要な特定のサービス用に設定することができる。

ゲートウェイ１０４は、クライアント１０２に対して、様々なトランザクション処理装置１０８への接続性を提供する。ゲートウェイ１０４は、ＨＴＴＰ要求および他のＸＭＬベースの要求を受け入れることができる。アプリケーションレベルの内容および移送環境の現況に基づいて、サービスおよびトランザクション処理装置１０８を選択することができる。トランザクションは、ＨＴＴＰまたは何らかの他のＸＭＬベースの要求で送信しておくことができるので、ゲートウェイ１０４は、トランザクションを切り替える前に、メッセージを、トランザクション処理装置１０８が要求するフォーマットに翻訳することができる。例えば、トランザクション処理装置１０８は、メッセージがＩＳＯ８５８３フォーマットに処理されていることを要求することができる。通常、ＰＯＳ装置がトランザクションを処理する場合は、トランザクションは、ＩＳＯ８５８３フォーマットで送信することができる。しかしながら、トランザクションがインターネットゲートウェイによって処理される場合、インターネットクライアント７０２は、ＩＳＯ８５８３メッセージを送信するように設定されていないことがある。従って、ゲートウェイ１０４は、トランザクション処理装置１０８によって要求されるＩＳＯ８５８３フォーマットに、メッセージをフォーマット化するよう設定されている。

一例では、ゲートウェイ１０４は、インターネットクライアント７０２からのインターネットトランザクションを処理することができる。インターネットクライアント７０２は、ＨＴＴＰ要求をゲートウェイ１０４に送信する。ゲートウェイ１０４は、ＨＴＴＰ要求を標準的な内部メッセージフォーマットに翻訳する。次いで、任意のビジネスサービスを、トランザクションに対して実行することができる。一例では、アプリケーションレベルのデータを、トランザクション処理装置１０８によって要求されるフォーマットに適合するように変更することができる。例えば、ＸＭＬトランザクションを、ＩＳＯ８５８３フォーマットに変換することができる。次いで、ゲートウェイ１０４は、トランザクションをトランザクション処理装置１０８へインテリジェントに切り替える。

トランザクション処理装置１０８は、トランザクションを処理して、応答をゲートウェイ１０４に返信する。この応答は、トランザクション処理装置に固有のフォーマットであってよい。次いで、ゲートウェイ１０４がＨＴＴＰ応答をビルドして、それをインターネットクライアント７０２に送信する。従って、インターネットを経由したトランザクションを、ゲートウェイ１０４を用いて処理することができる。

図９は、本発明の一実施形態による、ゲートウェイ１０４が無線ゲートウェイ１０４として用いられているシステム８００を示している。ゲートウェイは、ユーザの携帯電話、ＰＤＡ、ページャ等から無線メッセージを受信することができる。ゲートウェイ１０４は、無線アプリケーションプロトコル（ＷＡＰ）、モバイル情報デバイスプロトコル（ＭＩＤＰ）、ＪＱＭＥ等のような、異なる無線フォーマットに対応するように設定することができる。ＭＩＤｌｅｔは、モバイル通信用地球規模システム（ＧＳＭ）または汎用パケット無線サービス（ＧＰＲＳ）のようなネットワークを通じて、ＸＭＬフォーマットの要求を送信する。ゲートウェイ１０４は、インバウンド要求のペイロードを、標準的な内部メッセージフォーマットに変換することができる。次いで、内部メッセージフォーマット（ＩＭＦ）を、ビジネスサービスによって処理することができる。アウトバウンドメッセージストリームビルダ２１２は、ＩＭＦを、トランザクション処理装置１０８に送信するための応答ペイロードに変換する。従って、無線トランザクションは、ゲートウェイ１０４によって処理することができる。

ここで、無線トランザクションについて説明する。一実施形態では、無線クライアント８０８は、ＨＴＴＰ／ＧＳＭ／ＧＰＲＳを通じてＸＭＬ要求を送信することにより、無線支払トランザクションを開始する。ゲートウェイ１０４は、ＸＭＬ要求を受信して、該要求を処理する前に、それを標準的な内部メッセージフォーマットに変換する。移送環境の現況に加え、トランザクション内のアプリケーションレベルの内容を用いて、トランザクションがトランザクション処理装置１０８に切り替えられる。選択されたトランザクション処理装置１０８に応じて、フローハンドラ２１０が、トランザクションに対してビジネスサービスを実行することができる。その後、トランザクションは、トランザクション処理装置１０８に送信される。

トランザクション処理装置１０８は、クライアント銀行（またはイシュア）８０２を決定し、メッセージをイシュア８０２へルーティングする。イシュア８０２は、要求を処理して、応答をトランザクション処理装置１０８に返信する。次いで、トランザクション処理装置１０８は、応答（トランザクション処理装置固有のフォーマットで）をアクワイアラ８０４に返信する。ゲートウェイ１０４は、応答を受信し、それをＸＭＬフォーマットに翻訳し、それを無線クライアント８０８に送信する。従って、ゲートウェイ８０４は、無線トランザクション支払をルーティングするように設定されている。

図１０は、本発明の一実施形態によるＩＳＯ８５８３トランザクションを処理するシステム９００を示している。図に示すように、イシュア銀行９０２およびアクワイアラ銀行９０４がトランザクションに関与している。アクワイアラ銀行９０４のクライアントコンピュータ１０２は、ＩＳＯ８５８３要求をゲートウェイ１０４に送信する。ゲートウェイ１０４は、アプリケーションレベルの内容および移送環境の現況を用いてトランザクション処理装置１０８を選択し、要求を処理する。次いで、要求に対して何らかのビジネスサービスが実行された後、選択されたトランザクション処理装置１０８にメッセージが送信される。

トランザクション処理装置１０８は、トランザクションを処理し、認証のために、該トランザクションを適切なイシュア９０２に切り替える。イシュアは、トランザクション処理装置１０８にＩＳＯ８５８３を返送する。次いで、トランザクション処理装置１０８がゲートウェイ１０４に応答を送信し、次いで、応答がアクワイアラ銀行１０２のクライアント１０２に送信される。

一例では、あるトランザクション処理装置１０８が利用不能となるかもしれない。この場合、例えば、プロセッサＡ、データセンタ０１が利用不能となるかもしれない。これは、サービスに対するクライアント１０２の優先プロセッサであるかもしれない。その場合、ゲートウェイ１０４は、トランザクションを第２のプロセッサ、プロセッサＡ、データセンタ０２に送信する。ゲートウェイ１０４は、主データセンタの可用性をチェックし続け、ひとたびそれが利用可能になれば、主データセンタへのメッセージのルーティングを開始することができる。トランザクションの再ルーティングは、クライアント１０２には見えない方法で行われる。従って、ゲートウェイ１０４のインテリジェント切り替え機能を用いて、いずれのトランザクション処理装置１０８のダウンタイムも回避される。

別の実施形態では、プロセッサＡのデータセンタが故障しているかもしれず、プロセッサＢおよびＣのような、他のプロセッサの他のデータセンタを使用する必要があるかもしれない。プロセッサＢおよびＣは、プロセッサＡとは異なるフォーマットのトランザクションを処理するのかもしれない。この場合、ゲートウェイ１０４は、トランザクションのフォーマットを、プロセッサＢまたはプロセッサＣのフォーマットに相当するフォーマットに変換することができる。次いで、フォーマット化されたトランザクションが、プロセッサＢまたはプロセッサＣに送信される。結果的に、クライアント１０２には見えない方法で、異なるプロセッサを用いることができる。たとえプロセッサが異なるフォーマットを用いていても、ゲートウェイ１０４は、それでもそのフォーマットのトランザクションをルーティングするように設定されている。

（メッセージのパース／ビルド）
（パースビルドエンジンの概要）
図１１は、本発明の一実施形態によるメッセージをパースするシステム１０００を示している。システム１０００は、ＩＳＯ８５８３メッセージのようなマルチフォーマットメッセージストリームを、内部メッセージフォーマット（ＩＭＦ）と呼ばれる標準的なメッセージフォーマットにパースし、ＩＭＦから、ＩＳＯ８５８３メッセージストリームのようなマルチフォーマットメッセージストリームをビルドする。財務メッセージストリームについて説明しているが、システム１０００を用いて、どのようなマルチフォーマットメッセージストリームもパースおよびビルドすることができることを理解されたい。

パース／ビルドエンジン１００４は、図２のインバウンドメッセージストリームパーサ２０４およびアウトバウンドメッセージストリームビルダ２１２に相当する。図２に示す全ての構成要素を図１１に示していないが、それらの構成要素もシステム１０００に含めることができることを理解されたい。さらに、パース／ビルドエンジン１００４はゲートウェイ１０４に含めることができるが、他の構成要素にも含めることができる。例えば、パース／ビルドエンジン１００４は、他の異種システムとは異なるデータフォーマットのデータを処理するどのようなソフトウェアアプリケーションとも互換性を有することができる。

パース／ビルドエンジン１００４は、システム１００６から入力メッセージストリーム１０１０を受信し、該メッセージを内部メッセージフォーマットにパースする。内部メッセージフォーマット（ＩＭＦ）は、次いで、ゲートウェイ１０４に示すビジネスサービスアプリケーションのような他の構成要素によって処理することができる。ゲートウェイ１０４内の構成要素がＩＭＦのメッセージを処理した後、パース／ビルドエンジン１００４が、処理済のＩＭＦから出力メッセージストリーム１０１２をビルドする。出力メッセージストリーム１０１２は、次いで、システム１００８に送信されるか、または送信元システム１００６に返信される。

システム１００６および１００８は、メッセージ１０１０を送信し、かつ／またはパース／ビルドエンジン１００４（またはゲートウェイ１０４）からメッセージ１０１２を受信するように設定されたどのようなシステムでもよい。一実施形態では、システム１００６および１００８は、店舗販売時点情報管理装置、スマートカード装置、トランザクション処理装置１０８、アクワイアラ、イシュア、サービスプロバイダ、トランザクションオーセンティケータ等のような、トランザクションを処理するように設定された何らかのシステムとすることができる。システム１００６および１００８は、ＩＳＯ８５８３メッセージ、拡張可能なマーク付け言語（ＸＭＬ）、ＨＴＭＬ等のような、多くの異なるフォーマットのメッセージを送信／受信することができる。入力メッセージストリームも、ＡＳＣＩＩ、ＥＢＣＤＩＣ、ＢＣＤ、等のような、多数の符号化スキームのうちのいずれかとすることができ、数値、文字列、バイトアレイ等のような、異なるデータタイプを有することができる。

図１１のパース／ビルドエンジンは、スキーマテーブル１０２８を用いる。各スキーマは、受信したフォーマット用の文法構造、およびハンドラテーブル１０３０内のハンドラへのポインタを含む、メタデータを提供するデータ構造である。ハンドラは、メッセージ内の特定のフィールドに対応し、文法構造を用いて、メッセージの様々なフィールドを、内部メッセージフォーマットに変換する。ハンドラは、個々にコンパイルされるコードである。従って、システム全体をコンパイルせずに、ハンドラが別個にコンパイルされ、エンジンの他の要素に支障を来たすことなく容易にアップグレードすることができるモジュラーシステムを保持しながら、コンパイルされたソフトウェアの速度を速めている。

パース／ビルドエンジン１００４は、特定されたスキーマをロードし、該スキーマと関連付けられたハンドラの機能を呼び出す。次いで、ハンドラが、メッセージのフィールドをＩＭＦオブジェクトにパースする。

事前ロードされていないスキーマ、および関連付けられた全てのハンドラを、スキーマローダ１０２４を用いて、スキーマ定義ファイル１０２６から、スキーマテーブル１０２８およびハンドラテーブル１０３０内にロードすることができる。スキーマテーブル１０２６は、スキーマのｎａｍｅ１、ｎａｍｅ２．．．，ｎａｍｅＮのラベル付きの種々のスキーマを含む。パース／ビルドエンジン１００４によってパースおよびビルドされ得る各メッセージに対し、対応するスキーマを提供することができる。各スキーマ名は、外部フォーマット内のメッセージストリームの「文法」、構成を定義するスキーマオブジェクトと関連付けられている。構成には、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意または必須の他のフィールドが含まれる。新たなスキーマおよびコンパイルされたハンドラがロードされ、パース／ビルドエンジン１００４を再コンパイルすることなく、パース／ビルドエンジン１００４によって用いられることができる。

（パース／ビルドフロー）
ここで、フローの一例を説明する。図１１に示すように、メッセージが受信されると、ビジネスサービスプログラムがパース／ビルドエンジン１００４を呼び出す。メッセージ１０１０（ワイヤフォーマットのメッセージストリーム）がパース／ビルドエンジンに送信され、そこで、メッセージ１０１０は、最初にパーサ構成要素１０１６によって受信される。ビジネスサービスアプリケーションは、パーサ構成要素１０１６にスキーマ名１０１１も提供する。パーサ構成要素は、内部メッセージフォーマット（ＩＭＦ）オブジェクトを生成する。オブジェクトの中には、一旦メッセージフィールドがＩＭＦに翻訳されると、メッセージフィールドからの値が格納される。一実施形態では、パーサ構成要素１０１６は、メッセージ１０１０の起点を認識し、該起点から送信されたメッセージ１０１０に対して必要なスキーマを決定する。別の実施形態では、メッセージ１０１０内の情報をパースしてデータフォーマットを判断し、それにより、用いるべき対応するスキーマを決定することができる。さらに、メッセージ１０１０は、どのスキーマが当のデータフォーマットに対応するかを示すことができる。

一例では、パーサ構成要素１０１６は、最初に、ＩＳＯ８５８３財務メッセージのような、検出されたメッセージのフォーマットに対応するルートスキーマを調べる。そのようなＩＳＯメッセージは、どのフィールドが存在するかを特定するビットマップを冒頭に有している可能性がある。ルートスキーマは、ハンドラをポイントし、ハンドラが呼び出されて、タイプフィールドをパースし、何のタイプのメッセージが受信されたか（例えば、承認メッセージ、調整メッセージ等）を判定する。パーサ構成要素は、次いで、特定されたメッセージタイプに対するスキーマを調べ、次いで、スキーマが特定の文法を提供し、当該のメッセージタイプに対するハンドラをポイントする。スキーマおよびハンドラは、実際にメッセージ内に存在するフィールドに対してのみ調査および呼び出しが行われる。新たなフィールドが特定またはポイントされた際は、新たなスキーマを調べ、対応するハンドラを呼び出すことができる。特定のフィールドが１つ以上の条件を有する複合フィールドである可能性もあり、該条件の翻訳またはパーシングが、条件の結果によって、追加のスキーマおよび関連付けられたハンドラをポイントすることができる。

ＩＭＦオブジェクト１０１８（以下により詳細に説明する）は、呼び出されたハンドラによって埋め込みされる。埋め込みされるフィールドは、入力メッセージに含まれるフィールドに対応するフィールドのみである。

ＩＭＦオブジェクト１０１８は、次いで、ゲートウェイ１０４のビジネスソフトウェアアプリケーションによって処理される。処理された後、ＩＭＦオブジェクト１０１８は、アウトバウンドメッセージストリームに対するスキーマ名と共に、ビルド構成要素１０２０に送信される。処理済ＩＭＦオブジェクト１０１８の処理は異なるデータフォーマットで実行され得るので、ビルダ構成要素１０２０は、処理済のＩＭＦオブジェクト１０１８から出力メッセージストリーム１０１２をビルドするように設定されている。上述の処理は、ビルダ構成要素１０２０がルートスキーマを調べ、何度も繰り返すことができる工程において、ポイントされたハンドラを呼び出して、タイプ情報をビルドしながら、逆順に反復される。呼び出されたハンドラは、ＩＭＦオブジェクト１０１８内で見出した値を、出力メッセージストリーム１０１２に含める必要のあるフィールドにビルドする。その後、出力メッセージストリーム１０１２を、出力メッセージストリーム１０１２を処理することができる、システム１００８に送信することができる。

図１２に、ＩＭＦオブジェクト１０１８を用いて、ゲートウェイ１０４によって提供されるあらゆるサービスを実行するビジネスサービスアプリケーション１１０２を示す。ビジネスサービスアプリケーション１１０２は、ＩＭＦオブジェクト１０１８に対して動作する。動作には、イシュア銀行またはメッセージ送信先処理センタの判定のような、アプリケーション層ルーティングを含めることができる。さらに、サービスは、メッセージストリームのアプリケーションレベルのフォーマット化、ロギング、時刻表示、応答またはさらに別の処理に必要な新たなフィールドの生成等のように、メッセージに対して実行することもできる。ビジネスサービスアプリケーションは、イシュアまたは財務ネットワークに対する前処理を行うことも、負荷分担された局所処理を実行することもできる。例えば、＄５０未満の購入に対する許可メッセージを承認し、承認を求めて金融機関にメッセージを転送する必要なくして、応答メッセージを送信することができる。ビジネスサービスアプリケーション１１０２は、内部メッセージフォーマットのデータを処理するように設定されており、外部フォーマットに対してはそうではない。従って、ビジネスサービスアプリケーション１１０２は、メッセージをＩＭＦにパースすることによって他のシステムで用いられているどのような外部フォーマットからも隔離されている。

（ＩＭＦの構造）
図１３Ａは、本発明の一実施形態によるＩＭＦ１０１８用の構造を示している。図に示すように、ＩＭＦ１０１８内にＮ個のフィールドが提供されている。これらのフィールドは、各フィールドが任意数の子フィールドも含むことができ、順に孫フィールド等を含むことができる、階層構造のフィールドのアレイとすることができる。例えば、フィールド１は、子フィールド１．１、１．２、 ．．．１．Ｎを含む。フィールド１．２、 ．．．１．Ｎも、任意数の子フィールド（図示せず）を含むことができる。メッセージがもし受信されたときは、実際に用いられるフィールドのみにデータが埋め込みされる。

図１４Ｂに、オブジェクトのＩＤコード（図１３Ａに示すフィールドに対するフィールド定義の索引）を有する階層フォーマットを示す。ＯＩＤは、ＩＭＦオブジェクト１０１８内の種々のフィールドに対する索引付けを可能にする。フィールド定義は、ＯＩＤを用いて、ＩＭＦオブジェクト１０１８内のフィールドに対してアクセスされる。一実施形態では、ＯＩＤは、図に示すドット数値表現によって表される８バイトの数である。第１のフィールドに対するＯＩＤは、１．０．０として符号化されている。任意のサブフィールドは、１．１．０、１．２．０等々として符号化されている。第２のフィールドは、２．０．０として符号化され、任意のサブフィールドは、２．１．０、２．２．０等々として符号化されている。

（スキーマの構造）
図１３Ｂに、スキーマの一例を示す。スキーマのアドレスは、第１行、メッセージ定義（ＭｅｓｓａｇｅＤｅｆ）である。スキーマは、メッセージ内のフィールドの各々の文法とハンドラへのポインタとを含む。図示の例では、メッセージの第１のフィールドは、索引１．０．０を付けたＦｉｅｌｄ Ｄｅｆｉｎｉｔｉｏｎ Ｏｂｊｅｃｔ（ＦｉｅｌｄＤｅｆ）１２０２で識別されている。これは、ＯＩＤ属性１２０２とも呼ばれる。このフィールドに対する索引の後に続いているのは、呼び出し対象のハンドラ（ＨＤＲ）の識別１２０４である。当該行の要素の残り部分は、当該の特定フィールドの文法定義である。これらのフィールド定義は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、必要なハンドラの名前等のような、そのフィールドの特性を説明している。フィールド定義は、ＡＳＣＩＩ、ＥＢＣＤＩＣ、ＢＣＤ等のような異なる符号化方式で符号化されたフィールド、および数字、文字列、バイトアレイ等のような異なるデータタイプをパース／ビルドするために用いることができる。従って、マルチフォーマットメッセージストリームは、メッセージ定義を用いて処理することができる。一実施形態では、スキーマは、ＸＭＬスキーマの形のメタデータである。

フィールド定義は、いくつかの属性を含むことができる。図１３Ｂに示されている属性は網羅的ではないことが認識されるであろう。また当業者は、他の属性を用いてもよいことが分かるであろう。

ハンドラ属性１２０４は、フィールドの名前である。必須／任意属性１２０６は、そのフィールドがメッセージ内で必須であるかまたは任意であるかを示している。第１のデータフォーマット属性１２０８は、外部フォーマット（ワイヤフォーマットとも呼ばれる）内で見出されたフィールドの値に対するデータフォーマットである。第２のデータフォーマット属性１２１０は、フィールドがＩＭＦで格納され、ビジネスサービスによって処理される内部フォーマットである。

カスタム／非カスタム属性１２１２は、フィールドのパーシングおよびビルディングに、フィールドがカスタムハンドラを用いるかまたは汎用ハンドラを用いるかを示している。

７番目の属性１２１４は、メッセージのフィールド内の値を処理するために必要なハンドラの名前を示している。ハンドラは、受信メッセージの特定されたフィールド内の値を取り、それをＩＭＦにパースする（パーサスキーマ用）か、またはＩＭＦからの値を外部フォーマットにビルドする（ビルダスキーマ用）。

８番目の属性１２１６は、フィールド内のサブフィールドの数を示している。

（ＩＭＦ（内部メッセージフォーマット）に用いられるメッセージフィールドの例）
図１４Ａは、いくつかの異なるフィールドのオブジェクトＩＤ（ＯＩＤ）、１．０．０、１．１．０、１．１．１、２．０．０、２．２．０、４．０．０、および４．１．０を含む、特定のメッセージオブジェクト１０１０に用いられるフィールドの一例を示している。これらは、図１３Ｂのスキーマによってポイントされるフィールドである。従って、このメッセージ例では、図１４Ｃに特定されたフィールドのみが、図１３Ａに示すメッセージオブジェクトに埋め込みされる。図１４Ｂは、内部メッセージフォーマットの完全なフィールドのセットの全階層オブジェクトＩＤの一部を示している。図に見られるように、メッセージ１０１０は、これらのフィールドのうちの、メッセージ１０１０が必要とする部分のみを含んでいる。例えば、オブジェクトＩＤ１．２．０、３．０．０、および４．２．０は用いられていない。これらのフィールドは任意の数の子フィールドを有することができることに留意されたい。

オブジェクトＩＤは、図１３Ａに示すメッセージオブジェクトの階層型内部メッセージフォーマットへの素早い索引付けシステムを提供する。この索引付けシステムは、受信したフォーマットに用いられている各フィールド用に、内部メッセージフォーマットの対応するフィールドに索引を付ける（ポイントする）、符号化オブジェクトＩＤ（１．０．０など）を用いる。この索引は、階層構造の数層下にあるフィールドを直接ポイントすることができる。

ゲートウェイ１０４の構成要素がＩＭＦオブジェクト１０１８を処理する際には、不要なフィールドの処理は実行されない。従って、処理速度が向上する。

必須フィールドも、ＩＭＦオブジェクト１０１８に追加することができる。いくつかのフィールドは、ビジネスサービスモジュール１１０２またはトランザクション処理装置１０８には必須であるかもしれない。用いる必要のあるフィールドが受信メッセージ１０１０内に含まれていないと判断された場合、該フィールドは、ビジネスサービスモジュールによって埋め込みをし、再トランザクション用にビルドされることになるメッセージに含めることができる。このようにして、メッセージ１０１０内に含まれていない場合、図１３Ｂのスキーマ内の「必須」フィールドをＩＭＦオブジェクト１０１８に追加することができる。

（パース／ビルドエンジンの初期設定）
図１５は、ビジネスサービスアプリケーションのスタートアップと同時にパース／ビルドエンジン１００４を初期設定する方法の略フローチャート１４００を示している。ステップ１４０２で、初期設定要求がアプリケーションから受信される。この要求には、１つ以上のスキーマ定義ファイル１０２６の位置が含まれている。

ステップ１４０４で、スキーマ定義ファイル１０２６内で見出されたスキーマが検証される。スキーマは、的確なタイプのデータが参照されていること、スキーマによって特定されたハンドラが実際に存在すること等の検証のような、いくつかの手順によって検証される。

ステップ１４０６で、スキーマ定義ファイル１０２６内のスキーマが、レジストリ１０２２内に、スキーマローダ１０２４を用いて、ディスクまたは他のストレージリポジトリからＤＲＡＭメモリ内にロードされる。

ステップ１４０８で、スキーマ内で指定された全てのハンドラが、レジストリ１０２２内にロードされる。例えば、メッセージ定義オブジェクト内のフィールド定義によって指定されたハンドラが、ハンドラテーブル１０３０内にロードされる。一実施形態では、ハンドラは、ハンドラの名前でキーボードから入力されたオブジェクトとして格納されている。

ステップ１４１０で、ハンドラがそれぞれのメッセージ定義オブジェクトに結合される。例えば、メッセージ定義オブジェクト内のフィールド定義によって指定された全てのハンドラが、当該のメッセージ定義オブジェクトに結合される。

これで、スキーマに対するパース／ビルドエンジン１００４の初期設定が完了する。一実施形態では、パース／ビルドエンジン１００４のコンパイルはでは必要ない。それは、フィールド値をパース／ビルドするために用いられるコンパイル済みハンドラを使用するからである。

ランタイム中に、スキーマを動的に更新し、パース／ビルドエンジン１００４に追加することができる。スキーマは、メッセージ定義オブジェクトを変更することによって更新してもよく、新たなメッセージ定義オブジェクトを付加することによって追加してもよい。新たなハンドラが必要な場合、それらも、コンパイル済みオブジェクトとして、パース／ビルドエンジン１００４に動的に追加することができる。

スキーマは、パース／ビルドエンジン１００４を再コンパイルすることなく、かつそれを停止させることなく、追加することもできる。従って、パース／ビルドエンジン１００４は、スキーマが更新される際でさえも、メッセージをパース／ビルドし続けることができる。

（スキーマの追加または更新）
図１６は、本発明の一実施形態による、パース／ビルドエンジン１００４内のスキーマを動的に追加または更新する方法の略フローチャート１５００を示している。ステップ１５０２で、スキーマを動的に追加または更新するようにとの要求がアプリケーションから受信される。この要求は、新たな、または更新されたスキーマを含む１つ以上のスキーマ定義ファイル１０２６の位置を含んでいる。

ステップ１５０４で、スキーマ定義ファイル１０２６内で見出されたスキーマが検証される。

ステップ１５０６で、スキーマ定義ファイル１０２６内のスキーマがレジストリ１０２２内にロードされる。更新されたスキーマに一組の新たなフィールド定義または変更されたフィールド定義が提供されている場合、新たな、または変更されたフィールド定義のみをレジストリ１０２２内にロードすればよい。スキーマを追加または更新している間、適切なデータ構造が更新をロックされ、処理中のインフライトメッセージがスキーマ変更の結果破壊されないことが確保される。スキーマローダ１０２４がスキーマの更新バージョンをロードする間、インフライトメッセージは、スキーマの前バージョンを使用し続ける。

ステップ１５０８で、メッセージ定義オブジェクト内で指定された全てのハンドラが、レジストリ１０２２内にロードされる。パース／ビルドエンジン１００４は、いずれかのハンドラがレジストリ１０２２内にすでに存在する場合、それらのハンドラをレジストリ１０２２内に再ロードしないように判断するために、チェックを行うことができる。しかしながら、いずれかのハンドラが変更されていた場合、該変更されたハンドラがロードされる。

ステップ１５１０で、それぞれのメッセージ定義オブジェクトにハンドラが結合される。一実施形態では、新たな、または変更されたハンドラのみが、更新済みのメッセージ定義オブジェクトに結合される。これで、パース／ビルドエンジン１００４の動的な更新が完了する。

（パース工程のフローチャート）
図１７は、本発明の一実施形態による、入力メッセージストリーム１０１０をパースする方法の略フローチャート１６００を示している。ステップ１６０２で、メッセージ用のスキーマが決定される。そのスキーマは、入力メッセージストリーム１０１０を構成しているデータフォーマットに対応している。

ステップ１６０４で、スキーマ内のポインタから、メッセージ定義オブジェクトに対する全てのハンドラが決定される。

ステップ１６０６で、各フィールド用のハンドラがフィールドに添付される。

ステップ１６０８で、ハンドラがメッセージの各フィールドを翻訳する。各フィールドに対して１つのハンドラが呼び出される。ハンドラは、スキーマ内のフィールド定義を用いて、フィールドの値をＩＭＦに翻訳する。フィールドに対するＯＩＤは、当該のフィールド用スキーマ内のフィールド定義をポイントし、かつＩＭＦオブジェクト１０１８内の対応するフィールドもポイントする。

一実施形態では、パーサ構成要素１０１６は、メッセージ１０１０内に読み込まれたフィールドに対するオフセットを保持する。例えば、読み込まれたバイト数は、オフセットとして格納される。パーサ構成要素は、各ハンドラが呼び出される度に、このオフセットの数を減らしてゆく。ハンドラがメッセージ１０１０の末尾に到達する（例えば、オフセットが特定の長さと等しくなる）か、またはメッセージ定義オブジェクト内の最後のフィールド定義に到達すると、パーサ構成要素は、翻訳が完了したことを認識する。

ステップ１６１０で、翻訳されたフィールドが、ＩＭＦオブジェクト１０１８の対応する階層内に格納される。フィールドに対するＯＩＤは、ＩＭＦオブジェクト１０１８内の階層内の対応する位置に、翻訳された値を格納するために用いることができる。

上述の翻訳がいずれかの地点で失敗となった場合、エラーをゲートウェイ１０４に返すことができる。パーシングは続行することができ、ＩＭＦオブジェクト１０１８は返すことができる。しかしながら、ＩＭＦオブジェクト１０１８内に、エラーフラグを付けることができる。

（ビルド工程のフローチャート）
ここで、図１８に関して、ビルド工程を説明する。図１８は、本発明の一実施形態による、ＩＭＦオブジェクト１０１８から出力メッセージストリーム１０１２をビルドする方法の略フローチャート１７００を示している。ステップ１７０２で、スキーマ名およびＩＭＦオブジェクト１０１８が決定される。一実施形態では、ＩＭＦオブジェクト１０１８が最初に決定される。スキーマ名は、ＩＭＦオブジェクト１０１８内の情報に基づいて決定することができる。例えば、スキーマ名は、ＩＭＦオブジェクト１０１８内の情報内に格納することができる。また、スキーマ名は、ＩＭＦオブジェクト１０１８内の情報を送ることになるチャネルまたは宛先システムによって決定してもよい。

ステップ１７０４で、メッセージ定義オブジェクトを用いて、レジストリ１０２２内のスキーマをアドレス指定する。ステップ１７０６で、スキーマに対して必要なハンドラも全て決定される。

ステップ１７０８で、ＩＭＦオブジェクト１０１８内で見出された各フィールドに対して、ＩＭＦオブジェクト１０１８内の階層内の対応するフィールドからの値がロードされる。フィールドに対するＯＩＤを用いて、フィールド定義にアクセスする。

ステップ１７１０で、フィールドに対するフィールド定義の属性に従って、ＩＭＦオブジェクト１０１８内のフィールドから、値が翻訳される。その結果、ＩＭＦフォーマット内で見出された値は、別のシステムと互換性を有するフォーマットに翻訳される。

ステップ１７１２で、ビルドされた値が、生成された出力メッセージストリーム１０１２の対応するフィールド内に組み立てられる。

ＩＭＦオブジェクト１０１８内のフィールドに対する値が、外部フォーマットに対して必須のフィールド用に見出されない場合、外部メッセージ内の当該のフィールドに対する値を空白に設定してもよく、生成されたメッセージが単にメッセージ内にこのフィールドを有していなくてもよい。さらに、ＩＭＦオブジェクト１０１８がこのフィールドを有していたはずであると判断された場合、ＩＭＦオブジェクト１０１８内にフィールドが見つからなかったことを示すエラーを返すことができる。

（代案）
本発明は、ソフトウェアまたはハードウェア、もしくは両方を組み合わせたものにおける制御論理の形で実施することができる。この制御論理は、本発明の実施形態に開示した一組のステップを実行するよう情報処理装置を導くようになっている複数の命令として、情報記憶媒体に格納することができる。本明細書に提供される開示および教示に基づき、当業界の通常の技術者は、本発明を実施する他の手段および／または方法が分かるであろう。

上述の説明は、例証となるものであるが、限定するものではない。本開示を検討すれば、当業者には、本発明の多くの変形形態が明らかとなるであろう。従って、本発明の範囲は、上述の説明を参照して決定されるのではなく、出願に係る請求項を参照して、包括的にあるいは均等物も加えて決定されるべきである。

Claims (17)

1. メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
   複数のフィールドを含むメッセージを受信することと、
   前記受信されたメッセージのバイト数をオフセットとして格納することと、
   複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも１つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
   前記メッセージの前記フィールド用の１つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの１つをポイントし、かつ、１つ以上のフィールド用の文法定義を含む、ことと、
   前記複数のハンドラを用いて、前記メッセージの前記１つ以上のフィールドを前記共通の標準的な内部メッセージフォーマットに翻訳することであって、前記共通の標準的な内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含み、前記パースすることは、前記メッセージ内の前記１つ以上のフィールドに対してのみ行われ、前記共通の標準的な内部構造フォーマットの対応するフィールドのみが作成される、ことと、
   前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
   を含む、方法。
2. メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
   複数のフィールドを含むメッセージを受信することと、
   前記受信されたメッセージのバイト数をオフセットとして格納することと、
   複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも１つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
   前記メッセージの前記フィールド用の１つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの１つをポイントし、かつ、１つ以上のフィールド用の文法定義を含み、前記スキーマに含まれる各メッセージフィールドは、オブジェクトＩＤによって識別され、前記オブジェクトＩＤは、前記共通の標準的な内部メッセージフォーマット内の特定の場所をポイントする索引である、ことと、
   前記複数のハンドラを用いて、前記メッセージの前記１つ以上のフィールドを前記共通の標準的な内部メッセージフォーマットに翻訳することと、
   前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
   を含む、方法。
3. 他のスキーマおよびハンドラを再コンパイルすることなく、前記１つ以上のスキーマを動的にロードすることをさらに含む、請求項１に記載の方法。
4. 前記翻訳することから後続のスキーマを決定することと、
   前記メッセージに対して、前記後続のスキーマに対して請求項１に記載のプロセスを繰り返すことと
   をさらに含む、請求項１に記載の方法。
5. ビジネスサービスアプリケーションによって、前記共通の標準的な内部メッセージフォーマットの前記メッセージを処理することをさらに含む、請求項１に記載の方法。
6. 前記ビジネスサービスアプリケーションによる前記処理は、前記フィールド内の値を変更することを含む、請求項５に記載の方法。
7. 前記処理後、前記共通の標準的な内部メッセージフォーマットの前記メッセージを外部メッセージフォーマットにビルドするために、第２の１つ以上のスキーマのセットを決定することと、
   前記メッセージ内に含まれる前記１つ以上のフィールドに対応する前記第２の１つ以上のスキーマのセットにおけるフィールド定義およびハンドラを決定することと、
   前記ハンドラを用いて、前記外部メッセージフォーマットの１つ以上のフィールドをビルドすることと
   をさらに含む、請求項６に記載の方法。
8. 前記メッセージは、財務トランザクションを含む、請求項１に記載の方法。
9. 前記メッセージの前記１つ以上のフィールド以外の全ての必要なフィールドを決定することであって、前記必要なフィールドは出力メッセージに必須である、ことと、
   前記必要なフィールドが決定された場合、前記メッセージの前記１つ以上のフィールド以外の前記必要なフィールドを前記共通の標準的な内部メッセージオブジェクトに追加することであって、前記１つ以上のフィールドおよび前記必要なフィールドだけが前記内部メッセージオブジェクト内に作成され内包されたフィールドである、ことと
   をさらに含む、請求項１に記載の方法。
10. メッセージをパース／ビルドするように構成されているエンジン用の命令を含むコンピュータ読み取り可能な格納媒体であって、前記エンジンは、
    複数のハンドラであって、各ハンドラは、フィールド用の文法を用いて受信メッセージの複数のフィールドのうちの少なくとも１つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、複数のハンドラと、
    様々なタイプのメッセージ用の複数のスキーマであって、各スキーマは、前記複数のハンドラのうちの１つをポイントし、かつ、メッセージの１つ以上のフィールド用の文法定義を含む、複数のスキーマと、
    共通の標準的な内部メッセージフォーマットオブジェクトであって、前記複数のハンドラは、前記共通の標準的な内部メッセージフォーマットオブジェクトを前記メッセージ内で見い出されたフィールド、および／または、必須フィールドについてだけ作成するように構成されており、前記共通の標準的な内部メッセージフォーマットは必要となる可能性があるフィールドからなる階層構造を含む、共通の標準的な内部メッセージフォーマットオブジェクトと
    前記受信されたメッセージのバイト数を示すオフセットを維持するパーサであって、前記パーサの構成要素は、前記複数のハンドラが前記共通の標準的な内部メッセージフォーマットを作成する場合に前記オフセットを減らし、前記パースは、前記減らされたオフセットが所定値に等しい場合に終了する、パーサと
    を含む、コンピュータ読み取り可能な格納媒体。
11. 前記共通の標準的な内部メッセージフォーマットの前記メッセージを処理するように構成されているビジネスサービスモジュールをさらに含む、請求項１０に記載のコンピュータ読み取り可能な格納媒体。
12. 前記エンジンは、前記共通の標準的な内部メッセージフォーマットからメッセージをビルドするように構成されており、前記エンジンは、
    第２の１つ以上のスキーマのセットであって、前記第２の１つ以上のスキーマのセットは、メッセージ内のフィールドを前記共通の標準的な内部メッセージフォーマットから外部メッセージフォーマットにパースするのに使用可能なフィールド定義を含む、第２の１つ以上のスキーマのセットと、
    前記第２のスキーマのセット用の１つ以上のハンドラであって、前記ハンドラは、前記第２のスキーマのセット内の前記フィールド定義を用いて、前記メッセージ内のフィールドを前記共通の標準的な内部メッセージフォーマットから前記外部メッセージフォーマットにパースするように構成されている、前記第２のスキーマのセット用の１つ以上のハンドラと
    を含む、請求項１１に記載のコンピュータ読み取り可能な格納媒体。
13. メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
    複数のフィールドを含むメッセージを受信することと、
    前記受信されたメッセージのバイト数をオフセットとして格納することと、
    複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも１つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
    前記メッセージの前記フィールド用の１つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの１つをポイントし、かつ、１つ以上のフィールド用の文法定義を含む、ことと、
    前記複数のハンドラを用いて、前記メッセージの前記１つ以上のフィールドの全てを前記共通の標準的な内部メッセージフォーマットに翻訳することであって、前記共通の標準的な内部メッセージフォーマットは、前記受信されたメッセージの前記フィールドの全てを少なくとも含み、前記共通の標準的な内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含む、ことと、
    前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
    を含む、方法。
14. 前記共通の標準的な内部メッセージフォーマットに少なくとも１つのフィールドを追加することをさらに含み、前記フィールドは、前記受信されたメッセージに含まれていない、請求項１３に記載の方法。
15. 前記共通の標準的な内部メッセージフォーマットから出力メッセージを形成することをさらに含み、前記出力メッセージは、前記共通の標準的な内部メッセージフォーマットに存在しない少なくとも１つのフィールドを含む、請求項１４に記載の方法。
16. 前記受信されたメッセージは、ＩＳＯ８５８３財務メッセージである、請求項１に記載の方法。
17. 前記翻訳するステップが失敗した場合に、前記共通の標準的な内部メッセージフォーマットにエラーフラグを設定することをさらに含む、請求項１に記載の方法。