CN101295394B - Method and apparatus for providing electronic commerce and mobile commerce - Google Patents

Abstract

The present invention discloses techniques for using a portable device as an electronic purchaser (e.g., an electronic purse) and/or an electronic mobile merchandiser (e.g., a Point-of-sale (POS)). According to one aspect of the present invention, an apparatus is provided for enabling portable devices to conduct e-commerce and m-commerce transactions over an open network through a payment server and/or a point-of-sale transaction processing server without compromising security. In one particular embodiment, the portable device is loaded with an electronic wallet to serve as an electronic mobile purchaser. In another embodiment, the portable device is loaded into a mobile point of sale for use as an electronic mobile vendor.

Description

Method and device for providing electronic commerce and mobile commerce

Cross-reference to related application documents

This application is a continuation-in-part of co-pending US Patent Application Serial No. 11/543,653, filed September 24, 2006.

technical field

The present invention generally relates to transactions over networks, and in particular, the present invention relates to electronic commerce that can be effectively applied to portable devices customized for electronic commerce (E-Commerce, Electronic Commerce) and mobile commerce (M-Commerce, Mobile Commerce). Wallets and Mobile Point-of-Sales (POS).

Background technique

Single-function cards have been successfully used in closed environments such as transportation systems. An example of such a single function card is the contactless smart card (MIFARE), which is the most installed contactless smart card technology in the world. With more than 500 million smart IC cards and more than 5 million card reader components sold, MIFARE has been selected as the most successful contactless smart card technology. MIFARE provides the perfect solution for applications such as credit (loyalty) and vending (vending) cards, road tolls, city cards, access control and gaming.

However, the application of the single-function card is deployed in a closed system, and it is difficult to extend the application to other fields such as e-commerce and mobile commerce, because the stored value and transaction information are stored in each The data storage space of each tag is protected by a set of keys. The attribute of the tag is that the key must be sent to the card for verification before the data can be accessed in the transaction. This limitation makes it difficult for systems using this type of technology to be extended to open environments, such as the Internet for e-commerce and/or cellular communication networks for mobile commerce, because the transmission of keys in public domain networks poses security aspects of the problem.

Therefore, there is a need for a device in various devices, especially portable devices, that can be used as an electronic purchaser and/or electronic seller to pass payment servers and/or point-of-sale transaction processing servers on open networks. Trade without compromising security.

Contents of the invention

The purpose of this section is to outline some aspects of embodiments of the invention and briefly describe some preferred embodiments. The short descriptions or omissions in this section are the same as those in the title and abstract, which can avoid unclear purpose of this section, title and abstract, and these short descriptions or omissions are not intended to limit the protection scope of the present invention.

In general, the present invention relates to providing a device, in particular a portable device, with a means that can be used as an electronic purchaser (such as an electronic wallet (e-purse)) and/or an electronic mobile seller (such as a mobile point of sale), Transactions can be conducted over an open network through payment servers and point-of-sale transaction processing servers without compromising security. According to one aspect of the present invention, a portable device (eg, cellular phone, personal digital assistant (PDA), etc.) can be loaded with an electronic wallet manager. The electronic wallet manager can be configured to manage various transactions and be used as a means of accessing the emulator therein. The transaction may be conducted over a public domain network and/or a cellular communication network.

According to another aspect of the present invention, a three-layer security model is proposed, based on which the present invention will operate. The three-layer security model includes a physical security layer, an electronic wallet security layer, and a card manager security layer, and the three security layers are respectively concentrically encapsulated with each other. The e-wallet is personalized with a personalized security key (which can be symmetric or asymmetric) in the three-tiered security model, and secure transactions are executed with the payment server. In a specific embodiment, key data required for personalizing the e-wallet includes one or more operational keys (such as loading or top-up keys and purchase keys), preset personal identification numbers ( PINs, PersonalIdentificationNumbers), administrative keys (such as unblocking PIN keys and reloading PIN keys), and passwords (such as those provided by service providers such as Mifare). During the transaction, the security key is used to establish a secure connection between the embedded electronic wallet and the back-end server in the security identification module (SAM, Security Authentication Module) or financial institutions (such as banks, credit unions, credit clarification offices, etc.). aisle.

According to another aspect of the present invention, the portable device installed or pre-configured with the service manager is configured to receive information from one or more servers (such as a service provider) via a cellular communication network (such as a General Packet Radio Service (GPRS) network) ) securely download and install various business/application components (such as MIDlets applications and applets applications). Depending on the specific implementation, some or all of the MIDlets applications (eg, point-of-sale manager, e-wallet manager, etc.) are installed on the baseband (eg, memory space associated with microprocessor circuitry) of the portable device. The Applet application program is installed on a secure element (such as a smart card) in a portable device, and is further configured with a personalized security key (such as a converted key, a personal identification number) and other personalized information.

In addition, the aforementioned service manager can also be pre-installed on a computer (such as a notebook computer, a desktop personal computer), or implemented as an online application (such as a web-based application software). Together with a contactless reader (such as a Proximity Coupling Device complying with the ISO 14443 standard, or a Proximity Coupling Device according to the ISO 15693 standard), the aforementioned installation and personalization process can be performed over a wired and/or wireless network ( such as the Internet).

According to another aspect of the invention, the portable device is configured as an electronic mobile vending machine (eg, mobile point of sale) for electronic commerce and/or mobile commerce. E-commerce and mobile business operations (including offline payment, online payment, real-time recharge, virtual recharge, batch transaction upload, and various balance and transaction inquiries) can be used to install the point-of-sale manager and point-of-sale security identification module (SAM) portable device implementation.

Offline payments allow a portable device to collect e-tokens from another e-token-enabled device (such as a single-function card, Mifare, e-wallet-enabled portable device, etc.) without access to a backend point-of-sale server. Real-time top-up allows a portable device to replenish e-tokens in real time from a financial institution to another e-token-enabled device. Virtual top-up allows a portable device to replenish e-tokens with another device that supports e-tokens and is set to receive e-tokens only from a funding account set up by a sponsor or donor. Bulk transaction upload allows multiple transactions accumulated at the point of sale to be transferred to the backend point of sale transaction processing server for settlement. Transaction and balance history queries can be supported by a MIDlet application (eg, a GUI with built-in query functionality). The security of all the aforementioned applications complies with the industry standards for electronic commerce and/or mobile commerce.

The present invention can be implemented in a variety of ways including methods, systems and devices. In a specific embodiment, the present invention is a method for enabling a portable device to perform mobile commerce transactions, the method at least comprising the following steps: installing a mobile commerce transaction module on a secure element connected to the baseband of the mobile device; installed mobile commerce transaction module; according to the personalized information in the personalized mobile commerce transaction module, the mobile commerce transaction manager module is downloaded onto the baseband of the portable device; and the service manager module is pre-installed and It is configured to assist in the installation, personalization and download steps. The personalization step further includes: accessing the personalization server at the service provider to establish a secure channel; sending a personalization request to the personalization server; receiving one or more personalization information from the personalization server a network message of a data set; and sending the personalized data set to the e-commerce and mobile commerce transaction module.

According to another embodiment, the present invention is a system for conducting mobile commerce transactions, said system consisting at least of the following: a portable device configured as a mobile point-of-sale (POS) comprising an installed and a personalized point-of-sale manager and secure point-of-sale identification module (SAM); and an electronic token enabled device, wherein the electronic token is configured to be read by a contactless interface of said portable device, wherein the contactless interface It is a standard-compliant ultra-short distance coupling device. The system also includes a point-of-sale transaction processing server accessing the point-of-sale manager through a secure channel over a cellular communication network.

According to another embodiment, the present invention is a method of performing a mobile commerce transaction using a portable device, said method comprising at least the steps of: receiving from said device holder who wishes to conduct a purchase transaction by reading a device that supports electronic tokens retrieve the electronic token there; determine whether the retrieved electronic token is valid using a point-of-sale security identification module (POS SAM) installed on the portable device; if the electronic token is determined to be valid and valid sufficient balance to cover the purchase amount, the electronic token is deducted to record the purchase transaction in the point-of-sale security identification module, otherwise the purchase transaction is rejected. The method also includes uploading transactions accumulated in the point-of-sale security identification module to a point-of-sale transaction processing server via a cellular communication network or a public domain network, and receiving, via a point-of-sale manager in the portable device, from a financial institution or The linked account funds the electronic token enabled device.

It is therefore an object of the present invention to provide means which can be embedded in a device, in particular a portable device, which can be used as an electronic purchaser and/or an electronic mobile seller, to , executing a transaction via a payment server and/or a point-of-sale transaction processing server on an open network.

Other objectives, features and beneficial effects of the present invention will become apparent by looking at the following embodiments described in detail in conjunction with the accompanying drawings.

Description of drawings

The present invention will be easily understood through the following detailed description in conjunction with the accompanying drawings, wherein the same reference numerals represent the same structural components, in the figure:

Figure 1A shows a three-layer security model, according to a related specific embodiment, the present invention will operate based on the three-layer security model;

Figure 1B shows the data flow among the three entity components consistent with the aforementioned three-layer security model;

Fig. 2 shows a schematic diagram of the architecture when the portable device is used as an electronic wallet to perform e-commerce and mobile commerce according to a specific embodiment of the present invention;

FIG. 3A is a structural diagram showing the interaction of relevant modules to complete the personalized processing of the aforementioned electronic wallet by the authorized person;

FIG. 3B shows a structural diagram of the interaction of relevant modules to complete the processing of the aforementioned e-wallet personalized by its user;

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

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

Fig. 4C is a schematic diagram showing the interaction of relevant modules to complete 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 functions of e-commerce and mobile commerce on a cellular communication network (such as a GPRS network);

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

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

FIG. 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 be used as a mobile point of sale to perform transaction upload operations on the network;

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

FIG. 6D is a flowchart illustrating a process schematic of performing mobile commerce using a portable device used as a mobile point of sale and a multi-function card device supporting electronic tokens; and

Fig. 7 depicts a schematic structural diagram of a portable device used for electronic ticketing applications.

detailed description

In the following introduction, numerous specific details are set forth in order to provide a comprehensive understanding of the present invention. These specific details may be omitted in actual implementations of the invention. The descriptions and illustrations in this section are the means used by those skilled in the art to effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, structures and circuits have not been described in detail because these elements are well understood by the public and in order to avoid unnecessarily obscuring the present invention.

When "a specific embodiment" is mentioned in this section, it means that the specific technical features, configurations or characteristics described in connection with this specific embodiment can be included in at least one embodiment of the present invention. The phrase "in a specific embodiment" that appears in multiple places in the description may refer to multiple different specific embodiments, and a single specific embodiment or alternative implementation is not mutually exclusive with other embodiments. In addition, for program diagrams, flowcharts, or functional diagrams representing single or multiple specific embodiments, the order of the blocks in the diagram does not necessarily represent any specific order in the invention, nor should the order make any contribution to the invention. limited.

In discussing specific embodiments of the present invention, reference will be made to Figures 1A-7. However, as known to those skilled in the art, the detailed description in this section in conjunction with the illustrations is only to further illustrate the present invention, and the present invention is not limited to the specific embodiments described.

Fig. 1A shows a three-layer security model 100, according to a related specific embodiment, the present invention will operate based on the three-layer security model. The three-layer security model 100 includes a physical security layer 102 , an electronic wallet security layer 104 and a card manager security layer 106 .

The physical security layer 102 refers to the security mechanism provided by the single-function card to protect the data stored on the card. The card can be realized by hardware, or by software simulation running on a certain medium. Data on a single-function card is protected by a set of access keys. The key is embedded in the card when the card is issued. In order to prevent mutual confusion with the content in the present invention, the process of embedding the key into the card will be omitted. When accessing said data, the associated key is read by a contactless reader for identification.

The e-wallet security layer 104 defines a set of protocols that support the execution of micropayment transactions in wired and wireless environments. For electronic purses (e-purse) stored on smart cards, a set of keys (which may be symmetric or asymmetric keys) is personalized and deposited into the e-purse when the e-purse is issued. During the transaction, the electronic wallet uses a set of keys to perform data encryption and message identification code (MAC) operation respectively, so as to establish and protect the safe channel connecting the electronic wallet with the security identification module or back-end server. For a single-function card, the electronic wallet security layer 104 will act as a gatekeeper to protect the actual operations performed on the single-function card. During the personalization process, the access key (or its converted form) of the single-function card will be personalized and stored in the electronic wallet together with the electronic wallet transaction key.

The card manager security layer 106 refers to the general security framework of the pre-installed operating system in the smart card, which provides a platform for personal identification number management and card personalization security channel (security domain). In one embodiment, the platform can be used to personalize the e-wallet via the card manager. An example of the card manager security layer 106 is a cross-industry membership organization known as the Global Platform (GP) established to advance standards for the development of smart cards. GP brings together the interests of smart card issuers, manufacturers, industry groups, public entities and technology companies to develop design requirements and technical standards for multipurpose smart cards. In a specific embodiment, Global Platform Security (GPsecurity) is used to personalize the smart card. Therefore, both the Wallet Key and the Card Access Key are personalized and stored in the destination tag.

Figure 1B shows the data flow consistent with the three-layer security model between three entities, including a land-based security identification module or a network electronic wallet server 112, which acts as a gatekeeper An electronic wallet manager 114, and a single function tab 116. According to a specific embodiment of the present invention, the communication between the onshore security identification module or the network electronic wallet server 112 and the electronic wallet manager 114 will be carried out by a command (such as a network message), and the Communication between the electronic wallet manager 114 and the single-function tag 116 takes place via another type of command, such as an application protocol data unit (APDU), wherein the electronic wallet manager 114 acts as a gatekeeper to Ensure that only secure and authorized data exchanges are permitted.

As shown in Figure 1A, the physical security layer is implemented in a simulator. The emulator here means that one hardware device or program pretends to be another special hardware device or program, and other components wish to interact with the virtualized device or program. The electronic wallet security layer is implemented between one or more applet programs providing electronic wallet functions and the payment server. The card manager security layer (such as the global platform security layer) implements and updates the security key through the card manager to establish a suitable channel for the interaction between the server and the applet program, wherein the electronic wallet applet program plays the role of The gatekeeper acts to manage or control data exchange.

According to a specific embodiment, the smart card is preloaded with a smart card operating system providing a security framework to control access to the smart card (for example, installing external applications in the smart card). In order to manage the life cycle of the external application, a card manager module is provided through the smart card security framework. For example, Java-based SmartMX smart cards come pre-loaded with the JCOP 4.1 operating system. The Global Platform 2.1 (Global Platform 2.1) installed in the SmartMX smart card can execute the function of the card manager.

Referring to FIG. 2 , FIG. 2 shows a schematic diagram 200 of an architecture when a portable device is used as an electronic wallet to perform e-commerce and mobile commerce according to a specific embodiment of the present invention. The diagram 200 includes a cellular phone 202 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. The SMX module is pre-loaded with a Mifare emulator 208 (ie, a single-function card) for storing values. The cellular phone is equipped with a contactless interface (eg ISO 14443 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. According to a specific embodiment, the electronic wallet is built on the global platform (GP) and implemented as an applet program in the SMX module. The electronic wallet is configured to be able to access the data structure of the Mifare simulator through a password obtained after appropriate conversion from the access key.

The mobile phone 202 provides an electronic wallet manager MIDlet program 204 . In mobile commerce, the MIDlet program 204 acts as a communication agent between the electronic wallet applet program 206 and one or more payment networks and servers 210 to facilitate transactions between parties. The MIDlet program referred to here is a software component suitable for running on a portable device. The Wallet Manager MIDlet program 204 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 204 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 204 is also configured to provide management functions, such as changing a personal identification number (PIN), viewing electronic wallet balances and transaction history logs. In one example application the card issuer provides a Secure Identity Module (SAM) 212 for supporting and authenticating any transaction between the card and the corresponding server (ie the payment server). As shown in Figure 2, an Application Protocol Data Module (APDU) command is created by a server 210 that has access to a Secure Identity Module (SAM) 212, which is the communication module between the reader and the card. The structure of the APDU module is formulated according to the ISO 7816 standard. Typically, APDU commands are embedded in network messages and sent to the server 210 or the wallet applet 206 for processing.

In electronic commerce, a Web agent 214 running on a computer (not shown) is responsible for interacting with a contactless reader (eg an ISO 14443 RFID reader) and the web server 210 . In actual operation, the agent 214 sends an APDU command to the electronic wallet applet program 206 running on the portable phone 202 through the contactless reader 216, or sends an APDU command from the electronic wallet applet program 206 through the same channel Receive the corresponding reply. On the other hand, the proxy 214 can generate network requests (eg, HTTP) and receive corresponding responses from the payment server 210 .

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

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

As mentioned earlier, the Wallet Manager is built on the global platform to provide the security mechanisms needed to personalize the Wallet applet. In actual operation, the security domain is used to establish a secure channel connecting the personalized 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 (eg, 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 Figure 3A, the authorizer starts the personalization process 304, to personalize the electronic wallet applet program of the user, and described personalization process 304 is in existing (existing) new electronic wallet security identification module 306 and existing security identification 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 (such as electronic wallet applets) during the card personalization process; and (2) creates 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 , the e-wallet user wishes to initiate a personalization process to personalize the e-wallet applet over the air (eg, via 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 has a device on it which, if pressed, activates the personalization process. In another approach, a "not personalized" status prompt 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 a 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 (3) DES keys. For example:

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 can change the values of their respective key sets prior to the personalization process (or during the initial stages of the 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. The second set of data can likewise be personalized through the same channel. However, if the 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 the 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 ). Establish. In step 362, a set of converted keys is generated using the existing security identification module and tag ID. The converted key is stored in the simulator for subsequent data access authentication. In 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, including 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 raising 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.

Assume that the user gets a portable device (for example, a portable phone) on which an electronic wallet is installed. The user wishes to fund the e-wallet from the bank's account. At step 402, the user enters a set of personal identification numbers (PINs). Assuming that the PIN is valid, the electronic wallet manager in the portable device is activated and initiates a request (also referred to as an Over-the-Air (OTA) top-up request) in step 404 . 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 APDU commands from the reply and forwards the commands to the Wallet applet program. The e-wallet applet verifies the command in step 420, and if the command is verified as authorized, sends the command to the emulator in step 420 and updates the transaction log. In step 422, a ticket is generated to formulate a reply (for example, a reply in APDU format) sent to the payment server. In step 424, the payment server updates and sends success status information to the MIDlet program after receiving the reply, and saves the APDU reply for later checking.

As shown in FIG. 4C , the payment network and server 440 receives the reply from the electronic wallet manager MIDlet program 434 and verifies with the security identification module 444 that the reply is originally sent 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 checks the validity of the network reply (for example, 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 (eg, a GPRS network) is shown in FIG. 5A, according to an 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)) supporting near field communication (NFC, Near Field Communication). The baseband 524 provides an electronic platform or environment (such as a miniature version of Java (JME, JavaMicroEdition), or a mobile information device framework (MIDP, Mobile Information Device Profile)), on which the application MIDlet program 523 and server can be executed or run Manager 522 . The secure element 529 contains 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 execute 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 (eg, a MIDlet program with a GUI) needs to be activated. In a particular embodiment, the 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 (eg yellow page function) for various service providers (eg installation server, personalization server) that may provide products and/or services to registrants. The yellow pages function of the directory server 512 may include service planning information (such as service charge, start date, end date, etc.), installation, personalization and/or MIDlet program download location (such as Internet address). The installation and personalization process may be provided by two different business entities, for example, the installation process may be provided by the issuer of the secure element 529, and the personalization process may be provided by an application program holding a specific application program. Provided by the service provider that handles the key.

According to a particular embodiment, the service manager 522 is configured to connect to 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, and then personalize the application applet 527 and the available Selected emulator 528, and finally download application MIDlet program 523. The Applet program library 504 and the MIDlet program library 506 respectively provide general application applet programs and application MIDlet programs. The global platform security identification module 516 and the application program security identification module 517 are used to establish a security channel 518 for personalized operations.

FIG. 5B illustrates a second example architecture 540 that enables a portable device 530 to perform e-commerce and m-commerce over a public network 521, according to another 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 FIG. 5A. The difference is that the first architecture 500 is based on operation 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 (IEEE802.11) wireless connection, a Wi-Max (IEEE 802.16) wireless connection, and the like. In order to perform service operations on the public network 521 , an instance of the service manager 532 (that is, 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 .

FIG. 5C is a flowchart depicting a process 550 for enabling electronic commerce and m-commerce functionality on a portable device, according to an 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. In order to better understand the process 550, reference will be made to several earlier figures in the following description, especially FIGS. 5A and 5B.

An instance of service manager 522 or 532 has been downloaded or pre-installed on portable device 530 or computer 538 before process 550 begins. 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 may 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 (ie 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, while 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 be used 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 the point-of-sale security identification module applet program (such as a Java Cap file from the 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 (STOREDATA APDU)";

(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 program 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 security 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 real-time transactions 639 may be conducted between mobile point-of-sale enabled portable devices 630 and electronic token enabled devices 636 such as single function cards or e-wallet enabled mobile devices. The electronic token may represent electronic money (e-money), electronic shopping coupon (e-coupon), electronic ticket (e-ticket), electronic voucher (e-voucher) or any other form of payment token in the device .

Real-time transactions 639 can be conducted offline (ie, 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 the portable device 630 connected to the point-of-sale transaction processing server 613 through the 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 illustrates a representative architecture 640 in which a portable device 630 acts as a mobile point of sale and performs bulk uploads of transactions over a public network 521, according to an embodiment of the present invention. operation. The offline transaction records in the mobile point of sale are generally accumulated and saved in the transaction log in the security identification module 628 of the point of sale. 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 the secure channel 619 on the public network 521 . Each upload that contains one or more transactions is marked as a separate bulk upload. The data communication between the point-of-sale security identification module 628, the contactless reader 634 and the point-of-sale agent 632 is in APDU format and contains the transaction record. Network messages encapsulating APDUs (eg, HTTP) are then used for communications between the point-of-sale agent 632 and the point-of-sale transaction processing server 613 .

In a specific embodiment, a representative bulk upload process from the 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).

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, process 650 is best viewed 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 performed by the point-of-sale manager 623 in FIG. 6A) will be started. At step 652, the portable device 630 reads the e-token enabled device and retrieves the e-token (such as the tag ID of the Mifare card). The process 650 then verifies in step 654 whether the retrieved electronic token is valid. If the electronic token supporting device 636 in FIG. 6A is a single-function card (such as a Mifare), the verification process performed by the point-of-sale manager 623 includes: (i) reading the card identification (ID) of the card, The card identification is stored in an area that is not protected or only protected by a public key; (ii) sends an APDU request containing the card identification to the point of sale security identification module 628; (iii) receives one or more Transformed keys (eg, keys for transaction counts, issuer data, etc.) generated by point security identification module 628. If the received one or more converted keys are invalid, ie the retrieved electronic token is invalid, process 650 ends. Otherwise, process 650 will proceed along the "yes" branch to step 656, where it will be determined whether there is sufficient balance in the retrieved electronic tokens to cover the fees required for the current transaction. If the decision at step 656 is no, process 650 may choose to offer the holder to top up (ie load, inject or raise funds for) their electronic tokens at step 657 . If the holder chooses to "deny" the offer, process 650 ends. Otherwise, if the holder agrees to real-time recharge for the electronic token enabled device, then process 650 performs a recharge or virtual recharge operation at step 658 . Process 650 then returns to step 656. If there is sufficient coin balance in the electronic token, the process 650 in step 660 debits or debits the electronic token supporting the electronic token device 636 by the amount required to complete the purchase. In the case of said single function card, said one or more converted keys are used to authorize said 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 on a single transaction or a batch of transactions through the cellular communication network 520 or the public domain network 521 .

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, 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 can act 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 easier understanding, it is best to consider process 670 in conjunction with the previous illustrations, especially FIGS. 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 . The purchase fee is sent with the initial purchase request (eg, APDU command). 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 electronic token supporting device 636 , the result of decision step 674 is yes, and process 670 will follow the yes branch to step 676 . Responses (eg, 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, process 670 receives a debit request (eg, an APDU command) generated by 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 (ie, 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 security 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 (eg, 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 (eg, 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).

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 which 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 invention is described in sufficient detail based on the specific particularities thereof. Those skilled in the art will understand that the specific embodiments of the present invention are disclosed by way of examples only, and that a large number of changes in the arrangement and composition of parts can be made without departing from the claimed gist and scope of the present invention. Accordingly, the scope of the invention is defined by the appended claims rather than by the foregoing description of specific embodiments.

Claims (12)

1. A system for performing mobile commerce transactions and e-commerce transactions, the mobile commerce transactions are performed through a cellular network, the e-commerce transactions are performed through a data network, and the data network includes a wired Internet or a wireless Internet, the The system includes: A portable device configured as a mobile point-of-sale, including a point-of-sale manager stored in a baseband of the portable device and a point-of-sale security identification module SAM installed in a secure space of the portable device; wherein the point-of-sale security The identification module is personalized by: establishing a secure communication session with a personalization server, the personalization server configured to access the portable device to install a set of security keys and a pin after the identity of the portable device has been verified by the personalization server PIN; means capable of spending electronic tokens arranged to be read by the contactless interface of said portable device; and a transaction processing server for processing transactions via said portable device, wherein said portable device reads said electronic token-enabled means to retrieve electronic tokens into the portable device for In the case of communicating with the above-mentioned transaction processing server, it is determined whether the retrieved electronic token is valid, and when the electronic token is determined to be valid, the transaction cost in completing the transaction does not exceed the value in the electronic token that can be used. some transactions with a predetermined threshold set in the device, and said some transactions are transmitted in batches to said transaction processing server through a secure channel on said cellular network or said data network, The verification process performed by the point-of-sale manager includes: sending an APDU request containing the card identification to the point-of-sale security identification module; receiving one or more transformed keys generated by the point-of-sale security identification module, if the received one or more converted keys are invalid, that is, the retrieved electronic token is invalid; otherwise, the retrieved electronic token is considered valid. 2. The system according to claim 1, wherein the point-of-sale security identification module is configured to establish a secure channel with the device capable of using electronic tokens, so as to prompt the portable device to In the case of a transaction processing server communication, some transactions are supported and authenticated. 3. The system of claim 2, wherein the point of sale manager is a MIDlet module running in the baseband. 4. The system of claim 2, wherein the point-of-sale security identification module is an applet module running on a secure element in the portable device. 5. The system of claim 1, wherein the portable device is a mobile phone capable of using Near Field Communication (NFC). 6. The system according to claim 1, wherein the device capable of using electronic tokens is a single-function card or a multi-function card. 7. The system of claim 1, wherein the non-contact interface is a standard-compliant ultra-short-range coupling device. 8. A method of performing a mobile commerce transaction using a portable device, the method comprising: Retrieval of electronic tokens to portable devices from a device capable of using electronic tokens held by the holder wishing to make a purchase transaction; Using a point-of-sale manager and a point-of-sale secure identification module installed in said portable device, without communicating with a transaction processing server, determining whether said retrieved electronic token is valid, wherein the device supporting electronic token is a single-function card, the verification process performed by the point-of-sale manager includes: reading the card identification of said single-function card, said card identification is stored on an area that is not protected or only protected by a public key; The security identification module sends an APDU request comprising the card identification; receives one or more converted keys generated by the point-of-sale security identification module, if the received one or more converted keys are invalid, that is, the The electronic token retrieved is invalid, otherwise, the electronic token retrieved is considered valid; and if the electronic token is determined to be valid and has sufficient balance to pay for the purchase, recording the purchase transaction in the point-of-sale security identification module by deducting the electronic token; Otherwise reject said purchase transaction; One or more offline transaction records accumulated in the point-of-sale security identification module are uploaded to the transaction processing server, and the upload operation is performed for a single transaction or a batch of transactions through the cellular network. 9. The method according to claim 8, further comprising uploading the transactions accumulated in the point-of-sale security identification module to a transaction processing server via a cellular network or a public domain network. 10. The method of claim 8, further comprising injecting funds into the electronic token-enabled device through the point-of-sale manager of the portable device from a financial institution or a linked account. 11. The method of claim 10, wherein the linked account is set up and funded by a sponsor or donor. 12. The method according to claim 8, further comprising connecting to a transaction processing server for further authentication of the electronic token when the purchase cost exceeds a predefined threshold.