特許 7430696 入出金制御システム、入出金制御方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-02

(45)【発行日】2024-02-13

(54)【発明の名称】入出金制御システム、入出金制御方法、及びプログラム

(51)【国際特許分類】

   G06Q 40/02 20230101AFI20240205BHJP

【ＦＩ】

G06Q40/02

【請求項の数】 8

(21)【出願番号】P 2021201626

(22)【出願日】2021-12-13

(62)【分割の表示】P 2019238926の分割

【原出願日】2019-12-27

(65)【公開番号】P2022022453

(43)【公開日】2022-02-03

【審査請求日】2022-12-20

(73)【特許権者】

【識別番号】510247995

【氏名又は名称】楽天銀行株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】弁理士法人はるか国際特許事務所

(72)【発明者】

【氏名】井上 俊博

【審査官】平井 嗣人

(56)【参考文献】

【文献】特開２０１５－１９１４０１（ＪＰ，Ａ）

【文献】特開２００２－２０７８８２（ＪＰ，Ａ）

【文献】特開２００２－２４５２５１（ＪＰ，Ａ）

【文献】特開２０１９－０２３７９２（ＪＰ，Ａ）

【文献】特開２００２－１７５４１８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

第１金融機関に開設されたユーザの第１口座と、少なくとも前記第１金融機関と連携する第２金融機関に開設された前記ユーザの第２口座と、が関連付けられた第１連携情報を取得する第１取得手段と、
前記第２口座と、少なくとも前記第２金融機関と連携する金融商品取引業者に開設された前記ユーザの第３口座と、が関連付けられた第２連携情報を取得する第２取得手段と、
前記第１口座から前記第２口座への入金を受け付けた場合に、前記第２連携情報に基づいて、当該入金の全部又は一部を、前記第２口座から前記第３口座に入金し、前記第３口座から前記第２口座への入金を受け付けた場合に、前記第１連携情報に基づいて、当該入金の全部又は一部を、前記第２口座から前記第１口座に入金する入出金制御手段と、
を含むことを特徴とする入出金制御システム。

【請求項2】

前記第２金融機関と前記金融商品取引業者との間で入出金を行う入出金サービスが、前記第１金融機関に口座を開設していないユーザに対しても提供されており、
前記入出金制御手段は、
前記入出金サービスのＡＰＩと同じＡＰＩに基づいて、前記第１口座と前記第３口座との間の入出金のうち、前記第２口座と前記第３口座との間の入出金を制御し、
前記入出金サービスのＡＰＩとは異なるＡＰＩに基づいて、前記第１口座と前記第３口座との間の入出金のうち、前記第１口座と前記第２口座との間の入出金を制御する、
ことを特徴とする請求項１に記載の入出金制御システム。

【請求項3】

前記第２金融機関は、複数の前記第１金融機関と連携し、
前記入出金サービスのＡＰＩと同じＡＰＩは、前記複数の第１金融機関に共通であり、
前記入出金サービスのＡＰＩと異なるＡＰＩは、前記第１金融機関ごとに用意されている、
ことを特徴とする請求項２に記載の入出金制御システム。

【請求項4】

前記第２金融機関には、前記第１金融機関の専用支店が存在し、
前記入出金制御システムは、前記第１金融機関により前記ユーザの口座開設が許可された場合に、前記専用支店に前記第２口座を開設する口座開設手段を更に含む、
ことを特徴とする請求項１～３の何れかに記載の入出金制御システム。

【請求項5】

前記第２金融機関は、複数の前記第１金融機関と連携し、
前記第２金融機関には、前記第１金融機関ごとに、前記専用支店が存在し、
前記口座開設手段は、前記複数の第１金融機関のうち、前記ユーザの口座開設を許可した第１金融機関の前記専用支店に、前記第２口座を開設する、
ことを特徴とする請求項４に記載の入出金制御システム。

【請求項6】

前記第２金融機関は、複数の前記第１金融機関と連携し、
前記入出金制御システムは、
前記複数の第１金融機関の一覧を表示させる表示制御手段と、
前記一覧の中から、前記第１口座が開設された第１金融機関の選択を受け付ける受付手段と、
前記選択が受け付けられた場合に、前記第１連携情報と前記第２連携情報とを生成する生成手段と、
を含むことを特徴とする請求項１～５の何れかに記載の入出金制御システム。

【請求項7】

コンピュータが、
第１金融機関に開設されたユーザの第１口座と、少なくとも前記第１金融機関と連携する第２金融機関に開設された前記ユーザの第２口座と、が関連付けられた第１連携情報を取得する第１取得ステップと、
前記第２口座と、少なくとも前記第２金融機関と連携する金融商品取引業者に開設された前記ユーザの第３口座と、が関連付けられた第２連携情報を取得する第２取得ステップと、
前記第１口座から前記第２口座への入金を受け付けた場合に、前記第２連携情報に基づいて、当該入金の全部又は一部を、前記第２口座から前記第３口座に入金し、前記第３口座から前記第２口座への入金を受け付けた場合に、前記第１連携情報に基づいて、当該入金の全部又は一部を、前記第２口座から前記第１口座に入金する入出金制御ステップと、
を実行することを特徴とする入出金制御方法。

【請求項8】

第１金融機関に開設されたユーザの第１口座と、少なくとも前記第１金融機関と連携する第２金融機関に開設された前記ユーザの第２口座と、が関連付けられた第１連携情報を取得する第１取得手段、
前記第２口座と、少なくとも前記第２金融機関と連携する金融商品取引業者に開設された前記ユーザの第３口座と、が関連付けられた第２連携情報を取得する第２取得手段、
前記第１口座から前記第２口座への入金を受け付けた場合に、前記第２連携情報に基づいて、当該入金の全部又は一部を、前記第２口座から前記第３口座に入金し、前記第３口座から前記第２口座への入金を受け付けた場合に、前記第１連携情報に基づいて、当該入金の全部又は一部を、前記第２口座から前記第１口座に入金する入出金制御手段、
としてコンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、入出金制御システム、入出金制御方法、及びプログラムに関する。

【背景技術】

【0002】

従来、複数の金融機関が互いに連携して金融サービスを提供することが検討されている。例えば、特許文献１には、銀行が証券会社と連携するための証券仲介システムに、銀行口座を有する顧客の顧客情報と、銀行口座の口座情報と、が格納されたデータベースを用意し、顧客の端末から証券口座の開設要求があった場合に、データベースの中から、顧客情報に関連付けられた口座情報を取得し、証券会社との有価証券取引の決済を行うための銀行口座を決済口座として選択することが記載されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００６－１２７３１２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１の証券仲介システムは、証券会社と連携済みの銀行しか利用することができないので、これから証券会社と連携しようとする銀行は、新たに証券仲介システムを導入する必要がある。この点、業務内容が異なる銀行と証券会社を連携させようとすると、業務内容が似ている銀行同士を連携させる場合に比べて導入コストがかかる。このため、特許文献１の技術において、銀行ごとに証券仲介システムを導入しようとすると、膨大な導入コストがかかってしまう。

【0005】

本開示の目的は、金融機関と金融商品取引業者とを連携させる際の導入コストを軽減することが可能な入出金制御システム、入出金制御方法、及びプログラムを提供することである。

【課題を解決するための手段】

【0006】

上記課題を解決するために、本発明の一態様に係る入出金制御システムは、第１金融機関に開設されたユーザの第１口座と、少なくとも前記第１金融機関と連携する第２金融機関に開設された前記ユーザの第２口座と、が関連付けられた第１連携情報を取得する第１取得手段と、前記第２口座と、少なくとも前記第２金融機関と連携する金融商品取引業者に開設された前記ユーザの第３口座と、が関連付けられた第２連携情報を取得する第２取得手段と、前記第１連携情報と前記第２連携情報とに基づいて、前記第２口座を介して行われる、前記第１口座と前記第３口座との間の入出金を制御する入出金制御手段と、を含むことを特徴とする。

【図面の簡単な説明】

【0007】

【図1】実施形態に係る入出金制御システムの一例を示す図である。

【図2】実施形態に係る入出金サービスの一例を示す図である。

【図3】本実施形態において実現される機能を示す機能ブロック図である。

【図4】地方銀行の口座データベースのデータ格納例を示す図である。

【図5】ネット銀行の口座データベースのデータ格納例を示す図である。

【図6】第１連携データベースのデータ格納例を示す図である。

【図7】第２連携データベースのデータ格納例を示す図である。

【図8】ネット証券の口座データベースのデータ格納例を示す図である。

【図9】本実施形態において実行される処理のフロー図である。

【図10】変形例の機能ブロック図である。

【発明を実施するための形態】

【0008】

［１．入出金制御システムの全体構成］
以下、本発明に係る実施形態の例について図面に基づき詳細に説明する。図１は、実施形態に係る入出金制御システムの一例を示す図である。本実施形態では、入出金制御システムの一例として、図１に示すネット銀行システム２を説明する。このため、本実施形態でネット銀行システム２と記載した箇所は、入出金制御システムと読み替えることができる。

【0009】

図１に示すように、本実施形態では、地方銀行システム１、ネット銀行システム２、ネット証券システム３、及びユーザ端末４０の各々が、インターネットなどのネットワークＮに接続可能となっている。なお、図１では、これらを１つずつ示しているが、これらは複数存在してもよい。

【0010】

地方銀行システム１は、地方銀行が管理するシステムである。地方銀行は、第１金融機関の一例である。このため、本実施形態で地方銀行と記載した箇所は、第１金融機関と読み替えることができる。金融機関は、任意の種類であってよく、例えば、いわゆる預貯金取扱金融機関である。例えば、金融機関は、銀行、信用金庫、信用協同組合、労働金庫、又は農林中央金庫などである。銀行は、任意の種類であってよく、例えば、都市銀行、地方銀行、ネット銀行、又は信託銀行である。第１金融機関は、地方銀行以外の銀行であってもよい。

【0011】

地方銀行システム１は、地方銀行サーバ１０を含む。地方銀行サーバ１０は、サーバコンピュータである。例えば、地方銀行サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、例えば、少なくとも１つのプロセッサを含む。記憶部１２は、例えば、ＲＡＭ等の主記憶部やハードディスク等の補助記憶部を含む。制御部１１は、記憶部１２に記憶されたプログラムやデータに従って処理を実行する。通信部１３は、有線通信又は無線通信用の通信インタフェースを含む。なお、地方銀行システム１には、他のコンピュータが含まれていてもよい。例えば、地方銀行システム１には、他のサーバコンピュータが含まれていてもよいし、地方銀行の行員が操作する端末が含まれていてもよい。

【0012】

ネット銀行システム２は、ネット銀行が管理するシステムである。ネット銀行は、店舗を持たず、インターネット上での取引を中心として営業する銀行である。ネット銀行は、第２金融機関の一例である。このため、本実施形態でネット銀行と記載した箇所は、第２金融機関と読み替えることができる。第２金融機関は、第１金融機関とは異なる金融機関である。金融機関の意味は先述した通りである。第２金融機関は、任意の種類であってよく、例えば、ネット銀行以外の銀行が第２金融機関に相当してもよいし、銀行以外の金融機関が第２金融機関に相当してもよい。

【0013】

ネット銀行システム２は、ネット銀行サーバ２０を含む。ネット銀行サーバ２０は、サーバコンピュータである。例えば、ネット銀行サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。なお、ネット銀行システム２には、他のコンピュータが含まれていてもよい。例えば、ネット銀行システム２には、他のサーバコンピュータが含まれていてもよいし、ネット銀行の行員が操作する端末が含まれていてもよい。

【0014】

ネット証券システム３は、ネット証券が管理するシステムである。ネット証券は、店舗を持たず、インターネット上での取引を中心として営業する証券会社である。ネット証券は、金融商品取引業者の一例である。このため、本実施形態でネット証券と記載した箇所は、金融商品取引業者と読み替えることができる。金融商品取引業者は、任意の種類であってよく、例えば、第１種金融商品取引業を行う者であってもよいし、第２種金融商品取引業を行う者であってもよい。金融商品取引業者は、ネット証券以外の証券会社であってもよく、例えば、実店舗を有する証券会社であってもよい。

【0015】

ネット証券システム３は、ネット証券サーバ３０を含む。ネット証券サーバ３０は、サーバコンピュータである。例えば、ネット証券サーバ３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。なお、ネット証券システム３には、他のコンピュータが含まれていてもよい。例えば、ネット証券システム３には、他のサーバコンピュータが含まれていてもよいし、ネット証券の行員が操作する端末が含まれていてもよい。

【0016】

ユーザ端末４０は、ユーザが操作するコンピュータである。例えば、ユーザ端末４０は、パーソナルコンピュータ、スマートフォン、又はタブレット型端末である。ユーザ端末４０は、制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５を含む。制御部４１、記憶部４２、及び通信部４３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部４４は、タッチパネルやマウスなどの入力デバイスである。表示部４５は、液晶ディスプレイ又は有機ＥＬディスプレイである。

【0017】

なお、地方銀行サーバ１０、ネット銀行サーバ２０、ネット証券サーバ３０、及びユーザ端末４０の各々に記憶されるものとして説明するプログラム及びデータは、ネットワークＮを介してこれらに供給されてもよい。また、これらのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）や外部機器と直接的に接続するための入出力部（例えば、ＵＳＢ端子）が含まれていてもよい。この場合、情報記憶媒体に記憶されたプログラムやデータが読取部又は入出力部を介して供給されてもよい。

【0018】

［２．実施形態に係る入出金制御の概要］
本実施形態では、ネット銀行システム２とネット証券システム３は、互いに連携しており、入出金サービスがユーザに提供される。この入出金サービスは、ネット銀行の口座とネット証券の口座との間における入出金を実行するサービスである。入出金サービスは、口座連携サービスと呼ばれることもある。入出金サービスを利用するユーザは、ネット銀行とネット証券の各々に口座を開設する。

【0019】

例えば、入出金サービスでは、ユーザがネット証券で買い注文をした場合に、ネット証券のユーザの口座（預り金）の残高（資金）が不足していると、ネット証券システム３からネット銀行システム２に対し、ネット銀行のユーザの口座から出金するための出金要求が送信される。この出金要求は、ユーザの買い注文をするための不足資金を補充するための要求である。

【0020】

ネット銀行システム２は、出金要求に応じてネット銀行のユーザの口座から出金する。この出金は、買い注文をしたユーザのネット証券の口座に入金され、不足資金が補充される。不足資金が補充されると、ユーザが指定した内容に基づいて、買い注文が行われる。なお、ネット銀行の口座の残高は、ユーザが指定した金額は留めおくようにしてもよい。また、ネット証券システム３は、ネット銀行システム２に対し、ネット銀行のユーザの口座の残高照会を送信し、この口座の残高が不足金額以上だった場合に出金要求を送信してもよい。

【0021】

また例えば、入出金サービスでは、夜間などの所定の入出金タイミングが訪れると、ネット証券システム３は、ネット証券のユーザの口座から出金する。ネット証券システム３は、ネット証券の口座残高の全額を出金してもよいし、ユーザが指定した金額は留めおくようにしてもよい。この出金は、ネット銀行のユーザの口座に入金される。

【0022】

以上のように、ネット銀行とネット証券の両方に口座を開設しているユーザに対し、入出金サービスが提供される。ネット銀行システム２とネット証券システム３との間の入出金サービスを実現する方法自体は、公知の方法を利用可能であり、例えば、これらの間で自動的に入出金を実行するためのＡＰＩによって実現される。

【0023】

本実施形態では、地方銀行のユーザに対しても、入出金サービスが提供される。即ち、入出金サービスに係る機能は、ネット銀行とネット証券だけでなく、地方銀行に対しても公開されている。地方銀行は、当該公開された入出金サービスを利用して、地方銀行の口座とネット証券の口座との間における入出金を実行するサービスを、地方銀行のユーザに提供することができる。

【0024】

ただし、地方銀行に提供されるのは、あくまでネット銀行の口座とネット証券の口座との間における入出金サービスに係る機能である。例えば、ネット銀行が、宝くじや公営競技くじの購入といった他のサービスを提供している場合に、本実施形態では、ネット銀行の全ての機能が地方銀行に提供されるのではなく（ネット銀行の全てのサービスについて地方銀行と連携するのではなく）、ネット証券との間における入出金サービスに係る機能が地方銀行に提供される場合について説明する。このため、地方銀行の口座とネット証券の口座との間で直接的に入出金が実行されるのではなく、ネット銀行の口座を介して、地方銀行の口座とネット証券の口座との間で間接的に入出金が実行されるようになっている。ネット銀行の口座は、地方銀行の口座とネット証券の口座との間の入出金を仲介するハブのような役割を果たす。なお、地方銀行には、宝くじや公営競技くじの購入といったネット銀行の他のサービスが提供されてもよい。この点は、後述の変形例で説明する。

【0025】

ここでは、入出金サービスを利用していない地方銀行のユーザが、新たに入出金サービスの利用を開始する場合を例に挙げて、地方銀行の口座とネット証券の口座との間の入出金の流れを説明する。例えば、ユーザは、地方銀行をメインバンクとして利用しており、ネット銀行とネット証券には口座を開設していないものとする。ユーザは、地方銀行の店舗を訪れたり、地方銀行システム１にアクセスしたりして、入出金サービスの申込手続を行う。地方銀行は、ネット銀行とネット証券の各々に対して口座開設を要求し、ネット銀行とネット証券の各々に、ユーザの口座が開設される。

【0026】

口座開設自体は、公知の手順に沿って行われるようにすればよい。本実施形態では、ネット銀行には、地方銀行専用の支店が存在し、その支店にユーザの口座が開設されるようになっている。専用支店は、いわゆる法人支店であり、地方銀行の名前の全部又は一部が支店名に含まれている。地方銀行の専用支店には、地方銀行が許可したユーザだけが口座を開設することができ、他の銀行等が勝手に口座を開設できないようになっている。一方、ネット証券については、通常の口座開設の手順に沿って口座が開設される。口座開設が完了すると、地方銀行の口座、ネット銀行の口座、及びネット証券の口座の各々が互いに関連付けられて、入出金サービスを利用することができるようになる。

【0027】

図２は、実施形態に係る入出金サービスの一例を示す図である。図２の例では、ユーザＵ１のメインバンクが地方銀行Ａであり、ユーザＵ２のメインバンクが地方銀行Ｂであり、ユーザＵ３のメインバンクが地方銀行Ｃであるものとする。これらのユーザＵ１～Ｕ３の各々は、自身がメインバンクとする地方銀行Ａ～Ｃに口座Ａ１～Ｃ３を開設している。

【0028】

なお、図２に示すユーザＵ４は、ネット銀行Ｘをメインバンクとしており、ネット銀行Ｘの本店に口座Ｘ４を開設している。ユーザＵ４は、地方銀行には口座を開設していないものとする。ユーザＵ４は、ネット証券Ｙに口座Ｙ４を有しており、ネット銀行Ｘとネット証券Ｙとの間の従来型の入出金サービスを利用する。この入出金サービスにおける入出金は、ネット銀行システム２とネット証券システム３との二者で実行される。この入出金の流れについては先述した通りである。

【0029】

ユーザＵ１～Ｕ３の各々は、入出金サービスの申込手続を済ませており、ネット銀行Ｘとネット証券Ｙの各々に口座Ｘ１～Ｘ３，Ｙ１～Ｙ３を開設している。先述したように、ネット銀行Ｘは、地方銀行ごとに専用支店が存在する。一方、ネット証券Ｙについては、既存の入出金サービスを利用するユーザＵ４と同様の口座が開設されており、地方銀行の専用支店のような概念はないものとする。

【0030】

例えば、地方銀行ＡをメインバンクとするユーザＵ１は、ネット銀行ＸのＡ支店（地方銀行Ａの専用支店）に口座を開設する。また例えば、地方銀行ＢをメインバンクとするユーザＵ２は、ネット銀行ＸのＢ支店（地方銀行Ｂの専用支店）に口座を開設する。また例えば、地方銀行ＣをメインバンクとするユーザＵ３は、ネット銀行ＸのＣ支店（地方銀行Ｃの専用支店）に口座を開設する。本実施形態では、これらの口座は、残高が０円で固定されており、それ以上は増えないように制限されている。

【0031】

例えば、ユーザＵ１がネット証券Ｙで買い注文をした場合に、ネット証券ＹのユーザＵ１の口座の資金が不足していると、ネット証券システム３からネット銀行システム２に対し、ネット銀行Ｘの口座Ｘ１からの出金要求が送信される。この出金要求は、既存の入出金サービスのＡＰＩを利用して行われる。ネット銀行Ｘは、出金要求を受け付けると、地方銀行システム１に対し、地方銀行Ａの口座Ａ１からの出金要求を送信する。この出金要求は、地方銀行システム１とネット銀行システム２との間のＡＰＩを利用して行われる。

【0032】

地方銀行Ａの地方銀行システム１は、出金要求に応じて地方銀行Ａの口座Ａ１から不足資金に応じた額の出金を行い、ネット銀行Ｘの口座Ｘ１に入金する。この入出金は、地方銀行システム１とネット銀行システム２との間のＡＰＩを利用して行われる。先述したように、ネット銀行Ｘの口座Ｘ１は、残高が０円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。

【0033】

ネット銀行システム２は、地方銀行Ａの口座Ａ１からネット銀行Ｘの口座Ｘ１への入金を、ネット証券Ｙの口座Ｙ１に入金する。即ち、地方銀行Ａの口座Ａ１からネット銀行Ｘの口座Ｘ１に入金されると、口座Ｘ１の残高が増加することなく、ネット銀行Ｘの口座Ｘ１への入金が即座にそのままネット証券Ｙの口座Ｙ１に入金される。この入金は、既存の入出金サービスのＡＰＩを利用して行われる。ネット証券Ｙの口座Ｙ１は、不足資金に応じた額が増えるので、ユーザの指定した内容で買い注文を実行可能となる。

【0034】

以上のように、ネット銀行Ｘの口座Ｘ１を介して、地方銀行Ａの口座Ａ１からネット証券Ｙの口座Ｙ１に、ユーザの買い注文における不足資金が自動的に入金される。図２に示すように、ユーザＵ２，Ｕ３についても、ユーザＵ１と同様の流れで、ネット銀行Ｘを介して、地方銀行Ｂ，Ｃからネット証券Ｙに不足資金が入金される。ネット銀行ＸのＢ，Ｃ支店における口座Ｘ２，Ｘ３についても、残高が０円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。

【0035】

また例えば、夜間などの所定の入出金タイミングが訪れると、ネット証券Ｙから地方銀行Ａ～Ｃの各々への入金が実行される。ユーザＵ１を例に挙げて説明すると、ネット証券システム３は、入出金タイミングが訪れると、ネット証券Ｙの口座Ｙ１の全部又は一部を出金し、ネット銀行Ｘの口座Ｘ１に入金される。この入金は、既存の入出金サービスのＡＰＩを利用して行われる。先述したように、ネット銀行Ｘの口座Ｘ１は、残高が０円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。

【0036】

ネット銀行システム２は、ネット証券Ｙの口座Ｙ１からネット銀行Ｘの口座Ｘ１への入金を、地方銀行Ａの口座Ａ１に入金する。即ち、ネット証券Ｙの口座Ｙ１からネット銀行Ｘの口座Ｘ１に入金されると、口座Ｘ１の残高が増加することなく、ネット銀行Ｘの口座Ｘ１への入金が即座にそのまま地方銀行Ａの口座Ａ１に入金される。これにより、ユーザは、ネット証券Ｙにおける売買で得た資金を地方銀行Ａの口座Ａ１に移動させることができる。

【0037】

図２に示すように、ユーザＵ２，Ｕ３についても、ユーザＵ１と同様の流れで、ネット銀行Ｘを介して、ネット証券Ｙから地方銀行Ｂ，Ｃに資金が入金される。ネット銀行ＸのＢ，Ｃ支店におけるユーザＵ２，Ｕ３の口座Ｘ２，Ｘ３についても、残高が０円で固定されているため、入金が実行されても残高は増えず、出金が実行されても残高は減らない。

【0038】

以上のように、本実施形態では、ネット銀行Ｘとネット証券Ｙとの間の入出金サービスに係る機能が地方銀行Ａ～Ｃに公開されている。この入出金サービスに係る機能を利用して、ネット銀行Ｘを介して、地方銀行Ａ～Ｃとネット証券Ｙとの間の入出金を実現することによって、地方銀行Ａ～Ｃとネット証券Ｙとを連携させる際の導入コストを軽減するようにしている。以降、本実施形態において実現される機能等の詳細について説明する。

【0039】

［３．本実施形態において実現される機能］
図３は、本実施形態において実現される機能を示す機能ブロック図である。本実施形態では、地方銀行システム１、ネット銀行システム２、及びネット証券システム３の各々で実現される場合を説明する。

【0040】

［３－１．地方銀行システム］
地方銀行システム１は、データ記憶部１００と入出金制御部１０１とを備えている。データ記憶部１００は、記憶部１２を主として実現され、入出金制御部１０１は、制御部１１を主として実現される。

【0041】

［データ記憶部］
データ記憶部１００は、地方銀行の業務で必要なデータを記憶する。例えば、データ記憶部１００は、入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、地方銀行の口座データベースＤＢ１について説明する。

【0042】

図４は、地方銀行の口座データベースＤＢ１のデータ格納例を示す図である。図４に示すように、口座データベースＤＢ１は、地方銀行に開設された口座に関する各種情報が格納されるデータベースである。例えば、口座データベースＤＢ１には、支店コード、支店名、口座の預金種別、口座番号、名義人、及び残高等の情報が格納される。本実施形態では、入出金サービスを利用するユーザの預金種別は普通口座であるものとするが、他の種別の口座であってもよい。

【0043】

口座データベースＤＢ１には、地方銀行の全ての口座の情報が格納されてもよいし、入出金サービスを利用するユーザの口座の情報だけが格納されてもよい。口座データベースＤＢ１には、他の情報が格納されていてもよく、例えば、ユーザの入出金の履歴、又は、入出金サービスの利用有無を示す情報が格納されていてもよい。

【0044】

なお、データ記憶部１００が記憶するデータは、上記の例に限られない。例えば、データ記憶部１００は、地方銀行の口座とネット銀行の口座との間で入出金を実行するためのＡＰＩのデータを記憶してもよい。また例えば、データ記憶部１００は、地方銀行とネット銀行が連携するためのデータ（例えば、残高照会のＡＰＩのデータ）を記憶してもよい。

【0045】

［入出金制御部］
入出金制御部１０１は、地方銀行の口座とネット銀行の口座との間の入出金を制御する。例えば、入出金制御部１０１は、所定の出金要求を受信すると、当該出金要求に基づいて、地方銀行の口座から出金し、口座の残高を出金額に応じた額だけ減少させる。出金要求は、出金対象となる口座の口座情報、出金額、及び入金対象となる口座の口座情報が含まれるものとする。出金対象となる口座は、出金元となる口座であり、出金によって残高が減少する口座である。入金対象となる口座は、入金先となる口座であり、入金によって残高が増加する口座である。

【0046】

口座情報は、口座を識別可能な情報であり、例えば、支店コードと口座番号が格納される。口座情報には、口座を識別可能な情報が格納されるようにすればよく、金融機関コードや名義人などの他の情報が格納されてもよい。例えば、地方銀行システム１に対する出金要求には、出金対象となる地方銀行の口座の支店コードと口座番号、出金額、及び入金対象となるネット証券の口座の支店コードと口座番号が含まれるものとする。

【0047】

入出金制御部１０１は、出金要求を参照し、出金対象となる口座の口座情報を特定する。入出金制御部１０１は、当該特定した口座から、出金要求に応じた額を出金して残高を減少させる。入出金制御部１０１は、出金要求を参照し、入金先となる口座の口座情報を特定する。入出金制御部１０１は、当該特定した口座を管理するネット銀行システム２に対し、入金要求を送信する。入金要求は、入金対象となる口座の口座情報、出金額、及び出金対象となる口座の口座情報が含まれるものとする。入金対象と出金対象の意味は先述した通りである。入金要求が送信されると、ネット銀行システム２の入出金制御部２０４により、ネット銀行の口座への入金が実行される。

【0048】

また例えば、入出金制御部１０１は、所定の入金要求を受信すると、当該入金要求に基づいて、地方銀行の口座に入金し、口座の残高を入金額に応じた額だけ増加させる。この入金要求に含まれる入金対象の口座情報は、地方銀行の口座情報となる。入出金制御部１０１は、入金要求を参照し、入金先となる地方銀行の口座の口座情報を特定する。入出金制御部１０１は、当該特定した口座情報が示す地方銀行の口座に入金することになる。

【0049】

［３－２．ネット銀行システム］
ネット銀行システム２は、データ記憶部２００、口座開設部２０１、第１取得部２０２、第２取得部２０３、及び入出金制御部２０４を備えている。データ記憶部２００は、記憶部２２を主として実現され、他の各機能は、制御部２１を主として実現される。

【0050】

［データ記憶部］
データ記憶部２００は、ネット銀行の業務で必要なデータを記憶する。例えば、データ記憶部は、入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、ネット銀行の口座データベースＤＢ２、第１連携データベースＤＢ３、及び第２連携データベースＤＢ４について説明する。

【0051】

図５は、ネット銀行の口座データベースＤＢ２のデータ格納例を示す図である。図５に示すように、口座データベースＤＢ２は、ネット銀行に開設された口座に関する各種情報が格納されるデータベースである。例えば、口座データベースＤＢ２には、ネット銀行における支店を一意に識別する支店コード、支店名、口座の預金種別、口座番号、名義人、及び残高等の情報が格納される。本実施形態では、入出金サービスを利用するユーザの預金種別は普通口座であるものとするが、他の種別の口座であってもよい。

【0052】

口座データベースＤＢ２には、ネット銀行の全ての口座の情報が格納されてもよいし、入出金サービスを利用するユーザの口座の情報だけが格納されてもよい。口座データベースＤＢ２には、他の情報が格納されていてもよく、例えば、ユーザの入出金の履歴、入出金サービスの利用有無を示す情報、又は口座の残高が増えないように制限されていることを識別する情報が格納されていてもよい。

【0053】

図６は、第１連携データベースＤＢ３のデータ格納例を示す図である。図６に示すように、第１連携データベースＤＢ３は、地方銀行とネット銀行との間の入出金を実現するためのデータベースである。例えば、第１連携データベースＤＢ３には、地方銀行の金融機関コード、地方銀行の口座情報、及びネット銀行の口座情報が関連付けられている。本実施形態では、複数の地方銀行によって入出金サービスが提供されるので、第１連携データベースＤＢ３には、地方銀行ごとに、地方銀行の口座情報とネット銀行の口座情報の組み合わせが格納されることになる。

【0054】

第１連携データベースＤＢ３には、入出金サービスを利用するユーザごとに、地方銀行の口座の口座情報と、ネット銀行の口座の口座情報と、が関連付けられている。関連付けとは、一の情報から他の情報を検索可能にすることである。本実施形態では、第１連携データベースＤＢ３の同じレコードに情報を格納することが関連付けることに相当する。

【0055】

なお、本実施形態では、複数の地方銀行の各々のユーザの口座情報が、１つの第１連携データベースＤＢ３に格納されている場合を説明するが、地方銀行ごとに、第１連携データベースＤＢ３が用意されていてもよい。即ち、データ記憶部１００は、複数の地方銀行にそれぞれ対応する複数の第１連携データベースＤＢ３を記憶してもよい。

【0056】

図７は、第２連携データベースＤＢ４のデータ格納例を示す図である。図７に示すように、第２連携データベースＤＢ４は、ネット銀行とネット証券との間の入出金を実現するためのデータベースである。例えば、第２連携データベースＤＢ４には、ネット銀行の口座情報と、ネット証券の口座情報と、が関連付けられている。口座情報の意味は先述した通りである。

【0057】

ネット証券については、支店コードの代わりに部店コードが格納される場合を説明するが、ネット証券についても支店コードが用いられてもよい。第２連携データベースＤＢ４には、入出金サービスを利用するユーザごとに、ネット銀行の口座の口座情報と、ネット証券の口座の口座情報と、が関連付けられている。第２連携データベースＤＢ４には、入出金サービスを利用するユーザごとに、ネット銀行の口座情報とネット証券の口座情報の組み合わせが格納されることになる。

【0058】

なお、データ記憶部２００が記憶するデータは、上記の例に限られない。例えば、データ記憶部２００は、地方銀行の口座とネット証券の口座との間の入出金を仲介するためのＡＰＩのデータを記憶してもよい。また例えば、データ記憶部１００は、地方銀行とネット銀行が連携するためのデータ（例えば、残高照会のＡＰＩのデータ）と、ネット銀行とネット証券が連携するためのデータ（例えば、残高照会のＡＰＩのデータ）と、を記憶してもよい。

【0059】

［口座開設部］
口座開設部２０１は、ネット銀行に口座を開設する。先述したように、口座の開設自体は、公知の処理を適用可能である。本実施形態では、口座データベースＤＢ２に新たなレコードを作成し、新たに開設された口座の支店コードや口座番号といった情報を格納することが、口座を開設することに相当する。これらの情報は、ネット証券の行員が入力してもよいし、ユーザによって指定されてもよい。口座番号については、所定の採番ルールに基づいて自動的に採番されてもよい。

【0060】

本実施形態では、ネット銀行には、地方銀行の専用支店が存在し、口座開設部２０１は、地方銀行によりユーザの口座開設が許可された場合に、専用支店に口座を開設する。本実施形態では、ネット銀行は複数の地方銀行と連携し、ネット銀行には、地方銀行ごとに専用支店が存在するので、口座開設部２０１は、複数の地方銀行のうち、ユーザの口座開設を許可した地方銀行の専用支店に、ネット銀行の口座を開設する。

【0061】

口座開設部２０１は、地方銀行により口座の開設が許可されたことを条件として、その地方銀行の専用支店に口座を開設する。口座開設部２０１は、地方銀行によりユーザの口座開設が許可されない場合には、その地方銀行の専用支店に口座を開設せず、口座開設部２０１は、地方銀行によりユーザの口座開設が許可された場合に、その地方銀行の専用支店に口座を開設する。

【0062】

例えば、地方銀行により口座の開設が許可された場合に、地方銀行システム１からネット銀行システム２に対し、所定の口座開設要求が送信される。口座開設要求は、口座を開設するための要求であり、所定のデータ形式の情報が送信されることによって行われる。口座開設要求は、口座を開設するために必要な情報を含んでおり、例えば、支店コード、支店名、預金種別、名義人、住所、及び電話番号といった情報が含まれている。例えば、口座開設求は、地方銀行の行員が所定の操作を行った場合に送信されてもよいし、地方銀行システム１において口座開設の審査に合格した場合に自動的に送信されてもよい。

【0063】

［第１取得部］
第１取得部２０２は、地方銀行に開設されたユーザの口座と、少なくとも地方銀行と連携するネット銀行に開設された口座と、が関連付けられた第１連携情報を取得する。本実施形態では、地方銀行は、ネット銀行と直接的に連携する。地方銀行は、ネット証券については、ネット銀行を介して間接的に連携する。連携とは、業務上の協力関係にあることであり、例えば、ＡＰＩを利用して入出金を可能にすることである。地方銀行は、ネット銀行及びネット証券以外の金融機関と連携関係にあってもよいし、ネット証券については、単にネット銀行を介して入出金可能になっているだけであり、連携関係になくてもよい。

【0064】

本実施形態では、第１連携データベースＤＢ３に格納された地方銀行の口座情報とネット銀行の口座情報の組み合わせは、第１連携情報の一例である。このため、本実施形態でこれらの口座情報の組み合わせについて説明している箇所は、第１連携情報と読み替えることができる。例えば、第１連携データベースＤＢ３に第１連携情報が格納されているので、第１取得部２０２は、データ記憶部２００を参照することによって、第１連携情報を取得する。第１連携情報がネット銀行サーバ２０以外の他のコンピュータによって記憶される場合には、第１取得部２０２は、当該他のコンピュータに記憶された第１連携情報を取得する。

【0065】

第１取得部２０２によって取得される第１連携情報は、入出金の対象となる口座の名義人であるユーザの第１連携情報である。例えば、買い注文時の不足資金を補充するための入出金が実行される場合には、第１取得部２０２は、買い注文をしたユーザの第１連携情報を取得する。また例えば、所定の入出金タイミングが訪れたときの入出金が実行される場合には、第１取得部２０２は、入出金タイミングにおける入出金の対象となるユーザの第１連携情報を取得する。入出金タイミングにおける入出金の対象となるユーザは、全てのユーザであってもよいし、一部のユーザであってもよい。一部のユーザが対象となる場合には、入出金タイミングで入出金を希望するか否かをユーザ自身が指定するものとする。

【0066】

［第２取得部］
第２取得部２０３は、ネット銀行の口座と、少なくともネット銀行と連携するネット証券に開設されたユーザのネット証券の口座と、が関連付けられた第２連携情報を取得する。ネット証券は、ネット銀行と直接的に連携する。ネット証券は、地方銀行については、ネット銀行を介して間接的に連携する。ネット証券は、地方銀行及びネット銀行以外の金融機関と連携関係にあってもよいし、地方銀行については、単にネット銀行を介して入出金可能になっているだけであり、連携関係になくてもよい。

【0067】

本実施形態では、第２連携データベースＤＢ４に格納されたネット銀行の口座情報とネット証券の口座情報の組み合わせは、第２連携情報の一例である。このため、本実施形態でこれらの口座情報の組み合わせについて説明している箇所は、第２連携情報と読み替えることができる。例えば、第２連携データベースＤＢ４に第２連携情報が格納されているので、第２取得部２０３は、データ記憶部２００を参照することによって、第２連携情報を取得する。第２連携情報がネット銀行サーバ２０以外の他のコンピュータによって記憶される場合には、第２取得部２０３は、当該他のコンピュータに記憶された第２連携情報を取得する。

【0068】

第２取得部２０３によって取得される第２連携情報は、入出金の対象となる口座の名義人であるユーザの第２連携情報である。例えば、買い注文時の不足資金を補充するための入出金が実行される場合には、第２取得部２０３は、買い注文をしたユーザの第２連携情報を取得する。また例えば、所定の入出金タイミングが訪れたときの入出金が実行される場合には、第２取得部２０３は、入出金タイミングにおける入出金の対象となるユーザの第２連携情報を取得する。

【0069】

［入出金制御部］
入出金制御部２０４は、第１連携情報と第２連携情報とに基づいて、ネット銀行の口座を介して行われる、地方銀行の口座とネット証券の口座との間の入出金を制御する。この入出金は、地方銀行の口座からネット証券の口座への入金と、ネット証券の口座から地方銀行の口座への入金と、の少なくとも一方である。本実施形態では、入出金制御部２０４がこれらの両方を制御する場合を説明するが、何れか一方のみを制御してもよい。

【0070】

例えば、入出金制御部２０４は、地方銀行の口座からの出金をネット証券の口座に入金する。また例えば、入出金制御部２０４は、ネット証券の口座からの出金を地方銀行の口座に入金する。入出金制御部２０４は、ネット銀行の口座を利用して、地方銀行の口座とネット証券の口座との間の入出金を仲介することになる。別の言い方をすれば、入出金制御部２０４は、第１連携情報と第２連携情報とに基づいて、受信した出金要求又は入金要求を転送すべき口座を特定する。

【0071】

例えば、入出金制御部２０４は、地方銀行の口座からネット銀行の口座への入金を受け付けた場合に、第２連携情報に基づいて、当該入金の全部又は一部を、ネット銀行の口座からネット証券の口座に入金する。本実施形態では、地方銀行の口座からネット銀行の口座への入金の全部がネット証券の口座に入金される場合を説明するが、所定の手数料が引かれた額がネット証券の口座に入金されてもよい。この場合、地方銀行から出金される額は、ネット証券における不足資金に手数料が加算された額となる。入出金制御部２０４は、第２連携情報に基づいて、入金されたネット銀行の口座に関連付けられたネット証券の口座を特定する。入出金制御部２０４は、特定したネット証券の口座に、地方銀行の口座からの出金を入金する。

【0072】

また例えば、入出金制御部２０４は、ネット証券の口座からネット銀行の口座への入金を受け付けた場合に、第１連携情報に基づいて、当該入金の全部又は一部を、ネット銀行の口座から地方銀行の口座に入金する。本実施形態では、この入金についても全部が地方銀行の口座に入金される場合を説明するが、所定の手数料が引かれた額が地方銀行の口座に入金されてもよい。入出金制御部２０４は、第１連携情報に基づいて、入金されたネット銀行の口座に関連付けられた地方銀行の口座を特定する。入出金制御部２０４は、特定した地方銀行の口座に、ネット証券の口座からの出金を入金する。

【0073】

本実施形態では、入出金制御部２０４は、ネット銀行の口座から出金するための出金要求を受信した場合に、第１連携情報に基づいて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信する。この出金要求には、出金対象となる口座の口座情報として、ネット銀行の口座の口座情報が含まれる。出金額は、買い注文時の不足資金又はそれ以上の額である。入力対象となる口座の口座情報として、買い注文をしたユーザのネット証券の口座情報である。

【0074】

入出金制御部２０４は、ネット銀行の口座から出金するための出金要求を受信したことを条件として、第１連携情報に基づいて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信する。入出金制御部２０４は、ネット銀行の口座から出金するための出金要求を受信したことに応じて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信する。

【0075】

本実施形態では、図２のユーザＵ４のように、ネット銀行とネット証券との間で入出金を行う入出金サービスが、地方銀行に口座を開設していないユーザに対しても提供されている。例えば、この入出金サービスのＡＰＩについては、先述した通りであり、既存のＡＰＩであってよい。入出金制御部２０４は、入出金サービスのＡＰＩと同じＡＰＩに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、ネット銀行の口座とネット証券の口座との間の入出金を制御する。即ち、このＡＰＩについては、地方銀行のユーザもネット証券のユーザも関係なく共用される。

【0076】

入出金制御部２０４は、入出金サービスのＡＰＩとは異なるＡＰＩに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、地方銀行の口座とネット銀行の口座との間の入出金を制御する。異なるＡＰＩとは、地方銀行システム１とネット銀行システム２との間で開発されたＡＰＩであり、ネット証券システム３は、ＡＰＩの内容を認知せず、コールについても送信しないものとする。

【0077】

例えば、ネット銀行は、複数の地方銀行と連携し、入出金サービスのＡＰＩと同じＡＰＩは、複数の地方銀行に共通であり、入出金サービスのＡＰＩと異なるＡＰＩは、地方銀行ごとに用意されている。地方銀行システム１とネット銀行システム２については、これらの間だけで有効であり、入出金サービスのために開発されたＡＰＩが利用される。このＡＰＩは、普通口座間における通常の入出金サービスにおけるＡＰＩを利用可能である。例えば、地方銀行とネット銀行が、既に通常の入出金サービスで連携している場合には、既存の入出金サービスの機能を利用して、地方銀行とネット銀行の間の入出金が実行されてもよい。

【0078】

本実施形態のネット銀行の口座は、残高が増えない口座、又は、残高が所定額以内に制限された口座である。残高が増えない口座は、残高が固定値の口座であり、例えば、残高が０円より大きくならない口座である。残高が所定額以内に制限された口座は、残高が所定額以上にならない口座である。閾値となる所定額は、固定値であってもよいし、可変値であってもよい。

【0079】

入出金制御部２０４は、ネット銀行の口座の残高を増やすことなく、又は、ネット銀行の口座の残高を所定額以上にすることなく、ネット銀行の口座を介して行われる、地方銀行の口座とネット証券の口座との間の入出金を制御する。例えば、入出金制御部２０４は、ネット銀行のユーザの口座が受け付けた入金を、そのまま自身の出金として扱う。

【0080】

［３－３．ネット証券システム］
ネット証券システム３は、データ記憶部３００と入出金制御部３０１を備えている。データ記憶部３０は、記憶部３２を主として実現され、入出金制御部３０１は、制御部３１を主として実現される。

【0081】

［データ記憶部］
データ記憶部３００は、ネット証券の業務で必要なデータを記憶する。例えば、データ記憶部は、本実施形態の入出金サービスの実現に必要なデータを記憶する。ここでは、このデータの一例として、ネット証券の口座データベースＤＢ５について説明する。

【0082】

図８は、ネット証券の口座データベースＤＢ５のデータ格納例を示す図である。図８に示すように、口座データベースＤＢ５は、ネット証券に開設された口座に関する各種情報が格納されるデータベースである。例えば、口座データベースＤＢ５には、ネット証券における部店を一意に識別する部店コード、部店名、ユーザに割り当てられたお客様コード、名義人、及び残高等の情報が格納される。

【0083】

口座データベースＤＢ５には、ネット証券の全ての口座の情報が格納されてもよいし、入出金サービスを利用するユーザの口座の情報だけが格納されてもよい。口座データベースＤＢ５には、他の情報が格納されていてもよく、例えば、ユーザの入出金の履歴、又は、入出金サービスの利用有無を示す情報が格納されていてもよい。

【0084】

なお、データ記憶部３００が記憶するデータは、上記の例に限られない。例えば、データ記憶部３００は、地方銀行の口座とネット銀行の口座との間で入出金を実行するためのＡＰＩのデータを記憶してもよい。また例えば、データ記憶部３００は、地方銀行とネット銀行が連携するためのデータ（例えば、残高照会のＡＰＩのデータ）を記憶してもよい。

【0085】

［入出金制御部］
入出金制御部３０１は、ネット銀行の口座とネット証券の口座との間の入出金を制御する。例えば、入出金制御部３０１は、ユーザによる買い注文時においてネット証券の口座の資金が不足していた場合に、ネット銀行システム２に対し、ネット銀行の口座から出金するための出金要求を送信する。この出金用求には、出金対象となるネット銀行の口座の支店コードと口座番号、出金額、及び入金対象となるネット証券の口座の支店コードと口座番号が含まれるものとする。

【0086】

入出金制御部３０１は、ユーザによる買い注文が受け付けられると、ユーザの指定内容に基づいて、買い注文における必要額を計算する。入出金制御部３０１は、口座データベースＤＢ５を参照し、買い注文したユーザの残高が、当該計算された必要額以上であるか否かを判定する。残高が必要額未満であれば、資金が不足していたと判定される。

【0087】

また例えば、入出金制御部３０１は、所定の入金要求を受信すると、当該入金要求に基づいて、ネット銀行の口座に入金し、この口座の残高を入金額に応じた額だけ増加させる。この入金要求には、入金対象となるネット証券の口座情報、出金額、及び出金対象となる口座の口座情報が含まれるものとする。入出金制御部３０１は、入金要求を参照し、入金先となるネット証券の口座の口座情報を特定する。入出金制御部３０１は、当該特定した口座情報が示すネット証券の口座に入金することになる。

【0088】

［４．本実施形態において実行される処理］
図９は、本実施形態において実行される処理のフロー図である。図９に示す処理は、制御部１１，２１，３１の各々が記憶部１２，２２，３２に記憶されたプログラムに従って動作することによって実行される。これらの処理は、各機能ブロックが実行する処理の一例である。なお、図９の処理が実行されるにあたり、ユーザによる入出金サービスの申し込みが完了しており、ネット銀行の地方銀行専用支店にユーザの口座が開設されているものとする。また、ユーザはネット証券にログイン済みであり、ネット証券システム３は、どのユーザがアクセスしているか特定できるようになっている。

【0089】

図９に示すように、まず、ネット証券サーバ３０は、ユーザから買い注文を受け付けたか否かを判定する（Ｓ１）。Ｓ１においては、ユーザは、ユーザ端末４０を操作してネット証券サーバ３０にログインした後に、購入対象の銘柄、株数、及び注文方法等を指定して買い注文を行う。ネット証券サーバ３０は、ユーザ端末４０から、ユーザが指定した買い注文の内容を受信した場合に、買い注文を受け付けたと判定する。

【0090】

買い注文を受け付けたと判定された場合（Ｓ１；Ｙ）、ネット証券サーバ３０は、ネット証券の口座データベースＤＢ５と、ユーザが指定した買い注文の内容と、に基づいて、ネット証券の口座の資金が不足するか否かを判定する（Ｓ２）。Ｓ２においては、ネット証券サーバ３０は、ネット証券の口座データベースＤＢ５を参照し、買い注文をしたユーザの口座残高を特定する。ネット証券サーバ３０は、ユーザが指定した買い注文の内容に応じた金額を計算し、当該計算した金額が口座の資金以上であるか否かを判定する。

【0091】

資金が不足すると判定された場合（Ｓ２；Ｙ）、ネット証券サーバ３０は、ネット銀行サーバ２０に対し、不足金額に応じた出金要求を送信する（Ｓ３）。Ｓ３における出金要求の出金対象となるのは、ネット銀行のユーザの口座であってもよいし、地方銀行のユーザの口座であってもよい。ネット銀行のユーザの口座が出金対象となる場合には、第１連携データベースＤＢ３によって、この出金要求が地方銀行のユーザの口座の出金要求に変換されるようにすればよい。

【0092】

ネット銀行サーバ２０は、出金要求を受信すると、第１連携データベースＤＢ３に基づいて、地方銀行サーバ１０に対し、不足金額に応じた出金要求を送信する（Ｓ４）。この出金要求の出金対象となるのは、地方銀行のユーザの口座である。このため、この出金要求には、地方銀行のユーザの口座の支店コードと口座番号が含まれる。Ｓ４においては、ネット銀行サーバ２０は、第１連携データベースＤＢ３を参照し、買い注文をしたユーザの地方銀行の口座情報を取得する。ネット銀行サーバ２０は、取得した口座情報に基づいて、地方銀行サーバ１０の出金要求のＡＰＩをコールする。

【0093】

地方銀行サーバ１０は、出金要求を受信すると、口座データベースＤＢ１に基づいて、地方銀行の口座から出金し、ネット銀行サーバ２０に対し、入金要求を送信する（Ｓ５）。入金要求は、所定形式のデータが送信されることによって行われる。この入金要求には、出金された地方銀行の口座の支店コードと口座番号、出金額、及び入金するネット銀行の口座の支店コードと口座番号が含まれるものとする。Ｓ５においては、地方銀行サーバ１０は、買い注文をしたユーザの地方銀行の口座から、受信した出金要求に応じた額を出金し、当該口座の残高を当該額だけ減少させる。

【0094】

ネット銀行サーバ２０は、入金要求を受信すると、第２連携データベースＤＢ４に基づいて、ネット証券サーバ３０に対し、入金要求を送信する（Ｓ６）。この入金要求には、出金されたネット銀行の口座の支店コードと口座番号、出金額、及び入金するネット証券の部店コードと口座番号が含まれるものとする。ネット銀行の口座は０円で固定されているので、ネット銀行の口座の残高は変化しない。

【0095】

ネット証券サーバ３０は、入金要求を受信すると、口座データベースＤＢ５に基づいて、ネット証券の口座に入金する（Ｓ７）。Ｓ７においては、ネット証券サーバ３０は、買い注文をしたユーザのネット証券の口座の残高を、受信した出金結果に応じた額（不足金額）だけ増加させる。

【0096】

ネット証券サーバ３０は、Ｓ７で不足金額が入金されたネット証券の口座残高に基づいて、ユーザにより指定された内容で買い注文を実行する（Ｓ８）。なお、ユーザにより売り注文が指示された場合には、売り注文が実行されてネット証券の口座残高が増加する。

【0097】

ネット証券サーバ３０は、所定の入出金タイミングが訪れたか否かを判定する（Ｓ９）。本実施形態では、この入出金タイミングは、深夜の所定の時刻である場合を説明する。このため、Ｓ９において、ネット証券サーバ３０は、リアルタイムクロック等を利用して現在日時を取得し、所定の時刻が訪れたか否かを判定する。入出金タイミングが訪れたと判定されない場合（Ｓ９；Ｎ）、Ｓ１の処理に戻る。

【0098】

一方、入出金タイミングが訪れたと判定された場合（Ｓ９；Ｙ）、ネット証券サーバ３０は、ネット証券の口座データベースＤＢ５に基づいて、ネット証券の口座から出金し、ネット銀行サーバ２０に対し、入金要求を送信する（Ｓ１０）。この入金結果には、出金されたネット証券の口座の部店コードと口座番号、出金額、及び入金するネット銀行の口座の支店コードと口座番号が含まれるものとする。Ｓ１０においては、ネット証券サーバ３０は、ネット証券の口座の資金の全部又は一部を出金し、ネット証券の口座の残高をその額だけ減少させる。

【0099】

ネット銀行サーバ２０は、入金要求を受信すると、第１連携データベースＤＢ３に基づいて、ネット銀行への入金を出金し、地方銀行サーバ１０に対し、入金要求を送信する（Ｓ１１）。この入金要求には、出金されたネット銀行の口座の支店コードと口座番号、出金額、及び入金する地方銀行の口座の支店コードと口座番号が含まれるものとする。ネット銀行の口座は０円で固定されているので、Ｓ１１においては、口座の残高は変化しない。

【0100】

地方銀行サーバ１０は、出金結果を受信すると、口座データベースＤＢ１に基づいて、地方銀行の口座に入金し（Ｓ１２）、本処理は終了する。Ｓ１２においては、地方銀行サーバ１０は、買い注文をしたユーザの地方銀行の口座の残高を、受信した出金結果に応じた額だけ増加させる。

【0101】

以上説明した実施形態によれば、第１連携データベースＤＢ３に格納された第１連携情報と第２連携データベースＤＢ４に格納された第２連携情報とに基づいて、ネット銀行の口座を介して行われる、地方銀行の口座とネット証券の口座との間の入出金を制御することによって、ネット銀行システム２とネット証券システム３との間の入出金サービスの機能を流用可能となり、地方銀行とネット証券とを連携させる際の導入コストを軽減することができる。また、地方銀行をメインバンクとするユーザの中には、ネット証券の利用を希望するユーザも存在し、そのようなユーザによるネット証券の利用を促進することができる。

【0102】

また、ネット銀行システム２は、地方銀行の口座からネット銀行の口座への入金を受け付けた場合に、第２連携データベースＤＢ４に基づいて、当該入金の全部又は一部を、ネット銀行の口座からネット証券の口座に入金することによって、地方銀行の口座からネット証券の口座への入金を実現する際の導入コストを軽減することができる。また、ネット銀行システム２は、ネット証券の口座からネット銀行の口座への入金を受け付けた場合に、第１連携情報に基づいて、当該入金の全部又は一部を、ネット銀行の口座から地方銀行の口座に入金することによって、ネット証券の口座から地方銀行の口座への入金を実現する際の導入コストを軽減することができる。

【0103】

また、ネット銀行システム２は、ネット銀行の口座から出金するための出金要求を受信した場合に、第１連携データベースＤＢ３に基づいて、地方銀行に対し、地方銀行の口座から出金するための出金要求を送信し、地方銀行の口座からネット銀行の口座への入金は、地方銀行の口座から出金するための出金要求に応じて地方銀行により行われることによって、既存の入出金サービスの機能をより多く流用し、地方銀行とネット証券とを連携させる際の導入コストを効果的に軽減することができる。

【0104】

また、ネット銀行システム２は、ネット銀行とネット証券との間で入出金を行う入出金サービスと同じＡＰＩに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、ネット銀行の口座とネット証券の口座との間の入出金を制御することによって、既存のＡＰＩを流用し、地方銀行とネット証券とを連携させる際の導入コストを効果的に軽減することができる。また、ネット銀行システム２は、入出金サービスのＡＰＩとは異なるＡＰＩに基づいて、地方銀行の口座とネット証券の口座との間の入出金のうち、地方銀行の口座とネット銀行の口座との間の入出金を制御することによって、必要最低限のＡＰＩの開発によって、地方銀行の口座とネット証券の口座との間の入出金を実現できる。

【0105】

また、ネット銀行は、複数の地方銀行と連携し、入出金サービスのＡＰＩと同じＡＰＩは、複数の地方銀行に共通であることによって、既存の入出力サービスに係る機能を複数の地方銀行で流用し、複数の地方銀行とネット証券とを連携させる際の導入コストを効果的に軽減することができる。また、入出金サービスのＡＰＩと異なるＡＰＩは、地方銀行ごとに用意されていることによって、個々の銀行同士の入出金については独自のＡＰＩを導入し、複数の地方銀行の口座とネット証券の口座との間の入出金を効率的に実現することができる。

【0106】

また、ネット銀行システム２は、地方銀行によりユーザの口座開設が許可された場合に、専用支店にネット銀行の口座を開設することによって、第三者が勝手に専用支店に口座を開設することを防止し、入出金サービスにおけるセキュリティを向上させることができる。

【0107】

また、ネット銀行システム２は、複数の地方銀行のうち、ユーザの口座開設を許可した地方銀行の専用支店に、ネット銀行の口座を開設することによって、地方銀行ごとに専用支店を用意し、複数の地方銀行が提供する入出金サービスにおけるセキュリティを向上させることができる。

【0108】

また、ネット銀行の口座は、残高が増えない口座、又は、残高が所定額以内に制限された口座とすることで、地方銀行の口座の資金が意図せずネット銀行に流入することを防止し、セキュリティを向上させることができる。

【0109】

［５．変形例］
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。

【0110】

例えば、ネット銀行が複数の地方銀行と連携する場合、ユーザや地方銀行の行員に対し、入出金サービスを利用可能な地方銀行の一覧を提示し、その中から入出金サービスの利用対象となる地方銀行を選択させることによって、サービスの利用開始を効率化してもよい。

【0111】

図１０は、変形例の機能ブロック図である。図１０に示すように、変形例では、表示制御部２０５、受付部２０６、及び生成部２０７が実現される。本変形例では、これらの各機能がネット銀行サーバ２０の制御部２１を主として実現される場合を説明する。

【0112】

表示制御部２０５は、複数の地方銀行の一覧を表示させる。本変形例では、ネット銀行サーバ２０によって表示制御部２０５が実現されるので、表示制御部２０５は、ユーザ端末４０等のコンピュータに対し、一覧を表示させるためのデータを送信することによってこの一覧をユーザ端末４０等のコンピュータに表示させる。地方銀行の一覧は、任意のレイアウトで表示可能であり、例えば、地方銀行の選択を受け付けるボタン、チェックボックス、及び入力フォームの少なくとも１つが含まれてよい。なお、ネット銀行と提携する地方銀行に関する情報（例えば、銀行名や画像など）は、データ記憶部２００に予め記憶されているものとする。

【0113】

受付部２０６は、一覧の中から、地方銀行の口座が開設された地方銀行の選択を受け付ける。本変形例では、ネット銀行サーバ２０によって受付部２０６が実現されるので、受付部２０６は、ユーザ端末４０等のコンピュータから、選択された地方銀行を識別する情報を受信することによって、地方銀行の選択を受け付ける。受付部２０６は、少なくとも１つの地方銀行の選択を受け付けるようにすればよい。

【0114】

生成部２０７は、選択が受け付けられた場合に、第１連携情報と第２連携情報とを生成する。生成部２０７は、選択が受け付けられたことを条件として、第１連携情報と第２連携情報とを生成する。例えば、生成部２０７は、ユーザが選択した地方銀行の口座と、ユーザのネット銀行の口座と、が関連付けられるように第１連携情報を生成する。また例えば、生成部２０７は、当該ユーザのネット銀行の口座と、当該ユーザのネット証券の口座と、が関連付けられるように第２連携情報を生成する。ユーザの口座情報は、その場で入力されてもよいし、口座データベースＤＢ１，ＤＢ２，ＤＢ５から取得されてもよい。

【0115】

以上説明した変形例によれば、複数の地方銀行の一覧の中から、口座が開設された地方銀行の選択が受け付けられた場合に、第１連携情報と第２連携情報とを生成することによって、入出金サービスにおける口座開設を容易化することができる。

【0116】

また例えば、実施形態では、地方銀行の口座とネット証券の口座との間の入出金が自動的に実行される場合を説明したが、この入出金は、ユーザの指示によって自発的に実行されてもよい。例えば、地方銀行の口座からネット証券の口座への入金が指示されたことを条件として、実施形態で説明した流れでこの入金が実行されてもよい。また例えば、ネット証券の口座から地方銀行の口座への入金が指示されたことを条件として、実施形態で説明した流れでこの入金が実行されてもよい。

【0117】

また例えば、金融機関の口座からネット証券の口座への入出金について説明したが、電子バリュー、ポイント、仮想通貨、又はウォレットといった媒体にある資金を、他の媒体を介してネット証券に入金するようにしてもよい。この場合、第１金融機関及び第２金融機関を電子バリュー、ポイント、仮想通貨、又はウォレットといった媒体に読み替えるようにすればよい。口座については、電子バリュー、ポイント、仮想通貨、又はウォレットで資金を管理するアカウント等と読み替えればよい。

【0118】

なお、実施形態では、地方銀行の口座とネット証券の口座との間の入出金サービスについて説明したが、金融商品以外の他のサービスについても、地方銀行の口座からネット銀行の口座を介して、当該他のサービスに係る支払いが行われるようにしてもよい。この場合の支払いは、実施形態で説明した処理を流用すればよい。ここでは、ネット銀行が宝くじや公営競技くじ等のくじ購入サービスを提供していた場合に、くじ購入サービスに係る機能が地方銀行に提供される場合を説明する。

【0119】

くじ購入サービスでは、ネット銀行は、くじの運営主体と連携している。ネット銀行に口座を開設しているユーザは、ネット銀行の口座を利用して、運営主体が販売するくじを購入することができる。くじの購入処理は、ネット銀行とくじの運営主体との間の既存のＡＰＩによって実現されるようにすればよい。例えば、ユーザが所定の購入操作を行うと、ＡＰＩの処理により、ユーザが指定したくじの購入内容が運営主体のシステムに送信され、運営主体のシステムにおいて、所定の購入処理が実行される。また、その際の購入代金についても、ＡＰＩの処理により、ユーザの口座から出金されて、くじの運営主体に送金される。ユーザが購入したくじが当選すると、運営主体のシステムは、ユーザの口座に当選金額を入金するように要求する。ネット銀行システム２は、当該要求に応じてユーザの口座に当選金額を入金する。当選金額の入金もＡＰＩによって実現されるようにすればよい。

【0120】

例えば、ネット銀行のくじ購入サービスを地方銀行に連携させる場合、地方銀行をメインバンクとするユーザが所定の利用申込を行うと、実施形態と同様の手順に沿って、ネット銀行の専用支店に口座が開設される。そして、地方銀行のユーザの口座と、ネット銀行に開設されたユーザの口座と、が関連付けられた第１連携情報が生成される。この点は、実施形態で説明した通りである。本変形例では、証券会社のサービスではなく、くじの運営主体は口座の開設業務を行っていないものとする。このため、くじの運営主体にはユーザの口座は開設されない。

【0121】

ユーザは、地方銀行のウェブサイト等からくじの購入操作を行うと、地方銀行システム１は、地方銀行のユーザの口座から、購入代金に応じた額を出金し、ネット銀行のユーザの口座に入金する。地方銀行システム１とネット銀行システム２との間の入出金は、実施形態で説明したＡＰＩと同様のＡＰＩを利用して実現すればよい。ネット銀行システム２は、当該口座への入金に基づいて、くじの購入処理を実行する。くじの購入処理は、上記説明した既存のくじ購入サービスに係るＡＰＩによって実行される。既存のくじ購入サービスとは、先述したサービスであり、地方銀行を利用していないネット銀行のユーザも利用可能なサービスである。

【0122】

以上のように、ネット銀行のくじ購入サービスを地方銀行に公開する場合についても、実施形態で説明した処理を流用することによって、地方銀行のユーザが、ネット銀行の口座を介して、くじを購入できるようになる。この場合も既存のくじ購入サービスに係る機能を流用することで、金融機関とくじの運営主体とを連携させる際の導入コストを軽減することができる。

【0123】

なお、くじの運営主体が口座の開設業務を行っていれば、くじの運営主体についても、ユーザの口座が開設されてもよい。この場合には、ネット証券の口座を介して、地方銀行の口座と、くじの運営主体の口座と、の間の入出金を実行すればよいので、実施形態と同様の処理によって実現すればよい。即ち、実施形態におけるネット証券の記載をくじの運営主体と読み替えればよい。また、上記変形例では、ネット銀行のくじ購入サービスと地方銀行が連携する場合について説明したが、他の任意のサービスについても同様の処理によって連携することができる。

【0124】

また例えば、ネット銀行サーバ２０によって実現されるものとして説明した機能は、他のコンピュータによって実現されてもよいし、複数のコンピュータによって分担されてもよい。例えば、データ記憶部２００は、ネット銀行サーバ２０とは別のデータベースサーバで実現されてもよい。

【符号の説明】

【0125】

１ 地方銀行システム、２ ネット銀行システム、３ ネット証券システム、Ｎ ネットワーク、１０ 地方銀行サーバ、１１，２１，３１，４１ 制御部、１２，２２，３２，４２ 記憶部、１３，２３，３３，４３ 通信部、２０ ネット銀行サーバ、３０ ネット証券サーバ、４０ ユーザ端末、４４ 操作部、４５ 表示部、ＤＢ１，ＤＢ２，ＤＢ５ 口座データベース、ＤＢ３ 第１連携データベース、ＤＢ４ 第２連携データベース、１００ データ記憶部、１０１ 入出金制御部、２００ データ記憶部、２０１ 口座開設部、２０２ 第１取得部、２０３ 第２取得部、２０４ 入出金制御部、２０５ 表示制御部、２０６ 受付部、２０７ 生成部、３００ データ記憶部、３０１ 入出金制御部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】