特許 7430174 トランザクション処理エコシステムを実施するためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-01

(45)【発行日】2024-02-09

(54)【発明の名称】トランザクション処理エコシステムを実施するためのシステムおよび方法

(51)【国際特許分類】

   G06Q 20/00 20120101AFI20240202BHJP

【ＦＩ】

G06Q20/00

【請求項の数】 15

(21)【出願番号】P 2021513964

(86)(22)【出願日】2019-09-16

(65)【公表番号】

(43)【公表日】2021-12-23

(86)【国際出願番号】 US2019051236

(87)【国際公開番号】W WO2020056396

(87)【国際公開日】2020-03-19

【審査請求日】2022-09-02

(31)【優先権主張番号】62/731,396

(32)【優先日】2018-09-14

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】519022104

【氏名又は名称】ジェイピーモルガン・チェース・バンク，ナショナル・アソシエーション

【氏名又は名称原語表記】ＪＰＭｏｒｇａｎ Ｃｈａｓｅ Ｂａｎｋ，Ｎ．Ａ．

【住所又は居所原語表記】３８３ Ｍａｄｉｓｏｎ Ａｖｅｎｕｅ，Ｎｅｗ Ｙｏｒｋ，ＮＹ １０１７９，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100162846

【弁理士】

【氏名又は名称】大牧 綾子

(72)【発明者】

【氏名】ハンドリング，クリス

(72)【発明者】

【氏名】サポナーラ，スティーブン

(72)【発明者】

【氏名】ウィン，マット

(72)【発明者】

【氏名】ウィルソン，スコット

(72)【発明者】

【氏名】テイシェラ，アン・ケイ

(72)【発明者】

【氏名】チャウハン，ロヒット・シン

(72)【発明者】

【氏名】シュネルカー，クレイトン

【審査官】深津 始

(56)【参考文献】

【文献】米国特許第０７７８３５４９（ＵＳ，Ｂ１）

【文献】特開平１１－１６１５３０（ＪＰ，Ａ）

【文献】特表２０２０－５０７８４０（ＪＰ，Ａ）

【文献】第４回バスの基礎知識，2023年08月23日，1-9ページ，Internet<URL:https://jp.fujitsu.com/family/familyroom/syuppan/family/webs/serial-comp2/pdf/comp04.pdf>

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ －Ｇ０６Ｑ ９９／００

(57)【特許請求の範囲】

【請求項1】

トランザクション処理エコシステムであって、
複数のデータソースと、
キャプチャインターフェースと、
メッセージバスコントローラ、および前記メッセージバスコントローラとインターフェースする複数のプロセッサを含む金融トランザクション処理システムであって、
前記複数のプロセッサのそれぞれの登録情報を、前記メッセージバスコントローラに登録することであって、前記登録情報は、それぞれのプロセッサのトランザクション処理能力を示し、前記複数のプロセッサは、前記複数のプロセッサのそれぞれが異なるトランザクションタイプを処理できるように異なるトランザクション処理能力を有する、登録することと、
前記キャプチャインターフェースを介して、支払トランザクションについて生データフォーマットで生データを受信することであって、前記生データはクライアントの命令を備える、受信することと、
前記生データフォーマットを前記メッセージバスコントローラに登録することであって、前記登録は、前記生データフォーマットの複数のデータフィールドのそれぞれを標準化論理データモデルフォーマットの対応するデータフィールドにマッピングすることを備える、登録することと、
正規化されたトランザクションフォーマットを提供するために、前記キャプチャインターフェースを介して、前記生データを前記生データフォーマットの登録に基づいて前記標準化論理データモデルフォーマットの標準化されたトランザクションデータに正規化することと、
前記正規化されたトランザクションフォーマットを、前記キャプチャインターフェースを介して、トランザクションとして前記複数のプロセッサとインターフェースする前記メッセージバスコントローラに送信することであって、前記複数のプロセッサのそれぞれに前記送信が通知される、送信することと、
前記複数のプロセッサによって、前記複数のプロセッサのそれぞれの前記登録情報に基づいて前記トランザクションを処理するために前記メッセージバスコントローラを監視することであって、前記トランザクションは第１のトランザクションタイプの第１のサブトランザクションと、前記第１のトランザクションタイプとは異なる第２のトランザクションタイプの第２のサブトランザクションとを含む、監視することと、
前記複数のプロセッサのうちの第１のプロセッサによって、前記複数のプロセッサのそれぞれの前記登録情報に従って、前記第１のプロセッサのトランザクション処理能力に基づいて処理するために前記第１のトランザクションタイプの前記第１のサブトランザクションを含む前記トランザクションを、前記メッセージバスコントローラからプルすることであって、前記第１のトランザクションタイプは、前記複数のプロセッサのうち前記第１のプロセッサによって処理可能であるが、前記複数のプロセッサのうちの他のプロセッサによっては処理できないトランザクションタイプに対応するプルすることと、
前記第１のプロセッサの前記トランザクション処理能力に基づいて、前記複数のプロセッサのうちの前記他のプロセッサに、処理のために引き出された前記トランザクションを通知することと、
前記複数のプロセッサのうちの前記第１のプロセッサにより、前記トランザクションの前記第１のサブトランザクションを処理することと、
前記第１のプロセッサによって処理された前記トランザクションを前記メッセージバスコントローラに戻し、まだ処理されていない前記第２のサブトランザクションを含む前記トランザクションを、前記複数のプロセッサのうちの別のプロセッサによるさらなる処理のために、前記メッセージバスコントローラに送信することと、
前記複数のプロセッサによって、前記複数のプロセッサのそれぞれの前記登録情報に基づいて、前記第１のプロセッサによって処理され、前記第２のサブトランザクションのさらなる処理を要求する前記トランザクションのために前記メッセージバスコントローラを監視することと、
前記第２のサブトランザクションの前記第２のトランザクションタイプが、前記複数のプロセッサのうち第２のプロセッサによって処理可能であるが、前記複数のプロセッサのうちの前記他のプロセッサによって処理可能でないトランザクションタイプに対応する場合に、前記メッセージバスコントローラから、前記複数のプロセッサのうちの前記第２のプロセッサによって、処理のために前記第２のサブトランザクションを含む前記トランザクションをプルすることと、
前記複数のプロセッサのうちの残りのプロセッサによってさらなる処理が要求されないように、前記第２のプロセッサが前記支払トランザクションのエンドポイントであるかどうかを決定することと、
前記第２のプロセッサが前記支払トランザクションの前記エンドポイントであるという決定に応答して、処理された標準化されたトランザクションをユーザインターフェースに送信し、前記支払トランザクションを完了することと、
を実行するように構成される、トランザクション処理エコシステム。

【請求項2】

前記生データは、論理データモデルフォーマットに正規化される、請求項１に記載のシステム。

【請求項3】

前記第１のプロセッサの登録情報は、前記第１のプロセッサが処理するトランザクションタイプの識別情報を備える、請求項１に記載のシステム。

【請求項4】

前記第１のプロセッサは、前記第１のプロセッサで処理された前記トランザクションを、前記メッセージバスコントローラに送信する、請求項１に記載のシステム。

【請求項5】

前記第１のプロセッサは、前記正規化されたトランザクションフォーマットに対して、決済アクションをさらに実行する、請求項１に記載のシステム。

【請求項6】

前記金融トランザクション処理システムは、前記処理されたトランザクションを外部システムに通信する、請求項１に記載のシステム。

【請求項7】

前記金融トランザクション処理システムは、前記処理されたトランザクションを、ユーザインターフェースに通信する、請求項１に記載のシステム。

【請求項8】

メッセージバスコントローラと、前記メッセージバスコントローラとインターフェースする複数のプロセッサとを備える金融トランザクション処理システムを備えるトランザクション処理エコシステムにおいてトランザクションを処理するための方法であって、
前記複数のプロセッサのそれぞれの登録情報を、前記メッセージバスコントローラに登録するステップであって、前記登録情報は、それぞれのプロセッサのトランザクション処理能力を示し、前記複数のプロセッサは、前記複数のプロセッサのそれぞれが異なるトランザクションタイプを処理できるように異なるトランザクション処理能力を有する、登録するステップと、
キャプチャインターフェースを介して、支払トランザクションについて生データフォーマットで生データを受信するステップであって、前記生データはクライアントの命令を備える、受信するステップと、
前記キャプチャインターフェースを介して、前記生データフォーマットを前記メッセージバスコントローラに登録するステップであって、前記登録は、前記生データフォーマットの複数のデータフィールドのそれぞれを標準化された論理データモデルフォーマットの対応するデータフィールドにマッピングすることを備える、登録するステップと、
正規化されたトランザクションフォーマットを提供するために、前記キャプチャインターフェースを介して、前記生データを前記生データフォーマットの登録に基づいて前記標準化された論理データモデルフォーマットの標準化されたトランザクションデータに正規化するステップと、
前記正規化されたトランザクションフォーマットを、前記キャプチャインターフェースを介して、トランザクションを前記複数のプロセッサとインターフェースする前記メッセージバスコントローラに送信するステップであって、前記複数のプロセッサのそれぞれに前記送信が通知される、送信するステップと、
前記複数のプロセッサによって、前記複数のプロセッサのそれぞれの前記登録情報に基づいて前記トランザクションを処理するために前記メッセージバスコントローラを監視するステップであって、前記トランザクションは第１のトランザクションタイプの第１のサブトランザクションと、前記第１のトランザクションタイプとは異なる第２のトランザクションタイプの第２のサブトランザクションとを含む、監視するステップと、
前記複数のプロセッサのうちの第１のプロセッサによって、前記複数のプロセッサのそれぞれの前記登録情報に従って、前記第１のプロセッサのトランザクション処理能力に基づいて処理するために前記第１のトランザクションタイプの前記第１のサブトランザクションを含む前記トランザクションを、前記メッセージバスコントローラからプルするステップであって、前記第１のトランザクションタイプは、前記複数のプロセッサのうち前記第１のプロセッサによって処理可能であるが、前記複数のプロセッサのうちの他のプロセッサによっては処理できないトランザクションタイプに対応する、プルするステップと、
前記第１のプロセッサの前記トランザクション処理能力に基づいて、複数のプロセッサのうちの前記他のプロセッサに、処理のために引き出された前記トランザクションを通知するステップと、
前記複数のプロセッサのうちの前記第１のプロセッサにより、前記トランザクションの前記第１のサブトランザクションを処理するステップと、
前記第１のプロセッサによって処理された前記トランザクションを前記メッセージバスコントローラに戻し、まだ処理されていない前記第２のサブトランザクションを含む前記トランザクションを、前記複数のプロセッサのうちの別のプロセッサによるさらなる処理のために、前記メッセージバスコントローラに送信するステップと、
前記複数のプロセッサによって、前記複数のプロセッサのそれぞれの前記登録情報に基づいて、前記第１のプロセッサによって処理され、前記第２のサブトランザクションのさらなる処理を要求する前記トランザクションのために前記メッセージバスコントローラを監視するステップと、
前記第２のサブトランザクションの前記第２のトランザクションタイプが、前記複数のプロセッサのうち第２のプロセッサによって処理可能であるが、前記複数のプロセッサのうちの前記他のプロセッサによって処理可能でないトランザクションタイプに対応する場合に、前記メッセージバスコントローラから、前記複数のプロセッサのうちの前記第２のプロセッサによって、処理のために前記第２のサブトランザクションを含む前記トランザクションをプルするステップと、
前記複数のプロセッサのうちの残りのプロセッサによってさらなる処理が要求されないように、前記第２のプロセッサが前記支払トランザクションのエンドポイントであるかどうかを決定するステップと、
前記第２のプロセッサが前記支払トランザクションの前記エンドポイントであるという決定に応答して、前記処理された標準化されたトランザクションをユーザインターフェースに送信し、前記支払トランザクションを完了するステップと、
を含む、方法。

【請求項9】

前記生データは、論理データモデルフォーマットに正規化される、請求項８に記載の方法。

【請求項10】

前記第１のプロセッサの前記登録情報は、前記第１のプロセッサが処理するトランザクションタイプの識別情報を備える、請求項８に記載の方法。

【請求項11】

前記第１のプロセッサにより、前記第１のプロセッサで処理された前記トランザクションを、前記メッセージバスコントローラに送信するステップ
をさらに含む、請求項８に記載の方法。

【請求項12】

前記第１のプロセッサは、前記正規化されたトランザクションフォーマットに対して、決済アクションをさらに実行する、請求項８に記載の方法。

【請求項13】

前記金融トランザクション処理システムは、前記処理されたトランザクションを外部システムに通信する、請求項８に記載の方法。

【請求項14】

前記金融トランザクション処理システムは、前記処理されたトランザクションを、ユーザインターフェースに通信する、請求項８に記載の方法。

【請求項15】

前記第１のプロセッサによる前記トランザクションの前記第１のサブトランザクションの前記処理は、前記第１のプロセッサが、前記複数のプロセッサのうちの前記他のプロセッサによる処理のために、前記トランザクションの前記第２のサブトランザクションを前記メッセージバスコントローラに送信することをトリガする、請求項１に記載のトランザクション処理エコシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願に対する相互参照
[0001]本願は、２０１８年９月１４日に出願された米国仮出願第６２／７３１，３９６号（代理人整理番号７２１６７．００１５６０）の優先権を主張し、この米国仮出願の内容は、その全体が本明細書に組み込まれる。

【0002】

[0002]本開示は、一般に、イベント駆動型アーキテクチャに基づくトランザクション処理エコシステムに関する。

【背景技術】

【0003】

[0003]現在、金融機関は、トランザクションを処理するために数千のシステムを使用している。しかしながら、多くのシステムは冗長な機能を実行し、多くの場合、高レベルの機能性を何度も複製する。これらのシステムは、標準的な会計慣行を活用したり、またはデータの観点から一貫性を提供したりする、エンドツーエンドの技術的および事業的な機能の完全なセットを提供している訳ではない。

【0004】

[0004]たとえば、金融機関のための従来の現金管理プラットフォームのブロック図を示す図１は、資格検証(entitlement verification)、予約、アーカイブなどのようないくつかの冗長なシステム構成要素を含む。そのような従来のシステムでは、製品提供は統一されておらず、リアルタイムでもなく、報告は一貫性がなく、クライアントではなく製品に特化されている。

【発明の概要】

【課題を解決するための手段】

【0005】

[0005]１つの実施形態によれば、本発明は、トランザクション処理エコシステム(transaction processing ecosystem)であって、複数のデータソースと、キャプチャインターフェースと、メッセージバス、およびメッセージバスとインターフェースする複数のプロセッサを含む金融トランザクション処理システムであって、複数のプロセッサは、キャプチャインターフェースを介して、支払トランザクションの生データを受信することであって、生データは、クライアントの命令を備える、受信することと、キャプチャインターフェースを介して、生データを、標準的なデータモデルに基づいて、正規化されたトランザクションフォーマットに正規化することと、正規化されたトランザクションフォーマットを、キャプチャインターフェースを介して、メッセージバスに発行することと、正規化されたトランザクションフォーマットを、複数のプロセッサのうちの第１のプロセッサを介して処理することと、トランザクションを完了することとを実行するように構成される、金融トランザクション処理システムとを備えるトランザクション処理エコシステムに関する。

【0006】

[0006]１つの実施形態によれば、本発明は、メッセージバスと、メッセージバスとインターフェースする複数のプロセッサとを含む金融トランザクション処理システムを備えるトランザクション処理エコシステムにおいてトランザクションを処理するための方法に関する。この方法は、キャプチャインターフェースを介して、支払トランザクションの生データを受信するステップであって、生データは、クライアントの命令を備える、受信するステップと、キャプチャインターフェースを介して、生データを、標準的なデータモデルに基づいて、正規化されたトランザクションフォーマットに正規化するステップと、正規化されたトランザクションフォーマットを、キャプチャインターフェースを介して、メッセージバスに発行するステップと、正規化されたトランザクションフォーマットを、複数のプロセッサのうちの第１のプロセッサを介して処理するステップと、トランザクションを完了するステップを含む。

【0007】

[0007]本明細書に記載のコンピュータ実施システムおよび方法は、本発明の様々な実施形態にしたがって、エンティティ、組織、および他のユーザに、固有の利点を提供する。本発明の一実施形態は、様々な機能が、イベント駆動型アーキテクチャを介してともに結合された、フルスタックのエンドツーエンドのトランザクション処理を提供する金融トランザクション処理システムに関する。本発明の一実施形態は、標準化されたデータモデルに基づいて、統合された機能ベースのアーキテクチャを介して、様々な処理構成要素を、単一のプラットフォームに統合する。本発明の一実施形態は、金融トランザクションを処理する隔離されたシステム全体にわたって、重複する機能および特徴を排除することによって効率化を達成する。革新的なシステムおよび方法は、再利用性、（ボリューム制約に対処するための）最大のスケーラビリティ、向上した安定性（グローバルに一貫したプラットフォーム）、ほぼリアルタイムのデータ、（予約原則による）向上した規制管理および報告、リソース効率化、および大幅なコスト削減を提供する。これらおよび他の利点は、以下の詳細な説明でより完全に説明される。

【0008】

[0008]本発明のより完全な理解を容易にするために、ここで、添付の図面が参照される。図面は、本発明を限定するものとして解釈されるべきではなく、本発明の異なる態様および実施形態を説明することのみ意図される。

【図面の簡単な説明】

【0009】

【図1】[0009]図１は、従来の現金管理プラットフォームの状況を示す図である。

【図2】[0010]図２は、本発明の一実施形態による、金融トランザクションエコシステムを示す図である。

【図3】[0011]図３は、本発明の一実施形態による、トランザクション処理システムを含む例示的な現金管理システムを示す図である。

【図4】[0012]図４は、本発明の一実施形態による、例示的な資産記録システムを示す図である。

【図5】[0013]図５は、本発明の一実施形態による、金融トランザクションエコシステムのアーキテクチャ図である。

【図6】[0014]図６は、本発明の一実施形態による、金融トランザクション処理エコシステムにおけるトランザクション処理のための方法を示す図である。

【図7A】[0015]図７Ａは、本発明の一実施形態による、支払受領／支払キャッシュフローの例示的な例を示す図である。

【図7B】図７Ｂは、本発明の一実施形態による、支払受領／支払キャッシュフローの例示的な例を示す図である。

【発明を実施するための形態】

【0010】

[0016]以下の説明は、特定の実施形態および詳細を提供することによって、本発明の理解を伝えることが意図される。しかしながら、本発明は、これらの特定の実施形態および詳細に限定されず、これらは単に例示的であると理解される。知られているシステムおよび方法に照らして、当業者は、特定の設計および他の必要性に応じて、任意の数の代替実施形態におけるその意図された目的および利益のために、本発明の使用を評価するであろうことがさらに理解される。

【0011】

[0017]２０１８年５月３０日に出願された米国仮特許出願第６２／６７７，８８２号（代理人整理番号７２１６７．００１４３８）の開示は、参照によりその全体が本明細書に組み込まれる。

【0012】

[0018]本発明の一実施形態は、金融トランザクションエコシステムに関する。本発明の一実施形態によれば、金融トランザクションエコシステムは、標準的な会計原則に基づくことができ、データキャプチャ、トランザクション予約、資産移動、資産ジャーナル／保有高(asset journal/holding)などの多くの機能を含み得るエンドツーエンドのトランザクション処理を提供し得る。これらの機能は、１つまたは複数の標準的なデータモデルに基づき得るイベント駆動型アーキテクチャを介して結合され得る。

【0013】

[0019]図２は、本発明の一実施形態による、金融トランザクションエコシステムを示す。図２に示されるように、予約エンジン２１０、資産移動エンジン２２０、および資産記録エンジン２３０は、互いに通信し得る。例示的な例示は、複数の予約エンジン、単一の資産移動エンジン、および単一の資産記録エンジンを含み得る。他のバリエーションが実現され得る。

【0014】

[0020]たとえば、予約エンジン２１０は、トランザクション、再調整(realignment)、外国為替などを予約し得る。これらのイベントは、保留中のジャーナルおよびポジションの設定および／または作成をトリガし得る。

【0015】

[0021]資産移動エンジン２２０は、保留中のポジションの、決済および／または確認済みのポジションへの削除／移動をトリガするイベントを生成および／または監視し得る。
[0022]資産記録エンジン２３０は、ジャーナルおよび保有高を作成および／または生成し得る。

【0016】

[0023]完全性を確保し、標準的な原則にしたがうことにより、コアデータは正確で、タイムリーであり、リンクされ得る。したがって、本発明の一実施形態は、スケーラビリティ、大幅に削減された調整ブレーキ、および完全なイベントベースのアーキテクチャを提供する。

【0017】

[0024]図３は、本発明の一実施形態による、金融トランザクションエコシステムの例示的なブロック図を示す。エコシステム３００は、金融トランザクション処理システム３１０を含み得、これは、トランザクションを実施、記録、および／または、そうでなければ関与するために使用され得るいくつかの処理構成要素をさらに含み得る。たとえば、金融トランザクション処理システム３１０は、資格モジュール３１２、移動モジュール３１４、予約モジュール３１６、保有高モジュール３１８、参照データ３２０、通知モジュール３２２、データストレージモジュール３２４、および報告モジュール３２６を含み得る。これらのモジュールを含めることは単なる例示であり、必要な場合、および／または、所望される場合、より少ない、異なる、または追加のモジュールが提供され得ることが認識されるべきである。

【0018】

[0025]本発明の一実施形態によれば、モジュール（たとえば、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６など）のうちの１つまたは複数は、エコシステム３００によって着手され得る複数のトランザクションタイプに関連し得る。したがって、すべてのモジュールが、すべてのトランザクションに関与する訳ではない。たとえば、トランザクションが、モジュールを必要としない場合、メッセージバス３３０を監視している間、モジュールはアイドル状態のままであり得る。本発明の様々な実施形態の文脈において、モジュールは、プロセッサ、処理構成要素、ハードウェア構成要素上のソフトウェア実施、および／または他の実施を表し得る。

【0019】

[0026]システム３００は、いくつかのモジュールを単一のプラットフォームに統合し得、それにより、従来の垂直サイロ(vertical silo)から、統合された機能ベースのアーキテクチャに移動できる。技術的な利点は、たとえば、共通の構成要素およびコードベースを活用することによる技術的コストおよび運用コストの削減と、統合された製品の提供（たとえば、統合された売掛金、統合された買掛金など）と、標準化されたデータモデルを備えた最新のイベントベースのアーキテクチャと、リアルタイムまたはほぼリアルタイムのデータの使用と、（予約原則を介した）より厳格な規制管理および報告と、向上した安定性およびスケーラビリティとを含み得る。

【0020】

[0027]各モジュール（たとえば、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６など）は、メッセージバス３３０と通信し得る。たとえば、イベントは、メッセージバス３３０に書き込まれ得、各モジュールは、行うべきアクションを求めてメッセージバスを監視し得る。アクションが行われると、別のモジュールがアクションを行い得る。

【0021】

[0028]本発明の一実施形態によれば、モジュール（たとえば、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６など）は、独立していてもよく（たとえば、依存関係を除いて、互いに独立して動作し）、標準的なデータモジュールを活用して、メッセージバス２３０とインターフェースし得る。各モジュール（たとえば、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６など）は、独自のデータストアおよびメモリを有し得、様々な処理を実行し得る。

【0022】

[0029]本発明の一実施形態によれば、ユーザインターフェース３４０は、ユーザが、金融トランザクション処理システム３１０とインタラクトすることを可能にし得る。例示的なユーザインターフェース３４０は、たとえば、支払ファイルを送信する外部クライアントと、請求書をアップロードする外部クライアントと、有価証券処理のためのトランザクションを送信する内部または外部システムとを含み得る。

【0023】

[0030]本発明の一実施形態によれば、ストレージ３５０が提供され得る。ストレージ３５０は、たとえば、キャッシュストレージ（たとえば、Ｇｅｍｆｉｒｅ、Ｈａｚｅｌｃａｓｔなど）、インメモリデータストア、キャッシュを備えた永続ストレージなどを含み得る。たとえば、システム３００は、バス上のすべてのトランザクションを、長期のデータストアに永続化し得る。

【0024】

[0031]図４は、本発明の一実施形態による、例示的な資産記録システムを示す。図４に示されるように、例示的な現金管理システムは、トランザクション処理システムを含み得る。システム４００は、たとえば、買掛金４４０（チェックサービス４４２、デジタル買掛金４４４を含む）、売掛金４５０（売掛金管理４５２を含む）、預金４６０（現金残高管理４６２を含む）などのシステムから、生データをキャプチャし得るキャプチャモジュール４３０を含み得る。キャプチャモジュール４３０は、これらおよび他のシステムから任意のフォーマットで生データをキャプチャし得、生データを、正規化されたフォーマット（たとえば、以下で論じる論理データモデルフォーマット）に変換し得る。

【0025】

[0032]本発明の一実施形態によれば、エスクロー(escrow)管理４７２を含むエスクローシステム４７０からの生データは、金融トランザクション処理システム３１０によって受信され得る。

【0026】

[0033]金融トランザクション処理システム３１０は、予約モジュール３１６、移動モジュール３１４、保有高モジュール３１８、通知モジュール３２２、メッセージングモジュール３２３、参照データ３２０、データストレージモジュール３２４、および報告モジュール３２６などのモジュールを含み得る。必要な場合、および／または、所望される場合、他のモジュールが提供され得る。各モジュールは、処理する可能性のあるトランザクションタイプをメッセージバス３３０に登録し得る。

【0027】

[0034]ユーティリティ４８０は、金融トランザクション処理システム３１０とインタラクト(interact)し得る。ユーティリティ４８０は、たとえば、価格設定４８２、制裁(sanction)４８４、勘定４８６、およびステートメント４８８などのモジュールを含み得る。たとえば、ユーティリティ４８０は、パラメータが任意の構成要素によって提供され得るので、複数の機能エンジン（たとえば、入力）によって使用され得る一般的なサービスを提供し得る。この例では、出力は、回答または出力データを含めることができ、その後、さらなる処理のために使用され得る。

【0028】

[0035]クライアントツール４９０は、クライアントサービス４９２およびクライアント向けツール４９４を含み得る。たとえば、クライアントツールは、報告、監査などのためのユーザインターフェースを提供し得る。たとえば、クライアントツール４９０は、クライアントが、以前のトランザクションを照会し、トランザクションを開始することなどを可能にし得る。

【0029】

[0036]図５は、本発明の一実施形態による、金融トランザクションエコシステムのアーキテクチャ図を示す。図５は、例示的な資産記録システムを示す。たとえば、システム５００は、情報（たとえば、ジャーナル情報、キャッシング情報など）をキャッシュし得るデータキャッシングモジュール５３０を含み得る。

【0030】

[0037]本発明の一実施形態によれば、システム５００は、メッセージバス３３０とインタラクトし得る複数のモジュール（たとえば、モジュール５２０、モジュール５２２、およびモジュール５２４など）をさらに含み得る。３つのモジュールが示されているが、必要な場合、および／または、所望される場合、より多い、または、より少ない数が提供され得る。

【0031】

[0038]本発明の一実施形態によれば、モジュールは、新しいＬＤＭオブジェクトを作成し、それらをメッセージバスに発行し戻すこともできる、メッセージバスのコンシューマを表し得る。

【0032】

[0039]モジュール５２０、５２２、および５２４は、たとえば、資産移動モジュール、取引予約モジュール、ジャーナルモジュール、集約モジュール、ラダーモジュール、回復モジュール(reinstatement module)などを含み得る。必要な場合、および／または、所望される場合、他のモジュールが提供され得る。

【0033】

[0040]システム５００はまた、複数のライタ(writer)５４０、５４２、および５４４を含み得る。３つのライタが描かれているが、必要な場合、および／または、所望される場合、より多い、または、より少ない数が提供され得る。ライタ４４０、４４２、４４４は、たとえば、ジャーナルライタ、保有高ライタなどを含み得る。

【0034】

[0041]本発明の一実施形態によれば、メッセージバス上のオブジェクトの表示を可能にするユーザインターフェースが提供され得る。要求／応答により、コンシューマは、バスに既に発行され、データベースに格納されている保有高（ポジション）ルックアップ(look up)を求める呼出しを行うことができる。たとえば、要求／応答は、情報を望んでいるコンシューマが、バス上で発行されているすべてのポジションをリッスン(listen)するのではなく、アドホックコールを発信できるようにするための便利な特徴を表し得る。

【0035】

[0042]システム５００は、トランザクション、資産などの記録を維持し得る資産記録データベース５５０をさらに含み得る。本発明の一実施形態によれば、資産記録データベース５５０は、要求／応答呼出しにサービスを提供するだけでなく、回復目的でリアルタイムキャッシュをロードする目的で永続的なストアとして使用され得る。本発明の一実施形態によれば、リアルタイムキャッシュは、ダウンタイムまたはメンテナンス後に、資産記録データベースに基づいて再入力され得る。

【0036】

[0043]図６は、本発明の一実施形態による、金融トランザクション処理エコシステムにおけるトランザクション処理のための方法を示す。ステップ６１０において、生データがキャプチャされ得る。ステップ６１５において、生データが正規化され得る。ステップ６２０において、正規化されたトランザクションが、メッセージバスに発行され得る。ステップ６２５において、トランザクション処理エコシステムにおけるモジュールおよび／または機能は、メッセージバスを監視またはリッスンし得る。ステップ６３０において、トランザクションが処理され得る。ステップ６３５において、トランザクション処理が完了および／または別のシステムに転送され得る。図６の処理は、特定の順序で実行される特定のステップを示しているが、本発明の実施形態は、処理に１つまたは複数のステップを追加し、処理内のステップを省略し、および／または、１つまたは複数のステップが実行される順序を変更することによって実践され得ることを理解されたい。各ステップの追加の詳細が以下に提供される。

【0037】

[0044]ステップ６１０において、生データは、たとえば、キャプチャ機能を使用してキャプチャされ、処理エコシステムにもたらされ得る。生データの例は、個別のトランザクション、ファイルなど、またはこれらのバッチを含み得る。たとえば、生データは、ユーザインターフェースおよび／またはシステムから受信され得る。それに加えて、生データは、様々なフォーマットで受信され得る。

【0038】

[0045]ステップ６１５において、生データが正規化され得る。これは、生データを、正規化された変換フォーマットに変換することを含み得る。本発明の一実施形態によれば、構成ファイル（または「コンフィグ」ファイル）は、登録された生データフォーマットの、ＬＤＭ（論理データモデル）フォーマットなどの標準的なフォーマットへのマッピングを格納し得る。

【0039】

[0046]たとえば、生データは、１つまたは複数の処理を介して実行されて、生データを、メッセージバスに発行され得る標準化された、または正規化されたトランザクションに変換し得る。本発明の一実施形態によれば、トランザクションは、承認されたＬＤＭ（論理データモデル）フォーマットであり得る。たとえば、各生データフォーマットは、登録処理中に登録され得、生データフォーマットのデータフィールドは、ＬＤＭフォーマットの適切なフィールドにマッピングされ得る。

【0040】

[0047]本発明の一実施形態によれば、構成ファイルは、トランザクションの処理に関与するモジュールをさらに識別し得る。たとえば、ＬＤＭは、ｐｒｏｔｏｂｕｆ、ＪＳＯＮ、ＸＭＬなどの任意の適切なフォーマットに変換され得る。

【0041】

[0048]ＬＤＭフォーマットでの現金トランザクションの例示的な例が、以下に提供される。
ｃａｓｈＴｒａｎｓａｃｔｉｏｎ｛
ｔｒａｎｓａｃｔｉｏｎ｛
ｔｒａｎｓａｃｔｉｏｎＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＤｅｌｉｖｅｒｉｎｇＣｏｍｐｏｎｅｎｔＩｄ”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：２
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｏｒｉｇｉｎａｔｉｎｇＳｏｕｒｃｅＳｙｓｔｅｍＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ｏｒｉｇｉｎａｔｉｎｇＳｙｓｔｅｍＩｄ”
ｖｅｒｓｉｏｎ：２
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｏｒｉｇｉｎａｔｉｎｇＳｏｕｒｃｅＳｙｓｔｅｍＥｎｔｒｙＤａｔｅｔｉｍｅ：１０００００００００００
ｏｒｉｇｉｎａｔｉｎｇＳｏｕｒｃｅＳｙｓｔｅｍＩｎｓｔａｎｃｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ｏｒｉｇｉｎａｔｉｎｇＳｙｓｔｅｍＩｎｓｔａｎｃｅＩｄ”
ｖｅｒｓｉｏｎ：２
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｔｒａｎｓａｃｔｉｏｎＮａｒｒａｔｉｖｅ｛
ｎａｒｒａｔｉｖｅＴｙｐｅＮａｍｅ：ＩＮＴＥＲＮＡＬ
ｎａｒｒａｔｉｖｅＴｅｘｔ：“Ｔｒａｎｓａｃｔｉｏｎ Ｎｏｔｅｓ ａｓ Ｎａｒｒａｔｉｖｅ”
｝
ｔｒａｎｓａｃｔｉｏｎＳｔａｔｅＮａｍｅ：ＮＥＷ
ｔｒａｎｓａｃｔｉｏｎＥｆｆｅｃｔｉｖｅＤａｔｅ：２０１８０３０３
ｔｒａｎｓａｃｔｉｏｎＴｙｐｅＮａｍｅ：ＣＡＳＨ＿ＴＲＡＮＳＡＣＴＩＯＮ
ｔｒａｎｓａｃｔｉｏｎＢｕｓｉｎｅｓｓＥｖｅｎｔ｛
ｅｖｅｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ｅｖｎｔ－ｉｄ１２３”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｅｖｅｎｔＴｙｐｅＮａｍｅ：ＣＡＳＨ＿ＤＩＶＩＤＥＮＤ
ｅｖｅｎｔＴｉｍｅｓｔａｍｐ：１０００００００００００
｝
ｄｅｌｉｖｅｒｉｎｇＳｙｓｔｅｍＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＤｅｌｉｖｅｒｉｎｇＳｙｓｔｅｍＩｄｅｎｔｉｆｉｅｒ”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
ｆｉｒｍＲｏｏｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ｆｉｒｍＲｏｏｔＩｄ”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：２
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ａｌｔｅｒｎａｔｅＴｒａｎｓａｃｔｉｏｎＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ａｌｔｅｒｎａｔｅＴｘｎＩｄ”
ｖｅｒｓｉｏｎ：２
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｅｐｏｒｔｅｄＢｕｓｉｎｅｓｓＤａｔｅ：２０１８０３０３
ｌｏｇｉｃａｌＢｕｓｉｎｅｓｓＤａｔｅ：２０１８０３０３
ｔｒａｎｓａｃｔｉｏｎＴｉｍｅｓｔａｍｐ：１０００００００００００
ｔｒａｎｓａｃｔｉｏｎＰｕｒｐｏｓｅＴｙｐｅＮａｍｅ：ＳＥＥＤＩＮＧ＿ＴＲＡＮＳＡＣＴＩＯＮ
ｏｗｎｅｒＰａｒｔｙＡｃｃｏｕｎｔ｛
ｒｏｌｅ：ＣＬＩＥＮＴ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ｏｗｎｅｒ ａｃｃ １２３”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｌｅｇａｌＥｎｔｉｔｙ｛
ｐａｒｔｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＰａｒｔｙＩＤ１２３”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｏｌｅ：ＣＯＵＮＴＥＲＰＡＲＴＹ
｝
｝
ｃｏｕｎｔｅｒｐａｒｔｙＡｃｃｏｕｎｔ｛
ｒｏｌｅ：ＣＬＩＥＮＴ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ｏｗｎｅｒ ａｃｃ １２３”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
ｔｈｉｒｄＰａｒｔｙＡｃｃｏｕｎｔ｛
ｒｏｌｅ：ＣＬＩＥＮＴ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ｏｗｎｅｒ ａｃｃ １２３”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
ｐａｒｔｙ｛
ｐａｒｔｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＰａｒｔｙＩＤ１２３”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｏｌｅ：ＣＯＵＮＴＥＲＰＡＲＴＹ
｝
ｏｒｉｇｉｎａｌＣｕｒｒｅｎｃｙＭｏｎｅｙ｛
ｍｏｎｅｙＲｏｌｅＮａｍｅ：ＦＩＲＳＴ
ｍｏｎｅｙＡｍｏｕｎｔ：１００．０
ｃｕｒｒｅｎｃｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＵＳＤ”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｆｉｇｕｒａｔｉｏｎＴｙｐｅＮａｍｅ：ＮＯＴ＿ＦＩＧＵＲＥＤ
ｖａｌｕｅＢａｓｅｄＵｐｏｎＮａｍｅ：ＢＲＯＫＥＲ＿ＦＥＥ
ｖａｌｕｅＤｅｔｅｒｍｉｎｅｄＢｙＮａｍｅ：ＡＭＯＵＮＴ
ｒａｔｅ：１００．０
ｐｅｒｃｅｎｔａｇｅ：１０．４３
ｏｒｉｇｉｎａｌＴｏＳｅｔｔｌｅｄＣｕｒｒｅｎｃｙＦｘＲａｔｅ：１．６
ｍｕｌｔｉｐｌｙＤｉｖｉｄｅＣｏｄｅ：ＭＵＬＴＩＰＬＹ
｝
ｏｒｉｇｉｎａｌＣｕｒｒｅｎｃｙＭｏｎｅｙ｛
ｍｏｎｅｙＲｏｌｅＮａｍｅ：ＦＩＮＡＬ
ｍｏｎｅｙＡｍｏｕｎｔ：１１０．０
ｃｕｒｒｅｎｃｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＵＳＤ”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｆｉｇｕｒａｔｉｏｎＴｙｐｅＮａｍｅ：ＡＤＤＥＤ
ｏｒｉｇｉｎａｌＴｏＳｅｔｔｌｅｄＣｕｒｒｅｎｃｙＦｘＲａｔｅ：１．６
ｍｕｌｔｉｐｌｙＤｉｖｉｄｅＣｏｄｅ：ＭＵＬＴＩＰＬＹ
｝
ｓｅｔｔｌｅｄＣｕｒｒｅｎｃｙＭｏｎｅｙ｛
ｍｏｎｅｙＲｏｌｅＮａｍｅ：ＦＩＲＳＴ
ｍｏｎｅｙＡｍｏｕｎｔ：１６０．０
ｃｕｒｒｅｎｃｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＵＳＤ”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｆｉｇｕｒａｔｉｏｎＴｙｐｅＮａｍｅ：ＮＯＴ＿ＦＩＧＵＲＥＤ
｝
ｓｅｔｔｌｅｄＣｕｒｒｅｎｃｙＭｏｎｅｙ｛
ｍｏｎｅｙＲｏｌｅＮａｍｅ：ＦＩＮＡＬ
ｍｏｎｅｙＡｍｏｕｎｔ：１６６．０
ｃｕｒｒｅｎｃｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＵＳＤ”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｆｉｇｕｒａｔｉｏｎＴｙｐｅＮａｍｅ：ＳＵＢＴＲＡＣＴＥＤ
｝
ｃｕｒｒｅｎｃｙＤｉｒｅｃｔｉｖｅ｛
ｄｉｒｅｃｔｉｖｅＰｕｒｐｏｓｅ：ＳＥＴＴＬＥＭＥＮＴ
ｄｉｒｅｃｔｉｖｅＴｙｐｅ：ＤＥＬＩＶＥＲＹ＿ＭＥＴＨＯＤ
ｖａｌｕｅ：ＰＡＹ＿ＣＡＳＨ
｝
ｃｕｒｒｅｎｃｙＤｉｒｅｃｔｉｖｅ｛
ｄｉｒｅｃｔｉｖｅＰｕｒｐｏｓｅ：ＳＥＴＴＬＥＭＥＮＴ
ｄｉｒｅｃｔｉｖｅＴｙｐｅ：ＳＵＰＰＲＥＳＳ＿ＩＮＳＴＲＵＣＴＩＯＮ
ｖａｌｕｅ：ＳＵＰＰＲＥＳＳ＿ＣＡＳＨ＿ＩＮＳＴＲＵＣＴＩＯＮ
｝
ｄｉｒｅｃｔｉｏｎＴｙｐｅＮａｍｅ：ＰＡＹ
ｓｕｂＴｒａｎｓａｃｔｉｏｎ｛
ｍｏｎｅｙＲｏｌｅＮａｍｅ：ＦＩＲＳＴ
ｍｏｎｅｙＡｍｏｕｎｔ：１０００．０
ｃｕｒｒｅｎｃｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ＵＳＤ”
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｓｕｂＴｒａｎｓａｃｔｉｏｎＡｃｃｏｕｎｔ｛
ｒｏｌｅ：ＣＬＩＥＮＴ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ａｃｃ－ｉｄ１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
ｓｕｂＴｒａｎｓａｃｔｉｏｎＡｃｃｏｕｎｔ｛
ｒｏｌｅ：ＮＯＳＴＲＯ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＩＤＥＮＴＩＦＩＥＲ＿ＤＯＭＡＩＮ＿ＮＯＴ＿ＳＥＴ
ｖａｌｕｅ：“ａｃｃ－ｉｄ２”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
｝
｝
ｐａｙｍｅｎｔＤａｔｅ：２０１８０５３０
[0049]ＬＤＭフォーマットでの支払トランザクションの例示的な例が以下に提供される。
ｆｉｒｍＲｏｏｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ＦｉｒｍＲｏｏｔＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｐａｙｍｅｎｔＣａｐｔｕｒｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ＰａｙｍｅｎｔＣａｐｔｕｒｅＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｐａｙｍｅｎｔＳｔａｔｅ：ＯＰＥＮ
ｐａｙｍｅｎｔＲｅｑｕｅｓｔＣｒｅａｔｉｏｎＤａｔｅＴｉｍｅ：１４０００００００００００
ｒｅｑｕｅｓｔｅｄＶａｌｕｅＤａｔｅ：２０１８０３０１
ｐａｙｍｅｎｔＭｅｔｈｏｄＴｙｐｅ：ＣＨＥＱＵＥ
ａｌｔｅｒｎａｔｅＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ａｌｔｅｒｎａｔｅＳｏｕｒｃｅＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ａｌｔｅｒｎａｔｅＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ａｌｔｅｒｎａｔｅＳｏｕｒｃｅＩｄ－２”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｂｕｓｉｎｅｓｓＥｖｅｎｔ｛
ｂｕｓｉｎｅｓｓＥｖｅｎｔ｛
ｅｖｅｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｐａｙｍｅｎｔＢｕｓｉｎｅｓｓＥｖｅｎｔＩｄ－１”
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｅｖｅｎｔＤａｔｅＴｉｍｅ：１４０００００００００００
ｒｅｌａｔｅｄＥｖｅｎｔＴｙｐｅＮａｍｅ：“”
｝
ｂｕｓｉｎｅｓｓＥｖｅｎｔＴｙｐｅＮａｍｅ：ＰＡＹＭＥＮＴ＿ＩＮＩＴＩＡＴＩＯＮ
｝
ｐａｙｍｅｎｔＲｅｆｅｒｅｎｃｅ｛
ｐａｙｍｅｎｔＲｅｆｅｒｅｎｃｅＴｙｐｅ：ＣＨＥＱＵＥ＿ＮＵＭＢＥＲ
ｐａｙｍｅｎｔＲｅｆｅｒｅｎｃｅＶａｌｕｅ：“Ｔｅｓｔ ＰａｙｍｅｎｔＲｅｆｅｒｅｎｃｅＶａｌｕｅ”
｝
ｐａｙｍｅｎｔＤａｔｅＰｕｒｐｏｓｅ｛
ｄａｔｅＰｕｒｐｏｓｅＮａｍｅ：ＩＳＳＵＥ＿ＤＡＴＥ
ｐａｙｍｅｎｔＤａｔｅ：２０１８０３０２
｝
ｒｅｍｉｔｔａｎｃｅＡｄｖｉｃｅｓ｛
ｆｉｒｍＲｏｏｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ＦｉｒｍＲｏｏｔＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｅｍｉｔｔａｎｃｅＣａｐｔｕｒｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｒｅｍｉｔｔａｎｃｅＣａｐｔｕｒｅＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
ｒｅｍｉｔｔａｎｃｅＡｄｖｉｃｅｓ｛
ｆｉｒｍＲｏｏｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ＦｉｒｍＲｏｏｔＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｅｍｉｔｔａｎｃｅＣａｐｔｕｒｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｒｅｍｉｔｔａｎｃｅＣａｐｔｕｒｅＩｄ－２”
ｖｅｒｓｉｏｎ：２
ｒｅｖｉｓｉｏｎ：２
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
ｐａｙｍｅｎｔＭａｔｃｈｅｄＡｍｏｕｎｔ｛
ｍａｔｃｈｅｄＡｍｏｕｎｔ｛
ｖａｌｕｅ：“＼００６＼２１７”
ｓｃａｌｅ：２
｝
ｃｕｒｒｅｎｃｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ＵＳＤ”
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｍｏｎｅｙＲｏｌｅ：ＦＩＮＡＬ
ｂａｌａｎｃｅＳｔａｔｕｓ：ＮＯＴ＿ＢＡＬＡＮＣＥＤ
｝
ｄｉｒｅｃｔｉｖｅｓ｛
ｄｉｒｅｃｔｉｖｅＰｕｒｐｏｓｅ：ＳＥＴＴＬＥＭＥＮＴ
ｄｉｒｅｃｔｉｖｅＴｅｘｔ：ＳＥＴＴＬＥ＿ＩＭＭＥＤＩＡＴＥ＿ＣＡＳＨ＿ＩＮＳＴＲＵＣＴＩＯＮ
ｄｉｒｅｃｔｉｖｅＴｙｐｅＮａｍｅ：ＤＥＬＩＶＥＲＹ＿ＭＥＴＨＯＤ
｝
ｃａｓｈａｓｐｅｃｔ｛
ｏｒｉｇｉｎａｌＭｏｎｉｅｓ｛
ｃｕｒｒｅｎｃｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ＵＳＤ”
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｍｏｎｅｙＡｍｏｕｎｔ：１０４８．７５
ｍｏｎｅｙＲｏｌｅＮａｍｅ：ＦＩＮＡＬ
｝
｝
ｃｏｕｎｔｅｒＰａｒｔｙＡｃｃｏｕｎｔ｛
ｒｏｌｅ：ＣＬＩＥＮＴ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｃｏｕｎｔｅｒＰａｒｔｙＡｃｃｏｕｎｔＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｌｅｇａｌＥｎｔｉｔｙ｛
ｐａｒｔｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｃｏｕｎｔｅｒＰａｒｔｙＴｒａｎｓａｃｔｉｏｎＰａｒｔｙＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｏｌｅ：ＣＬＩＥＮＴ
｝
ｈｏｌｄｉｎｇＴｙｐｅｓ｛
ｔｒａｎｓａｃｔｉｏｎＰｕｒｐｏｓｅ：ＢＯＲＲＯＷＥＤ
ｈｏｌｄｉｎｇＬｏｃａｔｉｏｎＴｙｐｅ：ＳＴＡＮＤＡＲＤ
ｔｒａｄｅＰａｙｍｅｎｔＴｙｐｅ：ＦＵＬＬＹ＿ＰＡＩＤ
ｂｌｏｃｋｅｄＦｒｏｍＰｒｏｃｅｓｓｉｎｇＴｙｐｅ：ＤＥＬＩＶＥＲＹ＿ＢＹ＿ＭＡＲＫＥＴ
ｐｈｙｓｉｃａｌＩｎｓｔｒｕｍｅｎｔＮｅｇｏｔｉａｂｌｅＦｏｒｍ：ＮＯＮ＿ＮＥＧＯＴＩＡＢＬＥ
｝
｝
ｏｗｎｅｒｐａｒｔｙａｃｃｏｕｎｔ｛
ｒｏｌｅ：ＰＡＹＥＲ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｏｗｎｅｒＰａｒｔｙＡｃｃｏｕｎｔＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｌｅｇａｌＥｎｔｉｔｙ｛
ｐａｒｔｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｏｗｎｅｒＰａｒｔｙＴｒａｎｓａｃｔｉｏｎＰａｒｔｙＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｏｌｅ：ＰＡＹＥＲ
｝
ｈｏｌｄｉｎｇＴｙｐｅｓ｛
ｔｒａｎｓａｃｔｉｏｎＰｕｒｐｏｓｅ：ＢＯＲＲＯＷＥＤ
ｈｏｌｄｉｎｇＬｏｃａｔｉｏｎＴｙｐｅ：ＳＴＡＮＤＡＲＤ
ｔｒａｄｅＰａｙｍｅｎｔＴｙｐｅ：ＦＵＬＬＹ＿ＰＡＩＤ
ｂｌｏｃｋｅｄＦｒｏｍＰｒｏｃｅｓｓｉｎｇＴｙｐｅ：ＤＥＬＩＶＥＲＹ＿ＢＹ＿ＭＡＲＫＥＴ
ｐｈｙｓｉｃａｌＩｎｓｔｒｕｍｅｎｔＮｅｇｏｔｉａｂｌｅＦｏｒｍ：ＮＯＮ＿ＮＥＧＯＴＩＡＢＬＥ
｝
｝
ｔｈｉｒｄｐａｒｔｙａｃｃｏｕｎｔｓ｛
ｒｏｌｅ：ＢＥＮＥＦＩＣＩＡＲＹ＿ＣＵＳＴＯＭＥＲ
ａｃｃｏｕｎｔＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｔｈｉｒｄＰａｒｔｙＡｃｃｏｕｎｔＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｌｅｇａｌＥｎｔｉｔｙ｛
ｐａｒｔｙＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｔｈｉｒｄＰａｒｔｙＴｒａｎｓａｃｔｉｏｎＰａｒｔｙＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ｒｏｌｅ：ＢＲＡＮＣＨ
｝
ｈｏｌｄｉｎｇＴｙｐｅｓ｛
ｔｒａｎｓａｃｔｉｏｎＰｕｒｐｏｓｅ：ＢＯＲＲＯＷＥＤ
ｈｏｌｄｉｎｇＬｏｃａｔｉｏｎＴｙｐｅ：ＳＴＡＮＤＡＲＤ
ｔｒａｄｅＰａｙｍｅｎｔＴｙｐｅ：ＦＵＬＬＹ＿ＰＡＩＤ
ｂｌｏｃｋｅｄＦｒｏｍＰｒｏｃｅｓｓｉｎｇＴｙｐｅ：ＤＥＬＩＶＥＲＹ＿ＢＹ＿ＭＡＲＫＥＴ
ｐｈｙｓｉｃａｌＩｎｓｔｒｕｍｅｎｔＮｅｇｏｔｉａｂｌｅＦｏｒｍ：ＮＯＮ＿ＮＥＧＯＴＩＡＢＬＥ
｝
｝
ｌｏｇｉｃａｌＢｕｓｉｎｅｓｓＤａｔｅ：２０１８０３０２
ｐｒｅＳｅｔｔｌｅｍｅｎｔＭａｔｃｈＩｄｅｎｔｉｆｉｅｒ｛
ｐｒｅＳｅｔｔｌｅｍｅｎｔＭａｔｃｈＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ｐｒｅＳｅｔｔｌｅｍｅｎｔＭａｔｃｈＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｒｅｖｉｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
｝
ｐａｙｍｅｎｔＭａｔｃｈＳｔａｔｕｓ：ＮＯＴ＿ＫＮＯＷＮ
ａｌｔｅｒｎａｔｅＰａｙｍｅｎｔＣａｐｔｕｒｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ａｌｔｅｒｎａｔｅＰａｙｍｅｎｔＣａｐｔｕｒｅＩｄ－１”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
ａｌｔｅｒｎａｔｅＰａｙｍｅｎｔＣａｐｔｕｒｅＩｄｅｎｔｉｆｉｅｒ｛
ｄｏｍａｉｎ：ＲＥＣＥＩＶＡＢＬＥＳ＿ＣＡＰＴＵＲＥ＿ＥＮＧＩＮＥ
ｖａｌｕｅ：“ａｌｔｅｒｎａｔｅＰａｙｍｅｎｔＣａｐｔｕｒｅＩｄ－２”
ｖｅｒｓｉｏｎ：１
ｄｏｍａｉｎＴｙｐｅ：ＤＯＭＡＩＮ＿ＴＹＰＥ＿ＮＯＴ＿ＳＥＴ
｝
[0050]ステップ６２０において、正規化されたトランザクションは、メッセージバスに発行され得る。

【0042】

[0051]ステップ６２５において、トランザクション処理エコシステムにおけるモジュールおよび／または機能は、メッセージバスを監視および／またはリッスンすることができ、ステップ６３０において、関連する正規化されたトランザクションを処理し得る。たとえば、起動時または他の適切な時間において、各モジュールは、モジュールが処理を担当するトランザクションのタイプ、処理の順序などを、メッセージバス（または、メッセージバスコントローラ）に登録し得る。そのようなトランザクションがメッセージバスに発行されると、１つまたは複数のモジュールが、メッセージバスからトランザクションを「ピックアップ」し、トランザクションにおける処理を実行し得る。モジュールがトランザクションをピックアップすると、メッセージバスにアクノレッジメントメッセージを発行して、トランザクションの状態を他のモジュールに通知し得る。

【0043】

[0052]本発明の一実施形態によれば、モジュールがメッセージバスからトランザクションをピックアップするのではなく、メッセージバスは、モジュールの登録情報に基づいてトランザクションをモジュールにプッシュし得る。

【0044】

[0053]たとえば、金融トランザクションは、予約モジュールによって識別および「ピックアップ」され得、その後、予約モジュールは、処理のためにトランザクションを準備し得る。トランザクションによっては、複数のタイプの予約モジュールが存在し得る。例は、現金、有価証券、勘定書、請求書、予想される現金受領書、勘定書トランザクション、送金などを含み得る。本発明の一実施形態によれば、予約モジュールは、異なる法人の単一のトランザクションに対して複数の「レッグ(leg)」を作成し得る。その後、モジュールは、もう１つの予約可能なトランザクションをメッセージバスに発行し得る。

【0045】

[0054]資産移動モジュールおよび資産記録モジュールは、メッセージバスに発行される予約可能なトランザクションをリッスンし得る。資産移動モジュールは、予約可能なトランザクションをピックアップし、初期状態が「未決済」の、決済トランザクションを作成し得る。この機能は、決済トランザクションを、適切な決済モジュール（たとえば、ＣＨｉＰ、ＦＥＤ、ＳＷＩＦＴなど）にさらに供給し得る。トランザクションが決済されると、資産移動モジュールは、決済トランザクションの状態をクローズ、完了などに更新し得る。

【0046】

[0055]本発明の一実施形態によれば、バス上の異なる機能を識別する標準的な参照データキャッシュは、参照データを呼び出し得る。例示的な図によれば、エコシステムを流れるトランザクションには識別子のみを格納することができ、実際のデータまたは基礎となるデータを取得するためにそれらの識別子を分解する必要がある場合は、参照データキャッシュが呼び出され得る。

【0047】

[0056]参照データは、クライアント、口座および取引先企業／第三者（Ｃｐｔｙ: Counterparty/Third party）、固定決済命令（ＳＳＩ:Standing Settlement Instruction）、製品、クライアントの好みおよびプロファイル、清算データ、市場データ、クライアント口座振替（ＤＤ: Direct Debit）権限に関連するデータを含み得る。参照データは、参照データキャッシュツールを介して格納および管理され得る。参照データは、当事者およびアカウントと、製品および証書と、エスクロー契約管理（たとえば、エスクロー契約を管理するための参照データ）と、価格契約管理（たとえば、様々な製品やクライアントの価格契約を管理するための参照データ）と、決済命令（たとえば、クライアント自動引き落とし命令）と、制裁と、勘定と、ステートメント構成などをさらに含み得る。

【0048】

[0057]本発明の一実施形態によれば、資産記録モジュールはまた、メッセージバスに発行された任意の決済とともに、予約可能なトランザクションをもリッスンし得る。資産記録モジュールは、異なる予約可能なトランザクションに対して規則を適用して、メッセージバスに発行することもできるジャーナルまたは記録（たとえば、預金／クレジットセットを含む）を作成することができる規則エンジンを含み得る。ジャーナルは、セットおよび／または他のフォーマットに集約され得る。

【0049】

[0058]本発明の一実施形態によれば、状態変化を含むトランザクションは、たとえば、報告および監査のためにデータウェアハウスに格納され得る。
[0059]ステップ６３５において、モジュールは、処理されたトランザクションをメッセージバスに返し得る。モジュールが、トランザクションのエンドポイントである場合、処理されたトランザクションは、別のシステムへ、ユーザインターフェースへ送信され得るか、必要な場合、および／または、所望される場合、他の任意のアクションを行い得る。

【0050】

[0060]図７Ａおよび図７Ｂは、本発明の一実施形態による、支払受領書／支払キャッシュフローの例示的な例を示す。プレキャプチャ中、「ｐａｙｍｅｎｔ．ｒａｗ」７０１は、「ｐａｙｍｅｎｔ．ｉｎｉｔｉａｔｉｏｎ」７０２に変換され、その後、支払キャプチャ７２２によって強化／検証され得る。「ｐａｙｍｅｎｔ．ｎｏｒｍ」７０４は、支払キャプチャ７２２から生成され、その結果、支払予約エンジン７２４から「ｃａｓｈｔｘｎ．ｂｏｏｋａｂｌｅ」７０６が生成される。「ｃａｓｈｔｘｎ．ｂｏｏｋａｂｌｅ」７０７は、資産移動エンジン７２６（未決済決済）および資産記録７４４を介して処理される（保留中のジャーナルが作成される）。支払は、資産移動エンジン７２６を介して確認／決済され、その結果、「決済移動」７１１が決済され、資産記録７４４は、７０８、７０９、７１２および７１３によって表されるように、これらを保留中の「決済／確認されるポジション／ジャーナル」に消費する。

【0051】

[0061]図７Ａに示されるように、新しい支払または受領は、７０１によって表されるように、クライアントまたは清算システムによって開始され得る。取込チャネル(Ingestion Channel)７３０は、支払開始ソース、たとえば、クライアント、清算システム(clearing system)などを表し得る。データは、分離層を表し得るプレキャプチャ７２０において、生データ７０１として受信され得る。プレキャプチャ７２０は、変換、重複チェック、参照の設定（Ｓｅｔ Ｒｅｆ）、および統合を含む機能を実行し得る。支払は、７０２において、プレキャプチャ７２０からメッセージングバス７２８へと開始され得る。支払キャプチャ７２２は、７０３において、支払開始を受け取り得る。支払キャプチャ７２２を介して、支払開始は、７０４において、Ｐａｙｍｅｎｔ．Ｎｏｒｍとして正規化され得る。

【0052】

[0062]支払キャプチャ７２２は、資格、除外／賠償、支払管理、クライアントバッチ／バルク／集約、料金／課金／計算と、時間および／またはコストに基づく最適化と、クライアントの最適化と、ウェアハウス／スケジューリング、ＦＸ予約、フィルタサービスおよび優先順位付けとを含む、様々な特徴および機能を含み得る。支払キャプチャ７２２は、固定オーダ７３２からデータを受信し得る。たとえば、支払キャプチャ７２２は、様々なトランザクションタイプにわたるクライアントの命令をキャプチャし、さらに、正規化されたデータモデルに変換し得る。支払キャプチャ７２２は、クライアント固有のデータモデルから、ユニバーサル（またはエンティティ固有の）データモデルへの変換を実行し得る。正規化されたトランザクションデータモデルメッセージは、メッセージングバス７２８に発行され得る。キャプチャ処理は、ＯＣＲ／ＩＣＲ、機械学習、ファイル処理、およびメッセージ処理を含み得る。

【0053】

[0063]Ｐａｙｍｅｎｔ．Ｎｏｒｍは、７０５において、予約エンジン７２４によって受信され、７０６において、Ｃａｓｈ．Ｔｘｎ．Ｂｏｏｋａｂｌｅとしてクライアント予約を生成し得る。予約エンジン７２４は、トランザクションエンリッチメント、保有高タイプデリバティブ、レッグ生成、および料金／課金を含む様々な特徴および機能を含み得る。レッグ生成は、トランザクションレッグ生成を表す場合があり、たとえば、追加のトランザクションが必要になる場合がある。予約エンジン７２４は、レッグ生成７３４と通信し得る。本発明の一実施形態は、複数の予約エンジン、たとえば、各トランザクションタイプに対して１つの予約エンジンを含み得る。たとえば、予約エンジンは、基礎となる技術的構成要素を共有し得るが、トランザクションタイプごとに別々のインスタンスとして実行する。

【0054】

[0064]これは、資産移動７２６によって受け取られ、７０７において、決済ミッションのステータスを一致に更新することができる。決済ミッションは、ＳＭ．Ｏｐｅｎ７０８、ＳＭ．Ｏｐｅｎ．ＢｕｌｋＮｅｔ７０８．ａ、ＳＭ．Ｏｐｅｎ．ＣｌｅａｒＮｅｔ７０８．ｂ、およびＳＭ．Ｓｅｔｔｌｅｄ７１１によって示されているように、決済ファイルから生成され得る。たとえば、決済ミッションのステータスは、ＯＰＥＮ．Ｍａｔｃｈｅｄであり得る。決済時に、ステータスは、７１１を介して、ＳＥＴＴＬＥＤに設定され得る。

【0055】

[0065]資産移動７２６は、ゲートウェイ、クライアントバルク集約／ネッティング、ネッティング精算／集約、手動一致、リンケージ(Linkage)、承認、精算および決済（ＳＭ）、自動決済、マーキング失敗(Fails Marking)、信用調査、例外管理、支払管理、およびフィルタサービスを含む様々な特徴および機能を含み得る。資産移動７２６は、支払キャプチャ７２２からデータ（たとえば、ｄｄｉ．ｎｏｒｍ）を受信し、さらに、データ（たとえば、ｄｄｉ．ｎｏｒｍ）を、たとえば、クライアントの口座振替命令の設定および／または管理を行う口座振替（ＤＤ）管理７３６に送信することができる。資産移動７２６は、資産移動を必要とする様々なタイプのトランザクションのための決済ミッションを作成し得る。それに加えて、資産移動７２６は、取込チャネル７３０に、受領または確認メッセージを提供し得る。

【0056】

[0066]図７Ｂに示されるように、支払命令／収集７０９は、支払チャネル７４０から清算システム７４２へ送信され得る。支払が決済された後、決済７１０は、支払チャネル７４０に戻され得る。ジャーナル（転記）は、クライアントと決済との両方に対して作成され得る。ジャーナル／保有高ステータスは、保留中－転記(Pending-Post)として表され得る。

【0057】

[0067]資産記録７４４は、入力イベントからジャーナルおよび保有高を作成し得る。たとえば、資産記録７４４は、規則エンジン、ジャーナルエンジン、および保有高エンジンを含み得る。規則エンジンは、イベントをジャーナルに変換するための規則を保有し得る。ジャーナルエンジンは、イベントからジャーナル（ＤＲ／ＣＲセット）を作成し得る。たとえば、保有高エンジンは、生成されたＤＲ／ＣＲセットを集約し、保有高（たとえば、ポジション、残高）を作成し得る。他のエンジンは、ジャーナルセットを集約し、保有高に影響を与える集約エンジンを含み得、発行エンジンは、おのおのに変更が発生したときにジャーナルおよび保有高を公表し得る。また、資産記録７４４は、クライアントと決済との両方の口座ジャーナルを転記し得る。７０７、７０８、７０９、７１１、７１２、および７１３のインタラクションを通じて、ジャーナル／保有高ステータスは、決済済み－転記として表され得る。データは、一般台帳７４６のみならずデータウェアハウス７４８にも転記され得る。データは、７１６によって表されるように、Ｐａｙｍｅｎｔ．Ｉｎｉｔと、Ｐａｙｍｅｎｔ．Ｎｏｒｍと、Ｃａｓｈ．Ｔｘｎと、ＳＭ．Ｏｐｅｎと、ＴＤ．Ｊｏｕｒｎａｌと、ＴＳ．Ｈｏｌｄｉｎｇｓと、ＳＭ．Ｓｅｔｔｌｅｄと、ＳＤ．Ｊｏｕｒｎａｌと、ＳＤ．Ｈｏｌｄｉｎｇとを含み得る。

【0058】

[0068]本発明の一実施形態は、様々な用途、事業などに適用され得る。たとえば、イベントベースのインフラストラクチャは、コアバンキング技術、マーチャントサービス事業、国際債券事業などに適用され得る。それに加えて、様々な拡張機能が適用され得る。たとえば、金融トランザクション処理システムは、例外管理および調整特徴をサポートし得る。たとえば、例外は、取引予約エンジン、決済システム、および他の記録システムに適用され得る。例外が１つの記録システムで閉じられる場合、本発明の一実施形態は、メッセージングバスを介して更新をカスケード化またはルーティングし、それによって、例外に関連する重複する負担を除去し得る。例外は、必要に応じて、記録の調整システムまたは記録のタスク管理システムによって読み取られ得る。これにより、データと応答との一貫性および均一性が向上する。

【0059】

[0069]本発明の一実施形態は、ポジションロールアップ(position rollup)および／またはポジション集約(position aggregate)をサポートし得る。たとえば、事業は、基礎となる残高およびポジションの集約であり得る、利用可能な残高に関する情報を要求し得る。これは、メンバが口座を有しており、特定の地域に居住している可能性がある仮想口座に関連し得る。地域への資金提供は、集約が資金を必要とする集約レベルであり得る。したがって、本発明の一実施形態は、トランザクションが、基礎となる残高に達することを許可する前に、集約レベルでのポジションチェックをサポートし得る。別の例は、地域または通貨で、開発者に支払を要するエンティティを含み得る。他の集約は、特定の用途ケースシナリオに依存し得る。たとえば、ローンの場合、事業は、ローンの額を除外する利用可能なポジションまたは利用可能な残高を計算したい場合がある。したがって、本発明の一実施形態は、集約レベルポジションを決定するための事業規則に基づいて構成可能であり得る。

【0060】

[0070]以下、本発明のシステムおよび方法の実施の一般的な態様を説明する。
[0071]本発明のシステムまたは本発明のシステムの一部は、たとえば、汎用コンピュータなどの「プロセシングマシン」の形態であり得る。本明細書で使用される場合、「プロセシングマシン」という用語は、少なくとも１つのメモリを使用する少なくとも１つのプロセッサを含むと理解されるべきである。少なくとも１つのメモリは、命令のセットを格納する。命令は、永続的または一時的に、プロセシングマシンの１つまたは複数のメモリに格納され得る。プロセッサは、データを処理するために、１つまたは複数のメモリに格納されている命令を実行する。命令のセットは、上記のタスクなど、特定の１つまたは複数のタスクを実行する様々な命令を含み得る。特定のタスクを実行するためのそのような命令のセットは、プログラム、ソフトウェアプログラム、または単にソフトウェアとして特徴付けられ得る。

【0061】

[0072]１つの実施形態では、プロセシングマシンは、特殊なプロセッサであり得る。
[0073]上記のように、プロセシングマシンは、データを処理するために１つまたは複数のメモリに格納されている命令を実行する。データのこの処理は、たとえば、別のプロセシングマシンによる要求および／または他の入力に応答して、前の処理に応答して、プロセシングマシンの１人または複数のユーザによるコマンドに応答し得る。

【0062】

[0074]上記のように、本発明を実施するために使用されるプロセシングマシンは、汎用コンピュータであり得る。しかしながら、上記のプロセシングマシンはまた、特殊用途コンピュータと、たとえば、マイクロコンピュータ、ミニコンピュータまたはメインフレームを含むコンピュータシステムと、プログラムされたマイクロプロセッサと、マイクロコントローラと、周辺集積回路素子と、ＣＳＩＣ（カスタマ向け集積回路）またはＡＳＩＣ（特定用途向け集積回路）または他の集積回路と、論理回路と、デジタル信号プロセッサと、ＦＰＧＡ、ＰＬＤ、ＰＬＡ、またはＰＡＬなどのプログラマブル論理デバイスと、または、本発明の処理のステップを実施できる他の任意のデバイスまたはデバイスの構成とを含む多種多様な他の技術のうちのいずれかをも利用し得る。

【0063】

[0075]本発明を実施するために使用されるプロセシングマシンは、適切なオペレーティングシステムを利用し得る。したがって、本発明の実施形態は、ｉＯＳオペレーティングシステム、ＯＳ Ｘオペレーティングシステム、Ａｎｄｒｏｉｄオペレーティングシステム、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（商標）オペレーティングシステム、Ｕｎｉｘオペレーティングシステム、Ｌｉｎｕｘ（登録商標）オペレーティングシステム、Ｘｅｎｉｘオペレーティングシステム、ＩＢＭ ＡＩＸ（商標）オペレーティングシステム、Ｈｅｗｌｅｔｔ－Ｐａｃｋａｒｄ ＵＸ（商標）オペレーティングシステム、Ｎｏｖｅｌｌ Ｎｅｔｗａｒｅ（商標）オペレーティングシステム、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ Ｓｏｌａｒｉｓ（商標）オペレーティングシステム、ＯＳ／２（商標）オペレーティングシステム、ＢｅＯＳ（商標）オペレーティングシステム、Ｍａｃｉｎｔｏｓｈオペレーティングシステム、Ａｐａｃｈｅオペレーティングシステム、ＯｐｅｎＳｔｅｐ（商標）オペレーティングシステム、または別のオペレーティングシステムまたはプラットフォームを実行するプロセシングマシンを含み得る。

【0064】

[0076]上記のような本発明の方法を実践するために、プロセシングマシンのプロセッサおよび／またはメモリが、物理的に同じ地理的場所に配置される必要はないことが認識される。すなわち、プロセシングマシンによって使用されるプロセッサおよびメモリのおのおのは、地理的に異なる位置に配置され、任意の適切な方式で通信するように接続され得る。それに加えて、プロセッサおよび／またはメモリのおのおのは、異なる物理的な機器から構成され得ることが認識される。したがって、プロセッサが、１つの位置にある単一の機器である必要も、メモリが、別の位置にある別の単一の機器である必要もない。すなわち、プロセッサは、２つの異なる物理的位置にある２つの機器であり得ることが考慮される。２つの異なる機器は、任意の適切な方式で接続され得る。それに加えて、メモリは、２つ以上の物理的位置に、メモリの２つ以上の部分を含み得る。

【0065】

[0077]さらに説明すると、上記のように、処理は、様々な構成要素および様々なメモリによって実行される。しかしながら、本発明のさらなる実施形態によれば、上記のような２つの異なる構成要素によって実行される処理は、単一の構成要素によって実行され得ることが認識される。さらに、上記のように１つの異なる構成要素によって実行される処理は、２つの異なる構成要素によって実行され得る。同様の方式で、上記の２つの異なるメモリ部分によって実行されるメモリストレージは、本発明のさらなる実施形態によれば、単一のメモリ部分によって実行され得る。さらに、上記のように１つの異なるメモリ部分によって実行されるメモリストレージは、２つのメモリ部分によって実行され得る。

【0066】

[0078]さらに、様々な技術を使用して、様々なプロセッサおよび／またはメモリ間の通信を提供し、ならびに本発明のプロセッサおよび／またはメモリが、他の任意のエンティティと通信できるように、すなわち、たとえば、追加の命令を取得したり、リモートメモリストアにアクセスして使用できるようにすることができる。そのような通信を提供するために使用されるそのような技術は、たとえば、ネットワークと、インターネットと、イントラネットと、エクストラネットと、ＬＡＮと、イーサネットと、セルタワーまたは衛星を介したワイヤレス通信と、または、通信を提供する任意のクライアントサーバシステムとを含み得る。そのような通信技術は、たとえば、ＴＣＰ／ＩＰ、ＵＤＰ、またはＯＳＩなどの任意の適切なプロトコルを使用し得る。

【0067】

[0079]上記のように、命令のセットが、本発明の処理において使用され得る。命令のセットは、プログラムまたはソフトウェアのフォーマットの形態であり得る。ソフトウェアは、たとえば、システムソフトウェアまたはアプリケーションソフトウェアの形態であり得る。ソフトウェアは、たとえば、別々のプログラムの集合、より大きなプログラム内のプログラムモジュール、またはプログラムモジュールの一部の形態であり得る。使用されるソフトウェアは、オブジェクト指向プログラミングの形態のモジュール式プログラミングも含み得る。ソフトウェアは、処理中のデータをどう処理するかをプロセシングマシンに指示する。

【0068】

[0080]さらに、本発明の実施および操作で使用される命令または命令のセットは、プロセシングマシンが命令を読み取ることができるような、適切な形態であり得ることが認識される。たとえば、プログラムを形成する命令は、マシン語またはオブジェクトコードに変換されて、１つまたは複数のプロセッサが命令を読み取れるようにする適切なプログラミング言語の形態であり得る。つまり、特定のプログラミング言語で記述されたプログラミングコードまたはソースコードの行は、コンパイラ、アセンブラ、またはインタプリタを使用してマシン語に変換される。マシン語は、特定のタイプのプロセシングマシン、すなわち、たとえば、特定のタイプのコンピュータに固有の、バイナリコード化されたマシン命令である。コンピュータは、マシン語を理解する。

【0069】

[0081]本発明の様々な実施形態によれば、任意の適切なプログラミング言語が使用され得る。例示的に、使用されるプログラミング言語は、たとえば、アセンブリ言語、Ａｄａ、ＡＰＬ、Ｂａｓｉｃ、Ｃ、Ｃ＋＋、ＣＯＢＯＬ、ｄＢａｓｅ、Ｆｏｒｔｈ、Ｆｏｒｔｒａｎ、Ｊａｖａ、Ｍｏｄｕｌａ－２、Ｐａｓｃａｌ、Ｐｒｏｌｏｇ、ＲＥＸＸ、Ｖｉｓｕａｌ Ｂａｓｉｃ、および／またはＪａｖａＳｃｒｉｐｔを含み得る。さらに、本発明のシステムおよび方法の動作に関連して、単一のタイプの命令または単一のプログラミング言語を利用する必要はない。むしろ、必要な場合、および／または、所望される場合、任意の数の異なるプログラミング言語が利用され得る。

【0070】

[0082]また、本発明の実践において使用される命令および／またはデータは、必要に応じて、任意の圧縮または暗号化技術またはアルゴリズムを利用し得る。データを暗号化するために、暗号化モジュールが使用され得る。さらに、ファイルまたは他のデータは、たとえば、適切な復号モジュールを使用して復号され得る。

【0071】

[0083]上記のように、本発明は、たとえば、少なくとも１つのメモリを含む、コンピュータまたはコンピュータシステムを含むプロセシングマシンの形態で例示的に具体化され得る。たとえば、コンピュータオペレーティングシステムが、上記の操作を実行することを可能にする命令のセット、すなわち、ソフトウェアは、必要に応じて、多種多様な１つまたは複数の媒体のいずれかに含まれ得ることが認識されるべきである。さらに、命令のセットによって処理されるデータは、多種多様な１つまたは複数の媒体のいずれかに含まれ得る。すなわち、本発明で使用される命令および／またはデータのセットを保有するために利用される特定の媒体、すなわちプロセシングマシンのメモリは、たとえば、様々な物理的形態または伝送のいずれかを呈し得る。例示的に、媒体は、紙、紙の透明材、コンパクトディスク、ＤＶＤ、集積回路、ハードディスク、フロッピーディスク、光ディスク、磁気テープ、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ワイヤ、ケーブル、ファイバ、通信チャネル、衛星伝送、メモリカード、ＳＩＭカード、または他のリモート伝送、および、本発明のプロセッサによって読み取られ得る他の任意の媒体またはデータソースの形態であり得る。

【0072】

[0084]さらに、本発明を実施するプロセシングマシンで使用される１つまたは複数のメモリは、メモリが、必要に応じて、命令、データ、または他の情報を保有できるようにするために、多種多様な形態のいずれかであり得る。したがって、メモリは、データを保有するためのデータベースの形態であり得る。データベースは、たとえば、フラットファイル構成や、またはリレーショナルデータベース構成など、任意の所望されるファイル構成を使用し得る。

【0073】

[0085]本発明のシステムおよび方法では、様々な「ユーザインターフェース」を利用して、ユーザが、本発明を実施するために使用される１つまたは複数のプロセシングマシンとインターフェースすることを可能にすることができる。本明細書で使用される場合、ユーザインターフェースは、ユーザがプロセシングマシンとインタラクトすることを可能にする、プロセシングマシンによって使用される任意のハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せを含む。ユーザインターフェースは、たとえば、ダイアログ画面の形態であり得る。ユーザインターフェースは、マウス、タッチスクリーン、キーボード、キーパッド、音声リーダ、音声認識器、ダイアログ画面、メニューボックス、リスト、チェックボックス、トグルスイッチ、押しボタン、または、プロセシングマシンが命令のセットを処理するとき、ユーザが、プロセシングマシンの動作に関する情報を受信できるようにする、および／または、プロセシングマシンに情報を提供する他の任意のデバイス、のうちのいずれかを含み得る。したがって、ユーザインターフェースは、ユーザとプロセシングマシンとの間の通信を提供する任意のデバイスである。ユーザインターフェースを介して、ユーザによって、プロセシングマシンに提供される情報は、たとえば、コマンド、データの選択、または他の何らかの入力の形態であり得る。

【0074】

[0086]上記で論じたように、ユーザインターフェースは、プロセシングマシンがユーザのためにデータを処理できるように、命令のセットを実行するプロセシングマシンによって利用される。ユーザインターフェースは、通常、情報を伝達するため、またはユーザから情報を受信するために、ユーザとインタラクトするために、プロセシングマシンによって使用される。しかしながら、本発明のシステムおよび方法のいくつかの実施形態によれば、人間のユーザが、本発明のプロセシングマシンによって使用されるユーザインターフェースと実際にインタラクトする必要はないことを認識されたい。むしろ、本発明のユーザインターフェースは、人間のユーザではなく、別のプロセシングマシンとインタラクトする、すなわち、情報を伝達および受信し得ることも考慮される。したがって、他のプロセシングマシンは、ユーザとして特徴付けられ得る。さらに、本発明のシステムおよび方法において利用されるユーザインターフェースは、人間のユーザとも部分的にインタラクトしながら、別の１つまたは複数のプロセシングマシンと部分的にインタラクトし得ることが考慮される。

【0075】

[0087]本発明が幅広い有用性および用途に影響を受けやすいことは、当業者によって容易に理解されるであろう。本明細書に記載のもの以外の本発明の多くの実施形態および適合、ならびに多くの変形、修正、および同等の構成は、本発明の内容または範囲から逸脱することなく、本発明およびその前述の説明から明らかであるか、または合理的に示唆される。

【0076】

[0088]したがって、本発明は、その例示的な実施形態に関して本明細書で詳細に説明されたが、本開示は、本発明の例示的かつ例示的なものにすぎず、本発明の可能な開示を提供するように作られていることを理解されたい。したがって、前述の開示は、本発明を解釈または限定すること、あるいは他のそのような実施形態、適合、変形、修正または同等の構成を除外することは意図されていない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】