信頼度の低いネットワーク上で状況に基づくルールを用いてトランザクションおよびデータを切り替えるように適合されたゲートウェイ
ゲートウェイにおける、トランザクションのアプリケーション・レベルの切り替えが提供される。ゲートウェイは、アプリケーション・レベルの内容、伝送環境の現状、および／またはトランザクションの切り替えに関する動的なルールに基づいてトランザクションを切り替えるように構成されている。例えば、いくつかの考え得るプロバイダをトランザクションの種類に合わせて選択することができ、ゲートウェイは、様々な考え得るサービス・プロバイダについて、ネットワーク（単数または複数）を介した往復時間のみではなく、アプリケーション・レベルでトランザクションを完了して回答を返送するのに必要な時間についても監視することができる。アプリケーションは、ネットワークの送信側にて選択され、アプリケーション・レベルのフォーマッティングも同様に送信側にて行われる。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の引用）
本出願は、同時に出願された「ＳＣＨＥＭＡ−ＢＡＳＥＤ ＤＹＮＡＭＩＣ ＰＡＲＳＥ／ＢＵＩＬＤ ＥＮＧＩＮＥ ＦＯＲ ＰＡＲＳＩＮＧ ＭＵＬＴＩ−ＦＯＲＭＡＴ ＭＥＳＳＡＧＥＳ」と題する米国特許出願第＿＿＿＿＿号（代理人事件Ｎｏ．１６２２２Ｕ−０２０３００ＵＳ）と関連し、該出願はあらゆる目的において参照により本明細書に引用される。
【０００２】
本発明は、一般的に電気通信に関し、特に、トランザクションの内容、伝送環境に関する動的状況情報、および／またはトランザクション切り替えの動的ルールに基づいてアプリケーション・レベルでインテリジェントにトランザクションを切り替える技術に関する。
【背景技術】
【０００３】
クレジット・カード承認、デビット・カード取引、電子小切手取引などのトランザクションをクライアントにて実行するとき、クライアントは、トランザクションをサービス・プロバイダへ送信する。サービス・プロバイダは、クレジット・カード承認、トランザクション決済などのサービスをクライアントへ提供する。通常、クライアントは、処理を行うために、トランザクションをサービス・プロバイダのトランザクション処理装置へ送る。トランザクションは、各種ネットワークを経由して送ることができる。各種ネットワークは、本質的に異なっていてもよく、信頼性があってもなくてもよい。
【０００４】
通常、トランザクションは、迅速な応答および高い信頼性を必要とする。例えばユーザが、クライアントを用いてクレジット・カード取引を実行している場合がある。このトランザクションでは、クレジット・カード承認要求を処理するのに、トランザクション処理装置へ送信することが必要になることがあり、それによりトランザクションの承認を容易にすることができる。トランザクションが経由して送られる各種ネットワークのうちの１つ、あるいはこのクライアントに関するトランザクションを処理するのに使用されているトランザクション処理装置が機能しなかったために、トランザクションが失敗、あるいは遅延することがある。何らかの障害が生じると、クライアントは、トランザクションおよびトランザクションの完結から得られるいかなる利益をも失う危機にさらされる。
【０００５】
従来、トランザクションは、一連のパケットに分割され得る。本発明の実施形態は、アプリケーション・レベルでトランザクションに対して動作しており、これに対して、先行技術の多くはネットワーク・レベルでルーティングを行い、パケットに対して動作することを提示している。個別のパケットそれぞれについて、パケット・レベルでルーティングしてもよく、またはヘッダの情報などパケット内の情報に基づいてルーティングすることもできる。以下の特許は、（本発明の実施形態のアプリケーション・レベルの切り替えとは対照的に）パケットのネットワーク・レベルのルーティングについて記載している。ＩＢＭの特許第５，９７４，４６０号では、データをダウンロードするのに、インターネット上の多数のミラー・サイトのうち、まずどのサイトが、サイト選択の時点で最速の転送速度を示すかを判断することによって、１つを選択することを記載している。ＤＥＣの特許第５，３４１，４７７号も類似している。Ａｌｃａｔｅｌの特許第５，７５４，５４３号は、送信費用を考慮しながら行うネットワーク上のルーティングについて記載している。送信費用を考慮している他の特許としては、特許第６，５３５，４８８号、およびＮｏｒｔｅｌの特許第６，４８７，２８６号がある。ＤＥＣの特許５，４５９，８３７号は、ネットワーク全域にわたってサーバの動作を監視し、要求を処理するのに一番大きい帯域幅を有するサーバはどれかを判断するシステムを提示している。Ｃａｂｌｅｔｒｏｎ Ｓｙｓｔｅｍｓの特許第５，５２１，９１０号は、パケットを正規のフレーム形式で示し、さらにネットワークを介した最良の経路を各種メトリックを用いて判断することを示している。特許第６，８３９，７００号は、文書の生成費用に基づき、内容要求の負荷分散について記載している。特許第６，７５４，１８８号は、パケットの内容に基づき、すなわちそれが音声、映像、またはファイル転送のいずれであるかに基づいて、パケットをルーティングすることを記載している。
【０００６】
特許文献１（ＩＢＭの米国特許）は、ＯＳＩモデルの最初の三層を備えたネットワーク処理装置を示している。第４以上の層にアクセスしてフロー制御し、サービスの質に基づいてルーティングを決定する処理装置が、特許文献２（Ｔｏｐ Ｌａｙｅｒ Ｎｅｔｗｏｒｋｓの米国特許）に示されている。これにより、優先順位に基づく電子メールと、帯域幅保証に基づくマルチメディアとを区別できるようになる。
【０００７】
Ｉｎｔｅｌの特許第６，７３２，１７５号は、ビジネストランザクション（例えば、購買注文など）の種類を判断するべくパケットの内容について考察し、その種類のサービスを処理するのに適切なサーバへトランザクションを転送することに基づく、ネットワークにおける切り替えについて示している。上記のことが行われるのは、メッセージが宛て先のウェブ・サイトへネットワークを通じて送信された後であり、ネットワーク上に送信される前ではない。宛て先サーバにおいて内容に基づきメッセージをルーティングするシステムには多数の例があり、例えばインテリジェントな負荷分散装置が挙げられる。Ｄｉｅｂｏｌｄの特許第６，３０２，３２６号は、金融メッセージを共通の形式へ変換し、その後システム内の適切なプログラムへ送ることを示している。ＥＤＳの特許第５，８０５，７９８号は、金融処理サーバの状態を監視して、利用不能になった場合にはメッセージをバックアップへ送るネットワーク・ノードを記載している。
【特許文献１】米国特許第６，４６０，１２０号明細書
【特許文献２】米国特許第６，４３０，１８４号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記の特許は、個別のパケットをパケット・レベルでルーティングするか、または静的ルールに基づいてデータをルーティングするかのいずれかに焦点を当てている。これは、パケットの効率的なルーティングを提供することはできるが、一方で、伝送環境の動的状況、および動的ルールに基づいてアプリケーション・レベルでトランザクションを切り替えることに対しては対応していない。加えて、いずれの処理装置にするかの選択を、通常は負荷分散装置などの様に、ネットワークと宛て先との間のノードで行っている。従って、アプリケーション・レベルでトランザクションをインテリジェントに切り替える技術が提供されることが望ましい。
【０００９】
アプリケーション・レベルにおける現行の技術では、クライアントが、アプリケーション・レベルでの相互作用に対処することが必要である。クライアントは、トランザクション処理装置における変更に応じてソフトウェア・システムを変更する必要があり、さらに様々なトランザクション処理装置によって求められている様々なメッセージ形式をサポートすることも必要である。クライアントは、さらにサーバ・システムおよびネットワーク上の障害に対処し、クライアントのユーザに継続的な動作を提供するために代替的なサーバ処理装置へフェイルオーバするように対処することも必要とされる。
【課題を解決するための手段】
【００１０】
（発明の概要）
本発明の実施形態は、一般にトランザクションのアプリケーション・レベルの内容、伝送環境の動的状況情報、および／またはトランザクション切り替えの動的ルールに基づいて、アプリケーション・レベルでトランザクションを切り替えることに関する。ネットワークのクライアント・エッジにアプリケーション・ルータが設けられ、（１）アプリケーション・レベルの情報に基づいてインテリジェントなルーティングを提供し、（２）サーバへ転送する前に処理サービスを実施し、あるいは（３）サーバへ送ることをせずに、回答をクライアントへ返送するという負荷を分担するサービスを実施することができる。
【００１１】
一実施形態において、トランザクションのインテリジェントな切り替えが提供される。クライアントが、ゲートウェイへトランザクションを送信し、このゲートウェイは、次にトランザクションをトランザクション処理装置へインテリジェントに切り替えるように構成されている。ゲートウェイは、アプリケーション・レベルの内容、伝送環境の現状、および／またはトランザクションの切り替えに関する動的ルールに基づいて、トランザクションを切り替えるように構成されている。例えばいくつかの考え得るサービス・プロバイダをトランザクションの種類向けに選択することができ、ゲートウェイは、考え得る別々のサービス・プロバイダへのネットワーク（単数または複数）を介した往復時間のみでなく、サービス・プロバイダがアプリケーション・レベルでトランザクションを完了し回答を返送するのに必要とする時間についても、監視することができる。
【００１２】
本発明の実施形態による切り替えは、ネットワークの受信側ではなく、送信側において行われる。トランザクションは、特定のネットワークをわたってルーティングされるようにフォーマットされているだけではなく、ネットワークの宛て先にある特定の処理装置によって処理されるようにフォーマットされており、このようなフォーマットを受信ノードで行うのではない。従って、ネットワーク（単数または複数）の送信側にあるノードが、ネットワーク（単数または複数）の受信側にある処理装置のワークフローに関する情報を有している。一実施形態では、このことが、金融トランザクションの承認に必要な限定された数のフィールドなど、特定のフォーマットの限定された数のフィールドのみを扱うことによって可能かつ実用的となる。一実施形態では、承認を求めて金融トランザクションをルーティングするのに、インターネットと、プライベート金融ネットワークとのいずれかを選んでルーティングする。一方で、本発明の実施形態は、音楽、映像などの発注および配信など、あらゆる種類のトランザクションまたは内容に適用することができる。
【００１３】
一実施形態では、アプリケーション・レベルのサービス・プロバイダが、ネットワーク（単数または複数）上で自分たちのサービスを発行、通知、または登録することができる。本発明の実施形態によるゲートウェイが、これらの発行されたサービスの全てまたは選択されたものを、受信して保存することができる。ゲートウェイは、イシュアが信用のある事業体（登録されている銀行または売買業者など）であることを検証し、イシュアのサービスが、ゲートウェイのクライアント（単数または複数）のトランザクションに関係があるかどうかを判断する。サービスは、一日の終わりまで待つこと、あるいは人間のオペレータが介入することを必要とせずに、動的に登録および更新することができる。
【００１４】
一実施形態では、サービス・プロバイダが提供するサービスの保存されている詳細を使用することにより、ゲートウェイが、トランザクションをどのサービスへ向けて送信するかを選択できるだけではなく、サービス・プロバイダに適するように、トランザクションをアプリケーション・レベルでフォーマットすることができる。加えて、トランザクションをネットワークを通じてサービス・プロバイダへ送信する前に、ゲートウェイにて、何らかの事前処理または調整ステップを実施することができると考えられる。あるいは、一部または全ての場合において、サービス・プロバイダから受け取るルールに従って、トランザクション処理を全てゲートウェイにて行うことも可能と考えられる。例えば、或る閾値より低額のクレジット・カード取引については、承認を求めて銀行へ行く必要がないばかりでなく、ネットワークを通じてクレジット・カード会社へ行く必要もないまま、承認することが可能となり得る。
【００１５】
一実施形態では、クライアントが、どのサービス・プロバイダを選択するか判断するためのルールまたは基準を指定することができる。上記のルールまたは基準は、ゲートウェイに保存することができる。これらのクライアント基準については、トランザクションに先立ってロードすることもでき、あるいはトランザクションメッセージが送信される直前または直後にロードすることもできる。
【００１６】
一実施形態では、本発明によるゲートウェイ機能が、多数のゲートウェイへ分配されている。各ゲートウェイは、物理的にはネットワークのエッジ、クライアントのアクセス点に位置し、さらにはクライアントの物理的な構内にあってもよい。ゲートウェイは、接続しているクライアント（単数または複数）に関する情報を保存し、他のゲートウェイが接続しているサービスに関する情報については他のゲートウェイの提供に依存している。これは、ネットワークのパケット送信のために、接続している他のルータからテーブル情報を入手するルータに若干類似しているが、ただし、本発明の実施形態ではアプリケーション・レベルのサービスを扱っているところを別にする。各ゲートウェイは、自分あるいは自分のクライアントが関心のあるブロードキャスト・サービス・プロバイダの情報を保存するだけでよく、それ以外の接続が必要になる可能性もあるとはいえ、それが接続する他のゲートウェイのアドレスを保存するだけでよい。
【００１７】
本明細書に開示されている本発明の性質および利点について、本明細書の残りの部分、および添付の図面を参照することによって、さらに理解することができる。
【発明を実施するための最良の形態】
【００１８】
（処理の概要）
一実施形態において、トランザクションのインテリジェントな切り替えが提供される。トランザクションは、クレジット・カード承認、デビット・カード取引、または電子小切手取引とすることができる。トランザクションのその他の例としては、賞提供企画においてポイントまたは他の報酬を与えること、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａ認証用のパスワードを確認すること、送金を行うこと、Ｖｉｓａ Ｂｕｘｘカードまたは給与カードなどの料金前払い式カードから支払いを引き落とすこと、携帯電話、ページャ、ＰＤＡなどから近接型の支払いを処理すること、健康保険、自動車保険、または他の保険の適用対象範囲を判断することなどが挙げられる。クライアントは、トランザクションをゲートウェイへ送信し、ゲートウェイは、次に、トランザクションをサービス・プロバイダのトランザクション処理装置へインテリジェントに切り替えるように構成されている。クライアントは、ＰＯＳ、ＰＯＳデバイスまたはＥＣＲ（ｅｌｅｃｔｒｏｎｉｃ ｃａｓｈ ｒｅｇｉｓｔｅｒｓ：電子式金銭登録機）とネットワーク接続された売買業者のコンピュータ、キオスク（クーポンまたは資金の転送用など）、インターネット・ウェブ・サイト・サーバなどである可能性がある。
【００１９】
ゲートウェイは、トランザクションのアプリケーション・レベルの内容、伝送環境の現状、および／または動的ルールに基づいて、アプリケーション・レベルにて切り替えを決定するように構成されている。アプリケーション・レベルの内容は、トランザクション処理装置がトランザクションを処理するにあたって処理または使用する情報であり得る。一実施形態では、情報が、ＯＳＩ第７層の情報であり得る。この層は、直接、トランザクション処理装置またはエンド・ユーザに対して機能する。この層には、クレジット・カード承認、デビット・カード取引のアプリケーションなどのアプリケーションが含まれている。アプリケーション層のプロトコルの例としては、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ファイル転送プロトコル）、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ：ネットワーク・ファイル・システム）、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ：インターネット共有ファイル・システム）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ハイパー・テキスト転送プロトコル）、データベース・クエリ、ＳＱＬ（Ｓｔａｎｄａｒｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：標準問い合わせ言語）、およびＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ：拡張マークアップ言語）が挙げられる。例えば、クレジット・カード承認において、アプリケーション・レベルの内容としては、クレジット・カード番号、個人アカウント番号（ＰＡＮ：ｐｅｒｓｏｎａｌ ａｃｃｏｕｎｔ ｎｕｍｂｅｒ）、顧客アカウント番号、トランザクションの総額などが挙げられる。トランザクション処理装置は、トランザクションを処理するためにこの情報を使用すればよい。
【００２０】
伝送環境の現状には、トランザクションを伝送できるネットワークおよびトランザクションを処理できるトランザクション処理装置に関連するリアルタイムの情報が含まれている。リアルタイム情報としては、ネットワークまたはトランザクション処理装置の健康状態、ネットワークまたはトランザクション処理装置の利用可能性、トランザクション処理装置のアプリケーション処理速度などを挙げることができる。
【００２１】
動的ルールは、トランザクションのインテリジェントな切り替えの方法を決定するのに使用される情報であり得る。ルールは、アプリケーション・レベルの内容および伝送環境の現状に従ってトランザクションを切り替えるのに使用される。例えば、ルールは、或る特定のアプリケーション・レベルの内容および伝送環境の現状に応じて、サービス・プロバイダの提供する或る特定のサービスが選択されるように指定することができる。さらに、ルールを使うと、サービス・プロバイダがトランザクションを処理するトランザクション処理装置を選ぶことができる。例えば、或る特定の国が国内トランザクション用に局所的な処理を必要とすることがあり、故に局地的な処理センタへのルーティングを必要としている場合がある。これらのルールは、選択をするために、ネットワーク費用、サービス費用などの静的な情報も考慮に入れている。ルールは、ゲートウェイを停止させることなく、動的に変更することができる。
【００２２】
ゲートウェイは、ルールに従って、トランザクションに対するサービスを実施することもできる。サービスには、アプリケーション・レベルの内容を処理することも含まれ得る。例えば、トランザクション処理装置が、様々な形式でトランザクションを処理するように構成されているとよい。選択された処理装置が、トランザクションにおける現在のアプリケーション・レベルの内容とは異なる形式のアプリケーション・レベルの内容を処理するように構成されていることもある。従って、ゲートウェイが、アプリケーション・レベルの内容を新しい形式へ変更するとよく、よって選択されたトランザクション処理装置がそれを処理することができるようになる。故に、ゲートウェイは、アプリケーション・レベルにて、トランザクションにある情報を変更することがある。このことは、パケット・レベルで情報を見直すこととは異なる。従来、トランザクションはパケットに分割することがあり得る。ルータは、パケット内の情報を見て、適宜パケットをルーティングすることができる。しかし、パケット・レベルで情報を見ることでは、ルータが、トランザクションのアプリケーション・レベルの内容を使用してサービスを実施できるようにはならない。例えば、トランザクション全体に関するアプリケーション・レベルの内容を見ることによって、このトランザクションが、トランザクションに適用される適切なサービスを受けてインテリジェントにルーティングされることが可能となる。トランザクションに関する情報を伝える個別のパケットが個別に処理されている場合、このトランザクションのアプリケーション・レベルの内容は、全体としては処理されない。
【００２３】
故に、ゲートウェイが、アプリケーション・レベルの内容、伝送環境の現状、および／または動的ルールに基づいて、アプリケーション・レベルにてトランザクションをインテリジェントに切り替えるように備えられる。ゲートウェイは、さらに、切り替えの決定に基づいて適用されるサービスを提供し得る。
【００２４】
（システムの概要）
図１は、本発明の一実施形態に従ってトランザクションを処理するシステム１００を表している。図示されているように、システム１００は、１つ以上のクライアント１０２、１つ以上のゲートウェイ１０４、１つ以上のネットワーク１０６、および１つ以上のトランザクション処理装置１０８を含んでいる。以下の説明は単独のゲートウェイ１０４に関して記載されるが、当然のことながら、複数のゲートウェイ１０４が備えられ、後述のあらゆる機能が実行されてもよい。さらに、ゲートウェイがクライアントと隣り合って示されているが、ゲートウェイは、トランザクション処理装置と隣り合い、トランザクション処理装置とネットワーク１０６との間に配置されてもよい。
【００２５】
クライアント１０２は、トランザクションを送信するように構成されている任意のシステムを含む。例えば、クライアント１０２には、ユーザのトランザクションを実行するコンピュータ・デバイスのシステムを含めることができる。一例では、クライアント１０２には、販売時点管理（ＰＯＳ：ｐｏｉｎｔ ｏｆ ｓａｌｅ）デバイスが含まれていてもよく、これは、クレジット・カード承認、小切手カード取引などのための、クレジット・カード情報、暗証番号、名前などのユーザ情報を受信する。クライアントは、店舗にあってポイントまたはクーポン情報を確認するためのキオスク、あるいは送金用のキオスク、あるいは携帯電話または他のデバイスからの無線ユーザ入力を受信するノード、あるいはウェブ・サイト・サーバなどの可能性もある。クライアントは、さらに、売買業者のサーバであることも考えられ、ＰＯＳデバイスはこれを介してネットワーク接続をしている。
【００２６】
次に、クライアント（例えばＰＯＳデバイス）が、トランザクション処理装置１０８からのトランザクションサービスを要求するトランザクションを送信し得る。トランザクションサービスは、トランザクション処理装置１０８が実施することのできる任意の措置であり得る。一実施形態では、これらのトランザクションサービスが、クライアント１０２によって実施されているトランザクションに関して価値を付加する。トランザクションサービスの例としては、クレジット・カード承認、デビット・カード取引、電子小切手取引などを容易化することが挙げられる。トランザクションサービスには、さらに、トランザクションの処理、またはデータの交換を含めることもできる。
【００２７】
ゲートウェイ１０４は、クライアント１０２からトランザクションを受信し、このトランザクションを、ネットワーク１０６を介してトランザクション処理装置１０８へ送るように構成されているシステムを含む。一実施形態では、ゲートウェイ１０４は、ネットワーク１０６のエッジに位置している。例えば、ゲートウェイ１０４は、クライアント１０２のアクセス点にあってもよく、あるいはクライアント１０２の構内にあってもよい。ネットワーク１０６のエッジは、トランザクションが、ネットワーク１０６を経由するルーティングを設定され得る地点とすればよい。例えば、ゲートウェイ１０４は、トランザクション処理装置１０８を選択して、ネットワーク１０６のルータへ要求を送信することができる。トランザクションは、多数のパケットに分割することができる。ルータは、故に、トランザクションのパケットをネットワーク１０６を経由させてトランザクション処理装置１０６へ送ると考えられる。
【００２８】
ネットワーク１０６は、データを転送するように構成されている任意のネットワークとすればよい。例えば、ネットワーク１０６としては、任意のパケット・ベースのネットワーク、公衆交換電話網（ＰＳＴＮｓ：ｐｕｂｌｉｃ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋｓ）、無線ネットワーク、インターネット、プライベート金融ネットワークなどを挙げることができる。
【００２９】
一実施形態では、複数のネットワーク１０６が、本質的に異なっている、および／または信頼性のないネットワークであってもよい。ネットワークは、別々の事業体によって制御されていてもよく、別々のプロトコルおよび形式を用いてデータを送ってもよく、別々の伝送方法を用いてデータを送ってもよいというような点で、本質的に異なっている。例えば、複数のネットワーク１０６が、別々の事業体によって制御されていてもよい。一例としては、第１のインターネット・サービス・プロバイダ（ＩＳＰ：Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）がネットワーク１０６−１を維持管理し、第２のインターネット・サービス・プロバイダがネットワーク１０６−２を維持管理していてもよい。トランザクションは、一実施形態の中で、ネットワーク１０６−１、もしくはネットワーク１０６−２のいずれかを経由して送られればよい。
【００３０】
さらに、複数のネットワーク１０６が、別々の種類であってもよい。例えば、ネットワーク１０６−１が、データのパケットを送る非同期転送モード（ＡＴＭ：ａｓｙｎｃｈｒｏｎｏｕｓ ｔｒａｎｓｆｅｒ ｍｏｄｅ）のネットワークであり得る。別のネットワーク１０６−２は、データを無線で送信する無線ネットワークであってもよい。さらに、もう１つ別のネットワーク１０６が、ＶｉｓａＮｅｔネットワークなど一事業体用のプライベート・ネットワークであってもよい。ネットワーク１０６は２つしか図示されていないが、当然のことながら、もっと多数のネットワーク１０６を設けてもよい。さらに、これも当然のことながら、トランザクションは、複数のネットワーク１０６を経由して送られてもよい。例えば、トランザクションは、ネットワーク１０６−１を経由し、次いでネットワーク１０６−２を経由して、その後トランザクション処理装置１０８へ送られてもよい。
【００３１】
ネットワーク１０６は、さらに、信頼性がないこともあり得る。ネットワークの性質から、いつでも機能しなくなることがあり得る。従って、トランザクション処理が中断されるのを避けるために、フェイルオーバ処理が必要である。
【００３２】
サービス・プロバイダは、クライアント１０２へ提供することのできるサービスを登録および発行し得る。クライアント１０２は、サービスに対して登録し、トランザクションをサービス・プロバイダへ切り替えさせることができる。サービス・プロバイダは、クライアント１０２へサービスを提供するように構成されている不特定多数のトランザクション処理装置１０８を有し得る。一実施形態では、トランザクション処理装置１０８が、金融トランザクションを処理する。例えば、トランザクション処理装置１０８は、イシュア、アクワイアラ、売買業者、またはその他任意のサービス・プロバイダと関連づけられ得る。一例では、トランザクション処理装置１０８が、クレジット・カード取引の承認を容易化する。
【００３３】
サービスは、複数のトランザクション処理装置１０８によって提供することができる。例えば、サービス・プロバイダが、クライアント１０２へサービスを提供できるデータ・センタを多数有し得る。従って、このサービスに関するトランザクションは、このサービスを提供できるトランザクション処理装置１０８のうちのいずれかに切り替えられ得る。トランザクション処理装置１０８は、ゲートウェイ１０４によって、アプリケーション・レベルの内容、伝送環境に関する状況情報、および／または動的ルールに基づいて選択され得、これらは全て動的に変化していてもよい。
【００３４】
アプリケーション・レベルのサービスは、動的に変更されることがある。利用可能なサービスが、変更されたり、別の処理装置へ移動されたり、維持管理または障害を理由に利用不可能となっていたりすることが考えられる。
【００３５】
伝送環境に関する状況情報も、動的に変化している場合がある。故に、ゲートウェイ１０４は、トランザクションの切り替え方法を決定するにあたり、伝送環境に関する状況情報を判断する。例えば、ネットワーク１０６の現在の健康状態、ネットワーク１０６の利用可能性、トランザクション処理装置１０８の利用可能性、データがネットワーク１０６を介して転送されている速度、トランザクションをネットワーク１０６を介して転送する費用、トランザクションを処理する費用、アプリケーションがトランザクションをアプリケーション・レベルで処理するのに要する時間の長さなどについて判断され得る。
【００３６】
伝送環境に関する状況情報の動的な情報に加えて、何らかの比較的静的な情報についても判断され得る。例えば、静的な情報としては、トランザクションの費用、トランザクション処理装置１０８がトランザクションを処理するのに必要なフォーマットなどが挙げられる。ゲートウェイ１０６は、トランザクションをどのように送るかを決定するのに、動的および静的な情報を使用し得る。
【００３７】
動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するのに使用される情報であるといえる。ルールは、動的にロードすることができる。例えば、サービス・プロバイダが、サービスに関するルールを登録し得、これが、ゲートウェイ１０４へ動的にロードされ得る。さらに、クライアントが、サービスおよびプロバイダのルールに加入して、自分のトランザクションをサービス・プロバイダへ切り替え得る。これらのルールも、ゲートウェイ１０４へ動的にロードされ得る。
【００３８】
故に、ゲートウェイ１０４は、トランザクションを処理することのできる、サービスのためのトランザクション処理装置１０８を動的に選択することができる。選択されたトランザクション処理装置１０８が処理できるようにトランザクションをフォーマット可能であるなど、選択されたトランザクション処理装置に特有のビジネス・サービスをトランザクションに対して実施することもできる。次いで、トランザクションを、選択されたネットワーク１０６を介して、選択されたトランザクション処理装置１０８へ送信することができる。トランザクション処理装置１０８および／またはネットワーク１０６を動的に選択することによって、ゲートウェイ１０４は、トランザクション処理装置１０８および／またはネットワーク１０６のあらゆる障害からクライアント１０２を隔離している。故に、このことは、極めて高いサービスの利用可能性を提供している。ゲートウェイ１０４は、トランザクション処理装置１０８の停止期間を生じさせるような、必要とされるあらゆる変更から、クライアント１０２を隔離している。
【００３９】
（ゲートウェイ１０４の概要）
図２は、本発明の一実施形態によるゲートウェイ１０４のさらに詳な説明を図示している。図のように、ゲートウェイ１０４には、１つ以上の要求ハンドラ２０２、インバウンド・メッセージ・ストリーム・パーサ２０４、セキュリティ・マネージャ２０６、適応型ルート・セレクタ２０８、フロー・ハンドラ２１０、アウトバウンド・メッセージ・ストリーム・ビルダ２１２、メッセージ・ディスパッチャ２１４、コーディネータ２１６、管理モジュール２１８、設定ローダ２２０、ルール・データベース２２２、状況情報データベース２２４、および動的情報モニタ２２６が含まれる。
【００４０】
要求ハンドラ２０２は、クライアント１０２からトランザクションを受信するように構成されている。クライアント１０２は、ハイパー・テキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、拡張マークアップ言語（ＸＭＬ）、ＩＳＯ８５８３標準などの様々なプロトコルおよび形式でトランザクションを送信することができる。要求ハンドラ２０２は、多様なプロトコルおよび形式で送信されるトランザクションのためにインターフェースを備え、トランザクションを、インバウンド・メッセージ・ストリーム・パーサ２０４へ提供する。例えば、ＩＳＯメッセージのハンドラは、クライアント１０２からＩＳＯ８５８３要求を受信し、それをインバウンド・メッセージ・ストリーム・パーサ２０４へ渡すように構成されている。同様に、ＸＭＬメッセージのハンドラ、ＨＴＴＰ要求のハンドラ、およびＦＴＰ要求のハンドラは、ＸＭＬ、ＨＴＴＰ、およびＦＴＰのメッセージおよび／または要求に対処することができる。故に、要求ハンドラ２０２は、ゲートウェイ１０４が、様々なプロトコルおよび形式でメッセージを受信できるようにしている。上記の形式およびプロトコルについて説明がなされているが、当業者には当然のことながら、他にも要求ハンドラ２０２が処理できる形式およびプロトコルがある。
【００４１】
インバウンド・メッセージ・ストリーム・パーサ２０４は、要求ハンドラ２０２からトランザクションを受信し、この要求を正規の形式へ変換するように構成されている。インバウンド・メッセージ・ストリーム・パーサ２０４は、メッセージを様々な形式で受信し、これらの要求を正規の形式へ処理することができ、ひいては、これがゲートウェイ１０４の他の構成要素によって処理可能となる。従って、多様な形式のトランザクション要求を、ゲートウェイ１０４によって処理することができる。インバウンド・メッセージ・ストリーム・パーサ２０４は、さらに、拡張可能なアーキテクチャを備え、その中で、ゲートウェイ１０４によって処理できる新しい形式を使用可能にすることができる。新しい形式が追加された場合、インバウンド・メッセージ・ストリーム処理装置１０４には、この新しい形式を正規の形式へ変換することが追加される。このように、正規の形式が使用されるために、新しい形式が追加されるときにも、ゲートウェイ１０４の全構成要素への変更は必要ないのである。正しくは、インバウンド・メッセージ・ストリーム・パーサ２０４は、要求を、ゲートウェイ１０４の他の構成要素によって処理可能な正規の形式にパースするように構成されている。インバウンド・メッセージ・ストリーム処理装置２０４のさらなる詳細については後に記す。
【００４２】
セキュリティ・マネージャ２０６は、トランザクションに関するセキュリティ機能を提供するように構成されている。例えば、プラガブル（ｐｌｕｇｇａｂｌｅ）認証および承認、ロール・ベース・アクセス制御（ＲＢＡＣ：ｒｏｌｅ−ｂａｓｅｄ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）、暗号化、ファイル保全などのセキュリティ機能を提供できる。プラガブル認証および承認は、認証および承認用に標準インターフェースを備え、故に、現行の方法に影響を及ぼすことなく、認証の新しい方法およびアクセス制御の追加が可能となる。当業者には当然のことながら、他にもトランザクションへ付加することのできるセキュリティ機能がある。
【００４３】
適応型ルート・セレクタ２０８は、トランザクションを、トランザクション処理装置１０８へ、ネットワーク１０６を介して切り替えるように構成されている。適応型ルート・セレクタ２０８は、アプリケーション・レベルの内容、伝送環境の現状、および／または動的ルールに基づいて、トランザクションを切り替える。
【００４４】
適応型ルート・セレクタ２０８は、ルール・データベース２２２に含まれているルール、および状況情報データベース２２４に含まれている動的状況情報を使用して、トランザクションをルーティングする。上述のように、状況情報は、状況情報データベース２２４に保存されているとよい。一実施形態では、状況情報は動的であってもよい。動的情報モニタ２２６が、状況情報を監視し、判断することができる。動的情報は、次いで、状況情報データベース２２４に保存される。状況情報の例としては、ネットワーク１０６の利用可能性、トランザクション処理装置１０８の健康状態、トランザクションごとの費用、アプリケーションが前のトランザクションをアプリケーション・レベルで処理するのに要した時間などがある。一実施形態では、動的情報モニタ２２６は、トランザクションが受信されたら、動的状況情報をランタイムに判断し得る。別の実施形態では、動的情報モニタ２２６は、動的状況情報を或る一定の間隔で判断し得る。
【００４５】
トランザクション処理装置１０８によって実施される様々なサービスのそれぞれが、動的情報モニタ２２６によって実施することのできるプローブを指定し得る。プローブが送信され、トランザクション処理装置１０８および／またはネットワーク１０６の状態に基づいて情報が収集されることが可能となる。例えば、動的情報モニタ２２６は、ネットワークが利用可能かどうかを判断するために、ネットワークにテスト送信して応答を求めることができる。トランザクション処理装置１０８またはネットワーク１０６と連絡がつかなかったら、利用不可能とみなせばよく、状態の情報を状況情報データベース２２４内に反映させる。或るサービス用のトランザクション処理装置１０８全てと連絡がつかなかったら、そのときはこのサービスが利用不可能であるとみなせばよい。この場合、ゲートウェイ１０４が、このサービスを提供している他のサービス・プロバイダを指定し得る。さらに、トランザクション処理装置１０８上のアプリケーションがトランザクションを処理するのに要する時間が測定され得る。例えば、アプリケーションがクレジット・カード承認を承認するのに要する期間が測定される。この測定によって、トランザクションを切り替えるのに使用することのできるアプリケーション・レベルの状況が提供される。
【００４６】
ルール・データベース２２２は、トランザクションを処理するネットワーク１０６および処理装置１０８に加えてトランザクション用のサービスにも関する判断ルールを含んでいる。ルールは、クライアントの基準も表し得る。例えば、サービスが選択されるためには、ルールとして或る特定の状況情報およびアプリケーション・レベルの内容を満たす必要がある。クライアントが、トランザクションのサービスを選択するのに使用可能なクライアント独自のルールを用意してもよい。一例では、クライアント１０２に関するトランザクションを受信したら、適応型ルート・セレクタ２０８が、クライアント独自の選択ルールを判断し、このトランザクションに対処できるサービスを判断し得る。このサービスを提供しているサービス・プロバイダへトランザクションを切り替えるために、トランザクションからアプリケーション・レベルの内容を判断し、および／または状況情報データベース２２４から動的状況情報を判断する。アプリケーション・レベルの内容、および／または状況情報をルールに適用し、このルールに従って、トランザクションを処理できるサービス・プロバイダを判断する。クライアント１０２は、例えば、費用など或る特定の要素に基づいて、もっとも安価なサービスが第１に選択されるべきであるが利用不可能の場合にはより費用のかかる第２のサービスが選択されるように、指定することができる。さらに、アカウント番号などのアプリケーション・レベルの内容に基づいて、トランザクションを、或る特定のクレジット・カード・サービスへ切り替えることもできる。例えば、或る特定のアカウント番号が、クレジット・カードかデビット・カードかを示すか、あるいは特定のポイントまたは報酬システムが適用されていることを示してもよい。他のアカウント番号またはフィールドは、送金またはパスワード検証（例えば、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａ）など、他のサービスの必要性を示すことが考えられる。さらに、アプリケーション・レベルの内容には、クライアントの場所、およびトランザクションが局所的な処理を必要とするか、または異なる国の処理装置１０８への送付が必要かを指示する、何らかの地域または国を指定する規程を含めることもできる。
【００４７】
サービスには、さらに、サービスに関するルールを指定するサービス仕様が含まれ得る。例えば、ルールは、トランザクションに必要なメッセージ形式、サービスを提供するトランザクション処理装置１０８のネットワーク・アドレス、トランザクション処理装置１０８へのトランザクション切り替えに関する優先順位、サービスに適格なアカウント番号の範囲などを指定し得る。これらのルールは、後にさらに詳細に述べるように、登録にあたり、サービス・プロバイダによって提供される。サービス・プロバイダは、ルールを直接ゲートウェイ１０４へロードすることができ、ゲートウェイが、次に、他の関与するゲートウェイへルールを発行すると考えられる。
【００４８】
ルールは、トランザクションを処理することのできるフローを指定し得る。フローは、トランザクションをトランザクション処理装置１０８へ送信するための処理に対処する。メッセージは、その後、選択されたフロー・ハンドラ２１０へ送信される。トランザクション処理装置１０８およびネットワーク１０６が選択された後、フロー・ハンドラ２１０は、トランザクションに対してビジネス・サービスを実施し得る。例えば、別々のトランザクション処理装置１０８は、別々の形式でトランザクションを処理することが考えられる。フロー・ハンドラ２１０は、選択されたトランザクション処理装置１０８に適切な形式を判断し、その形式にトランザクションをフォーマットし得る。他のビジネス・サービスとしては、通貨の換算、機密情報を扱うフィールドの暗号化、或る特定の閾値を下回るトランザクション額に対するクライアント側の代理処理などが挙げられる。
【００４９】
フロー・ハンドラ２１０には、複数のフローを含めることができる。各フローは、あるクラスのメッセージを処理する一連のビジネス・サービスに対処し得る。各フローには、フローにおけるビジネス・サービスを全て調整するフロー・ハンドラが含まれている。フローの範囲内の一続きのサービスは、フロー仕様によって指定され、設定ローダ２２０を使用してランタイムにロードすることができる。フロー仕様は、着信メッセージにどのように対処するかを決定する一続きのサービスである。各サービスは、特定の機能を実行するソフトウェア・アプリケーション・コードである。新しいサービスおよびフロー仕様については、ゲートウェイ１０４へ動的にロードすることができる。
【００５０】
フローの中で、フロー・ハンドラ２１０がトランザクションを処理した後、メッセージはアウトバウンド・メッセージ・ストリーム・ビルダ２１２へ送信される。ビルダ２１２は、決定されたトランザクション処理装置１０８によって求められているメッセージ形式に基づいて、正規の形式からアウトバウンド・メッセージをビルドするように構成されている。ビルダ２１２は、故に、正規のメッセージ形式に基づいて任意のメッセージ形式でメッセージを生成するように構成されている。アウトバウンド・メッセージ・ストリーム・ビルダ２１２については、後にさらに詳述する。
【００５１】
メッセージ・ディスパッチャ２１２は、トランザクション処理装置１０８へトランザクションを送信するように構成されている。ディスパッチャ２１４は、トランザクションが選択されたトランザクション処理装置１０８へ確実に届くようにし得る。ディスパッチャは、多様なトランザクション処理装置１０８との接続を管理し、機能しなかったトランザクション処理装置１０８への再接続を試み、さらにトランザクション処理装置１０８およびネットワーク１０６の状態を動的情報モニタ２２６へ提供し得る。一実施形態では、トランザクションがパケット化、すなわち一連のパケットに分割されており、ルータへ送信され得る。ルータは、パケットを、ネットワーク１０６を経由させてトランザクション処理装置１０８へ送り得る。
【００５２】
コーディネータ２１６は、ゲートウェイ１０４の複数の処理装置を調整し、トランザクションの適正な処理が確実に行われるようにする。さらに、コーディネータ２１６は、アプリケーション管理、ソフトウェア配布、システム監視およびフェイルオーバ機能に関するサービスをゲートウェイ１０４に提供する。アプリケーション管理は、アプリケーションおよびサービスの開始および停止を局所的および遠隔的にサポートする。アプリケーション管理は、さらに、ゲートウェイ１０４に新しいアプリケーションおよびサービスが追加できるようにする。ソフトウェア配布は、ソフトウェア更新をゲートウェイ１０４上へインストールできるようにし、必要に応じてロールバック更新のサポートを行うことを含む。システム監視サービスは、メモリ、ＣＰＵ、ネットワーク・インターフェースなどのシステム構成要素の主要なパラメータ、および処理を監視し、設定されたパラメータが閾値から逸れた場合には警告を発する。コーディネータ２１６は、さらに、処理の失敗を検出したら、処理を再始動させる。コーディネータ２１６は、さらに、（複数ゲートウェイのクラスタ配置の場合に）ハートビート・メカニズムを使用してピア・ゲートウェイ１０４の健康状態を監視し、ピア・ゲートウェイ１０４が機能しない場合には、ピア・ゲートウェイ１０４の処理負荷を引き継ぐ。
【００５３】
（ルールの動的ロード）
サービスの初期登録（以下に記載）の後、ルールおよびゲートウェイ１０４によって実施されるビジネス・サービスは動的に変更されることがある。管理モジュール２１８および設定ローダ２２０が、ルール・データベース２２２およびフロー・ハンドラ２１０へ変更を動的にロードするように構成されている。
【００５４】
設定ローダ２２０は、設定の変更、ルーティングのルール、新しいフロー仕様などを、ルール・データベース２２２へランタイムにロードするように構成されている。故に、設定ローダ２２０によって、ルール・データベース２２２内のルーティングのルールを動的に再構成できるようになっている。ルールベースは、複数バージョンのルールオブジェクトを維持管理しており、ルールベースの現行バージョンと同期を取ったリファレンスを有する。設定ローダ２２０は、ルールベースへ更新をロードする前に、使用中のルールベースのシャドウ・コピーを作成し、次いでバージョン変更する。次いで、更新されているオブジェクトごとにオブジェクトの新インスタンスを作成し、ルールベースの新バージョンにおいてリファレンスを更新する。全ての更新が完了したら、リファレンスがルールベースの新バージョンを指し示すように変更する。
【００５５】
管理モジュール２１８は、管理上の措置が実施可能となるように構成されている。管理モジュール２１８は、ユーザ・エージェントが、１つ以上のゲートウェイ１０４を管理するのに使用することができる。例えば、管理モジュール２１８を使うと、ルール・データベース２２２の中へ新しいルールを定義することができ、あるいはルーティングのルールを動的に変更することができる。さらに、管理モジュール２１８を使用して、フロー・ハンドラ２１０用の新しいフロー仕様のロードおよびアンロード、ビジネス・サービスの開始および停止、さらに設定のロードおよびアンロードを行うこともできる。その後、設定ローダ２２０が、変更を実施するように構成されている。
【００５６】
本発明の実施形態の動的な変更は、サービスのモジュール化およびサービスのランタイム起動を組み合わせて、フローを通してメッセージ処理を行う（例えば、上述のフローの説明を参照）ことにより、可能となっている。適応型ルート・セレクタ２０８は、新しいトランザクションを受信すると、ルールベースの現行バージョンを読み、そのルールを適用して適切なフローを選択する。フロー・ハンドラ２１０は、トランザクションの全期間中にわたって特定のバージョンのフローを使用するので、各フロー仕様は、サービス、フローおよびルールの特定のバージョンを参照する。故に、現行のトランザクションによって現在使用されているバージョンとは異なるバージョンにおいて更新が行われるために、その時点で現行のトランザクションへ干渉することなくこれらを更新することが可能である。
【００５７】
（トランザクションの処理）
図３は、本発明の一実施形態に従ってトランザクションを処理する方法の簡略化したフロー図３００を表している。ステップ３０２で、クライアント１０２からトランザクションを受信する。トランザクションは、クレジット・カード承認、小切手カード取引など、いかなる種類のトランザクションであってもよい。
【００５８】
ステップ３０４で、トランザクションのアプリケーション・レベルの内容が判断される。上述のように、アプリケーション・レベルの内容は、トランザクションを処理するのに使用される。例えば、アプリケーション・レベルの内容は、クレジット・カード番号、ＰＩＮ、加盟銀行（アクワイアラまたはイシュア）の名前などであり得る。アプリケーション・レベルの内容は、全体としてとらえられ得る。例えば、トランザクションが多数のパケットにパケット化されていたら、アプリケーション・レベルの内容は、複数パケットのペイロードの中にあると考えられる。この情報は、トランザクションのアプリケーション・レベルの内容に組み立て直され得る。
【００５９】
ステップ３０６で、伝送環境の現状について判断される。例えば、サービスを提供できるトランザクション処理装置の健康状態について判断される。さらに、トランザクションを送ることのできるネットワーク１０６のネットワーク健康状態についても判断され得る。この情報は、伝送環境の現在の状況が提供されるように、リアルタイムに判断され得る。
【００６０】
ステップ３０８で、サービスを判断すべく、アプリケーション・レベルの情報および／または伝送環境の現状に対してルールを適用する。例えば、或る特定のクライアント１０２を、或る特定のサービスと関連付けてもよい。Ｖｉｓａなどの処理装置のホストは、自分のトランザクションがＶｉｓａの所有するトランザクション処理装置１０８へ切り替えられることを望む場合がある。さらに、他の処理装置のホストが、自分たちのトランザクションを、Ｖｉｔａｌなど二次的なトランザクション処理装置へ切り替えることを望む場合もある。
【００６１】
ステップ３１０で、ルールを適用して、サービスに向けてトランザクションを切り替えるトランザクション処理装置および／またはネットワーク１０６を判断する。この決定は、ルールに適用されたアプリケーション・レベルの内容および／または伝送環境に関する現状に基づいて判断され得る。例えば、トランザクションを処理するサービスについて判断される。次に、ネットワークの利用可能性に基づいて適用できるトランザクション処理装置１０８が判断される。
【００６２】
さらに、サービスを、多様なトランザクション処理装置１０８およびネットワーク１０６と関連付けてもよい。例えば、クレジット・カード承認が、或る特定のトランザクション処理装置１０８へ送信されるように構成され得る。さらに、小切手カード取引が、第２の一連のトランザクション処理装置１０８へ送信されるように構成されていてもよい。これらのルールは、クライアントおよび／またはトランザクションサービスに関して判断される。
【００６３】
ステップ３１２で、要求に応じて、トランザクションに対する任意のビジネス・サービスがアプリケーション・レベルで実施され得る。例えば、トランザクションが、選択されたトランザクション処理装置１０８に求められている形式へフォーマットされ得、アプリケーション・レベルにある任意の情報がトランザクションに付加され得、あるいは他の任意のビジネス・サービスが実施され得る。
【００６４】
ステップ３１４で、トランザクションは、選択されたトランザクション処理装置１０８へネットワーク１０６を介して切り替えられ得る。
【００６５】
あるいは、他の実施形態では、ゲートウェイ１０４が、トランザクションをサービス・プロバイダへ切り替えることをせずに、トランザクションを処理するように構成されている。或る特定の基準が満たされていれば、ゲートウェイ１０４がトランザクションを処理できることを提示するルールを、サービス・プロバイダが指定すればよい。例えば、トランザクションが、或る特定の金額を下回っている場合などである。一例では、閾値より低額のクレジット・カード取引については、承認を求めて銀行へ行く必要がないばかりでなく、ネットワーク１０６を通じてクレジット・カード会社へ行く必要もないまま、承認することが可能となり得る。このことは、トランザクションがネットワークのエッジにおいて処理できるため、多数の利点を提供する。これは、ネットワークのボトルネックを解消し、分散化された処理システムを提供する。
【００６６】
（サービスの作成および加入）
上述のように、ルールは、ルール・データベース２２２へ動的にロードすることができる。図４は、本発明の一実施形態に従って、トランザクション処理装置１０８が提供するサービスに関してゲートウェイ１０４へルールをロードする簡略化したフロー図４００を表している。ステップ４０２で、サービス作成要求を受信する。例えば、サービス・プロバイダが、このサービス・プロバイダの提供しているサービスを指定するサービス作成要求を送信することによって、サービスの登録を試みてもよい。あるいは、トランザクション処理装置または他のサービス・プロバイダと関連しているゲートウェイ１０４が、新しいサービスを動的に通知してもよく、クライアントと関連しているゲートウェイは、それらの新しいサービスへの登録を始めるかどうかを判断することができる。新しいサービスは、送金サービス、新しいポイント・プログラムなどであることが考えられる。
【００６７】
ステップ４０４で、サービスに関するルールを受信する。例えば、ルールが、サービスを処理することのできるトランザクション処理装置１０８のアドレスを指定し得る。ネットワーク・アドレスは、トランザクション処理装置１０８へトランザクションを送ることのできるＩＰアドレスまたは他の任意の識別番号とすればよい。加えて、要求をトランザクション処理装置１０８へ送るのに使用可能な、ネットワーク１０６に関する情報についても、受信され得る。ルールは、さらに、サービスの使用に関する基準を指定してもよい。例えば、メッセージの受信時に求められているフォーマットを指定している基準、サービスを使用する費用（固定費用およびトランザクションごとの費用の両方）、およびサービスの使用に関する他の任意の基準が受信され得る。ルールは、どのカードの種類あるいはどのアカウントの種類またはアカウント番号が、サービスに関して適格な範囲かまたは登録されているかを、指定することも可能と考えられる。
【００６８】
ステップ４０６で、サービスに関するルールは、管理モジュール２１８によって、設定ローダ２２０を用いてデータベース２２２へ動的にロードされる。さらに、サービスに関してトランザクションを処理するのに必要なあらゆるフロー仕様が、フロー・ハンドラ２０２へロードされ得る。
【００６９】
その結果、サービスが作成され発行されると、クライアント１０８が、サービスに加入することができる。図５は、本発明の一実施形態によるサービスに加入する方法の簡略化したフロー図５００を表している。ステップ５０２で、作成されたサービスへ加入する要求をクライアント１０８から受信する。要求は、ウェブのポータルを介して、あるいは他の任意の方法によって、受信すればよい。クライアント１０２は、ゲートウェイ１０４に直接接触およびアクセスしてもよい。
【００７０】
ステップ５０４で、サービスの使用に関するルールまたは基準の仕様を、クライアント１０８から受信する。この仕様は、クライアント１０８から受信したトランザクションに関するサービスを選択するのに必要な基準を示し得る。基準は、クライアント固有のものであってもよく、または多数のクライアント１０８にわたって（例えば、或る事業体の全ＰＯＳデバイスに対して）一様であってもよい。さらに、仕様は、加入する各サービスに関してクライアント１０８が優先順位をつける形式にしてもよい。例えば、クライアントは、或るトランザクションに関しては第１サービスが選択されるが、そのサービスが機能していなければ、そのときには第２サービスが選択されるようにする、といった指定をすることができる。基準をさらに複雑にして、ネットワーク費用、サービス費用などを考慮に入れた複雑なルールを含めてもよい。
【００７１】
ステップ５０６で、サービスの要求をルーティングするルールが生成される。これらのルールは、サービスが選択されるために、アプリケーション・レベルの内容および／またはネットワークの伝送環境の現状に基づいて満たす必要のある基準を指定し得る。
【００７２】
ステップ５０８で、これらのルールが、ルール・データベース２２２へ動的にロードされ得る。従って、サービスは、サービスに加入するクライアント１０８にとって直ちに利用可能な状態になり得る。
【００７３】
ステップ５１０で、サービスのフロー定義が生成される。フロー定義は、サービスをサポートするように構成され得る。一実施形態では、サービスのフロー定義が既に存在しており、生成する必要がなくてもよい。一方、クライアント１０８に特化したビジネス・サービスを実施する必要のある場合には、新しいフロー定義が生成され得る。
【００７４】
ステップ５１２で、ステップ５１０にて生成されたフロー定義が、設定ローダ２２０によって動的にロードされ得る。
【００７５】
一実施形態では、トランザクションが送信されるより前に、クライアント１０２からルールを受信することがある。例えば、クライアント１０２が、サービスに加入し、このサービスの使用に関するルールを準備してもよい。別の実施形態では、トランザクションが送信される直前または直後にルールが送信され得る。例えば、クライアント１０２が、トランザクションの前または後に送信されるメッセージに使用のルールを指定し得る。ルールは、次いで、ゲートウェイ１０４へ動的にロードされる。これにより、クライアント１０２が、ゲートウェイ１０４をランタイムに動的に構成することができる。
【００７６】
（サービスに関するルールの分散化）
複数のゲートウェイ１０４がシステム内に配置されてもよい。各ゲートウェイ１０４は、接続しているクライアント１０２へ、独自のサービスを提供し得る。ゲートウェイ１０４は、ネットワーク１０６のエッジ、クライアントのアクセスのポイント、および場合によってはクライアント１０２の物理的な構内に位置することができる。一実施形態では、ゲートウェイ１０４は、ゲートウェイ１０４によって提供されているサービスに関する情報のみを保存する。様々なゲートウェイ１０４が、様々な一連のサービスに関する情報を有すればよい。従って、サービス・プロバイダによって登録された、あるいはクライアント１０２によって加入された多様なサービスの提供に関する情報は、ゲートウェイ１０４全体にわたって配布されてもよく、すなわち分散させられ得る。情報の分散化によって、ゲートウェイ１０４は、他のゲートウェイ１０４に連絡して、サービスの情報について問い合わせるか、あるいはサービスの情報を提供するかのいずれかを行うように構成されている。
【００７７】
図６は、本発明の一実施形態に従ってゲートウェイ１０４の分散型システムを提示するシステム５５０を表している。図のように、複数のクライアント１０２およびゲートウェイ１０４が提示されている。ゲートウェイ１０４は、１つ以上のネットワーク１０６のエッジに位置している。
【００７８】
各ゲートウェイ１０４は、１つ以上のクライアント１０２に接続し得る。記述のために、単一のクライアント１０２がゲートウェイ１０４に接続して示されているが、当然のことながら、多数のクライアント１０２が、ゲートウェイ１０４に接続していてもよい。さらに、当然のことながら、ゲートウェイ１０４は、クライアント１０２ではなくトランザクション処理装置１０８に接続していてもよい。
【００７９】
ゲートウェイ１０４は、ネットワーク１０６のエッジにて接続しているクライアント１０２に関するトランザクションを処理するように構成されている。例えば、ゲートウェイ１０４−１は、クライアント１０２−１に関するトランザクションを処理するように構成されており、ゲートウェイ１０４−２は、クライアント１０４−２に関するトランザクションを処理するように構成されている。ゲートウェイ１０４−１は、クライアント１０２−１へ提供されるサービスに関する情報に加え、クライアント１０２−１の優先順位に関する情報も保存している。同様のことが、他のゲートウェイ１０４およびクライアント１０２についても当てはまる。
【００８０】
ゲートウェイ１０４は、サービスに関する情報の配布を容易化するように、他のゲートウェイ１０４の連絡先を維持管理している。例えば、第１ゲートウェイ１０４が、現在第１ゲートウェイ１０４の提供していないサービスに関する情報を必要とするとき、このサービスを提供している第２ゲートウェイ１０４に連絡して、サービスに関するルールなどの情報を送信してもらうことができる。別の実施形態では、第１ゲートウェイ１０４は、サービスに関するトランザクションを第２ゲートウェイ１０４へ送信してもよく、それにより第２ゲートウェイ１０４がトランザクションを処理できる。この場合、第２ゲートウェイ１０４は、トランザクションを、トランザクション処理装置１０８へ切り替え、回答を受信し、その後この回答を第１ゲートウェイ１０４へ返送することができる。
【００８１】
連絡先は、さらに、他のゲートウェイ１０４へサービスに関する情報を配布するのに使用してもよい。例えば、サービス・プロバイダが、第１ゲートウェイ１０４上に新しいサービスをアップロードする場合がある。このサービスに関するルールは、その後、他のゲートウェイ１０４へ配布されるとよい。例えば、エッジにてクライアント１０２と接続しているゲートウェイは、クライアント１０２がサービスに関心を持っていれば、ルールを送信される。クライアント１０２は、独自のルールをアップロードすることもできる。
【００８２】
各クライアントは、自分の望むサービスに関するルールのみをロードすればよいので、必要とされるメモリおよび更新が削減され、ゲートウェイの処理速度は改善される。例えば、クライアントがホテルであれば、ポイントあるいは報酬サービスを必要とするが、送金サービスは必要としないこともある。所望のサービスだけをロードすることによって、ホテルは、性能に影響を及ぼすことなく、ゲートウェイ上により多くの情報を獲得できると考えられる。例えば、ポイント・プログラムで使っているアカウント番号もしくはアカウント番号の範囲をゲートウェイ上に保存することができ、そのため或るユーザがポイントに適格であるかどうかの判断を局所的に行うことができる。一方、クライアントがウェブ・サイトであれば、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａサービスの方により関心を示すことが考えられる。同様に、或るカード会員が加入済であるか、およびパスワードを有するかなど、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａに固有の情報およびルールを局所的に保存することが可能と考えられ、それによりパスワードがネットワーク上に出て行かなくとも、ユーザが加入者か否かの判断をするためにパスワードを促すことができるようになる。或る特定の売買業者が或る特定の会社と多くトランザクションをするのであれば、Ｖｉｓａビジネス・カードにより高い関心を持ち、その特定の売買業者での購入を承認されている購入カード・アカウント番号の局所的なリスト作成を望むこともあり得る。
【００８３】
このようにして、クライアント１０２およびサービス・プロバイダは、直接ゲートウェイ１０４と相互作用して、サービスをロードまたは要求することができる。これは、ゲートウェイをクライアントの必要性に合ったものにすることができるので、クライアント１０２にとって有利であるといえる。さらに、ゲートウェイ１０４はクライアント・サイトにて維持管理することができるので、ゲートウェイ１０４へ容易にかつ遅滞なくアクセスすることができる。
【００８４】
故に、システム５５０によって、分散型の一連のサービスが提供される。中央処理装置を有する代わりに、処理が、ネットワークのエッジへ分配されている。このことは、ボトルネックを解消し、フェイルオーバ保護を提供する。例えば、従来は、中央型処理装置を使用していてそれが作動しなくなった場合は、システム全体のトランザクション処理が影響を受けることがある。一方、或るゲートウェイ１０４が作動しなくなっても、システム５５０全体の処理は影響を受けず、トランザクションは他のゲートウェイ１０４へ送られればよい。
【００８５】
（配置のシナリオ）
ゲートウェイ１０４は、多数の異なったシナリオで配置することができる。例えは、ゲートウェイ１０４は、プライベート・ネットワーク上のフロントエンド・ゲートウェイ、インターネット・ゲートウェイ、および／または無線ゲートウェイとして、配置できる。図７は、本発明の一実施形態に従って、ゲートウェイ１０４をフロントエンド・ゲートウェイとして提示するシステム６００を表している。システム６００は、本質的に異なる複数のネットワーク１０６を通じて１つ以上のクライアント１０２を１つ以上のトランザクション処理装置１０８へ接続している。トランザクション処理装置１０８は、クライアント１０２からのトランザクションを処理することのできる任意のシステムであればよい。例えば、Ｖｉｓａ、ＭａｓｔｅｒＣａｒｄなどが、クレジット・カードおよびデビット・カード取引用のトランザクション処理装置を所有し得、加盟銀行（アクワイアラ／イシュア）をクライアント１０２とすればよい。
【００８６】
クライアント・データ・センタ６０２が、クライアント１０２からトランザクションを受信し得る。トランザクションは、クレジット・カード承認またはデビット・カード取引であり得る。データ・センタは、例えば、クライアントのプライベート・ネットワークを介して、複数のＰＯＳデバイスと接続している中央コンピュータであり得る。ゲートウェイ１０４は、トランザクションを処理し、このトランザクションをトランザクション処理装置データ・センタ１０８へインテリジェントに切り替える。例えば、トランザクションがＶｉｓａのトランザクションである場合、トランザクション処理装置データ・センタＡおよびＢが、Ｖｉｓａと関連し得る。トランザクションがＭａｓｔｅｒＣａｒｄのトランザクションであれば、ＭａｓｔｅｒＣａｒｄと関連しているという理由で、処理装置データ・センタＣが選択され得る。
【００８７】
ゲートウェイ１０４は、適切なトランザクション処理装置１０８、およびトランザクションを送るネットワーク１０６を判断する。その後、トランザクションは、ルータ６０４へ送信され、次いで、ルータがこのトランザクションをルーティングすることができる。一実施形態では、ルータ６０４は、パケットを、選択されたトランザクション処理装置１０８へネットワーク１０６を経由させて送り得る。
【００８８】
図８は、本発明の一実施形態に従って、ゲートウェイ１０４がインターネット・ゲートウェイとなっているシステム７００を表している。インターネット・クライアント７０２は、クライアント１０２を含んでいる。クライアント１０２は、インターネット７０４を介してゲートウェイ１０４へトランザクションを送信することができる。ゲートウェイ１０４は、標準的なクレジット・カード承認、パスワード認証（Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａ）、報酬またはポイント処理など、オンライン・ショッピングに必要な特定のサービス向けに構成され得る。
【００８９】
ゲートウェイ１０４は、クライアント１０２に対し、様々なトランザクション処理装置１０８との接続性を提供する。ゲートウェイ１０４は、ＨＴＴＰ（Ｓ）および他のＸＭＬベースの要求を受け付け得る。アプリケーション・レベルの内容および伝送環境の現状に基づいて、サービスおよびトランザクション処理装置１０８が選択され得る。トランザクションはＨＴＴＰまたはその他任意のＸＭＬベースの要求の状態で送信されてきたと考えられるので、ゲートウェイ１０４は、トランザクションを切り替える前に、メッセージを、トランザクション処理装置１０８に求められている形式へ変換するとよい。例えば、トランザクション処理装置１０８は、メッセージがＩＳＯ８５８３形式で処理されていることを必要とする場合がある。通常、ＰＯＳデバイスがトランザクションを処理すれば、トランザクションはＩＳＯ８５８３形式で送信されると考えられる。一方、トランザクションがインターネット・ゲートウェイによって処理される場合、インターネット・クライアント７０２はＩＳＯ８５８３のメッセージを送信するようには構成されていないことがある。故に、ゲートウェイ１０４は、メッセージを、トランザクション処理装置１０８に必要とされるＩＳＯ８５８３形式へフォーマットするように構成されている。
【００９０】
一例では、ゲートウェイ１０４は、インターネット・クライアント７０２からのインターネットトランザクションを処理し得る。インターネット・クライアント７０２が、ＨＴＴＰ（Ｓ）要求をゲートウェイ１０４へ送信する。ゲートウェイ１０４は、ＨＴＴＰ（Ｓ）要求を、正規の内部メッセージ形式へ変換する。その後、任意のビジネス・サービスをトランザクションに対して実施することができる。一例では、トランザクション処理装置１０８に必要とされるフォーマットに適合するように、アプリケーション・レベルのデータを変更し得る。例えば、ＸＭＬトランザクションが、ＩＳＯ８５８３形式へ変換され得る。ゲートウェイ１０４は、その後、トランザクションを、トランザクション処理装置１０８へインテリジェントに切り替える。
【００９１】
トランザクション処理装置１０８は、トランザクションを処理し、ゲートウェイ１０４へ回答を返送する。この回答は、トランザクション処理装置に固有の形式であってもよい。ゲートウェイ１０４は、次に、ＨＴＴＰ（Ｓ）の回答をビルドし、それをインターネット・クライアント７０２へ送信する。故に、ゲートウェイ１０４を使用して、インターネットを介したトランザクションを処理することができる。
【００９２】
図９は、本発明の一実施形態に従って、ゲートウェイ１０４が無線ゲートウェイとして使用されているシステム８００を表している。ゲートウェイは、ユーザの移動電話、ＰＤＡ、ページャなどから無線メッセージを受信することができる。ゲートウェイ１０４は、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ：ｗｉｒｅｌｅｓｓ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ）、モバイル情報デバイス・プロトコル（ＭＩＤＰ：ｍｏｂｉｌｅ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｖｉｃｅ ｐｒｏｔｏｃｏｌ）、ＪＱＭＥなど、様々な無線形式をサポートするように構成され得る。ＭＩＤｌｅｔは、モバイル・コミュニケーション用グローバル・システム（ＧＳＭ：ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）または汎用パケット無線サービス（ＧＰＲＳ：ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅｓ）などのネットワークを通じてＸＭＬ形式の要求を送信する。ゲートウェイ１０４は、インバウンド要求のペイロードを正規の内部メッセージ形式へ変換し得る。内部メッセージ形式（ＩＭＦ：ｉｎｔｅｒｎａｌ ｍｅｓｓａｇｅ ｆｏｒｍａｔ）は、次いで、ビジネス・サービスによって処理し得る。アウトバウンド・メッセージ・ストリーム・ビルダ２１２が、ＩＭＦを、トランザクション処理装置１０８へ送信するための応答ペイロードへ変換する。故に、ゲートウェイ１０４によって無線トランザクションを処理することができる。
【００９３】
ここで無線トランザクションについて説明する。一実施形態では、無線クライアント８０８が、ＨＴＴＰ（Ｓ）／ＧＳＭ／ＧＰＲＳを通じてＸＭＬ要求を送信することによって、無線支払トランザクションを開始する。ゲートウェイ１０４は、ＸＭＬ要求を受信し、この要求を処理する前に、正規の内部メッセージ形式へ変換する。トランザクションをトランザクション処理装置１０８へ切り替えるのに、伝送環境の現状に加え、トランザクションのアプリケーション・レベルの内容を使用する。選択されたトランザクション処理装置１０８によっては、フロー・ハンドラ２１０が、トランザクションに対してビジネス・サービスを実施し得る。トランザクションは、その後、トランザクション処理装置１０８へ送信される。
【００９４】
トランザクション処理装置１０８が、クライアントの銀行（あるいはイシュア）８０２を判断し、メッセージをイシュア８０２へ送る。イシュア８０２は、要求を処理し、回答をトランザクション処理装置１０８へ返送する。次いで、トランザクション処理装置１０８が、アクワイアラ８０４へ回答を（トランザクション処理装置に固有の形式で）返送する。ゲートウェイ１０４は、回答を受信し、それをＸＭＬ形式へ変換し、それを無線クライアント８０８へ送信する。故に、ゲートウェイ１０４は、無線トランザクションの支払をルーティングするように構成されている。
【００９５】
図１０は、本発明の一実施形態に従って、ＩＳＯ８５８３のトランザクションを処理するシステム９００を表している。図示されているように、イシュア銀行９０２およびアクワイアラ銀行９０４がトランザクションに参加している。アクワイアラ銀行９０４にあるクライアント・コンピュータ１０２が、ＩＳＯ８５８３要求をゲートウェイ１０４へ送信する。ゲートウェイ１０４は、要求に対処するトランザクション処理装置１０８を選択するために、アプリケーション・レベルの内容および伝送環境の現状を使用する。次に、要求に対して任意のビジネス・サービスが実施された後で、メッセージは、選択されたトランザクション処理装置１０８へ送信される。
【００９６】
トランザクション処理装置１０８は、トランザクションを処理し、それを、承認を得るために適切なイシュア９０２へ切り替える。イシュアは、ＩＳＯ８５８３をトランザクション処理装置１０８へ返送する。トランザクション処理装置１０８は、次に、ゲートウェイ１０４へ回答を送信し、回答は、その後、アクワイアラ銀行１０２のクライアント１０２へ送信される。
【００９７】
一例では、トランザクション処理装置１０８が利用できないことがある。この場合、例えば、処理装置Ａ、データ・センタ０１が利用できなくなっていると考えられる。これが、クライアント１０２にとって、サービスのために望まれる処理装置である場合がある。ゲートウェイ１０４は、その結果、トランザクションを第２処理装置、すなわち処理装置Ａ、データ・センタ０２へ送信する。ゲートウェイ１０４は、第１のデータ・センタの利用可能性について確認し続け得、それが利用可能になり次第、第１のデータ・センタへメッセージをルーティングし始め得る。トランザクションのルートの再選択はクライアント１０２に気付かれない形で行われる。故に、ゲートウェイ１０４のインテリジェントな切り替えを用いて、あらゆるトランザクション処理装置１０８のダウンタイムが回避されている。
【００９８】
別の実施形態では、処理装置Ａのデータ・センタが機能停止し、処理装置ＢおよびＣなど他の処理装置のデータ・センタを使用しなくてはならない場合がある。処理装置ＢおよびＣは、処理装置Ａとは異なる形式でトランザクションを処理すると考えられる。この場合、ゲートウェイ１０４が、トランザクションの形式を、処理装置ＢおよびＣ用の形式と一致する形式へ変換すればよい。フォーマットされたトランザクションは、その後、処理装置ＢまたはＣへ送信される。従って、クライアント１０２には気付かれない形で、様々な処理装置を使用することができる。処理装置が別々の形式を使用している場合であっても、ゲートウェイ１０４が、トランザクションをなおその形式で送るように構成されている。
【００９９】
（メッセージのパース／ビルド）
（パースビルド・エンジンの概要）
図１１は、本発明の一実施形態に従ってメッセージをパースするシステム１０００を表している。システム１０００は、ＩＳＯ８５８３メッセージなどの複数の形式のメッセージ・ストリームについては内部メッセージ形式（ＩＭＦ）と呼ばれる正規のメッセージ形式へパースし、ＩＭＦからは、ＩＳＯ８５８３メッセージ・ストリームなど複数の形式のメッセージ・ストリームをビルドするように構成されている。金融メッセージ・ストリームについて説明が行われているが、当然のことながら、任意の複数の形式のメッセージ・ストリームについて、システム１０００を用いてパースおよびビルドすることができる。
【０１００】
パース／ビルド・エンジン１００４は、図２のインバウンド・メッセージ・ストリーム・パーサ２０４およびアウトバウンド・メッセージ・ストリーム・ビルダ２１２に相当する。図２に示されている構成要素の全てが図１１に示されているわけではないが、当然のことながら、それらの構成要素もシステム１０００へ含めることができる。加えて、パース／ビルド・エンジン１００４は、ゲートウェイ１０４へ含まれていてもよいし、あるいは他の構成要素に含まれていてもよい。例えば、パース／ビルド・エンジン１００４は、他の異機種システムとは異なるデータ形式でデータを処理する任意のソフトウェア・アプリケーションと適合可能であり得る。
【０１０１】
パース／ビルド・エンジン１００４は、システム１００６から入力メッセージ・ストリーム１０１０を受信し、このメッセージを内部メッセージ形式へパースするように構成されている。内部メッセージ形式（ＩＭＦ）は、次いで、ビジネス・サービス・アプリケーションなど、ゲートウェイ１０４内に示される他の構成要素によって処理することができる。ゲートウェイ１０４内の構成要素がＩＭＦのメッセージを処理した後、パース／ビルド・エンジン１００４は、処理されたＩＭＦから、出力メッセージ・ストリーム１０１２をビルドする。出力メッセージ・ストリーム１０１２は、次に、システム１００８へ送信されるか、または発信元のシステム１００６へ返送され得る。
【０１０２】
システム１００６および１００８は、メッセージ１０１０を送信、および／または、パース／ビルド・エンジン１００４（またはゲートウェイ１０４）からのメッセージ１０１２を受信するように、構成されている任意のシステムであり得る。一実施形態では、システム１００６および１００８は、販売時点管理デバイス、スマート・カード・デバイス、トランザクション処理装置１０８、あるいはアクワイアラ、イシュア、サービス・プロバイダ、トランザクション認証機能などトランザクションを処理するように構成されている任意のシステムであり得る。システム１００６および１００８は、ＩＳＯ８５８３メッセージ、拡張マークアップ言語（ＸＭＬ）、ＨＴＭＬなど多数の異なる形式のメッセージを送信／受信し得る。入力メッセージ・ストリームは、ＡＳＣＩＩ、ＥＢＣＤＩＣ、ＢＣＤなど多数の符号化方式のいずれを使っていてもよく、数字、文字列、バイト配列など様々なデータ型を有していてもよい。
【０１０３】
図１１のパース／ビルド・エンジンはスキーマ・テーブル１０２８を使用している。各スキーマは、受信形式に関する文法構造のほか、ハンドラ・テーブル１０３０内のハンドラへのポインタを含んだメタデータを提供するデータ構造である。ハンドラは、メッセージ内の特定のフィールドに対応し、文法構造を使用して、メッセージの様々なフィールドを内部メッセージ形式へ変換する。ハンドラは、個別にコンパイルされているコードである。故に、システム全体をコンパイルするのではなく、ハンドラが１つずつコンパイルされているために、エンジンの他のエレメントを妨害することなく、容易にアップグレードが可能なモジュラ・システムを保持しつつも、コンパイルされたソフトウェアの処理の速さを実現している。
【０１０４】
パース／ビルド・エンジン１００４は、識別されたスキーマをロードし、スキーマと関連するハンドラの機能を起動する。ハンドラは、次いで、メッセージのフィールドをＩＭＦオブジェクトにパースする。
【０１０５】
まだロードされていないスキーマおよび関連する任意のハンドラについては、スキーマ・ローダ１０２４を使用して、スキーマ定義ファイル１０２６からスキーマ・テーブル１０２８およびハンドラ・テーブル１０３０へロードすることができる。スキーマ・テーブル１０２６は、スキーマ名１、スキーマ名２からスキーマ名Ｎと表記された多様なスキーマを含んでいる。パース／ビルド・エンジン１００４によってパースおよびビルドされ得る各メッセージ形式に関して、対応するスキーマが提供され得る。各スキーマ名は、外部形式でのメッセージ・ストリーム構成である「文法」を定義するスキーマ・オブジェクトと関連している。構成には、フィールド順序、フィールド型、長さ、文字コード、および他の任意あるいは必須のフィールドを含めることができる。新しいスキーマおよびコンパイルされたハンドラについては、パース／ビルド・エンジン１００４を再コンパイルすることなく、パース／ビルド・エンジン１００４によってロードおよび使用することができる。
【０１０６】
（パース／ビルドフロー）
ここでフローの一例を説明する。図１１に示されているように、メッセージを受信すると、ビジネス・サービス・プログラムがパース／ビルド・エンジン１００４を呼び出す。メッセージ１０１０（ワイヤ形式のメッセージ・ストリーム）がパース／ビルド・エンジンへ送信され、ここでは、まずパーサ構成要素１０１６によって受信される。ビジネス・サービス・アプリケーションは、パーサ構成要素１０１６へ、スキーマ名１０１１も提供する。パーサ構成要素は、内部メッセージ形式（ＩＭＦ）のオブジェクトを作成し、その中に、メッセージ・フィールドから得られる値を、それがＩＭＦへ変換され次第、保存する。一実施形態では、パーサ構成要素１０１６が、メッセージ１０１０の起点を認識し、この起点から送信されたメッセージ１０１０にはどのスキーマが必要であるかを判断する。別の実施形態では、メッセージ１０１０内の情報がパースされて、使用すべきデータ形式、ひいては対応するスキーマを、判断することができる。さらには、メッセージ１０１０が、データ形式に対応するスキーマがどれであるかを指摘してもよい。
【０１０７】
一例では、パーサ構成要素１０１６が、ＩＳＯ８５８３の金融メッセージなど検出されたメッセージの形式に対応するルート・スキーマをまず検索する。ＩＳＯメッセージなどは、最初にビットマップを有し、どのフィールドが存在するかを特定していることがある。ルート・スキーマは、ハンドラを指し示し、このハンドラが呼び出されてタイプ・フィールドをパースし、どのようなタイプのメッセージが受信されたのか（例えば、承認メッセージ、調整メッセージなど）を判断する。パーサ構成要素は、次に、特定されたメッセージ・タイプ用のスキーマを検索し、スキーマが、今度は、特定の文法を提供し、そのメッセージ・タイプ用のハンドラを指し示す。スキーマおよびハンドラは、メッセージ中に実際に存在するフィールドに関するものだけが検索され呼び出される。新たにフィールドが特定または示唆されると、新たにスキーマが検索され、対応するハンドラが呼び出されることが可能になる。特定のフィールドを１つ以上の条件を備えた複合型のフィールドとすることも考えられ、条件の変換またはパースをすることにより、条件の結果に応じて、付加的なスキーマおよび必要な関連スキーマを指し示すことが可能となる。
【０１０８】
ＩＭＦオブジェクト１０１８（後にさらに詳述する）は、呼び出されたハンドラによって埋め込みが行われる。埋め込みされているフィールドのみが、着信メッセージに含まれているフィールドと対応するフィールドである。
【０１０９】
ＩＭＦオブジェクト１０１８は、次に、ゲートウェイ１０４のビジネス・ソフトウェア・アプリケーションによって処理され得る。処理された後で、ＩＭＦオブジェクト１０１８は、アウトバウンド・メッセージ・ストリーム用のスキーマ名と共に、ビルダ構成要素１０２０へ送信される。処理済みのＩＭＦオブジェクト１０１８の処理は別のデータ形式で実施され得るので、ビルダ構成要素１０２０が、処理済みのＩＭＦオブジェクト１０１８から出力メッセージ・ストリーム１０１２をビルドするように構成されている。前述の処理が逆順に繰り返され、そこでは、ビルダ構成要素１０２０がルート・スキーマを検索し、何度も繰り返され得る処理において、タイプの情報をビルドするために指し示されたハンドラを呼び出す。呼び出されたハンドラは、ＩＭＦオブジェクト１０１８の中にある値をフィールドに組み込み、これが出力メッセージ・ストリーム１０１２に含まれるようになる。出力メッセージ・ストリーム１０１２は、次に、出力メッセージ・ストリーム１０１２を処理することのできるシステム１００８へ送信され得る。
【０１１０】
図１２はゲートウェイ１０４によって提供される任意のサービスを実施するのにＩＭＦオブジェクトを使用するビジネス・サービス・アプリケーション１１０２を説明している。ビジネス・サービス・アプリケーション１１０２はＩＭＦオブジェクト１０１８に対して動作する。この動作には、メッセージの送信先のイシュア銀行あるいは処理センタを判断するなど、アプリケーション層のルーティングを含めることができると考えられる。加えて、メッセージ・ストリームのアプリケーション・レベルのフォーマット、ロギング、タイムスタンピング、応答またはさらなる処理に必要な新しいフィールドの作成など、メッセージに対してサービスを実施してもよい。ビジネス・サービス・アプリケーションは、イシュアまたは金融ネットワークに関する前処理を行うことが可能と考えられ、あるいは負荷を分担している局所の処理を実施することも可能と考えられる。例えば、５０ドルより小額の購入に対する承認メッセージが、承認を求めて金融機関へメッセージを転送する必要を伴わずに許可され、応答メッセージが送信され得る。ビジネス・サービス・アプリケーション１１０２は、外部形式ではなく内部メッセージ形式でデータを処理するように構成されている。故に、ビジネス・サービス・アプリケーション１１０２は、メッセージをＩＭＦにパースすることにより、他のシステムによって使用されているあらゆる外部形式から隔離されている。
【０１１１】
（ＩＭＦ構造）
図１３Ａは、本発明の一実施形態によるＩＭＦ１０１８の構造を表している。図示されているように、ＩＭＦ１０１８には、Ｎ個のフィールドが設けられている。フィールドは、フィールドの配列であってもよく、ここでは各フィールドが不特定多数の子フィールドを含むこともでき、ひいては孫フィールドなどを階層型構造で含むこともできる。例えば、フィールド１は、子フィールド１．１、１．２、から１．Ｎを含んでいる。フィールド１．２から１．Ｎが、さらに、不特定多数の子フィールド（図示せず）を含むこともできる。メッセージを受信すると、実際に使用されているフィールドだけにデータが埋め込まれる。
【０１１２】
図１４Ｂは、図１３Ａに示されているフィールドのフィールド定義についてのインデックスであるオブジェクトＩＤコードに関する階層化された形式を示している。ＯＩＤにより、ＩＭＦオブジェクト１０１８内の多様なフィールドをインデキシングすることができる。ＩＭＦオブジェクト１０１８内のフィールドに関して、ＯＩＤを使用してフィールド定義へアクセスする。一実施形態では、ＯＩＤが８バイトの番号であって、図のようにドット付き１０進表記で表されている。第１フィールドのＯＩＤは、１．０．０と符号化されている。任意のサブフィールドについて、１．１．０、１．２．０などと符号化される。第２フィールドは２．０．０と符号化され、２．１．０、２．２．０などと符号化される任意のサブフィールドを伴う。
【０１１３】
（スキーマ構造）
図１３Ｂはスキーマの例を示している。スキーマのアドレスは、第１行目であり、メッセージの定義（ＭｅｓｓａｇｅＤｅｆ）である。スキーマには、メッセージ内の各フィールドに関する、文法およびハンドラへのポインタを含んでいる。図示されている例では、メッセージの第１フィールドは、インデックス１．０．０を伴うＦｉｅｌｄ Ｄｅｆｉｎｉｔｉｏｎ Ｏｂｊｅｃｔ（ＦｉｅｌｄＤｅｆ）１２０２で特定される。これを、ＯＩＤ属性１２０２とも称する。このフィールドのインデックスに続くのは、呼び出されるハンドラ１２０４（ＨＤＲ）の識別表示である。その行の残りのエレメントは、その特定のフィールドに関する文法の定義である。これらのフィールド定義は、フィールド順序、フィールド型、長さ、文字コード、必要なハンドラ名などのフィールドの特性を述べている。フィールド定義は、ＡＳＣＩＩ、ＥＢＣＤＩＣ、ＢＣＤなどの様々なコード、および数字、文字列、バイト配列などの様々なデータ型で符号化されているフィールドを、パース／ビルドするのに使用され得る。故に、メッセージ定義を使用して、複数の形式のメッセージ・ストリームを処理することができる。一実施形態では、スキーマは、ＸＭＬスキーマの形をとったメタデータである。
【０１１４】
フィールド定義には、多くの属性を含めることができる。当然のことながら、図１３Ｂに表されている属性は網羅的なものではなく、他の属性を使用してもよいことが当業者には十分理解されよう。
【０１１５】
ハンドラ属性１２０４は、フィールド名である。必須／任意属性１２０６はメッセージ内でフィールドが必須あるいは任意のいずれであるかを示す。第１データ形式属性１２０８は、外部形式（ワイヤ形式とも称される）でのフィールド値のデータ形式である。第２データ形式属性１２１０は、フィールドがＩＭＦで保存されビジネス・サービスによって処理される、内部形式である。
【０１１６】
カスタム／非カスタム属性１２１２は、フィールドがカスタム・ハンドラあるいは汎用ハンドラのいずれを使用してフィールドのパースおよびビルドを行うかを示す。
【０１１７】
第７の属性１２１４は、メッセージのフィールド内の値を処理するのに必要なハンドラ名を示す。ハンドラは、受信メッセージ内の識別されたフィールドの値を取り込み、それを（パーサ・スキーマ用に）ＩＭＦにパースするか、あるいは値を（ビルダ・スキーマ用に）ＩＭＦから外部形式へビルドするかのいずれかを行う。
【０１１８】
第８の属性１２１６は、フィールド内のサブフィールド数を示す。
【０１１９】
（ＩＭＦ（内部メッセージ形式）で使用されるメッセージ・フィールド例）
図１４Ａは、特定のメッセージ・オブジェクト１０１０に使用されるフィールドの例を表しており、これは、様々なフィールド用のいくつかのオブジェクトＩＤ（ＯＩＤ）、すなわちＯＩＤ１．０．０、１．１．０、１．１．１、２．０．０、２．２．０、４．０．０、および４．１．０を含んでいる。これらは、図１３Ｂのスキーマによって指し示されているフィールドである。従って、このメッセージ例に関しては、図１３Ａで示されているメッセージ・オブジェクトの中で、図１４Ｃで特定されているフィールドだけが埋め込みされると考えられる。図１４Ｂは、内部メッセージ形式での完全な一式のフィールド用の階層型オブジェクトＩＤ全体の一部分を示している。図に示すように、メッセージ１０１０は、これらのフィールドのうち、自分が必要とする一部分のみを含んでいる。例えば、オブジェクトＩＤ１．２．０、３．０．０、および４．２．０は使用されていない。なお、これらのフィールドが不特定多数の子フィールドを有してもよい。
【０１２０】
オブジェクトＩＤは、図１３Ａに示されているメッセージ・オブジェクトの階層型内部メッセージ形式への、高速インデキシング・システムを提供する。このインデキシング・システムは、符号化されたオブジェクトＩＤ（１．０．０など）を使用しており、これらが、受信された形式で使用されている各フィールドに関して、内部メッセージ形式の対応するフィールドへインデックスする（対応するフィールドを指し示す）。インデックスは、階層型構造の中で数層下にあるフィールドを、直接指し示すことができる。
【０１２１】
ゲートウェイ１０４の構成要素がＩＭＦオブジェクト１０１８を処理するとき、不要なフィールドの処理は実行しない。従って、処理速度が速まる。
【０１２２】
ＩＭＦオブジェクト１０１８へ必要なフィールドを追加することもできる。何らかのフィールドが、ビジネス・サービス・モジュール１１０２またはトランザクション処理装置１０８によって要求され得る。使用する必要のあるフィールドが受信メッセージ１０１０に含まれていないと判断されたら、このフィールドをビジネス・サービス・モジュールによって埋め込み、再送信用にビルドされるメッセージの中へ含ませることができる。従って、図１３Ｂのスキーマにある「必要な」フィールドがメッセージ１０１０に含まれていない場合、ＩＭＦオブジェクト１０１８へ追加され得る。
【０１２３】
（パース／ビルド・エンジンの初期化）
図１５は、ビジネス・サービス・アプリケーションの開始にあたってパース／ビルド・エンジン１００４を初期化する方法の簡略化されたフロー図１４００を表している。ステップ１４０２で、アプリケーションから初期化要求を受信する。要求には、１つ以上のスキーマ定義ファイル１０２６の場所が含まれている。
【０１２４】
ステップ１４０４で、スキーマ定義ファイル１０２６内に見つかったスキーマの確認が行われる。スキーマの確認は、正しい型のデータが示されていること、スキーマによって特定されたハンドラが実際に存在することの検証など、多数の手続きによって行われる。
【０１２５】
ステップ１４０６では、スキーマ定義ファイル１０２６内のスキーマが、ディスクまたは他の記憶収納庫からＤＲＡＭメモリへと、スキーマ・ローダ１０２４を使用して、レジストリ１０２２へロードされる。
【０１２６】
ステップ１４０８で、スキーマで指定されているあらゆるハンドラをレジストリ１０２２へロードする。例えば、メッセージ定義オブジェクトのフィールド定義によって指定されているハンドラは、ハンドラ・テーブル１０３０へロードされる。一実施形態では、ハンドラが、ハンドラ名をキーに使い、オブジェクトとして保存される。
【０１２７】
ステップ１４１０で、ハンドラは、それぞれのメッセージ定義オブジェクトにバインドされる。例えば、或るメッセージ定義オブジェクト内のフィールド定義によって指定されているハンドラは全て、そのメッセージ定義オブジェクトにバインドされる。
【０１２８】
パース／ビルド・エンジン１００４は、今や、スキーマ用に初期化されている。一実施形態では、パース／ビルド・エンジン１００４のコンパイルが必要ではない。これは、フィールド値のパース／ビルドに用いられているコンパイル済みのハンドラを使用しているからである。
【０１２９】
ランタイムで、スキーマは、動的に更新され、パース／ビルド・エンジン１００４へ追加され得る。スキーマは、メッセージ定義オブジェクトを変更することによって更新され得、あるいは新しいメッセージ定義オブジェクトを追加することによって追加され得る。新しくハンドラが必要となる場合にも、コンパイル済みのオブジェクトとして、パース／ビルド・エンジン１００４へ動的に追加され得る。
【０１３０】
スキーマは、パース／ビルド・エンジン１００４を再コンパイルすることもなく、機能停止させることもないままで、追加することが可能である。従って、パース／ビルド・エンジン１００４は、スキーマが更新されている間であっても、メッセージのパース／ビルドを継続することができる。
【０１３１】
（スキーマの追加または更新）
図１６は、本発明の一実施形態によるパース／ビルド・エンジン１００４内のスキーマを動的に追加または更新する方法の簡略化したフロー図１５００を表している。ステップ１５０２で、スキーマを動的に追加または更新するよう求める要求をアプリケーションから受信する。要求には、新しいあるいは更新されたスキーマを含んでいる１つ以上のスキーマ定義ファイル１０２６の場所が含まれている。
【０１３２】
ステップ１５０４で、スキーマ定義ファイル１０２６内に見つかったスキーマの確認が行われる。
【０１３３】
ステップ１５０６で、スキーマ定義ファイル１０２６内のスキーマが、レジストリ１０２２へロードされる。更新されたスキーマが、一連の新しいフィールド定義または変更されたフィールド定義を備えている場合は、新しいまたは変更されたフィールド定義のみをレジストリ１０２２へロードすればよい。スキーマの追加または更新を行っている間、適切なデータ構造には書き込みロックをして、スキーマ変更の結果、処理中のインフライト・メッセージが破損することのないように保護する。スキーマ・ローダ１０２４がスキーマの更新されたバージョンをロードしている間は、インフライト・メッセージは、引き続き以前のバージョンのスキーマを使用する。
【０１３４】
ステップ１５０８で、メッセージ定義オブジェクトで指定されているあらゆるハンドラがレジストリ１０２２へロードされる。パース／ビルド・エンジン１００４が、いずれかのハンドラが既にレジストリ１０２２内にあるかどうかを確認して判断し、これらのハンドラについてはレジストリ１０２２へ再ロードしなくてもよい。その一方で、いずれかのハンドラが変更されていたら、変更されたハンドラがロードされる。
【０１３５】
ステップ１５１０で、ハンドラはそれぞれのメッセージ定義オブジェクトにバインドされる。一実施形態では、新しいまたは変更されたハンドラだけが、更新されているメッセージ定義オブジェクトにバインドされる。今や、パース／ビルド・エンジン１００４は動的に更新されている。
【０１３６】
（パース処理のフロー図）
図１７は、本発明の一実施形態に従って入力メッセージ・ストリーム１０１０をパースする方法の簡略化したフロー図１６００を表している。ステップ１６０２で、メッセージ用のスキーマが決定される。スキーマは、入力メッセージ・ストリーム１０１０を構成しているデータ形式に対応している。
【０１３７】
ステップ１６０４で、スキーマ内のポインタからメッセージ定義オブジェクト用のあらゆるハンドラが決定される。
【０１３８】
ステップ１６０６で、各フィールド用のハンドラがフィールドに添付される。
【０１３９】
ステップ１６０８で、ハンドラが、メッセージのフィールドを変換する。各フィールド用のハンドラが起動される。ハンドラは、スキーマ内のフィールド定義を使用して、フィールドの値をＩＭＦへ変換する。フィールドのＯＩＤは、スキーマ内のそのフィールド用のフィールド定義と、さらにＩＭＦオブジェクト１０１８内の対応するフィールドとの両方を指し示す。
【０１４０】
一実施形態では、パーサ構成要素１０１６が、メッセージ１０１０で読み取られたフィールドのオフセットを維持管理する。例えば、読み取られたバイトの数が、オフセットとして保存される。パーサ構成要素は、各ハンドラが呼ばれるのに従い、このオフセットを減らしてゆく。ハンドラがメッセージ１０１０の終わりに達すると（例えば、オフセットが或る特定の長さに等しくなると）、あるいはメッセージ定義オブジェクト内の最後のフィールド定義に達すると、パーサ構成要素は、変換が完了したことを認識する。
【０１４１】
ステップ１６１０で、変換されたフィールドは、ＩＭＦオブジェクト１０１８の対応する階層に保存される。フィールドのＯＩＤを使用して、変換された値をＩＭＦオブジェクト１０１８の階層内の対応する位置に保存すればよい。
【０１４２】
上述の変換をいずれかの点で失敗した場合は、エラーをゲートウェイ１０４へ返送し得る。パースは継続し得、ＩＭＦオブジェクト１０１８が返送され得る。ただし、ＩＭＦオブジェクト１０１８内にエラー・フラグが記録され得る。
【０１４３】
（ビルド・プロセスのフロー図）
ここで図１８に関連してビルドプロセスを説明する。図１８は、本発明の一実施形態に従って出力メッセージ・ストリーム１０１２をＩＭＦオブジェクト１０１８からビルドする方法の簡略化したフロー図１７００を表している。ステップ１７０２で、スキーマ名およびＩＭＦオブジェクト１０１８が決定される。一実施形態では、ＩＭＦオブジェクト１０１８が最初に決定される。スキーマ名は、ＩＭＦオブジェクト１０１８内の情報に基づいて決定され得る。例えば、スキーマ名が、ＩＭＦオブジェクト１０１８内の情報に保存され得る。さらに、スキーマ名は、ＩＭＦオブジェクト１０１８内の情報が送信される通信路または宛て先システムによって決定され得る。
【０１４４】
ステップ１７０４で、メッセージ定義オブジェクトを使用して、レジストリ１０２２内のスキーマにアドレスする。ステップ１７０６で、スキーマに必要なあらゆるハンドラについても決定される。
【０１４５】
ステップ１７０８で、ＩＭＦオブジェクト１０１８内に見つかった各フィールドに関して、ＩＭＦオブジェクト１０１８の階層内の対応するフィールドから得られる値がロードされる。フィールドのＯＩＤを使用して、フィールド定義にアクセスする。
【０１４６】
ステップ１７１０で、ＩＭＦオブジェクト１０１８のフィールドから、このフィールド用のフィールド定義の属性に従って、値を変換する。従って、ＩＭＦ形式で見つかった値が、他のシステムと互換性のある形式へと変換される。
【０１４７】
ステップ１７１２で、ビルドされた値が、生成された出力メッセージ・ストリーム１０１２の対応するフィールド内に構成される。
【０１４８】
外部形式に必要な或るフィールドに対する、ＩＭＦオブジェクト１０１８内のフィールドの値が見つからない場合、外部メッセージ内のそのフィールドの値は空値に設定されてもよく、または生成されたメッセージが単にメッセージ内にこのフィールドを有さないようにしてもよい。さらに、ＩＭＦオブジェクト１０１８がこのフィールドを有する必要があると決定されていたら、その場合はＩＭＦオブジェクト１０１８内にフィールドが見つからなかったことを示すエラーが返信されればよい。
【０１４９】
本発明の実施形態は、多くの利点を提供する。例えば、アプリケーション・レベルの内容、ネットワーク伝送環境の現状、および／または設定情報の組み合わせを使用して、トランザクションをインテリジェントに切り替えることができる。このことは、クライアントによって送信されるあらゆるトランザクションに価値を付加することになる。例えば、ネットワークまたはトランザクション処理装置において何らかの障害がある場合、トランザクションを、他のネットワークを経由させて他のトランザクション処理装置へ送ることができる。これにより、ダウンタイムおよびトランザクション上の何らかの損失が回避される。
【０１５０】
さらに、アプリケーション・レベルの内容対してビジネス・サービスを適用することができる。これにより、ゲートウェイ１０４に関する柔軟性が高まり、トランザクションをインテリジェントにルーティングすることができるようになる。例えば、データ処理装置１０８が、様々な形式のトランザクションを処理することができる。ゲートウェイ１０４が、トランザクション処理装置に必要とされる形式に基づいてアプリケーション・レベルの内容の形式を変更するように構成され得る。さらに、トランザクションに対して適用することのできるビジネス・サービスにより、ゲートウェイ１０４が、多数の形式またはプロトコルでトランザクションを受信し得る。例えば、無線トランザクション支払、インターネットトランザクション、ＰＯＳトランザクションなどについて処理し得る。これにより、トランザクションの処理における柔軟性を高めることができる。
【０１５１】
本発明の実施形態について、トランザクション処理およびある場合には金融トランザクションとして説明してきたが、当然のことながら、トランザクションは多種多様な領域に関して処理され得る。例えば、音楽共有サービスに関してトランザクションを処理し得る。トランザクションには、音楽のダウンロード要求などが含まれ、続いて、ゲートウェイ１０４がこの要求についてサービス・プロバイダへのインテリジェントな切り替えを行い、要求された内容をクライアントへ送り返し得る。さらに、映像サービスが提供されてもよい。映像の要求は、オンデマンド方式であれペイ・パー・ビュー方式であれ、ゲートウェイ１０４によって受信および処理することができる。リクエストおよびそれに続くダウンロードが、本発明の実施形態に従ってインテリジェントに切り替えられ得る。
【０１５２】
本発明は、制御論理の形で、ソフトウェアまたはハードウェアあるいは両方の組み合わせの中に実装することができる。制御論理は、本発明の実施形態の中で開示された一連のステップ群を情報処理デバイスに実行させるようになっている複数の命令として、情報記憶媒体に保存され得る。本明細書に記載された開示および教示に基づき、当業者には、本発明を実施する他の手段および／または方法についても理解されよう。
【０１５３】
上記の説明は、例示的なものであって、限定的なものではない。開示を検討すれば、本発明には多数の変形例があることが当業者には明らかとなる。故に、本発明の範囲は、上記の説明に準拠して判断されるべきではなく、出願の請求項に準拠して、包括的にあるいは均等物も加えて、判断されるべきである。
【図面の簡単な説明】
【０１５４】
【図１】図１は本発明の一実施形態によるトランザクションを処理するシステムを表す。
【図２】図２は本発明の一実施形態によるゲートウェイのさらに詳細な実施形態を表す。
【図３】図３は本発明の一実施形態によるトランザクションを処理する方法の簡略化したフロー図を表す。
【図４】図４は本発明の一実施形態によるトランザクション処理装置によって提供されるサービスに関する設定情報の生成の簡略化したフロー図を表す。
【図５】図５は本発明の一実施形態によるサービスに加入する方法の簡略化したフロー図を表す。
【図６】図６は本発明の一実施形態による複数のゲートウェイの分散型システムを表す。
【図７】図７は本発明の一実施形態によるゲートウェイをフロントエンド・ゲートウェイとして表示しているシステムを表す。
【図８】図８は本発明の一実施形態によるゲートウェイがインターネット・ゲートウェイであるシステムを表す。
【図９】図９は本発明の一実施形態によるゲートウェイが無線ゲートウェイとして使用されているシステムを表す。
【図１０】図１０は本発明の一実施形態によるＩＳＯ８５８３トランザクションを処理するシステムを表す。
【図１１】図１１は本発明の一実施形態によるメッセージをパースするシステムを表す。
【図１２】図１２は本発明の実施形態によるゲートウェイの一実施形態を開示している。
【図１３Ａ】図１３Ａは本発明の一実施形態によるＩＭＦオブジェクトの構造を表す。
【図１３Ｂ】図１３Ｂは本発明の一実施形態によるメッセージ定義の属性を表す。
【図１４Ａ】図１４Ａ、１４Ｂおよび１４Ｃは、本発明の一実施形態による考え得るメッセージ、オブジェクトＩＤコードの階層化された形式、およびメッセージ用のＩＭＦオブジェクトを表す。
【図１４Ｂ】図１４Ａ、１４Ｂおよび１４Ｃは、本発明の一実施形態による考え得るメッセージ、オブジェクトＩＤコードの階層化された形式、およびメッセージ用のＩＭＦオブジェクトを表す。
【図１４Ｃ】図１４Ａ、１４Ｂおよび１４Ｃは、本発明の一実施形態による考え得るメッセージ、オブジェクトＩＤコードの階層化された形式、およびメッセージ用のＩＭＦオブジェクトを表す。
【図１５】図１５は本発明の一実施形態によるメッセージ・ストリームを処理するパース／ビルド・エンジンを初期化する方法の簡略化したフロー図を表す。
【図１６】図１６は本発明の一実施形態によるパース／ビルド・エンジンにおいてスキーマを動的に追加または更新する方法の簡略化したフロー図を表す。
【図１７】図１７は本発明の一実施形態による入力メッセージをパースする方法の簡略化したフロー図を表す。
【図１８】図１８は本発明の一実施形態によるＩＭＦオブジェクトから出力メッセージをビルドする方法の簡略化したフロー図を表す。
【技術分野】
【０００１】
（関連出願の引用）
本出願は、同時に出願された「ＳＣＨＥＭＡ−ＢＡＳＥＤ ＤＹＮＡＭＩＣ ＰＡＲＳＥ／ＢＵＩＬＤ ＥＮＧＩＮＥ ＦＯＲ ＰＡＲＳＩＮＧ ＭＵＬＴＩ−ＦＯＲＭＡＴ ＭＥＳＳＡＧＥＳ」と題する米国特許出願第＿＿＿＿＿号（代理人事件Ｎｏ．１６２２２Ｕ−０２０３００ＵＳ）と関連し、該出願はあらゆる目的において参照により本明細書に引用される。
【０００２】
本発明は、一般的に電気通信に関し、特に、トランザクションの内容、伝送環境に関する動的状況情報、および／またはトランザクション切り替えの動的ルールに基づいてアプリケーション・レベルでインテリジェントにトランザクションを切り替える技術に関する。
【背景技術】
【０００３】
クレジット・カード承認、デビット・カード取引、電子小切手取引などのトランザクションをクライアントにて実行するとき、クライアントは、トランザクションをサービス・プロバイダへ送信する。サービス・プロバイダは、クレジット・カード承認、トランザクション決済などのサービスをクライアントへ提供する。通常、クライアントは、処理を行うために、トランザクションをサービス・プロバイダのトランザクション処理装置へ送る。トランザクションは、各種ネットワークを経由して送ることができる。各種ネットワークは、本質的に異なっていてもよく、信頼性があってもなくてもよい。
【０００４】
通常、トランザクションは、迅速な応答および高い信頼性を必要とする。例えばユーザが、クライアントを用いてクレジット・カード取引を実行している場合がある。このトランザクションでは、クレジット・カード承認要求を処理するのに、トランザクション処理装置へ送信することが必要になることがあり、それによりトランザクションの承認を容易にすることができる。トランザクションが経由して送られる各種ネットワークのうちの１つ、あるいはこのクライアントに関するトランザクションを処理するのに使用されているトランザクション処理装置が機能しなかったために、トランザクションが失敗、あるいは遅延することがある。何らかの障害が生じると、クライアントは、トランザクションおよびトランザクションの完結から得られるいかなる利益をも失う危機にさらされる。
【０００５】
従来、トランザクションは、一連のパケットに分割され得る。本発明の実施形態は、アプリケーション・レベルでトランザクションに対して動作しており、これに対して、先行技術の多くはネットワーク・レベルでルーティングを行い、パケットに対して動作することを提示している。個別のパケットそれぞれについて、パケット・レベルでルーティングしてもよく、またはヘッダの情報などパケット内の情報に基づいてルーティングすることもできる。以下の特許は、（本発明の実施形態のアプリケーション・レベルの切り替えとは対照的に）パケットのネットワーク・レベルのルーティングについて記載している。ＩＢＭの特許第５，９７４，４６０号では、データをダウンロードするのに、インターネット上の多数のミラー・サイトのうち、まずどのサイトが、サイト選択の時点で最速の転送速度を示すかを判断することによって、１つを選択することを記載している。ＤＥＣの特許第５，３４１，４７７号も類似している。Ａｌｃａｔｅｌの特許第５，７５４，５４３号は、送信費用を考慮しながら行うネットワーク上のルーティングについて記載している。送信費用を考慮している他の特許としては、特許第６，５３５，４８８号、およびＮｏｒｔｅｌの特許第６，４８７，２８６号がある。ＤＥＣの特許５，４５９，８３７号は、ネットワーク全域にわたってサーバの動作を監視し、要求を処理するのに一番大きい帯域幅を有するサーバはどれかを判断するシステムを提示している。Ｃａｂｌｅｔｒｏｎ Ｓｙｓｔｅｍｓの特許第５，５２１，９１０号は、パケットを正規のフレーム形式で示し、さらにネットワークを介した最良の経路を各種メトリックを用いて判断することを示している。特許第６，８３９，７００号は、文書の生成費用に基づき、内容要求の負荷分散について記載している。特許第６，７５４，１８８号は、パケットの内容に基づき、すなわちそれが音声、映像、またはファイル転送のいずれであるかに基づいて、パケットをルーティングすることを記載している。
【０００６】
特許文献１（ＩＢＭの米国特許）は、ＯＳＩモデルの最初の三層を備えたネットワーク処理装置を示している。第４以上の層にアクセスしてフロー制御し、サービスの質に基づいてルーティングを決定する処理装置が、特許文献２（Ｔｏｐ Ｌａｙｅｒ Ｎｅｔｗｏｒｋｓの米国特許）に示されている。これにより、優先順位に基づく電子メールと、帯域幅保証に基づくマルチメディアとを区別できるようになる。
【０００７】
Ｉｎｔｅｌの特許第６，７３２，１７５号は、ビジネストランザクション（例えば、購買注文など）の種類を判断するべくパケットの内容について考察し、その種類のサービスを処理するのに適切なサーバへトランザクションを転送することに基づく、ネットワークにおける切り替えについて示している。上記のことが行われるのは、メッセージが宛て先のウェブ・サイトへネットワークを通じて送信された後であり、ネットワーク上に送信される前ではない。宛て先サーバにおいて内容に基づきメッセージをルーティングするシステムには多数の例があり、例えばインテリジェントな負荷分散装置が挙げられる。Ｄｉｅｂｏｌｄの特許第６，３０２，３２６号は、金融メッセージを共通の形式へ変換し、その後システム内の適切なプログラムへ送ることを示している。ＥＤＳの特許第５，８０５，７９８号は、金融処理サーバの状態を監視して、利用不能になった場合にはメッセージをバックアップへ送るネットワーク・ノードを記載している。
【特許文献１】米国特許第６，４６０，１２０号明細書
【特許文献２】米国特許第６，４３０，１８４号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記の特許は、個別のパケットをパケット・レベルでルーティングするか、または静的ルールに基づいてデータをルーティングするかのいずれかに焦点を当てている。これは、パケットの効率的なルーティングを提供することはできるが、一方で、伝送環境の動的状況、および動的ルールに基づいてアプリケーション・レベルでトランザクションを切り替えることに対しては対応していない。加えて、いずれの処理装置にするかの選択を、通常は負荷分散装置などの様に、ネットワークと宛て先との間のノードで行っている。従って、アプリケーション・レベルでトランザクションをインテリジェントに切り替える技術が提供されることが望ましい。
【０００９】
アプリケーション・レベルにおける現行の技術では、クライアントが、アプリケーション・レベルでの相互作用に対処することが必要である。クライアントは、トランザクション処理装置における変更に応じてソフトウェア・システムを変更する必要があり、さらに様々なトランザクション処理装置によって求められている様々なメッセージ形式をサポートすることも必要である。クライアントは、さらにサーバ・システムおよびネットワーク上の障害に対処し、クライアントのユーザに継続的な動作を提供するために代替的なサーバ処理装置へフェイルオーバするように対処することも必要とされる。
【課題を解決するための手段】
【００１０】
（発明の概要）
本発明の実施形態は、一般にトランザクションのアプリケーション・レベルの内容、伝送環境の動的状況情報、および／またはトランザクション切り替えの動的ルールに基づいて、アプリケーション・レベルでトランザクションを切り替えることに関する。ネットワークのクライアント・エッジにアプリケーション・ルータが設けられ、（１）アプリケーション・レベルの情報に基づいてインテリジェントなルーティングを提供し、（２）サーバへ転送する前に処理サービスを実施し、あるいは（３）サーバへ送ることをせずに、回答をクライアントへ返送するという負荷を分担するサービスを実施することができる。
【００１１】
一実施形態において、トランザクションのインテリジェントな切り替えが提供される。クライアントが、ゲートウェイへトランザクションを送信し、このゲートウェイは、次にトランザクションをトランザクション処理装置へインテリジェントに切り替えるように構成されている。ゲートウェイは、アプリケーション・レベルの内容、伝送環境の現状、および／またはトランザクションの切り替えに関する動的ルールに基づいて、トランザクションを切り替えるように構成されている。例えばいくつかの考え得るサービス・プロバイダをトランザクションの種類向けに選択することができ、ゲートウェイは、考え得る別々のサービス・プロバイダへのネットワーク（単数または複数）を介した往復時間のみでなく、サービス・プロバイダがアプリケーション・レベルでトランザクションを完了し回答を返送するのに必要とする時間についても、監視することができる。
【００１２】
本発明の実施形態による切り替えは、ネットワークの受信側ではなく、送信側において行われる。トランザクションは、特定のネットワークをわたってルーティングされるようにフォーマットされているだけではなく、ネットワークの宛て先にある特定の処理装置によって処理されるようにフォーマットされており、このようなフォーマットを受信ノードで行うのではない。従って、ネットワーク（単数または複数）の送信側にあるノードが、ネットワーク（単数または複数）の受信側にある処理装置のワークフローに関する情報を有している。一実施形態では、このことが、金融トランザクションの承認に必要な限定された数のフィールドなど、特定のフォーマットの限定された数のフィールドのみを扱うことによって可能かつ実用的となる。一実施形態では、承認を求めて金融トランザクションをルーティングするのに、インターネットと、プライベート金融ネットワークとのいずれかを選んでルーティングする。一方で、本発明の実施形態は、音楽、映像などの発注および配信など、あらゆる種類のトランザクションまたは内容に適用することができる。
【００１３】
一実施形態では、アプリケーション・レベルのサービス・プロバイダが、ネットワーク（単数または複数）上で自分たちのサービスを発行、通知、または登録することができる。本発明の実施形態によるゲートウェイが、これらの発行されたサービスの全てまたは選択されたものを、受信して保存することができる。ゲートウェイは、イシュアが信用のある事業体（登録されている銀行または売買業者など）であることを検証し、イシュアのサービスが、ゲートウェイのクライアント（単数または複数）のトランザクションに関係があるかどうかを判断する。サービスは、一日の終わりまで待つこと、あるいは人間のオペレータが介入することを必要とせずに、動的に登録および更新することができる。
【００１４】
一実施形態では、サービス・プロバイダが提供するサービスの保存されている詳細を使用することにより、ゲートウェイが、トランザクションをどのサービスへ向けて送信するかを選択できるだけではなく、サービス・プロバイダに適するように、トランザクションをアプリケーション・レベルでフォーマットすることができる。加えて、トランザクションをネットワークを通じてサービス・プロバイダへ送信する前に、ゲートウェイにて、何らかの事前処理または調整ステップを実施することができると考えられる。あるいは、一部または全ての場合において、サービス・プロバイダから受け取るルールに従って、トランザクション処理を全てゲートウェイにて行うことも可能と考えられる。例えば、或る閾値より低額のクレジット・カード取引については、承認を求めて銀行へ行く必要がないばかりでなく、ネットワークを通じてクレジット・カード会社へ行く必要もないまま、承認することが可能となり得る。
【００１５】
一実施形態では、クライアントが、どのサービス・プロバイダを選択するか判断するためのルールまたは基準を指定することができる。上記のルールまたは基準は、ゲートウェイに保存することができる。これらのクライアント基準については、トランザクションに先立ってロードすることもでき、あるいはトランザクションメッセージが送信される直前または直後にロードすることもできる。
【００１６】
一実施形態では、本発明によるゲートウェイ機能が、多数のゲートウェイへ分配されている。各ゲートウェイは、物理的にはネットワークのエッジ、クライアントのアクセス点に位置し、さらにはクライアントの物理的な構内にあってもよい。ゲートウェイは、接続しているクライアント（単数または複数）に関する情報を保存し、他のゲートウェイが接続しているサービスに関する情報については他のゲートウェイの提供に依存している。これは、ネットワークのパケット送信のために、接続している他のルータからテーブル情報を入手するルータに若干類似しているが、ただし、本発明の実施形態ではアプリケーション・レベルのサービスを扱っているところを別にする。各ゲートウェイは、自分あるいは自分のクライアントが関心のあるブロードキャスト・サービス・プロバイダの情報を保存するだけでよく、それ以外の接続が必要になる可能性もあるとはいえ、それが接続する他のゲートウェイのアドレスを保存するだけでよい。
【００１７】
本明細書に開示されている本発明の性質および利点について、本明細書の残りの部分、および添付の図面を参照することによって、さらに理解することができる。
【発明を実施するための最良の形態】
【００１８】
（処理の概要）
一実施形態において、トランザクションのインテリジェントな切り替えが提供される。トランザクションは、クレジット・カード承認、デビット・カード取引、または電子小切手取引とすることができる。トランザクションのその他の例としては、賞提供企画においてポイントまたは他の報酬を与えること、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａ認証用のパスワードを確認すること、送金を行うこと、Ｖｉｓａ Ｂｕｘｘカードまたは給与カードなどの料金前払い式カードから支払いを引き落とすこと、携帯電話、ページャ、ＰＤＡなどから近接型の支払いを処理すること、健康保険、自動車保険、または他の保険の適用対象範囲を判断することなどが挙げられる。クライアントは、トランザクションをゲートウェイへ送信し、ゲートウェイは、次に、トランザクションをサービス・プロバイダのトランザクション処理装置へインテリジェントに切り替えるように構成されている。クライアントは、ＰＯＳ、ＰＯＳデバイスまたはＥＣＲ（ｅｌｅｃｔｒｏｎｉｃ ｃａｓｈ ｒｅｇｉｓｔｅｒｓ：電子式金銭登録機）とネットワーク接続された売買業者のコンピュータ、キオスク（クーポンまたは資金の転送用など）、インターネット・ウェブ・サイト・サーバなどである可能性がある。
【００１９】
ゲートウェイは、トランザクションのアプリケーション・レベルの内容、伝送環境の現状、および／または動的ルールに基づいて、アプリケーション・レベルにて切り替えを決定するように構成されている。アプリケーション・レベルの内容は、トランザクション処理装置がトランザクションを処理するにあたって処理または使用する情報であり得る。一実施形態では、情報が、ＯＳＩ第７層の情報であり得る。この層は、直接、トランザクション処理装置またはエンド・ユーザに対して機能する。この層には、クレジット・カード承認、デビット・カード取引のアプリケーションなどのアプリケーションが含まれている。アプリケーション層のプロトコルの例としては、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ファイル転送プロトコル）、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ：ネットワーク・ファイル・システム）、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ：インターネット共有ファイル・システム）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ハイパー・テキスト転送プロトコル）、データベース・クエリ、ＳＱＬ（Ｓｔａｎｄａｒｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：標準問い合わせ言語）、およびＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ：拡張マークアップ言語）が挙げられる。例えば、クレジット・カード承認において、アプリケーション・レベルの内容としては、クレジット・カード番号、個人アカウント番号（ＰＡＮ：ｐｅｒｓｏｎａｌ ａｃｃｏｕｎｔ ｎｕｍｂｅｒ）、顧客アカウント番号、トランザクションの総額などが挙げられる。トランザクション処理装置は、トランザクションを処理するためにこの情報を使用すればよい。
【００２０】
伝送環境の現状には、トランザクションを伝送できるネットワークおよびトランザクションを処理できるトランザクション処理装置に関連するリアルタイムの情報が含まれている。リアルタイム情報としては、ネットワークまたはトランザクション処理装置の健康状態、ネットワークまたはトランザクション処理装置の利用可能性、トランザクション処理装置のアプリケーション処理速度などを挙げることができる。
【００２１】
動的ルールは、トランザクションのインテリジェントな切り替えの方法を決定するのに使用される情報であり得る。ルールは、アプリケーション・レベルの内容および伝送環境の現状に従ってトランザクションを切り替えるのに使用される。例えば、ルールは、或る特定のアプリケーション・レベルの内容および伝送環境の現状に応じて、サービス・プロバイダの提供する或る特定のサービスが選択されるように指定することができる。さらに、ルールを使うと、サービス・プロバイダがトランザクションを処理するトランザクション処理装置を選ぶことができる。例えば、或る特定の国が国内トランザクション用に局所的な処理を必要とすることがあり、故に局地的な処理センタへのルーティングを必要としている場合がある。これらのルールは、選択をするために、ネットワーク費用、サービス費用などの静的な情報も考慮に入れている。ルールは、ゲートウェイを停止させることなく、動的に変更することができる。
【００２２】
ゲートウェイは、ルールに従って、トランザクションに対するサービスを実施することもできる。サービスには、アプリケーション・レベルの内容を処理することも含まれ得る。例えば、トランザクション処理装置が、様々な形式でトランザクションを処理するように構成されているとよい。選択された処理装置が、トランザクションにおける現在のアプリケーション・レベルの内容とは異なる形式のアプリケーション・レベルの内容を処理するように構成されていることもある。従って、ゲートウェイが、アプリケーション・レベルの内容を新しい形式へ変更するとよく、よって選択されたトランザクション処理装置がそれを処理することができるようになる。故に、ゲートウェイは、アプリケーション・レベルにて、トランザクションにある情報を変更することがある。このことは、パケット・レベルで情報を見直すこととは異なる。従来、トランザクションはパケットに分割することがあり得る。ルータは、パケット内の情報を見て、適宜パケットをルーティングすることができる。しかし、パケット・レベルで情報を見ることでは、ルータが、トランザクションのアプリケーション・レベルの内容を使用してサービスを実施できるようにはならない。例えば、トランザクション全体に関するアプリケーション・レベルの内容を見ることによって、このトランザクションが、トランザクションに適用される適切なサービスを受けてインテリジェントにルーティングされることが可能となる。トランザクションに関する情報を伝える個別のパケットが個別に処理されている場合、このトランザクションのアプリケーション・レベルの内容は、全体としては処理されない。
【００２３】
故に、ゲートウェイが、アプリケーション・レベルの内容、伝送環境の現状、および／または動的ルールに基づいて、アプリケーション・レベルにてトランザクションをインテリジェントに切り替えるように備えられる。ゲートウェイは、さらに、切り替えの決定に基づいて適用されるサービスを提供し得る。
【００２４】
（システムの概要）
図１は、本発明の一実施形態に従ってトランザクションを処理するシステム１００を表している。図示されているように、システム１００は、１つ以上のクライアント１０２、１つ以上のゲートウェイ１０４、１つ以上のネットワーク１０６、および１つ以上のトランザクション処理装置１０８を含んでいる。以下の説明は単独のゲートウェイ１０４に関して記載されるが、当然のことながら、複数のゲートウェイ１０４が備えられ、後述のあらゆる機能が実行されてもよい。さらに、ゲートウェイがクライアントと隣り合って示されているが、ゲートウェイは、トランザクション処理装置と隣り合い、トランザクション処理装置とネットワーク１０６との間に配置されてもよい。
【００２５】
クライアント１０２は、トランザクションを送信するように構成されている任意のシステムを含む。例えば、クライアント１０２には、ユーザのトランザクションを実行するコンピュータ・デバイスのシステムを含めることができる。一例では、クライアント１０２には、販売時点管理（ＰＯＳ：ｐｏｉｎｔ ｏｆ ｓａｌｅ）デバイスが含まれていてもよく、これは、クレジット・カード承認、小切手カード取引などのための、クレジット・カード情報、暗証番号、名前などのユーザ情報を受信する。クライアントは、店舗にあってポイントまたはクーポン情報を確認するためのキオスク、あるいは送金用のキオスク、あるいは携帯電話または他のデバイスからの無線ユーザ入力を受信するノード、あるいはウェブ・サイト・サーバなどの可能性もある。クライアントは、さらに、売買業者のサーバであることも考えられ、ＰＯＳデバイスはこれを介してネットワーク接続をしている。
【００２６】
次に、クライアント（例えばＰＯＳデバイス）が、トランザクション処理装置１０８からのトランザクションサービスを要求するトランザクションを送信し得る。トランザクションサービスは、トランザクション処理装置１０８が実施することのできる任意の措置であり得る。一実施形態では、これらのトランザクションサービスが、クライアント１０２によって実施されているトランザクションに関して価値を付加する。トランザクションサービスの例としては、クレジット・カード承認、デビット・カード取引、電子小切手取引などを容易化することが挙げられる。トランザクションサービスには、さらに、トランザクションの処理、またはデータの交換を含めることもできる。
【００２７】
ゲートウェイ１０４は、クライアント１０２からトランザクションを受信し、このトランザクションを、ネットワーク１０６を介してトランザクション処理装置１０８へ送るように構成されているシステムを含む。一実施形態では、ゲートウェイ１０４は、ネットワーク１０６のエッジに位置している。例えば、ゲートウェイ１０４は、クライアント１０２のアクセス点にあってもよく、あるいはクライアント１０２の構内にあってもよい。ネットワーク１０６のエッジは、トランザクションが、ネットワーク１０６を経由するルーティングを設定され得る地点とすればよい。例えば、ゲートウェイ１０４は、トランザクション処理装置１０８を選択して、ネットワーク１０６のルータへ要求を送信することができる。トランザクションは、多数のパケットに分割することができる。ルータは、故に、トランザクションのパケットをネットワーク１０６を経由させてトランザクション処理装置１０６へ送ると考えられる。
【００２８】
ネットワーク１０６は、データを転送するように構成されている任意のネットワークとすればよい。例えば、ネットワーク１０６としては、任意のパケット・ベースのネットワーク、公衆交換電話網（ＰＳＴＮｓ：ｐｕｂｌｉｃ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋｓ）、無線ネットワーク、インターネット、プライベート金融ネットワークなどを挙げることができる。
【００２９】
一実施形態では、複数のネットワーク１０６が、本質的に異なっている、および／または信頼性のないネットワークであってもよい。ネットワークは、別々の事業体によって制御されていてもよく、別々のプロトコルおよび形式を用いてデータを送ってもよく、別々の伝送方法を用いてデータを送ってもよいというような点で、本質的に異なっている。例えば、複数のネットワーク１０６が、別々の事業体によって制御されていてもよい。一例としては、第１のインターネット・サービス・プロバイダ（ＩＳＰ：Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）がネットワーク１０６−１を維持管理し、第２のインターネット・サービス・プロバイダがネットワーク１０６−２を維持管理していてもよい。トランザクションは、一実施形態の中で、ネットワーク１０６−１、もしくはネットワーク１０６−２のいずれかを経由して送られればよい。
【００３０】
さらに、複数のネットワーク１０６が、別々の種類であってもよい。例えば、ネットワーク１０６−１が、データのパケットを送る非同期転送モード（ＡＴＭ：ａｓｙｎｃｈｒｏｎｏｕｓ ｔｒａｎｓｆｅｒ ｍｏｄｅ）のネットワークであり得る。別のネットワーク１０６−２は、データを無線で送信する無線ネットワークであってもよい。さらに、もう１つ別のネットワーク１０６が、ＶｉｓａＮｅｔネットワークなど一事業体用のプライベート・ネットワークであってもよい。ネットワーク１０６は２つしか図示されていないが、当然のことながら、もっと多数のネットワーク１０６を設けてもよい。さらに、これも当然のことながら、トランザクションは、複数のネットワーク１０６を経由して送られてもよい。例えば、トランザクションは、ネットワーク１０６−１を経由し、次いでネットワーク１０６−２を経由して、その後トランザクション処理装置１０８へ送られてもよい。
【００３１】
ネットワーク１０６は、さらに、信頼性がないこともあり得る。ネットワークの性質から、いつでも機能しなくなることがあり得る。従って、トランザクション処理が中断されるのを避けるために、フェイルオーバ処理が必要である。
【００３２】
サービス・プロバイダは、クライアント１０２へ提供することのできるサービスを登録および発行し得る。クライアント１０２は、サービスに対して登録し、トランザクションをサービス・プロバイダへ切り替えさせることができる。サービス・プロバイダは、クライアント１０２へサービスを提供するように構成されている不特定多数のトランザクション処理装置１０８を有し得る。一実施形態では、トランザクション処理装置１０８が、金融トランザクションを処理する。例えば、トランザクション処理装置１０８は、イシュア、アクワイアラ、売買業者、またはその他任意のサービス・プロバイダと関連づけられ得る。一例では、トランザクション処理装置１０８が、クレジット・カード取引の承認を容易化する。
【００３３】
サービスは、複数のトランザクション処理装置１０８によって提供することができる。例えば、サービス・プロバイダが、クライアント１０２へサービスを提供できるデータ・センタを多数有し得る。従って、このサービスに関するトランザクションは、このサービスを提供できるトランザクション処理装置１０８のうちのいずれかに切り替えられ得る。トランザクション処理装置１０８は、ゲートウェイ１０４によって、アプリケーション・レベルの内容、伝送環境に関する状況情報、および／または動的ルールに基づいて選択され得、これらは全て動的に変化していてもよい。
【００３４】
アプリケーション・レベルのサービスは、動的に変更されることがある。利用可能なサービスが、変更されたり、別の処理装置へ移動されたり、維持管理または障害を理由に利用不可能となっていたりすることが考えられる。
【００３５】
伝送環境に関する状況情報も、動的に変化している場合がある。故に、ゲートウェイ１０４は、トランザクションの切り替え方法を決定するにあたり、伝送環境に関する状況情報を判断する。例えば、ネットワーク１０６の現在の健康状態、ネットワーク１０６の利用可能性、トランザクション処理装置１０８の利用可能性、データがネットワーク１０６を介して転送されている速度、トランザクションをネットワーク１０６を介して転送する費用、トランザクションを処理する費用、アプリケーションがトランザクションをアプリケーション・レベルで処理するのに要する時間の長さなどについて判断され得る。
【００３６】
伝送環境に関する状況情報の動的な情報に加えて、何らかの比較的静的な情報についても判断され得る。例えば、静的な情報としては、トランザクションの費用、トランザクション処理装置１０８がトランザクションを処理するのに必要なフォーマットなどが挙げられる。ゲートウェイ１０６は、トランザクションをどのように送るかを決定するのに、動的および静的な情報を使用し得る。
【００３７】
動的ルールは、トランザクションをインテリジェントに切り替える方法を決定するのに使用される情報であるといえる。ルールは、動的にロードすることができる。例えば、サービス・プロバイダが、サービスに関するルールを登録し得、これが、ゲートウェイ１０４へ動的にロードされ得る。さらに、クライアントが、サービスおよびプロバイダのルールに加入して、自分のトランザクションをサービス・プロバイダへ切り替え得る。これらのルールも、ゲートウェイ１０４へ動的にロードされ得る。
【００３８】
故に、ゲートウェイ１０４は、トランザクションを処理することのできる、サービスのためのトランザクション処理装置１０８を動的に選択することができる。選択されたトランザクション処理装置１０８が処理できるようにトランザクションをフォーマット可能であるなど、選択されたトランザクション処理装置に特有のビジネス・サービスをトランザクションに対して実施することもできる。次いで、トランザクションを、選択されたネットワーク１０６を介して、選択されたトランザクション処理装置１０８へ送信することができる。トランザクション処理装置１０８および／またはネットワーク１０６を動的に選択することによって、ゲートウェイ１０４は、トランザクション処理装置１０８および／またはネットワーク１０６のあらゆる障害からクライアント１０２を隔離している。故に、このことは、極めて高いサービスの利用可能性を提供している。ゲートウェイ１０４は、トランザクション処理装置１０８の停止期間を生じさせるような、必要とされるあらゆる変更から、クライアント１０２を隔離している。
【００３９】
（ゲートウェイ１０４の概要）
図２は、本発明の一実施形態によるゲートウェイ１０４のさらに詳な説明を図示している。図のように、ゲートウェイ１０４には、１つ以上の要求ハンドラ２０２、インバウンド・メッセージ・ストリーム・パーサ２０４、セキュリティ・マネージャ２０６、適応型ルート・セレクタ２０８、フロー・ハンドラ２１０、アウトバウンド・メッセージ・ストリーム・ビルダ２１２、メッセージ・ディスパッチャ２１４、コーディネータ２１６、管理モジュール２１８、設定ローダ２２０、ルール・データベース２２２、状況情報データベース２２４、および動的情報モニタ２２６が含まれる。
【００４０】
要求ハンドラ２０２は、クライアント１０２からトランザクションを受信するように構成されている。クライアント１０２は、ハイパー・テキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、拡張マークアップ言語（ＸＭＬ）、ＩＳＯ８５８３標準などの様々なプロトコルおよび形式でトランザクションを送信することができる。要求ハンドラ２０２は、多様なプロトコルおよび形式で送信されるトランザクションのためにインターフェースを備え、トランザクションを、インバウンド・メッセージ・ストリーム・パーサ２０４へ提供する。例えば、ＩＳＯメッセージのハンドラは、クライアント１０２からＩＳＯ８５８３要求を受信し、それをインバウンド・メッセージ・ストリーム・パーサ２０４へ渡すように構成されている。同様に、ＸＭＬメッセージのハンドラ、ＨＴＴＰ要求のハンドラ、およびＦＴＰ要求のハンドラは、ＸＭＬ、ＨＴＴＰ、およびＦＴＰのメッセージおよび／または要求に対処することができる。故に、要求ハンドラ２０２は、ゲートウェイ１０４が、様々なプロトコルおよび形式でメッセージを受信できるようにしている。上記の形式およびプロトコルについて説明がなされているが、当業者には当然のことながら、他にも要求ハンドラ２０２が処理できる形式およびプロトコルがある。
【００４１】
インバウンド・メッセージ・ストリーム・パーサ２０４は、要求ハンドラ２０２からトランザクションを受信し、この要求を正規の形式へ変換するように構成されている。インバウンド・メッセージ・ストリーム・パーサ２０４は、メッセージを様々な形式で受信し、これらの要求を正規の形式へ処理することができ、ひいては、これがゲートウェイ１０４の他の構成要素によって処理可能となる。従って、多様な形式のトランザクション要求を、ゲートウェイ１０４によって処理することができる。インバウンド・メッセージ・ストリーム・パーサ２０４は、さらに、拡張可能なアーキテクチャを備え、その中で、ゲートウェイ１０４によって処理できる新しい形式を使用可能にすることができる。新しい形式が追加された場合、インバウンド・メッセージ・ストリーム処理装置１０４には、この新しい形式を正規の形式へ変換することが追加される。このように、正規の形式が使用されるために、新しい形式が追加されるときにも、ゲートウェイ１０４の全構成要素への変更は必要ないのである。正しくは、インバウンド・メッセージ・ストリーム・パーサ２０４は、要求を、ゲートウェイ１０４の他の構成要素によって処理可能な正規の形式にパースするように構成されている。インバウンド・メッセージ・ストリーム処理装置２０４のさらなる詳細については後に記す。
【００４２】
セキュリティ・マネージャ２０６は、トランザクションに関するセキュリティ機能を提供するように構成されている。例えば、プラガブル（ｐｌｕｇｇａｂｌｅ）認証および承認、ロール・ベース・アクセス制御（ＲＢＡＣ：ｒｏｌｅ−ｂａｓｅｄ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）、暗号化、ファイル保全などのセキュリティ機能を提供できる。プラガブル認証および承認は、認証および承認用に標準インターフェースを備え、故に、現行の方法に影響を及ぼすことなく、認証の新しい方法およびアクセス制御の追加が可能となる。当業者には当然のことながら、他にもトランザクションへ付加することのできるセキュリティ機能がある。
【００４３】
適応型ルート・セレクタ２０８は、トランザクションを、トランザクション処理装置１０８へ、ネットワーク１０６を介して切り替えるように構成されている。適応型ルート・セレクタ２０８は、アプリケーション・レベルの内容、伝送環境の現状、および／または動的ルールに基づいて、トランザクションを切り替える。
【００４４】
適応型ルート・セレクタ２０８は、ルール・データベース２２２に含まれているルール、および状況情報データベース２２４に含まれている動的状況情報を使用して、トランザクションをルーティングする。上述のように、状況情報は、状況情報データベース２２４に保存されているとよい。一実施形態では、状況情報は動的であってもよい。動的情報モニタ２２６が、状況情報を監視し、判断することができる。動的情報は、次いで、状況情報データベース２２４に保存される。状況情報の例としては、ネットワーク１０６の利用可能性、トランザクション処理装置１０８の健康状態、トランザクションごとの費用、アプリケーションが前のトランザクションをアプリケーション・レベルで処理するのに要した時間などがある。一実施形態では、動的情報モニタ２２６は、トランザクションが受信されたら、動的状況情報をランタイムに判断し得る。別の実施形態では、動的情報モニタ２２６は、動的状況情報を或る一定の間隔で判断し得る。
【００４５】
トランザクション処理装置１０８によって実施される様々なサービスのそれぞれが、動的情報モニタ２２６によって実施することのできるプローブを指定し得る。プローブが送信され、トランザクション処理装置１０８および／またはネットワーク１０６の状態に基づいて情報が収集されることが可能となる。例えば、動的情報モニタ２２６は、ネットワークが利用可能かどうかを判断するために、ネットワークにテスト送信して応答を求めることができる。トランザクション処理装置１０８またはネットワーク１０６と連絡がつかなかったら、利用不可能とみなせばよく、状態の情報を状況情報データベース２２４内に反映させる。或るサービス用のトランザクション処理装置１０８全てと連絡がつかなかったら、そのときはこのサービスが利用不可能であるとみなせばよい。この場合、ゲートウェイ１０４が、このサービスを提供している他のサービス・プロバイダを指定し得る。さらに、トランザクション処理装置１０８上のアプリケーションがトランザクションを処理するのに要する時間が測定され得る。例えば、アプリケーションがクレジット・カード承認を承認するのに要する期間が測定される。この測定によって、トランザクションを切り替えるのに使用することのできるアプリケーション・レベルの状況が提供される。
【００４６】
ルール・データベース２２２は、トランザクションを処理するネットワーク１０６および処理装置１０８に加えてトランザクション用のサービスにも関する判断ルールを含んでいる。ルールは、クライアントの基準も表し得る。例えば、サービスが選択されるためには、ルールとして或る特定の状況情報およびアプリケーション・レベルの内容を満たす必要がある。クライアントが、トランザクションのサービスを選択するのに使用可能なクライアント独自のルールを用意してもよい。一例では、クライアント１０２に関するトランザクションを受信したら、適応型ルート・セレクタ２０８が、クライアント独自の選択ルールを判断し、このトランザクションに対処できるサービスを判断し得る。このサービスを提供しているサービス・プロバイダへトランザクションを切り替えるために、トランザクションからアプリケーション・レベルの内容を判断し、および／または状況情報データベース２２４から動的状況情報を判断する。アプリケーション・レベルの内容、および／または状況情報をルールに適用し、このルールに従って、トランザクションを処理できるサービス・プロバイダを判断する。クライアント１０２は、例えば、費用など或る特定の要素に基づいて、もっとも安価なサービスが第１に選択されるべきであるが利用不可能の場合にはより費用のかかる第２のサービスが選択されるように、指定することができる。さらに、アカウント番号などのアプリケーション・レベルの内容に基づいて、トランザクションを、或る特定のクレジット・カード・サービスへ切り替えることもできる。例えば、或る特定のアカウント番号が、クレジット・カードかデビット・カードかを示すか、あるいは特定のポイントまたは報酬システムが適用されていることを示してもよい。他のアカウント番号またはフィールドは、送金またはパスワード検証（例えば、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａ）など、他のサービスの必要性を示すことが考えられる。さらに、アプリケーション・レベルの内容には、クライアントの場所、およびトランザクションが局所的な処理を必要とするか、または異なる国の処理装置１０８への送付が必要かを指示する、何らかの地域または国を指定する規程を含めることもできる。
【００４７】
サービスには、さらに、サービスに関するルールを指定するサービス仕様が含まれ得る。例えば、ルールは、トランザクションに必要なメッセージ形式、サービスを提供するトランザクション処理装置１０８のネットワーク・アドレス、トランザクション処理装置１０８へのトランザクション切り替えに関する優先順位、サービスに適格なアカウント番号の範囲などを指定し得る。これらのルールは、後にさらに詳細に述べるように、登録にあたり、サービス・プロバイダによって提供される。サービス・プロバイダは、ルールを直接ゲートウェイ１０４へロードすることができ、ゲートウェイが、次に、他の関与するゲートウェイへルールを発行すると考えられる。
【００４８】
ルールは、トランザクションを処理することのできるフローを指定し得る。フローは、トランザクションをトランザクション処理装置１０８へ送信するための処理に対処する。メッセージは、その後、選択されたフロー・ハンドラ２１０へ送信される。トランザクション処理装置１０８およびネットワーク１０６が選択された後、フロー・ハンドラ２１０は、トランザクションに対してビジネス・サービスを実施し得る。例えば、別々のトランザクション処理装置１０８は、別々の形式でトランザクションを処理することが考えられる。フロー・ハンドラ２１０は、選択されたトランザクション処理装置１０８に適切な形式を判断し、その形式にトランザクションをフォーマットし得る。他のビジネス・サービスとしては、通貨の換算、機密情報を扱うフィールドの暗号化、或る特定の閾値を下回るトランザクション額に対するクライアント側の代理処理などが挙げられる。
【００４９】
フロー・ハンドラ２１０には、複数のフローを含めることができる。各フローは、あるクラスのメッセージを処理する一連のビジネス・サービスに対処し得る。各フローには、フローにおけるビジネス・サービスを全て調整するフロー・ハンドラが含まれている。フローの範囲内の一続きのサービスは、フロー仕様によって指定され、設定ローダ２２０を使用してランタイムにロードすることができる。フロー仕様は、着信メッセージにどのように対処するかを決定する一続きのサービスである。各サービスは、特定の機能を実行するソフトウェア・アプリケーション・コードである。新しいサービスおよびフロー仕様については、ゲートウェイ１０４へ動的にロードすることができる。
【００５０】
フローの中で、フロー・ハンドラ２１０がトランザクションを処理した後、メッセージはアウトバウンド・メッセージ・ストリーム・ビルダ２１２へ送信される。ビルダ２１２は、決定されたトランザクション処理装置１０８によって求められているメッセージ形式に基づいて、正規の形式からアウトバウンド・メッセージをビルドするように構成されている。ビルダ２１２は、故に、正規のメッセージ形式に基づいて任意のメッセージ形式でメッセージを生成するように構成されている。アウトバウンド・メッセージ・ストリーム・ビルダ２１２については、後にさらに詳述する。
【００５１】
メッセージ・ディスパッチャ２１２は、トランザクション処理装置１０８へトランザクションを送信するように構成されている。ディスパッチャ２１４は、トランザクションが選択されたトランザクション処理装置１０８へ確実に届くようにし得る。ディスパッチャは、多様なトランザクション処理装置１０８との接続を管理し、機能しなかったトランザクション処理装置１０８への再接続を試み、さらにトランザクション処理装置１０８およびネットワーク１０６の状態を動的情報モニタ２２６へ提供し得る。一実施形態では、トランザクションがパケット化、すなわち一連のパケットに分割されており、ルータへ送信され得る。ルータは、パケットを、ネットワーク１０６を経由させてトランザクション処理装置１０８へ送り得る。
【００５２】
コーディネータ２１６は、ゲートウェイ１０４の複数の処理装置を調整し、トランザクションの適正な処理が確実に行われるようにする。さらに、コーディネータ２１６は、アプリケーション管理、ソフトウェア配布、システム監視およびフェイルオーバ機能に関するサービスをゲートウェイ１０４に提供する。アプリケーション管理は、アプリケーションおよびサービスの開始および停止を局所的および遠隔的にサポートする。アプリケーション管理は、さらに、ゲートウェイ１０４に新しいアプリケーションおよびサービスが追加できるようにする。ソフトウェア配布は、ソフトウェア更新をゲートウェイ１０４上へインストールできるようにし、必要に応じてロールバック更新のサポートを行うことを含む。システム監視サービスは、メモリ、ＣＰＵ、ネットワーク・インターフェースなどのシステム構成要素の主要なパラメータ、および処理を監視し、設定されたパラメータが閾値から逸れた場合には警告を発する。コーディネータ２１６は、さらに、処理の失敗を検出したら、処理を再始動させる。コーディネータ２１６は、さらに、（複数ゲートウェイのクラスタ配置の場合に）ハートビート・メカニズムを使用してピア・ゲートウェイ１０４の健康状態を監視し、ピア・ゲートウェイ１０４が機能しない場合には、ピア・ゲートウェイ１０４の処理負荷を引き継ぐ。
【００５３】
（ルールの動的ロード）
サービスの初期登録（以下に記載）の後、ルールおよびゲートウェイ１０４によって実施されるビジネス・サービスは動的に変更されることがある。管理モジュール２１８および設定ローダ２２０が、ルール・データベース２２２およびフロー・ハンドラ２１０へ変更を動的にロードするように構成されている。
【００５４】
設定ローダ２２０は、設定の変更、ルーティングのルール、新しいフロー仕様などを、ルール・データベース２２２へランタイムにロードするように構成されている。故に、設定ローダ２２０によって、ルール・データベース２２２内のルーティングのルールを動的に再構成できるようになっている。ルールベースは、複数バージョンのルールオブジェクトを維持管理しており、ルールベースの現行バージョンと同期を取ったリファレンスを有する。設定ローダ２２０は、ルールベースへ更新をロードする前に、使用中のルールベースのシャドウ・コピーを作成し、次いでバージョン変更する。次いで、更新されているオブジェクトごとにオブジェクトの新インスタンスを作成し、ルールベースの新バージョンにおいてリファレンスを更新する。全ての更新が完了したら、リファレンスがルールベースの新バージョンを指し示すように変更する。
【００５５】
管理モジュール２１８は、管理上の措置が実施可能となるように構成されている。管理モジュール２１８は、ユーザ・エージェントが、１つ以上のゲートウェイ１０４を管理するのに使用することができる。例えば、管理モジュール２１８を使うと、ルール・データベース２２２の中へ新しいルールを定義することができ、あるいはルーティングのルールを動的に変更することができる。さらに、管理モジュール２１８を使用して、フロー・ハンドラ２１０用の新しいフロー仕様のロードおよびアンロード、ビジネス・サービスの開始および停止、さらに設定のロードおよびアンロードを行うこともできる。その後、設定ローダ２２０が、変更を実施するように構成されている。
【００５６】
本発明の実施形態の動的な変更は、サービスのモジュール化およびサービスのランタイム起動を組み合わせて、フローを通してメッセージ処理を行う（例えば、上述のフローの説明を参照）ことにより、可能となっている。適応型ルート・セレクタ２０８は、新しいトランザクションを受信すると、ルールベースの現行バージョンを読み、そのルールを適用して適切なフローを選択する。フロー・ハンドラ２１０は、トランザクションの全期間中にわたって特定のバージョンのフローを使用するので、各フロー仕様は、サービス、フローおよびルールの特定のバージョンを参照する。故に、現行のトランザクションによって現在使用されているバージョンとは異なるバージョンにおいて更新が行われるために、その時点で現行のトランザクションへ干渉することなくこれらを更新することが可能である。
【００５７】
（トランザクションの処理）
図３は、本発明の一実施形態に従ってトランザクションを処理する方法の簡略化したフロー図３００を表している。ステップ３０２で、クライアント１０２からトランザクションを受信する。トランザクションは、クレジット・カード承認、小切手カード取引など、いかなる種類のトランザクションであってもよい。
【００５８】
ステップ３０４で、トランザクションのアプリケーション・レベルの内容が判断される。上述のように、アプリケーション・レベルの内容は、トランザクションを処理するのに使用される。例えば、アプリケーション・レベルの内容は、クレジット・カード番号、ＰＩＮ、加盟銀行（アクワイアラまたはイシュア）の名前などであり得る。アプリケーション・レベルの内容は、全体としてとらえられ得る。例えば、トランザクションが多数のパケットにパケット化されていたら、アプリケーション・レベルの内容は、複数パケットのペイロードの中にあると考えられる。この情報は、トランザクションのアプリケーション・レベルの内容に組み立て直され得る。
【００５９】
ステップ３０６で、伝送環境の現状について判断される。例えば、サービスを提供できるトランザクション処理装置の健康状態について判断される。さらに、トランザクションを送ることのできるネットワーク１０６のネットワーク健康状態についても判断され得る。この情報は、伝送環境の現在の状況が提供されるように、リアルタイムに判断され得る。
【００６０】
ステップ３０８で、サービスを判断すべく、アプリケーション・レベルの情報および／または伝送環境の現状に対してルールを適用する。例えば、或る特定のクライアント１０２を、或る特定のサービスと関連付けてもよい。Ｖｉｓａなどの処理装置のホストは、自分のトランザクションがＶｉｓａの所有するトランザクション処理装置１０８へ切り替えられることを望む場合がある。さらに、他の処理装置のホストが、自分たちのトランザクションを、Ｖｉｔａｌなど二次的なトランザクション処理装置へ切り替えることを望む場合もある。
【００６１】
ステップ３１０で、ルールを適用して、サービスに向けてトランザクションを切り替えるトランザクション処理装置および／またはネットワーク１０６を判断する。この決定は、ルールに適用されたアプリケーション・レベルの内容および／または伝送環境に関する現状に基づいて判断され得る。例えば、トランザクションを処理するサービスについて判断される。次に、ネットワークの利用可能性に基づいて適用できるトランザクション処理装置１０８が判断される。
【００６２】
さらに、サービスを、多様なトランザクション処理装置１０８およびネットワーク１０６と関連付けてもよい。例えば、クレジット・カード承認が、或る特定のトランザクション処理装置１０８へ送信されるように構成され得る。さらに、小切手カード取引が、第２の一連のトランザクション処理装置１０８へ送信されるように構成されていてもよい。これらのルールは、クライアントおよび／またはトランザクションサービスに関して判断される。
【００６３】
ステップ３１２で、要求に応じて、トランザクションに対する任意のビジネス・サービスがアプリケーション・レベルで実施され得る。例えば、トランザクションが、選択されたトランザクション処理装置１０８に求められている形式へフォーマットされ得、アプリケーション・レベルにある任意の情報がトランザクションに付加され得、あるいは他の任意のビジネス・サービスが実施され得る。
【００６４】
ステップ３１４で、トランザクションは、選択されたトランザクション処理装置１０８へネットワーク１０６を介して切り替えられ得る。
【００６５】
あるいは、他の実施形態では、ゲートウェイ１０４が、トランザクションをサービス・プロバイダへ切り替えることをせずに、トランザクションを処理するように構成されている。或る特定の基準が満たされていれば、ゲートウェイ１０４がトランザクションを処理できることを提示するルールを、サービス・プロバイダが指定すればよい。例えば、トランザクションが、或る特定の金額を下回っている場合などである。一例では、閾値より低額のクレジット・カード取引については、承認を求めて銀行へ行く必要がないばかりでなく、ネットワーク１０６を通じてクレジット・カード会社へ行く必要もないまま、承認することが可能となり得る。このことは、トランザクションがネットワークのエッジにおいて処理できるため、多数の利点を提供する。これは、ネットワークのボトルネックを解消し、分散化された処理システムを提供する。
【００６６】
（サービスの作成および加入）
上述のように、ルールは、ルール・データベース２２２へ動的にロードすることができる。図４は、本発明の一実施形態に従って、トランザクション処理装置１０８が提供するサービスに関してゲートウェイ１０４へルールをロードする簡略化したフロー図４００を表している。ステップ４０２で、サービス作成要求を受信する。例えば、サービス・プロバイダが、このサービス・プロバイダの提供しているサービスを指定するサービス作成要求を送信することによって、サービスの登録を試みてもよい。あるいは、トランザクション処理装置または他のサービス・プロバイダと関連しているゲートウェイ１０４が、新しいサービスを動的に通知してもよく、クライアントと関連しているゲートウェイは、それらの新しいサービスへの登録を始めるかどうかを判断することができる。新しいサービスは、送金サービス、新しいポイント・プログラムなどであることが考えられる。
【００６７】
ステップ４０４で、サービスに関するルールを受信する。例えば、ルールが、サービスを処理することのできるトランザクション処理装置１０８のアドレスを指定し得る。ネットワーク・アドレスは、トランザクション処理装置１０８へトランザクションを送ることのできるＩＰアドレスまたは他の任意の識別番号とすればよい。加えて、要求をトランザクション処理装置１０８へ送るのに使用可能な、ネットワーク１０６に関する情報についても、受信され得る。ルールは、さらに、サービスの使用に関する基準を指定してもよい。例えば、メッセージの受信時に求められているフォーマットを指定している基準、サービスを使用する費用（固定費用およびトランザクションごとの費用の両方）、およびサービスの使用に関する他の任意の基準が受信され得る。ルールは、どのカードの種類あるいはどのアカウントの種類またはアカウント番号が、サービスに関して適格な範囲かまたは登録されているかを、指定することも可能と考えられる。
【００６８】
ステップ４０６で、サービスに関するルールは、管理モジュール２１８によって、設定ローダ２２０を用いてデータベース２２２へ動的にロードされる。さらに、サービスに関してトランザクションを処理するのに必要なあらゆるフロー仕様が、フロー・ハンドラ２０２へロードされ得る。
【００６９】
その結果、サービスが作成され発行されると、クライアント１０８が、サービスに加入することができる。図５は、本発明の一実施形態によるサービスに加入する方法の簡略化したフロー図５００を表している。ステップ５０２で、作成されたサービスへ加入する要求をクライアント１０８から受信する。要求は、ウェブのポータルを介して、あるいは他の任意の方法によって、受信すればよい。クライアント１０２は、ゲートウェイ１０４に直接接触およびアクセスしてもよい。
【００７０】
ステップ５０４で、サービスの使用に関するルールまたは基準の仕様を、クライアント１０８から受信する。この仕様は、クライアント１０８から受信したトランザクションに関するサービスを選択するのに必要な基準を示し得る。基準は、クライアント固有のものであってもよく、または多数のクライアント１０８にわたって（例えば、或る事業体の全ＰＯＳデバイスに対して）一様であってもよい。さらに、仕様は、加入する各サービスに関してクライアント１０８が優先順位をつける形式にしてもよい。例えば、クライアントは、或るトランザクションに関しては第１サービスが選択されるが、そのサービスが機能していなければ、そのときには第２サービスが選択されるようにする、といった指定をすることができる。基準をさらに複雑にして、ネットワーク費用、サービス費用などを考慮に入れた複雑なルールを含めてもよい。
【００７１】
ステップ５０６で、サービスの要求をルーティングするルールが生成される。これらのルールは、サービスが選択されるために、アプリケーション・レベルの内容および／またはネットワークの伝送環境の現状に基づいて満たす必要のある基準を指定し得る。
【００７２】
ステップ５０８で、これらのルールが、ルール・データベース２２２へ動的にロードされ得る。従って、サービスは、サービスに加入するクライアント１０８にとって直ちに利用可能な状態になり得る。
【００７３】
ステップ５１０で、サービスのフロー定義が生成される。フロー定義は、サービスをサポートするように構成され得る。一実施形態では、サービスのフロー定義が既に存在しており、生成する必要がなくてもよい。一方、クライアント１０８に特化したビジネス・サービスを実施する必要のある場合には、新しいフロー定義が生成され得る。
【００７４】
ステップ５１２で、ステップ５１０にて生成されたフロー定義が、設定ローダ２２０によって動的にロードされ得る。
【００７５】
一実施形態では、トランザクションが送信されるより前に、クライアント１０２からルールを受信することがある。例えば、クライアント１０２が、サービスに加入し、このサービスの使用に関するルールを準備してもよい。別の実施形態では、トランザクションが送信される直前または直後にルールが送信され得る。例えば、クライアント１０２が、トランザクションの前または後に送信されるメッセージに使用のルールを指定し得る。ルールは、次いで、ゲートウェイ１０４へ動的にロードされる。これにより、クライアント１０２が、ゲートウェイ１０４をランタイムに動的に構成することができる。
【００７６】
（サービスに関するルールの分散化）
複数のゲートウェイ１０４がシステム内に配置されてもよい。各ゲートウェイ１０４は、接続しているクライアント１０２へ、独自のサービスを提供し得る。ゲートウェイ１０４は、ネットワーク１０６のエッジ、クライアントのアクセスのポイント、および場合によってはクライアント１０２の物理的な構内に位置することができる。一実施形態では、ゲートウェイ１０４は、ゲートウェイ１０４によって提供されているサービスに関する情報のみを保存する。様々なゲートウェイ１０４が、様々な一連のサービスに関する情報を有すればよい。従って、サービス・プロバイダによって登録された、あるいはクライアント１０２によって加入された多様なサービスの提供に関する情報は、ゲートウェイ１０４全体にわたって配布されてもよく、すなわち分散させられ得る。情報の分散化によって、ゲートウェイ１０４は、他のゲートウェイ１０４に連絡して、サービスの情報について問い合わせるか、あるいはサービスの情報を提供するかのいずれかを行うように構成されている。
【００７７】
図６は、本発明の一実施形態に従ってゲートウェイ１０４の分散型システムを提示するシステム５５０を表している。図のように、複数のクライアント１０２およびゲートウェイ１０４が提示されている。ゲートウェイ１０４は、１つ以上のネットワーク１０６のエッジに位置している。
【００７８】
各ゲートウェイ１０４は、１つ以上のクライアント１０２に接続し得る。記述のために、単一のクライアント１０２がゲートウェイ１０４に接続して示されているが、当然のことながら、多数のクライアント１０２が、ゲートウェイ１０４に接続していてもよい。さらに、当然のことながら、ゲートウェイ１０４は、クライアント１０２ではなくトランザクション処理装置１０８に接続していてもよい。
【００７９】
ゲートウェイ１０４は、ネットワーク１０６のエッジにて接続しているクライアント１０２に関するトランザクションを処理するように構成されている。例えば、ゲートウェイ１０４−１は、クライアント１０２−１に関するトランザクションを処理するように構成されており、ゲートウェイ１０４−２は、クライアント１０４−２に関するトランザクションを処理するように構成されている。ゲートウェイ１０４−１は、クライアント１０２−１へ提供されるサービスに関する情報に加え、クライアント１０２−１の優先順位に関する情報も保存している。同様のことが、他のゲートウェイ１０４およびクライアント１０２についても当てはまる。
【００８０】
ゲートウェイ１０４は、サービスに関する情報の配布を容易化するように、他のゲートウェイ１０４の連絡先を維持管理している。例えば、第１ゲートウェイ１０４が、現在第１ゲートウェイ１０４の提供していないサービスに関する情報を必要とするとき、このサービスを提供している第２ゲートウェイ１０４に連絡して、サービスに関するルールなどの情報を送信してもらうことができる。別の実施形態では、第１ゲートウェイ１０４は、サービスに関するトランザクションを第２ゲートウェイ１０４へ送信してもよく、それにより第２ゲートウェイ１０４がトランザクションを処理できる。この場合、第２ゲートウェイ１０４は、トランザクションを、トランザクション処理装置１０８へ切り替え、回答を受信し、その後この回答を第１ゲートウェイ１０４へ返送することができる。
【００８１】
連絡先は、さらに、他のゲートウェイ１０４へサービスに関する情報を配布するのに使用してもよい。例えば、サービス・プロバイダが、第１ゲートウェイ１０４上に新しいサービスをアップロードする場合がある。このサービスに関するルールは、その後、他のゲートウェイ１０４へ配布されるとよい。例えば、エッジにてクライアント１０２と接続しているゲートウェイは、クライアント１０２がサービスに関心を持っていれば、ルールを送信される。クライアント１０２は、独自のルールをアップロードすることもできる。
【００８２】
各クライアントは、自分の望むサービスに関するルールのみをロードすればよいので、必要とされるメモリおよび更新が削減され、ゲートウェイの処理速度は改善される。例えば、クライアントがホテルであれば、ポイントあるいは報酬サービスを必要とするが、送金サービスは必要としないこともある。所望のサービスだけをロードすることによって、ホテルは、性能に影響を及ぼすことなく、ゲートウェイ上により多くの情報を獲得できると考えられる。例えば、ポイント・プログラムで使っているアカウント番号もしくはアカウント番号の範囲をゲートウェイ上に保存することができ、そのため或るユーザがポイントに適格であるかどうかの判断を局所的に行うことができる。一方、クライアントがウェブ・サイトであれば、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａサービスの方により関心を示すことが考えられる。同様に、或るカード会員が加入済であるか、およびパスワードを有するかなど、Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａに固有の情報およびルールを局所的に保存することが可能と考えられ、それによりパスワードがネットワーク上に出て行かなくとも、ユーザが加入者か否かの判断をするためにパスワードを促すことができるようになる。或る特定の売買業者が或る特定の会社と多くトランザクションをするのであれば、Ｖｉｓａビジネス・カードにより高い関心を持ち、その特定の売買業者での購入を承認されている購入カード・アカウント番号の局所的なリスト作成を望むこともあり得る。
【００８３】
このようにして、クライアント１０２およびサービス・プロバイダは、直接ゲートウェイ１０４と相互作用して、サービスをロードまたは要求することができる。これは、ゲートウェイをクライアントの必要性に合ったものにすることができるので、クライアント１０２にとって有利であるといえる。さらに、ゲートウェイ１０４はクライアント・サイトにて維持管理することができるので、ゲートウェイ１０４へ容易にかつ遅滞なくアクセスすることができる。
【００８４】
故に、システム５５０によって、分散型の一連のサービスが提供される。中央処理装置を有する代わりに、処理が、ネットワークのエッジへ分配されている。このことは、ボトルネックを解消し、フェイルオーバ保護を提供する。例えば、従来は、中央型処理装置を使用していてそれが作動しなくなった場合は、システム全体のトランザクション処理が影響を受けることがある。一方、或るゲートウェイ１０４が作動しなくなっても、システム５５０全体の処理は影響を受けず、トランザクションは他のゲートウェイ１０４へ送られればよい。
【００８５】
（配置のシナリオ）
ゲートウェイ１０４は、多数の異なったシナリオで配置することができる。例えは、ゲートウェイ１０４は、プライベート・ネットワーク上のフロントエンド・ゲートウェイ、インターネット・ゲートウェイ、および／または無線ゲートウェイとして、配置できる。図７は、本発明の一実施形態に従って、ゲートウェイ１０４をフロントエンド・ゲートウェイとして提示するシステム６００を表している。システム６００は、本質的に異なる複数のネットワーク１０６を通じて１つ以上のクライアント１０２を１つ以上のトランザクション処理装置１０８へ接続している。トランザクション処理装置１０８は、クライアント１０２からのトランザクションを処理することのできる任意のシステムであればよい。例えば、Ｖｉｓａ、ＭａｓｔｅｒＣａｒｄなどが、クレジット・カードおよびデビット・カード取引用のトランザクション処理装置を所有し得、加盟銀行（アクワイアラ／イシュア）をクライアント１０２とすればよい。
【００８６】
クライアント・データ・センタ６０２が、クライアント１０２からトランザクションを受信し得る。トランザクションは、クレジット・カード承認またはデビット・カード取引であり得る。データ・センタは、例えば、クライアントのプライベート・ネットワークを介して、複数のＰＯＳデバイスと接続している中央コンピュータであり得る。ゲートウェイ１０４は、トランザクションを処理し、このトランザクションをトランザクション処理装置データ・センタ１０８へインテリジェントに切り替える。例えば、トランザクションがＶｉｓａのトランザクションである場合、トランザクション処理装置データ・センタＡおよびＢが、Ｖｉｓａと関連し得る。トランザクションがＭａｓｔｅｒＣａｒｄのトランザクションであれば、ＭａｓｔｅｒＣａｒｄと関連しているという理由で、処理装置データ・センタＣが選択され得る。
【００８７】
ゲートウェイ１０４は、適切なトランザクション処理装置１０８、およびトランザクションを送るネットワーク１０６を判断する。その後、トランザクションは、ルータ６０４へ送信され、次いで、ルータがこのトランザクションをルーティングすることができる。一実施形態では、ルータ６０４は、パケットを、選択されたトランザクション処理装置１０８へネットワーク１０６を経由させて送り得る。
【００８８】
図８は、本発明の一実施形態に従って、ゲートウェイ１０４がインターネット・ゲートウェイとなっているシステム７００を表している。インターネット・クライアント７０２は、クライアント１０２を含んでいる。クライアント１０２は、インターネット７０４を介してゲートウェイ１０４へトランザクションを送信することができる。ゲートウェイ１０４は、標準的なクレジット・カード承認、パスワード認証（Ｖｅｒｉｆｉｅｄ ｂｙ Ｖｉｓａ）、報酬またはポイント処理など、オンライン・ショッピングに必要な特定のサービス向けに構成され得る。
【００８９】
ゲートウェイ１０４は、クライアント１０２に対し、様々なトランザクション処理装置１０８との接続性を提供する。ゲートウェイ１０４は、ＨＴＴＰ（Ｓ）および他のＸＭＬベースの要求を受け付け得る。アプリケーション・レベルの内容および伝送環境の現状に基づいて、サービスおよびトランザクション処理装置１０８が選択され得る。トランザクションはＨＴＴＰまたはその他任意のＸＭＬベースの要求の状態で送信されてきたと考えられるので、ゲートウェイ１０４は、トランザクションを切り替える前に、メッセージを、トランザクション処理装置１０８に求められている形式へ変換するとよい。例えば、トランザクション処理装置１０８は、メッセージがＩＳＯ８５８３形式で処理されていることを必要とする場合がある。通常、ＰＯＳデバイスがトランザクションを処理すれば、トランザクションはＩＳＯ８５８３形式で送信されると考えられる。一方、トランザクションがインターネット・ゲートウェイによって処理される場合、インターネット・クライアント７０２はＩＳＯ８５８３のメッセージを送信するようには構成されていないことがある。故に、ゲートウェイ１０４は、メッセージを、トランザクション処理装置１０８に必要とされるＩＳＯ８５８３形式へフォーマットするように構成されている。
【００９０】
一例では、ゲートウェイ１０４は、インターネット・クライアント７０２からのインターネットトランザクションを処理し得る。インターネット・クライアント７０２が、ＨＴＴＰ（Ｓ）要求をゲートウェイ１０４へ送信する。ゲートウェイ１０４は、ＨＴＴＰ（Ｓ）要求を、正規の内部メッセージ形式へ変換する。その後、任意のビジネス・サービスをトランザクションに対して実施することができる。一例では、トランザクション処理装置１０８に必要とされるフォーマットに適合するように、アプリケーション・レベルのデータを変更し得る。例えば、ＸＭＬトランザクションが、ＩＳＯ８５８３形式へ変換され得る。ゲートウェイ１０４は、その後、トランザクションを、トランザクション処理装置１０８へインテリジェントに切り替える。
【００９１】
トランザクション処理装置１０８は、トランザクションを処理し、ゲートウェイ１０４へ回答を返送する。この回答は、トランザクション処理装置に固有の形式であってもよい。ゲートウェイ１０４は、次に、ＨＴＴＰ（Ｓ）の回答をビルドし、それをインターネット・クライアント７０２へ送信する。故に、ゲートウェイ１０４を使用して、インターネットを介したトランザクションを処理することができる。
【００９２】
図９は、本発明の一実施形態に従って、ゲートウェイ１０４が無線ゲートウェイとして使用されているシステム８００を表している。ゲートウェイは、ユーザの移動電話、ＰＤＡ、ページャなどから無線メッセージを受信することができる。ゲートウェイ１０４は、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ：ｗｉｒｅｌｅｓｓ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ）、モバイル情報デバイス・プロトコル（ＭＩＤＰ：ｍｏｂｉｌｅ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｖｉｃｅ ｐｒｏｔｏｃｏｌ）、ＪＱＭＥなど、様々な無線形式をサポートするように構成され得る。ＭＩＤｌｅｔは、モバイル・コミュニケーション用グローバル・システム（ＧＳＭ：ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）または汎用パケット無線サービス（ＧＰＲＳ：ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅｓ）などのネットワークを通じてＸＭＬ形式の要求を送信する。ゲートウェイ１０４は、インバウンド要求のペイロードを正規の内部メッセージ形式へ変換し得る。内部メッセージ形式（ＩＭＦ：ｉｎｔｅｒｎａｌ ｍｅｓｓａｇｅ ｆｏｒｍａｔ）は、次いで、ビジネス・サービスによって処理し得る。アウトバウンド・メッセージ・ストリーム・ビルダ２１２が、ＩＭＦを、トランザクション処理装置１０８へ送信するための応答ペイロードへ変換する。故に、ゲートウェイ１０４によって無線トランザクションを処理することができる。
【００９３】
ここで無線トランザクションについて説明する。一実施形態では、無線クライアント８０８が、ＨＴＴＰ（Ｓ）／ＧＳＭ／ＧＰＲＳを通じてＸＭＬ要求を送信することによって、無線支払トランザクションを開始する。ゲートウェイ１０４は、ＸＭＬ要求を受信し、この要求を処理する前に、正規の内部メッセージ形式へ変換する。トランザクションをトランザクション処理装置１０８へ切り替えるのに、伝送環境の現状に加え、トランザクションのアプリケーション・レベルの内容を使用する。選択されたトランザクション処理装置１０８によっては、フロー・ハンドラ２１０が、トランザクションに対してビジネス・サービスを実施し得る。トランザクションは、その後、トランザクション処理装置１０８へ送信される。
【００９４】
トランザクション処理装置１０８が、クライアントの銀行（あるいはイシュア）８０２を判断し、メッセージをイシュア８０２へ送る。イシュア８０２は、要求を処理し、回答をトランザクション処理装置１０８へ返送する。次いで、トランザクション処理装置１０８が、アクワイアラ８０４へ回答を（トランザクション処理装置に固有の形式で）返送する。ゲートウェイ１０４は、回答を受信し、それをＸＭＬ形式へ変換し、それを無線クライアント８０８へ送信する。故に、ゲートウェイ１０４は、無線トランザクションの支払をルーティングするように構成されている。
【００９５】
図１０は、本発明の一実施形態に従って、ＩＳＯ８５８３のトランザクションを処理するシステム９００を表している。図示されているように、イシュア銀行９０２およびアクワイアラ銀行９０４がトランザクションに参加している。アクワイアラ銀行９０４にあるクライアント・コンピュータ１０２が、ＩＳＯ８５８３要求をゲートウェイ１０４へ送信する。ゲートウェイ１０４は、要求に対処するトランザクション処理装置１０８を選択するために、アプリケーション・レベルの内容および伝送環境の現状を使用する。次に、要求に対して任意のビジネス・サービスが実施された後で、メッセージは、選択されたトランザクション処理装置１０８へ送信される。
【００９６】
トランザクション処理装置１０８は、トランザクションを処理し、それを、承認を得るために適切なイシュア９０２へ切り替える。イシュアは、ＩＳＯ８５８３をトランザクション処理装置１０８へ返送する。トランザクション処理装置１０８は、次に、ゲートウェイ１０４へ回答を送信し、回答は、その後、アクワイアラ銀行１０２のクライアント１０２へ送信される。
【００９７】
一例では、トランザクション処理装置１０８が利用できないことがある。この場合、例えば、処理装置Ａ、データ・センタ０１が利用できなくなっていると考えられる。これが、クライアント１０２にとって、サービスのために望まれる処理装置である場合がある。ゲートウェイ１０４は、その結果、トランザクションを第２処理装置、すなわち処理装置Ａ、データ・センタ０２へ送信する。ゲートウェイ１０４は、第１のデータ・センタの利用可能性について確認し続け得、それが利用可能になり次第、第１のデータ・センタへメッセージをルーティングし始め得る。トランザクションのルートの再選択はクライアント１０２に気付かれない形で行われる。故に、ゲートウェイ１０４のインテリジェントな切り替えを用いて、あらゆるトランザクション処理装置１０８のダウンタイムが回避されている。
【００９８】
別の実施形態では、処理装置Ａのデータ・センタが機能停止し、処理装置ＢおよびＣなど他の処理装置のデータ・センタを使用しなくてはならない場合がある。処理装置ＢおよびＣは、処理装置Ａとは異なる形式でトランザクションを処理すると考えられる。この場合、ゲートウェイ１０４が、トランザクションの形式を、処理装置ＢおよびＣ用の形式と一致する形式へ変換すればよい。フォーマットされたトランザクションは、その後、処理装置ＢまたはＣへ送信される。従って、クライアント１０２には気付かれない形で、様々な処理装置を使用することができる。処理装置が別々の形式を使用している場合であっても、ゲートウェイ１０４が、トランザクションをなおその形式で送るように構成されている。
【００９９】
（メッセージのパース／ビルド）
（パースビルド・エンジンの概要）
図１１は、本発明の一実施形態に従ってメッセージをパースするシステム１０００を表している。システム１０００は、ＩＳＯ８５８３メッセージなどの複数の形式のメッセージ・ストリームについては内部メッセージ形式（ＩＭＦ）と呼ばれる正規のメッセージ形式へパースし、ＩＭＦからは、ＩＳＯ８５８３メッセージ・ストリームなど複数の形式のメッセージ・ストリームをビルドするように構成されている。金融メッセージ・ストリームについて説明が行われているが、当然のことながら、任意の複数の形式のメッセージ・ストリームについて、システム１０００を用いてパースおよびビルドすることができる。
【０１００】
パース／ビルド・エンジン１００４は、図２のインバウンド・メッセージ・ストリーム・パーサ２０４およびアウトバウンド・メッセージ・ストリーム・ビルダ２１２に相当する。図２に示されている構成要素の全てが図１１に示されているわけではないが、当然のことながら、それらの構成要素もシステム１０００へ含めることができる。加えて、パース／ビルド・エンジン１００４は、ゲートウェイ１０４へ含まれていてもよいし、あるいは他の構成要素に含まれていてもよい。例えば、パース／ビルド・エンジン１００４は、他の異機種システムとは異なるデータ形式でデータを処理する任意のソフトウェア・アプリケーションと適合可能であり得る。
【０１０１】
パース／ビルド・エンジン１００４は、システム１００６から入力メッセージ・ストリーム１０１０を受信し、このメッセージを内部メッセージ形式へパースするように構成されている。内部メッセージ形式（ＩＭＦ）は、次いで、ビジネス・サービス・アプリケーションなど、ゲートウェイ１０４内に示される他の構成要素によって処理することができる。ゲートウェイ１０４内の構成要素がＩＭＦのメッセージを処理した後、パース／ビルド・エンジン１００４は、処理されたＩＭＦから、出力メッセージ・ストリーム１０１２をビルドする。出力メッセージ・ストリーム１０１２は、次に、システム１００８へ送信されるか、または発信元のシステム１００６へ返送され得る。
【０１０２】
システム１００６および１００８は、メッセージ１０１０を送信、および／または、パース／ビルド・エンジン１００４（またはゲートウェイ１０４）からのメッセージ１０１２を受信するように、構成されている任意のシステムであり得る。一実施形態では、システム１００６および１００８は、販売時点管理デバイス、スマート・カード・デバイス、トランザクション処理装置１０８、あるいはアクワイアラ、イシュア、サービス・プロバイダ、トランザクション認証機能などトランザクションを処理するように構成されている任意のシステムであり得る。システム１００６および１００８は、ＩＳＯ８５８３メッセージ、拡張マークアップ言語（ＸＭＬ）、ＨＴＭＬなど多数の異なる形式のメッセージを送信／受信し得る。入力メッセージ・ストリームは、ＡＳＣＩＩ、ＥＢＣＤＩＣ、ＢＣＤなど多数の符号化方式のいずれを使っていてもよく、数字、文字列、バイト配列など様々なデータ型を有していてもよい。
【０１０３】
図１１のパース／ビルド・エンジンはスキーマ・テーブル１０２８を使用している。各スキーマは、受信形式に関する文法構造のほか、ハンドラ・テーブル１０３０内のハンドラへのポインタを含んだメタデータを提供するデータ構造である。ハンドラは、メッセージ内の特定のフィールドに対応し、文法構造を使用して、メッセージの様々なフィールドを内部メッセージ形式へ変換する。ハンドラは、個別にコンパイルされているコードである。故に、システム全体をコンパイルするのではなく、ハンドラが１つずつコンパイルされているために、エンジンの他のエレメントを妨害することなく、容易にアップグレードが可能なモジュラ・システムを保持しつつも、コンパイルされたソフトウェアの処理の速さを実現している。
【０１０４】
パース／ビルド・エンジン１００４は、識別されたスキーマをロードし、スキーマと関連するハンドラの機能を起動する。ハンドラは、次いで、メッセージのフィールドをＩＭＦオブジェクトにパースする。
【０１０５】
まだロードされていないスキーマおよび関連する任意のハンドラについては、スキーマ・ローダ１０２４を使用して、スキーマ定義ファイル１０２６からスキーマ・テーブル１０２８およびハンドラ・テーブル１０３０へロードすることができる。スキーマ・テーブル１０２６は、スキーマ名１、スキーマ名２からスキーマ名Ｎと表記された多様なスキーマを含んでいる。パース／ビルド・エンジン１００４によってパースおよびビルドされ得る各メッセージ形式に関して、対応するスキーマが提供され得る。各スキーマ名は、外部形式でのメッセージ・ストリーム構成である「文法」を定義するスキーマ・オブジェクトと関連している。構成には、フィールド順序、フィールド型、長さ、文字コード、および他の任意あるいは必須のフィールドを含めることができる。新しいスキーマおよびコンパイルされたハンドラについては、パース／ビルド・エンジン１００４を再コンパイルすることなく、パース／ビルド・エンジン１００４によってロードおよび使用することができる。
【０１０６】
（パース／ビルドフロー）
ここでフローの一例を説明する。図１１に示されているように、メッセージを受信すると、ビジネス・サービス・プログラムがパース／ビルド・エンジン１００４を呼び出す。メッセージ１０１０（ワイヤ形式のメッセージ・ストリーム）がパース／ビルド・エンジンへ送信され、ここでは、まずパーサ構成要素１０１６によって受信される。ビジネス・サービス・アプリケーションは、パーサ構成要素１０１６へ、スキーマ名１０１１も提供する。パーサ構成要素は、内部メッセージ形式（ＩＭＦ）のオブジェクトを作成し、その中に、メッセージ・フィールドから得られる値を、それがＩＭＦへ変換され次第、保存する。一実施形態では、パーサ構成要素１０１６が、メッセージ１０１０の起点を認識し、この起点から送信されたメッセージ１０１０にはどのスキーマが必要であるかを判断する。別の実施形態では、メッセージ１０１０内の情報がパースされて、使用すべきデータ形式、ひいては対応するスキーマを、判断することができる。さらには、メッセージ１０１０が、データ形式に対応するスキーマがどれであるかを指摘してもよい。
【０１０７】
一例では、パーサ構成要素１０１６が、ＩＳＯ８５８３の金融メッセージなど検出されたメッセージの形式に対応するルート・スキーマをまず検索する。ＩＳＯメッセージなどは、最初にビットマップを有し、どのフィールドが存在するかを特定していることがある。ルート・スキーマは、ハンドラを指し示し、このハンドラが呼び出されてタイプ・フィールドをパースし、どのようなタイプのメッセージが受信されたのか（例えば、承認メッセージ、調整メッセージなど）を判断する。パーサ構成要素は、次に、特定されたメッセージ・タイプ用のスキーマを検索し、スキーマが、今度は、特定の文法を提供し、そのメッセージ・タイプ用のハンドラを指し示す。スキーマおよびハンドラは、メッセージ中に実際に存在するフィールドに関するものだけが検索され呼び出される。新たにフィールドが特定または示唆されると、新たにスキーマが検索され、対応するハンドラが呼び出されることが可能になる。特定のフィールドを１つ以上の条件を備えた複合型のフィールドとすることも考えられ、条件の変換またはパースをすることにより、条件の結果に応じて、付加的なスキーマおよび必要な関連スキーマを指し示すことが可能となる。
【０１０８】
ＩＭＦオブジェクト１０１８（後にさらに詳述する）は、呼び出されたハンドラによって埋め込みが行われる。埋め込みされているフィールドのみが、着信メッセージに含まれているフィールドと対応するフィールドである。
【０１０９】
ＩＭＦオブジェクト１０１８は、次に、ゲートウェイ１０４のビジネス・ソフトウェア・アプリケーションによって処理され得る。処理された後で、ＩＭＦオブジェクト１０１８は、アウトバウンド・メッセージ・ストリーム用のスキーマ名と共に、ビルダ構成要素１０２０へ送信される。処理済みのＩＭＦオブジェクト１０１８の処理は別のデータ形式で実施され得るので、ビルダ構成要素１０２０が、処理済みのＩＭＦオブジェクト１０１８から出力メッセージ・ストリーム１０１２をビルドするように構成されている。前述の処理が逆順に繰り返され、そこでは、ビルダ構成要素１０２０がルート・スキーマを検索し、何度も繰り返され得る処理において、タイプの情報をビルドするために指し示されたハンドラを呼び出す。呼び出されたハンドラは、ＩＭＦオブジェクト１０１８の中にある値をフィールドに組み込み、これが出力メッセージ・ストリーム１０１２に含まれるようになる。出力メッセージ・ストリーム１０１２は、次に、出力メッセージ・ストリーム１０１２を処理することのできるシステム１００８へ送信され得る。
【０１１０】
図１２はゲートウェイ１０４によって提供される任意のサービスを実施するのにＩＭＦオブジェクトを使用するビジネス・サービス・アプリケーション１１０２を説明している。ビジネス・サービス・アプリケーション１１０２はＩＭＦオブジェクト１０１８に対して動作する。この動作には、メッセージの送信先のイシュア銀行あるいは処理センタを判断するなど、アプリケーション層のルーティングを含めることができると考えられる。加えて、メッセージ・ストリームのアプリケーション・レベルのフォーマット、ロギング、タイムスタンピング、応答またはさらなる処理に必要な新しいフィールドの作成など、メッセージに対してサービスを実施してもよい。ビジネス・サービス・アプリケーションは、イシュアまたは金融ネットワークに関する前処理を行うことが可能と考えられ、あるいは負荷を分担している局所の処理を実施することも可能と考えられる。例えば、５０ドルより小額の購入に対する承認メッセージが、承認を求めて金融機関へメッセージを転送する必要を伴わずに許可され、応答メッセージが送信され得る。ビジネス・サービス・アプリケーション１１０２は、外部形式ではなく内部メッセージ形式でデータを処理するように構成されている。故に、ビジネス・サービス・アプリケーション１１０２は、メッセージをＩＭＦにパースすることにより、他のシステムによって使用されているあらゆる外部形式から隔離されている。
【０１１１】
（ＩＭＦ構造）
図１３Ａは、本発明の一実施形態によるＩＭＦ１０１８の構造を表している。図示されているように、ＩＭＦ１０１８には、Ｎ個のフィールドが設けられている。フィールドは、フィールドの配列であってもよく、ここでは各フィールドが不特定多数の子フィールドを含むこともでき、ひいては孫フィールドなどを階層型構造で含むこともできる。例えば、フィールド１は、子フィールド１．１、１．２、から１．Ｎを含んでいる。フィールド１．２から１．Ｎが、さらに、不特定多数の子フィールド（図示せず）を含むこともできる。メッセージを受信すると、実際に使用されているフィールドだけにデータが埋め込まれる。
【０１１２】
図１４Ｂは、図１３Ａに示されているフィールドのフィールド定義についてのインデックスであるオブジェクトＩＤコードに関する階層化された形式を示している。ＯＩＤにより、ＩＭＦオブジェクト１０１８内の多様なフィールドをインデキシングすることができる。ＩＭＦオブジェクト１０１８内のフィールドに関して、ＯＩＤを使用してフィールド定義へアクセスする。一実施形態では、ＯＩＤが８バイトの番号であって、図のようにドット付き１０進表記で表されている。第１フィールドのＯＩＤは、１．０．０と符号化されている。任意のサブフィールドについて、１．１．０、１．２．０などと符号化される。第２フィールドは２．０．０と符号化され、２．１．０、２．２．０などと符号化される任意のサブフィールドを伴う。
【０１１３】
（スキーマ構造）
図１３Ｂはスキーマの例を示している。スキーマのアドレスは、第１行目であり、メッセージの定義（ＭｅｓｓａｇｅＤｅｆ）である。スキーマには、メッセージ内の各フィールドに関する、文法およびハンドラへのポインタを含んでいる。図示されている例では、メッセージの第１フィールドは、インデックス１．０．０を伴うＦｉｅｌｄ Ｄｅｆｉｎｉｔｉｏｎ Ｏｂｊｅｃｔ（ＦｉｅｌｄＤｅｆ）１２０２で特定される。これを、ＯＩＤ属性１２０２とも称する。このフィールドのインデックスに続くのは、呼び出されるハンドラ１２０４（ＨＤＲ）の識別表示である。その行の残りのエレメントは、その特定のフィールドに関する文法の定義である。これらのフィールド定義は、フィールド順序、フィールド型、長さ、文字コード、必要なハンドラ名などのフィールドの特性を述べている。フィールド定義は、ＡＳＣＩＩ、ＥＢＣＤＩＣ、ＢＣＤなどの様々なコード、および数字、文字列、バイト配列などの様々なデータ型で符号化されているフィールドを、パース／ビルドするのに使用され得る。故に、メッセージ定義を使用して、複数の形式のメッセージ・ストリームを処理することができる。一実施形態では、スキーマは、ＸＭＬスキーマの形をとったメタデータである。
【０１１４】
フィールド定義には、多くの属性を含めることができる。当然のことながら、図１３Ｂに表されている属性は網羅的なものではなく、他の属性を使用してもよいことが当業者には十分理解されよう。
【０１１５】
ハンドラ属性１２０４は、フィールド名である。必須／任意属性１２０６はメッセージ内でフィールドが必須あるいは任意のいずれであるかを示す。第１データ形式属性１２０８は、外部形式（ワイヤ形式とも称される）でのフィールド値のデータ形式である。第２データ形式属性１２１０は、フィールドがＩＭＦで保存されビジネス・サービスによって処理される、内部形式である。
【０１１６】
カスタム／非カスタム属性１２１２は、フィールドがカスタム・ハンドラあるいは汎用ハンドラのいずれを使用してフィールドのパースおよびビルドを行うかを示す。
【０１１７】
第７の属性１２１４は、メッセージのフィールド内の値を処理するのに必要なハンドラ名を示す。ハンドラは、受信メッセージ内の識別されたフィールドの値を取り込み、それを（パーサ・スキーマ用に）ＩＭＦにパースするか、あるいは値を（ビルダ・スキーマ用に）ＩＭＦから外部形式へビルドするかのいずれかを行う。
【０１１８】
第８の属性１２１６は、フィールド内のサブフィールド数を示す。
【０１１９】
（ＩＭＦ（内部メッセージ形式）で使用されるメッセージ・フィールド例）
図１４Ａは、特定のメッセージ・オブジェクト１０１０に使用されるフィールドの例を表しており、これは、様々なフィールド用のいくつかのオブジェクトＩＤ（ＯＩＤ）、すなわちＯＩＤ１．０．０、１．１．０、１．１．１、２．０．０、２．２．０、４．０．０、および４．１．０を含んでいる。これらは、図１３Ｂのスキーマによって指し示されているフィールドである。従って、このメッセージ例に関しては、図１３Ａで示されているメッセージ・オブジェクトの中で、図１４Ｃで特定されているフィールドだけが埋め込みされると考えられる。図１４Ｂは、内部メッセージ形式での完全な一式のフィールド用の階層型オブジェクトＩＤ全体の一部分を示している。図に示すように、メッセージ１０１０は、これらのフィールドのうち、自分が必要とする一部分のみを含んでいる。例えば、オブジェクトＩＤ１．２．０、３．０．０、および４．２．０は使用されていない。なお、これらのフィールドが不特定多数の子フィールドを有してもよい。
【０１２０】
オブジェクトＩＤは、図１３Ａに示されているメッセージ・オブジェクトの階層型内部メッセージ形式への、高速インデキシング・システムを提供する。このインデキシング・システムは、符号化されたオブジェクトＩＤ（１．０．０など）を使用しており、これらが、受信された形式で使用されている各フィールドに関して、内部メッセージ形式の対応するフィールドへインデックスする（対応するフィールドを指し示す）。インデックスは、階層型構造の中で数層下にあるフィールドを、直接指し示すことができる。
【０１２１】
ゲートウェイ１０４の構成要素がＩＭＦオブジェクト１０１８を処理するとき、不要なフィールドの処理は実行しない。従って、処理速度が速まる。
【０１２２】
ＩＭＦオブジェクト１０１８へ必要なフィールドを追加することもできる。何らかのフィールドが、ビジネス・サービス・モジュール１１０２またはトランザクション処理装置１０８によって要求され得る。使用する必要のあるフィールドが受信メッセージ１０１０に含まれていないと判断されたら、このフィールドをビジネス・サービス・モジュールによって埋め込み、再送信用にビルドされるメッセージの中へ含ませることができる。従って、図１３Ｂのスキーマにある「必要な」フィールドがメッセージ１０１０に含まれていない場合、ＩＭＦオブジェクト１０１８へ追加され得る。
【０１２３】
（パース／ビルド・エンジンの初期化）
図１５は、ビジネス・サービス・アプリケーションの開始にあたってパース／ビルド・エンジン１００４を初期化する方法の簡略化されたフロー図１４００を表している。ステップ１４０２で、アプリケーションから初期化要求を受信する。要求には、１つ以上のスキーマ定義ファイル１０２６の場所が含まれている。
【０１２４】
ステップ１４０４で、スキーマ定義ファイル１０２６内に見つかったスキーマの確認が行われる。スキーマの確認は、正しい型のデータが示されていること、スキーマによって特定されたハンドラが実際に存在することの検証など、多数の手続きによって行われる。
【０１２５】
ステップ１４０６では、スキーマ定義ファイル１０２６内のスキーマが、ディスクまたは他の記憶収納庫からＤＲＡＭメモリへと、スキーマ・ローダ１０２４を使用して、レジストリ１０２２へロードされる。
【０１２６】
ステップ１４０８で、スキーマで指定されているあらゆるハンドラをレジストリ１０２２へロードする。例えば、メッセージ定義オブジェクトのフィールド定義によって指定されているハンドラは、ハンドラ・テーブル１０３０へロードされる。一実施形態では、ハンドラが、ハンドラ名をキーに使い、オブジェクトとして保存される。
【０１２７】
ステップ１４１０で、ハンドラは、それぞれのメッセージ定義オブジェクトにバインドされる。例えば、或るメッセージ定義オブジェクト内のフィールド定義によって指定されているハンドラは全て、そのメッセージ定義オブジェクトにバインドされる。
【０１２８】
パース／ビルド・エンジン１００４は、今や、スキーマ用に初期化されている。一実施形態では、パース／ビルド・エンジン１００４のコンパイルが必要ではない。これは、フィールド値のパース／ビルドに用いられているコンパイル済みのハンドラを使用しているからである。
【０１２９】
ランタイムで、スキーマは、動的に更新され、パース／ビルド・エンジン１００４へ追加され得る。スキーマは、メッセージ定義オブジェクトを変更することによって更新され得、あるいは新しいメッセージ定義オブジェクトを追加することによって追加され得る。新しくハンドラが必要となる場合にも、コンパイル済みのオブジェクトとして、パース／ビルド・エンジン１００４へ動的に追加され得る。
【０１３０】
スキーマは、パース／ビルド・エンジン１００４を再コンパイルすることもなく、機能停止させることもないままで、追加することが可能である。従って、パース／ビルド・エンジン１００４は、スキーマが更新されている間であっても、メッセージのパース／ビルドを継続することができる。
【０１３１】
（スキーマの追加または更新）
図１６は、本発明の一実施形態によるパース／ビルド・エンジン１００４内のスキーマを動的に追加または更新する方法の簡略化したフロー図１５００を表している。ステップ１５０２で、スキーマを動的に追加または更新するよう求める要求をアプリケーションから受信する。要求には、新しいあるいは更新されたスキーマを含んでいる１つ以上のスキーマ定義ファイル１０２６の場所が含まれている。
【０１３２】
ステップ１５０４で、スキーマ定義ファイル１０２６内に見つかったスキーマの確認が行われる。
【０１３３】
ステップ１５０６で、スキーマ定義ファイル１０２６内のスキーマが、レジストリ１０２２へロードされる。更新されたスキーマが、一連の新しいフィールド定義または変更されたフィールド定義を備えている場合は、新しいまたは変更されたフィールド定義のみをレジストリ１０２２へロードすればよい。スキーマの追加または更新を行っている間、適切なデータ構造には書き込みロックをして、スキーマ変更の結果、処理中のインフライト・メッセージが破損することのないように保護する。スキーマ・ローダ１０２４がスキーマの更新されたバージョンをロードしている間は、インフライト・メッセージは、引き続き以前のバージョンのスキーマを使用する。
【０１３４】
ステップ１５０８で、メッセージ定義オブジェクトで指定されているあらゆるハンドラがレジストリ１０２２へロードされる。パース／ビルド・エンジン１００４が、いずれかのハンドラが既にレジストリ１０２２内にあるかどうかを確認して判断し、これらのハンドラについてはレジストリ１０２２へ再ロードしなくてもよい。その一方で、いずれかのハンドラが変更されていたら、変更されたハンドラがロードされる。
【０１３５】
ステップ１５１０で、ハンドラはそれぞれのメッセージ定義オブジェクトにバインドされる。一実施形態では、新しいまたは変更されたハンドラだけが、更新されているメッセージ定義オブジェクトにバインドされる。今や、パース／ビルド・エンジン１００４は動的に更新されている。
【０１３６】
（パース処理のフロー図）
図１７は、本発明の一実施形態に従って入力メッセージ・ストリーム１０１０をパースする方法の簡略化したフロー図１６００を表している。ステップ１６０２で、メッセージ用のスキーマが決定される。スキーマは、入力メッセージ・ストリーム１０１０を構成しているデータ形式に対応している。
【０１３７】
ステップ１６０４で、スキーマ内のポインタからメッセージ定義オブジェクト用のあらゆるハンドラが決定される。
【０１３８】
ステップ１６０６で、各フィールド用のハンドラがフィールドに添付される。
【０１３９】
ステップ１６０８で、ハンドラが、メッセージのフィールドを変換する。各フィールド用のハンドラが起動される。ハンドラは、スキーマ内のフィールド定義を使用して、フィールドの値をＩＭＦへ変換する。フィールドのＯＩＤは、スキーマ内のそのフィールド用のフィールド定義と、さらにＩＭＦオブジェクト１０１８内の対応するフィールドとの両方を指し示す。
【０１４０】
一実施形態では、パーサ構成要素１０１６が、メッセージ１０１０で読み取られたフィールドのオフセットを維持管理する。例えば、読み取られたバイトの数が、オフセットとして保存される。パーサ構成要素は、各ハンドラが呼ばれるのに従い、このオフセットを減らしてゆく。ハンドラがメッセージ１０１０の終わりに達すると（例えば、オフセットが或る特定の長さに等しくなると）、あるいはメッセージ定義オブジェクト内の最後のフィールド定義に達すると、パーサ構成要素は、変換が完了したことを認識する。
【０１４１】
ステップ１６１０で、変換されたフィールドは、ＩＭＦオブジェクト１０１８の対応する階層に保存される。フィールドのＯＩＤを使用して、変換された値をＩＭＦオブジェクト１０１８の階層内の対応する位置に保存すればよい。
【０１４２】
上述の変換をいずれかの点で失敗した場合は、エラーをゲートウェイ１０４へ返送し得る。パースは継続し得、ＩＭＦオブジェクト１０１８が返送され得る。ただし、ＩＭＦオブジェクト１０１８内にエラー・フラグが記録され得る。
【０１４３】
（ビルド・プロセスのフロー図）
ここで図１８に関連してビルドプロセスを説明する。図１８は、本発明の一実施形態に従って出力メッセージ・ストリーム１０１２をＩＭＦオブジェクト１０１８からビルドする方法の簡略化したフロー図１７００を表している。ステップ１７０２で、スキーマ名およびＩＭＦオブジェクト１０１８が決定される。一実施形態では、ＩＭＦオブジェクト１０１８が最初に決定される。スキーマ名は、ＩＭＦオブジェクト１０１８内の情報に基づいて決定され得る。例えば、スキーマ名が、ＩＭＦオブジェクト１０１８内の情報に保存され得る。さらに、スキーマ名は、ＩＭＦオブジェクト１０１８内の情報が送信される通信路または宛て先システムによって決定され得る。
【０１４４】
ステップ１７０４で、メッセージ定義オブジェクトを使用して、レジストリ１０２２内のスキーマにアドレスする。ステップ１７０６で、スキーマに必要なあらゆるハンドラについても決定される。
【０１４５】
ステップ１７０８で、ＩＭＦオブジェクト１０１８内に見つかった各フィールドに関して、ＩＭＦオブジェクト１０１８の階層内の対応するフィールドから得られる値がロードされる。フィールドのＯＩＤを使用して、フィールド定義にアクセスする。
【０１４６】
ステップ１７１０で、ＩＭＦオブジェクト１０１８のフィールドから、このフィールド用のフィールド定義の属性に従って、値を変換する。従って、ＩＭＦ形式で見つかった値が、他のシステムと互換性のある形式へと変換される。
【０１４７】
ステップ１７１２で、ビルドされた値が、生成された出力メッセージ・ストリーム１０１２の対応するフィールド内に構成される。
【０１４８】
外部形式に必要な或るフィールドに対する、ＩＭＦオブジェクト１０１８内のフィールドの値が見つからない場合、外部メッセージ内のそのフィールドの値は空値に設定されてもよく、または生成されたメッセージが単にメッセージ内にこのフィールドを有さないようにしてもよい。さらに、ＩＭＦオブジェクト１０１８がこのフィールドを有する必要があると決定されていたら、その場合はＩＭＦオブジェクト１０１８内にフィールドが見つからなかったことを示すエラーが返信されればよい。
【０１４９】
本発明の実施形態は、多くの利点を提供する。例えば、アプリケーション・レベルの内容、ネットワーク伝送環境の現状、および／または設定情報の組み合わせを使用して、トランザクションをインテリジェントに切り替えることができる。このことは、クライアントによって送信されるあらゆるトランザクションに価値を付加することになる。例えば、ネットワークまたはトランザクション処理装置において何らかの障害がある場合、トランザクションを、他のネットワークを経由させて他のトランザクション処理装置へ送ることができる。これにより、ダウンタイムおよびトランザクション上の何らかの損失が回避される。
【０１５０】
さらに、アプリケーション・レベルの内容対してビジネス・サービスを適用することができる。これにより、ゲートウェイ１０４に関する柔軟性が高まり、トランザクションをインテリジェントにルーティングすることができるようになる。例えば、データ処理装置１０８が、様々な形式のトランザクションを処理することができる。ゲートウェイ１０４が、トランザクション処理装置に必要とされる形式に基づいてアプリケーション・レベルの内容の形式を変更するように構成され得る。さらに、トランザクションに対して適用することのできるビジネス・サービスにより、ゲートウェイ１０４が、多数の形式またはプロトコルでトランザクションを受信し得る。例えば、無線トランザクション支払、インターネットトランザクション、ＰＯＳトランザクションなどについて処理し得る。これにより、トランザクションの処理における柔軟性を高めることができる。
【０１５１】
本発明の実施形態について、トランザクション処理およびある場合には金融トランザクションとして説明してきたが、当然のことながら、トランザクションは多種多様な領域に関して処理され得る。例えば、音楽共有サービスに関してトランザクションを処理し得る。トランザクションには、音楽のダウンロード要求などが含まれ、続いて、ゲートウェイ１０４がこの要求についてサービス・プロバイダへのインテリジェントな切り替えを行い、要求された内容をクライアントへ送り返し得る。さらに、映像サービスが提供されてもよい。映像の要求は、オンデマンド方式であれペイ・パー・ビュー方式であれ、ゲートウェイ１０４によって受信および処理することができる。リクエストおよびそれに続くダウンロードが、本発明の実施形態に従ってインテリジェントに切り替えられ得る。
【０１５２】
本発明は、制御論理の形で、ソフトウェアまたはハードウェアあるいは両方の組み合わせの中に実装することができる。制御論理は、本発明の実施形態の中で開示された一連のステップ群を情報処理デバイスに実行させるようになっている複数の命令として、情報記憶媒体に保存され得る。本明細書に記載された開示および教示に基づき、当業者には、本発明を実施する他の手段および／または方法についても理解されよう。
【０１５３】
上記の説明は、例示的なものであって、限定的なものではない。開示を検討すれば、本発明には多数の変形例があることが当業者には明らかとなる。故に、本発明の範囲は、上記の説明に準拠して判断されるべきではなく、出願の請求項に準拠して、包括的にあるいは均等物も加えて、判断されるべきである。
【図面の簡単な説明】
【０１５４】
【図１】図１は本発明の一実施形態によるトランザクションを処理するシステムを表す。
【図２】図２は本発明の一実施形態によるゲートウェイのさらに詳細な実施形態を表す。
【図３】図３は本発明の一実施形態によるトランザクションを処理する方法の簡略化したフロー図を表す。
【図４】図４は本発明の一実施形態によるトランザクション処理装置によって提供されるサービスに関する設定情報の生成の簡略化したフロー図を表す。
【図５】図５は本発明の一実施形態によるサービスに加入する方法の簡略化したフロー図を表す。
【図６】図６は本発明の一実施形態による複数のゲートウェイの分散型システムを表す。
【図７】図７は本発明の一実施形態によるゲートウェイをフロントエンド・ゲートウェイとして表示しているシステムを表す。
【図８】図８は本発明の一実施形態によるゲートウェイがインターネット・ゲートウェイであるシステムを表す。
【図９】図９は本発明の一実施形態によるゲートウェイが無線ゲートウェイとして使用されているシステムを表す。
【図１０】図１０は本発明の一実施形態によるＩＳＯ８５８３トランザクションを処理するシステムを表す。
【図１１】図１１は本発明の一実施形態によるメッセージをパースするシステムを表す。
【図１２】図１２は本発明の実施形態によるゲートウェイの一実施形態を開示している。
【図１３Ａ】図１３Ａは本発明の一実施形態によるＩＭＦオブジェクトの構造を表す。
【図１３Ｂ】図１３Ｂは本発明の一実施形態によるメッセージ定義の属性を表す。
【図１４Ａ】図１４Ａ、１４Ｂおよび１４Ｃは、本発明の一実施形態による考え得るメッセージ、オブジェクトＩＤコードの階層化された形式、およびメッセージ用のＩＭＦオブジェクトを表す。
【図１４Ｂ】図１４Ａ、１４Ｂおよび１４Ｃは、本発明の一実施形態による考え得るメッセージ、オブジェクトＩＤコードの階層化された形式、およびメッセージ用のＩＭＦオブジェクトを表す。
【図１４Ｃ】図１４Ａ、１４Ｂおよび１４Ｃは、本発明の一実施形態による考え得るメッセージ、オブジェクトＩＤコードの階層化された形式、およびメッセージ用のＩＭＦオブジェクトを表す。
【図１５】図１５は本発明の一実施形態によるメッセージ・ストリームを処理するパース／ビルド・エンジンを初期化する方法の簡略化したフロー図を表す。
【図１６】図１６は本発明の一実施形態によるパース／ビルド・エンジンにおいてスキーマを動的に追加または更新する方法の簡略化したフロー図を表す。
【図１７】図１７は本発明の一実施形態による入力メッセージをパースする方法の簡略化したフロー図を表す。
【図１８】図１８は本発明の一実施形態によるＩＭＦオブジェクトから出力メッセージをビルドする方法の簡略化したフロー図を表す。
【特許請求の範囲】
【請求項１】
ネットワークのエッジに位置するゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにてトランザクションを受信するステップと、
該トランザクションに関するアプリケーション・レベルの内容を決定するステップと、
該トランザクションが経由して送られる伝送環境に関するアプリケーション・レベルの動的状況情報を決定するステップであって、該伝送環境が、該トランザクションを処理することのできる１つ以上のトランザクション処理装置へ該トランザクションを送ることのできる１つ以上のネットワークを含んでいる、ステップと、
該トランザクションの該動的状況情報および該アプリケーション・レベルの内容に基づいて、該１つ以上のトランザクション処理装置の中のトランザクション処理装置、および該１つ以上のネットワークの中のネットワークへ、該トランザクションを切り替えるステップと
を含む、方法。
【請求項２】
前記トランザクションを送信したクライアントからのクライアント・ルールを決定するステップと、
該クライアント・ルールを使用して、前記動的状況情報に基づいて、該トランザクションを処理できるサービス、前記トランザクション処理装置、または該サービスの一部であるネットワークを決定するステップと
をさらに含む、請求項１に記載の方法。
【請求項３】
サービス・プロバイダ・ルールを決定するステップと、
該サービス・プロバイダ・ルールを使用して、前記動的状況情報に基づいて、前記トランザクションを切り替える前記トランザクション処理装置またはネットワークを決定する、ステップと
をさらに含む、請求項１に記載の方法。
【請求項４】
前記トランザクションの前記アプリケーション・レベルの内容に対するサービスをアプリケーション・レベルで実施するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記サービスが、決定された前記トランザクション処理装置またはネットワークに基づいて実施される、請求項４に記載の方法。
【請求項６】
前記サービスが、前記決定されたトランザクション処理装置に必要とされる形式へ前記内容を前記アプリケーション・レベルでフォーマットするステップを含む、請求項４に記載の方法。
【請求項７】
前記サービスが、前記決定されたネットワークに必要とされる形式へ前記内容を前記アプリケーション・レベルでフォーマットするステップを含む、請求項４に記載の方法。
【請求項８】
前記伝送環境に関する前記動的状況情報が、前記アプリケーション・レベルで以前のトランザクションを処理するのに要した時間を含む、請求項１に記載の方法。
【請求項９】
前記内容が、想定し得る数のフィールドを有するデータ形式になっており、前記アプリケーション・レベルの内容が、該想定し得る数のフィールドのサブセットであり、前記方法が、前記トランザクション内のフィールドの該サブセットだけを処理するステップをさらに含む、請求項１に記載の方法。
【請求項１０】
前記切り替えを処理するために動的に作成されたコードのインスタンスを使用して、ゲートウェイのトランザクションの切り替えに影響を及ぼすことなく、該ゲートウェイへ動的にルールをロードするステップをさらに含む、請求項１に記載の方法。
【請求項１１】
前記トランザクションを前記トランザクション処理装置へ送信することなく、該トランザクションを前記ゲートウェイにて処理するステップをさらに含む、請求項１に記載の方法。
【請求項１２】
ネットワークに接続されたゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにてトランザクションを受信するステップと、
該ネットワークを介してアクセスすることのできる、適切なトランザクション処理装置をアプリケーション・レベルで決定するステップと、
該適切なトランザクション処理装置に必要とされる該アプリケーション・レベルのフォーマッティングを決定するステップと、
該アプリケーション・レベルのフォーマッティングに従って該トランザクションをフォーマットするステップと、
該ネットワークを通じて、該トランザクションを該適切なトランザクション処理装置へ送信するステップと
を含む、方法。
【請求項１３】
ネットワークのエッジに位置するゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにてトランザクションを受信するステップと、
該トランザクションに関するアプリケーション・レベルの内容を決定するステップと、
該アプリケーション・レベルの内容に基づいて、適切なアプリケーション・レベルのトランザクション処理装置を該ネットワークを通じて決定するステップと、
該ネットワークを通じて、該トランザクションを該適切なアプリケーション・レベルのトランザクション処理装置へ送信するステップと
を含む、方法。
【請求項１４】
ネットワーク上のゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにおいて、クライアントからアプリケーション・サービスの選択に関する一連のアプリケーション・レベルのルールを受信するステップと、
該一連のルールを該ゲートウェイにて保存するステップと、
該クライアントから該ゲートウェイにてトランザクションを受信するステップと、
該トランザクションに関するアプリケーション・レベルの内容を決定するステップと、
該一連のルールに基づいて、該トランザクションを処理し、該トランザクションをトランザクション処理装置へ送信するステップと
を含む、方法。
【請求項１５】
ネットワーク上のゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
サービス・プロバイダに関するサービスへクライアントが加入できるように該サービスを発行するステップと、
トランザクションを該サービスのために該サービス・プロバイダへ切り替えることに関するサービス・プロバイダ・ルールを用いて、該ゲートウェイを動的に更新するステップであって、該ゲートウェイが、該動的な更新の後に、該サービスのために該サービス・プロバイダへトランザクションを切り替えるように構成されている、ステップと、
クライアントから該サービスに対する加入要求を受信するステップと、
該クライアントからトランザクションを受信するステップと、
該サービスが該トランザクションに対して実施されるように該トランザクションが該サービス・プロバイダへ切り替えられる必要があるかどうかを決定するステップであって、該決定が、該トランザクションに関する動的状況情報を該サービス・プロバイダ・ルールへ適用することによって行われる、ステップと
を含む、方法。
【請求項１６】
前記トランザクションは前記ゲートウェイにて処理される必要があると決定し、該トランザクションを前記サービス・プロバイダへは切り替えないステップと、
該トランザクションを該ゲートウェイにて処理するステップと、
をさらに含む、請求項１５に記載の方法。
【請求項１７】
前記サービス・プロバイダ・ルールが、前記サービス・プロバイダに必要なトランザクションの形式に関する情報、前記トランザクションを送信するアドレス、または異なるトランザクション処理装置への切り替えの優先順位を含む、請求項１５に記載の方法。
【請求項１８】
クライアントからのトランザクションを切り替えるシステムであって、該システムは、
アプリケーション・レベルでトランザクションを処理するように構成されている、ネットワークのエッジにおける複数のゲートウェイを含み、
各ゲートウェイが該ゲートウェイによって提供される一連のサービスを保存しているという点で、該複数のゲートウェイによって提供されるアプリケーション・レベルのサービスが分散化されており、
各ゲートウェイは、
該ゲートウェイと接続しているクライアントに関するトランザクションを切り替えるのに使用される該一連のサービスに関するルールと、
該複数のゲートウェイの中の他のゲートウェイの連絡先であって、該連絡先は、該一連のサービスの中のサービスに関するルールを別のゲートウェイへ送信して、そのゲートウェイが該サービスを提供できるようにするか、または該一連のサービスの中のサービスに関する別のゲートウェイのルールを問い合わせして、該ゲートウェイが該サービスを提供できるようにすることに使用される、連絡先と
を含む、ゲートウェイである、
システム。
【請求項１９】
サービスに関するルールが、サービス・プロバイダまたはクライアントによって、前記複数のゲートウェイの中の第１ゲートウェイ上にロードされており、該ルールが該複数のゲートウェイの中の該第１ゲートウェイ以外のゲートウェイに分配され得る、請求項１８に記載のシステム。
【請求項２０】
前記複数のゲートウェイの中の第１ゲートウェイが第１の一連のサービスを含み、該複数のゲートウェイの中の第２ゲートウェイが第２の一連のサービスを含んでおり、該第１の一連のサービスが、該第２の一連のサービスに含まれていない少なくとも１つのサービスを含んでいる、請求項１８に記載のシステム。
【請求項２１】
ネットワークのエッジにてトランザクションを切り替えるゲートウェイであって、該ゲートウェイは、
サービス・プロバイダによって提供されるサービスに関するルールを含んでいるルール・データベースと、
該ネットワークおよびサービス・プロバイダに関する動的状況情報を含んでいる状況情報データベースと、
クライアントからトランザクションを受信するように構成されている受信機と、
該トランザクションに関するサービスおよびサービス・プロバイダを決定するように動的状況情報へルールを適用するように構成されているルール・アプライヤと、
該トランザクションに関してフォーマッティングが必要な場合は、該決定されたサービスおよびサービス・プロバイダに基づいて、該トランザクションをアプリケーション・レベルでフォーマットするように構成されているフォーマッタと、
該トランザクションを該サービス・プロバイダへ送信するように構成されている送信機と
を含む、ゲートウェイ。
【請求項２２】
前記ルール・データベースへ、ルールを動的にロードするように構成されているルール・ローダをさらに含む、請求項２１に記載のゲートウェイ。
【請求項２３】
前記ルールが、前記ゲートウェイ上のトランザクションの切り替えに影響を及ぼすことなく動的にロードされる、請求項２２に記載のゲートウェイ。
【請求項２４】
クライアントまたはサービス・プロバイダから、前記ルールが動的にロードされる、請求項２２に記載のゲートウェイ。
【請求項２５】
前記トランザクションを前記サービス・プロバイダへ送信することなく、前記ゲートウェイにて該トランザクションを処理するように構成されているゲートウェイトランザクション処理装置をさらに含む、請求項２１に記載のゲートウェイ。
【請求項２６】
前記動的状況情報が、前記ネットワークの健康状態、前記サービス・プロバイダの利用可能性、前記アプリケーション・レベルで以前のトランザクションを処理するのに要した時間、あるいは該サービス・プロバイダへ該トランザクションを送信する費用を含む、請求項２１に記載のゲートウェイ。
【請求項２７】
トランザクションを切り替えるようにネットワークのエッジに位置するゲートウェイであって、
トランザクションを受信するように構成されているポートと、
該トランザクションに関するアプリケーション・レベルの内容および該トランザクションが経由して送られる伝送環境に関するアプリケーション・レベルの動的状況情報を決定するように構成されている処理装置であって、該伝送環境が、該トランザクションを処理することのできる１つ以上のトランザクション処理装置へ該トランザクションを送ることのできる１つ以上のネットワークを含む、処理装置と、
該トランザクションの該動的状況情報および該アプリケーション・レベルの内容に基づいて、該１つ以上のトランザクション処理装置の中のトランザクション処理装置、および該１つ以上のネットワークの中のネットワークへ該トランザクションを切り替えるように構成されている、スイッチと
を含む、ゲートウェイ。
【請求項２８】
ネットワークに接続している、トランザクションを切り替えるゲートウェイであって、
トランザクションを受信するように構成されているポートと、
該ネットワークを介してアクセスすることのできる適切なトランザクション処理装置を前記アプリケーション・レベルで決定し、該適切なトランザクション処理装置に必要とされる該アプリケーション・レベルのフォーマッティングを決定するように構成されている処理装置と、
該アプリケーション・レベルのフォーマッティングに従って該トランザクションをフォーマットするように構成されているフォーマッタと、
該ネットワークを通じて、該トランザクションを該適切なトランザクション処理装置へ送信するように構成されている送信機と
を含む、ゲートウェイ。
【請求項２９】
ネットワーク上でトランザクションを切り替えるゲートウェイであって、
クライアントから、アプリケーション・サービス選択に関する一連のアプリケーション・レベル・ルールを、該ゲートウェイにて保存するメモリと、
該クライアントから該ゲートウェイにてトランザクションを受信するように構成されているポートと、
該一連のルールに基づいて、該トランザクションに関するアプリケーション・レベルの内容を決定し、該トランザクションを処理し、該トランザクションをトランザクション処理装置へ送信するように構成されている処理装置と
を含む、ゲートウェイ。
【請求項３０】
ネットワーク上でトランザクションを切り替えるゲートウェイであって、
クライアントからの、アプリケーション・サービス選択に関する一連のアプリケーション・レベル・ルールを、該ゲートウェイにて保存するメモリと、
該クライアントから該ゲートウェイにてトランザクションを受信するように構成されているポートと、
該トランザクションを遠隔のトランザクション処理装置へ転送する必要なく、該一連のルールに基づいて該トランザクションに関するアプリケーション・レベルの内容を決定し、該トランザクションを該クライアントへ返送するように構成されている処理装置と
を含む、ゲートウェイ。
【請求項１】
ネットワークのエッジに位置するゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにてトランザクションを受信するステップと、
該トランザクションに関するアプリケーション・レベルの内容を決定するステップと、
該トランザクションが経由して送られる伝送環境に関するアプリケーション・レベルの動的状況情報を決定するステップであって、該伝送環境が、該トランザクションを処理することのできる１つ以上のトランザクション処理装置へ該トランザクションを送ることのできる１つ以上のネットワークを含んでいる、ステップと、
該トランザクションの該動的状況情報および該アプリケーション・レベルの内容に基づいて、該１つ以上のトランザクション処理装置の中のトランザクション処理装置、および該１つ以上のネットワークの中のネットワークへ、該トランザクションを切り替えるステップと
を含む、方法。
【請求項２】
前記トランザクションを送信したクライアントからのクライアント・ルールを決定するステップと、
該クライアント・ルールを使用して、前記動的状況情報に基づいて、該トランザクションを処理できるサービス、前記トランザクション処理装置、または該サービスの一部であるネットワークを決定するステップと
をさらに含む、請求項１に記載の方法。
【請求項３】
サービス・プロバイダ・ルールを決定するステップと、
該サービス・プロバイダ・ルールを使用して、前記動的状況情報に基づいて、前記トランザクションを切り替える前記トランザクション処理装置またはネットワークを決定する、ステップと
をさらに含む、請求項１に記載の方法。
【請求項４】
前記トランザクションの前記アプリケーション・レベルの内容に対するサービスをアプリケーション・レベルで実施するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記サービスが、決定された前記トランザクション処理装置またはネットワークに基づいて実施される、請求項４に記載の方法。
【請求項６】
前記サービスが、前記決定されたトランザクション処理装置に必要とされる形式へ前記内容を前記アプリケーション・レベルでフォーマットするステップを含む、請求項４に記載の方法。
【請求項７】
前記サービスが、前記決定されたネットワークに必要とされる形式へ前記内容を前記アプリケーション・レベルでフォーマットするステップを含む、請求項４に記載の方法。
【請求項８】
前記伝送環境に関する前記動的状況情報が、前記アプリケーション・レベルで以前のトランザクションを処理するのに要した時間を含む、請求項１に記載の方法。
【請求項９】
前記内容が、想定し得る数のフィールドを有するデータ形式になっており、前記アプリケーション・レベルの内容が、該想定し得る数のフィールドのサブセットであり、前記方法が、前記トランザクション内のフィールドの該サブセットだけを処理するステップをさらに含む、請求項１に記載の方法。
【請求項１０】
前記切り替えを処理するために動的に作成されたコードのインスタンスを使用して、ゲートウェイのトランザクションの切り替えに影響を及ぼすことなく、該ゲートウェイへ動的にルールをロードするステップをさらに含む、請求項１に記載の方法。
【請求項１１】
前記トランザクションを前記トランザクション処理装置へ送信することなく、該トランザクションを前記ゲートウェイにて処理するステップをさらに含む、請求項１に記載の方法。
【請求項１２】
ネットワークに接続されたゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにてトランザクションを受信するステップと、
該ネットワークを介してアクセスすることのできる、適切なトランザクション処理装置をアプリケーション・レベルで決定するステップと、
該適切なトランザクション処理装置に必要とされる該アプリケーション・レベルのフォーマッティングを決定するステップと、
該アプリケーション・レベルのフォーマッティングに従って該トランザクションをフォーマットするステップと、
該ネットワークを通じて、該トランザクションを該適切なトランザクション処理装置へ送信するステップと
を含む、方法。
【請求項１３】
ネットワークのエッジに位置するゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにてトランザクションを受信するステップと、
該トランザクションに関するアプリケーション・レベルの内容を決定するステップと、
該アプリケーション・レベルの内容に基づいて、適切なアプリケーション・レベルのトランザクション処理装置を該ネットワークを通じて決定するステップと、
該ネットワークを通じて、該トランザクションを該適切なアプリケーション・レベルのトランザクション処理装置へ送信するステップと
を含む、方法。
【請求項１４】
ネットワーク上のゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
該ゲートウェイにおいて、クライアントからアプリケーション・サービスの選択に関する一連のアプリケーション・レベルのルールを受信するステップと、
該一連のルールを該ゲートウェイにて保存するステップと、
該クライアントから該ゲートウェイにてトランザクションを受信するステップと、
該トランザクションに関するアプリケーション・レベルの内容を決定するステップと、
該一連のルールに基づいて、該トランザクションを処理し、該トランザクションをトランザクション処理装置へ送信するステップと
を含む、方法。
【請求項１５】
ネットワーク上のゲートウェイを使用してトランザクションを切り替える方法であって、該方法は、
サービス・プロバイダに関するサービスへクライアントが加入できるように該サービスを発行するステップと、
トランザクションを該サービスのために該サービス・プロバイダへ切り替えることに関するサービス・プロバイダ・ルールを用いて、該ゲートウェイを動的に更新するステップであって、該ゲートウェイが、該動的な更新の後に、該サービスのために該サービス・プロバイダへトランザクションを切り替えるように構成されている、ステップと、
クライアントから該サービスに対する加入要求を受信するステップと、
該クライアントからトランザクションを受信するステップと、
該サービスが該トランザクションに対して実施されるように該トランザクションが該サービス・プロバイダへ切り替えられる必要があるかどうかを決定するステップであって、該決定が、該トランザクションに関する動的状況情報を該サービス・プロバイダ・ルールへ適用することによって行われる、ステップと
を含む、方法。
【請求項１６】
前記トランザクションは前記ゲートウェイにて処理される必要があると決定し、該トランザクションを前記サービス・プロバイダへは切り替えないステップと、
該トランザクションを該ゲートウェイにて処理するステップと、
をさらに含む、請求項１５に記載の方法。
【請求項１７】
前記サービス・プロバイダ・ルールが、前記サービス・プロバイダに必要なトランザクションの形式に関する情報、前記トランザクションを送信するアドレス、または異なるトランザクション処理装置への切り替えの優先順位を含む、請求項１５に記載の方法。
【請求項１８】
クライアントからのトランザクションを切り替えるシステムであって、該システムは、
アプリケーション・レベルでトランザクションを処理するように構成されている、ネットワークのエッジにおける複数のゲートウェイを含み、
各ゲートウェイが該ゲートウェイによって提供される一連のサービスを保存しているという点で、該複数のゲートウェイによって提供されるアプリケーション・レベルのサービスが分散化されており、
各ゲートウェイは、
該ゲートウェイと接続しているクライアントに関するトランザクションを切り替えるのに使用される該一連のサービスに関するルールと、
該複数のゲートウェイの中の他のゲートウェイの連絡先であって、該連絡先は、該一連のサービスの中のサービスに関するルールを別のゲートウェイへ送信して、そのゲートウェイが該サービスを提供できるようにするか、または該一連のサービスの中のサービスに関する別のゲートウェイのルールを問い合わせして、該ゲートウェイが該サービスを提供できるようにすることに使用される、連絡先と
を含む、ゲートウェイである、
システム。
【請求項１９】
サービスに関するルールが、サービス・プロバイダまたはクライアントによって、前記複数のゲートウェイの中の第１ゲートウェイ上にロードされており、該ルールが該複数のゲートウェイの中の該第１ゲートウェイ以外のゲートウェイに分配され得る、請求項１８に記載のシステム。
【請求項２０】
前記複数のゲートウェイの中の第１ゲートウェイが第１の一連のサービスを含み、該複数のゲートウェイの中の第２ゲートウェイが第２の一連のサービスを含んでおり、該第１の一連のサービスが、該第２の一連のサービスに含まれていない少なくとも１つのサービスを含んでいる、請求項１８に記載のシステム。
【請求項２１】
ネットワークのエッジにてトランザクションを切り替えるゲートウェイであって、該ゲートウェイは、
サービス・プロバイダによって提供されるサービスに関するルールを含んでいるルール・データベースと、
該ネットワークおよびサービス・プロバイダに関する動的状況情報を含んでいる状況情報データベースと、
クライアントからトランザクションを受信するように構成されている受信機と、
該トランザクションに関するサービスおよびサービス・プロバイダを決定するように動的状況情報へルールを適用するように構成されているルール・アプライヤと、
該トランザクションに関してフォーマッティングが必要な場合は、該決定されたサービスおよびサービス・プロバイダに基づいて、該トランザクションをアプリケーション・レベルでフォーマットするように構成されているフォーマッタと、
該トランザクションを該サービス・プロバイダへ送信するように構成されている送信機と
を含む、ゲートウェイ。
【請求項２２】
前記ルール・データベースへ、ルールを動的にロードするように構成されているルール・ローダをさらに含む、請求項２１に記載のゲートウェイ。
【請求項２３】
前記ルールが、前記ゲートウェイ上のトランザクションの切り替えに影響を及ぼすことなく動的にロードされる、請求項２２に記載のゲートウェイ。
【請求項２４】
クライアントまたはサービス・プロバイダから、前記ルールが動的にロードされる、請求項２２に記載のゲートウェイ。
【請求項２５】
前記トランザクションを前記サービス・プロバイダへ送信することなく、前記ゲートウェイにて該トランザクションを処理するように構成されているゲートウェイトランザクション処理装置をさらに含む、請求項２１に記載のゲートウェイ。
【請求項２６】
前記動的状況情報が、前記ネットワークの健康状態、前記サービス・プロバイダの利用可能性、前記アプリケーション・レベルで以前のトランザクションを処理するのに要した時間、あるいは該サービス・プロバイダへ該トランザクションを送信する費用を含む、請求項２１に記載のゲートウェイ。
【請求項２７】
トランザクションを切り替えるようにネットワークのエッジに位置するゲートウェイであって、
トランザクションを受信するように構成されているポートと、
該トランザクションに関するアプリケーション・レベルの内容および該トランザクションが経由して送られる伝送環境に関するアプリケーション・レベルの動的状況情報を決定するように構成されている処理装置であって、該伝送環境が、該トランザクションを処理することのできる１つ以上のトランザクション処理装置へ該トランザクションを送ることのできる１つ以上のネットワークを含む、処理装置と、
該トランザクションの該動的状況情報および該アプリケーション・レベルの内容に基づいて、該１つ以上のトランザクション処理装置の中のトランザクション処理装置、および該１つ以上のネットワークの中のネットワークへ該トランザクションを切り替えるように構成されている、スイッチと
を含む、ゲートウェイ。
【請求項２８】
ネットワークに接続している、トランザクションを切り替えるゲートウェイであって、
トランザクションを受信するように構成されているポートと、
該ネットワークを介してアクセスすることのできる適切なトランザクション処理装置を前記アプリケーション・レベルで決定し、該適切なトランザクション処理装置に必要とされる該アプリケーション・レベルのフォーマッティングを決定するように構成されている処理装置と、
該アプリケーション・レベルのフォーマッティングに従って該トランザクションをフォーマットするように構成されているフォーマッタと、
該ネットワークを通じて、該トランザクションを該適切なトランザクション処理装置へ送信するように構成されている送信機と
を含む、ゲートウェイ。
【請求項２９】
ネットワーク上でトランザクションを切り替えるゲートウェイであって、
クライアントから、アプリケーション・サービス選択に関する一連のアプリケーション・レベル・ルールを、該ゲートウェイにて保存するメモリと、
該クライアントから該ゲートウェイにてトランザクションを受信するように構成されているポートと、
該一連のルールに基づいて、該トランザクションに関するアプリケーション・レベルの内容を決定し、該トランザクションを処理し、該トランザクションをトランザクション処理装置へ送信するように構成されている処理装置と
を含む、ゲートウェイ。
【請求項３０】
ネットワーク上でトランザクションを切り替えるゲートウェイであって、
クライアントからの、アプリケーション・サービス選択に関する一連のアプリケーション・レベル・ルールを、該ゲートウェイにて保存するメモリと、
該クライアントから該ゲートウェイにてトランザクションを受信するように構成されているポートと、
該トランザクションを遠隔のトランザクション処理装置へ転送する必要なく、該一連のルールに基づいて該トランザクションに関するアプリケーション・レベルの内容を決定し、該トランザクションを該クライアントへ返送するように構成されている処理装置と
を含む、ゲートウェイ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３Ａ】
【図１３Ｂ】
【図１４Ａ】
【図１４Ｂ】
【図１４Ｃ】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３Ａ】
【図１３Ｂ】
【図１４Ａ】
【図１４Ｂ】
【図１４Ｃ】
【図１５】
【図１６】
【図１７】
【図１８】
【公表番号】特表２００９−５００７３１（Ｐ２００９−５００７３１Ａ）
【公表日】平成２１年１月８日（２００９．１．８）
【国際特許分類】
【出願番号】特願２００８−５１９６６８（Ｐ２００８−５１９６６８）
【出願日】平成１８年６月２９日（２００６．６．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２５８８７
【国際公開番号】ＷＯ２００７／００２９３２
【国際公開日】平成１９年１月４日（２００７．１．４）
【出願人】（５０６１５４７２０）ビザ ユー．エス．エー． インコーポレイテッド (7)
【出願人】（５００３１３５９２）ビザ・インターナショナル・サービス・アソシエーション (8)
【Ｆターム（参考）】
【公表日】平成２１年１月８日（２００９．１．８）
【国際特許分類】
【出願日】平成１８年６月２９日（２００６．６．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２５８８７
【国際公開番号】ＷＯ２００７／００２９３２
【国際公開日】平成１９年１月４日（２００７．１．４）
【出願人】（５０６１５４７２０）ビザ ユー．エス．エー． インコーポレイテッド (7)
【出願人】（５００３１３５９２）ビザ・インターナショナル・サービス・アソシエーション (8)
【Ｆターム（参考）】
[ Back to top ]