CN108830586A - Apparatus and method for settlement and payment using mobile device - Google Patents

Abstract

The invention discloses a device and a method for settling payment by using a mobile device. The method comprises the following steps: providing a software module executing on a first mobile device embedded with a secure element, wherein said secure element has been personalized, said software module being configured via said secure element, said first mobile device comprising data relating to an electronic bill; receiving a payment request from a second mobile device upon approval by a user of the second mobile device of payment for the wirelessly transmitted electronic bill from the first mobile device, wherein the second mobile device is a near field communication device for executing an application in communication with a software module in the first mobile device to read the data from the first mobile device; verifying the payment request; sending a payment response to a user of the first mobile device after the payment request is processed. In this way, quick settlement payments can be made at the point of sale using the mobile device.

Description

Apparatus and method for settlement and payment using mobile device

This patent application is a divisional application of the Chinese invention patent application with the patent application number: 201310109741.9, the title of the invention: a device and method for settlement and payment using a mobile device, and the filing date: March 31, 2013.

【Technical field】

The present invention generally relates to the field of electronic commerce, and in particular, the present invention relates to utilizing a mobile device to read electronic bills or invoices from another mobile device within the near field communication Apparatus and method for on-device settlement of payment.

【Background technique】

For many credit or debit card transactions, the customer requests a statement when checking out for the purchase, thus beginning the payment process. A cashier or service worker brings a bill to the customer for verification. The customer then presents a credit or debit card to the service worker. The service worker brings the credit or debit card to the Point of Sales counter to initiate payment for the transaction. The service worker then takes back a receipt for the consumer to sign to approve the transaction. This is a lengthy process, often taking several minutes or more, and the service worker has to attend to multiple payment transactions at the same time. Furthermore, in the case of debit card transactions, the process may be more cumbersome when the transaction at the point of sale requires the use of an identification number.

There is therefore a real need to simplify the payment process. With the development of mobile devices, it is foreseeable that many customers will carry a mobile device with them. In this way, there is an opportunity to quickly settle payments at the point of sale (POS) using a mobile device.

【Content of invention】

The purpose of this section is to outline some aspects of embodiments of the invention and to briefly describe some preferred embodiments. Some simplifications or omissions may be made in this section, as well as in the abstract and titles of this application, to avoid obscuring the purpose of this section, abstract and titles, and such simplifications or omissions should not be used to limit the scope of the invention.

The invention provides a device and method for settlement and payment using a mobile device, which can enable consumers to use the mobile device to perform quick and convenient settlement and payment. The present invention relates to technologies related to mobile devices that can be used to settle charges in electronic bills. According to one aspect of the invention, a mobile device embedded with a secure element can generate or load an electronic bill. The mobile device is brought to a consumer carrying an NFC mobile device, and data including the electronic bill and other information about the mobile device or its owner is wirelessly read into the NFC mobile device. After the user verifies the amount due and approves the payment, the NFC mobile device communicates with a payment gateway or payment network for processing the payment according to the selected payment method.

According to another aspect of the invention, said mobile device is a contactless card or part of a mobile point of sale device for generating said electronic bill. An embodiment of the present invention may provide unexpected benefits in applications where multiple touches may be involved in the payment flow between the merchant and the consumer. One such application is the payment process in restaurants, where the customer is given a bill for verification and the opportunity to add a tip before the final bill is determined. The consumer completes payment using the NFC device using the payment method selected on the point-of-sale device without further contact with the merchant.

According to another aspect of the invention, a consumer uses his/her mobile device to settle a payment through a payment network, where the payment network can be an existing payment infrastructure (e.g., money transfer or credit and debit cards). When the fee is transferred to the designated account of the merchant, a payment response is sent to the merchant.

According to another aspect of the invention, the NFC mobile device used by the consumer is his own electronic wallet. In this way, after the NFC mobile device receives and presents the electronic bill, the consumer can operate his own NFC mobile device to settle the charges in the electronic bill.

According to another aspect of the present invention, the mobile device used by the consumer is an NFC device, which belongs to a part of the mobile payment ecosystem, and all parties in the mobile payment ecosystem work together to make the mobile payment ecosystem run smoothly . By providing a Trusted Service Management (TSM) server, the secure element of the mobile device can be remotely personalized, and various applications can be downloaded after being configured by a trusted service manager (such as a TSM server) , update, manage or replace. One of these modules, called Smart Bill Management, is downloaded and installed on the point-of-sale device or NFC device used by the merchant. The module is used to facilitate the communication and data exchange between the merchant (his device) and the consumer (his mobile device), where the mobile device used by the consumer is also installed with applications related to smart bill payment.

One of the important features, advantages and benefits of the present invention compared to the prior art is the use of NFC mobile devices to read data about electronic bills to settle charges for said electronic bills. The invention can be implemented as a single device, server, system or part of a system.

In a preferred embodiment, the invention is a method of settling payments, said method comprising: providing a software module executed on a first mobile device embedded with a secure element, wherein said secure element has been personalized, configuring said software module via said secure element, said first mobile device comprising data on an electronic bill; a user at a second mobile device authorizing the electronic bill for wireless transmission from said first mobile device After payment, receiving a payment request from the second mobile device, wherein the second mobile device is a near field communication device, which is used to execute an application that communicates with a software module in the first mobile device to reading the data from the first mobile device; implementing the payment request; and, after the payment request is processed, sending a payment response to a user of the first mobile device.

As a preferred embodiment of the present invention, the verification of the payment request includes: when the settlement amount provided by the user of the second mobile device is less than the payable amount on the electronic bill, sending a rejection message to the The second mobile device; or, when the settlement amount provided by the user of the second mobile device is equal to or greater than the payable amount on the electronic bill, continue the payment process.

According to another embodiment of the present invention, the present invention is a gateway for settlement and payment, said gateway comprising: a portal and a server, said portal providing a software module executed on a first mobile device embedded with a secure element, Where said secure element has been personalized via which said software module is configured, said first mobile device comprises data relating to an electronic bill. The server includes a processor and memory coupled to the processor for storing code executed on the processor to enable the server to perform the following operations: receiving a payment request from the second mobile device after payment of the electronic bill wirelessly transmitted from the first mobile device, wherein the second mobile device is a near field communication device configured to perform a communication with an application in which the software module in the first mobile device communicates to read the data from the first mobile device; verify the payment request; and, after the payment request is processed, send a payment response to A user of the first mobile device.

Compared with the prior art, in the present invention, consumers can utilize their NFC mobile devices to read data about electronic bills to settle the expenses of said electronic bills, thereby realizing fast and convenient payment.

【Description of drawings】

The specific features, embodiments and advantages of the invention will be aided in the ensuing detailed description, the following claims and the accompanying drawings, in which:

Fig. 1 shows a system architecture according to one embodiment of the present invention, wherein a payment network represents a collection of services or networks for settlement payments provided by financial institutions;

Figure 2A shows a mobile payment ecosystem, wherein the relevant parties (parties) in the mobile payment ecosystem are listed in turn;

Figure 2B shows a flow or process for configuring one or more applications according to one embodiment of the present invention;

Figure 2C shows the data flow of interactions between different parties when configuring an application;

Fig. 2D shows the data flow of different parties interacting when preparing application data in configuring an application process;

FIG. 2E shows a flow or process of locking or disabling an installed application;

Figure 2F shows a schematic diagram of the architecture of a portable device as an electronic wallet when performing e-commerce and mobile commerce according to a specific embodiment of the present invention;

Fig. 3 A has shown relevant module interaction, to complete the structural diagram that aforementioned electronic purse is carried out personalized processing by authorizer;

Fig. 3 B shows the interaction of relevant modules, to complete the structural diagram that the aforementioned electronic wallet is carried out by its user for personalization;

Figure 3C shows a flow or process diagram of a personalized electronic wallet according to a specific embodiment of the present invention;

Figure 4A and Figure 4B, according to a specific embodiment of the present invention, together show the flow or process when raising funds, injecting funds, loading or recharging the electronic wallet;

Fig. 4C shows the interaction of relevant modules to complete the structural representation of the process shown in Fig. 4A and Fig. 4B;

Fig. 5A shows a schematic diagram of the structure of the first portable device according to a specific embodiment of the present invention, enabling it to perform various e-commerce and mobile commerce on a cellular communication network (for example, 3G, LTE or GPRS network) Function;

Fig. 5B shows a schematic diagram of the structure of the second portable device according to another specific embodiment of the present invention, enabling it to perform various types of e-commerce and mobile commerce on wired and/or wireless data networks (such as the Internet) Function;

FIG. 5C is a flowchart illustrating a schematic diagram of a process for enabling the portable device in FIG. 5A to run service applications provided by one or more service providers according to a specific embodiment of the present invention;

Figure 6A shows a schematic diagram of an architecture according to a specific embodiment of the present invention, wherein the portable device can be used as a mobile point of sale to perform e-commerce and mobile commerce;

Fig. 6B shows a schematic diagram of an architecture according to a specific embodiment of the present invention, wherein the portable device can perform a transaction upload operation on the network as a mobile point of sale;

Figure 6C is a flow diagram illustrating the process of performing mobile commerce using a portable device used as a mobile point of sale and a single function card device supporting electronic tokens, according to an embodiment of the present invention;

Figure 6D is a flow chart illustrating the process of performing mobile commerce using a portable device used as a mobile point of sale and a multi-function card device supporting electronic tokens;

Fig. 7 has described the structure schematic diagram when portable device is used for electronic ticketing application;

Figure 8A shows a schematic diagram of the parties involved in a TSM operated or arranged by a business;

Figure 8B shows the relevant operational procedures between the parties of the TSM in one embodiment;

Figure 8C shows the workflow for establishing a mutual agreement between parties in an example TSM;

Figure 8D shows the data flow of ISD mapping (mapping) between SE issuer and TSM;

Figure 8E shows the corresponding data flow between TSM, SE issuer and service provider;

Figure 8F shows the data flow for approving an application by the SE issuer;

Figure 8G shows the process of replacing a secure element; and

Fig. 9 shows an example of a snapshot of a display screen of an account of a personalized secure element.

Figure 10 shows a flow or process diagram of settlement payment according to the present invention, wherein the process is implemented in software or in a combination of software and hardware;

【Detailed ways】

The detailed description of the present invention directly or indirectly simulates the operation of the technical solution of the present invention mainly through procedures, steps, logic blocks, processes or other symbolic descriptions. In the ensuing description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. Yet the invention may be practiced without these specific details. These descriptions and representations herein are used by those skilled in the art to effectively convey the substance of their work to others skilled in the art. In other words, for the purpose of avoiding obscuring the present invention, well-known methods and procedures have not been described in detail since they have been readily understood.

Reference herein to "one embodiment" or "an embodiment" refers to a particular feature, structure or characteristic that can be included in at least one implementation of the present invention. "In one embodiment" appearing in different places in this specification does not all refer to the same embodiment, nor is it a separate or selective embodiment that is mutually exclusive with other embodiments. Furthermore, the order of blocks in a method, flowchart, or functional block diagram representing one or more embodiments does not necessarily refer to any particular order nor constitute a limitation on the invention. A keyset in this context refers to a set of keys. "Card" in the present invention can also be referred to as a card. Payment in this article also has meanings such as payment and money that needs to be paid.

Various embodiments of the present invention are described below with reference to FIGS. 1-10 . However, those of ordinary skill in the art will readily appreciate that the detailed descriptions set forth herein with reference to these figures are for explanatory purposes only, and the present invention is not limited to these embodiments.

NFC presents a significant business opportunity when mobile phones with Near Field Communication (NFC) capabilities are used for services such as payment services, transportation ticketing, credit services, physical access control and other exciting new services. In order to support such a rapidly evolving business environment, various NFC-enabled mobile phones or devices (or called NFC devices) are being developed to support various applications in daily life.

FIG. 1 shows a system architecture 100 according to an embodiment of the present invention. Network 102 represents a collection of services or networks provided by financial institutions to settle payments. In other words, it is a system that provides electronic transfer or settlement payment services. Alternatives to cash used in traditional payments are cashable documents such as drafts (eg checks) and documentary credits such as letters of credit. With the advent of computers and electronic communications, many alternative electronic payment systems have emerged, including debit cards, credit cards, electronic funds transfer, direct credits, direct debits , online banking and e-commerce payment (payment) system. A payment system used as an alternative to presenting cash in domestic or international transactions, including the primary services provided by banks or other financial institutions.

The payment system or network 102 may be physical or electronic, with its own procedures and protocols. An example of a payment system that has been used globally is the Visa or Master card, a true global credit card and automated teller machine network. Both merchants and consumers use payment systems to settle transactions.

According to one embodiment, smart bill payment gateway 104 includes a server or a collection of servers, referred to as gateway or server 104, which is used to provide an application (or program) that can be installed by users in their mobile devices to enjoy this service. The benefits of the invention. Here, the application can be named as a smart bill payment program, and the application is published on the Internet and can be downloaded from a designated place (such as a server entrance or portal). The user downloads the application using a mobile device and installs it in the mobile device. The application may be executed automatically or manually to approve payment of a displayed electronic bill generated from interaction data of the mobile device's secure element with another mobile device. Unless otherwise specified, "computing device", "mobile device", "handheld device", "mobile phone", "smart phone", "handheld phone" or similar terms will be used interchangeably herein, however Those of ordinary skill in the art can understand that the above words can also refer to other devices, such as wearable watches, tablet computers, notebook computers, and other portable devices with NFC capabilities.

Reference numeral 106 refers to a point of sale (POS for short) device. Depending on implementation, the POS device 106 may be a single device or a stationary device with one or more portable devices such as contactless cards. One purpose of the device 106 is to generate electronic bills (electronic bills or invoices), which are loaded onto a portable device 108 (such as a contactless card or NFC device) that can be used to communicate with a customer's The NFC device is touched to settle the electronic bill.

According to one embodiment, said POS device is a single device embedded with a secure element. The separate device may be an NFC device used to enter information to generate an electronic bill. For example, a consumer orders several dishes in a restaurant, and the cashier inputs the unit price of each dish in the NFC device to generate an electronic bill, which shows the total price including taxes and fees, and sometimes can also include some minor items. Tips. A cashier or waiter presents the NFC device to the customer for approval and payment. According to another embodiment, the POS device includes a stationary device corresponding to 106 in FIG. 1 and one or more contactless cards corresponding to 108 in FIG. 1 . The teller uses the stationary device to enter billing information to generate an electronic bill. The electronic bill is loaded onto the contactless card, and the contactless card loaded with the electronic bill is then brought to the customer for approval and payment. In the following description, unless otherwise specified, the POS device can refer to any example, and the following assumes that it is a single device for introduction. The detailed description given here enables those of ordinary skill in the art to fully understand which POS device to use when implementing an embodiment of the present invention.

As described further below, the POS device has a secure element embedded therein. The secure element can facilitate communication between the server and the mobile device by providing the security and privacy required to support secure data communication between the two devices. In general, a secure element is a tamper-resistant platform (such as a single-chip secure microcontroller) that is able to be secure according to rules and security requirements set by a carefully identified group of trusted experts (well-identified trusted authorities). Manage various applications and their confidential and encrypted data (such as key management). Common forms of secure elements include: universal integrated circuit cards (Universal Integrated Circuit Card, UICC) and microSD cards (microSD cards) embedded with secure elements. Both the UICC and the microSD card are removed. In one embodiment, a software module (soft module) is configured as a secure element that can be updated by rewriting some or all components within it. Regardless of the form, each form can be implemented for different businesses and meet different market needs. For a secure element to be used, it must be personalized. Details of personalizing a secure element are described in co-pending U.S. patent application Ser. No. 13/749,696.

According to one embodiment, a software module (such as a JAVA program applet) refers to a smart bill payment applet (smart bill payment applet), which corresponds to an application described above, and is loaded into the POS device 106, The smart bill payment program is configured through a secure element in the POS device. The software modules may be distributed by a service provider operating the gateway or server 104 and downloaded to an NFC device via a wireless or wired network. Once downloaded, the software modules must be configured via the service provider, and then secure data exchanges with the server 104 are possible. Pending U.S. Patent Application No. 13/749,96 describes the details of configuring an application through a personalized secure element, to which reference is made.

FIG. 10 illustrates a flow or process 120 of settling payments according to one embodiment of the present invention. The process 120 can be implemented as software or a combination of software and hardware. Without any implied limitation, the process 120 can be better understood in conjunction with FIG. 1 .

In order to facilitate the description of the process 120, assume that a consumer (customer) eats in a restaurant, and the restaurant has installed a POS device including a static device in which the cashier manages/inputs various charging data An electronic bill is generated for the customer. The POS device also includes a reader/writer for exchanging data with one or more contactless cards. In other words, the teller can generate an electronic bill after entering the necessary information on the stationary device, and can load the electronic bill into a contactless card.

At the end of the meal, the waiter asks a cashier to prepare an electronic bill on the POS machine corresponding to 106 in Figure 1 . The POS machine generates an electronic bill, and transmits the electronic bill to a contactless card in operation 122, wherein the contactless card is embedded with a personalized security element and a smart bill configured with the personalized security element payment program or application. In operation 124, the waiter brings the contactless card to the customer. In operation 126, the customer reads the contactless card using his mobile device. As described above, assuming that the consumer’s mobile device has already installed the corresponding smart bill payment application, when the consumer’s mobile device detects the contactless card within a short distance, it will execute the smart bill payment application , and read data about the electronic bill from the contactless card in operation 128, and then display the electronic bill on the display screen of the mobile device for verification by the consumer. Unlike traditional bills typically seen on a screen, the electronic bill in the contactless card and transmitted to the mobile device includes the registered user's secure information. The secure information includes, but is not limited to, the restaurant's bank information and account, an identifier on the contactless card or a secure element in the POS machine. In one embodiment, said data also includes an address or link (such as a mobile phone number) through which said merchant is notified (such as a payment response) after said payment settlement has been completed. When implemented, the notification can be sent to the designated mobile device in the form of a short message or email.

After seeing the electronic bill displayed on the display screen, the consumer can select a method to settle the electronic bill. Based on implementation, the consumer can choose to settle the electronic bill through the electronic wallet application already installed on the mobile device, and can also choose to settle the electronic bill by cash, traditional credit or debit card, electronic transfer/payment or other means to settle the electronic bill. The method of settlement through e-wallets will be described in detail below.

Fig. 10 shows an embodiment of using the electronic payment, which is a kind of transfer service provided by the payment gateway 102 shown in Fig. 1 . In operation 130, the consumer has selected the electronic payment provided by the installed smart bill payment application, and input the amount that needs to be paid for the electronic bill. It should be appreciated that the customer may enter an amount greater than the amount due on the electronic bill as a tip for services provided by the restaurant. Once the customer enters the total amount, in operation 132 the smart bill payment application on the customer's mobile device sends a payment request to the server 104 for processing, the payment request including information on the electronic bill data. As described further below, in one embodiment, data exchange between the mobile device and the gateway or server 104 takes place over a secure channel according to The security information in the data is established.

After receiving the payment request, in operation 134, the server 104 is used to verify whether the amount input by the customer can cover the charge in the electronic bill. If the amount is less than the amount required to be paid in the electronic bill, for example, the customer may have entered an incorrect amount or made an error when typing, the server 104 will return the payment request to the mobile device. After receiving the rejection message, the smart bill payment application in the mobile device will display the rejection message as a reminder to the consumer so that the consumer can take an appropriate step to continue the payment process . If the amount is equal to or greater than the amount due on the electronic bill (e.g., the customer wishes to tip a portion of the charge), the server 104 will proceed with the payment request in operation 136.

As shown in FIG. 10 , after receiving the payment request approved by the consumer, the server 104 continues to cooperate with the payment network 102 to process the payment request. In one embodiment, the server 104 provides a payment service similar to Paypal commonly used in the United States and other countries or Alipay mainly used in China. In operation 138, the server 104 sends a notification to the merchant (eg, restaurant) upon completion or failure of the transaction.

As noted above, in one embodiment, the NFC device 110 in Figure 1 is configured to function as an electronic wallet, which can be used to directly settle charges displayed on its display screen. How e-wallets work in the mobile payment ecosystem will be described in detail below.

Referring now to FIG. 2A , which shows a mobile ecosystem 200, the parties involved in the mobile ecosystem are listed in order. In one embodiment, an NFC device is allowed to download or install one or more applications from a corresponding specified server 202 (such as an application management provider) originally developed by an application developer 204 and provided by a service provider 210. The application management provider 202 or other relevant parties publish. It is assumed that the secure element 206 provided by the secure element provider 208 has been personalized via the TSM or a trusted third party (eg, the financial institution 212 ).

Once an application is installed on the NFC device (such as the smart bill payment application in the NFC device 110 or the smart bill payment application in the POS device 106 in FIG. The secure element configures the application. The configuration process for an application can begin in several ways. One way of doing this is for an SE owner to select an application from the TSM portal on the mobile device and start the provisioning process. Another way is for the secure element owner to receive an application configuration notification on the mobile device from a TSM on behalf of the application provider.

The TSM or application provider can publish their applications on the TSM portal or portal for download to mobile devices with secure elements and/or subscription user requests (such as SE owners). In one embodiment, the TSM provides cloud services for multiple SE issuers. In this way, many applications from various service providers can be obtained from the TSM portal. However, when logged into the TSM portal, the SE owner can only view those applications that are authenticated by his SE provider. Based on the agreement between the secure element and the service provider, the download/installation/personalization of the application can be achieved using the secure element's ISD key set or the service provider's designated SSD key set. If the SSD key set is not installed in the secure element, it can be installed during an application installation.

The TSM knows the storage status of the secure element for each SSD. Based on the storage allocation policy of the SSD and the storage status of the secure element, the available applications for various SSDs in the application store can be marked with different indications, such as "can be installed" or "insufficient storage for installation". This prevents unnecessary failures for users.

Once an application is installed on an NFC device, the application starts the configuration process by itself, or the TSM server sends a configuration notification to the NFC device via a cellular network or a wireless data network. According to the type of the NFC device, there are many ways to send a message (PUSH message, or push message) to make the NFC device start the configuration process. An example of a sending method includes SMS sending or Android Google sending. Once the user receives the notification, the configuration process begins. The configuration process will be described in detail as deemed appropriate.

As part of the application configuration, the TSM server implements some protective mechanisms. One is to prevent accidental locking of the safety element. Another is to prevent the download of the application if there is not enough storage space in the secure element. In some instances, the secure element may lock itself permanently if there are too many mutual authentication failures during secure channel establishment. To prevent accidental locking of the secure element, the TSM keeps track of the number of authentication failures between the secure element and the TSM when a secure channel is established between the two entities. In one embodiment, if a predetermined limit is reached, the TSM will deny any further requests. If the secure element is manually restarted at the service center, the TSM can continue to process SE requests.

The TSM also keeps track of the storage usage of each secure element. The TSM determines whether an application can be installed on a secure element based on the storage allocation assigned to each service provider by the SE issuer. According to one embodiment, there are three types of policies:

●Pre-allocate a fixed storage space, which is guaranteed space;

● pre-allocate a minimum storage space, which is the guaranteed minimum space (implying that the capacity can be expanded in some cases);

• Best efforts (eg contractually stipulates that the secure element issuer is required to use his best efforts to perform his obligations in order to maximize the benefit to the user).

In one embodiment, the secure element issuer does this using the TSM web portal.

1. For a batch of secure elements, the secure element issuer can pre-allocate a storage policy for the service provider to install its application through the TSM webpage portal;

2. When the mobile device requests to install an application, whether the space of TSM server authentication corresponding service provider meets its storage policy; If not, then reject this request; Otherwise, described TSM server will process described configuration request;

3. If the configuration is successful, the TSM will accumulate the storage size of this application service.

When a mobile user subscribes to a mobile application (if it is already installed), the application needs to be configured via the secure element on the mobile device before said application can be used. In one embodiment, the configuration process includes four main phases;

- Create a Supplementary Security Domain (SSD) on said secure element, if required;

- downloading and installing an application on said secure element;

personalize said application in said secure element;

• Download UI (User Interface) components onto the mobile device.

Figure 2B illustrates a flow or process 220 for configuring one or more applications, according to one embodiment of the invention. The process 220 can be implemented as software or a combination of software and hardware. In one embodiment, the application configuration process 220 requires access to a configuration manager (such as an agent) on the mobile device to interact with the secure element within it.

As shown in Figure 2B, at operation 222, the application configuration process 220 may be started automatically or manually. For example, assuming it has not been configured, the user can initiate the configuration process by selecting an installed application to subscribe to related services, or when activating the installed application. In another embodiment, the application provider sends a message, such as a text message, to said mobile phone to start said configuration process.

In any case, the program 220 proceeds to operation 224 to establish communication with a dedicated server (such as a TSM server or a server operated by the application publisher) after extracting the device information (such as CPLC) from the secure element of the mobile device. . At operation 226, the device information is transmitted to the server along with an identifier identifying the application. In operation 228, the server first identifies the issuer of the secure element based on the device information to determine in operation 230 whether the secure element has been personalized. If the secure element has not been personalized, the process 220 proceeds to operation 232 to personalize the secure element, one embodiment of which may be implemented in accordance with process 110 of FIG. 10 .

Now assume that the secure element in the mobile device has been personalized. The process 220 proceeds to operation 234, where a secure channel is established with the secure element using the derived ISD. Depending on who provides the hardware security module HSM for the ISD (such as TSM or SE issuer), the server will contact the hardware security module to calculate a derived ISD for the secure element, and use this derived ISD to establish a secure aisle. Then, in operation 236, the server checks to see if there is an SSD associated with the application. If the application does not have a corresponding SSD, the server will check the database to see if it is already installed on the secure element. If SSD installation is required, the process 220 proceeds to 240 to install the SSD. In one embodiment, the user is reminded of the installation of the SSD (key). At operation 238, assuming the user refuses to install the SSD, the process 220 stops and proceeds to operation 222, where the configuration process 220 is restarted.

Assume now that an SSD installation process is performed in operation 240 . Installing said SSD is similar to installing an ISD. The TSM server contacts the hardware security module HSM that has the master SSD key in it, and calculates and derives the SSD key set for the secure element. The master SSD key can be in the TSM, service provider, or secure element issuer, depending on how the parties agree.

In order to download/install applications in the secure element, at operation 242 the server is configured to establish a secure channel with the secure element using a derivative SSD. In one embodiment, this is similar to how secure channels are established based on derived ISDs. In operation 244, data for the application is prepared, the details of which will be described in detail below. According to one embodiment, said server contacts said service provider to prepare stored data Application Protocol Data Units (APDUs). According to an application installed in the mobile device, the server may repeatedly distribute stored data to personalize the application. Provided the configuration procedure is successfully executed, additional data including an appropriate interface (e.g., the user interface of each mobile device's application) may be downloaded. In operation 246, the server notifies an application provider of the status of the configured application. Figure 2C illustrates a data flow 250 of interactions between different parties when configuring an application, according to one embodiment and as described above.

As operation 244 in Figure 2B, an important application of the configuration application consists in preparing custom application data for the target secure element. For example, for an electronic wallet application, the personalized data of the application includes various personalized transaction keys generated based on the device information (such as CPLC information) of the secure element. In order to carry the electronic wallet, the part of the personalization data includes the Mifare access key derived from the identifier of the Mifare card, and the server can personalize both the Java card application and the Mifare4Mobile service object. Typically, there are at least two different ways of preparing data to facilitate subsequent transactions.

For data preparation, an embodiment of the present invention supports two modes of interaction with the service provider to calculate personalized application data. For the first mode, the TSM server does not directly access the hardware security module associated with the service provider. The service provider can have a server interacting with its hardware security module generate application keys (e.g. transport, e-wallet or Mifare keys). The implementation of the TSM data preparation is to use the application programming interface (API) or the protocol provided by the server to request a derived application key (derived application key). The second mode is that the data preparation implementation can directly access the hardware security module related to the service provider to generate the application key.

According to one embodiment, Figure 2D shows a data flow 255 for different parties interacting in preparing application data during provisioning of an application. Figure 2D is a first mode, wherein the TSM server does not directly access the hardware security module associated with the service provider. The second mode has a similar process except that the application data preparation implementation will directly interact with the service provider's hardware security module.

In addition to supporting the configuration process, an embodiment of the invention also supports lifecycle management of secure elements. The life cycle management includes, but is not limited to, secure element locking, secure element unlocking, and application deletion (disabled). These activities can be initiated through TSM notifications. In actual use of the mobile device, Figure 2E shows a flow or process 260 of locking installed applications. An NFC device may have installed a certain number of applications running on the secure element. For some reason (eg, long periods of inactivity or expiration), an application needs to be disabled or locked by its publisher or provider.

FIG. 2E illustrates the process 260 of disabling an installed application. The process 260 of disabling an installed application begins at operation 262. In one embodiment, the process 260 is manually initiated by an operator through the TSM web portal. In another embodiment, the process 260 is automatically initiated by the service provider's internal workflow (such as using the TSM web services API). Once the process 260 is initiated, a message is sent to an NFC device (such as within a mobile device) that an application within it needs to be disabled. Such messages MAY have different formats when implemented. In one embodiment, the message is a PUSH command. In another embodiment, said message is a TCP/IP request passed over a network into said NFC device. In operation 264, a server, such as a TSM server, sends the message. When implemented, such a message includes an identifier identifying the application to be locked or disabled. Upon receipt of such a message, at operation 266, the card manager proxy on the NFC device is used to authenticate that such information is indeed from its original issuer or provider by replying with a message. In one embodiment, the message is sent to the TSM server for authentication. If the authentication fails, ie there is no response to such a query, the process 260 will end.

Assuming the authentication passes, i.e. a query from the device for the provider of the application receives a reply acknowledgment, the original request is proven authentic. Typically, at operation 268, such a reply confirmation includes an identifier of the application to be locked. The TSM server is used to establish a secure channel with the secure element. The TSM server then prepares the appropriate APDUs (such as SET STATUS, or/and DELETE) for the secure element via the card manager agent. In operation 270, the device sends an operation request to the secure element to lock a specific application.

In any case, in response to the command, in step 272, the secure element SE locks or disables the application. According to one embodiment, said SE is caused to disassociate from the application, such that said secure element can no longer be used by the installed application. At operation 274, the secure element is used to issue a confirmation to notify interested parties that the application is no longer running on the device. In one embodiment, the acknowledgment is sent to a TMS server that has a database that records which applications are installed on which devices and the corresponding status of each application. The database is updated according to acknowledgments from the secure element.

FIG. 2E shows a flow or process of disabling or locking installed applications. For those of ordinary skill in the art, other operations, such as unlocking or enabling an installed application, extending the time limit of an installed application, are similar to the process shown in Figure 2E.

Referring to Fig. 2F, Fig. 2F is based on a specific embodiment of the present invention, which shows a schematic diagram 280 of the architecture when the portable device is used as an electronic wallet to perform e-commerce and mobile commerce. The diagram 280 includes a cellular phone 282 with an embedded smart card module. An example of such a cellular phone is a cellular phone that supports Near Field Communication (NFC) and includes a SmartMX (SMX) module. Note that secure elements and applications can be integrated. Unless otherwise specified, the following description will not indicate which part performs the function of the secure element and which part is used as an application. It will be understood by those skilled in the art that an appropriate part or function will be implemented according to the detailed description given below.

The SMX module is pre-loaded with a Mifare emulator 288 (i.e. a single function card) for storing values. The cellular phone is equipped with a contactless interface (e.g. ISO14443 RFID) to allow the cellular phone to function as a tag. In addition, the SMX module is a Java card (JavaCard) capable of running Java applet programs. The electronic wallet application package is configured to be able to access the data structure of the Mifare emulator through a password obtained after appropriate conversion of the access key when the secure element is personalized.

An electronic wallet manager MIDlet program 284 is provided in the portable phone 282 . In order to realize mobile commerce, the MIDlet program 284 acts as a communication agent between the electronic wallet applet program 286 and one or more payment networks and servers 290, so that transactions between parties can proceed smoothly. The MIDlet program mentioned here is a software component suitable for running on a portable device. The Wallet Manager MIDlet program 284 may be implemented as a "MIDlet program" on a Java portable phone, or as an "application executable" on a Personal Digital Assistant (PDA) device. One of the functions of the electronic wallet manager MIDlet program 284 is to access the wireless network and communicate with the electronic wallet applet program running on the same device or an external smart card. In addition, the MIDlet program 284 is configured to provide administrative functions, such as changing a personal identification number (PIN), viewing wallet balances and transaction history logs. In one example application the card issuer provides a Secure Identity Module (SAM) 292 for supporting and authenticating any transaction between the card and the corresponding server (i.e. the payment server). As shown in Figure 2F, an Application Protocol Data Module (APDU) command is created by a server 290 that has access to a Secure Identity Module (SAM) 292, which is the communication module between the reader and the card. The structure of the APDU module is formulated according to the ISO7816 standard. Typically, APDU commands are embedded in network messages and sent to the server 290 or the Wallet applet 286 for processing.

A web agent 294 running on a computer (not shown) is responsible for interacting with a contactless reader (such as an ISO 14443 RFID reader) and said web server 290 for electronic commerce. In actual operation, the agent 294 sends an APDU command to the electronic wallet applet program 286 running on the portable phone 282 through the non-contact reader 296, or sends an APDU command from the electronic wallet applet program 286 through the same route. Receive the corresponding reply. Alternatively, the proxy 294 may generate network requests (eg, HTTP) and receive corresponding responses from the payment server 290 .

When personalizing the cellular phone 282, the block diagram 300 in Figure 3A shows the interaction of the relevant modules to complete the personalization of the e-purse by the authorized person. The block diagram 320 in Figure 3B shows the interaction of the relevant modules to complete the process of personalization of the e-wallet by its user as shown in Figure 2F.

The flowchart or process diagram 350 in FIG. 3C shows the process of personalizing the electronic wallet applet program according to a specific embodiment of the present invention. Figure 3C is suggested to be understood together with Figure 3A and Figure 3B. The process diagram 350 can be realized by software, hardware or a combination of software and hardware.

As mentioned above, the electronic wallet manager is built on the already personalized secure element to provide the security mechanism required for personalizing the electronic wallet applet program. In actual operation, the security domain is used to establish a secure channel connecting the personalization application server and the electronic wallet applet program. According to a specific embodiment, the key data that is personalized and stored in the electronic wallet applet program includes one or more operation keys (such as loading or recharging keys and purchase keys), preset personal identification numbers , manage keys (such as blocking unblocking PIN keys and reloading PIN keys), and passwords (such as those from Mifare).

Assume that a user wants to personalize an electronic wallet applet program embedded in a portable device such as a portable phone. In step 352 of Figure 3C, the personalization process is initiated. Depending on the implementation, the personalization process may be implemented in a module within the portable device and activated manually or automatically, or as a physical activation initiated by an authorized person (usually someone connected to the card issuer). process. As shown in FIG. 3A, the authorizer starts a personalization process 304 to personalize the user's electronic wallet applet program. Module 308 is performed through a contactless reader 310 as an interface. The card manager 311 performs at least two functions: (1) establishes a secure channel through the secure domain to install and personalize external applications (e.g., an electronic wallet applet) during the card personalization process; and (2) establishes security measures (such as a personal identification number) to protect the application in subsequent operations. The Wallet applet 312 and emulator 314 are personalized as a result of the personalization process using the personalization application server 304 .

Similarly, as shown in FIG. 3B, an e-wallet user wishes to initiate a personalization process to personalize an e-wallet applet over the air (e.g., through the mobile commerce path in FIG. 2). Unlike Figure 3A, Figure 3B allows the personalization process to be activated manually or automatically. For example, a cellular phone is provided with a device which, if pressed, activates the personalization process. In another approach, a status prompt of "not personalized" may be presented to the user to initiate the personalization process. As previously mentioned, the MIDlet program 322 (i.e., a service manager) in the portable device acts as a proxy to facilitate communication between the payment server 324, which has access to existing New e-wallet security identification module 306 and existing security identification module 308 permissions. Through the personalization process, the electronic wallet applet 312 and the emulator 314 are personalized.

Referring back now to FIG. 3C, after the personalization process shown in FIG. 3A is initiated, the contactless reader 310 is activated and reads the tag identifier (ID) (i.e. RFID tag ID) and key data. By applying the security domain (such as the default security setting of the card issuer), in step 356, a connection is established between the new electronic wallet security identification module (such as the security identification module 306 in Figure 3A) and the electronic wallet applet program (such as Figure 3A The safe channel of the electronic wallet applet program 312) in.

Each application security domain of the global platform includes three DES keys. E.g:

Key 1: 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f

Key 2: 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f

Key 3: 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f

The security domain is used to generate session keys for a secure session between two entities, such as a card manager applet and a host application, which may be a desktop computer Personalized applications in , may also be networked personalized services provided by back-end servers.

Default application domains can be installed by the card issuer and assigned to different application/service providers. Each application owner may change the values of their respective key sets prior to (or during the initial stages of) the personalization process. The application can then use said new set of keys to create a secure channel for performing the personalization process.

Through said secure channel established by the application security domain of the application provider, the first set of data can be personalized and stored in the electronic wallet applet program. A second set of numbers can likewise be personalized through the same channel. However, if said data is stored in a different secure identity module, a new secure channel using the same set of keys (or a different set of keys) can be used to personalize said second set of data.

In step 358, a group of electronic wallet operation keys and personal identification numbers are generated by the new electronic wallet security identification module 306 for data exchange between the new electronic wallet security identification module and the electronic wallet applet program, and in essence Personalize the electronic wallet applet program.

In step 360, the second security channel is established between the existing security identification module (such as the security identification module 308 in FIG. 3A ) and the electronic wallet applet program in the portable device (such as the electronic wallet applet program 312 in FIG. 3A ] Set up.Use described existing security identification module and tag ID to generate one group of converted key in step 362.The key after described conversion is preserved in described emulator for data access authentication afterwards.Step 358 Use the existing security identification module and tag ID to generate a group of MF passwords, and store the passwords into the electronic wallet applet program for subsequent data access authentication. After all the above operations are completed, the electronic wallet includes The electronic wallet applet program and the corresponding simulator will be set to the "personalized" state.

Figures 4A and 4B together illustrate a flow or process diagram 400 for funding or injecting funds into an electronic wallet, according to a specific embodiment of the present invention. Process 400 is implemented through the mobile commerce path in FIG. 2 . To better understand process 400, FIG. 4C shows a representative block diagram 450 of related blocks that interact to accomplish process 400 as described. According to different situations of the actual application of the present invention, the process 400 may be implemented by software, hardware, or a combination of software and hardware.

Assuming that the user has obtained a portable device (such as a portable phone) with an electronic wallet installed. The user wishes to inject funds into the electronic wallet from the account of the bank. In step 402, the user enters a set of personal identification Number (PIN). Assuming that the personal identification number is valid, the electronic wallet manager in the portable device is activated and initiates a request in step 404 (also known as an OTA (Over-the-Air) recharge request). In step 406, the MIDlet program in the portable device sends a request to the electronic wallet applet program. FIG. 4C depicts the communication process between the electronic wallet manager MIDlet program 434 and the electronic wallet applet program 436 in step 406.

In step 408, the electronic wallet applet program generates a reply for responding to the request of the MIDlet program. After receiving the reply, the MIDlet program sends the reply to the payment network and the server through the cellular communication network. As shown in FIG. 4C , the Wallet Manager MIDlet program 434 communicates with the Wallet applet program 436 to obtain a reply, which is then sent to the payment network and server 440. At step 410, process 400 needs to verify the validity of the reply. If the reply cannot be verified, process 400 will terminate. If the reply is verified as valid, the process 400 proceeds to step 412 and checks the corresponding account in the bank. If the account in question does exist, a funds transfer request will be initiated. In step 414, the bank will return a reply to respond to the request after receiving the request. Usually, the information exchange between the payment network and the server and the bank needs to comply with network protocols (such as the HTTP protocol used by the Internet).

In step 416, the reply returned by the bank is sent to the payment network and server. In step 418, the MIDlet program extracts the source APDU command from the reply and forwards the command to the Wallet applet program. In step 420 the e-wallet applet verifies the command, and if the command is verified as authorized, the command is sent to the emulator in step 420 and the transaction log is updated. In step 422, a ticket is generated to formulate a reply (such as a reply in APDU format) sent to the payment server. In step 424, after receiving the reply, the payment server updates and sends success status information to the MIDlet program, and saves the APDU reply for later checking.

As shown in Figure 4C, the payment network and server 440 receive the reply sent by the electronic wallet manager MIDlet program 434, and verify with the security identification module 444 that the reply was originally issued by the authorized electronic wallet applet program 436. After the reply is verified, the payment network and server 440 sends a request to the funding bank 442, assuming the user 432 has an account with the bank. The bank will verify and authorize the request, and then return an authorization number in a predetermined message format. After receiving the reply from the bank 442, the payment server 440 will send a network reply to the MIDlet program 434 to deny or approve the request.

The electronic wallet manager 434 verifies the validity of the network reply (eg, whether it is in APDU format), and then sends a command to the emulator 438 and updates the transaction log. So far, the electronic wallet applet program 436 completes the required steps and returns a reply to the MIDlet program 434 , and the MIDlet program 434 forwards a network request embedded in (APDU) reply to the payment server 440 .

Although the process 400 is described as injecting funds into the electronic wallet, other skilled in the art can easily draw the conclusion that the process of using the electronic wallet to purchase through the network is essentially the same as the process 400, so the process of making the purchase The process is not discussed separately here.

A first example architecture 500 for enabling a portable device 530 to conduct electronic commerce and m-commerce over a cellular communication network 520 (e.g., a GPRS network) is shown in FIG. 5A, according to a specific embodiment of the present invention. The portable device 530 consists of a baseband 524 and a secure element 529 (eg a smart card). An example of the portable device is a portable device (such as a portable phone or a personal digital assistant (PDA)) that supports short-range communication or near field communication (NFC, Near Field Communication). The baseband 524 provides an electronic platform or environment (such as a miniature version of Java (JME, JavaMicro Edition), or a mobile information device framework (MIDP, Mobile Information Device Profile)), on which the application MIDlet program 523 and the application MIDlet program 523 and Server Manager 522 . The secure element 529 includes a Global Platform (GP) card manager 526, an emulator 528 and other components such as a pin manager (not shown).

In order to support the portable device 530 to perform e-commerce and mobile commerce, one or more services/applications need to be pre-installed and configured on it. An instance of the service manager 522 (such as a MIDlet program with a graphical user interface) needs to be activated. In one particular embodiment, service manager 522 can be downloaded and installed. In another embodiment, the service manager 522 may be pre-loaded. Either way, once the service manager 522 is activated, a directory listing containing various services will be displayed. The directory list may include service items related to the user's subscription information, and may also include recommended items independent of the user's subscription information. The directory listing is available from directory repository 502 on directory server 512. Directory server 512 acts as a central hub (e.g., yellow pages function) for various service providers (e.g., installation servers, personalization servers) that may offer products and/or services to registrants. The yellow pages function of the directory server 512 can include service planning information (such as service charges, start date, end date, etc.), installation, personalization and/or MIDlet program download location (such as Internet address). The installation and personalization The process may be provided by two different commercial entities, for example the installation process may be provided by the publisher of the secure element 529, while the personalization process may be provided by a service that holds the application processing key for the specific application provided by the merchant.

According to a particular embodiment, the service manager 522 is configured to connect to the one or more servers 514 of the service provider through the cellular communication network 520 . It is assumed that the user has selected an application from the catalog of services presented to him. A secure channel 518 will be established between the one or more servers 514 and the global platform manager 526 to install/download the application applet 527 selected by the user, then personalize the application applet 527 and enable Selected emulator 528, and finally download application MIDlet program 523. Applet library 504 and MIDlet library 506 provide general application applet programs and application MIDlet programs, respectively. The global platform security identification module 516 and the application program security identification module 517 are used to establish a security channel 518 to carry out personalized operations.

Figure 5B illustrates a second example architecture 540 that enables a portable device 530 to perform electronic commerce and mobile commerce over a public network 521, according to another specific embodiment of the present invention. Most of the components in the second architecture 540 are similar in nature to those in the first architecture 500 of Figure 5A. The difference is that the first architecture 500 is based on operations over a cellular communication network 520, while the second architecture 540 uses a public network 521 (such as the Internet). The public network 521 may include a local area network (LAN, Local Area Network), a wide area network (WAN, Wide Area Network), a WiFi (IEEE 802.11) wireless connection, a Wi-Max (IEEE802.16) wireless connection, and the like. In order to perform service operations on the public network 521, an instance of the service manager 532 (i.e. an instance with the same or similar function as the service manager MIDlet program 522) will be installed on a computer 538 connected to the public network 521. The computer 538 may be a desktop personal computer (PC), a laptop, or other computing device capable of running the instance of the service manager 532 and connected to the public network 521. The connection between the computer 538 and the portable device 530 is made via a contactless reader 534. The service manager 532 acts as a proxy to facilitate the installation and personalization process between the service provider's server(s) 514 and the Global Platform Card Manager 526 over the secure channel 519 .

Figure 5C is a flowchart depicting a process 550 for enabling electronic commerce and m-commerce functionality on a portable device, according to one embodiment of the present invention. The process 550 may be implemented by software, hardware, or a combination of software and hardware according to different implementations. To better understand the process 550, reference will be made to several earlier figures in the following description, particularly Figures 5A and 5B.

Before process 550 begins, an instance of service manager 522 or 532 has been downloaded or pre-installed on portable device 530 or computer 538. At step 552, the service manager is activated and sends a service request to the server 514 at the service provider. After the user is identified and the portable device is verified as valid, in step 554, the process 550 provides a directory listing of services/applications based on the subscription information of the user of the portable device 530. For example, the list might include mobile point-of-sale applications, e-wallet applications, e-ticketing applications, and other commercialized services. A service/application is then selected from the directory listing. For example, an electronic wallet or mobile point of sale may be selected to configure portable device 530 . In response to the user selection, process 550 downloads and installs the selected service/application at step 556 . For example, the electronic wallet applet application program (i.e. the application applet program 527) is downloaded from the applet program library 504 and installed in the secure element 529. The path for downloading or installing may be a secure channel 518 or 519 . In step 558, process 550 personalizes the downloaded application applet and the emulator 528, if desired. Some downloaded application applets do not need to be personalized, others do. In one embodiment, the mobile point-of-sale application applet ("Point-of-Sale Security Identification Module (POS SAM)") needs to be personalized, then the following information or data sets must be provided:

(a) Unique security identification module ID based on the unique identifier of the underlying security element;

(b) a set of debit master keys;

(c) a converted message encryption key;

(d) a converted message identification key;

(e) The maximum allowed length of the remarks section of each offline transaction;

(f) a transformed bulk transaction key; and

(g) A Global Platform Personal Identification Number (GP PIN).

In another specific embodiment, when personalizing the electronic wallet applet program for a single-function card, it is not only necessary to configure specific data (i.e. personal identification number, converted key, start date, end date, etc.) in the electronic wallet, Also set up the emulator to work in an open system. Finally, in step 560, process 550 downloads and launches application MIDlet program 523 upon selection. Certain personalization data in the application applet may be accessed and displayed, or provided by the user. The process 550 ends after all service/application components have been downloaded, installed and personalized.

According to a specific embodiment, a representative process for enabling portable device 530 to function as a mobile point of sale is as follows:

(a) Access the installation server (i.e. a server 514 of the service provider), and request said server to set up the first secure channel (eg secure channel 518) to connect to a publisher domain (i.e. the applet library 504) with the Global Platform Card Manager 526 running on the Secure Element 529;

(b) receiving one or more network messages, including some APDU requests of encapsulating point-of-sale security identification module applet program (such as a Java Cap file from applet program library 504) in the message;

(c) extracting the APDU request from the received network message;

(d) send the extracted APDU request to the global platform card manager 526 according to the correct order, so as to install the point-of-sale security identification module (i.e. the application applet program 527) on the secure element 529;

(e) access a personalization server (i.e. a service provider's server 514), to open the second secure channel connecting the personalization server and the newly downloaded applet program (i.e. the point-of-sale security identification module) ( Depending on the server and/or path, the secure channel may or may not be a secure channel 518).

(f) receive one or more network messages to obtain one or more individual "data storage APDU (STORE DATAAPTU)";

(g) extracting and sending said "STORE DATA APDU" to personalize the point-of-sale security identification module; and

(h) Download and start the point of sale manager (ie apply the MIDlet process 523).

Figure 6A illustrates a representative architecture 600 in which a portable device 630 acts as a mobile point of sale to perform electronic commerce and mobile commerce, according to an embodiment of the present invention. The portable device 630 consists of a baseband 624 and a secure element 629. A point of sale manager 623 is downloaded and installed in the baseband 624 and a point of sale security identification module 628 is personalized and installed in the secure element 629 to enable the portable device 630 to act as a mobile point of sale. Such a real-time transaction 639 can be conducted between a mobile point-of-sale enabled portable device 630 and an electronic token enabled device 636 (such as a single function card or an e-wallet enabled mobile device). The e-token may represent e-money, e-coupon, e-ticket, e-voucher or any other form of payment token in the device .

The real-time transaction 639 can be performed offline (i.e. without connecting the portable device to the back-end point-of-sale transaction processing server 613). However, in specific practical situations, such as when the transaction volume exceeds a predetermined threshold, or when the device 636 supporting electronic tokens needs to be recharged or virtual recharged, or when (single or batch) transactions are uploaded, the portable device 630 can The backend point of sale transaction processing server 613 is accessed through the cellular network 520 .

The accumulated offline transaction records need to be uploaded to the back-end point-of-sale transaction processing server 613 for processing. The uploading operation is performed by a portable device 630 that accesses the point-of-sale transaction processing server 613 through a secure channel 618. Similar to the installation and personalization process described, the upload operation can be performed via two different routes: the cellular communication network 520; or the public network 521. Figure 6A depicts the first route.

The second route is shown in FIG. 6B, which shows a representative architecture 640 according to one embodiment of the present invention, wherein the portable device 630 acts as a mobile point of sale and executes transaction batches over the public network 521. The upload operation. The offline transaction records in the mobile point of sale are generally accumulated and stored in the transaction log in the point of sale security identification module 628. The transaction log is read by a contactless reader 634 and stored in a point-of-sale agent 633 installed in a computer 638. The point-of-sale agent 633 then accesses the point-of-sale transaction processing server 613 through a secure channel 619 on the public network 521. Each upload that contains one or more transactions is marked as a separate bulk upload. Data communications between the point of sale secure identification module 628, the contactless reader 634, and the point of sale agent 632 are formatted and include the transaction record. Network messages encapsulating APDUs (e.g., HTTP) are then used for communications between the point-of-sale agent 632 and the point-of-sale transaction processing server 613.

In one particular embodiment, a representative bulk upload process from a point of sale manager 623 or point of sale agent 633 includes:

(a) sending a request to the point-of-sale secure identification module 628 to initiate a bulk upload operation;

(b) After the point-of-sale security identification module 628 agrees to the bulk upload request, retrieve it in the form of an APDU command from the "batch" or "group" marked in the point-of-sale security identification module 628 accumulated transaction records;

(c) creating one or more network messages comprising the retrieved APDU command;

(d) sending the one or more network messages to the point-of-sale transaction processing server 613 via the secure channel 619;

(e) receiving a confirmation signature message from said point-of-sale transaction processing server 613;

(f) transfer the confirmed signature message to the point-of-sale security identification module 628 in the form of APDU for verification, and then delete the confirmed uploaded transaction record; and

(g) If there are still other unuploaded transaction records in the same "batch" or "group", repeat steps (b) to (f).

Figure 6C shows a flowchart depicting a process 650 for conducting mobile commerce using a portable device 630 acting as a mobile point of sale and a device 636 acting as a single function card and supporting electronic tokens, according to an embodiment of the present invention. For easier understanding, it is best to examine process 650 in relation to the previous illustrations, especially FIGS. 6A and 6B . The process 650 can be realized by software, hardware, or a combination of software and hardware.

When the holder of an electronic token device (such as a Mifare card or a portable phone that supports an electronic wallet and simulates a single-function card) wishes to purchase an item or order a service through a mobile point of sale (i.e., a portable device 630), the process 650 (such as The process> carried out by the point of sale manager 623 among Fig. 6A just can be started.In step 652, portable device 630 reads the device that supports electronic token and gets back electronic token (such as the label ID of Mifare card) The process 650 then verifies whether the retrieved electronic token is valid in step 654. If the electronic token supporting device 636 in FIG. The verification process includes: (i) reading the card's card identification (ID), which is stored on an area that is not protected or protected only by a known key; 628 sends a request containing the card identification; (iii) receives one or more transformed keys (such as keys for transaction counts, issuer data, etc.) generated by the point-of-sale security identification module 628. If the If the received one or more converted keys are invalid, i.e. the retrieved electronic token is invalid, then end process 650. Otherwise, process 650 will advance to step 656 along the "yes" branch, in step 656 It will be determined whether there is sufficient balance in the electronic tokens retrieved to pay the required fees for the current transaction. If the result of step 656 determination is "no", process 650 can choose to propose that the holder is in step 657 If the holder chooses to "deny" the offer, process 650 ends. Otherwise, if the holder agrees to support the electronic token If the device of the token performs real-time recharge, the process 650 performs a recharge or virtual recharge operation in step 658. After that, the process 650 returns to step 656. If there is enough currency balance in the electronic token, the process 650 receives the electronic token from the supporting electronic token in step 660. The amount required to complete the purchase is debited or debited from the electronic token of the token device 636. In the case of the single function card, the one or more converted keys are used to authorize the debiting operation .Finally in step 662, one or more offline transaction records accumulated in the point-of-sale security identification module 628 are uploaded to the point-of-sale transaction processing server 613 for processing. The upload operation can be performed through the cellular communication network 520 or the public domain network 521 Do it on a single transaction or in batches.

Process 400 in FIG. 4A describes the aforementioned top-up operation. A virtual top-up operation is a special type of said top-up operation, which is usually used by patrons or donors to increase the credit limit of electronic tokens. In order to be able to use the virtual recharge operation, the patron needs to set up an account and bind the account with a device that supports electronic tokens (such as a single-function card, a multi-function card, a mobile phone that supports electronic tokens, etc.) . For example, online accounts provided by commercial entities (eg, businesses, banks, etc.). Once the patron has loaded the online account with electronic tokens, the holder of the electronic token enabled device can receive electronic tokens from the online account when accessing a mobile point of sale. Various security measures will be implemented to ensure that the virtual top-up operation is safe and secure. A representative application scenario of the virtual top-up is that the parent (ie, the patron) can charge electronic tokens into an online account that is connected to a child (ie, the device holder) (i.e., a device that supports electronic tokens) so that the child can receive the charged electronic tokens when the child purchases items at the mobile point of sale. In addition to the various e-commerce and m-commerce functions described herein, the point-of-sale manager 623 is also configured to provide a variety of query operations, such as (a) checking the accumulated unformed batches in the point-of-sale security identification module (i.e. not uploaded), (b) lists the unbatched transaction log in the point of sale security identification module, (c) displays the details of a specific transaction stored in the point of sale security identification module, (d) checks The current balance of the e-token enabled device, (e) lists the transaction log of the e-token enabled device, and (f) displays details of a particular transaction of the e-token enabled device.

The flowchart in FIG. 6D depicts a representative process for conducting mobile commerce using a portable device 630 that acts as a mobile point of sale and a device 636 that acts as a multi-function card and supports electronic tokens, according to an embodiment of the present invention. The process 670. For better understanding, process 670 is best considered in conjunction with the previous illustrations, particularly Figures 6A and 6B. The process 670 can be implemented by software, hardware, or a combination of software and hardware.

Process 670 ( A process such as that performed by point-of-sale manager 623 in FIG. 6A) will be initiated. At step 672 , the process 670 sends an initial purchase request to the electronic token enabled device 636 . A purchase fee is sent with the initial purchase request (eg, order). Process 670 then proceeds to decision step 674. When there is insufficient balance in the electronic token enabled device 636, the point of sale manager 623 will receive a response message denying the initial purchase request. The result is that process 670 ends with the purchase request being denied. If there is sufficient balance in the device 636 supporting electronic savings, the result of decision step 674 is "Yes", and process 670 will follow the "Yes" branch to step 676. Responses (e.g., APDU commands) received from the e-token enabled device 636 are forwarded to the point-of-sale security identification module 628. The information in the reply includes the version of the e-token key, and a random number that will be used to establish a secure channel to an applet on the e-token enabled device 636 (e.g., an e-wallet applet) and the point-of-sale security identification module 628 installed on the portable device 630 . Then, at step 678, the process 670 receives a debit request (eg, an APDU command) generated by the point of sale security identification module 628 in response to the forward reply (ie, the reply at step 676). The debit request includes a message identification code (MAC, Message Authentication Code) so that the applet program (i.e. the electronic wallet applet program) can verify the upcoming debit operation, wherein the upcoming debit operation is to respond to the message sent in step 680 for debit requests. Process 670 proceeds to step 682, where a confirmation message for the debit operation is received. The confirmation message includes an additional message identification code that is used by the point of sale security identification module 628 and the point of sale transaction processing server 613 for verification and processing, respectively. Next at step 684, the debit confirmation message is forwarded to the point of sale secure identification module 628 for verification. Once the message identification code is verified as valid and the purchase transaction is recorded in the point of sale security identification module 628, the recorded transaction is displayed in step 686 and process 670 ends. It should be noted that the aforementioned e-commerce transactions can be conducted offline or online through the point-of-sale transaction processing server 613. And when the balance in the electronic token supporting device is insufficient, a top-up or funding operation may be performed according to the process 400 depicted in FIGS. 4A and 4B .

Figure 7 shows a representative setup when a portable device is used for an electronic ticketing application. Portable device 730 is configured to include an electronic wallet 724. When the owner or holder of the portable device 730 wishes to purchase tickets for a particular event (such as concert tickets, ball game tickets, etc.), the owner can use the electronic wallet 724 to pass through an electronic ticket service provider 720. buy tickets. The electronic ticket service provider 720 may contact a conventional box office reservation system 716 or an online ticketing application 710 to reserve and purchase the tickets. Electronic tokens (e.g., electronic money) are then deducted from the electronic wallet 724 of the portable device 730 to pay for the ticket purchase to a credit/debit system 714 (e.g., a financial institution, bank). The security identification module 718 is connected to the electronic ticket service provider 720 to ensure that the electronic wallet 724 in the portable device 730 is correctly identified. After receipt of payment confirmation, the electronic ticket is transmitted to the portable device 730 over the air (such as a cellular communication network) and stored electronically on the secure element 726, such as in the form of an electronic ticket code, key or password. Way. Afterwards, when the owner of the portable device 730, that is, the holder of the electronic ticket, attends the specific event, the electronic ticket holder only needs to let the entrance registration reader 734 read the information in the portable device 730. Saved e-ticket code or key. In one embodiment, the entry registration reader 734 is a non-contact reader (eg, an ISO 14443 compliant ultra-short range coupling device). The portable device 730 is a mobile phone supporting Near Field Communication (NFC).

Reference is now made to FIG. 8A, which shows a schematic diagram of the multiple parties involved in a TSM run or scheduled by a service, in one embodiment. The TSM operations team 802 includes administrators (administration, admin for short, or manager or admin) who are responsible for managing accounts for users who have personalized their secure elements through TSM or other tasks. In one embodiment, the TSM operations team 802 includes someone who manages the account, someone who manages system resources (such as managing HSMs, creating HSM indexes and GP key maps). In addition, the team is also responsible for offline input of default ISD information from one or more SE manufacturers. The team also includes people called certification engineers who work with service providers and SE issuers according to the application approval process. The TSM sales team 804, also known as business account managers, is responsible for sales and account management for TSM's vendors. Some members of the team 804 may only work for the SE manufacturer, some may only work for the SE issuer, and others may work for multiple types of suppliers. The TSM cooperative service team 806, which can also be referred to as a support engineer, is responsible for providing technical support to suppliers of TSM (such as SE issuers and service providers). The TSM cooperative service team 806 does not directly contact the mobile user, but can help partners analyze audit logs (audit logs). The suppliers 808 include one or more of SE issuers, SE manufacturers, and service providers. SE issuers are responsible for the issuance of SEs and own the ISDs of said SEs. The SE publisher works with the TSM team, who can install additional SSDs for service providers if needed. The SE maker, as the name suggests, is responsible for manufacturing the SE and installing a default ISD within the SE. It can also work with the TSM team to provide these default ISD key sets. The service provider is responsible for developing NFC mobile applications. Examples of applications from such service providers include, but are not limited to, transit wallets, bank e-wallets, and credit cards. Small service providers may be those who provide applications used as room keys.

Figure 8B illustrates the correlation process between the parties involved in the TSM in one embodiment. The description of the operations is not described in detail here to avoid obscuring the focus of one embodiment of the invention. FIG. 8C illustrates an example workflow in TSM for establishing a mutual consent agreement between parties. SE issuers or service providers require TSM to keep their GP key sets. In one embodiment, this GP key set is most likely to be used as the ISD for the SE issuer. For the service provider, this GP key set is used as SSD. As shown in Figure 8C, the process of creating a key set involves creating keys in the HSM and creating mappings in the TSM system. The validity range of the mapping will be set to the contract expiring date. In general, the HSM key index (key index) cannot be valid for multiple mappings at the same time.

When the key set is about to expire, it can be renewed. The update flow is similar to the creation process shown in Figure 8C. According to one embodiment, the TSM will periodically send a notification to the owner of the key set several months before the key set expires. Once the owner of the key set updates the contract, the notification stops. The owner of the key set can start the update process by creating a work request or project. A trusted TSM business account manager approves or rejects the work item. Upon receipt of the approved work item, the TSM manager updates the expiration date of the key set according to the updated contract.

Similarly, the key set may expire or end earlier. The ending flow is similar to the creation flow shown in Fig. 8C. The keyset owner may request that the keyset be discontinued at a future date. The trusted TSM business account administrator will immediately verify and approve or deny the request. The TSM administrator sets the expiration date of the mapping to a specified date. The TSM regenerates the HSM key index for other providers. Audit logs are kept to record traces of said transactions.

Figure 8D shows the data flow of ISD mapping between SE issuer and TSM. In general, the ISD map is managed directly by each SE issuer. SE issuers can create a mapping to bind an external or internal key set to an ISD key index. An external key set is a key set not present in the HSM associated with the TSM, and an internal key set is a key set present in said HSM. Normally, the SE issuer should not need to specify a default ISD, since the default ISD is from the SE manufacturer. However, SE issuers may choose to override this default ISD if desired.

As shown in Figure 8D, the SE issuer creates an ISD map for the Card OS to bind the key set and the ISD key index (eg range from 1-127). If the keyset is not external, the TSM will ensure that a keyset mapping with its HSM exists. In operation, the SE issuer can directly modify or delete the ISD map. As mentioned above, the SE manufacturer has default ISD information for the secure element. The TSM provides batch and real-time means for SE manufacturers to share this information. Based on the agreement with TSM, the SE manufacturer can use batch or real-time mode, which has been described.

For security reasons, the service provider (SP) may wish to have their own SSD in order to personalize his application. The SSD map is created by the SE issuer to bind a key index assigned to the service provider to the SP key set. FIG. 8E shows the corresponding data flow among TSM, SE issuer, and service provider. Similar to the creation of the SSD, the service provider can request the SE issuer to delete an SSD mapping. The described workflow is basically similar to the described SSD creation process.

As shown above, the application provided by the service provider for the user. Before a mobile user can order and download an application, the application needs to be approved or published. For example, a service provider needs to submit an application to the SE issuer and TSM for approval. Figure 8F shows the data flow for approving an application by the SE issuer. If a dedicated SSD is required, the service provider can pre-request one as above, or indicate it in the request. The service provider or the SE issuer may initiate the publication process before the approved application is available to the general public. Both parties must agree before the application is published for the user in the TSM. Subsequently, the supplier is notified of the date and validity of the application.

In some instances, the secure element needs to be replaced. Said secure element can be replaced at the request of the mobile user or his SE issuer. Usually, the SE needs to be updated for more services and larger storage space. The following three points should be noted:

● For these applications, their application status needs to be migrated from the old secure element, which needs to still be accessible by the application (via TSM);

- For those applications that do not require state migration, the TSM only needs to reset and personalize the application;

• However, if an application whose state is in the SE but does not support state migration, the TSM cannot migrate their state. For these applications, they will be treated in the second way (i.e. the application must be reset and personalized).

Fig. 8G shows the process of replacing the secure element. The SE issuer notifies TSM about:

The SE issuer notifies TSM about the SE replacement request;

The TSM cooperates with the service provider to prepare APDU commands to collect the state of the application on the old SE;

● For each application, TSM executes the command APDU command to extract the application state, and locks the application;

• The TSM notifies the mobile user to physically change the new secure element. The mobile user can change his/her mind to cancel or rollback the replacement request. There will be no revocation or return after this step;

● TSM will update the default ISD if it has not been processed;

• In collaboration with the service provider, the TSM will install and personalize or configure each application. TSM will install the SSD for the service provider if required. The personalization data is prepared based on the service provider's static data and dynamic application state.

As shown in Figure 9, which shows an example of a snapshot of the display screen of an account of a personalized secure element. Like the menu, the account maintains details of secure elements that have been personalized. Additionally, the account includes a set of configured applications and security keys. Other information may also be maintained, such as the application owner (the person who developed the application), trusted connections to the TSM, SE logs, and application logs.

The present invention is more suitable to be implemented in the form of software, but it can also be implemented in the form of hardware or a combination of software and hardware. The present invention can also be embodied as codes on a computer readable medium that can be read by a computer. The computer readable medium is any data storage device that can store data that can be read by a computer system. Examples of computer readable media include read only memory, random access memory, compact disc (CD-ROM), digital video disc (DVD), magnetic tape, optical data storage devices, and carrier waves. The computer-readable medium can also be distributed among multiple computer systems connected via a network, so that the computer-readable code will be stored and executed in a distributed manner.

The above description has fully disclosed the specific implementation manners of the present invention. It should be pointed out that any changes made by those skilled in the art to the specific embodiments of the present invention do not depart from the scope of the claims of the present invention. Accordingly, the scope of the claims of the present invention is not limited only to the foregoing specific embodiments.

Claims (14)

1. A method for settlement and payment, characterized in that it comprises: Providing a software module for execution on a first mobile device embedded with a secure element, wherein said secure element has been personalized, said software module is configured via said secure element, said first mobile device comprising information relating to an electronic bill The data; After a user of a second mobile device approves payment for an electronic bill wirelessly transmitted from the first mobile device, receiving a payment request from the second mobile device, wherein the second mobile device is a near field communication means for executing an application in communication with a software module in said first mobile device to read said data from said first mobile device; verify said payment request; and After the payment request is processed, a payment response is sent to the user of the first mobile device. 2. The method of claim 1, wherein the second mobile device includes a display screen, and the electronic bill is displayed using the display screen when the data is entered into the second mobile device. 3. The method according to claim 2, wherein said verifying said payment request comprises: When the settlement amount provided by the user of the second mobile device is less than the payable amount on the electronic bill, sending a rejection message to the second mobile device; or When the settlement amount provided by the user of the second mobile device is equal to or greater than the payable amount on the electronic bill, the payment process is continued. 4. The method of claim 3, wherein the data further includes an identifier of the personalized secure element, and the verifying the payment request further comprises: verifying whether the user of the second mobile device maintains an account for settlement of the electronic bill and whether the identifier of the secure element has been authenticated, The method further includes: exchanging encrypted information with a financial institution holding the second mobile device to transfer the settlement amount provided by the user of the second mobile device to a designated account of the user of the first mobile device. The account of the user of the device; upon receiving confirmation that the settlement amount has reached the designated account, generating the payment response. 5. The method of claim 1, wherein said first mobile device is part of a contactless card and a point of sale device for generating said electronic bill, said contactless card being loaded with said electronic bill , said data further comprising an identifier of said personalized secure element and an identifier of a user of said first mobile device to facilitate settlement of charges in said electronic bill by means of a service managed by a trusted service , The second mobile device includes an electronic wallet funded by a financial institution, the second mobile device having an emulator embedded therein for currency transactions. 6. The method according to claim 5, characterized in that: the electronic wallet is supported by a program running on the second mobile device, and the program is configured through the security element of the second mobile device, so The method also includes: establishing a first secure channel between the program and the secure identification module or payment server; A second secure channel is established to exchange various data between the program and the security identification module originally used to issue the program and between the simulator and the security identification module. 7. The method of claim 6, further comprising: Initiating a request from said program upon entry and receipt of a valid PIN on said second mobile device; A response is transmitted to a payment server configured to verify that the response is from an authenticated program, wherein the payment server further communicates with the financial institution to approve a transaction. 8. A gateway for settlement and payment, said gateway comprising: A portal providing a software module executed on a first mobile device embedded with a secure element, wherein said secure element has been personalized, said software module configured via said secure element, said first mobile device comprising Data relating to an electronic bill; A server consists of: a processor, A memory connected to the processor for storing codes executed on the processor, so that the server can perform the following operations: After a user of a second mobile device approves payment for an electronic bill wirelessly transmitted from the first mobile device, receiving a payment request from the second mobile device, wherein the second mobile device is a near field communication means for executing an application in communication with a software module in said first mobile device to read said data from said first mobile device; verify said payment request; and After the payment request is processed, a payment response is sent to the user of the first mobile device. 9. The gateway according to claim 8, wherein said second mobile device includes a display screen for displaying said electronic bill when said data enters said second mobile device. 10. The gateway according to claim 9, wherein said verifying said payment request comprises: When the settlement amount provided by the user of the second mobile device is less than the payable amount on the electronic bill, sending a rejection message to the second mobile device; or When the settlement amount provided by the user of the second mobile device is equal to or greater than the payable amount on the electronic bill, the payment process is continued. 11. The gateway according to claim 10, wherein said data further includes an identifier of said personalized secure element, and said verifying said payment request further comprises: verifying whether the user of the second mobile device maintains an account for settlement of the electronic bill and whether the identifier of the secure element has been authenticated, The method further includes: exchanging encrypted information with a financial institution holding the second mobile device to transfer the settlement amount provided by the user of the second mobile device to a designated account of the user of the first mobile device. The account of the user of the device; upon receiving confirmation that the settlement amount has reached the designated account, generating the payment response. 12. The gateway of claim 8, wherein said first mobile device is part of a contactless card and a point of sale device for generating said electronic bill, said contactless card being loaded with said electronic bill , said data further comprising an identifier of said personalized secure element and an identifier of a user of said first mobile device, to facilitate settlement of charges in said electronic bill by transfer by means of a service managed by a trusted service . 13. The gateway of claim 8, wherein said second mobile device includes an electronic wallet funded by a financial institution, said second mobile device embedding an emulator for currency transactions, said electronic wallet Supported by a program running on the second mobile device configured via a secure element of the second mobile device, the method further comprising: establishing a first secure channel between the program and the secure identification module or payment server; A second secure channel is established to exchange various data between the program and the security identification module originally used to issue the program and between the emulator and the security identification module. 14. The gateway according to claim 13, further comprising: Initiating a request from said program upon entry and receipt of a valid PIN on said second mobile device; A response is transmitted to a payment server configured to verify that the response is from an authenticated program, wherein the payment server further communicates with the financial institution to approve a transaction.