Authentication system, authentication method, and program
The authentication system enhances user convenience in payment services by enabling authentication code reading on a first terminal and switching authentication methods based on phone number changes, ensuring seamless transitions and security.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- RAKUTEN GROUP INC
- Filing Date
- 2024-08-29
- Publication Date
- 2026-06-24
AI Technical Summary
Existing authentication systems in payment services require users to perform non-standard operations, such as reading authentication codes, which detracts from user convenience.
An authentication system that allows users to read payment codes on a first terminal and perform authentication using a second terminal, switching between different authentication methods based on whether the user's phone number has changed, thereby enhancing convenience.
Improves user convenience by allowing seamless authentication transitions without requiring non-standard operations, while maintaining security through flexible authentication methods.
Smart Images

Figure 0007879905000001 
Figure 0007879905000002 
Figure 0007879905000003
Abstract
Description
Technical Field
[0001] The present disclosure relates to an authentication system, an authentication method, and a program.
Background Art
[0002] Conventionally, authentication for enhancing the security of payment services is known. For example, in Patent Document 1, there is described an information processing apparatus capable of communicating with each of a first terminal apparatus already authenticated as a terminal apparatus used by a user and a second terminal apparatus not yet authenticated, which generates code information in which authentication information is encoded when a login request is received from the second terminal apparatus, transmits the code information to either the first terminal apparatus or the second terminal apparatus, and executes authentication by reading an authentication code displayed based on the code information by the other party.
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] However, in the technique of Patent Document 1, since it is premised that the authentication code displayed based on the code information issued for authentication is read, the user needs to perform an operation (operation for displaying the authentication code) different from the operations for ordinary payment. Therefore, in the technique of Patent Document 1, since the user needs to perform an operation that the user is not accustomed to, the convenience of the user cannot be sufficiently enhanced. This is not limited to the technique of Patent Document 1, and the same applies to other techniques in payment services.
[0005] One object of the present disclosure is to enhance the convenience of the user. [Means for solving the problem]
[0006] The authentication system relating to this disclosure includes: a reading information acquisition unit that acquires reading information read from a payment code when the payment code displayed on a first user terminal of a user using a payment service is read by a second user terminal different from the first user terminal; and an authentication unit that performs payment code authentication using the payment code when the reading information is acquired. [Effects of the Invention]
[0007] This disclosure can improve user convenience. [Brief explanation of the drawing]
[0008] [Figure 1] This figure shows an example of the hardware configuration of the authentication system according to the first embodiment. [Figure 2] This figure shows an example of a screen displayed on the first user terminal of the first embodiment. [Figure 3] This figure shows an example of a screen displayed on the second user terminal of the first embodiment. [Figure 4] This figure shows an example of the functions implemented in the authentication system of the first embodiment. [Figure 5] This figure shows an example of an authentication database according to the first embodiment. [Figure 6] This figure shows an example of a payment database in the first embodiment. [Figure 7] This figure shows an example of the process performed by the authentication system of the first embodiment. [Figure 8] This figure shows an example of a screen displayed on the second user terminal in the second embodiment. [Figure 9] This figure shows an example of the functions implemented in the authentication system of the second embodiment. [Figure 10] This figure shows an example of the process performed by the authentication system of the second embodiment. [Figure 11]It is a diagram showing an example of a process executed in the authentication system of the second embodiment. [Figure 12] It is a diagram showing an example of a screen displayed on the second user terminal of the third embodiment. [Figure 13] It is a diagram showing an example of a function realized by the authentication system of the third embodiment. [Figure 14] It is a diagram showing an example of a process executed in the authentication system of the third embodiment. [Figure 15] It is a diagram showing an example of a process executed in the authentication system of the third embodiment. [Figure 16] It is a diagram showing an example of a function realized by a modification example related to the first embodiment. [Figure 17] It is a diagram showing an example of an authentication selection screen displayed on the second user terminal of modification examples 1-8. [Figure 18] It is a diagram showing an example of a screen displayed on each of the first user terminal and the second user terminal in modification example 1-11. [Figure 19] It is a diagram showing an example of a screen displayed on the second user terminal of modification example 2-2. [Figure 20] It is a diagram showing an example of a screen displayed on the second user terminal of modification example 2-3. [Figure 21] It is a diagram showing an example of a function realized by a modification example related to the third embodiment. [Figure 22] It is a diagram showing an example of a screen displayed on the second user terminal in modification example 3-1. [Embodiments for Carrying Out the Invention]
[0009] [1. First Embodiment] The first embodiment, which is an example of an embodiment of the authentication system, authentication switching method, and program according to the present disclosure, will be described.
[0010] [1-1. Hardware Configuration of the Authentication System of the First Embodiment] Figure 1 shows an example of the hardware configuration of the authentication system of the first embodiment. For example, the authentication system 1 of the first embodiment includes an authentication server 10, a payment server 20, a first user terminal 30A, a second user terminal 30B, and a store terminal 40. Each of the authentication server 10, payment server 20, first user terminal 30A, second user terminal 30B, and store terminal 40 is connected to a network N such as the Internet or a LAN. Note that there may be multiple units of at least one of the authentication server 10, payment server 20, first user terminal 30A, second user terminal 30B, and store terminal 40.
[0011] The authentication server 10 is a server computer that performs authentication for a predetermined service. For example, the authentication server 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The storage unit 12 includes at least one of volatile memory such as RAM and non-volatile memory such as flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.
[0012] In the first embodiment, we take the example of a case where the payment service corresponds to a predetermined service. Therefore, where it is written as "payment service," it can be read as "predetermined service." The payment service is a service that provides electronic payment (cashless payment) to the user. The predetermined service may be a service other than the payment service. For example, the predetermined service may be an e-commerce service, a travel booking service, an electronic ticketing service, a communication service, a financial service, or another service. The predetermined service may be a service provided from a browser rather than a specific application.
[0013] The payment server 20 is a server computer that performs payments in a payment service. For example, the payment server 20 includes a control unit 21, a storage unit 22, and a communication unit 23. The hardware configuration of the control unit 21, the storage unit 22, and the communication unit 23 may be the same as that of the control unit 11, the storage unit 12, and the communication unit 13, respectively. In the first embodiment, we take the example of a case where the authentication function and the payment function are divided between the authentication server 10 and the payment server 20, but these functions may be realized by a single computer. For example, the authentication server 10 may have not only an authentication function but also a payment function. The payment server 20 may have not only a payment function but also an authentication function.
[0014] The first user terminal 30A is the user's computer. For example, the first user terminal 30A is a smartphone, tablet, personal computer, or wearable device. The first user terminal 30A includes a control unit 31A, a storage unit 32A, a communication unit 33A, an operation unit 34A, a display unit 35A, and a camera unit 36A. The hardware configuration of the control unit 31A, the storage unit 32A, and the communication unit 33A may be the same as that of the control unit 11, the storage unit 12, and the communication unit 13, respectively. The operation unit 34A is an input device such as a touch panel or mouse. The display unit 35A is a display such as a liquid crystal or organic EL. The camera unit 36A includes at least one camera.
[0015] The second user terminal 30B is the user's computer. In principle, the user of the first user terminal 30A and the user of the second user terminal 30B are the same. However, if a malicious third party impersonates the user, the malicious third party's terminal may correspond to the second user terminal 30B. For example, the second user terminal 30B is a smartphone, tablet, personal computer, or wearable device. The second user terminal 30B includes a control unit 31B, a storage unit 32B, a communication unit 33B, an operation unit 34B, a display unit 35B, and a shooting unit 36B. The hardware configuration of the control unit 31B, storage unit 32B, communication unit 33B, operation unit 34B, display unit 35B, and shooting unit 36B may be the same as that of the control unit 31A, storage unit 32A, communication unit 33A, operation unit 34A, display unit 35A, and shooting unit 36A, respectively.
[0016] The store terminal 40 is a computer of a store participating in the payment service. The store is not limited to a physical store that a user actually visits, but may also be an online store. For example, the store terminal 40 may be a POS terminal, a self-checkout, a handheld terminal, a smartphone, a tablet, or a personal computer. The store terminal 40 includes a control unit 41, a storage unit 42, a communication unit 43, an operation unit 44, a display unit 45, and a reading unit 46. The hardware configuration of the control unit 41, storage unit 42, communication unit 43, operation unit 44, and display unit 45 may be the same as that of the control unit 11, storage unit 12, communication unit 13, operation unit 34A, and display unit 35A, respectively. The reading unit 46 includes at least one code reader or reader / writer. The reading unit 46 may also include at least one camera.
[0017] Furthermore, programs stored in memory units 12, 22, 32A, 32B, and 42 may be supplied to the authentication server 10, payment server 20, first user terminal 30A, second user terminal 30B, or store terminal 40 via the network N. In addition, at least one of a reading unit (e.g., a memory card slot) for reading computer-readable information storage media and an input / output unit (e.g., a USB port) for inputting and outputting data with external devices may be included in the authentication server 10, payment server 20, first user terminal 30A, second user terminal 30B, or store terminal 40. For example, a program stored on the information storage media may be supplied to the authentication server 10, payment server 20, first user terminal 30A, second user terminal 30B, or store terminal 40 via at least one of the reading unit and the input / output unit.
[0018] Furthermore, the authentication system 1 may include at least one computer. The computers included in the authentication system 1 are not limited to the example in Figure 1. For example, the authentication system 1 may include only the authentication server 10 and the payment server 20. In this case, the first user terminal 30A, the second user terminal 30B, and the store terminal 40 are located outside the authentication system 1. The authentication system 1 may include only the authentication server 10. In this case, the payment server 20, the first user terminal 30A, the second user terminal 30B, and the store terminal 40 are located outside the authentication system 1. For example, the authentication system 1 may include the authentication server 10 and other computers not shown in Figure 1.
[0019] [1-2. Overview of the First Embodiment] In the first embodiment, an example is given where a user uses a payment service from a payment application stored on the first user terminal 30A. The payment application is an application provided by the administrator of the payment service. Once the user installs the payment application on the first user terminal 30A and registers as a member of the payment service, they will be able to use the payment service from the payment application. The user may also use the payment service from other applications other than the payment application stored on the first user terminal 30A (for example, an application provided by a credit card company, or other non-payment applications) or from a browser.
[0020] Figure 2 shows an example of a screen displayed on the first user terminal 30A in the first embodiment. As shown in the upper left of Figure 2, when a user operates the first user terminal 30A to launch the payment application, the first user terminal 30A displays the login screen SC1 for the user to log in to the payment service on the display unit 35A, as shown in the upper right of Figure 2. For example, when a user selects button B10 and enters their login account and password, the first user terminal 30 performs login authentication with the authentication server 10 for the user to log in to the payment service. Login authentication may also be performed by the payment server 20.
[0021] In the first embodiment, we take an example where, in addition to login authentication, the user is required to perform telephone number authentication. For example, if the user does not perform telephone number authentication, the payment service may be subject to certain usage restrictions (e.g., a limit on the maximum payment amount). In this case, if the user performs telephone number authentication, the user can have the usage restrictions removed. If the user does not perform telephone number authentication, the user may be prevented from using the payment service. In this case, if the user performs telephone number authentication, the user will be able to use the payment service. Even if the user does not perform telephone number authentication, the user may be able to use the payment service without any usage restrictions. In this case, the user may be required to perform telephone number authentication by a predetermined deadline.
[0022] For example, if a user has not yet performed phone number verification, the first user terminal 30A displays the phone number verification screen SC2 on the display unit 35A, as shown in the lower left of Figure 2, to allow the user to perform phone number verification. Even if the user has logged into the payment service before, if the user has not performed phone number verification (i.e., their phone number is not registered with the payment service), the first user terminal 30A displays the phone number verification screen SC2 on the display unit 35A and requests the user to perform phone number verification. The user performs phone number verification according to the procedure guided on the phone number verification screen SC2.
[0023] The telephone number authentication process may be the same as the publicly known process. While Figure 2 shows an example where a call is made to the authentication telephone number, telephone number authentication may also be performed by receiving a call to the user's telephone number, using SMS (Short Message Service), or by other methods. Once telephone number authentication is performed, the user's telephone number is registered with the payment service. The payment service may also register other information, such as information that identifies the first user terminal 30A used by the user when logging into the payment service. Telephone number authentication may also verify the telephone number the user has registered with other services, such as e-commerce services.
[0024] For example, when phone number authentication is performed, the first user terminal 30A displays a code screen SC3 on the display unit 35A, which includes a payment code C30 generated based on a code ID that can temporarily identify the user, as shown in the lower right of Figure 2. The payment code C30 is a code for payment. In the example in the lower right of Figure 2, the case in which the payment code C30 includes a barcode and a two-dimensional code is explained, but the payment code C30 may be either a barcode or a two-dimensional code.
[0025] For example, when the store terminal 40 reads the payment code C30 with the reading unit 46, it obtains a code ID from the payment code C30. When the store terminal 40 transmits the code ID obtained from the payment code C30 to the authentication server 10 or the payment server 20, the payment is executed. The payment flow may be the same as the flow in known payment services. For example, once the validity of the code ID is confirmed, the payment is executed based on the payment method specified by the user as the payer.
[0026] Furthermore, payment may be performed by methods other than having the store terminal 40 read the payment code C30. For example, payment may be of the type in which the first user terminal 30A reads a code displayed on the store terminal 40, of the type in which the first user terminal 30A reads a code posted in the store, of the type that is completed solely by operations on the first user terminal 30A, of the type that utilizes the IC chip of the first user terminal 30A, online payment (e.g., account payment using the user's account, ID payment using the user's ID), carrier payment which is payment from the carrier used by the first user terminal 30A, or other types. Alternatively, for example, payment may be performed by the user reading the code on the invoice with the first user terminal 30A and paying the invoice. Similarly, payments made from the second user terminal 30B may be any of these methods.
[0027] In the first embodiment, we take the case where a user changes from a first user terminal 30A to a second user terminal 30B as an example. For example, the user installs a payment application on the second user terminal 30B. When the user operates the second user terminal 30B and launches the payment application, the second user terminal 30B displays the login screen SC1 on the display unit 35B. The user logs in to the payment service from the second user terminal 30B in the same way as when logging in to the payment service from the first user terminal 30A. When the authentication server 10 detects that the user has logged in from the new terminal, the second user terminal 30B, it requests the user to perform an authentication different from the login authentication. In the first embodiment, this authentication is switched depending on whether or not the phone number is changed.
[0028] Figure 3 shows an example of a screen displayed on the second user terminal 30B in the first embodiment. For example, when a user logs into the payment service for the first time from the second user terminal 30B after completing phone number authentication on the first user terminal 30A, the second user terminal 30B displays a change requirement screen SC4 on the display unit 35B, as shown in the upper right of Figure 3, asking the user whether or not to change their phone number. If the user does not want to change their phone number due to a change of device, the user selects button B40 to indicate that they do not want to change their phone number. If the user wants to change their phone number due to a change of device, the user selects button B41 to indicate that they want to change their phone number.
[0029] In the first embodiment, if the phone number has not been changed, the user is required to perform a predetermined authentication. Hereafter, this authentication will be referred to as the first authentication. The first authentication is a different authentication from the login authentication. In the first embodiment, the case in which phone number authentication corresponds to the first authentication is given as an example, but the first authentication may be any other authentication method other than phone number authentication. For example, the first authentication may be knowledge authentication that uses information other than the password used for login authentication, biometric authentication such as facial recognition or fingerprint recognition, or possession authentication that confirms possession of a credit card or the like.
[0030] For example, when the user selects button B40, the second user terminal 30B displays the first authentication screen SC5 on the display unit 35B for the user to perform the first authentication, as shown in the lower left of Figure 3. In the example in the lower left of Figure 3, the first authentication screen SC5 has the same layout as the telephone number authentication screen SC2, but the first authentication screen SC5 may have a different layout from the telephone number authentication screen SC2. The first authentication screen SC5 may be the same screen as the telephone number authentication screen SC2, or it may be a different screen. The user performs the first authentication from the first authentication screen SC5 in the same way as when the user performed telephone number authentication from the telephone number authentication screen SC2 on the first user terminal 30A. Once the user performs the first authentication, the user can use the payment service from the second user terminal 30B without changing their telephone number.
[0031] In the first embodiment, if the phone number has changed, the user is required to perform an authentication different from the first authentication. Hereafter, this authentication will be referred to as the second authentication. The second authentication is different from both the first authentication and the login authentication. In the first embodiment, the case in which the user scans a credit card with the second user terminal 30B is given as an example of the second authentication, but it may also be a card scan authentication that scans a card other than a credit card that the user possesses (electronic money card, My Number card, etc.). The second authentication may also be an authentication other than card scan authentication. For example, the second authentication may be a knowledge authentication that uses information other than the password for login authentication, a biometric authentication such as facial recognition or fingerprint recognition, or a possession authentication other than card scan authentication. For example, the second authentication may be an authentication (a type of knowledge authentication) that requires the user to input the phone number before the change and verifies the validity of the phone number before the change. The second authentication may also be an authentication (a type of knowledge authentication) that requires the user to input the user's attribute information and verifies the user's validity.
[0032] For example, when the user selects button B41, the second user terminal 30B displays the second authentication screen SC6 for the user to perform the second authentication on the display unit 35B, as shown in the lower right of Figure 3. In the first embodiment, we take the case where the communication unit 33B of the second user terminal 30B supports near-field communication (e.g., NFC). The second user terminal 30B activates the near-field communication function and scans the credit card. The flow of card scan authentication, which is an example of second authentication, may be the same as a known flow. Based on the information read from the credit card, the second user terminal 30B performs second authentication with the authentication server 10.
[0033] For example, once a user performs a second authentication, the user can access the payment service from the second user terminal 30B. The user may register their changed phone number with the payment service by performing phone number authentication with the changed phone number (new phone number) from the second user terminal 30B. Alternatively, the user may register their changed phone number with the payment service by entering the changed phone number from at least one of the first user terminal 30A and the second user terminal 30B before performing the second authentication. The user's old phone number (previous phone number) may remain registered with the payment service or may be overwritten with the changed phone number.
[0034] As described above, in the first embodiment, when a user who has been using the payment service from the first user terminal 30A changes their device and logs in to the payment service from the second user terminal 30B, the authentication system 1 allows the user to select from the change requirement screen SC4 whether or not to change the phone number registered with the payment service. Based on the user's operation on the change requirement screen SC4, the authentication system 1 switches between the first authentication and the second authentication performed from the second user terminal 30B. By providing the user with flexible authentication according to whether or not to change the phone number, the authentication system 1 enhances security while improving user convenience. The details of the authentication system 1 of the first embodiment will be described below.
[0035] [1-3. Functions realized in the authentication system of the first embodiment] Figure 4 shows an example of the functions realized in the authentication system 1 of the first embodiment. The components realized in the authentication system 1 of the first embodiment can be configured by combining them into a single device, or by further distributing them among multiple devices.
[0036] [1-3-1. Functions implemented by the authentication server] For example, the authentication server 10 includes a data storage unit 100, a change requirement information acquisition unit 101, and an authentication unit 102. The data storage unit 100 is implemented by a storage unit 12. The change requirement information acquisition unit 101 and the authentication unit 102 are each implemented by a control unit 11.
[0037] [Data Storage Unit] The data storage unit 100 stores various data for authentication. For example, the data storage unit 100 stores the authentication database DB1.
[0038] Figure 5 shows an example of the authentication database DB1 in the first embodiment. The authentication database DB1 is a database that stores various information for authentication. For example, the authentication database DB1 stores user ID, login account, password, code ID, expiration date, telephone number, and terminal ID. The information stored in the authentication database DB1 is not limited to the example in Figure 5. Other information may be stored in the authentication database DB1. For example, the authentication database DB1 may store personal information such as the user's name, or the user's login history to the payment service.
[0039] A user ID is an example of user identification information that can identify a user. A login account is also an example of user identification information. The login account may be freely changed by the user. In the first embodiment, we take the example of a case where there is a login account separate from the user ID (where there are at least two pieces of user identification information), but there may be only one piece of user identification information. That is, the user ID and the login account do not have to be separate. A password is authentication information that is verified during login authentication.
[0040] A code ID is an ID that can temporarily identify a user, and therefore, a code ID is also an example of user identification information. In the first embodiment, we take the case where the payment server 20 issues a code ID as an example. For example, when the payment server 20 issues a code ID for a user, it issues a new code ID so as not to overlap with other code IDs. The payment server 20 sends the new code ID for the user to the authentication server 10. The authentication server 10 stores the new code ID and its expiration date in the authentication database DB1, associating it with the user's user ID and login account. The expiration date may be determined by any method. For example, the expiration date may be a predetermined time after the issuance of the code ID.
[0041] The code ID may be issued at any time. For example, the payment server 20 may issue the code ID when the payment application is launched, when the expiration date has passed, when the user instructs it to issue a code ID, or at any other time. The code ID may also be issued by the authentication server 10 or another computer, rather than by the payment server 20. The code ID does not have to have an expiration date. For example, the code ID may be a semi-permanently valid ID with no specific expiration date.
[0042] Furthermore, the code ID may be issued by the authentication server 10 instead of the payment server 20. In this case, the payment server 20 may obtain the code ID issued by the authentication server 10 and store it in the payment database DB2. Also, the authentication server 10 does not need to manage the code ID in any special way. The expiration date of the code ID may also be determined by the authentication server 10 instead of the payment server 20. The payment server 20 obtains the expiration date of the code ID from the authentication server 10 and stores it in the authentication database DB1.
[0043] In the first embodiment, the telephone number stored in the authentication database DB1 is the telephone number registered with the payment service through telephone number authentication. For example, when a user performs telephone number authentication from the telephone number authentication screen SC2 of the first user terminal 30A, the authentication server 10 registers the telephone number with the payment service by storing the telephone number of the first user terminal 30A in the authentication database DB1, associating it with the user's user ID and login account. The telephone number may be registered in a database other than the authentication database DB1, a computer other than the authentication server 10, or an information storage medium. For example, the telephone number may be registered in the payment database DB2 of the payment server 20.
[0044] The terminal ID is an example of terminal identification information that can identify the first user terminal 30A or the second user terminal 30B. The terminal ID may be information issued by the authentication server 10 or another computer when a user logs in to the payment service for the first time from the first user terminal 30A or the second user terminal 30B. The terminal identification information may be other information besides the terminal ID. The terminal identification information may be information pre-stored in the first user terminal 30A or the second user terminal 30B (for example, the individual identification number of the first user terminal 30A or the second user terminal 30B). When a user logs in to the payment service from the first user terminal 30A or the second user terminal 30B, the terminal ID is stored in the authentication database DB1. The terminal ID may also be stored in the payment database DB2 of the payment server 20.
[0045] For example, the terminal ID may be stored in the authentication database DB1 on the condition that telephone number authentication is performed. When telephone number authentication is performed from a first user terminal 30A, the authentication server 10 may store the terminal ID of the first user terminal 30A in the authentication database DB1. The authentication server 10 may associate the telephone number confirmed by telephone number authentication with the terminal ID and store it in the authentication database DB1. The authentication server 10 may store the terminal ID of a second user terminal 30B that has completed first or second authentication in the authentication database DB1. When a user registers a changed telephone number with the payment service, the authentication server 10 may associate the changed telephone number with the terminal ID of the second user terminal 30B and store it in the authentication database DB1.
[0046] The authentication database DB1 may also store completed information indicating whether each of the telephone number authentication, first authentication, and second authentication has been performed. When a user performs authentication, the authentication unit 102, described later, stores completed information in the authentication database DB1, associated with the user's user ID and login account, indicating that the authentication has been performed. The authentication server 10 or payment server 20 may provide payment services to a user based on the user's completed information. For example, the authentication server 10 or payment server 20 may restrict a user's use of payment services if the user has not performed a specific authentication.
[0047] For example, the authentication server 10 or the payment server 20 may provide the same payment service to the second user terminal 30B that performed the first authentication and to the second user terminal 30B that performed the second authentication, or it may restrict the use of the payment service from at least one of them. The authentication server 10 or the payment server 20 may restrict the use of the payment service from the second user terminal 30B that performed the first authentication more than the use of the payment service from the second user terminal 30B that performed the second authentication. The authentication server 10 or the payment server 20 may restrict the use of the payment service from the second user terminal 30B that performed the second authentication more than the use of the payment service from the second user terminal 30B that performed the first authentication. Which authentication was performed can be identified by the execution information.
[0048] Furthermore, the data stored in the data storage unit 100 is not limited to the examples described above. The data storage unit 100 only needs to store data for authentication. For example, the data storage unit 100 may store data necessary for displaying the login screen SC1, the telephone number authentication screen SC2, the code screen SC3, the change requirement screen SC4, the first authentication screen SC5, the second authentication screen SC6, or other screens. The data storage unit 100 may also store a program that indicates the authentication process described in the first embodiment.
[0049] [Information Acquisition Unit for Change Requirements] The Change Necessity Information Acquisition Unit 101 acquires change necessity information regarding whether or not to change the telephone number registered with the payment service when a login to the payment service (an example of a predetermined service) is made from a second user terminal 30B, which is different from the first user terminal 30A, after a login to the payment service has been made from the first user terminal 30A. The first user terminal 30A and the second user terminal 30B are assumed to be logged in from the same login account. When a legitimate user logs in, both the first user terminal 30A and the second user terminal 30B belong to the legitimate user. When a malicious third party logs in, the first user terminal 30A belongs to the legitimate user, but the second user terminal 30B belongs to the malicious third party.
[0050] The change requirement information indicates either to change the telephone number or not to change the telephone number. In the first embodiment, the change requirement information acquisition unit 101 acquires the change requirement information from the second user terminal 30B as an example, but the change requirement information acquisition unit 101 may acquire the change requirement information from the first user terminal 30A, the payment server 20, another computer, or an information storage medium.
[0051] For example, if a user selects buttons B40 or B41 from the change requirement screen SC4, the second user terminal 30B generates change requirement information based on the user's selection and sends it to the authentication server 10. If the user selects button B40, the second user terminal 30B sends change requirement information to the authentication server 10 indicating that the phone number will not be changed. If the user selects button B41, the second user terminal 30B sends change requirement information to the authentication server 10 indicating that the phone number will be changed.
[0052] The decision of whether or not to change the phone number may be made using parts other than buttons B40 and B41. These other parts may be well-known parts used as part of the user interface. For example, the decision of whether or not to change the phone number may be made using radio buttons, checkboxes, panels, icons, or text. The decision of whether or not to change the phone number may also be made from a screen other than the change decision screen SC4. The user may select whether or not to change the phone number from the first user terminal 30A and register the change decision information in the authentication database DB1 in advance. In this case, the change decision information acquisition unit 101 may acquire the change decision information from the authentication database DB1. The change decision information acquisition unit 101 may also acquire the change decision information from a database other than the authentication database DB1.
[0053] Furthermore, whether or not to change the phone number may not be a choice made by the user, but may be determined automatically. For example, when a user logs in to the payment service from the second user terminal 30B, the second user terminal 30B may obtain the phone number registered by the user with the payment service from the authentication server 10 and determine whether or not to change the phone number by comparing it with the phone number stored in itself (e.g., a SIM card). The phone number registered with the payment service may differ from the phone number of another service that is linked to the payment service (e.g., a service that comprehensively manages user information) if the phone number of that other service changes. In this case, it may be determined that the phone number should be changed. If these phone numbers match, the second user terminal 30B may send change requirement information to the authentication server 10 indicating that the phone number should not be changed. If these phone numbers do not match, the second user terminal 30B may send change requirement information to the authentication server 10 indicating that the phone number should be changed. The change requirement information acquisition unit 101 acquires the change requirement information from the second user terminal 30B.
[0054] For example, the second user terminal 30B may accept phone number input from the user and transmit the phone number entered by the user to the authentication server 10. Alternatively, instead of accepting phone number input from the user, the second user terminal 30B may transmit the phone number stored in itself (for example, on a SIM card) to the authentication server 10. The change requirement information acquisition unit 101 may compare the phone number registered with the payment service with the phone number acquired from the second user terminal 30B to acquire change requirement information. If these phone numbers match, the change requirement information acquisition unit 101 may acquire change requirement information indicating that the phone number should not be changed. If these phone numbers do not match, the change requirement information acquisition unit 101 may acquire change requirement information indicating that the phone number should be changed.
[0055] For example, the authentication server 10 may accept input of the phone number of the second user terminal 30B from the first user terminal 30A, rather than from the second user terminal 30B. The first user terminal 30A transmits the phone number of the second user terminal 30B to the authentication server 10. The change requirement information acquisition unit 101 may compare the phone number registered with the payment service with the phone number obtained from the first user terminal 30A to obtain change requirement information. If these phone numbers match, the change requirement information acquisition unit 101 may obtain change requirement information indicating that the phone number should not be changed. If these phone numbers do not match, the change requirement information acquisition unit 101 may obtain change requirement information indicating that the phone number should be changed.
[0056] [Authentication Department] The authentication unit 102 performs authentication in the payment service. For example, the authentication unit 102 switches the authentication performed from the second user terminal 30B based on the change requirement information. Switching authentication means using different authentication methods (using different authentication methods) depending on the change requirement information. The authentication unit 102 requests different authentication from the user who logs into the payment service from the second user terminal 30B depending on whether the change requirement information indicates that the phone number will not be changed or that the phone number will be changed.
[0057] In the first embodiment, the authentication unit 102 performs a first authentication using the telephone number when the change requirement information indicates that the telephone number will not be changed, and performs a second authentication different from the first authentication when the change requirement information indicates that the telephone number will be changed. For example, the authentication unit 102 performs telephone number authentication as the first authentication when the change requirement information indicates that the telephone number will not be changed, and performs card scan authentication as the second authentication when the change requirement information indicates that the telephone number will be changed. In other words, the authentication unit 102 switches the authentication required from the user between the first and second authentications based on the change requirement information.
[0058] Furthermore, the authentication unit 102 may perform the first authentication based on conditions other than the change requirement information indicating that the phone number will not be changed. The authentication unit 102 is not required to perform the first authentication immediately simply because the change requirement information indicates that the phone number will not be changed. For example, the authentication unit 102 may perform the first authentication when the change requirement information indicates that the phone number will not be changed AND the user performs an operation for the first authentication (for example, the first authentication screen SC5 is displayed and the user performs an operation for the first authentication on it). This type of operation is also included in the authentication unit 102 performing the first authentication when the change requirement information indicates that the phone number will not be changed. Other conditions are not limited to screen displays or user operations. For example, other conditions may include a predetermined date and time arriving, a predetermined number of logins, or a predetermined amount of time elapsed since login.
[0059] Similarly, the authentication unit 102 may perform second authentication based on conditions other than the change requirement information indicating that the phone number should be changed. The authentication unit 102 is not required to perform second authentication immediately simply because the change requirement information indicates that the phone number should be changed. For example, the authentication unit 102 may perform second authentication only when the change requirement information indicates that the phone number should be changed and the user performs an operation for second authentication. This type of operation is also included in the authentication unit 102 performing second authentication when the change requirement information indicates that the phone number should be changed. Other conditions are not limited to user operations. For example, other conditions may include the arrival of a predetermined date and time, the number of logins reaching a predetermined number, or the elapsed time since login reaching a predetermined time.
[0060] Furthermore, the first and second authentications may be any combination. The combination of the first and second authentications is not limited to telephone number authentication and card scan authentication. For example, the first authentication may be an authentication that does not use a telephone number. Conversely, the second authentication may be an authentication that uses a telephone number. For example, the first authentication may be knowledge authentication and the second authentication may be biometric authentication or possession authentication. The first authentication may be biometric authentication and the second authentication may be knowledge authentication or possession authentication. The first authentication may be possession authentication and the second authentication may be knowledge authentication or biometric authentication. The first and second authentications may both be knowledge authentications, but the specific authentication methods may differ from each other. The first and second authentications may both be biometric authentications, but the specific authentication methods may differ from each other. The first and second authentications may both be possession authentications, but the specific authentication methods may differ from each other.
[0061] For example, if the authentication unit 102 indicates that the phone number will not be changed, it performs phone number authentication, which is an example of the first authentication, with the second user terminal 30B. The authentication unit 102 performs phone number authentication, which is an example of the first authentication, based on an incoming call from the second user terminal 30B, an outgoing call to the second user terminal 30B, or the sending of an SMS message to the second user terminal 30B. The authentication unit 102 may also perform phone number authentication, which is an example of the first authentication, by determining whether the phone number registered with the payment service matches the phone number of the second user terminal 30B. The authentication unit 102 may also perform phone number authentication, which is an example of the first authentication, with the first user terminal 30A.
[0062] For example, if the change requirement information indicates that the phone number needs to be changed, the authentication unit 102 performs card scan authentication, which is an example of second authentication, with the second user terminal 30B. The second user terminal 30B obtains the authentication information stored in the credit card using the short-range wireless communication function of the communication unit 33B and transmits it to the authentication server 10. The authentication unit 102 communicates with other computers, such as the card company, as needed to verify the validity of the authentication information obtained from the second user terminal 30B. If the authentication unit 102 has stored the information necessary for card scan authentication, it may perform second authentication without communicating with other computers. The authentication unit 102 may also perform other authentication as second authentication, such as authentication using the security code printed on the back of the credit card.
[0063] Furthermore, after the user selects button B41, the second user terminal 30B may transition to a screen that accepts input of a new phone number, and the user may enter the new phone number. Subsequently, the second user terminal 30B may transition to the second authentication screen SC6 and perform card scan authentication as the second authentication, or it may transition to the reading screen SC8 in the third embodiment described later and perform payment code authentication as the second authentication, or authentication may be performed by having the user enter both the old and new phone numbers on the same screen as the second authentication. If authentication for changing the device and authentication for changing the phone number are performed separately, it is troublesome for the user, but if the authentication system 1 can handle it with a single authentication called the second authentication, it can reduce the burden on the user, thereby improving user convenience while enhancing security.
[0064] Furthermore, the authentication unit 102 may perform authentication other than the first and second authentications. For example, the authentication unit 102 may perform login authentication, or it may perform authentication other than the first authentication, second authentication, and login authentication. The specific processing of each authentication may be the same as the processing employed in known authentications, or it may be a novel authentication as described in the third embodiment. In the first embodiment, the configuration in which the authentication unit 102 switches authentications according to the change requirement information is a novel configuration, but the specific flow of each authentication may be the same as a known flow.
[0065] [1-3-2. Functions implemented by the payment server] For example, the payment server 20 includes a data storage unit 200 and a payment unit 201. The data storage unit 200 is implemented by a storage unit 22. The payment unit 201 is implemented by a control unit 21.
[0066] [Data Storage Unit] The data storage unit 200 stores various data for settlement. For example, the data storage unit 200 stores the settlement database DB2.
[0067] Figure 6 shows an example of the payment database DB2 in the first embodiment. The payment database DB2 is a database that stores various information for payment. For example, the payment database DB2 stores user ID, login account, code ID, expiration date, payment method information, payment source information, and charge source information. The information stored in the payment database DB2 is not limited to the example in Figure 6. Other information may be stored in the payment database DB2. For example, the payment database DB2 may store telephone number, terminal ID, or payment service usage history. When the payment server 20 issues a code ID, the code ID of the payment server 20 is communicated to the authentication server 10 as needed.
[0068] Payment method information is information that can identify a payment method. For example, payment method information may include credit card numbers, electronic money numbers, bank account information, or point card numbers. Payment source information is information that can identify the payment method selected as the payment source. The payment source is the payment method used to pay for goods or services handled by the store. Charge source information is information that can identify the payment method selected as the charge source. The charge source is the payment method that serves as the source of funds for the charge.
[0069] The data stored in the data storage unit 200 is not limited to the examples above. The data storage unit 200 only needs to store data for payment. For example, the data storage unit 200 may store data necessary for displaying the login screen SC1, the telephone number authentication screen SC2, the code screen SC3, the change requirement screen SC4, the first authentication screen SC5, the second authentication screen SC6, or other screens. The data storage unit 200 may also store a store database containing various information about the store.
[0070] [Payment Department] The settlement unit 201 executes settlements in the settlement service. The processing performed by the settlement unit 201 may be the same as that of known settlement services. For example, when the settlement unit 201 receives a settlement request from the store terminal 40, it executes a settlement based on the settlement request. The settlement unit 201 obtains the payer information associated with the code ID included in the settlement request from the settlement database DB2, and executes a settlement of the payment amount included in the settlement request based on the payer information. The settlement unit 201 may also execute a settlement when it receives a settlement request from the first user terminal 30A or the second user terminal 30B.
[0071] [1-3-3. Functions implemented on the first user terminal] For example, the first user terminal 30A includes a data storage unit 300A, an operation reception unit 301A, and a display control unit 302A. The data storage unit 300A is implemented by a storage unit 32A. The operation reception unit 301A and the display control unit 302A are implemented by a control unit 31A.
[0072] [Data Storage Unit] The data storage unit 300A stores data necessary for the user to use the payment service. For example, the data storage unit 300A stores the payment application. If the user uses the payment service from another application or browser instead of the payment application, the data storage unit 300A stores the other application or browser. The data storage unit 300A may also store a phone number, code ID, terminal ID, payment service settings, or other information.
[0073] [Operation Reception Section] The operation reception unit 301A receives various user operations. For example, the operation reception unit 301A receives operations on the payment application. The operation reception unit 301A transmits data indicating the user's operation to the authentication server 10 or the payment server 20.
[0074] [Display Control Unit] The display control unit 302A displays various screens on the display unit 35A. For example, the display control unit 302A displays the login screen SC1, the telephone number authentication screen SC2, and the code screen SC3 on the display unit 35A. The display control unit 302A communicates with the authentication server 10 or the payment server 20 to receive display data for these screens and displays these screens on the display unit 35A based on the display data. The display data is the data necessary for displaying the screen. The display data may be data for the entire screen or data for a part of the screen. For example, the display data may be data in a markup language such as HTML, image data, text data, or other data.
[0075] [1-3-4. Functions implemented on the second user terminal] For example, the second user terminal 30B includes a data storage unit 300B, an operation reception unit 301B, and a display control unit 302B. The data storage unit 300B is implemented by a storage unit 32B. The operation reception unit 301B and the display control unit 302B are implemented by a control unit 31B.
[0076] [Data Storage Unit] The data storage unit 300B stores the data necessary for the user to use the payment service. For example, the data storage unit 300B stores the payment application. If the user uses the payment service from another application or browser instead of the payment application, the data storage unit 300B stores the other application or browser. The data storage unit 300B may also store a phone number, code ID, terminal ID, payment service settings, or other information.
[0077] [Operation Reception Section] The operation reception unit 301B receives various user operations. For example, the operation reception unit 301B receives operations on the payment application. The operation reception unit 301B transmits data indicating the user's operations to the authentication server 10 or the payment server 20.
[0078] [Display Control Unit] The display control unit 302B displays various screens on the display unit 35B. For example, the display control unit 302B displays the login screen SC1, the code screen SC3, the change requirement screen SC4, the first authentication screen SC5, and the second authentication screen SC6 on the display unit 35B. The display control unit 302B communicates with the authentication server 10 or the payment server 20 to receive display data for these screens and displays these screens on the display unit 35B based on the display data.
[0079] [1-3-5. Functions implemented on store terminals] For example, the store terminal 40 includes a data storage unit 400 and a payment request transmission unit 401. The data storage unit 400 is implemented by a storage unit 42. The payment request transmission unit 401 is implemented by a control unit 41.
[0080] [Data Storage Unit] The data storage unit 400 stores data necessary for store-side processing in the payment service. For example, the data storage unit 400 stores a database containing various information such as the prices of goods or services handled by the store. The data storage unit 400 may also store a store ID that can identify the store.
[0081] [Payment Request Transmission Section] The payment request transmission unit 401 sends a payment request to the authentication server 10. For example, when the store terminal 40 reads the payment code C30 with the reading unit 46, the payment request transmission unit 401 obtains a code ID from the payment code C30. The payment request transmission unit 401 sends a payment request to the authentication server 10 that includes information necessary for payment, such as the code ID, payment amount, and store ID. The payment request can be any request used in a well-known payment service.
[0082] [1-4. Processing performed by the authentication system of the first embodiment] Figure 7 shows an example of the processing performed by the authentication system 1 of the first embodiment. Figure 7 shows the processing performed by the authentication system 1 when a user logs in to the payment service from the second user terminal 30B. The processing in Figure 7 is performed by the control units 11 and 31B executing the programs stored in the storage units 12 and 32B, respectively. The same processing as in Figure 7 is performed when a user logs in to the payment service from the first user terminal 30A. The steps in Figure 7 are an example of the authentication switching method in the first embodiment.
[0083] As shown in Figure 7, when the second user terminal 30B starts the payment application, it performs a process with the authentication server 10 to display the login screen SC1 (S100). The second user terminal 30B may also communicate with the payment server 20 instead of the authentication server 10 to display the login screen SC1 on the display unit 35B. This is the same for subsequent processes. The second user terminal 30B performs login authentication with the authentication server 10 (S101). In S101, the authentication server 10 obtains the login account and password entered by the user from the second user terminal 30B and performs login authentication by determining whether or not they exist in the authentication database DB1.
[0084] The authentication server 10 determines whether a user with a new user ID has logged in (S102). Here, it is assumed that the authentication database DB1 stores the user's login history to the payment service. In S102, the authentication server 10 determines whether the user has logged in before based on the login history associated with the login account entered at the time of login. If it is determined in S102 that a user with a new user ID has logged in (S102:Y), the authentication server 10 performs telephone number authentication with the second user terminal 30B (S103), and this process ends. In S103, the authentication server 10 displays the telephone number authentication screen SC2 or the first authentication screen SC5 on the second user terminal 30B and performs telephone number authentication.
[0085] In S102, if it is determined that a user with a new user ID has logged in (S102:N), the authentication server 10 determines, based on the authentication database DB1, whether or not a phone number is registered with the payment service (S104). In S104, the authentication server 10 refers to the authentication database DB1 and determines whether or not a phone number is associated with the login account entered at the time of login. In S104, if it is determined that a phone number is not registered with the payment service (S104:N), the process proceeds to S103, and phone number authentication is performed.
[0086] In S104, if it is determined that the phone number is registered with the payment service (S104:Y), the authentication server 10 determines, based on the authentication database DB1, whether or not it is a login from a new terminal (S105). In S105, the authentication server 10 obtains the terminal ID from the second user terminal 30B and determines whether or not the terminal ID is associated with the login account entered at the time of login and stored in the authentication database DB1. In S105, if it is determined that it is not a login from a new terminal (S105:N), this process ends. In this case, the authentication server 10 notifies the payment server 20 that the second user terminal 30B is not a new terminal, and processing to display the code screen SC3 may be performed between the payment server 20 and the second user terminal 30B.
[0087] In S105, if it is determined that the login is from a new terminal (S105:Y), the second user terminal 30B performs a process to display the change requirement screen SC4 with the authentication server 10 (S106). The second user terminal 30B sends change requirement information based on the operation performed on the change requirement screen SC4 (S107). In S107, either button B40 or button B41 is selected. If the user performs another operation, the process corresponding to the other operation is executed, and this process ends. The authentication server 10 obtains the change requirement information from the second user terminal 30B (S108).
[0088] The authentication server 10 determines whether the change requirement information indicates that the phone number should be changed (S109). If, in S109, it is determined that the change requirement information indicates that the phone number should not be changed (S109:N), the authentication server 10 performs the first authentication with the second user terminal 30B (S110), and this process ends. In S110, the authentication server 10 displays the first authentication screen SC5 on the second user terminal 30B and performs phone number authentication as the first authentication with the second user terminal 30B.
[0089] In S109, if it is determined that the change requirement information indicates that the phone number should be changed (S109:Y), the authentication server 10 performs a second authentication with the second user terminal 30B (S111), and this process ends. In S111, the authentication server 10 displays the second authentication screen SC6 on the second user terminal 30B and performs card scan authentication as the second authentication with the second user terminal 30B.
[0090] [1-5. Summary of the First Embodiment] In the first embodiment, the authentication system 1 acquires change requirement information when a user who has used the payment service from a first user terminal 30A logs in to the service from a second user terminal 30B that is different from the first user terminal 30A. Based on the change requirement information, the authentication system 1 switches the authentication performed from the second user terminal 30B. By providing users with flexible authentication according to whether or not a change in phone number is necessary, the authentication system 1 can enhance security while improving user convenience. For example, as described in the first embodiment, authentication may be performed as a second authentication by having the user enter both the old and new phone numbers on the same screen. In this case, the authentication system 1 can complete the process with just one authentication, thus enhancing security while improving user convenience. For example, in addition to enhancing convenience for legitimate users, the authentication system 1 can also enhance security by preventing unauthorized users from logging in from different terminals.
[0091] Furthermore, authentication system 1 performs first authentication if the change requirement information indicates that the phone number will not be changed. Authentication system 1 performs second authentication if the change requirement information indicates that the phone number will be changed. As a result, authentication system 1 can appropriately use first and second authentication depending on whether or not the phone number is changed, thereby enhancing security while improving user convenience.
[0092] [2. Second Embodiment] A second embodiment, which is an example of an embodiment of the authentication system 1, authentication condition determination method, and program related to this disclosure, will be described. In the second embodiment, the same configuration as in the first embodiment will not be described. For example, the hardware configuration of the authentication system 1 may be the same as in the first embodiment.
[0093] [2-1. Overview of the Second Embodiment] In the second embodiment, similar to the first embodiment, we take the example of a case where a user changes from a first user terminal 30A to a second user terminal 30B. For example, as described in the first embodiment, card scan authentication may be performed when changing a phone number. In the second embodiment, we take the example of a case where only a specific credit card supports card scan authentication. In this case, if the user does not possess a credit card that supports card scan authentication, card scan authentication cannot be performed.
[0094] For example, even if a user possesses a credit card that supports card scan authentication, the communication unit 33B of the second user terminal 30B may not support short-range wireless communication. In this case, the user will not be able to perform card scan authentication. This is not limited to card scan authentication; other authentication methods are also affected. Some users may be unable to perform certain authentication methods. Therefore, in the second embodiment, the screen displayed on the second user terminal 30B changes depending on whether predetermined authentication conditions are met.
[0095] Figure 8 shows an example of a screen displayed on the second user terminal 30B in the second embodiment. For example, when a user logs in to the payment service from the second user terminal 30B, the second user terminal 30B displays the change requirement screen SC4, similar to that in the first embodiment, on the display unit 35B, as shown in the upper right of Figure 3. The display flow of the change requirement screen SC4 may be the same as in the first embodiment. The flow after the user selects button B40 may also be the same as in the first embodiment. When the user selects button B41, the authentication server 10 determines whether the authentication conditions for card scan authentication are met. Details of this determination method will be described later.
[0096] For example, if it is determined that the authentication conditions for card scan authentication are met, the second user terminal 30B displays the second authentication screen SC6 for card scan authentication on the display unit 35B, as shown in the lower left of Figure 8, similar to the first embodiment. If it is determined that the authentication conditions for card scan authentication are not met, the second user terminal 30B displays the alternative authentication screen SC7 on the display unit 35B, as shown in the lower right of Figure 8, for the user to perform an authentication other than card scan authentication.
[0097] Note that other authentication methods may be arbitrary. For example, other authentication methods may have different authentication conditions than those for specific credit cards and near-field communication functionality. In the example in the lower right of Figure 8, one-time password authentication is performed as an example of other authentication methods. The flow of one-time password authentication may be the same as the known flow. For example, a user may perform one-time password authentication by checking the one-time password in another application that issues one-time passwords and entering the one-time password into input form F70.
[0098] As described above, if the authentication system 1 of the second embodiment determines that the authentication conditions for card scan authentication are met, it displays the second authentication screen SC6 for card scan authentication on the second user terminal 30B. If the authentication system 1 determines that the authentication conditions for card scan authentication are not met, it displays the other authentication screen SC7 for one-time password authentication on the second user terminal 30B. In this way, the authentication system 1 can display different screens on the second user terminal 30B depending on whether or not the authentication conditions for card scan authentication are met, thereby enhancing security while improving user convenience. The details of the second embodiment will be described below.
[0099] [2-2. Functions realized in the authentication system of the second embodiment] Figure 9 shows an example of the functions implemented in the authentication system 1 of the second embodiment. Although some of the functions described in the first embodiment are not shown in Figure 9, the authentication system 1 of the second embodiment may include the functions described in the first embodiment. The components implemented in the authentication system 1 of the second embodiment can be configured by combining them into a single device or by further distributing them among multiple devices.
[0100] Furthermore, the authentication system 1 of the second embodiment does not necessarily have to include the function described in the first embodiment (the function of switching authentication according to the information on whether or not a change is necessary). For example, the authentication system 1 of the second embodiment may determine whether the authentication conditions are met regardless of whether or not the phone number is changed. The authentication system 1 of the second embodiment does not have to include the function described in the first embodiment, and telephone number authentication may not be performed at all, nor may the phone number be registered with the payment service.
[0101] As described above, an embodiment of the authentication system 1 that includes the functions described in the second embodiment but does not include the functions described in the first embodiment is within the scope of this disclosure. An embodiment of the authentication system 1 that includes both the functions described in the first embodiment and the functions described in the second embodiment is also, of course, within the scope of this disclosure. These points will be naturally understood by those skilled in the art from the description in this disclosure.
[0102] [2-2-1. Functions implemented by the authentication server] For example, the authentication server 10 includes a data storage unit 100, an authentication unit 102, a user information acquisition unit 103, an authentication condition determination unit 104, an authentication content display unit 105, and an other authentication content display unit 106.
[0103] [Data Storage Unit] The data storage unit 100 may be the same as in the first embodiment. In the second embodiment, the data storage unit 100 stores data necessary for determining the authentication conditions. For example, the authentication database DB1 may store ownership information indicating whether or not a user possesses a specific credit card. The ownership information may be stored in a database other than the authentication database DB1, a computer other than the authentication server 10, or an information storage medium. The data storage unit 100 may also store data necessary for displaying the authentication screen SC7.
[0104] [User Information Acquisition Unit] The user information acquisition unit 103 acquires user information relating to users who use the payment service. In the second embodiment, as in the first embodiment, the payment service is an example of a predetermined service. Therefore, the part that says "payment service" can be read as any other service. The authentication system 1 of the second embodiment is also applicable to any service such as e-commerce services.
[0105] User information is information about a user that is used to determine whether or not the authentication conditions are met. For example, user information may be information associated with a user ID (information that can be searched based on the user ID), or it may be information obtained from the first user terminal 30A or the second user terminal 30B. In the second embodiment, an example is given where possession information indicating whether or not a user possesses a particular credit card corresponds to user information. Possession information may be payment method information stored in the payment database DB2, or it may be information different from the payment method information. Possession information may be the card number of a particular credit card, identification information of a function attached to a particular credit card (e.g., electronic money or points), or other information.
[0106] In the second embodiment, we take the case where the information held is stored in the authentication database DB1 as an example. For example, when a user logs in to the payment service, the user information acquisition unit 103 refers to the authentication database DB1 and acquires the information held by that user as user information, which is associated with the user ID of that user. The user information acquisition unit 103 may also acquire the information held as user information from other databases other than the authentication database DB1 (for example, the payment database DB2), other computers other than the authentication server 10 (for example, the payment server 20, the first user terminal 30A, the second user terminal 30B, or a computer of another service that cooperates with the payment service), or an information storage medium.
[0107] Note that user information may be other information besides the information held. For example, user information may be information about the payment methods of a user who is not registered with the payment service. In this case, user information may be stored in the database of a service other than the payment service. For example, the user information acquisition unit 103 may acquire user information from the computer of a card company that issued a credit card compatible with card scan authentication. The user information acquisition unit 103 may acquire user information from the computer of a company that manages functions (e.g., electronic money or points) associated with a credit card compatible with card scan authentication.
[0108] Furthermore, user information is not limited to information about the payment methods held by the user. For example, user information may indicate whether or not the communication unit 33B of the second user terminal 30B supports short-range wireless communication. In this case, the second user terminal 30B transmits user information indicating whether or not the communication unit 33B supports short-range wireless communication to the authentication server 10. The user information acquisition unit 103 acquires user information from the second user terminal 30B. If other functions other than short-range wireless communication (for example, a shooting function by the shooting unit 36B) are required for a particular authentication, the user information acquisition unit 103 may acquire user information from the second user terminal 30B indicating whether or not it has such other functions.
[0109] For example, if a user is required to register authentication information used for a particular authentication in advance, that authentication information may correspond to user information. This authentication information may be any information, such as a password, passcode, facial photograph, fingerprint pattern, secret question, answer to a predetermined question, or other authentication information. This authentication information may be stored in advance in the authentication database DB1. The user information acquisition unit 103 acquires this authentication information stored in the authentication database DB1 as user information. Alternatively, the user information acquisition unit 103 may acquire information indicating whether or not the authentication information has been registered in advance as user information.
[0110] [Authentication Condition Determination Unit] The authentication condition determination unit 104 determines whether the user information satisfies predetermined authentication conditions related to authentication in the payment service. Authentication conditions are the conditions for the authentication unit 102 to perform authentication. In other words, authentication conditions are conditions that indicate whether the logged-in user is in an environment where authentication can be performed. For example, if the user needs to possess a specific item (e.g., a specific credit card) for authentication, the authentication condition is that the user possesses that item. If the user needs to be registered in the payment service for authentication, the authentication condition is that the user is registered in the payment service. If the second user terminal 30B needs to have a specific function (e.g., a short-range wireless communication function or a camera function) for authentication, the authentication condition is that the second user terminal 30B has that function.
[0111] In the second embodiment, we take the example of a case where a particular credit card supports card scan authentication. Therefore, the user possessing that particular credit card constitutes an authentication condition. The authentication condition determination unit 104 determines whether or not the user possesses that particular credit card based on the possession information obtained as user information. If the authentication condition determination unit 104 determines that the user does not possess that particular credit card, it determines that the user information does not satisfy the authentication condition. If the authentication condition determination unit 104 determines that the user possesses that particular credit card, it determines that the user information satisfies the authentication condition.
[0112] The determination method of the authentication condition determination unit 104 is not limited to the above example. The determination method of the authentication condition determination unit 104 can be any method that is appropriate to the authentication conditions. For example, the authentication condition determination unit 104 may determine whether the user information satisfies the authentication conditions by determining, based on the user information, whether the communication unit 33B of the second user terminal 30B supports short-range wireless communication. If the user information does not indicate that the communication unit 33B supports short-range wireless communication, the authentication condition determination unit 104 determines that the user information does not satisfy the authentication conditions. If the user information indicates that the communication unit 33B supports short-range wireless communication, the authentication condition determination unit 104 determines that the user information satisfies the authentication conditions.
[0113] For example, the authentication condition determination unit 104 may determine whether user information satisfies the authentication conditions by determining, based on user information, whether the user has registered specific authentication information with the payment service. If the user information does not indicate that the user has registered specific authentication information with the payment service, the authentication condition determination unit 104 determines that user information does not satisfy the authentication conditions. If the user information indicates that the user has registered specific authentication information with the payment service, the authentication condition determination unit 104 determines that user information satisfies the authentication conditions. User information may also be the specific authentication information itself. In this case, the authentication condition determination unit 104 only needs to determine whether user information, which is the specific authentication information, satisfies the authentication conditions by determining whether user information is registered with the payment service.
[0114] In the second embodiment, we take as an example the case in which the authentication server 10 executes the processing of the authentication content display unit 105 and the other authentication content display unit 106 based on the determination result of the authentication condition determination unit 104. However, the authentication server 10 only needs to execute a predetermined process based on the determination result of the authentication condition determination unit 104. The predetermined process may be only the processing of the authentication content display unit 105, or only the processing of the other authentication content display unit 106. The predetermined process may be any other process. For example, the authentication server 10 may execute a predetermined process by displaying a screen unrelated to authentication on the second user terminal 30B based on the determination result of the authentication condition determination unit 104. The authentication server 10 may also execute a predetermined process by storing the determination result of the authentication condition determination unit 104 in the authentication database DB1.
[0115] [Authentication Content Display Section] The authentication content display unit 105 does not display the second authentication screen SC6 on the user's second user terminal 30B if it determines that the user information does not meet the authentication conditions, and displays the second authentication screen SC6 on the second user terminal 30B if it determines that the user information meets the authentication conditions. The second authentication screen SC6 is an example of authentication content. Therefore, where it is written as "second authentication screen SC6", it can be read as "authentication content". The authentication content can be any content displayed for authentication, and is not limited to the second authentication screen SC6. The authentication content may be any screen other than the second authentication screen SC6, or it may not be the entire screen, but rather a component of the screen (a part of the screen, for example, a menu, window, popup, modal, button, panel, icon, or other component).
[0116] For example, if the authentication content display unit 105 determines that the user information meets the authentication conditions, it sends the display data for the second authentication screen SC6 to the second user terminal 30B, thereby displaying the second authentication screen SC6 on the second user terminal 30B. If the authentication content display unit 105 determines that the user information does not meet the authentication conditions, it does not send the display data for the second authentication screen SC6 to the second user terminal 30B. If the authentication content display unit 105 determines that the user information does not meet the authentication conditions, it may send other data, such as an error message, to the second user terminal 30B.
[0117] The authentication content display unit 105 may display the second authentication screen SC6 on the first user terminal 30A instead of the second user terminal 30B. The authentication content display unit 105 may display the second authentication screen SC6 on at least one of the first user terminal 30A and the second user terminal 30B. In the second embodiment, when the first user terminal 30A and the second user terminal 30B are not specifically distinguished, they are simply referred to as user terminal 30. The authentication content display unit 105 may not display the second authentication screen SC6 on the user terminal 30 if it is determined that the user information does not meet the authentication conditions, and may display the second authentication screen SC6 on the user terminal 30 if it is determined that the user information meets the authentication conditions.
[0118] [Other Authentication Content Display Section] If the other authentication content display unit 106 determines that the user information does not meet the authentication conditions, it displays an other authentication screen SC7 on the user terminal 30 (for example, a second user terminal 30B) that relates to an authentication other than the one being judged. The other authentication screen SC7 is an example of other authentication content. Therefore, where it is written as "other authentication screen SC7", it can be read as "other authentication content". The other authentication content can be any content for other authentication and is not limited to the other authentication screen SC7. The other authentication content may be any screen other than the other authentication screen SC7, or it may not be the entire screen but a component of the screen (a part of the screen, for example, a menu, window, popup, modal, button, panel, icon, or other component).
[0119] For example, if the other authentication content display unit 106 determines that the user information does not meet the authentication conditions, it sends the display data for the other authentication screen SC7 to the second user terminal 30B, thereby displaying the other authentication screen SC7 on the second user terminal 30B. If the other authentication content display unit 106 determines that the user information meets the authentication conditions, it does not send the display data for the other authentication screen SC7 to the second user terminal 30B. The authentication content display unit 105 may also display the other authentication screen SC7 on the first user terminal 30A instead of the second user terminal 30B. The other authentication screen SC7 can be any screen for other authentication that can be performed even if the user information does not meet the authentication conditions, and is not limited to a one-time password authentication screen like the one shown in the lower right of Figure 8.
[0120] [Authentication Department] The authentication unit 102 may be the same as in the first embodiment. In the second embodiment, the authentication unit 102 performs authentication after the authentication condition determination unit 104 has performed a determination. For example, the authentication unit 102 performs card scan authentication after the authentication condition determination unit 104 has performed a determination and the second authentication screen SC6 has been displayed. The processing for card scan authentication may be the same as in the first embodiment. The authentication unit 102 performs one-time password authentication after the authentication condition determination unit 104 has performed a determination and the other authentication screen SC7 has been displayed. The flow of one-time password authentication may be the same as a known flow.
[0121] In the second embodiment, card scan authentication is described as an example of authentication in which authentication conditions are set. The authentication in which authentication conditions are set may be any authentication other than card scan authentication. For example, the authentication in which authentication conditions are set may be authentication by photographing an identification document, payment code authentication as described in the third embodiment below, or other possession authentication. The authentication in which authentication conditions are set may be knowledge authentication which requires prior registration of authentication information, or biometric authentication which requires prior registration of biometric information. The authentication in which authentication conditions are set may be performed on the first user terminal 30A or the second user terminal 30B, rather than on the authentication server 10.
[0122] In the second embodiment, one-time password authentication is described as an example of authentication other than authentication for which authentication conditions are set. The other authentication may be any authentication other than one-time password authentication. For example, the other authentication may be telephone number authentication, authentication using a password different from the login authentication, other knowledge authentication, possession authentication other than card scan authentication, or biometric authentication. The other authentication may be performed on the first user terminal 30A or the second user terminal 30B instead of the authentication server 10.
[0123] [2-2-2. Functions implemented by the payment server] The functions of the payment server 20 may be the same as those of the first embodiment.
[0124] [2-2-3. Functions implemented on the first user terminal] The functions of the first user terminal 30A may be the same as those of the first embodiment.
[0125] [2-2-4. Functions implemented on the second user terminal] The functions of the second user terminal 30B may be the same as those of the first embodiment.
[0126] [2-2-5. Functions implemented on store terminals] The functions of the store terminal 40 may be the same as those of the first embodiment.
[0127] [2-3. Processing performed by the authentication system of the second embodiment] Figures 10 and 11 show an example of processing performed by the authentication system 1 of the second embodiment. Figures 10 and 11 show the processing performed by the authentication system 1 when a user logs in to the payment service from the second user terminal 30B. The processing in Figures 10 and 11 is performed by the control units 11 and 31B executing the programs stored in the storage units 12 and 32B, respectively. The same processing as in Figures 10 and 11 is performed when a user logs in to the payment service from the first user terminal 30A. The steps in Figures 10 and 11 are an example of the authentication condition determination method in the second embodiment.
[0128] As shown in Figure 10, the processes S200 to S210 are the same as the processes S100 to S110, respectively. Figure 10 shows an example in which the authentication system 1 of the second embodiment includes the functions of the first embodiment. However, if the authentication system 1 of the second embodiment does not include the functions of the first embodiment, if the determination in S205 is affirmative, the processes S206 to S210 may not be executed, and the process may proceed to S211. Note that the determination in S205 in the second embodiment does not necessarily have to determine whether or not it is a login from a new terminal. For example, it may be authentication when using a payment service (e.g., authentication of a newly registered user), or authentication related to the use of a function in a payment service (e.g., withdrawal function, or user authentication for changing a phone number).
[0129] In S209, if it is determined that the change requirement information indicates that the phone number should be changed (S209:Y), the process moves to Figure 11, where the authentication server 10 refers to the authentication database DB1 and obtains the ownership information associated with the user ID of the logged-in user as user information (S211). The authentication server 10 determines whether the user information satisfies the authentication conditions (S212). In S212, the authentication server 10 determines whether the ownership information indicates that the user possesses a specific credit card that is compatible with card scan authentication.
[0130] In S212, if it is determined that the user information meets the authentication conditions (S212:Y), the authentication server 10 executes a process to display the second authentication screen SC6 for card scan authentication with the second user terminal 30B (S213). The second authentication screen SC6 displayed in S213 is an example of authentication content. The authentication server 10 performs card scan authentication with the second user terminal 30B (S214), and this process ends. The process in S214 may be the same as in S111.
[0131] In S212, if it is determined that the user information does not meet the authentication conditions (S212:N), the authentication server 10 executes a process to display the other authentication screen SC7 for one-time password authentication with the second user terminal 30B (S215). The other authentication screen SC7 displayed in S215 is an example of other authentication content. The authentication server 10 performs one-time password authentication with the second user terminal 30B (S216), and this process ends. In S216, the second user terminal 30B sends the one-time password entered by the user in input form F70 to the authentication server 10. The authentication server 10 cooperates with other server computers that issue one-time passwords and verifies the validity of the one-time password received from the second user terminal 30B.
[0132] [2-4. Summary of the second embodiment] The authentication system 1 of the second embodiment acquires user information. The authentication system 1 determines whether the user information satisfies the authentication conditions. As a result, the authentication system 1 can determine whether the user information satisfies the authentication conditions, thereby improving user convenience. For example, the authentication system 1 can execute predetermined processing depending on whether the user information satisfies the authentication conditions, thus enabling flexible processing depending on whether the user information satisfies the authentication conditions. The authentication system 1 can also use different authentication methods depending on whether the user information satisfies the authentication conditions.
[0133] Furthermore, if the authentication system 1 determines that the user information does not meet the authentication conditions, it will not display the second authentication screen SC6 on the user terminal 30, and will display the second authentication screen SC6 on the user terminal 30 if it determines that the user information meets the authentication conditions. In this way, the authentication system 1 can control whether or not to display the second authentication screen SC6 depending on whether or not the user information meets the authentication conditions, thereby improving user convenience. For example, the authentication system 1 can prevent the display of the second authentication screen SC6 for card scan authentication to users who cannot perform card scan authentication because they do not meet the authentication conditions.
[0134] Furthermore, if the authentication system 1 determines that the user information does not meet the authentication conditions, it displays an alternative authentication screen SC7 on the user terminal 30. This allows the authentication system 1 to control whether or not to display the alternative authentication screen SC7 depending on whether or not the user information meets the authentication conditions, thereby improving user convenience. For example, if a user cannot perform card scan authentication because they do not meet the authentication conditions, the authentication system 1 can display an alternative authentication screen SC7 for one-time password authentication, which is different from card scan authentication, thereby allowing the user to perform one-time password authentication.
[0135] [3. Third Embodiment] A third embodiment, which is an example of an embodiment of the authentication system 1, authentication method, and program related to this disclosure, will be described. In the third embodiment, the same configuration as in the first or second embodiment will not be described. For example, the hardware configuration of the authentication system 1 may be the same as in the first embodiment.
[0136] [3-1. Overview of the Third Implementation] In the third embodiment, similar to the first and second embodiments, an example is given where the user changes from the first user terminal 30A to the second user terminal 30B. However, in the third embodiment, an example is given where, when changing the telephone number, payment code authentication is performed by reading the payment code C30 displayed on the first user terminal 30A with the second user terminal 30B, rather than card scan authentication.
[0137] Figure 12 shows an example of a screen displayed on the second user terminal 30B in the third embodiment. For example, when a user logs in to the payment service from the second user terminal 30B, the second user terminal 30B displays the change requirement screen SC4, similar to that in the first or second embodiment, on the display unit 35B, as shown in the upper right of Figure 3. The display flow of the change requirement screen SC4 may be the same as in the first or second embodiment. The flow after the user selects button B40 may also be the same as in the first or second embodiment.
[0138] For example, when the user selects button B41, the second user terminal 30B activates the imaging unit 36B and displays a reading screen SC8 on the display unit 35B for reading the payment code C30 with the imaging unit 36B. The reading screen SC8 displays a captured image I81 generated by the imaging unit 36B, along with a message M80 prompting the user to display the payment code C30 on the first user terminal 30A. As shown in the lower left of Figure 3, the user operates the first user terminal 30A to display the code screen SC3 on the display unit 35A.
[0139] If a device change occurs, the SIM card in the first user terminal 30A may be removed or deactivated. If the first user terminal 30A cannot connect to a public communication line, it may communicate with the authentication server 10 and the payment server 20 using other communication means such as wireless LAN, and display the code screen SC3 on the display unit 35A. The first user terminal 30A may also store an offline code ID in advance without any communication and display the code screen SC3 on the display unit 35A.
[0140] For example, when a user displays the code screen SC3 on the first user terminal 30A, the second user terminal 30B's scanning unit 36B reads the payment code C30. The payment code C30 can be a barcode or a two-dimensional code, and it is acceptable to read at least one of them. The second user terminal 30B transmits the code ID obtained from the payment code C30 to the authentication server 10. When the authentication server 10 obtains the code ID from the second user terminal 30B, it verifies the validity of the code ID. After verifying the validity of the code ID, the authentication server 10 performs payment code authentication by determining whether the user ID of the user logged in from the second user terminal 30B matches the user ID associated with the code ID.
[0141] As described above, the authentication system 1 of the third embodiment performs payment code authentication based on the payment code C30 used for payment. This allows the user to perform payment code authentication by performing an operation that they are already familiar with for displaying the payment code C30 (for example, launching a payment application), thus enhancing user convenience. Furthermore, since the payment code C30 can also be used for authentication, the cost of developing an authentication code can be saved. Details of the third embodiment will be described below.
[0142] [3-2. Functions realized in the authentication system of the third embodiment] Figure 13 shows an example of the functions implemented in the authentication system 1 of the third embodiment. Although some functions described in the first or second embodiment are not shown in Figure 13, the authentication system 1 of the third embodiment may include the functions described in the first or second embodiment. The components implemented in the authentication system 1 of the third embodiment can be configured by combining them into a single device or by further distributing them among multiple devices.
[0143] Furthermore, the authentication system 1 of the third embodiment does not have to include at least one of the functions described in the first embodiment (a function to switch authentication according to change necessity information) and the functions described in the second embodiment (a function to determine authentication conditions). The authentication system 1 of the third embodiment does not have to include the functions described in the first embodiment, and telephone number authentication may not be performed at all, nor may telephone numbers be registered with the payment service. The authentication system 1 of the third embodiment does not have to include the functions described in the second embodiment, and does not have to perform any determination of authentication conditions.
[0144] As described above, an embodiment of the authentication system 1 that includes the function described in the third embodiment but does not include at least one of the functions described in the first embodiment and the functions described in the second embodiment is within the scope of this disclosure. An embodiment of the authentication system 1 that includes at least one of the above and the function described in the third embodiment is also, of course, within the scope of this disclosure. These points will be naturally understood by those skilled in the art from the description in this disclosure.
[0145] [3-2-1. Functions implemented by the authentication server] For example, the authentication server 10 includes a data storage unit 100, an authentication unit 102, a read information acquisition unit 107, a first user information acquisition unit 108, and a second user information acquisition unit 109. Each of the read information acquisition unit 107, the first user information acquisition unit 108, and the second user information acquisition unit 109 is implemented by a control unit 11.
[0146] [Data Storage Unit] The data storage unit 100 may be the same as that of the first or second embodiment. For example, the data storage unit 100 stores data for payment code authentication. In the third embodiment, the user ID and code ID stored in the authentication database DB1 are used for payment code authentication.
[0147] [Information Acquisition Unit] The reading information acquisition unit 107 acquires the code ID read from the payment code C30 when the payment code C30 displayed on the first user terminal 30A of a user using the payment service is read by a second user terminal 30B that is different from the first user terminal 30A. For example, the reading information acquisition unit 107 acquires the code ID from the second user terminal 30B. The reading information acquisition unit 107 may also acquire the code ID via a computer other than the second user terminal 30B.
[0148] In the third embodiment, the code ID is an example of read information. Therefore, wherever "code ID" is written, it can be read as "read information." The read information is information read from the payment code C30. The read information can also be described as information encoded in the payment code C30. The read information is not limited to the code ID and can be any information usable for both payment and payment code authentication. For example, the read information may be information for offline payment, the URL of the payment service, other authentication information other than the code ID (e.g., user ID or login account), terminal ID, or other information.
[0149] [First User Information Acquisition Unit] The first user information acquisition unit 108 acquires a user ID based on the code ID acquired as read information. The user ID acquired by the first user information acquisition unit 108 is an example of first user information. Therefore, any section describing the user ID acquired by the first user information acquisition unit 108 can be read as referring to first user information. First user information is information about a user who logged in from the first user terminal 30A. For example, first user information is the user identification information of a user who logged in from the first user terminal 30A.
[0150] Furthermore, the first user information is not limited to the user ID. The first user information may be any information used for payment code authentication. For example, the first user information may be the login account of the user currently logged in from the first user terminal 30A. The first user information is not limited to user identification information, such as the user ID. The first user information may be information associated with user identification information (information that can be searched from user identification information). For example, the first user information may be a telephone number, terminal ID, payment method information, or other information associated with user identification information.
[0151] In the third embodiment, the first user information acquisition unit 108 acquires the user ID associated with the code ID acquired as read information as first user information. For example, the first user information acquisition unit 108 may request the payment server 20 to provide the user ID associated with the code ID acquired as read information. Based on the request from the authentication server 10, the payment server 20 acquires the user ID associated with the code ID from the payment database DB2 and sends it to the authentication server 10 as first user information. The first user information acquisition unit 108 acquires the user ID from the payment server 20 as first user information. If the code ID and user ID are associated with each other in the authentication database DB1, the first user information acquisition unit 108 may acquire the user ID associated with the code ID acquired as read information from the authentication database DB1.
[0152] For example, the authentication server 10 does not need to manage the association between the code ID and the user ID. In this case, the first user information acquisition unit 108 obtains the user ID associated with the code ID obtained as read information from a computer (e.g., the payment server 20) that manages the association between the code ID and the user ID. In this case, the second user terminal 30B may send the code ID read from the payment code C30 to the payment server 20. The payment server 20 may identify the user ID associated with the code ID based on the payment database DB2 and send the user ID to the authentication server 10. The first user information acquisition unit 108 obtains the user ID sent by the payment server 20 as first user information.
[0153] [Second User Information Acquisition Unit] The second user information acquisition unit 109 acquires the user ID of the user who logged in to the payment service from the second user terminal 30B. The user ID acquired by the second user information acquisition unit 109 is an example of second user information. Therefore, any section describing the user ID acquired by the second user information acquisition unit 109 can be read as referring to second user information. Second user information is information about the user who logged in from the second user terminal 30B. For example, second user information is the user identification information of the user who logged in from the second user terminal 30B.
[0154] Furthermore, the second user information is not limited to the user ID. The second user information may be any information used for payment code authentication. For example, the second user information may be the login account of the user logged in from the second user terminal 30B. The second user information is not limited to user identification information, such as the user ID. The second user information may be information associated with user identification information (information that can be searched from user identification information). For example, the second user information may be a telephone number, terminal ID, payment method information, or other information associated with user identification information.
[0155] In the third embodiment, the second user information acquisition unit 109 acquires a user ID as second user information based on the result of the login authentication performed from the second user terminal 30B. For example, the second user information acquisition unit 109 refers to the authentication database DB1 and acquires a user ID associated with the login account entered in the login authentication performed from the second user terminal 30B.
[0156] For example, if the session between the authentication server 10 and the second user terminal 30B is managed by a session ID after login authentication is performed, the second user information acquisition unit 109 may acquire a user ID as second user information based on the session ID. The session ID may be stored in the authentication database DB1. The second user information acquisition unit 109 acquires the user ID associated with the session ID acquired from the second user terminal 30B as second user information.
[0157] [Authentication Department] The authentication unit 102 may be the same as that of the first or second embodiment. When read information is obtained, the authentication unit 102 performs payment code authentication using the payment code C30. For example, when read information is obtained, the authentication unit 102 performs payment code authentication based on the user ID of the user who logged in to the payment service from the first user terminal 30A and the user ID of the user who logged in to the payment service from the second user terminal 30B. If these user IDs do not match, the authentication unit 102 determines that payment code authentication has failed, and if these user IDs match, it determines that payment code authentication has succeeded.
[0158] In the third embodiment, the authentication unit 102 performs payment code authentication based on the user ID obtained by the first user information acquisition unit 108 and the user ID obtained by the second user information acquisition unit 109 when read information is acquired. The authentication unit 102 may determine that payment code authentication has failed if these user IDs do not match, and determine that payment code authentication has succeeded if these user IDs match.
[0159] The method for performing payment code authentication is not limited to the above example. The authentication unit 102 only needs to perform payment code authentication when read information is obtained. For example, the authentication unit 102 may use the read information itself for payment code authentication. The authentication unit 102 may also perform payment code authentication by determining whether or not a code ID, which is an example of read information, is stored in the authentication database DB1. If the code ID, which is an example of read information, is not stored in the authentication database DB1, the authentication unit 102 may determine that payment code authentication has failed, and if the code ID is stored in the authentication database DB1, it may determine that payment code authentication has succeeded.
[0160] [3-2-2. Functions implemented by the payment server] The functions of the payment server 20 may be the same as those of the first or second embodiment. In the third embodiment, an example is given where the second user terminal 30B reads the payment code C30 displayed on the first user terminal 30A and sends the reading information to the authentication server 10, but the second user terminal 30B may also send the reading information to the payment server 20. The payment server 20 refers to the payment database DB2 and identifies the user ID corresponding to the reading information. The payment server 20 sends the identified user ID to the authentication server 10. The authentication server 10 may perform payment code authentication based on the user ID received from the payment server 20.
[0161] [3-2-3. Functions implemented on the first user terminal] The functions of the first user terminal 30A may be the same as those of the first or second embodiment.
[0162] [3-2-4. Functions implemented on the second user terminal] The functions of the second user terminal 30B may be the same as those of the first or second embodiment. In the third embodiment, the display control unit 302B of the second user terminal 30B displays the reading screen SC8 on the display unit 35B.
[0163] [3-2-5. Functions implemented on store terminals] The functions of the store terminal 40 may be the same as those of the first or second embodiment.
[0164] [3-3. Processing performed by the authentication system of the third embodiment] Figures 14 and 15 show an example of the processing performed by the authentication system 1 of the third embodiment. Figures 14 and 15 show the processing performed by the authentication system 1 when a user logs in to the payment service from the second user terminal 30B. The processing in Figures 14 and 15 is performed by the control units 11, 31A, and 31B executing the programs stored in the storage units 12, 32A, and 32B, respectively. The steps in Figures 14 and 15 are an example of the authentication method in the third embodiment.
[0165] As shown in Figure 14, the processes in S300 to S310 are the same as those in S100 to S110. Figure 14 shows an example in which the authentication system 1 of the third embodiment includes the functions of the first embodiment. However, if the authentication system 1 of the third embodiment does not include the functions of the first embodiment, if the determination in S305 is affirmative, the processes in S306 to S310 may not be executed, and the process may proceed to S311.
[0166] In S309, if it is determined that the change information indicates that the phone number needs to be changed (S309:Y), the process moves to Figure 15, and the authentication server 10 performs a process to display the reading screen SC8 with the second user terminal 30B (S311). In S311, the authentication server 10 transmits the display data for the reading screen SC8 to the second user terminal 30B. Based on the display data for the reading screen SC8, the second user terminal 30B activates the imaging unit 36B to display the reading screen SC8 on the display unit 35B. The user operates the first user terminal 30A to launch the payment application.
[0167] When the first user terminal 30A starts the payment application, it performs a process to display the code screen SC3 with the payment server 20 (S312). In S312, the first user terminal 30A performs login authentication with the payment server 20. If the user is already logged in, login authentication does not need to be performed. The payment server 20 issues a code ID, determines its expiration date, associates it with the user ID and login account of the user who logged in from the first user terminal 30A, and stores the code ID and expiration date in the payment database DB2. When the first user terminal 30A receives the display data for the code screen SC3 from the payment server 20, it displays the code screen SC3 on the display unit 35A. The display data for the code screen SC3 may be sent by the authentication server 10 instead of the payment server 20.
[0168] The second user terminal 30B reads the payment code C30 displayed on the code screen SC3 of the first user terminal 30A using the imaging unit 36B (S313). The second user terminal 30B transmits the code ID obtained from the payment code C30 to the authentication server 10 as read information (S314). The authentication server 10 obtains the code ID from the second user terminal 30B as read information (S315). The authentication server 10 transmits the code ID to the payment server 20 and obtains the user ID associated with the code ID from the payment server 20 (S316). The authentication server 10 obtains the user ID of the logged-in user from the second user terminal 30B (S317). The authentication server 10 performs payment code authentication based on the user ID obtained in S316 and the user ID obtained in S317 (S318), and this process ends. Furthermore, the process of obtaining the user ID of the logged-in user performed in S317 may include, for example, the process of obtaining the user ID of the logged-in user from the second user terminal 30B via the payment server 20. Specifically, the second user terminal 30B may be authenticated by the payment server 20, and the authentication server 10 may obtain the user ID of the logged-in second user terminal 30B from the payment server 20. Also, the process of obtaining the user ID associated with the code ID performed in S316 may be performed on the authentication server 10. In this case, the code ID, expiration date, and corresponding user ID are pre-confirmed from the payment server 20. Moreover, the authentication performed in S318 may be performed on the payment server 20.
[0169] [3-4. Summary of the Third Embodiment] The authentication system 1 of the third embodiment acquires read information from the payment code C30 when the payment code C30 used in the payment service, displayed on the first user terminal 30A of a user using the payment service, is read by a second user terminal 30B that is different from the first user terminal 30A. When the authentication system 1 acquires read information, it performs payment code authentication using the payment code. As a result, the authentication system 1 can improve user convenience because the user can perform payment code authentication by performing an operation that they are familiar with for displaying the payment code C30 (for example, the operation of launching the payment app). The authentication system 1 can also use the payment code C30 used for payment for authentication when changing devices, etc., so there is no need to issue an authentication code. As a result, the authentication system 1 can reduce the development cost for implementing the authentication function.
[0170] Furthermore, the authentication system 1 obtains second user information regarding the user who logged into the payment service from the second user terminal 30B. When the read information is obtained, the authentication system 1 performs payment code authentication based on the first user information regarding the user who logged into the payment service from the first user terminal 30A and the second user information. This allows the authentication system 1 to enhance security in the payment service by using the payment code C30.
[0171] Furthermore, the authentication server 10 includes an authentication unit 102, a read information acquisition unit 107, a second user information acquisition unit 109, and a first user information acquisition unit 108. When read information is acquired, the authentication server 10 performs payment code authentication based on the first user information acquired by the first user information acquisition unit 108 and the second user information. The authentication server 10 can complete payment code authentication quickly.
[0172] [4. Variant] This disclosure is not limited to the first to third embodiments described above. This disclosure may be modified as appropriate without departing from the spirit of this disclosure. Hereafter, variations relating to each of the first to third embodiments will be described.
[0173] [4-1. Modifications relating to the first embodiment] Figure 16 shows an example of a function realized by a modified version of the first embodiment. For example, the authentication server 10 includes a user information acquisition unit 103, a function restriction unit 110, a restriction release unit 111, a second authentication proposal unit 112, and a second authentication content display unit 113. Each of the user information acquisition unit 103, the function restriction unit 110, the restriction release unit 111, the second authentication proposal unit 112, and the second authentication content display unit 113 is realized by the control unit 11.
[0174] [Variation 1-1] For example, as explained to some extent in the first embodiment, if the change requirement information indicates that the phone number will not be changed, the authentication unit 102 may perform the same authentication as the authentication performed using the phone number on the first user terminal 30A as the first authentication. For example, if the change requirement information indicates that the phone number will not be changed, and the user performs the operation for the first authentication, the authentication unit 102 may perform the same authentication as the authentication performed using the phone number on the first user terminal 30A as the first authentication. The authentication performed using the phone number on the first user terminal 30A is a phone number authentication performed from the first user terminal 30A. That is, the authentication performed using the phone number on the first user terminal 30A is an authentication to confirm the phone number of the first user terminal 30A (the phone number that the user also uses on the second user terminal 30B).
[0175] In the example shown in Figure 2, the telephone number authentication performed from the telephone number authentication screen SC2 corresponds to the authentication performed using the telephone number on the first user terminal 30A. As explained in the first embodiment, telephone number authentication is not limited to authentication using an outgoing call from the user's telephone number as shown in Figure 2. Telephone number authentication may also be authentication using an incoming call to the user's telephone number, or authentication using an SMS message. The authentication unit 102 performs telephone number authentication from the first user terminal 30A in the same manner as known telephone number authentication.
[0176] Authentication performed using a telephone number on the first user terminal 30A is the same authentication method as the authentication performed using a telephone number on the first user terminal 30A. In the example in Figure 3, the telephone number authentication performed from the first authentication screen SC5 corresponds to the first authentication, which is the same as the authentication performed using a telephone number on the first user terminal 30A. If the telephone number authentication performed from the first authentication screen SC5 is authentication using an outgoing call from the user's telephone number, then authentication using an outgoing call from the user's telephone number corresponds to the first authentication.
[0177] Furthermore, if the telephone number authentication performed from the first authentication screen SC5 is authentication using incoming calls to the user's telephone number or authentication using SMS messages, then authentication using incoming calls to the user's telephone number or authentication using SMS messages may be considered equivalent to the first authentication. The authentication unit 102 should perform the first authentication in the same manner as the authentication performed using the telephone number on the first user terminal 30A.
[0178] In the modified example 1-1, if the change requirement information indicates that the phone number will not be changed, the authentication system 1 performs the same authentication as the authentication performed using the phone number on the first user terminal 30A as the first authentication. As a result, even if a malicious third party obtains the user's login account and password, they will not be able to successfully perform the same authentication as the authentication performed using the phone number on the first user terminal 30A, thus the authentication system 1 can enhance the security of the payment service. From the user's perspective, they only need to perform the same authentication as they have performed before from the first user terminal 30A (an authentication for which they already know the procedure), so the authentication system 1 can enhance security while improving user convenience.
[0179] [Variation 1-2] For example, suppose a malicious third party obtains a user's login account and password and logs into a payment service by impersonating the user. Even if the third party knows the user's phone number, it would be difficult to set the user's phone number on the third party's device (for example, it would be difficult to write the user's phone number onto the SIM card of a third party's smartphone without their permission), so it would be extremely difficult to successfully complete the first authentication.
[0180] On the other hand, if a third party logs into the payment service from their own device, impersonating a user, and falsely claims that the user's phone number has changed, the first authentication will not be performed. In this case, the third party may be able to bypass the second authentication by some means. Therefore, anticipating the possibility of a third party misusing the payment service, it may be possible to impose restrictions on the use of the payment service if the second authentication is performed. If the user or administrator notices the misuse while the restriction is in place, the damage can be minimized.
[0181] The authentication system 1 of Modification 1-2 includes a function restriction unit 110. When a second authentication is performed, the function restriction unit 110 restricts the functions related to the payment service used by the second user terminal 30B more than when a first authentication is performed. A function is an information processing operation performed by the payment service. For example, payment, charging, remittance, withdrawal, changing the payment source, changing the charging source, changing the information registered in the payment service, or other processing constitutes a function. If the specified service is a service other than the payment service, the function may be any information processing operation performed by the other service.
[0182] For example, the function restriction unit 110 may restrict functionality by setting an upper limit on the settlement amount per transaction or within a predetermined period (e.g., one day, one week, or one month). The function restriction unit 110 may restrict functionality by setting an upper limit on the number of transactions within a predetermined period. The function restriction unit 110 may restrict functionality by setting an upper limit on the charge amount per transaction or within a predetermined period. The function restriction unit 110 may restrict functionality by setting an upper limit on the number of charges within a predetermined period.
[0183] For example, the function restriction unit 110 may restrict functionality by setting an upper limit on the amount to be transferred per transaction or within a predetermined period. The function restriction unit 110 may restrict functionality by setting an upper limit on the number of transfers within a predetermined period. The function restriction unit 110 may restrict functionality by not accepting changes to the payer. The function restriction unit 110 may restrict functionality by not accepting changes to the charge source. The function restriction unit 110 may restrict functionality by not accepting changes to the information registered with the payment service. For example, the function restriction unit 110 may restrict the use of certain functions, such as withdrawals.
[0184] For example, when a user is logged into a payment service with a certain login account and a second authentication is performed, the function restriction unit 110 restricts functionality by storing function restriction information in the authentication database DB1, indicating that functionality is restricted in association with that login account. The function restriction information indicates whether or not functionality is restricted. For example, the function restriction information may be a flag that can be either a value indicating that functionality is not restricted, or a value indicating that functionality is restricted. The function restriction unit 110 may store the function restriction information in a database other than the authentication database DB1. The function restriction unit 110 may also associate the function restriction information with other user identification information other than the login account.
[0185] For example, when a payment service is used with a login account, the function restriction unit 110 refers to the function restriction information associated with that login account. If the function restriction information indicates that the function should not be restricted, the function restriction unit 110 provides the payment service without restricting the function. If the function restriction information indicates that the function should be restricted, the function restriction unit 110 provides the payment service with the function restricted. An example of function restriction is as described above. The function restriction unit 110 does not restrict the function when the first authentication has been performed.
[0186] In the modified version 1-2, the authentication system 1 restricts the functions related to the services used by the second user terminal 30B more than when the first authentication is performed, when the second authentication is performed. As a result, even if a third party manages to bypass the second authentication, the authentication system 1 can prevent damage from occurring in the first place or minimize damage by restricting functions. Consequently, the authentication system 1 can enhance security while improving user convenience.
[0187] [Modifications 1-3] For example, the functional restriction described in Modification Example 1-2 may be lifted under predetermined lifting conditions. The lifting conditions are the conditions for lifting the functional restriction. In other words, the lifting conditions are the criteria for deciding whether or not to lift the functional restriction. Lifting a functional restriction means changing from a state in which the function is restricted to a state in which the function is not restricted. To put it another way, lifting a functional restriction means returning to the state before the function was restricted.
[0188] The authentication system 1 in modified example 1-3 includes a restriction removal unit 111. The restriction removal unit 111 removes the restriction on a function when predetermined removal conditions are met. For example, the restriction removal unit 111 determines whether the user has met the removal conditions for each user whose function is restricted (for each login account whose function is restricted). If the restriction removal unit 111 determines that the user does not meet the removal conditions, it does not remove the restriction on the user's function, but if it determines that the user has met the removal conditions, it removes the restriction on the user's function.
[0189] In variation 1-3, we take an example where the expiration of a predetermined restriction period constitutes the condition for lifting the restriction. The restriction period is the period during which the function is restricted. The restriction period can also be described as information that identifies when the restriction on the function will be lifted. For example, the restriction period may be the period from when the second authentication is performed (when the restriction on the function begins) until a predetermined time (e.g., one week) has passed.
[0190] In Modification 1-3, the function restriction unit 110 associates restriction period information, which can identify the restriction period, with the function restriction information. The restriction period information may be included in the function restriction information. When the second authentication is performed, the function restriction unit 110 determines the period from the current date and time to a predetermined time later as the restriction period, and associates the restriction period information indicating the determined restriction period with the function restriction information. The restriction period information may indicate the date and time when the function restriction ends. In this case, when the second authentication is performed, the function restriction unit 110 may associate the restriction period information indicating the date and time a predetermined time later from the current date and time with the function restriction information. The restriction period information may indicate the date and time when the function restriction started. In this case, when the second authentication is performed, the function restriction unit 110 associates the function restriction information indicating the current date and time with the function restriction information.
[0191] For example, the restriction release unit 111 determines whether the release condition has been met by determining whether the restriction period has arrived based on the restriction period information. If the restriction release unit 111 determines that the restriction period has not arrived, it determines that the release condition has not been met, and if it determines that the restriction period has arrived, it determines that the release condition has been met. The restriction release unit 111 releases the restriction on the function by changing the function restriction information from a state in which the function restriction information indicates that the function is restricted to a state in which the function restriction information indicates that the function is not restricted. For example, if the function restriction information is a flag as described in Modification 1-2, the restriction release unit 111 releases the restriction on the function by changing the value of the flag.
[0192] The conditions for lifting the restriction can be any predetermined conditions, and may include conditions other than the expiration of the restriction period. For example, the condition for lifting the restriction may be that there is no suspicion of fraud in the use of the payment service after the second authentication. Suspicion of fraud may be determined visually by the payment service operator, or it may be determined automatically based on a predetermined fraud detection program. The fraud detection program may be the same as a program used in a well-known payment service. For example, the fraud detection program may be a program that determines whether or not there is suspicion of fraud by comprehensively considering the payment amount, payment date and time, payment location, number of payments, charge amount, charge date and time, number of charges, payment source, charge source, or other factors.
[0193] For example, the usage history of the payment service after the second authentication may be stored in the authentication database DB1, the payment database DB2, or another database. The restriction removal unit 111 presents the usage history to the payment service operator and receives the operator's confirmation result from the operator's terminal. If the operator's confirmation result indicates that the transaction is fraudulent, the restriction removal unit 111 may determine that the conditions for removal are not met, and if the operator's confirmation result indicates that the transaction is not fraudulent, the restriction removal unit 111 may determine that the conditions for removal are met.
[0194] For example, the unlocking condition may be that an authentication other than the second authentication is performed from the second user terminal 30B. The other authentication is different from both the login authentication and the first authentication. For example, the other authentication may be knowledge authentication, possession authentication, or biometric authentication. If the restriction removal unit 111 determines that no other authentication has been performed from the second user terminal 30B, it determines that the unlocking condition is not met, and if it determines that no other authentication has been performed from the second user terminal 30B, it determines that the unlocking condition is met. The unlocking condition may be any other arbitrary condition.
[0195] The authentication system 1 in Modification 1-3 removes the restriction on functionality when predetermined release conditions are met. This allows the user to use the payment service with the restriction removed, so the authentication system 1 can enhance security while ensuring the security of the payment service and improving user convenience. For example, even if the second authentication is performed, the authentication system 1 can restrict functionality if there is suspicion of fraud, and remove the restriction when the suspicion of fraud is gone.
[0196] [Modifications 1-4] For example, as a second authentication method to be performed when a user's phone number does not change, only one authentication method may be provided, or multiple authentication methods may be provided. If multiple authentication methods are provided, there may be a second authentication method among them that some users cannot use. Therefore, in Modification 1-4, we will give an example of a case in which a second authentication method that the user can use is proposed from among multiple authentication methods.
[0197] The authentication system 1 of Modified Example 1-4 includes a user information acquisition unit 103 and a second authentication proposal unit 112. The user information acquisition unit 103 may be the same as the user information acquisition unit 103 described in the second embodiment, but the user information acquisition unit 103 of Modified Example 1-4 is given as an example of having a different function from the user information acquisition unit 103 described in the second embodiment. The user information acquisition unit 103 of Modified Example 1-4 acquires user information about the user when the change requirement information indicates that the telephone number should be changed.
[0198] The user information in Modification 1-4 is information obtained from the second user terminal 30B, or information associated with the user ID or login account of a user who logged in from the second user terminal 30B. The user information in Modification 1-4 may be the same as the user information described in the second embodiment, or it may be different from the user information described in the second embodiment. Modification 1-4 describes a case where, as an example of user information, it is information indicating whether or not the communication unit 33B of the second user terminal 30B supports short-range wireless communication. The user information may be any information about the user and is not limited to the example in Modification 1-4.
[0199] For example, the second user terminal 30B determines whether the communication unit 33B supports short-range wireless communication. This determination method may be a known method. For example, the determination of whether the communication unit 33B supports short-range wireless communication may be based on the model information of the second user terminal 30B. For example, if information indicating whether the communication unit 33B supports short-range wireless communication is stored in the second user terminal 30B beforehand, the second user terminal 30B may determine whether the communication unit 33B supports short-range wireless communication based on that information. Based on the determination result, the second user terminal 30B transmits user information to the authentication server 10 indicating whether the communication unit 33B supports short-range wireless communication. The user information acquisition unit 103 acquires user information from the second user terminal 30B.
[0200] The second authentication proposal unit 112 proposes to the user, as a second authentication method, an authentication method in which the user information satisfies predetermined authentication conditions. In a payment service, multiple authentication methods may be provided, or only one authentication method may be provided. The second authentication proposal unit 112 may have at least some of the functions of the authentication condition determination unit described in the second embodiment. The second authentication proposal unit 112 may have at least some of the functions of the authentication content display unit 105 described in the second embodiment. The second authentication proposal unit 112 may have at least some of the functions of the other authentication content display unit 106 described in the second embodiment.
[0201] The authentication conditions are as described in the second embodiment. The authentication conditions in Modification 1-4 are the authentication conditions for the second authentication. The second authentication proposal unit 112 may determine whether the user information satisfies the authentication conditions in the same manner as the authentication condition determination unit 104 in the second embodiment. For example, as in Modification 1-4, if the user information indicates whether the communication unit 33B supports short-range wireless communication, the second authentication proposal unit 112 determines that the user information does not satisfy the authentication conditions if the user information indicates that the communication unit 33B does not support short-range wireless communication, and determines that the user information satisfies the authentication conditions if the user information indicates that the communication unit 33B supports short-range wireless communication.
[0202] In Modification 1-4, similar to the second embodiment, two authentication methods, card scan authentication and one-time password authentication, are provided as second authentication methods. For example, if the second authentication proposal unit 112 determines that the user information satisfies the authentication conditions, it proposes card scan authentication by displaying the second authentication screen SC6 for card scan authentication on the second user terminal 30B. In this case, the display flow of the second authentication screen SC6 may be the same as in the first embodiment.
[0203] For example, if the second authentication suggestion unit 112 determines that the user information does not meet the authentication conditions, it suggests one-time password authentication to the user by displaying the second authentication screen SC6 for one-time password authentication on the second user terminal 30B. This second authentication screen SC6 may be the same as the other authentication screen SC7 in the second embodiment. In the second embodiment, an example was given where one-time password authentication is a different type of authentication from the second authentication, but in modification 1-4, one-time password authentication is also a type of second authentication.
[0204] In the modified example 1-4, the authentication unit 102 performs a second authentication when a second authentication is proposed. For example, the authentication unit 102 performs a second authentication when a second authentication is proposed and the user performs an operation for the second authentication. As described in the first embodiment, the flow by which the authentication unit 102 performs the second authentication may be the same as the known flow. The authentication unit 102 performs the second authentication proposed by the second authentication proposal unit 112 from among multiple authentication methods. For example, if card scan authentication is proposed, the authentication unit 102 performs card scan authentication. If one-time password authentication is proposed, the authentication unit 102 performs one-time password authentication.
[0205] In the modified example 1-4, the authentication system 1 acquires user information when the change requirement information indicates that the user's phone number needs to be changed. The authentication system 1 proposes to the user, as a second authentication method, an authentication method that satisfies the user information's predetermined authentication conditions. As a result, the user can perform the second authentication using an authentication method that matches the authentication conditions their user information satisfies, thus the authentication system 1 can enhance security while improving user convenience.
[0206] [Variations 1-5] For example, in Modification 1-4, the second authentication proposal unit 112 may determine whether user information satisfies the authentication conditions by determining whether predetermined information regarding possessions is associated with user information. Modification 1-5 takes the case where user ID corresponds to user information as an example. User information may also be user identification information other than user ID (for example, login account). The method by which the user information acquisition unit in Modification 1-5 acquires user information, with user ID as an example, may be the same as that of the user information acquisition unit in the second embodiment.
[0207] The possessed item is the item used for so-called possession authentication. For example, the possessed item is a credit card or other card. In addition to a credit card, the possessed item may also be a membership card that can prove the user's identity, a health insurance card, a driver's license, a passport, or a My Number card. For example, personal authentication may be performed based on a My Number card. If the same login account is logged in from a different device, and the My Number card information is associated with the login account, the My Number card scan authentication may be performed again.
[0208] The specified information is information necessary for a particular second authentication, or information indicating the presence or absence of such information. For example, if card scan authentication corresponds to the second authentication, authentication information stored on the credit card (e.g., electronic money number or point card number) is required for the second authentication, so the specified information may be such authentication information, or information indicating the presence or absence of such authentication information. In Modification Example 1-5, the case where the specified information is stored in the authentication database DB1 is given as an example, but the specified information may be stored in a database other than the authentication database DB1. For example, the specified information may be stored in the payment database DB2.
[0209] Furthermore, the specified information is not limited to authentication information such as electronic money numbers or point card numbers. For example, if a second authentication is performed to verify the validity of a credit card number, the specified information may be the credit card number. If other possession authentication, knowledge authentication, or biometric authentication other than card scan authentication corresponds to the second authentication, the authentication required for these authentications, or information indicating the presence or absence of such authentication information, may correspond to the specified information. The second authentication proposal unit 112 may determine whether or not this specified information is associated with user information.
[0210] For example, if the second authentication proposal unit 112 determines that the user information does not meet the authentication conditions when it determines that the user information does not meet the authentication conditions when it determines that the user information does not meet the authentication conditions when it determines that the user information does not meet the authentication conditions when it determines that the user information does not meet the authentication conditions when it determines that the user information does not meet the authentication conditions when it determines that the authentication information such as an electronic money number or a point card number is not associated with the user information, the second authentication screen SC6 for one-time password authentication is displayed on the second user terminal 30B. If the second authentication proposal unit 112 determines that the authentication information such as an electronic money number or a point card number is associated with the user information, the second authentication proposal unit 112 determines that the user information meets the authentication conditions, and the second authentication screen SC6 for card scan authentication is displayed on the second user terminal 30B. The subsequent authentication flow may be the same as in the second authentication proposal unit 1-4.
[0211] The authentication system 1 in modified example 1-5 determines whether user information meets the authentication conditions by determining whether predetermined information about possessions is associated with user information. As a result, users can perform second authentication using a specific authentication method if predetermined information is associated with their user information, thus enhancing security while improving user convenience. For example, the authentication system 1 can prevent situations where the second authentication screen SC6 for card scan authentication is displayed on the second user terminal 30B even though authentication information such as an electronic money number or point card number is not associated with the user ID and the user cannot perform card scan authentication.
[0212] [Variations 1-6] For example, if the predetermined service described in the first embodiment is a payment service, the second authentication proposal unit 112 may determine whether predetermined information regarding payment methods that can be set in the payment service is associated with user information. Payment methods that can be set in the payment service are payment methods that the user can use in the payment service. For example, payment methods that can be set as a payment source or charge source correspond to payment methods that can be set in the payment service. Modification example 1-6 gives an example where the payment method of the payment source of the payment app corresponds to a payment method that can be set in the payment service.
[0213] In Modification 1-6, an example is given where the credit card described in Modifications 1-4 and 1-5 corresponds to a payment method that can be set in the payment service. Furthermore, an example is given where the electronic money number or point card number for the electronic money function or point function, which are ancillary functions of the credit card, corresponds to predetermined information related to a payment method, with the credit card being one example. The processing of the second authentication proposal unit 112 in these examples is as described in Modification 1-5. For example, if the predetermined information is authentication information such as an electronic money number or point card number, the second authentication proposal unit 112 determines whether the authentication information such as the electronic money number or point card number is associated with the user information. The authentication unit 102 performs the second authentication based on the predetermined information. The flow of the second authentication may be the same as in Modification 1-5.
[0214] Furthermore, the payment methods that can be set in the payment service are not limited to credit cards as described in the modified examples 1-4 and 1-5. For example, the payment method that can be set in the payment service may be a credit card without any additional functions such as electronic money or points. In this case, the specified information may be information such as the credit card number. The payment method that can be set in the payment service may be other cards such as debit cards instead of credit cards. In this case, the specified information may be information such as the debit card number.
[0215] For example, the payment methods that can be set in a payment service may be other payment methods besides cards. The payment methods that can be set in a payment service may be bank accounts, electronic money, or points. In this case, the specified information may be bank account information, electronic money information, or points information. The payment methods that can be set in a payment service may be apps of other payment services. In this case, the specified information may be information of apps of other payment services.
[0216] The authentication system 1 in modified example 1-6 determines whether predetermined information regarding payment methods configurable in the payment service is associated with the user information. As a result, the user can perform second authentication using a specific authentication method if predetermined information regarding payment methods configurable in the payment service is associated with their user information, thereby enhancing security while improving user convenience. For example, the authentication system 1 can prevent the display of the second authentication screen SC6 for card scan authentication on the second user terminal 30B in an environment where authentication information such as an electronic money number or point card number is not associated with the user ID and the user cannot perform card scan authentication.
[0217] [Variations 1-7] For example, as explained to some extent in Modification 1-4, in the first embodiment, as in the second embodiment, the second authentication content related to the second authentication may be presented to the user when the user meets the authentication conditions. In Modification 1-7, the authentication content described in the second embodiment is referred to as the second authentication content. The explanation of the authentication content in the second embodiment can be read as an explanation of the second authentication content. In Modification 1-7, as in the second embodiment, the case in which the second authentication screen SC6 corresponds to the second authentication content is given as an example, but the second authentication content may be a part of the second authentication screen SC6 rather than the entire second authentication screen SC6.
[0218] The authentication system 1 of modified example 1-7 includes a second authentication content display unit 113. The second authentication content display unit 113 displays second authentication content related to the second authentication on the second user terminal 30B when the change requirement information indicates that the telephone number should be changed and predetermined authentication conditions are met. For example, the second authentication content display unit 113 displays the second authentication screen SC6, which is an example of second authentication content, on the second user terminal 30B by transmitting display data for the second authentication screen SC6 to the second user terminal 30B.
[0219] For example, the second authentication content display unit 113 will not display the second authentication content on the second user terminal 30B if the change requirement information indicates that the telephone number will not be changed, or if the predetermined authentication conditions are not met. In this case, the authentication server 10 may display another authentication screen SC7 on the second user terminal 30B, as in the second embodiment, or it may not display any content at all.
[0220] In the modified example 1-7, the authentication unit 102 performs the second authentication when the second authentication content is displayed on the second user terminal 30B. For example, the authentication unit 102 performs the second authentication when the second authentication content is displayed on the second user terminal 30B and the user performs an operation for the second authentication. The flow of the authentication unit 102 performing the second authentication after the second authentication content is displayed on the second user terminal 30B may be the same as in the first or second embodiment. If another authentication screen SC7 is displayed on the second user terminal 30B, the authentication unit 102 may perform other authentications in the same manner as in the second embodiment.
[0221] In the modified example 1-7, the authentication system 1 displays the second authentication content on the second user terminal 30B when the system indicates that a change of phone number is necessary and the authentication conditions are met. The authentication system 1 performs the second authentication when the second authentication content is displayed on the second user terminal 30B. This allows the authentication system 1 to control whether or not to display the second authentication content depending on whether the user meets the authentication conditions, thereby enhancing security while improving user convenience. For example, the authentication system 1 can prevent the display of the second authentication screen SC6 for card scan authentication to users who cannot perform card scan authentication because they do not meet the authentication conditions.
[0222] [Variations 1-8] For example, in Modification 1-7, the second authentication content display unit 113 may, when it indicates that a change is necessary to change the telephone number and predetermined authentication conditions are met, distinguish between the second authentication content and other authentication content related to other authentications different from the second authentication and display them on the second user terminal 30B. The other authentication content is as described in the second embodiment.
[0223] Distinguishing between second-authentication content and other authentication content means displaying the second-authentication content before other authentication content, displaying the second-authentication content and other authentication content on separate screens, displaying the second-authentication content and other authentication content in different positions on the same screen, or displaying the second-authentication content with more emphasis than other authentication content. In variation 1-8, the second-authentication content and other authentication content are given as an example where they are not the entire screen but only a part of the screen; however, the second-authentication content and other authentication content may be the entire screen.
[0224] Figure 17 shows an example of the authentication selection screen displayed on the second user terminal 30B in the modified example 1-8. As shown in the upper right of Figure 17, the second authentication content display unit 113 displays an authentication selection screen SC9 on the second user terminal 30B, in which part P90, which is an example of second authentication content, and part P91, which is an example of other authentication content, are distinguished. In the example in the upper right of Figure 17, the second authentication content display unit 113 displays a message such as "Recommended" near part P90, emphasizing part P90 more than part P91, thereby distinguishing part P90 and part P91 and displaying them on the second user terminal 30B.
[0225] The method by which the second authentication content display unit 113 emphasizes the second authentication content more than other authentication content is not limited to the example in Figure 17. For example, the second authentication content display unit 113 may emphasize the second authentication content more than other authentication content by displaying a message other than the one in Figure 17, or an image other than a message. The second authentication content display unit 113 may emphasize the second authentication content more than other authentication content by displaying it above or before other authentication content. The second authentication content display unit 113 may prioritize the display of the second authentication content by automatically transitioning to the second authentication content instead of automatically transitioning to other authentication content.
[0226] For example, when a user selects part P90, the second user terminal 30B displays a second authentication screen SC6 for card scan authentication on the display unit 35B, as shown in the lower left of Figure 17. The display flow of the second authentication screen SC6 is the same as in the first or second embodiment. When a user selects part P91, the second user terminal 30B displays another authentication screen SC7 for other authentication on the display unit 35B, as shown in the lower right of Figure 17. The display flow of the other authentication screen SC7 is the same as in the second embodiment.
[0227] In the modified example 1-8, the authentication unit 102 performs the second authentication or other authentication when the second authentication content and other authentication content are distinguished and displayed on the second user terminal 30B. For example, the authentication unit 102 performs the second authentication or other authentication when the second authentication content and other authentication content are distinguished and displayed on the second user terminal 30B, and the user performs an operation for the second authentication or other authentication. For example, the authentication unit 102 performs the second authentication when part P90, which is an example of the second authentication content, is selected. The flow of the second authentication may be the same as in the first or second embodiment. The authentication unit 102 performs other authentication when part P91, which is an example of other authentication content, is selected. The flow of other authentication may be the same as in the second embodiment.
[0228] In the modified example 1-8, the authentication system 1 indicates whether a change is necessary when the phone number is changed, and if the authentication conditions are met, it distinguishes between the second authentication content and other authentication content and displays them on the second user terminal 30B. When the second authentication content and other authentication content are displayed separately on the second user terminal 30B, the authentication system 1 performs the second authentication or other authentication. This makes it easier for the user to distinguish between the second authentication content and other authentication content, so the authentication system 1 can enhance security while improving user convenience.
[0229] [Modifications 1-9] For example, the authentication unit 102 may perform a second authentication using the first user terminal 30A if the change requirement information indicates that the telephone number will be changed and the first user terminal 30A is owned. The second authentication using the first user terminal 30A is a second authentication in which an operation is performed on the first user terminal 30A. Modification 1-9 gives an example of a case where the payment code authentication described in the third embodiment corresponds to the second authentication. The authentication unit 102 may perform a payment code authentication similar to that in the third embodiment as the second authentication if the change requirement information indicates that the telephone number will be changed and the first user terminal 30A is owned. The authentication unit 102 may perform a payment code authentication similar to that in the third embodiment as the second authentication if the change requirement information indicates that the telephone number will be changed, the first user terminal 30A is owned, and the user performs an operation for the second authentication.
[0230] Furthermore, the second authentication using the first user terminal 30A may be any authentication method other than payment code authentication. For example, authentication performed by displaying a code different from the payment code C30 on the first user terminal 30A and reading that code with the second user terminal 30B may be considered the second authentication. Authentication performed by reading the payment code C30 displayed on the second user terminal 30B with the first user terminal 30A may also be considered the second authentication. For example, authentication performed by having the user enter a new phone number into the first user terminal 30A may be considered the second authentication.
[0231] For example, the authentication unit 102 may determine whether the user possesses the first user terminal 30A and perform the second authentication on the condition that the user possesses the first user terminal 30A. The authentication unit 102 may determine whether the user possesses the first user terminal 30A based on information transmitted by the first user terminal 30A (e.g., login account or terminal ID), information transmitted by the second user terminal 30B (e.g., login account or terminal ID), usage status of the payment service from the first user terminal 30A (e.g., date and time of login, date and time of issuance of payment code C30, expiration date of payment code C30), or other information. Alternatively, the authentication unit 102 may determine whether the user possesses the first user terminal 30A based on information entered by the user regarding whether or not they possess the first user terminal 30A. If the authentication unit 102 determines that the user does not possess the first user terminal 30A, it does not perform the second authentication using the first user terminal 30A. If it determines that the user possesses the first user terminal 30A, it performs the second authentication using the first user terminal 30A.
[0232] In the modified example 1-9, the authentication system 1 performs a second authentication using the first user terminal 30A when the change requirement information indicates that the phone number needs to be changed and the first user terminal 30A is possessed. This allows the authentication system 1 to enhance security through the second authentication using the first user terminal 30A. For example, if the authentication system 1 performs the second authentication on the condition that the user possesses the first user terminal 30A, it can prevent the process for the second authentication from being executed even if the user does not possess the first user terminal 30A.
[0233] [Variations 1-10] For example, as described in the first embodiment, the predetermined service may be a payment service in which payment is executed by reading the payment code C30. In this case, as described in Modification 1-9, the authentication unit 102 may perform a second authentication in which the payment code C30 displayed on the first user terminal 30A is read by the second user terminal 30B. This second authentication is the same as the payment code authentication in the third embodiment.
[0234] In the modified example 1-10, the authentication system 1 performs a second authentication in which the payment code C30 displayed on the first user terminal 30A is read by the second user terminal 30B. As a result, the authentication system 1 allows users to perform payment code authentication by performing an operation they are already familiar with to display the payment code C30 (for example, launching a payment app), thereby enhancing security while improving user convenience. The authentication system 1 can also use the payment code C30 used for payment for authentication when changing devices, etc., eliminating the need to issue a separate authentication code. Consequently, the authentication system 1 can reduce the development costs required to implement the authentication function.
[0235] [Variations 1-11] For example, if the change requirement information indicates that the phone number should be changed, the authentication unit 102 may perform a second authentication in which the changed phone number is entered from the first user terminal 30A. For example, if the change requirement information indicates that the phone number should be changed and the user performs an operation for the second authentication, the authentication unit 102 may perform a second authentication in which the changed phone number is entered from the first user terminal 30A. Based on the changed phone number entered from the first user terminal 30A, the authentication unit 102 performs phone number authentication using the second user terminal 30B. The changed phone number is the phone number of the second user terminal 30B.
[0236] Figure 18 shows an example of the screens displayed on the first user terminal 30A and the second user terminal 30B in the modified example 1-11. For example, as shown in the lower left of Figure 18, the first user terminal 30A communicates with the authentication server 10 and displays a telephone number input screen SC10 on the display unit 35A that accepts input of the changed telephone number. The user enters the changed telephone number into the input form F100. The first user terminal 30A sends the changed telephone number to the authentication server 10. The first user terminal 30A may also send the changed telephone number to the second user terminal 30B.
[0237] For example, when the authentication server 10 receives the changed phone number, it displays a second authentication screen SC6 on the second user terminal 30B, as shown in the upper right of Figure 18, to perform phone number authentication based on the changed phone number as the second authentication. The user performs the operation from the second authentication screen SC6 to perform phone number authentication based on the changed phone number as the second authentication. The authentication unit 102 performs phone number authentication based on the changed phone number as the second authentication. The phone number authentication flow itself may be the same as the publicly known flow.
[0238] Furthermore, when a user changes their phone number, the authenticated first user terminal 30A may obtain the changed phone number and display it on the display unit 35A. The first user terminal 30A may also obtain the changed phone number from another service or website linked to the payment service. The user is assumed to have registered the changed phone number from the second user terminal 30B or another computer to another service or website. The authentication server 10 may obtain the changed phone number displayed on the display unit 35A of the first user terminal 30A from the first user terminal 30A, another service, or website, and perform phone number authentication with the second user terminal 30B.
[0239] In the modified example 1-11, the authentication system 1 performs a second authentication when the change requirement information indicates that the phone number needs to be changed, by requiring the new phone number to be entered from the first user terminal 30A. This makes the user possessing the first user terminal 30A a condition for performing the second authentication, thus enhancing security in payment services. For example, even if a malicious third party obtains the user's login account and password, it would be difficult to seize the first user terminal 30A, and therefore they would be unable to perform the second authentication. For this reason, the authentication system 1 enhances security in payment services.
[0240] [4-2. Modifications relating to the second embodiment] Next, a modified example relating to the second embodiment will be described.
[0241] [Variation 2-1] For example, in the second embodiment, similar to the modification 1-8, the authentication content display unit 105 may preferentially display the authentication content on the second user terminal 30B when it is determined that the user information satisfies the authentication conditions. Modification 2-1 takes the example of a case where the authentication selection screen SC9, similar to that in modification 1-8, is displayed on the second user terminal 30B. The authentication content display unit 105 displays part P90 as authentication content. For example, the authentication content display unit 105 places part P90 on the authentication selection screen SC9. The other authentication content display unit 106 displays part P91 as other authentication content. For example, the other authentication content display unit 106 places part P91 on the authentication selection screen SC9.
[0242] In the example in the upper right of Figure 17, the authentication content display unit 105 displays a message such as "Recommended" near part P90, which is an example of authentication content, thereby prioritizing the display of part P90 over part P91, which is another example of authentication content. Emphasizing part P90 as described in Modification Example 1-8 is equivalent to prioritizing the display of part P90. The authentication content display unit 105 may also prioritize the display of part P90 over part P91 by using other messages. The authentication content display unit 105 may also prioritize the display of authentication content by automatically transitioning to the second authentication screen SC6 in the lower left of Figure 17 as authentication content.
[0243] In the modified version 2-1, the authentication system 1 prioritizes displaying the authentication content on the second user terminal 30B when it is determined that the user information meets the authentication conditions. This makes it easier for the user to notice the authentication content, thus improving user convenience.
[0244] [Modification 2-2] For example, if the user information is determined to meet the authentication conditions, the other authentication content display unit 106 may display other authentication content on the second user terminal 30B, based on the user's selection status of the authentication content, that is different from the authentication that will be performed when the authentication conditions are met. The selection status of the authentication content refers to the operation performed on the authentication content. For example, the choice of whether or not to perform the authentication indicated by the authentication content corresponds to the selection status of the authentication content. The user canceling the authentication is also an example of the selection status of the authentication content.
[0245] Figure 19 shows an example of a screen displayed on the second user terminal 30B in the modified example 2-2. As shown in the upper right of Figure 19, the authentication content display unit 105 displays the second authentication screen SC6, which includes a button B60 indicating whether or not to perform card scan authentication, on the second user terminal 30B. The user can perform card scan authentication without selecting button B60, or they can select button B60 and not perform card scan authentication. In the example in the upper right of Figure 19, whether or not the user selects button B60 corresponds to the selection status of the authentication content.
[0246] For example, if the user does not select button B60, card scan authentication is performed in the same manner as in the first or second embodiment. If the user selects button B60, the other authentication content display unit 106 displays the other authentication screen SC7 on the second user terminal 30B. That is, the other authentication content display unit 106 transitions from the second authentication screen SC6 to the other authentication screen SC7. The process by which the other authentication content display unit 106 displays the other authentication screen SC7 may be the same as in the second embodiment.
[0247] In the modified example 2-2, the authentication system 1, when it is determined that the user information meets the authentication conditions, displays other authentication content on the second user terminal 30B based on the user's selection of authentication content. This allows the user to perform other authentication by displaying other authentication content if they do not wish to perform the authentication indicated by the authentication content, thus improving user convenience. In the example in Figure 19, the user can perform one-time password authentication if they do not wish to perform card scan authentication, thus improving the flexibility of authentication in the authentication system 1.
[0248] [Modification 2-3] For example, in the second embodiment, the case in which the authentication conditions for one authentication, such as card scan authentication, are determined is given as an example, but there may be multiple authentications for which authentication conditions are set. The authentication condition determination unit 104 may determine whether or not the user information satisfies the authentication conditions for each of the multiple authentications. Modification 2-3 describes card scan authentication and biometric authentication as examples of multiple authentications. The authentication conditions for biometric authentication may be determined by whether or not biometric information (e.g., a facial photograph or fingerprint pattern) is registered in the authentication database DB1. The multiple authentications may be any authentications and are not limited to the example in Modification 2-3. For example, there may be three or more multiple authentications.
[0249] Figure 20 shows an example of a screen displayed on the second user terminal 30B in Modification 2-3. The authentication content display unit 105 in Modification 2-3 displays the authentication content of at least one authentication on the second user terminal 30B based on the priority associated with each of the multiple authentications when it is determined that the user information satisfies the authentication conditions of each of the multiple authentications. In the example in Figure 20, it is assumed that the authentication conditions for both card scan authentication and biometric authentication are satisfied. Furthermore, it is assumed that the priority of card scan authentication is higher than the priority of biometric authentication. The priority of each authentication is stored in the data storage unit 100. The priority is specified by the operator of the payment service.
[0250] For example, as shown in the upper right of Figure 20, the authentication content display unit 105 displays the second authentication screen SC6 for card scan authentication, which has a relatively higher priority among the card scan authentication and biometric authentication that meet the authentication conditions, on the second user terminal 30B before the second authentication screen SC6 for biometric authentication. If the user selects button B60 to indicate that they do not want to perform card scan authentication, the authentication content display unit 105 displays the second authentication screen SC6 for biometric authentication on the second user terminal 30B, as shown in the lower right of Figure 20.
[0251] The authentication system 1 in modified version 2-3 determines whether the user information satisfies the authentication conditions for each of the multiple authentications. If the authentication system 1 determines that the user information satisfies the authentication conditions for each of the multiple authentications, it displays the authentication content for at least one authentication on the second user terminal 30B based on the priority associated with each of the multiple authentications. This allows the user to check the authentication content according to the priority, thus improving user convenience. The authentication system 1 makes it easier for the user to perform authentications with relatively higher priority, thereby improving the security of the payment service.
[0252] [Modification 2-4] For example, in the second embodiment, similar to Modification 1-5, the authentication condition determination unit 104 may determine whether user information satisfies the authentication conditions by determining whether predetermined information is associated with the user information. The authentication condition determination unit 104 may determine the authentication conditions by the same process as the second authentication proposal unit 112 in Modification 1-5. The meaning of predetermined information is as explained in Modification 1-5. In Modification 2-4, the predetermined information may be information about possessions, similar to Modification 1-5, or it may be information unrelated to possessions. In Modification 2-4, similar to Modification 1-5, we will take the example where the user ID corresponds to user information and the authentication information stored on the credit card (for example, an electronic money number or a point card number) corresponds to the predetermined information.
[0253] For example, when the authentication condition determination unit 104 determines that predetermined information is not associated with the user information, it determines that the user information does not satisfy the authentication conditions, and when it determines that predetermined information is not associated with the user information, it determines that the user information satisfies the authentication conditions. When the authentication condition determination unit 104 determines that authentication information such as an electronic money number or a point card number is not associated with the user information, it determines that the user information does not satisfy the authentication conditions. When the authentication condition determination unit 104 determines that authentication information such as an electronic money number or a point card number is associated with the user information, it determines that the user information satisfies the authentication conditions. The subsequent authentication process may be the same as that of the second embodiment.
[0254] The authentication system 1 of Modification 2-4 determines whether the user information satisfies the authentication conditions by determining whether predetermined information is associated with the user information. Thereby, since the user can execute authentication when predetermined information is associated with his / her user information, the authentication system 1 can improve the convenience for the user. For example, the authentication system 1 can prevent a situation where, although authentication information such as an electronic money number or a point card number is not associated with the user ID and the user cannot execute card scan authentication, the process for card scan authentication is started.
[0255] [Modification 2-5] For example, also in the second embodiment, similar to Modification 1-6, when a predetermined service is a payment service, the authentication condition determination unit 104 may determine whether predetermined information regarding payment means that can be set in the payment service is associated with the user information. The authentication condition determination unit 104 may determine whether predetermined information is associated with the user information by the same process as the second authentication proposal unit 112 of Modification 1-6. When the predetermined information is authentication information such as an electronic money number or a point card number, the authentication condition determination unit 104 determines whether the authentication information such as an electronic money number or a point card number is associated with the user information.
[0256] The authentication system 1 of Modification Example 2-5 determines whether predetermined information regarding payment means that can be set in the payment service is associated with the user information. As a result, since the user can execute authentication when the predetermined information regarding the payment means that can be set in the payment service is associated with the user's own user information, the authentication system 1 can enhance the convenience of the user. For example, the authentication system 1 can prevent a situation where, although authentication information such as an electronic money number or a point card number is not associated with the user ID and the user cannot execute card scan authentication, a process for card scan authentication is executed in an environment where the user cannot execute card scan authentication.
[0257] [Modification Example 2-6] For example, although described somewhat in the second embodiment, the user information acquisition unit 103 may acquire user information when a user who uses the service from the first user terminal 30A logs in to the service from a second user terminal 30B different from the first user terminal 30A. In this case, the authentication for the user to use the payment service from the second user terminal 30B may be the authentication for using the first user terminal 30A. The authentication for using the first user terminal 30A may be the same as the second authentication for using the first user terminal 30A described in Modification Example 1-9.
[0258] The authentication condition determination unit 104 in Modification 2-6 determines whether user information satisfies the authentication conditions by determining whether the user possesses the first user terminal 30A. This determination method may be the same as that of the authentication unit 102 in Modification 1-9. For example, the authentication condition determination unit 104 may determine whether the user possesses the first user terminal 30A based on information transmitted by the first user terminal 30A (e.g., login account), information transmitted by the second user terminal 30B (e.g., login account), the usage status of the payment service from the first user terminal 30A (e.g., date and time of login, date and time of issuance of payment code C30, expiration date of payment code C30), or other information. For example, the authentication condition determination unit 104 may determine whether the user possesses the first user terminal 30A based on information entered by the user regarding whether or not they possess the first user terminal 30A.
[0259] In the modified example 2-6, the authentication system 1 obtains user information when a user who has used the service from the first user terminal 30A logs in to the service from the second user terminal 30B. The authentication system 1 determines whether the user information satisfies the authentication conditions by determining whether the user possesses the first user terminal 30A. This allows the authentication system 1 to enhance security by using authentication that utilizes the first user terminal 30A. For example, if the authentication system 1 performs authentication on the condition that the user possesses the first user terminal 30A, it can prevent the authentication process from being executed even if the user does not possess the first user terminal 30A.
[0260] [Modification 2-7] For example, as described in the second embodiment, the predetermined service may be a payment service in which payment is executed by reading the payment code C30. In this case, similar to the third embodiment or modifications 1-9 and 1-10, the authentication unit 102 may perform authentication in which the payment code C30 displayed on the first user terminal 30A is read by the second user terminal 30B when it is determined that the user information satisfies the authentication conditions. This authentication is the same as the payment code authentication in the third embodiment. For example, the authentication unit 102 may perform authentication in which the payment code C30 displayed on the first user terminal 30A is read by the second user terminal 30B when it is determined that the user information satisfies the authentication conditions and the user performs an operation for authentication.
[0261] In the modified example 2-7, the authentication system 1 performs authentication by reading the payment code C30 displayed on the first user terminal 30A at the second user terminal 30B when it is determined that the user information meets the authentication conditions. As a result, the authentication system 1 can enhance user convenience because the user can perform payment code authentication by performing an operation that they are already familiar with (for example, launching a payment app) to display the payment code C30. The authentication system 1 can also use the payment code C30 used for payment for authentication when changing devices, etc., eliminating the need to issue a separate authentication code. Consequently, the authentication system 1 can reduce the development costs required to implement the authentication function.
[0262] [4-3. Modifications relating to the third embodiment] Figure 21 shows an example of a function realized by a modification relating to the third embodiment. For example, the authentication server 10 includes an authentication condition determination unit 104, an authentication content display unit 105, a setting information application unit 114, and a payment code invalidation unit 115. The authentication condition determination unit 104, the authentication content display unit 105, the setting information application unit 114, and the payment code invalidation unit 115 are realized by the control unit 11.
[0263] [Modification 3-1] For example, in the third embodiment, as in the second embodiment, authentication content may be displayed based on whether or not the authentication conditions are met. The authentication system 1 of Modification 3-1 includes an authentication condition determination unit 104 and an authentication content display unit 105. The authentication condition determination unit 104 determines whether or not the user meets predetermined authentication conditions related to payment code authentication. The processing of the authentication condition determination unit 104 in Modification 3-1 is generally the same as in the second embodiment. Since payment code authentication requires the second user terminal 30B to have a shooting unit 36B, Modification 3-1 takes the example of a case where the second user terminal 30B having a shooting unit 36B corresponds to the authentication condition.
[0264] For example, the authentication condition determination unit 104 may determine whether the user meets the authentication conditions by determining whether the second user terminal 30B has a camera unit 36B (camera function). The second user terminal 30B transmits user information indicating whether or not it has a camera unit 36B to the authentication server 10. The presence or absence of the camera unit 36B may be determined by a known method. For example, the second user terminal 30B may store user information indicating the presence or absence of the camera unit 36B in advance.
[0265] For example, the authentication condition determination unit 104 determines whether the second user terminal 30B has a camera unit 36B (camera function) based on the user information received from the second user terminal 30B. If the user information does not indicate that the second user terminal 30B has a camera unit 36B, the authentication condition determination unit 104 determines that the user does not meet the authentication conditions. If the user information indicates that the second user terminal 30B has a camera unit 36B, the authentication condition determination unit 104 determines that the user meets the authentication conditions.
[0266] Note that the authentication conditions for payment code authentication are not limited to the above example. For example, the fact that a user possesses the first user terminal 30A may be considered an authentication condition for payment code authentication. In this case, the authentication condition determination unit 104 may determine whether the user satisfies the authentication conditions by determining whether or not the user possesses the first user terminal 30A, in the same manner as in Modification 2-6. If the authentication condition determination unit 104 determines that the user does not possess the first user terminal 30A, it determines that the user does not satisfy the authentication conditions. If the authentication condition determination unit 104 determines that the user possesses the first user terminal 30A, it determines that the user satisfies the authentication conditions.
[0267] Figure 22 shows an example of a screen displayed on the second user terminal 30B in Modification 3-1. In Modification 3-1, the authentication content display unit 105 displays authentication content related to payment code authentication on the second user terminal 30B when it is determined that the user meets the authentication conditions. The meaning of the authentication content is as explained in the second embodiment. In Modification 3-1, the authentication content is authentication content related to payment code authentication. In the example in the upper right of Figure 22, the message M42 displayed on the change requirement screen SC4 corresponds to the authentication content. In Modification 3-1, an example is given where a part of the screen, such as message M42, corresponds to the authentication content, but the entire screen may also correspond to the authentication content.
[0268] For example, in the state of the change requirement screen SC4 in the upper right of Figure 22, if the user selects button B41, a reading screen SC8 similar to the lower right of Figure 12 will be displayed. The reading information acquisition unit 107 in Modification 3-1 acquires reading information when the authentication content is displayed on the second user terminal 30B. When the authentication content is displayed on the second user terminal 30B, it means that the authentication content has been displayed on the second user terminal 30B. The authentication unit 102 in Modification 3-1 performs payment code authentication when the authentication content is displayed on the second user terminal 30B.
[0269] In the modified example 3-1, the authentication content display unit 105 does not display the authentication content related to payment code authentication on the second user terminal 30B if it is determined that the user does not meet the authentication conditions. In the example in the lower right of Figure 22, the user does not meet the authentication conditions, so message M42 is not displayed on the change requirement screen SC4. If the user selects button B41 while the change requirement screen SC4 is in the lower right of Figure 22, the other authentication screen SC7 in the lower right of Figure 8 may be displayed on the second user terminal 30B. In this case, one-time password authentication may be performed instead of payment code authentication. The flow of one-time password authentication may be the same as in the second embodiment.
[0270] The authentication system 1 in Modification 3-1 determines whether the user meets predetermined authentication conditions for payment code authentication. If the authentication system 1 determines that the user meets the authentication conditions, it displays authentication content related to payment code authentication on the second user terminal 30B. When the authentication content is displayed on the second user terminal 30B, the authentication system 1 acquires the reading information. When the authentication content is displayed on the second user terminal 30B, the authentication system 1 performs payment code authentication. This allows the authentication system 1 to display authentication content depending on whether the user meets the authentication conditions, thereby improving user convenience. For example, the authentication system 1 can prevent the display of the payment code authentication reading screen SC8 to users who do not meet the authentication conditions and therefore cannot perform payment code authentication.
[0271] [Modification 3-2] For example, in Modification 3-1, the authentication condition determination unit 104 may determine whether a user meets the authentication conditions by determining whether or not there has been a change in the user information relating to the user. The meaning of user information is as described in the second embodiment. Modification 3-2 takes the example of a case where the user information is information registered with a payment service. For example, the user information may be the user's telephone number, name, email address, address, other profile information, payment method information, payment source, charge source, or other information.
[0272] In variation 3-2, we take the example of a case where the user selects whether or not there has been a change in user information from the second user terminal 30B. For example, if the user's phone number corresponds to user information, the user selects whether or not there has been a change in user information from the change requirement screen SC4. Based on the user's selection, the second user terminal 30B sends change status information to the authentication server 10 indicating whether or not there has been a change in user information. If the user selects from the change requirement screen SC4 that there has been a change in user information, the change status information indicates that there has been a change in user information. If the user selects from the change requirement screen SC4 that there has been no change in user information, the change status information indicates that there has been no change in user information.
[0273] For example, the authentication condition determination unit 104 determines whether or not there has been a change in the user information based on the change information received from the second user terminal 30B. If the change information indicates that there has been no change in the user information, the authentication condition determination unit 104 determines that there has been no change in the user information. If the change information indicates that there has been a change in the user information, the authentication condition determination unit 104 determines that the authentication conditions are not met. If the user information is determined to have changed, the authentication condition determination unit 104 determines that the authentication conditions are met.
[0274] In the modified example 3-2, the user may select whether or not to change user information other than the phone number from the Change Requirement Screen SC4. For example, the user may select whether or not to change the user's name, email address, address, other profile information, payment method information, payment source, charge source, or other information from the Change Requirement Screen SC4. The user may also select whether or not to change user information from a screen other than the Change Requirement Screen SC4. The second user terminal 30B may send change information to the authentication server 10 indicating whether or not there has been a change in user information, based on the selection result from the other screen.
[0275] In addition, the user may select from the first user terminal 30A whether there is any change in the user information. For example, the first user terminal 30A causes the display unit 35A to display a screen for receiving a selection as to whether there is any change in the user information. The screen may have the same layout as the necessity-of-change screen SC4 or a different layout from the necessity-of-change screen SC4. The first user terminal 30A may transmit, to the authentication server 10, presence / absence-of-change information indicating whether there is any change in the user information based on the selection result for the screen. The authentication condition determination unit 104 may determine whether there is any change in the user information based on the presence / absence-of-change information received from the first user terminal 30A.
[0276] In the authentication content display unit 105 of Modification Example 3-2, based on whether there is any change in the user information, authentication content for code authentication for settlement is caused to be displayed on the second user terminal 30B. In Modification Example 3-1, as shown in the upper right of FIG. 22, the case where the message M42 on the necessity-of-change screen SC4 corresponds to the authentication content was taken as an example. However, in Modification Example 3-2, since it is determined whether there is any change in the user information after the necessity-of-change screen SC4 is displayed, the case where the screen displayed after the necessity-of-change screen SC4 is displayed or a part of the screen corresponds to the authentication content will be taken as an example.
[0277] For example, the reading screen SC8 may correspond to the authentication content. When it is determined that there is no change in the user information, the authentication content display unit 105 does not cause the reading screen SC8, which is an example of the authentication content, to be displayed on the second user terminal 30B, and when it is determined that there is no change in the user information, the authentication content display unit 105 causes the reading screen SC8, which is an example of the authentication content, to be displayed on the second user terminal 30B.
[0278] For example, the authentication selection screen SC9 described in Modification Example 1-8 may correspond to the authentication content. When it is determined that there is no change in the user information, the authentication content display unit 105 does not cause the authentication selection screen SC9, which is an example of the authentication content, to be displayed on the second user terminal 30B, and when it is determined that there is no change in the user information, the authentication content display unit 105 causes the authentication selection screen SC9, which is an example of the authentication content, to be displayed on the second user terminal 30B.
[0279] The authentication system 1 in modified example 3-2 determines whether a user meets the authentication conditions by determining whether or not there have been changes to the user information. This allows the authentication system 1 to display authentication content depending on whether or not there have been changes to the user information, thereby improving user convenience. For example, the authentication system 1 can prevent the display of authentication content for payment code authentication to users who do not meet the authentication conditions and are unable to perform payment code authentication.
[0280] [Modified example 3-3] For example, as explained to some extent in Modification 3-2, the authentication condition determination unit 104 may determine whether or not there has been a change in the user's phone number. In Modification 3-3, as in Modification 3-3, the user selects whether or not there has been a change in their phone number from the Change Requirement Screen SC4 as an example, but the system may also determine that there has been a change in the user's information if the user registers the changed phone number with another service or website that is linked to the payment service. The authentication condition determination unit 104 may obtain the changed phone number from the other service or website and determine whether or not there has been a change in the user's information, or it may request the other service or website to determine whether or not there has been a change in the user's information and receive the determination result from the other service or website.
[0281] For example, when the user selects button B40, the second user terminal 30B sends change information to the authentication server 10 indicating that there is no change in the phone number. When the user selects button B41, the second user terminal 30B sends change information to the authentication server 10 indicating that there is a change in the phone number. In the modified example 3-3, the authentication condition determination unit 104 may determine whether or not there is a change in the user information based on the change information received from the second user terminal 30B.
[0282] In Modification 3-3, as in Modification 3-2, the user may select whether or not to change their phone number from the first user terminal 30A. The first user terminal 30A sends change information to the authentication server 10. The authentication condition determination unit 104 may determine whether or not there has been a change in the user information based on the change information received from the first user terminal 30A. In Modification 3-3, as in Modification 1-11, the user may select whether or not to change their phone number by inputting information on the phone number input screen SC10 displayed on the first user terminal 30A.
[0283] The authentication system 1 in modified example 3-3 determines whether there has been a change in the user's phone number, thereby determining whether there has been a change in the user's information. This allows the authentication system 1 to display authentication content according to whether there has been a change in the phone number, thereby improving user convenience. For example, the authentication system 1 can prevent the display of authentication content for payment code authentication to a user whose phone number has not changed and who does not need payment code authentication.
[0284] [Modified example 3-4] For example, in the third embodiment, similar to Modification 2-6, the authentication condition determination unit 104 may determine whether the user satisfies the authentication conditions by determining whether the user possesses the first user terminal 30A. As explained in Modification 2-6, this determination method may be the same as that of the authentication unit 102 in Modification 1-9. For example, the authentication condition determination unit 104 may determine whether the user possesses the first user terminal 30A based on information transmitted by the first user terminal 30A (e.g., login account or terminal ID), information transmitted by the second user terminal 30B (e.g., login account or terminal ID), the usage status of the payment service from the first user terminal 30A (e.g., date and time of login, date and time of issuance of payment code C30, expiration date of payment code C30), or other information. Alternatively, the authentication unit 102 may determine whether the user possesses the first user terminal 30A based on information entered by the user regarding whether or not they possess the first user terminal 30A.
[0285] The authentication system 1 in modified example 3-4 determines whether a user meets the authentication conditions by determining whether the user possesses the first user terminal 30A. This allows the authentication system 1 to enhance security through authentication using the first user terminal 30A. For example, if the authentication system 1 performs authentication on the condition that the user possesses the first user terminal 30A, it can prevent the authentication process from being executed even if the user does not possess the first user terminal 30A.
[0286] [Modified example 3-5] For example, as explained to some extent in the third embodiment, the read information acquisition unit 107 may acquire read information if the user does not select telephone number authentication using the telephone number registered with the payment service. In the example in Figure 12, the user selects telephone number authentication by selecting button B40. The user selects not to perform telephone number authentication by selecting button B41.
[0287] For example, if the user selects button B41 but does not select telephone number authentication, the second user terminal 30B then activates the image capture unit 36B to display the reading screen SC8 on the display unit 35B and acquires the reading information. The second user terminal 30B transmits the reading information to the authentication server 10. The reading information acquisition unit 107 acquires the reading information from the second user terminal 30B. The authentication unit 102 performs payment code authentication if the user does not select telephone number authentication. For example, the authentication unit 102 performs payment code authentication if the user does not select telephone number authentication and performs an operation for payment code authentication. The flow of payment code authentication after the reading information has been acquired is the same as in the third embodiment.
[0288] In the modified example 3-5, the authentication system 1 obtains read information if the user does not select phone number authentication using the phone number registered with the payment service. If the user does not select phone number authentication, the authentication system 1 performs payment code authentication. This allows the authentication system 1 to perform highly secure payment code authentication, which requires the user to possess the first user terminal 30A, if the user does not select phone number authentication.
[0289] [Modification 3-6] For example, since payment code C30 is a hybrid code that can be used for both in-store payments and payment code authentication, authentication system 1 needs to determine whether to perform a payment or payment code authentication when it receives the read information. Authentication system 1 may store data for payment APIs and authentication APIs to make these determinations.
[0290] The payment API is an API for making payments. The payment API may be similar to APIs used in well-known payment services. When the payment API receives read information, it calls a function (program) for making payments. In Modification 3-6, the payment API is implemented by the payment server 20 as an example, but the payment API may be implemented by another computer, such as the authentication server 10. For example, when the payment API receives read information from a computer such as the store terminal 40, it executes a payment process. This process may be similar to the process of well-known payment services.
[0291] The authentication API is an API for authentication of payment codes. When the authentication API receives read information, it calls a function (program) for authentication of payment codes. In Modification 3-6, the case in which the authentication API is implemented by the authentication server 10 is given as an example, but the authentication API may be implemented by another computer such as the payment server 20. For example, when the authentication API receives read information from a computer such as the second user terminal 30B, it executes processing for authentication of payment codes. This processing is as described in the third embodiment.
[0292] In Modification 3-6, when the payment code C30 is read by the store terminal 40 in the payment service, the store terminal 40 sends read information to the payment API. For example, the store terminal 40 reads the payment code C30 displayed on the first user terminal 30A with the reading unit 46. The store terminal 40 obtains the code ID from the payment code C30 as read information. The store terminal 40 is assumed to have information about the payment API (e.g., URL or IP address) stored in advance. Based on this information, the store terminal 40 sends the code ID, which is an example of read information, to the payment API. When the payment API receives the code ID, it executes the payment.
[0293] In Modification 3-6, when the payment code C30 is read by the second user terminal 30B, the second user terminal 30B transmits the read information to an authentication API different from the payment API. For example, the second user terminal 30B reads the payment code C30 displayed on the first user terminal 30A with the imaging unit 36B. The second user terminal 30B obtains the code ID from the payment code C30 as read information. The second user terminal 30B is assumed to have pre-stored information for the authentication API (e.g., URL or IP address). Based on this information, the second user terminal 30B transmits the code ID, which is an example of read information, to the authentication API. The read information acquisition unit 107 acquires the read information transmitted to the authentication API. The processing after the read information is acquired may be the same as in the third embodiment.
[0294] Furthermore, if a payment is executed in which the second user terminal 30B reads a code displayed on the store terminal 40 or a code posted in the store, the second user terminal 30B will send the read information to the payment API, not the authentication API, when it reads these codes. The second user terminal 30B is assumed to have the payment API information (for example, URL or IP address) stored in advance.
[0295] For example, if the second user terminal 30B reads a store's code on the screen displayed when "Code Reading" is selected on the code screen SC3, it sends the reading information to the payment API. If the payment code C30 is read on the reading screen SC8, the second user terminal 30B sends the reading information to the authentication API. In this way, the second user terminal 30B may decide whether to send the information to the payment API or the authentication API depending on which screen the reading was performed on. The user may also choose whether to send the information to the payment API or the authentication API.
[0296] In variation 3-6, when the payment code C30 is read by the store terminal 40, the store terminal 40 sends the read information to the payment API. The second user terminal 30B sends the read information to an authentication API, which is different from the payment API. The authentication system 1 obtains the read information sent to the authentication API. As a result, the authentication system 1 can perform appropriate processing in each case, whether the payment code C30 is read by the store terminal 40 or by the second user terminal 30B, using the payment API and the authentication API.
[0297] [Modified example 3-7] For example, the first user terminal 30A may store configuration information related to the payment service. This configuration information indicates the settings for using the payment service. For example, the configuration information may include settings for the payment method used by the user with the payment service (e.g., payment source or charge source), settings for whether or not the user uses points, auto-charge settings, or other settings. The configuration information may also be other settings, such as screens or notifications displayed in the payment app, rather than settings for the payment method. If the user logs into the payment service from the second user terminal 30B and performs payment code authentication, the configuration information stored in the first user terminal 30A may be reflected in the second user terminal 30B. The configuration information may be displayed on the first user terminal 30A or the second user terminal 30B, or referenced when the authentication server 10 or the payment server 20 performs processing for the payment service.
[0298] The authentication system 1 in modified example 3-7 includes a configuration information application unit 114. When payment code authentication is performed, the configuration information application unit 114 applies the configuration information related to the payment service stored in the first user terminal 30A to the second user terminal 30B. For example, when payment code authentication is performed, the configuration information application unit 114 requests the first user terminal 30A to send configuration information. Upon receiving the request, the first user terminal 30A sends the configuration information stored in the data storage unit 300A to the authentication server 10. The configuration information application unit 114 applies the configuration information obtained from the first user terminal 30A to the second user terminal 30B by sending the configuration information to the second user terminal 30B.
[0299] The configuration information stored in a user's first user terminal 30A may be associated with the user's user ID and login account and may be stored in the authentication database DB1 in advance. In this case, the configuration information application unit 114 may retrieve the configuration information from the authentication database DB1 and apply it to the second user terminal 30B. The second user terminal 30B records the configuration information transmitted by the configuration information application unit 114 in the data storage unit 300B. The second user terminal 30B executes various processes in the payment service based on the configuration information stored in the data storage unit 300B.
[0300] In the modified version 3-7, when payment code authentication is performed, the authentication system 1 applies the setting information regarding the payment service stored in the first user terminal 30A to the second user terminal 30B. This eliminates the need for the user to perform any configuration work on the second user terminal 30B, thus improving user convenience.
[0301] [Modification 3-8] For example, a malicious third party may, by some means, obtain a screenshot (screen capture) of the payment code C30 on the first user terminal 30A and attempt to bypass the payment code authentication by impersonating the user. Therefore, in the modified example 3-8, if a screenshot operation is performed from the operation unit 34A while the payment code C30 is displayed on the first user terminal 30A, the payment code C30 may be invalidated.
[0302] The authentication system 1 of modified example 3-8 includes a payment code invalidation unit 115. The payment code invalidation unit 115 invalidates the payment code when a predetermined operation is performed on the payment code C30 at the first user terminal 30A. The predetermined operation is a screenshot operation performed while the payment code C30 is displayed. For example, the first user terminal 30A determines whether a screenshot operation has been performed while the payment code C30 is displayed. The method for determining whether a screenshot operation has been performed may be the same as a known method. For example, the first user terminal 30A determines whether a predetermined button on the operation unit 34A has been pressed.
[0303] For example, if the first user terminal 30A determines that a screenshot operation was performed while the payment code C30 was displayed, it sends an invalidation request to the authentication server 10 indicating that the payment code C30 should be invalidated. The invalidation request shall include the code ID, but it is sufficient if the invalidation request includes information that identifies which user's payment code C30 should be invalidated. For example, the invalidation request may include the user ID or login account. When the payment code invalidation unit 115 receives an invalidation request, it invalidates the target payment code C30. The authentication server 10 or payment server 20 will not execute the payment even if it receives a payment request that includes the code ID of an invalidated payment code C30. The authentication server 10 or payment server 20 will execute the payment when it receives a payment request that includes the code ID of a valid payment code C30.
[0304] For example, the payment code invalidation unit 115 may invalidate the payment code C30 by storing an invalidation flag in the authentication database DB1, associated with the code ID of the target payment code C30, indicating that the payment code C30 is invalid. In this case, even if a payment code C30 with an invalidation flag indicating invalidity is read, the payment code authentication or payment will fail. For example, the authentication unit 102 determines that payment code authentication has failed if the invalidation flag associated with the code ID of the payment code C30 subject to payment code authentication indicates that it is invalid.
[0305] Furthermore, the method by which the payment code invalidation unit 115 invalidates payment code C30 is not limited to the method using an invalidation flag. For example, the payment code invalidation unit 115 may invalidate payment code C30 by setting the expiration date of the code ID of the target payment code C30 to a past expiration date. The payment code invalidation unit 115 may also invalidate payment code C30 by deleting the code ID of the target payment code C30 from the authentication database DB1.
[0306] In the modified version 3-8, the authentication system 1 invalidates the payment code C30 when a predetermined operation is performed on the first user terminal 30A. As a result, even if a malicious third party illegally obtains a screenshot of the payment code C30, they will not be able to successfully authenticate the payment code, thus enhancing the security of the payment service.
[0307] [4-4. Other variations] For example, the above variations may be combined.
[0308] For example, in the first to third embodiments, the scenario of a user changing from a first user terminal 30A to a second user terminal 30B was given as an example, but the model of the first user terminal 30A and the model of the second user terminal 30B may be the same. The same processing as in the first to third embodiments may also be performed if the user purchases a second user terminal 30B of the same model because the battery of the first user terminal 30A has weakened. The user may have purchased the second user terminal 30B before purchasing the first user terminal 30A. Both the first user terminal 30A and the second user terminal 30B may be older.
[0309] For example, the authentication system 1 may not include an authentication server 10, and the authentication function may be implemented by a payment server 20. That is, the payment server 20 may have the functions of the authentication server 10 as described in the embodiment and the above modifications. In this case, the information described as being stored in the authentication database DB1 may be stored in the payment database DB2. The payment server 20 performs authentication of user login to the payment service. In the payment code authentication described in the third embodiment, when the second user terminal 30B reads the payment code C30 displayed on the code screen SC3 of the first user terminal 30A, it sends the code ID as read information to the payment server 20. The payment server 20 can perform payment code authentication by determining whether the user ID associated with the code ID received as read information from the second user terminal 30B matches the user ID of the user logged in from the second user terminal 30B.
[0310] For example, the functions described as being implemented by the authentication server 10 may be implemented by the payment server 20, the first user terminal 30A, the second user terminal 30B, the store terminal 40, or other computers. The processing described as being implemented by the authentication server 10 may be shared among multiple computers. The functions described as being implemented by the payment server 20 may be implemented by the authentication server 10, the first user terminal 30A, the second user terminal 30B, the store terminal 40, or other computers. The processing described as being implemented by the payment server 20 may be shared among multiple computers. For example, the case in which authentication functions are implemented by the authentication server 10 and payment functions are implemented by the payment server 20 has been given as an example, but the authentication functions and payment functions may be implemented by a single computer (for example, the authentication server 10, the payment server 20, or other computers).
[0311] [5. Addendum] For example, authentication system 1 can also be configured as follows:
[0312] [5-1. Notes concerning the first embodiment] For example, the authentication system 1 of the first embodiment can also be configured as follows. (1-1) A change necessity information acquisition unit acquires change necessity information regarding whether or not to change the telephone number registered with the service when a login to the service is made from a second user terminal different from the first user terminal after a login to the service has been made from the first user terminal. Based on the information regarding the need for change, the authentication unit switches the authentication performed from the second user terminal, An authentication system that includes this. (1-2) The authentication unit, If the change requirement information indicates that the aforementioned telephone number will not be changed, the first authentication using the aforementioned telephone number is performed. If the change requirement information indicates that the aforementioned telephone number should be changed, a second authentication different from the first authentication is performed. The authentication system described in (1-1). (1-3) If the change requirement information indicates that the telephone number will not be changed, the authentication unit will perform the same authentication as the authentication performed using the telephone number on the first user terminal, as the first authentication. The authentication system described in (1-2). (1-4) The authentication system further includes a function restriction unit that, when the second authentication is performed, restricts the functions related to the service used by the second user terminal to a degree greater than when the first authentication is performed. The authentication system described in (1-2) or (1-3). (1-5) The authentication system further includes a restriction release unit that releases the restriction on the function when predetermined release conditions are met. The authentication system described in (1-4). (1-6) The aforementioned authentication system is When the change requirement information indicates that the aforementioned telephone number should be changed, a user information acquisition unit acquires user information about the user, A second authentication proposal unit proposes an authentication method as the second authentication in which the user information satisfies predetermined authentication conditions, including, The authentication system described in any of (1-2) to (1-5). (1-7) The second authentication proposal unit determines whether the user information satisfies the authentication conditions by determining whether predetermined information regarding the possessions is associated with the user information. The authentication system described in (1-6). (1-8) The aforementioned service is a payment service, The second authentication proposal unit determines whether the predetermined information relating to the payment method that can be set in the payment service is associated with the user information. The authentication system described in (1-7). (1-9) The authentication system further includes a second authentication content display unit that, when the change requirement information indicates that the telephone number should be changed and predetermined authentication conditions are met, displays the second authentication content relating to the second authentication on the second user terminal. The authentication unit performs the second authentication when the second authentication content is displayed on the second user terminal. The authentication system described in any of (1-2) to (1-8). (1-10) The second authentication content display unit, when the change requirement information indicates that the telephone number should be changed and predetermined authentication conditions are met, distinguishes between the second authentication content and other authentication content related to other authentications different from the second authentication and displays them on the second user terminal. The authentication unit performs the second authentication or the other authentication when the second authentication content and the other authentication content are displayed separately on the second user terminal. The authentication system described in (1-9). (1-11) The authentication unit, when the change requirement information indicates that the telephone number should be changed and the first user terminal is possessed, performs the second authentication using the first user terminal. The authentication system described in any of (1-2) to (1-10). (1-12) The aforementioned service is a payment service in which payment is executed by reading a payment code. The authentication unit performs the second authentication, in which the payment code displayed on the first user terminal is read by the second user terminal. The authentication system described in (1-11). (1-13) The authentication unit, when the change requirement information indicates that the telephone number should be changed, performs the second authentication in which the changed telephone number is entered from the first user terminal. The authentication system described in any of (1-2) to (1-12).
[0313] [5-2. Notes concerning the second embodiment] For example, the authentication system 1 of the second embodiment can also be configured as follows. (2-1) A user information acquisition unit that acquires user information about users who use a specified service, An authentication condition determination unit that determines whether the user information satisfies predetermined authentication conditions related to authentication in the service, An authentication system that includes this. (2-2) The authentication system further includes an authentication content display unit that, if it is determined that the user information does not meet the authentication conditions, does not display the authentication content related to the authentication on the user's terminal, and if it is determined that the user information meets the authentication conditions, displays the authentication content on the user's terminal. The authentication system described in (2-1). (2-3) The authentication system further includes an alternative authentication content display unit that, if it is determined that the user information does not meet the authentication conditions, displays alternative authentication content related to an alternative authentication method different from the aforementioned authentication on the user terminal. The authentication system described in (2-2). (2-4) The authentication content display unit, when it is determined that the user information satisfies the authentication conditions, prioritizes displaying the authentication content on the user terminal. The authentication system described in (2-2) or (2-3). (2-5) The authentication system further includes an alternative authentication content display unit that, when it is determined that the user information satisfies the authentication conditions, displays alternative authentication content related to an alternative authentication to the authentication on the user terminal based on the user's selection of the authentication content. The authentication system described in any of (2-2) to (2-4). (2-6) The authentication condition determination unit determines whether the user information satisfies each of the authentication conditions of the plurality of authentications. When the authentication content display unit determines that the user information satisfies the authentication conditions for each of the multiple authentications, it displays the authentication content for at least one of the authentications on the user terminal based on the priority associated with each of the multiple authentications. The authentication system described in any of (2-2) to (2-5). (2-7) The authentication condition determination unit determines whether the user information satisfies the authentication conditions by determining whether predetermined information is associated with the user information. The authentication system described in any of (2-1) to (2-6). (2-8) The aforementioned service is a payment service, The authentication condition determination unit determines whether the predetermined information relating to the payment method that can be set in the payment service is associated with the user information. The authentication system described in (2-7). (2-9) The user information acquisition unit acquires the user information when a user who has used the service from a first user terminal logs in to the service from a second user terminal different from the first user terminal. The authentication condition determination unit determines whether the user information satisfies the authentication conditions by determining whether the user possesses the first user terminal. The authentication system described in any of (2-1) to (2-8). (2-10) The aforementioned service is a payment service in which payment is executed by reading a payment code. The authentication system further includes an authentication unit that, when it is determined that the user information satisfies the authentication conditions, performs authentication such that the payment code displayed on the first user terminal is read by the second user terminal. The authentication system described in (2-9).
[0314] [5-3. Notes concerning the third embodiment] For example, the authentication system 1 of the third embodiment can also be configured as follows. (3-1) When a payment code displayed on a first user terminal of a user using a payment service is read by a second user terminal different from the first user terminal, the system includes a reading information acquisition unit that acquires the reading information read from the payment code, When the aforementioned reading information is obtained, an authentication unit performs payment code authentication using the payment code, An authentication system that includes this. (3-2) The authentication system further includes a second user information acquisition unit that acquires second user information relating to the user who has logged in to the payment service from the second user terminal, When the read information is obtained, the authentication unit performs the payment code authentication based on the first user information and the second user information relating to the user who logged in to the payment service from the first user terminal. The authentication system described in (3-1). (3-3) The authentication system further includes a first user information acquisition unit that acquires the first user information based on the read information, When the read information is obtained, the authentication unit performs the payment code authentication based on the first user information obtained by the first user information acquisition unit and the second user information. The authentication system described in (3-2). (3-4) The aforementioned authentication system is An authentication condition determination unit that determines whether the user satisfies predetermined authentication conditions related to the payment code authentication, When it is determined that the user meets the authentication conditions, the authentication content display unit displays the authentication content related to the payment code authentication on the second user terminal. The authentication system described in any of (3-1) to (3-3), further including the above. (3-5) The authentication condition determination unit determines whether the user satisfies the authentication conditions by determining whether there has been a change in the user information relating to the user. The authentication system described in (3-4). (3-6) The authentication condition determination unit determines whether there has been a change in the user information by determining whether there has been a change in the user's telephone number. The authentication system described in (3-5). (3-7) The authentication condition determination unit determines whether the user satisfies the authentication conditions by determining whether the user possesses the first user terminal. The authentication system described in any of (3-4) to (3-6). (3-8) The read information acquisition unit acquires the read information if the user does not select telephone number authentication using the telephone number registered with the payment service. The authentication unit performs the payment code authentication if the user does not select the telephone number authentication. The authentication system described in any of (3-1) to (3-7). (3-9) When the payment code is read by the store terminal in the payment service, the store terminal transmits the read information to the payment API. When the payment code is read by the second user terminal, the second user terminal transmits the read information to an authentication API different from the payment API. The read information acquisition unit acquires the read information transmitted to the authentication API. The authentication system described in any of (3-1) to (3-8). (3-10) The authentication system further includes a configuration information application unit that applies the configuration information related to the payment service stored in the first user terminal to the second user terminal when the payment code authentication is performed. The authentication system described in any of (3-1) to (3-9). (3-11) The authentication system further includes a payment code invalidation unit that invalidates the payment code when a predetermined operation is performed on the first user terminal. The authentication system described in any of (3-1) to (3-10). [Explanation of symbols]
[0315] 1 Authentication system, N network, 10 Authentication server, 11,21,31A,31B,41 Control unit, 12,22,32A,32B,42 Storage unit, 13,23,33A,33B,43 Communication unit, 20 Payment server, 30A First user terminal, 30B Second user terminal, 34A,34B,44 Operation unit, 35A,35B,45 Display unit, 36A,36B Shooting unit, 40 Store terminal, 46 Reading unit, 100 Data storage unit, 101 Change requirement information acquisition unit, 102 Authentication unit, 103 User information acquisition unit, 104 Authentication condition determination unit, 105 Authentication content display unit, 106 Other authentication content display unit, 107 Reading information acquisition unit, 108 First user information acquisition unit, 109 Second user information acquisition unit, 110 Function restriction unit, 111 Restriction release unit, 112 Second authentication proposal unit, 113 Second authentication content display unit, 114 Setting information application unit, 115 Payment code invalidation unit, 200 Data storage unit, 201 Payment unit, 300A, 300B Data storage unit, 301A, 301B Operation reception unit, 302A, 302B Display control unit, 400 Data storage unit, 401 Payment request transmission unit, B10, B40, B41, B60 Buttons, C30 Payment code, DB1 Authentication database, DB2 Payment database, F70, F100 Input form, I81 Captured image, SC1 Login screen, SC2 Telephone number authentication screen, SC3 Code screen, SC4 Change required screen, SC5 First authentication screen, SC6 Second authentication screen, SC7 Other authentication screen, SC8 Reading screen, SC9 Authentication selection screen, SC10 Telephone number input screen.
Claims
1. An authentication condition determination unit determines whether a user satisfies predetermined authentication conditions for payment code authentication using the payment code by obtaining information from the second user terminal indicating whether the second user terminal has a camera unit before the payment code displayed on the first user terminal of a user using the payment service is read by a second user terminal different from the first user terminal, and determining whether the second user terminal has a camera unit, or by determining whether the user possesses the first user terminal based on information transmitted by at least one of the first user terminal and the second user terminal or the usage status of the payment service from the first user terminal, and determining whether the user satisfies predetermined authentication conditions for payment code authentication using the payment code. If it is determined that the user meets the authentication conditions before the payment code is read by the second user terminal, the authentication content related to the payment code authentication is displayed on a second user terminal different from the first user terminal. After the authentication content is displayed, if the payment code is read by the second user terminal, the reading information acquisition unit acquires the reading information read from the payment code. When the aforementioned reading information is obtained, an authentication unit performs the payment code authentication, An authentication system that includes this.
2. The authentication system further includes a second user information acquisition unit that acquires second user information relating to the user who has logged in to the payment service from the second user terminal, When the read information is obtained, the authentication unit performs the payment code authentication based on the first user information and the second user information relating to the user who logged in to the payment service from the first user terminal. The authentication system according to claim 1.
3. The authentication system further includes a first user information acquisition unit that acquires the first user information based on the read information, When the read information is obtained, the authentication unit performs the payment code authentication based on the first user information obtained by the first user information acquisition unit and the second user information. The authentication system according to claim 2.
4. An authentication condition determination unit determines whether a user satisfies predetermined authentication conditions related to payment code authentication using a payment code displayed on a first user terminal of a user using a payment service, by obtaining change information based on the selection result of whether or not there has been a change in the user's phone number from a second user terminal different from the first user terminal, and determining whether or not there has been a change in the user's phone number. If it is determined that the aforementioned telephone number has changed, the authentication content display unit displays the authentication content related to the payment code authentication on the second user terminal. When the payment code is read by the second user terminal, the reading information acquisition unit acquires the reading information read from the payment code, When the aforementioned reading information is obtained, the authentication unit performs the payment code authentication, and if it is determined that there is no change in the telephone number, the authentication unit performs telephone number authentication based on the telephone number with the second user terminal. An authentication system that includes this.
5. The authentication condition determination unit determines whether the user satisfies the authentication conditions by determining whether the user possesses the first user terminal. The authentication system according to any one of claims 1 to 4.
6. The read information acquisition unit acquires the read information if the user does not select telephone number authentication using the telephone number registered with the payment service. The authentication unit performs the payment code authentication if the user does not select the telephone number authentication. The authentication system according to any one of claims 1 to 4.
7. When the payment code is read by the store terminal in the payment service, the store terminal transmits the read information to the payment API. When the payment code is read by the second user terminal, the second user terminal transmits the read information to an authentication API different from the payment API. The read information acquisition unit acquires the read information transmitted to the authentication API. The authentication system according to any one of claims 1 to 4.
8. The authentication system further includes a payment code invalidation unit that invalidates the payment code when a predetermined operation is performed on the first user terminal. The authentication system according to any one of claims 1 to 4.
9. Computers An authentication condition determination step to determine whether the user satisfies predetermined authentication conditions for payment code authentication using the payment code, by obtaining information from the second user terminal indicating whether the second user terminal has a camera unit before the payment code displayed on the first user terminal of the user using the payment service is read by a second user terminal different from the first user terminal, and determining whether the second user terminal has a camera unit, or by determining whether the user possesses the first user terminal based on information transmitted by at least one of the first user terminal and the second user terminal or the usage status of the payment service from the first user terminal, If it is determined that the user meets the authentication conditions before the payment code is read by the second user terminal, the authentication content related to the payment code authentication is displayed on a second user terminal different from the first user terminal. After the authentication content is displayed, if the payment code is read by the second user terminal, the reading information acquisition step involves acquiring the reading information read from the payment code. When the aforementioned reading information is obtained, an authentication step is performed to execute the payment code authentication, The authentication method to use.
10. An authentication condition determination unit determines whether a user satisfies predetermined authentication conditions for payment code authentication using the payment code by obtaining information from the second user terminal indicating whether the second user terminal has a camera unit before the payment code displayed on the first user terminal of a user using the payment service is read by a second user terminal different from the first user terminal, and determining whether the second user terminal has a camera unit, or by determining whether the user possesses the first user terminal based on information transmitted by at least one of the first user terminal and the second user terminal or the usage status of the payment service from the first user terminal. If it is determined that the user meets the authentication conditions before the payment code is read by the second user terminal, the authentication content related to the payment code authentication is displayed on the second user terminal, which is different from the first user terminal. After the authentication content is displayed, if the payment code is read by the second user terminal, the read information acquisition unit acquires the read information read from the payment code. When the aforementioned reading information is obtained, the authentication unit performs the payment code authentication. A program that makes a computer function.