JP5752110B2 - 送金装置および送金方法 - Google Patents

Description

本発明は、主に外貨送金処理を行う送金装置および送金方法に関するものである。

現在の外貨送金処理は、例えば以下のような流れで行われている。なお、ここでは日本からアメリカの銀行に送金する場合を例にして説明する。
（１）送金者は、送金者が口座を開設している銀行（仕向銀行）に出向き、外貨送金用の書類に必要事項を記載した上で資金を口座に入金する。
（２）仕向銀行は所定事項を確認し必要な情報を付加した後、外為事務受託銀行に送金を行う。
（３）外為事務受託銀行はアメリカの銀行（これを例えば「Ｘ銀行」とする）に口座を開設している。外為事務受託銀行は所定事項を確認し必要な情報を付加した後、このＸ銀行に送金を行う。
（４）Ｘ銀行は所定事項を確認し必要な情報を付加した後、受取人が口座を開設している銀行（被仕向銀行）に送金を行う。
（５）受取者は被仕向銀行にて資金を引き出す。

この出願の発明に関連する先行技術文献情報としては次のものがある。
国内の各銀行が発行している「外国送金依頼書」。発行日や発行者は不明だが、外国送金を取り扱う銀行窓口で簡単に入手できるものである。ここには顧客が外国送金を行う際に記入すべき内容が掲載されている。

従来の外貨送金は以上のよう形で行われてるが、従来の外貨送金には以下のような問題がる。
（１）これまでの外貨送金は複数の銀行や処理機関が関与して行われている。そして、すべての銀行・機関との間で資金移動が伴うため、各々の銀行・機関において情報の確認作業や情報の付加作業を繰り返す必要があり、受取者へ送金が完了するまでに時間がかかる（１週間近くかかる）という問題がある。
（２）また、送金者は送金を行う度に必要書類に情報を全て記載しなければならず手続が煩雑となり、そのため記載ミスも生じやすく送金トラブルの大きな原因となっていた。
本発明はこのような問題に鑑みなされたものであり、外貨送金を迅速・簡便・確実に行うことを可能にする装置等を提供するものである。

前記課題は、本発明の送金装置によれば、資金の送金者と資金の受取者とその受取者の資金引出特定情報とを関連づけた送金登録レコードを複数集めた送金登録ファイルを記憶する送金登録ファイル記憶手段と、前記送金登録ファイルに含まれる１つの送金登録レコードを特定するための送金登録レコード特定情報と送金額とを関連づけた送金情報を顧客が利用する顧客端末から受信する送金情報受信手段と、前記送金登録レコード特定情報に該当する送金登録レコードを前記送金登録ファイルから検索する送金登録レコード検索手段と、前記受取者は団体であって、該団体から団体構成員に資金を再配分するための再配分金とそれを受け取る前記団体構成員である再配分金受取者とを関連づけた再配分データを受信する再配分データ受信手段と、検索された前記送金登録レコードに含まれる前記資金引出特定情報と前記送金情報に含まれる前記送金額とを関連づけた情報又は前記再配分金受取者の資金引出特定情報と前記再配分金とを関連づけた情報である引出許可判断情報を作成して記憶する引出許可判断情報記憶手段と、資金を引き出すための資金引出装置から資金引出特定情報と出金額とを関連づけた出金許可要請情報を受信する出金許可要請情報受信手段と、前記出金許可要請情報の前記資金引出特定情報と前記引出許可判断情報の前記資金引出特定情報とが一致するか否か、及び、前記出金額が前記送金額又は前記再配分金の範囲内か否かに基づいて前記出金額の出金を認めるか否かを判断し、出金の許可をする場合は出金許可情報を前記資金引出装置に送信する出金許可情報送信手段と、前記団体構成員のうち送金先の国から送金元の国に帰国した団体構成員を特定する帰国者特定情報を受信する帰国者特定情報受信手段と、前記帰国者特定情報により特定される帰国者の前記資金引出特定情報を含む前記出金許可要請情報を受信した場合その出金を不許可とする処理を行う出金不許可手段と、を備えること、により解決される。
また、本発明の送金装置によれば、前記帰国者特定情報により特定される帰国者の実質的に必要となる資金を管理する実質口座に関連づけられている実質送金額を予備的な資金を管理する予備口座に組み入れる予備口座組入手段をさらに備えること、により解決される。
また、本発明の送金装置によれば、前記送金額には実質送金額と予備送金額とが含まれ、実質的に必要となる資金を管理する実質口座と前記実質送金額と前記受取者とを関連づけた実質送金情報を記憶する実質送金情報記憶手段と、予備的な資金を管理する予備口座と前記予備送金額とを関連づけた予備送金情報を記憶する予備送金情報記憶手段と、をさらに備えること、により解決される。

前記課題は、本発明の送金方法によれば、コンピュータが、資金の送金者と資金の受取者とその受取者の資金引出特定情報とを関連づけた送金登録レコードを複数集めた送金登録ファイルを記憶する送金登録ファイル記憶ステップと、前記送金登録ファイルに含まれる１つの送金登録レコードを特定するための送金登録レコード特定情報と送金額とを関連づけた送金情報を顧客が利用する顧客端末から受信する送金情報受信ステップと、前記送金登録レコード特定情報に該当する送金登録レコードを前記送金登録ファイルから検索する送金登録レコード検索ステップと、前記受取者は団体であって、該団体から団体構成員に資金を再配分するための再配分金とそれを受け取る前記団体構成員である再配分金受取者とを関連づけた再配分データを受信する再配分データ受信ステップと、検索された前記送金登録レコードに含まれる前記資金引出特定情報と前記送金情報に含まれる前記送金額とを関連づけた情報又は前記再配分金受取者の資金引出特定情報と前記再配分金とを関連づけた情報である引出許可判断情報を作成して記憶する引出許可判断情報記憶ステップと、資金を引き出すための資金引出装置から資金引出特定情報と出金額とを関連づけた出金許可要請情報を受信する出金許可要請情報受信ステップと、前記出金許可要請情報の前記資金引出特定情報と前記引出許可判断情報の前記資金引出特定情報とが一致するか否か、及び、前記出金額が前記送金額又は前記再配分金の範囲内か否かに基づいて前記出金額の出金を認めるか否かを判断し出金の許可をする場合は出金許可情報を前記資金引出装置に送信する出金許可情報送信ステップと、前記団体構成員のうち送金先の国から送金元の国に帰国した団体構成員を特定する帰国者特定情報を受信する帰国者特定情報受信ステップと、前記帰国者特定情報により特定される帰国者の前記資金引出特定情報を含む前記出金許可要請情報を受信した場合その出金を不許可とする処理を行う出金不許可ステップと、を行うこと、により解決される。
本発明の送金方法によれば、前記コンピュータが、前記帰国者特定情報により特定される帰国者の実質的に必要となる資金を管理する実質口座に関連づけられている実質送金額を予備的な資金を管理する予備口座に組み入れる予備口座組入ステップをさらに行うこと、により解決される。
本発明の送金方法によれば、前記送金額には実質送金額と予備送金額とが含まれ、前記コンピュータが、実質的に必要となる資金を管理する実質口座と前記実質送金額と前記受取者と関連づけた実質送金情報を記憶する実質送金情報記憶ステップと、予備的な資金を管理する予備口座と前記予備送金額とを関連づけた予備送金情報を記憶する予備送金情報記憶ステップと、をさらに行うこと、により解決される。

（１）本発明は、送金者と受取者の情報を予め関連づけて登録しているので非常に送金手続が簡便且つ確実なものとなる。即ち、一度登録してしまえば、それ以降は送金の度に受取者の口座番号や連絡先等の情報を記載する必要がないので非常に簡便で、且つ、書き間違いにより送金が遅れる等の問題も生じない。また、これにより所定用紙への記入の必要性がなくなり全てＡＴＭやコンピュータ等の情報端末を利用して行えるので利便性がより高まる。
（２）本発明では、受取者のクレジットカード番号を知っていれば送金ができ、受取者もクレジットカードを持っているだけで送られた資金を引き出すことができる。すなわち、受取者の口座番号等の情報を一切利用せずに送金をすることができる。また、受取者は引出許可要請情報を受け入れる態勢がある金融機関・ＡＴＭ（クレジットカード会社と提携関係にある金融機関・ＡＴＭ）であればどこからでも資金を引き出すことができるので、数多くのＡＴＭ等から簡単に資金を引き出すことができる。
（３）本発明では、引出許可要請情報送信後に引出が可能になったことを送金者と受取者に電子メール等で知らせるので、送金者・受取者は送金が完了したことをいち早く知ることができる。
（４）本発明は、送金手続に関し、資金移動を伴わず送金データのみが流通するだけなので、非常に迅速に送金額を引出可能な状態にすることができる。
（５）本発明では、バーチャル口座に入金することにより送金を行うので、既存のＡＴＭからも容易に送金手続が行える。即ち、既存のＡＴＭから外国送金に必要な情報を入力するためには大幅なシステム変更が必要になるが、本発明ではバーチャル口座を設け、そこに入金する形で送金を行うのでシステム変更の必要もなく、既存のＡＴＭからも容易に送金ができるのである。また、このバーチャル口座は送金専用の口座であり資金の引出等が行えない口座なので安全・確実に送金することができる。
（６）本発明では、送金者は受取者のクレジットカード番号を知っていれば受取口座を知らなくても送金ができるので非常に手続が簡便なものとなる。また、一度登録した後は、バーチャル口座番号を知っていれば送金できるので手続が非常に簡便なものとなる。
（７）本発明は、クレジットカード会社のネットワークとデータベースを活用するので非常に迅速且つ確実な送金処理を行える。即ち、クレジットカード会社が管理するデータベースは非常に正確性の高いデータであるため送金処理を確実に行えるのである。
（８）本発明では、受取者のクレジットカード番号等をクレジットカード会社が管理するデータベースで確認してから登録するので、登録内容がより正確なものとなる。
（９）本発明では、送金情報受信後、送金者に送金したことを確認するので、誰かが不正に送金者になりすまして送金してしまう不都合を回避できる。
（１０）本発明では、送金に関する資金保全管理責任区分を設けるので、管理責任の所在を明らかにすることができる。よって、不測のトラブルが生じた場合でも送金の責任機関をすぐに特定でき、どこが責任を負うのかで紛争が生じることがなく、結果として送金者への補償をより迅速に行うことができる。
（１１）本発明では、受取者がクレジットカードを所有していない場合は、すぐに受取者の受取用のカード作成処理に進むので、クレジットカードを持っていない人にも速やかに送金できる。
（１２）本発明では、送金された資金を他の通貨に変更できるので、改めて銀行窓口で通貨を変更する手間を省くことができる。

本発明で利用するハードウェアの概略図の一例である。 本発明で利用する処理フローの一例を示す図である。 本発明で利用する口座利用申請データの一例を示す図である。 本発明で利用するカード番号確認要請データの一例を示す図である。 本発明で利用するクレジットカード所有者情報ファイルの一例を示す図である。 本発明で利用するカード番号確認済データの一例を示す図である。 本発明で利用する口座ファイルの一例を示す図である。 本発明で利用する口座番号等通知データの一例を示す図である。 本発明で利用する第１送金データの一例を示す図である。 本発明で利用する第２送金データの一例を示す図である。 本発明で利用する送金確認要請データの一例を示す図である。 本発明で利用する送金確認データの一例を示す図である。 本発明で利用する第３送金データの一例を示す図である。 本発明で利用する引出許可要請情報の一例を示す図である。 本発明で利用する確認済データの一例を示す図である。 本発明で利用する引出可能通知の一例を示す図である。 本発明で利用する出金許可要請情報の一例を示す図である。 本発明で利用する出金許可情報データの一例を示す図である。 本発明で利用する口座利用データの一例を示す図である。 本発明で利用するカード作成命令データの一例を示す図である。 本発明で利用する通貨変更依頼データの一例を示す図である。 本発明で利用する為替ファイルの一例を示す図である。 本発明で利用する通貨変更算出後データの一例を示す図である。 本発明で利用する引出許可判断情報の一例を示す図である。 本発明で利用する未付与資金引出番号の一例を示す図である。 本発明で利用する口座利用データの他の一例を示す図である。 本発明で利用する口座ファイルの他の一例を示す図である。 本発明で利用する資金引出特定情報通知データの一例を示す図である。 本発明で利用する法人用口座ファイルの他の一例を示す図である。 本発明で利用する口座対応ファイルの一例を示す図である。 送金先支社指定画面とそのデータの一例を示す図である。 送金振分画面とそのデータの一例を示す図である。 本発明で利用する口座対応ファイルの他の一例を示す図である。 引出許可要請情報一例を示す図である。 再振分画面とそのデータの一例を示す図である。 本発明で利用する口座対応ファイルの他の一例を示す図である。 引出許可要請情報一例を示す図である。 帰国報告画面とそのデータの一例を示す図である。 本発明で利用する口座対応ファイルの他の一例を示す図である。 引出許可要請情報一例を示す図である。

本発明は、外国送金に関する処理を行う装置等に関するものである。以下、図面に基づいて説明する。

まず、従来技術と本発明との違いを簡単に説明する。
従来技術では、「仕向銀行→外為事務受託銀行→Ｘ銀行（外為事務受託銀行が口座を開設している銀行）→被仕向銀行」という流れで送金処理がなされ、実際に資金移動が伴う形で外貨送金を行っている。一方、本発明では「送金元銀行のサーバー→仕向銀行のサーバー→送金仲介サーバー→クレジットカード会社のサーバー→提携金融機関サーバー」という流れで送金処理がなされ、この際に資金移動は伴わず送金データのみが流通する形で外貨送金を行う。即ち、両者は実際の資金移動が伴う、伴わないという点で大きく異なる。
また、従来技術は受取者の口座番号が必須であるのに対し本発明は受取者の口座番号は利用せずクレジットカード番号が必須である点で大きく異なる。

次に、本発明で利用するハードウェアについて説明する。
図１は本発明の実施に必要なハードウェアの概略を表した図である。本発明は外貨送金を行うための送金仲介サーバー、クレジットカード会社が利用するサーバー、送金元銀行が利用するサーバー、仕向銀行が利用するサーバー、Ｄ社と提携関係にある金融機関が利用するサーバー（提携金融機関サーバー）、送金者が利用するパーソナルコンピュータ（ＰＣ）、資金の受取用カードを作成する会社が利用するサーバーとからなる。また、仕向銀行や提携金融機関サーバーにはＡＴＭ（現金自動預け払い機）が接続されている。
これらは情報の入出力装置、情報の記憶装置、情報の処理装置を備えたコンピュータである。これら記憶装置には本発明を実現するためのコンピュータプログラムや所定のデータが記憶されており、処理装置はこのコンピュータプログラムの処理命令に従って所定の処理を行う。これら装置は各々インターネット等の通信手段により情報の送受信が可能となっている。なお、各装置はデータを受信した場合、受信したデータを記憶装置に記憶するものである。
本実施例において、仕向銀行が利用するサーバーと送金仲介サーバーとクレジットカード会社が利用するサーバーとが送金装置又は送金仲介装置としての役割を果たす。ただし、提携金融機関サーバーとＡＴＭが送金装置に含まれる場合もある。更に、送金者が利用するＰＣが顧客端末としての役割を果たし、カード作成会社が利用するサーバーがカード作成装置としての役割を果たし、提携金融機関サーバーとＡＴＭとが資金引出装置としての役割を果たす（ただし、資金引出装置はＡＴＭのみであってもよい）。
次に、本発明の処理フローについて説明する。本発明は、図２のような流れで実行される。なお、図２の「Ｓ１」、「Ｓ２」などは「ＳＴＥＰ１」、「ＳＴＥＰ２」を表すものである。以下、これら処理について説明する。

＜ＳＴＥＰ１：口座利用申請＞
まず、口座利用申請から説明する。
山田太郎さん（送金者）はアメリカに住んでいる三田一夫さん（受取者）に送金したいと考えている。
山田さんはまず海外送金をするために必要な口座（バーチャル口座）の利用申請を行う。この申請を行うため山田さんは送金者ＰＣを利用して所定のウェブページにアクセスして必要事項を入力する。そして、送金者ＰＣは入力された情報（図３のような口座利用申請データ）を送金仲介サーバーに送信する。なお、このバーチャル口座は送金者と受信者とを結びつける（関連づける）情報であり、送金者が山田さんであり且つ受信者が三田さんである場合にのみ利用できるものである。よって、山田さんがフランスにいる広田さんに送信する場合は山田さんと広田さんを結びつける他のバーチャル口座番号が設定される。また、ここではＢ銀行をインターネット銀行という設定にしているので口座番号をバーチャル口座としているが通常の銀行で利用されている普通の口座番号であってもよい。
以上がＳＴＥＰ１である。

＜ＳＴＥＰ２：申請内容確認・カード番号等確認要請＞
口座利用申請データを受信した送金仲介サーバーは情報の漏れや誤りがないか等のデータの正当性を確認する。なお、この口座利用申請データを受信する送金仲介サーバーが送金登録レコード受信手段としての役割を果たす。
正当性が確認された場合、送金仲介サーバーは、クレジットカード番号等の確認するためクレジットカード会社のサーバーに問い合わせを行う。
具体的には、送金仲介サーバーは、図４のようなカード番号確認要請データを作成し、これをクレジットカード会社サーバーに送信する。なお、このカード番号確認要請データの確認区分は「未確認」になっている。
以上がＳＴＥＰ２である。

＜ＳＴＥＰ３：カード番号等確認＞
図１のクレジットカード会社サーバーの記憶装置には図５のようなクレジットカード所有者情報ファイルが記憶されている。これはクレジットカード所有者の様々な情報が複数集まった情報であるが、このクレジットカード所有者情報ファイルはクレジットカード会社が保有・管理している情報であるため非常に正確性の高い情報である。なお、本実施例では、クレジットカード所有者情報が金融機関情報としての役割を果たし、これを記憶するクレジットカード会社サーバーの記憶装置がクレジットカード所有者情報記憶手段・金融機関情報記憶手段としての役割を果たし、カード所有者の金融機関名（カード利用者が利用している金融機関名）が金融機関としての役割を果たし、カード所有者名がクレジットカード所有者としての役割を果たし、カード番号がクレジットカード番号としての役割を果たす。
送金仲介サーバーは受信したカード番号確認要請データに含まれるクレジットカード番号とクレジットカード所有者情報に含まれる三田さんのクレジットカード番号とを比較して双方が一致するか否かを確認する（クレジットカード番号の正当性を確認する）。なお、この正当性を確認するクレジットカード会社サーバーがカード番号確認手段としての役割を果たす。
以上がＳＴＥＰ３である。

＜ＳＴＥＰ４：確認済データ＞
次に、クレジットカード番号等の正当性を確認したクレジットカード会社サーバーは図６のようなカード番号確認済データを作成し、これを送金仲介サーバーに送信する。なお、このカード番号確認済データの確認区分は「確認済」になっている。また、クレジットカード番号がクレジットカード所有者情報にない場合は予めクレジットカード会社サーバーに記憶されているエラーメッセージ（第１エラーメッセージ）「このカード番号は登録されておらず正当ではありません」等を送金仲介サーバーに送信する。なお、このメッセージを記憶するクレジットカード会社サーバーの記憶装置が第１エラーメッセージ記憶手段としての役割を果たし、第１エラーメッセージを送信するクレジットカード会社サーバーが第１エラーメッセージ送信手段としての役割を果たす。
以上がＳＴＥＰ４である。

＜ＳＴＥＰ５：口座番号等通知＞
次に、送金仲介サーバーは山田さんが海外送金するときに使用する銀行（Ｂ銀行）・口座番号（インターネットやＡＴＭから利用できるバーチャル口座の番号）・送金時に利用する閲覧用ＩＤ・パスワードを設定する。なお、この閲覧用ＩＤやパスワード等は送金仲介サーバーの記憶装置に予め記憶されているものとする。

次に、送金仲介サーバーは口座利用申請データや閲覧用ＩＤ・パスワード等の情報に基づいて口座レコードを作成し、それを図７のような口座ファイルの１レコードとして記憶装置に記憶する。なお、本実施例において、図７の口座レコードが送金登録レコードとしての役割を果たし、口座ファイルが送金登録ファイルとしての役割を果たし、口座レコードに含まれる送金者メールアドレスが送金者の連絡先としての役割を果たし、口座レコードに含まれる受取者のクレジットカード番号が受取者のクレジットカード番号としての役割を果たし、口座レコードに含まれる受取者のメールアドレスが受取者の連絡先としての役割を果たし、この口座レコードを記憶する送金仲介サーバーの記憶装置が送金登録ファイル記憶手段としての役割を果たし、受取者連絡先を記憶する送金仲介サーバーの記憶装置が受取者連絡先情報記憶手段としての役割を果たす。
次に、送金仲介サーバーは、図７の口座ファイルに基づいて図８のような口座番号等通知データを作成し、それを山田さんの連絡先（メールアドレス）に送信する。これにより山田さんは外国送金時に利用すべき口座番号や自分のＩＤやパスワード等を知ることができる。
以上がステップ５である。

＜ＳＴＥＰ６：第１送金データの送信処理＞
次に、第１送金データの送信処理について説明する。
山田さんは三田さんに資金を送るため送金元銀行（Ａ銀行）のＡＴＭを利用して送金元銀行からＢ銀行のバーチャル口座に対して入金処理を行う。即ち、山田さんは送金元銀行のＡＴＭから所定の情報を入力し、これにより送金元銀行サーバーは図９のような第１送金データを作成し、これをＢ銀行のサーバー（仕向銀行サーバー）に送信し、これにより山田さんのバーチャル口座に送金額が入金される。なお、本実施例では、この第１送金データが送金情報としての役割を果たし、この第１送金データに含まれるバーチャル口座番号が送金登録レコード特定情報・レコード固有の固有情報・外国送金用口座としての役割を果たし、送金金額が送金額としての役割を果たし、第１送金データを受信する仕向銀行サーバーが送金情報受信手段としての役割を果たす。
なお、本実施例では送金元銀行のＡＴＭを操作して入金をしているが、ＡＴＭでなく所定のパーソナルコンピュータや携帯電話等から入金を行っても良い。
以上がステップ６である。

＜ＳＴＥＰ７：受信内容確認・資金保全責任区分設定・第２送金データ送信＞
次に、受信内容確認及び資金保全区分設定について説明する。
Ｂ銀行の仕向銀行サーバーは定期的（例えば、３０分毎）に顧客のバーチャル口座に入金がなされたか否か（第１送金データが受信されたか否か）を確認し、入金があった場合は受信した第１送金データの正当性を確認する。なお、ここでの確認内容は一般的な確認であり、既知であるため説明は省略する。
第１送金データの正当性を確認した仕向銀行サーバーは、受信した第１送金データに「資金保全責任区分（資金保全区分）＝Ｂ銀行（仕向銀行：国内送金機関）」という項目を付加した第２送金データ（図１０）を作成し、これを送金仲介サーバーに送信する。この資金保全責任区分は第１送金データを受信しその内容が正当と確認された場合、送金データに含まれる送金金額を保全する責任がＢ銀行に発生したことを意味する。なお、本実施例において、この仕向銀行サーバーが資金保全区分付与手段としての役割を果たす。
以上がステップ７である。

＜ＳＴＥＰ８：受信内容確認・手数料算出）＞
送金仲介サーバーは、定期的（例えば、４５分毎）に仕向銀行サーバーから第２送金データの受信がなされたか否かを確認し、受信がされた場合は第２送金データに含まれるバーチャル口座番号に基づいて図７の口座ファイルを検索し、山田さんのレコードを抽出する。なお、ここで抽出したレコードは次のＳＴＥＰ９で使用される。また、本実施例では、この検索処理を行う送金仲介サーバーが送金登録レコード検索手段としての役割を果たす。
次に、送金仲介サーバーは送金手数料等の算出処理を行う。
送金仲介サーバーの記憶装置には送金手数料を算出するための数式やデータファイルが記憶されている（図示せず）。例えば、「手数料＝送金金額の３％」という数式データであったり、「１００アメリカドルまでは１０円、１０１アメリカドル〜５００アメリカドルまでは２０円、…」のような送金額と手数料とを関連づけたデータファイルであってもよい。
送金仲介サーバーは記憶装置に「手数料＝送金金額の３％」と記憶されていた場合、今回の送金額は９００アメリカドルなので送金仲介サーバーは手数料を２７アメリカドルと算出する。
以上がステップ８である。

＜ＳＴＥＰ９：送金確認要請＞
次に、送金確認要請処理について説明する。
今回の送金は山田さんから三田さんへの送金であるが、何者かが不正をして山田さんになりすまして三田さんに送金を依頼した可能性もある。よって、ここでは山田さんが本当に三田さんに送金しようとしているのかを確認する。
送金仲介サーバーは、ＳＴＥＰ８で算出した手数料とＳＴＥＰ８で抽出した山田さんの口座レコード（図７）とに基づいて図１１のような送金確認要請データを作成し、これを山田さんのメールアドレスに送信する。なお、この時点で送金確認要請 データの送金者ＩＤ・送金者パスワードは未入力であり、送金確認区分は未確認となっている。また、本実施例では、送金確認データが送金確認要求としての役割を果たし、これを送信する送金仲介サーバーが送金確認要求送信手段としての役割を果たす。
以上がステップ９である。

＜ＳＴＥＰ１０：送金確認＞
確認要請をされた山田さんは送金ＰＣや携帯電話等を操作して送金確認用のウェブページにアクセスし、そこでサイト閲覧用ＩＤやパスワードを入力する。これにより送金ＰＣは図１２のような送金確認データを作成する。なお、この送金確認データには送金者ＩＤ（サイト閲覧用ＩＤ）と送金者のパスワードが代入されている。送金ＰＣは、この送金確認データを送金仲介サーバに送信する。また、本実施例では、この送金確認データが送金確認済情報としての役割を果たし、これを受信する送金仲介サーバーが送金確認済情報受信手段としての役割を果たす。
以上がステップ１０である。

＜ＳＴＥＰ１１：認証処理＞
次に、送金仲介サーバーは受信した送金確認データに含まれる送金者ＩＤ・パスワードと口座ファイル（図７）のサイト閲覧用ＩＤ・パスワードとを比較し一致する場合はそれらが正当であると判断し（山田さんが本当に送金したものと判断し）、正当性が確認された場合は次の処理に進む。なお、これにより図１２の送金確認区分が確認済に更新される。一方、正当性が確認できない場合は再度の確認要求等を送金者に行い、正当性が確認できるまでは後述する引出許可要請情報の送信処理には進まない。
本実施例では、口座レコードに含まれるサイト閲覧用ＩＤとパスワードが送金者を認証するための認証情報としての役割を果たし、口座レコードが送金者認証情報としての役割を果たし、これを記憶している送金仲介サーバーの記憶装置が送金者認証情報記憶手段としての役割を果たし、この認証処理を行う送金仲介サーバーが認証情報確認手段としての役割を果たす。
以上がＳＴＥＰ１１である。

＜ＳＴＥＰ１２：第３送金データ送信＞
次に、第３送金データに関する処理について説明する。
送金仲介サーバーは、記憶装置に記憶されている第２送金データ等に基づいて図１３のような第３送金データを作成し、これをクレジットカード会社サーバーに送信する。
以上がステップ１２である。

＜ＳＴＥＰ１３：カード番号確認・金融機関特定・引出許可要請送信＞
クレジットカード会社では第３送金データに含まれるクレジットカード番号が存在するか否かを（ＳＴＥＰ５における口座レコード記憶後に退会等の理由によりカード番号が消滅していないか）を確認する。
クレジットカード会社サーバーはそれを確認するため第３送金データに含まれるクレジットカード番号を検索キーにしてクレジットカード所有者情報ファイルを検索して図５に表されているクレジットカード所有者レコードを抽出し、クレジットカード番号の存在を確認する。なお、本実施例では、この検索処理を行うクレジットカード会社サーバーが金融機関検索手段としての役割を果たす。
次に、クレジットカード会社サーバーは、検索されたクレジットカード所有者情報レコードに含まれる銀行（Ｄ社が提携している金融機関：ここではＥ銀行）を特定する。
次に、送金仲介サーバーは第３送金データに基づいて図１４のような引出許可要請情報を作成しこれをＥ銀行が利用するサーバー（提携金融機関サーバー）に送信する。この引出許可要請情報は受取者がクレジットカード番号と出金額（引出額）を指定して出金（引出）の許可要求をしてきた場合は、それに対し許可することを提携金融機関に要請するための情報である。なお、本実施例では、この引出許可要請情報を作成・送信するクレジットカード会社サーバーが引出許可要請情報作成手段・引出許可要請情報送信手段としての役割を果たす。
以上がステップ１３である。

＜ＳＴＥＰ１４：引出許可要請受信＞
引出許可要請情報を受信した提携金融機関サーバーはこれを記憶装置に記憶する。なお、本実施例では、提携金融機関サーバーが引出許可要請記憶手段としての役割を果たし、提携金融機関サーバーと後述する受取者が利用するＡＴＭが資金引出装置としての役割を果たす。ただし、資金引出装置はＡＴＭだけでも良い場合がある。
以上がステップ１４である。

＜ＳＴＥＰ１５：確認済データ送信＞
ＳＴＥＰ１３にてクレジットカード番号の存在を確認したクレジットカード会社サーバーは、図１５のようなクレジットカードの確認済通知（確認済データ）を送金仲介サーバーに送信する。
以上がステップ１５である。

＜ＳＴＥＰ１６：資金保全責任更新＞
クレジットカード番号確認済通知を受信した送金仲介サーバーは図１３の第３送金データの資金保全責任区分を「Ｂ銀行」から「Ｄ社（クレジットカード会社：国外送金機関）」に更新する。即ち、第３送金データが送信され、そのクレジットカード番号の存在が確認された後は山田さんの送金額の保全責任はＢ銀行からＤ社に移行したことになる。なお、本実施例において、送金仲介サーバーが資金保全者更新手段としての役割を果たす。
以上がステップ１６である。

＜ＳＴＥＰ１７：引出可能通知＞
次に、送金仲介サーバーは、記憶装置に記憶されている引出可能通知（銀行から引出すことが可能になった旨を知らせるメッセージ：図１６）を送金者のメールアドレス及び受取者のメールアドレスに送信する。
これにより送金額が引き出し可能になったことを送金者と受取者が知ることができる。なお、本実施例において、この引出可能通知を記憶する送金仲介サーバーの記憶装置が引出可能通知記憶手段としての役割を果たし、引出可能通知を送信する送金仲介サーバーが引出可能通知送信手段としての役割を果たす。
以上がステップ１７である。

＜ＳＴＥＰ１８：クレジットカード番号受信・引出許可＞
引出可能通知を受信した三田さん（受取者）は送金額を引き出すためＡＴＭのところに出向き、ＡＴＭにクレジットカード番号を読み取らせると共に所定の操作により出金額（引出額）を入力する。ＡＴＭと提携金融機関サーバーとは所定の通信回線で接続されておりＡＴＭは図１７のようなクレジットカード番号と出金額を含む出金許可要請情報を作成し、これを提携金融機関サーバーに送信する。これを受信した提携金融機関サーバーはＳ１４で記憶した引出許可要請情報（図１４）のクレジットカード番号とＡＴＭから送られたクレジットカード番号とが一致するか、更に引出許可要請情報に含まれる送金額を出金額が超えていないかを確認する（出金を認めるか否か判断する）。
そして、クレジットカード番号が一致し且つ送金額を出金額が超えていなければ図１８のような出金許可情報をＡＴＭに送信し、これにより受取者である三田さんは資金を引き出すことができる。
なお、本実施例では、提携金融機関サーバーの処理とＡＴＭの処理とを分けて説明したが、これら処理を１つの装置で行ってもよい。また、本実施例では、ＡＴＭ・提携金融機関サーバーが出金許可要請情報受信手段・出金許可情報送信手段としての役割を果たす。
以上が実施例１の処理内容である。

なお、本発明は、当初は送金データのみが流通するものであり資金は移動しないが、現実の資金移動は後日行われる。

実施例１では、受取者が予めクレジットカードを所有しているケースについて説明したが、本実施例では受取者がクレジットカードを所有していないケースについて説明する。
なお、本実施例の処理内容は原則として実施例１と同様であるが、ＳＴＥＰ２において処理内容が異なる。以下、その点について説明する（これをＳＴＥＰ２．１として説明する）。

＜ＳＴＥＰ２．１：クレジットカード作成命令処理＞
送金仲介サーバーは、図１９のような口座利用申請データ（カード所有情報）を受信した。なお、これは「受取者のクレジットカード所有区分：無（受取者がクレジットカードを所有していないことを意味する）」、「受取者のクレジットカード番号：情報なし」となっている点で実施例１と異なる。
「受取者のクレジットカード所有区分：無」を確認した送金仲介サーバーは、この口座利用申請データに基づいて図２０のようなカード作成命令データ（カード作成指示情報）を作成する。
送金仲介サーバーはカード作成サーバーにカード作成命令データを送信する。
これにより三田さんにカード作成のための情報が届き、三田さんがカードを作成するための所定の手続きを行った後、三田さんのカードが作成され、三田さんの手元に届けられる。そして、作成されたカードの情報を口座利用申請データの「受取者のクレジットカード番号」に代入すれば、その後実施例１と同様の処理により送金が可能となる。
なお、ここで作成されるカードは送金を受け取るためだけの受取専用カードであることが望ましいが、通常のクレジットカードであっても良い。
本実施例において、送金仲介サーバーがカード所有情報受信手段・カード作成指示情報作成手段・カード作成指示情報送信手段としての役割を果たす。
以上が実施例２である。

実施例１では、受取者が９００アメリカドルの送金を受けたらそのままアメリカドルで資金を引き出すケースを想定して説明したが、本実施例では受取者がアメリカドルを他の通貨に変更して引き出すケースを説明する。なお、本実施例の処理内容は原則として実施例１と同様であり、ここでは異なる部分だけをＳＴＥＰ２０として説明する。

＜ＳＴＥＰ２０：通貨変更処理＞
実施例１の処理により三田さんには９００アメリカドルが送金された。三田さんは急にロンドンに出張になったので、その資金をポンド（希望通貨）で引き出したいと考えた。三田さんはＡＴＭを操作して図２１のような通貨変更依頼データ（通貨変更希望情報）を入力する。ＡＴＭ（又は提携金融機関サーバー）には図２２のような為替ファイル（為替情報）が記憶されており、ＡＴＭ（又は提携金融機関サーバー）はこの為替ファイルに基づいて対象となる９００アメリカドルをポンド（変更後送金額）に変換する。即ち、希望通貨であるポンドに。なお、この場合、所定の手数料を徴収しても良い。これによりＡＴＭ（又は提携金融機関サーバー）は図２３のような通貨変更算出後データを作成し、山田さんから送られた額を９００アメリカドルを通貨変更後資金（ポンド）に更新する。これにより三田さんは通貨を変更して変更後の通貨を引き出すことが可能となる。
なお、本実施例においてＡＴＭ又は提携機関サーバーが為替情報記憶手段・通貨変更希望情報受信手段・通貨変更手段・送金額更新手段としての役割を果たす。

次に実施例４について説明する。本実施例は実施例１と共通する処理が多いので、ここでは実施例１と異なる点を説明し、共通する処理については説明を省略する。まず、本実施例と実施例１との相違点を説明する。
相違点１：実施例１では、各処理を３つの装置（送金仲介サーバー・クレジットカード会社サーバー・提携金融機関サーバー）に分けて行っていたが、本実施例ではこれらの処理を原則として送金仲介サーバーだけで行う。
相違点２：実施例１では、受取人からの出金要請に対し、出金を認めるか否かの判断をＡＴＭ又は提携金融機関サーバーが行っていたが、本実施例ではこの判断を送金仲介サーバーが行う。よって、実施例１のように提携金融機関サーバーに引出許可を要請するために「引出許可要請情報」を作成・送信するのではなく、本実施例では送金仲介サーバーが引出許可を行うための「引出許可判断情報」というデータを作成する。
相違点３：実施例１では資金を引き出すための情報として「クレジットカード番号」を用いていたが、本実施例では「クレジットカード番号」ではなく、その代わりに「資金引出特定番号」を用いる。この資金引出特定情報はクレジットカード番号の上位概念であり、資金引出特定情報の概念にはクレジットカード番号が含まれるものである。
相違点４：実施例１及び実施例２では、受取人がクレジットカードを所有していない場合はクレジットカードを作成するための処理を行っていた。本実施例ではクレジットカード番号の代わりに資金引出特定情報を用いるので、資金引出特定情報の付与を受けていない受取人には新しい資金引出特定情報（未付与資金引出特定情報）を付与するための処理を行う。
以上が本実施例と上記実施例との相違点である。

次に、処理の詳細について説明する。まず、上記相違点１・相違点２・相違点３について説明する。
本実施例では、実施例１の「ＳＴＥＰ１３：引出許可要請送信処理」と同様の処理を行う。実施例１において、送金仲介サーバーは図１４のような引出許可要請情報を作成しているが、本実施例ではこのデータの代わりに図２４のような「引出許可判断情報」を作成する（なお、このデータは図１４の引出許可要請情報とほぼ同じであるが、クレジットカード番号が資金引出特定情報となっている点だけが異なる）。
そして、実施例１では送金仲介サーバーは「引出許可要請情報」をクレジットカード会社サーバーに送信しているが、本実施例では送金仲介サーバーは「引出許可判断情報」を作成して記憶装置に記憶するだけの処理を行う（クレジットカード会社サーバーには送信しない）。なお、本実施例では送金仲介サーバーが引出許可判断情報記憶手段としての役割を果たす。

次に、本実施例でも実施例１の「ＳＴＥＰ１６：資金保全責任更新処理」と「ＳＴＥＰ１７：引出可能通知処理」を行う。なお、ＳＴＥＰ１４とＳＴＥＰ１５は行わなくてもよい。

次に、本実施例では「ＳＴＥＰ１８：クレジットカード番号受信・引出許可処理」と同様の処理を行う。このステップにおいて実施例１ではＡＴＭが出金許可要請情報（図１７）を作成し、これを提携金融機関サーバーに送信しているが、本実施例ではこの出金許可要請情報を送金仲介サーバーに送信する。そして、これを受信した送金仲介サーバーが本実施例のＳＴＥＰ１３で記憶した「引出許可判断情報」の資金引出特定情報（実施例１におけるクレジットカード番号に代わる情報）とＡＴＭから送られた資金引出特定情報（実施例１におけるクレジットカード番号に代わる情報）とが一致するか、更に引出許可判断情報に含まれる送金額を出金額が超えていないかを確認する（出金を認めるか否か判断する）。
そして、資金引出特定情報が一致し且つ送金額を出金額が超えていなければ送金仲介サーバーが図１８のような出金許可情報をＡＴＭに送信し、これにより受取者である三田さんは資金を引き出すことができる。即ち、クレジットカード会社サーバー・提携金融機関サーバーを用いなくとも実施例１と同様の効果を生じさせることができる。
以上が上記相違点１・相違点２・相違点３である。
なお、前述の出金を認めるか否かの判断は実施例１のＳＴＥＰ１１においてＩＤ・パスワードが正当であることが確認された場合にのみ行われるものである。

次に上記相違点４について説明する。
本実施例では「ＳＴＥＰ２．１：クレジットカード作成命令処理」の代わりに「ＳＴＥＰ２．２：資金引出特定情報付与処理」を行う。以下、この処理について説明する。
まず、送金仲介サーバーの記憶装置（未付与資金引出特定情報記憶手段）には未だ顧客（受取人）に付与されていない未付与資金引出特定情報（図２５）が記憶されているものとする。
本実施例では実施例１におけるＳＴＥＰ１と同様の処理を行うが、送金仲介サーバー（資金引出特定情報付与区分データ受信手段）は図３の口座利用申請データの代わりに図２６のような口座利用申請データ（資金引出特定情報付与区分データ）を受信する。なお、このデータは「受取者の資金引出特定情報付与区分：無（受取者に資金引出特定情報が付与されていないことを意味する）」、「資金引出特定情報：情報なし」となっているところに特徴がある。即ち、このデータは受取人である三田さんには未だ資金引出特定情報が割り当てられていないことを表すものである。資金引出特定情報が付与されていないと三田さんは資金を引き出すことができないので、次に資金引出特定情報を三田さんに割り当てるための処理を行う。

口座利用申請データ（図２６）の「受取者の資金引出特定情報付与区分：無」を確認した送金仲介サーバーは、実施例１のＳＴＥＰ５と同様の処理を行うが、ここで図７の口座レコードを作成する代わりに図２７の口座レコードを作成する。そして、その際に図２５の未付与資金引出特定情報「６７８９０」を「受取人の資金引出特定情報」に代入し、受取者の資金引出特定情報付与区分を「有」に更新する。これにより三田さんに資金引出特定情報が付与されたことになる。

次に、送金仲介サーバーは図２８の資金引出特定情報通知データを送金者である山田さんのメールアドレス及び／又は受取者である三田さんのメールアドレスに送信する。これにより受取人に資金引出特定情報が付与されてない場合でも、円滑・迅速に資金引出特定情報を受取人に付与することができ、三田さんは山田さんからの送金を受けることができる。

上記実施例は送金者及び受取人を個人とした例を説明したが、本実施例では送金者を法人（団体）の送金担当者とし、受取者を法人の従業員（団体構成員）とした例について説明する。具体的には、株式会社Fの東京本社からアメリカのフロリダ支社の従業員3人に送金するケースについて説明する。なお、本実施例は上記実施例と同様の部分が多いので、ここでは異なる部分のみを説明する。

まず、本実施例の概要を説明する。例えば、株式会社Ｆのフロリダ支社には鈴木、田中、加藤という３人の従業員がいるとする。東京本社からは当面、鈴木さんに１０００ドル、田中さんに２０００ドル、加藤さんに３０００ドルを送金する必要（合計６０００ドルの送金をする必要）があるものとする。また、その後もフロリダ支社の従業員には追加の送金が必要な場合があるものとする。
このような場合、東京本社からは６０００ドル（実質送金額）だけではなく少し多目の１００００ドルを送金する。これにより、鈴木さんは１０００ドル、田中さんは２０００ドル、加藤さんは３０００ドルを引出可能となり、残りの４０００ドルは余剰金（予備送金額）を管理する残高管理用の口座に一旦保管される。そして、例えば田中さんが２０００ドルを使い果たしてしまい、田中さんに１５００ドルを再送金しなければならない場合、残高管理用口座（４０００ドル）から１５００ドルを田中さんに振分けることにより田中さんは更に１５００ドルを引出可能になるのである。即ち、再度送金処理を行うことなく実質的に再送金を行うことができる点に本実施例の特徴がある。

次に本実施例の処理内容を説明する。
本実施例でも、上記実施例と同様に図２９のような口座ファイルが送金仲介サーバーに記憶されている。ただし、図２９において受取者は株式会社Fのフロリダ支社になっている点（個人ではなく法人の支社になっている点）で上記実施例とは異なる。
また、本実施例では送金仲介サーバーが図２９の口座ファイルのほかに図３０のような口座対応ファイルを記憶している。これはフロリダ支社の各情報とそこで働く３人の従業員の各情報とを関連づけて記憶したものである。なお、この口座対応ファイルには残高管理口座と残高の項目も含まれている。これら項目は前述の余剰金４０００ドルを保管するためのデータ項目である。なお、本実施例ではこの社員用の口座が実質口座としての役割を果たし、残高管理口座が予備口座としての役割を果たす。

＜送金金額振分処理＞
まず、株式会社Ｆ本社の送金担当者は１００００ドルを送金する前に、送金する金額を各従業員にどのように振り分けるかを決定する。そのために送金担当者はまずフロリダ支社を指定する。即ち、送金者ＰＣに表示された図３１左欄のような支社指定画面において「フロリダ支社」を指定して画面下の送信をクリックし、これにより送金者ＰＣは図３１右欄のような支社指定データを送金仲介サーバーに送信する。
これを受信した送金仲介サーバーは図３０の口座対応ファイルに含まれるフロリダ支社所属の社員氏名を検索し、これを送金者ＰＣに送信する。これにより送金者ＰＣには図３２左欄のような送金振分画面が表示され、送金担当者は各社員への振分金額を入力し画面下の送信をクリックする。これにより送金者ＰＣから送金仲介サーバーに図３２右欄のような送金振分データが送信される。これを受信した送金仲介サーバーは、図３０の口座対応ファイルを図３３のように更新する。即ち、鈴木さんには１０００ドル、田中さんには２０００ドル、加藤さんには３０００ドル、残余の４０００ドルは残高管理用口座に振り分けるよう更新される。

＜引出許可要請情報作成処理＞
次に、送金仲介サーバーは図３３の口座対応ファイルに基づき図３４のような引出許可要請情報（引出許可判断情報）を作成・記憶する。これにより鈴木さんは１０００ドル、田中さんは２０００ドル、加藤さんは３０００ドルを引き出すことが可能になる。

＜再振分処理＞
次に、田中さんが送金された２０００ドルを使い果たし、更に１５００ドルの資金が必要になったとする。その際、送金担当者は図３５左欄のような画面に所定の情報（フロリダ支社の残高管理口座から田中さんに１５００ドルを再振分するための情報）を入力し、画面下の送信をクリックする。これにより送金者ＰＣは図３５右欄のような再振分データを作成しこれを送金仲介サーバーに送信する。これを受信した送金仲介サーバーは口座対応ファイルを図３６のように更新する。即ち、残高管理口座の残高を２５００ドル（４０００−１５００）とし、田中さんの引出可能額を「０ドル」から「１５００ドル」に更新する。そして、図３７のような引出許可要請情報を作成する。これにより田中さんは１５００ドルを引き出すことができる。即ち、送金担当者は再振分処理をするだけで（再度送金処理を行うことなく）田中さんに１５００ドルを実質的に送金できるので送金担当者の手間を大幅に省くことができる。なお、本実施例では再振分データが再配分データとしての役割を果たし、振分金額が再配分金としての役割を果たし、振分先である田中さんの氏名等が再配分金受取者としての役割を果たす。

次に、実施例６について説明する。本実施例は、例えば、フロリダ支社の鈴木さんがフロリダ勤務を終え日本に帰国した場合は、それ以降鈴木さんが送金された金額を引き出すことができないようにするものである。

鈴木さんは送金された１０００ドルを使うことなくフロリダ勤務を終えたとする。鈴木さんは社内ネットワークに接続されたＰＣ（帰国管理ＰＣ：図示せず）を用い、図３８左欄のような帰国報告画面に自らの氏名（社員ＩＤ等であってもよい）を入力し、画面下の送信をクリックする。これにより帰国管理ＰＣは図３８右欄のような帰国報告データを作成し、これを送金仲介サーバーに送信する。これを受信した送金仲介サーバーは帰国報告データに基づいて口座対応ファイルを検索し口座対応ファイルを図３９のように更新する。即ち、鈴木さんの引出可能額を「０」（引出不能）にし、その分を残高管理口座に加算して残高を３５００ドル（２５００ドル+１０００ドル）にして、帰国者である鈴木さんの資金を残高管理口座に組み入れる。そして、送金仲介サーバーは図４０のような引出金額を「０」とした引出許可要請情報（引出許可判断情報）を作成する。これにより鈴木さんは海外送金された資金をその後引き出すことはできなくなり（出金を不許可とされることになり）、送金の不正利用等を防止できる。また、残高管理口座の残高が増えるので他のフロリダ勤務社員により多くの資金を再振分けすることができるのである。なお、本実施例では帰国報告データに含まれる帰国者名が帰国者特定情報としての役割を果たす。

なお、上記実施例では東京本社（国内）とフロリダ支社（海外支社）との間の送金処理について説明したが、必ずしも海外支社を設ける必要はない。例えば、東京本社が独自の残高管理口座を有し、一時的に海外出張する東京本社社員宛に送金してもよい。
また、例えば、フロリダ勤務の加藤さんが他の支社へ人事異動し、代わりに大島さんがフロリダ勤務になった場合は、大島さんが加藤さんの口座番号や資金引出特定情報をそのまま引き継ぐようにしてもよい。更に、各社員の引出可能額を送金仲介サーバーが所定の間隔で管理をし、一定額以下になったら警告のメール等をその社員に送信して資金がなくなることを防止するようにしてもよい。

上記実施例おいては特定のケースについて説明したが、本発明はこれら特定のケースに限るものではない。例えば、次のようなケースであっても構わないし、次のようにしても同様の効果が得られる。
（１）上記実施例では、特定の銀行や会社のサーバーを利用するケースを例に説明したが、本発明はこれに限るものではなく、あらゆる外国送金に利用できるものである。また、上記実施例では資金の引出に関しクレジットカード番号を用いたが、これを外国送金を引き出すことができる何らかの情報（例えば、資金引出特定情報や外国送金特定情報などの情報）を用いても良い。
（２）データの内容は実施例で説明したデータに限らない。即ち、同様の役割を果たすことができれば、他のどのようなデータであっても構わない。
（３）ハードウェアも実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのようなハードウェアであっても構わない。例えば、銀行ＡＴＭではなく、パーソナルコンピュータや携帯電話等を利用して行っても良い。
（４）処理の内容や手順（フロー）についても実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのような処理内容・処理手順であっても構わない。
（５）上記実施例に登場するデータ（データレコード、ファイル）のデータ（データ項目）は、原則として各々関連づけられて（対応づけられて）記憶装置に記憶されているものとする。図面に表されたものについても同様である。また、データの受信には「データ入力を受け付ける」ことが含まれる場合があり、データの送信には「データを出力する」ことが含まれる場合があるものとする。更に、「前記引出可能通知を前記送信者の前記連絡先及び／又は前記受取者の前記連絡先」とはどちらか一方のみに通知を送信してもよく、双方に送信してもよいことを意味する。

Claims (6)

1. 資金の送金者と資金の受取者とその受取者の資金引出特定情報とを関連づけた送金登録レコードを複数集めた送金登録ファイルを記憶する送金登録ファイル記憶手段と、
   前記送金登録ファイルに含まれる１つの送金登録レコードを特定するための送金登録レコード特定情報と送金額とを関連づけた送金情報を顧客が利用する顧客端末から受信する送金情報受信手段と、
   前記送金登録レコード特定情報に該当する送金登録レコードを前記送金登録ファイルから検索する送金登録レコード検索手段と、
   前記受取者は団体であって、該団体から団体構成員に資金を再配分するための再配分金とそれを受け取る前記団体構成員である再配分金受取者とを関連づけた再配分データを受信する再配分データ受信手段と、
   検索された前記送金登録レコードに含まれる前記資金引出特定情報と前記送金情報に含まれる前記送金額とを関連づけた情報又は前記再配分金受取者の資金引出特定情報と前記再配分金とを関連づけた情報である引出許可判断情報を作成して記憶する引出許可判断情報記憶手段と、
   資金を引き出すための資金引出装置から資金引出特定情報と出金額とを関連づけた出金許可要請情報を受信する出金許可要請情報受信手段と、
   前記出金許可要請情報の前記資金引出特定情報と前記引出許可判断情報の前記資金引出特定情報とが一致するか否か、及び、前記出金額が前記送金額又は前記再配分金の範囲内か否かに基づいて前記出金額の出金を認めるか否かを判断し、出金の許可をする場合は出金許可情報を前記資金引出装置に送信する出金許可情報送信手段と、
   前記団体構成員のうち送金先の国から送金元の国に帰国した団体構成員を特定する帰国者特定情報を受信する帰国者特定情報受信手段と、
   前記帰国者特定情報により特定される帰国者の前記資金引出特定情報を含む前記出金許可要請情報を受信した場合その出金を不許可とする処理を行う出金不許可手段と、
   を備えることを特徴とする送金装置。
2. 前記帰国者特定情報により特定される帰国者の実質的に必要となる資金を管理する実質口座に関連づけられている実質送金額を予備的な資金を管理する予備口座に組み入れる予備口座組入手段をさらに備えることを特徴とする請求項１に記載の送金装置。
3. 前記送金額には実質送金額と予備送金額とが含まれ、
   実質的に必要となる資金を管理する実質口座と前記実質送金額と前記受取者とを関連づけた実質送金情報を記憶する実質送金情報記憶手段と、
   予備的な資金を管理する予備口座と前記予備送金額とを関連づけた予備送金情報を記憶する予備送金情報記憶手段と、
   をさらに備えることを特徴とする請求項１又は２に記載の送金装置。
4. コンピュータが、
   資金の送金者と資金の受取者とその受取者の資金引出特定情報とを関連づけた送金登録レコードを複数集めた送金登録ファイルを記憶する送金登録ファイル記憶ステップと、
   前記送金登録ファイルに含まれる１つの送金登録レコードを特定するための送金登録レコード特定情報と送金額とを関連づけた送金情報を顧客が利用する顧客端末から受信する送金情報受信ステップと、
   前記送金登録レコード特定情報に該当する送金登録レコードを前記送金登録ファイルから検索する送金登録レコード検索ステップと、
   前記受取者は団体であって、該団体から団体構成員に資金を再配分するための再配分金とそれを受け取る前記団体構成員である再配分金受取者とを関連づけた再配分データを受信する再配分データ受信ステップと、
   検索された前記送金登録レコードに含まれる前記資金引出特定情報と前記送金情報に含まれる前記送金額とを関連づけた情報又は前記再配分金受取者の資金引出特定情報と前記再配分金とを関連づけた情報である引出許可判断情報を作成して記憶する引出許可判断情報記憶ステップと、
   資金を引き出すための資金引出装置から資金引出特定情報と出金額とを関連づけた出金許可要請情報を受信する出金許可要請情報受信ステップと、
   前記出金許可要請情報の前記資金引出特定情報と前記引出許可判断情報の前記資金引出特定情報とが一致するか否か、及び、前記出金額が前記送金額又は前記再配分金の範囲内か否かに基づいて前記出金額の出金を認めるか否かを判断し出金の許可をする場合は出金許可情報を前記資金引出装置に送信する出金許可情報送信ステップと、
   前記団体構成員のうち送金先の国から送金元の国に帰国した団体構成員を特定する帰国者特定情報を受信する帰国者特定情報受信ステップと、
   前記帰国者特定情報により特定される帰国者の前記資金引出特定情報を含む前記出金許可要請情報を受信した場合その出金を不許可とする処理を行う出金不許可ステップと、
   を行うことを特徴とする送金方法。
5. 前記コンピュータが、
   前記帰国者特定情報により特定される帰国者の実質的に必要となる資金を管理する実質口座に関連づけられている実質送金額を予備的な資金を管理する予備口座に組み入れる予備口座組入ステップをさらに行うことを特徴とする請求項４に記載の送金方法。
6. 前記送金額には実質送金額と予備送金額とが含まれ、
   前記コンピュータが、
   実質的に必要となる資金を管理する実質口座と前記実質送金額と前記受取者と関連づけた実質送金情報を記憶する実質送金情報記憶ステップと、
   予備的な資金を管理する予備口座と前記予備送金額とを関連づけた予備送金情報を記憶する予備送金情報記憶ステップと、
   をさらに行うことを特徴とする請求項４又は５に記載の送金方法。

Images