Authentication system, authentication condition determination method, and program
The authentication system addresses the inflexibility of existing systems by dynamically adjusting authentication methods based on user-specific conditions, enhancing both convenience and security.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-08-29
- Publication Date
- 2026-03-12
AI Technical Summary
Existing authentication systems lack flexibility and do not sufficiently improve user convenience, as they often require the same authentication method for all users, which may not be suitable for everyone.
An authentication system that includes a user information acquisition unit to gather user data and an authentication condition determination unit to dynamically adjust authentication methods based on user-specific conditions, such as changing phone numbers or device models, enhancing security and convenience.
The system provides flexible authentication options tailored to user needs, improving user convenience and security by allowing different authentication processes based on device changes or phone number updates.
Smart Images

Figure 2026043794000001_ABST
Abstract
Description
[Technical Field]
[0001] The present disclosure relates to an authentication system, an authentication condition determination method, and a program. [Background technology]
[0002] Conventionally, authentication for a user to use a predetermined service has been known. For example, Patent Document 1 describes a technology in which an authentication request including device-specific information specific to the user device is received from an application installed on the user device, an authentication request log is generated, the device-specific information is acquired from authentication information included in an SMS (Short Message Service) message, whether or not an authentication request log related to the device-specific information included in the authentication information exists, and if an authentication request log related to the device-specific information included in the authentication information exists, the device-specific information is stored in association with a telephone number. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] JP 2018-121099 A Summary of the Invention [Problem to be solved by the invention]
[0004] For example, in the technology of Patent Document 1, authentication that a user can perform from a user terminal is limited to authentication using an SMS message. However, since some users satisfy the authentication conditions for authentication in a service while others do not, the technology of Patent Document 1 lacks flexibility and does not sufficiently improve user convenience. This point is not limited to the technology of Patent Document 1, but is similar to other technologies that perform authentication.
[0005] One of the purposes of the present disclosure is to improve user convenience. [Means for solving the problem]
[0006] The authentication system according to the present disclosure includes a user information acquisition unit that acquires user information about a user who uses a specified service, and an authentication condition determination unit that determines whether the user information satisfies specified authentication conditions related to authentication in the service. [Effects of the Invention]
[0007] The present disclosure can improve convenience for users. [Brief explanation of the drawings]
[0008] [Figure 1] FIG. 2 is a diagram illustrating an example of a hardware configuration of the authentication system according to the first embodiment. [Figure 2] FIG. 4 is a diagram illustrating an example of a screen displayed on a first user terminal according to the first embodiment. [Figure 3] FIG. 10 is a diagram illustrating an example of a screen displayed on a second user terminal according to the first embodiment. [Figure 4] FIG. 2 is a diagram illustrating an example of functions realized in the authentication system of the first embodiment. [Figure 5] FIG. 3 is a diagram illustrating an example of an authentication database according to the first embodiment. [Figure 6] FIG. 3 is a diagram illustrating an example of a payment database according to the first embodiment. [Figure 7] FIG. 2 is a diagram illustrating an example of processing executed in the authentication system of the first embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of a screen displayed on a second user terminal according to the second embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of functions realized in an authentication system according to a second embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of processing executed in the authentication system of the second embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of processing executed in the authentication system of the second embodiment. [Figure 12] FIG. 11 is a diagram illustrating an example of a screen displayed on a second user terminal according to the third embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of functions realized in an authentication system according to a third embodiment. [Figure 14] FIG. 10 is a diagram illustrating an example of processing executed in the authentication system of the third embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of processing executed in the authentication system of the third embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of functions realized in a modification of the first embodiment. [Figure 17] FIG. 11 is a diagram showing an example of an authentication selection screen displayed on a second user terminal in Modification Example 1-8. [Figure 18] FIG. 11 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] FIG. 10 is a diagram showing an example of a screen displayed on a second user terminal in Modification Example 2-2. [Figure 20] FIG. 10 is a diagram showing an example of a screen displayed on a second user terminal in Modification Example 2-3. [Figure 21] FIG. 11 is a diagram illustrating an example of functions realized in a modification of the third embodiment. [Figure 22] FIG. 10 is a diagram showing an example of a screen displayed on a second user terminal in Modification Example 3-1. DETAILED DESCRIPTION OF THE INVENTION
[0009] [1. First embodiment] A first embodiment, which is an example of an embodiment of an authentication system, an authentication switching method, and a program according to the present disclosure, will be described.
[0010] [1-1. Hardware Configuration of the Authentication System of the First Embodiment] 1 is a diagram illustrating an example of the hardware configuration of an authentication system according to the first embodiment. For example, the authentication system 1 according to 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, the payment server 20, the first user terminal 30A, the second user terminal 30B, and the 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, the payment server 20, the first user terminal 30A, the second user terminal 30B, and the 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 a volatile memory such as RAM and a non-volatile memory such as a 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, an example is given in which a payment service corresponds to a predetermined service. Therefore, the phrase "payment service" can be read as "predetermined service." A payment service is a service that provides electronic payments (cashless payments) to users. The predetermined service may be a service other than a payment service. For example, the predetermined service may be an e-commerce service, a travel reservation service, an electronic ticket 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 executes payments in the payment service. For example, the payment server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be the same as those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. In the first embodiment, an example is given in which the authentication function and the payment function are shared 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 the authentication function but also the payment function. The payment server 20 may have not only the payment function but also the authentication function.
[0014] The first user terminal 30A is a user's computer. For example, the first user terminal 30A is a smartphone, a tablet, a personal computer, or a wearable terminal. The first user terminal 30A includes a control unit 31A, a memory unit 32A, a communication unit 33A, an operation unit 34A, a display unit 35A, and an imaging unit 36A. The hardware configurations of the control unit 31A, the memory unit 32A, and the communication unit 33A may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operation unit 34A is an input device such as a touch panel or a mouse. The display unit 35A is a display such as a liquid crystal or organic EL display. The imaging unit 36A includes at least one camera.
[0015] The second user terminal 30B is a 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 a 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 an image capture unit 36B. The hardware configurations of the control unit 31B, the storage unit 32B, the communication unit 33B, the operation unit 34B, the display unit 35B, and the image capture unit 36B may be the same as those of the control unit 31A, the storage unit 32A, the communication unit 33A, the operation unit 34A, the display unit 35A, and the image capture unit 36A, respectively.
[0016] The store terminal 40 is a computer of a store affiliated with the payment service. The store is not limited to a physical store that the user actually visits, but may also be an online store. For example, the store terminal 40 is a POS terminal, a self-checkout register, a handheld terminal, a smartphone, a tablet, or a personal computer. The store terminal 40 includes a control unit 41, a memory unit 42, a communication unit 43, an operation unit 44, a display unit 45, and a reading unit 46. The hardware configurations of the control unit 41, the memory unit 42, the communication unit 43, the operation unit 44, and the display unit 45 may be similar to those of the control unit 11, the memory unit 12, the communication unit 13, the operation unit 34A, and the display unit 35A, respectively. The reading unit 46 includes at least one code reader or reader / writer. The reading unit 46 may include at least one camera.
[0017] The programs stored in the memories 12, 22, 32A, 32B, 42 may be supplied to the authentication server 10, the payment server 20, the first user terminal 30A, the second user terminal 30B, or the store terminal 40 via the network N. Also, at least one of a reading unit (e.g., a memory card slot) that reads a computer-readable information storage medium and an input / output unit (e.g., a USB port) for inputting and outputting data to and from an external device may be included in the authentication server 10, the payment server 20, the first user terminal 30A, the second user terminal 30B, or the store terminal 40. For example, a program stored in an information storage medium may be supplied to the authentication server 10, the payment server 20, the first user terminal 30A, the second user terminal 30B, or the 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 FIG. 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 exist 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 exist outside the authentication system 1. For example, the authentication system 1 may include the authentication server 10 and other computers not shown in FIG. 1.
[0019] [1-2. Overview of the First Embodiment] The first embodiment takes as an example a case where a user uses a payment service from a payment app stored in the first user terminal 30A. The payment app is an application provided by a payment service administrator. Once the user installs the payment app on the first user terminal 30A and registers as a member of the payment service, the user will be able to use the payment service from the payment app. Note that the user may also use the payment service from a browser or from an app other than the payment app stored in the first user terminal 30A (for example, an app provided by a credit card company or other non-payment app).
[0020] Fig. 2 is a diagram showing an example of a screen displayed on the first user terminal 30A in the first embodiment. When a user operates the first user terminal 30A to launch a payment app as shown in the upper left of Fig. 2, the first user terminal 30A displays a 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 Fig. 2. For example, when a user selects button B10 and enters a login account and password, the first user terminal 30 performs login authentication between the first user terminal 30 and the authentication server 10 to allow the user to log in to the payment service. Note that the login authentication may be performed by the payment server 20.
[0021] In the first embodiment, an example is given of a case where a user is required to perform phone number authentication in addition to login authentication. For example, if a user does not perform phone number authentication, a predetermined usage restriction (e.g., a limit on the upper limit of the payment amount) may be set for the payment service. In this case, if the user performs phone number authentication, the user can lift the usage restriction. If a user does not perform phone number authentication, the user may not be able to use the payment service. In this case, if the user performs phone number authentication, the user will be able to use the payment service. Even if the user does not perform phone number authentication, the user may be able to use the payment service without any usage restriction. In this case, the user may be required to perform phone number authentication by a predetermined deadline.
[0022] For example, if the user has not yet performed phone number authentication, the first user terminal 30A displays a phone number authentication screen SC2 on the display unit 35A so that the user can perform phone number authentication, as shown in the lower left of Fig. 2. Even if the user has logged in to the payment service before, if the user has not performed phone number authentication (if the phone number is not registered with the payment service), the first user terminal 30A displays the phone number authentication screen SC2 on the display unit 35A and requests the user to perform phone number authentication. The user performs phone number authentication based on the flow guided on the phone number authentication screen SC2.
[0023] The flow of phone number authentication may be similar to known flows. The example in FIG. 2 shows a case where a call is made to an authentication phone number, but phone number authentication may also be performed by an incoming call to the user's phone number, by using SMS (Short Message Service), or by other methods. When phone number authentication is performed, the user's phone number is registered with the payment service. Other information, such as information that can identify the first user terminal 30A used by the user when logging in to the payment service, may also be registered with the payment service. Phone number authentication may also include checking the phone 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 including a payment code C30 generated based on a code ID that can temporarily identify the user on the display unit 35A, as shown in the lower right of Fig. 2. The payment code C30 is a code for payment. In the example in the lower right of Fig. 2, the payment code C30 includes a barcode and a two-dimensional code, 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 acquires a code ID from the payment code C30. When the store terminal 40 transmits the code ID acquired 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 that of known payment services. For example, when the validity of the code ID is confirmed, the payment is executed based on the payment means designated by the user as the payment source.
[0026] The payment may be performed by a method other than having the store terminal 40 read the payment code C30. For example, the payment may be performed by reading a code displayed on the store terminal 40 with the first user terminal 30A, by reading a code posted in the store with the first user terminal 30A, by completing the payment only with an operation on the first user terminal 30A, by using an IC chip in the first user terminal 30A, online payment (e.g., account payment using the user's account, or ID payment using the user's ID), carrier payment by the carrier used by the first user terminal 30A, or any other method. Alternatively, for example, the user may read a code on a bill with the first user terminal 30A and pay the bill. Similarly, the payment performed from the second user terminal 30B may be performed by any of these methods.
[0027] The first embodiment takes as an example a case where a user changes the model from a first user terminal 30A to a second user terminal 30B. For example, the user installs a payment app on the second user terminal 30B. When the user operates the second user terminal 30B to launch the payment app, the second user terminal 30B displays a 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 manner 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 second user terminal 30B, which is a new terminal, it requests authentication from the user that is separate from the login authentication. In the first embodiment, the authentication is switched depending on whether or not the phone number is changed.
[0028] 3 is a diagram showing an example of a screen displayed on the second user terminal 30B in the first embodiment. For example, when a user completes phone number authentication on the first user terminal 30A and then logs in to the payment service for the first time from the second user terminal 30B, the second user terminal 30B displays a change necessity screen SC4 on the display unit 35B, as shown in the upper right of FIG. 3, which asks the user whether or not to change the phone number. If the user does not want to change the phone number when changing the model, the user selects a button B40 indicating that the phone number will not be changed. If the user wants to change the phone number when changing the model, the user selects a button B41 indicating that the phone number will be changed.
[0029] In the first embodiment, if the phone number has not been changed, a predetermined authentication is requested of the user. Hereinafter, this authentication will be referred to as the first authentication. The first authentication is different from login authentication. In the first embodiment, an example is given in which phone number authentication corresponds to the first authentication, but the first authentication may be authentication other than phone number authentication. For example, the first authentication may be knowledge authentication that uses information other than a password for login authentication, biometric authentication such as face authentication or fingerprint authentication, or possession authentication that confirms possession of a credit card or the like.
[0030] For example, when the user selects button B40, as shown in the lower left of FIG. 3, the second user terminal 30B displays a first authentication screen SC5 on the display unit 35B, which allows the user to perform the first authentication. In the example shown in the lower left of FIG. 3, the first authentication screen SC5 has the same layout as the phone number authentication screen SC2, but the first authentication screen SC5 may have a different layout from the phone number authentication screen SC2. The first authentication screen SC5 may be the same screen as the phone number authentication screen SC2, or may be a different screen. The user performs the first authentication from the first authentication screen SC5 in a manner similar to the flow of performing phone number authentication from the phone 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 phone number.
[0031] In the first embodiment, when a telephone number has been changed, a different authentication from the first authentication is requested of the user. Hereinafter, this authentication is referred to as the second authentication. The second authentication is not only the first authentication but also different from login authentication. In the first embodiment, card scan authentication in which the user scans a credit card with the second user terminal 30B is taken as an example corresponding to the second authentication. However, the second authentication may be card scan authentication in which the user scans a card other than a credit card (such as an electronic money card or My Number card) held by the user. The second authentication may be authentication other than card scan authentication. For example, the second authentication may be knowledge authentication using information other than a password for login authentication, biometric authentication such as face authentication or fingerprint authentication, or possession authentication other than card scan authentication. For example, the second authentication may be authentication (a type of knowledge authentication) that requests the user to input the previous telephone number and confirms the authenticity of the previous telephone number. The second authentication may be authentication (a type of knowledge authentication) that requests the user to input user attribute information and confirms the authenticity of the user.
[0032] For example, when the user selects button B41, as shown in the lower right of FIG. 3, the second user terminal 30B displays a second authentication screen SC6 on the display unit 35B, which allows the user to perform the second authentication. In the first embodiment, a case is taken as an example in which the communication unit 33B of the second user terminal 30B supports short-range wireless communication (e.g., NFC (Near Field Communication)). The second user terminal 30B activates the short-range wireless communication function and scans a credit card. The flow of card scan authentication, which is an example of the second authentication, may be similar to a known flow. The second user terminal 30B performs the second authentication with the authentication server 10 based on the information read from the credit card.
[0033] For example, when the user performs the second authentication, the user becomes able to use the payment service from the second user terminal 30B. The user may register the 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. The user may register the changed phone number with the payment service by inputting the changed phone number from at least one of the first user terminal 30A and the second user terminal 30B before the second authentication. The user's old phone number (phone number before the change) may remain registered with the payment service, or may be overwritten with the changed phone number.
[0034] As described above, when a user who has been using a payment service from a first user terminal 30A changes their device and logs in to the payment service from a second user terminal 30B, the authentication system 1 of the first embodiment prompts the user to select, on the change necessity screen SC4, whether or not to change the phone number registered with the payment service. Based on the user's operation on the change necessity screen SC4, the authentication system 1 switches the authentication performed by the second user terminal 30B between the first authentication and the second authentication. By providing the user with flexible authentication depending on whether or not a phone number change is required, the authentication system 1 enhances user convenience while also improving security. Details of the authentication system 1 of the first embodiment will be described below.
[0035] [1-3. Functions realized by the authentication system of the first embodiment] 4 is a diagram showing an example of functions realized by the authentication system 1 of the first embodiment. The units realized by the authentication system 1 of the first embodiment can be configured by combining them into one device or by distributing the devices into smaller units.
[0036] [1-3-1. Functions realized by the authentication server] For example, the authentication server 10 includes a data storage unit 100, a change necessity information acquisition unit 101, and an authentication unit 102. The data storage unit 100 is realized by the storage unit 12. The change necessity information acquisition unit 101 and the authentication unit 102 are each realized by the control unit 11.
[0037] [Data storage section] The data storage unit 100 stores various data for authentication. For example, the data storage unit 100 stores an authentication database DB1.
[0038] FIG. 5 is a diagram showing an example of authentication database DB1 according to the first embodiment. Authentication database DB1 is a database that stores various types of information for authentication. For example, authentication database DB1 stores a user ID, a login account, a password, a code ID, an expiration date, a telephone number, and a terminal ID. The information stored in authentication database DB1 is not limited to the example shown in FIG. 5. Other information may also be stored in authentication database DB1. For example, authentication database DB1 may store personal information such as a user's name, or a user's login history to a 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. A login account may be freely changeable by a user. In the first embodiment, an example is given in which a login account exists in addition to a user ID (when there are at least two pieces of user identification information), but there may be only one piece of user identification information. In other words, the user ID and the login account do not need to be separate. A password is authentication information that is confirmed during login authentication.
[0040] Since a code ID is an ID that can temporarily identify a user, the code ID is also an example of user identification information. In the first embodiment, a case where the payment server 20 issues a code ID will be taken as an example. For example, when issuing a code ID for a certain user, the payment server 20 issues a new code ID so that it does not overlap with other code IDs. The payment server 20 transmits the new code ID for the user to the authentication server 10. The authentication server 10 stores the new code ID and expiration date in the authentication database DB1 in association with the user ID and login account of the user. 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 timing. For example, the payment server 20 may issue the code ID when the payment app is started, when the expiration date has passed, when the user instructs the issuance of a code ID, or at other timing. The code ID may be issued by the authentication server 10 or another computer, rather than by the payment server 20. An expiration date may not be set for the code ID. For example, the code ID may be a semi-permanently valid ID with no particular expiration date set.
[0042] Furthermore, the code ID may be issued by the authentication server 10, not by the payment server 20. In this case, the payment server 20 may acquire the code ID issued by the authentication server 10 and store it in the payment database DB2. Furthermore, the authentication server 10 does not have to manage the code ID in particular. The expiration date of the code ID may also be determined by the authentication server 10, not by the payment server 20. The payment server 20 acquires 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 numbers stored in the authentication database DB1 are telephone numbers registered in 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 associates the telephone number of the first user terminal 30A with the user ID and login account of the user and stores the telephone number of the first user terminal 30A in the authentication database DB1, thereby registering the telephone number in the payment service. 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 the user logs in to the payment service from the first user terminal 30A or the second user terminal 30B for the first time. The terminal identification information may be information other than 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 the 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 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 certain 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 the telephone number authentication with the terminal ID and store them in the authentication database DB1. The authentication server 10 may store the terminal ID of the second user terminal 30B for which the first authentication or the second authentication has been completed in the authentication database DB1. When the user registers a changed telephone number with a payment service, the authentication server 10 may associate the changed telephone number with the terminal ID of the second user terminal 30B and store them in the authentication database DB1.
[0046] The authentication database DB1 may store execution information indicating whether each of the phone number authentication, the first authentication, and the second authentication has been executed. When a user executes authentication, the authentication unit 102 (described later) stores execution information indicating that the authentication has been executed in the authentication database DB1, in association with the user ID and login account of the user. The authentication server 10 or the payment server 20 may provide a payment service to a user based on the execution information of the user. For example, if a user has not executed a specific authentication, the authentication server 10 or the payment server 20 may restrict the user from using the payment service.
[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 the second user terminal 30B that performed the second authentication, or may restrict use of the payment service from at least one of them. The authentication server 10 or the payment server 20 may restrict use of the payment service from the second user terminal 30B that performed the first authentication more than 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 use of the payment service from the second user terminal 30B that performed the second authentication more than use of the payment service from the second user terminal 30B that performed the first authentication. Which authentication was performed may be identified by the performed authentication information.
[0048] Furthermore, the data stored in the data storage unit 100 is not limited to the above examples. The data storage unit 100 may store any data for authentication. For example, the data storage unit 100 may store data necessary for displaying a login screen SC1, a phone number authentication screen SC2, a code screen SC3, a change necessity screen SC4, a first authentication screen SC5, a second authentication screen SC6, or other screens. The data storage unit 100 may store a program that indicates each authentication process described in the first embodiment.
[0049] [Change Necessity Information Acquisition Section] The change necessity information acquisition unit 101 acquires change necessity information regarding whether or not to change the telephone number registered in the payment service when a user logs in to a payment service (an example of a predetermined service) from a first user terminal 30A and then logs in to the payment service from a second user terminal 30B different from the first user terminal 30A. It is assumed that the first user terminal 30A and the second user terminal 30B are 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 necessity information indicates whether the telephone number is to be changed or not to be changed. In the first embodiment, the case where the change necessity information acquisition unit 101 acquires the change necessity information from the second user terminal 30B is exemplified, but the change necessity information acquisition unit 101 may acquire the change necessity information from the first user terminal 30A, the payment server 20, another computer, or an information storage medium.
[0051] For example, when the user selects buttons B40 and B41 on the change necessity screen SC4, the second user terminal 30B generates change necessity information based on the user's selection result and transmits it to the authentication server 10. When the user selects button B40, the second user terminal 30B transmits change necessity information indicating that the phone number will not be changed to the authentication server 10. When the user selects button B41, the second user terminal 30B transmits change necessity information indicating that the phone number will be changed to the authentication server 10.
[0052] Whether or not to change the phone number may be selected using parts other than buttons B40 and B41. The other parts may be known parts used as a user interface. For example, whether or not to change the phone number may be selected using a radio button, a check box, a panel, an icon, or text. Whether or not to change the phone number may be selected from a screen other than the change necessity screen SC4. The user may select whether or not to change the phone number from the first user terminal 30A and register the change necessity information in advance in the authentication database DB1. In this case, the change necessity information acquisition unit 101 may acquire the change necessity information from the authentication database DB1. The change necessity information acquisition unit 101 may acquire the change necessity information from a database other than the authentication database DB1.
[0053] Furthermore, whether or not to change the phone number may be determined automatically, rather than being determined by the user himself / herself. For example, when a user logs in to a payment service from the second user terminal 30B, the second user terminal 30B may obtain the phone number the user registered with the payment service from the authentication server 10 and compare it with the phone number stored in the second user terminal 30B (e.g., on a SIM card) to determine whether or not to change the phone number. If the phone number of another service linked to the payment service (e.g., a service that comprehensively manages user information) is changed, the phone number registered with the payment service may differ from the phone number of the other service. In this case, it may be determined that the phone number will be changed. If these phone numbers match, the second user terminal 30B may transmit change necessity information to the authentication server 10 indicating that the phone number will not be changed. If these phone numbers do not match, the second user terminal 30B may transmit change necessity information to the authentication server 10 indicating that the phone number will be changed. The change necessity information acquisition unit 101 acquires the change necessity information from the second user terminal 30B.
[0054] For example, the second user terminal 30B may accept a phone number input by the user and transmit the phone number input by the user to the authentication server 10. The second user terminal 30B may transmit a phone number stored in itself (for example, a SIM card) to the authentication server 10, instead of accepting a phone number input by the user. The change necessity information acquisition unit 101 may acquire change necessity information by comparing the phone number registered in the payment service with the phone number acquired from the second user terminal 30B. If these phone numbers match, the change necessity information acquisition unit 101 may acquire change necessity information indicating that the phone number should not be changed. If these phone numbers do not match, the change necessity information acquisition unit 101 may acquire change necessity 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, instead of 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 necessity information acquisition unit 101 may acquire change necessity information by comparing the phone number registered in the payment service with the phone number acquired from the first user terminal 30A. If these phone numbers match, the change necessity information acquisition unit 101 may acquire change necessity information indicating that the phone number should not be changed. If these phone numbers do not match, the change necessity information acquisition unit 101 may acquire change necessity information indicating that the phone number should be changed.
[0056] [Authentication section] 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 necessity information. Switching the authentication means varying the authentication depending on the change necessity information (using different authentications). The authentication unit 102 requests different authentication from a user who logs in to the payment service from the second user terminal 30B when the change necessity information indicates that the phone number should not be changed and when the change necessity information indicates that the phone number should be changed.
[0057] In the first embodiment, the authentication unit 102 performs a first authentication using the telephone number when the change necessity information indicates that the telephone number will not be changed, and performs a second authentication different from the first authentication when the change necessity 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 necessity information indicates that the telephone number will not be changed, and performs card scan authentication as the second authentication when the change necessity information indicates that the telephone number will be changed. That is, the authentication unit 102 switches the authentication requested of the user between the first authentication and the second authentication based on the change necessity information.
[0058] Note that the authentication unit 102 may execute the first authentication based on other conditions in addition to the change necessity information indicating that the telephone number will not be changed. The authentication unit 102 does not have to immediately execute the first authentication just because the change necessity information indicates that the telephone number will not be changed. For example, the authentication unit 102 may execute the first authentication when the change necessity information indicates that the telephone 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 the screen). Such a mode is also included in the execution of the first authentication by the authentication unit 102 when the change necessity information indicates that the telephone number will not be changed. The other conditions are not limited to the display of a screen or a user operation. For example, the other conditions may be 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.
[0059] Similarly, the authentication unit 102 may execute the second authentication based on other conditions in addition to the change necessity information indicating that the phone number is to be changed. The authentication unit 102 does not have to immediately execute the second authentication just because the change necessity information indicates that the phone number is to be changed. For example, the authentication unit 102 may execute the second authentication when the change necessity information indicates that the phone number is to be changed and the user performs an operation for the second authentication. Such an embodiment is also included in the execution of the second authentication by the authentication unit 102 when the change necessity information indicates that the phone number is to be changed. The other conditions are not limited to the user's operation. For example, the other conditions may be 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 authentication and the second authentication may be any combination. The combination of the first authentication and the second authentication is not limited to phone number authentication and card scan authentication. For example, the first authentication may be authentication that does not use a phone number. Conversely, the second authentication may be authentication that uses a phone 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 authentication and the second authentication may both be knowledge authentication, but the specific authentication methods may be different from each other. The first authentication and the second authentication may both be biometric authentication, but the specific authentication methods may be different from each other. The first authentication and the second authentication may both be possession authentication, but the specific authentication methods may be different from each other.
[0061] For example, when the change necessity information indicates that the phone number should not be changed, the authentication unit 102 executes phone number authentication, which is an example of the first authentication, with the second user terminal 30B. The authentication unit 102 executes phone number authentication, which is an example of the first authentication, based on an incoming call from the second user terminal 30B, a call made to the second user terminal 30B, or an SMS message sent to the second user terminal 30B. The authentication unit 102 may execute 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 execute phone number authentication, which is an example of the first authentication, with the first user terminal 30A.
[0062] For example, when the change necessity information indicates that the phone number should be changed, the authentication unit 102 executes card scan authentication, which is an example of the second authentication, with the second user terminal 30B. The second user terminal 30B acquires authentication information stored in the credit card using the short-range wireless communication function of the communication unit 33B and transmits the information to the authentication server 10. The authentication unit 102 communicates with another computer of a card company, etc., as necessary, to confirm the validity of the authentication information acquired from the second user terminal 30B. When the authentication unit 102 stores information necessary for card scan authentication, it may execute the second authentication without communicating with another computer. The authentication unit 102 may execute other authentication, such as authentication using a security code written on the back of a credit card, as the second authentication.
[0063] 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 input a new phone number. Thereafter, the second user terminal 30B may transition to a second authentication screen SC6, where card scan authentication is performed as the second authentication, or may transition to a reading screen SC8 in a third embodiment described below, where payment code authentication is performed as the second authentication, or may execute authentication by having the old phone number and the new phone number entered on the same screen as the second authentication. If authentication for changing the model and authentication for changing the phone number are performed separately, the user will have to work harder. However, if the authentication system 1 only requires one authentication, the second authentication, the user's work can be reduced, thereby improving user convenience and enhancing security.
[0064] Furthermore, the authentication unit 102 may perform authentication other than the first authentication and the second authentication. For example, the authentication unit 102 may perform login authentication, or may perform authentication other than the first authentication, the second authentication, and the login authentication. The specific processing of each authentication may be the same as the processing employed in known authentication, or may be a new authentication as described in the third embodiment. In the first embodiment, the configuration in which the authentication unit 102 switches authentication depending on the change necessity information is a new configuration, but the specific flow of each authentication may be the same as a known flow.
[0065] [1-3-2. Functions realized 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 realized by the storage unit 22. The payment unit 201 is realized by the control unit 21.
[0066] [Data storage section] The data storage unit 200 stores various data for payment. For example, the data storage unit 200 stores a payment database DB2.
[0067] FIG. 6 is a diagram showing an example of the payment database DB2 of the first embodiment. The payment database DB2 is a database in which various information for payment is stored. For example, the payment database DB2 stores a user ID, a login account, a code ID, an expiration date, payment method information, payment source information, and charging source information. The information stored in the payment database DB2 is not limited to the example of FIG. 6. Other information may also be stored in the payment database DB2. For example, the payment database DB2 may store a telephone number, a terminal ID, or a payment service usage history. Note that when the payment server 20 issues a code ID, the code ID of the payment server 20 is linked to the authentication server 10 as needed.
[0068] Payment method information is information that can identify a payment method. For example, payment method information is information such as a credit card number, electronic money number, bank account number, or point card number. Payment source information is information that can identify a payment method selected as a payment source. A payment source is a payment method used to pay for goods or services handled by a store. Charging source information is information that can identify a payment method selected as a charging source. A charging source is a payment method that serves as the source of funds for charging.
[0069] The data stored in the data storage unit 200 is not limited to the above examples. The data storage unit 200 may store any data for payment. For example, the data storage unit 200 may store data necessary for displaying a login screen SC1, a phone number authentication screen SC2, a code screen SC3, a change necessity screen SC4, a first authentication screen SC5, a second authentication screen SC6, or other screens. The data storage unit 200 may also store a store database that stores various information related to stores.
[0070] [Payment Department] The settlement unit 201 executes settlement in a settlement service. The processing executed by the settlement unit 201 may be similar to processing of known settlement services. For example, when the settlement unit 201 receives a settlement request from the store terminal 40, it executes settlement based on the settlement request. The settlement unit 201 acquires payment source information associated with the code ID included in the settlement request from the settlement database DB2, and executes settlement of the payment amount included in the settlement request based on the payment source information. The settlement unit 201 may execute settlement when it receives a settlement request from the first user terminal 30A or the second user terminal 30B.
[0071] [1-3-3. Functions realized by 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 realized by the storage unit 32A. The operation reception unit 301A and the display control unit 302A are realized by the control unit 31A.
[0072] [Data storage section] The data storage unit 300A stores data necessary for the user to use a payment service. For example, the data storage unit 300A stores a payment app. If the user uses a payment service from another app or browser instead of the payment app, the data storage unit 300A stores the other app or browser. The data storage unit 300A may store a phone number, a code ID, a terminal ID, payment service settings, or other information.
[0073] [Operation reception section] The operation accepting unit 301A accepts various operations from the user. For example, the operation accepting unit 301A accepts operations for the payment application. The operation accepting unit 301A transmits data indicating the content of the user's operation to the authentication server 10 or the payment server 20.
[0074] [Display control section] The display control unit 302A displays various screens on the display unit 35A. For example, the display control unit 302A displays each of a login screen SC1, a phone number authentication screen SC2, and a code screen SC3 on the display unit 35A. The display control unit 302A communicates with the authentication server 10 or the payment server 20, receives display data for these screens, and displays these screens on the display unit 35A based on the display data. The display data is data necessary for displaying a screen. The display data may be data for the entire screen or data for a portion 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 realized by 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 realized by the storage unit 32B. The operation reception unit 301B and the display control unit 302B are realized by the control unit 31B.
[0076] [Data storage section] Data storage unit 300B stores data necessary for the user to use a payment service. For example, data storage unit 300B stores a payment app. If the user uses a payment service from another app or browser rather than the payment app, data storage unit 300B stores the other app or browser. Data storage unit 300B may store a phone number, a code ID, a terminal ID, payment service settings, or other information.
[0077] [Operation reception section] The operation accepting unit 301B accepts various operations from the user. For example, the operation accepting unit 301B accepts operations for the payment application. The operation accepting unit 301B transmits data indicating the content of the user's operation to the authentication server 10 or the payment server 20.
[0078] [Display control section] The display control unit 302B displays various screens on the display unit 35B. For example, the display control unit 302B displays each of a login screen SC1, a code screen SC3, a change necessity screen SC4, a first authentication screen SC5, and a 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, receives display data for these screens, and displays these screens on the display unit 35B based on the display data.
[0079] [1-3-5. Functions realized by 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 realized by the storage unit 42. The payment request transmission unit 401 is realized by the control unit 41.
[0080] [Data storage section] 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 that stores various information such as prices of products 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 sending section] The payment request sending 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 sending unit 401 acquires a code ID from the payment code C30. The payment request sending unit 401 sends a payment request including information necessary for payment, such as the code ID, payment amount, and store ID, to the authentication server 10. The payment request may be any request used in known payment services.
[0082] [1-4. Processing Executed in the Authentication System of the First Embodiment] FIG. 7 is a diagram showing an example of processing executed in authentication system 1 of the first embodiment. FIG. 7 shows processing executed when a user logs in to a payment service from second user terminal 30B, among the processing executed in authentication system 1. The processing of FIG. 7 is executed by control units 11 and 31B executing programs stored in storage units 12 and 32B, respectively. The same processing as that of FIG. 7 is also executed when a user logs in to a payment service from first user terminal 30A. The steps of FIG. 7 are an example of an authentication switching method in the first embodiment.
[0083] As shown in FIG. 7, when the second user terminal 30B launches the payment app, it executes processing with the authentication server 10 to display the login screen SC1 (S100). The second user terminal 30B may communicate with the payment server 20 instead of the authentication server 10 to display the login screen SC1 on the display unit 35B. This also applies to the subsequent processing. The second user terminal 30B executes login authentication with the authentication server 10 (S101). In S101, the authentication server 10 executes login authentication by acquiring the login account and password entered by the user from the second user terminal 30B and determining whether 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 a login history of users to the payment service. In S102, the authentication server 10 determines whether the user has previously logged in 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 phone number authentication with the second user terminal 30B (S103), and this process ends. In S103, the authentication server 10 causes the second user terminal 30B to display the phone number authentication screen SC2 or the first authentication screen SC5, and performs phone number authentication.
[0085] If it is determined in S102 that a user with a new user ID has not logged in (S102: N), the authentication server 10 determines whether or not a phone number is registered with the payment service based on the authentication database DB1 (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. If it is determined in S104 that a phone number is not registered with the payment service (S104: N), the process proceeds to S103, where phone number authentication is performed.
[0086] If it is determined in S104 that the phone number is registered with the payment service (S104: Y), the authentication server 10 determines whether the login is from a new terminal based on the authentication database DB1 (S105). In S105, the authentication server 10 acquires a terminal ID from the second user terminal 30B, and determines whether the terminal ID is associated with the login account entered at the time of login and stored in the authentication database DB1. If it is determined in S105 that the login is not from a new terminal (S105: N), this process ends. In this case, the authentication server 10 may notify the payment server 20 that the second user terminal 30B is not a new terminal, and a process for displaying the code screen SC3 may be executed between the payment server 20 and the second user terminal 30B.
[0087] If it is determined in S105 that the login is from a new terminal (S105: Y), the second user terminal 30B executes processing with the authentication server 10 to display the change necessity screen SC4 (S106). The second user terminal 30B transmits change necessity information based on the operation content on the change necessity screen SC4 (S107). In S107, button B40 or button B41 is selected. If the user performs another operation, processing corresponding to the other operation is executed, and this processing ends. The authentication server 10 acquires the change necessity information from the second user terminal 30B (S108).
[0088] The authentication server 10 determines whether the change necessity information indicates that the telephone number should be changed (S109). If it is determined in S109 that the change necessity information indicates that the telephone number should not be changed (S109: N), the authentication server 10 executes a first authentication with the second user terminal 30B (S110), and this processing ends. In S110, the authentication server 10 displays a first authentication screen SC5 on the second user terminal 30B, and executes telephone number authentication as the first authentication with the second user terminal 30B.
[0089] If it is determined in S109 that the change necessity information indicates that the phone number should be changed (S109: Y), the authentication server 10 executes second authentication with the second user terminal 30B (S111), and this process ends. In S111, the authentication server 10 displays a second authentication screen SC6 on the second user terminal 30B, and executes card scan authentication as the second authentication with the second user terminal 30B.
[0090] [1-5. Summary of the first embodiment] The authentication system 1 of the first embodiment acquires change necessity information when a user who uses a payment service from a first user terminal 30A logs in to the service from a second user terminal 30B different from the first user terminal 30A. The authentication system 1 switches the authentication performed from the second user terminal 30B based on the change necessity information. The authentication system 1 can improve security while enhancing user convenience by providing the user with flexible authentication depending on whether or not the phone number needs to be changed. For example, as described in the first embodiment, the second authentication may be performed by having the user enter both the old and new phone numbers on the same screen. In this case, the authentication system 1 can perform only one authentication, the second authentication, thereby improving user convenience and enhancing security. For example, the authentication system 1 not only improves convenience for legitimate users but also enhances security by preventing unauthorized users from logging in from different terminals.
[0091] Furthermore, when the change necessity information indicates that the telephone number will not be changed, the authentication system 1 performs the first authentication. When the change necessity information indicates that the telephone number will be changed, the authentication system 1 performs the second authentication. This allows the authentication system 1 to appropriately use the first authentication and the second authentication depending on whether the telephone number will be changed, thereby improving user convenience and security.
[0092] [2. Second Embodiment] A second embodiment will be described, which is an example of an embodiment of the authentication system 1, authentication condition determination method, and program according to the present disclosure. In the second embodiment, a description of the same configuration as in the first embodiment will be omitted. 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, as in the first embodiment, an example is given of a case where a user changes the model 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, an example is given of a case where only certain credit cards support card scan authentication. In this case, card scan authentication cannot be performed unless the user has a credit card that supports card scan authentication.
[0094] For example, even if a user has a credit card that supports card scan authentication, the communication unit 33B of the second user terminal 30B may not support near-field wireless communication. In this case, the user cannot perform card scan authentication. This is not limited to card scan authentication, but also applies to other authentications. Some users may not be able to perform a particular authentication. Therefore, in the second embodiment, the screen displayed on the second user terminal 30B changes depending on whether a predetermined authentication condition is met.
[0095] FIG. 8 is a diagram showing an example of a screen displayed on the second user terminal 30B in the second embodiment. For example, when a user logs in to a payment service from the second user terminal 30B, the second user terminal 30B displays a change necessity screen SC4, similar to that of the first embodiment, on the display unit 35B, as shown in the upper right of FIG. 3. The display flow of the change necessity screen SC4 may be the same as that of the first embodiment. The flow after the user selects button B40 may also be the same as that of the first embodiment. When the user selects button B41, the authentication server 10 determines whether the authentication conditions for card scan authentication are met. The method of this determination will be described in detail later.
[0096] For example, if it is determined that the authentication conditions for card scan authentication are met, the second user terminal 30B displays a second authentication screen SC6 for card scan authentication on the display unit 35B, as in the first embodiment, as shown in the lower left of Fig. 8. If it is determined that the authentication conditions for card scan authentication are not met, the second user terminal 30B displays an other authentication screen SC7 for the user to perform another authentication different from card scan authentication on the display unit 35B, as shown in the lower right of Fig. 8.
[0097] The other authentication may be any authentication. For example, the other authentication may be authentication for which other authentication conditions, such as a specific credit card and a near-field wireless communication function, are set. In the example at the bottom right of FIG. 8, one-time password authentication is performed as an example of the other authentication. The flow of one-time password authentication may be similar to a known flow. For example, the user may perform one-time password authentication by checking the one-time password in another app that issues one-time passwords and entering the one-time password in input form F70.
[0098] As described above, when it is determined that the authentication conditions for card scan authentication are met, the authentication system 1 of the second embodiment displays the second authentication screen SC6 for card scan authentication on the second user terminal 30B. When it is determined that the authentication conditions for card scan authentication are not met, the authentication system 1 displays the other authentication screen SC7 for one-time password authentication on the second user terminal 30B. This allows the authentication system 1 to display different screens on the second user terminal 30B depending on whether the authentication conditions for card scan authentication are met, thereby improving user convenience and security. The second embodiment will be described in detail below.
[0099] [2-2. Functions realized by the authentication system of the second embodiment] Fig. 9 is a diagram showing an example of functions realized by the authentication system 1 of the second embodiment. Although some of the functions described in the first embodiment are not shown in Fig. 9, the authentication system 1 of the second embodiment may include the functions described in the first embodiment. The units realized by the authentication system 1 of the second embodiment can be configured by combining them into one device or by distributing them among more finely divided devices.
[0100] The authentication system 1 of the second embodiment may not include the function described in the first embodiment (the function of switching authentication depending on the change necessity information). For example, the authentication system 1 of the second embodiment may determine whether the authentication conditions are met regardless of whether the phone number is changed. The authentication system 1 of the second embodiment may not include the function described in the first embodiment, and phone number authentication may not be performed in the first place, and the phone number may not be registered in the payment service.
[0101] As described above, an aspect in which the authentication system 1 does not include the functions described in the first embodiment but includes the functions described in the second embodiment is within the scope of the present disclosure. Naturally, an aspect in which the authentication system 1 includes the functions described in the first embodiment and the functions described in the second embodiment is also within the scope of the present disclosure. These points are matters that can be naturally understood by a person skilled in the art from the description of the present disclosure.
[0102] [2-2-1. Functions realized 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 .
[0103] [Data storage section] 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 authentication conditions. For example, the authentication database DB1 may store ownership information indicating whether or not the user holds a specific credit card. The ownership information may be stored in a database other than the authentication database DB1, in a computer other than the authentication server 10, or in an information storage medium. The data storage unit 100 may store data necessary for displaying the other authentication screen SC7.
[0104] [User information acquisition section] The user information acquisition unit 103 acquires user information about a user who uses a payment service. In the second embodiment, as in the first embodiment, the payment service is an example of a predetermined service. Therefore, the phrase "payment service" can be replaced with any other service. The authentication system 1 of the second embodiment can also be applied to any service, such as an e-commerce service.
[0105] User information is information about a user that is used to determine whether authentication conditions are satisfied. For example, user information may be information associated with a user ID (information searchable based on the user ID), or may be information acquired from the first user terminal 30A or the second user terminal 30B. In the second embodiment, an example is given in which user information corresponds to possession information indicating whether a user possesses a specific credit card. The possession information may be payment method information stored in the payment database DB2, or may be information different from the payment method information. The possession information may be the card number of a specific credit card, identification information of a function (e.g., electronic money or points) associated with a specific credit card, or other information.
[0106] In the second embodiment, the case where the possessed information is stored in authentication database DB1 will be taken as an example. For example, when a user logs in to a payment service, user information acquisition unit 103 refers to authentication database DB1 and acquires possessed information associated with the user's user ID as user information. User information acquisition unit 103 may acquire possessed information as user information from a database other than authentication database DB1 (e.g., payment database DB2), a computer other than authentication server 10 (e.g., payment server 20, first user terminal 30A, second user terminal 30B, or a computer of another service linked to the payment service), or an information storage medium.
[0107] The user information may be information other than the possessed information. For example, the user information may be information about a payment method of a user that is not registered with the payment service. In this case, the user information may be stored in a database of a service other than the payment service. For example, the user information acquisition unit 103 may acquire the user information from a computer of a card company that issued a credit card that supports card scan authentication. The user information acquisition unit 103 may acquire the user information from a computer of a company that manages functions (e.g., electronic money or points) associated with credit cards that support card scan authentication.
[0108] Furthermore, the user information is not limited to information regarding the payment method held by the user. For example, the user information may indicate whether the communication unit 33B of the second user terminal 30B supports a short-range wireless communication function. In this case, the second user terminal 30B transmits user information indicating whether the communication unit 33B supports the short-range wireless communication function to the authentication server 10. The user information acquisition unit 103 acquires user information from the second user terminal 30B. If a function other than the short-range wireless communication function (for example, a photographing function by the photographing unit 36B) is required for a specific authentication, the user information acquisition unit 103 may acquire user information indicating whether the second user terminal 30B has the other function from the second user terminal 30B.
[0109] For example, if a user needs to register authentication information to be used in a particular authentication in advance, the authentication information may correspond to user information. The authentication information may be any information, such as a password, a passcode, a facial photograph, a fingerprint pattern, a password, an answer to a predetermined question, or other authentication information. The authentication information may be stored in advance in the authentication database DB1. The user information acquisition unit 103 acquires the authentication information stored in the authentication database DB1 as the user information. The user information acquisition unit 103 may acquire, instead of the authentication information, information indicating whether the authentication information has been registered in advance as the user information.
[0110] [Authentication condition determination section] The authentication condition determination unit 104 determines whether the user information satisfies predetermined authentication conditions related to authentication in the payment service. The authentication conditions are conditions required for the authentication unit 102 to perform authentication. In other words, the authentication conditions are conditions indicating whether the logged-in user is in an environment where authentication can be performed. For example, if authentication requires the user to possess a specific item (e.g., a specific credit card), the authentication condition is that the user possesses the item. If authentication requires that specific user information be registered with the payment service, the authentication condition is that the user information is registered with the payment service. If authentication requires that the second user terminal 30B have a specific function (e.g., a short-range wireless communication function or a photographing function), the authentication condition is that the second user terminal 30B has the function.
[0111] In the second embodiment, a case where a certain specific credit card supports card scan authentication is taken as an example. Therefore, the authentication condition is that the user holds the specific credit card. The authentication condition determination unit 104 determines whether the user holds the specific credit card based on the ownership information acquired as user information. If it is determined that the user does not hold the specific credit card, the authentication condition determination unit 104 determines that the user information does not satisfy the authentication condition. If it is determined that the user holds the specific credit card, the authentication condition determination unit 104 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 may be any method that corresponds to the authentication condition. For example, the authentication condition determination unit 104 may determine whether the user information satisfies the authentication condition by determining whether the communication unit 33B of the second user terminal 30B supports a short-range wireless communication function based on the user information. If the user information does not indicate that the communication unit 33B supports the short-range wireless communication function, the authentication condition determination unit 104 determines that the user information does not satisfy the authentication condition. If the user information indicates that the communication unit 33B supports the short-range wireless communication function, the authentication condition determination unit 104 determines that the user information satisfies the authentication condition.
[0113] For example, the authentication condition determination unit 104 may determine whether the user information satisfies the authentication condition by determining whether the user has registered specific authentication information with the payment service based on the user information. 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 the user information does not satisfy the authentication condition. 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 the user information satisfies the authentication condition. The user information may be the specific authentication information itself. In this case, the authentication condition determination unit 104 may determine whether the user information satisfies the authentication condition by determining whether the user information, which is the specific authentication information, is registered with the payment service.
[0114] In the second embodiment, the authentication server 10 executes the processes 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 may execute a predetermined process based on the determination result of the authentication condition determination unit 104. The predetermined process may be only the process of the authentication content display unit 105 or only the process of the other authentication content display unit 106. The predetermined process may be other processes. 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 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] If it is determined that the user information does not satisfy the authentication conditions, the authentication content display unit 105 does not display the second authentication screen SC6 on the user's second user terminal 30B, and if it is determined that the user information satisfies the authentication conditions, the authentication content display unit 105 displays the second authentication screen SC6 on the second user terminal 30B. The second authentication screen SC6 is an example of authentication content related to authentication. Therefore, the term "second authentication screen SC6" can be read as "authentication content." The authentication content may be any content displayed for authentication and is not limited to the second authentication screen SC6. The authentication content may be a screen other than the second authentication screen SC6, or may be a component of the screen (e.g., a part of the screen, such as a menu, window, pop-up, modal, button, panel, icon, or other component) rather than the entire screen.
[0116] For example, if it is determined that the user information satisfies the authentication conditions, the authentication content display unit 105 transmits display data of the second authentication screen SC6 to the second user terminal 30B, thereby causing the second authentication screen SC6 to be displayed on the second user terminal 30B. If it is determined that the user information does not satisfy the authentication conditions, the authentication content display unit 105 does not transmit display data of the second authentication screen SC6 to the second user terminal 30B. If it is determined that the user information does not satisfy the authentication conditions, the authentication content display unit 105 may transmit 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 there is no need to particularly distinguish between the first user terminal 30A and the second user terminal 30B, they are simply referred to as user terminals 30. If it is determined that the user information does not satisfy the authentication conditions, the authentication content display unit 105 does not display the second authentication screen SC6 on the user terminal 30, and if it is determined that the user information satisfies the authentication conditions, the authentication content display unit 105 displays the second authentication screen SC6 on the user terminal 30.
[0118] [Other certified content display section] When it is determined that the user information does not satisfy the authentication conditions, the other authentication content display unit 106 displays, on the user terminal 30 (for example, the second user terminal 30B), an other authentication screen SC7 relating to another authentication different from the authentication for which the authentication conditions are to be determined. The other authentication screen SC7 is an example of other authentication content. Therefore, the phrase "other authentication screen SC7" can be read as "other authentication content." The other authentication content may be any content for another authentication and is not limited to the other authentication screen SC7. The other authentication content may be a screen other than the other authentication screen SC7, or may be a component of the screen (a part of the screen, for example, a menu, window, pop-up, modal, button, panel, icon, or other component) rather than the entire screen.
[0119] For example, when it is determined that the user information does not satisfy the authentication conditions, the other authentication content display unit 106 transmits display data of the other authentication screen SC7 to the second user terminal 30B, thereby displaying the other authentication screen SC7 on the second user terminal 30B. When it is determined that the user information satisfies the authentication conditions, the other authentication content display unit 106 does not transmit display data of the other authentication screen SC7 to the second user terminal 30B. Note that the authentication content display unit 105 may display the other authentication screen SC7 on the first user terminal 30A instead of the second user terminal 30B. The other authentication screen SC7 may be any screen for other authentication that can be performed even if the user information does not satisfy the authentication conditions, and is not limited to the one-time password authentication screen shown in the lower right of FIG. 8.
[0120] [Authentication section] 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 makes a determination. For example, the authentication unit 102 performs card scan authentication after the authentication condition determination unit 104 makes a determination and the second authentication screen SC6 is 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 makes a determination and the other authentication screen SC7 is displayed. The flow of one-time password authentication may be the same as a known flow.
[0121] In the second embodiment, card scan authentication will be described as an example of authentication for which authentication conditions are set. The authentication for which authentication conditions are set may be any authentication other than card scan authentication. For example, the authentication for which authentication conditions are set may be authentication for photographing an identification card, payment code authentication described in a third embodiment below, or other possession authentication. The authentication for which authentication conditions are set may be knowledge authentication that requires registration of authentication information in advance, or biometric authentication that requires registration of biometric information in advance. The authentication for which authentication conditions are set may be performed by the first user terminal 30A or the second user terminal 30B, rather than by the authentication server 10.
[0122] In the second embodiment, one-time password authentication will be 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 phone number authentication, authentication using a password different from login authentication, other knowledge authentication, possession authentication other than card scan authentication, or biometric authentication. The other authentication may be performed by the first user terminal 30A or the second user terminal 30B instead of the authentication server 10.
[0123] [2-2-2. Functions realized by the payment server] The function of the payment server 20 may be the same as that in the first embodiment.
[0124] [2-2-3. Functions implemented by the first user terminal] The functions of the first user terminal 30A may be the same as those in the first embodiment.
[0125] [2-2-4. Functions realized by the second user terminal] The functions of the second user terminal 30B may be the same as those in the first embodiment.
[0126] [2-2-5. Functions realized by store terminals] The functions of the store terminal 40 may be the same as those in the first embodiment.
[0127] [2-3. Processing Executed in the Authentication System of the Second Embodiment] 10 and 11 are diagrams showing an example of processing executed by authentication system 1 of the second embodiment. Among the processing executed by authentication system 1, FIGS. 10 and 11 show processing executed when a user logs in to a payment service from second user terminal 30B. The processing of FIGS. 10 and 11 is executed by control units 11 and 31B executing programs stored in storage units 12 and 32B, respectively. Processing similar to that of FIGS. 10 and 11 is also executed when a user logs in to a payment service from first user terminal 30A. The steps of FIGS. 10 and 11 are an example of an authentication condition determination method in the second embodiment.
[0128] As shown in Fig. 10, the processes of S200 to S210 are the same as the processes of S100 to S110, respectively. Fig. 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, when the determination in S205 is affirmative, the processes of 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 need to determine whether or not the login is from a new terminal. For example, the determination 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 the payment service (e.g., user authentication for a withdrawal function or a change of phone number).
[0129] If it is determined in S209 that the change necessity information indicates that the telephone number should be changed (S209: Y), the process proceeds to Fig. 11, where the authentication server 10 refers to the authentication database DB1 and acquires, as user information, ownership information associated with the user ID of the currently logged-in user (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 owns a specific credit card that supports card scan authentication.
[0130] If it is determined in S212 that the user information satisfies the authentication conditions (S212: Y), the authentication server 10 executes processing to display a 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 executes card scan authentication with the second user terminal 30B (S214), and this processing ends. The processing of S214 may be the same as S111.
[0131] If it is determined in S212 that the user information does not satisfy the authentication conditions (S212: N), the authentication server 10 executes processing between the second user terminal 30B and the authentication server 10 to display an other authentication screen SC7 for one-time password authentication (S215). The other authentication screen SC7 displayed in S215 is an example of other authentication content. The authentication server 10 executes one-time password authentication between the second user terminal 30B (S216), and this processing ends. In S216, the second user terminal 30B transmits the one-time password entered by the user in the input form F70 to the authentication server 10. The authentication server 10 cooperates with another server computer that issues one-time passwords to verify 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. This allows the authentication system 1 to 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, thereby enabling flexible processing depending on whether the user information satisfies the authentication conditions. The authentication system 1 can also use different authentication methods to request from the user depending on whether the user information satisfies the authentication conditions.
[0133] Furthermore, if it is determined that the user information does not satisfy the authentication conditions, the authentication system 1 does not display the second authentication screen SC6 on the user terminal 30, and if it is determined that the user information satisfies the authentication conditions, the authentication system 1 displays the second authentication screen SC6 on the user terminal 30. This allows the authentication system 1 to control whether or not to display the second authentication screen SC6 depending on whether the user information satisfies the authentication conditions, thereby improving user convenience. For example, the authentication system 1 can prevent the second authentication screen SC6 for card scan authentication from being displayed to a user who does not satisfy the authentication conditions and therefore cannot perform card scan authentication.
[0134] Furthermore, if it is determined that the user information does not satisfy the authentication conditions, the authentication system 1 displays the other authentication screen SC7 on the user terminal 30. This allows the authentication system 1 to control whether or not to display the other authentication screen SC7 depending on whether the user information satisfies the authentication conditions, thereby improving user convenience. For example, for a user who does not satisfy the authentication conditions and cannot perform card scan authentication, the authentication system 1 can allow the user to perform one-time password authentication by displaying the other authentication screen SC7 for one-time password authentication that is different from card scan authentication.
[0135] 3. Third Embodiment A third embodiment will be described, which is an example of an embodiment of the authentication system 1, authentication method, and program according to the present disclosure. In the third embodiment, a description of the same configuration as the first or second embodiment will be omitted. For example, the hardware configuration of the authentication system 1 may be the same as that of the first embodiment.
[0136] [3-1. Overview of the Third Embodiment] In the third embodiment, similarly to the first and second embodiments, an example is given of a case where a user changes the model from a first user terminal 30A to a second user terminal 30B. However, in the third embodiment, an example is given of a case where, when changing the phone 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] FIG. 12 is a diagram showing an example of a screen displayed on the second user terminal 30B in the third embodiment. For example, when a user logs in to a payment service from the second user terminal 30B, the second user terminal 30B displays a change necessity screen SC4, similar to that of the first or second embodiment, on the display unit 35B, as shown in the upper right of FIG. 3. The display flow of the change necessity screen SC4 may be similar to that of the first or second embodiment. The flow after the user selects button B40 may also be similar to that of the first or second embodiment.
[0138] For example, when the user selects button B41, the second user terminal 30B activates the photographing unit 36B and displays a reading screen SC8 on the display unit 35B for reading the payment code C30 with the photographing unit 36B. The reading screen SC8 displays a captured image I81 generated by the photographing unit 36B along with a message M80 prompting the first user terminal 30A to display the payment code C30. As shown in the lower left of FIG. 3, the user operates the first user terminal 30A to display a code screen SC3 on the display unit 35A.
[0139] When changing the model, the SIM card of the first user terminal 30A may be removed or invalid. When the first user terminal 30A cannot connect to a public communication line, it may communicate with each of 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 store an offline code ID in advance and display the code screen SC3 on the display unit 35A without any special communication.
[0140] For example, when the user displays the code screen SC3 on the first user terminal 30A, the photographing unit 36B of the second user terminal 30B reads the payment code C30. The payment code C30 may be a barcode or a two-dimensional code, but at least one of them may be read. The second user terminal 30B transmits the code ID acquired from the payment code C30 to the authentication server 10. Upon acquiring the code ID from the second user terminal 30B, the authentication server 10 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 currently 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 for making a payment. This allows the user to perform payment code authentication by simply performing an operation for displaying the payment code C30 (for example, an operation for launching a payment app) that the user is accustomed to, so the authentication system 1 can improve user convenience. Furthermore, because the payment code C30 can also be used for authentication, it is possible to save on the cost of developing an authentication code. Details of the third embodiment will be described below.
[0142] [3-2. Functions realized by the authentication system of the third embodiment] Fig. 13 is a diagram showing an example of functions realized by the authentication system 1 of the third embodiment. Although Fig. 13 does not show some of the functions described in the first or second embodiment, the authentication system 1 of the third embodiment may include the functions described in the first or second embodiment. The units realized by the authentication system 1 of the third embodiment can be configured by combining them into one device or by distributing them into smaller devices.
[0143] The authentication system 1 of the third embodiment may not include at least one of the function described in the first embodiment (the function of switching authentication depending on the change necessity information) and the function described in the second embodiment (the function of determining the authentication conditions). The authentication system 1 of the third embodiment may not include the function described in the first embodiment, and may not perform phone number authentication in the first place, or may not register the phone number in the payment service. The authentication system 1 of the third embodiment may not include the function described in the second embodiment, and may not particularly perform determination of the authentication conditions.
[0144] As described above, an aspect in which the authentication system 1 does not include at least one of the functions described in the first embodiment and the functions described in the second embodiment, but includes the functions described in the third embodiment, is within the scope of the present disclosure. Of course, an aspect in which the authentication system 1 includes at least one of the functions described in the first embodiment and the functions described in the third embodiment is also within the scope of the present disclosure. These points are matters that can be naturally understood by those skilled in the art from the description of the present disclosure.
[0145] [3-2-1. Functions realized 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 realized by the control unit 11.
[0146] [Data storage section] The data storage unit 100 may be the same as in 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] [Read information acquisition section] When a payment code C30 displayed on a first user terminal 30A of a user using a payment service is read by a second user terminal 30B different from the first user terminal 30A, the read information acquisition unit 107 acquires the code ID read from the payment code C30. For example, the read information acquisition unit 107 acquires the code ID from the second user terminal 30B. The read information acquisition unit 107 may 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, the parts written as code ID can be read as read information. The read information is information read from the payment code C30. The read information can also be said to be information coded into the payment code C30. The read information is not limited to a code ID as long as it is information that can be used for both payment and payment code authentication. For example, the read information may be information for offline payment, a payment service URL, authentication information other than the code ID (e.g., a user ID or login account), a 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 description of the user ID acquired by the first user information acquisition unit 108 can be read as first user information. The first user information is information about a user who has logged in from the first user terminal 30A. For example, the first user information is user identification information of a user who has logged in from the first user terminal 30A.
[0150] The first user information is not limited to a user ID. The first user information may be any information that is used for payment code authentication. For example, the first user information may be the login account of a user currently logged in from the first user terminal 30A. The first user information is not limited to user identification information, such as a user ID. The first user information may be information associated with the user identification information (information that can be searched from the user identification information). For example, the first user information may be a telephone number, terminal ID, payment method information, or other information associated with the user identification information.
[0151] In the third embodiment, the first user information acquisition unit 108 acquires, as the first user information, a user ID associated with the code ID acquired as read information. For example, the first user information acquisition unit 108 may request the payment server 20 for the user ID associated with the code ID acquired as read information. Based on a 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 transmits the user ID 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 the first user information. Note that if the code ID and the user ID are associated with each other in the authentication database DB1, the first user information acquisition unit 108 may acquire, from the authentication database DB1, the user ID associated with the code ID acquired as read information.
[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 acquires the user ID associated with the code ID acquired 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 transmit 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 transmit the user ID to the authentication server 10. The first user information acquisition unit 108 acquires the user ID transmitted by the payment server 20 as the 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 description of the user ID acquired by the second user information acquisition unit 109 can be read as second user information. The second user information is information about the user who logged in from the second user terminal 30B. For example, the second user information is user identification information of the user who logged in from the second user terminal 30B.
[0154] The second user information is not limited to a user ID. The second user information may be any information that is used for payment code authentication. For example, the second user information may be the login account of a user currently logged in from the second user terminal 30B. The second user information is not limited to user identification information, such as a user ID. The second user information may be information associated with the user identification information (information that can be searched from the user identification information). For example, the second user information may be a telephone number, terminal ID, payment method information, or other information associated with the user identification information.
[0155] In the third embodiment, the second user information acquiring unit 109 acquires a user ID as second user information based on the execution result of login authentication executed from the second user terminal 30 B. For example, the second user information acquiring unit 109 refers to the authentication database DB1 and acquires the user ID associated with the login account entered in the login authentication executed from the second user terminal 30 B.
[0156] For example, if a 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 acquiring unit 109 may acquire a user ID as the second user information based on the session ID. The session ID may be stored in the authentication database DB1. The second user information acquiring unit 109 acquires, as the second user information, the user ID associated with the session ID acquired from the second user terminal 30B.
[0157] [Authentication section] The authentication unit 102 may be the same as in the first or second embodiment. When read information is acquired, the authentication unit 102 performs payment code authentication using the payment code C30. For example, when read information is acquired, 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 the payment code authentication has failed, and if these user IDs match, the authentication unit 102 determines that the payment code authentication has been successful.
[0158] In the third embodiment, the authentication unit 102 performs payment code authentication based on the user ID acquired by the first user information acquisition unit 108 when the read information is acquired and the user ID acquired by the second user information acquisition unit 109. If these user IDs do not match, the authentication unit 102 may determine that the payment code authentication has failed, and if these user IDs match, the authentication unit 102 may determine that the payment code authentication has been successful.
[0159] The method for performing payment code authentication is not limited to the above example. The authentication unit 102 may perform payment code authentication when read information is acquired. For example, the authentication unit 102 may use the read information itself for payment code authentication. The authentication unit 102 may perform payment code authentication by determining whether a code ID, which is an example of read information, is stored in the authentication database DB1. The authentication unit 102 may determine that payment code authentication has failed if the code ID, which is an example of read information, is not stored in the authentication database DB1, and may determine that payment code authentication has been successful if the code ID is stored in the authentication database DB1.
[0160] [3-2-2. Functions realized by the payment server] The function of the payment server 20 may be the same as that of the first or second embodiment. In the third embodiment, an example is given in which the second user terminal 30B reads the payment code C30 displayed on the first user terminal 30A and transmits the read information to the authentication server 10. However, the second user terminal 30B may transmit the read information to the payment server 20. The payment server 20 refers to the payment database DB2 and identifies the user ID corresponding to the read information. The payment server 20 transmits 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 by the first user terminal] The functions of the first user terminal 30A may be the same as those in the first or second embodiment.
[0162] [3-2-4. Functions realized by the second user terminal] The functions of the second user terminal 30B may be the same as those of the first or second embodiment. A display control unit 302B of the second user terminal 30B in the third embodiment displays a read screen SC8 on a display unit 35B.
[0163] [3-2-5. Functions realized by store terminals] The functions of the store terminal 40 may be the same as those in the first or second embodiment.
[0164] [3-3. Processing Executed in the Authentication System of the Third Embodiment] 14 and 15 are diagrams showing an example of processing executed in authentication system 1 of the third embodiment. Among the processing executed in authentication system 1, Fig. 14 and 15 show processing executed when a user logs in to a payment service from second user terminal 30B. The processing of Fig. 14 and Fig. 15 is executed by control units 11, 31A, and 31B executing programs stored in storage units 12, 32A, and 32B, respectively. The steps of Fig. 14 and Fig. 15 are an example of an authentication method in the third embodiment.
[0165] As shown in Fig. 14, the processes of S300 to S310 are the same as the processes of S100 to S110, respectively. Fig. 14 shows an example in which the authentication system 1 of the third embodiment includes the functions of the first embodiment, but if the authentication system 1 of the third embodiment does not include the functions of the first embodiment, when the determination of S305 is positive, the processes of S306 to S310 may not be executed and the process may proceed to S311.
[0166] If it is determined in S309 that the change necessity information indicates that the phone number should be changed (S309: Y), the process proceeds to FIG. 15, where the authentication server 10 executes processing with the second user terminal 30B to display a reading screen SC8 (S311). In S311, the authentication server 10 transmits display data of the reading screen SC8 to the second user terminal 30B. Based on the display data of the reading screen SC8, the second user terminal 30B activates the photographing unit 36B to display the reading screen SC8 on the display unit 35B. The user operates the first user terminal 30A to activate the payment app.
[0167] When the first user terminal 30A launches the payment app, it executes processing with the payment server 20 to display the code screen SC3 (S312). In S312, the first user terminal 30A executes login authentication with the payment server 20. Note that if the user is already logged in, login authentication does not need to be executed. The payment server 20 issues a code ID and determines an expiration date, associates the code ID and expiration date with the user ID and login account of the user who logged in from the first user terminal 30A, and stores them in the payment database DB2. When the first user terminal 30A receives display data for the code screen SC3 from the payment server 20, it displays the code screen SC3 on the display unit 35A. Note that the display data for the code screen SC3 may be sent by the authentication server 10, not by 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 with the photographing unit 36B (S313). The second user terminal 30B transmits the code ID acquired from the payment code C30 as read information to the authentication server 10 (S314). The authentication server 10 acquires the code ID as read information from the second user terminal 30B (S315). The authentication server 10 transmits the code ID to the payment server 20 and acquires the user ID associated with the code ID from the payment server 20 (S316). The authentication server 10 acquires 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 acquired in S316 and the user ID acquired in S317 (S318), and this process ends. Note that the process executed in S317 to acquire the user ID of the logged-in user may include, for example, a process to acquire 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 for login by the payment server 20, and the authentication server 10 may acquire the user ID of the logged-in second user terminal 30B from the payment server 20. Also, the process executed in S316 to acquire the user ID associated with the code ID may be executed by the authentication server 10. In this case, the code ID, expiration date, and corresponding user ID are linked in advance from the payment server 20. Furthermore, the authentication executed in S318 may be executed by the payment server 20.
[0169] [3-4. Summary of the third embodiment] The authentication system 1 of the third embodiment acquires read information read from the payment code C30 when a payment code C30 for a payment service displayed on a first user terminal 30A of a user using the payment service is read by a second user terminal 30B different from the first user terminal 30A. When the read information is acquired, the authentication system 1 performs payment code authentication using the payment code. This allows the user to perform payment code authentication by simply performing an operation for displaying the payment code C30 (e.g., an operation for launching a payment app) that the user is familiar with, thereby 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 an authentication code. As a result, the authentication system 1 can reduce development costs for implementing authentication functions.
[0170] Furthermore, the authentication system 1 acquires second user information about the user who logged in to the payment service from the second user terminal 30B. When the read information is acquired, the authentication system 1 performs payment code authentication based on the first user information about the user who logged in to the payment service from the first user terminal 30A and the second user information. This allows the authentication system 1 to improve security in the payment service by using the payment code C30.
[0171] Furthermore, authentication server 10 includes authentication unit 102, read information acquisition unit 107, second user information acquisition unit 109, and first user information acquisition unit 108. When read information is acquired, authentication server 10 executes payment code authentication based on the first user information and second user information acquired by first user information acquisition unit 108. Authentication server 10 can quickly complete payment code authentication.
[0172] [4. Modifications] The present disclosure is not limited to the first to third embodiments described above. The present disclosure can be modified as appropriate without departing from the spirit of the present disclosure. Modifications of each of the first to third embodiments will be described below.
[0173] [4-1. Modifications of the First Embodiment] 16 is a diagram showing an example of functions realized in a modification of the first embodiment. For example, the authentication server 10 includes a user information acquisition unit 103, a function restriction unit 110, a restriction removal unit 111, a second authentication suggestion 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 removal unit 111, the second authentication suggestion unit 112, and the second authentication content display unit 113 is realized by the control unit 11.
[0174] [Variation 1-1] For example, as described somewhat in the first embodiment, when the change necessity information indicates that the telephone number will not be changed, the authentication unit 102 may execute, as the first authentication, authentication similar to the authentication executed using the telephone number at the first user terminal 30A. For example, when the change necessity information indicates that the telephone number will not be changed and the user performs an operation for the first authentication, the authentication unit 102 may execute, as the first authentication, authentication similar to the authentication executed using the telephone number at the first user terminal 30A. The authentication executed using the telephone number at the first user terminal 30A is telephone number authentication performed from the first user terminal 30A. In other words, the authentication executed using the telephone number at the first user terminal 30A is authentication for confirming the telephone number of the first user terminal 30A (the telephone number that the user also uses at the second user terminal 30B).
[0175] In the example of FIG. 2, the phone number authentication executed from the phone number authentication screen SC2 corresponds to authentication executed using the phone number on the first user terminal 30A. As described in the first embodiment, phone number authentication is not limited to authentication using an outgoing call from the user's phone number as shown in FIG. 2. Phone number authentication may also be authentication using an incoming call to the user's phone number or authentication using an SMS message. The authentication unit 102 executes phone number authentication from the first user terminal 30A in the same manner as known phone number authentication.
[0176] Authentication similar to the authentication performed using the telephone number on the first user terminal 30A is authentication using the same authentication method as the authentication method performed using the telephone number on the first user terminal 30A. In the example of Fig. 3, telephone number authentication performed from the first authentication screen SC5 corresponds to the first authentication similar to the authentication performed using the telephone number on the first user terminal 30A. If the telephone number authentication performed from the first authentication screen SC5 is authentication using a call from the user's telephone number, then the authentication using the call from the user's telephone number corresponds to the first authentication.
[0177] Note that, if the phone number authentication executed from the first authentication screen SC5 is authentication using an incoming call to the user's phone number or authentication using an SMS message, the authentication using an incoming call to the user's phone number or authentication using an SMS message may correspond to the first authentication. The authentication unit 102 may execute the first authentication in the same manner as the authentication executed using the phone number on the first user terminal 30A.
[0178] When the change necessity information indicates that the telephone number should not be changed, the authentication system 1 of Variation 1-1 executes, as the first authentication, authentication similar to the authentication executed using the telephone number on the first user terminal 30A. This prevents a malicious third party from successfully executing an authentication similar to the authentication executed using the telephone number on the first user terminal 30A, even if the malicious third party obtains the user's login account and password, and thus the authentication system 1 can improve the security of the payment service. From the user's perspective, it is sufficient to execute authentication similar to the authentication previously performed on the first user terminal 30A (authentication whose flow is already known), so the authentication system 1 can improve user convenience while also improving security.
[0179] [Variation 1-2] For example, suppose a malicious third party obtains a user's login account and password and logs in to a payment service by impersonating the user. Even if the third party learns the user's phone number, it is difficult for the third party to set the user's phone number on the third party's device (for example, it is difficult for the third party to write the user's phone number to the SIM card of the third party's smartphone without permission), so it is considered extremely difficult to successfully complete the first authentication.
[0180] On the other hand, if a third party logs in to the payment service from their own device pretending to be the 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 in some way. Therefore, assuming that a third party may fraudulently use the payment service, restrictions may be imposed on the use of the payment service if the second authentication is performed. If the user or administrator can notice the fraudulent use during the restriction, damage can be minimized.
[0181] The authentication system 1 of variant 1-2 includes a function restriction unit 110. When the second authentication is performed, the function restriction unit 110 restricts functions related to the payment service used from the second user terminal 30B more than when the first authentication is performed. A function is an information process performed in the payment service. For example, a function includes payment, charging, remittance, withdrawal, change of payment source, change of charging source, change of information registered in the payment service, or other processes. If the specified service is a service other than a payment service, the function may be any information process performed in the other service.
[0182] For example, the function restriction unit 110 may restrict functions by setting an upper limit on the payment amount per transaction or within a predetermined period (e.g., per day, per week, or per month). The function restriction unit 110 may restrict functions by setting an upper limit on the number of transactions within a predetermined period. The function restriction unit 110 may restrict functions by setting an upper limit on the recharge amount per transaction or within a predetermined period. The function restriction unit 110 may restrict functions by setting an upper limit on the number of recharges within a predetermined period.
[0183] For example, the function restriction unit 110 may restrict functions by setting an upper limit on the amount of remittance per transaction or within a predetermined period. The function restriction unit 110 may restrict functions by setting an upper limit on the number of remittances within a predetermined period. The function restriction unit 110 may restrict functions by not accepting changes to the payment source. The function restriction unit 110 may restrict functions by not accepting changes to the charge source. The function restriction unit 110 may restrict functions by not accepting changes to information registered in the payment service. For example, the function restriction unit 110 may restrict the use of some functions, such as withdrawal.
[0184] For example, when the second authentication is performed while logged in to the payment service with a certain login account, the function restriction unit 110 restricts the function by storing function restriction information indicating that the function is restricted in the authentication database DB1 in association with the login account. The function restriction information indicates whether or not the function is restricted. For example, the function restriction information may be information such as a flag that takes on a value indicating that the function is not restricted or a value indicating that the function 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 associate the function restriction information with user identification information other than the login account.
[0185] For example, when a payment service is used with a certain login account, the function restriction unit 110 refers to the function restriction information associated with the login account. If the function restriction information indicates that functions are not restricted, the function restriction unit 110 provides the payment service without restricting the functions. If the function restriction information indicates that functions are restricted, the function restriction unit 110 provides the payment service with restricted functions. An example of function restriction is as described above. If first authentication is performed, the function restriction unit 110 does not restrict the functions.
[0186] In the authentication system 1 of Modification 1-2, when the second authentication is performed, functions related to the service used from the second user terminal 30B are restricted more than when the first authentication is performed. As a result, even if a third party breaks through the second authentication, the authentication system 1 can prevent damage from occurring in the first place or minimize the damage by restricting the functions. As a result, the authentication system 1 can improve security while increasing user convenience.
[0187] [Variation 1-3] For example, the function restriction described in Modification 1-2 may be lifted under a predetermined lifting condition. The lifting condition is a condition for lifting the function restriction. In other words, the lifting condition is a criterion for determining whether or not to lift the function restriction. Lifting the function restriction means changing the function from a restricted state to an unrestricted state. In other words, lifting the function restriction means returning the function to the state before it was restricted.
[0188] The authentication system 1 of Modification 1-3 includes a restriction lifting unit 111. The restriction lifting unit 111 lifts the restriction on a function when a predetermined lifting condition is met. For example, the restriction lifting unit 111 determines whether or not each user whose functions are restricted (each login account whose functions are restricted) satisfies the lifting condition. If it is determined that the user does not satisfy the lifting condition, the restriction lifting unit 111 does not lift the restriction on the user's functions, and if it is determined that the user satisfies the lifting condition, the restriction lifting unit 111 lifts the restriction on the user's functions.
[0189] In Modification 1-3, an example is given in which the elapse of a predetermined restriction period corresponds to the release condition. The restriction period is the period during which the function is restricted. The restriction period can also be said to be information that identifies when the function restriction will be released. For example, the restriction period may correspond to a period from when the second authentication is performed (when the function restriction begins) until a predetermined time (e.g., one week) has elapsed.
[0190] In Modification 1-3, the function restriction unit 110 associates restriction period information that 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 a period from the current date and time a predetermined time later as the restriction period, and associates 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 will end. In this case, when the second authentication is performed, the function restriction unit 110 may associate restriction period information indicating a date and time a predetermined time later than 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 function restriction information indicating the current date and time with the function restriction information.
[0191] For example, the restriction removal unit 111 determines whether the restriction period has arrived based on the restriction period information, thereby determining whether the removal condition has been satisfied. If it is determined that the restriction period has not arrived, the restriction removal unit 111 determines that the removal condition has not been met, and if it is determined that the restriction period has arrived, the restriction removal unit 111 determines that the removal condition has been met. The restriction removal unit 111 removes 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 described in Modification 1-2, the restriction removal unit 111 removes the restriction on the function by changing the value of the flag.
[0192] The release condition may be any predetermined condition other than the expiration of the restriction period. For example, the release condition may be that there is no suspicion of fraud in the use of the payment service after the second authentication. The suspicion of fraud may be determined visually by an operator of the payment service or automatically based on a predetermined fraud detection program. The fraud detection program may be similar to programs used in known payment services. 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 authentication database DB1, payment database DB2, or another database. The restriction lifting unit 111 presents the usage history to an operator of the payment service and receives a confirmation result from the operator's terminal. The restriction lifting unit 111 may determine that the lifting condition is not met if the operator's confirmation result indicates fraud, and may determine that the lifting condition is met if the operator's confirmation result indicates no fraud.
[0194] For example, the release condition may be that another authentication other than the second authentication is performed from the second user terminal 30B. The other authentication is an authentication different from the login authentication and the first authentication. For example, the other authentication may be any of knowledge authentication, possession authentication, or biometric authentication. If it is determined that another authentication has not been performed from the second user terminal 30B, the restriction release unit 111 determines that the release condition is not satisfied, and if it is determined that another authentication has been performed from the second user terminal 30B, the restriction release unit 111 determines that the release condition is satisfied. The release condition may be any other condition.
[0195] The authentication system 1 of Variation 1-3 releases the function restriction when a predetermined release condition is met. This allows the user to use the payment service with the function restriction released, so that the authentication system 1 can ensure the security of the payment service while improving user convenience and security. For example, even if the second authentication is performed, the authentication system 1 can also restrict the function if there is suspicion of fraud, and release the function restriction when the suspicion of fraud is no longer present.
[0196] [Variation 1-4] For example, only one authentication method may be provided as the second authentication to be executed when the user's phone number remains unchanged, or multiple authentication methods may be provided. If multiple authentication methods are provided, some of the multiple authentication methods may not be compatible with the second authentication, depending on the user. Therefore, in Modification 1-4, an example is given in which a second authentication that the user can support is proposed from among the multiple authentication methods.
[0197] The authentication system 1 of Modification 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 Modification 1-4 will be exemplified as having a function different from that of the user information acquisition unit 103 described in the second embodiment. The user information acquisition unit 103 of Modification 1-4 acquires user information about the user when the change necessity information indicates that the phone number should be changed.
[0198] The user information of Modification 1-4 is information acquired from the second user terminal 30B, or information associated with the user ID or login account of the user who logged in from the second user terminal 30B. The user information of Modification 1-4 may be the same as the user information described in the second embodiment, or may be information different from the user information described in the second embodiment. In Modification 1-4, as an example of user information, a case will be described in which information indicating whether the communication unit 33B of the second user terminal 30B supports a short-range wireless communication function. The user information may be any information about the user, and is not limited to the example of Modification 1-4.
[0199] For example, the second user terminal 30B determines whether the communication unit 33B supports the short-range wireless communication function. This determination method may be a known method. For example, the second user terminal 30B determines whether the communication unit 33B supports the short-range wireless communication function based on model information of the second user terminal 30B. For example, if information indicating whether the communication unit 33B supports the short-range wireless communication function is pre-stored in the second user terminal 30B, the second user terminal 30B may determine whether the communication unit 33B supports the short-range wireless communication function based on the information. Based on the determination result, the second user terminal 30B transmits user information indicating whether the communication unit 33B supports the short-range wireless communication function to the authentication server 10. The user information acquisition unit 103 acquires user information from the second user terminal 30B.
[0200] The second authentication proposing unit 112 proposes to the user, as the second authentication, an authentication method for which the user information satisfies predetermined authentication conditions. A payment service may provide multiple authentication methods or only one authentication method. The second authentication proposing unit 112 may have at least some of the functions of the authentication condition determining unit described in the second embodiment. The second authentication proposing unit 112 may have at least some of the functions of the authentication content displaying unit 105 described in the second embodiment. The second authentication proposing unit 112 may have at least some of the functions of the other authentication content displaying unit 106 described in the second embodiment.
[0201] The authentication conditions are as described in the second embodiment. The authentication conditions of Modification 1-4 are authentication conditions for the second authentication. The second authentication proposing unit 112 may determine whether or not the user information satisfies the authentication conditions, similarly to the authentication condition determining unit 104 of the second embodiment. For example, as in Modification 1-4, when the user information indicates whether or not the communication unit 33B supports the short-range wireless communication function, the second authentication proposing 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 the short-range wireless communication function, and determines that the user information satisfies the authentication conditions if the user information indicates that the communication unit 33B supports the short-range wireless communication function.
[0202] In Modification 1-4, similarly to the second embodiment, two authentication methods, card scan authentication and one-time password authentication, are provided as the second authentication. For example, when it is determined that the user information satisfies the authentication conditions, the second authentication suggestion unit 112 suggests card scan authentication by displaying a 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 that of the first embodiment.
[0203] For example, if it is determined that the user information does not satisfy the authentication conditions, the second authentication proposal unit 112 proposes one-time password authentication to the user by displaying a second authentication screen SC6 for one-time password authentication on the second user terminal 30B. This second authentication screen SC6 may be similar to the other authentication screen SC7 of the second embodiment. In the second embodiment, an example was given in which one-time password authentication is another type of authentication different from the second authentication, but in Modification 1-4, one-time password authentication is also a type of second authentication.
[0204] The authentication unit 102 of Modification 1-4 executes the second authentication when the second authentication is proposed. For example, the authentication unit 102 executes the second authentication when the second authentication is proposed and the user performs an operation for the second authentication. As described in the first embodiment, the flow of the authentication unit 102 executing the second authentication may be similar to a known flow. The authentication unit 102 executes the second authentication proposed by the second authentication proposing unit 112 from among multiple authentication methods. For example, when card scan authentication is proposed, the authentication unit 102 executes card scan authentication. When one-time password authentication is proposed, the authentication unit 102 executes one-time password authentication.
[0205] The authentication system 1 of Modification Example 1-4 acquires user information when the change necessity information indicates that the phone number should be changed. The authentication system 1 proposes to the user, as the second authentication, an authentication method for which the user information satisfies predetermined authentication conditions. This allows the user to perform the second authentication using an authentication method that corresponds to the authentication conditions satisfied by their own user information, so the authentication system 1 can improve security while increasing user convenience.
[0206] [Variation 1-5] For example, in Modification 1-4, the second authentication proposal unit 112 may determine whether the user information satisfies the authentication condition by determining whether predetermined information about belongings is associated with the user information. Modification 1-5 takes as an example a case where a user ID corresponds to the user information. The user information may be user identification information other than the user ID (for example, a login account). The method by which the user information acquisition unit of Modification 1-5 acquires user information, for example, a user ID, may be the same as that of the user information acquisition unit of the second embodiment.
[0207] Possessions are items used for so-called possession authentication. For example, possessions are cards such as credit cards. Possessions may be other than credit cards, such as membership cards, health insurance cards, driver's licenses, passports, or My Number cards that can prove the user's identity. For example, personal authentication may be performed based on My Number cards. When logging in from a different terminal using the same login account, if My Number card information is associated with the login account, scan authentication of the My Number card may be performed again.
[0208] The predetermined information is information required for a specific second authentication or information indicating the presence or absence of such information. For example, when card scan authentication corresponds to the second authentication, authentication information stored in a credit card (e.g., electronic money number or point card number) is required for the second authentication, so the predetermined information may be the authentication information or information indicating the presence or absence of the authentication information. In Modification Examples 1-5, an example is given in which the predetermined information is stored in authentication database DB1, but the predetermined information may also be stored in a database other than authentication database DB1. For example, the predetermined information may be stored in payment database DB2.
[0209] The predetermined information is not limited to authentication information such as an electronic money number or a point card number. For example, when a second authentication is performed to verify the validity of a credit card number, the predetermined information may be the credit card number. When possession authentication, knowledge authentication, or biometric authentication other than card scan authentication corresponds to the second authentication, the predetermined information may be authentication required for these authentications or information indicating the presence or absence of the authentication information. The second authentication proposal unit 112 may determine whether the predetermined information is associated with user information.
[0210] For example, if the second authentication proposal unit 112 determines that the user information is not associated with predetermined information, it determines that the user information does not satisfy the authentication condition. If the second authentication proposal unit 112 determines that the user information is not associated with predetermined information, it determines that the user information satisfies the authentication condition. In Modification 1-5, if the second authentication proposal unit 112 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 condition, and therefore displays a second authentication screen SC6 for one-time password authentication on the second user terminal 30B. If the second authentication proposal unit 112 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 condition, and therefore displays a second authentication screen SC6 for card scan authentication on the second user terminal 30B. The subsequent authentication flow may be similar to that of Modification 1-4.
[0211] The authentication system 1 of Modification Example 1-5 determines whether the user information satisfies the authentication conditions by determining whether predetermined information related to the user's belongings is associated with the user information. This allows the user to perform the second authentication using a specific authentication method when the predetermined information is associated with the user's user information, so the authentication system 1 can improve security while enhancing user convenience. For example, the authentication system 1 can prevent the second authentication screen SC6 for card scan authentication from being displayed on the second user terminal 30B even in an environment where authentication information such as an electronic money number or a point card number is not associated with the user ID and the user cannot perform card scan authentication.
[0212] [Variation 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 a charge source correspond to payment methods that can be set in the payment service. Modification 1-6 takes as an example a case 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 in which the credit card described in Modifications 1-4 and 1-5 corresponds to a payment method that can be set in a payment service. Furthermore, an example is given in which an electronic money number or a point card number for an electronic money function or a point function, which are additional functions of the credit card, corresponds to predetermined information related to a payment method, with a credit card being an 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 a point card number, the second authentication proposal unit 112 determines whether the authentication information such as the electronic money number or the point card number is associated with user information. The authentication unit 102 performs second authentication based on the predetermined information. The flow of the second authentication may be the same as that of Modification 1-5.
[0214] It should be noted that the payment methods that can be set in the payment service are not limited to the credit cards described in Modifications 1-4 and 1-5. For example, the payment methods that can be set in the payment service may be credit cards that do not have additional functions such as electronic money or points. In this case, the predetermined information may be information such as a credit card number. The payment methods that can be set in the payment service may not be credit cards, but other cards such as debit cards. In this case, the predetermined information may be information such as a debit card number.
[0215] For example, the payment method that can be set in the payment service may be a payment method other than a card. The payment method that can be set in the payment service may be a bank account, electronic money, or points. In this case, the predetermined information may be information about the bank account, electronic money, or points. The payment method that can be set in the payment service may be an app for another payment service. In this case, the predetermined information may be information about the app for the other payment service.
[0216] The authentication system 1 of Modifications 1-6 determines whether predetermined information related to payment methods that can be set in the payment service is associated with user information. This allows the user to perform second authentication using a specific authentication method when the predetermined information related to payment methods that can be set in the payment service is associated with their user information. Therefore, the authentication system 1 can improve security while enhancing user convenience. For example, the authentication system 1 can prevent the second authentication screen SC6 for card scan authentication from being displayed on the second user terminal 30B even in an environment where authentication information such as an electronic money number or a point card number is not associated with the user ID and the user cannot perform card scan authentication.
[0217] [Variation 1-7] For example, as explained somewhat in Modification 1-4, in the first embodiment, similar to the second embodiment, when the user satisfies the authentication conditions, second authentication content related to the second authentication may be presented to the user. In Modification 1-7, the authentication content described in the second embodiment is referred to as the second authentication content. The description of the authentication content in the second embodiment can be interpreted as the description of the second authentication content. In Modification 1-7, similar to the second embodiment, the second authentication screen SC6 corresponds to the second authentication content, 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 Variation 1-7 includes a second authentication content display unit 113. When the change necessity information indicates that the phone number should be changed and a predetermined authentication condition is satisfied, the second authentication content display unit 113 causes the second user terminal 30B to display second authentication content related to the second authentication. For example, the second authentication content display unit 113 causes the second user terminal 30B to display the second authentication screen SC6, which is an example of the second authentication content, by transmitting display data of the second authentication screen SC6 to the second user terminal 30B.
[0219] For example, if the change necessity information indicates that the phone number should not be changed, or if a predetermined authentication condition is not satisfied, the second authentication content display unit 113 does not display the second authentication content on the second user terminal 30B. In this case, the authentication server 10 may display the other authentication screen SC7 on the second user terminal 30B, as in the second embodiment, or may not display any particular content.
[0220] The authentication unit 102 of Modification Example 1-7 executes the second authentication when the second authentication content is displayed on the second user terminal 30B. For example, the authentication unit 102 executes 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 executing 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. When the other authentication screen SC7 is displayed on the second user terminal 30B, the authentication unit 102 executes the other authentication in the same manner as in the second embodiment.
[0221] The authentication system 1 of Modification Example 1-7 displays the second authentication content on the second user terminal 30B when the change necessity information indicates that the phone number should be changed and the authentication conditions are satisfied. The authentication system 1 executes 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 satisfies the authentication conditions, thereby improving user convenience and security. For example, the authentication system 1 can prevent the second authentication screen SC6 for card scan authentication from being displayed to a user who does not satisfy the authentication conditions and therefore cannot perform card scan authentication.
[0222] [Variation 1-8] For example, in Modification 1-7, when the change necessity information indicates that the phone number should be changed and a predetermined authentication condition is satisfied, the second authentication content display unit 113 may distinguish between the second authentication content and other authentication content related to another authentication different from the second authentication and display the other authentication content on the second user terminal 30B. The other authentication content is as described in the second embodiment.
[0223] Distinguishing the second authentication content from the other authentication content means displaying the second authentication content before the other authentication content, displaying the second authentication content and the other authentication content on separate screens, displaying the second authentication content and the other authentication content in separate positions on the same screen, or displaying the second authentication content more prominently than the other authentication content. Variation 1-8 gives an example in which the second authentication content and the other authentication content are only a part of the screen rather than the entire screen, but the second authentication content and the other authentication content may also be the entire screen.
[0224] 17 is a diagram showing an example of an authentication selection screen displayed on the second user terminal 30B in Modification Example 1-8. As shown in the upper right of FIG. 17, the second authentication content display unit 113 causes the second user terminal 30B to display an authentication selection screen SC9 in which part P90, which is an example of the second authentication content, and part P91, which is an example of the other authentication content, are distinguished from each other. In the example shown in the upper right of FIG. 17, the second authentication content display unit 113 displays a message such as "recommended" near part P90 and highlights part P90 more than part P91, thereby distinguishing between 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 displays the second authentication content in a more emphasized manner than the other authentication contents is not limited to the example of FIG. 17. For example, the second authentication content display unit 113 may display a message other than that shown in FIG. 17 or an image other than a message to display the second authentication content in a more emphasized manner than the other authentication contents. The second authentication content display unit 113 may display the second authentication content above or before the other authentication contents to display the second authentication content in a more emphasized manner than the other authentication contents. The second authentication content display unit 113 may preferentially display the second authentication content by automatically transitioning to the second authentication content instead of automatically transitioning to the other authentication contents.
[0226] For example, when the user selects part P90, the second user terminal 30B causes the display unit 35B to display a second authentication screen SC6 for card scan authentication, as shown in the lower left of Fig. 17. The display flow of the second authentication screen SC6 is the same as in the first or second embodiment. When the user selects part P91, the second user terminal 30B causes the display unit 35B to display an other authentication screen SC7 for other authentication, as shown in the lower right of Fig. 17. The display flow of the other authentication screen SC7 is the same as in the second embodiment.
[0227] The authentication unit 102 of Modification Example 1-8 performs the second authentication or another authentication when the second authentication content and the other authentication content are distinguished and displayed on the second user terminal 30B. For example, the authentication unit 102 performs the second authentication or another authentication when the second authentication content and the other authentication content are distinguished and displayed on the second user terminal 30B and the user performs an operation for the second authentication or another authentication. For example, the authentication unit 102 performs the second authentication when part P90, an example of the second authentication content, is selected. The flow of the second authentication may be the same as that of the first or second embodiment. The authentication unit 102 performs another authentication when part P91, an example of the other authentication content, is selected. The flow of the other authentication may be the same as that of the second embodiment.
[0228] In the authentication system 1 of Modification Example 1-8, when the change necessity information indicates that the phone number should be changed and the authentication conditions are satisfied, the second authentication content and the other authentication content are displayed separately on the second user terminal 30B. The authentication system 1 executes 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 30B. This makes it easier for the user to distinguish between the second authentication content and the other authentication content, allowing the authentication system 1 to improve security while increasing user convenience.
[0229] [Variation 1-9] For example, when the change necessity information indicates that the telephone number is to be changed and the first user terminal 30A is in possession of the user, the authentication unit 102 may execute the second authentication using the first user terminal 30A. 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. Variation 1-9 exemplified a case in which the payment code authentication described in the third embodiment corresponds to the second authentication. When the change necessity information indicates that the telephone number is to be changed and the first user terminal 30A is in possession of the user, the authentication unit 102 may execute the payment code authentication similar to that of the third embodiment as the second authentication. When the change necessity information indicates that the telephone number is to be changed, the first user terminal 30A is in possession of the user, and the user has performed an operation for the second authentication, the authentication unit 102 may execute the payment code authentication similar to that of the third embodiment as the second authentication.
[0230] The second authentication using the first user terminal 30A may be authentication other than the payment code authentication. For example, the second authentication may be authentication performed by displaying a code different from the payment code C30 on the first user terminal 30A and reading the code on the second user terminal 30B. The second authentication may be authentication performed by reading the payment code C30 displayed on the second user terminal 30B with the first user terminal 30A. For example, the second authentication may be authentication performed by having the user input a new phone number into the first user terminal 30A.
[0231] For example, the authentication unit 102 may determine whether the user owns the first user terminal 30A, and perform the second authentication on the condition that the user owns the first user terminal 30A. The authentication unit 102 may determine whether the user owns the first user terminal 30A based on information transmitted by the first user terminal 30A (e.g., a login account or a terminal ID), information transmitted by the second user terminal 30B (e.g., a login account or a terminal ID), the usage status of the payment service from the first user terminal 30A (e.g., the date and time of login, the date and time the payment code C30 was issued, the expiration date of the payment code C30), or other information. Furthermore, the authentication unit 102 may determine whether the user owns the first user terminal 30A based on information input by the user regarding whether the user owns 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, and if it determines that the user possesses the first user terminal 30A, it performs the second authentication using the first user terminal 30A.
[0232] The authentication system 1 of Modification Example 1-9 executes the second authentication using the first user terminal 30A when the change necessity information indicates that the phone number is to be changed and the first user terminal 30A is in possession of the user. This allows the authentication system 1 to enhance security by the second authentication using the first user terminal 30A. For example, when the authentication system 1 executes 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 when the user does not possess the first user terminal 30A.
[0233] [Variation 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 execute 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 similar to the payment code authentication of the third embodiment.
[0234] The authentication system 1 of Variation 1-10 performs second authentication in which the payment code C30 displayed on the first user terminal 30A is read by the second user terminal 30B. This allows the authentication system 1 to perform payment code authentication by simply performing an operation (e.g., launching a payment app) that the user is accustomed to for displaying the payment code C30, thereby improving user convenience and security. The authentication system 1 can also use the payment code C30 used for payment for authentication when changing devices, eliminating the need to issue an authentication code. As a result, the authentication system 1 can reduce development costs for implementing authentication functions.
[0235] [Variation 1-11] For example, when the change necessity information indicates that the phone number is to be changed, the authentication unit 102 may execute the second authentication in which the changed phone number is input from the first user terminal 30A. For example, when the change necessity information indicates that the phone number is to be changed and the user performs an operation for the second authentication, the authentication unit 102 may execute the second authentication in which the changed phone number is input from the first user terminal 30A. The authentication unit 102 executes phone number authentication using the second user terminal 30B based on the changed phone number input from the first user terminal 30A. The changed phone number is the phone number of the second user terminal 30B.
[0236] FIG. 18 is a diagram showing an example of a screen displayed on each of the first user terminal 30A and the second user terminal 30B in Modification Example 1-11. For example, as shown in the lower left of FIG. 18, the first user terminal 30A communicates with the authentication server 10 and displays a phone number input screen SC10, which accepts input of a changed phone number, on the display unit 35A. The user inputs the changed phone number into the input form F100. The first user terminal 30A transmits the changed phone number to the authentication server 10. The first user terminal 30A may also transmit the changed phone number to the second user terminal 30B.
[0237] For example, when the authentication server 10 receives the changed phone number, it causes the second user terminal 30B to display a second authentication screen SC6 for executing phone number authentication based on the changed phone number as the second authentication, as shown in the upper right of FIG. 18. The user performs an operation on the second authentication screen SC6 to execute phone number authentication based on the changed phone number as the second authentication. The authentication unit 102 executes phone number authentication based on the changed phone number as the second authentication. The flow of phone number authentication itself may be the same as a known flow.
[0238] When changing the 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 obtain the changed phone number from another service or website that is linked to the payment service. It is assumed that the user has registered the changed phone number with another service or website from the second user terminal 30B or another computer. 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 authentication system 1 of Modification Example 1-11, when the change necessity information indicates that the phone number should be changed, the authentication system 1 executes the second authentication in which the changed phone number is input from the first user terminal 30A. This makes it a condition for executing the second authentication that the user possesses the first user terminal 30A, so the authentication system 1 can improve security in the payment service. For example, even if a malicious third party obtains the user's login account and password, it is difficult for the third party to steal the first user terminal 30A, and therefore the second authentication cannot be executed. This allows the authentication system 1 to improve security in the payment service.
[0240] [4-2. Modifications of the Second Embodiment] Next, a modification of the second embodiment will be described.
[0241] [Variation 2-1] For example, in the second embodiment, similarly to Modification 1-8, the authentication content display unit 105 may preferentially display authentication content on the second user terminal 30B when it is determined that the user information satisfies the authentication conditions. Modification 2-1 takes as an example a case where an authentication selection screen SC9 similar to 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 arranges 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 arranges part P91 on the authentication selection screen SC9.
[0242] In the example shown in the upper right of FIG. 17 , the authentication content display unit 105 displays part P90, which is an example of authentication content, with priority over part P91, which is an example of other authentication content, by displaying a message such as “recommended” near part P90, which is an example of authentication content. Highlighting part P90, as described in Modification 1-8, corresponds to displaying part P90 with priority. The authentication content display unit 105 may display part P90 with priority over part P91 by using another message. The authentication content display unit 105 may display part P90 with priority over part P91 by arranging part P90 above part P91. The authentication content display unit 105 may display the authentication content with priority by automatically transitioning to the second authentication screen SC6 shown in the lower left of FIG. 17 as the authentication content.
[0243] When it is determined that the user information satisfies the authentication conditions, the authentication system 1 of Modification 2-1 preferentially displays the authentication content on the second user terminal 30B. This makes it easier for the user to notice the authentication content, and the authentication system 1 can improve user convenience.
[0244] [Variation 2-2] For example, when it is determined that the user information satisfies the authentication condition, the other authentication content display unit 106 may display, on the second user terminal 30B, other authentication content related to another authentication different from the authentication performed when the authentication condition is satisfied, based on the selection status of the authentication content by the user. The selection status of the authentication content is an operation performed on the authentication content. For example, the selection status of 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] FIG. 19 is a diagram showing an example of a screen displayed on the second user terminal 30B in Modification Example 2-2. As shown in the upper right corner of FIG. 19, the authentication content display unit 105 causes the second user terminal 30B to display a second authentication screen SC6 including a button B60 indicating whether or not to perform card scan authentication. The user can perform card scan authentication without selecting button B60, or can select button B60 to not perform card scan authentication. In the example in the upper right corner of FIG. 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] When it is determined that the user information satisfies the authentication conditions, the authentication system 1 of Modification 2-2 displays other authentication content on the second user terminal 30B based on the selection status of the authentication content by the user. This allows the user to display other authentication content and perform other authentication when the user does not want the authentication indicated by the authentication content, so the authentication system 1 can improve user convenience. In the example of Fig. 19, the user can perform one-time password authentication when the user does not want card scan authentication, so the authentication system 1 can improve the flexibility of authentication.
[0248] [Variation 2-3] For example, in the second embodiment, the case where the authentication condition of one authentication, such as card scan authentication, is determined is exemplified, but there may be multiple authentications for which authentication conditions are set. The authentication condition determination unit 104 may determine whether or not user information satisfies the authentication condition of each of the multiple authentications. In Modification 2-3, card scan authentication and biometric authentication are described as examples of multiple authentications. The authentication condition of biometric authentication may be determined based on whether or not biometric information (e.g., a facial photograph or a fingerprint pattern) is registered in the authentication database DB1. The multiple authentications may be any authentications and are not limited to the example of Modification 2-3. For example, the multiple authentications may be three or more.
[0249] FIG. 20 is a diagram showing an example of a screen displayed on the second user terminal 30B of Modification 2-3. When it is determined that the user information satisfies the authentication conditions for each of the multiple authentications, the authentication content display unit 105 of Modification 2-3 displays authentication content for at least one of the multiple authentications on the second user terminal 30B based on the priority associated with each of the multiple authentications. In the example of FIG. 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. It is assumed that 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 Fig. 20, the authentication content display unit 105 displays the second authentication screen SC6 for card scan authentication, which has a relatively higher priority among card scan authentication and biometric authentication that satisfy the authentication conditions, on the second user terminal 30B before displaying the second authentication screen SC6 for biometric authentication. When the user selects a button B60 indicating that card scan authentication will not be performed, 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 Fig. 20.
[0251] The authentication system 1 of Variation 2-3 determines whether user information satisfies the authentication conditions for each of the multiple authentications. When it is determined that the user information satisfies the authentication conditions for each of the multiple authentications, the authentication system 1 displays authentication content for at least one of the authentications 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, thereby improving user convenience. The authentication system 1 makes it easier for the user to perform authentication with a relatively high priority, thereby improving the security of the payment service.
[0252] [Variation 2-4] For example, in the second embodiment, as in Modification 1-5, the authentication condition determination unit 104 may determine whether the user information satisfies the authentication condition by determining whether predetermined information is associated with the user information. The authentication condition determination unit 104 may determine the authentication condition by processing similar to that of the second authentication proposal unit 112 in Modification 1-5. The meaning of the predetermined information is as described in Modification 1-5. In Modification 2-4, the predetermined information may be information about belongings as in Modification 1-5, or may be information that is not particularly related to belongings. As in Modification 1-5, Modification 2-4 also takes as an example a case where a user ID corresponds to user information and authentication information stored in a credit card (e.g., an electronic money number or a point card number) corresponds to the predetermined information.
[0253] For example, if it is determined that predetermined information is not associated with the user information, the authentication condition determination unit 104 determines that the user information does not satisfy the authentication condition, and if it is determined that predetermined information is not associated with the user information, the authentication condition determination unit 104 determines that the user information satisfies the authentication condition. If it is determined that authentication information such as an electronic money number or a point card number is not associated with the user information, the authentication condition determination unit 104 determines that the user information does not satisfy the authentication condition. If it is determined that authentication information such as an electronic money number or a point card number is associated with the user information, the authentication condition determination unit 104 determines that the user information satisfies the authentication condition. The subsequent authentication flow may be the same as in 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. This allows the user to perform authentication when the predetermined information is associated with the user's user information, thereby improving user convenience. For example, the authentication system 1 can prevent the start of processing for card scan authentication even in an environment where authentication information such as an electronic money number or a point card number is not associated with the user ID and the user cannot perform card scan authentication.
[0255] [Variation 2-5] For example, in the second embodiment, similarly to Modification 1-6, when the predetermined service is a payment service, the authentication condition determination unit 104 may determine whether predetermined information related to a payment method that can be set in the payment service is associated with user information. The authentication condition determination unit 104 may determine whether the predetermined information is associated with user information by processing similar to that of the second authentication proposal unit 112 in 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 the electronic money number or the point card number is associated with user information.
[0256] The authentication system 1 of Variation 2-5 determines whether predetermined information related to payment methods that can be set in the payment service is associated with user information. This allows the user to perform authentication when predetermined information related to payment methods that can be set in the payment service is associated with their own user information, thereby improving user convenience. For example, the authentication system 1 can prevent a situation in which authentication information such as an electronic money number or a point card number is not associated with a user ID and a process for card scan authentication is executed even in an environment in which the user cannot perform card scan authentication.
[0257] [Variation 2-6] For example, as explained somewhat in the second embodiment, the user information acquisition unit 103 may acquire user information when a user who has used a service from a 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, authentication for the user to use the payment service from the second user terminal 30B may be authentication using the first user terminal 30A. The authentication using the first user terminal 30A may be the same as the second authentication using the first user terminal 30A explained in Modification 1-9.
[0258] The authentication condition determination unit 104 of Modification 2-6 determines whether the user information satisfies the authentication condition by determining whether the user owns the first user terminal 30A. This determination method may be the same as that of the authentication unit 102 of Modification 1-9. For example, the authentication condition determination unit 104 may determine whether the user owns the first user terminal 30A based on information (e.g., login account) transmitted by the first user terminal 30A, information (e.g., login account) transmitted by the second user terminal 30B, the usage status of the payment service from the first user terminal 30A (e.g., login date and time, date and time the payment code C30 was issued, expiration date of the payment code C30), or other information. For example, the authentication condition determination unit 104 may determine whether the user owns the first user terminal 30A based on information input by the user regarding whether the user owns the first user terminal 30A.
[0259] The authentication system 1 of Variation 2-6 acquires user information when a user who has used a service from a first user terminal 30A logs in to the service from a second user terminal 30B. The authentication system 1 determines whether the user information satisfies the authentication conditions by determining whether the user owns the first user terminal 30A. This allows the authentication system 1 to enhance security by performing authentication using the first user terminal 30A. For example, when performing authentication on the condition that the user owns the first user terminal 30A, the authentication system 1 can prevent the authentication process from being performed even if the user does not own the first user terminal 30A.
[0260] [Variation 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 execute 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 condition. This authentication is similar to the payment code authentication of the third embodiment. For example, the authentication unit 102 may execute 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 condition and the user performs an operation for authentication.
[0261] When it is determined that the user information satisfies the authentication conditions, the authentication system 1 of Variation 2-7 performs authentication in which the payment code C30 displayed on the first user terminal 30A is read by the second user terminal 30B. This allows the authentication system 1 to perform payment code authentication by simply performing an operation (e.g., launching a payment app) that the user is accustomed to for displaying the payment code C30, thereby improving user convenience. The authentication system 1 can also use the payment code C30 used for payment for authentication when changing devices, eliminating the need to issue an authentication code. As a result, the authentication system 1 can reduce development costs for implementing authentication functions.
[0262] [4-3. Modifications of the Third Embodiment] 21 is a diagram showing an example of functions realized in a modification of 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] [Variation 3-1] For example, in the third embodiment, as in the second embodiment, authentication content may be displayed based on whether or not authentication conditions are satisfied. 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 a user satisfies predetermined authentication conditions related to payment code authentication. The processing of the authentication condition determination unit 104 in Modification 3-1 is generally similar to that of the second embodiment. Since payment code authentication requires that the second user terminal 30B has the photographing unit 36B, Modification 3-1 takes as an example a case where the second user terminal 30B having the photographing unit 36B corresponds to an authentication condition.
[0264] For example, the authentication condition determination unit 104 may determine whether the user satisfies the authentication conditions by determining whether the second user terminal 30B has an image capturing unit 36B (image capturing function). The second user terminal 30B transmits user information indicating whether the second user terminal 30B has the image capturing unit 36B to the authentication server 10. The presence or absence of the image capturing unit 36B may be determined by a known method. For example, the second user terminal 30B may store in advance user information indicating the presence or absence of the image capturing unit 36B.
[0265] For example, the authentication condition determination unit 104 determines whether the second user terminal 30B has an image capture unit 36B (image capture 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 the image capture unit 36B, the authentication condition determination unit 104 determines that the user does not satisfy the authentication condition. If the user information indicates that the second user terminal 30B has the image capture unit 36B, the authentication condition determination unit 104 determines that the user satisfies the authentication condition.
[0266] The authentication condition for payment code authentication is not limited to the above example. For example, the authentication condition for payment code authentication may be that the user possesses the first user terminal 30A. In this case, the authentication condition determination unit 104 may determine whether the user satisfies the authentication condition by determining whether the user possesses the first user terminal 30A, as in Variation 2-6. If it is determined that the user does not possess the first user terminal 30A, the authentication condition determination unit 104 determines that the user authentication condition is not satisfied. If it is determined that the user possesses the first user terminal 30A, the authentication condition determination unit 104 determines that the user authentication condition is satisfied.
[0267] FIG. 22 is a diagram showing an example of a screen displayed on the second user terminal 30B in Modification 3-1. When it is determined that the user satisfies the authentication conditions, the authentication content display unit 105 in Modification 3-1 displays authentication content related to payment code authentication on the second user terminal 30B. The meaning of 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 FIG. 22, the message M42 displayed on the change necessity screen SC4 corresponds to the authentication content. In Modification 3-1, an example is given in which a part on the screen, such as the message M42, corresponds to the authentication content, but the entire screen may also correspond to the authentication content.
[0268] For example, when the user selects button B41 in the state of the change necessity screen SC4 in the upper right of FIG. 22, a read screen SC8 similar to that in the lower right of FIG. 12 is displayed. The read information acquisition unit 107 of Modification 3-1 acquires read information when the authentication content is displayed on the second user terminal 30B. The case where the authentication content is displayed on the second user terminal 30B refers to after the authentication content has been displayed on the second user terminal 30B. The authentication unit 102 of Modification 3-1 performs payment code authentication when the authentication content is displayed on the second user terminal 30B.
[0269] In Modification Example 3-1, if it is determined that the user does not satisfy the authentication conditions, the authentication content display unit 105 does not display authentication content related to payment code authentication on the second user terminal 30B. In the example at the bottom right of FIG. 22, since the user does not satisfy the authentication conditions, the message M42 is not displayed on the change necessity screen SC4. When the user selects button B41 on the change necessity screen SC4 at the bottom right of FIG. 22, the other authentication screen SC7 at the bottom right of FIG. 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 that of the second embodiment.
[0270] The authentication system 1 of Variation 3-1 determines whether a user satisfies predetermined authentication conditions related to payment code authentication. When it is determined that the user satisfies the authentication conditions, the authentication system 1 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 read 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 satisfies the authentication conditions, thereby improving user convenience. For example, the authentication system 1 can prevent the read screen SC8 for payment code authentication from being displayed to a user who does not satisfy the authentication conditions and therefore cannot perform payment code authentication.
[0271] [Variation 3-2] For example, in Modification 3-1, the authentication condition determination unit 104 may determine whether the user satisfies the authentication condition by determining whether there has been a change in the user information related to the user. The meaning of the user information is as described in the second embodiment. Modification 3-2 takes as an example a case where the user information is information registered in a payment service. For example, the user information may be the user's phone number, name, email address, address, other profile information, payment method information, payment source, charge source, or other information.
[0272] In Variation 3-2, an example is given in which the user selects from the second user terminal 30B whether or not there is a change in the user information. For example, if the user's telephone number corresponds to the user information, the user selects from the change necessity screen SC4 whether or not there is a change in the user information. The second user terminal 30B transmits change necessity information indicating whether or not there is a change in the user information to the authentication server 10 based on the user's selection result. If the user selects from the change necessity screen SC4 that there is a change in the user information, the change necessity information indicates that there is a change in the user information. If the user selects from the change necessity screen SC4 that there is no change in the user information, the change necessity information indicates that there is no change in the user information.
[0273] For example, the authentication condition determination unit 104 determines whether or not there is a change in the user information based on the change presence information received from the second user terminal 30B. If the change presence information indicates that there is no change in the user information, the authentication condition determination unit 104 determines that there is no change in the user information, and if the change presence information indicates that there is a change in the user information, the authentication condition determination unit 104 determines that the authentication condition is not satisfied if it is determined that there is no change in the user information, and determines that the authentication condition is satisfied if it is determined that there is a change in the user information.
[0274] In addition, in Modification 3-2, whether or not to change user information other than the phone number may be selected from the change necessity screen SC4. For example, 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 may be selected from the change necessity screen SC4. Whether or not to change the user information may be selected from a screen other than the change necessity screen SC4. The second user terminal 30B may transmit change necessity information indicating whether or not to change the user information to the authentication server 10 based on the selection result on the other screen.
[0275] Furthermore, the user may select whether or not there is a change in the user information from the first user terminal 30A. For example, the first user terminal 30A displays a screen on the display unit 35A that accepts the selection of whether or not there is a change in the user information. The screen may have the same layout as the change necessity screen SC4, or may have a layout different from that of the change necessity screen SC4. The first user terminal 30A may transmit change necessity information indicating whether or not there is a change in the user information to the authentication server 10 based on the selection result on the screen. The authentication condition determination unit 104 may determine whether or not there is a change in the user information based on the change necessity information received from the first user terminal 30A.
[0276] The authentication content display unit 105 in Modification 3-2 displays authentication content for payment code authentication on the second user terminal 30B based on whether or not there is a change in the user information. In Modification 3-1, as shown in the upper right of Fig. 22, the case where the message M42 on the change necessity screen SC4 corresponds to the authentication content is taken as an example, but in Modification 3-2, since it is determined whether or not there is a change in the user information after the change necessity screen SC4 is displayed, the case where the screen or parts of the screen displayed after the change necessity screen SC4 is displayed corresponds to the authentication content is taken as an example.
[0277] For example, the reading screen SC8 may correspond to the authentication content. If it is determined that there is no change in the user information, the authentication content display unit 105 does not display the reading screen SC8, which is an example of the authentication content, on the second user terminal 30B, and if it is determined that there is no change in the user information, the authentication content display unit 105 displays the reading screen SC8, which is an example of the authentication content, on the second user terminal 30B.
[0278] For example, the authentication selection screen SC9 described in Modification 1-8 may correspond to the authentication content. If it is determined that there is no change in the user information, the authentication content display unit 105 does not display the authentication selection screen SC9, which is an example of the authentication content, on the second user terminal 30B, and if it is determined that there is no change in the user information, the authentication content display unit 105 displays the authentication selection screen SC9, which is an example of the authentication content, on the second user terminal 30B.
[0279] The authentication system 1 of Variation 3-2 determines whether a user satisfies the authentication conditions by determining whether there are any changes in the user information. This allows the authentication system 1 to display authentication content depending on whether there are any changes in the user information, thereby improving user convenience. For example, the authentication system 1 can prevent authentication content for payment code authentication from being displayed to a user who does not satisfy the authentication conditions and therefore cannot perform payment code authentication.
[0280] [Variation 3-3] For example, as explained somewhat in Modification 3-2, the authentication condition determination unit 104 may determine whether there has been a change in the user information by determining whether there has been a change in the user's telephone number. Similar to Modification 3-3, Modification 3-3 takes as an example a case in which the user selects whether there has been a change in the telephone number from the change necessity screen SC4. However, it may also be determined that there has been a change in the user information when the user registers the changed telephone number with another service or website linked to the payment service. The authentication condition determination unit 104 may obtain the changed telephone number from the other service or website and determine whether there has been a change in the user information, or may request the other service or website to determine whether there has been a change in the user 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 transmits change presence / absence information indicating that there is no change in the telephone number to the authentication server 10. When the user selects button B41, the second user terminal 30B transmits change presence / absence information indicating that there is a change in the telephone number to the authentication server 10. The authentication condition determination unit 104 of Modification 3-3 may determine whether there is a change in the user information based on the change presence / absence information received from the second user terminal 30B.
[0282] In addition, in Variation 3-3, as in Variation 3-2, the user may select whether or not to change the telephone number from the first user terminal 30A. The first user terminal 30A transmits change / non-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 / non-change information received from the first user terminal 30A. In Variation 3-3, as in Variation 1-11, whether or not to change the telephone number may be selected by input on the telephone number input screen SC10 displayed on the first user terminal 30A.
[0283] The authentication system 1 of Variation 3-3 determines whether there has been a change in user information by determining whether there has been a change in the user's telephone number. This allows the authentication system 1 to display authentication content depending on whether there has been a change in the telephone number, thereby improving user convenience. For example, the authentication system 1 can prevent authentication content for payment code authentication from being displayed to a user whose telephone number has not changed and who does not require payment code authentication.
[0284] [Variation 3-4] For example, in the third embodiment, as in Modification 2-6, the authentication condition determination unit 104 may determine whether the user satisfies the authentication condition by determining whether the user owns the first user terminal 30A. As described in Modification 2-6, this determination method may be similar to that of the authentication unit 102 in Modification 1-9. For example, the authentication condition determination unit 104 may determine whether the user owns the first user terminal 30A based on information transmitted by the first user terminal 30A (e.g., a login account or a terminal ID), information transmitted by the second user terminal 30B (e.g., a login account or a terminal ID), the usage status of the payment service from the first user terminal 30A (e.g., the date and time of login, the date and time the payment code C30 was issued, the expiration date of the payment code C30), or other information. Furthermore, the authentication unit 102 may determine whether the user owns the first user terminal 30A based on information input by the user regarding whether the user owns the first user terminal 30A.
[0285] The authentication system 1 of Modification 3-4 determines whether the user satisfies 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, when performing authentication on the condition that the user possesses the first user terminal 30A, the authentication system 1 can prevent the authentication process from being executed even if the user does not possess the first user terminal 30A.
[0286] [Variation 3-5] For example, as described somewhat in the third embodiment, the read information acquisition unit 107 may acquire read information when the user does not select phone number authentication using the phone number registered with the payment service. In the example of Fig. 12, the user selects phone number authentication by selecting button B40. The user selects not to perform phone number authentication by selecting button B41.
[0287] For example, if the user selects button B41 and does not select phone number authentication, the second user terminal 30B then activates the photographing 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 executes payment code authentication when the user does not select phone number authentication. For example, the authentication unit 102 executes payment code authentication when the user does not select phone number authentication and performs an operation for payment code authentication. The flow of payment code authentication after the reading information is acquired is the same as in the third embodiment.
[0288] The authentication system 1 of Variation 3-5 acquires read information when the user does not select phone number authentication using the phone number registered with the payment service. The authentication system 1 performs payment code authentication when the user does not select phone number authentication. This allows the authentication system 1 to perform highly secure payment code authentication that requires the user to possess the first user terminal 30A when the user does not select phone number authentication.
[0289] [Variation 3-6] For example, since the payment code C30 is a hybrid code that can be used for both in-store payment and payment code authentication, when the authentication system 1 receives the read information, it needs to determine whether to execute payment or payment code authentication. The authentication system 1 may store data for the payment API and authentication API for determining this.
[0290] The payment API is an API for payment. The payment API may be similar to an API used in a known payment service. When the payment API receives the read information, it calls a function (program) for payment. In variant example 3-6, an example is given in which the payment API is realized by payment server 20, but the payment API may also be realized by another computer such as authentication server 10. For example, when the payment API receives the read information from a computer such as store terminal 40, it executes processing for payment. This processing may be similar to the processing of a known payment service.
[0291] The authentication API is an API for authenticating the payment code. When the authentication API receives the read information, it calls a function (program) for authenticating the payment code. In Variation 3-6, an example is given in which the authentication API is realized by the authentication server 10, but the authentication API may also be realized by another computer such as the payment server 20. For example, when the authentication API receives the read information from a computer such as the second user terminal 30B, it executes processing for authenticating the payment code. This processing is as described in the third embodiment.
[0292] In Variation 3-6, when a payment code C30 is read by a store terminal 40 in a payment service, the store terminal 40 sends read information to a payment API. For example, the store terminal 40 reads the payment code C30 displayed on the first user terminal 30A using the reader 46. The store terminal 40 acquires a code ID from the payment code C30 as read information. The store terminal 40 is assumed to have stored information about the payment API (e.g., a URL or IP address) in advance. Based on this information, the store terminal 40 sends a code ID, which is an example of read information, to the payment API. Upon receiving the code ID, the payment API 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 read information to an authentication API that is 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 photographing unit 36B. The second user terminal 30B acquires a code ID as read information from the payment code C30. It is assumed that the second user terminal 30B has stored information of the authentication API (for example, a URL or IP address) in advance. 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 that in the third embodiment.
[0294] In addition, when a payment is made by the second user terminal 30B reading a code displayed on the store terminal 40 or a code posted in a store, the second user terminal 30B sends the read information to the payment API instead of the authentication API when reading the code. The second user terminal 30B is assumed to have stored information about the payment API (for example, a URL or IP address) in advance.
[0295] For example, if the store code is read on the screen that is displayed when "Read Code" is selected on code screen SC3, the second user terminal 30B sends the read information to the payment API. If the payment code C30 is read on reading screen SC8, the second user terminal 30B sends the read information to the authentication API. In this way, the second user terminal 30B may determine whether the payment API or the authentication API is to be the destination depending on which screen the reading was performed on. The user may select whether the payment API or the authentication API is to be the destination.
[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 that is different from the payment API. The authentication system 1 acquires the read information sent to the authentication API. This allows the authentication system 1 to perform appropriate processing using the payment API and authentication API in each of the cases where the payment code C30 is read by the store terminal 40 and where the payment code C30 is read by the second user terminal 30B.
[0297] [Variation 3-7] For example, the first user terminal 30A may store setting information related to a payment service. The setting information is information indicating settings for using the payment service. For example, the setting information may be a setting for a payment method (e.g., a payment source or a charge source) used by the user in the payment service, a setting for whether the user uses points, an auto-charge setting, or other settings. The setting information may not be a setting for a payment method, but may be other settings such as a screen or notification displayed in a payment app. When a user logs in to a payment service from the second user terminal 30B and performs payment code authentication, the setting information stored in the first user terminal 30A may be reflected in the second user terminal 30B. The setting information may be displayed on the first user terminal 30A or the second user terminal 30B, or referred to when the authentication server 10 or the payment server 20 executes processing for the payment service.
[0298] The authentication system 1 of Variation 3-7 includes a setting information application unit 114. When payment code authentication is executed, the setting information application unit 114 applies setting 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 executed, the setting information application unit 114 requests the first user terminal 30A to transmit setting information. Upon receiving the request, the first user terminal 30A transmits the setting information stored in the data storage unit 300A to the authentication server 10. The setting information application unit 114 transmits the setting information acquired from the first user terminal 30A to the second user terminal 30B, thereby applying the setting information to the second user terminal 30B.
[0299] The setting information stored in a user's first user terminal 30A may be associated with the user ID and login account of the user and stored in advance in the authentication database DB1. In this case, the setting information application unit 114 may obtain the setting information from the authentication database DB1 and apply it to the second user terminal 30B. The second user terminal 30B records the setting information transmitted by the setting 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 setting information stored in the data storage unit 300B.
[0300] When payment code authentication is performed, the authentication system 1 of Modification Example 3-7 applies the setting information related to 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 setting work on the second user terminal 30B, and therefore the authentication system 1 can improve user convenience.
[0301] [Variation 3-8] For example, a malicious third party may obtain a screenshot (screen capture) of the payment code C30 on the first user terminal 30A by some method, impersonate the user, and attempt to break through the payment code authentication. Therefore, in Modification 3-8, if a screenshot operation is performed on 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 Modification 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 in the first user terminal 30A. The predetermined operation is a screenshot operation performed with the payment code C30 displayed. For example, the first user terminal 30A determines whether a screenshot operation is performed with the payment code C30 displayed. The method for determining the screenshot operation 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 is pressed.
[0303] For example, when 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 includes a code ID, but the invalidation request may also include information that identifies which user's payment code C30 should be invalidated. For example, the invalidation request may include a user ID or login account. When the payment code invalidation unit 115 receives an invalidation request, it invalidates the applicable payment code C30. The authentication server 10 or the payment server 20 does not execute payment even if it receives a payment request that includes the code ID of the invalidated payment code C30. When the authentication server 10 or the payment server 20 receives a payment request that includes the code ID of a valid payment code C30, it executes payment.
[0304] For example, the payment code invalidation unit 115 may invalidate the payment code C30 by storing an invalid flag indicating that the payment code C30 is invalid in the authentication database DB1, in association with the code ID of the payment code C30. In this case, even if a payment code C30 whose invalid flag indicates invalid is read, the payment code authentication or payment will not be successful and will fail. For example, if the invalid flag associated with the code ID of the payment code C30 that is the target of payment code authentication indicates invalid, the authentication unit 102 determines that the payment code authentication has failed.
[0305] The method by which the payment code invalidation unit 115 invalidates the payment code C30 is not limited to the method using the invalid flag. For example, the payment code invalidation unit 115 may invalidate the 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 invalidate the payment code C30 by deleting the code ID of the target payment code C30 from the authentication database DB1.
[0306] The authentication system 1 of Modification 3-8 invalidates the payment code C30 when a predetermined operation is performed on the payment code C30 at the first user terminal 30A. This prevents a malicious third party from successfully authenticating the payment code even if they illegally obtain a screenshot of the payment code C30, and therefore the authentication system 1 can improve the security of the payment service.
[0307] [4-4. Other Modifications] For example, the above modifications may be combined.
[0308] For example, in the first to third embodiments, an example is given of a situation in which a user changes the model from the first user terminal 30A to the second user terminal 30B, but the model of the first user terminal 30A and the model of the second user terminal 30B may be the same. Even when the user repurchases a second user terminal 30B of the same model because the battery of the first user terminal 30A becomes weak, processing similar to that of the first to third embodiments may be executed. The user may have purchased the second user terminal 30B before purchasing the first user terminal 30A. Either the first user terminal 30A or the second user terminal 30B may be older.
[0309] For example, the authentication system 1 may not include the authentication server 10, and the authentication function may be realized by the payment server 20. That is, the payment server 20 may have the functions of the authentication server 10 described in the embodiment and the above-mentioned modified example. 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 a user's login to a 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 transmits the code ID as read information to the payment server 20. The payment server 20 performs 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 currently logged in from the second user terminal 30B.
[0310] For example, the functions described as being realized by the authentication server 10 may be realized by the payment server 20, the first user terminal 30A, the second user terminal 30B, the store terminal 40, or another computer. The processes described as being realized by the authentication server 10 may be shared among multiple computers. The functions described as being realized by the payment server 20 may be realized by the authentication server 10, the first user terminal 30A, the second user terminal 30B, the store terminal 40, or another computer. The processes described as being realized by the payment server 20 may be shared among multiple computers. For example, although the above example shows a case where the authentication function is realized by the authentication server 10 and the payment function is realized by the payment server 20, the authentication function and the payment function may be realized by a single computer (e.g., the authentication server 10, the payment server 20, or another computer).
[0311] [5. Notes] For example, the authentication system 1 can also be configured as follows.
[0312] [5-1. Supplementary notes regarding 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 that acquires change necessity information regarding whether or not to change the telephone number registered in a predetermined service when a user logs in to the service from a second user terminal different from the first user terminal after logging in to the service from a first user terminal; an authentication unit that switches authentication performed by the second user terminal based on the change necessity information; Authentication system including. (1-2) The authentication unit If the change necessity information indicates that the telephone number should not be changed, a first authentication is performed using the telephone number; When the change necessity information indicates that the telephone number is to be changed, a second authentication different from the first authentication is performed. The authentication system according to (1-1). (1-3) When the change necessity information indicates that the telephone number should not be changed, the authentication unit executes, as the first authentication, authentication similar to the authentication executed by the first user terminal using the telephone number. The authentication system according to (1-2). (1-4) the authentication system further includes a function restriction unit that, when the second authentication is performed, restricts functions related to the service used from the second user terminal more than when the first authentication is performed. An authentication system according to (1-2) or (1-3). (1-5) the authentication system further includes a restriction release unit that releases the restriction on the function when a predetermined release condition is satisfied. The authentication system according to (1-4). (1-6) The authentication system includes: a user information acquisition unit that acquires user information about the user when the change necessity information indicates that the telephone number should be changed; a second authentication proposing unit that proposes, as the second authentication, an authentication method that satisfies a predetermined authentication condition for the user information; Including, An authentication system according to any one of (1-2) to (1-5). (1-7) the second authentication proposal unit determines whether predetermined information related to belongings is associated with the user information, thereby determining whether the user information satisfies the authentication condition; The authentication system according to (1-6). (1-8) The service is a payment service, the second authentication proposal unit determines whether the predetermined information regarding payment methods that can be set in the payment service is associated with the user information; The authentication system according to (1-7). (1-9) the authentication system further includes a second authentication content display unit that, when the change necessity information indicates that the telephone number should be changed and a predetermined authentication condition is satisfied, causes the second user terminal to display second authentication content related to the second authentication; the authentication unit performs the second authentication when the second authentication content is displayed on the second user terminal. An authentication system according to any one of (1-2) to (1-8). (1-10) the second authentication content display unit, when the change necessity information indicates that the telephone number should be changed and a predetermined authentication condition is satisfied, causes the second user terminal to distinguish between the second authentication content and other authentication content related to another authentication different from the second authentication; 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 according to (1-9). (1-11) the authentication unit performs the second authentication using the first user terminal when the change necessity information indicates that the telephone number is to be changed and the first user terminal is in possession. An authentication system according to any one of (1-2) to (1-10). (1-12) The service is a payment service in which payment is executed by reading a payment code, the authentication unit executes the second authentication in which the payment code displayed on the first user terminal is read by the second user terminal. (1-11) An authentication system according to the present invention. (1-13) the authentication unit executes the second authentication in which the changed telephone number is input from the first user terminal when the change necessity information indicates that the telephone number is to be changed. An authentication system according to any one of (1-2) to (1-12).
[0313] [5-2. Supplementary notes regarding 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 related to a user who uses a predetermined service; an authentication condition determination unit that determines whether the user information satisfies a predetermined authentication condition related to authentication in the service; Authentication system including. (2-2) the authentication system further includes an authentication content display unit that, when it is determined that the user information does not satisfy the authentication conditions, does not display authentication content related to the authentication on the user terminal of the user, and, when it is determined that the user information satisfies the authentication conditions, displays the authentication content on the user terminal. The authentication system described in (2-1). (2-3) the authentication system further includes an other authentication content display unit that, when it is determined that the user information does not satisfy the authentication condition, causes the user terminal to display other authentication content related to another authentication different from the authentication. The authentication system described in (2-2). (2-4) the authentication content display unit causes the authentication content to be preferentially displayed on the user terminal when it is determined that the user information satisfies the authentication condition. An authentication system according to (2-2) or (2-3). (2-5) the authentication system further includes an other authentication content display unit that, when it is determined that the user information satisfies the authentication condition, causes the user terminal to display other authentication content related to another authentication different from the authentication based on a selection status of the authentication content by the user; An authentication system according to any one of (2-2) to (2-4). (2-6) the authentication condition determination unit determines whether the user information satisfies the authentication condition for each of the plurality of authentications; when it is determined that the user information satisfies the authentication condition for each of the plurality of authentications, the authentication content display unit displays the authentication content for at least one of the authentications on the user terminal based on a priority associated with each of the plurality of authentications; An authentication system according to any one of (2-2) to (2-5). (2-7) the authentication condition determination unit determines whether the user information satisfies the authentication condition by determining whether predetermined information is associated with the user information; An authentication system according to any one of (2-1) to (2-6). (2-8) The service is a payment service, the authentication condition determination unit determines whether the predetermined information regarding payment methods 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 condition by determining whether the user owns the first user terminal; An authentication system according to any one of (2-1) to (2-8). (2-10) The 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 condition, performs authentication by reading the payment code displayed on the first user terminal with the second user terminal. (2-9) An authentication system according to the present invention.
[0314] [5-3. Supplementary notes regarding the third embodiment] For example, the authentication system 1 of the third embodiment can also be configured as follows. (3-1) a read information acquisition unit that acquires read information read from a payment code when the payment code displayed on a first user terminal of a user who uses a payment service is read by a second user terminal different from the first user terminal; an authentication unit that performs payment code authentication using the payment code when the read information is acquired; Authentication system including. (3-2) the authentication system further includes a second user information acquisition unit that acquires second user information related to the user who has logged in to the payment service from the second user terminal; When the read information is acquired, the authentication unit performs the payment code authentication based on first user information about the user who logged in to the payment service from the first user terminal and the second user information. 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; the authentication unit performs the payment code authentication based on the first user information and the second user information acquired by the first user information acquisition unit when the read information is acquired. The authentication system described in (3-2). (3-4) The authentication system includes: an authentication condition determination unit that determines whether the user satisfies a predetermined authentication condition related to the payment code authentication; an authentication content display unit that displays authentication content related to the payment code authentication on the second user terminal when it is determined that the user satisfies the authentication condition; The authentication system according to any one of (3-1) to (3-3), further comprising: (3-5) the authentication condition determination unit determines whether or not there is a change in user information related to the user, thereby determining whether or not the user satisfies the authentication condition; The authentication system described in (3-4). (3-6) the authentication condition determination unit determines whether there is a change in the user information by determining whether there is 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 condition by determining whether the user owns the first user terminal; An authentication system according to any one of (3-4) to (3-6). (3-8) the read information acquisition unit acquires the read information when the user does not select phone number authentication using the phone number registered in the payment service; the authentication unit executes the payment code authentication when the user does not select the phone number authentication. An authentication system according to any one of (3-1) to (3-7). (3-9) When the payment code is read by a store terminal in the payment service, the store terminal transmits the read information to a 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 that is different from the payment API, the read information acquisition unit acquires the read information transmitted to the authentication API; An authentication system according to any one of (3-1) to (3-8). (3-10) The authentication system further includes a setting information application unit that applies setting information related to the payment service stored in the first user terminal to the second user terminal when the payment code authentication is executed. An authentication system according to any one 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 on the payment code is performed in the first user terminal; An authentication system according to any one 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 memory 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 photographing unit, 40 store terminal, 46 reading unit, 100 data storage unit, 101 change necessity 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 read information acquisition unit, 108 first user information acquisition unit, 109 second user information acquisition unit, 110 Function restriction unit, 111 restriction removal 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 units, 301A, 301B operation reception unit, 302A, 302B display control unit, 400 data storage unit, 401 payment request transmission unit, B10, B40, B41, B60 button, C30 payment code, DB1 authentication database, DB2 payment database, F70, F100 input form, I81 captured image, SC1 login screen, SC2 phone number authentication screen, SC3 code screen, SC4 change necessity screen, SC5 first authentication screen, SC6 second authentication screen, SC7 other authentication screen, SC8 reading screen, SC9 authentication selection screen, SC10 phone number input screen.
Claims
1. a user information acquisition unit that acquires user information related to a user who uses a predetermined service; an authentication condition determination unit that determines whether the user information satisfies a predetermined authentication condition related to authentication in the service; Authentication system including.
2. the authentication system further includes an authentication content display unit that, when it is determined that the user information does not satisfy the authentication conditions, does not display authentication content related to the authentication on the user terminal of the user, and, when it is determined that the user information satisfies the authentication conditions, displays the authentication content on the user terminal. The authentication system of claim 1 .
3. the authentication system further includes an other authentication content display unit that, when it is determined that the user information does not satisfy the authentication condition, causes the user terminal to display other authentication content related to another authentication different from the authentication. The authentication system of claim 2 .
4. the authentication content display unit causes the authentication content to be preferentially displayed on the user terminal when it is determined that the user information satisfies the authentication condition.
4. The authentication system according to claim 2 or 3.
5. the authentication system further includes an other authentication content display unit that, when it is determined that the user information satisfies the authentication condition, causes the user terminal to display other authentication content related to another authentication different from the authentication based on a selection status of the authentication content by the user; 4. The authentication system according to claim 2 or 3.
6. the authentication condition determination unit determines whether the user information satisfies the authentication condition for each of the plurality of authentications; when it is determined that the user information satisfies the authentication condition for each of the plurality of authentications, the authentication content display unit displays the authentication content for at least one of the authentications on the user terminal based on a priority associated with each of the plurality of authentications; 4. The authentication system according to claim 2 or 3.
7. the authentication condition determination unit determines whether the user information satisfies the authentication condition by determining whether predetermined information is associated with the user information; 4. The authentication system according to claim 1.
8. The service is a payment service, the authentication condition determination unit determines whether the predetermined information regarding payment methods that can be set in the payment service is associated with the user information; The authentication system of claim 7.
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 condition by determining whether the user owns the first user terminal; 4. The authentication system according to claim 1.
10. The 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 condition, performs authentication by reading the payment code displayed on the first user terminal with the second user terminal. The authentication system of claim 9.
11. a user information acquisition step of acquiring user information related to a user who uses a predetermined service; an authentication condition determination step of determining whether or not the user information satisfies a predetermined authentication condition related to authentication in the service; An authentication condition determination method including:
12. a user information acquisition unit that acquires user information regarding a user who uses a predetermined service; an authentication condition determination unit that determines whether the user information satisfies a predetermined authentication condition related to authentication in the service; A program that allows a computer to function as a
Citation Information
Patent Citations
JP121099A