Card determination system, card determination method and program

Abstract

To provide a card determination system enabling management according to cards of users.SOLUTION: A usage setting request receiving unit (101) of a card determination system (1) receives a usage setting request from a user terminal of a user regarding usage settings of a card used by the user for a prescribed service. A card determination unit (102) determines whether the card is a virtual card or a physical card when the usage setting request is received.SELECTED DRAWING: Figure 5

Description

[Technical Field]

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

[0002] Conventionally, there are known services that allow users to use cards such as credit cards. For example, Patent Document 1 describes a wallet device that issues a virtual card with the same card information, such as a credit card number, in addition to a physical card, which is a physical credit card, so that the user can use the virtual card for shopping on the Internet. [Prior art documents] [Patent documents]

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

[0004] However, the wallet device of Patent Document 1 issues a virtual card that a user can use for shopping, but does not manage the user's physical card and virtual card separately. This point is similar to other technologies other than the wallet device of Patent Document 1. Conventional technologies do not distinguish between physical cards and virtual cards, and do not adequately manage cards applied for by users.

[0005] One of the objectives of the present disclosure is to enable management according to a user's card. [Means for solving the problem]

[0006] The card determination system of the present disclosure includes a usage setting request receiving unit that receives, from a user's user terminal, a usage setting request regarding the usage settings of a card used by the user for a specified service, and a card determination unit that, when the usage setting request is received, determines whether the card is a virtual card or a physical card. [Effects of the Invention]

[0007] The present disclosure can enable management according to a user's card. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of a hardware configuration of a card determination system. [Figure 2] FIG. 10 is a diagram showing an example of a flow of a user registering as a member of a payment service. [Figure 3] FIG. 10 is a diagram showing an example of a flow in which a user performs first authentication. [Figure 4] FIG. 10 is a diagram showing an example of a flow in which a user performs second authentication. [Figure 5] FIG. 1 is a diagram illustrating an example of functions realized by the card determination system. [Figure 6] FIG. 10 is a diagram illustrating an example of a payment database. [Figure 7] FIG. 10 is a diagram illustrating an example of a card database. [Figure 8] FIG. 10 is a diagram illustrating an example of a process executed in the card determination system. [Figure 9] FIG. 10 is a diagram illustrating an example of a function realized in a modified example. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0011] The card server 20 is a server computer for the card service. The card service is a service that uses cards. The card service can be linked to a payment service. The card used in the card service may be any card. For example, the card may be a credit card, cash card, debit card, transportation card, electronic money card, point card, membership card, personal number card used as identification, or other card. The business operator that operates the payment service and the business operator that operates the card service may be the same or different.

[0012] In this embodiment, a credit card will be described as an example of a card. Therefore, in this embodiment, the word "card" refers to a credit card. The card service in this embodiment is a service provided by the card company that issued the card. For example, the card service is a service that enables payment using the card, application for installment payments, application for bonus payments, or changes to user registration information. The card server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

[0013] The user terminal 30 is a user's computer. For example, the user terminal 30 is a smartphone, a tablet, a personal computer, or a wearable terminal. The user terminal 30 includes a control unit 31, a storage unit 32, a communication unit 33, an operation unit 34, and a display unit 35. The hardware configurations of the control unit 31, the storage unit 32, and the communication unit 33 may be similar to those of the control unit 11, the storage unit 12, and the communication unit 13, respectively. The communication unit 33 is a Near Field Communication (NFC) The operation unit 34 is an input device such as a touch panel or a mouse. The display unit 35 is a display such as a liquid crystal or organic EL display.

[0014] The programs stored in the storage units 12, 22, 32 may be supplied to the payment server 10, the card server 20, or the user terminal 30 via the network N. Also, at least one of a reading unit (e.g., a memory card slot) that reads a computer-readable information storage medium and an input / output unit (e.g., a USB port) for inputting and outputting data to and from an external device may be included in the payment server 10, the card server 20, or the user terminal 30. For example, a program stored in an information storage medium may be supplied to the payment server 10, the card server 20, or the user terminal 30 via at least one of the reading unit and the input / output unit.

[0015] Furthermore, the card judgment system 1 only needs to include at least one computer. The computers included in the card judgment system 1 are not limited to the example in FIG. 1. For example, the card judgment system 1 may include only the payment server 10 and the user terminal 30. In this case, the card server 20 exists outside the card judgment system 1. The card judgment system 1 may also include only the payment server 10. In this case, the card server 20 and the user terminal 30 exist outside the card judgment system 1. For example, the card judgment system 1 may include the payment server 10 and other computers not shown in FIG. 1.

[0016] [2. Overview of the card judgment system] In this embodiment, a user applies for issuance of a card to a card company. The application for issuance of a card may be made in accordance with a known procedure. For example, the user operates the user terminal 30 to access the card company's website. The user inputs information required for issuance of a card (e.g., a phone number) into the card company's website. At least a portion of the information required for issuance of a card may be reused from other services, such as e-commerce services. The user operates the user terminal 30 to upload identification documents required for issuance of a card. The application for issuance of a card may be made offline. For example, the user may apply for issuance of a card in writing.

[0017] For example, when a user completes an application for card issuance, the card company conducts an examination for issuing the card. The examination may be conducted in accordance with known procedures and standards. If the user passes the examination, the card company issues a physical card, which is a physical card. The physical card may be of a known type. For example, the physical card may be an NFC-enabled IC card, a non-NFC-enabled IC card, a magnetic card, or any other type. The card company ships the physical card to an address specified by the user. The user receives the physical card from the card company via a delivery company. In this way, the user can use the physical card.

[0018] For example, it takes a certain amount of time from when a user passes the screening until the physical card arrives in the user's hands. This time can be as short as a few days or as long as a week or more. During this time, the user has not received the physical card and cannot use it. For example, even if the user tries to use the physical card for a payment service, the user does not have the physical card in hand, so the user cannot know the card number. The user also cannot know the security code written on the back of the physical card.

[0019] Therefore, in this embodiment, a user can use a virtual card, which is a virtual card, while waiting for the physical card to arrive. A virtual card is a card that does not have a physical entity. In other words, a virtual card can be a card that a user can use while waiting for the physical card to arrive. The information on the virtual card may basically be the same as the information on the physical card. For example, the card number, expiration date, cardholder, and security code of the virtual card are the same as the card number, expiration date, cardholder, and security code of the physical card, respectively. Note that at least a portion of the information on the virtual card may differ from at least a portion of the information on the physical card.

[0020] Note that the virtual card is not limited to a card that can be used for payment or the like with credit card information until the physical card is delivered to the user. The virtual card may also be a card that can be used for payment or the like with credit card information such as a card number and expiration date without a physical card being issued. For example, the virtual card may not only be used temporarily, but may also be issued as a virtual card only depending on the user's request. In this embodiment, the virtual card is described as a card, but it means that the virtual card is not issued in the form of a card, but is issued with credit card information such as a card number and expiration date.

[0021] Hereinafter, when there is no distinction between a virtual card and a physical card, they will simply be referred to as a card. In this embodiment, the user can use the virtual card with the payment service while waiting for the physical card to arrive. The user can use any payment method with the payment service. A payment method is a method used by the user for payment. For example, a payment method may be a credit card, electronic money, points, cryptocurrency, debit card, wallet, account such as a bank account, or other method. Codes such as barcodes or two-dimensional codes are also a means for payment, and therefore correspond to a payment method. A payment method can also be called a payment method because it is sometimes used for payment.

[0022] In this embodiment, an example is taken of a case where a user makes a payment using a payment app installed on user terminal 30. The payment app is an application provided by a business operator that operates a payment service. For example, if the user has not yet registered as a member of the payment service, the user registers as a member of the payment service from the payment app. After installing the payment app on user terminal 30, the user launches the payment app to register as a member of the payment service. For example, the user performs the procedure for registering as a member of the payment service from the payment app.

[0023] FIG. 2 is a diagram showing an example of the flow of a user registering as a member of a payment service. In this embodiment, when a user proceeds with membership registration for the payment service, the user terminal 30 displays a pre-authentication screen SC1 on the display unit 35, as shown in the upper left of FIG. 2, requesting pre-authentication from the user. Pre-authentication is authentication that is performed before the first authentication and second authentication described below. For example, pre-authentication is performed at the time of membership registration.

[0024] In this embodiment, telephone authentication will be described as an example of pre-authentication. Telephone authentication is authentication that utilizes at least one of making and receiving a call. The method of telephone authentication may be the same as a known method. For example, telephone authentication is performed when the telephone number entered by the user when registering as a member of the payment service matches the telephone number called by the user from the pre-authentication screen SC1. A call is made to the telephone number entered when registering as a member of the payment service, and telephone authentication is performed depending on whether the call is received on the pre-authentication screen SC1.

[0025] For example, if pre-authentication, such as telephone authentication, is successful, the user terminal 30 displays a payment source setting screen SC2 on the display unit 35, as shown in the upper right corner of Figure 2, which accepts the specification of the payment source for the payment service. The payment source is the payment method used for payments in the payment service. The user can specify any payment source. For example, when registering as a member of the payment service, if the user has passed the card screening but has not yet received the physical card, the user can specify a virtual card as the payment source. When registering as a member of the payment service, if the user has already received the physical card, the user can specify the physical card as the payment source. The user can specify a payment method other than a card as the payment source.

[0026] In this embodiment, when a user passes the card screening, the card server 20 links information such as the card number with the payment server 10. In the example in the upper right of FIG. 2, a button B20 for designating a card as a payment source is displayed on the payment source setting screen SC2 based on the linked information. For example, even if the physical card has not yet arrived, the user can set a virtual card as a payment source by selecting button B20. However, in this embodiment, a predetermined authentication is required for the user to set a virtual card as a payment source. Hereinafter, the authentication performed by the user to set a virtual card as a payment source is referred to as the first authentication.

[0027] On the other hand, the user may have already received a physical card when the payment source setting screen SC2 is displayed. In this case, the user can use the physical card as the payment source. In this embodiment, a predetermined authentication is required even when the user sets a physical card as the payment source. Hereinafter, the authentication required for the user to set a physical card as the payment source is referred to as the second authentication. For example, when a user who is using a virtual card (a user who has completed the first authentication) receives a physical card, the second authentication may or may not be necessary. Thus, in this embodiment, the authentication required of the user differs depending on whether the user's card is a virtual card or a physical card.

[0028] FIG. 3 is a diagram showing an example of the flow of a user performing first authentication. When the user selects button B20 on the payment source setting screen SC2 shown in the upper left of FIG. 3, the user terminal 30 displays modal M21 on the payment source setting screen SC2, which allows the user to start first authentication, as shown in the upper right of FIG. 3. In this embodiment, an example is given in which attribute authentication is performed as the first authentication. Attribute authentication is authentication in which the attributes of a user are confirmed. In other words, attribute authentication is authentication in which information that can prove the identity of the user is confirmed. The specific method of attribute authentication may be the same as a known method.

[0029] In this embodiment, an example is taken of a case where two user attributes, a user ID and a phone number, are confirmed in the first authentication. The user ID is an ID that can identify the user in the payment service. The user ID may be common to the payment service and the card service. The user ID may also be common to services other than the payment service and the card service. The user ID may not be common to services other than the payment service, but may be an ID that is valid only for the payment service.

[0030] For example, when the user selects button B22, the first authentication is performed. If the first authentication fails, the user cannot use the virtual card for the payment service. If the first authentication is successful, the user terminal 30 displays a window W23 indicating that the first authentication was successful on the payment source setting screen SC2, as shown in the lower left of Figure 3. Since the first authentication was successful, the virtual card is set as the payment source. When the user selects button B24, the user terminal 30 displays a top screen SC3, which corresponds to the first view of the payment app, on the display unit 35, as shown in the lower right of Figure 3.

[0031] For example, the top screen SC3 includes a code C30 generated based on a code ID that can temporarily identify a user. The code C30 is at least one of a barcode and a two-dimensional code. When the code C30 is read at a store that is a member of the payment service, payment is executed based on the payment method set as the payment source. In the example at the bottom right of FIG. 3, a virtual card is set as the payment source, so payment is executed based on the virtual card. The appearance of the top screen SC3 does not indicate that it is a virtual card. However, the appearance of the top screen SC3 may indicate that it is a virtual card.

[0032] The payment is not limited to the type in which the code C30 displayed on the user terminal 30 is read. The payment may be of any type. For example, the payment may be of the type in which the user terminal 30 reads a code displayed on a terminal in a store, the type in which the user terminal 30 reads a code posted in a store, the type in which the payment is completed by operating the user terminal 30 alone (e.g., ID payment or account payment), the type in which an IC chip in the user terminal 30 is used, carrier payment which is payment by the carrier used by the user terminal 30, or any other type.

[0033] FIG. 4 is a diagram showing an example of the flow of a user performing second authentication. When the user selects button B20 on the payment source setting screen SC2 shown in the upper left of FIG. 4, the user terminal 30 displays modal M25 for starting second authentication on the payment source setting screen SC2, as shown in the upper right of FIG. 4. In this embodiment, an example is given in which possession authentication is performed as the second authentication. Possession authentication is authentication that confirms that the user has the card in their possession. The specific method of possession authentication may be the same as known methods. For example, possession authentication may be scan authentication performed by reading the card.

[0034] In this embodiment, a case will be taken as an example in which the user confirms that they have a card by reading (scanning) the card using the NFC function of the communication unit 33. For example, when the user reads the card, the second authentication is executed. If the second authentication fails, the user cannot use the physical card for the payment service. If the second authentication is successful, the user terminal 30 displays a window W26 indicating that the second authentication was successful on the payment source setting screen SC2, as shown in the lower left of FIG. 4. Since the second authentication was successful, the physical card is set as the payment source. If the user selects button B27, the user terminal 30 displays a top screen SC3 including a code C30 on the display unit 35, as shown in the lower right of FIG. 4.

[0035] As described above, the card determination system 1 of this embodiment determines whether a user's card is a virtual card or a physical card when payment source usage settings are made. If the user's card is a virtual card, the card determination system 1 performs a first authentication to set the virtual card as the payment source. If the user's card is a physical card, the card determination system 1 performs a second authentication to set the physical card as the payment source. This allows the card determination system 1 to perform flexible management according to the card. Details of the card determination system 1 will be described below.

[0036] [3. Functions realized by the card judgment system] Figure 5 is a diagram showing an example of the functions realized by the card judgment system 1. The units realized by the card judgment system 1 can be configured as a single device, or as more finely divided devices.

[0037] [3-1. Functions realized by the payment server] For example, the payment server 10 includes a data storage unit 100, a usage setting request receiving unit 101, a card judgment unit 102, a pre-authentication execution unit 103, a first authentication execution unit 104, a first usage setting unit 105, a second authentication execution unit 106, and a second usage setting unit 107. The data storage unit 100 is realized by the memory unit 12. The usage setting request receiving unit 101, the card judgment unit 102, the pre-authentication execution unit 103, the first authentication execution unit 104, the first usage setting unit 105, the second authentication execution unit 106, and the second usage setting unit 107 are each realized by the control unit 11.

[0038] [Data storage section] The data storage unit 100 stores data necessary for the payment service. For example, the data storage unit 100 stores a payment database DB1.

[0039] FIG. 6 is a diagram showing an example of payment database DB1. Payment database DB1 is a database that stores various information related to users of payment services. For example, payment database DB1 stores user IDs, passwords, code IDs, telephone numbers, payment method information, payment source information, and charging source information. Payment database DB1 may also store other data. For example, payment database DB1 may store usage history information related to the usage history of payment services.

[0040] The user ID is an example of user identification information that can identify a user. A login account may exist in addition to the user ID. The login account may be freely changeable by the user. The login account is also an example of user identification information. A password is information that is confirmed when logging in. The code ID is also an example of user identification information, as it is an ID that can identify a user in the payment service. The code ID is updated each time the code C30 is displayed. The user identification information may be information other than the user ID, login account, and code ID.

[0041] In this embodiment, an example is given in which the user ID is common to the payment service and the card service. Furthermore, an example is given in which the user ID is also common to other services, such as an e-commerce service. For example, when a user starts membership registration for a payment service, the user executes a predetermined login process using information already issued by the card service or other service. If the login process is successful, the payment server 10 creates a record for the user in the payment database DB1 and stores information such as the user ID in the record. Some information in the record may not be stored at the start of membership registration. Information may be registered in the record as the user proceeds with membership registration.

[0042] The telephone number stored in the payment database DB1 is the telephone number used in pre-authentication. The payment method information is information that allows a user to identify the payment methods that can be used for payment services. The payment method indicated by the payment method information can be said to be a payment method that is a candidate for at least one of the payment source and the charge source. For example, the payment method information is information such as a credit card number, electronic money number, bank account information, or point card number.

[0043] In this embodiment, when a user passes card screening, the payment server 10 acquires card information of the virtual card from the card server 20. The payment server 10 may acquire card information of the virtual card immediately after the user passes card screening. In this case, the payment server 10 may acquire a user ID from the card server 20 so as to identify which user's virtual card it is. The payment server 10 may store the user ID and card information acquired from the card server 20 in the payment database DB1 before the user starts membership registration for the payment service.

[0044] For example, the payment server 10 may obtain card information of the virtual card from the card server 20 when a user begins membership registration for a payment service. The payment server 10 may store the card information of the virtual card in the payment database DB1 as one piece of payment method information. Based on the card information stored as one piece of payment method information, button B20 on the payment source setting screen SC2 is displayed. The payment source information stored in the payment database DB1 is information that can identify the payment method set as the payment source. The charging source information stored in the payment database DB1 is information that can identify the payment method set as the charging source. Charging is a process of increasing the balance of electronic money. The charging source is the payment method that serves as the source of funds for charging.

[0045] The data stored in the data storage unit 100 is not limited to the above example. The data storage unit 100 may store any data necessary for the payment service. For example, the data storage unit 100 may store data necessary for displaying each of the pre-authentication screen SC1, the payment source setting screen SC2, and the top screen SC3. The data storage unit 100 may store data necessary for each of the pre-authentication, the first authentication, and the second authentication.

[0046] [Usage setting request reception unit] The usage setting request receiving unit 101 receives, from the user terminal 30, a usage setting request regarding the usage setting of a card used by a user for a payment service. A payment service is an example of a predetermined service. Therefore, the phrase "payment service" can be read as "predetermined service." The predetermined service is not limited to a payment service. The predetermined service may be any service that allows the user to use a card. For example, the predetermined service may be an e-commerce service, a travel reservation service, a ticket reservation service, a communication service, an online flea market service, a financial service, or other services.

[0047] The usage settings are settings related to card usage. For example, whether or not to use a card for a specific service corresponds to the usage settings. The extent to which a card is used for a specific service corresponds to the usage settings. If a user can use multiple cards, the usage priority set for each card corresponds to the usage settings. The usage settings may be settings for changing the card's upper limit. The usage settings are not limited to settings for a payment app, but may also be settings for contactless payment. The usage settings may be new usage settings or updates to existing usage settings. The usage setting request is data indicating a request for usage settings. In the examples of FIGS. 2 to 4, data indicating that the user selected button B20 corresponds to the usage setting request. The usage setting request may also be data indicating that the user has performed another operation for usage settings. The usage setting request may be sent from the user terminal 30 without the user performing any particular operation.

[0048] In this embodiment, the predetermined service is a payment service in which payment is performed based on a card, and therefore the usage setting request receiving unit 101 receives a usage setting request regarding the usage settings of a payment source or a charge source used by the user in the payment service. While the examples in FIGS. 3 and 4 illustrate a case in which usage settings of a payment source are performed, the usage setting request may also be usage settings of a charge source. For example, data indicating that a user has designated a virtual card or a physical card as a charge source may correspond to the usage setting request. The usage setting may also be settings other than a payment source or a charge source. For example, the usage setting may be a setting for using a card for identity verification. If the card is used for another purpose in the predetermined service, a usage setting for that other purpose may also exist.

[0049] [Card Judging Department] When a usage setting request is received, the card determination unit 102 determines whether the card is a virtual card or a physical card. In this embodiment, the card determination unit 102 acquires a card flag indicating whether the card is a virtual card or a physical card from the card server 20, and determines whether the card is a virtual card or a physical card based on the card flag. For example, the card flag indicates either a first value indicating that the card is a virtual card or a second value indicating that the card is a physical card.

[0050] For example, the card determination unit 102 requests the card server 20 to acquire a card flag. The card determination unit 102 also requests user identification information from the card server 20 that can identify the user for whom the card flag is to be acquired. The card server 20 may store the card flag itself, or may store only information necessary for generating the card flag (for example, delivery history information, which will be described later) without storing the card flag. In this embodiment, an example is given in which the card server 20 stores the card flag itself. The card determination unit 102 acquires the card flag stored in the card server 20 from the card server 20. If the card flag has a first value, the card determination unit 102 determines that the card is a virtual card. If the card flag has a second value, the card determination unit 102 determines that the card is a physical card.

[0051] In this embodiment, the card determination unit 102 determines that a card is a virtual card when the usage setting request is received before a physical card is issued and delivered to the user. This determination is made using a card flag or delivery history information stored in the card server 20. The card determination unit 102 determines that a card is a physical card when the usage setting request is received after a physical card is issued and delivered to the user. This determination is also made using the card flag or delivery history information stored in the card server 20. Information other than the card flag or delivery history information may also be used for these determinations. An example of the other information will be described in a modified example below.

[0052] Note that a card flag may be stored in the payment database DB1. In this case, the card determination unit 102 may determine whether the card is a virtual card or a physical card based on the card flag stored in the payment database DB1, without requesting the card flag from the card server 20. Also, delivery history information may be stored in the payment database DB1. In this case, too, the card determination unit 102 may determine whether the card is a virtual card or a physical card based on the delivery history information stored in the payment database DB1, without requesting the card flag from the card server 20.

[0053] Furthermore, the card flag or delivery history information may be stored in a database other than the payment database DB1, in a computer other than the payment server 10 and the card server 20, or in an external information storage medium. In this case, the card determination unit 102 may acquire the card flag or delivery history information from the other database, the other computer, or the external information storage medium, and determine whether the card is a virtual card or a physical card based on the acquired delivery history information.

[0054] [Pre-authentication execution unit] The pre-authentication executing unit 103 executes pre-authentication. In this embodiment, a case is exemplified in which the pre-authentication executing unit 103 executes pre-authentication before a usage setting request is accepted. The pre-authentication executing unit 103 may execute pre-authentication after the usage setting request is accepted. For example, the pre-authentication executing unit 103 may execute pre-authentication when a usage setting request is accepted and the user has not performed pre-authentication. Thereafter, the first authentication by the user may be executed.

[0055] Pre-authentication is authentication different from the first authentication and the second authentication. In this embodiment, a case where telephone authentication corresponds to pre-authentication is taken as an example. Pre-authentication may be authentication other than telephone authentication. For example, pre-authentication may be SMS authentication, email authentication, biometric authentication, password authentication, secret word authentication, or other authentication. Authentication information used in these pre-authentications may be reused for at least one of the first authentication and the second authentication.

[0056] For example, when a payment service makes a call to a user, the pre-authentication executing unit 103 executes pre-authentication by determining whether the user has answered the call to the user's phone number. The user's phone number may be entered by the user when registering as a member of the payment service, or may be a phone number registered with another service such as a card service. The pre-authentication executing unit 103 determines that pre-authentication has been successful if the user has answered the call. The pre-authentication executing unit 103 determines that pre-authentication has failed if the user has not answered the call.

[0057] For example, when the user answers a call from the payment service, authentication information such as a password may be communicated by voice. In this case, the pre-authentication executing unit 103 may execute pre-authentication by determining whether the authentication information entered by the user into the user terminal 30 matches the authentication information communicated by voice. If the authentication information matches, the pre-authentication executing unit 103 determines that pre-authentication has been successful. If the authentication information does not match, the pre-authentication executing unit 103 determines that pre-authentication has failed.

[0058] For example, when a user makes a call to a payment service, the pre-authentication execution unit 103 executes pre-authentication by determining whether a call has been made from the user's phone number to the phone number of the payment service. If a call has been made from the user's phone number, the pre-authentication execution unit 103 determines that pre-authentication has been successful. If a call has not been made from the user's phone number, the pre-authentication execution unit 103 determines that pre-authentication has failed.

[0059] The pre-authentication executing unit 103 may execute processing according to the authentication method adopted for pre-authentication. For example, if pre-authentication corresponds to SMS authentication, email authentication, biometric authentication, password authentication, secret word authentication, or other authentication, the pre-authentication executing unit 103 may acquire authentication information required for such authentication from the user terminal 30 and execute pre-authentication based on the authentication information. The authentication information required for pre-authentication may also be publicly known information used in such authentication.

[0060] [First authentication execution unit] The first authentication execution unit 104 executes the first authentication when it is determined that the user's card is a virtual card. The first authentication execution unit 104 only needs to execute at least a part of the processing required for the first authentication. For example, the first authentication execution unit 104 executes the first authentication in which user information about the user, which is managed by the card server 20 of the card issuer that issued the card, is confirmed. The card server 20 is an example of a card issuer system. Therefore, any description of the card server 20 can be read as the card issuer system. The card issuer system may include the card server 20 and a computer other than the card server 20.

[0061] The user information is authentication information used in the first authentication. In this embodiment, since the first authentication is attribute authentication, the user information indicates the attributes of the user. For example, the user information indicates a user ID and a phone number. The user information may be any information related to the user. The user information is not limited to a user ID and a phone number. For example, the user information may be only a user ID or only a phone number. The user information may also be the user's name, date of birth, address, or other information.

[0062] In this embodiment, an example is taken of a case where the verification of the validity of user information is executed by the card server 20. For example, the first authentication execution unit 104 acquires the user information to be verified in the first authentication. The first authentication execution unit 104 may acquire the user information from the user terminal 30 or another computer. The first authentication execution unit 104 transmits the user information to the card server 20 and requests verification of the validity. The first authentication execution unit 104 may make the request to the card server 20 via another computer such as a gateway.

[0063] For example, the first authentication executing unit 104 acquires confirmation result information regarding the confirmation result of the user information from the card server 20, and executes the first authentication based on the confirmation result information. The confirmation result information indicates either a valid value, which means that the information is valid, or an invalid value, which means that the information is invalid. If the confirmation result information is a valid value, the first authentication executing unit 104 determines that the first authentication has been successful. If the confirmation result information is an invalid value, the first authentication executing unit 104 determines that the first authentication has failed.

[0064] In this embodiment, when it is determined that the user's card is a virtual card, the first authentication execution unit 104 executes the first authentication based on authentication information authenticated in pre-authentication. The authentication information authenticated in pre-authentication is authentication information whose validity has been confirmed in pre-authentication. For example, the first authentication execution unit 104 executes the first authentication based on a telephone number authenticated in pre-authentication. The telephone number among the user information to be confirmed in the first authentication is the telephone number confirmed in pre-authentication. Therefore, the user can execute the first authentication without having to input the telephone number again.

[0065] For example, when it is determined that the card is a virtual card, the first authentication execution unit 104 may execute a first authentication in which authentication information about the user held by the card administrator (e.g., the card company) is compared with authentication information about the user at the time of receiving the usage setting request. For example, the authentication information about the user at the time of receiving the usage setting request is authentication information about the user held in the payment server 10. The authentication information about the user at the time of receiving the usage setting request may be authentication information about the user obtained from the user terminal 30.

[0066] In this embodiment, the authentication information is user information, but the authentication information may be other information other than information about the user. For example, the authentication information may be other information such as a password. For example, it may be authentication information (e.g., an authentication code) issued by the card server 20 (a card company). The first authentication execution unit 104 acquires confirmation result information, which is the result of the comparison between these, from the card server 20, and executes the first authentication by referring to the confirmation result information. If the confirmation result information indicates a match, the first authentication execution unit 104 determines that the first authentication has been successful, and if the confirmation result information does not indicate a match, the first authentication has failed. The authentication information about the user may be authentication information at the time of applying for a card.

[0067] The first authentication executing unit 104 may execute the first authentication without making a request to the card server 20. In this case, the first authentication executing unit 104 may request a computer other than the card server 20 to confirm the validity of the user information. The first authentication executing unit 104 may acquire confirmation result information from the other computer and execute the first authentication based on the confirmation result information. The other computer executes the same process as the process described as being executed by the card server 20. The other computer transmits confirmation result information indicating the processing result to the payment server 10.

[0068] Furthermore, the first authentication execution unit 104 may execute the first authentication without making a request to the card server 20 or the like. When the information necessary for the first authentication is stored in the data storage unit 100, the first authentication execution unit 104 may execute the first authentication so that it is completed only within the payment server 10. The first authentication execution unit 104 may execute the first authentication by comparing authentication information about the user held by the card administrator with authentication information about the user at the time of receiving the usage setting request. For example, if these match, the first authentication execution unit 104 determines that the first authentication has been successful, and if they do not match, the first authentication has been unsuccessful.

[0069] [1st usage setting section] The first usage setting unit 105 performs usage settings based on the execution result of the first authentication. For example, if the first authentication is successful, the first usage setting unit 105 performs usage settings for the virtual card. If the first authentication fails, the first usage setting unit 105 does not perform usage settings for the virtual card. In this embodiment, the first usage setting unit 105 performs usage settings by updating the payment source information or charging source information stored in the payment database DB1. For example, the first usage setting unit 105 updates the payment source information or charging source information so that the payment source information or charging source information indicates the virtual card.

[0070] The first usage setting unit 105 may perform the usage setting by storing the information of the usage setting in the payment database DB1 or another database. For example, if information other than the payment source information and the charging source information indicates whether the user will use a virtual card, the first usage setting unit 105 may perform the usage setting by generating or updating the other information. If the usage setting is a change in the card's upper limit, the first usage setting unit 105 may perform the usage setting by changing the information indicating the upper limit. If the usage setting is something else, the first usage setting unit 105 may perform the usage setting by generating or updating the information indicating the other content.

[0071] [Second authentication execution unit] The second authentication execution unit 106 executes the second authentication when it is determined that the user's card is a physical card. The second authentication is different from the first authentication. For example, the second authentication may be authentication that cannot be successful without the physical card. The second authentication may be performed by taking a photo of the physical card, entering letters or numbers printed on the physical card, or other actions other than reading the physical card. The second authentication may be authentication that does not particularly use a physical card. For example, the second authentication may be authentication with higher security than the first authentication. The second authentication can also be authentication that uses authentication information different from that used for the first authentication.

[0072] In this embodiment, the second authentication is possession authentication, and therefore, when it is determined that the card is a physical card, the second authentication execution unit 106 executes second authentication using the physical card. Each of the second authentications may be any authentication and is not limited to the example of this embodiment. For example, the second authentication may be authentication called 3D Secure. 3D Secure is authentication using a password registered in advance by the user. The second authentication may be other authentication such as authentication called CVV2 or biometric authentication. When the second authentication is other authentication, the second authentication execution unit 106 executes the second authentication based on authentication information corresponding to the second authentication.

[0073] In this embodiment, the case where the validation of card information obtained from a physical card is executed by the card server 20 will be exemplified. For example, the second authentication execution unit 106 acquires card information to be validated in the second authentication. For example, the second authentication execution unit 106 acquires card information stored in an IC chip of the physical card. The card information may be any information stored in the IC chip of the physical card, such as a card number, an electronic money number for a card with an electronic money function, a point number for a card with a point card function, or other information. The second authentication execution unit 106 transmits the card information to the card server 20 and requests validation of the card information. The second authentication execution unit 106 may make the request to the card server 20 via another computer such as a gateway.

[0074] For example, the second authentication execution unit 106 acquires confirmation result information regarding the confirmation result of the card information from the card server 20, and executes the second authentication based on the confirmation result information. The confirmation result information indicates either a valid value, which means that the card information is valid, or an invalid value, which means that the card information is invalid. If the confirmation result information is a valid value, the second authentication execution unit 106 determines that the second authentication has been successful. If the confirmation result information is an invalid value, the second authentication execution unit 106 determines that the second authentication has failed.

[0075] The second authentication execution unit 106 may execute the second authentication without making a request to the card server 20. In this case, the second authentication execution unit 106 may request a computer other than the card server 20 to confirm the validity of the card information. The second authentication execution unit 106 may acquire confirmation result information from the other computer and execute the second authentication based on the confirmation result information. The other computer executes the same process as the process described as being executed by the card server 20. The other computer transmits confirmation result information indicating the processing result to the payment server 10.

[0076] Furthermore, the second authentication execution unit 106 may execute the second authentication without making a request to the card server 20 or the like. When the information necessary for the second authentication is stored in the data storage unit 100, the second authentication execution unit 106 may execute the second authentication so that it is completed only within the payment server 10. For example, the data storage unit 100 stores authentication information such as card information that is the correct answer for the second authentication. The second authentication execution unit 106 executes the second authentication based on the authentication information that is the correct answer stored in the data storage unit 100 and authentication information obtained by reading a physical card or the like.

[0077] [Second usage setting section] The second usage setting unit 107 performs usage settings based on the execution result of the second authentication. If the second authentication is successful, the second usage setting unit 107 performs usage settings for the physical card. If the second authentication fails, the second usage setting unit 107 does not perform usage settings for the physical card. In this embodiment, the second usage setting unit 107 performs usage settings by updating the payment source information or charging source information stored in the payment database DB1. For example, the second usage setting unit 107 updates the payment source information or charging source information so that the payment source information or charging source information indicates the physical card. Since the information such as the card number of the virtual card and the physical card is the same, if the virtual card is already the payment source information or charging source information, the payment source information or charging source information may not be changed.

[0078] The second usage setting unit 107 may perform the usage setting by storing the information of the usage setting in the payment database DB1 or another database. For example, if information other than the payment source information and the charging source information indicates whether the user will use a virtual card, the second usage setting unit 107 may perform the usage setting by generating or updating the other information. If the usage setting is a change in the card's upper limit, the second usage setting unit 107 may perform the usage setting by changing the information indicating the upper limit. If the usage setting is something else, the second usage setting unit 107 may perform the usage setting by generating or updating the information indicating the other content.

[0079] Furthermore, if the card determination unit 102 determines that the card is a physical card after the first usage setting unit 105 has performed the usage setting, the usage setting by the first usage setting unit 105 may be cancelled. For example, the payment server 10 returns the user's usage setting to its original state (the state before the first usage setting unit 105 performed the usage setting). In this case, the user may be unable to use the virtual card. Because the user has a physical card in hand, the user must successfully complete the second authentication in order to use the same card number as the virtual card (i.e., the physical card) for the payment service. If the second authentication is successful, the second usage setting unit 107 performs the usage setting for the physical card.

[0080] [3-2. Functions realized by card servers] For example, card server 20 includes data storage unit 200, delivery determination unit 201, card determination unit 202, first authentication execution unit 203, and second authentication execution unit 204. Data storage unit 200 is realized by memory unit 22. Delivery determination unit 201, card determination unit 202, first authentication execution unit 203, and second authentication execution unit 204 are each realized by control unit 21.

[0081] [Data storage section] The data storage unit 200 stores data necessary for card services. For example, the data storage unit 200 stores a card database DB2.

[0082] 7 is a diagram showing an example of the card database DB2. The card database DB2 is a database that stores various information related to users in the card service. For example, the card database DB2 stores user IDs, passwords, application information, card information, delivery history information, and card flags. The card database DB2 may also store other data.

[0083] In this embodiment, it is assumed that the user ID for the payment service and the user ID for the card service are the same. If the user ID for the payment service and the user ID for the card service are different from each other, a relational database indicating the relationship between the user ID for the payment service and the user ID for the card service is stored in the data storage unit 200. The relational database may be stored in the payment server 10, another computer, or an external information storage medium.

[0084] The application information is information entered by the user when applying for a card. For example, the application information may indicate a telephone number, address, date of birth, gender, occupation, annual income, family composition, or other information. When a user logs in to a card service and applies, card server 20 associates the application information entered by the user when applying with the user's user ID and stores it in card database DB2. The application information may also be information registered in other services other than the card service.

[0085] The card information indicates various information related to the card. For example, the card information indicates each of the credit card number, expiration date, cardholder name, and security code. The card information may indicate the electronic money number of a card with an electronic money function, the point number of a card with a point card function, or other information. The delivery history information is information related to the delivery history of the delivery service. For example, the delivery history information is the delivery service's slip number, delivery address, telephone number, and delivery status. The delivery status indicates information such as whether delivery is required, whether delivery is pending, whether delivery is in progress, or whether delivery is complete. The card server 20 obtains the latest delivery history information from the delivery company's system and updates the delivery history information in the card database DB2. Note that instead of the card server 20 obtaining the delivery history information, the delivery history information in the card database DB2 may be manually entered or updated.

[0086] The card flag is a flag that indicates whether the card is a virtual card or a physical card. For example, the card flag indicates either a first value that means the card is a virtual card, or a second value that means the card is a physical card. The initial value of the card flag is the first value. In this embodiment, the card flag is updated by the delivery determination unit 201. The card flag may also be updated based on other conditions. The other conditions will be described in a modified example below.

[0087] The data storage unit 200 may store data according to the card service. For example, the data storage unit 200 may store information required for at least one of the first authentication and the second authentication. The data storage unit 200 may store information required for providing the card service.

[0088] [Delivery Judgment Department] The delivery determination unit 201 determines whether a physical card has been delivered to a user based on delivery history information related to the delivery history of a delivery service that delivers physical cards to users. The delivery determination unit 201 determines whether the physical card has not yet been delivered to a user or whether the physical card has been delivered to a user based on delivery history information related to the delivery history of a delivery service that delivers physical cards to users. If the delivery history information associated with a user's user ID does not indicate that delivery has been completed, the delivery determination unit 201 does not update the card flag associated with the user ID. If the delivery history information associated with a user's user ID indicates that delivery has been completed, the delivery determination unit 201 updates the card flag associated with the user ID so that the card flag indicates that the user ID has delivered a physical card.

[0089] [Card Judging Department] The card determination unit 202 executes processing for the card service and the payment service to cooperate with each other. For example, the card determination unit 202 receives, from the payment server 10, a request to acquire a card flag indicating whether the card is a virtual card or a physical card. The card determination unit 202 acquires the card flag from the card database DB2. The card determination unit 202 transmits the card flag to the payment server 10. The card determination unit 202 may transmit delivery history information to the payment server 10 instead of the card flag. Note that the card determination unit 202 may include the delivery determination unit 201. In this case, the card determination unit 202 may determine whether the card is a physical card or a virtual card by determining whether the physical card has been delivered to the user based on the delivery history information. The card determination unit 202 may determine whether the card is a physical card or a virtual card based on information other than the delivery history information.

[0090] [First authentication execution unit] The first authentication executing unit 203 executes the first authentication. The first authentication executing unit 203 only needs to execute at least a part of the processing required for the first authentication. In this embodiment, the first authentication executing unit 203 executes processing to assist the processing of the first authentication executing unit 104 of the payment server 10. For example, when the payment server 10 requests the first authentication executing unit 203 to confirm the authenticity of user information, the first authentication executing unit 203 determines whether the user information received from the payment server 10 matches the user information stored in the card database DB2. In this embodiment, since the user information is a pair of a user ID and a phone number, the first authentication executing unit 203 determines whether the pair exists in the card database DB2. If the pair exists, the first authentication executing unit 203 determines that the user information is authentic. If the pair does not exist, the first authentication executing unit 203 determines that the user information is invalid. The first authentication executing unit 203 transmits confirmation result information to the payment server 10.

[0091] [Second authentication execution unit] The second authentication execution unit 204 executes the second authentication. The second authentication execution unit 204 only needs to execute at least a part of the processing required for the second authentication. In this embodiment, the second authentication execution unit 204 executes processing to assist the processing of the second authentication execution unit 106 of the payment server 10. For example, when the payment server 10 requests the second authentication execution unit 204 to confirm the authenticity of card information, the second authentication execution unit 204 determines whether the card information received from the payment server 10 matches the card information stored in the card database DB2. For example, if the card information is an electronic money number of a card with an electronic money function, the second authentication execution unit 204 determines whether the electronic money number is associated with the user ID of the user in the card database DB2. If the electronic money number is associated with the user ID, the second authentication execution unit 204 determines that the card information is authentic. If the electronic money number is not associated with the user ID, the second authentication execution unit 204 determines that the card information is invalid. The second authentication execution unit 204 transmits the confirmation result information to the payment server 10.

[0092] [3-3. Functions implemented on user devices] For example, the user terminal 30 includes a data storage unit 300, an operation reception unit 301, and a display control unit 302. The data storage unit 300 is realized by the storage unit 32. The operation reception unit 301 and the display control unit 302 are realized by the control unit 31.

[0093] [Data storage section] The data storage unit 300 stores data necessary for a user to use each of the payment service and the card service. For example, the data storage unit 300 stores a payment app. When a user uses a payment service from a browser instead of the payment app, the data storage unit 300 stores the browser.

[0094] [Operation reception section] The operation reception unit 301 receives various operations from the user. For example, the operation reception unit 301 receives operations for the payment application. The operation reception unit 301 transmits data indicating the content of the user's operation to the payment server 10 or the card server 20.

[0095] [Display control section] The display control unit 302 displays various screens on the display unit 35. For example, the display control unit 302 displays a pre-authentication screen SC1, a payment source setting screen SC2, and a top screen SC3 on the display unit 35. The display control unit 302 communicates with the payment server 10, the card server 20, or another computer, receives data necessary to display these screens, and displays these screens on the display unit 35.

[0096] [4. Processing performed by the card judgment system] Fig. 8 is a diagram showing an example of processing executed by the card judgment system 1. The processing of Fig. 8 is executed by the control units 11, 21, and 31 executing programs stored in the storage units 12, 22, and 32, respectively. Fig. 8 explains the processing when a user passes the card screening.

[0097] As shown in Figure 8, when a user passes the card screening, card server 20 executes a process to link various information related to the card (e.g., card number) with payment server 10 (S1). By the process of S1, information necessary for using the virtual card is linked to payment server 10. Payment server 10 also acquires the user ID of the user who passed the card screening from card server 20. Payment server 10 associates the user ID with the information necessary for using the virtual card and stores them in payment database DB1 or another database.

[0098] When the user launches the payment app, the user terminal 30 executes processing to start the payment service membership registration procedure with the payment server 10 (S2). In S2, the user inputs information required for membership registration. In this embodiment, the user ID for the payment service and the user ID for the card service are the same, and since the user ID has already been issued, the user may log in based on the user ID. In this case, information such as the name registered by the user with the card service may be carried over to the payment service.

[0099] When the member registration procedure has progressed to a certain extent, the user terminal 30 executes processing with the payment server 10 to display a pre-authentication screen SC1 (S3). The user terminal 30 executes telephone authentication, an example of pre-authentication, with the payment server 10 (S4). Note that the timing at which pre-authentication is executed is not limited to the time of member registration, but may be other timing, such as when the user registers a phone number. If telephone authentication, an example of pre-authentication, is successful, the user terminal 30 executes processing with the payment server 10 to display a payment source setting screen SC2 (S5). If telephone authentication fails, the processing from S5 onwards is not executed, and this processing ends.

[0100] When the user selects button B20, the user terminal 30 transmits a usage setting request to the payment server 10 to set the user's card as the payment source (S6). The payment server 10 accepts the usage setting request from the user terminal 30 (S7). The payment server 10 executes processing with the card server 20 to acquire a card flag indicating whether the card is a virtual card or a physical card (S8).

[0101] In S8, the payment server 10 transmits the user ID of the user to be judged to the card server 20. The card server 20 receives the user ID from the payment server 10. The card server 20 refers to the card database DB2 and acquires a card flag associated with the user ID. The card server 20 transmits the card flag to the payment server 10. The payment server 10 receives the card flag from the card server 20. Note that in S8, the payment server 10 may transmit card information to the card server 20 instead of the user ID. The payment server 10 may transmit both the user ID and card information to the card server 20. For example, if a user holds multiple cards, the card server 20 can identify which card is the target based on the card information.

[0102] The payment server 10 determines whether the card is a virtual card or a physical card based on the card flag acquired in S8 (S9). If it is determined in S9 that the card is a virtual card (S9: virtual card), the payment server 10 executes attribute authentication, which is an example of first authentication, between the card server 20 and the user terminal 30 (S10). In S10, the payment server 10 executes processing to display modal M21 with the user terminal 30. When the user selects button B22, the payment server 10 transmits the user ID and the phone number used in pre-authentication to the card server 20. Upon receiving the user ID and phone number from the payment server 10, the card server 20 determines whether these pairs exist in the card database DB2. The card server 20 transmits confirmation result information to the payment server 10. The payment server 10 refers to the confirmation result information and determines whether the first authentication was successful. If the first authentication was successful, the payment server 10 sets the virtual card as the payment source (S11), and this processing ends.

[0103] If it is determined in S9 that the card is a physical card (S9: physical card), the payment server 10 executes possession authentication, which is an example of second authentication, between the card server 20 and the user terminal 30 (S12). In S12, the payment server 10 executes processing to display a modal M25 between the user terminal 30 and the payment server 20. When the user reads the physical card, the payment server 10 transmits the user ID and the card information read from the physical card to the card server 20. When the card server 20 receives the user ID and the card information from the payment server 10, it determines whether or not a pair of these exists in the card database DB2. The card server 20 transmits confirmation result information to the payment server 10. Note that the flow of possession authentication is not limited to the example of this embodiment. For example, possession authentication may be executed by the payment server 10 determining whether or not the user ID of the currently logged-in user and the card information read from the physical card match those stored in the database in the payment server 10. The payment server 10 references the confirmation result information and determines whether or not the second authentication is successful. If the second authentication is successful, the payment server 10 sets the physical card as the payment source (S13), and this process ends.

[0104] [5. Summary of embodiments] The card determination system 1 of this embodiment receives a usage setting request from the user terminal 30. When the usage setting request is received, the card determination system 1 determines whether the card is a virtual card or a physical card. This enables the card determination system 1 to manage cards according to whether the card is a virtual card or a physical card. For example, the card determination system 1 can perform different subsequent processes depending on whether the card is a virtual card or a physical card. Examples of subsequent processes include first authentication and second authentication. The card determination system 1 can execute a certain process if the card is a virtual card and not execute the process if the card is a physical card, thereby determining whether or not to execute the process depending on whether the card is a virtual card or a physical card. Similarly, the card determination system 1 can execute a certain process if the card is a physical card and not execute the process if the card is a virtual card, thereby determining whether or not to execute the process depending on whether the card is a virtual card or a physical card. For example, if virtual cards and physical cards are not distinguished, the choice of which card to use is left to the user's discretion. Therefore, users who are particularly accustomed to physical cards may not use virtual cards even if they are issued. In this case, the usage rate of virtual cards is not sufficiently increased. In this regard, the card determination system 1 can manage virtual cards and physical cards separately, thereby increasing the usage rate of virtual cards. In other words, the card determination system 1 can support users in using virtual cards.

[0105] Furthermore, the card determination system 1 determines that a card is a virtual card if a usage setting request is received before a physical card is issued and delivered to a user. The card determination system 1 determines that a card is a physical card if a usage setting request is received after a physical card is issued and delivered to a user. This allows the card determination system 1 to accurately determine whether a card is a virtual card or a physical card. For example, by treating a card as a virtual card until a physical card is delivered to a user, the user can use the virtual card without waiting for delivery of the physical card. The card determination system 1 can promote card usage.

[0106] Furthermore, the card determination system 1 determines whether the physical card has not yet been delivered to the user or has been delivered to the user based on delivery history information about the delivery history of the delivery service that delivers the physical card to the user, thereby enabling the card determination system 1 to more accurately determine whether the card is a virtual card or a physical card.

[0107] Furthermore, the card determination system 1 performs first authentication when the card is determined to be a virtual card, and performs second authentication when the card is determined to be a physical card. The card determination system 1 performs usage settings based on the results of at least one of the first and second authentications. This allows the card determination system 1 to selectively use authentication depending on whether the card is a virtual card or a physical card, thereby enabling flexible authentication. Regardless of whether the card is a virtual card or a physical card, the card determination system 1 allows users to perform some form of authentication, thereby improving user convenience. For example, virtual cards are authenticated upon application and have a limited usable period, making them less likely to be subject to phishing. Therefore, even if the first authentication is different from the second authentication of a physical card, the risk of fraudulent use is low. Therefore, by making the first authentication simpler than the second authentication, the card determination system 1 improves user convenience.

[0108] Furthermore, if the card is determined to be a physical card, the card determination system 1 performs a second authentication using the physical card. The card determination system 1 can enhance security by using a physical object such as a physical card for the second authentication. For example, even if a malicious third party somehow obtains information such as a card number, the second authentication cannot be successful unless the physical card is obtained, so the card determination system 1 can enhance security.

[0109] Furthermore, the card determination system 1 performs a first authentication in which user information acquired from the card server 20 is confirmed. This enables the card determination system 1 to enhance security through the first authentication in which user information strictly managed by the card company is confirmed.

[0110] Furthermore, the card determination system 1 performs pre-authentication, and if it is determined that the card is a virtual card, it performs first authentication based on the authentication information authenticated in pre-authentication. Because the card determination system 1 uses the authentication information authenticated in pre-authentication in the first authentication, the user does not need to re-enter the authentication information, thereby saving the user time and effort.

[0111] Furthermore, when the card is determined to be a virtual card, the card determination system 1 performs a first authentication in which authentication information about the user held by the card administrator is compared with authentication information about the user at the time of receiving the usage setting request. This allows the card determination system 1 to enhance security through the first authentication in which authentication information strictly managed by the card company is confirmed.

[0112] The predetermined service is a payment service in which payment is made based on a card. The card determination system 1 accepts a usage setting request regarding the usage setting of the payment source or charge source used by the user in the payment service. This enables the card determination system 1 to manage the payment service according to the card used.

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

[0114] 9 is a diagram showing an example of functions realized in the modified example. For example, the payment server 10 includes a cancellation unit 108, a storage unit 109, an execution / non-execution information setting unit 110, a bonus granting unit 111, and a screen transition unit 112. Each of the cancellation unit 108, the storage unit 109, the execution / non-execution information setting unit 110, the bonus granting unit 111, and the screen transition unit 112 is realized by the control unit 11.

[0115] [6-1. Variation 1] For example, the card determination unit 102 of the embodiment determines that a card is a physical card when a physical card is delivered to a user. Some users may not receive the physical card because they are away from home for a long period of time or intentionally refuse to receive the physical card. In this case, the user may be able to use the virtual card with the payment app for a long period of time. Such use of the virtual card is not appropriate in terms of its original intention (to allow the user to use the virtual card temporarily until the physical card arrives). Therefore, if a user does not receive the physical card for a long period of time, the use of the virtual card may be prohibited.

[0116] The first usage setting unit 105 of the first modification performs usage settings for the virtual card when it is determined that the card is a virtual card. In the first modification, an example is given in which the use of a virtual card for payment corresponds to the use of the virtual card. That is, an example is given in which the use of a virtual card corresponds to the execution of a payment or charge when the virtual card is set as the payment source or charge source. The use of a virtual card may be any case in which the virtual card is referenced in processing in a payment service. The use of a virtual card is not limited to the example of the first modification. For example, the use of a virtual card may also correspond to the reference of a virtual card for authentication in a payment service.

[0117] For example, when a user's card is determined to be a virtual card, the first usage setting unit 105 updates the payment source information or charging source information of the user so that the virtual card becomes the payment source or charging source. The first usage setting unit 105 stores payment source information indicating that the payment source is a virtual card or charging source information indicating that the charging source is a virtual card in the payment database DB1. The first usage setting unit 105 may also permit the use of the virtual card by recording other information indicating that the user can use the virtual card for the payment service in the data storage unit 100.

[0118] The card determination system 1 of the first modification includes a cancellation unit 108. The cancellation unit 108 of the first modification cancels the usage setting of the virtual card if the physical card is not delivered to the user by a predetermined deadline. Canceling the usage setting means returning the virtual card to the state before usage was permitted. For example, when a user's card is determined to be a virtual card, the cancellation unit 108 updates the payment source information or charging source information of the user so that the virtual card is released as a payment source or charging source. The first usage setting unit 105 may prohibit the use of the virtual card by recording information indicating that the user cannot use the virtual card for the payment service in the data storage unit 100.

[0119] The predetermined deadline may be determined by any method. For example, the predetermined deadline may be a predetermined time (e.g., two months) after the physical card is shipped. The start point of the predetermined deadline may not be the shipping of the physical card, but may be any time point. For example, it may be the time when the user passes the screening, the time when the user applies for issuance of a card, a time point after the physical card is shipped, or any other time point. The payment server 10 may store information indicating the predetermined deadline and determine whether the predetermined deadline has arrived. Alternatively, for example, another computer such as the card server 20 may store the information and determine whether the predetermined deadline has arrived. In this case, the payment server 10 obtains information indicating the determination result of whether the predetermined deadline has arrived from the other computer. The cancellation unit 108 may cancel the usage setting of the virtual card based on the information.

[0120] The card verification system 1 of the first modification cancels the usage setting of the virtual card if the physical card is not delivered to the user by a predetermined deadline. This prevents the virtual card from being used in an unintended manner if the user does not receive the physical card for a long period of time. For example, the card verification system 1 can prevent fraudulent use of the virtual card.

[0121] [6-2. Variation 2] For example, the card determination unit 102 may determine whether the physical card has been delivered to the user or whether the physical card has been delivered to the user based on an operation using the physical card. Hereinafter, this operation is referred to as a physical card use operation. For example, a user performs a physical card use operation. A physical card use operation is an operation that cannot be performed unless the physical card is in hand. In Modification 2, a case is exemplified in which the physical card use operation is an operation of reading the physical card using the NFC function of the communication unit 33. The physical card use operation may be other operations. For example, the physical card use operation may be an operation of photographing the physical card with a camera of the user terminal 30, an operation of reading the physical card using a function other than the NFC function, an operation for making a payment with the physical card in a physical store (e.g., an operation in which the user or a store clerk causes a reader to read the physical card), or other operations. For example, the card server 20 can determine that the user has used the physical card that has been delivered to them (i.e., that delivery of the physical card has been completed) by performing an operation for making a payment with the physical card in a physical store.

[0122] In the second modification, upon receiving the physical card, the user brings the user terminal 30 close to the physical card and uses the NFC function of the communication unit 33 to read the IC chip of the physical card. The user terminal 30 can read any information stored in the IC chip. For example, the user terminal 30 reads the card number, the electronic money number attached to the card, the point number attached to the card, or other information stored in the IC chip. The user terminal 30 transmits the information read from the IC chip to the payment server 10. The payment server 10 receives the information from the user terminal 30. The card determination unit 102 may determine that the physical card has been delivered to the user when information acquired based on the physical card usage operation is received. The method of confirming this information may be the same as the process described as the process of the second authentication execution unit 106 in the embodiment.

[0123] The card determination system 1 of the second modification determines whether the physical card has not yet been delivered to the user or whether the physical card has been delivered to the user, based on the physical card use operation. The card determination system 1 can accurately determine whether the card is a virtual card or a physical card based on the physical card use operation. For example, the card determination system 1 can determine whether the physical card has been delivered to the user, even in an environment where delivery history information cannot be obtained from the delivery company.

[0124] [6-3. Variation 3] For example, the card determination unit 102 may determine whether a card is a virtual card or a physical card based on the delivery period required for delivery of a physical card. The delivery period is a predetermined period generally estimated to be required for delivery of a physical card. The length of the delivery period may be any length. For example, the length of the delivery period may be one to six days, one week, or any other length. The start point (e.g., the starting date) of the delivery period may be any point in time. For example, the start point of the delivery period may be the time when the user's screening is completed, the time when the physical card is issued, the time when the physical card is shipped, or any other time.

[0125] In Modification 3, the delivery period is set to one week after the physical card is shipped. For example, when the physical card is shipped, card server 20 transmits delivery period information to payment server 10, indicating a delivery period of one week from the present time. When payment server 10 receives the delivery period information from card server 20, it stores the delivery period information in payment database DB1. Card determination unit 102 determines whether the delivery period has elapsed based on the delivery period information. If the delivery period has not elapsed, card determination unit 102 determines that the card is a virtual card. If the delivery period has elapsed, card determination unit 102 determines that the card is a physical card. The delivery period information does not need to be stored in payment database DB1. In this case, card determination unit 102 may inquire of card server 20 about delivery period information for each user.

[0126] The card determination system 1 of the third modification determines whether a card is a virtual card or a physical card based on the delivery time required for delivery of a physical card. This allows the card determination system 1 to accurately determine whether a card is a virtual card or a physical card. For example, even in an environment where delivery history information cannot be obtained from a delivery company, the card determination system 1 can determine whether a physical card has been delivered to a user.

[0127] [6-4. Variation 4] For example, in the embodiment, the case where the first authentication is executed based on user information such as a user ID and a telephone number is taken as an example. When the payment server 10 acquires the user information from the card server 20, the payment server 10 may store the user information in the data storage unit 100. In this case, the first authentication execution unit 104 may perform the comparison itself and execute the first authentication without requesting the card server 20 to compare the user information. The user information stored in the data storage unit 100 may be used when the first authentication is required again.

[0128] The card judgment system 1 of the fourth modification includes a retention unit 109. The retention unit 109 retains user information managed by the card server 20 in the data storage unit 100 of the card judgment system 1. Storing user information in the data storage unit 100 means continuing to record the user information in the data storage unit 100 (recording the user information in the data storage unit 100 and not erasing it). For example, the retention unit 109 retains the user information in the data storage unit 100 by storing the user information in the payment database DB1. The retention unit 109 may retain the user information in a database other than the payment database DB1, in a computer other than the payment server 10, or in an external information storage medium.

[0129] The first authentication execution unit 104 of the fourth modification executes the next and subsequent first authentications based on the user information stored in the data storage unit 100. The next and subsequent first authentications refer to first authentications that are executed after the first authentication that caused the user information to be stored in the data storage unit 100. In other words, the second and subsequent first authentications correspond to the next and subsequent first authentications. For example, if first authentications are repeatedly requested while the virtual card is set as the payment source, the first authentication execution unit 104 may acquire the user information stored in the data storage unit 100 and execute the first authentication when the second or subsequent first authentications become necessary without inquiring about user information from the card server 20. This differs from the embodiment in that no inquiry is made to the card server 20, but the processing content of the first authentication itself is the same as that of the embodiment.

[0130] The card determination system 1 of the fourth modification stores user information managed by the card server 20 in the data storage unit 100 of the card determination system 1. The card determination system 1 performs the first authentication from the next time onwards based on the user information stored in the data storage unit 100. This allows the card determination system 1 to omit requesting user information from the card server 20, thereby reducing the processing load and communication load. In cases where a cost is incurred in requesting user information, the card determination system 1 can reduce the cost.

[0131] [6-5. Variation 5] For example, even if the first authentication fails, a user who satisfies certain predetermined conditions may be permitted to set up a virtual card for use. The predetermined conditions are criteria for determining whether or not the virtual card is permitted for use. For example, the predetermined conditions may be determined based on the available balance of the virtual card, the amount of use by the user in services other than the payment service, the user's credit information managed by a credit company or services other than the payment service, user information obtained from other cards, or other information.

[0132] The predetermined condition is not limited to the above example. The predetermined condition may be any condition that the payment service provider deems acceptable for permitting use of the virtual card. The predetermined condition may be that the available balance is lower than when the first authentication is successful. For example, the predetermined condition may be that when the first authentication is successful, the usage limit for one transaction or a predetermined period is a first amount, and when the first authentication is unsuccessful, the usage limit is set to a second amount lower than the first amount. A second authentication may be further requested after delivery of the physical card. According to this configuration, by initially permitting use of the card on the condition that the available balance is kept low, it is possible to improve user convenience while ensuring security. Furthermore, when the second authentication is performed, security can also be enhanced.

[0133] The first usage setup unit 105 of the fifth modification performs usage setup for the virtual card if the first authentication fails and the user satisfies predetermined conditions. If the first authentication fails, the first usage setup unit 105 determines whether the user satisfies predetermined conditions. If the first usage setup unit 105 determines that the user does not satisfy the predetermined conditions, it does not perform usage setup for the virtual card, but if it determines that the user satisfies the predetermined conditions, it performs usage setup for the virtual card. Note that the second authentication execution unit 106 of the fifth modification performs the second authentication when the physical card is delivered to the user. The second authentication in this case is as described in the embodiment.

[0134] For example, if the available balance of the virtual card or the user's usage amount in other services meets a predetermined condition, the first usage setting unit 105 acquires information about the user's usage amount from the other services. Based on the information, the first usage setting unit 105 determines whether the user's usage amount is equal to or greater than a threshold. If the user's usage amount is less than the threshold, the first usage setting unit 105 determines that the user does not meet the predetermined condition, and if the user's usage amount is equal to or greater than the threshold, the first usage setting unit 105 determines that the user meets the predetermined condition.

[0135] For example, if the user's credit information managed by a credit company or a service other than the payment service satisfies the predetermined condition, the first usage setting unit 105 acquires the user's credit information from the credit company or the like. Here, a case will be taken as an example where the credit information is a numerical value indicating the user's creditworthiness. The first usage setting unit 105 determines whether the creditworthiness indicated by the credit information is equal to or greater than a threshold. If the user's creditworthiness is less than the threshold, the first usage setting unit 105 determines that the user does not satisfy the predetermined condition, and if the user's creditworthiness is equal to or greater than the threshold, the first usage setting unit 105 determines that the user satisfies the predetermined condition. Similarly, if the predetermined condition is another condition, the first usage setting unit 105 acquires information necessary for determining whether the predetermined condition is satisfied and determines whether the predetermined condition is satisfied based on the information.

[0136] The card determination system 1 of the fifth modification performs usage setup for a virtual card when the first authentication fails and the user satisfies predetermined conditions. This allows the card determination system 1 to perform usage setup for a virtual card if predetermined conditions are met, even if the user is unable to successfully complete the first authentication, thereby improving user convenience. For example, if the user changes their phone number after applying for a card issuance, the first authentication may fail. Even in such a case, the user only needs to satisfy predetermined conditions, so the card determination system 1 can improve user convenience. The card determination system 1 can reduce opportunity loss by temporarily permitting the user to use a virtual card.

[0137] [6-6. Variation 6] For example, for some reason, it may be appropriate for the card determination system 1 not to perform the first authentication. For example, if a failure occurs in the card determination system 1, there is a possibility that a further failure will occur if the card determination system attempts to perform the first authentication. For this reason, the card determination system 1 may determine whether to perform the first authentication based on execution information regarding whether the first authentication has been performed in the payment service. The execution information indicates either a value indicating that the first authentication will be performed or a value indicating that the first authentication will not be performed. In Variation 6, an example is given in which the execution information is stored in the data storage unit 100. The execution information may be stored in a computer other than the payment server 10 or in an external information storage medium.

[0138] The card determination system 1 of the sixth modification includes an execution / non-execution information setting unit 110. The execution / non-execution information setting unit 110 sets the execution / non-execution information based on predetermined conditions. The predetermined conditions of the sixth modification are different from the predetermined conditions of the fifth modification. The predetermined conditions of the sixth modification are conditions that serve as a criterion for changing the value of the execution / non-execution information. For example, the predetermined conditions may be an administrator of the payment service performing an operation to change the value of the execution / non-execution information, a failure occurring in the card determination system 1, the arrival of a predetermined date and time, the receipt of predetermined information from the card server 20, or other conditions. The execution / non-execution information setting unit 110 sets the execution / non-execution information based on these predetermined conditions.

[0139] The first authentication executing unit 104 of Modification 6 executes the first authentication based on the execution / non-execution information. For example, the first authentication executing unit 104 executes the first authentication when the execution / non-execution information indicates that the first authentication should be executed, and does not execute the first authentication when the execution / non-execution information indicates that the first authentication should not be executed.

[0140] The card determination system 1 of the sixth modification sets execution information regarding whether or not to execute the first authentication for the service based on predetermined conditions. The card determination system 1 executes the first authentication based on the execution information. This allows the card determination system 1 to prevent an attempt to execute the first authentication when there are circumstances that make it impossible to execute the first authentication.

[0141] [6-7. Variation 7] For example, the card determination system 1 may be provided with multiple first authentications. A user may be allowed to perform any one of the multiple first authentications. In Modification 7, an example is given in which 3D Secure is provided as a first authentication in addition to the first authentication described in the embodiment. The number of first authentications is not limited to two as in Modification 7. The card determination system 1 may be provided with three or more first authentications.

[0142] When the card is determined to be a virtual card, the first authentication execution unit 104 of the seventh modification executes the first authentication selected by the user from among the multiple first authentications. For example, when the user selects button B20 on the payment source setting screen SC2, the user terminal 30 causes the display unit 35 to display the payment source setting screen SC2, which allows the user to select one of the multiple first authentications. The user selects one of the multiple first authentications. The user terminal 30 notifies the payment server 10 of the first authentication selected by the user. The first authentication execution unit 104 executes the first authentication selected by the user. First authentications other than the first authentications described in the embodiments may be executed according to a known process. For example, when 3D Secure corresponds to the first authentication, the first authentication execution unit 104 executes the first authentication by determining whether the password entered by the user matches a password previously registered by the user.

[0143] When a card is determined to be a virtual card, the card determination system 1 of the seventh modification executes a first authentication selected by the user from among a plurality of first authentications. This allows the user to select any first authentication from among the plurality of first authentications, so the card determination system 1 can improve user convenience. For example, if a user changes their phone number and is unable to successfully complete telephone authentication, they can execute 3D Secure to use the virtual card for payment services. The card determination system 1 can promote the use of virtual cards by increasing the flexibility of the first authentication.

[0144] [6-8. Variation 8] For example, in the embodiment, a case has been described in which a user can set a virtual card as a payment source before receiving a physical card. In this case, some kind of benefit may be given to the user. The benefit may also be called a reward. For example, the benefit may be points, an increased point award rate, electronic money, a coupon, a free voucher, a product voucher, content such as a video, a lottery ticket, or other benefits. The benefit is not limited to these and may be various well-known benefits.

[0145] The card determination system 1 of the eighth modification example includes a benefit granting unit 111. When the card is determined to be a virtual card, the benefit granting unit 111 grants a predetermined benefit to the user. When the card is determined to be a physical card, the benefit granting unit 111 does not grant the benefit to the user. When the card is determined to be a physical card, the benefit granting unit 111 may grant a different benefit to the user. For example, the benefit granting unit 111 may grant a benefit by associating benefit information indicating a benefit to be granted to the user (e.g., benefit information indicating that a point grant rate is being increased) with a user ID, or may grant a benefit by increasing the user's points, electronic money, or the like. The method of granting a benefit may be the same as a method employed for granting a known benefit. Note that the benefit granting unit 111 may grant a benefit to the user when the card is determined to be a virtual card and usage settings are performed on the card in a virtual card state.

[0146] The card determination system 1 of the eighth modification provides a predetermined benefit to the user when the card is determined to be a virtual card. This allows the card determination system 1 to motivate the user to use the virtual card.

[0147] [6-9. Variation 9] For example, as explained somewhat in Figures 3 and 4, when it is determined that the card is a virtual card or a physical card, the screen may transition to the next screen with the card in a selected state. The state in which the card is selected is a state in which the card is selected as the target card for usage settings. In the example of Figures 3 and 4, when the user selects button B20, the card displayed on button B20 is selected as the target card for usage settings. The screen transitions to the next screen with this card selected state maintained.

[0148] In Variation 9, an example is given in which, when the payment source setting screen SC2 of FIG. 3 is displayed, if the card applied for by the user is displayed on the payment source setting screen SC2 (i.e., if the card applied for by the user has been linked in advance), automatic transition to the next screen (e.g., the payment source setting screen SC2 including modal M21) occurs without the user selecting button B20. The automatic transition operation may occur only a predetermined number of times (e.g., once). Automatic transition may occur whether the card is a virtual card or a physical card. This configuration can improve the usability and utilization rate of cards. Furthermore, by limiting the number of times, the user can be given an opportunity to set a card other than a specific card.

[0149] The card determination system 1 of the ninth modification includes a screen transition unit 112. When a determination is made by the card determination unit 102, the screen transition unit 112 automatically transitions the user terminal 30 to the next screen with the card selected. Automatically transitioning to the next screen means transmitting data required to display the next screen to the user terminal 30 without requiring user operation. In the examples of FIGS. 3 and 4, the screen transition unit 112 transitions to the payment source setting screen SC2 including modals M21 and M25 as the next screen. Therefore, the screen transition unit 112 transitions to the next screen by transmitting data required to display modals M21 and M25 to the user terminal 30.

[0150] The next screen to which the screen transition unit 112 transitions is not limited to the payment source setting screen SC2 including modals M21 and M25. Any screen on which some processing is performed based on the selected card may correspond to the next screen. For example, the screen transition unit 112 may transition the user terminal 30 to a screen for increasing the limit amount of the selected card as the next screen. The screen transition unit 112 may transition the user terminal 30 to a screen for making a payment with the selected card as the next screen. The screen transition unit 112 may transition the user terminal 30 to another screen on which the selected card is used in some way. It is assumed that data necessary for displaying the destination screen is stored in the data storage unit 100.

[0151] The card determination system 1 of the ninth modification automatically transitions the user terminal 30 to the next screen with the card selected when a determination is made by the card determination unit 102. This allows the card determination system 1 to transition to an appropriate screen with the card selected, thereby improving user convenience.

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

[0153] For example, the functions described as being realized by the payment server 10 may be realized by the card server 20, the user terminal 30, or another computer. The processes described as being realized by the payment server 10 may be shared among multiple computers. The processes described as being realized by the card server 20 may be shared among multiple computers.

[0154] [7. Notes] For example, the card judgment system can be configured as follows. (1) a usage setting request receiving unit that receives, from a user terminal of a user, a usage setting request regarding usage settings of a card used by the user for a predetermined service; a card determination unit that determines whether the card is a virtual card or a physical card when the usage setting request is received; A card judging system including: (2) The card determination unit If the usage setting request is received before the physical card is issued and delivered to the user, the card is determined to be the virtual card; If the usage setting request is received after the physical card has been issued and delivered to the user, the card is determined to be the physical card. The card judgment system according to (1). (3) the card determination system further includes a delivery determination unit that determines whether the physical card has been delivered to the user based on delivery history information regarding a delivery history of a delivery service that delivers the physical card to the user; The card determination unit If the usage setting request is received before it is determined that the physical card has been delivered to the user, it is determined that the card is the virtual card; If the usage setting request is received after it is determined that the physical card has been delivered to the user, it is determined that the card is the physical card. (2) A card judgment system according to the present invention. (4) The card judgment system includes: a first usage setting unit that performs the usage setting of the virtual card when the card is determined to be the virtual card; a cancellation unit that cancels the usage setting of the virtual card if the physical card is not delivered to the user by a predetermined deadline; The card judgment system according to (2) or (3) further comprises: (5) the card determination unit determines, based on an operation using the physical card, whether the physical card has not been delivered to the user or has been delivered to the user. A card judgment system according to any one of (2) to (4). (6) the card determination unit determines whether the card is the virtual card or the physical card based on a delivery period required for delivery of the physical card. A card judgment system according to any one of (1) to (5). (7) The card judgment system includes: a first authentication execution unit that executes a first authentication when the card is determined to be the virtual card; a first usage setting unit that performs the usage setting based on a result of the first authentication; a second authentication execution unit that executes a second authentication when the card is determined to be the physical card; a second usage setup unit that performs the usage setup based on a result of the second authentication; The card judgment system according to any one of (1) to (6), further comprising: (8) the second authentication execution unit executes the second authentication using the physical card when it is determined that the card is the physical card. (7) A card judgment system according to (7). (9) the first authentication execution unit executes the first authentication to confirm user information related to the user, the user information being managed by a card issuer system of a card issuer that issued the card; A card judgment system according to (7) or (8). (10) the card judgment system further includes a storage unit that stores the user information managed by the card issuer system in a data storage unit of the card judgment system; the first authentication execution unit executes the first authentication from the next time onwards based on the user information stored in the data storage unit. (9) A card judgment system according to (9). (11) the first usage setup unit performs the usage setup of the virtual card when the first authentication fails and the user satisfies a predetermined condition; the second authentication execution unit executes the second authentication when the physical card is delivered to the user. A card judgment system according to any one of (7) to (10). (12) the card determination system further includes an execution / non-execution information setting unit that sets execution / non-execution information regarding execution / non-execution of the first authentication based on a predetermined condition; the first authentication execution unit executes the first authentication based on the execution / non-execution information. A card judgment system according to any one of (7) to (11). (13) The card judgment system further includes a pre-authentication execution unit that executes pre-authentication, when it is determined that the card is the virtual card, the first authentication execution unit executes the first authentication based on authentication information authenticated in the pre-authentication. A card judgment system according to any one of (7) to (12). (14) When the card is determined to be the virtual card, the first authentication execution unit executes the first authentication in which authentication information about the user held by an administrator of the card is compared with authentication information about the user at the time of receiving the usage setting request. A card judgment system according to any one of (7) to (13). (15) the first authentication execution unit executes the first authentication selected by the user from among the plurality of first authentications when it is determined that the card is the virtual card; A card judgment system according to any one of (7) to (14). (16) the predetermined service is a payment service in which payment is made based on the card, the usage setting request receiving unit receives the usage setting request regarding the usage setting of a payment source or a charge source used by the user in the payment service; A card judgment system according to any one of (1) to (15). (17) the card determination system further includes a benefit granting unit that grants a predetermined benefit to the user when the card is determined to be the virtual card. A card judgment system according to any one of (1) to (16). (18) The card determination system further includes a screen transition unit that automatically transitions the user terminal to a next screen with the card selected when a determination is made by the card determination unit. A card judgment system according to any one of (1) to (17). [Explanation of symbols]

[0155] 1 Card Determination System, N Network, 10 Payment Server, 11, 21, 31 Control Unit, 12, 22, 32 Memory Unit, 13, 23, 33 Communication Unit, 20 Card Server, 30 User Terminal, 34 Operation Unit, 35 Display Unit, 100, 200, 300 Data Storage Unit, 101 Usage Setting Request Acceptance Unit, 102, 202 Card Determination Unit, 103 Pre-Authentication Execution Unit, 104, 203 First Authentication Execution Unit, 105 First Usage Setting Unit, 106, 204 Second Authentication Execution Unit, 107 Second Usage Setting Unit, 108 Cancellation Unit, 109 Storage Unit, 110 Execution / non-execution information setting unit, 111 Benefit Granting Unit, 112 Screen Transition Unit, 201 Delivery Determination Unit, 301 Operation Acceptance Unit, 302 Display Control Unit, B20, B22, B24, B27 Button, C30 code, DB1 payment database, DB2 card database, M21, M25 modal, SC1 pre-authentication screen, SC2 payment source setting screen, SC3 top screen, W23, W26 window.

Claims

[Claim 1] a usage setting request receiving unit that receives, from a user terminal of a user, a usage setting request regarding usage settings of a card used by the user for a predetermined service; a card determination unit that determines whether the card is a virtual card or a physical card when the usage setting request is received; A card judging system including:

Images