WO2014122451A2

WO2014122451A2 - System and method for mobile wallet data access

Info

Publication number: WO2014122451A2
Application number: PCT/GB2014/050326
Authority: WO
Inventors: Edward Neil LIVINGSTON; Aaron Concannon
Original assignee: Barclays Bank Plc
Priority date: 2013-02-05
Filing date: 2014-02-05
Publication date: 2014-08-14
Also published as: GB2510430A; GB201302039D0; WO2014122451A3

Abstract

A method and mobile device are provided for facilitating secure access to transaction data associated with an electronic wallet on the mobile device. An electronic wallet is provided on the mobile device for processing transactions, where at least one component of the electronic wallet is provided on a secure element of the mobile device. A data store is created on the mobile device for storing transaction data associated with the electronic wallet. Data identifying a unique identifier of a secure element associated with the data store is also stored in the data store. The electronic wallet determines that the unique identifier of the secure element matches the stored unique identifier before access is allowed.

Description

System and Method for Mobile Wallet Data Access

Field of the Invention

[0001] This invention relates to a mobile payment system, and more particularly to system and method for facilitating secured access to mobile electronic wallet data. Background of the Invention

[0002] Mobile payment systems are generally well known, in which portable electronic devices are configured to provide payment from an electronic wallet. Typically, these portable electronic devices are configured with hardware and software to enable a contactless communication with a merchant Point Of Sale (POS) terminal to carry out a payment transaction, for example using near field communication (NFC) technology. General examples of such mobile payment systems can be found in the Applicant's earlier applications, such as WO 2012/042262.

[0003] In such conventional systems and methods, the mobile wallet is operational when the electronic device is in an "online" state, whereby communications with a payment service issuer backend system can be established, for example to perform a payment transaction or to retrieve historical transactional data. Therefore, transactional data is typically not available when the electronic device is in an "offline" state.

[0004] Additionally, conventional mobile wallet systems typically store sensitive data in a secure element of the electronic device, such as a Universal Integrated Circuit Card (UICC) type secure element. Patent publication WO2012/091350 (SK C & C) discusses a method for securing information stored in a non-UICC type secure element over-the- air (OTA). However, access to such secure elements is often tightly controlled by the underlying operating system of the electronic device, for example via a set of functions made available through code libraries or Application Programming Interfaces (APIs). Therefore, it is difficult to configure a mobile wallet system to facilitate secured access to mobile wallet data in an "offline" state. [0005] What is desired is an improved mobile payment system and method that provides for flexible access by the mobile wallet to transactional data when the electronic device is in an offline state. It is a further object of the invention to provide a system and method that enables such offline access to mobile wallet data in a secure manner.

Statements of the Invention

[0006] In one aspect of the present invention, a method is provided for providing secure access to transaction data associated with an electronic wallet on a mobile device, the method comprising the steps of providing an electronic wallet on the mobile device for processing transactions, wherein at least one component of the electronic wallet is provided on a secure element of the mobile device, the secure element associated with a unique identifier; creating a data store on the mobile device for storing transaction data associated with the electronic wallet; storing, in the data store, data identifying a unique identifier of a secure element associated with the data store; and determining that the unique identifier of the secure element matches the stored unique identifier before enabling access to the electronic wallet.

[0007] In another aspect, there is provided a method of providing secure access to an application module on a mobile device having a secure element associated with a unique identifier, the method comprising storing, on the mobile device, data identifying the unique identifier of a secure element associated with the mobile device, and determining that the unique identifier of the secure element matches the stored unique identifier before access to the application module is allowed.

[0008] In yet another aspect, there is provided a mobile device arranged to carry out the above method.

[0009] In other aspects, there are provided computer programs arranged to carry out the above methods when executed by a suitable mobile device. Brief Description of the Drawings

[0010] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.

Figure 1 is a block diagram showing the main components of a mobile payment system according to an embodiment of the present invention.

Figure 2 is a block diagram showing the main elements of a mobile device shown in Figure 1.

Figure 3 is a flow diagram illustrating the main processing steps performed by the mobile device during initial set up of a mobile wallet.

Figure 4 is a flow diagram illustrating the main processing steps performed by the mobile device to authenticate the device before enabling access to mobile wallet functionality.

Figure 5, which comprises Figures 5a and 5b, illustrates exemplary display screens displayed by the mobile device to the user during the processes illustrated in Figures 3 and 4.

Detailed Description of Embodiments of the Invention

Mobile Wallet System

[0011] Referring to Figure 1, there is illustrated a block diagram of a mobile wallet system 1 according to an exemplary embodiment of the present invention, for implementing an electronic wallet 3 on a mobile handset 5, hereinafter referred to as a mobile wallet, with secured access to transactional data. Generally, the mobile wallet system 1 enables payment transactions to be effected between a financial institution 7 associated with a user's mobile wallet 3 and a financial institution 9 associated with a merchant (retailer) system, such as a point of sale (POS) terminal 11, for the purchase of goods or services provided by the merchant, via a backend system 13 of a payment service issuer associated with the mobile wallet 3. Such payment service issuer systems for processing payment transactions via a payment scheme network 15 are of a type that are known to the person skilled in the art of mobile wallet systems and need not be described further. It is appreciated that the user's financial institution 7 and the merchant's financial institution 9 may be the same financial institution.

[0012] The mobile wallet 3 is provided by a payment service issuer system 13, such as an ID card provider, credit card issuer, bank or other financial institution, which is responsible for authorizing and settling the payment of funds for service or products purchased by the user of the mobile handset 5. The mobile wallet 3 can be downloaded as an application software module from the payment service issuer system 13 and launched for execution by the mobile device 5. It is appreciated that the payment service issuer system 13 may be a component of the user's financial institution 7 or the merchant's financial institution 9.

[0013] The mobile handset 5 can be any suitable mobile device such as a cellular device, a smartphone, etc. that includes software and/or hardware components to communicate with other mobile devices over a cellular network and to communicate wirelessly with the payment service issuer system 13. The mobile handset 5 includes a network interface 17 and communicates electronically with the payment service issuer system 13 via a data network 19. The data network 19 may be any suitable data communication network such as a wireless network, a local- or wide-area network including a corporate intranet or the Internet, using for example the TCP/IP protocol, or a cellular communication network such as GPRS, EDGE, CDMA, UMTS or 3G/4G, for example. Such communication protocols are of a type that are known to a person skilled in the art of data networks and need not be described further.

[0014] Merchants (retailers) will be able to participate in the mobile wallet system 1 by ensuring related infrastructure of the associated merchant systems, such as the POS terminal 11 equipment (which may have many forms such as tablets, POS integrated with payment terminals etc), payment modules of the merchant websites, payment processors, acquirers, and other hardware and software related equipment, is supported by the mobile wallet 3 and payment service issuer system 13. The mobile wallet 3 may include specific functional support for a number of participating merchant systems of the mobile wallet system 1. [0015] Optionally, the mobile device 5 and the electronic POS terminal 11 communicate with one another via a contactless communication link 21, using respective contactless link interfaces 23. The contactless communication link 21 may be for example a near field communication (NFC) link, an infra-red and/or optical link (eg. for bar code scanning), an ultra-sonic link, a radio frequency (eg. RFID) link, a wireless link such as Bluetooth or Wi-Fi based on the IEEE 802.11 standards, or any other communication link that does not require direct physical contact.

[0016] As shown in Figure 1, the mobile device 5 in this embodiment includes a secure element 25 storing wallet application secure data 27 including for example, payment account data identifying one or more mobile payment accounts that have been set up for the mobile wallet 3. The secure element 25 is, in this embodiment, a Universal Integrated Circuit Card (UICC) type secure element having a unique identifier 29, such as an Integrated Circuit Card ID (ICC-ID) stored in the secure element 25. It is appreciated that other types of secure elements are possible, such as an embedded secure element chip having a unique serial number, as is known in the art. Other forms of mobile handset software and/or hardware can be implemented to provide built-in secure electronic wallet functionality for accessing the secure element 25, including encryption and decryption of the electronic wallet application secure data 27, as necessary.

[0017] The mobile device 3 also includes a wallet application module 31 storing computer-implementable processing instructions used to control the operation of the mobile device 3, for example to i) process a transaction with a merchant via the electronic POS terminal 5 to effectively transfer funds from the mobile wallet 3 or a payment account linked with the mobile wallet 3 to a merchant's account, ii) create a persistent data store 33 in a memory 35 of the mobile device 5 to store, for example, data associated with processed transactions, and iii) to retrieve historical transaction data from the persistent data store 33 for display by the mobile wallet 3. The wallet application module 31 can be implemented as one or more software components of an operating system running on the mobile device 5 or implemented as one or more separate software applications installed on the mobile device 5. Such software applications may be configured to run as background applications on the mobile device 5 that monitor receipt of messages or events and activate upon receipt of appropriate messages or events so as to carry out the above operations. Alternatively, the user can launch the software applications. The wallet application module 31 can instead or additionally be launched via a web browser running on the mobile device 5 and/or executed as a component of a web-based interface. As yet a further alternative, the wallet application module 31 can be stored in the secure element 25, and loaded into a virtual machine of the mobile device 5 to provide the functionality of the present embodiment.

[0018] In this way, the mobile wallet 3 is configured to facilitate creation of a persistent data store 33 on the mobile device 5 for storing historical transaction data that is advantageously available to the user even when the mobile device 5 is in an "offline" state, where electronic communication with the payment service issuer system 13 is not available, for example due to a lack of cellular data network coverage. Additionally and as will be described in further detail below, in order to provide for data integrity, the mobile wallet 3 is configured to perform a security check upon launch or startup of the wallet application module 31 to verify that that secure element 25 has not changed since creation of the persistent data store 33.

Mobile Device

[0019] Figure 2 shows in more detail the elements of the mobile device 5 in the system 1 of Figure 1. As shown in Figure 2, the mobile device 5 includes operating system and hardware 41 having a controller 43 for controlling the mobile device 5, and a user interface 45 arranged to process inputs from a keypad 47 and to control output on a display 49. The keypad 47 and display 49 can be provided as separate hardware entities of the mobile device 5, or alternatively, as an integrated entity such as a touch sensitive display screen user interface. The mobile device 5 can also include components included in commonly known mobile handsets, such as a microphone, an earpiece speaker, a camera, and/or a GPS sensors/receiver etc., which are not shown. A working memory 51 is provided for use by the device operating system and hardware units 41.

[0020] Software and data are transferred via the data network interface 17 in the form of signals 53, which can be electronic, electromagnetic, optical, or other signals capable of being received by the data network interface 17 via a communication path 55 that carries the signals and can be implemented using wire or cable, fiber optics, a physical phone line, a wireless link, a radio frequency link, or any other suitable communication channel, including any combination of suitable communication channels.

[0021] As mentioned above, the mobile device 5 includes a secure element 25. The mobile device 5 is operable to receive the wallet application secure data 6, such as associated payment account details, via the data network interface 17 and/or via a cellular telephone network interface 18, and to store the received wallet application secure data 6 in the secure element 25. The mobile device 3 is also operable to store the received wallet application secure data 6 in the secure memory 4. The mobile device 3 is also operable to receive transaction authorization request messages from and send authorization messages to the merchant's POS terminal 5 via a contactless communications link interface 37 and the contactless communications link 9. Communication between a POS terminal 5 and the mobile device 3 can involve transmission of data in a single direction from the mobile device 3 to the POS terminal 5, depending on an implemented protocol (such as the protocols used by the DISCOVER ZIP™, MasterCard PayPass™, Visa Paywave™ and AMEX ExpressPay™ cashless payment systems).

[0022] The mobile device 5 includes a wallet application module 31 as mentioned above, which stores processing instructions used to control the operation of the mobile device 5 to perform the various mobile payment account processes, as will be described in detail below. In this embodiment, the wallet application module 31 comprises a mobile service provider wallet application module 31a, which can be provided by a mobile service provider associated with the mobile device 5 such as a Mobile Network Operator (MNO) or device manufacturer, and a payment service issuer wallet application module 31b, which can be provided by the payment service issuer such as an electronic wallet issuer or a financial institution. The mobile service provider wallet application module 31a or the payment service issuer wallet application module 31b can include a transaction authorization sub-module (not shown) which stores processing instructions used to control the operation of the controller 43 to carry out and authorize a transaction in response to user input from the keypad 47 and transaction authorization request messages received from the merchant's POS terminal 11 via the contactless communications link interface 23. The payment service issuer wallet application module 31b also stores a plurality of wallet display screens 57 which may be output on display 49 of the user interface 45 to facilitate user interaction with the mobile wallet 3. The wallet application module 31 may also store one or more non-payment application modules (not shown) including processing instructions used to control the operation of the mobile device 5 to perform other non-payment related processes.

[0023] As those skilled in the art will appreciate, although the above discussed functionality is described as being provided by separate service provider wallet application module 31a and issuer wallet application module 31b on the mobile device 3, the mobile wallet 3 functionality may instead be provided by a single module. It is also appreciated that the wallet application module 31 may be provided as one or more hardware and/or software components of the mobile device 5.

[0024] The mobile device 5 also includes in the non-volatile memory 35. As will be described in further detail below, the issuer wallet application module 31b is configured to create a wallet persistent data store 33 in the memory 35 of the mobile device, upon initial setup of the issuer wallet application module 31. The issuer wallet application module 31b is also configured to store data 34 recording the unique identifier 29 of the secure element 25 in the persistent data store 33 at the time the persistent data store 33 is created. Preferably, the secure element identifier 34 is stored in an encoded or scrambled format in the persistent data store 33. In this way, on subsequent launching of the issuer wallet application module 31b, a security check can be performed to ensure that the secure element 25 has not changed, and thus providing an extra layer of security and assurance that the mobile wallet 3 is in the possession of and being used by the legitimate owner.

[0025] Also schematically illustrated in the exemplary embodiment of Figure 2 are a plurality of security domains which can be implemented in the secure element 25 of the mobile device 5. The secure element 25 is advantageously implemented to be compliant with one or more specifications of a standard infrastructure in order to facilitate communication of data and messages between the mobile device 5 (and the secure element 25) and other entities in the mobile payment system 1. For example, and in accordance with a preferred embodiment, the secure element 4 is compliant with the known GlobalPlatform Card Specifications (for example the "GlobalPlatform Card Specification 2.2", March 2006), and accordingly includes a plurality of security domains for facilitating control of the management of and accessibility to executable operations and sensitive data associated with specific areas of the secure element 4 by the various entities in the mobile payment system 1. The GlobalPlatform Card Specifications (for example the "GlobalPlatform Card Specification 2.2", March 2006) define a hierarchical arrangement of security domains, each defining functionality and data that can be accessed by a respective associated entity, for example, cryptographic keys or certificates, that can be used to support secure channel protocol operations between the mobile device 5 and the entity or entities associated with that particular security domain, and/or to authorize secure element 25 content management functions.

[0026] As shown in the exemplary embodiment of Figure 2, a wallet security domain 61 associated with one or more payment account issuers and other service providers. In this embodiment, the wallet security domain 61 includes a service provider security domain 63 associated with a particular mobile network operator, an issuer security domain 65 associated with the payment service issuer, a Controlling Authority (CA) security domain 67 associated with a controlling authority (not shown) in the mobile payment system 1, and a Supplementary Security Domain (SSD) 69 associated with an intermediate security domain (not shown) to manage card content and perform cryptographic services for confidentiality. The wallet security domain 61 in this exemplary embodiment includes the securely stored wallet application secure data 37 for use by the wallet application module 31. The wallet security domain 61 can also include one or more optional other service provider security domains (not shown). The issuer security domain 65 includes one or more payment applet instances 71 which enable the transaction processing functionality using an associated mobile payment account.

[0027] The service provider security domain 63 also include a Proximity Payment System Environment (PPSE) module 73, defining application functionality associated with transaction processing functionality and, in particular, for handling communications with a contactless reader of the POS terminal 11. The PPSE module 73 facilitates an additional application layer level of control of the transaction processing functionality between a respective one of the transaction applet instances 71 and the contactless communication link interface 23. The PPSE module 73 is a program module inside the secure element 25 but is generally provided in a security domain associated with and controlled by the owner of the secure element 25 and not with a specific payment service issuer, thus providing for segregation that allows for privacy among issuers and mobile network operators.

[0028] Each security domain is associated with one or more respective entities in the mobile payment system 1 depending on the particular business model that is implemented by the mobile payment system 1. The specific implementation details of the various security domains for compliance with the GlobalPlatform Card Specifications are beyond the scope of this application and will be appreciated by the skilled reader. The mobile device 5 can also include one or more other third party application modules (not shown) stored in the secure element 25. The secure element 25 also stores a Subscriber Identity Module (SIM) module 75, which is an application to manage and hold the mobile network operator's functionality and secure information, such as a network key 77 and GSM (Global Systems for Mobile Communications) PIN (Personal Identification Number) 79.

Secure Offline Data Access

[0029] A brief description has been given above of the components forming part of the mobile payment system 1 of the exemplary embodiment. A more detailed description of the operation of these components in this embodiment will now be given for an example computer-implemented process of providing secured access to transaction data stored by the mobile wallet 3 on the mobile device 5, with reference to the flow diagrams of Figures 3 and 4.

[0030] As shown in Figure 3, the process begins with the mobile wallet 3 receiving user input to launch the issuer wallet application module 31b stored on the mobile device 5, this being the first time that the issuer wallet application module 31b is launched for execution since provision and installation on the mobile device 5. At step S3-1, creates a persistent data store 33 in the non-volatile memory 35 of the mobile device 5. It will be appreciated that the persistent data store 33 can be any form of data structure in the memory 35 suitable for storing data associated with transactions processed by the mobile wallet 3, such as details of the transaction history. The issuer wallet application module 31b can call one or more functions provided by libraries or APIs for the operating system and hardware 41 to create the persistent data store 33.

[0031] Optionally, at step S3-3, the issuer wallet application module 31b can be configured to handle an error or fault that may occur during the creation of the persistent data store 33 at step S3-1. If the issuer wallet application module 31b determines or is notified at step S3-3 that the persistent data store 33 has not been set up correctly, then at step S3-5, the issuer wallet application module 31b can raise and handle an unexpected error, for example by displaying an appropriate error display screen, before exiting the application. In such a case, the issuer wallet application module 31b may be configured to restart the initial set up process on subsequent launch of the application so that a new replacement persistent data store 33 is created.

[0032] Once the persistent data store 33 has been created and verified, at step S3-7 the issuer wallet application module 31b stores data 34 in the persistent data store 33 recording the unique identifier 29 of the secure element 25. Preferably, the issuer wallet application module 31b performs a series of sub-steps to calculate an encoded or scrambled form of the secure element 25 unique identifier 29, for example involving a cryptographic hash and the manipulation of various elements of the data.

[0033] Optionally, the issuer wallet application module 31b may then proceed to perform additional processes to complete the initial setup, such as activation of one or more payment accounts associated with the mobile wallet 3, prompting and setting up a user-defined passcode or PIN for subsequent access to the mobile wallet 3, etc. Alternatively or additionally, the issuer wallet application module 31b can prompt the user to proceed with normal operation of the mobile wallet 3, for example to complete one or more payment transactions using the mobile wallet 3, before execution of the issuer wallet application module 31b is stopped by the user or otherwise terminated.

[0034] Figure 4 illustrates the processing by the issuer wallet application module 31b on subsequent launches, after the initial set up process of Figure 3 has been completed and the persistent data store 33 has been created and stored in the non-volatile memory 35. Upon subsequent launch of the issuer wallet application module 31b, the process begins with the issuer wallet application module 31b verifying that the secure element 25 in the mobile device 5 at the time of launch is the same secure element 25 that was in the mobile device 5 when the issuer wallet application module 31b was initially launched to create the persistent data store 33. Accordingly, the issuer wallet application module 31b retrieves the stored secure element identifier 34 from the persistent data store 33 at step S4-1. Preferably, the issuer wallet application module 31b performs a corresponding sequence of sub-steps to decode or descramble the data 34 stored in the persistent data store 33 to recover the recorded secure element identifier. [0035] At step S4-3, the issuer wallet application module 31b determines the unique identifier 29 of the current secure element 25. It will be appreciated that this step can be handled via a call to the SIM module 75 directly, or indirectly via the mobile device operating system 41. At step S4-5, the issuer wallet application module 31b compares the recorded secure element identifier 34 from the persistent data store 33 with the retrieved unique identifier 29 of the secure element 25 to determine if the identifiers match. If the issuer wallet application module 31b determines that the identifiers do not match, then at step S4-7, an error message display screen is displayed to the user before the application is terminated. An example error message display screen 57-1 is illustrated in Figure 5a. Preferably, the issuer wallet application module 31b is further configured to delete the persistent data store 33 upon detection that the secure element 25 has been changed, or to store an indication that a new replacement persistent data store 33 is to be created on subsequent launch of the application. In this way, data integrity is protected.

[0036] On the other hand, if the issuer wallet application module 31b determines at step S4-5 that the identifiers match, processing continues to step S4-9 where the issuer wallet application module 31b displays a wallet display screen prompting the user to select a mobile wallet 3 function. Optionally, the issuer wallet application module 31b may prompt for and verify the user's pre-registered passcode or PIN before access to the mobile wallet 3 functionality is allowed.

[0037] Figure 4 illustrates two exemplary mobile wallet functions utilizing the persistent data store 33 in the non-volatile memory 35 of the mobile device 5. At step S4-11, the issuer wallet application module 31b receives a request for a new payment transaction. It is appreciated that the request can take one of many different known forms, such as a user input command to initiate a payment process with a payment account associated with the mobile wallet 3, a signal received from the merchant POS terminal 11 via the PPSE module 73, data representing a payment request from a checkout webpage of an online merchant, etc. In response to receiving the request, the issuer wallet application module 31b processes the payment transaction using a payment account associated with the mobile wallet 3, as will be apparent to those skilled in the art. Once the payment transaction is completed, the issuer wallet application module 31b stores a record of the payment transaction as historical transaction data in the persistent data store 33, including details of the completed payment transaction. Processing can then return to step S4-9 where the issuer wallet application module 31b prompts the user for a further command.

[0038] At step 4-17, the issuer wallet application module 31b receives a user command to request for historical transaction data, such as details of a prior completed payment transaction made from the mobile wallet 3. In response, the issuer wallet application module 31b retrieves the requested data from the persistent data store 33 at step S4-19 and displays the retrieved data as a wallet display screen at step S4-21. An example historical transaction data display screen 57-2 is illustrated in Figure 5b.

[0039] Optionally, the issuer wallet application module 31b can determine if network connectivity is available to the payment service issuer system 13 and to retrieve the requested data from the persistent data store 33 when network connectivity is not available and the mobile device is in an "offline" state. Processing can then return to step S4-9 where the issuer wallet application module 31b prompts the user for a further command.

[0040] In this way, the issuer wallet application module 31b does not require a data connection to the payment service issuer system 13 to process the request for historical transaction data. Moreover, access to the stored data is protected by the security check initially performed every time the wallet application is launched.

Alternative Embodiments

[0041] It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention. [0042] For example, in the embodiments described above, the mobile device includes a communication interface for facilitating communications over a respective type of contactless communication link. As an alternative, the mobile device may include a plurality of communication interfaces for enabling the plurality of transaction applets to carry out contactless communications over a plurality of respective types of contactless communication links. In this way, the mobile device would be capable of conducting contactless transactions over a combination of contactless communication links such as near field communication (NFC), infra-red and/or optical (eg. for bar code scanning), ultra-sonic, radio frequency (eg. FID), wireless such as Bluetooth or Wi-Fi based on the IEEE 802.11 standards, and any other communication link that does not require direct physical contact.

[0043] As a further alternative, the mobile device may be additionally or alternatively configured for conducting mobile transaction operations over any other form of communication link that requires a contact and/or coupling of communication interfaces. In this case, the mobile device may include a plurality of transaction modules operable to process mobile transaction operations with a respective transaction account over a communication link via an associated communication interface of the mobile device. Preferably but not essentially, at least one of the transaction modules is configured for contactless transaction operations over at least one type of contactless communication link.

[0044] In the embodiment described above, the merchant system is a POS terminal for effecting contactless payment transactions with the mobile wallet. It will be appreciated there are many other alternative ways in which associated data for a payment transaction can be communicated between the mobile wallet 3 and a merchant system 7 via the payment service provider 11 in order to complete a payment transaction. For example, the merchant system can instead be a web-based online merchant interface for the sale of goods or services over the Internet.

[0045] In the embodiments described above, the exemplary mobile device as illustrated in Figure 2 is based on a type of cellular device or smartphone that includes software and/or hardware components to communicate with other mobile devices over a cellular network and to communicate wirelessly with the payment service issuer system 13. It will be appreciated that the present invention can be applied to alternative forms of electronic mobile devices, such as portable USB flash memory devices of the type described in the Applicant's earlier applications GB1219514.5, GB1219515.2 and 1220776.7.

[0046] In particular, the mobile device can be a secure and self-contained device with a USB serial communication module for connecting the device to a USB interface of a host computer. The mobile device can include an on-board cellular data modem for secure network access to services provided by the backend system. The USB serial communication module provides a link between custom browser software and security and network stacks on the mobile device, in order to translate and transmit HTTP/HTTPS requests from the custom browser running on the electronic device via the host computer over the serial USB interfaces and to return the responses back to the browser. The mobile device also includes circuitry and application software/logic to faciliate contactless payment transactions. The application software is executed from the mobile device when the device is connected to the host computer and configures the mobile device to initiate a payment transaction by receiving payment token data via the contactless interface and transmitting the payment token data to the remote system via the mobile network interface. In this alternative embodiment, the mobile device is also adapted to store data identifying the unique identifier of a secure element such as a SIM module associated with the mobile device, and to determine that the unique identifier of the secure element matches the stored unique identifier before access to the application modules, for example the custom browser, is allowed.

[0047] In the embodiments described above, the mobile device stores a plurality of application modules (also referred to as computer programs or software) in memory, which when executed, enable the mobile device to implement embodiments of the present invention as discussed herein. As those skilled in the art will appreciate, the software may be stored in a computer program product and loaded into the mobile device using any known instrument, such as removable storage disk or drive, hard disk drive, or communication interface, to provide some examples.

[0048] In the embodiment described above, a passcode or personal identification number (PIN) is optionally provided for an extra layer of user authentication before access to the wallet application is allowed. It will be appreciated that the passcode or PIN can take any known form, such as an alphanumeric passcode or a numeric passcode of varying length. Alternatively or additionally, user verification can be base on gesture based actions or facial recognition.

[0049] Alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims. In particular, it is appreciated that the various embodiments are not necessarily mutually exclusive and can be combined with one or more other embodiments to form new embodiments. For example, the above- described embodiments may be combined to form a mobile payment system having all of the described aspects thereof.

Claims

1. A computer-implemented method of providing secure access to transaction data associated with an electronic wallet on a mobile device, the method comprising: providing an electronic wallet on the mobile device for processing transactions, wherein at least one component of the electronic wallet is provided on a secure element of the mobile device, the secure element associated with a unique identifier; creating a data store on the mobile device for storing transaction data associated with the electronic wallet;

storing, in the data store, data identifying a unique identifier of a secure element associated with the data store; and

determining that the unique identifier of the secure element matches the stored unique identifier before enabling access to the electronic wallet.

2. The method of claim 1, wherein the data store is created during an initial set up process of the electronic wallet.

3. The method of claim 2, wherein the unique identifier of the secure element is determined and stored in the data store during the initial set up process.

4. The method of any preceding claim, further comprising storing the data identifying a unique identifier of a secure element in an encoded or scrambled format.

5. The method of any preceding claim, further comprising re-creating the data store when it is determined that the unique identifiers do not match.

6. The method of any preceding claim, further comprising storing details of a completed transaction in the data store.

7. The method of any preceding claim, wherein the electronic wallet comprises one or more modules comprising computer-implementable instructions for configuring the mobile device to process a transaction.

8. The method of any preceding claim, wherein the transaction is a payment transaction with a merchant terminal.

9. The method of claim 8, wherein the payment transaction is completed over a contactless communication link with the merchant terminal.

10. The method of any preceding claim, further comprising verifying a user-defined passcode before enabling access to the electronic wallet.

11. The method of any preceding claim, wherein the data store is created in a non- volatile memory of the mobile device.

12. The method of any preceding claim, wherein the secure element is a Universal Integrated Circuit Card (UlCC) secure element and the unique identifier is a UlCC ID.

13. A computer-implemented method of providing secure access to an application module on a mobile device having a secure element associated with a unique identifier, the method comprising:

storing, on the mobile device, data identifying the unique identifier of a secure element associated with the mobile device; and

determining that the unique identifier of the secure element matches the stored unique identifier before access to the application module is allowed.

14. A mobile electronic device comprising means for performing the method of any one of claims 1 to 13.

15. A computer-readable medium comprising program code means for configuring a computer to perform the steps of the method of any one of claims 1 to 13.