JP5698235B2 - 口座並列処理の方法およびシステム - Google Patents

Description

関連特許出願の相互参照
本出願は、２００９年８月７日出願の中国特許出願第２００９１０１６４８８８．１号「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＡＣＣＯＵＮＴ ＰＡＲＡＬＬＥＬ ＰＲＯＣＥＳＳＩＮＧ」の優先権を主張するものであり、その文献は全体が参照により本明細書に援用される。

本開示は、インターネットの分野に関し、詳細には、口座並列処理のシステムおよび方法に関する。

図１に、現行の口座処理システムの原理を示す。口座処理システムは、口座処理センタ１１およびいくつかのクライアント１２を含む。口座処理センタ１１は、専用のラインまたはネットワーク（インターネットまたはイントラネット）を通してクライアント１２と連絡を取ることができる。複数のクライアント１２がいる可能性がある。クライアント１２は、独立した端子またはいくつかの端子から構成されたイントラネットとすることができる。口座処理センタ１１は、少なくともサーバ２１およびデータベース２２を含む。データベース２２は、口座情報および様々な処理情報を格納するように構成されている。サーバ２１は、口座の様々な操作および管理を行うように構成されている。

口座処理センタ１１が第三者支払いプラットフォームである例では、クライアント１２が他のいくつかの口座（口座Ｂ１、Ｂ２、Ｂ３、・・・、Ｂｎなど）に口座Ａの資金を支払うように口座処理センタ１１に指示を送信し、その支払い額がそれぞれＳ１、Ｓ２、Ｓ３、・・・、Ｓｎであるときの、現行の支払い処理を以下に説明する。

まず、口座処理センタ１１は、クライアント１２からの支払い操作に関する要求を受信する。

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

サーバ２１は、口座Ａをロックし、口座Ａの残高が金額Ｓ１よりも多いかどうかを判定する。口座Ａの残高がＳ１よりも多い場合は、サーバ２１は、口座Ａの残高から金額Ｓ１を差し引き、口座Ａをロック解除する。次いで、口座Ｂ１をロックし、金額Ｓ１を口座Ｂ１に追加し、支払い操作の完了後に口座Ｂ１をロック解除する。

したがって、口座処理センタ１１は、その支払いを完了するためにこの操作をｎ回実行する必要がある。

換言すると、口座並列処理が口座の残高に影響を与えるのを防止するために、１回に口座に影響を及ぼす操作は１つのみとすることになっている。これは通常、口座をロックすることによって実現され、例えば、口座に対する全ての操作に、最初に口座をロックできるかどうかを判定することが必要である。ロックできる場合は、同一の口座に対する他の操作が存在しないと見なされ、そのため、その口座に対して現在の操作を実施することができる。そうでない場合は、同一の口座に対する他の操作が存在すると見なされ、そのため、待機が必要になる。複数の待機操作があるときは、待機処理用のキューが形成される。待機処理用のキューの操作ごとに口座のロックおよびロック解除が必要である。サーバは、これらの操作を順次処理することしかできず、したがって、多くのリソースが必要になる。特に、こうした口座（例えば、待機処理用のキューを有する口座）がいくつかあるか、または待機処理用のキューに処理すべき操作が多数ある場合は、システムの崩壊が簡単に起きる恐れがある。データベースの接続の最大数が１００、例えば、並列データアクセスの最大数が１００であると仮定すると、待機処理用のキューに１００の操作があるときは、システム全体が口座操作に関するいかなる新規の要求をも受け取ることができない。したがって、後の新規の口座操作の効率低下がもたらされ、システム全体の崩壊が簡単に起きることになる。

いくつかの予期せぬ事象が存在すると、１つまたは複数の口座に対する異常な操作が生じる。非常に一般的に、予期せぬ事象は口座に対する操作を急激に増加させる。これは、待機処理用のキューの処理すべき操作が急激に増加することから生じ、それにより、システム全体の効率が低下する。

予期せぬ事象のいくつかは、システムの不安定性または技術的理由から生じる。一部は人間が作り出している。例えば、小売商がそれぞれ、オンライン取引き処理における信用格付けを有する。その信用格付けは、その小売商のサービスまたは商品に関するバイヤまたは他のユーザの満足度を表している。ユーザは、オンライン取引きという状況で商品を体験することができず、したがって、信用格付けは小売商にとって非常に重要である。より高い信用格付けを得るために何らかの虚偽の取引きを行うことは信用不正と呼ばれる。いくつかの小売商が小売商の不正のグループを形成するときに、こうした小売商の口座に対して頻繁な操作がある可能性がある。このような操作を処理するためにシステムの多くのリソースが必要になり、他の口座に対する通常の操作が影響を受ける。

換言すると、口座処理センタの現行の口座処理操作は、以下で説明するようないくつかの技術的な落とし穴を有する。

現行の支払い処理は、口座Ａに対して頻繁な操作を必要とする。各操作は、それぞれ操作の前に口座Ａをロックし、操作の完了後に口座Ａをロック解除する必要がある。これはサーバ２１の処理効率を低くするだけでなく、サーバ２１の処理能力を急激に低減させ、そのため、他のクライアントによって送信された処理要求を受信することさえできなくなり、ひどい場合はサーバ２１が崩壊することもある。

具体的には、口座をバッチ処理するために比較的多くの量の要求があるか、またはこうしたバッチ処理で処理すべき多くの口座があるときに、サーバ２１に課される操作負荷が大きくなる。これにより、サーバ２１での処理を要求するキューのトラフィックが簡単に生じ、処理要求の故障率が上昇する恐れがあり、したがって、他のユーザの体験に影響が及ぼされる。

本開示の第１の目的は、予期した事象から生じる同一口座に対する並列操作が増加するとシステム全体の処理効率を低下させる恐れがあるという技術的問題を解決する口座並列処理方法を提供することである。

本開示の第２の目的は、予期した事象から生じる同一口座に対する並列操作が増加するとシステム全体の処理効率を低下させる恐れがあるという技術的問題を解決する口座並列処理システムを提供することである。

口座処理センタによる口座操作の並列処理方法が提供される。その方法は、
（１）口座を並列頻発口座および一般口座として分類することと、
（２）口座を処理するための要求をクライアントから受信するときに、まず口座が並列頻発口座であるかどうかを判定し、口座が並列頻発口座である場合は（３）に進み、そうでない場合は（４）に進むことと、
さらに、
（３）口座がロックされている場合に、現在の操作の実施まで待機するように現在の操作をキューに入れることと、
（４）口座処理センタによって、口座がロックされているかどうかをさらに判定し、口座がロックされている場合はエラーメッセージを出力し、そうでない場合は現在の操作を実施することと
を含むことができる。

ステップ（４）は、口座がロックされているときに、所定の期間遅延させ、次いで現在の操作が実施されるかどうかを再判定し、実施されない場合はエラーメッセージを出力することを含んでもよい。

好ましくは、ステップ（１）は、（Ａ１）全ての口座の中の並列頻発口座の割合に従って並列頻発口座をＱ個設定することと、（Ａ２）所定の期間の各口座のそれぞれの操作数を計算し、それらの各操作数に従って口座をランク付けすることと、（Ａ３）操作数が多い上位Ｑ個の口座を並列頻発口座として使用することとをさらに含んでもよい。さらに、ステップ（１）は、好ましくは、並列頻発口座の口座ＩＤをメモリに保存することを含んでもよい。

ステップ（２）は、口座の口座ＩＤを、メモリに事前に格納した全ての並列頻発口座の口座ＩＤと比較することを含んでもよい。合致する場合は、その口座は並列頻発口座であり、そうでない場合はその口座は一般口座である。

現在の操作を実施することは、口座をロックすることと、その口座に対して操作を実施することと、操作の実施の後にその口座の対応するロックを解除することとをさらに含んでもよい。

口座処理センタを含む口座並列処理システムを提供する。その口座処理センタは、全ての並列頻発口座の情報を保存するように構成された並列頻発口座データベースと、口座の操作を処理するための要求を受信するときに、並列頻発口座データベースに従って口座が並列頻発口座であるかどうかを判定するように構成された口座特徴判定装置と、口座がロックされているかどうかをさらに判定し、口座がロックされている場合は現在の操作を実施するまで待機するように待機処理用のキューに現在の操作を割り当て、口座がロックされていない場合は現在の操作をすぐに実施するように構成された並列頻発口座処理装置と、口座がロックされているかどうかを判定し、口座がロックされている場合はエラーメッセージをすぐに出力して戻し、ロックされていない場合は現在の操作を実施するように構成された一般口座処理装置と、を含んでもよい。

並列頻発口座装置は、並列頻発口座がロックされているかどうかを判定するように構成された並列頻発口座ロック判定サブユニットと、口座をロックし、その口座の操作を実施し、その口座の対応するロックを解除するように構成された操作実施サブユニットとをさらに含んでもよい。

一般口座処理装置は、口座がロックされているかどうかを判定するように構成された一般口座ロック判定サブユニットと、口座をロックし、その口座の操作を実施し、その口座の対応するロックを解除するように構成された操作実施サブユニットと、口座がロックされた後で口座の操作を受信し、エラーメッセージをすぐに出力し戻すように構成されたロック判定サブユニットとをさらに含んでもよい。

クライアントが提出した口座操作の要求を処理するために口座処理センタによって利用される口座並列処理方法を提供する。その方法は、
（１）口座を口座処理センタによって異なるタイプの口座として分類し、口座がロックされた後でそれぞれのタイプの口座ごとに処理操作を設定することと、
（２）口座に対する操作を処理するためのクライアントからの要求を受信したときにまず口座のタイプを判定することと、
（３）口座処理センタによって、口座がロックされているかどうかをさらに判定し、口座がロックされている場合は、口座のタイプに対応する処理操作の流れに従って口座がロックされた後の操作を行い、ロックされていない場合は現在の操作を実施することと
を含んでもよい。

ステップ（１）では、各タイプの口座ごとに口座がロックされた後で操作を設定することは、
（Ａ１）口座がロックされた後で、数Ｍがゼロかどうかを判定し、ゼロの場合は、エラーメッセージをすぐに出力して戻し、ゼロでない場合は、待機時間Ｔの後に口座がロックされているかどうかを判定することをさらに含んでもよい。口座がロックされている場合は、数Ｍを１だけ減らし、ステップ（Ａ１）に続き、口座がロックされていない場合は、現在の操作を実施する。ここで、Ｍは、各タイプの口座ごとに設定される待機回数であり、その範囲はゼロと無限大との間である。

現行の技法と比較すると、本開示は、以下で説明するようにいくつかの利点を有する。

一般口座に関しては、口座にビジネス上の取引き業務があるのが普通であり、通常は期間中の固定様式がある。ビジネスプラットフォームの例のように、１日に共通のバイヤのビジネスの量は限られている。毎日多すぎるほどの取引き業務があるはずがない。換言すると、口座の並行取引き業務の可能性は高くない。口座に大量の取引き業務がある場合は、違法の取引き業務である可能性が非常に高い。しかし、大規模な売り手に関しては、多くの並行取引き業務がある可能性が非常に高い。多くのバイヤがその売り手の商品を購入し、これは多くの並行取引き業務につながる。こうした特徴に従って、本出願人は、口座を２つのタイプ、並列頻発口座および一般口座に分類する。並列頻発口座に関しては、口座残高に変化があり、口座がすでにロックされていると分かっている間にその口座をロックする必要があるときに、システムは、エラーメッセージを戻すことなしに待機を維持する。しかし、一般口座の口座残高に変化があり、口座がすでにロックされていると分かっている間に口座をロックする必要があるときに、システムはエラーメッセージをすぐに戻す。こうした方法は、並列頻発口座により質の高いサービスを提供する。一般の顧客に関しては、一般口座で同じ日に多量の並行取引き業務があるときに、並行処理の発生数を、エラーを出力することによって効果的に制御することができ、こうした口座がシステムに損傷を与えるのを防止する。

さらに、本開示により、一般口座の操作に関する要求があり、かつ一般口座がすでにロックされているときに、システムは、所定の長さの時間だけ延期し、次いで、現在の操作を実施できるかどうかを判定する。実施できない場合は、システムがエラーメッセージをすぐに出力し、結果を返す。このような延期された処理により、一般口座で並列処理の間違ったメッセージの可能性のある割合を低減することができる。

現行の口座処理システムを示す図である。 本開示による口座処理センタの例示的実施形態を示す図である。 本開示による口座並列処理方法を示すフローチャートである。 本開示による口座並列処理方法を示す別のフローチャートである。

図を参照しながら以下の詳細な説明を示す。

図２に、口座並列処理に関するシステムの例示的実施形態を示す。図１を参照すると、図２のシステムは、口座処理センタ１１およびクライアント１２を含む。クライアント１２は、口座処理センタ１１で１つまたは複数の口座に操作の要求を提出し、口座処理センタ１１から戻ってきた処理結果を受け取る。

口座処理センタ１１はさらに、サーバ３１およびデータベース３２を含む。データベース３２は、口座情報および様々な処理情報を格納するように構成される。サーバ３１は、口座の様々な操作および管理を行うように構成される。本開示では、口座情報を格納するように構成された口座格納装置３２１と、口座処理操作記録情報を格納するように構成された口座操作記録格納装置３２２に加えて、データベース３２は並列頻発口座データベース３２３も含む。並列頻発口座データベース３２３は、並列頻発口座の全ての情報を格納するように構成される。

並列頻発口座の情報は、主として並列頻発口座を一意的に識別する口座ＩＤを照会する。本開示は、様々なルールに従って口座処理センタ１１の並列頻発口座を指定することができる。例えば、重要な口座を並列頻発口座として指定することができる。口座処理センタ１１は、ある期間のそれぞれの口座操作の数に従って、頻度が高いものから低いものまで口座をランク付けすることもでき、大量の操作を伴う上位複数の口座が並列頻発口座として扱われる。

サーバ３１はさらに、口座特徴判定装置３１１、並列頻発口座処理装置３１２、および一般口座処理装置３１３を含む。

口座特徴判定装置３１１は、操作を処理するための要求を口座から受け取った後で、並列頻発口座データベース３２３に従って、口座が並列頻発口座であるかどうかを判定するように構成される。並列頻発口座である場合は、口座特徴判定装置３１１は並列頻発口座処理装置３１２を起動する。並列頻発口座でない場合は、口座特徴判定装置３１１は一般口座処理装置３１３を起動する。

並列頻発処理装置３１２は、口座がロックされているかどうかをさらに判定するように構成される。口座がロックされている場合は、並列頻発口座処理装置３１２は、現在の操作の実施まで待つように待機処理用のキューに現在の操作を割り当てる。ロックされていない場合は、並列頻発口座処理装置３１２は、現在の操作をすぐに実施する。

並列頻発処理装置３１２は、並列頻発口座ロック判定サブユニット３１２１、待機処理キュー管理サブユニット３１２２、および操作実施サブユニット３１２３をさらに含む。

並列頻発口座ロック判定サブユニット３１２１は、並列頻発口座がロックされているかどうかを判定するように構成される。

待機処理キュー管理サブユニット３１２２は、待機処理用のキューの操作を管理するように構成される。待機処理用のキューの操作の管理は、先入れ先出し原理または優先順位原理などのような、それらの操作の処理を扱うことを含む。いくつかのシステムは、ユーザが管理サブユニットを手動で設定する必要がないような管理サブユニット３１２２を有する。

操作実施サブユニット３１２３は、口座をロックし、その口座に対して操作を実施し、次いで、その口座に対応するロックを解除するように構成される。

一般口座処理装置３１３は、口座がロックされているかどうかを判定するように構成される。口座がロックされている場合は、一般口座処理装置３１３は、エラーメッセージをすぐに出力し、戻す。ロックされていない場合は、一般口座処理装置３１３は、現在の操作を実施する。一般口座処理装置３１３は、一般口座ロック判定サブユニット３１３１、操作実施サブユニット３１３２、およびロック処理サブユニット３１３３をさらに含む。

一般口座ロック判定サブユニット３１３１は、並列頻発口座がロックされているかどうかを判定するように構成される。

操作実施サブユニット３１３２は、口座をロックし、その口座の操作を実施し、次いで、その口座に対応するロックを解除するように構成される。

ロック処理サブユニット３１３３は、口座がロックされた後で口座の操作を受信し、エラーメッセージを出力する操作を受け取り、戻すように構成される。

一実施形態では、一般口座処理装置３１３は、時間遅延サブユニット３１３４も含む。時間遅延サブユニット３１３４は、口座がロックされる時期を所定の期間延期し、次いで現在の操作が実施されるかどうかを再判定するように構成される。実施されない場合は、時間遅延サブユニット３１３４は、エラーメッセージをすぐに出力し、戻す。

上記で開示した装置は、論理装置についてのみ言及し、これは通常ソフトウェアの形態で実装される。しかし、本開示は、ハードウェアの形態での実装を除外しない。

図３に、口座処理センタで口座操作を処理するために使用される、口座並列処理方法のフローチャートを示す。この方法は、以下で説明する複数の動作を含む。

Ｓ１１０：口座を並列頻発口座および一般口座として分類すること。一実施形態では、口座処理センタ１１では多くの現行の口座がすでに存在する。したがって、並列頻発口座データベース３２３は、並列頻発口座情報を格納するようにさらに設定される。口座が並列頻発口座であるか一般口座であるかを判定するために、並列頻発口座データベース３２３の検索を実行することができる。この方法は、現在の口座情報を修正する必要はなく、したがって、現在のシステムの安定性への影響が低減される。別の実施形態では、口座の特徴属性項目を設けることができる。各口座は、それぞれの口座の属性を、口座が並列頻発口座であるか一般口座であるかを示すその特徴属性項目に記憶する。こうした手法は、実現可能であるが、現在の口座の修正を必要とするので時間効率が良くない可能性がある。

口座を並列頻発口座および一般口座に分類するために、以下の動作を実施することができる。

Ａ１：全ての口座の中の並列頻発口座の割合に従って並列頻発口座をＱ個設定する。
Ａ２：所定の期間（例えば１週間など）内の口座ごとの操作数を計算し、操作数に従って口座をランク付けする。
Ａ３：多くの操作を伴う上位Ｑ個の口座を並列頻発口座として指定し、これらの並列頻発口座の情報を並列頻発口座データベース３２３に格納する。

さらに、その方法はまた、操作数に従って並列頻発口座データベース３２３中の並列頻発口座の情報を定期的に更新する。この方法によってより多くの数の操作を伴う口座を見つけることができる。

その後の処理効率を向上させるために、並列頻発口座データベース３２３の全ての並列頻発口座の口座ＩＤをサーバ３１のメモリに保存することができる。

Ｓ１２０：操作を処理するための要求を口座から受信するときに、まずその口座が並列頻発口座であるかどうかを判定し、並列頻発口座である場合はＳ１３０に進み、並列頻発口座でない場合はＳ１４０に進む。

本開示は、口座が並列頻発口座であるかどうかを判定するために以下のステップを利用する。

口座の口座ＩＤを、メモリまたは並列頻発口座データベース３２３に事前格納された全ての並列頻発口座の口座ＩＤと比較する。比較結果により同一であることが示された場合は、そのような口座は並列頻発口座である。そうでない場合はその口座は一般口座である。

Ｓ１３０：口座がロックされているかどうかを判定する。ロックされている場合は、現在の操作の実施まで待機するように現在の操作を待機処理用のキューに割り当て（Ｓ１３１）、ロックされていない場合は、現在の操作を口座に実施する（Ｓ１３２）。

Ｓ１４０：口座がロックされているかどうかをさらに判定する。ロックされている場合は、エラーメッセージを出力し、戻し（Ｓ１４１）、ロックされていない場合は、現在の操作を実施する（Ｓ１３２）。

Ｓ１３０の動作は、「ｓｅｌｅｃｔ ＊ ｆｒｏｍ ａｃｃｏｕｎｔ ｗｈｅｒｅ ａｃｃｏｕｎｔＮｏ＝‘ＸＸＸＸＸ’ ｆｏｒ ｕｐｄａｔｅ」など、Ｏｒａｃｌｅによって実現することができる。

こうしたコーディングは、口座番号がＸＸＸＸＸである口座に対して操作を実行することを示す。こうした指示は、「ｓｅｌｅｃｔ ＊ ｆｒｏｍ ａｃｃｏｕｎｔ ｗｈｅｒｅ ａｃｃｏｕｎｔＮｏ＝‘ＸＸＸＸＸ’ ｆｏｒ ｕｐｄａｔｅ ｗａｉｔ」を意味する。

換言すると、口座がロックされているときは、システムは、システムが操作を実施できるときまで待機する。

動作Ｓ１４０は、「ｓｅｌｅｃｔ ＊ ｆｒｏｍ ａｃｃｏｕｎｔ ｗｈｅｒｅ ａｃｃｏｕｎｔＮｏ＝‘ｙｙｙｙｙ’ ｆｏｒ ｕｐｄａｔｅ ｎｏｗａｉｔ」など、Ｊａｖａ（登録商標）によって実現することもできる。

こうしたコーディングは、口座に対して操作を実行するときに口座がロックされていることが判明した場合に、システムがエラーメッセージを出力することを示す。上記の記述は、本開示の実施形態であり、本開示を限定するために用いられるものではない。本開示の概念を実現するどの実施方法も本開示の保護範囲内に包含されるものとする。

現在の操作を実施することはさらに、口座をロックすることと、その口座に対して操作を実施することと、操作の実施後にその口座に対応するロックを解除することとをさらに含む。

図４に、別の口座並列処理方法のフローチャートを示す。

この実施形態では、動作Ｓ２４０は図３の動作１４０とは異なる。他の動作は、概して図３の動作と同様である。

Ｓ１１０：口座を並列頻発口座および一般口座として分類する。

Ｓ１２０：操作を処理するための要求を口座から受信したときに、まずその口座が並列頻発口座であるかどうかを判定する。並列頻発口座である場合はＳ１３０に進み、並列頻発口座でない場合はＳ２４０に進む。

Ｓ１３０：口座がロックされているかどうかを判定する。ロックされている場合は、現在の操作の実施まで待機するように現在の操作を待機処理用のキューに割り当て（Ｓ１３１）、ロックされていない場合は、現在の操作を口座に実施する（Ｓ１３２）。

Ｓ２４０：口座がロックされているかどうかをさらに判定する。口座がロックされている場合は、所定の時間待機した（Ｓ２４１）後に、現在の操作が実施されるかどうかをさらに判定する（Ｓ２４２）。実施されない場合は、エラーメッセージをすぐに出力し、戻し（Ｓ２４３）、実施される場合は、現在の操作を実施する（Ｓ１３２）。口座がロックされていない場合は、現在の操作を実施する（Ｓ１３２）。

口座のロックを実施する多くの方法がある。例えば、１つの一般的な方法は、口座のフラグビットを設定することである。フラグビットが１のときは、口座がロックされていることを表す。フラグビットが０のときは、口座がロックされていないことを表す。口座がロックされているかどうかは、フラグビットを判定することによって判定される。

この実施形態では、一般口座に対する操作に関する要求を受信するときに、その口座に対する現行の操作がある場合は、要求された操作は、操作が実施されるか否かを判定する前に所定の時間延期する。それにより、一般口座に対する並列処理の可能性のあるエラー報告率を低減させることができる。

本開示の実施形態は、口座を並列頻発口座および一般口座として分類する。実際には、本開示のこの実施形態によって限定されることなく、口座を、第１タイプの口座、第２タイプの口座、第３タイプの口座、・・・、第ｎタイプの口座など、複数のタイプに分けることができる。それを以下の詳細な動作によって実施することができる：
Ａ１：全ての口座の中の第１タイプの口座の割合に従って、第１タイプの口座をＱ１個設定し、全ての口座のうちの第２タイプの口座の割合に従って、第２タイプの口座をＱ２個設定し、等々を第ｎタイプの口座をＱｎ個設定するまで続ける。
Ａ２：所定の期間（例えば１週間など）内の各口座ごとの操作数の統計を取り、操作数に従って口座をランク付けする。
Ａ３：最も少ない操作数を伴う上位Ｑ１個の口座を第１タイプの口座として指定し、次に少ないＱ２個の口座を第２タイプの口座として指定し、等々を様々なタイプの口座の情報を得るまで続け、様々なタイプの口座の情報をデータベースに格納する。

口座を複数のタイプに分類するために、以下の動作を利用することができる。
Ｂ１：全ての口座のうちの第１タイプの口座、第２タイプの口座、・・・、および第ｎタイプの口座のそれぞれの割合を予め設定する。
Ｂ２：所定の期間（例えば１週間など）内の各口座ごとの操作数を計算し、それらの操作数に従って口座をランク付けする。
Ｂ３：現在の合計口座数Ｍを計算する。
Ｂ４：各タイプの口座のそれぞれの割合および合計口座数Ｍに従って、各タイプの口座のそれぞれの数を計算する。
Ｂ５：口座の対応するそれぞれの数を各タイプの口座に割り当て、このような口座の情報を対応するデータベースに保存する。

この実施形態の処理概念は以下の通りである。口座を第１タイプの口座、第２タイプの口座、第３タイプの口座、・・・および第ｎタイプの口座に分類し、異なるタイプの口座に対して異なる処理方針を設定する。例えば、異なるタイプの口座に、異なる優先順位を与えることができる。優先順位がより高い場合は、それぞれの口座がロックされているときに所定の待機期間はより長くなる。

例えば、処理方針は以下の通りとすることができる。第１タイプの口座に関しては、口座がロックされているときに、システムはエラーメッセージをすぐに出力し、戻す。第２タイプの口座に関しては、口座がロックされているときに、システムは所定の時間待機し、次いで、口座がロックされているかどうかを判定し、口座が未だロックされている場合は、システムは、エラーメッセージを出力し、戻す。第３タイプの口座に関しては、口座がロックされているときに、システムは、所定の時間Ｔだけ待機し、次いで、口座がロックされているかどうかを判定する。口座が未だロックされている場合は、システムはさらに所定の時間Ｔだけ待機する。その後、口座が未だロックされている場合は、システムはエラーメッセージを出力し、戻す。異なるタイプの口座について異なる処理方針を定めることができ、以下同様である。

口座を、上記のように異なるタイプに分類する。異なる処理方針を各タイプの口座ごとに設定する。

換言すると、本開示は、クライアントが送信する口座操作に関する要求を処理するために口座処理センタによって利用される口座並列処理方法も提供する。その方法は、以下で説明する動作を含む。
（１）口座を口座処理センタによって異なるタイプの口座に分類し、口座がロックされた後で口座の各タイプごとに操作を設定する。
（２）口座に対して操作を実行するためのクライアントからの要求を受信するときに、まず口座のタイプを判定する。
（３）口座処理センタによって、口座がロックされているかどうかをさらに判定し、口座がロックされている場合は、口座がロック解除された後で口座のタイプに対応する処理操作の流れに従って操作を実行する。

動作（１）では、各タイプの口座ごとに口座がロックされた後で操作を設定することは、
Ａ１：口座がロックされた後で、数Ｍがゼロかどうかを判定し、ゼロの場合は、エラーメッセージをすぐに出力して戻し、ゼロでない場合は、待機時間Ｔの後に口座がロックされているかどうかを判定することをさらに含む。口座が未だロックされている場合は、数Ｍを１だけ減らし動作Ａ１に進み、口座がロックされていない場合は、現在の操作を実施する。ここで、
Ｍは、各タイプの口座ごとに設定される待機回数であり、その範囲はゼロと無限大との間である。

上記は、本開示のいくつかの実施形態であるが、本開示を限定するために用いられるものではない。当業者によって開示された実施形態のどんな予測可能な変更も、やはり本開示の保護範囲内に包含される。

Claims (12)

1. 口座に対する操作を処理するようにクライアントによって提出された要求を処理するために口座処理センタによって利用される口座並列処理方法であって、前記口座処理センタを備える口座並列処理システムが、
   所定の期間の各口座のそれぞれの操作数に従って、口座を並列頻発口座および一般口座として分類するステップと、
   前記口座を処理するための前記クライアントからの前記要求を受信する際に、前記口座が並列頻発口座であるかどうかを判定するステップと、
   前記口座が並列頻発口座であると判定されたときに、
   前記口座処理センタによって、前記口座がロックされているかどうかを判定するステップと、
   前記口座がロックされていると判定されるときに、現在の操作の実施まで待機するように現在の操作をキューに入れるステップと、
   前記口座がロックされていないと判定されるときに、前記現在の操作を実施するステップと、
   前記口座が並列頻発口座でないと判定されたときに、
   前記口座処理センタによって、前記口座がロックされているかどうかを判定するステップと、
   前記口座がロックされていると判定されるときに、エラーメッセージを出力するステップと、
   前記口座がロックされていないと判定されるときに、前記現在の操作を実施するステップと
   を含むことを特徴とする方法。
2. 前記口座が並列頻発口座でないと判定され、さらに前記口座がロックされていると判定されるときに、所定の期間遅延させ、次いで前記現在の操作が実施されるかどうかを再判定するステップをさらに含み、
   実施されない場合に、エラーメッセージを出力することを特徴とする請求項１に記載の方法。
3. 口座を並列頻発口座および一般口座として分類するステップが、
   全ての口座のうちの並列頻発口座の割合に従って、並列頻発口座をＱ個設定するステップと、
   所定の期間の各口座のそれぞれの操作数を計算し、それぞれの操作数に従って口座をランク付けするステップと、
   最も多くの操作数を伴う上位Ｑ個の口座を前記並列頻発口座として指定するステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
4. 口座を並列頻発口座および一般口座として分類するステップが、並列頻発口座の口座識別表示をメモリに保存するステップを含むことを特徴とする請求項１に記載の方法。
5. 前記口座を処理するための前記クライアントからの前記要求を受信する際に、前記口座が並列頻発口座であるかどうかを判定するステップが、
   前記口座の口座識別表示を、前記メモリに格納された全ての並列頻発口座の口座識別表示と比較するステップを含み、
   前記口座の前記口座識別表示と、全ての前記並列頻発口座の前記口座識別表示のうちの１つとが合致するときに、前記口座が並列頻発口座と判定され、合致しない場合は前記口座が一般口座と判定されることを特徴とする請求項４に記載の方法。
6. 前記現在の操作を実施するステップが、
   前記口座をロックするステップと、
   前記口座に対して操作を実施するステップと、
   前記操作が実施された後で前記口座の対応するロックを解除するステップと
   を含むことを特徴とする請求項１に記載の方法。
7. 口座処理センタを備える口座並列処理システムであって、
   前記口座処理センタは、
   全ての並列頻発口座の情報を格納する並列頻発口座データベースと、
   前記口座を処理する要求を受信するときに、前記並列頻発口座データベースに従って口座が並列頻発口座であるかどうかを判定する口座特徴判定装置と、
   前記口座が並列頻発口座であると判定されたときに、前記口座がロックされているかどうかを判定し、前記口座がロックされているときは、現在の操作を、前記現在の操作の実施まで待機するように、キューに入れ、前記口座がロックされていないときは前記現在の操作を実施する、並列頻発口座処理装置と、
   前記口座が並列頻発口座でないと判定されたときに、前記口座がロックされているかどうかを判定し、前記口座がロックされているときはエラーメッセージを出力し、前記口座がロックされていないときは前記現在の操作を実施する、一般口座処理装置と
   を備えることを特徴とする口座並列処理システム。
8. 前記並列頻発口座処理装置が、
   前記並列頻発口座がロックされているかどうかを判定する並列頻発口座ロック判定サブユニットと、
   前記口座をロックし、前記口座に対して１つまたは複数の操作を実施し、前記口座のロックを解除する、操作実施サブユニットと
   を備えることを特徴とする請求項７に記載のシステム。
9. 前記一般口座処理装置が、
   前記口座がロックされているかどうかを判定する一般口座ロック判定サブユニットと、
   前記口座をロックし、前記口座に対して１つまたは複数の操作を実施し、前記口座に対して対応するロックを解除する、操作実施サブユニットと、
   前記口座がロックされた後で前記口座の操作を受信し、エラーメッセージを出力するロック判定サブユニットと
   を備えることを特徴とする請求項７に記載のシステム。
10. 前記一般口座処理装置が、
    前記口座がロックされているとき、所定の期間延期し、前記現在の操作が実施されるかどうかを再判定し、実施されない場合はエラーメッセージを出力する、時間遅延サブユニットをさらに備えることを特徴とする請求項９に記載のシステム。
11. クライアントによって提出される口座操作に関する要求を処理するために口座処理センタによって実施される口座並列処理方法であって、前記口座処理センタを備える口座並列処理システムが、
    口座を前記口座処理センタによって異なるタイプの口座に分類し、それぞれの口座がロックされた後で各タイプの口座に対する操作の処理を確立するステップと、
    前記口座を処理するための前記クライアントからの前記要求を受信するのに応答して前記口座のタイプを判定するステップと、
    前記口座処理センタによって、前記口座がロックされているかどうかを判定するステップと、
    前記口座がロックされているときは前記口座の前記タイプに対応する処理操作に従って、前記口座を処理し、ロックされていない場合は現在の操作を実施するステップと
    を含むことを特徴とする方法。
12. それぞれの口座がロックされた後で各タイプの口座に対する操作の処理を確立するステップが、
    Ｍがゼロであるときは、前記口座がロックされた後で、エラーメッセージを出力し、前記口座がロックされているかどうかをさらに判定する前に時間Ｔだけ待機するステップと、
    前記口座がロックされているとさらに判定されるときには、Ｍを１だけ減らし、そうでない場合は前記現在の操作を実施するステップと
    を含み、
    Ｍがそれぞれのタイプの口座に対して設定される待機回数であり、Ｍは包括的にゼロと無限大との間の数とすることができることを特徴とする請求項１１に記載の方法。

Images