JP2012533824A - リアルタイムバッチ口座処理用のシステムおよび方式 - Google Patents

Abstract

本開示は、リアルタイム口座処理用の技術を開示するものである。一態様において、本方式は、（１）バッチ処理用としてマーキングされた要求を口座処理センターが受信し、（２）このマーキングされた要求をキャッシュし、（３）マーキングされた要求内の口座に関係するタイプのサブ要求の前処理を行い（口座処理の操作タイプのマージを含む）、（４）前処理されたサブ要求を含むマーキングされた要求を処理し、処理結果を対応するクライアントに提供する、という各手順を含む。バッチ処理要求は、クライアントで直接送信することも、バッチ処理要求を含む要求を送信するためにクライアントに提供されているインターフェースを使用してクライアントから送信することもできる。バッチ処理要求を送信する際に、クライアントは処理結果をオンラインで待機し、処理結果をリアルタイムで取得することができる。さらに、バッチ処理要求を受信する際に、口座処理センターはそのバッチ処理要求の前処理を行うことができる。たとえば、同一口座についての操作をマージすることにより、バッチ処理の効率性が高まる。

Description

関連特許出願の相互参照
本出願は、２００９年７月２２日に「リアルタイムバッチ口座処理用のシステムおよび方式」という名称で出願された中国出願番号第２００９１０１５９６５９．０に基づく優先権を主張し、参照により本明細書に組み込まれる。

本開示はインターネット分野に関するもので、特に、リアルタイムバッチ口座処理用のシステムと方式に関するものである。

図１は、従来の口座処理システムを示したものである。この口座処理システムは、処理センター１１と、複数のクライアント１２を含む。口座処理センター１１は、専用回線またはネットワーク（インターネットまたはイントラネット）を経由して、クライアント１２にアクセスすることができる。クライアント１２は複数存在する場合があり、端末またはネットワークであり得る。口座処理センター１１は、少なくともサーバー２１とのデータベース２２を含む。データベース２２は、口座情報とさまざまな処理情報を格納するように構成される。サーバー２１は、口座に関する各種の操作と管理を行うように構成される。

口座処理センター１１がサードパーティの支払プラットフォームである例においては、クライアント１２が口座処理センター１１に対して、支払額がそれぞれＳ１、Ｓ２、Ｓ３、・・・、Ｓｎである他の複数の口座（口座Ｂ１，口座Ｂ２，口座Ｂ３、・・・、口座Ｂｎなど）に口座Ａの中の資金を支払うようにという指示を出す。従来の支払システムを以下に説明する。

最初に、口座処理センター１１が、支払操作の要求をクライアント１２から受信する。

次に、支払口座処理センター１１は、１つの支払操作を処理する。

サーバー２１は、データベース２２の口座Ａにアクセスして、口座Ａの残高が支払額Ｓ１よりも多いかどうかを判断する。口座Ａの残高がＳ１の金額よりも多い場合、サーバー２１は口座Ａと口座Ｂ１をロックし、口座Ａから金額Ｓ１を差し引き、データベースの口座Ｂ１に金額Ｓ１を加算し、支払操作の完了後に口座Ａと口座Ｂ１のロックを解除する。

このように、口座処理センター１１は、支払を完了するためにｎ回の操作を実行する必要がある。こうした処理の操作には、いくつかの技術的な落とし穴がある。

従来の支払処理では、口座Ａに対する頻繁な操作が必要になる。それぞれの操作において、支払操作の完了後に、口座Ａのロックと解除が必要になる。これにより、サーバー２１の処理効率が低下するだけでなく、サーバー２１の処理能力も急激に低下し、他のクライアントから送信された処理要求すら受信できなくなり、深刻な場合はサーバー２１が停止する可能性がある。

具体的には、比較的大量のバッチ口座処理要求が発生した場合や、こうしたバッチ処理において処理される口座が大量に存在する場合、高い操作負荷がサーバー２１にかかることになる。その場合、サーバー２１における処理要求のトラフィック量が容易に増大し、処理要求の失敗率が高くなるため、クライアントのカスタマーエクスペリエンスに影響する。

こうした問題を解決するため、口座処理センター１１の技術者たちは多くのリサーチを試み、以下に説明する銀行サブシステムの例を使用した、非同期のバッチ口座処理用の方式を開発した。

口座処理センター１１は、支払額がそれぞれＳ１、Ｓ２、Ｓ３、…、Ｓｎである他の複数の口座（口座Ｂ１，口座Ｂ２，口座Ｂ３、…、口座Ｂｎなど）に口座Ａの資金を支払うようにという指示をクライアントから受信する。口座処理センター１１はこうした指示を格納し、この指示を実行するための適切な時間まで待機し、指示の処理結果を保存し、この処理結果を適切なタイミングでクライアント１２にフィードバックする。通常、口座処理センター１１は、サーバー２１における要求処理の待ち行列が短くなるまで（深夜など）、指示の処理は行わない。こうしたバッチ処理により、サーバー２１に対する高い操作負荷の問題は軽減することができる。ただし、この方法では、リアルタイム処理による効果が低くなる。特に、クライアント１２における口座Ａの残高が支払額より少ないにもかかわらず、クライアント１２はそうした情報をタイムリーに知ることができないという場合に、リアルタイム処理による効果が低くなる。その結果、支払処理全体が影響を受けることになる。

本開示は、バッチ口座処理によるサーバーへの高い操作負荷や低いリアルタイム効率など、従来の技術における問題を解決するためのリアルタイムバッチ口座処理用のシステムを提供する。

この目標を達成するため、本開示は、口座処理センターとクライアントを含むことができるリアルタイムバッチ口座処理用システムを提供する。

クライアントは、バッチ処理要求をマーキングするように構成されたバッチ処理ユニットと、口座処理センターとの相互作用を確立するように構成された中央相互作用ユニットを含むことができる。

口座処理センターは、受信した要求からバッチ処理要求を識別するように構成されたバッチ処理識別ユニット、バッチ処理内の同一口座に関係する処理について同じタイプの要求の前処理を行うように構成された前処理ユニット（同一口座のすべての同じタイプの処理要求のマージを含む）、および、前処理を含む操作の完了後にバッチ処理要求を処理し、対応するクライアントに処理結果を返すように構成された要求処理ユニットをさらに含むことができる。

前処理ユニットとバッチ処理識別ユニットは、前処理サーバーにインストールすることができる。要求処理ユニットは、要求処理サーバーにインストールすることができる。あるいは、前処理ユニットとバッチ処理識別ユニットを前処理モジュールにインストールすることもできる。前処理モジュールと要求処理ユニットは、２つの並行処理ユニットにすることができる。

本開示は、リアルタイムバッチ口座処理用の別のシステムも提供し、このシステムは、口座処理センターを含むことができる。この口座処理センターは、前処理ユニットと処理要求ユニットをさらに含むことができる。

前処理ユニットは、バッチ処理要求を含む要求を送信するためのインターフェースをクライアントに提供するように構成されたクライアント相互作用サブユニット、バッチ処理内の同一口座に関係する処理について同じタイプの要求の前処理を行うように構成された前処理サブユニット（同一口座の処理用のすべての同じタイプの処理要求のマージを含む）、および、前処理を含む操作の完了後にバッチ処理要求を処理し、対応するクライアントに処理結果を返すように構成された要求処理ユニットを含むことができる。

さらに本開示は、クライアントから送信されたバッチ処理要求のリアルタイム処理を実現するための、リアルタイムバッチ口座処理用の方式を提供する。この方式は、（１）バッチ処理としてマーキングされた要求を口座処理センターが受信し、（２）マーキングされた要求を取得し、（３）マーキングされた要求内の同一口座に関係するサブ要求タイプの前処理を行い（口座処理の操作タイプのマージを含む）、（４）前処理されたサブ要求を含むマーキングされた要求を処理して、対応するクライアントへ処理結果を提供する、という各手順を含むことができる。

この方式の手順（３）を実行する際に、要求を処理し、対応するクライアントに処理結果を返す手順と、別のバッチ処理要求を処理し、対応するクライアントに処理結果を返す手順のいずれかを同時に実行することができる。

さらに、この方式の手順（１）の前に、バッチ処理要求の指示を入力するためのインターフェースをクライアントに提供し、クライアントの入力バッチ処理情報を取得し、マーキング後にバッチ処理要求を作成するという手順を含めることができる。

あるいは、この方式の手順（１）の前に、クライアントからのバッチ処理要求をクライアントが受信し、バッチ処理要求の先頭に開始マークを追加し、バッチ処理要求の最後に終了マークを追加するという手順を含めることもできる。

以下に説明するように、本発明には、従来の技術と比較した場合にいくつかの利点がある。

第一に、バッチ処理要求を実行する際に、クライアントは処理結果をオンラインで待機し、処理結果をリアルタイムで取得することができる。

第二に、バッチ処理要求を受信する際に、口座処理センターはその要求の前処理を実行することができる。たとえば、同一口座に関する各操作をマージすることにより、バッチ処理の効率を高めることができる。

第三に、本発明は、既存の要求処理ユニットの改修は必要とせず、既存のシステムの安定性を確保するための追加のバッチ処理ユニット（最新のソフトウェアまたはサーバー）を増設するだけで済む。

最後に、本開示は、実装可能な２つの実施形態を提供する。１つは、クライアントがバッチ処理要求を口座処理センターに直接送信する実施形態であり、もう１つは、バッチ処理要求を含む要求を送信するためのインターフェースを、口座処理センターがクライアントに提供する実施形態である。どちらの実施形態にも、使いやすいという利点がある。

従来の口座処理システムを示す図である。 本開示に従い、リアルタイムバッチ口座処理用システムの典型的な実装を示す図である。 本開示に従い、リアルタイムバッチ口座処理用の第１の方式の流れ図を示している。 本開示に従い、口座処理センターのブロック図を示している。 本開示に従い、リアルタイムバッチ口座処理用の第２の方式の流れ図を示している。

各図面を参照しながら、以下に詳細な説明を記述する。

以下に、第１の典型的な実施形態を記述する。

図２は、本開示に従い、リアルタイムバッチ口座処理用システムの典型的な実施形態を示している。このシステムは、口座処理センター３１およびクライアント３２を含む。

クライアント３２は、イントラネットにおける端末またはノードにすることができる。通常、クライアント３２は、メモリー４２およびプロセッサ４１を含む。

リアルタイム処理のバッチ要求を実行するには、口座処理センター３１からクライアント３２に対して、バッチ処理要求用のソフトウェアまたはハードウェアを提供する必要がある。通常、口座処理センター３１からクライアント３２に対して、ネットワーク経由でソフトウェアまたはプラグインを提供するか、ソフトウェアを含むコンパクトディスク（ＣＤ）を提供するか、あるいはソフトウェアを含むユニバーサルシリアルバス（ＵＳＢ）を提供する。クライアント３２はこのソフトウェアをインストールして、バッチ要求を送信するための機能を実装する。

クライアント３２は、プロセッサ４１およびメモリー４２を含む。プロセッサ４１は、バッチ処理要求を含む要求を口座処理センター３１に送信し、口座処理センター３１から返された結果を受信するように構成される。メモリー４２は、処理ソフトウェア、要求のデータ、処理結果などの情報を保存するように構成される。要求の送信と返された結果の保存については当業者には明らかであるから、説明を簡潔にするため、詳しい説明は記述しない。本開示では、バッチ処理についてのみ、詳しい説明を記述する。

プロセッサ４１は、バッチ処理ユニット４１１および中央相互作用ユニット４１２をさらに含む。

バッチ処理ユニット４１１は、バッチ処理要求をマーキングするように構成される。クライアントから送信されたバッチ処理要求を受信する際に、バッチ処理ユニット４１１は、このバッチ処理をマーキングして要求を送信する。

中央相互作用ユニット４１２は、口座処理センター３１との相互作用を確立するように構成される。通常、クライアント３２は、口座処理センター３１用のインターフェースを持つ。中央相互作用ユニット４１２は、このインターフェースを経由して口座処理センター３１に要求を送信し、返された処理結果をこのインターフェースを経由して受信する。

メモリー４２は、バッチ処理ストレージユニット４２１および要求レコードストレージユニット４２２をさらに含む。バッチ処理ストレージユニット４２１は、バッチ処理ソフトウェアを格納するように構成され、特に、バッチ処理要求の開始マークと終了マークを追加するように構成される。要求レコードストレージユニット４２２は、各要求の処理情報を格納するように構成される。

さらに、バッチ要求表示インターフェース４１３を、クライアント３２のプロセッサ４１にインストールすることができる。バッチ要求表示インターフェース４１３により、バッチ処理ユニット４１１が接続される。バッチ要求表示インターフェース４１３は、バッチ処理を指示するインターフェースをクライアントに提供するように構成される。バッチ要求表示インターフェース４１３は、クライアントのバッチ処理要求をバッチ処理ユニット４１１に送信する。バッチ処理ユニット４１１は、バッチ処理要求に開始マークと終了マークを追加する。

口座処理センター３１は、サーバー５１およびデータベース５２を含む。

サーバー５１は、バッチ処理識別ユニット５１１、前処理ユニット５１３、および要求処理ユニット５１４をさらに含む。

バッチ処理識別ユニット５１１は、受信した要求からバッチ処理要求を識別するように構成される。

前処理ユニット５１３は、バッチ処理内の同一口座に関係する処理について同じタイプの要求の前処理を行うように構成される（同一口座のすべての同じタイプの処理要求のマージを含む）。

要求処理ユニット５１４は、前処理を含む操作の完了後にバッチ処理要求を処理し、クライアント３２などの対応するクライアントに処理結果を返すように構成される。

サーバー５１の要求処理ユニット５１４は既存の処理ユニットと同じであるため、追加の操作は必要ない。バッチ処理識別ユニット５１１および前処理ユニット５１３は、２つの形式で既存の要求処理ユニット５１４とは異なるユニットにすることができる。１つは、バッチ処理識別ユニット５１１および前処理ユニット５１３を含む前処理サーバーをセットアップする形式で、もう１つは、独立した前処理モジュールを現行サーバー５１内にセットアップする形式である。バッチ処理識別ユニット５１１は、マークに従って、受信した要求からバッチ処理要求を識別する。前処理ユニット５１３は、同一口座に対するすべての要求を１つの要求にマージする。マージされる要求の形式は、既存の形式の要件に準拠する。そのため、前処理ユニット５１３が操作を実行しても、既存の要求処理ユニット５１４の操作を妨げることはなく、２つの並行処理ユニットが実現する。

データベース５２は、既存のストレージユニット（口座ストレージユニットや処理結果ストレージユニットなど）のほかに、バッチ処理識別ユニット５１１と前処理ユニット５１３にそれぞれ接続するバッチ処理キャッシュセクション５２１も含む。バッチ処理キャッシュセクション５２１は、バッチ処理識別ユニット５１１によって識別されたバッチ処理をキャッシュするように構成される。独立した前処理サーバーをインストールした場合、この前処理サーバーには、バッチ処理識別ユニット５１１および前処理ユニット５１３が含まれる。その場合、バッチ処理キャッシュセクション５２１を前処理サーバーに直接インストールし、前処理サーバーのメモリーに直接格納することができる。一方、独立した前処理モジュールをサーバー５１にインストールした場合、バッチ処理キャッシュセクション５２１をデータベース５２にインストールするか（図２を参照）、またはサーバー５１のメモリーに格納することができる。

上記は、典型的な実施形態の一つにすぎない。こうしたユニットは、論理ユニットにすることも、物理ユニットにすることもできる。たとえば、ソフトウェアまたはハードウェアのいずれかによって実装されたユニットなどであり、本開示の範囲を制限するものとして解釈されるべきではない。

上記の開示された典型的な実施形態に関し、図３は、本開示によるリアルタイムバッチ口座処理の第１の方式の流れ図を示したものである。この方式は、バッチ処理のリアルタイム処理要求を実現するために使用される。この方式には、以下に記述するように、いくつかのアクションが含まれる。

Ｓ１１０では、口座処理センターが、バッチ処理としてマーキングされた要求をクライアントから受信する。

クライアントは最初に、バッチ処理の指示を受信するためのインターフェースをクライアントに提供するなど、バッチ処理を可能にするためのセットアップを実行する。

クライアントからの指示をクライアントが受信すると、クライアントは、バッチ処理要求の先頭に開始マークを追加し、バッチ処理要求の最後に終了マークを追加する。

クライアントは、マーキングされたバッチ処理要求を口座処理センターに送信する。

マークは、通常の文字マークにすることができる。一実施形態では、このマークは主に指示として機能する。口座処理センターが指示を受信すると、対応するバッチ処理を開始することができる。

口座処理センターが要求を受信すると、前処理モジュール／前処理サーバーは、この要求がバッチ処理の要求かどうかを最初に判断する。バッチ処理の要求である場合、前処理モジュール／前処理サーバーはバッチ処理の操作を開始する。バッチ処理の要求ではない場合、前処理モジュール／前処理サーバーは、この要求を要求処理ユニットに処理用として送信する。前処理モジュール／前処理サーバーは、マークに従って、この要求がバッチ処理の要求かどうかを判断する。

Ｓ１２０では、バッチ処理としてマーキングされた要求をキャッシュする。

この要求がバッチ処理の要求であると判断した場合、前処理モジュール／前処理サーバーは、このバッチ処理要求をキャッシュすることができる。たとえば、要求に含まれているデータがバッチ処理の開始マークであると判断した場合、前処理モジュール／前処理サーバーは、バッチ処理の終了マークを検出するまで、データのキャッシュを行う。

一実施形態では、こうした機能は、主にプログラミング言語によって実行される。以下に例を示す。

public class BatchTemplate {
/＊＊
＊ implement account’s batch processing
＊
＊ @return}

クライアントによって入力されたバッチ処理要求をクライアントが受信すると、クライアントは、先頭に「public class BatchTemplate {」を追加し、最後に「@return}」を追加することができる。実際には、パブリッククラスのBatchTemplateはテンプレートである。つまり、口座処理センターとクライアントは、「BatchTemplate」がバッチ処理の指示であり、含まれているデータがバッチ処理を必要とするデータであることについて合意することができ、こうしたバッチ処理データの順序と内容についても合意することができる。クライアントは、この合意に従って、BatchTemplateテンプレート内のデータを編成する。

こうしたデータは、他のデータとともに、口座処理センターに送信される。口座処理センターが要求を受信すると、「public class BatchTemplate」を検出してこれがバッチ処理要求の指示であることを理解し、バッチ処理要求指示の最後にある「@return」を使用して、含まれている内容の実行を開始する。

Ｓ１３０では、マーキングされた要求内の同一口座に関係する同じタイプのサブ要求の前処理を行う（同一口座の同じ処理タイプのマージ操作を含む）。

バッチ処理とは、一部の口座に対する複数の操作のことを主に指す。前処理とは、同一口座に関して、すべての操作を統一して分類することを主に指す。同一口座の同じタイプのサブ要求処理のマージには、口座のすべての入金と出金（つまり、口座の取引）の計算、口座残高の計算、および最終的な取引金額の取得がさらに含まれる。

口座について同じタイプの操作のマージが完了すると、処理要求の形式に従い、新しい処理要求が作成される。

Ｓ１４０では、前処理されたサブ要求を含むマーキングされたバッチ処理要求が処理され、処理結果がクライアントに提供される。

Ｓ１３０を実行する際に、本方式では、要求を処理し、対応するクライアントに処理結果を返す手順と、別のバッチ処理要求を処理し、対応するクライアントに処理結果を返す手順のいずれかを同時に実行する。

つまり、要求処理ユニットが手順１４０を実行する際に、前処理モジュール／前処理サーバーは、他のバッチ処理要求の前処理を行うことができる。

上記の実施形態では、バッチ処理用の対応するソフトウェアまたはプラグインがクライアントにインストールされる。クライアントは、クライアントにインストールされたソフトウェアまたはプラグイン通じて、バッチ処理要求を送信する。この実施形態では、対応するソフトウェアまたはプラグインをクライアントはインストールする必要がある。

以下に、第２の典型的な実施形態を記述する。

図４は、本開示に従い、口座処理センターの別の実施形態の原則的な構造図を示したものである。このシステムは、前処理ユニット６１および要求処理ユニット６２を含む。要求処理ユニット６２は、既存の要求処理ユニットにすることができる。１つの例として、サードパーティの支払プラットフォームでは、要求処理ユニット６２は既存の支払処理システムにすることができる。

この実施形態では、既存のサードパーティ支払プラットフォームに前処理ユニット６１が追加される。前処理ユニット６１は、クライアント相互作用サブユニット６１１、バッチ処理サブユニット６１２、バッチ処理識別サブユニット、および前処理サブユニット６１４を含む。

クライアント相互作用サブユニット６１１は、バッチ処理要求を含む要求をクライアントに送信するためのインターフェースを提供するように構成される。クライアントは、クライアント相互作用サブユニット６１１を使用して、前処理ユニット６１との相互作用を確立する。クライアントは、インターネットまたは無線通信システムを使用して、クライアント相互作用サブユニット６１１と接続することができる。バッチ処理要求を送信するためのクライアント用インターフェースは、クライアント相互作用サブユニット６１１にインストールされる。

前処理サブユニット６１４は、バッチ処理内の同一口座に関係する処理に対する同じタイプの要求の前処理を行うように構成される（同一口座のすべての同じタイプの処理要求のマージを含む）。

クライアント相互作用サブユニット６１１がバッチ処理要求だけを受信した場合、前処理サブユニット６１１だけが関与する。クライアント相互作用サブユニット６１１は、クライアントから送信されたバッチ処理要求のほかにも要求を受信するため、前処理ユニット６１には以下に示す他のコンポーネントも含まれる。

バッチ処理サブユニット６１２は、クライアントによって入力されたバッチ処理情報を取得し、バッチ処理要求を作成するためのマークを追加するように構成される。

バッチ処理識別サブユニット６１３は、各要求からバッチ処理要求を識別し、識別したバッチ処理要求を前処理サブユニット６１４に送信するように構成される。

独立したサーバーによって前処理ユニット６１を実装すると、このサーバーのメモリー内にスペースが確保される。たとえば、バッチ処理識別サブユニット６１３によって識別されたバッチ処理要求をキャッシュするように構成されたバッチ処理キャッシュセクション６１５などである。既存の要求処理ユニット６２が配置されたサーバーによって前処理ユニット６１を実装すると、バッチ処理識別サブユニット６１３によって識別されたバッチ処理要求をキャッシュするためのスペースが、既存のデータベース内に確保される。

上記の説明により、クライアントがクライアント相互作用サブユニット６１１との相互作用を確立できる限り、第２の典型的な実施形態では、クライアント側での改良は一切必要ないことが理解されよう。

図５は、本開示に従い、リアルタイムバッチ口座処理の第２の実施形態の流れ図を示したものである。この実施形態は、クライアントから送信されたバッチ処理要求をリアルタイムで処理する場合に使用される。この実施形態には、以下に示すいくつかのアクションが含まれる。

Ｓ２１０では、バッチ処理要求を送信するためのインターフェースを口座処理センターがクライアントに提供する。

前処理ユニットは、このインターフェースをクライアントに提供し、無線通信ネットワークまたはインターネットを使用して、クライアントによるこのインターフェースへのアクセスを受信する。

Ｓ２２０では、このインターフェースを使用して、クライアントによって入力されたバッチ処理情報を受信し、バッチ処理要求を作成するためのマークを追加する。

前処理ユニットは、クライアントによって入力されたバッチ処理情報を受信し、バッチ処理要求を作成するための開始マークと終了マークを追加する。

Ｓ２３０では、バッチ処理要求をキャッシュする。

要求がバッチ処理要求であると判断した場合、前処理ユニットはこの要求をバッチ処理用にキャッシュする。たとえば、要求に含まれているデータがバッチ処理の開始マークを示していると判断した場合、前処理ユニットは、バッチ処理の終了マークを示すデータを検出するまで、データのキャッシュを行う。

Ｓ２４０では、バッチ処理要求内の同一口座に関係する同じタイプのサブ要求の前処理を行う（同一口座の処理についての同じタイプの操作のマージを含む）。

バッチ処理とは、１つ以上の口座に関する複数の操作のことを主に指す。前処理とは、同一口座のすべての操作を統一して分類することを主に指す。同一口座の処理についての同じタイプの操作のマージには、口座のすべての取引金額の計算と、最終的な取引金額の取得がさらに含まれる。

口座について同じタイプの操作のマージが完了すると、処理要求の形式に従い、新しい処理要求が作成される。

Ｓ２５０では、前処理されたサブ要求を含むバッチ処理要求を処理し、処理結果をクライアントに返す。

以下に、適用のシナリオを記述する。

以下のシナリオは、口座Ａの資金から他の３０の口座（口座Ｂ１、Ｂ２、・・・、Ｂ３０）にそれぞれ３，０００ドルを送信するという指示を、口座処理センターがクライアントから受信するという例に基づくものである。

従来の支払処理は以下のようになる。

１．Ａ→Ｂ１（Ａが口座Ｂ１に対して３，０００ドルを支払う）
ａ）口座Ａのロックを取得するために待機する
ｂ）口座Ａをロックする
ｃ）口座Ｂ１のロックを取得するために待機する
ｄ）口座Ｂ１をロックする
ｅ）口座Ａから３，０００ドルを差し引く
ｆ）口座Ｂ１に３，０００ドルを加算する

２．Ａ→Ｂ２（Ａが口座Ｂ２に対して３，０００ドルを支払う）
ａ）口座Ａのロックを取得するために待機する
ｂ）口座Ａをロックする
ｃ）口座Ｂ２のロックを取得するために待機する
ｄ）口座Ｂ２をロックする
ｅ）口座Ａから３，０００ドルを差し引く
ｆ）口座Ｂ２に３，０００ドルを加算する
・・・

このように、口座Ａを３０回ロックしなければならない。こうした支払処理は非常に時間がかかる。さらに、口座Ａに十分な残高がない場合、ある支払処理でのみこうした情報はわかる。特に、支払用の十分な残高がないことをクライアントがタイムリーに知ることができない場合は、支払処理にかかる時間がさらに長くなる。

本開示に従った適用例での支払処理は以下のようになる。

１．前処理
ａ）要求の分析後、口座Ａから３，０００ドル×３０を差し引くことを計画する
ｂ）口座Ｂ１に３，０００ドルを加算することを計画する
ｃ）口座Ｂ２に３，０００ドルを加算することを計画する
・・・
ｄ）口座Ｂ３０に３，０００ドルを加算することを計画する

２．処理
ａ）口座Ａのロックを取得するために待機する
ｂ）口座Ａから９０，０００ドルを差し引く
ｃ）口座Ｂ１のロックを取得するために待機する
ｄ）口座Ｂ１に３，０００ドルを加算する
ｅ）口座Ｂ２のロックを取得するために待機する
ｆ）口座Ｂ２に３，０００ドルを加算する
・・・
ｇ）口座Ｂ３０のロックを取得するために待機する
ｈ）口座Ｂ３０に３，０００ドルを加算する

こうした前処理により、現在の支払額に対して口座Ａの残高が十分にあるかどうかをタイムリーに判断できるため、支払操作の効率性が向上する。さらに、口座Ａのロックを取得するための待機時間が２９回分も大幅に短縮される。通常、数千倍以上のレベルで時間が短縮される。待機による遅延がなくなるため、システムは他の多くの要求を受信することができる。これにより、システム全体の処理効率も向上する。

以下に結論を記述する。

ここで開示する方式およびシステムは、広く普及しているコンピュータシステムまたは特殊なコンピュータシステムの環境または構成で使用することができる。例としては、パーソナルコンピュータ（ＰＣ）、サーバーコンピュータ、ハンドヘルドデバイスまたは携帯デバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットアップボックス、プログラム式カスタマー電子デバイス、ネットワークＰＣ、小規模コンピュータ、大規模コンピュータ、上記の任意のシステムやデバイスを含む分散コンピューティング環境などがある。

本開示は、コンピュータによって実行されるコンピュータ実行可能指示の一般的なコンテキスト（プログラムモジュールなど）において記述することができる。通常、プログラムモジュールには、特定のタスクを実行するための、または特定の抽象データ型を実装するためのルーチン、プログラム、オブジェクト、モジュール、データ構造などが含まれる。ここで開示する方式とシステムは、分散コンピューティング環境で実装することもできる。分散コンピューティング環境では、通信ネットワーク経由で接続されたリモート処理デバイスによってタスクが実行される。分散コンピューティング環境では、ローカルコンピュータおよびリモートコンピュータのストレージメディア（ストレージデバイスを格納）にプログラムモジュールを配置することができる。

上記は、本開示の好適な典型的実施形態にすぎないが、本開示はこれに限定されるものではない。当業者は、本開示の精神と範囲から逸脱することなく、さまざまな異なる方法で本開示を変更または改修できることを理解されたい。したがって、こうした改修と変更は、本開示の請求項およびそれに相当するものの範囲内に含まれるものとして考える必要がある。

口座について同じタイプの操作をマージ後、本技術は、処理要求の従来の形式に従って、新しい処理要求を作成する。この適用においては、口座Ａについて同じタイプの操作がマージされると、処理要求がシステムに送信される。システム上の処理要求の形式には、口座と取引金額（たとえば、口座Ａ、支払額４０，０００ドルなど）が含まれる。

上記は、本開示におけるいくつかの詳細な実装にすぎないが、本開示を制限する目的でこれらの実装を使用することはできない。当業者による予想される改修は、本開示の保護範囲に含まれる。

Claims (16)

1. 口座処理センターとクライアントとを備え、
   前記口座処理センターが、
   受信した要求からバッチ処理要求を識別するバッチ処理識別ユニットと、
   バッチ処理内の口座に関係するタイプの処理要求の前処理を行い、前記口座のすべての要求タイプを処理用にマージする前処理ユニットと、
   前記前処理の実行後に前記バッチ処理要求を処理し、処理結果を提供する要求処理ユニットと、
   を備え、
   前記クライアントが、
   バッチ処理要求のマーキングを行うバッチ処理ユニットと、
   前記口座処理センターとの相互作用を確立する中央相互作用ユニットと、
   を備える、リアルタイムバッチ口座処理用のシステム。
2. 前記前処理ユニットと前記バッチ処理識別ユニットが前処理サーバーにインストールされ、前記要求処理ユニットが要求処理サーバーにインストールされる、請求項１に記載のシステム。
3. 前記前処理ユニットと前記バッチ処理識別ユニットが前処理モジュールにインストールされ、前記前処理モジュールと前記要求処理ユニットが２つの並行処理ユニットとなる、請求項１に記載のシステム。
4. 前記口座処理センターが、前記バッチ処理識別ユニットと前記前処理ユニットに接続するバッチ処理キャッシュセクションをさらに備える、請求項１に記載のシステム。
5. 前記クライアントが、バッチ処理要求の開始マークと終了マークを格納するバッチ処理マークストレージユニットをさらに備える、請求項１に記載のシステム。
6. 前記クライアントが、前記バッチ処理ユニットに接続し、バッチ処理の指示インターフェースをクライアントに提供し、前記クライアントのバッチ処理要求にバッチ処理用の開始マークと終了マークを追加するために前記バッチ処理要求を前記バッチ処理ユニットに送信するバッチ要求表示インターフェースをさらに備える、請求項５に記載のシステム。
7. 口座処理センターを備え、
   前記口座処理センターが、前処理ユニットと要求処理ユニットとを備え、
   前記前処理ユニットが、
   バッチ処理要求を含む要求をクライアントに送信するためのインターフェースを提供するクライアント相互作用サブユニットと、
   バッチ処理内の口座に関係する処理について要求のタイプの前処理を行い、前記口座の処理についてすべてのタイプの要求をマージする前処理サブユニットと、
   前記前処理後にバッチ処理要求を処理し、処理結果を提供する要求処理ユニットと、
   を備える、リアルタイムバッチ口座処理用のシステム。
8. 前記口座処理センターと前記クライアントとの通信がネットワーク経由で行われる、請求項７に記載のシステム。
9. 前記前処理ユニットが、
   前記クライアントによって入力されたバッチ処理情報を取得し、バッチ処理要求を作成するためのマークを追加するバッチ処理サブユニットと、
   複数の要求からバッチ処理要求を識別するバッチ処理識別サブユニットと、
   を備える、請求項７に記載のシステム。
10. バッチ処理用としてマーキングされた要求を口座処理センターが受信し、
    前記マーキング済み要求をキャッシュし、
    前記マーキング済み要求内の口座に関係するタイプのサブ要求の前処理（口座処理についての操作タイプのマージを含む）を行い、
    前記前処理済みサブ要求を含む前記マーキング済み要求を処理し、処理結果を提供する、
    という各手順を備える、クライアントから送信されたバッチ処理要求のリアルタイム処理を実現するためのリアルタイム口座処理用の方式。
11. バッチ処理用としてマーキングされた前記要求を受信する前に、バッチ処理要求の指示を入力するためのインターフェースを提供し、
    ユーザーからバッチ処理の情報を取得し、
    バッチ処理要求を作成する、
    という各手順をさらに備える、請求項１０に記載の方式。
12. バッチ処理用としてマーキングされた前記要求を受信する前に、前記クライアントがユーザーからのバッチ処理要求を受信し、
    前記クライアントが、前記バッチ処理要求の先頭に開始マークを追加し、
    前記クライアントが、前記バッチ処理要求の最後に終了マークを追加する、
    という各手順をさらに備える、請求項１０に記載の方式。
13. 複数の要求から開始マークと終了マークを識別することにより、バッチ処理用としてマーキングされた前記要求を識別する、請求項１０に記載の方式。
14. 前記前処理を行う際に、
    要求を処理し、処理結果を対応するクライアントに返す手順、または、
    別のバッチ処理要求を処理し、処理結果を対応するクライアントに返す手順、
    のいずれかを同時に実行することをさらに備える、請求項１０に記載の方式。
15. 口座処理についての操作タイプの前記マージ処理が、
    口座のすべての取引額を計算し、
    最終的な取引額を計算する、
    という手順をさらに備える、請求項１０に記載の方式。
16. 前記前処理が、
    口座処理についての操作タイプをマージし、処理要求の形式に従って新しい処理要求を作成する、
    という手順をさらに備える、請求項１０に記載の方式。

Images