JP2019087063A - 入出金代行システム - Google Patents

Abstract

【課題】入出金サービスを提供する提携先の顧客が提携先のサーバに対して要求した取引に基づいて、取引サーバと連携する入出金装置において当該取引の実行を可能とした入出金代行システムを提供する。【解決手段】取引サーバは、利用者からの要求に応じて取引データを送信する提携先のサーバから、提携先情報、利用者の情報及び取引情報を含む取引データを受け付けて、入出金明細レコードを登録する取引データ受付部と、入出金明細レコードに関連付けられた確認コードを利用者の連絡先に送信する認証データ送信部と、入出金装置から、提携先情報、利用者の情報及び確認コードを含む認証要求を受信して、当該認証要求により特定される入出金明細レコードが存在するか否かを判定する取引認証部と、入出金装置から取引結果を受信して、当該取引結果により特定される入出金明細レコードを更新する取引結果受付部とを備える。【選択図】図２

Description

本発明は、入出金代行システムに関する。

ＡＴＭを用いた入出金サービスが普及している（例えば、特許文献１）。顧客は金融機関において口座を開設することで、ＡＴＭを利用して口座への入出金を行うことができる。

金融機関の口座における金融資産に加えて、あるいは口座における金融資産に代えて、顧客は、電子マネーやプリペイドカード、クレジットカード、証券等、様々な形で金融資産を保有している。金融機関は、他の金融機関が保有・管理するＡＴＭを業務提携により利用することができる。

ＡＴＭによる入出金サービスを提供する提携先機関とＡＴＭとの間は閉域網を通じた金融標準の接続手順（従来型のＡＴＭ接続）により接続されており、ＡＴＭによるサービスを新たに開始する提携先機関は、従来型ＡＴＭ接続に対応するシステムを構築する必要がある。

特開平７−２３９８９０号公報

しかし、従来型ＡＴＭ接続に対応するシステム構築は、提携先機関に対して一定の開発コストを課すものであり、これはＡＴＭを用いたサービス提供実現への壁の１つとなっている。

顧客は、クレジットカードや電子マネーを用いて支払いを行うことができる一方で、現金が必要となる場面もある。口座からの出金が出来ない場合、プリペイドカードや証券等、例え他の金融資産を保有していたとしても、顧客は現金を得ることはできない。

また、顧客は、現金を持ち歩きたくない場合もある。口座への入金が出来ない場合、顧客は現金を信頼できる機関に預けることはできない。

そこで、本発明は、入出金サービスを提供する提携先の顧客が、提携先のサーバに対して要求した取引に基づいて、取引サーバと連携する入出金装置において当該取引の実行を可能とした入出金代行システムを提供することを目的とする。

本発明の一態様に係る取引サーバは、入出金サービスを提供する提携先のサーバから、提携先情報、入出金サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、入出金明細レコードを登録する取引データ受付部であって、提携先のサーバは、利用者からの要求に応じて取引データを送信する、取引データ受付部と、入出金明細レコードに関連付けられた確認コードを利用者の連絡先に送信する認証データ送信部と、入出金装置から、提携先情報、利用者の情報及び確認コードを含む認証要求を受信して、当該認証要求により特定される入出金明細レコードが存在するか否かを判定する取引認証部であって、入出金明細レコードが存在する場合、特定された入出金明細レコードの取引情報を入出金装置に送信する、取引認証部と、入出金装置から取引結果を受信して、当該取引結果により特定される入出金明細レコードを更新する取引結果受付部とを備える。

この態様によれば、入出金サービスを提供する提携先の顧客が、提携先のサーバに対して要求した取引に基づいて、取引サーバと連携する入出金装置において当該取引を実行することができる。

上記取引サーバにおいて、登録から一定の期間を経過した未実行の入出金明細レコードを削除する期限管理部をさらに備えてもよい。この態様によれば、登録から一定の期間を経過した入出金明細レコードについては無効であるとして削除することで、よりセキュアな取引サーバを構築することができる。

上記取引サーバにおいて、取引情報が出金取引を示す場合、取引データ受付部は、提携先に関連付けられた口座に基づいて、出金取引に対する資金の引き当てに成功する場合に、入出金明細レコードを登録してもよい。上記取引サーバにおいて、取引データ受付部は、出金取引に対する資金の引き当てに成功する場合に、取引情報に基づいて口座に出金レコードを登録してもよい。この態様によれば、出金取引について、入出金明細レコードを登録する前に資金の引き当てを行うことにより、取引サーバは、適切なリスク管理を行うことができる。

上記サーバにおいて、取引情報が出金取引を示す場合、取引データ受付部は、提携先に関連付けられた信用情報に基づいて、出金取引に対する出金余力がある場合に、入出金明細レコードを登録してもよい。上記取引サーバにおいて、取引データ受付部は、出金取引に対する出金余力がある場合に、取引情報に基づいて提携先に関連付けられた記憶部に出金レコードを登録してもよい。

上記取引サーバにおいて、取引情報が入金取引を示す場合、取引結果受付部は、取引結果に基づいて提携先に関連付けられた記憶部に入金レコードを登録してもよい。この態様によれば、入金取引について、取引実行後に記憶部に入金レコードを登録することにより、取引サーバは、適切なリスク管理を行うことができる。

本発明の他の態様に係る、コンピュータが実行する入出金代行方法は、入出金サービスを提供する提携先のサーバから、提携先情報、入出金サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、入出金明細レコードを登録する工程であって、提携先のサーバは、利用者からの要求に応じて取引データを送信する、工程と、入出金明細レコードに関連付けられた確認コードを利用者の連絡先に送信する工程と、入出金装置から、提携先情報、利用者の情報及び確認コードを含む認証要求を受信して、当該認証要求により特定される入出金明細レコードが存在するか否かを判定する工程であって、入出金明細レコードが存在する場合、特定された入出金明細レコードの取引情報を入出金装置に送信する、工程と、入出金装置から取引結果を受信して、当該取引結果により特定される入出金明細レコードを更新する工程とを含む。

本発明の他の態様に係るプログラムは、コンピュータに、入出金サービスを提供する提携先のサーバから、提携先情報、入出金サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、入出金明細レコードを登録する工程であって、提携先のサーバは、利用者からの要求に応じて取引データを送信する、処理と、入出金明細レコードに関連付けられた確認コードを利用者の連絡先に送信する処理と、入出金装置から、提携先情報、利用者の情報及び確認コードを含む認証要求を受信して、当該認証要求により特定される入出金明細レコードが存在するか否かを判定する処理であって、入出金明細レコードが存在する場合、特定された入出金明細レコードの取引情報を入出金装置に送信する、処理と、入出金装置から取引結果を受信して、当該取引結果により特定される入出金明細レコードを更新する処理とを実行させる。

本発明の他の態様に係る入出金装置は、入出金サービスを提供する提携先の情報、入出金サービスを利用する利用者の情報及び確認コードを含む認証要求を取引サーバに送信する認証要求送信部であって、確認コードは、取引サーバから利用者の連絡先に通知されたものである、認証要求送信部と、認証要求の応答として取引サーバから受信した取引情報に基づいて、入出金処理を実行する入出金処理部と、取引結果を取引サーバに送信する取引結果送信部と、を備え、提携先のサーバは、利用者からの要求に応じて、提携先の情報、利用者の情報及び取引情報を含む取引データを送信し、取引サーバは、受信した取引データに関連付けられた確認コードを利用者の連絡先に送信する。

本発明の他の態様に係る取引サーバは、サービスを提供する提携先のサーバから、提携先情報、サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、サービス明細レコードを登録する取引データ受付部であって、提携先のサーバは、利用者からの要求に応じて取引データを送信する、取引データ受付部と、サービス明細レコードに関連付けられた確認コードを利用者の連絡先に送信する認証データ送信部と、入出金装置から、提携先情報、利用者の情報及び確認コードを含む認証要求を受信して、当該認証要求により特定されるサービス明細レコードが存在するか否かを判定する取引認証部であって、サービス明細レコードが存在する場合、特定されたサービス明細レコードの取引情報を入出金装置に送信する、取引認証部と、入出金装置から取引結果を受信して、当該取引結果により特定されるサービス明細レコードを更新する取引結果受付部とを備える。

本発明の他の態様に係る入出金装置は、サービスを提供する提携先の情報、サービスを利用する利用者の情報及び確認コードを含む認証要求を取引サーバに送信する認証要求送信部であって、確認コードは、取引サーバから利用者の連絡先に通知されたものである、認証要求送信部と、認証要求の応答として取引サーバから受信した取引情報に基づいて、処理を実行する処理部と、取引結果を取引サーバに送信する取引結果送信部と、を備え、提携先のサーバは、利用者からの要求に応じて、提携先の情報、利用者の情報及び取引情報を含む取引データを送信し、取引サーバは、受信した取引データに関連付けられた確認コードを利用者の連絡先に送信する。

本発明によれば、入出金サービスを提供する提携先の顧客が、提携先のサーバに対して要求した取引に基づいて、取引サーバと連携する入出金装置において当該取引の実行を可能とした入出金代行システムを提供することができる。

本発明の一実施形態に係る入出金代行システムの構成例を示す図である。 本発明の一実施形態に係る銀行サーバの構成図である。 本発明の一実施形態に係る提携先サーバの構成図である。 本発明の一実施形態に係る顧客端末の構成図である。 本発明の一実施形態に係るＡＴＭの構成図である。 本発明の一実施形態に係る入出金明細ＤＢの内容を例示する図である。 本発明の一実施形態に係る入出金代行処理の一例を示すフローチャートである。 本発明の一実施形態に係る入出金代行処理の一例を示すフローチャートである。

添付図面を参照して、本発明の実施形態について説明する。なお、以下の実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施形態を採用することが可能であり、係る実施形態も本発明の範囲に含まれる。

（システム構成）
図１は、本発明の一実施形態に係る入出金代行システムの構成例を示す。入出金代行システム１は、銀行サーバ１０、提携先サーバ２０、顧客端末３０、現金自動預払装置（以下、ＡＴＭという。）４０を備える。銀行サーバ１０は、提携先サーバ２０及び顧客端末３０とネットワークＮを介して通信を行うよう構成されている。また、銀行サーバ１０は、ＡＴＭ４０と専用回線ＰＮを介して通信を行うよう構成されている。銀行サーバ１０は、提携先サーバ２０及びＡＴＭ４０と協働して、顧客端末３０を使用する顧客に入出金サービスを提供する。

顧客は、顧客端末３０を用いて、提携先サーバ２０が提供する入出金サービスサイトにアクセスして、取引予約を行うことができる。取引予約を受け付けた提携先サーバ２０は、銀行サーバ１０に取引登録を行う。取引登録を受け付けた銀行サーバ１０は、顧客端末３０に確認コードを含む認証データを送信する。顧客は、ＡＴＭ４０を操作して認証データに関する入力を行うことで、予約した取引を実行することができる。

銀行サーバ１０は、提携先機関のデポジット口座を備える。銀行サーバ１０は、インターネットバンキング、紙媒体を使用した銀行の店頭窓口での受付等、種々の手法を通じた提携先機関によるデポジット口座への振込又は入金データを受信して、デポジット口座に対する入金処理を実行する。

銀行サーバ１０は、提携先サーバ２０を介して提携先機関から取引データを受信すると、取引登録を行う。提携先サーバ２０から出金取引に関する取引データを受信した場合、銀行サーバ１０は、デポジット口座の資金を引き当てることで、取引登録を行う。

銀行サーバ１０は、取引登録が完了した取引データについて、取引データに関連付けられる確認コードを生成する。銀行サーバ１０は、確認コードを含む、取引の実行に必要な認証データを顧客端末３０に送信する。なお、本明細書におけるコードは、漢字、ひらがな、カタカナ、英数字、記号等の１又は複数からなる情報である。

提携先サーバ２０は、入出金サービスを提供するためのウェブサイトをネットワークＮ上で提供する。当該ウェブサイトにおいて、顧客は入出金取引の予約を行うことができる。提携先サーバ２０は、顧客端末３０から取引予約を受け付けると、受け付けた取引予約に基づいて銀行サーバ１０に取引データを送信する。

顧客端末３０で認証データを受信した顧客は、ＡＴＭ４０を操作して確認コード等の入力を行う。入力に応答して、ＡＴＭ４０は、認証要求を銀行サーバ１０に送信する。銀行サーバ１０において認証要求が認証されると、確認コードに関連付けられた取引データに基づいて、取引が実行される。取引の実行により、顧客は、ＡＴＭ４０を介して入金、出金等を行うことができる。

（銀行サーバ構成）
図２は、本発明の一実施形態に係る銀行サーバ１０の構成を示す。なお、図２では、単一の銀行サーバ１０を想定し、必要な機能構成だけを示しているが、銀行サーバ１０を、複数のコンピュータシステムによる多機能の分散システムの一部として構成することもできる。

銀行サーバ１０は、ネットワークＮを介して提携先サーバ２０及び顧客端末３０と通信し、専用回線ＰＮを介してＡＴＭ４０と通信する機能を備えたサーバ装置である。図２に示すように、銀行サーバ１０は、入力部１１、制御部１２、記憶部１３及び通信部１４を備えている。

入力部１１は、銀行サーバ１０に対する各種入力を受信する。

制御部１２は、ＣＰＵやＭＰＵ等の演算処理部１２１及びＲＡＭ等のメモリ１２２を備えている。演算処理部１２１は、各種入力に基づき、記憶部１３に記憶されているプログラムを実行することで、各種機能部を動作させるものである。このプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記憶され、若しくはネットワークＮを介して配布され、コンピュータにインストールされるものであってもよい。メモリ１２２は、銀行サーバ用プログラムにおいて処理の実行中、演算等に必要な各種データを、一時的に記憶するためのものである。

記憶部１３は、ハードディスク等の記憶装置によって構成され、制御部１２における処理の実行に必要な各種プログラムや、各種プログラムの実行に必要なデータ等を記録しておくものである。本実施形態では、記憶部１３は、代行契約データベース（ＤＢ）１３１、入出金明細ＤＢ１３２及びデポジット口座ＤＢ１３３を有していることが望ましい。

代行契約ＤＢ１３１には、入出金代行サービスを管理するための情報が保存されている。一実施形態では、代行契約ＤＢ１３１には、提携先機関コード、提携先機関名、デポジット口座番号、出金枠等が登録されていることが望ましい。デポジット口座番号は、後述するデポジット口座ＤＢ１３３を識別可能な情報である。出金枠は、提携先機関からの出金取引に関する取引データに制限を設ける際に設定することができる。デポジット口座の残高のみに応じて出金取引に資金を引き当てる場合は、出金枠は未設定としてもよい。

入出金明細ＤＢ１３２には、提携先サーバ２０から送信される取引データに基づいて、取引を実行するための情報が保存されている。一実施形態では、図６に示されるように、入出金明細ＤＢ１３２には、取引通番、提携先機関コード、顧客コード、確認コード、入金額、出金額、ステータス、顧客連絡先、登録日時等が登録されていることが望ましい。

顧客コードは、取引データに含まれる、顧客に関連付けられた情報である。例えば、入出金代行システム１は、提携先機関が提供するサービスで利用している顧客ＩＤ、顧客の電話番号等、提携先機関と顧客との間で共有している情報のうち、当該顧客のみが知り得る情報を顧客コードとして用いることが望ましい。確認コードは、少なくとも同一顧客に対する複数の取引を識別するために用いる情報である。本実施形態では、銀行サーバ１０が確認コードを生成するが、代替の実施形態では、提携先機関が確認コードを生成して取引データに含めてもよい。

ステータスは、当該取引に関するステータスを示し、例えば、取引実行前の状態を示す「０」、取引が完了した状態を示す「１」、入金取引がデポジット口座に反映された状態を示す「２」等が設定される。顧客連絡先は、メールアドレスや携帯端末電話番号等、認証データを顧客端末３０に送信するために用いる情報である。登録日時は、レコードが登録された日時が設定され、当該取引の有効期限を管理するために用いることができる。

デポジット口座ＤＢ１３３には、提携先機関毎の入出金を管理する情報が保存されている。本実施形態では、銀行サーバ１０は、デポジット口座番号によって提携先機関に関連付けられたデポジット口座ＤＢ１３３を特定することができる。一実施形態では、デポジット口座ＤＢ１３３には、取引日、出金額、入金額、残高等が登録されていることが望ましい。

通信部１４は、銀行サーバ１０を専用回線ＰＮ及びネットワークＮに接続するための通信インタフェースを有する。例えば、通信部１４は、ＬＡＮカード、アナログモデム、ＩＳＤＮモデム等、及びこれらをシステムバス等の伝送路を介して処理部と接続するためのインタフェースから実現することができる。

さらに、図２に示すように、演算処理部１２１は、機能部として、取引データ受付部１２３、認証データ送信部１２４、デポジット受付部１２５、取引認証部１２６、取引結果受付部１２７及び期限管理部１２８を備えている。

取引データ受付部１２３は、提携先サーバ２０から取引データを受け付けて、入出金明細レコードを入出金明細ＤＢ１３２に登録する。入出金明細レコードを登録した後、取引データ受付部１２３は、提携先サーバ２０に完了通知を行ってもよい。一実施形態では、取引データには、提携先機関コード、顧客コード、取引区分、取引額、顧客連絡先等が含まれる。一実施形態では、取引データ受付部１２３は、提携先サーバ２０から受け付けた取引データの取引区分が入金を示す場合、デポジット口座ＤＢ１３３の残高から独立して入出金明細レコードを登録し、一方、受け付けた取引データの取引区分が出金を示す場合、デポジット口座ＤＢ１３３の残高に基づいて、入出金明細レコードを登録してもよい。

受け付けた取引データの取引区分が出金を示す場合、具体的には、取引データ受付部１２３は、デポジット口座ＤＢ１３３の資金の引き当てに成功した場合に、取引データに基づいて入出金明細レコードを登録し、引き当てに失敗した場合、取引登録に失敗した旨を含むエラー情報を提携先サーバ２０に戻す。資金の引き当てに成功すると、取引データ受付部１２３は、デポジット口座ＤＢ１３３に出金レコードを登録する。

一実施形態では、取引データ受付部１２３は、代行契約ＤＢ１３１の出金枠に基づいて、入出金明細レコードを登録してもよい。取引データ受付部１２３は、デポジット口座ＤＢ１３３の残高に加えて代行契約ＤＢ１３１の出金枠を考慮することもできるし、デポジット口座ＤＢ１３３の残高に代えて代行契約ＤＢ１３１の出金枠を考慮することもできる。

認証データ送信部１２４は、入出金明細ＤＢ１３２に登録が完了した取引データについて、取引データに関連付けられる確認コードを生成して入出金明細ＤＢ１３２に保存する。前述したように、確認コードは、少なくとも同一顧客に対する複数の取引を識別するために用いる情報であり、提携先機関コード及び顧客コードと組み合わせることで取引を一意に識別し得る。

続いて、認証データ送信部１２４は、取引の実行に必要な認証データを顧客端末３０に送信する。本実施形態では、認証データには、提携先機関コード及び確認コードが含まれる。認証データに顧客コードを含めないことで、顧客コードを知る正当な顧客のみが取引を実行することを可能とし得る。一実施形態では、認証データ送信部１２４は、認証データに入出金明細レコードの有効期限を含めてもよい。有効期限は、入出金明細レコードの登録日時に基づいて算出してもよい。

デポジット受付部１２５は、資金入金情報を受け付けて、デポジット口座ＤＢ１３３に入金レコードを登録する。本実施形態では、資金入金情報には提携先機関コード及び入金額が含まれ、デポジット受付部１２５は、資金入金情報の提携先機関コードに関連付けられたデポジット口座番号により特定されるデポジット口座ＤＢ１３３に、入金レコードを登録する。

取引認証部１２６は、ＡＴＭ４０から認証要求を受信して、取引の認証を行う。本実施形態では、認証要求には、提携先機関コード、顧客コード及び確認コードが含まれる。取引認証部１２６は、認証要求で特定される入出金明細レコードが存在し、かつ、特定される入出金明細レコードのステータスに「０」が設定されているか否かを判定する。認証要求で特定される入出金明細レコードが存在し、かつ、特定された入出金明細レコードのステータスに「０」が設定されている場合、取引認証部１２６は、特定された入出金明細レコードに基づく取引指示をＡＴＭ４０に送信する。一実施形態では、取引指示には、取引通番、取引区分及び取引額が含まれる。

一方、認証要求で特定される入出金明細レコードが存在しない場合、又は特定された入出金明細レコードのステータスに「０」以外が設定されている場合、取引認証部１２６は、取引処理を実行できない原因情報をＡＴＭ４０に送信する。

取引結果受付部１２７は、ＡＴＭ４０から取引結果を受信して、受信した取引結果に対応する入出金明細レコードを入出金明細ＤＢ１３２で特定して、ステータスを「１」に更新する。本実施形態では、取引結果には、提携先機関コード、顧客コード及び取引通番が含まれる。ここで、取引結果受付部１２７は、受信した取引結果を、提携先サーバ２０に送信してもよい。

さらに、取引結果受付部１２７は、入金取引の完了後、デポジット口座ＤＢ１３３に入金レコードを登録する。取引結果受付部１２７は、取引結果の受信に応答して、デポジット口座ＤＢ１３３に入金レコードを登録してもよいし、一定の間隔で入出金明細レコードのステータスが「１」である入金取引を抽出して、デポジット口座ＤＢ１３３に入金レコードを登録してもよい。デポジット口座ＤＢ１３３への入金レコードの登録が完了すると、取引結果受付部１２７は、入出金明細レコードのステータスを「２」に更新する。

期限管理部１２８は、登録から一定の期間を経過した未実行の入出金明細レコードを、入出金明細ＤＢ１３２から削除する。出金取引に関する入出金明細レコードを入出金明細ＤＢ１３２から削除する場合、期限管理部１２８は、デポジット口座ＤＢ１３３に入金レコードを登録することで、引き当て済の資金を解除することが望ましい。

（提携先サーバ構成）
図３は、本発明の一実施形態に係る提携先サーバ２０の構成を示す。なお、図３では、単一の提携先サーバ２０を想定し、必要な機能構成だけを示しているが、提携先サーバ２０を、複数のコンピュータシステムによる多機能の分散システムの一部として構成することもできる。

提携先サーバ２０は、ネットワークＮを介して銀行サーバ１０及び顧客端末３０と通信する機能を備えたサーバ装置である。図３に示すように、提携先サーバ２０は、入力部２１、ＣＰＵ及びメモリを含む制御部２２、記憶部２３及びネットワークＮと接続するための通信部２４を備えている。

制御部２２は、記憶部２３に記憶されているプログラムがＲＡＭに読み出され、ＣＰＵによって実行されることで、ウェブサイト提供部２２１及び取引データ生成部２２２として機能する。また、記憶部２３は、顧客ＤＢ２３１及び取引予約ＤＢ２３２を有していることが望ましい。

ウェブサイト提供部２２１は、入出金サービスを提供するためのウェブサイトをネットワークＮ上で提供する。当該ウェブサイトにおいて、顧客は入出金取引の予約を行うことができる。ウェブサイト提供部２２１は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等で記述されたウェブページを、顧客の使用する顧客端末３０へ送信すると共に、ユーザ入力等を顧客端末３０から受信する。

ウェブサイト提供部２２１は、顧客からの入力等に応答して、対応するウェブページを作成して顧客端末３０に送信する。具体的には、例えば、ログイン画面、入出金取引の予約画面、予約した結果を表示する結果画面等に係る各種ウェブページを、ウェブサイト提供部２２１は顧客端末３０のブラウザへ送信する。

取引データ生成部２２２は、ウェブサイト提供部２２１が受信した顧客端末３０からのユーザ入力に基づいて取引データを生成し、生成した取引データを銀行サーバ１０に送信する。一実施形態では、取引データには、提携先機関コード、顧客コード、取引区分、取引額、顧客連絡先等が含まれる。前述したように、顧客コードは、提携先機関が提供するサービスで利用している顧客ＩＤ、顧客の電話番号等、提携先機関と顧客との間で共有している情報のうち、当該顧客のみが知り得る情報とすることが望ましい。

取引データ生成部２２２は、顧客ＤＢ２３１等に基づいて、顧客から申請された取引を許可するか否かを判定してもよい。例えば、取引データ生成部２２２は、顧客が保有する金融資産や顧客に関連付けられた取引条件、これまでの取引履歴等に基づき、顧客から申請された取引を許可するか否かを判定してもよい。

さらに、取引データ生成部２２２は、ウェブサイト提供部２２１が受信した顧客端末３０からのユーザ入力に基づいて、取引予約ＤＢ２３２に取引予約レコードを登録してもよい。取引予約ＤＢ２３２には、顧客コード、取引区分、取引額、予約日時等が登録されていることが望ましい。予約日時は、取引データの送信に応答して、取引データ受付完了通知を受信した日時を設定してもよい。

（顧客端末構成）
図４は、本発明の一実施形態に係る顧客端末３０の構成を示す。顧客端末３０は、ネットワークＮを介して銀行サーバ１０及び提携先サーバ２０と通信する機能を備えた情報処理端末である。具体的には、携帯電話やスマートフォン、ＰＣ、ＰＤＡ、タブレット等が挙げられるが、これに限られない。図４に示すように、顧客端末３０は、ユーザからの操作を受け付けるタッチパネル等の入力部３１、ディスプレイ等の表示部３２、ＣＰＵ及びメモリを含む制御部３３、記憶部３４、ネットワークＮと接続するための通信部３５等を備えている。制御部３３は、記憶部３４に記憶されているプログラムがＲＡＭに読み出され、ＣＰＵによって実行されることで、認証データ受信部３３１として機能する。

認証データ受信部３３１は、銀行サーバ１０から認証データを受信して、認証データに含まれる各種情報を表示部３２に表示する。本実施形態では、認証データには、提携先機関コード及び確認コードが含まれる。

（ＡＴＭ構成）
図５は、本発明の一実施形態に係るＡＴＭ４０の構成を示す。ＡＴＭ４０は、専用回線ＰＮを介して銀行サーバ１０と通信する機能を備えた情報処理装置である。ＡＴＭ４０は、ユーザからの入力を受け付けるタッチパネル等の入力部４１、ディスプレイ等の表示部４２、ＣＰＵ及びメモリを含む制御部４３、記憶部４４、現金の受取及び引き渡しを行うための入出金部４５、専用回線ＰＮと接続するための通信部４６並びにキャッシュカードリーダ４７を備えている。

制御部４３は、記憶部４４に記憶されているプログラムがＲＡＭに読み出され、ＣＰＵによって実行されることで、フロー制御部４３１、認証要求送信部４３２、入出金処理部４３３及び取引結果送信部４３４として機能する。

フロー制御部４３１は、入出金取引のフローを制御し、フローに応じた画面を表示部４２に表示する。フロー制御部４３１は、入力部４１を介してユーザから入出金処理開始指示を受信することに応答して、提携先機関コード、顧客コード及び確認コードを取得するための入出金処理開始画面を生成して表示部４２に表示する。

後述する認証要求送信部４３２からの認証要求の応答として、取引区分及び取引金額を含む取引指示を受信すると、フロー制御部４３１は、取引指示に基づいて、取引内容確認画面を生成して表示部４２に表示する。

認証要求送信部４３２は、銀行サーバ１０に認証要求を送信する。本実施形態では、上述したように、認証要求には、提携先機関コード、顧客コード及び確認コードが含まれる。認証要求送信部４３２は、入力部４１を介してユーザから受け付けた入力に基づいて、提携先機関コード、顧客コード及び確認コードを含む認証要求を生成して、銀行サーバ１０に送信する。

入出金処理部４３３は、入金取引時に、入出金部４５に顧客が投入した紙幣及び／又は硬貨を集計して取引指示に含まれる取引額と照合し、取引額に相当する紙幣及び／又は硬貨を収納庫に収納する。また、入出金処理部４３３は、出金取引時に、取引指示に含まれる取引額に相当する紙幣及び／又は硬貨を収納庫から繰り出して入出金部４５から放出する。入出金処理部４３３は、紙幣又は硬貨の一方を取り扱ってもよいし、紙幣と硬貨との両方を取り扱ってもよい。入出金処理部４３３は、入出金処理の完了を後述の取引結果送信部４３４に通知する。

取引結果送信部４３４は、入出金処理部４３３から入出金処理の完了通知を受け取ると、取引結果を銀行サーバ１０に送信する。前述したように、一実施形態では、取引結果には、提携先機関コード、顧客コード及び取引指示に含まれる取引通番が含まれる。

（実施形態）
図７及び図８を参照して、本発明の一実施形態に係る入出金代行処理の一例を示す。まず、図７を参照して、顧客による取引予約から、取引に必要な認証データが顧客に通知されるまでに入出金代行システム１によって実行される処理について説明する。次に、図８を参照して、顧客がＡＴＭ４０で入出金取引を行う際に入出金代行システム１によって実行される処理について説明する。

本実施形態では、プリペイド発行会社１は、入出金代行サービスを提供する銀行との間で契約を結び、代行契約ＤＢ１３１には、提携先機関コード「００１」、提携先機関名「プリペイドカード発行会社１」、デポジット口座番号「１２３４５６７」、出金枠「未設定」を含む代行契約レコードが登録されているものとする。また、デポジット口座番号「１２３４５６７」により特定される銀行サーバ１０のデポジット口座ＤＢ１３３には、３００，０００円の残高があるものとする。

顧客Ａは、プリペイドカード発行会社１が発行したプリペイドカードの利用者であり、顧客Ａについて、プリペイドカード発行会社１が管理する提携先サーバ２０の顧客ＤＢ２３１では、顧客ＩＤ「ＡＡＡ」、顧客名「顧客Ａ」、パスワード「ＸＸＸ」、メールアドレス「ＹＹＹ」のレコードが登録されている。

（取引予約から顧客への認証データ送信まで）
顧客が顧客端末３０のブラウザを用いて提携先サーバ２０の提供する入出金サービスサイトへとアクセスすると（Ｓ７０１、Ｓ７０２）、提携先サーバ２０のウェブサイト提供部２２１は、アクセスを受けたＵＲＬに応じたウェブページを顧客端末３０へと送信する（Ｓ７０３）。ウェブページを受信した顧客端末３０は、ウェブページを表示する（Ｓ７０４）。

ブラウザでの顧客の操作に応じて、ログイン画面で入力された情報を含むログイン要求が顧客端末３０から送信されると（Ｓ７０５）、提携先サーバ２０は認証処理を行う（Ｓ７０６）。本実施形態では、顧客ＩＤ「ＡＡＡ」及びパスワード「ＸＸＸ」を含むログイン要求が顧客端末３０から送信され、提携先サーバ２０は、顧客ＤＢ２３１の顧客ＩＤ「ＡＡＡ」で特定されるレコードに基づいて、ログイン要求を認証したものとする。

ブラウザでの顧客の操作に応じて、顧客端末３０から取引予約要求が送信されると（Ｓ７０７、Ｓ７０８）、提携先サーバ２０の取引データ生成部２２２は、取引予約要求に基づいて取引データを生成し、生成した取引データを銀行サーバ１０に送信する（Ｓ７０９）。本実施形態では、取引予約要求には、入金取引又は出金取引を選択可能な取引区分、及び取引金額が含まれ、取引データには、提携先機関コード、顧客コード、取引区分、取引額、顧客連絡先等が含まれる。Ｓ７０９において、提携先機関コード「００１」、顧客コード「ＡＡＡ」、取引区分「出金」、取引額「３，０００」、顧客連絡先「ＹＹＹ」を含む取引データが銀行サーバ１０に送信されたものとする。

一実施形態では、取引データ生成部２２２は、銀行サーバ１０への取引データの送信の前に、顧客ＤＢ２３１等に基づいて、顧客から申請された取引を許可するか否かを判定してもよい。

銀行サーバ１０の取引データ受付部１２３は、提携先サーバ２０から取引データを受け付けて（Ｓ７１０）、取引データの取引区分を判定する（Ｓ７１１）。取引区分が出金を示す場合（Ｓ７１１：出金）、取引データ受付部１２３は、デポジット口座ＤＢ１３３の資金の引き当てに成功するか否かを判定する。引き当てに成功すると、デポジット口座ＤＢ１３３に引き当てた資金の出金レコードを登録し（Ｓ７１２）、入出金明細レコードを登録する（Ｓ７１３）。取引区分が入金を示す場合（Ｓ７１１：入金）、Ｓ７１３に進み、取引データ受付部１２３は入出金明細レコードを登録する。

本実施形態では、取引区分が出金を示すので、取引データ受付部１２３は、提携先機関コード「００１」に関連付けられたデポジット口座番号「１２３４５６７」により特定されるデポジット口座ＤＢ１３３の残高を確認し、引き当てに成功すると判定する。よって、取引データ受付部１２３は、デポジット口座ＤＢ１３３に３，０００円の出金レコードを登録し、入出金明細ＤＢ１３２に入出金明細レコードを登録する。本実施形態では、図６（Ａ）に示される入出金明細レコードが登録されたものとする。

提携先サーバ２０の取引データ生成部２２２は、取引予約情報に基づいて、取引予約ＤＢ２３２に取引予約レコードを登録する（Ｓ７１４）。本実施形態では、取引データ生成部２２２は、提携先サーバ２０からの取引レコード受付完了通知を受け、取引予約ＤＢ２３２に、顧客コード「ＡＡＡ」、取引区分「出金」、取引額「３，０００」、予約日時「２０１７年１０月３０日１１時３０分２３秒」を含む取引予約レコードを登録したものとする。

銀行サーバ１０の認証データ送信部１２４は、入出金明細ＤＢ１３２に登録が完了した取引データについて、取引データに関連付けられる確認コードを生成して（Ｓ７１５）入出金明細ＤＢ１３２に保存する。前述したように、確認コードは、少なくとも同一顧客に対する複数の取引を識別するために用いる情報であり、提携先機関コード及び顧客コードと組み合わせることで取引を一意に識別し得る。本実施形態では、認証データ送信部１２４は、確認コード「１１１」を生成して、図６（Ｂ）に示されるように入出金明細ＤＢ１３２に保存したものとする。

続いて、認証データ送信部１２４は、取引の実行に必要な認証データを顧客端末３０に送信する（Ｓ７１６）。本実施形態では、認証データ送信部１２４は、提携先機関コード「００１」及び確認コード「１１１」を含む認証データを、顧客Ａの顧客連絡先に送信する。認証データを受信した顧客端末３０の認証データ受信部３３１は、認証データに含まれる各種情報を表示部３２に表示する（Ｓ７１７）。

（ＡＴＭ４０での取引実行）
図８は、本発明の一実施形態に係る銀行サーバ１０とＡＴＭ４０との処理の一例を示すフローチャートである。本実施形態では、認証データを顧客端末３０で受信した顧客Ａ（顧客コード：ＡＡＡ）が、ＡＴＭ４０を操作して入出金処理を開始したものとする。

ＡＴＭ４０がユーザから入出金処理開始指示を受信すると、ＡＴＭ４０のフロー制御部４３１は、提携先機関コード、顧客コード及び確認コードを取得するための入出金処理開始画面を生成して表示部４２に表示する（Ｓ８０１）。顧客Ａが、画面に沿って提携先機関コード、顧客コード及び確認コードを入力すると、ＡＴＭ４０の認証要求送信部４３２は、銀行サーバ１０に認証要求を送信する（Ｓ８０２）。本実施形態では、提携先機関コード「００１」、顧客コード「ＡＡＡ」、及び確認コード「１１１」を含む認証要求が送信されたものとする。

銀行サーバ１０が認証要求を受信すると（Ｓ８０３）、銀行サーバ１０の取引認証部１２６は、入出金取引の認証を行う（Ｓ８０４）。本実施形態では、取引認証部１２６は、入出金明細ＤＢ１３２を参照して、認証要求で特定される入出金明細レコードが存在し、かつ、特定される入出金明細レコードのステータスに「０」が設定されているか否かを判定する。

認証要求で特定される入出金明細レコードが存在し、かつ、特定された入出金明細レコードのステータスに「０」が設定されている場合、取引認証部１２６は、特定された入出金明細レコードに基づく取引指示をＡＴＭ４０に送信する（Ｓ８０５）。一方、認証要求で特定される入出金明細レコードが存在しない場合、又は特定された入出金明細レコードのステータスに「０」以外が設定されている場合、取引認証部１２６は、入出金取引処理を開始できない原因情報をＡＴＭ４０に送信する。

本実施形態では、認証要求で特定される入出金明細レコードが存在し、かつ、特定された入出金明細レコードのステータスに「０」が設定されているので、処理はＳ８０５に進み、取引認証部１２６は、取引通番「００００２」、取引区分「出金」及び取引額「３，０００」を含む取引指示をＡＴＭ４０に送信する。

ＡＴＭ４０が取引指示を受信すると（Ｓ８０６）、フロー制御部４３１は、取引指示に基づいて、取引内容確認画面を生成して表示部４２に表示する（Ｓ８０７）。本実施形態では、取引指示に基づいて、３，０００円の出金取引を実行するか否かを確認する取引内容確認画面が表示され、顧客Ａは、取引実行指示を、入力部４１を介して送信したものとする。

ＡＴＭ４０が取引実行指示を受信すると（Ｓ８０８）、ＡＴＭ４０の入出金処理部４３３は、取引指示に含まれる取引額に相当する紙幣及び／又は硬貨を収納庫から繰り出して入出金部４５から放出し（Ｓ８０９）、入出金処理の完了をＡＴＭ４０の取引結果送信部４３４に通知する。

次に、取引結果送信部４３４は、取引結果を銀行サーバ１０に送信する（Ｓ８１０）。本実施形態では、提携先機関コード「００１」、顧客コード「ＡＡＡ」、取引通番「００００２」を含む取引結果が送信されたものとする。

銀行サーバ１０が取引結果を受信すると（Ｓ８１１）、銀行サーバ１０の取引結果受付部１２７は、受信した取引結果に対応する入出金明細レコードを入出金明細ＤＢ１３２で特定して、特定した入出金明細レコードのステータスを「１」に更新する（Ｓ８１２）。ここで、取引結果受付部１２７は、受信した取引結果を、提携先サーバ２０に送信してもよい。本実施形態では、取引結果受付部１２７は、受信した取引結果に対応する入出金明細レコードを特定して、図６（Ｃ）に示されるように入出金明細ＤＢ１３２を更新する。

なお、本実施形態では、取引データ受付部１２３が、提携先機関のデポジット口座ＤＢ１３３に基づいて出金取引に対する資金の引き当てを行うことで、出金取引が可能であるか否かを判断する例について説明したが、代替の実施形態では、提携先機関の信用力や保証金等の信用情報に基づいて出金取引に対する出金余力があるかを判断して、出金取引が可能であるか否かを判断してもよい。

以上、本実施形態によれば、入出金サービスを提供するプリペイドカード発行会社１の顧客が、プリペイドカード発行会社１の提携先サーバ２０に対して要求した出金取引に基づいて、銀行サーバ１０と連携するＡＴＭ４０において当該出金取引を実行することができる。出金取引については、入出金明細ＤＢ１３２に入出金明細レコードを登録する前に資金の引き当てを行うことにより、銀行サーバ１０は、適切なリスク管理を行うことができる。

（別の実施形態）
上記した実施形態では、顧客が出金取引を行う例について説明してきた。顧客が入金取引を行う実施形態についても、図７に示されるように、顧客による取引予約から、取引に必要な認証データが顧客に通知されるまでに入出金代行システム１によって実行される処理は同一である。ただし、出金取引では、Ｓ７１２でデポジット口座ＤＢ１３３に出金レコードが登録されるのに対して、顧客が入金取引を行う実施形態では、取引予約の段階ではデポジット口座ＤＢ１３３に入金レコードは登録されない。

デポジット口座ＤＢ１３３に対する入金レコードの登録は、本実施形態では、入金取引の完了後、取引結果受付部１２７によって行われる。例えば、取引結果受付部１２７は、図８のＳ８１１の取引結果の受信に応答して、デポジット口座ＤＢ１３３に入金レコードを登録してもよいし、毎日６時００分００秒に等、一定の間隔で入出金明細レコードのステータスが「１」である入金取引を入出金明細ＤＢ１３２から抽出して、デポジット口座ＤＢ１３３に入金レコードを登録してもよい。デポジット口座ＤＢ１３３への入金レコードの登録が完了すると、取引結果受付部１２７は、入出金明細レコードのステータスを「２」に更新する。

以上、本実施形態によれば、入出金サービスを提供するプリペイドカード発行会社１の顧客が、プリペイドカード発行会社１の提携先サーバ２０に対して要求した入金取引に基づいて、銀行サーバ１０と連携するＡＴＭ４０において当該入金取引を実行することができる。入金取引については、取引実行後にデポジット口座ＤＢ１３３に入金レコードを登録することにより、銀行サーバ１０は、適切なリスク管理を行うことができる。

（追加の実施形態）
銀行サーバ１０は、登録から一定の期間を経過した未実行の入出金明細レコードを、入出金明細ＤＢ１３２から削除する期限管理部１２８を備えてもよい。出金取引に関する入出金明細レコードを入出金明細ＤＢ１３２から削除する場合、期限管理部１２８は、デポジット口座ＤＢ１３３に入金レコードを登録することで、引き当て済の資金を解除することが望ましい。一実施形態では、期限管理部１２８は、登録から３０分経過した入出金明細レコードを削除するが、入出金明細レコードを削除する時間として他の任意の期間を設定することができる。

以上、本実施形態によれば、登録から一定の期間を経過した入出金明細レコードについては無効であるとして削除することで、よりセキュアな入出金代行システム１を構築することができる。

１…入出金代行システム、１０…銀行サーバ、１１…入力部、１２…制御部、１２１…演算処理部、１２３…取引データ受付部、１２４…認証データ送信部、１２５…デポジット受付部、１２６…取引認証部、１２７…取引結果受付部、１２８…期限管理部、１２９…請求データ生成部、１２２…メモリ、１３…記憶部、１３１…代行契約ＤＢ、１３２…入出金明細ＤＢ、１３３…デポジット口座ＤＢ、１４…通信部、２０…提携先サーバ、２１…入力部、２２…制御部、２２１…ウェブサイト提供部、２２２…取引データ生成部、２３…記憶部、２３１…顧客ＤＢ、２３２…取引予約ＤＢ、２４…通信部、３０…顧客端末、３１…入力部、３２…表示部、３３…制御部、３３１…認証データ受信部、３４…記憶部、３５…通信部、４０…ＡＴＭ、４１…入力部、４２…表示部、４３…制御部、４３１…フロー制御部、４３２…認証要求送信部、４３３…入出金処理部（処理部）、４３４…取引結果送信部、４４…記憶部、４５…入出金部、４６…通信部、Ｎ…ネットワーク、ＰＮ…専用回線

Claims (12)

1. 入出金サービスを提供する提携先のサーバから、提携先情報、入出金サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、入出金明細レコードを登録する取引データ受付部であって、前記提携先のサーバは、前記利用者からの要求に応じて前記取引データを送信する、取引データ受付部と、
   前記入出金明細レコードに関連付けられた確認コードを前記利用者の連絡先に送信する認証データ送信部と、
   入出金装置から、前記提携先情報、前記利用者の情報及び前記確認コードを含む認証要求を受信して、当該認証要求により特定される入出金明細レコードが存在するか否かを判定する取引認証部であって、入出金明細レコードが存在する場合、前記特定された入出金明細レコードの前記取引情報を前記入出金装置に送信する、取引認証部と、
   前記入出金装置から取引結果を受信して、当該取引結果により特定される入出金明細レコードを更新する取引結果受付部と
   を備えた取引サーバ。
2. 登録から一定の期間を経過した未実行の入出金明細レコードを削除する期限管理部をさらに備えた請求項１に記載の取引サーバ。
3. 前記取引情報が出金取引を示す場合、前記取引データ受付部は、前記提携先に関連付けられた記憶部に基づいて、前記出金取引に対する資金の引き当てに成功する場合に、前記入出金明細レコードを登録する、請求項１に記載の取引サーバ。
4. 前記取引データ受付部は、前記出金取引に対する資金の引き当てに成功する場合に、前記取引情報に基づいて前記記憶部に出金レコードを登録する、請求項３に記載の取引サーバ。
5. 前記取引情報が入金取引を示す場合、前記取引結果受付部は、前記取引結果に基づいて前記提携先に関連付けられた記憶部に入金レコードを登録する、請求項１に記載の取引サーバ。
6. 前記取引情報が出金取引を示す場合、前記取引データ受付部は、前記提携先に関連付けられた信用情報に基づいて、前記出金取引に対する出金余力がある場合に、前記入出金明細レコードを登録する、請求項１に記載の取引サーバ。
7. 前記取引データ受付部は、前記出金取引に対する出金余力がある場合に、前記取引情報に基づいて前記提携先に関連付けられた記憶部に出金レコードを登録する、請求項６に記載の取引サーバ。
8. コンピュータが実行する入出金代行方法であって、
   入出金サービスを提供する提携先のサーバから、提携先情報、入出金サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、入出金明細レコードを登録する工程であって、前記提携先のサーバは、前記利用者からの要求に応じて前記取引データを送信する、工程と、
   前記入出金明細レコードに関連付けられた確認コードを前記利用者の連絡先に送信する工程と、
   入出金装置から、前記提携先情報、前記利用者の情報及び前記確認コードを含む認証要求を受信して、当該認証要求により特定される入出金明細レコードが存在するか否かを判定する工程であって、入出金明細レコードが存在する場合、前記特定された入出金明細レコードの前記取引情報を前記入出金装置に送信する、工程と、
   前記入出金装置から取引結果を受信して、当該取引結果により特定される入出金明細レコードを更新する工程と
   を含む方法。
9. コンピュータに、
   入出金サービスを提供する提携先のサーバから、提携先情報、入出金サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、入出金明細レコードを登録する工程であって、前記提携先のサーバは、前記利用者からの要求に応じて前記取引データを送信する、処理と、
   前記入出金明細レコードに関連付けられた確認コードを前記利用者の連絡先に送信する処理と、
   入出金装置から、前記提携先情報、前記利用者の情報及び前記確認コードを含む認証要求を受信して、当該認証要求により特定される入出金明細レコードが存在するか否かを判定する処理であって、入出金明細レコードが存在する場合、前記特定された入出金明細レコードの前記取引情報を前記入出金装置に送信する、処理と、
   前記入出金装置から取引結果を受信して、当該取引結果により特定される入出金明細レコードを更新する処理と
   を実行させるプログラム。
10. 入出金サービスを提供する提携先の情報、入出金サービスを利用する利用者の情報及び確認コードを含む認証要求を取引サーバに送信する認証要求送信部であって、前記確認コードは、前記取引サーバから前記利用者の連絡先に通知されたものである、認証要求送信部と、
    前記認証要求の応答として前記取引サーバから受信した取引情報に基づいて、入出金処理を実行する入出金処理部と、
    取引結果を前記取引サーバに送信する取引結果送信部と、
    を備え、
    前記提携先のサーバは、前記利用者からの要求に応じて、前記提携先の情報、前記利用者の情報及び前記取引情報を含む取引データを送信し、
    前記取引サーバは、受信した前記取引データに関連付けられた前記確認コードを前記利用者の連絡先に送信する、入出金装置。
11. サービスを提供する提携先のサーバから、提携先情報、サービスを利用する利用者の情報及び取引情報を含む取引データを受け付けて、サービス明細レコードを登録する取引データ受付部であって、前記提携先のサーバは、前記利用者からの要求に応じて前記取引データを送信する、取引データ受付部と、
    前記サービス明細レコードに関連付けられた確認コードを前記利用者の連絡先に送信する認証データ送信部と、
    入出金装置から、前記提携先情報、前記利用者の情報及び前記確認コードを含む認証要求を受信して、当該認証要求により特定されるサービス明細レコードが存在するか否かを判定する取引認証部であって、サービス明細レコードが存在する場合、前記特定されたサービス明細レコードの前記取引情報を前記入出金装置に送信する、取引認証部と、
    前記入出金装置から取引結果を受信して、当該取引結果により特定されるサービス明細レコードを更新する取引結果受付部と
    を備えた取引サーバ。
12. サービスを提供する提携先の情報、サービスを利用する利用者の情報及び確認コードを含む認証要求を取引サーバに送信する認証要求送信部であって、前記確認コードは、前記取引サーバから前記利用者の連絡先に通知されたものである、認証要求送信部と、
    前記認証要求の応答として前記取引サーバから受信した取引情報に基づいて、処理を実行する処理部と、
    取引結果を前記取引サーバに送信する取引結果送信部と、
    を備え、
    前記提携先のサーバは、前記利用者からの要求に応じて、前記提携先の情報、前記利用者の情報及び前記取引情報を含む取引データを送信し、
    前記取引サーバは、受信した前記取引データに関連付けられた前記確認コードを前記利用者の連絡先に送信する、入出金装置。

Images