WO2023167390A1 - 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법 - Google Patents

인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법 Download PDF

Info

Publication number
WO2023167390A1
WO2023167390A1 PCT/KR2022/018676 KR2022018676W WO2023167390A1 WO 2023167390 A1 WO2023167390 A1 WO 2023167390A1 KR 2022018676 W KR2022018676 W KR 2022018676W WO 2023167390 A1 WO2023167390 A1 WO 2023167390A1
Authority
WO
WIPO (PCT)
Prior art keywords
card
user
virtual code
server
verification
Prior art date
Application number
PCT/KR2022/018676
Other languages
English (en)
French (fr)
Inventor
유창훈
Original Assignee
주식회사 센스톤
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020220156436A external-priority patent/KR20230131434A/ko
Application filed by 주식회사 센스톤 filed Critical 주식회사 센스톤
Priority to EP22922525.5A priority Critical patent/EP4273777A4/en
Priority to US18/359,330 priority patent/US20240020704A1/en
Publication of WO2023167390A1 publication Critical patent/WO2023167390A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/353—Payments by cards read by M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/50—Finance; Insurance
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y20/00—Information sensed or collected by the things
    • G16Y20/40—Information sensed or collected by the things relating to personal data, e.g. biometric data, records or preferences
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y40/00—IoT characterised by the purpose of the information processing
    • G16Y40/10—Detection; Monitoring

Definitions

  • the present disclosure relates to a method of registering a user in a holderless card using a virtual code for authentication.
  • Code type data is used in many fields. Not only card numbers and account numbers used for payment, but also IPIN numbers and resident registration numbers for user identification are code-type data.
  • OTP One Time Password
  • a separate OTP generating device is required, which is inconvenient.
  • An object of the present disclosure is to provide a method for registering a user in a holderless card using a virtual code for authentication.
  • a method of registering a user in a holderless card using a virtual code for authentication performed by a holderless card in the form of a physical form in which the user is not registered is , Receiving current time data from the user terminal through card tagging, using an applet included in the card, based on the current time data and pre-stored seed data, virtual authentication for authentication of the user generating a code and sending the virtual code to a verification server through the user terminal to request verification of the virtual code, wherein the card is manufactured in a state in which the user is not registered; When the verification is completed, the user is registered in the verification server by being connected to the mobile card already possessed by the user.
  • the verification request step may include the card number of the card pre-stored in the verification server through the user terminal and the At least one of the unique values of the card is further transmitted to request the verification, and when the verification is completed, at least one of the seed data, the card number of the card, and the unique value of the card in the verification server, and the user terminal User information generated in may be matched and stored.
  • the card number of the card, the unique value of the card, and the seed data are transmitted to the server of the card manufacturer by the verification server and embedded in an IC chip when the card is manufactured, and the card number of the card is , Includes the identification code of the financial company, and the unique value of the card may be a value sequentially assigned to each card manufactured by the card manufacturer.
  • the verification server is a service server that acts as a card issuance agent
  • the card is produced by a provider of the card issuance agent service
  • the user's registration is performed using the first method based on an application for registering a real card or a real card. It can be performed by the second method based on the interface for registration.
  • the user terminal is provided with the application provided by the service server, and the user registration of the first method is performed through the card tacking after the card number of the mobile card is input through the application.
  • the user registration of the first method is performed by matching the card number of the card and the card number of the mobile card searched based on the virtual code by the service server, and the card number of the card is When payment is requested through the completed card, it is transmitted from the payment server to the service server through the payment network, and the card number of the mobile card matched to the card number of the card is transmitted to the service server through the payment network.
  • the payment server may be transmitted to the payment server from
  • the user registration of the second method may be performed through the card tagging after the interface linked to the card issuance agency service is created in the application of the financial institution.
  • the user registration of the second method is performed based on the virtual code transmitted to the service server through the interface and a unique value of the user, and the card number of the card indicates the card for which the registration has been completed.
  • a payment is requested through the payment network, it is transmitted from the payment server to the service server and used for extracting the user-specific value, and the user-specific value is transmitted to the server of the financial company and used for extracting the card number of the mobile card.
  • the current time data may be received along with an APDU command for driving the applet when tagging the card, and in the generating step, the applet may be generated by driving the applet according to the APDU command.
  • a real-type holderless card device in which a user is not registered is an NFC that performs NFC-based communication when tagging with the user's terminal.
  • module and an IC module including an applet for generating a virtual code for authentication of the user, wherein the IC module, upon tagging with the user terminal, receives a current time from the user terminal through the NFC module Receives data, controls the applet, generates a virtual code based on the current time data and pre-stored seed data, and transmits the virtual code to a verification server through the user terminal, so that the verification server Verification of the virtual code is requested, the card device is manufactured in a state in which the user is not registered, and when the verification is completed, the user is registered by connecting to a mobile card previously owned by the user in the verification server.
  • a computer program stored in a computer readable recording medium for execution to implement the present disclosure may be further provided.
  • a computer readable recording medium recording a computer program for executing a method for implementing the present disclosure may be further provided.
  • the card it is possible to customize the card by linking with the card manufacturer or using an external issuance service, and by using it for marketing, the physical card can be used as a new transaction item.
  • FIG. 1 is a diagram schematically illustrating a system for registering a user in a holderless card using a virtual code for authentication according to the present disclosure.
  • FIG. 2 is a schematic configuration diagram of a holderless card device according to the present disclosure.
  • FIG. 3 is a flowchart of a method of registering a user in a holderless card using a virtual code for authentication according to the present disclosure.
  • FIG. 4 is a diagram for explaining how a user registers a user by connecting an unregistered physical card to a mobile card according to the present disclosure.
  • FIG. 5 is a diagram for explaining a registration process when a verification server according to the present disclosure is a financial institution server.
  • FIGS. 6 and 7 are diagrams for explaining a registration process when the verification server according to the present disclosure is a service server that acts as a card issuing agent.
  • FIG. 8 is a diagram illustrating a computing device according to the present disclosure.
  • the identification code is used for convenience of description, and the identification code does not explain the order of each step, and each step may be performed in a different order from the specified order unless a specific order is clearly described in context. there is.
  • a "character” is a component constituting a code, and includes all or part of uppercase alphabets, lowercase alphabets, numbers, and special characters.
  • code means a string in which characters are listed.
  • virtual code for authentication may mean a One Time Authentication Code (OTAC) that is temporarily generated for the user registration.
  • OTAC One Time Authentication Code
  • holderless card refers to a physical card equipped with an applet for generating a virtual code, and a card manufactured and issued without a user assigned thereto. Although the holderless card is not assigned to a user, an actual card number that can be used for payment after the user's registration process may be stored.
  • virtual code generation function means a function that generates virtual code.
  • OTP one time password
  • the "detailed code generation function” means a function that generates each of the detailed codes constituting the virtual code.
  • the "detail code combining function” means a function that generates a virtual code by combining or combining a plurality of detailed codes.
  • a "unit count” is a unit defined as being set at a specific time interval and changed as the time interval elapses. For example, 1 count may be set to a specific time interval (eg, 1.5 seconds) and used.
  • storage location means a point (count) on a track corresponding to a time point at which card registration is requested by a user.
  • user registration and “card registration” may be interpreted as having the same meaning as performing registration by assigning a user to a holderless card in an unspecified physical form.
  • FIG. 1 is a diagram schematically illustrating a system for registering a user in a holderless card using a virtual code for authentication according to the present disclosure.
  • a system 1 (hereinafter, the system) for registering a user in a holderless card using a virtual code for authentication includes a physical card 10, a user terminal 20, and a verification server 30.
  • the system 1 may include fewer or more components than those shown in FIG. 1 .
  • the physical card 10 is a holderless card that is produced and issued without a user being specified (registered). After that, when user registration is completed through virtual code verification, the user already possesses and uses a mobile card and can be connected
  • “real card” and “holderless card” may be interpreted as the same meaning.
  • user-related information is not embedded during manufacture. Depending on the embodiment, no information may be displayed on the surface of the physical card 10 .
  • the real card 10 includes an applet for generating a virtual code for authentication, and the virtual code for authentication (hereinafter, virtual code) based on the data received from the user terminal 20 and the embedded data using the applet. code) can be generated.
  • the physical card 10 may be a card device including an applet that performs various calculation processes for card registration.
  • the user terminal 20 may transmit current time data to the physical card 10 and the physical card 10 when tagging.
  • the user terminal 20 may receive the virtual code from the physical card 10 and transmit user information along with the virtual code to the verification server 30 .
  • the verification server 30 verifies the virtual code received from the user terminal 20 and when it is determined that the received virtual code is normally generated at the present time, user registration for the physical card 10 may be completed. As a result, the user's physical card 10 is connected to the mobile card already used by the user, and then, when payment is requested using the physical card 10, payment can be made with the mobile card connected to the physical card 10. .
  • the verification server 30 is shown as being composed of one server, but may be composed of a system in which a plurality of servers are linked to each other.
  • the real card 10, the user terminal 20, and the verification server 30 may transmit and receive various data, signals, or information to each other through a communication network.
  • wireless LANs such as WLAN (Wireless LAN), Wi-Fi, Wibro, Wimax, and High Speed Downlink Packet Access (HSDPA).
  • a wired communication method such as communication method or Ethernet, xDSL (ADSL, VDSL), HFC (Hybrid Fiber Coax), FTTC (Fiber to The Curb), FTTH (Fiber To The Home) may be used.
  • the communication network is not limited to the communication methods presented above, and may include all other types of communication methods that are widely known or will be developed in the future in addition to the above communication methods.
  • FIG. 2 is a schematic configuration diagram of a holderless card device according to the present disclosure.
  • the holderless card device 100 of FIG. 2 means the physical card 10 described with reference to FIG. 1 . That is, the holderless card device 10 is manufactured in a state where the user is not registered, and when the virtual code verification is completed, the physical card 10 in which the user is registered by connecting to the mobile card already owned by the user in the verification server 30 can mean
  • the holderless card device 100 may include an NFC module 120 and an IC module 140 . However, in some embodiments, the holderless card device 100 may include fewer or more components than those shown in FIG. 2 .
  • the Narrow Frequency Communication (NFC) module 120 (ie, NFC chip) is a communication module and can perform NFC-based communication when tagging with the user terminal 20 .
  • the IC module 140 (ie, the IC chip) may include an applet for generating a virtual code for user authentication. Although the IC module has been described as including an applet, the IC module 140 may be an applet itself.
  • the IC module 140 may include an EMV applet and an OTAC applet.
  • a card number and a unique value of the physical card 10 may be embedded in the EMV applet, and seed data for generating a virtual code (OTAC) may be embedded in the OTAC applet.
  • OTAC virtual code
  • the IC module 140 When tagging with the user terminal 20, the IC module 140 receives current time data from the user terminal 20 through the NFC module 120, and uses (controls) the applet (specifically, the OTAC applet). ), a virtual code can be generated based on the current time data and pre-stored seed data, and the virtual code can be transmitted to the user terminal 20 through the NFC module 120.
  • the user terminal 20 may request verification of the virtual code by transmitting the virtual code to the verification server 30 .
  • the holderless card device 100 may further include a separate communication module to communicate with the user terminal 20.
  • the virtual code may be transmitted to the user terminal 20 through a separate communication module.
  • the separate communication module may include a wireless communication module and a short-distance communication module.
  • wireless communication modules include global system for mobile communication (GSM), code division multiple access (CDMA), wideband code division multiple access (WCDMA), and universal mobile telecommunications system (UMTS). ), time division multiple access (TDMA), long term evolution (LTE), and a wireless communication module supporting various wireless communication schemes such as 4G, 5G, and 6G.
  • 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
  • wireless communication module supporting various wireless communication schemes such as 4G, 5G, and 6G.
  • the short-range communication module is for short-range communication, and includes BluetoothTM, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), ZigBee, and Near Field Communication (NFC). Communication), Wi-Fi (Wireless-Fidelity), Wi-Fi Direct, and wireless USB (Wireless Universal Serial Bus) technologies may be used to support short-distance communication.
  • RFID Radio Frequency Identification
  • IrDA Infrared Data Association
  • UWB Ultra Wideband
  • ZigBee Ultra Wideband
  • NFC Near Field Communication
  • Wi-Fi Wireless-Fidelity
  • Wi-Fi Direct Wireless USB (Wireless Universal Serial Bus) technologies may be used to support short-distance communication.
  • the IC module 140 is mounted in a PCB board and contacts the terminal of an IC type card reader to perform data exchange.
  • the IC module 140 includes an arbitrary form such as a component including an integrated circuit (IC) and a system on chip (SoC).
  • the IC chip may be an ISO 14443 NXP Mifare Classic type according to the present disclosure, but is not limited thereto.
  • FIG. 3 is a flowchart of a method of registering a user in a holderless card using a virtual code for authentication according to the present disclosure.
  • 4 is a diagram for explaining how a user registers a user by connecting an unregistered physical card to a mobile card according to the present disclosure.
  • the method of FIG. 3 may be performed by a holderless card.
  • the method of FIG. 3 will be described as being performed by the physical card 10 disclosed in FIG. 1 , but it may also be understood that the method of FIG. 3 is performed by the holderless card device 100 .
  • the present disclosure provides a physical card 10 (holderless card) user registration.
  • the physical card 10 may be obtained by purchasing the physical card 10 directly by the user, rather than being delivered to the user by a financial institution.
  • the physical card 10 may receive current time data from the user terminal 20 (hereinafter referred to as the user terminal) through card tagging (S110).
  • the physical card 10 may generate a virtual code for user authentication based on current time data and seed data pre-stored in the physical card using an applet included in the card (S120). At this time, the virtual code generated in each card can be generated so as not to be duplicated between cards by seed data stored in the card.
  • the physical card 10 may request verification of the virtual code by transmitting the virtual code to the verification server 30 through the user terminal 20 (S130).
  • the real card 10 may receive the current time data together with an APDU command for driving the applet from the user terminal 20 when tagging the card.
  • the physical card 10 when it receives the APDU command and current time data from the user terminal 20 through card tagging, it can drive an applet based on the APDU command.
  • the virtual code may be generated based on the received current time data and the seed data for generating the virtual code already stored in the card using the driven applet. The generated virtual code may be transmitted to the user terminal 20 .
  • the user terminal 20 may transmit at least one of user information logged into the financial service application and the received virtual code to the verification server 30 .
  • the user information may include the user's login information and mobile card information that the user wants to connect with the physical card 10 .
  • the financial service application may be an application built by the financial institution itself or an application provided from an external server.
  • the verification server 30 determines that the virtual code is normally generated at the present time, the user registration for the physical card 10 may be completed by connecting the physical card 10 to the mobile card.
  • the physical card 10 is produced and issued without user registration, and the user purchases it, registers it in a financial company application, and connects it to a mobile card in use to perform card registration.
  • the user may install a financial service application on his or her user terminal 20 and connect a mobile card already used by the user to the physical card 10 through the corresponding application.
  • the verification server 30 completes the verification of the virtual code generated by the physical card 10
  • the corresponding physical card 10 is connected to the mobile card, so that the user of the mobile card can use the physical card 10 Registration as a user may be completed.
  • the user registration may be performed using one application provided by the financial institution, and if the financial service application is an application provided from an external server, the user registration Registration may be performed using two applications, an application provided by a financial company and an application provided by an external service company.
  • the OTAC applet included in the physical card 10 may generate one or a plurality of detailed codes.
  • the detailed code refers to some codes constituting the virtual code.
  • the virtual code may consist of only the detailed code, or the final virtual code by combining one or more detailed codes with the first virtual security code generated by the OTP function. (OTAC) may be formed.
  • the OTAC applet includes a virtual code generating function that generates virtual codes, and the virtual code generating function includes a detailed code generating function that generates one or more detailed codes and a detailed code combining function that generates virtual codes by combining the detailed codes ( That is, a rule for combining a plurality of detailed codes).
  • the virtual code generating function when the virtual code includes a plurality of detailed codes, the virtual code generating function generates a plurality of detailed codes using the plurality of detailed codes generating functions, and generates the plurality of detailed codes through the detailed code combining function. Combining with a set combination creates a virtual security code.
  • a plurality of detailed codes have a correlation used by the verification server 30 to search for a storage space of information capable of identifying a user or a card. That is, the verification server 30 has a search algorithm (storage space search algorithm), and the search algorithm extracts a plurality of detailed codes included in the virtual code, and based on the correlation of the plurality of detailed codes, the user or The storage space of the identification information assigned to the card is searched.
  • the search algorithm included in the verification server 30 determines the correlation between the plurality of detailed codes from a waypoint corresponding to one or more detailed codes among the plurality of detailed codes. It is possible to search the storage location of the identification information of the user or card by calculating based on . At this time, the number of waypoints may be one or plural, and the number and order are not limited.
  • the plurality of detail codes may include first codes and second codes, and the OTAC applet includes the first function and the second function as detail code generation functions, 1st code and 2nd code are generated.
  • the first code and the second code have a correlation for searching the storage space of the identification information of the user or card in the verification server 30, but the OTAC applet first function to generate the first code to increase security and the second function for generating the second code as the detailed code generating function, but may not include data on the correlation between the first code and the second code.
  • the first code and the second code may play respective roles for searching for the storage space of the identification information. That is, the first code may include information about the waypoint, and the second code may include information necessary for an operation capable of reaching the storage space of the identification information from the waypoint.
  • the first code may be generated based on the first count
  • the second code may be generated based on the second count.
  • the first count is the number of unit counts that have elapsed from the first time the virtual code generating function is driven in the verification server 30 to the time the virtual code is generated
  • the second count is the number of user or card identification information It may include the number of unit counts that have elapsed from the point of time registered in (30).
  • the first function generating the first code is a function providing a specific code value corresponding to the first count
  • the second function generating the second code is a function providing a specific code value corresponding to the second count. am.
  • the verification server 30 when the verification server 30 receives the virtual code from the user terminal 20, the virtual code is obtained by comparing time data of the virtual code and time data of the virtual code. can be verified
  • the verification server 30 verifies whether the virtual code is normally generated. That is, after receiving the virtual code, the verification server 30 determines whether the received virtual code is normally generated at the current time based on information stored in the verification server 30 (ie, virtual code generating function and seed data). Check whether the virtual code is normal or not. For example, the verification server 30 inputs a count within a specific range from the count of receiving the virtual code to the virtual code generation function (ie, the OTP function), and determines whether there is a value that matches the virtual code among the OTP numbers calculated. Check. The verification server 30 applies an inverse function of the virtual code generating function to the virtual code to find a count corresponding to the time point at which the virtual code is generated.
  • the virtual code generation function ie, the OTP function
  • the verification server 30 allows an error range from the count receiving the virtual code.
  • the verification server 30 extracts the identification information of the user or card by searching the storage location of the identification information of the user or card based on the virtual code, and based on the extracted identification information User authentication can be performed with
  • FIG. 5 is a diagram for explaining a registration process when a verification server according to the present disclosure is a financial institution server.
  • a verification server according to the present disclosure is a financial institution server.
  • FIG. 5 a user registration process in the case where a financial company independently manufactures and issues a physical card 10 will be described.
  • the verification server 30 becomes the financial company server 31, and the physical card 10 is produced by a card manufacturer associated with the financial company.
  • step S130 the physical card 10 is transferred to the verification server 30 through the user terminal 20.
  • the virtual code as well as the card number of the physical card 10 pre-stored in the physical card 10 and the physical card 10 At least one of the eigenvalues of ) may be further transmitted.
  • At least one of the seed data, the card number of the physical card 10, and the unique value of the physical card 10 in the verification server 30, and the user terminal 20 ) User information generated in may be matched and stored.
  • the verification server 30 extracts seed data included in the virtual code, and at least among the extracted seed data, the card number of the real card 10, and the unique value of the real card 10.
  • One and user information may be matched to complete user registration for the physical card 10 .
  • the user information may include login information of a user logged into the financial company application and mobile card information (mobile card number) possessed by the user.
  • the card number of the physical card 10, the unique value of the physical card 10, and the seed data are transmitted to the server of the card manufacturer by the verification server 30, and IC when the physical card 10 is manufactured.
  • Embedded in the chip EMV applet and OTAC applet. That is, the card number of the physical card 10 , a unique value of the physical card 10 , and seed data of the physical card 10 may already be stored in the verification server 30 .
  • the card number of the physical card 10 includes the identification code (eg, BIN) of the financial company, and the unique value of the physical card 10 is a value sequentially assigned to each card manufactured by the card manufacturer.
  • the card manufacturer can install the virtual code (OTAC) server in the WAS server in the financial company system, and sequentially input the unique value provided by the virtual code (OTAC) server when making a physical card.
  • OEC virtual code
  • the server 30 may match and store the seed data extracted from the virtual code with the card number of the physical card 10 and the unique value of the physical card 10 with user information.
  • the verification server 30 determines the virtual code. After verification is complete, the seed data extracted from the virtual code and the card number of the real card 10 and user information may be matched and stored.
  • the verification server 30 determines the virtual code. After verification is completed, the seed data extracted from the virtual code and the unique value of the physical card 10 and user information may be matched and stored.
  • the physical card 10 provides first information (eg, card number) among the virtual code, the card number of the physical card 10, and the unique value of the physical card 10 through the user terminal 20.
  • first information eg, card number
  • the verification server 30 extracts seed data from the virtual code after verification of the virtual code, and receives the first received card number and unique value of the physical card 10.
  • Second information eg, eigenvalue
  • a card number and received user information may be matched and stored.
  • the user terminal 20 may transmit current time data to the physical card 10 (S21).
  • the physical card 10 may generate a virtual code based on the received current time data and pre-stored seed data (S22).
  • the physical card 10 may transmit at least one of the generated virtual code, the card number and the unique value of the pre-stored physical card 10 to the user terminal 20 (S23).
  • the user terminal 20 transmits user information to the financial institution server 31 together with at least one of the received virtual code, the card number of the physical card 10 and the unique value (S24).
  • the financial company server 31 may perform verification to determine whether the virtual code is a code generated normally at the present time (S25). When it is determined that the virtual code is a normal code (verification is completed), the financial company server 31 matches at least one of seed data, card number and unique value of the card, and user information to determine the user information for the physical card 10. Registration can be completed (S26).
  • the mobile card connected to the physical card 10 Payment can be made using
  • the physical card 10 and the mobile card may be connected by matching and storing the physical card number and the mobile card number in the financial company server 31 .
  • FIGS. 6 and 7 are diagrams for explaining a registration process when the verification server according to the present disclosure is a service server that acts as a card issuing agent.
  • a user registration process in the case of using a physical card 10 produced by a financial institution from outside will be described.
  • the reason why financial companies use physical cards produced outside of them instead of their own is that the number of physical cards that can be used offline is decreasing, and that physical cards and mobile cards/mobile payments tend to coexist. This is because there is a need for a service that can issue physical cards to users while reducing costs (material card production and delivery costs).
  • the verification server 30 becomes a service server 32 (hereinafter referred to as a service server) that acts as an agent for card issuance, and the physical card 10 ) is produced by the provider of the card issuance agency service.
  • user registration may be performed by a first method based on an application for registering a physical card or a second method based on an interface for registering a physical card.
  • the user terminal 20 may be provided with the registration application provided by the service server 32 .
  • User registration of the first method may be performed through tagging between the physical card 10 and the user terminal 20 after the card number of the mobile card already owned by the user is input through the registration application.
  • user registration of the first method may be performed by matching the card number of the real card 10 and the card number of the mobile card, which are searched by the service server 32 based on the virtual code.
  • the card number of the physical card 10 is transferred from the payment server (not shown) through the payment network to the service server 32.
  • the card number of the mobile card matched to the card number of the physical card 10 may be transmitted from the service server 32 to the payment server through the payment network.
  • the service server 32 may charge the financial company according to the number of payments using the physical card 10 (real card number) and the number of users who receive and use the physical card 10 through the card issuance agency service. there is.
  • the service server 32 may provide an application for registration to the user terminal 20 (S31).
  • the user terminal 20 may install an application for registration (S32).
  • the user can input the card number of the mobile card he/she is using through the application for registration (S33).
  • the user terminal 20 may transmit current time data to the physical card 10 (S34).
  • the physical card 10 may generate a virtual code based on the received current time data and pre-stored seed data (S35).
  • the physical card 10 may transmit the generated virtual code to the user terminal 20 (S36).
  • the user terminal 20 may transmit the virtual code and the card number of the mobile card input by the user to the service server 32 (S37).
  • the service server 32 may search for the card number of the physical card 10 based on the virtual code (S38). Specifically, the issuance agent server 32 may extract seed data included in the virtual code and search for a real card number matched with the seed data and stored in the server. The service server 32 may complete user registration by matching the card number of the searched physical card with the card number of the mobile card (S39).
  • the service server 32 may receive the card number of the physical card from the payment server (not shown) through the payment network.
  • the service server 20 provides the card number (mobile card number) of the mobile card matched to the card number (real card number) of the received real card to the payment server through the payment network, so that the payment server obtains the mobile card number. You can use it to proceed with payment.
  • a registration interface linked to the card issuance agency service is created in the financial company application installed in the user terminal 20, and then, when the physical card 10 is tagged in the user terminal 20, the second method is performed through the registration interface. User registration may be performed. At this time, the interface for registration may be created through linkage of the SDK and API of the service server 32 .
  • the user registration of the second method may be performed based on the virtual code transmitted to the service server 32 through the registration interface and the unique value of the user.
  • the service server 32 can extract the unique value of the user using the received physical card number.
  • the service server 32 may transmit the unique value of the user to the financial company server based on the extracted user's unique value and financial company information.
  • the financial company server may perform payment by searching for the card number (mobile card number) of the mobile card issued to the user using the user's unique value.
  • the user's unique value may mean user's identification information for a specific mobile card for which connection with the physical card 10 is requested.
  • the service server 32 may charge the financial company according to the number of payments using the physical card 10 and the number of users who receive and use the physical card 10 through the card issuance agency service.
  • a registration interface interworking with the service server 32 may be created in the financial company application installed on the user terminal 20 (S41).
  • the interface for registration may be generated when the user selects a specific mobile card desired to be connected to the actual card 10 from among mobile cards registered in the financial company application.
  • the user terminal 20 may transmit current time data to the physical card 10 (S42).
  • the physical card 10 may generate a virtual code based on the received current time data and pre-stored seed data (S43).
  • the physical card 10 may transmit the generated virtual code to the user terminal 20 (S44).
  • the user terminal 20 may transmit the virtual code and the unique value of the user to the service server 32 (S45).
  • the unique value of the user may mean user identification information for the specific mobile card.
  • the service server 32 may search for the card number (real card number) of the physical card 10 based on the virtual code (S46). Specifically, the service server 32 may extract seed data included in the virtual code and search for a physical card number matched with the seed data and stored in the server. The service server 32 may complete user registration by matching the searched card number of the physical card with the unique value of the user (S47).
  • the service server 32 may receive the card number of the physical card from the payment server (not shown) through the payment network.
  • the service server 20 may transmit the user's unique value to the financial company server by using the user's unique value matched with the received card number (real card number) of the physical card and the financial company information.
  • the financial company server may proceed with payment by searching for the card number of the mobile card connected to the actual card 10 using the received user's unique value.
  • FIGS. 3, 5 to 7 are described as sequentially executing steps, but this is merely an example of the technical idea of this embodiment, and those skilled in the art to which this embodiment belongs can see this Since it will be possible to apply various modifications and variations by changing the order described in FIGS. 3 and 5 to 7 without departing from the essential characteristics of the embodiment or by executing them in parallel, FIGS. 3, 5 to 7 It is not limited to a time-series order.
  • FIGS. 3 and 5 to 7 may be further divided into additional steps or combined into fewer steps according to embodiments of the present disclosure. Also, some steps may be omitted if necessary, and the order of steps may be changed.
  • the computing device TN100 may be any of the devices described herein (eg, the user terminal 20, the verification server 30, etc.).
  • the computing device TN100 may include at least one processor TN110, a transceiver TN120, and a memory TN130.
  • the computing device TN100 may further include a storage device TN140, an input interface device TN150, and an output interface device TN160. Elements included in the computing device TN100 may communicate with each other by being connected by a bus TN170.
  • the processor TN110 may execute program commands stored in at least one of the memory TN130 and the storage device TN140.
  • the processor TN110 may mean a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed.
  • Processor TN110 may be configured to implement procedures, functions, methods, and the like described in relation to embodiments of the present invention.
  • the processor TN110 may control each component of the computing device TN100.
  • Each of the memory TN130 and the storage device TN140 may store various information related to the operation of the processor TN110.
  • Each of the memory TN130 and the storage device TN140 may include at least one of a volatile storage medium and a non-volatile storage medium.
  • the memory TN130 may include at least one of read only memory (ROM) and random access memory (RAM).
  • the transmitting/receiving device TN120 may transmit or receive a wired signal or a wireless signal.
  • the transmitting/receiving device TN120 may perform communication by being connected to a network.
  • the disclosed embodiments may be implemented in the form of a recording medium storing instructions executable by a computer. Instructions may be stored in the form of program codes, and when executed by a processor, create program modules to perform operations of the disclosed embodiments.
  • the recording medium may be implemented as a computer-readable recording medium.
  • Computer-readable recording media include all types of recording media in which instructions that can be decoded by a computer are stored. For example, there may be read only memory (ROM), random access memory (RAM), magnetic tape, magnetic disk, flash memory, optical data storage device, and the like.
  • ROM read only memory
  • RAM random access memory
  • magnetic tape magnetic tape
  • magnetic disk magnetic disk
  • flash memory optical data storage device

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법이 제공된다. 상기 방법은, 카드 태깅을 통해 상기 사용자의 단말로부터 현재 시간 데이터를 수신하는 단계, 상기 카드에 포함된 애플릿(Applet)을 이용하여, 상기 현재 시간 데이터 및 기 저장된 시드 데이터를 기반으로 상기 사용자의 인증을 위한 가상코드를 생성하는 단계 및 상기 가상코드를 상기 사용자 단말을 통해 검증 서버로 송신하여 상기 가상코드에 대한 검증을 요청하는 단계;를 포함한다.

Description

인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법
본 개시는 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법에 관한 것이다.
코드형태 데이터는 많은 영역에서 이용되고 있다. 결제 시에 이용되는 카드번호, 계좌 번호뿐만 아니라 사용자 식별을 위한 IPIN번호, 주민등록번호 등이 코드형태 데이터이다.
그러나 이러한 코드데이터를 이용하는 과정에서 유출되는 사고가 많이 발생한다. 카드번호의 경우, 카드 표면에 실제 카드번호가 그대로 기재되어 있어서 타인에게 시각적으로 유출되며, 마그네틱을 이용한 결제 시에 카드번호가 그대로 POS장치로 전달되면서 유출된다.
실제코드가 그대로 유출되지 않도록 하기 위해 가상코드를 이용하고자 하는 시도가 많았으나, 가상코드에 대응되는 실제코드를 탐색하기 위해 사용자를 식별하기 위한 데이터가 필요하였다.
그러나 OTP(One Time Password)의 경우, 별도의 OTP생성 장치를 필요로 하여 불편함을 수반하고, 특히 사용자 단말기의 경우 OTP생성에 이용되는 시드 데이터의 유출로 보안상의 취약점 존재한다.
따라서 많은 사용자가 소지하고 있는 카드의 카드 데이터를 기반으로 사용자 인증에 필요한 가상 보안 코드를 생성하는 것과 같이 OTP코드를 생성하되, 별도의 OTP생성 장치를 필요로 하지 않고 동시에 시드 데이터가 유출되지 않도록 하여 보안을 높이는 방안이 필요하다. 그러나 아직까지 이에 대한 적절한 방안이 제시되지 못하는 실정이다.
본 개시에 개시된 실시예는 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법을 제공하는데 그 목적이 있다.
본 개시가 해결하고자 하는 과제들은 이상에서 언급된 과제로 제한되지 않으며, 언급되지 않은 또 다른 과제들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
상술한 기술적 과제를 달성하기 위한 본 개시에 일 측면에 따른 사용자가 등록되지 않은 실물 형태의 홀더리스(Holderless) 카드에 의해 수행되는 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법은, 카드 태깅을 통해 상기 사용자의 단말로부터 현재 시간 데이터를 수신하는 단계, 상기 카드에 포함된 애플릿(Applet)을 이용하여, 상기 현재 시간 데이터 및 기 저장된 시드 데이터를 기반으로 상기 사용자의 인증을 위한 가상코드를 생성하는 단계 및 상기 가상코드를 상기 사용자 단말을 통해 검증 서버로 송신하여 상기 가상코드에 대한 검증을 요청하는 단계를 포함하고, 상기 카드는, 상기 사용자가 등록되지 않은 상태로 제작되고, 상기 검증이 완료되면 상기 검증 서버 내에 상기 사용자가 기 보유한 모바일 카드와 연결되어 상기 사용자가 등록되는 것이다.
또한, 상기 검증 서버가 금융사 서버이고, 상기 카드가 상기 금융사와 연계된 카드제조사에 의해 제작되는 경우, 상기 검증 요청 단계는, 상기 사용자 단말을 통해 상기 검증 서버로 기 저장된 상기 카드의 카드번호 및 상기 카드의 고유값 중 적어도 하나를 더 송신하여 상기 검증을 요청하고, 상기 검증이 완료되면, 상기 검증 서버 내에 상기 시드 데이터, 상기 카드의 카드번호 및 상기 카드의 고유값 중 적어도 하나, 및 상기 사용자 단말에서 생성된 사용자 정보가 매칭되어 저장될 수 있다.
또한, 상기 카드의 카드번호, 상기 카드의 고유값 및 상기 시드 데이터는, 상기 검증 서버에 의해 상기 카드제조사의 서버로 전달되어, 상기 카드의 제작 시 IC 칩에 내장되고, 상기 카드의 카드번호는, 상기 금융사의 식별코드를 포함하고, 상기 카드의 고유값은, 상기 카드제조사에 의해 제작되는 카드 별로 순차적으로 부여되는 값일 수 있다.
또한, 상기 검증 서버가 카드발급을 대행하는 서비스 서버이고, 상기 카드가 상기 카드발급 대행 서비스의 제공사에 의해 제작되는 경우, 상기 사용자의 등록은, 실물 카드 등록용 어플리케이션 기반의 제1 방식 또는 실물 카드 등록용 인터페이스 기반의 제2 방식에 의해 수행될 수 있다.
또한, 상기 사용자 단말은, 상기 서비스 서버에 의해 제공되는 상기 어플리케이션이 구비되고, 상기 제1 방식의 사용자 등록은, 상기 어플리케이션을 통해 상기 모바일 카드의 카드번호가 입력된 후에 상기 카드 태킹을 통해 수행될 수 있다.
또한, 상기 제1 방식의 사용자 등록은, 상기 서비스 서버에 의해 상기 가상코드 기반으로 탐색된 상기 카드의 카드번호와 상기 모바일 카드의 카드번호가 매칭되어 수행되고, 상기 카드의 카드번호는, 상기 등록이 완료된 상기 카드를 통해 결제가 요청되는 경우에 결제망을 통해 결제 서버로부터 상기 서비스 서버로 송신되고, 상기 카드의 카드번호에 매칭된 상기 모바일 카드의 카드번호는, 상기 결제망을 통해 상기 서비스 서버로부터 상기 결제 서버로 송신될 수 있다.
또한, 상기 제2 방식의 사용자 등록은, 금융사의 어플리케이션에 상기 카드발급 대행 서비스와 연동되는 상기 인터페이스가 생성된 후에 상기 카드 태깅을 통해 수행될 수 있다.
또한, 상기 제2 방식의 사용자 등록은, 상기 인터페이스를 통해 상기 서비스 서버로 송신된 상기 가상코드 및 상기 사용자의 고유값을 기반으로 수행되며, 상기 카드의 카드번호는, 상기 등록이 완료된 상기 카드를 통해 결제가 요청되는 경우에 결제망을 통해 결제 서버로부터 상기 서비스 서버로 송신되어 상기 사용자 고유값 추출에 이용되고, 상기 사용자 고유값은, 상기 금융사의 서버로 송신되어 상기 모바일 카드의 카드번호 추출에 이용될 수 있다.
또한, 상기 수신 단계는, 상기 카드 태깅 시에 상기 애플릿의 구동을 위한 APDU 명령어와 함께 상기 현재 시간 데이터가 수신되고, 상기 생성 단계는, 상기 APDU 명령어에 따라 상기 애플릿이 구동되어 생성될 수 있다.
또한, 상술한 기술적 과제를 달성하기 위한 본 개시에 다른 측면에 따른 사용자가 등록되지 않은 실물 형태의 홀더리스(Holderless) 카드 장치는, 상기 사용자의 단말과 태깅 시에 NFC 기반의 통신을 수행하는 NFC 모듈 및 상기 사용자의 인증을 위한 가상코드를 생성하기 위한 애플릿(Applet)이 포함된 IC 모듈을 포함하고, 상기 IC 모듈은, 상기 사용자 단말과 태깅 시, 상기 NFC 모듈을 통해 상기 사용자 단말로부터 현재 시간 데이터를 수신하고, 상기 애플릿을 제어하여, 상기 현재 시간 데이터 및 기 저장된 시드 데이터를 기반으로 가상코드를 생성하며, 상기 가상코드가 상기 사용자 단말을 통해 검증 서버로 송신되도록 하여, 상기 검증 서버에 상기 가상코드에 대한 검증을 요청하고, 상기 카드 장치는, 상기 사용자가 등록되지 않은 상태로 제작되고, 상기 검증이 완료되면 상기 검증 서버 내에 상기 사용자가 기 보유한 모바일 카드와 연결되어 상기 사용자가 등록되는 것일 수 있다.
이 외에도, 본 개시를 구현하기 위한 실행하기 위한 컴퓨터 판독 가능한 기록 매체에 저장된 컴퓨터 프로그램이 더 제공될 수 있다.
이 외에도, 본 개시를 구현하기 위한 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체가 더 제공될 수 있다.
본 개시의 전술한 과제 해결 수단에 의하면, 금융사가 카드 발급을 연계된 카드제조사를 통해 수행하거나, 외부의 발급대행 서비스를 이용함으로써 실물 카드를 제작하고 배송하는 데 드는 비용을 절감할 수 있다.
또한, 카드제조사와 연계하거나 외부 발급대행 서비스를 이용함으로써 카드의 커스터마이징이 가능하고 마케팅에 활용함으로써 실물 카드를 새로운 거래 물품으로 활용할 수 있다.
또한, 기존에는 실물 카드를 사용하기 위해 연회비를 지불해야 했지만, 실물 카드를 모바일 카드에 연결하여 사용함으로써 실물 카드에 대한 연회비를 지불할 필요가 없게 된다.
본 개시의 효과들은 이상에서 언급된 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시에 따른 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하기 위한 시스템을 개략적으로 나타낸 도면이다.
도 2는 본 개시에 따른 홀더리스 카드 장치의 개략적인 구성도이다.
도 3은 본 개시에 따른 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법의 순서도이다.
도 4는 본 개시에 따른 사용자가 등록되지 않은 실물 카드를 모바일 카드에 연결하여 사용자를 등록하는 것을 설명하기 위한 도면이다.
도 5는 본 개시에 따른 검증 서버가 금융사 서버인 경우의 등록 프로세스를 설명하기 위한 도면이다.
도 6 및 도 7은 본 개시에 따른 검증 서버가 카드발급을 대행하는 서비스 서버인 경우의 등록 프로세스를 설명하기 위한 도면이다.
도 8은 본 개시에 따른 컴퓨팅 장치를 나타내는 도면이다.
본 개시 전체에 걸쳐 동일 참조 부호는 동일 구성요소를 지칭한다. 본 개시가 실시예들의 모든 요소들을 설명하는 것은 아니며, 본 개시가 속하는 기술분야에서 일반적인 내용 또는 실시예들 간에 중복되는 내용은 생략한다. 명세서에서 사용되는 '부, 모듈, 부재, 블록'이라는 용어는 소프트웨어 또는 하드웨어로 구현될 수 있으며, 실시예들에 따라 복수의 '부, 모듈, 부재, 블록'이 하나의 구성요소로 구현되거나, 하나의 '부, 모듈, 부재, 블록'이 복수의 구성요소들을 포함하는 것도 가능하다.
명세서 전체에서, 어떤 부분이 다른 부분과 "연결"되어 있다고 할 때, 이는 직접적으로 연결되어 있는 경우뿐 아니라, 간접적으로 연결되어 있는 경우를 포함하고, 간접적인 연결은 무선 통신망을 통해 연결되는 것을 포함한다.
또한 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.
명세서 전체에서, 어떤 부재가 다른 부재 "상에" 위치하고 있다고 할 때, 이는 어떤 부재가 다른 부재에 접해 있는 경우뿐 아니라 두 부재 사이에 또 다른 부재가 존재하는 경우도 포함한다.
제 1, 제 2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위해 사용되는 것으로, 구성요소가 전술된 용어들에 의해 제한되는 것은 아니다.
단수의 표현은 문맥상 명백하게 예외가 있지 않는 한, 복수의 표현을 포함한다.
각 단계들에 있어 식별부호는 설명의 편의를 위하여 사용되는 것으로 식별부호는 각 단계들의 순서를 설명하는 것이 아니며, 각 단계들은 문맥상 명백하게 특정 순서를 기재하지 않는 이상 명기된 순서와 다르게 실시될 수 있다.
이하 첨부된 도면들을 참고하여 본 개시의 작용 원리 및 실시예들에 대해 설명한다.
이하, 첨부된 도면을 참조하여 본 개시의 실시예를 상세하게 설명한다.
설명에 앞서 본 명세서에서 사용하는 용어의 의미를 간략히 설명한다. 그렇지만 용어의 설명은 본 명세서의 이해를 돕기 위한 것이므로, 명시적으로 본 개시를 한정하는 사항으로 기재하지 않은 경우에 본 개시의 기술적 사상을 한정하는 의미로 사용하는 것이 아님을 주의해야 한다.
본 명세서에서 "문자"는 코드를 구성하는 구성요소로서, 대문자 알파벳, 소문자 알파벳, 숫자 및 특수문자 등의 전부 또는 일부를 포함한다.
본 명세서에서 "코드"는 문자가 나열된 문자열을 의미한다.
본 명세서에서 “인증용 가상코드”는 상기 사용자 등록을 위해 임시적으로 생성되는 OTAC(One Time Authentication Code)를 의미할 수 있다.
본 명세서에서 “홀더리스(holedrless) 카드”는 가상코드를 생성하기 위한 애플릿(Applet)이 탑재된 실물 카드로, 사용자가 할당되지 않은 상태로 제작 및 발급되는 카드를 의미한다. 홀더리스 카드는 사용자가 할당되지는 않았지만, 사용자의 등록 절차 이후에 결제에 사용 가능한 실제카드번호가 저장되어 있을 수 있다.
본 명세서에서 "가상코드 생성 함수"는 가상코드를 생성하는 함수를 의미한다. 예를 들어, OTP(One Time Password) 등을 포함하며, 이에 한정하는 것은 아니다.
본 명세서에서 "세부코드 생성 함수"는 가상코드를 구성하는 각각의 세부코드를 생성하는 함수를 의미한다.
본 명세서에서 "세부코드 결합 함수"는 복수의 세부코드를 조합 또는 결합하여 가상코드를 생성하는 함수를 의미한다.
본 명세서에서 "단위카운트"는 특정한 시간간격으로 설정되어, 상기 시간간격이 경과됨에 따라 변경되는 것으로 정의된 단위이다. 예를 들어, 1카운트는 특정한 시간간격(예를 들어, 1.5초)으로 설정되어 사용될 수 있다.
본 명세서에서 “저장위치”는 사용자에 의해 카드의 등록이 요청된 시점에 해당하는 트랙 상 지점(카운트)을 의미한다.
본 명세서에서 “사용자 등록” 및 “카드 등록”은 사용자가 특정되지 않은 실물 형태의 홀더리스 카드에 사용자를 할당하여 등록을 수행한다는 것으로 동일한 의미로 해석될 수 있다.
도 1은 본 개시에 따른 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하기 위한 시스템을 개략적으로 나타낸 도면이다.
도 1을 참조하면, 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하기 위한 시스템(1)(이하, 시스템)은 실물 카드(10), 사용자 단말(20) 및 검증 서버(30)를 포함한다. 다만, 몇몇 실시예에서 시스템(1)은 도 1에 도시된 구성요소보다 더 적은 수의 구성요소나 더 많은 수의 구성요소를 포함할 수도 있다.
실물 카드(10)는 사용자가 특정(등록)되지 않은 상태로 제작 및 발급되는 홀더리스(holderless) 카드로서, 이후 가상코드 검증을 통해 사용자 등록이 완료되면 사용자가 이미 보유하여 사용하고 있는 모바일 카드와 연결될 수 있다. 본 명세서에서, “실물 카드” 및 “홀더리스 카드”는 동일 의미로 해석될 수 있다.
실물 카드(10)는 사용자가 특정되지 않기 때문에 제작 시에 사용자 관련 정보가 내장되지 않는다. 실시예에 따라, 실물 카드(10)의 표면에는 어떠한 정보도 표시되지 않을 수 있다.
실물 카드(10)는 인증용 가상코드를 생성하기 위한 애플릿(Applet)을 포함하고, 애플릿을 이용하여 사용자 단말(20)로부터 수신된 데이터와 내장된 데이터를 기반으로 인증용 가상코드(이하, 가상코드)를 생성할 수 있다. 본 개시에서, 실물 카드(10)는 애플릿을 포함하여 카드 등록을 위한 다양한 연산처리를 수행하는 카드 장치일 수 있다.
사용자 단말(20)은 실물 카드(10)와 태깅 시 실물 카드(10)로 현재 시간 데이터를 송신할 수 있다.
사용자 단말(20)은 실물 카드(10)로부터 가상코드를 전달받아, 가상코드와 함께 사용자 정보를 검증 서버(30)로 송신할 수 있다.
검증 서버(30)는 사용자 단말(20)로부터 수신된 가상코드를 검증하여 수신된 가상코드가 현시점에 정상적으로 생성된 것으로 판단되면, 실물 카드(10)에 대한 사용자 등록을 완료할 수 있다. 이로써, 사용자의 실물 카드(10)는 사용자가 이미 사용하고 있던 모바일 카드와 연결되어, 이후 실물 카드(10)를 이용하여 결제가 요청되면 실물 카드(10)와 연결된 모바일 카드로 결제가 진행될 수 있다.
도 1을 참조하면, 검증 서버(30)는 하나의 서버로 구성된 것으로 표시되어 있지만, 복수의 서버가 서로 연계된 시스템 형태로 구성될 수도 있다.
도 1에 도시된 바와 같이, 실물 카드(10), 사용자 단말(20) 및 검증 서버(30)는 통신망을 통해 서로 각종 데이터, 신호 또는 정보를 송수신할 수 있다.
여기서, 통신망은 다양한 형태의 통신망이 이용될 수 있으며, 예컨대, WLAN(Wireless LAN), 와이파이(Wi-Fi), 와이브로(Wibro), 와이맥스(Wimax), HSDPA(High Speed Downlink Packet Access) 등의 무선 통신방식 또는 이더넷(Ethernet), xDSL(ADSL, VDSL), HFC(Hybrid Fiber Coax), FTTC(Fiber to The Curb), FTTH(Fiber To The Home) 등의 유선 통신방식이 이용될 수 있다.
한편, 통신망은 상기에 제시된 통신방식에 한정되는 것은 아니며, 상술한 통신방식 이외에도 기타 널리 공지되었거나 향후 개발될 모든 형태의 통신 방식을 포함할 수 있다.
도 2는 본 개시에 따른 홀더리스 카드 장치의 개략적인 구성도이다. 도 2의 홀더리스 카드 장치(100)는 도 1을 참조하여 설명한 실물 카드(10)를 의미한다. 즉, 홀더리스 카드 장치(10)는 사용자가 등록되지 않은 상태로 제작되고, 가상코드 검증이 완료되면 검증 서버(30) 내에 사용자가 기 보유한 모바일 카드와 연결되어 사용자가 등록되는 실물 카드(10)를 의미할 수 있다.
도 2를 참조하면, 홀더리스 카드 장치(100)는 NFC 모듈(120) 및 IC 모듈(140)을 포함할 수 있다. 다만, 몇몇 실시예에서 홀더리스 카드 장치(100)는 도 2에 도시된 구성요소보다 더 적은 수의 구성요소나 더 많은 수의 구성요소를 포함할 수도 있다.
NFC(Narrow Frequency Communication) 모듈(120)(즉, NFC 칩)은 통신 모듈로서, 사용자 단말(20)과 태깅 시에 NFC 기반의 통신을 수행할 수 있다.
IC 모듈(140)(즉, IC 칩)은 사용자의 인증을 위한 가상코드를 생성하기 위한 애플릿(Applet)을 포함할 수 있다. IC 모듈이 애플릿을 포함하는 것으로 설명하였지만, IC 모듈(140)이 애플릿 자체일 수 있다.
보다 상세하게, IC 모듈(140)은 EMV 애플릿 및 OTAC 애플릿을 포함할 수 있다. EMV 애플릿에는 실물 카드(10)의 카드번호 및 실물 카드(10)의 고유값이 내장되고, OTAC 애플릿에는 가상코드(OTAC) 생성을 위한 시드 데이터가 내장될 수 있다.
IC 모듈(140)은 사용자 단말(20)과 태깅 시, 상기 NFC 모듈(120)을 통해 상기 사용자 단말(20)로부터 현재 시간 데이터를 수신하고, 상기 애플릿(구체적으로, OTAC 애플릿)을 이용(제어)하여, 상기 현재 시간 데이터 및 기 저장된 시드 데이터를 기반으로 가상코드를 생성하고, NFC 모듈(120)을 통해 상기 가상코드를 상기 사용자 단말(20)로 송신할 수 있다. 사용자 단말(20)은 상기 가상코드를 검증 서버(30)로 송신하여 상기 가상코드에 대한 검증을 요청할 수 있다.
도 2에는 홀더리스 카드 장치(100)가 NFC 모듈(120)만 포함하는 것으로 도시하였지만, 홀더리스 카드 장치(100)는 별도의 통신 모듈을 더 구비하여 사용자 단말(20)과 통신을 수행할 수 있다. 즉, 별도의 통신 모듈을 통해 사용자 단말(20)로 가상코드를 송신할 수 있다. 여기서, 별도의 통신 모듈은 무선 통신 모듈 및 근거리 통신 모듈을 포함할 수 있다.
무선 통신 모듈은 와이파이(Wifi) 모듈, 와이브로(Wireless broadband) 모듈 외에도, 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, 6G 등 다양한 무선 통신 방식을 지원하는 무선 통신 모듈을 포함할 수 있다.
근거리 통신 모듈은 근거리 통신(Short range communication)을 위한 것으로서, 블루투스(Bluetooth™), RFID(Radio Frequency Identification), 적외선 통신(Infrared Data Association; IrDA), UWB(Ultra Wideband), ZigBee, NFC(Near Field Communication), Wi-Fi(Wireless-Fidelity), Wi-Fi Direct, Wireless USB(Wireless Universal Serial Bus) 기술 중 적어도 하나를 이용하여, 근거리 통신을 지원할 수 있다.
IC 모듈(140)은 PCB판 내에 실장되어 IC 방식의 카드리더기의 단자와 접촉하여 데이터 교환을 수행하도록 한다. IC 모듈(140)은 집적회로(Integrated circuit; IC)를 포함하는 부품, 시스템 온칩(System on chip; SoC) 등 임의의 형태를 포함한다. 예를 들어, IC 칩은 본 개시에 따라 ISO 14443 NXP Mifare Classic 타입일 수 있으나, 이에 한정하는 것은 아니다.
도 3은 본 개시에 따른 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법의 순서도이다. 도 4는 본 개시에 따른 사용자가 등록되지 않은 실물 카드를 모바일 카드에 연결하여 사용자를 등록하는 것을 설명하기 위한 도면이다. 도 3의 방법은 홀더리스 카드에 의해 수행될 수 있다. 이하에서는 도 3의 방법을 도 1에 개시된 실물 카드(10)가 수행하는 것으로 설명하지만, 이는 홀더리스 카드 장치(100)에 의해 수행되는 것으로도 이해될 수 있다.
본 개시는 사용자가 이미 금융사 어플리케이션(앱)에 등록하여 사용하고 있는 모바일 카드에 실물 카드(10)를 연결하여 실물 카드(10)를 오프라인 결제에 사용하길 원하는 경우에 실물 카드(10)(홀더리스 카드)의 사용자 등록을 수행할 수 있다. 본 개시에서 실물 카드(10)는 금융사가 사용자에게 배송해주는 것이 아니라 사용자가 직접 구매하여 획득될 수 있다.
도 3을 참조하면, 실물 카드(10)는 카드 태깅을 통해 사용자의 단말(20)(이하, 사용자 단말)로부터 현재 시간 데이터를 수신할 수 있다(S110).
실물 카드(10)는 상기 카드에 포함된 애플릿(Applet)을 이용하여, 현재 시간 데이터 및 실물 카드에 기 저장된 시드 데이터를 기반으로 사용자의 인증을 위한 가상코드를 생성할 수 있다(S120). 이때, 각 카드에서 생성되는 가상코드는 카드 내에 저장된 시드 데이터에 의해 카드 간에 절대 중복되지 않게 생성될 수 있다.
실물 카드(10)는 가상코드를 사용자 단말(20)을 통해 검증 서버(30)로 송신하여 가상코드에 대한 검증을 요청할 수 있다(S130).
실물 카드(10)는 상기 카드 태깅 시에 사용자 단말(20)로부터 상기 애플릿의 구동을 위한 APDU 명령어와 함께 상기 현재 시간 데이터를 수신할 수 있다.
즉, 실물 카드(10)는 카드 태깅을 통해 사용자 단말(20)로부터 APDU 명령어 및 현재 시간 데이터를 수신하면, APDU 명령어를 기반으로 애플릿을 구동시킬 수 있다. 그리고, 구동된 애플릿을 이용하여 수신된 현재 시간 데이터와 카드 내에 이미 저장되어 있던 가상코드 생성을 위한 시드 데이터를 기반으로 가상코드를 생성할 수 있다. 이렇게 생성된 가상코드는 사용자 단말(20)로 송신될 수 있다.
사용자 단말(20)은 금융서비스 어플리케이션에 로그인되어 있는 사용자 정보와 수신된 가상코드 중 적어도 하나를 검증 서버(30)로 송신할 수 있다. 여기서, 사용자 정보는 사용자의 로그인 정보 및 사용자가 실물 카드(10)와 연결하기를 원하는 모바일 카드 정보를 포함할 수 있다. 여기서, 금융서비스 어플리케이션은 금융사가 자체적으로 구축한 어플리케이션일 수 있고, 외부 서버로부터 제공받은 어플리케이션일 수 있다.
검증 서버(30)는 가상코드가 현시점에 정상적으로 생성된 것으로 판단되면, 실물 카드(10)를 모바일 카드에 연결하여 상기 실물 카드(10)에 대한 사용자 등록을 완료할 수 있다.
도 3을 참조하면, 실물 카드(10)는 사용자가 등록되지 않은 상태로 제작 및 발급되고, 사용자가 이를 구매하여 자신이 금융사 어플리케이션에 등록하여 사용 중인 모바일 카드에 연결하여 카드 등록을 수행할 수 있다. 보다 상세하게, 사용자는 자신의 사용자 단말(20)에 금융서비스 어플리케이션을 설치하여 해당 어플리케이션을 통해 자신이 이미 사용하고 있는 모바일 카드를 실물 카드(10)와 연결할 수 있다. 구체적으로, 검증 서버(30)가 실물 카드(10)에서 생성된 가상코드에 대한 검증을 완료하면, 해당 실물 카드(10)는 모바일 카드에 연결되어, 모바일 카드의 사용자가 실물 카드(10)의 사용자로 등록이 완료될 수 있다. 여기서, 금융서비스 어플리케이션이 금융사가 자체적으로 구축한 어플리케이션인 경우, 상기 사용자 등록은 금융사가 제공하는 하나의 어플리케이션을 이용하여 수행될 수 있고, 금융서비스 어플리케이션이 외부 서버로부터 제공받은 어플리케이션일인 경우, 상기 사용자 등록은 금융사가 제공하는 어플리케이션과 외부 서비스사가 제공하는 어플리케이션, 두 개의 어플리케이션을 이용하여 수행될 수 있다.
이하에서는 가상코드 생성 장치로서의 역할을 수행하는 실물 카드(10)가 가상코드를 생성하는 방법에 대해서 구체적으로 설명하도록 한다.
실물 카드(10)에 포함된 OTAC 애플릿은 하나 또는 복수의 세부코드를 생성할 수 있다. 세부코드는 가상코드를 구성하는 일부 코드를 의미하는데, 가상코드는 세부코드만으로 구성될 수도 있으며, 또는 OTP함수에 의해 생성된 제1 가상보안코드에 하나 또는 복수의 세부코드를 결합하여 최종 가상코드(OTAC)의 형태로 형성될 수도 있다.
OTAC 애플릿은 가상코드를 생성하는 가상코드 생성 함수를 포함하고, 가상코드 생성 함수는 하나 이상의 세부코드를 생성하는 세부코드 생성 함수와, 상기 세부코드를 결합하여 가상코드를 생성하는 세부코드 결합 함수(즉, 복수의 세부코드를 조합하는 규칙)를 포함한다.
즉, 가상코드가 복수의 세부코드를 포함하는 경우, 가상코드 생성 함수는 복수의 세부코드 생성 함수를 이용하여 복수의 세부코드를 생성하고, 상기 세부코드 결합 함수를 통해 상기 복수의 세부코드를 기 설정된 조합으로 결합하여 가상보안코드를 생성한다.
복수의 세부코드 간에는 검증 서버(30)가 사용자 또는 카드를 식별할 수 있는 정보의 저장공간을 탐색하기 위해 이용되는 상관관계를 가진다. 즉, 검증 서버(30)는 탐색 알고리즘(저장공간탐색알고리즘)을 구비하고, 상기 탐색 알고리즘은 가상코드에 포함된 복수의 세부코드를 추출하고, 상기 복수의 세부코드의 상관관계를 기반으로 사용자 또는 카드에 부여된 식별 정보의 저장공간을 탐색한다. 상기 복수의 세부코드가 가지는 상관관계에 대한 일 실시예로, 검증 서버(30)에 포함된 탐색 알고리즘은 복수의 세부코드 중 하나 이상의 세부코드에 대응하는 경유지점으로부터 상기 복수의 세부코드 간의 상관관계를 기반으로 연산하여 상기 사용자 또는 카드의 식별 정보의 저장위치를 탐색할 수 있다. 이때, 상기 경유지점은 하나 또는 복수일 수 있으며 개수 및 순서에 제한은 없다.
또한, 복수의 세부코드의 일 실시예로, 복수의 세부코드는 제1코드 및 제2코드를 포함할 수 있고, OTAC 애플릿은 세부코드 생성 함수로 제1함수와 제2함수를 포함하여, 제1코드 및 제2코드를 생성한다. 제1코드와 제2코드는 검증 서버(30) 내에서 사용자 또는 카드의 식별 정보의 저장공간을 탐색하기 위한 상관관계를 가지나, OTAC 애플릿은 보안성을 높이기 위해 제1코드를 생성하는 제1함수와 제2코드를 생성하는 제2함수를 세부코드 생성 함수로 포함할 뿐, 제1코드와 제2코드의 상관관계에 대한 데이터를 포함하지 않을 수 있다.
제1코드와 제2코드의 상관관계의 구체적인 예로, 제1코드와 제2코드는 상기 식별 정보의 저장공간을 탐색하기 위한 각각의 역할을 수행할 수 있다. 즉, 제1코드는 상기 경유지점에 대한 정보를 포함하고, 제2코드는 상기 경유 지점으로부터 상기 식별 정보의 저장공간에 도달할 수 있는 연산에 필요한 정보를 포함할 수 있다.
한편, 본 개시의 일 실시예로 제1코드는 제1카운트를 기반으로 생성되며, 제2코드는 제2카운트를 기반으로 생성될 수 있다. 이때, 제1카운트는 검증 서버(30)에서 가상코드 생성 함수가 구동된 최초시점으로부터 가상코드가 생성된 시점까지 경과된 단위 카운트의 개수이고, 제2카운트는 사용자 또는 카드의 식별 정보가 검증 서버(30)에 등록된 시점으로부터 경과된 단위 카운트 개수를 포함할 수 있다.
즉, 제1코드를 생성하는 제1함수는 제1카운트에 대응되는 특정한 코드값을 제공하는 함수이고, 제2코드를 생성하는 제2함수는 제2카운트에 대응되는 특정한 코드값을 제공하는 함수이다.
이하에서는, 가상코드 검증 장치로서의 역할을 수행하는 검증 서버(30)가 가상코드를 검증하는 방법에 대하여 구체적으로 설명하도록 한다.
본 개시의 일 실시예로, 검증 서버(30)가 상기 사용자 단말(20)로부터 상기 가상코드를 수신하면, 상기 가상코드를 수신한 시간 데이터 및 상기 가상코드의 시간 데이터를 비교하여 상기 가상코드를 검증할 수 있다.
구체적으로, 검증 서버(30)에서 가상코드가 정상적으로 생성된 것인지를 검증한다. 즉, 검증 서버(30)는 가상코드를 수신한 후 검증 서버(30)에 저장된 정보(즉, 가상코드 생성 함수 및 시드 데이터)를 바탕으로 상기 수신한 가상코드가 현 시점에 정상적으로 생성된 것인지를 확인하여 가상코드의 정상여부를 판단한다. 예를 들어, 검증 서버(30)는 가상코드 생성 함수(즉, OTP함수)를 가상코드를 수신한 카운트로부터 특정범위 내의 카운트를 입력하여 산출된 OTP번호 중에 가상코드와 일치하는 값이 있는지 여부를 확인한다. 검증 서버(30)는 가상코드에 가상코드 생성 함수의 역함수를 적용하여 가상코드가 생성된 시점에 상응하는 카운트를 찾아낸다. 가상코드의 전송시간이나 딜레이에 의해 가상코드가 생성된 시점과 검증 서버(30)가 가상코드를 수신한 시점의 차이가 존재함에 따라 검증 서버(30)가 가상코드를 수신한 카운트와 가상코드에 해당하는 OTP번호를 생성한 카운트가 일치하지 않을 수도 있으므로, 검증 서버(30)는 가상코드를 수신한 카운트로부터 오차범위를 허용한다.
한편, 본 개시의 일 실시예로 검증 서버(30)는 상기 가상코드를 기반으로 사용자 또는 카드의 식별 정보의 저장 위치를 탐색하여 상기 사용자 또는 카드의 식별 정보를 추출하고, 상기 추출한 식별 정보를 기반으로 사용자 인증을 수행할 수 있다.
도 5는 본 개시에 따른 검증 서버가 금융사 서버인 경우의 등록 프로세스를 설명하기 위한 도면이다. 이하에서는 도 5를 참조하여, 금융사에서 자체적으로 실물 카드(10)를 제작하고 발급하는 경우의 사용자 등록 프로세스를 설명하도록 한다.
이러한 경우, 검증 서버(30)는 금융사 서버(31)가 되고, 상기 실물 카드(10)가 상기 금융사와 연계된 카드제조사에 의해 제작된다.
S130에서, 실물 카드(10)는 사용자 단말(20)을 통해 상기 검증 서버(30)로 상기 가상코드뿐만 실물 카드(10) 내에 기 저장되어 있던 실물 카드(10)의 카드번호 및 실물 카드(10)의 고유값 중 적어도 하나를 더 송신할 수 있다.
그리고, 가상코드에 대한 검증이 완료되면, 검증 서버(30) 내에 상기 시드 데이터, 상기 실물 카드(10)의 카드번호 및 상기 실물 카드(10)의 고유값 중 적어도 하나, 및 상기 사용자 단말(20)에서 생성된 사용자 정보가 매칭되어 저장될 수 있다.
보다 상세하게, 검증이 완료되면 검증 서버(30)는 가상코드 내에 포함된 시드 데이터를 추출하여, 추출된 시드 데이터와, 실물 카드(10)의 카드번호 및 실물 카드(10)의 고유값 중 적어도 하나, 그리고 사용자 정보를 매칭하여 해당 실물 카드(10)에 대한 사용자 등록을 완료할 수 있다. 여기서, 사용자 정보는 금융사 어플리케이션에 로그인된 사용자의 로그인 정보 및 사용자가 보유한 모바일 카드의 정보(모바일 카드번호)를 포함할 수 있다.
실물 카드(10)의 카드번호, 실물 카드(10)의 고유값 및 상기 시드 데이터는, 상기 검증 서버(30)에 의해 상기 카드제조사의 서버로 전달되어, 상기 실물 카드(10)의 제작 시 IC 칩(EMV 애플릿 및 OTAC 애플릿)에 내장된다. 즉, 검증 서버(30)에는 실물 카드(10)의 카드번호, 실물 카드(10)의 고유값 및 실물 카드(10)의 시드 데이터가 이미 저장되어 있을 수 있다.
여기서, 실물 카드(10)의 카드번호는 상기 금융사의 식별코드(예를 들어, BIN)를 포함하고, 실물 카드(10)의 고유값은 상기 카드제조사에 의해 제작되는 카드 별로 순차적으로 부여되는 값일 수 있다. 카드제조사는 가상코드(OTAC) 서버를 금융사시스템 내 WAS 서버에 설치하고, 실물 카드 제작 시에 가상코드(OTAC) 서버에서 제공한 상기 고유값을 순차적으로 입력할 수 있다.
실시예에 따라, 실물 카드(10)가 사용자 단말(20)을 통해 가상코드, 실물 카드(10)의 카드번호 및 실물 카드(10)의 고유값을 검증 서버(30)로 송신하는 경우, 검증 서버(30)는 가상코드에 대한 검증 완료 후, 가상코드로부터 추출된 시드 데이터와 실물 카드(10)의 카드번호 및 실물 카드(10)의 고유값과 사용자 정보를 매칭하여 저장할 수 있다.
실시예에 따라, 실물 카드(10)가 사용자 단말(20)을 통해 가상코드 및 실물 카드(10)의 카드번호를 검증 서버(30)로 송신하는 경우, 검증 서버(30)는 가상코드에 대한 검증 완료 후, 가상코드로부터 추출된 시드 데이터와 실물 카드(10)의 카드번호와 사용자 정보를 매칭하여 저장할 수 있다.
실시예에 따라, 실물 카드(10)가 사용자 단말(20)을 통해 가상코드 및 실물 카드(10)의 고유값을 검증 서버(30)로 송신하는 경우, 검증 서버(30)는 가상코드에 대한 검증 완료 후, 가상코드로부터 추출된 시드 데이터와 실물 카드(10)의 고유값과 사용자 정보를 매칭하여 저장할 수 있다.
실시예에 따라, 실물 카드(10)가 사용자 단말(20)을 통해 가상코드, 실물 카드(10)의 카드번호 및 실물 카드(10)의 고유값 중 제1정보(예를 들어, 카드번호)를 검증 서버(30)로 송신하는 경우, 검증 서버(30)는 가상코드에 대한 검증 완료 후, 가상코드로부터 시드 데이터를 추출하고, 카드번호 및 실물 카드(10)의 고유값 중 수신된 제1정보(예를 들어, 카드번호)로부터 제2정보(예를 들어, 고유값)을 추출하고, 추출된 시드 데이터와 추출된 제2정보(예를 들어, 고유값), 수신된 제1정보(예를 들어, 카드번호), 수신된 사용자 정보를 매칭하여 저장할 수 있다.
도 5를 참조하면, 실물 카드(10)와 사용자 단말(20) 간에 태깅이 되면, 사용자 단말(20)은 실물 카드(10)로 현재 시간 데이터를 송신할 수 있다(S21). 실물 카드(10)는 수신된 현재 시간 데이터와 기 저장된 시드 데이터를 기반으로 가상코드를 생성할 수 있다(S22). 실물 카드(10)는 생성된 가상코드와, 기 저장된 실물 카드(10)의 카드번호 및 고유값 중 적어도 하나를 사용자 단말(20)로 송신할 수 있다(S23). 사용자 단말(20)은 수신된 가상코드, 실물 카드(10)의 카드번호 및 고유값 중 적어도 하나와 함께, 사용자 정보를 금융사 서버(31)로 송신한다(S24). 금융사 서버(31)는 가상코드가 현시점에 정상적으로 생성된 코드인지를 판단하는 검증을 수행할 수 있다(S25). 금융사 서버(31)는 가상코드가 정상적인 코드인 것으로 판단되면(검증이 완료되면), 시드 데이터, 카드의 카드번호 및 고유값 중 적어도 하나, 사용자 정보를 매칭하여 상기 실물 카드(10)에 대한 사용자 등록을 완료할 수 있다(S26).
이에 따라, 금융사 서버(31) 내에서 상기 실물 카드(10)와 상기 모바일 카드가 연결되어, 이후 사용자가 실물 카드(10)를 이용하여 오프라인 결제를 요청하면, 실물 카드(10)와 연결된 모바일 카드를 이용하여 결제가 진행될 수 있다. 여기서, 실물 카드(10)와 모바일 카드는 금융사 서버(31) 내에서 실물 카드번호와 모바일 카드번호가 매칭되어 저장됨으로써 연결될 수 있다.
도 6 및 도 7은 본 개시에 따른 검증 서버가 카드발급을 대행하는 서비스 서버인 경우의 등록 프로세스를 설명하기 위한 도면이다. 이하에서는 도 6 및 도 7을 참조하여, 금융사가 외부에서 제작한 실물 카드(10)를 이용하는 경우의 사용자 등록 프로세스를 설명하도록 한다. 이렇게 금융사가 자체적으로 제작하지 않고 외부에서 제작한 실물 카드를 이용하는 이유는, 현재 오프라인에서 사용 가능한 실물 카드의 발급 장수가 줄어들고 있고, 실물 카드와 모바일카드/모바일결제가 공존하는 추세이므로, 금융사는 관련 비용(실물 카드 제작 및 배송 비용)을 절감하면서 실물 카드를 사용자에게 발급할 수 있는 서비스를 필요로 하기 때문이다.
이렇게 카드발급을 대행하는 서비스 제공사에서 제작한 실물 카드(10)를 이용하는 경우, 검증 서버(30)는 카드발급을 대행하는 서비스 서버(32)(이하, 서비스 서버)가 되고, 상기 실물 카드(10)가 상기 카드발급 대행 서비스의 제공사에 의해 제작된다.
이렇게 서비스 제공사에서 제작한 실물 카드(10)를 이용하는 경우, 사용자 등록은 실물 카드 등록용 어플리케이션 기반의 제1 방식 또는 실물 카드 등록용 인터페이스 기반의 제2 방식에 의해 수행될 수 있다.
- 제1 방식에 의해 수행되는 경우 사용자 등록 방식
사용자 단말(20)은 상기 서비스 서버(32)가 제공하는 상기 등록용 어플리케이션이 구비될 수 있다.
제1 방식의 사용자 등록은 상기 등록용 어플리케이션을 통해 상기 사용자가 기 보유한 모바일 카드의 카드번호가 입력된 후에, 상기 실물 카드(10) 및 사용자 단말(20) 간의 태깅을 통해 수행될 수 있다.
여기서, 제1 방식의 사용자 등록은, 상기 서비스 서버(32)에 의해 상기 가상코드 기반으로 탐색된 상기 실물 카드(10)의 카드번호와 상기 모바일 카드의 카드번호가 매칭되어 수행될 수 있다.
이후, 사용자가 상기 등록이 완료된 상기 실물 카드(10)를 이용하여 결제를 요청하는 경우, 상기 실물 카드(10)의 카드번호가 결제망을 통해 결제 서버(미도시)로부터 상기 서비스 서버(32)로 송신되고, 상기 실물 카드(10)의 카드번호에 매칭된 상기 모바일 카드의 카드번호는 상기 결제망을 통해 상기 서비스 서버(32)로부터 상기 결제 서버로 송신될 수 있다.
이때, 서비스 서버(32)는 실물 카드(10)(실물 카드번호)를 이용한 결제 건수, 실물 카드(10)를 카드발급 대행 서비스를 통해서 발급받아서 사용하는 사용자 수에 따라 금융사에게 과금을 청구할 수 있다.
도 6을 참조하면, 서비스 서버(32)는 등록용 어플리케이션을 사용자 단말(20)로 제공할 수 있다(S31). 사용자 단말(20)은 등록용 어플리케이션을 설치할 수 있다(S32). 사용자는 등록용 어플리케이션을 통해 자신이 사용하고 있는 모바일 카드의 카드번호를 입력할 수 있다(S33). 그런 다음 실물 카드(10)와 사용자 단말(20) 간에 태깅이 되면, 사용자 단말(20)은 실물 카드(10)로 현재 시간 데이터를 송신할 수 있다(S34). 실물 카드(10)는 수신된 현재 시간 데이터와 기 저장된 시드 데이터를 기반으로 가상코드를 생성할 수 있다(S35). 실물 카드(10)는 생성된 가상코드를 사용자 단말(20)로 송신할 수 있다(S36). 사용자 단말(20)은 가상코드와 사용자가 입력한 모바일 카드의 카드번호를 서비스 서버(32)로 송신할 수 있다(S37). 서비스 서버(32)는 가상코드를 기반으로 실물 카드(10)의 카드번호를 탐색할 수 있다(S38). 구체적으로, 발급 대행 서버(32)는 가상코드에 포함된 시드 데이터를 추출하고, 서버 내에 상기 시드 데이터에 매칭되어 저장된 실물 카드번호를 탐색할 수 있다. 서비스 서버(32)는 탐색된 실물 카드의 카드번호를 모바일 카드의 카드번호와 매칭하여 사용자 등록을 완료할 수 있다(S39).
이에 따라, 이후 사용자가 실물 카드(10)를 이용하여 오프라인 결제를 요청하면, 서비스 서버(32)는 결제망을 통해 결제 서버(미도시)로부터 실물 카드의 카드번호를 수신할 수 있다. 서비스 서버(20)는 수신된 실물 카드의 카드번호(실물 카드번호)에 매칭된 모바일 카드의 카드번호(모바일 카드번호)를 결제망을 통해 상기 결제 서버로 제공하여, 결제 서버가 모바일 카드번호를 이용하여 결제를 진행하도록 할 수 있다.
- 제2 방식에 의해 수행되는 경우 사용자 등록 방식
사용자 단말(20)에 설치된 금융사 어플리케이션에 상기 카드발급 대행 서비스와 연동되는 등록용 인터페이스가 생성되고, 이후 사용자 단말(20)에 실물 카드(10)가 태깅되면 상기 등록용 인터페이스를 통해 제2 방식의 사용자 등록이 수행될 수 있다. 이때, 등록용 인터페이스는, 상기 서비스 서버(32)의 SDK 및 API 연동을 통해 생성될 수 있다.
여기서, 제2 방식의 사용자 등록은, 상기 등록용 인터페이스를 통해 상기 서비스 서버(32)로 송신된 상기 가상코드 및 사용자의 고유값을 기반으로 수행될 수 있다.
이후, 사용자가 상기 등록이 완료된 실물 카드(10)를 이용하여 결제를 요청하는 경우, 실물 카드(10)의 카드번호(실물 카드번호)가 결제망을 통해 결제 서버(미도시)로부터 서비스 서버(32)로 송신되면, 서비스 서버(32)는 수신된 실물 카드번호를 이용하여 상기 사용자의 고유값을 추출할 수 있다. 서비스 서버(32)는 추출된 사용자의 고유값 및 금융사 정보를 기반으로 금융사 서버로 상기 사용자의 고유값을 송신할 수 있다. 금융사 서버는 사용자의 고유값을 이용하여 사용자에게 발급한 모바일 카드의 카드번호(모바일 카드번호)를 탐색하여 결제를 수행할 수 있다. 여기서, 사용자의 고유값은 실물 카드(10)와의 연결이 요청된 특정 모바일 카드에 대한 사용자의 식별정보를 의미할 수 있다.
이때, 서비스 서버(32)는 실물 카드(10)를 이용한 결제 건수, 실물 카드(10)를 카드발급 대행 서비스를 통해서 발급받아서 사용하는 사용자 수에 따라 금융사에게 과금을 청구할 수 있다.
도 7을 참조하면, 사용자 단말(20)에 설치된 금융사 어플리케이션에 서비스 서버(32)와 연동되는 등록용 인터페이스가 생성될 수 있다(S41). 이때, 등록용 인터페이스는 사용자가 금융사 어플리케이션에 등록된 모바일 카드 중에서 실제 카드(10)와의 연결을 원하는 특정 모바일 카드를 선택했을 때 생성될 수 있다. 그런 다음, 실물 카드(10)와 사용자 단말(20) 간에 태깅이 되면, 사용자 단말(20)은 실물 카드(10)로 현재 시간 데이터를 송신할 수 있다(S42). 실물 카드(10)는 수신된 현재 시간 데이터와 기 저장된 시드 데이터를 기반으로 가상코드를 생성할 수 있다(S43). 실물 카드(10)는 생성된 가상코드를 사용자 단말(20)로 송신할 수 있다(S44). 사용자 단말(20)은 가상코드와 사용자의 고유값을 서비스 서버(32)로 송신할 수 있다(S45). 여기서, 사용자의 고유값은 상기 특정 모바일 카드에 대한 사용자 식별정보를 의미할 수 있다. 서비스 서버(32)는 가상코드를 기반으로 실물 카드(10)의 카드번호(실물 카드번호)를 탐색할 수 있다(S46). 구체적으로, 서비스 서버(32)는 가상코드에 포함된 시드 데이터를 추출하고, 서버 내에 상기 시드 데이터에 매칭되어 저장된 실물 카드번호를 탐색할 수 있다. 서비스 서버(32)는 탐색된 실물 카드의 카드번호를 상기 사용자의 고유값과 매칭하여 사용자 등록을 완료할 수 있다(S47).
이에 따라, 이후 사용자가 실물 카드(10)를 이용하여 오프라인 결제를 요청하면, 서비스 서버(32)는 결제망을 통해 결제 서버(미도시)로부터 실물 카드의 카드번호를 수신할 수 있다. 서비스 서버(20)는 수신된 실물 카드의 카드번호(실물 카드번호)에 매칭된 사용자의 고유값과 금융사 정보를 이용하여 해당 금융사 서버로 사용자의 고유값을 송신할 수 있다. 금융사 서버는 수신된 사용자의 고유값을 이용하여 해당 실제 카드(10)와 연결된 모바일 카드의 카드번호를 탐색하여 결제를 진행할 수 있다.
도 3, 도 5 내지 도 7은 단계들을 순차적으로 실행하는 것으로 기재하고 있으나, 이는 본 실시예의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 실시예가 속하는 기술분야에서 통상의 지식을 가진 자라면 본 실시예의 본질적인 특성에서 벗어나지 않는 범위에서 도 3, 도 5 내지 도 7에 기재된 순서를 변경하여 실행하거나 병렬적으로 실행하는 것으로 다양하게 수정 및 변형하여 적용 가능할 것이므로, 도 3, 도 5 내지 도 7는 시계열적인 순서로 한정되는 것은 아니다.
한편, 상술한 설명에서, 도 3, 도 5 내지 도 7에 기재된 단계들은 본 개시의 구현예에 따라서, 추가적인 단계들로 더 분할되거나, 더 적은 단계들로 조합될 수 있다. 또한, 일부 단계는 필요에 따라 생략될 수도 있고, 단계 간의 순서가 변경될 수도 있다.
도 8은 본 개시에 따른 컴퓨팅 장치를 나타내는 도면이다. 컴퓨팅 장치(TN100)는 본 명세서에서 기술된 장치(예, 사용자 단말(20), 검증 서버(30) 등)일 수 있다.
컴퓨팅 장치(TN100)는 적어도 하나의 프로세서(TN110), 송수신 장치(TN120), 및 메모리(TN130)를 포함할 수 있다. 또한, 컴퓨팅 장치(TN100)는 저장 장치(TN140), 입력 인터페이스 장치(TN150), 출력 인터페이스 장치(TN160) 등을 더 포함할 수 있다. 컴퓨팅 장치(TN100)에 포함된 구성 요소들은 버스(bus)(TN170)에 의해 연결되어 서로 통신을 수행할 수 있다.
프로세서(TN110)는 메모리(TN130) 및 저장 장치(TN140) 중에서 적어도 하나에 저장된 프로그램 명령(program command)을 실행할 수 있다. 프로세서(TN110)는 중앙 처리 장치(CPU: central processing unit), 그래픽 처리 장치(GPU: graphics processing unit), 또는 본 발명의 실시예에 따른 방법들이 수행되는 전용의 프로세서를 의미할 수 있다. 프로세서(TN110)는 본 발명의 실시예와 관련하여 기술된 절차, 기능, 및 방법 등을 구현하도록 구성될 수 있다. 프로세서(TN110)는 컴퓨팅 장치(TN100)의 각 구성 요소를 제어할 수 있다.
메모리(TN130) 및 저장 장치(TN140) 각각은 프로세서(TN110)의 동작과 관련된 다양한 정보를 저장할 수 있다. 메모리(TN130) 및 저장 장치(TN140) 각각은 휘발성 저장 매체 및 비휘발성 저장 매체 중에서 적어도 하나로 구성될 수 있다. 예를 들어, 메모리(TN130)는 읽기 전용 메모리(ROM: read only memory) 및 랜덤 액세스 메모리(RAM: random access memory) 중에서 적어도 하나로 구성될 수 있다.
송수신 장치(TN120)는 유선 신호 또는 무선 신호를 송신 또는 수신할 수 있다. 송수신 장치(TN120)는 네트워크에 연결되어 통신을 수행할 수 있다.
한편, 개시된 실시예들은 컴퓨터에 의해 실행 가능한 명령어를 저장하는 기록매체의 형태로 구현될 수 있다. 명령어는 프로그램 코드의 형태로 저장될 수 있으며, 프로세서에 의해 실행되었을 때, 프로그램 모듈을 생성하여 개시된 실시예들의 동작을 수행할 수 있다. 기록매체는 컴퓨터로 읽을 수 있는 기록매체로 구현될 수 있다.
컴퓨터가 읽을 수 있는 기록매체로는 컴퓨터에 의하여 해독될 수 있는 명령어가 저장된 모든 종류의 기록 매체를 포함한다. 예를 들어, ROM(Read Only Memory), RAM(Random Access Memory), 자기 테이프, 자기 디스크, 플래쉬 메모리, 광 데이터 저장장치 등이 있을 수 있다.
이상에서와 같이 첨부된 도면을 참조하여 개시된 실시예들을 설명하였다. 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자는 본 개시의 기술적 사상이나 필수적인 특징을 변경하지 않고도, 개시된 실시예들과 다른 형태로 본 개시가 실시될 수 있음을 이해할 것이다. 개시된 실시예들은 예시적인 것이며, 한정적으로 해석되어서는 안 된다.

Claims (11)

  1. 사용자가 등록되지 않은 실물 형태의 홀더리스(Holderless) 카드에 의해 수행되는 방법에 있어서,
    카드 태깅을 통해 상기 사용자의 단말로부터 현재 시간 데이터를 수신하는 단계;
    상기 카드에 포함된 애플릿(Applet)을 이용하여, 상기 현재 시간 데이터 및 기 저장된 시드 데이터를 기반으로 상기 사용자의 인증을 위한 가상코드를 생성하는 단계; 및
    상기 가상코드를 상기 사용자 단말을 통해 검증 서버로 송신하여 상기 가상코드에 대한 검증을 요청하는 단계;를 포함하고,
    상기 카드는, 상기 사용자가 등록되지 않은 상태로 제작되고, 상기 검증이 완료되면 상기 검증 서버 내에 상기 사용자가 기 보유한 모바일 카드와 연결되어 상기 사용자가 등록되는 것인,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  2. 제1항에 있어서,
    상기 검증 서버가 금융사 서버이고, 상기 카드가 상기 금융사와 연계된 카드제조사에 의해 제작되는 경우,
    상기 검증 요청 단계는,
    상기 사용자 단말을 통해 상기 검증 서버로 기 저장된 상기 카드의 카드번호 및 상기 카드의 고유값 중 적어도 하나를 더 송신하여 상기 검증을 요청하고,
    상기 검증이 완료되면, 상기 검증 서버 내에 상기 시드 데이터, 상기 카드의 카드번호 및 상기 카드의 고유값 중 적어도 하나, 및 상기 사용자 단말에서 생성된 사용자 정보가 매칭되어 저장되는,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  3. 제2항에 있어서,
    상기 카드의 카드번호, 상기 카드의 고유값 및 상기 시드 데이터는, 상기 검증 서버에 의해 상기 카드제조사의 서버로 전달되어, 상기 카드의 제작 시 IC 칩에 내장되고,
    상기 카드의 카드번호는, 상기 금융사의 식별코드를 포함하고,
    상기 카드의 고유값은, 상기 카드제조사에 의해 제작되는 카드 별로 순차적으로 부여되는 값인,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  4. 제1항에 있어서,
    상기 검증 서버가 카드발급을 대행하는 서비스 서버이고, 상기 카드가 상기 카드발급 대행 서비스의 제공사에 의해 제작되는 경우,
    상기 사용자의 등록은, 실물 카드 등록용 어플리케이션 기반의 제1 방식 또는 실물 카드 등록용 인터페이스 기반의 제2 방식에 의해 수행되는,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법
  5. 제4항에 있어서,
    상기 사용자 단말은, 상기 서비스 서버에 의해 제공되는 상기 어플리케이션이 구비되고,
    상기 제1 방식의 사용자 등록은, 상기 어플리케이션을 통해 상기 모바일 카드의 카드번호가 입력된 후에 상기 카드 태킹을 통해 수행되는,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  6. 제5항에 있어서,
    상기 제1 방식의 사용자 등록은, 상기 서비스 서버에 의해 상기 가상코드 기반으로 탐색된 상기 카드의 카드번호와 상기 모바일 카드의 카드번호가 매칭되어 수행되고,
    상기 카드의 카드번호는, 상기 등록이 완료된 상기 카드를 통해 결제가 요청되는 경우에 결제망을 통해 결제 서버로부터 상기 서비스 서버로 송신되고,
    상기 카드의 카드번호에 매칭된 상기 모바일 카드의 카드번호는, 상기 결제망을 통해 상기 서비스 서버로부터 상기 결제 서버로 송신되는,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  7. 제4항에 있어서,
    상기 제2 방식의 사용자 등록은, 금융사의 어플리케이션에 상기 카드발급 대행 서비스와 연동되는 상기 인터페이스가 생성된 후에 상기 카드 태깅을 통해 수행되는,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  8. 제7항에 있어서,
    상기 제2 방식의 사용자 등록은, 상기 인터페이스를 통해 상기 서비스 서버로 송신된 상기 가상코드 및 상기 사용자의 고유값을 기반으로 수행되며,
    상기 카드의 카드번호는, 상기 등록이 완료된 상기 카드를 통해 결제가 요청되는 경우에 결제망을 통해 결제 서버로부터 상기 서비스 서버로 송신되어 상기 사용자 고유값 추출에 이용되고,
    상기 사용자 고유값은, 상기 금융사의 서버로 송신되어 상기 모바일 카드의 카드번호 추출에 이용되는,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  9. 제1항에 있어서,
    상기 수신 단계는, 상기 카드 태깅 시에 상기 애플릿의 구동을 위한 APDU 명령어와 함께 상기 현재 시간 데이터가 수신되고,
    상기 생성 단계는, 상기 APDU 명령어에 따라 상기 애플릿이 구동되어 생성되는,
    인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법.
  10. 컴퓨터와 결합되어, 제1항의 방법을 실행하기 위해 컴퓨터 판독 가능한 기록 매체에 저장된 프로그램.
  11. 사용자가 등록되지 않은 실물 형태의 홀더리스(Holderless) 카드 장치에 있어서,
    상기 사용자의 단말과 태깅 시에 NFC 기반의 통신을 수행하는 NFC 모듈; 및
    상기 사용자의 인증을 위한 가상코드를 생성하기 위한 애플릿(Applet)이 포함된 IC 모듈;을 포함하고,
    상기 IC 모듈은,
    상기 사용자 단말과 태깅 시, 상기 NFC 모듈을 통해 상기 사용자 단말로부터 현재 시간 데이터를 수신하고,
    상기 애플릿을 제어하여, 상기 현재 시간 데이터 및 기 저장된 시드 데이터를 기반으로 가상코드를 생성하며,
    상기 가상코드가 상기 사용자 단말을 통해 검증 서버로 송신되도록 하여, 상기 검증 서버에 상기 가상코드에 대한 검증을 요청하고,
    상기 카드 장치는, 상기 사용자가 등록되지 않은 상태로 제작되고, 상기 검증이 완료되면 상기 검증 서버 내에 상기 사용자가 기 보유한 모바일 카드와 연결되어 상기 사용자가 등록되는 것인,
    실물 형태의 홀더리스 카드 장치.
PCT/KR2022/018676 2022-03-04 2022-11-24 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법 WO2023167390A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22922525.5A EP4273777A4 (en) 2022-03-04 2022-11-24 PROCEDURE FOR REGISTRATION OF A USER ON A HOLDERLESS CARD WITH VIRTUAL CODE FOR AUTHENTICATION
US18/359,330 US20240020704A1 (en) 2022-03-04 2023-07-26 Method for registering user in holderless card by using authentication virtual code

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2022-0027972 2022-03-04
KR20220027972 2022-03-04
KR1020220156436A KR20230131434A (ko) 2022-03-04 2022-11-21 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법
KR10-2022-0156436 2022-11-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/359,330 Continuation US20240020704A1 (en) 2022-03-04 2023-07-26 Method for registering user in holderless card by using authentication virtual code

Publications (1)

Publication Number Publication Date
WO2023167390A1 true WO2023167390A1 (ko) 2023-09-07

Family

ID=87575959

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/018676 WO2023167390A1 (ko) 2022-03-04 2022-11-24 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법

Country Status (3)

Country Link
US (1) US20240020704A1 (ko)
EP (1) EP4273777A4 (ko)
WO (1) WO2023167390A1 (ko)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160036471A (ko) * 2014-08-27 2016-04-04 유한회사 실릭스 오티피 기반의 가상 번호 결제 방법, 컴퓨터 판독가능한 기록매체 및 시스템
KR20170040469A (ko) * 2015-10-05 2017-04-13 페이몬㈜ Ｏｔｐ 기반의 스마트카드 및 이를 이용한 인증방법
KR101751894B1 (ko) * 2015-12-29 2017-07-03 한국정보통신주식회사 결제 단말 장치 및 일회용 카드 코드를 이용한 결제 처리 방법
JP2018506093A (ja) * 2014-11-20 2018-03-01 ブリリアンツ カンパニー リミテッド スマートマルチカードおよびスマートマルチカード用カードデータ発行方法
KR20200018284A (ko) * 2018-08-09 2020-02-19 주식회사 센스톤 가상코드를 생성 및 제공하는 스마트카드와 그 방법 및 프로그램
KR20210119945A (ko) * 2018-08-09 2021-10-06 주식회사 센스톤 가상보안코드를 이용한 사용자 인증 방법 및 시스템

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10607214B1 (en) * 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160036471A (ko) * 2014-08-27 2016-04-04 유한회사 실릭스 오티피 기반의 가상 번호 결제 방법, 컴퓨터 판독가능한 기록매체 및 시스템
JP2018506093A (ja) * 2014-11-20 2018-03-01 ブリリアンツ カンパニー リミテッド スマートマルチカードおよびスマートマルチカード用カードデータ発行方法
KR20170040469A (ko) * 2015-10-05 2017-04-13 페이몬㈜ Ｏｔｐ 기반의 스마트카드 및 이를 이용한 인증방법
KR101751894B1 (ko) * 2015-12-29 2017-07-03 한국정보통신주식회사 결제 단말 장치 및 일회용 카드 코드를 이용한 결제 처리 방법
KR20200018284A (ko) * 2018-08-09 2020-02-19 주식회사 센스톤 가상코드를 생성 및 제공하는 스마트카드와 그 방법 및 프로그램
KR20210119945A (ko) * 2018-08-09 2021-10-06 주식회사 센스톤 가상보안코드를 이용한 사용자 인증 방법 및 시스템

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4273777A4 *

Also Published As

Publication number Publication date
EP4273777A4 (en) 2024-05-01
EP4273777A1 (en) 2023-11-08
US20240020704A1 (en) 2024-01-18

Similar Documents

Publication Publication Date Title
WO2017222183A1 (ko) 거래 승인 처리 방법 및 카드사 서버
WO2013137528A1 (ko) 오프라인 거래 결제 시스템, 이를 위한 방법 및 장치
WO2013176474A1 (ko) 이동통신 단말기를 결제 단말기로 사용하기 위한 애플리케이션, 애플리케이션 서비스 프로바이더 시스템 및 방법
WO2016122035A1 (ko) 거래 전 확인이 가능한 카드 결제시스템 및 결제방법
WO2016060345A1 (ko) 멀티 카드 생성 방법, 멀티 카드 사용 방법 및 멀티 카드 시스템
WO2019031644A1 (ko) 가상카드번호 기반의 금융거래제공시스템, 가상카드번호생성장치, 가상카드번호검증장치, 가상카드번호 기반의 금융거래제공방법 및 가상카드번호 기반의 금융거래제공프로그램
WO2017209513A1 (ko) 모바일 결제 방법 및 그 장치
WO2014092286A1 (ko) 오프라인 상거래를 위한 결제 지원 방법, 이를 위한 시스템 및 장치
WO2020032498A1 (ko) 인증용가상코드를 이용한 사용자 인증 방법 및 시스템
WO2012115484A2 (ko) 모바일 카드 관리 방법
WO2020050584A1 (en) System and method for secure transactions with a trusted execution environment (tee)
WO2019203384A1 (ko) 온라인 또는 오프라인 결제 시 결제금액을 사용자가 직접 입력하고 금융기관에서 생성되는 일회성 결제 보안코드를 사용자가 받아 결제함으로써 개인정보 유출, 중복결제, 초과결제 또는 결제오류를 방지하는 모바일 페이먼트 서비스 방법 및 시스템
WO2013055114A1 (ko) 전자 결제 방법, 시스템 및 장치
WO2015069028A1 (ko) 이동통신단말기를 이용한 다채널 인증과 금융 이체 방법 및 시스템
WO2020045826A1 (ko) 디지털 키를 처리하는 전자 디바이스 및 그 동작 방법
WO2013187557A1 (ko) 오프라인 결제 시스템, 장치 및 방법
WO2014084608A1 (ko) 보안 요소 정보 관리 방법 및 시스템
WO2023167390A1 (ko) 인증용 가상코드를 이용하여 홀더리스 카드에 사용자를 등록하는 방법
WO2013039304A1 (ko) 전자 결제를 위한 회원 등록 방법과 그를 위한 시스템, 장치 및 단말기
WO2019031716A2 (ko) 가상토큰 기반의 결제제공시스템, 가상토큰생성장치, 가상토큰검증서버, 가상토큰 기반의 결제제공방법 및 가상토큰 기반의 결제제공프로그램
WO2013141457A1 (ko) 전자 결제 시스템, 단말기, 장치 및 방법
WO2020184815A1 (ko) 일회용 패스워드 기반 모바일 자동 결제방법 및 이를 이용한 시스템
EP3847603A1 (en) System and method for payment authentication
WO2020162739A1 (ko) 칩 고유값 기반의 가상코드를 이용하여 장치를 식별하는 방법, 프로그램 및 장치
WO2022145677A1 (ko) 일회용 qr코드를 활용한 신분 인증 및 간편 결제 통합 시스템 및 그 구동방법

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2022922525

Country of ref document: EP

Effective date: 20230731

WWE Wipo information: entry into national phase

Ref document number: 11202305688X

Country of ref document: SG