JP7724261B2 - Authentication system, authentication method, and program - Google Patents

Description

This disclosure relates to an authentication system, an authentication method, and a program.

Conventionally, cards (e.g., credit cards or debit cards) that can be used to make payments in certain services (e.g., payment services or online shopping services) are known. With such services, fraudulent activities such as impersonation or phishing scams by malicious third parties have become a problem. For this reason, there is a demand for improved payment security. For example, Patent Document 1 describes a technology that improves security by requiring users to enter multiple pieces of authentication information, such as a password and a security code.

Japanese Patent Application Laid-Open No. 2008-015924

However, with the technology of Patent Document 1, users are required to enter multiple pieces of authentication information, which is cumbersome. As a result, while the technology of Patent Document 1 can increase security, it reduces user convenience. Reducing the amount of authentication information that users must enter can reduce the cumbersomeness experienced by users, but security will also decrease. For this reason, there is a demand for improving user convenience while maintaining security.

One of the goals of this disclosure is to improve user convenience while maintaining payment security.

The authentication system disclosed herein 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 a related card related to the card to be set up; an authentication execution unit that executes processing for authentication according to the type of at least one of the cards; and a setting reflection unit that reflects the settings when the authentication is executed.

This disclosure makes it possible to maintain payment security while improving user convenience.

FIG. 1 illustrates an example of a hardware configuration of an authentication system. FIG. 10 is a diagram illustrating an example of first authentication. FIG. 10 is a diagram illustrating an example of second authentication. FIG. 2 is a diagram illustrating an example of functions realized in the authentication system. FIG. 2 is a diagram illustrating an example of a user database. FIG. 2 is a diagram illustrating an example of an electronic money database. FIG. 10 is a diagram illustrating an example of processing executed in the authentication system. FIG. 10 is a diagram illustrating an example of processing executed in the authentication system. FIG. 10 is a diagram illustrating an example of a function in a modified example.

[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 the 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.

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.

In this embodiment, an example is given in which the payment service corresponds to the specified service. Therefore, the term "payment service" can be read as "specified service." The specified service may be any service in which payment occurs based on the target card to be set, as described below. The specified service is not limited to a payment service. For example, the specified 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 hair salons and restaurants, or other services.

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 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.

The user terminal 30 is a user's computer. For example, the user terminal 30 is a smartphone, tablet, personal computer, or wearable device. While 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 memory unit 32, a communication unit 33, an operation unit 34, a display unit 35, and a photographing unit 36.

For example, the hardware configurations of the control unit 31, memory unit 32, and communication unit 33 may be similar to those of the control unit 11, memory unit 12, and communication unit 13, respectively. In this embodiment, the communication unit 33 is capable of near field communication (NFC). 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 an LCD or organic EL display. The image capture unit 36 includes at least one camera.

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

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 shown in Figure 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 Figure 1.

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

In this embodiment, an example is given of a case where 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.

For example, when a payment app is launched on the user terminal 30, the user terminal 30 displays the payment app screen on the 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 the payment terminal of a member store of the payment service, payment is executed based on the payment method set as the payment source.

The payment flow itself in the payment service may be a known flow. For example, instead of a payment where the payment terminal of the affiliated store reads a code on the user terminal 30, a payment where the user terminal 30 reads a code on the affiliated store may be executed. For example, a payment where no code is used and the payment is completed only by operating the user terminal 30 may be executed. Payment in the payment service may be made not only in a physical store, but also online.

In this embodiment, we will take as an example 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 entering information such as a credit card number through the payment app. A credit card may only function as a credit card, but it may also function as a payment method other than a credit card or have functions other than payment. Hereinafter, such functions will be referred to as additional functions.

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 a variety of well-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 the additional function of a points card, a membership card, a transportation commuter pass, an identification card, a facility admission pass, or any other function. A credit card may have multiple additional functions.

Hereinafter, information used for the additional functions will be referred to as additional information. In this embodiment, the electronic money number that can identify IC card-type electronic money corresponds to the additional information. The electronic money number is written in the IC chip of a credit card that has 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.

In this embodiment, the user cannot use electronic money as an additional function of a credit card for payments made from a payment app. In other words, to use electronic money as an additional function of a credit card, the user must have the electronic money identification information (e.g., electronic money number) read from a payment terminal at an affiliated store using a physical credit card (a so-called card plate), rather than a user terminal 30. The user may be able to select whether or not to use the additional function when issuing a credit card. 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, allowing the electronic money to be used from the payment app.

Hereinafter, a credit card that is to be set as the payment source in a payment app will be referred to as the "set target card." A set target card may have cards related to it. 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 considered related cards. Credit cards issued for the user's family members will also be considered related cards. In this embodiment, not only the set target card but also the related cards can have additional functions.

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

For example, to set a target card as the payment source in a payment app, a user must successfully complete a specified authentication. 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 an 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 an electronic money number is not present is referred to as first authentication. The first authentication may be a combination of multiple authentication methods, such as 3D Secure authentication and security code authentication.

On the other hand, if the electronic money number of at least one of the target card and related cards is present, 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 present is referred to as second authentication. In this embodiment, an example is given in which 3D Secure authentication corresponds to first authentication and scan authentication corresponds to second authentication. Each of the first authentication and second authentication may be any authentication. Each of the first authentication and second authentication is not limited to the example in this embodiment.

Figure 2 shows 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 Figure 2, the user specifies the payment method of the payment source from among the credit card "AAA Card," the bank account "BBB Bank," and the online electronic money "DDD Cash." Although omitted from Figure 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.

For example, the user may designate a new credit card as the payment source by entering 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 credit cards pre-registered with the payment service, but may be a credit card for which the user enters 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.

For example, if the electronic money numbers of the target card and 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 in the upper right of Figure 2. Because the electronic money numbers of the target card and related cards do not exist, the payment server 10 cannot execute the process for second authentication. Therefore, a notification is displayed, as shown in the authentication screen SC2 in the upper right of Figure 2, that first authentication will be executed.

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 the password for the first authentication in input form F30 and selects button B31, the first authentication is performed. The flow of the first authentication may be similar to known authentication flows. 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.

Figure 3 is a diagram showing an example of second authentication. The example in Figure 3 differs from the example in Figure 2 in that the electronic money number of at least one of the target card and related cards is present. For example, when a user selects button B10, as shown in the upper right corner of Figure 3, the user terminal 30, under the control of the payment server 10, causes the display unit 35 to display an authentication screen SC2 indicating that second authentication is supported. Note that in the example in Figure 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.

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 Figure 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 more 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.

For example, the user terminal 30 transmits the electronic money number read using 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 Figure 3. The user can then make payments using the configured card as the payment source from the payment app.

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 Figure 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 Figure 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.

Furthermore, the electronic money function as an additional function of a credit card may only be supported by credit cards from a specific card company. In this case, if the card to be set up is a credit card from another 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.

As described above, the authentication system 1 of this embodiment determines whether an electronic money number is present on at least one of the target card and related cards. If it is determined that electronic money is present, the authentication system 1 performs the first authentication. If it is determined that electronic money is not present, the authentication system 1 performs the second authentication. This allows the authentication system 1 to improve user convenience while maintaining payment security. Details of the authentication system 1 are explained below.

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

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.

[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" field in the user database DB1 in FIG. 5 is a description for explaining this embodiment. The user database DB1 does not include a "Notes" field.

Figure 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 ID, login password, user name, 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 shown in Figure 5. For example, user database DB1 may store information on points and online electronic money that can be used from the payment app, as well as terminal identification information that can identify the user terminal 30.

A user ID is an example of user identification information that can identify a user. Therefore, any reference to a 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.

The user ID may be common to multiple services, including payment services. 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 differs 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.

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

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, the 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 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, if the user always uses the user terminal 30, they can log in using only the user ID, but when they log in to the payment service using the same user ID from another user terminal 30, authentication using the terminal identification information may also be required.

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, authentication for setting the target card is required for each user terminal 30, even if the user ID is the same. By doing this, 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 on the third party's user terminal 30, thereby further enhancing security.

Payment source information is information that identifies the payment method set as the payment source from among the multiple payment methods available to the user for 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.

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 considered a payment method that the user has registered with the payment service or payment app. The payment method can also be considered a payment method that is a candidate for payment source. This embodiment provides an example in which a user can use multiple payment methods, but a user may also be able to use only one payment method.

In this embodiment, the case where the user uses a credit card is taken as an example, and therefore the payment method information indicates the 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 Figure 5), the expiration date, the cardholder's name, or a combination of these. If the user has registered multiple credit cards with the 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 can be used with the payment service, the payment method information may indicate those 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 that the user can use 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, cryptocurrencies, wallets, or other methods.

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 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 authentication is not required for payment methods such as points or bank accounts.

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

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 user "Tenko Kosuke"'s child card "AAA Card" has an electronic money number. The parent user "Tenko Taro" also owns an IC card-type electronic money card that does not have credit card functionality.

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

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

In this embodiment, to make it easier to distinguish between cards owned by each user, different alphabets are used to name the cards, such as "AAA Card" to "LLL Card." However, a credit card with an electronic money function may also be a credit card from a specific card company. In this case, the process by the type determination unit 102, described below, to determine whether or not an electronic money number exists may be performed only if the card to be set is a credit card from that specific card company. If the card to be set is a credit card from another company, the second authentication may not be activated, and the first authentication may be activated instead.

The data storage unit 100 can also 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 to display the screens of Figures 2 and 3. The data storage unit 100 may also 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.

[3-2. Data stored in 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" field in the electronic money database DB2 in FIG. 6 is a description for 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.

Figure 6 is a diagram showing an example of electronic money database DB2. Electronic money database DB2 is a database that stores various information related to electronic money. For example, electronic money database DB2 stores user IDs, electronic money numbers, and validity information. Electronic money database DB2 only needs to store any information related to electronic money, and the information stored in electronic money database DB2 is not limited to the example shown in Figure 6. For example, if the electronic money has a credit card function, credit card information may be stored in 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 electronic money database DB2.

An electronic money number is an example of electronic money identification information that can identify electronic money. Therefore, any reference to an 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). Electronic money identification information is an example of additional information, so any reference to electronic money identification information can also be read as additional information.

The validity information is information that indicates 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 explained in Variation 1 below.

In the example of Figure 6, the user ID "u00001" of user "Takken Taro" is associated with the electronic money number of his "AAA Card," the electronic money number of his "EEE Card," the electronic money number of his "AAA Card" of child user "Takken Kosuke," and the electronic money number 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 with the payment service. The association of the user ID and electronic money number may be performed by user "Takken Taro" himself, or by a service provider, electronic money administrator, card company, or other party. This also applies to other users.

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

[3-3. Data stored in user terminal]
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.

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

[User Identification Information Acquisition Unit]
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 itself for acquiring the user ID of the logged-in user can be various known methods. In this embodiment, a 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 interpreted as any other user identification information.

For example, when a user logs in to a payment service by entering a user ID and 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 also acquire the user ID from a computer other than the user terminal 30. When a user can log in without entering a user ID and login password, the authentication information (e.g., a token, certificate, or session ID) stored in the user terminal 30 and the user ID are assumed to be 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.

[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 a related 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 related card (i.e., both the type of the setting target card and the type of the related 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 related card.

The settings for the card to be set include at least one of the following: settings for whether the card can be used or not, and settings for usage restrictions on the card to be set. In this embodiment, the example is taken of a case where the setting as a payment source (setting for whether the card can be used or not) corresponds to the settings for the card to be set. For example, if 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 settings for the payment source information correspond to the settings for the card to be set. Therefore, any section describing the settings for the payment source information can be read as settings for the card to be set.

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

For example, the settings for the card to be set may be settings for the payment method that will be used to charge electronic money that can be used on the payment app. In this case, the settings for the card to be set 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 specified period (e.g., one week or one month), the upper limit of the number of charges in a specified period, or a combination of these. The settings for the card to be set may also be settings for a credit card used in a known payment service.

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

The additional information may be any information that is attached to at least one of the target card and related cards. The additional information is not limited to electronic money numbers. 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's 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 the point card number that can identify the point card.

For example, if the card has an additional function as a membership card, the additional information may be a membership number that can identify the member. If the card has an additional function as a transportation commuter pass, 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. This embodiment cites an example in which different additional information is associated with the target card and related cards, but the same additional information may also be associated with the target card and related cards. The additional information does not have to be associated with the target card and related cards, as long as it can be attached. The target card and related cards may each be associated with multiple pieces of additional information. 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 or child card, the credit card rank (e.g., gold or platinum), the card company, brand, card design, the maximum shopping limit, the maximum cash advance limit, or other types.

In this embodiment, the type determination unit 102 requests from the electronic money server 20 an electronic money number list related to the electronic money numbers associated with the user ID of the currently logged-in user 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.

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.

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 card to be set and the associated card are of a type that does not have an electronic money number (for example, a type that does not have additional functions). If there is no associated card in the first place, the type determination unit 102 determines that the card to be set is of a type that does not have an electronic money number.

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 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 target card is of a type in which an electronic money number exists.

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

In the example of Figure 6, the electronic money number of the child card "AAA Card" of child user "Tokkosuke" is associated with the user ID "u00001" of parent user "Tokko Taro." Therefore, when child user "Tokkosuke" attempts to set 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 child card "AAA Card" does not have an electronic money number. In order for child user "Tokkosuke" to set child card "AAA Card" as the payment source, he must successfully complete the first authentication.

The electronic money number of the child user "Takken Kosuke's" child card "AAA Card" may be associated with the child user "Takken Kosuke's" user ID "u00002" rather than the parent user "Takken Taro's" user ID "u00001." In this case, even if the parent user "Takken 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 "Takken Kosuke" 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 "Takken Kosuke's" child card "AAA Card" may be associated with either the parent user "Takken Taro's" user ID "u00001" or the child user "Takken Kosuke's" user ID "u00002."

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

Note that, like user "Patent Taro," users "Practical Design Hideo," "Design Hanako," and "Trademark Ayaka" have electronic money number lists that indicate at least one electronic money number. 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 with the payment service, and therefore the type determination unit 102 determines that the related card has an electronic money number.

The type determination unit 102 may also use other methods for making the determination. 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. In other words, 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 in the user database DB1 or another database indicating whether first authentication or second authentication will be activated. The flag may be referenced during authentication.

For example, the determination result information does not indicate the presence or absence of an electronic money number, but simply indicates the presence or absence of an electronic money number. The determination result information is a first value indicating the presence of an electronic money number, or a second value indicating the absence of an electronic money number. 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 over the network N. The type determination unit 102 may determine the presence or absence of electronic money information by referencing the determination result information.

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 the card company, or a server of a company other than the card company. The other server transmits the electronic money number list or determination result information to the payment server 10 by processing similar to that of 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.

For example, if the payment server 10 stores a database similar to the electronic money database DB2, the type determination unit 102 may determine whether or not an electronic money number is present 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 obtains data from the electronic money database DB2 from the electronic money server 20 (for example, every few hours or every day) and updates the above-mentioned database. This allows the processing of the type determination unit 102 to be completed solely within the payment server 10.

If the electronic money number is not found 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 found in the group of cards associated with the user ID "u00002" of the child user "Takken Kosuke." In the example of Figure 6, such a group of cards does not exist, but if the child user "Takken Kosuke" has a card with an electronic money number, the type determination unit 102 may treat that 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, etc. Furthermore, additional information determination and second authentication may be performed for 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 prompt the user to select second authentication, and second authentication may be initiated simply by the user's selection operation.

[Authentication execution unit]
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 related card (i.e., both the type of the setting target card and the type of the related 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 related card.

The authentication process may be auxiliary processing in which the payment server 10 has another computer perform authentication, or it may mean that the payment server 10 itself performs authentication. For example, the auxiliary processing occurs when the payment server 10 displays a screen containing a link to another computer, when the payment server 10 redirects the user terminal 30 to another computer, or when the payment server 10 sends information necessary for authentication to another computer. The payment server 10 performing processing to compare authentication information (e.g., user ID, password, electronic money number, etc.) corresponds to the payment server 10 itself performing authentication processing.

In this embodiment, the first authentication is primarily 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 Figure 2, button B20 on authentication screen SC2 in the upper right corner of Figure 2 includes a link to card company screen SC3 (e.g., a direct link to card company screen SC3, or a link for redirecting to card company screen SC3). The processing for displaying authentication screen SC2 including this link on 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.

In this embodiment, the second authentication is performed primarily 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 that 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 performed by a card company's computer, as with the first authentication, or may be performed by a server other than the payment server. In other words, 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 performed by a computer other than the payment server 10 (for example, a card company's computer). The authentication execution unit 103 may acquire data indicating the execution result of the second authentication from the other computer.

Authentication according to type is authentication in which the processing content differs depending on the type. For example, if 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 this embodiment. The first authentication may be security code authentication, password authentication, biometric authentication, or other authentication. If the type determined by the type determination unit 102 is the second type, the authentication execution unit 103 executes a second authentication that is different from the first authentication. The second authentication is not limited to scan authentication as in this embodiment. The second authentication may be any authentication that is different from the first authentication. The second authentication may be any authentication that is exemplified as the first authentication and different from the first authentication. Contrary to the example in this 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.

In this embodiment, the authentication execution unit 103 executes processing for authentication depending on 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, if the type determination unit 102 determines that at least one of the cards 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, if the type determination unit 102 determines that at least one of the cards has an electronic money number, the authentication execution unit 103 executes processing for second authentication in which the electronic money number is used.

In this embodiment, the second authentication is scan authentication, so if the type determination unit 102 determines 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 obtained 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.

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 imaging unit 36. In this case, the electronic money number is assumed to be 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 obtains the electronic money number by performing image processing such as optical character recognition on the image generated by the imaging unit 36.

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 also be other information as described above. In the description of the authentication process in this embodiment, the term "user ID" can be replaced with any other user identification information.

For example, when the payment server 10 acquires an electronic money number from the user terminal 30, the authentication execution unit 103 requests the user ID associated with the electronic money number from the electronic money server 20. 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.

For example, the authentication execution unit 103 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. 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.

In the examples of Figures 5 and 6, let's assume that the "AAA Card" of user "Takken Taro" has not yet been authenticated. Let's assume that user "Takken Taro" attempts to set the "AAA Card" as the payment source. In other words, let's 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.

In the example of Figure 6, four electronic money numbers are associated with the user ID "u00001" of user "Takken Taro." In this embodiment, the second authentication will be successful no matter which card with these four electronic money numbers user "Takken Taro" reads, as the user ID matches. Therefore, the second authentication will be successful even if user "Takken Taro" reads not only the target card "AAA card" but also three related cards (the "EEE card," the "AAA card" of child user "Takken Kosuke," and the "FFF Money" IC card without credit card functionality).

In addition, if user "Takken Taro" successfully completes the second authentication for the "AAA Card," the second authentication for the "EEE Card," another credit card registered by user "Takken Taro" with the payment service, may also be treated as successful, since it is associated with the same user ID. Also, if user "Takken Taro" reads an "FFF Money" IC card without credit card functionality with user terminal 30, authentication execution unit 103 may determine that the second authentication has been successful.

Furthermore, if 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 has been 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 has been successful only when a related card with a credit card function has been 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. As another example, rather than excluding it from the authentication, the second authentication may be combined with other authentication such as attribute authentication.

In the example of Figure 6, the second authentication is not initiated for the child user "Takken Kosuke" because the electronic money number on the child card is associated with the user ID of the parent user "Takken Taro." Even if the child user "Takken Kosuke" attempts second authentication in some way, the second authentication will not be successful because the user ID associated with the electronic money number on the child card "AAA Card" belongs to the parent user "Takken Taro." For example, if second authentication is initiated solely by user selection, the child user "Takken Kosuke" selects second authentication, and second authentication is initiated. In this case, the authentication execution unit 103 determines that 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." Therefore, the authentication execution unit 103 determines that these user IDs do not match each other and determines that the second authentication has failed.

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

For example, suppose a malicious third party fraudulently obtains information such as user ID "u00001" and the credit card number of "AAA Card." Furthermore, suppose the third party masquerades as user "Takken Taro" and fraudulently attempts to set "AAA Card" as the payment source for his or her payment app. In this case, even if the third party reads the electronic money number of a credit card in hand (a credit card other than user "Takken Taro's" AAA Card), the user ID associated with that electronic money number is not the logged-in user ID "u00001." Because these user IDs do not match, the authentication execution unit 103 determines that the second authentication has failed.

Note that the second authentication may be performed by other methods. The method of performing second authentication is not limited to the example in 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 user IDs, rather than comparing 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 this data, the authentication execution unit 103 determines whether the second authentication was successful.

For example, instead of comparing user IDs, the authentication execution unit 103 may execute the second authentication by determining whether the electronic money number obtained by reading with the user terminal 30 is present in the electronic money number list. In this case, the authentication execution unit 103 determines that the second authentication has failed if the electronic money number is not present in the electronic money number list. The authentication execution unit 103 determines that the second authentication has succeeded if the electronic money number is present in the electronic money number list.

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

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

In this embodiment, the card to be set is the personal card of the user 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 for user "Takken Taro" includes the family card of his child user "Takken Kosuke." The family card is a card in whose name a family member 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.

For example, even if the authentication execution unit 103 determines that the principal card does not have an electronic money number, it may execute processing for second authentication if it determines that the family card does have 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, 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.

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

In this embodiment, the setting reflection 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 that 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.

[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 member 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.

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

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

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

[3-6. Other functions implemented in 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.

[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 imaging unit 36.

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

[4. Processing Executed in 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 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.

As shown in FIG. 7, when the payment app is launched, the user terminal 30 executes a login process with the payment server 10 to allow 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 memory unit 12. As mentioned above, a login process may be executed in which the entry of the user ID and login password is omitted. This login process itself may be a known process.

The following describes the processing that occurs when a 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 identifies 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).

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 processing from S6 onwards.

If it is determined in S5 that the authentication result information does not indicate that authentication has been completed (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).

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

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

If the payment server 10 determines in S12 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, where the payment server 10 executes processing with the user terminal 30 to display the authentication screen SC2 in the upper right corner of FIG. 3 (S16). The user terminal 30 transmits information indicating which of the first and second authentications the user selected to the payment server 10 (S17). Upon receiving this information (S18), the payment server 10 determines whether the user selected the first or second authentication (S19).

If it is determined in S19 that the user has selected first authentication (S19: First Authentication), the process proceeds to S13. If it is determined in S19 that the user has selected second authentication (S19: Second Authentication), the payment server 10 executes processing to display 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 target card or related card (S21). The user terminal 30 transmits the electronic money number read by the NFC function to the payment server 10 (S22).

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).

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 was 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 failed (S28: N), this process ends. If the second authentication failed, first authentication may be requested. If it is determined that the second authentication was successful (S28: Y), the payment source information settings are reflected (S29), and this process ends. In S29, the payment server 10 also performs processing to update the authenticated information.

5. Summary of the embodiment
In this embodiment, when a setting is made for a card to be set, the authentication system 1 determines the type of at least one of the card to be set and a related card. The authentication system 1 executes an authentication process 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 payment security. For example, if the type of the at least one card is capable of 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 capable of such authentication, the authentication system 1 executes another authentication process 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.

Furthermore, 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). Authentication system 1 then executes authentication processing depending on whether or not the at least one card has an electronic money number. This allows authentication system 1 to flexibly select authentication methods depending on whether or not the at least one card has an electronic money number, thereby enhancing user convenience while maintaining payment security. For example, if an authentication method that enhances user convenience while maintaining security is possible when an electronic money number is present, authentication system 1 enables such authentication, thereby enhancing user convenience while maintaining payment security. For example, authentication system 1 can enhance security by exchanging only the electronic money number, which is additional information for a secondary additional function, rather than exchanging a credit card number for the essential function of the at least one card during authentication, thereby enhancing security. For example, authentication system 1 can promote the use of electronic money services (an example of services related to additional information) by using the electronic money number (an example of additional information) as authentication information.

Furthermore, when it is determined that at least one of the target card and related cards does not have an electronic money number, the authentication system 1 executes processing for first authentication, which does not use the electronic money number. When it is determined that at least one of the target card and related cards has an electronic money number, the authentication system 1 executes processing for second authentication, which uses the electronic money number. This allows the authentication system 1 to flexibly use first authentication and 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 second authentication provides higher security and user convenience than first authentication, the authentication system 1 executes processing for second authentication if the type of card is capable of second authentication, thereby improving user convenience while maintaining payment security. The authentication system 1 can prevent a situation where the user is unable to perform any authentication by executing first authentication even if the type of card is not capable of second authentication, thereby improving user convenience while maintaining payment security.

Furthermore, when it is determined that at least one of the target card and 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. 3D Secure authentication or security code authentication requires the user to enter information, and the user may forget their password, but scan authentication does not require the user to enter a password, etc., improving user convenience.

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. As a result, the authentication system 1 does not need to exchange highly confidential information such as a credit card number to perform authentication, and can therefore execute authentication without leaking highly confidential information.

The authentication system 1 also determines whether or not the setting target card and related cards each have an electronic money number. Even if it determines that the setting target card does not have an electronic money number, the authentication system 1 executes processing for second authentication if it determines 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 settings of the setting target card through second authentication using the related card, thereby maintaining payment security while improving user convenience.

Also, as mentioned above, the card to be configured may be the personal card of the user performing the configuration. The related card may be a family card of the user's family. In this case, even if it is determined that the personal card does not have an electronic money number, if it is determined that the family card has an electronic money number, the authentication system 1 will execute processing for second authentication. As a result, even if second authentication is not possible with the personal card that the user is attempting to configure, 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 while improving user convenience.

Furthermore, even if the authentication system 1 determines that the target card has an electronic money number, it can execute processing for second authentication based on the additional information acquired by the user terminal 30 reading the related card. This allows the authentication system 1 to authenticate related cards that are different from the target card, further increasing user convenience. For example, even if the user does not have the target card on hand, if the user has a related card on hand, they can use the related card to complete the second authentication.

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.

Figure 9 is a diagram showing an example of functions in a modified example. As shown in Figure 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.

[6-1. Modification 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, 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.

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

The authentication execution unit 103 in variant 1 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.

In Variation 1, an example was given in which the electronic money number list includes validity information, but 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 electronic money database DB2, the authentication execution unit 103 may determine whether an electronic money number is valid based on the validity information stored in that database.

As another 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 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 first authentication or processing for second authentication based on the data.

The authentication system 1 of variant 1 executes processing for first authentication when the electronic money number of at least one of the target card and related cards is invalid. The authentication system 1 executes processing for second authentication when the electronic money number of at least one of the target card and related cards is valid. This allows the authentication system 1 to prevent 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 will not be able to impersonate the user and succeed in second authentication, and the authentication system 1 can further improve security in payments.

[6-2. Modification 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 the user database DB1, the 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.

In variant 2, parent-child relationship information indicating the relationship between parent cards and child cards is stored in electronic money database DB2. In the example of Figure 6, of the electronic money numbers associated with the user ID "u000001" of parent user "Takken Taro," parent-child relationship information indicating that the electronic money number of child user "Takken Kosuke" is associated with the electronic money number of the child card. The parent-child relationship information may also include information that can identify the parent card.

The electronic money number list of variant 2 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.

In addition, in variant example 2, 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, if 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. If at least one of the setting target card and the related card is a child card and the child card is read by the 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.

Furthermore, in Variation 2, an example was given in which the electronic money number list includes parent-child relationship information, 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 that similar database.

As another 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 the parent-child relationship information 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.

The authentication system 1 of variant 2 determines the types of the setting target card and the related cards 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.

[6-3. Modification 3]
For example, in Modification Example 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 Example 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, the determination of whether a scanned card is a child is performed after the second authentication. The determination of whether a child card having an electronic money number exists may be performed before scanning.

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 that uses authentication information such as an electronic certificate, question authentication that asks for information such as family surnames, dates of birth, and telephone 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.

For example, if the third authentication is performed primarily 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 in which the payment server 10 compares information acquired from the user terminal 30 or information associated with that 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 in which the payment server 10 confirms the validity of the electronic certificate acquired from the user terminal 30.

The third authentication may be performed primarily by a computer other than the payment server 10. In this case, the process for the third authentication is a process for having the other computer perform the third authentication. For example, the user terminal 30 includes a link to the other computer (e.g., 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.

In variant 3, the authentication system 1 executes multiple authentication processes when it is determined that the type of at least one of the target card and related cards is child. This allows the authentication system 1 to request authentication with higher security when the target card is configured using a child card.

[6-4. Modification 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, if 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.

In variant 4, even if the expiration date indicated in the payment method information stored in the user database DB1 is updated, the authentication execution unit 103 does not request re-authentication if the authentication result information indicates that the credit card has been authenticated. 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 for that credit card. Since the authentication result information for that credit card remains unchanged and indicates that the credit card has been authenticated, the payment execution unit 105 can execute the payment without re-authentication.

When the expiration date of the target card is updated, the authentication system 1 of variant 4 can execute a payment based on the settings reflected by the settings reflection unit 104 without requiring re-authentication. This allows the authentication system 1 to improve user convenience by not requiring the user to re-authenticate even when the expiration date of the target card is updated.

[6-5. Modification 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 another service. Furthermore, the other service may 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.

In variant 5, the user can charge electronic money for a transportation service from the payment app. When the user issues a charge instruction from the payment app using the 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 electronic money balance increases by the charge amount.

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 transportation-related services. Applying authentication means that when a user performs a payment to use a transportation-related service, a payment method that has been authenticated by the payment service can be used without requiring 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-related service from a payment app to indicate that it has been authenticated, which corresponds to applying authentication to the transportation-related service.

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 that should be applied has not yet been performed, and the authentication application unit 106 causes the authentication execution unit 103 to perform authentication.

In the authentication system 1 of variant 5, 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 the target card as the payment source for a payment app, it is possible to prevent further authentication from being performed to set the target card as the electronic money top-up method for transportation services, thereby saving the user time and effort.

[6-6. Modification 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 another type.

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 that has 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 credit card rank, a shopping limit upper limit above a threshold, or some other type.

The authentication system 1 includes a first selection receiving unit 107. The first selection receiving unit 107 receives a selection regarding whether 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 second authentication is required is received on the authentication screen SC2 in the upper right corner of Figure 3. For example, when the user selects button B21, the first selection receiving unit 107 determines that the selection was made regarding whether second authentication is required. When the user selects button B22, the first selection receiving unit 107 determines that the selection was made regarding whether second authentication is not required.

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. If it is selected that second authentication is required, the authentication execution unit 103 executes processing for second authentication. The processing in this case is as described in the embodiment. If it is selected that second authentication is not required, the authentication execution unit 103 executes processing for first authentication or processing for authentication other than first and second authentication.

In variant 6, the authentication system 1 accepts a selection regarding whether second authentication is required when the type of at least one of the target card and related cards 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 perform authentication according to the user's preferences, thereby improving user convenience.

[6-7. Modification 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.

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 credit card rank, a shopping limit upper limit that is equal to or greater than a threshold, or other types. The need for 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 required may be accepted on the payment source setting screen SC1, the authentication screen SC2, or another screen.

When it is selected to perform processing for authentication using not only the target card but also an associated card, the authentication execution unit 103 performs processing for authentication using the target card and processing for authentication using the associated card. The meaning of the authentication processing 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.

In addition, if a user authenticates both the setting target card and related cards, the user may receive some kind of benefit. For example, the payment server 10 may periodically request authentication from a user who has authenticated only either the setting target card or related cards, and may omit periodic authentication from a user who has authenticated both the setting target card and related cards. 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 related cards, 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 related cards.

In variant 7, when the type of the card to be set is a predetermined type and the type of the related card is also a predetermined type, the authentication system 1 accepts a selection as to whether to perform processing for authentication using not only the card to be set but also the related card. When it is selected to perform processing for authentication using not only the card to be set but also the related card, the authentication system 1 performs authentication using the card to be set and authentication using the related card. This allows the authentication system 1 to perform authentication according to the user's preferences, thereby improving user convenience.

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

In the embodiments and variants 1 to 7, an example is given of a case where a credit card is set in a payment service. The authentication system 1 may also execute authentication processing when a credit card is set in a service other than a payment service. For example, the authentication system 1 may execute authentication processing 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 authentication processing when other settings, such as setting a spending limit, are made rather than when a payment source is set in these services.

For example, in order to "enhance user convenience while maintaining security in payments" as stated 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 processing 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 enhancing user convenience while maintaining security in payments.

For example, in addition to scan authentication, biometric authentication is known to be highly secure. 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, authentication system 1 can perform biometric authentication that is both secure and convenient for users, thereby improving user convenience while maintaining payment security. The same applies to other authentication methods besides scan authentication and biometric authentication. When at least one of the cards is of the second type, authentication system 1 simply executes an authentication process that is relatively more secure and convenient for users than when at least one of the cards is of the first type.

For example, 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 sharing the functions. For example, functions described as being realized by the payment server 10 may be realized by the electronic money server 20. Conversely, functions described as being realized by the electronic money server 20 may be realized by the payment server 10.

[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.
An authentication system according to (1).
(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 (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;
(4) An authentication system according to (4).
(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 (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 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 executed;
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 related 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 related 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).

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 Photography 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 Reception unit, 202 Transmission unit, 300 Data storage unit, 301 Reading unit, 302 Transmission 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 (16)

a type determination unit that determines the type of the associated card by determining whether or not there is electronic money identification information that can identify electronic money or point identification information that can identify points as additional information related to the associated card that is related to the setting target card for payment in a payment service that the user uses from a payment app or browser installed on the user terminal;
an authentication execution unit that executes a process for authentication according to the type of the associated card , the process being based on the presence or absence of the additional information of the electronic money identification information or the point identification information of the associated card;
a setting reflecting unit that reflects settings related to the target card so that the target card can be used as a payment source or a charge source in the payment app or the browser when the authentication is performed;
Authentication system including. The authentication execution unit
If it is determined that the associated 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 associated card has the additional information, a process for second authentication is executed in which the additional information is used.
The authentication system of claim 1 . When it is determined that the associated card has the additional information, the authentication execution unit executes a process for the second authentication based on the additional information acquired by the user terminal reading the associated card.
The authentication system of claim 2 . 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 3 . 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.
The authentication system according to any one of claims 2 to 4 . 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 according to claim 5 . 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.
The authentication system according to any one of claims 2 to 4 . The authentication execution unit
If the additional information of the related card is invalid, execute a process for the first authentication;
If the additional information of the related card is valid, a process for the second authentication is executed.
The authentication system according to any one of claims 2 to 4 . a type determination unit that determines the type of at least one of a target card for setting for payment in a payment service used by a user from a payment app or browser installed on a user terminal, and an associated card related to the target card for setting, based on a parent-child relationship between the target card and the associated 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 settings related to the target card so that the target card can be used as a payment source or a charge source in the payment app or the browser when the authentication is performed;
Authentication system including. the authentication execution unit executes a plurality of processes for the authentication when it is determined that the associated card is a child.
The authentication system of claim 9 . 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;
The authentication system according to any one of claims 1 to 4 . The authentication system further includes an authentication application unit that, when the authentication is executed, applies the authentication to a service other than the payment service.
The authentication system according to any one of claims 1 to 4 . a type determination unit that determines the type of at least one of a target card for payment in a payment service used by a user from a payment app or browser installed on the user terminal and an associated card related to the 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 settings related to the target card so that the target card can be used as a payment source or a charge source in the payment app or the browser when the authentication is performed;
An authentication system comprising:
The authentication execution unit
If the at least one type 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.
Authentication system. a type determination unit that, when setting is made for a setting target card for payment in a predetermined service, determines the types of the setting target card and related cards related to the setting target card;
a second selection receiving unit that receives a selection regarding whether to execute a process for authentication using the related card in addition to authentication using the target card when the type of the target card is a predetermined type and the type of the related card is also the predetermined type;
an authentication execution unit that 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 the process for authentication using not only the setting target card but also the related card in the authentication according to the type;
a setting reflecting unit that reflects the setting when the authentication is performed;
Authentication system including. a type determination step of determining the type of the associated card by determining whether or not there is electronic money identification information capable of identifying electronic money or point identification information capable of identifying points as supplementary information related to the associated card to be set for payment in a payment service used by the user from a payment app or browser installed on the user terminal;
an authentication execution step of executing a process for authentication according to the type of the related card , the process being according to the presence or absence of the additional information of the electronic money identification information or the point identification information of the related card;
a setting reflection step of reflecting settings related to the target card so that the target card can be used as a payment source or a charge source in the payment app or the browser when the authentication is executed;
Authentication methods, including: a type determination unit that determines the type of the associated card by determining whether or not there is electronic money identification information that can identify electronic money or point identification information that can identify points as additional information related to the associated card that is related to the setting target card for payment in a payment service that the user uses from a payment app or browser installed on the user terminal;
an authentication execution unit that executes a process for authentication according to the type of the associated card , the process being according to the presence or absence of the additional information of the electronic money identification information or the point identification information of the associated card;
a setting reflecting unit that reflects settings related to the setting target card so that the setting target card can be used as a payment source or a charge source in the payment app or the browser when the authentication is executed;
A program that allows a computer to function as a