JP2018501593A - 電子トランザクション要求を処理するための装置、システム、方法及びコンピュータプログラム製品 - Google Patents

電子トランザクション要求を処理するための装置、システム、方法及びコンピュータプログラム製品 Download PDF

Info

Publication number
JP2018501593A
JP2018501593A JP2017551371A JP2017551371A JP2018501593A JP 2018501593 A JP2018501593 A JP 2018501593A JP 2017551371 A JP2017551371 A JP 2017551371A JP 2017551371 A JP2017551371 A JP 2017551371A JP 2018501593 A JP2018501593 A JP 2018501593A
Authority
JP
Japan
Prior art keywords
message
transaction
switch
bank
request message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017551371A
Other languages
English (en)
Other versions
JP6474915B2 (ja
Inventor
ジョージ ガーリック スティーブン
ジョージ ガーリック スティーブン
アントニー マスターズ ニール
アントニー マスターズ ニール
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
IPCO 2012 Ltd
Original Assignee
IPCO 2012 Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=54337806&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=JP2018501593(A) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by IPCO 2012 Ltd filed Critical IPCO 2012 Ltd
Publication of JP2018501593A publication Critical patent/JP2018501593A/ja
Application granted granted Critical
Publication of JP6474915B2 publication Critical patent/JP6474915B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825Use of electronic signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

金融機関からの電子トランザクション要求メッセージを処理するための装置であって、各トランザクション要求メッセージは第1の金融機関内の金融口座から第2の金融機関内の別の金融口座へと資金の払い込みを指示し、該装置は、ある位置に配置された複数のスイッチであって、各スイッチは金融機関からのトランザクション要求メッセージを受信するように動作可能である、複数のスイッチと、複数のスイッチに接続されたクラスターデータベースであって、クラスターデータベースは複数の同期化されたデータベースを備えており、クラスターデータベースは受信されたトランザクション要求メッセージに基づいてトランザクションサマリ記録を生成するように構成されており、トランザクションサマリ記録は受信されたトランザクション要求メッセージによって定義された金融口座間での資金決済を可能とする、クラスターデータベースとを備える、装置を開示する。

Description

本発明は、電子トランザクション要求を処理するための装置、システム、方法及びコンピュータプログラム製品に関する。
本明細書にて示される「背景」の目的は、本願開示の背景的文脈を一般的に提示することである。背景に関してのセクションにおいて述べられている限りにおいて本願にて特定される発明者の功績、及び、出願時において先行技術と分類されないかもしれない本願明細書の側面は、本発明との関係では明示的に又は黙示的に先行技術として自認されない。
現代的な電子銀行システムは、電子トランザクション要求メッセージ(トランザクションメッセージ)を用いることによって、異なる銀行の銀行口座間での資金の電子的移転を可能とする。このような資金移転の方法は、(ネットワーク上でのセキュアなデータ移転を可能とする様々な既知のセキュリティプロトコルを用いることによって)セキュアであり、また、(該方法によって銀行口座保有者は任意の時、即ち年間365日、一日中24時間にわたって資金移転の要求を発することができる故に)便利である。
もっとも、このような電子トランザクション要求メッセージは何時でも発せられるのに対して、銀行間での資金の実際の移転は周期的にしか行われない。この様式は、「決済サイクル」モデルとして知られている。各決済サイクル中に、銀行によって発行されたトランザクションメッセージが受信及び記録される。そして、決済サイクルの終わりにおいて、記録されたトランザクションメッセージに基づいて、資金が実際に銀行間で移転される(これが「決済」と称される)。決済サイクル間の期間は典型的には8時間、12時間又は24時間であるが、任意の適切な周期を用いることができる。
後になされる銀行間決済が、決済サイクル中になされた記録されたトランザクションメッセージに基づいているため、記録されたトランザクションメッセージが効率的に格納及び管理されることが至上命題であり、例えば技術的な故障や自然災害の場合においてもこのことは変わらない。こうすれば、各決済サイクルの終末時において、完了されたトランザクションの各々が決済に際して考慮され、かつ、1回だけ考慮されることが保証される。これによって、銀行間での現金の過剰な又は過小な支払いが防止される。したがって、本発明は、電子トランザクションメッセージを効率的に格納及び管理することに関しての頑健かつ柔軟なシステムを提供する、という課題に関する問題を緩和することを少なくとも目的とする。
本発明は、金融機関からの電子トランザクション要求メッセージを処理するための装置であって、各トランザクション要求メッセージは第1の金融機関内のある金融口座から第2の金融機関内の別の金融口座へと資金の払い込みを指示し、該装置は、ある位置に配置された複数のスイッチであって、各スイッチは金融機関からのトランザクション要求メッセージを受信するように動作可能である、複数のスイッチと、複数のスイッチに接続されたクラスターデータベースであって、クラスターデータベースは複数の同期化されたデータベースを備えており、クラスターデータベースは受信されたトランザクション要求メッセージに基づいてトランザクションサマリ記録を生成するように構成されており、トランザクションサマリ記録は受信されたトランザクション要求メッセージによって定義された金融口座間での資金決済を可能とする、クラスターデータベースとを備える、装置を提供する。
有利なことに、この構成によれば、同期化されたデータベースの一方が(故障又は計画された保守作業等によって)非稼働状態に陥ってもトランザクションサマリ記録のデータは依然アクセス可能なままとなる。したがって、より高度な頑健性を伴う電子トランザクションを処理するための構成が達成される。
実施形態では、各トランザクション要求メッセージはトランザクション要求メッセージが関連付けられているトランザクションを一意的に識別する識別子を含み、装置は識別子に基づいてトランザクション要求メッセージを特定のスイッチへとルーティングする処理回路を備える。
実施形態では、各トランザクション要求メッセージはデジタル署名で署名されており、処理回路は署名されたトランザクション要求メッセージを検証するように動作可能であり、署名されたトランザクション要求メッセージを検証できない場合において処理回路はトランザクション要求メッセージを金融機関へと返送するように動作可能である。
実施形態では、処理回路は、装置にて検証不能なトランザクション要求メッセージが受信されたことについて金融機関に対して警告するようにさらに動作可能である。
本発明は、上述した本発明に関する装置を複数備えるシステムを提供するのであり、装置は複数の位置にわたって分散されており、各装置は複数の装置のうちの他の装置の各々とデータ通信するように動作可能である。
本発明は、金融機関からの電子トランザクション要求メッセージを処理するための方法であって、各トランザクション要求メッセージは第1の金融機関内のある金融口座から第2の金融機関内の別の金融口座へと資金の払い込みを指示し、該方法は、ある位置に配置された複数のスイッチのうちの1つのスイッチにて、金融機関からのトランザクション要求メッセージを受信するステップと、複数の同期化されたデータベースを備えており且つ複数のスイッチに接続されているクラスターデータベース内にて、受信されたトランザクション要求メッセージに基づいてトランザクションサマリ記録を生成するステップであって、トランザクションサマリ記録は受信されたトランザクション要求メッセージによって定義された金融口座間での資金決済を可能とする、ステップとを含む、方法を提供する。
実施形態では、各トランザクション要求メッセージはトランザクション要求メッセージが関連付けられているトランザクションを一意的に識別する識別子を含み、方法は識別子に基づいてトランザクション要求メッセージを特定のスイッチへとルーティングするステップを含む。
実施形態では、各トランザクション要求メッセージはデジタル署名で署名されており、方法は署名されたトランザクション要求メッセージを検証するステップをさらに含み、署名されたトランザクション要求メッセージを検証できない場合において方法はトランザクション要求メッセージを金融機関へと返送するステップを含む。
実施形態では、方法は、検証不能なトランザクション要求メッセージが受信されたことについて金融機関に対して警告するステップを備える。
本発明は、コンピュータプログラムを格納するように構成された記憶媒体を備えたコンピュータプログラム製品であって、コンピュータプログラムは、コンピュータに読み込まれると本発明に関する上述の方法をコンピュータに行わせるコンピュータ可読命令を含んでいる、コンピュータプログラム製品を、提供する。
上記は、一般的な導入として提供されており、添付の特許請求の範囲を限定することを意図していない。以下の詳細な説明と添付の図面とを参照することによって、説明された実施形態はさらなる長所と共により良く理解されるであろう。
添付の図面を伴って以下の詳細な説明を参照することによって本願をより良く理解できるのであり、本願開示についてのより完全な理解及び本願開示に付随する多くの長所が明らかとなる。
実施形態によるシステムの様々なコンポーネントを表す概略図である。 実施形態によるシステムの一部を構成するスイッチによってトランザクションメッセージに対して行われる様々な処理ステップを表すフローチャートである。 実施形態によるシステムの一部を構成するスイッチによってトランザクションメッセージに対して行われる様々な処理ステップを表すフローチャートである。 システムを用いてデビット上限を実装する場合に関連しての問題を表す概略図である。 実施形態による、図3Aの問題に対する解決策を表す概略図である。 実施形態による、システムによってトランザクションメッセージに対して行われる様々な処理ステップを表すフローチャートである。 実施形態によるコンピュータを表す概略図である。
図面を参照するに、様々な視点において、同様の参照符号は同一又は対応する部分を表している。
図1は、実施形態によるシステム100に関しての概要を表している。システムは、複数の銀行(ここでは2行の銀行、即ち銀行1及び銀行2)及び複数のスイッチ(ここでは2カ所のスイッチサイト、即ちスイッチサイト1及びスイッチサイト2)を備えている。各銀行は、データ通信チャンネルを介して双方のスイッチサイトと接続されている(不図示)。同様に、スイッチサイトは、データ通信チャンネルを介して相互に接続されている(不図示)。データ通信チャンネルは、インターネット等のデータ通信ネットワークを介して実装されていることができる。頑健性の向上のためにスイッチサイトは分離されており、一方のスイッチサイトで技術的な故障や自然災害等の問題が生じた場合には他方のスイッチサイトで処理が続行され得る。例えば、スイッチサイトは地理的に異なる位置に配置されていることができる。
各々の銀行は、バンキングアプリケーション102A,102Bと、ゲートウェイアプリケーション104A,104B(単に「ゲートウェイ」と称する場合もある)とメッセージキューユニット106A,106Bとを備えている。各々のスイッチサイトは、メッセージキューユニット108A,108Bと、複数のスイッチ(ここでは各サイトに2つのスイッチ、即ちスイッチサイト1にスイッチSW1及びSW2並びにスイッチサイト2にスイッチSW3及びSW4)と、データベース110A,110Bと、メッセージキューユニット112A,112Bとを備えている。さらに、スイッチサイトの一方(ここではスイッチサイト1)はバックオフィスユニット114を備えている。これらのコンポーネントそれぞれの機能は以下において詳述される。各々の銀行又はスイッチサイトの対応するコンポーネント(異なるアルファベット文字を伴う同じ番号で表される符号、例えばスイッチサイト1及び2おける110A及び110Bのそれぞれや、銀行1及び2におけるメッセージキュー106A及び106Bのそれぞれ)は、機能的には同一であることに留意されたい。
図1は、銀行口座間でのトランザクションの実行を可能とするためのシステム100によって実装される例示的なメッセージフローを表す。図1の例では、銀行1の銀行口座から銀行2の異なる銀行口座への資金のトランザクションが実行される。もっとも、システム100は、同じ銀行の異なる銀行口座間での資金のトランザクションを実行するためにも用いられ得ることに留意されたい。さらに、勿論ではあるが、銀行2が、銀行2に所在する口座から銀行1内に所在する口座へと資金を移転するトランザクション要求を生成することができる。
銀行1と銀行2との間のトランザクションを実現するためのメッセージフローは、銀行1での銀行口座の保有者が、銀行1に対して、資金を銀行2の銀行口座へと移転するように指示すると、開始される。この結果、トランザクション要求メッセージM1が生成される。メッセージM1は、資金の引出元となる銀行及び具体的銀行口座に関しての識別子(例えば、銀行1の銀行ソートコード及び口座番号)と、資金の振込先となる銀行及び具体的銀行口座に関しての識別子(例えば、銀行2の銀行ソートコード及び口座番号)と、移転すべき資金に関しての金額及び通貨種類とを含む。メッセージM1は、メッセージM1が関連するトランザクションを一意的に識別する一意的な識別子をも含む(例えば、一意な番号、一意な文字配列、一意な文字と数字とからなる組み合わせ、又は、ほかの何らかの配列)。この情報は、バンキングアプリケーション102Aによって提供される。バンキングアプリケーション102Aは、銀行によって提供されて、及び、顧客によってアクセスされることができ、セキュアなウェブサイト又は顧客の携帯端末又はタブレット型コンピュータ上で提供されるアプリケーションを用いてこれを行うことができる。この一意的な識別子は、「トランザクション識別子」という。
メッセージM1はメッセージキューユニット106Aへと渡され、ゲートウェイ104AがメッセージM1を処理できる状態になるまでメッセージM1はそこで一時的に保持される。メッセージキューユニット106Aは、メッセージM1を、ゲートウェイ104Aへと送信されるべき他のメッセージと共に、待ち行列内に保持する(即ち、より早い時間に受信されたメッセージが、より遅い時間に受信されたメッセージよりも先にゲートウェイ104Aへと送信される)。そして、ゲートウェイ104Aが利用可能となると、待ち行列の先頭にあるメッセージを回収する。
ゲートウェイ104AがメッセージM1を受信できるようになると、メッセージキューユニット106AはメッセージM1をゲートウェイ104Aへと渡す。ゲートウェイ104Aは、メッセージM1がシステム100に対応した所定の標準フォーマット(例えば、標準フォーマットたるISO20022)に則っていることを保証し、メッセージM1をデジタル的に署名する。また、ゲートウェイ104Aは、M1に(例えば、M1のヘッダに)、M1がどのスイッチサイトへ送信されれば良いかを識別するルーティング情報をも追加する。ゲートウェイ104Aの動作は、後ほど詳述する。以下において明らかになるように、ゲートウェイ104Aはシステムにとって随意的であるが、実施形態には含まれている。ゲートウェイ104Aが無い場合、バンキングアプリケーション102Aを用いてメッセージM1が正しくフォーマット及び署名される必要があり、また正しくルーティングされる必要もある。
メッセージM1のフォーマットが検査され、メッセージM1がデジタル的に署名され、及び、メッセージM1にルーティング情報が追加された場合、メッセージM1は、スイッチサイトのいずれかのメッセージキューユニット108A,108Bへの送信に先んじてメッセージキューユニット106Aに戻されて一時的に保持される。ここでも、メッセージキューユニット106Aは、メッセージM1を、スイッチサイトへと送信されるべき他のメッセージと共に、待ち行列内に保持する。メッセージキューユニット106Aの先頭にあるメッセージは、各メッセージ内のルーティング情報に従って、スイッチサイト1のメッセージキューユニット108A又はスイッチサイト2のメッセージキューユニット108Bへと送信される。通常、各銀行のゲートウェイは、一連のメッセージの各々を2つのスイッチサイト間で交互的にルーティングする。したがって、メッセージキューユニット106Aの先頭にあるメッセージがメッセージキューユニット108Aへと送信された場合には、待ち行列内の次のメッセージはメッセージキューユニット108Bへと送信され、その後のメッセージはメッセージキューユニット108Aへと送信され、以後同様になされる。この場合、メッセージM1がスイッチサイト1のメッセージキューユニット108Aへと送信されたことが見受けられる。
メッセージM1は、スイッチSW1又はSW2のどちらか一方がメッセージM1を処理できる状態になるまでは、メッセージキューユニット108A内で一時的に保持される。ここでも、メッセージキューユニット108Aは、メッセージM1を、スイッチSW1又はSW2へと送信されるべき他のメッセージと共に保持するのであり、待ち行列の先頭にあるメッセージは最初に利用可能となったスイッチ(SW1又はSW2)へと送信される。銀行側メッセージキュー及びシステム側メッセージキューは、IBM(登録商標)MQ等のシステムを用いて実装されることができることに留意されたい。
この場合、メッセージM1はスイッチSW1へと送信される。そして、スイッチSW1は、ハッシュ関数をメッセージM1に適用する。ハッシュ関数は、メッセージM1のトランザクション識別子と全サイトにある利用可能なスイッチの個数(即ち、この実施形態ではスイッチは4個)とについての関数であり、ハッシュ関数の出力は、メッセージM1を処理するのに使用すべきスイッチを識別する番号である(例えば、番号たる1、2、3又は4がそれぞれスイッチSW1、SW2、SW3又はSW4を表す)。ハッシュ関数によって識別されるスイッチは、メッセージキューユニット108AによってメッセージM1が当初仕向けられたスイッチと同じスイッチであることができるし、又は、代替的には異なるスイッチであることもできる。ハッシュ関数によって識別されたスイッチが異なるスイッチである場合、当初の受信側スイッチ(この場合ではスイッチSW1)はメッセージM1を、ハッシュ関数によって識別されたスイッチへと渡す。もっとも、図1の実施形態では、ハッシュ関数によって識別されたスイッチはメッセージM1を当初受信したスイッチ(即ちスイッチSW1)と同じスイッチであるため、メッセージは異なるスイッチへと転送はされない。ハッシュアルゴリズムについては後ほど詳述する。
メッセージM1がスイッチSW1によって受信された後、メッセージM1が関連するトランザクションの状態がデータベース110Aに記録される。この場合では、データベース110Aが記録することは、トランザクションが未だ係属中であり、また、トランザクションが完了するために必要とされる3つのメッセージ(即ち、メッセージM1、M2及びM3。後述を参照。)のうちの1つのメッセージ(メッセージM1)がこれまでにスイッチSW1によって受信又は送信されたということである。
データベース110Aは、記憶ユニット109A及び109Bの双方内に格納されているデータに基づいて生成されたクラスターデータベースである。データベース110Aは、例えばMnesiaデータベースとして実装されることができる。スイッチSW1,SW2は、これらのスイッチによって処理されたトランザクションの各々のトランザクション状態をデータベース110A内に記録し更新されるようにする(これは矢印TUによって図1で表されている)。記憶ユニット109A,109Bは相互に同期された状態に維持されるのであり、トランザクション状態の各々が記憶ユニット109A及び記憶ユニット109Bの双方において記録及び更新される。したがって、記憶ユニット109A,109Bは同じデータについての同一コピーを含んでいるのであり、それ故にデータベース110A内の各トランザクション状態は記憶ユニット109A又は記憶ユニット109Bのいずれからも取得されることができる。有利なことに、この構成によれば、記憶ユニット109A,109Bの一方が(故障又は計画された保守作業等によって)非稼働状態に陥った場合でも、データベース110A内のトランザクション状態にアクセスすることができる。
データベース110Bはデータベース110Aと同じ構成を有しており、データベース110Bは記憶ユニット109C及び109Dの双方内に格納されているデータに基づいて生成されたクラスターデータベースである。スイッチSW3,SW4は、これらのスイッチによって処理されたトランザクションの各々のトランザクション状態をデータベース110B内に記録し更新されるようにする。記憶ユニット109C,109Dは相互に同期された状態に維持されるのであり、トランザクション状態の各々が記憶ユニット109C及び記憶ユニット109Dの双方において記録及び更新される。したがって、記憶ユニット109C,109Dは同じデータについての同一コピーを含んでいるのであり、それ故にデータベース110B内の各トランザクション状態は記憶ユニット109C又は記憶ユニット109Dのいずれからも取得されることができる。
スイッチSW1によってメッセージM1が受信されたことに続いてデータベース110A内のトランザクション状態が記録されたらば、スイッチSW1はトランザクション情報メッセージM2を生成する。トランザクション情報メッセージM2は、トランザクション資金を受けるべき側の銀行(即ち、銀行2)に対してトランザクションのことを通知するためのものである。また、受取側銀行は、資金を受けるべき具体的銀行口座及び受領されるべき現金に関しての金額及び通貨種類についても知らされる。したがって、トランザクション要求メッセージM1と同じように、M2は、資金を振り込むべき銀行及び具体的銀行口座に関しての識別子(例えば、銀行2の銀行ソートコード及び口座番号)と、移転すべき資金に関しての金額及び通貨種類とを含む。また、(メッセージM1とメッセージM2とは同じトランザクションに関連しているが故に)メッセージM2はメッセージM1と同じトランザクション識別子を含んでいる。また、メッセージM2は資金の送金元の銀行及び具体的銀行口座に関しての識別子を含むこともできるのであり、これによって受取側銀行口座の保有者が送金者の正体を知り得る。
メッセージM2が生成されたらば、メッセージキューユニット108A及び106B並びにゲートウェイ104Bを介して、M2は銀行2へと送信される。銀行2のメッセージキューユニット106B及びゲートウェイ104Bは、銀行1のメッセージキューユニット108A及びゲートウェイ104Aと機能的に同一である。したがって、メッセージM2は、メッセージキューユニット108Aにて一時的に保持及びキューイングされる。そしてメッセージM2は、データ通信チャンネル上を(メッセージM2内の銀行2の識別子に基づいて)メッセージキューユニット106Bへと送信され、ゲートウェイ104Bがそれを受信できるようになるまでそこで再び一時的に保持及びキューイングされる。ゲートウェイ104Bによって受信されたらば、メッセージM2は(スイッチによって生成されたデジタル署名を用いて)検証される。そして、メッセージM2はメッセージキューユニット106Bへと戻されて、そこで一時的に保持及びキューイングされてその後に銀行2のバンキングアプリケーション102Bへと渡される。したがって、銀行2はトランザクションのこと及びトランザクション資金を受けるべき具体的銀行口座について知らされることになる。したがって、銀行1と銀行2との間での決済が未だ発生していないにもかかわらず、当該具体的銀行口座へトランザクション資金をクレジット付けすることができる。
メッセージM2が銀行2へと送信された後、データベース110A内のトランザクション状態は更新されて、トランザクションが未だ係属中でありかつトランザクションが完了するために必要とされる3つのメッセージのうちの2つのメッセージ(即ち、メッセージM1及びM2)がこれまでにスイッチSW1によって受信又は送信されたということが記録される。
メッセージM2が銀行2のバンキングアプリケーション102Bによって成功裏に処理されると、バンキングアプリケーション102Bは第1のトランザクション確認メッセージM3を生成する。メッセージM3は、メッセージM2が銀行2によって成功裏に受信及び処理されたことについての確認であり、(メッセージM1、M2及びM3は全て同じトランザクションに関連しているため)当該メッセージはメッセージM1及びM2と同じトランザクション識別子を含んでいる。メッセージM3はメッセージキューユニット106B内で一時的に保持及びキューイングされて、そしてゲートウェイ104Bへと渡され、当該メッセージが適切な標準フォーマットになっていることが保証されて、また、デジタル署名及びルーティング情報が付加される。そして、メッセージM3はメッセージキューユニット106Bへと戻されて、スイッチサイトの1つへと転送されるまでは一時的に保持及びキューイングされる。メッセージキューユニット106Aの場合と同じように、メッセージキューユニット106B内の待ち行列の先頭にあるメッセージは一般的には交互的にスイッチサイト1のメッセージキューユニット108A及びスイッチサイト2のメッセージキューユニット108Bへと送信されるのであり、これはゲートウェイ104Bによって各メッセージに付加されたルーティング情報に基づいてなされる。この場合では、メッセージ3はスイッチサイト2のメッセージキューユニット108Bへと送信されることが分かる。
メッセージM3は、スイッチSW3及びSW4のいずれか1つがメッセージM3を受信可能になるまで、メッセージキューユニット108B内にて一時的に保持及びキューイングされる。この場合では、待ち行列の先頭にメッセージM3がある時点において最初に利用可能となるのがスイッチSW4であることが分かるのであり、したがってメッセージM3はスイッチSW4へと送られる。
スイッチSW4では、メッセージM3に対してハッシュアルゴリズムが適用される。メッセージM3はメッセージM1(及びメッセージM2)と同じトランザクション識別子を有しているため、ハッシュアルゴリズムの出力はメッセージM1についてのハッシュアルゴリズムの出力と同じになる。換言すれば、メッセージM3が送られるべきなのがスイッチSW1である、ということがハッシュアルゴリズムの出力によって指示される。したがって、図1にみられるように、スイッチSW4はメッセージM3をスイッチSW1へと送信する。この送信は、スイッチサイト1及び2を接続するデータ通信チャンネル上でなされる。
メッセージM3がスイッチSW1によって受信されたらば、データベース110A内のトランザクション状態は更新されるのであり、トランザクションが完了するために必要なメッセージ(メッセージM1、M2及びM3)の全てがスイッチSW1によって受信又は送信された故にトランザクションが完了したことが記録される。この場合では、トランザクション状態は、係属中のトランザクションのトランザクション詳細事項を記録するデータベース110A内の進行中(in-flight)テーブルから、完了されたトランザクションのトランザクション詳細事項を記録するデータベース110A内の完了テーブルへと、移される。
トランザクションが完了したことを決定するためには3つのメッセージM1、M2及びM3を用いることで足りる。なぜならば、メッセージM3が受信されるとメッセージM2内に含まれている支払情報が銀行2によって受信され及び成功裏に処理されたことが確認されるからである。したがって、メッセージM1の送信の後に銀行1の送金元口座から引き落とされた額と同じ額の現金が、銀行2の送金先口座に入金されている。これによって、銀行1と銀行2との間での決済が未だ行われていなくとも、銀行1及び銀行2の顧客は、資金の即時的な移転を享受することができる、という点に留意されたい。
トランザクションが完了されたことをデータベース110A内において記録するためのトランザクション状態についての更新に続いて、トランザクションサマリ記録TSがトランザクション状態に基づいて作成される。トランザクションサマリ記録TSは、トランザクションメッセージによって定義された金融口座間での資金決済を可能とするのに十分な情報を含んでいるのであり、メッセージキューユニット112A内にて保持される。具体的には、トランザクションサマリ記録TSは次の事項を含む:資金の送金者(送金元、originator)の氏名若しくは名称、アドレス、ソートコード及び口座番号;資金の受取人(受益者、beneficiary)の氏名若しくは名称、アドレス、ソートコード及び口座番号;送金されるべき資金の額(これには送金の際に用いられる通貨種類も含まれる);並びに一意的なトランザクション識別子。また、トランザクションサマリ記録TSは次のような追加的な事項も含むことができる:レコードが作成された日時;トランザクションメッセージ(M1、M2及びM3)が送信又は受信された時点に関するタイムスタンプ;決済の日時(又はトランザクションが処理されるべき具体的な決済サイクル回を指示する徴表);並びにトランザクションが成功したか否かについての徴表等。この列挙はもちろん網羅的ではなく、決済を行うに際して有用たり得る任意の情報及び全てのトランザクションについて勘定するために有用たり得る任意の情報を、トランザクションサマリ記録TSに含めることができる。
図1には不図示であるも、メッセージキューユニット112Aはクラスターデータベースの形態をとっており、当該構成においては全てのトランザクションサマリ記録TSについての2つのコピーが別個の記憶ユニット上にて格納されている。2つのコピーの同期を維持することによってシステム100の頑健性は向上する。なぜならば、トランザクションサマリ記録の片方のコピーが仮に(技術的な障害等によって)利用不能となったとしても、2つ目のコピーを依然使用することができるからである。メッセージキューユニット112Aは、バックオフィスユニット114(後述参照)が決済処理のためにトランザクションサマリ記録を受信する準備ができるまでは、トランザクションサマリ記録を一時的に保持及びキューイングする。
トランザクションサマリ記録TSの作成並びにメッセージキューユニット112A及び112Bの運用は、Rabbit MQ(登録商標)等のソフトウェアアプリケーションを用いて実装されることができる。実際には、クラスターデータベース110A及びメッセージキューユニット112A(並びに、同様にクラスターデータベース110B及びメッセージキューユニット112B)はソフトウェアアプリケーションによって機能的に連結されていることができ、各サイトにおけるクラスターデータベース及びメッセージキューユニットが完全に別個のエンティティであるにも関わらずにこれらの間での読み出し及び書き込み機能(これにはトランザクションサマリ記録TSの作成も含む)を簡便且つ確実に実装することができる。
メッセージキューユニット112A内にトランザクションサマリ記録TSが成功裏に格納されたことに続いて、スイッチSW1は第2のトランザクション確認メッセージM4を生成する。メッセージM4は、銀行2でトランザクションが成功裏に行われたことを銀行1に確認的に知らせるための確認メッセージであり、(メッセージM1,M2,M3,M4は全て同じトランザクションに関連しているが故に)メッセージM1,M2,M3と同じトランザクション識別子を有している。メッセージM4は、メッセージキューユニット108A,106A及びゲートウェイ104Aを介して銀行1へと送信される。換言すれば、メッセージM4は、メッセージキューユニット108A内にて一時的に保持及びキューイングされる。そして該メッセージは、メッセージキューユニット106Aへとデータ通信チャンネル上で送信され、該メッセージをゲートウェイ104Aが受信できるようになるまでそこで一時的に保持及びキューイングされる。ゲートウェイ104Aによって受信されたらば、メッセージM4は(スイッチによって生成されたデジタル署名を用いて)検証される。そして、該メッセージは、メッセージキューユニット106Aへと差し戻され、銀行1のバンキングアプリケーション102Aへと渡される前にそこで一時的に保持及びキューイングされる。これにより、資金の移転が成功裏に実行されたことが銀行1に確認的に知らされる。
指示発令側銀行(図1の例においては銀行1)の口座保有者が最初に要求発令アプリケーションを用いてインターネットを介してメッセージM1を受信するスイッチへと送信し、且つ、(ハッシュ関数によって決定された)処理をするスイッチがこの当初受信したスイッチと同じスイッチでない場合(注:図1の場合はこれに該当しない。なぜならば、処理をするスイッチSW1はメッセージM1を当初受信したスイッチでもあるからである。)、メッセージM4はまず処理をするスイッチから当初受信したスイッチへと転送されてそして当初受信したスイッチから指示発令側銀行へと(該当するメッセージキューユニット108A,108B,106A,106Bを介して)送信される。トランザクションのためにメッセージM1を送信した要求発令アプリケーションそのものにメッセージM4を戻すことを保証するためには、このようにすることが必要である。
バックオフィスユニット114は、銀行1と銀行2との間で決済が行われることを可能とするために、メッセージキューユニット112A,112B内にて保持及びキューイングされたトランザクションサマリ記録を処理するように構成されている。これが可能なのは、各トランザクションサマリ記録が、各トランザクションについて銀行1から銀行2へと(又はその逆へと)移転される金額を捕捉するために必要な全ての情報を含んでいるからであり、それ故に決済サイクルの終わりにおいて銀行間で移転されるべき金額の合計を、トランザクションサマリ記録を用いて算出することができる。これにより、上述した各トランザクションについての銀行口座に対してのクレジット及びデビット処理が、銀行間での現金についての繰延差金決済(real money deferred net settlement)に対応付けされることが保証される。トランザクションサマリ記録TSは、処理のためバックオフィスユニット114へと10送信される前に、メッセージキュー112A内にて保持及びキューイングされる。バックオフィスユニット114での処理は、トランザクションサマリ記録TSを格納することと、決済処理において用いるために各銀行についての二者間(銀行対銀行)及び多者間(銀行対全ての他行)の債務(即ち、支払うべき金銭)に関しての暫定合計を管理することとを含む。そして、バックオフィスユニット114が有しているこのデータに基づいて、(例えば、上述したように8時間、12時間又は24時間毎の)決済サイクルの終わりにおいて決済が行われる。
この実施形態では、バックオフィスユニット114はスイッチサイト1に配置されていることに留意されたい。したがって、スイッチサイト2のメッセージキューユニット112B内に保持されたトランザクションサマリ記録TSは、バックオフィスユニット114によって受信されるためには、スイッチサイト間にわたるデータ通信チャンネル上を介して送信される必要がある。代替的な実施形態では、バックオフィスユニット114はスイッチサイト2に配置されていることができ、この場合、スイッチサイト1のメッセージキューユニット112A内に保持されたトランザクションサマリ記録TSは、バックオフィスユニット114によって受信されるためには、スイッチサイト間にわたるデータ通信チャンネル上を介して送信される必要がある。別の実施形態では、複数のバックオフィスユニットがあり、スイッチサイト1及びスイッチサイト2の各々に1つ配置されている。この場合、一方のみのバックオフィスユニットを決済のために使用する。もっとも、複数のバックオフィスユニット114が存在しているため、(故障又は計画された保守作業等によって)バックオフィスユニット114の一方が非稼働状態に陥った場合、メッセージキューユニット112A,112B内に保持されたトランザクションサマリ記録TSは残っている稼働中のバックオフィスユニット114へとリダイレクトされて決済がなされることができる。したがって、システム100は向上した頑健性を有している。なぜならば、バックオフィスユニット114の一方の故障にもかかわらずにトランザクションサマリ記録TSを用いて決済を依然行えるからである。
トランザクション要求の分配
既述のように、図1の実施形態では、ハッシュ関数(「ハッシュアルゴリズム」ともいう)によってトランザクションメッセージ(特に銀行から受信されるメッセージM1及びM3)がスイッチSW1,SW2,SW3,SW4間で分配される。これによってスイッチ間でメッセージが等しく分配されることが支援されるのであり、それ故にシステム100に向上した負荷分散性をもたらす。また、これによって、同じトランザクションに関するメッセージが、同じスイッチ又は少なくとも同じデータベース110A,110Bへのアクセスを有している幾つかのスイッチによって処理されることをより確実なものとするのにも資する。以下、ハッシュ関数について詳述する。
既述のように、ハッシュ関数は各メッセージをスイッチへとマッピングする。より具体的には、ハッシュ関数は、入力としてメッセージの一意的なトランザクション識別子とスイッチの個数とを受け付けて、メッセージを処理するのにスイッチSW1,SW2,SW3,SW4のうちどの1つを用いるべきかを指示する番号を出力する。即ち、ハッシュ関数は以下の形式で表される:
スイッチ番号=関数(トランザクション識別子,スイッチの総数)
ハッシュ関数として用いられることができる具体例(即ち、入力の個数が多数又は場合によっては無限大であっても、決まった個数の規定の出力値しか出力しない関数)は当業者に知られている故にここでは言及しない。
実施形態では、銀行のうちのある1行から(より具体的に言えば、メッセージキューユニット108A,108Bのうちの1つから)メッセージを最初に受信したスイッチがメッセージに対してハッシュ関数を適用する処理を行う。これによって、どのスイッチがメッセージを処理するかが識別される。そして、メッセージは識別されたスイッチへと送信(即ち、換言すれば、転送)される。この関数は、スイッチ内に配置された処理回路によって行われるのであり、スイッチ内の記憶ユニット内に格納されたコンピュータ可読命令を用いて該処理が行われる。ハッシュ関数の適用後のメッセージの転送については、図1との関係で上記において以前例示した(当該例においては、最初はスイッチSW4へと渡されたメッセージM3が、ハッシュ関数が適用された後にはスイッチSW1へと転送される。)。ハッシュ関数の適用は銀行から受信されたメッセージ(即ち、図1の例ではメッセージM1及びM3)に対して行われる。なぜならば、これらのメッセージが初期的にスイッチSW1,SW2,SW3,SW4のいずれか1つへと送信され得るからである。
同じトランザクションと関連付けられた全てのメッセージは、同じトランザクション識別子を有している。このため、これが可能であれば、このようなメッセージは、同じスイッチ又は少なくとも同じデータベース110A,110Bへのアクセスを有している幾つかのスイッチへと送信されてまた処理されることができる。特定のトランザクションの進行について、より容易に且つより効率的に、追跡を行って該当するデータベース110A,110Bをアップツーデートに維持することができる、という点においてこれは有利である。
特定のトランザクションと関連付けられた全てのメッセージを処理するための単一の識別されたスイッチを割り当てることが有利であるが、損傷又は計画された保守作業等のために識別されたスイッチが非稼働状態に陥った場合に関しては、本願開示の実施形態では、そのトランザクションを扱うべき代替的スイッチについての優先順位リストを提供する。
スイッチに関しての優先順位の一例を下記の表1との関連で述べる。
表1ではスイッチに関しての優先順位が示されている。第1スイッチは、全スイッチに渡っての均一なメッセージ分配を決するためにハッシュアルゴリズムによって選定されたスイッチである。第2スイッチは、優先順位における次順位スイッチであり、第1スイッチが利用不能である場合には、特定のトランザクションに関してのメッセージは第2スイッチへと送信される。この場合では、第2スイッチは第1スイッチと同じサイトに配置されている。換言すれば、第1スイッチがスイッチサイト1に配置されている場合、第2スイッチもスイッチサイト1に配置されていることになる。第3スイッチは優先順位においてその次の順位にあるスイッチであり、第2スイッチが利用不能である場合にメッセージは第3スイッチへと送信される。この場合、第3スイッチは、第1及び第2スイッチとは異なるスイッチサイトに配置されていることが必要である。なぜならば、第1及び第2スイッチのスイッチサイトには他の利用可能なスイッチが無いからである。最後に、第4スイッチは優先順位においてその次の順位にあるスイッチであり、第3スイッチが利用不能である場合にメッセージは第4スイッチへと送信される。この場合、(唯一残っているスイッチである)第4スイッチは第3スイッチと同じサイトに配置されていることが必要である。
表1のような優先順でスイッチを提供することには2つの明確に異なる利点がある。第1の利点は、一方のスイッチが故障しても、アクティブなスイッチによってメッセージが迅速に処理されるという点にある。これによって、トランザクション要求が迅速に再割り当てされるということが保証される。第2の利点としては次の観点がある:優先順位における第2スイッチは第1スイッチと同じサイトにあるため、第1スイッチが非稼働状態に陥ったとしても、第1スイッチと同じくデータベース110A,110Bに直接アクセスできるスイッチへとメッセージが送信されることが、保証されること。これによって、第1スイッチが未だ稼働中であるかのようにメッセージ処理が続行されることができる。なぜならば、以前第1スイッチによって処理されていた全ての進行中トランザクションについてのトランザクション状態記録に対して、第2スイッチが即時にアクセス及び更新を行うことができるからである。有利なことに、これにより、特定のスイッチサイトにあるスイッチの1つが非稼働状態に陥った場合に生じる失調が緩和される。
特定のスイッチサイトのスイッチ両方が非稼働状態に陥ると、優先順位リストにある第3及び第4スイッチの存在によって新規トランザクション(即ち、特定のスイッチサイトのスイッチ両方が非稼働状態に陥った後にメッセージM1が発せられたトランザクション)の処理を続行させることができる。有利なことに、これによって、スイッチサイトの両方のスイッチが非稼働状態に陥った場合(例えば、一方のスイッチサイトで自然災害が発生した後の状態)であっても、新たに指示されたトランザクションは遂行可能となる。ただし、非稼働状態のスイッチサイトで既に部分的に完了されたトランザクションは続行されることができない。なぜならば、(非稼働状態のサイトにあるデータベース110A,110B上に格納された)トランザクション状態データにアクセスできないからである。この局面に関しては、後ほど詳述する。
表1にて示した各スイッチについての具体的な優先順位リストは例に過ぎないのであり、代替的な優先順位リストを用いることもできることに留意されたい。また、上記においては2つのサイトに2つのスイッチが設けられている場合について述べたが、上述した原理は任意の個数のサイトに任意の個数のスイッチを設けた場合にも妥当し得ることが想定されている。
システム頑健性の向上
既述のように、システム100では、トランザクションのトランザクション状態データは、トランザクションを処理するのに用いられたスイッチサイトのデータベース110A,110B内に格納される。そして、トランザクション状態データはトランザクションサマリ記録TSを生成するために使用されて、決済サイクルの終わりになってバックオフィスユニット114がトランザクションサマリ記録TSを受信できるようになるまで、これが適切なメッセージキューユニット112A,112B内にて保持及びキューイングされる。適切なメッセージキューユニット112A,112B内に成功裏にトランザクションサマリ記録TSが格納されると、データベース110A,110Bからトランザクション状態データを消去することができる。さらに、バックオフィス114が適切なメッセージキューユニット112A,112Bに対して自己が成功裏にトランザクションサマリ記録TSを受信したことを確認的に知らせた場合、トランザクションサマリ記録TSをメッセージキューユニット112A,112Bから消去することができる。
もっとも、トランザクションサマリ記録TSが格納されているスイッチサイトにて問題があり、該問題によってバックオフィスユニット114がそのスイッチサイトのメッセージキューユニット112A,112Bにアクセスできなくなっている場合(即ち、メッセージキューユニット112A,112Bのクラスターデータベース構成にも関わらずにアクセスが妨げられている場合)、決済サイクルの終わりにてトランザクションサマリ記録TSが勘定されない恐れがある。この結果、銀行間決済は誤って計算されることになる(したがって、銀行間では誤った現金移転が行われることになる)。
当該問題を緩和するために、自己の処理用スイッチサイトのメッセージキューユニット112A,112Bへと各トランザクションサマリ記録TSが渡される際に、他のスイッチサイトのうちの1つのスイッチへそのコピーを転送しておきバックアップ記憶ユニット(不図示)における格納のために供する。したがって、例示すれば、スイッチサイト1で生成されてメッセージキューユニット112Aにて一時的に保持及びキューイングされた各トランザクションサマリ記録TSは、スイッチサイト2のスイッチSW3又はSW4へコピーされた上で転送されてスイッチサイト2のバックアップ記憶ユニットに格納される。有利なことに、この構成によれば次の場合において次の結論が導かれる:特定のサイトのメッセージキューユニット112A,112Bにて格納されたトランザクションサマリ記録TSが何らかの理由によって決済サイクルの終わりにおいてバックオフィスユニット114からアクセスできないこととなった場合(例えば、メッセージキューユニット112A,112Bの故障等が生じた場合)であっても、トランザクションサマリ記録TSのバックアップ済みコピーを検索して決済関連計算を行わせるためにバックオフィスユニット114にこれを提供することができる。メッセージキューユニット112A,112Bについてクラスターデータベース構成を採用することと共に上記によって、銀行間決済が正しく行われることをより確実にすることを支援することができる。
上述したように、実施形態では、スイッチは複数のサイト間で分散されており、各サイトはスイッチのクラスターを有している。図1の実施形態では、例えば、4つのスイッチSW1,SW2,SW3,SW4があり、スイッチSW1及びSW2がサイト1でクラスターをなし、スイッチSW3及びSW4がサイト2でクラスターをなしている。
スイッチSW1,SW2,SW3,SW4の各々は、互いとの関係で独立的に動作する。したがって、クラスター内のスイッチの1つが(例えば、エラーや誤作動等によって)故障した場合や、クラスター内のスイッチの1つが保守作業のためにシャットダウンされる必要がある場合においては、トランザクション処理をそのクラスター内の(有利なことに、同じデータベース110A,110Bに対してのアクセスを有している)他方のスイッチにて依然として続行していくことができる。
当該原理は単一のスイッチが故障しても妥当するのであり、さらなるスイッチが故障したとしても、システム内に稼働中のスイッチが少なくとも1つある限りにおいては、(少なくとも新規に発令されたトランザクションについての)トランザクション処理を続行することができる。例えば、サイト1及びサイト2の各々にてスイッチが故障した場合(例えば、スイッチSW1及びSW3)や、単一のサイトにて両方のスイッチが故障した場合(例えば、サイト1のスイッチSW1及びSW2)や、たとい1つのスイッチを除いて他の全てのスイッチが故障した場合(例えば、スイッチSW1、SW2及びSW3が故障してSW4のみが稼働中の場合)であっても、トランザクションメッセージは(ハッシュ関数を用いて)利用可能なスイッチへと再ルーティングされてトランザクション処理は続行される。
さらに、この原理はスイッチ故障に限定されない。システム100の他のコンポーネント(例えば、記憶ユニット109A〜Dの1つ)が故障した場合、当該事象は該当するスイッチによって検知されて、ハッシュ関数に従って決定された通りに当該スイッチがメッセージを代替的なスイッチへと転送する。このようにして、トランザクション処理は他のスイッチの1つを用いて続行される。
また、この原理はコンポーネント故障に対応する局面に限定されない。例えば、(例えば、ソフトウェアやハードウェア更新等のために)スイッチサイトが保守作業のためにシャットダウンされた場合、そのサイトのスイッチはトランザクションメッセージを受信することができなくなり得る。しかし、トランザクションメッセージは他のサイトのスイッチによって依然として受信及び処理されることができるのであり、したがってトランザクション処理は続行されることができる。このことは、例えば自然災害等(例えば、火災、洪水等)によってサイト全体がシャットダウンされた場合にも妥当する。
既述のように、トランザクションメッセージは、スイッチSW1,SW2,SW3,SW4間で分配されるのであり、これはハッシュ関数によって決定されたスイッチ優先順位リストに準拠してなされる。スイッチが最初にトランザクションメッセージを受信すると、メッセージにハッシュ関数を適用して(必要であれば)メッセージを転送するのであり、転送先はシステムによって処理可能であると認識されている優先順位リスト内の首位の(第1の)スイッチである(ポーリング構成を用いたスイッチ利用可能性の監視は、下記において詳述する)。メッセージを転送するために、当初に受信したスイッチは、優先順位リストの首位のスイッチと接続(例えば、通信制御プロトコル(TCP)接続等)を確立しようと試みるのであり、そしてこの接続が成功裏に確立された後、メッセージを転送する。接続が成功裏に確立できない場合(例えば、優先順位首位のスイッチに故障がある場合等)においては、優先順位リストの首位のスイッチは利用不能であると決定されるのであり、システムによって利用可能であると認識されている優先順位リストにおいて次順位のスイッチへとメッセージを転送する試みが(ここでも、優先順位リストにおける次順位スイッチとの接続を確立させようとすることによって)なされる。このようにして、利用可能なスイッチが発見されるまで、処理は反復される。
(新規に指示されたトランザクションを表す)メッセージM1に関しては、優先順位リストのスイッチが1つでもトランザクションメッセージ受信可能状態であれば、トランザクション処理はそのスイッチによって完了されることができ、それによってトランザクションサマリ記録TSが生成される。なぜならば、特定のトランザクションについてのトランザクション状態データが最初にメッセージM1内の情報に基づいて記録されるからであり、これ故に、トランザクション処理を続行するために(一方のスイッチサイトのデータベース110A,110B内に格納されている)以前のトランザクション状態データにアクセスする必要がないからである。他方で、メッセージM3に関しては、メッセージM1が転送されたスイッチ(なお、このスイッチではメッセージM2が生成された)と同じスイッチサイトにあるスイッチへとメッセージM3が転送された場合のみにおいて、トランザクション処理が完了され得る。なぜならば、トランザクション処理を続行するためには、そのスイッチサイトにて格納されているトランザクション状態データにアクセスすることを要するからである。したがって、メッセージM1のトランザクションが処理されたスイッチサイトのスイッチがメッセージM3を受信する前に両方が非稼働状態に陥った場合、トランザクションを続行することができない。なぜならば、非稼働状態のスイッチサイトに格納されているトランザクション状態データにアクセスすることができないからである。このシナリオは後ほど詳述する。
浪費されるネットワーク帯域を削減するために、各スイッチSW1,SW2,SW3,SW4は、他の全てのスイッチに対して周期的にポーリングを行うように構成されており、これによってそれらが利用可能であるかが確定される。このポーリング動作には、他のスイッチの各々に対してテストメッセージを送信することと、応答に関してリスニングすることとが含まれる。特定のスイッチからの応答が所定の期間内に受信されなかった場合、その特定のスイッチは利用不能であると決定される。そして、このスイッチへと送信されるものと決定されたトランザクションに関連付けられたメッセージは、優先順位リストの次順位のスイッチへと送信される。このポーリングを周期的に行うことによって、利用不能なスイッチと接続を確立しようとするスイッチによってネットワーク帯域幅が浪費されなくなる。ポーリング行為間の時間周期は、ポーリングによって追加消費される帯域幅が、利用不能なスイッチと接続を確立しようとして用いられる帯域幅に関しての削減量によって、十分に補償されるようにして、決定される。適切な時間周期は100msたり得るが、他の周期も想定される。利用不能と決定されたスイッチに対してのポーリングは続行されるのであり、該当するスイッチが再度利用可能となったらばそのことが他のスイッチに認知されるようにするために続行されるのであり、そしてその場合には、再度メッセージを復帰したスイッチへと送信することができる。
このようにして、否定的なポーリング結果が生じた場合(即ち、応答が受信されない場合)又はそのスイッチとの接続試行が失敗した場合、別のスイッチが利用不能であるとスイッチが決定する。いずれの場合にあっても、利用不能なスイッチへと送信されるべきメッセージは、優先順位リストにおける次順位のスイッチへと送信されることになる。この方法によってシステム内の他の問題についても知り得るのであり、例えばスイッチサイト間のデータ通信リンクの故障が察知され得る(例えば、SW1及びSW2の両方がそれぞれSW3及びSW4の両方と接続できず又は一貫して否定的なポーリング結果を受信している場合、スイッチサイト1とスイッチサイト2との間のデータ通信リンクが故障したのかもしれない)。問題発生時においては、ポーリングがなされていなかった場合よりはより迅速に保守作業が故障スイッチ又は故障スイッチサイトに施されることになる。例えば、ポーリングがなされていない場合、故障したスイッチ又はスイッチサイトは、トランザクションに関連付けられたメッセージが正しく送信されなかった場合にしか特定されない。これは、ポーリング信号よりも遙かにまれにしか発生しないかもしれない。
送金元銀行(図1の例では銀行1)は、メッセージM4を受信することによってトランザクションが成功裏に完了されたことを知ることになる。(タイムアウト期間ともいう)所定の期間内にメッセージM4が送金元銀行にて受信されない場合、送金元銀行はトランザクションが成功したか否か知り得ない。このタイムアウトは幾つかの理由に起因し得る。例えば、メッセージM1が処理されたスイッチサイトがトランザクション完了前(例えば、メッセージM3の受信前)に非稼働状態に陥ったかもしれないのであり、即ちトランザクションサマリ記録TSが作成されもしなかったことを意味し、また、メッセージM4が生成されもしなかったことを意味する。これは、失敗したトランザクションとなる。他方で、トランザクションは成功裏に完了され、メッセージM4が生成されたのではあるが、その後にメッセージM4がシステム100内で失われたか、タイムアウト期間が満了するほどに遅延したのかもしれない。タイムアウト期間内にメッセージM4が受信されていない場合においては、送金元銀行はメッセージM1を再送信することができる。図2A〜2Bは、どのようにして個々のスイッチがトランザクションメッセージを処理するかを示しており、これには個々のスイッチがどのようにして送金元銀行からの再送信トランザクションメッセージを処理するかが含まれる。
図2Aは、実施形態についてのフローチャートであって、メッセージキューユニット108A,108Bの1つからトランザクションメッセージを最初に受信したスイッチによって行われるプロセスを示すフローチャートである。
プロセスはステップ200で開始される。ステップ202では、該当するメッセージキューユニット108A,108Bからのトランザクションメッセージ(例えば、図1に示されているメッセージM1又はM3)が、スイッチによって受信される。ステップ204では、メッセージにハッシュ関数が適用され、これによってメッセージが転送されるべき宛先についての優先順位リストが識別される。ステップ206では、優先順位リストの首位のスイッチがメッセージを受信することができるか否かを決定する。当該決定は、既述されたように、首位のスイッチに対してのポーリング又は首位のスイッチと接続を確立しようと試行することによって決定される。首位のスイッチが利用可能であると決定された場合、プロセスはステップ208へと進むのであり、そこではメッセージが首位のスイッチへと転送される。プロセスは、ステップ210にて終了する。他方、首位のスイッチが利用不能であると決定された場合、プロセスはステップ212へと進む。
ステップ212では、優先順位リストの次順位スイッチ(第2のスイッチ)がメッセージを受信することができるか否かが決定される。再びここでも、当該決定は、次順位スイッチに対してのポーリング又は次順位スイッチと接続を確立しようと試行することによって決定される。次順位スイッチが利用可能であると決定された場合、プロセスはステップ214へと進み、そこではメッセージが次順位スイッチへと転送される。そして、プロセスはステップ210で終了する。他方、次順位スイッチが利用可能ではないと決定された場合、ステップ212は優先順位リストにおけるその次のスイッチについて反復される(したがって、例えば優先順位リストにおける第2スイッチが利用不能であると決定された場合、優先順位リストの第3スイッチが利用可能であるか否かが決定されることになる)。ステップ212は利用可能なスイッチが発見されるまで反復されるのであり、発見された際にはプロセスはステップ214へと進み、メッセージは利用可能なスイッチへと転送される。なお、図2Aのプロセスを行うことによって利用可能なスイッチが必ず発見されることに留意されたい。なぜならば、図2Aのプロセスを行うことができるスイッチであれば、そのスイッチは勿論メッセージを受信することができるからである。
図2Bは、優先順位リストに従って転送されたメッセージが到来したスイッチにて行われるプロセスを示すフローチャートである。
プロセスは、ステップ216で開始される。ステップ218では、メッセージがスイッチによって受信される。ステップ220では、メッセージが、トランザクションに関する初めてのメッセージ(即ち、メッセージM1)であるか否かが決定される。メッセージがメッセージM1である場合、プロセスはステップ222へと進むのであり、そこでは受信されたメッセージM1がメッセージM1の反復であるか否かを決定する。メッセージM1の反復は即ち特定のトランザクションについての送金元銀行からのメッセージM1の再送であり、送金元銀行がメッセージM1を以前送信したのにタイムアウト期間内にメッセージM4の戻しを受信できていない場合に生じ得る。
ステップ222の決定は、メッセージM1のトランザクション識別子を確認することによって行うことができる。メッセージM1が反復である場合には元のメッセージM1が既にスイッチサイトにて処理されていたかもしれないのであり、したがってトランザクション識別子(なお、トランザクション識別子は特定のトランザクションに関しての元のメッセージM1及び反復されたメッセージM1の両者について同じである)はスイッチサイトにて(例えば、トランザクション状態データの一部としてデータベース110A,110B内にて)記録されていることになり得る。よって、新たに受信されたメッセージM1のトランザクション識別子がスイッチサイトにて記録されたトランザクション識別子と一致する場合には、メッセージM1が反復であることが分かる。代替的に又は追加的には、反復されたメッセージM1は、(例えば、そのメッセージヘッダ内にて)当該メッセージが反復されたメッセージであることを指示する反復情報を含むことができる(例えば、この反復情報を、送金元銀行のバンキングアプリ120A,120BによってメッセージM1に追加することができる)。
メッセージM1が反復であると決定された場合、プロセスはステップ224へと進む。他方で、メッセージM1と関連付けられているトランザクションに関する以前のメッセージがスイッチサイトで処理されていなかった場合、メッセージM1は再送されたものではないと決定され、むしろそれは真性な意味で最初に送信されたメッセージであって特定のトランザクションと関連付けられたメッセージであることが分かる。この場合、プロセスはステップ230へと進み、そこではメッセージM1が普通に処理される。
反復メッセージM1に含まれる反復情報を用いることは、特に有利であることに留意されたい。例えば、次のシナリオを検討されたい:反復情報が使用されておらず、且つ、メッセージM3の受信後且つトランザクションサマリ記録TSの作成後且つメッセージM4の送信前に、スイッチサイトが丸ごと非稼働状態に陥った場合。メッセージM4の欠如によって、送金元銀行はメッセージM1を再送信することになり、これは代替的なスイッチサイトへと再ルーティングされることになる。(トランザクションサマリ記録TSが元のスイッチサイトのデータベース110A,110B内に格納されているが故に)代替的スイッチサイトはトランザクション識別子についての記録を有しておらず、したがって、トランザクション識別子の一致に単に依拠してメッセージM1が反復であると決定することができない。よって、トランザクションが既に元のスイッチサイトにて(トランザクションサマリ記録TSの作成によって)完了されていたにも関わらず、メッセージM1と関連付けられているトランザクションは、代替的スイッチサイトにて新規なトランザクションとして処理される。このため、トランザクションは誤って二重処理されることになる(即ち、決済の際には送金者の意図した額の2倍の額の金銭が移転されることになる)。他方で、反復情報が用いられれば、任意のスイッチサイトの任意のスイッチにおいても再送メッセージM1が反復であることが決定できるようになる(さもなくば、元のメッセージM1が処理されてトランザクション識別子が格納されたスイッチサイトでのみ決定が可能となる)。したがって、反復情報の使用によって、メッセージM1が新たなメッセージM1として誤って1回より多く処理される危険性を減少させるのであり、これによって同じトランザクションが誤って1回より多く処理される危険性を減少させる。
ステップ224では、反復メッセージM1と関連付けられたトランザクションについてのメッセージM4がスイッチサイトにて利用可能であるか否か(例えば、メッセージM4がスイッチサイトのデータベース110A,110B内に格納されているのか)を決定する。メッセージM4が利用可能である場合、トランザクションについてのトランザクションサマリ記録TSが作成されていたことが暗示されるのであり、また、スイッチサイトにてトランザクションが完了されていたことになる。この場合、プロセスはステップ226へと進み、ここではメッセージM4が送金元銀行へと再送される。これによって、当初送信されていたメッセージM4が送金元銀行によって受信されていなかったとしても(或いは少なくともタイムアウト期間の満了前までに受信されていなかったとしても)、トランザクションが成功裏に完了されたことを銀行に確認的に知らせることができる。そして、プロセスはステップ232にて終了する。
他方で、メッセージM4が利用可能でない場合、トランザクションが成功裏に完了されたか否かについて不確定性があることが暗示される。これが起こる場合としては、例えば次の場合があり得る:トランザクションが当初処理された(且つ、トランザクションが成功裏に完了されていたならばメッセージM4が生成されていたことになっていた)スイッチサイトのスイッチ両方が(技術的な故障等によって)利用不能となった場合。この場合、トランザクションの状態は未知であり、メッセージM4を取得することは可能でない。したがって、プロセスはステップ232にて終了する。したがって、決済サイクル終了時において手動でトランザクションを調査する必要がある(後述参照)。
メッセージがメッセージM1ではないことがステップ220にて決定された場合、そのメッセージは、トランザクションの資金を受け取る側の銀行から受信されたメッセージM3であるはずである。この事例では、図2Bのプロセスを行っているスイッチがトランザクションについてのトランザクション状態データにアクセスできる場合のみにおいて、トランザクションを完了することができる(即ち、メッセージM1が処理され且つトランザクション状態データが格納されているデータベース110A,110Bへのアクセスを有しているサイトと同じサイト、にスイッチが存在していることを要する)。スイッチがトランザクション状態データへのアクセスを有している場合、プロセスはステップ230へと進み、そこではメッセージM3が普通に処理される。これによって、トランザクションは完了されることができる(結果としてメッセージM4が生成される)。そして、プロセスはステップ232にて終了する。他方で、スイッチがトランザクション状態データへのアクセスを有していない場合、トランザクションを完了することはできない(メッセージM4の発行前にトランザクション状態データベースが格納されているサイトのスイッチが全て非稼働状態に陥った場合にこれが起こり得る)。したがって、プロセスは単にステップ232にて終了することになる(メッセージM4は生成されない)。
したがって、トランザクションが成功裏に実行されたことを確認するメッセージM4が送金元銀行にて受信されない場合、トランザクションを指示する当初のメッセージM1を送金元銀行が再送し得る。(未だ稼働中のスイッチサイトにて成功裏に処理されたトランザクションを表す)メッセージM4が利用可能であるが、単に失われたか遅延している場合、反復メッセージM1に応答してメッセージM4を送金元銀行へと再送信する。もっとも、メッセージM4が利用可能でない場合、次のどちらかに該当する:トランザクションが成功裏に処理されなかったか(即ち、メッセージM4がそもそも生成されていないことを意味する)、又は、メッセージM4の生成の後にトランザクションが処理されたスイッチサイトの全てのスイッチが非稼働状態に陥ったことになる(即ち、メッセージM4の再送が不能であることを意味する)。この場合、再送信されたメッセージM1に関して更なる処理は行われない。これによって、システム100がトランザクションを二重に処理しないようにする(これによって、送金元銀行口座にて金銭が二重に引き落とされる局面を回避しやすくする)。この場合では、(メッセージM1の再送信にもかかわらず)メッセージM4は依然として送金元銀行によって受信されないのであり、銀行のバンキングアプリ102A,102Bはユーザに対してトランザクションが成功していないかもしれないと報告することができる。決済サイクルの終わりにおいて、送金元銀行の内部記録と受取側銀行の内部記録とシステム100によって生成されたトランザクションサマリ記録TSとを分析して、トランザクションの帰趨を決定して、全てのトランザクション資金の勘定がなされていることを保証することができる。
上述の実施形態では、メッセージM4を受信することについての送金元銀行のタイムアウト期間は、メッセージM4が到着するのに合理的に要するであろう期間として当業者によって決定されるのであり、システム100内の各コンポーネントの処理時間の期待値及び該当する場合にはネットワーク遅延等を加味する。図2Aを参照するとステップは優先順位リストによって決定された適切なスイッチへとトランザクションメッセージを「転送」することを含んでいるが、ステップ202でメッセージを受信するスイッチが実際には(優先順位リストによると)メッセージを処理すべきスイッチである場合、トランザクションメッセージは実際には異なるスイッチへと転送されないこととなることが理解される。むしろ、メッセージは受信を行ったスイッチそのものによって処理される。
上述の特徴によって、システム100の1以上のコンポーネントが非稼働状態に陥ったとしてもトランザクション処理が確実且つ効率的に続行されることが保証される。更なる検査として、決済サイクルの終わりにおいて且つトランザクションサマリ記録TSを用いての決済処理をバックオフィスユニット114が行う前に、トランザクションサマリ記録TSによって決定された{各銀行へ向かっての及び/又は各銀行からの}トランザクション合計額(即ち、移転されるべき金銭の合計額)を、スイッチによって保持されている対応するトランザクション金額についての記録との対比で検査する(例えば、各トランザクションのメッセージM1を処理するスイッチが、トランザクション額並びに送金元及び受取側銀行についての記録を維持する)。メッセージの処理及びトランザクションサマリ記録TSの作成が正しく行われているのならば、トランザクションサマリ記録TSによって記録された{各銀行へ向かっての及び/又は各銀行からの}トランザクション合計額は、スイッチ記録と完全に一致するはずである。この場合、決済処理を確実に行うことができることが分かる。他方で、トランザクション合計額に関して食い違いがある場合、トランザクションサマリ記録TSの生成において問題が発生したことが分かる。したがって、このことを調査して、決済処理の前に修正しておくことができる。
したがって、上述の特徴を前提とすれば、システム100によって次の事項をより確実にすることができるということが理解されるであろう:決済サイクルの終わりにおいて処理される前に、銀行によって指示された電子トランザクションが削除されたり、破損したり、重複処理されたりしないようにすること。これによって、指示された各々のトランザクションが決済サイクルの終わりにおいて確実に勘定され且つ1回だけ集計されるようにすることを確実にすることができる。上記のことは、システム100のコンポーネントが故障しても、又は、システム100の任意のコンポーネントに関してコンポーネントの一時的シャットダウンを要するような保守作業が計画されていても、成立する。また同時に、システム100が少なくとも1つの稼働中のスイッチを有している限り、銀行口座保有者は新たなトランザクションの指示を出し続けていくことができ、平常通りのサービスを享受し得る。
債務管理
上述したシステムにおいては、銀行間での差金決済は周期的に行われる。換言すれば、周期的に銀行間で現金が移転される。すなわち、トランザクションサマリ記録TSは、決済時において支払うことの約束である。この実施形態での決済は、イングランド銀行(BOE)等の共通預金を保持する銀行によって実現されるシステムを介して、本システム100とは別個に行われる。このような決済システムは当業者に既知である。したがって、決済のために保持される預金に応じてデビット上限が設けられている。銀行は、自己のデビット上限を絶対超過してはならない。
複数のサイトに渡って分散された、実施形態における頑健なシステムでデビット上限を実現するためには、問題がある。これは図3Aにて説明する。
図3Aに示した例では、銀行Aが−10,000GBPのデビット上限602を有しているものと仮定する。システム100はスイッチサイト1(603、単に「サイト1」ともいう)とスイッチサイト2(604、単に「サイト2」ともいう)とに分けて分割されているため、頑健性を確実にするためには、デビット上限602をサイト1とサイト2との間で均等に分かつ。各ケースでは、各サイトのスイッチがそのサイトについてのデビット上限を記録する。したがって、この場合においては、銀行Aと関連付けられたサイト1のデビット上限は−5,000GBPであり、銀行Aと関連付けられたサイト2で格納されたデビット上限も−5,000GBPである。勿論他の分割態様も適切たり得、例えば4つのサイトに渡って分散されている場合においては−2,500GBP等とし得る。
デビットトランザクションたるトランザクション1がサイト1で処理されたと仮定する。トランザクション1は、−2,500GBPのデビットトランザクションである。ここで、決済リスクポジション(SRP、Settlement Risk Position)とは各サイトについて今まで発生したトランザクションの合計を意味する術語であり、即ちサイト1に関してのSRPは−2,500GBPである。したがって、サイト1上での、将来のトランザクションに利用し得るデビット上限の残部(単に「利用可能デビット枠」ともいう)は、−2,500GBPである。サイト2では何らのトランザクションも行われないため、サイト2のSRPは0であり、サイト2における銀行Aの利用可能デビット枠は未だ−5,000GBPである。したがって、合計利用可能デビット枠は−7,500GBPであり、合計SRPは−2,500GBPである(605)。
次に、第2のデビットトランザクションたるトランザクション2がサイト2で処理され、トランザクション2は−300GBPであると仮定する。したがって、サイト2についての利用可能デビット枠は−4,700GBPであり、サイト2上でのSRPは−300GBPである。サイト1のSRPは−2,500GBPに留まり、サイト1の利用可能デビット枠は−2,500GBPに留まっている。銀行Aについての合計SRP(即ち、サイト1のSRPとサイト2のSRPの和)は−2,800GBPであり、また、銀行Aの利用可能デビット枠(即ち、サイト1及びサイト2の利用可能デビット枠の和)は−7,200GBPである。図3Aにおいては利用可能デビット枠の計算は不図示であることに留意されたい。
次に、サイト1で第3のデビットトランザクションたるトランザクション3が試みられたと仮定する。トランザクション3は−2,600GBPのデビットである。すなわち、(仮にトランザクションが処理された場合に)サイト1のSRPが−5,100GBPに達し、したがってサイト1との関連で銀行Aに対して割り当てられた−5,000GBPのデビット上限を超過することになる。よって、トランザクション3は却下される。
もっとも、トランザクション3到来前においては、銀行Aの合計SRPはたったの−2,800GBPであったのであり、それ故に銀行Aの合計利用可能デビット枠は−7,200GBPであり、トランザクション3は処理されるべきといえる。すなわち、技術的な故障に対して追加的な頑健性付与措置を講じたがために、何もなければ許容されたはずのトランザクションが妨げられることになる。当該問題点に対応することを目指す実施形態について以下説明する。
図3Bは、本願開示の実施形態による例を示す。例では、デビット上限651は−10,000GBPのままである。図3Aに示した例と似て、図3Bの例ではデビット上限651は2つのサイト間で等しく分割されている。換言すれば、サイト1は−5,000GBPのデビット上限を有しており、サイト2は−5,000GBPのデビット上限を有している。
図3Aと類似の例において、トランザクション1はサイト1に到来し、これは−2,500GBPのデビットである。したがって、サイト1との関連での銀行AのSRPは−2,500GBPであり、サイト2との関連での銀行AのSRPは0であり、両サイトを通算しての銀行Aの合計SRPは−2,500GBPである。さらに、サイト1の利用可能デビット枠は−2,500GBPへと縮減し、サイト2の利用可能デビット枠は−5,000GBPのままである。したがって、合計利用可能デビット枠は−7,500GBPである。図3Bにおいては利用可能デビット枠の計算は不図示であることに留意されたい。
そして、トランザクション2はサイト2に到来し、これは−300GBPのデビットである。したがって、サイト1との関連での銀行AのSRPは−2,500GBPのままであり、サイト2との関連での銀行AのSRPは−300GBPであり、それ故に合計SRPは−2,800GBPである。さらに、サイト2の利用可能デビット枠は−4,700GBPに縮減し、また、サイト1の利用可能デビット枠は−2,500GBPのままである。したがって、銀行Aの合計利用可能デビット枠は−7,200GBPである。
図3Aを参照して説明されたように、トランザクション3(2,600GBPのデビット)がスイッチサイト1に到来すると、サイト1のSRPがサイト1に割り当てられた5,000GBPのデビット上限を超過することとなる故に、トランザクションは却下される。この問題を回避するために、システム内にて調整サイクルを周期的に行う。具体的には、調整サイクル656は、サイト1及び2のスイッチによって周期的に行われる。調整サイクルは、各サイトのSRPの現在の大きさを合算することによって調整値を計算することを含む。すなわち、SRP1の現在の大きさたる−2,500GBPと、SRP2の現在の大きさたる−300GBPとを合算して−2,800GBPを得る。そして、この和をサイト数で平均化する。この場合、2つのサイトに渡ってならされた平均値(mean average)は、−2,800/2=−1,400GBPである。勿論のこと、中央値(median average)等の他の種類の値を用いることもできる。システム内の全サイト(この場合はサイト1及び2)に渡っての平均SRPを決定することの意義は、全スイッチサイト間での銀行債務を実効的にバランシングすることにある。すなわち、1つのスイッチサイトが、他のスイッチサイトに比して相当に高額なトランザクションを受けた場合、(全スイッチに渡っての銀行のデビット上限が超過されていない限り)システム100のデビット上限が超過されない。
特定のスイッチサイトに適用されるべき調整値を算出するためには、以下の数式を用いる:
ここで、「adjustment_site」は特定のスイッチサイトに適用されるべき調整値であり、「averaged_SRP」はシステム内のスイッチサイト間でのSRPの平均値であり、「SRP」は特定のスイッチサイトにおけるSRPである。
この数式を用いることによって、サイト1における調整値=−2800/2−(−2500)=+1100であり、サイト2における調整値=−2800/2−(−300)=−1100であることが分かる。
したがって、特定のサイトのSRPを調整値によって調整する。この調整値は、銀行の合計SRPに影響を与えない(したがって、銀行が全体的デビット上限を超過することが許容されることはない)。むしろ、調整済みSRP値は、銀行の債務を全スイッチサイトに渡って分散させるために用いられる。
より正式には、調整済みSRP=SRP値+adjustment_siteである。
したがって、図3Bの場合、調整サイクルが実行された後においては、サイト1の調整済みSRP=−2500+1100=−1,400GBPであり、サイト2の調整済みSRP=−300+−1100=−1,400GBPである。換言すれば、各サイトにおける実効SRPは等しい。
調整済みSRPと新規トランザクションとの和がサイトのデビット上限を超過しない場合、新規トランザクションは承認される。しかし、調整済みSRPと新規トランザクションとの和がサイトのデビット上限を超過する場合、新規トランザクションは却下される。
次に、図3Bを参照するに、サイト1の調整済みSRP(−1,400GBP)と、トランザクション3たる新規トランザクションの額(−2,600GBP)とを用いると、合計は−4000GBPとなる。これはサイト1のデビット上限−5,000GBPを超過しない故に、システム100によって許容される。したがって、このようにして、各サイトの調整値を用いることによって、有効なトランザクション額(即ち、合計デビット上限によって許容されるトランザクション額)が個々のスイッチサイトの利用可能デビット枠に基づいて却下されてしまう場合を減らす。
実施形態では、(新たな調整値を計算するための)調整サイクルは周期的に訪れる。周期は、例えば20秒若しくは30秒毎等の周期であることができ、又は、サイトが所定のトランザクション件数を扱うたびに訪れるか、または、サイトのSRPが所定額を超過した際に訪れることができる。
サイトが故障した際には、残存するサイト各々のデビット上限を増額させてデビット上限の全額が利用可能となるようにすることができる。したがって、例えばサイト2が故障したのならば、デビット上限の全額−10,000GBPをサイト1に割り当てることができるのであり、これによってデビット上限の全額に達するまでトランザクション処理を続行することができる。
各サイトの実際のSRP値は重要である(この例では、図3Bの全てのトランザクションが行われた後においては、サイト1が−5100であり、サイト2が−300である)。なぜならば、トランザクションがサイトでなされた後に関していえば、サイトのSRPは、(SRPが正であれば)銀行に払うべき金額に、又は(SRPが負であれば)銀行が払うべき金額に、等しいからである。決済が正しく行われたことを保証するために、各サイトの実際のSRP値は、不変のままである必要がある。したがって、合計デビット上限が超過されないことを保証するために用いられるのが調整済みSRP値であるものの、任意の時刻における各サイトの実際のSRP値はそれぞれのサイトに未だ格納されたままである。各サイトのSRPを可能な限り正確に維持するために、送金元銀行に関してはメッセージM1の成功裏な処理後にSRPの更新を行い、受取側銀行に関してはメッセージM3の成功裏な処理後にSRPの更新を行うことに留意されたい。
ゲートウェイ用途
既述のように、各銀行のゲートウェイ104A,104Bは、該銀行とスイッチSW1,SW2,SW3,SW4との間でのメッセージ転送の制御を支援する。各ゲートウェイ104,104Bは、自己の銀行及びスイッチの代わりに幾つかの機能を行うのであり、これによって銀行及びスイッチにおける処理負荷を減らす。ゲートウェイアプリケーションを全体のシステム内で使用することは任意である、ということにここで留意されたい。もっとも、任意にゲートウェイが用いられない場合、バンキングアプリケーション102A,102Bは次の事項を同じような機能性をもたらしつつ行える必要がある:構造に関する検証(後述参照、特に図4のステップ906);メッセージに関する署名、送信及び検証(後述参照、特に図4のステップ910,912,914);メッセージに関するルーティング;並びにメッセージM1反復情報の付加(該当する場合、上述参照)。
ゲートウェイの1つの機能は、(銀行における口座保有者の指示に基づいて)銀行がシステム100にトランザクションを処理させたい場面に関する。一般に、各銀行は、口座管理及び自行の口座保有者によるトランザクション指示等を許容することに関して、異なるプロプライエタリなシステムを用いる。もっとも、効率性の観点から、スイッチによって処理されるトランザクションメッセージは、特定の標準的構造(或いは、既述のISO20022標準等のフォーマット)に準拠していることを要する。したがって、銀行の口座保有者によって生成された任意のトランザクションメッセージは、スイッチによって受け付けられるためには、標準タイプトランザクションメッセージの形式に準拠していることを要する。さらに、セキュリティ上の理由から、銀行とスイッチとの間で送信された任意のトランザクションメッセージはデジタル的に署名されていることを要するのであり、また、(デジタル署名を用いて)検証されることを要するのであり、これによってメッセージの出所が真正であり正当なものであることを保証し得る。
トランザクションメッセージの構造の検査は、ゲートウェイによって行われる。さらに、銀行からスイッチへと送信されるべきメッセージ(これらのメッセージは受信側スイッチによって後に検証される)に対しての署名付与、及び、スイッチから銀行へと送信されるメッセージ(これらのメッセージは送信側スイッチによって以前署名されている)の検証は、ゲートウェイを用いて実現される。すなわち、銀行のゲートウェイが銀行のプロプライエタリなシステムとスイッチとの間のトランスミッションインターフェースを提供するのであり、これによってトランザクションメッセージがデジタルに署名され及び検証され並びに要求される標準的構造に準拠することを保証する。トランザクションメッセージの構造並びにデジタルな署名及び検証に関しては、任意の適切な標準を使用することができる。このような標準は、当業者にとって既知である。デジタルな署名及び検証に関する例では、メッセージデータについてハッシングを行い(SHA1によってハッシュする)、そして送信に際してこれを暗号化する(RSA暗号を使用)。実施形態では、ゲートウェイ104A,104Bによって処理されるべきトランザクションメッセージはそれぞれメッセージキュー106A,106Bにてキューイングされる。ゲートウェイ104A及び104Bが設けられていない場合、バンキングアプリケーション102A及び102Bがこの機能を提供する必要がある。
ゲートウェイは、各メッセージのヘッダにルーティング情報を付加することによってもメッセージをスイッチサイトへとルーティングしており、この情報はメッセージキュー106A,106B,108A,108Bによって読み取られてメッセージが適切なスイッチサイトへと仕向けられる。例えば、図1の例では、メッセージキュー108AはMQ1と表示され、メッセージキュー108BはMQ2と表示されることができる。したがって、ゲートウェイによって、スイッチサイトへと送信されるべきメッセージの各々のヘッダにMQ1又はMQ2の表示が追加されて、これによりメッセージキュー106A,106Bがメッセージを適切なスイッチへと仕向けることができる。また、1つの銀行が複数の銀行側メッセージキューユニット106A,106Bを有していることもでき(例えば、銀行1は複数の銀行側メッセージキューユニット106A1,106A2,...,106An(不図示)を有していることができる)、また、ゲートウェイによって追加されるルーティング情報はメッセージがどの銀行側メッセージキューユニットへと仕向けられるべきかを特定する情報を含むことができる。有利なことに、この構成によりシステム100の負荷分散が支援される。
例示的な実施形態として、メッセージが銀行1からスイッチへと送信された場合の、銀行1のゲートウェイ104Aの動作とスイッチの動作とを、図4のプロセスを参照して説明する。プロセスはステップ900にて開始される。ステップ902では、ゲートウェイ104Aが銀行1のバンキングアプリ102Aからのトランザクションメッセージを受信するのであり、このメッセージは処理のためにいずれかのスイッチへと送信されるべきものである。ステップ904では、ゲートウェイ104Aがトランザクションメッセージの構造を分析する。特に、ゲートウェイ104Aは、メッセージがスイッチによる処理を受けるために必要とされる標準的構造を有しているかを確認して確実にする。これには、全ての必要な情報がメッセージ内に含まれていることを保証することも含まれる。例えば、メッセージが銀行1の口座から銀行2の口座への資金の払い込みを指示している場合、支払額及び通貨種類と、銀行1の銀行ソートコード及び口座詳細事項と、銀行2の銀行ソートコード及び口座詳細事項とが全てメッセージ内に存在していることを保証するのであり、且つ、これらが正しいフォーマットに準拠していることを保証する(なぜならば、トランザクションを完了するためにはこれらの情報が必要だからである)。またこのステップには、メッセージが一意的なトランザクション識別子を有しているか否か及びメッセージが適切なルーティング情報を有しているか否かについて検査することも含まれている。
ステップ906では、メッセージ構造が標準に準拠するものと決定されると、プロセスはステップ910へと進む。他方、メッセージ構造が標準に準拠していないと決定されると(例えば何らかの必須情報がメッセージから欠落している場合)、プロセスはステップ908へと進む。ステップ908では、メッセージがエラーメッセージを伴って銀行1へと返送される。エラーメッセージは銀行1に対して次の事項を通知する:トランザクションメッセージがメッセージ標準に準拠していなかったこと、及び、(例えば欠落していた情報を追記することによって)当該エラーを訂正してトランザクションメッセージを再送することを要すること。プロセスは、ステップ922で終了する。
ステップ910では、トランザクションメッセージが銀行1のデジタル署名で署名される。デジタル署名により、受信側スイッチはメッセージの真正性(即ち、メッセージが銀行1から発信されたこと)を保証できるようになる。そして、ステップ912では、トランザクション要求が、銀行1と(ルーティング情報で決定される)適切なスイッチサイトとの間のデータ通信チャンネル上で送信される。ゲートウェイは、銀行1のサイトにある記憶媒体上に格納されたソフトウェアを実行している回路によって実装されていることに留意されたい。有利なことに、この構成によれば、トランザクションメッセージに関しての検査及び送信がゲートウェイの回路によって完全に取り扱われることができるのであり、これによって銀行1のプロプライエタリなシステム及びスイッチサイトの処理負荷が削減される。なぜならば、正しい情報を含まないメッセージはスイッチサイトへと転送されないからである。また、システム内にゲートウェイが設けられていない場合、銀行アプリケーションがデジタル署名されたメッセージを提供し、これらには全ての関連性のある情報が含まれており、これらは適切なフォーマットで提供されている、ということが想定されている。
スイッチサイトのスイッチによってメッセージが受信されたらば、デジタル署名を用いてそれについての検証を行う。これがステップ914でなされる。既述のように、デジタル署名するステップ及び検証するステップ(それぞれステップ910及び914)によって、スイッチで受信された任意のメッセージがシステム100を使用するために加入している銀行のうちの1行から本当に到来したものであることの保証が支援される。署名の検証は、メッセージを最初に受信したスイッチ又は(該当する場合は)メッセージが転送された先のスイッチで、なされることができる。
ステップ916では、デジタル署名の検証が成功した場合にはプロセスはステップ920へと進むのであり、そこではトランザクションメッセージが適切なスイッチによって(既述のように)処理される。そして、プロセスはステップ922で終了する。他方で、デジタル署名の検証が成功しなかった場合、トランザクションにエラー等が関連付けられていることが暗示される。したがって、プロセスはステップ918へと進み、そこではトランザクションメッセージが送金元銀行へと返送される。この場合、検証プロセス内でエラーが生じたことを示す情報が検証を行ったスイッチによって生成されるのであり、これがトランザクションメッセージと共に(或いはその一部として)返送される。有利なことに、これによって送金元銀行に対してトランザクションメッセージに問題があったことを通知できるのであり、したがって送金元銀行がこのことを調査することができる。そして、プロセスはステップ922で終了する。有利なことに、着信する全てのトランザクションメッセージについて行われるデジタル署名検証によって、(例えば、トランザクションを指示しようとしている授権されていない主体から発せられた)偽造された又は不正なメッセージが処理される事態の防止に役立つこととなる。
したがって、ゲートウェイの使用によって、処理のためにスイッチで受信されたトランザクションメッセージの全てが正しい標準的構造を有していることを保証しやすくなる。したがって、スイッチは、(異なる銀行で生成される複数の異なるメッセージ構造ではなく、)この1つの標準的構造のみを扱えれば済むのであり、これ故にシステム100の効率性が向上する。さらに、正しいメッセージ構造に準拠している場合のみにメッセージがネットワークを介して銀行からシステム100へと送信されるため、正しいメッセージ構造を有していないメッセージ(即ち、却下されるであろうメッセージ)をスイッチへ送信するということによってネットワーク帯域幅が浪費されない。更なる利点としては、デジタル署名に関しての署名行為及び検証行為をゲートウェイ及びスイッチにさせる実装によって、システムのセキュリティを向上させることに役立たせることができる。
既述のように、実施形態では、各ゲートウェイ104A,104Bは、関連する銀行の位置にある記憶媒体(不図示)上に格納されたソフトウェアを実行している回路によって実装されている。このソフトウェアは、各銀行の内部機能を実装する任意のソフトウェア(例えば、各銀行の口座管理用システム及び口座保有者によるトランザクション等の指示を可能にするためのバンキングアプリ等)及びスイッチサイトの内部機能を実装する任意のソフトウェア(例えば、スイッチSW1,SW2,SW3,SW4やメッセージキュー108A,108B等によって実装される任意のソフトウェア等)とは機能的に別個のものとされる。有利なことに、この構成によれば、ゲートウェイの機能の利点(向上した効率性及びセキュリティ、上述参照)を実現させつつ銀行又はスイッチサイトのコア処理負荷を増大させないことができる。
ゲートウェイ104A,104Bの第2の機能は、メッセージの送受信及びシステム100のデータ負荷分散のために、どの銀行及びスイッチサイトを利用できるかを監視することに関する。
メッセージが所定期間内に関連するメッセージキューユニット106A,106B,108A,108Bを介してスイッチサイトに送達されなかった場合、関連するメッセージキューユニットは、コレクトタイム(collect time)が満了したことを示す情報をメッセージヘッダに追加してメッセージをゲートウェイに戻す。先の場合は例えば次のどちらかの局面の結果生じ得る:スイッチサイトのメッセージキューユニット108A,108Bが所定の期間内にメッセージを関連するメッセージキューユニット106A,106Bから取得しなかった場合、又は、スイッチサイトのスイッチが所定の期間内にメッセージを関連するメッセージキューユニット108A,108Bから取得しなかった場合。このことには幾つかの理由があり得るのであり、これらには次の事象が含まれる:スイッチサイトにおけるメッセージキューユニット108A,108Bの故障;スイッチの故障;又はネットワークの故障。この場合、ゲートウェイはメッセージを代替サイトへと再送信する。したがって、スイッチサイト1のSW1及びSW2のいずれもが所定期間内にメッセージを拾わなかった場合、指示発令側銀行のゲートウェイは、返送されたメッセージを受信すると、メッセージをスイッチサイト2へと再ルーティングする。もっとも、この構成の問題点は次の点にある:例えば特定のスイッチサイトの両スイッチのダウンタイムが長引いている場合、メッセージの再ルーティングが行われるがこれは相当にプロセッサを酷使するのでありまたネットワーク帯域幅を浪費する。このようにいえるのはアクティブでないサイトへ継続的にメッセージが送信されているからであり、ただエラーメッセージが返ってくるだけである。
同様に、1以上の銀行の内部システムが一時的にメッセージを受信できなくなり得る。例えば、図1の例では、銀行2の口座保有者に対して支払いを命じるトランザクションメッセージM1が銀行1の口座保有者によって発せられたという場面において、銀行1からの資金による決済を待ち受けるように銀行2に通知するメッセージM2を、銀行2が受信できないかもしれない。この場合、メッセージM2がバンキングアプリ102Bへと送信された後にメッセージM3が銀行2から受信されないのであり、したがってトランザクションは完了されない。ここでも、銀行2が長期にわたって利用不能である場合、メッセージM2を銀行2へと送り続けるこの方法は問題となる。なぜならば、この方法はプロセッサに対して相当に高負荷であり、ネットワーク帯域幅を浪費するからである。この理由は、アクティブでない銀行へとメッセージが継続的に送り続けられるという点に求められる。
これらの問題を緩和するために、各銀行のゲートウェイ104A,104Bは、他の銀行のうちどれが及びどのスイッチサイトが、メッセージ受信に関して利用可能であるかということを追跡するように構成されている。これが、利用可能性キャッシュ(availability cache)として定義される。
ゲートウェイがスイッチサイトを監視することに関しては、テストメッセージをそのスイッチサイトのメッセージキューユニット108A,108Bを介してネットワークを経由するようにスイッチサイトへと送信し、スイッチサイトから戻ってくるそのメッセージについてのエコーに関して待ち受ける。典型的には、ゲートウェイが特定のスイッチサイトから特定の期間にわたってメッセージを受信していない場合に、ゲートウェイはこのようなことを行う。エコー(より具体的にはリモートエコーという)はスイッチサイトに送られたテストメッセージのコピーであり、スイッチサイトからゲートウェイへと戻るように送信されるものである。エコーは、スイッチサイトのスイッチどれかによって生成されるのであり、テストメッセージ内に含まれる命令に準拠して生成されるものである。特定のスイッチサイトへテストメッセージを送ったことに応答して、ゲートウェイがそのメッセージについてのエコーを所定の期間内(例えば、メッセージM4の受信に関してのタイムアウト期間に等しい期間)に受信した場合、スイッチサイトがそのメッセージキューユニット108A,108Bを介して未だにメッセージを受信できるということをゲートウェイが知ることになる。他方、エコーが受信されない場合、スイッチサイトが自己のメッセージキューユニット108A,108Bを介してメッセージを受信できないものとゲートウェイが決定するのであり(故障が原因かもしれない)、したがって更なるメッセージがこのルートを介してスイッチサイトへと送信されないようにする。
ゲートウェイがテストメッセージを上述の態様でスイッチサイトへと送信して所定の期間経過後に戻ってくるエコーが受信されなかった場合、スイッチサイトのメッセージキューユニット108A,108Bを介したスイッチサイトとの通信が利用不能であるとゲートウェイは決定する。なぜならば、このルートが利用可能であったならばテストメッセージがいずれスイッチサイトのスイッチに到達していたはずであり、そのスイッチがエコーとしてゲートウェイに戻されるべきテストメッセージのコピーを生成していたはずだからである。エコーが受信されない場合、ゲートウェイはもはやメッセージをスイッチサイトへそのメッセージキューユニット108A,108Bを介してルーティングしなくなる。換言すれば、スイッチサイトは利用不能と決定される。したがって、スイッチサイトのいずれかが利用不能であると決定されたらば、以後のメッセージ分配はゲートウェイによって制御される。
また、メッセージM1が所定期間内にスイッチサイトのスイッチによって拾われなかった(上述参照)が故に、メッセージM1がスイッチサイトからゲートウェイへと返送された場合にも、スイッチサイトが利用不能であるとゲートウェイは決定する。この場合でも、ゲートウェイはもはやメッセージをスイッチサイトへそのメッセージキューユニット108A,108Bを介してルーティングしなくなる。
念のため付言しておくが、ゲートウェイによってスイッチサイトが利用不能であると決定された場合であっても、必ずしもそのスイッチサイトのスイッチが利用不能であるとは限らない。むしろ、このことは、そのスイッチサイトのメッセージキューユニット108A,108Bを介してメッセージをそのスイッチサイトのスイッチへと送信することができないと暗示しているのである。例えば、単にネットワーク障害があるだけで、それによってスイッチサイトのメッセージキューユニット108A,108Bを介してメッセージをその特定のスイッチサイトのスイッチへと送信することが妨げられているだけなのかもしれないのであり、スイッチサイトのスイッチの機能は完全であるかもしれない。この場合、他のスイッチサイト及びサイト間データ通信リンクを介してスイッチへとメッセージをルーティングしていくことがまだできるかもしれない(例えば、ハッシュ関数にしたがって行う)。
(ゲートウェイでエコーが受信されていないこと又はメッセージM1がゲートウェイに返送されたことに起因して)スイッチサイトが利用不能と決定された場合、テストメッセージは周期的にそのメッセージキューユニット108A,108Bを介してスイッチサイトへと送られてスイッチサイトが復帰したか否かを決定する。スイッチサイトが利用不能のままであると、エコーは受信されず、したがってスイッチサイトへメッセージは送られないままである。他方、(修理または保守作業の完了によって)スイッチサイトの利用可能性が回復された場合、次のテストメッセージがスイッチサイトへと送られると、戻りエコーが受信されることとなる。この場合、ゲートウェイはスイッチサイトが再び利用可能となったものと決定し、そのメッセージキューユニット108A,108Bを介してメッセージが再びそのスイッチサイトへと送信されるようにする。また、そのスイッチサイトからトランザクションメッセージ(例えば、メッセージM2)が受信された場合、利用不能であると決定されたスイッチサイトが再び利用可能となったものとゲートウェイは決定する(このようにする理由は、もしスイッチサイトがまだ利用不能だったらばそのようなメッセージを受信することができなかったからである)。他行を監視することに関しては、銀行のゲートウェイは、スイッチにて生成された情報に依存しているか、及び/又は特定の銀行へのトランザクションに関してのメッセージM4の受領から推論される情報に依存している。
より具体的には、スイッチの各々が、システム100を用いる銀行のそれぞれへ周期的にテストメッセージを送って、これらの銀行のそれぞれからのエコーを待ち構えることができる。
特定のスイッチにおいて所定期間内に特定の銀行からのエコーが受信されなかった場合、この特定のスイッチからのメッセージを受信することに関してはこの銀行は利用不能であると決定される(スイッチと銀行との間のネットワーク接続に障害があるのかもしれない)。この場合、このスイッチから銀行へと送信されるべきメッセージM2は代替ルートを介して(例えば、スイッチサイトの別のスイッチを介して、又は代替スイッチサイトのいずれかのスイッチを介してサイト間データ接続を介して)再ルーティングされる。この場合、スイッチ自体は稼働中であり、ハッシュ関数に従ってメッセージを未だ受信することができ、またこれらのメッセージを処理することができる。唯一問題なのが実施にメッセージM2を問題の銀行へと実際に送信することであり、これはここで説明した再ルーティングによって克服される。このことがメッセージM4には妥当しないことに留意されたい。なぜならば、既述のように、メッセージM4は、(ハッシュ関数によって決定されたスイッチではなく、)当初メッセージM1が受信されたのと同じスイッチを介して、トランザクション要求を発している送金元銀行へと返送されることを要する。当初のスイッチと送金元銀行との間の接続が途切れている場合、このスイッチを介して送金元銀行へとメッセージM4を送信することができない。したがって、システムは、送金元銀行からのメッセージM1の再送信を待つ必要があり、当初のスイッチと送金元銀行との間の接続が途切れたままである場合には、再送信は、適切なメッセージキュー106A,106B,108A,108Bを介して、送金元銀行との接続を有している代替的受信側スイッチへとルーティングされる。この再送メッセージM1は(ハッシュ関数に従って)処理スイッチへと転送されるのであり、結果としてメッセージM4は再送され、また、このメッセージM4についての送信は代替的受信側スイッチを介して送金元銀行へと戻される。
全てのスイッチが特定の銀行からのエコーを受信できない場合、銀行全体が利用不能である(即ち、どのスイッチからもメッセージを受信できない)と決定されるのであり、このことを示す情報が他行全てのゲートウェイに中継を経て戻される。
また、例えば、銀行の内部システムについての計画された保守作業の場合、システム100を使用する各行は、システム100から切断することができる。この場合、銀行は意図的にスイッチから切断する(即ち、サインオフする)のであり、1以上のスイッチが、サインオフした銀行が利用不能となったことを示す情報を他行全てのゲートウェイに中継する。
(テストメッセージに対してのエコーが全てのスイッチに関して欠けていること又はサインオフに起因して)銀行が利用不能である場合、利用不能な銀行への資金トランザクションを指示するメッセージM1を受信したスイッチは、メッセージM4を生成でき、このメッセージM4を送金元銀行へと返送することができる。このメッセージM4は、成功したトランザクションを表す通常のメッセージM4とは異なる。なぜならば、このメッセージは、受取側銀行が利用不能であり、及び、それ故にトランザクションが成功裏に処理されなかったことを送金元銀行へと通知するための情報を含んでいるからである(この場合、送金元銀行のデビットされた口座に対しては再クレジット処理をしておくことができる)。特に、このメッセージM4は、トランザクションが却下された理由を示すデータを含んでいる(例えば、エコーの欠落から分かる受取側銀行におけるネットワーク障害を表す理由コード又は受取側銀行がサインオフしたことを表す理由コード)。したがって、送金元銀行のゲートウェイはこのメッセージM4を用いて受取側銀行が現在利用不能であると決定することができる。既述のように、エコーが受信されないこと又は銀行がスイッチからサインオフすることによって、スイッチは利用不能な銀行を認知することができる。エコーに基づいて又は銀行サインオフ手順に基づいてある銀行が利用不能であるとスイッチによって決定したことは、他行のそれぞれに中継されるが、特定の銀行に関して失敗したトランザクション要求を表すためにメッセージM4を使うことによって、この利用不能状態を他行に周知する更なる手段が得られることになる(例えば、スイッチによるこの情報の標準的な中継行為に遅延がある場合には、このことは有利となり得る)。
各銀行のゲートウェイは、スイッチによって中継された情報(この情報はエコーの使用及び/又は銀行サインオフ手順に基づいている)及び/又は特定の銀行が利用不能であることを示しているメッセージM4の受領に基づいて、他行の利用可能性について記録を維持する(例えば、銀行A:利用可能、銀行B:利用可能、銀行C:利用不能)。この記録が、各銀行にて保有されている利用可能性キャッシュの一部をなす(利用可能性キャッシュは、どのスイッチサイトが利用可能であるかに関する情報も含んでいる)。この記録があるが故に、利用不能な銀行へメッセージを送ろうとする試みによって生じる帯域幅の浪費が削減される。例えば、利用不能であると決定されている銀行(例えば、この場合では銀行C)へ仕向けられている新規な資金トランザクションを銀行Aの顧客が要求した場合、ゲートウェイはこの要求を却下するのであり、メッセージM1は一度も送られず、受取側銀行(銀行C)が現在利用不能であるとの通知を銀行Aのバンキングアプリによって銀行口座保有者に対して通知する。したがって、システム100を通して利用不能な銀行へとトランザクションメッセージを送ることによって浪費された帯域幅の量は削減される。
(既述のように)エコーの使用によって銀行が利用不能であると決定された場合、その銀行が以後復帰したか否かを決定するために周期的にテストメッセージを利用不能な銀行へと送信することができる。銀行が依然として利用不能のままであればエコーは受信されないのであり、したがって引き続きメッセージは銀行に送信されないことになる。他方、(例えば、故障していたネットワーク接続の再確立等によって)銀行が復帰した場合、次のテストメッセージが送信されたらば戻りエコーが受信される。この場合、ゲートウェイが、銀行が再び利用可能となったことと決定するのであり、その銀行へメッセージが送信されることが再び許容されることとなる。
スイッチからサインオフすることによって銀行が利用不能となった場合、その銀行が再接続(即ち、サインオン)するまではその銀行は利用不能のままとなる。銀行がスイッチにサインオンしてきた場合、1以上のスイッチが情報を全ての他行のゲートウェイへと中継し、その銀行が再び利用可能となったことを示す。
一般には、テストメッセージをスイッチによって各銀行に周期的に送信することができるのであり、周期は、利用不能である銀行に送られるトランザクションメッセージの件数が最小化されるように十分に短い周期とするのであり、これによって帯域幅を節約できる。同時に、周期は短すぎても良くはなく、テストメッセージが頻繁に送信されてネットワーク帯域幅を圧迫しすぎてしまいネットワークの効率性を減じてしまうほどに短期であってはならない(即ち、テストメッセージとエコーを用いて達成した当初の帯域幅節約を相殺するほど短期であってはならない)。例としては、特定の銀行に送られるテストメッセージの周期としては約5秒から30秒を想定できる。勿論、当業者であれば必要に応じてこれを変化させることができる。
実施形態では、ゲートウェイは、スイッチサイトが利用不能であると決定する前に複数のテストメッセージを送信する。同様に、各スイッチは、特定の銀行が利用不能であると決定する前に複数のテストメッセージを送信する。例えば、テストメッセージ間の送信周期が30秒である構成においては、ゲートウェイ又はスイッチは第1のテストメッセージを送出してエコーを待ち受けることができる。30秒後、エコーが受信されていなければ、ゲートウェイ又はスイッチは、第2のテストメッセージを送出して、エコーを待ち受けることができる。その30秒後、未だにエコーが受信されていなければ、テストメッセージの送信先たるスイッチサイト(ゲートウェイがテストメッセージを送信している場合)又は銀行(スイッチがテストメッセージを送信している場合)が利用不能であると決定されるのであり、そのスイッチサイト又は銀行へのトランザクションメッセージの送信は中止される。スイッチサイト又は銀行が利用不能であると決定する前に複数のテストメッセージを送信することによって、例えばネットワーク遅延等がスイッチサイト又は銀行から戻ってくるエコーに作用している場合に誤って機能しているスイッチサイト又は銀行へのトランザクションメッセージの送信を停止させなくて済むことをより確実にすることができる。
有利なことに、各銀行のゲートウェイによって維持されている利用可能性キャッシュの存在によって、利用不能と決定された銀行またはスイッチサイトへとトランザクションメッセージが送られないことになるのであり、それ故にメッセージを受け入れられないスイッチサイトや銀行へとメッセージを送信しようとするための試行回数が削減されることになる。この構成によれば、メッセージが破損したり失われたりする危険性を減少させる他、送達不能なメッセージのために処理帯域幅及びネットワーク帯域幅が浪費されないことになる。したがって、処理及びネットワークの効率性が向上する。
また、多くの場合、トランザクション所要時間に関して銀行は所定の制限値を義務づけていることに留意されたい。すなわち、銀行においてみた、初期メッセージM1の送信とメッセージM4の受信との間の時間が所定期間内に収まる必要がある。任意の適切な制限時間を設定することができるが、通常は約5秒から約15秒ほどに設定される。したがって、この制限時間内にトランザクションが完了されることを保証するために、可能な限り効率的にトランザクションメッセージがシステムのなかを通過していくように保証することが肝要である。有利なことに、各銀行にて利用可能性キャッシュが用いられるため、利用不能なスイッチサイトを経由してスイッチへとトランザクションメッセージを送信しようとする試みによって時間が浪費されない(利用不能なスイッチを関与させると、メッセージが結果として返送され、再ルーティングすることを要し、これ故に時間が浪費される)。同様に、(各銀行へ送信したテストメッセージと各銀行から受信したエコーに基づいて、)各スイッチは各銀行へのルートのうち利用可能なものについての記録を維持しているため、利用不能なルートを介して銀行へとトランザクションメッセージを送信しようとする試みによって時間は浪費されない。また、各スイッチが他のスイッチにポーリングしてその利用可能性を把握しているため、利用可能ではないスイッチへとトランザクションメッセージを送信しようとする試みによって時間が浪費されない。これらの特徴全てが、システム100内におけるトランザクションメッセージの効率的な送信を保証すること、及び、銀行によって決定された制限時間内にトランザクションが完了されるように保証すること、に寄与している。
更なる利点としては、スイッチサイト及び銀行の利用可能性を監視するために並びに命令を発するためにゲートウェイを用いることによって、この処理はバンキングアプリ102A,102Bからオフローディングされることになる。したがって、銀行においての全体的な処理能率は、向上する。
図5は、システム100と共に使用するためのコンピュータ700を示す。実施形態では、システム100の各要素(即ち、バンキングアプリ102A,102B、ゲートウェイ104A,104B、メッセージキューユニット106A,106B,108A,108B,112A,112B、スイッチSW1,SW2,SW3,SW4、データベース110A,110B及びバックオフィスユニット114)によって行われる機能は、このようなコンピュータ700の1台以上をもって実装される。これらのコンピュータはサーバであることもできる(これらは物理サーバ又は仮想サーバであることができる)。コンピュータ700は、中央演算装置(CPU)702によって制御されるのであり、CPU702はメモリ704内に保持された命令を処理するように構成されている。コンピュータ700とのデータ通信は、ネットワークインターフェース706を介して行われる。コンピュータ700は(ハードディスクドライブ、半導体メモリ又はテープドライブ等の)記憶媒体708をも有するのであり、これはデータを格納するためのものである。
システム100は金融トランザクションメッセージの処理との関連で説明されたが、システム100は、各データユニットを必ず計上し、且つ、1回だけ計上する態様での更なる処理を行えるように管理されることを要する任意の種類のデータユニットの処理及び格納用途に用いることができることに留意されたい。この場合、どのようなデータユニットが用いられるにしても、システム100は、データユニットの削除、破損又は重複が回避されるのを確実にするために役立つ。
例えば、システム100は、科学的又は工学的な実験にて生成されたデータを、データ分析に先立って処理及び保持するために用いることができる。この場合、各データユニットは、例えば個別の実験測定値であることができる。このようなデータユニットは、多くの場合入手が極度に困難であるか高価な出費を伴うものであり、したがって、該データの削除又は破損を回避することが肝要である。さらに、後行する分析のためには、データが重複していないことが肝要であり、さもなくば分析から導出される結論が誤ったものとなってしまう場合がある。したがって、このような種類のデータを管理するに際しては、システム100を用いることが有益となる。
上記の記載は銀行との関連で説明されているが、本願開示はクレジットカード会社等の資金のトランザクションを行う任意の金融機関にも関連するものである。
上述したシステム100の具体的な利点を挙げるとすれば、システムのコンポーネントの配置がシステムを頑健(即ち、システムの特定のコンポーネントが仮に機能不全に陥ったとしてもシステムが確実にトランザクションを処理し続けることができるという状態)にするために選ばれている一方で、一旦トランザクションメッセージが(ハッシュ関数による決定に従って)スイッチによって受信されると、当該メッセージはバックオフィスユニット114へと転送される以前においては単一のサイトにて保持及び処理されるため、システムの(異サイトの異コンポーネント間でのトランザクションメッセージの転送に起因する)レイテンシが減少することになる、という利点が挙げられる。したがって、システム頑健性が向上すれどもシステムのレイテンシは低いままとなる。
図1は(説明の便宜上)2つの銀行と2つのスイッチサイトと各スイッチサイトについて2つのスイッチを図示しているが、本発明の実施形態はこれに限定はされないことに留意されたい。現実世界においては、システム100を使用するように構成された多数の銀行が存在し得るのであり、各々が図1の銀行1及び銀行2の構成を有していることができる(即ち、バンキングアプリとゲートウェイとメッセージキューユニットとを有する構成)。また、スイッチサイト1及び2と同様に構成された3個目以上のスイッチサイトも設けられていることができる(各スイッチサイトは他のスイッチサイト及び各銀行とデータ通信可能とされている)。さらに、各スイッチサイトは、2つより多くのスイッチを含むことができ、それぞれは同じデータベース内にトランザクションメッセージを格納するように構成されており、これによって同じトランザクションに関連付けられているメッセージを特定サイトの任意のスイッチにて処理することが可能となる。当業者であれば、どのようにして図1のシステム100を拡張してより多くの銀行、スイッチサイト及び/又はスイッチを含めることができるかを理解するであろう。
上述はトランザクション要求との関係で述べたが、開示はこれに限定されてはおらず、任意の種類の電子メッセージが想定される。さらに、上述は、ゲートウェイ104Aへと送信する前にトランザクション要求をメッセージキュー106A内にて一時的に保持する構成との関係で述べたが、開示はこれに限定されてはいない。例えば、バンキングアプリケーション102Aは、トランザクション要求をメッセージキュー106A内に保持させずにゲートウェイ104Aと直接的に通信することができる。この構成は、ゲートウェイ104Aがトランザクション要求を扱えるようになるまでトランザクション要求を保持するバッファをゲートウェイ104A内に設けることによって達成し得る。
本願開示に関しては、上記教示事項を前提とすれば、様々な変更及び変形例を想定できることは明らかである。したがって、本願にて具体的に記述したものとは異なる態様で本願開示内容を実践することができるのであり、これも添付の特許請求の範囲内に含まれるものと解されるべきである。
ソフトウェア制御されたデータ処理装置によって少なくとも部分的に実装されるものとの関係で本願開示の実施形態が説明されている限りにおいては、そのようなソフトウェアを化体している光学ディスク、磁気ディスク、半導体メモリ等の非一時的マシン可読媒体も本願開示の実施形態を表すことに留意されたい。
上述の記載においては、簡潔性のために、異なる実施形態に関して異なる機能的ユニット、回路、及び/又はプロセッサを参照しつつ説明したことに留意されたい。もっとも、異なる機能的ユニット、回路、及び/又はプロセッサの相互間に関しては、実施形態に悪影響を与えずに任意の適切な役割分担を採用できることは明らかである。
説明した実施形態は、任意の適切な態様で実施されることができるのであり、これにはハードウェア、ソフトウェア、ファームウェア又はこれらの任意の組合せが含まれる。説明した実施形態は、随意的には、1以上のデータプロセッサ及び/又はデジタル信号プロセッサ上で実行されるコンピュータソフトウェアとして少なくとも部分的に実装され得る。任意の実施形態の要素及びコンポーネントは、任意の態様にて、物理的に、機能的に、又は論理的に実装されることができる。実際には、機能性を実装するに際しては、単一のユニット、複数のユニット、又は他の機能的ユニットの一部として実装することができる。したがって、開示した実施形態は、単一のユニット内で実装されるか、又は、異なるユニット、回路、及び/又はプロセッサ間で物理的に又は機能的に分散されることができる。
本願開示は一部の実施形態との関係で説明されたのであるが、具体的に列挙されたこれらに限定されることは意図されていない。また、ある特徴が特定の実施形態との関連で説明されているように見えても、当業者であれば開示された実施形態の様々な特徴は任意の適切な態様で組み合わされた上で手法を実施するために用いられ得ることに気付くであろう。

Claims (11)

  1. 金融機関からの電子トランザクション要求メッセージを処理するための装置であって、各トランザクション要求メッセージは第1の金融機関内の金融口座から第2の金融機関内の別の金融口座へと資金の払い込みを指示し、該装置は、
    ある位置に配置された複数のスイッチであって、各スイッチは金融機関からのトランザクション要求メッセージを受信するように動作可能である、複数のスイッチと、
    前記複数のスイッチに接続されたクラスターデータベースであって、前記クラスターデータベースは複数の同期化されたデータベースを備えており、前記クラスターデータベースは受信された前記トランザクション要求メッセージに基づいてトランザクションサマリ記録を生成するように構成されており、前記トランザクションサマリ記録は、受信された前記トランザクション要求メッセージによって定義された前記金融口座間での資金決済を可能とする、クラスターデータベース
    とを備える、装置。
  2. 各トランザクション要求メッセージは、前記トランザクション要求メッセージが関連付けられているトランザクションを一意的に識別する識別子を含み、前記装置は、前記識別子に基づいて前記トランザクション要求メッセージを特定のスイッチへとルーティングする処理回路を備える、請求項1に記載の装置。
  3. 各トランザクション要求メッセージはデジタル署名で署名されており、前記処理回路は前記署名されたトランザクション要求メッセージを検証するように動作可能であり、前記署名されたトランザクション要求メッセージを検証できない場合において前記処理回路は前記トランザクション要求メッセージを前記金融機関へと返送するように動作可能である、請求項1又は2に記載の装置。
  4. 前記処理回路は、検証不能なトランザクション要求メッセージが前記装置にて受信されたことについて前記金融機関に対して警告するようにさらに動作可能である、請求項3に記載の装置。
  5. 請求項1乃至4のいずれか1項に記載の装置を複数備えるシステムであって、前記装置は複数の位置にわたって分散されており、各装置は前記複数の装置のうちの他の装置の各々とデータ通信するように動作可能である、システム。
  6. 金融機関からの電子トランザクション要求メッセージを処理するための方法であって、各トランザクション要求メッセージは第1の金融機関内の金融口座から第2の金融機関内の別の金融口座へと資金の払い込みを指示し、該方法は、
    ある位置に配置された複数のスイッチのうちの1つのスイッチにて、金融機関からのトランザクション要求メッセージを受信するステップと、
    複数の同期化されたデータベースを備えており且つ前記複数のスイッチに接続されているクラスターデータベース内にて、受信された前記トランザクション要求メッセージに基づいてトランザクションサマリ記録を生成するステップであって、前記トランザクションサマリ記録は、受信された前記トランザクション要求メッセージによって定義された前記金融口座間での資金決済を可能とする、ステップ
    とを含む、方法。
  7. 各トランザクション要求メッセージは、前記トランザクション要求メッセージが関連付けられているトランザクションを一意的に識別する識別子を含み、前記方法は、前記識別子に基づいて前記トランザクション要求メッセージを特定のスイッチへとルーティングするステップを含む、請求項6に記載の方法。
  8. 各トランザクション要求メッセージはデジタル署名で署名されており、前記方法は前記署名されたトランザクション要求メッセージを検証するステップをさらに含み、前記署名されたトランザクション要求メッセージを検証できない場合において、前記方法は前記トランザクション要求メッセージを前記金融機関へと返送するステップを含む、請求項6又は7に記載の方法。
  9. 検証不能なトランザクション要求メッセージが受信されたことについて前記金融機関に対して警告するステップを備える、請求項8に記載の方法。
  10. コンピュータプログラムを格納するように構成された記憶媒体を備えたコンピュータプログラム製品であって、前記コンピュータプログラムは、コンピュータに読み込まれると請求項6乃至9のいずれか1項に記載の方法を前記コンピュータに行わせるコンピュータ可読命令を含んでいる、コンピュータプログラム製品。
  11. 添付の図面を参照して前記において実質的に記述された装置、システム、方法又はコンピュータプログラム製品。
JP2017551371A 2014-12-18 2015-10-14 電子トランザクション要求を処理するための装置、システム、方法及びコンピュータプログラム製品 Active JP6474915B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1422900.9A GB2533432A (en) 2014-12-18 2014-12-18 A device system, method and computer program product for processing electronic transaction requests
GB1422900.9 2014-12-18
PCT/GB2015/053034 WO2016097672A1 (en) 2014-12-18 2015-10-14 A device, system, method and computer program product for processing electronic transaction requests

Publications (2)

Publication Number Publication Date
JP2018501593A true JP2018501593A (ja) 2018-01-18
JP6474915B2 JP6474915B2 (ja) 2019-02-27

Family

ID=54337806

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017551371A Active JP6474915B2 (ja) 2014-12-18 2015-10-14 電子トランザクション要求を処理するための装置、システム、方法及びコンピュータプログラム製品

Country Status (11)

Country Link
US (1) US11080690B2 (ja)
EP (2) EP4220513A1 (ja)
JP (1) JP6474915B2 (ja)
AU (1) AU2015365764B2 (ja)
CA (1) CA2971665C (ja)
CO (1) CO2017007195A2 (ja)
EA (1) EA034401B1 (ja)
GB (1) GB2533432A (ja)
SA (1) SA517381770B1 (ja)
SG (1) SG11201704907QA (ja)
WO (1) WO2016097672A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10708213B2 (en) 2014-12-18 2020-07-07 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages
US10963882B2 (en) 2014-12-18 2021-03-30 Ipco 2012 Limited System and server for receiving transaction requests
US10997568B2 (en) 2014-12-18 2021-05-04 Ipco 2012 Limited System, method and computer program product for receiving electronic messages
US11080690B2 (en) 2014-12-18 2021-08-03 Ipco 2012 Limited Device, system, method and computer program product for processing electronic transaction requests

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8725607B2 (en) 2004-01-30 2014-05-13 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
CN110992175A (zh) * 2019-10-30 2020-04-10 成都摩宝网络科技有限公司 基于消息中间件的异步会计核算与交易分离方法及系统
CN111404643A (zh) * 2020-03-10 2020-07-10 山东汇贸电子口岸有限公司 一种基于消息队列的数据收发处理方法
CN112087373B (zh) * 2020-09-21 2022-05-13 全通金信控股(广东)有限公司 一种消息发送方法及业务装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002042038A (ja) * 2000-07-25 2002-02-08 Dai-Ichi Kangyo Bank Ltd 支払明細情報を提供可能な代金回収システム
US20050171811A1 (en) * 2000-09-26 2005-08-04 Bottomline Technologies (De) Inc. Electronic financial transaction system
JP2009282807A (ja) * 2008-05-23 2009-12-03 Fujitsu Ltd メッセージ紐付け処理装置、方法及びプログラム
JP2011138523A (ja) * 2004-05-03 2011-07-14 Visa Internatl Service Association オンライン認証を利用した情報の提供方法、そのためのサーバ、及び、コンピューティングデバイス

Family Cites Families (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4100533A (en) 1976-12-06 1978-07-11 Bell Telephone Laboratories, Incorporated Multipoint polling technique
US5283897A (en) 1990-04-30 1994-02-01 International Business Machines Corporation Semi-dynamic load balancer for periodically reassigning new transactions of a transaction type from an overload processor to an under-utilized processor based on the predicted load thereof
IL112126A0 (en) 1994-01-05 1995-03-15 Transaction Technology Inc Wireless banking system and method using cellular telephone communication
US7613659B1 (en) 1994-11-28 2009-11-03 Yt Acquisition Corporation System and method for processing tokenless biometric electronic transmissions using an electronic rule module clearinghouse
US5931961A (en) 1996-05-08 1999-08-03 Apple Computer, Inc. Discovery of acceptable packet size using ICMP echo
US6039245A (en) 1996-06-10 2000-03-21 Diebold, Incorporated Financial transaction processing system and method
US6304860B1 (en) * 1997-10-03 2001-10-16 Joseph B. Martin, Jr. Automated debt payment system and method using ATM network
WO1999021322A2 (en) 1997-10-20 1999-04-29 The Foxboro Company Method and system for fault-tolerant network connection switchover
AU6049999A (en) * 1998-09-17 2000-04-03 Nexchange Corporation Affiliate commerce system and method
US6470342B1 (en) 1999-03-12 2002-10-22 Compaq Computer Corporation Process of maintaining a distributed map of transaction identifiers and using hashing to access these maps
CA2384242A1 (en) 1999-09-24 2001-04-05 Mary Mckenney System and method for providing payment services in electronic commerce
US8271336B2 (en) 1999-11-22 2012-09-18 Accenture Global Services Gmbh Increased visibility during order management in a network-based supply chain environment
US7366695B1 (en) 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
US7756786B2 (en) 2000-03-29 2010-07-13 Mastercard International Incorporated Method and system for processing messages in a bill payment and presentment system over a communications network
US7131108B1 (en) * 2000-04-17 2006-10-31 Ncr Corporation Software development system having particular adaptability to financial payment switches
US20020138431A1 (en) * 2000-09-14 2002-09-26 Thierry Antonin System and method for providing supervision of a plurality of financial services terminals with a document driven interface
US7020713B1 (en) 2000-10-10 2006-03-28 Novell, Inc. System and method for balancing TCP/IP/workload of multi-processor system based on hash buckets
JP2002133306A (ja) 2000-10-20 2002-05-10 Canon Inc 情報処理装置、情報処理システム、情報処理方法、及び記憶媒体
US6980550B1 (en) 2001-01-16 2005-12-27 Extreme Networks, Inc Method and apparatus for server load balancing
US7444335B1 (en) * 2001-02-28 2008-10-28 Oracle International Corporation System and method for providing cooperative resource groups for high availability applications
JP2002269482A (ja) * 2001-03-14 2002-09-20 Canon Sales Co Inc 機器管理システム及びその制御方法及び記憶媒体、プログラム
US6745197B2 (en) 2001-03-19 2004-06-01 Preston Gates Ellis Llp System and method for efficiently processing messages stored in multiple message stores
JP2002319058A (ja) 2001-04-20 2002-10-31 Hitachi Ltd 国際オンライン現金自動取引システム
US7742984B2 (en) 2001-07-06 2010-06-22 Hossein Mohsenzadeh Secure authentication and payment system
US20030023877A1 (en) * 2001-07-30 2003-01-30 Michael Luther System and method of managing data transmission loads
US20030065702A1 (en) 2001-09-24 2003-04-03 Ravinder Singh Cache conscious load balancing
US20030065623A1 (en) 2001-10-01 2003-04-03 Chad Corneil Service, method and apparatus for receipt, authentication, transformation and delivery of transactions using a computer network
GB2381713A (en) 2001-11-01 2003-05-07 3Com Corp Failover mechanism involving blocking of access of a malfunctioning server and continuing monitoring to enable unblocking of access if server recovers
US20030125969A1 (en) 2001-12-28 2003-07-03 Wireless Checking, Inc. Method and apparatus for processing financial transactions over a paging network
AU2002253437A1 (en) 2002-04-12 2003-10-27 Nokia Corporation System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network
JP3737460B2 (ja) 2002-07-09 2006-01-18 株式会社東京三菱銀行 コンピュータ・システム
US7379978B2 (en) 2002-07-19 2008-05-27 Fiserv Incorporated Electronic item management and archival system and method of operating the same
CA2396666C (en) 2002-08-02 2005-03-01 Bend All Automotive Incorporated Press-formed keyway for headrest mounting tube
JP2004134879A (ja) 2002-10-08 2004-04-30 Hitachi Information Technology Co Ltd ルータ装置
US7260066B2 (en) 2002-10-31 2007-08-21 Conexant Systems, Inc. Apparatus for link failure detection on high availability Ethernet backplane
JP2004159146A (ja) 2002-11-07 2004-06-03 Nippon Telegr & Teleph Corp <Ntt> 通信ネットワーク及びパケット転送装置
US20050021836A1 (en) 2003-05-01 2005-01-27 Reed Carl J. System and method for message processing and routing
US7284147B2 (en) 2003-08-27 2007-10-16 International Business Machines Corporation Reliable fault resolution in a cluster
US20050058063A1 (en) 2003-09-15 2005-03-17 Dell Products L.P. Method and system supporting real-time fail-over of network switches
WO2005052801A1 (en) 2003-11-26 2005-06-09 Point Of Pay Pty Ltd Secure payment system
US7583661B2 (en) 2004-03-05 2009-09-01 Sid Chaudhuri Method and apparatus for improved IP networks and high-quality services
US7761375B2 (en) * 2004-03-16 2010-07-20 Hewlett-Packard Development Company, L.P. Transaction switch and a method for use thereof
AU2005251014B2 (en) 2004-06-04 2008-01-24 Nokia Solutions And Networks Gmbh & Co. Kg Dynamic and traffic-driven optimization of message routing to geographical addresses
JP2006120036A (ja) 2004-10-25 2006-05-11 Hitachi Ltd トランザクション転送システム
US20070061379A1 (en) 2005-09-09 2007-03-15 Frankie Wong Method and apparatus for sequencing transactions globally in a distributed database cluster
WO2008048304A2 (en) 2005-12-01 2008-04-24 Firestar Software, Inc. System and method for exchanging information among exchange applications
JP2007164535A (ja) 2005-12-14 2007-06-28 Nomura Research Institute Ltd 業務統合方法、業務統合装置、業務統合システムおよび業務統合プログラム
ATE442735T1 (de) 2006-01-25 2009-09-15 Ericsson Telefon Ab L M Gateway-entität
US7801846B2 (en) * 2006-04-04 2010-09-21 Computer Associates Think, Inc. Generating log sequence identifiers to apply a transaction to a storage system
US8413160B2 (en) * 2006-06-22 2013-04-02 American Express Travel Related Services Company, Inc. Systems, methods, and computer program products for transaction based load balancing
US20080071664A1 (en) 2006-09-18 2008-03-20 Reuters America, Inc. Limiting Counter-Party Risk in Multiple Party Transactions
US20080109335A1 (en) 2006-11-08 2008-05-08 Keohane Susann M Delivering electronic messages from a user's electronic message service provider to a system for facilitating financial transactions
US8804486B2 (en) 2007-03-05 2014-08-12 Alcatel Lucent Base stations routing traffic over a packet backhaul network to multiple routing elements
US20090006233A1 (en) * 2007-03-30 2009-01-01 Roland Chemtob Electronic Fund Transfers Using an Electronic Mail Interface
US7725440B2 (en) * 2007-09-26 2010-05-25 Yahoo! Inc. Restoring a database using fuzzy snapshot techniques
US8140483B2 (en) * 2007-09-28 2012-03-20 International Business Machines Corporation Transaction log management
US20090144220A1 (en) 2007-11-30 2009-06-04 Yahoo! Inc. System for storing distributed hashtables
US9338176B2 (en) * 2008-01-07 2016-05-10 Global Dataguard, Inc. Systems and methods of identity and access management
US9077684B1 (en) 2008-08-06 2015-07-07 Mcafee, Inc. System, method, and computer program product for determining whether an electronic mail message is compliant with an etiquette policy
JP4722973B2 (ja) 2008-08-12 2011-07-13 株式会社日立製作所 リクエスト処理方法及び計算機システム
JP5308148B2 (ja) 2008-12-26 2013-10-09 株式会社大和証券グループ本社 回線障害処理システムおよびプログラム
US8296624B2 (en) 2009-06-30 2012-10-23 Comcast Cable Communications, Llc Variable interleave data transmission
US8713027B2 (en) 2009-11-18 2014-04-29 Qualcomm Incorporated Methods and systems for managing electronic messages
US20110225091A1 (en) 2010-03-12 2011-09-15 Franco Plastina Methods, systems, and computer readable media for transactional fraud detection using wireless communication network mobility management information
JP2011249979A (ja) 2010-05-25 2011-12-08 Nec Corp 通信システム
WO2011147566A2 (de) 2010-05-25 2011-12-01 Paycash Labs Ag Verfahren zum erzeugen eines transaktionssignals
US8898333B1 (en) 2010-08-31 2014-11-25 Juniper Networks, Inc. Methods and apparatus related to a virtual multi-hop network topology emulated within a data center
US8751355B2 (en) * 2010-09-29 2014-06-10 Stephen Edward Rossi System and method for credit enhancing a debt issuance and creating a present value investable arbitrage
US10263888B2 (en) 2010-09-30 2019-04-16 Trading Technologies International, Inc. Sticky order routers
JP5678723B2 (ja) 2011-02-28 2015-03-04 富士通株式会社 スイッチ、情報処理装置および情報処理システム
US20120271765A1 (en) 2011-04-20 2012-10-25 Karen Cervenka Routing optimization
JP5620881B2 (ja) 2011-05-18 2014-11-05 日本電信電話株式会社 トランザクション処理システム、トランザクション処理方法、および、トランザクション処理プログラム
US8635185B2 (en) 2011-06-27 2014-01-21 Oracle International Corporation System and method for providing session affinity in a clustered database environment
US20130013516A1 (en) 2011-07-08 2013-01-10 Hamilton Andrew R Social network financial portal
US8630954B2 (en) 2011-12-15 2014-01-14 Visa International Service Association System and method of using load network to associate product or service with a consumer token
US20130339189A1 (en) * 2012-06-18 2013-12-19 Jonathan Minerick Method and apparatus for facilitating real estate transactions
US10318911B1 (en) * 2013-03-14 2019-06-11 Jpmorgan Chase Bank, N.A. Persistenceless business process management system and method
GB2533432A (en) 2014-12-18 2016-06-22 Ipco 2012 Ltd A device system, method and computer program product for processing electronic transaction requests

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002042038A (ja) * 2000-07-25 2002-02-08 Dai-Ichi Kangyo Bank Ltd 支払明細情報を提供可能な代金回収システム
US20050171811A1 (en) * 2000-09-26 2005-08-04 Bottomline Technologies (De) Inc. Electronic financial transaction system
JP2011138523A (ja) * 2004-05-03 2011-07-14 Visa Internatl Service Association オンライン認証を利用した情報の提供方法、そのためのサーバ、及び、コンピューティングデバイス
JP2009282807A (ja) * 2008-05-23 2009-12-03 Fujitsu Ltd メッセージ紐付け処理装置、方法及びプログラム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10708213B2 (en) 2014-12-18 2020-07-07 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages
US10963882B2 (en) 2014-12-18 2021-03-30 Ipco 2012 Limited System and server for receiving transaction requests
US10997568B2 (en) 2014-12-18 2021-05-04 Ipco 2012 Limited System, method and computer program product for receiving electronic messages
US10999235B2 (en) 2014-12-18 2021-05-04 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages
US11080690B2 (en) 2014-12-18 2021-08-03 Ipco 2012 Limited Device, system, method and computer program product for processing electronic transaction requests
US11521212B2 (en) 2014-12-18 2022-12-06 Ipco 2012 Limited System and server for receiving transaction requests
US11665124B2 (en) 2014-12-18 2023-05-30 Ipco 2012 Limited Interface, method and computer program product for controlling the transfer of electronic messages

Also Published As

Publication number Publication date
SA517381770B1 (ar) 2021-11-25
AU2015365764A1 (en) 2017-07-06
JP6474915B2 (ja) 2019-02-27
CA2971665C (en) 2021-10-26
SG11201704907QA (en) 2017-07-28
EP3234888A1 (en) 2017-10-25
GB2533432A (en) 2016-06-22
WO2016097672A1 (en) 2016-06-23
AU2015365764B2 (en) 2019-09-26
EA034401B1 (ru) 2020-02-04
EP4220513A1 (en) 2023-08-02
CO2017007195A2 (es) 2017-09-29
US20180174140A1 (en) 2018-06-21
EA201791339A1 (ru) 2017-12-29
CA2971665A1 (en) 2016-06-23
US11080690B2 (en) 2021-08-03

Similar Documents

Publication Publication Date Title
JP6831412B2 (ja) 電子メッセージの転送を制御するためのインターフェース、システム、方法及びコンピュータプログラム製品
JP6474915B2 (ja) 電子トランザクション要求を処理するための装置、システム、方法及びコンピュータプログラム製品
JP6450471B2 (ja) 電子メッセージを受信するためのシステム、方法及びコンピュータプログラム製品
JP6483277B2 (ja) 電子メッセージの転送を制御するためのインターフェース、方法及びコンピュータプログラム製品
US11521212B2 (en) System and server for receiving transaction requests

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180625

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180717

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181016

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181120

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181221

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190115

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190130

R150 Certificate of patent or registration of utility model

Ref document number: 6474915

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250