JP7516896B2 - Card provision method, server and computer program - Google Patents

Description

The present invention relates to a card provision method, a server, and a computer program.

A system has been disclosed that, when applying for a credit card service, stores the user's seal impression information in a database in advance, extracts the seal impression from the application documents entered by the user via a web screen, and if the extracted seal impression matches the seal impression information, performs application processing based on the application documents, thereby shortening the time required to apply for the service (see Patent Document 1).

JP 2010-191629 A

Such credit cards are delivered to the user by registered mail or other registered letter and must be handed over to the user not only when applying for a new card but also when renewing the card. Furthermore, if the user is not at home when the card is delivered, it cannot be handed over to the user and the card is often delivered to the user at home. This causes the cost of sending the cards to remain high.

The present invention was made in consideration of the above circumstances, and aims to provide a card providing method, server, and computer program that can use a delivery method that does not require hand delivery.

The card provision method according to an embodiment of the present invention records the member information of the invalidated card in a database, and the authentication business server authenticates the user making the authentication request, and when the authentication is complete, outputs authentication information for activating the invalidated card that has been sent to the user.

The server according to an embodiment of the present invention includes an authentication unit that authenticates a user making an authentication request, and an output unit that outputs authentication information for activating a deactivated card that has been sent to the user when the authentication is complete.

A computer program according to an embodiment of the present invention causes a computer to execute a process of authenticating a user making an authentication request, and, when authentication is complete, outputting authentication information for activating a deactivated card that has been sent to the user.

According to the present invention, when sending a card to a user, a method of delivery that does not require hand delivery and does not require registered mail or other correspondence can be used, so there is no risk of missed delivery and delivery costs can be reduced.

1 is a schematic diagram showing an example of the configuration of a card providing system according to an embodiment of the present invention; FIG. 2 is an explanatory diagram showing an example of items recorded in a member DB. FIG. 11 is a flow diagram showing an example of a renewal card sending process. FIG. 11 is a flow diagram illustrating an example of a process for activating a renewal card. FIG. 11 is a flow diagram illustrating an example of a secret authentication process. FIG. 11 is a flow diagram illustrating an example of a security code authentication process. FIG. 11 is a flow diagram illustrating an example of an authentication process based on eKYC.

The present invention will be described below with reference to the drawings showing the embodiment. FIG. 1 is a schematic diagram showing an example of the configuration of the card provision system of this embodiment. The card provision system includes an authentication server 50 as an authentication business server. The card server 100 is a server operated by a card business such as a card company. The authentication server 50 is a server operated by an authentication business or a business entrusted by the authentication business. The authentication business can be, for example, a business that provides the card business with an authentication agency service that performs authentication work on behalf of the user (card member). In this specification, the card may be any card that requires renewal at regular intervals, and includes, for example, a credit card and a debit card. The current card is also called an old card and is a card currently being used by a user. The renewal card is also called a new card and is a card that is generated a certain period before the expiration date of the current card and that replaces the current card.

In the authentication agency service, when it is time to update the current card, the card operator generates updated card data, creates an updated card, and sends it to the user. The updated card may be sent by mail or by a delivery company other than the post office. When the updated card is sent, it is disabled (temporarily unusable). The authentication operator authenticates the user making the authentication request, and if the authentication is completed (successful), it provides the card operator with authentication information for activating the updated card sent to the user. The card operator activates the updated card (makes it usable) based on the authentication information, allowing the user to use the updated card.

The authentication server 50 and the card server 100 are connected via a secret communication path 3. The authentication server 50 is connected to a user terminal 11 and a user terminal 12 via a communication network 2 such as the Internet. The user terminal 11 is, for example, a smartphone or a tablet terminal, and the user terminal 12 is, for example, a PC (personal computer). The authentication server 50 is connected to a user terminal 13 via a telephone line network 1. The user terminal 13 is, for example, a telephone or a mobile phone. The authentication server 50 is also connected to an operator terminal 20 and a member DB 60. The operator terminal 20 is, for example, a PC (personal computer). The card server 100 is also connected to a member DB 80. The user terminals 11, 12, and 13 are collectively referred to as user terminals 10.

The authentication server 50 includes a control unit 51 that controls the entire server, a first authentication unit 52, a second authentication unit 53, a third authentication unit 54, an interface unit 55, a communication unit 56, a memory unit 57, a card information issuing unit 58, and a counting unit 59. The control unit 51 can be composed of a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM (Random Access Memory), etc.

The first authentication unit 52 authenticates the user making the authentication request using secret information known only to the user (e.g., password, ID, passphrase, etc.) in addition to information recorded on the renewal card (e.g., card number) or information that uniquely identifies the user (e.g., user ID). In this specification, the authentication performed by the first authentication unit 52 is referred to as secret authentication. The user can make an authentication request by accessing the web based on a URL or two-dimensional barcode for secret authentication. The first authentication unit 52 can provide an input screen required for web access.

The second authentication unit 53 authenticates a user making an authentication request using the security code of the current card. In this specification, the authentication performed by the second authentication unit 53 is referred to as security code authentication. A user can make an authentication request by accessing the Web based on a URL or two-dimensional barcode for security code authentication. A user can also make an authentication request via an operator or an automated voice response system by calling a designated office. The second authentication unit 53 can provide an input screen and an automated voice response system required for Web access.

The third authentication unit 54 authenticates a user who makes an authentication request to verify the identity of the user online using a photo ID and a face photo. The photo ID includes, for example, a driver's license, a passport, a My Number card, etc., but any ID having the same meaning as an "identification document" may be used. In this specification, the authentication performed by the third authentication unit 54 is referred to as authentication based on eKYC (electronic Know Your Customer). The user can make an authentication request by accessing the Web based on an authentication URL or a two-dimensional barcode based on eKYC. The third authentication unit 54 can provide an input screen required for Web access. When the third authentication unit 54 acquires input information input by the user (for example, a photo ID such as a driver's license or passport, a user's face photo, and user information such as a name and address), it outputs the input information to the operator terminal 20 via the interface unit 55. The operator can authenticate the user by checking the input information displayed on the operator terminal 20. In addition, a facial recognition system may be linked to the third authentication unit 54 to automatically authenticate the user, or authentication by the facial recognition system may be combined with final authentication by an operator.

The control unit 51 includes an encryption processor such as a hardware security module, and causes one of the first authentication unit 52, the second authentication unit 53, and the third authentication unit 54 to perform authentication processing according to the authentication means selected by the user. By providing the first authentication unit 52, the second authentication unit 53, and the third authentication unit 54, it is possible to provide a user making an authentication request with a plurality of selectable authentication means. The user can select the required authentication means from a plurality of authentication means, such as confidential authentication using Web access, security code authentication, or authentication based on eKYC, or security code authentication by telephone. For example, when an invalidated renewal card is shipped to a user, information indicating which authentication means can be selected can be written on the backing paper or instruction manual of the renewal card. For example, a URL or two-dimensional barcode for each authentication, a telephone number for a service center, etc. can be written. Also, instead of a URL or two-dimensional barcode for each authentication, a URL or two-dimensional barcode for accessing a specific Web page can be written, and a plurality of authentication means can be provided selectably within the specific Web page.

The above-mentioned configuration makes it possible to provide authentication means according to the attributes of the user. For example, for users of a generation that uses the Internet relatively frequently, it is possible to provide authentication means that utilizes highly convenient web access. Furthermore, for users who are not familiar with the Internet, such as the senior generation, it is possible to provide authentication means that utilizes telephone calls, making it possible to provide a variety of authentication means to users.

When user authentication is completed (successful), the first authentication unit 52, the second authentication unit 53, and the third authentication unit 54 generate authentication information. The authentication information includes information for activating a deactivated renewal card sent to the user, and may include, for example, a command for activating a deactivated renewal card. When user authentication is not completed (unsuccessful), the first authentication unit 52, the second authentication unit 53, and the third authentication unit 54 may output an authentication failure notification to the user.

When sending an invalidated renewal card to a user, the card information issuance unit 58 can generate the invalidated renewal card, address label, mount for the renewal card, instructions, and other items required for sending. The actual issuance of the renewal card can be handled by an issuing staff member. When the card business performs the issuance of the renewal card itself, the card server 100 may be provided with the card information issuance unit 58. When an authentication business performs the issuance of the renewal card on behalf of the user, the authentication server 50 may be provided with the card information issuance unit 58. In this specification, it is assumed that the authentication business performs the issuance of the renewal card on behalf of the user.

The counting unit 59 can count the number of authentications performed by the first authentication unit 52, the second authentication unit 53, and the third authentication unit 54. The authentication business or card business can issue the renewal card in an invalid state and send the renewal card to the user using a simple delivery method that does not require hand delivery, thereby reducing delivery costs. The user authentication process required to activate the renewal card can be performed by an authentication agency service provided by the authentication business. The authentication business can use the number of authentications counted by the counting unit 59 when billing the card business for the authentication agency service.

The communication unit 56 can open a secret communication path 3 between the card server 100 and the communication unit 56. The communication unit 56 can transmit the generated authentication information to the card server 100 via the secret communication path 3. The communication unit 56 can also transmit the counted number of authentications to the card server 100.

The storage unit 57 is configured with a semiconductor memory or a hard disk, etc., and can store required information such as information acquired by the authentication server 50 and information obtained as a result of processing by the authentication server 50. The storage unit 57 can also store a computer program that defines the processing procedures to be performed by the authentication server 50 (control unit 51).

Member DB 60 records member information of users (card members). The information recorded in member DB 60 can be all or part of the information recorded in member DB 80. Details of member DB 80 will be described later. Member DB 60 and member DB 80 can synchronize data at the required timing. Of the member information recorded in member DB 80 at the time when user authentication is required, only the information necessary for authentication may be recorded in member DB 60, and the information recorded in member DB 60 may be deleted when authentication is completed or when a required period of time (e.g., two months) has elapsed since the time authentication was completed. This makes it possible to prevent leakage or unauthorized acquisition of information necessary for authentication (e.g., card number, etc.).

In the example of FIG. 1, one authentication server 50 is configured to include a first authentication unit 52, a second authentication unit 53, a third authentication unit 54, an interface unit 55, a communication unit 56, a memory unit 57, a card information issuing unit 58, and a counting unit 59, but this is not limited to the above, and each functional unit may be distributed across multiple servers.

The card server 100 comprises a control unit 101 that controls the entire server, a communication unit 102, a valid/invalid setting unit 103, a card data generation unit 104, and a storage unit 105. The control unit 101 can be composed of a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM (Random Access Memory), etc.

The communication unit 102 includes an encryption processor such as a hardware security module, and can establish a secret communication path 3 with the authentication server 50. The communication unit 102 can receive authentication information from the authentication server 50. The communication unit 102 can also transmit updated card information to the authentication server 50.

The card data generation unit 104 generates update card information for an update card that updates the current card corresponding to the update timing, based on the member information recorded in the member DB 80. The update timing can be, for example, a point in time a certain period before the expiration date of the current card. When generating the update card information, the card data generation unit 104 also generates information for temporarily rendering the update card unusable (invalidating it) (for example, data for setting the valid/invalid flag to "invalid"). An update card can be created using the update card information generated by the card data generation unit 104. The update card information generated by the card data generation unit 104 is recorded in the member DB 80.

The valid/invalid setting unit 103 can activate a disabled renewal card recorded in the member DB 80 based on the authentication information received from the authentication server 50. This allows the user to use the renewal card.

The memory unit 105 is composed of a semiconductor memory or a hard disk, etc., and can store required information such as information acquired by the card server 100 and information obtained as a result of processing by the card server 100.

In the example of FIG. 1, one card server 100 is configured to include a communication unit 102, a valid/invalid setting unit 103, a card data generation unit 104, and a memory unit 105, but this is not limited to the above, and each functional unit may be distributed across multiple servers.

Figure 2 is an explanatory diagram showing an example of items recorded in member DB 80. As shown in Figure 2, in member DB 80, items such as the member user's name, date of birth, sex, address, telephone number, bank account information, email address or ID, password, card information of the current card (e.g., card number, cardholder, expiration date, security code), and card information of the renewal card (e.g., card number, cardholder, expiration date, security code, valid/invalid flag indicating whether the renewal card is valid or invalid) are recorded as member information. The card number of the current card and the card number of the renewal card may be the same or different.

Of the member information, name, date of birth, gender, address, telephone number, and bank account information can be extracted from the information filled in by the user on the application form when applying for a new card and recorded in member DB 80. For a newly applied card, card information for the current card is recorded in member DB 80 at the time the card is generated. Renewal card information is recorded in member DB 80 at the time the renewal card information is generated. When the expiration date of the current card has passed, the current card information is overwritten by the renewal card information, and the renewal card information is deleted. An email address or ID and password are set by the user at the required time, and are recorded in member DB 80 at the time they are set.

Next, we will explain the processing of the card provision system.

Figure 3 is a flow diagram showing an example of the process for sending an updated card. At the required update timing, the card server 100 generates updated card information (S11) and invalidates the updated card (S12). To invalidate an updated card, the valid/invalid flag is set to "invalid." The card server 100 records the updated card information in the member DB 80 (S13) and transmits the updated card information to the authentication server 50 (S14).

The authentication server 50 receives the renewal card information and records the received renewal card information in the member DB 60 (S15). The authentication server 50 performs the renewal card issuing process (S16). The issuing staff of the authentication business attaches the invalidated renewal card generated by the issuing process to a mount, places it in an envelope together with the instructions, affixes an address label, and sends the renewal card by regular mail (S17). Note that the attachment of the invalidated renewal card to the mount, the insertion of the mount and instructions into the envelope, and the affixing of an address label may be performed automatically. Furthermore, the method of sending the renewal card is not limited to regular mail, and any simple method that does not require hand delivery may be used, and may be performed by a delivery company other than the post office.

Since a deactivated renewal card is an unusable card, even if a third party other than the user is able to obtain the card, the third party cannot use the card. Therefore, the deactivated renewal card can be sent to the user using a method that does not require hand delivery, rather than a method that requires hand delivery, such as registered mail or other correspondence, and delivery costs can be reduced without the risk of missed delivery.

Figure 4 is a flow diagram showing an example of a process for activating a renewal card. The user terminal 10 makes an authentication request using an authentication means selected by the user from among multiple authentication means (S21). The authentication means can be selected from confidential authentication using web access, security code authentication, or authentication based on eKYC, or security code authentication using a telephone.

The authentication server 50 performs authentication processing for the user (S22). The authentication processing can be performed according to the authentication means selected by the user, and can be any of confidential authentication processing, security code authentication processing, or authentication processing based on eKYC. Details of the authentication processing will be described later.

The authentication server 50 determines whether the authentication was successful (S23), and if the authentication was not successful (NO in S23), notifies the user terminal 10 that the authentication was not successful (S24). If the authentication was successful (YES in S23), the authentication server 50 sends authentication information to the card server 100 (S25). The authentication information (authentication file) can be shared between the authentication server 50 and the card server 100, for example, by HULFT (Host Unix Linkage File Transfer). The authentication server 50 notifies the user terminal 10 that the authentication was successful (S26).

The card server 100 receives the authentication information, activates the updated card based on the received authentication information (S27), and updates the member DB 80 (S28). Here, the valid/invalid flag of the updated card information is updated from "invalid" to "valid." The card server 100 transmits the updated card information to the authentication server 50 (S29).

The authentication server 50 receives the updated card information, updates the member DB 60 (S30), and notifies the user terminal 10 that the updated card has been activated (S31). The authentication server 50 counts the number of authentications (S32). Here, the authentication server 50 increments the number of authentications by 1. Note that the processing of S31 may be performed together with the processing of S26 if the processing of S27 does not require time. This allows the user to use the updated card immediately after receiving the notification that it has been activated.

With the above-described configuration, the user can make an authentication request after receiving the invalidated renewal card, which activates the invalidated renewal card and allows the user to use the renewal card. Furthermore, even if the invalidated renewal card is fraudulently received by a third party other than the user of the card, the third party will only know the information recorded on the renewal card (card number, cardholder, expiration date, security code). Therefore, by performing user authentication using information other than the information recorded on the renewal card, the authentication request from the third party will not be successful, preventing fraudulent use of the renewal card.

That is, the first authentication unit 52, the second authentication unit 53, and the third authentication unit 54 authenticate whether or not the user making the authentication request is a card member of the invalidated renewal card. When an invalidated renewal card is sent, even if the renewal card is obtained by a third party who is not a legitimate user, the authentication request by the third party will not be successful because the third party is not a card member of the renewal card. This makes it possible to prevent fraudulent use of the renewal card.

Next, we will explain the details of the authentication process.

Figure 5 is a flow diagram showing an example of confidential authentication processing. The user terminal 11 or the user terminal 12 makes a confidential authentication request (S41). The authentication server 50 provides the user terminal 11 or the user terminal 12 with a card number input screen (S42). The user terminal 11 or the user terminal 12 transmits the card number of the updated card input by the user to the authentication server 50 (S43).

The authentication server 50 provides a password input screen to the user terminal 11 or 12 (S44). The user terminal 11 or 12 transmits the password entered by the user to the authentication server 50 (S45). The password corresponds to the membership information of the card member of the invalidated renewal card. Here, the information other than the information written on the renewal card may be a password, a user ID, a passphrase, or information assumed in risk-based authentication. Risk-based authentication is a secure login authentication in which, in a system requiring login, information on the connected device such as the user's IP address, network information, OS, and browser environment are checked, and if the information is different from usual, additional information such as a "secret question" is used for authentication. Although it is somewhat cumbersome for the user, the security of the authentication process can be further improved by using at least two pieces of information such as a password, ID, and passphrase.

The authentication server 50 refers to the member DB 60, collates the input card number and password (S46), and judges whether the authentication is successful (S47). The judgment of whether the authentication is successful is based on whether the input password matches the password recorded in the member DB 60, i.e., whether the user making the authentication request is a card member of the invalidated renewal card. A third party who illegally obtains the sent renewal card has no way of knowing information that only the user would know, such as the password, ID, and passphrase, so the authentication request by the third party will not be successful. After S47, the process can continue to S23 in FIG. 4.

Figure 6 is a flow diagram showing an example of security code authentication processing. User terminal 11, user terminal 12, or user terminal 13 makes a security code authentication request (S51). Here, in the case of user terminals 11 and 12, the authentication request is made on a web basis, and in the case of user terminal 13 such as a telephone, the authentication request can be made by key input using an IVR (voice response unit). Note that the authentication request may also be made verbally using a telephone instead of an IVR (voice response unit).

The authentication server 50 requests the input of card information for the current card (S42). The card information for the current card corresponds to the membership information of the card member of the invalidated renewal card. Here, a card information input screen is provided for the user terminals 11 and 12, and the user terminal 13 can be prompted to input card information by IVR (voice response device) or voice. The card information is the card number, expiration date, and security code. Note that an ID may be input instead of the card number. Here, the expiration date and security code of the current card are used as information other than the information written on the renewal card. Furthermore, if the card numbers of the current card and renewal card are different, the card number will also be included in the information other than the information written on the renewal card.

The user terminal 11, the user terminal 12, or the user terminal 13 transmits the card information to the authentication server 50 (S53). Here, in the case of the user terminal 13, the card information is transmitted to the authentication server 50 by key input or voice via an IVR (voice response device).

The authentication server 50 checks the expiration date of the current card (S54). For example, if the entered expiration date does not match the expiration date recorded in the member DB 80, the authentication may be deemed unsuccessful. Since the expiration date is one element in calculating the security code, as described below, checking the entered expiration date can increase the security of the authentication process.

The authentication server 50 uses a predetermined calculation algorithm to calculate a security code from the card number, expiration date, etc. of the current card, and compares the calculated security code with the input security code (S55). If the two security codes do not match, the authentication can be deemed unsuccessful. Since a third party who has fraudulently obtained the renewal card would not know the security code of the current card, the security of the authentication process can be further improved by comparing it with the input security code. Note that instead of calculating the security code, the security code may be recorded in advance in the member DB 60 and the recorded security code may be compared with the input security code, but in order to improve security, a calculation configuration is preferable.

The authentication server 50 judges whether the authentication is successful (S56). The judgment of whether the authentication is successful is based on whether the input expiration date and security code match the expiration date and security code of the current card recorded in the member DB 60, that is, whether the user making the authentication request is a card member of the invalidated renewal card. The security code may not be recorded in the member DB 60, but rather it may be judged by whether a value calculated based on the input information such as the card number and expiration date and a card company-specific encryption key matches the input security code. A third party who illegally obtains the sent renewal card has no way of knowing the expiration date and security code of the current card, so the authentication request by the third party will not be successful. After S56, the process can continue to S23 in FIG. 4.

In the above example, if the entered expiration date and security code are incorrect a predetermined number of times in a row (e.g., five, ten, etc.), the authentication server 50 can stop the authentication request. Also, since a legitimate user is likely to start using the updated card before the expiration date of the current card, the card information of the current card recorded in the member DB 60 can be deleted a predetermined period of time (e.g., two months) after the expiration date. This makes it impossible for a third party who has illegally obtained the updated card to match the security code, even if they later launch a full attack on the security code, reducing the risk of the updated card being used illegally.

In the above example, if the entered card number is incorrect a predetermined number of times in a row (e.g., 5 times, 10 times, etc.), there is a high possibility that fraudulent activity is occurring, so the authentication server 50 can stop the authentication request (user authentication). This can improve security.

In the above example, the authentication server 50 can temporarily store the input card number in the member DB 60 and then delete the stored card number after a predetermined period of time (e.g., two months) has passed. Since it is expected that a user to whom an updated card has been sent will make an authentication request within a relatively short period of time, the card number is stored only for the period required for user authentication and then deleted after the required period has passed, thereby preventing the card number from being leaked or obtained illegally.

Figure 7 is a flow diagram showing an example of authentication processing based on eKYC. The user terminal 11 or the user terminal 12 requests authentication based on eKYC (S61). The authentication server 50 requests the attachment of image data of an identity verification document (S62). Here, an input request screen can be displayed.

The user terminal 11 or the user terminal 12 transmits image data of the identification document to the authentication server 50 (S63). Here, the user can take a photo of the driver's license, for example, so that the front, back, and thickness of the driver's license, which includes the user's name, address, and date of birth, can be confirmed, and transmit the photo.

The authentication server 50 requests the user to input a facial photograph (S64). Here, by requesting the user to turn his/her face and input a facial photograph according to the instructions on the screen, it is possible to ensure that the user is the one taking the photograph.

The user terminal 11 or the user terminal 12 sends a facial photograph to the authentication server 50 (S65). The authentication server 50 requests the input of user information (S66). Here, an input request screen can be displayed. The user information can be, for example, name, address, date of birth, and gender. The user information corresponds to the membership information of the card member of the invalidated renewal card. The user terminal 11 or the user terminal 12 sends the user information to the authentication server 50 (S67).

The authentication server 50 compares the identity document, face photo, and user information (S68). The authentication server 50 may automatically compare the identity document, face photo, and user information, or the operator may visually check the identity document, face photo, and user information, or the operator may visually check the identity document, face photo, and user information without the system.

The authentication server 50 determines whether the authentication is successful (S69). The authentication is determined based on whether the input user information matches the information (name, address, date of birth, etc.) printed on the identification document, and whether the facial photograph printed on the identification document matches the input facial photograph. In other words, the authentication is determined based on whether the user making the authentication request is a card member of the invalidated renewal card. A third party who illegally obtains the sent renewal card cannot pose as the member of the renewal card (at least cannot obtain the facial photograph or identification document), so the authentication request by the third party will not be successful. After S69, the process can continue to S23 in FIG. 4.

As described in Figures 5 to 7, the authentication server 50 can accept input information entered by a user making an authentication request, and authenticate the user using the accepted input information and member information. In the example of Figure 5, the member information is a password, etc. In the example of Figure 6, the member information is the card information of the current card. Also, in the example of Figure 7, the member information is user information. In this way, even if a renewal card is illegally obtained by a third party other than the member of the invalidated renewal card, measures can be taken to ensure that the authentication request from the third party is unsuccessful.

According to this embodiment, when generating the renewal card information, the card operator can temporarily disable the renewal card, making it unusable. This eliminates the need to send the renewal card by registered mail or other registered mail that allows hand delivery, and allows a simpler method of sending the renewal card that does not require hand delivery, such as regular mail, to be used, thereby reducing the cost of sending the renewal card. In addition, the user who is the card member of the renewal card can receive the renewal card even when he or she is absent, which eliminates the need to deal with absentee delivery and improves convenience. In addition, the user can select an authentication method that matches the user's attributes from multiple authentication methods to authenticate that the user is the card member of the renewal card, thereby improving user convenience.

In the above embodiment, we have described a case where a renewal card is invalidated when a renewal card is sent, but in this embodiment, it is also technically possible to invalidate a new card when a new card that has been newly applied for is sent. In the case of a new card, the membership information required for user authentication can be the information provided by the user when applying for the new card.

In the above-described embodiment, the card business server receives authentication information from the authentication business server and activates the updated card using the received authentication information, but this is not limited to the above, and the authentication business server may activate the updated card using the authentication information without going through the card business server. In addition, the card business may operate both the card server and the authentication server, or the authentication business may operate both the card server and the authentication server. The card server and the authentication server may be integrated into one server, or may be distributed across three or more servers.

The card provision method of this embodiment records the member information of the invalidated card in a database, and the authentication business server authenticates the user making the authentication request, and when authentication is complete, outputs authentication information for activating the invalidated card that has been sent to the user.

The server of this embodiment includes an authentication unit that authenticates a user making an authentication request, and an output unit that outputs authentication information for activating a deactivated card that has been sent to the user when authentication is complete.

The computer program of this embodiment causes the computer to execute a process of authenticating a user making an authentication request, and when authentication is complete, outputting authentication information for activating a deactivated card that has been sent to the user.

The database records the membership information of invalidated cards (also called renewal cards). The card may be any card that requires renewal at regular intervals, and includes, for example, credit cards and debit cards. The database is, for example, a membership DB that records the membership information of cards. The membership DB can include items such as the member user's name, date of birth, gender, address, telephone number, bank account information, email address or ID, password, card information of the current card (for example, card number, expiration date, security code), and card information of the renewal card (for example, card number, expiration date, security code, flag that sets whether the renewal card is valid or invalid). A invalidated renewal card is an unusable card until it is activated.

The authentication provider server authenticates the user making the authentication request, and when authentication is complete (successful), it outputs authentication information to the card provider server for activating the deactivated renewal card sent to the user. Because a deactivated renewal card is an unusable card, even if a third party other than the user is able to obtain the card, the third party cannot use the card. The authentication information can include, for example, a command to activate the deactivated renewal card sent to the user whose authentication has been completed.

With the above-mentioned configuration, the user can make an authentication request after receiving the invalidated renewal card, which activates the invalidated renewal card and allows the user to use the renewal card. Even if the invalidated renewal card is mistakenly received by a third party other than the member of the card, measures can be taken to prevent the third party from making an authentication request successful, thereby preventing unauthorized use of the renewal card. Therefore, the invalidated renewal card can be sent to the user using a method that does not require hand delivery, rather than a method that requires hand delivery, such as registered mail or other correspondence, which prevents delivery to the user in an unattended manner and reduces delivery costs.

In the card provision method of this embodiment, the authentication business server outputs the authentication information to the card business server, thereby validating the card recorded in the database.

The authentication business server outputs the authentication information to the card business server, thereby activating the card recorded in the database. In other words, the card business server acquires the authentication information, and activates the invalidated renewal card recorded in the database based on the acquired authentication information. This allows the user to use the renewal card.

In the card provision method of this embodiment, the authentication business server authenticates whether the user making the authentication request is a card member of the invalidated card.

The authentication provider server authenticates whether or not the user making the authentication request is a cardholder of the invalidated renewal card. The authentication of a user can be determined based on whether or not the user is a cardholder of the invalidated renewal card. If an invalidated renewal card is sent and the renewal card is obtained by a third party who is not a legitimate user, the authentication request by the third party will not be successful because the third party is not a cardholder of the renewal card. This makes it possible to prevent fraudulent use of the renewal card.

In the card provision method of this embodiment, the authentication business server accepts input information entered by the user making the authentication request, and authenticates the user using the accepted input information and the member information.

The authentication provider server accepts input information entered by the user making an authentication request, and authenticates the user using the accepted input information and member information. For example, the input information entered by the user can be matched against the member information to authenticate the user. For example, the card number of the renewal card and the user's password can be associated and recorded as member information in a member DB, and the card number and password of the renewal card entered by the user can be matched against the member information in the member DB to authenticate the user.

In the card provision method of this embodiment, the authentication business server provides the user making the authentication request with a selection of multiple authentication methods, and accepts input information from the user based on the authentication method selected by the user.

The authentication provider server provides a user making an authentication request with a selection of multiple authentication methods. When an invalidated renewal card is shipped, information indicating which authentication methods are selectable can be written on the card's backing or instruction manual. Selectable authentication methods include, for example, confidential authentication using confidential information known only to the user (e.g., password, ID, passphrase, etc.) in addition to the information written on the renewal card, security code authentication using the card's security code, and eKYC (electronic Know Your Customer) authentication using a photo ID and a photo, etc.

The authentication provider server accepts the user's input information based on the authentication method selected by the user. For example, if the user selects confidential authentication, the user can input the input information by accessing the Web based on a specified URL or two-dimensional barcode. If the user selects security code authentication, the user can input the input information by connecting to an automated voice response system via the Web or by calling a specified office. If the user selects authentication based on eKYC, the user can input the input information by accessing the Web.

The above-mentioned configuration makes it possible to provide authentication means according to the attributes of the user. For example, for users of a generation that uses the Internet relatively frequently, it is possible to provide authentication means that utilizes highly convenient web access. Furthermore, for users who are not familiar with the Internet, such as the senior generation, it is possible to provide authentication means that utilizes telephone calls, making it possible to provide a variety of authentication means to users.

In the card provision method of this embodiment, the authentication business server retains the card number received as the input information and deletes the card number that has been retained for a specified period of time.

The card number accepted as input information is temporarily stored and then deleted after a specified period of time (e.g., two months) has passed. This allows the card number to be stored only for the period required for user authentication, and by deleting the card number after the required period has passed, it is possible to prevent the card number from being leaked or obtained illegally.

In the card provision method of this embodiment, the authentication business server stops authenticating the user if the user making the authentication request inputs the wrong card number a predetermined number of times.

If the card number is entered incorrectly a certain number of times, there is a high possibility that fraudulent activity is occurring, so security can be improved by stopping user authentication.

In the card provision method of this embodiment, the authentication business server counts the number of authentications of the user who made the authentication request and outputs the counted number of authentications.

The authentication provider server counts the number of authentications for users who have made authentication requests, and outputs the counted number of authentications. The card operator can issue the updated card in an invalid state and send it to the user using a simple delivery method that does not require hand delivery, thereby reducing delivery costs. The user authentication process required to activate the updated card can be performed by an authentication agency service provided by the authentication provider. The authentication provider can use the number of authentications counted by the authentication provider server when billing the card operator for the authentication agency service.

REFERENCE SIGNS LIST 1 telephone line network 2 communication network 3 confidential communication path 11, 12, 13 user terminal 20 operator terminal 50 authentication server 51 control unit 52 first authentication unit 53 second authentication unit 54 third authentication unit 55 interface unit 56 communication unit 57 storage unit 58 card information issuing unit 59 counting unit 60, 80 member DB
REFERENCE SIGNS LIST 100 Card server 101 Control unit 102 Communication unit 103 Valid/invalid setting unit 104 Card data generation unit 105 Storage unit

Claims (13)

Record the member information of the deactivated card in a database,
The authentication provider server
Authenticate the user making the authentication request;
If the authentication is completed, outputting authentication information for activating the invalidated card that was sent to the user;
receiving input information input by a user making the authentication request;
authenticating the user using the received input information and the member information;
The card number received as the input information is stored,
Delete card numbers that have been held for a specified period of time ;
Card delivery method. Record the member information of the deactivated card in a database,
The authentication provider server
Authenticate the user making the authentication request;
If the authentication is completed, outputting authentication information for activating the invalidated card that was sent to the user;
Counting the number of authentications of the user who has made the authentication request;
Output the counted number of authentications.
Card delivery method. The authentication business server
outputting the authentication information to a card company server to validate the card recorded in the database;
The card providing method according to claim 1 or 2 . The authentication business server
authenticating whether the user making the authentication request is a cardholder of the invalidated card;
The card providing method according to any one of claims 1 to 3 . The authentication business server
receiving input information input by a user making the authentication request;
authenticating the user using the received input information and the member information;
The card providing method according to claim 2 . The authentication business server
providing a plurality of authentication means selectable from the user making the authentication request;
accepting input information from the user based on an authentication means selected by the user;
The card providing method according to claim 5 . The authentication business server
The card number received as the input information is stored,
Delete card numbers that have been held for a specified period of time;
The card providing method according to claim 5 or 6 . The authentication business server
If the user making the authentication request inputs an incorrect card number a predetermined number of times, authentication of the user is stopped.
The card providing method according to any one of claims 5 to 7 . The authentication business server
Counting the number of authentications of the user who has made the authentication request;
Output the counted number of authentications.
The card providing method according to claim 1 . a recording unit for recording member information of the invalidated card in a database;
an authentication unit that authenticates a user making an authentication request;
an output unit that outputs authentication information for activating the invalidated card sent to the user when the authentication is completed ;
a reception unit that receives input information input by a user making the authentication request;
an authentication unit that authenticates the user using the received input information and the member information;
a storage unit that stores the card number received as the input information;
a deletion unit for deleting card numbers that have been held for a predetermined period of time;
A server comprising: a recording unit for recording member information of the invalidated card in a database;
an authentication unit that authenticates a user making an authentication request;
a first output unit that outputs authentication information for activating a disabled card that has been sent to the user when the authentication is completed;
a counting unit that counts the number of authentications of the user who has made the authentication request;
a second output unit that outputs the counted number of authentications;
A server comprising: On the computer,
Record the member information of the deactivated card in a database,
Authenticate the user making the authentication request;
If the authentication is completed, outputting authentication information for activating the invalidated card sent to the user;
receiving input information input by a user making the authentication request;
authenticating the user using the received input information and the member information;
The card number received as the input information is stored,
Delete card numbers that have been held for a specified period of time ;
A computer program that executes a process. On the computer,
Record the member information of the deactivated card in a database,
Authenticate the user making the authentication request;
If the authentication is completed, outputting authentication information for activating the invalidated card sent to the user;
Counting the number of authentications of the user who has made the authentication request;
Output the counted number of authentications.
A computer program that executes a process.

Images