決済順序確定システム、方法及びプログラム
【課題】複数の取引を連続して決済可能な決済順序について、少ない試行回数により効率的に確定すること。
【解決手段】本発明の第１の態様にかかる決済順序確定システムは、決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行し、試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとし、Ｎが１からＬまでの間繰り返し実行する。実行の結果、試行が成功した取引における決済順序以前に、試行が失敗した取引が存在する場合、試行が失敗した全ての取引における決済順序が、試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように決済順序記憶部を更新し、更新後に、ＮがＭ＋１からＬまでの間、繰り返し実行する。
【解決手段】本発明の第１の態様にかかる決済順序確定システムは、決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行し、試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとし、Ｎが１からＬまでの間繰り返し実行する。実行の結果、試行が成功した取引における決済順序以前に、試行が失敗した取引が存在する場合、試行が失敗した全ての取引における決済順序が、試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように決済順序記憶部を更新し、更新後に、ＮがＭ＋１からＬまでの間、繰り返し実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、決済順序確定システム、方法及びプログラムに関し、特に、債券等の複数の取引を連続して決済する場合に決済可能な決済順序を確定する決済順序確定システム、方法及びプログラムに関する。
【背景技術】
【０００２】
近年、債券等のペーパーレス化に伴い、物理的な券面を発行せず、所定の機関において保有者、銘柄名及び額面等の管理が行われるようになった。そして、これらの管理が情報システム化されることにより、取引後の受渡し決済時に券面の移動を伴わないため、省力化やコストの軽減が図れるようになった。
【０００３】
特許文献１には、同一銘柄で異額面の債券取引におけるネッティング決済を可能とするネッティング決済システムに関する技術が開示されている。特許文献１にかかるネッティング決済システムは、二者による債券取引に関する取引関連データを入力する取引関連データ入力手順と、入力された取引関連データの中から同一銘柄の受け渡しの組合せを抽出する同一銘柄受け渡し抽出手順と、抽出された受け渡しの組合せの中から相殺すべき受け渡しの組合せたる相殺組合せを抽出する相殺抽出手順と、抽出された相殺組合せを決済演算可能な決済演算手順と、決済演算された結果を決済明細として出力する決済明細出力手順とを備える。特に、前記相殺抽出手順は、異額面の債券の受け渡しの組合せを含む相殺組合せを抽出可能とする。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３５２１７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
債券等の取引の中には、所定期間内に請求された複数の取引の請求を所定の期日又は時間に一括して決済を行うものがある。例えば、日中であれば取引の請求毎に即時に決済が行われるが、夜間に取引をまとめて受け付けて、翌朝までに決済を行う場合などである。ここで、債券等の取引の決済は、取引元の口座から取引先の口座へ金融商品の取引額を移動させることである。そして、取引額に比べて取引元の口座に債券等の残高が不足している場合は、決済を行うことができない。また、複数の取引の決済を一括して行う場合、ある取引における決済により口座の残高が変更することに伴い、他の取引の決済の可否が影響を受ける場合がある。つまり、決済の順序により、取引における決済の可否の結果が異なる場合がある。そのため、ある口座が複数の取引に関係している場合、これらの取引をまとめて取引グループとして扱うことが必要である。そして、複数の取引の決済を一括して行う場合、取引グループに含まれる複数の取引について所定の決済順序により直列に決済を行い、取引グループ内の全ての取引が決済可能である場合に、当該取引グループについて、一括して決済が可能と判断することができる。
【０００６】
例えば、取引グループに含まれる複数の取引について、決済順序の組み合わせを総当たりで試行することにより、決済可能な決済順序を検出することも可能である。この場合、取引グループに含まれる取引数に伴う計算量の増加が著しい。債券等における取引の請求は、一時期に集中する傾向があり、取引額は数千億円にのぼる場合もある。また、取引グループ内の取引の関係は複雑であるため、決済可能な決済順序を検出するには、複雑な処理を必要とし、時間がかかるという問題がある。
【０００７】
ここで、債券等における大部分の取引グループにおける取引の関係には、様々なパターンが存在するが、大部分の取引グループについては、単純なパターンが多く含まれ、複雑なパターンが全体に占める割合は少ないという特徴がある。
【０００８】
本発明は、このような問題を解決するためになされたものであり、複数の取引を連続して決済する場合に、決済可能な決済順序について、少ない試行回数により効率的に確定するための決済順序確定システム、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の態様にかかる決済順序確定システムは、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済可能な決済順序を確定する決済順序確定システムであって、前記取引に関わる口座の残高情報を記憶する残高情報記憶部（例えば、本発明の実施の形態１にかかる口座情報記憶部３２）と、前記取引グループに含まれる各取引における決済順序を記憶する決済順序記憶部（例えば、本発明の実施の形態１にかかる取引情報記憶部３３）と、前記取引における前記決済順序を確定する処理を制御する制御部と、を備え、前記制御部は、前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整手段と、前記第１の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定手段と、を備え、前記第１の決済順序調整手段は、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行手段と、前記取引決済試行手段による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高情報更新手段と、Ｎが１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第１の繰り返し実行手段と、前記第１の繰り返し実行手段による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新手段と、前記決済順序更新手段による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第２の繰り返し実行手段と、を含む。
【００１０】
また、前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記取引グループに含まれる全ての取引の決済が確定したと仮定した場合の口座当たりの残高を算出し、算出された残高が所定値以下となる口座について、残高が所定値となる取引額を加算して前記残高情報記憶部に格納された残高情報を補正する残高情報補正手段と、前記残高情報補正手段により補正された残高情報を用いて、前記決済順序記憶部に格納された決済順序に基づき、前記第１の決済順序調整手段により前記試行が失敗した全ての取引についての決済を試行することにより前記決済順序を調整する第２の決済順序調整手段と、をさらに備え、前記確定手段は、前記第２の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序としてさらに確定することが望ましい。
【００１１】
また、前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記取引グループに含まれる各取引から、取引元の口座が当該取引グループ内の他の取引の取引先の口座と一致しない取引である始点取引と、取引先の口座が当該取引グループ内の他の取引の取引元の口座と一致しない取引である終点取引とを選択する端点取引選択手段と、前記始点取引における決済順序を、最初の順序として前記決済順序記憶部を更新し、当該始点取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、前記終点取引における決済順序を、最後の順序として前記決済順序記憶部を更新する端点取引処理手段と、前記端点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整する第３の決済順序調整手段と、をさらに備え、前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記決済順序記憶部に格納された決済順序を決済可能な順序として確定することが望ましい。
【００１２】
さらに、前記第３の決済順序調整手段により試行が失敗した取引に含まれる口座から、自己が前記取引先の口座となる取引が存在し、かつ、自己が前記取引元の口座となる取引が２以上存在する口座を選択する起点口座選択手段と、前記起点口座選択手段により選択された口座が前記取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて前記決済順序記憶部を更新する起点取引処理手段と、をさらに備え、前記第３の決済順序調整手段は、前記起点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整することが望ましい。
【００１３】
また、前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序として確定するとよい。
【００１４】
さらに、取引元の口座から取引先の口座へ所定額を決済するための複数の取引を外部から受け付け、受け付けた複数の取引の中から、前記取引先の口座又は前記取引元の口座の少なくとも一方の口座が他の取引と共通する取引を選択し、選択した取引の集合を前記取引グループとして生成する取引グループ生成手段をさらに備え、前記第１の決済順序調整手段は、前記取引グループ生成手段により生成された取引グループに対して、前記決済順序を調整するとよい。
【００１５】
さらに、前記残高情報補正手段は、前記取引が券種及び枚数により定まる債券における取引である場合に、前記取引グループに含まれる口座の残高における債券の券種及び枚数に基づき、前記口座当たりの残高を算出するとよい。
【００１６】
本発明の第２の態様にかかる決済順序確定方法は、取引に関わる口座の残高情報を記憶する残高情報記憶部（例えば、本発明の実施の形態１にかかる口座情報記憶部３２）と、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部（例えば、本発明の実施の形態１にかかる取引情報記憶部３３）と、前記取引における前記決済順序を確定する処理を制御する制御部と、を備えるコンピュータにおける前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を制御するための決済順序確定方法であって、前記制御部において、前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整ステップと、前記第１の決済順序調整ステップにより調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定ステップと、を含み、前記第１の決済順序調整ステップは、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行ステップと、前記取引決済試行ステップによる試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新ステップと、Ｎが１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第１の繰り返し実行ステップと、前記第１の繰り返し実行ステップによる実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新ステップと、前記決済順序更新ステップによる更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第２の繰り返し実行ステップと、を含む。
【００１７】
本発明の第３の態様にかかる決済順序確定プログラムは、取引に関わる口座の残高情報を記憶する残高情報記憶部（例えば、本発明の実施の形態１にかかる口座情報記憶部３２）と、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部（例えば、本発明の実施の形態１にかかる取引情報記憶部３３）と、前記取引における前記決済順序を確定する処理を制御する制御部と、を備えるコンピュータに、前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を実行させる決済順序確定プログラムであって、前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整処理と、前記第１の決済順序調整処理により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定処理と、を含み、前記第１の決済順序調整処理は、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行処理と、前記取引決済試行処理による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新処理と、Ｎが１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第１の繰り返し実行処理と、前記第１の繰り返し実行処理による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新処理と、前記決済順序更新処理による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第２の繰り返し実行処理と、を含む。
【発明の効果】
【００１８】
本発明によれば、複数の取引を連続して決済する場合に、決済可能な決済順序について、少ない試行回数により効率的に確定するための決済順序確定システム、方法及びプログラムを提供することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態１にかかる決済順序確定システムを含む全体構成を示すブロック図である。
【図２】本発明の実施の形態１にかかる口座情報の例を示す図である。
【図３】本発明の実施の形態１にかかる取引情報の例を示す図である。
【図４】本発明の実施の形態１にかかる決済順序確定システムの機能ブロック図である。
【図５】本発明の実施の形態１にかかる決済順序確定システムのハードウェア構成を示すブロック図である。
【図６】本発明の実施の形態１にかかる決済順序確定処理の流れを示すフローチャートである。
【図７】本発明の実施の形態１にかかる取引グループ生成処理の流れを示すフローチャートである。
【図８】本発明の実施の形態１にかかる取引グループの例を示す図である。
【図９】本発明の実施の形態１にかかる決済順序調整処理の流れを示すフローチャートである。
【図１０】本発明の実施の形態１にかかる取引グループ決済試行処理の流れを示すフローチャートである。
【図１１】本発明の実施の形態１にかかる決済試行処理の流れを示すフローチャートである。
【図１２】本発明の実施の形態１にかかる取引グループ決済試行処理の実行結果の例を示す図である。
【図１３】本発明の実施の形態１にかかる取引グループ決済試行処理の実行結果の例を示す図である。
【図１４】本発明の実施の形態１にかかる口座収支算出処理の実行結果の例を示す図である。
【図１５】本発明の実施の形態１にかかる残高補正処理後の取引グループ決済試行処理の実行結果の例を示す図である。
【図１６】本発明の実施の形態１にかかる擬似ループ判定処理の流れを示すフローチャートである。
【図１７】本発明の実施の形態１にかかる起点口座が選択される取引グループの例を示す図である。
【図１８】本発明の実施の形態１にかかる確定処理の流れを示すフローチャートである。
【図１９】本発明の実施の形態２にかかる券種及び枚数を考慮した取引グループの例を示す図である。
【図２０】本発明の実施の形態２にかかる券種及び枚数を考慮した口座収支の例を示す図である。
【発明を実施するための形態】
【００２０】
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
【００２１】
＜発明の実施の形態１＞
図１は、本発明の実施の形態１にかかる決済順序確定システム３を含む全体構成を示すブロック図である。決済順序確定システム３は、ネットワーク２を介して、端末１ａ、１ｂ、・・・１ｎと接続され、端末１ａ、１ｂ、・・・１ｎから送信される複数の取引の請求を受け付け、所定期間内に受け付けた複数の取引について決済可能な決済順序を確定する決済順序確定処理を行う情報システムである。また、決済順序確定システム３は、決済が不可能な取引については、その旨を通知する。ここで、取引とは、取引元の口座から取引先の口座へ金融商品の取引額の移動又は債券等の権利の移転を定義したものとする。そして、取引の決済とは、取引額の移動又は債券等の権利の移転を実行することとする。また、決済順序とは、複数の取引について、取引の決済を実行する順序を示すものとする。
【００２２】
決済順序確定システム３は、汎用的なコンピュータシステムであり、取引における決済順序を確定する処理を制御する制御部３１と、口座情報記憶部３２と、取引情報記憶部３３とを少なくとも備える。口座情報記憶部３２は、口座ＩＤ３２１と、残高情報３２２とを関連付けて記憶する記憶装置である。ここでは、口座ＩＤ３２１は、取引に関わる口座を識別する情報である。また、残高情報３２２は、取引に関わる口座の取引可能な金額情報又は債券額である。尚、口座情報記憶部３２は、言い換えると、取引に関わる口座の残高情報３２２を記憶する残高情報記憶部といえる。
【００２３】
ここで、図２は、本発明の実施の形態１にかかる口座情報の例を示す図である。図２では、３０個の口座ＩＤについてそれぞれ残高情報が関連付けられていることを示す。
【００２４】
図１に戻り、取引情報記憶部３３は、グループＩＤ３３１と、取引ＩＤ３３２と、取引元口座ＩＤ３３３と、取引先口座ＩＤ３３４と、取引額３３５と、決済順序３３６とを記憶する記憶装置である。グループＩＤ３３１は、取引グループを識別する情報である。ここで、取引グループは、取引先の口座又は取引元の口座の少なくとも一方の口座が他の取引と共通する取引の集合である。取引ＩＤ３３２は、取引を識別する情報である。取引元口座ＩＤ３３３は、口座ＩＤ３２１の内、取引における取引元の口座ＩＤである。取引先口座ＩＤ３３４は、口座ＩＤ３２１の内、取引における取引先の口座ＩＤである。取引額３３５は、取引において決済される金額情報又は債券額である。決済順序３３６は、取引の決済を実行する順序を示す情報である。例えば、決済順序３３６は、数値で表現される番号情報であり、番号の昇順又は降順に実行されるものとする。尚、決済順序３３６は、開始の番号は、任意であり、番号は連続している必要はない。また、決済順序３３６は、少なくとも取引グループ内で一意に順序が定まるものとする。または、決済順序３３６は、当該取引の直前又は直後に決済を実行する取引ＩＤ３３２であってもよい。尚、取引情報記憶部３３は、言い換えると、取引グループに含まれる各取引における決済順序を記憶する決済順序記憶部といえる。また、取引は、取引ＩＤ３３２、取引元口座ＩＤ３３３、取引先口座ＩＤ３３４、取引額３３５及び決済順序３３６の組み合わせで表現される。そして、一つのグループＩＤ３３１には、複数の取引ＩＤ３３２が関連付けられている。
【００２５】
ここで、図３は、本発明の実施の形態１にかかる取引情報の例を示す図である。図３では、図２の口座が取引元又は取引先の口座となった２８個の取引ＩＤについて取引元口座ＩＤ、取引先口座ＩＤ、取引額及び決済順序が関連付けられていることを示し、各取引ＩＤは、６個のグループＩＤのいずれかに関連付けられていることを示す。
【００２６】
図１に戻り、端末１ａ、１ｂ、・・・１ｎは、キーボードやマウス等の入力装置（不図示）と、画面等の表示装置（不図示）と通信機能を備える端末装置である。そして、端末１ａ、１ｂ、・・・１ｎは、ネットワーク２を介して、任意のタイミングで取引に関する情報を決済順序確定システム３へ送信する。また、ネットワーク２は、インターネット、公衆網、専用線及び移動体通信網等の通信ネットワークである。
【００２７】
尚、口座情報記憶部３２及び取引情報記憶部３３は、ハードディスクドライブ、フラッシュメモリ等の不揮発性の記憶装置であることが望ましい。
【００２８】
図４は、本発明の実施の形態１にかかる決済順序確定システム３の機能ブロック図である。決済順序確定システム３は、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済可能な決済順序を確定する情報システムである。決済順序確定システム３は、取引グループ生成手段３４０と、取引グループ決済試行手段３５０と、残高情報補正手段３６０と、擬似ループ判定手段３７０と、確定手段３８０とを備える。
【００２９】
取引グループ生成手段３４０は、端末１ａ、１ｂ、・・・１ｎからネットワーク２を介して、複数の取引を外部から受け付け、受け付けた複数の取引の中から、取引先の口座又は取引元の口座の少なくとも一方の口座が他の取引と共通する取引を選択し、選択した取引の集合を取引グループとして生成する。これにより、大量の取引について複数の取引グループに分けて効率的に決済順序を確定することができる。尚、このとき、取引グループ生成手段３４０は、取引グループ内の各取引について決済順序を初期設定するとよい。
【００３０】
取引グループ決済試行手段３５０は、取引情報記憶部３３に格納された決済順序３３６に基づき、取引グループに含まれる取引の決済を試行することにより決済順序を調整する。つまり、取引グループ決済試行手段３５０は、取引グループ生成手段３４０により生成された取引グループに対して設定された決済順序を調整する。尚、取引グループは、取引グループ生成手段３４０により生成されたものの代わりに、予め定められたものを対象としてもよい。また、取引グループ決済試行手段３５０は、取引決済試行手段３５１と、残高情報更新手段３５２と、繰り返し実行手段３５３と、決済順序更新手段３５４とを備える。
【００３１】
取引決済試行手段３５１は、口座情報記憶部３２及び取引情報記憶部３３を参照し、決済順序３３６がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する。残高情報更新手段３５２は、取引決済試行手段３５１による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して口座情報記憶部３２に格納された残高情報３２２を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする。繰り返し実行手段３５３は、取引情報記憶部３３に格納された決済順序３３６に従い、例えば、Ｎが１からＬまでの間、取引決済試行手段３５１による処理及び残高情報更新手段３５２による処理を繰り返し実行する。
【００３２】
決済順序更新手段３５４は、繰り返し実行手段３５３による実行の結果、試行が成功した取引における決済順序以前に、試行が失敗した取引が存在する場合、試行が失敗した全ての取引における決済順序が、試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように取引情報記憶部３３を更新する。そして、繰り返し実行手段３５３は、決済順序更新手段３５４による更新後に、ＮがＭ＋１からＬまでの間、取引決済試行手段３５１による処理及び残高情報更新手段３５２による処理を繰り返し実行する。
【００３３】
確定手段３８０は、取引グループ決済試行手段３５０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する。
【００３４】
このように、少なくとも上述した取引グループ決済試行手段３５０及び確定手段３８０を実行することにより、１巡目の試行では、初期設定された決済順序に基づき、各取引についての決済が試行され、試行が成功した取引の残高については、随時、決済後の残高に更新する。そして、更新後の残高を用いて以降の決済順序における取引が試行される。そして、１巡目の試行が終了した後に、試行が成功した取引及び試行が失敗した取引がそれぞれ存在し、かつ、最初の失敗以後に１以上の成功がある場合、言い換えると、最後の成功以前に１以上の失敗がある場合に、決済順序の更新及び２巡目の試行が行われる。決済順序更新手段３５４では、少なくとも試行が失敗した取引の決済順序を、試行が成功した全ての取引の決済順序より後の順序とする。
【００３５】
そして、２巡目の試行では、試行が失敗した取引のみについて、更新した決済順序に基づき決済が試行される。このとき、１巡目における試行が成功した取引における口座の残高は更新されており、２巡目の開始時点の条件は１巡目の開始時点とは条件が異なるため、１巡目にて最後の成功以前に試行が失敗した取引については、２巡目において試行が成功する可能性がある。これにより、初期設定とは異なる決済順序により試行を行ったこととなる。また、２巡目においては、１巡目において試行が成功した取引については、再度の試行を行わないため、試行回数を減らすことができる。すなわち、異なる決済順序を少ない試行回数により実行することができる。これにより、決済順序を並べ替えるだけで決済可能な取引グループであるか否かについて効率的に判定し、決済可能な決済順序を確定することができる。
【００３６】
また、残高情報補正手段３６０は、確定手段３８０により決済順序が決済可能な順序として確定されなかった場合に、口座情報記憶部３２及び取引情報記憶部３３を参照し、取引グループに含まれる全ての取引の決済が確定したと仮定した場合の口座当たりの残高を算出し、算出された残高が所定値以下となる口座について、残高が所定値となる取引額を加算して口座情報記憶部３２に格納された残高情報３２２を補正する。そして、取引グループ決済試行手段３５０は、残高情報補正手段３６０により補正された残高情報を用いて、取引情報記憶部３３に格納された決済順序３３６に基づき、取引グループ決済試行手段３５０により前回、試行が失敗した全ての取引についての決済を試行することにより決済順序を調整する。このとき、確定手段３８０は、取引グループ決済試行手段３５０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、取引グループ決済試行手段３５０により試行が成功した最後の取引の決済順序までを決済可能な順序としてさらに確定する。
【００３７】
ここで、取引グループが決済順序に関わらず、そもそも取引元の口座の初期残高が不足していたために決済不可能であったことを赤残連鎖取引と呼ぶ。上述した手段により、赤残連鎖取引について、初期残高の不足を解消した場合に決済可能な決済順序を確定することができる。また、初期残高が不足している口座を特定でき、当該口座の持ち主へ不足額の解消を依頼する通知をすることにより、初期残高の不足が解消した後、直ちに決済可能となるため、不要に取引を決済不可能とすることがなくなる。よって、決済可能な取引グループを検出する精度を高めることができる。
【００３８】
ここで、取引グループにおけるループ取引について説明する。ループ取引とは、複数の口座間で取引元の口座と取引先の口座とが入れ替わった取引を含む取引グループである。つまり、ループ取引とは、複数の口座間で循環する複数の取引を指す。特に、取引額が同額で循環する場合、当該ループ取引における口座の収支は過不足がない。そのため、残高情報補正手段３６０により初期残高の不足する口座を含む取引グループとして検出することはできない。しかし、上述したようにループ取引は口座の収支に過不足がないため、取引グループ内の初期設定の決済順序と異なる順序とすることで、決済可能となる場合もある。このようなループ取引を擬似ループ取引と呼ぶ。さらに、赤残連鎖取引であったために、初期設定の決済順序では決済可能とならなかったが、初期残高の不足を解消した上で、擬似ループ取引となる取引グループもある。このようなループ取引を、赤残連鎖取引かつ擬似ループ取引と呼ぶ。一方、ループ取引に関係する各口座のいずれにも初期残高が不足している場合には、決済順序に関わらず決済可能とはならない。このようなループ取引を真正ループ取引と呼ぶ。さらに、赤残連鎖取引であり、ループ取引以外の取引のための初期残高の不足を解消したとしても、真正ループ取引となる取引グループもある。このようなループ取引を、赤残連鎖取引かつ真正ループ取引と呼ぶ。
【００３９】
そこで、擬似ループ判定手段３７０は、取引グループ決済試行手段３５０における試行に失敗した取引が存在する場合、取引グループが擬似ループ取引となっているか否かを判定する。擬似ループ判定手段３７０は、端点取引選択手段３７１と、端点取引処理手段３７２と、起点口座選択手段３７３と、起点取引処理手段３７４とを備える。
【００４０】
端点取引選択手段３７１は、確定手段３８０により決済順序が決済可能な順序として確定されなかった場合に、取引グループに含まれる各取引から、取引元の口座が当該取引グループ内の他の取引の取引先の口座と一致しない取引である始点取引と、取引先の口座が当該取引グループ内の他の取引の取引元の口座と一致しない取引である終点取引とを選択する。端点取引処理手段３７２は、始点取引における決済順序を、最初の順序として取引情報記憶部３３を更新し、当該始点取引の決済が確定したと仮定して口座情報記憶部３２に格納された残高情報３２２を更新し、終点取引における決済順序を、最後の順序として取引情報記憶部３３を更新する。
【００４１】
そして、擬似ループ判定手段３７０は、端点取引処理手段３７２により更新された決済順序に基づき、取引グループの内、始点取引及び終点取引を除いた取引についての決済を試行することにより決済順序を調整する。このとき、確定手段３８０は、取引グループ決済試行手段３５０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、取引情報記憶部３３に格納された決済順序３３６を決済可能な順序として確定する。これにより、擬似ループ取引を検出して決済可能な順序として確定することができる。よって、決済可能な取引グループを検出する精度を高めることができる。
【００４２】
また、起点口座選択手段３７３は、擬似ループ判定手段３７０により試行が失敗した取引に含まれる口座から、自己が取引先の口座となる取引が存在し、かつ、自己が取引元の口座となる取引が２以上存在する口座を選択する。起点取引処理手段３７４は、起点口座選択手段３７３により選択された口座が取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて取引情報記憶部３３を更新する。そして、擬似ループ判定手段３７０は、起点取引処理手段３７４により更新された決済順序に基づき、取引グループの内、始点取引及び終点取引を除いた取引についての決済を試行することにより決済順序を調整する。このように、ループ取引における起点となりうる複数の起点取引を特定し、当該複数の起点取引の決済順序における先後関係を入れ替えることにより、試行に成功する場合があり、結果的に試行回数を減らし、効率的に決済順序を確定することができる。
【００４３】
さらに、確定手段３８０は、擬似ループ判定手段３７０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、取引グループ決済試行手段３５０により試行が成功した最後の取引の決済順序までを決済可能な順序として確定するとよい。これにより、擬似ループ取引を検出して決済可能な順序として確定することができる。また、確定手段３８０は、擬似ループ判定手段３７０により調整された決済順序により試行が失敗した場合にも、取引グループ決済試行手段３５０により試行が成功した最後の取引の決済順序までを決済可能な順序として確定してもよい。これにより、赤残連鎖取引又は真正ループ取引であっても、決済可能な取引については決済順序を確定させることができる。逆に、決済不可能な取引を特定することができる。そのため、決済不可能な取引の原因を絞り込み、後処理を効率的に行うことができる。
【００４４】
図５は、本発明の実施の形態１にかかる決済順序確定システム３のハードウェア構成を示すブロック図である。決済順序確定システム３は、ＣＰＵ（Central Processing Unit）３０１と、ＲＡＭ（Random Access Memory）３０２と、ＲＯＭ（Read Only Memory）３０３と、通信部３０４と、ハードディスク３０５とを備える。また、ハードディスク３０５は、不揮発性記憶装置であり、ＯＳ（Operating System）３０６及び決済順序確定プログラム３０７が格納されている。尚、ハードディスク３０５は、口座情報記憶部３２及び取引情報記憶部３３をさらに含むものであってもよい。決済順序確定プログラム３０７は、本発明の実施の形態１にかかる決済順序確定処理が実装されたコンピュータプログラムである。
【００４５】
ＣＰＵ３０１は、決済順序確定システム３における各種処理、ＲＡＭ３０２、ＲＯＭ３０３、通信部３０４及びハードディスク３０５へのアクセス等を制御する。通信部３０４は、口座情報記憶部３２及び取引情報記憶部３３並びにネットワーク２を介して端末１ａ、１ｂ、・・・１ｎとの通信を行う。決済順序確定システム３は、ＣＰＵ３０１が、ＲＡＭ３０２、ＲＯＭ３０３又はハードディスク３０５に格納されたＯＳ３０６及び決済順序確定プログラム３０７を読み込み、実行する。これにより、決済順序確定システム３は、決済順序確定処理を実現することができる。尚、決済順序確定システム３は、複数台のコンピュータサーバに分散して実現されても構わない。
【００４６】
図６は、本発明の実施の形態１にかかる決済順序確定処理の流れを示すフローチャートである。まず、取引グループ生成手段３４０は、端末１ａ、１ｂ、・・・１ｎから取引情報を受け付ける（Ｓ１１）。具体的には、取引グループ生成手段３４０は、受け付けた取引情報に応じて取引ＩＤ３３２を発行し、取引情報に含まれる取引元口座ＩＤ３３３、取引先口座ＩＤ３３４及び取引額３３５に取引ＩＤ３３２を関連付けて取引情報記憶部３３に格納する。次に、取引グループ生成手段３４０は、取引グループ生成処理を行う（Ｓ１２）。尚、取引グループ生成処理の詳細は、図７を用いて後述する。
【００４７】
そして、取引グループ決済試行手段３５０は、取引グループを選択する（Ｓ１３）。具体的には、取引グループ決済試行手段３５０は、取引情報記憶部３３を参照し、複数のグループＩＤ３３１の内、一つを選択する。その後、取引グループ決済試行手段３５０は、決済順序調整処理を行う（Ｓ１４）。尚、決済順序調整処理の詳細は、図９を用いて後述する。引き続き、確定手段３８０は、決済順序を確定する確定処理を行う（Ｓ１５）。尚、確定処理の詳細は、図１８を用いて後述する。
【００４８】
ここで、取引グループ決済試行手段３５０は、未選択の取引グループが存在するか否かを判定する（Ｓ１６）。具体的には、取引グループ決済試行手段３５０は、取引情報記憶部３３を参照し、グループＩＤ３３１の内、未選択のグループが存在するか否かを判定する。ステップＳ１６において、未選択のグループが存在すると判定した場合、全ての取引グループが選択し終えるまでの間、ステップＳ１３乃至Ｓ１６を繰り返し実行する。ステップＳ１６において、未選択のグループが存在しない、すなわち、全てのグループが選択済みであると判定した場合、決済順序確定システム３は、決済順序確定処理を終了する。
【００４９】
図７は、本発明の実施の形態１にかかる取引グループ生成処理の流れを示すフローチャートである。まず、取引グループ生成手段３４０は、取引情報を選択する（Ｓ２１）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、複数の取引ＩＤ３３２の内、一つを選択する。次に、取引グループ生成手段３４０は、選択した取引情報に関連する取引情報が存在するか否かを判定する（Ｓ２２）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、ステップＳ２１において選択した取引ＩＤ３３２に関連付けられた取引元口座ＩＤ３３３及び取引先口座ＩＤ３３４を取得する。そして、取引グループ生成手段３４０は、取得した取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４の口座ＩＤを検索キーとして、取引情報記憶部３３を検索する。そして、検索キーと一致する取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４が関連付けられた取引ＩＤ３３２が存在するか否かを判定する。
【００５０】
ステップＳ２２において、関連する取引情報が存在すると判定した場合、取引グループ生成手段３４０は、当該関連する取引情報を選択する（Ｓ２３）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、複数の取引ＩＤ３３２の内、ステップＳ２２において、検索キーと一致する取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４が関連付けられた取引ＩＤ３３２を全て選択する。その後、取引グループ生成手段３４０は、ステップＳ２３において選択した取引ＩＤ３３２に関連する取引情報を選択する。以後、関連する取引情報が存在しなくなるまでの間、ステップＳ２２及びＳ２３を繰り返し実行する。尚、ステップＳ２２において、取引グループ生成手段３４０は、未選択の口座ＩＤについて、未選択の取引情報の中から検索を行うものとする。また、ステップＳ２３において複数の関連する取引情報が選択された場合、それぞれについてステップＳ２２及びＳ２３を繰り返し実行する。例えば、ステップＳ２２において、図３の取引ｔ１１が選択された場合、取引元の口座ａ１Ｂを取引元口座ＩＤ３３３とする取引ｔ１４と、取引先口座ＩＤ３３４とする取引ｔ１３とが関連する取引情報として選択される。一方、取引ｔ１１の取引先の口座ａ１Ｅを取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４とする取引は存在しないため、口座ａ１Ｅに関連する取引情報は選択されない。そして、取引ｔ１４における取引先の口座ａ１Ｄと、取引ｔ１３の取引元の口座ａ１Ａとのいずれかに関連する取引情報として、取引ｔ１２が選択される。その後、取引ｔ１２の取引元の口座ａ１Ａに関連する取引情報（取引ｔ１３）が選択済みであり、取引先の口座ａ１Ｃに関連する取引情報が存在しないため、ステップＳ２２において、関連する取引情報が存在しないと判定される。
【００５１】
ステップＳ２２において、関連する取引情報が存在しないと判定した場合、取引グループ生成手段３４０は、取引グループを生成する（Ｓ２４）。具体的には、取引グループ生成手段３４０は、一つのグループＩＤ３３１を発行し、選択した複数の取引ＩＤ３３２に関連付けてグループＩＤ３３１を取引情報記憶部３３に格納する。
【００５２】
そして、取引グループ生成手段３４０は、取引グループ内の取引情報に決済順序を設定する（Ｓ２５）。具体的には、取引グループ生成手段３４０は、所定の項目についてソートを行う。そして、取引グループ生成手段３４０は、ソート結果に従い決済順序を設定する。すなわち、取引グループ生成手段３４０は、選択されたグループＩＤ３３１に関連付けられた取引ＩＤ３３２について、所定のソート順に基づき、並び替えを行い、並び替えた結果に基づき、各取引ＩＤ３３２に対応する決済順序３３６に順序番号を設定して取引情報記憶部３３を更新する。
【００５３】
例えば、受け付けた順序、取引の種別等を考慮してソートを行う。取引の種別によっては、他の取引種別が決済可能となるための前提となるものや、優先して決済しなければならないものがあるため、特定の取引の種別を優先してソートを行う。また、債券取引の場合、債券の券種が小さいものを優先してソートを行ってもよい。つまり、業務における優先順位に基づき決済順序を初期設定することにより、決済順序試行処理において、少ない試行回数により試行が成功しやすくなる。
【００５４】
続いて、取引グループ生成手段３４０は、未選択の取引情報が存在するか否かを判定する（Ｓ２６）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、取引ＩＤ３３２の内、未選択の取引情報が存在するか否かを判定する。ステップＳ２６において、未選択の取引情報が存在すると判定した場合、取引グループ生成手段３４０は、未選択の取引ＩＤ３３２の内、一つを選択する（Ｓ２７）。その後、全ての取引情報について選択し終えるまでの間、ステップＳ２２乃至Ｓ２７を繰り返し実行する。
【００５５】
ステップＳ２６において、未選択の取引情報が存在しない、つまり、全ての取引情報が選択済みであると判定した場合、取引グループ生成手段３４０は、取引グループ生成処理を終了する。尚、ステップＳ２５は、全ての取引グループ生成処理の最後に、まとめて決済順序を設定してもよい。上述した図３は、本発明の実施の形態１にかかる取引グループ生成処理の実行結果の一例である。
【００５６】
図８は、本発明の実施の形態１にかかる取引グループの例を示す図である。尚、図８（ａ）〜（ｆ）は、図３の取引グループｇ１〜ｇ６について、口座と取引との関係を概念で示した図である。また、図８（ｇ）は、図８（ａ）〜（ｆ）における一取引の凡例である。以下の決済順序調整処理及び確定処理の説明においては、適宜、図２、図３及び図８に例示した残高情報、取引グループ及び取引情報を用いる。
【００５７】
図９は、本発明の実施の形態１にかかる決済順序調整処理の流れを示すフローチャートである。まず、取引グループ決済試行手段３５０は、取引グループ決済試行処理を行う（Ｓ３０１）。ここで、図１０は、本発明の実施の形態１にかかる取引グループ決済試行処理の流れを示すフローチャートである。まず、繰り返し実行手段３５３は、Ｎ及びＬに初期値を設定する（Ｓ４１）。ここで、Ｎは、後述するステップＳ４２の決済試行処理において参照する決済順序の番号であり、決済試行処理を繰り返し実行するためのループカウンタである。つまり、ステップＳ４１では、決済試行処理の対象とする最初の決済順序を設定する。また、Ｌは、決済試行処理において参照する決済順序の番号の上限値である。尚、図９のステップＳ３０１においては、Ｎに"１"を設定し、Ｌに図６のステップＳ１３において選択された取引グループに含まれる取引数を設定する。尚、このとき、併せて、成功回数Ｍは、"０"に設定される
【００５８】
次に、繰り返し実行手段３５３は、決済試行処理を行う（Ｓ４２）。ここで、図１１は、本発明の実施の形態１にかかる決済試行処理の流れを示すフローチャートである。まず、取引決済試行手段３５１は、Ｎ番目の取引の決済を試行する（Ｓ５１）。例えば、図１０のステップＳ４１の直後、かつ、１回目の試行においては、Ｎは"１"であるため、繰り返し実行手段３５３は、"Ｎ＝１"として取引決済試行手段３５１を実行させる。そして、取引決済試行手段３５１は、口座情報記憶部３２及び取引情報記憶部３３を参照し、決済順序３３６がＮ番目の取引の決済を試行する。すなわち、取引決済試行手段３５１は、決済順序３３６がＮ番目である取引ＩＤ３３２に関連付けられた取引元口座ＩＤ３３３及び取引先口座ＩＤ３３４を特定し、取引額３３５を取得する。そして、取引決済試行手段３５１は、特定した取引元口座ＩＤ３３３に対応する残高情報３２２を口座情報記憶部３２から取得する。続いて、取引決済試行手段３５１は、取得した残高情報３２２が取得した取引額３３５以上であるか否かを判定する。
【００５９】
続いて、残高情報更新手段３５２は、ステップＳ５１における試行が成功したか否かを判定する（Ｓ５２）。具体的には、ステップＳ５１において、Ｎ番目の取引ＩＤ３３２における取引元口座ＩＤ３３３の残高情報３２２が、当該取引ＩＤ３３２における取引額３３５以上であると判定した場合、残高情報更新手段３５２は、当該試行が成功したと判定する。一方、取引額３３５未満であると判定した場合、残高情報更新手段３５２は、当該試行が失敗したと判定する。尚、残高情報更新手段３５２は、ステップＳ５１における試行が成功したか否かの判定結果（不図示）を、取引ＩＤ３３２に関連付けて取引情報記憶部３３に格納するものとする。また、２巡目以降が実行される場合、個別に記憶することが望ましい。ステップＳ５２において、当該試行が失敗したと判定した場合、ステップＳ５５へ進む。
【００６０】
ステップＳ５２において、当該試行が成功したと判定した場合、残高情報更新手段３５２は、成功回数Ｍに"１"を加算する（Ｓ５３）。そして、残高情報更新手段３５２は、残高情報３２２を更新する（Ｓ５４）。具体的には、まず、残高情報更新手段３５２は、上記特定した取引元口座ＩＤ３３３に対応する残高情報３２２から取引額３３５を減算した結果を、取引元口座ＩＤ３３３における残高情報３２２として口座情報記憶部３２を更新する。また、残高情報更新手段３５２は、上記特定した取引先口座ＩＤ３３４に対応する残高情報３２２に取引額３３５を加算した結果を、取引先口座ＩＤ３３４における残高情報３２２として口座情報記憶部３２を更新する。
【００６１】
その後、繰り返し実行手段３５３は、ＮがＬ未満であるか否かを判定する（Ｓ５５）。すなわち、繰り返し実行手段３５３は、決済が未試行である取引が存在するか否かにより、取引決済試行手段３５１の処理及び残高情報更新手段３５２の処理を繰り返し実行すべきか否かを判定する。ステップＳ５５において、ＮがＬ未満であると判定した場合、繰り返し実行手段３５３は、Ｎに"１"を加算する（Ｓ５６）。その後、全ての取引について決済順序に従って試行を終えるまでの間、ステップＳ５１乃至Ｓ５６を繰り返し実行する。ステップＳ５５において、ＮがＬ以上であると判定した場合、つまり、全ての取引について試行を終えた場合、繰り返し実行手段３５３は、決済試行処理を終了する。
【００６２】
図１２及び図１３は、本発明の実施の形態１にかかる取引グループ決済試行処理の実行結果の例を示す図である。図１２（ａ）〜（ｃ）は、図８に示した取引グループｇ１〜ｇ３における１巡目並びに取引グループｇ１及びｇ２における２巡目の決済試行処理の実行結果の例を示す図である。図１３（ｄ）〜（ｆ）は、図８に示した取引グループｇ４〜ｇ６における１巡目の決済試行処理の実行結果の例を示す図である。
【００６３】
例えば、取引グループｇ１の場合、１巡目の決済試行処理では、決済順序に従い、取引ｔ１１、ｔ１２、ｔ１３、ｔ１４の順序で決済が試行される。まず、決済順序"１"である取引ｔ１１については、取引額が"１０"であるところ、取引元口座ａ１Ｂの残高情報が"０"である。そのため、残高情報更新手段３５２は、取引ｔ１１の試行が失敗すると判定する（Ｓ５２）。よって、取引元口座ａ１Ｂ及び取引先口座ａ１Ｅの残高情報は更新されない。次に、決済順序"２"である取引ｔ１２については、取引額が"１０"であるところ、取引元口座ａ１Ａの残高情報が"３０"である。そのため、残高情報更新手段３５２は、取引ｔ１２の試行が成功すると判定する（Ｓ５２）。よって、残高情報更新手段３５２は、成功回数Ｍを"１"とし（Ｓ５３）、取引元口座ａ１Ａの残高情報"３０"から取引額"１０"を減算した"２０"として口座情報記憶部３２の口座ＩＤ"ａ１Ａ"の残高情報３２２を更新する。また、残高情報更新手段３５２は、取引先口座ａ１Ｃの残高情報"０"に取引額"１０"を加算した"１０"として口座情報記憶部３２の口座ＩＤ"ａ１Ｃ"の残高情報３２２を更新する（Ｓ５４）。その後、決済順序"３"である取引ｔ１３については、取引額が"２０"であるところ、取引元口座ａ１Ａの残高情報が"２０"である。そのため、残高情報更新手段３５２は、取引ｔ１３の試行が成功すると判定（Ｓ５２）し、上述したようにステップＳ５３及びＳ５４を行う。さらに、決済順序"４"である取引ｔ１４については、取引額が"１０"であるところ、取引元口座ａ１Ｂの残高情報が"１０"である。そのため、残高情報更新手段３５２は、取引ｔ１４の試行が成功すると判定（Ｓ５２）し、上述したようにステップＳ５３及びＳ５４を行う。
【００６４】
以上が取引グループｇ１における１巡目の決済試行処理の流れである。図１２（ａ）の１巡目の成否の"○"が試行に成功した取引を示し、"×"が試行に失敗した取引を示す。また、同様に、図１２（ｂ）（ｃ）、図１３（ｄ）〜（ｆ）が取引グループｇ２からｇ６についての１巡目の決済試行処理の結果を示す。
【００６５】
図１０に戻り、決済順序更新手段３５４は、ステップＳ４２の結果により再試行を行う必要があるか否かを判定する（Ｓ４３）。すなわち、決済順序更新手段３５４は、ステップＳ４２の結果、試行が成功した取引における決済順序以前に、試行が失敗した取引が存在するか否かを判定する。つまり、決済順序更新手段３５４は、少なくとも試行が最後に成功した取引における決済順序以前に、試行が失敗した取引が１以上存在するか否かを判定することとなる。
【００６６】
例えば、図１２（ａ）では、試行が成功した取引ｔ１２〜ｔ１４の決済順序"２"〜"４"以前に、試行が失敗した取引ｔ１１が存在する。そのため、決済順序更新手段３５４は、取引グループｇ１について再試行を行う必要があると判定する。また、図１２（ｂ）では、試行が成功した取引ｔ２１の決済順序"１"以前には、試行が失敗した取引が存在しないが、試行が成功した取引ｔ２３の決済順序"３"以前には、試行が失敗した取引ｔ２２が存在する。そのため、決済順序更新手段３５４は、取引グループｇ２について再試行を行う必要があると判定する。また、図１２（ｃ）及び図１３（ｄ）では、全ての取引について試行が失敗しているため、決済順序更新手段３５４は、取引グループｇ３及びｇ４について再試行を行う必要がないと判定する。これは、試行が成功していないため、各口座の残高が更新されておらず、試行を行う際の条件が変更していないため、再試行により結果の差が生じえないためである。さらに、図１３（ｅ）及び（ｆ）では、最後に試行が成功した取引ｔ５２又はｔ６２の決済順序"２"以前には、試行が失敗した取引が存在しないため、決済順序更新手段３５４は、取引グループｇ５及びｇ６について再試行を行う必要がないと判定する。
【００６７】
ステップＳ４３において、再試行を行う必要があると判定した場合、決済順序更新手段３５４は、決済順序を更新する（Ｓ４４）。すなわち、決済順序更新手段３５４は、試行が失敗した全ての取引における決済順序が、試行が成功した全ての取引（成功数Ｍ）における決済順序より後の順序である"Ｍ＋１"以降となるように取引情報記憶部３３を更新する。具体的には、まず、決済順序更新手段３５４は、試行が成功した各取引における決済順序を、当該試行が成功した時点における成功した取引の成功数Ｍとして、取引情報記憶部３３を更新する。次に、決済順序更新手段３５４は、試行が失敗した全ての取引における決済順序を、Ｍ＋１以上かつＬ以下として、取引情報記憶部３３を更新する。
【００６８】
例えば、図１２（ａ）では、まず、試行が成功した全ての取引ｔ１２、ｔ１３及びｔ１４の２巡目の決済順序として、それぞれ"１"、"２"及び"３"とする。次に、試行が失敗した全ての取引ｔ１１の２巡目の決済順序として、"３"に"１"を加算した"４"とする。同様に、図１２（ｂ）では、試行が成功した全ての取引ｔ２１及びｔ２３の２巡目の決済順序として、それぞれ"１"及び"２"とし、試行が失敗した取引ｔ２２の２巡目の決済順序として、"２"に"１"を加算した"３"、そして、取引ｔ２４の２巡目の決済順序として、"４"とする。
【００６９】
尚、図１１のステップＳ５３における成功数Ｍの算出処理は、ステップＳ４４において、決済順序更新手段３５４が取引決済試行手段３５１の試行結果を基に集計することにより実行しても構わない。
【００７０】
また、決済順序更新手段３５４は、成功した取引の決済順序の更新を図１１のステップＳ５３の後に実行しても構わない。すなわち、決済順序更新手段３５４は、取引決済試行手段３５１における試行が成功した場合に、当該Ｎ番目の取引における決済順序を、ステップＳ５３により加算後の成功数Ｍとして、取引情報記憶部３３を更新しても構わない。
【００７１】
続いて、繰り返し実行手段３５３は、Ｎに"Ｍ＋１"を代入する（Ｓ４５）。その後、再試行を行う必要がある間、ステップＳ４２乃至Ｓ４５を繰り返し実行する。ステップＳ４３において、再試行を行う必要がないと判定した場合、取引グループ決済試行手段３５０は、取引グループ決済試行処理を終了する。
【００７２】
尚、ステップＳ４３において、再試行を行う必要があると判定した場合、決済順序更新手段３５４は、最後に試行が成功した取引における決済順序を特定し、試行が失敗した全ての取引における決済順序を、当該特定された決済順序より後の順序として、取引情報記憶部３３を更新する。この場合、必ずしも試行に成功した取引の決済順序を更新しなくてもよい。この場合、決済順序更新手段３５４による更新後に、繰り返し実行手段３５３は、試行が失敗した全ての取引について、取引情報記憶部３３に格納された決済順序に基づいてＮを昇順に更新して、取引決済試行手段３５１の処理及び残高情報更新手段３５２の処理を繰り返し実行する。
【００７３】
例えば、図１２（ａ）では、最後に試行が成功した取引ｔ１４における決済順序が"４"であることを特定し、取引ｔ１１の２巡目の決済順序として、"４"に"１"を加算した"５"としてもよい。同様に、図１２（ｂ）では、最後に試行が成功した取引ｔ２３における決済順序が"３"であることを特定し、取引ｔ２２及びｔ２４の２巡目の決済順序として、それぞれ"４"及び"５"としてもよい。但し、この場合、ステップＳ４２を再度実行する際に、Ｎを"最後に試行が成功した取引における決済順序＋１"とし、Ｌを"最後に試行が成功した取引における決済順序＋失敗した取引総数"とする。これにより、試行が成功した取引における決済順序を更新する処理を減らし、処理コストを減らすことができる。
【００７４】
図９に戻り、取引グループ決済試行手段３５０は、試行に失敗した取引が存在するか否かを判定する（Ｓ３０２）。例えば、取引グループ決済試行手段３５０は、取引情報記憶部３３を参照し、取引ＩＤ３３２に関連付けられた判定結果に基づき判定する。ステップＳ３０２において、試行に失敗した取引が存在しないと判定した場合、つまり、対象の取引グループにおける全ての取引についてステップＳ３０１における試行が成功した場合、取引グループ決済試行手段３５０は、当該取引グループが"通常取引"であると判定する（Ｓ３１０）。図８の例では、取引グループｇ１のみが"通常取引"であると判定される。このとき、取引グループ決済試行手段３５０は、"通常取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００７５】
ステップＳ３０２において、試行に失敗した取引が存在すると判定した場合、つまり、対象の取引グループにおける取引の中にステップＳ３０１における試行が失敗した取引が含まれる場合、残高情報補正手段３６０は、口座当たりの収支残高を算出する（Ｓ３０３）。図８の例では、取引グループｇ２〜ｇ６がステップＳ３０３の対象となる。残高情報補正手段３６０は、口座情報記憶部３２及び取引情報記憶部３３を参照し、各取引グループに含まれる口座ごとに以下の処理を行う。具体的には、まず、残高情報補正手段３６０は、口座情報記憶部３２から対象口座の残高情報３２２を取得する。次に、残高情報補正手段３６０は、取引情報記憶部３３を参照し、対象口座を取引元又は取引先の口座とする全ての取引を選択し、選択した取引ＩＤ３３２における取引額３３５から取引元及び取引先のそれぞれの合計を算出する。そして、残高情報補正手段３６０は、取得した残高情報３２２に、対象口座を取引先の口座とする取引の取引額３３５の合計を加算し、対象口座を取引元の口座とする取引の取引額３３５の合計を減算する。そして、その結果である口座当たりの収支残高（不図示）を対象口座に関連付けて口座情報記憶部３２に格納する。
【００７６】
ここで、図１４は、本発明の実施の形態１にかかる口座収支算出処理の実行結果の例を示す図である。図１４（ａ）〜（ｅ）は、それぞれ取引グループｇ２〜ｇ６における口座収支の例を示す図である。図１４（ａ）では、例えば、口座ａ２Ｂを対象口座とした場合、まず、残高情報補正手段３６０は、初期残高"０"を取得する。次に、残高情報補正手段３６０は、口座ａ２Ｂを取引先の口座とする取引ｔ２１の取引額"１０"を取得する。このとき、取引額合計（入）は、"１０"である。また、残高情報補正手段３６０は、口座ａ２Ｂを取引元の口座とする取引ｔ２３及びｔ２４の取引額"１０"及び"１０"を取得する。このとき、取引額合計（払）は、"２０"である。そして、残高情報補正手段３６０は、初期残高"０"に、取引額合計（入）"１０"を加算し、取引額合計（払）"２０"を減算して、収支残高"−１０"を算出し、口座情報記憶部３２に格納する。その他、図１４（ａ）〜（ｅ）について同様に口座当たりの収支残高が算出される。
【００７７】
その後、残高情報補正手段３６０は、取引グループ内に収支残高が赤字となる赤字口座が存在するか否かを判定する（Ｓ３０４）。すなわち、残高情報補正手段３６０は、ステップＳ３０３において算出された収支残高が所定値以下となる口座が存在するか否かを判定する。具体的には、残高情報補正手段３６０は、口座情報記憶部３２を参照し、収支残高がマイナスである口座が存在するか否かを確認する。例えば、図１４（ａ）の場合、口座ａ２Ａ及びａ２Ｂの収支残高がマイナスであるため、取引グループｇ２内に赤字口座が存在すると判定される。同様に、図１４（ｂ）及び（ｃ）に基づき、取引グループｇ３及びｇ４内に赤字口座が存在すると判定される。一方、図１４（ｄ）及び（ｅ）の場合、収支残高がマイナスとなる口座が存在しないため、取引グループｇ５及びｇ６内に赤字口座が存在しないと判定される。ステップＳ３０４において、取引グループ内に赤字口座が存在しないと判定された場合、ステップＳ３０８へ進む。
【００７８】
ステップＳ３０４において、取引グループ内に赤字口座が存在すると判定された場合、残高情報補正手段３６０は、残高を補正する（Ｓ３０５）。すなわち、残高情報補正手段３６０は、残高が所定値となる取引額を加算して口座情報記憶部３２に格納された残高情報３２２を補正する。例えば、残高情報補正手段３６０は、取引グループｇ２の口座ａ２Ａの残高情報３２２に、"１０"を加算して口座情報記憶部３２を更新する。同様に、取引グループｇ２、ｇ３及びｇ４における口座ａ２Ｂ、ａ３Ａ及びａ４Ａの残高情報３２２に、不足額を加算して口座情報記憶部３２を更新する。
【００７９】
そして、取引グループ決済試行手段３５０は、取引グループ決済試行処理を実行する（Ｓ３０６）。すなわち、取引グループ決済試行手段３５０は、残高情報補正手段３６０により補正された残高情報を用いて、取引情報記憶部３３に格納された決済順序３３６に基づき、取引グループ決済試行手段３５０により前回、試行が失敗した全ての取引についての決済を試行することにより決済順序を調整する。
【００８０】
ここで、図１５は、本発明の実施の形態１にかかる残高補正処理後の取引グループ決済試行処理の実行結果の例を示す図である。図１５（ａ）〜（ｃ）は、それぞれ取引グループｇ２〜ｇ４のステップＳ３０６における１巡目の決済試行処理の実行結果の例を示す図である。図１５（ａ）の場合、ステップＳ３０１の実行後の決済順序に従い、ステップＳ３０１により試行が失敗した取引ｔ２２及びｔ２４のみについて、口座ａ２Ａ及びａ２Ｂの残高が補正された状態として、決済を試行する。そして、取引ｔ２２及びｔ２４が共に試行に成功する。尚、この場合、図９のステップＳ３０６においては、Ｎに"３"を設定し、Ｌに"４"を設定して、図１０の取引グループ決済試行処理を実行する。そのため、残高を補正する前に試行が成功した取引ｔ２１及びｔ２３については、試行の対象とならない。よって、不要な処理を減らすことができる。同様に、図１５（ｂ）及び（ｃ）の場合、図９のステップＳ３０６においては、Ｎに"１"を設定し、Ｌに"５"を設定して、図１０の取引グループ決済試行処理を実行する。ここでは、決済順序"１"及び"２"のみが試行に成功するが、以降の取引の試行は失敗する。
【００８１】
図９に戻り、取引グループ決済試行手段３５０は、ステップＳ３０２と同様に、試行に失敗した取引が存在するか否かを判定する（Ｓ３０７）。ステップＳ３０７において、試行に失敗した取引が存在しないと判定した場合、取引グループ決済試行手段３５０は、当該取引グループが"赤残連鎖取引"であると判定する（Ｓ３１１）。図８の例では、取引グループｇ２のみが"赤残連鎖取引"であると判定される。このとき、取引グループ決済試行手段３５０は、"赤残連鎖取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００８２】
その後、擬似ループ判定手段３７０は、擬似ループ判定処理を行う（Ｓ３０８）。ここで、図１６は、本発明の実施の形態１にかかる擬似ループ判定処理の流れを示すフローチャートである。尚、以下では、図８においては、取引グループｇ３〜ｇ６が処理対象となる。
【００８３】
まず、端点取引選択手段３７１は、始点及び終点取引を選択する（Ｓ６１）。具体的には、端点取引選択手段３７１は、取引情報記憶部３３を参照し、処理対象の取引グループ内の取引について、取引元口座ＩＤ３３３が他の取引の取引先口座ＩＤ３３４と一致しない取引である始点取引を選択する。また、端点取引選択手段３７１は、取引情報記憶部３３を参照し、処理対象の取引グループ内の取引について、取引先口座ＩＤ３３４が他の取引の取引元口座ＩＤ３３３と一致しない取引である終点取引を選択する。尚、始点及び終点取引を端点取引と呼ぶものとする。例えば、取引グループｇ３の場合、始点取引が取引ｔ３１、終点取引が取引ｔ３２として選択される。同様に、取引グループｇ４、ｇ５及びｇ６の場合、それぞれ始点取引が取引ｔ４１、ｔ５１及びｔ６１、また、終点取引が取引ｔ４２、ｔ５２及びｔ６２として選択される。
【００８４】
次に、端点取引処理手段３７２は、始点及び終点取引の決済順序を更新する（Ｓ６２）。具体的には、端点取引処理手段３７２は、始点取引における決済順序を、最初の順序として取引情報記憶部３３を更新し、終点取引における決済順序を、最後の順序として取引情報記憶部３３を更新する。例えば、取引グループｇ３の場合、端点取引選択手段３７１は、始点取引である取引ｔ３１の決済順序を"１"とし、終点取引である取引ｔ３２の決済順序を"５"として取引情報記憶部３３を更新する。同様に、取引グループｇ４、ｇ５及びｇ６の場合、端点取引選択手段３７１は、それぞれ始点取引である取引ｔ４１、ｔ５１及びｔ６１の決済順序を"１"とし、終点取引である取引ｔ４２、ｔ５２及びｔ６２の決済順序を"５"として取引情報記憶部３３を更新する。尚、始点取引又は終点取引が複数存在する場合、決済順序を同じ値とするとよい。
【００８５】
続いて、端点取引処理手段３７２は、始点取引に関する残高情報を更新する（Ｓ６３）。具体的には、端点取引処理手段３７２は、当該始点取引の決済が確定したと仮定して口座情報記憶部３２に格納された残高情報３２２を更新する。例えば、取引グループｇ３の場合、端点取引選択手段３７１は、始点取引の決済を試行して成功する場合に、図１１のステップＳ５４に基づき、取引元の口座である口座ａ３Ａ及び取引先の口座である口座ａ３Ｂのそれぞれの残高情報３２２を決済後の残高情報へ更新する。尚、ステップＳ３０５において、残高情報補正手段３６０により残高が補正された口座については、さらに、残高情報が更新されることとなる。
【００８６】
そして、擬似ループ判定手段３７０は、始点及び終点取引を除いて、取引グループ決済試行手段３５０により取引グループ決済試行処理を実行する（Ｓ６４）。例えば、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、決済順序が２以上かつ取引数未満となるように取引情報記憶部３３を更新する。そして、Ｎに"２"を設定し、Ｌに"取引数−１"を設定して、図１０の取引グループ決済試行処理を実行する。尚、ステップＳ６４においては、擬似ループ判定処理の対象となる取引グループに始点取引が存在しない場合、Ｎに"１"を設定する。また、終点取引が存在しない場合、Ｌに"取引数"を設定する。そして、図１０の取引グループ決済試行処理を実行する。例えば、取引グループがループ取引のみである場合や、始点取引又は終点取引の一方が存在しない場合が該当する。また、始点取引又は終点取引が複数存在する場合、Ｎに"３"以上の値を設定し、Ｌに"取引数−１"未満の値を設定して、図１０の取引グループ決済試行処理を実行する。
【００８７】
例えば、取引グループｇ３の場合、擬似ループ判定手段３７０は、始点又は終点取引以外の取引である取引ｔ３３、ｔ３４及びｔ３５について、決済順序を"２"〜"４"として更新する。そして、Ｎに"２"を設定し、Ｌに"４"を設定して、図１０の取引グループ決済試行処理を実行する。ここでは、決済順序"２"の取引ｔ３３の取引元の口座ａ３Ｂの残高情報３２２がステップＳ６３により"１０"に更新されているため、取引ｔ３３の試行が成功する。続いて、決済順序"３"の取引ｔ３４の取引元の口座ａ３Ｄの残高情報３２２が上記の試行により"１０"に更新されているため取引ｔ３４の、試行が成功する。さらに、決済順序"４"の取引ｔ３５の取引元の口座ａ３Ｅの残高情報３２２が上記の試行により"１０"に更新されているため取引ｔ３５の試行が成功する。そのため、決済順序"５"の取引ｔ３２の試行も成功することとなる。つまり、取引グループｇ３は、ステップＳ６４により全ての取引の試行が成功することとなる。また、取引グループｇ５の場合も同様である。このように、ステップＳ３０１及びＳ３０６における取引グループ決済試行処理において、試行に失敗した取引を含む取引グループであっても、ステップＳ６１〜Ｓ６４により、始点及び終点取引を除いた取引に対して試行を行うことにより、決済可能な決済順序を求めることができる。一方、取引グループｇ４及びｇ６の場合、ステップＳ６４によっても試行に失敗する取引が存在する。
【００８８】
その後、擬似ループ判定手段３７０は、ステップＳ３０２と同様に、試行に失敗した取引が存在するか否かを判定する（Ｓ６５）。ステップＳ６５において、試行に失敗した取引が存在しないと判定した場合、擬似ループ判定手段３７０は、擬似ループ判定処理を終了する。
【００８９】
ステップＳ６５において、試行に失敗した取引が存在すると判定した場合、起点口座選択手段３７３は、起点口座を選択する（Ｓ６６）。具体的には、起点口座選択手段３７３は、取引情報記憶部３３を参照し、ステップＳ６４において、試行に失敗した取引に含まれる口座から、１以上の取引先口座ＩＤ３３３かつ２以上の取引元口座ＩＤ３３４として設定される口座を選択する。例えば、取引グループｇ４の場合、口座ａ４Ｂは、取引ｔ４２及びｔ４３の取引元の口座であり、取引ｔ４１及びｔ４５の取引先の口座であるため、起点口座として選択される。また、取引グループｇ６の場合、口座ａ６Ｂは、取引ｔ６２及びｔ６３の取引元の口座であり、取引ｔ６１及びｔ６５の取引先の口座であるため、起点口座として選択される。
【００９０】
さらに、図１７は、本発明の実施の形態１にかかる起点口座が選択される取引グループの顕著な例を示す図である。図１７は、取引グループｇ７について、口座と取引との関係を概念で示した図である。尚、一取引の凡例は、図８（ｇ）と同様であるため、図示を省略する。ここで、取引グループｇ７の決済順序の初期設定が取引ｔ７１、ｔ７２、・・・ｔ７９の順序であるものとする。このとき、ステップＳ３０１において、取引ｔ７１、ｔ７２及びｔ７３までの試行が成功し、取引ｔ７４以降の試行が失敗する。ステップＳ３０４において、赤字口座が存在しないと判定され、擬似ループ判定処理（Ｓ３０８）が実行される。そして、取引グループｇ７の場合、取引ｔ７１が始点取引、取引ｔ７３が終点取引として選択される（Ｓ６１）。その後、ステップＳ６４により、取引ｔ７１及びｔ７３を除いて、取引グループ決済試行処理が実行される。このとき、取引ｔ７２、ｔ７４、ｔ７５、ｔ７６までが試行に成功し、取引ｔ７７〜ｔ７９の試行に失敗する。そのため、ステップＳ６５において、試行に失敗した取引が存在すると判定される。そこで、ステップＳ６６において、起点口座選択手段３７３は、取引ｔ７７〜ｔ７９に含まれる口座ａ７Ｂ、ａ７Ｇ及びａ７Ｈから、取引ｔ７２及びｔ７７の取引元の口座であり、取引ｔ７１及びｔ７９の取引先の口座である口座ａ７Ｂを起点口座として選択する。
【００９１】
そして、起点取引処理手段３７４は、起点取引の決済順序を更新する（Ｓ６７）。具体的には、起点取引処理手段３７４は、起点口座選択手段３７３により選択された口座が取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて取引情報記憶部３３を更新する。例えば、取引グループｇ７の場合、起点取引処理手段３７４は、口座ａ７Ｂが取引元の口座となる取引ｔ７７の決済順序を"２"、取引ｔ７２の決済順序を"２"より大きい値として、つまり、取引ｔ７７と取引ｔ７２との決済順序の先後関係を入れ替えて取引情報記憶部３３を更新する。同様に、取引グループｇ４及びｇ６の場合、起点取引処理手段３７４は、取引ｔ４３及びｔ６３の決済順序を"２"、取引ｔ４２及びｔ６２の決済順序を"取引数"として、つまり、取引ｔ４２と取引ｔ４３との決済順序の先後関係を入れ替えて、また、取引ｔ６２と取引ｔ６３との決済順序の先後関係を入れ替えて、取引情報記憶部３３を更新する。尚、ステップＳ６７においては、擬似ループ判定処理の対象となる取引グループに起点取引が存在しない場合、取引情報記憶部３３を更新しない。また、取引ｔ７７、ｔ４３及びｔ６３の決済順序は、"２"でなくとも構わない。
【００９２】
その後、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、取引グループ決済試行処理を行う（Ｓ６８）。このとき、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、取引グループ決済試行処理を行う。このとき、複数の起点取引の決済順序における先後関係を適宜入れ替えて、取引情報記憶部３３を更新し、取引グループ決済試行処理を行うとよい。そして、全ての取引について試行が成功するか、全ての順序の組み合わせについて試行が終了するまで繰り返し、決済の試行を行う。これにより、赤字口座が存在しない状態の対象の取引グループについて、決済可能か否かについて確実に判明させることができる。尚、ステップＳ６８では、対象となる複数の取引における決済順序の様々な組み合わせについて試行するため、処理時間が長くなる。しかし、ステップＳ６８の処理対象となる取引グループの数は、ステップＳ６４以前の処理により絞りこまれているため、少ないといえる。よって、ステップＳ６８の処理を行う効果が高いといえる。その後、擬似ループ判定手段３７０は、擬似ループ判定処理を終了する。尚、ステップＳ６６乃至Ｓ６８に代えて、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、単に、総当たりにして決済の試行を行ってもよい。
【００９３】
例えば、取引グループｇ７の場合、擬似ループ判定手段３７０は、始点取引ｔ７１及び終点取引ｔ７３を除いた取引ｔ７２、ｔ７４、ｔ７５、ｔ７６、ｔ７７、ｔ７８、ｔ７９について、起点取引ｔ７２及びｔ７７の決済順序の先後関係を入れ替えて、全ての決済順序の組み合わせについて試行を行う。これにより、取引ｔ７１、ｔ７７、ｔ７８、ｔ７９、ｔ７２、ｔ７４、ｔ７５、ｔ７６、ｔ７３の順序により決済可能であることが判明する。一方、取引グループｇ４及びｇ６の場合、全ての決済順序の組み合わせを試行しても決済可能な決済順序が存在しないことが判明する。
【００９４】
図９に戻り、擬似ループ判定手段３７０は、ステップＳ３０２と同様に、試行に失敗した取引が存在するか否かを判定する（Ｓ３０９）。ステップＳ３０９において、試行に失敗した取引が存在しないと判定した場合、擬似ループ判定手段３７０は、当該取引グループが"擬似ループ取引"であると判定する（Ｓ３１２）。尚、当該取引グループがステップＳ３０４により赤字口座が存在すると判定されていた場合、擬似ループ判定手段３７０は、当該取引グループが"赤残連鎖取引"かつ"擬似ループ取引"であると判定する。図８の例では、取引グループｇ５が"擬似ループ取引"であると判定され、取引グループｇ３が"赤残連鎖取引"かつ"擬似ループ取引"であると判定される。また、図１７の例である取引グループｇ７が"擬似ループ取引"であると判定される。このとき、擬似ループ判定手段３７０は、"擬似ループ取引"又は"赤残連鎖取引"かつ"擬似ループ取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００９５】
ステップＳ３０９において、試行に失敗した取引が存在すると判定した場合、擬似ループ判定手段３７０は、当該取引グループが"真正ループ取引"であると判定する（Ｓ３１３）。尚、当該取引グループがステップＳ３０４により赤字口座が存在すると判定されていた場合、擬似ループ判定手段３７０は、当該取引グループが"赤残連鎖取引"かつ"真正ループ取引"であると判定する。図８の例では、取引グループｇ６が"真正ループ取引"であると判定され、取引グループｇ４が"赤残連鎖取引"かつ"真正ループ取引"であると判定される。このとき、擬似ループ判定手段３７０は、"真正ループ取引"又は"赤残連鎖取引"かつ"真正ループ取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００９６】
図１８は、本発明の実施の形態１にかかる確定処理の流れを示すフローチャートである。まず、確定手段３８０は、取引情報記憶部３３を参照し、処理対象の取引グループにおける判定結果を確認する（Ｓ７０１）。ステップＳ７０１において判定結果が"通常取引"と確認された場合、確定手段３８０は、処理対象の取引グループにおける全取引のＳ３０１後の決済順序を決済可能なものとして確定する（Ｓ７０２）。例えば、取引グループｇ１の場合、図１２（ａ）の２巡目の決済順序が決済可能なものとして確定される。ここで、確定する処理として、例えば、当該取引グループに含まれる全ての取引の決済を実行するべく勘定系システム等へ通知するか、または、当該取引グループに含まれる口座の所有者へ決済可能である旨を通知する等であるとよい。
【００９７】
ステップＳ７０１において判定結果が"赤残連鎖取引"のみと確認された場合、確定手段３８０は、ステップＳ３０１後の決済順序の内、赤残取引より前の取引の決済順序を決済可能なものとして確定する（Ｓ７０３）。ここで、赤残取引とは、図９のステップＳ３０５による残高情報の補正された口座を取引元の口座とする取引の内、ステップＳ３０６において、決済の試行が成功した取引である。例えば、取引グループｇ２の場合、図１５（ａ）の赤残取引である取引ｔ２２以前の決済順序である取引ｔ２１及び取引ｔ２３の決済順序"１"及び"２"が決済可能なものとして確定される。
【００９８】
そして、確定手段３８０は、ステップＳ３０５により残高が補正された口座へ残高不足通知を行う（Ｓ７０４）。ここで、残高不足通知として、例えば、通知対象の口座の所有者へ残高不足であるために決済が行えない旨と、不足額を当該口座へ追加する旨等を通知するとよい。例えば、取引グループｇ２の場合、確定手段３８０は、口座ａ２Ａ及びａ２Ｂへ残高不足通知を行う。
【００９９】
ステップＳ７０１において判定結果が"擬似ループ取引"を含むと確認された場合、確定手段３８０は、さらに、判定結果が"赤残連鎖取引"を含むか否かを判定する（Ｓ７０５）。ステップＳ７０５において、判定結果が"赤残連鎖取引"を含むと判定した場合、確定手段３８０は、ステップＳ３０８後の決済順序の内、赤残取引より前の取引の決済順序を決済可能なものとして確定する（Ｓ７０６）。例えば、取引グループｇ３の場合、図１５（ｂ）の赤残取引である取引ｔ３１以前の決済順序である取引は存在しないため、決済可能な決済順序として確定されない。
【０１００】
そして、確定手段３８０は、ステップＳ７０４と同様に、ステップＳ３０５により残高が補正された口座へ残高不足通知を行う（Ｓ７０７）。例えば、取引グループｇ３の場合、確定手段３８０は、口座ａ３Ａへ残高不足通知を行う。
【０１０１】
ステップＳ７０５において、判定結果が"赤残連鎖取引"を含まないと判定した場合、確定手段３８０は、処理対象の取引グループにおける全取引のＳ３０８後の決済順序を決済可能なものとして確定する（Ｓ７０８）。例えば、取引グループｇ５の場合、取引ｔ５１、ｔ５３、ｔ５４、ｔ５５、ｔ５２の決済順序が決済可能なものとして確定される。
【０１０２】
ステップＳ７０１において判定結果が"真正ループ取引"を含むと確認された場合、確定手段３８０は、さらに、判定結果が"赤残連鎖取引"を含むか否かを判定する（Ｓ７０９）。ステップＳ７０９において、判定結果が"赤残連鎖取引"を含まないと判定した場合、ステップＳ７１１へ進む。ステップＳ７０９において、判定結果が"赤残連鎖取引"を含むと判定した場合、確定手段３８０は、ステップＳ７０４と同様に、ステップＳ３０５により残高が補正された口座へ残高不足通知を行う（Ｓ７１０）。例えば、取引グループｇ４の場合、確定手段３８０は、口座ａ４Ａへ残高不足通知を行う。
【０１０３】
その後、確定手段３８０は、ステップＳ３０１で試行が成功した取引の決済順序を確定する（Ｓ７１１）。例えば、取引グループｇ４の場合、図１３（ｄ）に示すように、ステップＳ３０１で試行が成功した取引が存在しないため、決済可能な決済順序として確定されない。取引グループｇ６の場合、図１３（ｆ）の取引ｔ６１及びｔ６２の決済順序"１"及び"２"が決済可能なものとして確定される。
【０１０４】
そして、確定手段３８０は、ループ取引に取引不可通知を行う（Ｓ７１２）。ここで、取引不可通知として、例えば、通知対象の口座の所有者へループ取引であるために決済が行えない旨と、関係する他の口座等を通知するとよい。例えば、取引グループｇ４の場合、確定手段３８０は、口座ａ４Ｂ、ａ４Ｄ及びａ４Ｅへ取引不可通知を行う。取引グループｇ６の場合、確定手段３８０は、口座ａ６Ｂ、ａ６Ｄ及びａ６Ｅへ取引不可通知を行う。
【０１０５】
その後、確定手段３８０は、確定処理を終了する。尚、図１８は、本発明の実施の形態１にかかる確定処理の一例であり、他の方法でも実現可能である。本発明の実施の形態１にかかる確定処理は、少なくとも決済順序調整処理により判定された取引グループの判定結果に応じて各取引の決済順序を確定すればよい。
【０１０６】
このように、本発明の実施の形態１では、取引グループ決済試行処理により、所定の順序により決済が可能である取引については、逐次、決済が確定したものとし、以後の試行の対象から除くものである。すなわち、一旦、試行が成功した取引については、原則として再度の試行を行わないようにする。そのため、総当たりで試行を行うことに比べて、試行回数を減らすことができる。つまり、決済可能な決済順序を網羅的に求めず、実際に決済可能である割合が高いケースを優先的に検出する。よって、複数の取引を連続して決済する場合に、決済可能な決済順序について、少ない試行回数により効率的に確定することができる。
【０１０７】
＜発明の実施の形態２＞
債券等の取引では、債券額を券種及び枚数により取り扱う場合がある。例えば、"１００"を１単位とする券種と、"５０"を１単位とする券種とがある場合、それぞれに券面の枚数を管理する必要がある。そして、取引は、券種及び枚数の指定が可能である。そのため、債券取引の場合、単に、口座の残高の金額において決済可能であっても、券種と枚数により決済不可能となる場合がある。そこで、本発明の実施の形態２にかかる決済順序確定システムは、本発明の実施の形態１にかかる決済順序確定システム３の残高情報補正手段３６０に変更を加えたものである。すなわち、本発明の実施の形態２にかかる残高情報補正手段は、取引が券種及び枚数により定まる債券における取引である場合に、取引グループに含まれる口座の残高における債券の券種及び枚数に基づき、口座当たりの残高を算出するものである。このとき、図１の口座情報記憶部３２には、残高情報３２２に代えて又は別途、債券の券種の識別情報と、当該券種の枚数とを記憶しているものとする。また、図１の取引情報記憶部３３には、取引ＩＤ３３２にかかる債券の券種の識別情報と、当該券種の枚数とを取引ＩＤ３３２に関連付けて記憶しているものとする。尚、本発明の実施の形態２にかかる決済順序確定システムは、本発明の実施の形態１と比べて、上述した以外の構成に変更がない。以下、実施の形態１との違いを中心に説明し、実施の形態１と同等の構成及び処理については、詳細な説明を省略する。
【０１０８】
図１９は、本発明の実施の形態２にかかる券種及び枚数を考慮した取引グループの例を示す図である。図１９（ａ）は、取引グループｇ８について、口座と取引との関係を概念で示した図である。また、図１９（ｂ）は、図１９（ａ）における一取引の凡例である。ここで、取引グループｇ８の決済順序の初期設定が取引ｔ８１、ｔ８２、・・・ｔ８７の順序であるものとする。また、各口座の下の括弧書きは、債券の券種及び枚数の初期残高を示し、各取引の下の取引額の括弧書きが"−"である取引は、債券の券種及び枚数の指定がない取引であるものとする。
【０１０９】
また、図２０（ａ）は、本発明の実施の形態１と同様に取引額のみで口座収支を算出した場合の口座収支の例を示す図である。また、図２０（ｂ）は、本発明の実施の形態２にかかる券種及び枚数を考慮した口座収支の例を示す図である。
【０１１０】
続いて、図９のステップＳ３０３において、口座ａ８Ａについての収支残高を算出する場合を説明する。まず、本発明の実施の形態１にかかる残高情報補正手段３６０は、口座情報記憶部３２から口座ａ８Ａの残高情報"１００"を取得する。そして、残高情報補正手段３６０は、取引情報記憶部３３から口座ａ８Ａを取引先の口座とする取引ｔ８１、ｔ８２及びｔ８３の取引額"２００"、"１００"及び"１５０"を取得し、取引額合計（入）"４５０"を算出する。また、残高情報補正手段３６０は、取引情報記憶部３３から口座ａ８Ａを取引元の口座とする取引ｔ８４、ｔ８５、ｔ８６及びｔ８７の取引額"５０"、"１５０"、"１００"及び"１００"を取得し、取引額合計（払）"４００"を算出する。そして、残高情報補正手段３６０は、取得した残高情報"１００"に、取引額合計（入）"４５０"を加算し、取引額合計（払）"４００"を減算して、収支残高"１５０"を算出する。
【０１１１】
一方、本発明の実施の形態２にかかる残高情報補正手段は、口座情報記憶部３２から口座ａ８Ａの券種"１００"の枚数"１"を初期枚数として取得する。そして、当該残高情報補正手段は、取引情報記憶部３３から口座ａ８Ａを取引先の口座とする取引の内、券種指定のある取引ｔ８２の券種"１００"の枚数"１"を取得し、併せて、券種指定のない取引ｔ８１及びｔ８３の取引額"２００"及び"１５０"を取得する。そして、当該残高情報補正手段は、取得した取引額"２００"及び"１５０"についてできるだけ大きな単位の券種の枚数として換算する。つまり、券種"１００"の枚数"３"及び券種"５０"の枚数"１"と換算する。その後、当該残高情報補正手段は、券種"１００"の合計枚数（入）"４"及び券種"５０"の合計枚数（入）"１"を算出する。また、当該残高情報補正手段は、取引情報記憶部３３から口座ａ８Ａを取引元の口座とする取引の内、券種指定のある取引ｔ８４の券種"５０"の枚数"１"を取得し、併せて、券種指定のない取引ｔ８５、ｔ８６及びｔ８７の取引額"１５０"、"１００"及び"１００"を取得する。そして、当該残高情報補正手段は、取得した取引額"１５０"、"１００"及び"１００"についてできるだけ大きな単位の券種の枚数として換算する。つまり、券種"１００"の枚数"３"及び券種"５０"の枚数"１"と換算する。その後、当該残高情報補正手段は、券種"１００"の合計枚数（払）"３"及び券種"５０"の合計枚数（払）"２"を算出する。そして、当該残高情報補正手段は、券種"１００"について、初期枚数"１"に、合計枚数（入）"４"を加算し、合計枚数（払）"３"を減算して、収支枚数"２"を算出する。併せて、当該残高情報補正手段は、券種"５０"について、初期枚数"０"に、合計枚数（入）"１"を加算し、合計枚数（払）"２"を減算して、収支枚数"−１"を算出する。すなわち、図２０（ｂ）に示すように、口座ａ８Ａは、収支残高が赤字と判定される。
【０１１２】
このように、図２０（ａ）のように券種及び枚数を考慮しない場合、黒字と判定されるが、本発明の実施の形態２により、図２０（ｂ）のように券種及び枚数を考慮することにより、赤字と判定され、単に、口座の残高の金額において決済可能であっても、券種と枚数により決済不可能となる場合を正確に決済可能な決済順序を確定することができる。
【０１１３】
＜その他の発明の実施の形態＞
さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
【符号の説明】
【０１１４】
１ａ、１ｂ、・・・１ｎ 端末
２ ネットワーク
３ 決済順序確定システム
３０１ ＣＰＵ
３０２ ＲＡＭ
３０３ ＲＯＭ
３０４ 通信部
３０５ ハードディスク
３０６ ＯＳ
３０７ 決済順序確定プログラム
３１ 制御部
３２ 口座情報記憶部
３２１ 口座ＩＤ
３２２ 残高情報
３３ 取引情報記憶部
３３１ グループＩＤ
３３２ 取引ＩＤ
３３３ 取引元口座ＩＤ
３３４ 取引先口座ＩＤ
３３５ 取引額
３３６ 決済順序
３４０ 取引グループ生成手段
３５０ 取引グループ決済試行手段
３５１ 取引決済試行手段
３５２ 残高情報更新手段
３５３ 繰り返し実行手段
３５４ 決済順序更新手段
３６０ 残高情報補正手段
３７０ 擬似ループ判定手段
３７１ 端点取引選択手段
３７２ 端点取引処理手段
３７３ 起点口座選択手段
３７４ 起点取引処理手段
３８０ 確定手段
ａ１Ａ、ａ１Ｂ、ａ１Ｃ、ａ１Ｄ、ａ１Ｅ 口座
ａ２Ａ、ａ２Ｂ、ａ２Ｃ、ａ２Ｄ、ａ２Ｅ 口座
ａ３Ａ、ａ３Ｂ、ａ３Ｃ、ａ３Ｄ、ａ３Ｅ 口座
ａ４Ａ、ａ４Ｂ、ａ４Ｃ、ａ４Ｄ、ａ４Ｅ 口座
ａ５Ａ、ａ５Ｂ、ａ５Ｃ、ａ５Ｄ、ａ５Ｅ 口座
ａ６Ａ、ａ６Ｂ、ａ６Ｃ、ａ６Ｄ、ａ６Ｅ 口座
ａ７Ａ、ａ７Ｂ、ａ７Ｃ、ａ７Ｄ、ａ７Ｅ、ａ７Ｆ、ａ７Ｇ、ａ７Ｈ 口座
ａ８Ａ、ａ８Ｂ、ａ８Ｃ、ａ８Ｄ、ａ８Ｅ、ａ８Ｆ、ａ８Ｇ、ａ８Ｈ 口座
ｇ１、ｇ２、ｇ３、ｇ４、ｇ５、ｇ６、ｇ７、ｇ８ 取引グループ
ｔ１１、ｔ１２、ｔ１３、ｔ１４ 取引
ｔ２１、ｔ２２、ｔ２３、ｔ２４ 取引
ｔ３１、ｔ３２、ｔ３３、ｔ３４、ｔ３５ 取引
ｔ４１、ｔ４２、ｔ４３、ｔ４４、ｔ４５ 取引
ｔ５１、ｔ５２、ｔ５３、ｔ５４、ｔ５５ 取引
ｔ６１、ｔ６２、ｔ６３、ｔ６４、ｔ６５ 取引
ｔ７１、ｔ７２、ｔ７３、ｔ７４、ｔ７５、ｔ７６、ｔ７７、ｔ７８、ｔ７９ 取引
ｔ８１、ｔ８２、ｔ８３、ｔ８４、ｔ８５、ｔ８６、ｔ８７ 取引
【技術分野】
【０００１】
本発明は、決済順序確定システム、方法及びプログラムに関し、特に、債券等の複数の取引を連続して決済する場合に決済可能な決済順序を確定する決済順序確定システム、方法及びプログラムに関する。
【背景技術】
【０００２】
近年、債券等のペーパーレス化に伴い、物理的な券面を発行せず、所定の機関において保有者、銘柄名及び額面等の管理が行われるようになった。そして、これらの管理が情報システム化されることにより、取引後の受渡し決済時に券面の移動を伴わないため、省力化やコストの軽減が図れるようになった。
【０００３】
特許文献１には、同一銘柄で異額面の債券取引におけるネッティング決済を可能とするネッティング決済システムに関する技術が開示されている。特許文献１にかかるネッティング決済システムは、二者による債券取引に関する取引関連データを入力する取引関連データ入力手順と、入力された取引関連データの中から同一銘柄の受け渡しの組合せを抽出する同一銘柄受け渡し抽出手順と、抽出された受け渡しの組合せの中から相殺すべき受け渡しの組合せたる相殺組合せを抽出する相殺抽出手順と、抽出された相殺組合せを決済演算可能な決済演算手順と、決済演算された結果を決済明細として出力する決済明細出力手順とを備える。特に、前記相殺抽出手順は、異額面の債券の受け渡しの組合せを含む相殺組合せを抽出可能とする。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３５２１７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
債券等の取引の中には、所定期間内に請求された複数の取引の請求を所定の期日又は時間に一括して決済を行うものがある。例えば、日中であれば取引の請求毎に即時に決済が行われるが、夜間に取引をまとめて受け付けて、翌朝までに決済を行う場合などである。ここで、債券等の取引の決済は、取引元の口座から取引先の口座へ金融商品の取引額を移動させることである。そして、取引額に比べて取引元の口座に債券等の残高が不足している場合は、決済を行うことができない。また、複数の取引の決済を一括して行う場合、ある取引における決済により口座の残高が変更することに伴い、他の取引の決済の可否が影響を受ける場合がある。つまり、決済の順序により、取引における決済の可否の結果が異なる場合がある。そのため、ある口座が複数の取引に関係している場合、これらの取引をまとめて取引グループとして扱うことが必要である。そして、複数の取引の決済を一括して行う場合、取引グループに含まれる複数の取引について所定の決済順序により直列に決済を行い、取引グループ内の全ての取引が決済可能である場合に、当該取引グループについて、一括して決済が可能と判断することができる。
【０００６】
例えば、取引グループに含まれる複数の取引について、決済順序の組み合わせを総当たりで試行することにより、決済可能な決済順序を検出することも可能である。この場合、取引グループに含まれる取引数に伴う計算量の増加が著しい。債券等における取引の請求は、一時期に集中する傾向があり、取引額は数千億円にのぼる場合もある。また、取引グループ内の取引の関係は複雑であるため、決済可能な決済順序を検出するには、複雑な処理を必要とし、時間がかかるという問題がある。
【０００７】
ここで、債券等における大部分の取引グループにおける取引の関係には、様々なパターンが存在するが、大部分の取引グループについては、単純なパターンが多く含まれ、複雑なパターンが全体に占める割合は少ないという特徴がある。
【０００８】
本発明は、このような問題を解決するためになされたものであり、複数の取引を連続して決済する場合に、決済可能な決済順序について、少ない試行回数により効率的に確定するための決済順序確定システム、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の態様にかかる決済順序確定システムは、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済可能な決済順序を確定する決済順序確定システムであって、前記取引に関わる口座の残高情報を記憶する残高情報記憶部（例えば、本発明の実施の形態１にかかる口座情報記憶部３２）と、前記取引グループに含まれる各取引における決済順序を記憶する決済順序記憶部（例えば、本発明の実施の形態１にかかる取引情報記憶部３３）と、前記取引における前記決済順序を確定する処理を制御する制御部と、を備え、前記制御部は、前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整手段と、前記第１の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定手段と、を備え、前記第１の決済順序調整手段は、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行手段と、前記取引決済試行手段による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高情報更新手段と、Ｎが１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第１の繰り返し実行手段と、前記第１の繰り返し実行手段による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新手段と、前記決済順序更新手段による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第２の繰り返し実行手段と、を含む。
【００１０】
また、前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記取引グループに含まれる全ての取引の決済が確定したと仮定した場合の口座当たりの残高を算出し、算出された残高が所定値以下となる口座について、残高が所定値となる取引額を加算して前記残高情報記憶部に格納された残高情報を補正する残高情報補正手段と、前記残高情報補正手段により補正された残高情報を用いて、前記決済順序記憶部に格納された決済順序に基づき、前記第１の決済順序調整手段により前記試行が失敗した全ての取引についての決済を試行することにより前記決済順序を調整する第２の決済順序調整手段と、をさらに備え、前記確定手段は、前記第２の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序としてさらに確定することが望ましい。
【００１１】
また、前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記取引グループに含まれる各取引から、取引元の口座が当該取引グループ内の他の取引の取引先の口座と一致しない取引である始点取引と、取引先の口座が当該取引グループ内の他の取引の取引元の口座と一致しない取引である終点取引とを選択する端点取引選択手段と、前記始点取引における決済順序を、最初の順序として前記決済順序記憶部を更新し、当該始点取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、前記終点取引における決済順序を、最後の順序として前記決済順序記憶部を更新する端点取引処理手段と、前記端点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整する第３の決済順序調整手段と、をさらに備え、前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記決済順序記憶部に格納された決済順序を決済可能な順序として確定することが望ましい。
【００１２】
さらに、前記第３の決済順序調整手段により試行が失敗した取引に含まれる口座から、自己が前記取引先の口座となる取引が存在し、かつ、自己が前記取引元の口座となる取引が２以上存在する口座を選択する起点口座選択手段と、前記起点口座選択手段により選択された口座が前記取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて前記決済順序記憶部を更新する起点取引処理手段と、をさらに備え、前記第３の決済順序調整手段は、前記起点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整することが望ましい。
【００１３】
また、前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序として確定するとよい。
【００１４】
さらに、取引元の口座から取引先の口座へ所定額を決済するための複数の取引を外部から受け付け、受け付けた複数の取引の中から、前記取引先の口座又は前記取引元の口座の少なくとも一方の口座が他の取引と共通する取引を選択し、選択した取引の集合を前記取引グループとして生成する取引グループ生成手段をさらに備え、前記第１の決済順序調整手段は、前記取引グループ生成手段により生成された取引グループに対して、前記決済順序を調整するとよい。
【００１５】
さらに、前記残高情報補正手段は、前記取引が券種及び枚数により定まる債券における取引である場合に、前記取引グループに含まれる口座の残高における債券の券種及び枚数に基づき、前記口座当たりの残高を算出するとよい。
【００１６】
本発明の第２の態様にかかる決済順序確定方法は、取引に関わる口座の残高情報を記憶する残高情報記憶部（例えば、本発明の実施の形態１にかかる口座情報記憶部３２）と、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部（例えば、本発明の実施の形態１にかかる取引情報記憶部３３）と、前記取引における前記決済順序を確定する処理を制御する制御部と、を備えるコンピュータにおける前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を制御するための決済順序確定方法であって、前記制御部において、前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整ステップと、前記第１の決済順序調整ステップにより調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定ステップと、を含み、前記第１の決済順序調整ステップは、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行ステップと、前記取引決済試行ステップによる試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新ステップと、Ｎが１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第１の繰り返し実行ステップと、前記第１の繰り返し実行ステップによる実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新ステップと、前記決済順序更新ステップによる更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第２の繰り返し実行ステップと、を含む。
【００１７】
本発明の第３の態様にかかる決済順序確定プログラムは、取引に関わる口座の残高情報を記憶する残高情報記憶部（例えば、本発明の実施の形態１にかかる口座情報記憶部３２）と、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部（例えば、本発明の実施の形態１にかかる取引情報記憶部３３）と、前記取引における前記決済順序を確定する処理を制御する制御部と、を備えるコンピュータに、前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を実行させる決済順序確定プログラムであって、前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整処理と、前記第１の決済順序調整処理により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定処理と、を含み、前記第１の決済順序調整処理は、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行処理と、前記取引決済試行処理による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新処理と、Ｎが１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第１の繰り返し実行処理と、前記第１の繰り返し実行処理による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新処理と、前記決済順序更新処理による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第２の繰り返し実行処理と、を含む。
【発明の効果】
【００１８】
本発明によれば、複数の取引を連続して決済する場合に、決済可能な決済順序について、少ない試行回数により効率的に確定するための決済順序確定システム、方法及びプログラムを提供することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態１にかかる決済順序確定システムを含む全体構成を示すブロック図である。
【図２】本発明の実施の形態１にかかる口座情報の例を示す図である。
【図３】本発明の実施の形態１にかかる取引情報の例を示す図である。
【図４】本発明の実施の形態１にかかる決済順序確定システムの機能ブロック図である。
【図５】本発明の実施の形態１にかかる決済順序確定システムのハードウェア構成を示すブロック図である。
【図６】本発明の実施の形態１にかかる決済順序確定処理の流れを示すフローチャートである。
【図７】本発明の実施の形態１にかかる取引グループ生成処理の流れを示すフローチャートである。
【図８】本発明の実施の形態１にかかる取引グループの例を示す図である。
【図９】本発明の実施の形態１にかかる決済順序調整処理の流れを示すフローチャートである。
【図１０】本発明の実施の形態１にかかる取引グループ決済試行処理の流れを示すフローチャートである。
【図１１】本発明の実施の形態１にかかる決済試行処理の流れを示すフローチャートである。
【図１２】本発明の実施の形態１にかかる取引グループ決済試行処理の実行結果の例を示す図である。
【図１３】本発明の実施の形態１にかかる取引グループ決済試行処理の実行結果の例を示す図である。
【図１４】本発明の実施の形態１にかかる口座収支算出処理の実行結果の例を示す図である。
【図１５】本発明の実施の形態１にかかる残高補正処理後の取引グループ決済試行処理の実行結果の例を示す図である。
【図１６】本発明の実施の形態１にかかる擬似ループ判定処理の流れを示すフローチャートである。
【図１７】本発明の実施の形態１にかかる起点口座が選択される取引グループの例を示す図である。
【図１８】本発明の実施の形態１にかかる確定処理の流れを示すフローチャートである。
【図１９】本発明の実施の形態２にかかる券種及び枚数を考慮した取引グループの例を示す図である。
【図２０】本発明の実施の形態２にかかる券種及び枚数を考慮した口座収支の例を示す図である。
【発明を実施するための形態】
【００２０】
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
【００２１】
＜発明の実施の形態１＞
図１は、本発明の実施の形態１にかかる決済順序確定システム３を含む全体構成を示すブロック図である。決済順序確定システム３は、ネットワーク２を介して、端末１ａ、１ｂ、・・・１ｎと接続され、端末１ａ、１ｂ、・・・１ｎから送信される複数の取引の請求を受け付け、所定期間内に受け付けた複数の取引について決済可能な決済順序を確定する決済順序確定処理を行う情報システムである。また、決済順序確定システム３は、決済が不可能な取引については、その旨を通知する。ここで、取引とは、取引元の口座から取引先の口座へ金融商品の取引額の移動又は債券等の権利の移転を定義したものとする。そして、取引の決済とは、取引額の移動又は債券等の権利の移転を実行することとする。また、決済順序とは、複数の取引について、取引の決済を実行する順序を示すものとする。
【００２２】
決済順序確定システム３は、汎用的なコンピュータシステムであり、取引における決済順序を確定する処理を制御する制御部３１と、口座情報記憶部３２と、取引情報記憶部３３とを少なくとも備える。口座情報記憶部３２は、口座ＩＤ３２１と、残高情報３２２とを関連付けて記憶する記憶装置である。ここでは、口座ＩＤ３２１は、取引に関わる口座を識別する情報である。また、残高情報３２２は、取引に関わる口座の取引可能な金額情報又は債券額である。尚、口座情報記憶部３２は、言い換えると、取引に関わる口座の残高情報３２２を記憶する残高情報記憶部といえる。
【００２３】
ここで、図２は、本発明の実施の形態１にかかる口座情報の例を示す図である。図２では、３０個の口座ＩＤについてそれぞれ残高情報が関連付けられていることを示す。
【００２４】
図１に戻り、取引情報記憶部３３は、グループＩＤ３３１と、取引ＩＤ３３２と、取引元口座ＩＤ３３３と、取引先口座ＩＤ３３４と、取引額３３５と、決済順序３３６とを記憶する記憶装置である。グループＩＤ３３１は、取引グループを識別する情報である。ここで、取引グループは、取引先の口座又は取引元の口座の少なくとも一方の口座が他の取引と共通する取引の集合である。取引ＩＤ３３２は、取引を識別する情報である。取引元口座ＩＤ３３３は、口座ＩＤ３２１の内、取引における取引元の口座ＩＤである。取引先口座ＩＤ３３４は、口座ＩＤ３２１の内、取引における取引先の口座ＩＤである。取引額３３５は、取引において決済される金額情報又は債券額である。決済順序３３６は、取引の決済を実行する順序を示す情報である。例えば、決済順序３３６は、数値で表現される番号情報であり、番号の昇順又は降順に実行されるものとする。尚、決済順序３３６は、開始の番号は、任意であり、番号は連続している必要はない。また、決済順序３３６は、少なくとも取引グループ内で一意に順序が定まるものとする。または、決済順序３３６は、当該取引の直前又は直後に決済を実行する取引ＩＤ３３２であってもよい。尚、取引情報記憶部３３は、言い換えると、取引グループに含まれる各取引における決済順序を記憶する決済順序記憶部といえる。また、取引は、取引ＩＤ３３２、取引元口座ＩＤ３３３、取引先口座ＩＤ３３４、取引額３３５及び決済順序３３６の組み合わせで表現される。そして、一つのグループＩＤ３３１には、複数の取引ＩＤ３３２が関連付けられている。
【００２５】
ここで、図３は、本発明の実施の形態１にかかる取引情報の例を示す図である。図３では、図２の口座が取引元又は取引先の口座となった２８個の取引ＩＤについて取引元口座ＩＤ、取引先口座ＩＤ、取引額及び決済順序が関連付けられていることを示し、各取引ＩＤは、６個のグループＩＤのいずれかに関連付けられていることを示す。
【００２６】
図１に戻り、端末１ａ、１ｂ、・・・１ｎは、キーボードやマウス等の入力装置（不図示）と、画面等の表示装置（不図示）と通信機能を備える端末装置である。そして、端末１ａ、１ｂ、・・・１ｎは、ネットワーク２を介して、任意のタイミングで取引に関する情報を決済順序確定システム３へ送信する。また、ネットワーク２は、インターネット、公衆網、専用線及び移動体通信網等の通信ネットワークである。
【００２７】
尚、口座情報記憶部３２及び取引情報記憶部３３は、ハードディスクドライブ、フラッシュメモリ等の不揮発性の記憶装置であることが望ましい。
【００２８】
図４は、本発明の実施の形態１にかかる決済順序確定システム３の機能ブロック図である。決済順序確定システム３は、取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済可能な決済順序を確定する情報システムである。決済順序確定システム３は、取引グループ生成手段３４０と、取引グループ決済試行手段３５０と、残高情報補正手段３６０と、擬似ループ判定手段３７０と、確定手段３８０とを備える。
【００２９】
取引グループ生成手段３４０は、端末１ａ、１ｂ、・・・１ｎからネットワーク２を介して、複数の取引を外部から受け付け、受け付けた複数の取引の中から、取引先の口座又は取引元の口座の少なくとも一方の口座が他の取引と共通する取引を選択し、選択した取引の集合を取引グループとして生成する。これにより、大量の取引について複数の取引グループに分けて効率的に決済順序を確定することができる。尚、このとき、取引グループ生成手段３４０は、取引グループ内の各取引について決済順序を初期設定するとよい。
【００３０】
取引グループ決済試行手段３５０は、取引情報記憶部３３に格納された決済順序３３６に基づき、取引グループに含まれる取引の決済を試行することにより決済順序を調整する。つまり、取引グループ決済試行手段３５０は、取引グループ生成手段３４０により生成された取引グループに対して設定された決済順序を調整する。尚、取引グループは、取引グループ生成手段３４０により生成されたものの代わりに、予め定められたものを対象としてもよい。また、取引グループ決済試行手段３５０は、取引決済試行手段３５１と、残高情報更新手段３５２と、繰り返し実行手段３５３と、決済順序更新手段３５４とを備える。
【００３１】
取引決済試行手段３５１は、口座情報記憶部３２及び取引情報記憶部３３を参照し、決済順序３３６がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する。残高情報更新手段３５２は、取引決済試行手段３５１による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して口座情報記憶部３２に格納された残高情報３２２を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする。繰り返し実行手段３５３は、取引情報記憶部３３に格納された決済順序３３６に従い、例えば、Ｎが１からＬまでの間、取引決済試行手段３５１による処理及び残高情報更新手段３５２による処理を繰り返し実行する。
【００３２】
決済順序更新手段３５４は、繰り返し実行手段３５３による実行の結果、試行が成功した取引における決済順序以前に、試行が失敗した取引が存在する場合、試行が失敗した全ての取引における決済順序が、試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように取引情報記憶部３３を更新する。そして、繰り返し実行手段３５３は、決済順序更新手段３５４による更新後に、ＮがＭ＋１からＬまでの間、取引決済試行手段３５１による処理及び残高情報更新手段３５２による処理を繰り返し実行する。
【００３３】
確定手段３８０は、取引グループ決済試行手段３５０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する。
【００３４】
このように、少なくとも上述した取引グループ決済試行手段３５０及び確定手段３８０を実行することにより、１巡目の試行では、初期設定された決済順序に基づき、各取引についての決済が試行され、試行が成功した取引の残高については、随時、決済後の残高に更新する。そして、更新後の残高を用いて以降の決済順序における取引が試行される。そして、１巡目の試行が終了した後に、試行が成功した取引及び試行が失敗した取引がそれぞれ存在し、かつ、最初の失敗以後に１以上の成功がある場合、言い換えると、最後の成功以前に１以上の失敗がある場合に、決済順序の更新及び２巡目の試行が行われる。決済順序更新手段３５４では、少なくとも試行が失敗した取引の決済順序を、試行が成功した全ての取引の決済順序より後の順序とする。
【００３５】
そして、２巡目の試行では、試行が失敗した取引のみについて、更新した決済順序に基づき決済が試行される。このとき、１巡目における試行が成功した取引における口座の残高は更新されており、２巡目の開始時点の条件は１巡目の開始時点とは条件が異なるため、１巡目にて最後の成功以前に試行が失敗した取引については、２巡目において試行が成功する可能性がある。これにより、初期設定とは異なる決済順序により試行を行ったこととなる。また、２巡目においては、１巡目において試行が成功した取引については、再度の試行を行わないため、試行回数を減らすことができる。すなわち、異なる決済順序を少ない試行回数により実行することができる。これにより、決済順序を並べ替えるだけで決済可能な取引グループであるか否かについて効率的に判定し、決済可能な決済順序を確定することができる。
【００３６】
また、残高情報補正手段３６０は、確定手段３８０により決済順序が決済可能な順序として確定されなかった場合に、口座情報記憶部３２及び取引情報記憶部３３を参照し、取引グループに含まれる全ての取引の決済が確定したと仮定した場合の口座当たりの残高を算出し、算出された残高が所定値以下となる口座について、残高が所定値となる取引額を加算して口座情報記憶部３２に格納された残高情報３２２を補正する。そして、取引グループ決済試行手段３５０は、残高情報補正手段３６０により補正された残高情報を用いて、取引情報記憶部３３に格納された決済順序３３６に基づき、取引グループ決済試行手段３５０により前回、試行が失敗した全ての取引についての決済を試行することにより決済順序を調整する。このとき、確定手段３８０は、取引グループ決済試行手段３５０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、取引グループ決済試行手段３５０により試行が成功した最後の取引の決済順序までを決済可能な順序としてさらに確定する。
【００３７】
ここで、取引グループが決済順序に関わらず、そもそも取引元の口座の初期残高が不足していたために決済不可能であったことを赤残連鎖取引と呼ぶ。上述した手段により、赤残連鎖取引について、初期残高の不足を解消した場合に決済可能な決済順序を確定することができる。また、初期残高が不足している口座を特定でき、当該口座の持ち主へ不足額の解消を依頼する通知をすることにより、初期残高の不足が解消した後、直ちに決済可能となるため、不要に取引を決済不可能とすることがなくなる。よって、決済可能な取引グループを検出する精度を高めることができる。
【００３８】
ここで、取引グループにおけるループ取引について説明する。ループ取引とは、複数の口座間で取引元の口座と取引先の口座とが入れ替わった取引を含む取引グループである。つまり、ループ取引とは、複数の口座間で循環する複数の取引を指す。特に、取引額が同額で循環する場合、当該ループ取引における口座の収支は過不足がない。そのため、残高情報補正手段３６０により初期残高の不足する口座を含む取引グループとして検出することはできない。しかし、上述したようにループ取引は口座の収支に過不足がないため、取引グループ内の初期設定の決済順序と異なる順序とすることで、決済可能となる場合もある。このようなループ取引を擬似ループ取引と呼ぶ。さらに、赤残連鎖取引であったために、初期設定の決済順序では決済可能とならなかったが、初期残高の不足を解消した上で、擬似ループ取引となる取引グループもある。このようなループ取引を、赤残連鎖取引かつ擬似ループ取引と呼ぶ。一方、ループ取引に関係する各口座のいずれにも初期残高が不足している場合には、決済順序に関わらず決済可能とはならない。このようなループ取引を真正ループ取引と呼ぶ。さらに、赤残連鎖取引であり、ループ取引以外の取引のための初期残高の不足を解消したとしても、真正ループ取引となる取引グループもある。このようなループ取引を、赤残連鎖取引かつ真正ループ取引と呼ぶ。
【００３９】
そこで、擬似ループ判定手段３７０は、取引グループ決済試行手段３５０における試行に失敗した取引が存在する場合、取引グループが擬似ループ取引となっているか否かを判定する。擬似ループ判定手段３７０は、端点取引選択手段３７１と、端点取引処理手段３７２と、起点口座選択手段３７３と、起点取引処理手段３７４とを備える。
【００４０】
端点取引選択手段３７１は、確定手段３８０により決済順序が決済可能な順序として確定されなかった場合に、取引グループに含まれる各取引から、取引元の口座が当該取引グループ内の他の取引の取引先の口座と一致しない取引である始点取引と、取引先の口座が当該取引グループ内の他の取引の取引元の口座と一致しない取引である終点取引とを選択する。端点取引処理手段３７２は、始点取引における決済順序を、最初の順序として取引情報記憶部３３を更新し、当該始点取引の決済が確定したと仮定して口座情報記憶部３２に格納された残高情報３２２を更新し、終点取引における決済順序を、最後の順序として取引情報記憶部３３を更新する。
【００４１】
そして、擬似ループ判定手段３７０は、端点取引処理手段３７２により更新された決済順序に基づき、取引グループの内、始点取引及び終点取引を除いた取引についての決済を試行することにより決済順序を調整する。このとき、確定手段３８０は、取引グループ決済試行手段３５０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、取引情報記憶部３３に格納された決済順序３３６を決済可能な順序として確定する。これにより、擬似ループ取引を検出して決済可能な順序として確定することができる。よって、決済可能な取引グループを検出する精度を高めることができる。
【００４２】
また、起点口座選択手段３７３は、擬似ループ判定手段３７０により試行が失敗した取引に含まれる口座から、自己が取引先の口座となる取引が存在し、かつ、自己が取引元の口座となる取引が２以上存在する口座を選択する。起点取引処理手段３７４は、起点口座選択手段３７３により選択された口座が取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて取引情報記憶部３３を更新する。そして、擬似ループ判定手段３７０は、起点取引処理手段３７４により更新された決済順序に基づき、取引グループの内、始点取引及び終点取引を除いた取引についての決済を試行することにより決済順序を調整する。このように、ループ取引における起点となりうる複数の起点取引を特定し、当該複数の起点取引の決済順序における先後関係を入れ替えることにより、試行に成功する場合があり、結果的に試行回数を減らし、効率的に決済順序を確定することができる。
【００４３】
さらに、確定手段３８０は、擬似ループ判定手段３７０により調整された決済順序により取引グループに含まれる全ての取引の決済の試行が成功する場合に、取引グループ決済試行手段３５０により試行が成功した最後の取引の決済順序までを決済可能な順序として確定するとよい。これにより、擬似ループ取引を検出して決済可能な順序として確定することができる。また、確定手段３８０は、擬似ループ判定手段３７０により調整された決済順序により試行が失敗した場合にも、取引グループ決済試行手段３５０により試行が成功した最後の取引の決済順序までを決済可能な順序として確定してもよい。これにより、赤残連鎖取引又は真正ループ取引であっても、決済可能な取引については決済順序を確定させることができる。逆に、決済不可能な取引を特定することができる。そのため、決済不可能な取引の原因を絞り込み、後処理を効率的に行うことができる。
【００４４】
図５は、本発明の実施の形態１にかかる決済順序確定システム３のハードウェア構成を示すブロック図である。決済順序確定システム３は、ＣＰＵ（Central Processing Unit）３０１と、ＲＡＭ（Random Access Memory）３０２と、ＲＯＭ（Read Only Memory）３０３と、通信部３０４と、ハードディスク３０５とを備える。また、ハードディスク３０５は、不揮発性記憶装置であり、ＯＳ（Operating System）３０６及び決済順序確定プログラム３０７が格納されている。尚、ハードディスク３０５は、口座情報記憶部３２及び取引情報記憶部３３をさらに含むものであってもよい。決済順序確定プログラム３０７は、本発明の実施の形態１にかかる決済順序確定処理が実装されたコンピュータプログラムである。
【００４５】
ＣＰＵ３０１は、決済順序確定システム３における各種処理、ＲＡＭ３０２、ＲＯＭ３０３、通信部３０４及びハードディスク３０５へのアクセス等を制御する。通信部３０４は、口座情報記憶部３２及び取引情報記憶部３３並びにネットワーク２を介して端末１ａ、１ｂ、・・・１ｎとの通信を行う。決済順序確定システム３は、ＣＰＵ３０１が、ＲＡＭ３０２、ＲＯＭ３０３又はハードディスク３０５に格納されたＯＳ３０６及び決済順序確定プログラム３０７を読み込み、実行する。これにより、決済順序確定システム３は、決済順序確定処理を実現することができる。尚、決済順序確定システム３は、複数台のコンピュータサーバに分散して実現されても構わない。
【００４６】
図６は、本発明の実施の形態１にかかる決済順序確定処理の流れを示すフローチャートである。まず、取引グループ生成手段３４０は、端末１ａ、１ｂ、・・・１ｎから取引情報を受け付ける（Ｓ１１）。具体的には、取引グループ生成手段３４０は、受け付けた取引情報に応じて取引ＩＤ３３２を発行し、取引情報に含まれる取引元口座ＩＤ３３３、取引先口座ＩＤ３３４及び取引額３３５に取引ＩＤ３３２を関連付けて取引情報記憶部３３に格納する。次に、取引グループ生成手段３４０は、取引グループ生成処理を行う（Ｓ１２）。尚、取引グループ生成処理の詳細は、図７を用いて後述する。
【００４７】
そして、取引グループ決済試行手段３５０は、取引グループを選択する（Ｓ１３）。具体的には、取引グループ決済試行手段３５０は、取引情報記憶部３３を参照し、複数のグループＩＤ３３１の内、一つを選択する。その後、取引グループ決済試行手段３５０は、決済順序調整処理を行う（Ｓ１４）。尚、決済順序調整処理の詳細は、図９を用いて後述する。引き続き、確定手段３８０は、決済順序を確定する確定処理を行う（Ｓ１５）。尚、確定処理の詳細は、図１８を用いて後述する。
【００４８】
ここで、取引グループ決済試行手段３５０は、未選択の取引グループが存在するか否かを判定する（Ｓ１６）。具体的には、取引グループ決済試行手段３５０は、取引情報記憶部３３を参照し、グループＩＤ３３１の内、未選択のグループが存在するか否かを判定する。ステップＳ１６において、未選択のグループが存在すると判定した場合、全ての取引グループが選択し終えるまでの間、ステップＳ１３乃至Ｓ１６を繰り返し実行する。ステップＳ１６において、未選択のグループが存在しない、すなわち、全てのグループが選択済みであると判定した場合、決済順序確定システム３は、決済順序確定処理を終了する。
【００４９】
図７は、本発明の実施の形態１にかかる取引グループ生成処理の流れを示すフローチャートである。まず、取引グループ生成手段３４０は、取引情報を選択する（Ｓ２１）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、複数の取引ＩＤ３３２の内、一つを選択する。次に、取引グループ生成手段３４０は、選択した取引情報に関連する取引情報が存在するか否かを判定する（Ｓ２２）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、ステップＳ２１において選択した取引ＩＤ３３２に関連付けられた取引元口座ＩＤ３３３及び取引先口座ＩＤ３３４を取得する。そして、取引グループ生成手段３４０は、取得した取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４の口座ＩＤを検索キーとして、取引情報記憶部３３を検索する。そして、検索キーと一致する取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４が関連付けられた取引ＩＤ３３２が存在するか否かを判定する。
【００５０】
ステップＳ２２において、関連する取引情報が存在すると判定した場合、取引グループ生成手段３４０は、当該関連する取引情報を選択する（Ｓ２３）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、複数の取引ＩＤ３３２の内、ステップＳ２２において、検索キーと一致する取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４が関連付けられた取引ＩＤ３３２を全て選択する。その後、取引グループ生成手段３４０は、ステップＳ２３において選択した取引ＩＤ３３２に関連する取引情報を選択する。以後、関連する取引情報が存在しなくなるまでの間、ステップＳ２２及びＳ２３を繰り返し実行する。尚、ステップＳ２２において、取引グループ生成手段３４０は、未選択の口座ＩＤについて、未選択の取引情報の中から検索を行うものとする。また、ステップＳ２３において複数の関連する取引情報が選択された場合、それぞれについてステップＳ２２及びＳ２３を繰り返し実行する。例えば、ステップＳ２２において、図３の取引ｔ１１が選択された場合、取引元の口座ａ１Ｂを取引元口座ＩＤ３３３とする取引ｔ１４と、取引先口座ＩＤ３３４とする取引ｔ１３とが関連する取引情報として選択される。一方、取引ｔ１１の取引先の口座ａ１Ｅを取引元口座ＩＤ３３３又は取引先口座ＩＤ３３４とする取引は存在しないため、口座ａ１Ｅに関連する取引情報は選択されない。そして、取引ｔ１４における取引先の口座ａ１Ｄと、取引ｔ１３の取引元の口座ａ１Ａとのいずれかに関連する取引情報として、取引ｔ１２が選択される。その後、取引ｔ１２の取引元の口座ａ１Ａに関連する取引情報（取引ｔ１３）が選択済みであり、取引先の口座ａ１Ｃに関連する取引情報が存在しないため、ステップＳ２２において、関連する取引情報が存在しないと判定される。
【００５１】
ステップＳ２２において、関連する取引情報が存在しないと判定した場合、取引グループ生成手段３４０は、取引グループを生成する（Ｓ２４）。具体的には、取引グループ生成手段３４０は、一つのグループＩＤ３３１を発行し、選択した複数の取引ＩＤ３３２に関連付けてグループＩＤ３３１を取引情報記憶部３３に格納する。
【００５２】
そして、取引グループ生成手段３４０は、取引グループ内の取引情報に決済順序を設定する（Ｓ２５）。具体的には、取引グループ生成手段３４０は、所定の項目についてソートを行う。そして、取引グループ生成手段３４０は、ソート結果に従い決済順序を設定する。すなわち、取引グループ生成手段３４０は、選択されたグループＩＤ３３１に関連付けられた取引ＩＤ３３２について、所定のソート順に基づき、並び替えを行い、並び替えた結果に基づき、各取引ＩＤ３３２に対応する決済順序３３６に順序番号を設定して取引情報記憶部３３を更新する。
【００５３】
例えば、受け付けた順序、取引の種別等を考慮してソートを行う。取引の種別によっては、他の取引種別が決済可能となるための前提となるものや、優先して決済しなければならないものがあるため、特定の取引の種別を優先してソートを行う。また、債券取引の場合、債券の券種が小さいものを優先してソートを行ってもよい。つまり、業務における優先順位に基づき決済順序を初期設定することにより、決済順序試行処理において、少ない試行回数により試行が成功しやすくなる。
【００５４】
続いて、取引グループ生成手段３４０は、未選択の取引情報が存在するか否かを判定する（Ｓ２６）。具体的には、取引グループ生成手段３４０は、取引情報記憶部３３を参照し、取引ＩＤ３３２の内、未選択の取引情報が存在するか否かを判定する。ステップＳ２６において、未選択の取引情報が存在すると判定した場合、取引グループ生成手段３４０は、未選択の取引ＩＤ３３２の内、一つを選択する（Ｓ２７）。その後、全ての取引情報について選択し終えるまでの間、ステップＳ２２乃至Ｓ２７を繰り返し実行する。
【００５５】
ステップＳ２６において、未選択の取引情報が存在しない、つまり、全ての取引情報が選択済みであると判定した場合、取引グループ生成手段３４０は、取引グループ生成処理を終了する。尚、ステップＳ２５は、全ての取引グループ生成処理の最後に、まとめて決済順序を設定してもよい。上述した図３は、本発明の実施の形態１にかかる取引グループ生成処理の実行結果の一例である。
【００５６】
図８は、本発明の実施の形態１にかかる取引グループの例を示す図である。尚、図８（ａ）〜（ｆ）は、図３の取引グループｇ１〜ｇ６について、口座と取引との関係を概念で示した図である。また、図８（ｇ）は、図８（ａ）〜（ｆ）における一取引の凡例である。以下の決済順序調整処理及び確定処理の説明においては、適宜、図２、図３及び図８に例示した残高情報、取引グループ及び取引情報を用いる。
【００５７】
図９は、本発明の実施の形態１にかかる決済順序調整処理の流れを示すフローチャートである。まず、取引グループ決済試行手段３５０は、取引グループ決済試行処理を行う（Ｓ３０１）。ここで、図１０は、本発明の実施の形態１にかかる取引グループ決済試行処理の流れを示すフローチャートである。まず、繰り返し実行手段３５３は、Ｎ及びＬに初期値を設定する（Ｓ４１）。ここで、Ｎは、後述するステップＳ４２の決済試行処理において参照する決済順序の番号であり、決済試行処理を繰り返し実行するためのループカウンタである。つまり、ステップＳ４１では、決済試行処理の対象とする最初の決済順序を設定する。また、Ｌは、決済試行処理において参照する決済順序の番号の上限値である。尚、図９のステップＳ３０１においては、Ｎに"１"を設定し、Ｌに図６のステップＳ１３において選択された取引グループに含まれる取引数を設定する。尚、このとき、併せて、成功回数Ｍは、"０"に設定される
【００５８】
次に、繰り返し実行手段３５３は、決済試行処理を行う（Ｓ４２）。ここで、図１１は、本発明の実施の形態１にかかる決済試行処理の流れを示すフローチャートである。まず、取引決済試行手段３５１は、Ｎ番目の取引の決済を試行する（Ｓ５１）。例えば、図１０のステップＳ４１の直後、かつ、１回目の試行においては、Ｎは"１"であるため、繰り返し実行手段３５３は、"Ｎ＝１"として取引決済試行手段３５１を実行させる。そして、取引決済試行手段３５１は、口座情報記憶部３２及び取引情報記憶部３３を参照し、決済順序３３６がＮ番目の取引の決済を試行する。すなわち、取引決済試行手段３５１は、決済順序３３６がＮ番目である取引ＩＤ３３２に関連付けられた取引元口座ＩＤ３３３及び取引先口座ＩＤ３３４を特定し、取引額３３５を取得する。そして、取引決済試行手段３５１は、特定した取引元口座ＩＤ３３３に対応する残高情報３２２を口座情報記憶部３２から取得する。続いて、取引決済試行手段３５１は、取得した残高情報３２２が取得した取引額３３５以上であるか否かを判定する。
【００５９】
続いて、残高情報更新手段３５２は、ステップＳ５１における試行が成功したか否かを判定する（Ｓ５２）。具体的には、ステップＳ５１において、Ｎ番目の取引ＩＤ３３２における取引元口座ＩＤ３３３の残高情報３２２が、当該取引ＩＤ３３２における取引額３３５以上であると判定した場合、残高情報更新手段３５２は、当該試行が成功したと判定する。一方、取引額３３５未満であると判定した場合、残高情報更新手段３５２は、当該試行が失敗したと判定する。尚、残高情報更新手段３５２は、ステップＳ５１における試行が成功したか否かの判定結果（不図示）を、取引ＩＤ３３２に関連付けて取引情報記憶部３３に格納するものとする。また、２巡目以降が実行される場合、個別に記憶することが望ましい。ステップＳ５２において、当該試行が失敗したと判定した場合、ステップＳ５５へ進む。
【００６０】
ステップＳ５２において、当該試行が成功したと判定した場合、残高情報更新手段３５２は、成功回数Ｍに"１"を加算する（Ｓ５３）。そして、残高情報更新手段３５２は、残高情報３２２を更新する（Ｓ５４）。具体的には、まず、残高情報更新手段３５２は、上記特定した取引元口座ＩＤ３３３に対応する残高情報３２２から取引額３３５を減算した結果を、取引元口座ＩＤ３３３における残高情報３２２として口座情報記憶部３２を更新する。また、残高情報更新手段３５２は、上記特定した取引先口座ＩＤ３３４に対応する残高情報３２２に取引額３３５を加算した結果を、取引先口座ＩＤ３３４における残高情報３２２として口座情報記憶部３２を更新する。
【００６１】
その後、繰り返し実行手段３５３は、ＮがＬ未満であるか否かを判定する（Ｓ５５）。すなわち、繰り返し実行手段３５３は、決済が未試行である取引が存在するか否かにより、取引決済試行手段３５１の処理及び残高情報更新手段３５２の処理を繰り返し実行すべきか否かを判定する。ステップＳ５５において、ＮがＬ未満であると判定した場合、繰り返し実行手段３５３は、Ｎに"１"を加算する（Ｓ５６）。その後、全ての取引について決済順序に従って試行を終えるまでの間、ステップＳ５１乃至Ｓ５６を繰り返し実行する。ステップＳ５５において、ＮがＬ以上であると判定した場合、つまり、全ての取引について試行を終えた場合、繰り返し実行手段３５３は、決済試行処理を終了する。
【００６２】
図１２及び図１３は、本発明の実施の形態１にかかる取引グループ決済試行処理の実行結果の例を示す図である。図１２（ａ）〜（ｃ）は、図８に示した取引グループｇ１〜ｇ３における１巡目並びに取引グループｇ１及びｇ２における２巡目の決済試行処理の実行結果の例を示す図である。図１３（ｄ）〜（ｆ）は、図８に示した取引グループｇ４〜ｇ６における１巡目の決済試行処理の実行結果の例を示す図である。
【００６３】
例えば、取引グループｇ１の場合、１巡目の決済試行処理では、決済順序に従い、取引ｔ１１、ｔ１２、ｔ１３、ｔ１４の順序で決済が試行される。まず、決済順序"１"である取引ｔ１１については、取引額が"１０"であるところ、取引元口座ａ１Ｂの残高情報が"０"である。そのため、残高情報更新手段３５２は、取引ｔ１１の試行が失敗すると判定する（Ｓ５２）。よって、取引元口座ａ１Ｂ及び取引先口座ａ１Ｅの残高情報は更新されない。次に、決済順序"２"である取引ｔ１２については、取引額が"１０"であるところ、取引元口座ａ１Ａの残高情報が"３０"である。そのため、残高情報更新手段３５２は、取引ｔ１２の試行が成功すると判定する（Ｓ５２）。よって、残高情報更新手段３５２は、成功回数Ｍを"１"とし（Ｓ５３）、取引元口座ａ１Ａの残高情報"３０"から取引額"１０"を減算した"２０"として口座情報記憶部３２の口座ＩＤ"ａ１Ａ"の残高情報３２２を更新する。また、残高情報更新手段３５２は、取引先口座ａ１Ｃの残高情報"０"に取引額"１０"を加算した"１０"として口座情報記憶部３２の口座ＩＤ"ａ１Ｃ"の残高情報３２２を更新する（Ｓ５４）。その後、決済順序"３"である取引ｔ１３については、取引額が"２０"であるところ、取引元口座ａ１Ａの残高情報が"２０"である。そのため、残高情報更新手段３５２は、取引ｔ１３の試行が成功すると判定（Ｓ５２）し、上述したようにステップＳ５３及びＳ５４を行う。さらに、決済順序"４"である取引ｔ１４については、取引額が"１０"であるところ、取引元口座ａ１Ｂの残高情報が"１０"である。そのため、残高情報更新手段３５２は、取引ｔ１４の試行が成功すると判定（Ｓ５２）し、上述したようにステップＳ５３及びＳ５４を行う。
【００６４】
以上が取引グループｇ１における１巡目の決済試行処理の流れである。図１２（ａ）の１巡目の成否の"○"が試行に成功した取引を示し、"×"が試行に失敗した取引を示す。また、同様に、図１２（ｂ）（ｃ）、図１３（ｄ）〜（ｆ）が取引グループｇ２からｇ６についての１巡目の決済試行処理の結果を示す。
【００６５】
図１０に戻り、決済順序更新手段３５４は、ステップＳ４２の結果により再試行を行う必要があるか否かを判定する（Ｓ４３）。すなわち、決済順序更新手段３５４は、ステップＳ４２の結果、試行が成功した取引における決済順序以前に、試行が失敗した取引が存在するか否かを判定する。つまり、決済順序更新手段３５４は、少なくとも試行が最後に成功した取引における決済順序以前に、試行が失敗した取引が１以上存在するか否かを判定することとなる。
【００６６】
例えば、図１２（ａ）では、試行が成功した取引ｔ１２〜ｔ１４の決済順序"２"〜"４"以前に、試行が失敗した取引ｔ１１が存在する。そのため、決済順序更新手段３５４は、取引グループｇ１について再試行を行う必要があると判定する。また、図１２（ｂ）では、試行が成功した取引ｔ２１の決済順序"１"以前には、試行が失敗した取引が存在しないが、試行が成功した取引ｔ２３の決済順序"３"以前には、試行が失敗した取引ｔ２２が存在する。そのため、決済順序更新手段３５４は、取引グループｇ２について再試行を行う必要があると判定する。また、図１２（ｃ）及び図１３（ｄ）では、全ての取引について試行が失敗しているため、決済順序更新手段３５４は、取引グループｇ３及びｇ４について再試行を行う必要がないと判定する。これは、試行が成功していないため、各口座の残高が更新されておらず、試行を行う際の条件が変更していないため、再試行により結果の差が生じえないためである。さらに、図１３（ｅ）及び（ｆ）では、最後に試行が成功した取引ｔ５２又はｔ６２の決済順序"２"以前には、試行が失敗した取引が存在しないため、決済順序更新手段３５４は、取引グループｇ５及びｇ６について再試行を行う必要がないと判定する。
【００６７】
ステップＳ４３において、再試行を行う必要があると判定した場合、決済順序更新手段３５４は、決済順序を更新する（Ｓ４４）。すなわち、決済順序更新手段３５４は、試行が失敗した全ての取引における決済順序が、試行が成功した全ての取引（成功数Ｍ）における決済順序より後の順序である"Ｍ＋１"以降となるように取引情報記憶部３３を更新する。具体的には、まず、決済順序更新手段３５４は、試行が成功した各取引における決済順序を、当該試行が成功した時点における成功した取引の成功数Ｍとして、取引情報記憶部３３を更新する。次に、決済順序更新手段３５４は、試行が失敗した全ての取引における決済順序を、Ｍ＋１以上かつＬ以下として、取引情報記憶部３３を更新する。
【００６８】
例えば、図１２（ａ）では、まず、試行が成功した全ての取引ｔ１２、ｔ１３及びｔ１４の２巡目の決済順序として、それぞれ"１"、"２"及び"３"とする。次に、試行が失敗した全ての取引ｔ１１の２巡目の決済順序として、"３"に"１"を加算した"４"とする。同様に、図１２（ｂ）では、試行が成功した全ての取引ｔ２１及びｔ２３の２巡目の決済順序として、それぞれ"１"及び"２"とし、試行が失敗した取引ｔ２２の２巡目の決済順序として、"２"に"１"を加算した"３"、そして、取引ｔ２４の２巡目の決済順序として、"４"とする。
【００６９】
尚、図１１のステップＳ５３における成功数Ｍの算出処理は、ステップＳ４４において、決済順序更新手段３５４が取引決済試行手段３５１の試行結果を基に集計することにより実行しても構わない。
【００７０】
また、決済順序更新手段３５４は、成功した取引の決済順序の更新を図１１のステップＳ５３の後に実行しても構わない。すなわち、決済順序更新手段３５４は、取引決済試行手段３５１における試行が成功した場合に、当該Ｎ番目の取引における決済順序を、ステップＳ５３により加算後の成功数Ｍとして、取引情報記憶部３３を更新しても構わない。
【００７１】
続いて、繰り返し実行手段３５３は、Ｎに"Ｍ＋１"を代入する（Ｓ４５）。その後、再試行を行う必要がある間、ステップＳ４２乃至Ｓ４５を繰り返し実行する。ステップＳ４３において、再試行を行う必要がないと判定した場合、取引グループ決済試行手段３５０は、取引グループ決済試行処理を終了する。
【００７２】
尚、ステップＳ４３において、再試行を行う必要があると判定した場合、決済順序更新手段３５４は、最後に試行が成功した取引における決済順序を特定し、試行が失敗した全ての取引における決済順序を、当該特定された決済順序より後の順序として、取引情報記憶部３３を更新する。この場合、必ずしも試行に成功した取引の決済順序を更新しなくてもよい。この場合、決済順序更新手段３５４による更新後に、繰り返し実行手段３５３は、試行が失敗した全ての取引について、取引情報記憶部３３に格納された決済順序に基づいてＮを昇順に更新して、取引決済試行手段３５１の処理及び残高情報更新手段３５２の処理を繰り返し実行する。
【００７３】
例えば、図１２（ａ）では、最後に試行が成功した取引ｔ１４における決済順序が"４"であることを特定し、取引ｔ１１の２巡目の決済順序として、"４"に"１"を加算した"５"としてもよい。同様に、図１２（ｂ）では、最後に試行が成功した取引ｔ２３における決済順序が"３"であることを特定し、取引ｔ２２及びｔ２４の２巡目の決済順序として、それぞれ"４"及び"５"としてもよい。但し、この場合、ステップＳ４２を再度実行する際に、Ｎを"最後に試行が成功した取引における決済順序＋１"とし、Ｌを"最後に試行が成功した取引における決済順序＋失敗した取引総数"とする。これにより、試行が成功した取引における決済順序を更新する処理を減らし、処理コストを減らすことができる。
【００７４】
図９に戻り、取引グループ決済試行手段３５０は、試行に失敗した取引が存在するか否かを判定する（Ｓ３０２）。例えば、取引グループ決済試行手段３５０は、取引情報記憶部３３を参照し、取引ＩＤ３３２に関連付けられた判定結果に基づき判定する。ステップＳ３０２において、試行に失敗した取引が存在しないと判定した場合、つまり、対象の取引グループにおける全ての取引についてステップＳ３０１における試行が成功した場合、取引グループ決済試行手段３５０は、当該取引グループが"通常取引"であると判定する（Ｓ３１０）。図８の例では、取引グループｇ１のみが"通常取引"であると判定される。このとき、取引グループ決済試行手段３５０は、"通常取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００７５】
ステップＳ３０２において、試行に失敗した取引が存在すると判定した場合、つまり、対象の取引グループにおける取引の中にステップＳ３０１における試行が失敗した取引が含まれる場合、残高情報補正手段３６０は、口座当たりの収支残高を算出する（Ｓ３０３）。図８の例では、取引グループｇ２〜ｇ６がステップＳ３０３の対象となる。残高情報補正手段３６０は、口座情報記憶部３２及び取引情報記憶部３３を参照し、各取引グループに含まれる口座ごとに以下の処理を行う。具体的には、まず、残高情報補正手段３６０は、口座情報記憶部３２から対象口座の残高情報３２２を取得する。次に、残高情報補正手段３６０は、取引情報記憶部３３を参照し、対象口座を取引元又は取引先の口座とする全ての取引を選択し、選択した取引ＩＤ３３２における取引額３３５から取引元及び取引先のそれぞれの合計を算出する。そして、残高情報補正手段３６０は、取得した残高情報３２２に、対象口座を取引先の口座とする取引の取引額３３５の合計を加算し、対象口座を取引元の口座とする取引の取引額３３５の合計を減算する。そして、その結果である口座当たりの収支残高（不図示）を対象口座に関連付けて口座情報記憶部３２に格納する。
【００７６】
ここで、図１４は、本発明の実施の形態１にかかる口座収支算出処理の実行結果の例を示す図である。図１４（ａ）〜（ｅ）は、それぞれ取引グループｇ２〜ｇ６における口座収支の例を示す図である。図１４（ａ）では、例えば、口座ａ２Ｂを対象口座とした場合、まず、残高情報補正手段３６０は、初期残高"０"を取得する。次に、残高情報補正手段３６０は、口座ａ２Ｂを取引先の口座とする取引ｔ２１の取引額"１０"を取得する。このとき、取引額合計（入）は、"１０"である。また、残高情報補正手段３６０は、口座ａ２Ｂを取引元の口座とする取引ｔ２３及びｔ２４の取引額"１０"及び"１０"を取得する。このとき、取引額合計（払）は、"２０"である。そして、残高情報補正手段３６０は、初期残高"０"に、取引額合計（入）"１０"を加算し、取引額合計（払）"２０"を減算して、収支残高"−１０"を算出し、口座情報記憶部３２に格納する。その他、図１４（ａ）〜（ｅ）について同様に口座当たりの収支残高が算出される。
【００７７】
その後、残高情報補正手段３６０は、取引グループ内に収支残高が赤字となる赤字口座が存在するか否かを判定する（Ｓ３０４）。すなわち、残高情報補正手段３６０は、ステップＳ３０３において算出された収支残高が所定値以下となる口座が存在するか否かを判定する。具体的には、残高情報補正手段３６０は、口座情報記憶部３２を参照し、収支残高がマイナスである口座が存在するか否かを確認する。例えば、図１４（ａ）の場合、口座ａ２Ａ及びａ２Ｂの収支残高がマイナスであるため、取引グループｇ２内に赤字口座が存在すると判定される。同様に、図１４（ｂ）及び（ｃ）に基づき、取引グループｇ３及びｇ４内に赤字口座が存在すると判定される。一方、図１４（ｄ）及び（ｅ）の場合、収支残高がマイナスとなる口座が存在しないため、取引グループｇ５及びｇ６内に赤字口座が存在しないと判定される。ステップＳ３０４において、取引グループ内に赤字口座が存在しないと判定された場合、ステップＳ３０８へ進む。
【００７８】
ステップＳ３０４において、取引グループ内に赤字口座が存在すると判定された場合、残高情報補正手段３６０は、残高を補正する（Ｓ３０５）。すなわち、残高情報補正手段３６０は、残高が所定値となる取引額を加算して口座情報記憶部３２に格納された残高情報３２２を補正する。例えば、残高情報補正手段３６０は、取引グループｇ２の口座ａ２Ａの残高情報３２２に、"１０"を加算して口座情報記憶部３２を更新する。同様に、取引グループｇ２、ｇ３及びｇ４における口座ａ２Ｂ、ａ３Ａ及びａ４Ａの残高情報３２２に、不足額を加算して口座情報記憶部３２を更新する。
【００７９】
そして、取引グループ決済試行手段３５０は、取引グループ決済試行処理を実行する（Ｓ３０６）。すなわち、取引グループ決済試行手段３５０は、残高情報補正手段３６０により補正された残高情報を用いて、取引情報記憶部３３に格納された決済順序３３６に基づき、取引グループ決済試行手段３５０により前回、試行が失敗した全ての取引についての決済を試行することにより決済順序を調整する。
【００８０】
ここで、図１５は、本発明の実施の形態１にかかる残高補正処理後の取引グループ決済試行処理の実行結果の例を示す図である。図１５（ａ）〜（ｃ）は、それぞれ取引グループｇ２〜ｇ４のステップＳ３０６における１巡目の決済試行処理の実行結果の例を示す図である。図１５（ａ）の場合、ステップＳ３０１の実行後の決済順序に従い、ステップＳ３０１により試行が失敗した取引ｔ２２及びｔ２４のみについて、口座ａ２Ａ及びａ２Ｂの残高が補正された状態として、決済を試行する。そして、取引ｔ２２及びｔ２４が共に試行に成功する。尚、この場合、図９のステップＳ３０６においては、Ｎに"３"を設定し、Ｌに"４"を設定して、図１０の取引グループ決済試行処理を実行する。そのため、残高を補正する前に試行が成功した取引ｔ２１及びｔ２３については、試行の対象とならない。よって、不要な処理を減らすことができる。同様に、図１５（ｂ）及び（ｃ）の場合、図９のステップＳ３０６においては、Ｎに"１"を設定し、Ｌに"５"を設定して、図１０の取引グループ決済試行処理を実行する。ここでは、決済順序"１"及び"２"のみが試行に成功するが、以降の取引の試行は失敗する。
【００８１】
図９に戻り、取引グループ決済試行手段３５０は、ステップＳ３０２と同様に、試行に失敗した取引が存在するか否かを判定する（Ｓ３０７）。ステップＳ３０７において、試行に失敗した取引が存在しないと判定した場合、取引グループ決済試行手段３５０は、当該取引グループが"赤残連鎖取引"であると判定する（Ｓ３１１）。図８の例では、取引グループｇ２のみが"赤残連鎖取引"であると判定される。このとき、取引グループ決済試行手段３５０は、"赤残連鎖取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００８２】
その後、擬似ループ判定手段３７０は、擬似ループ判定処理を行う（Ｓ３０８）。ここで、図１６は、本発明の実施の形態１にかかる擬似ループ判定処理の流れを示すフローチャートである。尚、以下では、図８においては、取引グループｇ３〜ｇ６が処理対象となる。
【００８３】
まず、端点取引選択手段３７１は、始点及び終点取引を選択する（Ｓ６１）。具体的には、端点取引選択手段３７１は、取引情報記憶部３３を参照し、処理対象の取引グループ内の取引について、取引元口座ＩＤ３３３が他の取引の取引先口座ＩＤ３３４と一致しない取引である始点取引を選択する。また、端点取引選択手段３７１は、取引情報記憶部３３を参照し、処理対象の取引グループ内の取引について、取引先口座ＩＤ３３４が他の取引の取引元口座ＩＤ３３３と一致しない取引である終点取引を選択する。尚、始点及び終点取引を端点取引と呼ぶものとする。例えば、取引グループｇ３の場合、始点取引が取引ｔ３１、終点取引が取引ｔ３２として選択される。同様に、取引グループｇ４、ｇ５及びｇ６の場合、それぞれ始点取引が取引ｔ４１、ｔ５１及びｔ６１、また、終点取引が取引ｔ４２、ｔ５２及びｔ６２として選択される。
【００８４】
次に、端点取引処理手段３７２は、始点及び終点取引の決済順序を更新する（Ｓ６２）。具体的には、端点取引処理手段３７２は、始点取引における決済順序を、最初の順序として取引情報記憶部３３を更新し、終点取引における決済順序を、最後の順序として取引情報記憶部３３を更新する。例えば、取引グループｇ３の場合、端点取引選択手段３７１は、始点取引である取引ｔ３１の決済順序を"１"とし、終点取引である取引ｔ３２の決済順序を"５"として取引情報記憶部３３を更新する。同様に、取引グループｇ４、ｇ５及びｇ６の場合、端点取引選択手段３７１は、それぞれ始点取引である取引ｔ４１、ｔ５１及びｔ６１の決済順序を"１"とし、終点取引である取引ｔ４２、ｔ５２及びｔ６２の決済順序を"５"として取引情報記憶部３３を更新する。尚、始点取引又は終点取引が複数存在する場合、決済順序を同じ値とするとよい。
【００８５】
続いて、端点取引処理手段３７２は、始点取引に関する残高情報を更新する（Ｓ６３）。具体的には、端点取引処理手段３７２は、当該始点取引の決済が確定したと仮定して口座情報記憶部３２に格納された残高情報３２２を更新する。例えば、取引グループｇ３の場合、端点取引選択手段３７１は、始点取引の決済を試行して成功する場合に、図１１のステップＳ５４に基づき、取引元の口座である口座ａ３Ａ及び取引先の口座である口座ａ３Ｂのそれぞれの残高情報３２２を決済後の残高情報へ更新する。尚、ステップＳ３０５において、残高情報補正手段３６０により残高が補正された口座については、さらに、残高情報が更新されることとなる。
【００８６】
そして、擬似ループ判定手段３７０は、始点及び終点取引を除いて、取引グループ決済試行手段３５０により取引グループ決済試行処理を実行する（Ｓ６４）。例えば、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、決済順序が２以上かつ取引数未満となるように取引情報記憶部３３を更新する。そして、Ｎに"２"を設定し、Ｌに"取引数−１"を設定して、図１０の取引グループ決済試行処理を実行する。尚、ステップＳ６４においては、擬似ループ判定処理の対象となる取引グループに始点取引が存在しない場合、Ｎに"１"を設定する。また、終点取引が存在しない場合、Ｌに"取引数"を設定する。そして、図１０の取引グループ決済試行処理を実行する。例えば、取引グループがループ取引のみである場合や、始点取引又は終点取引の一方が存在しない場合が該当する。また、始点取引又は終点取引が複数存在する場合、Ｎに"３"以上の値を設定し、Ｌに"取引数−１"未満の値を設定して、図１０の取引グループ決済試行処理を実行する。
【００８７】
例えば、取引グループｇ３の場合、擬似ループ判定手段３７０は、始点又は終点取引以外の取引である取引ｔ３３、ｔ３４及びｔ３５について、決済順序を"２"〜"４"として更新する。そして、Ｎに"２"を設定し、Ｌに"４"を設定して、図１０の取引グループ決済試行処理を実行する。ここでは、決済順序"２"の取引ｔ３３の取引元の口座ａ３Ｂの残高情報３２２がステップＳ６３により"１０"に更新されているため、取引ｔ３３の試行が成功する。続いて、決済順序"３"の取引ｔ３４の取引元の口座ａ３Ｄの残高情報３２２が上記の試行により"１０"に更新されているため取引ｔ３４の、試行が成功する。さらに、決済順序"４"の取引ｔ３５の取引元の口座ａ３Ｅの残高情報３２２が上記の試行により"１０"に更新されているため取引ｔ３５の試行が成功する。そのため、決済順序"５"の取引ｔ３２の試行も成功することとなる。つまり、取引グループｇ３は、ステップＳ６４により全ての取引の試行が成功することとなる。また、取引グループｇ５の場合も同様である。このように、ステップＳ３０１及びＳ３０６における取引グループ決済試行処理において、試行に失敗した取引を含む取引グループであっても、ステップＳ６１〜Ｓ６４により、始点及び終点取引を除いた取引に対して試行を行うことにより、決済可能な決済順序を求めることができる。一方、取引グループｇ４及びｇ６の場合、ステップＳ６４によっても試行に失敗する取引が存在する。
【００８８】
その後、擬似ループ判定手段３７０は、ステップＳ３０２と同様に、試行に失敗した取引が存在するか否かを判定する（Ｓ６５）。ステップＳ６５において、試行に失敗した取引が存在しないと判定した場合、擬似ループ判定手段３７０は、擬似ループ判定処理を終了する。
【００８９】
ステップＳ６５において、試行に失敗した取引が存在すると判定した場合、起点口座選択手段３７３は、起点口座を選択する（Ｓ６６）。具体的には、起点口座選択手段３７３は、取引情報記憶部３３を参照し、ステップＳ６４において、試行に失敗した取引に含まれる口座から、１以上の取引先口座ＩＤ３３３かつ２以上の取引元口座ＩＤ３３４として設定される口座を選択する。例えば、取引グループｇ４の場合、口座ａ４Ｂは、取引ｔ４２及びｔ４３の取引元の口座であり、取引ｔ４１及びｔ４５の取引先の口座であるため、起点口座として選択される。また、取引グループｇ６の場合、口座ａ６Ｂは、取引ｔ６２及びｔ６３の取引元の口座であり、取引ｔ６１及びｔ６５の取引先の口座であるため、起点口座として選択される。
【００９０】
さらに、図１７は、本発明の実施の形態１にかかる起点口座が選択される取引グループの顕著な例を示す図である。図１７は、取引グループｇ７について、口座と取引との関係を概念で示した図である。尚、一取引の凡例は、図８（ｇ）と同様であるため、図示を省略する。ここで、取引グループｇ７の決済順序の初期設定が取引ｔ７１、ｔ７２、・・・ｔ７９の順序であるものとする。このとき、ステップＳ３０１において、取引ｔ７１、ｔ７２及びｔ７３までの試行が成功し、取引ｔ７４以降の試行が失敗する。ステップＳ３０４において、赤字口座が存在しないと判定され、擬似ループ判定処理（Ｓ３０８）が実行される。そして、取引グループｇ７の場合、取引ｔ７１が始点取引、取引ｔ７３が終点取引として選択される（Ｓ６１）。その後、ステップＳ６４により、取引ｔ７１及びｔ７３を除いて、取引グループ決済試行処理が実行される。このとき、取引ｔ７２、ｔ７４、ｔ７５、ｔ７６までが試行に成功し、取引ｔ７７〜ｔ７９の試行に失敗する。そのため、ステップＳ６５において、試行に失敗した取引が存在すると判定される。そこで、ステップＳ６６において、起点口座選択手段３７３は、取引ｔ７７〜ｔ７９に含まれる口座ａ７Ｂ、ａ７Ｇ及びａ７Ｈから、取引ｔ７２及びｔ７７の取引元の口座であり、取引ｔ７１及びｔ７９の取引先の口座である口座ａ７Ｂを起点口座として選択する。
【００９１】
そして、起点取引処理手段３７４は、起点取引の決済順序を更新する（Ｓ６７）。具体的には、起点取引処理手段３７４は、起点口座選択手段３７３により選択された口座が取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて取引情報記憶部３３を更新する。例えば、取引グループｇ７の場合、起点取引処理手段３７４は、口座ａ７Ｂが取引元の口座となる取引ｔ７７の決済順序を"２"、取引ｔ７２の決済順序を"２"より大きい値として、つまり、取引ｔ７７と取引ｔ７２との決済順序の先後関係を入れ替えて取引情報記憶部３３を更新する。同様に、取引グループｇ４及びｇ６の場合、起点取引処理手段３７４は、取引ｔ４３及びｔ６３の決済順序を"２"、取引ｔ４２及びｔ６２の決済順序を"取引数"として、つまり、取引ｔ４２と取引ｔ４３との決済順序の先後関係を入れ替えて、また、取引ｔ６２と取引ｔ６３との決済順序の先後関係を入れ替えて、取引情報記憶部３３を更新する。尚、ステップＳ６７においては、擬似ループ判定処理の対象となる取引グループに起点取引が存在しない場合、取引情報記憶部３３を更新しない。また、取引ｔ７７、ｔ４３及びｔ６３の決済順序は、"２"でなくとも構わない。
【００９２】
その後、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、取引グループ決済試行処理を行う（Ｓ６８）。このとき、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、取引グループ決済試行処理を行う。このとき、複数の起点取引の決済順序における先後関係を適宜入れ替えて、取引情報記憶部３３を更新し、取引グループ決済試行処理を行うとよい。そして、全ての取引について試行が成功するか、全ての順序の組み合わせについて試行が終了するまで繰り返し、決済の試行を行う。これにより、赤字口座が存在しない状態の対象の取引グループについて、決済可能か否かについて確実に判明させることができる。尚、ステップＳ６８では、対象となる複数の取引における決済順序の様々な組み合わせについて試行するため、処理時間が長くなる。しかし、ステップＳ６８の処理対象となる取引グループの数は、ステップＳ６４以前の処理により絞りこまれているため、少ないといえる。よって、ステップＳ６８の処理を行う効果が高いといえる。その後、擬似ループ判定手段３７０は、擬似ループ判定処理を終了する。尚、ステップＳ６６乃至Ｓ６８に代えて、擬似ループ判定手段３７０は、取引グループ内の始点及び終点取引を除いた取引について、単に、総当たりにして決済の試行を行ってもよい。
【００９３】
例えば、取引グループｇ７の場合、擬似ループ判定手段３７０は、始点取引ｔ７１及び終点取引ｔ７３を除いた取引ｔ７２、ｔ７４、ｔ７５、ｔ７６、ｔ７７、ｔ７８、ｔ７９について、起点取引ｔ７２及びｔ７７の決済順序の先後関係を入れ替えて、全ての決済順序の組み合わせについて試行を行う。これにより、取引ｔ７１、ｔ７７、ｔ７８、ｔ７９、ｔ７２、ｔ７４、ｔ７５、ｔ７６、ｔ７３の順序により決済可能であることが判明する。一方、取引グループｇ４及びｇ６の場合、全ての決済順序の組み合わせを試行しても決済可能な決済順序が存在しないことが判明する。
【００９４】
図９に戻り、擬似ループ判定手段３７０は、ステップＳ３０２と同様に、試行に失敗した取引が存在するか否かを判定する（Ｓ３０９）。ステップＳ３０９において、試行に失敗した取引が存在しないと判定した場合、擬似ループ判定手段３７０は、当該取引グループが"擬似ループ取引"であると判定する（Ｓ３１２）。尚、当該取引グループがステップＳ３０４により赤字口座が存在すると判定されていた場合、擬似ループ判定手段３７０は、当該取引グループが"赤残連鎖取引"かつ"擬似ループ取引"であると判定する。図８の例では、取引グループｇ５が"擬似ループ取引"であると判定され、取引グループｇ３が"赤残連鎖取引"かつ"擬似ループ取引"であると判定される。また、図１７の例である取引グループｇ７が"擬似ループ取引"であると判定される。このとき、擬似ループ判定手段３７０は、"擬似ループ取引"又は"赤残連鎖取引"かつ"擬似ループ取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００９５】
ステップＳ３０９において、試行に失敗した取引が存在すると判定した場合、擬似ループ判定手段３７０は、当該取引グループが"真正ループ取引"であると判定する（Ｓ３１３）。尚、当該取引グループがステップＳ３０４により赤字口座が存在すると判定されていた場合、擬似ループ判定手段３７０は、当該取引グループが"赤残連鎖取引"かつ"真正ループ取引"であると判定する。図８の例では、取引グループｇ６が"真正ループ取引"であると判定され、取引グループｇ４が"赤残連鎖取引"かつ"真正ループ取引"であると判定される。このとき、擬似ループ判定手段３７０は、"真正ループ取引"又は"赤残連鎖取引"かつ"真正ループ取引"であることを示す情報である判定結果（不図示）をグループＩＤ３３１に関連付けて取引情報記憶部３３に格納する。
【００９６】
図１８は、本発明の実施の形態１にかかる確定処理の流れを示すフローチャートである。まず、確定手段３８０は、取引情報記憶部３３を参照し、処理対象の取引グループにおける判定結果を確認する（Ｓ７０１）。ステップＳ７０１において判定結果が"通常取引"と確認された場合、確定手段３８０は、処理対象の取引グループにおける全取引のＳ３０１後の決済順序を決済可能なものとして確定する（Ｓ７０２）。例えば、取引グループｇ１の場合、図１２（ａ）の２巡目の決済順序が決済可能なものとして確定される。ここで、確定する処理として、例えば、当該取引グループに含まれる全ての取引の決済を実行するべく勘定系システム等へ通知するか、または、当該取引グループに含まれる口座の所有者へ決済可能である旨を通知する等であるとよい。
【００９７】
ステップＳ７０１において判定結果が"赤残連鎖取引"のみと確認された場合、確定手段３８０は、ステップＳ３０１後の決済順序の内、赤残取引より前の取引の決済順序を決済可能なものとして確定する（Ｓ７０３）。ここで、赤残取引とは、図９のステップＳ３０５による残高情報の補正された口座を取引元の口座とする取引の内、ステップＳ３０６において、決済の試行が成功した取引である。例えば、取引グループｇ２の場合、図１５（ａ）の赤残取引である取引ｔ２２以前の決済順序である取引ｔ２１及び取引ｔ２３の決済順序"１"及び"２"が決済可能なものとして確定される。
【００９８】
そして、確定手段３８０は、ステップＳ３０５により残高が補正された口座へ残高不足通知を行う（Ｓ７０４）。ここで、残高不足通知として、例えば、通知対象の口座の所有者へ残高不足であるために決済が行えない旨と、不足額を当該口座へ追加する旨等を通知するとよい。例えば、取引グループｇ２の場合、確定手段３８０は、口座ａ２Ａ及びａ２Ｂへ残高不足通知を行う。
【００９９】
ステップＳ７０１において判定結果が"擬似ループ取引"を含むと確認された場合、確定手段３８０は、さらに、判定結果が"赤残連鎖取引"を含むか否かを判定する（Ｓ７０５）。ステップＳ７０５において、判定結果が"赤残連鎖取引"を含むと判定した場合、確定手段３８０は、ステップＳ３０８後の決済順序の内、赤残取引より前の取引の決済順序を決済可能なものとして確定する（Ｓ７０６）。例えば、取引グループｇ３の場合、図１５（ｂ）の赤残取引である取引ｔ３１以前の決済順序である取引は存在しないため、決済可能な決済順序として確定されない。
【０１００】
そして、確定手段３８０は、ステップＳ７０４と同様に、ステップＳ３０５により残高が補正された口座へ残高不足通知を行う（Ｓ７０７）。例えば、取引グループｇ３の場合、確定手段３８０は、口座ａ３Ａへ残高不足通知を行う。
【０１０１】
ステップＳ７０５において、判定結果が"赤残連鎖取引"を含まないと判定した場合、確定手段３８０は、処理対象の取引グループにおける全取引のＳ３０８後の決済順序を決済可能なものとして確定する（Ｓ７０８）。例えば、取引グループｇ５の場合、取引ｔ５１、ｔ５３、ｔ５４、ｔ５５、ｔ５２の決済順序が決済可能なものとして確定される。
【０１０２】
ステップＳ７０１において判定結果が"真正ループ取引"を含むと確認された場合、確定手段３８０は、さらに、判定結果が"赤残連鎖取引"を含むか否かを判定する（Ｓ７０９）。ステップＳ７０９において、判定結果が"赤残連鎖取引"を含まないと判定した場合、ステップＳ７１１へ進む。ステップＳ７０９において、判定結果が"赤残連鎖取引"を含むと判定した場合、確定手段３８０は、ステップＳ７０４と同様に、ステップＳ３０５により残高が補正された口座へ残高不足通知を行う（Ｓ７１０）。例えば、取引グループｇ４の場合、確定手段３８０は、口座ａ４Ａへ残高不足通知を行う。
【０１０３】
その後、確定手段３８０は、ステップＳ３０１で試行が成功した取引の決済順序を確定する（Ｓ７１１）。例えば、取引グループｇ４の場合、図１３（ｄ）に示すように、ステップＳ３０１で試行が成功した取引が存在しないため、決済可能な決済順序として確定されない。取引グループｇ６の場合、図１３（ｆ）の取引ｔ６１及びｔ６２の決済順序"１"及び"２"が決済可能なものとして確定される。
【０１０４】
そして、確定手段３８０は、ループ取引に取引不可通知を行う（Ｓ７１２）。ここで、取引不可通知として、例えば、通知対象の口座の所有者へループ取引であるために決済が行えない旨と、関係する他の口座等を通知するとよい。例えば、取引グループｇ４の場合、確定手段３８０は、口座ａ４Ｂ、ａ４Ｄ及びａ４Ｅへ取引不可通知を行う。取引グループｇ６の場合、確定手段３８０は、口座ａ６Ｂ、ａ６Ｄ及びａ６Ｅへ取引不可通知を行う。
【０１０５】
その後、確定手段３８０は、確定処理を終了する。尚、図１８は、本発明の実施の形態１にかかる確定処理の一例であり、他の方法でも実現可能である。本発明の実施の形態１にかかる確定処理は、少なくとも決済順序調整処理により判定された取引グループの判定結果に応じて各取引の決済順序を確定すればよい。
【０１０６】
このように、本発明の実施の形態１では、取引グループ決済試行処理により、所定の順序により決済が可能である取引については、逐次、決済が確定したものとし、以後の試行の対象から除くものである。すなわち、一旦、試行が成功した取引については、原則として再度の試行を行わないようにする。そのため、総当たりで試行を行うことに比べて、試行回数を減らすことができる。つまり、決済可能な決済順序を網羅的に求めず、実際に決済可能である割合が高いケースを優先的に検出する。よって、複数の取引を連続して決済する場合に、決済可能な決済順序について、少ない試行回数により効率的に確定することができる。
【０１０７】
＜発明の実施の形態２＞
債券等の取引では、債券額を券種及び枚数により取り扱う場合がある。例えば、"１００"を１単位とする券種と、"５０"を１単位とする券種とがある場合、それぞれに券面の枚数を管理する必要がある。そして、取引は、券種及び枚数の指定が可能である。そのため、債券取引の場合、単に、口座の残高の金額において決済可能であっても、券種と枚数により決済不可能となる場合がある。そこで、本発明の実施の形態２にかかる決済順序確定システムは、本発明の実施の形態１にかかる決済順序確定システム３の残高情報補正手段３６０に変更を加えたものである。すなわち、本発明の実施の形態２にかかる残高情報補正手段は、取引が券種及び枚数により定まる債券における取引である場合に、取引グループに含まれる口座の残高における債券の券種及び枚数に基づき、口座当たりの残高を算出するものである。このとき、図１の口座情報記憶部３２には、残高情報３２２に代えて又は別途、債券の券種の識別情報と、当該券種の枚数とを記憶しているものとする。また、図１の取引情報記憶部３３には、取引ＩＤ３３２にかかる債券の券種の識別情報と、当該券種の枚数とを取引ＩＤ３３２に関連付けて記憶しているものとする。尚、本発明の実施の形態２にかかる決済順序確定システムは、本発明の実施の形態１と比べて、上述した以外の構成に変更がない。以下、実施の形態１との違いを中心に説明し、実施の形態１と同等の構成及び処理については、詳細な説明を省略する。
【０１０８】
図１９は、本発明の実施の形態２にかかる券種及び枚数を考慮した取引グループの例を示す図である。図１９（ａ）は、取引グループｇ８について、口座と取引との関係を概念で示した図である。また、図１９（ｂ）は、図１９（ａ）における一取引の凡例である。ここで、取引グループｇ８の決済順序の初期設定が取引ｔ８１、ｔ８２、・・・ｔ８７の順序であるものとする。また、各口座の下の括弧書きは、債券の券種及び枚数の初期残高を示し、各取引の下の取引額の括弧書きが"−"である取引は、債券の券種及び枚数の指定がない取引であるものとする。
【０１０９】
また、図２０（ａ）は、本発明の実施の形態１と同様に取引額のみで口座収支を算出した場合の口座収支の例を示す図である。また、図２０（ｂ）は、本発明の実施の形態２にかかる券種及び枚数を考慮した口座収支の例を示す図である。
【０１１０】
続いて、図９のステップＳ３０３において、口座ａ８Ａについての収支残高を算出する場合を説明する。まず、本発明の実施の形態１にかかる残高情報補正手段３６０は、口座情報記憶部３２から口座ａ８Ａの残高情報"１００"を取得する。そして、残高情報補正手段３６０は、取引情報記憶部３３から口座ａ８Ａを取引先の口座とする取引ｔ８１、ｔ８２及びｔ８３の取引額"２００"、"１００"及び"１５０"を取得し、取引額合計（入）"４５０"を算出する。また、残高情報補正手段３６０は、取引情報記憶部３３から口座ａ８Ａを取引元の口座とする取引ｔ８４、ｔ８５、ｔ８６及びｔ８７の取引額"５０"、"１５０"、"１００"及び"１００"を取得し、取引額合計（払）"４００"を算出する。そして、残高情報補正手段３６０は、取得した残高情報"１００"に、取引額合計（入）"４５０"を加算し、取引額合計（払）"４００"を減算して、収支残高"１５０"を算出する。
【０１１１】
一方、本発明の実施の形態２にかかる残高情報補正手段は、口座情報記憶部３２から口座ａ８Ａの券種"１００"の枚数"１"を初期枚数として取得する。そして、当該残高情報補正手段は、取引情報記憶部３３から口座ａ８Ａを取引先の口座とする取引の内、券種指定のある取引ｔ８２の券種"１００"の枚数"１"を取得し、併せて、券種指定のない取引ｔ８１及びｔ８３の取引額"２００"及び"１５０"を取得する。そして、当該残高情報補正手段は、取得した取引額"２００"及び"１５０"についてできるだけ大きな単位の券種の枚数として換算する。つまり、券種"１００"の枚数"３"及び券種"５０"の枚数"１"と換算する。その後、当該残高情報補正手段は、券種"１００"の合計枚数（入）"４"及び券種"５０"の合計枚数（入）"１"を算出する。また、当該残高情報補正手段は、取引情報記憶部３３から口座ａ８Ａを取引元の口座とする取引の内、券種指定のある取引ｔ８４の券種"５０"の枚数"１"を取得し、併せて、券種指定のない取引ｔ８５、ｔ８６及びｔ８７の取引額"１５０"、"１００"及び"１００"を取得する。そして、当該残高情報補正手段は、取得した取引額"１５０"、"１００"及び"１００"についてできるだけ大きな単位の券種の枚数として換算する。つまり、券種"１００"の枚数"３"及び券種"５０"の枚数"１"と換算する。その後、当該残高情報補正手段は、券種"１００"の合計枚数（払）"３"及び券種"５０"の合計枚数（払）"２"を算出する。そして、当該残高情報補正手段は、券種"１００"について、初期枚数"１"に、合計枚数（入）"４"を加算し、合計枚数（払）"３"を減算して、収支枚数"２"を算出する。併せて、当該残高情報補正手段は、券種"５０"について、初期枚数"０"に、合計枚数（入）"１"を加算し、合計枚数（払）"２"を減算して、収支枚数"−１"を算出する。すなわち、図２０（ｂ）に示すように、口座ａ８Ａは、収支残高が赤字と判定される。
【０１１２】
このように、図２０（ａ）のように券種及び枚数を考慮しない場合、黒字と判定されるが、本発明の実施の形態２により、図２０（ｂ）のように券種及び枚数を考慮することにより、赤字と判定され、単に、口座の残高の金額において決済可能であっても、券種と枚数により決済不可能となる場合を正確に決済可能な決済順序を確定することができる。
【０１１３】
＜その他の発明の実施の形態＞
さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
【符号の説明】
【０１１４】
１ａ、１ｂ、・・・１ｎ 端末
２ ネットワーク
３ 決済順序確定システム
３０１ ＣＰＵ
３０２ ＲＡＭ
３０３ ＲＯＭ
３０４ 通信部
３０５ ハードディスク
３０６ ＯＳ
３０７ 決済順序確定プログラム
３１ 制御部
３２ 口座情報記憶部
３２１ 口座ＩＤ
３２２ 残高情報
３３ 取引情報記憶部
３３１ グループＩＤ
３３２ 取引ＩＤ
３３３ 取引元口座ＩＤ
３３４ 取引先口座ＩＤ
３３５ 取引額
３３６ 決済順序
３４０ 取引グループ生成手段
３５０ 取引グループ決済試行手段
３５１ 取引決済試行手段
３５２ 残高情報更新手段
３５３ 繰り返し実行手段
３５４ 決済順序更新手段
３６０ 残高情報補正手段
３７０ 擬似ループ判定手段
３７１ 端点取引選択手段
３７２ 端点取引処理手段
３７３ 起点口座選択手段
３７４ 起点取引処理手段
３８０ 確定手段
ａ１Ａ、ａ１Ｂ、ａ１Ｃ、ａ１Ｄ、ａ１Ｅ 口座
ａ２Ａ、ａ２Ｂ、ａ２Ｃ、ａ２Ｄ、ａ２Ｅ 口座
ａ３Ａ、ａ３Ｂ、ａ３Ｃ、ａ３Ｄ、ａ３Ｅ 口座
ａ４Ａ、ａ４Ｂ、ａ４Ｃ、ａ４Ｄ、ａ４Ｅ 口座
ａ５Ａ、ａ５Ｂ、ａ５Ｃ、ａ５Ｄ、ａ５Ｅ 口座
ａ６Ａ、ａ６Ｂ、ａ６Ｃ、ａ６Ｄ、ａ６Ｅ 口座
ａ７Ａ、ａ７Ｂ、ａ７Ｃ、ａ７Ｄ、ａ７Ｅ、ａ７Ｆ、ａ７Ｇ、ａ７Ｈ 口座
ａ８Ａ、ａ８Ｂ、ａ８Ｃ、ａ８Ｄ、ａ８Ｅ、ａ８Ｆ、ａ８Ｇ、ａ８Ｈ 口座
ｇ１、ｇ２、ｇ３、ｇ４、ｇ５、ｇ６、ｇ７、ｇ８ 取引グループ
ｔ１１、ｔ１２、ｔ１３、ｔ１４ 取引
ｔ２１、ｔ２２、ｔ２３、ｔ２４ 取引
ｔ３１、ｔ３２、ｔ３３、ｔ３４、ｔ３５ 取引
ｔ４１、ｔ４２、ｔ４３、ｔ４４、ｔ４５ 取引
ｔ５１、ｔ５２、ｔ５３、ｔ５４、ｔ５５ 取引
ｔ６１、ｔ６２、ｔ６３、ｔ６４、ｔ６５ 取引
ｔ７１、ｔ７２、ｔ７３、ｔ７４、ｔ７５、ｔ７６、ｔ７７、ｔ７８、ｔ７９ 取引
ｔ８１、ｔ８２、ｔ８３、ｔ８４、ｔ８５、ｔ８６、ｔ８７ 取引
【特許請求の範囲】
【請求項１】
取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済可能な決済順序を確定する決済順序確定システムであって、
前記取引に関わる口座の残高情報を記憶する残高情報記憶部と、
前記取引グループに含まれる各取引における決済順序を記憶する決済順序記憶部と、
前記取引における前記決済順序を確定する処理を制御する制御部と、を備え、
前記制御部は、
前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整手段と、
前記第１の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定手段と、を備え、
前記第１の決済順序調整手段は、
前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行手段と、
前記取引決済試行手段による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高情報更新手段と、
Ｎが１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第１の繰り返し実行手段と、
前記第１の繰り返し実行手段による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新手段と、
前記決済順序更新手段による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第２の繰り返し実行手段と、
を含むことを特徴とする決済順序確定システム。
【請求項２】
前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記取引グループに含まれる全ての取引の決済が確定したと仮定した場合の口座当たりの残高を算出し、算出された残高が所定値以下となる口座について、残高が所定値となる取引額を加算して前記残高情報記憶部に格納された残高情報を補正する残高情報補正手段と、
前記残高情報補正手段により補正された残高情報を用いて、前記決済順序記憶部に格納された決済順序に基づき、前記第１の決済順序調整手段により前記試行が失敗した全ての取引についての決済を試行することにより前記決済順序を調整する第２の決済順序調整手段と、をさらに備え、
前記確定手段は、前記第２の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序としてさらに確定することを特徴とする請求項１に記載の決済順序確定システム。
【請求項３】
前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記取引グループに含まれる各取引から、取引元の口座が当該取引グループ内の他の取引の取引先の口座と一致しない取引である始点取引と、取引先の口座が当該取引グループ内の他の取引の取引元の口座と一致しない取引である終点取引とを選択する端点取引選択手段と、
前記始点取引における決済順序を、最初の順序として前記決済順序記憶部を更新し、当該始点取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、前記終点取引における決済順序を、最後の順序として前記決済順序記憶部を更新する端点取引処理手段と、
前記端点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整する第３の決済順序調整手段と、をさらに備え、
前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記決済順序記憶部に格納された決済順序を決済可能な順序として確定することを特徴とする請求項１又は２に記載の決済順序確定システム。
【請求項４】
前記第３の決済順序調整手段により試行が失敗した取引に含まれる口座から、自己が前記取引先の口座となる取引が存在し、かつ、自己が前記取引元の口座となる取引が２以上存在する口座を選択する起点口座選択手段と、
前記起点口座選択手段により選択された口座が前記取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて前記決済順序記憶部を更新する起点取引処理手段と、をさらに備え、
前記第３の決済順序調整手段は、前記起点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整することを特徴とする請求項３に記載の決済順序確定システム。
【請求項５】
前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序として確定することを特徴とする請求項１乃至４のいずれか１項に記載の決済順序確定システム。
【請求項６】
取引元の口座から取引先の口座へ所定額を決済するための複数の取引を外部から受け付け、受け付けた複数の取引の中から、前記取引先の口座又は前記取引元の口座の少なくとも一方の口座が他の取引と共通する取引を選択し、選択した取引の集合を前記取引グループとして生成する取引グループ生成手段をさらに備え、
前記第１の決済順序調整手段は、前記取引グループ生成手段により生成された取引グループに対して、前記決済順序を調整することを特徴とする請求項１乃至５のいずれか１項に記載の決済順序確定システム。
【請求項７】
前記残高情報補正手段は、前記取引が券種及び枚数により定まる債券における取引である場合に、前記取引グループに含まれる口座の残高における債券の券種及び枚数に基づき、前記口座当たりの残高を算出することを特徴とする請求項２に記載の決済順序確定システム。
【請求項８】
取引に関わる口座の残高情報を記憶する残高情報記憶部と、
取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部と、
前記取引における前記決済順序を確定する処理を制御する制御部と、
を備えるコンピュータにおける前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を制御するための決済順序確定方法であって、
前記制御部において、
前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整ステップと、
前記第１の決済順序調整ステップにより調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定ステップと、を含み、
前記第１の決済順序調整ステップは、
前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行ステップと、
前記取引決済試行ステップによる試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新ステップと、
Ｎが１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第１の繰り返し実行ステップと、
前記第１の繰り返し実行ステップによる実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新ステップと、
前記決済順序更新ステップによる更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第２の繰り返し実行ステップと、
を含むことを特徴とする決済順序確定方法。
【請求項９】
取引に関わる口座の残高情報を記憶する残高情報記憶部と、
取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部と、
前記取引における前記決済順序を確定する処理を制御する制御部と、
を備えるコンピュータに、前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を実行させる決済順序確定プログラムであって、
前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整処理と、
前記第１の決済順序調整処理により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定処理と、を含み、
前記第１の決済順序調整処理は、
前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行処理と、
前記取引決済試行処理による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新処理と、
Ｎが１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第１の繰り返し実行処理と、
前記第１の繰り返し実行処理による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新処理と、
前記決済順序更新処理による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第２の繰り返し実行処理と、
を含むことを特徴とする決済順序確定プログラム。
【請求項１】
取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済可能な決済順序を確定する決済順序確定システムであって、
前記取引に関わる口座の残高情報を記憶する残高情報記憶部と、
前記取引グループに含まれる各取引における決済順序を記憶する決済順序記憶部と、
前記取引における前記決済順序を確定する処理を制御する制御部と、を備え、
前記制御部は、
前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整手段と、
前記第１の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定手段と、を備え、
前記第１の決済順序調整手段は、
前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行手段と、
前記取引決済試行手段による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高情報更新手段と、
Ｎが１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第１の繰り返し実行手段と、
前記第１の繰り返し実行手段による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新手段と、
前記決済順序更新手段による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行手段による処理及び前記残高情報更新手段による処理を繰り返し実行する第２の繰り返し実行手段と、
を含むことを特徴とする決済順序確定システム。
【請求項２】
前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記残高情報記憶部及び前記決済順序記憶部を参照し、前記取引グループに含まれる全ての取引の決済が確定したと仮定した場合の口座当たりの残高を算出し、算出された残高が所定値以下となる口座について、残高が所定値となる取引額を加算して前記残高情報記憶部に格納された残高情報を補正する残高情報補正手段と、
前記残高情報補正手段により補正された残高情報を用いて、前記決済順序記憶部に格納された決済順序に基づき、前記第１の決済順序調整手段により前記試行が失敗した全ての取引についての決済を試行することにより前記決済順序を調整する第２の決済順序調整手段と、をさらに備え、
前記確定手段は、前記第２の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序としてさらに確定することを特徴とする請求項１に記載の決済順序確定システム。
【請求項３】
前記確定手段により前記決済順序が決済可能な順序として確定されなかった場合に、前記取引グループに含まれる各取引から、取引元の口座が当該取引グループ内の他の取引の取引先の口座と一致しない取引である始点取引と、取引先の口座が当該取引グループ内の他の取引の取引元の口座と一致しない取引である終点取引とを選択する端点取引選択手段と、
前記始点取引における決済順序を、最初の順序として前記決済順序記憶部を更新し、当該始点取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、前記終点取引における決済順序を、最後の順序として前記決済順序記憶部を更新する端点取引処理手段と、
前記端点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整する第３の決済順序調整手段と、をさらに備え、
前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記決済順序記憶部に格納された決済順序を決済可能な順序として確定することを特徴とする請求項１又は２に記載の決済順序確定システム。
【請求項４】
前記第３の決済順序調整手段により試行が失敗した取引に含まれる口座から、自己が前記取引先の口座となる取引が存在し、かつ、自己が前記取引元の口座となる取引が２以上存在する口座を選択する起点口座選択手段と、
前記起点口座選択手段により選択された口座が前記取引元の口座となる取引である２以上の起点取引の決済順序における先後関係を入れ替えて前記決済順序記憶部を更新する起点取引処理手段と、をさらに備え、
前記第３の決済順序調整手段は、前記起点取引処理手段により更新された決済順序に基づき、前記取引グループの内、前記始点取引及び前記終点取引を除いた取引についての決済を試行することにより前記決済順序を調整することを特徴とする請求項３に記載の決済順序確定システム。
【請求項５】
前記確定手段は、前記第３の決済順序調整手段により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、前記第１の決済順序調整手段により前記試行が成功した最後の取引の決済順序までを決済可能な順序として確定することを特徴とする請求項１乃至４のいずれか１項に記載の決済順序確定システム。
【請求項６】
取引元の口座から取引先の口座へ所定額を決済するための複数の取引を外部から受け付け、受け付けた複数の取引の中から、前記取引先の口座又は前記取引元の口座の少なくとも一方の口座が他の取引と共通する取引を選択し、選択した取引の集合を前記取引グループとして生成する取引グループ生成手段をさらに備え、
前記第１の決済順序調整手段は、前記取引グループ生成手段により生成された取引グループに対して、前記決済順序を調整することを特徴とする請求項１乃至５のいずれか１項に記載の決済順序確定システム。
【請求項７】
前記残高情報補正手段は、前記取引が券種及び枚数により定まる債券における取引である場合に、前記取引グループに含まれる口座の残高における債券の券種及び枚数に基づき、前記口座当たりの残高を算出することを特徴とする請求項２に記載の決済順序確定システム。
【請求項８】
取引に関わる口座の残高情報を記憶する残高情報記憶部と、
取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部と、
前記取引における前記決済順序を確定する処理を制御する制御部と、
を備えるコンピュータにおける前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を制御するための決済順序確定方法であって、
前記制御部において、
前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整ステップと、
前記第１の決済順序調整ステップにより調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定ステップと、を含み、
前記第１の決済順序調整ステップは、
前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行ステップと、
前記取引決済試行ステップによる試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新ステップと、
Ｎが１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第１の繰り返し実行ステップと、
前記第１の繰り返し実行ステップによる実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新ステップと、
前記決済順序更新ステップによる更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行ステップ及び前記残高更新ステップを繰り返し実行する第２の繰り返し実行ステップと、
を含むことを特徴とする決済順序確定方法。
【請求項９】
取引に関わる口座の残高情報を記憶する残高情報記憶部と、
取引グループに含まれるＬ（Ｌは、３以上の整数）個の取引における決済順序を記憶する決済順序記憶部と、
前記取引における前記決済順序を確定する処理を制御する制御部と、
を備えるコンピュータに、前記取引グループに含まれる各取引における決済可能な決済順序を確定する処理を実行させる決済順序確定プログラムであって、
前記決済順序記憶部に格納された決済順序に基づき、前記取引グループに含まれる取引の決済を試行することにより前記決済順序を調整する第１の決済順序調整処理と、
前記第１の決済順序調整処理により調整された決済順序により前記取引グループに含まれる全ての取引の決済の試行が成功する場合に、当該決済順序を決済可能な順序として確定する確定処理と、を含み、
前記第１の決済順序調整処理は、
前記残高情報記憶部及び前記決済順序記憶部を参照し、前記決済順序がＮ（Ｎは、１以上かつＬ以下の整数）番目の取引の決済を試行する取引決済試行処理と、
前記取引決済試行処理による試行が成功した場合に、当該Ｎ番目の取引の決済が確定したと仮定して前記残高情報記憶部に格納された残高情報を更新し、当該試行が失敗した場合には、当該Ｎ番目の取引の決済が行われなかったものとする残高更新処理と、
Ｎが１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第１の繰り返し実行処理と、
前記第１の繰り返し実行処理による実行の結果、前記試行が成功した取引における決済順序以前に、前記試行が失敗した取引が存在する場合、前記試行が失敗した全ての取引における決済順序が、前記試行が成功した取引の全てであるＭ個（Ｍは、１以上かつＬ未満の整数）の取引における決済順序より後の順序であるＭ＋１以降となるように前記決済順序記憶部を更新する決済順序更新処理と、
前記決済順序更新処理による更新後に、ＮがＭ＋１からＬまでの間、前記取引決済試行処理及び前記残高更新処理を繰り返し実行する第２の繰り返し実行処理と、
を含むことを特徴とする決済順序確定プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１１−２０４１４８（Ｐ２０１１−２０４１４８Ａ）
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願番号】特願２０１０−７３０６８（Ｐ２０１０−７３０６８）
【出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
[ Back to top ]