JP5981507B2 - How to process payments - Google Patents

Description

  The present invention relates to a method of processing a payment, and more particularly to a method of using a plug and play device to process a payment.

  Currently, payment for goods and / or services can be made using plastic memory cards (eg, credit cards, debit cards, etc.). In order to accept a plastic memory card as a means of payment, a merchant can read a processing device (eg, a payment card) to agree with a card issuer (eg, a bank) and to interact with the card issuer. Card reader). As a result, merchants operating with low profits and / or low margins may be reluctant to accept plastic memory cards.

  For online transactions, online payment using a credit card is typically performed with a personal computer or mobile device (eg, a smart phone). When performing online payment, the user first enters personal information, including the username and associated password to verify the user's identity, via an interface (eg, a web page displayed on a personal computer). You are instructed. After the user's identity is verified, the interface further instructs the user to enter credit card information that can include a card number, expiration date, and the like. Conventional systems for performing such payments can be seen, for example, as disclosed in Taiwan Patent No. 473681 and Taiwan Patent Publication No. 200816099.

  However, if a computer or mobile device is not available or does not function (due to lack of internet connection or insufficient power), online payments may not be possible.

  Accordingly, it is an object of the present invention to provide a method that can address the disadvantages of the prior art described above.

As a result, the method of the present invention is for processing payments. The method is implemented using an electronic device that is removably connected to a portable payment device and communicates with a bank server. The portable payment device is a plug-and-play device and includes a payment card. The method is
(A) receiving transaction information related to the transaction and payment for the transaction by the electronic device;
(B) accessing a payment card by an electronic device via a portable payment device;
(C) cooperating with the payment card by the electronic device to generate a payment command including at least transaction information;
(D) establishing a session with the bank server by the electronic device, the session providing a secure communication channel between the electronic device and the bank server;
(E) sending a payment command by the electronic device to the bank server under the session established in step (d), wherein the bank server is based on the payment command in response to receiving the payment command. Configured to process the payment according to the transaction information included in the payment command after confirming the validity of the payment card and confirming that the payment card is valid;
(F) receiving payment results from the bank server under the session established in step (d) by the electronic device, wherein the payment results are generated by the bank server after completing the payment; When,
Is provided.

  Another object of the present invention is to provide a system configured to communicate with a bank server to perform the method described above.

  As a result, the system of the present invention comprises an electronic device and a portable payment device.

  An electronic device includes a processor, a storage device coupled to the processor and storing a transaction application, a first connection interface coupled to the processor, and a communication coupled to the processor and configured to communicate with a bank server. And a device.

  The portable payment device is a plug and play device and is detachably connected to the electronic device. The portable payment device is electrically connected to a card slot provided with a card interface to contain a payment card and a first connection interface of the electronic device, and allows the payment card to be accessed using the electronic device. Two connection interfaces.

  When executed by a processor through a transaction application, the electronic device cooperates with the payment card and bank server to perform the method of the present invention.

  Yet another object of the present invention is to provide an electronic device capable of performing the method.

  As a result, the electronic device of the present invention is removably coupled to a processor, a storage device coupled to the processor and storing a transaction application, and a portable payment device coupled to the processor and provided with a payment card. A connection interface, and a communication device coupled to the processor and configured to communicate with the bank server.

  When executed by a processor through a transaction application, the electronic device cooperates with the payment card and bank server to perform the method of the present invention.

  Yet another object of the present invention is to provide a payment card that is configured to use a variety of security mechanisms to manage data from different sources.

  As a result, the payment card of the present invention is coupled to an electronic device that executes an application for performing a personalization process for the payment card. The payment card has a control module and a storage device.

  The control module includes a controller chip, controller firmware, and an application program interface (API).

  The storage device has a hidden area that is only accessible to the application via the controller firmware and API after a predetermined authorization sequence has been performed.

  The hidden area is divided into a plurality of hidden data blocks. Each of the hidden data blocks is associated with a storage security level and is configured to store personalization data of a predetermined data type.

  For each hidden data block, the controller chip is configured to perform a personalization process that stores personalization data along with a predetermined one of a plurality of security mechanisms corresponding to the storage security level of the hidden data block. The

Other features and advantages of the present invention will become apparent from the following detailed description of preferred embodiments, taken in conjunction with the accompanying drawings.
FIG. 1 is a block diagram of a preferred embodiment of a system according to the present invention. FIG. 2 is a schematic diagram of an interface device configured to communicate with various electronic devices of the system of FIG. FIG. 3A is a flowchart illustrating the steps of a method for processing a payment using the system of FIG. FIG. 3B is a flowchart illustrating the steps of a method for processing a payment using the system of FIG. FIG. 3C is a flowchart illustrating the steps of a method for processing a payment using the system of FIG. FIG. 4 shows the various messages output by the input / output devices of the electronic device at various stages of the method. FIG. 5 shows various messages output by the input / output devices of the electronic device at various stages of the method. FIG. 6 shows various messages output by the input / output devices of the electronic device at various stages of the method. FIG. 7 shows the various messages output by the input / output devices of the electronic device at various stages of the method. FIG. 8 is a block diagram of a payment card storage device according to the present invention. FIG. 9 is a flowchart of a payment card personalization process according to the present invention. FIG. 10 is a flowchart of a personalization process performed using the first securing mechanism. FIG. 11 is a flowchart of a personalization process performed using the second securing mechanism. FIG. 12 is a flowchart illustrating a bank server cooperating with a platform server and an organization server to generate information for performing a personalization process using a third securing mechanism. FIG. 13A is a flowchart of a personalization process performed using a third securing mechanism. FIG. 13B is a flowchart of a personalization process performed using the third securing mechanism. FIG. 14A is a flowchart of a personalization process performed using a fourth securing mechanism. FIG. 14B is a flowchart of a personalization process performed using the fourth securing mechanism.

  As shown in FIG. 1, a preferred embodiment of a system 100 according to the present invention is for implementing a method for processing payments associated with a transaction. The system 100 is provided with an electronic device 1 capable of communicating with a bank server 5, a payment card 22, removably connected to the electronic device 1, and for coupling the payment card 22 to the electronic device 1. A portable payment device 2 that serves as an interface device.

  In the present embodiment, the electronic device 1 may be embodied using one of a personal computer, a laptop computer, a tablet computer, a mobile device, an automated teller machine (ATM), and a vending machine. Yes (see FIG. 2). Note that personal computers, laptop computers, tablet computers and mobile devices can be owned by either the customer or the merchant. The electronic device 1 needs to have a network connection and a mechanism for executing an application designed to cause the electronic device 1 to execute a method of processing payments.

  The electronic device 1 operates to communicate with the bank server 5 over the network. The bank server 5 can be operated by a master bank or member bank that issues payment cards to customers. In the present embodiment, the bank server 5 includes a platform server 3 for communicating with an electronic device, and a bank system 4 coupled to the platform server 3. In various embodiments, platform server 3 and banking system 4 are integrated as a single component (eg, server) or implemented as two separate components that communicate on a dedicated channel or session. Can do. When the platform server 3 and the bank system 4 are realized as separate components, the platform server 3 can be operated by a third party other than the bank.

  The electronic device 1 includes a processor 11, a storage device 12 coupled to the processor 11 and storing a transaction application 120, a first connection interface 13 coupled to the processor 11, and an input / output coupled to the processor 11 ( I / O) device 14 and a communication device 15 coupled to the processor 11.

  In the present embodiment, the first connector 13 can be embodied using a universal serial bus (USB) 2.0, USB 3.0, MiniUSB, or USB port. The I / O device 14 can include, but is not limited to, a mouse / keyboard combination, a touch screen, a speaker / display combination, or a combination thereof. When the electronic device 1 is implemented using a vending machine, the I / O device 14 may have a plurality of physical / virtual buttons, a control panel, a product dispenser, or a combination thereof. When the electronic device is implemented using an automated teller machine (ATM), the I / O device 14 can include a touch screen, a keyboard, and an automated teller machine.

  The portable payment device 2 is embodied using a plug and play device (for example, a device having a universal serial bus (USB) 2.0, USB 3.0, MiniUSB or USB connection). The portable payment device 2 is removably connected to the electronic device 1 to perform a method for processing payments.

  The portable payment device 2 can be sufficiently dimensioned to fit into a pocket or wallet and / or to be attached to other items such as a wallet, portable device, etc. as an accessory. The portable payment apparatus 2 is electrically connected to the housing 20 formed with the card slot 201, the circuit board 21 arranged in the housing 20, the circuit board 21, and the first connection interface 13 of the electronic apparatus 1. And a second connection interface 23 configured to be connected to each other. The card slot 201 is provided with a card interface for containing the payment card 22. The card interface provides a communication interface between the payment card 22 and the second connection interface 23 so that when the portable payment device 2 is coupled to the electronic device 1, access to the payment card 22 is electronic. This is possible by using the device 1. It should be noted that when the payment card 22 is not connected to the mobile payment device 2, the mobile payment device 2 is not provided with a calculation function.

  In the present embodiment, the payment card 22 is embodied by using a micro secure digital (SD) card. The payment card 22 includes a control module 220, a financial data chip 221, and a storage device 225. The financial data chip 221 (see FIG. 1) can be compiled according to the FISC II specification.

  The control module 220 includes a controller chip 222, controller firmware 224 disposed in a read-only memory (ROM) (not shown), and an application programming interface (API) 223. The controller chip 222 and ROM can be integrated using integrated circuit packaging and can be juxtaposed with the storage device 225.

  When the portable payment device 2 is coupled to the electronic device 1, the processor 11 operates to access the financial data chip 221 and the storage device 225 through the controller firmware 224. The API 223 and the control firmware 224 can operate according to the instructions of the transaction application 120. The API 223 has a function capable of executing encryption using an algorithm such as triple data encryption algorithm subject key block cipher (3DES), advanced encryption standard (AES), RSA cipher.

  The storage device 225 includes a system unit 226 and a storage unit 227. The system unit 226 is constructed with basic operation information. The storage unit 227 has a hidden area 228 and a visible area 229. The visible area 229 permits access by the operating system (OS) of the electronic device 1. For example, in the case of a Microsoft Windows (registered trademark) system, the visible region 229 can be accessed by using a file management program.

  The hidden area 228 cannot access the OS, and is not permitted to perform operations such as reading, writing, or changing the contents of the file stored in the hidden area 228 via the OS. Instead, hidden area 228 is only accessible to transaction application 120 via controller firmware 224 after a predetermined authorization sequence has been performed. Specifically, when the mobile payment device 2 is coupled to the electronic device 1, the controller firmware 224 reports to the OS that only the visible region 229 is detected. As a result, the OS does not display the hidden area 228 to the user. Hidden area 228 is accessible only when the user executes transaction application 120 and passes the authorization sequence. Details regarding the authorization sequence can be readily understood by those skilled in the art, so details are not discussed here for the sake of brevity.

  The hidden area 228 stores a virtual account associated with a bank deposit account between the user of the mobile payment device 2 and the bank operating the bank server 5. Data relating to the bank account is stored in the financial data chip 221. In practice, the hidden area 228 can store a plurality of virtual accounts each associated with a plurality of bank deposit accounts.

  Further, referring to FIG. 3A, an embodiment of a method for processing a payment will be described. In the following example, the electronic device 1 can be realized using a computer, and the transaction is the purchase of a ticket for the Taiwan High Speed Rail.

  Initially, the user can operate the electronic device 1 to connect to a website that handles ticket purchases (see FIG. 4). The website may provide the user with an interface for entering transaction information related to the transaction and payment for the transaction. Here, the transaction information includes details relating to travel (for example, information on the user, departure time, departure place, destination, railway fare, etc.).

  After the transaction information is provided by the user, the website provides the user with multiple ways to make payments (eg, payment at a convenience store or railway station, use of a regular credit card or payment card 22). . Here, in this case, the user selects to perform payment using the payment card 22. In response, the processor 11 of the electronic device 1 operates to execute the transaction application 120 (step S11).

  In step S12, the processor 11 receives the transaction information. Thereafter, the processor 11 executes the security function 121 included in the transaction application 120 in order to generate data to be authenticated in step S13 and to invalidate the adjustments made in the transaction information in step S14. Specifically, the data to be authenticated includes transaction information, and after step S14, the user is not allowed to make any changes to the transaction information. Note that steps S13 and S14 can be performed in any order or simultaneously.

  Thereafter, the processor 11 generates a command for the user to connect the portable payment device 2 (provided with the payment card 22) to the electronic device 1 (see FIG. 5). When the processor 11 detects the payment card 22 through the mobile payment device 2 in step S15, the flow proceeds to step S16. Otherwise, the processor 11 is idle until the mobile payment device 2 is connected.

  In step S16, the processor 11 outputs the transaction information again to the user for confirmation via the I / O device 14, and the list of virtual accounts stored in the payment card 22 is selected for the user for selection. To provide. Specifically, payment card 22 may first store a master virtual account associated with the master bank and may store additional member virtual accounts associated with various member banks.

  After selecting one of the virtual accounts, in step S17, the processor 11 outputs a command instructing user input of an access password associated with the payment card 22 (see FIG. 6).

  After receiving the access password (step S18), the processor 11 then transmits the access password to the payment card 22 through the first connection interface 13 and the second connection interface 23. In step S19, the payment card 22 operates to confirm the access password. When the payment card 22 confirms that the access password is correct, the payment card 22 transmits an access permission command to the electronic device 1, and the flow proceeds to step S23. Otherwise, the flow proceeds to step S20 where the payment card 22 sends an access denial command to the electronic device 1, where the payment card 22 counts the number of consecutive events that receive an incorrect access password. To do. When the number is less than a threshold (eg, 3), the flow returns to step S17 to allow the user to enter another access password. Otherwise, the flow proceeds to step S22 where the payment card 22 is locked and access to the payment card 22 is prohibited.

  In step S23, the electronic device 1 clears the temporarily stored access password (received in step S18). This step is performed to prevent the access password from being read by others. This is even more important when public electronic equipment or merchant owned electronic equipment is used to perform the method.

  In step S24, the processor 11 operates to compare the data to be authenticated generated in step S13 with the transaction information confirmed by the user in step S16. When it is determined that the data to be authenticated matches the transaction information, the flow proceeds to step S25. Otherwise, the flow returns to step S12.

  In step S <b> 25, the processor 11 transmits data to be authenticated to the payment card 22. Thereafter, in step S26, the payment card 22 generates a transaction authentication code (TAC) based on the data to be authenticated and the secret key, and transmits the TAC to the electronic device 1.

  More specifically, the payment card 22 stores a master secret key corresponding to the master virtual account in the financial data chip 221. Payment card 22 may store an additional member secret key corresponding to the member virtual account in hidden area 228. As such, the payment card 22 selects a corresponding one of the secret keys (including the master secret key and member secret key) based on the virtual account selected in step S26 for generating the TAC.

  In step S27, the processor 11 executing the transaction software 120 composes a payment command using the TAC. The payment command includes at least transaction information and TAC and is encrypted.

  Referring to FIG. 3B, after step S <b> 27, the electronic device 1 attempts to establish a session with the platform server 3. The session is for providing a secure communication channel between the electronic device 1 and the platform server 3 and confirming the validity of the payment card 22.

  In step A1, the processor 11 executing the transaction application 120 acquires the virtual account used in step S16 from the payment card 22. It should be noted that in other embodiments, various codes or symbols that can identify the user of the mobile payment device 2 can be used.

  In step A <b> 2, the processor 11 transmits a session request to the platform server 3. The session request has a virtual account.

  In step A <b> 3, the platform server 3 generates a session identification (ID) in response to receiving the session request, and transmits the session ID to the electronic apparatus 1. The electronic device 1 receives the session ID, and transmits the session ID to the payment card 22 in step A4.

  In step A5, the payment card 22 operates to generate a first authentication code based on the session ID and the card identification key stored in the hidden area 228 during physical production of the payment card 22. Thereafter, the payment card 22 transmits the first authentication code to the electronic device 1.

  Note that the card identification key is known only to the payment card 22 and the platform server 3 and is not transmitted to the electronic device 1 from the beginning to the end of the method. Furthermore, the generation of the first authentication code is performed in the payment card 22. This ensures that the electronic device 1 cannot intervene in the generation of the first authentication code and cannot generate a valid first authentication code without the card identification key. Therefore, only a valid payment card 22 can generate a valid first authentication code.

  Next, in step A <b> 6, the electronic device 1 transmits a first authentication code to the platform server 3.

  Next, in step A7, the platform server 3 finds the stored user identification key according to the virtual account included in the session request received from the electronic device 1 in step A2. The user identification key corresponds to the card identification key and is dedicated to the virtual account.

  In step A8, the platform server 3 generates a second authentication code based on the session ID generated in step A3 and the user identification key found in step A7.

  In step A9, the platform server 3 determines whether or not the first authentication code received from the electronic device 1 in step A6 matches the second authentication code generated in step A8. When it is determined that the first authentication code matches the second authentication code (ie, the payment card 22 has been issued by a bank), the flow proceeds to step A10. Otherwise, the platform server 3 determines that the payment card 22 has not been able to generate a valid first authentication code (and therefore has not been issued by a bank) and ends the flow.

  In step A10, the platform server 3 sends a session response to the electronic device 1 to establish a session and allow the transaction to proceed.

  Referring to FIG. 3C, after allowing the platform server 3 to proceed with the transaction, in step S28, under the session, the payment command configured in step S27 is sent to the platform server 3 via the communication device 15 by the processor 11. Send to. Specifically, the transmission is performed using a secure socket layer (SSL) protocol. Next, in step S29, the platform server 3 transmits a payment command to the bank system 4 through a dedicated channel.

  In response to receiving the payment command, in step S30, the bank system 4 operates to decrypt the received payment command and verify the validity of the payment card 22 based on the payment command. More specifically, the bank system 4 uses the data to be authenticated included in the payment command by using the same secret key stored in the payment card 22 (for example, the financial data chip 221 or the hidden area 228). To generate a confirmation code. In some embodiments, a secret key for generating a confirmation code can be included in the payment command and transmitted to the bank system 4 by the platform server 3.

  Thereafter, the bank system 4 compares the TAC with the confirmation code. When it is determined that the verification code matches the TAC, the bank system 4 has determined that the payment card 22 is valid and the transaction information has not been changed during the transaction. Thereafter, the flow proceeds to step S31. Otherwise, the flow proceeds to step S36.

  In step S31, the bank system processes the payment according to the transaction information included in the payment command. In this case, the railway fare fee (in this case 160 NT dollars) is withdrawn from the bank account represented by the virtual account and transferred to the account owned by the Taiwan High Speed Rail Company.

  Thereafter, in step S <b> 32, the bank system 4 generates a payment result indicating that the transaction has been processed, and transmits the payment result to the platform server 3.

  Next, in step S33, the payment result is sent to the electronic device 1. The payment results are similar under the session and use the SSL protocol. Thereafter, in step S34, the electronic device 1 can output a warning instructing the user to disconnect the mobile payment device 2 (see FIG. 7).

  The payment result can include authentication information provided to the user in step S35. Authentication information can be used directly at the station when downloaded to a portable device or in the form of a quick response (QR) code or series of codes for use at a convenience store or station to redeem a physical train ticket It can be in the form of an electronic railroad ticket.

  When it is determined in step S30 that the confirmation code does not match the TAC, the bank system 4 determines that the payment card 22 is not valid or the transaction information has been changed during transmission. As a result, in step S36, the bank system 4 generates an error message and transmits the seller message to the platform server 3. In step S37, the platform server 3 sends an error message to the electronic device 1, and the electronic device 1 outputs the error message in step S38. As a result, the transaction is not processed.

  The method described above can be employed in places such as retail stores. In such a case, when the customer purchases goods and / or services, the merchant can operate the electronic device 1 (eg, a personal computer) to execute the transaction application (step S11). In step S12, transaction information can be entered into the electronic device 1 by scanning, for example, a bar code associated with the goods and / or services. Thereafter, the customer provides the merchant with the portable payment device 2 having the payment card 22 in step S15, confirms the transaction information in step S16, and provides the access password to the electronic device 1 in step S17.

  The electronic device 1 automatically executes subsequent steps together with the platform server 3 and the bank system 4. Thereafter, in step S34, the payment is processed, and the customer can search the mobile payment device 2 and obtain the goods / services.

  For example, the method can be applied when goods / services are provided to customers by delivery and payment is made after goods / services are delivered. The delivery staff carries the electronic device 1 having the first connection interface 13 and the transaction application 120 installed, and operates the electronic device 1 to execute the method after the customer confirms the goods / services. be able to. As a result, delivery personnel do not need to have cash during the visit.

  The method can also be applied when goods / services are provided to customers by vending machines. After payment is made in step S35, the vending machine provides the merchandise.

  Furthermore, the portable payment device 2 can be used with an automatic teller machine to withdraw cash from a bank deposit account. In such cases, after the method is executed, the ATM pays cash to the customer.

  In some embodiments, payment card 22 may be configured to store additional data (eg, medical health information, license or identification information, member information, etc.) in storage device 225. Additional data can be stored in the storage device 225 by the electronic device 1 executing the application 120, and the application 120 can further perform a personalization process (referred to as a “persono process”).

  Assume that in the personal process, the data stored on the payment card 22 needs to be processed using different security levels (eg, bank account information may require a higher security level than other general information). unknown.). As a result, the payment card 22 of the present invention is also configured to provide more secure and more applicable data management.

  In some embodiments, the hidden area 228 of the payment card 22 is divided into a plurality of hidden data blocks. Each of the hidden data blocks is associated with a storage security level and is configured to store personalization data of a predetermined data type. As a result, for each hidden data block, the controller chip 222 is configured to execute a personal process that stores personalization data along with a predetermined one of a plurality of security mechanisms corresponding to the storage security level. .

  In the example shown in FIG. 8, the hidden area 228 of the payment card 22 is divided into eight hidden data blocks (5A to 5H) for the input data. Specifically, the hidden data block 5A is for storing first-aid information about the user of the payment card 22 such as the user's (one or more) emergency contact information, major medical history, allergies to drugs, and the like.

  The hidden data block 5B is for storing basic health and medical information about the user such as the user's health checkup and blood test results, and medical records (EMR) by electronic devices.

  The hidden data block 5C is for storing electronic personal documents and licenses held by users and / or relatives such as identification cards, passports, and driver's licenses.

  The hidden data block 5D is for storing an electronic ticket such as a prepaid railway ticket or event ticket, an electronic invoice, and a receipt. The hidden data block 5E confirms the user's private data.

  The hidden data block 5F is for storing registration data of users of various social organizations. The hidden data block 5G is for storing account information of users of various banks. The hidden data block 5H is for storing other information.

  For example, four different security mechanisms are provided to implement personal processes for different storage security levels. In addition, parties can have authorization to access a portion of the hidden data block based on the security level.

  In different security mechanisms, payment card 22 may be required to establish communications with various third parties to obtain permission to implement the personalization process.

  Specifically, in each of the securing mechanisms, the payment card 22 is required to communicate with the platform server 3 that stores at least part of the authorization information and / or personalization data for authorizing the personal process. .

  In some securitization mechanisms, the payment card 22 may interact with other third parties such as authorized organization servers 32, cooperating organization servers 33 or banking systems 4 to obtain other parts of the authorization information. It is further required to perform the communication.

  The authorized organization server 32 can be operated by a third party authorized by the platform server 3 to provide information related to the personal process. The cooperating organization server 33 is operated by a third party cooperating with the platform server 3 to generate information related to the personal process.

  In some of the security mechanisms, user input of personalization data is allowed (ie, personalization data can be received from applicon 120 via controller firmware 224 and API 223), while other security In the ring mechanism, personalization data is received from a third party and cannot be changed by the user.

  For example, in the example shown in FIG. 8, for the hidden data block 5A, personalization data can be entered / changed by the user and access to it can be granted to everyone. For hidden data blocks 5C-5E, personalization data can be entered / changed by the user and the personalization data can only be accessed by the user. For hidden data blocks 5B, 5F and 5G, personalization data is received from a third party (ie, the user cannot modify the data) and the personalization data is accessible only by the user. For the hidden data block 5H, personalization data can be received from a third party and access to it can be granted to everyone.

  In the present embodiment, each of the hidden data blocks (5A-5H) is further divided into a plurality of hidden data sub-blocks for storing personalization data (eg, hidden data sub-blocks under the hidden data block 5G). Each of the blocks stores the registered data and account number of a particular bank.) Note that all hidden data sub-blocks under a particular hidden data block are associated with the same security level and use the same security mechanism.

  In other embodiments, additional hidden data blocks can be further divided and existing hidden data sub-blocks can be used to store various other information. Additional security mechanisms can also be provided.

  In use, the system portion 226 of the payment card 22 can maintain a hidden data sub-block list 61 and a hidden data sub-block sub-list 62 under each of the hidden data sub-blocks 5A-5H. For each of the hidden data sub-blocks, a specific personal process is performed to store the personalization data in the hidden data sub-block.

  Referring to FIG. 9, the personal process includes a registration step, a formatting step, and a personalization step.

  In the registration step, payment card 22 designates one of hidden data blocks 5A-5H and assigns one of the hidden data sub-blocks to be used for storing personalization data.

  In the formatting step, the designated hidden data block of the hidden data blocks 5A-5H is formatted to match a predetermined data type to allow storing personalization data therein.

  In the personalization step, the payment card 22 stores the personalization data in the designated hidden data blocks (5A-5H) of the hidden data blocks (5A-5H).

  In this embodiment, each of the hidden data sub-blocks stores a preset registration ID / password combination to allow the registration step and a preset format ID / password combination to allow the formatting step. The

  Before executing the registration step of the personal process, the payment card 22 receives the ID / password combination that permits registration, and the ID / password combination that permits registration matches the preset registration ID / password combination. The registration step is executed only when Similarly, before performing the formatting step of the personal process, payment card 22 receives the format authorization ID / password combination, and the format authorization ID / password combination matches the previously set format ID / password combination. Only when the registration step is executed.

  Further, with reference to FIGS. 1 and 10, the personal process realized by the first securing mechanism will be described in detail.

  In step S40, the user operates the application 120 of the computer device 1, and the computer device 1 starts the personal process in step S41 in response thereto. In step S42, the user selects one of the hidden data blocks (5A to 5H) according to the type of data stored in the payment card 22 and the hidden data block selected from the hidden data block (5A to 5H). Select one of the blocks. In response to the selection, the payment card 22 specifies the selected hidden data block of the hidden data blocks (5A-5H) and the selected hidden data sub-block of the hidden data sub-blocks. For example, one of the hidden data sub-blocks of the hidden data block (5H) is designated to be subject to a personal process.

  In step S43, the user is instructed to enter an activation password. Thereafter, the computer device 1 that receives the activation password transmits the activation password to the payment card 22 in step S44. In step S45, the payment card 22 determines whether the activation password is correct. When it is determined that the activation password is correct, the flow proceeds to step S46. Otherwise, the flow ends.

  In step S46, the computer apparatus 1 communicates with the platform server 3 to request a registration permission ID / password combination corresponding to the designated hidden data sub-block. In step S47, the platform server 3 determines, for the registration step, for example whether the payment card 22 has been authorized by a third party associated with the hidden data block (5H). When the payment card 22 determines that the registration step is permitted, the flow proceeds to step S48. If not, end the process.

  In step S <b> 48, the platform server 3 transmits the registration permission ID / password combination and other related information corresponding to the designated hidden data sub-block to the computer device 1. Thereafter, the computer device 1 uses the registration permission ID / password combination to transmit the registration command to the payment card 22 in step S49.

  In response to receiving the registration command at step S50, the payment card 22 compares the received registration permission ID / password combination with the previously set registration ID / password combination at step S51. / Determine whether the password combination is correct. When it is determined that the registration ID / password combination matches the previously set registration ID / password combination, the flow proceeds to step S52. If not, end the process.

  In step S52, the payment card 22 physically assigns the designated hidden data sub-block in the hidden data block 5H, and stores related information in the designated hidden data sub-block. More specifically, the controller firmware 224 transmits related information to the controller chip 222, and the controller chip 222 identifies the physical address of the specified hidden data sub-block via the list 61, and identifies the identified physical data. Write relevant information to the address, thereby completing the registration step.

  The process then proceeds to the formatting step. In step S53, the computer device 1 communicates with the platform server 3 to request a format permission ID / password combination corresponding to the designated hidden data sub-block. In step S54, the platform server 3 determines whether or not to allow the payment card 22 to format. When the payment card 22 determines that the formatting step is allowed, for example by a third party associated with the hidden data block (5H), the flow proceeds to step S55. If not, end the process.

  In step S55, the platform server 3 sends the format permission ID / password combination and personalization information corresponding to the designated hidden data sub-block to the computer device 1, and then the computer device 1 in step S56. The format authorization ID / password combination is used to send a command to the payment card 22.

  In response, the payment card 22 receives the format permission ID / password combination from the computer device 1 in step S57, and then, in step S58, the format permission ID in which the received format permission ID / password combination is set in advance. By comparing with the ID / password combination, it is determined whether or not the format permission ID / password combination is correct. When it is determined that the format permission ID / password combination set in advance matches the format permission ID / password combination, the flow proceeds to step S59. If not, end the process.

  In step S59, the payment card 22 formats the designated hidden data sub-block and stores the personalization data in the designated hidden data sub-block.

  In the present embodiment, the list 61 is also updated to reflect the personal process.

  FIG. 11 shows the steps of the personal process using the second securing mechanism. In the example shown in FIG. 11, the user can try to input the membership information of the user of the club named “X1” to the payment card 22, and as a result, one of the hidden data sub-blocks of the hidden data block 5F. Is subject to a personalization process.

  In this example, the registration steps (ie, steps S41 to S52) are performed in the same manner as the registration steps using the first securing mechanism, and details thereof are omitted here for the sake of brevity.

  The main differences between the use of the first and second securing mechanisms are as follows. In step S53, the computing device 1 is authorized to the organization server 32 (in this case, the server operated by the club X1) to request the format authorization ID / password combination corresponding to the designated hidden data sub-block. Communicate with. The authorized organization server 32 determines whether or not to permit the payment card 22 to perform the formatting step in step S54 instead of the platform server 3.

  In addition, the personalization data in this case does not attempt to reveal to everyone for access, so to block unauthorized access attempts against the specified hidden data sub-block. Access ID / password combinations can be further assigned.

  FIGS. 13A and 13B show the steps of the personal process using a third securing mechanism. In the example as shown in FIGS. 13A and 13B, the user can try to enter bank account information, which results in imposing a personal process on one of the hidden data sub-blocks of the hidden data block 5G. .

  In this example, the registration steps (ie, steps S41-S52) are performed in the same manner as the registration steps using the first and second security mechanisms, so that details are here for brevity. I will omit it.

  The main difference between the use of the first and third securing mechanisms is as follows.

  The format permission ID / password combination used in the formatting step is generated cooperatively by the platform server 3 and the cooperative organization server 33 (in this case, a server operated by a third party other than the bank system 4).

  The generation of the format permission ID / password combination can be performed using the steps shown in FIG. In step S61, the bank system 4 transmits a request for data necessary to generate a format permission ID / password combination to both the platform server 3 and the cooperating organization server 33. In response, platform server 3 and cooperating organization server 33 each return some of the data required to generate the format authorization ID / password combination to bank system 4 in steps S62 and S63, respectively. Thereafter, in step S64, the bank system 4 uses the received data to generate a format permission ID / password combination.

  Thereafter, in the formatting step (as shown in FIG. 13A), in step S53, the computer device 1 requests a format permission ID / password combination from the bank system 4. Thereafter, in step S71, the bank system 4 inquires from the platform server 3 and the cooperating organization server 33 whether the formatting step is permitted.

  In response thereto (see FIG. 13B), the platform server 3 and the cooperating organization server 33 each determine in step S72a and step S72b whether the formatting step is allowed. More specifically, when it is determined that the formatting step is not permitted for each of the platform server 3 and the cooperative organization server 33, a negative response is transmitted to the bank system 4 (steps S73a and S73b). On the other hand, when it is determined that the formatting step is permitted, an acknowledgment is transmitted to the bank system 4 (steps S74a and S74b). Note that personalization data is also sent to the banking system 4 in step S74b when the cooperating organization server 33 determines that the formatting step is allowed.

  The bank system 4 receives the response in step S75, determines whether both responses are positive in step S76, and proceeds to step S77 when both responses are positive. When at least one of the responses is negative, in step S78, the bank system 4 returns the response to the computer device 1 to inform the end of the process.

  In step S77, the bank system 4 acquires the format permission ID / password combination generated in step S64, and transmits the format permission ID / password combination to the computer apparatus 1 together with the personalization data in step S79. Thereafter, the computer apparatus 1 continues the personal process as described above.

  FIG. 14 shows the steps of the personal process using the fourth securing mechanism. In the example shown in FIG. 14, the user can try to input the user's first aid information to the payment card 22, and as a result, a personal process is imposed on one of the hidden data sub-blocks of the hidden data block 5A. .

  In this example, the registration steps (ie, steps S41 to S52) are performed in the same manner as the registration steps using the first securing mechanism, and details thereof are omitted here for the sake of brevity.

  The main differences between the use of the first and the fourth security mechanism are as follows. In step S <b> 53, the computer device 1 does not request personalization data from the platform server 3. Instead, after the payment card 22 is formatted in step S59, the computing device 1 permits the user to input first aid information in step S81. Thereafter, in step S82, the computer apparatus 1 stores first aid information (used as personalization data) in the designated hidden data sub-block of the hidden data block 5A.

  Note that when receiving personalization data from the platform server 3, the received personalization data may have an access code for the next access of the designated hidden data sub-block (5A). If personalization data is entered by the user, the access code is also determined by the user. Thus, after completing the personal process, the hidden data sub-block is assigned a specific access level based on the security mechanism used.

  For example, anyone holding the payment card 22 is allowed to read the hidden data sub-block of the hidden data block 5A, but only the user is allowed to write the hidden data sub-block of the hidden data block 5A.

  The user is allowed to read the hidden data sub-blocks of the hidden data blocks 5B and 5F, but only the authorized organization (hospital or social organization) is allowed to write the hidden data sub-blocks of the hidden data blocks 5B and 5F. Is done.

  The user is allowed to read and write the hidden data sub-blocks of the hidden data blocks 5C to 5E.

  The user is allowed to read the hidden data sub-block of the hidden data block 5G, but only the cooperating organization (bank) is allowed to write the hidden data sub-block of the hidden data block 5G.

  Anyone who holds the payment card 22 is allowed to read the hidden data sub-block of the hidden data block 5H, but only the platform server 3 is allowed to write the hidden data sub-block of the hidden data block 5H.

  In summary, the method of the present invention does not require the merchant to provide a specific processing device in order to use a normal credit card. Since the portable payment device 2 is realized using a plug and play device, any electronic device that has the first connection interface 13 and has the transaction application 120 installed can be used as the electronic device 1. As a result, the method is useful for extending the use of the payment card 22 when a normal credit card is not applicable. Further, the hidden area 228 of the payment card 22 can be divided into a plurality of hidden data blocks, each associated with a storage security level. Each of the hidden data blocks can be further divided into a plurality of hidden data sub-blocks, each requiring a personalization process to be activated. As a result, the hidden area 228 can be considered an extended information bank with improved security.

Claims (16)

In a method for processing a payment carried out using an electronic device (1) removably connected to a portable payment device (2) and communicating with a bank server (5), the portable payment device (2) comprises: A plug-and-play device and a payment card (22),
(A) receiving, by the electronic device (1), transaction information related to transactions and payments for transactions;
(B) accessing the payment card (22) by the electronic device (1) via the portable payment device (2);
(C) cooperating with the payment card (22) by the electronic device (1) to generate a payment command including at least transaction information;
(D) Establishing a session with the bank server (5) by the electronic device (1), the session between the electronic device (1) and the bank server (5). Providing a secure communication channel;
(E) sending a payment command by the electronic device (1) to the bank server (5) under the session established in step (d), wherein the bank server (5) Transaction information included in the payment command after confirming the validity of the payment card (22) based on the payment command in response to receiving the payment command and confirming that the payment card (22) is valid Steps configured to process payments according to:
(F) receiving a payment result from the bank server (5) under the session established in the step (d) by the electronic device (1), wherein the payment result is a payment Generated by said bank server (5) after completion;
Equipped with a,
Step (d)
(D1) A sub-step of acquiring a virtual account from the payment card (22) by the electronic device (1), the virtual account being a user of the mobile payment device (2) and a server (5 of the bank) Sub-steps associated with the bank account that is between and operating the bank and used for the payment;
(D2) a substep of sending a session request to the bank server (5) by the electronic device (1), wherein the session request comprises the virtual account;
(D3) generating a session identification (ID) in response to receipt of the session request by the bank server (5) and transmitting the session ID to the electronic device (1);
(D4) A sub-step of transmitting the session ID to the payment card (22) by the electronic device (1), wherein the payment card (22) uses a first authentication code based on the session ID. And a sub-step configured to generate a card identification key stored in the payment card (22) and send the first authentication code to the electronic device (1);
(D5) a sub-step of transmitting the first authentication code to the bank server (5) by the electronic device (1);
(D6) a sub-step of finding a stored user identification key by the bank server (5) according to the virtual account included in the session request received from the electronic device (1) in sub-step (d2). The user identification key corresponds to the card identification key and is dedicated to the virtual account;
(D7) Sub-step of generating a second authentication code by the bank server (5) based on the session ID generated in sub-step (d3) and the user identification key found in sub-step (d6) When,
(D8) The first authentication code received from the electronic device (1) in sub-step (d5) by the bank server (5) matches the second authentication code generated in sub-step (d7). A sub-step for deciding whether to
(D9) A session response is sent by the bank server (5) to establish the session when the sub-step (d8) determines that the first authentication code matches the second authentication code. Transmitting to the electronic device (1),
Method characterized by having a. In a method for processing a payment carried out using an electronic device (1) removably connected to a portable payment device (2) and communicating with a bank server (5), the portable payment device (2) comprises: A plug-and-play device and a payment card (22),
(A) receiving, by the electronic device (1), transaction information related to transactions and payments for transactions;
(B) accessing the payment card (22) by the electronic device (1) via the portable payment device (2);
(C) cooperating with the payment card (22) by the electronic device (1) to generate a payment command including at least transaction information;
(D) Establishing a session with the bank server (5) by the electronic device (1), the session between the electronic device (1) and the bank server (5). Providing a secure communication channel;
(E) sending a payment command by the electronic device (1) to the bank server (5) under the session established in step (d), wherein the bank server (5) Transaction information included in the payment command after confirming the validity of the payment card (22) based on the payment command in response to receiving the payment command and confirming that the payment card (22) is valid Steps configured to process payments according to:
(F) receiving a payment result from the bank server (5) under the session established in the step (d) by the electronic device (1), wherein the payment result is a payment Generated by said bank server (5) after completion;
With
Step (b)
(B1) determining whether the payment card (22) is detected by the electronic device (1) when the portable payment device (2) is connected to the electronic device (1);
(B2) in response to the determination that the payment card (22) has been detected, outputting a command by the electronic device (1) requesting the user to enter an access password;
(B3) In response to receiving the access password, the electronic device (1) transmits the access password to the payment card (22), wherein the payment card (22) And configured to send an access permission instruction to the electronic device (1) when the access password is correct;
(B4) temporarily clearing the stored access password by the electronic device (1) in response to receiving the access permission command;
How it characterized in that it has a. Step (c)
(C1) Sub-step of transmitting data to be authenticated to the payment card (22) by the electronic device (1), the data to be authenticated having the transaction information, and the payment card (22) Is configured to generate a transaction authentication code (TAC) based on the data to be authenticated and to send the TAC to the electronic device (1);
(C2) Substep of configuring the payment command using the TAC by the electronic device (1);
The method according to claim 1, wherein the method comprises: The payment card (22) is configured to generate the TAC using a secret key stored in the payment card (22). In step (e), the bank server (5)
Using the same secret key, generate a confirmation code using the data to be authenticated included in the payment command,
By comparing the TAC and the confirmation code,
4. Method according to claim 3, characterized in that the validity of the payment card (22) is confirmed. 5. The method according to any one of claims 1 to 4 , further comprising the step of invalidating adjustments made in the transaction information after step (a). A system (1) having an electronic device (1), wherein the electronic device (1)
A processor (11);
A storage device (12) coupled to the processor (11) for storing a transaction application (120);
A first connection interface (13) coupled to the processor (11);
A communication device (15) coupled to the processor (11) and configured to communicate with a bank server (5);
A portable payment device (2) that is a plug and play device and is detachably connected to the electronic device (1), wherein the portable payment device (2)
A card slot (201) provided with a card interface for containing a payment card (22);
A second connection electrically connecting to the first connection interface (13) of the electronic device (1) to allow access to the payment card (22) using the electronic device (1); In a system (100) having an interface (23),
When the transaction application (120) is executed by the processor (11), the electronic device (1) is placed on the payment card (1) to perform the method of any one of claims 1 and 2. 22) and the system (100) characterized by cooperating with the bank server (5). The electronic device (1) is an automated teller machine (ATM), according to claim 6, further comprising at least cash dispenser output having an (I / O) device (14) System (100). The electronic device (1) is a vending machine, in claim 6, characterized by further comprising input and output having at least a physical / virtual buttons and items dispenser (I / O) device (14) The described system (100). A processor (11);
A storage device (12) coupled to the processor (11) for storing a transaction application (120);
A first connection interface (13) coupled to the processor (11) for releasably coupling to a portable payment device (2) provided with a payment card (22);
A communication device (15) coupled to the processor (11) and configured to communicate with a bank server (5);
In an electronic device (1) having
When the transaction application (120) is executed by the processor (11), the electronic device (1) is placed on the payment card (1) to perform the method of any one of claims 1 and 2. 22) and an electronic device (1) characterized by cooperating with the bank server (5). The electronic device (1) is an automated teller machine (ATM), according to claim 9, further comprising at least cash dispenser output having an (I / O) device (14) Electronic device (1). The electronic device (1) is a vending machine, to claim 9, characterized by further comprising input and output having at least a physical / virtual buttons and items dispenser (I / O) device (14) The electronic device (1) described. A payment card (22) coupled to an electronic device (1), wherein the electronic device (1) executes an application (120) to perform a personalization process on the payment card (22). The payment card (22)
A control module (220) having a controller chip (222), controller firmware (224) and application program interface (API) (223);
A storage device (225) having a hidden area (228) that can access the application (120) via the controller firmware (224) and the API (223) only after a predetermined authorization sequence has been performed;
In a payment card (22) having
The hidden area (228) is divided into a plurality of hidden data blocks (5A-5H), and each of the hidden data blocks (5A-5H) is associated with a storage security level and has a predetermined data type. Configured to store personalization data for
For each of the hidden data blocks (5A to 5H), the controller chip (222) determines a predetermined securing mechanism among a plurality of secured mechanisms corresponding to the storage security level of the hidden data block. A payment card (22), characterized in that it is configured to perform a personalization process for storing said personalization data. The personalization process is:
A registration step of selecting one of the hidden data blocks (5A-5H) for use in storing the personalization data;
Formatting a specified hidden data block of the hidden data blocks (5A-5H) to match the predetermined data type in order to be able to store the personalization data; ,
A personalization step in which the payment card (22) stores the personalization data in a designated hidden data block of the hidden data blocks (5A-5H);
13. A payment card (22) according to claim 12 , characterized in that Each of the hidden data blocks (5A-5H) is divided into a plurality of hidden data sub-blocks, and in the registration step, the payment card (22) is used for storing the personalization data. Further specifying one of the hidden data sub-blocks of the designated hidden data block among the hidden data blocks (5A to 5H), and in the formatting step, the designated hidden of the hidden data sub-blocks Format the data sub-block,
Each of the hidden data sub-blocks stores a preset registration ID / password combination to allow the registration step and a preset format ID / password combination to allow the formatting step;
The payment card (22) receives the registration permission ID / password combination and executes the registration step only when the registration permission ID / password combination matches the previously set registration permission ID / password combination. ,
The payment card (22) receives the format permission ID / password combination and executes the formatting step only when the format permission ID / password combination matches the previously set format permission ID / password combination. 14. Payment card (22) according to claim 13 , characterized in that The payment card (22) performs the personalization process according to one of a first, a second, a third and a fourth securing mechanism;
Receiving the registration permission ID / password combination, the format permission ID / password combination and the personalization data from the platform server (3) in the first securing mechanism;
In the second security mechanism, the registration permission ID / password combination and the personalization data are received from the platform server (3), and the format permission ID / password combination is received from the format permission ID / password. Receiving from an authorized organization server (32) authorized by the platform server (3) to provide a combination;
Receiving the registration authorization ID / password combination and the personalization data from the platform server (3) in the third securing mechanism, and receiving the format authorization ID / password combination from a third party; The format authorization ID / password combination is generated in cooperation by the platform server (3) and a cooperating organization server (33);
In the fourth security mechanism, the registration permission ID / password combination and the format permission ID / password combination are received from the platform server (3), and the personalization data is received from the controller firmware (224) and 15. Payment card (22) according to claim 14 , characterized in that it is received from the application (120) via the API (223). The registration step includes:
In response to receiving a registration command, a sub-step for designating a hidden data sub-block divided from one of the hidden data blocks (5A-5H);
Receiving a format authorization ID / password combination from a first party operating under one of the Securing Mechanisms of a designated hidden data block of the hidden data blocks (5A-5H);
Have
When the formatting step determines that the received format permission ID / password combination matches a previously set format permission ID / password combination, the designated hidden data sub-block is formatted;
14. The payment card (22) of claim 13 , wherein in the personalization step, the personalization data is stored in the designated hidden data sub-block.

Images