KR20200143195A - A mobile payment method for enhancing security of cloud-based payment system and the device therefor - Google Patents

Abstract

Disclosed is a payment method in which a user device and a payment terminal perform payment using a key. The payment method includes the steps of: executing an application program to receive and obtain a control information including a key, an effective number of times, and a valid use period of the key from a server; and performing a payment process with the payment terminal using the key using the application program. The user device is configured to delete or invalidate the key in the process of terminating the application program. In addition, even before the application program is terminated, the user device deletes the key when the number of times of use of the key has reached the number of valid times of use, or the effective period of use has elapsed since receiving the key, and the key is supposed to be invalidated.

Description

A mobile payment method for enhancing security of cloud-based payment system and the device therefor}

The present invention relates to a payment technology performed by using a mobile application of a user device, and in particular, to a technology that enables fast payment without failure while maintaining security even if the user device does not use a Secure Element (SE).

In particular, the present invention is a technology for performing payment between a user device and a payment terminal using a mobile application of a user device, and provides enhanced security while performing a payment without intervention of another remote server at the time of payment. It relates to a technology that enables reuse of a key used for payment in a device without redistribution of the key.

USIM (Universal Subscriber Identity) that serves as a separate secure memory area, SE (Secure Element), for user devices such as smartphones (hereinafter, simply referred to as'mobile','mobile device', and'mobile terminal') Module) may be installed. SE stores important data such as internal transaction data and key data with physical/logical security functions, and protects such important data from the outside.

When payment is performed between the user device and the payment terminal, the payment information and the value information may be stored in at least two methods of the first method and the second method. In the first method, a Secure Element (SE) installed in the user device is used, and the payment information and value information may be stored in an SE that the user device can access. In the second method, a server is used, and the payment information and value information may be stored in the server. In the second method, the user device does not permanently/semi-permanently store the payment information and/or value information itself, or information related to them, or information derived from them, and only payment is made between the server and the payment terminal. It may only play a role in conveying these information at the time.

The first method may be referred to as an “offline payment method” because payment is completed by short-range wired communication or short-range wireless communication between the user device and the payment terminal without the need for remote network communication between the user device and the server.

The second method includes a process in which the user device and the server perform network communication remotely, and the actual payment process is a method performed between the server and the payment terminal, and the user device simply relays data. Therefore, the second method may also be referred to as an'online payment method', a'cloud-based payment method', or a'cloud mode payment method'.

In the present specification, the payment terminal may be replaced with a name of a payment terminal.

In the first method, that is, in the traditional offline payment method, payment information and a secret key of a symmetric key method are used, and the integrity and legitimacy of the other party is verified through a signature (Sign) generated based on the payment information. In the case of the first method, a payment payment environment requiring a relatively fast payment speed may be satisfied. According to the first method, an offline transaction is performed between the user device and the payment terminal using a permanent key stored in the SE accessed by the user device and the SE (ie, SAM) accessed by the payment terminal.

In the second method, that is, in the online payment method using a server, all transaction information is managed by a card system that is virtually present in a server built in a remote central center connected by communication, and when a user requests use The transaction information is used by remotely communicating with the payment terminal using the wireless communication function of. Since transaction information implemented as a payment method using a server exists inside the central center, there is little exposure to the outside, so it can be managed relatively safely.

As a related prior document, there is a Korean registered patent (registration number '10-1468626') for a smart phone card payment system using key exchange with a VAN company server. The smart phone card payment system, a card reader for encrypting the first secret key using the RSA public key included in the certificate issued by the VAN company server, and encrypting the card information through the encrypted first secret key, and After generating the second secret key and encrypting the second secret key through the RSA public key, the card information encrypted with the encrypted first secret key and the payment information encrypted with the encrypted second secret key are transferred to the VAN company server. Includes a smartphone to transmit. That is, after generating a second secret key in the mobile, it is encrypted, and the payment message information is encrypted with the encrypted second secret key, and the second secret key is a one-time data that is destroyed upon termination of the card payment process and the first secret. A configuration is disclosed in which a key is generated and encrypted, and card information is encrypted using the encrypted first secret key. Here, the first secret key is generated by the card reader using a random number generator.

The technology behind the above-described invention has been presented to aid understanding of the present invention, and includes content that the inventor knows about and content that the inventor has created but has not yet disclosed. Therefore, all of the technologies behind the above-described invention should not be regarded as disclosed at the time of filing a patent for the present invention.

In the above-described first method, that is, the traditional offline transaction method, since payment information and value information are stored in the SE of the user device, security problems may arise when the user device is lost or stolen. In addition, when the user equipment needs to change the communication company or replace the USIM, there is a problem in that the transportation card application including payment information must be reissued because all payment information is stored in the USIM even if there is no service change in the transportation card application.

According to the above-described second method, that is, an online transaction method using a server, since payment information and value information are stored in the server, the payment terminal and the server perform remote communication through the user device. At this time, the user device serves as an intermediary, and transmits and receives data using the communication function of the user device. At this time, communication with the central center is performed 2 to 4 times for payment, and there is a problem that the payment time is also delayed if the communication is delayed even though the payment must be made in real time. Also, there is a problem that normal service may not be possible in the case of a communication shadow area.

In order to solve the problems of the first and second methods described above, the use of a transportation card may be considered in a manner that does not use SE such as USIM and uses an application running on the operating system of the user device. In this case, payment information and value information may be stored in a memory of the user device accessible to the application. Since the memory of the user device is less secure than the SE, it is more vulnerable to attack by a malicious third party. In this case, there is a risk of theft, such as exposure of important data such as eavesdropping and man-in-the-middle attacks, and application duplication and modification due to hacking and jailbreak due to security vulnerabilities of user devices.

That is, according to the payment method according to the above-described technologies, ① decrease of security when using an application of a user device (mobile device), ② restriction of service due to SE dependency when using SE, and ③ In the case of using an online transaction method using a server, there are problems such as the possibility of failure to provide a service.

In the present invention, ① using the transportation card application installed in the user device, ② excluding the use of SE accessible from the user device, ③ improving the security weakness of the transportation card payment method by reducing the use of the server to a minimum. It is intended to provide a transportation card payment method using a user device application method.

In the present specification, during the execution of the session for payment, the server and the payment terminal are each subject to exchange signatures, but the payment method relayed by the user device in the data exchange between the server and the payment terminal is an online payment method or It can be referred to as a cloud-based payment method. In addition, during the execution of the session for payment, a payment method in which the user device and the payment terminal are each subject to exchange signatures may be referred to as an offline payment method. The offline payment method provided according to an aspect of the present invention may be different from the above-described first method, that is, a traditional offline payment method.

According to an aspect of the present invention, a payment method in which a user device and a payment terminal perform payment using a key may be provided. The payment method includes the steps of: receiving, by the user device, a key from a server by executing an application program; And performing, by the user device, a payment process with the payment terminal using the key, wherein the user device may be configured to delete or invalidate the key in the process of terminating the application program.

In this case, the obtaining step includes the step of receiving, by the user device, control information including information on at least one of the validity period and the validity number of the key from the server using the application program. I can. In this case, the user device may be configured to determine whether to proceed with the payment process using the key based on the validity period or the validity number.

In this case, the payment method may further include transmitting, by the user device, the control information to the payment terminal using the application program. In this case, the validity period or the number of validity times is whether the payment terminal or the SAM installed in the payment terminal will proceed with the payment process using the key based on the validity period or the validity number included in the control information. May be provided for use in determining whether or not.

In this case, the payment process may be executed after the key is generated by the payment terminal or a SAM installed in the payment terminal.

In this case, the key may be a payment key derived from the master key by the server using a card number.

Alternatively, the key may be a session key derived from the master key by the server.

In this case, the payment process may be executed multiple times by using the key from the time the application program is executed until the end.

In this case, the obtaining step includes receiving control information including information on at least one of the validity period for the key and the number of validity times for the key from the server using the application program, The user device may be configured to delete or invalidate the key when the validity period for the key elapses or the number of validity times for the key exceeds from execution of the application program until termination. have.

In this case, while the payment process is executed a plurality of times from the time the application program is executed until the end of the application program, the user device may not receive another key from the server again.

According to another aspect of the present invention, a payment method may be provided in which the user device and the payment terminal generate and provide the key to perform payment using the key. The payment method comprises the steps of: receiving, by a server, a request message regarding the generation and provision of the key from the user device (1); And generating, by the server, the key, and transmitting the generated key to the user device 1. At this time, the payment terminal receives the card number specified using the information included in the request message from the user device, or the server is generated based on the card number specified using the information included in the request message It may be arranged to receive a temporary card number from the user device. And the payment terminal, using the card number or the temporary card number to derive the key from the master key stored in the payment terminal, and performed between the payment terminal and the user device using the derived key It may be supposed to run the payment process. In addition, the user device may be configured to execute the payment process performed between the payment terminal and the user device by using the key obtained from the server by the user device by using an application program installed in the user device. have. In addition, the request message may be generated by the application program, and the user device may be configured to delete the key obtained from the server in the process of terminating the application program.

According to another aspect of the present invention, a payment method in which a user device and a payment terminal perform payment using a key may be provided. The payment method may include a payment terminal receiving a card number specified using information included in a request message sent by the user device to the server from the user device, or a card specified using information included in the request message. Receiving a temporary card number generated by the server based on the number from the user device; Deriving, by the payment terminal, a key from a master key stored in the payment terminal using the card number or the temporary card number; And executing, by the payment terminal, a payment process performed between the payment terminal and the user device by using the derived key. At this time, control information including information on the validity number or validity period for use of the key is received from the user device, and when the number of use of the key exceeds the validity number, or the validity period is In the case of elapsed, it may be configured not to execute the payment process using the derived key.

According to the present invention, security weaknesses of a transportation card payment method using a mobile transportation card application without a security medium such as SE can be improved, thereby enhancing the security of a transportation card payment method of a user device application method.

According to the present invention, a technology capable of maintaining security without using SE can be provided, and since SE is not used, it is possible to diversify services by breaking away from SE dependency.

According to the present invention, offline payment between a payment terminal and the user device is possible while maintaining security even in situations where communication between a server and a user device (mobile device) is impossible.

In addition, according to the present invention, the use of the server required to receive the distribution of the key can be reduced to a minimum due to the update cycle of the key (temporary) distributed by the server to the user device. That is, the user device may receive the key in advance before the payment point. Accordingly, since offline payment is possible, a payment payment environment requiring a relatively fast payment speed can be satisfied.

In addition, according to the present invention, the key includes information on the validity period and/or the number of validity, so that payment is not made when the validity period of the key received by the payment terminal expires or exceeds the validity number. Security can be improved, such as preventing theft of the key. In addition, if the payment terminal does not have a master key shared with the server to generate the key, the payment terminal cannot generate the key for payment, so that no transaction is made.

In addition, according to the present invention, any user device capable of RF wireless communication can be used without distinguishing between the characteristics of a communication company and a user device. In addition, it can be used if it is a payment terminal of the existing traditional offline payment method. In addition, you can use the service as it is without manufacturer's restrictions.

In addition, the existing card and USIM methods require issuance of a new card or USIM in order to change or expand the service within the card, and the card manufacturing cost and issuance fee are duplicated each time. In addition, cost is required when physical card damage occurs due to external attack or damage, or if replacement is required due to S/W error or issuance error. However, according to the present invention, there is an advantage that such a cost is not required.

According to an embodiment of the present invention, since the user device does not use a permanent key, there is an advantage that it is free from a security threat in case the permanent key is hacked. In addition, according to an embodiment of the present invention, since the key temporarily used by the user device is not used only once, but can be used as many times as a preset validity number or during the validity period, offline payment may be performed once. There is an advantage in that the user device communicates with the server every time to relieve the burden of having to redistribute a temporary key every time.

1A is a flow chart showing a payment method according to an embodiment of the present invention.
1B is a flowchart showing a payment method according to an embodiment modified from the embodiment shown in FIG. 1A.
2A is a view for explaining a payment method between a user device and a payment terminal according to an embodiment of the present invention.
FIG. 2B is a diagram illustrating a method of obtaining a payment key, which is a type of key for executing offline payment, by a user device and a payment terminal according to an embodiment of the present invention.
3A is a view for explaining a payment method between a user device and a payment terminal according to another embodiment of the present invention.
3B is a diagram for explaining a method of obtaining a temporary card key, which is a type of key for executing offline payment by a user device and a payment terminal according to an embodiment of the present invention.
4A is a view for explaining a payment method between a user device and a payment terminal according to another embodiment of the present invention.
FIG. 4B is a diagram illustrating a method of obtaining a session key, which is a type of key for executing offline payment, by a user device and a payment terminal according to an embodiment of the present invention.
5 shows a payment flow chart according to an embodiment of the present invention.
6 is a diagram for explaining the components of a user device according to an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, the present invention is not limited to the embodiments described in the present specification and may be implemented in various different forms. The terms used in the present specification are intended to aid understanding of the embodiments, and are not intended to limit the scope of the present invention. In addition, the singular forms used below also include plural forms unless the phrases clearly indicate the opposite meaning.

<First Example>

Hereinafter, a payment method according to an embodiment of the present invention will be described with reference to FIG. 1A.

1A is a flow chart showing a payment method according to an embodiment of the present invention.

The user device 1, the server 2, and the payment terminal 3 may participate in the payment method according to an embodiment of the present invention.

The user device 1 and the server 2 can communicate with each other remotely using a wired or wireless network communication technology, for example, 4G, 5G, LTE, and MAN.

The user device 1 and the payment terminal 3 may communicate with each other using a short-range wireless communication technology, such as Bluetooth, NFC, or a short-range wired communication technology, such as USB cable communication.

The user device 1 is a portable terminal implementing the wired/wireless network communication technology and the short-range wireless communication technology, and may be, for example, a smart phone or a tablet. The user device 1 is not limited to a specific type of device.

The payment terminal 3 is a device implementing the short-range wireless communication technology or the short-range wired communication technology, and may be a device having a function of processing payment using a key and signature information, such as a public transportation fee processing terminal, a POS, or the like.

Referring to FIG. 1A, a payment method according to an embodiment of the present invention may include the following steps.

In step S110, the user device 1 may request the server 2 to transmit a key using the application program 101 installed and executed on the user device 1.

In step S130, the server 2 may generate a key in response to a request for transmission of the key.

The key may be derived from a master key stored in the server 2.

In step S160, the server 2 may transmit the generated key to the user device 1.

Steps S110 and S160 may be performed through the above-described wired/wireless network communication technology.

In step S500, the user device 1 may perform a payment process with the payment terminal 3 using the key.

There may be a significant time interval between step S160 and step S500. That is, the key acquired by the user device 1 in step S160 may be obtained in advance for the payment process where it is not known when to be performed.

The payment process may be performed through a process in which the application program 101 and the payment terminal 3 prepare session keys, respectively, and generate and verify signatures using the session key. This payment process may use a signature verification method according to the prior art.

Here, the session key may be the key obtained in step S160 itself, or may be derived from the key.

In step S330, the user device 1 may delete or invalidate the key in the process of terminating the application program 101.

At this time, the termination of the application program 101 may be terminated by a user input by a person using the user device 1, or automatically according to the operating conditions of the operating system (OS) of the user device 1 It may be terminated, or it may be automatically terminated according to an operation setting of the application program 101 itself.

In one embodiment, the termination of the application program 101 may be executed before the payment process is performed. That is, step S330 may be performed prior to step S500.

Step (S110), step (S160), step (S500), and step (S330) may be executed under the involvement of the application program 101.

The above-described key may be any one of a payment key, a temporary card key, and a session key, which will be described through drawings to be described later.

1B is a flowchart showing a payment method according to an embodiment modified from the embodiment shown in FIG. 1A.

Steps (S110), (S130), and (S330) of FIG. 1B are the same as steps (S110), (S130), and (S330) of FIG. 1A.

Compared to FIG. 1A, in FIG. 1B, steps S140 and S200 are added.

Steps S160-1 and S500-1 of FIG. 1B are modified from steps S160 and S500 of FIG. 1A.

Hereinafter, the difference between the method according to FIG. 1A and the method according to FIG. 1B will be mainly described.

In step S140, the server 2 may generate control information. The control information may include the validity period of the key generated in step S130 and/or the validity number of the key.

In the user device (1), the key that has not expired and has not exceeded the number of validity is treated as a key in a valid state, otherwise the key is deleted or treated as a key in an invalid state even if not deleted. Can be.

In step S160-1, the server 2 may provide the key and the control information to the user device 1.

In step S200, the application program 101 may check the control information at any time, and delete or invalidate the key when the validity period for the key has elapsed or the number of validity times of the key has exceeded. .

In step S500-1, the user device 1 may perform a payment process with the payment terminal 3 using the application program 101 and the key in a valid state.

If the key does not exist in the user device 1 or is invalidated even if the key exists, the payment process cannot be performed using the key.

As described above, when the validity period and/or the number of validity times is set for the key, it may be understood that the key is not used permanently but is used temporarily. Therefore, in this specification, the key may be referred to as a temporary key.

The second, third, and fourth embodiments to be described later are various embodiments presented by further concretely specifying the first embodiment. The'key' mentioned in the first embodiment is embodied as a'payment key' in the second embodiment to be described later, and is embodied as a'temporary card key' in the third embodiment to be described later, and a fourth embodiment to be described later. In the'session key' can be specified.

<Second Example>

2A is a view for explaining a payment method between a user device and a payment terminal according to an embodiment of the present invention.

FIG. 2B is a diagram illustrating a method of obtaining a payment key, which is a type of key for executing offline payment by a user device and a payment terminal according to an embodiment of the present invention.

Hereinafter, it will be described with reference to FIGS. 2A and 2B together.

A payment system for performing a payment method between a user device and a payment terminal according to an embodiment of the present invention may include a user device 1, a server 2, and a payment terminal 3.

In this specification, the server 2 may be referred to as a generic concept of a plurality of servers that are physically separated from each other and connected to each other through network communication.

A person who operates the server 2 to provide a payment method between a user device and a payment terminal according to an embodiment of the present invention may operate a payment service platform for providing payment services according to an embodiment of the present invention. . The payment service may be a service completed by participating in all of the server 2, the user device 1, and the payment terminal 3. To this end, a person operating the server 2 or a person related thereto may produce and distribute a server program and/or an application program for a user device and/or a payment terminal program required for the payment service. The programs may be programs running on the main operating system of each device and/or programs running on the SE installed in each device. A user of the payment service may log in to the payment service platform using an application program for a user device running on a main operating system of the user device. The user and the operator of the payment terminal may have subscribed to the payment service in advance. The user may use a user device on which the application program is executed to use the payment service, and an operator of the payment terminal may use a payment terminal on which a payment terminal program compatible with the payment service platform is executed.

The description of the payment service and the payment service platform described above may also be applied to the embodiments described by FIGS. 1A, 1B and 3A, 3B, 4A, and 4B described later.

The user device 1 may receive control information and a payment key required for payment from the server 2. The server 2 may also be referred to as a cloud server. The payment key is a kind of the key according to the present invention.

Hereinafter, the'payment key', the'temporary transaction key', the'temporary card key', and the'session key' referred to in the present specification may all be collectively referred to as keys according to the present invention. In the present specification, the'key' may also be referred to as a'temporary transaction key'.

In a preferred embodiment, the user device 1 may not transmit the control information provided from the server 2 to the payment terminal 3.

However, in another embodiment, the user device 1 may transmit the control information to the payment terminal 3. In this case, the user device 1 may transmit the encrypted control information to the payment terminal 3 after encrypting the control information.

Here, the user device 1 may or may not include SE.

In a preferred embodiment of the present invention, an application program that manages the control information and payment keys in the user device 1 and performs payment processing with the payment terminal 3 is installed in the user device 1, It may be installed outside.

However, in a modified embodiment of the present invention, the application program may be installed inside the SE. A plurality of technical effects may be provided by the present invention disclosed in this specification. Regardless of whether the application program is installed inside or outside the SE, it can be understood that one or more technical effects according to the present invention may be provided by other configuration disclosed in the present invention.

Hereinafter, an embodiment in which payment is made without using SE will be mainly described.

Even if the user equipment 1 includes the SE, the SE is not used in the embodiment of the present invention.

The server 2 may generate the control information and the payment key and transmit the generated control information to the user device 1. The payment key and the control information may be periodically or aperiodically updated. In a preferred embodiment, the control information may be generated at the request of the user device 1. The control information may include valid information such as the validity period and the number of validity of the payment key.

In one embodiment, the control information may include an authentication code. In this case, valid information such as the validity period and the number of validity may be included in the authentication code.

The server 2 may store the master key in advance. The master key may be a secret key. In addition, the master key may be stored in the SAM installed in the payment terminal 3.

In the present specification, the master key and the key are distinct concepts. Therefore, in this specification, the'master key' and the'key (payment key/temporary card key/session key)' are different concepts.

The server 2 may generate the payment key according to a predetermined rule by using the card number specified by the request of the user device 1 and the master key together.

Although the payment key is derived from the master key using the card number in FIG. 2B, in another embodiment of the present invention, it may be derived using information other than the card number.

In this case, the server 2 may further include a secret key used in a payment method according to the prior art. However, the secret key may not be used at all in the offline payment process between the payment terminal 3 and the user device 1 described by the embodiment of the present invention.

A SAM may be installed in the payment terminal 3. Alternatively, the payment terminal 3 can access the SAM. The master key may be stored in the SAM.

In one embodiment, as shown in step S401 of FIG. 2B, the SAM, only when the state of the payment key matches valid information such as the validity period and the number of validity stored in the control information, It is possible to allow the payment key to be used for actual offline transactions. However, the determination of whether to proceed with offline payment in the optimal implementation mode according to the present embodiment may be performed only by the user device 1, and the SAM may not be involved in the determination.

In step S310 of FIG. 2B, the payment terminal 3 may receive a card number from the user device 1. In addition, in step S410 of FIG. 2B, the SAM may derive the payment key from the master key stored in the payment terminal 3 using the card number.

The order of execution of steps S401 and S410 of FIG. 2B may be interchanged.

In the optimal embodiment mode according to the present embodiment, steps S320 and S401 of FIG. 2B may be omitted. In this case, the determination of whether to proceed with the offline payment may be performed only by the user device 1.

In an embodiment of the present invention, the valid information may be transmitted from the user device 1 to the payment terminal 3 in an obfuscated state. The obfuscated and transmitted valid information may be decrypted by the SAM installed in the payment terminal 3. The decrypted valid information may be implemented to be recognized by the SAM. In this way, regardless of the type or state of the payment terminal in which the SAM is installed, the SAM may be able to recognize the decrypted valid information.

However, in a modified embodiment, the decrypted valid information may be recognized by a module existing outside the SAM of the payment terminal 3.

The user device 1 can obtain the payment key from the server 2, and the SAM can obtain the payment key through the same process as in step S410 of FIG. 2B, so that the user device 1 and The SAM can share the payment key.

In step S500 ₂ of FIG. 2B, a payment process between the user device 1 and the payment terminal 3 may be performed in an offline manner. At this time, the payment key shared between the user device 1 and the SAM may be used to perform the payment process.

As described above, the server 2 and the payment terminal 3 (or the SAM) may each store a permanent key used in the prior art. However, according to the present invention, the user device 1 does not use the permanent key used in the prior art, and can use the payment key instead. As described above, the control information includes information on the validity period and/or the number of validity, and the validity of the payment key is dependent on the control information. In consideration of this property of the payment key, in this specification, the payment key may be referred to as a'key' or'imposed' for performing an offline payment process between the user device 1 and the payment terminal 3. .

Hereinafter, it will be described with reference to FIG. 2B.

In step S210, the user device 1 may request the server 2 for control information and a payment key. Specifically, an application program installed in the user device 1 may request control information and a payment key from the server 2. At this time, it must be an environment in which remote network communication between the user device 1 and the server 2 can be performed. At this time, at least one of the device identifier of the user device 1 and the login information of the user who has logged in to the payment service platform through an application program may be transmitted together. The login information may include a user ID of a logged-in user and a card number associated with the user ID. In this case, the user may have registered a plurality of card numbers in the payment service platform in order to use the payment service. In addition, when requesting the control information and the payment key, which card number is for a plurality of card numbers may be specified using a user interface provided by the application program and the payment service platform. The specified card number may be transmitted to the server 2 in step S210.

The card number may be, for example, a card number of a prepaid card.

In step S220, the server 2 may specify a card number for generating control information and a payment key using the device identifier of the user device 1. To this end, the server 2 may be configured to access a storage device including a table indicating a matching relationship between a device identifier and a card number. The table may include the device identifier field and the card number field.

Alternatively, in step S220, the server 2 may specify a card number for generating control information and a payment key using the transmitted user ID. To this end, the server 2 may be configured to access a storage device including a table indicating a matching relationship between a user ID and a card number. The table may include the user ID field and the card number field.

Alternatively, in step S220, the server 2 may specify a card number for generating control information and a payment key by using the transmitted card number as it is.

In step S230, the server 2 may derive a payment key from the master key using the specified card number.

For example, assuming that there is a first payment key derived from the master key using a first card number, and a second payment key derived from the master key using a second card number different from the first card number, , The first payment key and the second payment key may be different from each other.

In step S240, the server 2 may generate control information. The control information may include the validity period and/or the number of validity of the payment key. The validity period and/or the number of validity times may be determined by a predetermined rule.

For example, a grade may be assigned to a prepaid card designated by a specified card number. The grade may be defined in various ways, such as a first grade, a second grade, a general grade, and a youth grade. If the prepaid card designated by the first card number is a first class card, the validity period and/or the number of validity times may have the first validity period and/or the first validity period. And, if the prepaid card designated by the second card number is a second class card, the validity period and/or the number of validity times may have the second validity period and/or the second validity period.

In step S260 ₂ , the server 2 may transmit control information and a payment key to the user device 1.

According to a preferred embodiment, in step S301, the application program may determine whether the validity period included in the control information has passed or whether the validity count has been exhausted. If it is determined that the validity period included in the control information has elapsed or the validity count has been exhausted, the application program may control not to proceed with offline payment using the payment key associated with the control information. In an exemplary embodiment, if it is determined that the validity period included in the control information has passed or that the validity count has been exhausted, step S310 and subsequent steps to be described later may not be executed.

In step S310, the user device 1 may transmit a specific card number to the payment terminal 3. Step S310 may be performed by an application program of the user device 1. The specific card number may be transmitted through short-range wired/wireless communication. The transfer of the specific card number may be performed between the user device 1 and the payment terminal 3 when performing the user operation for performing the above-described offline payment. For example, the transfer of the specific card number may be performed when the user device 1 is brought close to or contacted with the payment terminal 3.

The specific card number transmitted from the user device 1 to the payment terminal 3 may be the same as the card number used in step S230.

In one embodiment, step S310 may not be executed unless the above-described step S301 is satisfied. If the step (S310) is not executed, the subsequent step is also not executed, and eventually payment may not be made.

In step S320, the user device 1 may transmit the control information received from the server 2 to the payment terminal 3.

When step S320 is executed, step S310 and step S320 may be integrated with each other, and thus the control information and the specific card number may be simultaneously transmitted to the payment terminal 3.

In an embodiment, in step S401, the payment terminal 3 may determine whether to allow offline payment using a payment key based on the validity period or the number of validity included in the control information.

In the optimal embodiment mode according to the present embodiment, steps S320 and S401 of FIG. 2B may be omitted. In this case, determining whether to proceed with the offline payment can be performed only by the user device 1.

In step S410, the payment terminal 3 may derive a payment key from the master key using the specific card number received from the user device 1. In this case, the master key stored in the payment terminal 3 may be the same as the master key stored in the server 2. Therefore, the payment key derived from the payment terminal 3 may be the same as the payment key derived from the server 2.

Now, the payment terminal 3 and the user device 1 have each secured a payment key, and these two payment keys are the same. Therefore, the payment terminal 3 and the user device 1 can perform offline payment using the payment key. The procedure for the offline payment may be the same as, for example, a conventional offline payment procedure.

The conventional offline payment procedure may be a procedure performed using, for example, a secret key permanently stored in the SE installed in the user device 1 and a secret key permanently stored in the SAM installed in the payment terminal 3. . The conventional offline payment may be an arbitrary payment method in which the user device 1 and the payment terminal 3 each use the same secret key with each other to make payment through wired or wireless mutual communication.

In step S500 ₂ , offline payment may be performed using the same payment key secured by the payment terminal 3 and the user device 1, respectively.

In step (S500 ₂ ), the user device 1 and the payment terminal 3 derive a session key from the respective payment key, and generate signs using the respective derived session keys, and transmit and verify each other. You can perform offline payments. A method of generating a signature and verifying each other using a session key can be used as it is or by modifying the conventional technology.

For example, the user device 1 may generate a first signature using the session key, and then transmit the first signature to the payment terminal 3. Thereafter, the payment terminal 3 may generate the 1-1 signature using the session key, and then verify whether the first signature and the 1-1 signature date are the same. If the first signature and the 1-1 signature date are verified to be the same, the payment terminal 3 may generate a second signature using the session key, and then transmit the second signature to the user device 1. . Then, the user device 1 may generate a signature 2-1 using the session key, and then verify whether the second signature and the signature 2-1 are the same. Then, if the second signature and the 2-1 signature are verified to be the same, the user device 1 generates a third signature using the session key, and then converts the third signature to the payment terminal 3 Can be sent to Thereafter, the payment terminal 3 may generate the 3-1 signature using the session key, and then verify whether the third signature and the 3-1 signature date are the same. When such a series of signature information verification processes are completed, the transaction process may be terminated.

In an embodiment in which step S320 is executed, the payment terminal 3 may be configured to determine whether to proceed with the payment process based on the validity period or the number of validity included in the control information. For example, if it is determined that the validity period included in the control information has elapsed or it is determined that the validity number included in the control information has been exceeded, the payment terminal 3 will not allow the payment process. I can.

In step S330 ₂ , the user device 1 may delete the payment key when a certain condition is satisfied.

At this time, for example, the condition may be that the application program executed in the user device 1 is terminated. That is, when the procedure for terminating the application program is executed, the payment key may be deleted during the termination procedure.

At this time, during the execution period, which is the period between the execution of the application program and the termination, if the number of validity for the use of the payment key exceeds or it is confirmed that the validity period has expired, the procedure for terminating the application program Even before is executed, the payment key may be deleted.

In Figure 2b, step (S330 ₂ ) is illustrated as being performed after step (S500 ₂ ), but step (S330 ₂ ) is continuously executed on the user device 1 while the application program is being executed. There may be, and step (S500 ₂ ) may be executed only when a specific action of the user of the user device 1 occurs. That is, if the application program is being executed, step S330 ₂ may be continuously executed in the user device 1 at all times. As a result, when any one of the exceeding of the effective number of use of the payment key, the expiration of the valid use period of the payment key, and the termination events of the application program is satisfied, the payment key stored in the user device 1 May be deleted or invalidated.

However, during the execution period of the application program, even if the offline payment is executed using the payment key, the payment key is not deleted only because the offline payment success event, error event, or failure event has occurred. That is, the payment key is not literally a one-time key.

In this way, the payment key can be used up to N times when the above-described conditions are satisfied in the user device 1. Here, N is the number of valid times included in the control information and may be a natural number of 1 or more. In this way, if an event corresponding to the termination of the application program, the achievement of the valid number of times, or the expiration of the validity period does not occur, the server 2 sends the payment key to the user device 1 again. There is no need to distribute.

The above-described steps (S210), step (S260 ₂ ), step (S301), step (S310), step (S320), step (500 ₂ ), and step (S330 ₂ ) are executed in the user device (1). It can be executed by an application program. Step (S210), step (S260 ₂ ), step (S301), step (S310), step (S320), step (500 ₂ ), and step (S330 ₂ ) are from the start point of execution of the application program to the end point of completion It may be previously executed, and may not be executed when the application program is terminated.

<Third Example>

3A is a view for explaining a payment method between a user device and a payment terminal according to another embodiment of the present invention.

The system shown in Fig. 3A has the same basic configuration as the system shown in Fig. 2A. Hereinafter, differences between the embodiment according to FIG. 3A and the embodiment shown in FIG. 2A will be mainly described.

In FIG. 2B, the'payment key' is transmitted from the server to the user device, but in FIG. 3A, the'temporary card key' is transmitted from the server to the user device. The'temporary card key' is a kind of the'key' according to the present invention.

In a preferred embodiment, the user device 1 may not transmit the control information provided from the server 2 to the payment terminal 3.

However, in another embodiment, the control information may be transmitted to the payment terminal 3. In this case, the user device 1 may transmit the encrypted control information to the payment terminal 3 after encrypting the control information.

The server 2 may generate control information, a temporary card key, a temporary card number, and information on a master key and transmit the information to the user device 1. The control information may be periodically or aperiodically updated. In a preferred embodiment, the control information may be generated at the request of the user device 1. The control information may include valid information such as a validity period and validity number related to the use of the temporary card key.

In one embodiment, the control information may include an authentication code. In this case, valid information such as the validity period and the number of validity may be included in the authentication code.

The server 2 may store the master key in advance. The master key may be a secret key. In addition, the master key may be stored in the SAM installed in the payment terminal 3.

The server 2 may generate a temporary card number using the user card number specified by the request of the user device 1. And it is possible to derive the temporary card key from the master key by using the temporary card number.

A SAM may be installed in the payment terminal 3. Alternatively, the payment terminal 3 can access the SAM. The master key may be stored in the SAM.

In one embodiment, the SAM is configured to use the temporary transaction key for an actual offline transaction only when the current state of the temporary card key matches valid information such as the validity period and the number of validity stored in the control information. I can allow it.

The payment terminal 3 may receive the temporary card number from the user device 1. In addition, the SAM may derive the temporary card key from the master key stored in the payment terminal 3 using the temporary card number.

The user device 1 can obtain the temporary card key from the server 2, and the SAM can obtain the temporary card key by the process described above, so that the user device 1 and the SAM are Card keys can be shared.

The payment process between the user device 1 and the payment terminal 3 may be performed in an offline manner. In this case, the user device 1 may use the temporary card key shared between the user device 1 and the SAM, instead of using a permanent key used in the prior art to perform the payment process. That is, in the user device 1, the temporary card key may instead perform the function of a permanent key used in the prior art.

As described above, the server 2 and the payment terminal 3 (or the SAM) may each store a permanent key used in the prior art. However, according to the present invention, the user device 1 does not use the permanent key used in the prior art, and can use the temporary card key instead. As described above, the control information includes information on the validity period and/or the number of validity, and the validity of the temporary card key is dependent on the control information. In consideration of this property of the temporary card key, in this specification, the temporary card key will be referred to as a'key' or'imposed' for performing an offline payment process between the user device 1 and the payment terminal 3 May be.

3B is a diagram for explaining a method of obtaining a temporary card key, which is a type of key for executing offline payment by a user device and a payment terminal according to an embodiment of the present invention.

In step S1210, the user device 1 may request a temporary card number and a temporary card key from the server 2. In this case, the server 2 may be composed of a plurality of servers.

The temporary card number is a user card number that is a card number (for example, a card number of a physical card in the form of a plate) that can be specified based on a message sent by the user device 1 to the server 1 in step S1210. It may be generated by the server 2 based on it.

For example, in the message that the user device 1 sends to the server 1 in step S1210, the device identifier of the user device 1, the identifier of the user logged in through the application program installed in the user device 1, or the Designated card information designated by a user through an application program may be included. The designated card information may be selected by the user among, for example, a first card generated by a first card financial company being used by the user and a second card generated by a second card financial company being used by the user.

In a recording medium accessible to the server 2, the device identifier, the user identifier, or the user card number matched with the card information may be stored in advance. This matching relationship may be generated by information previously registered by the user of the application program of the user device 1. Therefore, the server 2 may specify the user card number by using the device identifier, the user identifier, or the card information obtained in step S1210.

In step S1220, the server 2 may generate a temporary card number using the specified user card number.

In step S1230, the server 2 may derive a temporary card key from the master key stored in the server 2 using the generated temporary card number.

In step S1240, the server 2 may generate control information. The control information may include valid information, which is information about a valid number of times that the temporary card key can be used effectively, or a valid period during which the temporary card key can be effectively used.

In step S1260, the server 2 may transmit the temporary card key, the temporary card number, the control information, and information on the master key used to generate the temporary card key to the user device 1.

According to a preferred embodiment, in step S1301, the application program may determine whether the validity period included in the control information has passed or whether the number of validity times has been exhausted. If it is determined that the validity period included in the control information has expired or the validity number of times has been exhausted, the application program may control not to proceed with offline payment using the temporary card key. In an exemplary embodiment, if it is determined that the validity period included in the control information has passed or that the validity number of times has been exhausted, the step S1310 described below and subsequent steps thereof may not be executed.

In step S1310, the user device 1 may transmit information on the temporary card number and the master key to the payment terminal 3. In this case, the temporary card key itself may not be transmitted to the payment terminal 3.

In step S1320, the user device 1 may transmit the control information to the payment terminal 3.

According to an embodiment, in step S1401, the payment terminal 3 may determine whether to allow offline payment using a temporary card key based on the valid information included in the control information.

In the optimal embodiment mode according to the present embodiment, steps S1320 and S1401 of FIG. 3B may be omitted. In this case, determining whether to proceed with the offline payment between the user device 1 and the payment terminal 3 can be performed only by the user device 1.

In the short term (S1410), the payment terminal 3 may derive a temporary card key from the master key previously stored in the payment terminal 3 using the temporary card number. At this time, the master key stored in advance in the payment terminal 3 is the master key received from the user device 1 through step S1310 among a plurality of master keys previously stored in the payment terminal 3. It may be selected using information about.

In step S1500, the user device 1 and the payment terminal 3 may perform offline payment using the same temporary card key respectively secured.

In step S1500, the user device 1 and the payment terminal 3 derive a session key from the temporary card key each held, and generate signs using the respective derived session keys, and transmit and verify each other. You can perform offline payments. A method of generating a signature and verifying each other using a session key can be used as it is or by modifying the conventional technology.

In step S1330, the user device 1 may delete the temporary card key when a certain condition is satisfied. At this time, for example, the condition may be that the application program executed in the user device 1 is terminated. That is, when the procedure for ending the application program is executed, the temporary card key may be deleted during the ending procedure.

At this time, if it is confirmed that the number of validity times for the use of the temporary card key has been exceeded or the validity period has expired during the execution period, which is the period between the execution of the application program and the termination, the application program is terminated. Even before the procedure is executed, the temporary card key may be deleted.

In FIG. 3B, the step S1330 is illustrated as being performed after the step S1500, but the step S1330 may be continuously continuously executed by the user device 1. That is, if the application program is being executed, step S1330 may be continuously executed on the user device 1 at all times. As a result, when any one of the exceeding the number of valid use times of the temporary card key, the expiration of the valid use period of the temporary card key, and the termination event of the application program is satisfied, the stored in the user device 1 Temporary card keys can be deleted or invalidated.

However, even if the offline payment is executed using the temporary card key during the execution period of the application program, the temporary card key is not deleted only because the offline payment success event, error event, or failure event has occurred. .

The above-described steps (S1210), (S1260), (S1301), (S1310), (1500), and (S1330) may be executed by the application program executed in the user device 1. Step (S1210), step (S1260), step (S1301), step (S1310), step (1500), and step (S1330) may be executed from the start point of execution of the application program before the end point of completion, When the application program is terminated, it may not be executed.

<Fourth Example>

4A is a view for explaining a payment method between a user device and a payment terminal according to another embodiment of the present invention.

FIG. 4B is a diagram illustrating a method for each of a user device and a payment terminal to obtain a session key, which is a key for executing offline payment, according to an embodiment of the present invention.

Hereinafter, it will be described with reference to FIGS. 4A and 4B together.

The embodiment shown in Figs. 4A and 4B is a modification of the embodiment shown in Figs. 2A and 2B. Specifically, in Figs. 2A and 2B, the server 2 generates a payment key required to generate a session key. Then, it is transmitted to the user device 1, and the session key is generated by the user device 1. On the other hand, in FIGS. 4A and 4B, the server 2 generates a session key and transmits it to the user device 1, and the user device 1 only uses the received session key, and the user device 1 directly receives the session key. It is different in that it does not generate.

In common in FIGS. 2B and 4B, signatures required for offline payment between the user device 1 and the payment terminal 3 may be generated from the session key.

In FIGS. 4A and 4B, a session key transmitted from the server 2 to the user device 1 is a kind of the aforementioned key according to the present invention.

The offline payment method according to an embodiment of the present invention described with reference to FIGS. 4A and 4B may have the same configuration as the embodiments described with reference to FIGS. 2A and 2B except for the above description. Hereinafter, it will be described with reference to FIG. 4B.

In FIG. 4B, the session key is derived from the master key using the card number and transaction information, but in another embodiment of the present invention, it may be derived using other information.

In step S2210, the user device 1 may request the server 2 for control information and a session key. At this time, one or more of the login information of the user who has logged in to the payment service platform through the device identifier of the user device 1 and the application program of the user device 1 may be transmitted together. The login information may include a user ID of a logged in user and a card number specified by the user in association with the user ID. The card number may be, for example, a card number of a prepaid card.

In step S2220, the server 2 may specify a card number for generating control information and a session key by using the device identifier of the user device 1. To this end, the server 2 may be configured to access a storage device including a table indicating a matching relationship between a device identifier and a card number. The table may include the device identifier field and the card number field.

Alternatively, in step S2220, the server 2 may specify a card number for generating control information and a session key using the transmitted user ID. To this end, the server 2 may be configured to access a storage device including a table indicating a matching relationship between a user ID and a card number. The table may include the user ID field and the card number field.

Alternatively, in step S2220, the server 2 may specify a card number for generating control information and a session key by using the specified and transmitted card number as it is.

In step S2230, the server 2 may derive a session key from the master key using the card number and/or transaction information. In a modified embodiment, the server 2 may derive a session key from the master key using information other than the card number and/or transaction information.

In step S2240, the server 2 may generate control information. The control information may include the validity period and/or the number of validity of the session key. The validity period and/or the number of validity times may be determined by a predetermined rule.

In step S2260, the server 2 may transmit control information and a session key to the user device 1.

According to a preferred embodiment, in step S2301, the application program of the user device 1 may determine whether the validity period included in the control information has expired or whether the validity count has been exhausted. If it is determined that the validity period included in the control information has expired or the validity number of times has been exhausted, the application program may control not to proceed with offline payment using the session key. In an exemplary embodiment, if it is determined that the validity period included in the control information has passed or that the validity count has been exhausted, the step S2310 described below and subsequent steps thereof may not be executed.

In step S2310, the user device 1 may transmit a specific card number to the payment terminal 3. Step S2310 may be performed by an application program of the user device 1. The specific card number may be transmitted through short-range wired/wireless communication. The transfer of the specific card number may be performed between the user device 1 and the payment terminal 3 when performing the user operation for performing the above-described offline payment. For example, the transfer of the specific card number may be performed when the user device 1 is brought close to or contacted with the payment terminal 3.

The specific card number transmitted from the user device 1 to the payment terminal 3 may be the same as the card number used in step S2230.

In an embodiment, step S2310 may not be executed unless the above-described step S2301 is satisfied. If the step (S310) is not executed, the subsequent step is also not executed, and eventually payment may not be made.

In step S2320, the user device 1 may transmit the control information received from the server 2 to the payment terminal 3.

When step S2320 is executed, step S2310 and step S2320 may be integrated with each other, and thus the control information and the specific card number may be simultaneously transmitted to the payment terminal 3.

In an embodiment, in step S2401, the payment terminal 3 may determine whether to allow offline payment using a session key based on the validity period or the number of validity included in the control information.

In the optimal embodiment mode according to the present embodiment, steps S2320 and S2401 of FIG. 4B may be omitted. In this case, determining whether to proceed with the offline payment can be performed only by the user device 1.

In step S2410, the payment terminal 3 may derive the session key from the master key by using the specific card number received from the user device 1. In this case, the master key stored in the payment terminal 3 may be the same as the master key stored in the server 2. Therefore, the session key derived from the payment terminal 3 may be the same as the session key generated by the server 2 and distributed to the user device 1.

Now, the payment terminal 3 and the user device 1 have each secured a session key, and these session keys are the same. Therefore, the payment terminal 3 and the user device 1 can perform offline payment using the session key. The procedure for the offline payment may be the same as, for example, a conventional offline payment procedure.

In step S2500, offline payment may be performed using the same session key secured by the payment terminal 3 and the user device 1, respectively.

In step S2500, the user device 1 and the payment terminal 3 may perform offline payment by generating signs using each secured session key, transmitting and verifying each other. A method of generating a signature and verifying each other using a session key can be used as it is or by modifying the conventional technology.

In an embodiment in which step S2320 is executed, the payment terminal 3 may be configured to determine whether to proceed with the payment process based on the validity period or the number of validity included in the control information.

In step S2330, the user device 1 may delete the session key when a certain condition is satisfied.

At this time, for example, the condition may be that the application program executed in the user device 1 is terminated. That is, when the procedure for terminating the application program is executed, the session key may be deleted during the termination procedure.

At this time, during the execution period, which is the period between the execution of the application program and the termination, if the number of validity times for the use of the session key exceeds or it is confirmed that the validity period has expired, the procedure for terminating the application program Even before is executed, the session key may be deleted.

In FIG. 4B, step S2330 is illustrated as being performed after step S2500, but step S2330 may be continuously executed in the user device 1 at all times. That is, if the application program is being executed, step S2330 may be continuously executed in the user device 1 at all times. As a result, the session key stored in the user device 1 is satisfied when any one of the exceeding the number of valid use times of the session key, the expiration of the valid use period of the session key, and the termination events of the application program are satisfied. May be deleted or invalidated.

However, even if the offline payment is executed using the session key during the execution period of the application program, the session key is not deleted only because of the occurrence of a success event, an error event, or a failure event of the offline payment. That is, the session key is not literally a one-time key.

In this way, the session key can be used a plurality of times when the above-described condition is satisfied in the user device 1. In this way, if an event corresponding to the termination of the application program, the exceeding the number of valid usage, or the elapse of the valid usage period does not occur, the server 2 sends the session key for payment to the user device 1 again. There is no need to distribute.

5 shows a payment flow chart according to an embodiment of the present invention.

In step S10, the user device may receive and obtain a key generated by using the master key in which ① control information and ② the server are stored in advance, from the server. In this case, the control information may include information on the validity period or the number of validity. At this time, the master key may also be stored in the SAM installed in the payment terminal.

In step S20, the user device may transmit the control information to the payment terminal. In this case, the payment terminal may be configured to determine whether to start the payment process based on the validity period or the number of validity included in the control information.

In step S30, the user device and the payment terminal may perform a payment process using the key.

In the optimal implementation mode according to the present embodiment, the control information may not be transmitted from the user device to the payment terminal. That is, step S20 may be omitted. In this case, the payment terminal may not determine whether to start the payment process, and determining whether to start the payment process may be performed by the user device.

In this case, the SAM of the payment terminal may be configured to generate the key by using the master key stored in the SAM installed in the payment terminal.

The payment process may be performed using a conventional technique. For example, according to the prior art, the payment process may be performed using a key permanently or semi-permanently stored in the SE of the user device and the SAM of the payment terminal according to a predetermined procedure. In contrast, in the payment process provided according to an embodiment of the present invention, according to the predetermined procedure, the key (imkeyed) managed by the application program of the user device and the SAM generated by the payment terminal It can be performed using the key (imkey). That is, according to an embodiment of the present invention, in the related art, the key (temporary key) is used by replacing the key permanently stored in the SE of the user device. In this case, the number of validity of the key (temporary key) Or, since the validity period is set and the generation/management/disposal of the key (temporary) is performed by the server, the payment process according to the prior art is secured even if the user device does not use an SE having a hardware security device. It can be done safely.

That is, according to an embodiment of the present invention, the payment can be completed by using a predetermined procedure according to the conventional technology as it is, but not using a permanently or semi-permanently stored key used in the conventional technology. The difference is that a key (temporary key) that can be discarded is used because the validity period or the number of validity is set. In addition, the present invention proposes a specific method for securing such a key (imposed) between the user device 1 and the payment terminal 3.

The key steps of the payment process according to the prior art described above may be performed between the user device 1 and the SAM. However, the payment terminal 3 may intervene in a wired/wireless communication process and user input for performing the payment process. Therefore, in the embodiments of the present invention introduced in the present specification, it has been comprehensively described that the payment process is performed between the user device 1 and the payment terminal 3. In particular, in the payment process, the subject generating and verifying a signature (signature) may be a user device and a payment terminal.

In the step S10, the control information and the key may be updated periodically or aperiodically in the server 2 to be newly generated. In the case of aperiodic updating, the control information and the key may be newly generated only when, for example, the user device 1 requests the server 2. The server 2 may transmit the newly generated control information and the key to the user device 1 again. Accordingly, the user device 1 can also obtain the newly generated control information and the key.

One or more of the control information and the key may be exchanged between the user device 1, the server 2, and the payment terminal 3, and the exchanged information may be encrypted and decrypted using a conventional technique. . The present invention is not limited by the application of the encryption and decryption and a specific technique for encryption and decryption.

In this case, if the application program is being executed in the user device 1, the determination of a condition for deleting or invalidating the key may be continuously performed. That is, after the user device 1 obtains the key from the server 2, any one of the exceeding of the effective number of times of use of the key, the expiration of the valid use period of the key, and termination events of the application program If satisfied, the key stored in the user device 1 may be deleted or invalidated.

In this case, even if the offline payment is executed using the key during the execution period of the application program, the key is not deleted only because the offline payment success event, error event, or failure event has occurred. That is, the key is not literally a one-time key.

In this way, the key can be used a preset number of times when the above-described conditions are satisfied in the user device 1. In this way, if an event corresponding to the termination of the application program, exceeding the number of valid usages, or the elapse of the valid usage period does not occur, the server 2 distributes the key for payment to the user device 1 again. There is no need to do it.

6 is a diagram for explaining the components of a user device according to an embodiment of the present invention.

The user device 1 may include an SE 10, a network communication unit 11, a processing unit 12, a short range communication unit 13, and a storage unit 14.

The network communication unit 11 is a component for communicating with the server 2, and the control information and the key (temporary/payment) from the server 2 through a MAN, LAN, and/or mobile communication network such as WiFi and LTE. Key/temporary card key/session key) can be received.

The processing unit 12 may store the control information and the key received by the network communication unit 11 in the storage unit 14. In addition, the control information may be transmitted to the short-range communication unit 13.

The short-range communication unit 13 may transmit the control information to the payment terminal 3. In this case, the key may be prevented from being transmitted to the payment terminal 3.

At this time, the payment terminal 3 may include the SAM (30). The SAM 30 may generate the key using the control information received from the short range communication unit 13 of the user device 1 and the master key stored in the SAM 30. At this time, since the verification of the control information is performed through the SAM (30), it cannot be operated from the outside, and abnormal transactions can be immediately blocked. Before generating the key, the SAM 30 may check the verification code using the master key, and may determine whether to approve the payment by comparing valid information of the token such as the payment request date and time.

Subsequent processing procedures and signature verification procedures are the same as in the prior art. The replacement of the master key is performed by the SAM in the traffic terminal, and there is no need for additional modification or change of the traffic terminal in the work for traffic payment payment.

The payment terminal 3 may be a transportation terminal or a terminal for paying for a service or product in a store. The application of the payment terminal 3 is not limited to a specific application.

In order to perform the above-described embodiment of the present invention, the user of the user device 1 first installs the application required for execution of the embodiment of the present invention on the user device 1, and then on the server 2 You can perform a registration procedure for registering users and user devices. The registration process may include the following process.

That is, when the user device 1 executes the application, the application may operate to cause the user device 1 to receive a user registration request from the server 2.

Then, the user can transmit user information and user device information to the server 2 through the application and the user device 1.

The server 2 may generate a user ID and a user device ID by using the user information and the user device information and store them in the server 2.

In addition, the server 2 may transmit the user ID and the user device ID to the user device 1.

When communication between the server 2 and the user device 1 is established, the server 2 can uniquely identify the user device 1 using the user ID and the user device ID.

Through the registration procedure, the server 2 can distribute, for example, issuance information of a transportation card to the user device 1. However, the control information for use in actual traffic payment and the registration process may not be distributed. In order for the user device 1 to acquire the control information and the key, the same procedure as described in FIGS. 1A, 2B, 3B, or 4B must be separately performed.

In the above-described embodiments, the step of receiving the key from the server by the user device and the step of receiving the control information may be combined as one step.

By using the above-described embodiments of the present invention, those belonging to the technical field of the present invention will be able to easily implement various changes and modifications within the scope not departing from the essential characteristics of the present invention. The content of each claim in the claims may be combined with other claims having no citation relationship within the range that can be understood through the present specification.

Claims (11)

As a payment method in which a user device and a payment terminal perform payment using a key,
Receiving, by the user device, a key from a server by executing an application program; And
Performing, by the user device, a payment process with the payment terminal using the key;
Including,
The user device is configured to delete or invalidate the key in the process of terminating the application program,
Payment Method. The method of claim 1,
The obtaining step includes the step of receiving, by the user device, control information including information on at least one of the validity period and the validity number of the key from the server using the application program,
The user device is characterized in that it is configured to determine whether to proceed with the payment process using the key based on the validity period or the validity number of times,
Payment Method. The method of claim 1,
The obtaining step includes the step of receiving, by the user device, control information including information on at least one of the validity period and the validity number of the key from the server using the application program,
The payment method further includes, by the user device, transmitting the control information to the payment terminal using the application program,
The validity period or the number of validity times determines whether the payment terminal or the SAM installed in the payment terminal performs the payment process using the key based on the validity period or the number of validity times included in the control information. Characterized in that it is provided for use in determining,
Payment Method. The method of claim 1, wherein the payment process is executed after the key is generated by the payment terminal or a SAM installed in the payment terminal. The method of claim 1, wherein the key is a payment key derived from a master key by the server using a card number. The method of claim 1, wherein the key is a session key derived from a master key by the server. The payment method according to claim 1, wherein the payment process can be executed a plurality of times by using the key from after the application program is executed to before the application program is terminated. The payment method of claim 1, wherein while the payment process is executed a plurality of times from the time the application program is executed until the end of the application program, the user device does not redistribute another key from the server. The method of claim 7,
The obtaining step includes receiving control information including information on at least one of the validity period for the key and the number of validity times for the key from the server using the application program,
The user device is configured to delete or invalidate the key when the validity period for the key elapses or the number of validity times for the key elapses from execution of the application program until termination,
Payment Method. A payment method for generating and providing the key so that a user device and a payment terminal perform payment using a key,
Receiving, by a server, a request message for generating and providing the key from a user device; And
Generating, by the server, the key and transmitting the generated key to the user device;
Including,
The payment terminal receives from the user device a card number specified using information included in the request message, or a temporary generated by the server based on a card number specified using information included in the request message. The card number is to be received from the user device,
The payment terminal derives the key from the master key stored in the payment terminal using the card number or the temporary card number, and payment performed between the payment terminal and the user device using the derived key Is supposed to run the process,
The user device is configured to execute the payment process performed between the payment terminal and the user device by using the key obtained by the user device from the server by using an application program installed in the user device,
The request message is generated by the application program,
The user device is configured to delete the key obtained from the server in the process of terminating the application program,
Payment Method. As a payment method in which a user device and a payment terminal perform payment using a key,
The payment terminal receives the card number specified using the information included in the request message sent by the user device to the server from the user device, or the card number specified using the information included in the request message. Receiving a temporary card number generated by a server from the user device;
Deriving, by the payment terminal, a key from a master key stored in the payment terminal using the card number or the temporary card number; And
Executing, by the payment terminal, a payment process performed between the payment terminal and the user device by using the derived key;
Including,
Control information including information on the validity number or validity period for use of the key is received from the user device,
When the number of times of use of the key exceeds the number of validity, or when the validity period has elapsed, the payment process is not executed using the derived key,
Payment Method.

Images