(58)【調査した分野】(Int.Cl.,DB名)
前記利用者は複数人おり、同一のグループに設定された前記利用者の口座間で前記資金移動が実行され、前記利用者は、同一のグループに設定された前記利用者に関する前記条件データのみ設定可能であり、前記条件データを設定可能な前記利用者は許可された者のみであることを特徴とする請求項1または2に記載のサーバコンピュータ。
利用者が予め設定した条件が満たされた場合に口座間の資金移動を実行する方法をサーバコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは前記サーバコンピュータによって実行されると、
前記サーバコンピュータが、前記利用者が予め設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定するステップであって、前記条件データは、対象口座、および前記対象口座に対する入金額、出金額または残高に関するデータを少なくとも含み、前記条件が満たされているか否かを判定するステップは、
前記条件データに第1の対象口座に対する第1の条件が設定されているか否かを判定するステップと、
前記第1の条件が設定されていると判定した場合に、前記第1の条件が満たされているか否かを判定するステップと、
前記第1の条件が満たされていると判定した場合に、前記条件データに前記第1の条件に関連する第2の条件が設定されているか否かを判定するステップと、
前記第2の条件が設定されていると判定した場合に、前記第2の条件が満たされているか否かを判定するステップと
を含む、ステップと、
前記サーバコンピュータが、前記第2の条件が満たされていると判定した場合に、前記条件データに関連付けられる出金口座から入金口座への資金移動を実行するステップと
を前記サーバコンピュータに実行させることを特徴とするコンピュータプログラム。
【発明の概要】
【発明が解決しようとする課題】
【0003】
このような資金移動について、あらかじめ指定した日に、指定した出金口座から入金口座へ同じ金額を定期的に振込すること、特定の日に特定の出金口座から、事前に指定した複数の入金口座へ各々指定した金額を振込すること(例えば、給与振込)などはできるものの、原則、利用者のマニュアル運用がほとんどである。その大きな要因として資金移動が流動的であることによる。例えば、移動する金額が固定額ではなく、預金額に対する割合である場合や、移動先の口座の残高が所定の金額以下になるなどの条件成立に応じて資金移動を実行する場合など、より複雑な条件が求められることによる。また、より具体的な例を挙げると、暫くの間、出費が多くなることが予想されるため、給与受取用口座から貯蓄用口座への移動金額を減らしたい(または移動自体を停止したい)場合などがある。このように、利用者によって様々な場面が想定されるため、利用者(金融機関の契約顧客)自身が自由に条件設定可能な機能を有する口座および資金管理システムが求められている。また、複数人で1つまたは複数の口座を管理することもあるが、管理対象の口座が個人口座を含むこともあり、セキュリティ上の観点からも、その取扱いには十分な注意が必要である。
【課題を解決するための手段】
【0004】
本発明は、このような目的を達成するために、利用者が設定した条件が満たされた場合に口座間の資金移動を実行するサーバコンピュータであって、前記サーバコンピュータは、
前記利用者が設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定し、
前記条件が満たされていると判定した場合に、前記条件データに設定された出金口座から入金口座への資金移動を実行する
ように構成されたことを特徴とする。
【0005】
また、前段落に記載のサーバコンピュータにおいて、前記判定することは、前記条件の対象となる口座データに対するアクセスがあったこと、または前記条件データに設定された所定の日時が到来したことに応答して実行されることを特徴とする。
【0006】
さらに、前2段落に記載のサーバコンピュータにおいて、前記条件は、複数の条件であり、前記条件を満たすとは、前記複数の条件のすべてを満たすことであることを特徴とする。
【0007】
そして、前3段落に記載のサーバコンピュータにおいて、前記利用者は複数人おり、同一のグループに設定された前記利用者の口座間で前記資金移動が実行され、前記利用者は、同一のグループに設定された前記利用者に関する前記条件データのみ設定可能であり、前記条件データを設定可能な前記利用者は許可された者のみであることを特徴とする。
【0008】
また、前段落に記載のサーバコンピュータにおいて、前記条件データは、前記利用者が同一のグループに設定された別の利用者に対する承認を得るという条件を含み、前段落に記載のサーバコンピュータは、
前記別の利用者の使用するクライアントコンピュータに承認依頼用のレポートを送信し、
前記クライアントコンピュータから、前記レポートに対する承認結果を受信し、
前記承認結果が承認を示す場合に、前記資金移動を実行する
ようにさらに構成されたことを特徴とする。
【0009】
また本発明は、別の実施形態において、利用者が設定した条件が満たされた場合に口座間の資金移動を実行するサーバコンピュータによって実行される方法であって、前記方法は、
前記サーバコンピュータが、前記利用者が設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定するステップと、
前記サーバコンピュータが、前記条件が満たされていると判定した場合に、前記条件データに設定された出金口座から入金口座への資金移動を実行するステップと
を備えたことを特徴とする。
【0010】
さらに本発明は、さらに別の実施形態において、利用者が設定した条件が満たされた場合に口座間の資金移動を実行する方法をサーバコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは前記サーバコンピュータによって実行されると、
前記サーバコンピュータが、前記利用者が設定した条件を条件データとして記憶し、前記条件データに設定された条件が満たされているか否かを判定するステップと、
前記サーバコンピュータが、前記条件が満たされていると判定した場合に、前記条件データに設定された出金口座から入金口座への資金移動を実行するステップと
を前記サーバコンピュータに実行させることを特徴とする。
【発明の効果】
【0011】
以上説明したように、本発明によれば、コンピューティングシステムによって、利用者自身が資金移動の条件を自由に設定することができ、対象の口座に対するアクセスが、設定された条件を満たす場合に、設定されたアクションを実行することができる。また、当該システムは、アクションを実行した場合に関連する利用者にレポートを通知したり、利用者間および口座ごとのアクセス制御を行なったりすることにより、セキュリティ上の観点からも一定の安全性を確保することができる。
【発明を実施するための形態】
【0013】
以下、添付した図面を参照して、本発明の実施形態に係る口座および資金管理システムを詳細に説明する。
図1は、本発明の一実施形態に係るシステム構成を示す図である。
図1において、例えば、データセンタなどに設置された、各金融機関の口座および資金を管理する資金管理サーバ100が、ネットワーク103(例えば、インターネット)を介して、利用者端末101および全銀システムサーバ102と通信を行うように構成される。なお、
図1では、資金管理サーバ100を1つのサーバコンピュータとして表しているが、複数のサーバコンピュータによる分散型コンピューティングシステムとして構築することもできる。
【0014】
利用者端末101は、本システムの利用者が使用するパーソナルコンピュータやモバイル端末である。利用者は利用者端末101を使用して、資金管理サーバ100が提供する専用のWebサイトを介して本システムにアクセスし、資金移動の条件を設定することができる。また、利用者端末101は、設定した条件に基づいて資金移動が実行された場合は、資金管理サーバ100から、実行結果を示すレポートを受信することができる。
【0015】
資金管理サーバ100は、各金融機関が管理するサーバコンピュータである。資金管理サーバ100は、利用者によって設定された条件に基づいて、トリガ条件(所定の口座データへのアクセス、所定日時の到来など)を監視する。トリガ条件を満たした場合、資金管理サーバ100は、利用者によって設定されたアクション(振替、振込、レポート通知など)を実行する。
【0016】
全銀システムサーバ102は、全国銀行資金決済ネットワークが管理するサーバコンピュータである。各金融機関は、全銀システムを通すことにより、異なる金融機関に対しての振込もオンライン処理で行なうことが可能となっている。
【0017】
次に、資金管理サーバ100の構成を詳細に説明する。なお、
図1では、単一のサーバコンピューティングシステムを想定し、必要な構成だけを示している。資金管理サーバ100は、それぞれがシステムバス115を介して接続された、CPU110、RAM111、入力装置112、出力装置113、通信制御装置114、および記憶装置116を備えている。記憶装置116は不揮発性記憶媒体(ROMやHDDなど)で構成され、振込処理に関連するソフトウェアプログラムを格納したプログラム格納領域と、当該ソフトウェアプログラムで取り扱うデータを格納したデータ格納領域とを備えている。以下に説明するプログラム格納領域の各手段は、実際は独立したソフトウェアプログラム、そのルーチンやコンポーネントなどであり、記憶装置116に格納されている。各手段は、実行時にCPU110によって記憶装置116から呼び出されRAM111のワークエリアに展開されることで、データベースなどに適宜アクセスしながら各機能を発揮することができる。
【0018】
図1の記憶装置116におけるプログラム格納領域に格納されたソフトウェアプログラムは、本発明に関連するものだけを列挙すると、トリガ条件監視手段120、資金移動手段121、およびレポート通知手段122を備えている。これらの手段は、CPU110によって実行される。
【0019】
図1のトリガ条件監視手段120は、各口座データに対するアクセス(入金、出金、残高照会など)を監視し、アクセス内容が、条件データ記憶部132に格納された条件データを満たすか否かを判定する。また、トリガ条件監視手段120は、当該条件データに設定された所定の日時が到来した場合に、設定された口座の内容(例えば、残高)が条件データを満たすか否かを判定する。
【0020】
図1の資金移動手段121は、トリガ条件監視手段120による条件判定により、条件を満たすと判定された場合、条件データに基づいて、対応する口座間の振替または振込処理を実行する。
【0021】
図1のレポート通知手段122は、トリガ条件監視手段120による条件判定により、条件を満たすと判定され、さらに条件データに実行アクションとしてレポート通知が設定されている場合、レポートデータを作成し、レポートデータ記憶部133に格納する。また、レポート通知手段122は、作成したレポートデータを、対応する利用者端末101に送信する。また、資金移動に対する承認依頼を行なう場合、レポート通知手段122は、承認依頼用のレポートデータを作成し、レポートデータ記憶部133に格納した上で、対応する利用者端末101に送信する。
【0022】
次に、
図1の記憶装置116におけるデータ格納領域は、本発明に関連するものだけを列挙すると、利用者データ記憶部130、口座データ記憶部131、条件データ記憶部132、およびレポートデータ記憶部133を備える。いずれも、記憶装置116内に確保された一定の記憶領域である。
【0023】
図1の利用者データ記憶部130は、本システムの利用者(金融機関の契約顧客)に関するデータを格納する。
図4は、本発明の一実施形態に係る利用者データ記憶部130に格納されたデータを示す図である。
【0024】
図4における利用者データには、利用者を一意に示す「利用者ID」、利用者を関連付けるための「グループID」、利用者によって自由に設定可能である利用者の名称を示す「利用者名」、利用者の契約口座の提供元である金融機関を一意に示す「金融機関コード」、当該金融機関の支店を一意に示す「支店コード」、契約口座の口座種別(科目)を一意に示す「口座種別」、各金融機関内での契約口座の識別番号を示す「口座番号」、利用者に対するレポートの通知先を示す「レポート先」、同一グループ内での共有口座の利用可否を示す「共有口座利用可否」、他の利用者から自身の口座データへのアクセス許可レベルを示す「他からアクセス」、他の利用者の口座データへの自身のアクセス許可レベルを示す「他へのアクセス」、および条件データ(
図6)の設定および更新の可否を示す「条件設定可否」などを格納することができる。
【0025】
利用者データは、本システムを利用するにあたり、利用者が予め登録しておくマスタデータである。利用者データにおける「グループID」は、グループIDが同一の利用者間でのみ条件設定や資金移動を可能とするために用いられる。例えば、ある利用者が専用のWebサイトを使用して条件設定を行なう際、当該Webサイトには自身と同一グループの利用者に関する情報しか表示されず、同一グループの利用者の口座に対してのみ条件設定が行なえるように制御することができる。また、「利用者名」は、利用者によって任意に設定することができ、当該Webサイトやレポートに表示して使用することができる。
【0026】
「口座種別」には、口座種別を示す数値(例えば、1:普通預金、2:定期預金、3:当座預金・・・)を設定することができる。また、利用者の契約口座は、「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」によって一意に識別され、口座データ(
図5)における同一名称の各データ項目と同一の番号を設定することにより、本データと口座データとを紐付けることができる。なお、同一の利用者が複数の口座を持ち、各口座に対する条件データを設定する場合は、利用者データ上はそれぞれを別利用者扱いとし、複数レコードの設定が必要となる。これは、同一の利用者の同一の口座を、複数のグループで利用する場合も同様である。
【0027】
利用者データにおける「共有口座利用可否」、「他からアクセス」、および「他へのアクセス」には、それぞれ、共有口座データ、他の利用者から自身の口座データ、および他の利用者の口座データへのアクセス許可レベルを示す数値(例えば、0:利用不可、1:参照のみ可、2:出金のみ可、3:フルアクセス・・・)を設定することができる。同様に、利用者データにおける「条件設定可否」には、条件データ(
図6)の設定および更新に対する許可レベルを示す数値(例えば、0:不可、1:可能・・・)を設定することができる。
【0028】
図1の口座データ記憶部131は、本システムにおいて入金口座または出金口座として使用する利用者の契約口座に関するデータを格納する。
図5は、本発明の一実施形態に係る口座データ記憶部131に格納されたデータを示す図である。
【0029】
図5における口座データには、契約口座の提供元である金融機関を一意に示す「金融機関コード」およびその名称を示す「金融機関名」、当該金融機関の支店を一意に示す「支店コード」およびその名称を示す「支店名」、契約口座の口座種別(科目)を一意に示す「口座種別」、各金融機関内での契約口座の識別番号を示す「口座番号」、契約口座の口座名義を示す「口座名義」、ならびに契約口座の現在の預金額を示す「預金額」などを格納することができる。
【0030】
口座データは、利用者の契約口座開設時に金融機関によって登録されるマスタデータである。利用者の契約口座は、「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」によって一意に識別される。「口座種別」には、口座種別を示す数値(例えば、1:普通預金、2:定期預金、3:当座預金・・・)を設定することができる。また、
図5における口座データは、実口座を想定して記載されているが、別の実施形態では、仮想口座により本発明を実現することもできる。これにより、入金を行なった利用者(入金者)ができるため、より細かい条件設定を行なうことも可能である(例えば、ある仮想口座に入金があった場合、入金者は特定されるため、条件データとして入金者を設定しなくても、入金者ごとに実行アクションを分けることなどが可能)。
【0031】
図1の条件データ記憶部132は、本システムにおける資金移動の条件および条件を満たした場合の実行アクションに関するデータを格納する。
図6は、本発明の一実施形態に係る条件データ記憶部132に格納されたデータを示す図である。
【0032】
図6における条件データには、資金移動のトリガとなる1つ目の条件(条件1)を示す「トリガ条件1a」および「トリガ条件1b」、条件1の判定対象となる口座を一意に示すための「対象口座1」、条件1の判定に対する金額の閾値を示す「条件金額1a」および「条件金額1b」、条件1との複合条件となる2つ目の条件(条件2)を示す「トリガ条件2a」および「トリガ条件2b」、条件2の判定対象となる口座を一意に示すための「対象口座2」、条件2の判定に対する金額の閾値を示す「条件金額2a」および「条件金額2b」、条件を満たす場合に実行するアクションを示す「実行アクション」、資金移動の対象となる出金口座および入金口座をそれぞれ一意に示すための「出金口座」および「入金口座」、資金移動を行なう金額を示す「実行金額」、ならびにアクション実行時のレポート通知先を示す「レポート先1」および「レポート先2」などを格納することができる。
【0033】
条件データは、本システムを利用するにあたり、許可された利用者が予め登録しておくマスタデータである。
図6における「トリガ条件1a」、「トリガ条件1b」、「条件金額1a」、「条件金額1b」、「トリガ条件2a」、「トリガ条件2b」、「条件金額2b」、「実行アクション」、および「実行金額」には、説明を解り易くするために文字列を設定しているが、各条件やアクションの内容を一意に示すことができる数値やコードを設定することもできる。「対象口座1」、「対象口座2」、「出金口座」、および「入金口座」のそれぞれには、利用者データ(
図4)における「利用者ID」を設定する。これにより、利用者データにおける「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」から口座データ(
図5)を紐付けることができ、1つの口座を識別することができる。なお、別の実施形態では、条件データに、「対象口座1」、「対象口座2」、「出金口座」、および「入金口座」のそれぞれに対する「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」を持ち、口座データを直接紐付けることもできる。
【0034】
図6における「トリガ条件1a」〜「条件金額1b」が資金移動のトリガとなる1つ目の条件(条件1)を示し、「トリガ条件2a」〜「条件金額2b」が2つ目の条件(条件2)を示す。条件1および条件2は複合条件であり、両条件を満たす場合に、対応するアクションが実行される。なお、さらに条件を追加する場合は、「トリガ条件3a」〜「条件金額3b」、「トリガ条件4a」〜「条件金額4b」・・・などのデータ項目を追加し、条件3、条件4・・・などと任意に条件を追加することもできる。
【0035】
図6における条件設定をより詳細に示す。
図6の1レコード目は、条件1のみが設定されており、「対象口座1」から紐付けられる口座番号“00000002”の口座(利用者“お母さん”の口座)に、50万円以上が入金された場合(条件1を満たす場合)、「出金口座」から紐付けられる口座番号“00000002”の口座から、「入金口座」から紐付けられる口座番号“00000001”の口座(利用者“お父さん”の口座)に3万円の振替処理を実行することを示している。また、
図6の1レコード目は、当該振替処理の実行結果を、「レポート先1」および「レポート先2」が示すレポート先(この場合、利用者“お父さん”および“お母さん”のレポート先)に対してレポートとして送信することも示している。なお、さらにレポート先を追加する場合は、条件データ(
図6)に「レポート先3」、「レポート先4」・・・などのデータ項目を追加し、任意にレポート先を追加することができる。
【0036】
図6の2レコード目は、条件1および条件2が設定されており、「対象口座1」から紐付けられる口座番号“11111111”の口座(利用者“太郎”の口座)の残高が、許可された利用者によって照会され(“残高”を“手動”で照会)、預金額が5万円以下であった場合(条件1を満たす場合)、さらに条件2の判定を実行することを示している。さらに、条件2の判定において、「対象口座2」から紐付けられる口座番号“00000002”の口座の残高が1万円以上であった場合(条件2も満たす場合)、対応するアクションを実行することを示している。
【0037】
図6の3レコード目は、例えば、バッチ処理で定期的に毎月25日に、「対象口座1」から紐付けられる口座番号“00000002”の口座の残高が照会され、残高が15万円以上ある場合に、対応するアクションを実行することを示している。同様に、
図6の4レコード目は、バッチ処理で定期的に毎週月曜日に、「対象口座1」から紐付けられる口座番号“00000002”の口座の残高が照会され、残高が10万円以下であった場合に、「レポート先1」が示す利用者“お母さん”のレポート先に、残高が閾値以下になった旨を示すアラーム用のレポートを送信することを示している。
【0038】
図6の5レコード目は、例えば、バッチ処理により、指定日である“2016/12/20”が到来した際に、対応するアクションを実行することを示している。
図6の6レコード目は、「対象口座1」から紐付けられる口座番号“22222222”の口座から出金された結果、残高が5千円以下になってしまい(条件1を満たす場合)、さらに「対象口座2」から紐付けられる口座番号“00000002”の口座の残高が10万円以上の場合(条件2も満たす場合)、対応するアクションを実行することを示している。
【0039】
図6の7レコード目は、「対象口座1」から紐付けられる口座番号“22222222”から、「対象口座2」から紐付けられる口座番号“00000002”に対して“任意”の金額を移動するための承認依頼を実行し、承認が得られた場合に、対応するアクションを実行することを示している。例えば、口座番号“22222222”の利用者である“次郎”が本システムを介して“任意”の金額を指定し、口座番号“00000002”の利用者である“お母さん”に対して承認依頼を行なうと、“お母さん”のレポート先に対してその旨が通知され、“お母さん”が承認結果を送信する(例えば、承認依頼メール上の承認用のリンクをクリックし、本システムにログインして「承認」ボタンを押下する)。承認依頼が承認された場合は、「条件金額1a」に設定された金額を「実行金額」として、口座番号“00000002”の口座から、口座番号“22222222”の口座に対する振込処理を実行し、レポート先に対し、その旨を通知する。なお、承認依頼を否認した場合は、承認依頼者である“次郎”のレポート先に対し、その旨を通知することもできる。
【0040】
図1のレポートデータ記憶部133は、設定された条件を満たした場合のアクション実行時などに通知されるレポートに関するデータを格納する。
図7は、本発明の一実施形態に係るレポートデータ記憶部133に格納されたデータを示す図である。
【0041】
図7におけるレポートデータには、利用者に対するレポートの通知先を示す「レポート先」、およびレポートの内容を示す「レポート内容」などを格納することができる。
【0042】
次に、
図2のフローチャート、および
図4−7のデータを参照して、本発明の一実施形態に係る資金移動処理を流れに沿って説明する。
図2は、本発明の一実施形態に係る口座アクセスをトリガとする資金移動処理を示すフロー図である。本処理は、本システムが、利用者aの口座(口座A)データに対する何らかのアクセス(入金、出金、残高照会など)を確認することをトリガとして、口座Aに対して設定された条件および関連する条件を満たす場合に、対応するアクション(資金移動など)を実行するものである。
【0043】
まず、トリガ条件監視手段120は、各口座に対するアクセスを監視しており、口座Aに対して何らかのアクセスがあったことを確認する(ステップ201)。
【0044】
次に、トリガ条件監視手段120は、口座Aに対する条件を検索する(ステップ202)。具体的には、口座Aの「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」を検索キーとして利用者データ(
図4)における口座Aの利用者aの「利用者ID」を抽出する。その後、口座Aに対するアクセス内容と抽出した「利用者ID」とに基づいて、条件データ(
図6)の「トリガ条件1a」、「トリガ条件1b」、および「対象口座1」を検索し(すなわち、条件1)、設定された条件の有無を確認する。口座Aに対して設定された条件が無い場合は、ステップ203のNoルートに進み、本処理は終了する。
【0045】
一方、口座Aに対して設定された条件がある場合、ステップ203のYesルートに進み、トリガ条件監視手段120は、その条件を満たすか否かを判定する(ステップ204)。具体的には、ステップ202で検索した条件データの「トリガ条件1a」、「トリガ条件1b」、「条件金額1a」、および「条件金額1b」に設定された条件を満たすか否かを判定する。例えば、口座Aに対するアクセス内容が入金または出金である場合は、入金額または出金額が「条件金額1a」および「条件金額1b」に設定された金額条件を満たすか否かを判定する。または、口座Aに対するアクセス内容が残高照会である場合は、口座Aの口座番号を検索キーとして、口座データ(
図5)を検索し、口座データにおける「預金額」が「条件金額1a」および「条件金額1b」に設定された金額条件を満たすか否かを判定する。
【0046】
ステップ204において、口座Aに対して設定された条件を満たさないと判定された場合、Noルートに進み、本処理は終了する。一方、口座Aに対して設定された条件を満たすと判定された場合、Yesルートに進み、トリガ条件監視手段120は、関連する他の条件を検索する(ステップ205)。関連する他の条件とは、ステップ202で検索された条件1に関連する条件2以降の条件である。具体的には、ステップ202で検索した条件データ(
図6)の「トリガ条件2a」、「トリガ条件2b」、および「対象口座2」を検索し(すなわち、条件2である。条件3以降については後述する)、設定された条件の有無を確認する。
【0047】
ステップ206において、関連する他の条件がある場合、Yesルートに進み、その条件を満たすか否かを判定する(ステップ207)。具体的には、条件データ(
図6)の「対象口座2」から紐付けられる口座に対して、「トリガ条件2a」、「トリガ条件2b」、「条件金額2a」、および「条件金額2b」に設定された条件を満たすか否かを判定する。例えば、「トリガ条件2a」および「トリガ条件2b」によって示される条件が残高照会である場合、「対象口座2」から紐付けられる口座番号を検索キーとして、口座データ(
図5)を検索し、口座データにおける「預金額」が「条件金額2a」および「条件金額2b」に設定された金額条件を満たすか否かを判定する。
【0048】
ステップ207において、関連する条件を満たさないと判定された場合、Noルートに進み、本処理は終了する。一方、関連する条件を満たすと判定された場合、Yesルートに進み、さらに関連する他の条件(すなわち、条件3以降)があるか否かを判定し(ステップ205)、関連する他の条件が存在する限り、ステップ205〜207を繰り返す。
【0049】
ステップ206において、関連する他の条件が無い、またはこれ以上関連する他の条件が無い場合、Noルートに進み、資金移動手段121および/またはレポート通知手段122は、対応するアクションを実行する(ステップ207)。具体的には、ステップ202で検索した条件データ(
図6)の「実行アクション」が示すアクションを実行する。例えば、「実行アクション」によって示されるアクションが“振替”または“振込”である場合、資金移動手段121は、条件データ(
図6)の「出金口座」から紐付けられる口座から「入金口座」から紐付けられる口座に、「実行金額」が示す金額を移動する。さらに、レポート通知手段122は、アクションの実行結果を示すレポートデータ(
図7)を作成し、レポートデータ記憶部133に格納する。そして、レポート通知手段122は、作成したレポートデータを、条件データ(
図6)の「レポート先1」および「レポート先2」が示す通知先に送信する。一方、「実行アクション」によって示されるアクションが“レポート”である場合は、例えば、「対象口座1」から紐付けられる口座の残高が「条件金額1a」および「条件金額1b」に設定された条件を満たす(例えば、設定金額以下)場合などが想定されるため、その旨を示すレポートデータ(
図7)を作成し、レポートデータ記憶部133に格納した上で、「レポート先1」および「レポート先2」が示す通知先に送信する。
【0050】
次に、
図3のフローチャート、および
図4−7のデータを参照して、
図2で説明した実施形態とは異なる実施形態に係る資金移動処理を流れに沿って説明する。
図3は、本発明の一実施形態に係る所定日時の到来をトリガとする資金移動処理を示すフロー図である。本処理は、本システムが、所定の日時の到来をトリガとして、関連する条件を満たす場合に、対応するアクション(資金移動など)を実行するものである。
【0051】
まず、トリガ条件監視手段120は、所定の日時が到来したか否かを判定する(ステップ301)。具体的には、定期的に(例えば、1時間に1回のバッチ処理により)条件データ(
図6)の「トリガ条件1a」が“指定日到来”を示すレコードの「トリガ条件1b」に設定された日時と、資金管理サーバ100のシステム日時とを比較し、トリガ条件の指定日が到来したか否かを判定する。また、「トリガ条件1b」が“定期(・・・)”を示すレコードも同様の判定を実行することができる。
【0052】
ステップ301にて、指定日が到来していないと判定された場合は、Noルートに進み、本処理は終了する。この場合、次のバッチ処理の起動を待ち(例えば、1時間後)、再度ステップ301を実行することになる。なお、
図6の条件データには様々な利用者の条件データが格納されているため、ステップ301の対象となるレコードが複数存在することが想定される。この場合、本処理は対象レコードの数だけ実行されることになる。
【0053】
一方、ステップ301にて、指定日が到来したと判定された場合は、Yesルートに進み、トリガ条件監視手段120は、関連する他の条件を検索する(ステップ302)。以降、ステップ302〜305は、
図2で説明した実施形態におけるステップ205〜208と同様の処理を実行する。
【0054】
以上により、コンピューティングシステムによって、利用者自身が資金移動の条件を自由に設定することができ、対象の口座に対するアクセスが、設定された条件を満たす場合に、設定されたアクションを実行することができる。また、当該システムは、アクションを実行した場合に関連する利用者にレポートを通知したり、利用者間および口座ごとのアクセス制御を行なったりすることにより、セキュリティ上の観点からも一定の安全性を確保することができる。
【課題】口座間の資金移動について、あらかじめ指定した日に、指定した出金口座から入金口座へ同じ金額を定期的に振込すること、特定の日に特定の出金口座から、事前に指定した複数の入金口座へ各々指定した金額を振込することなどはできるものの、利用者のマニュアル運用がほとんどである。また、複数人で口座を管理することもあるが、管理対象の口座が個人口座を含むこともあり、セキュリティ上の観点からも、その取扱いには十分な注意が必要である。
【解決手段】コンピューティングシステムによって、利用者自身が資金移動の条件を自由に設定することができ、対象の口座に対するアクセスが、設定された条件を満たす場合に、設定されたアクションを実行することができる。また、当該システムは、利用者間および口座ごとのアクセス制御を行なったりすることなどにより一定の安全性を確保することができる。