(57)【要約】  方法およびシステムは、ユーザが次の決算日まで待つことなく口座情報を見るように、バッファされた簿記を使用してタイムリーに口座を更新する。方法は、要求イベントを記録して、多量の並列トランザクションを有する口座に対する要求イベントのバッファ記録を生成し、次の決算日を待たずに口座内の要求イベントの簿記のために、所定の時間間隔で、または再帰的に、一定の間隔でバッファ記録を取り出し、処理する。口座内のトランザクション資金は、問い合わせのために利用可能とされ、トランザクションの発生後の短期間後すぐにアクセス可能となる。遅延の長さは、口座の並列トランザクションのレベルに従って設定可能である。
2011527057.tif 000002
【特許請求の範囲】
【請求項１】
金融トランザクションを伴う口座のコンピュータ化された簿記のための方法であって、
複数の要求イベントを記録して、多量の並列トランザクションを有する口座に対する要求イベントのバッファ記録を生成するステップと、
次の決算日を待たずに前記口座内の前記要求イベントの簿記のための前記バッファ記録を取り出し、処理するステップであって、前記簿記は、簿記情報を前記口座に記録するステップと、前記勘定残高を更新するステップと、を含む、ステップ
からなる方法。
【請求項２】
前記バッファ記録を取り出し、処理するステップは、所定の時間間隔で行われる、請求項１に記載の方法。
【請求項３】
前記バッファ記録を取り出し、処理するステップは、再帰的に行われる、請求項１に記載の方法。
【請求項４】
前記バッファ記録を処理するステップは、
前記バッファ記録を、別のそれぞれの口座から送出される要求イベントを各々が含有する複数の記録に分割するステップと、
処理スレッドを前記複数の記録の各々に配属して、バックグラウンドで前記複数の記録を処理するステップ
からなる請求項１に記載の方法。
【請求項５】
前記バッファ記録を処理するステップは、
リソースロックを多量の並列トランザクションを有する前記口座に掛けるステップと、
前記簿記情報を記録するステップと、前記口座を更新するステップを含む、簿記を行うステップと、
前記リソースロックを解除するステップ
からなる請求項１に記載の方法。
【請求項６】
前記バッファ記録を、前記バッファ記録が処理された後に削除するステップ、
をさらに含む、請求項１に記載の方法。
【請求項７】
前決算日の簿記情報を毎日照合し、確認するステップ、
をさらに含む、請求項１に記載の方法。
【請求項８】
前記前決算日から処理されていない任意の残りのバッファ記録を、前記前決算日の前記簿記情報を照合し、確認する前に取り出し、処理するステップ、
をさらに含む、請求項７に記載の方法。
【請求項９】
要求イベントを記録するステップは、複数の要求イベントを各々が含む複数のバッファ記録を生成するように継続的に行われ、
次の決算日を待たずに前記口座内の前記要求イベントの簿記のための前記複数のバッファ記録を連続して取り出し、処理するステップ、
をさらに含む、請求項１に記載の方法。
【請求項１０】
金融トランザクションを伴う口座のコンピュータ化された簿記のための方法であって、
第１の口座および複数の第２の口座を確立するステップであって、前記第１の口座は、前記複数の第２の口座内の多量の並列トランザクションを有する、ステップと、
前記複数の第２の口座の１つまたはそれ以上に代わって開始される複数の要求イベントを受け取るステップと、
前記要求イベントが、前記要求イベントを開始した前記それぞれの第２の口座の簿記のために行われる際、前記要求イベントの各々を処理するステップと、
前記複数の要求イベントを記録して、前記第１の口座に対する要求イベントのバッファ記録を生成するステップと、
次の決算日を待たずに前記第１の口座内の前記要求イベントの簿記のための前記バッファ記録を取り出し、処理するステップであって、前記簿記は、簿記情報を前記口座に記録するステップと、前記勘定残高を更新するステップと、を含む、ステップ
からなる方法。
【請求項１１】
要求イベントを受け取るステップと、要求イベントを記録するステップは、複数の要求イベントを各々が含む複数のバッファ記録を生成するように継続的に行われ、
次の決算日を待たずに前記第１の口座内の前記要求イベントの簿記のための前記複数のバッファ記録を連続して取り出し、処理するステップ、
をさらに含む、方法。
【請求項１２】
前記複数のバッファ記録を連続して取り出し、処理するステップは、
前記複数のバッファ記録を１つずつ所定の時間間隔で取り出し、処理するステップ、
を含む、請求項１１に記載の方法。
【請求項１３】
前記複数のバッファ記録を連続して取り出し、処理するステップは、
前記複数のバッファ記録を１つずつ再帰的に取り出し、処理するステップ、
を含む、請求項１１に記載の方法。
【請求項１４】
金融トランザクションを伴う口座のコンピュータ化された簿記のためのシステムであって、
第１の口座および複数の第２の口座を保存する保存庫であって、前記第１の口座は、前記複数の第２の口座との多量の並列トランザクションを有する、保存庫と、
前記複数の第２の口座の１つまたはそれ以上に代わって開始される複数の要求イベントを記録して、前記第１の口座に対する要求イベントのバッファ記録を生成するために適合されるバッファ保存ユニットと、
次の決算日を待たずに前記第１の口座内の前記要求イベントの簿記のための前記バッファ記録を取り出し、処理するようにプログラムされる簿記ユニットであって、前記簿記は、簿記情報を前記口座に記録するステップと、前記勘定残高を更新するステップとを含む、簿記ユニット
からなるシステム。
【請求項１５】
前決算日から処理されていない任意の残りのバッファ記録を取り出し、処理し、前記前決算日の前記簿記情報を照合し、確認するためにプログラムされる照合／確認ユニット、
をさらに含む、請求項１４に記載のシステム。
【請求項１６】
前記簿記ユニットは、前記バッファ保存ユニットからの前記バッファ記録を所定の時間間隔で、または再帰的に取り出し、処理するために適合される、請求項１４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、２００８年７月４日出願の中国特許出願、出願第２００８１０１３３０１８．３号、表題「バッファされた簿記のための方法およびシステム」からの優先権を主張する。
【背景技術】
【０００２】
本開示は、データ処理技術に関し、特に、コンピュータ化された簿記のための方法およびシステムに関する。
【０００３】
資金が１つの口座から別の口座へ振り替えられる会計過程の間に、両口座は、簿記過程を伴う。簿記過程は、主に２つの部分を含み、一方は簿記証明書記録であり、他方は勘定残高更新である。
【０００４】
簿記の例は、取引過程、特に簿記要求のイベントに関連するものにおいて見られる。リソースロックが、まず取引に関連する口座（その口座は、買主の支払口座および売主の受取口座を含んでもよい）に掛けられ、データの正確性が、他の要求によって影響されないことを確実にする。その後、簿記証明書記録および残高更新を含む支払口座の簿記が行われ、その後、簿記証明書記録および残高更新を含む受取口座の簿記が行われる。簿記要求イベントが完全に処理されると、リソースロックは、共に解除される。
【０００５】
概して、当該の口座は、他の操作が現在処理されている口座に対してさらに行われること、およびデータの不一致を引き起こすことを回避するために、各簿記操作においてロックされる必要がある。ロックは、並列実行制御を実現するための一次的方法である。取引量が増加するにつれて、ある口座は、同時に複数の並列操作を有し得る。しかしながら、すべての並列スレッドのうちの１つのスレッドのみが、一度にリソースロックを処理することができるが、他のスレッドは、適宜に簿記を行うためにロックが解除されるまで、待たなければならない。こうした状況の下、請求システムの機能性は、深刻な影響を受ける。
【０００６】
例えば、数千の宝くじ購入者が、同時に宝くじの口座へ支払う可能性があり、その瞬間に宝くじの口座に対する並んだ数千の要求が生じる。各要求が処理される前にロック権を得る必要がある場合、他のトランザクションのシステムの処理は、深刻な影響を受ける可能性がある。
【０００７】
１つの既存の解決策は、バッファ機構を使用することである。既存のバッファ機構は、受取口座の簿記操作に対して仕訳帳をつけるのみ（例えば、一時的に記帳証明書を記録する）であるが、勘定残高の更新を延期する。すなわち、既存のバッファ機構は、正確な簿記操作を行わずに、口座に対する関連簿記要求の中間処理を行う。この中間処理は、口座のロックを必要とせず、そのため、単一のリソースの多量の並列トランザクション要求を満たすことができ、他の関連トランザクションが通常に行われることを確実にする。
【０００８】
口座の残高を更新することに関して、勘定残高は、口座の毎日の簿記更新により毎日集約される。決算日の最後に、システムは、口座の決算日の簿記仕訳帳に基づいて勘定残高を集約する。具体的には、勘定残高は、各決算日の最後に更新される。決算日の境界線は、所定の時点、例えば、決算日が２１：００から次の暦日の約２０：５９へ延期される場合は２１：００、によって定義される。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
基本的に、既存の技術は、一時的に多量の並列要求をバッファし、その後、他のトランザクションの通常操作に影響を与えないように、バッファに記録される要求を連続的に処理する。既存の技術は、また、徐々に処理するために、ピークの間隔内のデータを複数の時間間隔へ広げることによって、システムの処理圧力を分布する。しかしながら、本技術には問題が存在する。ユーザはリアルタイムで支払明細を照合することが可能であるが、明細は、正確な残高が次の決算日まで反映されないため、本当の勘定残高と相関しない。したがって、現在の残高が支払明細の合計と同等である必要があるユーザ口座照合に対する残高規則は満たされない。さらに、ユーザによって受け取られる資金は、次の決算日まで見ることもできず、使用することもできない。例えば、ある口座は、１０のトランザクションに関連する資金を受け取ったかもしれないが、実際に資金にアクセスするためには、次の決算日までさらに待つ必要がある。
【課題を解決するための手段】
【００１０】
ユーザが次の決算日まで待つことなく口座情報を見られるように、バッファされた簿記を使用してタイムリーに口座を更新する方法およびシステムを開示する。この方法は、要求イベントを記録して、多量の並列トランザクションを有する口座に対する要求イベントのバッファ記録を生成し、次の決算日を待たずに口座内の要求イベントの簿記のために、所定の時間間隔で、または再帰的にバッファ記録を取り出し、処理する。口座内のトランザクション資金は、問い合わせのために利用可能とされ、トランザクションの発生から短期間後すぐにアクセス可能となる。遅延の長さは、口座の並列トランザクションのレベルに従って設定可能である。
【００１１】
一実施形態では、方法は、バッファ記録を、別のそれぞれの口座から送出される要求イベントをそれぞれ含有する複数の記録に分割し、処理スレッドを複数の記録のそれぞれに配属して、バックグラウンドでこの複数の記録を処理する。
【００１２】
バッファ記録の処理は、リソースロックを、多量の並列トランザクションを有する口座に掛けるステップ、簿記を行うステップ、およびリソースロックを解除するステップを含んでもよい。バッファ記録は、バッファ記録が処理された後に削除されてもよい。
【００１３】
一実施形態では、方法は、継続的に要求イベントを記録して、複数の要求イベントをそれぞれ含む複数のバッファ記録を生成する。この方法は、次の決算日を待たずに口座内の要求イベントの簿記のための複数のバッファ記録をさらに連続して取り出し、処理する。
【００１４】
本開示の別の態様によると、金融トランザクションを伴う口座のコンピュータ化された簿記のための方法は、第１の口座および複数の第２の口座を確立する。第１の口座は、複数の第２の口座との多量の並列トランザクションを有する。この方法は、複数の第２の口座の１つまたはそれ以上に代わって開始される複数の要求イベントを受け取り、要求イベントが、要求イベントを開始したそれぞれの第２の口座の簿記のために行われる際、要求イベントのそれぞれを処理する。同時に、この方法は、複数の要求イベントを記録して、第１の口座に対する要求イベントのバッファ記録を生成し、次の決算日を待たずに第１の口座内の要求イベントの簿記のためのバッファ記録を取り出し、処理する。
【００１５】
金融トランザクションを伴う口座のコンピュータ化された簿記のための開示されたシステムは、保存庫、バッファ保存ユニット、および簿記ユニットを含む。保存庫は、第１の口座および複数の第２の口座を保存し、第１の口座は、複数の第２の口座との多量の並列トランザクションを有する。バッファ保存ユニットは、複数の第２の口座の１つまたはそれ以上に代わって開始される複数の要求イベントを記録して、第１の口座に対する要求イベントのバッファ記録を生成するために適合される。簿記ユニットは、次の決算日を待たずに第１の口座内の要求イベントの簿記のためのバッファ記録を取り出し、処理するようにプログラムされる。
【発明の効果】
【００１６】
本開示の例示的な実施形態によると、開示された方法およびシステムは、以下の技術的利益を有し得る。
【００１７】
第１に、この方法は、多量の並列トランザクションを有する口座を目的とする。方法は、保存領域を使用して各要求イベントを一時的に記録し、次に、関連簿記情報を記録し、勘定残高を更新することによって簿記を行って、前の要求によって処理されていない簿記ステップを完了する。既存の技術と異なり、要求イベントは、バッファされる。この方法は、簿記情報を記録するステップおよび勘定残高を更新するステップを分離しないが、代わりに、最終段階で同調して両操作を行う。さらに、最終段階処理は、口座の毎日の集約を行うために次の決算日まで待たずに短期間で完了することができる。したがって、支払明細および勘定残高を、ユーザの口座照合要件を満たすように同調して更新することができる。また、資金は、問い合わせのために利用可能であり、より短い期間でアクセス可能となる。短い遅延は、口座の並列トランザクションのレベルに従って設定することができる。
【００１８】
第２に、本開示は、最終段階処理中、バッファ記録を取り出し、処理する２つの代替方法を提供する。１つは、所定の時間間隔で一定の間隔でバッファ記録を取り出し、処理することである。これは、比較的大きい取引量を有するが、厳重な時間遅延要件を伴わない口座に好適である。もう１つは、現在のバッチを完全に処理した直後に別のバッチを開始することによって再帰的にバッファ記録を取り出し、処理することである。これは、非常に大きい取引量を有し、より短い時間遅延要件を有する口座に好適である。
【００１９】
本概要は、発明を実施するための形態において以下に詳述される、簡素化した形の概念の選択を導入するために提供される。本概要は、主張された主題の重要な特徴または基本的な特徴を特定することを目的とせず、主張された主題の範囲を決定する援助として使用されることを目的ともしない。
【図面の簡単な説明】
【００２０】
詳細な説明を、添付図を参照して記載する。図において、異なる図における同じ参照番号の使用は、類似または同一の項目を示す。
【図１】本開示による、バッファされた簿記の例示的な全体的過程のフローチャートである。
【図２】図１の例示的な全体的過程において使用されるバッファ記録を復元し、処理する例示的な過程のフローチャートである。
【図３】本開示による、少量のトランザクションを有する口座（例えば、買主の口座）の例示的な簿記過程を説明する略図である。
【図４】本開示による、多量のトランザクションを有する口座（例えば、売主の口座）の例示的な簿記過程を説明する略図である。
【図５】本開示による、バッファされた簿記のための第１の例示的なシステムの図である。
【図６】本開示による、バッファされた簿記のための第２の例示的なシステムの構造図である。
【発明を実施するための形態】
【００２１】
目的、特徴、および利益をより良く理解するために、開示された方法およびシステムを、添付図および例示的な実施形態を使用して以下にさらに詳述する。
【００２２】
本明細書において記載されるバッファされた簿記方法は、多量の並列金融要求のために使用される。この方法は、多量の並列トランザクションを有する口座を目的とし、バッファ保存領域を使用して各要求イベントを一時的に記録し、その後、最終段階で簿記情報を記録し、口座を更新して、本来の要求の処理されていない簿記作業を完了する。
【００２３】
開示された方法は、オンラインショッピング、公正購入、およびコンサートチケットの購入等の多数の分野における金融処理の様々な状況において好適に適用することができる。また、この方法は、支払いが複数の口座から単一の口座に同時に行われる並列支払要求を処理するために特に好適である。
【００２４】
当該方法を、タッチトランザクションを伴う例示的な実施形態を使用して以下に詳述する。買主は、売主から商品を購入し、売主の口座に支払いを送る必要がある。売主の口座は、受取口座と称してもよく、買主の口座は、支払口座と称される。具体的には、支払いは、支払口座から受取口座へ振り込まれる。
【００２５】
過程は、２つの役割型の利益を伴う。第１の型は、口座を所有するユーザ（買主または売主等）であり、手短に「ユーザ」と称される。第２の型は、請求および支払サービスを提供するシステムであり、手短に「システム」と称される。
【００２６】
ユーザの観点から、取引状態および条件を確認するためにリアルタイムで簿記仕訳帳情報（すなわち、支払明細）を見る要望、および勘定残高をタイムリーに更新させ、リアルタイムで使用可能にする要望の両方が存在する。
【００２７】
システムの観点から、システムの処理圧力を均一に分配するために多量の並列トランザクションの状況においてリアルタイム処理を有し、他の関連トランザクションが正常に処理されることを確実にする要望が存在する。
【００２８】
ユーザおよびシステムの上記の要件を満たすために、バッファされた簿記のための方法の例示的な実施形態は、複数の口座が同時に単一の口座に支払いを送る例を使用する。
【００２９】
図１は、本開示によるバッファされた簿記のための例示的な過程のフローチャートを示す。本記載では、過程が記載される順序は、限定と解釈されることを目的とせず、任意の数の記載される過程ブロックは、方法、または代替方法を実施するための任意の順序で組み合わされてもよい。過程を以下に記載する。
【００３０】
ブロック１０１では、多量の並列トランザクションの状況において売主に支払うために、買主は、支払要求を開始し、要求を請求システムに提出する。複数の買主は、同時に、または非常に短い期間内で支払いを提出してもよい。
【００３１】
ブロック１０２では、各支払要求のために、請求システムは、まず、それぞれの買主の口座の簿記を行う。簿記を行うために、リソースロックは、買主の口座に掛けられる必要があってもよい。簿記は、以下の操作を含んでもよい。
【００３２】
１）リソースロックをそれぞれの買主の口座に掛ける。
【００３３】
２）簿記証明書を簿記仕訳帳に記録する。
【００３４】
３）それぞれの勘定残高を更新する（例えば、それぞれの買主の口座から支払いを引き落とす）。
【００３５】
買主の口座は、多量のトランザクションを経験しないため、買主の口座の簿記は、バッファ過程を必要としなくてもよい。
【００３６】
ブロック１０３では、その後、請求システムは、売主の口座に対するバッファリング過程を行い、後の段階（すなわち、最終段階）で行われるさらなる簿記処理を待つ。バッファリング過程は、要求イベントのみを記録して、バッファ記録を生成してもよいが、いかなる実際の簿記操作（証明書記録および勘定残高更新等）も行わない。
【００３７】
請求システムは、仕訳帳の形で各要求をバッファ領域に記録し、バッファ記録を生成し、バッファ記録は、次に、一定期間後の簿記のために連続して請求システムへ入力される。バッファ領域は、データベース、サーバ、ハードディスク、メモリ、またはそれらの一部としての保存装置であってもよい。
【００３８】
ブロック１０４では、要求イベントが上記のように処理された後、買主の口座に対するリソースロックは、解除されてもよい。
【００３９】
ブロック１０５では、請求システムは、次に、バッファ記録を復元することによって、売主の口座の簿記のためのバッファ記録を処理する。一実施形態では、バッファ記録は、請求システムによって別々に最終段階で処理される。
【００４０】
図２は、バッファ記録を復元することによる、バッファされた簿記の例示的な過程のフローチャートを示す。
【００４１】
ブロック２０１では、請求システムは、バッファ保存庫に保存される１つまたはそれ以上のバッファ記録を取り出す。２つの例示的な取り出し方法を使用してもよい。１つは、所定の期間での一定の間隔での取り出しである。これは、比較的大きい取引量を有するが、厳重な時間遅延要件を有さない口座に好適である。もう１つは、以前に取り出したバッファ記録のバッチを処理した直後にバッファ記録の新規のバッチを取り出す、再帰的な取り出しである。遅延は、２つの隣接する取り出しの間に使用されても、されなくてもよい。これは、非常に大きい取引量を有し、より短い時間遅延要件も有する口座に好適である。いずれの場合にも、取り出しは、開始するために次の決算日まで待つ必要がない。しかし、代わりに、バッファされた簿記のための取り出しおよび次の処理は、商取引の発生後、短期間内に開始してもよい。
【００４２】
バッファ記録が取り出された後、請求システムは、バッファ記録を、それぞれの買主の口座から送出される要求イベントをそれぞれ含有する複数の記録に分割してもよく、処理スレッドを複数の記録のそれぞれに配属して、バックグラウンドで処理スレッドを処理する。つまり、各買主の口座は、最終処理のための記録の分割に基づいて処理スレッドを割り当てられる。これは、処理時間を低減するために役立つ。
【００４３】
２０２では、請求システムは、取り出されたバッファ記録を１つずつ処理し始める。各バッファ記録を処理するために、リソースロックが、まず、それぞれの売主の口座に掛けられる。
【００４４】
２０３では、簿記証明書は、簿記仕訳帳として記録される。これは、売主の口座の簿記過程の一部である。
【００４５】
２０４では、売主の口座の残高が更新される。例えば、それぞれの買主によって行われる支払いは、売主の口座に振り替えられる。これは、売主の口座の簿記過程の別の部分である。
【００４６】
２０５では、当該のバッファ記録は、次の処理を容易にするためにバッファ領域から削除される。
【００４７】
２０６では、現在のバッファ記録が上記のように処理された後、売主の口座に対するリソースロックは解除されてもよい。その後、過程は、２０２に戻り、他の取り出されたバッファ記録を処理し続ける。全ての取り出されたバッファ記録が完全に処理された後、過程は、２０１に戻り、復元および簿記のための１つまたはそれ以上の新規のバッファ記録の新規のバッチを取り出す。
【００４８】
請求システムは、一度に１つのバッファ記録のみを取り出し、処理するか、または一度に複数のバッファ記録のバッチを取り出し、現在のバッチが処理された後に別のバッチを取り出すために待つか、のいずれかであってもよいことが理解される。
【００４９】
上記の過程を図３および図４にさらに示す。図３は、本開示による、少量のトランザクションを有する口座（例えば、買主の口座）の例示的な簿記過程を示す略図を示す。図４は、本開示による、多量のトランザクションを有する口座（例えば、売主の口座）の例示的な簿記過程を示す略図を示す。
【００５０】
図３および図４では、請求システムは、販売を行うトランザクションシステムの一部か、またはトランザクションシステムと共同して作用する別のシステムのいずれかであってもよい。いずれの場合にも、請求システムは、好ましくは、買主または売主によって所有されない第三者支払システムである。
【００５１】
請求システムは、仮想のユーザ口座を有し、仮想のユーザ口座は、買主の仮想口座および売主の仮想口座を含んでもよい。実際には、請求システムは、多くの買主の仮想口座および複数の売主の仮想口座を含んでもよい。買主は、まず、銀行口座から買主の仮想口座へ資金を振り替える。振り替えられた資金は、複数のトランザクションを払うための預金、または特定のトランザクションを払うことを意図するトランザクション資金のいずれかであってもよい。その後、トランザクション資金は、トランザクション過程中に、買主の仮想口座から売主の仮想口座へ振り替えられる。この段階で、トランザクション資金は、第三者支払基盤（請求システム等）の管理下となるため、売主は、資金を即座に引き出すことはできない。買主が、購入品の満足できる受領を確認した後、トランザクション資金は、売主の仮想口座から売主の銀行口座へ振り替えられる。したがって、開示された方法は、請求システムにおいて、買主によって保有される複数の仮想口座から売主によって保有される単一の仮想口座へ同時に送出される要求を処理するために使用することができる。
【００５２】
図３および図４では、トランザクションシステムは、ネットワーク上での買主と売主との間のトランザクションを行うための基盤であり、主に、トランザクションを完了し、関連トランザクション情報を記録するために使用される。トランザクション過程の間、トランザクション資金の振り替えは、請求システムによって完了される。トランザクションのイベントにおいて、トランザクションシステムは、処理されるために要求を請求システムに提出する。本明細書において記載されるようにトランザクション資金の処理を完了した後、請求システムは、トランザクションシステムがトランザクション過程を完了し続けることができるように、処理結果をトランザクションシステムに戻す。実践上の用途では、トランザクションシステムおよび請求システムは、第三者支払基盤として合わせて作用してもよい。しかしながら、ある用途では、トランザクションシステムは、請求システム等の第三者支払基盤から分離されてもよい。
【００５３】
図３に示される買主の口座の例示的な簿記過程は、以下のように要約される。この処理はバッファされることを必要としない。
【００５４】
３０１では、買主は、請求システムを使用して売主に支払う。支払いが、図３に示されるように買主の口座に対して処理される間に、請求システムは、支払要求をバッファ保存庫に保存することによって、売主の口座に対するバッファリング過程を行う。
【００５５】
３０２では、請求システムは、買主の口座のリソースをロックする。
【００５６】
３０３では、請求システムは、支払要求の簿記証明書を買主の口座に記録する。
【００５７】
３０４では、請求システムは、買主の口座の残高を更新する。
【００５８】
３０５では、請求システムは、要求イベントを売主の口座に記録する。
【００５９】
３０６では、請求システムは、買主の口座のリソースロックを解除する。
【００６０】
図４に示されるように、売主の口座の例示的なバッファされた簿記過程は、以下のように要約される。
【００６１】
４１１では、タイミングシステムは、簿記のためのバッファ記録を一定の間隔で復元し、処理するように請求システムに指示する。タイミングシステムは、請求システムの一部であってもよい。タイミングシステムは、過程が、バッファ記録の再帰的な取り出しを使用する場合、必要とされなくてもよい。
【００６２】
４１２では、請求システムは、バッファ記録を取り出し、取り出されたバッファ記録を処理する。複数のバッファ記録が取り出される場合、請求システムは、ループ過程を使用して、取り出されたバッファ記録を１つずつ処理する。各ループは、以下のステップ４１３〜４１７を含む。
【００６３】
４１３では、請求システムは、売主の口座のリソースをロックする。
【００６４】
４１４では、請求システムは、簿記証明書を売主の口座に記録する。
【００６５】
４１５では、請求システムは、売主の口座の残高を更新する。
【００６６】
４１６では、請求システムは、処理されたバッファ記録を削除する。このステップは、ループの各サイクルに対して行われるか、またはループが完了した後に行われるかのいずれかであってもよい。
【００６７】
４１７では、請求システムは、売主の口座のリソースロックを解除する。
【００６８】
バッファ記録の取り出しは、ある時間に処理するために、バッファ領域からバッファ記録を取り出すように請求システムに指示するタイミングシステムによって制御される。一実施形態では、タイミングシステムは、実際のシステムの必要性またはトランザクションの必要性に従ってカスタマイズされてもよい、すべての一定時間ごとにバッファ記録を取り出すように請求システムを制御するために使用される。
【００６９】
上記に示される、多量の並列トランザクションを有する口座のバッファされた簿記では、支払明細（簿記証明書等）および勘定残高の更新は、各バッファ記録のために同調して行われる。多量の並列トランザクションを有する口座の簿記は、トランザクション後に遅れて完了する場合があるが、簿記過程は、ユーザの商取引にほとんど影響を与えず、ユーザの口座照合に対する要求を満たすことができる。また、請求、支払い、及びトランザクション資金の記録は、使用問い合わせに対して利用可能であり、資金は、トランザクション後のより短い期間内の使用に対して利用可能である。短い遅延は、口座の並列トランザクションのレベルに従って、さらに設定されてもよい。リソースロックの延期は、大幅に減少し、それは、システムの観点から望ましい結果である。
【００７０】
請求システムは、毎日の集約操作を行ってもよい。開示された方法は、対象の日付に対する未処理のバッファ記録が、バッファ簿記のために毎日の集約操作中に存在する可能性があるという点で、従来の毎日の集約操作と異なる。したがって、追加の処理が、毎日の集約操作の前に追加されてもよい。具体的に、請求システムは、対象の日付のいかなる未処理のバッファ記録が未だに存在するかどうかを調べる。肯定的である場合、そのような残りのバッファ記録は、毎日の集約操作を継続する前に、まず、復元され、処理される。そうでなければ、毎日の集約操作は、一時停止され、残りのバッファ記録が処理された後に継続するように設定される。
【００７１】
バッファされた簿記のための上記の方法を実施するために、本開示は、バッファされた簿記のための例示的なシステムをさらに提供する。図５は、第１の例示的なシステムの構造図を示す。システム５００は、好ましくは、金融トランザクションを伴う口座の簿記のためのコンピュータ化されたシステムである。示されるように、システム５００は、保存庫５０５、バッファ保存ユニット５０１、および簿記ユニット５０２を有する。
【００７２】
保存庫５０５は、第１の口座（売主の口座等）および複数の第２の口座（買主の口座等）を保存する。一実施形態では、これらの口座は、第三者支払基盤を支持するシステム５００においてユーザによって確立される仮想口座である。各仮想口座は、それぞれのユーザの銀行口座等の本当の金融口座と関連する。第１の口座は、複数の第２の口座との多量の並列トランザクションを有する。保存ユニット５０５は、データベース、サーバ、ハードディスク、またはメモリ等の保存装置であってもよい。
【００７３】
バッファ保存ユニット５０１は、複数の第２の口座の１つまたはそれ以上に代わって開始される複数の要求イベントを記録して、第１の口座に対する要求イベントのバッファ記録を生成するために適合される。バッファ保存ユニット５０１は、データベース、サーバ、ハードディスク、またはメモリ等の保存装置であってもよい。バッファ保存ユニット５０１および保存庫５０５は、同じ一体化保存システムに属するか、または２つの別々の保存ユニットに属するかのいずれかであってもよいことが理解される。例えば、バッファ保存ユニット５０１は、システム５００に組み込まれているコンピュータのＲＡＭによって提供されてもよい。
【００７４】
簿記ユニット５０２は、次の決算日を待たずに第１の口座内の要求イベントの簿記のためのバッファ記録を取り出し、処理するようにプログラムされる。簿記は、口座内の簿記情報を記録するステップおよび口座を更新するステップを含む。簿記ユニット５０２は、所定の時間間隔で定期的に、または再帰的にかのいずれかでバッファ保存ユニット５０１からバッファ記録を取り出してもよい。
【００７５】
好ましくは、取り出しが、所定の時間間隔で定期的に行われる場合、システムは、タイミングユニット５０３をさらに含み、タイミングユニット５０３は、所定の時間間隔を設定し、バッファ記録をバッファ保存ユニット５０１から取り出すように簿記ユニット５０２を定期的に誘引するために使用される。時間間隔は、口座の並列トランザクションのレベルに従って設定されてもよい。
【００７６】
簿記過程中、簿記ユニット５０２は、バッファ記録を１つずつ処理する。バッファ記録が処理される時、多量の並列トランザクションを有する関連口座はロックされ、次に、現在のバッファ記録が完全に処理された後に解除される。好ましくは、バッファ記録が簿記ユニット５０２によって完全に処理された後、バッファ記録は、次の毎日の集約操作を容易にするために、バッファ保存ユニット５０１から削除される。
【００７７】
好ましくは、システムは、照合／確認ユニット５０４をさらに含み、照合／確認ユニット５０４は、毎日、前決算日の簿記情報を照合し、確認するために使用される。前決算日の任意のバッファ記録が、バッファ保存ユニット５０１に存在する場合、システム５００によって簿記ユニット５０２は、以降、前決算日の簿記情報を照合および確認し続ける前に、まず、簿記のための残りのバッファ記録の処理を完了することが可能となる。
【００７８】
図６は、本開示による、バッファされた簿記の別の例示的なシステムの構造図を示す。この例示的な実施形態は、電子商取引における図５の上記の例示的なシステムの用途である。システムは、主に、トランザクションシステム６１１、請求システム６０２、およびバッファ保存領域６０１を含む。これらの構成要素は、ネットワーク６２０を介して、買主のユーザクライアント６３０および売主のユーザクライアント６４０に接続される。
【００７９】
トランザクションシステム６１１は、買主のユーザクライアント６３０と売主のユーザクライアント６４０との間のネットワークトランザクションを処理するために使用され、関連トランザクション情報を記録する。請求システム６０２は、主に、証明書記録および勘定残高更新等の操作を含むトランザクション過程内の請求または支払要求を処理するために使用される。請求システム６０２は、要求をバッファ保存領域６０１に記録することによって、多量の並列要求のためのバッファリング過程を行い、その後、連続して売主の口座のバッファされた簿記のために処理されるバッファ記録をバッファ保存領域６０１から取り出す。
【００８０】
請求システム６０２は、第三者支払基盤によって提供されてもよい。トランザクションシステム６１１および請求システム６０２は、両方とも、第三者支払基盤によって提供されてもよい。実施の特定の方法は、柔軟であり得る。請求システム６０２内には、買主およびユーザの仮想口座が設置される。そのような口座は、請求システム６０２の一部である保存庫に保存されてもよい。仮想口座は、買主のユーザクライアント、および売主のユーザクライアントに対して分離される。買主と売主との間のトランザクションおよび資金振り替えは、仮想口座を使用して達成される。
【００８１】
買主のユーザクライアント６３０、および売主のユーザクライアント６４０は、トランザクションシステム６１１を通ってトランザクション過程を完遂する。買主が売主に支払う場合、トランザクションシステム６１１は、請求要求を請求システム６０２に送出する。要求を完了するために、請求システム６０２は、買主の仮想口座内のトランザクション資金を、売主の仮想口座へ振り替える。
【００８２】
複数の買主口座から単一の売主口座へ同時に提出された支払いを同時に処理するために、請求システム６０２は、まず、買主の仮想口座にロックを掛け、口座に対する簿記証明書を記録し、口座の残高を更新する。その後、請求システム６０２は、関連する要求イベントをバッファ保存領域６０１に記録することによって、売主の仮想口座に対するバッファリング過程を行い、完了後に買主の仮想口座からリソースロックを解除する。
【００８３】
請求システム６０２は、定期的な取り出し方法または再帰的な取り出し方法を使用して、バッファ保存領域６０１におけるバッファ記録を１つずつ処理する。バッファ記録を処理するために、請求システム６０２は、バッファ記録を取り出し、売主の仮想口座にロックを掛け、バッファ記録に従って簿記証明書を記録し、売主の口座の残高を更新する。その後、請求システム６０２は、処理されたバッファ記録をバッファ保存領域６０１から削除し、売主の仮想口座からリソースロックを解除して、現在のバッファ記録の処理を完了する。その後、請求システム６０２は、各バッファ記録の処理結果をトランザクションシステム６１１に戻し、トランザクションシステム６１１は、受領した処理結果を使用してトランザクション過程を完了し続ける。
【００８４】
上記の処理を通して、バッファされた簿記のためのシステムは、口座リソースの延期されたロックを短縮し、並列処理の効率性を改善し、支払明細および勘定残高の同期更新を達成することができる。これは、買主および売主の両方の口座照合要件を満たす。
【００８５】
図５および図６における任意の省略された詳細は、図２から図４における方法に関連して記載されるそれらの関連部分を参照することができる。
【００８６】
本明細書において論じられる潜在的利益および利点は、添付の請求項の範囲に対する限定または制限と解釈されるものではないことが理解される。
【００８７】
主題は、構造的特徴および／または方法論的作用に特異的な言語で記載されているが、当然のことながら、添付の請求項において定義される主題は、必ずしも記載される特定の特徴または作用に限定されるわけではない。むしろ、特定の特徴および作用は、請求項を実施する例示的な形として開示される。
【図１】
2011527057.tif 000003
【図２】
2011527057.tif 000004
【図３】
2011527057.tif 000005
【図４】
2011527057.tif 000006
【図５】
2011527057.tif 000007
【図６】
2011527057.tif 000008
【国際調査報告】
2011527057.tif 000009