KR20120010756A

KR20120010756A - Micropay settlement system based on ID using OTP signature and method thereof

Info

Publication number: KR20120010756A
Application number: KR1020100072301A
Authority: KR
Inventors: 이원석; 이정원
Original assignee: 주식회사 케이티
Priority date: 2010-07-27
Filing date: 2010-07-27
Publication date: 2012-02-06

Abstract

The present invention relates to an ID-based micropayment system using OTP (One-Time Password) signature and a method thereof, and to provide an ID-based micropayment service using OTP (One-Time Password) signature in a general browser environment. To provide a system and a method thereof.
To this end, the present invention, a payment method for processing a billing request of an external pay service system, comprising: a subscription step of subscribing a user to a payment service based on an identifier (ID); A payment credential setting step of generating a one-time password (OTP) using an ID and a password from a payment service subscriber, generating a payment credential, issuing the generated OTP to the payment service subscriber, and setting a cookie; And a payment processing step of performing payment processing by verifying the OTP signature as a payment request using an OTP signature is received from the payment service subscriber who has confirmed the payment history according to the payment credential set. Include.

Description

Micro payment settlement system based on ID using OTP signature and method etc.

The present invention relates to an ID-based micropayment system and method using one-time password (OTP) signature, and more particularly, to a content provider / service provider (CP / SP) and broker using an OTP hash. It solves the security and reliability problem between users and contents users, and provides a mechanism to simply consume contents. Also, a micro payment service is provided so that various payment methods such as total carriers, credit cards, or points can be linked to virtual IDs. It relates to a system and method for providing the same.

Looking at the terms used in one embodiment of the present invention.

First, credentials are cryptographic personal information used in a specific application of an information system, and are public / private key pairs for a public key cryptographic algorithm used by an individual, issued by a public certification authority. A total of cryptographic information including public key certificates, information about trusted root certification authorities (eg, KISA top level certification authorities), passwords, authorization information, and so on.

And signature refers to a specific string indicating that it is in data communication.

The one-time password (OTP) is a one-time password generated to be used only in the session every time the user logs in, and can prevent a password theft problem caused by the same password being used repeatedly. Unlike regular passwords, one-way password-based hashes are used. They are discarded at the end of the session and are safe to reuse.

As the use of wired / wireless internet and the variety of terminals are released, the demand for distributing paid contents online has greatly increased. Recently, terminals such as Kindle, an e-book terminal of "Amazon Corporation" and iPad, a tablet terminal of "Apple", have been released, and these terminals are wireless networks such as Wi-Fi or third generation (3G) mobile communication systems. By mounting the interface, expectations for the online content distribution market are increasing.

In order to distribute paid online content, a payment and payment method is required to exchange a fee between a content provider / service provider (CP / SP) and a user who is a content consumer. In the case of e-book content, Amazon's Kindle registers the Kindle device serial number in an Amazon account and pays through the Amazon Card credit card at the time of purchase. In the case of Apple, iPod, iPhone, etc., payment is made through a credit card mapped to an Apple ID (Identifier) registered on the terminal. In the "Google company" Android terminal, the payment is made through a credit card registered in a Google account when using the Google App Store.

Payment for online purchases on a personal computer (PC) -based browser generates a payment provider's ID, such as PayPal Checkout, Google Checkout or ClickandBuy. When the credit card is mapped and settled, payment is made by verifying the mapped credit card and verifying the authentication on the web page of the payment service provider using the ID and password of the payment service provider.

Online contents are mostly made up of a small amount of 10,000 won or less, and in Korea, payments are often processed using a collection agency service and book vouchers, which are billed in addition to carrier fees.

Recently, expectations for the online content market have increased due to the emergence of portable terminals and the payment of newspapers and e-books. In addition, in order to distribute the small contents of long-tails (Long-Tail), a small payment method that can provide a small payment quickly and securely is required. And these small contents should be able to consume a large amount of small contents, for example, articles of paid online newspaper service.

Payment methods as described above have disadvantages that are not suitable for payment of very small amount (1,000 won or less) of online content. Checkout service provided by "Google" or "PayPal" will go to the company's authentication page every time a payment occurs and enter your ID / Password. Transactions such as credit card or bank transfer occur at the time of payment, which increases the cost. In addition, in the case of the collection agency service, which is charged in addition to the carrier's fee, the ARS (Automatic Response Service) authentication or the SMS (Short Message Service) authentication must be performed for authentication. There is a disadvantage that is not suitable.

In addition, the ID (Identifier) based payment service mapped to the hardware used in the Kindle or iPod can be used only in a closed environment that can control the terminal, and in particular, can be used only on specific hardware and a specific client. Not available in. In addition, use is inconvenient because a credit card must be used.

As described above, the prior art as described above has a problem that is not suitable for a small amount of payment or is restricted to a specific environment, and it is an object of the present invention to solve such a problem.

Accordingly, an object of the present invention is to provide a system and method for providing an ID-based micropayment service using a one-time password (OTP) signature in a general browser environment.

In other words, the present invention solves security and reliability problems between CPs / Contents Provider / Service Provider (CP / SP), Broker and Content User using one-time password (OTP) hash, thereby simplifying content consumption. It is an object of the present invention to provide a system and a method for providing a micro payment service by providing a mechanism and allowing a plurality of payment methods such as telcos, credit cards, or points to be linked to a virtual ID.

The objects of the present invention are not limited to the above-mentioned objects, and other objects and advantages of the present invention which are not mentioned can be understood by the following description, and will be more clearly understood by the embodiments of the present invention. Also, it will be readily appreciated that the objects and advantages of the present invention may be realized by the means and combinations thereof indicated in the claims.

A system of the present invention for achieving the above object, the payment system for processing a billing request of an external pay service system, comprising: an ID manager for managing an identifier (ID) of a payment service subscriber; A storage unit which stores mapping information between the payment service subscriber and at least one external payment system; And generating a credential and a one-time password (OTP) using the ID and payment password received from the subscriber terminal and issuing it to the subscriber terminal, and the payment service according to the charge request of the external pay service system. And a payment processing unit for verifying a subscriber's OTP signature and requesting billing to a corresponding payment system of the one or more external payment systems according to the mapping information of the storage unit.

On the other hand, the method of the present invention for achieving the above object, the subscription step of subscribing the user to the payment service based on the ID (Identifier); A payment credential setting step of generating a one-time password (OTP) using an ID and a password from a payment service subscriber, generating a payment credential, issuing the generated OTP to the payment service subscriber, and setting a cookie; And a payment processing step of performing payment processing by verifying the OTP signature as a payment request using an OTP signature is received from the payment service subscriber who has confirmed the payment history according to the payment credential set. Include.

As described above, the present invention has the effect of providing a safe and convenient micropayment service in a general-purpose browser environment (PC, mobile terminal, set-top box, etc.) in which JavaScript works.

That is, the present invention can generate payment by simply entering the OTP after the subscriber once authenticated, which provides convenience to the subscriber in generating a large amount of payment in a very small unit, and in particular, generates payment in the browser of the mobile terminal. In this case, the subscriber can enter a single ID / Password and after that, simply enter a 4-digit OTP to receive payment service. In other words, in the present invention, the subscriber's own information and information for using the payment means are processed only once in the subscription site in advance and thereafter, the payment is performed using an ID / password and one-time password. Therefore, it is unlikely that sensitive information of the customer is exposed.

In addition, in the present invention, since the payment credential is changed every time a payment occurs because the one-time password (OTP) is hashed as much as CNT, the credential value is obtained through packet capture. Even if the next payment is a meaningless value, it is impossible to steal by hacking.

In addition, the present invention can reduce the transaction cost between the billing system (Billing System) and the micropayment processing unit by collecting the charge log when it is accumulated to a certain level and delivers it to the billing system at a time. .

Figure 1a is a configuration diagram of an embodiment of an ID-based micropayment system using an OTP signature according to the present invention,
Figure 1b is a detailed configuration diagram of an embodiment of the micropayment processor of Figure 1 according to the present invention,
Figure 1c is a flow diagram of an embodiment of the ID-based micropayment method using the OTP signature in accordance with the present invention,
2 is a flow chart of an embodiment of a subscription process at the time of a carrier billing sum according to the present invention;
3 is a diagram illustrating an embodiment of a subscription process when a credit card is added in accordance with the present invention;
4 is a flowchart illustrating an embodiment of a payment credential setting process according to the present invention;
FIG. 5 is a flow chart of an embodiment of a payment process when a payment credential is set in a cookie according to the present invention; FIG.
FIG. 6 is a flowchart illustrating an embodiment of a payment processing process when a payment credential is set in a cookie but is not valid according to the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description of the present invention when taken in conjunction with the accompanying drawings, It can be easily carried out. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

And throughout the specification, when a part is referred to as being "connected" to another part, it includes not only "directly connected" but also "electrically connected" with another part in between. Also, when a component is referred to as " comprising "or" comprising ", it does not exclude other components unless specifically stated to the contrary .

1A is a diagram illustrating an embodiment of an ID-based micropayment system using an OTP signature according to the present invention.

As shown in FIG. 1A, the ID-based micropayment system using the OTP signature according to the present invention includes an ID manager 11 for managing an ID of a payment service subscriber, a subscriber of the micropayment service, and one or more subscribers. Credential and OTP (One) using a mapping database (DB, 12) that stores mapping information between payment systems (billing systems), and an ID and a payment password entered through the browser 16 of the external subscriber station. -Time Password) is generated to issue an OTP to the browser (16, subscriber terminal), verify the subscriber's OTP signature (Signature) in accordance with the small charge request from the CP / SP system 15 and the mapping database (DB, Requests billing to the billing system 14 according to the mapping information of 12), and provides an API (Application Programming Interface) for making a small payment to the CP / SP system 15. One micropayment processor 13 is included.

In addition, the ID-based micropayment system using the OTP signature according to the present invention uses a billing-related information such as a credit card or a contract with a telecommunications company or a prepaid card (including points) to provide a micropayment to the subscriber. It further includes a billing system (Billing System, payment means, 14) for billing, CP / SP system 15 for providing paid content or paid services to the subscriber, the browser 16 mounted on the subscriber's terminal, etc. do.

Here, the billing system 14 includes a credit card company billing system, a telecommunication company billing system, and a point billing system.

As described above, in the present invention, when a small payment occurs, payment authentication is performed, and at this time, the small payment processing unit 13 issues a one-time password (OTP) temporarily available for the session to the browser 16 to show the subscriber. In this way, the subscriber can use the one-time password (OTP) to use a small amount of paid content or a paid service on the CP / SP site without a separate authentication process. At this time, the present invention uses the OTP-based signature (Signature) to agree to the payment of the subscriber and to verify the reliability of the CP / SP.

Figure 1b is a detailed configuration of an embodiment of the micropayment processor of Figure 1 according to the present invention.

As shown in FIG. 1B, the micropayment processing unit 13 of FIG. 1 according to the present invention generates an external JavaScript code and provides it to the browser 16, and between each module inside and an external system. Providing an external API for interworking (eg REST / SOAP) to provide an external API providing module 131 and payment authentication UI (User Interface) to the browser 16 to check the input ID / password, Issuing, processing, and verifying a credential, providing a payment authentication module 132 for generating and issuing an OTP and a subscription UI (User Interface) to the browser 16 to perform subscription processing, and ID management unit 11 ), An identity management module for performing email authentication and interworking with an identity management module 133 for performing email transmission and callback processing, and an identity authentication system (eg, mobile phone, credit card, authorized authentication, etc.). (134), Paytoken The signature processing module 135 for verifying the signature and verifying the signature, the information (payment information) of the total contract or credit card, and checks the validity of the payment key to check the billing log. Billing processing module 136 for creating and processing billing transactions, authenticating CP / SP, creating and managing CP / SP credentials, and CP / for performing access control. The SP authentication module 137, the CP / SP management module 138 for issuing CP / SP codes and registering and managing CP / SP information, and the settlement processing module 139 for performing settlement processing for CP / SP. ).

Figure 1c is a flow diagram of an embodiment of a small payment method based on ID using the OTP signature in accordance with the present invention.

First, a user is subscribed to a micro payment service based on an identifier (see 151, FIGS. 2 and 3).

An OTP (One-Time Password) is generated using an ID and a password from the subscriber, a payment credential is generated, the generated OTP is issued to the subscriber, and a cookie is set (see FIG. 4).

As the payment credential is set, the payment is performed by verifying the OTP signature as a payment request using the OTP signature is received from the subscriber who checks the payment details (153, 5 and 6).

Figure 2 is a flow diagram of an embodiment of the subscription process when the carrier charges sum in accordance with the present invention.

In the present invention, the user must first subscribe to the micropayment service. The sign-up process can be divided into carrier billing and credit card billing. In this case, since the point settlement is possible similarly to the credit card billing, it will not be described separately. At this time, the subscription process when the carrier charges are added as shown in FIG. 2. The subscription process in the case of credit card billing is as shown in FIG.

On the other hand, as an ID of the registration process, for example, the user's e-mail address is used. Of course, an ID (Identifier) managed by the micropayment processor 13 may be issued without using an e-mail address. This is a part related to the policy of creating an ID in a small payment service subscription, and various applications are possible.

First, the user enters an address into a link of a CP / SP or a direct URL (Uniform Resource Locator) or through a link of an ID / password input window at the time of the settlement of the micro settlement processing unit 13, etc. Access to a subscriber page (201). At this time, the subscriber page of the micropayment processing unit 13 shows a page for logging in and managing a subscriber who has already subscribed, and moves to a subscription link for a user who has not subscribed. In this case, the micropayment processing unit 13 shows the service usage guide / terms agreement UI (User Interface) to the user (202).

Accordingly, when the user agrees to the terms in the expression of subscription (203), the micropayment processing unit 13 shows a screen (input window) for inputting an email ID to subscribe to (204).

Accordingly, when the user inputs the e-mail ID (205), the micropayment processing unit 13 sends the e-mail containing the confirmation-URL to the ID management unit 11 (206).

Accordingly, when the user checks the e-mail of the ID management unit 11 (207) and clicks the confirm-URL linked to the e-mail, the related content is transmitted to the micro payment processing unit 13 (208). .

Then, the micro payment processing unit 13 shows the UI for selecting a payment method type to the user (209).

Accordingly, when the user selects the payment method type (210), the micro payment processing unit 13 shows the screen for selecting the user authentication method to the user (211).

Accordingly, the user selects a user authentication method suitable for his environment (212). At this time, a possible identity verification method may be, for example, mobile phone authentication, authorized authentication, credit card authentication.

Then, the micropayment processor 13 shows a user interface (UI) for inputting user authentication information according to the selected user authentication method (means) (213).

Accordingly, when the user inputs the user authentication information according to the user authentication method (means) (214), the micropayment processing unit 13 performs the user authentication by interworking with the relevant user authentication authority or the user authentication system based on the corresponding user authentication information. Perform (215).

Subsequently, the micropayment processing unit 13 inquires a contract that can be added to the telecommunication company with the telecommunication company billing system using the user's social security number (216).

Then, the carrier billing system inquires the customer's sumable contract and maps and stores the summable contract list and the settlement key that can generate the actual settlement (217). Related information such as a payment key) is transferred to the micro payment processing unit 13 (218).

Then, the micro payment processing unit 13 shows the UI for selecting a contract to be summed up to the user (219). In this case, the payment key may be a key value managed by the telecommunication company billing system as a contract distinguishing key for total billing in the telecommunication company billing system.

Accordingly, when the user (customer) selects the contract to be summed up (220), the micropayment processing unit 13 shows a user interface (UI) to the user to enter a payment password (221).

Accordingly, when the user enters the payment password (222), the database of the micropayment processing unit 13 includes an e-mail ID address, whether the customer agrees, an encrypted payment password, a payment key that can be combined with the payment method, and a billing key. Other information is stored (223).

Figure 3 is an embodiment configuration for a subscription process at the time of credit card total billing in accordance with the present invention.

First, the user enters an address into a link of a CP / SP or a direct URL (Uniform Resource Locator) or through a link of an ID / password input window at the time of the settlement of the micro settlement processing unit 13, etc. Access the subscriber page (301). Then, the micropayment processor 13 shows the service usage guide / terms agreement UI (User Interface) to the user (302).

Accordingly, when the user agrees to the terms in the expression of subscription (303), the micropayment processing unit 13 shows the user a screen (input window) for inputting an email ID to join (304).

Accordingly, when the user inputs the e-mail ID (305), the micropayment processing unit 13 sends the e-mail containing the confirmation-URL to the ID management unit 11 (306).

Accordingly, when the user checks the e-mail of the ID manager 11 and clicks the call-back linked to the e-mail, the related content is transmitted to the ID manager 11 (307), and accordingly the ID The management unit 11 transmits a call-back to the micropayment processing unit 13 (308).

Thereafter, the micro payment processing unit 13 shows a UI for selecting a payment method type to the user (309).

Accordingly, when the user selects a credit card from the payment method type (310), the micropayment processor 13 shows the credit card authentication information input window to the user (311).

Accordingly, when the user inputs credit card authentication information such as a credit card number and an expiration date (312), the micropayment processing unit 13 transmits the credit card authentication information to the credit card company billing system (313).

Then, the credit card company billing system checks the corresponding credit card authentication information (314) to generate a payment key value that the customer can pay with the credit card and map the generated payment key value and the corresponding credit card number ( 315) The small payment processing unit 13 transmits (316).

Then, the micro payment processing unit 13 shows a user interface (UI) for inputting a payment password to the user (customer) (317). Accordingly, when the user inputs a payment password (318), the micro payment processing unit 13 The database stores the email ID address, the customer's consent, the encrypted payment password, the payment method type, the payment key that can be paid by credit card, and other information (319). In this case, the payment key is a key value for generating a payment by mapping a credit card, and may be an encrypted credit card number or a management value of a credit card company billing system.

A method of using the micropayment service of the present invention when a subscriber subscribed through the subscription process (process) of FIG. 2 or FIG. 3 described above uses the service of CP / SP. 1) Payment credential setting process (see FIG. 4). 2) Payment processing when payment credential is set in the cookie (see FIG. 5), 3) Payment processing process when payment credential is set in the cookie but is invalid (Fig. 6).

4 is a flowchart illustrating a payment credential setting process according to the present invention, which illustrates a process of setting a payment credential using an ID / password.

First, the subscriber accesses the paid web page among the services of the CP / SP system 15 (401). At this time, the browser 16 loads the external JavaScript code for the CP / SP into the micro payment processing unit 13 (402). Here, when the external JavaScript is loaded, the key value and the cpcode of the CP / SP are passed to the URL to be passed to the micro settlement processing unit 13, and the micro settlement processing unit 13 transmits the CP / SP. The CP is authenticated with a key value of the SP, an IP / domain address, and a CP code (hereinafter referred to as "cpcode"), and a credential C0 of the CP is generated. In order to use it to prevent site traffic, the IP address (IPO) of the browser is mapped with the CP credential and stored (403). Here, cpcode is a code that CP / SP is assigned when the service is registered in the micro payment processing unit 13 and is a billing and settlement classification code for each CP / SP.

The micro payment processing unit 13 generates a hash function H0 for the generated CP credential and loads it as a function in JavaScript (404).

Subsequently, the micropayment processing unit 13 sets the CP credential C0 to a cookie (CPC = C0) when the page loading is completed while including JavaScript (operation 405).

Thereafter, when the subscriber (browser) accesses the paid content of the CP / SP system 15 (406), the JavaScript provided by the CP / SP system 15 to the browser 16 by the micropayment processing unit 13 is provided. (Javascript) payment API is called (invoking payment function for paid payment, including payment information and cpcode) (407) JavaScript payment API on browser 16 checks the cookie value to make payment Check if there is a credential (408).

As a result of the check 408, if there is a payment credential, the process proceeds to a payment function call process 421. If there is no payment credential, the JavaScript payment API on the browser 16 is small. The payment authentication page of the payment processor 13 forwards (HTTP) based on the HTTPS protocol. At this time, cpcode and CP credential C0 are transmitted to the micropayment processor 13 as a URL (409).

Then, the micropayment processor 13 removes the possibility of pitting by comparing the browser IP IP0 and C0 received in step 409 with the browser IP IP0 and C0 stored in step 403 (step 410). The micro payment processing unit 13 shows the ID / Password input window to the subscriber (411).

Accordingly, when the subscriber inputs the ID / Password set at the time of subscribing to the micropayment service in the ID / Password input window (412), the micropayment processing unit 13 verifies the ID / Password. In operation 413, the controller requests a verification (validation) from the billing system 14 to determine whether a payment key value mapped to the corresponding ID is valid (414).

Then, the charging system 14 checks the validity of the total billing contract and the credit card mapped to the corresponding payment key (payment key validity check) and transmits the result to the micro payment processing unit 13 (415).

Then, the micro payment processing unit 13 generates a 4-digit one-time password (OTP) (416), generates a payment credential (U), and stores the mapping to the corresponding ID (417). In addition, the micropayment processor 13 outputs the OTP to the browser 16 (418).

Accordingly, when the browser 16 confirms the OTP (419), the micropayment processing unit 13 uses the return URL or the Call-Back function set by the CP to CP page of the browser 16. Forward to. At this time, the micropayment processor 13 sets CPC = C0, PTKEN = P (0) = U, and CNT = 0 as a cookie (420). In the CP page on the browser 16, the payment function for the paid payment is called again (421) so that the payment is processed through the payment processing of FIG. 5 or 6.

5 is a flowchart illustrating an embodiment of a payment processing process when a payment credential is set in a cookie according to the present invention.

First, when the CP / SP system 15 calls the payment function for the paid payment to the browser 16 (501), the payment function on the browser 16 checks whether the payment credential is set in the cookie ( 502). At this time, if payment credential is set, cookie values of CP credential C0 (CPC = C0), payment credential (PTKEN = P (n + 1)), and usage count (CNT = n + 1) exist. When the payment function is called with CP credential CPC = C0, payment credential PTKEN = P (n + 1), and usage count CNT = n + 1, the billing information and cpcode are used so that the subscriber can recognize the payment and check the amount. Call the payment function with the information.

As a result of the check 502, if a payment credential exists in a cookie, a JavaScript API pops up a payment UI (User Interface) and shows the payment information (503). Here, the payment UI (User Interface) shows the payment information (CP / service name, amount) and the like to the subscriber, and provides an input window for receiving a one-time password (OTP) from the subscriber.

Accordingly, the subscriber inputs the OTP (O0) received from the micro payment processing unit 13 through the ID / password input in the payment credential setting process of FIG. 4 (504). Then, a JavaScript function on the browser 16 calculates a Paytoken (M), which is represented by Equation 1 below (505).

Then, the JavaScript API on the browser 16 makes a payment request to the micro payment processing unit 13, where cpcode, C0, cnt, P (n + 1), M, amount, and P (n). Information is passed along (506).

Here, the micropayment processing unit 13 basically includes H0, which is a hash function in this payment session, IP0 of the browser loaded with JavaScript, initial payment credential P (0), and OTP (O0) issued to the subscriber. , The number of times used so far (use count, n) and the current payment credential P (n).

Accordingly, when the micro payment processing unit 13 receives the CP credentials (C0) in the process “506,” the JavaScript is normally called by checking the preset browser IP, IP0, and the IP when the payment request is made. It is possible to check whether or not it is called by Pip.

When the information of the process “506” is received, the micro payment processing unit 13 checks the valid condition of the payment credential P (n) (507). In this case, the valid condition may set a specific time, a specific usage count (cnt) limit, or a specific amount limit after the initial payment credential issuance time as a valid condition.

As a result of the check 507, if the payment credential P (n) is valid, the micropayment processor 13 calculates the pay token (M) using the values stored therein (508 and 509).

Looking at the paytoken (M) calculation process in more detail, the micropayment processor 13 first calculates P (n + 1) as shown in Equation 2 using information stored therein ( 508).

The micro settlement processing unit 13 calculates a pay token (M) as shown in Equation 3 using the calculated P (n + 1) value and the amount delivered in the process “506”. 509.

In addition, the micro payment processing unit 13 compares the calculated paytoken (M) value with the paytoken (M) value received in the process “506”, and generates a billing log and generates a billing log. Create a transaction ID (Trid) that is a key value. At this time, the state of the charging log becomes the charging standby state (510).

Subsequently, the micropayment processor 13 transmits the generated transaction ID Trid to a JavaScript API, and accordingly, the JavaScript API transmits the cookie of the browser to CPC = C0, PTKEN = P (n +1), CNT = n + 1 is set (511).

Afterwards, the JavaScript API transfers the transaction ID Trid to the CP / SP system 15 as a payment result (512), and accordingly, the CP / SP system 15 has a small transaction ID (Trid). A payment confirmation request is made to the payment processing unit 13 (513).

Accordingly, if there is a normal charging log, the micro settlement processing unit 13 changes the charging log for the corresponding transaction ID Trid to the charging confirmation state (514), and transfers the charging confirmation result to the CP / SP system 15. (515). Accordingly, when the CP / SP system 15 receives the charging confirmation result, the CP / SP system 15 provides a service to the browser 16 according to the result (516).

In addition, the micro settlement processing unit 13 checks a specific billing transmission condition (for example, after a predetermined time, or according to a predetermined number of payments, or when a certain amount of money is reached) (517) to satisfy the billing transmission condition. In step 518, a billing request (payment key) is made to the billing system.

Meanwhile, in the present invention, as described above with reference to FIG. 4, the ID / password may be authenticated once, and as described above with reference to FIG. 5, payment may be repeatedly generated using OTP. Here, OTP can reduce the entry of the customer by issuing a four-digit number as well as to prevent theft because the customer confirms the payment history and generates a signature with OTP, a temporary value only known to the customer. In addition, information leakage can be greatly reduced by minimizing ID / password input during recurring payments. In addition, the paytoken value cannot be generated by CP / SP, the payment credential value changes every time, and the payment credential value cannot be generated without knowing the OTP, and the initial credential value is generated. Theft is impossible because it cannot be inferred.

Therefore, according to the present invention, the subscriber can generate payment by simply inputting only OTP after authentication. This approach may provide a convenience to the subscriber in generating a large amount of payment in a very small unit. In particular, when a payment is generated in the browser of the mobile terminal, the subscriber can receive a micro payment service by inputting one ID / password and then simply entering a 4-digit OTP.

In the present invention, since the payment credential is hashed by including the one-time password (OTP) as much as the usage count (CNT), each time the payment credential is changed. That is, in the present invention, the payment credential is changed at every use by using the one-time password (OTP), the usage count (CNT), and the payment credential of the previous usage count. Therefore, even if the payment credential value is obtained through packet capture, it is not possible at the next payment, so that theft by hacking is impossible.

In addition, in the present invention, the payment credential may be set to be valid only for a specific condition. When the validity condition is checked for a specific time, the micropayment processing unit 13 may allow the OTP to be issued by specifying the validity period and re-entering ID / Password while storing the payment credential issuing time. . Alternatively, valid conditions can be created with usage count (CNT) values or total usage amounts. The payment process at this time is as shown in FIG.

FIG. 6 is a flowchart illustrating an embodiment of a payment processing process when a payment credential is set in a cookie but is not valid according to the present invention.

First, when the CP / SP system 15 calls the payment function for the paid payment to the browser 16 (601), the payment function on the browser 16 checks whether the payment credential is set in the cookie ( 602). At this time, if payment credential is set, cookie values of CP credential C0 (CPC = C0), payment credential (PTKEN = P (n + 1)), and usage count (CNT = n + 1) exist. When the payment function is called with CP credential CPC = C0, payment credential PTKEN = P (n + 1), and usage count CNT = n + 1, the billing information and cpcode are used so that the subscriber can recognize the payment and check the amount. Call the payment function with the information.

As a result of the check 602, if a payment credential exists in a cookie, a JavaScript API pops up a payment UI (User Interface) and shows the payment information (603). Here, the payment UI (User Interface) shows the payment information (CP / service name, amount) and the like to the subscriber, and provides an input window for receiving a one-time password (OTP) from the subscriber.

Accordingly, the subscriber inputs the OTP (O0) received from the micropayment processing unit 13 through the ID / password input in the payment credential setting process of FIG. 4 (604). Then, a JavaScript function on the browser 16 calculates Paytoken (M), which is the same as Equation 1 above (605).

Then, the JavaScript API on the browser 16 makes a payment request to the micro payment processing unit 13, where cpcode, C0, cnt, P (n + 1), M, amount, and P (n). Information is passed along (606).

Accordingly, when the micro payment processing unit 13 receives the CP credentials (C0) in the process “606”, the small payment processing unit 13 checks the preset browser IP IP0 and the IP upon the payment request, and the JavaScript is normally called. It is possible to check whether or not it is called by Pip.

When the information of the “606” process is received, the micro payment processing unit 13 confirms the valid condition of the payment credential P (n) (607). In this case, the valid condition may set a specific time, a specific usage count (cnt) limit, or a specific amount limit after the initial payment credential issuance time as a valid condition.

If the check result 607, the payment credential P (n) is not valid, the micropayment processing unit 13 requests a JavaScript payment API on the browser 16 to forward to a payment authentication page ( 608).

Then, the JavaScript payment API on the browser 16 forwards to the payment authentication page of the micro payment processing unit 13 based on the HTTPS protocol. At this time, the cpcode, the CP credential C0 and the payment credential P (n) are transmitted to the micropayment processor 13 as a URL (609).

Then, the micro payment processing unit 13 removes the possibility of pitting by comparing the browser IP (IP0) and C0 received in step 609 with the browser IP (IP0) and C0 stored in the payment credential setting process (step 403). 610. In addition, the micro payment processing unit 13 extracts an ID (Identifier) to P (n) (611) and shows a password input window to the subscriber (612). In this case, the ID may be basically set in the ID / password input window to minimize the subscriber's input. In other words, the ID may show the ID mapped to the payment credential in the ID / Password input window so that only the payment password may be input to facilitate the subscriber's convenience.

Accordingly, when the subscriber inputs the password set at the time of subscribing to the micro payment service in the password input window (613), the micro payment processing unit 13 verifies (confirms) the ID / password. In operation 615, a check (verification) is requested to the billing system 14 to determine whether a payment key value mapped to the corresponding ID is valid.

Then, the charging system 14 checks the validity of the total billing contract and the credit card mapped to the corresponding payment key (payment key validity check) and transmits the result to the micro payment processing unit 13 (616).

Then, the micro payment processing unit 13 generates a 4-digit one-time password (OTP) (617), generates a payment credential (U), maps the ID, and stores it (618). The micro settlement processing unit 13 outputs the OTP to the browser 16 (619).

Accordingly, when the browser 16 confirms the OTP (620), the micropayment processing unit 13 uses the return URL or the Call_Back function set by the CP to the CP page of the browser 16. Forward to. At this time, the micropayment processor 13 sets CPC = C0, PTKEN = P (0) = U, and CNT = 0 as a cookie (621). In the CP page on the browser 16, the payment function for the paid payment is called again (622) so that the payment is processed through the payment processing process.

As described above, the billing request to the actual billing system is a billing request with a payment key. At this time, if a billing log is accumulated over a predetermined level, the billing log is collected and delivered at once. Therefore, the transaction cost between the billing system and the micro payment processing unit is reduced.

In addition, the subscriber's personal information and information for using the payment method is processed only once in the subscription site, and afterwards, payment is made using an ID / password and one-time password. It is unlikely that sensitive information will be disclosed.

On the other hand, the micropayment method according to the present invention as described above is implemented in the form of program instructions that can be executed by various computer means may be recorded on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. Program instructions recorded on the media may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. The medium may be a transmission medium such as an optical or metal line, a wave guide, or the like, including a carrier wave for transmitting a signal designating a program command, a data structure, or the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, Various permutations, modifications and variations are possible without departing from the spirit of the invention.

Therefore, the scope of the present invention should not be construed as being limited to the embodiments described, but should be determined by the scope of the appended claims, as well as the appended claims.

The present invention can be used for a micro payment service in a general browser environment in which JavaScript is operated in a terminal such as a personal computer (PC), a set-top box, and a portable terminal.

11: ID management unit 12: mapping database (DB)
13: micropayment processing unit 14: billing system (Billing System)
15: CP / SP system 16: browser

Claims

In the payment system for processing the charge request of the external pay service system,
An ID manager for managing an identifier (ID) of a payment service subscriber;
A storage unit which stores mapping information between the payment service subscriber and at least one external payment system; And
Using the ID received from the subscriber terminal and the payment password, a credential and a one-time password are generated and issued to the subscriber terminal, and the payment service subscriber is requested according to the charge request of the external paid service system. The payment processing unit for verifying the OTP signature of the payment request for the charge to the corresponding payment system of the one or more external payment system according to the mapping information of the storage unit
Payment system comprising a.

The method of claim 1,
The payment processing unit,
An external API providing module for generating an external JavaScript code and providing it to a browser of the subscriber terminal and providing an external API for interworking with an external system;
A payment authentication module for providing a payment authentication UI (User Interface) to the browser to check input ID / password, issue, process and verify payment credentials, and generate and issue an OTP;
An ID management module for providing a subscription UI (User Interface) to the browser to perform subscription processing, interworking with the ID management unit, and performing email transmission and callback processing;
An identity verification module for performing identity verification in association with an external identity verification system;
A signature processing module for calculating and authenticating a paytoken and authenticating a signature;
A billing processing module for querying payment information and checking the validity of a payment key to generate a billing log and to process a billing transaction;
A paid service system authentication module for authenticating the paid service system, generating and managing credentials for the paid service system, and performing access control;
A paid service system management module for issuing a code for the paid service system and registering and managing information on the paid service system; And
Settlement processing module for performing the settlement processing for the pay service system
Payment system comprising a.

In the payment method for processing the charge request of the external paid service system,
A subscription step of subscribing a user to a payment service based on an ID;
A payment credential setting step of generating a one-time password (OTP) using an ID and a password from a payment service subscriber, generating a payment credential, issuing the generated OTP to the payment service subscriber, and setting a cookie; And
A payment processing step of performing a payment process by verifying the OTP signature as a payment request using an OTP signature is received from the payment service subscriber who checks the payment history according to the payment credential set.
Payment method comprising a.

The method of claim 3, wherein
The payment method characterized in that the payment processing is repeatedly performed using the issued OTP repeatedly.

The method of claim 4, wherein
The payment method of claim 1, wherein the payment credential is changed at every use by using the issued one-time password (OTP), the usage count (CNT), and the payment credential of the previous usage count.

6. The method according to any one of claims 3 to 5,
The joining step,
And a payment method, a payment password, a payment method type, and a payment key.

The method according to claim 6,
The joining step,
Verifying by receiving the user's consent and receiving an e-mail ID according to access of the user's subscriber page;
Receiving a selection of a payment method type from the user;
Performing identity verification for the user;
Querying for a summable contract using the social security number of the user and selecting a contract to sum up from the user;
Receiving a payment password from the user; And
A process for storing an email ID address, whether the user agrees, an encrypted payment password, a payment key, and a payment key that can be combined
Payment method comprising a.

The method according to claim 6,
The joining step,
Verifying by receiving the user's consent and receiving an e-mail ID according to access of the user's subscriber page;
Receiving a credit card from the user to a payment system;
Receiving a credit card authentication information from the user to obtain a payable credit card payment key;
Receiving a payment password from the user; And
A process of storing an email ID address, whether the user agrees, an encrypted payment password, a payment method type, and a payment key that can be paid by credit card.
Payment method comprising a.

6. The method according to any one of claims 3 to 5,
The payment credential setting step,
Authenticate the pay service system according to the loading of external JavaScript code for the pay service system, generate a credential C0 for the pay service system, and map and store it with a browser IP address (IPO). First process;
A second step of generating a hash function H0 for the generated paid service system credential C0 and setting the generated paid service system credential C0 as a cookie;
A third step of forwarding to a payment authentication page when there is no payment credential as a result of confirming the existence of a payment credential according to a call to a payment function for paying a payment;
A fourth step of receiving and verifying an ID and a password set at the time of subscribing a payment service from the payment service subscriber and requesting verification of a payment key mapped to the ID to verify validity;
A fifth step of generating an OTP using the verified ID and password, generating and storing a payment credential (U), mapping and storing the generated OTP, and issuing the generated OTP to the payment service subscriber; And
As the issued OTP is confirmed, the service is forwarded to the paid service page, and the generated paid service system credential C0, the generated payment credential U, and the usage count "0" are set as cookies. 6th course
Payment method comprising a.

The method of claim 9,
Comparing the browser IP address and the paid service system credential (C0) received during the forwarding in the third process with the browser IP address and the paid service system credential (C0) stored in the first process to eliminate the possibility of pitting 7th course
Payment method that includes more.

The method of claim 10,
The payment processing step,
An eighth step of receiving a payment request using a pay token M calculated using an OTP received from the payment service subscriber who checks the payment details according to a payment credential set;
A ninth step of checking a valid condition of the set payment credential to calculate a pay token M using previously stored values;
A tenth step of generating a charging log and generating a transaction ID (Trid) according to the coincidence of the pay token (M) value of the eighth step and the pay token (M) value of the ninth step;
An eleventh step of confirming payment for the pay service system using the generated transaction ID Trid and changing the generated charge log to a charge confirmation state; And
Step 12 of requesting billing to an external payment system according to the billing transmission condition
Payment method comprising a.

The method of claim 11,
A thirteenth step of confirming valid conditions of the set payment credential and forwarding to a payment verification page according to the invalidity; And
Extract the ID by the payment credential, receive and verify the password set at the time of subscription of the payment service from the payment service subscriber, and request validation of the payment key mapped to the ID. After the 14th process proceeds to the fifth process
Payment method that includes more.

The method of claim 12,
Valid conditions of the payment credential,
The payment method comprising any one of a specific time, a usage count (cnt) limit, or a specific amount limit after the initial payment credential issuance time.