JP6663531B1 - Electronic money charging method and electronic money support system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to immediately transfer money from a user's savings account to an electronic money business operator by using an open API provided by a financial institution. SOLUTION: In an electronic money support system 10, an API platform 40 transfers money on the condition that a transfer execution API (settlement execution) 42, which is an open API and is issued based on a user's intention, is received. The first step of executing the execution API (settlement execution) 42, and the second amount in which the API base 40 deducts the same amount as the charge amount determined by the user from the savings account (user savings account 53) by the accounting system 52. And the third step in which the API base 40 transfers the same amount as the charge amount to the transfer destination account (electronic money business deposit / savings account 54) by the accounting system 52, and after the simultaneous withdrawal and transfer, the API is executed. The fourth step is that the base 40 sends the “success code” to the electronic money server 30. [Selection diagram] FIG.

Description

  The present invention relates to a method for charging electronic money and an electronic money support system, and can use an open API provided by a financial institution to immediately transfer money from a user's savings account to an electronic money company. It was made.

Conventionally, when using a debit card, there is a time when the accounting host stops, and a “payment processing system, a payment processing method, and a payment processing program” related thereto are known (see Patent Document 1).
Specifically, first, before the bank account system of the bank is stopped, the necessary amount determined for the electronic money function is charged, payment is made by electronic money, and thereafter, the remaining balance is returned to the account. Second, when the accounting system is stopped, a fixed amount of credit is defined and paid, and the payment of the credit amount is paid after the accounting system is restarted.

Japanese Patent No. 6493722

However, the conventional system described above relates to a temporary response to the time when the banking host of the bank is stopped, and does not correspond to a continuous charge to electronic money.
As a mechanism for continuous charge to electronic money, it is also possible to use fund transfer at banks. For example, it is also possible for a user to collect a charge amount and deposit it into an electronic money trader's account using a bank account system. However, there is a problem that the payment to the electronic money trader's account is made on the next business day, the funding of the electronic money trader is delayed, and the payment to the member store tends to be delayed.
Therefore, the inventions described in the respective claims have been made in view of the above-mentioned problems of the conventional technology, and the objects thereof are as follows.

( Claims 1 to 4 )
The invention according to claims 1 to 4 relates to an “electronic money charging method” and has the following objects.
In other words, each of the inventions according to claims 1 to 4 uses an open API for charging electronic money and immediately transfers money from the user's savings account to the electronic money business, thereby enabling the electronic money business. This will allow for quicker funding and faster payment to member stores.

( Claims 5 to 8 )
The invention according to claims 5 to 8 relates to an “electronic money support system” and has the same object as the inventions according to claims 1 to 4 described above.

Each invention described in each claim has been made to achieve the above objects .

(Claim 1)
The invention according to claim 1 relates to “electronic money charging method” and is characterized by the following points.
That is, the invention according to claim 1 is, first, capable of communicating with the electronic money server that manages the electronic money owned by the user, and being open to the electronic money server. An API platform that manages the open API, and a deposit / withdrawal account connected to the API platform that is owned by the user, and a transfer account that is owned by a management entity that manages the electronic money server. It is assumed that a banking system that can execute the transfer.

  Secondly, a first step in which the API base executes the transfer execution API issued from the electronic money server based on the user's intention, on condition that the transfer execution API is the open API. A second step in which the API base debits the same amount as the charge determined by the user from the deposit / saving account by the API base system by the accounting system; The system includes a third step of transferring to the transferee account by the system, and a fourth step of transmitting the “successful code” to the electronic money server after the simultaneous execution of the debit and the transfer.

Third, the API base transmits the “success code” to the electronic money server, and upon receipt of the transmitted “success code” by the electronic money server, The server requests that the charge amount be added to the money balance of the electronic money owned by the user.
Fourth, an access token issued from the electronic money server and permitted to be used only once, prohibited from being reused, and has an expiration date is provided on condition that a transfer instruction API which is the open API is received. The seventh step issued by the API base to the electronic money server and the receipt of the transfer execution API from the electronic money server trigger the received transfer execution API using the access token. An eighth step of accessing the accounting system by transmitting the accounting system to the accounting system from the API base.

(Claim 2)
A second aspect of the present invention relates to an "electronic money charging method" and has the following features in addition to the features of the first aspect of the present invention.
According to the second aspect of the present invention, the transfer execution API is executed on condition that the transfer execution API is received, so that the determined amount determined in advance by the user or the money balance owned by the user is determined. A fifth step in which the API base is debited from the deposit / saving account by the accounting system by the accounting system, and at the same time, the determined amount or the shortage is transferred to the transfer destination account by the API infrastructure by the accounting system. And a sixth step of transferring.

( Claim 3 )
The invention according to claim 3 relates to the “electronic money charging method” and is characterized by the following points.
That is, the invention according to claim 3 is, first, capable of communicating with the electronic money server that manages the electronic money owned by the user, and being open to the electronic money server. An API platform that manages the open API, and a deposit / withdrawal account connected to the API platform that is owned by the user, and a transfer account that is owned by a management entity that manages the electronic money server. It is assumed that a banking system that can execute the transfer.

Second, a first step in which the electronic money server issues the transfer instruction API and the transfer execution API , which are the open APIs, based on the user's intention, and the issued transfer instruction API and the transfer execution API A second step in which the electronic money server transmits the API transfer to the API platform, and the API platform executes the transfer execution API received by the account system to store the charge amount determined by the user in the deposit account. After the transfer from the account and the transfer of the charge amount to the transfer destination account at the same time, the simultaneous execution of the transfer and the transfer, the `` success code '' transmitted by the API platform, provided that the electronic money server receives the The electronic money server adds the charge amount to the money balance of the electronic money owned by the user. And a third step that, the.
Third, an access token issued from the electronic money server and permitted to be used only once, prohibited from being reused, and has an expiration date is provided on condition that the transfer instruction API which is the open API is received. The seventh step issued by the API base to the electronic money server and the receipt of the transfer execution API from the electronic money server trigger the received transfer execution API using the access token. An eighth step of accessing the accounting system by transmitting the accounting system to the accounting system from the API base.

( Claim 4 )
A fourth aspect of the present invention relates to an "electronic money charging method" and has the following features in addition to the above-described features of the third aspect of the present invention.
That is, the invention described in claim 4, the first, the when the user received by the electronic money server utilization estimated amount of electronic money which is scheduled from the sales store electronic terminal, the usage amount planned is the A fourth step in which the electronic money server determines whether or not the money balance owned by the user has been reached; and if the result of the determination is that the money balance is insufficient, the open API is used. A fifth step in which the electronic money server issues the transfer instruction API and the transfer execution API, and a sixth step in which the electronic money server transmits the issued transfer instruction API and the transfer execution API to the API base. And a step.

  Secondly, the electronic money server transmits the transfer instruction API and the transfer execution API to the API base, so that the transfer of the transfer instruction API and the transfer execution API is received by the API base. In the API platform, the determined amount determined by the user in advance, or the shortage amount for the money balance owned by the user, the API platform with the accounting system, the withdrawal from the savings account by the accounting system, A request is made to transfer the determined amount or the insufficient amount to the transfer destination account.

( Claim 5 )
The invention according to claim 5 relates to the “electronic money support system” and is characterized by the following points.
That is, the invention according to claim 5 is, first, capable of communicating with the electronic money server that manages the electronic money owned by the user and being open to the electronic money server. An API platform that manages the open API, and a deposit / withdrawal account connected to the API platform that is owned by the user, and a transfer account that is owned by a management entity that manages the electronic money server. It is assumed that a banking system that can execute the transfer.

Secondly, the API base executes the transfer execution API issued from the electronic money server based on the user's intention, on condition that the transfer execution API which is the open API is received, and executes the transfer execution API. The same amount as the charge determined by the person is withdrawn from the savings account by the accounting system, and at the same time, the same amount as the charge is transferred to the transfer destination account by the accounting system, and the simultaneous execution of withdrawal and transfer After that, by transmitting a “success code” to the electronic money server and transmitting the “success code” to the electronic money server, the transmitted “success code” is received by the electronic money server. In the electronic money server, the charge amount is added to the money balance of the electronic money owned by the user. It has requested so as to.
Third, the API base is issued from the electronic money server, and is permitted to be used only once, is prohibited from being reused, and has an expiration date, provided that the transfer instruction API, which is the open API, is received. Is issued to the electronic money server, and upon receipt of the transfer execution API from the electronic money server, the transfer execution API is transmitted from the API base to the accounting system using the access token. By transmitting to the system, the accounting system is accessed.

( Claim 6 )
The invention according to claim 6 relates to an "electronic money support system" and has the following features in addition to the features of the invention described in claim 5 described above.
That is, the invention according to claim 6 is characterized in that the API base executes the received transfer execution API on condition that the transfer execution API is received, so that the user can determine a predetermined amount or the usage amount. A shortfall in the money balance owned by the person is withdrawn from the savings account by the accounting system, and at the same time, the determined amount or the shortfall is transferred to the transfer destination account.

( Claim 7 )
The invention according to claim 7 relates to an “electronic money support system” and is characterized by the following points.
That is, the invention according to claim 7 is, first, capable of communicating with the electronic money server that manages the electronic money owned by the user and being open to the electronic money server. An API platform that manages the open API, and a deposit / withdrawal account connected to the API platform that is owned by the user, and a transfer account that is owned by a management entity that manages the electronic money server. It is assumed that a banking system that can execute the transfer.

Second, the electronic money server issues a transfer instruction API and a transfer execution API , which are the open APIs, based on the user's intention, and transmits the issued transfer instruction API and the transfer execution API to the API base. The API platform transmits the received transfer execution API to the account system, and the account system debits the same amount as the charge determined by the user from the savings account, and at the same time, the same amount as the charge After the transfer to the transfer account, the withdrawal, and the transfer at the same time, the charge amount is added to the money balance of the electronic money owned by the user on condition that the “success code” transmitted by the API platform is received. I do.
Third, the API base is issued from the electronic money server, and is permitted to be used only once, is prohibited from being reused, and has an expiration date, provided that the transfer instruction API, which is the open API, is received. Is issued to the electronic money server, and upon receipt of the transfer execution API from the electronic money server, the transfer execution API is transmitted from the API base to the accounting system using the access token. By transmitting to the system, the accounting system is accessed.

( Claim 8 )
The invention according to claim 8 relates to an "electronic money support system" and has the following features in addition to the features of the invention described in claim 7 described above.
That is, in the invention according to claim 8 , first, when the electronic money server receives a planned use amount of electronic money scheduled by the user from an electronic terminal of a store, the planned use amount becomes wherein determining whether the reached the user the money balance owned by the result of the determination, if the money balance is insufficient, and issues the transfer order API and the transfer execution API is the open API And transmitting the issued transfer instruction API and the transfer execution API to the API base.

  Secondly, the electronic money server transmits the transfer instruction API and the transfer execution API to the API base, so that the transfer of the transfer instruction API and the transfer execution API is received by the API base. In the API platform, the determined amount determined by the user in advance, or the shortage amount for the money balance owned by the user, the API platform with the accounting system, the withdrawal from the savings account by the accounting system, A request is made to transfer the determined amount or the insufficient amount to the transfer destination account.

The present invention is configured as described above, and has the following effects.
( Claims 1 to 4 )
The invention according to claims 1 to 4 relates to the “electronic money charging method” and has the following effects.
In other words, according to the first to fourth aspects of the present invention, the electronic money business is performed by immediately transferring the electronic money charge from the user's savings account to the electronic money company using the open API. This will speed up the funding of the sellers and speed up the payment to franchisees.

( Claims 5 to 8 )
The inventions according to claims 5 to 8 relate to the “electronic money support system” and have the same effects as the inventions according to claims 1 to 4 described above.

It is an explanatory view for explaining an outline of an electronic money support system. It is an explanatory view for explaining the details of an electronic money support system. It is a flowchart for explaining the charge processing of electronic money. It is a flowchart for demonstrating the automatic charge process of electronic money. It is a flowchart of an example of registration of the account number for charge. FIG. 4 is an explanatory diagram for describing an example of a screen of a communication terminal. FIG. 8 is an explanatory diagram for describing an example of a screen of a communication terminal of a user regarding a charging process. It is an explanatory view for explaining an example of an account statement of a user. It is an explanatory view for explaining an example of an account statement of an electronic money company. FIG. 9 is an explanatory diagram of a part of a list for explaining a list of response codes to API requests; It is an explanatory view for explaining an example of use of an IC card. It is an explanatory view for explaining the example of use of a smart phone. It is an explanatory view for explaining an example of use of a prepaid card or a smart phone. It is a flowchart for demonstrating the auto charge process using an IC card.

(Electronic money support system 10)
In FIG. 1, reference numeral 10 denotes an electronic money support system.
As shown in FIG. 1, the electronic money support system 10 is based on the following configuration, “thing” (hereinafter, referred to as “precondition”).
(1) Electronic money server 30
The electronic money server 30 manages electronic money owned by the user. The electronic money server 30 is managed by an electronic money company.
Here, “electronic money” refers to an electronic record balance that has been exchanged equivalently to money or the like paid by the user.

(2) API platform 40
The API base 40 can communicate with the electronic money server 30 and manages an open API opened to the electronic money server 30. The electronic money server 30 is managed by a financial institution such as a bank, but is not limited to a bank.
Here, the “open API” refers to an interface that provides a function of a financial institution to an external company.
Here, “communication” uses, for example, the Internet.

(3) Accounting system 52
The accounting system 52 is connected to the API base 40, and is owned by a management entity that manages the deposit / withdrawal to / from a savings account (a user savings account 53, see FIG. 2) owned by the user and the electronic money server 30. It is possible to execute a transfer to a transfer destination account (an electronic money company savings account 54, see FIG. 2).
Here, the “connection” is, for example, connected using a dedicated line, but is not limited to the dedicated line.

(Features of the present invention)
The features of the present invention reside in the following two points.
(1) Electronic money charge processing (2) Electronic money auto charge processing

(Electronic money charging process)
The "(1) charge processing of electronic money" enables a user to use his / her deposit / saving account (user saving / saving account 53) to charge electronic money owned by the user.

The electronic money support system 10 uses the open API of a financial institution such as a bank based on the intention of the user, and stores the same amount as the charge determined by the user in the savings account (user savings account 53, see FIG. 2). ), And at the same time, the same amount as the charge amount is transferred to the transfer account of the electronic money company (the electronic money company savings account 54, see FIG. 2).
After the simultaneous execution of the debit and the transfer, the API base 40 of the electronic money support system 10 transmits a “success code” to the electronic money server 30 of the electronic money provider, and the electronic money server 30 receiving the “success code” , The charge amount is added to the money balance of the electronic money owned by the user.

Here, “based on the intention of the user” includes the following cases in the case of the “charging process”.
(1) When a “charge request” is triggered by the user's communication terminal 21 (2) When a “charge request” is transmitted via the electronic terminal 60 of the store (see FIG. 1)

Further, in the case of the “auto charge process” described later, a determination result indicating that the money balance is insufficient in the electronic terminal 60 of the store or the electronic money server 30 of the electronic money provider is triggered.
In the case of "auto charge", the user specifies the charge request in the consent form or terms of use, etc., a fixed amount or a shortage is specified, and it is recognized as "the charge amount determined by the user" You.

Thereby, the electronic money owned by the user can be charged. That is, when the user's money balance is "2,000 yen" and the user requests charging of "3,000 yen", the electronic money support system 10 is activated, and the electronic money server 30 of the electronic money provider In response to receiving the “success code” from the financial institution's API platform 40, the charge amount “3,000 yen” is added to the electronic money money balance “2,000 yen” of the electronic money owned by the user, and the money balance becomes “5,000”. Circle ".
The electronic money support system 10 simultaneously executes withdrawal and transfer, and transmits a “successful code” to the electronic money server 30 of the electronic money business, thereby speeding up the funding of the electronic money business and increasing the number of affiliated stores. Payments can be made earlier.

(Automatic charge processing of electronic money)
The above-mentioned "(2) Auto-charge processing of electronic money" is a development of "(1) Electronic-charge processing of electronic money", and can automatically charge a shortage of the money balance owned by the user. Things.
The electronic money support system 10 operates upon receiving a scheduled use amount of electronic money scheduled by the user from the electronic terminal 60 of the store.

  The electronic money server 30 of the electronic money provider determines whether or not the estimated usage amount has reached the money balance owned by the user, and if the result of the determination indicates that the money balance is insufficient, The API base 40 uses the open API of a financial institution such as a bank to determine the amount determined by the user in advance or the shortage amount of the money balance owned by the user, and the It is required to withdraw from the user deposit / saving account 53) and, at the same time, to transfer the determined amount or the shortage amount to the transfer destination account (electronic money business operator saving / saving account 54).

  Thus, the electronic money owned by the user can be automatically charged. That is, when the money balance owned by the user is “2,000 yen” and the planned usage amount of the user is “3,000 yen”, the money balance is insufficient. At this time, if the amount determined by the user in advance is “5,000 yen”, the electronic money server 30 uses the open API of the financial institution such as the bank and sends the “API” to the API base 40 of the financial institution such as the bank. 5,000 yen "withdrawal and transfer at the same time.

  Note that the accounting system 52 of a financial institution such as a bank checks the account balance of the user's savings account (user savings account 53) and, for example, in the case of "20,000 yen", deducts "5,000 yen". , The account balance is “15,000 yen”.

Thereafter, the electronic money server 30, upon receiving the "success code" from the API base 40, adds the determined amount "5,000 yen" transferred to the user's money balance "2,000 yen", and Becomes "7,000 yen".
The electronic terminal 60 at the store confirms that the user's money balance "7,000 yen" exceeds the planned usage amount "3,000 yen", pays the planned usage amount "3,000 yen", and the money balance "4,000 yen". ".

The electronic money support system 10 simultaneously executes withdrawal and transfer, and transmits a “successful code” to the electronic money server 30 of the electronic money business, thereby speeding up the funding of the electronic money business and increasing the number of affiliated stores. Payments can be made earlier.
In addition, as the debit and transfer amount, a predetermined method is selected from the charge amount predetermined by the user or the shortage amount for the money balance owned by the user, so that the user can calculate the charge amount. It is not necessary to make a request, and the burden on the user can be reduced.

(First feature point)
Hereinafter, features of the present invention will be described.
The first feature relates to the “electronic money charging method” and includes the above “preconditions”, and includes the following steps as a first configuration.

(First configuration)
(1) First Step The first step is based on the intention of the user, and the API base 40 is issued on the condition that a transfer execution API (settlement execution) 42 which is issued from the electronic money server 30 and is an open API is received. Is a step for executing the transfer execution API (payment execution) 42.
The first step corresponds to steps S10, S20, S21, S31, S32, S22, S23, and S33 in the order of FIG. 3 described later.

(2) Second Step The second step is a step in which the API base 40 debits the same amount as the charge determined by the user from the savings account (user savings account 53) by the accounting system 52.
The second step corresponds to step S34 in FIG. 3 described later.

(3) Third Step The third step is a step in which the API base 40 simultaneously transfers the same amount as the charge amount to the transfer destination account (the electronic money business operator's savings account 54) using the accounting system 52.
The third step corresponds to step S35 in FIG. 3 described later.

(4) Fourth Step The fourth step is a step in which the API base 40 transmits a “successful code” to the electronic money server 30 after the simultaneous execution of the withdrawal and the transfer.
The fourth step corresponds to step S36 in FIG. 3 described later.

(Second configuration)
As a second configuration, the API base 40 transmits the “success code” to the electronic money server 30, and the electronic money server 30 receives the transmitted “success code” from the electronic money server 30. 30. The method according to 30, wherein a request is made to add a charge amount to the money balance of the electronic money owned by the user.
In the second configuration, steps S24 and S11 correspond to the order of FIG. 3 described later.

(Second feature point)
The second feature relates to the “electronic money charging method”. In addition to the first feature (first to fourth steps) and the second feature of the above-described first feature, a third feature is provided. It includes the following steps.

(Third configuration)
(1) Fifth Step A fifth step is to execute the transfer execution API (payment execution) 42 on condition that the transfer execution API (payment execution) 42 is received, thereby determining the amount determined by the user in advance. Alternatively, this is a step in which the API base 40 debits the shortage amount of the money balance owned by the user from the savings account (user savings account 53) by the accounting system 52.
The fifth step corresponds to steps S63 and S64 in the order of FIG. 4 described later.

(2) Sixth Step The sixth step is a step in which the API base 40 simultaneously transfers the determined amount or the shortage amount to the transfer destination account (the electronic money business savings account 54) by the accounting system 52.
The sixth step corresponds to step S65 in FIG. 4 described later.

(Third feature point)
A third feature relates to the “electronic money charging method”. In addition to the first configuration (first to fourth steps) and the second configuration of the first feature described above, a fourth configuration is provided. It includes the following steps.

(Fourth configuration)
(1) Seventh Step The seventh step is executed only once on the condition that a transfer instruction API (settlement application) 41 issued from the electronic money server 30 and is an open API is received based on the user's intention. This is a step in which the API base 40 issues an access token with an expiration date to the electronic money server 30 in which the use is permitted and the reuse is prohibited.
The seventh step corresponds to steps S10, S20, S21, S31, and S32 in FIG. 3 described later.

(2) Eighth Step In the eighth step, upon receiving the transfer execution API (payment execution) 42 from the electronic money server 30, the received transfer execution API (payment execution) 42 is used by using an access token. This is a step of accessing the accounting system 52 by transmitting the data from the API base 40 to the accounting system 52.
The seventh step corresponds to steps S22, S23, S33, and S34 in FIG. 3 described later.

(Fourth feature)
A fourth feature relates to the “electronic money charging method” and includes the above “preconditions”, and the fifth configuration includes the following steps.

(Fifth configuration)
(1) First Step In the first step, the electronic money server 30 issues a transfer instruction API (payment application) 41 and a transfer execution API (payment execution) 42, which are open APIs, based on the user's intention. Step.
The first step corresponds to steps S10, S20, S21, and S23 in the order of FIG. 3 described later.

(2) Second Step The second step is a step in which the electronic money server 30 transmits the issued transfer instruction API (payment application) 41 and the transfer execution API (payment execution) 42 to the API base 40.
The second step corresponds to steps S21, S22, and S23 in the order of FIG. 3 described later.

(3) Third Step In the third step, the API base 40 executes the received transfer execution API (payment execution) 42 to cause the accounting system 52 to transfer the charge determined by the user to the deposit account. After the withdrawal from the bank account 53) and the transfer of the charge amount to the account to which the charge is to be transferred (the electronic money operator bank account 54), the withdrawal and the transfer are simultaneously executed, the "success code" transmitted by the API This is a step in which the electronic money server 30 adds the charge amount to the money balance of the electronic money owned by the user on condition that the money server 30 receives the money.
The third step corresponds to steps S33, S34, S35, S36, and S24 in the order of FIG. 3 described later.

(Fifth feature point)
The fifth feature relates to the “electronic money charging method” and includes the following steps as a sixth structure in addition to the fifth structure (first to third steps) of the fifth feature described above. .

(Sixth configuration)
(1) Fourth Step In the fourth step, when the electronic money server 30 receives the planned use amount of the electronic money from the electronic terminal 60 of the dealer, the planned use amount is owned by the user. This is a step in which the electronic money server 30 determines whether or not the remaining money balance has been reached.
As for the fourth step, steps S40 and S50 correspond to the order of FIG. 4 described later.

(2) Fifth Step In the fifth step, if the result of the determination is that the money balance is insufficient, the transfer instruction API (payment application) 41 and the transfer execution API (payment execution) 42, which are open APIs, are executed. This is a step issued by the electronic money server 30.
The fifth step corresponds to steps S51, 52, and S63 in the order of FIG. 4 described later.

(3) Sixth Step The sixth step is a step in which the electronic money server 30 transmits the issued transfer instruction API (payment application) 41 and the transfer execution API (payment execution) 42 to the API base 40.
As for the sixth step, steps S51 and S53 correspond to the order of FIG. 4 described later.

(Seventh configuration)
As a seventh configuration, the electronic money server 30 transmits the transfer instruction API (payment application) 41 and the transfer execution API (payment execution) 42 to the API base 40, thereby transmitting the transfer instruction API (payment application) 41 and When the API base 40 receives the transfer execution API (payment execution) 42, the API base 40 determines the amount determined by the user in advance or the shortage amount for the money balance owned by the user in the API base 40. Is required by the accounting system 52 to debit the savings account (user savings account 53) and at the same time transfer the determined amount or the shortage to the transfer destination account (electronic money business savings account 54). And
In the seventh configuration, steps S61, S62, S63, S64, and S65 correspond to the order of FIG. 4 described later.

(Description of FIG. 1)
As shown in FIG. 1, the electronic money support system 10 is premised on the following configuration, “thing”.
Note that the following (1) to (3) have already been described, and thus description thereof will be omitted. In addition, the electronic money support system 10 is not limited to the following (1) to (6). If the user only charges the electronic money, (5) the ordinary savings account 22 and (6) the store Electronic terminal 60 may be omitted.
(1) Electronic money server 30
(2) API platform 40
(3) Accounting system 52

(4) Electronic money card 20
For example, a “barcode” is displayed on the electronic money card 20 and is owned by the user.
Although a “barcode” or the like is illustrated, the present invention is not limited to this, and a “two-dimensional code” other than the “barcode” may be displayed, or “RFID” may be embedded.

(5) Communication terminal 21
The communication terminal 21 is composed of, for example, a “smart phone” and is owned by the user. The user uses the smartphone to access the electronic money server 30 of the electronic money provider via the Internet, and transmits, for example, a charge request for electronic money.
The communication terminal 21 is exemplified by a “smart phone”, but is not limited thereto, and may be a mobile communication terminal such as a mobile phone, a PHS, a PDA, a notebook PC, a tablet, or a portable information terminal.

(6) Passbook for financial institutions 22
The financial institution passbook 22 is owned by the user and used for transactions with the financial institution. A cash card may be used in addition to the bankbook 22 for a financial institution. Further, the financial institution passbook 22 may be paper or a “digital passbook”.

(7) Electronic terminal 60
The electronic terminal 60 is composed of, for example, a “POS cash register” and is installed at a store or the like. The “POS cash register” reads the barcode of the electronic money card 20 of the user, and confirms the identity of the user. The electronic terminal 60 uses the read barcode to access the electronic money server 30 of the electronic money provider via a dedicated line, and confirms and exchanges electronic money information. “Cashier” is an abbreviation for “register”.
Although the “POS cash register” is exemplified as the electronic terminal 60, the electronic terminal 60 is not limited to this and may be a terminal. Further, although the “dedicated line” has been illustrated, the present invention is not limited to this, and the Internet may be used or used together.

(Relationship between the electronic money card 20 and the communication terminal 21)
There are the following types of combinations of the electronic money card 20 and the communication terminal 21.
(1) When using the electronic money card 20 and the communication terminal 21 in combination (2) When using the communication terminal 21 alone (3) When using the electronic money card 20 alone

(Combination of electronic money card 20 and communication terminal 21)
The combination of the electronic money card 20 and the communication terminal 21 is such that the electronic money card 20 is “positive” and the communication terminal 21 is “sub”.
As shown in FIG. 1, the electronic money card 20 is brought to the store, and after the shopping is completed, the electronic money card 20 is attached to the reader of the electronic terminal 60 of, for example, a “POS cash register” installed in the store. And use it to identify the user by reading a "barcode" or the like.

The communication terminal 21 such as a smartphone is used for electronic money charge requests.
The communication terminal 21 has installed therein a program (hereinafter, referred to as “first smartphone application”) provided by an electronic money provider. As shown in FIG. 7, the first smartphone application includes a communication function with an electronic money server and a display function of a display.

(When using the communication terminal 21 alone)
When the communication terminal 21 is used alone, there are the following specification modes.
(1) First Specification Mode of Communication Terminal 21 The first specification mode of the communication terminal 21 is a case where a barcode or a “two-dimensional code” other than the “barcode” is displayed on the display of the smartphone.

The barcode or the like on the display is used for reading the “barcode” and confirming the identity of the user by holding the barcode over the reader of the electronic terminal 60 installed in the store, like the electronic money card 20.
In the communication terminal 21, in addition to the first smartphone application, a program for displaying a barcode or the like on a display (hereinafter, referred to as a "second smartphone application") is installed.

(2) Second Specification Mode of Communication Terminal 21 The second specification mode of the communication terminal 21 has the function of the electronic money server 30 of the electronic money provider.
The communication terminal 21 has installed therein a program (hereinafter, referred to as a “third smartphone application”) that manages the electronic money of the user in addition to the communication function with the API base 40 during the financial period.

(When using the electronic money card 20 alone)
When the electronic money card 20 is used alone, the electronic money card 20 can be read by holding the electronic money card 20 over the reader of the electronic terminal 60 at the store as shown in FIG. In addition to being used to confirm the identity of the user, it also has a charging function through the touch panel and keyboard of the electronic terminal 60.

(Description of FIG. 2)
FIG. 2 illustrates details of the electronic money support system 10 shown in FIG.
The electronic money support system 10 includes the following configuration.
(1) Electronic terminal 60
The electronic terminal 60 is installed at a store or the like and includes the following configuration.

(1-1) Electronic Money Operation Function System 61
The electronic money operation function system 61 mainly controls a money balance inquiry and a charge screen.
(1-2) Electronic money settlement function system 62
The electronic money settlement function system 62 mainly controls a reduction in the amount of payment and an increase in charge. The electronic money settlement function system 62 is connected to the electronic money operation function system 61.

(2) Electronic money server 30
The electronic money server 30 is managed by an electronic money company.
The electronic money server 30 includes the following configuration.
(2-1) Electronic money support function system 31
The electronic money support function system 31 mainly constitutes a mechanism for transmitting a transfer instruction API, a transfer execution, and an API.

(2-2) Electronic money management function system 32
The electronic money management function system 32 mainly manages member management, balance management, usage statement management, settlement, and the like. The electronic money management function system 32 increases or decreases the money balance in response to the completion instruction of the electronic money support function system 31 after executing the API.
The electronic money management function system 32 is connected to the electronic money settlement function system 62 and is also connected to the electronic money support function system 31.

(2-3) Others Although not shown, the electronic money server 30 includes an electronic money balance management DB, and member information, money balance, and the like are stored in the electronic money balance management DB.
(3) API platform 40
The API base 40 is managed by a financial institution such as a bank.
The API board 40 includes the following configuration.
(3-1) Settlement application API (transfer instruction) 41
The payment application API (transfer instruction) 41 is connected to an electronic money payment function system 62.

(3-2) Settlement execution API (transfer execution) 42
The payment execution API (transfer execution) 42 is connected to the electronic money payment function system 62.
In addition, the API base 40 has programs for the transfer instruction API 41 and the transfer execution API 42, which receives an API request from the electronic money support function system and cooperates with the financial institution system 50 at the next stage.

(4) Financial institution system 50
The financial institution system 50 is managed by a financial institution such as a bank. The management entity of the financial institution system 50 and the management entity of the API infrastructure 40 may be the same or different. For example, the API infrastructure 40 is managed by the first administration entity, and the financial institution system 50 is managed. May be managed by a second management entity.

The financial institution system 50 includes the following configuration.
(4-1) Internal API 51
The internal API 51 is connected to a settlement execution API (transfer execution) 42.
(4-2) Account system 52
The accounting system 52 is connected to the internal API 51.

The accounting system 52 includes the following configuration.
(4-2-1) User savings account 53
(4-2-2) Electronic Money Business Savings Account 54
The electronic money business savings account 54 can be transferred from the user savings account 53.
In addition, the financial institution system 50 includes an internal API 51 that receives the transfer execution API 42, and an accounting system 52 that instructs (1) withdrawal from the user deposit / saving account 53 and (2) withdrawal amount according to an instruction from the internal API 51. The process of transferring money to the electronic money company deposit / saving account 54 is sequentially executed.

(Description of FIG. 3)
FIG. 3 is a flowchart for explaining the electronic money charging process.
It is divided into three columns, and the left column on the left side in FIG. 3 explains the operation of the communication terminal 21 of the user. The central column at the center describes the operation of the electronic money server 30 of the electronic money company, and the right column at the right describes the operation of the API base 40 and the accounting system 52 (50) of the financial institution.

First, the process proceeds to step S10 in the left column, and an “electronic money charge request (3,000 yen)” is executed. Step S10 is executed by the user using the communication terminal 21, and is transmitted to the electronic money server 30 of the electronic money provider.
After the end of step S10, the process proceeds to step S20 in the center row. In step S20, "confirmation of money balance of electronic money (2,000 yen remaining)" is executed. Step S20 is executed by the electronic money server 30 and is started upon a “charge request” to confirm the user's money balance and to confirm whether the sum of the charge amount and the balance does not reach the upper limit of the electronic money. Is done. Electronic money has an upper limit.

After the step S20 ends, the process proceeds to the lower step S21. In step S21, "creation and transmission of transfer instruction API based on charge amount" is executed. Step S21 is executed by the electronic money server 30, and the created transfer instruction API is transmitted to the API base 40.
After the end of step S21, the process proceeds to step S31 in the right column.

  If there is no balance in the electronic money in step S21, the content of the balance shortage is returned. The error code is "400" as illustrated in FIG. 10, and the transfer instruction API replies with a balance shortage error. Here, it is assumed that the balance of the electronic money is “10,000 yen”.

In step S31, "reception of transfer instruction API" is executed. Step S31 is executed by the API base 40.
After the step S31 ends, the process proceeds to the lower step S32. In step S32, a "reply of transfer instruction API (grant / transmission of update token)" is executed.
Here, the “update token” refers to a payment application acceptance token, which will be described later.
The payment application acceptance token is issued each time a transfer instruction API is issued, and is a one-time-limited token.

Step S32 is executed by the accounting system 52 (50), and a reply of the transfer instruction API and an update token are transmitted to the electronic money server 30.
After the end of step S32, the process proceeds to step S22 in the center row. In step S22, "reception of transfer instruction API (reception of update-related token)" is executed, and the payment processing reception number issued together with the payment application reception token in the transfer instruction API is received. Step S22 is executed by the electronic money server 30.

After the step S22 ends, the process proceeds to the lower step S23. In step S23, “the transfer execution API is created / transmitted (access using the update token) is executed. Step S23 is executed by the electronic money server 30 and uses the update token and the settlement processing reception number. The API base 40 is accessed, and the transfer execution API is transmitted.
After the end of step S23, the process proceeds to step S33 in the right column. In step S33, “receiving / executing the transfer execution API” is executed. Step S33 is executed by the API base 40.

Step S33 proceeds to the lower step S34. In step S34, "withdrawal of the charge amount (3,000 yen) from the user's savings account by the accounting system (account balance: 7,000 yen)" is executed. Step S34 is executed by the accounting system 52 (50) based on the "transfer execution API" transmitted from the API base 40.
After the step S34 ends, the process proceeds to the lower step S35. In step S35, "transfer of the charge amount (3,000 yen) to the transfer destination account of the electronic money company by the accounting system" is executed. Step S35 is executed by the accounting system 52 (50).

After the step S35 ends, the process proceeds to the lower step S36. In step S36, "reply of transfer execution API (processing result: success)" is executed. Step S36 is executed by the API base 40 based on the report from the accounting system 52 (50), and transmits a “success code” to the electronic money server 30.
After the end of step S36, the process proceeds to step S24 in the center row. In step S24, "reception of a successful code, addition of charge amount (5,000 yen remaining), transmission of charge completion notification" is executed. Step S24 is executed in the electronic money server 30, and transmits a "charge completion notification" to the communication terminal 21 of the user.

  After the end of step S24, the process proceeds to step S11 in the left column. In step S11, "completion of charge completion notification (balance display: 5,000 yen)" is executed. Step S11 is executed in the communication terminal 21, and when the user confirms the "balance display: 5,000 yen" displayed on the display of the communication terminal 21, the "electronic money charge request (3,000 yen)" is executed. You can confirm that it was done.

(Description of FIG. 4)
FIG. 4 is a flowchart for explaining the electronic money auto-charging process.
It is divided into three columns, and the left column on the left side in FIG. 4 explains the operation of the electronic terminal 61 of the store. The central column at the center describes the operation of the electronic money server 30 of the electronic money company, and the right column at the right describes the operation of the API base 40 and the accounting system 52 (50) of the financial institution.

First, the process proceeds to step S40 in the left column, and “electronic money payment operation (3,000 yen)” is executed. Step S40 is executed by using the electronic terminal 61 of the store, and the estimated usage amount of the user is transmitted to the electronic money server 30 of the electronic money company.
After the end of step S40, the process proceeds to step S50 in the center row. In step S50, it is determined whether "the money balance is sufficient". Step S50 is executed by the electronic money server 30.

Here, two cases are assumed.
Case 1 is a case where the money balance is “5,000 yen”, which exceeds the planned use amount (3,000 yen), so that the determination result of step S50 is “Yes” (YES).
Case 2 is a case where the money balance is “2,000 yen”, which is less than the planned use amount (3,000 yen) and is insufficient, so that the determination result in step S50 is “NO” (NO).

Case 1: If "yes" (YES), the process proceeds from step S50 to step S54 at the bottom of the center row.
In step S54, "payment processing (payment amount: 3,000 yen)" is executed. Step S54 is executed by the electronic money server 30, and transmits "payment completed" to the electronic terminal 61.
After the step S54 ends, the process advances to the step S41 in the left column. In step S41, "payment completed" is notified to the user. Step S41 is executed by the electronic terminal 61.
Since the money balance has been reduced from "5,000 yen" to "2,000 yen", the user can confirm that the payment has been executed from the money balance.

Next, the case of Case 2, that is, the case where the money balance is insufficient will be described.
Case 2: If "No" (NO), the process proceeds from step S50 to step S51 immediately below.
In step S51, "creation and transmission of transfer instruction API with added money amount" is executed. Step S51 is executed by the electronic money server 30, and the created transfer instruction API is transmitted to the API base 40.
Here, the "additional money amount" is selected from a charge amount determined in advance by the user or a shortage amount for the money balance owned by the user, and a predetermined method is selected. Is exemplified.

After the end of step S51, the process proceeds to step S61 in the right column.
If there is no electronic money balance in step S61, the content of the balance shortage is replied. The error code is "400" as illustrated in FIG. 10, and the transfer instruction API replies with a balance shortage error. Here, it is assumed that the balance of the electronic money is “20,000 yen”.

In S61, "Reception of transfer instruction API" is executed. Step S61 is executed by the API base 40.
After the step S61 ends, the process proceeds to the lower step S62. In step S62, "reply of transfer instruction API (grant / transmission of update token)" is executed.
Here, the “update token” refers to a payment application acceptance token, which will be described later.
The payment application acceptance token is issued each time a transfer instruction API is issued, and is a one-time-limited token.

Step S62 is executed by the accounting system 52 (50), and a reply of the transfer instruction API and an update token are transmitted to the electronic money server 30.
After the end of step S62, the process proceeds to step S52 in the center row. In step S52, "Reception of transfer instruction API (reception of update-related token)" is executed, and the payment processing reception number issued together with the payment application reception token in the transfer instruction API is received. Step S52 is executed by the electronic money server 30.

After the step S52 ends, the process proceeds to the lower step S53. In step S53, “creation and transmission of a transfer execution API (access using an update token) is executed. Step S53 is executed by the electronic money server 30, and uses the update token and the settlement processing reception number. The API base 40 is accessed, and the transfer execution API is transmitted.
After the end of step S53, the process proceeds to step S63 in the right column. In step S63, “receiving / executing the transfer execution API” is executed. Step S63 is executed by the API base 40.

After the step S63 ends, the process proceeds to the lower step S64. In step 634, “withdrawal (account balance: 15,000 yen) of the additional amount of money (5,000 yen) from the user's savings account by the accounting system” is executed. Step S64 is executed by the accounting system 52 (50) based on the "transfer execution API" transmitted from the API base 40.
After the step S64 ends, the process proceeds to the lower step S65. In step S65, "transfer the additional money (5,000 yen) to the transfer destination account of the electronic money company by the accounting system" is executed. Step S65 is executed by the accounting system 52 (50).

After the step S65 ends, the process proceeds to the lower step S66. In step S66, "reply of transfer execution API (processing result: success)" is executed. Step S66 is executed by the API base 40 based on the report from the accounting system 52 (50), and transmits a “success code” to the electronic money server 30.
After the end of step S66, the process proceeds to step S55 in the center row. In step S55, “receiving a successful code, adding money addition amount (5,000 yen) (7,000 yen remaining)” is executed. Step S55 is executed in the electronic money server 30.

After the step S55 ends, the process proceeds to the upper step S54 described above. In step S54, "payment processing (payment amount: 3,000 yen)" is executed, and thereafter, the process proceeds to step S41 in the left column.
In step S41, "payment completed" is notified to the user.
The user can confirm that the money balance has become insufficient and the additional amount of money (5,000 yen) has been automatically charged because the money balance has been increased from "2,000 yen" to "4,000 yen".

(Description of FIG. 5)
FIG. 5 is a flowchart of registering a charging account number in charging electronic money.
Referring to FIG. 5, by using a communication terminal 21 owned by the user to register a charging account number in advance, the user can charge electronic money simply by inputting a charge amount.
By using the transfer instruction API to register the transfer source account (user account) in advance, the user can transfer money without specifying his own account or the transfer destination account.
It is divided into three columns, and the left column on the left side in FIG. 5 explains the operation of the communication terminal 21 of the user. The central column at the center describes the operation of the electronic money server 30 of the electronic money company, and the right column at the right describes the operation of the API base 40 of the financial institution.

First, the process proceeds to step S100 in the left column, and a “connection request with an account number” is executed (see screen 70 in FIG. 6). In step S100, using the “smartphone application” installed in communication terminal 21, a request is made to a financial institution for an account connection.
After the end of step S100, the process proceeds to step S110 in the center row. In step S110, an “API login request” is executed. Step S110 is executed by the electronic money server 30 of the electronic money provider. The electronic money server 30 executes a login request to the API base 40 of the financial institution.

  After the end of step S110, the process proceeds to step S120 in the right column. In step S120, “API login screen, redirect” is executed. The API base 40 of the financial institution returns (redirects) an “API login screen” to the user's communication terminal 21 in response to the login request using the “open API”.

  After the end of step S120, the process proceeds to step S101 in the left column. In step S101, “login screen display (ID, PASSWORD) is executed.“ Open API ”is used for“ login screen display, ”and a“ login screen ”is displayed on the display of the communication terminal 21 ( (See screen 71 in FIG. 6). The user inputs an ID, a password, and the like on the “login screen”.

After the end of step S101, the process proceeds to step S122 in the right column. In step S122, “API authorization screen, redirect” is executed. The API base 40 of the financial institution performs an authentication process, and returns (redirects) an “API authorization screen” to the user's communication terminal 21 using the “open API”.
After the end of step S122, the process proceeds to step S102 in the left column. In step S102, “API authorization screen display (authorization permission response)” is executed. “Open API” is used for “API authorization screen display”, and an “API authorization screen” is displayed on the display of the communication terminal 21 (see screen 72 in FIG. 6).

  After the end of step S102, the process proceeds to step S123 in the right column. In step S123, “API authorization processing (authorization success)” is executed. The information which approved the service (here, electronic money charge) is transferred to the API base 40 of the financial institution, and the “authorization code” of the electronic money charge is transmitted to the smartphone application using “open API”.

  After the end of step S123, the process proceeds to step S103 in the left column. In step S103, "authorization code reception" is executed. Step S103 is executed using the “smartphone application” of the communication terminal 21. Thereafter, the “smartphone application” of the communication terminal 21 uses the “authorization code” to acquire reference information such as account information, balance / deposit / withdrawal details, etc. from the API base 40 via the electronic money server 30.

After the end of step S103 in the left column, the process proceeds to step S111 in the center column. In step S111, a “reference access token request” is executed. Step S111 is executed by the electronic money server 30 of the electronic money provider.
After the step S111 ends, the process proceeds to the step S124 in the right column. In step S124, “API authorization server, access token issuance” is executed. Step S124 is executed by the API base 40 of the financial institution using the “open API”.

  After the end of step S124, the process proceeds to step S112 in the center row. In step S112, "account number inquiry API required by access token" is executed. Step S112 is executed by the electronic money server 30 of the electronic money company, executes the account number inquiry API using the reference token, and acquires the target account information used for the electronic money charge from the accounting system 52 (50). I do.

After the end of step S112, the process proceeds to step S125 in the right column. In step S125, "account number inquiry API reception / reply" is executed. Step S125 is executed by the API base 40 of the financial institution using “open API”.
After the end of step S125, the process proceeds to step S113 in the center row. In step S113, “display a list of account numbers for the application” is executed. Step S113 is executed by the electronic money server 30 of the electronic money business operator, provides list data of the target account to the smartphone application, and stores the account number in the electronic money management function system 32 when the user selects it. .

After the end of step S113, the process proceeds to step S104 in the left column. In step S104, "select an account number for settlement" is executed. Step S104 is executed by the “smartphone application” of the communication terminal 21 of the user.
After the end of step S104, the process proceeds to step S114 in the center row. In step S114, “registration of account number database for payment” is executed. Step S114 is executed by the electronic money server 30 of the electronic money provider.

(Description of FIG. 6)
FIG. 6 is an explanatory diagram for describing an example of the screen of the communication terminal 21.
Screens 70 to 74 relate to the registration process of the account number for settlement shown in FIG.
Screen 70 corresponds to step S100 in FIG.
Screen 71 corresponds to steps S120 and S101 in FIG.
The screen 72 corresponds to step S122 and step S102 in FIG.
Screen 73 corresponds to step S113 in FIG.
Screen 74 corresponds to step S114 in FIG. 5 and is a “completion screen”.

(Description of FIG. 7)
FIG. 7 is an explanatory diagram for explaining another example of the screen of the communication terminal 21.
The screens 80 and 81 relate to the charging process shown in FIG.
Screen 80 corresponds to step S10 in FIG.
Screen 81 corresponds to step S11 in FIG. 3 and assumes that the balance of electronic money is “5,000 yen”.

(Description of FIG. 8)
FIG. 8 shows an example of the account details of the user.
At the bottom, “Payout: 3,000” yen, “Payment (passbook summary): Electronic money charge”, and “Balance: 7,000” yen are displayed.
"3,000" yen for the withdrawal of "electronic money charge" is subtracted from the "balance: 10,000" yen in the upper row.

(Description of FIG. 9)
FIG. 9 shows an example of an account detail of an electronic money company.
At the bottom, “Payment (Passbook Summary): Charge Deposit”, “Payment: 3,000” yen, and “Balance: 1,051,500” yen are displayed.
The "Balance: 1,048,5000" yen on the upper row is added with the "3,000" yen for the deposit of "Electronic Money Charge".

(Description of FIG. 10)
FIG. 10 is a part of a list for explaining a list of response codes to API requests.
The following three examples of the “HTTP status code” will be described.
(1) Code "201" (normal processing)
The code “201” is output at the time of “(normal processing)”, and the “answer items” are as follows.
"Payment processing reception number, payment processing reception date, payment processing reception time, etc."
Remarks are as follows.
"Request transfer execution API by payment process receipt number"

(2) Code "400" (error)
The code “400” is output at the time of “(error)”, and the “answer items” are as follows.
`` Error information (insufficient balance, suspended account, etc.) ''
Remarks are as follows.
"Pause electronic money"

(3) Code "503" (error)
The code “503” is also output at the time of “(error)”, and the “answer items” are as follows.
"Error Information (Out of Banking System Hours)"
The remarks are the same as "(2) Code" 400 "(Error)", and a description thereof will be omitted.

(Description of FIG. 11)
FIG. 11 illustrates an example of use of the IC card 23.
The IC card 23 is owned by a user and is an example of the electronic money card 20 shown in FIG. 1. An IC chip is embedded therein, and the IC chip functions as the electronic money unit 21.

The electronic money section 21 mainly has electronic money balance management, and stores personal information for user identification and electronic money information here.
The IC card 23 is brought to a store, for example, and the stored electronic information is read by the electronic money communication device 63 installed in the store. The electronic money communication device 63 also serves as an electronic money reading device, and communicates with the IC card 23 via an internal sensor.
After that, the electronic money communication device 63 communicates with the electronic money management system 32 of the electronic money server 30 of the electronic money company, and executes the operation of the electronic money including the charging process.

(Description of FIG. 12)
FIG. 12 is for explaining a usage example of the smartphone 25.
FIG. 12 shows a case where a smartphone 25 is used instead of the IC card 23 of FIG.
The smartphone 25 is an example of the communication terminal 21 shown in FIG. 1 owned by the user. An electronic money application 26 is installed in the smartphone 25. The electronic money application 26 is an example of a smartphone application, and stores personal information for confirming the identity of the user in addition to the communication function.

  The smartphone 25 communicates with the electronic money server 30 of the electronic money company via the Internet, and executes the operation of the electronic money including the charging process. The electronic money server 30 has an electronic money section 21, and as described above, the electronic money section 21 mainly has a balance management of electronic money.

(Description of FIG. 13)
FIG. 13 illustrates an example of use of the prepaid card 27 or the smartphone 25.
FIG. 13 shows a case in which a prepaid card 27 or a smartphone 25 is used instead of the IC card 23 in FIG.
The prepaid card 27 is owned by the user and is an example of the electronic money card 20 shown in FIG. 1, and a “bar code” is displayed on the surface of the card. Although the “barcode” has been exemplified, the present invention is not limited to this, and a “two-dimensional code” other than the “barcode” may be displayed.

  The prepaid card 27 is brought to a store or the like, for example, and is read by an electronic money reading device 64 such as a barcode reader installed in the store. The read information is transmitted to the POS cash register 65 to which the electronic money reading device 64 is connected. The POS cash register 65 communicates with the electronic money server 30 of the electronic money business operator by a communication function, and stores the electronic money including the charging process. Perform operations.

The electronic money server 30 has an electronic money section 21, and as described above, the electronic money section 21 mainly has a balance management of electronic money.
On the other hand, when using the smartphone 25, the display function of the smartphone application installed on the smartphone 25 is used to display a “barcode” on the screen. Although the “barcode” has been illustrated, the present invention is not limited to this, and a “two-dimensional code” other than the “barcode” may be displayed.
The “barcode” displayed on the screen is read and used by an electronic money reading device 64 installed at a store or the like, like the prepaid card 27.

(Description of FIG. 14)
FIG. 14 is a flowchart for explaining the auto charge process using the IC card 23.
FIG. 14 is partially common to FIG. 4 described above, so that common components are denoted by the same reference numerals and description thereof is omitted.

First, the process proceeds to step S40 in the left column, and the user performs “electronic money payment operation (3,000 yen)” using the IC card 23.
After the step S40 ends, the process proceeds to the lower step S70. In step S70, the IC card 23 determines whether "the money balance is sufficient".

As shown in FIG. 11, the IC card 23 has an electronic money section 21 and has a balance management of electronic money. For this reason, the POS cash register 65 (see FIG. 13) installed at the store or the like can compare the electronic money balance stored in the IC card 23 with the planned use amount.
As a result, when the balance of the electronic money is sufficient, the process proceeds to “Yes” (YES), and proceeds from the step S70 to the lower step S71. In step S71, “payment processing (payment amount: 3,000 yen)” is executed using the IC card 23.

After the end of step S71, the process proceeds to the lower step S41, where the user is notified that "payment completed" has been completed, for example, by using the POS register 65.
On the other hand, if the money balance is insufficient, that is, if the money balance is insufficient, the process proceeds from step S70 to step S51 in the center row, and thereafter, the auto charge process described with reference to FIG. 4 is executed.

10 Electronic money support system
20 Electronic Money Card
21 Communication terminal
22 Passbook
23 IC card
24 Electronic Money Department
25 Smartphone
26 Electronic Money App (Smartphone App)
27 Prepaid Card
30 Electronic Money Server
31 Electronic Money Support Function System
32 Electronic Money Management Function System
40 API platform
41 Transfer Order API (Settlement Application)
42 Transfer execution API (payment execution)
50 Banking system
51 Internal API
52 Core system
53 User Savings Account
54 Electronic money business savings account
60 electronic terminal
61 Electronic Money Operation Function System
62 Electronic Money Settlement Function System
63 Electronic money communication device (electronic money reader)
64 Electronic Money Reader
65 POS cash register
70-74 screen
80-81 screen

Claims (8)

An electronic money server that manages electronic money owned by the user;
An API platform capable of communicating with the electronic money server and managing an open API open to the electronic money server;
An accounting system connected to the API base and capable of executing deposit / withdrawal to / from a savings account owned by the user and transfer to a transfer destination account owned by a management entity that manages the electronic money server; Assuming that
A first step in which the API base executes the transfer execution API, on condition that the transfer execution API is issued from the electronic money server and is the open API, based on the intention of the user;
A second step in which the API base withdraws the same amount as the charge determined by the user from the savings account by the accounting system,
At the same time, a third step in which the API base transfers the same amount as the charge amount to the transfer destination account using the accounting system,
A fourth step in which after the simultaneous execution of the debit and the transfer, the API base sends a “success code” to the electronic money server;
The API platform is:
By transmitting the “success code” to the electronic money server,
In response to the electronic money server receiving the transmitted "success code", the electronic money server requests that the charge amount be added to the money balance of the electronic money owned by the user,
An access token issued from the electronic money server and permitted to be used only once, prohibited from being reused, and with an expiration date is provided on condition that the transfer instruction API, which is the open API, is received. A seventh step of issuing to the electronic money server;
In response to receiving the transfer execution API from the electronic money server, the received transfer execution API is transmitted from the API platform to the accounting system using the access token, thereby providing the accounting system with An eighth step to access;
A method for charging electronic money, comprising: By executing the transfer execution API on condition that the transfer execution API is received, the API base determines the determined amount determined in advance by the user or the shortage amount for the money balance owned by the user by the API base. A fifth step of withdrawing from the savings account by the accounting system;
At the same time, a sixth step in which the API base transfers the determined amount or the shortage amount to the transfer-destination account using the accounting system,
The electronic money charging method according to claim 1, further comprising: An electronic money server that manages electronic money owned by the user;
  An API platform capable of communicating with the electronic money server and managing an open API opened to the electronic money server;
  An accounting system connected to the API base and capable of executing deposit / withdrawal to a savings account held by the user, and transfer to a transfer destination account owned by a management entity managing the electronic money server; Assuming that
  A first step in which the electronic money server issues a transfer instruction API and a transfer execution API, which are the open APIs, based on an intention of the user;
  A second step in which the electronic money server transmits the issued transfer instruction API and the transfer execution API to the API base;
  By executing the received transfer execution API, the API base debits the charge determined by the user from the savings account by the accounting system, and at the same time, transfers the charge to the transfer destination account and debits. After the simultaneous execution of the transfer and the transfer, the "success code" transmitted by the API base is received by the electronic money server, on condition that the electronic money server receives the charge amount in the money balance of the electronic money owned by the user. A third step added by the electronic money server;
An access token issued from the electronic money server and permitted to be used only once, prohibited from being reused, and with an expiration date is provided on condition that the transfer instruction API which is the open API is received. A seventh step of issuing to the electronic money server;
  In response to receiving the transfer execution API from the electronic money server, the received transfer execution API is transmitted from the API platform to the accounting system using the access token, thereby providing the accounting system with An eighth step to access;
A method for charging electronic money, comprising: When the electronic money server receives the planned use amount of the electronic money from the electronic terminal of the store, the electronic money server determines whether the planned use amount has reached the money balance owned by the user. A fourth step determined by the electronic money server;
  If the result of the determination is that the money balance is insufficient, a fifth step in which the electronic money server issues the transfer instruction API and the transfer execution API, which are the open APIs,
  A sixth step in which the electronic money server transmits the issued transfer instruction API and the transfer execution API to the API base,
  The electronic money server,
  By transmitting the transfer instruction API and the transfer execution API to the API base,
  In response to the API base receiving the transmitted transfer instruction API and the transfer execution API, the API base has a shortage of the determined amount predetermined by the user or the money balance owned by the user. 4. The method according to claim 3, wherein the API base requests that the API base be debited from the deposit / saving account by the accounting system, and at the same time, the determined amount or the shortage amount be transferred to the transfer destination account. Electronic money charging method described. An electronic money server that manages electronic money owned by the user;
  An API platform capable of communicating with the electronic money server and managing an open API opened to the electronic money server;
  An accounting system connected to the API base and capable of executing deposit / withdrawal to a savings account held by the user, and transfer to a transfer destination account owned by a management entity managing the electronic money server; Assuming that
  The API platform is:
  Based on the user's intention, the transfer execution API is issued on condition that the transfer execution API is issued from the electronic money server and is the open API, and the same amount as the charge determined by the user is determined. Debit from the savings account by the accounting system, and at the same time, the same amount as the charge amount is transferred to the transfer destination account by the accounting system,
  After the simultaneous execution of the debit and the transfer, a "success code" is sent to the electronic money server,
  By transmitting the “success code” to the electronic money server,
  Triggered by the electronic money server receiving the transmitted “success code”, the electronic money server requests that the charge amount be added to the money balance of the electronic money owned by the user,
  The API platform is:
  An access token issued from the electronic money server and permitted to be used only once, prohibited from being reused, and with an expiration date is provided to the electronic money server on condition that the transfer instruction API which is the open API is received. Issued for
  Upon receiving the transfer execution API from the electronic money server, the transfer execution API is transmitted from the API base to the account system using the access token to access the account system. An electronic money support system characterized in that: The API platform is:
  By executing the received transfer execution API on condition that the transfer execution API is received, the amount determined by the user in advance or the shortage amount for the money balance owned by the user can be calculated by the accounting system. The electronic money support system according to claim 5, wherein the determined amount or the insufficient amount is transferred to the transfer destination account at the same time by debiting from the savings account. An electronic money server for managing electronic money owned by the user;
  An API platform capable of communicating with the electronic money server and managing an open API opened to the electronic money server;
  An accounting system connected to the API base and capable of executing deposit / withdrawal to a savings account held by the user, and transfer to a transfer destination account owned by a management entity managing the electronic money server; Assuming that
  The electronic money server,
  Issue a transfer instruction API and a transfer execution API, which are the open APIs, based on the user's intention;
  The issued transfer instruction API and the transfer execution API are transmitted to the API base,
  The API base, by executing the received transfer execution API, withdraws the same amount as the charge determined by the user from the savings account by the accounting system, and simultaneously transfers the same amount as the charge to the transfer destination account. After the simultaneous execution of the transfer, withdrawal and transfer, the charge amount is added to the money balance of the electronic money owned by the user, on condition that the “success code” transmitted by the API base is received,
  The API platform is:
  An access token issued from the electronic money server and permitted to be used only once, prohibited from being reused, and with an expiration date is provided to the electronic money server on condition that the transfer instruction API which is the open API is received. Issued for
  Upon receiving the transfer execution API from the electronic money server, the transfer execution API is transmitted from the API base to the account system using the access token to access the account system. An electronic money support system characterized in that: The electronic money server,
  When the estimated use amount of the electronic money scheduled by the user is received from the electronic terminal of the store, it is determined whether the estimated use amount has reached the money balance owned by the user,
  If the result of the determination is that the money balance is insufficient, the transfer instruction API and the transfer execution API that are the open APIs are issued,
  The issued transfer instruction API and the transfer execution API are transmitted to the API base,
  The electronic money server,
  By transmitting the transfer instruction API and the transfer execution API to the API base, the user receives the transfer instruction API and the transfer execution API and receives the transfer instruction API and the transfer execution API. The API base debits the determined amount or the shortfall amount for the money balance owned by the user from the deposit / saving account by the accounting system by the accounting system, and at the same time transfers the determined amount or the shortage amount. 8. The electronic money support system according to claim 7, wherein a request is made to make a transfer to a destination account.

Images