ホーム > 特許ランキング > 株式会社ローソン銀行
知財求人 - 知財ポータルサイト「IP Force」
特許7603424金融関連情報管理装置、金融関連情報管理システム、金融関連情報管理装置の制御方法及び金融関連情報管理装置の制御プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-12-12
(45)【発行日】2024-12-20
(54)【発明の名称】金融関連情報管理装置、金融関連情報管理システム、金融関連情報管理装置の制御方法及び金融関連情報管理装置の制御プログラム
(51)【国際特許分類】
G06Q 20/06 20120101AFI20241213BHJP
【ＦＩ】
G06Q20/06 300
【請求項の数】
6
(21)【出願番号】P 2020196178
(22)【出願日】2020-11-26
(65)【公開番号】P2021111361
(43)【公開日】2021-08-02
【審査請求日】2023-10-26
(31)【優先権主張番号】P 2020003053
(32)【優先日】2020-01-10
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】519195534
【氏名又は名称】株式会社ローソン銀行
(74)【代理人】
【識別番号】100098796
【弁理士】
【氏名又は名称】新井 全
(74)【代理人】
【識別番号】100121647
【弁理士】
【氏名又は名称】野口 和孝
(74)【代理人】
【識別番号】100187377
【弁理士】
【氏名又は名称】芳野 理之
(72)【発明者】
【氏名】畑 優摩
(72)【発明者】
【氏名】茂木 俊樹
(72)【発明者】
【氏名】深見 勇
(72)【発明者】
【氏名】片山 弘毅
【審査官】前田 侑香
(56)【参考文献】
【文献】特開２０１１－１９２１４７（ＪＰ，Ａ）
【文献】特開２０１８－０４５６１０（ＪＰ，Ａ）
【文献】特開２０１７－１３００１３（ＪＰ，Ａ）
【文献】特開２０１６－１８１２３７（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
利用者の端末装置、前記端末装置と通信する事業者の管理装置である事業者側管理装置と金融機関の管理装置である金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置であって、利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、
前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信され、
前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信され、
また、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成し、
前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、
前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更され、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供する構成となっていることを特徴とする金融関連情報管理装置。
【請求項2】
金融機関における暗証情報の一致情報と、金融機関から受信した当該利用者の残高情報と、利用者が入力した残高情報の一致情報に基づいて、電子通貨の利用許可を判断する構成となっていることを特徴とする請求項１に記載の金融関連情報管理装置。
【請求項3】
前記端末装置に、電子通貨を法定通貨に払い戻すための払戻要求情報が入力されたとき、前記金融機関側管理装置に前記払戻要求情報を実行させることを特徴とする請求項１又は請求項２に記載の金融関連情報管理装置。
【請求項4】
利用者の端末装置と、
前記端末装置と通信する事業者の管理装置である事業者側管理装置と、
金融機関の管理装置である金融機関側管理装置と、
前記端末装置、前記事業者側管理装置と前記金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置と、を有する金融機関側管理システムであって、
利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、
前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信され、
前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信され、
また、前記金融関連情報管理装置は、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成し、
前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、
前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更され、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供する構成となっていることを特徴とする金融関連情報管理システム。
【請求項5】
利用者の端末装置、前記端末装置と通信する事業者の管理装置である事業者側管理装置と金融機関の管理装置である金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置の制御方法であって、
利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、
前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信され、
前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信され、
また、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成し、
前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、
前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更され、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供する構成となっていることを特徴とする金融関連情報管理装置の制御方法。
【請求項6】
利用者の端末装置、前記端末装置と通信する事業者の管理装置である事業者側管理装置と金融機関の管理装置である金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置に、
利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信される機能、
前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信される機能、
また、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成する機能、
前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更される機能、
チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供される機能、を実行させる構成となっている金融関連情報管理装置の制御プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、事業を行う事業者と金融機関との間の金融関連情報を管理する金融関連情報管理装置、金融関連情報管理システム、金融関連情報管理装置の制御方法及び金融関連情報管理装置の制御プログラムに関するものである。
【背景技術】
【0002】
近年は、例えば、電子通貨等で物品等の購入等を行うシステムが広がっている（例えば、特許文献１等）。
このような電子通貨のシステムは、銀行等の金融機関等ではない他の事業者が、利用者に電子通貨等を提供している場合が多い。
また、利用者が電子通貨等をチャージ等するためには、予め利用者の金融機関等の口座等と利用者の電子通貨等を関連付ける必要がある。
このような関連付けをするためには、金融機関等が自ら公開するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）に従い、事業者が自己のサーバ等と金融機関のサーバ等との通信を個別に確立する必要がある。
このような電子通貨のシステムは、銀行等の金融機関等ではない他の事業者が、利用者に電子通貨等を提供している場合が多い。
また、利用者が電子通貨等をチャージ等するためには、予め利用者の金融機関等の口座等と利用者の電子通貨等を関連付ける必要がある。
このような関連付けをするためには、金融機関等が自ら公開するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）に従い、事業者が自己のサーバ等と金融機関のサーバ等との通信を個別に確立する必要がある。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１６－５１２７９号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、各金融機関のＡＰＩは、それぞれ相違しているので、事業者は、顧客である利用者が取引する異なる金融機関のＡＰＩに合わせて、個別にネットワーク等を構築する必要があり、その構築に多大なコストがかかるという問題があった。
【0005】
そこで、本発明は、事業者が、容易且つ低コストで金融機関とネットワーク等を構築することができる金融関連情報管理装置、金融関連情報管理システム、金融関連情報管理装置の制御方法及び金融関連情報管理装置の制御プログラムを提供することを目的とする。
【0006】
上記目的は、本発明にあっては、利用者の端末装置、前記端末装置と通信する事業者の管理装置である事業者側管理装置と金融機関の管理装置である金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置であって、利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信され、前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信され、また、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成し、前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更され、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供する構成となっていることを特徴とする金融関連情報管理装置により達成される。
【0007】
前記構成によれば、登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、事業者が受信可能な事業者向送信情報を生成する。
このように、事業者が情報を金融機関に送信するときは、金融関連情報管理装置は、金
融機関側管理装置が受信可能な電文等の情報を作成して、送信する。
また、金融機関が事業者に情報を送信するときは、金融関連情報管理装置は、事業者側管理装置が受信可能な電文等の情報を作成して、送信する。
このように、金融関連情報管理装置は、金融機関側管理装置と事業者側管理装置が、それぞれ、受信可能な電文等で情報を送信するので、事業者側管理装置と金融機関側管理装置は、従来のネットワークシステム等を一切変更することなく、そのままで、相互に情報を交換することができる。
例えば、各金融機関側管理装置は、それぞれ、別個のＡＰＩ（（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を採用しているため、事業者側管理装置が、各金融機関側管理装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要があった。
これに対し、本発明では、金融関連情報管理装置が、各金融機関側管理装置のＡＰＩに合わせた電文等を生成するので、事業者側管理装置が、各金融機関側管理装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要はなく、従来のネットワーク等をそのまま利用でき、コストを大幅に低減することができる。
このように、事業者が情報を金融機関に送信するときは、金融関連情報管理装置は、金
融機関側管理装置が受信可能な電文等の情報を作成して、送信する。
また、金融機関が事業者に情報を送信するときは、金融関連情報管理装置は、事業者側管理装置が受信可能な電文等の情報を作成して、送信する。
このように、金融関連情報管理装置は、金融機関側管理装置と事業者側管理装置が、それぞれ、受信可能な電文等で情報を送信するので、事業者側管理装置と金融機関側管理装置は、従来のネットワークシステム等を一切変更することなく、そのままで、相互に情報を交換することができる。
例えば、各金融機関側管理装置は、それぞれ、別個のＡＰＩ（（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を採用しているため、事業者側管理装置が、各金融機関側管理装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要があった。
これに対し、本発明では、金融関連情報管理装置が、各金融機関側管理装置のＡＰＩに合わせた電文等を生成するので、事業者側管理装置が、各金融機関側管理装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要はなく、従来のネットワーク等をそのまま利用でき、コストを大幅に低減することができる。
【0008】
また、前記構成によれば、利用者等の暗証番号や残高情報等の金融機関識別情報は、事業者側管理装置を介することなく、金融関連情報管理装置に送信されるため、これら暗証番号や残高情報等の金融機関識別情報は、事業者に漏れることがない。
このため、暗証番号や残高情報等の金融機関識別情報の拡散を未然に防止することができ、セキュリティのレベルを安定化させることができ、利用者等にとって安全性が高い装置となっている。
また、前記構成によれば、利用者の暗証情報を事業者に知らせることなく、チャージの取引結果等の情報を事業者に知らせることができ、利用者等にとって安全性が高い装置となっている。
このため、暗証番号や残高情報等の金融機関識別情報の拡散を未然に防止することができ、セキュリティのレベルを安定化させることができ、利用者等にとって安全性が高い装置となっている。
また、前記構成によれば、利用者の暗証情報を事業者に知らせることなく、チャージの取引結果等の情報を事業者に知らせることができ、利用者等にとって安全性が高い装置となっている。
【0009】
好ましくは、金融機関における暗証情報の一致情報と、金融機関から受信した当該利用者の残高情報と、利用者が入力した残高情報の一致情報に基づいて、前記金融関連情報管理装置が電子通貨の利用許可を判断する構成となっていることを特徴とする。
【0010】
前記構成によれば、金融機関における暗証情報の一致情報と、金融機関から受信した当該利用者の残高情報と、利用者が入力した残高情報の一致情報に基づいて、電子通貨の利用許可を判断する構成となっているので、利用者等の本人認証を確実にすることができる。
【0013】
好ましくは、前記端末装置に、電子通貨を法定通貨に払い戻すための払戻要求情報が入力されたとき、金融関連情報管理装置が前記金融機関側管理装置に前記払戻要求情報を実行させることを特徴とする。
【0014】
前記構成によれば、端末装置に電子通貨を法定通貨に払い戻すための払戻要求情報が入力されたとき、金融関連情報管理装置が金融機関側管理装置に対して払戻要求情報を実行する構成となっている。
このため、事業者用管理装置が電子通貨を法定通貨に払い戻しのための工程を実行する必要がないので、事業者管理装置を管理する事業者に振込手数料等が発生せず、使い易い装置となる。また、即時に銀行用管理装置で勘定処理が行われることから、振込と異なり、時間をかけずに利用者の預金口座に入金することができる。
このため、事業者用管理装置が電子通貨を法定通貨に払い戻しのための工程を実行する必要がないので、事業者管理装置を管理する事業者に振込手数料等が発生せず、使い易い装置となる。また、即時に銀行用管理装置で勘定処理が行われることから、振込と異なり、時間をかけずに利用者の預金口座に入金することができる。
【0015】
上記目的は、本発明にあっては、利用者の端末装置と、前記端末装置と通信する事業者の管理装置である事業者側管理装置と、金融機関の管理装置である金融機関側管理装置と、前記端末装置、前記事業者側管理装置と前記金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置と、を有する金融機関側管理システムであって、利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信され、前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信され、また、前記金融関連情報管理装置は、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成し、前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更され、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供する構成となっていることを特徴とする金融関連情報管理システムにより達成される。
【0016】
上記目的は、本発明にあっては、利用者の端末装置、前記端末装置と通信する事業者の管理装置である事業者側管理装置と金融機関の管理装置である金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置の制御方法であって、利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信され、前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信され、
また、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成し、前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更され、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供する構成となっていることを特徴とする金融関連情報管理装置の制御方法により達成される。
また、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成し、前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更され、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供する構成となっていることを特徴とする金融関連情報管理装置の制御方法により達成される。
【0017】
上記目的は、本発明にあっては、利用者の端末装置、前記端末装置と通信する事業者の管理装置である事業者側管理装置と金融機関の管理装置である金融機関側管理装置の間で金融関連情報を管理する金融関連情報管理装置に、利用者が事業者と取引するに必要な登録関連情報は、一般的な登録関連情報である一般登録関連情報と、金融機関に関する識別情報である金融機関識別情報を含み、前記一般登録関連情報は、前記事業者側管理装置を介して、前記金融関連情報管理装置に送信される機能、前記金融機関識別情報は、前記事業者側管理装置を介することなく、前記金融関連情報管理装置に送信される機能、また、前記登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、前記事業者が受信可能な事業者向送信情報を生成する機能、前記金融機関に関する識別情報は、利用者の金融機関の暗証情報と利用者の金融機関の口座の残高情報を含み、前記端末装置が電子通貨を増加するためにチャージを実行する際、前記暗証情報の入力時に自動的に前記事業者側管理装置から前記金融関連情報管理装置に接続が変更される機能、チャージが終了したときに、終了の信号が前記端末装置から前記事業者側管理装置に送信され、その後、前記事業者側管理装置にチャージ関連情報を提供される機能、を実行させる構成となっている金融関連情報管理装置の制御プログラムにより達成される。
【発明の効果】
【0018】
以上説明したように、本発明は、事業者が、容易且つ低コストで金融機関とネットワーク等を構築することができる金融関連情報管理装置、金融関連情報管理システム、金融関連情報管理装置の制御方法及び金融関連情報管理装置の制御プログラムを提供することができるという利点がある。
【図面の簡単な説明】
【0019】
【図1】本発明の実施の形態にかかる「金融関連情報管理システム」である例えば、電子通貨情報管理システム１を示す概略説明図である。
【図3】事業者サーバ側第１の各種情報記憶部２００の主な構成を示す概略ブロック図である。
【図4】事業者サーバ側第２の各種情報記憶部２１０の主な構成を示す概略ブロック図である。
【図6】管理サーバ側第１の各種情報記憶部４００の主な構成を示す概略ブロック図である。
【図7】管理サーバ側第２の各種情報記憶部４１０の主な構成を示す概略ブロック図である。
【図8】管理サーバ側第３の各種情報記憶部４２０の主な構成を示す概略ブロック図である。
【図9】管理サーバ側第４の各種情報記憶部４３０の主な構成を示す概略ブロック図である。
【図10】管理サーバ側第５の各種情報記憶部４４０の主な構成を示す概略ブロック図である。
【図11】管理側サーバ側第６の各種情報記憶部４５０の主な構成を示す概略ブロック図である。
【図13】銀行サーバ側第１の各種情報記憶部３００の主な構成を示す概略ブロック図である。
【図14】銀行サーバ側第２の各種情報記憶部３１０の主な構成を示す概略ブロック図である。
【図15】利用者の登録工程を示す主な概略フローチャートである。
【図16】利用者の登録工程を示す他の主な概略フローチャートである。
【図17】利用者の登録工程を示す他の主な概略フローチャートである。
【図18】利用者のチャージ工程を示す主な概略フローチャートである。
【図19】利用者のチャージ工程を示す主な他の概略フローチャートである。
【図20】利用者のチャージ工程を示す主な他の概略フローチャートである。
【図21】利用者の払い戻し工程を示す概略フローチャートである。
【図22】利用者の払い戻し工程を示す他の概略フローチャートである。
【図23】利用者の払い戻し工程を示す他の概略フローチャートである。
【図24】ＳＴ４で記憶された「管理側利用者情報（その１）」を示す概略説明図である。
【図25】ＳＴ６でＭＳ情報が記憶された管理側利用者情報（その２）を示す概略説明図である。
【図26】ＳＴ１３で「利用許可フラグ」が設定された状態を示す管理側利用者情報を示す概略説明図である。
【図27】ＳＴ１４で「トークン情報」が記憶された「管理側利用者情報（その４）」示す概略説明図である。
【図28】ＳＴ２５で「管理側チャージ受付情報記憶部３２」に記憶される「管理側チャージ受付情報（その１）」の内容を示す概略説明図である。
【図29】ＳＴ２７で「管理側チャージ受付情報記憶部３２」に記憶される「管理側チャージ受付情報（その２）」の内容を示す概略説明図である。
【図30】ＳＴ２８で、「チャージ金額」「取引ＩＤ」「取引日時」の情報が付加された管理側利用者情報（その５）を示す概略説明図である。
【図31】ＳＴ３５で「取引結果（出金）」が付加された「管理者側利用者情報（その６）」を示す概略説明図である。
【図32】ＳＴ５６で、「払い戻し金額」「取引ＩＤ」「取引日時」の情報が付加された管理側利用者情報（その７）を示す概略説明図である。
【図33】ＳＴ６４で「取引結果（入金）」が付加された「管理者側利用者情報（その８）」を示す概略説明図である。
【発明を実施するための形態】
【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】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】