HK1230326B - Mobile payment methods and mobile payment device - Google Patents

Description

Mobile payment method and mobile payment device

Technical Field

The present invention relates to a mobile payment method and a mobile payment device, and in particular to a mobile payment method and a mobile payment device for implementing secure transaction payment using near field communication.

Background Art

Electronic wallets or plastic money, such as bank cards, credit cards, debit cards, or smart cards, all require computer systems and digital stored-value systems to enable functions like top-up and transfers. Since using electronic wallets or plastic money reduces the need for customers to carry excessive amounts of cash when shopping, and eliminates the need for merchants to verify the correct amount of cash received upon payment, they can improve transaction efficiency and convenience. Consequently, electronic wallets have become widely accepted and used in recent years.

However, existing traditional contactless stored-value smart cards often lack card authentication capabilities or have insufficient card authentication measures. Once a card is counterfeited, the store will have no choice but to bear the risk of loss.

Furthermore, when using traditional contactless stored-value smart cards to pay for purchases, transaction records for each purchase are typically stored at the merchant's end. However, these records are not immediately transmitted to the card issuer or payment institution to verify the authenticity of the stored-value smart card before payment is processed. Instead, the entire batch of transaction records is sent to the card issuer or payment institution for payment at the end of the business day, a process known as batch settlement. When this batch settlement process is not immediate, merchants may complete transactions without verifying the authenticity of each stored-value smart card used by the card issuer or payment institution, exposing them to 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 transactions to be processed promptly and ensure transaction security.

The mobile payment method of the present invention is executed by a computer device that 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 transaction list associated with 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, wherein the session mechanism provides a secure communication channel between the computer device and the payment institution server;

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

A payment result is received from the payment institution server under the session mechanism, where 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, the mobile device being able to interact with a computer device. The mobile device and the computer device communicate with a payment institution server. The mobile payment method comprises:

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, and transmitting the payment instruction to the computer device via the wireless short-range communication, wherein the computer device provides the payment instruction to the payment institution server, and the payment instruction causes the payment institution server to identify the correctness of the payment card based on the payment instruction upon receipt of the payment instruction, and after the payment institution server identifies the payment card as correct, the payment instruction further causes the payment institution server to process the payment according to the transaction list included in the payment instruction; and

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

The mobile payment device of the present invention can interact with a computer device, which communicates with a payment institution server. The mobile payment device includes a mobile device, which includes a processor, a memory unit, a card 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 removably inserts a payment card, thereby enabling the mobile device 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:

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, and transmitting the payment instruction to the computer device via the wireless short-range communication; the computer device providing the payment instruction to the payment institution server, and the payment instruction causing the payment institution server to identify the correctness of the payment card based on the payment instruction upon receipt of the payment instruction; and after the payment institution server identifies the payment card as correct, the payment instruction further causing the payment institution server to process the payment according to the transaction list included in the payment instruction, and

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

The present invention provides the following advantages: by verifying the authenticity of payment cards based on payment instructions generated by mobile devices, it can detect payment attempts using fake cards. Furthermore, by instantly transmitting payment instructions corresponding to transaction lists to the payment institution's server, payments for each transaction can be processed promptly. This prevents losses caused by fraudulent payments or inconsistent transaction records.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

3A to 3C are flow charts illustrating the process 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 at different stages of the mobile payment method;

FIG13 is a block diagram illustrating a storage unit of a payment card of the present invention;

FIG14 is a flow chart illustrating the process steps of the payment card personalization operation of the present invention;

FIG15 is a flow chart illustrating the process steps of a personalization operation using the first security mechanism;

FIG16 is a flow chart illustrating the process steps of a personalization operation using a second security mechanism;

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

18A and 18B are flowcharts illustrating the steps of a personalization process using a third security mechanism; and

19A and 19B are flow charts illustrating the process steps of personalization using the fourth security mechanism.

DETAILED DESCRIPTION

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 shown for implementing a mobile payment method that processes a payment associated with a transaction. System 100 includes a computer device 1 and a mobile payment device 2. For example, computer device 1 is held by a merchant, and mobile payment device 2 is held by a consumer. Mobile payment device 2 includes a mobile device 20 and a payment card 22, which is removably inserted into a card slot 26 of mobile device 20. Computer device 1 can interact with mobile device 20 with payment card 22. Computer device 1 and mobile device 20 can communicate with a payment institution server 5.

In this embodiment, the computer device 1 can be a personal computer, a laptop, a tablet computer, a smartphone, or a mobile electronic device (see FIG. 2 ). The computer device 1 needs to have an Internet connection to execute a transaction software 120 that enables the computer device 1 to execute the mobile payment method of the present invention.

The payment institution server 5 is operated by the payment institution that issues payment cards to consumers. In this embodiment, the payment institution server 5 includes a platform-side server 3 and a payment institution system 4. The platform-side server 3 is used to communicate with the computer device 1 and the mobile device 20, and the payment institution system 4 is coupled to the platform-side server 3. In different implementations, the platform-side server 3 and the payment institution system 4 can be integrated into a single device (e.g., a server), or can be implemented as two separate devices that communicate via a dedicated channel or session mechanism. Taking the latter of the two aforementioned implementations as an example, the platform-side server 3 can be operated by a third party (not the payment institution).

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 processing module 11 coupled to the memory module 12 , the near-field communication module 13 , the input/output module 14 , and the communication module 15 .

In this embodiment, the computer device 1 includes a NFC module 13, which provides NFC functionality. The NFC module 13 is an external device connected to the computer device 1, such as an external USB NFC dongle or a USB NFC reader. In another embodiment, the NFC module 13 may be a built-in module embedded in the computer device 1. The input/output module 14 may include, but is not limited to, a mouse/keyboard, a touch screen, or a speaker/display. The communication module 15 enables communication between the computer device 1 and the payment institution server 5.

Mobile payment device 2 can interact with computer device 1. Mobile device 20 of mobile payment device 2 can be a smartphone or tablet computer. Mobile device 20 includes a memory unit 27, a card slot 26, an input/output unit 24, a short-range communication unit (e.g., a near-field communication unit 23), a communication unit 25, and a processor 21 coupled to the near-field communication unit 23, the input/output unit 24, the communication unit 25, the card slot 26, and the memory unit 27. Memory unit 27 stores payment software 270 and a personalized application 271. Card slot 26 removably accepts a payment card 22, enabling mobile device 20 to access the payment card 22. Near-field communication unit 23 can communicate with computer device 1. Communication unit 25 can communicate with a payment institution server 5. In another embodiment, the payment card 22 may be coupled to an interface device, so that the mobile device 20 can access the payment card 22 via the interface device. The interface device is coupled to the mobile device 20 via a USB interface of the mobile device 20 .

In this embodiment, the near-field communication unit 23 supports near-field communication functionality. The input/output unit 24 may include, but is not limited to, a mouse/keyboard, a touch screen, or a speaker/display. The processor 21 of the mobile device 20 executes payment software 270 stored in the memory unit 27. 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 brought into proximity with each other for NFC payment, the computer device 1 and the mobile device 20 can establish wireless short-range communication (eg, NFC) via the NFC module 13 and the NFC 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 complies with the FISC II standard.

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

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

Storage unit 225 includes a system portion 226 and a storage portion 227. System portion 226 contains basic operation information. Storage portion 227 includes a private data area 228 and a visible area 229. Visible area 229 is accessible to the operating system (OS) of mobile device 20. For example, visible 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 files in the secret data area 228. Instead, the payment software 270 or the personalized application 271 can access the secret data area 228 through the control firmware 224 only after a specific authorization sequence is 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 secret data area 228 can only be accessed when the user executes the payment software 270 or the personalized application 271 and completes the authorization sequence.

The secret data area 228 stores a virtual account number associated with a payment institution account number. The payment institution account number is associated with the holder of the payment card 22 and the payment institution (e.g., a 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 accounts.

If the mobile device 20 does not have an NFC unit 23 and does not have NFC functionality, the payment card 22 can be designed with NFC functionality. In other embodiments, the payment card 22 includes multiple NFC pins and an NFC antenna, and can be implemented as an SDIO (Secure Digital Input/Output) card that supports NFC functionality.

Therefore, in other embodiments, the card slot 26 includes multiple near-field communication (NFC) terminals. These NFC terminals comply with the NFC specification (published by the SD Association). When a payment card 22 is inserted into the card slot 26, the NFC terminals are electrically connected to the NFC pins of the payment card 22. This allows the payment card 22 to interact with the mobile device 20, enabling the mobile device 20 to support NFC functionality.

3A , an embodiment of a mobile payment method is described below, which processes a payment related to a transaction. Here, the computer device 1 may be a computer, the mobile device 20 may be a smartphone with a payment card 22 inserted, and the transaction is the purchase of a book from a bookstore.

First, a merchant in a bookstore uses the computer device 1 to execute the transaction software 120 (see FIG. 4 ).

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 merchants with an interface for inputting a transaction list (see FIG5 ), which is related to the transaction and the payment. Here, the transaction list includes the details of the book purchased (e.g., store number, transaction date, payment number, and 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 can be input into the computer device 1 by scanning a barcode of the goods and/or services. Alternatively, the transaction list can be input 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 staked.

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 is worth noting that the order of steps S13 and S14 can be interchanged or performed simultaneously.

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

In step S16, processing module 11 generates an indication (see FIG. 7 ) prompting the consumer to bring mobile device 20, which contains payment card 22, close to a payment sensing area (e.g., near-field communication module 13 of computer device 1 ). When processing module 11 detects mobile device 20 via near-field communication module 13, it establishes wireless short-range communication with mobile device 20 via near-field communication module 13 and then proceeds to step S17. Otherwise, processing module 11 remains idle until mobile device 20 is detected. More specifically, when computer device 1 and mobile device 20 are in proximity, processing module 11 automatically establishes near-field communication (NFC), a form of wireless short-range communication, with mobile device 20.

On the other hand, when the consumer wants to use the mobile payment device 2 (eg, a mobile device 20 combined with a payment card 22 ) to complete payment for the book purchase, the consumer uses the mobile device 20 to execute the 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 .

The payment software 270 provides consumers with multiple payment methods (such as near field communication payment or cash on delivery). Here, the user selects near field communication payment to make payment.

In step S22 , the processor 21 is instructed to instruct the consumer to select NFC payment.

In step S23 , the processor 21 outputs an instruction to prompt the user to input an access code associated with the payment card 22 (see 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 code. If the payment card 22 verifies that the access code is correct, the payment card 22 sends an access consent instruction to the mobile device 20, and the process then proceeds to step S25. Otherwise, the process then proceeds to step S32.

In step S32, the payment card 22 sends an access rejection command to the mobile device 20, and the mobile device 20 notifies the user that the access code is incorrect via the input/output unit 24. The payment card 22 counts the number of consecutive times it receives an incorrect access code.

In step S33, the payment card 22 determines whether the counted number is greater than or equal to a threshold (e.g., 3 times). If the counted number is not greater than the threshold, the process returns to step S23 to allow the consumer to enter another access code. Otherwise, the process proceeds to step S34.

In step S34 , the payment card 22 is locked and access is 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 an electronic wallet to make small payments, convenience is the primary 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 NFC unit 23 to initiate the NFC 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 NFC is established between the computer device 1 (step S16 ) and the mobile device 20 (step S27 ), the processing module 11 of the computer device 1 transmits the data to be coded to the mobile device 20 via the NFC.

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

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

More specifically, payment card 22 stores a secret key for a virtual account used for payment, stored in either the financial chip 221 or the secret data area 228. Thus, payment card 22 obtains the secret key based on the virtual account number to generate the transaction deposit. It is worth noting that payment institution system 4 on payment institution server 5 has the same secret key corresponding to the virtual account number to verify the authenticity of payment card 22.

In step S29, the processor 21 of the mobile device 20 executing the payment software 270 uses the transaction code to construct a payment instruction. The payment instruction includes at least the virtual account number, the transaction list, and the transaction 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 near field communication.

It is worth mentioning that the aforementioned steps S17, S28, S35, S29 and S18 are performed in near field communication, and after these steps are completed, at least one of the computer device 1 and the mobile device 20 can provide an indication to remind the consumer to move the mobile device 20 away from the position near 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 to verify the authenticity of the computer device 1 .

In step A1 , the processing module 11 of the computer device 1 executing the transaction software 120 sends 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 that corresponds to the first identification key and is pre-stored in the platform server 3. The platform server 3 then generates a second authentication code based on the session ID and the second identification key.

In step A7, platform server 3 determines whether the first authentication code received from computer device 1 (step A5) is identical to the second authentication code generated in step A6. If so, the process proceeds to step A8. Otherwise, platform server 3 determines that computer device 1 was unable to generate a 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.

Referring to FIG. 3C , after platform server 3 permits the transaction to proceed, in step B1, processing module 11 transmits the payment instruction received in step S18 to platform server 3 via communication module 15 under the session mechanism. Specifically, this transmission 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, upon receiving the payment instruction, the payment institution system 4 decrypts the received payment instruction and verifies the authenticity 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 encrypted in the payment instruction and using the same key stored in the payment card 22 (e.g., the financial chip or the secret data area). In some embodiments, the key used to generate the confirmation code may be included in the payment instruction and transmitted to the payment institution system 4 by the platform server 3.

Payment institution system 4 then compares the transaction code and confirmation code. If the confirmation code matches the transaction code, payment institution system 4 determines that payment card 22 is correct and the transaction list has not been altered during transmission. The process then proceeds to step B4. Otherwise, the process 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 number 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. This payment result is transmitted via a session mechanism using the SSL protocol. Furthermore, the platform server 3 transmits the payment result to the mobile device 20 via a session mechanism established between the platform server 3 and the mobile device 20. The establishment of this session mechanism is similar to that between the platform server 3 and the computer device 1, so this will not be described in detail. It should be noted that the session mechanism is established between 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, upon receiving the payment result, the processing module 11 of the computer device 1 outputs the payment result (see FIG. 11 ) via the input/output module 14 to inform the merchant of the payment result. Thus, the payment is completed, and the customer can obtain the goods/services (e.g., books).

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

In step B3, if the confirmation code is different from the transaction deposit code, the payment institution system 4 determines that the payment card 22 is incorrect or the transaction list has been altered during transmission. 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 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, this method is applied when goods/services are delivered to customers via shipping, and payment is completed upon delivery (e.g., cash on delivery). The delivery person can carry a computer device 1 installed with transaction software 120. After the customer confirms the goods/services, the delivery person can use the computer device 1 to execute the mobile payment method. Therefore, the delivery person does not need to carry cash when making deliveries.

The mobile payment method can also be applied to providing goods/services to customers via a vending machine. After step B7 (payment completed), the vending machine provides the goods to the customer.

Furthermore, the mobile payment method of the present invention can also be applied to transferring money using two mobile smartphones. For example, using two smartphones to transfer money, the payee operates a first smartphone to execute transaction software 120, causing the first smartphone to perform the aforementioned steps related to computer device 1. The remitter operates a second smartphone to execute payment software 270, causing the second smartphone to perform the aforementioned steps related to mobile device 20 and payment card 22. In this way, simply by bringing the two smartphones close together or touching them, a money transfer can be accomplished using the two mobile devices.

In some embodiments, the payment card 22 may store additional data in the storage unit 225 of the payment card 22 coupled to the mobile device 20. The additional data may include medical information, credentials, identification information, or membership status. The mobile device 20 may store the additional data in the program storage unit 225 by executing a personalized operation (perso) through the personalized application 271.

During personalization, the data to be stored on the payment card 22 needs to be handled at different security levels. For example, payment institution account information needs to be handled at a higher security level than general information. Therefore, the payment card 22 of the present invention can also provide more secure and adaptable data management.

In some embodiments, 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 personalized data of a predetermined data type. Therefore, for each block, the controller chip 222 can perform a personalization operation to store the personalized data in that block using a predetermined security mechanism corresponding to the storage security level.

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

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

Block 5C (various certificates and licenses area) is used to store the user's electronic identification documents or certificates, 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, etc. Block 5E (Private Secret Area) is used to store user's private data.

Block 5F (Community Area) is used to store user community registration data. Block 5G (Member Bank Area) is used to store user 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 personalized operations at different storage security levels. In addition, a party can access partial blocks based on the corresponding storage security level.

Under different security mechanisms, the payment card 22 needs to establish communication with different third parties (such as an authorization organization server 32) to obtain authorization for personalization.

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 the personalization data for authorizing the personalization operation.

In some security mechanisms, the payment card 22 also needs to communicate with other third parties (such as the authorization organization server 32, a cooperative 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-side server 3 stores at least a registered role ID and password, a formatted role ID and password, and personalized data. For the second security mechanism (authorized organization personalization mechanism), the platform-side 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-side server 3 stores the registered role ID and password, and a third party (such as the payment institution server 5) stores the formatted role password, and the formatted role password is generated by the cooperative organization server 33 and the platform-side 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-side server 3 stores the registered role ID and password and the formatted role ID and password, and the personalized data is entered by the user.

The authorized organization server 32 may 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 cooperating with the platform server 3 to generate information related to personalization operations.

In some security mechanisms, the user is allowed to input personalization data, for example, the personalization data may be received from the personalization application 271 via the control firmware 224 and the application program interface 223. In other security mechanisms, the personalization data is received from a third party and cannot be modified by the user.

For example, the personalized data in block 5A can be entered/modified by the user and is accessible to everyone. The personalized data in blocks 5C-5E can be entered/modified by the user and is accessible only to the user. The personalized data in blocks 5B, 5F, and 5G is received from a third party (the user cannot modify the data) and is accessible only to the user. The personalized data in block 5H is received from a third party and is accessible to everyone.

In this embodiment, each block 5A-5H is further divided into multiple sub-blocks for storing personalized data (hidden data sub-blocks). For example, each sub-block of block 5G stores registration data and account information for a specific payment institution. It is worth noting that all sub-blocks of a specific block are associated with the same security level and use the same security mechanism.

In another embodiment, additional blocks may be partitioned and existing blocks may be used to store various other information. In addition, additional security mechanisms may be employed.

The system portion 226 of the payment card 22 can record a block list 61 of blocks and a sub-list 62 of sub-block addresses of each block 5A-5H. Each sub-block stores personalized data using a specific personalization process.

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

During registration operation I, the payment card 22 specifies one of the blocks 5A-5H and points the data location to a sub-block that will later be used to store personalized data. In this embodiment, registration operation I is managed by the platform server 3, which stores personalization permissions and related data for blocks 5A-5H, such as a registration ID and corresponding password, as well as the ID and password used to access the designated blocks 5A-5H. Therefore, during the personalization operation, the platform server 3, one of the authorized organization server 32, and the partner organization server 33 obtains the pre-stored personalized data associated with the designated blocks 5A-5H, confirms whether to permit the formatting operation II and the personalized data writing operation III for the designated blocks 5A-5H, and provides the data required for the designated blocks 5A-5H.

During formatting operation II, a designated block 5A-5H is formatted into a predetermined data type, enabling the storage of personalized data. In this embodiment, formatting operation II is equivalent to obtaining permission to read/write the secret data area 228. Based on the various security mechanisms for the personalization operation, this permission is managed by one of the following: the platform server 3, the authorized organization server 32, the partner organization server 33, the payment institution system 4 and its associated administrators, and the personalized application 271. More specifically, the platform server 3 stores the registered role ID and password, as well as the personalized data, for the designated block 5A-5H. The platform server 3 is responsible for personalizing the designated block 5A-5H. The platform server 3 also stores the server network addresses and related data of an authorized organization, a partner organization, and a payment institution system. The authorized organization server 32 also stores the personalized data for the authorized block 5A-5H, such as the formatted role ID and password, formatted data, personalized data, and a user ID and password for the authorized block 5A-5H. The partner organization server 33 also stores the personalized data of the authorized blocks 5A-5H, such as the formatting role ID, formatting data, personalized data, and a user ID and password for the authorized blocks 5A-5H. Thus, when performing formatting operation II, the platform server 3, the authorized organization server 32, or the partner organization server 33 can read the personalized data to confirm that formatting operation II is permitted and provide the required data for each block 5A-5H.

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

In this embodiment, each sub-block stores a preset registration ID and password combination to authorize registration operation I, and stores a preset formatting ID and password combination to authorize formatting operation II.

Payment card 22 receives a registration authorizing ID/password combination and only performs the registration step if the registration authorizing ID and password match a predetermined registration authorizing ID and password. Similarly, payment card 22 receives a formatting authorizing ID/password combination and only performs the formatting step II if the formatting authorizing ID and password match a predetermined formatting authorizing ID and password.

15 , the personalization operation using the first security mechanism will be described in detail.

In step S40, the user operates the personalization application 271 on the mobile device 20 to initiate the personalization process, as shown in step S41. In step S42, the user selects one of the blocks (5A-5H) and a sub-block of the selected block based on the type of data to be stored on the payment card 22. The payment card 22 then specifies the selected block (e.g., 5H) and sub-block. For example, sub-block 5H is designated for personalization.

In step S43, the user is instructed to enter an activation code. In step S44, mobile device 20 receives the activation code and transmits it to payment card 22. In step S45, payment card 22 verifies whether the activation code is correct. If so, step S46 is executed. If not, the process ends.

In step S46, the mobile device 20 communicates with the platform server 3 to request registration data, such as the registered character ID and password corresponding to the designated sub-block. In this embodiment, only the platform server 3 has the corresponding predetermined registered character ID and password. The predetermined registered character ID and password are stored in the payment card 22 when it is manufactured. In step S47, after receiving the request, the platform server 3 reads the pre-stored personalized data (e.g., registered character ID and password) corresponding to the designated sub-block. The server then determines whether to allow the payment card 22 to perform the registration operation I. If so, step S48 is executed. If not, the process ends.

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

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

In step S52, the payment card 22 points the data location to the designated sub-block within 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 sub-block via the sub-menu address table 62 and writes the relevant information to the identified physical location, thus completing the registration process I.

The process then executes Formatting Operation II. In step S53, the mobile device 20 communicates with the platform server 3 to request the formatted role ID and password corresponding to the designated sub-block, as well as the personalized data. In this embodiment, only the platform server 3 has the formatted role ID and password corresponding to the predetermined formatted role ID and password. The predetermined formatted role ID and password are stored in the payment card 22 when it is manufactured. In step S54, after receiving the request, the platform server 3 reads the pre-stored personalized data (e.g., formatted role ID and password) corresponding to the designated sub-block. The server determines whether to allow the payment card 22 to execute Formatting Operation II. If so, step S55 is executed. If not, the process ends.

In step S55, the platform server 3 returns the formatted role ID and password and other personalized data corresponding to the designated sub-block 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 and a command to allow subsequent formatting operations to the payment card 22.

In step S57, the payment card 22 receives the formatted character ID and password. In step S58, the payment card 22 verifies whether the formatted character ID and password are correct. More specifically, the payment card 22 compares the formatted character ID and password with the predetermined formatted character ID and password. If the formatted character ID and password are the same as the predetermined formatted character ID and password, step S59 is executed. If the formatted character ID and password are different from the predetermined formatted character ID and password, the process ends.

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 illustrates a personalization operation using the second security mechanism. An authorized organization (e.g., X1 community) can write community member data to the payment card 22 of its community members and perform a personalization operation on one of the sub-blocks of block 5F.

Since the registration steps (such as steps S41 to S52) are similar to the first security mechanism, they are not described here in detail.

The main differences between the second security mechanism and the first are described below. In step S53, the mobile device 20 communicates with the authorized organization server 32 (operated by the X1 community) to request the formatted role ID and password corresponding to the designated sub-block. In step S54, the authorized organization server 32 (not the platform server 3) determines whether to allow the payment card 22 to perform formatting operation II. Furthermore, in step S55, the authorized organization server 32 (not the platform server 3) returns the formatted role ID and password, along with other personalized data corresponding to the designated sub-block, to the mobile device 20.

In addition, since the personalized data in this example is not open to everyone, an access ID and password combination can be set for the designated sub-block to prevent unauthorized access.

Figures 18A and 18B illustrate the steps involved in a personalization process using the third security mechanism. In the example of Figures 18A and 18B , a partner organization (e.g., member bank A) can write the user's account information into the payment card 22, and a sub-block of block 5G is configured to perform the personalization process.

In this example, since the registration steps (such as steps S41 to S52 ) are similar to the first security mechanism, they are not described in detail here.

The main differences between the third safety mechanism and the first safety mechanism are described as follows.

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

Figure 17 illustrates the steps for generating a formatted role password. In step S61, the payment institution system 4 requests the data required to generate the formatted role password from the platform server 3 and the partner organization server 33. The platform server 3 and the partner organization server 33 then return a portion of the data required to generate the formatted role password to the payment institution system 4 in steps S62 and S63, respectively. Then, in step S64, the payment institution system 4 uses the received data to generate the formatted role password.

18A , in step S53 the mobile device 20 requests the formatted role ID and password from the payment institution system 4. Then, in step S71 , the payment institution system 4 inquires the platform server 3 and the partner organization server 33 whether to authorize the formatting operation II.

Referring to Figure 18B , the platform server 3 and the partner server 33 each determine whether to allow the execution of Formatting Operation II. If not, the platform server 3 and the partner server 33 transmit a denial message to the payment institution system 4 in steps S73a and S73b, respectively. If so, the platform server 3 and the partner 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 server 33 determines that Formatting Operation II is allowed, it also transmits the formatted role ID and personalized 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 partner organization server 33. In step S76, the payment institution system 4 determines whether both the platform server 3 and the partner organization server 33 approve the execution of formatting operation II. If so, step S77 is executed. If at least one of them disapproves, the payment institution system 4 notifies the mobile device 20 that the process has ended. In step S77, the payment institution system 4 obtains the formatted role password generated in step S64. In step S79, the payment institution system 4 transmits the formatted role ID and password, along with the personalized data, back to the mobile device 20. The mobile device 20 and the payment card 22 then continue the aforementioned personalization process.

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

In this example, since the registration steps (such as steps S41 to S52 ) are similar to the first security mechanism, they are not described in detail here.

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

When performing personalization using one of the aforementioned security mechanisms, a predetermined formatted role ID and password are stored on the payment card 22, and the formatted role ID and password corresponding to the predetermined formatted role ID and password are stored on the platform server 3. However, after formatting operation II is completed, the formatted role password can be modified by one of the platform server 3, the authorized organization server 32, or the partner organization server 33 to prevent the damage caused by the password leaking during the manufacture of the payment card 22. Therefore, in the third security mechanism, the formatted role password is collaboratively generated by the platform server 3 and the partner organization server 33 and then stored in the payment institution system 4. The generated formatted role password can be used to update the formatted role ID and password after formatting operation 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 formatted role password can be pre-set by the platform server 3 or the authorized organization server 32. When the formatted role ID and password are transmitted to a mobile device 20 (step S55), the set formatted role password is also transmitted to update the formatted role 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 subsequent access to the designated sub-block. In this way, after the personalization operation is completed, each sub-block will be set to a specific access level based on the security mechanism used.

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

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

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 partner organizations (such as member banks or payment institutions) have write permissions.

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

In summary, by verifying the authenticity of the payment card 22 based on the payment instructions generated by the mobile device 20, payment attempts using fake cards can be detected. Furthermore, by instantly transmitting the payment instructions corresponding to the transaction list to the payment institution server 5, payments for each transaction can be processed promptly. This prevents losses caused by fraudulent payments or inconsistent transaction records. Furthermore, the secret data area 228 of the payment card 22 can be divided into multiple blocks, each associated with a storage security level. Each block is further divided into multiple sub-blocks, each requiring a personalized operation to activate. Therefore, the secret data area 228 functions as an information expansion library.

However, the above is merely an embodiment of the present invention and should not be used to limit the scope of implementation of the present invention. In other words, any simple equivalent changes and modifications made according to the claims and the contents of the patent specification of the present invention are still within the scope of the patent of the present invention.

Claims (15)

1. A mobile payment method, executed by a computer device capable of interacting with a mobile device having a payment card, the computer device communicating with a payment institution server; characterized in that: the mobile payment method comprises: Receive a list of transactions relating to a transaction and a payment related to that transaction; Establish a short-range wireless communication with the mobile device; The transaction list is transmitted to the mobile device via this short-range wireless communication. The mobile device receives a payment instruction via the short-range wireless communication, the payment instruction being generated by the mobile device based on at least the transaction list; Establish a session mechanism with the payment institution's server, which provides a secure communication channel between the computer device and the payment institution's server; Under this session mechanism, the payment instruction is transmitted to the payment institution's server. Upon receiving the payment instruction, the payment institution's server verifies the correctness of the payment card based on the payment instruction. After the payment institution's server verifies the payment card's correctness, the payment instruction further instructs the payment institution's server to process the payment according to the transaction list included in the payment instruction; and Under this session mechanism, a payment result is received from the payment institution's server, which is generated by the payment institution's server after the payment is completed; Prior to the step of establishing the short-range wireless communication, the method further includes: Generate data to be staked, which includes the transaction list; The step of transmitting the transaction list includes transmitting the data to be wagered to the mobile device via the short-range wireless communication. In the step of receiving the payment instruction via the short-range wireless communication, the data to be secured causes the mobile device to transmit the data to be secured to the payment card, and 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 compose the payment instruction and transmits the payment instruction to the computer device via the short-range wireless communication. 2. The mobile payment method according to claim 1, characterized in that: the computer device and the mobile device have near-field communication capability, and the step of establishing the wireless short-range communication includes: When the computer device and the mobile device are close to each other, the computer device automatically establishes a near-field communication with the mobile device as a short-range wireless communication. 3. The mobile payment method according to claim 1, characterized in that: in the step of receiving the payment instruction via the wireless short-range communication, the data to be secured also enables 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 also causes the payment institution server to generate a confirmation code using the same key based on the data of the transaction deposit included in the payment instruction, and causes the payment institution server to compare the transaction deposit and the confirmation code to identify the correctness of the payment card. 4. The mobile payment method according to claim 1, characterized in that: the step of establishing the session mechanism includes the following sub-steps: A session request is sent to the payment institution server, which causes the payment institution server to generate a session identifier upon receiving the session request and then send the session identifier to the computer device. After receiving the session identifier, a first authentication code is generated based on the session identifier and a first identification key pre-stored in the computer device; The first authentication code is transmitted to the payment institution server. The first authentication code causes the payment institution server to find a second authentication key pre-stored in the payment institution server and corresponding to the first authentication key of the computer device. The payment institution server generates a second authentication code based on the session identifier and the second authentication key. The payment institution server determines whether the first authentication code received from the computer device is the same as the second authentication code. When the payment institution server determines that the first authentication code is the same as the second authentication code, it sends a session response to the computer device to establish the session mechanism. 5. The mobile payment method according to claim 1, characterized in that: after the step of receiving the transaction list, it further comprises: Lock the transaction list. 6. A mobile payment method, executed by a mobile device having a payment card, the mobile device being able to interact with a computer device, the mobile device and the computer device communicating with a payment institution server; characterized in that: the mobile payment method comprises: Establish a short-range wireless communication with the computer device; Receive 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; A payment instruction is generated based on at least the transaction list, and transmitted 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 upon receiving the payment instruction, the payment institution server verifies the correctness of the payment card based on the payment instruction. After the payment institution server verifies the payment card is correct, the payment instruction further instructs the payment institution server to process the payment according to the transaction list included in the payment instruction; and Receive a payment result from the payment institution's server, which is generated by the payment institution's server after the payment is completed; The step of receiving the transaction list includes: The system receives data to be wagered from the computer device via the short-range wireless communication. The data to be wagered is generated by the computer device and includes the transaction list. The step of generating the transaction instruction includes: The mobile device transmits the data to be deposited to the payment card; The payment card generates a transaction deposit based on the data to be deposited and transmits the transaction deposit to the mobile device; and The mobile device uses the transaction deposit to form the payment instruction and transmits the payment instruction to the computer device via the wireless short-range communication. The payment instruction is transmitted from the computer device to the payment institution server through a session mechanism established between the computer device and the payment institution server. 7. The mobile payment method according to claim 6, characterized in that: the computer device and the mobile device have near-field communication capability, and the step of establishing the wireless short-range communication includes: When the computer device and the mobile device are close to each other, the mobile device automatically establishes a near-field communication with the computer device as a short-range wireless communication. 8. The mobile payment method according to claim 6, wherein the step of generating the payment instruction further includes the payment card using a key stored in the payment card to generate the transaction deposit; The payment instruction also causes the payment institution's server to generate a confirmation code based on the data of the deposit included in the payment instruction and using the same key, and causes the payment institution's server to compare the transaction deposit and the confirmation code to identify the correctness of the payment card. 9. The mobile payment method according to claim 6, characterized in that: before the step of establishing the wireless short-range communication, it further comprises: The mobile device outputs an instruction prompting the user to enter a startup password; Upon receiving the activation password, the mobile device transmits the activation password to the payment card. The payment card verifies the activation password, and when the activation password is correct, the payment card sends an access consent instruction to the mobile device; and The mobile device clears the temporarily stored startup password upon receiving the access consent instruction. 10. A mobile payment device capable of interacting with a computer device, the computer device communicating with a payment institution server; characterized in that: the mobile payment device comprises: A mobile device, including One processor, A memory unit, coupled to the processor, stores payment software. A card slot, coupled to the processor, is removably fitted with a payment card, allowing the mobile device to access the payment card. A short-range communication unit, coupled to the processor, and capable of communicating with the computer device, and A communication unit is coupled to the processor and is capable of communicating with the payment institution's server; When the processor executes the payment software, the payment software enables the mobile payment device to: Establish a short-range wireless communication with the computer device. The system receives a transaction list from the computer device via short-range wireless communication. The transaction list relates to a transaction and a payment related to that transaction. A payment instruction is generated based on at least the transaction list and transmitted to the computer device via the wireless short-range communication. The computer device provides the payment instruction to the payment institution server, which, upon receiving the instruction, verifies the correctness of the payment card. After the payment institution server verifies the payment card's correctness, the payment instruction further instructs the payment institution server to process the payment according to the transaction list included in the payment instruction. Receive a payment result from the payment institution's server, which is generated by the payment institution's server after the payment is completed; The step of receiving the transaction list includes: The system receives data to be wagered from the computer device via the short-range wireless communication. The data to be wagered is generated by the computer device and includes the transaction list. The step of generating the transaction instruction includes: The mobile device transmits the data to be deposited to the payment card; The payment card generates a transaction deposit based on the data to be deposited and transmits the transaction deposit to the mobile device; and The mobile device uses the transaction deposit to form the payment instruction and transmits the payment instruction to the computer device via the wireless short-range communication. The payment instruction is transmitted from the computer device to the payment institution server through a session mechanism established between the computer device and the payment institution server. 11. The mobile payment device according to claim 10, characterized in that: the mobile device can also execute a personalized application to perform a personalized operation for the payment card, the payment card comprising: A control module, including a controller chip, a control firmware, and an application interface; and A storage unit includes a hidden data area that can be accessed by the personalized application via the control firmware and the application interface only after a specific authorization sequence has been completed; The confidential data area is divided into multiple blocks, each block is associated with a storage security level and can store personalized data of a predetermined data type. The controller chip can perform the personalized operation and store the personalized data using one of multiple security mechanisms, which corresponds to the storage security level of the block. 12. The mobile payment device according to claim 11, characterized in that: the personalization process includes: In a registration process, one block is selected to store the personalized data; A formatting operation is performed whereby the selected block is formatted to conform to the predetermined data type, so that the personalized data can subsequently be stored in the selected block; and A personalized data write job is performed whereby the payment card stores the personalized data in the selected block. 13. The mobile payment device according to claim 12, characterized in that: each block is divided into multiple sub-blocks, during the registration operation, the payment card further selects one of the sub-blocks of the selected block to store the personalized data, and during the formatting operation, the selected sub-block is formatted; Each sub-block stores a pre-defined registration role ID and password for authorizing the registration job, and a pre-defined formatting role ID and password for authorizing the formatting job; The payment card receives a registered role ID and password, and the registration process is only executed if the registered role ID and password are the same as the pre-registered role ID and password. The payment card receives a formatted role ID and password, and the formatting operation is only performed if the formatted role ID and password are the same as the predetermined formatted role ID and password. 14. The mobile payment device according to claim 13, wherein the payment card can perform the personalization operation according to one of a first security mechanism, a second security mechanism, a third security mechanism and a fourth security mechanism; In this 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. 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, which is authorized by the platform server to provide the formatted role ID and password. In this 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 is generated by the platform server and a cooperating organization server, and the personalized data is provided by the cooperating organization server. The third party is authorized by the platform server to provide the formatted role ID and password. In this fourth security mechanism, the registered role ID and password, as well as the formatted role ID and password, are received from the platform server, while the personalized data is received from the personalized application software via the control firmware and the application interface. 15. The mobile payment device according to claim 12, characterized in that: the registration process includes the following sub-steps: Upon receiving a registration instruction, select a sub-block from one of the blocks, and A formatted role ID and password are received from a third party, which operates on the security mechanism of the selected block. In the formatting operation, when it is determined that the received formatting role ID and password are the same as the predetermined formatting role ID and password stored in the selected sub-block, the selected sub-block is formatted. In the personalized data writing operation, the personalized data is stored in the selected sub-block.