JP6321772B1 - 顧客自身が自由に条件設定可能な機能を有する口座および資金管理システム - Google Patents

Abstract

【課題】口座間の資金移動について、あらかじめ指定した日に、指定した出金口座から入金口座へ同じ金額を定期的に振込すること、特定の日に特定の出金口座から、事前に指定した複数の入金口座へ各々指定した金額を振込することなどはできるものの、利用者のマニュアル運用がほとんどである。また、複数人で口座を管理することもあるが、管理対象の口座が個人口座を含むこともあり、セキュリティ上の観点からも、その取扱いには十分な注意が必要である。【解決手段】コンピューティングシステムによって、利用者自身が資金移動の条件を自由に設定することができ、対象の口座に対するアクセスが、設定された条件を満たす場合に、設定されたアクションを実行することができる。また、当該システムは、利用者間および口座ごとのアクセス制御を行なったりすることなどにより一定の安全性を確保することができる。【選択図】図２

Description

本発明は、顧客自身が自由に条件設定可能な機能を有する口座および資金管理システムに関する。より詳細には、顧客自身が口座間の資金移動の条件を自由に設定することができ、対象の口座に対するアクセス（入金、出金、残高照会など）が、設定された条件を満たす場合に、設定されたアクション（資金移動など）を実行することができる口座および資金管理システムに関する。

現状、家族、グループ各社や外部パートナー、およびサークルなどの団体において、複数の口座を持ち、資金管理をしている場面がある。例えば、ある家族の給与受取用口座に給与が振り込まれた場合、給与のうちの所定の金額を、それぞれ、お小遣いとして父親の口座に、仕送りとして子供の口座に、貯蓄用に別の口座に移動している。

このような資金移動について、あらかじめ指定した日に、指定した出金口座から入金口座へ同じ金額を定期的に振込すること、特定の日に特定の出金口座から、事前に指定した複数の入金口座へ各々指定した金額を振込すること（例えば、給与振込）などはできるものの、原則、利用者のマニュアル運用がほとんどである。その大きな要因として資金移動が流動的であることによる。例えば、移動する金額が固定額ではなく、預金額に対する割合である場合や、移動先の口座の残高が所定の金額以下になるなどの条件成立に応じて資金移動を実行する場合など、より複雑な条件が求められることによる。また、より具体的な例を挙げると、暫くの間、出費が多くなることが予想されるため、給与受取用口座から貯蓄用口座への移動金額を減らしたい（または移動自体を停止したい）場合などがある。このように、利用者によって様々な場面が想定されるため、利用者（金融機関の契約顧客）自身が自由に条件設定可能な機能を有する口座および資金管理システムが求められている。また、複数人で１つまたは複数の口座を管理することもあるが、管理対象の口座が個人口座を含むこともあり、セキュリティ上の観点からも、その取扱いには十分な注意が必要である。

本発明は、このような目的を達成するために、利用者が設定した条件が満たされた場合に口座間の資金移動を実行するサーバコンピュータであって、前記サーバコンピュータは、
前記利用者が設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定し、
前記条件が満たされていると判定した場合に、前記条件データに設定された出金口座から入金口座への資金移動を実行する
ように構成されたことを特徴とする。

また、前段落に記載のサーバコンピュータにおいて、前記判定することは、前記条件の対象となる口座データに対するアクセスがあったこと、または前記条件データに設定された所定の日時が到来したことに応答して実行されることを特徴とする。

さらに、前２段落に記載のサーバコンピュータにおいて、前記条件は、複数の条件であり、前記条件を満たすとは、前記複数の条件のすべてを満たすことであることを特徴とする。

そして、前３段落に記載のサーバコンピュータにおいて、前記利用者は複数人おり、同一のグループに設定された前記利用者の口座間で前記資金移動が実行され、前記利用者は、同一のグループに設定された前記利用者に関する前記条件データのみ設定可能であり、前記条件データを設定可能な前記利用者は許可された者のみであることを特徴とする。

また、前段落に記載のサーバコンピュータにおいて、前記条件データは、前記利用者が同一のグループに設定された別の利用者に対する承認を得るという条件を含み、前段落に記載のサーバコンピュータは、
前記別の利用者の使用するクライアントコンピュータに承認依頼用のレポートを送信し、
前記クライアントコンピュータから、前記レポートに対する承認結果を受信し、
前記承認結果が承認を示す場合に、前記資金移動を実行する
ようにさらに構成されたことを特徴とする。

また本発明は、別の実施形態において、利用者が設定した条件が満たされた場合に口座間の資金移動を実行するサーバコンピュータによって実行される方法であって、前記方法は、
前記サーバコンピュータが、前記利用者が設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定するステップと、
前記サーバコンピュータが、前記条件が満たされていると判定した場合に、前記条件データに設定された出金口座から入金口座への資金移動を実行するステップと
を備えたことを特徴とする。

さらに本発明は、さらに別の実施形態において、利用者が設定した条件が満たされた場合に口座間の資金移動を実行する方法をサーバコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは前記サーバコンピュータによって実行されると、
前記サーバコンピュータが、前記利用者が設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定するステップと、
前記サーバコンピュータが、前記条件が満たされていると判定した場合に、前記条件データに設定された出金口座から入金口座への資金移動を実行するステップと
を前記サーバコンピュータに実行させることを特徴とする。

以上説明したように、本発明によれば、コンピューティングシステムによって、利用者自身が資金移動の条件を自由に設定することができ、対象の口座に対するアクセスが、設定された条件を満たす場合に、設定されたアクションを実行することができる。また、当該システムは、アクションを実行した場合に関連する利用者にレポートを通知したり、利用者間および口座ごとのアクセス制御を行なったりすることにより、セキュリティ上の観点からも一定の安全性を確保することができる。

本発明の一実施形態に係るシステム構成を示す図である。 本発明の一実施形態に係る口座アクセスをトリガとする資金移動処理を示すフロー図である。 本発明の一実施形態に係る所定日時の到来をトリガとする資金移動処理を示すフロー図である。 本発明の一実施形態に係る利用者データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る口座データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る条件データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係るレポートデータ記憶部に格納されたデータを示す図である。

以下、添付した図面を参照して、本発明の実施形態に係る口座および資金管理システムを詳細に説明する。図１は、本発明の一実施形態に係るシステム構成を示す図である。図１において、例えば、データセンタなどに設置された、各金融機関の口座および資金を管理する資金管理サーバ１００が、ネットワーク１０３（例えば、インターネット）を介して、利用者端末１０１および全銀システムサーバ１０２と通信を行うように構成される。なお、図１では、資金管理サーバ１００を１つのサーバコンピュータとして表しているが、複数のサーバコンピュータによる分散型コンピューティングシステムとして構築することもできる。

利用者端末１０１は、本システムの利用者が使用するパーソナルコンピュータやモバイル端末である。利用者は利用者端末１０１を使用して、資金管理サーバ１００が提供する専用のＷｅｂサイトを介して本システムにアクセスし、資金移動の条件を設定することができる。また、利用者端末１０１は、設定した条件に基づいて資金移動が実行された場合は、資金管理サーバ１００から、実行結果を示すレポートを受信することができる。

資金管理サーバ１００は、各金融機関が管理するサーバコンピュータである。資金管理サーバ１００は、利用者によって設定された条件に基づいて、トリガ条件（所定の口座データへのアクセス、所定日時の到来など）を監視する。トリガ条件を満たした場合、資金管理サーバ１００は、利用者によって設定されたアクション（振替、振込、レポート通知など）を実行する。

全銀システムサーバ１０２は、全国銀行資金決済ネットワークが管理するサーバコンピュータである。各金融機関は、全銀システムを通すことにより、異なる金融機関に対しての振込もオンライン処理で行なうことが可能となっている。

次に、資金管理サーバ１００の構成を詳細に説明する。なお、図１では、単一のサーバコンピューティングシステムを想定し、必要な構成だけを示している。資金管理サーバ１００は、それぞれがシステムバス１１５を介して接続された、ＣＰＵ１１０、ＲＡＭ１１１、入力装置１１２、出力装置１１３、通信制御装置１１４、および記憶装置１１６を備えている。記憶装置１１６は不揮発性記憶媒体（ＲＯＭやＨＤＤなど）で構成され、振込処理に関連するソフトウェアプログラムを格納したプログラム格納領域と、当該ソフトウェアプログラムで取り扱うデータを格納したデータ格納領域とを備えている。以下に説明するプログラム格納領域の各手段は、実際は独立したソフトウェアプログラム、そのルーチンやコンポーネントなどであり、記憶装置１１６に格納されている。各手段は、実行時にＣＰＵ１１０によって記憶装置１１６から呼び出されＲＡＭ１１１のワークエリアに展開されることで、データベースなどに適宜アクセスしながら各機能を発揮することができる。

図１の記憶装置１１６におけるプログラム格納領域に格納されたソフトウェアプログラムは、本発明に関連するものだけを列挙すると、トリガ条件監視手段１２０、資金移動手段１２１、およびレポート通知手段１２２を備えている。これらの手段は、ＣＰＵ１１０によって実行される。

図１のトリガ条件監視手段１２０は、各口座データに対するアクセス（入金、出金、残高照会など）を監視し、アクセス内容が、条件データ記憶部１３２に格納された条件データを満たすか否かを判定する。また、トリガ条件監視手段１２０は、当該条件データに設定された所定の日時が到来した場合に、設定された口座の内容（例えば、残高）が条件データを満たすか否かを判定する。

図１の資金移動手段１２１は、トリガ条件監視手段１２０による条件判定により、条件を満たすと判定された場合、条件データに基づいて、対応する口座間の振替または振込処理を実行する。

図１のレポート通知手段１２２は、トリガ条件監視手段１２０による条件判定により、条件を満たすと判定され、さらに条件データに実行アクションとしてレポート通知が設定されている場合、レポートデータを作成し、レポートデータ記憶部１３３に格納する。また、レポート通知手段１２２は、作成したレポートデータを、対応する利用者端末１０１に送信する。また、資金移動に対する承認依頼を行なう場合、レポート通知手段１２２は、承認依頼用のレポートデータを作成し、レポートデータ記憶部１３３に格納した上で、対応する利用者端末１０１に送信する。

次に、図１の記憶装置１１６におけるデータ格納領域は、本発明に関連するものだけを列挙すると、利用者データ記憶部１３０、口座データ記憶部１３１、条件データ記憶部１３２、およびレポートデータ記憶部１３３を備える。いずれも、記憶装置１１６内に確保された一定の記憶領域である。

図１の利用者データ記憶部１３０は、本システムの利用者（金融機関の契約顧客）に関するデータを格納する。図４は、本発明の一実施形態に係る利用者データ記憶部１３０に格納されたデータを示す図である。

図４における利用者データには、利用者を一意に示す「利用者ＩＤ」、利用者を関連付けるための「グループＩＤ」、利用者によって自由に設定可能である利用者の名称を示す「利用者名」、利用者の契約口座の提供元である金融機関を一意に示す「金融機関コード」、当該金融機関の支店を一意に示す「支店コード」、契約口座の口座種別（科目）を一意に示す「口座種別」、各金融機関内での契約口座の識別番号を示す「口座番号」、利用者に対するレポートの通知先を示す「レポート先」、同一グループ内での共有口座の利用可否を示す「共有口座利用可否」、他の利用者から自身の口座データへのアクセス許可レベルを示す「他からアクセス」、他の利用者の口座データへの自身のアクセス許可レベルを示す「他へのアクセス」、および条件データ（図６）の設定および更新の可否を示す「条件設定可否」などを格納することができる。

利用者データは、本システムを利用するにあたり、利用者が予め登録しておくマスタデータである。利用者データにおける「グループＩＤ」は、グループＩＤが同一の利用者間でのみ条件設定や資金移動を可能とするために用いられる。例えば、ある利用者が専用のＷｅｂサイトを使用して条件設定を行なう際、当該Ｗｅｂサイトには自身と同一グループの利用者に関する情報しか表示されず、同一グループの利用者の口座に対してのみ条件設定が行なえるように制御することができる。また、「利用者名」は、利用者によって任意に設定することができ、当該Ｗｅｂサイトやレポートに表示して使用することができる。

「口座種別」には、口座種別を示す数値（例えば、１：普通預金、２：定期預金、３：当座預金・・・）を設定することができる。また、利用者の契約口座は、「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」によって一意に識別され、口座データ（図５）における同一名称の各データ項目と同一の番号を設定することにより、本データと口座データとを紐付けることができる。なお、同一の利用者が複数の口座を持ち、各口座に対する条件データを設定する場合は、利用者データ上はそれぞれを別利用者扱いとし、複数レコードの設定が必要となる。これは、同一の利用者の同一の口座を、複数のグループで利用する場合も同様である。

利用者データにおける「共有口座利用可否」、「他からアクセス」、および「他へのアクセス」には、それぞれ、共有口座データ、他の利用者から自身の口座データ、および他の利用者の口座データへのアクセス許可レベルを示す数値（例えば、０：利用不可、１：参照のみ可、２：出金のみ可、３：フルアクセス・・・）を設定することができる。同様に、利用者データにおける「条件設定可否」には、条件データ（図６）の設定および更新に対する許可レベルを示す数値（例えば、０：不可、１：可能・・・）を設定することができる。

図１の口座データ記憶部１３１は、本システムにおいて入金口座または出金口座として使用する利用者の契約口座に関するデータを格納する。図５は、本発明の一実施形態に係る口座データ記憶部１３１に格納されたデータを示す図である。

図５における口座データには、契約口座の提供元である金融機関を一意に示す「金融機関コード」およびその名称を示す「金融機関名」、当該金融機関の支店を一意に示す「支店コード」およびその名称を示す「支店名」、契約口座の口座種別（科目）を一意に示す「口座種別」、各金融機関内での契約口座の識別番号を示す「口座番号」、契約口座の口座名義を示す「口座名義」、ならびに契約口座の現在の預金額を示す「預金額」などを格納することができる。

口座データは、利用者の契約口座開設時に金融機関によって登録されるマスタデータである。利用者の契約口座は、「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」によって一意に識別される。「口座種別」には、口座種別を示す数値（例えば、１：普通預金、２：定期預金、３：当座預金・・・）を設定することができる。また、図５における口座データは、実口座を想定して記載されているが、別の実施形態では、仮想口座により本発明を実現することもできる。これにより、入金を行なった利用者（入金者）ができるため、より細かい条件設定を行なうことも可能である（例えば、ある仮想口座に入金があった場合、入金者は特定されるため、条件データとして入金者を設定しなくても、入金者ごとに実行アクションを分けることなどが可能）。

図１の条件データ記憶部１３２は、本システムにおける資金移動の条件および条件を満たした場合の実行アクションに関するデータを格納する。図６は、本発明の一実施形態に係る条件データ記憶部１３２に格納されたデータを示す図である。

図６における条件データには、資金移動のトリガとなる１つ目の条件（条件１）を示す「トリガ条件１ａ」および「トリガ条件１ｂ」、条件１の判定対象となる口座を一意に示すための「対象口座１」、条件１の判定に対する金額の閾値を示す「条件金額１ａ」および「条件金額１ｂ」、条件１との複合条件となる２つ目の条件（条件２）を示す「トリガ条件２ａ」および「トリガ条件２ｂ」、条件２の判定対象となる口座を一意に示すための「対象口座２」、条件２の判定に対する金額の閾値を示す「条件金額２ａ」および「条件金額２ｂ」、条件を満たす場合に実行するアクションを示す「実行アクション」、資金移動の対象となる出金口座および入金口座をそれぞれ一意に示すための「出金口座」および「入金口座」、資金移動を行なう金額を示す「実行金額」、ならびにアクション実行時のレポート通知先を示す「レポート先１」および「レポート先２」などを格納することができる。

条件データは、本システムを利用するにあたり、許可された利用者が予め登録しておくマスタデータである。図６における「トリガ条件１ａ」、「トリガ条件１ｂ」、「条件金額１ａ」、「条件金額１ｂ」、「トリガ条件２ａ」、「トリガ条件２ｂ」、「条件金額２ｂ」、「実行アクション」、および「実行金額」には、説明を解り易くするために文字列を設定しているが、各条件やアクションの内容を一意に示すことができる数値やコードを設定することもできる。「対象口座１」、「対象口座２」、「出金口座」、および「入金口座」のそれぞれには、利用者データ（図４）における「利用者ＩＤ」を設定する。これにより、利用者データにおける「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」から口座データ（図５）を紐付けることができ、１つの口座を識別することができる。なお、別の実施形態では、条件データに、「対象口座１」、「対象口座２」、「出金口座」、および「入金口座」のそれぞれに対する「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」を持ち、口座データを直接紐付けることもできる。

図６における「トリガ条件１ａ」〜「条件金額１ｂ」が資金移動のトリガとなる１つ目の条件（条件１）を示し、「トリガ条件２ａ」〜「条件金額２ｂ」が２つ目の条件（条件２）を示す。条件１および条件２は複合条件であり、両条件を満たす場合に、対応するアクションが実行される。なお、さらに条件を追加する場合は、「トリガ条件３ａ」〜「条件金額３ｂ」、「トリガ条件４ａ」〜「条件金額４ｂ」・・・などのデータ項目を追加し、条件３、条件４・・・などと任意に条件を追加することもできる。

図６における条件設定をより詳細に示す。図６の１レコード目は、条件１のみが設定されており、「対象口座１」から紐付けられる口座番号“00000002”の口座（利用者“お母さん”の口座）に、５０万円以上が入金された場合（条件１を満たす場合）、「出金口座」から紐付けられる口座番号“00000002”の口座から、「入金口座」から紐付けられる口座番号“00000001”の口座（利用者“お父さん”の口座）に３万円の振替処理を実行することを示している。また、図６の１レコード目は、当該振替処理の実行結果を、「レポート先１」および「レポート先２」が示すレポート先（この場合、利用者“お父さん”および“お母さん”のレポート先）に対してレポートとして送信することも示している。なお、さらにレポート先を追加する場合は、条件データ（図６）に「レポート先３」、「レポート先４」・・・などのデータ項目を追加し、任意にレポート先を追加することができる。

図６の２レコード目は、条件１および条件２が設定されており、「対象口座１」から紐付けられる口座番号“11111111”の口座（利用者“太郎”の口座）の残高が、許可された利用者によって照会され（“残高”を“手動”で照会）、預金額が５万円以下であった場合（条件１を満たす場合）、さらに条件２の判定を実行することを示している。さらに、条件２の判定において、「対象口座２」から紐付けられる口座番号“00000002”の口座の残高が１万円以上であった場合（条件２も満たす場合）、対応するアクションを実行することを示している。

図６の３レコード目は、例えば、バッチ処理で定期的に毎月２５日に、「対象口座１」から紐付けられる口座番号“00000002”の口座の残高が照会され、残高が１５万円以上ある場合に、対応するアクションを実行することを示している。同様に、図６の４レコード目は、バッチ処理で定期的に毎週月曜日に、「対象口座１」から紐付けられる口座番号“00000002”の口座の残高が照会され、残高が１０万円以下であった場合に、「レポート先１」が示す利用者“お母さん”のレポート先に、残高が閾値以下になった旨を示すアラーム用のレポートを送信することを示している。

図６の５レコード目は、例えば、バッチ処理により、指定日である“2016/12/20”が到来した際に、対応するアクションを実行することを示している。図６の６レコード目は、「対象口座１」から紐付けられる口座番号“22222222”の口座から出金された結果、残高が５千円以下になってしまい（条件１を満たす場合）、さらに「対象口座２」から紐付けられる口座番号“00000002”の口座の残高が１０万円以上の場合（条件２も満たす場合）、対応するアクションを実行することを示している。

図６の７レコード目は、「対象口座１」から紐付けられる口座番号“22222222”から、「対象口座２」から紐付けられる口座番号“00000002”に対して“任意”の金額を移動するための承認依頼を実行し、承認が得られた場合に、対応するアクションを実行することを示している。例えば、口座番号“22222222”の利用者である“次郎”が本システムを介して“任意”の金額を指定し、口座番号“00000002”の利用者である“お母さん”に対して承認依頼を行なうと、“お母さん”のレポート先に対してその旨が通知され、“お母さん”が承認結果を送信する（例えば、承認依頼メール上の承認用のリンクをクリックし、本システムにログインして「承認」ボタンを押下する）。承認依頼が承認された場合は、「条件金額１ａ」に設定された金額を「実行金額」として、口座番号“00000002”の口座から、口座番号“22222222”の口座に対する振込処理を実行し、レポート先に対し、その旨を通知する。なお、承認依頼を否認した場合は、承認依頼者である“次郎”のレポート先に対し、その旨を通知することもできる。

図１のレポートデータ記憶部１３３は、設定された条件を満たした場合のアクション実行時などに通知されるレポートに関するデータを格納する。図７は、本発明の一実施形態に係るレポートデータ記憶部１３３に格納されたデータを示す図である。

図７におけるレポートデータには、利用者に対するレポートの通知先を示す「レポート先」、およびレポートの内容を示す「レポート内容」などを格納することができる。

次に、図２のフローチャート、および図４−７のデータを参照して、本発明の一実施形態に係る資金移動処理を流れに沿って説明する。図２は、本発明の一実施形態に係る口座アクセスをトリガとする資金移動処理を示すフロー図である。本処理は、本システムが、利用者ａの口座（口座Ａ）データに対する何らかのアクセス（入金、出金、残高照会など）を確認することをトリガとして、口座Ａに対して設定された条件および関連する条件を満たす場合に、対応するアクション（資金移動など）を実行するものである。

まず、トリガ条件監視手段１２０は、各口座に対するアクセスを監視しており、口座Ａに対して何らかのアクセスがあったことを確認する（ステップ２０１）。

次に、トリガ条件監視手段１２０は、口座Ａに対する条件を検索する（ステップ２０２）。具体的には、口座Ａの「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」を検索キーとして利用者データ（図４）における口座Ａの利用者ａの「利用者ＩＤ」を抽出する。その後、口座Ａに対するアクセス内容と抽出した「利用者ＩＤ」とに基づいて、条件データ（図６）の「トリガ条件１ａ」、「トリガ条件１ｂ」、および「対象口座１」を検索し（すなわち、条件１）、設定された条件の有無を確認する。口座Ａに対して設定された条件が無い場合は、ステップ２０３のＮｏルートに進み、本処理は終了する。

一方、口座Ａに対して設定された条件がある場合、ステップ２０３のＹｅｓルートに進み、トリガ条件監視手段１２０は、その条件を満たすか否かを判定する（ステップ２０４）。具体的には、ステップ２０２で検索した条件データの「トリガ条件１ａ」、「トリガ条件１ｂ」、「条件金額１ａ」、および「条件金額１ｂ」に設定された条件を満たすか否かを判定する。例えば、口座Ａに対するアクセス内容が入金または出金である場合は、入金額または出金額が「条件金額１ａ」および「条件金額１ｂ」に設定された金額条件を満たすか否かを判定する。または、口座Ａに対するアクセス内容が残高照会である場合は、口座Ａの口座番号を検索キーとして、口座データ（図５）を検索し、口座データにおける「預金額」が「条件金額１ａ」および「条件金額１ｂ」に設定された金額条件を満たすか否かを判定する。

ステップ２０４において、口座Ａに対して設定された条件を満たさないと判定された場合、Ｎｏルートに進み、本処理は終了する。一方、口座Ａに対して設定された条件を満たすと判定された場合、Ｙｅｓルートに進み、トリガ条件監視手段１２０は、関連する他の条件を検索する（ステップ２０５）。関連する他の条件とは、ステップ２０２で検索された条件１に関連する条件２以降の条件である。具体的には、ステップ２０２で検索した条件データ（図６）の「トリガ条件２ａ」、「トリガ条件２ｂ」、および「対象口座２」を検索し（すなわち、条件２である。条件３以降については後述する）、設定された条件の有無を確認する。

ステップ２０６において、関連する他の条件がある場合、Ｙｅｓルートに進み、その条件を満たすか否かを判定する（ステップ２０７）。具体的には、条件データ（図６）の「対象口座２」から紐付けられる口座に対して、「トリガ条件２ａ」、「トリガ条件２ｂ」、「条件金額２ａ」、および「条件金額２ｂ」に設定された条件を満たすか否かを判定する。例えば、「トリガ条件２ａ」および「トリガ条件２ｂ」によって示される条件が残高照会である場合、「対象口座２」から紐付けられる口座番号を検索キーとして、口座データ（図５）を検索し、口座データにおける「預金額」が「条件金額２ａ」および「条件金額２ｂ」に設定された金額条件を満たすか否かを判定する。

ステップ２０７において、関連する条件を満たさないと判定された場合、Ｎｏルートに進み、本処理は終了する。一方、関連する条件を満たすと判定された場合、Ｙｅｓルートに進み、さらに関連する他の条件（すなわち、条件３以降）があるか否かを判定し（ステップ２０５）、関連する他の条件が存在する限り、ステップ２０５〜２０７を繰り返す。

ステップ２０６において、関連する他の条件が無い、またはこれ以上関連する他の条件が無い場合、Ｎｏルートに進み、資金移動手段１２１および／またはレポート通知手段１２２は、対応するアクションを実行する（ステップ２０７）。具体的には、ステップ２０２で検索した条件データ（図６）の「実行アクション」が示すアクションを実行する。例えば、「実行アクション」によって示されるアクションが“振替”または“振込”である場合、資金移動手段１２１は、条件データ（図６）の「出金口座」から紐付けられる口座から「入金口座」から紐付けられる口座に、「実行金額」が示す金額を移動する。さらに、レポート通知手段１２２は、アクションの実行結果を示すレポートデータ（図７）を作成し、レポートデータ記憶部１３３に格納する。そして、レポート通知手段１２２は、作成したレポートデータを、条件データ（図６）の「レポート先１」および「レポート先２」が示す通知先に送信する。一方、「実行アクション」によって示されるアクションが“レポート”である場合は、例えば、「対象口座１」から紐付けられる口座の残高が「条件金額１ａ」および「条件金額１ｂ」に設定された条件を満たす（例えば、設定金額以下）場合などが想定されるため、その旨を示すレポートデータ（図７）を作成し、レポートデータ記憶部１３３に格納した上で、「レポート先１」および「レポート先２」が示す通知先に送信する。

次に、図３のフローチャート、および図４−７のデータを参照して、図２で説明した実施形態とは異なる実施形態に係る資金移動処理を流れに沿って説明する。図３は、本発明の一実施形態に係る所定日時の到来をトリガとする資金移動処理を示すフロー図である。本処理は、本システムが、所定の日時の到来をトリガとして、関連する条件を満たす場合に、対応するアクション（資金移動など）を実行するものである。

まず、トリガ条件監視手段１２０は、所定の日時が到来したか否かを判定する（ステップ３０１）。具体的には、定期的に（例えば、１時間に１回のバッチ処理により）条件データ（図６）の「トリガ条件１ａ」が“指定日到来”を示すレコードの「トリガ条件１ｂ」に設定された日時と、資金管理サーバ１００のシステム日時とを比較し、トリガ条件の指定日が到来したか否かを判定する。また、「トリガ条件１ｂ」が“定期（・・・）”を示すレコードも同様の判定を実行することができる。

ステップ３０１にて、指定日が到来していないと判定された場合は、Ｎｏルートに進み、本処理は終了する。この場合、次のバッチ処理の起動を待ち（例えば、１時間後）、再度ステップ３０１を実行することになる。なお、図６の条件データには様々な利用者の条件データが格納されているため、ステップ３０１の対象となるレコードが複数存在することが想定される。この場合、本処理は対象レコードの数だけ実行されることになる。

一方、ステップ３０１にて、指定日が到来したと判定された場合は、Ｙｅｓルートに進み、トリガ条件監視手段１２０は、関連する他の条件を検索する（ステップ３０２）。以降、ステップ３０２〜３０５は、図２で説明した実施形態におけるステップ２０５〜２０８と同様の処理を実行する。

以上により、コンピューティングシステムによって、利用者自身が資金移動の条件を自由に設定することができ、対象の口座に対するアクセスが、設定された条件を満たす場合に、設定されたアクションを実行することができる。また、当該システムは、アクションを実行した場合に関連する利用者にレポートを通知したり、利用者間および口座ごとのアクセス制御を行なったりすることにより、セキュリティ上の観点からも一定の安全性を確保することができる。

Claims (6)

1. 利用者が予め設定した条件が満たされた場合に口座間の資金移動を実行するサーバコンピュータであって、前記サーバコンピュータは、
   前記利用者が予め設定した条件を条件データとして記憶し、前記条件データに予め設定された条件が満たされているか否かを判定し、前記条件データは、対象口座、および前記対象口座に対する入金額、出金額または残高に関するデータを少なくとも含み、前記条件が満たされているか否かを判定することは、
   前記条件データに第１の対象口座に対する第１の条件が設定されているか否かを判定し、
   前記第１の条件が設定されていると判定した場合に、前記第１の条件が満たされているか否かを判定し、
   前記第１の条件が満たされていると判定した場合に、前記条件データに前記第１の条件に関連する第２の条件が設定されているか否かを判定し、
   前記第２の条件が設定されていると判定した場合に、前記第２の条件が満たされているか否かを判定する
   ことを含み、
   前記第２の条件が満たされていると判定した場合に、前記条件データに関連付けられる出金口座から入金口座への資金移動を実行する
   ように構成されたことを特徴とするサーバコンピュータ。
2. 前記条件データは、さらに前記資金移動を実行するための所定の日時に関するデータを含むことを特徴とする請求項１に記載のサーバコンピュータ。
3. 前記利用者は複数人おり、同一のグループに設定された前記利用者の口座間で前記資金移動が実行され、前記利用者は、同一のグループに設定された前記利用者に関する前記条件データのみ設定可能であり、前記条件データを設定可能な前記利用者は許可された者のみであることを特徴とする請求項１または２に記載のサーバコンピュータ。
4. 前記条件データは、前記利用者が同一のグループに設定された別の利用者に対する承認を得るという条件を含み、前記サーバコンピュータは、
   前記別の利用者の使用するクライアントコンピュータに承認依頼用のレポートを送信し、
   前記クライアントコンピュータから、前記レポートに対する承認結果を受信し、
   前記承認結果が承認を示す場合に、前記資金移動を実行する
   ようにさらに構成されたことを特徴とする請求項３に記載のサーバコンピュータ。
5. 利用者が予め設定した条件が満たされた場合に口座間の資金移動を実行するサーバコンピュータによって実行される方法であって、前記方法は、
   前記サーバコンピュータが、前記利用者が予め設定した条件を条件データとして記憶し、前記条件データに予め設定された条件が満たされているか否かを判定するステップであって、前記条件データは、対象口座、および前記対象口座に対する入金額、出金額または残高に関するデータを少なくとも含み、前記条件が満たされているか否かを判定するステップは、
   前記条件データに第１の対象口座に対する第１の条件が設定されているか否かを判定するステップと、
   前記第１の条件が設定されていると判定した場合に、前記第１の条件が満たされているか否かを判定するステップと、
   前記第１の条件が満たされていると判定した場合に、前記条件データに前記第１の条件に関連する第２の条件が設定されているか否かを判定するステップと、
   前記第２の条件が設定されていると判定した場合に、前記第２の条件が満たされているか否かを判定するステップと
   を含む、ステップと、
   前記サーバコンピュータが、前記第２の条件が満たされていると判定した場合に、前記条件データに関連付けられる出金口座から入金口座への資金移動を実行するステップと
   を備えたことを特徴とする方法。
6. 利用者が予め設定した条件が満たされた場合に口座間の資金移動を実行する方法をサーバコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは前記サーバコンピュータによって実行されると、
   前記サーバコンピュータが、前記利用者が予め設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定するステップであって、前記条件データは、対象口座、および前記対象口座に対する入金額、出金額または残高に関するデータを少なくとも含み、前記条件が満たされているか否かを判定するステップは、
   前記条件データに第１の対象口座に対する第１の条件が設定されているか否かを判定するステップと、
   前記第１の条件が設定されていると判定した場合に、前記第１の条件が満たされているか否かを判定するステップと、
   前記第１の条件が満たされていると判定した場合に、前記条件データに前記第１の条件に関連する第２の条件が設定されているか否かを判定するステップと、
   前記第２の条件が設定されていると判定した場合に、前記第２の条件が満たされているか否かを判定するステップと
   を含む、ステップと、
   前記サーバコンピュータが、前記第２の条件が満たされていると判定した場合に、前記条件データに関連付けられる出金口座から入金口座への資金移動を実行するステップと
   を前記サーバコンピュータに実行させることを特徴とするコンピュータプログラム。