ホーム > 特許ランキング > 株式会社ローソン銀行
知財求人 - 知財ポータルサイト「IP Force」
特許7576974管理装置、管理システム、管理装置の制御方法及び管理装置の制御プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-24
(45)【発行日】2024-11-01
(54)【発明の名称】管理装置、管理システム、管理装置の制御方法及び管理装置の制御プログラム
(51)【国際特許分類】
G06Q 40/02 20230101AFI20241025BHJP
【ＦＩ】
G06Q40/02
【請求項の数】
5
(21)【出願番号】P 2020213608
(22)【出願日】2020-12-23
(65)【公開番号】P2022099675
(43)【公開日】2022-07-05
【審査請求日】2023-10-26
(73)【特許権者】
【識別番号】519195534
【氏名又は名称】株式会社ローソン銀行
(74)【代理人】
【識別番号】100098796
【弁理士】
【氏名又は名称】新井 全
(74)【代理人】
【識別番号】100121647
【弁理士】
【氏名又は名称】野口 和孝
(74)【代理人】
【識別番号】100187377
【弁理士】
【氏名又は名称】芳野 理之
(72)【発明者】
【氏名】片山 弘毅
(72)【発明者】
【氏名】畑 優摩
(72)【発明者】
【氏名】深見 勇
【審査官】阿部 圭子
(56)【参考文献】
【文献】特開２００７－３０４９２２（ＪＰ，Ａ）
【文献】特開２００７－０４１７３１（ＪＰ，Ａ）
【文献】特開２００７－２２６４３５（ＪＰ，Ａ）
【文献】特開２０１０－１９１８５２（ＪＰ，Ａ）
【文献】特開２０１１－１９２１４７（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
(57)【特許請求の範囲】
【請求項1】
利用者の端末装置、利用者の金融関連情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置及び利用者の金融機関の装置である金融機関側装置のそれぞれと通信可能な管理装置であって、前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において、前記金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の前記金融関連情報の登録を停止し、
前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する構成となっていることを特徴とする管理装置。
【請求項2】
前記金融関連情報の登録受付が可能な時間には、定期的な登録受付が可能な時間帯情報と、不定期に登録受付が停止する時間帯情報を含むことを特徴とする請求項１に記載の管理装置。
【請求項3】
利用者の端末装置と、
利用者の金融関連情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置と、
利用者の金融機関の装置である金融機関側装置と、
前記端末装置、前記事業者側装置及び金融機関側装置のそれぞれと通信可能な管理装置と、を有する管理システムであって、
前記管理装置は、前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において、前記金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の前記金融関連情報の登録を停止し、
前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する構成となっていることを特徴とする管理システム。
【請求項4】
利用者の端末装置、利用者の金融関連情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置及び利用者の金融機関の装置である金融機関側装置のそれぞれと通信可能な管理装置の制御方法であって、
前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において前記金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の前記金融関連情報の登録を停止し、
前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する構成となっていることを特徴とする管理装置の制御方法。
【請求項5】
利用者の端末装置、利用者の金融機関情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置及び利用者の金融機関の装置である金融機関側装置のそれぞれと通信可能な管理装置に、
前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において前記金融関連情報の登録受付が可能な時間か否かを判断する機能、
前記金融機関側装置において前記金融関連情報の登録受付が可能な時間でないときに、利用者の前記金融関連情報の登録を停止する機能、
前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する機能、を実行させる構成となっている管理装置の制御プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、事業を行う事業者と金融機関との間の各種情報を管理する管理装置、管理システム、管理装置の制御方法及び管理装置の制御プログラムに関するものである。
【背景技術】
【0002】
近年は、現金等ではなく、電子通貨等で物品等の購入等を行うシステムが急速に普及している（例えば、特許文献１等）。
このような電子通貨等のシステムの利用者は、使用前に自己が金融機関に有している口座情報と関連付ける登録手続きが必要となっている。
そして、この登録手続を行う際には、利用者の口座の詳細な情報を入力等する必要があった。
このような電子通貨等のシステムの利用者は、使用前に自己が金融機関に有している口座情報と関連付ける登録手続きが必要となっている。
そして、この登録手続を行う際には、利用者の口座の詳細な情報を入力等する必要があった。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１６－５１２７９号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、このような登録手続きは、利用者が口座を有する金融機関の取り扱い可能な時間内に行わなければならず、この取り扱い可能な時間以外に登録手続きをして利用者が口座等の詳細な情報を入力しても登録することができず、時間外に口座等の詳細な情報を入力した利用者の行為が無駄になる等の問題があった。
【0005】
そこで、本発明は、電子通貨等のシステム等の利用者が金融機関等の情報を登録等する際に、無駄なく手続き等を行うことができる管理装置、管理装置の制御方法、管理装置の制御プログラムを提供することを目的とする。
【0006】
上記目的は、本発明にあっては、利用者の端末装置、利用者の金融関連情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置及び利用者の金融機関の装置である金融機関側装置のそれぞれと通信可能な管理装置であって、前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において、前記金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の前記金融関連情報の登録を停止し、前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する構成となっていることを特徴とする管理装置により達成される。
【0007】
前記構成によれば、端末装置が金融関連情報（例えば、利用者の口座情報等）を入力する前に、入力予定の金融関連情報を管理する金融機関側装置が金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の金融関連情報の登録を停止する構成となっているため、利用者は、端末装置に利用者の口座情報等を入力した後、登録できない等の無駄な手続きを行うことを未然に回避することができる。
また、前記構成によれば、端末装置で入力された金融機関名情報に基づいて、金融機関側装置が金融関連情報の登録受付が可能な時間か否か判断するので、極めて容易かつ迅速に判断をすることができる。
また、前記構成によれば、登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、事業者が受信可能な事業者向送信情報を生成する。
このように、事業者が情報を金融機関に送信するときは、管理装置は、金融機関側装置が受信可能な電文等の情報を作成して、送信する。
また、金融機関が事業者に情報を送信するときは、管理装置は、事業者側装置が受信可能な電文等の情報を作成して、送信する。
また、このように、管理装置は、金融機関側装置と事業者側装置が、それぞれ、受信可能な電文等で情報を送信するので、事業者側装置と金融機関側装置は、従来のネットワークシステム等を一切変更することなく、そのままで、相互に情報を交換することができる。
例えば、各金融機関側装置は、それぞれ、別個のＡＰＩ（（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を採用しているため、事業者側装置が、各金融機関側装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要があった。
これに対し、本発明では、管理装置が、各金融機関側装置のＡＰＩに合わせた電文等を生成するので、事業者側装置が、各金融機関側装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要はなく、従来のネットワーク等をそのまま利用でき、コストを大幅に低減することができる。
また、前記構成によれば、端末装置で入力された金融機関名情報に基づいて、金融機関側装置が金融関連情報の登録受付が可能な時間か否か判断するので、極めて容易かつ迅速に判断をすることができる。
また、前記構成によれば、登録関連情報に基づいて、金融機関が受信可能な金融機関向送信情報を生成すると共に、金融機関から受信した情報に基づいて、事業者が受信可能な事業者向送信情報を生成する。
このように、事業者が情報を金融機関に送信するときは、管理装置は、金融機関側装置が受信可能な電文等の情報を作成して、送信する。
また、金融機関が事業者に情報を送信するときは、管理装置は、事業者側装置が受信可能な電文等の情報を作成して、送信する。
また、このように、管理装置は、金融機関側装置と事業者側装置が、それぞれ、受信可能な電文等で情報を送信するので、事業者側装置と金融機関側装置は、従来のネットワークシステム等を一切変更することなく、そのままで、相互に情報を交換することができる。
例えば、各金融機関側装置は、それぞれ、別個のＡＰＩ（（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を採用しているため、事業者側装置が、各金融機関側装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要があった。
これに対し、本発明では、管理装置が、各金融機関側装置のＡＰＩに合わせた電文等を生成するので、事業者側装置が、各金融機関側装置と通信するために、異なるＡＰＩに合わせたネットワークを構築する必要はなく、従来のネットワーク等をそのまま利用でき、コストを大幅に低減することができる。
【0010】
好ましくは、前記管理装置の前記金融関連情報の登録受付が可能な時間には、定期的な登録受付が可能な時間帯情報と、不定期に登録受付が停止する時間帯情報を含むことを特徴とする。
【0011】
前記構成によれば、金融関連情報の登録受付が可能な時間帯等をより精度良く判断することができる。
【0017】
上記目的は、本発明にあっては、利用者の端末装置と、利用者の金融関連情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置と、利用者の金融機関の装置である金融機関側装置と、
前記端末装置、前記事業者側装置及び金融機関側装置のそれぞれと通信可能な管理装置と、を有する管理システムであって、前記管理装置は、前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において、前記金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の前記金融関連情報の登録を停止し、前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する構成となっていることを特徴とする管理システムにより達成される。
前記端末装置、前記事業者側装置及び金融機関側装置のそれぞれと通信可能な管理装置と、を有する管理システムであって、前記管理装置は、前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において、前記金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の前記金融関連情報の登録を停止し、前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する構成となっていることを特徴とする管理システムにより達成される。
【0018】
上記目的は、本発明にあっては、利用者の端末装置、利用者の金融関連情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置及び利用者の金融機関の装置である金融機関側装置のそれぞれと通信可能な管理装置の制御方法であって、前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において前記金融関連情報の登録受付が可能な時間か否かを判断し、可能でないときは、利用者の前記金融関連情報の登録を停止し、前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する構成となっていることを特徴とする管理装置の制御方法により達成される。。
【0019】
上記目的は、本発明にあっては、利用者の端末装置、利用者の金融機関情報を関連付けて登録することで利用可能となる役務を提供する事業者の装置である事業者側装置及び利用者の金融機関の装置である金融機関側装置のそれぞれと通信可能な管理装置に、前記端末装置で前記金融関連情報が入力される前に、前記端末装置で入力された金融機関名情報に基づいて、入力予定の前記金融関連情報を管理する前記金融機関側装置において前記金融関連情報の登録受付が可能な時間か否かを判断する機能、前記金融機関側装置において前記金融関連情報の登録受付が可能な時間でないときに、利用者の前記金融関連情報の登録を停止する機能、前記利用者が前記事業者と取引するために前記事業者側装置に入力された登録関連情報に基づいて、前記金融機関が受信可能な金融機関向送信情報を生成すると共に、前記金融機関から受信した情報に基づいて、前記事業者側装置が受信可能な事業者向送信情報を生成する機能、を実行させる構成となっている管理装置の制御プログラムにより達成される。
【発明の効果】
【0020】
以上説明したように、本発明は、電子通貨等のシステム等の利用者が金融機関等の情報を登録等する際に、無駄なく手続き等を行うことができる管理装置、管理装置の制御方法、管理装置の制御プログラムを提供することができるという利点がある。
【図面の簡単な説明】
【0021】
【図1】本発明の「管理システム」の実施の形態にかかる「電子通貨情報管理システム１」を示す概略説明図である。
【図4】「管理サーバ側各種情報記憶部４００」の主な構成を示す概略ブロック図である。
【図6】「利用者の登録前金融機関サービス時間確認工程」を示す概略フローチャートである。
【図7】「利用者の登録前金融機関サービス時間確認工程」を示す他の概略フローチャートである。
【図8】利用者の登録工程を示す概略フローチャートである。
【図9】利用者の登録工程を示す他の概略フローチャートである。
【図10】利用者の登録工程を示す他の概略フローチャートである。
【図11】利用者の登録工程を示す他の概略フローチャートである。
【図12】ＳＴ２６で記憶された「管理側利用者情報（その１）」を示す概略説明図である。
【図13】ＳＴ３０でＭＳ情報が記憶された「管理側利用者情報（その２）」を示す概略説明図である。
【図14】ＳＴ４１で「利用許可フラグ」が設定された状態を示す管理側利用者情報を示す概略説明図である。
【図15】ＳＴ４２で「トークン情報」が記憶された「管理側利用者情報（その４）」を示す概略説明図である。
【発明を実施するための形態】
【0022】
以下、この発明の好適な実施の形態を添付図面等を参照しながら、詳細に説明する。
尚、以下に述べる実施の形態は、本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。
尚、以下に述べる実施の形態は、本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。
【0023】
図１は、本発明の「管理システム」の実施の形態にかかる「電子通貨情報管理システム１」を示す概略説明図である。
図１に示すように、本システム１は、例えば、Ｘペイ等の電子通貨を使用する、または使用を希望する利用者が所持する端末装置１０、Ｘペイ等の電子通貨を扱う事業者の事業者側装置である例えば、事業者サーバ２０、銀行等の金融機関側装置である例えば、銀行サーバ３０を有している。
図１に示すように、本システム１は、例えば、Ｘペイ等の電子通貨を使用する、または使用を希望する利用者が所持する端末装置１０、Ｘペイ等の電子通貨を扱う事業者の事業者側装置である例えば、事業者サーバ２０、銀行等の金融機関側装置である例えば、銀行サーバ３０を有している。
【0024】
また、同システム１は、これら端末装置１０、事業者サーバ２０、銀行サーバ３０の間で、金融関連情報である例えば、利用者の口座情報等を管理する管理装置である例えば、管理サーバ４０を有している。
また、これら端末装置１０、事業者サーバ２０、管理サーバ４０等は図１に示すように、インターネット網２や基地局３等を介して相互に通信可能に接続されている。
さらに、図１に示すように、管理サーバ４０は銀行サーバ３０と通信可能な構成となっている。
また、これら端末装置１０、事業者サーバ２０、管理サーバ４０等は図１に示すように、インターネット網２や基地局３等を介して相互に通信可能に接続されている。
さらに、図１に示すように、管理サーバ４０は銀行サーバ３０と通信可能な構成となっている。
【0025】
図１に示すように端末装置１０は、入力装置及び表示部である例えば、「タッチパネル１１」を有している。
ここで「タッチパネル１１」は、表示部である例えば、ディスプレイと、位置入力装置を組み合わせた電子部品であり、ディスプレイ上の表示に利用者が触れることで各種情報を入力できる入力装置である。
また、図１に示す端末装置１０は、図示しない端末装置側通信装置を有している。
ここで「タッチパネル１１」は、表示部である例えば、ディスプレイと、位置入力装置を組み合わせた電子部品であり、ディスプレイ上の表示に利用者が触れることで各種情報を入力できる入力装置である。
また、図１に示す端末装置１０は、図示しない端末装置側通信装置を有している。
【0026】
そして、図１の「電子通貨情報管理システム１」の端末装置１０、事業者サーバ２０、管理サーバ４０、銀行サーバ３０等は、コンピュータであり、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やハードディスク等を有し、バスを介して接続されている。
【0027】
（事業者サーバ２０の主な構成について）
図２は、図１の事業者サーバ２０の主な構成を示す概略ブロック図である。
図２に示すように、事業者サーバ２０は、「事業者側制御部２１」を有し、同制御部２１は、「事業者側通信装置２２」、「事業者側ディスプレイ２３」及び「事業者側各種情報入力装置２４」を制御する。
また、同制御部２１は、図２に示す「事業者側金融機関一覧情報記憶部２５」、「事業者側登録受付処理部２６」、「登録受付用情報記憶部２７」及び「事業者側利用者情報記憶部２８」も制御する。
これらの内容については、後述する。
図２は、図１の事業者サーバ２０の主な構成を示す概略ブロック図である。
図２に示すように、事業者サーバ２０は、「事業者側制御部２１」を有し、同制御部２１は、「事業者側通信装置２２」、「事業者側ディスプレイ２３」及び「事業者側各種情報入力装置２４」を制御する。
また、同制御部２１は、図２に示す「事業者側金融機関一覧情報記憶部２５」、「事業者側登録受付処理部２６」、「登録受付用情報記憶部２７」及び「事業者側利用者情報記憶部２８」も制御する。
これらの内容については、後述する。
【0028】
（管理サーバ４０について）
図３は、図１の管理サーバ４０の主な構成を示す概略ブロック図である。
図３に示すように、管理サーバ４０は、「管理側制御部４１」を有し、同制御部４１は、「管理側通信装置４２」、「管理側ディスプレイ４３」及び「管理側各種情報入力装置４４」を制御する。
また、同制御部４１は、図３に示す「管理サーバ側各種情報記憶部４００」も制御する。
図３は、図１の管理サーバ４０の主な構成を示す概略ブロック図である。
図３に示すように、管理サーバ４０は、「管理側制御部４１」を有し、同制御部４１は、「管理側通信装置４２」、「管理側ディスプレイ４３」及び「管理側各種情報入力装置４４」を制御する。
また、同制御部４１は、図３に示す「管理サーバ側各種情報記憶部４００」も制御する。
【0029】
図４は、「管理サーバ側各種情報記憶部４００」の主な構成を示す概略ブロック図である。これらの内容については、後述する。
【0030】
（銀行サーバ３０について）
図５は、図１の銀行サーバ３０の主な構成を示す概略ブロック図である。
図５に示すように、銀行サーバ３０は、「銀行側制御部３１」を有し、同制御部３１は、「銀行側通信装置３２」、「銀行側ディスプレイ３３」、「銀行側各種情報入力装置３４」を制御する。
また、同制御部３１は、図５の「現在残高付銀行送信用電文記憶部３５」、「暗証番号突合処理部３６」及び「現在残高付銀行送信用電文作成部３７」も制御する。
これらの内容については、後述する。
図５は、図１の銀行サーバ３０の主な構成を示す概略ブロック図である。
図５に示すように、銀行サーバ３０は、「銀行側制御部３１」を有し、同制御部３１は、「銀行側通信装置３２」、「銀行側ディスプレイ３３」、「銀行側各種情報入力装置３４」を制御する。
また、同制御部３１は、図５の「現在残高付銀行送信用電文記憶部３５」、「暗証番号突合処理部３６」及び「現在残高付銀行送信用電文作成部３７」も制御する。
これらの内容については、後述する。
【0031】
（電子通貨情報管理システム１の動作例について）
以下、本実施の形態にかかる「電子通貨情報管理システム１」の動作例等を説明する。
本システム１では、X電子通貨の利用を希望する利用者が、図１に示す端末装置１０を操作し、インターネット網２等を介して、Ｘ電子通貨を取り扱う事業者の事業者サーバ２０にアクセスし、利用者の登録を行うが、その際、利用者の銀行等の金融機関の口座情報等の金融関連情報の入力と登録が必要となる。
しかも、この入力は、当該銀行の事務受付時間（サービス時間）内でなければならず、時間外の場合は、入力が無駄となる。
そこで、以下の実施の形態では、かかる弊害を回避するための動作等について、説明するが、その前に、かかる動作をするための事業者サーバ２０及び管理サーバ４０の準備工程を先ず説明する。
以下、本実施の形態にかかる「電子通貨情報管理システム１」の動作例等を説明する。
本システム１では、X電子通貨の利用を希望する利用者が、図１に示す端末装置１０を操作し、インターネット網２等を介して、Ｘ電子通貨を取り扱う事業者の事業者サーバ２０にアクセスし、利用者の登録を行うが、その際、利用者の銀行等の金融機関の口座情報等の金融関連情報の入力と登録が必要となる。
しかも、この入力は、当該銀行の事務受付時間（サービス時間）内でなければならず、時間外の場合は、入力が無駄となる。
そこで、以下の実施の形態では、かかる弊害を回避するための動作等について、説明するが、その前に、かかる動作をするための事業者サーバ２０及び管理サーバ４０の準備工程を先ず説明する。
【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】
１・・・電子通貨情報管理システム、２・・インターネット網、３・・・基地局、１０・・・端末装置、２０・・・事業者サーバ、２１・・事業者側制御部、２２・・・事業者側通信装置、２３・・・事業者側ディスプレイ、２４・・・事業者側各種情報入力装置、２５・・・事業者側金融機関一覧情報記憶部、２６・・・事業者側登録受付処理部、２７・・・登録受付用情報記憶部、２８・・・事業者側利用者情報記憶部、３０・・・銀行サーバ、３１・・・銀行側制御部、３２・・・銀行側通信装置、３３・・・銀行側ディスプレイ、３４・・・銀行側各種情報入力装置、３５・・・現在残高付銀行送信用電文記憶部、３６・・・暗証番号突合処理部、３７・・・現在残高付銀行送信用電文作成部、４０・・・管理サーバ、４１・・・管理側制御部、４２・・・管理側通信装置、４３・・・管理側ディスプレイ、４４・・・管理側各種情報入力装置、４００・・・管理サーバ側各種情報記憶部、４０１・・・管理側金融機関一覧情報記憶部、４０２・・・サービス時間情報記憶部、４０３・・・サービス停止判断部、４０４・・・管理側登録受付処理部、４０５・・・管理側利用者情報記憶部、４０６・・・ＭＳ情報取得部、４０７・・・ＭＳ情報記憶部、４０８・・・銀行向送信用電文作成部、４０９・・・第１の銀行向送信用電文記憶部、４１０・・・現在残高付事業者向送信用電文作成部、４１１・・・現在残高付事業者向送信用電文記憶部、４１２・・・情報比較部、４１３・・・利用期間情報生成部、４１４・・・事業者サーバ送信用利用者情報生成部、４１５・・・事業者サーバ送信用情報記憶部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】