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 determines a type of the terminal device in a case where a request for login to the predetermined service is received from the user application, and causes the user application to display an authentication method by a web service associated with the terminal device as an option of an authentication method when logging in the predetermined service in a case where the type of the terminal device is determined to be a specific type.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, the specified service managing the user's account by linking it to the user's telephone number, and is equipped with an authentication processing unit that performs authentication processing to authenticate the user of the specified service, and when the authentication processing unit receives a login request for the specified service from the user application, it determines the type of the terminal device, and if it determines that the type of the terminal device is a specific type, it causes the user application to display authentication methods using a web service linked to the terminal device as options for authentication methods when logging in to the specified service. [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 showing an example of a screen transition according to a first modified example. [Figure 11] FIG. 10 is a diagram showing an example of a screen transition according to a second modified example. [Figure 12] FIG. 10 is a diagram showing an example of a screen transition according to a third modified example. 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 app 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 app 20 is an example of a "user app."

[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 a certain type of web service account, 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] Here, the user terminal device 10 that operates on an OS linked to the first-class web service is an example of a "specific type of terminal device." The first-class web service is also an example of a "web service linked to a terminal device." The OS linked to the first-class web service is also an example of a "specific operating system."

[0040] 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.

[0041] 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).

[0042] 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.

[0043] 9 is based on the assumption that the first-class web service is registered in advance with the electronic payment service as a user authentication method, but depending on the registration status of the user information, it is also possible that the first-class web service is not registered with the electronic payment service. Therefore, in order to deal with such a situation, the payment server 100 may be configured to realize screen transitions in the following modified manner.

[0044] <First Modification> FIG. 10 shows an example of screen transitions according to a first modification. The first modification assumes a case where the first-class web service selected on the authentication method selection screen D31 is not registered as a user's authentication method, but a password is set for the telephone number. In this case, even if the first-class web service is not registered as a user's authentication method, if the OS of the user terminal device 10 is linked to the first-class web service, the first authentication method is presented as an option for authentication methods on the authentication method selection screen D31. In this case, even if the first authentication method is selected on the authentication method selection screen D31 and authentication using the first authentication method is successful, if the first-class web service is not registered as a user's authentication method for the electronic payment service, login to the electronic payment service is generally not permitted.

[0045] However, in the first modified example, since a password is set for the phone number, payment server 100 may be configured to present payment app 20 with an alternative authentication method using a phone number and password. For example, payment server 100 transitions from sign-in screen D32 to phone number input screen D33 and password input screen D34 in this order to prompt the user to input a phone number and password, and if the input phone number and password match the registered details, causes payment app 20 to display top screen D35. This allows the user to continue the authentication procedure using a phone number and password without having to reselect the authentication method, even if the user mistakenly selects the first authentication method despite not having registered a first-type web service.

[0046] <Second Modification> FIG. 11 shows an example of a screen transition according to the second modified example. The second modified example assumes a case where the first-class web service (hereinafter referred to as the "first web service") selected on the authentication method selection screen D41 is not registered as the user's authentication method, but a different first-class web service (hereinafter referred to as the "second web service") is registered as the user's authentication method. This situation may occur, for example, when the user changes the user terminal device 10 to one with a different OS. For example, suppose that the user registered Google ID as the first authentication method when using an Android (registered trademark) device before the change, and then changed to an iPhone (registered trademark) device. In this case, the user terminal device 10 being used is an iPhone (registered trademark), but Google ID is registered as the first authentication method.

[0047] In this case, as in the first modification, even if the first authentication method is selected on the authentication method selection screen D41 and authentication using the first authentication method is successful, if the first web service is not registered as the user's authentication method, login to the electronic payment service is generally not permitted. Therefore, in this case, the user must select an authentication method other than the first authentication method. Therefore, in such a situation, if the second web service is registered as an authentication method, the payment server 100 may be configured to provide a means for registering the first web service as the user's authentication method against the background of the second web service authentication, and to realize passwordless authentication using the first web service that has been registered by that means.

[0048] For example, when the second authentication method is selected on the authentication method selection screen D41, the payment server 100 displays a phone number input screen D42 on the payment app 20 and prompts the user to input a phone number. Based on the input phone number, the payment server 100 recognizes that a second web service is registered as the authentication method for the user. For authentication using the second web service, the payment server 100 displays an account ID input screen D43 and a password input screen D44 and prompts the user to input an account ID and password for the second web service. When authentication using the input account ID and password is successful, the payment server 100 displays an authentication method registration screen D45 on the payment app 20 and accepts an operation to register the first web service as the authentication method for the user. When registration of the first web service is complete, the payment server 100 displays a sign-in screen D46 for the first web service on the payment app 20. When the user operates the sign-in screen D46 and succeeds in authentication by the first web service, the payment server 100 causes the payment application 20 to display the top screen D47. As a result, even if the first web service corresponding to the OS type of the user terminal device 10 being used is not registered, if the second web service is registered, the user can select the second authentication method to register the first web service while authentication by the second web service is performed as a background, and perform passwordless authentication with the registered first web service.

[0049] <Third Modification> FIG. 12 illustrates an example of a screen transition according to the third modification. The third modification assumes a case in which the first web service selected on the authentication method selection screen D51 is not registered as the user's authentication method, and a password is not set for the telephone number, but a second web service is registered as the user's authentication method. As with the first and second modifications, even if the first authentication method is selected on the authentication method selection screen D51 and authentication using the first authentication method is successful, if the first web service is not registered as the user's authentication method, login to the electronic payment service is generally not permitted. Therefore, in this case, the user must select an authentication method other than the first authentication method. Furthermore, in the third modification, a password is not set for the telephone number, so authentication using a combination of a telephone number and a password is also not possible. Therefore, if a second web service is registered under such circumstances, the payment server 100 may be configured to permit login to the electronic payment service based on authentication using the second web service.

[0050] For example, when authenticating on the sign-in screen D52 of a first web service, if the first web service is not registered as an authentication method for the user, the payment server 100 displays a phone number input screen D53 on the payment app 20 and prompts the user to input a phone number. Furthermore, if the payment server 100 recognizes that no password is set for the entered phone number and that a second web service is registered as an authentication method, the payment server 100 displays an account ID input screen D54 and a password input screen D55 for the second web service on the payment app 20. Then, if authentication by the second web service is successful, the payment server 100 displays a top screen D56 on the payment app 20. At this time, the payment server 100 associates the first web service (unregistered) that was successfully authenticated on the sign-in screen D52 with the second web service (registered) that was successfully authenticated on the account ID input screen D54 and the password input screen D55.

[0051] As a result, even if a user is not registered with the first web service and has not set a password for their phone number, if the user is registered with the second web service, they can log in to the electronic payment service using the authentication function of the second web service without having to reselect the authentication method, even if they mistakenly select the first authentication method. Furthermore, if authentication by the second web service is successful, the first web service is linked to the second web service, so that the user can use passwordless authentication by the first web service from the next time they log in.

[0052] 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.

[0053] <Other variations> 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 payment service 100 may be modified to provide any service.

[0054] 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]

[0055] 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 D11 First authentication method selection section D12 Second authentication method selection section D13 Third authentication method selection section D20 Sign-in screen D21 Display section D22 Control unit 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 receiving a login request for the predetermined service from the user application, determines the type of the terminal device; When it is determined that the type of the terminal device is a specific type, the authentication method by the web service associated with the terminal device is displayed on the user application as an option of the authentication method when logging in to the predetermined service. Service providing device.

2. the specific type of terminal device operates on a specific operating system linked to a web service that provides a social login function; The user application is an application program configured to run on the specific operating system. The service providing device according to claim 1 .

3. the authentication processing unit recognizes through communication with the user application that the operating system of the terminal device is the specific operating system, and causes the user application to display a web service corresponding to the specific operating system as one of the authentication method options. The service providing device according to claim 2 .

4. the terminal device is used in a state where the user is logged in to the web service using an account used by the operating system, The web service does not require the user to enter authentication information when authenticating an account used by the operating system. The service providing device according to claim 2 .

5. the authentication processing unit, when the authentication by the web service is successful, determines whether or not an authentication method by the web service is registered for the user; If the web service authentication method is registered for the user, authenticate the user's login to the predetermined service. The service providing device according to claim 1 .

6. If the authentication method by the web service is not registered for the user, the authentication processing unit registers the web service for which the authentication was successful as an authentication method for the user in the specified service, and then authenticates the user's login to the specified service. The service providing device according to claim 5 .

7. the user application provides the user with a user interface for an electronic payment service; the service providing device further includes a payment processing unit for providing the electronic payment service as the predetermined service; The service providing device according to claim 1 .

8. 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, An authentication method for performing an authentication process for authenticating a user of the predetermined service, the predetermined service manages the user's account by linking it to the user's telephone number, the authentication process determines the type of the terminal device when a login request for the predetermined service is received from the user application; When it is determined that the type of the terminal device is a specific type, the authentication method by a web service associated with the terminal device is displayed on the user application as an option of the authentication method when logging in to the predetermined service. Authentication method.

9. 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, A program for executing an authentication process for authenticating a user of the predetermined service, the predetermined service manages the user's account by linking it to the user's telephone number, the authentication process determines the type of the terminal device when a login request for the predetermined service is received from the user application; When it is determined that the type of the terminal device is a specific type, the authentication method by a web service associated with the terminal device is displayed on the user application as an option of the authentication method when logging in to the predetermined service. program.

Images