(57)【要約】      （修正有）【課題】銀行システムの業務を代行する代行システムにおいて、より精度の高い利用者の口座残高の情報を取得可能にする。【解決手段】口座を識別する口座情報と、取引の金額である取引金額とを含む取引情報を取得する取得部と、銀行システムから、銀行システムが取引情報に基づいて口座の残高を管理する処理を停止する前に、口座の残高を示す残高情報を取得して、第１金額として口座情報と対応付けて記憶部に格納する第１格納部と、残高情報を取得したあと、銀行システムが処理を停止する前に、取引情報が取得されると、当該取引情報に含まれる取引金額を第２金額として、口座情報と対応付けて記憶部に格納する第２格納部と、銀行システムが処理を停止している間に、取引情報が取得されると、当該取引情報に含まれる取引金額と、第１金額から第２金額を減じた金額とに基づいて、当該取引情報に関する取引を承認するかどうかを判定する判定部と、を備える。【選択図】図７
2019175134.tif 000002
【特許請求の範囲】
【請求項１】
銀行システムにおいて管理されている口座の残高の少なくとも一部を利用する取引が行われる際に、前記口座を識別する口座情報と、前記取引の金額である取引金額とを含む取引情報を取得する取得部と、
前記銀行システムから、前記銀行システムが前記取引情報に基づいて前記口座の残高を管理する処理を停止する前に、前記口座の残高を示す残高情報を取得して、第１金額として前記口座情報と対応付けて記憶部に格納する第１格納部と、
前記残高情報を取得したあと、前記銀行システムが前記処理を停止する前に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額を第２金額として、前記口座情報と対応付けて前記記憶部に格納する第２格納部と、
前記銀行システムが前記処理を停止している間に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額と、前記第１金額から前記第２金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定する判定部と、を備える代行システム。
【請求項２】
前記判定部は、
前記取引を承認する場合に、前記銀行システムが前記処理を停止している間に取得された前記取引情報に含まれる前記取引金額を、第３金額として前記口座情報と対応付けて前記記憶部に格納する、
請求項１に記載の代行システム。
【請求項３】
前記銀行システムが前記処理を停止している間に、前記銀行システムから前記口座の残高情報を取得した場合に、
前記第１格納部は、
当該残高情報に基づいて、当該口座の前記口座情報に対応する前記第１金額を更新し、
前記判定部は、
前記取引を承認するかどうかの判定に、前記第１金額及び第３金額を用いる、
請求項２に記載の代行システム。
【請求項４】
前記判定部は、
前記銀行システムが前記処理を停止している間に、前記取引情報がさらに取得された場合に、当該取引情報に含まれる前記取引金額と、前記第１金額から、前記第３金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定し、当該取引情報に含まれる前記取引金額を前記第３金額に加算する、
請求項３に記載の代行システム。
【請求項５】
前記銀行システムがオンライン処理を停止していた期間における、前記第３金額の累積額を、前記銀行システムが前記オンライン処理を開始する際に当該銀行システムに提供する提供部、
をさらに備える請求項２又は３に記載の代行システム。
【請求項６】
コンピュータが、
銀行システムにおいて管理されている口座の残高の少なくとも一部を利用する取引が行われる際に、前記口座を識別する口座情報と、前記取引の金額である取引金額とを含む取引情報を取得するステップと、
前記銀行システムから、前記銀行システムが前記取引情報に基づいて前記口座の残高を管理する処理を停止する前に、前記口座の残高を示す残高情報を取得して、第１金額として前記口座情報と対応付けて記憶部に格納するステップと、
前記残高情報を取得したあと、前記銀行システムが前記処理を停止する前に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額を第２金額として、前記口座情報と対応付けて前記記憶部に格納するステップと、
前記銀行システムが前記処理を停止している間に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額と、前記第１金額から前記第２金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定するステップと、
を実行する代行方法。
【請求項７】
コンピュータを、
銀行システムにおいて管理されている口座の残高の少なくとも一部を利用する取引が行われる際に、前記口座を識別する口座情報と、前記取引の金額である取引金額とを含む取引情報を取得する手段、
前記銀行システムから、前記銀行システムが前記取引情報に基づいて前記口座の残高を管理する処理を停止する前に、前記口座の残高を示す残高情報を取得して、第１金額として前記口座情報と対応付けて記憶部に格納する手段、
前記残高情報を取得したあと、前記銀行システムが前記処理を停止する前に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額を第２金額として、前記口座情報と対応付けて前記記憶部に格納する手段、及び
前記銀行システムが前記処理を停止している間に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額と、前記第１金額から前記第２金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定する手段、
として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、代行システム、代行方法、及びそのプログラム等に関する。
【背景技術】
【０００２】
銀行システムの多くは、バッチ処理等のために非稼働の時間帯がある。銀行システムの非稼働時には、通常、利用者は自身の口座から残高を引き落としたり、振込処理を行ったりすることができなくなる。この不都合を解消するために、銀行システムの非稼働時に、銀行システムの代行を行う技術がある（例えば特許文献１等）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２４３４００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
銀行システムの代行を行う場合、利用者の口座残高を超える取引を防ぐために、銀行システムからの切り替え時の利用者の口座の残高が必要になる。銀行システムは例えば数千万程度の多数の口座を管理しているため、利用者の口座残高の情報の取得には多くの時間を要する。そのため、口座残高の情報の取得は、代行開始のタイミングより所定時間前に実行される。これにより、口座残高の情報が取得されてから代行開始までの間に時間的なズレが生じる。この時間的なズレの間に、口座引落等によって残高が変更されると、代行システムでは、利用者の正確な残高を知ることができない。
【０００５】
そこで、本発明は、上記事情に鑑み、銀行システムの業務を代行する代行システムにおいて、より精度の高い利用者の口座残高の情報を取得可能な技術を提供することを目的とするものである。
【課題を解決するための手段】
【０００６】
本発明による代行システムは、銀行システムにおいて管理されている口座の残高の少なくとも一部を利用する取引が行われる際に、口座を識別する口座情報と、取引の金額である取引金額とを含む取引情報を取得する取得部と、銀行システムから、銀行システムが取引情報に基づいて口座の残高を管理する処理を停止する前に、口座の残高を示す残高情報を取得して、第１金額として口座情報と対応付けて記憶部に格納する第１格納部と、残高情報を取得したあと、銀行システムが処理を停止する前に、取引情報が取得されると、当該取引情報に含まれる取引金額を第２金額として、口座情報と対応付けて記憶部に格納する第２格納部と、銀行システムが処理を停止している間に、取引情報が取得されると、当該取引情報に含まれる取引金額と、第１金額から第２金額を減じた金額とに基づいて、当該取引情報に関する取引を承認するかどうかを判定する判定部と、を備える。
【０００７】
本発明のプログラムは、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。
【０００８】
また、本明細書等において、「部」とは、単に物理的構成を意味するものではなく、その構成が有する機能をソフトウェアによって実現する場合も含む。また、１つの構成が有する機能が２つ以上の物理的構成により実現されても、２つ以上の構成の機能が１つの物理的構成により実現されてもよい。
【発明の効果】
【０００９】
本発明によれば、銀行システムの業務を代行する代行システムにおいて、より精度の高い利用者の口座残高の情報を取得可能な技術を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態における代行システムを含むシステムの構成図である。
【図２】本発明の実施形態における銀行システムの機能ブロックの一例を示す図である。
【図３】本発明の実施形態における残高管理テーブルの一例を示す図である。
【図４】本発明の実施形態におけるシステムの稼働状態と切替指示との関係を示す模式図である。
【図５】本発明の実施形態における代行システムの機能ブロックの一例を示す図である。
【図６】本発明の実施形態における代行用テーブルの一例を示す図である。
【図７】本発明の実施形態における代行システムの処理フローの一例を示すフローチャートである。
【図８】本発明の実施形態におけるシステムのシーケンス図の一例を示す図である。
【図９】本発明の実施形態におけるシステムのシーケンス図の一例を示す図である。
【図１０】本発明の実施形態におけるシステムのシーケンス図の一例を示す図である。
【図１１】本発明の実施形態におけるシステムのシーケンス図の一例を示す図である。
【図１２】本発明の実施形態におけるシステムのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１１】
［第１実施形態］
以下、本発明の実施の形態の１つについて詳細に説明する。なお、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。
【００１２】
＜１．システム構成の概要＞
図１は、本実施形態に係るシステム１の構成の一例を示している。図１に示すように、システム１は、インターネットや専用線等のネットワークＮを介して、代行システム１０と、銀行システム２０と、端末３０とが互いに接続されて構成されている。
【００１３】
ネットワークＮは、無線ネットワークや有線ネットワークにより構成される。ネットワークの一例としては、携帯電話網や、ＰＨＳ（Ｐｅｒｓｏｎａｌ  Ｈａｎｄｙ−ｐｈｏｎｅ  Ｓｙｓｔｅｍ）網、無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）、４Ｇ（４ｔｈ  Ｇｅｎｅｒａｔｉｏｎ）、ＷｉＭａｘ（登録商標）、赤外線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、有線ＬＡＮ、電話線、電灯線ネットワーク、ＩＥＥＥ１３９４等に準拠したネットワークがある。
【００１４】
銀行システム２０は、銀行が所有するシステムであり、利用者の口座情報が管理されている。本実施形態では、銀行システム２０は、バッチ処理を行うため、銀行の閉局時間はオンライン処理が停止した状態（以下、「オンライン処理停止状態」ともいう。）となる。ただし、銀行システム２０のオンライン処理停止状態の期間は銀行の閉局時間に限定されず、任意の期間でよい。
【００１５】
代行システム１０は、銀行システム２０がオンライン処理停止状態の場合に、銀行業務における残高管理業務の代行を行う。本実施形態では、一例として、代行システム１０は、デビット利用による口座引き落とし処理が行われた場合に、残高管理業務の代行を行う。しかし、代行システム１０で代行する業務はこれに限定されず、例えば、代行システム１０は、銀行システム２０のオンライン処理停止状態中にＡＴＭ装置やネットバンキング等を利用した口座引き落とし処理や口座振替処理、入金処理等が行われた際に、残高管理業務を代行してもよい。
【００１６】
端末３０は、例えば小売店等に設置される装置である。端末３０は、銀行システム２０と通信を行い、デビット決済を行う機能を有している。なお、端末３０は小売店に設置される装置に限定されず、ＡＴＭ装置の他、インターネットショッピング等の非対面販売やネットバンキングに用いられるユーザ端末を含む。また、端末３０が有する機能は、デビット決済機能に限定されず、クレジット決済機能でもよいし、さらに銀行システム２０が管理している口座からの引き落とし処理や口座振替処理を行う機能を有していてもよい。
【００１７】
＜２．詳細構成＞
＜２−１．端末３０＞
端末３０は、ネットワークＮに接続されたコンピュータである。具体的には、端末３０は、例えば携帯電話やスマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ）、タブレット、ウェアラブル（Ｗｅａｒａｂｌｅ）端末等によって実現される。
【００１８】
端末３０は、小売店が実店舗を有する場合、ユーザがデビット決済を利用した取引に用いたカードに記録された情報をスキャンする機能、及びスキャンされた情報に基づいて、銀行システム２０に取引情報を送信する機能を有する。取引情報は、例えば、利用者の口座を識別する口座情報と、取引の金額である取引金額（以下、「利用金額」ともいう。）とを含む。口座情報は、利用者がデビット決済に利用する口座を特定可能な情報であり、本実施形態ではユーザが利用した口座の識別子（カードＩＤ）であるが、これに限定されず、ユーザが利用したカードの識別子等でもよい。なお、取引情報はその他、取引日時や取引が行われた小売店の情報、取引の種別等を含んでもよい。取引の種別は、取引情報を受信した銀行システム２０が行う処理を特定する情報である。例えば取引の種別は、取引情報に含まれる口座情報に対応する口座からの引き落とし処理が必要な取引や、取引情報に含まれる口座情報に対応する口座への入金が必要な取引、取引情報に含まれる口座情報に対応する口座から他の口座への送金が必要な取引（この場合、取引情報は、送金先の口座を特定する情報を有することが好ましい。）か、等を示すことができる。また例えば取引の種別は、決済手段（例えばデビット決済かクレジット決済か）を示す情報でもよい。
なお、小売店がインターネットや電話等による通信販売を営むものである場合、端末３０は、カードに記録された情報をスキャンする機能を省略することができる。
【００１９】
＜２−２．銀行システム２０の機能＞
銀行システム２０は、インターネットや専用線等のネットワークＮに接続されたＰＣやサーバ装置等によって実現される。銀行システム２０は、端末３０から送信された取引情報に応じて、当該取引情報に含まれる利用金額を、口座情報に対応する口座から引き落とす機能や、口座情報に対応する口座の残高を管理する機能等を有している。なお、銀行システム２０は、端末３０から送信された取引情報を代行システム１０を介して取得する。
【００２０】
図２を参照して、本実施形態に係る銀行システム２０の機能構成について説明する。図２は、銀行システム２０の機能ブロック図の一例を示す図である。銀行システム２０は、契約者情報ＤＢ２３１と、残高管理テーブル２３２と、残高管理部２００と、代行データ生成部２０１と、切替指示部２０２と、代行反映部２０３と、を有している。なお、代行データ生成部２０１と、切替指示部２０２と、代行反映部２０３は、銀行システム２０とは別システムとして構成されてもよい
【００２１】
契約者情報ＤＢ２３１には、銀行システム２０が管理する口座（以下、銀行システム２０が管理する口座を「契約口座」ともいう。）を有しているユーザの識別子と、当該ユーザの利用する契約口座の識別子（以下「契約口座ＩＤ」ともいう。）とが対応付けられている。さらに契約者情報ＤＢ２３１には、ユーザの契約口座からデビット決済可能なカードのＩＤが対応付けられてもよい。なお、ユーザが複数の契約口座を有している場合には、ユーザＩＤに複数の契約口座ＩＤが対応付けられる。
【００２２】
残高管理テーブル２３２には、銀行システム２０が管理する契約口座について、契約口座ＩＤと、当該契約口座の現在の残高（以下「残高情報」ともいう。）とが対応付けられて管理されている（図３参照）。さらに、残高管理テーブル２３２の各レコードには、最終更新日時、又は更新フラグが対応付けられていることが好ましい。更新フラグは、代行データ生成部２０１が後述する代行条件データを生成したあとに、更新が行われたレコードを示すフラグである。なお、残高管理テーブル２３２は、図３の例に限定されず、残高情報の更新履歴（例えば更新ログ等である。）と、更新日時とをさらに含む構成でもよい。
【００２３】
残高管理部２００は、代行システム１０から送信される取引情報に基づいて、契約口座の残高情報を管理する。具体的には、残高管理部２００は、取引情報を参照し、契約口座ＩＤを特定する。次に、残高管理部２００は、残高管理テーブル２３２を参照し、特定した契約口座ＩＤのレコードにおいて、取引情報に含まれる利用金額が残高を上回っているか否か、すなわち引落の可否を判定し、引落可能な場合には、残高から利用金額を、減算する。残高管理部２００は、後述する代行データ生成部２０１が全件データを生成したあと、かつ、代行中（後述する代行状態及び第２切替状態の期間である。）の取引情報の反映が完了するまでは、残高管理テーブル２３２において残高情報を更新した際には、該当するレコードにおいて更新フラグを立てることが好ましい。なお、利用金額が残高を上回った場合には、残高管理部２００は減算処理を行わなくてもよい。
【００２４】
さらに、残高管理部２００は、取引情報に含まれる利用金額が、対応する契約口座の残高を上回っていたか否かの結果（以下「引落結果」ともいう。）を代行システム１０に通知をすることが好ましい。
【００２５】
なお、残高管理部２００は、取引情報だけでなく、本実施形態に係るシステム１が管理していない取引（以下「システム外取引」ともいう。）に関する情報に基づいても、契約口座の残高情報を管理することが好ましい。システム外取引は、例えば、ＡＴＭやネットバンキングを利用した契約口座からの引き落とし処理や口座振替処理等である。なお、システム外取引には、代行システム１０が管理しないデビット決済を用いた取引や、クレジット決済を用いた取引を含んでもよい。さらにシステム外取引は、夜間のバッチ処理等により行われる口座振替処理等を含んでもよい。
【００２６】
代行データ生成部２０１は、代行システム１０が銀行システム２０の口座管理業務を代行するにあたり、必要な代行データを生成して、代行システム１０と共有する。共有する方法は、代行データ生成部２０１が代行データを代行システム１０に送信する形式（プッシュ形式）でもよいし、代行システム１０が生成された代行データを取得する形式（プル形式）でもよい。
【００２７】
代行データ生成部２０１が生成する代行データは、全件データと差分データの２種類である。代行データ生成部２０１は、システムの稼働状態が後述する通常状態から第１切替
状態に切り替わる前（図４参照）に、全件データを生成する。代行データ生成部２０１は、通常状態において、例えば所定の時刻となった際に全件データを生成してもよい。全件データは、銀行システム２０が管理する契約口座の全件について、システムの稼働状態が通常状態に切り替わったときから、全件データが生成される時刻における、少なくとも最新の残高情報を含む。なお、全件データは、残高情報のすべての履歴でもよい。さらに、代行データは、契約口座の残高情報の他にも、ユーザや契約口座ごとに他の条件（又は設定）を含んでもよい。他の条件は、例えば、１回及び／又は１日当たりの取引金額の合計値の上限等である。
【００２８】
差分データは、前回差分データ（又は全件データ）を作成した時刻から、今回差分データを作成する時刻までの間に、残高情報が更新された契約口座についての最新の残高情報を含む情報である。代行データ生成部２０１は、例えば所定の時刻となった際、あるいは前回差分データ又は全件データを生成してから所定の時間を経過した際に、今回の差分データを生成する。このとき、代行データ生成部２０１は、残高管理テーブル２３２を参照して、更新フラグが立っているレコードに基づいて、差分データを生成することができる。なお、代行データ生成部２０１は、差分データを生成すると、残高管理テーブル２３２における更新フラグをクリアすることが好ましい。
【００２９】
切替指示部２０２は、代行システム１０に対して、稼働状態の切り替え指示を通知する。切替指示部２０２は、例えば、代行準備指示と、代行開始指示と、代行解除指示との３種類の指示を代行システム１０に通知することができる。以下の説明では、代行準備指示と、代行開始指示と、代行解除指示とをまとめて切替指示ともいう。代行システム１０では、受信した切替指示に応じて、実行する処理を切り替えることが好ましい。
【００３０】
図４を参照して、本実施形態に係るシステム１の稼働状態と切替指示との関係について説明する。システム１は、通常状態、第１切替状態、代行状態、第２切替状態の４つの稼働状態を有している。なお、以下の説明では、システム１の稼働状態が切り替わるタイミングは、代行システム１０が切替指示を受信したときとして説明するが、これに限定されない。稼働状態が切り替わるタイミングは、所定の時刻が到来したときや、代行システム１０が切替指示を受信したときから所定の時間が経過したときでもよい。また、以下の説明では、システム１が代行状態及び第２切替状態の期間を、代行システム１０の代行中、ともいう。
【００３１】
通常状態は、代行システム１０から銀行システム２０に対する代行中（すなわち、システム１が代行状態及び第２切替状態の期間である）の取引情報の提供が完了したときに開始し、代行準備指示を受信したときに終了する。通常状態では、銀行システム２０が通常稼働しており（すなわち、オンライン処理を行っており）、代行システム１０から送信される取引情報に基づいて、少なくとも銀行システム２０が契約口座の残高情報を更新する。なお、通常状態は、所定の時刻が到来したとき（例えば銀行の開局時刻）に開始する構成でもよい。
【００３２】
第１切替状態は、代行システム１０が代行準備指示を受信したときに開始し、代行開始指示を受信したときに終了する。第１切替状態では、銀行システム２０は通常稼働しており、端末３０から送信される取引情報に基づいて、銀行システム２０及び代行システム１０の両方が、契約口座の残高情報を管理する。より詳細には、銀行システム２０は、代行システム１０によって中継された端末３０から送信される取引情報に基づいて残高情報の管理を行う。なお、第１切替状態の開始時は、例えば、銀行システム２０が業務を停止する時刻から所定の時間前である。また、銀行システム２０のオンライン処理停止状態は、完全にシステムが停止する状態だけでなく、システム外取引に基づく契約口座の残高更新ついては管理を行う状態を含んでもよい。なお、第１切替状態は、所定の時刻が到来したときに開始する構成でもよい。
【００３３】
代行状態は、代行システム１０が代行開始指示を受信したときに開始し、代行解除指示を受信したときに終了する。代行状態では、銀行システム２０は業務を停止しており、端末３０から送信される取引情報に基づいて、少なくとも代行システム１０が、契約口座の残高情報を管理する。なお、代行状態であってもシステム外取引については、銀行システム２０が契約口座の残高情報を管理する構成でもよい。また、代行状態は、所定の時刻（例えば銀行の閉局時刻）が到来したときや、第１切替状態において代行システム１０が受信した差分データの後述する代行管理テーブルへの反映が完了したときに開始する構成でもよい。
【００３４】
第２切替状態は、代行システム１０が代行解除指示を受信したときに開始し、代行システム１０から銀行システム２０に代行中の取引情報の提供が完了した場合に終了する。第２切替状態では、銀行システム２０は稼働準備中であり、端末３０から送信される取引情報に基づいて、少なくとも代行システム１０が、契約口座の残高情報を管理する。なお、代行状態及び第２切替状態であってもシステム外取引については、銀行システム２０が契約口座の残高情報を管理する構成でもよいまた、第２切替状態は、所定の時刻が到来したときに開始する構成でもよい。
【００３５】
次に、切替指示部２０２が、切替指示を代行システム１０に通知するタイミングについて説明する。まず、代行準備指示について、切替指示部２０２は、例えば、代行データ生成部２０１が全件データを生成したあと、最初の差分データの生成を開始した際に、通知してもよい。なお、これに限定されず、代行データ生成部２０１が差分データの生成を開始してから所定の時間を経過したときや、所定の時刻が到来したときに通知する構成でもよい。
【００３６】
代行開始指示について、切替指示部２０２は、銀行システム２０を管理する銀行が閉局するときや、銀行システム２０が業務を停止したとき、差分データを代行システム１０に送信したとき等に、代行システム１０に通知する構成でもよい。
【００３７】
代行解除指示について、切替指示部２０２は、例えば、銀行システム２０を管理する銀行の開局時刻より所定の時間前に、代行システム１０に通知する。
【００３８】
代行反映部２０３は、代行システム１０が代行状態及び第２切替状態において取得した取引情報に基づいて、契約口座の残高情報を更新する代行結果反映処理を実行する。
【００３９】
＜２−３．代行システム１０＞
代行システム１０は、上述のネットワークＮに接続されたＰＣやサーバ装置等によって実現される。代行システム１０は、銀行システム２０がオンライ処理停止状態の際に、銀行システム２０において管理される契約口座の残高管理業務を代行する。さらに代行システム１０は、端末３０から取引情報を受信した場合に、端末３０が読み取ったカードが利用可能であるか否かの審査を行う機能等を有してもよい。
【００４０】
図５を参照して、本実施形態に係る代行システム１０の機能構成について説明する。図５は、代行システム１０の機能ブロック図の一例を示す図である。代行システム１０は、審査部１００と、取引代行部１０１と、ユーザ情報ＤＢ１３１と、代行用テーブル１３２とを備えている。
【００４１】
ユーザ情報ＤＢ１３１は、上述した契約者情報ＤＢ２３１と同様の構成を有している。
【００４２】
図６は代行用テーブル１３２の一例を示す図である。代行用テーブル１３２には、契約口座ＩＤごとに、準備中累積金額（第２金額の一例である。）と、代行中累積金額（第３金額の一例である。）と、代行条件金額（第１金額の一例である。）との各値を格納する領域が対応付けられて記憶されている。
【００４３】
準備中累積金額は、代行システム１０が代行準備指示を受信したあと、代行開始指示を受信するまでの間（すなわち第１切替状態時）に、受信した取引情報に含まれる利用金額の累積額である。
【００４４】
代行中累積金額は、代行システム１０が代行開始指示を受信したあと、代行中の取引情報の反映が完了するまでの間（すなわち代行状態時、及び第２切替状態時）に、受信した取引情報に含まれる利用金額の累積額である。なお、代行中累積金額には、累積額と併せて、代行状態時及び第２切替状態時において代行システム１０が受信した取引情報が紐づけられていることが好ましい。もっとも、代行状態時及び第２切替状態時において代行システム１０が受信した取引情報は、対応する契約口座のＩＤに紐づけられて記憶されていればよく、代行中累積金額に紐づいている構成に限定されない。
【００４５】
代行条件金額は、代行開始指示を受信したあと、代行中の取引情報の反映が完了するまでの間（すなわち代行状態時、及び第２切替状態時）に、代行システム１０が利用可能金額の判定に用いる上限値である。
【００４６】
取引代行部（取得部、第１格納部、及び第２格納部の一例である。）１０１は、端末３０から銀行システム２０に送信される取引情報、及び銀行システム２０から取得した代行データ（差分データ・全件データ）に基づいて、代行用テーブル１３２を用いて契約口座の残高情報を管理する。
【００４７】
取引代行部１０１は、代行データを取得した際には、当該代行データに基づいて、代行用テーブル１３２における対応するレコードの代行条件金額の値を更新する。また、取引代行部１０１は、取引情報を取得した際には、当該取引情報に含まれる利用金額に基づいて、代行用テーブル１３２における対応するレコードの準備中累積金額の値、又は代行中累積金額の値を更新する。例えば取引代行部１０１は、システム１の稼働状態が、第１切替状態の場合には、準備中累積金額の値を更新し、代行状態又は第２切替状態の場合には、代行中累積金額の値を更新する。
【００４８】
審査部１０２（判定部の一例である。）は、端末３０から取引情報を受信すると、当該取引情報に対応する取引について、承認すべきか否かを判定する。例えば、審査部１０２は、通常状態、及び第１切替状態においては、銀行システム２０から通知される引落結果に基づいて、承認すべきか否かを判定することができる。
【００４９】
他方、審査部１０２は、代行状態、及び第２切替状態において、取引情報を受信した場合には、代行条件金額と、準備中累積金額とに基づいて、取引情報の承認の可否を判定することができる。具体的には、取引代行部１０１は、取引情報に含まれる利用金額が利用可能な限度額を超えていないか否かを以下の式（１）を用いて判定し、超えていない場合には、取引情報を承認することができる。
＜利用可能条件＞
加算後の代行中累積金額≦代行条件金額−準備中累積金額  ・・・式（１）
【００５０】
なお、審査部１０２は、代行状態において、最初に銀行システム２０から代行データ（すなわち差分データ）を受信したあとは、代行状態及び第２切替状態において代行中累積金額と代行条件金額とに基づいて、取引情報の承認の可否を判定することも可能である。
【００５１】
なお、代行データが残高情報以外の条件や設定を含む場合には、審査部１０２は、残高情報以外の条件や設定に基づいて取引情報の承認の可否を判定してもよい。例えば、代行データにある契約口座について、１回当たりの利用金額の合計値の上限が含まれる場合には、取引代行部１０１は、取引情報に含まれる利用金額が代行データに含まれる上限金額を超えていないか否かを判定することが好ましい。さらに、審査部１０２は、予め作成された不正検知ルールに基づいて、取引の承認の可否を判定してもよい。不正検知ルールは、例えば、契約者が過去一定期間カードを利用していた地域から、「遠隔した地域において、高額の利用が相次いだ場合」や、「換金性が高く、かつ高額の商品ばかりの利用が続いた場合」等が挙げられる。
【００５２】
審査部１０２は、承認するか否かを判定した結果を端末３０に送信する。端末３０では、取引を承認する旨の結果が代行システム１０から送信された場合に、取引を成立させることができる。
【００５３】
図７を参照して、取引代行部１０１の処理についてより詳細に説明する。図７は取引代行部１０１の処理フローの一例を示すフローチャートである。
【００５４】
まず、システム１の稼働状態が通常状態、すなわち、前回の代行中の取引情報提供の完了後、かつ代行準備指示受信前（Ｓ１１：ＮＯ）において、取引代行部１０１は、銀行システム２０において生成された代行条件の全件データを受信する（Ｓ１１：ＹＥＳ）と、代行用テーブルを参照して、各レコードの代行条件金額の値に対応する契約口座ＩＤの残高情報をセットする（Ｓ１２）。
【００５５】
次に、代行準備指示の受信後（Ｓ１３：ＹＥＳ）、かつ代行開始指示の受信前（Ｓ１６：ＮＯ）は、システム１の稼働状態は、代行システム１０が代行業務を準備する、第１切替状態である。このとき、端末３０から取引情報が送信された場合（Ｓ１４：ＹＥＳ）、代行システム１０においても契約口座の残高情報の管理を行う。具体的には、取引代行部１０１は、代行用テーブル１３２を参照して、取引情報に含まれる契約口座ＩＤに対応するレコードにおいて、準備中累積金額の値に取引情報に含まれる利用金額を加算する（Ｓ１５）。代行システム１０は、Ｓ１４，Ｓ１５の処理を代行開始指示を受信する（Ｓ１６）まで繰り返し実行する。
【００５６】
代行開始指示の受信後（Ｓ１６：ＹＥＳ）、かつ代行解除指示の受信前（Ｓ２５：ＮＯ）は、システム１の稼働状態は、代行システム１０が代行業務を実行する、代行状態である。このとき、端末３０から取引情報が送信された場合（Ｓ２１：ＹＥＳ）、銀行システム２０に代わり、代行システム１０において契約口座の残高情報の管理を行う。具体的には、取引代行部１０１は、取引情報に含まれる契約口座ＩＤと利用金額を抽出し、代行用テーブル１３２における、取引情報に含まれる契約口座ＩＤに対応するレコードにおいて、代行中累積金額の値に利用金額を加算する（Ｓ２２）。このとき、審査部１０２は、加算後の代行中累積金額が以下の利用可能条件（上述の式（１）と同様である。）を満たすか否かを判定し、取引情報の承認の可否を判定することが好ましい。判定の結果、取引情報が否認される場合には、取引代行部１０１はＳ２２の処理を行わず、審査部１０２が端末３０に取引が否認された旨の通知を行うことが好ましい。
＜利用可能条件＞
加算後の代行中累積金額≦代行条件金額−準備中累積金額
【００５７】
取引代行部１０１は、代行状態において、最初に銀行システム２０から代行データ（すなわち差分データ）を受信したあとは、当該差分データに含まれる残高情報が示す金額に代行条件金額を更新し、準備中累積金額をゼロにする。なお、このとき、取引代行部１０１が準備中累積金額をゼロにする代わりに、審査部１０２が以降の利用可能条件の判定式に準備中累積金額を用いず、代行中累積金額が代行条件金額を上回っているか否かを判定するように切り替える構成でもよい。
【００５８】
代行状態において、システム外取引が発生した場合、取引代行部１０１は、銀行システム２０から更新後の残高の情報を含む差分データを取得して、代行用テーブル１３２における対応するレコードの代行条件金額の値を更新する（Ｓ２４）。
【００５９】
代行解除指示の受信後（Ｓ２５：ＹＥＳ）、かつ代行中の取引情報の提供が完了する前（Ｓ３４：ＮＯ）までは、システム１の稼働状態は、銀行システム２０が稼働の準備を行う第２切替状態である。第２切替状態が開始される（すなわち、代行解除指示を受信する）と、取引代行部１０１は、代行用テーブル１３２を参照し、各レコードの代行中累積金額に紐づけられた取引情報を銀行システム２０に提供する（Ｓ３１）。なお、銀行システム２０に提供を開始してから、代行中の取引情報の反映が完了するまでの間（Ｓ３４：ＮＯ）に、取引情報を再度受信した場合（Ｓ３２：ＹＥＳ）には、取引代行部１０１は、代行用テーブル１３２における、取引情報に含まれる契約口座ＩＤに対応するレコードにおいて、代行中累積金額の値に利用金額を加算する（Ｓ３３）。そして、Ｓ３２で受信した取引情報を銀行システム２０に提供する。
【００６０】
＜４．処理シーケンス＞
次に、図８乃至図１１を参照して、本実施形態に係るシステムの処理シーケンスについて説明する。なお、図８乃至図１１の例では、あるユーザＡの契約口座Ａの残高を管理する例について説明する。
【００６１】
図８は、システム１の稼働状態が通常状態の場合のシーケンス図である。図８のシーケンス開始時には、ユーザＡの口座残高は１０万円であるとする。例えばユーザＡがデビット決済により、契約口座Ａから１万円分の代金を利用したとする。システム１が通常状態の場合、取引が発生する（Ｓ１１１）と、端末３０から、代行システム１０に対して取引情報が送信される（Ｓ１１２）。このとき取引情報には、利用金額（１万円）と契約口座ＩＤ（契約口座ＡのＩＤ）が含まれている。なお、契約口座ＩＤの代わりに、デビット決済に用いたカードＩＤが含まれていてもよい。
【００６２】
銀行システム２０では、代行システム１０から転送された取引情報を受信すると、残高管理部２００が、残高管理テーブル２３２を参照し、取引情報に含まれる契約口座ＡのＩＤに対応するレコードを抽出する。なお、取引情報にカードＩＤが含まれる構成の場合には、残高管理部２００は、契約者情報ＤＢ２３１を参照してカードＩＤに対応する契約口座ＩＤを特定したのち、残高管理テーブル２３２を参照することが好ましい。なお、カードＩＤから契約口座ＩＤを特定する処理は代行システム１０で行ってもよい。
次に、残高管理部２００は、抽出したレコードにおける口座残高を今回の利用金額が上回っていないか、すなわち引落の可否を判定し、引落可能な場合には、現在の残高である１０万円から１万円を減算し、９万円にして更新する（Ｓ２１１）。残高管理部２００は引落結果を代行システム１０に通知する（Ｓ２１２）。代行システム１０では引落結果に基づいて、今回の取引情報を承認するか否かを判定し、承認結果を端末３０に通知する（Ｓ３１０）。
【００６３】
銀行システム２０がオンライン処理停止状態に切り替わるときから所定の時間前になると、代行データ生成部２０１は、代行データの全件データを生成する。この場合には、代行データ生成部２０１は、残高管理テーブル２３２を参照し、銀行システム２０において管理している全件分の契約口座のレコードについて、少なくとも現時点での最新の残高の情報に基づいて代行データを生成する（Ｓ２１３）。なお、システム１が通常状態の場合に生成される全件データは、銀行システム２０のすべての契約口座の更新履歴（ログ）を含んでもよい。代行データ生成部２０１は、生成した全件データを代行システム１０と共有する（Ｓ２１４）。なお、代行データ生成部２０１は、全件分の代行データを生成した際に、代行用テーブルにおける各レコードの更新フラグをクリアすることが好ましい。
【００６４】
代行システム１０では、全件データを取得すると、代行用テーブル１３２を参照して、対応する契約口座ＩＤのレコードにおける代行条件金額の値に、全件データに含まれる最新の残高情報をセットする（Ｓ３１１）。このとき、契約口座Ａのレコードにおいては、代行条件金額の値に９万円がセットされる。
【００６５】
全件分の代行データを代行システム１０と共有してから、再度、ユーザＡがデビット決済によって１万円分の代金を契約口座Ａから利用した場合（Ｓ１１３）、再度、端末３０は代行システム１０に取引情報を送信する（Ｓ１１４）。このとき代行システム１０から銀行システム２０に取引情報が転送されると、残高管理部２００によって、引落の可否が判定され、引落可能な場合には、残高管理テーブル２３２における契約口座Ａに対応するレコードにおいて、残高情報が、９万円から８万円に更新される（Ｓ２１５）。そして残高管理部２００から引落結果が通知される（Ｓ２１６）と、代行システム１０の審査部２０２において今回の取引情報の承認の可否が判定され、承認結果が端末３０に通知される（Ｓ３１２）。
【００６６】
銀行システム２０では、代行データの差分データ生成処理が行われる（Ｓ２２０）。代行データ生成部２０１が差分データを生成するタイミングは、例えば、前回、代行データを生成してから所定の期間が経過したときである。なお、代行データ生成部２０１が差分データを生成するタイミングは、これに限定されず、取引情報を受信したとき、または受信したときから所定の期間経過後でもよい。代行データ生成部２０１は、残高管理テーブル２３２を参照して、更新フラグが立っているレコードから残高情報を取得して差分データを生成することができる。このとき生成される差分データには、契約口座Ａの残高情報（８万円）が含まれている。なお、代行データ生成部２０１は、差分データを生成した際に、代行用テーブルにおける各レコードの更新フラグをクリアすることが好ましい。
【００６７】
差分データの生成が開始されると、銀行システム２０における切替指示部２０２から代行準備指示が代行システム１０に送信される（Ｓ２１７）。代行準備指示が、代行システム１０によって受信されると、システム１の稼働状態が第１切替状態に切り替わる。なお、通常状態から切替状態に切り替わるタイミングはこれに限定されず、代行データ生成部２０１が代行システム１０と全件分の代行データを共有したときから所定の期間経過後でもよい。
【００６８】
図９は、第１切替状態におけるシーケンス図である。
第１切替状態において、ユーザＡがデビット決済により、契約口座Ａから１万円分の代金を利用したとする。システム１が第１切替状態の場合、取引が発生する（Ｓ１２１）と、端末３０から、代行システム１０に対して取引情報が送信される（Ｓ１２２）。代行システム１０は受信した取引情報を銀行システム２０に転送する。このとき取引情報には、利用金額（１万円）と契約口座ＩＤ（契約口座ＡのＩＤ）が含まれている。
【００６９】
さらに銀行システム２０では、Ｓ１２２において送信された取引情報を受信したことに応じて、残高管理部２００によって、残高管理テーブル２３２における契約口座Ａに対応するレコードにおいて、引落の可否が判定され、引落可能な場合には、対応するレコードの残高情報から今回の利用金額が減算され、８万円から７万円に更新される（Ｓ２２１）。このとき残高管理部２００は、更新したレコードにおいて更新フラグを立てておくことが好ましい。そして、残高管理部２００は、引落結果を代行システム１０に通知する（Ｓ２２２）。
【００７０】
他方、代行システム１０では、Ｓ１２２において送信された取引情報について、銀行システム２０から引落結果（Ｓ２２２）を受信すると、取引代行部１０１が、代行用テーブル１３２を参照して、契約口座Ａに対応するレコードを抽出する。取引代行部１０１は、抽出したレコードの準備中累積金額の値に、今回受信した取引情報に含まれる利用金額（１万円）を加算して、更新する（Ｓ３２１）。また、代行システム１０では、銀行システム２０から引落結果を受信すると、今回の取引情報の承認の可否を判定し、結果を端末３０に通知する（Ｓ３２２）。
【００７１】
銀行システム２０においては、差分データの生成が完了すると、当該差分データを代行システム１０に送信する（Ｓ２２３）。
【００７２】
代行システム１０では、取引代行部１０１が、差分データを取得すると、代行用テーブル１３２を参照して、更新があったレコードの代行条件金額を更新する（Ｓ３２３）。例えば、契約口座Ａのレコードにおいて、代行条件金額の値を８万円に更新する。
【００７３】
システム１が第１切替状態の場合には、代行開始指示が送信されるまで、Ｓ１２１乃至Ｓ３２２の処理が、ユーザＡが契約口座Ａを用いて取引を行うたびに発生する。
【００７４】
他方、銀行システム２０では、差分データの送信が完了すると、切替指示部２０２が代行システム１０に対して、代行開始指示を送信する（Ｓ２２４）。
【００７５】
図１０は、システム１が代行状態の場合におけるシーケンス図である。
システム１が代行状態の場合において、ユーザＡがデビット決済により、契約口座Ａから１万円分の代金を利用したとする。代行状態では、取引が発生する（Ｓ１３１）と、端末３０から、代行システム１０に対して取引情報が送信される（Ｓ１３２）。このとき取引情報には、利用金額（１万円）と契約口座ＩＤ（契約口座ＡのＩＤ）が含まれている。
【００７６】
代行システム１０では、取引情報を受信すると、取引代行部１０１が、代行用テーブル１３２を参照して、ユーザＡに対応するレコードを抽出する。審査部１０２は、このとき上述した利用可能条件の判定式（式（１））に基づいて、取引の承認の可否を決定する（Ｓ３３１）。取引が承認される場合には、取引代行部１０１は、抽出したレコードの代行中累積金額の値に、今回受信した取引情報に含まれる利用金額（１万円）を加算して、更新する（Ｓ３３２）。このとき審査部１０２は、並行して承認結果を端末３０に通知する（Ｓ３３３）。
【００７７】
銀行システム２０においては、前回、差分データを生成してから所定の期間が経過すると、代行データ生成部２０１が、代行データの差分データを生成する（Ｓ２３１）。上述した図９の例では、Ｓ２２３の差分データ生成処理のタイミングにより、Ｓ２２１で行われた口座更新のデータが、代行システム１０と共有された差分データが含まれていない。この場合には、代行データ生成部２０１は、Ｓ２２１の更新処理のデータを含む差分データを生成する。このとき、代行データ生成部２０１は、残高管理テーブル２３２を参照して、更新フラグが立っているレコードから残高情報を取得して差分データを生成する。このとき生成される差分データには、契約口座Ａの残高情報（７万円）が含まれている。なお、代行データ生成部２０１は、差分データを生成した際に、残高管理テーブル２３２における各レコードの更新フラグをクリアすることが好ましい。
【００７８】
代行システム１０では、システム１が代行状態になってから初回の差分データ取得時には、代行条件金額の値の更新と併せて、準備中累積金額の値をクリアする（Ｓ３３４）。例えば契約口座Ａの例では、差分データとして受信した残高情報（７万円）を代行条件金額の値にセットし、さらに準備中累積金額の値を１万円から０円に更新する。準備中累積金額の値は、代行状態開始時における契約口座Ａの残高を管理するための値である。すなわち、差分データの生成タイミングによっては、代行状態開始時に、契約口座Ａの最新の残高情報を代行システム１０が取得できていない場合がある（例えば図９に示した例である。）。本実施形態に係る代行システム１０では、準備中累積金額を管理することで、代行フェーズ開始時に、契約口座Ａの最新の残高情報を代行システム１０が取得できていない場合でも適切に利用可能上限金額を管理することができる。
【００７９】
システム１が代行状態の場合において、システム外取引により契約口座の残高情報の更新があった場合（Ｓ２３３）、残高管理部２００は、契約口座Ａの残高情報を更新する。図１０の例では、契約口座Ａの残高情報が７万円から６万円に更新されている。代行データ生成部２０１は、前回、差分データを生成してから所定の期間が経過すると、代行データの差分データを生成する（Ｓ２３４）。なお、代行データ生成部２０１が差分データを生成する他のタイミングや生成方法は、上述のとおりである。代行データ生成部２０１が、生成した差分データを代行システム１０と共有する（Ｓ２３５）と、取引代行部１０１は、代行用テーブル１３２を参照し、対応するレコードの代行条件金額の値を受信した残高情報で更新する（Ｓ３３５）。
【００８０】
図１１は、システム１が第２切替状態の場合のシーケンス図である。
銀行システム２０から代行システム１０が代行解除指示を受信する（Ｓ２４１）と、稼働状態が代行状態から第２切替状態に切り替わる。なお、第２切替状態への切替タイミングは、代行システム１０が代行解除指示を受信したときに限定されず、所定の時刻が到来したときでもよい。第２切替状態においても、代行中の取引情報の反映が完了するまでの間に、取引が発生する（Ｓ１４１）と、端末３０から、代行システム１０に対して取引情報が送信される（Ｓ１４２）。このとき取引情報には、利用金額（１万円）と契約口座ＩＤ（契約口座ＡのＩＤ）が含まれている。この場合における代行システム１０の処理（Ｓ３４１、３４２，３４３）は、上述の代行状態におけるＳ３３１，Ｓ３３２、Ｓ３３３の処理と同様である。
【００８１】
代行解除指示を受信すると、取引代行部１０１は、代行中に受信した取引情報を銀行システム２０に送信する（Ｓ３４４）。
【００８２】
銀行システム２０においては、受信した取引情報に基づいて、代行反映部２０３が残高管理テーブル２３２の各レコードにおける残高情報を更新する。例えば、契約口座Ａについて、利用金額が１万円の取引情報が送信された場合には、代行反映部２０３は、残高管理テーブル２３２における契約口座Ａの残高情報について、代行フェーズ移行前に管理していた６万円から、受信した取引情報分（１万円）減算して、更新し（Ｓ２４３）、引落結果を代行システム１０に通知する（Ｓ２４４）。このＳ３４４，Ｓ２４３，Ｓ２４４と同様の処理が、代行中の取引情報の反映が完了するまで繰り返し実行される（Ｓ３４５，Ｓ２４５，Ｓ２４６）。
【００８３】
代行システム１０では、代行中の取引情報の送信が完了した場合、または所定の時刻が到来するすると、通常状態に切り替わり、代行用テーブル１３２における各値（準備中累積金額、代行中累積金額、及び／又は代行条件金額）をクリアする（Ｓ３４５）。なお、所定の時刻が到来した際に通常状態に切り替わる構成の場合には、クリアするのは取引情報の反映が完了してからである。
【００８４】
このように、本実施形態に係るシステム１によると、代行システム１０が代行データを受信してから、銀行システム２０がオンライン処理停止状態になる前に取引情報が送信された場合であっても、当該取引情報によって更新される残高情報を代行システム１０が管理することができる。これによって、代行システム１０において管理する契約口座の残高情報の正確性が向上するため、銀行システム２０の業務の代行時において、利用可能な限度額以上の取引が誤って行われることを抑制することができる。
【００８５】
＜５．ハードウェア構成＞
以下、図１２を参照しながら、上述してきた代行システム１０、銀行システム２０、及び端末３０をコンピュータ８００により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。
【００８６】
図１２に示すように、コンピュータ８００は、プロセッサ８０１、メモリ８０３、記憶装置８０５、入力Ｉ／Ｆ部８０７、データＩ／Ｆ部８０９、通信Ｉ／Ｆ部８１１、及び表示装置８１３を含む。
【００８７】
プロセッサ８０１は、メモリ８０３に記憶されているプログラムを実行することによりコンピュータ８００における様々な処理を制御する。例えば、代行システム１０の取引代行部１０１や、銀行システム２０の残高管理部２００、代行データ生成部２０１、切替指示部２０２、及び代行反映部２０３などは、メモリ８０３に一時記憶された上で、主にプロセッサ８０１上で動作するプログラムとして実現可能である。
【００８８】
メモリ８０３は、例えばＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等の記憶媒体である。メモリ８０３は、プロセッサ８０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。
【００８９】
記憶装置８０５は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶装置８０５は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。この他、記憶装置８０５は、ユーザ情報ＤＢ１３１、代行用テーブル１３２、契約者情報ＤＢ２３１や、残高管理テーブル２３２を記憶することも可能である。このようなプログラムやデータは、必要に応じてメモリ８０３にロードされることにより、プロセッサ８０１から参照される。
【００９０】
入力Ｉ／Ｆ部８０７は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部８０７の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイス等が挙げられる。入力Ｉ／Ｆ部８０７は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）等のインタフェースを介してコンピュータ８００に接続されても良い。
【００９１】
データＩ／Ｆ部８０９は、コンピュータ８００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部８０９の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置等がある。データＩ／Ｆ部８０９は、コンピュータ８００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部８０９は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００へと接続される。
【００９２】
通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部の装置と有線又は無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部８１１は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００に接続される。
【００９３】
表示装置８１３は、各種情報を表示するためのデバイスである。表示装置８１３の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイ等が挙げられる。表示装置８１３は、コンピュータ８００の外部に設けられても良い。その場合、表示装置８１３は、例えばディスプレイケーブル等を介してコンピュータ８００に接続される。また、入力Ｉ／Ｆ部８０７としてタッチパネルが採用される場合には、表示装置８１３は、入力Ｉ／Ｆ部８０７と一体化して構成することが可能である。
【００９４】
［その他の実施形態］
以上説明した各実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更／改良され得るととともに、本発明にはその等価物も含まれる。また、各実施形態は例示であり、異なる実施形態で示した構成の部分的な置換または組み合わせが可能であることは言うまでもなく、これらも本発明の特徴を含む限り本発明の範囲に包含される。
【００９５】
例えば、既述の実施形態では、取引情報は、デビット決済を用いた取引に関する情報を例に説明したが、これに限定されない。取引情報は、クレジット決済を用いた取引に関する情報や、契約口座から所定の金額を引き落とす処理に関する情報、所定の契約口座から他の契約口座への任意の金額を振り返る処理に関する情報でもよい。
【００９６】
また、既述の実施形態では、システム１の稼働状態は、代行準備指示に基づいて通常状態から第１切替状態に切り替わる構成について説明したが、これに限定されない。システム１の稼働状態が切り替わる際に、代行準備指示が代行システム１０に通知されない構成でもよい。この場合には、例えば、代行データ生成部２０１が全件データの生成を開始してから所定の時間を経過したときや、代行システム１０に全件データの送信を開始してから所定の時間を経過したときに通常状態から第１切替状態に切り替わる構成でもよい。
【００９７】
さらに既述の実施形態では、銀行システム２０は、代行システム１０から取引情報を受信する構成として説明したが、これに限定されず、端末３０から直接受信する構成でもよい。この場合、通常状態及び第１切替状態においては、銀行システム２０が取引の承認の可否を判定してもよい。
【００９８】
また、既述の実施形態では、取引情報には契約口座ＩＤが含まれる構成を説明したがこれに限定されず、取引情報には契約口座ＩＤの代わりにユーザが利用したカードＩＤが含まれる構成でもよい。この場合、代行システム１０は、取引情報を銀行システム２０に転送する際に、ユーザ情報ＤＢテーブル１３１を参照して、取引情報に含まれるカードＩＤに応じた契約口座ＩＤを特定して、特定した契約口座ＩＤを銀行システム２０に併せて通知してもよい。
【符号の説明】
【００９９】
１  システム
１０  代行システム
２０  銀行システム
３０  端末
１０１  取引代行部
１３２  代行用テーブル
２００  残高管理部
２０１  代行データ生成部
２０２  切替指示部
２０３  代行反映部
２３２  残高管理テーブル
【図１】
2019175134.tif 000003
【図２】
2019175134.tif 000004
【図３】
2019175134.tif 000005
【図４】
2019175134.tif 000006
【図５】
2019175134.tif 000007
【図６】
2019175134.tif 000008
【図７】
2019175134.tif 000009
【図８】
2019175134.tif 000010
【図９】
2019175134.tif 000011
【図１０】
2019175134.tif 000012
【図１１】
2019175134.tif 000013
【図１２】
2019175134.tif 000014
【手続補正書】
【提出日】平成30年9月5日(2018.9.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
銀行システムにおいて管理されている口座の残高の少なくとも一部を利用する取引が行われる際に、前記口座を識別する口座情報と、前記取引の金額である取引金額とを含む取引情報を取得する取得部と、
前記銀行システムから、前記銀行システムが前記取引情報に基づいて前記口座の残高を管理する処理を停止する前に、前記口座の残高を示す残高情報を取得して、第１金額として前記口座情報と対応付けて記憶部に格納する第１格納部と、
前記残高情報を取得したあと、前記銀行システムが前記処理を停止する前に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額を第２金額として、前記口座情報と対応付けて前記記憶部に格納する第２格納部と、
前記銀行システムが前記処理を停止している間に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額と、前記第１金額から前記第２金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定する判定部と、を備え、
前記第１格納部は、前記銀行システムが前記処理を停止している間に前記銀行システムから前記口座の更新された残高情報を受信した場合、当該口座の前記口座情報に対応する前記第１金額を、前記更新された残高情報によって更新する、代行システム。
【請求項２】
前記判定部は、
前記取引を承認する場合に、前記銀行システムが前記処理を停止している間に取得された前記取引情報に含まれる前記取引金額を、第３金額として前記口座情報と対応付けて前記記憶部に格納する、
請求項１に記載の代行システム。
【請求項３】
前記銀行システムが前記処理を停止している間に、前記銀行システムから前記口座の更新された残高情報を受信した場合に、
前記判定部は、
前記取引を承認するかどうかの判定に、前記第１金額及び第３金額を用いる、
請求項２に記載の代行システム。
【請求項４】
前記判定部は、
前記銀行システムが前記処理を停止している間に、前記取引情報がさらに取得された場合に、当該取引情報に含まれる前記取引金額と、前記第１金額から、前記第３金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定し、当該取引情報に含まれる前記取引金額を前記第３金額に加算する、
請求項３に記載の代行システム。
【請求項５】
前記銀行システムがオンライン処理を停止していた期間における、前記第３金額の累積額を、前記銀行システムが前記オンライン処理を開始する際に当該銀行システムに提供する提供部、
をさらに備える請求項２又は３に記載の代行システム。
【請求項６】
前記第１格納部は、前記銀行システムから、前記銀行システムが前記取引情報に基づいて前記口座の残高を管理する処理を停止する前に、前記銀行システムにおいて管理されているすべての口座について、前記口座の残高を示す残高情報を取得して、第１金額として前記口座情報と対応付けて記憶部に格納する、請求項１から５のいずれか一項に記載の代行システム。
【請求項７】
コンピュータが、
銀行システムにおいて管理されている口座の残高の少なくとも一部を利用する取引が行われる際に、前記口座を識別する口座情報と、前記取引の金額である取引金額とを含む取引情報を取得するステップと、
前記銀行システムから、前記銀行システムが前記取引情報に基づいて前記口座の残高を管理する処理を停止する前に、前記口座の残高を示す残高情報を取得して、第１金額として前記口座情報と対応付けて記憶部に格納するステップと、
前記残高情報を取得したあと、前記銀行システムが前記処理を停止する前に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額を第２金額として、前記口座情報と対応付けて前記記憶部に格納するステップと、
前記銀行システムが前記処理を停止している間に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額と、前記第１金額から前記第２金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定するステップと、
前記銀行システムが前記処理を停止している間に、前記銀行システムから前記口座の更新された残高情報を受信すると、当該口座の前記口座情報に対応する前記第１金額を、前記更新された残高情報によって更新するステップと、
を実行する代行方法。
【請求項８】
コンピュータを、
銀行システムにおいて管理されている口座の残高の少なくとも一部を利用する取引が行われる際に、前記口座を識別する口座情報と、前記取引の金額である取引金額とを含む取引情報を取得する手段、
前記銀行システムから、前記銀行システムが前記取引情報に基づいて前記口座の残高を管理する処理を停止する前に、前記口座の残高を示す残高情報を取得して、第１金額として前記口座情報と対応付けて記憶部に格納する第１格納手段、
前記残高情報を取得したあと、前記銀行システムが前記処理を停止する前に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額を第２金額として、前記口座情報と対応付けて前記記憶部に格納する第２格納手段、及び
前記銀行システムが前記処理を停止している間に、前記取引情報が取得されると、当該取引情報に含まれる前記取引金額と、前記第１金額から前記第２金額を減じた金額とに基づいて、当該取引情報に関する前記取引を承認するかどうかを判定する手段、
として機能させ、
前記第１格納手段は、前記銀行システムが前記処理を停止している間に前記銀行システムから前記口座の更新された残高情報を受信した場合、当該口座の前記口座情報に対応する前記第１金額を、前記更新された残高情報によって更新する、プログラム。