JP7212101B2 - Account payment system and account payment method - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act January 25, 2021, https://www. rakuten-bank. co. jp/, https://www. rakuten-bank. co. jp/press/2021/210125. html, https://www. rakuten-bank. co. jp/gs/pay/ January 25, 2021, https://corp. rakuten. co. jp/, https://corp. rakuten. co. jp/news/update/2021/0125_02. html? scid=wi_rpt_top_jp_042019, https://pay. rakuten. co. jp/, https://pay. rakuten. co. jp/guide/bank_payment/? l-id=guide_rakuten_bank January 25, 2021, https://apps. apple. com/, https://apps. apple. com/jp/app/%E6%A5%BD%E5%A4%A9%E3%83%9A%E3%82%A4-%E3%81%8B%E3%82%93%E3%81%9F% E3%82%93-%E3%81%8A%E5%BE%97%E3%81%AA%E3%82%B9%E3%83%9E%E3%83%9B%E6%B1%BA%E6 %B8%88%E3%82%A2%E3%83%97%E3%83%AA/id 1139755229, https://play. google. com/, https://play. google. com/store/apps/details? id=jp. co. rakuten. pay

The present disclosure relates to an account payment system, an account payment method, an account app, and a payment app.

2. Description of the Related Art Conventionally, techniques for executing electronic settlement using a user's account are known. For example, Patent Literature 1 describes a technique for executing electronic settlement by charging electronic money in a mobile phone from a user's account. Further, for example, Patent Document 2 describes an account payment method in which biometric information is associated with a user's account and the biometric information is input to a terminal that executes electronic payment, whereby the payment amount is directly debited from the user's account. It is

JP 2009-075985 A JP 2019-168959 A

However, with the technique of Patent Document 1, if the balance is insufficient when using electronic money, the user has to carry out a charging operation on the spot, so the user's convenience cannot be sufficiently improved. In the account payment described in Patent Document 2, the payment amount is directly debited from the user's account, so there is no need to quickly recharge the money on the spot. must be secured by

One of the purposes of this disclosure is to increase security in account payments.

The account payment system according to the present disclosure uses an account application for using a predetermined account and a payment application for using electronic payment on the condition that the payment application is installed on the same user terminal. a permitting means for permitting account payment to withdraw the settlement amount from the account; and an executing means for executing the account payment when the account payment is permitted.

The present disclosure provides increased security in account payments.

It is a figure which shows an example of the whole structure of an account payment system. It is a figure which shows an example of the application procedure of account payment. It is a figure which shows an example of the application procedure of account payment. It is a figure which shows an example of the application procedure of account payment. It is a figure which shows an example of the utilization procedure of account payment. It is an example of the functional block diagram which shows the function implement|achieved by an account payment system. It is a figure which shows the data storage example of a bank database. It is a figure which shows the data storage example of a settlement database. It is an example of a flow chart of setting processing. It is an example of a flow chart of setting processing. It is an example of a flow diagram of an execution process. It is an example of a flow diagram of an execution process. It is an example of a flow diagram of an execution process. It is a functional block diagram of a modification.

[1. Overall configuration of account payment system]
An example of an embodiment of an account payment system according to the present disclosure will be described. FIG. 1 is a diagram showing an example of the overall configuration of an account payment system. As shown in FIG. 1, the account payment system S includes a bank server 10, a settlement server 20, a user terminal 30, and a store terminal 40. Each of the bank server 10, the settlement server 20, the user terminal 30, and the store terminal 40 can be connected to a network N such as the Internet. The account payment system S may include at least one computer and is not limited to the example of FIG.

The bank server 10 is a bank server computer. For example, bank server 10 includes control unit 11 , storage unit 12 , and communication unit 13 . Control unit 11 includes at least one processor. The storage unit 12 includes a volatile memory such as RAM and a nonvolatile memory such as a hard disk. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

The settlement server 20 is a server computer of a settlement company that cooperates with a bank. For example, the payment server 20 includes a control section 21 , a storage section 22 and a communication section 23 . Physical configurations of the control unit 21, the storage unit 22, and the communication unit 23 are the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

The user terminal 30 is a user's computer. For example, the user terminal 30 is a smartphone, tablet terminal, wearable terminal, or personal computer. The user terminal 30 includes a control section 31 , a storage section 32 , a communication section 33 , an operation section 34 , a display section 35 and a photographing section 36 . Physical configurations of the control unit 31, the storage unit 32, and the communication unit 33 are the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively. The operation unit 34 is an input device such as a touch panel. The display unit 35 is a liquid crystal display or an organic EL display. The imaging unit 36 includes at least one camera.

The store terminal 40 is a store computer. For example, the store terminal 40 is a POS terminal, smart phone, tablet terminal, or personal computer. The store terminal 40 includes a control section 41 , a storage section 42 , a communication section 43 , an operation section 44 , a display section 45 and a reading section 46 . The physical configurations of the control unit 41, the storage unit 42, the communication unit 43, the operation unit 44, and the display unit 45 are the same as those of the control unit 11, the storage unit 12, the communication unit 13, the operation unit 34, and the display unit 35, respectively. be. The reading unit 46 is a code reader or camera capable of reading codes such as barcodes or two-dimensional codes.

At least one of the programs and data stored in each of the bank server 10, the settlement server 20, the user terminal 30, and the store terminal 40 may be supplied via the network N. In addition, each of the bank server 10, the settlement server 20, the user terminal 30, and the store terminal 40 has a reading unit (for example, an optical disk drive or a memory card slot) that reads a computer-readable information storage medium, and an external device and data and/or an input/output unit (for example, a USB port) for input/output. For example, at least one of the program and data stored in the information storage medium may be supplied via at least one of the reading section and the input/output section.

[2. Overview of account payment system]
In this embodiment, the user has already opened an account with the bank. The user operates the user terminal 30 to use online financial services provided by the bank. The financial services themselves may be various known services, such as confirmation of deposit/withdrawal details, confirmation of balance, transfer, transfer, or remittance. In this embodiment, a case where a user uses a financial service from a bank application installed on the user terminal 30 will be described.

A bank application is an application for using an account. A bank app is an example of an account app. Therefore, the part described as a bank application can be read as an account application. Examples of applications for non-bank accounts will be described in variations below. Users can access their accounts online by logging into the banking app. For example, at the time of initial setting of a bank application, the user inputs a user ID and password notified in advance by the bank. Hereinafter, this user ID and password will be referred to as bank user ID and bank password.

In the present embodiment, an authentication method that can omit the input of the bank user ID corresponding to the account is set at the initial setting of the bank application. Hereinafter, this authentication method will be referred to as quick login authentication. Quick login authentication allows users to log into banking apps by simply entering their bank password. Quick login authentication can also use biometric authentication instead of entering a bank password. In quick login authentication, an authentication ID unique to the user terminal 30 is issued and recorded in each of the bank server 10 and the user terminal 30 . By using the authentication ID, the input of the bank user ID can be omitted. In this embodiment, an authentication ID is issued to only one user terminal 30 in principle. Therefore, quick login authentication is an authentication method with very high security.

The user has already registered as a member of the settlement service. A user operates the user terminal 30 to use a payment service provided by a payment business operator. A payment service is a service that provides electronic payment for a predetermined means of payment. Payment means may be of any type, such as credit cards, debit cards, electronic money, electronic cash, points, virtual currency, or a combination thereof. In this embodiment, a case where a user uses a payment service from a payment application installed on the user terminal 30 will be described.

A payment application is an application for using electronic payment. For example, a user can use electronic payment at a physical store or online by logging into a payment application. For example, the user can log into the payment application by entering his or her own user ID and password. Hereinafter, this user ID and password will be referred to as payment user ID and payment password. The settlement user ID and settlement password may be issued at the time of member registration, or may be used for other services such as e-commerce services.

The user can designate any one of a plurality of payment methods as the payment source payment method. In this embodiment, a case where electronic payment is executed by reading a code displayed on the display unit 35 of the user terminal 30 with the reading unit 46 of the store terminal 40 will be described. Various methods can be used for the execution method of electronic payment itself. A method of reading the code posted on the user terminal 30 with the photographing unit 36 of the user terminal 30 or a method of completing only the operation of the user terminal 30 may be used.

In this embodiment, the user can use a payment application to use account payment, in which the payment amount is withdrawn from the user's account. Direct payment is a service operated and provided by banks, not payment providers. In account payment, the charge amount such as electronic money is not withdrawn from the user's account, but the payment amount is directly withdrawn from the user's account without going through other payment means such as electronic money. Therefore, the user's account is one of the settlement means. The user operates the user terminal 30 to apply for account payment in order to use the account payment.

2 to 4 are diagrams showing an example of the application procedure for account payment. As shown in FIG. 2, in the present embodiment, both the bank application and the payment application are already installed on the user terminal 30, so the bank application icon I10 and the payment application icon I11 are each installed on the home screen of the user terminal 30. It is displayed on the screen G1.

When the user selects the icon I11, the payment application is activated and the home screen G2 of the payment application is displayed. In the example of FIG. 2, a credit card is selected as the payment source. When the code C20 of the home screen G2 is read by the reading unit 46 of the store terminal 40, electronic payment using the credit card designated as the payment source is executed. Code C20 includes an ID issued by settlement server 20 . This ID is different from the payment user ID, and is information that can identify the payment application. This ID is valid only for a certain period of time (eg, 5 minutes). After this period has passed, this ID needs to be updated.

When the user selects the button B21, a setting screen G3 showing a list of payment means that can be set as a payment source is displayed. When the user selects the button B31 after selecting the area A30 corresponding to account payment, a setting screen G4 for setting account payment is displayed. In the input forms F40 to F42, the surname, first name, and date of birth registered in the payment server 20 in advance by the user who is logged in to the payment application are automatically entered. The user may manually enter each of the first name, last name, and date of birth.

When the user selects the button B43, the flow shifts to FIG. 3, and the first authentication page P44 of the bank is displayed on the account payment setting screen G4. The first authentication page P44 is a so-called web view screen. Although it is visually displayed as the screen of the payment application, the portion of the first authentication page P44 is displayed using the browser. The information entered on the first authentication page P44 is transmitted to the bank server 10 and is not transmitted to the payment business operator including the payment server 20. These points are the same for a second authentication page P45 and a third authentication page P46, which will be described later.

As shown in FIG. 3, the user is prompted to enter the bank user ID and bank password corresponding to the user's account. When the user selects the button B442 after entering the bank user ID and bank password in the input forms F440 and F441, authentication based on the bank user ID and bank password is executed. At the time of this authentication, it may be determined whether the name and date of birth entered in the input forms F40 to F42 match the name and date of birth registered in the bank server 10. FIG.

When authentication based on the bank user ID and bank password succeeds, a second authentication page P45 for entering the branch name (branch number) and account number of the account is displayed on the setting screen G4 for identity verification. When the user selects the button B452 after entering the branch name and account number in the input forms F450 and F451, authentication based on the branch name and account number is executed.

If the authentication based on the branch name and account number is successful, a third authentication page P46 for entering the one-time key and account password is displayed on the setting screen G4. When the user selects button B460, a one-time key is sent to the user's email address. The user confirms the one-time key described in the e-mail and enters the one-time key in the input form F461. When the user enters a personal identification number into the input form F462 and selects the button B463, authentication based on the one-time key and personal identification number is executed.

When the authentication based on the one-time key and the personal identification number succeeds, the process shifts to FIG. 4, the third authentication page P46 of the web view is closed, and a dialog D47 prompting authentication from the bank application is displayed on the setting screen G4. When the user selects the button B470, the bank application is activated and an authentication screen G5 for quick login authentication is displayed. Until the authentication screen G5 is displayed, the bank application has not been started and the login to the bank application has not been performed. The authentication on the first authentication page P44 to the third authentication page P46 in FIG. 3 is not login to the bank application, but direct login to the bank server 10 without going through the bank application.

If the bank application is not installed, the installation of the bank application is prompted. If you do not have a bank app installed, you will not be able to proceed to the next step. The bank user ID is not displayed on the authentication screen G5, and the input form for the bank user ID is not displayed either. When the user enters the bank password in the input form F50 and selects the button B51, quick login authentication is executed.

In this embodiment, when the quick login authentication is successful, a token necessary for performing account payment is issued. Tokens are recorded in the payment app's storage area via the bank app. For example, tokens are recorded as part of a payment app. After that, the bank application is closed, the screen returns to the payment source setting screen G3 of the payment application, and a dialog D32 indicating that the payment source has been changed is displayed. When the user selects the button B320, the screen returns to the home screen G2 of the payment application, and a dialog D22 for selecting an authentication method when executing account payment is displayed.

In this embodiment, biometric authentication and personal identification number authentication are prepared as authentication methods when performing account payment. The user can select biometric authentication with button B220. The user can select password authentication with button B221. When the user selects button B220 or button B221, all settings for account payment are completed. Thereafter, the user can display the code on the user terminal 30 and use account payment.

FIG. 5 is a diagram showing an example of a procedure for using account payment. As shown in FIG. 5, when the payment source is changed to account payment, a message M22 prompting display of code C25, which will be described later, is displayed on the home screen G2 of the payment application. Code C25 is not displayed at this point. When the user performs an operation such as tapping to display the code, authentication is performed using the authentication method selected from the dialog D22 in FIG.

When the user selects the personal identification number authentication, a dialog D23 prompting the user to enter the personal identification number is displayed on the home screen G2. When the user enters a personal identification number into the input form F230 and selects the button B231, personal identification number authentication with the bank server 10 is executed. If the personal identification number authentication succeeds, a code C25 for executing account payment is displayed on the home screen G2. The type of information included in the account payment code C25 is the same as the credit card payment code C20.

When the user selects biometrics authentication, a dialog D24 indicating that biometrics authentication is being performed with the bank server 10 is displayed on the home screen G2. In FIG. 5, face authentication is taken as an example, but other biometric authentication methods such as fingerprint authentication can also be used. In biometric authentication, the functions of the user terminal 30 may be used, but final confirmation is performed by the bank server 10 . If the biometric authentication succeeds, a code C25 for executing account payment is displayed on the home screen G2.

When the user causes the home screen G2 to display the code C25, the user presents the code C25 to the store clerk. When the store clerk reads the code C25 with the reading unit 46 of the store terminal 40, the settlement amount is deducted from the user's account by processing mainly performed by the bank server 10.例文帳に追加Each of the user terminal 30 and the shop terminal 40 displays that the account payment has been completed.

As described above, in the payment-to-account system S of the present embodiment, as conditions for executing payment-to-account, both the bank application and the payment application must be installed on the user terminal 30, and each There are various conditions such as successful authentication and successful authentication just prior to account payment. This increases security in account payments. Hereinafter, details of the account payment system S will be described.

[3. Functions realized by the account payment system]
FIG. 6 is an example of a functional block diagram showing functions realized by the account payment system S. As shown in FIG. In the present embodiment, since account payment is a service operated and provided by a bank, a case where the main functions are implemented by the bank server 10 will be described. Note that the shop terminal 40 only has to include a function of reading the code C25 and a function of transmitting information necessary for account payment to the settlement server 20, so the description of FIG. 6 is omitted.

[3-1. Functions Realized in Bank Server]
As shown in FIG. 6 , the bank server 10 implements a data storage unit 100 , a setting unit 101 , a permission unit 102 and an execution unit 103 . The data storage unit 100 is realized mainly by the storage unit 12, and other functions are mainly realized by the control unit 11. FIG.

[Data storage part]
The data storage unit 100 stores data necessary for realizing account payment. Here, the bank database DB1 will be described as an example of data stored in the data storage unit 100. FIG.

FIG. 7 is a diagram showing an example of data storage in the bank database DB1. As shown in FIG. 7, the bank database DB1 is a database that stores information about accounts opened in banks. For example, the bank database DB1 stores a bank user ID, bank password, name, date of birth, email address, branch number, account number, password, one-time key information, quick login information, and account payment information. . Individual records in bank database DB1 correspond to individual accounts.

A bank user ID is a user account for using financial services online. Since the bank user ID is issued for each account, it can uniquely identify the account. A bank password is a password required to log in to an account. Name, date of birth, and e-mail address are personal information registered at the time of opening the account. The e-mail address can be changed after the fact. A branch number and an account number are information that can uniquely identify an account. A personal identification number is authentication information required when using some financial services.

The one-time key information includes the one-time key notified to the user's email address and the expiration date of this one-time key. The quick login information is information related to setting of quick login authentication, and includes, for example, information indicating whether or not quick login authentication is set, and an authentication ID used for quick login authentication. The payment-to-account information is information relating to the setting of payment-to-account. For example, information indicating whether or not payment-to-account is set, the payment user ID of the user who set payment-to-account, and the token T issued when payment-to-account was set. It contains information that can identify the user terminal 30 .

Any information may be stored in the bank database DB1. For example, other personal information such as the user's address or telephone number, account balance, or deposit/withdrawal details may be stored. The data storage unit 100 may also store data other than the bank database DB1. For example, a program for executing authentication such as token authentication, a program for issuing a token T, a one-time key A program for doing so, or data (HTML data or the like) of the first authentication page P44 to the third authentication page P46 displayed as a web view may be stored.

[Setting section]
The setting unit 101 performs authentication for an account designated by a user among a plurality of accounts when setting payment by account. This plurality of accounts means all accounts opened with a bank. The account specified by the user is the account used by the user for account payment. A user specifies an account by specifying at least one of a bank user ID and a branch name and account number. For example, inputting a bank user ID from the input form F440 of the first authentication page P44 corresponds to specifying an account. Inputting the branch name and the account number from the input forms F450 and F451 of the second authentication page P45 also corresponds to specifying the account.

Account-related authentication is authentication performed based on registered information associated with the account. This authentication is authentication performed before quick login authentication from the bank application A1. In this embodiment, the setting unit 101 performs authentication based on the bank user ID and bank password from the first authentication page P44, authentication based on the branch name and account number from the second authentication page P45, Four types of authentication are executed: one-time key authentication and personal identification number authentication from the third authentication page P46. The setting unit 101 may perform only some of these four authentications, or may perform other authentications such as biometric authentication and password authentication.

Setting up credit card means performing the processing necessary to allow credit card payment. The setting unit 101 acquires the payment user ID and the like of the user who applied for account payment from the payment server 20, generates account payment information, and stores the information in the bank database DB1. The setting unit 101 executes necessary processing up to the stage before quick login authentication from the bank application.

For example, the setting unit 101 performs authentication based on the bank user ID entered by the user from the input form F440 of the first authentication page P44. The setting unit 101 refers to the bank database DB1 and acquires the bank password associated with the input bank user ID. The setting unit 101 determines whether or not the acquired bank password matches the bank password entered by the user from the input form F441 of the first authentication page P44. If they match, authentication succeeds.

Also, for example, the setting unit 101 performs authentication based on the branch name and account number input by the user from the input forms F450 and F451 of the second authentication page P45. The setting unit 101 determines whether or not the input combination of branch name and account number exists in the bank database DB1. Authentication succeeds if this combination exists.

Also, for example, the setting unit 101 issues a one-time key, stores it in the bank database DB1 along with the expiration date, and notifies the user's e-mail address of the one-time key. The one-time key may be notified by other notification means such as SMS. The setting unit 101 determines whether or not the one-time key input by the user from the input form F461 of the third authentication page P46 matches the one-time key notified to the user. If they match and are within the one-time key's validity period, one-time key authentication succeeds.

Also, for example, the setting unit 101 determines whether or not the personal identification number entered by the user from the input form F462 of the third authentication page P46 matches the correct personal identification number obtained from the bank database DB1. The correct PIN number is the PIN number of the account for which authentication based on the bank user ID and bank password and authentication based on the branch name and account number have succeeded. If they match, the PIN authentication will succeed.

[Permission section]
The permission unit 102 uses the payment application A2 on the condition that the bank application A1 for using a predetermined account and the payment application A2 for using electronic payment are installed on the same user terminal 30. to withdraw the settlement amount from the account. This condition is a criterion for determining whether or not to allow account payment from the user's account. The installation of the bank application A1 and the payment application A2 is one of the conditions, and in this embodiment there are other conditions as described below.

Permitting account payment means permitting execution of account payment. In this embodiment, a case will be described in which the completion of all the settings required for account payment and the change of the payment source to account payment corresponds to permission of account payment. In addition, for example, issuing information (token T in this embodiment) necessary for execution of account payment may correspond to permitting account payment. Further, for example, executing account payment and withdrawing the settlement amount from the balance of the account may correspond to permitting account payment.

In the present embodiment, when account payment from the user's account is permitted, the payment amount can be withdrawn from this account when the execution of account payment is instructed using the payment application A2. If the user's account payment is not permitted, it is not possible to instruct the execution of the account payment using the payment application A2, or even if the instruction to execute the account payment can be given, the amount of the payment from the account will not be processed. cannot be withdrawn.

For example, if the payment application A2 is installed but the bank application A1 is not installed, if the bank application A1 is installed but the payment application A2 is not installed, or if the bank application A1 is also installed If the payment application A2 is also not installed, account payment is not permitted. In this embodiment, even if the bank application A1 is deleted after the setting of the payment source is completed, as long as the token T is valid, the account payment can be executed. When the token T becomes invalid, permission by the permission unit 102 is required again.

In this embodiment, the authorization unit 102 allows the bank application A1 and the payment application A2 to be installed on the same user terminal 30, and on the condition that the user logs in to both the bank application A1 and the payment application A2. allow payment. In this embodiment, a case will be described where the user logs into the payment application A2 and then logs into the bank application A1, but the user may log into the payment application A2 after logging into the bank application A1. The permission unit 102 permits account payment even if the bank application A1 and the payment application A2 are installed on the same user terminal 30 when the user has not logged into at least one of the payment application A2 and the bank application A1. do not do.

In this embodiment, the authorization unit 102 determines that the authentication of the setting unit 101 (the four authentications described above) is successful, and the bank application A1 and the payment application A2 of the account specified when setting the payment by account are installed on the same user terminal 30. and the user has logged in to both the bank application A1 and the payment application A2 of the account designated at the time of setting up the account payment, the account payment is permitted. The account designated at the time of setting of account payment is the account designated by authentication in the setting of the setting unit 101 . For example, this account is identified by the bank user ID entered in the input form F440 of the first authentication page P44. That is, this account is identified by the branch name and account number entered in the input forms F450 and F451 of the second authentication page P45. The bank application A1 of the account specified when setting the payment to the account is the bank application A1 for using this account. This bank application A1 is an application that has logged in to this account.

In this embodiment, an authentication ID used for quick login authentication is recorded in the storage area of the bank application A1. The number of authentication IDs that can be used for one bank user ID is limited to a predetermined number (one in this embodiment, but may be any number). Login to the bank application A1 included in the conditions of the permission unit 102 is performed by quick login authentication using an authentication ID. That is, the condition for permitting account payment is to log in to the account specified when the account payment is set by quick login authentication from the bank application A1. If the quick login authentication to this account is not successful, the authorization unit 102 determines that the authentication in the settings of the setting unit 101 has been successful and that the bank application A1 and the payment application A2 are installed on the same user terminal 30. Therefore, even if you are logged in to the payment application A2, account payment is not permitted. In logging into the bank application A1, an authentication method other than the quick login authentication (for example, an authentication method requiring entry of both a bank user ID and a bank password) may be used.

In this embodiment, the permitting unit 102 permits account payment by issuing a token T indicating that account payment is permitted. For example, the permitting unit 102 transmits the token T to the bank application A1. Token T is an example of permission information. Therefore, the portion described as token T can be read as permission information. Permission information is authentication information issued when account payment is permitted. Permission information is not limited to the token T. The permission information may be any information that can identify that the account payment is permitted, and may be information such as an ID. The permitting unit 102 sets the valid period of the token T from the time when the account payment is permitted to the time after a predetermined time. The token T is information that is not held in the bank server 10 in principle, but the token T may be held in the bank server 10 . A known method can be used as the method of issuing the token T itself.

[Execution unit]
The executing unit 103 executes the account payment when the account payment is permitted. The execution unit 103 executes account payment by withdrawing the settlement amount for account payment of a certain user from this user's account. In this embodiment, the case where the settlement amount is transmitted from the store terminal 40 to the bank server 10 via the settlement server 20 will be described. may be sent to

In this embodiment, the execution unit 103 confirms the validity of the token T and executes the account payment when the account payment is permitted. For example, the execution unit 103 confirms the validity of the token T by executing token authentication based on the token T stored in the user terminal 30 . A known authentication method can be used for the token authentication itself. In this embodiment, the execution unit 103 confirms the validity of the token T recorded in the storage area of the payment application A2.

For example, the execution unit 103 confirms the validity of the token T in at least one of when the payment application A2 is activated and when an instruction regarding account payment is issued after the payment application A2 is activated. In this embodiment, the validity of the token T is confirmed in both cases, but the validity of the token T may be confirmed in only one of these cases. The instruction regarding account payment is an instruction that serves as a declaration of intention for executing account payment. In this embodiment, the account payment is executed based on the code C25 displayed on the user terminal 30, so this instruction is an instruction for displaying the code C25. A tap on the home screen G2 is an example of an instruction to display code C25. This instruction may be performed by any operation.

When account payment is executed by reading the code displayed on the display unit 45 of the store terminal 40 or posted at the store with the photographing unit 36 of the user terminal 30, the instruction regarding the account payment activates the photographing unit 36. or an instruction to execute account payment to the user terminal 30 after the imaging unit 36 is activated and the code is read. When the account payment is executed by the user's operation on the user terminal 30 , the instruction regarding the account payment is an execution instruction for the account payment given to the user terminal 30 .

For example, the execution unit 103 executes authentication for personal identification and executes account payment. In the present embodiment, a case will be described in which this authentication is performed when the validity of token T has been confirmed (after the validity of token T has been confirmed). This authentication may be performed before. If this authentication succeeds, account payment is performed. Therefore, if this authentication does not succeed, even if the validity of the token T is confirmed, the account payment will not be executed. For example, the execution unit 103 executes authentication based on the authentication method selected by the user. When the user selects PIN authentication, the executing unit 103 executes PIN authentication based on the PIN entered from the input form F230 of the dialog D23. When the user selects biometric authentication, the execution unit 103 executes biometric authentication based on the image generated by the imaging unit 36, for example.

[3-2. Functions implemented in the payment server]
As shown in FIG. 6, the payment server 20 implements a data storage unit 200 . Data storage unit 200 is implemented mainly by storage unit 22 . The data storage unit 200 stores data necessary for realizing account payment. Here, the settlement database DB2 will be described as an example of data stored in the data storage unit 200. FIG.

FIG. 8 is a diagram showing an example of data storage in the payment database DB2. As shown in FIG. 8, the payment database DB2 is a database that stores information about users who have registered to use the payment service. For example, the payment database DB2 stores payment user IDs, payment passwords, names, dates of birth, e-mail addresses, payment source information, credit card information, electronic money information, electronic cash information, and account payment information.

A settlement user ID is a user account in the settlement service. The payment password is a password necessary for logging into the payment application A2. The name, date of birth, and e-mail address are personal information registered at the time of membership registration of the settlement service. The e-mail address can be changed after the fact. The payment source information is information that enables identification of the payment method set as the payment source.

The credit card information includes credit card number, credit card expiration date, and user name. The electronic money information includes an electronic money ID that uniquely identifies the electronic money and the balance. The electronic cash information includes an electronic cash ID that uniquely identifies the electronic cash and the balance. The account payment information includes at least one of the bank user ID of the account used for account payment, and the branch name (branch number) and account number of this account.

Arbitrary information may be stored in the payment database DB2, for example, the ID and expiration date included in the codes C20 and C25, or other personal information such as the user's address may be stored. Also, the data storage unit 200 may store data other than the payment database DB2, and may store, for example, a program for executing authentication.

[3-3. Functions implemented in user terminal]
As shown in FIG. 6 , the user terminal 30 implements a data storage unit 300 , a bank application execution unit 301 and a payment application execution unit 302 . The data storage unit 300 is realized mainly by the storage unit 32, and the other functions are mainly realized by the control unit 31. FIG.

[Data storage part]
The data storage unit 300 stores data necessary for realizing account payment. For example, the data storage unit 300 stores bank application A1, payment application A2, token T, expiration date of token T, and biometric authentication information. This biometric authentication information is information that is correct for biometric authentication. Further, for example, the data storage unit 300 may store quick login authentication settings for the bank application A1 and settings for the payment source and authentication method for the payment application A2.

[Bank application execution part]
Bank application execution unit 301 executes bank application A1. The bank application execution unit 301 permits account payment, in which the payment amount is withdrawn from the account using the payment application A2 based on a request from the payment application A2 for using electronic payment, which is installed on the same user terminal 30. Execute the process for Quick login authentication corresponds to processing for authorizing account payment. In this embodiment, when the bank application A1 receives the token T, it transfers the token T to the settlement application A2, so this transfer processing also corresponds to processing for permitting account payment.

[Payment application execution part]
The payment application executing unit 302 executes the payment application A2. The payment application executing unit 302 uses the payment application A2, which is permitted on the condition that the bank application A1 for using a predetermined account is installed in the same user terminal 30, to withdraw the payment amount from the account. Execute the process to execute the payment. This process may be any process necessary for account payment, and may be any process described as being executed using the payment application A2 in the present embodiment.

For example, the process of displaying the home screen G2 and the setting screens G3 and G4, or the process of transmitting the information input from these screens to the bank server 10 or the settlement server 20 executes account payment. Equivalent to processing for Further, for example, the process of receiving the temporary ID from the settlement server 20 and displaying the code C25 on the home screen G2 corresponds to the process of executing account payment. In this embodiment, when the payment application A2 receives the token T, it records the token T in the storage area corresponding to the payment application A2, so this process also corresponds to the process for executing the account payment.

[4. Processing performed by the account payment system]
Next, processing executed in the account payment system S will be described. In the present embodiment, among the processes executed in the payment-to-account system S, a setting process for setting the payment-to-account and an execution process for executing the payment-to-account will be described. Each of setting processing and execution processing is an example of processing executed by each functional block.

[4-1. Setting process]
9 and 10 are examples of flow charts of the setting process. The setting process is executed by each of control units 11 , 21 and 31 operating according to programs stored in storage units 12 , 22 and 32 . Here, as described with reference to FIG. 2, it is assumed that credit card payment is selected as the payment source.

As shown in FIG. 9, the user terminal 30 causes the display unit 35 to display the home screen G1 of the user terminal 30 (S100). When the user selects the icon I11, the user terminal 30 activates the payment application A2 (S101) and performs authentication with the payment server 20 (S102). In this authentication, the user may enter the payment user ID and payment password, or the authentication information recorded in the storage area of the payment application A2 may be used. The settlement server 20 generates and transmits an ID valid only for a certain period of time to the user terminal 30 (S103). Upon receiving this ID, the user terminal 30 causes the display unit 35 to display the home screen G2 of the payment application A2 (S104). In S104, the user terminal 30 encodes the received ID and displays the code C20 on the home screen G2.

When the user selects the button B21, the user terminal 30 displays the payment source setting screen G3 on the display unit 35 (S105). When the user selects the button B31 after selecting the area A30, the user terminal 30 displays the account payment setting screen G4 on the display unit 35 (S106). In S106, the family name, given name, and date of birth automatically entered in the input forms F40 to F42 of the setting screen G4 are acquired from the payment database DB2. When the user selects the button B43, the user terminal 30 transmits an access request to the bank's first authentication page P44 to the bank server 10 (S107).

The bank server 10 will transmit the data of the 1st authentication page P44 memorize|stored in the memory|storage part 12, if an access request|requirement is received (S108). Upon receiving this data, the user terminal 30 displays the first authentication page P44 on the setting screen G4 (S109). When the user selects the button B442 after entering the bank user ID and bank password in the input forms F440 and F441, the user terminal 30 executes authentication based on the bank user ID and bank password with the bank server 10 ( S110). If this authentication fails, this process ends.

When authentication based on the bank user ID and bank password is successful, the bank server 10 transmits data of the second authentication page P45 stored in the storage unit 12 to the user terminal 30 (S111). Upon receiving this data, the user terminal 30 displays the second authentication page P45 on the setting screen G4 (S112). When the user selects the button B452 after entering the branch name and account number in the input forms F450 and F451, the user terminal 30 executes authentication based on the branch name and account number with the bank server 10 (S113). . If this authentication fails, this process ends.

When the authentication based on the branch name and account number is successful, the bank server 10 transmits the data of the third authentication page P46 stored in the storage unit 12 to the user terminal 30 (S114). Moving to FIG. 10, when receiving this data, the user terminal 30 displays the third authentication page P46 on the setting screen G4 (S115). When the user selects the button B460, the user terminal 30 transmits a one-time key issue request to the bank server 10 (S116).

Upon receiving the issue request, the bank server 10 issues a one-time key, stores it in the bank database DB1, and transmits the one-time key to the user's email address (S117). When the user confirms the one-time key of the e-mail, the user terminal 30 accepts the input of the one-time key to the input form F461 (S118). When the user selects the button B463 after entering the personal identification number in the input form F462, the user terminal 30 performs authentication with the bank server 10 based on the one-time key and the personal identification number (S119). If the authentication in S119 fails, this process ends.

When the authentication based on the one-time key and the personal identification number is successful, the bank server 10 transmits to the user terminal 30 a success notification indicating that all the authentications necessary for setting up account payment have been successful (S120). Upon receiving the success notification, the user terminal 30 closes the third authentication page P46 and displays the dialog D47 on the setting screen G4 (S121). When the user selects the button B470, the user terminal 30 shifts the payment application A2 to the background, activates the bank application A1 (S122), and displays the authentication screen G5 on the display unit 35 (S123). In S122, if the bank application A1 is not installed, a screen requesting the download of the bank application A1 is displayed, and the process ends. In S123, if the user has not completed the setting of quick login authentication, a screen requesting this setting is displayed, and the process ends.

When the user inputs the bank password in the input form F50 and selects the button B51, the user terminal 30 performs quick login authentication with the bank server 10 (S124). In S124, the user terminal 30 transmits to the bank server 10 the authentication ID recorded in the storage area of the bank application A1 and the bank password entered by the user from the input form F50 of the authentication screen G5. The bank server 10 refers to the bank database DB1 and determines whether or not the bank password associated with the authentication ID matches the bank password entered by the user. Quick login authentication succeeds if these match. If the quick login authentication in S124 fails, this process ends.

When quick login authentication succeeds, the bank server 10 issues a token T with an expiration date based on a predetermined issuance rule, and transmits it to the user terminal 30 (S125). When receiving the token T using the bank application A1, the user terminal 30 transfers the token T from the bank application A1 to the payment application A2 and records the token T in the storage area of the payment application A2 (S126). The user terminal 30 shifts or terminates the bank application A1 to the background, returns the payment application A2 to the foreground, and displays the dialog D32 on the setting screen G3 (S127). In S127, a notification that the payment source has been changed to account payment is sent to the settlement server 20, and the user's payment source information is updated.

When the user selects the button B320, the user terminal 30 displays the dialog D22 on the home screen G2 (S128). When the user selects the button B220 or the button B221, the user terminal 30 records the authentication method selected by the user in the storage area of the payment application A2 (S129), and ends this process. The authentication method selected by the user may be transmitted to the bank server 10 and stored in the bank database DB1.

[4-2. Execution process]
11 to 13 are examples of flow diagrams of execution processing. The execution process is executed by each of the control units 11, 21, 31, 41 operating according to the programs stored in the storage units 12, 22, 32, 42. FIG. Here, it is assumed that the setting processing in FIGS. 9 and 10 has been completed, and the account payment has been set as the payment source. As shown in FIG. 11, the processing of S200-S202 is the same as the processing of S100-S102.

When the authentication in S202 succeeds, the user terminal 30 performs token authentication to confirm the validity of the token T recorded in the storage area of the payment application A2 with the bank server 10 (S203). The token authentication in S203 succeeds when the current date and time are within the validity period of the token T and it is confirmed that the token T is valid. Confirmation of the expiration date may be performed by the user terminal 30 or by the bank server 10 . If the token authentication fails, this process ends. The execution result of token authentication is transmitted from the bank server 10 to the user terminal 30 . The user terminal 30 refers to the validity of the token T received from the bank server 10 (S204).

If the token T is invalid (S204; N), the user terminal 30 determines whether there is a setting for quick login authentication of the bank application A1 (S205). If it is determined that there is no setting for quick login authentication (S205; N), this process ends. In this case, the user activates the bank application A1 by himself and sets quick login authentication. On the other hand, if it is determined that there is a setting for quick login authentication (S205; Y), the user terminal 30 shifts the payment application A2 to the background, starts the bank application A1 (S206), and performs authentication similar to S123. The screen G5 is displayed on the display unit 35 (S207). The subsequent processing of S208-S210 is the same as the processing of S124-S126. When the token T is recorded in the storage area of the payment application A2, the process proceeds to S211.

In S204, if the token T is valid (S204; Y), the user terminal 30 causes the display unit 35 to display the home screen G2 in the upper left state of FIG. 5 (S211). The user terminal 30 determines whether the user tapped to display the code C25 (S212). If it is not determined that the tap has been performed (S212; N), this process ends.

On the other hand, if it is determined that the tap has been performed (S212; Y), the process moves to FIG. refer to the validity of the token T received from (S214). If the token T is invalid (S214; N), the processing of S215-S220 similar to the processing of S205-S210 is executed, and the process proceeds to S221. Note that token authentication may be performed only once in the execution process. That is, one of S203 to S210 and S213 to S220 may be omitted.

In S214, if the token T is valid (S214; Y), the user terminal 30 performs authentication with the bank server 10 using the authentication method selected by the user (S221). In S221, if the user selects PIN authentication, the user terminal 30 transmits to the bank server 10 information that can identify the user and the PIN entered by the user in the input form F230. When the password entered by the user matches the password of the record corresponding to the user, the password authentication is successful. When the user selects biometric authentication, the user terminal 30 executes biometric authentication such as face authentication using the function of the OS, and transmits the authentication result to the bank server 10 . Upon receiving the authentication result, the bank server 10 transmits to the user terminal 30 a notification that the authentication result has been confirmed.

If the authentication in S221 succeeds, the processes of S222 and S223 similar to the processes of S103 and S104 are executed, and the code C25 is displayed on the home screen G2. Moving to FIG. 13, the user shows the code C25 to the store clerk. When the reading unit 46 reads the code C25 (S224), the store terminal 40 transmits a payment request including the information extracted from the code C25 and information such as the payment amount to the payment server 20 (S225). .

The settlement server 20, upon receiving the settlement request, transmits a request for execution of account payment to the bank server 10 (S226). Upon receiving the execution request, the bank server 10 executes the account payment (S227), and transmits the execution result of the account payment to the settlement server 20 (S228). Upon receiving the account payment execution result, the settlement server 20 transmits the account payment execution result to each of the user terminal 30 and the store terminal 40 (S229). Each of the user terminal 30 and the store terminal 40 causes the display units 35 and 45 to display the execution result of the account payment (S230, S231), and the process ends.

According to the payment-to-account system S of the present embodiment, on the condition that the bank application A1 and the payment application A2 are installed on the same user terminal 30, the payment-to-account payment is permitted from the payment application A2 to the bank. Compared to the case where payment by bank account can be used by completing an application procedure, installation of the bank application A1 (that is, cooperation between the bank application A1 and the payment application A2) is also a condition, so security in payment by bank account is enhanced. In addition, since the balance of the account is larger than the balance of electronic money or electronic cash, it is less likely that the balance will become insufficient, which enhances convenience for the user. For example, it is possible to prevent the user from having to recharge the balance of electronic money or electronic cash on the spot or to change the payment source to another payment method on the spot.

In addition, the account payment system S allows bank account payment on the condition that the bank application A1 and the payment application A2 are installed in the same user terminal 30 and that the user has logged into both the bank application A1 and the payment application A2. By permitting, not only the login to the payment application A2 but also the login to the bank application A1 becomes a condition, so the security of account payment is further enhanced.

In the payment-to-account system S, the authentication at the time of setting the payment-to-account has succeeded, the bank application A1 and the payment application A2 of the account specified at the time of setting the payment-to-account are installed on the same user terminal 30, and the account On the condition that the user has logged in to both the bank application A1 and the payment application A2 of the account specified at the time of setting the payment, by permitting the payment to the account, the bank application A1 of the account specified at the time of setting the payment to the account can be accessed. Since login is a condition, security in account payment is further enhanced. For example, even if some kind of bank application A1 is installed in the user terminal 30, if this bank application A1 is not for using the account specified at the time of setting up the payment by bank account, the payment by bank account is not permitted. Increased payment security.

In addition, the account payment system S allows login to the bank application A1 by quick login authentication in which the number of authentication IDs that can be used for one bank user ID is limited to a predetermined number. By making it a condition, quick login authentication with higher security becomes a condition, so the security in account payment is further enhanced. From the user's point of view, if the quick login authentication that is usually used is used, the account payment setting is completed, and the user's convenience is improved because there is no need for unfamiliar operations.

In addition, the account payment system S confirms the validity of the token T and executes the account payment, thereby eliminating the need for complicated procedures when executing the account payment, further enhancing the user's convenience. Further, even after the authorization unit 102 has permitted the payment to the account, the execution unit 103 confirms the validity of the token T when the payment to the account is executed, thereby further enhancing the security of the payment to the account.

Also, the account payment system S confirms that the bank application A1 is installed in the user terminal 30 by confirming the validity of the token T recorded in the storage area corresponding to the payment application A2 via the bank application A1. can be more reliably confirmed, security in account payment is further enhanced.

In addition, the payment-to-account system S confirms the validity of the token T when the payment application A2 is activated, and notices that the token T is invalid when the user executes the payment to the account. It is possible to prevent reissue. As a result, store turnover efficiency increases. In addition, the account payment system S confirms the validity of the token T immediately before the account payment is executed by confirming the validity of the token T when an instruction regarding account payment is issued after the settlement application A2 is activated. confirmation, further enhancing security in account payments. In addition, if the account payment system S confirms the validity of the token T multiple times, the security of account payment is further enhanced.

In addition, the account payment system S confirms the validity of the token T immediately before the account payment is executed by confirming the validity of the token T when an instruction to display the code C25 is given. , further increases security in account payments.

In addition, the account payment system S executes authentication for personal identification, and executes account payment when the authentication is successful, so that the bank application A1 and the payment application A2 can be installed on the same user terminal 30 only. Security is further enhanced because authentication for personal identification is also required.

[5. Modification]
Note that the present disclosure is not limited to the embodiments described above. Modifications can be made as appropriate without departing from the gist of the present disclosure.

FIG. 14 is a functional block diagram of a modification. As shown in FIG. 14, in the modification, a first restricting section 104 and a second restricting section 105 are implemented. These are realized mainly by the control unit 11 .

(1) For example, the payment application A2 may be installable in each of the plurality of user terminals 30 . In this modification, the user installs the payment application A2 on each of the user terminal 30A, which is a smartphone, and the user terminal 30B, which is a tablet terminal, and logs in with the same payment user ID. If the payment source is other than account payment, the user can log in to the payment application A2 of each of the user terminals 30A and 30B with the same payment user ID and execute electronic payment using a credit card or the like.

The account payment system S of this modified example includes a first restriction unit 104 . The first restriction unit 104 restricts each of the plurality of user terminals 30 from being permitted to pay by account using the same account. For example, the first restriction unit 104 determines whether the user terminal 30A's account payment is set as the payment source for the payment application A2 and the same account as the payment source for the payment application A2 of the user terminal 30B. It restricts both the condition to be set and

For example, assume that a user applies for account payment from the user terminal 30A and a token T is issued to the user terminal 30A. After that, the user applies for account payment from the user terminal 30B, and the token T is issued to the user terminal 30B. In this case, the first restriction unit 104 invalidates the previously issued token T for the user terminal 30A. As a result, account payment cannot be used from the user terminal 30A. When the user wants to use account payment from the user terminal 30A, the quick login authentication is executed again from the bank application A1 of the user terminal 30A. In this case, the first restriction unit 104 invalidates the token T of the user terminal 30B.

According to the modified example (1), by restricting each of the plurality of user terminals 30 from being allowed to pay by account using the same account, a malicious third party can use his/her own user terminal 30 to make an account payment. To limit the use of payment and further enhance security in account payment.

(2) Further, for example, the payment application A2 may be able to log in using each of a plurality of payment user IDs. A user has issued a plurality of payment user IDs. Each payment user ID is individually associated with credit card information and the like, and the user can log in to the payment application A2 with any payment user ID.

The account payment system S of this modification includes a second restriction unit 105 . The second restriction unit 105 restricts each of the plurality of payment user IDs from being permitted to pay by account using the same account. The second restriction unit 105 restricts an account set for account payment from the first settlement user ID so that account payment is not set from the second settlement user ID. This restriction may be provided with a restriction period (for example, about 30 days). For example, the second restriction unit 105 may permit account payment to be set from the second settlement user ID after the restriction period has passed. In this case, the second restriction unit 105 may restrict the use of account payment from the first payment user ID.

According to the modified example (2), by restricting each of a plurality of settlement user IDs from being permitted to make an account payment using the same account, a malicious third party can use their own settlement user ID to make an account. To limit the use of payment and further enhance security in account payment.

(3) Further, for example, the modified examples described above may be combined.

Further, for example, in the embodiment, as long as the token T is valid, even if the bank application A1 is deleted from the user terminal 30, the account payment can be executed. installation may be required. In this case, the permitting unit 102 may permit execution of account payment on the condition that bank application A1 and settlement application A2 are installed in the same user terminal 30 when account payment is executed. For example, the token T recorded in the storage area corresponding to the payment application A2 is transferred again to the bank application A1 and transmitted to the bank server 10 via the bank application A1, thereby confirming the installation of the bank application A1. good too. The same applies to the other conditions described in the embodiment, and the permitting unit 102 may determine whether or not each condition is satisfied when the account payment is executed.

Also, for example, when applying for bank account payment, it is not necessary that the bank application A1 and the payment application A2 are installed on the same user terminal 30 as a condition. In this case, if the authentication of each of the first authentication page P44 to the third authentication page P46 is successful, account payment may be set as the payment source. These authentications can succeed even if the bank application A1 is not installed. After that, when the user attempts to display the code C25 by tapping the home screen G2 of FIG. 5, quick login authentication is requested. If the bank application A1 is not installed, of course the quick login authentication cannot succeed. At this point quick login authentication may be performed and token T issued. Alternatively, for example, the account payment may be executed without using the token T. For example, for each account payment, some form of authentication may be performed by the bank.

Also, for example, in account payment, an account other than a bank may be used. Therefore, the account application is not limited to the bank application A1. For example, another account may be an account at a financial institution such as a credit union. Also, for example, there are electronic money and virtual currency accounts, and such accounts may be used for account payment.

Also, for example, the payment to account may be a service operated and provided by both the bank and the payment service provider, rather than by the bank. In this case, the functions described as being realized in the bank server 10 may be realized in either the settlement server 20 or the user terminal 30. FIG. Also, for example, each function may be realized by another computer, or may be shared by a plurality of computers.

S Account payment system 10 Bank server 20 Settlement server 30 User terminal 40 Store terminal 11, 21, 31, 41 Control unit 12, 22, 32, 42 Storage unit 13, 23, 33, 43 Communication unit , 34, 44 operation unit, 35, 45 display unit, 36 photographing unit, 46 reading unit, 100, 200, 300 data storage unit, 101 setting unit, 102 permission unit, 103 execution unit, 104 first restriction unit, 105 second 2 restriction unit, 301 bank application execution unit, 302 payment application execution unit, N network, T token, A1 bank application, A2 payment application, G1, G2 home screen, G3, G4 setting screen, G5 authentication screen, A30 area, C20 , C25 code, D22, D23, D24, D32, D47 dialog, DB1 bank database, DB2 payment database, I10, I11 icon, M22 message, P44 first authentication page, P45 second authentication page, P46 third authentication page, B21 , B31, B43, B51, B220, B221, B231, B320, B442, B452, B460, B463, B470 button, F40, F50, F230, F440, F441, F450, F460, F461, F462 input form.

Claims (9)

a first receiving means for receiving a login from an account application for using a predetermined account;
a second accepting means for accepting a login from the payment application, which is a payment application for using electronic payment and is capable of applying for account payment in which the payment amount is withdrawn from the account using the payment application ;
When the login and the application for both the account application and the payment application are received from the same user terminal , it is determined that the account application and the payment application are installed in the user terminal, and the account payment is permitted . issuing permission information indicating that the payment has been made, storing confirmation information necessary for confirming the validity of the permission information in a database, and transmitting the permission information to the user terminal, thereby permitting the account payment means and
including
the user terminal records the permission information in a storage area corresponding to the payment application via the account application;
When the account payment is permitted , the account payment system stores the permission information recorded in the storage area corresponding to the payment application via the account application and the confirmation information stored in the database. further comprising an execution means for verifying said validity and executing said account payment based on
account payment system. The payment-to-account system further includes setting means for executing authentication of the account specified by the user among the plurality of accounts when setting the payment-to-account,
The permission means permits the account payment when the authentication is successful and the account application and the payment application of the account specified at the time of setting are installed on the same user terminal.
The account payment system according to claim 1 . An authentication ID used in an authentication method that can omit input of a user ID corresponding to the account is recorded in the storage area of the account application,
The number of authentication IDs that can be used for one user ID is limited to a predetermined number,
Login to the account application is performed by the authentication method using the authentication ID,
The account payment system according to claim 2 . The execution means confirms the validity of the permission information at least one of when the payment application is activated and when an instruction regarding the account payment is issued after the payment application is activated.
The account payment system according to any one of claims 1 to 3 . the account payment is performed based on a code displayed on the user terminal;
The instruction is an instruction for displaying the code,
The account payment system according to claim 4 . The execution means further executes authentication for identity verification, and executes the account payment if the authentication is successful.
The account payment system according to any one of claims 1 to 5 . The payment application can be installed on each of the plurality of user terminals,
The account payment system includes first restriction means for restricting each of the plurality of user terminals from allowing the account payment using the same account;
The account payment system according to any one of claims 1 to 6 , further comprising: The payment application can be logged in using each of a plurality of user IDs,
the account payment system includes second restricting means for restricting each of the plurality of user IDs from being permitted to perform the account payment using the same account;
The account payment system according to any one of claims 1 to 7 , further comprising: the computer
a first reception step of accepting a login from an account application for using a predetermined account;
a second accepting step of accepting a login from the payment application, which is a payment application for using electronic payment and is capable of applying for account payment in which the payment amount is withdrawn from the account using the payment application ;
When the login and the application for both the account application and the payment application are received from the same user terminal , it is determined that the account application and the payment application are installed in the user terminal, and the account payment is permitted . issuing permission information indicating that the payment has been made, storing confirmation information necessary for confirming the validity of the permission information in a database, and transmitting the permission information to the user terminal, thereby permitting the account payment a step ;
and run
the user terminal records the permission information in a storage area corresponding to the payment application via the account application;
When the account payment is permitted, the computer stores the permission information recorded in the storage area corresponding to the payment application via the account application and the confirmation information stored in the database. further performing an execution step of confirming the validity and performing the account payment, based on
Account payment method.

Images