JP7430696B2 - 入出金制御システム、入出金制御方法、及びプログラム - Google Patents
入出金制御システム、入出金制御方法、及びプログラム Download PDFInfo
- Publication number
- JP7430696B2 JP7430696B2 JP2021201626A JP2021201626A JP7430696B2 JP 7430696 B2 JP7430696 B2 JP 7430696B2 JP 2021201626 A JP2021201626 A JP 2021201626A JP 2021201626 A JP2021201626 A JP 2021201626A JP 7430696 B2 JP7430696 B2 JP 7430696B2
- Authority
- JP
- Japan
- Prior art keywords
- account
- deposit
- bank
- withdrawal
- online
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 21
- 238000000151 deposition Methods 0.000 claims description 13
- 239000008186 active pharmaceutical agent Substances 0.000 description 47
- 238000013500 data storage Methods 0.000 description 42
- 238000010586 diagram Methods 0.000 description 19
- 238000004891 communication Methods 0.000 description 15
- 230000008569 process Effects 0.000 description 11
- 238000012545 processing Methods 0.000 description 10
- 238000012546 transfer Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 6
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 238000007726 management method Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 2
- 230000006735 deficit Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Description
本発明は、入出金制御システム、入出金制御方法、及びプログラムに関する。
従来、複数の金融機関が互いに連携して金融サービスを提供することが検討されている。例えば、特許文献1には、銀行が証券会社と連携するための証券仲介システムに、銀行口座を有する顧客の顧客情報と、銀行口座の口座情報と、が格納されたデータベースを用意し、顧客の端末から証券口座の開設要求があった場合に、データベースの中から、顧客情報に関連付けられた口座情報を取得し、証券会社との有価証券取引の決済を行うための銀行口座を決済口座として選択することが記載されている。
しかしながら、特許文献1の証券仲介システムは、証券会社と連携済みの銀行しか利用することができないので、これから証券会社と連携しようとする銀行は、新たに証券仲介システムを導入する必要がある。この点、業務内容が異なる銀行と証券会社を連携させようとすると、業務内容が似ている銀行同士を連携させる場合に比べて導入コストがかかる。このため、特許文献1の技術において、銀行ごとに証券仲介システムを導入しようとすると、膨大な導入コストがかかってしまう。
本開示の目的は、金融機関と金融商品取引業者とを連携させる際の導入コストを軽減することが可能な入出金制御システム、入出金制御方法、及びプログラムを提供することである。
上記課題を解決するために、本発明の一態様に係る入出金制御システムは、第1金融機関に開設されたユーザの第1口座と、少なくとも前記第1金融機関と連携する第2金融機関に開設された前記ユーザの第2口座と、が関連付けられた第1連携情報を取得する第1取得手段と、前記第2口座と、少なくとも前記第2金融機関と連携する金融商品取引業者に開設された前記ユーザの第3口座と、が関連付けられた第2連携情報を取得する第2取得手段と、前記第1連携情報と前記第2連携情報とに基づいて、前記第2口座を介して行われる、前記第1口座と前記第3口座との間の入出金を制御する入出金制御手段と、を含むことを特徴とする。
[1.入出金制御システムの全体構成]
以下、本発明に係る実施形態の例について図面に基づき詳細に説明する。図1は、実施形態に係る入出金制御システムの一例を示す図である。本実施形態では、入出金制御システムの一例として、図1に示すネット銀行システム2を説明する。このため、本実施形態でネット銀行システム2と記載した箇所は、入出金制御システムと読み替えることができる。
以下、本発明に係る実施形態の例について図面に基づき詳細に説明する。図1は、実施形態に係る入出金制御システムの一例を示す図である。本実施形態では、入出金制御システムの一例として、図1に示すネット銀行システム2を説明する。このため、本実施形態でネット銀行システム2と記載した箇所は、入出金制御システムと読み替えることができる。
図1に示すように、本実施形態では、地方銀行システム1、ネット銀行システム2、ネット証券システム3、及びユーザ端末40の各々が、インターネットなどのネットワークNに接続可能となっている。なお、図1では、これらを1つずつ示しているが、これらは複数存在してもよい。
地方銀行システム1は、地方銀行が管理するシステムである。地方銀行は、第1金融機関の一例である。このため、本実施形態で地方銀行と記載した箇所は、第1金融機関と読み替えることができる。金融機関は、任意の種類であってよく、例えば、いわゆる預貯金取扱金融機関である。例えば、金融機関は、銀行、信用金庫、信用協同組合、労働金庫、又は農林中央金庫などである。銀行は、任意の種類であってよく、例えば、都市銀行、地方銀行、ネット銀行、又は信託銀行である。第1金融機関は、地方銀行以外の銀行であってもよい。
地方銀行システム1は、地方銀行サーバ10を含む。地方銀行サーバ10は、サーバコンピュータである。例えば、地方銀行サーバ10は、制御部11、記憶部12、及び通信部13を含む。制御部11は、例えば、少なくとも1つのプロセッサを含む。記憶部12は、例えば、RAM等の主記憶部やハードディスク等の補助記憶部を含む。制御部11は、記憶部12に記憶されたプログラムやデータに従って処理を実行する。通信部13は、有線通信又は無線通信用の通信インタフェースを含む。なお、地方銀行システム1には、他のコンピュータが含まれていてもよい。例えば、地方銀行システム1には、他のサーバコンピュータが含まれていてもよいし、地方銀行の行員が操作する端末が含まれていてもよい。
ネット銀行システム2は、ネット銀行が管理するシステムである。ネット銀行は、店舗を持たず、インターネット上での取引を中心として営業する銀行である。ネット銀行は、第2金融機関の一例である。このため、本実施形態でネット銀行と記載した箇所は、第2金融機関と読み替えることができる。第2金融機関は、第1金融機関とは異なる金融機関である。金融機関の意味は先述した通りである。第2金融機関は、任意の種類であってよく、例えば、ネット銀行以外の銀行が第2金融機関に相当してもよいし、銀行以外の金融機関が第2金融機関に相当してもよい。
ネット銀行システム2は、ネット銀行サーバ20を含む。ネット銀行サーバ20は、サーバコンピュータである。例えば、ネット銀行サーバ20は、制御部21、記憶部22、及び通信部23を含む。制御部21、記憶部22、及び通信部23のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。なお、ネット銀行システム2には、他のコンピュータが含まれていてもよい。例えば、ネット銀行システム2には、他のサーバコンピュータが含まれていてもよいし、ネット銀行の行員が操作する端末が含まれていてもよい。
ネット証券システム3は、ネット証券が管理するシステムである。ネット証券は、店舗を持たず、インターネット上での取引を中心として営業する証券会社である。ネット証券は、金融商品取引業者の一例である。このため、本実施形態でネット証券と記載した箇所は、金融商品取引業者と読み替えることができる。金融商品取引業者は、任意の種類であってよく、例えば、第1種金融商品取引業を行う者であってもよいし、第2種金融商品取引業を行う者であってもよい。金融商品取引業者は、ネット証券以外の証券会社であってもよく、例えば、実店舗を有する証券会社であってもよい。
ネット証券システム3は、ネット証券サーバ30を含む。ネット証券サーバ30は、サーバコンピュータである。例えば、ネット証券サーバ30は、制御部31、記憶部32、及び通信部33を含む。制御部31、記憶部32、及び通信部33のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。なお、ネット証券システム3には、他のコンピュータが含まれていてもよい。例えば、ネット証券システム3には、他のサーバコンピュータが含まれていてもよいし、ネット証券の行員が操作する端末が含まれていてもよい。
ユーザ端末40は、ユーザが操作するコンピュータである。例えば、ユーザ端末40は、パーソナルコンピュータ、スマートフォン、又はタブレット型端末である。ユーザ端末40は、制御部41、記憶部42、通信部43、操作部44、及び表示部45を含む。制御部41、記憶部42、及び通信部43のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。操作部44は、タッチパネルやマウスなどの入力デバイスである。表示部45は、液晶ディスプレイ又は有機ELディスプレイである。
なお、地方銀行サーバ10、ネット銀行サーバ20、ネット証券サーバ30、及びユーザ端末40の各々に記憶されるものとして説明するプログラム及びデータは、ネットワークNを介してこれらに供給されてもよい。また、これらのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)や外部機器と直接的に接続するための入出力部(例えば、USB端子)が含まれていてもよい。この場合、情報記憶媒体に記憶されたプログラムやデータが読取部又は入出力部を介して供給されてもよい。
[2.実施形態に係る入出金制御の概要]
本実施形態では、ネット銀行システム2とネット証券システム3は、互いに連携しており、入出金サービスがユーザに提供される。この入出金サービスは、ネット銀行の口座とネット証券の口座との間における入出金を実行するサービスである。入出金サービスは、口座連携サービスと呼ばれることもある。入出金サービスを利用するユーザは、ネット銀行とネット証券の各々に口座を開設する。
本実施形態では、ネット銀行システム2とネット証券システム3は、互いに連携しており、入出金サービスがユーザに提供される。この入出金サービスは、ネット銀行の口座とネット証券の口座との間における入出金を実行するサービスである。入出金サービスは、口座連携サービスと呼ばれることもある。入出金サービスを利用するユーザは、ネット銀行とネット証券の各々に口座を開設する。
例えば、入出金サービスでは、ユーザがネット証券で買い注文をした場合に、ネット証券のユーザの口座(預り金)の残高(資金)が不足していると、ネット証券システム3からネット銀行システム2に対し、ネット銀行のユーザの口座から出金するための出金要求が送信される。この出金要求は、ユーザの買い注文をするための不足資金を補充するための要求である。
ネット銀行システム2は、出金要求に応じてネット銀行のユーザの口座から出金する。この出金は、買い注文をしたユーザのネット証券の口座に入金され、不足資金が補充される。不足資金が補充されると、ユーザが指定した内容に基づいて、買い注文が行われる。なお、ネット銀行の口座の残高は、ユーザが指定した金額は留めおくようにしてもよい。また、ネット証券システム3は、ネット銀行システム2に対し、ネット銀行のユーザの口座の残高照会を送信し、この口座の残高が不足金額以上だった場合に出金要求を送信してもよい。
また例えば、入出金サービスでは、夜間などの所定の入出金タイミングが訪れると、ネット証券システム3は、ネット証券のユーザの口座から出金する。ネット証券システム3は、ネット証券の口座残高の全額を出金してもよいし、ユーザが指定した金額は留めおくようにしてもよい。この出金は、ネット銀行のユーザの口座に入金される。
以上のように、ネット銀行とネット証券の両方に口座を開設しているユーザに対し、入出金サービスが提供される。ネット銀行システム2とネット証券システム3との間の入出金サービスを実現する方法自体は、公知の方法を利用可能であり、例えば、これらの間で自動的に入出金を実行するためのAPIによって実現される。
本実施形態では、地方銀行のユーザに対しても、入出金サービスが提供される。即ち、入出金サービスに係る機能は、ネット銀行とネット証券だけでなく、地方銀行に対しても公開されている。地方銀行は、当該公開された入出金サービスを利用して、地方銀行の口座とネット証券の口座との間における入出金を実行するサービスを、地方銀行のユーザに提供することができる。
ただし、地方銀行に提供されるのは、あくまでネット銀行の口座とネット証券の口座との間における入出金サービスに係る機能である。例えば、ネット銀行が、宝くじや公営競技くじの購入といった他のサービスを提供している場合に、本実施形態では、ネット銀行の全ての機能が地方銀行に提供されるのではなく(ネット銀行の全てのサービスについて地方銀行と連携するのではなく)、ネット証券との間における入出金サービスに係る機能が地方銀行に提供される場合について説明する。このため、地方銀行の口座とネット証券の口座との間で直接的に入出金が実行されるのではなく、ネット銀行の口座を介して、地方銀行の口座とネット証券の口座との間で間接的に入出金が実行されるようになっている。ネット銀行の口座は、地方銀行の口座とネット証券の口座との間の入出金を仲介するハブのような役割を果たす。なお、地方銀行には、宝くじや公営競技くじの購入といったネット銀行の他のサービスが提供されてもよい。この点は、後述の変形例で説明する。
ここでは、入出金サービスを利用していない地方銀行のユーザが、新たに入出金サービスの利用を開始する場合を例に挙げて、地方銀行の口座とネット証券の口座との間の入出金の流れを説明する。例えば、ユーザは、地方銀行をメインバンクとして利用しており、ネット銀行とネット証券には口座を開設していないものとする。ユーザは、地方銀行の店舗を訪れたり、地方銀行システム1にアクセスしたりして、入出金サービスの申込手続を行う。地方銀行は、ネット銀行とネット証券の各々に対して口座開設を要求し、ネット銀行とネット証券の各々に、ユーザの口座が開設される。
口座開設自体は、公知の手順に沿って行われるようにすればよい。本実施形態では、ネット銀行には、地方銀行専用の支店が存在し、その支店にユーザの口座が開設されるようになっている。専用支店は、いわゆる法人支店であり、地方銀行の名前の全部又は一部が支店名に含まれている。地方銀行の専用支店には、地方銀行が許可したユーザだけが口座を開設することができ、他の銀行等が勝手に口座を開設できないようになっている。一方、ネット証券については、通常の口座開設の手順に沿って口座が開設される。口座開設が完了すると、地方銀行の口座、ネット銀行の口座、及びネット証券の口座の各々が互いに関連付けられて、入出金サービスを利用することができるようになる。
図2は、実施形態に係る入出金サービスの一例を示す図である。図2の例では、ユーザU1のメインバンクが地方銀行Aであり、ユーザU2のメインバンクが地方銀行Bであり、ユーザU3のメインバンクが地方銀行Cであるものとする。これらのユーザU1~U3の各々は、自身がメインバンクとする地方銀行A~Cに口座A1~C3を開設している。
なお、図2に示すユーザU4は、ネット銀行Xをメインバンクとしており、ネット銀行Xの本店に口座X4を開設している。ユーザU4は、地方銀行には口座を開設していないものとする。ユーザU4は、ネット証券Yに口座Y4を有しており、ネット銀行Xとネット証券Yとの間の従来型の入出金サービスを利用する。この入出金サービスにおける入出金は、ネット銀行システム2とネット証券システム3との二者で実行される。この入出金の流れについては先述した通りである。
ユーザU1~U3の各々は、入出金サービスの申込手続を済ませており、ネット銀行Xとネット証券Yの各々に口座X1~X3,Y1~Y3を開設している。先述したように、ネット銀行Xは、地方銀行ごとに専用支店が存在する。一方、ネット証券Yについては、既存の入出金サービスを利用するユーザU4と同様の口座が開設されており、地方銀行の専用支店のような概念はないものとする。
例えば、地方銀行AをメインバンクとするユーザU1は、ネット銀行XのA支店(地方銀行Aの専用支店)に口座を開設する。また例えば、地方銀行BをメインバンクとするユーザU2は、ネット銀行XのB支店(地方銀行Bの専用支店)に口座を開設する。また例えば、地方銀行CをメインバンクとするユーザU3は、ネット銀行XのC支店(地方銀行Cの専用支店)に口座を開設する。本実施形態では、これらの口座は、残高が0円で固定されており、それ以上は増えないように制限されている。
例えば、ユーザU1がネット証券Yで買い注文をした場合に、ネット証券YのユーザU1の口座の資金が不足していると、ネット証券システム3からネット銀行システム2に対し、ネット銀行Xの口座X1からの出金要求が送信される。この出金要求は、既存の入出金サービスのAPIを利用して行われる。ネット銀行Xは、出金要求を受け付けると、地方銀行システム1に対し、地方銀行Aの口座A1からの出金要求を送信する。この出金要求は、地方銀行システム1とネット銀行システム2との間のAPIを利用して行われる。
地方銀行Aの地方銀行システム1は、出金要求に応じて地方銀行Aの口座A1から不足資金に応じた額の出金を行い、ネット銀行Xの口座X1に入金する。この入出金は、地方銀行システム1とネット銀行システム2との間のAPIを利用して行われる。先述したように、ネット銀行Xの口座X1は、残高が0円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。
ネット銀行システム2は、地方銀行Aの口座A1からネット銀行Xの口座X1への入金を、ネット証券Yの口座Y1に入金する。即ち、地方銀行Aの口座A1からネット銀行Xの口座X1に入金されると、口座X1の残高が増加することなく、ネット銀行Xの口座X1への入金が即座にそのままネット証券Yの口座Y1に入金される。この入金は、既存の入出金サービスのAPIを利用して行われる。ネット証券Yの口座Y1は、不足資金に応じた額が増えるので、ユーザの指定した内容で買い注文を実行可能となる。
以上のように、ネット銀行Xの口座X1を介して、地方銀行Aの口座A1からネット証券Yの口座Y1に、ユーザの買い注文における不足資金が自動的に入金される。図2に示すように、ユーザU2,U3についても、ユーザU1と同様の流れで、ネット銀行Xを介して、地方銀行B,Cからネット証券Yに不足資金が入金される。ネット銀行XのB,C支店における口座X2,X3についても、残高が0円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。
また例えば、夜間などの所定の入出金タイミングが訪れると、ネット証券Yから地方銀行A~Cの各々への入金が実行される。ユーザU1を例に挙げて説明すると、ネット証券システム3は、入出金タイミングが訪れると、ネット証券Yの口座Y1の全部又は一部を出金し、ネット銀行Xの口座X1に入金される。この入金は、既存の入出金サービスのAPIを利用して行われる。先述したように、ネット銀行Xの口座X1は、残高が0円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。
ネット銀行システム2は、ネット証券Yの口座Y1からネット銀行Xの口座X1への入金を、地方銀行Aの口座A1に入金する。即ち、ネット証券Yの口座Y1からネット銀行Xの口座X1に入金されると、口座X1の残高が増加することなく、ネット銀行Xの口座X1への入金が即座にそのまま地方銀行Aの口座A1に入金される。これにより、ユーザは、ネット証券Yにおける売買で得た資金を地方銀行Aの口座A1に移動させることができる。
図2に示すように、ユーザU2,U3についても、ユーザU1と同様の流れで、ネット銀行Xを介して、ネット証券Yから地方銀行B,Cに資金が入金される。ネット銀行XのB,C支店におけるユーザU2,U3の口座X2,X3についても、残高が0円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。
以上のように、本実施形態では、ネット銀行Xとネット証券Yとの間の入出金サービスに係る機能が地方銀行A~Cに公開されている。この入出金サービスに係る機能を利用して、ネット銀行Xを介して、地方銀行A~Cとネット証券Yとの間の入出金を実現することによって、地方銀行A~Cとネット証券Yとを連携させる際の導入コストを軽減するようにしている。以降、本実施形態において実現される機能等の詳細について説明する。
[3.本実施形態において実現される機能]
図3は、本実施形態において実現される機能を示す機能ブロック図である。本実施形態では、地方銀行システム1、ネット銀行システム2、及びネット証券システム3の各々で実現される場合を説明する。
図3は、本実施形態において実現される機能を示す機能ブロック図である。本実施形態では、地方銀行システム1、ネット銀行システム2、及びネット証券システム3の各々で実現される場合を説明する。
[3-1.地方銀行システム]
地方銀行システム1は、データ記憶部100と入出金制御部101とを備えている。データ記憶部100は、記憶部12を主として実現され、入出金制御部101は、制御部11を主として実現される。
地方銀行システム1は、データ記憶部100と入出金制御部101とを備えている。データ記憶部100は、記憶部12を主として実現され、入出金制御部101は、制御部11を主として実現される。
[データ記憶部]
データ記憶部100は、地方銀行の業務で必要なデータを記憶する。例えば、データ記憶部100は、入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、地方銀行の口座データベースDB1について説明する。
データ記憶部100は、地方銀行の業務で必要なデータを記憶する。例えば、データ記憶部100は、入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、地方銀行の口座データベースDB1について説明する。
図4は、地方銀行の口座データベースDB1のデータ格納例を示す図である。図4に示すように、口座データベースDB1は、地方銀行に開設された口座に関する各種情報が格納されるデータベースである。例えば、口座データベースDB1には、支店コード、支店名、口座の預金種別、口座番号、名義人、及び残高等の情報が格納される。本実施形態では、入出金サービスを利用するユーザの預金種別は普通口座であるものとするが、他の種別の口座であってもよい。
口座データベースDB1には、地方銀行の全ての口座の情報が格納されてもよいし、入出金サービスを利用するユーザの口座の情報だけが格納されてもよい。口座データベースDB1には、他の情報が格納されていてもよく、例えば、ユーザの入出金の履歴、又は、入出金サービスの利用有無を示す情報が格納されていてもよい。
なお、データ記憶部100が記憶するデータは、上記の例に限られない。例えば、データ記憶部100は、地方銀行の口座とネット銀行の口座との間で入出金を実行するためのAPIのデータを記憶してもよい。また例えば、データ記憶部100は、地方銀行とネット銀行が連携するためのデータ(例えば、残高照会のAPIのデータ)を記憶してもよい。
[入出金制御部]
入出金制御部101は、地方銀行の口座とネット銀行の口座との間の入出金を制御する。例えば、入出金制御部101は、所定の出金要求を受信すると、当該出金要求に基づいて、地方銀行の口座から出金し、口座の残高を出金額に応じた額だけ減少させる。出金要求は、出金対象となる口座の口座情報、出金額、及び入金対象となる口座の口座情報が含まれるものとする。出金対象となる口座は、出金元となる口座であり、出金によって残高が減少する口座である。入金対象となる口座は、入金先となる口座であり、入金によって残高が増加する口座である。
入出金制御部101は、地方銀行の口座とネット銀行の口座との間の入出金を制御する。例えば、入出金制御部101は、所定の出金要求を受信すると、当該出金要求に基づいて、地方銀行の口座から出金し、口座の残高を出金額に応じた額だけ減少させる。出金要求は、出金対象となる口座の口座情報、出金額、及び入金対象となる口座の口座情報が含まれるものとする。出金対象となる口座は、出金元となる口座であり、出金によって残高が減少する口座である。入金対象となる口座は、入金先となる口座であり、入金によって残高が増加する口座である。
口座情報は、口座を識別可能な情報であり、例えば、支店コードと口座番号が格納される。口座情報には、口座を識別可能な情報が格納されるようにすればよく、金融機関コードや名義人などの他の情報が格納されてもよい。例えば、地方銀行システム1に対する出金要求には、出金対象となる地方銀行の口座の支店コードと口座番号、出金額、及び入金対象となるネット証券の口座の支店コードと口座番号が含まれるものとする。
入出金制御部101は、出金要求を参照し、出金対象となる口座の口座情報を特定する。入出金制御部101は、当該特定した口座から、出金要求に応じた額を出金して残高を減少させる。入出金制御部101は、出金要求を参照し、入金先となる口座の口座情報を特定する。入出金制御部101は、当該特定した口座を管理するネット銀行システム2に対し、入金要求を送信する。入金要求は、入金対象となる口座の口座情報、出金額、及び出金対象となる口座の口座情報が含まれるものとする。入金対象と出金対象の意味は先述した通りである。入金要求が送信されると、ネット銀行システム2の入出金制御部204により、ネット銀行の口座への入金が実行される。
また例えば、入出金制御部101は、所定の入金要求を受信すると、当該入金要求に基づいて、地方銀行の口座に入金し、口座の残高を入金額に応じた額だけ増加させる。この入金要求に含まれる入金対象の口座情報は、地方銀行の口座情報となる。入出金制御部101は、入金要求を参照し、入金先となる地方銀行の口座の口座情報を特定する。入出金制御部101は、当該特定した口座情報が示す地方銀行の口座に入金することになる。
[3-2.ネット銀行システム]
ネット銀行システム2は、データ記憶部200、口座開設部201、第1取得部202、第2取得部203、及び入出金制御部204を備えている。データ記憶部200は、記憶部22を主として実現され、他の各機能は、制御部21を主として実現される。
ネット銀行システム2は、データ記憶部200、口座開設部201、第1取得部202、第2取得部203、及び入出金制御部204を備えている。データ記憶部200は、記憶部22を主として実現され、他の各機能は、制御部21を主として実現される。
[データ記憶部]
データ記憶部200は、ネット銀行の業務で必要なデータを記憶する。例えば、データ記憶部は、入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、ネット銀行の口座データベースDB2、第1連携データベースDB3、及び第2連携データベースDB4について説明する。
データ記憶部200は、ネット銀行の業務で必要なデータを記憶する。例えば、データ記憶部は、入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、ネット銀行の口座データベースDB2、第1連携データベースDB3、及び第2連携データベースDB4について説明する。
図5は、ネット銀行の口座データベースDB2のデータ格納例を示す図である。図5に示すように、口座データベースDB2は、ネット銀行に開設された口座に関する各種情報が格納されるデータベースである。例えば、口座データベースDB2には、ネット銀行における支店を一意に識別する支店コード、支店名、口座の預金種別、口座番号、名義人、及び残高等の情報が格納される。本実施形態では、入出金サービスを利用するユーザの預金種別は普通口座であるものとするが、他の種別の口座であってもよい。
口座データベースDB2には、ネット銀行の全ての口座の情報が格納されてもよいし、入出金サービスを利用するユーザの口座の情報だけが格納されてもよい。口座データベースDB2には、他の情報が格納されていてもよく、例えば、ユーザの入出金の履歴、入出金サービスの利用有無を示す情報、又は口座の残高が増えないように制限されていることを識別する情報が格納されていてもよい。
図6は、第1連携データベースDB3のデータ格納例を示す図である。図6に示すように、第1連携データベースDB3は、地方銀行とネット銀行との間の入出金を実現するためのデータベースである。例えば、第1連携データベースDB3には、地方銀行の金融機関コード、地方銀行の口座情報、及びネット銀行の口座情報が関連付けられている。本実施形態では、複数の地方銀行によって入出金サービスが提供されるので、第1連携データベースDB3には、地方銀行ごとに、地方銀行の口座情報とネット銀行の口座情報の組み合わせが格納されることになる。
第1連携データベースDB3には、入出金サービスを利用するユーザごとに、地方銀行の口座の口座情報と、ネット銀行の口座の口座情報と、が関連付けられている。関連付けとは、一の情報から他の情報を検索可能にすることである。本実施形態では、第1連携データベースDB3の同じレコードに情報を格納することが関連付けることに相当する。
なお、本実施形態では、複数の地方銀行の各々のユーザの口座情報が、1つの第1連携データベースDB3に格納されている場合を説明するが、地方銀行ごとに、第1連携データベースDB3が用意されていてもよい。即ち、データ記憶部100は、複数の地方銀行にそれぞれ対応する複数の第1連携データベースDB3を記憶してもよい。
図7は、第2連携データベースDB4のデータ格納例を示す図である。図7に示すように、第2連携データベースDB4は、ネット銀行とネット証券との間の入出金を実現するためのデータベースである。例えば、第2連携データベースDB4には、ネット銀行の口座情報と、ネット証券の口座情報と、が関連付けられている。口座情報の意味は先述した通りである。
ネット証券については、支店コードの代わりに部店コードが格納される場合を説明するが、ネット証券についても支店コードが用いられてもよい。第2連携データベースDB4には、入出金サービスを利用するユーザごとに、ネット銀行の口座の口座情報と、ネット証券の口座の口座情報と、が関連付けられている。第2連携データベースDB4には、入出金サービスを利用するユーザごとに、ネット銀行の口座情報とネット証券の口座情報の組み合わせが格納されることになる。
なお、データ記憶部200が記憶するデータは、上記の例に限られない。例えば、データ記憶部200は、地方銀行の口座とネット証券の口座との間の入出金を仲介するためのAPIのデータを記憶してもよい。また例えば、データ記憶部100は、地方銀行とネット銀行が連携するためのデータ(例えば、残高照会のAPIのデータ)と、ネット銀行とネット証券が連携するためのデータ(例えば、残高照会のAPIのデータ)と、を記憶してもよい。
[口座開設部]
口座開設部201は、ネット銀行に口座を開設する。先述したように、口座の開設自体は、公知の処理を適用可能である。本実施形態では、口座データベースDB2に新たなレコードを作成し、新たに開設された口座の支店コードや口座番号といった情報を格納することが、口座を開設することに相当する。これらの情報は、ネット証券の行員が入力してもよいし、ユーザによって指定されてもよい。口座番号については、所定の採番ルールに基づいて自動的に採番されてもよい。
口座開設部201は、ネット銀行に口座を開設する。先述したように、口座の開設自体は、公知の処理を適用可能である。本実施形態では、口座データベースDB2に新たなレコードを作成し、新たに開設された口座の支店コードや口座番号といった情報を格納することが、口座を開設することに相当する。これらの情報は、ネット証券の行員が入力してもよいし、ユーザによって指定されてもよい。口座番号については、所定の採番ルールに基づいて自動的に採番されてもよい。
本実施形態では、ネット銀行には、地方銀行の専用支店が存在し、口座開設部201は、地方銀行によりユーザの口座開設が許可された場合に、専用支店に口座を開設する。本実施形態では、ネット銀行は複数の地方銀行と連携し、ネット銀行には、地方銀行ごとに専用支店が存在するので、口座開設部201は、複数の地方銀行のうち、ユーザの口座開設を許可した地方銀行の専用支店に、ネット銀行の口座を開設する。
口座開設部201は、地方銀行により口座の開設が許可されたことを条件として、その地方銀行の専用支店に口座を開設する。口座開設部201は、地方銀行によりユーザの口座開設が許可されない場合には、その地方銀行の専用支店に口座を開設せず、口座開設部201は、地方銀行によりユーザの口座開設が許可された場合に、その地方銀行の専用支店に口座を開設する。
例えば、地方銀行により口座の開設が許可された場合に、地方銀行システム1からネット銀行システム2に対し、所定の口座開設要求が送信される。口座開設要求は、口座を開設するための要求であり、所定のデータ形式の情報が送信されることによって行われる。口座開設要求は、口座を開設するために必要な情報を含んでおり、例えば、支店コード、支店名、預金種別、名義人、住所、及び電話番号といった情報が含まれている。例えば、口座開設求は、地方銀行の行員が所定の操作を行った場合に送信されてもよいし、地方銀行システム1において口座開設の審査に合格した場合に自動的に送信されてもよい。
[第1取得部]
第1取得部202は、地方銀行に開設されたユーザの口座と、少なくとも地方銀行と連携するネット銀行に開設された口座と、が関連付けられた第1連携情報を取得する。本実施形態では、地方銀行は、ネット銀行と直接的に連携する。地方銀行は、ネット証券については、ネット銀行を介して間接的に連携する。連携とは、業務上の協力関係にあることであり、例えば、APIを利用して入出金を可能にすることである。地方銀行は、ネット銀行及びネット証券以外の金融機関と連携関係にあってもよいし、ネット証券については、単にネット銀行を介して入出金可能になっているだけであり、連携関係になくてもよい。
第1取得部202は、地方銀行に開設されたユーザの口座と、少なくとも地方銀行と連携するネット銀行に開設された口座と、が関連付けられた第1連携情報を取得する。本実施形態では、地方銀行は、ネット銀行と直接的に連携する。地方銀行は、ネット証券については、ネット銀行を介して間接的に連携する。連携とは、業務上の協力関係にあることであり、例えば、APIを利用して入出金を可能にすることである。地方銀行は、ネット銀行及びネット証券以外の金融機関と連携関係にあってもよいし、ネット証券については、単にネット銀行を介して入出金可能になっているだけであり、連携関係になくてもよい。
本実施形態では、第1連携データベースDB3に格納された地方銀行の口座情報とネット銀行の口座情報の組み合わせは、第1連携情報の一例である。このため、本実施形態でこれらの口座情報の組み合わせについて説明している箇所は、第1連携情報と読み替えることができる。例えば、第1連携データベースDB3に第1連携情報が格納されているので、第1取得部202は、データ記憶部200を参照することによって、第1連携情報を取得する。第1連携情報がネット銀行サーバ20以外の他のコンピュータによって記憶される場合には、第1取得部202は、当該他のコンピュータに記憶された第1連携情報を取得する。
第1取得部202によって取得される第1連携情報は、入出金の対象となる口座の名義人であるユーザの第1連携情報である。例えば、買い注文時の不足資金を補充するための入出金が実行される場合には、第1取得部202は、買い注文をしたユーザの第1連携情報を取得する。また例えば、所定の入出金タイミングが訪れたときの入出金が実行される場合には、第1取得部202は、入出金タイミングにおける入出金の対象となるユーザの第1連携情報を取得する。入出金タイミングにおける入出金の対象となるユーザは、全てのユーザであってもよいし、一部のユーザであってもよい。一部のユーザが対象となる場合には、入出金タイミングで入出金を希望するか否かをユーザ自身が指定するものとする。
[第2取得部]
第2取得部203は、ネット銀行の口座と、少なくともネット銀行と連携するネット証券に開設されたユーザのネット証券の口座と、が関連付けられた第2連携情報を取得する。ネット証券は、ネット銀行と直接的に連携する。ネット証券は、地方銀行については、ネット銀行を介して間接的に連携する。ネット証券は、地方銀行及びネット銀行以外の金融機関と連携関係にあってもよいし、地方銀行については、単にネット銀行を介して入出金可能になっているだけであり、連携関係になくてもよい。
第2取得部203は、ネット銀行の口座と、少なくともネット銀行と連携するネット証券に開設されたユーザのネット証券の口座と、が関連付けられた第2連携情報を取得する。ネット証券は、ネット銀行と直接的に連携する。ネット証券は、地方銀行については、ネット銀行を介して間接的に連携する。ネット証券は、地方銀行及びネット銀行以外の金融機関と連携関係にあってもよいし、地方銀行については、単にネット銀行を介して入出金可能になっているだけであり、連携関係になくてもよい。
本実施形態では、第2連携データベースDB4に格納されたネット銀行の口座情報とネット証券の口座情報の組み合わせは、第2連携情報の一例である。このため、本実施形態でこれらの口座情報の組み合わせについて説明している箇所は、第2連携情報と読み替えることができる。例えば、第2連携データベースDB4に第2連携情報が格納されているので、第2取得部203は、データ記憶部200を参照することによって、第2連携情報を取得する。第2連携情報がネット銀行サーバ20以外の他のコンピュータによって記憶される場合には、第2取得部203は、当該他のコンピュータに記憶された第2連携情報を取得する。
第2取得部203によって取得される第2連携情報は、入出金の対象となる口座の名義人であるユーザの第2連携情報である。例えば、買い注文時の不足資金を補充するための入出金が実行される場合には、第2取得部203は、買い注文をしたユーザの第2連携情報を取得する。また例えば、所定の入出金タイミングが訪れたときの入出金が実行される場合には、第2取得部203は、入出金タイミングにおける入出金の対象となるユーザの第2連携情報を取得する。
[入出金制御部]
入出金制御部204は、第1連携情報と第2連携情報とに基づいて、ネット銀行の口座を介して行われる、地方銀行の口座とネット証券の口座との間の入出金を制御する。この入出金は、地方銀行の口座からネット証券の口座への入金と、ネット証券の口座から地方銀行の口座への入金と、の少なくとも一方である。本実施形態では、入出金制御部204がこれらの両方を制御する場合を説明するが、何れか一方のみを制御してもよい。
入出金制御部204は、第1連携情報と第2連携情報とに基づいて、ネット銀行の口座を介して行われる、地方銀行の口座とネット証券の口座との間の入出金を制御する。この入出金は、地方銀行の口座からネット証券の口座への入金と、ネット証券の口座から地方銀行の口座への入金と、の少なくとも一方である。本実施形態では、入出金制御部204がこれらの両方を制御する場合を説明するが、何れか一方のみを制御してもよい。
例えば、入出金制御部204は、地方銀行の口座からの出金をネット証券の口座に入金する。また例えば、入出金制御部204は、ネット証券の口座からの出金を地方銀行の口座に入金する。入出金制御部204は、ネット銀行の口座を利用して、地方銀行の口座とネット証券の口座との間の入出金を仲介することになる。別の言い方をすれば、入出金制御部204は、第1連携情報と第2連携情報とに基づいて、受信した出金要求又は入金要求を転送すべき口座を特定する。
例えば、入出金制御部204は、地方銀行の口座からネット銀行の口座への入金を受け付けた場合に、第2連携情報に基づいて、当該入金の全部又は一部を、ネット銀行の口座からネット証券の口座に入金する。本実施形態では、地方銀行の口座からネット銀行の口座への入金の全部がネット証券の口座に入金される場合を説明するが、所定の手数料が引かれた額がネット証券の口座に入金されてもよい。この場合、地方銀行から出金される額は、ネット証券における不足資金に手数料が加算された額となる。入出金制御部204は、第2連携情報に基づいて、入金されたネット銀行の口座に関連付けられたネット証券の口座を特定する。入出金制御部204は、特定したネット証券の口座に、地方銀行の口座からの出金を入金する。
また例えば、入出金制御部204は、ネット証券の口座からネット銀行の口座への入金を受け付けた場合に、第1連携情報に基づいて、当該入金の全部又は一部を、ネット銀行の口座から地方銀行の口座に入金する。本実施形態では、この入金についても全部が地方銀行の口座に入金される場合を説明するが、所定の手数料が引かれた額が地方銀行の口座に入金されてもよい。入出金制御部204は、第1連携情報に基づいて、入金されたネット銀行の口座に関連付けられた地方銀行の口座を特定する。入出金制御部204は、特定した地方銀行の口座に、ネット証券の口座からの出金を入金する。
本実施形態では、入出金制御部204は、ネット銀行の口座から出金するための出金要求を受信した場合に、第1連携情報に基づいて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信する。この出金要求には、出金対象となる口座の口座情報として、ネット銀行の口座の口座情報が含まれる。出金額は、買い注文時の不足資金又はそれ以上の額である。入力対象となる口座の口座情報として、買い注文をしたユーザのネット証券の口座情報である。
入出金制御部204は、ネット銀行の口座から出金するための出金要求を受信したことを条件として、第1連携情報に基づいて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信する。入出金制御部204は、ネット銀行の口座から出金するための出金要求を受信したことに応じて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信する。
本実施形態では、図2のユーザU4のように、ネット銀行とネット証券との間で入出金を行う入出金サービスが、地方銀行に口座を開設していないユーザに対しても提供されている。例えば、この入出金サービスのAPIについては、先述した通りであり、既存のAPIであってよい。入出金制御部204は、入出金サービスのAPIと同じAPIに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、ネット銀行の口座とネット証券の口座との間の入出金を制御する。即ち、このAPIについては、地方銀行のユーザもネット証券のユーザも関係なく共用される。
入出金制御部204は、入出金サービスのAPIとは異なるAPIに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、地方銀行の口座とネット銀行の口座との間の入出金を制御する。異なるAPIとは、地方銀行システム1とネット銀行システム2との間で開発されたAPIであり、ネット証券システム3は、APIの内容を認知せず、コールについても送信しないものとする。
例えば、ネット銀行は、複数の地方銀行と連携し、入出金サービスのAPIと同じAPIは、複数の地方銀行に共通であり、入出金サービスのAPIと異なるAPIは、地方銀行ごとに用意されている。地方銀行システム1とネット銀行システム2については、これらの間だけで有効であり、入出金サービスのために開発されたAPIが利用される。このAPIは、普通口座間における通常の入出金サービスにおけるAPIを利用可能である。例えば、地方銀行とネット銀行が、既に通常の入出金サービスで連携している場合には、既存の入出金サービスの機能を利用して、地方銀行とネット銀行の間の入出金が実行されてもよい。
本実施形態のネット銀行の口座は、残高が増えない口座、又は、残高が所定額以内に制限された口座である。残高が増えない口座は、残高が固定値の口座であり、例えば、残高が0円より大きくならない口座である。残高が所定額以内に制限された口座は、残高が所定額以上にならない口座である。閾値となる所定額は、固定値であってもよいし、可変値であってもよい。
入出金制御部204は、ネット銀行の口座の残高を増やすことなく、又は、ネット銀行の口座の残高を所定額以上にすることなく、ネット銀行の口座を介して行われる、地方銀行の口座とネット証券の口座との間の入出金を制御する。例えば、入出金制御部204は、ネット銀行のユーザの口座が受け付けた入金を、そのまま自身の出金として扱う。
[3-3.ネット証券システム]
ネット証券システム3は、データ記憶部300と入出金制御部301を備えている。データ記憶部30は、記憶部32を主として実現され、入出金制御部301は、制御部31を主として実現される。
ネット証券システム3は、データ記憶部300と入出金制御部301を備えている。データ記憶部30は、記憶部32を主として実現され、入出金制御部301は、制御部31を主として実現される。
[データ記憶部]
データ記憶部300は、ネット証券の業務で必要なデータを記憶する。例えば、データ記憶部は、本実施形態の入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、ネット証券の口座データベースDB5について説明する。
データ記憶部300は、ネット証券の業務で必要なデータを記憶する。例えば、データ記憶部は、本実施形態の入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、ネット証券の口座データベースDB5について説明する。
図8は、ネット証券の口座データベースDB5のデータ格納例を示す図である。図8に示すように、口座データベースDB5は、ネット証券に開設された口座に関する各種情報が格納されるデータベースである。例えば、口座データベースDB5には、ネット証券における部店を一意に識別する部店コード、部店名、ユーザに割り当てられたお客様コード、名義人、及び残高等の情報が格納される。
口座データベースDB5には、ネット証券の全ての口座の情報が格納されてもよいし、入出金サービスを利用するユーザの口座の情報だけが格納されてもよい。口座データベースDB5には、他の情報が格納されていてもよく、例えば、ユーザの入出金の履歴、又は、入出金サービスの利用有無を示す情報が格納されていてもよい。
なお、データ記憶部300が記憶するデータは、上記の例に限られない。例えば、データ記憶部300は、地方銀行の口座とネット銀行の口座との間で入出金を実行するためのAPIのデータを記憶してもよい。また例えば、データ記憶部300は、地方銀行とネット銀行が連携するためのデータ(例えば、残高照会のAPIのデータ)を記憶してもよい。
[入出金制御部]
入出金制御部301は、ネット銀行の口座とネット証券の口座との間の入出金を制御する。例えば、入出金制御部301は、ユーザによる買い注文時においてネット証券の口座の資金が不足していた場合に、ネット銀行システム2に対し、ネット銀行の口座から出金するための出金要求を送信する。この出金用求には、出金対象となるネット銀行の口座の支店コードと口座番号、出金額、及び入金対象となるネット証券の口座の支店コードと口座番号が含まれるものとする。
入出金制御部301は、ネット銀行の口座とネット証券の口座との間の入出金を制御する。例えば、入出金制御部301は、ユーザによる買い注文時においてネット証券の口座の資金が不足していた場合に、ネット銀行システム2に対し、ネット銀行の口座から出金するための出金要求を送信する。この出金用求には、出金対象となるネット銀行の口座の支店コードと口座番号、出金額、及び入金対象となるネット証券の口座の支店コードと口座番号が含まれるものとする。
入出金制御部301は、ユーザによる買い注文が受け付けられると、ユーザの指定内容に基づいて、買い注文における必要額を計算する。入出金制御部301は、口座データベースDB5を参照し、買い注文したユーザの残高が、当該計算された必要額以上であるか否かを判定する。残高が必要額未満であれば、資金が不足していたと判定される。
また例えば、入出金制御部301は、所定の入金要求を受信すると、当該入金要求に基づいて、ネット銀行の口座に入金し、この口座の残高を入金額に応じた額だけ増加させる。この入金要求には、入金対象となるネット証券の口座情報、出金額、及び出金対象となる口座の口座情報が含まれるものとする。入出金制御部301は、入金要求を参照し、入金先となるネット証券の口座の口座情報を特定する。入出金制御部301は、当該特定した口座情報が示すネット証券の口座に入金することになる。
[4.本実施形態において実行される処理]
図9は、本実施形態において実行される処理のフロー図である。図9に示す処理は、制御部11,21,31の各々が記憶部12,22,32に記憶されたプログラムに従って動作することによって実行される。これらの処理は、各機能ブロックが実行する処理の一例である。なお、図9の処理が実行されるにあたり、ユーザによる入出金サービスの申し込みが完了しており、ネット銀行の地方銀行専用支店にユーザの口座が開設されているものとする。また、ユーザはネット証券にログイン済みであり、ネット証券システム3は、どのユーザがアクセスしているか特定できるようになっている。
図9は、本実施形態において実行される処理のフロー図である。図9に示す処理は、制御部11,21,31の各々が記憶部12,22,32に記憶されたプログラムに従って動作することによって実行される。これらの処理は、各機能ブロックが実行する処理の一例である。なお、図9の処理が実行されるにあたり、ユーザによる入出金サービスの申し込みが完了しており、ネット銀行の地方銀行専用支店にユーザの口座が開設されているものとする。また、ユーザはネット証券にログイン済みであり、ネット証券システム3は、どのユーザがアクセスしているか特定できるようになっている。
図9に示すように、まず、ネット証券サーバ30は、ユーザから買い注文を受け付けたか否かを判定する(S1)。S1においては、ユーザは、ユーザ端末40を操作してネット証券サーバ30にログインした後に、購入対象の銘柄、株数、及び注文方法等を指定して買い注文を行う。ネット証券サーバ30は、ユーザ端末40から、ユーザが指定した買い注文の内容を受信した場合に、買い注文を受け付けたと判定する。
買い注文を受け付けたと判定された場合(S1;Y)、ネット証券サーバ30は、ネット証券の口座データベースDB5と、ユーザが指定した買い注文の内容と、に基づいて、ネット証券の口座の資金が不足するか否かを判定する(S2)。S2においては、ネット証券サーバ30は、ネット証券の口座データベースDB5を参照し、買い注文をしたユーザの口座残高を特定する。ネット証券サーバ30は、ユーザが指定した買い注文の内容に応じた金額を計算し、当該計算した金額が口座の資金以上であるか否かを判定する。
資金が不足すると判定された場合(S2;Y)、ネット証券サーバ30は、ネット銀行サーバ20に対し、不足金額に応じた出金要求を送信する(S3)。S3における出金要求の出金対象となるのは、ネット銀行のユーザの口座であってもよいし、地方銀行のユーザの口座であってもよい。ネット銀行のユーザの口座が出金対象となる場合には、第1連携データベースDB3によって、この出金要求が地方銀行のユーザの口座の出金要求に変換されるようにすればよい。
ネット銀行サーバ20は、出金要求を受信すると、第1連携データベースDB3に基づいて、地方銀行サーバ10に対し、不足金額に応じた出金要求を送信する(S4)。この出金要求の出金対象となるのは、地方銀行のユーザの口座である。このため、この出金要求には、地方銀行のユーザの口座の支店コードと口座番号が含まれる。S4においては、ネット銀行サーバ20は、第1連携データベースDB3を参照し、買い注文をしたユーザの地方銀行の口座情報を取得する。ネット銀行サーバ20は、取得した口座情報に基づいて、地方銀行サーバ10の出金要求のAPIをコールする。
地方銀行サーバ10は、出金要求を受信すると、口座データベースDB1に基づいて、地方銀行の口座から出金し、ネット銀行サーバ20に対し、入金要求を送信する(S5)。入金要求は、所定形式のデータが送信されることによって行われる。この入金要求には、出金された地方銀行の口座の支店コードと口座番号、出金額、及び入金するネット銀行の口座の支店コードと口座番号が含まれるものとする。S5においては、地方銀行サーバ10は、買い注文をしたユーザの地方銀行の口座から、受信した出金要求に応じた額を出金し、当該口座の残高を当該額だけ減少させる。
ネット銀行サーバ20は、入金要求を受信すると、第2連携データベースDB4に基づいて、ネット証券サーバ30に対し、入金要求を送信する(S6)。この入金要求には、出金されたネット銀行の口座の支店コードと口座番号、出金額、及び入金するネット証券の部店コードと口座番号が含まれるものとする。ネット銀行の口座は0円で固定されているので、ネット銀行の口座の残高は変化しない。
ネット証券サーバ30は、入金要求を受信すると、口座データベースDB5に基づいて、ネット証券の口座に入金する(S7)。S7においては、ネット証券サーバ30は、買い注文をしたユーザのネット証券の口座の残高を、受信した出金結果に応じた額(不足金額)だけ増加させる。
ネット証券サーバ30は、S7で不足金額が入金されたネット証券の口座残高に基づいて、ユーザにより指定された内容で買い注文を実行する(S8)。なお、ユーザにより売り注文が指示された場合には、売り注文が実行されてネット証券の口座残高が増加する。
ネット証券サーバ30は、所定の入出金タイミングが訪れたか否かを判定する(S9)。本実施形態では、この入出金タイミングは、深夜の所定の時刻である場合を説明する。このため、S9において、ネット証券サーバ30は、リアルタイムクロック等を利用して現在日時を取得し、所定の時刻が訪れたか否かを判定する。入出金タイミングが訪れたと判定されない場合(S9;N)、S1の処理に戻る。
一方、入出金タイミングが訪れたと判定された場合(S9;Y)、ネット証券サーバ30は、ネット証券の口座データベースDB5に基づいて、ネット証券の口座から出金し、ネット銀行サーバ20に対し、入金要求を送信する(S10)。この入金結果には、出金されたネット証券の口座の部店コードと口座番号、出金額、及び入金するネット銀行の口座の支店コードと口座番号が含まれるものとする。S10においては、ネット証券サーバ30は、ネット証券の口座の資金の全部又は一部を出金し、ネット証券の口座の残高をその額だけ減少させる。
ネット銀行サーバ20は、入金要求を受信すると、第1連携データベースDB3に基づいて、ネット銀行への入金を出金し、地方銀行サーバ10に対し、入金要求を送信する(S11)。この入金要求には、出金されたネット銀行の口座の支店コードと口座番号、出金額、及び入金する地方銀行の口座の支店コードと口座番号が含まれるものとする。ネット銀行の口座は0円で固定されているので、S11においては、口座の残高は変化しない。
地方銀行サーバ10は、出金結果を受信すると、口座データベースDB1に基づいて、地方銀行の口座に入金し(S12)、本処理は終了する。S12においては、地方銀行サーバ10は、買い注文をしたユーザの地方銀行の口座の残高を、受信した出金結果に応じた額だけ増加させる。
以上説明した実施形態によれば、第1連携データベースDB3に格納された第1連携情報と第2連携データベースDB4に格納された第2連携情報とに基づいて、ネット銀行の口座を介して行われる、地方銀行の口座とネット証券の口座との間の入出金を制御することによって、ネット銀行システム2とネット証券システム3との間の入出金サービスの機能を流用可能となり、地方銀行とネット証券とを連携させる際の導入コストを軽減することができる。また、地方銀行をメインバンクとするユーザの中には、ネット証券の利用を希望するユーザも存在し、そのようなユーザによるネット証券の利用を促進することができる。
また、ネット銀行システム2は、地方銀行の口座からネット銀行の口座への入金を受け付けた場合に、第2連携データベースDB4に基づいて、当該入金の全部又は一部を、ネット銀行の口座からネット証券の口座に入金することによって、地方銀行の口座からネット証券の口座への入金を実現する際の導入コストを軽減することができる。また、ネット銀行システム2は、ネット証券の口座からネット銀行の口座への入金を受け付けた場合に、第1連携情報に基づいて、当該入金の全部又は一部を、ネット銀行の口座から地方銀行の口座に入金することによって、ネット証券の口座から地方銀行の口座への入金を実現する際の導入コストを軽減することができる。
また、ネット銀行システム2は、ネット銀行の口座から出金するための出金要求を受信した場合に、第1連携データベースDB3に基づいて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信し、地方銀行の口座からネット銀行の口座への入金は、地方銀行の口座から出金するための出金要求に応じて地方銀行により行われることによって、既存の入出金サービスの機能をより多く流用し、地方銀行とネット証券とを連携させる際の導入コストを効果的に軽減することができる。
また、ネット銀行システム2は、ネット銀行とネット証券との間で入出金を行う入出金サービスと同じAPIに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、ネット銀行の口座とネット証券の口座との間の入出金を制御することによって、既存のAPIを流用し、地方銀行とネット証券とを連携させる際の導入コストを効果的に軽減することができる。また、ネット銀行システム2は、入出金サービスのAPIとは異なるAPIに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、地方銀行の口座とネット銀行の口座との間の入出金を制御することによって、必要最低限のAPIの開発によって、地方銀行の口座とネット証券の口座との間の入出金を実現できる。
また、ネット銀行は、複数の地方銀行と連携し、入出金サービスのAPIと同じAPIは、複数の地方銀行に共通であることによって、既存の入出力サービスに係る機能を複数の地方銀行で流用し、複数の地方銀行とネット証券とを連携させる際の導入コストを効果的に軽減することができる。また、入出金サービスのAPIと異なるAPIは、地方銀行ごとに用意されていることによって、個々の銀行同士の入出金については独自のAPIを導入し、複数の地方銀行の口座とネット証券の口座との間の入出金を効率的に実現することができる。
また、ネット銀行システム2は、地方銀行によりユーザの口座開設が許可された場合に、専用支店にネット銀行の口座を開設することによって、第三者が勝手に専用支店に口座を開設することを防止し、入出金サービスにおけるセキュリティを向上させることができる。
また、ネット銀行システム2は、複数の地方銀行のうち、ユーザの口座開設を許可した地方銀行の専用支店に、ネット銀行の口座を開設することによって、地方銀行ごとに専用支店を用意し、複数の地方銀行が提供する入出金サービスにおけるセキュリティを向上させることができる。
また、ネット銀行の口座は、残高が増えない口座、又は、残高が所定額以内に制限された口座とすることで、地方銀行の口座の資金が意図せずネット銀行に流入することを防止し、セキュリティを向上させることができる。
[5.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
例えば、ネット銀行が複数の地方銀行と連携する場合、ユーザや地方銀行の行員に対し、入出金サービスを利用可能な地方銀行の一覧を提示し、その中から入出金サービスの利用対象となる地方銀行を選択させることによって、サービスの利用開始を効率化してもよい。
図10は、変形例の機能ブロック図である。図10に示すように、変形例では、表示制御部205、受付部206、及び生成部207が実現される。本変形例では、これらの各機能がネット銀行サーバ20の制御部21を主として実現される場合を説明する。
表示制御部205は、複数の地方銀行の一覧を表示させる。本変形例では、ネット銀行サーバ20によって表示制御部205が実現されるので、表示制御部205は、ユーザ端末40等のコンピュータに対し、一覧を表示させるためのデータを送信することによってこの一覧をユーザ端末40等のコンピュータに表示させる。地方銀行の一覧は、任意のレイアウトで表示可能であり、例えば、地方銀行の選択を受け付けるボタン、チェックボックス、及び入力フォームの少なくとも1つが含まれてよい。なお、ネット銀行と提携する地方銀行に関する情報(例えば、銀行名や画像など)は、データ記憶部200に予め記憶されているものとする。
受付部206は、一覧の中から、地方銀行の口座が開設された地方銀行の選択を受け付ける。本変形例では、ネット銀行サーバ20によって受付部206が実現されるので、受付部206は、ユーザ端末40等のコンピュータから、選択された地方銀行を識別する情報を受信することによって、地方銀行の選択を受け付ける。受付部206は、少なくとも1つの地方銀行の選択を受け付けるようにすればよい。
生成部207は、選択が受け付けられた場合に、第1連携情報と第2連携情報とを生成する。生成部207は、選択が受け付けられたことを条件として、第1連携情報と第2連携情報とを生成する。例えば、生成部207は、ユーザが選択した地方銀行の口座と、ユーザのネット銀行の口座と、が関連付けられるように第1連携情報を生成する。また例えば、生成部207は、当該ユーザのネット銀行の口座と、当該ユーザのネット証券の口座と、が関連付けられるように第2連携情報を生成する。ユーザの口座情報は、その場で入力されてもよいし、口座データベースDB1,DB2,DB5から取得されてもよい。
以上説明した変形例によれば、複数の地方銀行の一覧の中から、口座が開設された地方銀行の選択が受け付けられた場合に、第1連携情報と第2連携情報とを生成することによって、入出金サービスにおける口座開設を容易化することができる。
また例えば、実施形態では、地方銀行の口座とネット証券の口座との間の入出金が自動的に実行される場合を説明したが、この入出金は、ユーザの指示によって自発的に実行されてもよい。例えば、地方銀行の口座からネット証券の口座への入金が指示されたことを条件として、実施形態で説明した流れでこの入金が実行されてもよい。また例えば、ネット証券の口座から地方銀行の口座への入金が指示されたことを条件として、実施形態で説明した流れでこの入金が実行されてもよい。
また例えば、金融機関の口座からネット証券の口座への入出金について説明したが、電子バリュー、ポイント、仮想通貨、又はウォレットといった媒体にある資金を、他の媒体を介してネット証券に入金するようにしてもよい。この場合、第1金融機関及び第2金融機関を電子バリュー、ポイント、仮想通貨、又はウォレットといった媒体に読み替えるようにすればよい。口座については、電子バリュー、ポイント、仮想通貨、又はウォレットで資金を管理するアカウント等と読み替えればよい。
なお、実施形態では、地方銀行の口座とネット証券の口座との間の入出金サービスについて説明したが、金融商品以外の他のサービスについても、地方銀行の口座からネット銀行の口座を介して、当該他のサービスに係る支払いが行われるようにしてもよい。この場合の支払いは、実施形態で説明した処理を流用すればよい。ここでは、ネット銀行が宝くじや公営競技くじ等のくじ購入サービスを提供していた場合に、くじ購入サービスに係る機能が地方銀行に提供される場合を説明する。
くじ購入サービスでは、ネット銀行は、くじの運営主体と連携している。ネット銀行に口座を開設しているユーザは、ネット銀行の口座を利用して、運営主体が販売するくじを購入することができる。くじの購入処理は、ネット銀行とくじの運営主体との間の既存のAPIによって実現されるようにすればよい。例えば、ユーザが所定の購入操作を行うと、APIの処理により、ユーザが指定したくじの購入内容が運営主体のシステムに送信され、運営主体のシステムにおいて、所定の購入処理が実行される。また、その際の購入代金についても、APIの処理により、ユーザの口座から出金されて、くじの運営主体に送金される。ユーザが購入したくじが当選すると、運営主体のシステムは、ユーザの口座に当選金額を入金するように要求する。ネット銀行システム2は、当該要求に応じてユーザの口座に当選金額を入金する。当選金額の入金もAPIによって実現されるようにすればよい。
例えば、ネット銀行のくじ購入サービスを地方銀行に連携させる場合、地方銀行をメインバンクとするユーザが所定の利用申込を行うと、実施形態と同様の手順に沿って、ネット銀行の専用支店に口座が開設される。そして、地方銀行のユーザの口座と、ネット銀行に開設されたユーザの口座と、が関連付けられた第1連携情報が生成される。この点は、実施形態で説明した通りである。本変形例では、証券会社のサービスではなく、くじの運営主体は口座の開設業務を行っていないものとする。このため、くじの運営主体にはユーザの口座は開設されない。
ユーザは、地方銀行のウェブサイト等からくじの購入操作を行うと、地方銀行システム1は、地方銀行のユーザの口座から、購入代金に応じた額を出金し、ネット銀行のユーザの口座に入金する。地方銀行システム1とネット銀行システム2との間の入出金は、実施形態で説明したAPIと同様のAPIを利用して実現すればよい。ネット銀行システム2は、当該口座への入金に基づいて、くじの購入処理を実行する。くじの購入処理は、上記説明した既存のくじ購入サービスに係るAPIによって実行される。既存のくじ購入サービスとは、先述したサービスであり、地方銀行を利用していないネット銀行のユーザも利用可能なサービスである。
以上のように、ネット銀行のくじ購入サービスを地方銀行に公開する場合についても、実施形態で説明した処理を流用することによって、地方銀行のユーザが、ネット銀行の口座を介して、くじを購入できるようになる。この場合も既存のくじ購入サービスに係る機能を流用することで、金融機関とくじの運営主体とを連携させる際の導入コストを軽減することができる。
なお、くじの運営主体が口座の開設業務を行っていれば、くじの運営主体についても、ユーザの口座が開設されてもよい。この場合には、ネット証券の口座を介して、地方銀行の口座と、くじの運営主体の口座と、の間の入出金を実行すればよいので、実施形態と同様の処理によって実現すればよい。即ち、実施形態におけるネット証券の記載をくじの運営主体と読み替えればよい。また、上記変形例では、ネット銀行のくじ購入サービスと地方銀行が連携する場合について説明したが、他の任意のサービスについても同様の処理によって連携することができる。
また例えば、ネット銀行サーバ20によって実現されるものとして説明した機能は、他のコンピュータによって実現されてもよいし、複数のコンピュータによって分担されてもよい。例えば、データ記憶部200は、ネット銀行サーバ20とは別のデータベースサーバで実現されてもよい。
1 地方銀行システム、2 ネット銀行システム、3 ネット証券システム、N ネットワーク、10 地方銀行サーバ、11,21,31,41 制御部、12,22,32,42 記憶部、13,23,33,43 通信部、20 ネット銀行サーバ、30 ネット証券サーバ、40 ユーザ端末、44 操作部、45 表示部、DB1,DB2,DB5 口座データベース、DB3 第1連携データベース、DB4 第2連携データベース、100 データ記憶部、101 入出金制御部、200 データ記憶部、201 口座開設部、202 第1取得部、203 第2取得部、204 入出金制御部、205 表示制御部、206 受付部、207 生成部、300 データ記憶部、301 入出金制御部。
Claims (8)
- 第1金融機関に開設されたユーザの第1口座と、少なくとも前記第1金融機関と連携する第2金融機関に開設された前記ユーザの第2口座と、が関連付けられた第1連携情報を取得する第1取得手段と、
前記第2口座と、少なくとも前記第2金融機関と連携する金融商品取引業者に開設された前記ユーザの第3口座と、が関連付けられた第2連携情報を取得する第2取得手段と、
前記第1口座から前記第2口座への入金を受け付けた場合に、前記第2連携情報に基づいて、当該入金の全部又は一部を、前記第2口座から前記第3口座に入金し、前記第3口座から前記第2口座への入金を受け付けた場合に、前記第1連携情報に基づいて、当該入金の全部又は一部を、前記第2口座から前記第1口座に入金する入出金制御手段と、
を含むことを特徴とする入出金制御システム。 - 前記第2金融機関と前記金融商品取引業者との間で入出金を行う入出金サービスが、前記第1金融機関に口座を開設していないユーザに対しても提供されており、
前記入出金制御手段は、
前記入出金サービスのAPIと同じAPIに基づいて、前記第1口座と前記第3口座との間の入出金のうち、前記第2口座と前記第3口座との間の入出金を制御し、
前記入出金サービスのAPIとは異なるAPIに基づいて、前記第1口座と前記第3口座との間の入出金のうち、前記第1口座と前記第2口座との間の入出金を制御する、
ことを特徴とする請求項1に記載の入出金制御システム。 - 前記第2金融機関は、複数の前記第1金融機関と連携し、
前記入出金サービスのAPIと同じAPIは、前記複数の第1金融機関に共通であり、
前記入出金サービスのAPIと異なるAPIは、前記第1金融機関ごとに用意されている、
ことを特徴とする請求項2に記載の入出金制御システム。 - 前記第2金融機関には、前記第1金融機関の専用支店が存在し、
前記入出金制御システムは、前記第1金融機関により前記ユーザの口座開設が許可された場合に、前記専用支店に前記第2口座を開設する口座開設手段を更に含む、
ことを特徴とする請求項1~3の何れかに記載の入出金制御システム。 - 前記第2金融機関は、複数の前記第1金融機関と連携し、
前記第2金融機関には、前記第1金融機関ごとに、前記専用支店が存在し、
前記口座開設手段は、前記複数の第1金融機関のうち、前記ユーザの口座開設を許可した第1金融機関の前記専用支店に、前記第2口座を開設する、
ことを特徴とする請求項4に記載の入出金制御システム。 - 前記第2金融機関は、複数の前記第1金融機関と連携し、
前記入出金制御システムは、
前記複数の第1金融機関の一覧を表示させる表示制御手段と、
前記一覧の中から、前記第1口座が開設された第1金融機関の選択を受け付ける受付手段と、
前記選択が受け付けられた場合に、前記第1連携情報と前記第2連携情報とを生成する生成手段と、
を含むことを特徴とする請求項1~5の何れかに記載の入出金制御システム。 - コンピュータが、
第1金融機関に開設されたユーザの第1口座と、少なくとも前記第1金融機関と連携する第2金融機関に開設された前記ユーザの第2口座と、が関連付けられた第1連携情報を取得する第1取得ステップと、
前記第2口座と、少なくとも前記第2金融機関と連携する金融商品取引業者に開設された前記ユーザの第3口座と、が関連付けられた第2連携情報を取得する第2取得ステップと、
前記第1口座から前記第2口座への入金を受け付けた場合に、前記第2連携情報に基づいて、当該入金の全部又は一部を、前記第2口座から前記第3口座に入金し、前記第3口座から前記第2口座への入金を受け付けた場合に、前記第1連携情報に基づいて、当該入金の全部又は一部を、前記第2口座から前記第1口座に入金する入出金制御ステップと、
を実行することを特徴とする入出金制御方法。 - 第1金融機関に開設されたユーザの第1口座と、少なくとも前記第1金融機関と連携する第2金融機関に開設された前記ユーザの第2口座と、が関連付けられた第1連携情報を取得する第1取得手段、
前記第2口座と、少なくとも前記第2金融機関と連携する金融商品取引業者に開設された前記ユーザの第3口座と、が関連付けられた第2連携情報を取得する第2取得手段、
前記第1口座から前記第2口座への入金を受け付けた場合に、前記第2連携情報に基づいて、当該入金の全部又は一部を、前記第2口座から前記第3口座に入金し、前記第3口座から前記第2口座への入金を受け付けた場合に、前記第1連携情報に基づいて、当該入金の全部又は一部を、前記第2口座から前記第1口座に入金する入出金制御手段、
としてコンピュータを機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021201626A JP7430696B2 (ja) | 2019-12-27 | 2021-12-13 | 入出金制御システム、入出金制御方法、及びプログラム |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019238926A JP7026094B2 (ja) | 2019-12-27 | 2019-12-27 | 入出金制御システム、入出金制御方法、及びプログラム |
JP2021201626A JP7430696B2 (ja) | 2019-12-27 | 2021-12-13 | 入出金制御システム、入出金制御方法、及びプログラム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019238926A Division JP7026094B2 (ja) | 2019-12-27 | 2019-12-27 | 入出金制御システム、入出金制御方法、及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2022022453A JP2022022453A (ja) | 2022-02-03 |
JP7430696B2 true JP7430696B2 (ja) | 2024-02-13 |
Family
ID=76967919
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019238926A Active JP7026094B2 (ja) | 2019-12-27 | 2019-12-27 | 入出金制御システム、入出金制御方法、及びプログラム |
JP2021201626A Active JP7430696B2 (ja) | 2019-12-27 | 2021-12-13 | 入出金制御システム、入出金制御方法、及びプログラム |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019238926A Active JP7026094B2 (ja) | 2019-12-27 | 2019-12-27 | 入出金制御システム、入出金制御方法、及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP7026094B2 (ja) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002175418A (ja) | 2000-09-27 | 2002-06-21 | Casio Comput Co Ltd | 資産管理サービスの方法及び資産管理サービスシステム |
JP2002207882A (ja) | 2001-01-05 | 2002-07-26 | Shinichiro Ohora | 貯金口座の現金引き落とし方式 |
JP2002245251A (ja) | 2001-02-16 | 2002-08-30 | Matsushita Electric Ind Co Ltd | オンライン証券取引サーバ、口座管理サーバ、オンライン証券取引システム、買い注文決済方法、買い注文決済プログラム、および記録媒体 |
JP2015191401A (ja) | 2014-03-28 | 2015-11-02 | マネックスグループ株式会社 | 口座管理サーバ |
JP2019023792A (ja) | 2017-07-24 | 2019-02-14 | トッパン・フォームズ株式会社 | 証券カード管理方法 |
-
2019
- 2019-12-27 JP JP2019238926A patent/JP7026094B2/ja active Active
-
2021
- 2021-12-13 JP JP2021201626A patent/JP7430696B2/ja active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002175418A (ja) | 2000-09-27 | 2002-06-21 | Casio Comput Co Ltd | 資産管理サービスの方法及び資産管理サービスシステム |
JP2002207882A (ja) | 2001-01-05 | 2002-07-26 | Shinichiro Ohora | 貯金口座の現金引き落とし方式 |
JP2002245251A (ja) | 2001-02-16 | 2002-08-30 | Matsushita Electric Ind Co Ltd | オンライン証券取引サーバ、口座管理サーバ、オンライン証券取引システム、買い注文決済方法、買い注文決済プログラム、および記録媒体 |
JP2015191401A (ja) | 2014-03-28 | 2015-11-02 | マネックスグループ株式会社 | 口座管理サーバ |
JP2019023792A (ja) | 2017-07-24 | 2019-02-14 | トッパン・フォームズ株式会社 | 証券カード管理方法 |
Also Published As
Publication number | Publication date |
---|---|
JP2021107995A (ja) | 2021-07-29 |
JP2022022453A (ja) | 2022-02-03 |
JP7026094B2 (ja) | 2022-02-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPH10222581A (ja) | 金融情報仲介処理装置およびそのプログラムを格納した記憶媒体 | |
KR101303300B1 (ko) | 담보거래 서비스 방법 | |
US20200074460A1 (en) | System and method for a stable cryptocurrency | |
JP2002063356A (ja) | 金融機関の貸出システム及びその方法 | |
JP2019070931A (ja) | 銀行システム、銀行システムによって実行される方法およびプログラム | |
JP2002245251A (ja) | オンライン証券取引サーバ、口座管理サーバ、オンライン証券取引システム、買い注文決済方法、買い注文決済プログラム、および記録媒体 | |
JP6409115B1 (ja) | 自動仕訳サーバおよび自動仕訳プログラム | |
US20160125482A1 (en) | System and method for making and tracking charitable contributions | |
JP4065669B2 (ja) | 複数の口座間における資金移動方法 | |
JP2002169964A (ja) | 預貯金口座管理装置、預貯金口座管理方法及び預貯金口座管理プログラムを記憶したコンピュータに読み取り可能な記憶媒体 | |
KR20190099545A (ko) | 국가별 화폐 단위를 가상적인 픽셀을 조합하여 만들어내는 블록 체인 기반의 암호화폐와 해당 플랫폼 및 프로그램 및 서비스 | |
JP7430696B2 (ja) | 入出金制御システム、入出金制御方法、及びプログラム | |
JP7061643B2 (ja) | 口座管理システム、口座の管理方法及びホストコンピュータ | |
JP7061992B2 (ja) | 資産運用システムおよびプログラム | |
JP2022154916A (ja) | データ処理装置およびデータ処理方法 | |
JP7256322B1 (ja) | 情報処理装置、情報処理システム及び情報処理方法 | |
JP2004171550A (ja) | 有価証券転売支援装置およびプログラム | |
JP7366116B2 (ja) | 残高連携システム、残高連携方法、及びプログラム | |
JP7268233B1 (ja) | 情報処理装置、情報処理方法及びプログラム | |
KR100359987B1 (ko) | 은행 증권 제휴 선물 옵션 거래 서비스 시스템 및 그제어방법 | |
JP7359919B1 (ja) | 情報処理装置、情報処理方法、及びプログラム | |
JP6810775B2 (ja) | 振込システム、振込方法、及びプログラム | |
KR102045139B1 (ko) | 가상 화폐 원스톱 대출 신청 서비스 방법 및 그 장치 | |
JP2007109125A (ja) | 優待確認システム、支払システム、株式取引情報システム、株主優待システム、優待確認方法、株主優待方法、支払決定プログラムおよび優待確認プログラム | |
KR20230126780A (ko) | 금융서비스 이용 약자를 위한 다계좌 투자 일임 계약 관리 서비스 제공 서버 및 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20221220 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20240116 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20240131 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7430696 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |