マルチフォーマットのメッセージをパースする動的パース/ビルド・エンジン
【課題】マルチフォーマットのメッセージをパースする動的パース/ビルド・エンジンを提供すること。
【解決手段】マルチフォーマットの財務メッセージを処理することができるパース/ビルドエンジン。このエンジンは、異なるフォーマットのメッセージを共通のフォーマットに変換し、その後、共通のフォーマットは、ビジネスサービスアプリケーションによって処理される。パーサは、メッセージを調べ、受信したメッセージの特定のフォーマットに適切なスキーマを決定する。スキーマは、受信したフォーマット用の文法構造と、該文法構造(「文法」は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意・必須フィールド等を含むことができる)を用いて、メッセージの様々なフィールドを内部メッセージフォーマットに変換するためのハンドラへのポインタとを含む、スキーマレジストリ内のデータ構造である。ハンドラは、個々にコンパイルされる。
【解決手段】マルチフォーマットの財務メッセージを処理することができるパース/ビルドエンジン。このエンジンは、異なるフォーマットのメッセージを共通のフォーマットに変換し、その後、共通のフォーマットは、ビジネスサービスアプリケーションによって処理される。パーサは、メッセージを調べ、受信したメッセージの特定のフォーマットに適切なスキーマを決定する。スキーマは、受信したフォーマット用の文法構造と、該文法構造(「文法」は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意・必須フィールド等を含むことができる)を用いて、メッセージの様々なフィールドを内部メッセージフォーマットに変換するためのハンドラへのポインタとを含む、スキーマレジストリ内のデータ構造である。ハンドラは、個々にコンパイルされる。
【発明の詳細な説明】
【技術分野】
【0001】
(関連出願の引用)
本出願は、同時に出願された「ADAPTIVE FRONT END GATEWAY FOR SWITCHING TRANSACTIONS AND DATA ON UNRELIABLE NETWORKS USING CONTEXT−BASED RULES」と題する米国特許出願第_____号(代理人事件No.16222U−020200US)と関連し、該出願はあらゆる目的において参照により本明細書に引用される。
【0002】
本発明は、全体としてパース/ビルドエンジンに関し、より具体的には、マルチフォーマットのメッセージストリームを内部メッセージフォーマットに翻訳し、処理を施して、内部メッセージフォーマットをマルチフォーマットのメッセージストリームに逆翻訳することができ、翻訳することができるフォーマットをパース/ビルドエンジンに動的に追加することができる、高性能でなおかつ極めて柔軟なパース/ビルドエンジンに関する。
【背景技術】
【0003】
タスクを実行する際に、アプリケーションは、他の異種システムと通信する必要がある。これらの異種システムは、ホストアプリケーションの内部フォーマットとは異なるフォーマットのデータを用いているかもしれない。異なるデータフォーマットで受信した情報を処理できるためには、ホストアプリケーションは、外部データフォーマットをホストアプリケーション独自の内部データフォーマットにパースする必要があるかもしれない。その後、ホストアプリケーションは、パースされた情報を内部データフォーマットで処理することができる。その結果、ソフトウェアアプリケーションは、その後、該ソフトウェアアプリケーションによって用いられる内部データフォーマットとは異なるデータフォーマットのデータを処理する外部異種システムと効果的に通信することができる。
【0004】
通常、パース/ビルドエンジンは、上述のパースステップおよびビルドステップに用いられる。これらのエンジンは、一般に、インタプリタベースのパース/ビルドエンジンおよびコンパイル済みパース/ビルドエンジンの2種類のうちの1つである。
【発明の概要】
【発明が解決しようとする課題】
【0005】
インタプリタベースのパース/ビルドエンジンは、多数のデータフォーマットを処理することができる。インタプリタベースのパース/ビルドエンジンは、特定のメッセージのセットを翻訳するために用いられる、大型の文法辞書を含む。従って、多数のデータフォーマットを処理することができるが、この文法辞書の使用には非常に手間がかかることが多く、またこれを用いてメッセージを翻訳することによって性能が低下するため、性能が犠牲となる。インタプリタベースのパース/ビルドエンジンの別の欠点は、それらが文法辞書に含まれる特定のメッセージのセットしか翻訳できない点にある。追加の定義を文法辞書に加える必要がある場合、このエンジンは通常、新たな定義をこの文法辞書に対して用いるために、再コンパイルする必要がある。
【0006】
コンパイル済みパース/ビルドエンジンは、データフォーマットの固定セットに対して高性能となるようにカスタマイズされている。しかしながら、コンパイル済みパース/ビルドエンジンは、新たなデータフォーマットに動的に対応することができない。それらは、新たなビジネス要件に対応するのに必要となるかもしれない新たなデータフォーマットを組み込むのに、コード変更を必要とする。その後、コード変更を再コンパイルしなければならない。従って、コンパイル済みパース/ビルドエンジンは、新たなメッセージタイプを動的に処理する必要があり、また再コンパイルのために停止することができないシステムに対してはうまく適合しない。
【課題を解決するための手段】
【0007】
本発明は、マルチフォーマットのメッセージを処理することができるパース/ビルドエンジンを提供する。このエンジンは、異なるフォーマットのメッセージを共通のフォーマットに変換し、次いで、共通のフォーマットのメッセージが、ビジネスサービスアプリケーションによって処理される。共通のフォーマットは、本明細書において内部メッセージフォーマットと呼ばれる標準メッセージフォーマットである。パーサは、メッセージを調べ、受信したメッセージの特定のフォーマットに適切なスキーマを決定する。スキーマは、受信したフォーマットの文法構造と、該文法構造(「文法」は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意・必須フィールド、等を含むことができる)を用いて、メッセージの様々なフィールドを内部メッセージフォーマットに変換するためのハンドラへのポインタとを含む、スキーマレジストリ内のデータ構造である。ハンドラは、個々にコンパイルされる。従って、システム全体をコンパイルせずに、ハンドラが別個にコンパイルされ、エンジンの他の要素に支障を来たすことなく容易にアップグレードすることができるモジュラーシステムを保持しながら、コンパイルされたソフトウェアの速度を速めている。新たなスキーマおよびハンドラをロードすることにより、フォーマットが変化する際に、新たなフォーマットまたは旧フォーマットに対する変更を、パース/ビルドエンジンに動的に追加することができる。
【0008】
一実施形態では、パーサは、ISO8583財務メッセージのような、検出したメッセージのフォーマットに対応するルートスキーマをロードすることができる。ルートスキーマは、どのタイプのメッセージが受信されたか(例えば、承認メッセージ、調整メッセージ等)を判断するハンドラをポイントする。次いで、パーサが、特定されたメッセージタイプ用のスキーマをロードし、次いで、該スキーマが、特定の文法を提供し、当該のメッセージタイプ用のハンドラをポイントする。従って、全タイプの財務メッセージ用に全文法および全ハンドラをロードする必要がなく、実際に必要なサブセットのみをロードすればよく、その結果、必要メモリを抑え、性能を向上させる。さらに、各メッセージタイプ用に、実際に存在するフィールドに対してのみスキーマおよびハンドラがロードされ、呼び出される。これは、本発明のモジュール構造および反復アプローチによって可能となる。
【0009】
一実施形態では、実際に必要なスキーマ、文法、およびハンドラのみをロードすることに加え、本パース/ビルドエンジンは、内部メッセージフォーマットに対し、高速索引付けシステムを用いる。この索引付けシステムは、受信したフォーマットで用いられている各フィールドに対して、内部メッセージフォーマットの対応するフィールドを指し示す(をポイントする)、スキーマ内の符号化オブジェクトIDを用いる。用いられていない内部メッセージフォーマットのフィールドはポイントされず、従って、アクセスする必要はない。索引によって、階層構造内の数層下にあるフィールドをポイントすることができる。全フィールドを順次処理するのではなく、索引を用いることにより、速度の利点が提供される。
【0010】
一実施形態では、ビジネスサービスアプリケーションは、内部メッセージフォーマットのメッセージを処理する。処理の結果として、ビジネスサービスアプリケーションは、フィールドを更新または追加することができる(例えば、タイムスタンプ、リスクスコアの算出のような再処理タスク等)。変更されたメッセージは、次いで、パース動作の逆、ビルド動作を受ける。ビルド動作は、同様に、スキーマおよびハンドラを用いて、メッセージを、発信者へ返信するため、または処理のために別の宛先へ転送するための所望の外部フォーマットにビルドする。ビジネスサービスアプリケーションは、パースビルドエンジンから分離しており、従って、パースビルドエンジンに対する変更は、ビジネスサービスアプリケーションに影響を与えないで済む。
【0011】
本明細書に開示した本発明の性質および利点の更なる理解は、本明細書の残りの部分および添付の図面を参照することによって実現することができる。
本発明は、例えば、以下を提供する。
(項目1)
メッセージを内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信する工程と、
複数のハンドラを準備する工程であって、該ハンドラの各々が該フィールド用の文法を用いて該フィールドのうちの少なくとも1つをパースするためのコードであり、該ハンドラの各々が別個にコンパイルされる、工程と、
該メッセージの該フィールド用の1つ以上のスキーマを決定する工程であって、各スキーマが該ハンドラのうちの1つをポイントし、かつ1つ以上のフィールド用の文法定義を含む、工程と、
該ハンドラを用いて、該メッセージの該1つ以上のフィールドを該内部メッセージフォーマットに翻訳する工程と
を含む、方法。
(項目2)
上記内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含み、上記パーシングは、上記メッセージ内の上記フィールドに対してのみ行われ、該内部メッセージフォーマットの対応するフィールドのみが埋め込みされる、項目1に記載の方法。
(項目3)
上記スキーマ内に含まれる各メッセージフィールドは、上記内部メッセージフォーマット内の特定の場所をポイントする索引であるオブジェクトIDによって識別される、項目1に記載の方法。
(項目4)
他のスキーマおよびハンドラを再コンパイルすることなく、上記1つ以上のスキーマを動的にロードする工程をさらに含む、項目1に記載の方法。
(項目5)
上記翻訳から後続のスキーマを決定し、上記メッセージに対して、項目1の上記プロセスを、該後続のスキーマに対して反復する工程をさらに含む、項目1に記載の方法。
(項目6)
ビジネスサービスアプリケーションによって、上記内部メッセージフォーマットの上記メッセージを処理する工程をさらに含む、項目1に記載の方法。
(項目7)
上記ビジネスサービスアプリケーションによる上記処理は、上記フィールド内の値を変更する工程を含む、項目6に記載の方法。
(項目8)
上記処理後、上記内部メッセージフォーマットの上記メッセージを外部メッセージフォーマットにビルドするために、第2の1つ以上のスキーマのセットを決定する工程と、
該メッセージ内に含まれる上記1つ以上のフィールドに対応する該第2の1つ以上のスキーマのセットにおけるフィールド定義およびハンドラを決定する工程と、
該ハンドラを用いて、該外部メッセージフォーマットの1つ以上のフィールドをビルドする工程と
をさらに含む、項目7に記載の方法。
(項目9)
上記メッセージは、財務トランザクションを含む、項目1に記載の方法。
(項目10)
上記メッセージ内の上記1つ以上のフィールド以外の全ての必要なフィールドを決定する工程であって、該必要なフィールドは出力メッセージに必須である、工程と、
該必要なフィールドが決定された場合、該メッセージ内の該1つ以上のフィールド以外の該必要なフィールドを、該内部メッセージのオブジェクトに追加する工程とを
さらに含み、
該内部メッセージオブジェクトにおいて、該1つ以上のフィールドおよび該必要なフィールドだけが埋め込みされ内包されたフィールドである、項目1に記載の方法。
(項目11)
メッセージをパース/ビルドするように設定されているエンジンであって、該エンジンは、
複数のハンドラであって、各ハンドラがフィールド用の文法を用いて受信メッセージのフィールドのうちの少なくとも1つをパースするためのコードであり、該ハンドラの各々が別個にコンパイルされる、複数のハンドラと、
様々なタイプのメッセージ用の複数のスキーマであって、各スキーマが該ハンドラのうちの1つをポイントし、メッセージの1つ以上のフィールド用の文法定義を含む、複数のスキーマと
を備えている、エンジン。
(項目12)
内部メッセージフォーマットオブジェクトをさらに備え、上記ハンドラは、該内部メッセージフォーマットオブジェクトを、上記メッセージ内で見出されたフィールド、および/または必須フィールドについてだけ埋め込みするように設定されている、項目11に記載のエンジン。
(項目13)
上記内部メッセージフォーマットの上記メッセージを処理するように設定されたビジネスサービスモジュールをさらに備える、項目11に記載のエンジン。
(項目14)
上記エンジンは、上記内部メッセージフォーマットからメッセージをビルドするように設定されており、該エンジンは、
第2の1つ以上のスキーマのセットであって、該第2の1つ以上のスキーマのセットは、メッセージ内のフィールドを該内部メッセージフォーマットから外部メッセージフォーマットにパースするのに使用可能なフィールド定義を含む、第2の1つ以上のスキーマのセットと、
該第2のスキーマのセット用の1つ以上のハンドラであって、該ハンドラは、該第2のスキーマのセット内の該フィールド定義を用いて、該メッセージ内のフィールドを、該内部メッセージフォーマットから該外部メッセージフォーマットにパースするように設定された、該第2のスキーマのセット用の1つ以上のハンドラと
を備えている、項目13に記載のエンジン。
【図面の簡単な説明】
【0012】
【図1】図1は、本発明の一実施形態による、トランザクションを処理するシステムを示している。
【図2】図2は、本発明の一実施形態による、ゲートウェイのより詳細な実施形態を示している。
【図3】図3は、本発明の一実施形態による、トランザクションを処理する方法の略フローチャートを示している。
【図4】図4は、本発明の一実施形態による、トランザクション処理装置によって提示されるサービスに対する設定情報を生成するための略フローチャートを示している。
【図5】図5は、本発明の一実施形態による、サービスに加入する方法の略フローチャートを示している。
【図6】図6は、本発明の一実施形態による、複数のゲートウェイの分散化システムを示している。
【図7】図7は、本発明の一実施形態による、ゲートウェイをフロントエンドゲートウェイとして示すシステムを示している。
【図8】図8は、本発明の一実施形態による、ゲートウェイがインターネットゲートウェイであるシステムを示している。
【図9】図9は、本発明の一実施形態による、ゲートウェイが無線ゲートウェイとして用いられているシステムを示している。
【図10】図10は、本発明の一実施形態による、ISO8583トランザクションを処理するシステムを示している。
【図11】図11は、本発明の一実施形態による、メッセージをパースするシステムを示している。
【図12】図12は、本発明の実施形態による、ゲートウェイの一実施形態を開示している。
【図13A】図13Aは、本発明の一実施形態による、IMFオブジェクトに対する構造を示している。
【図13B】図13Bは、本発明の一実施形態による、メッセージ定義用属性を示している。
【図14A】図14A、図14B、および図14Cは、本発明の一実施形態による、あり得るメッセージ、オブジェクトIDコードを有する階層フォーマット、およびメッセージに対するIMFオブジェクトを示している。
【図14B】図14A、図14B、および図14Cは、本発明の一実施形態による、あり得るメッセージ、オブジェクトIDコードを有する階層フォーマット、およびメッセージに対するIMFオブジェクトを示している。
【図14C】図14A、図14B、および図14Cは、本発明の一実施形態による、あり得るメッセージ、オブジェクトIDコードを有する階層フォーマット、およびメッセージに対するIMFオブジェクトを示している。
【図15】図15は、本発明の一実施形態による、パースビルドエンジンを初期設定してメッセージストリームを処理する方法の略フローチャートを示している。
【図16】図16は、本発明の一実施形態による、パースビルドエンジン内にスキーマを動的に追加または更新する方法の略フローチャートを示している。
【図17】図17は、本発明の一実施形態による、入力メッセージをパースする方法の略フローチャートを示している。
【図18】図18は、本発明の一実施形態による、IMFオブジェクトからの出力メッセージをビルドする方法の略フローチャートを示している。
【発明を実施するための形態】
【0013】
本発明の実施形態は、メッセージのパース(parse)/ビルド(build)に関する。本発明の一実施形態によるパース/ビルドエンジンを組み込むことができるゲートウェイを最初に説明する。その後、このパース/ビルドエンジンをより詳細に説明する。
【0014】
(ゲートウェイ)
(処理の概要)
一実施形態では、トランザクションのインテリジェントな切り替えを提供する。トランザクションは、クレジットカード承認でも、デビットカードトランザクションでも、電子小切手トランザクションでもよい。トランザクションの他の例には、賞プログラムにおけるポイントまたは他の報酬の授与、Visa認証サービス用パスワードのチェック、送金の実行、Visa Buxxカードまたは給与カードのようなプリペイドカードからの支払金の引き落とし、携帯電話、ページャ、PDA等からの近接支払、健康保険、自動車保険、または他の保険等の補償範囲の判定が含まれる。クライアントは、トランザクションをゲートウェイに送信する。その後、ゲートウェイは、該トランザクションをサービスプロバイダのトランザクション処理装置へインテリジェントに切り替えるように設定される。クライアントは、POS、POS装置またはECR(電子式金銭登録機)にネットワーク接続している商人のコンピュータ、キオスク(例えばクーポンまたは送金に対する)、インターネットのウェブサイトサーバ等とすることができる。
【0015】
ゲートウェイは、アプリケーションレベルのトランザクションの内容、移送環境の現況、および/または動的ルールに基づいて、アプリケーションレベルで切り替え判断を行うように設定されている。アプリケーションレベルの内容は、トランザクションを処理する際にトランザクション処理装置によって処理または用いられる情報とすることができる。一実施形態では、情報は、OSI第7層の情報とすることができる。この層は、トランザクション処理装置またはエンドユーザに直接的に対応する。この層は、クレジットカード承認、デビットカードトランザクションアプリケーション等のようなアプリケーションを含む。例示的なアプリケーション層プロトコルは、FTP(ファイル転送プロトコル)、NFS(ネットワークファイルシステム)、CIFS(共通インターネットファイルシステム)、HTTP(ハイパーテキストトランスファープロトコル)、データベースクエリ、SQL(標準クエリ言語)、およびXML(拡張可能なマーク付け言語)である。例えばクレジットカード承認では、アプリケーションレベルの内容は、クレジットカード番号、個人アカウント番号(PAN)、顧客アカウント番号、トランザクションに対する合計金額等を含むことができる。トランザクション処理装置は、この情報を用いてトランザクションを処理することができる。
【0016】
移送環境の現況は、トランザクションを移送することができるネットワークおよび該トランザクションを処理することができるトランザクション処理装置と関連付けられた、リアルタイムの情報を含む。リアルタイムの情報は、ネットワークまたはトランザクション処理装置の調子、ネットワークまたはトランザクション処理装置の使用可能度、トランザクション処理装置のアプリケーション処理速度等を含むことができる。
【0017】
動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するために用いられる情報とすることができる。これらのルールは、アプリケーションレベルの内容および移送環境の現況に応じてトランザクションを切り替えるために用いられる。例えば、これらのルールは、特定のアプリケーションレベルの内容および移送環境の現況に応じて、サービスプロバイダによって提供される特定のサービスを選択すべきであると指定することができる。さらに、これらのルールは、サービスプロバイダがトランザクションを処理するためのトランザクション処理装置を選択するために用いることができる。例えば、特定の国は、国内のトランザクションに対する局所処理を必要とし、従って、地域の処理センタへのルーティングを必要とするかもしれない。これらのルールは、選択を行うための、ネットワークコスト、サービスコスト等のような静的情報を考慮することができる。これらのルールは、ゲートウェイを停止することなく、動的に変化することができる。
【0018】
ゲートウェイは、ルールに従って、トランザクションに対してサービスを行うこともできる。サービスは、アプリケーションレベルの内容の処理を含むことができる。例えば、トランザクション処理装置は、異なるフォーマットのトランザクションを処理するように設定することができる。選択されたトランザクション処理装置は、現在トランザクション中のアプリケーションレベルの内容と異なるフォーマットのアプリケーションレベルの内容を処理するように設定することができる。従って、ゲートウェイは、アプリケーションレベルの内容を新たなフォーマットに変更することができ、それにより、選択されたトランザクション処理装置は、それを処理することができる。従って、ゲートウェイは、トランザクション内の情報を、アプリケーションレベルで変更することができる。これは、パケットレベルで情報を見直すこととは異なる。通常、トランザクションは、パケットに分割することができる。ルータは、パケット内の情報を見て、該パケットをしかるべくルーティングすることはできる。しかしながら、パケットレベルで情報を見るので、ルータは、アプリケーションレベルの内容を用いてトランザクションに対するサービスを行うことはできない。例えば、トランザクション全体に関してアプリケーションレベルの内容を見ることによって、トランザクションに適切なサービスを適用し、トランザクションをインテリジェントにルーティングすることができる。トランザクションに関する情報を搬送する個々のパケットが個別に処理された場合には、全体としてのアプリケーションレベルの内容は処理されない。
【0019】
従って、アプリケーションレベルの内容、移送環境の現況、および/または動的ルールに基づいて、アプリケーションレベルでトランザクションをインテリジェントに切り替えるゲートウェイを提供する。ゲートウェイは、切り替え判断に基づいて適用されたサービスを提供することもできる。
【0020】
(システムの概要)
図1は、本発明の一実施形態によるトランザクションを処理するシステム100を示している。図に示すように、システム100は、1つ以上のクライアント102と、1つ以上のゲートウェイ104と、1つ以上のネットワーク106と、1つ以上のトランザクション処理装置108とを含む。以下の説明では、単一のゲートウェイ104に関して説明するが、多数のゲートウェイ104を備えて、以下に説明する全ての機能を実行できることを理解されたい。また、ゲートウェイをクライアントに隣接して示しているが、ゲートウェイは、トランザクション処理装置に隣接して、トランザクション処理装置とネットワーク106との間に配備することもできる。
【0021】
クライアント102は、トランザクションを送信するようになっている何らかのシステムを含む。例えば、クライアント102は、ユーザとトランザクションを行うコンピュータ処理装置のシステムを含むことができる。一例では、クライアント102は、クレジットカード承認、チェックカードトランザクション等に対して、クレジットカード情報、暗証番号、氏名等のようなユーザ情報を受信する店舗販売時点情報管理(POS)装置を含むことができる。クライアントはまた、ポイントまたはクーポンの情報をチェックするための店舗内キオスクであっても、送金のためのキオスクであっても、携帯電話または他の装置からの無線ユーザ入力を受信するためのノードであっても、ウェブサイトサーバ等であってもよい。クライアントはまた、POS装置をネットワークに接続している商人のサーバであってもよい。
【0022】
クライアント(例えばPOS装置)は、次いで、トランザクション処理装置108からのトランザクションサービスを要求するトランザクションを送信することができる。トランザクションサービスは、トランザクション処理装置108によって実行することができるどのような行為でもよい。一実施形態では、これらのトランザクションサービスは、クライアント102によって実行されているトランザクションに対して付加価値を付ける。トランザクションサービスの例には、クレジットカード承認、デビットカードトランザクション、電子小切手トランザクション等の促進が含まれる。トランザクションサービスは、トランザクションの処理、またはデータの交換を含むこともできる。
【0023】
ゲートウェイ104は、クライアント102からのトランザクションを受信し、ネットワーク106を経由して該トランザクションをトランザクション処理装置108にルーティングするように設定されたシステムを含む。一実施形態では、ゲートウェイ104は、ネットワーク106の縁部上に位置している。例えば、ゲートウェイ104は、クライアント102に対するアクセスポイントにあっても、クライアント102の構内にあってもよい。ネットワーク106の縁部は、ネットワーク106を経由してルーティングするようにトランザクションを設定することができる点である。例えば、ゲートウェイ104は、トランザクション処理装置108を選択し、次に、要求をネットワーク106のルータに送信することができる。トランザクションは、いくつかのパケットに分割することができる。次いで、ルータは、ネットワーク106を通じてトランザクションのために、パケットをトランザクション処理装置106にルーティングする。
【0024】
ネットワーク106は、データを転送するようになっているどのようなネットワークでもよい。例えば、ネットワーク106は、何らかのパケットベースのネットワーク、公衆交換電話網(PSTN)、無線ネットワーク、インターネット、民間金融ネットワーク等を含むことができる。
【0025】
一実施形態では、ネットワーク106は、異種および/または低信頼ネットワークであってもよい。これらのネットワークは、それらを、異なる事業体によって制御することができる点、異なるプロトコルおよびフォーマットを用いてデータをルーティングすることができる点、異なる転送方法を用いてデータをルーティングすることができる点等で異種である。例えば、ネットワーク106は、異なる事業体によって制御することができる。一例では、第1のインターネットサービスプロバイダ(ISP)は、ネットワーク106−1を保持することができ、第2のインターネットサービスプロバイダは、ネットワーク106−2を保持することができる。一実施形態では、トランザクションは、ネットワーク106−1またはネットワーク106−2を経由してルーティングすることができる。
【0026】
また、ネットワーク106は、異なる種類のものであってもよい。例えば、ネットワーク106−1は、データのパケットをルーティングする非同期転送モード(ATM)ネットワークであってもよい。別のネットワーク106−2は、無線でデータを伝送する無線ネットワークであってもよい。さらに、別のネットワーク106は、VisaNetネットワークのような、一事業体用のプライベートネットワークであってもよい。2つのネットワーク106のみを示しているが、さらに多くのネットワーク106を備えることができることを理解されたい。また、トランザクションは多数のネットワーク106を経由してルーティングすることができることを理解されたい。例えば、トランザクションは、ネットワーク106−1を、次いでネットワーク106−2を経由し、その後トランザクション処理装置108にルーティングすることができる。
【0027】
ネットワーク106はまた、低信頼ネットワークであってもよい。ネットワークの性質により、ネットワークは、いかなる時点においても、機能しなくなる可能性がある。従って、トランザクション処理における途絶を回避するために、フェイルオーバ処理が必要となる。
【0028】
サービスプロバイダは、クライアント102に提供することができるサービスを登録および公開することができる。クライアント102は、サービスに対して登録を行い、トランザクションをサービスプロバイダへ切り替えてもらうことができる。サービスプロバイダは、クライアント102にサービスを提供するように設定されたトランザクション処理装置108をいくつでも有することができる。一実施形態では、トランザクション処理装置108は、金融トランザクションを処理する。例えば、トランザクション処理装置108は、イシュア、アクワイアラ、商人、またはいずれかの他のサービスプロバイダと関連付けることができる。一例では、トランザクション処理装置108は、クレジットカードトランザクションの認証を促進する。
【0029】
サービスは、1つより多いトランザクション処理装置108によって提供することができる。例えば、サービスプロバイダは、クライアント102にサービスを提供することができる多くのデータセンタを有することができる。従って、サービスに対するトランザクションは、該サービスを提供することができるトランザクション処理装置108のうちのいずれかに切り替えればよい。トランザクション処理装置108は、全てが動的に変化している可能性がある、アプリケーションレベルの内容、移送環境に関する状況情報、および/または動的ルールに基づいて、ゲートウェイ104によって選択することができる。
【0030】
アプリケーションレベルのサービスは、動的に変化する可能性がある。利用可能なサービスは、修正、別のプロセッサへの移動があるかもしれず、メンテナンスまたは障害により利用不能となるかもしれない。
【0031】
移送環境に関する状況情報も、動的に変化している可能性がある。従って、ゲートウェイ104は、トランザクションを切り替える方法を決定する際に、移送環境に関する状況情報を判断する。例えば、ネットワーク106の調子の現況、ネットワーク106の可用性、トランザクション処理装置108の可用性、ネットワーク106を経由してデータが転送されている速度、ネットワーク106を経由してトランザクションを転送するコスト、トランザクションを処理するコスト、アプリケーションレベルでトランザクションを処理するのにアプリケーションが要する時間等が判断されるかもしれない。
【0032】
移送環境に関する状況情報を提供する動的情報に加え、特定の比較的静的な情報が判断されるかもしれない。例えば、静的情報は、トランザクションのコスト、トランザクション処理装置108がトランザクションを処理するのに必要なフォーマット等とすることができる。ゲートウェイ106は、トランザクションをルーティングする方法を決定する際に、動的情報および静的情報を用いることができる。
【0033】
動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するために用いられる情報とすることができる。これらのルールは、動的にロードされ得る。例えば、サービスプロバイダは、ゲートウェイ104上に動的にロードされる、サービスに対するルールを登録することができる。また、クライアントは、サービスおよびプロバイダのルールに加入して、クライアントのトランザクションをサービスプロバイダへ切り替えることができる。これらのルールも、ゲートウェイ104上に動的にロードすることができる。
【0034】
従って、ゲートウェイ104は、サービスに対して、トランザクションを処理することができるトランザクション処理装置108を動的に選択することができる。選択された処理装置108が、それを処理することができるようにトランザクションをフォーマット化するなど、選択されたトランザクション処理装置に特有のビジネスサービスも、トランザクション上で実行することができる。その後、トランザクションを、選択されたネットワーク106を経由して、選択されたトランザクション処理装置108へ送信することができる。トランザクション処理装置108および/またはネットワーク106を動的に選択することにより、ゲートウェイ104は、クライアント102を、トランザクション処理装置108および/またはネットワーク106のあらゆる障害から防護する。従って、これにより、極めて高度なサービス可用性が提供される。ゲートウェイ104は、トランザクション処理装置108に対してダウンタイムを生じさせるかもしれない、行う必要のあるあらゆる変更から、クライアント102を防護する。
【0035】
(ゲートウェイ104の概要)
図2は、本発明の一実施形態によるゲートウェイ104のより詳細な説明を示している。図に示すように、ゲートウェイ104は、1つ以上の要求ハンドラ202と、インバウンドメッセージストリームパーサ204と、セキュリティマネージャ206と、適応型ルートセレクタ208と、フローハンドラ210と、アウトバウンドメッセージストリームビルダ212と、メッセージディスパッチャ214と、コーディネータ216と、管理モジュール218と、設定ローダ220と、ルールデータベース222と、状況情報データベース224と、動的情報監視装置226とを含む。
【0036】
要求ハンドラ202は、クライアント102からトランザクションを受信するように設定されている。クライアント102は、トランザクションを、ハイパーテキストトランスファープロトコル(HTTP)、ファイル転送プロトコル(FTP)、拡張可能なマーク付け言語(XML)、ISO8583標準等のような、様々なプロトコルおよびフォーマットで送信することができる。要求ハンドラ202は、種々のプロトコルおよびフォーマットで送信されたトランザクション用のインタフェースとなり、トランザクションをインバウンドメッセージストリームパーサ204に供給する。例えば、ISOメッセージハンドラは、クライアント102からISO8583要求を受信し、それらをインバウンドメッセージストリームパーサ204に渡すように設定されている。また、XMLメッセージハンドラ、HTTP要求ハンドラ、ならびにFTP要求ハンドラは、XML、HTTP、およびFTPによるメッセージおよび/または要求を処理することができる。従って、要求ハンドラ202によって、ゲートウェイ104は、様々なプロトコルおよびフォーマットのメッセージを受信することができる。上述のフォーマットおよびプロトコルを記載しているが、当業者には、要求ハンドラ202によって処理することができる他のフォーマットおよびプロトコルがあることを理解されたい。
【0037】
インバウンドメッセージストリームパーサ204は、要求ハンドラ202からトランザクションを受信し、要求を標準形に変換するように設定されている。インバウンドメッセージストリームパーサ204は、様々なフォーマットのメッセージを受信し、それらの要求を、次にゲートウェイ104の他の構成要素によって処理することができる標準形に処理する。従って、多くの異なるフォーマットのトランザクション要求を、ゲートウェイ104によって処理することができる。インバウンドメッセージストリームパーサ204は、新たなフォーマットをゲートウェイ104によって処理して使用可能にすることができるという点で拡張可能な構造も提供する。新たなフォーマットが追加される場合、新たなフォーマットから標準形への翻訳が、インバウンドメッセージストリームプロセッサ104に追加される。従って、標準形が用いられるため、新たなフォーマットが追加される際に、ゲートウェイ104内の全ての構成要素を変更する必要はない。むしろ、インバウンドメッセージストリームパーサ204は、要求をゲートウェイ104の他の構成要素によって処理することができる標準形にパースするように設定されている。インバウンドメッセージストリームパーサ204のさらなる詳細は、以下に見出すことができる。
【0038】
セキュリティマネージャ206は、トランザクションに対してセキュリティ機能を提供するように設定されている。例えば、プラグ可能認証および認証、役割ベースアクセス制御(RBAC)、暗号化、ファイル保全等のようなセキュリティ機能を提供することができる。プラグ可能認証および認証機能は、認証および許可用の標準インタフェースとなり、従って、既存の方法に影響を及ぼすことなく、より新しい認証およびアクセス制御の方法を追加することが可能となる。当業者は、トランザクションに追加することができる他のセキュリティ機能が分かるであろう。
【0039】
適応型ルートセレクタ208は、ネットワーク106を経由して、トランザクションをトランザクション処理装置108に切り替えるように設定されている。適応型ルートセレクタ208は、アプリケーションレベルの内容、移送環境の現況、および/または動的ルールに基づいて、トランザクションを切り替える。
【0040】
適応型ルートセレクタ208は、ルールデータベース222内で見出したルール、および状況情報データベース224内で見出した動的状況情報を用いて、トランザクションをルーティングする。上に述べたように、状況情報は、状況情報データベース224に格納することができる。一実施形態では、状況情報は動的であってもよい。動的情報監視装置226は、状況情報を監視および判断する。次いで動的情報は、状況情報データベース224に格納される。状況情報の例には、ネットワーク106の可用性、トランザクション処理装置108の調子、1トランザクション当たりのコスト、アプリケーションレベルで全トランザクションを処理するためにアプリケーションに対して要する時間等が含まれる。一実施形態では、動的情報監視装置226は、トランザクションが受信される際に、ランタイムで動的状況情報を判断することができる。別の実施形態では、動的情報監視装置226は、ある時間間隔で動的状況情報を判断することができる。
【0041】
トランザクション処理装置108によって実行される各異なるサービスは、動的情報監視装置226によって実行することができるプローブを指定することができる。プローブが送信され、トランザクション処理装置108および/またはネットワーク106の状態に基づいて、情報の収集が可能となる。例えば、動的情報監視装置226は、ネットワークが利用可能であるかどうかを判断するために、ネットワークにテスト送信して応答を求めることができる。トランザクション処理装置108またはネットワーク106に対する応答が得られなかった場合、それは、利用不能と考えることができ、状態の情報は、状況情報データベース224に反映される。サービスに対する全てのトランザクション処理装置108に対して応答が得られなかった場合、同サービスは、利用不能と考えることができる。ゲートウェイ104は、この場合に同サービスを提供する別のサービスプロバイダを決定することができる。また、トランザクションを処理するためにトランザクション処理装置108上でアプリケーションに要する時間を測定することもできる。例えば、クレジットカード承認を許可するためにアプリケーションが要する時間が測定される。この測定値によって、トランザクションを切り替えるために用いることができるアプリケーションレベルの状況がもたらされる。
【0042】
ルールデータベース222は、トランザクションを処理するネットワーク106および処理装置108に加えて、トランザクションに対するサービスを決定するためのルールをも含む。ルールは、クライアントの基準も示すことができる。例えば、サービスが選択されるためには、特定の状況情報およびアプリケーションレベルの内容がルールを満たしている必要がある。クライアントは、トランザクションに対するサービスを選択するために用いることができるクライアント固有のルールを提供することができる。一例では、クライアント102のトランザクションが受信される際に、適応型ルートセレクタ208がクライアントの固有の選択ルールを判断し、該トランザクションに対応することができるサービスを決定することができる。同サービスを提供するサービスプロバイダへトランザクションを切り替えるために、トランザクションからアプリケーションレベルの内容が判断され、かつ/または状況情報データベース224から動的状況情報が判断される。アプリケーションレベルの内容および/または状況情報がルールに適用され、ルールに従ってトランザクションを処理することができるサービスプロバイダが決定される。例えば、コストのような特定の要因に基づいて、クライアント102は、最も安価なサービスを最初に選択するように、しかしながら、それを利用できない場合、2番目のより費用のかかるサービスを選択するように指定することができる。また、アカウント番号のようなアプリケーションレベルの内容に基づいて、トランザクションを特定のクレジットカードサービスに切り替えることができる。例えば、指定されたアカウント番号によって、クレジットまたはデビットカードを指示するか、または特定のポイントもしくは賞システムを適用する。他のアカウント番号またはフィールドは、送金またはパスワード確認(例えば、Visa認証サービス)のような、他のサービスの必要性を示すことができる。また、アプリケーションレベルの内容は、トランザクションを局所的に処理するか、または異なる国の処理ルーチン108に送信する必要があるかどうかを示す、クライアントの位置、およびいずれかの地域もしくは国ごとの規則を含むことができる。
【0043】
サービスは、サービスのルールを明記したサービス明細書も含むことができる。例えば、ルールは、トランザクションに要するメッセージフォーマット、サービスを提供するトランザクション処理装置108のネットワークアドレス、トランザクションをトランザクション処理装置108に切り替えるためのプリファレンス、サービスを得るのに適格であるアカウント番号の範囲等を特定することができる。以下により詳細に論じるように、これらのルールは、登録と同時にサービスプロバイダによって提供される。サービスプロバイダは、ルールをゲートウェイ104上に直接ロードすることができ、次いで、ゲートウェイ104が、該ルールを他の関与するゲートウェイに公開する。
【0044】
ルールは、トランザクションを処理することができるフローを指定することができる。フローは、トランザクション処理装置108に送信するためのトランザクションの処理を取り扱う。メッセージは、次いで、選択されたフローハンドラ210に送信される。トランザクション処理装置108およびネットワーク106が選択された後、フローハンドラ210は、トランザクションに対してビジネスサービスを実行することができる。例えば、異なるトランザクション処理装置108は、異なるフォーマットのトランザクションを処理し得る。フローハンドラ210は、選択されたトランザクション処理装置108に適切なフォーマットを決定し、該トランザクションを、同フォーマットにフォーマット化する。他のビジネスサービスには、通貨換算、保護必要フィールドの暗号化、特定の閾値を下回る取引額のクライアント側での代理処理等が含まれる。
【0045】
フローハンドラ210は、複数のフローを含むことができる。各フローが、一群のメッセージを処理する一組のビジネスサービスを取り扱う。各フローが、該フロー内の全てのビジネスサービスを調整するフローハンドラを含む。フロー内の一連のサービスは、設定ローダ220を用いてランタイムでロードすることができるフロー明細によって指定されている。フロー明細は、入力メッセージを処理する方法を確定する一連のサービスである。各サービスは、特定の機能を実行するソフトウェアアプリケーションコードである。新たなサービスおよびフロー明細は、ゲートウェイ104に動的にロードすることができる。
【0046】
フローハンドラ210がフロー内でトランザクションを処理した後、メッセージは、アウトバウンドメッセージストリームビルダ212に送信される。ビルダ212は、決定されたトランザクション処理装置108が要求するメッセージ形に基づいて、標準形からアウトバウンドメッセージをビルドするように設定されている。従って、ビルダ212は、標準メッセージフォーマットに基づいて、どのようなメッセージフォーマットも生成するように設定されている。アウトバウンドメッセージストリームビルダ212については、以下により詳細に説明する。
【0047】
メッセージディスパッチャ212は、トランザクションをトランザクション処理装置108に送信するように設定されている。ディスパッチャ214は、トランザクションが選択されたトランザクション処理装置108へ確実に到達するようにすることができる。ディスパッチャ214は、種々のトランザクション処理装置108への接続を管理し、接続に失敗したトランザクション処理装置108への再接続を試みることができ、またトランザクション処理装置108およびネットワーク106の状態を動的情報監視装置226に提供することもできる。一実施形態では、トランザクションをパケット化、すなわち、一連のパケットに分割して、ルータに送信することができる。ルータは、ネットワーク106を経由して、パケットをトランザクション処理装置108へルーティングすることができる。
【0048】
コーディネータ216は、ゲートウェイ104の処理を調整し、かつトランザクションが必ず適切に処理されるようにするために備えられている。また、コーディネータ216は、アプリケーション管理機能、ソフトウェア配布機能、システム監視機能、およびフェイルオーバ機能に対するサービスをゲートウェイ104に提供する。アプリケーション管理機能は、アプリケーションおよびサービスの開始ならびに停止に局所および遠隔で対応する。コーディネータ216はまた、新たなアプリケーションおよびサービスをゲートウェイ104に追加するのを可能にする。ソフトウェア配布機能は、ゲートウェイ104上にインストールすることになるソフトウェアの更新を有効にし、かつ必要な場合、繰り下げ更新への対応を含む。システム監視サービスは、メモリ、CPU、ネットワークインタフェース、および処理のようなシステム構成要素の主要パラメータを監視し、設定されたパラメータが閾値から逸脱した場合には、アラートを発生する。システム監視サービスはまた、それが処理の故障を検出した場合に、処理を再開始する。コーディネータ216は、ハートビートメカニズムを用いて(マルチゲートウェイクラスタ配備の場合)、ピアゲートウェイ104の調子も監視し、ピアゲートウェイ104が故障した場合に、ピアゲートウェイ104の処理負荷を引き受ける。
【0049】
(ルールの動的ロード)
サービスの新規登録後(以下に説明する)、ゲートウェイ104によって実行されるルールおよびビジネスサービスを動的に変更することができる。管理モジュール218および設定ローダ220は、ルールデータベース222およびフローハンドラ210に対する変更を動的にロードするように設定されている。
【0050】
設定ローダ220は、設定変更、ルーティングルール、新たなフロー明細等を、ランタイムでルールデータベース222内にロードするように設定されている。従って、設定ローダ220は、ルールデータベース222内のルーティングルールの動的再設定を可能にする。ルールベースは、ルールオブジェクトの多数のバージョンを保持しており、ルールベースの現行バージョンへの同期参照を有する。設定ローダ220が更新をルールベースにロードする前に、設定ローダ220は、アクティブルールベースのシャドウコピーを生成し、アクティブルールベースを改版する。次いで、更新される各オブジェクトに対し、設定ローダ220は、オブジェクトの新たなインスタンスを生成し、ルールベースの新版内の参照を更新する。全ての更新が完了した時点で、設定ローダ220は、ルールベースの新バージョンをポイントするように、参照を変更する。
【0051】
管理モジュール218は、管理行為を実行することを可能にするように設定されている。管理モジュール218は、1つ以上のゲートウェイ104を管理するために、ユーザの代理人が用いることができる。例えば、管理モジュール218は、おそらく、新たなルールをルールデータベース222内に定義するため、またはルーティングルールを動的に変更するために用いられる。また、管理モジュール218は、フローハンドラ210用の新たなフロー明細をロードおよびアンロードするため、ビジネスサービスを開始および停止するため、また設定をロードおよびアンロードするためにも用いることができる。次いで、設定ローダ220は、変更を実行するように設定される。
【0052】
サービスのモジュール化とフロー(例えば、上述のフローの説明を参照されたい)を介したメッセージ処理サービスのランタイム起動との組み合わせにより、本発明の実施形態の動的変更が可能となる。新たなトランザクションが適応型ルートセレクタ208によって受信されると、適応型ルートセレクタ208は、ルールベースの現行バージョンを読み取り、該ルールを適用して、適切なフローを選択する。フローハンドラ210は、トランザクションの全存続期間に対してフローの特定バージョンを用い、各フロー明細は、サービス、フロー、およびルールの特定のバージョンを参照する。従って、更新は既存のトランザクションによって現在用いられているバージョンではなく、異なるバージョンにおいて成立するので、フローハンドラ210および各フロー明細は、その時点で存在するトランザクションを妨害することなく更新することができる。
【0053】
(トランザクションの処理)
図3は、本発明の一実施形態によるトランザクションを処理する方法のフローチャート300を示している。ステップ302で、クライアント102からのトランザクションが受信される。トランザクションは、例えばクレジットカード承認、チェックカードトランザクション等のような、どのような種類のトランザクションでもよい。
【0054】
ステップ304で、トランザクションに対して、アプリケーションレベルの内容が判断される。上に述べたように、アプリケーションレベルの内容は、トランザクションを処理するために用いられる。例えば、アプリケーションレベルの内容は、クレジットカード番号、暗証番号、加盟銀行の名称(アクワイアラまたはイシュア)等かもしれない。アプリケーションレベルの内容は、全体として検討することができる。例えば、トランザクションがいくつかのパケットにパケット化されていた場合、アプリケーションレベルの内容は、多数のパケットのペイロード内で見つけることができる。この情報は、トランザクションのために、アプリケーションレベルの内容に再構築することができる。
【0055】
ステップ306で、移送環境の現況が判断される。例えば、サービスを提供することができるトランザクション処理装置の調子が判断される。さらに、トランザクションをルーティングすることができるネットワーク106に対するネットワークの調子も判断することができる。この情報は、移送環境の現況を提供するために、リアルタイムで判断することができる。
【0056】
ステップ308で、ルールがアプリケーションレベルの情報および/または移送環境の現況に適用され、サービスが決定される。例えば、特定のクライアント102は、特定のサービスと関連付けることができる。Visaのようなプロセッサのホストは、そのトランザクションが、Visaが所有するトランザクション処理装置に切り替えられることを所望するかもしれない。さらに、他のプロセッサのホストは、それらのトランザクションが、Vitalのような二次トランザクション処理装置に切り替えられることを所望するかもしれない。
【0057】
ステップ310で、サービスに対するトランザクションを切り替えるべきトランザクション処理装置および/またはネットワーク106を決定するために、ルールが提供される。この決定は、ルールに適用されたアプリケーションレベルの内容および/または移送環境の現況に基づいて判断することができる。例えば、トランザクションを処理するサービスが決定される。次いで、ネットワークの可用性に基づいて、適用可能なトランザクション処理装置108が決定される。
【0058】
また、サービスは、種々のトランザクション処理装置108およびネットワーク106と関連付けることもできる。例えば、クレジットカード承認は、指定されたトランザクション処理装置108に送信されるように設定することができる。さらに、チェックカードトランザクションは、第2の組のトランザクション処理装置108に送信するように設定することができる。これらのルールは、クライアントおよび/またはトランザクションサービスに対して決定される。
【0059】
ステップ312で、必要に応じて、アプリケーションレベルで、あらゆるビジネスサービスをトランザクションに対して実行することができる。例えば、トランザクションを、選択されたトランザクション処理装置108が要求するフォーマットにフォーマット化することも、アプリケーションレベルの何らかの情報をトランザクションに追加することも、何らかの他のビジネスサービスを実行することもできる。
【0060】
ステップ314で、トランザクションを、ネットワーク106を経由して、選択されたトランザクション処理装置108に切り替えることができる。
【0061】
代案として、別の実施形態では、ゲートウェイ104は、トランザクションをサービスプロバイダに切り替えることなく、トランザクションを処理するように設定されている。サービスプロバイダは、特定の基準が満たされればゲートウェイ104がトランザクションを処理することができると明記したルールを指定することができる。例えば、トランザクションが特定の額を下回る場合である。一例では、閾値額未満のクレジットカードトランザクションは、銀行に出向いて承認を求める必要がないばかりでなく、ネットワーク106を介してクレジットカード会社に連絡する必要もなく承認することができる。これは、トランザクションをネットワークの縁部で処理することができるので、多くの利点を提供する。これによって、ネットワークのボトルネックが排除され、分散処理システムが提供される。
【0062】
(サービスの生成および申し込み)
上に述べたように、ルールは、ルールデータベース222内に動的にロードすることができる。図4は、本発明の一実施形態による、トランザクション処理装置108によって提示されたサービスに対して、ゲートウェイ104内にルールをロードするための略フローチャート400を示している。ステップ402で、サービス生成要求が受信される。例えば、サービスプロバイダは、該サービスプロバイダが提示しているサービスを特定したサービス生成要求を送信することによって、サービスの登録を試みることができる。あるいは、トランザクション処理装置または他のサービスプロバイダと関連付けられたゲートウェイ104が、新たなサービスを動的に広告してもよく、クライアントと関連付けられたゲートウェイは、それらの新たなサービスに対する登録を開始するか否かを決定することができる。新たなサービスは、送金サービス、新たなポイントプログラム等であるかもしれない。
【0063】
ステップ404で、サービスに対するルールが受信される。例えば、ルールは、同サービスを処理することができるトランザクション処理装置108のアドレスを指定することができる。ネットワークアドレスは、IPアドレスでも、トランザクション処理装置108にトランザクションをルーティングするために用いることができる任意の他の識別子でもよい。さらに、要求をトランザクション処理装置108にルーティングするために用いることができるネットワーク106の情報も受信することができる。ルールは、サービスを利用するための基準を指定することもできる。例えば、受け入れられるために求められるフォーマットメッセージを指定する基準、サービスを利用するコスト(固定コストおよび1トランザクション当たりコストの両方)、サービスを利用するためのどのような他の基準も受信することができる。ルールは、サービスに対して、いずれの種類のカード、またはいずれの種類のアカウントもしくはアカウント番号範囲を適格とするかまたは登録するかを指定することができる。
【0064】
ステップ406で、設定ローダ220を用い、管理モジュール218によって、サービスに対するルールがルールデータベース222内に動的にロードされる。さらに、サービスに対するトランザクションを処理するために必要な全てのフロー明細をフローハンドラ202内にロードすることができる。
【0065】
従って、サービスが生成および公開された場合、クライアント108は、該サービスに加入することができる。図5は、本発明の一実施形態による、サービスに加入する方法の略フローチャート500を示している。ステップ502で、生成されたサービスへの加入要求がクライアント108から受信される。要求は、ウェブポータルまたは何らかの他の方法を通じて受信することができる。クライアント102は、ゲートウェイ104に直接コンタクトしアクセスを行うことができる。
【0066】
ステップ504で、サービスを利用するためのルールまたは基準に対する指定がクライアント108から受信される。この指定は、クライアント108から受信したトランザクションに対するサービスを選択するために必要な基準を含むことができる。基準は、クライアントに固有のものであっても、多くのクライアント108全体にわたって(例えば、ある事業体用の全てのPOS装置に対して)一定のものであってもよい。また、指定は、クライアント108が加入した各サービスの優先順位の形であってもよい。例えば、クライアントは、トランザクションに対して、第1のサービスが選択されること、しかしながら、そのサービスが稼働していない場合には、第2のサービスを選択すること等を指定することができる。基準は、より複雑であってもよく、ネットワークコスト、サービスコスト等を織り込んだ、より複雑なルールを含んでいてもよい。
【0067】
ステップ506で、サービス要求をルーティングするためのルールが生成される。これらのルールは、サービスが選択されるように、アプリケーションレベルの内容および/またはネットワーク移送環境の現況に基づいて、満たす必要のある基準を指定することができる。
【0068】
ステップ508で、これらのルールを、ルールデータベース222内に動的にロードすることができる。従って、サービスは、該サービスに加入するクライアント108に対して、直ちに利用可能とすることができる。
【0069】
ステップ510で、サービス用のフロー定義が生成される。フロー定義は、サービスに対応するように設定することができる。一実施形態では、サービス用のフロー定義は、すでに存在していてもよく、生成する必要がなくてもよい。しかしながら、特化されたビジネスサービスをクライアント108に対して実行する必要がある場合、新たなフロー定義を生成することができる。
【0070】
ステップ512で、ステップ510において生成されたフロー定義を、設定ローダ220によって、動的にロードすることができる。
【0071】
一実施形態では、ルールは、トランザクションが送信される前に、クライアント102から受信することができる。例えば、クライアント102は、サービスに加入して、該サービスを利用するためのルールを提供することができる。別の実施形態では、ルールは、トランザクション送信の直前または直後に送信することができる。例えば、クライアント102は、トランザクションの前または後に送信したメッセージにおいて、利用するためのルールを指定することができる。ルールは、その後、ゲートウェイ104上に動的にロードされる。これにより、クライアント102は、ゲートウェイ104をランタイムで動的に設定することが可能となる。
【0072】
(サービスに対するルールの分散化)
複数のゲートウェイ104をシステム内に配備することができる。各ゲートウェイ104は、それが接続されているクライアント102に、ゲートウェイ104独自のサービスを提供することができる。ゲートウェイ104は、ネットワークの縁部、クライアントのアクセスポイント、および、おそらくはクライアント102の物理的構内に配置することができる。一実施形態では、ゲートウェイ104は、ゲートウェイ104によって提示されるサービスに関する情報を格納しているだけである。異なるゲートウェイ104が、異なる一組のサービスに関する情報を有することができる。従って、サービスプロバイダによって登録されたかまたはクライアント102が加入した種々のサービスを提供するための情報は、全ゲートウェイ104の各々に分散することができるか、または分散化されている。情報の分散化のため、ゲートウェイ104は、情報の問い合わせを行うか、またはサービスに関する情報を提供するために、他のゲートウェイ104にコンタクトするように設定されている。
【0073】
図6は、本発明の一実施形態によるゲートウェイ104の分散化システムを表したシステム550を示している。図に示すように、複数のクライアント102およびゲートウェイ104が示されている。ゲートウェイ104は、1つ以上のネットワーク106の縁部上に配置されている。
【0074】
各ゲートウェイ104は、1つ以上のクライアント102に接続することができる。論述の目的で、ゲートウェイ104に接続された単一のクライアント102を示しているが、多くのクライアント102をゲートウェイ104に接続することができることを理解されたい。また、ゲートウェイ104はクライアント102の代わりにトランザクション処理装置108に接続してもよいことを理解されたい。
【0075】
ゲートウェイ104は、それがネットワーク106の縁部で接続されているクライアント102に対するトランザクションを処理するように設定されている。例えば、ゲートウェイ104−1は、クライアント102−1に対するトランザクションを処理するように設定され、ゲートウェイ104−2は、クライアント104−2に対するトランザクションを処理するように設定されている。ゲートウェイ104−1は、クライアント102−1に提示されたサービスに関する情報を格納し、また、クライアント102−1のプリファレンスに関する情報も格納する。他のゲートウェイ104およびクライアント102も同様である。
【0076】
ゲートウェイ104は、サービスに関する情報の分散を促進するために、他のゲートウェイ104に対するコンタクト情報を保持している。例えば、第1のゲートウェイ104が、現在第1のゲートウェイ104によって提示されていないサービスに関する情報を必要とする場合、第1のゲートウェイ104は、該サービスを提示する第2のゲートウェイ104にコンタクトを取り、該サービスに対するルールのような情報を、第1のゲートウェイ104に送信させることができる。別の実施形態では、第1のゲートウェイ104は、サービスに対するトランザクションを第2のゲートウェイ104に送信してもよく、そこで、第2のゲートウェイ104が、該トランザクションを処理することができる。この場合、第2のゲートウェイ104は、トランザクションをトランザクション処理装置108に切り替え、応答を受信し、次いで、該応答を第1のゲートウェイ104に返送することができる。
【0077】
コンタクト情報は、サービスに関する情報を他のゲートウェイ104に分散するために用いることもできる。例えばサービスプロバイダは、第1のゲートウェイ104上に、新たなサービスをアップロードすることができる。次いで、サービスに対するルールが他のゲートウェイ104に分散される。例えば、縁部でクライアント102に接続されたゲートウェイは、クライアント102がサービスに関心を有する場合、そのルールを送信される。クライアント102は、クライアント102独自のルールをアップロードすることもできる。
【0078】
各クライアントは、それが所望するサービスに対するルールのみをロードし、必要なメモリおよび更新を少なくすることができ、かつゲートウェイの処理速度を向上させることができる。例えば、ホテルのクライアントは、ポイントまたは賞のサービスを望むかもしれないが、送金サービスは望まないかもしれない。所望のサービスのみをロードすることにより、ホテルは、性能に影響を及ぼすことなく、ゲートウェイ上でより多くの情報を得ることができる。例えば、ポイントプログラム内にあるアカウント番号、またはアカウント番号の範囲は、ゲートウェイ上に格納することができ、従って、ユーザがポイントに対して適格であるかどうかを判断する処理を局所的に行うことができる。一方で、ウェブサイトクライアントは、Visa認証サービスにより関心があるかもしれない。同様に、カード会員が申し込んだか否か、またパスワードを有するか否かのようなVisa認証サービスに特有の情報およびルールを局所的に格納することができ、ユーザが加入者かどうかを決定するためにネットワークの外へ行く必要なくして、パスワードに対するプロンプティングを可能にする。いくつかの法人を有する多くのビジネスを行う特定の商人は、Visaビジネスカードにより関心があり、当該の特定の商人からの購入を承認されたパーチャスカードのアカウント番号の局所リストを望んでいるかもしれない。
【0079】
この方法で、クライアント102と被送信プロバイダは、ゲートウェイ104で直接対話し、サービスをロードまたは要求することができる。これは、ゲートウェイを当該クライアントのニーズに合わせることができるので、クライアント102にとってはおそらく有利であろう。さらに、ゲートウェイ104をクライアントの場所に保持することができるため、容易にかつ遅延なくゲートウェイ104にアクセスすることができる。
【0080】
従って、分散化された一組のサービスが、システム550によって提供される。中央処理装置を有するのではなく、処理は、ネットワークの縁部に分散される。これがボトルネックを排除し、かつフェイルオーバ保護を提供する。例えば、通常、中央処理装置を用い、それが故障した場合、システム全体のトランザクション処理に影響が及ぶ恐れがある。しかしながら、あるゲートウェイ104が故障しても、システム550全体に対する処理に支障はなく、トランザクションを他のゲートウェイ104に再送すればよい。
【0081】
(配備のシナリオ)
ゲートウェイ104は、多くの異なるシナリオで配備することができる。例えば、ゲートウェイ104は、プライベートネットワーク上のフロントエンドとして、インターネットゲートウェイとして、かつ/または無線ゲートウェイとして配備することができる。図7は、本発明の一実施形態による、フロントエンドゲートウェイとしてのゲートウェイ104を表したシステム600を示している。システム600は、異種ネットワーク106を跨いで、1つ以上のクライアント102を1つ以上のトランザクション処理装置108に接続する。トランザクション処理装置108は、クライアント102からのトランザクションを処理することができるどのようなシステムでもよい。例えば、Visa、MasterCard等は、クレジットカードトランザクションおよびデビットカードトランザクション用のトランザクションプロセッサを所有することができ、加盟銀行(アクワイアラ/イシュア)は、クライアント102であり得る。
【0082】
クライアントデータセンタ602は、クライアント102からのトランザクションを受信することができる。トランザクションは、クレジットカード承認でも、デビットカードトランザクションでもよい。データセンタは、例えば、クライアントのプライベートネットワークを介して多数のPOS装置に接続された中央コンピュータであってもよい。ゲートウェイ104は、トランザクションを処理し、該トランザクションを、トランザクション処理装置データセンタ108にインテリジェントに切り替える。例えば、トランザクションがVisaトランザクションである場合、トランザクション処理装置データセンタAおよびBをVisaと関連付けることができる。トランザクションがMasterCardである場合、処理装置データセンタCがMasterCardと関連付けられているため、処理装置データセンタCを選択することができる。
【0083】
ゲートウェイ104は、適切なトランザクション処理装置108、および該トランザクションをルーティングするネットワーク106を決定する。次いで、トランザクションがルータ604に送信され、次いでルータ604が、該トランザクションをルーティングすることができる。一実施形態では、ルータ604は、パケットを、ネットワーク106を経由して選択されたトランザクション処理装置108にルーティングすることができる。
【0084】
図8は、本発明の一実施形態による、ゲートウェイ104がインターネットゲートウェイであるシステム700を示している。インターネットクライアント702は、クライアント102を含む。クライアント102は、インターネット704を経由して、トランザクションをゲートウェイ104に送信することができる。ゲートウェイ104は、通常のクレジットカード承認、パスワード認証(Visa認証サービス)、賞またはポイント処理等のような、オンラインショッピングに必要な特定のサービス用に設定することができる。
【0085】
ゲートウェイ104は、クライアント102に対して、様々なトランザクション処理装置108への接続性を提供する。ゲートウェイ104は、HTTP要求および他のXMLベースの要求を受け入れることができる。アプリケーションレベルの内容および移送環境の現況に基づいて、サービスおよびトランザクション処理装置108を選択することができる。トランザクションは、HTTPまたは何らかの他のXMLベースの要求で送信しておくことができるので、ゲートウェイ104は、トランザクションを切り替える前に、メッセージを、トランザクション処理装置108が要求するフォーマットに翻訳することができる。例えば、トランザクション処理装置108は、メッセージがISO8583フォーマットに処理されていることを要求することができる。通常、POS装置がトランザクションを処理する場合は、トランザクションは、ISO8583フォーマットで送信することができる。しかしながら、トランザクションがインターネットゲートウェイによって処理される場合、インターネットクライアント702は、ISO8583メッセージを送信するように設定されていないことがある。従って、ゲートウェイ104は、トランザクション処理装置108によって要求されるISO8583フォーマットに、メッセージをフォーマット化するよう設定されている。
【0086】
一例では、ゲートウェイ104は、インターネットクライアント702からのインターネットトランザクションを処理することができる。インターネットクライアント702は、HTTP要求をゲートウェイ104に送信する。ゲートウェイ104は、HTTP要求を標準的な内部メッセージフォーマットに翻訳する。次いで、任意のビジネスサービスを、トランザクションに対して実行することができる。一例では、アプリケーションレベルのデータを、トランザクション処理装置108によって要求されるフォーマットに適合するように変更することができる。例えば、XMLトランザクションを、ISO8583フォーマットに変換することができる。次いで、ゲートウェイ104は、トランザクションをトランザクション処理装置108へインテリジェントに切り替える。
【0087】
トランザクション処理装置108は、トランザクションを処理して、応答をゲートウェイ104に返信する。この応答は、トランザクション処理装置に固有のフォーマットであってよい。次いで、ゲートウェイ104がHTTP応答をビルドして、それをインターネットクライアント702に送信する。従って、インターネットを経由したトランザクションを、ゲートウェイ104を用いて処理することができる。
【0088】
図9は、本発明の一実施形態による、ゲートウェイ104が無線ゲートウェイ104として用いられているシステム800を示している。ゲートウェイは、ユーザの携帯電話、PDA、ページャ等から無線メッセージを受信することができる。ゲートウェイ104は、無線アプリケーションプロトコル(WAP)、モバイル情報デバイスプロトコル(MIDP)、JQME等のような、異なる無線フォーマットに対応するように設定することができる。MIDletは、モバイル通信用地球規模システム(GSM)または汎用パケット無線サービス(GPRS)のようなネットワークを通じて、XMLフォーマットの要求を送信する。ゲートウェイ104は、インバウンド要求のペイロードを、標準的な内部メッセージフォーマットに変換することができる。次いで、内部メッセージフォーマット(IMF)を、ビジネスサービスによって処理することができる。アウトバウンドメッセージストリームビルダ212は、IMFを、トランザクション処理装置108に送信するための応答ペイロードに変換する。従って、無線トランザクションは、ゲートウェイ104によって処理することができる。
【0089】
ここで、無線トランザクションについて説明する。一実施形態では、無線クライアント808は、HTTP/GSM/GPRSを通じてXML要求を送信することにより、無線支払トランザクションを開始する。ゲートウェイ104は、XML要求を受信して、該要求を処理する前に、それを標準的な内部メッセージフォーマットに変換する。移送環境の現況に加え、トランザクション内のアプリケーションレベルの内容を用いて、トランザクションがトランザクション処理装置108に切り替えられる。選択されたトランザクション処理装置108に応じて、フローハンドラ210が、トランザクションに対してビジネスサービスを実行することができる。その後、トランザクションは、トランザクション処理装置108に送信される。
【0090】
トランザクション処理装置108は、クライアント銀行(またはイシュア)802を決定し、メッセージをイシュア802へルーティングする。イシュア802は、要求を処理して、応答をトランザクション処理装置108に返信する。次いで、トランザクション処理装置108は、応答(トランザクション処理装置固有のフォーマットで)をアクワイアラ804に返信する。ゲートウェイ104は、応答を受信し、それをXMLフォーマットに翻訳し、それを無線クライアント808に送信する。従って、ゲートウェイ804は、無線トランザクション支払をルーティングするように設定されている。
【0091】
図10は、本発明の一実施形態によるISO8583トランザクションを処理するシステム900を示している。図に示すように、イシュア銀行902およびアクワイアラ銀行904がトランザクションに関与している。アクワイアラ銀行904のクライアントコンピュータ102は、ISO8583要求をゲートウェイ104に送信する。ゲートウェイ104は、アプリケーションレベルの内容および移送環境の現況を用いてトランザクション処理装置108を選択し、要求を処理する。次いで、要求に対して何らかのビジネスサービスが実行された後、選択されたトランザクション処理装置108にメッセージが送信される。
【0092】
トランザクション処理装置108は、トランザクションを処理し、認証のために、該トランザクションを適切なイシュア902に切り替える。イシュアは、トランザクション処理装置108にISO8583を返送する。次いで、トランザクション処理装置108がゲートウェイ104に応答を送信し、次いで、応答がアクワイアラ銀行102のクライアント102に送信される。
【0093】
一例では、あるトランザクション処理装置108が利用不能となるかもしれない。この場合、例えば、プロセッサA、データセンタ01が利用不能となるかもしれない。これは、サービスに対するクライアント102の優先プロセッサであるかもしれない。その場合、ゲートウェイ104は、トランザクションを第2のプロセッサ、プロセッサA、データセンタ02に送信する。ゲートウェイ104は、主データセンタの可用性をチェックし続け、ひとたびそれが利用可能になれば、主データセンタへのメッセージのルーティングを開始することができる。トランザクションの再ルーティングは、クライアント102には見えない方法で行われる。従って、ゲートウェイ104のインテリジェント切り替え機能を用いて、いずれのトランザクション処理装置108のダウンタイムも回避される。
【0094】
別の実施形態では、プロセッサAのデータセンタが故障しているかもしれず、プロセッサBおよびCのような、他のプロセッサの他のデータセンタを使用する必要があるかもしれない。プロセッサBおよびCは、プロセッサAとは異なるフォーマットのトランザクションを処理するのかもしれない。この場合、ゲートウェイ104は、トランザクションのフォーマットを、プロセッサBまたはプロセッサCのフォーマットに相当するフォーマットに変換することができる。次いで、フォーマット化されたトランザクションが、プロセッサBまたはプロセッサCに送信される。結果的に、クライアント102には見えない方法で、異なるプロセッサを用いることができる。たとえプロセッサが異なるフォーマットを用いていても、ゲートウェイ104は、それでもそのフォーマットのトランザクションをルーティングするように設定されている。
【0095】
(メッセージのパース/ビルド)
(パースビルドエンジンの概要)
図11は、本発明の一実施形態によるメッセージをパースするシステム1000を示している。システム1000は、ISO8583メッセージのようなマルチフォーマットメッセージストリームを、内部メッセージフォーマット(IMF)と呼ばれる標準的なメッセージフォーマットにパースし、IMFから、ISO8583メッセージストリームのようなマルチフォーマットメッセージストリームをビルドする。財務メッセージストリームについて説明しているが、システム1000を用いて、どのようなマルチフォーマットメッセージストリームもパースおよびビルドすることができることを理解されたい。
【0096】
パース/ビルドエンジン1004は、図2のインバウンドメッセージストリームパーサ204およびアウトバウンドメッセージストリームビルダ212に相当する。図2に示す全ての構成要素を図11に示していないが、それらの構成要素もシステム1000に含めることができることを理解されたい。さらに、パース/ビルドエンジン1004はゲートウェイ104に含めることができるが、他の構成要素にも含めることができる。例えば、パース/ビルドエンジン1004は、他の異種システムとは異なるデータフォーマットのデータを処理するどのようなソフトウェアアプリケーションとも互換性を有することができる。
【0097】
パース/ビルドエンジン1004は、システム1006から入力メッセージストリーム1010を受信し、該メッセージを内部メッセージフォーマットにパースする。内部メッセージフォーマット(IMF)は、次いで、ゲートウェイ104に示すビジネスサービスアプリケーションのような他の構成要素によって処理することができる。ゲートウェイ104内の構成要素がIMFのメッセージを処理した後、パース/ビルドエンジン1004が、処理済のIMFから出力メッセージストリーム1012をビルドする。出力メッセージストリーム1012は、次いで、システム1008に送信されるか、または送信元システム1006に返信される。
【0098】
システム1006および1008は、メッセージ1010を送信し、かつ/またはパース/ビルドエンジン1004(またはゲートウェイ104)からメッセージ1012を受信するように設定されたどのようなシステムでもよい。一実施形態では、システム1006および1008は、店舗販売時点情報管理装置、スマートカード装置、トランザクション処理装置108、アクワイアラ、イシュア、サービスプロバイダ、トランザクションオーセンティケータ等のような、トランザクションを処理するように設定された何らかのシステムとすることができる。システム1006および1008は、ISO8583メッセージ、拡張可能なマーク付け言語(XML)、HTML等のような、多くの異なるフォーマットのメッセージを送信/受信することができる。入力メッセージストリームも、ASCII、EBCDIC、BCD、等のような、多数の符号化スキームのうちのいずれかとすることができ、数値、文字列、バイトアレイ等のような、異なるデータタイプを有することができる。
【0099】
図11のパース/ビルドエンジンは、スキーマテーブル1028を用いる。各スキーマは、受信したフォーマット用の文法構造、およびハンドラテーブル1030内のハンドラへのポインタを含む、メタデータを提供するデータ構造である。ハンドラは、メッセージ内の特定のフィールドに対応し、文法構造を用いて、メッセージの様々なフィールドを、内部メッセージフォーマットに変換する。ハンドラは、個々にコンパイルされるコードである。従って、システム全体をコンパイルせずに、ハンドラが別個にコンパイルされ、エンジンの他の要素に支障を来たすことなく容易にアップグレードすることができるモジュラーシステムを保持しながら、コンパイルされたソフトウェアの速度を速めている。
【0100】
パース/ビルドエンジン1004は、特定されたスキーマをロードし、該スキーマと関連付けられたハンドラの機能を呼び出す。次いで、ハンドラが、メッセージのフィールドをIMFオブジェクトにパースする。
【0101】
事前ロードされていないスキーマ、および関連付けられた全てのハンドラを、スキーマローダ1024を用いて、スキーマ定義ファイル1026から、スキーマテーブル1028およびハンドラテーブル1030内にロードすることができる。スキーマテーブル1026は、スキーマのname1、name2...,nameNのラベル付きの種々のスキーマを含む。パース/ビルドエンジン1004によってパースおよびビルドされ得る各メッセージに対し、対応するスキーマを提供することができる。各スキーマ名は、外部フォーマット内のメッセージストリームの「文法」、構成を定義するスキーマオブジェクトと関連付けられている。構成には、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意または必須の他のフィールドが含まれる。新たなスキーマおよびコンパイルされたハンドラがロードされ、パース/ビルドエンジン1004を再コンパイルすることなく、パース/ビルドエンジン1004によって用いられることができる。
【0102】
(パース/ビルドフロー)
ここで、フローの一例を説明する。図11に示すように、メッセージが受信されると、ビジネスサービスプログラムがパース/ビルドエンジン1004を呼び出す。メッセージ1010(ワイヤフォーマットのメッセージストリーム)がパース/ビルドエンジンに送信され、そこで、メッセージ1010は、最初にパーサ構成要素1016によって受信される。ビジネスサービスアプリケーションは、パーサ構成要素1016にスキーマ名1011も提供する。パーサ構成要素は、内部メッセージフォーマット(IMF)オブジェクトを生成する。オブジェクトの中には、一旦メッセージフィールドがIMFに翻訳されると、メッセージフィールドからの値が格納される。一実施形態では、パーサ構成要素1016は、メッセージ1010の起点を認識し、該起点から送信されたメッセージ1010に対して必要なスキーマを決定する。別の実施形態では、メッセージ1010内の情報をパースしてデータフォーマットを判断し、それにより、用いるべき対応するスキーマを決定することができる。さらに、メッセージ1010は、どのスキーマが当のデータフォーマットに対応するかを示すことができる。
【0103】
一例では、パーサ構成要素1016は、最初に、ISO8583財務メッセージのような、検出されたメッセージのフォーマットに対応するルートスキーマを調べる。そのようなISOメッセージは、どのフィールドが存在するかを特定するビットマップを冒頭に有している可能性がある。ルートスキーマは、ハンドラをポイントし、ハンドラが呼び出されて、タイプフィールドをパースし、何のタイプのメッセージが受信されたか(例えば、承認メッセージ、調整メッセージ等)を判定する。パーサ構成要素は、次いで、特定されたメッセージタイプに対するスキーマを調べ、次いで、スキーマが特定の文法を提供し、当該のメッセージタイプに対するハンドラをポイントする。スキーマおよびハンドラは、実際にメッセージ内に存在するフィールドに対してのみ調査および呼び出しが行われる。新たなフィールドが特定またはポイントされた際は、新たなスキーマを調べ、対応するハンドラを呼び出すことができる。特定のフィールドが1つ以上の条件を有する複合フィールドである可能性もあり、該条件の翻訳またはパーシングが、条件の結果によって、追加のスキーマおよび関連付けられたハンドラをポイントすることができる。
【0104】
IMFオブジェクト1018(以下により詳細に説明する)は、呼び出されたハンドラによって埋め込みされる。埋め込みされるフィールドは、入力メッセージに含まれるフィールドに対応するフィールドのみである。
【0105】
IMFオブジェクト1018は、次いで、ゲートウェイ104のビジネスソフトウェアアプリケーションによって処理される。処理された後、IMFオブジェクト1018は、アウトバウンドメッセージストリームに対するスキーマ名と共に、ビルド構成要素1020に送信される。処理済IMFオブジェクト1018の処理は異なるデータフォーマットで実行され得るので、ビルダ構成要素1020は、処理済のIMFオブジェクト1018から出力メッセージストリーム1012をビルドするように設定されている。上述の処理は、ビルダ構成要素1020がルートスキーマを調べ、何度も繰り返すことができる工程において、ポイントされたハンドラを呼び出して、タイプ情報をビルドしながら、逆順に反復される。呼び出されたハンドラは、IMFオブジェクト1018内で見出した値を、出力メッセージストリーム1012に含める必要のあるフィールドにビルドする。その後、出力メッセージストリーム1012を、出力メッセージストリーム1012を処理することができる、システム1008に送信することができる。
【0106】
図12に、IMFオブジェクト1018を用いて、ゲートウェイ104によって提供されるあらゆるサービスを実行するビジネスサービスアプリケーション1102を示す。ビジネスサービスアプリケーション1102は、IMFオブジェクト1018に対して動作する。動作には、イシュア銀行またはメッセージ送信先処理センタの判定のような、アプリケーション層ルーティングを含めることができる。さらに、サービスは、メッセージストリームのアプリケーションレベルのフォーマット化、ロギング、時刻表示、応答またはさらに別の処理に必要な新たなフィールドの生成等のように、メッセージに対して実行することもできる。ビジネスサービスアプリケーションは、イシュアまたは財務ネットワークに対する前処理を行うことも、負荷分担された局所処理を実行することもできる。例えば、$50未満の購入に対する許可メッセージを承認し、承認を求めて金融機関にメッセージを転送する必要なくして、応答メッセージを送信することができる。ビジネスサービスアプリケーション1102は、内部メッセージフォーマットのデータを処理するように設定されており、外部フォーマットに対してはそうではない。従って、ビジネスサービスアプリケーション1102は、メッセージをIMFにパースすることによって他のシステムで用いられているどのような外部フォーマットからも隔離されている。
【0107】
(IMFの構造)
図13Aは、本発明の一実施形態によるIMF1018用の構造を示している。図に示すように、IMF1018内にN個のフィールドが提供されている。これらのフィールドは、各フィールドが任意数の子フィールドも含むことができ、順に孫フィールド等を含むことができる、階層構造のフィールドのアレイとすることができる。例えば、フィールド1は、子フィールド1.1、1.2、 ...1.Nを含む。フィールド1.2、 ...1.Nも、任意数の子フィールド(図示せず)を含むことができる。メッセージがもし受信されたときは、実際に用いられるフィールドのみにデータが埋め込みされる。
【0108】
図14Bに、オブジェクトのIDコード(図13Aに示すフィールドに対するフィールド定義の索引)を有する階層フォーマットを示す。OIDは、IMFオブジェクト1018内の種々のフィールドに対する索引付けを可能にする。フィールド定義は、OIDを用いて、IMFオブジェクト1018内のフィールドに対してアクセスされる。一実施形態では、OIDは、図に示すドット数値表現によって表される8バイトの数である。第1のフィールドに対するOIDは、1.0.0として符号化されている。任意のサブフィールドは、1.1.0、1.2.0等々として符号化されている。第2のフィールドは、2.0.0として符号化され、任意のサブフィールドは、2.1.0、2.2.0等々として符号化されている。
【0109】
(スキーマの構造)
図13Bに、スキーマの一例を示す。スキーマのアドレスは、第1行、メッセージ定義(MessageDef)である。スキーマは、メッセージ内のフィールドの各々の文法とハンドラへのポインタとを含む。図示の例では、メッセージの第1のフィールドは、索引1.0.0を付けたField Definition Object(FieldDef)1202で識別されている。これは、OID属性1202とも呼ばれる。このフィールドに対する索引の後に続いているのは、呼び出し対象のハンドラ(HDR)の識別1204である。当該行の要素の残り部分は、当該の特定フィールドの文法定義である。これらのフィールド定義は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、必要なハンドラの名前等のような、そのフィールドの特性を説明している。フィールド定義は、ASCII、EBCDIC、BCD等のような異なる符号化方式で符号化されたフィールド、および数字、文字列、バイトアレイ等のような異なるデータタイプをパース/ビルドするために用いることができる。従って、マルチフォーマットメッセージストリームは、メッセージ定義を用いて処理することができる。一実施形態では、スキーマは、XMLスキーマの形のメタデータである。
【0110】
フィールド定義は、いくつかの属性を含むことができる。図13Bに示されている属性は網羅的ではないことが認識されるであろう。また当業者は、他の属性を用いてもよいことが分かるであろう。
【0111】
ハンドラ属性1204は、フィールドの名前である。必須/任意属性1206は、そのフィールドがメッセージ内で必須であるかまたは任意であるかを示している。第1のデータフォーマット属性1208は、外部フォーマット(ワイヤフォーマットとも呼ばれる)内で見出されたフィールドの値に対するデータフォーマットである。第2のデータフォーマット属性1210は、フィールドがIMFで格納され、ビジネスサービスによって処理される内部フォーマットである。
【0112】
カスタム/非カスタム属性1212は、フィールドのパーシングおよびビルディングに、フィールドがカスタムハンドラを用いるかまたは汎用ハンドラを用いるかを示している。
【0113】
7番目の属性1214は、メッセージのフィールド内の値を処理するために必要なハンドラの名前を示している。ハンドラは、受信メッセージの特定されたフィールド内の値を取り、それをIMFにパースする(パーサスキーマ用)か、またはIMFからの値を外部フォーマットにビルドする(ビルダスキーマ用)。
【0114】
8番目の属性1216は、フィールド内のサブフィールドの数を示している。
【0115】
(IMF(内部メッセージフォーマット)に用いられるメッセージフィールドの例)
図14Aは、いくつかの異なるフィールドのオブジェクトID(OID)、1.0.0、1.1.0、1.1.1、2.0.0、2.2.0、4.0.0、および4.1.0を含む、特定のメッセージオブジェクト1010に用いられるフィールドの一例を示している。これらは、図13Bのスキーマによってポイントされるフィールドである。従って、このメッセージ例では、図14Cに特定されたフィールドのみが、図13Aに示すメッセージオブジェクトに埋め込みされる。図14Bは、内部メッセージフォーマットの完全なフィールドのセットの全階層オブジェクトIDの一部を示している。図に見られるように、メッセージ1010は、これらのフィールドのうちの、メッセージ1010が必要とする部分のみを含んでいる。例えば、オブジェクトID1.2.0、3.0.0、および4.2.0は用いられていない。これらのフィールドは任意の数の子フィールドを有することができることに留意されたい。
【0116】
オブジェクトIDは、図13Aに示すメッセージオブジェクトの階層型内部メッセージフォーマットへの素早い索引付けシステムを提供する。この索引付けシステムは、受信したフォーマットに用いられている各フィールド用に、内部メッセージフォーマットの対応するフィールドに索引を付ける(ポイントする)、符号化オブジェクトID(1.0.0など)を用いる。この索引は、階層構造の数層下にあるフィールドを直接ポイントすることができる。
【0117】
ゲートウェイ104の構成要素がIMFオブジェクト1018を処理する際には、不要なフィールドの処理は実行されない。従って、処理速度が向上する。
【0118】
必須フィールドも、IMFオブジェクト1018に追加することができる。いくつかのフィールドは、ビジネスサービスモジュール1102またはトランザクション処理装置108には必須であるかもしれない。用いる必要のあるフィールドが受信メッセージ1010内に含まれていないと判断された場合、該フィールドは、ビジネスサービスモジュールによって埋め込みをし、再トランザクション用にビルドされることになるメッセージに含めることができる。このようにして、メッセージ1010内に含まれていない場合、図13Bのスキーマ内の「必須」フィールドをIMFオブジェクト1018に追加することができる。
【0119】
(パース/ビルドエンジンの初期設定)
図15は、ビジネスサービスアプリケーションのスタートアップと同時にパース/ビルドエンジン1004を初期設定する方法の略フローチャート1400を示している。ステップ1402で、初期設定要求がアプリケーションから受信される。この要求には、1つ以上のスキーマ定義ファイル1026の位置が含まれている。
【0120】
ステップ1404で、スキーマ定義ファイル1026内で見出されたスキーマが検証される。スキーマは、的確なタイプのデータが参照されていること、スキーマによって特定されたハンドラが実際に存在すること等の検証のような、いくつかの手順によって検証される。
【0121】
ステップ1406で、スキーマ定義ファイル1026内のスキーマが、レジストリ1022内に、スキーマローダ1024を用いて、ディスクまたは他のストレージリポジトリからDRAMメモリ内にロードされる。
【0122】
ステップ1408で、スキーマ内で指定された全てのハンドラが、レジストリ1022内にロードされる。例えば、メッセージ定義オブジェクト内のフィールド定義によって指定されたハンドラが、ハンドラテーブル1030内にロードされる。一実施形態では、ハンドラは、ハンドラの名前でキーボードから入力されたオブジェクトとして格納されている。
【0123】
ステップ1410で、ハンドラがそれぞれのメッセージ定義オブジェクトに結合される。例えば、メッセージ定義オブジェクト内のフィールド定義によって指定された全てのハンドラが、当該のメッセージ定義オブジェクトに結合される。
【0124】
これで、スキーマに対するパース/ビルドエンジン1004の初期設定が完了する。一実施形態では、パース/ビルドエンジン1004のコンパイルはでは必要ない。それは、フィールド値をパース/ビルドするために用いられるコンパイル済みハンドラを使用するからである。
【0125】
ランタイム中に、スキーマを動的に更新し、パース/ビルドエンジン1004に追加することができる。スキーマは、メッセージ定義オブジェクトを変更することによって更新してもよく、新たなメッセージ定義オブジェクトを付加することによって追加してもよい。新たなハンドラが必要な場合、それらも、コンパイル済みオブジェクトとして、パース/ビルドエンジン1004に動的に追加することができる。
【0126】
スキーマは、パース/ビルドエンジン1004を再コンパイルすることなく、かつそれを停止させることなく、追加することもできる。従って、パース/ビルドエンジン1004は、スキーマが更新される際でさえも、メッセージをパース/ビルドし続けることができる。
【0127】
(スキーマの追加または更新)
図16は、本発明の一実施形態による、パース/ビルドエンジン1004内のスキーマを動的に追加または更新する方法の略フローチャート1500を示している。ステップ1502で、スキーマを動的に追加または更新するようにとの要求がアプリケーションから受信される。この要求は、新たな、または更新されたスキーマを含む1つ以上のスキーマ定義ファイル1026の位置を含んでいる。
【0128】
ステップ1504で、スキーマ定義ファイル1026内で見出されたスキーマが検証される。
【0129】
ステップ1506で、スキーマ定義ファイル1026内のスキーマがレジストリ1022内にロードされる。更新されたスキーマに一組の新たなフィールド定義または変更されたフィールド定義が提供されている場合、新たな、または変更されたフィールド定義のみをレジストリ1022内にロードすればよい。スキーマを追加または更新している間、適切なデータ構造が更新をロックされ、処理中のインフライトメッセージがスキーマ変更の結果破壊されないことが確保される。スキーマローダ1024がスキーマの更新バージョンをロードする間、インフライトメッセージは、スキーマの前バージョンを使用し続ける。
【0130】
ステップ1508で、メッセージ定義オブジェクト内で指定された全てのハンドラが、レジストリ1022内にロードされる。パース/ビルドエンジン1004は、いずれかのハンドラがレジストリ1022内にすでに存在する場合、それらのハンドラをレジストリ1022内に再ロードしないように判断するために、チェックを行うことができる。しかしながら、いずれかのハンドラが変更されていた場合、該変更されたハンドラがロードされる。
【0131】
ステップ1510で、それぞれのメッセージ定義オブジェクトにハンドラが結合される。一実施形態では、新たな、または変更されたハンドラのみが、更新済みのメッセージ定義オブジェクトに結合される。これで、パース/ビルドエンジン1004の動的な更新が完了する。
【0132】
(パース工程のフローチャート)
図17は、本発明の一実施形態による、入力メッセージストリーム1010をパースする方法の略フローチャート1600を示している。ステップ1602で、メッセージ用のスキーマが決定される。そのスキーマは、入力メッセージストリーム1010を構成しているデータフォーマットに対応している。
【0133】
ステップ1604で、スキーマ内のポインタから、メッセージ定義オブジェクトに対する全てのハンドラが決定される。
【0134】
ステップ1606で、各フィールド用のハンドラがフィールドに添付される。
【0135】
ステップ1608で、ハンドラがメッセージの各フィールドを翻訳する。各フィールドに対して1つのハンドラが呼び出される。ハンドラは、スキーマ内のフィールド定義を用いて、フィールドの値をIMFに翻訳する。フィールドに対するOIDは、当該のフィールド用スキーマ内のフィールド定義をポイントし、かつIMFオブジェクト1018内の対応するフィールドもポイントする。
【0136】
一実施形態では、パーサ構成要素1016は、メッセージ1010内に読み込まれたフィールドに対するオフセットを保持する。例えば、読み込まれたバイト数は、オフセットとして格納される。パーサ構成要素は、各ハンドラが呼び出される度に、このオフセットの数を減らしてゆく。ハンドラがメッセージ1010の末尾に到達する(例えば、オフセットが特定の長さと等しくなる)か、またはメッセージ定義オブジェクト内の最後のフィールド定義に到達すると、パーサ構成要素は、翻訳が完了したことを認識する。
【0137】
ステップ1610で、翻訳されたフィールドが、IMFオブジェクト1018の対応する階層内に格納される。フィールドに対するOIDは、IMFオブジェクト1018内の階層内の対応する位置に、翻訳された値を格納するために用いることができる。
【0138】
上述の翻訳がいずれかの地点で失敗となった場合、エラーをゲートウェイ104に返すことができる。パーシングは続行することができ、IMFオブジェクト1018は返すことができる。しかしながら、IMFオブジェクト1018内に、エラーフラグを付けることができる。
【0139】
(ビルド工程のフローチャート)
ここで、図18に関して、ビルド工程を説明する。図18は、本発明の一実施形態による、IMFオブジェクト1018から出力メッセージストリーム1012をビルドする方法の略フローチャート1700を示している。ステップ1702で、スキーマ名およびIMFオブジェクト1018が決定される。一実施形態では、IMFオブジェクト1018が最初に決定される。スキーマ名は、IMFオブジェクト1018内の情報に基づいて決定することができる。例えば、スキーマ名は、IMFオブジェクト1018内の情報内に格納することができる。また、スキーマ名は、IMFオブジェクト1018内の情報を送ることになるチャネルまたは宛先システムによって決定してもよい。
【0140】
ステップ1704で、メッセージ定義オブジェクトを用いて、レジストリ1022内のスキーマをアドレス指定する。ステップ1706で、スキーマに対して必要なハンドラも全て決定される。
【0141】
ステップ1708で、IMFオブジェクト1018内で見出された各フィールドに対して、IMFオブジェクト1018内の階層内の対応するフィールドからの値がロードされる。フィールドに対するOIDを用いて、フィールド定義にアクセスする。
【0142】
ステップ1710で、フィールドに対するフィールド定義の属性に従って、IMFオブジェクト1018内のフィールドから、値が翻訳される。その結果、IMFフォーマット内で見出された値は、別のシステムと互換性を有するフォーマットに翻訳される。
【0143】
ステップ1712で、ビルドされた値が、生成された出力メッセージストリーム1012の対応するフィールド内に組み立てられる。
【0144】
IMFオブジェクト1018内のフィールドに対する値が、外部フォーマットに対して必須のフィールド用に見出されない場合、外部メッセージ内の当該のフィールドに対する値を空白に設定してもよく、生成されたメッセージが単にメッセージ内にこのフィールドを有していなくてもよい。さらに、IMFオブジェクト1018がこのフィールドを有していたはずであると判断された場合、IMFオブジェクト1018内にフィールドが見つからなかったことを示すエラーを返すことができる。
【0145】
(代案)
本発明は、ソフトウェアまたはハードウェア、もしくは両方を組み合わせたものにおける制御論理の形で実施することができる。この制御論理は、本発明の実施形態に開示した一組のステップを実行するよう情報処理装置を導くようになっている複数の命令として、情報記憶媒体に格納することができる。本明細書に提供される開示および教示に基づき、当業界の通常の技術者は、本発明を実施する他の手段および/または方法が分かるであろう。
【0146】
上述の説明は、例証となるものであるが、限定するものではない。本開示を検討すれば、当業者には、本発明の多くの変形形態が明らかとなるであろう。従って、本発明の範囲は、上述の説明を参照して決定されるのではなく、出願に係る請求項を参照して、包括的にあるいは均等物も加えて決定されるべきである。
【技術分野】
【0001】
(関連出願の引用)
本出願は、同時に出願された「ADAPTIVE FRONT END GATEWAY FOR SWITCHING TRANSACTIONS AND DATA ON UNRELIABLE NETWORKS USING CONTEXT−BASED RULES」と題する米国特許出願第_____号(代理人事件No.16222U−020200US)と関連し、該出願はあらゆる目的において参照により本明細書に引用される。
【0002】
本発明は、全体としてパース/ビルドエンジンに関し、より具体的には、マルチフォーマットのメッセージストリームを内部メッセージフォーマットに翻訳し、処理を施して、内部メッセージフォーマットをマルチフォーマットのメッセージストリームに逆翻訳することができ、翻訳することができるフォーマットをパース/ビルドエンジンに動的に追加することができる、高性能でなおかつ極めて柔軟なパース/ビルドエンジンに関する。
【背景技術】
【0003】
タスクを実行する際に、アプリケーションは、他の異種システムと通信する必要がある。これらの異種システムは、ホストアプリケーションの内部フォーマットとは異なるフォーマットのデータを用いているかもしれない。異なるデータフォーマットで受信した情報を処理できるためには、ホストアプリケーションは、外部データフォーマットをホストアプリケーション独自の内部データフォーマットにパースする必要があるかもしれない。その後、ホストアプリケーションは、パースされた情報を内部データフォーマットで処理することができる。その結果、ソフトウェアアプリケーションは、その後、該ソフトウェアアプリケーションによって用いられる内部データフォーマットとは異なるデータフォーマットのデータを処理する外部異種システムと効果的に通信することができる。
【0004】
通常、パース/ビルドエンジンは、上述のパースステップおよびビルドステップに用いられる。これらのエンジンは、一般に、インタプリタベースのパース/ビルドエンジンおよびコンパイル済みパース/ビルドエンジンの2種類のうちの1つである。
【発明の概要】
【発明が解決しようとする課題】
【0005】
インタプリタベースのパース/ビルドエンジンは、多数のデータフォーマットを処理することができる。インタプリタベースのパース/ビルドエンジンは、特定のメッセージのセットを翻訳するために用いられる、大型の文法辞書を含む。従って、多数のデータフォーマットを処理することができるが、この文法辞書の使用には非常に手間がかかることが多く、またこれを用いてメッセージを翻訳することによって性能が低下するため、性能が犠牲となる。インタプリタベースのパース/ビルドエンジンの別の欠点は、それらが文法辞書に含まれる特定のメッセージのセットしか翻訳できない点にある。追加の定義を文法辞書に加える必要がある場合、このエンジンは通常、新たな定義をこの文法辞書に対して用いるために、再コンパイルする必要がある。
【0006】
コンパイル済みパース/ビルドエンジンは、データフォーマットの固定セットに対して高性能となるようにカスタマイズされている。しかしながら、コンパイル済みパース/ビルドエンジンは、新たなデータフォーマットに動的に対応することができない。それらは、新たなビジネス要件に対応するのに必要となるかもしれない新たなデータフォーマットを組み込むのに、コード変更を必要とする。その後、コード変更を再コンパイルしなければならない。従って、コンパイル済みパース/ビルドエンジンは、新たなメッセージタイプを動的に処理する必要があり、また再コンパイルのために停止することができないシステムに対してはうまく適合しない。
【課題を解決するための手段】
【0007】
本発明は、マルチフォーマットのメッセージを処理することができるパース/ビルドエンジンを提供する。このエンジンは、異なるフォーマットのメッセージを共通のフォーマットに変換し、次いで、共通のフォーマットのメッセージが、ビジネスサービスアプリケーションによって処理される。共通のフォーマットは、本明細書において内部メッセージフォーマットと呼ばれる標準メッセージフォーマットである。パーサは、メッセージを調べ、受信したメッセージの特定のフォーマットに適切なスキーマを決定する。スキーマは、受信したフォーマットの文法構造と、該文法構造(「文法」は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意・必須フィールド、等を含むことができる)を用いて、メッセージの様々なフィールドを内部メッセージフォーマットに変換するためのハンドラへのポインタとを含む、スキーマレジストリ内のデータ構造である。ハンドラは、個々にコンパイルされる。従って、システム全体をコンパイルせずに、ハンドラが別個にコンパイルされ、エンジンの他の要素に支障を来たすことなく容易にアップグレードすることができるモジュラーシステムを保持しながら、コンパイルされたソフトウェアの速度を速めている。新たなスキーマおよびハンドラをロードすることにより、フォーマットが変化する際に、新たなフォーマットまたは旧フォーマットに対する変更を、パース/ビルドエンジンに動的に追加することができる。
【0008】
一実施形態では、パーサは、ISO8583財務メッセージのような、検出したメッセージのフォーマットに対応するルートスキーマをロードすることができる。ルートスキーマは、どのタイプのメッセージが受信されたか(例えば、承認メッセージ、調整メッセージ等)を判断するハンドラをポイントする。次いで、パーサが、特定されたメッセージタイプ用のスキーマをロードし、次いで、該スキーマが、特定の文法を提供し、当該のメッセージタイプ用のハンドラをポイントする。従って、全タイプの財務メッセージ用に全文法および全ハンドラをロードする必要がなく、実際に必要なサブセットのみをロードすればよく、その結果、必要メモリを抑え、性能を向上させる。さらに、各メッセージタイプ用に、実際に存在するフィールドに対してのみスキーマおよびハンドラがロードされ、呼び出される。これは、本発明のモジュール構造および反復アプローチによって可能となる。
【0009】
一実施形態では、実際に必要なスキーマ、文法、およびハンドラのみをロードすることに加え、本パース/ビルドエンジンは、内部メッセージフォーマットに対し、高速索引付けシステムを用いる。この索引付けシステムは、受信したフォーマットで用いられている各フィールドに対して、内部メッセージフォーマットの対応するフィールドを指し示す(をポイントする)、スキーマ内の符号化オブジェクトIDを用いる。用いられていない内部メッセージフォーマットのフィールドはポイントされず、従って、アクセスする必要はない。索引によって、階層構造内の数層下にあるフィールドをポイントすることができる。全フィールドを順次処理するのではなく、索引を用いることにより、速度の利点が提供される。
【0010】
一実施形態では、ビジネスサービスアプリケーションは、内部メッセージフォーマットのメッセージを処理する。処理の結果として、ビジネスサービスアプリケーションは、フィールドを更新または追加することができる(例えば、タイムスタンプ、リスクスコアの算出のような再処理タスク等)。変更されたメッセージは、次いで、パース動作の逆、ビルド動作を受ける。ビルド動作は、同様に、スキーマおよびハンドラを用いて、メッセージを、発信者へ返信するため、または処理のために別の宛先へ転送するための所望の外部フォーマットにビルドする。ビジネスサービスアプリケーションは、パースビルドエンジンから分離しており、従って、パースビルドエンジンに対する変更は、ビジネスサービスアプリケーションに影響を与えないで済む。
【0011】
本明細書に開示した本発明の性質および利点の更なる理解は、本明細書の残りの部分および添付の図面を参照することによって実現することができる。
本発明は、例えば、以下を提供する。
(項目1)
メッセージを内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信する工程と、
複数のハンドラを準備する工程であって、該ハンドラの各々が該フィールド用の文法を用いて該フィールドのうちの少なくとも1つをパースするためのコードであり、該ハンドラの各々が別個にコンパイルされる、工程と、
該メッセージの該フィールド用の1つ以上のスキーマを決定する工程であって、各スキーマが該ハンドラのうちの1つをポイントし、かつ1つ以上のフィールド用の文法定義を含む、工程と、
該ハンドラを用いて、該メッセージの該1つ以上のフィールドを該内部メッセージフォーマットに翻訳する工程と
を含む、方法。
(項目2)
上記内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含み、上記パーシングは、上記メッセージ内の上記フィールドに対してのみ行われ、該内部メッセージフォーマットの対応するフィールドのみが埋め込みされる、項目1に記載の方法。
(項目3)
上記スキーマ内に含まれる各メッセージフィールドは、上記内部メッセージフォーマット内の特定の場所をポイントする索引であるオブジェクトIDによって識別される、項目1に記載の方法。
(項目4)
他のスキーマおよびハンドラを再コンパイルすることなく、上記1つ以上のスキーマを動的にロードする工程をさらに含む、項目1に記載の方法。
(項目5)
上記翻訳から後続のスキーマを決定し、上記メッセージに対して、項目1の上記プロセスを、該後続のスキーマに対して反復する工程をさらに含む、項目1に記載の方法。
(項目6)
ビジネスサービスアプリケーションによって、上記内部メッセージフォーマットの上記メッセージを処理する工程をさらに含む、項目1に記載の方法。
(項目7)
上記ビジネスサービスアプリケーションによる上記処理は、上記フィールド内の値を変更する工程を含む、項目6に記載の方法。
(項目8)
上記処理後、上記内部メッセージフォーマットの上記メッセージを外部メッセージフォーマットにビルドするために、第2の1つ以上のスキーマのセットを決定する工程と、
該メッセージ内に含まれる上記1つ以上のフィールドに対応する該第2の1つ以上のスキーマのセットにおけるフィールド定義およびハンドラを決定する工程と、
該ハンドラを用いて、該外部メッセージフォーマットの1つ以上のフィールドをビルドする工程と
をさらに含む、項目7に記載の方法。
(項目9)
上記メッセージは、財務トランザクションを含む、項目1に記載の方法。
(項目10)
上記メッセージ内の上記1つ以上のフィールド以外の全ての必要なフィールドを決定する工程であって、該必要なフィールドは出力メッセージに必須である、工程と、
該必要なフィールドが決定された場合、該メッセージ内の該1つ以上のフィールド以外の該必要なフィールドを、該内部メッセージのオブジェクトに追加する工程とを
さらに含み、
該内部メッセージオブジェクトにおいて、該1つ以上のフィールドおよび該必要なフィールドだけが埋め込みされ内包されたフィールドである、項目1に記載の方法。
(項目11)
メッセージをパース/ビルドするように設定されているエンジンであって、該エンジンは、
複数のハンドラであって、各ハンドラがフィールド用の文法を用いて受信メッセージのフィールドのうちの少なくとも1つをパースするためのコードであり、該ハンドラの各々が別個にコンパイルされる、複数のハンドラと、
様々なタイプのメッセージ用の複数のスキーマであって、各スキーマが該ハンドラのうちの1つをポイントし、メッセージの1つ以上のフィールド用の文法定義を含む、複数のスキーマと
を備えている、エンジン。
(項目12)
内部メッセージフォーマットオブジェクトをさらに備え、上記ハンドラは、該内部メッセージフォーマットオブジェクトを、上記メッセージ内で見出されたフィールド、および/または必須フィールドについてだけ埋め込みするように設定されている、項目11に記載のエンジン。
(項目13)
上記内部メッセージフォーマットの上記メッセージを処理するように設定されたビジネスサービスモジュールをさらに備える、項目11に記載のエンジン。
(項目14)
上記エンジンは、上記内部メッセージフォーマットからメッセージをビルドするように設定されており、該エンジンは、
第2の1つ以上のスキーマのセットであって、該第2の1つ以上のスキーマのセットは、メッセージ内のフィールドを該内部メッセージフォーマットから外部メッセージフォーマットにパースするのに使用可能なフィールド定義を含む、第2の1つ以上のスキーマのセットと、
該第2のスキーマのセット用の1つ以上のハンドラであって、該ハンドラは、該第2のスキーマのセット内の該フィールド定義を用いて、該メッセージ内のフィールドを、該内部メッセージフォーマットから該外部メッセージフォーマットにパースするように設定された、該第2のスキーマのセット用の1つ以上のハンドラと
を備えている、項目13に記載のエンジン。
【図面の簡単な説明】
【0012】
【図1】図1は、本発明の一実施形態による、トランザクションを処理するシステムを示している。
【図2】図2は、本発明の一実施形態による、ゲートウェイのより詳細な実施形態を示している。
【図3】図3は、本発明の一実施形態による、トランザクションを処理する方法の略フローチャートを示している。
【図4】図4は、本発明の一実施形態による、トランザクション処理装置によって提示されるサービスに対する設定情報を生成するための略フローチャートを示している。
【図5】図5は、本発明の一実施形態による、サービスに加入する方法の略フローチャートを示している。
【図6】図6は、本発明の一実施形態による、複数のゲートウェイの分散化システムを示している。
【図7】図7は、本発明の一実施形態による、ゲートウェイをフロントエンドゲートウェイとして示すシステムを示している。
【図8】図8は、本発明の一実施形態による、ゲートウェイがインターネットゲートウェイであるシステムを示している。
【図9】図9は、本発明の一実施形態による、ゲートウェイが無線ゲートウェイとして用いられているシステムを示している。
【図10】図10は、本発明の一実施形態による、ISO8583トランザクションを処理するシステムを示している。
【図11】図11は、本発明の一実施形態による、メッセージをパースするシステムを示している。
【図12】図12は、本発明の実施形態による、ゲートウェイの一実施形態を開示している。
【図13A】図13Aは、本発明の一実施形態による、IMFオブジェクトに対する構造を示している。
【図13B】図13Bは、本発明の一実施形態による、メッセージ定義用属性を示している。
【図14A】図14A、図14B、および図14Cは、本発明の一実施形態による、あり得るメッセージ、オブジェクトIDコードを有する階層フォーマット、およびメッセージに対するIMFオブジェクトを示している。
【図14B】図14A、図14B、および図14Cは、本発明の一実施形態による、あり得るメッセージ、オブジェクトIDコードを有する階層フォーマット、およびメッセージに対するIMFオブジェクトを示している。
【図14C】図14A、図14B、および図14Cは、本発明の一実施形態による、あり得るメッセージ、オブジェクトIDコードを有する階層フォーマット、およびメッセージに対するIMFオブジェクトを示している。
【図15】図15は、本発明の一実施形態による、パースビルドエンジンを初期設定してメッセージストリームを処理する方法の略フローチャートを示している。
【図16】図16は、本発明の一実施形態による、パースビルドエンジン内にスキーマを動的に追加または更新する方法の略フローチャートを示している。
【図17】図17は、本発明の一実施形態による、入力メッセージをパースする方法の略フローチャートを示している。
【図18】図18は、本発明の一実施形態による、IMFオブジェクトからの出力メッセージをビルドする方法の略フローチャートを示している。
【発明を実施するための形態】
【0013】
本発明の実施形態は、メッセージのパース(parse)/ビルド(build)に関する。本発明の一実施形態によるパース/ビルドエンジンを組み込むことができるゲートウェイを最初に説明する。その後、このパース/ビルドエンジンをより詳細に説明する。
【0014】
(ゲートウェイ)
(処理の概要)
一実施形態では、トランザクションのインテリジェントな切り替えを提供する。トランザクションは、クレジットカード承認でも、デビットカードトランザクションでも、電子小切手トランザクションでもよい。トランザクションの他の例には、賞プログラムにおけるポイントまたは他の報酬の授与、Visa認証サービス用パスワードのチェック、送金の実行、Visa Buxxカードまたは給与カードのようなプリペイドカードからの支払金の引き落とし、携帯電話、ページャ、PDA等からの近接支払、健康保険、自動車保険、または他の保険等の補償範囲の判定が含まれる。クライアントは、トランザクションをゲートウェイに送信する。その後、ゲートウェイは、該トランザクションをサービスプロバイダのトランザクション処理装置へインテリジェントに切り替えるように設定される。クライアントは、POS、POS装置またはECR(電子式金銭登録機)にネットワーク接続している商人のコンピュータ、キオスク(例えばクーポンまたは送金に対する)、インターネットのウェブサイトサーバ等とすることができる。
【0015】
ゲートウェイは、アプリケーションレベルのトランザクションの内容、移送環境の現況、および/または動的ルールに基づいて、アプリケーションレベルで切り替え判断を行うように設定されている。アプリケーションレベルの内容は、トランザクションを処理する際にトランザクション処理装置によって処理または用いられる情報とすることができる。一実施形態では、情報は、OSI第7層の情報とすることができる。この層は、トランザクション処理装置またはエンドユーザに直接的に対応する。この層は、クレジットカード承認、デビットカードトランザクションアプリケーション等のようなアプリケーションを含む。例示的なアプリケーション層プロトコルは、FTP(ファイル転送プロトコル)、NFS(ネットワークファイルシステム)、CIFS(共通インターネットファイルシステム)、HTTP(ハイパーテキストトランスファープロトコル)、データベースクエリ、SQL(標準クエリ言語)、およびXML(拡張可能なマーク付け言語)である。例えばクレジットカード承認では、アプリケーションレベルの内容は、クレジットカード番号、個人アカウント番号(PAN)、顧客アカウント番号、トランザクションに対する合計金額等を含むことができる。トランザクション処理装置は、この情報を用いてトランザクションを処理することができる。
【0016】
移送環境の現況は、トランザクションを移送することができるネットワークおよび該トランザクションを処理することができるトランザクション処理装置と関連付けられた、リアルタイムの情報を含む。リアルタイムの情報は、ネットワークまたはトランザクション処理装置の調子、ネットワークまたはトランザクション処理装置の使用可能度、トランザクション処理装置のアプリケーション処理速度等を含むことができる。
【0017】
動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するために用いられる情報とすることができる。これらのルールは、アプリケーションレベルの内容および移送環境の現況に応じてトランザクションを切り替えるために用いられる。例えば、これらのルールは、特定のアプリケーションレベルの内容および移送環境の現況に応じて、サービスプロバイダによって提供される特定のサービスを選択すべきであると指定することができる。さらに、これらのルールは、サービスプロバイダがトランザクションを処理するためのトランザクション処理装置を選択するために用いることができる。例えば、特定の国は、国内のトランザクションに対する局所処理を必要とし、従って、地域の処理センタへのルーティングを必要とするかもしれない。これらのルールは、選択を行うための、ネットワークコスト、サービスコスト等のような静的情報を考慮することができる。これらのルールは、ゲートウェイを停止することなく、動的に変化することができる。
【0018】
ゲートウェイは、ルールに従って、トランザクションに対してサービスを行うこともできる。サービスは、アプリケーションレベルの内容の処理を含むことができる。例えば、トランザクション処理装置は、異なるフォーマットのトランザクションを処理するように設定することができる。選択されたトランザクション処理装置は、現在トランザクション中のアプリケーションレベルの内容と異なるフォーマットのアプリケーションレベルの内容を処理するように設定することができる。従って、ゲートウェイは、アプリケーションレベルの内容を新たなフォーマットに変更することができ、それにより、選択されたトランザクション処理装置は、それを処理することができる。従って、ゲートウェイは、トランザクション内の情報を、アプリケーションレベルで変更することができる。これは、パケットレベルで情報を見直すこととは異なる。通常、トランザクションは、パケットに分割することができる。ルータは、パケット内の情報を見て、該パケットをしかるべくルーティングすることはできる。しかしながら、パケットレベルで情報を見るので、ルータは、アプリケーションレベルの内容を用いてトランザクションに対するサービスを行うことはできない。例えば、トランザクション全体に関してアプリケーションレベルの内容を見ることによって、トランザクションに適切なサービスを適用し、トランザクションをインテリジェントにルーティングすることができる。トランザクションに関する情報を搬送する個々のパケットが個別に処理された場合には、全体としてのアプリケーションレベルの内容は処理されない。
【0019】
従って、アプリケーションレベルの内容、移送環境の現況、および/または動的ルールに基づいて、アプリケーションレベルでトランザクションをインテリジェントに切り替えるゲートウェイを提供する。ゲートウェイは、切り替え判断に基づいて適用されたサービスを提供することもできる。
【0020】
(システムの概要)
図1は、本発明の一実施形態によるトランザクションを処理するシステム100を示している。図に示すように、システム100は、1つ以上のクライアント102と、1つ以上のゲートウェイ104と、1つ以上のネットワーク106と、1つ以上のトランザクション処理装置108とを含む。以下の説明では、単一のゲートウェイ104に関して説明するが、多数のゲートウェイ104を備えて、以下に説明する全ての機能を実行できることを理解されたい。また、ゲートウェイをクライアントに隣接して示しているが、ゲートウェイは、トランザクション処理装置に隣接して、トランザクション処理装置とネットワーク106との間に配備することもできる。
【0021】
クライアント102は、トランザクションを送信するようになっている何らかのシステムを含む。例えば、クライアント102は、ユーザとトランザクションを行うコンピュータ処理装置のシステムを含むことができる。一例では、クライアント102は、クレジットカード承認、チェックカードトランザクション等に対して、クレジットカード情報、暗証番号、氏名等のようなユーザ情報を受信する店舗販売時点情報管理(POS)装置を含むことができる。クライアントはまた、ポイントまたはクーポンの情報をチェックするための店舗内キオスクであっても、送金のためのキオスクであっても、携帯電話または他の装置からの無線ユーザ入力を受信するためのノードであっても、ウェブサイトサーバ等であってもよい。クライアントはまた、POS装置をネットワークに接続している商人のサーバであってもよい。
【0022】
クライアント(例えばPOS装置)は、次いで、トランザクション処理装置108からのトランザクションサービスを要求するトランザクションを送信することができる。トランザクションサービスは、トランザクション処理装置108によって実行することができるどのような行為でもよい。一実施形態では、これらのトランザクションサービスは、クライアント102によって実行されているトランザクションに対して付加価値を付ける。トランザクションサービスの例には、クレジットカード承認、デビットカードトランザクション、電子小切手トランザクション等の促進が含まれる。トランザクションサービスは、トランザクションの処理、またはデータの交換を含むこともできる。
【0023】
ゲートウェイ104は、クライアント102からのトランザクションを受信し、ネットワーク106を経由して該トランザクションをトランザクション処理装置108にルーティングするように設定されたシステムを含む。一実施形態では、ゲートウェイ104は、ネットワーク106の縁部上に位置している。例えば、ゲートウェイ104は、クライアント102に対するアクセスポイントにあっても、クライアント102の構内にあってもよい。ネットワーク106の縁部は、ネットワーク106を経由してルーティングするようにトランザクションを設定することができる点である。例えば、ゲートウェイ104は、トランザクション処理装置108を選択し、次に、要求をネットワーク106のルータに送信することができる。トランザクションは、いくつかのパケットに分割することができる。次いで、ルータは、ネットワーク106を通じてトランザクションのために、パケットをトランザクション処理装置106にルーティングする。
【0024】
ネットワーク106は、データを転送するようになっているどのようなネットワークでもよい。例えば、ネットワーク106は、何らかのパケットベースのネットワーク、公衆交換電話網(PSTN)、無線ネットワーク、インターネット、民間金融ネットワーク等を含むことができる。
【0025】
一実施形態では、ネットワーク106は、異種および/または低信頼ネットワークであってもよい。これらのネットワークは、それらを、異なる事業体によって制御することができる点、異なるプロトコルおよびフォーマットを用いてデータをルーティングすることができる点、異なる転送方法を用いてデータをルーティングすることができる点等で異種である。例えば、ネットワーク106は、異なる事業体によって制御することができる。一例では、第1のインターネットサービスプロバイダ(ISP)は、ネットワーク106−1を保持することができ、第2のインターネットサービスプロバイダは、ネットワーク106−2を保持することができる。一実施形態では、トランザクションは、ネットワーク106−1またはネットワーク106−2を経由してルーティングすることができる。
【0026】
また、ネットワーク106は、異なる種類のものであってもよい。例えば、ネットワーク106−1は、データのパケットをルーティングする非同期転送モード(ATM)ネットワークであってもよい。別のネットワーク106−2は、無線でデータを伝送する無線ネットワークであってもよい。さらに、別のネットワーク106は、VisaNetネットワークのような、一事業体用のプライベートネットワークであってもよい。2つのネットワーク106のみを示しているが、さらに多くのネットワーク106を備えることができることを理解されたい。また、トランザクションは多数のネットワーク106を経由してルーティングすることができることを理解されたい。例えば、トランザクションは、ネットワーク106−1を、次いでネットワーク106−2を経由し、その後トランザクション処理装置108にルーティングすることができる。
【0027】
ネットワーク106はまた、低信頼ネットワークであってもよい。ネットワークの性質により、ネットワークは、いかなる時点においても、機能しなくなる可能性がある。従って、トランザクション処理における途絶を回避するために、フェイルオーバ処理が必要となる。
【0028】
サービスプロバイダは、クライアント102に提供することができるサービスを登録および公開することができる。クライアント102は、サービスに対して登録を行い、トランザクションをサービスプロバイダへ切り替えてもらうことができる。サービスプロバイダは、クライアント102にサービスを提供するように設定されたトランザクション処理装置108をいくつでも有することができる。一実施形態では、トランザクション処理装置108は、金融トランザクションを処理する。例えば、トランザクション処理装置108は、イシュア、アクワイアラ、商人、またはいずれかの他のサービスプロバイダと関連付けることができる。一例では、トランザクション処理装置108は、クレジットカードトランザクションの認証を促進する。
【0029】
サービスは、1つより多いトランザクション処理装置108によって提供することができる。例えば、サービスプロバイダは、クライアント102にサービスを提供することができる多くのデータセンタを有することができる。従って、サービスに対するトランザクションは、該サービスを提供することができるトランザクション処理装置108のうちのいずれかに切り替えればよい。トランザクション処理装置108は、全てが動的に変化している可能性がある、アプリケーションレベルの内容、移送環境に関する状況情報、および/または動的ルールに基づいて、ゲートウェイ104によって選択することができる。
【0030】
アプリケーションレベルのサービスは、動的に変化する可能性がある。利用可能なサービスは、修正、別のプロセッサへの移動があるかもしれず、メンテナンスまたは障害により利用不能となるかもしれない。
【0031】
移送環境に関する状況情報も、動的に変化している可能性がある。従って、ゲートウェイ104は、トランザクションを切り替える方法を決定する際に、移送環境に関する状況情報を判断する。例えば、ネットワーク106の調子の現況、ネットワーク106の可用性、トランザクション処理装置108の可用性、ネットワーク106を経由してデータが転送されている速度、ネットワーク106を経由してトランザクションを転送するコスト、トランザクションを処理するコスト、アプリケーションレベルでトランザクションを処理するのにアプリケーションが要する時間等が判断されるかもしれない。
【0032】
移送環境に関する状況情報を提供する動的情報に加え、特定の比較的静的な情報が判断されるかもしれない。例えば、静的情報は、トランザクションのコスト、トランザクション処理装置108がトランザクションを処理するのに必要なフォーマット等とすることができる。ゲートウェイ106は、トランザクションをルーティングする方法を決定する際に、動的情報および静的情報を用いることができる。
【0033】
動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するために用いられる情報とすることができる。これらのルールは、動的にロードされ得る。例えば、サービスプロバイダは、ゲートウェイ104上に動的にロードされる、サービスに対するルールを登録することができる。また、クライアントは、サービスおよびプロバイダのルールに加入して、クライアントのトランザクションをサービスプロバイダへ切り替えることができる。これらのルールも、ゲートウェイ104上に動的にロードすることができる。
【0034】
従って、ゲートウェイ104は、サービスに対して、トランザクションを処理することができるトランザクション処理装置108を動的に選択することができる。選択された処理装置108が、それを処理することができるようにトランザクションをフォーマット化するなど、選択されたトランザクション処理装置に特有のビジネスサービスも、トランザクション上で実行することができる。その後、トランザクションを、選択されたネットワーク106を経由して、選択されたトランザクション処理装置108へ送信することができる。トランザクション処理装置108および/またはネットワーク106を動的に選択することにより、ゲートウェイ104は、クライアント102を、トランザクション処理装置108および/またはネットワーク106のあらゆる障害から防護する。従って、これにより、極めて高度なサービス可用性が提供される。ゲートウェイ104は、トランザクション処理装置108に対してダウンタイムを生じさせるかもしれない、行う必要のあるあらゆる変更から、クライアント102を防護する。
【0035】
(ゲートウェイ104の概要)
図2は、本発明の一実施形態によるゲートウェイ104のより詳細な説明を示している。図に示すように、ゲートウェイ104は、1つ以上の要求ハンドラ202と、インバウンドメッセージストリームパーサ204と、セキュリティマネージャ206と、適応型ルートセレクタ208と、フローハンドラ210と、アウトバウンドメッセージストリームビルダ212と、メッセージディスパッチャ214と、コーディネータ216と、管理モジュール218と、設定ローダ220と、ルールデータベース222と、状況情報データベース224と、動的情報監視装置226とを含む。
【0036】
要求ハンドラ202は、クライアント102からトランザクションを受信するように設定されている。クライアント102は、トランザクションを、ハイパーテキストトランスファープロトコル(HTTP)、ファイル転送プロトコル(FTP)、拡張可能なマーク付け言語(XML)、ISO8583標準等のような、様々なプロトコルおよびフォーマットで送信することができる。要求ハンドラ202は、種々のプロトコルおよびフォーマットで送信されたトランザクション用のインタフェースとなり、トランザクションをインバウンドメッセージストリームパーサ204に供給する。例えば、ISOメッセージハンドラは、クライアント102からISO8583要求を受信し、それらをインバウンドメッセージストリームパーサ204に渡すように設定されている。また、XMLメッセージハンドラ、HTTP要求ハンドラ、ならびにFTP要求ハンドラは、XML、HTTP、およびFTPによるメッセージおよび/または要求を処理することができる。従って、要求ハンドラ202によって、ゲートウェイ104は、様々なプロトコルおよびフォーマットのメッセージを受信することができる。上述のフォーマットおよびプロトコルを記載しているが、当業者には、要求ハンドラ202によって処理することができる他のフォーマットおよびプロトコルがあることを理解されたい。
【0037】
インバウンドメッセージストリームパーサ204は、要求ハンドラ202からトランザクションを受信し、要求を標準形に変換するように設定されている。インバウンドメッセージストリームパーサ204は、様々なフォーマットのメッセージを受信し、それらの要求を、次にゲートウェイ104の他の構成要素によって処理することができる標準形に処理する。従って、多くの異なるフォーマットのトランザクション要求を、ゲートウェイ104によって処理することができる。インバウンドメッセージストリームパーサ204は、新たなフォーマットをゲートウェイ104によって処理して使用可能にすることができるという点で拡張可能な構造も提供する。新たなフォーマットが追加される場合、新たなフォーマットから標準形への翻訳が、インバウンドメッセージストリームプロセッサ104に追加される。従って、標準形が用いられるため、新たなフォーマットが追加される際に、ゲートウェイ104内の全ての構成要素を変更する必要はない。むしろ、インバウンドメッセージストリームパーサ204は、要求をゲートウェイ104の他の構成要素によって処理することができる標準形にパースするように設定されている。インバウンドメッセージストリームパーサ204のさらなる詳細は、以下に見出すことができる。
【0038】
セキュリティマネージャ206は、トランザクションに対してセキュリティ機能を提供するように設定されている。例えば、プラグ可能認証および認証、役割ベースアクセス制御(RBAC)、暗号化、ファイル保全等のようなセキュリティ機能を提供することができる。プラグ可能認証および認証機能は、認証および許可用の標準インタフェースとなり、従って、既存の方法に影響を及ぼすことなく、より新しい認証およびアクセス制御の方法を追加することが可能となる。当業者は、トランザクションに追加することができる他のセキュリティ機能が分かるであろう。
【0039】
適応型ルートセレクタ208は、ネットワーク106を経由して、トランザクションをトランザクション処理装置108に切り替えるように設定されている。適応型ルートセレクタ208は、アプリケーションレベルの内容、移送環境の現況、および/または動的ルールに基づいて、トランザクションを切り替える。
【0040】
適応型ルートセレクタ208は、ルールデータベース222内で見出したルール、および状況情報データベース224内で見出した動的状況情報を用いて、トランザクションをルーティングする。上に述べたように、状況情報は、状況情報データベース224に格納することができる。一実施形態では、状況情報は動的であってもよい。動的情報監視装置226は、状況情報を監視および判断する。次いで動的情報は、状況情報データベース224に格納される。状況情報の例には、ネットワーク106の可用性、トランザクション処理装置108の調子、1トランザクション当たりのコスト、アプリケーションレベルで全トランザクションを処理するためにアプリケーションに対して要する時間等が含まれる。一実施形態では、動的情報監視装置226は、トランザクションが受信される際に、ランタイムで動的状況情報を判断することができる。別の実施形態では、動的情報監視装置226は、ある時間間隔で動的状況情報を判断することができる。
【0041】
トランザクション処理装置108によって実行される各異なるサービスは、動的情報監視装置226によって実行することができるプローブを指定することができる。プローブが送信され、トランザクション処理装置108および/またはネットワーク106の状態に基づいて、情報の収集が可能となる。例えば、動的情報監視装置226は、ネットワークが利用可能であるかどうかを判断するために、ネットワークにテスト送信して応答を求めることができる。トランザクション処理装置108またはネットワーク106に対する応答が得られなかった場合、それは、利用不能と考えることができ、状態の情報は、状況情報データベース224に反映される。サービスに対する全てのトランザクション処理装置108に対して応答が得られなかった場合、同サービスは、利用不能と考えることができる。ゲートウェイ104は、この場合に同サービスを提供する別のサービスプロバイダを決定することができる。また、トランザクションを処理するためにトランザクション処理装置108上でアプリケーションに要する時間を測定することもできる。例えば、クレジットカード承認を許可するためにアプリケーションが要する時間が測定される。この測定値によって、トランザクションを切り替えるために用いることができるアプリケーションレベルの状況がもたらされる。
【0042】
ルールデータベース222は、トランザクションを処理するネットワーク106および処理装置108に加えて、トランザクションに対するサービスを決定するためのルールをも含む。ルールは、クライアントの基準も示すことができる。例えば、サービスが選択されるためには、特定の状況情報およびアプリケーションレベルの内容がルールを満たしている必要がある。クライアントは、トランザクションに対するサービスを選択するために用いることができるクライアント固有のルールを提供することができる。一例では、クライアント102のトランザクションが受信される際に、適応型ルートセレクタ208がクライアントの固有の選択ルールを判断し、該トランザクションに対応することができるサービスを決定することができる。同サービスを提供するサービスプロバイダへトランザクションを切り替えるために、トランザクションからアプリケーションレベルの内容が判断され、かつ/または状況情報データベース224から動的状況情報が判断される。アプリケーションレベルの内容および/または状況情報がルールに適用され、ルールに従ってトランザクションを処理することができるサービスプロバイダが決定される。例えば、コストのような特定の要因に基づいて、クライアント102は、最も安価なサービスを最初に選択するように、しかしながら、それを利用できない場合、2番目のより費用のかかるサービスを選択するように指定することができる。また、アカウント番号のようなアプリケーションレベルの内容に基づいて、トランザクションを特定のクレジットカードサービスに切り替えることができる。例えば、指定されたアカウント番号によって、クレジットまたはデビットカードを指示するか、または特定のポイントもしくは賞システムを適用する。他のアカウント番号またはフィールドは、送金またはパスワード確認(例えば、Visa認証サービス)のような、他のサービスの必要性を示すことができる。また、アプリケーションレベルの内容は、トランザクションを局所的に処理するか、または異なる国の処理ルーチン108に送信する必要があるかどうかを示す、クライアントの位置、およびいずれかの地域もしくは国ごとの規則を含むことができる。
【0043】
サービスは、サービスのルールを明記したサービス明細書も含むことができる。例えば、ルールは、トランザクションに要するメッセージフォーマット、サービスを提供するトランザクション処理装置108のネットワークアドレス、トランザクションをトランザクション処理装置108に切り替えるためのプリファレンス、サービスを得るのに適格であるアカウント番号の範囲等を特定することができる。以下により詳細に論じるように、これらのルールは、登録と同時にサービスプロバイダによって提供される。サービスプロバイダは、ルールをゲートウェイ104上に直接ロードすることができ、次いで、ゲートウェイ104が、該ルールを他の関与するゲートウェイに公開する。
【0044】
ルールは、トランザクションを処理することができるフローを指定することができる。フローは、トランザクション処理装置108に送信するためのトランザクションの処理を取り扱う。メッセージは、次いで、選択されたフローハンドラ210に送信される。トランザクション処理装置108およびネットワーク106が選択された後、フローハンドラ210は、トランザクションに対してビジネスサービスを実行することができる。例えば、異なるトランザクション処理装置108は、異なるフォーマットのトランザクションを処理し得る。フローハンドラ210は、選択されたトランザクション処理装置108に適切なフォーマットを決定し、該トランザクションを、同フォーマットにフォーマット化する。他のビジネスサービスには、通貨換算、保護必要フィールドの暗号化、特定の閾値を下回る取引額のクライアント側での代理処理等が含まれる。
【0045】
フローハンドラ210は、複数のフローを含むことができる。各フローが、一群のメッセージを処理する一組のビジネスサービスを取り扱う。各フローが、該フロー内の全てのビジネスサービスを調整するフローハンドラを含む。フロー内の一連のサービスは、設定ローダ220を用いてランタイムでロードすることができるフロー明細によって指定されている。フロー明細は、入力メッセージを処理する方法を確定する一連のサービスである。各サービスは、特定の機能を実行するソフトウェアアプリケーションコードである。新たなサービスおよびフロー明細は、ゲートウェイ104に動的にロードすることができる。
【0046】
フローハンドラ210がフロー内でトランザクションを処理した後、メッセージは、アウトバウンドメッセージストリームビルダ212に送信される。ビルダ212は、決定されたトランザクション処理装置108が要求するメッセージ形に基づいて、標準形からアウトバウンドメッセージをビルドするように設定されている。従って、ビルダ212は、標準メッセージフォーマットに基づいて、どのようなメッセージフォーマットも生成するように設定されている。アウトバウンドメッセージストリームビルダ212については、以下により詳細に説明する。
【0047】
メッセージディスパッチャ212は、トランザクションをトランザクション処理装置108に送信するように設定されている。ディスパッチャ214は、トランザクションが選択されたトランザクション処理装置108へ確実に到達するようにすることができる。ディスパッチャ214は、種々のトランザクション処理装置108への接続を管理し、接続に失敗したトランザクション処理装置108への再接続を試みることができ、またトランザクション処理装置108およびネットワーク106の状態を動的情報監視装置226に提供することもできる。一実施形態では、トランザクションをパケット化、すなわち、一連のパケットに分割して、ルータに送信することができる。ルータは、ネットワーク106を経由して、パケットをトランザクション処理装置108へルーティングすることができる。
【0048】
コーディネータ216は、ゲートウェイ104の処理を調整し、かつトランザクションが必ず適切に処理されるようにするために備えられている。また、コーディネータ216は、アプリケーション管理機能、ソフトウェア配布機能、システム監視機能、およびフェイルオーバ機能に対するサービスをゲートウェイ104に提供する。アプリケーション管理機能は、アプリケーションおよびサービスの開始ならびに停止に局所および遠隔で対応する。コーディネータ216はまた、新たなアプリケーションおよびサービスをゲートウェイ104に追加するのを可能にする。ソフトウェア配布機能は、ゲートウェイ104上にインストールすることになるソフトウェアの更新を有効にし、かつ必要な場合、繰り下げ更新への対応を含む。システム監視サービスは、メモリ、CPU、ネットワークインタフェース、および処理のようなシステム構成要素の主要パラメータを監視し、設定されたパラメータが閾値から逸脱した場合には、アラートを発生する。システム監視サービスはまた、それが処理の故障を検出した場合に、処理を再開始する。コーディネータ216は、ハートビートメカニズムを用いて(マルチゲートウェイクラスタ配備の場合)、ピアゲートウェイ104の調子も監視し、ピアゲートウェイ104が故障した場合に、ピアゲートウェイ104の処理負荷を引き受ける。
【0049】
(ルールの動的ロード)
サービスの新規登録後(以下に説明する)、ゲートウェイ104によって実行されるルールおよびビジネスサービスを動的に変更することができる。管理モジュール218および設定ローダ220は、ルールデータベース222およびフローハンドラ210に対する変更を動的にロードするように設定されている。
【0050】
設定ローダ220は、設定変更、ルーティングルール、新たなフロー明細等を、ランタイムでルールデータベース222内にロードするように設定されている。従って、設定ローダ220は、ルールデータベース222内のルーティングルールの動的再設定を可能にする。ルールベースは、ルールオブジェクトの多数のバージョンを保持しており、ルールベースの現行バージョンへの同期参照を有する。設定ローダ220が更新をルールベースにロードする前に、設定ローダ220は、アクティブルールベースのシャドウコピーを生成し、アクティブルールベースを改版する。次いで、更新される各オブジェクトに対し、設定ローダ220は、オブジェクトの新たなインスタンスを生成し、ルールベースの新版内の参照を更新する。全ての更新が完了した時点で、設定ローダ220は、ルールベースの新バージョンをポイントするように、参照を変更する。
【0051】
管理モジュール218は、管理行為を実行することを可能にするように設定されている。管理モジュール218は、1つ以上のゲートウェイ104を管理するために、ユーザの代理人が用いることができる。例えば、管理モジュール218は、おそらく、新たなルールをルールデータベース222内に定義するため、またはルーティングルールを動的に変更するために用いられる。また、管理モジュール218は、フローハンドラ210用の新たなフロー明細をロードおよびアンロードするため、ビジネスサービスを開始および停止するため、また設定をロードおよびアンロードするためにも用いることができる。次いで、設定ローダ220は、変更を実行するように設定される。
【0052】
サービスのモジュール化とフロー(例えば、上述のフローの説明を参照されたい)を介したメッセージ処理サービスのランタイム起動との組み合わせにより、本発明の実施形態の動的変更が可能となる。新たなトランザクションが適応型ルートセレクタ208によって受信されると、適応型ルートセレクタ208は、ルールベースの現行バージョンを読み取り、該ルールを適用して、適切なフローを選択する。フローハンドラ210は、トランザクションの全存続期間に対してフローの特定バージョンを用い、各フロー明細は、サービス、フロー、およびルールの特定のバージョンを参照する。従って、更新は既存のトランザクションによって現在用いられているバージョンではなく、異なるバージョンにおいて成立するので、フローハンドラ210および各フロー明細は、その時点で存在するトランザクションを妨害することなく更新することができる。
【0053】
(トランザクションの処理)
図3は、本発明の一実施形態によるトランザクションを処理する方法のフローチャート300を示している。ステップ302で、クライアント102からのトランザクションが受信される。トランザクションは、例えばクレジットカード承認、チェックカードトランザクション等のような、どのような種類のトランザクションでもよい。
【0054】
ステップ304で、トランザクションに対して、アプリケーションレベルの内容が判断される。上に述べたように、アプリケーションレベルの内容は、トランザクションを処理するために用いられる。例えば、アプリケーションレベルの内容は、クレジットカード番号、暗証番号、加盟銀行の名称(アクワイアラまたはイシュア)等かもしれない。アプリケーションレベルの内容は、全体として検討することができる。例えば、トランザクションがいくつかのパケットにパケット化されていた場合、アプリケーションレベルの内容は、多数のパケットのペイロード内で見つけることができる。この情報は、トランザクションのために、アプリケーションレベルの内容に再構築することができる。
【0055】
ステップ306で、移送環境の現況が判断される。例えば、サービスを提供することができるトランザクション処理装置の調子が判断される。さらに、トランザクションをルーティングすることができるネットワーク106に対するネットワークの調子も判断することができる。この情報は、移送環境の現況を提供するために、リアルタイムで判断することができる。
【0056】
ステップ308で、ルールがアプリケーションレベルの情報および/または移送環境の現況に適用され、サービスが決定される。例えば、特定のクライアント102は、特定のサービスと関連付けることができる。Visaのようなプロセッサのホストは、そのトランザクションが、Visaが所有するトランザクション処理装置に切り替えられることを所望するかもしれない。さらに、他のプロセッサのホストは、それらのトランザクションが、Vitalのような二次トランザクション処理装置に切り替えられることを所望するかもしれない。
【0057】
ステップ310で、サービスに対するトランザクションを切り替えるべきトランザクション処理装置および/またはネットワーク106を決定するために、ルールが提供される。この決定は、ルールに適用されたアプリケーションレベルの内容および/または移送環境の現況に基づいて判断することができる。例えば、トランザクションを処理するサービスが決定される。次いで、ネットワークの可用性に基づいて、適用可能なトランザクション処理装置108が決定される。
【0058】
また、サービスは、種々のトランザクション処理装置108およびネットワーク106と関連付けることもできる。例えば、クレジットカード承認は、指定されたトランザクション処理装置108に送信されるように設定することができる。さらに、チェックカードトランザクションは、第2の組のトランザクション処理装置108に送信するように設定することができる。これらのルールは、クライアントおよび/またはトランザクションサービスに対して決定される。
【0059】
ステップ312で、必要に応じて、アプリケーションレベルで、あらゆるビジネスサービスをトランザクションに対して実行することができる。例えば、トランザクションを、選択されたトランザクション処理装置108が要求するフォーマットにフォーマット化することも、アプリケーションレベルの何らかの情報をトランザクションに追加することも、何らかの他のビジネスサービスを実行することもできる。
【0060】
ステップ314で、トランザクションを、ネットワーク106を経由して、選択されたトランザクション処理装置108に切り替えることができる。
【0061】
代案として、別の実施形態では、ゲートウェイ104は、トランザクションをサービスプロバイダに切り替えることなく、トランザクションを処理するように設定されている。サービスプロバイダは、特定の基準が満たされればゲートウェイ104がトランザクションを処理することができると明記したルールを指定することができる。例えば、トランザクションが特定の額を下回る場合である。一例では、閾値額未満のクレジットカードトランザクションは、銀行に出向いて承認を求める必要がないばかりでなく、ネットワーク106を介してクレジットカード会社に連絡する必要もなく承認することができる。これは、トランザクションをネットワークの縁部で処理することができるので、多くの利点を提供する。これによって、ネットワークのボトルネックが排除され、分散処理システムが提供される。
【0062】
(サービスの生成および申し込み)
上に述べたように、ルールは、ルールデータベース222内に動的にロードすることができる。図4は、本発明の一実施形態による、トランザクション処理装置108によって提示されたサービスに対して、ゲートウェイ104内にルールをロードするための略フローチャート400を示している。ステップ402で、サービス生成要求が受信される。例えば、サービスプロバイダは、該サービスプロバイダが提示しているサービスを特定したサービス生成要求を送信することによって、サービスの登録を試みることができる。あるいは、トランザクション処理装置または他のサービスプロバイダと関連付けられたゲートウェイ104が、新たなサービスを動的に広告してもよく、クライアントと関連付けられたゲートウェイは、それらの新たなサービスに対する登録を開始するか否かを決定することができる。新たなサービスは、送金サービス、新たなポイントプログラム等であるかもしれない。
【0063】
ステップ404で、サービスに対するルールが受信される。例えば、ルールは、同サービスを処理することができるトランザクション処理装置108のアドレスを指定することができる。ネットワークアドレスは、IPアドレスでも、トランザクション処理装置108にトランザクションをルーティングするために用いることができる任意の他の識別子でもよい。さらに、要求をトランザクション処理装置108にルーティングするために用いることができるネットワーク106の情報も受信することができる。ルールは、サービスを利用するための基準を指定することもできる。例えば、受け入れられるために求められるフォーマットメッセージを指定する基準、サービスを利用するコスト(固定コストおよび1トランザクション当たりコストの両方)、サービスを利用するためのどのような他の基準も受信することができる。ルールは、サービスに対して、いずれの種類のカード、またはいずれの種類のアカウントもしくはアカウント番号範囲を適格とするかまたは登録するかを指定することができる。
【0064】
ステップ406で、設定ローダ220を用い、管理モジュール218によって、サービスに対するルールがルールデータベース222内に動的にロードされる。さらに、サービスに対するトランザクションを処理するために必要な全てのフロー明細をフローハンドラ202内にロードすることができる。
【0065】
従って、サービスが生成および公開された場合、クライアント108は、該サービスに加入することができる。図5は、本発明の一実施形態による、サービスに加入する方法の略フローチャート500を示している。ステップ502で、生成されたサービスへの加入要求がクライアント108から受信される。要求は、ウェブポータルまたは何らかの他の方法を通じて受信することができる。クライアント102は、ゲートウェイ104に直接コンタクトしアクセスを行うことができる。
【0066】
ステップ504で、サービスを利用するためのルールまたは基準に対する指定がクライアント108から受信される。この指定は、クライアント108から受信したトランザクションに対するサービスを選択するために必要な基準を含むことができる。基準は、クライアントに固有のものであっても、多くのクライアント108全体にわたって(例えば、ある事業体用の全てのPOS装置に対して)一定のものであってもよい。また、指定は、クライアント108が加入した各サービスの優先順位の形であってもよい。例えば、クライアントは、トランザクションに対して、第1のサービスが選択されること、しかしながら、そのサービスが稼働していない場合には、第2のサービスを選択すること等を指定することができる。基準は、より複雑であってもよく、ネットワークコスト、サービスコスト等を織り込んだ、より複雑なルールを含んでいてもよい。
【0067】
ステップ506で、サービス要求をルーティングするためのルールが生成される。これらのルールは、サービスが選択されるように、アプリケーションレベルの内容および/またはネットワーク移送環境の現況に基づいて、満たす必要のある基準を指定することができる。
【0068】
ステップ508で、これらのルールを、ルールデータベース222内に動的にロードすることができる。従って、サービスは、該サービスに加入するクライアント108に対して、直ちに利用可能とすることができる。
【0069】
ステップ510で、サービス用のフロー定義が生成される。フロー定義は、サービスに対応するように設定することができる。一実施形態では、サービス用のフロー定義は、すでに存在していてもよく、生成する必要がなくてもよい。しかしながら、特化されたビジネスサービスをクライアント108に対して実行する必要がある場合、新たなフロー定義を生成することができる。
【0070】
ステップ512で、ステップ510において生成されたフロー定義を、設定ローダ220によって、動的にロードすることができる。
【0071】
一実施形態では、ルールは、トランザクションが送信される前に、クライアント102から受信することができる。例えば、クライアント102は、サービスに加入して、該サービスを利用するためのルールを提供することができる。別の実施形態では、ルールは、トランザクション送信の直前または直後に送信することができる。例えば、クライアント102は、トランザクションの前または後に送信したメッセージにおいて、利用するためのルールを指定することができる。ルールは、その後、ゲートウェイ104上に動的にロードされる。これにより、クライアント102は、ゲートウェイ104をランタイムで動的に設定することが可能となる。
【0072】
(サービスに対するルールの分散化)
複数のゲートウェイ104をシステム内に配備することができる。各ゲートウェイ104は、それが接続されているクライアント102に、ゲートウェイ104独自のサービスを提供することができる。ゲートウェイ104は、ネットワークの縁部、クライアントのアクセスポイント、および、おそらくはクライアント102の物理的構内に配置することができる。一実施形態では、ゲートウェイ104は、ゲートウェイ104によって提示されるサービスに関する情報を格納しているだけである。異なるゲートウェイ104が、異なる一組のサービスに関する情報を有することができる。従って、サービスプロバイダによって登録されたかまたはクライアント102が加入した種々のサービスを提供するための情報は、全ゲートウェイ104の各々に分散することができるか、または分散化されている。情報の分散化のため、ゲートウェイ104は、情報の問い合わせを行うか、またはサービスに関する情報を提供するために、他のゲートウェイ104にコンタクトするように設定されている。
【0073】
図6は、本発明の一実施形態によるゲートウェイ104の分散化システムを表したシステム550を示している。図に示すように、複数のクライアント102およびゲートウェイ104が示されている。ゲートウェイ104は、1つ以上のネットワーク106の縁部上に配置されている。
【0074】
各ゲートウェイ104は、1つ以上のクライアント102に接続することができる。論述の目的で、ゲートウェイ104に接続された単一のクライアント102を示しているが、多くのクライアント102をゲートウェイ104に接続することができることを理解されたい。また、ゲートウェイ104はクライアント102の代わりにトランザクション処理装置108に接続してもよいことを理解されたい。
【0075】
ゲートウェイ104は、それがネットワーク106の縁部で接続されているクライアント102に対するトランザクションを処理するように設定されている。例えば、ゲートウェイ104−1は、クライアント102−1に対するトランザクションを処理するように設定され、ゲートウェイ104−2は、クライアント104−2に対するトランザクションを処理するように設定されている。ゲートウェイ104−1は、クライアント102−1に提示されたサービスに関する情報を格納し、また、クライアント102−1のプリファレンスに関する情報も格納する。他のゲートウェイ104およびクライアント102も同様である。
【0076】
ゲートウェイ104は、サービスに関する情報の分散を促進するために、他のゲートウェイ104に対するコンタクト情報を保持している。例えば、第1のゲートウェイ104が、現在第1のゲートウェイ104によって提示されていないサービスに関する情報を必要とする場合、第1のゲートウェイ104は、該サービスを提示する第2のゲートウェイ104にコンタクトを取り、該サービスに対するルールのような情報を、第1のゲートウェイ104に送信させることができる。別の実施形態では、第1のゲートウェイ104は、サービスに対するトランザクションを第2のゲートウェイ104に送信してもよく、そこで、第2のゲートウェイ104が、該トランザクションを処理することができる。この場合、第2のゲートウェイ104は、トランザクションをトランザクション処理装置108に切り替え、応答を受信し、次いで、該応答を第1のゲートウェイ104に返送することができる。
【0077】
コンタクト情報は、サービスに関する情報を他のゲートウェイ104に分散するために用いることもできる。例えばサービスプロバイダは、第1のゲートウェイ104上に、新たなサービスをアップロードすることができる。次いで、サービスに対するルールが他のゲートウェイ104に分散される。例えば、縁部でクライアント102に接続されたゲートウェイは、クライアント102がサービスに関心を有する場合、そのルールを送信される。クライアント102は、クライアント102独自のルールをアップロードすることもできる。
【0078】
各クライアントは、それが所望するサービスに対するルールのみをロードし、必要なメモリおよび更新を少なくすることができ、かつゲートウェイの処理速度を向上させることができる。例えば、ホテルのクライアントは、ポイントまたは賞のサービスを望むかもしれないが、送金サービスは望まないかもしれない。所望のサービスのみをロードすることにより、ホテルは、性能に影響を及ぼすことなく、ゲートウェイ上でより多くの情報を得ることができる。例えば、ポイントプログラム内にあるアカウント番号、またはアカウント番号の範囲は、ゲートウェイ上に格納することができ、従って、ユーザがポイントに対して適格であるかどうかを判断する処理を局所的に行うことができる。一方で、ウェブサイトクライアントは、Visa認証サービスにより関心があるかもしれない。同様に、カード会員が申し込んだか否か、またパスワードを有するか否かのようなVisa認証サービスに特有の情報およびルールを局所的に格納することができ、ユーザが加入者かどうかを決定するためにネットワークの外へ行く必要なくして、パスワードに対するプロンプティングを可能にする。いくつかの法人を有する多くのビジネスを行う特定の商人は、Visaビジネスカードにより関心があり、当該の特定の商人からの購入を承認されたパーチャスカードのアカウント番号の局所リストを望んでいるかもしれない。
【0079】
この方法で、クライアント102と被送信プロバイダは、ゲートウェイ104で直接対話し、サービスをロードまたは要求することができる。これは、ゲートウェイを当該クライアントのニーズに合わせることができるので、クライアント102にとってはおそらく有利であろう。さらに、ゲートウェイ104をクライアントの場所に保持することができるため、容易にかつ遅延なくゲートウェイ104にアクセスすることができる。
【0080】
従って、分散化された一組のサービスが、システム550によって提供される。中央処理装置を有するのではなく、処理は、ネットワークの縁部に分散される。これがボトルネックを排除し、かつフェイルオーバ保護を提供する。例えば、通常、中央処理装置を用い、それが故障した場合、システム全体のトランザクション処理に影響が及ぶ恐れがある。しかしながら、あるゲートウェイ104が故障しても、システム550全体に対する処理に支障はなく、トランザクションを他のゲートウェイ104に再送すればよい。
【0081】
(配備のシナリオ)
ゲートウェイ104は、多くの異なるシナリオで配備することができる。例えば、ゲートウェイ104は、プライベートネットワーク上のフロントエンドとして、インターネットゲートウェイとして、かつ/または無線ゲートウェイとして配備することができる。図7は、本発明の一実施形態による、フロントエンドゲートウェイとしてのゲートウェイ104を表したシステム600を示している。システム600は、異種ネットワーク106を跨いで、1つ以上のクライアント102を1つ以上のトランザクション処理装置108に接続する。トランザクション処理装置108は、クライアント102からのトランザクションを処理することができるどのようなシステムでもよい。例えば、Visa、MasterCard等は、クレジットカードトランザクションおよびデビットカードトランザクション用のトランザクションプロセッサを所有することができ、加盟銀行(アクワイアラ/イシュア)は、クライアント102であり得る。
【0082】
クライアントデータセンタ602は、クライアント102からのトランザクションを受信することができる。トランザクションは、クレジットカード承認でも、デビットカードトランザクションでもよい。データセンタは、例えば、クライアントのプライベートネットワークを介して多数のPOS装置に接続された中央コンピュータであってもよい。ゲートウェイ104は、トランザクションを処理し、該トランザクションを、トランザクション処理装置データセンタ108にインテリジェントに切り替える。例えば、トランザクションがVisaトランザクションである場合、トランザクション処理装置データセンタAおよびBをVisaと関連付けることができる。トランザクションがMasterCardである場合、処理装置データセンタCがMasterCardと関連付けられているため、処理装置データセンタCを選択することができる。
【0083】
ゲートウェイ104は、適切なトランザクション処理装置108、および該トランザクションをルーティングするネットワーク106を決定する。次いで、トランザクションがルータ604に送信され、次いでルータ604が、該トランザクションをルーティングすることができる。一実施形態では、ルータ604は、パケットを、ネットワーク106を経由して選択されたトランザクション処理装置108にルーティングすることができる。
【0084】
図8は、本発明の一実施形態による、ゲートウェイ104がインターネットゲートウェイであるシステム700を示している。インターネットクライアント702は、クライアント102を含む。クライアント102は、インターネット704を経由して、トランザクションをゲートウェイ104に送信することができる。ゲートウェイ104は、通常のクレジットカード承認、パスワード認証(Visa認証サービス)、賞またはポイント処理等のような、オンラインショッピングに必要な特定のサービス用に設定することができる。
【0085】
ゲートウェイ104は、クライアント102に対して、様々なトランザクション処理装置108への接続性を提供する。ゲートウェイ104は、HTTP要求および他のXMLベースの要求を受け入れることができる。アプリケーションレベルの内容および移送環境の現況に基づいて、サービスおよびトランザクション処理装置108を選択することができる。トランザクションは、HTTPまたは何らかの他のXMLベースの要求で送信しておくことができるので、ゲートウェイ104は、トランザクションを切り替える前に、メッセージを、トランザクション処理装置108が要求するフォーマットに翻訳することができる。例えば、トランザクション処理装置108は、メッセージがISO8583フォーマットに処理されていることを要求することができる。通常、POS装置がトランザクションを処理する場合は、トランザクションは、ISO8583フォーマットで送信することができる。しかしながら、トランザクションがインターネットゲートウェイによって処理される場合、インターネットクライアント702は、ISO8583メッセージを送信するように設定されていないことがある。従って、ゲートウェイ104は、トランザクション処理装置108によって要求されるISO8583フォーマットに、メッセージをフォーマット化するよう設定されている。
【0086】
一例では、ゲートウェイ104は、インターネットクライアント702からのインターネットトランザクションを処理することができる。インターネットクライアント702は、HTTP要求をゲートウェイ104に送信する。ゲートウェイ104は、HTTP要求を標準的な内部メッセージフォーマットに翻訳する。次いで、任意のビジネスサービスを、トランザクションに対して実行することができる。一例では、アプリケーションレベルのデータを、トランザクション処理装置108によって要求されるフォーマットに適合するように変更することができる。例えば、XMLトランザクションを、ISO8583フォーマットに変換することができる。次いで、ゲートウェイ104は、トランザクションをトランザクション処理装置108へインテリジェントに切り替える。
【0087】
トランザクション処理装置108は、トランザクションを処理して、応答をゲートウェイ104に返信する。この応答は、トランザクション処理装置に固有のフォーマットであってよい。次いで、ゲートウェイ104がHTTP応答をビルドして、それをインターネットクライアント702に送信する。従って、インターネットを経由したトランザクションを、ゲートウェイ104を用いて処理することができる。
【0088】
図9は、本発明の一実施形態による、ゲートウェイ104が無線ゲートウェイ104として用いられているシステム800を示している。ゲートウェイは、ユーザの携帯電話、PDA、ページャ等から無線メッセージを受信することができる。ゲートウェイ104は、無線アプリケーションプロトコル(WAP)、モバイル情報デバイスプロトコル(MIDP)、JQME等のような、異なる無線フォーマットに対応するように設定することができる。MIDletは、モバイル通信用地球規模システム(GSM)または汎用パケット無線サービス(GPRS)のようなネットワークを通じて、XMLフォーマットの要求を送信する。ゲートウェイ104は、インバウンド要求のペイロードを、標準的な内部メッセージフォーマットに変換することができる。次いで、内部メッセージフォーマット(IMF)を、ビジネスサービスによって処理することができる。アウトバウンドメッセージストリームビルダ212は、IMFを、トランザクション処理装置108に送信するための応答ペイロードに変換する。従って、無線トランザクションは、ゲートウェイ104によって処理することができる。
【0089】
ここで、無線トランザクションについて説明する。一実施形態では、無線クライアント808は、HTTP/GSM/GPRSを通じてXML要求を送信することにより、無線支払トランザクションを開始する。ゲートウェイ104は、XML要求を受信して、該要求を処理する前に、それを標準的な内部メッセージフォーマットに変換する。移送環境の現況に加え、トランザクション内のアプリケーションレベルの内容を用いて、トランザクションがトランザクション処理装置108に切り替えられる。選択されたトランザクション処理装置108に応じて、フローハンドラ210が、トランザクションに対してビジネスサービスを実行することができる。その後、トランザクションは、トランザクション処理装置108に送信される。
【0090】
トランザクション処理装置108は、クライアント銀行(またはイシュア)802を決定し、メッセージをイシュア802へルーティングする。イシュア802は、要求を処理して、応答をトランザクション処理装置108に返信する。次いで、トランザクション処理装置108は、応答(トランザクション処理装置固有のフォーマットで)をアクワイアラ804に返信する。ゲートウェイ104は、応答を受信し、それをXMLフォーマットに翻訳し、それを無線クライアント808に送信する。従って、ゲートウェイ804は、無線トランザクション支払をルーティングするように設定されている。
【0091】
図10は、本発明の一実施形態によるISO8583トランザクションを処理するシステム900を示している。図に示すように、イシュア銀行902およびアクワイアラ銀行904がトランザクションに関与している。アクワイアラ銀行904のクライアントコンピュータ102は、ISO8583要求をゲートウェイ104に送信する。ゲートウェイ104は、アプリケーションレベルの内容および移送環境の現況を用いてトランザクション処理装置108を選択し、要求を処理する。次いで、要求に対して何らかのビジネスサービスが実行された後、選択されたトランザクション処理装置108にメッセージが送信される。
【0092】
トランザクション処理装置108は、トランザクションを処理し、認証のために、該トランザクションを適切なイシュア902に切り替える。イシュアは、トランザクション処理装置108にISO8583を返送する。次いで、トランザクション処理装置108がゲートウェイ104に応答を送信し、次いで、応答がアクワイアラ銀行102のクライアント102に送信される。
【0093】
一例では、あるトランザクション処理装置108が利用不能となるかもしれない。この場合、例えば、プロセッサA、データセンタ01が利用不能となるかもしれない。これは、サービスに対するクライアント102の優先プロセッサであるかもしれない。その場合、ゲートウェイ104は、トランザクションを第2のプロセッサ、プロセッサA、データセンタ02に送信する。ゲートウェイ104は、主データセンタの可用性をチェックし続け、ひとたびそれが利用可能になれば、主データセンタへのメッセージのルーティングを開始することができる。トランザクションの再ルーティングは、クライアント102には見えない方法で行われる。従って、ゲートウェイ104のインテリジェント切り替え機能を用いて、いずれのトランザクション処理装置108のダウンタイムも回避される。
【0094】
別の実施形態では、プロセッサAのデータセンタが故障しているかもしれず、プロセッサBおよびCのような、他のプロセッサの他のデータセンタを使用する必要があるかもしれない。プロセッサBおよびCは、プロセッサAとは異なるフォーマットのトランザクションを処理するのかもしれない。この場合、ゲートウェイ104は、トランザクションのフォーマットを、プロセッサBまたはプロセッサCのフォーマットに相当するフォーマットに変換することができる。次いで、フォーマット化されたトランザクションが、プロセッサBまたはプロセッサCに送信される。結果的に、クライアント102には見えない方法で、異なるプロセッサを用いることができる。たとえプロセッサが異なるフォーマットを用いていても、ゲートウェイ104は、それでもそのフォーマットのトランザクションをルーティングするように設定されている。
【0095】
(メッセージのパース/ビルド)
(パースビルドエンジンの概要)
図11は、本発明の一実施形態によるメッセージをパースするシステム1000を示している。システム1000は、ISO8583メッセージのようなマルチフォーマットメッセージストリームを、内部メッセージフォーマット(IMF)と呼ばれる標準的なメッセージフォーマットにパースし、IMFから、ISO8583メッセージストリームのようなマルチフォーマットメッセージストリームをビルドする。財務メッセージストリームについて説明しているが、システム1000を用いて、どのようなマルチフォーマットメッセージストリームもパースおよびビルドすることができることを理解されたい。
【0096】
パース/ビルドエンジン1004は、図2のインバウンドメッセージストリームパーサ204およびアウトバウンドメッセージストリームビルダ212に相当する。図2に示す全ての構成要素を図11に示していないが、それらの構成要素もシステム1000に含めることができることを理解されたい。さらに、パース/ビルドエンジン1004はゲートウェイ104に含めることができるが、他の構成要素にも含めることができる。例えば、パース/ビルドエンジン1004は、他の異種システムとは異なるデータフォーマットのデータを処理するどのようなソフトウェアアプリケーションとも互換性を有することができる。
【0097】
パース/ビルドエンジン1004は、システム1006から入力メッセージストリーム1010を受信し、該メッセージを内部メッセージフォーマットにパースする。内部メッセージフォーマット(IMF)は、次いで、ゲートウェイ104に示すビジネスサービスアプリケーションのような他の構成要素によって処理することができる。ゲートウェイ104内の構成要素がIMFのメッセージを処理した後、パース/ビルドエンジン1004が、処理済のIMFから出力メッセージストリーム1012をビルドする。出力メッセージストリーム1012は、次いで、システム1008に送信されるか、または送信元システム1006に返信される。
【0098】
システム1006および1008は、メッセージ1010を送信し、かつ/またはパース/ビルドエンジン1004(またはゲートウェイ104)からメッセージ1012を受信するように設定されたどのようなシステムでもよい。一実施形態では、システム1006および1008は、店舗販売時点情報管理装置、スマートカード装置、トランザクション処理装置108、アクワイアラ、イシュア、サービスプロバイダ、トランザクションオーセンティケータ等のような、トランザクションを処理するように設定された何らかのシステムとすることができる。システム1006および1008は、ISO8583メッセージ、拡張可能なマーク付け言語(XML)、HTML等のような、多くの異なるフォーマットのメッセージを送信/受信することができる。入力メッセージストリームも、ASCII、EBCDIC、BCD、等のような、多数の符号化スキームのうちのいずれかとすることができ、数値、文字列、バイトアレイ等のような、異なるデータタイプを有することができる。
【0099】
図11のパース/ビルドエンジンは、スキーマテーブル1028を用いる。各スキーマは、受信したフォーマット用の文法構造、およびハンドラテーブル1030内のハンドラへのポインタを含む、メタデータを提供するデータ構造である。ハンドラは、メッセージ内の特定のフィールドに対応し、文法構造を用いて、メッセージの様々なフィールドを、内部メッセージフォーマットに変換する。ハンドラは、個々にコンパイルされるコードである。従って、システム全体をコンパイルせずに、ハンドラが別個にコンパイルされ、エンジンの他の要素に支障を来たすことなく容易にアップグレードすることができるモジュラーシステムを保持しながら、コンパイルされたソフトウェアの速度を速めている。
【0100】
パース/ビルドエンジン1004は、特定されたスキーマをロードし、該スキーマと関連付けられたハンドラの機能を呼び出す。次いで、ハンドラが、メッセージのフィールドをIMFオブジェクトにパースする。
【0101】
事前ロードされていないスキーマ、および関連付けられた全てのハンドラを、スキーマローダ1024を用いて、スキーマ定義ファイル1026から、スキーマテーブル1028およびハンドラテーブル1030内にロードすることができる。スキーマテーブル1026は、スキーマのname1、name2...,nameNのラベル付きの種々のスキーマを含む。パース/ビルドエンジン1004によってパースおよびビルドされ得る各メッセージに対し、対応するスキーマを提供することができる。各スキーマ名は、外部フォーマット内のメッセージストリームの「文法」、構成を定義するスキーマオブジェクトと関連付けられている。構成には、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、任意または必須の他のフィールドが含まれる。新たなスキーマおよびコンパイルされたハンドラがロードされ、パース/ビルドエンジン1004を再コンパイルすることなく、パース/ビルドエンジン1004によって用いられることができる。
【0102】
(パース/ビルドフロー)
ここで、フローの一例を説明する。図11に示すように、メッセージが受信されると、ビジネスサービスプログラムがパース/ビルドエンジン1004を呼び出す。メッセージ1010(ワイヤフォーマットのメッセージストリーム)がパース/ビルドエンジンに送信され、そこで、メッセージ1010は、最初にパーサ構成要素1016によって受信される。ビジネスサービスアプリケーションは、パーサ構成要素1016にスキーマ名1011も提供する。パーサ構成要素は、内部メッセージフォーマット(IMF)オブジェクトを生成する。オブジェクトの中には、一旦メッセージフィールドがIMFに翻訳されると、メッセージフィールドからの値が格納される。一実施形態では、パーサ構成要素1016は、メッセージ1010の起点を認識し、該起点から送信されたメッセージ1010に対して必要なスキーマを決定する。別の実施形態では、メッセージ1010内の情報をパースしてデータフォーマットを判断し、それにより、用いるべき対応するスキーマを決定することができる。さらに、メッセージ1010は、どのスキーマが当のデータフォーマットに対応するかを示すことができる。
【0103】
一例では、パーサ構成要素1016は、最初に、ISO8583財務メッセージのような、検出されたメッセージのフォーマットに対応するルートスキーマを調べる。そのようなISOメッセージは、どのフィールドが存在するかを特定するビットマップを冒頭に有している可能性がある。ルートスキーマは、ハンドラをポイントし、ハンドラが呼び出されて、タイプフィールドをパースし、何のタイプのメッセージが受信されたか(例えば、承認メッセージ、調整メッセージ等)を判定する。パーサ構成要素は、次いで、特定されたメッセージタイプに対するスキーマを調べ、次いで、スキーマが特定の文法を提供し、当該のメッセージタイプに対するハンドラをポイントする。スキーマおよびハンドラは、実際にメッセージ内に存在するフィールドに対してのみ調査および呼び出しが行われる。新たなフィールドが特定またはポイントされた際は、新たなスキーマを調べ、対応するハンドラを呼び出すことができる。特定のフィールドが1つ以上の条件を有する複合フィールドである可能性もあり、該条件の翻訳またはパーシングが、条件の結果によって、追加のスキーマおよび関連付けられたハンドラをポイントすることができる。
【0104】
IMFオブジェクト1018(以下により詳細に説明する)は、呼び出されたハンドラによって埋め込みされる。埋め込みされるフィールドは、入力メッセージに含まれるフィールドに対応するフィールドのみである。
【0105】
IMFオブジェクト1018は、次いで、ゲートウェイ104のビジネスソフトウェアアプリケーションによって処理される。処理された後、IMFオブジェクト1018は、アウトバウンドメッセージストリームに対するスキーマ名と共に、ビルド構成要素1020に送信される。処理済IMFオブジェクト1018の処理は異なるデータフォーマットで実行され得るので、ビルダ構成要素1020は、処理済のIMFオブジェクト1018から出力メッセージストリーム1012をビルドするように設定されている。上述の処理は、ビルダ構成要素1020がルートスキーマを調べ、何度も繰り返すことができる工程において、ポイントされたハンドラを呼び出して、タイプ情報をビルドしながら、逆順に反復される。呼び出されたハンドラは、IMFオブジェクト1018内で見出した値を、出力メッセージストリーム1012に含める必要のあるフィールドにビルドする。その後、出力メッセージストリーム1012を、出力メッセージストリーム1012を処理することができる、システム1008に送信することができる。
【0106】
図12に、IMFオブジェクト1018を用いて、ゲートウェイ104によって提供されるあらゆるサービスを実行するビジネスサービスアプリケーション1102を示す。ビジネスサービスアプリケーション1102は、IMFオブジェクト1018に対して動作する。動作には、イシュア銀行またはメッセージ送信先処理センタの判定のような、アプリケーション層ルーティングを含めることができる。さらに、サービスは、メッセージストリームのアプリケーションレベルのフォーマット化、ロギング、時刻表示、応答またはさらに別の処理に必要な新たなフィールドの生成等のように、メッセージに対して実行することもできる。ビジネスサービスアプリケーションは、イシュアまたは財務ネットワークに対する前処理を行うことも、負荷分担された局所処理を実行することもできる。例えば、$50未満の購入に対する許可メッセージを承認し、承認を求めて金融機関にメッセージを転送する必要なくして、応答メッセージを送信することができる。ビジネスサービスアプリケーション1102は、内部メッセージフォーマットのデータを処理するように設定されており、外部フォーマットに対してはそうではない。従って、ビジネスサービスアプリケーション1102は、メッセージをIMFにパースすることによって他のシステムで用いられているどのような外部フォーマットからも隔離されている。
【0107】
(IMFの構造)
図13Aは、本発明の一実施形態によるIMF1018用の構造を示している。図に示すように、IMF1018内にN個のフィールドが提供されている。これらのフィールドは、各フィールドが任意数の子フィールドも含むことができ、順に孫フィールド等を含むことができる、階層構造のフィールドのアレイとすることができる。例えば、フィールド1は、子フィールド1.1、1.2、 ...1.Nを含む。フィールド1.2、 ...1.Nも、任意数の子フィールド(図示せず)を含むことができる。メッセージがもし受信されたときは、実際に用いられるフィールドのみにデータが埋め込みされる。
【0108】
図14Bに、オブジェクトのIDコード(図13Aに示すフィールドに対するフィールド定義の索引)を有する階層フォーマットを示す。OIDは、IMFオブジェクト1018内の種々のフィールドに対する索引付けを可能にする。フィールド定義は、OIDを用いて、IMFオブジェクト1018内のフィールドに対してアクセスされる。一実施形態では、OIDは、図に示すドット数値表現によって表される8バイトの数である。第1のフィールドに対するOIDは、1.0.0として符号化されている。任意のサブフィールドは、1.1.0、1.2.0等々として符号化されている。第2のフィールドは、2.0.0として符号化され、任意のサブフィールドは、2.1.0、2.2.0等々として符号化されている。
【0109】
(スキーマの構造)
図13Bに、スキーマの一例を示す。スキーマのアドレスは、第1行、メッセージ定義(MessageDef)である。スキーマは、メッセージ内のフィールドの各々の文法とハンドラへのポインタとを含む。図示の例では、メッセージの第1のフィールドは、索引1.0.0を付けたField Definition Object(FieldDef)1202で識別されている。これは、OID属性1202とも呼ばれる。このフィールドに対する索引の後に続いているのは、呼び出し対象のハンドラ(HDR)の識別1204である。当該行の要素の残り部分は、当該の特定フィールドの文法定義である。これらのフィールド定義は、フィールドシーケンス、フィールドタイプ、長さ、文字符号化、必要なハンドラの名前等のような、そのフィールドの特性を説明している。フィールド定義は、ASCII、EBCDIC、BCD等のような異なる符号化方式で符号化されたフィールド、および数字、文字列、バイトアレイ等のような異なるデータタイプをパース/ビルドするために用いることができる。従って、マルチフォーマットメッセージストリームは、メッセージ定義を用いて処理することができる。一実施形態では、スキーマは、XMLスキーマの形のメタデータである。
【0110】
フィールド定義は、いくつかの属性を含むことができる。図13Bに示されている属性は網羅的ではないことが認識されるであろう。また当業者は、他の属性を用いてもよいことが分かるであろう。
【0111】
ハンドラ属性1204は、フィールドの名前である。必須/任意属性1206は、そのフィールドがメッセージ内で必須であるかまたは任意であるかを示している。第1のデータフォーマット属性1208は、外部フォーマット(ワイヤフォーマットとも呼ばれる)内で見出されたフィールドの値に対するデータフォーマットである。第2のデータフォーマット属性1210は、フィールドがIMFで格納され、ビジネスサービスによって処理される内部フォーマットである。
【0112】
カスタム/非カスタム属性1212は、フィールドのパーシングおよびビルディングに、フィールドがカスタムハンドラを用いるかまたは汎用ハンドラを用いるかを示している。
【0113】
7番目の属性1214は、メッセージのフィールド内の値を処理するために必要なハンドラの名前を示している。ハンドラは、受信メッセージの特定されたフィールド内の値を取り、それをIMFにパースする(パーサスキーマ用)か、またはIMFからの値を外部フォーマットにビルドする(ビルダスキーマ用)。
【0114】
8番目の属性1216は、フィールド内のサブフィールドの数を示している。
【0115】
(IMF(内部メッセージフォーマット)に用いられるメッセージフィールドの例)
図14Aは、いくつかの異なるフィールドのオブジェクトID(OID)、1.0.0、1.1.0、1.1.1、2.0.0、2.2.0、4.0.0、および4.1.0を含む、特定のメッセージオブジェクト1010に用いられるフィールドの一例を示している。これらは、図13Bのスキーマによってポイントされるフィールドである。従って、このメッセージ例では、図14Cに特定されたフィールドのみが、図13Aに示すメッセージオブジェクトに埋め込みされる。図14Bは、内部メッセージフォーマットの完全なフィールドのセットの全階層オブジェクトIDの一部を示している。図に見られるように、メッセージ1010は、これらのフィールドのうちの、メッセージ1010が必要とする部分のみを含んでいる。例えば、オブジェクトID1.2.0、3.0.0、および4.2.0は用いられていない。これらのフィールドは任意の数の子フィールドを有することができることに留意されたい。
【0116】
オブジェクトIDは、図13Aに示すメッセージオブジェクトの階層型内部メッセージフォーマットへの素早い索引付けシステムを提供する。この索引付けシステムは、受信したフォーマットに用いられている各フィールド用に、内部メッセージフォーマットの対応するフィールドに索引を付ける(ポイントする)、符号化オブジェクトID(1.0.0など)を用いる。この索引は、階層構造の数層下にあるフィールドを直接ポイントすることができる。
【0117】
ゲートウェイ104の構成要素がIMFオブジェクト1018を処理する際には、不要なフィールドの処理は実行されない。従って、処理速度が向上する。
【0118】
必須フィールドも、IMFオブジェクト1018に追加することができる。いくつかのフィールドは、ビジネスサービスモジュール1102またはトランザクション処理装置108には必須であるかもしれない。用いる必要のあるフィールドが受信メッセージ1010内に含まれていないと判断された場合、該フィールドは、ビジネスサービスモジュールによって埋め込みをし、再トランザクション用にビルドされることになるメッセージに含めることができる。このようにして、メッセージ1010内に含まれていない場合、図13Bのスキーマ内の「必須」フィールドをIMFオブジェクト1018に追加することができる。
【0119】
(パース/ビルドエンジンの初期設定)
図15は、ビジネスサービスアプリケーションのスタートアップと同時にパース/ビルドエンジン1004を初期設定する方法の略フローチャート1400を示している。ステップ1402で、初期設定要求がアプリケーションから受信される。この要求には、1つ以上のスキーマ定義ファイル1026の位置が含まれている。
【0120】
ステップ1404で、スキーマ定義ファイル1026内で見出されたスキーマが検証される。スキーマは、的確なタイプのデータが参照されていること、スキーマによって特定されたハンドラが実際に存在すること等の検証のような、いくつかの手順によって検証される。
【0121】
ステップ1406で、スキーマ定義ファイル1026内のスキーマが、レジストリ1022内に、スキーマローダ1024を用いて、ディスクまたは他のストレージリポジトリからDRAMメモリ内にロードされる。
【0122】
ステップ1408で、スキーマ内で指定された全てのハンドラが、レジストリ1022内にロードされる。例えば、メッセージ定義オブジェクト内のフィールド定義によって指定されたハンドラが、ハンドラテーブル1030内にロードされる。一実施形態では、ハンドラは、ハンドラの名前でキーボードから入力されたオブジェクトとして格納されている。
【0123】
ステップ1410で、ハンドラがそれぞれのメッセージ定義オブジェクトに結合される。例えば、メッセージ定義オブジェクト内のフィールド定義によって指定された全てのハンドラが、当該のメッセージ定義オブジェクトに結合される。
【0124】
これで、スキーマに対するパース/ビルドエンジン1004の初期設定が完了する。一実施形態では、パース/ビルドエンジン1004のコンパイルはでは必要ない。それは、フィールド値をパース/ビルドするために用いられるコンパイル済みハンドラを使用するからである。
【0125】
ランタイム中に、スキーマを動的に更新し、パース/ビルドエンジン1004に追加することができる。スキーマは、メッセージ定義オブジェクトを変更することによって更新してもよく、新たなメッセージ定義オブジェクトを付加することによって追加してもよい。新たなハンドラが必要な場合、それらも、コンパイル済みオブジェクトとして、パース/ビルドエンジン1004に動的に追加することができる。
【0126】
スキーマは、パース/ビルドエンジン1004を再コンパイルすることなく、かつそれを停止させることなく、追加することもできる。従って、パース/ビルドエンジン1004は、スキーマが更新される際でさえも、メッセージをパース/ビルドし続けることができる。
【0127】
(スキーマの追加または更新)
図16は、本発明の一実施形態による、パース/ビルドエンジン1004内のスキーマを動的に追加または更新する方法の略フローチャート1500を示している。ステップ1502で、スキーマを動的に追加または更新するようにとの要求がアプリケーションから受信される。この要求は、新たな、または更新されたスキーマを含む1つ以上のスキーマ定義ファイル1026の位置を含んでいる。
【0128】
ステップ1504で、スキーマ定義ファイル1026内で見出されたスキーマが検証される。
【0129】
ステップ1506で、スキーマ定義ファイル1026内のスキーマがレジストリ1022内にロードされる。更新されたスキーマに一組の新たなフィールド定義または変更されたフィールド定義が提供されている場合、新たな、または変更されたフィールド定義のみをレジストリ1022内にロードすればよい。スキーマを追加または更新している間、適切なデータ構造が更新をロックされ、処理中のインフライトメッセージがスキーマ変更の結果破壊されないことが確保される。スキーマローダ1024がスキーマの更新バージョンをロードする間、インフライトメッセージは、スキーマの前バージョンを使用し続ける。
【0130】
ステップ1508で、メッセージ定義オブジェクト内で指定された全てのハンドラが、レジストリ1022内にロードされる。パース/ビルドエンジン1004は、いずれかのハンドラがレジストリ1022内にすでに存在する場合、それらのハンドラをレジストリ1022内に再ロードしないように判断するために、チェックを行うことができる。しかしながら、いずれかのハンドラが変更されていた場合、該変更されたハンドラがロードされる。
【0131】
ステップ1510で、それぞれのメッセージ定義オブジェクトにハンドラが結合される。一実施形態では、新たな、または変更されたハンドラのみが、更新済みのメッセージ定義オブジェクトに結合される。これで、パース/ビルドエンジン1004の動的な更新が完了する。
【0132】
(パース工程のフローチャート)
図17は、本発明の一実施形態による、入力メッセージストリーム1010をパースする方法の略フローチャート1600を示している。ステップ1602で、メッセージ用のスキーマが決定される。そのスキーマは、入力メッセージストリーム1010を構成しているデータフォーマットに対応している。
【0133】
ステップ1604で、スキーマ内のポインタから、メッセージ定義オブジェクトに対する全てのハンドラが決定される。
【0134】
ステップ1606で、各フィールド用のハンドラがフィールドに添付される。
【0135】
ステップ1608で、ハンドラがメッセージの各フィールドを翻訳する。各フィールドに対して1つのハンドラが呼び出される。ハンドラは、スキーマ内のフィールド定義を用いて、フィールドの値をIMFに翻訳する。フィールドに対するOIDは、当該のフィールド用スキーマ内のフィールド定義をポイントし、かつIMFオブジェクト1018内の対応するフィールドもポイントする。
【0136】
一実施形態では、パーサ構成要素1016は、メッセージ1010内に読み込まれたフィールドに対するオフセットを保持する。例えば、読み込まれたバイト数は、オフセットとして格納される。パーサ構成要素は、各ハンドラが呼び出される度に、このオフセットの数を減らしてゆく。ハンドラがメッセージ1010の末尾に到達する(例えば、オフセットが特定の長さと等しくなる)か、またはメッセージ定義オブジェクト内の最後のフィールド定義に到達すると、パーサ構成要素は、翻訳が完了したことを認識する。
【0137】
ステップ1610で、翻訳されたフィールドが、IMFオブジェクト1018の対応する階層内に格納される。フィールドに対するOIDは、IMFオブジェクト1018内の階層内の対応する位置に、翻訳された値を格納するために用いることができる。
【0138】
上述の翻訳がいずれかの地点で失敗となった場合、エラーをゲートウェイ104に返すことができる。パーシングは続行することができ、IMFオブジェクト1018は返すことができる。しかしながら、IMFオブジェクト1018内に、エラーフラグを付けることができる。
【0139】
(ビルド工程のフローチャート)
ここで、図18に関して、ビルド工程を説明する。図18は、本発明の一実施形態による、IMFオブジェクト1018から出力メッセージストリーム1012をビルドする方法の略フローチャート1700を示している。ステップ1702で、スキーマ名およびIMFオブジェクト1018が決定される。一実施形態では、IMFオブジェクト1018が最初に決定される。スキーマ名は、IMFオブジェクト1018内の情報に基づいて決定することができる。例えば、スキーマ名は、IMFオブジェクト1018内の情報内に格納することができる。また、スキーマ名は、IMFオブジェクト1018内の情報を送ることになるチャネルまたは宛先システムによって決定してもよい。
【0140】
ステップ1704で、メッセージ定義オブジェクトを用いて、レジストリ1022内のスキーマをアドレス指定する。ステップ1706で、スキーマに対して必要なハンドラも全て決定される。
【0141】
ステップ1708で、IMFオブジェクト1018内で見出された各フィールドに対して、IMFオブジェクト1018内の階層内の対応するフィールドからの値がロードされる。フィールドに対するOIDを用いて、フィールド定義にアクセスする。
【0142】
ステップ1710で、フィールドに対するフィールド定義の属性に従って、IMFオブジェクト1018内のフィールドから、値が翻訳される。その結果、IMFフォーマット内で見出された値は、別のシステムと互換性を有するフォーマットに翻訳される。
【0143】
ステップ1712で、ビルドされた値が、生成された出力メッセージストリーム1012の対応するフィールド内に組み立てられる。
【0144】
IMFオブジェクト1018内のフィールドに対する値が、外部フォーマットに対して必須のフィールド用に見出されない場合、外部メッセージ内の当該のフィールドに対する値を空白に設定してもよく、生成されたメッセージが単にメッセージ内にこのフィールドを有していなくてもよい。さらに、IMFオブジェクト1018がこのフィールドを有していたはずであると判断された場合、IMFオブジェクト1018内にフィールドが見つからなかったことを示すエラーを返すことができる。
【0145】
(代案)
本発明は、ソフトウェアまたはハードウェア、もしくは両方を組み合わせたものにおける制御論理の形で実施することができる。この制御論理は、本発明の実施形態に開示した一組のステップを実行するよう情報処理装置を導くようになっている複数の命令として、情報記憶媒体に格納することができる。本明細書に提供される開示および教示に基づき、当業界の通常の技術者は、本発明を実施する他の手段および/または方法が分かるであろう。
【0146】
上述の説明は、例証となるものであるが、限定するものではない。本開示を検討すれば、当業者には、本発明の多くの変形形態が明らかとなるであろう。従って、本発明の範囲は、上述の説明を参照して決定されるのではなく、出願に係る請求項を参照して、包括的にあるいは均等物も加えて決定されるべきである。
【特許請求の範囲】
【請求項1】
メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信することと、
前記受信されたメッセージのバイト数をオフセットとして格納することと、
複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
前記メッセージの前記フィールド用の1つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、1つ以上のフィールド用の文法定義を含む、ことと、
前記複数のハンドラを用いて、前記メッセージの前記1つ以上のフィールドを前記共通の標準的な内部メッセージフォーマットに翻訳することであって、前記共通の標準的な内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含み、前記パースすることは、前記メッセージ内の前記1つ以上のフィールドに対してのみ行われ、前記共通の標準的な内部構造フォーマットの対応するフィールドのみが作成される、ことと、
前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
を含む、方法。
【請求項2】
メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信することと、
前記受信されたメッセージのバイト数をオフセットとして格納することと、
複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
前記メッセージの前記フィールド用の1つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、1つ以上のフィールド用の文法定義を含み、前記スキーマに含まれる各メッセージフィールドは、オブジェクトIDによって識別され、前記オブジェクトIDは、前記共通の標準的な内部メッセージフォーマット内の特定の場所をポイントする索引である、ことと、
前記複数のハンドラを用いて、前記メッセージの前記1つ以上のフィールドを前記共通の標準的な内部メッセージフォーマットに翻訳することと、
前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
を含む、方法。
【請求項3】
他のスキーマおよびハンドラを再コンパイルすることなく、前記1つ以上のスキーマを動的にロードすることをさらに含む、請求項1に記載の方法。
【請求項4】
前記翻訳することから後続のスキーマを決定することと、
前記メッセージに対して、前記後続のスキーマに対して請求項1に記載のプロセスを繰り返すことと
をさらに含む、請求項1に記載の方法。
【請求項5】
ビジネスサービスアプリケーションによって、前記共通の標準的な内部メッセージフォーマットの前記メッセージを処理することをさらに含む、請求項1に記載の方法。
【請求項6】
前記ビジネスサービスアプリケーションによる前記処理は、前記フィールド内の値を変更することを含む、請求項5に記載の方法。
【請求項7】
前記処理後、前記共通の標準的な内部メッセージフォーマットの前記メッセージを外部メッセージフォーマットにビルドするために、第2の1つ以上のスキーマのセットを決定することと、
前記メッセージ内に含まれる前記1つ以上のフィールドに対応する前記第2の1つ以上のスキーマのセットにおけるフィールド定義およびハンドラを決定することと、
前記ハンドラを用いて、前記外部メッセージフォーマットの1つ以上のフィールドをビルドすることと
をさらに含む、請求項6に記載の方法。
【請求項8】
前記メッセージは、財務トランザクションを含む、請求項1に記載の方法。
【請求項9】
前記メッセージの前記1つ以上のフィールド以外の全ての必要なフィールドを決定することであって、前記必要なフィールドは出力メッセージに必須である、ことと、
前記必要なフィールドが決定された場合、前記メッセージの前記1つ以上のフィールド以外の前記必要なフィールドを前記共通の標準的な内部メッセージオブジェクトに追加することであって、前記1つ以上のフィールドおよび前記必要なフィールドだけが前記内部メッセージオブジェクト内に作成され内包されたフィールドである、ことと
をさらに含む、請求項1に記載の方法。
【請求項10】
メッセージをパース/ビルドするように構成されているエンジン用の命令を含むコンピュータ読み取り可能な格納媒体であって、前記エンジンは、
複数のハンドラであって、各ハンドラは、フィールド用の文法を用いて受信メッセージの複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、複数のハンドラと、
様々なタイプのメッセージ用の複数のスキーマであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、メッセージの1つ以上のフィールド用の文法定義を含む、複数のスキーマと、
共通の標準的な内部メッセージフォーマットオブジェクトであって、前記複数のハンドラは、前記共通の標準的な内部メッセージフォーマットオブジェクトを前記メッセージ内で見い出されたフィールド、および/または、必須フィールドについてだけ作成するように構成されており、前記共通の標準的な内部メッセージフォーマットは必要となる可能性があるフィールドからなる階層構造を含む、共通の標準的な内部メッセージフォーマットオブジェクトと
前記受信されたメッセージのバイト数を示すオフセットを維持するパーサであって、前記パーサの構成要素は、前記複数のハンドラが前記共通の標準的な内部メッセージフォーマットを作成する場合に前記オフセットを減らし、前記パースは、前記減らされたオフセットが所定値に等しい場合に終了する、パーサと
を含む、コンピュータ読み取り可能な格納媒体。
【請求項11】
前記共通の標準的な内部メッセージフォーマットの前記メッセージを処理するように構成されているビジネスサービスモジュールをさらに含む、請求項10に記載のコンピュータ読み取り可能な格納媒体。
【請求項12】
前記エンジンは、前記共通の標準的な内部メッセージフォーマットからメッセージをビルドするように構成されており、前記エンジンは、
第2の1つ以上のスキーマのセットであって、前記第2の1つ以上のスキーマのセットは、メッセージ内のフィールドを前記共通の標準的な内部メッセージフォーマットから外部メッセージフォーマットにパースするのに使用可能なフィールド定義を含む、第2の1つ以上のスキーマのセットと、
前記第2のスキーマのセット用の1つ以上のハンドラであって、前記ハンドラは、前記第2のスキーマのセット内の前記フィールド定義を用いて、前記メッセージ内のフィールドを前記共通の標準的な内部メッセージフォーマットから前記外部メッセージフォーマットにパースするように構成されている、前記第2のスキーマのセット用の1つ以上のハンドラと
を含む、請求項11に記載のコンピュータ読み取り可能な格納媒体。
【請求項13】
メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信することと、
前記受信されたメッセージのバイト数をオフセットとして格納することと、
複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
前記メッセージの前記フィールド用の1つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、1つ以上のフィールド用の文法定義を含む、ことと、
前記複数のハンドラを用いて、前記メッセージの前記1つ以上のフィールドの全てを前記共通の標準的な内部メッセージフォーマットに翻訳することであって、前記共通の標準的な内部メッセージフォーマットは、前記受信されたメッセージの前記フィールドの全てを少なくとも含み、前記共通の標準的な内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含む、ことと、
前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
を含む、方法。
【請求項14】
前記共通の標準的な内部メッセージフォーマットに少なくとも1つのフィールドを追加することをさらに含み、前記フィールドは、前記受信されたメッセージに含まれていない、請求項13に記載の方法。
【請求項15】
前記共通の標準的な内部メッセージフォーマットから出力メッセージを形成することをさらに含み、前記出力メッセージは、前記共通の標準的な内部メッセージフォーマットに存在しない少なくとも1つのフィールドを含む、請求項14に記載の方法。
【請求項16】
前記受信されたメッセージは、ISO8583財務メッセージである、請求項1に記載の方法。
【請求項17】
前記翻訳するステップが失敗した場合に、前記共通の標準的な内部メッセージフォーマットにエラーフラグを設定することをさらに含む、請求項1に記載の方法。
【請求項1】
メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信することと、
前記受信されたメッセージのバイト数をオフセットとして格納することと、
複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
前記メッセージの前記フィールド用の1つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、1つ以上のフィールド用の文法定義を含む、ことと、
前記複数のハンドラを用いて、前記メッセージの前記1つ以上のフィールドを前記共通の標準的な内部メッセージフォーマットに翻訳することであって、前記共通の標準的な内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含み、前記パースすることは、前記メッセージ内の前記1つ以上のフィールドに対してのみ行われ、前記共通の標準的な内部構造フォーマットの対応するフィールドのみが作成される、ことと、
前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
を含む、方法。
【請求項2】
メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信することと、
前記受信されたメッセージのバイト数をオフセットとして格納することと、
複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
前記メッセージの前記フィールド用の1つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、1つ以上のフィールド用の文法定義を含み、前記スキーマに含まれる各メッセージフィールドは、オブジェクトIDによって識別され、前記オブジェクトIDは、前記共通の標準的な内部メッセージフォーマット内の特定の場所をポイントする索引である、ことと、
前記複数のハンドラを用いて、前記メッセージの前記1つ以上のフィールドを前記共通の標準的な内部メッセージフォーマットに翻訳することと、
前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
を含む、方法。
【請求項3】
他のスキーマおよびハンドラを再コンパイルすることなく、前記1つ以上のスキーマを動的にロードすることをさらに含む、請求項1に記載の方法。
【請求項4】
前記翻訳することから後続のスキーマを決定することと、
前記メッセージに対して、前記後続のスキーマに対して請求項1に記載のプロセスを繰り返すことと
をさらに含む、請求項1に記載の方法。
【請求項5】
ビジネスサービスアプリケーションによって、前記共通の標準的な内部メッセージフォーマットの前記メッセージを処理することをさらに含む、請求項1に記載の方法。
【請求項6】
前記ビジネスサービスアプリケーションによる前記処理は、前記フィールド内の値を変更することを含む、請求項5に記載の方法。
【請求項7】
前記処理後、前記共通の標準的な内部メッセージフォーマットの前記メッセージを外部メッセージフォーマットにビルドするために、第2の1つ以上のスキーマのセットを決定することと、
前記メッセージ内に含まれる前記1つ以上のフィールドに対応する前記第2の1つ以上のスキーマのセットにおけるフィールド定義およびハンドラを決定することと、
前記ハンドラを用いて、前記外部メッセージフォーマットの1つ以上のフィールドをビルドすることと
をさらに含む、請求項6に記載の方法。
【請求項8】
前記メッセージは、財務トランザクションを含む、請求項1に記載の方法。
【請求項9】
前記メッセージの前記1つ以上のフィールド以外の全ての必要なフィールドを決定することであって、前記必要なフィールドは出力メッセージに必須である、ことと、
前記必要なフィールドが決定された場合、前記メッセージの前記1つ以上のフィールド以外の前記必要なフィールドを前記共通の標準的な内部メッセージオブジェクトに追加することであって、前記1つ以上のフィールドおよび前記必要なフィールドだけが前記内部メッセージオブジェクト内に作成され内包されたフィールドである、ことと
をさらに含む、請求項1に記載の方法。
【請求項10】
メッセージをパース/ビルドするように構成されているエンジン用の命令を含むコンピュータ読み取り可能な格納媒体であって、前記エンジンは、
複数のハンドラであって、各ハンドラは、フィールド用の文法を用いて受信メッセージの複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、複数のハンドラと、
様々なタイプのメッセージ用の複数のスキーマであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、メッセージの1つ以上のフィールド用の文法定義を含む、複数のスキーマと、
共通の標準的な内部メッセージフォーマットオブジェクトであって、前記複数のハンドラは、前記共通の標準的な内部メッセージフォーマットオブジェクトを前記メッセージ内で見い出されたフィールド、および/または、必須フィールドについてだけ作成するように構成されており、前記共通の標準的な内部メッセージフォーマットは必要となる可能性があるフィールドからなる階層構造を含む、共通の標準的な内部メッセージフォーマットオブジェクトと
前記受信されたメッセージのバイト数を示すオフセットを維持するパーサであって、前記パーサの構成要素は、前記複数のハンドラが前記共通の標準的な内部メッセージフォーマットを作成する場合に前記オフセットを減らし、前記パースは、前記減らされたオフセットが所定値に等しい場合に終了する、パーサと
を含む、コンピュータ読み取り可能な格納媒体。
【請求項11】
前記共通の標準的な内部メッセージフォーマットの前記メッセージを処理するように構成されているビジネスサービスモジュールをさらに含む、請求項10に記載のコンピュータ読み取り可能な格納媒体。
【請求項12】
前記エンジンは、前記共通の標準的な内部メッセージフォーマットからメッセージをビルドするように構成されており、前記エンジンは、
第2の1つ以上のスキーマのセットであって、前記第2の1つ以上のスキーマのセットは、メッセージ内のフィールドを前記共通の標準的な内部メッセージフォーマットから外部メッセージフォーマットにパースするのに使用可能なフィールド定義を含む、第2の1つ以上のスキーマのセットと、
前記第2のスキーマのセット用の1つ以上のハンドラであって、前記ハンドラは、前記第2のスキーマのセット内の前記フィールド定義を用いて、前記メッセージ内のフィールドを前記共通の標準的な内部メッセージフォーマットから前記外部メッセージフォーマットにパースするように構成されている、前記第2のスキーマのセット用の1つ以上のハンドラと
を含む、請求項11に記載のコンピュータ読み取り可能な格納媒体。
【請求項13】
メッセージを共通の標準的な内部メッセージフォーマットにパースする方法であって、
複数のフィールドを含むメッセージを受信することと、
前記受信されたメッセージのバイト数をオフセットとして格納することと、
複数のハンドラを提供することであって、各ハンドラは、前記フィールド用の文法を用いて前記複数のフィールドのうちの少なくとも1つをパースするためのコードであり、各ハンドラは、別個にコンパイルされる、ことと、
前記メッセージの前記フィールド用の1つ以上のスキーマを決定することであって、各スキーマは、前記複数のハンドラのうちの1つをポイントし、かつ、1つ以上のフィールド用の文法定義を含む、ことと、
前記複数のハンドラを用いて、前記メッセージの前記1つ以上のフィールドの全てを前記共通の標準的な内部メッセージフォーマットに翻訳することであって、前記共通の標準的な内部メッセージフォーマットは、前記受信されたメッセージの前記フィールドの全てを少なくとも含み、前記共通の標準的な内部メッセージフォーマットは、必要となる可能性があるフィールドからなる階層構造を含む、ことと、
前記複数のハンドラが用いられている場合に前記オフセットを減らすことであって、前記翻訳は、前記減らされたオフセットが所定値に等しい場合に終了する、ことと
を含む、方法。
【請求項14】
前記共通の標準的な内部メッセージフォーマットに少なくとも1つのフィールドを追加することをさらに含み、前記フィールドは、前記受信されたメッセージに含まれていない、請求項13に記載の方法。
【請求項15】
前記共通の標準的な内部メッセージフォーマットから出力メッセージを形成することをさらに含み、前記出力メッセージは、前記共通の標準的な内部メッセージフォーマットに存在しない少なくとも1つのフィールドを含む、請求項14に記載の方法。
【請求項16】
前記受信されたメッセージは、ISO8583財務メッセージである、請求項1に記載の方法。
【請求項17】
前記翻訳するステップが失敗した場合に、前記共通の標準的な内部メッセージフォーマットにエラーフラグを設定することをさらに含む、請求項1に記載の方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
【図14A】
【図14C】
【図15】
【図16】
【図17】
【図18】
【図6】
【図14B】
【図2】
【図3】
【図4】
【図5】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
【図14A】
【図14C】
【図15】
【図16】
【図17】
【図18】
【図6】
【図14B】
【公開番号】特開2013−101676(P2013−101676A)
【公開日】平成25年5月23日(2013.5.23)
【国際特許分類】
【外国語出願】
【出願番号】特願2013−12892(P2013−12892)
【出願日】平成25年1月28日(2013.1.28)
【分割の表示】特願2008−519670(P2008−519670)の分割
【原出願日】平成18年6月29日(2006.6.29)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(506154720)ビザ ユー.エス.エー. インコーポレイテッド (7)
【出願人】(500313592)ビザ・インターナショナル・サービス・アソシエーション (8)
【公開日】平成25年5月23日(2013.5.23)
【国際特許分類】
【出願番号】特願2013−12892(P2013−12892)
【出願日】平成25年1月28日(2013.1.28)
【分割の表示】特願2008−519670(P2008−519670)の分割
【原出願日】平成18年6月29日(2006.6.29)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(506154720)ビザ ユー.エス.エー. インコーポレイテッド (7)
【出願人】(500313592)ビザ・インターナショナル・サービス・アソシエーション (8)
[ Back to top ]