Financial information management device, control method for financial information management device, and control program for financial information management device

Abstract

To provide a finance-related information management device and the like that ensure transaction security without requiring users to perform complicated procedures when withdrawing from a deposit account of a financial institution to charge electronic currency such as electronic money.SOLUTION: A finance-related information management device 40 is capable of communicating with a user terminal device 10, a business management device 20, which is a management device of a business entity, and a financial institution side management device 30, which is a management device of the financial institution. If a predetermined condition is reached, automatic account withdrawal is executed that automatically withdrawals a predetermined amount from a deposit account of the financial institution and increases the electronic currency of the terminal device. The execution of automatic account withdrawal does not require to input user financial institution password information. The execution of automatic account withdrawal is permitted based on the past automatic account withdrawal execution information, which is automatic account withdrawal execution record information in the past.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a financial-related information management device for managing financial-related information between a business operator and a financial institution, a control method for the financial-related information management device, and a control program for the financial-related information management device.

Background Art

[0002] Conventionally, there is "electronic money automatic recharge" that automatically recharges from a user's bank account or the like when the balance of electronic money or the like is low. However, in this "electronic money automatic recharge", in order to ensure the security of the transaction, input of a "password" or the like is required. (Patent Document 1, etc.)

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, for users of electronic money, there is a problem that it is cumbersome to be required to input a password or the like every time they recharge. In addition, when a financial institution or the like that manages devices such as ATMs for recharging electronic money or the like is different from the financial institution or the like used by the user, there is also a problem that the financial institution has to let other financial institutions or the like manage the "password" or the like.

[0005] Therefore, an object of the present invention is to provide a financial-related information management device, a control method for the financial-related information management device, a control program for the financial-related information management device, etc., which can ensure the safety of transactions without requiring complicated procedures for users when withdrawing money from a deposit account of a financial institution when charging (depositing) electronic currency such as electronic money.

[0006] The above objective is achieved by a financial information management device in the present invention that manages financial information that can communicate with a user's terminal device, a business operator's management device which is a business operator's management device that communicates with the terminal device, and a financial institution's management device which is a financial institution's management device, wherein when the electronic currency of the terminal device reaches predetermined conditions, an automatic account withdrawal is performed in which funds are automatically withdrawn from the financial institution's deposit account and a predetermined amount is increased, the execution of the automatic account withdrawal does not require the user to enter their financial institution's PIN information, and the execution of the automatic account withdrawal is permitted based on past automatic account withdrawal execution information which is information on past automatic account withdrawal execution results.

[0007] According to the above configuration, automatic withdrawals from the account are possible without entering a PIN or other security information, thus eliminating the need to force users to enter a PIN. Furthermore, when an automatic account withdrawal (e.g., auto-charge) is executed, the system is configured to allow the execution of the automatic account withdrawal based on past automatic account withdrawal performance information (e.g., the number of withdrawals executed per day for each business), thus preventing inappropriate automatic account withdrawals.

[0008] Preferably, the past automatic account withdrawal execution performance information of the financial information management device is the information of the maximum number of automatic account withdrawals performed in the past for each business operator, and the information of the maximum number of performances is equal to or greater than a predetermined lower limit.

[0009] According to the above configuration, the past automatic account withdrawal execution history information is, for example, the maximum number of times automatic account withdrawals (e.g., auto-charge, etc.) have been executed in a single day for each business operator. Therefore, it is possible to accurately and proactively identify any unusual automatic account withdrawals by users. Furthermore, with the above configuration, since the maximum execution count information is above a predetermined lower limit information, it is possible to prevent situations such as denying automatic account withdrawals even when the number of automatic account withdrawals in the past is small, such as immediately after starting automatic account withdrawals.

[0010] Preferably, the financial information management device generates information that can be received by the financial institution based on registration-related information entered into the business management device by the user of the financial information management device in order to conduct transactions with the business, and the business management device generates information that can be received by the business based on information received from the financial institution.

[0011] According to the above configuration, based on registration-related information (e.g., name in kana, date of birth, bank name, etc.), information to be transmitted to financial institutions that can be received by financial institutions is generated, and based on information received from financial institutions, information to be transmitted to businesses that can be received by businesses is generated. Thus, when a business operator transmits information to a financial institution, the financial information management device creates and transmits information such as messages that can be received by the financial institution's management device. Furthermore, when a financial institution transmits information to a business operator, the financial information management device creates and transmits information such as messages that can be received by the business operator's management device.

[0012] In this way, the financial information management system allows the financial institution's management device and the business operator's management device to transmit information in a format that each can receive, enabling the business operator's management device and the financial institution's management device to exchange information with each other without any changes to their existing network systems. For example, each financial institution's management device uses a different API (Application Programming Interface), so the business operator's management device needed to build a network adapted to the different APIs in order to communicate with each financial institution's management device. In contrast, in the present invention, the financial information management device generates messages and the like that are tailored to the API of each financial institution's management device. Therefore, the business operator's management device does not need to build a network tailored to different APIs in order to communicate with each financial institution's management device. It can use the existing network as is, and costs can be significantly reduced.

[0013] The above objective is achieved by a control method for a financial information management device that manages financial information that can communicate with a user's terminal device, a business operator's management device which is a business operator's management device that communicates with the terminal device, and a financial institution's management device which is a financial institution's management device, wherein when the electronic currency of the terminal device reaches predetermined conditions, an automatic account withdrawal is performed in which funds are automatically withdrawn from the financial institution's deposit account and a predetermined amount is increased, the execution of the automatic account withdrawal does not require the user to enter their financial institution's PIN information, and the execution of the automatic account withdrawal is permitted based on past automatic account withdrawal execution information which is information on past automatic account withdrawal execution results.

[0014] The above objective is achieved by a control program for a financial information management device, which manages financial information that can communicate with a user's terminal device, a business management device which is a management device of a business operator that communicates with the terminal device, and a financial institution management device which is a management device of a financial institution. The program is configured to perform an automatic account withdrawal, in which, when the electronic currency of the terminal device reaches predetermined conditions, funds are automatically withdrawn from the deposit account of the financial institution and a predetermined amount is increased; the execution of the automatic account withdrawal does not require the user to enter their financial institution PIN information; and the execution of the automatic account withdrawal is permitted based on past automatic account withdrawal execution information, which is information on past automatic account withdrawal execution results. [Effects of the Invention]

[0015] As described above, the present invention has the advantage of providing a financial information management device, a control method for the financial information management device, and a control program for the financial information management device that can ensure the security of transactions without requiring users to go through complicated procedures when charging (depositing) electronic currency such as electronic money from a financial institution's deposit account. [Brief explanation of the drawing]

[0016] [Figure 1] For example, it is a schematic explanatory diagram showing an electronic money management system 1, which is a "financial-related information management system" according to an embodiment of the present invention. [Figure 2] It is a schematic block diagram showing the main configuration of the operator server 20 in FIG. 1. [Figure 3] It is a schematic block diagram showing the main configuration of the first various information storage units 200 on the operator server side. [Figure 4] It is a schematic block diagram showing the main configuration of the second various information storage units 210 on the operator server side. [Figure 5] It is a schematic block diagram showing the main configuration of the management server 40 in FIG. 1. [Figure 6] It is a schematic block diagram showing the main configuration of the first various information storage units 400 on the management server side. [Figure 7] It is a schematic block diagram showing the main configuration of the second various information storage units 410 on the management server side. [Figure 8] It is a schematic block diagram showing the main configuration of the third various information storage units 420 on the management server side. [Figure 9] It is a schematic block diagram showing the main configuration of the fourth various information storage units 430 on the management server side. [Figure 10] It is a schematic block diagram showing the main configuration of the fifth various information storage units 440 on the management server side. [Figure 11] It is a schematic block diagram showing the main configuration of the bank server 30 in FIG. 1. [Figure 12] It is a schematic block diagram showing the main configuration of the first various information storage units 300 on the bank server side. [Figure 13] It is a schematic block diagram showing the main configuration of the second various information storage units 310 on the bank server side. [Figure 14] It is a main schematic flowchart showing the user registration process. [Figure 15] It is another main schematic flowchart showing the user registration process. [Figure 16] It is another main schematic flowchart showing the user registration process. [Figure 17]This is a schematic flowchart illustrating the main steps involved in the user's recharge process. [Figure 18] This is another main schematic flowchart illustrating the user's one-time charging process. [Figure 19] This is another main schematic flowchart illustrating the user's one-time charging process. [Figure 20] This is a general flowchart illustrating the main steps involved in registering for automatic account withdrawals (auto-charge, etc.) for users. [Figure 21] This is another schematic flowchart illustrating the process of executing automatic account withdrawals (such as auto-charge). [Figure 22] This is another schematic flowchart illustrating the process of executing automatic account withdrawals (such as auto-charge). [Figure 23] This is another schematic flowchart illustrating the process of executing automatic account withdrawals (such as auto-charge). [Figure 24] This is a schematic diagram illustrating the "Administrative User Information (Part 1)" stored in ST4. [Figure 25] This is a schematic diagram illustrating the administrator user information (part 2) stored in ST6. [Figure 26] This is a schematic diagram illustrating the administrator user information, showing the state where the "permission flag" is set in ST13. [Figure 27] This is a schematic diagram illustrating the "administrative user information (part 4)" in ST14, where "token information" is stored. [Figure 28] This is a schematic diagram illustrating the contents of the "management-side charge request information (part 1)" stored in the "management-side charge request information storage unit 421" in ST25. [Figure 29] This is a schematic diagram illustrating the contents of the "management-side charge request information (part 2)" stored in the "management-side charge request information storage unit 421" in ST27. [Figure 30] This is a schematic diagram illustrating the administrator user information (part 5) in ST28, which includes information such as "amount charged each time," "transaction ID," and "transaction date and time." [Figure 31]This is a schematic diagram illustrating the "Administrator User Information (Part 6)" with the "Transaction Result (Withdrawal)" added in ST35. [Figure 32] This is a schematic diagram illustrating "Administrative User Information (Part 7)" with the "Transaction Result (Automatic Account Withdrawal)" information added. [Modes for carrying out the invention]

[0017] Hereinafter, preferred embodiments of this invention will be described in detail with reference to the accompanying drawings and other materials. Furthermore, the embodiments described below are preferred examples of the present invention and are therefore technically preferable. Although various limitations are attached, the scope of the present invention is not limited to these embodiments unless otherwise stated in the following description.

[0018] Figure 1 is a schematic diagram illustrating an "electronic currency information management system 1" having a management server 40, which is an "institutional information management device" according to an embodiment of the present invention. As shown in Figure 1, System 1 includes, for example, a terminal device 10 held by a user who uses or wishes to use electronic currency such as X Pay, a business server 20 which is a business-side management device for a business that handles electronic currency such as X Pay, and a bank server 30 which is a financial institution-side management device such as a bank.

[0019] Furthermore, the system 1 includes a management server 40, which is a financial information management device that manages financial information such as user account information, between these terminal devices 10, a business operator server 20, and a bank server 30. Furthermore, as shown in Figure 1, these terminal devices 10, carrier servers 20, management servers 40, etc., are connected to each other via the internet network 2, base stations 3, etc., enabling them to communicate with one another. Furthermore, as shown in Figure 1, the management server 40 is configured to communicate with the bank server 30.

[0020] As shown in Figure 1, the terminal device 10 has an input device and a display unit, such as a "touch panel 11". Here, "touch panel 11" refers to a display unit, such as a display, and a position input device. It is an electronic component that combines various elements, and when the user touches the display on the screen, various information is displayed. It is an input device that can input [text]. Furthermore, the terminal device 10 shown in Figure 1 has a terminal device-side communication device (not shown).

[0021] Furthermore, the terminal device 10, operator server 20, management server 40, bank server 30, etc. in the "Electronic Currency Management System 1" shown in Figure 1 are computers, each possessing a CPU (Central Processing Unit), RAM (Random Access Memory), ROM (Read Only Memory), hard disk, etc., and are connected via a bus.

[0022] (Regarding the main configuration of the operator server 20) Figure 2 is a schematic block diagram showing the main configuration of the operator server 20 in Figure 1. As shown in Figure 2, the operator server 20 has an "operator-side control unit 21," which controls the "operator-side communication device 22," the "operator-side display 23," and the "operator-side various information input devices 24." Furthermore, the control unit 21 also controls the "first various information storage unit 200 on the carrier server side" and the "second various information storage unit 210 on the carrier server side" shown in Figure 2.

[0023] Figures 3 and 4 are schematic block diagrams showing the main configurations of the "first information storage unit 200 on the carrier server side" and the "second information storage unit 210 on the carrier server side," respectively. Their details will be described later.

[0024] (Regarding management server 40) Figure 5 is a schematic block diagram showing the main configuration of the management server 40 in Figure 1. As shown in Figure 5, the management server 40 has a "management control unit 41", which controls the "management communication device 42", the "management display 43", and the "management various information input devices 44". Furthermore, the control unit 41 also controls the "first various information storage unit 400 on the management server side," the "second various information storage unit 410 on the management server side," the "third various information storage unit 420 on the management server side," the "fourth various information storage unit 430 on the management server side," and the "fifth various information storage unit 440 on the management server side," as shown in Figure 5.

[0025] Figures 6 to 10 are schematic block diagrams showing the main configurations of the "first information storage unit 400 on the management server side" to the "fifth information storage unit 440 on the management server side," respectively. Their contents will be described later.

[0026] (Regarding bank server 30) Figure 11 is a schematic block diagram showing the main components of the bank server 30 in Figure 1. As shown in Figure 11, the bank server 30 has a "bank-side control unit 31", which controls the "bank-side communication device 32", "bank-side display 33", "bank-side various information input device 34", "bank server-side first various information storage unit 300", and "bank server-side second various information storage unit 310".

[0027] Figures 12 and 13 are schematic block diagrams showing the main configurations of the "first information storage unit 300 on the bank server side" and the "second information storage unit 310 on the bank server side." These details will be described later.

[0028] (Example of operation of Electronic Currency Management System 1) The following describes examples of the operation of the "Electronic Currency Management System 1" according to this embodiment. In this embodiment, we will first describe the "user registration process" in which a user who wishes to use the X electronic currency operates the terminal device 10 shown in Figure 1, accesses the business server 20 of a business that handles the X electronic currency via the internet network 2, etc., and performs a "registration procedure" to make it available for use.

[0029] Figures 14 to 16 are main schematic flowcharts showing the user registration process, and Figures 17 to 19 are main schematic flowcharts showing the user's pay-as-you-go (on-demand) charging process. Furthermore, Figure 20 is a schematic flowchart showing the main steps involved in registering for automatic account withdrawals (auto-charge, etc.) by a user, and Figures 21 to 23 are schematic flowcharts showing the steps involved in executing automatic account withdrawals (auto-charge, etc.).

[0030] First, the user registration process will be explained, followed by the "on-demand top-up process" in which a registered user operates the terminal device 10 shown in Figure 1 and tops up X electronic currency from their bank account via the internet network 2, etc. Next, we will explain the process for registering for automatic account withdrawals and the process for executing them.

[0031] Here, the "on-demand charge process" refers to the process by which a user can, at any time as needed, convert cash in their bank account into X electronic currency usable on the terminal device 10. This process differs from the automatic account withdrawal process, such as the auto-charge process, which, under predetermined conditions, automatically converts cash in the user's bank account into X electronic currency usable on the terminal device 10, as will be described later.

[0032] (User registration process) First, in step 1 of Figure 14 (hereinafter referred to as "ST"), a user who wishes to use X electronic currency (X Pay, etc.) operates their own terminal device 10 in Figure 1 and accesses the X electronic currency (X Pay, etc.) service provider server 20 in Figure 1 via the internet network 2, etc.

[0033] Next, proceed to ST2. In ST2, the "Business Operator Registration Acceptance Processing Unit (Program) 201" shown in Figure 3 of the business operator server 20 shown in Figure 1 operates and refers to the "Registration Acceptance Information Storage Unit 202" shown in Figure 3. The memory unit 202 stores information to be displayed as registered information on the touch panel 11 of the terminal device 10, such as basic registration information (e.g., "name in kana, date of birth, bank name, branch name, account type, account number, etc."). Therefore, the processing unit 201 displays a screen on the touch panel 11 of the terminal device 10 requesting the input of "basic registration information (for example, "name in kana, date of birth, bank name, branch name, account type, account number")." Here, basic registration information is an example of registration-related information and general registration-related information.

[0034] Next, the process proceeds to ST3. In ST3, once the user has finished inputting information into the terminal device 10, the connection with the terminal device 10 is automatically changed from the operator server 20 to the management server 40. The "Management-side registration acceptance processing unit (program) 401" shown in Figure 6 of the management server 40 then operates, and the management server 40 prompts the terminal device 10's touch panel 11 to input the "current balance" and "PIN". In addition, users will be asked to enter their "Name (in Katakana)", "Date of Birth", "Occupation", "Purpose of Use", "Telephone Number", and "Account (Deposit Account) Information (Branch Name, Account Type, Account Number)". These "current balance" and "PIN" are examples of registration-related information and financial institution identification information.

[0035] Next, the process proceeds to ST4. In ST4, once the user has completed entering information such as "current balance (e.g., 1,000,000 yen)", "PIN (e.g., 5678)", "name in Katakana", "date of birth", "occupation", "purpose of use", and "account information (branch name, account type, account number)", the processing unit 401 of the management server 40 operates and stores this information in the "management-side user information" of the "management-side user information storage unit 402" in Figure 6.

[0036] Figure 24 is a schematic diagram illustrating the "Administrative User Information (Part 1)" stored in ST4. As shown in Figure 24, at this stage, the administrator's user information, including "User ID," "Name (in Katakana)," "Bank Name," "Branch Name," "Account Type," "Account Number," "Current Balance," "PIN," "Date of Birth," "Purpose of Use," "Occupation," and "Telephone Number," is stored.

[0037] Thus, in this embodiment, the user's "current balance" and "PIN" are not entered into the service provider's server 20. Therefore, PINs, account numbers, etc., will not be leaked to electronic currency operators, and their dissemination can be prevented.

[0038] Next, the process proceeds to ST5. In ST5, the management server 40 receives data on "name in kana" and "date of birth" from the business server 20 and determines whether the "name in kana" and "date of birth" entered in the business server 20 match the "name in kana" and "date of birth" entered in the management server 40.

[0039] Next, proceed to ST6. In ST6, the "MS Information Acquisition Unit (Program) 403" in Figure 6 of the management server 40 operates and refers to the "MS Information Storage Unit 404" in Figure 6. This "MS information storage unit 404" stores the magnetic stripe (MS) information of each bank's cash card. Here, MS information refers to the information stored on each bank's ATM card, where account numbers and other data are stored in an encrypted form.

[0040] Furthermore, the acquisition unit 403 refers to the "bank name (e.g., ABC Bank)" of the user ID in the management-side user information (part 1) in Figures 6 and 24, acquires the magnetic stripe (MS) information of the cash card of that bank (e.g., ABC Bank), and stores it in the "management-side user information storage unit 402" in Figure 6.

[0041] Figure 25 is a schematic diagram illustrating the administrator user information (part 2) stored in ST6. As shown in Figure 25, unlike the above-mentioned Part 1, the administrator user information (Part 2) stores "MS information".

[0042] Next, proceed to ST7. In ST7, the "First Bank Message Creation Unit (Program) 405" of the management server 40 (Figure 6) operates, and the "Bank Name (ABC Bank)" is generated from the management user information (part 2) of the management user information storage unit 402 (Figures 6 and 25). "Branch name (Osaki Branch)" "Account type (Savings)" "Account number (1234567)" "MS Information Obtain the "Information (...)" and "PIN (5678)" and create the "First Message to Send to Bank". The message is then stored in the "First Bank-to-Bank Message Storage Unit 406" in Figure 6.

[0043] Here, "the first message to be sent to a bank" is an example of information to be sent to a financial institution, and is a message that can be received by financial institutions such as banks. In this embodiment, for example, the message is in accordance with an API (Application Programming Intercace) that ABC Bank can receive. Although each bank uses a different API for sending messages to banks, the management server 40 in this embodiment obtains information on each bank's API, and therefore can create messages that match the specific bank (for example, ABC Bank).

[0044] Therefore, even if a business operator obtains user information, they can send that information to the management server 40, which in turn can send it to the bank server 30. This eliminates the need for the business operator to build a network in accordance with APIs that differ from bank to bank, allowing them to communicate with banks at an extremely low cost. Furthermore, since banks can communicate with the management server 40 using the API network they have been using, there is no need to build a new network, and communication can be done at an extremely low cost.

[0045] Next, the process proceeds to ST8. In ST8, the management server 40 sends the message from the "first message storage unit 406 for sending to the bank" shown in Figure 6 to the "bank server 30". After transmission, the management server 40 deletes the "PIN" from the management user information (part 2) in Figure 25 and the "PIN" from the "first bank-to-bank transmission message" in the "first bank-to-bank transmission message storage unit 406" in Figure 6.

[0046] Thus, in this embodiment, the system is extremely secure because it does not store the "PIN," which is extremely important to the user, on either the service provider server 20 or the management server 40.

[0047] Next, the process proceeds to ST9. In ST9, the "PIN matching processing unit (program) 301" shown in Figure 12 of the bank server 30 operates and obtains the "PIN" information for the account in question from the "account number" etc. of the received "first message to be sent to the bank" on the bank server 30. Then, the PIN for the first message to be sent to the bank is matched with the PIN of the bank server 30.

[0048] Next, the process proceeds to ST10. In ST10, if the bank server 30 finds that the PIN for the user's account matches exactly as determined by the matching process, the "Current Balance Message Creation Unit (Program) 302" shown in Figure 12 of the bank server 30 will activate. Then, a "Message to be sent to the bank with current balance" including the "current balance" in the bank server 30 of the account is created and stored in the "Message to be sent to the bank with current balance storage unit 303" in Figure 12. This "Message to be sent to a bank with a current balance" also includes the account holder's name in katakana, date of birth, a flag to identify whether or not the account holder's identity has been verified by the bank (identity verification flag), and a flag to identify whether the account holder is an individual or a corporation (individual / corporate identification flag). Please note that this PIN is just one example of PIN information.

[0049] This message sent to the bank with the current balance is created in accordance with the bank's API and, as shown in Figure 12, includes information such as the bank name (ABC_bank), branch name (Osaki_Branch), account type (Savings), account number (1234567), MS number (abvdefg), PIN (efgh), and the bank's current balance (1,000,000 yen).

[0050] In this process, the bank server 30 determines whether the "PIN" entered by the user on the terminal device 10 is correct.

[0051] Next, the process proceeds to ST11. In ST11, the bank server 30 sends the "Message to be sent to a bank with a current balance" from the "Message storage unit 303 for sending messages to banks with current balances" in Figure 12 to the management server 40.

[0052] Next, proceed to ST12. In ST12, the management server 40 is shown as "Current balance-bearing business operator" in Figure 6. The "Message Creation Unit (Program) 407 for Sending Messages To Banks" is activated, and upon receiving the message "Current Balance To Banks Sending Messages," Convert the "Message for Use" to "Message for Sending to Businesses with Current Balances". Then, it is stored in the "Current Balance-Related Business Operator Message Storage Unit 411" in Figure 7.

[0053] Here, the "Message to be sent to a carrier" in the currently available balance-based carrier-based message is an example of carrier-based transmission information that the carrier server 20 can receive. Thus, in this embodiment, the management server 40 converts special messages for banks into messages for businesses, so businesses do not need to build a new network in accordance with the API adopted by the bank in order to communicate with the bank, and communication costs can be kept low.

[0054] As described above, in this embodiment, the management server 40 transmits information in a message format that can be received by the bank server 30 and the business operator server 20. Therefore, the bank server 30 and the business operator server 20 can exchange information with each other without changing their existing network system or anything else. For example, since each bank's bank server 30 uses a different API, the business server 20 needed to build a network adapted to the different APIs in order to communicate with each bank server 30. In contrast, in this embodiment, the management server 40 generates messages tailored to the API of each bank server 30. Therefore, the carrier server 20 does not need to build a network tailored to different APIs in order to communicate with the bank servers 30. It can use the existing network as is, significantly reducing costs.

[0055] Next, the process proceeds to ST13. In ST13, the "Information Comparison Unit (Matching) (Program) 412" of the management server 40 operates and compares the "Name in Katakana," "Date of Birth," and "Current Balance on the Bank Side (1,000,000 Yen)" of the "Message to Send to Businesses with Current Balance" in the "Message Storage Unit 411 for Sending Messages with Current Balance" in Figure 7 with the "Name in Katakana," "Date of Birth," and "Current Balance (1,000,000 Yen)" of the "Management User Information (Part 2)" in the "Management User Information Storage Unit 402" in Figures 6 and 25. It determines whether the data matches, and if they match and identity verification has been performed and it is confirmed that the account holder is an individual, it sets the "Permission to Use Flag" in the Management User Information Storage Unit 402 in Figure 6. Furthermore, this identity verification and confirmation that the account holder is an individual are performed based on the "Message to be sent to a business with a current balance" shown in Figure 7.

[0056] Figure 26 is a schematic diagram illustrating the administrator user information when the "permission flag" is set in ST13. As shown in Figure 26, the administrator user information (part 3) has a "permission flag" set. Please note that the current balance shown here is just an example of balance information.

[0057] In this embodiment, the bank server 30 verifies that the PIN entered by the user matches the PIN registered on the user's cash card. Furthermore, the management server 40 compares the "Kana name," "date of birth," and current balance entered by the user with the "Kana name," "date of birth," and current balance obtained from the bank server 30. The "permission flag" is set only if these match, and if the bank has verified the user's identity and confirmed that the account holder is an individual. Therefore, user authentication can be reliably performed.

[0058] In particular, in this embodiment, the matching of the PIN is performed by the bank server 30, and the matching of the current balance, etc., is performed by the management server 40, so more reliable user authentication is possible.

[0059] Next, the process proceeds to ST14. In ST14, the "Usage Period Information (Token) Generation Unit (Program) 413" in Figure 7 of the management server 40 operates, generates token information (valid for 120 days from a specific date), and registers it in the "Management-Side User Information Storage Unit 402" in Figure 6. Figure 27 is a schematic diagram illustrating the "administrative user information (part 4)" in which the "token information" is stored in ST14. As shown in Figure 27, the reliability of user authentication is ensured by adding information that limits the validity period of the user flag.

[0060] Next, the process proceeds to ST15. In ST15, the "User Information Generation Unit (Program) 414 for Transmission to the Service Provider Server" shown in Figure 7 of the management server 40 operates, generates "Information for Transmission to the Service Provider Server," and stores it in the "Information Storage Unit 415 for Transmission to the Service Provider Server" shown in Figure 7. This information for transmission to the carrier server is generated in a format that the carrier server 20 can receive, and is limited to information necessary for the carrier, excluding the user's ATM card PIN and current bank account balance.

[0061] Specifically, the "Information to be sent to the service provider server" in Figure 7 includes service provider ID (e.g., 2001), user ID (e.g., 10001), name in katakana, bank name (e.g., ABC Bank), branch name (e.g., Osaki Branch), account type (e.g., ordinary), account number (e.g., 1234567), token (e.g., 20200130), etc.

[0062] In this embodiment, the operator can communicate with the bank server 30 via the management server 40 without changing the existing system, and the configuration prevents the acquisition of confidential user information. Therefore, the system is easy for businesses to use, automatically retrieves necessary information, and is highly secure for users.

[0063] Next, the process proceeds to ST16. In ST16, the management server 40 transmits the "information for transmission to the carrier server" from the "information storage unit for transmission to the carrier server 415" in Figure 7 to the carrier server 20.

[0064] Next, the process proceeds to ST17. In ST17, the carrier server 20 stores the "carrier-side user information" in the "carrier-side user information storage unit 203" shown in Figure 3 of the carrier server 20, based on the received "carrier server transmission information". Specifically, as shown in the "Business Operator User Information Storage Unit 203" in Figure 3, information such as business operator ID (e.g., 2001), user ID (e.g., 10001), name in kana, bank name (e.g., ABC Bank), branch name (e.g., Osaki Branch), account type (e.g., ordinary), account number (e.g., 1234567), and token (e.g., 20200130) is stored.

[0065] This allows the service provider server 20 to automatically obtain the necessary information of users who use the X electronic currency.

[0066] Next, the process proceeds to ST18. In ST18, the management server 40 displays a registration completion screen on the touch panel 11 of the terminal device 10, and the "user registration" is completed.

[0067] (Charging process each time) The following describes the process by which a user who has completed registration to use X electronic currency can "charge" X electronic currency, that is, convert cash in their bank account into X electronic currency usable on terminal device 10. First, in ST21 of Figure 17, a user who wishes to charge electronic currency accesses the electronic currency provider's server 20 using their own terminal device 10.

[0068] Next, the process proceeds to ST22. In ST22, the "One-Time Charge Acceptance Processing Unit (Program) 204" shown in Figure 3 of the operator server 20 is activated, and a screen for inputting one-time charge information, such as the one-time charge amount, is displayed on the touch panel 11 of the terminal device 10.

[0069] Next, the process proceeds to ST23. In ST23, once the input is complete, the processing unit 204 operates and stores the amount charged each time in the "operator-side charge acceptance information storage unit 205" shown in Figure 3. In the business operator's one-time charge acceptance information storage unit 205 in Figure 3, the following information is stored: "Bank name (e.g., ABC Bank)", "Branch name (e.g., Osaki Branch)", "Account type (e.g., Savings)", "Account number (e.g., 124567)", and "One-time charge amount (e.g., 1,000 yen)".

[0070] Next, the process proceeds to ST24. In ST24, the connection with the terminal device 10 is automatically changed from the operator server 20 to the management server 40, and the operator server 20 transmits the "operator-side charge request information" from the "operator-side charge request information storage unit 205" in Figure 3 to the management server 40.

[0071] Next, the process proceeds to ST25. In ST25, the management server 40 stores the received "operator-side charge request information" as "management-side charge request information" in the "management-side per-charge request information storage unit 421" shown in Figure 8. Figure 28 is a schematic diagram illustrating the contents of the "management-side charge request information (part 1)" stored in the "management-side charge request information storage unit 421" in ST25. As shown in Figure 28, the "Management-side per-charge request information (part 1)" consists of the following items. "Bank name (e.g., ABC Bank)", "Branch name (e.g., Osaki Branch)", "Account type (e.g., Savings)", "Account number (e.g., 1234567)", "Amount to be charged each time (e.g., 1,000 yen)"

[0072] Next, the process proceeds to ST26. In ST26, the "PIN request unit (program) 422" shown in Figure 8 of the management server 40 is activated, and a "PIN" input screen is displayed on the touch panel 11 of the terminal device 10.

[0073] Next, the process proceeds to ST27. In ST27, upon receiving input, the request unit 422 of the management server 40 stores the entered "PIN (for example, 5678)" in the "management-side per-charge request information storage unit 421" shown in Figure 8.

[0074] Figure 29 is a schematic diagram illustrating the contents of the "management-side charge request information (part 2)" stored in the "management-side charge request information storage unit 421" in ST27. As shown in Figure 29, the "Management-side per-charge request information (part 2)" includes the following items. "Bank name (e.g., ABC Bank)", "Branch name (e.g., Osaki Branch)", "Account type (e.g., Savings)", "Account number (e.g., 1234567)", "Amount to be charged each time (e.g., 1,000 yen)", "PIN (e.g., 5678)"

[0075] Thus, in this embodiment, the user's PIN is entered directly into the management server 40, not the service provider server 20. Therefore, the service provider does not acquire unnecessary information, and the user can ensure the confidentiality of their PIN.

[0076] Next, the process proceeds to ST28. In ST28, the "User Determination Unit (Program) 423" in Figure 8 of the management server 40 operates and compares the "Management Side One-Time Charge Reception Information" in the "Management Side One-Time Charge Reception Information Storage Unit 421" in Figure 8 with the "Management Side User Information" in the "Management Side User Information Storage Unit 402" in Figure 6 of the management server 40. Specifically, the "Management-side one-time charge request information (part 2)" in Figure 29 and the "Management-side user information (part 4)" in Figure 27 are compared to determine whether the information matches. If they match, the "one-time charge amount," "transaction ID," and "transaction date and time" information are stored in the "Management-side user information storage unit 402" in Figure 6.

[0077] Figure 30 is a schematic diagram illustrating the administrator user information (part 5) in ST28, to which information such as "charge amount per transaction," "transaction ID," and "transaction date and time" has been added. As shown in Figure 30, the administrator user information (part 5) stores information such as "amount charged each time (for example, 1,000 yen)", "transaction ID (...)", and "transaction date and time (...)".

[0078] Thus, in this embodiment, even for users who have gone through the registration process, the management server 40 performs identity verification again when charging, resulting in a more secure system.

[0079] Next, the process proceeds to ST29. In ST29, the "Second Bank Message Creation Unit (Program) 424" in Figure 8 of the management server 40 operates and creates a "Second Bank Message," such as an ATM message, based on the "Management User Information (Part 5)" in Figure 30 of the "Management User Information Storage Unit 402" in Figure 6 and the "Management Charge Acceptance Information (Part 2)" in Figure 29 of the "Management Charge Acceptance Information Storage Unit 421" in Figure 8, and stores it in the "Second Bank Message Storage Unit 425" in Figure 8.

[0080] Specifically, as shown in Figure 8, the content of the "second message to be sent to the bank" is as follows: "Bank name (e.g., ABC_bank)", "Branch name (e.g., Osaki_branch)", "Account type (Savings)", "Account number (e.g., 1234567)", "MS information (e.g., Abcdefg)", "PIN (e.g., efgh)", "Charge method type (0)", "PIN check type (0)", "Charge amount per transaction (e.g., 1,000 yen)"

[0081] Here, the charge method category refers to the distinction between one-time charge or auto-charge (automatic account withdrawal), and "0" means one-time charge. Furthermore, the "Encryption Number Check Classification" indicates whether or not an encryption number check is required, with "0" meaning that a check is required. Since cipher code verification is not required for auto-charge but is required for one-time charges, it is listed here as "Check Required (0)".

[0082] Next, the process proceeds to ST30. In ST30, the management server 40 sends the "second message to be sent to the bank" from the "second message to be sent to the bank storage unit 425" shown in Figure 8 to the "bank server (ABC Bank) 30". Then, the "PIN" information in the "second message to be sent to the bank" is deleted.

[0083] Therefore, the management server 40 does not store the user's highly confidential ATM card PIN, thus enhancing security.

[0084] Next, the process proceeds to ST31. In ST31, the "Withdrawal Decision Processing Unit (Program) 304" shown in Figure 12 of the bank server 30 operates to determine whether the "One-Time Charge Amount" is eligible for withdrawal. If it is eligible, the withdrawal process (1,000 yen) is performed (accounting system processing). Then, a "Message to Send to Bank After Withdrawal" is generated and stored in the "Message to Send to Bank After Withdrawal Storage Unit 305" in Figure 12.

[0085] Next, the process proceeds to ST32. In ST32, the bank server 30 sends the "Message to Send to Bank After Withdrawal" from the "Message Storage Unit 305 for Messages to Send to Bank After Withdrawal" shown in Figure 12 to the management server 40.

[0086] Next, the process proceeds to ST33. In ST33, the management server 40 stores the received "Message to Send to Withdrawn Bank" in the "Management-Side Message to Send to Withdrawn Bank Storage Unit 426" shown in Figure 8.

[0087] Next, the process proceeds to ST34. In ST34, the "Message Conversion Processing Unit (Program) 427 for Sending to Businesses" shown in Figure 8 of the management server 40 operates, converting the "Message to Sending to Banks with Disbursement by the Management Side" in the "Message Storage Unit 426 for Sending to Banks with Disbursement by the Management Side" shown in Figure 8 into a "Message to Sending to Businesses with Disbursement by the Management Side," and storing it in the "Message Storage Unit 431 for Sending to Businesses with Disbursement by the Management Side" shown in Figure 9.

[0088] Therefore, similar to the user registration process described above, the management server 40 generates and sends messages to the bank server 30 and the business operator server 20. As a result, businesses and banks can continue to use their existing systems without making any changes, and this system 1 can be used at a low cost.

[0089] Next, the process proceeds to ST35. In ST35, the management server 40 stores the "Transaction Result (Withdrawal) (for example, 1,000 yen)" of the "Message to be sent to the management-side withdrawn business operator" in the "Message storage unit 431 for sending messages to the management-side withdrawn business operator" in Figure 9 in the "Management-side user information storage unit 402" in Figure 6.

[0090] Figure 31 is a schematic diagram showing the "Administrator-side user information (part 6)" with "Transaction result (withdrawal)" added in ST35. As shown in Figure 31, the management server 40 is configured to manage user information excluding the password.

[0091] Next, the process proceeds to ST36. In ST36, the management server 40 displays on the terminal device 10's touch panel 11 that 1000 yen has been deposited as electronic currency through the charge.

[0092] Next, the process proceeds to ST37. In ST37, once approval is entered on terminal device 10, a transaction completion signal is sent to the business server 20.

[0093] Next, the process proceeds to ST38. In ST38, the carrier server 20 obtains the "Message to be sent to the carrier after withdrawal by the management side" from the management server 40, and stores it in the "Carrier-side user information" of the "Carrier-side user information storage unit 203" in Figure 3, along with the "Transaction result (withdrawal)" information.

[0094] In the charging process of this embodiment, communication from ST24 to the terminal device 10 is automatically changed to the management server 40 instead of the operator server 20. As a result, the operator server 20 is unable to obtain charge-related information, such as transaction result (withdrawal) information. Therefore, in ST37, when a transaction is completed, a signal is sent from the terminal device 10 to the carrier server 20, and the carrier server 20 can obtain information such as the transaction result (withdrawal) from the management server 40. In other words, confidential information such as PINs is not entered into the service provider server 20, and the system is configured so that necessary information such as transaction results (withdrawals) can be quickly and completely obtained by the service provider server 20.

[0095] In addition, according to this embodiment, even if communication between the business operator server 20, the bank server 30, and the management server 40 is interrupted, the business operator can still verify the consistency of transaction results between the business operator server 20, the management server 40, and the bank server 30, and correct any inconsistencies.

[0096] (Automatic account withdrawal (auto-charge, etc.) registration process) Next, we will explain the registration process for a user who has completed registration to use X electronic currency, specifically for "automatic account withdrawal," that is, when the amount of X electronic currency available on the terminal device 10 reaches a predetermined amount (for example, 1,000 yen or less), to automatically withdraw cash (10,000 yen) from their bank account and convert it to X electronic currency on the terminal device 10.

[0097] Figure 20 is a schematic flowchart illustrating the automated account withdrawal registration process. First, in ST41 of Figure 20, users who wish to auto-charge their X electronic currency should... The terminal device 10 accesses the electronic currency business server 20.

[0098] Next, the process proceeds to ST42. In ST42, the "Automatic Account Withdrawal (e.g., Autocharge) Acceptance Processing Unit (Program) 211" shown in Figure 4 of the business server 20 operates, and an input screen for automatic account withdrawal information (e.g., autocharge withdrawal, etc.), specifically the automatic account withdrawal amount (e.g., 10,000 yen) and the amount to be executed for automatic account withdrawal (e.g., autocharge execution amount, 1,000 yen), is displayed on the touch panel 11 of the terminal device 10.

[0099] Next, once the input is complete, the process proceeds to ST43. In ST43, the same processing unit 211 operates and stores the auto-charge withdrawal amount (10,000 yen) and the auto-charge execution amount (1,000 yen) in the "Business Operator Auto-Account Withdrawal Reception Information Storage Unit 212" in Figure 4. The "Business Operator Automatic Account Withdrawal Reception Information Storage Unit 212" stores information such as "Bank Name (e.g., ABC Bank)", "Branch Name (e.g., Osaki Branch)", "Account Type (e.g., Savings)", "Account Number (e.g., 124567)", "Auto-Charge Withdrawal Amount (e.g., 10,000 yen)", and "Auto-Charge Execution Amount (e.g., 1,000 yen)". This completes the registration process for automatic account withdrawal (auto-charge) of X electronic currency.

[0100] (Execution process for automatic account withdrawal (auto-charge)) Figure 21 is a schematic flowchart illustrating the process of executing an automated account withdrawal. The process will be explained below in accordance with Figure 21. First, in ST51 in Figure 21, the "Automatic Account Withdrawal Reception Processing Unit (Program) 211" in Figure 4 of the business server 20 operates, referencing the balance information of the X electronic currency of the terminal device 10 in the "Electronic Currency Balance Information Storage Unit 213 for Each Terminal Device" in Figure 4 of the business server 20, and the "Automatic Account Withdrawal Execution Amount (1,000 yen)" in the "Business Operator's Automatic Account Withdrawal Reception Information Storage Unit 212" in Figure 4. The system determines whether the balance information corresponds to the automatic account withdrawal execution amount, and if it does, it sends this "Business Operator's Automatic Account Withdrawal Reception Information" to the management server 40.

[0101] Next, the process proceeds to ST52. In ST52, the "automatic account withdrawal request information on the business side" received from the business server 20 is stored in the "automatic account withdrawal request information storage unit on the management side 432" shown in Figure 9.

[0102] Next, the process proceeds to ST53. In ST53, the "Provisional Total Withdrawal Execution Count Generation Unit (Program) 433" in Figure 9 operates. Upon receiving "Business Operator Automatic Account Withdrawal Request Information" from the business operator server 20, it provisionally includes the withdrawal in the "Withdrawal Execution Count" as if the withdrawal had been executed, adds it to the total number of withdrawal executions for the business operator for that day, and stores the total number as the provisional total withdrawal execution count for that day in the "Provisional Total Withdrawal Execution Count Storage Unit 434" in Figure 9.

[0103] Next, the process proceeds to ST54. In ST54, the "Withdrawal Restriction and Other Criteria Information Generation Unit (Program) 436" in Figure 9 operates and refers to the "Automatic Account Withdrawal History Information Storage Unit 435" in Figure 9. Here, the "Automatic Account Withdrawal History Information Storage Unit 435" is configured to also store the total number of withdrawals performed per day for each electronic currency business operator for each terminal device 10, etc. This withdrawal execution count is calculated based on the number of withdrawals executed by bank server 30.

[0104] Furthermore, this withdrawal execution count is configured to prioritize storing the maximum number of withdrawals per day in the past. If the number of withdrawals exceeds the previously stored maximum number of withdrawals, the previous maximum number is updated.

[0105] The generation unit 436 then determines the "withdrawal restriction threshold count" and the "withdrawal suspension threshold count," calculated by multiplying the maximum number of withdrawals executed in a single day in the past, as recorded in the "automatic account withdrawal history information storage unit 435," by a certain ratio, and stores these in the "withdrawal restriction and other criteria information storage unit 437" in Figure 9.

[0106] In this case, if the maximum number of withdrawals executed in a single day in the past is less than the arbitrarily set minimum number of withdrawals, the "withdrawal limit threshold number" etc. will be determined and stored based on this minimum number of withdrawals, rather than the maximum number in the past. Therefore, for example, even when the number of past automatic account withdrawals (such as auto-charges) is small, such as immediately after the start of automatic account withdrawals, it is possible to prevent situations where automatic account withdrawals are denied.

[0107] Next, the process proceeds to ST55. In ST55, the "Automatic Account Withdrawal Monitoring Unit (Program) 442" in Figure 10 operates to determine whether the provisional total number of withdrawals in the "Provisional Total Withdrawal Execution Count Storage Unit 434" in Figure 9 has reached the "Withdrawal Restriction Criteria Count" or "Withdrawal Suspension Criteria Count" in the "Withdrawal Restriction Criteria Information Storage Unit 437" in Figure 9. If the provisional total number of withdrawals has reached the "Withdrawal Restriction Criteria Count" but not the "Withdrawal Suspension Criteria Count," a "Warning Information" is generated and sent to the operator of the management server 40. The "Warning Information" is also stored in the "Monitoring Result Information Storage Unit 441" in Figure 10, and the process proceeds to the "Withdrawal Restriction Information Related Process" described later.

[0108] Furthermore, if the provisional total number of withdrawal attempts reaches the "withdrawal suspension threshold," "suspension information" is generated and sent to the administrator of the management server 40. The "suspension information" is also stored in the "monitoring result information storage unit 441" in Figure 10, and the process proceeds to the "withdrawal suspension information related process" described later. Furthermore, if the provisional total number of withdrawal attempts has not reached the "withdrawal limit threshold," the process will proceed to the "normal procedure" described later.

[0109] In this embodiment, when an automatic account withdrawal (e.g., auto-charge) is executed, the system categorizes the automatic account withdrawal into "normal," "warning (withdrawal restricted)," or "stopped (withdrawal suspended)" based on past automatic account withdrawal execution history information (e.g., the number of withdrawals executed per day for each business operator), and performs different processing accordingly. This configuration prevents inappropriate automatic account withdrawals.

[0110] . The following provides a detailed explanation of each of the following processes: "Normal Process," "Withdrawal Restriction Information Process," and "Withdrawal Suspension Information Process."

[0111] (Normal process) Figures 22 and 23 are schematic flowcharts showing the main steps of the "normal process". The "normal process" in this embodiment will be described below in accordance with the same schematic flowchart. First, in the ST70 shown in Figure 22, the management server 40 refers to the "monitoring result information storage unit 441" in Figure 10. If no "warning information" or "stop information" is stored in the storage unit 441, it determines that the system is "normal," generates a "transmission message for automatic bank account withdrawal," and stores it in the "transmission message for automatic bank account withdrawal storage unit 443" in Figure 10.

[0112] Specifically, as shown in Figure 10, the contents of the "Message to be sent for automatic account withdrawal to a bank" are as follows: The following information should be added: "Bank name (e.g., ABC Bank)", "Branch name (e.g., Osaki Branch)", "Account type (e.g., Savings)", "Account number (e.g., 1234567)", "Automatic withdrawal amount (e.g., 10,000 yen)", and "MS information (e.g., Abcdefg)". For automatic withdrawals, the "Charge method type" in the MS information should be set to "Automatic withdrawal (1)" and the "PIN check type" should be set to "No check required (1)".

[0113] Next, the process proceeds to ST71. In ST71, the management server 40 sends a "Message for Automatic Account Withdrawal to Bank" to the bank server 30. In ST72, the bank server 30 operates the "Withdrawal Decision Processing Unit (Program) 311" shown in Figure 13, which determines whether the "Automatic Account Withdrawal Amount" is eligible for withdrawal. If it is eligible, it processes the withdrawal (10,000 yen) (accounting system processing). Then, proceeding to ST73, the bank server 30 generates a "Withdrawal Bank Message" and stores it in the "Withdrawal Bank Message Storage Unit 312" shown in Figure 13.

[0114] In this case, since the bank server 30 does not verify the "PIN," the management server 40 does not need to send the "PIN" information to the bank server 30. Therefore, since users of terminal device 10 are not required to enter a "PIN," the system is easy to use. Furthermore, instead of requiring users to enter a PIN, the system is designed to prevent improper automatic withdrawals based on criteria such as the "maximum total number of withdrawals per day."

[0115] Next, the process proceeds to ST74. In ST74, the bank server 30 sends the "Message to Send to Bank After Withdrawal" from the "Message Storage Unit 312 for Messages to Send to Bank After Withdrawal" shown in Figure 13 to the management server 40. Next, in ST75, the management server 40 stores the received "Message to Send to Withdrawn Bank" in the "Management-Side Message to Send to Withdrawn Bank Storage Unit 444" in Figure 10.

[0116] Next, the process proceeds to ST76. In ST76, the "Message Conversion Processing Unit (Program) 445 for Sending Messages to Businesses" in Figure 10 of the management server 40 operates, converting the "Message for Sending Messages to Banks with Disbursement by the Management Side" in the "Message Storage Unit 444 for Sending Messages to Banks with Disbursement by the Management Side" in Figure 10 to a "Message for Sending Messages to Businesses with Disbursement by the Management Side," and storing it in the "Message Storage Unit 446 for Sending Messages to Businesses with Disbursement by the Management Side" in Figure 10. In this way, the management server 40 generates and sends "messages to be sent to bank servers" and "messages to be sent to carrier servers," so carriers and banks can continue to use their existing systems without making any changes, and this system 1 can be used at a low cost.

[0117] Next, the process proceeds to ST77. In ST77, the management server 40 stores the "Transaction Result Automatic Withdrawal (for example, 10,000 yen)" from the "Message Storage Unit 446 for Sending Messages to Businesses That Have Already Disbursed by the Management Side" in Figure 10, in the "Management Side User Information Storage Unit 402" in Figure 6.

[0118] Figure 32 is a schematic diagram illustrating "Administrative User Information (Part 7)" with "Transaction Result (Automatic Account Withdrawal)" added. As shown in Figure 32, the management server 40 is configured to manage user information excluding the password.

[0119] Next, the process proceeds to ST78. In ST78, the touch panel 11 of the terminal device 10 displays that 10,000 yen has been automatically deposited as electronic currency via automatic account withdrawal. Next, in ST79, when approval input is entered on terminal device 10, a transaction completion signal is sent from terminal device 10 to management server 40.

[0120] Next, the process proceeds to ST80. In ST80, the management server 40 sends a "Message to be sent to the business operator after withdrawal by the management side" to the business operator server 20, and the "Business Operator User Information" in the "Business Operator User Information Storage Unit 203" in Figure 3 is stored with the "Transaction Result (Automatic Account Withdrawal Transaction)" information added.

[0121] However, if the transmission of "transaction results (automatic account withdrawal transactions)" information, etc., from the management server 40 to the business server 20 is not completed successfully within a specified time, the business server 20 is configured to be able to obtain the transaction results (automatic account withdrawal) information, etc., from the management server 40. This concludes the process for executing automatic account withdrawals when the transaction is deemed "normal."

[0122] (Process related to withdrawal restriction information) In the "Withdrawal Restriction Information Related Process," the management server 40 refers to the "Monitoring Result Information Storage Unit 441" in Figure 10. If "Warning Information" is stored in the storage unit 441, the management server 40 notifies the management server 40 operator of this fact via email. The other processes are the same as in the "When Determined to be Normal" case described above.

[0123] However, if the management server 40 operator who received the "warning information" email also has "stop information" arbitrarily set and stored, the system will not send the "automatic account withdrawal message to the bank" to the bank server 30, but will instead send information to the "business server 20" and the "terminal device 10" indicating that automatic account withdrawal (auto-charge, etc.) is not possible. Therefore, improper automated account withdrawals will not be executed, and their execution will be prevented.

[0124] (Regarding the "Process related to information on suspension of withdrawals") In the "Withdrawal Suspension Information Related Process," the management server 40 refers to the "Monitoring Result Information Storage Unit 441" in Figure 10. If "suspension information" is stored in the storage unit 441, it does not send a "Transmission Message for Automatic Account Withdrawal to Bank" to the bank server 30, but instead sends information to the "Business Operator Server 20" and the "Terminal Device 10" indicating that automatic account withdrawal is not possible. Therefore, improper automated account withdrawals will not be executed, and their execution will be prevented.

[0125] Thus, in this embodiment, when an automatic account withdrawal (e.g., auto-charge) is executed, the execution of the automatic account withdrawal is permitted based on past automatic account withdrawal execution history information (e.g., the number of withdrawals executed per day for each business operator), thereby preventing inappropriate automatic account withdrawals.

[0126] In the embodiments described above, the case where the invention is implemented as a device was given as an example, but the present invention is not limited thereto, and may be stored and distributed as a program that can be executed by a computer on a storage medium such as a magnetic disk (floppy disk, hard disk, etc.), optical disk (CD-ROM, DVD, etc.), magneto-optical disk (MO), or semiconductor memory.

[0127] Furthermore, the storage medium only needs to be capable of storing programs and be readable by a computer. The storage format of the storage medium is not particularly limited.

[0128] Furthermore, an operating system (OS) running on a computer, or middleware (MW) such as database management software or network software, may execute some of the processes necessary to realize this embodiment based on instructions from a program installed on the computer from a storage medium.

[0129] Furthermore, the storage medium in this invention is not limited to a medium independent of the computer, but also includes a storage medium that stores or temporarily stores programs that have been downloaded via a LAN, the Internet, or the like.

[0130] Furthermore, the computer in this invention only needs to execute each process in this embodiment based on a program stored in a storage medium, and may be a device consisting of a single personal computer or the like, or a system in which multiple devices are connected via a network.

[0131] Furthermore, the term "computer" in this invention is not limited to personal computers, but also includes arithmetic processing units, microcontrollers, and the like included in information processing equipment, and refers collectively to any equipment or device capable of realizing the functions of this invention through a program.

[0132] Embodiments of the present invention have been described above. However, the present invention is not limited to the above embodiments, and various modifications can be made without departing from the scope of the claims. The configurations of the above embodiments can be partially omitted or combined in any way different from those described above. [Explanation of Symbols]

[0133] 1...Electronic currency information management system, 2...Internet network, 3...Base station, 10...Terminal device, 20...Operator server, 30...Bank server, 40...Management server, 200...First information storage unit on the operator server side, 210...Second information storage unit on the operator server side, 300...First information storage unit on the bank server side, 310...Second information storage unit on the bank server side, 400...First information storage unit on the management server side, 410...Second information storage unit on the management server side, 420...Third information storage unit on the management server side, 430...Fourth information storage unit on the management server side, 440...Fifth information storage unit on the management server side

Claims

1. An electronic currency information management system comprising a user's terminal device, a business operator's management device which is a business operator's management device that communicates with the terminal device, a financial institution's management device which is a financial institution's management device, and a financial information management device which manages financial information, The aforementioned electronic currency information management system, upon reaching predetermined conditions, will automatically perform an automatic account withdrawal, without requiring the user to enter their financial institution's PIN, and will increase the electronic currency balance information of the user's terminal device, managed by the business management device, by withdrawing a predetermined amount from the user's deposit account at the aforementioned financial institution. The financial information management device generates withdrawal limit threshold information and withdrawal suspension threshold information based on the past daily maximum number of automatic account withdrawals for each business operator for the terminal device. If the provisional total withdrawal execution information, which is the current daily number of automatic account withdrawals performed by the terminal device, reaches the withdrawal limit threshold information but does not reach the withdrawal suspension threshold information, the financial information management device generates warning information and executes the withdrawal limit information related process. When the provisional total withdrawal execution information reaches the withdrawal suspension threshold information, the financial information management device generates suspension information and executes the withdrawal suspension information related process. On the other hand, if the provisional total withdrawal execution information does not reach the withdrawal limit threshold information, the financial information management device will execute the normal process. An electronic currency information management system characterized in that, when the information on the maximum number of withdrawals per day in the past is less than the information on the minimum number of withdrawals set in advance, the financial information management device generates the information on the limit number of withdrawals and the information on the limit number of withdrawals based on this minimum number of withdrawals.

2. The electronic currency information management system according to Claim 1, characterized in that it stores registration-related information received from the user's terminal device as administrator-side user information, and when the administrator-side user information matches the registration-related information which is information received from the business management device, it generates financial institution-bound transmission information that can be received by the financial institution based on the administrator-side user information, and generates business-bound transmission information that can be received by the business management device based on the information received from the financial institution.

3. A control method for an electronic currency information management system having a user terminal device, a business operator management device which is a business operator management device that communicates with the terminal device, a financial institution side management device which is a financial institution management device, and a financial information management device which manages financial information, The aforementioned electronic currency information management system, upon reaching predetermined conditions, will automatically perform an automatic account withdrawal, without requiring the user to enter their financial institution's PIN, and will increase the electronic currency balance information of the user's terminal device, managed by the business management device, by withdrawing a predetermined amount from the user's deposit account at the aforementioned financial institution. The financial information management device generates withdrawal limit threshold information and withdrawal suspension threshold information based on the past daily maximum number of automatic account withdrawals for each business operator for the terminal device. If the provisional total withdrawal execution information, which is the current daily number of automatic account withdrawals performed by the terminal device, reaches the withdrawal limit threshold information but does not reach the withdrawal suspension threshold information, the financial information management device generates warning information and executes the withdrawal limit information related process. When the provisional total withdrawal execution information reaches the withdrawal suspension threshold information, the financial information management device generates suspension information and executes the withdrawal suspension information related process. On the other hand, if the provisional total withdrawal execution information does not reach the withdrawal limit threshold information, the financial information management device will execute the normal process. A control method for an electronic currency information management system, characterized in that, when the information on the maximum number of executions in a single day in the past is less than the information on the minimum number of withdrawals to be performed in advance, the financial information management device generates the information on the limit number of withdrawals and the information on the limit number of withdrawals to be performed based on this minimum number of withdrawals to be performed.

4. An electronic currency information management system having a user terminal device, a business operator management device which is a management device of a business operator that communicates with the terminal device, a financial institution management device which is a management device of a financial institution, and a financial information management device which manages financial information, The aforementioned electronic currency information management system has a function that, when predetermined conditions are met, automatically performs an automatic account withdrawal, which increases the electronic currency balance information of the user's terminal device managed by the business management device by a predetermined amount from the user's deposit account at the aforementioned financial institution, without requiring the user to enter their financial institution's PIN information. The financial information management device has a function to generate withdrawal limit threshold information and withdrawal suspension threshold information based on the past daily maximum number of automatic account withdrawals for each business operator for the terminal device. When the provisional total withdrawal execution information, which is the current daily number of automatic account withdrawals performed by the terminal device, reaches the withdrawal limit threshold information but does not reach the withdrawal suspension threshold information, the financial information management device generates warning information and performs the withdrawal limit information related process. When the provisional total withdrawal execution information reaches the withdrawal suspension threshold information, the financial information management device generates suspension information and performs the withdrawal suspension information related process. On the other hand, if the provisional total withdrawal execution information does not reach the withdrawal limit threshold information, the financial information management device will execute the normal process. A control program for an electronic currency information management system, characterized in that, when the information on the maximum number of withdrawals per day in the past is less than the information on the minimum number of withdrawals per day set in advance, the financial information management device is configured to execute a function that generates the information on the minimum number of withdrawals per day and the information on the minimum number of withdrawals per day based on this information on the minimum number of withdrawals per day.

Images