Method, device and secure element for secure financial transactions on a device

Abstract

A method, device and secure element for conducting a secure financial transaction on a device are disclosed. The device includes a central processing unit; a communication interface for establishing communication between the device and a financial institution associated with a financial account; an interface for obtaining financial account related data; a secure element for processing at least a portion of the financial account related data obtained by the interface; and control logic for obtaining an amount of a purchase to be debited from the financial account and for obtaining a transaction authorization from the financial institution associated with the financial account, the transaction authorization being based at least in part on data processed by the secure element independently of data processed by the central processing unit. A method of conducting a secure financial transaction and a computer program product for execution by the secure element are also disclosed.

Description

[0001] This application is a divisional application of patent application 201380011751.7, filed on February 28, 2013, entitled "Method, apparatus and security element for conducting secure financial transactions on an equipment".

[0002] Cross-references to related applications

[0003] This application incorporates by reference all of the following U.S. provisional application which is permitted to be incorporated by reference: namely, application number US61 / 604,613 filed by Sébastien FONTAINE et al. on February 29, 2012, entitled “SYSTEM AND METHOD FORCONDUCTING A SECURED TRANSACTION ON A DEVICE”. Technical Field

[0004] This invention relates to methods, apparatus, and security elements for conducting secure transactions on equipment, and particularly to secure financial transactions. Background Technology

[0005] This section is intended to introduce the reader to various aspects that may be relevant to the aspects described and / or claimed below in this disclosure. This discussion is intended to help provide the reader with background information to facilitate a better understanding of the various aspects of the invention. Therefore, it should be understood that these statements are read in this context and not as an admission of prior art.

[0006] Merchants frequently use payment terminals to conduct secure financial transactions with customers. These customers typically hold payment cards issued by financial institutions or payment card providers. In some cases, the payment card contains a magnetic stripe and / or a smart card chip, allowing the transaction to be initiated by swiping the card in the payment terminal's magnetic stripe reader or by inserting the payment card into the payment terminal's smart card reader. In other cases, the payment card may be a contactless transaction that allows the transaction to occur by presenting the payment card near the payment terminal. To ensure security in financial transactions, transaction standards such as Europay, Mastercard, and Visa (EMV) have been developed and used to authenticate both the payment terminal and the payment card. However, due to various factors, including the technical complexity of meeting security standards, payment terminals used for secure financial transactions are typically devices specifically designed for the execution of financial transactions.

[0007] Therefore, there is a need in the prior art for a method, apparatus, and security element for secure transactions from any device, particularly from devices that provide functions other than the execution of purely financial transactions. Summary of the Invention

[0008] The present invention aims to provide a method for conducting secure financial transactions on a device serving as a payment terminal, the device comprising a central processing unit and a secure element. The method includes: obtaining a purchase amount to be debited from a financial account; obtaining data related to the financial account via the device; and obtaining transaction authorization from the financial institution associated with the financial account. The authorization is based at least in part on data processed separately by the secure element, independent of the data processed by the central processing unit. The data processed separately by the secure element includes at least a portion of the obtained financial account-related data.

[0009] Another objective of this invention is to provide a device as a payment terminal for conducting secure financial transactions. The device includes: a central processing unit; a communication interface configured to establish communication between the device and a financial institution associated with a financial account; an interface for obtaining data related to the financial account; a security element for processing at least a portion of the financial account-related data obtained by the interface; and control logic configured to obtain purchase amounts debited from the financial account and to obtain transaction authorization from the financial institution associated with the financial account. Transaction authorization is at least partially based on data processed separately by the security element, independent of the data processed by the central processing unit. The data processed separately by the security element includes at least a portion of the obtained financial account-related data.

[0010] Another objective of this invention is to provide a secure element housed in a device serving as a payment terminal. The secure element includes instructions for operating a Eurocard, Mastercard, and Visa (EMV) transaction module configured to process data obtained from the device's interface according to authentication standards; and an operating system (OS) configured to process data provided by the EMV transaction module according to Level 1 of the EMVCo standard.

[0011] Another object of the present invention is to provide a computer program product executed by a device as a payment terminal, the device having a computer-readable storage medium in which computer program logic is embedded. The computer program logic, when executed by the device, runs a Eurocard, Mastercard, and Visa (EMV) transaction module configured to process data obtained from the device's interface according to authentication standards; and an operating system (OS) configured to process data provided by the EMV transaction module according to Level 1 of the EMVCo standard.

[0012] Another objective of this invention is a transaction module running on a secure element of a device serving as a payment terminal to perform: receiving a request to conduct a financial transaction from a payment control application running on the device; obtaining data related to a financial account from a payment device via the device's interface; establishing a secure communication channel with a server of a financial institution related to the financial account via the device's communication interface; sending an authorization request to the server on the secure communication channel to execute the financial transaction, the authorization request including at least a portion of the data related to the financial account; receiving a response from the server on the secure communication channel to the authorization request; processing the response to the authorization request to generate a financial transaction status; and sending the financial transaction status to the payment control application.

[0013] This invention application provides the following:

[0014] 1) A method for conducting secure financial transactions on a device serving as a payment terminal, said device comprising a central processing unit and a security element, the method comprising:

[0015] Obtain the purchase amount debited from the financial account;

[0016] Data about the financial account is obtained through the device; and

[0017] Transaction authorization is obtained from the financial institution associated with the financial account, the authorization being based at least in part on data processed separately by the security element, independent of the data processed by the central processing unit;

[0018] The data processed separately by the security element includes at least a portion of the data obtained regarding the financial account.

[0019] 2) According to the method of 1), wherein the data concerning the financial account is located outside the device.

[0020] 3) According to the method of 1), obtaining the transaction authorization from the financial institution associated with the financial account includes transmitting the data processed separately by the security element to the financial institution to generate the transaction authorization.

[0021] 4) According to the method of 1), wherein obtaining the data about the financial account includes obtaining the data through one of the contactless interface of the device and the smart card reader of the device.

[0022] 5) According to the method of 4), wherein obtaining the data about the financial account includes one of contact reading data from a payment card and contactless reading data from a payment card and a mobile device.

[0023] 6) The method according to 1), wherein obtaining the data about the financial account includes obtaining the data through the magnetic stripe reader of the device.

[0024] 7) According to the method of 6), wherein obtaining the data about the financial account includes reading data from the magnetic stripe of the payment card by contact.

[0025] 8) The method according to 1), wherein the data is processed by the secure element to obtain the authorization from the financial institution based on the transaction process certified by Pan-European Card, Mastercard and Visa EMV.

[0026] 9) The method according to 1), wherein obtaining the data about the financial account includes obtaining at least one of a personal identification number PIN, a signature, a password, and biometric data through the device.

[0027] 10) The method according to 1), wherein the data concerning the financial account includes at least one of a key, a certificate, and a payment card number.

[0028] 11) A device as a payment terminal for conducting secure financial transactions, the device comprising:

[0029] Central processing unit;

[0030] A communication interface configured to establish communication between the device and the financial institution associated with the financial account;

[0031] An interface for obtaining data about the financial account;

[0032] A security element for processing at least a portion of the data about the financial account obtained through the interface; and

[0033] Control logic is configured to obtain a purchase amount debited from the financial account and to obtain transaction authorization from the financial institution associated with the financial account, the transaction authorization being based at least in part on data processed separately by the security element, independent of the data processed by the central processing unit;

[0034] The data processed separately by the security element includes at least a portion of the data obtained regarding the financial account.

[0035] 12) The device according to 11), wherein the data concerning the financial account is located outside the device.

[0036] 13) The device according to 11), wherein the control logic is configured to transmit the data, which is processed separately by the security element, to the financial institution to generate the transaction authorization.

[0037] 14) The device according to 11), wherein the interface is one of a smart card reader and a contactless interface, the smart card reader being configured to read data from a payment card in a contact manner, and the contactless interface being configured to receive data in a contactless manner from a payment card and a mobile device.

[0038] 15) The device according to 14), wherein the payment card is Visa. Authentication card, Mastercard Authentication card, American Express Authentication card, Interac Authentication Card and Discoverer One of the authentication cards.

[0039] 16) The device according to 14), wherein the mobile device is embedded in Visa Authentication module, Mastercard Authentication module, American Express Authentication module, Interac Authentication module, discoverer Authentication module and One of the modules.

[0040] 17) The device according to 11), wherein the interface is a magnetic stripe reader configured to read data from the magnetic stripe of a payment card in a contact manner.

[0041] 18) The device according to 11), wherein the security element is configured to be compatible with Pan-European Card, Mastercard and Visa EMV transaction processes.

[0042] 19) The device according to 11), wherein the safety element is configured according to EMVCo, The authentication standard in PCI SSC processes the data obtained from the interface.

[0043] 20) The device according to claim 11), wherein the security element is embedded in a chipset, the chipset including instructions to operate:

[0044] Pan-European Card, Mastercard, and Visa EMV transaction modules are configured to process data obtained from the interface according to authentication standards; and

[0045] The operating system (OS) is configured to process data provided by the EMV transaction module in accordance with Level 1 of the EMVCo standard.

[0046] 21) The device according to 20), wherein the OS is One of the global platforms.

[0047] 22) The device according to 20), wherein the EMV transaction module is one of a contactless transaction module and a contact transaction module.

[0048] 23) The device according to 20), wherein the certification standard is from EMVCo, And one of the certification standards of PCI SSC.

[0049] 24) The device according to 23), wherein the EMV transaction module is certified according to at least one of the certification standard level 2 and the certification standard level 3.

[0050] 25) The device according to 11), wherein the central processing unit runs a financial transaction application configured to control the security element without accessing certain data of the data processed by the security element.

[0051] 26) The device according to 11), wherein the security element is embedded in one of the chipset embedded in the circuitry of the device, the user identity module SIM card, the secure digital SD card, the non-volatile memory card, and the housing of the device.

[0052] 27) The device according to 11), wherein the control logic is configured to obtain at least one of a personal identification number PIN, a signature, a password and biometric data from the user of the device.

[0053] 28) The device according to claim 11), wherein the device is a multi-purpose device, a mobile device, a mobile phone device, The model, The model, Models, tablets, The model, The model, Models, laptops, personal computers, printers, money counters, payment terminals, ATMs, vending machines, televisions, video game systems, internet-connected set-top boxes, and Apple Inc. one of the.

[0054] 29) The device according to 11), wherein the data concerning the financial account includes at least one of a key, a certificate, and a payment card number.

[0055] 30) A security element for installation in a device serving as a payment terminal, the security element comprising instructions to operate:

[0056] Pan-European Card, Mastercard, and Visa EMV transaction modules are configured to process data obtained from the device's interface according to authentication standards; and

[0057] The operating system (OS) is configured to process data provided by the EMV transaction module in accordance with Level 1 of the EMVCo standard.

[0058] 31) The security element according to 30), wherein the OS is One of the global platforms.

[0059] 32) The security element according to 30), wherein the security element is embedded in one of the chipset embedded in the circuitry of the device, the user identity module SIM card, the secure digital SD card, the non-volatile memory card, and the housing of the device.

[0060] 33) According to the security element described in 30), wherein the EMV transaction module is one of a contactless transaction module and a contact transaction module.

[0061] 34) The security element according to 30), wherein the certification standard is from EMVCo, And one of the certification standards of PCI SSC.

[0062] 35) According to the security element of 34), wherein the EMV transaction module is certified according to at least one of the certification standard level 2 and the certification standard level 3.

[0063] 36) According to the security element described in 30), wherein the EMV transaction module performs:

[0064] Receive requests to conduct financial transactions from a payment control application running on the device;

[0065] Data about the financial account is obtained from the payment device via the interface of the device;

[0066] A secure communication channel is established between the device's communication interface and the server of the financial institution associated with the financial account.

[0067] An authorization request to execute the financial transaction is sent to the server via the secure communication channel, the authorization request including at least a portion of the data related to the financial account;

[0068] Receive the response to the authorization request from the server through the secure communication channel;

[0069] The response to the authorization request is processed to generate the state of the financial transaction; and

[0070] The status of the financial transaction is sent to the payment control application.

[0071] 37) According to the security element of 36), wherein the request to conduct the financial transaction includes a purchase amount credited to the debit side of the financial account.

[0072] 38) According to the security element of 36), wherein the interface of the device is a contactless interface configured to receive data contactlessly, and the payment device is one of a payment card and a mobile device.

[0073] 39) According to the security element of 36), wherein the interface of the device is a smart card reader configured to read data by contact, and the payment device is a payment card.

[0074] 40) According to the security element of 36), wherein the interface of the device is a magnetic stripe reader configured to read data by contact, and the payment device is a payment card with a magnetic stripe.

[0075] 41) According to the security element of 36), the data associated with the financial account includes at least one of a key, a certificate, and a payment card number.

[0076] 42) A computer program product executed by a device serving as a payment terminal, said device having a computer-readable storage medium in which computer program logic is embedded, said computer program logic operating when executed by said device:

[0077] Pan-European Card, Mastercard, and Visa EMV transaction modules are configured to process data obtained from the device's interface according to authentication standards; and

[0078] The operating system (OS) is configured to process data provided by the EMV transaction module in accordance with Level 1 of the EMVCo standard.

[0079] 43) The computer program product according to 42), wherein the EMV transaction module performs:

[0080] Receive requests to conduct financial transactions from a payment control application running on the device;

[0081] Data about the financial account is obtained from the payment device via the interface of the device;

[0082] A secure communication channel is established between the device's communication interface and the server of the financial institution associated with the financial account.

[0083] An authorization request to execute the financial transaction is sent to the server via the secure communication channel, the authorization request including at least a portion of the data related to the financial account;

[0084] Receive the response to the authorization request from the server through the secure communication channel;

[0085] The response to the authorization request is processed to generate the state of the financial transaction; and

[0086] The status of the financial transaction is sent to the payment control application.

[0087] 44) The computer program product according to 43) wherein the request to conduct the financial transaction includes a purchase amount credited to the debit side of the financial account.

[0088] 45) The computer program product according to 43), wherein the interface of the device is a contactless interface configured to receive data contactlessly, and the payment device is one of a payment card and a mobile device.

[0089] 46) The computer program product according to 43), wherein the interface of the device is a smart card reader configured to read data by contact, and the payment device is a payment card.

[0090] 47) The computer program product according to 43), wherein the interface of the device is a magnetic stripe reader configured to read data by contact, and the payment device is a payment card with a magnetic stripe.

[0091] 48) The computer program product according to 43), wherein the data related to the financial account includes at least one of a key, a certificate, and a payment card number.

[0092] 49) The computer program product according to 43), wherein the OS is One of the global platforms.

[0093] 50) The computer program product according to 43), wherein the computer program logic is run by a secure element.

[0094] 51) The computer program product according to 43), wherein the security element is embedded in one of the chipset embedded in the circuitry of the device, the SIM card, the secure digital SD card, the non-volatile memory card, and the housing of the device.

[0095] 52) The computer program product according to 43), wherein the EMV transaction module is one of a contactless transaction module and a contact transaction module.

[0096] 53) The computer program product according to 43), wherein the certification standard is from EMVCo, And one of the certification standards of PCI SSC.

[0097] 54) The computer program product according to 53), wherein the EMV transaction module is certified according to at least one of the certification standard level 2 and the certification standard level 3.

[0098] 55) The computer program product according to 42), wherein the computer-readable storage medium is a non-transitory computer-readable storage medium.

[0099] 56) A computer program product executed by a device serving as a payment terminal, said device having a computer-readable storage medium in which computer program logic is embedded, said computer program logic, when executed by said device, runs a payment control application to perform:

[0100] Obtain the purchase amount debited from the financial account;

[0101] The purchase amount is transmitted to a transaction module running on the secure element of the device;

[0102] A communication channel is established between the transaction module running on the secure element and the financial institution's server; and

[0103] The transaction module running on the security element receives the status of financial transactions;

[0104] The state of the financial transaction corresponds to a response to an authorization request to execute the financial transaction, which is sent by the transaction module running on the secure element to the server of the financial institution through an established communication channel.

[0105] 57) A computer program product executed by a device serving as a payment terminal, said device having a computer-readable storage medium in which computer program logic is embedded, said computer program logic, when executed by said device, running a transaction module to perform:

[0106] Receive requests to conduct financial transactions from a payment control application running on the device;

[0107] Data about the financial account is obtained from the payment device via the interface of the device;

[0108] A secure communication channel is established between the device's communication interface and the server of the financial institution associated with the financial account.

[0109] An authorization request to execute the financial transaction is sent to the server via the secure communication channel, the authorization request including at least a portion of the data related to the financial account;

[0110] Receive the response to the authorization request from the server through the secure communication channel;

[0111] The response to the authorization request is processed to generate the state of the financial transaction; and

[0112] The status of the financial transaction is sent to the payment control application.

[0113] 58) A method for conducting secure financial transactions on a device serving as a payment terminal, the device comprising a central processing unit and a secure element, the method comprising:

[0114] Obtain the purchase amount debited from the financial account;

[0115] Data about the financial account is obtained through the device, and the data about the financial account is located outside the device; and

[0116] Transaction authorization is obtained from the financial institution associated with the financial account, and the authorization is based at least in part on data processed separately by the security element, independent of the data processed by the central processing unit;

[0117] The data processed separately by the security element includes at least a portion of the data obtained about the financial account, and the data processed separately by the security element is transmitted to the financial institution to generate transaction authorization.

[0118] 59) A device as a payment terminal for conducting secure financial transactions, the device comprising:

[0119] Central processing unit;

[0120] A communication interface configured to establish communication between the device and the financial institution associated with the financial account;

[0121] An interface for obtaining data about the financial account, the data about the financial account being located outside the device;

[0122] A security element for processing at least a portion of the data about the financial account obtained through the interface; and

[0123] Control logic is configured to obtain a purchase amount debited from the financial account and to obtain transaction authorization from the financial institution associated with the financial account, the transaction authorization being based at least in part on data processed separately by the security element, independent of the data processed by the central processing unit;

[0124] The data processed separately by the security element includes at least a portion of the data obtained about the financial account, and the data processed separately by the security element is transmitted to the financial institution to generate the transaction authorization. Attached Figure Description

[0125] The invention will now be described with reference to the accompanying drawings, in which:

[0126] Figure 1 This is a schematic representation of a system for conducting secure financial transactions from a secure device, according to one embodiment of the present invention;

[0127] Figure 2 This is a graphical representation of a contactless transaction occurring according to one embodiment of the present invention;

[0128] Figure 3 This is a flowchart describing a method for conducting secure financial transactions according to one embodiment of the present invention;

[0129] Figure 4 This is a simplified block diagram of a device on which secure financial transactions can take place, according to one embodiment of the present invention;

[0130] Figure 5 According to one embodiment of the present invention Figure 4 A diagrammatic representation of the safety components embedded in the device;

[0131] Figure 6 It is a schematic representation of the architecture of various devices incorporating safety elements according to various embodiments of the present invention;

[0132] Figure 7 This is a graphical representation of the software stack that enables the payment control application to communicate with the software on the security element in one embodiment of the present invention;

[0133] Figure 8a , 8b 8c is a graphical representation of the software architecture of the security element in various embodiments of the present invention;

[0134] Figure 9a , 9b 9c is a flowchart representation of the communication flow between a security element and a plurality of other entities for conducting secure financial transactions on the device, according to one embodiment of the present invention;

[0135] Figure 10 It is a graphical representation of a secure communication channel between security components and financial institutions;

[0136] Figure 11 This is a graphical representation of the loading, updating, and configuration processes of payment software in a secure element according to one embodiment of the present invention;

[0137] Figure 12 This is a flowchart describing the payment software loading process, update process, and configuration process in a secure element according to an embodiment of the present invention; and

[0138] Figure 13 This is a flowchart describing a payment control application that communicates with software on a security element according to one embodiment of the present invention.

[0139] In the accompanying drawings, embodiments of the invention are illustrated by way of example. It should be clearly understood that the specification and drawings are for illustrative and understanding purposes only. They are not intended to be limiting definitions of the invention. Detailed Implementation

[0140] The present invention will now be described in conjunction with one or more contemplated embodiments. The described embodiments are intended as examples of the invention and not as limiting its scope. In other words, while attention is focused on specific embodiments of the invention, those embodiments are not intended to limit the invention. Rather, the examples provided below are intended to illustrate the broad scope of the invention.

[0141] the term

[0142] Throughout this disclosure, references are made to secure transactions (e.g., but not limited to, contact and contactless transactions), secure elements (e.g., but not limited to, chipsets, security chipsets, hardware with embedded secure elements, software with embedded secure elements, or firmware with embedded secure elements), and security standards. Examples of security standards include, but are not limited to, Pan-European Card, Mastercard and Visa (EMV), EMVCo, and PCI SSC (Payment Card Industry Security Standards Committee, which defines the security standards for financial transactions) and References to secure transactions, secure elements, and secure standards are for illustrative purposes and are intended to demonstrate the invention and not to limit its scope.

[0143] Secure element: A processing entity characterized by specific hardware and / or software components, the software components being subject to certification to ensure a specific level of security according to specific security standards. From a hardware perspective, a secure element includes components typically found in a computing entity: at least one microcontroller (e.g., CPU), memory (e.g., RAM or FLASH memory), communication interfaces, etc. Specific hardware components may also be included to implement specific functions specific to the secure element. For example, an encryption accelerator may be included. Similarly, modules providing RF and electrostatic isolation may be included to protect the secure element from eavesdropping. In a financial transaction environment, the certification of the secure element ensures that various financial entities are willing to use the secure element to store and process critical financial data, and to execute secure financial transactions using that critical financial data.

[0144] Information / Data: The terms “information” and “data” are used interchangeably and have similar meanings for the purposes of this disclosure.

[0145] Security standards may include multiple security levels, but are not required to be limited to, for example, Level 1, Level 2, or Level 3. For example, Level 1 may correspond to a higher security level than Level 2, and vice versa. For example, the EMCo standard may provide examples of security levels, as well as approval and certification standards, such as terminal type approval processes, security assessment processes, card type approval processes, or mobility type approval processes.

[0146] For example, the terminal type approval process can be a mechanism for testing compatibility with Eurocard, Mastercard, and Visa (EMV) specifications. Terminal type approval provides a level of confidence that interoperability and consistent behavior between compatible applications can be achieved. In this example, terminal type approval testing can be divided into two levels, Level 1 and Level 2. Level 1 approval tests compatibility with electromechanical characteristics, logical interfaces, and transport protocol requirements defined in the EMV specifications. Level 2 approval tests compatibility with requirements such as those for debit / credit applications defined in the EMV specifications. Furthermore, terminal type approval testing can include Level 3 approval, which guarantees secure communication between applications running on the terminal and financial institutions.

[0147] For example, a security assessment process might aim to provide EMVCo member issuers with information on general security features and the suitability of smart card-related products and the use of integrated circuit (IC) chip-based tokens. The EMVCo security assessment process can be designed to ensure a robust security foundation for these products at the product line and component levels. Alternatively, a security assessment process might aim to provide PCI SSC member issuers with information on general security features and the suitability of smart card-related products and the use of integrated circuit (IC) chip-based tokens. In the case of PCI SSC, the software layer can also be covered by security standards and requirements.

[0148] For example, the card type approval process can create mechanisms for testing compatibility with EMV and Common Payment Application (CPA) specifications. The card type approval process can provide a level of confidence that interoperability and consistent behavior between compatible applications can be achieved. Separate card type approval processes can be defined for cards implementing the Common Core Definition (CCD) specification or the CPA specification.

[0149] For example, the mobile type approval process may include a contactless mobile payment (CMP) product type approval process to create a mechanism for testing compatibility with EMV specifications. The CMP product type approval process can provide a level of confidence that interoperability and consistent behavior between compatible mobile products can be achieved.

[0150] Contactless Interface: A contactless interface is an interface between two entities (e.g., a mobile phone and a credit card in the context of this disclosure) that allows the exchange of data between the two entities without physical contact. Although Near Field Communication (NFC) interfaces are mentioned in this disclosure, any technology and communication protocol that allows contactless exchange of data between two entities is relevant to this disclosure.

[0151] Systems and methods for conducting secure financial transactions on devices

[0152] Figure 1 A schematic representation of a system 9 for secure financial transactions from device 12 according to one embodiment of the present invention is shown. In one embodiment of the invention, customer 4 has a contractual relationship with a financial institution 6 that holds the customer's financial account. Financial institution 6 may be a bank that maintains the customer's checking account or credit card account. Financial institution 6 provides customer 4 with an authentication token to provide strong authentication during financial transactions. Such an authentication token may be, for example, a payment card and / or a securely unique identification component that may be embedded in customer 4's device (e.g., a mobile phone). The payment card is held by a payment card company 8 and may be, for example, but not necessarily limited to, from... The company's debit card or from such and A credit card from one of the credit card companies. Payment cards can be made concrete using magnetic stripes, smart card chips, and / or tags with radio frequency identification (RFID) circuitry to convey data about a customer's financial account. Tags including RFID circuitry can provide contactless transaction capabilities, particularly offering security standards compatible with Eurocard, Mastercard, and Visa (EMV) (e.g., Visa). Mastercard Interac discoverer It supports contactless transaction capabilities. In an alternative implementation, the tag containing RFID circuitry can be embedded in other supporting devices instead of the payment card, such as in a device like a mobile phone (e.g., embedded in the customer's device). (Module). Data about a customer's financial account can be any kind of data that allows the financial account to be identified during a transaction. For example, but not limited to, such data can include keys, certificates, and payment card numbers.

[0153] Seller 2 has a contractual relationship with financial institution 10, which holds the seller's financial account. Financial institution 10 may be a bank that maintains the seller's checking account or credit card account. Financial institution 10 allows seller 2 to conduct financial transactions with customers (e.g., with customer 4) through gateway 11. Although gateway 11 is shown in Figure 1However, it should be understood that financial transactions can occur directly between the retailer 2 and the financial institution 10 without going through a gateway between them. In an embodiment of the invention, the retailer 2 can initiate and complete secure financial transactions with the customer 4 via device 12. Device 12 includes a secure element 16 and an interface 18. In one embodiment of the invention, interface 18 can be, for example, but not limited to, a magnetic stripe reader, a smart card reader, or a near field communication (NFC) interface. Interface 18 allows contact and / or contactless transactions to occur on device 12 between the customer 4's payment card and / or the customer 4's device. It should be understood that contact transactions can be, for example, but not limited to, swiping a magnetic stripe in a magnetic stripe reader or contacting a smart card chip with a smart card reader. Furthermore, it should be understood that contactless transactions can include transactions in which the payment card or mobile device can physically contact the contactless reader in this transaction. Similarly, contactless transactions can involve communication that occurs contactlessly, but in the process of occurring, the payment card or mobile device physically contacts the contactless reader. In one embodiment of the invention, the transaction is a protected financial transaction, and the transaction is compatible with the EMV transaction standard and an applicable PCI SSC standard. The applicable PCI SSC standard may be one of Payment Application Data Security Standard (PA-DSS), PIN Transaction Security (PTS), and / or Peer-to-Peer Encryption (P2PE). In another embodiment, the transaction may be compatible with other secure transaction standards.

[0154] Now simultaneously Figure 1 and 2 For reference, among which Figure 2 It happened Figure 1 A diagram illustrating a contactless transaction between customer 4 and retailer 2. In one embodiment of the invention, the transaction is a secure financial transaction initiated by retailer 2 via device 12, which communicates with financial institution 10 and payment card company 8. Retailer 2 initiates the transaction by entering the purchase amount into device 12. Customer 4 then presents her / his payment card, such as Visa. The contactless credit card 13 is brought close to the interface 18 of the device 12, in this example, the NFC interface, to establish a Visa account. Contactless activation of communication between credit card 13 and secure element 16 of device 12. Once secure element 16 completes communication from Visa... After contactless activation of credit card 13 and data readout, device 12 can prompt customer 4 to enter a personal identification number (PIN), signature, password, biometric data, or any data that allows verification of customer identity. Once the required information is entered by customer 4, device 12 requests financial transaction authorization from customer 4's financial institution 6 and / or payment card company 8. Then, customer 4's financial institution 6 and / or payment card company 8 authorizes or rejects (as applicable) the financial transaction and communicates with device 12 to notify of the authorization status. Once the financial transaction status is received by device 12, customer 4 is notified that the financial transaction has been accepted or rejected by customer 4's financial institution 6 and / or payment card company 8. In other embodiments of the invention, customer 4 uses a Mastercard... Contactless activation of credit card 15 and mobile phone (or tablet) 17 can initiate financial transactions. Mobile phone (or tablet) 17 includes RFID circuitry that provides secure contactless transaction capabilities. In other embodiments of the invention, the secure element 16 and interface 18 may be embedded in other devices besides device 12. For example, but not limited to, the secure element 16 and interface 18 may be embedded in devices such as tablet 14, cash register 20, printer 22, vending machine 24, payment terminal 26, and / or ATM 28 (in which case customer 4 can transact without interacting with the retailer 2, i.e., by interacting only with her / his payment card company 8 or her / his financial institution 6). Other examples of devices in which the secure element 16 and interface 18 may be embedded include, but are not limited to, television sets, video game systems, internet-connected set-top boxes, or Apple products.

[0155] Figure 3 This is a flowchart describing a method 111 for conducting a transaction according to one embodiment of the present invention. Method 111 can be employed to conduct various types of transactions, such as, but not limited to, secure contact and / or contactless financial transactions. Method 111 can be specifically implemented in software applications, such as in a point-of-sale application 112 running on device 12. According to method 111, the point-of-sale application 112 may include various software components that allow transactions between customer 4 and retailer 2. In particular, some of the various software components may be executed on the secure element 16 of device 12, while other software components are executed by the CPU of device 12.

[0156] For illustrative purposes, interface 18 of device 12 is an NFC interface capable of reading data on contactless enabled payment cards. Method 111 begins in step 100 by the seller 2 entering the purchase amount into device 12. Then, in step 102, customer 4 presents her / his payment card, for example, a Visa card. Contactless activation of credit card 13 by bringing it close to the NFC interface 18 of device 12 to establish Visa Contactless activation of communication between credit card 13 and secure element 16 of device 12. Once secure element 16 completes communication from Visa... In step 104, the device 12 prompts the customer 4 to enter a personal identification number (PIN), signature, password, biometric data, or any data that allows verification of the customer's identity. Once the required information is entered by the customer 4, in step 106, the device 12 requests financial transaction authorization from the customer 4's financial institution 6 and / or payment card company 8. The customer 4's financial institution 6 and / or payment card company 8 then authorizes or rejects (as applicable) the financial transaction and communicates with the device 12, notifying them of the authorization status in step 108. Once the financial transaction status is received by the device 12, in step 110, the customer 4 is notified that the financial transaction has been accepted or rejected by the customer 4's financial institution 6 and / or payment card company 8. The financial transaction status can be provided to the customer 4 in the form of a transaction receipt. The transaction receipt can be an electronic receipt displayed on the device 12 or sent to the customer electronically (e.g., via email, Multimedia Messaging Service (MMS), and / or Short Message Service (SMS)). The transaction receipt can also be a physical receipt (e.g., a paper receipt) generated by a printer communicating with the device 12.

[0157] In another embodiment of the invention, device 12 can securely read data from membership cards, gift cards, prepaid cards, coupon cards, reward cards, points cards, discount cards, club cards, etc.; and a secure transaction is executed by the card-associated institution (which identifies the cardholder as a member of the membership program). Communication between device 12 and the card can be a contactless transaction, for example, using the NFC interface 18 of device 12. The secure transaction with the card-associated institution can exist in verifying the availability of sufficient membership points in the customer's account.

[0158] Devices for conducting secure financial transactions

[0159] By reference Figure 4 Additional details about device 12 can be better understood. Figure 4 This is a block diagram illustrating various exemplary components and features of an illustrative device 12 according to one embodiment of the present invention. The device may include a security element 16, an NFC interface 19, a smart card reader 55, a SIM card slot 36, a communication interface 38, a control circuit 40, a central processing unit (CPU) 42 on which an operating system (OS) of the device 12 runs, an input / output (I / O) controller 44, a display 46, a keyboard 48, and a printer (not included in the main unit). Figure 4The CPU 42 includes a magnetic stripe reader 52 and a memory 54. Examples of operating systems running on the CPU 42 include, but are not limited to, those available from Apple Inc. or versions thereof; Android available from Google. or a derivative version thereof; the PlayBook available from RIM. or versions thereof. It should be understood that other proprietary OSes or custom OSes can be used in the same way without departing from the scope of this invention.

[0160] In one embodiment of the invention, device 12 is controlled by CPU 42 and control circuitry 40 to provide the processing power required to execute the operating system of device 12. CPU 42 may include a single processor or multiple processors. For example, CPU 42 may include a "general-purpose" microprocessor, a combination of general-purpose and special-purpose microprocessors, an instruction set processor, a graphics processor, or a special-purpose processor. Control circuitry 40 may include one or more data buses for transferring data and instructions between components of device 12. Control circuitry 40 may also include onboard memory for caching purposes.

[0161] In some embodiments of the invention, information used by CPU 42 may be located in memory 54. Memory 54 may be non-volatile memory, such as read-only memory, flash memory, hard disk drive, or any other suitable optical, magnetic, or solid-state computer-readable medium, and combinations thereof. Memory 54 may be used to store data required for the operation of CPU 42, as well as other data required by device 12. For example, memory 54 may store firmware of device 12. Firmware may include an operating system, as well as other programs that enable various functions of electronic device 12, graphical user interface (GUI) functions, or processor functions. Memory 54 may be a GUI storage component, such as graphical elements, screens, and templates. Memory 54 may also include data files such as connection information (e.g., information used to establish communication), or data that allows device 12 to run a payment control application. The payment control application is one of the software components of point-of-sale application 112 (executed by CPU 42 of device 12). The data stored in memory 54 that allows device 12 to run the payment control application includes data that generates a GUI on display 46 for the processing power required to conduct and complete secure financial transactions. Furthermore, memory 54 can store data controlling the activation / deactivation of NFC interface 19, and when activated, control the operating mode of NFC interface 19 (e.g., passive or active). For example, NFC interface 19 can operate in passive mode unless point-of-sale application 112 is running.

[0162] Communication interface 38 can provide additional connectivity channels for receiving and transmitting information. For example, communication interface 38 can provide connectivity to allow device 12 to communicate with entity 8, which processes credit card information, via gateway 11 and a bank server of financial institution 10. Communication interface 38 can represent, for example, one or more network interface cards (NICs) or network controllers and associated communication protocols. Communication interface 38 can include various types of interfaces, including, but not limited to, wireless local area network (WLAN) interfaces, local area network (LAN) interfaces, wide area network (WAN) interfaces, multimedia messaging service (MMS) interfaces, and short message service (SMS) interfaces.

[0163] In some implementations, device 12 can use a device identification network protocol to establish a connection with an external device via a network interface. For example, both device 12 and the external device can broadcast identification information using the Internet Protocol (IP). The device can then use the identification information to establish network connections between devices, such as establishing a LAN connection.

[0164] The NFC interface 19 allows for short-range communication at various data rates, conforming to standards such as ISO 14443, ISO 15693, ISO 18092, or ISO 21481. The NFC interface 19 can be implemented using an NFC device embedded in a portion of the chipset of device 12. Alternatively, the NFC interface 19 can be implemented using an NFC device, which is a separate component and communicates via communication interface 38, or via an additional port of device 12 (not included in the standard). Figure 4 The NFC interface 19 communicates with device 12. The NFC interface 19 may include one or more protocols, such as the Near Field Communication Interface and Protocol (NFCIP-1) for communicating with another NFC-enabled device. The protocol can be used to adapt to communication speeds and designate a connected device as the initiating device for controlling near field communication. In some embodiments, the NFC interface 19 may be used to receive information such as a Service Set Identifier (SSID), channel, and key, used to connect via another communication interface. In one embodiment of the invention, the NFC interface 19 communicates directly with both the secure element 16 and the control circuitry 40. In alternative embodiments of the invention, the NFC interface 19 may be connected to, for example, but not limited to, the control circuitry 40, the I / O controller 44, or both.

[0165] The NFC interface 19 can control the near-field communication mode of device 12. For example, the NFC interface 19 can be configured to switch device 12 between a read / write mode for reading NFC tags, a peer-to-peer mode for exchanging data with another NFC-enabled device, and a card emulation mode for allowing another NFC-enabled device to read data. The NFC interface 19 can also be configured to switch device 12 between an active mode and a passive mode, where device 12 generates its own RF field in active mode, while in passive mode, device 12 uses load conditioning to transfer data to another device that generates the RF field. Operating in passive mode can extend the battery life of device 12. In some implementations, the mode of the NFC interface 19 can be controlled based on user or manufacturer preferences.

[0166] In this implementation, NFC communication can occur within a range of approximately 2 to 4 centimeters. Near-field communication with the NFC interface 19 can occur via magnetic field induction, which allows the NFC interface 19 to communicate with other NFC devices or retrieve data from tags with RFID circuitry. (Refer to the above description.) Figure 2 The discussion suggests that the NFC interface 19 can be used to obtain data from credit cards 13 and 15 or from mobile devices (smartphones or tablets) 17, particularly data that enables secure contactless financial transactions.

[0167] The secure element 16 is configured to enable the point-of-sale application 112 to run on the device while providing a sufficient level of security to meet the established security standards for EMV transactions. In one embodiment, the secure element 16 is embedded in a chipset connected to control circuitry 40, which cooperates with NFC interface 19 to provide contactless payment functionality. In another embodiment, the secure element 16 is specifically implemented in a chipset connected to control circuitry 40, which cooperates with smart card reader 55 to provide payment functionality. In yet another embodiment, the secure element 16 is specifically implemented in a chipset connected to control circuitry 40, which cooperates with magnetic stripe reader 52 to provide payment functionality. For example, but not limited to, the chipset on which the secure element 16 is specifically implemented can be available from STMicroelectronics. or Models of chipset series or their derivatives. See below for reference. Figure 5 Safety element 16 is described in more detail.

[0168] The SIM card slot 36 allows a SIM card to be inserted into the device 12. The SIM card inserted into the SIM card slot 36 contains an International Mobile Subscriber Identity (IMSI) and a key used to identify and verify the user of the device 12.

[0169] I / O controller 44 provides the infrastructure for exchanging data between control circuitry 40, CPU 42, and input / output devices. I / O controller 44 may contain one or more integrated circuits and may be integrated within control circuitry 40 or exist as a separate component. I / O controller 44 can be used with display 46, keyboard 48, printer (not included in the main unit), etc. Figure 4 The communication infrastructure provided by the magnetic stripe reader 52 or the smart card reader 55 is shown in the figure. Although the magnetic stripe reader 52 and the smart card reader 55 are in... Figure 4 The magnetic stripe reader 52 and smart card reader 55 are shown as connected to I / O controller 44, but it should be understood that they may, for example but not necessarily limited to, communicate directly with control circuitry 40 and / or security element 16.

[0170] I / O controller 44 can also provide infrastructure for communication with external devices and can be used to connect device 12 to external computers, barcode scanners, audio headsets, etc.

[0171] In embodiments of the invention, device 12 is a mobile device, whose portability makes it particularly suitable for performing mobile sales transactions. For example, the mobile device may be, but is not limited to, a mobile phone (e.g., available from Apple Inc.). Models of or their derivatives; available from RIM Corporation Models of or derivatives thereof; available from Samsung. Models of or derivatives thereof), tablet computers (e.g., available from Apple Inc.) or its derivative models; Galaxy models available from Samsung. Models of or their derivatives; available from RIM Corporation (or models of derivatives thereof) and laptops. For ease of transport and mobility, device 12 may include an integrated power supply for powering device 12. The power supply may include one or more batteries, such as lithium-ion batteries, which may be removable by the user or fixed to device 12.

[0172] Due to the portability of device 12, sales transactions can be conducted in various environments. For example, a sales transaction can occur inside a taxi or after the item has been delivered to the customer's doorstep. Furthermore, this invention provides sellers with the ability to conduct financial transactions via a device rather than a dedicated payment terminal, such as a mobile phone embedded with a secure element 16, an NFC interface 19, a smart card reader 55, a magnetic stripe reader 52, or various combinations thereof.

[0173] In alternative embodiments of the invention, the security element 16, NFC interface 19, smart card reader 55, magnetic stripe reader 52, or various combinations thereof, can be embedded in a non-mobile device to run the point-of-sale application 112, for example, in a printer, personal computer, cash register, payment terminal, ATM, vending machine, television, video game system, internet-connected set-top box, or Apple's device. Point-of-sale application 112. Various secure transactions can be performed because various devices can specifically implement the secure element 16 and interface 18. For example, a customer can order a movie from her / his television and conduct a secure transaction directly on her / his television, which is embedded with the secure element 16 and interface 18.

[0174] Point-of-sale applications for secure financial transactions on devices

[0175] Figure 5 A schematic representation of the architecture that allows point-of-sale application 112 to run on device 12 and perform secure transactions with EMV authentication is illustrated. In embodiments of the invention, the architecture is implemented as a combination of pre-programmed hardware or firmware elements (e.g., application-specific integrated circuits (ASICs) running on a chipset implementing secure element 16) and software components stored in memory 54 that are executed by CPU 42 upon activation of point-of-sale application 112. It should be understood that the components running on secure element 16 can be separate pre-programmed hardware elements, or alternatively, separate firmware or software elements. In embodiments of the invention, the chipset on which secure element 16 is implemented has memory and processing capabilities (e.g., a controller and / or a microprocessor).

[0176] The software components stored in memory 54 that are executed by CPU 42 after activation of point-of-sale application 112 include payment control application 208. It is also conceivable that payment control application 208 may be stored elsewhere besides memory 54. In embodiments of the invention, payment control application 208 is executed by an OS running on CPU 42. Payment control application 208 includes instructions to control secure element 16 to facilitate the initiation and completion of EMV-compliant transactions (e.g., Financial transactions, especially those conforming to the EMV contactless transaction standard (Visa). Mastercard American Express Interac Discover ) for contactless transactions. The payment control application 208 manages the communication between the customer 4 and at least one of the merchant 2, financial institution 10, financial institution 6, and payment card company 8. The payment control application 208 directly or indirectly manages the display of the transaction progress on the display 46 through the I / O controller 44. The payment control application 208 can also manage the processing of data read from a payment card or from an RFID-enabled device by the NFC interface 19 through the security element 16. The payment control application 208 can also manage the processing of data read from a payment card by the smart card reader 55 through the security element 16. The payment control application 208 can also manage the processing of data read from a payment card by the magnetic stripe reader 52 through the security element 16. In addition, the payment control application 208 can also manage the processing of data such as, for example, personal identification number (PIN), user signature, password, user biometric data, or any data that allows for the secure identification of the user. According to the standards of most payment brands, for example, but not limited to, and The payment control application 208 is designed to facilitate level 3 authentication for the processing of secure payment card data.

[0177] When referring to the description of the security element, the components of the security element 12 that implement the point-of-sale application 112 will be described in more detail in the following description.

[0178] Now referring to Figure 7 , an example illustration of a software stack that enables the payment control application 208 to communicate with the software that implements the point-of-sale application 112 on the security element 16 is presented. In one embodiment of the present invention as illustrated in Figure 7 , the payment control application 208 executed on the CPU 42 of the control circuit 40 communicates directly with the security element 16 via the following software stack: SEEK (Security Element Evaluation Toolkit), operating system (e.g., Android OS), and underlying drivers. SEEK is a software library for the Android OS that enables Android applications to communicate with security elements, SIM cards, or MicroSD cards. The physical communication between the security element 16 and the control circuit 40 is implemented via an ISO7816 link (not shown in Figure 7 . In Figure 7 another embodiment of the present invention as illustrated, the payment control application 208 executed on the CPU 42 of the control circuit 40 communicates with the security element 16 via a contactless front end (CLF) 710 using the same software stack as in the previous embodiment. The physical communication between the CLF 710 and the control circuit 40 is implemented via an I2C link (not shown in Figure 7 .

[0179] Figure 13This is a flowchart illustrating the communication between the payment control application 208 and the terminal applet executing on the secure element 16 via the aforementioned software stack. In the example illustrated in the flowchart, an ISO7816 link is used. Alternatively, communication can be via a CLF 710.

[0180] Security elements for conducting secure financial transactions on the device.

[0181] Refer again Figure 5 The secure element 16 includes a first module 200, a second module 202, and a third module, an EMV contact / contactless transaction module 204, and / or a third module, MAG 206. In this disclosure, although it is referred to as one module or multiple modules, it should be understood that a module may include, for example, but not necessarily limited to, computer program logic, computer program instructions, software, stacks, firmware, hardware circuitry, or combinations thereof providing the required capabilities. The first module 200 includes a driver for the chipset on which the secure element 16 runs and provides access to the hardware layer of the secure element 16. The first module 200 is designed to perform Level 1 authentication for secure payment card data processing in accordance with the EMVCo Level 1 contact and contactless standards. Although payment card data is referred to, it should be understood that any data on a payment card, regardless of whether it resides on any other carrier (e.g., a mobile device embedded with RFID functionality for secure contactless payment processing), can also be considered. The second module 202 includes an operating system (OS) for the chipset implementing the secure element 16. In one embodiment of the invention, the OS is from Oracle Corporation. In another embodiment of the invention, the OS is compatible with global platform standards. In yet another embodiment of the invention, the OS is a certified or uncertified customer-customized OS. In yet another embodiment, no OS runs on the first module 200. In one embodiment of the invention, the OS of the second module 202 runs on the first module 200 according to the EMVCo Level 1 contact and contactless standard, and also employs Level 1 certification for secure payment card data processing.

[0182] The third module, EMV contact / contactless transaction module 204, runs on top of the second module 202 and is designed for Level 2 authentication (optionally Level 3 authentication) based on major payment brand standards, such as, but not limited to, [payment brands]. and The third module, EMV contact / contactless transaction module 204, includes instructions for processing data read from a payment card via NFC interface 19 and / or from an RFID-enabled device, or from a payment card via smart card reader 55. In embodiments of the invention, data read by NFC interface 19, smart card reader 55, or magnetic stripe reader 52 can be directly transmitted to secure element 16 without passing through control circuitry 40. In alternative embodiments of the invention, data read by NFC interface 19 or smart card reader 55 passes through control circuitry 40 before being transmitted to secure element 16. The third module, EMV contact / contactless transaction module 204, allows for secure processing of read data compatible with the EMV transaction standard. Data processed by the third module, EMV contact / contactless transaction module 204, includes data read from NFC interface 19 or smart card reader 55, but may also include information such as personal identification number (PIN), user signature, password, user biometric data, or any data that allows identification of a customer. Such information can be provided via I / O controller 44 through customer input from keyboard 48, display 46 (e.g., via touchscreen display), or any other interface that allows customer interaction with device 12. Although a third module EMV contact / contactless transaction module 204 is shown that simultaneously incorporates contact and contactless transaction capabilities, it should be understood that contact and contactless transaction capabilities can be embedded in two different EMV modules without departing from the scope of the invention. It should also be understood that the third module EMV contact / contactless transaction module 204 can incorporate additional capabilities, such as, but not limited to, the ability to process data read from magnetic stripe reader 52.

[0183] Alternatively, security element 16 may include, in addition to or instead of, a third module EMV contact / non-contact 204 and a third module magnetic (MAG) 206. The third module MAG 206 operates on the OS provided by the second module 202 and is designed for Level 2 authentication according to the standards of the major payment brand (optionally, it can also be Level 3 authentication, for example, but not limited to...). and Such a brand. The third module MAG 206 includes instructions for processing data read from the payment card by the magnetic stripe reader 52. The third module MAG 206 allows for the secure processing of the read data that is compatible with the EMV transaction standard. The data processed by the third module MAG 206 includes data read from the magnetic stripe reader 52, but may also include information such as a personal identification number (PIN), user signature, password, user biometric data, or any data that allows identification of the customer. Such information may be provided by the customer via an input from the keyboard 48, display 46 (e.g., via a touchscreen display), or any other interface that allows the customer to interact with the device 12, through the I / O controller.

[0184] The third module, EMV contact / contactless transaction module 204, and the third module, MAG 206, are embedded in a chipset that implements the secure element 16. This architecture allows for rapid data processing while enabling secure transactions on the device 12, which is compatible with the EMV transaction standard. Furthermore, in one embodiment of the invention, this architecture allows the device 12 to have data processed independently of the CPU 42 by the secure element 16. In other words, the secure element 16 can process data that might not be accessible to the CPU 42 or the control circuitry 40. In one embodiment of the invention, this architecture allows the device 12 to obtain transaction authorization from financial institutions at least in part based on data processed independently of the CPU 42 or the control circuitry 40 by the secure element 16.

[0185] In another embodiment of the invention, only the security element 16 accesses data read from the payment card or from an RFID-enabled device via the NFC interface 19, data read by the smart card reader 55, and data read from the payment card by the magnetic stripe reader 52. Similarly, the payment control application 208 manages transactions by interacting with the security element 16 without needing to access at least some sensitive data (e.g., keys, certificates, and payment card numbers), which remains processed separately by and stored within the memory of the security element 16. In accordance with EMVCo standards and the standards of major payment brands, the security element 16 is designed for Level 2 authentication (and possibly Level 3 authentication, depending on the case) for secure payment card data processing. Major payment brands, for example, but not necessarily limited to, […]. and It provides a higher level of security by preventing any application running on CPU 42 or control circuitry 40 (e.g., payment control application 208) from accessing data processed by the memory of secure element 16 and data stored in the memory of secure element 16. Furthermore, secure element 16 is designed and pre-loaded onto a separate chipset, allowing secure element 16 to be an EMV transaction authenticated independently of device 12. Similarly, in embodiments of the invention, the integration of secure element 16 on control circuitry 40 allows device 12 to become an authenticated EMV transaction without requiring other components of device 12 to undergo the EMV transaction authentication process. In alternative embodiments, the integration of secure element 16 on control circuitry 40 still requires device 12 to undergo at least partially the EMV authentication process to become an authenticated EMV transaction. Depending on the standards of major payment brands, secure element 16 can also be designed for Level 3 authentication for secure payment card data processing; major payment brands include, but are not limited to, [list of major payment brands]. and Level 3 certification ensures secure data exchange between software running on Secure Element 16 and financial institutions.

[0186] Figure 6 A device 12 with embedded secure element 16 is illustrated, along with schematic representations of alternative embodiments 12a, 12b, and 12c. The representations of devices 12a, 12b, and 12c illustrate that the secure element 16 can be located in various positions, without limitation. Device 12a includes the secure element 16, an NFC interface 19, and a CPU 42, but does not include a SIM card slot, and therefore does not include a SIM card, a unique identifier for the device user provided by selection circuitry or firmware / software embedded in device 12a. Device 12b includes an NFC interface 19, a CPU 42, a SIM card slot 36, and a secure digital (SD) card 60. Although an SD card 60 is shown, it should be understood that any non-volatile memory card can be used without departing from the scope of the invention. The SD card 60 includes a controller 62 and a memory 64. Figure 6As shown, the secure element 16 is embedded in an SD card 60, which can be introduced into or removed from device 12b. The architecture of the embodiment of the invention described in 12b allows the secure element 16 to be installed on a device whose original circuitry does not include any secure elements, thus enabling device 12b to enable contactless transactions via EMV without requiring device 12b to undergo the original authentication process for EMV contactless transactions. Device 12c includes an NFC interface 19, a CPU 42, and a SIM card slot 360. As shown, the secure element 16 is embedded within a SIM card located in the SIM card slot 36, which can be introduced into or removed from device 12c. In embodiments of the invention, the SIM card located in the SIM card slot 36 is compatible with the Global Subscriber Identity Module (USIM) standard. The architecture of the embodiment of the invention described in 12c allows the secure element 16 to be installed on a device whose original circuitry does not include any secure elements, thus enabling device 12c to enable contactless transactions via EMV without requiring device 12c to undergo the original authentication process for EMV contactless transactions. Figure 6 In another alternative embodiment not shown, the safety element 16 may be located within the housing to insert the device 12.

[0187] Now refer to Figure 5 and Figure 8a and 8b It explains the software architecture of the security element 16 that provides security functions. Figure 8a and 8bThe secure element 16, as shown, includes a low-level operating system, the Java Virtual Machine (JVM) of the Java card, and global platform components corresponding to the L1 authentication driver 200 and OS 202. Secure element 16 also includes a primary security domain (ISD) and optional secondary security domains (SSDs). Above these components, the Java applet executes in a secure environment. Specifically, the payment applet 810 can implement Level 2 authentication (or Level 3 authentication if needed) modules: EMV contact / contactless transaction module 204 and / or MAG module 206. Each security domain (SD) is isolated from each other. The owner of a security domain cannot access data / programs residing in other security domains. Each security domain is protected by encryption keys and authentication processes. To access a specific security domain (add / modify / delete an applet residing in a specific security domain), an encryption key protecting that specific security domain is used. The primary security domain (ISD) is under the control of the issuer of secure element 16 (the bank of the payment card, the mobile operator of the SIM card in the phone, or the mobile phone manufacturer of the secure element embedded in the phone). A publisher can create, for example, a secondary security domain (SSD) for use by a peer. The publisher then passes the encryption key controlling the secondary security domain to the peer, who is then authorized to access the secondary security domain and control the content loaded on that SSD. Furthermore, an ISD can impose constraints on the SSDs it creates (e.g., the maximum memory space in the SSD's flash memory). And, a hierarchy of security domains can be created, where an ISD contains 0, 1, or more SSDs.

[0188] Now refer to Figure 8c It explains Figure 8a and 8bThe software architecture of the payment mini-program 810 is shown in the diagram. The payment mini-program 810 includes an abstraction layer that generally interfaces with the underlying software components (e.g., the OS) of the secure element 16. The payment mini-program 810 includes interface modules that connect to different contact and contactless interfaces of the device 12: EMV contact L1 and EMV contact L2 cores for connection to the smart card reader 55, EMV contactless L1 and EMV contactless L2 cores for connection to the NFC interface 19, and a magnetic stripe core for connection to the magnetic stripe reader 52. The payment mini-program 810 includes communication services for communicating with external entities (e.g., financial institutions) via the communication interface 38 of the device 12. The payment mini-program 810 also includes security services for ensuring communication with external entities (e.g., financial institutions): authentication services, encryption services, and encrypted storage services. The payment mini-program 810 also includes an acceptor module. Furthermore, the payment mini-program 810 includes multiple payment modules (such as Mastercard PayPass magnetic stripe, Visa PayWave MSD, Mastercard PayPass M / Chip, Visa PayWave qVSDC) to support various types of payment applications provided by different types of payment methods (such as contact or contactless credit cards, contactless payment enabled mobile phones, etc.).

[0189] Execution of secure financial transactions via secure elements on the device

[0190] Now refer to Figure 1 , 2 4, 5 and Figure 9a -c, Figure 9a -c is a flowchart illustrating the communication process between a secure element and multiple other entities for conducting secure financial transactions on a device according to the embodiments described above. Specifically, a financial server 910 of financial institution 10 or payment card company 8 is shown. A payment control application 208 executing on the CPU 42 of device 12 is shown. An NFC interface 19 is shown. A secure element 16 of device 12 is shown (the payment app 810 executes on secure element 16). Furthermore, a proximity-coupled integrated circuit card (PICC) 920 is shown. The PICC 920 is integrated into a contactless payment enabling device (such as a mobile phone 17 or a credit card 13) and contains data associated with a financial account. The financial account is associated with financial institution 10 or payment card company 8.

[0191] exist Figure 9a In the implementation described in -c, communication between the payment control application 208 and the secure element 16 is conducted via the NFC interface 19 (e.g., via a contactless front-end CLF). Alternative implementations are also applicable. For example, communication can be conducted via control circuitry 40.

[0192] Similarly, in Figure 9a In the implementation described in -c, the interface 18 of the device 12 used to read data related to financial accounts is the NFC interface 19 of the device 12. Alternatively, the interface can be a smart card reader 55 or a magnetic stripe reader 52 of the device 12.

[0193] The user initiates a financial transaction via payment control application 208, and the corresponding amount is specified. Payment control application 208 sends a "Start Payment Mini-Program" message to secure element 16 via NFC interface 19. Secure element 16 is activated, and payment mini-program 810 is launched on secure element 16. Secure element 16 can verify that payment mini-program 810 (not on...) Figure 9a The -c option indicates the start of the transaction. Then, the payment control application 208 sends a start transaction message (with amount) to the secure element 16 via the NFC interface 19.

[0194] Secure element 16 sends a request to NFC interface 19 to enable reader mode for NFC interface 19. Radio frequency (RF) and contactless functions of NFC interface 19 are activated. PICC 920 announces its presence, and NFC interface 19 detects the presence of PICC 920. NFC interface 19 then notifies secure element 16 of the presence of PICC 920.

[0195] Secure Element 16 initiates a payment transaction using the detected PICC 920. The first step includes sending a Near Field Payment System Environment (PPSE) request (via NFC interface 19) to the PICC 920. The PICC 920 responds to this request with a response indicating the payment application supported by the PICC 920 (via NFC interface 19). Secure Element 16 selects a payment application from among the available applications and sends a Select Application Identifier (Select AID) request (via NFC interface 19) to the PICC 920. The PICC 920 responds to this request with a response indicating the status of the selected payment application (allowed / unallowed) and configuration options for the selected payment application (via NFC interface 19).

[0196] The second step involves reading the payment credentials (e.g., password, certificate, payment card number) for the selected payment application from the PICC 920. A protocol exchange occurs between the secure element 16 and the PICC 920 via the NFC interface 19 to read the payment credentials. This protocol exchange is EMV compliant to ensure secure reading of the payment credentials. After this second step, the secure element 16 does not need to communicate with the PICC 920. Therefore, the secure element 16 sends a request to the NFC interface 19 to deactivate the RF and contactless functions of the NFC interface 19.

[0197] Optional steps include an exchange (via NFC interface 19) between the secure element 16 and the payment control application 208 to verify the payment credential. For example, the payment control application 208 can retrieve the PIN code associated with the PICC 920 (via interaction between the owner of the PICC 920 and the display 46 and keypad 48 of the device 12). The PIN code is passed to the secure element 16 and used to verify the payment credential.

[0198] The third step involves initiating communication with the financial server 910. The secure element 16 sends a request (via NFC interface 19) to the payment control application 208 to establish a communication channel with the financial server 910. The payment control application 208 uses the network resources of device 12 to establish a communication channel between the secure element 16 and the financial server 910 via the device's communication interface 38. The secure element 16 and the financial server 910 then establish secure communication on the communication channel, through, for example, the exchange of certificates, encryption keys, etc.

[0199] The fourth step involves requesting authorization from a financial institution. Secure element 16 sends a request to authorize the transaction to financial server 910 via a secure communication channel. The authorization request includes several parameters for authorizing the transaction; for example, the amount, payment voucher, and vendor ID (the vendor ID can be stored in secure element 16 to identify vendors using a point-of-sale application implemented by device 12). Financial server 910 processes the authorization request, determines whether the financial transaction should be authorized, and sends a response to the authorization request via the secure communication channel. At this point, the secure communication channel is closed because no further communication is needed between secure element 16 and financial server 910.

[0200] In the fifth step, secure element 16 processes the financial institution's response and determines the status of the financial transaction: accepted or rejected. Secure element 16 also processes parameters that have been transmitted along with the transaction status by the financial server 910. For example, secure element 16 can generate a payment statistics chart. Secure element 16 then transmits (via NFC interface 19) a notification of the transaction status, along with any parameters that may exist (e.g., the payment statistics chart), to the payment control application 208.

[0201] In step six, the payment control application 208 notifies the user of the transaction status. The payment control application 208 also sends a message (via NFC interface 19) to the secure element 16 to stop the payment app. The payment app 810 stops on the secure element 16, and the secure element 16 is deactivated.

[0202] Now for reference Figure 10This is a diagrammatic representation of a secure communication channel between a secure element and a financial institution. The secure communication channel 950 is established between the secure element 16 of the mobile device 12 and the financial institution server 910, and illustrates the previously described... Figure 9a -c Related secure communication channel. Secure communication channel 950 is established through various entities of mobile device 12, including, for example, payment control application 208 and the CPU of mobile device 12 (not in...). Figure 10 The operating system (represented in the image) is used. A secure communication channel 950 is established via a communication interface supported by the mobile device 12. For illustrative purposes, the three communication interfaces are represented in... Figure 10 (Wireless network, Bluetooth, and cellular data); the cellular data interface is used to establish communication channel 950. Secure communication channel 950 is typically established between mobile device 12 and financial institution server 910 via insecure network 915 (the cellular data network in this description). Secure communication channel 950 is initially an insecure or partially secure communication channel. Securityization (such as...) Figure 9a As described in -c, this is performed in the second phase via the secure element 16 and the financial institution server 910 (e.g., via the exchange and use of encryption keys, certificates, etc.) to achieve the appropriate level of security required for executing secure financial transactions through the secure communication channel 950.

[0203] Secure loading, configuration, and updating of payment software on the secure element

[0204] Now for reference Figure 11 This is a schematic representation of the payment software loading, updating, and configuration process in a secure element according to one embodiment of the present invention. The secure element 16 of the mobile device 12 can communicate with multiple entities to load, update, and configure the payment software executed by the secure element 16 (e.g., ...). Figure 8c The payment mini-program mentioned in the text (810) is an example. Such entities include Trusted Service Managers (TSMs), financial institutions, and third-party servers.

[0205] A Trusted Service Manager (TSM) is a third party that manages security domains (ISD or SSD) for clients within a secure element (e.g., a SIM card, an embedded secure element, a microSD card). The TSM has the appropriate infrastructure to securely store and access the security domain using cryptographic keys, store software and data, and remotely access the secure element. The TSM enables trusted and remote deployment of software and data on secure element 16 without requiring physical access to device 12. Instead of a TSM, a financial institution server or a third-party server can be used to manage the secure storage and deployment of software and data loaded onto secure element 16. In particular, third-party servers are functionally similar to TSMs but may not have all the security constraints and responsibilities associated with a fully-fledged TSM. In the first step, a communication channel is opened between the payment control application 208 executing on device 12 and the TSM / financial institution server / third-party server. In the second step, the TSM / financial institution server / third-party server opens a secure communication channel with secure element 16 on device 12, connects to the appropriate security domain interface on secure element 16, and securely loads the software and data onto secure element 16.

[0206] The loading / updating / configuration process is typically performed via an insecure network 915 (e.g., a cellular data network) using one of the communication interfaces of the mobile device 12 (e.g., Wi-Fi, Bluetooth, or cellular data). Therefore, the loading / updating / configuration process needs to be protected, such as by [protecting it against threats]. Figure 12 As further explained, the loading / updating / configuration process is typically performed according to specific (secure) protocols, such as global platform protocols.

[0207] In the alternative implementation methods (not in Figure 11 (As indicated in the text), instead of using the communication network 915, a MicroSD card containing the software and data to be uploaded to the secure element 12 can be used.

[0208] Now refer to Figure 12 This is a flowchart describing the process of loading, updating, and configuring payment software in a secure element according to one embodiment of the present invention. The flowchart illustrates the comprehensive installation of all necessary software and data on a mobile device with the embedded secure element for point-of-sale applications.

[0209] In the first step, the user of the mobile device downloads the software for its client (e.g., Figure 12The payment application (represented by the TSM, financial institution server, or third-party server) is sent to a mobile device (e.g., from a marketplace, app store, etc.). The user launches the payment application, which is executed by the mobile device's CPU. The payment application requests the user to enter their credentials in order to contact the acquiring party. The user enters their credentials. The payment application contacts the acquiring party via a secure connection. The acquiring party verifies the user's credentials. If the credentials are invalid, the user is asked by the payment application to enter their credentials again.

[0210] In the second step (once the credentials have been verified), the payment application opens a communication channel between the payer and the secure element. The steps for opening this communication channel are similar to those for... Figure 10 This describes one step. The security domains of the receiving party and the security element establish secure communication over the communication channel, providing authentication and security messages between them.

[0211] In the third step, the acceptor loads a specific payment mini-program into the secure element, selecting the appropriate mini-program based on the user's configuration (point-of-sale functionality) for the mobile device. The acceptor then activates the mini-program.

[0212] In step four, mutual verification is performed between the acquirer and the payment mini-program; and secure communication is established between them (through the secure communication channel already established between the acquirer and the secure element). The acquirer then loads the encryption certificate and private key into the payment mini-program. The acquirer loads the mobile device's user-specific configuration data (point-of-sale functionality) into the payment mini-program. This configuration data may include the acquirer's hostname, connection credentials, customer EMV tag, activated payment module (e.g., PayPass, PayWave), country code, and currency, etc. The payment mini-program is now ready for use.

[0213] Updates to the payment mini-program can be performed according to steps two, three, and four described above.

[0214] While embodiments of the invention described above have been described and illustrated with reference to specific steps performed in a particular order, it should be understood that these steps may be combined, subdivided, or reordered without departing from the teachings of the invention. Therefore, the order and grouping of these steps are not limitations of the invention.

[0215] Modifications and improvements to the above embodiments of the present invention will become apparent to those skilled in the art. The above description is intended to be exemplary and not restrictive. Therefore, the scope of the invention is intended to be defined only by the scope of the appended claims.

Claims

1. A secure element for installation in a device used as a payment terminal, the device running a point-of-sale (POS) application, the POS application including a payment control application, the payment control application including control instructions for controlling the secure element, the device including a processor, an interface, and a communication interface, the secure element including instructions accessed from a non-transitory computer-readable storage medium such that the secure element performs the following when the instructions are executed: Pan-European Card, Mastercard, and Visa EMV transaction modules are configured to process data obtained from the payment device by the interface of the device according to authentication standards, the interface being a contactless interface configured to receive data from the payment device in a contactless manner; The operating system (OS) is configured to process data provided by the EMV transaction module in accordance with Level 1 of the EMVCo standard. in, The EMV transaction module is configured to perform the following operations: The secure element is used to receive requests for secure financial transactions. Using the security element, data about a financial account is obtained from the payment device via the interface of the device, the obtaining including: (i) sending a request to select a Near Field Payment System Environment (PPSE) to the payment device, (ii) receiving a response from the payment device indicating the payment applications supported by the payment device, and (iii) selecting a payment application among these available payment applications; A secure communication channel is established with the server of the financial institution regarding the financial account via the communication interface of the device using the secure element. The establishment includes the secure element sending a request to the payment control application to establish the secure communication channel with the server of the financial institution. The authorization request for executing the secure financial transaction is sent to the server via the secure communication channel using the secure element, and the authorization request includes at least a portion of the data regarding the financial account; Receive a response to the authorization request from the server via the secure communication channel; and The response to the authorization request is processed to generate the state of the secure financial transaction.

2. The safety element according to claim 1, wherein, The request to conduct a secure financial transaction is received from the payment control application running on the device.

3. The safety element according to claim 1, wherein, The data concerning the financial account is processed by the security element independently of the data processed by the processor of the device.

4. The safety element according to claim 1, wherein, The EMV transaction module is also configured to perform the following: send the status of the secure financial transaction to the payment control application running on the device via the secure element.

5. The safety element according to claim 1, wherein, The control instructions for controlling the security element include instructions for causing the following operations: sending a start payment mini-program message to the security element via the payment control application, and activating the security element based on the start payment mini-program message.

6. The safety element according to claim 1, wherein, The security element is embedded in one of the following: a chipset embedded in the circuitry of the device, a user identity module SIM card, a secure digital SD card, a non-volatile memory card, or inserted into the casing of the device.

7. The safety element according to claim 1, wherein, The EMV transaction module is a contactless transaction module.

8. The safety element according to claim 1, wherein, The request to conduct the secure financial transaction includes crediting the purchase amount to the debit side of the financial account.

9. The safety element according to claim 1, wherein, The payment device is either a payment card or a mobile device.

10. The safety element according to claim 1, wherein, The data regarding the financial account includes at least one of a key, certificate, and payment card number.

11. An electronic device comprising a security element according to any one of claims 1-10.

12. A method of operating a mobile device used as a payment terminal, the mobile device being different from a dedicated payment terminal, the mobile device being configured to run a point-of-sale (POS) application and operate a secure element, the mobile device including a central processing unit, a contactless interface including a near-field communication (NFC) interface, and a communication interface, the method comprising: The secure element sends a request to the NFC interface to enable the reader mode of the NFC interface, thereby activating the radio frequency (RF) and contactless functions of the NFC interface. The security element reads payment credentials for a payment application, the payment credentials including a key, certificate, or payment card number that is kept separately processed and stored in the memory of the security element; The secure element sends a request to the NFC interface to deactivate the RF and contactless functions of the NFC interface; Sending a request to the payment control application to establish a communication channel with the financial service provider includes establishing a secure communication channel between the secure element and the financial server via the communication interface of the mobile device through the exchange of encryption keys. The secure element sends an authorization transaction request to the financial server via the secure communication channel, the authorization transaction request including the payment voucher; and The secure communication channel is closed.

13. The method according to claim 12, wherein, The security element includes software with embedded security components.

14. The method according to claim 12, wherein, The security element includes a chipset.

15. The method according to claim 12, wherein, The POS application includes a payment control application.

16. The method according to claim 12, wherein, Reading the payment credential for the payment application by the secure element includes: The secure element receives the "Start Payment" mini-program message; Launch the payment app on the secure element; and The payment credential is read from the PICC (Peripherally Coupled Integrated Circuit Card).

17. The method of claim 12, further comprising: The PPSE (Pre-Payment System Environment) request will be sent to the PICC (Personally Coupled Integrated Circuit Card). Receive a response from the PICC indicating the payment applications supported by the PICC; as well as The security element selects a payment application from among these available payment applications.

18. The method according to claim 17, wherein, Communication between the payment control application and the security element is conducted via a contactless front end.

19. The method of claim 17, further comprising: The payment control application retrieves the Personal Identification Number (PIN) associated with the PICC. The PIN is passed to the security element; and Use the PIN to verify the payment voucher.

20. The method of claim 17, wherein, Establishing the secure communication channel between the secure element and the financial server via the communication interface of the mobile device includes: the secure element sending a request to the payment control application to establish the secure communication channel with the financial service provider.

21. The method of claim 12, further comprising: Receive a response to the transaction authorization request from the financial server through the secure communication channel; and The response is processed to determine the status of the financial transaction.

22. The method of claim 12, further comprising: The secure element receives the message to stop payment from the mini-program; and Stop the payment app on the security element.

23. The method according to claim 12, wherein, The payment control application manages the processing of user biometric data or any data allowing user security identifiers through the security element.

24. A mobile device, comprising: Central processing unit; as well as A non-transitory computer-readable storage medium containing computer-executable instructions that, when executed, cause the execution of the method according to any one of claims 12-23.

25. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed, cause the execution of the method according to any one of claims 12-23.

26. A method of operating a mobile device used as a payment terminal, the mobile device being different from a dedicated payment terminal, the mobile device being configured to operate a secure element, the secure element being configured to execute a payment app, the method comprising: The payment mini-program is loaded onto the secure element by the accepting system, wherein the payment mini-program is selected based on the configuration of the user for the mobile device; The payment mini-program is activated by the receiving party's system; Mutual verification is performed between the acceptor system and the payment mini-program; and Load the encryption certificate or private key into the payment mini-program.

27. The method according to claim 26, wherein, The method is executed before the payment mini-program is loaded onto the secure element by the accepting system: A communication channel is opened between the acceptor system and the security element by a payment application running on the mobile device.

28. The method according to claim 26, wherein, The receiving system is at least one of a trusted service manager, a financial institution server, or a third-party server.

29. The method of claim 26, further comprising: The accepting system loads the user-specific configuration data of the mobile device into the payment mini-program.

30. The method according to claim 29, wherein, The configuration data includes at least one of the following: the hostname of the acquiring system, connection credentials, customer tag, activated payment module, country code, or currency.

31. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by a processor, cause the execution of the method according to any one of claims 26-30.

32. A mobile device, comprising: processor; as well as A non-transitory computer-readable storage medium containing computer-executable instructions that, when executed, cause the execution of the method according to any one of claims 26-30.

33. A method of operating a mobile device used as a payment terminal by a retailer, the mobile device being different from a dedicated payment terminal, the mobile device being configured to run a point-of-sale (POS) application and operate a secure element, the mobile device including a central processing unit, a near-field communication (NFC) interface, and a communication interface, the secure element including software with embedded security components, the POS application including a payment control application, the method comprising: Initiating a financial transaction via the payment control application includes specifying the amount corresponding to the financial transaction; Activate the radio frequency (RF) and contactless functions of the NFC interface of the mobile device; Receive instructions for one or more payment applications supported by the PICC from the customer's payment device's proximity-coupled integrated circuit card (PICC); The security element selects one payment application from the one or more payment applications. The payment credential is read by the secure element via the NFC interface of the mobile device, wherein the payment credential includes a key, certificate, or payment card number identifying the customer's financial account; and The secure element sends an authorization request to the financial server via a secure communication channel. The authorization request includes the payment credential and an identifier corresponding to the seller.

34. The method of claim 33, wherein reading the payment voucher comprises: Read the payment credentials for the selected payment application from the PICC.

35. The method of claim 33, further comprising: A Select Nearest Payment System Environment (PPSE) request is sent to the PICC, wherein the PICC responds to the PPSE request with a response indicating a payment application supported by the PICC.

36. The method of claim 33, further comprising: Receive a response to the authorization request from the financial server via the secure communication channel; as well as The response is processed to determine the status of the financial transaction.

37. The method according to claim 33, wherein, The payment device is a credit card.

38. The method according to claim 37, wherein, The payment device is another mobile device.

39. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by a processor, cause to perform the method according to any one of claims 33-38.

40. A mobile device, comprising: At least one processor; as well as A memory storing a plurality of executable instructions, which, when executed by the at least one processor, cause the mobile device to perform the method according to any one of claims 33-38.

41. A method for processing a payment by a mobile device operating as a payment terminal, the mobile device including a secure element, the method comprising: Initiate a financial transaction, including specifying the amount corresponding to the financial transaction; Activate the radio frequency (RF) and contactless functions of the near-field communication (NFC) interface of the mobile device; Receive instructions from the customer's proximity-coupled integrated circuit card (PICC) for one or more payment applications supported by the PICC; The security element selects one payment application from the one or more payment applications. The payment credential is read by the secure element via the NFC interface of the mobile device, wherein the payment credential includes a key, certificate, or payment card number identifying a financial account associated with the customer; and The security element sends the payment voucher and the identifier corresponding to the seller to the financial server through a secure communication channel.

42. The method according to claim 41, wherein, The security element and the financial server establish secure communication over the communication channel via the exchange of certificates.

43. The method according to claim 41, wherein, The secure element and the financial server establish secure communication over the communication channel via the exchange of encryption keys.

44. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by a processor, cause to perform the method according to any one of claims 41-43.

45. A mobile device, comprising: At least one processor, and A memory storing a plurality of executable instructions, which, when executed by the at least one processor, cause the mobile device to perform the method according to any one of claims 41-43.

Images