Server and method for user authentication through tagging of authentication card

Abstract

Provided are a server and method for user authentication through tagging of an authentication card. The server according to the present disclosure may comprise: a communication module; and a processor which, when a selection for any one of at least one card issued to a user is inputted from a terminal of the user through the communication module, registers the selected card as an authentication card of the user and performs virtual code-based user authentication when approval of a financial transaction using the authentication card is requested from the user terminal through the communication module.

Description

User authentication server and method through tagging of authentication cards

[0001] The present disclosure relates to a user authentication server and method through tagging of an authentication card.

[0002] Code-based data is used in many areas. Examples of code-based data include card numbers and account numbers used for payment, as well as IPIN numbers and resident registration numbers used for user identification.

[0003] However, there are frequent cases of data leaks during the use of this code. Card numbers are often printed on the card's surface, making them visible to others. Furthermore, card numbers are also leaked when magnetic stripe payments are made, transmitting them directly to the POS device.

[0004] There have been many attempts to use virtual code to prevent the actual code from being leaked, but data to identify the user was needed to search for the actual code corresponding to the virtual code.

[0005] However, in the case of OTP (One Time Password), a separate OTP generation device is required, which is inconvenient, and in particular, in the case of user terminals, there is a security vulnerability due to the leakage of seed data used for OTP generation.

[0006] Therefore, a method is needed to increase security by generating OTP codes, such as generating virtual security codes required for user authentication based on card data of cards held by many users, without requiring a separate OTP generation device, and at the same time preventing seed data from being leaked.

[0007] The purpose of the embodiments disclosed in this disclosure is to provide a user authentication server and method through tagging of an authentication card.

[0008] The problems to be solved by the present disclosure are not limited to the problems mentioned above, and other problems not mentioned will be clearly understood by those skilled in the art from the description below.

[0009] In order to achieve the above-described technical problem, a user authentication server through tagging of an authentication card according to one aspect of the present disclosure includes a communication module and a processor for registering the selected card as an authentication card for the user when a selection of at least one card issued to the user is input from the user's terminal through the communication module, and for performing user authentication based on a virtual code when approval of a financial transaction using the authentication card is requested from the user's terminal through the communication module, wherein the virtual code can be generated through a first applet for generating a virtual code loaded in the authentication card when the authentication card is manufactured or issued.

[0010] In addition, the first applet may include at least one of a unique value for generating the virtual code and a card number of the authentication card, and the card number may be injected into the first applet and the second applet for payment loaded in the authentication card, respectively.

[0011] Additionally, the processor can generate a unique value for each card issuer or financial institution associated with the card issuer.

[0012] In addition, the processor may receive the virtual code generated through tagging of the authentication card from the user terminal, and when the user authentication is completed through verification of the virtual code, the processor may approve the financial transaction.

[0013] Additionally, the user authentication may be performed through a service application, separately from authentication through login to the application for the financial transaction.

[0014] Additionally, when a change of the authentication card is requested from the user terminal, the processor can perform registration of a new authentication card through tagging of the new authentication card.

[0015] Additionally, the first applet loaded on the new authentication card may include a new unique value that is different from the unique value included in the first applet loaded on the previous authentication card.

[0016] In addition, the processor can calculate a first fee incurred per issuance of a physical card registered as an authentication card, and a second fee incurred per user authentication process using a physical card registered as an authentication card.

[0017] In addition, a method for user authentication through tagging of an authentication card according to another aspect of the present disclosure for achieving the above-described technical problem includes the steps of receiving a selection of one of at least one card issued to the user from the user's terminal, registering the selected card as the user's authentication card, receiving a request for approval of a financial transaction using the authentication card from the user terminal, and performing user authentication based on a virtual code generated when the authentication card is tagged to the user terminal, wherein the virtual code may be generated through a first applet for generating a virtual code loaded in the authentication card when the authentication card is manufactured or issued.

[0018] In addition, according to another aspect of the present disclosure for achieving the above-described technical problem, an authentication card for performing user authentication through tagging includes a first applet including at least one of a unique value and a card number for generating a virtual code, and a second applet including the card number for payment during a financial transaction, wherein the first applet is mounted in the authentication card when the authentication card is manufactured or issued, and the authentication card is registered in a service application by selecting any one of at least one card issued to the user as the authentication card, and the virtual code can be generated by the first applet and transmitted to a user authentication server when the authentication card is tagged to the user's terminal during the financial transaction.

[0019] In addition, a computer program stored in a computer-readable recording medium for executing a method for implementing the present disclosure may be further provided.

[0020] In addition, a computer-readable recording medium recording a computer program for executing a method for implementing the present disclosure may be further provided.

[0021] According to the aforementioned problem solving means of the present disclosure, when a user conducts a financial transaction using a card selected for authentication from among the cards held by the user, the user can prevent a financial transaction against the user's will by performing the final approval of the financial transaction through service app tagging.

[0022] By utilizing a virtual code that changes with each use and cannot be reused for user authentication, transaction authentication can be preemptively blocked in non-face-to-face situations where the user is not aware of the code.

[0023] The effects of the present disclosure are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

[0024] FIG. 1 is a schematic diagram of a system for user authentication through tagging of an authentication card according to one embodiment of the present disclosure.

[0025] FIG. 2 is a drawing for explaining the effect of performing user authentication through tagging of an authentication card during a financial transaction of the present disclosure.

[0026] FIG. 3 is a block diagram of a user authentication server according to one embodiment of the present disclosure.

[0027] FIG. 4 is a block diagram of an authentication card according to one embodiment of the present disclosure.

[0028] FIG. 5 is a flowchart of a user authentication method through tagging of an authentication card according to one embodiment of the present disclosure.

[0029] FIGS. 6 to 8 are drawings for explaining a process for manufacturing and issuing a physical card according to one embodiment of the present disclosure.

[0030] Throughout this disclosure, the same reference numerals denote the same components. This disclosure does not describe all elements of the embodiments, and any content that is common in the technical field to which this disclosure pertains or that overlaps between embodiments is omitted. The terms "part, module, element, block" used in the specification may be implemented in software or hardware, and depending on the embodiments, multiple "parts, modules, elements, blocks" may be implemented as a single component, or a single "part, module, element, block" may include multiple components.

[0031] Throughout the specification, when a part is said to be "connected" to another part, this includes not only direct connection but also indirect connection, and indirect connection includes connection via a wireless communication network.

[0032] Additionally, when a part is said to "include" a component, this does not mean that it excludes other components, but rather that it may include other components, unless otherwise specifically stated.

[0033] Throughout the specification, when we say that an element is "on" another element, this includes not only cases where the element is in contact with the other element, but also cases where another element exists between the two elements.

[0034] The terms first, second, etc. are used to distinguish one component from another, and the components are not limited by the aforementioned terms.

[0035] Singular expressions include plural expressions unless the context clearly indicates otherwise.

[0036] The identification codes for each step are used for convenience of explanation and do not describe the order of each step. Each step may be performed in a different order than specified unless the context clearly indicates a specific order.

[0037] The operating principle and embodiments of the present disclosure are described below with reference to the attached drawings.

[0038] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0039] Before proceeding, the meanings of terms used in this specification will be briefly explained. However, it should be noted that the explanation of terms is intended to aid understanding of this specification, and therefore, unless explicitly stated to limit the disclosure, they are not intended to limit the technical concepts of this disclosure.

[0040] As used herein, the term "device" encompasses a variety of devices capable of performing computational processing and providing results to a user. For example, a device may include a computer, a server, or a mobile terminal, or may be any one of these.

[0041] Here, the computer may include, for example, a notebook, desktop, laptop, tablet PC, slate PC, etc. equipped with a web browser.

[0042] The above server device is a server that processes information by communicating with an external device, and may include an application server, a computing server, a database server, a file server, a game server, a mail server, a proxy server, and a web server.

[0043] The above portable terminal may include, for example, a wireless communication device that ensures portability and mobility, and may include all kinds of handheld-based wireless communication devices such as a PCS (Personal Communication System), GSM (Global System for Mobile communications), PDC (Personal Digital Cellular), PHS (Personal Handyphone System), PDA (Personal Digital Assistant), IMT (International Mobile Telecommunication)-2000, CDMA (Code Division Multiple Access)-2000, W-CDMA (W-Code Division Multiple Access), WiBro (Wireless Broadband Internet) terminal, a smart phone, and a wearable device such as a watch, a ring, a bracelet, an anklet, a necklace, glasses, contact lenses, or a head-mounted device (HMD).

[0044] In this specification, “character” is a component that constitutes a code, and includes all or part of uppercase alphabets, lowercase alphabets, numbers, and special characters.

[0045] In this specification, “code” means a string of characters.

[0046] In this specification, “virtual code” may mean an OTAC (One Time Authentication Code) temporarily generated for user authentication.

[0047] In this specification, "virtual code generation function" refers to a function that generates virtual code. Examples include, but are not limited to, OTP (One Time Password).

[0048] In this specification, “detail code generation function” means a function that generates each detail code that constitutes a virtual code.

[0049] In this specification, “detail code combination function” means a function that generates a virtual code by combining or combining multiple detail codes.

[0050] In this specification, a "unit count" is defined as a unit set at a specific time interval and changed as the time interval elapses. For example, 1 count may be set and used at a specific time interval (e.g., 1.5 seconds).

[0051] In this specification, "storage location" refers to the point (count) on the track corresponding to the time of user registration. Here, user registration may refer to a case where a physical card is issued to a specific user (at the time the physical card owner is identified), a case where a user registers the issued physical card for use, or a case where a user registers the issued physical card as an authentication card.

[0052] In this specification, "financial transaction" is understood to encompass situations involving the movement of money online, such as e-commerce (e.g., online shopping), mobile payments, transfers, and virtual asset transactions. However, it is not limited to these situations and can also encompass situations involving the movement of money offline. Furthermore, while this specification discusses user authentication for financial transactions, user authentication for login or access is also applicable.

[0053] Hereinafter, with reference to FIGS. 1 and 2, a system for providing a user authentication service through tagging of an authentication card and the effect of the user authentication service will be described.

[0054] FIG. 1 is a schematic diagram of a system for user authentication through tagging of an authentication card according to one embodiment of the present disclosure.

[0055] FIG. 2 is a drawing for explaining the effect of performing user authentication through tagging of an authentication card during a financial transaction of the present disclosure.

[0056] Referring to FIG. 1, a system (hereinafter, “system”) (1) for user authentication through tagging of an authentication card may include a user authentication server (10), a user terminal (20), an authentication card (30), a card issuer server (40), and a card manufacturer server (50). However, in some embodiments, the system may include fewer or more components than the components illustrated in FIG. 1.

[0057] The user authentication server (10) may be a server of a company or organization that provides user authentication service through tagging of an authentication card.

[0058] The user authentication server (10) can enable the user to additionally perform user authentication by tagging a physical card registered as an authentication card in a user authentication service application (hereinafter, “service application”) to his / her terminal when conducting a financial transaction.

[0059] A user terminal (20) may refer to a terminal device of a user who utilizes a user authentication service. A user may install a service application on the user terminal (20) and use the service in the form of an online web or app.

[0060] The user terminal (20) may be applied with an information processing means such as a computer, and may include a processor such as a control unit, a photographing means such as a camera, an input / output means including a touch screen, and may mean any device with a communication function. In other words, any device such as a smartphone, tablet, PDA, laptop, or desktop may be applied.

[0061] The authentication card (30) is one of the cards held by the user. When registered as an authentication card (30) in the service application, the card can be tagged during financial transactions to perform user authentication. Here, the user's card may be a payment card, but is not limited thereto and may also be an identification card (such as an ID card or access card).

[0062] In other words, users can select a card they wish to use as an authentication card for financial transactions from among their existing cards and register it with the service application. When the service application is activated during a financial transaction, the user can be redirected from the web or app page providing the financial transaction service to the web or app page providing the user authentication service. On the redirected page, the user can perform user authentication by tagging the physical card registered as the authentication card to the terminal.

[0063] Once user authentication is complete, the user is redirected to the website or app providing the financial transaction service, where payment authentication, such as password entry, can be performed to complete the payment. However, depending on the embodiment, if payment authentication has already been completed prior to card tagging, the payment can be completed immediately upon completion of card tagging and redirection to the website or app providing the financial transaction service.

[0064] At this time, when conducting a financial transaction on a web or app page that provides financial transaction services, the card used for payment (transfer) may be the same card as the authentication card or a different card.

[0065] The card issuer server (40) may refer to a server of a company or institution that provides a physical card to a user in response to the user's card issuance request.

[0066] The card manufacturer server (50) may refer to a server of a company or institution that manufactures physical cards and supplies them to card issuers according to card manufacturing requests from card issuers.

[0067] Referring to FIG. 2, when a user conducts a financial transaction using a user terminal (20), if user authentication through card tagging is requested through app linkage, the user can perform user authentication by tagging a physical card registered as an authentication card to the user terminal (20). Once user authentication through card tagging is completed, payment (transfer) can be completed.

[0068] On the other hand, if a hacker steals a user's personal information and attempts to make a payment using a stolen device (user terminal), or if a hacker steals a user's personal information and logs in from another device to make a payment, user authentication through card tagging may be requested via app integration. However, since the hacker cannot possess the physical card registered for authentication, card tagging is impossible, resulting in a failed payment attempt.

[0069] By performing additional user authentication through tagging of the authentication card in this way, users can prevent payment attempts by hackers even if their personal information is leaked through hacking or phishing.

[0070] Below, a user authentication server through tagging of an authentication card is described with reference to FIG. 3.

[0071] FIG. 3 is a block diagram of a user authentication server according to one embodiment of the present disclosure.

[0072] Referring to FIG. 3, a user authentication server (hereinafter, user authentication server) (10) through tagging of an authentication card may include a communication module (11), a memory (12), and a processor (13).

[0073] However, in some embodiments, the user authentication server (10) and processor (13) may include fewer or more components than the components illustrated in FIG. 3.

[0074] The communication module (11) may include one or more modules that enable wireless or wired communication between the user authentication server (10) and the user terminal (20), between the user authentication server (10) and the card issuer server (40), between the user authentication server (10) and the card manufacturer server (50), between the user authentication server (10) and a communication network, and between the user authentication server (10) and an external device (server) (not shown). For example, it may include at least one of a wired communication module, a wireless communication module, a short-range communication module, and a location information module.

[0075] The communication network can use various types of communication networks, for example, wireless communication methods such as WLAN (Wireless LAN), Wi-Fi, Wibro, WiMAX, and HSDPA (High Speed ​​Downlink Packet Access), or wired communication methods such as Ethernet, xDSL (ADSL, VDSL), HFC (Hybrid Fiber Coax), FTTC (Fiber to The Curb), and FTTH (Fiber to The Home) can be used.

[0076] Meanwhile, the communication network is not limited to the communication methods presented above, and may include all other widely known or future-developed communication methods in addition to the above-described communication methods.

[0077] The wired communication module may include various wired communication modules such as a Local Area Network (LAN) module, a Wide Area Network (WAN) module, or a Value Added Network (VAN) module, as well as various cable communication modules such as a Universal Serial Bus (USB), a High Definition Multimedia Interface (HDMI), a Digital Visual Interface (DVI), RS-232 (recommended standard 232), power line communication, or plain old telephone service (POTS).

[0078] The wireless communication module may include a wireless communication module that supports various wireless communication methods such as GSM (global System for Mobile Communication), CDMA (Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), UMTS (universal mobile telecommunications system), TDMA (Time Division Multiple Access), LTE (Long Term Evolution), 4G, 5G, and 6G, in addition to a WiFi module and a Wireless Broadband module.

[0079] The short-range communication module is for short-range communication, and can support short-range communication using at least one of Bluetooth™, RFID (Radio Frequency Identification), Infrared Data Association (IrDA), UWB (Ultra Wideband), ZigBee, NFC (Near Field Communication), Wi-Fi (Wireless-Fidelity), Wi-Fi Direct, and Wireless USB (Wireless Universal Serial Bus) technologies.

[0080] The memory (12) may store at least one process for providing a user authentication service through tagging of an authentication card.

[0081] The memory (12) can store data supporting various functions of the user authentication server (10), a program for the operation of the processor (13), can store input / output data (e.g., music files, still images, moving images, etc.), and can store a plurality of application programs (or applications) running on the user authentication server (10), data for the operation of the user authentication server (10), and commands. At least some of these application programs can be downloaded from an external server via wireless communication.

[0082] The memory (12) may include at least one type of storage medium among a flash memory type, a hard disk type, an SSD (Solid State Disk type), an SDD (Silicon Disk Drive type), a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, and an optical disk. In addition, the memory (12) is separate from the user authentication server (10), but may be a database connected by wire or wirelessly.

[0083] The processor (13) can perform the aforementioned operations using a memory that stores data regarding an algorithm for controlling the operation of components within the user authentication server (10) or a program that reproduces the algorithm, and the data stored in the memory. In this case, the memory (12) and the processor (13) may each be implemented as separate chips. Alternatively, the memory (12) and the processor (13) may be implemented as a single chip.

[0084] In addition, the processor (13) can control any one or a combination of the components discussed above in order to implement various embodiments according to the present disclosure described in FIGS. 5 to 8 below on the user authentication server (10).

[0085] Below, the authentication card will be described with reference to Fig. 4.

[0086] FIG. 4 is a block diagram of an authentication card according to one embodiment of the present disclosure.

[0087] Referring to FIG. 4, the authentication card (30) may include a first applet (31) and a second applet (32).

[0088] However, in some embodiments, the authentication card (30) may include fewer or more components than those illustrated in FIG. 4.

[0089] The first applet (31) may be installed in the card to generate a virtual code for user authentication. The first applet (31) may include at least one of a unique value required for virtual code generation and a card number of the authentication card, but is not limited thereto, and may also include a secret value. Here, the unique value may be a unique value of the user or the card. The secret value may be a value required for OTP generation. When user authentication is performed using the authentication card (30), a virtual code is generated using the data contained in the first applet (31) (at least one of the unique value, the secret value, and the card number), and the generated virtual code may be transmitted to the user authentication server (10) and verified.

[0090] The first applet (31) can be loaded into the card when manufacturing or issuing the physical card corresponding to the authentication card.

[0091] A second applet (32) may be embedded within a card for payment purposes. The second applet (32) may contain a card number. When making a payment using the authentication card (30), the card number contained in the second applet (32) is transmitted to the payment server, allowing the payment to proceed.

[0092] When both the first applet (31) and the second applet (32) contain card numbers, the card numbers can be injected into the first applet (31) and the second applet (32), respectively.

[0093] The second applet (32) can be loaded into the card when issuing a physical card corresponding to the authentication card.

[0094] Hereinafter, a user authentication method through tagging of an authentication card will be specifically described with reference to FIGS. 5 to 8.

[0095] FIG. 5 is a flowchart of a user authentication method through tagging of an authentication card according to one embodiment of the present disclosure. The method of FIG. 5 may be performed by the user authentication server (10) (specifically, the processor (13)) described above.

[0096] FIGS. 6 to 8 are drawings for explaining a process for manufacturing and issuing a physical card according to one embodiment of the present disclosure.

[0097] Referring to FIG. 5, the processor (13) of the user authentication server (10) can receive a selection of one of at least one card issued to the user from the user's terminal (20) through the communication module (11) (S510).

[0098] The processor (13) of the user authentication server (10) can register the selected card as a user authentication card (S520).

[0099] A user can install a service application on a user terminal (20), select one of the one or more physical cards he or she has to use as an authentication card, tag it to the service application, and complete the registration of the card as an authentication card in the service application.

[0100] The user authentication server (10) can share information related to the card with the server (40) of the card issuer that issued the physical card registered as the authentication card.

[0101] The processor (13) of the user authentication server (10) can receive a request for approval of a financial transaction using an authentication card from a user terminal (20) through a communication module (11) (S530).

[0102] The processor (13) of the user authentication server (10) can perform user authentication based on a virtual code generated when an authentication card (30) is tagged to a user terminal (20) (S540).

[0103] When a user tags a physical card registered as an authentication card on a user terminal (20) during a financial transaction, the user terminal (20) can request approval by transmitting a virtual code to the user authentication server (10).

[0104] Here, the virtual code can be generated by the first applet (31) of the authentication card (30) when the authentication card (30) is tagged to the user terminal (20) and transmitted to the user authentication server (10) through the user terminal (20).

[0105] Depending on the embodiment, the virtual code may be generated based on a user-specific value for identifying the user or a card-specific value for identifying the card.

[0106] In some embodiments, the virtual code may be generated based on at least one of a user-specific value for identifying a user, a card-specific value for identifying a card, a secret value, and a card number.

[0107] The unique value can be generated by the user authentication server (10) for each card issuer or financial institution linked to the card issuer and transmitted to the entity that injects the unique value into the card. If the entity that injects the unique value is the card issuer server (40), the user authentication server (10) can provide the unique value assigned to the corresponding card issuer to the card issuer server (40). If the entity that injects the unique value is the card manufacturer server (50), the user authentication server (10) can provide the unique value assigned to the corresponding card issuer to the card issuer server (40), and the card issuer server (40) can then transmit the unique value to the card manufacturer server (50).

[0108] The processor (13) of the user authentication server (10) can perform user authentication through verification of virtual code.

[0109] The processor (13) of the user authentication server (10) performs a comparison between the unique value included in the virtual code and the unique value already stored in the user authentication server (10), and can determine whether the virtual code has been normally generated at the current point in time based on whether the two values ​​match.

[0110] The processor (13) of the user authentication server (10) can complete user authentication and approve the financial transaction if it is confirmed through verification of the virtual code that the two values ​​match.

[0111] User authentication performed by the user authentication server (10) may be performed through a service application, separate from authentication through logging into an application for financial transactions. That is, in addition to logging in or entering a payment password into an application that provides financial transaction services for financial transactions, the user must additionally perform user authentication through card tagging in the linked service application.

[0112] When a request for a change of the authentication card is made from a user terminal (20), the processor (13) of the user authentication server (10) can cancel the currently registered authentication card and perform registration of the new authentication card through tagging of the new authentication card.

[0113] At this time, the first applet loaded on the new authentication card may include new data (at least one of a unique value, a secret value, and a card number) that is different from the data (at least one of a unique value, a secret value, and a card number) included in the first applet loaded on the previously canceled authentication card.

[0114] Depending on the embodiment, when changing an authentication card, additional authentication procedures, such as entering an authentication number, may be performed in addition to card tagging. This can prevent abnormal card change attempts.

[0115] Hereinafter, embodiments of manufacturing and issuing a physical card (authentication card) will be described with reference to FIGS. 6 to 8.

[0116] FIG. 6 is a drawing for explaining a case where a card manufacturer server (50) loads a first applet (32) when manufacturing a physical card, and a card issuer server (40) injects a unique value into the first applet (32).

[0117] Referring to FIG. 6, the card manufacturer server (50) can manufacture a card by loading a first applet (31) for generating a virtual code on a physical card (S61).

[0118] The card issuer server (40) may inject a unique value used for virtual code generation into the first applet (31) installed on the physical card (S62). According to an embodiment, the card issuer server (40) may inject at least one of the unique value, card number, and secret value used for virtual code generation into the first applet (31) installed on the physical card.

[0119] The card issuer server (40) can generate and store physical card issuance information (S63). Here, the issuance information may include information about the user receiving the physical card and mapping information that maps the card number and unique value assigned to the physical card. However, without limitation, the issuance information may include all information generated during card issuance.

[0120] The card issuer server (40) can issue a physical card to a user and share the physical card issuance information with the user authentication server (10).

[0121] The user authentication server (10) can store physical card issuance information (S64).

[0122] FIG. 7 is a drawing for explaining a case where the card manufacturer server (50) only manufactures cards, and the card issuer server (40) injects the first applet (32) into the physical card and injects a unique value into the first applet (32).

[0123] Referring to FIG. 7, when a card manufacturer server (50) manufactures a physical card (S71), the card issuer server (40) injects a first applet (32) for generating a virtual code into the physical card (S72), and may inject a unique value used for generating the virtual code into the first applet (32) (S73). According to an embodiment, the card issuer server (40) may inject at least one of a unique value, a card number, and a secret value used for generating the virtual code into the first applet (31) of the physical card.

[0124] The card issuer server (40) can generate and store physical card issuance information (S74). Here, the issuance information may include information about the user receiving the physical card and mapping information that maps the card number and unique value assigned to the physical card. However, this is not limited to this information, and may include all information generated during card issuance.

[0125] The card issuer server (40) can issue a physical card to a user and share the physical card issuance information with the user authentication server (10).

[0126] The user authentication server (10) can store physical card issuance information (S75).

[0127] Figure 8 is a drawing for explaining a case where a card manufacturer server (50) loads a first applet and injects a unique value into the first applet when manufacturing a physical card.

[0128] The card manufacturer server (50) can manufacture a card by loading a first applet (31) for generating a virtual code into a physical card and injecting a unique value used for generating the virtual code into the first applet (31) (S81). According to an embodiment, the card issuer server (40) can inject at least one of a card number and a secret value further necessary for generating the virtual code in addition to the unique value into the first applet (31) loaded into the physical card. According to an embodiment, the card manufacturer server (50) can manufacture a card by injecting at least one of a unique value and a secret value used for generating the virtual code into the first applet (31), and the card issuer server (40) can inject a card number further necessary for generating the virtual code into the first applet (31) loaded into the physical card.

[0129] The card issuer server (40) can read the unique value injected into the physical card and map it to the card number assigned to the physical card to generate mapping information (S82).

[0130] The card issuer server (40) can generate and store physical card issuance information (S83). Here, the issuance information may include information on the user receiving the physical card and the mapping information, but is not limited thereto and may include all information generated during card issuance.

[0131] The card issuer server (40) can issue a physical card to a user and share the physical card issuance information with the user authentication server (10).

[0132] The user authentication server (10) can store physical card issuance information (S84).

[0133] With reference to FIGS. 6 to 8 above, only the mounting of the first applet (31) on a physical card is described, and the mounting of the second applet (32) is not described. However, as described above, the second applet (32) is mounted on the card by the card issuer server (40) when the physical card is issued, and the card number input into the second applet (32) is also performed by the card issuer server (40).

[0134] Meanwhile, the processor (13) of the user authentication server (10) can calculate the first fee to be paid from the card issuer and the second fee to be paid to the card issuer.

[0135] Here, the first fee may be a fee incurred per issuance of a physical card registered as an authentication card. The second fee may be a fee incurred per user authentication process using a physical card registered as an authentication card.

[0136] Additionally, the processor (13) of the user authentication server (10) can calculate a third-party fee to be paid from the payment company.

[0137] Here, the third fee may be a fee incurred per user authentication process using a physical card registered as the authentication card. The second fee is a fee that the user authentication server (10) must pay to the card issuer, while the third fee is a fee that the user authentication server (10) must receive from the payment company. In this case, the second fee may be set at a lower price than the third fee.

[0138] Here, the payment company refers to a company or institution that a user uses for financial transactions, and may refer to a company or institution that requires user authentication via a user authentication server (10) during financial transactions. Payment companies may include banks, card companies, simple payment service providers, mobile payment service providers, etc.

[0139] Additionally, the processor (13) of the user authentication server (10) can calculate a fourth fee to be paid to the card manufacturer or user authentication software provider.

[0140] Here, the fourth fee may be a fee incurred per physical card issued as a card for authentication. The first fee is the fee that the user authentication server (10) must receive from the card issuer, while the fourth fee is the fee that the user authentication server (10) must pay to the card manufacturer or user authentication software provider. In this case, the sum of the fourth fee to be paid to the card manufacturer and the fourth fee to be paid to the user authentication software provider may be set within the first fee.

[0141] Below, a detailed description will be given of how the virtual code generation module generates virtual code. Here, the virtual code generation module may be included in the first applet (31) or may be the first applet (31) itself.

[0142] The virtual code generation module can generate one or more subcodes. A subcode is a portion of the code that constitutes a virtual code. The virtual code may consist solely of subcodes, or it may be formed by combining one or more subcodes with a virtual security code generated by the OTP function, ultimately forming a virtual code (OTAC).

[0143] The virtual code generation module includes a code generation function that generates a virtual code, and the code generation function includes a detail code generation function that generates one or more detail codes, and a detail code combination function that generates a virtual code by combining the detail codes (i.e., a rule for combining multiple detail codes).

[0144] That is, when a virtual code includes multiple detailed codes, the code generation function generates multiple detailed codes using multiple detailed code generation functions, and combines the multiple detailed codes into a preset combination using the detailed code combination function to generate a virtual code.

[0145] A virtual code verification module has a correlation between multiple detailed codes to search for a storage location of information that can identify a user or an authentication card. That is, the virtual code verification module has a search algorithm, and the search algorithm extracts multiple detailed codes included in the virtual code and searches for a storage location of identification information (eigenvalue) of a user or an authentication card based on the correlation between the multiple detailed codes. As an example of the correlation between the multiple detailed codes, the search algorithm can search for the storage location by calculating the correlation between the multiple detailed codes from a transit point corresponding to one or more of the multiple detailed codes. At this time, the transit points may be one or more, and there is no limitation on the number and order.

[0146] In addition, as an embodiment of a plurality of detailed codes, the plurality of detailed codes may include a first code and a second code, and the virtual code generation module includes a first function and a second function as detailed code generation functions to generate the first code and the second code. The first code and the second code have a correlation for searching the storage location within the virtual code verification module, but the virtual code generation module may not include data on the correlation between the first code and the second code, but may only include a first function for generating the first code and a second function for generating the second code as detailed code generation functions to enhance security.

[0147] As a specific example of the correlation between the first and second codes, the first and second codes may each perform a role in searching for the storage location. That is, the first code may include information about the transit point, and the second code may include information necessary for an operation to reach the storage location from the transit point.

[0148] Meanwhile, in one embodiment of the present disclosure, the first code may be generated based on the first count, and the second code may be generated based on the second count. In this case, the first count may be the number of unit counts that have elapsed from the initial point in time when the code generation function is executed in the virtual code generation module or the virtual code verification module to the point in time when the virtual code is generated, and the second count may include the number of unit counts that have elapsed from the point in time when the identification information (unique value) is stored in the virtual code verification module.

[0149] That is, the first function that generates the first code is a function that provides a specific code value corresponding to the first count, and the second function that generates the second code is a function that provides a specific code value corresponding to the second count.

[0150] Below, a detailed description will be given of how a virtual code verification module verifies virtual code. Here, the virtual code verification module may be included in a user authentication server (10) or may be the user authentication server (10) itself.

[0151] In one embodiment of the present disclosure, the virtual code verification module can verify the virtual code by comparing the time data received by the virtual code with the time data included in the virtual code.

[0152] Specifically, the virtual code verification module verifies whether the virtual code is normally generated. That is, after receiving the virtual code, the virtual code verification module determines whether the received virtual code is normally generated at the current point in time based on the information stored in the virtual code verification module (i.e., the code generation function and seed data), thereby determining whether the virtual code is normal. The virtual code verification module applies the inverse function of the code generation function to the virtual code to find the count corresponding to the time at which the virtual code was generated. Since there is a difference between the time at which the virtual code is generated and the time at which the virtual code verification module receives the virtual code due to the transmission time or delay of the virtual code, the count at which the virtual code verification module receives the virtual code and the count at which the OTP number for authentication is generated may not match, and therefore the virtual code verification module allows a margin of error from the count at which the virtual code is received.

[0153] Meanwhile, in one embodiment of the present disclosure, the virtual code verification module searches for a storage location of identification information (unique value) of a user or an authentication card based on the virtual code, extracts the identification information (unique value), and performs user or authentication card authentication based on the extracted identification information (unique value).

[0154] Although FIGS. 5 to 8 describe the steps as being executed sequentially, this is merely an example of the technical idea of ​​the present embodiment, and a person having ordinary skill in the technical field to which the present embodiment pertains can modify and apply various modifications and variations by changing the order described in FIGS. 5 to 8 or executing them in parallel without departing from the essential characteristics of the present embodiment, and therefore FIGS. 5 to 8 are not limited to a chronological order.

[0155] Meanwhile, in the above description, the steps described in FIGS. 5 through 8 may be further divided into additional steps or combined into fewer steps, depending on the implementation of the present disclosure. Furthermore, some steps may be omitted as needed, and the order of the steps may be changed.

[0156] Meanwhile, the disclosed embodiments may be implemented in the form of a recording medium storing computer-executable instructions. The instructions may be stored in the form of program code, and when executed by a processor, may generate program modules to perform the operations of the disclosed embodiments. The recording medium may be implemented as a computer-readable recording medium.

[0157] Computer-readable storage media include all types of storage media that store instructions that can be deciphered by a computer. Examples include read-only memory (ROM), random access memory (RAM), magnetic tape, magnetic disks, flash memory, and optical data storage devices.

[0158] The disclosed embodiments have been described with reference to the attached drawings as described above. Those skilled in the art will understand that the present disclosure can be implemented in forms other than the disclosed embodiments without altering the technical spirit or essential features of the present disclosure. The disclosed embodiments are illustrative and should not be construed as limiting.

Claims

1. Communication module; and When a selection of at least one card issued to the user is input from the user's terminal through the communication module, the selected card is registered as the user's authentication card, and when approval of a financial transaction using the authentication card is requested from the user's terminal through the communication module, a processor is included that performs user authentication based on a virtual code; The above virtual code is generated through the first applet for generating a virtual code loaded in the authentication card when manufacturing or issuing the authentication card. User authentication server through tagging of authentication cards.

2. In paragraph 1, The first applet includes at least one of a unique value for generating the virtual code and a card number of the authentication card, The above card number is injected into the second applet for payment and the first applet loaded in the authentication card, respectively. User authentication server through tagging of authentication cards.

3. In paragraph 2, The above processor, Generates a unique value for each card issuer or financial institution affiliated with said card issuer. User authentication server through tagging of authentication cards.

4. In paragraph 1, The above processor, Receiving the virtual code generated through tagging of the authentication card from the user terminal, and when the user authentication is completed through verification of the virtual code, approving the financial transaction. User authentication server through tagging of authentication cards.

5. In paragraph 4, The above user authentication is performed through the service application separately from the authentication through login to the application for the above financial transaction. User authentication server through tagging of authentication cards.

6. In paragraph 1, The above processor, When a change of the authentication card is requested from the user terminal, registration of the new authentication card is performed through tagging of the new authentication card. User authentication server through tagging of authentication cards.

7. In paragraph 6, The first applet loaded on the new authentication card includes a new unique value that is different from the unique value included in the first applet loaded on the previous authentication card. User authentication server through tagging of authentication cards.

8. In paragraph 1, The above processor, Calculate the first fee incurred per physical card issued as a card for authentication, Calculate the second fee incurred per user authentication process using a physical card registered as an authentication card. User authentication server through tagging of authentication cards.

9. In a method performed by a user authentication server, A step of receiving a selection of at least one card from the user's terminal among the cards issued to the user; A step of registering the selected card as an authentication card for the user; A step of receiving a request for approval of a financial transaction using the authentication card from the user terminal; and A step of performing user authentication based on a virtual code generated when the authentication card is tagged to the user terminal; The above virtual code is generated through the first applet for generating a virtual code loaded in the authentication card when manufacturing or issuing the authentication card. A method of user authentication through tagging of an authentication card.

10. For an authentication card for performing user authentication through tagging, A first applet including at least one of a unique value and a card number for generating a virtual code; and A second applet including the card number for payment during a financial transaction; The above first applet is loaded into the authentication card when the authentication card is manufactured or issued, The above authentication card is registered in the service application by selecting one of at least one card issued to the user as the authentication card, The above virtual code is generated by the first applet and transmitted to the user authentication server when the authentication card is tagged to the user's terminal during the financial transaction. Card for authentication.

Images