Authentication system, authentication method and program

Abstract

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

Description

[Technical field]

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

[0002] Conventionally, cards (e.g., credit cards or debit cards) that can be used for payments in a given service (e.g., a payment service or an online shopping service) are known. In 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 improving security in payments. For example, Patent Document 1 describes a technology that improves security by requiring users to input multiple pieces of authentication information such as a password and a security code. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2008-015924 A Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the technology of Patent Document 1, the user needs to input multiple pieces of authentication information, which is cumbersome. Therefore, although the technology of Patent Document 1 can increase security, it reduces user convenience. If the number of pieces of authentication information that the user needs to input can be reduced, the cumbersomeness felt by the user can be reduced, but security will be reduced. Therefore, there is a demand for improving user convenience while maintaining security.

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

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

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

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

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

[0010] The payment server 10 is a server computer of a service provider that provides a payment service to a user. The payment service is a service that performs electronic payment (cashless payment) by a user on behalf of the user. 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 a volatile memory such as a RAM and a non-volatile memory such as a flash memory. The communication unit 13 includes at least one communication interface for wired communication and wireless communication.

[0011] In this embodiment, an example is given in which the payment service corresponds to the specified service. Therefore, the description of the payment service can be read as the specified service. The specified service may be any service in which a payment is made based on the setting target card 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 electronic book service, a video distribution service, a music distribution service, a financial service, a reservation service for various stores or facilities such as a hair salon or a restaurant, or other services.

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

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

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

[0015] The programs stored in the storage units 12, 22, and 32 may be supplied to the payment server 10, the electronic money server 20, or the user terminal 30 via the network N. Also, the programs stored in a computer-readable information storage medium may be supplied to the payment server 10, the electronic money server 20, or the user terminal 30 via a reading unit (e.g., an optical disk drive or a 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.

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

[0017] [2. Overview of the authentication system] In this embodiment, the user operates the user terminal 30 to use the payment service. The payment means available to the user in the payment service may be various known payment means. For example, the payment means available to the user in 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 financial institution other than a financial institution, a debit card, crypto assets, a wallet, or other means.

[0018] In this embodiment, an example is taken 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.

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

[0020] The payment flow in the payment service may be a known flow. For example, a payment may be executed in which the user terminal 30 reads a code of the affiliated store, instead of a payment terminal of the affiliated store reads a code of the user terminal 30. For example, a payment may be executed in which no code is used and the payment is completed only by operating the user terminal 30. Payment in the payment service may be not only a payment in a brick-and-mortar store, but also an online payment.

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

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

[0023] Hereinafter, information used for the additional function is referred to as additional information. In this embodiment, the electronic money number capable of identifying IC card type electronic money corresponds to the additional information. The electronic money number is written in the IC chip of a credit card having the additional function of IC card type electronic money. If the credit card has a memory other than the IC chip, the electronic money number may be written in the memory. The electronic money number may be formed on the face of the credit card. Forming 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 a two-dimensional code.

[0024] In this embodiment, the user cannot use electronic money as an additional function of a credit card in 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 a physical credit card (a so-called plate card) read by the payment terminal of the affiliated store's payment terminal instead of the user terminal 30 to identify the electronic money (e.g., electronic money number). When issuing a credit card, the user may be allowed to select whether or not to include the additional function. Note that identification information of the electronic money attached to a physical credit card having the electronic money function may be registered in the payment app, and the electronic money may be used from the payment app.

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

[0026] For example, the 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). The associated card may be any card that is related to the card to be set. The associated card is not limited to a credit card. For example, the associated card may be an electronic money card without a credit function, a point card, a prepaid card, a membership card, an identification card, an entrance / exit card, a cash card, or any other card. The associated card may be a card that is directly or indirectly associated with the card to be set.

[0027] For example, a user needs to successfully complete a predetermined authentication to set a target card as a payment source in a payment app. In this embodiment, the authentication method differs depending on the presence or absence of an electronic money number of at least one of the target card and related cards. For example, when there is no electronic money number, authentication such as 3D Secure authentication or security code (CVV: Card Verification Value) authentication is executed. Hereinafter, authentication when there is no electronic money number is referred to as first authentication. The first authentication may be a combination of multiple authentications such as 3D Secure authentication and security code authentication.

[0028] On the other hand, when the electronic money number of at least one of the setting target card and the related card is present, authentication such as scan authentication that requires reading at least one of the setting target card and the related card is executed. Hereinafter, authentication when the 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 the first authentication and scan authentication corresponds to the second authentication. Each of the first authentication and the second authentication may be any authentication. Each of the first authentication and the second authentication is not limited to the example of this embodiment.

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

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

[0031] For example, if the electronic money numbers of the target card and the related cards are not available, the user terminal 30, under the control of the payment server 10, displays the authentication screen SC2 in the upper right of Fig. 2 on the display unit 35. Since the electronic money numbers of the target card and the related cards are not available, the payment server 10 cannot execute the process for the second authentication. For this reason, a notification is displayed that the first authentication will be executed, as shown in the authentication screen SC2 in the upper right of Fig. 2.

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

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

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

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

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

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

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

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

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

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

[0042] FIG. 5 is a diagram showing an example of the user database DB1. The user database DB1 is a database in which various information related to each of a plurality of users is stored. For example, the user database DB1 stores a user ID, a login password, a user's name, payment source information, payment method information, and authentication result information. Any information related to a user may be stored in the user database DB1. The information stored in the user database DB1 is not limited to the example of FIG. 5. For example, information on points and online electronic money available from a payment application, and terminal identification information capable of identifying the user terminal 30 may be stored in the user database DB1.

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

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

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

[0046] For example, the terminal identification information of the user terminal 30 may correspond to the user identification information. The terminal identification information may be the serial ID (individual identification information) of the user terminal 30, the SIM number, an ID issued by the payment server 10, or other information. When the terminal identification information corresponds to the user identification information, when the same user uses multiple user terminals 30, the user identification information is different when the user logs in to the payment service from a certain user terminal 30 with his / her own user ID and when the user logs in to the payment service from another user terminal 30 with the same user ID. In addition, the user identification information is not limited to one, and multiple pieces of user identification information may be combined. For example, the user ID and the terminal identification information may be combined. When the same user uses multiple user terminals 30, if the user terminal 30 is one that is always used, the user can log in with only the user ID, but when the user logs in to the payment service with the same user ID from another user terminal 30, authentication with the terminal identification information may be required.

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

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

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

[0050] In this embodiment, the case where the user uses a credit card is taken as an example, so the payment method information indicates the credit card registered in the payment service. For example, the payment method information indicates the card company that issued the credit card, at least a part of the credit card number (the last four digits in the example of FIG. 5), the expiration date, the cardholder, or a combination of these. When the user registers multiple credit cards in 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. When cards other than credit cards can be used in the payment service, the payment method information may indicate the other cards. Examples of the 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, the payment methods that the user can use in the payment service may be credit cards, electronic money, points, bank accounts, accounts at financial institutions other than banks, accounts at financial institutions other than financial institutions, debit cards, crypto assets, wallets, or other methods.

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

[0052] In the example of Figure 5, user "Tenko Taro" has registered two cards with electronic money numbers, an "AAA card" and an "EEE card," in the payment service. User "Tenko Taro" is the parent of user "Tenko Kosuke." Child user "Tenko Kosuke" has registered an "AAA card" in the payment service, in which the bank account of parent user "Tenko Taro" is set as the debit destination. Hereinafter, a credit card in which a 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.

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

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

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

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

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

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

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

[0060] The electronic money number is an example of electronic money identification information capable of identifying electronic money. Therefore, any place where it is written "electronic money number" can be read as "electronic money identification information." The electronic money identification information is not limited to the electronic money number. For example, the electronic money identification information may be information other than a number (e.g., letters or symbols). The electronic money identification information is an example of additional information, so any place where it is written as "electronic money identification information" can also be read as "additional information."

[0061] The validity information is information indicating whether the electronic money is valid or not. 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, when fraudulent use of the electronic money occurs, the electronic money server 20 updates the validity information to indicate that the electronic money is invalid. When 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 situation in which the validity information is used will be described in Variation 1 below.

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

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

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

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

[0066] [User identification information acquisition section] The user identification information acquisition unit 101 acquires user identification information capable of identifying a logged-in user based on a login from the user terminal 30. The method of acquiring the user ID of the logged-in user can use various known methods. In this embodiment, the user ID is described as an example of user identification information capable of identifying a 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 by the user identification information acquisition unit 101 as user identification information can be read as any other user identification information.

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

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

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

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

[0071] For example, the setting for the target card may be the setting for a payment method that is the source of recharge of electronic money available on the payment app. In this case, the setting for the target card may be the payment method of the recharge source, the upper limit of the recharge amount per transaction, the upper limit of the total recharge amount in a predetermined period (e.g., one week or one month), the upper limit of the number of recharges in a predetermined period, or a combination of these. The setting for the target card may be the setting for a credit card adopted in a known payment service.

[0072] In this embodiment, the type determination unit 102 determines the type of at least one of the setting target card and the related card by determining the presence or absence of additional information on the card. For example, the type determination unit 102 determines the presence or absence of additional information on each of the setting target card and the related card. The additional information is information related to the additional function of the card. In this embodiment, since the case where the electronic money function corresponds to the additional function is taken as an example, the electronic money number capable of identifying the electronic money corresponds to the additional information. Each of the setting target card and the related card may have multiple pieces of additional information.

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

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

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

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

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

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

[0079] In the examples of Figs. 5 and 6, it is assumed that the "AAA card" of the user "Takken Taro" is not yet authenticated. It is assumed that the user "Takken Taro" attempts to set the "AAA card" as the payment source. In other words, it is assumed 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 the user ID "u00001" in the example of Fig. 6. The type determination unit 102 determines that an electronic money number exists based on the electronic money number list. In other words, the type determination unit 102 determines that each of the electronic money numbers exists for the card to be set, the "AAA card", and three related cards (the "EEE card", the "AAA card" of the child user "Takken Kosuke", and the "FFF money" IC card without a credit card function).

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

[0081] In addition, the electronic money number of the child card "AAA card" of the child user "Patent Kosuke" may be associated with the user ID "u00002" of the child user "Patent Kosuke" instead of the user ID "u00001" of the parent user "Patent Taro". In this case, even if the parent user "Patent Taro" logs into the payment service with his own user ID and reads the child card "AAA card", the second authentication will not be successful. If the child user "Patent Kosuke" logs into 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 card "AAA card" of the child user "Patent Kosuke" may be associated with either the user ID "u00001" of the parent user "Patent Taro" or the user ID "u00002" of the child user "Patent Kosuke".

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

[0083] In addition, for users "Practical Design Hideo", "Design Hanako", and "Trademark Ayaka", the electronic money number list indicates at least one electronic money number, just like for user "Patent Taro". Therefore, the type determination unit 102 determines that at least one of the setting target card and the related card has an electronic money number. For example, even if the setting 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 the "LLL card" (related card) that is not registered in the payment service, so the type determination unit 102 determines that the related card has an electronic money number.

[0084] Further, the method of determination by the type determination unit 102 may be another method. 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 executed by the electronic money server 20, not by the payment server 10. In this case, the type determination unit 102 may request the electronic money server 20 for determination result information regarding the determination result of the presence or absence of an electronic money number, instead of requesting an electronic money number list from the electronic money server 20. That is, the type determination unit 102 requests the electronic money server 20 to determine the presence or absence of an electronic money number. For example, the type determination unit 102 may determine in advance the presence or absence of an electronic money number, and store a flag indicating whether the first authentication or the second authentication is to be activated in the user database DB1 or another database. The flag may be referred to at the time of authentication.

[0085] For example, the determination result information does not indicate 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 manner, it is possible to prevent the electronic money number from being transmitted onto the network N. The type determination unit 102 may determine the presence or absence of electronic money information by referring to the determination result information.

[0086] For example, the payment server 10 may request an electronic money number list or judgment result information from a server other than the electronic money server 20. For example, the other server manages cards in an integrated manner. The other server may be a server of a card company, or may be a server of a company other than a card company. The other server transmits the electronic money number list or judgment result information to the payment server 10 by a process 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 judgment result information transmitted from the other server.

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

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

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

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

[0091] In this embodiment, the first authentication is executed mainly by the card company's computer, so the process for the first authentication is a process for making the card company's computer execute the first authentication. In the example of FIG. 2, the button B20 of the authentication screen SC2 in the upper right of FIG. 2 includes a link to the card company's screen SC3 (for example, a direct link to the card company's screen SC3, or a link for redirecting to the card company's screen SC3). The process for displaying the authentication screen SC2 including the link on the user terminal 30 corresponds to the process for the first authentication. Note that the process for the first authentication may mean that the payment server 10 itself executes the first authentication. Depending on the type of the first authentication, it may be executed by the payment server 10 itself, not by another computer such as the card company's computer, so the authentication execution unit 103 may execute the process for the first authentication by executing the first authentication itself.

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

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

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

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

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

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

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

[0099] For example, the authentication execution unit 103 executes processing for the second authentication based on a user ID acquired based on the login and a user ID associated with an 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 each other. If the authentication execution unit 103 determines that these user IDs do not match each other, it determines that the second authentication has failed. If the authentication execution unit 103 determines that these user IDs match each other, it determines that the second authentication has succeeded.

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

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

[0102] In addition, when the user "Takken Taro" succeeds in the second authentication of the "AAA card", the second authentication of the "EEE card", another credit card registered by the user "Takken Taro" in the payment service, may also be treated as being successful, since the "EEE card" is associated with the same user ID. In addition, when the user "Takken Taro" reads the "FFF Money" IC card without a credit card function with the user terminal 30, the authentication execution unit 103 may determine that the second authentication is successful.

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

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

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

[0106] For example, suppose that a malicious third party illegally obtains information such as the user ID "u00001" and the credit card number of "AAA card". Furthermore, suppose that the third party poses as the user "Patent Taro" and illegally attempts to set "AAA card" as the payment source of his / her payment application. In this case, even if the third party reads the electronic money number of a credit card at hand (a credit card other than the "AAA card" of the user "Patent Taro"), the user ID associated with the electronic money number is not the logged-in user ID "u00001". Since these user IDs do not match, the authentication execution unit 103 determines that the second authentication has failed.

[0107] The second authentication may be performed by another method. The second authentication is not limited to the example of this embodiment. For example, when 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 managed by itself, without inquiring the electronic money server 20 about the user ID associated with the electronic money number scanned by the user. As another example, the authentication execution unit 103 may request the electronic money server 20 or another computer to compare the user IDs, instead of comparing the user IDs by itself. In this case, the authentication execution unit 103 obtains data indicating the comparison result from the electronic money server 20 or another computer. The authentication execution unit 103 determines whether the second authentication is successful or not based on the data.

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

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

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

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

[0112] For example, even if it is determined that the electronic money number is not present on the principal card, the authentication execution unit 103 may execute the process for the second authentication when it is determined that the electronic money number is present on the family card. The flow of the second authentication itself is as described above. In the example of Fig. 5 and Fig. 6, even if the principal card of the user "Takken Taro" does not have an electronic money number, the second authentication can be successful with the child card, so the above process is executed. In the example of Fig. 6, the electronic money number of the child card is associated with the user ID of the parent user, but the electronic money number of the child card may be associated with the user ID of the child user. Furthermore, other information such as the credit card number of the child card may also be associated with the user ID of the parent user or with the user ID of the child user. However, since a credit card can be used only by the principal in principle, the child card is used by the child (family member). For this reason, the parent user does not use the child card in his / her own payment application in principle.

[0113] [Settings reflection section] The setting reflecting unit 104 reflects the settings for the target card when authentication is performed. Reflecting the settings means activating the settings. When 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 adding the payment source information to the user database DB1. The setting reflecting unit 104 does not reflect the settings when authentication fails. The setting determination unit reflects the settings when authentication is successful. The authentication that is the condition for whether the settings are reflected may be either the first authentication or the second authentication.

[0114] In this embodiment, the setting reflecting unit 104 changes the payment source information and the authentication result information. When the authentication result information of a credit card is changed to authenticated, the user can set the credit card as the payment source without needing to be authenticated again. The authentication is reflected not only in the setting of the payment source, 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 be set as the payment source as the charging method for the online electronic money "DDD Cash" without needing to be authenticated again.

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

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

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

[0118] [Transmitter] The transmission unit 202 transmits various data to the payment server 10 or other computers. For example, the transmission unit 202 transmits an electronic money number list to the payment server 10 or other computers. The method of generating the electronic money number list is as described above.

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

[0120] [Reading section] 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 by using the NFC function of the user terminal 30. The reading unit 301 may perform reading by using a communication function other than the NFC function, or may perform reading by using the photographing unit 36.

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

[0122] [4. Processing performed by the authentication system] Figures 7 and 8 are diagrams showing an example of processing executed in the authentication system 1. The processing in Figures 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.

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

[0124] The following describes the process when the user performs an operation to select a payment source. The user terminal 30 executes a process to display a payment source setting screen SC1 with the payment server 10 (S2). When the user selects button B10, the user terminal 30 transmits payment method information capable of identifying 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 or not the authentication result information associated with the payment method information indicates that it has been authenticated based on the user database DB1 (S5).

[0125] If it is determined in S5 that the authentication result information indicates that authentication has been performed (S5: Y), the payment server 10 executes a process for updating the payment source information with the user terminal 30 (S6), and this process ends. In this case, since authentication has already been performed, the payment source is set / changed without executing the processes from S6 onward.

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

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

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

[0129] In S12, when the payment server 10 judges that at least one of the setting target card and the related card has an electronic money number (S12: Y), the process proceeds to Fig. 8, and the payment server 10 executes a process for displaying the authentication screen SC2 in the upper right of Fig. 3 with the user terminal 30 (S16). The user terminal 30 transmits information indicating the authentication selected by the user from the first authentication and the second authentication to the payment server 10 (S17). When the payment server 10 receives the information (S18), it judges which authentication from the first authentication and the second authentication the user selected (S19).

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

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

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

[0133] [5. Summary of the embodiment] The authentication system 1 of the present embodiment determines the type of at least one of the setting target card and the related card when the setting is performed on the setting target card. The authentication system 1 executes a process for authentication according to the type of the at least one card. The authentication system 1 reflects the setting when the authentication is executed. This allows the authentication system 1 to flexibly use authentication according to the type of the at least one card, thereby improving the convenience of the user while maintaining security in payment. For example, if the type of the at least one card is a type that allows authentication that improves the convenience of the user while maintaining security, the authentication is possible. Even if the type of the at least one card is not a type that allows such authentication, the authentication system 1 executes a process for other authentication to improve security and prevent a situation in which there is no authentication means for the user to reflect the setting (for example, the setting can be reflected if the user succeeds in the first authentication), thereby improving the convenience.

[0134] Moreover, the authentication system 1 determines the type of at least one of the setting target card and the related card by determining the presence or absence of an electronic money number (an example of incidental information) for the at least one of the cards. The authentication system 1 executes a process for authentication according to the presence or absence of an electronic money number for the at least one of the cards. This allows the authentication system 1 to flexibly use different authentication methods according to the presence or absence of an electronic money number incidental to the at least one of the cards, thereby improving user convenience while maintaining security in payment. For example, if there is an electronic money number, and authentication that improves user convenience while maintaining security is possible, the authentication is possible, so the authentication system 1 can improve user convenience while maintaining security in payment. For example, the authentication system 1 does not exchange a credit card number for the essential function of the at least one of the cards during authentication, but only exchanges an electronic money number, which is incidental information for an incidental function that plays a secondary role, thereby improving security. For example, the authentication system 1 can promote the use of electronic money services (an example of services related to incidental information) by using an electronic money number (an example of incidental information) as authentication information.

[0135] Furthermore, when it is determined that at least one of the setting target card and the related card does not have an electronic money number, the authentication system 1 executes a process for the first authentication in which the electronic money number is not used. When it is determined that at least one of the setting target card and the related card has an electronic money number, the authentication system 1 executes a process for the second authentication in which the electronic money number is used. This allows the authentication system 1 to flexibly use the first authentication and the second authentication depending on the presence or absence of the electronic money number attached to the at least one card, thereby improving the user's convenience while maintaining security in payment. For example, when the second authentication has higher security and is more convenient for the user than the first authentication, the authentication system 1 executes a process for the second authentication in the case of a type for which the second authentication is possible, thereby improving the user's convenience while maintaining security in payment. The authentication system 1 can prevent a situation where the user cannot perform any authentication by executing the first authentication even if the type is not one for which the second authentication is possible, thereby improving the user's convenience while maintaining security in payment.

[0136] Furthermore, when it is determined that at least one of the setting target card and the related card has an electronic money number, the authentication system 1 executes processing for the second authentication based on the electronic money number acquired by the user terminal 30 reading the at least one of the cards. This allows the authentication system 1 to improve user convenience while maintaining security in payment. 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 the password, but scan authentication does not require the user to enter a password or the like, improving user convenience.

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

[0138] Furthermore, the authentication system 1 judges whether or not the setting target card and the related card each have an electronic money number. Even if it is judged that the setting target card does not have an electronic money number, the authentication system 1 executes processing for the second authentication when it is judged that the related card has an electronic money number. As a result, even if the setting target card that the user is trying to set does not allow the second authentication, if the related card allows the second authentication, the authentication system 1 allows the user to reflect the setting of the setting target card by the second authentication using the related card, thereby improving user convenience while maintaining security in payment.

[0139] As described above, the card to be set may be the personal card of the user who performs the setting. The related card may be the 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, the authentication system 1 executes processing for the second authentication when it is determined that the family card has an electronic money number. As a result, even if the personal card that the user is trying to set is not capable of the second authentication, if the family card is capable of the second authentication, the authentication system 1 allows the user to reflect the settings of the personal card through the second authentication using the family card, thereby maintaining security in the payment and improving user convenience.

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

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

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

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

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

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

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

[0147] 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 or not based on the validity information of the electronic money number. The electronic money server 20 or another computer transmits data indicating the determination result to the payment server 10. The payment server 10 receives the data from the electronic money server 20 or another computer. The authentication execution unit 103 may determine whether to execute processing for the first authentication or processing for the second authentication based on the data.

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

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

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

[0151] The electronic money number list of the second modification includes not only electronic money numbers but also parent-child relationship information. The type determination unit 102 determines the type of each of the setting target card and the related card 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 the 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 that the credit card is a child card, the authentication execution unit 103 executes processing for the second authentication.

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

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

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

[0155] The authentication system 1 of the second modification determines the types of the setting target card and the related card based on the parent-child relationship between the setting target card and the related card. 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 payment. For example, when a child card is used for authentication, the authentication system 1 can request authentication with higher security than when a parent card is used for authentication.

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

[0157] The third authentication is different from the second authentication. The third authentication may be the same as the first authentication, but in the third modification, it is different from the first authentication. For example, the third authentication may be attribute authentication using authentication information such as an electronic certificate, question authentication asking information such as family members' surnames, birth dates, and phone numbers, 3D secure authentication, security code authentication, or other authentication. The authentication information that is the correct answer 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 authentication information that is the correct answer.

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

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

[0160] The authentication system 1 of the third modification executes 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 a child. This allows the authentication system 1 to request authentication with higher security when the setting target card is set using a child card.

[0161] [6-4. Variation 4] For example, if the expiration date of the setting target card set as the payment source is updated, re-authentication may be requested, 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 modified example, when the expiration date of the setting target card whose setting has been reflected by the setting reflecting unit 104 is updated, the payment execution unit 105 can execute payment based on the setting without requiring re-authentication.

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

[0163] When the expiration date of the setting target card is updated, the authentication system 1 of the fourth modification can execute a settlement without requiring re-authentication, based on the setting reflected by the setting reflection unit 104. This improves user convenience because the authentication system 1 does not request the user to authenticate again even if the expiration date of the setting target card is updated.

[0164] [6-5. Variation 5] For example, the payment service may be linked to another service different from the payment service. In the fifth modification, the user can use the other service from the payment app. The other service can be paid for using a payment means registered by the user in the payment service. In the fifth modification, 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 electronic book service, a financial service, or another service. The other service may also be another payment service different from the payment service. For example, the payment service may be a payment service using a first electronic money, and the other service may be a payment service using a second electronic money.

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

[0166] The authentication system 1 includes an authentication application unit 106. When authentication is executed by the authentication execution unit 103, the authentication application unit 106 applies authentication to a transportation service. Applying authentication means that, even when a payment is executed for a user to use a transportation service, a payment means that has been authenticated in the payment service can be used without requiring further authentication. For example, setting authentication result information to be authenticated corresponds to applying authentication. As another example, setting other information that the payment server 10 refers to when a user uses a transportation service from a payment app to indicate that the information has been authenticated corresponds to applying authentication to the transportation service.

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

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

[0169] [6-6. Variation 6] For example, the authentication execution unit 103 may execute processing for the first authentication when the type of at least one of the setting target card and the related card is a first type. In the example of the embodiment, the first type is a type without an electronic money number. The first type may be a predetermined type and is not limited to the example of the 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, an upper limit of the shopping limit being less than a threshold, or another type.

[0170] For example, when the type of at least one of the setting 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 of the embodiment, the second type is a type having an electronic money number. The second type may be a predetermined type and is not limited to the example of the embodiment. For example, the second type may be a parent card. The second type may be a predetermined brand, a predetermined card company, a predetermined rank of the credit card, an upper limit of the shopping limit being equal to or greater than a threshold, or other types.

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

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

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

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

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

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

[0177] In addition, when a user authenticates both the setting target card and the related card, some kind of benefit may be given to the user. For example, the payment server 10 may periodically request authentication for a user who authenticates only either the setting target card or the related card, and may omit periodic authentication for a user who authenticates both the setting target card and the related card. The payment server 10 may increase the charge upper limit by a predetermined amount for a user who authenticates only either the setting target card or the related card, and may increase the charge upper limit by an amount greater than the predetermined amount for a user who authenticates both the setting target card and the related card.

[0178] When the type of the setting target card is a predetermined type and the type of the associated card is also a predetermined type, the authentication system 1 of the seventh modification accepts a selection as to whether or not to execute processing for authentication using the associated card in addition to authentication using the setting target card. When it is selected to execute processing for authentication using the associated card in addition to authentication using the setting target card, the authentication system 1 executes authentication using the setting target card and authentication using the associated card. This allows the authentication system 1 to execute authentication according to the user's preferences, thereby improving user convenience.

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

[0180] In the embodiment and the first to seventh modified examples, a case where a credit card is set in a payment service is taken as an example. The authentication system 1 may execute a process for authentication when a credit card is set in a service other than a payment service. For example, the authentication system 1 may execute a process for authentication when a payment source is set in an online shopping service, an electronic ticket service, a travel reservation service, or a payment source is set in other services. Furthermore, the authentication system 1 may execute a process for authentication when other settings, such as setting a maximum usage amount, are made instead of setting a payment source in these services.

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

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

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

[0184] [7. Notes] For example, the authentication system according to the present disclosure may be configured as follows. (1) a type determination unit that, when a setting is made for a setting target card for a 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 the presence or absence of additional information related to the at least one card; 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 as described in (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 a first authentication is executed 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 by a user terminal. (3) An authentication system according to the above. (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 a login from the user terminal, The authentication execution unit, Identifying user identification information associated with the auxiliary information acquired by the user terminal; execute 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 auxiliary information acquired by the user terminal. (4) An authentication system according to the present invention. (6) the type determination unit determines whether or not the additional information exists for each of the setting target card and the related card; the authentication execution unit executes the process for the second authentication when it is determined that the associated 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 personal card does not have the additional information. (6) An authentication system according to the present invention. (8) The authentication execution unit is capable of executing the process for the second authentication based on the additional information acquired by reading the associated card by the user terminal even if it is determined that the additional information is present in the setting target 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; executing a process for the second authentication when the additional information of the at least one card is valid; 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 the present invention. (12) the authentication system further includes a payment execution unit capable of executing payment based on the setting without requiring re-authentication when an expiration date of the setting target card reflecting the setting is updated; An authentication system according to any one of (1) to (11). (13) The authentication system further includes an authentication application unit that applies the authentication to a service other than the predetermined service when the authentication is executed. An authentication system according to any one of (1) to (12). (14) The authentication execution unit, performing a process for a first authentication when the type of the at least one card is a first type; When the type of the at least one card is a second type different from the first type, a process for a 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 or not 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 receives a selection as to whether or not to execute a process for the authentication using the related card in addition to the authentication using the setting target card when the type of the setting target card is a predetermined type and the type of the related card is also the predetermined type, the authentication execution unit executes the process for the authentication using the setting target card and the process for the 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 the authentication using the related card. An authentication system according to any one of (1) to (14). [Explanation of symbols]

[0185] 1 Authentication system, N Network, 10 Payment server, 11, 21, 31 Control unit, 12, 22, 32 Memory unit, 13, 23, 33 Communication unit, 20 Electronic money server, 30 User terminal, 34 Operation unit, 35 Display unit, 36 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 reception unit, 108 Second selection reception 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 issuer screen.

Claims

1. a type determination unit that, when a setting is made for a setting target card for a 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 the presence or absence of additional information related to the at least one card; 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. The authentication system according to claim 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 a first authentication is executed without using the additional information; When it is determined that the at least one card has the additional information, a process for a second authentication is executed in which the additional information is used. The authentication system according to claim 2 .

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 by a user terminal. The authentication system according to claim 3.

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

6. the 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 associated 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 claims 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 personal card does not have the additional information. The authentication system according to claim 6.

8. The authentication execution unit is capable of executing the process for the second authentication based on the additional information acquired by reading the associated card by the user terminal even if it is determined that the additional information is present in the setting target card. An authentication system according to any one of claims 3 to 5.

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; executing a process for the second authentication when the additional information of the at least one card is valid; An authentication system according to any one of claims 3 to 5.

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 claims 1 to 5.

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. The authentication system according to claim 10.

12. the authentication system further includes a payment execution unit capable of executing a payment based on the setting without requiring re-authentication when an expiration date of the setting target card reflecting the setting is updated; An authentication system according to any one of claims 1 to 5.

13. The authentication system further includes an authentication application unit that applies the authentication to a service other than the predetermined service when the authentication is executed. An authentication system according to any one of claims 1 to 5.

14. The authentication execution unit, executing a process for a first authentication when the type of the at least one card is a first type; When the type of the at least one card is a second type different from the first type, a process for a 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 or not 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 claims 1 to 5.

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 receives a selection as to whether or not to execute a process for the authentication using the related card in addition to the authentication using the setting target card when the type of the setting target card is a predetermined type and the type of the related card is also the predetermined type, the authentication execution unit executes the process for the authentication using the setting target card and the process for the 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 the authentication using the related card. An authentication system according to any one of claims 1 to 5.

16. a type determination step of determining the type of at least one of a setting target card and a related card related to the setting target card when a setting is made for a setting target card for a payment in a predetermined service; an authentication execution step of executing a process for authentication according to the type of the at least one card; a setting reflection step of reflecting the setting when the authentication is performed; Authentication methods, including:

17. a type determination unit that, when a setting is made for a setting target card for settlement in a predetermined service, determines a 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; A program that makes a computer function as a

Images