TWI911788B - Certification systems, certification methods, and application products - Google Patents

Abstract

[Problem] To maintain security during checkout while improving user convenience. [Solution] The type determination unit (102) of the authentication system (1) determines the type of at least one of the cards—the target card and related cards—when the relevant settings for the target card required for checkout of the specified service are configured. The authentication execution unit (103) performs the necessary authentication processing corresponding to the aforementioned type of the card. The setting feedback unit (104) reflects the settings after authentication has been performed.

Description

Certification systems, certification methods, and application products

This disclosure relates to certification systems, certification methods, and software products.

Previously, cards (such as credit cards or debit cards) that could be used during checkout for pre-selected services (such as checkout services or online shopping services) were known. In such services, problems have arisen due to malicious third-party impersonation or phishing scams. Therefore, improving checkout security is in demand. For example, Patent 1 describes a technology that requires users to input multiple authentication information such as passwords and security codes to improve security. [Prior Art Documents] [Patent Documents]

[Patent Document 1] Japanese Patent Application Publication No. 2008-015924

[The problem the invention aims to solve]

However, the technology in Patent 1 requires users to input multiple authentication details, which can be inconvenient. Therefore, while Patent 1 improves security, it reduces user convenience. Conversely, reducing the amount of authentication information required from the user alleviates inconvenience but lowers security. Therefore, there is a need to balance security with improved user convenience.

One of the purposes of this disclosure is to maintain checkout security while improving user convenience. [Means used to solve the problem]

The authentication system disclosed herein includes: a category determination unit, which, when settings related to the designated object card required for checkout of a specified service are configured, determines the category of at least one of the pre-set object card and related cards; an authentication execution unit, which performs the authentication processing required for the pre-set category of the pre-set at least one card; and a setting feedback unit, which reflects the pre-set settings when the pre-authentication has been performed. [Invention Effects]

According to this disclosure, it is possible to maintain security at checkout while improving user convenience.

[1. Hardware Configuration of the Authentication System]

This illustration shows an example of an implementation of the authentication system, authentication method, and program disclosed herein. Figure 1 is a diagram illustrating an example of the hardware configuration of the authentication system. For example, authentication system 1 includes: a checkout server 10, an electronic currency server 20, and a user terminal 30. Each of the checkout server 10, the electronic currency server 20, and the user terminal 30 is connected to a network N such as the Internet or a LAN.

Checkout server 10 is a server computer that provides checkout services to users. Checkout service refers to the service of processing electronic checkouts (cashless checkouts) initiated by users. For example, checkout server 10 includes: a control unit 11, a memory unit 12, and a communication unit 13. Control unit 11 includes at least one processor. Memory unit 12 includes at least one type of volatile memory such as RAM and non-volatile memory such as flash memory. Communication unit 13 includes a communication interface for at least one type of communication, namely wired communication and wireless communication.

In this embodiment, the example given is that the checkout service is equivalent to the designated service. Therefore, the place listed as "checkout service" can be replaced with the designated service. The designated service is any service that involves checkout based on the designated card, as described later. The designated service is not limited to checkout services. For example, the designated service can also be: online shopping service, e-ticket service, travel reservation service, e-book service, video streaming service, music streaming service, financial service, reservation service for various stores or facilities such as beauty salons or restaurants, or other services.

The electronic currency server 20 is a server computer for managing electronic currencies. In this embodiment, an example is given where the electronic currency manager is different from the service provider, but the electronic currency manager can also be the same as the service provider. For example, the electronic currency server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configuration of the control unit 21, memory unit 22, and communication unit 23 can be the same as that of the control unit 11, memory unit 12, and communication unit 13, respectively.

User terminal 30 is a user's computer. For example, user terminal 30 can be a smartphone, tablet, personal computer, or wearable terminal. Although only one user terminal 30 is shown in Figure 1, there can be multiple user terminals 30 for multiple users. For example, user terminal 30 includes: a control unit 31, a memory unit 32, a communication unit 33, an operation unit 34, a display unit 35, and a camera unit 36.

For example, the hardware configuration of the control unit 31, memory unit 32, and communication unit 33 can be the same as that of the control unit 11, memory unit 12, and communication unit 13, respectively. In this embodiment, the communication unit 33 is capable of NFC (Near Field Communication). The user terminal 30 may also be different from the communication unit 33 and contain an IC chip capable of NFC. The operation unit 34 is an input device such as a touch panel or buttons. The display unit 35 is a display such as a liquid crystal display or an organic EL display. The camera unit 36 contains at least one camera.

Furthermore, the programs stored in memory units 12, 22, and 32 can also be supplied to the checkout server 10, the electronic currency server 20, or the user terminal 30 via network N. Additionally, programs stored in computer-readable information memory media can also be supplied to the checkout server 10, the electronic currency server 20, or the user terminal 30 via a read unit of the information memory media (such as a CD drive or memory card slot) or an input/output unit (such as a USB port) required for data input/output with external machines.

Furthermore, authentication system 1 only needs to contain at least one computer. The hardware configuration of authentication system 1 is not limited to the example in Figure 1. For example, authentication system 1 may also contain only checkout server 10. In this case, electronic currency server 20 and user terminal 30 may also exist outside of authentication system 1. For example, authentication system 1 may also contain only checkout server 10 and electronic currency server 20. In this case, user terminal 30 exists outside of authentication system 1. Authentication system 1 may also contain computers not shown in Figure 1.

[2. Overview of the Authentication System] In this embodiment, the user operates a user terminal 30 to utilize the checkout service. The checkout methods that the user can use in the checkout service are any known checkout methods. For example, the checkout methods that the user can use in the checkout service may also be credit cards, electronic currency, points, bank accounts, accounts with financial institutions other than banks, accounts with non-financial institutions, debit cards, encrypted assets, e-wallets, or other means.

In this embodiment, an example is given where the user utilizes the checkout service through an application installed on the user terminal 30 (such as a smartphone application), i.e., a checkout application. The medium through which the user utilizes the checkout service is not limited to a checkout application. For example, the medium through which the user utilizes the checkout service could also be the user terminal 30's browser, the user terminal 30's IC chip, IC card, magnetic card, a part of the user's own body, or other media.

For example, once the checkout application is launched on user terminal 30, the user terminal 30 displays the checkout application screen on display unit 35. The checkout application screen displays a code (such as a barcode or QR code) required for the user to complete the checkout using a payment method that has been set as the payment source. This code contains a temporarily identifiable user ID. Once the code is read at the checkout terminal of a participating store, the checkout will be executed based on the payment method that has been set as the payment source.

Furthermore, the checkout process itself is a known process. For example, instead of the checkout terminal of the franchisee reading the user terminal 30's code, the checkout could be performed by the user terminal 30 reading the franchisee's code. Alternatively, it could be a checkout that doesn't specifically use a code, but is completed simply by an action on the user terminal 30. The checkout process in the checkout service includes not only in-store checkouts but also online checkouts.

In this embodiment, the example given is a user using a credit card through a checkout application. The credit card can be pre-registered to the checkout service, or it can be registered by the user entering their credit card number and other information through the checkout application. A credit card may function solely as a credit card, but it may also function as a payment method other than a credit card, or have functions beyond payment. Hereinafter, these functions will be referred to as ancillary functions.

In this embodiment, the function of an electronic currency in the form of an IC card is taken as an example, which is equivalent to an ancillary function. An ancillary function can be any known function. An ancillary function is not limited to the examples in this embodiment. For example, the ancillary function of a credit card can also be: an ancillary function as a points card, a membership card, a commuter pass for transportation, an identity document, an admission pass for facilities, or other functions. A credit card can also have multiple ancillary functions.

Hereinafter, information used for ancillary functions will be referred to as ancillary information. In this embodiment, the electronic currency number used to identify IC card-type electronic currency is equivalent to ancillary information. The IC chip of a credit card with IC card-type electronic currency ancillary functions has the electronic currency number written into it. If the credit card has memory other than an IC chip, the electronic currency number can also be written into that memory. The electronic currency number can also be formed on the surface of the credit card. This formation includes not only printing but also embossing. The electronic currency number can also be formed on the surface of the credit card as a barcode or QR code.

In this embodiment, it is assumed that the user has configured the electronic currency, which is a function attached to a credit card, to be unusable during checkout transactions made through the checkout application. That is, the user is configured so that to use the electronic currency, it is not done through the user's terminal 30, but rather by having the physical credit card (the so-called SIM card) be sent to the merchant's checkout terminal to read the electronic currency's identification information (e.g., the electronic currency number). Users can also choose whether or not to include this function when issuing the credit card. Alternatively, the identification information of the electronic currency attached to a physical credit card with electronic currency functionality can be registered in the checkout application, allowing the electronic currency to be used through the checkout application.

Hereinafter, the credit card that serves as the payment source in a checkout application will be referred to as the designated card. Sometimes, a designated card may have associated cards. These associated cards will be referred to as associated cards. For example, if a user holds multiple credit cards from the same issuing company, the credit cards other than the designated card are considered associated cards. Credit cards issued to the user's family members are also considered associated cards. In this embodiment, not only the designated card but also the associated card may have supplementary functions.

For example, a linked card can also be a card that is directly or indirectly linked to the user ID of the target card (e.g., a sub-card, as described later, is further linked to the parent's user ID through the child's user ID). A linked card is any card that is related to the target card. Linked cards are not limited to credit cards. For example, a linked card can also be a card without credit functionality, such as an electronic currency card, points card, prepaid card, membership card, identity document card, entry/exit card, cash card, or other card. Furthermore, a linked card can also be a card that is directly or indirectly linked to the target card.

For example, in order to set a target card as a payment source in a checkout application, the specified authentication must be successful. In this embodiment, the authentication method differs depending on whether at least one of the target card and the associated card has an electronic currency number. For example, in the absence of an electronic currency number, authentication such as 3D security authentication or Card Verification Value (CVV) authentication is performed. Hereinafter, authentication without an electronic currency number will be referred to as first authentication. First authentication can also be a combination of multiple authentications such as 3D security authentication and CVV authentication.

On the other hand, if at least one of the target card and the associated card has an electronic currency number, then authentication such as scan authentication, which is necessary to read at least one of the target card and the associated card, is performed. Hereinafter, the authentication in the case of having an electronic currency number will be referred to as second authentication. In this embodiment, 3D security authentication is equivalent to first authentication, and scan authentication is equivalent to second authentication. Both first and second authentication can be arbitrary. The examples of first and second authentication are not limited to this embodiment.

Figure 2 illustrates an example of the first authentication. For instance, once a user performs the necessary operation to set the payment source using the checkout application, the user terminal 30 displays the payment source setting screen SC1, which allows the user to specify the payment method for the checkout. In the example of Figure 2, the user specifies the payment method to be used as the payment source from among the following: credit card "AAA Card", bank account "BBB Bank", and online electronic currency "DDD Electronic Cash". Although omitted in Figure 2, the user can also specify "EEE Card", which is set as the top-up method for online electronic currency "DDD Electronic Cash", as the payment source.

For example, users can also designate a new credit card as a payment source by entering its credit card number and other information from the payment source setting screen SC1. That is, the designated card is not limited to credit cards pre-registered with the checkout service, but can also be a credit card whose information, such as its number, has been entered by the user on the spot. Once the user designates a credit card without associated functions as a payment source and selects button B10, the checkout server 10 works in conjunction with the electronic currency server 20 to determine the presence or absence of electronic currency numbers for both the designated card and associated cards. If no associated card exists, the checkout server 10 only determines the presence or absence of the electronic currency number for the designated card.

For example, if no electronic currency numbers are set for the target card and associated cards, the user terminal 30, controlled by the checkout server 10, displays the authentication screen SC2 in the upper right corner of Figure 2 on the display unit 35. Since the electronic currency numbers for the target card and associated cards do not exist, the checkout server 10 cannot perform the processing required for the second authentication. Therefore, as shown in the authentication screen SC2 in the upper right corner of Figure 2, it will notify the user to perform the first authentication.

For example, once the user selects button B20, as shown in the lower left of Figure 2, the user terminal 30 accesses the card issuer screen SC3, which represents the website of the card issuer that issued the target card. Once the user enters the password for first authentication in input form F30 and selects button B31, first authentication is performed. The first authentication process is the same as known authentication processes. Once first authentication is successful, this is displayed in the card issuer screen SC3, as shown in the lower right of Figure 2. Once the user selects button B32, they are returned to the checkout application screen. The user can then proceed with checkout from the checkout application for the card that has been set as the payment source.

Figure 3 illustrates an example of the second authentication method. In the example of Figure 3, the presence of an electronic currency number for at least one of the target card and associated cards differs from the example of Figure 2. For instance, once the user selects button B10, as shown in the upper right corner of Figure 3, the user terminal 30, controlled by the checkout server 10, displays an authentication screen SC2 indicating support for the second authentication on the display unit 35. Furthermore, in the example of Figure 3, "FFF Coins" are electronic currencies that function as an add-on to the "AAA Card." "DDD Electronic Cash" is an online electronic currency that can be used within the checkout application.

For example, once the user selects button B21, the NFC function of the user terminal 30 will be activated. As shown in the lower left of Figure 3, the user terminal 30 displays the interactive window M23, which prompts the NFC function to read the target card, on the authentication screen SC2. The user terminal 30 reads the electronic currency code written on the target card. In addition, although details are described later, under certain conditions, the user can also successfully complete the second authentication by reading a related card with an electronic currency code.

For example, user terminal 30 sends the electronic currency code, read via NFC, to checkout server 10. Once checkout server 10 receives the electronic currency code from user terminal 30, it performs a second authentication. Upon successful second authentication, this is displayed in interactive window M23, as shown in the lower right corner of Figure 3. The user can then proceed with checkout from the checkout application for a card that has been set as the payment source.

Alternatively, if at least one of the target card and the associated card has an electronic currency number, the user can perform the first authentication once they select button B22 on the authentication screen SC2 in the upper right corner of Figure 3. The process after the user selects button B22 is the same as the process following authentication screen SC2 in the upper right corner of Figure 2. If at least one of the target card and the associated card has an electronic currency number, the user can choose between the first authentication and the second authentication.

Furthermore, the electronic currency function, as an ancillary feature of credit cards, may only support credit cards from specific issuing companies. In this case, if the target card is a credit card from another company, the first authentication can be initiated without checking the presence or absence of an electronic currency number. Moreover, the authentication processes shown in Figures 2 and 3 can be executed immediately after the user installs the checkout application on the user terminal 30. That is, the authentication in Figures 2 and 3 can be performed during the initial setup of the checkout application.

As described above, the authentication system 1 of this embodiment determines whether at least one of the target card and the associated card has an electronic currency number. Authentication system 1 performs a first authentication if electronic currency is detected. Authentication system 1 performs a second authentication if electronic currency is not detected. In this way, authentication system 1 can maintain checkout security while improving user convenience. Details of authentication system 1 are explained below.

[3. Functions Implemented in the Authentication System] Figure 4 illustrates one example of the functions implemented in authentication system 1. For example, the checkout server 10 includes: a data memory unit 100, a user identification information acquisition unit 101, a category determination unit 102, an authentication execution unit 103, a setting response unit 104, and a checkout execution unit 105. The data memory unit 100 is implemented via a memory unit 12. The user identification information acquisition unit 101, the category determination unit 102, the authentication execution unit 103, the setting response unit 104, and the checkout execution unit 105 are implemented via a control unit 11.

For example, an electronic currency server 20 includes a data memory unit 200, a receiving unit 201, and a transmitting unit 202. The data memory unit 200 is implemented using a memory unit 22. The receiving unit 201 and the transmitting unit 202 are each implemented using a control unit 21. Similarly, a user terminal 30 includes a data memory unit 300, a reading unit 301, and a transmitting unit 302. The data memory unit 300 is implemented using a memory unit 32. The reading unit 301 and the transmitting unit 302 are implemented using a control unit 31.

[3-1. Data Memory Stored by the Checkout Server] The data memory unit 100 stores the data necessary for the checkout service. For example, the data memory unit 100 stores the user database DB1. Furthermore, the "Remarks" field in the user database DB1 shown in Figure 5 is for illustrative purposes. The user database DB1 may not have a "Remarks" field.

Figure 5 is an illustration of an example of a user database DB1. The user database DB1 is a database that stores various information about multiple users. For example, the user database DB1 stores: user ID, login password, user name, payment source information, payment method information, and authentication result information. The user database DB1 only needs to store certain information about the users. The information stored in the user database DB1 is not limited to the example in Figure 5. For example, information about points and online electronic currencies that can be used from the checkout application, and terminal identification information that can be used to identify users, can also be stored in the user database DB1.

A user ID is one example of user identification information that can be used to identify a user. Therefore, the place where a user ID is recorded can be replaced with user identification information. User identification information is any information that can identify a user in some form. User identification information is not limited to a user ID. For example, user identification information can also be an email address, telephone number, code ID, or digital ID. In this embodiment, the user ID and login password are used to allow the user to log in to the checkout service.

Furthermore, the user ID can be common across multiple services, including the checkout service. For example, the user ID can be common among the checkout service provider, the electronic money manager, and the card issuer. In cases where the user ID differs across services, it is assumed that the user ID link has been obtained. For example, if the user ID link has been obtained, security can be guaranteed because authentication system 1 does not need to disclose confidential credit card information during data exchange.

For example, in addition to the user identification information required for login, there may be other user identification information that is associated with that user identification information. This other user identification information may also be common to multiple services, including the checkout service. Furthermore, if multiple services, including the checkout service, are interconnected, then the user identification information may be different for each service. In this case, it is assumed that the user identification information for one service and its relationship with the user identification information for other services are predefined in a database, etc.

For example, the terminal identification information of user terminal 30 can also be equivalent to user identification information. Terminal identification information can be: the serial number ID (personal identification information) of user terminal 30, SIM number, ID issued by the checkout server 10, or other information. When terminal identification information is equivalent to user identification information, if the same user uses multiple user terminals 30, the user identification information will be different when the user logs in to the checkout service from one user terminal 30 using their own user ID compared to when the same user logs in to the checkout service from other user terminals 30 using the same user ID. Furthermore, user identification information is not limited to one; multiple combinations are also possible. For example, the user ID can be combined with the terminal identification information. Alternatively, in the case where the same user uses multiple user terminals 30, if it is the frequently used user terminal 30, only the user ID is needed to log in. However, when the user logs in to the checkout service from other user terminals 30 using the same user ID, authentication using the terminal identification information is also required.

Furthermore, when the terminal identification information is equivalent to the user identification information, in order for a user to set a target card as a payment source, even with the same user ID, authentication is still required for each user terminal 30 to set that target card as the payment source. With this design, even if a malicious third party improperly obtains the user ID and login password, as long as authentication on the third party's user terminal 30 fails, the legitimate user's target card cannot be set as the payment source, thus enhancing security.

Payment source information refers to the information that identifies the payment method set as the payment source among the multiple payment methods that a user can use in the checkout service. The payment source payment method is the payment method used in checkout. Once the first authentication or the second authentication is successful, the payment source information is set to represent the set object card. Once the user changes the payment source payment method, the checkout server 10 sets the payment source information in a way that changes the payment method represented by the payment source information.

Payment method information refers to information about the payment methods available to a user in the checkout service. This payment method can also refer to the payment method of the user registered in the checkout service or checkout application. It can also refer to alternative payment methods as payment sources. This embodiment exemplifies a case where a user can use multiple payment methods, but a user may also use only one payment method.

In this embodiment, the example given is a user using a credit card. Therefore, the payment method information represents the credit card that has been registered with the payment service. For example, the payment method information represents: the issuing company of the credit card, at least a portion of the credit card number (the last four digits in the example of Figure 5), the expiration date, the name of the cardholder, or a combination thereof. If the user has registered multiple credit cards with the payment service or payment application, the payment method information represents the credit card number and other information of each of the multiple credit cards. If other cards besides credit cards can be used in the payment service, the payment method information can also represent those other cards. Examples of other cards are as described above. The payment method information can also represent other payment methods besides cards. The payment method information can be information related to various known payment methods. For example, the payment methods that users can use in the checkout service may include credit cards, electronic money, points, bank accounts, accounts of financial institutions other than banks, accounts of non-financial institutions, debit cards, encrypted assets, e-wallets, or other means.

The authentication result information indicates whether the credit card has been successfully authenticated. In this embodiment, users can set up payment methods whose authentication result information indicates successful authentication as the payment source, provided the payment method information is linked to their user ID. Users must authenticate payment methods whose authentication result information indicates incomplete authentication in order to set them up as the payment source. Furthermore, payment methods such as points or bank accounts do not require authentication.

In the example in Figure 5, the user "Takkyu Taro" has already registered two cards with e-currency numbers, "AAA Card" and "EEE Card," to the checkout service. The user "Takkyu Taro" is the parent of the user "Takkyu Kosuke." The child user "Takkyu Kosuke" has registered the "AAA Card," with the parent's bank account set as the debit target and the child user listed as the nominee, to the checkout service. Hereinafter, the credit card with the parent's bank account set as the debit target is called a sub-card. Sub-cards are also called family cards. Sub-cards can be issued not only to children, but also to spouses or other individuals listed as nominees.

Hereinafter, the bank account that is the same as the bank account to which the sub-card's deduction is targeted will be referred to as the target card, or the parent card. In the example in Figure 5, the credit card held by the user "Taku Taro" is the parent card. The sub-card "AAA Card" held by the child user "Taku Kosuke" has an electronic currency number. The parent user "Taku Taro" still holds an IC card-type electronic currency that does not have credit card functionality.

For example, the user "Real Case Hero" has already registered the "HHH Card" with an e-currency number to the checkout service. The only credit card held by the user "Real Case Hero" is the "HHH Card". That is, the user "Real Case Hero" only holds the designated card. The user "Real Case Hero" does not hold any related cards regardless of whether they have an e-currency number.

For example, user "意匠 花子" has already registered the "III card" with an e-currency number and the "JJJ card" without an e-currency number to the checkout service. User "商标 彩香" has already registered the "KKK card" without an e-currency number to the checkout service. User "商标 彩香" holds an "LLL card" with an e-currency number, but has not registered the "LLL card" to the checkout service.

Furthermore, in this embodiment, to easily distinguish the cards held by different users, different letters are added to the card names, such as "AAA Card" to "LLL Card." However, credit cards with electronic payment functions can also be issued by a specific card issuer. In this case, the process described later by the type determination unit 102 to determine the presence or absence of the electronic payment number is only executed when the card is a target card issued by that specific card issuer. If the card is a target card issued by other companies, the first authentication can be initiated without initiating the second authentication.

Furthermore, the data memory unit 100 can store any data. The data stored in the data memory unit 100 is not limited to the user database DB1. For example, the data memory unit 100 can also store the data necessary for the display of the screens in Figures 2 and 3. The data memory unit 100 can also store a database equivalent to the electronic currency database DB2 described later. In this case, it is assumed that the content of the equivalent database is integrated with the electronic currency database DB2 described later.

[3-2. Data Memory of the Electronic Currency Server] The data memory unit 200 stores data related to the electronic currency. For example, the data memory unit 200 stores the electronic currency database DB2. Furthermore, the "Remarks" field in the electronic currency database DB2 shown in Figure 6 is for illustrative purposes. The electronic currency database DB2 may not have a "Remarks" field. The data memory unit 200 may also store other data besides the electronic currency database DB2.

Figure 6 is an illustration of an example of an electronic currency database DB2. The electronic currency database DB2 is a database that stores various information about electronic currencies. For example, the electronic currency database DB2 stores: user ID, electronic currency number, and validity information. The electronic currency database DB2 only needs to store certain information about electronic currencies; the information stored in the electronic currency database DB2 is not limited to the example in Figure 6. For example, if it is an electronic currency with credit card functionality, the credit card information can also be stored in the electronic currency database DB2. As credit card information, information that identifies whether it is a parent card or a child card can also be stored in the electronic currency database DB2.

An electronic currency serial number is one example of electronic currency identification information that can identify electronic currency. Therefore, the place where an electronic currency serial number is recorded can be replaced by electronic currency identification information. Electronic currency identification information is not limited to an electronic currency serial number. For example, electronic currency identification information can also be other information besides a serial number (such as text or symbols). Electronic currency identification information is one example of ancillary information; therefore, the place where electronic currency identification information is recorded can be replaced by ancillary information.

Validity information is information indicating whether electronic currency is valid. For example, validity information indicates either that the electronic currency is a valid value or that it is an invalid value. Validity information is updated by the electronic currency server 20. For example, the electronic currency server 20 updates the validity information to indicate that the electronic currency is invalid when an improper use of electronic currency occurs. The electronic currency server 20 also updates the validity information to indicate that the electronic currency is invalid when it has not been used for a certain period of time. Scenarios where validity information is used are explained in Variation 1 described later.

In the example in Figure 6, the user ID "u00001" of user "Special Permit Taro" is associated with the following electronic currency numbers: the electronic currency number of the "AAA Card," the electronic currency number of the "EEE Card," the electronic currency number of the "AAA Card" of the child user "Special Permit Kosuke," and the electronic currency number of the electronic currency of an IC card without credit card functionality. In this embodiment, since the checkout service does not support electronic currency for IC cards, IC cards without credit card functionality are not registered with the checkout service. The association between user IDs and electronic currency numbers can be done by the user "Special Permit Taro" himself, or by the service provider, electronic currency administrator, card issuer, or others. This applies to other users as well.

For example, the user ID "u00002" of the user "实案　英雄" is linked to the "HHH Card" e-currency number. The user ID "u00003" of the user "意匠　花子" is linked to the "III Card" e-currency number. The user ID "u00004" of the user "商标　彩香" is linked to the "LLL Card" e-currency number. As mentioned above, the "LLL Card" is not registered in the checkout service.

[3-3. Data Memory Stories on the User Terminal] The data memory unit 300 stores the data required for the user to use the checkout service. For example, the data memory unit 300 stores the checkout application or browser required to display various screens such as the payment source settings screen SC1.

[3-4. Other Functions Implemented in the Checkout Server] For example, as examples of other functions implemented in the checkout server 10, the following are described: user identification information acquisition unit 101, category determination unit 102, authentication execution unit 103, setting response unit 104, and checkout execution unit 105.

[User Identification Information Acquisition Unit] The user identification information acquisition unit 101 acquires user identification information, which can be used to identify a logged-in user, based on login from the user terminal 30. The method for obtaining the user ID of a logged-in user can utilize various known methods. In this embodiment, the user ID is described as one example of user identification information that can be used to identify a logged-in user, but the user identification information acquired by the user identification information acquisition unit 101 can also 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 replaced with any other user identification information.

For example, when a user logs into the checkout service by entering their user ID and password on user terminal 30, the user identification information acquisition unit 101 obtains the user ID from user terminal 30. The user identification information acquisition unit 101 can also obtain the user ID from a computer other than user terminal 30. When a user can log in without entering their user ID and password, assuming that the authentication information (e.g., token, certificate, or meeting ID) stored in user terminal 30 and the user ID are linked in the user database DB1, the user identification information acquisition unit 101 obtains the user ID associated with that authentication information.

[Category Determination Unit] The category determination unit 102 determines the category of at least one of the setting object card and related cards when settings for the setting object card required for checkout are being made during the checkout service. In this embodiment, the category determination unit 102 determines the category of both the setting object card and the related cards (i.e., both the category of the setting object card and the category of the related cards). However, the category determination unit 102 may also determine only the category of the setting object card. Alternatively, for example, the category determination unit 102 may determine only the category of the related cards.

The so-called settings related to the target card refer to at least one of the settings for whether the target card can be used and the settings for restrictions on the use of the target card. In this embodiment, the setting for the target card as a payment source (the setting for whether the target card can be used) is taken as an example, as it is equivalent to the settings related to the target card. For example, payment source information indicates that, in the case of a target card, the target card is set as a payment source and can be used in the checkout service; therefore, the setting of payment source information is equivalent to the settings related to the target card. Therefore, the explanation of the settings for payment source information can be replaced with the settings related to the target card.

Furthermore, the settings related to the target card can be any settings related to the target card. The settings related to the target card are not limited to the examples of this embodiment. For example, registering the target card to the checkout service (in this embodiment, storing the payment method information of the target card in the user database DB1) is equivalent to setting the target card. For example, if the payment method information of a user's multiple credit cards is pre-registered in the user database DB1, and authentication is performed based on the credit card selected by the user from among the multiple credit cards displayed on the user terminal 30, the setting of the target card as a payment source can also be equivalent to setting the target card. In addition, the settings for the target card can also be, for example, the maximum amount that can be paid per checkout of the target card, the maximum total amount that can be paid during a certain period of time (e.g., one week or one month) of checkout of the target card, the maximum number of checkouts of the target card, the goods or services that can be purchased during checkout of the target card, or a combination of these.

For example, the settings for the target card can also be settings for a payment method that serves as a source of electronic currency for use in the checkout application. In this case, the settings for the target card can also be: the payment method for the source of the top-up, the maximum amount that can be topped up each time, the maximum total amount of top-ups over a given period (e.g., one week or one month), the maximum number of top-ups over a given period, or a combination of these. The settings for the target card can also be settings for credit cards used in known checkout services.

In this embodiment, the category determination unit 102 determines the category of at least one card by determining whether or not there is any attached information related to the card of the target card and the associated card. For example, the category determination unit 102 determines whether or not there is any attached information for each of the target card and the associated card. Attached information refers to information about the card's attached functions. In this embodiment, the case where electronic currency function is equivalent to an attached function is taken as an example, therefore, the electronic currency number that can identify electronic currency is equivalent to attached information. Each of the target card and the associated card may also have multiple pieces of attached information.

Furthermore, attached information can be any information attached to at least one of the target card and the associated card. Attached information is not limited to electronic currency numbers. For example, attached information can also be information that is directly or indirectly associated with the same user ID as the target card (e.g., a child card is further associated with the parent's user ID through the child's user ID). For example, if the attached function is a card with a points card function, then the points card number that can identify the points card can also be considered attached information.

For example, if a card functions as a membership card, the membership number that identifies the member is equivalent to the attached information. Similarly, if a card functions as a commuter pass for a transportation agency, the commuter pass number is equivalent to the commuter pass number. Attached information can also include prepaid card numbers, ETC card numbers, electronic cash card numbers, and other information related to attached functions. This embodiment illustrates a case where different attached information is linked to the target card and the associated card, but the same attached information can also be linked to both. Attached information may or may not be linked to the target card or the associated card; it simply needs to be attached. For each of the target card and associated cards, multiple pieces of additional information may be linked. In this case, a second authentication combining multiple pieces of additional information can also be performed. Furthermore, the category determined by the category determination unit 102 is not limited to the presence or absence of additional information. For example, the category determination unit 102 may also determine: whether it is a parent card or a child card, the credit card tier (e.g., gold or platinum), the issuing company, the brand, the card design, the spending limit, the cash advance limit, or other categories.

In this embodiment, the category determination unit 102 requests a list of electronic currency numbers associated with the user IDs of logged-in users obtained by the user identification information acquisition unit 101 from the electronic currency server 20. The electronic currency number list represents the electronic currency numbers associated with the user ID. If multiple electronic currency numbers are associated with a user ID, the electronic currency number list represents each of those multiple electronic currency numbers. If no electronic currency number is associated with the user ID, the electronic currency number list does not represent any information.

For example, the electronic currency server 20 receives a request for an electronic currency code list from the checkout server 10. Suppose the request contains the user ID (the user ID of the logged-in user) that is the object of the electronic currency code list generation. The electronic currency server 20, referring to the electronic currency database DB2, generates an electronic currency code list representing the electronic currency codes associated with that user ID. If the electronic currency code associated with the user ID does not exist, the electronic currency server 20 generates an electronic currency code list without any information. The electronic currency server 20 then sends the electronic currency list to the checkout server 10.

For example, checkout server 10 receives a list of electronic currency codes from electronic currency server 20. Category determination unit 102 determines whether an electronic currency code exists in the electronic currency code list. If no electronic currency code exists in the electronic currency code list, category determination unit 102 determines that there is no electronic currency code associated with the user ID. That is, in this case, category determination unit 102 determines that both the target card and the associated card are categories without electronic currency codes (e.g., categories without attached functions). If the associated card does not exist from the beginning, then category determination unit 102 determines that the target card is a category without electronic currency codes.

For example, if the category determination unit 102 finds an electronic currency number in the electronic currency number list, it determines that there is an electronic currency number associated with the user ID. That is, in this case, the category determination unit 102 determines that at least one of the target card and the associated card is a category with an electronic currency number (e.g., a category with attached functions). If the associated card does not exist from the beginning, the category determination unit 102 determines that the target card is a category with an electronic currency number.

In the examples of Figures 5 and 6, suppose the user "Takkyu Taro's" "AAA Card" is unauthenticated. Suppose the user "Takkyu Taro" attempts to set the "AAA Card" as a payment source. That is, suppose the "AAA Card" is the target card. In this case, the electronic currency number list indicates the four electronic currency numbers associated with the user ID "u00001" in the example of Figure 6. The category determination unit 102 determines that an electronic currency number exists based on the electronic currency number list. That is, the category determination unit 102 determines that the electronic currency numbers of the target card "AAA card", the three related cards ("EEE card", the "AAA card" of the child user "Special Permit Kosuke", and the IC card of "FFF Coin" without credit card function) are present.

In the example of Figure 6, the electronic currency number of the child user "Special Permit Kosuke's" sub-card "AAA Card" is associated with the user ID "u00001" of the parent user "Special Permit Taro". Therefore, if the child user "Special Permit Kosuke" attempts to set the sub-card "AAA Card" as a payment source, the electronic currency number list will not contain any information. In this case, the category determination unit 102 determines that the sub-card "AAA Card" has no electronic currency number. In order for the child user "Special Permit Kosuke" to set the sub-card "AAA Card" as a payment source, the first authentication must be successful.

Furthermore, the electronic currency number of the child user "Special Permit Kosuke's" sub-card "AAA Card" can be linked not to the parent user "Special Permit Taro's" user ID "u00001", but to the child user "Special Permit Kosuke's" user ID "u00002". In this case, even if the parent user "Special Permit Taro" logs into the checkout service with their own user ID and reads the sub-card "AAA Card", the second authentication will still fail. Once the child user "Special Permit Kosuke" logs into the checkout service with their own user ID and reads the sub-card "AAA Card", the second authentication will succeed. Furthermore, the credit card number and other information of the child user "Special Permit Kosuke"’s sub-card "AAA Card" can also be linked to either the user ID "u00001" of the parent user "Special Permit Taro" or the user ID "u00002" of the child user "Special Permit Kosuke".

Furthermore, if the electronic currency number of the child user "Special Permit Kosuke's" sub-card "AAA Card" is linked to the child user "Special Permit Kosuke's" user ID "u00002", it is further possible that the child user "Special Permit Kosuke's" user ID "u00002" is linked to the parent user "Special Permit Taro's" user ID "u00001". In this case, since the electronic currency number of the child user "Special Permit Kosuke's" sub-card "AAA Card" is indirectly linked to the parent user "Special Permit Taro's" user ID "u00001", further authentication may be required, as described in Variation Example 3 below. In addition, for example, if the information such as the credit card number of the child user "Special Permit Kosuke's" sub-card "AAA Card" is associated with the user ID "u00002" of the child user "Special Permit Kosuke", then further, the user ID "u00002" of the child user "Special Permit Kosuke" can be associated with the user ID "u00001" of the parent user "Special Permit Taro".

Furthermore, users "Real Case Hero", "Designer Hanako", and "Trademark Ayaka" all have electronic currency number lists similar to user "License Taro", indicating at least one electronic currency number. Therefore, the category determination unit 102 determines that at least one of the target card and the associated card has an electronic currency number. For example, even if the target card for user "Trademark Ayaka" does not have an electronic currency number, the user ID "u00005" of user "Trademark Ayaka" has an electronic currency number associated with an "LLL Card" (associated card) that has not yet been registered to the checkout service. Therefore, the category determination unit 102 determines that the associated card has an electronic currency number.

Furthermore, the determination method used by the category determination unit 102 can also be other methods. The determination method used by the category determination unit 102 is not limited to the examples of this embodiment. For example, the determination of the presence or absence of an electronic currency number may not be performed by the checkout server 10, but by the electronic currency server 20. In this case, the category determination unit 102 may not request an electronic currency number list from the electronic currency server 20, but rather request determination result information regarding the presence or absence of an electronic currency number. That is, the category determination unit 102 entrusts the electronic currency server 20 with the determination of the presence or absence of electronic currency numbers. For example, the category determination unit 102 can also determine in advance whether an electronic currency number exists and store a flag indicating whether to initiate the first or second authentication in the user database DB1 or another database. The flag can be referred to during authentication.

For example, the determination result information does not represent the electronic currency number, but simply indicates whether or not an electronic currency number exists. The determination result information is either a first value indicating the presence of an electronic currency number, or a second value indicating the absence of an electronic currency number. The electronic currency server 20 sends the determination result information to the checkout server 10. The checkout server 10 receives the determination result information from the electronic currency server 20. In this way, the electronic currency number can be prevented from being sent on the network N. The category determination unit 102 can also determine the presence or absence of electronic currency information by referring to the determination result information.

For example, checkout server 10 can also request electronic currency number lists or determination result information from servers other than electronic currency server 20. For example, these other servers might be servers that centrally manage cards. These other servers could be servers of card issuers or servers of companies other than card issuers. These other servers send electronic currency number lists or determination result information to checkout server 10 using the same processing as described above for electronic currency server 20. The category determination unit 102 can also determine the presence or absence of electronic currency numbers based on the electronic currency number lists or determination result information sent from other servers.

For example, if the checkout server 10 has a database identical to the electronic currency database DB2, then the category determination unit 102 can determine the presence or absence of an electronic currency number without requesting a list of electronic currency numbers or determination result information from the electronic currency server 20 or other servers. In this case, the checkout server 10 periodically (e.g., every few hours or daily) retrieves data from the electronic currency database DB2 from the electronic currency server 20 and updates the database accordingly. Thus, the processing of the category determination unit 102 can be completed entirely within the checkout server 10.

Furthermore, assuming that the card group associated with the user ID "u00001" of the parent user "Special Permit Taro" does not contain an electronic currency number, the category determination unit 102 can also determine the presence or absence of an electronic currency number in the card group associated with the user ID "u00002" of the child user "Special Permit Kosuke". In the example of Figure 6, although the card group does not exist, if the child user "Special Permit Kosuke" possesses any card with an electronic currency number, the category determination unit 102 can also consider that card as an associated card. In this case, the second authentication can also be initiated by the authentication execution unit 103, which will be described later. Furthermore, the authentication execution unit 103 can also perform questioning authentication first, and then initiate the second authentication. Furthermore, it can also perform information-based verification or second authentication on other cards linked to the user ID of the child's user. Furthermore, the user terminal 30 can allow the user to choose either first or second authentication. Even when the user possesses a card with an electronic currency number, the user terminal 30 can guide the user to choose second authentication, initiating the second authentication solely through the user's selection.

[Authentication Execution Unit] The authentication execution unit 103 performs the authentication processing required for the type of at least one of the cards determined by the type determination unit 102. In this embodiment, it is exemplified that the authentication execution unit 103 performs the authentication processing required for the type of both the target card and the related cards (i.e., both the type of the target card and the type of the related cards). However, the authentication execution unit 103 may also perform the authentication processing required only for the type of the target card. Furthermore, for example, the authentication execution unit 103 may also perform the authentication processing required only for the type of the related cards.

The processing required for authentication can refer to the auxiliary processing that the checkout server 10 enables other computers to perform for authentication, or it can mean that the checkout server 10 itself performs the authentication. For example, the checkout server 10 displaying a screen containing links to other computers, the checkout server 10 redirecting the user terminal 30 to other computers, or the checkout server 10 sending the necessary authentication information to other computers are equivalent to such auxiliary processing. The checkout server 10 performing the comparison processing of authentication information (such as user ID, password, or electronic currency code) is equivalent to the checkout server 10 itself performing the processing required for authentication.

In this embodiment, the first authentication is performed primarily by the card issuer's computer. Therefore, the processing required for the first authentication is the processing necessary for the card issuer's computer to perform the first authentication. In the example of Figure 2, the button B20 on the authentication screen SC2 in the upper right corner of Figure 2 contains a link to the card issuer's screen SC3 (e.g., a direct link to the card issuer's screen SC3, or a link required to redirect to the card issuer's screen SC3). The processing of displaying the authentication screen SC2 containing this link on the user terminal 30 is equivalent to the processing required for the first authentication. Furthermore, the processing required for the first authentication can also mean that the first authentication is performed by the checkout server 10 itself. Depending on the type of first authentication, it may not be performed by the card issuer's computer or other computers, but by the checkout server 10 itself. Therefore, the authentication execution unit 103 can also perform the first authentication itself to carry out the processing required for the first authentication.

In this embodiment, the second authentication is performed primarily by the checkout server 10. Therefore, the processing required for the second authentication is performed by the checkout server 10 itself. For example, the processing required for the second authentication involves the checkout server 10 comparing the information obtained from the user terminal 30, or information associated with that information, with the information used as the correct answer in the second authentication. For example, the comparison processing of user identification information described later is equivalent to the processing required for the second authentication. Furthermore, the second authentication can also be performed via the card issuer's computer, just like the first authentication, or on a server other than the checkout server. That is, the processing required for the second authentication can also be the processing of displaying the screen required for the second authentication. In this case, the second authentication is performed using a computer other than the checkout server 10 (such as the card issuer's computer). The authentication execution unit 103 can also obtain data indicating the execution result of the second authentication from the other computer.

The term "category-specific authentication" refers to authentication processes that differ depending on the category. For example, authentication execution unit 103 performs first authentication if the category determined by category determination unit 102 is Category 1. First authentication is not limited to 3D security authentication as in this embodiment. First authentication can also be: security code authentication, password authentication, biometric authentication, or other authentication. If authentication execution unit 103 performs second authentication, which differs from first authentication, if the category determined by category determination unit 102 is Category 2. Second authentication is not limited to scan authentication as in this embodiment. Second authentication can be any authentication different from first authentication. The second certification can also be any certification different from the first certification exemplified in the first certification. Alternatively, contrary to the examples of this embodiment, the first certification can be a scan certification, and the second certification can be a certification other than a scan certification. However, in this case, it is assumed that some information other than the accompanying information can be scanned.

In this embodiment, the authentication execution unit 103 performs the necessary processing for authentication corresponding to the presence or absence of an electronic currency number in the card of at least one party as determined by the category determination unit 102. For example, if the authentication execution unit 103 determines that an electronic currency number is not present in the card of at least one party as determined by the category determination unit 102, it performs the necessary processing for first authentication that does not utilize the electronic currency number. For example, if the authentication execution unit 103 determines that an electronic currency number is present in the card of at least one party as determined by the category determination unit 102, it performs the necessary processing for second authentication that utilizes the electronic currency number.

In this embodiment, since the second authentication is scan authentication, the authentication execution unit 103 performs the processing required for the second authentication based on the electronic currency number obtained by the user terminal 30 reading the card of at least one of the cards determined by the category determination unit 102, when the card is determined to contain an electronic currency number. The method for reading the electronic currency number by the user terminal 30 can be any method. The method for reading the electronic currency number by the user terminal 30 is not limited to reading using NFC functionality.

For example, user terminal 30 can also read the electronic currency number using communication functions other than NFC. For example, user terminal 30 can also read the electronic currency number using camera unit 36. In this case, it is assumed that the electronic currency number has already been formed on the surface of the target card or associated card. The electronic currency number can also be printed on the card surface or formed by embossing. User terminal 30 obtains the electronic currency number by performing image processing such as optical character recognition on the image generated by camera unit 36.

For example, the authentication execution unit 103 specifies the user identification information that has been associated with the electronic currency number obtained by the user terminal 30. In this embodiment, one example of the user identification information used in authentication is the user ID, but the user identification information can also be other information mentioned above. The part of the authentication processing description in this embodiment that is recorded as the user ID can be replaced with any other user identification information.

For example, once the checkout server 10 obtains an electronic currency number from the user terminal 30, the authentication execution unit 103 requests the user ID associated with that electronic currency number from the electronic currency server 20. Upon receiving the request, the electronic currency server 20 retrieves the user ID associated with the electronic currency number from the electronic currency database DB2. The electronic currency server 20 then sends the user ID to the checkout server 10. The checkout server 10 receives the user ID from the electronic currency server 20.

For example, the authentication execution unit 103 performs the processing required for the second authentication based on the user ID obtained upon login and the user ID associated with the electronic currency number obtained by the user terminal 30. In this embodiment, the authentication execution unit 103 compares these user IDs and determines whether they are consistent. If the user IDs are not determined to be consistent, the authentication execution unit 103 determines that the second authentication has failed. If the user IDs are determined to be consistent, the authentication execution unit 103 determines that the second authentication has succeeded.

In the examples of Figures 5 and 6, suppose the user "Takkyu Taro's" "AAA Card" is in an unauthenticated state. Suppose the user "Takkyu Taro" attempts to set the "AAA Card" as a payment source. That is, suppose the "AAA Card" is the target card. In this case, since the type determination unit 102 determines that at least one of the target card and the associated card has an electronic currency number, the authentication execution unit 103 performs the processing required for the second authentication.

In the example in Figure 6, the user ID "u00001" of user "Taku Taro" is associated with four electronic currency codes. In this embodiment, the user ID of user "Taku Taro" will remain consistent regardless of which of these four electronic currency codes is read, thus the second authentication will succeed. Therefore, user "Taku Taro" can successfully complete the second authentication not only by setting the target card "AAA Card", but also by reading three associated cards ("EEE Card", the "AAA Card" of his child user "Patent Kosuke", and the IC card "FFF Coin" without credit card functionality).

Furthermore, if user "Taku Taro" successfully completes the second authentication for the "AAA Card," then the second authentication for the "EEE Card," another credit card already registered to the checkout service by user "Taku Taro," is also considered successful because it is linked to the same user ID. Additionally, if user "Taku Taro" reads an IC card (which is a "FFF coin" card without credit card functionality) using user terminal 30, then the authentication execution unit 103 can also determine that the second authentication was successful.

Furthermore, if the user "Takumi Taro" reads an IC card ("FFF Coins") without credit card functionality using the user terminal 30, the authentication execution unit 103 may not determine that the second authentication has been successful. In this case, assuming that the information used to identify the presence or absence of credit card functionality is already stored in a database such as the electronic currency database DB2, the authentication execution unit 103 may only determine that the second authentication is successful if a related card with credit card functionality is read. Even if an IC card ("FFF Coins") without credit card functionality is used, since its security level may be lower than that of a credit card, it may also be considered an unauthorized authentication target. In addition, for example, other certifications such as attribute certifications can be combined with a second certification, rather than being regarded as certification objects.

In the example in Figure 6, the child user "Kousuke" will not trigger the second authentication because the child card's e-currency number is linked to the parent user "Taro." Even if the child user "Kousuke" attempts to perform the second authentication in some way, the second authentication will still fail because the user ID linked to the child card "AAA Card's" e-currency number belongs to the parent user "Taro." For example, if the second authentication is triggered solely by the user's choice, the second authentication will be triggered if the child user "Kousuke" chooses the second authentication option. In this case, the authentication execution unit 103 determines that the user ID obtained based on login belongs to the child user "Special Permit Kosuke" and the user ID associated with the electronic currency number obtained by the user terminal 30 belongs to the parent user "Special Permit Taro". Therefore, the authentication execution unit 103 does not determine that these user IDs are consistent and determines that the second authentication fails.

Furthermore, users "Real Case Hero," "Designer Hanako," and "Trademark Ayaka," like user "Licensed Taro," were able to successfully complete the second authentication by reading a credit card with an electronic currency code. For example, even though user "Trademark Ayaka" used an "LLL Card" that was not registered with the checkout service for scanning authentication, the authentication execution department 103 determined that the second authentication was successful because the user ID matched.

For example, suppose a malicious third party improperly obtains information such as the user ID "u00001" and the credit card number of "AAA Card". Furthermore, suppose the third party impersonates the user "Tsukai Taro" and improperly sets "AAA Card" as the payment source for their own checkout application. In this case, even if the third party reads the electronic currency number of the credit card at hand (not the user "Tsukai Taro's" "AAA Card"), the user ID associated with that electronic currency number is still not the logged-in user ID "u00001". The authentication execution unit 103 determines that the second authentication has failed because these user IDs are inconsistent.

Furthermore, the execution method of the second authentication can also be other methods. The execution method of the second authentication is not limited to the examples of this embodiment. For example, if the checkout server 10 manages the same database as the electronic currency database DB2, the authentication execution unit 103 may also identify the user ID based on its own database without having to query the user ID associated with the scanned electronic currency number from the electronic currency server 20. Alternatively, for example, the authentication execution unit 103 may not perform the comparison of user IDs itself, but instead delegate the comparison of user IDs to the electronic currency server 20 or other computers. In this case, the authentication execution unit 103 obtains data representing the comparison results from the electronic currency server 20 or other computer. The authentication execution unit 103 determines whether the second authentication is successful based on this data.

For example, the authentication execution unit 103 may not compare user IDs, but instead determine whether the electronic currency number obtained through reading from the user terminal 30 exists in the electronic currency number list to perform the second authentication. In this case, the authentication execution unit 103 determines that the second authentication has failed if the electronic currency number does not exist in the electronic currency number list. The authentication execution unit 103 determines that the second authentication has succeeded if the electronic currency number exists in the electronic currency number list.

For example, the authentication execution unit 103 can still perform the processing required for the second authentication even if it is determined that the target card does not contain an electronic currency number, but the related card does contain an electronic currency number. That is, the user can also scan the related card with the user terminal 30 instead of scanning the target card. The second authentication process in this case is as described above. In the examples of Figures 5 and 6, the second authentication process for the user "Trademark Ayaka" is equivalent to the above processing.

For example, even if the authentication execution unit 103 is determined to have an electronic currency number on the target card, it can still perform the processing required for the second authentication based on the attached information obtained by reading the associated card through the user terminal 30. In this case, the second authentication process is as described above. The authentication execution unit 103 can also perform the processing required for the second authentication without using either the electronic currency number of the target card or the electronic currency number of the associated card. In the examples of Figures 5 and 6, the second authentication process when the user "Takeru Taro" reads a card other than "AAA Card" is equivalent to the processing described above.

In this embodiment, the setting target card is the user's own card. The user's own card is the card whose name is the user currently logging into the checkout service from user terminal 30. The related card can also be a family member's card. In the examples of Figures 5 and 6, one of the related cards for the user "Takkyu Taro" is the family card of the user who includes their children, namely "Takkyu Kosuke". A family card is a card whose name is a family member of the user currently logging into the checkout service from user terminal 30. For example, family members can be a spouse, children, or other persons. A child card is one type of family card. A family card may not necessarily show a parent-child relationship with the user's own card.

For example, the authentication execution unit 103 can still perform the processing required for the second authentication even if it is determined that the user's card does not contain an electronic currency number, but a family member's card does. The second authentication process itself is as described above. In the examples of Figures 5 and 6, even if the user "Takeru Taro" does not have an electronic currency number in his own card, the child card can still be used to successfully complete the second authentication, so the above processing will be performed. Furthermore, in the example of Figure 6, although the electronic currency number of the child card is linked to the user ID of the parent user, the electronic currency number of the child card can also be linked to the user ID of the child user. Furthermore, other information such as the child card's credit card number can also be linked to the user ID of the parent user or the user ID of the child user. However, credit cards are, in principle, only the cardholder can use them; therefore, the child card is assumed to be used by the child (family member). Thus, the parent user, in principle, will not use the child card in their own checkout application.

[Settings Reflection Unit] The settings reflection unit 104 reflects the relevant settings of the target card when authentication has been performed. Reflecting the settings means validating them. Once the settings are reflected, checkout is performed based on the reflected settings. In this embodiment, since payment source information is equivalent to a setting, the settings reflection unit 104 reflects the settings by updating or adding payment source information to the user database DB1. The settings reflection unit 104 does not reflect settings if authentication fails. The settings determination unit reflects settings only if authentication is successful. Authentication, which determines whether a setting is reflected, can be either first authentication or second authentication.

In this embodiment, the setting response unit 104 updates the payment source information and the authentication result information. Once the authentication result information of a credit card is changed to "authenticated," the user can set the credit card as a payment source without re-authenticating. Authentication not only reflects the payment source setting but also other settings such as the top-up method setting for the online electronic currency "DDD e-cash." Therefore, users can set credit cards that have been authenticated as payment sources as the top-up method for the online electronic currency "DDD e-cash" without re-authenticating.

[Checkout Execution Department] The Checkout Execution Department 105 executes checkout based on the settings reflected by the Setting and Reflection Department 104. Checkout includes not only payments from franchisees to checkout services, but also the addition of electronic currency or remittances to others. The checkout execution method itself is a known procedure. The Checkout Execution Department 105 identifies the checkout method based on the payment source information and executes checkout based on that identified checkout method.

[3-5. Other Functions Implemented in the Electronic Currency Server] As an example of other functions implemented in the electronic currency server 20, the receiving unit 201 and the transmitting unit 202 will be described.

[Receiver Unit] The receiver unit 201 receives various requests from the checkout server 10 or other computers. For example, the receiver unit 201 receives a request from the checkout server 10 to generate an electronic currency code slip. This request contains the user ID of the user who will be the object of generating the electronic currency code slip.

[Sending Department] Sending department 202 sends various data to checkout server 10 or other computers. For example, sending department 202 sends electronic currency code lists to checkout server 10 or other computers. The method for generating electronic currency code lists is as described above.

[3-6. Other Functions Implemented in the User Terminal] As an example of other functions implemented in the user terminal 30, the reading unit 301 and the transmission unit 302 will be described.

[Reading Unit] The reading unit 301 reads at least one of the target card and the associated card. In this embodiment, it is exemplified that the reading unit 301 reads only one of the target card or the associated card, but the reading unit 301 can also read both the target card and the associated card. For example, the reading unit 301 uses the NFC function of the user terminal 30 for reading. The reading unit 301 can also use communication functions other than NFC for reading, or it can use the camera unit 36 for reading.

[Sending Department] Sending department 302 sends data (e.g., data indicating electronic currency code) to checkout server 10, representing the read result caused by read department 301.

[4. Processing Performed in the Authentication System] Figures 7 and 8 illustrate examples of processing performed in authentication system 1. The processing shown in Figures 7 and 8 is executed by control units 11, 21, and 31 according to programs stored in memory units 12, 22, and 32, respectively.

As shown in Figure 7, once the checkout application is started, the user terminal 30 performs login processing (S1) with the checkout server 10 to allow the user to log in to the checkout service. In S1, the user terminal 30 sends the user ID and login password entered by the user to the checkout server 10. The checkout server 10 determines that the login is successful if the user ID and login password entered by the user are present in the user database DB1. The checkout server 10 stores the user ID of the logged-in user in the memory 12. As mentioned above, login processing in which the input of the user ID and login password is omitted can also be performed. Such login processing itself is a known process.

The following describes the processing of the user's actions to select a payment source. The user terminal 30 performs the necessary processing (S2) between itself and the checkout server 10 to display the payment source setting screen SC1. Once the user selects button B10, the user terminal 30 sends checkout method information (S3) to the checkout server 10 to identify the selected payment source. Once the checkout server 10 receives the checkout method information from the user terminal 30 (S4), it determines, based on the user database DB1, whether the authentication result information associated with the checkout method information indicates authentication (S5).

In step S5, if the authentication result information indicates that authentication has been completed (S5: Y), the checkout server 10, in conjunction with the user terminal 30, performs the necessary processing to update the payment source information (S6), and this processing is complete. In this case, since authentication has been completed, there is no need to perform processing after S6, and the payment source is set and changed.

In step S5, if the authentication result information is not determined to indicate that authentication has been completed (S5: N), the checkout server 10 requests a list of electronic currency numbers from the electronic currency server 20 based on the user ID of the logged-in user (S7). The electronic currency server 20 then processes the request from the checkout server 10 (S8). The electronic currency server 20 generates a list of electronic currency numbers based on the electronic currency database DB2, representing the electronic currency numbers associated with the user IDs contained in the request from the checkout server 10 (S9). The electronic currency server 20 then sends the electronic currency number list to the checkout server 10 (S10).

The checkout server 10 receives a list of electronic currency codes from the electronic currency server 20 (S11). Based on the list of electronic currency codes, the checkout server 10 determines whether the electronic currency codes of the target card and associated cards are present (S12). If the checkout server 10 determines that no electronic currency codes are present for the target card and associated cards (S12:N), it performs the necessary processing for the first authentication with the user terminal 30 (S13). Through the processing in S13, the authentication screen SC2 in the upper right corner of Figure 2 is displayed on the user terminal 30. Next, a first authentication (such as 3D security authentication and security code authentication) will be performed between the user terminal 30 and the card issuing company's computer.

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

In S12, if the checkout server 10 is determined to have an electronic currency number in at least one of the target card and the associated card (S12: Y), then proceed to Figure 8. The checkout server 10 and the user terminal 30 perform the necessary processing to display the authentication screen SC2 in the upper right corner of Figure 3 (S16). The user terminal 30 sends information to the checkout server 10 indicating which authentication method (first authentication or second authentication) the user has selected (S17). Once the checkout server 10 receives this information (S18), it determines which authentication method (first authentication or second authentication) the user has selected (S19).

In S19, if it is determined that the user has selected the first authentication (S19: First Authentication), the process proceeds to S13. In S19, if it is determined that the user has selected the second authentication (S19: Second Authentication), the checkout server 10 performs the necessary processing between itself and the user terminal 30 to display the interactive window M23 (S20). The user terminal 30 activates the NFC function of the communication unit 23 to read the set object card or associated card (S21). The user terminal 30 sends the electronic currency number read via the NFC function to the checkout server 10 (S22).

The checkout server 10 receives the electronic currency number read via NFC from the user terminal 30 (S23). The checkout server 10 requests the user ID associated with the electronic currency number read via NFC from the electronic currency server 20 (S24). Once the electronic currency server 20 accepts the request (S25), it sends the user ID associated with the electronic currency number read via NFC to the checkout server 10 based on the electronic currency database DB2 (S26).

The checkout server 10 receives the user ID associated with the electronic currency number read via NFC from the electronic currency server 20 (S27). The checkout server 10 determines whether the second authentication is successful by comparing the user ID of the logged-in user with the user ID associated with the electronic currency number read via NFC (S28). If the second authentication fails (S28: N), the process ends. If the second authentication fails, the first authentication can still be requested. If the second authentication is successful (S28: Y), the payment source information settings are reflected (S29), and the process ends. In S29, the checkout server 10 also performs the process of updating the authenticated information.

[5. Summary of the Embodiment] The authentication system 1 of this embodiment determines the type of at least one of the target card and related cards when the relevant settings of the target card are configured. Authentication system 1 performs the processing required for authentication corresponding to the type of the at least one card. Authentication system 1 reflects the settings after authentication has been performed. Therefore, authentication system 1 can flexibly differentiate authentication based on the type of the at least one card, thus maintaining security at checkout while improving user convenience. For example, authentication becomes possible when the type of the at least one card is one that allows for authentication that maintains security while improving user convenience. Authentication System 1 enhances security even for categories that are not eligible for such authentication by performing the necessary processing for other authentications. Furthermore, it prevents situations where there is no means for users to reflect the authentication required for setting changes (e.g., the user can reflect changes simply by successfully completing the first authentication), thus improving convenience.

Furthermore, authentication system 1 determines the type of at least one card by checking whether it contains an electronic currency number (an example of attached information) associated with the target card and the associated card. Authentication system 1 performs the necessary authentication processing based on the presence or absence of the electronic currency number on the at least one card. Therefore, authentication system 1 can flexibly differentiate authentication based on the presence or absence of an electronic currency number attached to the at least one card, thus maintaining checkout security while improving user convenience. For example, if authentication that maintains security while improving user convenience is feasible when an electronic currency number is present, then authentication becomes feasible. Therefore, authentication system 1 can maintain checkout security while improving user convenience. For example, authentication system 1 does not require the exchange of the credit card number, which is essential for the card's intrinsic function, during authentication. Instead, it only exchanges the ancillary information, namely the electronic currency number, which plays a secondary role, thereby enhancing security. For example, authentication system 1 facilitates the use of electronic currency services (an example of the services involved in the ancillary information) by utilizing the electronic currency number (an example of the ancillary information) as authentication information.

Furthermore, Authentication System 1 performs the necessary processing for first authentication without using the electronic currency number when it is determined that at least one of the target card and the associated card does not have an electronic currency number. Authentication System 1 also performs the necessary processing for second authentication using the electronic currency number when it is determined that at least one of the target card and the associated card does have an electronic currency number. Therefore, Authentication System 1 can flexibly distinguish between using first and second authentication depending on whether an electronic currency number is attached to the card of the at least one party, thus maintaining checkout security while improving user convenience. For example, if a second authentication method offers higher security and greater user convenience than the first authentication method, then Authentication System 1, when the second authentication is feasible, maintains checkout security while improving user convenience by implementing the necessary processing for the second authentication. Authentication System 1, even if the second authentication is not feasible, prevents users from being unable to complete any authentication by implementing the first authentication method, thus maintaining checkout security while improving user convenience.

Furthermore, Authentication System 1 performs the necessary processing for the second authentication when at least one of the cards identified as the target card or related cards contains an electronic currency number, based on the electronic currency number obtained by the user terminal 30 reading the card of that target card. In this way, Authentication System 1 can maintain checkout security while improving user convenience. For example, scan authentication offers higher security because the physical credit card is readily available. 3D security authentication or security code authentication can cause inconvenience due to user input, and users sometimes forget their passwords, but scan authentication improves user convenience because it eliminates the need for password input.

Furthermore, authentication system 1 obtains the user ID of the logged-in user based on the login from user terminal 30. Authentication system 1 identifies the user ID that has been associated with the electronic currency number obtained by user terminal 30. Authentication system 1 performs the processing required for the second authentication based on the user ID obtained from login and the user ID associated with the electronic currency number obtained by user terminal 30. Therefore, authentication system 1 does not need to exchange highly confidential information such as credit card numbers for authentication, thus avoiding the leakage of highly confidential information and performing authentication.

Furthermore, Authentication System 1 determines the presence or absence of electronic currency numbers on both the target card and the associated card. Even if the target card is determined to lack an electronic currency number, Authentication System 1 will perform the necessary processing for second authentication if the associated card is determined to have an electronic currency number. Thus, Authentication System 1 ensures that even if second authentication cannot be performed using the target card the user is attempting to set, but can be performed using the associated card, the user can still have the target card's settings reflected by utilizing the second authentication of the associated card. This maintains checkout security while improving user convenience.

Furthermore, as mentioned above, the target card can be the user's own card. The associated card can be a family member's card. In this case, even if the user's own card is determined to lack an electronic currency number, but a family member's card is determined to have an electronic currency number, authentication system 1 will perform the necessary processing for second authentication. Thus, even if second authentication cannot be performed using the user's own card, but can be performed using a family member's card, authentication system 1 allows the user to have their own card's settings reflected by utilizing the family member's card's second authentication. This maintains checkout security while improving user convenience.

Furthermore, even if the target card is determined to contain an electronic currency code, Authentication System 1 can still perform the processing required for the second authentication based on the information obtained by reading the associated card through the user terminal 30. Therefore, Authentication System 1 can perform authentication even using an associated card different from the target card, thus further improving user convenience. For example, even if the user does not have the target card on hand, they can complete the second authentication using the associated card if it is available.

[6. Variations] Furthermore, this disclosure is not limited to the embodiments described above. Appropriate modifications may be made to this disclosure without departing from its purpose.

Figure 9 is a diagram illustrating one example of the functions in the variant. As shown in Figure 9, the checkout server 10 of the variant 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 implemented by the control unit 11.

[6-1. Variation 1] For example, the authentication execution unit 103 can also perform authentication corresponding to the validity of electronic currency numbers. In Variation 1, similar to the embodiment, it is assumed that the validity information of the electronic currency numbers is already stored in the electronic currency database DB2. Furthermore, it is assumed that the electronic currency number list in Variation 1 contains not only electronic currency numbers but also validity information. The authentication execution unit 103 determines whether an electronic currency number is valid based on the validity information in the electronic currency number list. Alternatively, the electronic currency number list may not contain validity information but only display the electronic currency number to indicate that the validity information is valid.

In Variant Example 1, the authentication execution unit 103 performs the processing required for first authentication when the electronic currency number of at least one of the target card and related cards is invalid. For example, the authentication execution unit 103 performs the processing required for first authentication when all electronic currency numbers contained in the electronic currency number list are invalid. Alternatively, the authentication execution unit 103 may perform the processing required for first authentication when only a portion of the electronic currency numbers contained in the electronic currency number list are invalid. The processing required for first authentication is as described in the embodiment.

In Variant Example 1, the authentication execution unit 103 performs the processing required for the second authentication only if the electronic currency number of at least one of the target card and the associated card is valid. For example, the authentication execution unit 103 performs the processing required for the second authentication only if the electronic currency number list contains even one valid electronic currency number. Alternatively, the authentication execution unit 103 may perform the processing required for the second authentication only if all electronic currency numbers contained in the electronic currency number list are valid. The processing required for the second authentication is as described in the embodiment.

Furthermore, while Variation 1 exemplifies the case where the electronic currency number list contains validity information, the method for determining the validity of electronic currency numbers is not limited to the above example. For instance, if the checkout server 10 stores a database identical to the electronic currency database DB2, the authentication execution unit 103 can also determine whether the electronic currency number is valid based on the validity information stored in that identical database.

Alternatively, for example, checkout server 10 may delegate the determination of the validity of electronic currency numbers to electronic currency server 20 or other computers. In this case, electronic currency server 20 or other computers determine whether the electronic currency number is valid based on the validity information of the electronic currency number. Electronic currency server 20 or other computers send data indicating the determination result to checkout server 10. Checkout server 10 receives this data from electronic currency server 20 or other computers. The authentication execution unit 103 may also determine, based on this data, whether to perform the processing required for first authentication or the processing required for second authentication.

In Modification 1, authentication system 1 performs the processing required for first authentication when the electronic currency number of at least one of the target card and associated cards is invalid. Authentication system 1 also performs the processing required for second authentication when the electronic currency number of at least one of the target card and associated cards is valid. Therefore, authentication system 1 prevents the use of invalid electronic currency numbers for successful second authentication, thus enhancing checkout security. For example, even if a malicious third party obtains a user's lost card, as long as the card's electronic currency number is invalid, the third party cannot impersonate the user and successfully complete the second authentication; therefore, authentication system 1 further enhances checkout security.

[6-2. Variation Example 2] For example, the category determination unit 102 can also determine the category of each of the target card and related cards based on the parent-child relationship between the target card and the related card. The parent-child relationship between the target card and the related card can be represented in any database. For example, the parent-child relationship between the target card and the related card can also be represented in the user database DB1, the electronic currency database DB2, or other databases. For example, other databases might be the database of the card issuing company. It is assumed that information indicating whether each of the target card and the related card is held by a parent or child is stored in these databases. The parent card can also be linked to identify the child card's information. The child card can also be linked to identify the parent card's information.

In Variation Example 2, it is assumed that the electronic currency database DB2 stores parent-child relationship information indicating the relationship between the parent card and the child card. In the example of Figure 6, among the electronic currency numbers associated with the user ID "u000001" of the parent user "Special Permit Taro," there is parent-child relationship information indicating that the electronic currency number of the child user "Special Permit Kosuke" is the child card's electronic currency number, and this association is established. This parent-child relationship information can also represent information that can be used to identify the parent card.

Assuming that the electronic currency number list in Variation Example 2 includes not only electronic currency numbers but also parent-child relationship information, the category determination unit 102 determines the category of the target card and the associated card based on the parent-child relationship information in the electronic currency number list. For example, the category determination unit 102 identifies the credit card with the electronic currency number associated with the child's user "Special Permit Kosuke" as a sub-card based on the parent-child relationship information established therewith. Once the category determination unit 102 identifies the credit card as a sub-card, the authentication execution unit 103 performs the processing required for the second authentication.

Furthermore, in Variation 2, the authentication execution unit 103 only needs to perform the authentication corresponding to whether at least one of the target card and the associated card is a parent card or a child card. For example, the authentication execution unit 103 can also perform the processing required for the second authentication when at least one of the target card and the associated card is a parent card and that parent card is used for authentication. The authentication execution unit 103 can also perform both the processing required for the first authentication and the processing required for the second authentication when at least one of the target card and the associated card is a child card and that child card is read by the user and used for authentication. Whether the parent card or the child card is used for authentication can be determined based on information about the card that can be used to identify electronic currency numbers, etc.

Furthermore, in Variation 2, the example given is that the electronic currency number list contains parent-child relationship information. However, the method for determining parent-child relationships is not limited to the above example. For instance, if the checkout server 10 has a database that is identical to the electronic currency database DB2, then the category determination unit 102 can also determine the parent-child relationship based on the parent-child relationship information stored in that identical database.

Alternatively, for example, checkout server 10 may delegate the determination of parent-child relationship to electronic currency server 20 or another computer. In this case, electronic currency server 20 or the other computer determines the parent-child relationship based on the parent-child relationship information it manages. Electronic currency server 20 or the other computer sends data indicating the determination result to checkout server 10. Checkout server 10 receives this data from electronic currency server 20 or the other computer. Category determination unit 102 may also determine the parent-child relationship based on this data.

The authentication system 1 in Variation 2 determines the type of each card based on the parent-child relationship between the target card and the associated card. Therefore, authentication system 1 can flexibly differentiate authentication based on the parent-child relationship, thus maintaining checkout security while improving user convenience. For example, authentication system 1 can require a higher level of security when the child card is used for authentication compared to when the parent card is used for authentication.

[6-3. Variation 3] For example, in Variation 2, the authentication execution unit 103 can perform multiple authentication processes when at least one of the target card and related cards is determined to be a child. Multiple authentications are also referred to as multi-stage authentication or multi-element authentication. In Variation 3, the authentication execution unit 103 performs the processing required for the second authentication and the processing required for the third authentication when at least one of the target card and related cards is determined to be a child. That is, the authentication execution unit 103 performs the processing required for the second authentication and the processing required for the third authentication when a child card is used for authentication. Multiple authentications are not limited to the second and third authentications; there can be three or more authentications. For example, whether a scanned card is a sub-card is determined after the second authentication. The determination of whether a sub-card with an electronic currency number exists can also be performed before scanning.

The third authentication is an authentication different from the second authentication. The third authentication can be the same as the first authentication, but in variant 3, it is set to be different from the first authentication. For example, the third authentication could be: attribute authentication where authentication information such as electronic certificates is used; challenge authentication that asks for information such as family members' names/dates of birth/phone numbers; 3D security authentication; security code authentication; or other authentication. Assume that the authentication information used as the correct answer in the third authentication is already stored in the checkout server 10 or other computer. The third authentication is performed by comparing the information received from the user terminal 30 with the authentication information used as the correct answer.

For example, if the checkout server 10 is the entity performing the third authentication, the processing required for the third authentication is performed by the checkout server 10 itself. In this case, the processing required for the third authentication involves the checkout server 10 comparing the information obtained from the user terminal 30, or information associated with that information, with the information used as the correct answer in the third authentication. For example, if it is attribute authentication, then the processing of verifying the validity of the electronic voucher obtained by the checkout server 10 from the user terminal 30 is equivalent to the processing required for the third authentication.

Furthermore, the third authentication can also be performed on a computer other than the checkout server 10. In this case, the processing required for the third authentication is the same processing required for the other computer to perform the third authentication. For example, the user terminal 30 may contain links to other computers (e.g., direct links to other computers, or links used to redirect to other computers). The processing of displaying a screen containing such a link on the user terminal 30 is equivalent to the processing required for the third authentication.

In the authentication system 1 of variant 3, when at least one of the target card and related cards is determined to be a child, multiple authentication processes are performed. Thus, authentication system 1 can require higher security authentication when the target card is set using a child card.

[6-4. Variation 4] For example, if the expiration date of a designated object card that has been set as a payment source is updated, although re-authentication may be required, if the designated object card has already been authenticated, it can be set as a payment source without re-authentication. In Variation 4, the checkout execution unit 105, when the expiration date of a designated object card set via the setting feedback unit 104 is updated, does not require re-authentication; instead, it can execute the checkout based on the setting.

In Variation 4, even if the expiration date indicated by the checkout method information stored in the user database DB1 is updated, if the authentication result information indicates that authentication is complete, the authentication execution unit 103 does not require re-authentication. That is, if the user updates the expiration date of an already authenticated credit card, the checkout server 10 does not change the authentication result information of that credit card. Since the authentication result information of the credit card indicates that authentication is complete and has not changed, the checkout execution unit 105 does not require re-authentication and can still execute the checkout.

In the authentication system 1 of variant example 4, when the validity period of the target card is updated, no further authentication is required. Based on the settings reflected by the setting feedback unit 104, checkout can be performed. Therefore, authentication system 1 does not require the user to authenticate again even if the validity period of the target card has been updated, thus improving user convenience.

[6-5. Variation 5] For example, a checkout service can also operate in conjunction with other services besides the checkout service. In Variation 5, the user can utilize other services from the checkout application. These other services can be made using the checkout method the user has registered with the checkout service. In Variation 5, transportation services are illustrated as an example of other services. Other services can be any service, not limited to transportation services. For example, other services can also be: online shopping services, e-ticket services, e-book services, financial services, or other services. Furthermore, other services can also be checkout services different from the checkout service. For example, the checkout service can also be a checkout service for the first electronic currency, and other services can also be checkout services for the second electronic currency.

In Variation 5, the user can top up the electronic currency for the transportation service from the checkout application. Once the user instructs the user to top up using a checkout method already set as the payment source, the electronic currency for the transportation service is topped up. The collaborative operation method between the checkout service and the transportation service is itself a known method. For example, the checkout server 10 requests a top-up from the transportation service server once it performs the checkout required for the top-up. The top-up request indicates a top-up amount. The transportation service server performs the top-up based on this request, such that the electronic currency balance is increased by the top-up amount.

The authentication system 1 includes an authentication application unit 106. The authentication application unit 106 applies authentication to the transportation service after the authentication has already been performed by the authentication execution unit 103. Authentication application means that when a user uses the transportation service to complete the checkout process, the already authenticated checkout method can be used without further authentication. For example, treating the authentication result information as complete authentication is equivalent to authentication application. In addition, setting other information referenced by the checkout server 10 when the user uses the transportation service from the checkout application to indicate that authentication is complete is equivalent to authentication application for the transportation service.

For example, if a user instructs the use of a transportation service (e.g., adding value to electronic currency within the transportation service), the authentication application unit 106 refers to the authentication result information of the payment method used for adding value. If the authentication result information indicates that authentication is complete, the authentication application unit 106 does not perform further authentication. If the authentication result information does not indicate that authentication is complete, the authentication application unit 106 instructs the authentication execution unit 103 to perform authentication because the necessary authentication has not yet been performed.

In Modification 5, authentication system 1 applies authentication to services other than the checkout service after the initial authentication has been performed. Therefore, authentication system 1 eliminates the need for re-authentication for other services, thus improving user convenience. For example, if a user authenticates to set up a target card as a payment source for the checkout application, the need for further authentication to set up the target card as a top-up method for electronic currency in transportation services can be prevented, thus saving the user's effort.

[6-6. Variation 6] For example, the authentication execution unit 103 can also perform the processing required for first authentication when at least one of the target card and related cards is of type 1. In the example of the implementation form, type 1 is a type without an electronic currency number. Type 1 is not limited to any specified type, but can be any type specified in the example of the implementation form. For example, type 1 can also be a sub-card. Type 1 can be: a specified brand, a specified card issuing company, a specified credit card tier, a spending limit that is below the threshold, or other types.

For example, the authentication execution unit 103 can perform the processing required for a second authentication, different from the first authentication, when at least one of the target card and related cards is a second type, different from the first type. In an example of implementation, the second type is a type with an electronic currency number. The second type is not limited to any of the defined types. For example, the second type can also be a master card. The second type can be: a defined brand, a defined card issuing company, a defined credit card tier, a spending limit exceeding a threshold, or other types.

Authentication System 1 includes a first selection receiving unit 107. The first selection receiving unit 107 accepts the user's choice regarding whether or not to perform second authentication when at least one of the target card and associated cards is of type second. Accepting the choice means receiving data indicating the user's selection result from the user terminal 30. This is the same as the second selection receiving unit 108 described later. In an example implementation, the user's choice regarding whether or not to perform second authentication is accepted on the authentication screen SC2 in the upper right corner of Figure 3. For example, the first selection receiving unit 107 determines that the user has selected the requirement for second authentication when the user selects button B21. The first selection processing unit 107 determines that the user has selected "no second authentication" when the user selects button B22.

Furthermore, the decision regarding the requirement for second authentication can be made from any screen. The screen where the user can select whether or not to perform second authentication is not limited to authentication screen SC2. For example, the selection can also be made on the payment source settings screen SC1 or other screens. The authentication execution unit 103 performs the necessary processing for second authentication when it has been selected that second authentication is necessary. This processing is as described in the embodiment. The authentication execution unit 103 performs the necessary processing for first authentication, or the processing required for authentication other than first and second authentication, when it has been selected that second authentication is not required.

In the authentication system 1 of Variation 6, when the type of at least one of the target card and the associated card is a second type, the system accepts the choice regarding whether or not a second authentication is required. Authentication system 1 performs the necessary processing for second authentication when it has been selected that second authentication is necessary. Therefore, authentication system 1 can perform authentication according to the user's preferences, thus improving user convenience.

[6-7. Variation 7] For example, the user can also perform authentication using both the target card and the associated card. The authentication system 1 in Variation 7 includes a second selection receiving unit 108. The second selection receiving unit 108, when both the target card and the associated card are of the defined type, accepts a selection regarding whether processing is required to perform authentication not only using the target card but also using the associated card.

In the implementation example, the defined type is the type with an electronic currency number. The defined type includes: master card, sub-card, designated brand, designated card issuer, designated credit card tier, spending limit exceeding a threshold, or other types. Whether or not authentication is required for both the target card and related cards can be processed from any screen. For example, the option to select whether or not authentication is required for both the target card and related cards can be processed on the payment source setting screen SC1, the authentication screen SC2, or other screens.

The authentication execution unit 103, when selected to perform not only the authentication of the target card but also the authentication of the associated card, executes the processing required for authentication of both the target card and the associated card. The processing required for authentication means, as explained in the embodiment. This authentication can be either the first or second authentication as described in the embodiment. It can also be other authentications besides the first and second authentications.

Furthermore, there are certain benefits for users who have authenticated both the target card and the associated card. For example, the checkout server 10 can periodically require users who have only authenticated either the target card or the associated card, while waiving the periodic authentication for users who have authenticated both the target card and the associated card. The checkout server 10 can also increase the top-up limit by one amount for users who have only authenticated either the target card or the associated card, and increase the top-up limit by more than the fixed amount for users who have authenticated both the target card and the associated card.

In the authentication system 1 of variant example 7, when both the type of the target card and the type of the associated card are predetermined, the system accepts the option to perform the processing required for authentication of both the target card and associated cards. Authentication system 1 performs both the authentication of the target card and the authentication of associated cards when the option to perform the processing required for authentication of both the target card and associated cards has been selected. Therefore, authentication system 1 can perform authentication according to the user's preferences, thus improving user convenience.

[6-8. Other Variations] For example, the above-mentioned variations can also be combined.

Examples of implementation forms and variations 1-7 illustrate the case where credit card settings are configured during checkout services. Authentication System 1 can also perform the necessary processing for authentication in cases where credit card settings are configured in services other than checkout. For example, Authentication System 1 can also perform the necessary processing for authentication in scenarios where payment source settings are configured in online shopping services, e-ticket services, travel booking services, or other services. Furthermore, Authentication System 1 can also perform the necessary processing for authentication in scenarios where payment source settings are not used in these services, but rather in scenarios where settings such as spending limits are used.

For example, in order to achieve the goal of "maintaining security at checkout while improving user convenience" as described in the "Problem to be Solved by the Invention" section of this disclosure, scan authentication is a suitable component, but it is not a necessary component of authentication system 1. Authentication system 1 can perform flexible authentication corresponding to the type of card of at least one of the target card and associated cards by performing the necessary processing, thereby maintaining security at checkout while improving user convenience.

For example, besides scanning authentication, biometric authentication is known to be highly secure. Biometric authentication does not require the input of passwords, and therefore is also known to be highly convenient for users. For example, authentication system 1, by establishing a link with a specific type of card and registering the user's biometric information, can perform highly secure and user-friendly biometric authentication, thereby maintaining checkout security while improving user convenience. The same applies to other authentication methods besides scanning and biometric authentication. Authentication system 1, when at least one of the aforementioned cards is of type 2, only needs to perform the necessary processing for authentication that is relatively more secure and relatively more convenient for users compared to when at least one of the aforementioned cards is of type 1.

For example, the functions described and implemented in checkout server 10 can also be shared by multiple computers in authentication system 1. In this case, the function can be shared simply by each of the multiple computers sending its processing results to the other computers. For example, the functions described and implemented in checkout server 10 can also be implemented in electronic currency server 20. Conversely, the functions described and implemented in electronic currency server 20 can also be implemented in checkout server 10.

[7. Notes] For example, the authentication system described in this disclosure may also be configured as follows: (1) An authentication system comprising: a category determination unit, which, when settings related to a designated object card required for checkout of a specified service are performed, determines the category of at least one of the previously set object card and related cards associated with the previously set object card; an authentication execution unit, which performs the authentication processing required for the previously set category of the previously set at least one card; and a setting feedback unit, which reflects the previously set settings when the previously authenticated has been performed. (2) In the authentication system described in (1), the prefix type determination unit determines the prefix type of the card of at least one of the prefixes by determining whether or not there is attached information regarding the prefix of the card; the prefix authentication execution unit performs the authentication processing required for the presence or absence of the attached information of the prefix of the card of at least one of the prefixes. (3) In the authentication system described in (2), the prefix authentication execution unit performs the processing required for first authentication (where the attached information is not used) when the card of at least one of the prefixes is determined to lack such information; when the card of at least one of the prefixes is determined to contain such information, it performs the processing required for second authentication (where the attached information is used). (4) As described in (3), in the authentication system, the Pre-registration Execution Unit performs the processing required for Pre-registration 2nd authentication based on the Pre-registration information obtained by reading the Pre-registration information of at least one of the Pre-registration cards through a user terminal, when the Pre-registration information is determined to be present in the card of at least one of the Pre-registration parties. (5) As described in (4), the authentication system further includes: a user identification information acquisition unit, which acquires user identification information that can be used to identify the logged-in user based on login from the previous user terminal; a previous authentication execution unit: specifically identifies the user identification information that has been associated with the previous attached information acquired by the previous user terminal; based on: the previous user identification information acquired based on previous login, and the previous user identification information that has been associated with the previous attached information acquired by the previous user terminal, performs the processing required for the previous second authentication. (6) In any of the authentication systems described in (3) to (5), the Prerequisite Category Determination Unit determines the presence or absence of prerequisite-related information in both the Prerequisite Setting Object Card and the Prerequisite Related Card; the Prerequisite Authentication Execution Unit performs the processing required for Prerequisite 2 authentication even if the Prerequisite Setting Object Card is determined to lack prerequisite-related information, but the Prerequisite Related Card is determined to contain prerequisite-related information. (7) In the authentication system described in (6), the Pre-registration target card is the user's own card; the Pre-registration associated card is the family card of the user's family member; the Pre-registration authentication execution unit performs the processing required for Pre-registration 2 authentication even if the user's own card is determined to lack Pre-registration associated information, but the family member's card is determined to contain Pre-registration associated information. (8) In the authentication system described in any of (3) to (7), the Pre-registration authentication execution unit performs the processing required for Pre-registration 2 authentication based on the associated information obtained by reading the Pre-registration associated card through the user's terminal, even if the user's pre-registration target card is determined to contain Pre-registration associated information. (9) In any of the authentication systems described in (3) to (8), the pre-registration execution unit performs the following: When the pre-registration information attached to at least one of the pre-registration cards is invalid, it performs the processing required for the first pre-registration authentication; When the pre-registration information attached to at least one of the pre-registration cards is valid, it performs the processing required for the second pre-registration authentication. (10) In any of the authentication systems described in (1) to (9), the pre-registration type determination unit determines the pre-registration type of each of the pre-registration target card and the pre-registration related card based on the parent-child relationship between the pre-registration target card and the pre-registration related card. (11) In the authentication system described in (10), the pre-authentication execution unit performs the processing required for multiple pre-authentications when the pre-authentication type of at least one of the pre-authentication cards is determined to be a child. (12) In the authentication system described in any of (1) to (11), the pre-authentication system further includes: a checkout execution unit that, when the validity period of the pre-authentication target card that has been reflected in the pre-authentication settings has been updated, performs checkout based on the pre-authentication settings without requiring re-authentication. (13) The authentication system described in any of (1) to (12) includes, an authentication system further comprising: an authentication application unit, which, in the event that the authentication described in the foregoing has been performed, applies the authentication described in the foregoing to services other than those specified in the foregoing. (14) The authentication system described in any of (1) to (13) comprises, the prior authentication execution unit: when the prior type of at least one of the prior cards is type 1, performing the processing required for first authentication; when the prior type of at least one of the prior cards is type 2, different from type 1, performing the processing required for second authentication; the prior authentication system further comprises: a first selection acceptance unit, which accepts the selection regarding whether or not to perform second prior authentication when the prior type of at least one of the prior cards is type 2; the prior authentication execution unit, which performs the processing required for second prior authentication when the requirement for second prior authentication has been selected. (15) The authentication system described in any of (1) to (14) includes, a prior type determination unit that determines the prior type of both the prior-set object card and the prior-related card; the prior authentication system further includes: a second selection acceptance unit that, when the prior type of the prior-set object card is the designated type, and the prior type of the prior-related card is also the designated type, accepts a selection regarding whether to perform the processing required for prior authentication not only on the prior-set object card but also on the prior authentication of the prior-related card; The Pre-Authentication Execution Unit executes the necessary processing for pre-authentication using both the pre-set object card and the pre-authentication processing for pre-authentication using related cards, provided that this has been selected as a requirement.

1: Authentication System N: Network 10: Checkout Server 11, 21, 31: Control Unit 12, 22, 32: Memory Unit 13, 23, 33: Communication Unit 20: Electronic Currency Server 30: User Terminal 34: Operation Unit 35: Display Unit 36: Camera Unit 100: Data Memory Unit 101: User Identification Information Acquisition Unit 102: Category Determination Unit 103: Authentication Execution Unit 104: Setting Response Unit 105: Checkout Execution Unit 106: Authentication Application Unit 107: First Selection Acceptance Unit 108: Second Selection Acceptance Unit 200: Data Memory Unit 201: Receiving Unit 202: Transmission Department 300: Data Memory Department 301: Reading Department 302: Transmission Department B10, B20, B21, B22, B31, B32: Buttons DB1: User Database DB2: Electronic Currency Database F30: Input Form M23: Interactive Window SC1: Payment Source Setting Screen SC2: Authentication Screen SC3: Card Issuing Company Screen

[Figure 1] Illustration of an example of the hardware configuration of an authentication system. [Figure 2] Illustration of an example of first authentication. [Figure 3] Illustration of an example of second authentication. [Figure 4] Illustration of an example of the functions implemented in an authentication system. [Figure 5] Illustration of an example of a user database. [Figure 6] Illustration of an example of an electronic currency database. [Figure 7] Illustration of an example of the processing performed in an authentication system. [Figure 8] Illustration of an example of the processing performed in an authentication system. [Figure 9] Illustration of an example of the function in a variant example.

10: Checkout Server

20: Electronic Currency Servers

30: User Terminal

100:Data Memory Department

101: User Identification Information Acquisition Department

102: Category Judgment Department

103: Certification and Implementation Department

104: Setting up the response department

105: Checkout Execution Department

200:Data Memory Department

201: Receiving Department

202: Message Transmission Department

300:Data Memory Department

301: Reading Section

302: Message Transmission Department

DB1: User Database

DB2: Electronic Currency Database

Claims (16)

An authentication system includes: a type determination unit, which determines the type of a prior associated card by determining the presence or absence of electronic currency identification information (identifiable electronic currency) or points identification information (identifiable points) required for payment services accessed by a user through a payment application or browser installed on a user's terminal, and by including associated information related to the associated card; and an authentication execution unit, which performs the authentication processing required for the prior type of the prior associated card, including processing based on the presence or absence of associated information related to the prior electronic currency identification information or points identification information of the prior associated card; and The settings reflection section reflects the relevant settings of the pre-registration object card after pre-registration authentication has been performed, so that the pre-registration object card can be used as a payment source or value-added source in the pre-registration checkout application or pre-registration browser. As described in Request 1, the prior authentication execution unit performs the following: First, when it is determined that the prior related card does not contain the prior attached information, it performs the necessary processing for first authentication, which ensures that the prior attached information is not used; Second, when it is determined that the prior related card contains the prior attached information, it performs the necessary processing for second authentication, which ensures that the prior attached information is used. As described in Request 2, the Pre-record Authentication Execution Unit performs the processing required for Pre-record 2 authentication when it is determined that the Pre-record associated card contains Pre-record associated information, based on the Pre-record associated information obtained by reading the Pre-record associated card through the user terminal. As described in claim 3, the aforementioned authentication system further includes: a user identification information acquisition unit that acquires user identification information that can be used to identify the logged-in user based on login from the aforementioned user terminal; and an aforementioned authentication execution unit that: identifies the user identification information that has been associated with the aforementioned attached information acquired by the aforementioned user terminal; and performs the processing required for the aforementioned second authentication based on: the aforementioned user identification information acquired based on the aforementioned login and the aforementioned user identification information that has been associated with the aforementioned attached information acquired by the aforementioned user terminal. The authentication system described in any of claims 2 to 4 includes: A Prerequisite Type Determination Unit, which determines the presence or absence of prerequisite information in both the Prerequisite Setting Object Card and the Prerequisite Related Card; and a Prerequisite Authentication Execution Unit, which performs the processing required for Prerequisite 2 authentication even if the Prerequisite Setting Object Card is determined to lack prerequisite information, but the Prerequisite Related Card is determined to contain prerequisite information. As described in Request 5, the authentication system includes: ... The authentication system described in any of requests 2 to 4, wherein the Pre-Authentication Execution Unit is capable of performing the processing required for Pre-Authentication 2 based on the attached information obtained by reading the Pre-Related Card through the user terminal, even if the Pre-Set Object Card is determined to contain Pre-Related Information. The authentication system described in any of requests 2 to 4, wherein: The pre-authentication execution unit performs the following: When the pre-related information on the pre-related card is invalid, it performs the following: When the pre-related information on the pre-related card is valid, it performs the following: The pre-authentication second-order processing. An authentication system includes: a category determination unit that determines the category of at least one of the pre-set object cards and pre-set related cards based on the parent-child relationship between the pre-set object cards and the pre-set related cards in a checkout service that is used by a user from a checkout application or browser installed on a user's terminal; an authentication execution unit that performs the authentication processing required for the pre-set category of at least one of the pre-set cards; and a setting reflection unit that, when pre-set authentication has been performed, reflects the relevant settings of the pre-set object cards so that the pre-set object cards can be used as a source of payment or a source of added value in the pre-set checkout application or pre-set browser. As described in Request 9, the prior authentication execution unit performs the processing required for multiple prior authentications when the prior related card is determined to be a child. The authentication system described in any of the requests 1 to 4, wherein the pre-registration authentication system also includes: a checkout execution unit that, when the validity period of the pre-registration target card has been updated as reflected in the pre-registration settings, does not require re-authentication, but can perform checkout based on the pre-registration settings. The authentication system described in any of the requests 1 to 4, wherein the aforementioned authentication system further includes: an authentication application section, which applies the aforementioned authentication to services other than the aforementioned checkout service, provided that the aforementioned authentication has been performed. An authentication system includes: a type determination unit, which determines the type of at least one of the following cards: a pre-set object card and a related card associated with the pre-set object card, used by a user through a checkout service installed on a user's terminal; an authentication execution unit, which performs the authentication processing required for the pre-set type of the pre-set card; and a setting feedback unit, which, upon pre-authentication being performed, reflects the relevant settings of the pre-set object card so that the pre-set object card can be used as a payment source or value-added source in the pre-set checkout application or pre-set browser; the pre-set authentication execution unit is: When at least one of the prefaces is of type 1, the system performs the processing required for first authentication; when at least one of the prefaces is of type 2, different from type 1, the system performs the processing required for second authentication, different from type 1; the preface authentication system further includes: a first selection receiving unit, which accepts the selection regarding whether or not second authentication is required when at least one of the prefaces is of type 2; and a preface authentication execution unit, which performs the processing required for second authentication when second authentication is required. An authentication system includes: a category determination unit, which, when settings related to the target card required for checkout of a specified service are configured, determines the category of each of the pre-set target card and related cards; and a second selection acceptance unit, which, when the pre-set category of the pre-set target card is the specified category and the pre-set category of the related cards is also the specified category, accepts a selection regarding whether processing is required not only for authentication of the pre-set target card but also for authentication of the related cards; and The Authentication Execution Department, as the authentication corresponding to the Pre-record category, performs the necessary processing for Pre-record authentication using both the Pre-record setting object card and the Pre-record authentication using the Pre-record related card when it has been selected that this task must be performed. An authentication method includes: a category determination step, which determines the category of a prior associated card by determining the presence or absence of electronic currency identification information (identifiable electronic currency) or points identification information (identifiable points) required for payment through a checkout service installed on a user's terminal and associated with related cards; and an authentication execution step, which performs the authentication processing required for the prior category of the prior associated card, including prior processing based on the presence or absence of prior electronic currency identification information or points identification information of the prior associated card; and The setup reflection step, after Pre-registration authentication has been performed, reflects the relevant settings of the Pre-registration setting object card, so that the Pre-registration setting object card can be used as a payment source or value-added source in the Pre-registration checkout application or Pre-registration browser. A program product, used to enable a computer to perform functions, comprises: A type determination unit, which determines the type of a pre-existing card by determining the presence or absence of electronic currency identification information (identifiable electronic currency) or points identification information (identifiable points), as supplementary information associated with the related cards of the card required for checkout services that allow users to access the checkout service from the checkout application or browser installed on the user's terminal; and an authentication execution unit, which performs the authentication processing required for the pre-existing type of the pre-existing related card, including the processing corresponding to the presence or absence of supplementary information associated with the pre-existing electronic currency identification information or points identification information of the pre-existing related card. The settings reflection section reflects the relevant settings of the pre-registration object card after pre-registration authentication has been performed, so that the pre-registration object card can be used as a payment source or value-added source in the pre-registration checkout application or pre-registration browser.