Authentication system, authentication method and program

Abstract

To improve user convenience while maintaining security in settlement.SOLUTION: A type determination part (102) of an authentication system (1) determines a type of at least one of a setting target card and a related card related to the setting target card when settings are made for the setting target card for settlement in a prescribed service. An authentication execution part (103) executes the processing for authentication according to the type of at least one of the cards. A setting reflection part (104) reflects the setting when authentication is executed.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to an authentication system, an authentication method, and a program. [Background technology]

[0002] Conventionally, cards (e.g., credit cards or debit cards) that can be used for payments in predetermined services (e.g., payment services or online shopping services) have been known. With such services, fraudulent activities such as impersonation or phishing by malicious third parties have become a problem. For this reason, there is a demand for improving security in payments. For example, Patent Document 1 describes a technology that improves security by requiring users to input multiple pieces of authentication information, such as a password and a security code. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2008-015924 Summary of the Invention [Problem to be solved by the invention]

[0004] However, with the technology of Patent Document 1, users are required to input multiple pieces of authentication information, which is cumbersome for users. Therefore, although the technology of Patent Document 1 can improve security, it reduces user convenience. Reducing the number of pieces of authentication information that users must input can reduce the cumbersomeness felt by users, but security will also be reduced. Therefore, there is a demand for improving user convenience while maintaining security.

[0005] One of the objectives of the present disclosure is to improve user convenience while maintaining security in payments. [Means for solving the problem]

[0006] The authentication system according to the present disclosure includes a type determination unit that, when settings are made for a card to be set up for payment in a specified service, determines the type of at least one of the card to be set up and an associated card related to the card to be set up; an authentication execution unit that executes processing for authentication according to the type of the at least one card; and a setting reflection unit that reflects the settings when the authentication is executed. [Effects of the Invention]

[0007] According to the present disclosure, it is possible to improve convenience for users while maintaining security in payments. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an example of a hardware configuration of an authentication system. [Figure 2] FIG. 10 is a diagram illustrating an example of first authentication. [Figure 3] FIG. 10 is a diagram illustrating an example of second authentication. [Figure 4] FIG. 2 is a diagram illustrating an example of functions realized in the authentication system. [Figure 5] FIG. 2 is a diagram illustrating an example of a user database. [Figure 6] FIG. 2 is a diagram illustrating an example of an electronic money database. [Figure 7] FIG. 10 is a diagram illustrating an example of processing executed in the authentication system. [Figure 8] FIG. 10 is a diagram illustrating an example of processing executed in the authentication system. [Figure 9] FIG. 10 is a diagram illustrating an example of a function in a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0009] [1. Hardware configuration of authentication system] An example of an embodiment of an authentication system, an authentication method, and a program according to the present disclosure will be described. Fig. 1 is a diagram showing an example of the hardware configuration of an authentication system. For example, the authentication system 1 includes a payment server 10, an electronic money server 20, and a user terminal 30. Each of the payment server 10, the electronic money server 20, and the user terminal 30 is connected to a network N such as the Internet or a LAN.

[0010] The payment server 10 is a server computer of a service provider that provides payment services to users. The payment service is a service that handles electronic payments (cashless payments) by users on their behalf. For example, the payment server 10 includes a control unit 11, a memory unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The memory unit 12 includes at least one of volatile memory such as RAM and non-volatile memory such as flash memory. The communication unit 13 includes at least one communication interface for wired communication and wireless communication.

[0011] In this embodiment, an example is given in which the payment service corresponds to the predetermined service. Therefore, the phrase "payment service" can be read as "predetermined service." The predetermined service may be any service in which a payment is made based on the setting target card, as described below. The predetermined service is not limited to a payment service. For example, the predetermined service may be an online shopping service, an electronic ticket service, a travel reservation service, an e-book service, a video distribution service, a music distribution service, a financial service, a reservation service for various stores or facilities such as a hair salon or a restaurant, or other services.

[0012] The electronic money server 20 is a server computer of an electronic money administrator that manages electronic money. In this embodiment, an example is given in which the electronic money administrator is a party different from the service provider, but the electronic money administrator may be the same as the service provider. For example, the electronic money server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

[0013] The user terminal 30 is a user's computer. For example, the user terminal 30 is a smartphone, a tablet, a personal computer, or a wearable terminal. Although only one user terminal 30 is shown in FIG. 1, there may be a user terminal 30 for each of multiple users. For example, the user terminal 30 includes a control unit 31, a storage unit 32, a communication unit 33, an operation unit 34, a display unit 35, and an image capture unit 36.

[0014] For example, the hardware configurations of the control unit 31, the storage unit 32, and the communication unit 33 may be similar to those of the control unit 11, the storage unit 12, and the communication unit 13, respectively. In this embodiment, the communication unit 33 is capable of NFC (Near Field Communication). The user terminal 30 may include an IC chip capable of NFC in addition to the communication unit 33. The operation unit 34 is an input device such as a touch panel or buttons. The display unit 35 is a display such as a liquid crystal or organic EL display. The photographing unit 36 ​​includes at least one camera.

[0015] The programs stored in the storage units 12, 22, and 32 may be supplied to the payment server 10, the electronic money server 20, or the user terminal 30 via the network N. Also, the programs stored in a computer-readable information storage medium may be supplied to the payment server 10, the electronic money server 20, or the user terminal 30 via a reading unit (for example, an optical disk drive or a memory card slot) that reads the information storage medium, or an input / output unit (for example, a USB port) that inputs and outputs data to and from an external device.

[0016] Furthermore, the authentication system 1 only needs to include at least one computer. The hardware configuration of the authentication system 1 is not limited to the example of FIG. 1. For example, the authentication system 1 may include only the payment server 10. In this case, the electronic money server 20 and the user terminal 30 exist outside the authentication system 1. For example, the authentication system 1 may include only the payment server 10 and the electronic money server 20. In this case, the user terminal 30 exists outside the authentication system 1. The authentication system 1 may include a computer not shown in FIG. 1.

[0017] [2. Overview of the authentication system] In this embodiment, a user operates the user terminal 30 to use a payment service. The payment means available to the user for the payment service may be any of various known payment means. For example, the payment means available to the user for the payment service may be a credit card, electronic money, points, a bank account, an account at a financial institution other than a bank, an account at a non-financial institution, a debit card, cryptocurrency, a wallet, or other means.

[0018] In this embodiment, an example is given in which a user uses a payment service from a payment app, which is an application (e.g., a so-called smartphone app) installed on the user terminal 30. The medium through which the user uses the payment service is not limited to the payment app. For example, the medium through which the user uses the payment service may be a browser on the user terminal 30, an IC chip on the user terminal 30, an IC card, a magnetic card, a part of the user's body, or other medium.

[0019] For example, when a payment app is launched on user terminal 30, user terminal 30 displays the payment app screen on display unit 35. The payment app screen displays a code (e.g., a barcode or two-dimensional code) for making a payment using the payment method set by the user as the payment source. This code contains a code ID that can temporarily identify the user. When this code is read by a payment terminal at a member store of the payment service, payment is executed based on the payment method set as the payment source.

[0020] The payment flow itself in the payment service may be a known flow. For example, instead of the type of payment in which the payment terminal of the affiliated store reads the code on the user terminal 30, the user terminal 30 may read the code of the affiliated store. For example, the payment may be completed only by operating the user terminal 30 without using a particular code. Payment in the payment service may be made not only in a physical store but also online.

[0021] In this embodiment, an example is taken of a case where a user uses a credit card with a payment app. The credit card may be registered with the payment service in advance, or may be registered with the payment service by the user inputting information such as a credit card number from the payment app. A credit card may have only the function of a credit card, but may also have functions as a payment method other than a credit card or functions other than payment. Hereinafter, such functions are referred to as additional functions.

[0022] In this embodiment, an example is given in which the function of IC card-type electronic money corresponds to the additional function. The additional function may be various known functions. The additional function is not limited to the example of this embodiment. For example, the additional function of a credit card may be an additional function of a points card, a membership card, a commuter pass for transportation, an identification card, an admission pass to a facility, or other functions. A credit card may have multiple additional functions.

[0023] Hereinafter, information used for the additional function will be referred to as additional information. In this embodiment, the electronic money number capable of identifying IC card-type electronic money corresponds to the additional information. The electronic money number is written in the IC chip of a credit card having the additional function of IC card-type electronic money. If the credit card has memory other than the IC chip, the electronic money number may be written in that memory. The electronic money number may be formed on the face of the credit card. Formed here means not only printing but also embossing. The electronic money number may be formed on the face of the credit card as a code such as a barcode or two-dimensional code.

[0024] In this embodiment, a user cannot use electronic money as an additional function of a credit card in payments made through a payment app. That is, to use electronic money as an additional function of a credit card, a user must have a physical credit card (a so-called "sticker card"), rather than a user terminal 30, read by a payment terminal at an affiliated store the identification information of the electronic money (e.g., electronic money number). When issuing a credit card, the user may be able to select whether or not to include the additional function. Note that the identification information of the electronic money attached to a physical credit card with electronic money functionality may be registered in the payment app, and the electronic money may be used through the payment app.

[0025] Hereinafter, a credit card to be set as a payment source in a payment app will be referred to as a "set target card." A set target card may have cards related to the set target card. Hereinafter, such cards will be referred to as "related cards." For example, if a user holds multiple credit cards from the same card company, credit cards other than the set target card among the multiple credit cards will be referred to as "related cards." Credit cards issued for the user's family members will also be referred to as "related cards." In this embodiment, not only the set target card but also the related cards can have additional functions.

[0026] For example, the related card may be a card that is directly or indirectly associated with the same user ID as the setting target card (for example, when a child card described below is further associated with a parent user ID via the child's user ID). The related card may be any card that is related to the setting target card. The related card is not limited to a credit card. For example, the related card may be an electronic money card without a credit function, a point card, a prepaid card, a membership card, an identification card, an entrance / exit card, a cash card, or any other card. The related card may be a card that is directly or indirectly associated with the setting target card.

[0027] For example, a user must successfully complete a predetermined authentication to set a target card as the payment source in a payment app. In this embodiment, the authentication method differs depending on whether or not the target card and / or related cards have an electronic money number. For example, if the electronic money number is not present, authentication such as 3D Secure authentication or security code (CVV: Card Verification Value) authentication is performed. Hereinafter, authentication when the electronic money number is not present is referred to as first authentication. The first authentication may be a combination of multiple authentications such as 3D Secure authentication and security code authentication.

[0028] On the other hand, if the electronic money number of at least one of the target card and related cards is available, authentication such as scan authentication, which requires reading at least one of the target card and related cards, is performed. Hereinafter, authentication when an electronic money number is available is referred to as second authentication. In this embodiment, an example is given in which 3D Secure authentication corresponds to the first authentication and scan authentication corresponds to the second authentication. Each of the first authentication and the second authentication may be any authentication. Each of the first authentication and the second authentication is not limited to the example in this embodiment.

[0029] FIG. 2 is a diagram showing an example of the first authentication. For example, when a user performs an operation to set the payment source in a payment app, the user terminal 30 displays a payment source setting screen SC1 on the display unit 35, which allows the user to specify the payment method of the payment source. In the example of FIG. 2, the user specifies the payment method to be the payment source from among the credit card "AAA Card," the bank account "BBB Bank," and the online electronic money "DDD Cash." Although omitted in FIG. 2, the user can also specify the "EEE Card," which is set as a charge method for the online electronic money "DDD Cash," as the payment source.

[0030] For example, the user may designate a new credit card as the payment source by inputting information such as the credit card number of the new credit card on the payment source setting screen SC1. In other words, the card to be set is not limited to a credit card registered in advance with the payment service, but may be a credit card for which the user inputs information such as the credit card number on the spot. When the user designates a credit card without additional functions as the payment source and selects button B10, the payment server 10, in cooperation with the electronic money server 20, determines whether or not the electronic money number of each of the card to be set and related cards exists. If no related cards exist, the payment server 10 determines whether or not the electronic money number of only the card to be set exists.

[0031] For example, if the electronic money numbers of the target card and the related cards do not exist, the user terminal 30, under the control of the payment server 10, causes the display unit 35 to display the authentication screen SC2 at the top right of Fig. 2. Since the electronic money numbers of the target card and the related cards do not exist, the payment server 10 cannot execute the process for the second authentication. Therefore, a notification is displayed, as shown in the authentication screen SC2 at the top right of Fig. 2, that the first authentication will be executed.

[0032] For example, when the user selects button B20, the user terminal 30 accesses the card company screen SC3, which shows the website of the card company that issued the card to be set up, as shown in the lower left of Figure 2. When the user enters a password for the first authentication in input form F30 and selects button B31, the first authentication is executed. The flow of the first authentication may be the same as a known authentication flow. If the first authentication is successful, a message to that effect is displayed on the card company screen SC3, as shown in the lower right of Figure 2. When the user selects button B32, the screen returns to the payment app screen. The user will be able to make payments from the payment app using the card to be set up as the payment source.

[0033] FIG. 3 is a diagram showing an example of the second authentication. The example of FIG. 3 differs from the example of FIG. 2 in that the electronic money number of at least one of the target card and the related card is present. For example, when a user selects button B10, as shown in the upper right corner of FIG. 3, the user terminal 30, under the control of the payment server 10, displays an authentication screen SC2 on the display unit 35 indicating that the second authentication is supported. In the example of FIG. 3, "FFF Money" is electronic money that is an additional function of "AAA Card." "DDD Cash" is online electronic money that can be used in a payment app.

[0034] For example, when the user selects button B21, the NFC function of the user terminal 30 is activated. As shown in the lower left of FIG. 3, the user terminal 30 displays modal M23 on the authentication screen SC2, prompting the user to read the target card using the NFC function. The user terminal 30 reads the electronic money number written on the target card. Note that, as will be described in detail later, under certain conditions, the user can also successfully complete the second authentication by reading a related card that has the electronic money number.

[0035] For example, the user terminal 30 transmits the electronic money number read by the NFC function to the payment server 10. When the payment server 10 receives the electronic money number from the user terminal 30, it performs the second authentication. If the second authentication is successful, a message to that effect is displayed in modal M23, as shown in the lower right of Fig. 3. The user can then make payments from the payment app using the target card as the payment source.

[0036] Note that even if at least one of the target card and related cards has an electronic money number, the user can perform the first authentication by selecting button B22 on the authentication screen SC2 in the upper right of Fig. 3. The flow after the user selects button B22 is the same as the flow from the authentication screen SC2 in the upper right of Fig. 2 onwards. If at least one of the target card and related cards has an electronic money number, the user can select either the first authentication or the second authentication.

[0037] Furthermore, the electronic money function as an additional function of a credit card may only be supported by credit cards of a specific card company. In this case, if the card to be set up is a credit card of another card company, the first authentication may be triggered without executing the process of determining whether or not an electronic money number is present. Furthermore, the authentication flow in Figures 2 and 3 may be executed immediately after the user installs the payment app on the user terminal 30. In other words, the authentication in Figures 2 and 3 may be executed when the user performs initial setup of the payment app.

[0038] As described above, the authentication system 1 of this embodiment determines whether or not an electronic money number exists on at least one of the target card and the related card. If it is determined that electronic money exists, the authentication system 1 performs the first authentication. If it is determined that electronic money does not exist, the authentication system 1 performs the second authentication. This enables the authentication system 1 to improve user convenience while maintaining security in payments. Details of the authentication system 1 will be explained below.

[0039] [3. Functions realized by the authentication system] 4 is a diagram showing an example of functions realized by the authentication system 1. For example, the payment server 10 includes a data storage unit 100, a user identification information acquisition unit 101, a type determination unit 102, an authentication execution unit 103, a setting reflection unit 104, and a payment execution unit 105. The data storage unit 100 is realized by the memory unit 12. The user identification information acquisition unit 101, the type determination unit 102, the authentication execution unit 103, the setting reflection unit 104, and the payment execution unit 105 are realized by the control unit 11.

[0040] For example, the electronic money server 20 includes a data storage unit 200, a receiving unit 201, and a transmitting unit 202. The data storage unit 200 is realized by the storage unit 22. The receiving unit 201 and the transmitting unit 202 are each realized by the control unit 21. For example, the user terminal 30 includes a data storage unit 300, a reading unit 301, and a transmitting unit 302. The data storage unit 300 is realized by the storage unit 32. The reading unit 301 and the transmitting unit 302 are realized by the control unit 31.

[0041] [3-1. Data stored by the payment server] The data storage unit 100 stores data necessary for the payment service. For example, the data storage unit 100 stores a user database DB1. Note that the "Notes" in the user database DB1 in FIG. 5 are descriptions for the purpose of explaining this embodiment. The user database DB1 does not include a "Notes" field.

[0042] FIG. 5 is a diagram showing an example of user database DB1. User database DB1 is a database that stores various information related to each of multiple users. For example, user database DB1 stores user IDs, login passwords, user names, payment source information, payment method information, and authentication result information. User database DB1 may store any information related to users. The information stored in user database DB1 is not limited to the example of FIG. 5. For example, information on points and online electronic money that can be used from a payment app, and terminal identification information that can identify user terminal 30 may be stored in user database DB1.

[0043] The user ID is an example of user identification information that can identify a user. Therefore, the term "user ID" can be read as "user identification information." User identification information may be any information that can identify a user in some way. User identification information is not limited to a user ID. For example, user identification information may be an email address, a phone number, a code ID, or a digital ID. In this embodiment, the user ID and login password are used by the user to log in to the payment service.

[0044] The user ID may be common to multiple services, including the payment service. For example, the user ID may be common to the payment service provider, the electronic money administrator, and the card company that issued the credit card. If the user ID is different for each service, it is assumed that the user IDs are linked. For example, if the user IDs are linked, the authentication system 1 does not need to disclose confidential credit card information when exchanging data, thereby ensuring security.

[0045] For example, in addition to the user identification information for logging in, there may be other user identification information associated with the user identification information. The other user identification information may be common to multiple services including a payment service. Furthermore, when multiple services including a payment service are linked to each other, the user identification information may be different for each service. In this case, it is assumed that the relationship between the user identification information of one service and the user identification information of another service is defined in advance in some database or the like.

[0046] For example, the terminal identification information of the user terminal 30 may correspond to the user identification information. The terminal identification information may be the serial ID (individual identification information) of the user terminal 30, a SIM number, an ID issued by the payment server 10, or other information. If the same user uses multiple user terminals 30, when the terminal identification information corresponds to the user identification information, the user identification information will be different when the user logs in to the payment service from one user terminal 30 using their own user ID and when the user logs in to the payment service from another user terminal 30 using the same user ID. Furthermore, the user identification information is not limited to one, and multiple user identification information may be combined. For example, the user ID and the terminal identification information may be combined. When the same user uses multiple user terminals 30, the user can log in using only the user ID if the user terminal 30 is one that they regularly use. However, when the user logs in to the payment service using the same user ID from another user terminal 30, authentication using the terminal identification information may be required.

[0047] If the terminal identification information corresponds to the user identification information, in order for a user to set the target card as the payment source, even if the user ID is the same, authentication for setting the target card is required for each user terminal 30. By doing so, even if a malicious third party illegally obtains the user ID and login password, the legitimate user's target card cannot be set as the payment source unless authentication is successful at the third party's user terminal 30, thereby further enhancing security.

[0048] The payment source information is information that can identify the payment method set as the payment source from among multiple payment methods that the user can use in the payment service. The payment source payment method is the payment method used for payment. If the first authentication or second authentication is successful, the payment source information is set to indicate the card to be set. If the user changes the payment source payment method, the payment server 10 sets the payment source information so that the payment method indicated in the payment source information is changed.

[0049] Payment method information is information about payment methods that can be used by a user in a payment service. The payment method can also be referred to as a payment method of the user registered in the payment service or payment app. The payment method can also be referred to as a payment method that is a candidate for payment source. In this embodiment, an example is given in which a user can use multiple payment methods, but a user may also be able to use only one payment method.

[0050] In this embodiment, an example is taken of a case where a user uses a credit card, and therefore the payment method information indicates a credit card registered with the payment service. For example, the payment method information indicates the card company that issued the credit card, at least a portion of the credit card number (the last four digits in the example of FIG. 5), the expiration date, the cardholder's name, or a combination thereof. If a user has registered multiple credit cards with a payment service or payment app, the payment method information indicates information such as the credit card number of each of the multiple credit cards. If cards other than credit cards are available with the payment service, the payment method information may indicate the other cards. Examples of other cards are as described above. The payment method information may indicate payment methods other than cards. The payment method information may be information related to various known payment methods. For example, payment methods available to a user with the payment service may be credit cards, electronic money, points, bank accounts, accounts at financial institutions other than banks, accounts at other financial institutions, debit cards, crypto assets, wallets, or other methods.

[0051] The authentication result information indicates whether a credit card has been authenticated. In this embodiment, a user can set as the payment source a payment method for which the authentication result information indicates that the credit card has been authenticated, among the payment methods for which the payment method information is associated with the user's user ID. To set as the payment source a payment method for which the authentication result information indicates that the credit card has not been authenticated, the user must be authenticated. Note that payment methods such as points or bank accounts do not require authentication.

[0052] In the example of Figure 5, user "Tenko Taro" has registered two cards with electronic money numbers, "AAA Card" and "EEE Card," with the payment service. User "Tenko Taro" is the parent of user "Tenko Kosuke." Child user "Tenko Kosuke" has registered with the payment service an "AAA Card" in the child user's name, with parent user "Tenko Taro's" bank account set as the debit destination. Hereinafter, a credit card set as the debit destination for a parent's bank account will be referred to as a child card. A child card may also be referred to as a family card. A child card may be held not only by a child, but also by someone else, such as a spouse.

[0053] Hereinafter, a card that has the same bank account as the child card's debit destination will be referred to as the parent card. In the example of Figure 5, the credit card owned by user "Tenko Taro" is the parent card. The child card "AAA Card" of child user "Tenko Kosuke" has an electronic money number. Parent user "Tenko Taro" also owns an IC card-type electronic money that does not have a credit card function.

[0054] For example, user "Plan Hero" has registered "HHH Card," which has an electronic money number, with the payment service. The only credit card held by user "Plan Hero" is the "HHH Card." In other words, user "Plan Hero" holds only the card to be set. User "Plan Hero" does not hold any related cards, regardless of whether they have an electronic money number or not.

[0055] For example, user "Design Hanako" has registered "III Card" with an electronic money number and "JJJ Card" without an electronic money number with the payment service. User "Trademark Ayaka" has registered "KKK Card" without an electronic money number with the payment service. User "Trademark Ayaka" has "LLL Card" with an electronic money number, but has not registered "LLL Card" with the payment service.

[0056] In this embodiment, to make it easier to distinguish between cards owned by each user, different alphabets are used for the card names, such as "AAA card" to "LLL card." However, the credit card with electronic money function may be a credit card of a specific card company. In this case, the process by the type determination unit 102, which will be described later, to determine whether or not an electronic money number exists may be executed only if the target card is a credit card of the specific card company. If the target card is a credit card of another company, the second authentication may not be activated, and the first authentication may be activated.

[0057] Furthermore, the data storage unit 100 can store any data. The data stored in the data storage unit 100 is not limited to the user database DB1. For example, the data storage unit 100 may store data necessary for displaying the screens of FIGS. 2 and 3. The data storage unit 100 may store a database equivalent to the electronic money database DB2 described below. In this case, the contents of the equivalent database are assumed to be consistent with the electronic money database DB2 described below.

[0058] [3-2. Data stored by the electronic money server] The data storage unit 200 stores data related to electronic money. For example, the data storage unit 200 stores an electronic money database DB2. Note that the "Notes" in the electronic money database DB2 in FIG. 6 are descriptions for the purpose of explaining this embodiment. The electronic money database DB2 does not include a "Notes" field. The data storage unit 200 may store data other than the electronic money database DB2.

[0059] FIG. 6 is a diagram showing an example of the electronic money database DB2. The electronic money database DB2 is a database in which various information related to electronic money is stored. For example, the electronic money database DB2 stores a user ID, an electronic money number, and validity information. The electronic money database DB2 only needs to store any information related to electronic money, and the information stored in the electronic money database DB2 is not limited to the example shown in FIG. 6. For example, if the electronic money has a credit card function, credit card information may be stored in the electronic money database DB2. As credit card information, information that can identify whether the card is a parent card or a child card may be stored in the electronic money database DB2.

[0060] An electronic money number is an example of electronic money identification information that can identify electronic money. Therefore, the phrase "electronic money number" can be read as "electronic money identification information." Electronic money identification information is not limited to an electronic money number. For example, electronic money identification information may be information other than a number (e.g., letters or symbols). Since electronic money identification information is an example of additional information, the phrase "electronic money identification information" can also be read as "additional information."

[0061] The validity information is information indicating whether the electronic money is valid. For example, the validity information indicates either a value indicating that the electronic money is valid or a value indicating that the electronic money is invalid. The validity information is updated by the electronic money server 20. For example, if fraudulent use of the electronic money occurs, the electronic money server 20 updates the validity information to indicate that the electronic money is invalid. If the electronic money has not been used for a certain period of time, the electronic money server 20 updates the validity information to indicate that the electronic money is invalid. The situations in which the validity information is used will be described in Variation 1 below.

[0062] In the example of Figure 6, the user ID "u00001" of user "Takken Taro" is associated with the electronic money number of the "AAA card," the electronic money number of the "EEE card," the electronic money number of the "AAA card" of child user "Takken Kosuke," and the electronic money number of the electronic money of an IC card without a credit card function. In this embodiment, the payment service does not support electronic money from IC cards, so IC cards without a credit card function are not registered in the payment service. The association of the user ID and the electronic money number may be performed by user "Takken Taro" himself, or by a service provider, an electronic money administrator, a card company, or other party. This also applies to other users.

[0063] For example, the user ID "u00002" of the user "Practical Idea Eiyuu" is associated with the electronic money number of the "HHH Card." The user ID "u00003" of the user "Design Hanako" is associated with the electronic money number of the "III Card." The user ID "u00004" of the user "Trademark Ayaka" is associated with the electronic money number of the "LLL Card." As mentioned above, the "LLL Card" is not registered with the payment service.

[0064] [3-3. Data stored on the user device] The data storage unit 300 stores data necessary for the user to use the payment service. For example, the data storage unit 300 stores a payment app or a browser for displaying each screen such as the payment source setting screen SC1.

[0065] [3-4. Other functions realized by the payment server] For example, as examples of other functions realized by the payment server 10, a user identification information acquisition unit 101, a type determination unit 102, an authentication execution unit 103, a setting reflection unit 104, and a payment execution unit 105 will be described.

[0066] [User identification information acquisition section] The user identification information acquisition unit 101 acquires user identification information that can identify the logged-in user based on a login from the user terminal 30. The method for acquiring the user ID of the logged-in user can be any of various known methods. In this embodiment, the user ID is described as an example of user identification information that can identify the logged-in user, but the user identification information acquired by the user identification information acquisition unit 101 may be other information as described above. In this embodiment, the user ID acquired as user identification information by the user identification information acquisition unit 101 can be replaced with any other user identification information.

[0067] For example, when a user logs in to a payment service by inputting a user ID and a login password from the user terminal 30, the user identification information acquisition unit 101 acquires the user ID from the user terminal 30. The user identification information acquisition unit 101 may acquire the user ID from a computer other than the user terminal 30. When a user can log in without inputting a user ID and a login password, it is assumed that authentication information (e.g., a token, a certificate, or a session ID) stored in the user terminal 30 and the user ID are associated with the user database DB1. In this case, the user identification information acquisition unit 101 acquires the user ID associated with the authentication information.

[0068] [Type determination section] When a setting is made for a setting target card for payment in a payment service, the type determination unit 102 determines the type of at least one of the setting target card and an associated card related to the setting target card. In this embodiment, an example is given in which the type determination unit 102 determines the type of each of the setting target card and the associated card (i.e., both the type of the setting target card and the type of the associated card), but the type determination unit 102 may determine only the type of the setting target card. As another example, the type determination unit 102 may determine only the type of the associated card.

[0069] The setting for the card to be set is at least one of the setting for whether the card to be set can be used and the setting for usage restrictions for the card to be set. In this embodiment, the case where the setting as a payment source (the setting for whether the card to be set can be used) corresponds to the setting for the card to be set is taken as an example. For example, when the payment source information indicates the card to be set, the card to be set is set as the payment source and becomes usable in the payment service, so the setting of the payment source information corresponds to the setting for the card to be set. Therefore, the parts that explain the setting of the payment source information can be read as the setting for the card to be set.

[0070] The setting for the target card may be any setting for the target card. The setting for the target card is not limited to the example of this embodiment. For example, registering the target card in a payment service (in this embodiment, storing payment method information for the target card in the user database DB1) may correspond to the setting for the target card. For example, the setting for the target card may correspond to the payment method information for each of a user's multiple credit cards being registered in the user database DB1 in advance, and authentication being performed based on a credit card selected by the user from multiple credit cards displayed on the user terminal 30, and the setting for the target card being set as the payment source. Other examples of the setting for the target card may include the upper limit of the payment amount per payment using the target card, the upper limit of the total payment amount for payments using the target card in a predetermined period (e.g., one week or one month), the upper limit of the number of payments using the target card, products or services that can be purchased with payments using the target card, or a combination thereof.

[0071] For example, the setting for the target card may be the setting for a payment method that will be used to charge electronic money available on the payment app. In this case, the setting for the target card may be the payment method that will be used to charge, the upper limit of the amount that can be charged per transaction, the upper limit of the total amount that can be charged in a predetermined period (e.g., one week or one month), the upper limit of the number of times that the card can be charged in a predetermined period, or a combination thereof. The setting for the target card may be the setting for a credit card used in a known payment service.

[0072] In this embodiment, the type determination unit 102 determines the type of at least one of the setting target card and related cards by determining whether or not there is additional information about the card. For example, the type determination unit 102 determines whether or not there is additional information about each of the setting target card and related cards. The additional information is information about the card's additional functions. In this embodiment, an example is given in which the electronic money function corresponds to the additional function, so an electronic money number that can identify the electronic money corresponds to the additional information. The setting target card and related cards may each have multiple pieces of additional information.

[0073] The additional information may be any information that is attached to at least one of the target card and the related card. The additional information is not limited to the electronic money number. For example, the additional information may be information that is directly or indirectly associated with the same user ID as the target card (for example, when a child card is further associated with the parent user ID via the child's user ID). For example, if the card has a point card function as an additional function, the additional information may be a point card number that can identify the point card.

[0074] For example, if the card has a membership card function as an additional function, the additional information may be a membership number that can identify the member. If the card has a transportation commuter pass function as an additional function, the additional information may be a commuter pass number that can identify the commuter pass. The additional information may also be information related to other additional functions, such as a prepaid card number, ETC card number, or cash card number. In this embodiment, an example is given in which different additional information is associated with the setting target card and related cards. However, the same additional information may also be associated with the setting target card and related cards. The additional information does not have to be associated with the setting target card and related cards, as long as it can be attached. Multiple pieces of additional information may be associated with each of the setting target card and related cards. In this case, a second authentication may be performed that combines multiple pieces of additional information. Furthermore, the type determined by the type determination unit 102 is not limited to the presence or absence of additional information. For example, the type determination unit 102 may determine whether the card is a parent card or a child card, the credit card rank (e.g., gold or platinum), the card company, brand, card face design, shopping limit, cash advance limit, or other type.

[0075] In this embodiment, the type determination unit 102 requests the electronic money server 20 to provide an electronic money number list related to the electronic money numbers associated with the user ID of the currently logged-in user, which is acquired by the user identification information acquisition unit 101. The electronic money number list indicates the electronic money numbers associated with the user ID. If multiple electronic money numbers are associated with the user ID, the electronic money number list indicates each of the multiple electronic money numbers. If there is no electronic money number associated with the user ID, the electronic money number list indicates nothing.

[0076] For example, the electronic money server 20 receives a request for an electronic money number list from the payment server 10. The request includes the user ID (user ID of the logged-in user) for which the electronic money number list is to be generated. The electronic money server 20 references the electronic money database DB2 and generates an electronic money number list indicating the electronic money numbers associated with the user ID. If there is no electronic money number associated with the user ID, the electronic money server 20 generates an electronic money number list that indicates nothing. The electronic money server 20 transmits the electronic money list to the payment server 10.

[0077] For example, the payment server 10 receives an electronic money number list from the electronic money server 20. The type determination unit 102 determines whether or not an electronic money number exists in the electronic money number list. If an electronic money number does not exist in the electronic money number list, the type determination unit 102 determines that there is no electronic money number associated with the user ID. That is, in this case, the type determination unit 102 determines that both the setting target card and the associated card are of a type that does not have an electronic money number (for example, a type that does not have an additional function). If there is no associated card in the first place, the type determination unit 102 determines that the setting target card is of a type that does not have an electronic money number.

[0078] For example, if an electronic money number exists in the electronic money number list, the type determination unit 102 determines that there is an electronic money number associated with the user ID. That is, in this case, the type determination unit 102 determines that at least one of the setting target card and the associated card is of a type in which an electronic money number exists (for example, a type in which an additional function exists). If there is no associated card, the type determination unit 102 determines that the setting target card is of a type in which an electronic money number exists.

[0079] In the examples of Figures 5 and 6, assume that the "AAA Card" of user "Tenko Taro" is still in an unauthenticated state. Assume that user "Tenko Taro" attempts to set the "AAA Card" as the payment source. In other words, assume that the "AAA Card" is the card to be set. In this case, the electronic money number list indicates four electronic money numbers associated with user ID "u00001" in the example of Figure 6. The type determination unit 102 determines that electronic money numbers exist based on the electronic money number list. In other words, the type determination unit 102 determines that electronic money numbers exist for the card to be set, the "AAA Card," and three related cards (the "EEE Card," the "AAA Card" of child user "Tenko Kosuke," and the "FFF Money" IC card without credit card function).

[0080] In the example of Figure 6, the electronic money number of the child card "AAA Card" of the child user "Tokkyo Kosuke" is associated with the user ID "u00001" of the parent user "Tokkyo Taro." Therefore, when the child user "Tokkyo Kosuke" attempts to set the child card "AAA Card" as the payment source, the electronic money number list shows nothing. In this case, the type determination unit 102 determines that the child card "AAA Card" does not have an electronic money number. In order for the child user "Tokkyo Kosuke" to set the child card "AAA Card" as the payment source, the first authentication must be successful.

[0081] The electronic money number of the child user "Patent Kosuke's" child card "AAA Card" may be associated with the child user "Patent Kosuke's" user ID "u00002" rather than the parent user "Patent Taro's" user ID "u00001." In this case, even if the parent user "Patent Taro" logs in to the payment service with his own user ID and reads the child card "AAA Card," the second authentication will not be successful. If the child user "Patent Kosuke's" logs in to the payment service with his own user ID and reads the child card "AAA Card," the second authentication will be successful. Furthermore, information such as the credit card number of the child user "Patent Kosuke's" child card "AAA Card" may be associated with either the parent user "Patent Taro's" user ID "u00001" or the child user "Patent Kosuke's" user ID "u00002."

[0082] Furthermore, if the electronic money number of the child card "AAA Card" of the child user "Patent Kosuke" is associated with the user ID "u00002" of the child user "Patent Kosuke," the user ID "u00002" of the child user "Patent Taro" may be further associated with the user ID "u00001" of the parent user "Patent Taro." In this case, since the electronic money number of the child card "AAA Card" of the child user "Patent Kosuke" is indirectly associated with the user ID "u00001" of the parent user "Patent Taro," more authentication may be required, as in Variation 3 described below. As another example, if information such as the credit card number of the child card "AAA Card" of the child user "Patent Kosuke" is associated with the user ID "u00002" of the child user "Patent Kosuke," the user ID "u00002" of the child user "Patent Kosuke" may be further associated with the user ID "u00001" of the parent user "Patent Taro."

[0083] Note that, like user "Patent Taro," users "Practical Design Hideo," "Design Hanako," and "Trademark Ayaka" have at least one electronic money number in their electronic money number list. Therefore, the type determination unit 102 determines that at least one of the target card and related cards has an electronic money number. For example, even if the target card does not have an electronic money number, as in the case of user "Trademark Ayaka," the user ID "u00005" of user "Trademark Ayaka" is associated with the electronic money number of an "LLL card" (related card) that is not registered in the payment service, so the type determination unit 102 determines that the related card has an electronic money number.

[0084] Furthermore, the method of determination by the type determination unit 102 may be other methods. The method of determination by the type determination unit 102 is not limited to the example of this embodiment. For example, the determination of the presence or absence of an electronic money number may be performed by the electronic money server 20, rather than the payment server 10. In this case, the type determination unit 102 may request determination result information regarding the determination result of the presence or absence of an electronic money number, rather than requesting an electronic money number list from the electronic money server 20. That is, the type determination unit 102 requests the electronic money server 20 to determine the presence or absence of an electronic money number. For example, the type determination unit 102 may determine in advance the presence or absence of an electronic money number, and store a flag indicating whether first authentication or second authentication will be activated in the user database DB1 or another database. The flag may be referenced at the time of authentication.

[0085] For example, the determination result information does not indicate an electronic money number, but simply indicates whether an electronic money number is present. The determination result information is a first value indicating that an electronic money number is present, or a second value indicating that an electronic money number is not present. The electronic money server 20 transmits the determination result information to the payment server 10. The payment server 10 receives the determination result information from the electronic money server 20. In this way, it is possible to prevent the electronic money number from being transmitted onto the network N. The type determination unit 102 may determine whether electronic money information is present by referring to the determination result information.

[0086] For example, the payment server 10 may request an electronic money number list or determination result information from a server other than the electronic money server 20. For example, the other server manages cards in an integrated manner. The other server may be a server of a card company, or a server of a company other than a card company. The other server transmits the electronic money number list or determination result information to the payment server 10 by the same process as the electronic money server 20 described above. The type determination unit 102 may determine whether or not an electronic money number is present based on the electronic money number list or determination result information transmitted from the other server.

[0087] For example, if the payment server 10 stores a database similar to the electronic money database DB2, the type determination unit 102 may determine the presence or absence of an electronic money number without requesting an electronic money number list or determination result information from the electronic money server 20 or another server. In this case, the payment server 10 periodically (for example, every few hours or every day) obtains data from the electronic money database DB2 from the electronic money server 20 and updates a database similar to the above. This allows the processing of the type determination unit 102 to be completed only within the payment server 10.

[0088] If the electronic money number is not included in the group of cards associated with the user ID "u00001" of the parent user "Takken Taro," the type determination unit 102 may determine whether the electronic money number is included in the group of cards associated with the user ID "u00002" of the child user "Takken Kosuke." In the example of FIG. 6, the group of cards does not exist. However, if the child user "Takken Kosuke" has a card with an electronic money number, the type determination unit 102 may treat the card as a related card. In this case, the authentication execution unit 103, described below, may initiate second authentication. Furthermore, the authentication execution unit 103 may initiate second authentication after performing question authentication or the like. Furthermore, additional information determination and second authentication may be performed on other cards associated with the child user's user ID. Furthermore, the user terminal 30 may allow the user to select either the first authentication or the second authentication. If the user has a card with an electronic money number, the user terminal 30 may guide the user to select the second authentication, and the second authentication may be initiated simply by the user's selection operation.

[0089] [Authentication execution part] The authentication execution unit 103 executes a process for authentication according to the type of at least one of the cards determined by the type determination unit 102. In this embodiment, an example is given in which the authentication execution unit 103 executes a process for authentication according to the type of each of the setting target card and the associated card (i.e., both the type of the setting target card and the type of the associated card), but the authentication execution unit 103 may execute a process for authentication according to only the type of the setting target card. As another example, the authentication execution unit 103 may execute a process for authentication according to only the type of the associated card.

[0090] The process for authentication may be auxiliary processing in which the payment server 10 causes another computer to perform authentication, or it may mean that the payment server 10 itself performs authentication. For example, the auxiliary processing is when the payment server 10 displays a screen including a link to another computer, when the payment server 10 redirects the user terminal 30 to another computer, or when the payment server 10 transmits information required for authentication to another computer. The process in which the payment server 10 performs a process to compare authentication information (e.g., user ID, password, electronic money number, etc.) is equivalent to the payment server 10 itself performing a process for authentication.

[0091] In this embodiment, the first authentication is mainly performed by the card company's computer, and therefore the processing for the first authentication is processing for having the card company's computer perform the first authentication. In the example of FIG. 2, the button B20 on the authentication screen SC2 in the upper right corner of FIG. 2 includes a link to the card company's screen SC3 (for example, a direct link to the card company's screen SC3 or a link for redirecting to the card company's screen SC3). The processing for displaying the authentication screen SC2 including the link on the user terminal 30 corresponds to the processing for the first authentication. Note that the processing for the first authentication may mean that the payment server 10 itself performs the first authentication. Depending on the type of first authentication, the payment server 10 itself may perform the first authentication, rather than another computer such as the card company's computer. Therefore, the authentication execution unit 103 may perform the processing for the first authentication by itself performing the first authentication.

[0092] In this embodiment, the second authentication is mainly performed by the payment server 10, and therefore the processing for the second authentication is performed by the payment server 10 itself. For example, the processing for the second authentication is processing in which the payment server 10 compares information acquired from the user terminal 30 or information associated with the information, with information that is correct in the second authentication. For example, the processing for comparing user identification information, which will be described later, corresponds to the processing for the second authentication. Note that the second authentication may be executed by a computer of the card company, as in the first authentication, or may be executed by a server other than the payment server. That is, the processing for the second authentication may be processing in which a screen for the second authentication is displayed. In this case, the second authentication is executed by a computer other than the payment server 10 (for example, a computer of the card company). The authentication execution unit 103 may acquire data indicating the execution result of the second authentication from the other computer.

[0093] Authentication according to type is authentication in which the processing content differs depending on the type. For example, when the type determined by the type determination unit 102 is the first type, the authentication execution unit 103 executes the first authentication. The first authentication is not limited to 3D Secure authentication as in the present embodiment. The first authentication may be security code authentication, password authentication, biometric authentication, or other authentication. When the type determined by the type determination unit 102 is the second type, the authentication execution unit 103 executes a second authentication different from the first authentication. The second authentication is not limited to scan authentication as in the present embodiment. The second authentication may be any authentication different from the first authentication. The second authentication may be any authentication different from the first authentication among the authentications exemplified as the first authentication. Contrary to the example of the present embodiment, the first authentication may be scan authentication, and the second authentication may be authentication other than scan authentication. In this case, however, it is assumed that some information other than the incidental information can be scanned.

[0094] In this embodiment, the authentication execution unit 103 executes processing for authentication according to the presence or absence of an electronic money number on at least one of the cards determined by the type determination unit 102. For example, when it is determined that at least one of the cards determined by the type determination unit 102 does not have an electronic money number, the authentication execution unit 103 executes processing for first authentication in which the electronic money number is not used. For example, when it is determined that at least one of the cards determined by the type determination unit 102 has an electronic money number, the authentication execution unit 103 executes processing for second authentication in which the electronic money number is used.

[0095] In this embodiment, the second authentication is scan authentication, and therefore, when it is determined by the type determination unit 102 that at least one of the cards has an electronic money number, the authentication execution unit 103 executes processing for the second authentication based on the electronic money number acquired by the user terminal 30 reading at least one of the cards. The method for reading the electronic money number by the user terminal 30 may be any method. The method for reading the electronic money number by the user terminal 30 is not limited to reading using the NFC function.

[0096] For example, the user terminal 30 may read the electronic money number using a communication function other than NFC. For example, the user terminal 30 may read the electronic money number using the photographing unit 36. In this case, it is assumed that the electronic money number is formed on the face of the target card or related card. The electronic money number may be printed on the face of the card or may be formed by embossing. The user terminal 30 acquires the electronic money number by performing image processing such as optical character recognition on the image generated by the photographing unit 36.

[0097] For example, the authentication execution unit 103 identifies user identification information associated with the electronic money number acquired by the user terminal 30. In this embodiment, a user ID is described as an example of user identification information used in authentication, but the user identification information may be other information as described above. In the description of the authentication process in this embodiment, the term "user ID" may be replaced with any other user identification information.

[0098] For example, when the payment server 10 acquires an electronic money number from the user terminal 30, the authentication execution unit 103 requests the electronic money server 20 for the user ID associated with the electronic money number. Upon receiving the request, the electronic money server 20 acquires the user ID associated with the electronic money number based on the electronic money database DB2. The electronic money server 20 transmits the user ID to the payment server 10. The payment server 10 receives the user ID from the electronic money server 20.

[0099] For example, the authentication execution unit 103 executes processing for the second authentication based on a user ID acquired based on the login and a user ID associated with the electronic money number acquired by the user terminal 30. In this embodiment, the authentication execution unit 103 compares these user IDs to determine whether they match. If the authentication execution unit 103 determines that these user IDs do not match, it determines that the second authentication has failed. If the authentication execution unit 103 determines that these user IDs match, it determines that the second authentication has succeeded.

[0100] In the examples of Figures 5 and 6, let us assume that the "AAA card" of user "Takken Taro" is still in an unauthenticated state. Let us assume that user "Takken Taro" attempts to set the "AAA card" as the payment source. In other words, let us assume that the "AAA card" is the card to be set. In this case, the type determination unit 102 determines that there is an electronic money number for at least one of the card to be set and the related card, so the authentication execution unit 103 executes processing for second authentication.

[0101] In the example of FIG. 6, four electronic money numbers are associated with the user ID "u00001" of the user "Takken Taro." In this embodiment, even if the user "Takken Taro" reads any of the cards with these four electronic money numbers, the user ID matches, so the second authentication is successful. Therefore, the user "Takken Taro" can read not only the target card "AAA card," but also three related cards ("EEE card," child user "Takken Taro"), The second authentication will be successful even if the IC card ("AAA Card" of "Kosuke" and "FFF Money" IC card without credit card function) is read.

[0102] If the user "Takken Taro" has successfully completed the second authentication of the "AAA Card," the second authentication of the "EEE Card," another credit card registered by the user "Takken Taro" in the payment service, may also be treated as successful, since the "EEE Card" is associated with the same user ID. Also, if the user "Takken Taro" reads an "FFF Money" IC card without a credit card function with the user terminal 30, the authentication execution unit 103 may determine that the second authentication has been successful.

[0103] Furthermore, when the user "Takken Taro" reads an "FFF Money" IC card without a credit card function with the user terminal 30, the authentication execution unit 103 may not determine that the second authentication is successful. In this case, it is assumed that information capable of identifying whether or not the card has a credit card function is stored in a database such as the electronic money database DB2. The authentication execution unit 103 may determine that the second authentication is successful only when a related card with a credit card function is read. Furthermore, when an "FFF Money" IC card without a credit card function is used, it may have a lower security level than a credit card, so it may be excluded from the authentication. Alternatively, for example, instead of excluding the IC card from the authentication, the second authentication may be combined with another authentication such as attribute authentication.

[0104] In the example of Figure 6, the second authentication is not triggered for the child user "Patent Kosuke" because the electronic money number of the child card is associated with the user ID of the parent user "Patent Taro." Even if the child user "Patent Kosuke" were to attempt the second authentication in some way, the user ID associated with the electronic money number of the child card "AAA Card" would not be the user ID of the parent user "Patent Taro." Since the user ID acquired based on the login belongs to the child user "Takken Kosuke," and the user ID associated with the electronic money number acquired by the user terminal 30 belongs to the parent user "Takken Taro," the second authentication is not successful. For example, if the second authentication is activated solely by the user's selection, the child user "Takken Kosuke" selects the second authentication, and the second authentication is activated. In this case, the authentication execution unit 103 determines that these user IDs do not match each other, and therefore determines that the second authentication has failed.

[0105] Note that, like user "Taro Patent," users "Hideo Design," "Hanako Design," and "Ayaka Trademark" can successfully complete the second authentication by scanning a credit card with an electronic money number. For example, even if user "Ayaka Trademark" uses an "LLL card" that is not registered in the payment service for scan authentication, the authentication execution unit 103 determines that the second authentication is successful because the user IDs match.

[0106] For example, suppose a malicious third party has illegally obtained information such as the user ID "u00001" and the credit card number of "AAA Card." Furthermore, suppose the third party masquerades as user "Patent Taro" and tries to fraudulently set "AAA Card" as the payment source for his / her own payment application. In this case, the third party uses the credit card (user "Patent Taro") in hand to Even if the electronic money number of a credit card (not "AAA card" of "Mr. Taro") is read, the user ID associated with the electronic money number is not the logged-in user ID "u00001". Since these user IDs do not match, the authentication execution unit 103 determines that the second authentication has failed.

[0107] Note that the second authentication may be performed by other methods. The second authentication method is not limited to the example of this embodiment. For example, if the payment server 10 manages a database similar to the electronic money database DB2, the authentication execution unit 103 may identify the user ID associated with the electronic money number scanned by the user based on the database it manages, without inquiring of the electronic money server 20 about the user ID. As another example, the authentication execution unit 103 may request the electronic money server 20 or another computer to compare the user IDs, rather than comparing the user IDs itself. In this case, the authentication execution unit 103 obtains data indicating the comparison result from the electronic money server 20 or another computer. Based on the data, the authentication execution unit 103 determines whether the second authentication was successful.

[0108] For example, the authentication execution unit 103 may execute the second authentication by determining whether or not the electronic money number acquired by reading by the user terminal 30 exists in the electronic money number list, rather than comparing the user IDs. In this case, the authentication execution unit 103 determines that the second authentication has failed if the electronic money number does not exist in the electronic money number list. The authentication execution unit 103 determines that the second authentication has succeeded if the electronic money number exists in the electronic money number list.

[0109] For example, even if it is determined that the target card does not have an electronic money number, the authentication execution unit 103 may execute processing for the second authentication if it is determined that the related card has an electronic money number. That is, the user may scan the related card with the user terminal 30 instead of the target card. The flow of the second authentication in this case is as described above. In the examples of Figures 5 and 6, the flow of the second authentication for the user "Trademark Ayaka" corresponds to the above processing.

[0110] For example, even if it is determined that the target card has an electronic money number, the authentication execution unit 103 can execute the process for the second authentication based on the additional information acquired by the user terminal 30 reading the related card. The flow of the second authentication in this case is as described above. The authentication execution unit 103 may use either the electronic money number of the target card or the electronic money number of the related card in the process for the second authentication. In the examples of Figures 5 and 6, the flow of the second authentication when the user "Takken Taro" reads a card other than the "AAA card" corresponds to the above process.

[0111] In this embodiment, the card to be set is the personal card of the user who is making the setting. The personal card is a card in whose name the user currently logged in to the payment service from the user terminal 30 is the holder. The related card may also be a family card of the user's family. In the example of Figures 5 and 6, one of the related cards of user "Takken Taro" includes the family card of his child user "Takken Kosuke." The family card is a card in whose name the family of the user currently logged in to the payment service from the user terminal 30 is the holder. For example, the family member may be a spouse, child, or other person. The child card is a type of family card. The family card does not have to have a parent-child relationship with the personal card.

[0112] For example, even if it is determined that the principal card does not have an electronic money number, the authentication execution unit 103 may execute processing for second authentication if it is determined that the family card has an electronic money number. The flow of second authentication itself is as described above. In the examples of Figures 5 and 6, even if the principal card of user "Takken Taro" does not have an electronic money number, the second authentication can be successful with the child card, and the above processing is executed. Note that in the example of Figure 6, the child card's electronic money number is associated with the parent user's user ID, but the child card's electronic money number may also be associated with the child user's user ID. Furthermore, other information on the child card, such as the child card's credit card number, may also be associated with the parent user's user ID or the child user's user ID. However, since credit cards can generally only be used by the principal, child cards are assumed to be used by children (family members). For this reason, the parent user generally does not use the child card with his or her own payment app.

[0113] [Settings reflection section] The setting reflecting unit 104 reflects the settings for the target card when authentication is performed. Reflecting the settings means activating the settings. Once the settings are reflected, payment is performed based on the reflected settings. In this embodiment, since the payment source information corresponds to the settings, the setting reflecting unit 104 reflects the settings by updating the payment source information in the user database DB1 or by adding the payment source information to the user database DB1. If authentication fails, the setting reflecting unit 104 does not reflect the settings. If authentication is successful, the setting determination unit reflects the settings. The authentication that determines whether the settings are reflected may be either the first authentication or the second authentication.

[0114] In this embodiment, the setting reflecting unit 104 changes the payment source information and the authentication result information. When the authentication result information for a credit card is changed to authenticated, the user can set the credit card as the payment source without needing to authenticate again. The authentication is reflected not only in the payment source setting, but also in other settings, such as the setting of the charging method for the online electronic money "DDD Cash." Therefore, the user can set the credit card that was authenticated to set as the payment source as the charging method for the online electronic money "DDD Cash" without needing to authenticate again.

[0115] [Payment Execution Department] The payment execution unit 105 executes the payment based on the settings reflected by the setting reflection unit 104. Payment includes not only payments by affiliated stores to payment services, but also charging electronic money or transferring money to others. The method of executing the payment itself may be a known process. The payment execution unit 105 identifies the payment means of the payment source based on the payment source information, and executes the payment based on the identified payment means.

[0116] [3-5. Other functions realized by the electronic money server] As an example of other functions realized by the electronic money server 20, a receiving unit 201 and a transmitting unit 202 will be described.

[0117] [Receiver] The receiving unit 201 receives various requests from the payment server 10 or other computers. For example, the receiving unit 201 receives a request to generate an electronic money number list from the payment server 10. The request includes the user ID of the user for whom the electronic money number list is to be generated.

[0118] [Transmitter] The transmitting unit 202 transmits various data to the payment server 10 or another computer. For example, the transmitting unit 202 transmits an electronic money number list to the payment server 10 or another computer. The method for generating the electronic money number list is as described above.

[0119] [3-6. Other functions realized on the user terminal] As an example of other functions realized by the user terminal 30, a reading unit 301 and a transmitting unit 302 will be described.

[0120] [Reading unit] The reading unit 301 reads at least one of the setting target card and the related card. In this embodiment, an example is given in which the reading unit 301 reads only one of the setting target card or the related card, but the reading unit 301 may read both the setting target card and the related card. For example, the reading unit 301 performs reading using the NFC function of the user terminal 30. The reading unit 301 may perform reading using a communication function other than the NFC function, or may perform reading using the photographing unit 36.

[0121] [Transmitter] The transmitting unit 302 transmits to the payment server 10 data indicating the result of reading by the reading unit 301 (for example, data indicating the electronic money number).

[0122] [4. Processing performed by the authentication system] 7 and 8 are diagrams showing an example of processing executed in the authentication system 1. The processing in Fig. 7 and Fig. 8 is executed by the control units 11, 21, and 31 operating in accordance with programs stored in the storage units 12, 22, and 32, respectively.

[0123] As shown in FIG. 7, when the payment app is launched, the user terminal 30 executes a login process with the payment server 10 for the user to log in to the payment service (S1). In S1, the user terminal 30 transmits the user ID and login password entered by the user to the payment server 10. The payment server 10 determines that the login is successful if the user ID and login password entered by the user exist in the user database DB1. The payment server 10 stores the user ID of the logged-in user in the storage unit 12. As described above, a login process may be executed in which the input of the user ID and login password is omitted. Such a login process itself may be a known process.

[0124] The following describes the processing that occurs when the user performs an operation to select a payment source. The user terminal 30 executes processing with the payment server 10 to display the payment source setting screen SC1 (S2). When the user selects button B10, the user terminal 30 transmits payment method information that can identify the payment method selected as the payment source to the payment server 10 (S3). When the payment server 10 receives the payment method information from the user terminal 30 (S4), it determines whether the authentication result information associated with the payment method information indicates that it has been authenticated, based on the user database DB1 (S5).

[0125] If it is determined in S5 that the authentication result information indicates that authentication has been completed (S5: Y), the payment server 10 executes processing to update the payment source information with the user terminal 30 (S6), and this processing ends. In this case, since authentication has already been completed, the payment source is set or changed without executing the processing from S6 onwards.

[0126] If it is determined in S5 that the authentication result information does not indicate that the user has been authenticated (S5:N), the payment server 10 requests an electronic money number list from the electronic money server 20 based on the user ID of the logged-in user (S7). The electronic money server 20 accepts the request from the payment server 10 (S8). The electronic money server 20 generates an electronic money number list indicating the electronic money numbers associated with the user ID included in the request from the payment server 10 based on the electronic money database DB2 (S9). The electronic money server 20 transmits the electronic money number list to the payment server 10 (S10).

[0127] The payment server 10 receives a list of electronic money numbers from the electronic money server 20 (S11). The payment server 10 determines whether or not the electronic money numbers of the setting target card and the related cards are present based on the list of electronic money numbers (S12). If the payment server 10 determines that the electronic money numbers of the setting target card and the related cards are absent (S12: N), it executes processing for first authentication with the user terminal 30 (S13). By the processing of S13, the authentication screen SC2 in the upper right of FIG. 2 is displayed on the user terminal 30. Thereafter, the first authentication (for example, 3D Secure authentication and security code authentication) is executed between the user terminal 30 and the card company's computer.

[0128] The payment server 10 acquires information indicating the execution result of the first authentication from the user terminal 30 or the card company's computer, and determines whether the first authentication was successful or not (S14). If it is determined that the first authentication failed (S14: N), this process ends. In this case, the setting of the payment source information is not reflected. If it is determined that the first authentication was successful (S14: Y), the payment server 10 reflects the setting of the payment source information (S15), and this process ends. In S15, the payment server 10 also executes a process to update the authenticated information.

[0129] In S12, if the payment server 10 determines that at least one of the target card and the related card has an electronic money number (S12: Y), the process proceeds to Fig. 8, and the payment server 10 executes processing with the user terminal 30 to display the authentication screen SC2 in the upper right of Fig. 3 (S16). The user terminal 30 transmits information indicating the authentication selected by the user from the first authentication and the second authentication to the payment server 10 (S17). Upon receiving the information (S18), the payment server 10 determines which authentication, the first authentication or the second authentication, the user selected (S19).

[0130] If it is determined in S19 that the user has selected the first authentication (S19: first authentication), the process proceeds to S13. If it is determined in S19 that the user has selected the second authentication (S19: second authentication), the payment server 10 executes processing to display a modal M23 between the payment server 10 and the user terminal 30 (S20). The user terminal 30 activates the NFC function of the communication unit 23 and reads the setting target card or a related card (S21). The user terminal 30 transmits the electronic money number read by the NFC function to the payment server 10 (S22).

[0131] The payment server 10 receives the electronic money number read by the NFC function from the user terminal 30 (S23). The payment server 10 requests the user ID associated with the electronic money number read by the NFC function from the electronic money server 20 (S24). Upon receiving the request (S25), the electronic money server 20 transmits the user ID associated with the electronic money number read by the NFC function to the payment server 10 based on the electronic money database DB2 (S26).

[0132] The payment server 10 receives from the electronic money server 20 the user ID associated with the electronic money number read by the NFC function (S27). The payment server 10 determines whether the second authentication has been successful by determining whether the user ID of the logged-in user matches the user ID associated with the electronic money number read by the NFC function (S28). If it is determined that the second authentication has failed (S28: N), this process ends. If the second authentication has failed, the first authentication may be requested. If it is determined that the second authentication has been successful (S28: Y), the setting of the payment source information is reflected (S29), and this process ends. In S29, the payment server 10 also executes a process of updating the authenticated information.

[0133] [5. Summary of embodiments] When a setting is made for a setting target card, the authentication system 1 of this embodiment determines the type of at least one of the setting target card and related cards. The authentication system 1 executes a process for authentication according to the type of the at least one card. The authentication system 1 reflects the setting when the authentication is executed. This allows the authentication system 1 to flexibly use different authentication methods depending on the type of the at least one card, thereby improving user convenience while maintaining security in payment. For example, if the type of the at least one card is a type that allows authentication that improves user convenience while maintaining security, the authentication system 1 enables the authentication. Even if the type of the at least one card is not a type that allows such authentication, the authentication system 1 executes a process for another authentication to improve security and prevent a situation where the user has no authentication means to reflect the setting (for example, the setting can be reflected if the user successfully completes the first authentication), thereby improving convenience.

[0134] Furthermore, the authentication system 1 determines the type of at least one of the target card and related cards by determining whether or not the card has an electronic money number (an example of additional information). The authentication system 1 executes authentication processing depending on whether or not the at least one card has an electronic money number. This allows the authentication system 1 to flexibly use authentication methods depending on whether or not the at least one card has an electronic money number, thereby improving user convenience while maintaining payment security. For example, if an authentication method that improves user convenience while maintaining security is possible when an electronic money number is present, the authentication system 1 enables such authentication, thereby improving user convenience while maintaining payment security. For example, the authentication system 1 does not exchange a credit card number for the essential function of the at least one card during authentication, but only exchanges an electronic money number, which is additional information for an additional function that plays a secondary role, thereby improving security. For example, the authentication system 1 can promote the use of electronic money services (an example of services related to additional information) by using an electronic money number (an example of additional information) as authentication information.

[0135] Furthermore, when it is determined that at least one of the target card and the related cards does not have an electronic money number, the authentication system 1 executes processing for first authentication that does not use the electronic money number. When it is determined that at least one of the target card and the related cards has an electronic money number, the authentication system 1 executes processing for second authentication that uses the electronic money number. This allows the authentication system 1 to flexibly use the first authentication and the second authentication depending on whether or not at least one of the cards has an electronic money number, thereby improving user convenience while maintaining payment security. For example, if the second authentication provides higher security and user convenience than the first authentication, the authentication system 1 executes processing for the second authentication when the type of card is capable of second authentication, thereby improving user convenience while maintaining payment security. The authentication system 1 can prevent a user from being unable to perform any authentication by executing the first authentication even if the type of card is not capable of second authentication, thereby improving user convenience while maintaining payment security.

[0136] Furthermore, when it is determined that at least one of the target card and the related cards has an electronic money number, the authentication system 1 executes processing for second authentication based on the electronic money number obtained by the user terminal 30 reading the at least one card. This allows the authentication system 1 to improve user convenience while maintaining payment security. For example, scan authentication is highly secure because the physical credit card is in hand. While 3D Secure authentication or security code authentication requires the user to enter information, and the user may forget their password, scan authentication does not require the user to enter a password or the like, improving user convenience.

[0137] Furthermore, the authentication system 1 acquires the user ID of the logged-in user based on the login from the user terminal 30. The authentication system 1 identifies the user ID associated with the electronic money number acquired by the user terminal 30. The authentication system 1 executes processing for the second authentication based on the user ID acquired based on the login and the user ID associated with the electronic money number acquired by the user terminal 30. This eliminates the need for the authentication system 1 to exchange highly confidential information such as a credit card number, and therefore allows authentication to be executed without leaking highly confidential information.

[0138] Furthermore, the authentication system 1 determines whether or not the setting target card and the related cards each have an electronic money number. Even if it is determined that the setting target card does not have an electronic money number, the authentication system 1 executes processing for second authentication if it is determined that the related card has an electronic money number. As a result, even if second authentication is not possible with the setting target card that the user is trying to set, if second authentication is possible with the related card, the authentication system 1 allows the user to reflect the setting of the setting target card through second authentication using the related card, thereby maintaining security in payments and improving user convenience.

[0139] As described above, the target card for setting may be the user's personal card. The related card may be the family card of the user's family member. In this case, even if it is determined that the personal card does not have an electronic money number, the authentication system 1 executes processing for second authentication if it is determined that the family card has an electronic money number. As a result, even if the personal card that the user is trying to set up is not capable of second authentication, if second authentication is possible with the family card, the authentication system 1 allows the user to reflect the settings on the personal card through second authentication using the family card, thereby maintaining security in payments and improving user convenience.

[0140] Furthermore, even if it is determined that the target card has an electronic money number, the authentication system 1 can execute processing for the second authentication based on the accompanying information acquired by the user terminal 30 reading the associated card. This allows the authentication system 1 to authenticate an associated card different from the target card, further increasing user convenience. For example, even if the target card is not on hand, if the user has an associated card on hand, the user can use the associated card to complete the second authentication.

[0141] [6. Modifications] The present disclosure is not limited to the above-described embodiments, and may be modified as appropriate without departing from the spirit of the present disclosure.

[0142] Fig. 9 is a diagram showing an example of functions in the modified example. As shown in Fig. 9, the payment server 10 in the modified example includes an authentication application unit 106, a first selection acceptance unit 107, and a second selection acceptance unit 108. Each of the authentication application unit 106, the first selection acceptance unit 107, and the second selection acceptance unit 108 is realized by the control unit 11.

[0143] [6-1. Variation 1] For example, the authentication execution unit 103 may execute authentication according to the validity of the electronic money number. In the first modification, as in the embodiment, it is assumed that validity information of the electronic money number is stored in the electronic money database DB2. Furthermore, it is assumed that the electronic money number list of the first modification includes not only the electronic money number but also the validity information. The authentication execution unit 103 determines whether the electronic money number is valid based on the validity information in the electronic money number list. Note that the electronic money number list may not include the validity information, and may only show the electronic money number so that the validity information indicates that it is valid.

[0144] The authentication execution unit 103 of the first modification executes processing for the first authentication when the electronic money number of at least one of the setting target card and the related card is invalid. For example, the authentication execution unit 103 executes processing for the first authentication when all electronic money numbers included in the electronic money number list are invalid. Note that the authentication execution unit 103 may execute processing for the first authentication when some of the electronic money numbers included in the electronic money number list are invalid. The processing for the first authentication is as described in the embodiment.

[0145] The authentication execution unit 103 of the first modification executes processing for second authentication when the electronic money number of at least one of the target card and the related card is valid. For example, the authentication execution unit 103 executes processing for second authentication when the electronic money number list contains at least one valid electronic money number. Note that the authentication execution unit 103 may execute processing for second authentication when all electronic money numbers contained in the electronic money number list are valid. The processing for second authentication is as described in the embodiment.

[0146] Although the first modification has been described with reference to an example in which the electronic money number list includes validity information, the method for determining the validity of an electronic money number is not limited to the above example. For example, if the payment server 10 stores a database similar to the electronic money database DB2, the authentication execution unit 103 may determine whether the electronic money number is valid based on the validity information stored in the database.

[0147] Alternatively, for example, the payment server 10 may request the electronic money server 20 or another computer to determine the validity of the electronic money number. In this case, the electronic money server 20 or another computer determines whether the electronic money number is valid or not based on the validity information of the electronic money number. The electronic money server 20 or another computer transmits data indicating the determination result to the payment server 10. The payment server 10 receives the data from the electronic money server 20 or another computer. The authentication execution unit 103 may determine whether to execute processing for the first authentication or processing for the second authentication based on the data.

[0148] The authentication system 1 of Variation 1 executes processing for the first authentication when the electronic money number of at least one of the setting target card and related cards is invalid. The authentication system 1 executes processing for the second authentication when the electronic money number of at least one of the setting target card and related cards is valid. This allows the authentication system 1 to prevent the second authentication from succeeding with an invalid electronic money number, thereby further improving security in payments. For example, even if a malicious third party obtains a card that a user has lost, if the electronic money number of the card is invalid, the third party cannot impersonate the user and succeed in the second authentication, so the authentication system 1 can further improve security in payments.

[0149] [6-2. Variation 2] For example, the type determination unit 102 may determine the types of the setting target card and the related card based on the parent-child relationship between the setting target card and the related card. The parent-child relationship between the setting target card and the related card may be shown in any database. For example, the parent-child relationship between the setting target card and the related card may be shown in a user database DB1, an electronic money database DB2, or another database. For example, the other database may be a card company database. These databases store information indicating whether the setting target card and the related card are a parent or a child. The parent card may be associated with information that can identify the child card. The child card may be associated with information that can identify the parent card.

[0150] In the second modification, it is assumed that parent-child relationship information indicating the relationship between a parent card and a child card is stored in the electronic money database DB2. In the example of FIG. 6, among the electronic money numbers associated with the user ID "u000001" of the parent user "Takken Taro," the electronic money number of the child user "Takken Kosuke" is associated with parent-child relationship information indicating that it is the electronic money number of the child card. The parent-child relationship information may indicate information that can identify the parent card.

[0151] The electronic money number list of the second modification includes not only electronic money numbers but also parent-child relationship information. The type determination unit 102 determines the type of each of the target card and related cards based on the parent-child relationship indicated by the parent-child relationship information in the electronic money number list. For example, the type determination unit 102 identifies a credit card having an electronic money number as a child card based on the parent-child relationship information associated with the electronic money number of the child user "Patent Kosuke." When the type determination unit 102 identifies the credit card as a child card, the authentication execution unit 103 executes processing for second authentication.

[0152] In the second modification, the authentication execution unit 103 may execute authentication depending on whether at least one of the setting target card and the related card is a parent card or a child card. For example, when at least one of the setting target card and the related card is a parent card and the parent card is used for authentication, the authentication execution unit 103 may execute processing for the second authentication. When at least one of the setting target card and the related card is a child card and the child card is read by a user and used for authentication, the authentication execution unit 103 may execute both processing for the first authentication and processing for the second authentication. Whether the parent card or the child card is used for authentication may be specified based on information that can identify the card, such as an electronic money number.

[0153] In addition, in the second modification, the case where the electronic money number list includes parent-child relationship information has been exemplified, but the method for determining the parent-child relationship is not limited to the above example. For example, if the payment server 10 stores a database similar to the electronic money database DB2, the type determination unit 102 may determine the parent-child relationship based on the parent-child relationship information stored in the database.

[0154] Alternatively, for example, the payment server 10 may request the electronic money server 20 or another computer to determine the parent-child relationship. In this case, the electronic money server 20 or another computer determines the parent-child relationship based on parent-child relationship information that it manages. The electronic money server 20 or another computer transmits data indicating the determination result to the payment server 10. The payment server 10 receives the data from the electronic money server 20 or another computer. The type determination unit 102 may determine the parent-child relationship based on the data.

[0155] The authentication system 1 of the second modification determines the types of the setting target card and the related card based on the parent-child relationship between them. This allows the authentication system 1 to flexibly use different authentication methods depending on the parent-child relationship, thereby improving user convenience while maintaining security in payments. For example, when a child card is used for authentication, the authentication system 1 can request authentication with higher security than when a parent card is used for authentication.

[0156] [6-3. Variation 3] For example, in Modification 2, the authentication execution unit 103 may execute a process for multiple authentications when it is determined that the type of at least one of the setting target card and the related card is child. Multiple authentications are sometimes called multi-step authentication or multi-factor authentication. In Modification 3, the authentication execution unit 103 executes a process for second authentication and a process for third authentication when it is determined that the type of at least one of the setting target card and the related card is child. That is, when a child card is used for authentication, the authentication execution unit 103 executes a process for second authentication and a process for third authentication. The multiple authentications are not limited to two, such as the second authentication and the third authentication, but may be three or more authentications. For example, whether or not a scanned card is a child is determined after the second authentication. The determination of whether or not a child card having an electronic money number exists may be executed before scanning.

[0157] The third authentication is different from the second authentication. The third authentication may be the same as the first authentication, but in variant 3, it is different from the first authentication. For example, the third authentication may be attribute authentication using authentication information such as an electronic certificate, question authentication asking information such as family surnames, birth dates, and phone numbers, 3D Secure authentication, security code authentication, or other authentication. The authentication information that is correct in the third authentication is stored in the payment server 10 or another computer. The third authentication is performed by comparing the information received from the user terminal 30 with the correct authentication information.

[0158] For example, when the third authentication is performed mainly by the payment server 10, the processing for the third authentication is performed by the payment server 10 itself. In this case, the processing for the third authentication is processing for comparing information acquired by the payment server 10 from the user terminal 30 or information associated with the information, with information that is correct in the third authentication. For example, in the case of attribute authentication, the processing for the third authentication corresponds to processing for the payment server 10 confirming the validity of the digital certificate acquired by the payment server 10 from the user terminal 30.

[0159] The third authentication may be performed mainly by a computer other than the payment server 10. In this case, the process for the third authentication is a process for making the other computer perform the third authentication. For example, the user terminal 30 includes a link to the other computer (for example, a direct link to the other computer or a link for redirecting to the other computer). The process for displaying a screen including the link on the user terminal 30 corresponds to the process for the third authentication.

[0160] The authentication system 1 of the third modification executes multiple authentication processes when it is determined that the type of at least one of the target card and the related card is a child. This allows the authentication system 1 to request authentication with higher security when the target card is configured using a child card.

[0161] [6-4. Variation 4] For example, if the expiration date of the setting target card set as the payment source is updated, re-authentication may be required, but if the setting target card has already been authenticated, it may be possible to set it as the payment source without requiring re-authentication. In the fourth modification, when the expiration date of the setting target card whose setting has been reflected by the setting reflecting unit 104 is updated, the payment execution unit 105 can execute payment based on the setting without requiring re-authentication.

[0162] In Variation 4, even if the expiration date indicated in the payment method information stored in the user database DB1 is updated, if the authentication result information indicates that the card has been authenticated, the authentication execution unit 103 does not request re-authentication. In other words, even if the user updates the expiration date of an authenticated credit card, the payment server 10 does not change the authentication result information of the credit card. Since the authentication result information of the credit card remains unchanged, indicating that the card has been authenticated, the payment execution unit 105 can execute the payment without re-authentication.

[0163] When the expiration date of the setting target card is updated, the authentication system 1 of the fourth modification can execute payment without requiring re-authentication, based on the settings reflected by the setting reflection unit 104. This allows the authentication system 1 to improve user convenience because it does not require the user to perform re-authentication even when the expiration date of the setting target card is updated.

[0164] [6-5. Variation 5] For example, the payment service may be linked to another service different from the payment service. In Variation 5, the user can use another service from the payment app. Payment for the other service can be made using a payment method registered by the user with the payment service. In Variation 5, a transportation service is described as an example of the other service. The other service may be any service and is not limited to a transportation service. For example, the other service may be an online shopping service, an electronic ticket service, an e-book service, a financial service, or other service. The other service may also be a payment service different from the payment service. For example, the payment service may be a payment service using a first electronic money, and the other service may be a payment service using a second electronic money.

[0165] In variant 5, a user can charge electronic money for a transportation service from a payment app. When a user issues a charge instruction from the payment app using a payment method set as the payment source, the electronic money for the transportation service is charged. The method of linking the payment service and the transportation service may be a known method. For example, when the payment server 10 executes a payment for charging, it requests a charge from the transportation service server. The charge request indicates the charge amount. Based on the request, the transportation service server executes the charge so that the balance of the electronic money increases by the charge amount.

[0166] The authentication system 1 includes an authentication application unit 106. When authentication is performed by the authentication execution unit 103, the authentication application unit 106 applies authentication to a transportation service. Applying authentication means that, even when a payment is performed to use a transportation service by a user, a payment method that has already been authenticated by the payment service can be used without further authentication. For example, setting authentication result information to "authenticated" corresponds to applying authentication. Another example is setting other information referenced by the payment server 10 when a user uses a transportation service from a payment app to indicate that the information has been authenticated, which corresponds to applying authentication to the transportation service.

[0167] For example, when a user instructs the use of a transportation service (e.g., charging electronic money for a transportation service), the authentication application unit 106 refers to the authentication result information of the payment method used for charging. If the authentication result information indicates that authentication has been performed, the authentication application unit 106 does not perform further authentication. If the authentication result information does not indicate that authentication has been performed, the authentication application unit 106 has the authentication execution unit 103 perform authentication because the authentication to be applied has not yet been performed.

[0168] In the authentication system 1 of the fifth modification, when authentication is performed, the authentication is applied to services other than the payment service. This eliminates the need for authentication to be performed again to use other services, thereby improving user convenience. For example, if a user performs authentication to set a target card as a payment source for a payment app, it is possible to prevent further authentication from being performed to set the target card as a charge method for electronic money for transportation services, thereby saving the user time and effort.

[0169] [6-6. Variation 6] For example, the authentication execution unit 103 may execute processing for the first authentication when the type of at least one of the target card and the related card is a first type. In the example embodiment, the first type is a type without an electronic money number. The first type may be any predetermined type and is not limited to the example embodiment. For example, the first type may be a child card. The first type may be a predetermined brand, a predetermined card company, a predetermined rank of credit card, a shopping limit upper limit less than a threshold, or any other type.

[0170] For example, when the type of at least one of the target card and the related card is a second type different from the first type, the authentication execution unit 103 can execute processing for the second authentication different from the first authentication. In the example embodiment, the second type is a type having an electronic money number. The second type may be any predetermined type and is not limited to the example embodiment. For example, the second type may be a parent card. The second type may be a predetermined brand, a predetermined card company, a predetermined rank of credit card, a shopping limit upper limit equal to or greater than a threshold, or any other type.

[0171] The authentication system 1 includes a first selection receiving unit 107. The first selection receiving unit 107 receives a selection regarding whether or not second authentication is required when the type of at least one of the target card and related cards is the second type. Receiving a selection means receiving data indicating the user's selection from the user terminal 30. This also applies to the second selection receiving unit 108 described below. In the example embodiment, the selection regarding whether or not second authentication is required is received on the authentication screen SC2 in the upper right corner of FIG. 3. For example, when the user selects button B21, the first selection receiving unit 107 determines that the user has selected that second authentication is required. When the user selects button B22, the first selection receiving unit 107 determines that the user has selected that second authentication is not required.

[0172] The need for second authentication can be accepted from any screen. The screen on which the user selects whether second authentication is required is not limited to the authentication screen SC2. For example, the selection of whether second authentication is required may be accepted on the payment source setting screen SC1 or another screen. When it is selected that second authentication is required, the authentication execution unit 103 executes processing for the second authentication. The processing in this case is as described in the embodiment. When it is selected that second authentication is not required, the authentication execution unit 103 executes processing for the first authentication or processing for authentication other than the first authentication and the second authentication.

[0173] The authentication system 1 of the sixth modification accepts a selection as to whether or not second authentication is required when the type of at least one of the target card and the related card is the second type. When it is selected that second authentication is required, the authentication system 1 executes processing for the second authentication. This allows the authentication system 1 to execute authentication according to the user's preferences, thereby improving user convenience.

[0174] [6-7. Variation 7] For example, the user may perform authentication using both the setting target card and the related card. The authentication system 1 of the seventh modification includes a second selection receiving unit 108. When the type of the setting target card is a predetermined type and the type of the related card is also a predetermined type, the second selection receiving unit 108 receives a selection regarding whether to perform processing for authentication using not only the setting target card but also the related card.

[0175] In the example embodiment, the predetermined type is a type that has an electronic money number. The predetermined type may be a parent card, a child card, a predetermined brand, a predetermined card company, a predetermined rank of credit card, a shopping limit upper limit equal to or greater than a threshold, or other types. The necessity of authentication using both the target card and related cards can be accepted from any screen. For example, the selection of whether authentication using both the target card and related cards is necessary may be accepted on the payment source setting screen SC1, the authentication screen SC2, or another screen.

[0176] When it is selected to perform not only authentication using the setting target card but also processing for authentication using an associated card, the authentication execution unit 103 executes processing for authentication using the setting target card and processing for authentication using an associated card. The meaning of the processing for authentication is as explained in the embodiment. These authentications may be either the first authentication or the second authentication explained in the embodiment. These authentications may be authentications other than the first authentication and the second authentication.

[0177] Note that if a user authenticates both the setting target card and the related card, some benefit may be provided to the user. For example, the payment server 10 may periodically request authentication for a user who has authenticated only either the setting target card or the related card, and may omit periodic authentication for a user who has authenticated both the setting target card and the related card. The payment server 10 may increase the top-up limit by a predetermined amount for a user who has authenticated only either the setting target card or the related card, and may increase the top-up limit by an amount greater than the predetermined amount for a user who has authenticated both the setting target card and the related card.

[0178] When the type of the setting target card is a predetermined type and the type of the associated card is also a predetermined type, the authentication system 1 of Variation 7 accepts a selection as to whether to perform processing for authentication using not only the setting target card but also the associated card. When it is selected to perform processing for authentication using not only the setting target card but also the associated card, the authentication system 1 performs authentication using the setting target card and authentication using the associated card. This allows the authentication system 1 to perform authentication according to the user's preferences, thereby improving user convenience.

[0179] [6-8. Other variations] For example, the above modifications may be combined.

[0180] In the embodiment and Modifications 1 to 7, a case where a credit card is set in a payment service is given as an example. The authentication system 1 may also execute a process for authentication when a credit card is set in a service other than a payment service. For example, the authentication system 1 may execute a process for authentication when a payment source is set in an online shopping service, an electronic ticket service, a travel reservation service, or another service. Furthermore, the authentication system 1 may execute a process for authentication when other settings, such as setting a spending limit, are made instead of setting a payment source in these services.

[0181] For example, in order to "improve user convenience while maintaining security in payments" as described in the "Problem to be Solved by the Invention" section of this disclosure, scan authentication is a suitable configuration but is not a required configuration for authentication system 1. If authentication system 1 executes a process for authentication according to the type of at least one of the target card and related cards, flexible authentication according to the type of at least one of the cards becomes possible, thereby improving user convenience while maintaining security in payments.

[0182] For example, biometric authentication, in addition to scan authentication, is known to have high security. Biometric authentication is also known to be highly convenient for users because it does not require the input of a password or the like. For example, when a user's biometric information is registered in association with a specific type of card, the authentication system 1 can improve user convenience while maintaining payment security by enabling the execution of biometric authentication that is both highly secure and convenient for users. The same applies to other authentications besides scan authentication and biometric authentication. When at least one of the cards is of a second type, the authentication system 1 may execute an authentication process that is relatively more secure and convenient for users than when at least one of the cards is of a first type.

[0183] For example, the functions described as being realized by the payment server 10 may be shared among multiple computers in the authentication system 1. In this case, each of the multiple computers may transmit its own processing results to the other computers, thereby realizing the sharing of functions. For example, the functions described as being realized by the payment server 10 may be realized by the electronic money server 20. Conversely, the functions described as being realized by the electronic money server 20 may be realized by the payment server 10.

[0184] [7. Notes] For example, the authentication system according to the present disclosure can also be configured as follows. (1) a type determination unit that, when setting is made for a setting target card for payment in a predetermined service, determines the type of at least one of the setting target card and an associated card related to the setting target card; an authentication execution unit that executes a process for authentication according to the type of the at least one card; a setting reflecting unit that reflects the setting when the authentication is performed; Authentication system including. (2) the type determination unit determines the type of the at least one card by determining whether or not additional information about the at least one card is present; the authentication execution unit executes a process for authentication according to the presence or absence of the additional information of the at least one card. (1) An authentication system according to the present invention. (3) The authentication execution unit When it is determined that the at least one card does not have the additional information, a process for first authentication is performed in which the additional information is not used; When it is determined that the at least one card has the additional information, a process for second authentication is executed in which the additional information is used. (2) An authentication system according to the present invention. (4) When it is determined that the at least one card has the additional information, the authentication execution unit executes a process for the second authentication based on the additional information acquired by reading the at least one card with a user terminal. (3) An authentication system according to the present invention. (5) the authentication system further includes a user identification information acquisition unit that acquires user identification information capable of identifying a logged-in user based on the login from the user terminal; The authentication execution unit Identifying user identification information associated with the supplementary information acquired by the user terminal; executes a process for the second authentication based on the user identification information acquired based on the login and the user identification information associated with the additional information acquired by the user terminal; (4) An authentication system according to the present invention. (6) the type determination unit determines whether or not the additional information exists for each of the setting target card and the related card; the authentication execution unit executes the process for the second authentication when it is determined that the related card has the additional information even if it is determined that the setting target card does not have the additional information. An authentication system according to any one of (3) to (5). (7) the setting target card is a personal card of the user who performs the setting, the related card is a family card of the user's family, the authentication execution unit executes the process for the second authentication when it is determined that the family card has the additional information even if it is determined that the principal card does not have the additional information. (6) An authentication system according to the present invention. (8) Even if it is determined that the setting target card has the additional information, the authentication execution unit can execute the process for the second authentication based on the additional information acquired by the user terminal reading the related card. An authentication system according to any one of (3) to (7). (9) The authentication execution unit If the additional information of the at least one card is invalid, a process for the first authentication is performed; If the additional information of the at least one card is valid, a process for the second authentication is executed. An authentication system according to any one of (3) to (8). (10) the type determination unit determines the types of the setting target card and the related card based on a parent-child relationship between the setting target card and the related card; An authentication system according to any one of (1) to (9). (11) the authentication execution unit executes a plurality of processes for the authentication when it is determined that the type of the at least one card is a child. (10) An authentication system according to (10). (12) the authentication system further includes a payment execution unit that, when the expiration date of the setting target card to which the setting is reflected is updated, is capable of executing payment based on the setting without requiring re-authentication; An authentication system according to any one of (1) to (11). (13) the authentication system further includes an authentication application unit that, when the authentication is executed, applies the authentication to a service other than the predetermined service. An authentication system according to any one of (1) to (12). (14) The authentication execution unit If the type of the at least one card is a first type, a process for first authentication is performed; When the type of the at least one card is a second type different from the first type, a process for second authentication different from the first authentication can be executed; the authentication system further includes a first selection receiving unit that receives a selection regarding whether the second authentication is required when the type of the at least one card is the second type; the authentication execution unit executes a process for the second authentication when it is selected that the second authentication is necessary. An authentication system according to any one of (1) to (13). (15) the type determination unit determines the type of each of the setting target card and the related card; the authentication system further includes a second selection receiving unit that, when the type of the setting target card is a predetermined type and the type of the associated card is also the predetermined type, receives a selection regarding whether to execute not only the authentication using the setting target card but also a process for the authentication using the associated card; the authentication execution unit executes the process for authentication using the setting target card and the process for authentication using the related card when it is selected to execute not only the authentication using the setting target card but also the process for authentication using the related card. An authentication system according to any one of (1) to (14). [Explanation of symbols]

[0185] 1 authentication system, N network, 10 payment server, 11, 21, 31 control unit, 12, 22, 32 memory unit, 13, 23, 33 communication unit, 20 electronic money server, 30 user terminal, 34 operation unit, 35 display unit, 36 photographing unit, 100 data storage unit, 101 user identification information acquisition unit, 102 type determination unit, 103 authentication execution unit, 104 setting reflection unit, 105 payment execution unit, 106 authentication application unit, 107 first selection acceptance unit, 108 second selection acceptance unit, 200 data storage unit, 201 receiving unit, 202 transmitting unit, 300 data storage unit, 301 reading unit, 302 transmitting unit, B10, B20, B21, B22, B31, B32 button, DB1 user database, DB2 electronic money database, F30 input form, M23 Modal, SC1 payment source setting screen, SC2 authentication screen, SC3 card company screen.

Claims

1. a determination unit that, when a setting is made for a card to be set for payment in a predetermined service, determines whether or not additional information is present for the card to be set; an authentication execution unit that executes a process for the authentication in accordance with the presence or absence of the additional information, when the setting is performed; a setting reflecting unit that reflects the setting when the authentication is performed; Authentication system including.

2. the determination unit determines whether the additional information includes electronic money identification information that can identify electronic money or point identification information that can identify points; the authentication execution unit executes a process for authentication depending on whether or not the electronic money identification information or the point identification information exists. The authentication system of claim 1 .

3. The authentication execution unit If it is determined that the additional information is not present, a process for first authentication is performed in which the additional information is not used; If it is determined that the additional information is present, a process for second authentication is executed in which the additional information is used.

3. The authentication system according to claim 1 or 2.

4. When it is determined that the additional information is present, the authentication execution unit executes a process for the second authentication based on the additional information acquired by the user terminal reading the setting target card. The authentication system according to claim 3 .

5. the authentication system further includes a user identification information acquisition unit that acquires user identification information capable of identifying a logged-in user based on the login from the user terminal; The authentication execution unit Identifying user identification information associated with the supplementary information acquired by the user terminal; executes a process for the second authentication based on the user identification information acquired based on the login and the user identification information associated with the additional information acquired by the user terminal; The authentication system according to claim 4 .

6. the determination unit determines whether or not there is the additional information of the setting target card and whether or not there is additional information about a related card related to the setting target card; the authentication execution unit executes the process for the second authentication when it is determined that the related card has the additional information even if it is determined that the setting target card does not have the additional information. The authentication system according to claim 3 .

7. the setting target card is a personal card of the user who performs the setting, the related card is a family card of the user's family, the authentication execution unit executes the process for the second authentication when it is determined that the family card has the additional information even if it is determined that the principal card does not have the additional information. The authentication system of claim 6.

8. Even if it is determined that the setting target card has the additional information, the authentication execution unit can execute the process for the second authentication based on the additional information acquired by reading the associated card related to the setting target card with a user terminal. The authentication system according to claim 3 .

9. The authentication execution unit If the additional information is invalid, the processing for the first authentication is performed; If the additional information is valid, the process for the second authentication is executed. The authentication system according to claim 3 .

10. the authentication system further includes a payment execution unit that, when the expiration date of the setting target card to which the setting is reflected is updated, is capable of executing payment based on the setting without requiring re-authentication; 3. The authentication system according to claim 1 or 2.

11. the authentication system further includes an authentication application unit that, when the authentication is executed, applies the authentication to a service other than the predetermined service.

3. The authentication system according to claim 1 or 2.

12. a determination step of determining whether or not additional information about a setting target card is present when setting the setting target card for payment in a predetermined service is performed; an authentication execution step for executing a process for the authentication depending on whether or not the additional information is present, in which the authentication is performed when the setting is performed; a setting reflection step of reflecting the setting when the authentication is performed; Authentication methods, including:

13. a determination unit that determines whether or not additional information is present on a setting target card when setting is performed on the setting target card for payment in a predetermined service; an authentication execution unit that executes a process for the authentication in accordance with the presence or absence of the additional information, when the setting is performed; a setting reflecting unit that reflects the setting when the authentication is performed; A program that allows a computer to function as a

Images