KR20160036471A - Payment method, computer readable recording medium and system using virtual number based on otp - Google Patents

Abstract

The objective of the present invention is to provide a one time password (OTP)-based virtual number payment method, and a computer readable recording medium and a system thereof. The objective of the present invention is to support a safe transaction in a payment or authentication process by generating a virtual number with utilization of OTP, which is a one-time pass, as a decryption key value. The virtual number payment method includes the steps of: operating a client application in a client terminal; generating an OTP if a password is received while the client application is operated; transmitting, by the client terminal, a virtual number generation request to an authentication server; generating, by the authentication server, the virtual number by using the OTP included in the virtual number generation request as an encryption key; transmitting, by the authentication server, the generated virtual number to the client terminal; receiving, by the client terminal, the virtual number and transmitting a payment request including the virtual number and payment information; receiving, by the authentication server, the payment request and extracting an actual card number matched with the virtual number; and processing, by the authentication server, a payment approval based on the actual card number by linking with a card company server.

Description

TECHNICAL FIELD [0001] The present invention relates to a virtual number settlement method, a computer readable recording medium and a computer readable recording medium,

The present invention relates to a virtual number payment method based on One Time Password (OTP), a computer readable recording medium and a system, and more particularly, And to a system and a system for extracting an actual payment card number by using the same.

With the increasing use of digital devices such as computers and smart phones, electronic commerce using digital devices has been widely used in various fields. In particular, mobile terminals such as smart phones have advantages that users always carry around, and various financial related applications are released to facilitate users' convenience.

In financial transactions (for example, bank transfer) using various computing devices including smartphones, an off-chip input method, which is a one-time password, has been commercialized as a function of security and authentication in place of an existing security card. However, otipi is simply used as a password or an authentication number and its use is very limited.

On the other hand, in the existing payment method, even though the user's mobile phone number and card number are important personal information, there is a need to protect the user from being leaked or abused directly. Furthermore, it is necessary to protect the data so that it can not be used even when important information is exposed or captured in the data transmission / reception process.

As a prior art, Korean Patent Laid-Open No. 10-2008-0044029 discloses a technique of generating a virtual card number and using the virtual card number for settlement when a home shopping payment process is performed in a home shopping payment system using a virtual card number, Is a technology in which the payment server inquires the virtual card number through the virtual card number generator and inquires the corresponding credit card number, and does not show a solution to the method of protecting data in transmission and reception. Therefore, the payment server can not directly decode the virtual card number, and always has to search for the corresponding credit card information through the virtual card number generator. Also, if the virtual card number generator is hacked, there is also a risk of leakage of real credit card information.

Korean Patent Publication No. 10-2008-0044029 (disclosed on May 20, 2008)

In order to solve the above problems, it is an object of the present invention to provide a virtual number generation method and system using an OTF.

According to a first aspect of the present invention, there is provided a virtual number generation method using an OTP (One Time Password), the method comprising: driving a client application operating in a secure operating system on a client terminal; Inputting a password when the client application is activated; generating an audiope; Automatically recognizing a card number previously stored from a security area or a general area by a security operating system; And generating a virtual number by encrypting the card number using the generated atopy.

According to a second aspect of the present invention, there is provided a virtual number generation system comprising: a client PC for making a payment for an online merchant; An online merchant server for receiving payment information from the client PC and requesting settlement; A card settlement agency server for receiving a settlement request from the online merchant server and delivering the settlement request to an authentication company; An authentication server that runs a client app on a client terminal in a push-type manner and issues and manages an opportunistic file in cooperation with an opportunistic server; And a client terminal for generating the first api by driving the client app, recognizing the previously stored card number, and generating a virtual number obtained by encrypting the card number using the first api, Is operated in the security operating system on the client terminal, and the card number is previously stored in the security area by the security operating system, or is stored in advance in the general area in an encrypted form.

According to a third aspect of the present invention, there is provided a virtual number generation system according to another embodiment, comprising: a client PC for making a payment for an online merchant; A client terminal for generating a first octet by driving a client app, recognizing a previously stored card number, and generating a virtual number obtained by encrypting the card number using the first orthopy; An online merchant server for receiving the virtual number and the telephone number from the client PC and request payment; A card settlement agency server for receiving a settlement request from an online merchant server and delivering the settlement request to an authentication company; And an authentication server for issuing and managing an authentication ticket in cooperation with an authentication server, wherein the client application operates in the security operating system on the client terminal, and the card number is stored in advance in the secure area by the secure operating system , And is stored in advance in the general area in an encrypted form.

Alternatively, the virtual number generation system may further include a card issuer server that receives payment request and payment information from the card settlement agency server and processes the payment in cooperation with the issuing bank server, and the payment information includes a virtual number, a telephone number, And the card issuer server decrypts the virtual number using the first off-chip as a decryption key value, and extracts the card number.

A fourth aspect of the present invention is a virtual number payment method comprising the steps of: driving a client app on a client terminal; generating an api when a password is input when the client app is running; The authentication server generating a virtual number using an encryption key included in the virtual number creation request, transmitting the virtual number generated by the authentication server to the client terminal, Transmitting a payment request including the virtual number and the payment information, extracting an actual card number corresponding to the virtual number by transmitting the payment request to the authentication server, And processing the settlement approval based on the actual card number in cooperation with the step It includes.

According to a fifth aspect of the present invention, there is provided a merchant server for receiving payment information from a client terminal, A card settlement agency server for receiving a settlement request from the merchant server and transmitting the settlement request to an authentication company; An authentication server including a payment authentication server for supporting the client application on the client terminal to proceed with a payment process and an authentication server for issuing and managing an authentication; And a client terminal for generating an auth type by driving the client app, and transmitting a virtual number generation request including the atopy to the payment authentication server, wherein the payment authentication server receives the virtual number generation request, After authenticating the password, the authentication server transmits the virtual number creation request to the atopy server. The atopy server verifies the atopy included in the virtual number creation request, and creates a virtual number And transmits the generated information to the client terminal.

The virtual number generation method and system using the OTF of the present invention can be a solution for preventing the problem of leakage of personal information, which has recently become an issue. In addition, a virtual number is generated by using an opportunistic password as a decryption key value, so that a secure transaction can be supported in a payment or authentication process.

As described above, the present invention utilizes a virtual number when transmitting and receiving data, thereby preventing personal information such as an actual card number or a mobile phone number from being leaked during data transmission and reception required for settlement, and protecting the information from being exposed even if it is leaked. .

FIG. 1 shows a virtual number generation system 100 using an orthopyxis according to an embodiment of the present invention.
2 shows an operating system of the client terminal 10 used for generating an opportunistic packet according to an embodiment of the present invention.
Fig. 3 (a) shows a general operation in a client terminal according to an embodiment of the present invention, Fig. 3 (b) shows a comparison of operations at the time of using an OTF according to another embodiment of the present invention (c) illustrate an embodiment of a security UI according to an embodiment of the present invention.
4 is a flowchart illustrating a virtual number generation method using an OTFT on a client terminal according to an embodiment of the present invention.
FIG. 5 illustrates a virtual number generation method using an OTFT according to an embodiment of the present invention.
6 illustrates a virtual number generation method using an OTFT according to another embodiment of the present invention.
FIG. 7 is a flowchart illustrating a virtual number-based payment service registration procedure according to an embodiment of the present invention.
FIG. 8 is a screen shot illustrating a virtual number-based payment service registration procedure according to an embodiment of the present invention.
9 is a flowchart illustrating a procedure of using a virtual number based payment service according to an embodiment of the present invention.
10 is a screen shot illustrating an online settlement service procedure among a virtual number based settlement service according to an embodiment of the present invention.
FIG. 11 is a screen shot illustrating an offline settlement service procedure among virtual number based settlement services according to an embodiment of the present invention.
12 is a flowchart illustrating a payment cancellation procedure of a virtual number-based payment service according to an embodiment of the present invention.
In the various drawings, the same reference numerals and symbols denote the same elements.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference symbols as possible even if they are shown in different drawings. In the following description of the embodiments of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the difference that the embodiments of the present invention are not conclusive. In this specification, when it is mentioned that a certain element includes an element, it means that it may further include other elements.

FIG. 1 shows a virtual number generation system 100 using an orthopyxis according to an embodiment of the present invention. The system 100 includes a client terminal 10, a client PC 20, an online merchant server 30, a card settlement agency (VAN company) server 40, an authentication server 50, a card issuer server 60, A bank server 70 and the components 10, 20, 30, 40, 50, 60 and 70 are capable of communicating over a wired or wireless network. Although the components 40, 50, 60, and 70 are shown separately in the figure, some or all of them may be combined.

The client PC 20 may be a variety of digital computers such as a laptop, a desktop, a workstation, or other suitable computers capable of performing a payment or authentication process using the virtual number proposed in the present invention, an IPTV And digital devices capable of communicating.

The client terminal 10 is a communication device capable of driving a client application (hereinafter referred to as a "client application") proposed by the present invention and connectable to the authentication server 50 or the client PC 20, Refers to a mobile computing device equipped with hardware and software capable of running on a computer. The user's client terminal 10 can be any type of mobile device, such as a personal digital assistant (PDA), a cellular phone, a smart phone, and the like. In the description of the present invention, the client terminal 10 will be described with reference to a smart phone having a performance comparable to that of a computer and mobility, but is not limited thereto.

For reference, an application is a kind of software operating on an operating system (OS), and is a program designed to directly perform a specific function with respect to a user or another application program. A security application used in a user portable terminal such as a smart phone according to an embodiment of the present invention may be a mobile application that is adapted to be applied to a mobile device. The mobile application may be a browser-based application that accesses the web, A native application manufactured in accordance with the present invention, or a hybrid application combining the applications. Application data, system data, and the like are recorded and stored in a predetermined programming language (for example, C language or Java (JAVA)) on a computer-readable recording medium. The application data is data having various program functions (for example, screen switching by recognizing a user's touch through a display screen) implemented so as to enable interaction with a user, and is also referred to as full mode data. System data refers to data including application management information, start-up information, and the like, and attribute and operation information for reproducing application data. And information for implementing other additional functions can be stored in the recording medium.

The client terminal 10 according to the present invention includes hardware and software capable of operating various applications on a terminal. In particular, the present invention provides an application capable of performing authentication using a security application (i.e., a client application) And a processor for operating a security OS (operating system) for operating the security OS.

The client terminal 10 of the present invention performs a financial transaction using a security OS independently operated, unlike a general OS used for executing a general application of the client terminal 10 during a financial transaction. The environment in which the security OS and the security application operate in the client terminal 10 is referred to as a trust zone. The present invention relates to a trust zone-based financial transaction. The operation of the trust zone based will be described in more detail with reference to FIGS. 2 and 3. FIG.

The client terminal 10 of the present invention can store the card information in the trust zone, which is a security area, and generate a virtual number by encrypting the card number if necessary, and transmit / receive the virtual number to the outside. That is, since the actual card number itself is not transmitted or received, it is possible to prevent the leakage of important personal information such as the card number. In one embodiment, the card information may be stored in a security zone such as a trust zone (TZ) or a USIM, or the card information may be stored in a general area in an encrypted form. A general area is an area that is operated and managed by a general operating system and has no restriction on access.

In addition, the inventive entity can be created on the client application using a secure OS that runs independently on the client terminal 10. Specifically, the OTTP generation method of the present invention is based on a time-based OTP generation algorithm based on time and an OTP key (for example, an OTP generation algorithm according to the RFC 6238 standard), an internal counter value and time, and an OTP key Challenge-Response OTP generation algorithm based on one event-based OTP generation algorithm (OTP generation algorithm according to RFC 4226 and RFC 6238 standard) or random value between time and client / server and OTP key ( An OTP generation algorithm according to the RFC 6287 standard) can be used.

According to an embodiment of the present invention, the client PC 20 and the client terminal 10 can be utilized in, for example, general financial transactions such as banking, and commerce using merchant sites or online shopping malls. The client PC 20 and the client terminal 10 can access the authentication server 50 or the online merchant server 30 through the network and proceed with the payment or authentication process according to the guidance. In one embodiment, the client PC 20 accesses the online merchant server 30 and proceeds with the payment process. When the client terminal 10 executes the client application and generates a virtual number in cooperation with the authentication server 50 . At this time, the network that facilitates connection between the components may be implemented in any form or medium of digital data communication (e.g., a communication network), examples of which include a local area network (LAN), a wide area network And can be used in various mobile networks including various forms of wireless communication such as 3G, WiFi, and LTE.

The online merchant server 30 is also referred to as a PG (Payment Gateway) server. The online merchant server 30 is a server that supports the settlement or authentication process on behalf of the Internet settlement service when performing electronic commerce using the client PC 20 or the client terminal 10, You can guide the payment or progress process through the web page or app provided by the online merchant.

The card payment agency (VAN company) server 40 is a server for payment of card payment by a plurality of card companies. The server 40 interworks with the online merchant server 30 and the authentication server 50 to send information necessary for settlement or authentication to the card company 60 .

The authentication server 50 operates the client application on the client terminal 10 and provides and manages the information (orthape) necessary for generating the virtual number through the client application. In an embodiment, the virtual number can be decrypted using the authentication issued by the authentication server 50. In another embodiment, the authentication is transmitted to the card company 60 or the card settlement agency 40 to decrypt You can support to proceed. The authentication server 50 may operate in conjunction with a separate authentication server or may perform authentication and management including an authentication server.

The card issuer server 60 and the issuing bank server 70 can process payment or authentication using the information transmitted from the card settlement agency server 40. [ In another embodiment, the card issuer server 60 receives a virtual number, receives an opportunistic, decrypts the virtual number, and proceeds with settlement. Herein, the card issuer server 60 refers to a server of a card issuer that issues a payment card and processes settlement with the card, and the issuance bank server 70 refers to a bank server that issued the apex used in the present invention. The card issuer server 60 can receive a payment processing request and a response to the payment transaction of the payment card in cooperation with the issuing bank server 70. [ For example, in the case of payment using a check card, the issuance processing is performed in real time in cooperation with the issuing bank server 70. In the case of a credit card, the issuer server 70 And can perform the withdrawal processing for one or more payment terms in interlocking manner.

The present invention utilizes these components (10, 20, 30, 40, 50, 60, 70) to generate a virtual number using an OTF through a client app running on the client terminal 10 And proceeds with the settlement and authentication process using the virtual number.

2 shows an operating system of the client terminal 10 used for generating an opportunistic packet according to an embodiment of the present invention. The client terminal 10 of the present invention includes a normal environment 110 for driving the general OS 114 and the general application 112 and a secure environment 130 ). The Trust OS 134 and the Trusted App 132 operate independently of the normal OS 114 and the general application 112 in the Trust Zone 130 which is a security environment, May share some or all of the user interface 120, as shown. The client terminal 10 also includes a terminal processor 150 (e.g., an ARM processor) based on trust zone technology capable of selectively operating the trust zone 130 and the general environment 110.

The trust zone 130 includes a secure OS 134 supporting a secure environment and a secure application 132 operated by a secure OS. The trust zone 130 is a hardware-based security execution environment (TEE) that logically separates a mobile CPU (AP) of a client terminal such as a smart device into a general area and a security area and then implements access to the security area, Technology. The security zone is logically separated from the general environment 110. The security zone is implemented such that it can not access each other except for the interface 120 and the shared memory defined for the predefined communication, And other access is blocked. In addition, the trust zone 130 restricts installation and use of applications only by a service provider authorized by the Trusted Service Manager (TSM), and operates in a completely separated manner in a separate area, . In this way, secure storage is possible even when storing the E2E key, private key, etc. through the implementation of the completely separated security zone. In one embodiment, data stored using the secure application 132 in the trust zone 130 may be stored in the general environment 110 as an encrypted form, but it is not decryptable in a normal environment, It is implemented so that decoding is not possible in the application. As another embodiment, even if an application of the same kind as that of the security application 132 is used, it can not be decrypted by another device.

As such, the trust zone 130 is logically completely separated and driven independently, so that it is possible to safely store and process information related to financial transactions using the user client terminal 10 and financial information related to commercial transactions. The trust zone-based security application 132 implements security authentication and secure login, generates the authentication and virtual numbers proposed in the present invention, and further encrypts and stores information requiring security such as a public certificate.

In particular, the trust zone-based security application 132 implements a secure UI (Trust UI) to implement security authentication and secure login, thereby realizing safe authentication in the security domain, And can securely process information requiring security such as an official certificate. Furthermore, by implementing a new technology that combines a security UI with the E2E encryption method described later in the security domain, it becomes possible to implement a non-hackable transaction-oriented authentication. The security UI will be described in more detail with reference to FIG.

The client application of the present invention, that is, the security application 132, automatically recognizes the stored card number from the financial transaction or general commercial transaction trust zone, receives an authentication ticket from the authentication server 50 or generates it, The security and the data stability are improved, and the authentication of the present invention can be utilized as an authentication means in IoT (Internet of things). Since the transaction-related authentication proposed in the present invention is generated substantially without a physical medium, there is an advantage that a user can be easily issued online without visiting a bank or the like (for example, an online bank And can be implemented so as to be issued.

3 (a) shows a general operation in the client terminal 10 according to an embodiment of the present invention, and FIG. 3 (b) shows an operation in the trust zone 130 according to another embodiment of the present invention (C) shows an implementation example of the security UI.

2, the general environment 110 and the trust zone 130 are logically separated, and when the general application 112 is executed, the general OS 114 supports the operation, and the display unit 170 displays, (UI) 116 (FIG. 3 (a)).

On the other hand, at the time of execution of the security application 132, the security OS 134 supports the operation thereof and displays a security UI 136 ('TUI') through the display unit 170 (Fig. 3 (b)). As shown in FIG. 3 (c), since the security UI 136 is displayed with higher priority than the general UI, the security UI 136 can not be accessed in the normal environment 110, It is possible to secure the safety of financial transaction or commerce executed through the trust zone 130. [

Particularly, when the security UI 136 is activated, all input / output information can not be captured outside. When the security screen is activated, the security zone uses the CPU exclusively. Therefore, all operations and operations of the general area are suspended, and the application of the trust zone based on the separate OS (ie, security OS) It blocks access itself. At this time, it is possible to prevent hardware data transmission such as capturing and recording by implementing not to execute even hardware operation keys such as home button and back button except input keypad. In order to return to the normal environment, It can be implemented only through the SW Back button. For example, if a smartphone with a trust zone is connected to a PC and the PC screen is displayed through a projector, if the smartphone is running TZ OTP, the screen changes on the smartphone from the moment when the security UI screen is executed, The output port is blocked and nothing is displayed on the PC and projector screen.

When the security UI is executed, all rights of the screen input / output can be acquired by the security area, and data input / output can be blocked. Capture or recording of the output screen is also impossible. For example, there is no way to block the screen capture by a hardware capture method (for example, a method of capturing a screen by pressing the home key and the power key at the same time) even if a security screen is implemented through an existing software security method. However, when the security UI 136 implemented in the present invention is operated, it is prevented from capturing or recording by a screen capture action, thereby completing the weakness of the existing security method. In addition, all coordinate values input on the screen can not be deodorized from the outside, and data forgery can be prevented. When the security UI according to the present invention is driven, additional security devices such as a virtual keyboard are unnecessary. Therefore, it is possible to prevent forgery and falsification without a separate security solution, and also to provide a keyboard and coordinate value security.

The security UI 136 is used in the OTP PIN number input screen and the OTP generation result screen, and it is possible to safely protect the OTP generation value after the PIN number authentication from the risk of hacking through the security UI screen.

4 is a flowchart showing a virtual number generation method using an OTFT on the client terminal 10 according to an embodiment of the present invention. The virtual number generation method of FIG. 4 shows a process of driving a client application on the client terminal 10. [

Before driving the virtual number generation method of the present invention, the client terminal 10 may download and install the client application through an application store (for example, an application store). As described above, the client app is installed to operate within the trust zone. When the client application is installed, the user can enter the card information to be used for the TZ OTP-based payment in advance, and then register the card after validation by following the agreement procedure for the OTF-based service (TZ OTP service) using the trust zone have. The card information may include an actual card number, an expiration date, a name, a password, and a CVC number. The card information may be validated using part or all of the card information, and personal information such as card information and mobile phone number Can be stored in the security area. At this time, a card nickname can be set so that it is easily distinguished when there are a plurality of card information, and only a part or a nickname of the card number can be displayed and displayed so as not to be exposed to the outside when displaying the card information. In another embodiment, card information and personal information such as cellular phone number may be stored in the general area in the form of encrypted data. The encrypted private information may be used or transmitted only through decryption, if necessary, or may be transmitted as encrypted data.

When the client PC 20 proceeds the settlement through the connection with the online merchant server 30, the client PC automatically pushes the client app 10 to the client terminal 10 through the authentication server 50 according to the payment request, The user can manually run the client app (step 410). In the present specification, an embodiment in which the client PC 20 proceeds with the online settlement and the client terminal 10 operates the client app to generate the virtual number will be described. However, in the case of the mobile settlement, The payment with the merchant server 30 is performed, the client application is executed, and the billing process is performed after the virtual number is generated. That is, the progress of the payment process is not limited to the client PC 20, and online / mobile settlement can be performed on the web or the app through the client terminal 10. [

The client application is a kind of security application, and may request input of a password at operation (step 420). It is possible to confirm the identity of the user through the input of the password and to automatically generate the atype when the password is input (operation 430). The authenticity of the present invention can be directly generated using a client application, and can be issued in real time when a password is input through an authentication server 50 interlocked with an opportunistic server.

At step 440, the client app can recognize the card number that is stored in advance in the security area (TZ or USIM) or that has been stored in the encrypted form in the general area at the same time as or after the occurrence of the atopy. When there are a plurality of cards, one card can be selected and recognized by the user's choice. At this time, only the part of the number or the nickname is displayed on the card number.

When the card number is recognized, the client app generates a virtual number by encrypting the card number using a predefined encryption method (operation 450). For example, the present invention can generate a virtual number by applying a Format Preserving Encryption (FPE) scheme. FPE is a pure encryption technique using a symmetric key encryption algorithm instead of substituting or transforming it with any value having the same property in order to maintain the property of the existing data. This is a known encryption technique by a person skilled in the art, Are omitted from the specification. The client application generates a virtual number (e.g., a one-time card number (OTC)) using an OTF via the FPE method. In this specification, the case where encryption is performed using FPE has been mainly described, but the encryption method is not limited thereto and other encryption methods can be applied to the present invention.

In the case of conducting online settlement through the client PC 20 or the client terminal 10, the generated virtual number OTC is transmitted to proceed with settlement (step 470). In an embodiment, the authentication server 30 or the card issuing server 60 may transmit the decryption key to the authentication server 30 through the client application, and decrypt and settle the decryption key. The virtual number generated in the client terminal 10 may be input (directly input or transmitted) to the client PC 20 and the virtual number generated in the client PC 20 may be transmitted to the client PC 20 via the client PC 20 To the merchant server 30. When the mobile terminal 10 proceeds with the mobile payment, the virtual number is input to the web page or the application, and the virtual number is inputted to the online merchant server 30.

At the time of online payment, the mobile phone number can be further inputted and transmitted for checking the ID value of the user, and the mobile phone number can be transmitted together with the virtual number transmission.

At the time of offline payment, the virtual number can be converted into a payment code (step 480). That is, a series of numbers, bar codes or QR codes can be converted and generated so as to be recognized by the payment terminal of the offline store, and the payment terminal can recognize the payment code through local communication such as NFC and proceed payment. In another embodiment, the payment code may be generated based on a virtual number and a mobile phone number, and may be implemented so that a virtual number and a mobile phone number are transmitted together when a payment is requested.

The virtual number and the mobile phone number can be decrypted using the authentication key in the authentication server 50 or the card issuer server 60 to extract the actual card number and the mobile phone number. As described above, during the data transmission / reception, the virtual merchant server 30 or the card settlement agency server 40 can not decode the virtual number, thereby improving the data stability and security, and can improve the utilization of the one- Can be increased.

FIG. 5 illustrates a virtual number generation method using an OTFT according to an embodiment of the present invention. The virtual number generation method of the present invention can be implemented by transmitting and receiving data between the client terminal 10, the client PC 20, the online merchant server 30, the card settlement agency server 40 and the authentication server 50, The settlement agency server 40 interlocks with the card issuer server 60 and processes the settlement.

In the present embodiment, a case where the client PC 20 connects to the online merchant server 30 to proceed with settlement will be described. However, the present invention is not limited to this embodiment. In the case of proceeding with mobile settlement through the client terminal 10 The client terminal 10 can connect with the online merchant server 30 and proceed with settlement.

The present embodiment describes a case where a virtual number is transmitted through the client terminal 10 and the card issuer server 60 proceeds to decryption.

The client PC 20 connects with the online merchant server 30 and proceeds to the online payment process according to the guidance of the online merchant server 30 (step 510). As described above, the mobile phone number can be additionally input for confirming the user ID value at the time of online settlement. When the input of the mobile phone number is requested, the mobile phone number is inputted on the client PC 20 and transmitted to the online merchant server 30 (step 520).

The online merchant server 30 receives the mobile phone number, transmits a payment request to the card settlement agency 40, and transmits the received mobile phone number together (step 530). At this time, transaction information such as payment details other than the mobile phone number can be transmitted together. The card settlement agency 40 may transmit the transaction information including the mobile phone number and the payment details while transmitting a payment request to the authentication server 50 (step 540).

The authentication server 50 causes the client terminal 10 to execute the client application in a push manner using the mobile phone number included in the payment request (step 550). At this time, if the client app is not installed, you can send a link to the client app install page. When the client application is installed in advance, the client information (for example, a password for executing the client application) can be stored in advance in the authentication server 50 when the client application is installed before proceeding with the payment.

When the client app is pushed by the push on the client terminal 10, the client app can determine whether to execute the client app according to the input of the password (step 560). The client application can be executed when the password input value coincides with the registered password, and at the same time, an authentication can be generated in cooperation with the authentication server. For example, the authentication may be implemented in real time from the authentication server 50 or generated through the client app itself.

In addition, the client application can automatically recognize the card number previously stored in the security zone (TZ) or the USIM (step 562). At this time, not all of the card number is displayed, but only some number or nickname of the card number is outputted. If there are several card numbers, one card number can be selected by the user's choice. For one recognized card or one selected card number, the client app creates an OTC (virtual number) using the atype (step 564). The client app can generate a virtual number using a predetermined encryption method. The present invention generates a virtual number using an encryption key value of an oppy using the FPE method.

The client terminal 10 may automatically or manually transmit the generated virtual number (OTC) value to the authentication server 50 (step 570). Thereafter, the authentication server 50 transmits the received virtual number to the card settlement agency server 40 (step 575), and the card settlement agency server 40 transmits the received virtual number to the card issuer server 60, (Step 577).

After receiving the settlement request from the card settlement agency 40, the card issuer server 60 inquires of the nottip server for the nottip number, inquires and receives the nottifunit number (for example, (Step 580, step 582). In step 580, the virtual key number (OTC) is decoded using the received key value as a decryption key. In step 584, the card company server processes the payment by interworking with the issuing bank server 70 having the payment account of the card using the extracted card number. For example, in the case of payment using a check card, the issuance processing is performed in real time in cooperation with the issuing bank server 70. In the case of a credit card, the issuer server 70 And can perform the withdrawal processing for one or more payment terms in interlocking manner.

The card issuer server 60 receives a response to the withdrawal processing from the issuing bank or performs a self approval process and transmits a settlement response to the card settlement agency 40 in step 590. The card settlement agency server 40 The payment response is delivered to the online merchant (step 592). The online merchant server 30 can forward the order completion message to the client PC 20 (Step 594). For example, the payment web page operated by the online merchant server 30 may be transferred to the order completion page to deliver the order completion message.

In this case, since the card number is not exposed at all during the interim settlement process other than the client 20 and the card issuer server 60 that make the settlement in the E2E (End to End) manner, Thereby realizing data transmission and enhancing security and data security.

Meanwhile, although the embodiment of FIG. 5 has been described with respect to the embodiment in which the card issuer server 60 performs decoding, in another embodiment, the authentication server 50 may perform a decoding process. For example, if the client PC 10 and the online merchant server 30 proceed to settle payment and the card settlement agency server 40 sends a payment request to the authentication server 50, The process of generating the virtual number and transmitting it to the authentication server 50 is the same as the above-described embodiment.

Thereafter, after receiving the virtual number, the authentication server 50 may inquire of the atype and may receive the issued or generated api to the corresponding client terminal 10 in cooperation with the api server (not shown) . The authentication server 50 decrypts the virtual number using the authentication key as the decryption key value, and extracts the actual card number.

The authentication server 50 transmits the extracted card number to the card settlement agency server 40 and the card settlement agency server 40 transmits a settlement request to the card issuer server 60. [ At this time, the card settlement agency server 40 can transmit the actual card number and transaction details received from the authentication server 50 to the card issuer server 60 together.

The card company server 60 having received the payment request may include a payment processing server and a payment history management server. The payment processing server transmits a payment request including the card number and payment details to the issuing bank server 70, And receives a response to the settlement processing from the issuing bank server 70. The card issuer server 60 can receive the settlement response, store it in the settlement history management server, and transmit the settlement response to the card settlement agency server 40. [ The card settlement agency server 40 delivers the payment response to the online merchant server 30 and the online merchant server 30 can deliver the order completion message to the client PC 20. [

As described above, according to the virtual number generation method using the orthophile of the present invention, the issue of personal information leaked recently can be solved, and a virtual number can be generated by utilizing the one-time password as the decryption key value, To enable safe transactions on the Internet.

6 illustrates a virtual number generation method using an OTFT according to another embodiment of the present invention. The present embodiment describes a case where the virtual number is transmitted to the online merchant server 30 through the client terminal 10 and the decryption is proceeded by the card issuer server 60. [

In this embodiment, a case where the client terminal 10 accesses the online merchant server 30 and proceeds with settlement during the mobile settlement using the client terminal 10 will be described. However, the present invention is not limited thereto, 20, the client PC 20 can access the online merchant server 30 and proceed with settlement as in the embodiment described with reference to FIG.

The client terminal 10 can proceed with the payment by connecting with the online merchant server 30 (step 610). At the same time or at the same time, the user can start the client application of the client terminal 10 (step 630). For example, it is possible to guide the client application of the client terminal 10 manually through the guidance on the payment page provided by the online merchant server 30, or to push the client appa- ratus 10 by pushing on the client terminal 10 in cooperation with the online merchant server 10 You can implement client apps to run automatically.

When the client application is activated on the client terminal 10, the client application can determine whether to execute the client application according to the input of the password (operation 630). The client application can be executed when the password input value coincides with the registered password, and at the same time, an authentication can be generated in cooperation with the authentication server. For example, the authentication may be implemented in real time from the authentication server 50 or generated through the client app itself.

Also, the client application can automatically recognize the card number previously stored in the security zone (TZ) or the USIM (step 632). At this time, not all of the card number is displayed, but only some number or nickname of the card number is outputted. If there are several card numbers, one card number can be selected by the user's choice. For one recognized card or one selected card number, the client app generates an OTC (virtual number) using an OTF (step 634). The client app can generate a virtual number using a predetermined encryption method. The present invention generates a virtual number using an encryption key value of an oppy using the FPE method. Here, the client app can generate the virtual number by encrypting the card number stored in the USIM or TZ by means of OTF without communication with the authentication server, and can generate the virtual number through communication with the authentication server.

The client terminal 10 can automatically or manually input the generated virtual number (OTC) value to the payment page provided by the online merchant server 30, and can additionally input a telephone number for ID confirmation at the time of settlement. The client terminal 10 transmits the inputted virtual number and telephone number to the online merchant server 30 (operation 650). The online merchant server 30 transmits a payment request including a telephone number, a virtual number, and transaction details to the card settlement agency server 40 to request payment (step 660).

The card settlement agency server 40 may transmit a settlement request including the telephone number, the virtual number, and the transaction details to the card issuer server 60 (step 670). After receiving the settlement request, the card issuer server 60 requests and inquires of the nottip number to the nottip server (not shown) to inquire and receive the nottifnum number (for example, An actual card number can be extracted by decoding a virtual number using a correct key value as a decryption key (steps 680 and 682).

In one embodiment, the card issuer server 60 may store a matching table of a virtual number and an actual card number. The card issuer server 60 does not necessarily use a matching table at the time of payment approval, but can generate and store a matching table of a virtual number and an actual card number for quick and easy processing at a later cancellation processing and the like.

The card issuer server 60 extracts the actual card number through decryption, processes the payment account of the corresponding card in cooperation with the issuing bank server 70, and transmits the settlement response through the card settlement agency server 40 684). For example, in the case of payment using a check card, the issuance processing is performed in real time in cooperation with the issuing bank server 70. In the case of a credit card, the issuer server 70 And can perform the withdrawal processing for one or more payment terms in interlocking manner. The card issuer server 60 can receive the settlement response from the issuing bank server 70 or process the settlement approval process and store it in the settlement history management server and transmit the settlement response to the card settlement agency server 40 (step 692) .

The card settlement agency server 40 delivers the payment response to the online merchant server 30 and the online merchant server 30 can deliver the order completion message to the client PC 20 in steps 692 and 694. [ For example, the payment web page operated by the online merchant server 30 may be transferred to the order completion page to deliver the order completion message.

In this way, when the decryption is performed by the card issuer server 60, there is no fear that the actual card number is exposed at all during the intermediate settlement through the encrypted transmission of the E2E scheme, thereby improving security and data security.

Meanwhile, although the embodiment of FIG. 6 has been described with respect to the embodiment in which the card issuer server 60 performs decoding, in another embodiment, the authentication server 50 may perform a decoding process. For example, the client PC 10 and the online merchant server 30 proceed to settlement, the client terminal 10 generates a virtual number through the client app, inputs the virtual number to the client PC 10, ) To the card settlement agency server 40 via the network 40 is the same as the above-described embodiment. Then, the authentication server 50 transmits a telephone number and a virtual number to request authentication. After receiving the authentication request, the authentication server 50 can inquire the authentication and can receive the issued or generated authentication to the corresponding client terminal 10 in cooperation with an authentication server (not shown). The authentication server 50 decrypts the virtual number using the authentication key as the decryption key value, and extracts the actual card number.

The authentication server 50 transmits the extracted card number to the card settlement agency server 40 and the card settlement agency server 40 transmits a settlement request to the card issuer server 60. [ At this time, the card settlement agency server 40 can transmit the actual card number and transaction details received from the authentication server 50 to the card issuer server 60 together.

The card company server 60 having received the payment request may include a payment processing server and a payment history management server. The payment processing server transmits a payment request including the card number and payment details to the issuing bank server 70, And receives a response to the settlement processing from the issuing bank server 70. The card issuer server 60 can receive the settlement response, store it in the settlement history management server, and transmit the settlement response to the card settlement agency server 40. [ The card settlement agency server 40 delivers the payment response to the online merchant server 30 and the online merchant server 30 can deliver the order completion message to the client PC 20. [

As described above, the present invention extends the utility of the authentication value by encrypting the actual card number using the authentication value, and prevents the personal information such as the actual card number or the mobile phone number from being leaked by utilizing the virtual number when transmitting and receiving data. And protects the information from exposure even if it is leaked.

Hereinafter, the registration, payment and cancellation processes of the virtual number settlement service according to another embodiment of the present invention will be described with reference to FIGS. 7 to 12. FIG.

FIG. 7 is a flowchart illustrating a virtual number-based payment service registration procedure according to an embodiment of the present invention. The service subscription procedure may be implemented between the client terminal 10, the authentication server 50, the card issuer server 60, and a self certification authority (e.g., a communication company) server for authentication.

First, the card issuer server 60 extracts user information and registration information, extracts users who agree with the marketing message, and generates and sends a subscription message for each card (steps 710 and 715). At least one card company may send an SMS message using the registered user information, and the SMS message is not limited to SMS but may be implemented in various message formats such as e-mail and messenger. Here, the SMS message includes encrypted card information and security code. In this embodiment, an embodiment in which only one piece of card information is encrypted and included as the card company transmits a message for each card will be mainly described. However, in another embodiment, all the card information of the user subscribed to the card company may be encrypted and included in the message, or only the representative card information may be extracted and included in the message by extracting the representative card preset by the user. The security code may also be implemented so that it is included in the message but not output to the user.

The client terminal 10 can install the client app and the OTP client according to the link or the guidance included in the SMS message. The client terminal 10 executes a client application (for example, the payment application shown in FIG. 8) for service subscription, and inputs whether or not to agree to the terms and conditions output to the payment application. The client application collects the terminal information including the International Mobile Equipment Identity (IMEI) of the client terminal 10, the ICCID (Integrated Circuit Card Identifier), and the payment authentication server 510) (step 725). Next, in step 730, the client terminal 10 may perform an authentication process of authenticating the authentication of the user through the communication company by inputting information for authentication of the user. When the communication company authentication is completed, the card authentication is performed (steps 735 to 748). When receiving the SMS message, the client application extracts the encrypted security code included in the SMS message, and automatically inputs the 4-digit number of the card number and the card information into the card registration window. The user can directly input only the first two digits of the password. If the SMS message is not received, the client app provides the user with the ability to enter card information directly. When the card information is inputted, a card authentication request is transmitted to the card company server (step 742), and the card company server 60 performs card authentication according to the request, and then transmits the authentication result to the payment authentication server 510 (746, 748 step).

When the card authentication through the card issuer 60 is completed, the payment authentication server 510 requests the card issuer server 60 for the card registration status and receives the card information held by the user (steps 750, 755). In step 760, the payment authentication server 510 outputs at least one card information according to the card registration status inquiry to the client app, and allows the user to select a card that can be registered by the payment authentication server 510 (step 760). The payment authentication server 510 stores the card list selected by the user (Step 765). The client terminal 10 can input and store a signature image required for offline payment, and can set a payment password (steps 770 and 775), and the card registration is completed.

Next, proceed with the OTP issue procedure. When the client terminal 10 requests OTP registration to the payment authentication server 510, the payment authentication server 510 requests the OTP server 520 for the OTP key and the serial, and the OTP server 520 receives the request OTP key is issued and stored (steps 780, 782 and 784). The OTP server 20 transmits the OTP key and the serial to the client terminal 10, and the client terminal 10 completes the OTP issuance procedure by receiving it and storing it in a secure space (e.g., USIM or TZ).

FIG. 8 is a detailed screen shot illustrating a virtual number-based payment service registration procedure according to an embodiment of the present invention illustrated in FIG. First, the card issuer server 60 may extract a user who has agreed to receive the marketing message, and may set up to send a subscription guidance SMS message according to a predetermined criterion for each card (810).

The client terminal 10 receives a message including the encrypted security code and card information from the card issuer server 60 (820). As described above, the message may include a link to and guidance for client application installation. If the user wants to install the app, he can go to the application market (e.g., Google Play, App Store, etc.) (830) and the user can start the installation by clicking the install (835) button.

When the client terminal executes the client application (the payment application of FIG. 8), it displays a service registration message and card registration guide (840). When the user subscribes to the service, he or she accepts the agreement (850), and receives the identification information for the communication company authentication (860). When the authentication through the communication company is completed, the card registration proceeds. When the user receives the message from the card company and proceeds to card registration (870), card information such as the card name, card number, validity period, and CVC is extracted from the message and automatically input. ). ≪ / RTI > If the user does not receive a message from the card company and proceeds to register the card through the client application (880), the user is guided to directly input card information for card registration.

When the card authentication is completed by sending the inputted card information to the card company server 60, the payment authentication server 510 outputs the card list held by the user, and the user can set the card list and the main card to be registered (885 ). Thereafter, six digits of the settlement password (PIN) are set, and a signature necessary for offline settlement is set (890, 892). As described above, the payment service subscription procedure of the present invention performs registration of the carrier, authentication of the card, card authentication and card registration, and outputs the OTP to the user. As described above, when the client terminal 10 completes the card registration, it can send an OTP issuance request to the OTP server 520 via the payment authentication server 510, and can issue and store the OTP key and serial.

As described above, the subscription of the payment service of the present invention induces subscription through a message, and card authentication is performed by automatically inputting the card information included in the message, thereby adding convenience to the existing subscription procedure.

9 is a flowchart illustrating a procedure of using a virtual number based payment service according to an embodiment of the present invention. The client terminal 10 can request payment for a specific article or service through a web page operated by the online merchant 30 or a separate application and the online merchant outputs a settlement window at the time of the payment request (steps 910, 915, ). Although the present embodiment is described mainly for online settlement, the present invention is not limited to this, and payment at an offline merchant can also be implemented. In addition, although the authentication server and the card issuer server are implemented as separate components, the authentication server and the card company may be implemented as a single entity or a single server integrated with each other. In another embodiment, the card issuer server performs all of the functions of the authentication server, and the card issuer server can be implemented to perform the authty authentication and the virtual number issuance function.

The client terminal 10 can select a settlement means (e.g., a credit card), a card type, a installment month, and a settlement type in the output settlement window, and can select a settlement (OTC settlement) using the virtual number of the present invention. When the client terminal 10 selects OTC payment, the client application is automatically or manually operated in step 920.

When the client app is running, the payment card can be selected (step 922). The payment card selects a card selected in accordance with a criterion previously set by the user (for example, a card setting according to amount, category, or main card setting). After confirming the card to be paid out, if the user proceeds to settle the payment, the payment password (PIN) is input (step 924).

When the payment password is input, the client application issues an OTP (step 930), and requests the payment authentication server 510 to generate a virtual number (OTC) (step 932). Here, the OTP may be generated based on terminal information such as IMEI, or may be generated according to another criterion, and the request information including the company code, the OTP value, the PIN value, and the card selection information may be transmitted upon generation of the virtual number . The payment authentication server 510 receives the request, authenticates the PIN (step 934), and transmits a request including the OTP serial, company code, OTP value, and card selection information to the OTP server 520. The OTP server 520 verifies the OTP value (step 936), and issues a virtual number using the OTP (step 938). As described above, the OTP server can generate the virtual number by using the oppy as an encryption key through the FPE method, but is not limited thereto.

In one embodiment, the card issuer server 60 or the authentication server 50 may store a matching table of the virtual number and the actual card number. The card issuer server 60 or the authentication server 50 does not necessarily use the matching table at the time of payment approval but creates a matching table of the virtual number and the actual card number for quick and easy processing in the procedure such as cancellation processing Can be stored.

The OTP server 520 issues a virtual number to the client terminal 10 (step 940), and the client terminal 10 confirms the completion of the authentication of the OTP and confirms the output virtual number. As an embodiment, the barcode and the signature information can be output together with the output of the virtual number for the unification of the forms of both online and offline payment.

The user inputs the virtual number into the payment window automatically or manually (step 950), and the inputted virtual number is transmitted to the online merchant 30 (step 955). The online merchant 30 transmits a payment approval request to the card settlement agency including the received virtual number and order information, and the card payment agency transmits a settlement approval request to the payment authentication server 510 (steps 960 and 965) . The payment authentication server 510 receives the payment approval request, extracts the actual card number matched with the virtual number, and transmits a payment approval request based on the actual card number to the card issuing server 60 (steps 970 and 975). Here, the extraction of the actual card number can extract the actual card number matched to the virtual number by using the OTP value as the decryption key value.

The card issuer server 60 determines whether or not to approve the payment based on the actual card number (step 980), and transmits the approval result to the online merchant to complete the payment (steps 982, 984, 986, and 990). The payment authentication server 510 may output the receipt on the client app according to the approval result (Step 995).

FIG. 10 is a screen shot illustrating an online settlement service procedure among the virtual number based settlement services described with reference to FIG. 9, FIG. 11 is a flowchart illustrating an offline settlement service procedure of a virtual number based settlement service according to an embodiment of the present invention. It is a screenshot that I implemented. The merchant payment window 1300 is displayed at the online merchant terminal connected to the client terminal 10 and the payment window 1300 may include information on order information, delivery information, and payment means selection. In this embodiment, the mobile payment using the client terminal 10 has been described as an example. However, the user can make an online payment using a computing device (e.g., PC) other than the client terminal and output a payment window.

When the user selects virtual number payment (OTC payment) 1305 in the payment window 1300, the client application (the payment application of FIG. 10) is automatically activated on the client terminal 10 (1310). In another embodiment, the user may manually operate the client application, or may be automatically driven using a push message or a short-range wireless communication method, when the online payment is made to another computing device.

When the client application is activated, a card to be paid is printed according to a preset reference (1320), and the user receives a payment password (1330) when the payment is proceeding. When the payment password is input, an OTP is issued, and a request for generating a virtual number is transmitted to the payment authentication server 510. The information transmitted upon request includes the company code, OTP value, PIN value, and card selection information. When the virtual number is issued from the OTP server 520, the virtual number is transmitted to the client terminal 10 and outputted (1340). The client application 1340 includes the authentication completion result of the OTP, and may include the virtual number 1345 and the corresponding barcode, and may output the pre-stored signature information together.

Thereafter, the user automatically or manually enters the virtual number into the merchant payment window (1350), and the online merchant 30 sends a payment approval request. The payment authentication server 520 extracts the actual card number from the virtual number included in the payment approval request, receives the payment approval result from the card company 60, and transmits the purchase information, approval number, And a receipt 1360 including the date and time of purchase.

11, a payment window can be displayed on a payment terminal (for example, a POS terminal or a payment terminal including a barcode reader) provided at an affiliate shop rather than the user side, and payment can be made according to the selection of the payer .

The user may activate the client app 1400, automatically identify the card to be paid 1410, and enter the payment password 1420, either automatically (e.g., near field wireless communication) or manually. OTP is issued when a payment password is input, and requests generation of a virtual number to the payment authentication server 510 as in the case of online payment. The information transmitted upon request includes the company code, OTP value, PIN value, and card selection information. When the virtual number is generated, it is output 1430 to the client app, and the output page 1430 includes the OTP authentication result, the virtual number and the corresponding barcode 1435 and signature information.

The payment terminal (offline payment terminal in FIG. 11) of the merchant can receive the virtual number by recognizing the barcode using the barcode reader, or the purveyor directly inputs the virtual number output to the client terminal 10. [ When the customer performs the signature (1450), the approval request is transmitted from the merchant to the payment authentication server 520 (1460), and the payment authentication server 520 extracts the actual card number and transmits an approval request to the card company 60 do. If the payment approval is made from the card company 60, the approval result may be transmitted to the client terminal 10 and the payment terminal 1470. A receipt may also be printed on the client app (1480).

In the case of on-line and off-line settlement using the virtual number, the virtual number generated by the encryption key is used for settlement. In the process of intermediating the settlement procedure by the authentication company 50, the virtual number is decoded, The credit card company can quickly and easily perform payment approval processing based on the actual card number, and it is possible to use the payment service with enhanced security without changing the existing infrastructure.

12 is a flowchart illustrating a payment cancellation procedure of a virtual number-based payment service according to an embodiment of the present invention. As with the payment authorization procedure, the cancellation request using the virtual number is also possible in the payment cancellation procedure.

When the user requests the merchant 30 for a payment cancellation request for online, mobile or offline payment 1010, the merchant 30 transmits a settlement cancellation request to the authentication company 50 via the card settlement agency. At this time, the payment cancellation request may include transaction number, approval number, and virtual number (OTC) information. The authentication company 50 extracts the actual card number from the received virtual number and transmits a payment cancellation request including the transaction number, the approval number, and the question card number to the card company 60 (1050).

The card company processes the payment cancellation 1060, and transmits the payment cancellation result to the authentication company 50 (1070). The authentication company 50 can deliver the settlement cancellation result to the card settlement agency 40 and the merchant 30 and output the settlement cancellation result to the merchant 1080, 1090, 1100. On the user side, the payment cancellation result can be confirmed through various routes such as an SMS message from a credit card company or a client application (1200).

As described above, the payment and cancellation process proposed by the present invention is performed by using the virtual number, and there is no risk that the actual card information is exposed in the middle, and the problem of data deception and forgery can be solved.

While the present invention has been described in detail in the foregoing for the purpose of illustration, it is to be understood that the components, their connections and relationships, and their functions are merely exemplary. In the present invention, each component may be implemented as a physically separated form or as an integrated form of one or more components as needed.

The present invention is not necessarily limited to these embodiments, as all the constituent elements constituting the embodiment of the present invention are described as being combined or operated in one operation. That is, within the scope of the present invention, all of the components may be selectively coupled to one or more of them.

Furthermore, the terms "comprises", "comprising", or "having" described above mean that a component can be implanted unless otherwise specifically stated, But should be construed as including other elements. All terms, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Commonly used terms, such as predefined terms, should be interpreted to be consistent with the contextual meanings of the related art, and are not to be construed as ideal or overly formal, unless expressly defined to the contrary.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

10: Client terminal
20: Client PC
30: Online Merchant Server
40: Card payment agency server
50: Authentication server
60: Card issuer server
70: Issuing bank server

Claims (17)

A virtual number settlement method based on an OTP (One Time Password)
Operating a client app on a client terminal;
Generating an audiope using at least one of a USIM of the client terminal or at least one of card information and terminal information stored in a security zone when the password is input when the client application is operated;
The client terminal transmitting a virtual number generation request to an authentication server;
The authentication server generating a virtual number using an encryption key included in the virtual number creation request;
Transmitting the virtual number generated by the authentication server to the client terminal;
The client terminal receiving the virtual number and transmitting a payment request including the virtual number and payment information;
Transmitting, by the authentication server, the payment request, decrypting the virtual number using the atype and extracting an actual card number; And
And the authentication server processing payment approval based on the actual card number in cooperation with a card issuer server,
When the security UI is activated, the security operating system of the client terminal exclusively uses the CPU, so that all operations and operations of the general area are suspended , And external input / output of information input / output through the security UI is impossible. The method according to claim 1,
Wherein the virtual number is encrypted by a predefined encryption method. The method according to claim 1,
Wherein the step of extracting the actual card number decrypts and extracts the virtual number with the authentication key as the decryption key value in the authentication server. The method according to claim 1,
Wherein the step of processing the payment approval includes the step of: the card company server receives the actual card number from the authentication server, processes the payment approval using the actual card number, and transmits the payment approval result to the authentication server Number payment method. The method according to claim 1,
Further comprising the step of subscribing to the payment service before driving the client app,
The step of subscribing to the payment service may include receiving a subscription announcement message from the card company server, installing the client app, performing authentication in cooperation with a communication company, performing card authentication, And issuing an authentication ticket. 6. The method of claim 5,
In the step of receiving the subscription information message from the card company server, the subscription information message includes encryption information,
Wherein the step of performing the card authentication includes extracting the encryption information and automatically inputting the card information. 6. The method of claim 5,
Wherein the authentication server includes a payment authentication server and an authentication server,
Wherein the atopy server issues an atopy registration request to the atopy server, the atopy server issues and stores the atopy key, and the atopy server sends the at least one authentication key and the serial value And transmits the virtual number payment method. 8. The method of claim 7,
Wherein the authentication key and the serial are stored in a USIM or a Trust Zone. The method according to claim 1,
Wherein the virtual number is a one-time number and can not be reused after an expiration time has elapsed. A computer-readable recording medium storing the client application, which executes the virtual number payment method according to any one of claims 1 to 9 on the client terminal. A merchant server for receiving payment information from a client terminal and requesting settlement;
A card settlement agency server for receiving a settlement request from the merchant server and transmitting the settlement request to an authentication company;
An authentication server including a payment authentication server for supporting the client application on the client terminal to proceed with a payment process and an authentication server for issuing and managing an authentication; And
The client application is activated to generate an atype using at least one of the USIM of the client terminal or at least one of the card information and the terminal information stored in a security zone of the client terminal, A client terminal sending a number generation request,
Wherein the payment authentication server receives the virtual number generation request, authenticates the payment password, and transmits the virtual number generation request to the atopy server,
Wherein the atopy server verifies the atopy included in the virtual number generation request, generates a virtual number having the atype as an encryption key value, and transmits the virtual number to the client terminal,
When the security UI is activated, the security operating system of the client terminal exclusively uses the CPU, so that all operations and operations of the general area are suspended , And external input / output of information input / output through the security UI is impossible. 12. The method of claim 11,
Wherein the virtual number is encrypted by a predefined encryption method. 12. The method of claim 11,
Further comprising a card issuer server for performing authorization processing for card payment,
The authentication server extracts the actual card number by decrypting the virtual number using the oppy as a decryption key value, transmits the actual card number to the credit card company number,
Wherein the card issuer server transmits a payment approval result to the authentication server. 14. The method of claim 13,
Wherein the client terminal receives the subscription announcement message from the card issuer server to install the client app,
The subscription information message including encryption information,
Wherein the client application extracts the encryption information upon card authentication and automatically inputs card information. 12. The method of claim 11,
Wherein the atopy server issues a request for issuing an authentication ticket from the client terminal upon issuance of a service, issues and stores an authentication key, and transmits the authentication key and the serial value to the client terminal. 16. The method of claim 15,
Wherein the authentication key and the serial value are stored in a USIM or a Trust Zone. 12. The method of claim 11,
Wherein the virtual number is a one-time number, and can not be reused after an expiration time has elapsed.

Images