Service providing device, authentication method, and program

Abstract

To improve convenience of user authentication in a system in which an account of a user is managed in association with a telephone number.SOLUTION: A service providing device provides a predetermined service to a user in cooperation with a user application that operates on a terminal device of the user, the predetermined service managing an account of the user in association with a telephone number of the user. The service providing device comprises an authentication processing section that executes authentication processing for authenticating a user of the predetermined service. The authentication processing section issues a one-time code and notifies the user application of the code in a case where an authentication request for the user is received from the user application, and authenticates the user of the user application when option information notified by an originated call matches the one-time code in a case where the originated call is received after the notification of the one-time code.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a service providing device, an authentication method, and a program. [Background technology]

[0002] Conventionally, in authenticating a user logging in to a service, in addition to the specified authentication means, it has been possible to check whether the terminal device from which the login request was made is a registered terminal device, and if the terminal device from which the login request was made is not a registered terminal device, additional authentication is performed using a QR code (registered trademark, the same applies below) or SMS (Short Message Service) (see, for example, Patent Documents 1 and 2). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7247416 [Patent Document 2] Patent No. 7202500 Summary of the Invention [Problem to be solved by the invention]

[0004] In conventional technology, if the terminal device that made the login request was not a registered terminal device, the user's identity could be verified by issuing an authentication code (hereinafter referred to as the authentication code) and having it return it. However, in this case, there was a risk that a third party who had obtained the authentication code illegally through phishing or other methods could misuse the legitimate user's account. In addition, in this case, the notified authentication code and other information, such as ID and password, had to be manually entered into a specific app, which could be time-consuming. As such, conventional technology required further improvements in convenience from the perspectives of security and operability.

[0005] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide an authentication device, an authentication method, and a program that can improve the convenience of user authentication in a system in which user accounts are managed in association with telephone numbers. [Means for solving the problem]

[0006] One aspect of the present invention is a service providing device that works in cooperation with a user application running on the user's terminal device to provide a specified service to the user, wherein the specified service manages the user's account by linking it to the user's telephone number, and includes an authentication processing unit that performs authentication processing to authenticate the user of the specified service, wherein the authentication processing unit, when receiving an authentication request for the user from the user application, issues a one-time code and notifies the user application, and when a call is received after notifying the one-time code, authenticates the user of the user application if the optional information notified by the call matches the one-time code. [Effects of the Invention]

[0007] According to one aspect of the present invention, a service providing device, an authentication method, and a program can be provided that can improve the convenience of user authentication in a system in which user accounts are managed in association with telephone numbers. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] FIG. 2 is a configuration diagram of a payment server 100 according to the first embodiment. [Figure 5]FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 10 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] FIG. 10 is a diagram (part 1) showing an example of screen transitions in passwordless authentication. [Figure 8] FIG. 2 is a diagram (part 2) showing an example of screen transitions in passwordless authentication. [Figure 9] FIG. 10 is a diagram showing an example of a processing flow when the payment server 100 authenticates a user by passwordless authentication when logging in to an electronic payment service. [Figure 10] FIG. 10 is a diagram (part 1) showing an example of screen transitions of payment application 20 according to the first embodiment of the model change procedure. [Figure 11] FIG. 10 is a diagram (part 2) showing an example of screen transitions of payment application 20 according to the first embodiment of the model change procedure. [Figure 12] 10A to 10C are diagrams showing an example of screen transitions of the payment application 20 according to the second embodiment of the model change procedure. [Figure 13] 10A to 10C are diagrams showing an example of screen transitions of the payment application 20 according to the third embodiment of the model change procedure. [Figure 14] FIG. 10 is a diagram showing an example of a processing flow according to the first embodiment of call origination authentication. [Figure 15] FIG. 10 is a diagram showing an example of a processing flow according to a second embodiment of call origination authentication. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, with reference to the drawings, embodiments of a service providing device, an authentication method, and a program of the present invention will be described. Various devices, such as a "server," a "management device," and an "information providing device," that provide services to users and perform internal analysis, may be realized by a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) and the business that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a "payment app." An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real store) existing in the real world, but may also include a virtual store for e-commerce transactions. A virtual store may also include a store operated by an entity other than the operator of the electronic payment service. In such a case, when making a payment for a purchase at the virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and processing such as payment when a purchase is made at the store is primarily conducted between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] Figure 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, and one or more second store terminal devices 70 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, etc.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input acceptance function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment app 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment app 20 is installed on the user terminal device 10 from, for example, an application store, and controls the camera, communication device, touch panel, etc. The input acceptance function may include a function for acquiring information necessary for biometric authentication such as fingerprint authentication or iris authentication.

[0012] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).

[0013] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, tablet terminal, personal computer, etc. An interface for affiliated stores 72 runs on the second store terminal device 70. The interface for affiliated stores 72 may be an app for affiliated stores or a browser. The interface for affiliated stores 72 accepts coupon settings and the like from the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading the code image displayed by the user terminal device 10 by executing the app for affiliated stores.

[0014] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, this distinction will not be made and it is assumed that payment information is sent from the first store terminal device 50.

[0015] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns for electronic payment: Pattern 1 and Pattern 2.

[0016] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10, with the payment application 20 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment application 20 sends first payment information including the store URL and account ID to the payment server 100 (S2). The payment server 100 searches for store information (described below) using the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include information on the payment amount in addition to the store URL. In this case, the step of the user inputting the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.

[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, the payment app 20 sends a request to issue a one-time code to the payment server 100 when the payment app 20 is launched, when a payment operation is performed in the payment app 20, at the automatic update timing (e.g., every minute), and at other timings (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image, such as a QR code or barcode, generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first in-store terminal device 50, and the first in-store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). The first in-store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode, manually entering it, etc. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). Then, the payment server 100 sends a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

[0018] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0019] [Payment server] FIG. 4 is a configuration diagram of the payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a content providing unit 120, a payment processing unit 130, an information management unit 140, a user authentication unit 150, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a GPU (Graphics Processing Unit), or may be realized by a combination of software and hardware. The program may be stored in advance in a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device with a non-transitory storage medium), or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.

[0020] The storage unit 170 is a HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access via a network. The storage unit 170 stores information such as user information 172, content information 174, affiliated store / shop information 176, etc.

[0021] The communication unit 110 is a communication interface for connecting to the network NW, and is, for example, a network interface card.

[0022] The content providing unit 120 has, for example, a web server function, and provides information (content) for displaying various screens for electronic payment services to the user terminal device 10. The content providing unit 120 reads out necessary content from the content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs from the user while content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100.

[0023] The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.

[0024] FIG. 5 is a diagram showing an example of the contents of user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, telephone number, and password, as well as associated information such as email address, user ID, name, address, date of birth, registration date, charge balance, credit card payment settings, credit card limit, credit card payment amount, available credit card payment amount, payment method settings, bank account, credit card number, charge history information, payment history information, and login authentication settings. The user URL is used for remittance processing between users. When registering for the electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100, and the user ID can be set by the user (or does not have to be set). The email address, name, address, and date of birth are also information that can be set by the user (or do not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.

[0025] The charge balance indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated bank's ATM (Automatic Teller Machine) or from a registered bank account. The credit payment setting indicates whether the settings for electronic credit payment have been completed and is set to either "Completed" or "Not Completed." The credit payment limit is the monthly credit payment limit. The credit payment amount is the amount of credit payment already used in the current month. The available credit payment amount is the amount of credit payment available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the figure shows only one credit payment limit, in reality, there may also be daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be discussed later. The payment method setting indicates whether the user will currently make electronic payments using the charge balance or by credit payment. The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. The payment history information is information that shows the breakdown of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.). The login authentication settings are setting information for the authentication method registered as the first authentication method, which will be described later.

[0026] 6 is a diagram showing an example of the contents of affiliated store / store information 176. The affiliated store / store information 176 includes, for example, a first table 176A in which an affiliated store ID and a store ID are associated with a store URL, a second table 176B in which an affiliated store ID is associated with an affiliated store name and sales amount (described above), and a third table 176C in which a store ID is associated with a store name. In addition to this information, the affiliated store / store information 176 may also include information such as the category of the affiliated store or store, the store's location, and payment patterns.

[0027] The information management unit 140 manages the user information 172 and the affiliated store / store information 176 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds new records to, edits, deletes, etc. the user information 172 and the affiliated store / store information 176.

[0028] The user authentication unit 150 performs authentication processing for a user logging in to an electronic payment service. Specifically, the user authentication unit 150 processes a user login request received from the user terminal device 10 in the payment server 100. More specifically, the user authentication unit 150 basically performs user authentication using a method that does not require the user to input text information such as a password or authentication code. Hereinafter, user authentication using this method will be referred to as "passwordless authentication." This passwordless authentication allows the user to complete login in as few as two operations after displaying the login screen of the payment application 20. The user authentication unit 150 is an example of an "authentication processing unit."

[0029] [Electronic Payment] When payment information is acquired from the user terminal device 10 or the first store terminal device 50, the payment processing unit 130 references the user information 172 to acquire the "payment method setting" of the user. For users whose "payment method setting" is set to "charge balance," the payment processing unit 130 performs electronic payment as follows: For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales proceeds. The item value of the affiliated store's sales proceeds is not itself used as electronic money, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.

[0030] The payment processing unit 130 performs electronic payments for users whose "setting information" is set to "credit card payment" as follows. Credit card payment is a payment method in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service. The operator of the electronic payment service acts as the creditor, allowing electronic payments within the credit card payment limit and independent of the remaining balance. To receive the credit card payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The monthly amount used for credit card payment is settled on the following month's payment date, for example, by debit from a bank account. In this case, the payment processing unit 130 makes a provisional settlement by adding the settlement amount to the credit card payment amount and subtracting the same amount from the available credit card balance. On the closing date, the payment processing unit 130 performs the process described above to debit the current month's payment on the following month's payment date, or requests the credit card company operator to perform this process. If the settlement amount exceeds the available credit card balance at the time of provisional settlement, an error notification is returned to the payment app 20.

[0031] [Passwordless authentication] Conventional authentication methods impose a heavy operational burden on users, with survey results showing that users typically perform input operations of 30 or more times per login process, such as entering a password or authentication code. In contrast, in this embodiment, the passwordless authentication described above makes it possible to complete user authentication with as few as two operations from the login screen. Whether the minimum number of operations is two or not may vary depending on the specifications of the user terminal device 10 (particularly the specifications of the operating system), but the resulting difference in the number of operations is at most one or two, which is still a significant reduction in the number of operations compared to the conventional 30 or so operations.

[0032] 7 and 8 are diagrams showing an example of screen transitions in passwordless authentication. The example in FIG. 7 shows the transitions between an authentication method selection screen D10, a sign-in screen D20, and a top screen D30, in this order. The authentication method selection screen D10 is a screen that allows a user to select an authentication method for logging in to payment application 20. The authentication method selection screen D10 has, for example, a first authentication method selection section D11, a second authentication method selection section D12, and a third authentication method selection section D13. The first authentication method selection section D11, the second authentication method selection section D12, and the third authentication method selection section D13 are user interfaces such as buttons and links. Here, payment application 20 is an example of a "user application."

[0033] The first authentication method selection unit D11 accepts a selection operation for the first authentication method. The second authentication method selection unit D12 accepts a selection operation for the second authentication method. The second authentication method is, for example, an authentication method using a telephone number. The third authentication method selection unit D13 accepts a selection operation for the third authentication method. The third authentication method is, for example, an authentication method using a personal identification medium (e.g., a My Number card in Japan) issued by the country or administrative agency to which the user belongs. The "ccc card" in FIG. 7 is an example of a personal identification medium. FIG. 7 illustrates a situation in which the authentication method selection screen D10 transitions to a sign-in screen D20 as a result of an operation on the first authentication method selection unit D11. The sign-in screen D20 is a screen that accepts an operation for the user to sign in to a type 1 web service. FIG. 7 illustrates an example in which the sign-in screen D20 is displayed as an overlay on the authentication method selection screen D10. For example, sign-in screen D20 includes a display unit D21 that displays confirmation items for the user regarding signing in to the type 1 web service, and an operation unit D22 that accepts an operation by the user to instruct the user to sign in. When the user operates operation unit D22, authentication processing by the type 1 web service is performed, and if authentication is successful, the screen of payment application 20 transitions to top screen D30. Top screen D30 is the screen that is first displayed after logging in to payment application 20. For example, top screen D30 may display various operation menus related to the electronic payment service.

[0034] More specifically, the first authentication method is a method in which, when a user has an account with a certain type of web service, the authentication function of the web service is used to authenticate login to an electronic payment service. The certain type of web service here refers to a type of web service that allows payment server 100, which communicates with payment application 20, to recognize that the user has an account with the web service. Hereinafter, this type of web service will be referred to as a "type 1 web service" and other web services will be referred to as a "type 2 web service" to distinguish between the two.

[0035] Generally, applications running on terminal devices are created in a format appropriate for the OS of the operating environment, and therefore the application contains information about the OS of the operating environment. Therefore, by communicating with the payment app 20, the payment server 100 can recognize the OS type of the user terminal device 10 on which the payment app 20 is running. Therefore, if an account for a type 1 web service is linked to the OS of the user terminal device 10, the payment server 100 can recognize that the user of the payment app 20 has an account for the type 1 web service by recognizing the OS type of the user terminal device 10 on which the payment app 20 it communicates with is running. Examples of OSs linked to such type 1 web services include Android (registered trademark) provided by Google (registered trademark) and iOS provided by Apple (registered trademark). For example, if the OS of the user terminal device 10 is Android (registered trademark), the payment server 100 can recognize that the user has an account for a web service provided by Google (registered trademark) by communicating with the payment app 20. Similarly, if the OS of the user terminal device 10 is iOS (registered trademark), the payment server 100 can recognize that the user has an account for a web service provided by Apple (registered trademark) by communicating with the payment app 20. The payment server 100 displays the authentication method corresponding to the recognized type 1 web service as the first authentication method on the authentication method selection screen D10. "aaa-ID" in FIG. 7 is an example of a type 1 web service.

[0036] Furthermore, in a type 1 web service, the user's account is linked to the OS (operating system) of the user terminal device 10 used by the user. Furthermore, the type 1 web service manages the login status by combining the user and the user terminal device 10, and authenticates the user without requesting a password if the user requesting authentication remains logged in to the service. Meanwhile, the user terminal device 10 is used in a state where the user is logged in to the type 1 web service using an account linked to the OS. Therefore, according to the first authentication method, the user can log in to payment application 20 without entering a password.

[0037] For example, the second authentication method requires input of a phone number and a password, whereas the first authentication method allows a user to complete login with two operations: an operation of the first authentication method selection unit D11 and an operation of the operation unit D22. Furthermore, confirmation items related to signing in to the first type of web service only need to be confirmed the first time the first authentication method is used, and may be omitted from subsequent uses. Therefore, according to the first authentication method, login can be completed with only one operation of the first authentication method selection unit D11, at the shortest. Since the total number of characters in a phone number and a password is statistically considered to be around 30 characters, the first authentication method can significantly reduce the user's input operation burden during authentication at login.

[0038] FIG. 8 shows an example of screen transitions when a first authentication method is achieved by combining authentication by a type 1 web service and biometric authentication. FIG. 8 shows an example when biometric authentication is applied to the confirmation operation on the sign-in screen D20. In FIG. 8, the same user interfaces as in FIG. 7 are denoted by the same reference numerals. Here, fingerprint authentication is used as the biometric authentication, but other biometric authentication methods such as voiceprint authentication or iris authentication may be used instead. In the example of FIG. 8, the number of operations is increased by at most one compared to the example of FIG. 7, and similar to the example of FIG. 7, the input operation load at the time of login can be significantly reduced compared to other authentication methods. "bbb-ID" in FIG. 8 is an example of a type 1 web service that is different from the example of FIG. 7.

[0039] In the past, authentication functions provided by web services such as social networking services (SNSs) have been presented to users as options for authentication methods when logging in to other systems or services. Conventionally, any web service, regardless of whether it is a type 1 or type 2 web service, has been presented as an option. Because type 2 web services are not tied to the OS of the user terminal device 10, the user is required to enter authentication information during authentication. In contrast, in this embodiment, the payment server 100 recognizes the OS type of the user terminal device 10. If the OS type is tied to a type 1 web service, the payment server 100 presents the type 1 web service, rather than the type 2 web service, as an option for authentication methods. Therefore, when a type 1 web service is selected, the user is not required to enter authentication information, enabling login with fewer operations than conventional methods. For example, in the example of FIG. 7 , the user can complete login with a minimum of two operations: operating the first authentication method selection section D11 on the authentication method selection screen D10 and operating the operation section D22 on the subsequent sign-in screen D20.

[0040] FIG. 9 is a diagram showing an example of the processing flow when the payment server 100 authenticates a user through passwordless authentication when logging in to an electronic payment service. Here, it is assumed that, at the start of the series of processes, the payment application 20 is not running on the user terminal device 10, and the user has not logged in to the electronic payment service. First, the user operates the user terminal device 10 to start the payment application 20 (S101). Upon startup, the payment application 20 requests content information for displaying the authentication method selection screen D10 from the payment server 100 (S102). In response to this request, the payment server 100 returns content information for the authentication method selection screen D10 to the payment application 20 (S103). The payment application 20 displays the authentication method selection screen D10 using the content information provided by the payment server 100, and accepts an operation to select an authentication method on the authentication method selection screen D10 (S104). The payment application 20 notifies the payment server 100 of the selection result of the authentication method (S105).

[0041] Here, a case where the authentication method using the type 1 web service is selected will be described. From the notification in S105, the payment server 100 recognizes that the user has selected the authentication method using the type 1 web service as the authentication method for logging in to the electronic payment service (S106), and causes the payment application 20 to display the sign-in screen D20 of the type 1 web service (S107). Here, some or all of the content information for displaying the sign-in screen D20 may be included in the content information 174, or may be acquired from the system of the type 1 web service. The payment application 20 accepts the user's operation on the sign-in screen D20 (authentication execution) (S108), and notifies the system of the type 1 web service of this fact (S109). Subsequently, when the type 1 web service authenticates the user (S110), it notifies the payment application 20 of this fact (S111), and the payment application 20 notifies the payment server 100 of the success of the authentication using the type 1 web service (S112). Upon receiving this notification, the payment server 100 transmits content information for displaying the top screen D30 to the payment application 20 (S113), and the top screen D30 is displayed on the payment application 20 (S114), thereby completing the user's login to the electronic payment service.

[0042] The processing flow described in FIG. 9 assumes a situation in which the first-class web service is registered in advance with the electronic payment service as the user's authentication method. However, if the user changes the user terminal device 10 they use due to a model change or other reason, the new user terminal device 10 is not registered with the electronic payment service. Therefore, regardless of whether the above-described passwordless authentication registration (registering the first-class web service as the passwordless authentication method) has been completed, the payment server 100 requests the user to perform a model change procedure to change the registration of the previous user terminal device 10 to the new user terminal device 10. After completing the model change procedure, the user can use the payment app 20 with the new user terminal device 10. In the following description, for simplicity, the previous user terminal device 10 will be referred to as the old terminal 10, and the new user terminal device 10 will be referred to as the new terminal 10.

[0043] Whether the user terminal device 10 has been changed can be identified by the payment server 100 managing the device ID of the payment app 20 by linking it to the user. More specifically, the payment server 100 acquires the device ID of the payment app 20 from the accessing payment app 20, and can detect that the user terminal device 10 has been changed if the acquired device ID does not match the device ID previously linked to the user. Such an authentication method based on device ID matching is used by itself or in combination with other authentication methods as a means for authenticating the accessing user terminal device 10 or the user. Such an authentication method is generally called device authentication or terminal authentication.

[0044] In the payment server 100 of the embodiment, the user authentication unit 150 has such a device authentication function, and this device authentication function can detect whether or not there has been a change in the user terminal device 10. Furthermore, the payment server 100 can be configured to be able to perform authentication by combining the results of device authentication in the above-mentioned first authentication method, second authentication method, and third authentication method.

[0045] The following describes an example of a method for allowing a user who has already registered for passwordless authentication to carry out a model change procedure. Here, the model change procedure is assumed to be completed when the user logs in to the electronic payment service from payment application 20 on new terminal 10.

[0046] <First example of model change procedure> FIG. 10 is a diagram showing an example of screen transitions of the payment app 20 according to a first embodiment of the model change procedure. The model change procedure according to the first embodiment is completed by displaying a two-dimensional code for the model change procedure on the payment app 20 of the old terminal 10 and reading the two-dimensional code with the payment app 20 of the new terminal 10. A user who is performing the model change procedure first displays an authentication method selection screen D41 on the payment app 20 of the old terminal 10 and selects an authentication method to use for logging in. Here, a case where a first-type web service is selected as the authentication method will be described. FIG. 10 shows an example where the "aaa-ID" illustrated in FIG. 7 is selected as the first-type web service. When the user selects the authentication method using "aaa-ID," a sign-in screen D42 using "aaa-ID" is displayed on the payment app 20. When a sign-in operation is performed on the sign-in screen D42, a two-dimensional code display screen D43 is displayed on the payment app 20. Here, authentication using the first-type web service is an example of "first-factor authentication." Furthermore, even if the first-class web service is "bbb-ID" as shown in Figure 8 instead of "aaa-ID", the basic flow is the same as in Figure 10, although the appearance of the sign-in screen D42 will be different (see Figure 8).

[0047] The two-dimensional code display screen D43 includes, for example, a two-dimensional code CD for a model change procedure and a link LK for transitioning to a procedure when the old terminal 10 is not at hand. The two-dimensional code CD is an encoded one-time code with an expiration date issued by the payment app 20. The one-time code includes information for identifying the user. The user logs in to the payment app 20 on the old terminal 10 and uses the payment app 20 to read the two-dimensional code CD displayed on the new terminal 10. The payment app 20 transmits the one-time code read from the two-dimensional code to the payment server 100. The payment server 100 authenticates the user if it confirms that the one-time code received from the payment app 20 of the old terminal 10 matches the issued one-time code. After authenticating the user, the payment server 100 registers the new terminal 10 in association with the user's account information and notifies the payment app 20 of the new terminal 10 that the authentication was successful, thereby displaying a top screen D44 on the payment app 20 of the new terminal 10.

[0048] If an authentication method using a phone number is selected on the authentication method selection screen D41 of FIG. 10, sign-in using an "aaa-ID" may be replaced by authentication using a phone number and password, as shown in the following FIG. 11. In this case, in the payment app 20 of the new terminal 10, the authentication method selection screen D41 transitions to a phone number input screen D45 and a password input screen D46, in that order. The payment app 20 acquires the user's phone number and password from the phone number input screen D46 and password input screen D46, and transmits them to the payment server 100. The payment server 100 attempts to authenticate the user using the phone number and password received from the payment app 20 of the new terminal 10, and if the authentication is successful, causes the payment app 20 of the new terminal 10 to display a two-dimensional code display screen D43.

[0049] <Second example of the model change procedure> FIG. 12 is a diagram showing an example of screen transitions of the payment app 20 according to a second embodiment of the model change procedure. The second embodiment is an embodiment in which sign-in is successful using the "aaa-ID" selected on the authentication method selection screen D41 of the first embodiment, but the account has not been registered for passwordless authentication using the "aaa-ID." In this case, the payment server 100 causes the payment app 20 to display a registration confirmation screen D47 that prompts registration for passwordless authentication using the "aaa-ID," and transitions to a sign-in screen D48 upon receiving an operation to execute registration. The sign-in screen D48 is similar to the sign-in screen D42. If sign-in using the sign-in screen D48 is successful, the payment server 100 causes the payment app 20 to display a top screen D44.

[0050] <Third example of model change procedure> FIG. 13 shows an example of screen transitions of the payment application 20 according to a third embodiment of the model change procedure. The third embodiment provides an authentication method using a phone call (hereinafter referred to as "phone call authentication") instead of a two-dimensional code, allowing the user to perform the model change procedure when the user does not have the old terminal 10 in hand in the first embodiment. The screen transitions up to the two-dimensional code display screen D43 are the same as those in FIG. 10 and are therefore not shown here. In this case, the user can operate the link LK on the two-dimensional code display screen D43 to cause the payment application 20 to display an alternative authentication method selection screen D51. The alternative authentication method selection screen D51 displays options for authentication methods that can be substituted for the two-dimensional code authentication method, and the options for authentication methods that can be substituted for the two-dimensional code authentication method include the phone call authentication method D511. When the user selects the phone call authentication method D511 on the alternative authentication method selection screen D51, the payment application 20 displays a call permission screen D52. Here, authentication by making a phone call is an example of a "second factor of authentication."

[0051] The outgoing call permission screen D52 is a screen that requests the user's permission to make an outgoing call using the payment app 20. When the user gives permission to the payment app 20 to make an outgoing call, the payment app 20 displays an outgoing call authentication execution screen D53. The outgoing call authentication execution screen D53 is a screen that accepts an instruction operation to make an outgoing call to the payment app 20. When an instruction operation to make an outgoing call is performed on the outgoing call authentication execution screen D53, the payment app 20 makes an outgoing call to the phone number of the payment server 100. Note that it is assumed here that the phone number of the new terminal 10 has not been changed from the phone number of the old terminal 10 by MNP (Mobile Number Portability). When the payment server 100 receives this outgoing call, it recognizes the phone number and user of the caller and determines whether the phone number matches the phone number registered for the user. If the phone number of the caller matches the registered phone number, the payment server 100 authenticates the user and displays a top screen D44 on the payment app 20 of the new terminal 10.

[0052] In this way, according to the first to third embodiments, when a user who has registered to use passwordless authentication goes through the procedure to change their model, authentication is performed using a Type 1 web service, allowing the user to go through the procedure to change their model without having to enter an ID or password.

[0053] [Call Authentication] As described above, outgoing call authentication is a method of having the requesting payment application 20 make an outgoing call and authenticating the user if the caller's phone number matches a registered phone number. Outgoing call authentication is similar to the second authentication method described above in that it uses a phone number, but differs from the second authentication method in that it requires the user to make an outgoing call.

[0054] Note that call origination authentication basically only needs to authenticate a user based on whether the call origination phone number is registered. However, simply verifying the call origination phone number may allow a third party to easily impersonate the user. Therefore, in the call origination authentication of this embodiment, in addition to verifying the call origination phone number, security is enhanced by verifying verification information based on the call origination. Here, the following two examples are described as examples of how this can be achieved. The first example is a method for verifying the legitimacy of the call origination by transmitting and receiving verification information between the payment server 100 and the payment application 20 in association with the call origination. The second example is a method for verifying the call origination using the timing of various operations performed by the user terminal device 10 in connection with the call origination for authentication as verification information.

[0055] [First Example of Call Authentication] FIG. 14 is a diagram showing an example of a processing flow according to a first embodiment of outgoing call authentication. The sequence chart in FIG. 14 is started, for example, in response to an instruction operation to execute an outgoing call on the outgoing call authentication execution screen D53 in FIG. 13. First, the payment application 20 requests a verification one-time code from the payment server 100 (S201). In the first embodiment, the verification one-time code is the verification information. Upon receiving the request in S201, the payment server 100 issues the verification one-time code and associates it with the user ID of the requesting user (S202). The payment server 100 notifies the payment application 20 of the verification one-time code issued in S202 (S203). The payment application 20 can transmit the notified verification one-time code to the payment server 100 as option information for the outgoing call, thereby transmitting the verification one-time code to the payment server 100. The option information is numerical information that can be automatically transmitted to the destination by specifying it when the call is made. Generally, the optional information can be specified by separating it with a comma after the destination telephone number. The numeric value specified as the optional information is automatically sent to the destination by a push signal of the corresponding numeric value.

[0056] Here, an application program (hereinafter referred to as "telephone app") that provides a voice call function using a public telephone line is pre-installed in the user terminal device 10, and the payment app 20 uses the telephone app to make a call to the payment server 100. In this case, the payment app 20 specifies the telephone number of the call destination and executes a call command, thereby activating the telephone app AP (S204), and the activated telephone app AP makes a call to the specified telephone number (S205). When the payment server 100 receives the call request of S205 (S206), a call is initiated between the payment server 100 and the telephone app AP. When the call with the payment server 100 is initiated, the telephone app AP transmits option information (verification one-time code) specified by the payment app 20 to the payment server 100 by a push signal (S207). When the payment server 100 receives the option information, it disconnects the call line (S208). In the user terminal device 10, the telephone application is terminated in response to the disconnection of the telephone line, and as a result of the termination of the telephone application, control of the application is returned from the telephone application AP to the payment application 20 (S209).

[0057] Next, the payment server 100 identifies the user who is the caller by referring to the user information 172 based on the caller phone number of the outgoing call received in S206 and recognizing the user ID linked to the caller phone number (S210). The payment server 100 checks whether the verification one-time code issued in S202 for the user identified in S210 matches with the optional information acquired in S207 (S211), and notifies the payment application 20 of the authentication result determined based on the match (S212). Specifically, the payment server 100 determines that the authentication is successful if the verification one-time code matches the optional information, and determines that the authentication is unsuccessful if they do not match.

[0058] Next, the payment application 20 determines whether the call origination authentication has been successful or not based on the authentication result notified in S212 (S213). If it is determined that the call origination authentication has failed, the payment application 20 notifies an authentication error (S214). On the other hand, if it is determined in S213 that the call origination authentication has been successful, the payment application 20 transitions to the top screen (S215).

[0059] [Second Example of Call Authentication] FIG. 15 is a diagram showing an example of a process flow according to a second embodiment of call origination authentication. In FIG. 15, the processes of S201 to S211 are the same as those in FIG. 14, and therefore, description thereof will be omitted where appropriate. In the second embodiment, the payment application 20 acquires and records the time of the outgoing call from the telephone application (or the telephone application log, etc.) in response to the execution of the outgoing call in S205 (S221), acquires and records the time of the incoming call from the telephone application (or the telephone application log, etc.) in response to the execution of the incoming call in S206 (S222), and stores the time of disconnection in response to the disconnection of the call line in S208 (S223). The disconnection time may be the time when control of the application is returned to the payment application 20 in S209, or may be acquired from the telephone application (or the telephone application log, etc.). The payment application 20 transmits time information indicating the outgoing call time, the incoming call time, and the disconnection time recorded in S221 to S223 to the payment server 100 (S224). In the second embodiment, the verification information is a one-time verification code and time information.

[0060] Meanwhile, in addition to confirming the consistency of the verification one-time code (S211), the payment server 100 also confirms the validity of the outgoing call from the viewpoint of timing based on the time information received in S224 (S225), and notifies the payment application 20 of the authentication result determined based on the consistency and validity (S226). For example, the payment server 100 determines that the timing of the outgoing call is appropriate if all the conditions related to the validity confirmation are determined to be true, and determines that the timing is inappropriate if one or more of the conditions are determined to be false. The first, second, and third conditions illustrated below are examples of the conditions related to the validity confirmation. The conditions related to the validity confirmation may include one or more of the conditions illustrated below. Note that the conditions illustrated below are merely examples, and the conditions related to the validity confirmation may include other conditions than those illustrated below as long as they are based on one or more of the outgoing call time, the incoming call time, and the disconnection time.

[0061] (Condition 1) The time elapsed from the issuance of the verification one-time code to the time of calling is less than a threshold. The threshold may be set based on the time required for a typical user to perform normal operations when making a call. (Second condition) The arrival time indicated by the time information matches the arrival time at the payment server 100. (Third condition) The disconnection time indicated by the time information matches the disconnection time in the payment server 100. The coincidence of the times in the second and third conditions may be determined in a manner that allows for some delay in the communication line.

[0062] The payment server 100 determines that the authentication is successful if the match of the verification one-time code is confirmed and the validity of the timing of the call outgoing is confirmed, and determines that the authentication is unsuccessful if either or both are not confirmed. Note that the payment server 100 may be configured to allow the login authentication of the user to be successful by managing the user as a monitoring target even if either one is not confirmed. In this case, the payment server 100 may also be configured to provide the electronic payment service to the user as a restricted user with certain functions restricted.

[0063] As a modification of the second embodiment, the processes for checking the consistency of the verification one-time codes (S201 to S203, S211) may be omitted, and the validity of the call source may be verified only by the validity of the timing of the outgoing call. In this case, the payment server 100 may be configured to authenticate the user when the validity of the timing of the outgoing call is confirmed in S225 for the user ID identified in S210.

[0064] According to the outgoing call authentication of the first or second embodiment, a user of an electronic payment service can be authenticated without requiring the user to enter a password. Note that, in outgoing call authentication, the payment server 100 needs to receive an outgoing call from the user terminal device 10, so basically, the calling user incurs a call charge. However, if a call charge is charged each time authentication is performed, the burden on the user is heavy. Therefore, it is desirable that outgoing call authentication be performed in a manner (for example, a so-called toll-free number) in which the call charge is not charged to the calling user when a call is received on the payment server 100 side.

[0065] According to the embodiment described above, it is possible to improve the convenience of user authentication in a system in which a user's account is managed in association with a telephone number.

[0066] <Modification> In the embodiment, a method for realizing call authentication has been described. However, it is also possible to use SMS (Short Message Service) authentication by replacing the call with SMS. In this case, in S204 of FIG. 14 (or FIG. 15), payment application 20 may send an SMS message with optional information in the body to a destination phone number. In this case, in S205 of FIG. 14 (or FIG. 15), payment server 100 may acquire the optional information from the body of the received SMS message. The use of passwordless authentication is not limited to a specific use. Passwordless authentication may be used as an authentication method in one-factor authentication or two-factor authentication. For example, passwordless authentication may be used for authentication when a user logs in to payment application 20 or when a user changes their password.

[0067] Furthermore, in the call origination authentication, the payment server 100 may be configured to notify the payment application 20 of the telephone number of the destination. In this case, the payment server 100 may store several candidates for the telephone number of the destination in advance, and may select one telephone number from the candidate telephone numbers in response to an authentication request and notify the payment server 100. The telephone number to be notified may be selected randomly or based on a predetermined rule.

[0068] Furthermore, depending on the terminal used as the user terminal device 10, there is a possibility that the telephone number of the called party and optional information may be displayed on the screen of the telephone application AP when making a call. Therefore, when making a call during call authentication, the user terminal device 10 may perform control so that the telephone number of the called party and optional information (verification one-time code) are not displayed on the screen. For example, the telephone application AP may be configured to allow external control to specify whether to display or hide the telephone number and optional information. In this case, the payment application 20 may specify whether to hide the telephone number and optional information during call authentication and have the telephone application AP make the call. Furthermore, during call authentication, the display of the telephone number and optional information by the telephone application AP may be masked by other applications or functions.

[0069] In the embodiment, the content displayed on the screen of the payment app 20 is controlled solely based on content information provided to the payment app 20 by the payment server 100. However, the control of the content displayed on the screen of the payment app 20 may be performed by the payment app 20 alone, or may be performed by the payment app 20 and the payment server 100 in cooperation with each other. The control method may differ for each screen. The screen displayed on the payment app 20 may be generated based on information provided from an external system other than the payment app 20 and the payment server 100. For example, the timing of screen transition to the sign-in screen D20 may be controlled by the payment app 20 or the payment server 100, while the sign-in screen D20 itself may be provided by a system of the first type web service. The payment server 100 may be configured such that the user authentication unit 150, instead of the content provider unit 120, provides content to the payment app 20 related to logging in to the electronic payment service. In the above embodiment, the electronic payment service is an example of a "predetermined service," but the "predetermined service" is not limited to the electronic payment service. In an embodiment, the electronic payment service may be modified to provide any service.

[0070] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]

[0071] 10 User terminal device 20. Payment App 50 First store terminal device 60 Store Code Image 70 Second store terminal device 72 Merchant Interface 100 Payment Server 110 Communications Department 120 Contents Provider 130 Payment processing unit 140 Information Management Department 150 User authentication section 170 Storage section 172 User information 174 Content Information 176 Affiliated Stores / Store Information D10 Authentication method selection screen D20 Sign-in screen D30 top screen

Claims

1. A service providing device that provides a predetermined service to a user in cooperation with a user application that runs on the user's terminal device, the predetermined service manages the user's account by linking it to the user's telephone number, an authentication processing unit that executes authentication processing for authenticating a user of the predetermined service; The authentication processing unit When an authentication request for the user is received from the user application, a one-time code is issued and notified to the user application; When a call is received after the one-time code is notified, the user of the user application is authenticated if the option information notified by the call matches the one-time code. Service providing device.

2. the user application makes a call to a telephone number of the service providing device using the one-time code notified from the service providing device as the option information; The service providing device according to claim 1 .

3. The authentication processing unit The issued one-time code is stored in association with the user, When the call is received, the target user is identified based on the caller's phone number, If the optional information is associated with the identified user, authenticating the user. The service providing device according to claim 1 .

4. The authentication processing unit If the caller's phone number is not associated with a user of the service, the user of the user application of the caller is registered as a new user of the service, and the caller's phone number is associated with the new user and registered. The service providing device according to claim 1 .

5. The authentication processing unit When a first authentication using a first-factor authentication method that is different from the authentication by outgoing phone call is successful for a user of the user application, and the identification information of the user application is not associated with the identification information of the user, the authentication by outgoing phone call is executed as a second authentication of a second factor. The service providing device according to claim 1 .

6. the user application sends an SMS (Short Message Service) message including the option information to the telephone number of the service providing device instead of making the call; When the authentication processing unit receives an SMS message after the one-time code is notified, it authenticates the user of the user application if option information included in the SMS message matches the one-time code. The service providing device according to claim 1 .

7. An authentication method implemented by a service providing device that provides a predetermined service to a user in cooperation with a user application running on the user's terminal device, comprising: the predetermined service manages the user's account by linking it to the user's telephone number, The service providing device executes an authentication process for authenticating a user of the predetermined service; In the authentication process, When an authentication request for the user is received from the user application, a one-time code is issued and notified to the user application; When a call is received after the one-time code is notified, the user of the user application is authenticated if the option information notified by the call matches the one-time code. Authentication method.

8. A program executed by a service providing device that provides a predetermined service to a user in cooperation with a user application that runs on the user's terminal device, the predetermined service manages the user's account by linking it to the user's telephone number, The service providing device, executes an authentication process for authenticating a user of the predetermined service, In the authentication process, When an authentication request for the user is received from the user application, a one-time code is issued and notified to the user application; When a call is received after the one-time code is notified, the user of the user application is authenticated if the option information notified by the call matches the one-time code. Program for.

Images