CN106157037B - Mobile payment method and mobile payment equipment - Google Patents

Abstract

A mobile payment method is executed by a computer device and includes: receiving a transaction list, establishing a wireless short-range communication with a mobile device having a payment card, and transmitting the transaction list to the mobile device via the wireless short-range communication. And receive a payment instruction from the mobile device, the payment instruction is generated by the mobile device based on the transaction list, transmit the payment instruction to the payment institution server, and receive a payment result from the payment institution server. The payment instruction causes the payment institution server to identify the correctness of the payment card and process the payment. The payment result is generated by the payment institution server after completing the payment. In this way, losses caused by fraudulent payments or mismatched transaction records can be avoided.

Description

Mobile payment method and mobile payment device

technical field

The invention relates to a mobile payment method and a mobile payment device, in particular to a mobile payment method and a mobile payment device for realizing transaction security payment by using near field communication.

Background technique

Electronic wallets or plastic currency such as bank cards, credit cards, debit cards or smart cards, etc., all require computer systems and digital stored value systems to achieve functions such as adding value and transferring money. Since the use of electronic wallets or plastic currency can reduce the need for customers to carry too much cash when shopping, and the store does not have to check the correct amount of cash when customers pay, it can improve the efficiency and convenience of transaction behavior. . Therefore, in recent years, electronic wallets have been widely accepted and used.

However, the existing traditional contactless stored-value smart cards usually lack the function of card authentication, or the card authentication measures are insufficient. Once the card is counterfeited, the store owner can only bear the risk of loss.

In addition, when using the traditional contactless stored-value smart card for shopping and payment, the transaction record generated by each purchase is usually stored at the store side, but the transaction record is not immediately transmitted to the card issuing unit or payment institution. to verify the authenticity of the stored-value smart card and request payment. But after the end of one business day, the whole batch of transaction records will be sent to the card issuing unit or payment institution to request payment, which means that the whole batch is settled. When the batch settlement procedure is not timely enough, the store owner completes the transaction without the card issuing unit or payment institution verifying the authenticity of the stored-value smart card used for each purchase, which will expose the store owner to at the risk of loss.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a mobile payment method and a mobile payment device that allow timely processing of transactions and ensure transaction security.

The mobile payment method of the present invention is executed by a computer device, which can interact with a mobile device having a payment card, and the computer device communicates with a payment institution server. The mobile payment method includes:

receiving a list of transactions related to a transaction and a payment related to the transaction;

establishing a wireless short-range communication with the mobile device;

transmitting the transaction list to the mobile device via the wireless short-range communication;

receiving a payment instruction from the mobile device via the wireless short-range communication, the payment instruction being generated by the mobile device based on at least the transaction list;

establishing a session mechanism with the payment institution server, the session mechanism providing a secure communication channel between the computer device and the payment institution server;

The payment instruction is transmitted to the payment institution server under the session mechanism, the payment instruction enables the payment institution server to recognize the correctness of the payment card based on the payment instruction when receiving the payment instruction, and the payment institution server recognizes the correctness of the payment card. After the payment card is correct, the payment instruction also causes the payment institution server to process the payment according to the transaction list included in the payment instruction; and

A payment result from the payment institution server is received under the session mechanism, the payment result is generated by the payment institution server after the payment is completed.

The mobile payment method of the present invention is executed by a mobile device having a payment card, and the mobile device can interact with a computer device. The mobile device and the computer device communicate with a payment institution server. The mobile payment method includes:

establishing a wireless short-range communication with the computer device;

receiving, via the wireless short-range communication, a transaction list from the computer device, the transaction list relating to a transaction and a payment for the transaction;

Generate a payment instruction based on at least the transaction list, and transmit the payment instruction to the computer device via the wireless short-range communication, the payment instruction is provided by the computer device to the payment institution server, and the payment instruction causes the payment institution server to When the payment instruction is received, the correctness of the payment card is identified based on the payment instruction, and after the payment institution server recognizes that the payment card is correct, the payment instruction also causes the payment institution server to perform the transaction according to the transaction included in the payment instruction. list to process the payment; and

A payment result is received from the payment institution server, the payment result generated by the payment institution server after completing the payment.

The mobile payment device of the present invention can interact with a computer device, the computer device communicates with a payment institution server, the mobile payment device includes a mobile device, and the mobile device includes a processor, a memory unit, a card slot slot, a short-range communication unit and a communication unit. The memory unit is coupled to the processor and stores a payment software. The card slot is coupled to the processor and is removably inserted with a payment card, whereby the mobile device can be used to access the payment card. The short-range communication unit is coupled to the processor and can communicate with the computer device. The communication unit is coupled to the processor and can communicate with the payment institution server. When the processor executes the payment software, the payment software causes the mobile payment device to:

establish a wireless short-range communication with the computer device,

receiving a transaction list from the computer device via the wireless short-range communication, the transaction list relating to a transaction and a payment for the transaction,

Generate a payment instruction based on at least the transaction list, and transmit the payment instruction to the computer device via the wireless short-range communication, the payment instruction is provided by the computer device to the payment institution server, and the payment instruction causes the payment institution server to When the payment instruction is received, the correctness of the payment card is identified based on the payment instruction, and after the payment institution server recognizes that the payment card is correct, the payment instruction also causes the payment institution server to perform the transaction according to the transaction included in the payment instruction. list to process the payment, and

A payment result is received from the payment institution server, the payment result generated by the payment institution server after completing the payment.

The beneficial effects of the present invention are: by identifying the correctness of the payment card based on the payment instruction generated by the mobile device, the payment behavior of using a fake card can be detected. Furthermore, by instantly transmitting the payment instruction corresponding to the transaction list to the payment institution server, the payment of each transaction can be processed in time. In this way, losses caused by fraudulent payments or mismatched transaction records can be avoided.

Description of drawings

1 is a block diagram illustrating a system including a computer device and a mobile payment device;

2 is a schematic diagram illustrating that the mobile payment device can communicate with different computer devices;

3A to FIG. 3C are a flow chart illustrating the flow steps of the mobile payment method of the present invention; and

4 to 12 illustrate various messages output by the input/output module of the computer device and the input/output unit of the mobile device in different stages of the mobile payment method;

Figure 13 is a block diagram illustrating a memory cell of a payment card of the present invention;

Figure 14 is a flow chart illustrating the flow steps of the personalization operation of the payment card of the present invention;

Figure 15 is a flow chart illustrating the flow steps of a personalization operation using the first security mechanism;

16 is a flow chart illustrating the flow steps of a personalization job using the second security mechanism;

17 is a flow chart illustrating a payment institution system cooperating with a platform-side server and a partner organization server to generate information for implementing a personalization operation of the third security mechanism;

18A and 18B are respectively a flow chart illustrating the flow steps of the personalization operation using the third security mechanism; and

19A and 19B are a flowchart illustrating the flow steps of a personalization operation using the fourth security mechanism.

Detailed ways

The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

Referring to FIG. 1, a system 100 is adapted to implement a mobile payment method that processes a payment related to a transaction. The system 100 includes a computer device 1 and a mobile payment device 2. For example, the computer device 1 is held by a store, and the mobile payment device 2 is held by a consumer. The mobile payment device 2 includes a mobile device 20 and a payment card 22 . The payment card 22 is removably inserted into a card slot 26 of the mobile device 20 . The computer device 1 can interact with the mobile device 20 with the payment card 22 . The computer device 1 and the mobile device 20 can communicate with a payment institution server 5 .

In this embodiment, the computer device 1 may be one of a personal computer, a notebook computer, a tablet computer, a smart phone, and a mobile electronic device (see FIG. 2 ). The computer device 1 needs to have a network connection function to execute a transaction software 120, and the transaction software 120 can enable the computer device 1 to execute the mobile payment method of the present invention.

The payment institution server 5 is operated by a payment institution that issues payment cards to consumers. In this embodiment, the payment institution server 5 includes a platform server 3 and a payment institution system 4 , the platform server 3 is used for communicating with the computer device 1 and the mobile device 20 , and the payment institution system 4 is coupled to the platform server 3 . In different implementation aspects, the platform-side server 3 and the payment institution system 4 may be integrated into one device (for example, a server), or may be implemented as two separate devices, and the two separate devices pass through a dedicated channel or session. mechanism communication. Taking the latter of the aforementioned two implementation aspects as an example, the platform server 3 may be operated by a third party (not a payment institution).

Referring to FIG. 1, the computer device 1 includes a memory module 12 storing the transaction software 120, a near field communication module 13, an input/output module 14, a communication module 15, and a memory module 12, The near field communication module 13 , the input/output module 14 and the processing module 11 of the communication module 15 .

In this embodiment, the computer device 1 having the near field communication module 13 has a near field communication function, and the near field communication module 13 is an external device connected to the computer device 1 , such as an external USB near field communication device (dongle). ) or a USB NFC reader. In another embodiment, the near field communication module 13 may be a built-in module embedded in the computer device 1 . The input/output module 14 may include a mouse/keyboard, a touch screen or a speaker/display, etc., but not limited thereto. The communication module 15 enables the computer device 1 to establish communication with the payment institution server 5 .

The mobile payment device 2 can interact with the computer device 1 . The mobile device 20 of the mobile payment device 2 may be a smart phone or a tablet computer or the like. The mobile device 20 includes a memory unit 27, a card slot 26, an input/output unit 24, a short-range communication unit (such as a near field communication unit 23), a communication unit 25, and a communication unit coupled to the near field communication unit 23 , input/output unit 24 , communication unit 25 , card slot 26 and processor 21 of memory unit 27 . The memory unit 27 stores a payment software 270 and a personalization application 271 . The card slot 26 is for removably inserting the payment card 22 so that the mobile device 20 can access the payment card 22 . The near field communication unit 23 can communicate with the computer device 1 . The communication unit 25 can communicate with the payment institution server 5. In another embodiment, the payment card 22 may be coupled to an interface device such that the mobile device 20 can access the payment card 22 via the interface device, and the interface device is coupled to the mobile device 20 via a USB interface. Mobile device 20 .

In this embodiment, the near field communication unit 23 supports the near field communication function. The input/output unit 24 may include a mouse/keyboard, a touch screen or a speaker/display, etc., but is not limited thereto. The processor 21 of the mobile device 20 executes the payment software 270 stored in the memory unit 27 , and the payment software 270 enables the mobile device 20 to cooperate with the payment card 22 to execute the mobile payment method of the present invention.

When the computer device 1 and the mobile device 20 are adjacent to each other for near field communication payment, the computer device 1 and the mobile device 20 can establish wireless short-range communication (such as near field communication) via the near field communication module 13 and the near field communication unit 23 ).

In this embodiment, the payment card 22 is implemented as an SD card. The payment card 22 includes a control module 220 , a financial chip 221 and a storage unit 225 . The financial chip 221 conforms to the FISC II specification.

The control module 220 includes a controller chip 222 , a control firmware 224 contained in a ROM (read-only memory, not shown), and an application program interface (API) 223 . The aforementioned controller chip 222 and ROM can be integrated using an integrated circuit package, and are in parallel with the memory unit 225 .

When the payment card 22 is inserted into the card slot 26 , the processor 21 can access the financial chip 221 and the storage unit 225 via the control firmware 224 . The application program interface 223 and the control firmware 224 can operate according to the instructions of the payment software 270 or the personalization application program 271 . The application program interface 223 can use algorithms such as 3DES (Triple Data Encryption Algorithmsymmetric-key block cipher), AES (Advanced Encryption Standard) or RSA for encryption.

系统举例来说，可视区 229能被档案管理程序(file management program)访问。The storage unit 225 includes a system part 226 and a storage part 227 . The system part 226 has built-in basic operation information. The storage part 227 includes a secret data area 228 and a visible area 229 . The viewable area 229 allows access by the operating system (OS) of the mobile device 20 . by

For example, the viewable area 229 can be accessed by a file management program.

The operating system cannot access the secret data area 228 and cannot read, write or modify the files in the secret data area 228 . Instead, payment software 270 or personalization application 271 can access private data area 228 via control firmware 224 only after a specific authorization sequence has been completed. When the payment card 22 is inserted into the card slot 26 of the mobile device 20, the control firmware 224 only reports the visible area 229 to the operating system. Therefore, the operating system does not display the secret data area 228 to the user. The private data area 228 can only be accessed when the user executes the payment software 270 or the personalization application 271 and passes the authorization sequence.

The secret data area 228 stores a virtual account number associated with a payment institution account number associated with the holder of the payment card 22 and the payment institution (eg, bank) operating the payment institution server 5 . Data related to the payment institution account number is stored in the financial chip 221 . The secret data area 228 can store multiple virtual account numbers corresponding to multiple payment institution account numbers respectively.

When the mobile device 20 does not have the near field communication unit 23, and the mobile device 20 itself does not have the near field communication function, the payment card 22 can be designed to have the near field communication function. In other embodiments, the payment card 22 includes a plurality of NFC pins, and includes a NFC antenna, and can be implemented with an SDIO (Secure Digital Input Output) card supporting NFC function.

Therefore, in other embodiments, the card slot 26 includes a plurality of near field communication terminals. The near field communication terminal conforms to the near field communication specification (published by the SD Association). When the payment card 22 is inserted into the card slot 26 , the near field communication terminals are respectively electrically connected to the near field communication pins of the payment card 22 . Thereby, the payment card 22 can interact with the mobile device 20 so that the mobile device 20 supports the near field communication function.

Referring to FIG. 3A, an embodiment of a mobile payment method is described below, which processes a payment for a transaction. The computer device 1 in the following description may be a computer, and the mobile device 20 may be a smart phone with a payment card 22 inserted therein. The transaction is to purchase a book from a bookstore.

First, the merchant of the bookstore executes the transaction software 120 (see FIG. 4 ) using the computer device 1 .

In step S11, the processing module 11 of the computer device 1 executes the transaction software 120 stored in the memory module 12.

The transaction software 120 provides the vendor with an interface for entering a transaction list (see FIG. 5 ), the transaction list related to the transaction and the payment. Here, the transaction list includes details of the purchase of the book (eg, store number, transaction date, payment number, transaction amount, etc.).

In step S12, the processing module 11 receives a transaction list related to the transaction and the payment. For example, the transaction list may be input to the computer device 1 by scanning the barcode of the goods and/or services. Alternatively, the transaction list may be entered by the consumer using the computer device 1 .

In step S13, the processing module 11 executes a security control device 121 of the transaction software 120 to generate data to be bet.

In step S14, the processing module 11 locks the transaction list.

More specifically, the data to be staked includes a transaction list, and after step S14, the merchant cannot change the transaction list. It should be noted that the sequence of step S13 and step S14 can be interchanged, or performed simultaneously.

In step S15 , the processing module 11 outputs a transaction list (refer to FIG. 6 ) via the input/output module 14 for confirmation by the consumer who wants to buy the book.

In step S16 , the processing module 11 generates an instruction (see FIG. 7 ) to prompt the consumer to bring the mobile device 20 with the payment card 22 close to a payment sensing area (eg, the near field communication module 13 of the computer device 1 ). When the processing module 11 detects the mobile device 20 via the near field communication module 13, the processing module 11 establishes wireless short-range communication with the mobile device 20 via the near field communication module 13, and then executes step S17. Otherwise, the processing module 11 is idle until the mobile device 20 is detected. More specifically, when the computer device 1 and the mobile device 20 are adjacent to each other, the processing module 11 automatically establishes near field communication as wireless short-range communication with the mobile device 20 .

On the other hand, when the consumer wants to use the mobile payment device 2 (eg, the mobile device 20 is combined with the payment card 22 ) to complete the payment for the book purchase, the consumer uses the mobile device 20 to execute payment software 270 (see FIG. 8 ).

Therefore, in step S21 , the processor 21 of the mobile device 20 executes the payment software 270 stored in the memory unit 27 .

Payment software 270 provides consumers with various payment methods (eg, near field communication payment or cash on delivery). Here, the user selects the near field communication payment for payment.

In step S22, the processor 21 is instructed to select the near field communication payment by the consumer.

In step S23, the processor 21 outputs an instruction to prompt the user to input an access password related to the payment card 22 (refer to FIG. 9).

In step S24, upon receiving the access code, the processor 21 then transmits the access code to the payment card 22 via the card slot 26.

In step S31, the payment card 22 verifies the access password. When the payment card 22 verifies that the access password is correct, the payment card 22 transmits an access approval instruction to the mobile device 20, and the process then executes step S25. Otherwise, the flow proceeds to step S32.

In step S32, the payment card 22 transmits an access rejection instruction to the mobile device 20, and the mobile device 20 notifies the user via the input/output unit 24 that the access password is incorrect. The payment card 22 counts the number of consecutive times that an incorrect access code has been received.

In step S33, the payment card 22 determines that the number of times of the aforementioned counting is greater than or equal to a threshold value (for example, 3 times). When the counted number of times is not greater than the threshold value, the flow returns to step S23 to allow the consumer to input other access codes. Otherwise, the flow proceeds to step S34.

At step S34, the payment card 22 is locked and access prohibited.

In step S25, the processor 21 of the mobile device 20 clears the access password received and temporarily stored in step S24. This step is used to prevent the access password from being obtained by others.

It is worth noting that when using e-wallets for micropayments, convenience is the main consideration. Therefore, steps S23 to S25 and steps S31 to S34 can be omitted to speed up the payment process.

In step S26, the processor 21 of the mobile device 20 activates the near field communication unit 23 to initiate the near field communication function.

Next, referring to FIG. 10 , the mobile device 20 prompts the consumer to bring the mobile device 20 close to the payment sensing area (eg, the near field communication module 13 of the computer device 1 ).

Then, in step S27 , when the mobile device 20 and the computer device 1 are adjacent to each other, the processor 21 of the mobile device 20 automatically establishes wireless short-range communication (eg, near field communication) with the computer device 1 via the near field communication unit 23 .

In step S17, after the near field communication between the computer device 1 (step S16) and the mobile device 20 (step S27) is established, the processing module 11 of the computer device 1 transmits the data to be staked to the mobile device via the near field communication 20.

In step S28 , in the near field communication, the processor 21 of the mobile device 20 transmits the data to be charged to the payment card 22 .

In step S35 , the payment card 22 generates a transaction key based on the data to be keyed and a secret key stored in the payment card 22 , and transmits the transaction key to the mobile device 20 .

More specifically, the payment card 22 stores a pair of secret keys for a virtual account used for payment, and is stored in one of the financial chip 221 and the secret data area 228 . Thereby, the payment card 22 obtains the secret key based on the virtual account number to generate the transaction key. It is worth noting that the payment institution system 4 of the payment institution server 5 has the same key corresponding to the virtual account number to identify the correctness of the payment card 22 .

In step S29, the processor 21 of the mobile device 20 executing the payment software 270 uses the transaction key to form a payment instruction. The payment instruction includes at least a virtual account number, a transaction list and a transaction betting code, and is encrypted. The mobile device 20 then transmits the payment instruction to the computer device 1 via near field communication.

In step S18, the processing module 11 of the computer device 1 receives the payment command from the mobile device 20 via the near field communication.

It is worth mentioning that the aforementioned steps S17, S28, S35, S29 and S18 are performed in the near field communication, and after these steps are performed, at least one of the computer device 1 and the mobile device 20 can provide an instruction to remind The consumer moves the mobile device 20 away from the location adjacent to the computer device 1 .

Referring to FIG. 3B , after step S18, the computer device 1 attempts to establish a session with the platform server 3 of the payment institution server 5. The session mechanism is used to provide a secure communication channel between the computer device 1 and the platform server 3 . And it is used to identify the correctness of the computer device 1 .

In step A1 , the processing module 11 of the computer device 1 executing the transaction software 120 transmits a session request to the platform server 3 .

In step A2, when the platform server 3 receives the session request, the platform server 3 generates a session identification number and transmits the session identification number to the computer device 1.

In step A3, the processing module 11 of the computer device 1 receives the session identification number.

In step A4 , the processing module 11 generates a first authentication code based on the received session identification number and a first identification key pre-stored in the computer device 1 .

In step A5 , the processing module 11 transmits the first authentication code to the platform server 3 .

In step A6, the platform server 3 searches for a second identification key pre-stored in the platform server 3, and the second identification key corresponds to the first identification key. The platform server 3 then generates a second authentication code based on the session identification number and the second identification key.

In step A7, the platform server 3 determines whether the first authentication code received from the computer device 1 (step A5) is the same as the second authentication code generated in step A6. When the judgment result is YES, the flow proceeds to step A8. Otherwise, the platform server 3 determines that the computer device 1 cannot generate the correct first authentication code, and the process ends.

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

3C, after the platform server 3 allows the transaction to proceed, in step B1, the processing module 11 transmits the payment instruction received in step S18 to the platform server 3 via the communication module 15 under the session mechanism. To be more specific, the aforementioned transfer action is performed using the SSL (Secured Sockets Layer) protocol.

In step B2, the platform server 3 sequentially transmits payment instructions to the payment institution system 4 via a dedicated channel.

In step B3, when the payment institution system 4 receives the payment instruction, the payment institution system 4 can decrypt the received payment instruction, and can identify the correctness of the payment card 22 based on the payment instruction. More specifically, the payment institution system 4 generates a confirmation code based on the data to be charged in the payment instruction and using the same secret key stored in the payment card 22 (eg, financial chip or secret data area). In some implementation aspects, the secret key for generating the confirmation code may be included in the payment instruction and transmitted by the platform-side server 3 to the payment institution system 4 .

The payment institution system 4 then compares the transaction deposit code and the confirmation code. When the confirmation code is the same as the transaction key, the payment institution system 4 determines that the payment card 22 is correct and the transaction list has not been changed during the transmission. The flow then proceeds to step B4. Otherwise, the flow proceeds to step B8.

In step B4, the payment institution system 4 can process the payment according to the transaction list in the payment instruction. In this embodiment, the payment institution account represented by the virtual account deducts the amount of the book (500 yuan), and the amount is transferred to an account owned by the bookstore.

In step B5 , the payment institution system 4 generates a payment result indicating that the transaction has been processed, and transmits the payment result to the platform server 3 .

In step B6 , the platform server 3 transmits the payment result to the computer device 1 . The transmission of payment results is under the session mechanism and uses the SSL protocol. In addition, the platform-side server 3 also transmits the payment result to the mobile device 20, because it is transmitted through the session mechanism established by the platform-side server 3 and the mobile device 20, and the method of establishing the session mechanism is the same as that between the platform-side server 3 and the computer device. 1 is the same, so it is not repeated here. It should be noted that the session mechanism is established by the mobile device 20 and the platform server 3 after the mobile device 20 transmits the payment instruction to the computer device 1 in step S29.

Next, in step B7, when the payment result is received, the processing module 11 of the computer device 1 outputs the payment result via the input/output module 14 (refer to FIG. 11 ) to inform the merchant of the payment result. As such, the payment is completed and the customer can obtain the goods/services (eg, books).

Similarly, in step B7', upon receiving the payment result, the processor 21 of the mobile device 20 outputs the payment result via the input/output unit 24 (refer to FIG. 12 ) to inform the customer of the payment result.

In step B3, when the confirmation code and the transaction deposit code are different, the payment institution system 4 determines that the payment card 22 is incorrect, or the transaction list is changed during the transmission process. Therefore, in step B8, the payment institution system 4 generates and transmits an error message to the platform server 3.

In step B9, the platform server 3 transmits an error message to the computer device 1, and the computer device 1 outputs the error message in step B10.

Similarly, in step B9, the platform-side server 3 transmits an error message to the mobile device 20, and the mobile device 20 outputs the error message in step B10'. Therefore, the transaction will not be completed.

In one example, the method is applied when the goods/services are delivered to the customer via shipping and payment is made when the goods/services are delivered (eg, cash on delivery). The deliveryman can carry the computer device 1 installed with the transaction software 120, and after the customer confirms the goods/services, the deliveryman can operate the computer device 1 to execute the mobile payment method. Therefore, the delivery person does not need to carry cash when making the delivery.

The mobile payment method can also be applied to provide goods/services to customers via vending machines. After step B7 (completion of payment), the vending machine provides the goods to the customer.

Furthermore, the mobile payment method of the present invention can also be applied to transfer money using two mobile smart phones. For example, two smart phones are used to transfer money for illustration. The payee operates a first smart phone to execute the transaction software 120, so that the first smart phone executes the aforementioned steps for the computer device 1, and the remitter operates a second smart phone to execute the transaction software 120. The smart phone executes the payment software 270, which causes the second smart phone to perform the steps described above with respect to the mobile device 20 and the payment card 22, whereby the use of two mobile devices can be achieved as long as the two smart phones are brought close to or in contact with each other. transfer job.

In some implementations, the payment card 22 may store additional data in the storage unit 225 of the payment card 22 coupled to the mobile device 20 , such as medical health information, certificates, identification information or membership status. The mobile device 20 can store the additional data in the program storage unit 225 through the personalization application 271 performing a perso.

For personalization, the data to be stored in the payment card 22 needs to be processed at a different security level, eg, the account information of the payment institution needs to be processed at a higher security level than general information. Accordingly, the payment card 22 of the present invention also provides for more secure and adaptive data management.

In some implementations, the hidden data area 228 of the payment card 22 is divided into a plurality of hidden data blocks. Each block is associated with a storage security level and is used to store personalization data of a predetermined data type. Therefore, for each block, the controller chip 222 can perform the personalization operation of storing the personalization data in the block with one of the predetermined security mechanisms corresponding to the storage security level.

Referring to FIG. 13 , FIG. 16 and FIG. 17 , in this embodiment, the secret data area 228 of the payment card 22 is divided into 8 blocks 5A-5H. More specifically, the block 5A (emergency reminder area) is used to store the emergency information of the user of the payment card 22, such as emergency contact information, history of major illnesses, drug allergies, and the like.

Block 5B (medical health area) is used to store the user's medical and health information, such as physical examination, blood test results, electronic medical records, etc.

Block 5C (various license area) is used to store the user's electronic identification documents or licenses, such as ID cards, passports, driver's licenses, etc.

Block 5D (ticket/receipt area) is used to store electronic tickets and receipts, such as prepaid train tickets or electronic invoices. Block 5E (Private Privacy Area) is used to store the user's private data.

Block 5F (community area) is used to store the user's community registration data. Block 5G (member bank area) is used to store the user's payment institution account information. Block 5H (information message area) is used to store other information.

For example, four different security mechanisms are used to implement personalization operations at different levels of storage security. In addition, a party can access partial blocks based on the corresponding storage security level.

Due to different security mechanisms, the payment card 22 needs to establish communication with different third parties (eg, an authorization organization server 32 ) to obtain authorization to perform personalization operations.

More specifically, in each security mechanism, the payment card 22 needs to communicate with the platform server 3, and the platform server 3 stores at least part of the authorization information and/or personalization data for authorizing personalization operations.

In some security mechanisms, the payment card 22 also needs to communicate with other third parties (eg, the authorization organization server 32, a partner organization server 33, or the payment institution system 4) to obtain authorization information.

For example, for the first security mechanism (platform personalization mechanism), the platform server 3 at least stores a registered role ID and password, a formatted role ID and password, and personalization data. For the second security mechanism (authorized organization personalization mechanism), the platform server 3 stores the registered role ID and password, and the authorized organization server 32 stores the formatted role ID and password and personalized data. For the third security mechanism (cooperative organization personalization mechanism), the platform server 3 stores the registered role ID and password, and a third party (for example, the payment institution server 5 ) stores the formatted role password, and the formatted role The password is generated by cooperation between the cooperative organization server 33 and the platform server 3 , and the cooperative organization server 33 stores the formatted role ID and personalized data. For the fourth security mechanism (user personalization mechanism), the platform server 3 stores the registered role ID and password and the formatted role ID and password, and the personalized data is input by the user.

The authorized organization server 32 can be operated by a third party authorized by the platform server 3 to provide information related to personalization operations. The cooperative organization server 33 may be operated by a third party that cooperates with the platform-side server 3 to generate information related to personalization operations.

In some security mechanisms, the user is allowed to enter personalization data, eg, the personalization data may be received from the personalization application 271 via the control firmware 224 and the application programming interface 223 . In other security mechanisms, personalization data is received from third parties and cannot be modified by the user.

For example, the personalization data of block 5A can be entered/modified by the user and accessible to everyone. Personalization data in blocks 5C-5E can be entered/modified by the user and only accessible by the user. Personalized data for blocks 5B, 5F and 5G are received from third parties (the user cannot modify the data) and only the user can access it. Personalized data in Block 5H is received from third parties and is accessible to everyone.

In this embodiment, each block 5A-5H is further divided into a plurality of hidden data sub-blocks for storing personalized data. For example, each sub-block of block 5G stores the data of a specific payment institution. Registration data and account information. Notably, all sub-blocks of a particular block are associated with the same security level and use the same security mechanism.

In another embodiment, additional blocks can be divided, and the existing blocks can be used to store various other information, and additional security mechanisms can also be used.

The system portion 226 of the payment card 22 may record a block main list 61 of blocks, and a sub-list address list 62 of the subblocks of each block 5A-5H. Each subblock uses a specific personalization job to store personalization data.

1, 13 and 14, the personalization operation includes a registration operation I, a formatting operation II and a personalized data writing operation III.

In registration operation 1, the payment card 22 designates one of the blocks 5A-5H, and points the data location to one of the sub-blocks to be used to store personalization data later. In this embodiment, the registration operation 1 is managed by the platform-side server 3, and the platform-side server 3 stores the personalized licenses and related data of blocks 5A-5H, such as a registration ID and a corresponding password, and is used for accessing The ID and password of the designated block 5A-5H. Therefore, during the personalization operation, the platform-side server 3 and one of the authorized organization server 32 and the cooperative organization server 33 obtains the pre-stored personalization data related to the designated blocks 5A-5H, and confirms whether to approve the designated block 5A-5H. The designated blocks 5A-5H perform formatting operation II and personalization data writing operation III, and provide the data required by the designated blocks 5A-5H.

In the formatting operation II, one of the designated blocks 5A-5H is formatted into a predetermined data type, so that the personalized data can be stored. In this embodiment, the format operation II is equivalent to obtaining permission to read/write the secret data area 228 . Based on the different security mechanisms of the personalization operation, the license is managed by one of the following: the platform server 3, the authorized organization server 32, the cooperative organization server 33, the payment institution system 4 and related managers, and the personalized application program 271. More specifically, the platform server 3 stores the registered role IDs, passwords and personalization data of the designated blocks 5A-5H. The platform server 3 is responsible for the personalization of the designated blocks 5A-5H. The platform server 3 also stores a server network address and related data of an authorized organization, a cooperative organization and a payment institution system. The authorized organization server 32 also stores the authorized personalization data of blocks 5A-5H, such as the formatted role ID and password of authorized blocks 5A-5H, formatted data, personalized data, and a user ID with password. The partner organization server 33 also stores the authorized personalization data of blocks 5A-5H, such as the authorized block 5A-5H formatted role ID, formatted data, personalized data, and a user ID and password . In this way, when the formatting operation II is performed, the platform server 3 and one of the authorized organization server 32 and the cooperative organization server 33 can read the personalized data to confirm that the formatting operation II is authorized and can Provides the data required for each block 5A-5H.

In the personalization data writing operation III, the payment card 22 stores the personalization data in one of the designated blocks 5A-5H.

In this embodiment, each sub-block stores a predetermined registration role ID and password (presetregistration ID/password combination) to authorize the registration operation I, and stores a predetermined format role ID and password (preset format ID/password combination) for Authorize Formatting Job II.

The payment card 22 receives a registration authorizing ID and password (registration authorizing ID/passwordcombination), and performs the registration step only when the registration authorizing ID and password are the same as the predetermined registration character ID and password. Similarly, the payment card 22 receives a format authorizing ID and password (format authorizing ID/passwordcombination), and executes the formatting operation II only when the format authorizing ID and password are the same as the predetermined format authorizing ID and password.

With further reference to FIG. 15, the personalization operation using the first security mechanism is described in detail next.

In step S40, the user operates the personalization application 271 on the mobile device 20 to start the personalization operation as shown in step S41. In step S42, the user selects one of the blocks (5A-5H) and one of the sub-blocks of the selected block according to the type of data to be stored in the payment card 22. Payment card 22 then specifies the selected block (eg, 5H) and sub-block. For example, subblock 5H is designated for personalization.

In step S43, the user is instructed to input an activation password. In step S44 , the mobile device 20 receives the activation password, and transmits the activation password to the payment card 22 . In step S45, the payment card 22 checks whether the activation password is correct, if yes, then proceeds to step S46, if not, the process ends.

In step S46, the mobile device 20 communicates with the platform server 3 to obtain registration data, such as the registration role ID and password corresponding to the specified sub-block. In this embodiment, only the platform server 3 has a registered role ID and password corresponding to the predetermined registered role ID and password, and the predetermined registered role ID and password are stored in the payment card 22 when the payment card 22 is manufactured. In step S47, after receiving the request, the platform server 3 reads the pre-stored personalized data (such as the registration role ID and password) corresponding to the designated sub-block, and the server determines whether the payment card 22 is allowed to perform registration. Operation I, if yes, execute step S48, if no, the flow ends.

In step S48 , the platform server 3 returns the registered character ID and password and other related information corresponding to the designated sub-block to the mobile device 20 . In step S49, the mobile device 20 then sends a registration instruction to the payment card 22 using the registered character ID and password.

In step S50, the payment card 22 receives the registration instruction, and in step S51, the payment card 22 checks whether the registered character ID and password are correct. More specifically, the payment card 22 compares the registered character ID and password with the predetermined registered character ID and password. , when the registered role ID and the password and the predetermined registered role ID and the password are the same, then step S52 is executed. When the registered role ID and the password and the predetermined registered role ID and the password are different, the process ends.

In step S52, the payment card 22 points the data location to the designated sub-block in the block 5H, and stores the relevant information in the designated sub-block. More specifically, the control firmware 224 transmits the relevant information to the controller chip 222, the controller chip 222 identifies the physical location of the designated subblock through the submenu address list 62, and the control firmware 224 writes the relevant information into the The identified physical location, thus completing the registration job I.

The flow then executes format job II. In step S53, the mobile device 20 communicates with the platform server 3 to obtain the formatted role ID and password corresponding to the designated sub-block, as well as personalization data. In this embodiment, only the platform server 3 has a formatted role ID and password corresponding to a predetermined formatted role ID and password, and the predetermined formatted role ID and password are stored in the payment card 22 when the payment card 22 is manufactured. In step S54, after receiving the request, the platform-side server 3 reads the pre-stored personalized data (for example, formatted character ID and password) corresponding to the designated sub-block, and determines whether the payment card 22 is allowed to execute with the server. Formatting job II, if yes, execute step S55, if no, the flow ends.

In step S55 , the platform server 3 returns the formatted character ID and password and other personalized data corresponding to the designated sub-blocks to the mobile device 20 . In step S56 , the mobile device 20 then uses the formatted role ID and password to transmit the formatted role ID and password for allowing subsequent formatting operations and an instruction to the payment card 22 .

In step S57, the payment card 22 receives the formatted character ID and password, and in step S58, the payment card 22 checks whether the formatted character ID and password are correct, more specifically, the payment card 22 compares the formatted character ID and password and Predetermined formatted role ID and password, when the formatted role ID and password and the predetermined formatted role ID and password are the same, then step S59 is executed, when the formatted role ID and password and the predetermined formatted role ID and password are different, then the flow Finish.

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

In this embodiment, the block main menu 61 and the sub-menu address list 62 are also updated to reflect the personalization operation.

Figure 16 shows a personalization operation using the second security mechanism. An authorized organization (eg, the X1 society) can write the affiliated society member data into the payment card 22 of the affiliated society member, and perform a personalization operation for one of the sub-blocks of block 5F.

Since the registration steps (eg, steps S41 to S52 ) are similar to the first security mechanism, they will not be repeated here.

The main differences between the second security mechanism and the first security mechanism are described below. In step S53, the mobile device 20 communicates with the authorized organization server 32 (operated by the X1 community) to obtain the formatted role ID and password corresponding to the designated subblock. In step S54, the authorization organization server 32 (not the platform server 3) determines whether the payment card 22 is allowed to execute the formatting operation II. In addition, in step S55 , the authorization organization server 32 (rather than the platform server 3 ) returns the formatted role ID, password and other personalization data corresponding to the designated sub-blocks to the mobile device 20 .

In addition, since the personalized data in this example is not open to everyone, the designated sub-block can also be set with an access ID and password (access ID/password combination) to block unauthorized access actions .

18A and 18B illustrate the flow steps of the personalization operation using the third security mechanism. In the example of FIG. 18A and FIG. 18B , the cooperative organization (such as the A member bank) can write the account information of the affiliated user into the payment card 22, and one of the sub-blocks of block 5G is set for personalization.

In this example, since the registration steps (eg, steps S41 to S52 ) are similar to the first security mechanism, they will not be repeated here.

The main differences between the third security mechanism and the first security mechanism are described below.

The format role password used in the format operation II is generated by the cooperation between the platform server 3 and the partner organization server 33 (operated by the A member bank).

FIG. 17 shows the steps of generating a formatted character password. In step S61 , the payment institution system 4 requests the platform server 3 and the partner organization server 33 for the data required for generating the formatted character password. The platform-side server 3 and the cooperative organization server 33 then return part of the data required for generating the formatted character password to the payment institution system 4 in step S62 or step S63, respectively. Next in step S64, the payment institution system 4 uses the received data to generate a formatted character password.

Next, referring to FIG. 18A , in step S53 the mobile device 20 asks the payment institution system 4 for the formatted character ID and password. Next, in step S71, the payment institution system 4 asks the platform server 3 and the partner organization server 33 whether to authorize the execution of the formatting operation II.

Referring to FIG. 18B , the platform server 3 and the cooperative organization server 33 respectively judge whether to permit the execution of the format operation II, if not, the platform server 3 and the cooperative organization server 33 transmit negative messages to the payment institution system 4 in steps S73a and S73b, respectively; If yes, the platform-side server 3 and the cooperative organization server 33 transmit an approval message to the payment institution system 4 in steps S74a and S74b, respectively. It is worth noting that when the partner organization server 33 determines that the format operation II is permitted to be executed, the partner organization server 33 also transmits the formatted role ID and personalization data to the payment institution system 4 in step S74b.

In step S75, the payment institution system 4 receives the data transmitted by the platform server 3 and the cooperative organization server 33, and in step S76 determines whether the platform server 3 and the cooperative organization server 33 are both allowed to execute the format operation II, and if so, then Step S77 is executed, and if at least one of them is disapproved, the payment institution system 4 notifies the mobile device 20 that the process ends. In step S77 , the payment institution system 4 obtains the formatted character password generated in step S64 , and in step S79 , the payment institution system 4 returns the formatted character ID, password and personalization data to the mobile device 20 . Next, the mobile device 20 and the payment card 22 continue the aforementioned personalization operations.

FIG. 19A and FIG. 19B illustrate the flow steps of performing the personalization operation using the fourth security mechanism. In this example, the user enters emergency alert information into the payment card 22, and one of the sub-blocks of block 5A is set for personalization.

In this example, since the registration steps (eg, steps S41 to S52 ) are similar to the first security mechanism, they will not be repeated here.

The main differences between the fourth security mechanism and the first security mechanism are described below. In step S53, the mobile device 20 does not request the personalization data from the platform server 3. Conversely, after step S59 (the payment card 22 is formatted), the mobile device 20 allows the user to input emergency alert information in step S81. Next, in step S82, the mobile device 20 stores the emergency reminder information (considered as personalized data) to the designated sub-block in the block 5A.

When using one of the aforementioned security mechanisms to carry out the personalization operation, the predetermined formatted role ID and password are stored in the payment card 22, and the formatted role ID and password corresponding to the predetermined formatted role ID and password are stored in the platform server. 3. However, after the format operation II is completed, the format role password can be modified by one of the platform server 3 , the authorized organization server 32 and the partner organization server 33 , so as to avoid the password leakage of the payment card 22 during manufacture. harm. Therefore, in the third security mechanism, the formatted character password is jointly generated by the platform server 3 and the partner organization server 33 , and then stored in the payment institution system 4 . The generated format role password can be used to update the format role ID and password after format job II is completed. In this way, the payment institution system 4 can simultaneously provide the initial formatted role ID and password and the new formatted role ID and password. In the remaining three security mechanisms, the platform server 3 or the authorization organization server 32 may be used to set the formatted role password in advance. When the formatted character ID and password are sent to a mobile device 20 (step S55), the set formatted character password is also sent to update the formatted character password.

It is worth mentioning that, when the personalized data is received from the platform server 3, the received personalized data also includes an access code for accessing the designated sub-block later. In this way, after the personalization operation is completed, each sub-block is set to a specific access level based on the security mechanism used.

For example, anyone holding a payment card 22 is permitted to read the sub-blocks of block 5A, but only the user has permission to write.

Users are authorized to read the sub-blocks of blocks 5B and 5F, but only authorized organizations (such as hospitals or social organizations) have the right to write.

The user is authorized to read and write sub-blocks of blocks 5C to 5E.

Users are authorized to read sub-blocks of block 5G, but only cooperative organizations (such as member banks or payment institutions) have the right to write.

Anyone holding a payment card 22 is allowed to read the sub-blocks of block 5H, but only the platform side server 3 has permission to write.

To sum up, by identifying the correctness of the payment card 22 based on the payment instruction generated by the mobile device 20, the payment behavior using a fake card can be detected. Furthermore, by instantly transmitting the payment instruction corresponding to the transaction list to the payment institution server 5, the payment of each transaction can be processed in time. In this way, losses caused by fraudulent payments or mismatched transaction records can be avoided. In addition, the secret data area 228 of the payment card 22 can be divided into a plurality of blocks, and each block is associated with a storage security level, and each block is also divided into a plurality of sub-blocks, and each sub-block requires a humanized operation to activate , therefore, the secret data area 228 has the function of an information expansion library.

However, the above are only examples of the present invention, and should not limit the scope of implementation of the present invention, that is, any simple equivalent changes and modifications made according to the contents of the claims and the patent specification of the present invention are still applicable. It belongs to the scope covered by the patent of the present invention.

Claims (15)

1. A mobile payment method is executed by a computer device, the computer device can interact with a mobile device with a payment card, and the computer device is communicated with a payment mechanism server; the method is characterized in that: the mobile payment method comprises the following steps:

receiving a transaction list, the transaction list relating to a transaction and a payment related to the transaction;

establishing wireless short-range communication with the mobile device;

transmitting the transaction list to the mobile device via the wireless short-range communication;

receiving a payment instruction from the mobile device via the wireless short-range communication, the payment instruction being generated by the mobile device based on at least the transaction list;

establishing a session mechanism with the payment authority server, the session mechanism providing a secure communication channel between the computer device and the payment authority server;

transmitting the payment instruction to the payment mechanism server under the session mechanism, wherein the payment instruction enables the payment mechanism server to identify the correctness of the payment card based on the payment instruction when receiving the payment instruction, and after the payment mechanism server identifies the payment card as correct, the payment instruction further enables the payment mechanism server to process the payment according to the transaction list included in the payment instruction; and

receiving a payment result from the payment authority server under the session mechanism, the payment result being generated by the payment authority server after completion of the payment;

wherein, before the step of establishing the wireless short-range communication, the method further comprises:

generating data to be secured, wherein the data to be secured comprises the transaction list;

wherein the step of transmitting the transaction list comprises transmitting the data to be secured to the mobile device via the wireless short-range communication;

in the step of receiving the payment instruction through the wireless short-distance communication, the mobile device transmits the data to be secured to the payment card by the data to be secured, the payment card generates a transaction security code based on the data to be secured and transmits the transaction security code to the mobile device, and the mobile device uses the transaction security code to form the payment instruction and transmits the payment instruction to the computer device through the wireless short-distance communication.

2. A mobile payment method as claimed in claim 1, wherein: the computer device and the mobile device have near field communication capability, and the step of establishing the wireless short-range communication comprises the following steps:

when the computer device and the mobile device are in proximity to each other, the computer device automatically establishes a near field communication with the mobile device as the wireless short-range communication.

3. A mobile payment method as claimed in claim 1, wherein: in the step of receiving the payment instruction via the wireless short-range communication, the data to be secured further causes the payment card to generate the transaction security code using a key stored in the payment card;

in the step of transmitting the payment instruction, the payment instruction further causes the payment mechanism server to generate a confirmation code by using the same key based on the data of the code to be secured included in the payment instruction, and causes the payment mechanism server to compare the transaction security code and the confirmation code to identify the correctness of the payment card.

4. A mobile payment method as claimed in claim 1, wherein: the step of establishing the session mechanism comprises the sub-steps of:

transmitting a session request to the payment mechanism server, wherein the session request enables the payment mechanism server to generate a session identification number when receiving the session request, and transmits the session identification number to the computer device;

after receiving the session identification number, generating a first authentication code based on the session identification number and a first identification key prestored in the computer device;

and transmitting the first authentication code to the payment mechanism server, wherein the first authentication code enables the payment mechanism server to search for a second identification key which is prestored in the payment mechanism server and corresponds to the first identification key of the computer device, enables the payment mechanism server to generate a second authentication code based on the session identification number and the second identification key, enables the payment mechanism server to judge whether the first authentication code received from the computer device is the same as the second authentication code, and enables the payment mechanism server to transmit a session response to the computer device to establish the session mechanism when judging that the first authentication code and the second authentication code are the same.

5. A mobile payment method as claimed in claim 1, wherein: after the step of receiving the transaction list, further comprising:

the transaction list is locked.

6. A mobile payment method is executed by a mobile device with a payment card, the mobile device can interact with a computer device, and the mobile device and the computer device are communicated with a payment mechanism server; the method is characterized in that: the mobile payment method comprises the following steps:

establishing wireless short-distance communication with the computer device;

receiving a transaction list from the computer device via the wireless short-range communication, the transaction list relating to a transaction and a payment related to the transaction;

generating a payment instruction based on at least the transaction list, and transmitting the payment instruction to the computer device through the wireless short-distance communication, wherein the payment instruction is provided for the payment mechanism server by the computer device, the payment instruction enables the payment mechanism server to identify the correctness of the payment card based on the payment instruction when receiving the payment instruction, and the payment instruction also enables the payment mechanism server to process the payment according to the transaction list included in the payment instruction after the payment mechanism server identifies the payment card as correct; and

receiving a payment result from the payment authority server, the payment result being generated by the payment authority server after completion of the payment;

wherein the step of receiving the transaction list comprises:

receiving data to be secured from the computer device via the wireless short-range communication, the data to be secured being generated by the computer device and including the transaction list;

wherein the step of generating the transaction instruction comprises:

the mobile device transmits the data to be secured to the payment card;

the payment card generates a transaction code based on the data to be secured and transmits the transaction code to the mobile device; and

the mobile device uses the transaction escort code to form the payment instruction, and transmits the payment instruction to the computer device through the wireless short-distance communication, and the payment instruction is transmitted to the payment mechanism server by the computer device under a session mechanism established between the computer device and the payment mechanism server.

7. A mobile payment method as claimed in claim 6, wherein: the computer device and the mobile device have near field communication capability, and the step of establishing the wireless short-range communication comprises the following steps:

when the computer device and the mobile device are in proximity to each other, the mobile device automatically establishes a near field communication with the computer device as the wireless short-range communication.

8. A mobile payment method as claimed in claim 6, wherein: the step of generating the payment instruction further comprises the step of generating the transaction security code by the payment card by using a secret key stored in the payment card;

the payment instruction also enables the payment mechanism server to generate a confirmation code based on the data of the code to be checked, which is included in the payment instruction, and by using the same secret key, and enables the payment mechanism server to compare the transaction code to the confirmation code so as to identify the correctness of the payment card.

9. A mobile payment method as claimed in claim 6, wherein: before the step of establishing the wireless short-range communication, further comprising:

the mobile device outputs an instruction to prompt a user to input a starting password;

the mobile device transmits the starting password to the payment card when receiving the starting password;

the payment card verifies the start password, and when the start password is correct, the payment card transmits an access approval indication to the mobile device; and

the mobile device clears the temporarily stored starting password when receiving the access permission indication.

10. A mobile payment device capable of interacting with a computer device in communication with a payment mechanism server; the method is characterized in that: the mobile payment device comprises:

a mobile device comprising

A processor for processing the received data, a storage device for storing the processed data,

a memory unit coupled to the processor and storing a payment software,

a card slot coupled to the processor and removably receiving a payment card, whereby the payment card is accessible using the mobile device,

a short-range communication unit coupled to the processor and capable of communicating with the computer device, an

A communication unit coupled to the processor and capable of communicating with the payment authority server;

wherein when the processor executes the payment software, the payment software causes the mobile payment device to:

establishing a wireless short-range communication with the computer device,

receiving a transaction list from the computer device via the wireless short-range communication, the transaction list relating to a transaction and a payment related to the transaction,

generating a payment instruction based on at least the transaction list, transmitting the payment instruction to the computer device through the wireless short-distance communication, wherein the payment instruction is provided for the payment mechanism server by the computer device, the payment instruction enables the payment mechanism server to identify the correctness of the payment card based on the payment instruction when receiving the payment instruction, and the payment instruction enables the payment mechanism server to process the payment according to the transaction list included in the payment instruction after the payment mechanism server identifies the correctness of the payment card, and

receiving a payment result from the payment authority server, the payment result being generated by the payment authority server after completion of the payment;

wherein the step of receiving the transaction list comprises:

receiving data to be secured from the computer device via the wireless short-range communication, the data to be secured being generated by the computer device and including the transaction list;

wherein the step of generating the transaction instruction comprises:

the mobile device transmits the data to be secured to the payment card;

the payment card generates a transaction code based on the data to be secured and transmits the transaction code to the mobile device; and

the mobile device uses the transaction escort code to form the payment instruction, and transmits the payment instruction to the computer device through the wireless short-distance communication, and the payment instruction is transmitted to the payment mechanism server by the computer device under a session mechanism established between the computer device and the payment mechanism server.

11. The mobile payment device of claim 10, wherein: the mobile device can also execute a personalized application program to execute a personalized operation aiming at the payment card, wherein the payment card comprises:

a control module including a controller chip, a control firmware and an application program interface; and

a storage unit including a hidden data area accessible to the personalized application via the control firmware and the application program interface only after a specific authorization sequence is completed;

the controller chip can execute the personalization operation to store the personalization data by one of a plurality of security mechanisms, wherein one of the security mechanisms corresponds to the storage security level of the block.

12. The mobile payment device of claim 11, wherein: the personalization operation includes:

a registration operation in which a block is selected to store the personalization data;

a formatting operation, wherein the selected block is formatted to be consistent with the predetermined data type, so that the personalized data can be stored in the selected block later; and

a personalized data writing operation, wherein the payment card stores the personalized data to the selected block.

13. The mobile payment device of claim 12, wherein: each of the blocks is divided into a plurality of sub-blocks, the payment card further selects one of the sub-blocks of the selected block to store the personalization data during the registration process, and the one of the selected sub-blocks is formatted during the formatting process;

each subblock stores a preset registration role ID and a password used for authorizing the registration operation and a preset formatting role ID and a password used for authorizing the formatting operation;

wherein the payment card receives a registration role ID and a password, and executes the registration operation only when the registration role ID and the password are the same as the predetermined registration role ID and the password;

the payment card receives a formatted role ID and a password, and the formatting operation is executed only when the formatted role ID and the password are the same as the preset formatted role ID and the password.

14. The mobile payment device of claim 13, wherein: the payment card can execute the personalized operation according to one of a first security mechanism, a second security mechanism, a third security mechanism and a fourth security mechanism;

wherein, in the first security mechanism, the registered role ID and password, the formatted role ID and password and the personalized data are received from a platform server;

wherein, in the second security mechanism, the registered role ID and password are received from the platform server, and the formatted role ID and password and the personalized data are received from an authorized organization server authorized by the platform server to provide the formatted role ID and password;

wherein, in the third security mechanism, the registered role ID and password are received from the platform server, the formatted role ID and password are received from a third party, the formatted role password of the formatted role ID and password are generated by the platform server and a collaboration organization server, the personalized data is provided by the collaboration organization server, and the third party is authorized by the platform server to provide the formatted role ID and password;

wherein, in the fourth security mechanism, the registered role ID and password and the formatted role ID and password are received from the platform server, and the personalized data is received from the personalized application software via the control firmware and the application program interface.

15. The mobile payment device of claim 12, wherein: the registration operation includes the following substeps:

when a register command is received, a sub-block divided from one of the blocks is selected, and

receiving a formatted role ID and password from a third party operating the security mechanism of the selected block;

wherein, in the formatting operation, when the received formatting role ID and password are judged to be the same as the preset formatting role ID and password stored in the selected sub-block, the selected sub-block is formatted;

wherein the personalization data is stored in the selected sub-block during the personalization data writing operation.

Images