PROVISIONING TO A DIGITAL PAYMENT DEVICE (DPD)

Abstract

A provisioning agent for provisioning a Digital Payment Device (DPD) which includes a Digital Transaction Processing Unit (DTPU) operable to host one or more transaction applications, the DTPU being further operable to adopt at least one transaction application selected from the one or more transaction applications, the DPD operable for a digital transaction with a Digital Transaction Device (DTD) using the adopted at least one transaction application, the provisioning agent being operable to provide provisioning data to the DPD, the DPD further including apparatus operable to receive the provisioning data, the provisioning data being operable to provide one or more functions to the DPD, the provisioning agent being operable to: prepare one or more first digital objects, receive one or more second digital objects from a second provisioning agent, include at least one of the one or more first digital objects and at least one of the one or more second digital objects in the provisioning data.

Claims

1. A provisioning agent for provisioning a Digital Payment Device (DPD) which comprises a Digital Transaction Processing Unit (DTPU) operable to host one or more transaction applications, the DTPU being further operable to adopt at least one transaction application selected from the one or more transaction applications, the DPD operable for a digital transaction with a Digital Transaction Device (DTD) using the adopted at least one transaction application, the provisioning agent being operable to provide provisioning data to the DPD, the DPD further including apparatus operable to receive the provisioning data, the provisioning data being operable to provide one or more functions to the DPD, the provisioning agent being operable to: prepare one or more first digital objects, receive one or more second digital objects from a second provisioning agent, and include at least one of the one or more first digital objects and at least one of the one or more second digital objects in the provisioning data.

2. A provisioning agent in accordance with claim 1, wherein the provisioning agent and the second provisioning agent are remote from the DPD.

3. A provisioning agent in accordance with claim 1, wherein the DTPU is operable to adopt the at least one transaction application selected from the one or more transaction applications while the provisioning agent and the second provisioning agent are remote from the DPD and without intercommunication with the DPD.

4. A provisioning agent in accordance with claim 1, wherein the DTPU is operable to host one or more Personalized Digital Transaction Packages (PDTPs), each PDTP associated with at least one of the one or more transaction applications.

5. A provisioning agent in accordance with claim 4, wherein the DTPU is operable to adopt at least one PDTP selected from the one or more hosted PDTPs, the DPD operable for a digital transaction with a Digital Transaction Device (DTD) using the adopted PDTP.

6. A provisioning agent in accordance with claim 1, wherein the one or more functions provided to the DPD by the provisioning data include a personality operable to be hosted by the DPD, the personality including a PDTP operable to be hosted by the DTPU.

7. A provisioning agent in accordance with claim 1, wherein the one or more functions include operability to adopt the PDTP selected from the one or more hosted PDTPs, wherein the adoption is effected independently of the provisioning agent and the second provisioning agent.

8. A provisioning agent in accordance with claim 1, wherein the provisioning agent is operable to provide routing information for inclusion in the provisioning data, the routing information being operable to instruct a first component of the DPD to provide at least some of the provisioning data to a second component of the DPD.

9. A provisioning agent in accordance with claim 8, wherein the first component is a Microcontroller Unit (MCU).

10. A provisioning agent in accordance with claim 8, wherein the second component is an MCU.

11. A provisioning agent in accordance with claim 8, wherein the second component is the DTPU.

12. A provisioning agent in accordance with claim 8, wherein the second component is an Operational Security Element (OSE).

13. A provisioning agent in accordance with claim 1, wherein the one or more first digital objects includes at least one of: a command for execution by the OSE, a command for execution by DTPU, a command for execution by the MCU, information for storage on the DPD, and firmware for installation on the MCU.

14. A provisioning agent in accordance with claim 1, wherein the one or more second digital objects is operable to be executed by the DTPU, and thereby install an additional transaction application on the DTPU.

15. A provisioning agent in accordance with claim 1, wherein the one or more second digital objects includes at least one of: a command for execution by the DTPU, information for storage on the DPD, and information for transferral from the DPD to a Data Assistance Device (DAD).

16. A provisioning agent in accordance with claim 1, wherein the second provisioning agent is selected from a group comprising a TSM and a TSP.

17. A method for provisioning a Digital Payment Device (DPD) with provisioning data which provides one or more functions to the DPD, the DPD including a Digital Transaction Processing Unit (DTPU), the DTPU operable to host one or more transaction applications, the DTPU further operable to adopt at least one transaction application from the one or more hosted transaction applications, the DPD being operable to perform a digital transaction with a Digital Transaction Device (DTD) using an adopted at least one transaction application of the DTPU, the DPD further including apparatus operable to receive the provisioning data, the method comprising: a first provisioning agent preparing one or more first digital objects; the first provisioning agent receiving one or more second digital objects from a second provisioning agent; and the first provisioning agent providing the provisioning data to the DPD, the provisioning data including at least one of the one or more first digital objects and at least one of the one or more second digital objects.

18. A method in accordance with claim 17, wherein the DTPU is operable to adopt the at least one transaction application selected from the one or more transaction applications while the provisioning agent and the second provisioning agent are remote from the DPD and without intercommunication with the DPD.

19. A method in accordance with claim 17, wherein the DTPU is operable to host one or more Personalized Digital Transaction Packages (PDTPs), each PDTP associated with at least one of the one or more transaction applications.

20. At least one digital object provided by at least one provisioning agent to a Digital Transaction Processing Unit (DTPU) on a Digital Payment Device (DPD) remote from the at least one provisioning agent, wherein the at least one digital object causes the DTPU to be operable to adopt at least one transaction application independently of the at least one provisioning agent, the at least one transaction application being selected from one or more transaction applications hosted by the DTPU.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0725] FIG. 1 is a diagram of an embodiment of a provisioning infrastructure, DAD and DTC.

[0726] FIG. 2 is a diagram of an embodiment of a provisioning infrastructure, DAD and DTC.

[0727] FIG. 3 is a diagram of an embodiment of a provisioning infrastructure, DAD and DTC.

[0728] FIG. 4 is a diagram of an embodiment of a provisioning infrastructure, DAD, DTC and payment network.

[0729] FIG. 5A is an illustration of the exterior of an embodiment of a DTC.

[0730] FIG. 5B is a diagram of components in an embodiment of a DTC.

[0731] FIG. 5C is a diagram of components in an embodiment of a DTC.

[0732] FIG. 6 is a diagram of electrical connections between contact pads, an MCU and a DTPU in an embodiment of a DTC.

[0733] FIG. 7 is a tree diagram of an embodiment of a security hierarchy in a DTPU.

[0734] FIG. 8 is a tree diagram of an embodiment of a security hierarchy in a DTPU.

[0735] FIG. 9 is a tree diagram of an embodiment of a security hierarchy in a DTPU.

[0736] FIG. 10 is a tree diagram of a further embodiment of a security hierarchy in a DTPU.

[0737] FIG. 11 is a sequence diagram of an embodiment of a DTC provisioning process.

[0738] FIG. 12 is a sequence diagram of an embodiment of a DTC provisioning process.

[0739] FIG. 13 is a sequence diagram of an embodiment of a DTC provisioning process.

[0740] FIG. 14 is a sequence diagram of an embodiment of a DTC provisioning process.

[0741] FIG. 15 is a sequence diagram of an embodiment of a DTC provisioning process.

[0742] FIG. 16 is a sequence diagram of an embodiment of a DTC provisioning process.

[0743] FIG. 17 is a sequence diagram of an embodiment of a DTC provisioning process.

[0744] FIG. 18 is a sequence diagram of an embodiment of a DTC provisioning process.

[0745] FIG. 19 is a sequence diagram of an embodiment of a DTC provisioning process.

[0746] FIG. 20 is a sequence diagram of an embodiment of a DTC provisioning process.

[0747] FIG. 21 is an embodiment of metadata associated with a personality.

[0748] FIG. 22 is a sequence diagram of an embodiment of a DTC provisioning process.

[0749] FIG. 23 is a sequence diagram showing part of an embodiment of a process for adopting a personality on a DTC.

[0750] FIG. 24 is a sequence diagram showing part of an embodiment of a process for adopting a personality on a DTC.

[0751] FIG. 25 is a tree diagram of a further embodiment of a security hierarchy in a DTPU.

[0752] FIG. 26 is a tree diagram of a further embodiment of a security hierarchy in a DTPU.

[0753] FIG. 27 is a tree diagram of a further embodiment of a security hierarchy in a DTPU.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

[0754] FIG. 1 provides an overview of the main components of the apparatus, system and methods used for secure provisioning of data to a Digital Transaction Card (DTC) 12. In at least some embodiments, the DTC 12 is capable of hosting a plurality of personalities and adopting a personality from the plurality of personalities while the DTC is in the field. FIG. 1 shows a provisioning infrastructure 10 arranged to provision the DTC 12 via a Data Assistance Device (DAD) 14 (for example a smart phone) while the DTC and DAD are both physically remote (which is referred to here as being “in the field”) from the provisioning infrastructure 10. The provisioning infrastructure 10 includes a provisioning network 16, at least one issuer 18 (sometimes referred to as an initial card issuer), a remote notification service 22, a wireless communication network 24, and a mobile application portal 62. The provisioning network 16 is described below with reference to FIG. 2-4.

[0755] In the embodiments illustrated in the figures, the Digital Payment Device (DPD) is exemplified as a DTC. It will be appreciated that in other embodiments the invention can operate with other types of DPD, including non-payment embodiments. In at least some embodiments, the DTC has dimensions and a shape which conform to specifications for a traditional plastic transaction card, such as a credit card, which is suitable for use in an automated teller machine or contact payment terminal. For example, the DTC can be in accordance with at least one of ISO 7816-1 (physical characteristics), ISOC 14443-1 (physical characteristics), and ISO 7816-2 (location of contacts). It will be appreciated that in other embodiments the DPD can have a different shape and/or dimensions, and can for example be configured for use in wearable applications (for example a ring, pendant or watch), non-wearable goods (for example a refrigerator or vehicle), non-payment applications (for example an identity document), and transport payment devices.

Terminology Related to Personalities

[0756] In embodiments of the present invention, the DTC 12 is operable to host one or more personalities and the DTC is operable to adopt a personality selected from one or more hosted personalities. The one or more hosted personalities can be associated with at least one issuer. In an embodiment, the DTC 12 is operable to host a plurality of personalities including at least one personality associated with a first issuer and at least one personality associated with a second issuer. In an embodiment, the DTC is operable to host one or more personalities associated with the same issuer.

[0757] In an embodiment, the DTC 12 is operable to host one or more transaction applications associated with at least one domestic payment scheme. In an embodiment, the DTC 12 is operable to host one or more transaction applications associated with at least one international payment scheme. In an embodiment, the DTC 12 is operable to host a plurality of transaction applications including at least one transaction application associated with a first domestic payment scheme and at least one transaction application associated with a second domestic payment scheme. In an embodiment, the DTC 12 is operable to host a plurality of transaction applications including at least one transaction application associated with a first international payment scheme and at least one transaction application associated with a second international payment scheme.

[0758] A “hosted” personality is one which is installed on the DTC. An installed personality is either in an active state or an inoperable state. A personality in an active state (an “active” personality) is capable of being used by the DTC in a transaction with a DTD. A personality in an inoperable state (an “inoperable” personality) cannot be used by the DTC in transactions with a DTD. An inoperable personality is available to be made active (activated) while the DTC is in the field, and an active personality can be made inoperable (de-activated) while the DTC is in the field. The DTC is operable to enable a cardholder to initiate the activation or de-activation of a personality while the DTC is in the field.

[0759] Activating a personality is also referred to as adopting a personality. Changing the active personality/personalities is also simply referred to as changing the personality. An embodiment of a process for activating/adopting a personality is described below with reference to FIGS. 8-9 and FIGS. 23-24.

[0760] Referring to FIG. 5A, an example of a DTC 12 is shown in which three personalities 7, 8, 9 are installed on (hosted by) the DTC 12. The three personalities 7, 8, 9 correspond to three transaction accounts issued by various payment schemes and banks: [0761] personality 7: Visa credit account (issued by Bank 1); [0762] personality 8: Mastercard debit account (issued by Bank 1); and [0763] personality 9: American Express credit account (issued by Bank 2).

[0764] Each personality 7, 8, 9 represents a different transaction account and enables the DTC to conduct transactions with one specific transaction account. To conduct a transaction with a transaction account, the personality associated with the transaction account must be adopted by the DTC. The adoption is triggered by a cardholder.

[0765] Each hosted personality 7, 8, 9 is associated with a single Personalized Digital Transaction Package (PDTP). An active personality is associated with an active PDTP, and an inoperable personality is associated with an inoperable PDTP.

[0766] Each PDTP is associated with at least one transaction application, therefore each personality is also associated with at least one transaction application. A transaction application which is inoperable for transactions with the DTC is referred to as being “locked”, and a transaction application which is operable for transactions with the DTC is referred to as being “unlocked”. A locked transaction application is not selectable in a transaction with a DTD, even with direct selection.

[0767] Where an active PDTP is associated with a plurality of transaction applications, the PDTP may be associated with one or more unlocked transaction applications and one or more locked transaction applications. Such a PDTP (and associated personality) is considered to be active because it is operable to be used in at least some transactions.

Provisioning Infrastructure Embodiments

[0768] The issuer 18 in payment embodiments can be any party that authorises a payment service to be provided by the DTC 12 (in at least some non-payment embodiments, the issuer can be the party that issues a document such as a passport or drivers licence). For example, the issuer 18 may be a financial institution or a party with a banking licence. The issuer 18 also authorises the provisioning network 16 to provision the DTC 12 while the DTC is in the field. In various embodiments, the issuer 18 issues the DTC 12 to a cardholder. It is also contemplated in other embodiments that the DTC 12 can be issued by another authorized provider (sometimes referred to as an additional card issuer or distributor). However, in this specification the system will be exemplified with an initial card issuer 18. The provisioning infrastructure 10 is shown operating with only one issuer 18, however, in various embodiments, the provisioning infrastructure is operable with multiple issuers (for example, issuers for many different banks and/or financial institutions). In other embodiments, the provisioning network may be associated with a single issuer.

[0769] The provisioning network 16 is operable to communicate with the DAD 14 by means of the wireless communication service 24 (creating a communication link 20) and to communicate with the DTC 12 via the DAD 14 (using wireless communication link 26). The issuer 18 or its agent is operable to communicate with the DAD 14 via the provisioning network 16 and link 20. The wireless communication network 24 can be any wireless network capable of transmitting sufficient data to and from the DAD 14, and could include, for example, an internet service provider or a mobile network operator.

[0770] In the illustrated embodiments, the provisioning infrastructure 10 is operable to communicate with the DTC 12 via the DAD 14 and the wireless communication network 24. However, in other embodiments, communications with the DTC 12 may occur Over The Wire (OTW) through a DTD, such as a POS terminal, directly to the DTC via contact link (for example, by dipping the DTC in to the DTD) or by a contactless communication link between the DTD and the DTC, for example via NFC or Bluetooth between the DTD and DTC. In other embodiments, the OTW communication may be to the DAD 14 via a contactless communication link (for example, NFC or Bluetooth) and then from the DAD to the DTC 12 (for example, via Bluetooth).

[0771] In the embodiment shown in FIG. 1, the DAD 14 and the DTC 12 are linked via link 26 for intercommunication. In one example, the link 26 uses Bluetooth (including Bluetooth Low Energy BLE). In other examples, the link 26 uses Near Field Communication (NFC). In yet another example (described below with reference to FIG. 3), the DTC 12 includes WiFi capability which enables the DTC to connect directly to the wireless communication network 24 without requiring the DAD 14 for intercommunication therebetween. However, the DAD may be employed in initially setting up the WiFi communication between the DTC and the wireless communication network.

[0772] In alternative embodiments, the link 26 between the DAD 14 and DTC 12 is a non-wireless communication link. In one such embodiment, link 26 is a cable connection between the DTC 12 and DAD 14. In another such embodiment, the link 26 includes electrical contacts which are operable to be brought into data communication with electrical contacts on the DTC 12 (for example, contact plate 34 shown in FIGS. 5A and 5B). In one version, the DAD 14 includes such electrical contacts. In another version, the DAD 14 is operable to connect via a cable to an apparatus which includes electrical contacts operable to be brought into data communication with electrical contacts on the DTC 12. In other alternative embodiments, the link 26 includes both wireless and non-wireless communication links. In one such embodiment, the DAD 14 is operable to connect wirelessly to an apparatus which includes electrical contacts and is operable to be brought into data communication with electrical contacts on the DTC 12.

[0773] FIG. 1 also illustrates a remote notification service 22 which is operable to provide push notifications to a mobile application 60 on the DAD 14. For example, a push notification may request the cardholder to download provisioning data to the DTC or DAD, such as digital objects which install a new personality or a firmware update. Such a push notification could include a notification to the cardholder to check that the DTC is powered up and paired with the DAD before commencing a download of digital objects. Such provisioning would take place through the provisioning infrastructure 10 using the processes described below.

[0774] FIG. 1 also illustrates a mobile application portal 62. In one embodiment, the mobile application portal 62 is operable to download the mobile application 60 onto the DAD 14. In another embodiment, the mobile application portal 62 is operable to download a configuration file onto the DAD 14. Such a configuration file may include Bluetooth keys for a specific DTC to enable the DAD 14 to pair with the DTC 12. In an embodiment, such a configuration file is only be provided after the specific DTC has been confirmed to be eligible to receive the download, for example by registering the DTC through the mobile application portal 62.

[0775] FIG. 2 shows the same embodiment shown in FIG. 1 but illustrates further details of the provisioning network 16, DAD 14 and DTC 12. The DTC 12 includes a DTPU 30, a Microcontroller Unit (MCU) 32, and a metal contact plate 34 (for contact transactions) which is electrically connected to the DTPU 30 and MCU 32. Other components on the DTC 12 have been omitted from FIG. 2 for simplicity but are described below with reference to FIGS. 5A and 5B.

[0776] The provisioning network 16 includes a first provisioning agent 36 and at least one second provisioning agent 38. The provisioning agent 36 includes functions of a TSM, but provides functions not provided by known TSMs, including management functions which support the operation of the DPD. In the following embodiments, the provisioning agent 36 will be referred to as a DPD manager 36.

[0777] In embodiments, each provisioning agent 38 is a Trusted Service Manager (TSM) or a Tokenised Service Provider (TSP), both of which are known in the prior art. In the following embodiments, the at least one second provisioning agent 38 will be referred to as a TSM/TSP 38.

[0778] The TSM/TSP 38 is trusted or managed by the issuer 18. The DPD manager 36 is in data communication with the DAD 14 and the TSM/TSP 38, and the TSM/TSP is in data communication with the issuer 18. In some embodiments, the components and functions of the provisioning network 16 can be provided by a single agent (provisioning agent), a single server and/or a single site, however, it is envisaged that in most embodiments the various components and functions are to be provided by different agents, albeit with some components and functions combined in a single agent or single server. It is also possible that the issuer 18 and the provisioning network 16 is a combined agent (combined provisioning agent), or that parts of the provisioning network are combined with the issuer.

[0779] The DPD manager 36 provides a number of important functions related to the provisioning and operation of the DTC 12. The DPD manager 36 is operable to generate digital objects additional to those provided by a traditional TSM/TSP 38, and to transmit such digital objects to the DTC 12.

[0780] The DPD manager 36 is also operable to transmit digital objects to the DTC 12 on behalf of the TSM/TSP 38. In particular, the DPD manager 36 is operable to receive digital objects provided by the TSM/TSP 38 and to transmit such digital objects to the DTC 12. The DPD manager 36 provides this function (the transmission of digital objects on behalf of the TSM/TSP 38) because provisioning agents of the prior art, such as TSM/TSP 38, are not suitable for provisioning a digital payment device such as a DTC 12. One of the reasons is that a prior art TSM/TSP 38 is arranged to communicate directly with a mobile device hosting a wallet, without communicating through an intermediary device such as the DAD 14. Also, a prior art TSM/TSP 38 does not provide routing information to instruct the MCU 32 to provide the digital objects to a suitable component on the DTC. Also, a prior art TSM/TSP 38 is only known to provision contactless payment instances. Further, a prior art TSM/TSP 38 is only known to provide metadata (such as the payment scheme name, branding, account name, last four digits of the PAN) to a single device (a wallet on mobile device), whereas embodiments of the present information provision two devices with metadata, namely the DTC 12 and DAD 14.

[0781] In the embodiment in FIGS. 1-2, the DPD manager 36 is operable to transmit digital objects to the DTC 12 via the DAD 14 via link 26 (for example using Bluetooth for communications between the DTC 12 and the DAD 14), and in the embodiment (shown in FIG. 3) the DPD manager 36 is operable to transmit digital objects directly to the DTC 12 via a WiFi communication link 64. Such digital objects are provided to at least one of the MCU 32 and DTPU 30 of the DTC 12. In the embodiment in FIGS. 1-2, providing the digital objects to the MCU and/or DTPU involves establishing the communications links 20, 26 with the DTC 12 via the DAD 14. In the embodiment in FIG. 3, providing the digital objects to the MCU and/or DTPU involves establishing the communication link 64 with the DTC 12.

[0782] In an embodiment, the DPD manager 36 includes routing information (for example, a header) with each digital object transmitted to the DTC via link 20, link 26 or link 24. In an embodiment, the routing information includes information indicative of an intended destination of the digital object. In an embodiment, the information indicative of an intended destination of the digital object specifies a component of the DTC, for example the DTPU. The MCU is operable to read the routing information and provide the digital object to the specified component of the DTC (as specified in the routing information). For example, the routing information can be operable to instruct the MCU to forward a digital object to the DTPU, or in another example, store the digital object in the MCU. The DPD manager 36 also includes routing information with any digital object provided by the TSM/TSP 38, and transmits such digital object(s) together with the routing information to the DTC 12.

[0783] In an embodiment, the DPD manager 36 is also operable to maintain a record of the state of the DTC 12, including a record of each personality installed on (hosted by) the DTC 12, and characteristics of the DTC 12, for example the device model. In an embodiment, the DPD manager 36 is operable to request the DTC 12 to provide information indicative of the state of the DTC. The DPD manager 36 is also operable to receive requests from the cardholder for a new personality to be installed on the DTC 12 while the DTC 12 is in the field. The DAD 14 is operable to transmit each such cardholder request to the DPD manager 36, and the DPD manager 36 is operable to forward each such cardholder request to the TSM/TSP 38, which in turn is operable to forward each such cardholder request to the issuer 18. In an embodiment, the DPD manager 36 is operable to include additional information in the request to the issuer 18, for example information which specifies aspects of the personality to be installed, including information regarding the required operation mode of the personality (contact, contactless, or both). In another embodiment, the issuer 18 provides an online facility for the cardholder to submit the request directly without using the DAD 14. If the issuer 18 approves the cardholder's request for a new personality to be installed, the issuer 18 initiates a process in which the DPD manager 36 and the TSM/TSP 38 both provide digital objects for installation on the DTC 12. An example of such a process will be described below with reference to FIGS. 17 to 21.

[0784] In the embodiments shown in FIGS. 1-4 only one issuer 18 and one TSM/TSP 38 are depicted in the provisioning infrastructure 10, but it should be understood that the provisioning infrastructure 10 can include a plurality of issuers and the provisioning network 16 can include a plurality of provisioning agents. In one embodiment, the provisioning network 16 includes a plurality of TSMs. In another embodiment, the provisioning network 16 includes a plurality of TSPs. In another embodiment, the provisioning network 16 includes at least one TSM and at least one TSP. Each TSM (which may also be referred to as a Service Provider TSM or SP-TSM) is usually managed directly by a separate issuer 18. A TSP is generally a service provided by another party such as a payment scheme (for example Visa or Mastercard) on behalf of the issuer 18. In an embodiment, the provisioning infrastructure 10 includes at least one issuer for each TSP and includes a separate TSP for each payment scheme supported by the provisioning infrastructure.

[0785] The TSM/TSP 38 includes a key manager 42 and is operable (amongst other functions) to negotiate SSD cryptographic key management on the DTC 12 on behalf of the issuer 18. Each key manager 42 is operable to issue SSD keys 44 to the DTC 12. The key manager 42 may sometimes be referred to as, or the functions of a key manager may be incorporated into, a security domain manager.

[0786] The embodiment in FIG. 2 also includes a number of Application Programming Interfaces (APIs) to facilitate communications between parties, but the APIs are not illustrated. In particular, the DPD manager 36 has an API for each communication link with another party, including an API for communications with the DAD 14, an API for communications with the issuer 18, and an API for communications with the TSM/TSP 38. The issuer 18 and TSM/TSP 38 each have a separate API for communications with the DPD manager 36. The DPD manager 36 also includes APIs for communications with parties involved in the manufacture, assembly and personalisation of the DTC 12 before the DTC is distributed to future cardholders in the field.

Components of the DPD Manager

[0787] In the embodiment depicted in FIG. 2, components of the DPD manager 36 include a DPD manager gateway 46, a DPD content management system 52, a DPD application management system 58, a DPD key manager 54, and a mobile application server 50.

[0788] In an embodiment, the DPD manager gateway 46 is operable to provide an interface for communications between components of the DPD manager 36 and the DAD 14 or DTC 12, and to manage network connectivity with the DAD 14 or DTC 12. Specifically, the DPD manager gateway 46 is operable to communicate with a DAD gateway 48, which is a software installation on the DAD 14. The DPD manager gateway 46 is operable to both send and receive data to and from the DAD gateway 48. In an embodiment, all communications via link 20 (or link 64 in FIG. 3) are encrypted in accordance with TLS cryptographic protocol and the DPD manager gateway 46 and DAD gateway 48 include suitable functionality to set up encrypted TLS sessions and decrypt such communications.

[0789] In an embodiment, the mobile application server 50 is operable to serve as an interface between the DPD manager gateway 46 and the other components of the DPD manager (DPD content management system 52, DPD application management system 58, DPD key manager 54). In an embodiment, the mobile application server 50 is also operable to manage the mobile application 60 installed on the DAD. The mobile application 60 enables the cardholder to perform certain management and operational functions for the DTC 12. The mobile application server 50 is also operable to store configuration files for the mobile application 60. In an embodiment, the mobile application server 50 is also operable to store metadata for the DTC 12, such as PAN (personal account number, or primary account number), expiry date and cardholder name. Such metadata may be used by the MCU and/or displayed on a graphical user interface of the DTC, or displayed on the DAD 14.

[0790] In an embodiment, the DPD content management system 52 is operable to generate digital objects (for installation on the DTC 12) and to forward the digital objects to the DTC 12. The DPD content management system 52 is operable to request a DPD key manager 54 to encrypt such digital objects before transmission to the DTC 12. In an embodiment, the DPD content management system 52 is operable to transmit the digital objects via the mobile application server 50 and DPD manager gateway 46 to the DTC 12.

[0791] In an embodiment, the digital objects generated by the DPD content management system 52 include commands for execution on the DTPU 30. Examples of such commands include scripts operable to: query the state of PDTPs installed on the DTPU, install a container on the DTPU, install a DTP on the DTPU, install a security hierarchy on the DTPU, install an application selection module on the DTPU, de-activate all PDTPs on the DTPU, activate a PDTP, install SSD keys on the DTPU, or install an SSD on the DTPU. In embodiments, the commands are provided in command scripts, and in this embodiment are in the form of command APDUs or C-APDUs.

[0792] In an embodiment, the DPD content management system 52 is operable to process responses sent from the DTPU 30 in response to commands received by the DTPU 30. In this embodiment, responses from the DTPU are in the form of response APDUs or R-APDUs. In an embodiment, such responses are received and analysed by the DPD content management system 52 and the result is passed to the DPD application management system 58. If there has been an error on the DTPU 30 when attempting to execute a command, the DPD application management system 58 is operable to initiate a suitable response. For example, the DPD application management system 58 may re-send a command. The MCU 32 may also analyse responses to provide feedback to the cardholder via a graphical user interface. In another embodiment, responses are received and analysed directly by the DPD application management system 58 without passing through the DPD content management system 52.

[0793] In an embodiment, the digital objects generated by the DPD content management system 52 include digital objects for installation on the MCU 32, for example: firmware, a TLS certificate, an FQDN, a Bluetooth key, or a PKI key.

[0794] In an embodiment, the DPD content management system 52 is also operable to store one or more containers, for example Executable Load Files (ELFs), for one or more payment schemes or one or more non-payment schemes supported by the DPD manager 36.

[0795] The DPD key manager 54 is operable to generate cryptographic keys 56 and securely store and protect such keys, for example in a hardware security module (HSM). The DPD key manager 54 is also operable to look up a keyset for a particular DTC 12, or look up a key for a specific end point on a DTC 12, for example a key for specific SSD, or a PKI key (for example a public PKI key) for a counterpart PKI key (for example a private key) on an MCU of a specific DTC 12. In an embodiment, only SSD and ISD keys are generated and stored by the DPD key manager 54.

[0796] The DPD key manager 54 is also operable to encrypt and decrypt information received from the DPD content management system 52, for example scripts and firmware.

[0797] The DPD application management system 58 can perform a number of functions. In an embodiment, the DPD application management system 58 is operable to maintain a record of each DTC 12 in the field and the characteristics of each DTC 12 in the field, for example, identifiers (for example, ICCID), model, and date of manufacture. The DPD application management system 58 is also operable to store details of cardholders.

[0798] In an embodiment, the DPD application management system 58 is operable to receive commands from the TSM/TSP 38 and forward the commands to the DTPU 30 on the DTC 12 (via the mobile application server 50 and DPD manager gateway 46). Although only one TSM/TSP 38 is illustrated in FIGS. 2-3 for simplicity, it is understood that the DPD application management system 58 is operable to receive commands from a plurality of provisioning agents. Examples of commands that the DPD application management system 58 may receive from the TSM/TSP 38 and transmit to the DTPU 30 include scripts operable to rotate an SSD key on the DTPU, and scripts operable to personalise a DTP. When the DTPU 30 sends a response to a command that has been provided by a TSM/TSP 38, the response is transmitted to the DPD application management system 58 (via the DPD manager gateway 46 and mobile application server 50), and the DPD application management system 58 is operable to forward the response to the TSM/TSP 38 which originally issued the corresponding command.

Some DAD Component Details and Mobile Application Setup

[0799] In the embodiment shown in FIGS. 1-2, the DAD 14 is a smartphone, however, in other embodiments, the DAD can be any suitable device, such as a PC, a tablet PC, or other types of mobile computing devices. In yet other embodiments, the DAD may be a Digital Transaction Device (DTD), such as an Automatic Teller Machine (ATM), which has been suitably adapted to provide the functionality required of the DAD in embodiments of this invention.

[0800] In other embodiments, it is contemplated that the functions required of the DAD 14 in the present invention could be performed on a DTC if configured with functionality to communicate with the provisioning network 16 (likely using WiFi or similar technology). Such a DTC would also need to be equipped with suitable processing, memory and a power source to perform the required functions as performed by the DAD in embodiments of the present invention. Thus, the DAD 14 is an optional component for implementing embodiments of the present invention.

[0801] The DAD has software installed, referred to as a DAD gateway 48, which enables the DAD 14 to act as a bridge between the provisioning infrastructure 10 and the DTC 12. The DAD gateway 48 is operable to communicate with the provisioning infrastructure 10 via link 20, and with the DTC 12 via link 26. The DAD gateway 48 provides functionality which may not be visible to the cardholder of the DAD 14, unlike the mobile application 60 which is visible to cardholders. The DAD gateway 48 and mobile application 60 can be part of the same software installation, but as they provide different types of functionality they will be described here as though they are separate software items.

[0802] The DAD gateway 48 and mobile application 60 may be requested and distributed by another authorized party. In some embodiments, the DAD gateway 48 and mobile application 60 are provided to the DAD 14 only upon confirmation that the user of the DAD (or the DAD itself) is authorized to receive the mobile application, wherein the DAD provides confirmation of the DAD identity (for example, the International Mobile Equipment Identity (IMEI) of the DAD if a smartphone). Typically, the DAD user will be the same person as the DTC cardholder. In other embodiments, the confirmation of authorization includes confirming the DTC 12 identity, which may include one or more of a unique serial number for the DTC, a Bluetooth ID, a unique identifier for a DTPU on the DTC and other unique identifiers which either singly or in combination uniquely identify the DTC or components thereon. In some embodiments, the confirmation of authorization includes a combination of a DAD identifier and one or more DTC identifier(s).

[0803] In at least some embodiments, the DTC 12 is operable to take part in a personality installation process which is operable to install a new personality on the DTC while the DTC is in the field. In such a process, the DPD manager 36 transmits digital objects to the DAD 14 and DTC 12, the digital objects including scripts and metadata associated with the personality. Examples of metadata associated with a personality include the scheme name, the issuer name, the cardholder's name, the full PAN, the last four digits of the PAN, the expiry date, and the CVV. In embodiments, at least some of the metadata is stored on both the DAD 14 and the DTC 12. The DTC 12 is operable to use the stored metadata to present information to the cardholder about the personality which is currently active on the DTC 12.

[0804] In the embodiment shown in FIGS. 1-2, the DPD manager 36 is operable to forward digital objects for the installation of a new personality to the DAD 14, and the DAD 14 is operable to forward the digital objects to the DTC 12. The DTC 12, after processing the digital objects, is operable to forward at least some of the metadata (contained within the received digital objects) back to the DAD 14 for installation thereon.

[0805] In an alternative embodiment, shown in FIG. 3, the DTC 12 includes a WiFi communication module (a WiFi communication module is shown in FIG. 5B as item 88) and the DTC is operable to communicate with the DPD manager 36 via link 64 which uses wireless communication network 24. The DPD manager 36 is operable to forward digital objects to install a new personality directly to the DTC 12 via link 64, bypassing the DAD 14. In an embodiment, the cardholder triggers the download of such digital objects to the DTC, for example by pressing a button on the DTC. The DTC 12 and DAD 14 in FIG. 3 are also operable to communicate via link 26 (as in FIGS. 1-2), for example via Bluetooth or NFC. The DTC 12, after processing the received digital objects, is operable to forward at least some of the metadata (contained within the received digital objects) back to the DAD 14 for installation thereon.

[0806] The process of installing a new personality on the DTC 12 can be triggered in different ways. In an embodiment of a personality installation process (which can be implemented in at least some versions of the configurations shown in FIGS. 1-3), the process is triggered when a cardholder uses the mobile application 60 on the DAD 14 to select a new personality and request installation of the personality on the DTC. In an embodiment, the personality is selected from a list of personalities available for download to the cardholder. This list of personalities may be determined by the issuer 18, based on accounts held by the cardholder.

[0807] The DAD gateway 48 on the DAD 14 is operable to transmit the personality installation request to the issuer 18 and/or the DPD manager 36. In an alternative embodiment of a personality installation process (which can be implemented in the configurations shown in FIGS. 1-3), the process of installing a new personality on the DTC 12 begins when a cardholder engages a user interface on the DTC 12 (not shown) to select a new personality and requests installation of the personality on the DTC. The DTC 12 is operable to transmit the personality installation request to the DAD gateway 48 on the DAD 14, and the DAD gateway 48 is operable to transmit the installation request to the issuer 18 and/or the DPD manager 36.

[0808] If a cardholder's personality installation request is approved by the provisioning infrastructure 10 (typically by the issuer 18 and/or the DPD manager 36), the DPD manager 36 is operable to begin the installation process. An embodiment of such an installation process is described below with reference to FIGS. 17 to 21.

[0809] In the prior art, provisioning of mobile payment cards in digital wallets on smart phones requires a GP communications session (which is synchronous) between endpoints comprising the provisioning network and a secure element within the phone. All segments between the endpoints must remain established during the session. All commands must be sent and all responses must be received during the session. If any commands are not sent or any responses are not received (all of which are APDUs) between the endpoints, the session will not be successful i.e. it will have failed. Also, if any segments of a session are dropped (for example, when two components associated with a segment are de-linked and are not in data communication with each other), the entire session will need to be re-established (once the components are re-linked for intercommunication therebetween) to attempt the provisioning process again.

[0810] As synchronous communication requires all components in a session to be operational for the duration of the session, all of those components consume electrical power for the duration of the session. This is generally not a problem for mobile phones because they are designed to be recharged regularly at a power outlet. However, it is advantageous if the DTC 12 can operate without requiring a cardholder to remember to recharge the DTC for at least six months and preferably at least a year, and ideally for the life of the DTC. Therefore, depending on the power storage capacity of the DTC, at least some embodiments of the DTC 12 may be constrained to operate within a power consumption budget which is much smaller than that of a mobile phone. With such a small power budget, the DTC 12 may not have the power budget to maintain synchronous communications sessions with the provisioning network 16.

[0811] In the present specification, FIGS. 1-6 illustrate embodiments of the invention in which provisioning includes asynchronous communications in at least part of the provisioning process.

[0812] Due to the less-stringent requirement of asynchronous provisioning, it is possible in some embodiments to have responses delayed, as the session for delivering the responses need not be established within any particular time frame. However, for practical purposes, it will be recognized that the delay for responses in asynchronous provisioning should be kept as short as possible. Asynchronous provisioning allows for more robust provisioning (and for communication between the provisioning network and the DTPU), as the session requirements allow for delayed responses and for segments to be dropped, without compromising a provisioning event.

[0813] The asynchronous communications are made possible by the use of a proxy for the provisioning network 16 in communications with the DTC 12. The purpose of the proxy is to emulate characteristics and communications of the provisioning network, so that the proxy appears, from the point of view of the DTPU, to be the provisioning network itself, such that the DTPU will accept commands from the proxy and send responses to the proxy.

[0814] In an embodiment, the DAD is operable to act as a proxy for the provisioning network 16. In an embodiment, the DAD gateway 48 is operable to act as the proxy. In other embodiments, a communications component or other component of the DTC 12 is operable to act as the proxy. In an embodiment, the MCU 32 is operable to act as the proxy. In some embodiments, the function of a proxy is provided by multiple components which may be distributed across different devices, such as the DAD and DTC. In yet other embodiments, there are more than one proxy between the provisioning network 16 and the DTPU 30.

[0815] The proxy is operable to communicate with one or more components of the DTC 12 (for example the DTPU 30 and/or the MCU 32) independently of the provisioning network. In embodiments, the proxy is operable to process a response from one or more components of the DTC without communicating with the provisioning network. In embodiments, the proxy is operable to receive a first response from the component of the DTC and respond by transmitting a command to the component, without transmitting the first response to the provisioning network. For example, the proxy may be operable to receive and store a plurality of commands provided by the provisioning network, and to select and transmit a single command (from the plurality of commands) to a component of the DTC. Each of the plurality of commands may include a packet header which is readable by the proxy and contains sufficient information to enable the proxy to select a command for transmission to the DTPU. This sequence of communications in which the proxy receives a response from a component of the DTC and transmits a command back to the component may be repeated multiple times (depending on the number of commands held by the proxy) before the proxy communicates with the provisioning network.

[0816] In embodiments, the proxy is operable to store a plurality of responses from a component of the DTC, for example the DTPU. In embodiments, the proxy is operable to transmit a plurality of responses (for example, a plurality of responses from the DTPU) in a single transmission to the provisioning network.

Interactions with a Payment Network

[0817] Referring to FIG. 4, at least some embodiments of the DTC 12 are operable to conduct financial transactions with a conventional payment network including a DTD 70 (for example a POS terminal) which communicates with the DTC 12, an acquirer 72, a payment scheme 74, and the issuer 18. In the embodiment shown in FIG. 4, the provisioning network 16 is not involved in the process of conducting a transaction. However, the provisioning network 16, together with the issuer 18, are operable to provision the DTC 12 with digital objects that enable the DTC 12 to conduct transactions with a conventional payment network.

Architecture of the DTC

[0818] FIGS. 5A and 5B illustrates further details of an embodiment of a DTC 12 operable to be provisioned by the provisioning infrastructure 10 described above and illustrated in FIGS. 1-3.

[0819] In the prior art, a plastic credit card or debit card has a single operable personality provided by a single issuer, for example a single bank. Some cards in the prior art are operable to route transactions through two payment schemes (also known as payment networks) which consist of a single domestic payment scheme (for example, EFTPOS in Australia, Interac in Canada, or RuPay in India), and a single international payment scheme (for example, Visa or Mastercard). Such cards include a different transaction application for each payment scheme, but only include transaction applications for a single international payment scheme and a single domestic payment scheme. Such prior art cards do not include transaction applications for two different international payment schemes, and do not include transaction applications for two different domestic payment schemes. One transaction application on the card is used whenever the card performs a transaction with a Digital Transaction Device (DTD), for example a POS terminal. The DTD selects an appropriate transaction application to be used, for example a domestic transaction application or an international transaction application. Some cards have separate transaction applications for contact and contactless transactions. Again, the DTD selects an appropriate transaction application to be used.

[0820] Since transaction cards of the prior art have only one operable personality, there is no possibility to select a personality from one or more personalities hosted by the card. Where a card has a plurality of transaction applications, there is no facility on the card itself to select one particular transaction application for use in a transaction.

[0821] The DTC 12 includes a user interface 83A, 83B which can be used by a cardholder to select one of the personalities for use in a transaction. In this embodiment, the user interface includes a display screen 83A (for example a dot matrix display) and a button keypad 83B. In another embodiment the user interface includes a touchscreen display instead of a keypad.

[0822] The DTC 12 in this embodiment has interfaces for performing both contact and contactless transactions. In an alternative embodiment, the DTC 12 is operable to perform only contactless transactions, and in a further alternative embodiment, the DTC 12 is operable to perform only contact transactions. In the embodiment shown in FIG. 5B, contact transactions are conducted via a contact plate 34 and contactless transactions are conducted via an NFC antenna 92, as is well known in the prior art. The contact plate 34 is an external interface for the DTPU 30 and MCU 32 and enables data communication between the DTPU 30 and an MCU 32. The MCU 32 is also in data communication with an Operational Secure Element (OSE) 80, a secure memory 84, a communications module 86, and the user interface 83A, 83B.

[0823] The MCU 32 is operable to perform various operations on the DTC 12, including: receiving external information (including digital objects) transmitted from the provisioning network 16, routing digital objects to other components on the DTC 12, generating a list of AIDs for a personality selected by a cardholder, requesting scripts from a script applet 81 on the OSE 80 and forwarding scripts to the DTPU 30, forwarding information from the DTC 12 to the provisioning network 16, reading and writing information to and from the secure memory 84, and managing the user interface 83A, 83B.

[0824] In the depicted embodiment, the DTPU 30 is a tamper-resistant secure element suitable for performing financial transactions and capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the relevant rules and security requirements. The DTPU 30 has a GlobalPlatform-compliant (GP-compliant) operating system installed thereon and sufficient user memory to install multiple personalities which includes being operable to install multiple payment scheme containers, multiple PDTPs, and a security hierarchy with multiple subsidiary security domains (SSDs). The SSDs in the security hierarchy include at least one SSD 94 associated with PDTPs, and at least one SSD 96 associated with an application selection module. The DTPU 30 stores multiple cryptographic keys including at least one ISD key 98 for the ISD of the DTPU, an SSD key 100 for each SSD 94 associated with PDTPs, and an SSD key 102 for the SSD 96 associated with the application selection module. The keys 98, 100, 102 are used by the DTPU 30 to authenticate a script to be executed thereon.

[0825] In an embodiment, the DTPU 30 is in an OP_READY or INITIALIZED state while in the factory, and the state must be changed to SECURED (using appropriate keys for authentication) before the DTC is distributed to a cardholder.

[0826] The GP-compliant operating system on the DTPU 30 includes a “Global Lock” privilege which enables the locking and unlocking of a transaction application on the DTPU. When all transaction applications of a PDTP are locked, the PDTP and associated personality are inoperable. When one or more transaction applications of a PDTP are unlocked, the PDTP and associated personality are considered to be active. As each PDTP is associated with a personality, de-activating a PDTP effectively de-activates the associated personality, and activating a PDTP activates the associated personality. The locking and unlocking of transaction applications and the activation and de-activation of PDTPs are described below.

[0827] As will be described, the Global Lock action is implemented by executing one or more authenticated scripts in the DTPU 30. The MCU 32 is operable to initiate a process of generating such authenticated scripts. Authenticated scripts are generated by a command generation unit which in this embodiment is an applet referred to as a script applet 81. The script applet 81 uses a script template from a template store 82, and an SSD key 104, to generate authenticated scripts which include commands. The template store 82 stores one or more script templates which are not functioning scripts until certain values are filled in, for example an AID of a target application in the DTPU. In the embodiment in FIG. 5B, the script applet 81, template store 82, and key(s) 104 are all stored in the OSE 80. The process of generating authenticated scripts is described in more detail below with reference to FIGS. 8-9 and FIGS. 23-24.

[0828] Plastic credit or debit cards and digital wallets in the prior art do not have the capacity to generate authenticated scripts. In the case of plastic cards in the prior art, authenticated scripts are prepared externally (for example, by a perso bureau) and provided to the card while the card is in a secure environment such as a perso bureau. In the case of digital wallets in the prior art, authenticated scripts are prepared externally (typically by a TSM) and transmitted to the digital wallet for execution.

[0829] In at least some embodiments, the DTC is operable to simultaneously have multiple active personalities. However, it is preferable that the simultaneously active personalities are those that would not have the potential to compete or conflict with each other during a transaction. For example, when conducting a contactless payment, a first personality which is exclusively associated with contact transactions application would not compete with a second personality which is exclusively associated with contactless transaction applications, so there would not be a conflict. Similarly, a personality for a document (e.g. a drivers licence) could not take part in a financial transaction, so the document personality can be simultaneously active with any personality for a financial transaction. In an embodiment, the MCU controls which personalities are operable be simultaneously active. The MCU can refer to rules stored on the DTC, for example in an MCU register. Such rules can be recorded in metadata associated with personalities.

[0830] In an embodiment, the DTPU 30 is operable to use the Global Lock privilege to lock all transaction applications installed on the DTPU and then unlock one or more transaction applications associated with a PDTP (which is associated with a personality selected by the cardholder), while the DTC is in the field without the DTC communicating with the provisioning infrastructure 10. In an embodiment, such locking and unlocking of transaction applications can be triggered by a cardholder interacting with the user interface 83A, 83B and making a personality selection. In an alternative embodiment, the locking and unlocking of transaction applications can be triggered by a cardholder interacting with the DAD 14 and making a personality selection, and the DAD is operable to communicate the cardholder's personality selection to the DTC 12.

[0831] In the depicted embodiment, the OSE 80 is a tamper resistant secure element. In one embodiment, a GP-compliant operating system is installed on the OSE 80, and in another embodiment the OSE 80 does not include a GP-compliant operating system. In an embodiment, a security hierarchy with at least one SSD is installed on the OSE 80. The OSE 80 is operable to store keys 104, the script applet 81 and the template store 82, all of which are used in a process for changing the active personality on the DTC 12.

[0832] In the embodiment depicted in FIG. 5B, the secure memory 84 is a tamper resistant storage area which does not include a GP-compliant operating system. For example, the secure memory 84 can include ultra-secure hardware-based cryptographic key storage and cryptographic countermeasures designed to reduce or eliminate potential backdoors linked to software weaknesses. The MCU 32 has read and write access to the secure memory 84 and is operable to store digital objects in the secure memory 84 that do not require a GP-compliant operating system, for example Bluetooth keys and metadata associated with a personality. In an alternative embodiment, the DTC does not include a secure memory, and digital objects such as Bluetooth keys and metadata are instead stored in the MCU 32.

[0833] Referring to FIG. 5C, an alternative embodiment of a DTC 12 is shown in which the script applet 81, template store 82, SSD key 104, and MCU registry 35 are included on a secure MCU 33. In this embodiment the function of the OSE 80 (shown in FIG. 5B) is performed by the secure MCU 33. Further, the DTPU 30 and secure MCU 33 are incorporated into a single integrated circuit chip 37 (indicated by a dotted line 37 in FIG. 5C). The script applet 81, template store 82 and SSD key 104 should always be stored securely as they enable the generation of scripts capable of being executed on the DTPU 30. Therefore, the secure MCU 33 should have a level of security which is accordance with the relevant rules and security requirements. In an alternative embodiment (not shown), the secure MCU 33 and DTPU 30 are provided as separate chips.

The Communications Module of the DTC

[0834] In embodiment depicted in FIG. 5B, the communications module 86 is operable to conduct wireless communications with either the DAD 14 (by Bluetooth or NFC, through link 26 shown in FIGS. 1-2) or the DPD manager 36 (by WiFi, through link 64 shown in FIG. 3). In the case of Bluetooth and NFC communications, the communications module enables the DTC 12 to be linked to (sometimes referred to as being paired with) the DAD 14 for intercommunications. In this embodiment, the communications module 86 includes a WiFi module 88 (which includes a WiFi chip and antenna), a Bluetooth module 90 (which includes a Bluetooth chip and antenna), and the NFC antenna 92.

[0835] The NFC antenna 92 is directly connected to the DTPU 30, whereas the Bluetooth module 90 and WiFi module 88 are connected to the MCU 32. The WiFi module 88, Bluetooth module 90 and NFC antenna 92 may be discrete components but are referred to collectively as the communications module 86. In other embodiments of the DTC 12, the communications module 86 does not have all three items 88, 90, 92, but includes at least one of a WiFi module, a Bluetooth module, and an NFC antenna. In one embodiment, the communications module 86 consists of the Bluetooth module 90. In another embodiment, the communications module 86 consists of the WiFi module 88. In another embodiment, the communications module 86 consists of both the WiFi module 88 and the Bluetooth module 90. Alternatively, any other suitable apparatus for wireless communication can be included in the communications module 86.

MCU, OSE and DTPU Connections

[0836] In the embodiment shown in FIG. 5B, a communication link 106 between the MCU 32 and OSE 80 uses a serial communication protocol. A communication link 108 between the DTPU 30 and the contact plate 34 is in accordance with the ISO 7816 standard, as is well known in the prior art. Unlike the prior art, the depicted embodiment illustrates a communication link 110 between the MCU 32 and the contact plate 34. In one embodiment, link 110 is in accordance with the ISO 7816 standard. In another embodiment, link 110 uses a serial communication protocol. Links 108, 110 enable command APDUs (C-APDUs) to be transmitted from the MCU to the DTPU 30, and response APDUs (R-APDUs) to be transmitted from the DTPU to the MCU.

[0837] Referring to FIG. 6, the communication links between the contact plate 34 and the DTPU 30 and MCU 32 (shown in FIG. 5B) are illustrated in more detail. As is known in the prior art, the DTPU 30 is connected to five patterned metal contact pads within the contact plate 34, having standard functions: VCC (pad 122), RESET (pad 124), CLOCK (pad 126), GROUND (pad 128), and DATA (pad 130). These five contact pads (122, 124, 126, 128, 130) are conventionally used in financial transactions to exchange APDUs between a DTD (for example, a POS terminal) and the DTPU 30. In the embodiment in FIG. 6, the five contact pads (122, 124, 126, 128, 130) are also connected to the MCU 32. As indicated in FIG. 5B, the MCU has also communication links with the other components on the DTC (the OSE 80, user interface 83A, 83B, secure memory 84, Bluetooth module 90, and NFC antenna 92) and these links are indicated by lines 136 in FIG. 6.

[0838] The contact plate 34 depicted in FIG. 6 also includes two pads 132, 134 which are connected to the MCU 32 but not to the DTPU 30. The pads 132, 134 are specified by ISO 7816 to be used for custom applications, and in this embodiment pads 132, 134 are provided to enable serial communications with the MCU 32. In this embodiment, pad 132 is operable to transmit data to the MCU 32, and pad 134 is operable to receive data from the MCU. Custom contact pins will likely be required to contact pads 132, 134. It is anticipated that pads 132, 134 may be used in a factory or similar environment (for example a perso bureau) for provisioning the MCU with digital objects before the DTC is distributed to a cardholder. For example, digital objects provisioned via pads 132, 134 could include digital objects intended for the MCU 32 or digital objects for relocation (by the MCU) to either the OSE 80, secure memory 84, or communications module 86. The five contact pads (122, 124, 126, 128, 130) enable the DTPU 30 to be provisioned directly without using the MCU 32 to route digital objects to the DTPU, for example when transmitting scripts to the DTPU while the DTC is in the factory or in contact mode with a DTD.

[0839] In at least some embodiments, a switch (not shown) is included to disconnect the MCU 32 from pads 132, 134 when these pads are not in use, to avoid unwanted voltages inadvertently affecting the MCU and the risk of hacking via pads 132, 134.

[0840] The same communication links shown in FIG. 6 are also used in the embodiment shown in FIG. 5C between the contact plate 34, DTPU 30, and secure MCU 33 (in place of the MCU 32).

Metadata

[0841] The DTC 12 and DAD 14 store metadata associated with each personality hosted by the DTC. Such metadata is used by the MCU when changing the active personality on the DTC. The metadata enables the MCU to look up an AID of each transaction application associated with a selected personality and then request the script applet 81 to generate one or more scripts in respect of the AID(s). In an embodiment, at least some of the metadata is displayed on the display screen 83A to indicate the active personality/personalities.

[0842] FIG. 21 shows an embodiment of metadata for one personality. In this embodiment, the metadata is stored as a table in which a first column 888 comprises scheme name, issuer name, cardholder name and AID list, a second column 890 comprises the full PAN (personal account number or primary account number), the last four digits of the full PAN, expiry date and CVV, and a third column 892 comprises a nickname (generated by the cardholder) for the personality. In this embodiment, such metadata is stored on the MCU 32 in an MCU registry 35 (shown in FIG. 5B). In alternative embodiments, the metadata is stored outside the MCU 32. In an embodiment, the metadata is stored in the secure memory 84, and in another embodiment the metadata is stored in the OSE 80.

[0843] In an embodiment in which a PDTP is associated with a plurality of transaction applications and the DTC 12 is operable to unlock at least one transaction application (from the plurality of transaction applications) and to lock all other of the plurality of transaction applications, the DTC 12 stores additional metadata about the plurality of transaction applications. In an embodiment, metadata is stored for each transaction application and at least some of the metadata can be displayed on the display screen 83A. The metadata enables the MCU to look up each AID associated with each selected transaction application and then request the script applet 81 to generate one or more scripts in respect of the AID(s). In an embodiment, the metadata for each transaction application includes at least the following information: primary PAN, AID, identifying information, nickname, operation mode (contact or contactless). In an embodiment, the identifying information in the metadata is a tokenised PAN. In another embodiment, the identifying information is a sequence number. The purpose of the identifying information is to enable an issuer to identify a transaction application that has been used in a transaction.

Provisioning the DTC

[0844] The purpose of provisioning is to provide digital objects to the DTC 12, for example to give operational functionality to the DTC, or to install a personality. Examples of such digital objects include data for installing firmware needed for operation of the DTC (for example, MCU firmware), and for providing scripts, keys, payment scheme containers, metadata, and applications (including transaction applications, PDTPs, and selection applications). Scripts can be provided to the DTC to perform many functions on the DTC, including installing a payment scheme container, installing a DTP from a payment scheme container, personalising a DTP, and installing a security hierarchy in the OSE or DTPU, amongst others.

[0845] In an embodiment, the DTC is at least partially “pre-provisioned” in a factory, which means being provisioned with digital objects in a factory environment prior to the DTC being distributed to a cardholder in the field. The DTC in this embodiment is operable to be further provisioned in the field by the provisioning infrastructure 10. Pre-provisioning in the factory includes provisioning with the involvement of a component manufacturer, device assembly operation, device testing operation, key injection partner, lamination factory, perso bureau or any other party involved in the manufacture or preparation of the DTC before it reaches the field. At least some of the digital objects required to provision the DTC are provided to the factory by the provisioning infrastructure 10.

[0846] In one version, the DTC is pre-provisioned in the factory with at least one of firmware, a GP-compliant security hierarchy, a cryptographic key, a payment scheme container, a PDTP, and a selection application. For example, the DTC can be pre-provisioned with digital objects to install a number of personalities, and the DTC can be operable to be provisioned in the field (by the provisioning infrastructure 10) so as to install at least one more personality on the DTC. Alternatively, the DTC may be pre-provisioned with one or more payment scheme containers, and the DTC is operable to be provisioned in the field (by the provisioning infrastructure 10) so as install a PDTP from the one or more installed payment scheme containers.

[0847] In an alternative embodiment, the DTC is distributed to a cardholder after very little pre-provisioning in the factory, and is operable to be largely provisioned in the field by the provisioning infrastructure 10. In such an embodiment, the DTC is pre-provisioned with rudimentary bootstrap firmware (installed on the MCU) and keys, for example a TLS certificate, a key for decryption of a subsequent firmware update (for example a PKI key), and DTPU keys to enable the DTPU to be supplied in a SECURED state.

[0848] In an alternative embodiment, the DTC is pre-provisioned in the factory with a plurality of personalities and the DTC is not capable of being provisioned in the field. This embodiment of the DTC is also capable of hosting a plurality of personalities and for adopting a personality from the plurality of personalities while the DTC is in the field.

Embodiment of a Security Hierarchy on the DTPU

[0849] As has been mentioned, provisioning the DTC includes installing a security hierarchy on the DTPU. FIG. 7 illustrates an embodiment of a security hierarchy 201 suitable for hosting a plurality of personalities and for adopting a personality from the plurality of personalities while the DTC is in the field.

[0850] The security hierarchy 201 has a tree structure. The highest level of the security hierarchy is the Issuer Security Domain (ISD) 200. The ISD in this embodiment is a parent to three SSDs (202, 96, 206) which are each a parent to three sibling branches of the tree structure and described below. Each SSD in the hierarchy holds at least one cryptographic key which is operable to authenticate scripts targeting that SSD. For example, SSD 206 holds a key which is operable to authenticate any script targeting SSD 206. Only a party that has a copy of the appropriate key for a specific SSD can authenticate scripts targeting that SSD.

[0851] SSD 96 is a parent to a first branch of the tree structure. The first branch includes a PSE selection application 222, a PPSE selection application 224, and a container 226. A copy of the key held by SSD 96 is also held by the OSE 80 (shown in FIG. 5B) and a provisioning network 16 (specifically a DPD manager 36, as shown in FIGS. 1-3). Therefore, the OSE 80 and DPD manager 36 are each operable to authenticate scripts targeting SSD 96 and the applications 222, 224 associated with SSD 96 (in the terminology of a tree structure, applications 222, 224 are each a “child” of SSD 96). The PSE and PPSE selection applications are installed from the container 226 which in the form of at least one Elementary Load File (ELF).

[0852] SSD 206 is parent to a second branch of the tree structure. The second branch is a sibling to the first branch. SSD 206 is a parent to SSD 228 and SSD 236, each of which is under the control of a different party, for example a bank. SSD 228, which is controlled by “Bank 1”, is a parent to three further SSDs 242, 244, 246, and each of these further SSDs is a parent to one PDTP (which includes at least one transaction application) for a single personality: [0853] SSD 242 is a parent to PDTP 230 for a Bank 1 Visa personality; [0854] SSD 244 is a parent to PDTP 232 for a Bank 1 Mastercard personality; [0855] SSD 246 is a parent to PDTP 234 for a Bank 1 American Express personality.

[0856] Only Bank 1 has a copy of the keys held by SSDs 228, 242, 244, 246. Bank 1 would use its own SP-TSM to perform operations on SSDs 228, 242, 244, 246.

[0857] “Bank 2” controls SSD 236, which is a parent to two further SSDs 248, 250, and each of these further SSDs is a parent to a PDTP (which includes at least one transaction application) for a single personality: [0858] SSD 248 is a parent to PDTP 238 for a Bank 2 Visa personality; [0859] SSD 250 is a parent to PDTP 240 for a Bank 2 Mastercard personality.

[0860] Only Bank 2 has a copy of the key held by SSDs 236, 248, 250. Bank 2 would use its own SP-TSM to perform operations on SSD 236, 248, 250.

[0861] SSD 202 is a parent to a third branch of the tree structure. The third branch and is a sibling to the first and second branches. SSD 202 is a parent to three SSDs: SSD 210 (which is a parent to a payment scheme container 216 for Visa), SSD 212 (which is a parent to a payment scheme container 218 for Mastercard), and SSD 214 (which is a parent to a payment scheme container 220 for American Express). Each payment scheme container is used to generate (instantiate) an unpersonalised transaction application which (when combined with personalisation data) is used to create a transaction application. For example, the container 216 for Visa in FIG. 7 would have been used to generate unpersonalised Visa transaction applications for Bank 1 and Bank 2, which were subsequently personalised to create each transaction application included in Visa PDTP 230 and each transaction application included in Visa PDTP 238.

[0862] Within the DTPU is an additional security domain 208 known as a Controlling Authority Security Domain (CASD). The CASD 208 in this embodiment is a domain which is trusted by both the DPD manager and the managers of PDTPs on the DTPU. This embodiment, Bank 1 and Bank 2 are the managers of the PDTPs on the DTPU. The CASD can be used to perform a key rotation, which is where a key provided by one party (for example, the DPD manager) is swapped for a key provided by another party (for example, a PDTP manager). A key rotation may be used after the DPD manager installs an SSD (for example, an SSD associated with a new personality) to give control of the SSD to the relevant PDTP manager (for example, Bank 1 or Bank 2). In some embodiments, the CASD is present on the DTPU when issued by a chip manufacturer or provider. In another embodiment, a CASD is installed when the DTC is in a secure factory environment and prior to the issuer 18 having access to the DTC (to avoid the possibility of tampering by the issuer). In embodiments in which there is trust between the DPD manager and the manager of each PDTP, a CASD may not be required. In some of such embodiments, the DTPU does not include a CASD.

Embodiments of an Application Selection Module

[0863] A function of the application selection module 225 is to enable the DTC 12 to provide an identifier for each transaction application on the DTPU 30 which is unlocked and therefore available to be used in a transaction with a DTD 70 (for example a POS terminal 70 shown in FIG. 4). In the embodiments described here, the identifier is a AID (application identifier) known in the prior art, but the identifier can alternatively be any information which is capable of identifying a transaction application and can be recognised and processed by a DTD 70 and complies with relevant standards and agreements for payment networks, payment processing methods, and DPDs for such payment networks.

[0864] In at least some embodiments, the DTC 12 is operable to unlock selected transaction applications and to lock any other transaction application on the DTPU 30. Each selected transaction application can be associated with one or more PDTPs. Such embodiments of a DTC 12, when performing a transaction with a DTD 70, are operable to provide to the DTD an AID for each unlocked transaction application on the DTPU 30, without providing an AID for any locked transaction application. The set of AIDs provided by the DTC 12 to the DTD 70 is referred to here as a “candidate list”. During a transaction, the DTD 70 selects an AID from the candidate list, and the selected AID is subsequently used in the transaction.

[0865] In an embodiment of the invention, the application selection module 225 is operable to generate the candidate list during a transaction, and the DTPU 30 is operable to provide the candidate list to the DTD 70. The candidate list must only include transaction applications which are currently unlocked. If a personality is subsequently activated or de-activated (and a transaction application is therefore unlocked or locked, respectively), such a change in state must be reflected in the candidate list during a subsequent transaction.

[0866] In an embodiment, the application selection module 225 is operable to generate a candidate list for many kinds of transaction application, including a transaction application associated with a payment scheme (for example, a credit or debit account personality), a transaction application associated with a non-payment personality (for example, an identity document), a transaction application associated with a transport smart card personality, a transaction application for contact transactions, a transaction application for contactless transactions, and a transaction application with interfaces for both contact and contactless transactions. Such transaction applications include transaction applications with different primary PANs, transaction applications with the same primary PAN, transaction applications with different tokenised PANs, and transaction applications with different sequence numbers.

[0867] In an embodiment in which the DTC 12 hosts at least one transaction application for a payment scheme, the application selection module 225 includes the PSE selection application 222 and the PPSE selection application 224. In an embodiment in which each transaction application hosted by the DTC 12 is a contact transaction application (operable for contact transactions only), the application selection module 225 may not include the PPSE selection application 224. In an embodiment in which each transaction application hosted by the DTC 12 is a contactless transaction application (operable for contactless transactions only), the application selection module 225 may not include the PSE selection application 222. In all such embodiments, the application selection module 225 is operable to perform a process in which the PSE selection application (if included) is set with an AID of each unlocked contact transaction application, and the PPSE selection application 224 is set with an AID of each unlocked contactless transaction application. When there is a change in the status of any transaction application (changing from locked to unlocked or vice versa), the DTC 12 is operable to repeat the process of setting the PSE selection application 222 with an AID of each unlocked contact transaction application and setting the PPSE selection application 224 with an AID of each unlocked contact transaction application.

[0868] Although the presently described embodiment of the application selection module 225 includes the PSE selection application 222 and the PPSE selection application 224, the application selection module 225 is not limited to these selection applications. For example, the application selection module 225 can include a selection application for selecting a transaction application associated with a non-payment personality. Such a selection application can operate in a similar way to the PSE and PPSE selection applications.

[0869] In DTCs in the prior art, the PSE selection application and PPSE selection application are set in the factory and never changed once the DTC is in the field. There is no facility to re-set the PSE selection application and PPSE selection application once the DTC is in the field.

[0870] In an embodiment of the present invention, the DTC 12 is operable to set or re-set the PSE selection application 222 and the PPSE selection application 224 by sending at least one script 203 containing one more commands (script 203 is shown in FIG. 7) to the application selection module 225 in the DTPU 30. In an embodiment, the script 203 includes appropriately authenticated APDUs which include an encrypted payload in accordance with the SCP02 protocol. For security purposes, the script 203 must be authenticated as a prerequisite to being executed by the application selection module 225. The script 203 is authenticated against the SSD 96 (which, in the hierarchy in FIG. 7, is a parent to the application selection module 225) and executed by the PSE selection application 222 and/or PPSE selection application 224. The script 203, when executed, sets the PSE selection application with an AID of each unlocked contact transaction application, and sets the PPSE selection application 224 with an AID of each unlocked contactless transaction application.

[0871] In an embodiment, the script 203 is generated on the DTC 12 by the script applet 81 (in the OSE 80). Inputs used by the script applet 81 to generate the script include: a script template provided by the template store 82 (in the OSE 80), an AID of each unlocked transaction application (each AID is provided by the MCU 32, for example from metadata shown in FIG. 21), a key 104 (stored in the OSE 80), and a counter value associated with a targeted SCP02 keyset in the DTPU 30. The key 104 is a copy of an SSD key held by SSD 96. As shown in FIG. 7, SSD 96 is a parent to the application selection module 225 in the security hierarchy. The script applet 81 uses the key 104 and counter value to generate a session key which is used to authenticate the script 203 against the SSD 96 so that the script can be executed by the application selection module 225. An example of a process for generating the script 203 is described below with reference to FIGS. 23 and 24, as part of a process for changing the active personality/personalities.

[0872] In an alternative embodiment, script 203 is provided by the provisioning infrastructure 10 in a provisioning process. An embodiment of a provisioning infrastructure 10 operable suitable for provisioning the DTC 12 while the DTC 12 is in the field (remote from the provisioning infrastructure 10) is described with reference to FIGS. 1-3. In an embodiment, script 203 is provided by the provisioning infrastructure 10 (specifically the DPD manager 36) and stored in the MCU 32 until required. In another embodiment, script 203 is stored in the OSE 80 and retrieved by the MCU 32 when required. In another embodiment, script 203 is stored in the secure memory 84 and retrieved by the MCU 32 when required. Multiple types of scripts 203 can be provisioned and stored to meet the future requirements of the DTC 12 until it is provisioned by the provisioning infrastructure 10.

[0873] In an alternative embodiment, script 203 is pre-provisioned (installed while the DTC 12 is in the factory) and stored until required. Again, such script 203 can be stored in the MCU 32, OSE 80 or secure memory 84 until required. In such an embodiment, multiple scripts 203 are stored to meet the future requirements of the DTC 12 or until it is provisioned by a provisioning infrastructure 10.

[0874] In an embodiment, script 203 includes each AID to be set. In an alternative embodiment, the PSE selection application 222 and/or the PPSE selection application 224 includes a register which is operable to store AIDs of respective transaction applications hosted by the DTPU 30. In such an embodiment, script 203 includes information to identify a transaction application (for example, “05” to indicate a specific transaction application), and the PSE selection application 222 and/or the PPSE selection application 224 refer to the register to look up the AID corresponding to transaction application “05”. When a new personality is installed on the DTC, the register is updated with each AID associated with the new personality.

De-Activating PDTPs

[0875] In an embodiment, changing the active personality on the DTC involves locking all transaction applications hosted by the DTPU and then unlocking each transaction application associated with a selected PDTP, which leaves any other transaction application locked. Each locked transaction application is inoperable during a transaction and cannot be directly selected by a DTD.

[0876] In an embodiment of a locking process illustrated in FIG. 8 (which shows the same hierarchy 201 depicted in FIG. 7), SSD 206 is targeted with an appropriately authenticated “Lock and Associated” command, which does the following: [0877] a) locks (makes inactive) SSD 206, [0878] b) locks all SSDs associated with (children of) the SSD 206 in the hierarchy, and [0879] c) locks all transaction applications associated with (children of) the locked SSDs.

[0880] Therefore, in this embodiment, the Lock and Associated command has the effect of a) locking SSD 206, b) locking SSDs 228, 236, 242, 244, 246, 248, 250, and c) de-activating PDTPs 230, 232, 234, 238, 240. Each padlock 211 indicates either a locked SSD or an inoperable PDTP.

[0881] The locking of all SSDs associated with SSD 206 (and the consequent de-activation of all PDTPs) is referred to here as a “cascade locking” process. In a cascade locking process the SSD 206 is referred to as a Lock SSD for PDTPs. Applying cascade locking to Lock SSD 206 makes all PDTPs inoperable. From the cardholder's point of view, cascade locking de-activates all personalities (makes them inoperable). In an embodiment, the DTC is operable to perform cascade locking when changing the active personality on the DTC.

[0882] The cascade locking process is triggered when the DTPU receives at least one authenticated script 207 in the form of APDUs. In an embodiment, the APDUs include an encrypted payload in accordance with the SCP02 protocol and are authenticated against SSD 96 (the parent SSD of application selection module 225).

[0883] In this example, script 207 commands the application selection module 225 to target the Lock SSD 206 (as indicated by arrow 209) with a cascade locking command. In an embodiment, the application selection module 225 is operable to use the Global Lock privilege to target the Lock SSD 206 with the cascade locking command.

[0884] In an embodiment, script 207 targets the PSE selection application 222 to perform the cascade locking process. In an alternative embodiment, the script 207 targets the PPSE selection application 224 to perform the cascade locking process. In an alternative embodiment, the script 207 targets a different unlocked application to either perform the cascade locking process or delegate the PSE or PPSE application to perform the cascade locking process.

[0885] In an alternative embodiment (not shown), a single cascade locking command is not used to de-activate PDTPs. Instead, multiple lower-level SSDs are each targeted with a separate lock command. For example, by locking SSD 228 and SSD 236, all lower level SSDs will be locked. In the example shown in FIG. 8, targeting SSD 228 with a lock command causes SSDs 242, 244, 246 to be locked and PDTPs 230, 232, 234 to be de-activated. Similarly, targeting SSD 236 with a lock command causes SSDs 248, 250 to be locked and PDTPs 238, 240 to be de-activated. Alternatively, a separate lock command can be targeted at each of SSDs 242, 244, 246, 248, 250 to de-activate all PDTPs. In one version, the application selection module 225 uses the Global Lock privilege to target each SSD to be locked. In another version, Global Lock privilege and the application selection module 225 are not used. Instead, each SSD to be locked (for example SSD 242) is targeted directly by a lock command included in a script provided to the DTPU 30. The script is in the form of APDUs and authenticated against the SSD to be targeted. In an embodiment, a registry in the MCU keeps a record of the locking status of each SSD and enables the DTC 12 to avoid generating scripts for SSDs that do not need to change locking status.

[0886] In an embodiment, each authenticated script to lock all PDTPs (such as script 207) is generated on the DTC 12. In an embodiment, the MCU 32 commands the script applet 81 (in the OSE 80) to generate each authenticated script. Inputs used by the script applet 81 to generate the script include: a script template (provided by the template store 82 in the OSE 80), identifiers such as AIDs to identify each PDTP to be de-activated (the identifiers are included in metadata provided by the MCU 32), a key 104 (stored in the OSE 80), and a counter value associated with a targeted SCP02 keyset in the DTPU 30. The key 104 is a copy of a key held by the SSD to be targeted. Where the script targets the application selection module 225, the key a copy of a key held by the parent SSD 96. An example of a process for generating script 207 is described below with reference to FIGS. 23 and 24. Where the script targets a parent SSD of a PDTP, the key 104 is a copy of a key held by the targeted SSD.

[0887] The script applet 81 uses the key 104 and counter value to generate a session key which is used to authenticate the script against the targeted SSD. Once an authenticated script has been generated by the script applet 81, the MCU 32 forwards the authenticated script to the DTPU 30 for execution.

Activating Targeted PDTPs

[0888] In an embodiment, changing the active personality on the DTC includes activating a targeted PDTP. Activating a targeted PDTP directly after a cascade locking process results in only the targeted PDTP being active. Therefore, only the personality associated with the targeted PDTP is activated. Referring to FIG. 9 (which shows the same hierarchy 201 depicted in FIGS. 7 and 8), an inoperable PDTP can be activated by unlocking at least one transaction application associated with the PDTP. For example, PDTP 230 can be activated by unlocking at least one transaction application associated with PDTP 230.

[0889] In this example, script 213 commands the application selection module 225 (which has the Global Lock privilege) to target at least one transaction application associated with the Visa PDTP 230 with an application unlock command (as indicated by arrow 215). In an embodiment, the application unlock command is a SET STATUS command which causes one or more transaction applications associated with the Visa PDTP 230 to revert to their previous state, which was an unlocked state. Once script 213 is executed, Visa PDTP 230 becomes active, which means transaction applications associated with PDTP 230 can be used in transactions and the personality associated with PDTP 230 is active (available to be used by the cardholder).

[0890] In an alternative embodiment, the script 213 targets a different unlocked application on the DTPU 30 (instead of application selection module 225) to either target each transaction application with an unlock command, or delegate the PSE or PPSE application to target each transaction application with an unlock command.

[0891] In a further alternative embodiment (not shown), Global Lock privilege and the application selection module 225 are not used. Instead, a script is provided to the DTPU 30 to command another application on the DTPU 30 to target each PDTP to be activated. Such an application could be an unlocked SSD. In an embodiment, an additional SSD referred to here as an Application Unlock SSD is provided which is a parent to SSD 206 for the purpose of activating PDTPs. The Application Unlock SSD does not get locked in a cascade locking process because it is a parent to Lock SSD 206 in the hierarchy. In the example shown in FIG. 9, a script would be provided to command the Application Unlock SSD to activate PDTP 230, without involving the application selection module 225 in the unlocking process.

[0892] In an embodiment, each authenticated script for activating a PDTP (such as script 213) is generated on the DTC 12. In an embodiment, the MCU 32 commands the script applet 81 (in the OSE 80) to generate each authenticated script. Inputs used by the script applet 81 to generate the script include: a script template (provided by the template store 82 in the OSE 80), identifiers such as AIDs to identify each PDTP to be activated (identifiers are included in metadata provided by the MCU 32), a key 104 (stored in the OSE 80), and a counter value associated with a targeted SCP02 keyset in the DTPU 30. The key 104 is a copy of a key held by the SSD to be targeted. Where the script targets the application selection module 225, the key 104 is a copy of a key held by the parent SSD 96. An example of such a process for generating script 213 is described below with reference to FIGS. 23 and 24. Where the script targets a parent SSD of PDTP, the key 104 is a copy of a key held by the parent SSD (for example, where the script targets PDTP 230, the key is a copy of the key held by SSD 242).

[0893] The script applet 81 uses the key 104 and counter value to generate a session key which is used to authenticate the script against the targeted SSD. Once an authenticated script has been generated by the script applet 81, the MCU 32 forwards the authenticated script to the DTPU 30 for execution.

[0894] Script 213 may be included as part of the cascade locking script 207 or it may be a separate script. In this embodiment, script 213 targets a PDTP 230 which may include both contact and/or contactless functionality. Script 213 is operable to target a single transaction application or multiple transaction applications within a PDTP, for example either a contact transaction application or contactless transaction application, or both contact and contactless transaction applications.

[0895] The PSE selection application 222 and PPSE selection application 224 are each operable to unlock any transaction application on the DTPU. In an embodiment, the PSE selection application 222 is used to unlock each contact transaction application within a targeted PDTP, and the PPSE selection application 224 is used to unlock each contactless transaction application within a targeted PDTP. In an embodiment, the PSE selection application 222 is operable to manage the PPSE selection application 224 (to reduce processing overheads). In such an embodiment, script 213 targets the PSE selection application 222, which delegates the PPSE selection application 224 to unlock any contactless applications to be targeted. In another embodiment, the PPSE selection application 224 is operable to manage the PSE selection application 222. In such an embodiment, script 213 targets the PPSE selection application 222 which delegates the PSE selection application 222 to unlock any contact applications to be targeted. In an alternative embodiment, there is an additional application (not shown, but which is part of the application selection module 225) which manages both the PSE and PPSE selection applications 222, 224. In such an embodiment, script 213 targets this additional application, which delegates the PSE and PPSE selection applications 222, 224 to unlock transaction applications to be targeted as appropriate.

Provisioning the DTC

[0896] Embodiments of processes related to the provisioning the DTC will now be described with reference to sequence diagrams shown in FIGS. 11 to 22.

Initial Set-Up of the DTC Through Provisioning in the Field

[0897] In an embodiment of the DTC and provisioning infrastructure 10, the DTC 12 is distributed to a cardholder with very little pre-provisioning in a factory and the DTC is operable to be mainly provisioned in the field by the provisioning infrastructure 10. An initial set-up phase of provisioning prepares the DTC for a subsequent phase of provisioning to install a personality. FIGS. 11 to 13 depict an embodiment of a process for performing the initial set-up phase (in the field), and FIGS. 17 to 21 depict an embodiment of performing the subsequent phase of provisioning (in the field).

[0898] FIG. 11 is a sequence diagram illustrating an embodiment of a provisioning process which is part of the initial set-up phase of provisioning in the field. The process in FIG. 11 loads a firmware update into the MCU of the DTC. Such a firmware update can enable the MCU to provide a range of functions on the DTC, for example storing or re-directing information received from the provisioning network, and retrieving script templates saved on the DTC in order to activate a different personality. Before the firmware update takes place, the MCU has a pre-installed “bootstrap” firmware which may be relatively rudimentary but at a minimum has the ability to decrypt and install the firmware update. In an embodiment, the bootstrap firmware is loaded onto the MCU during a chip manufacturing stage. In embodiments, the bootstrap firmware is capable of communication using a transport layer security (TLS) cryptographic protocol.

[0899] The process begins with step 498: the DPD manager 36 prepares a firmware update, encrypts the update, and bundles the encrypted firmware update with an installation command. In an embodiment, PKI encryption is used to encrypt the firmware update. In step 500, the DPD manager 36 forwards the firmware update and installation command to the DPD manager gateway 46 which then forwards the firmware update and command (in step 502) to a DAD gateway 48 on the cardholder's DAD. In step 504, the DAD gateway 48 forwards the firmware update and command to the mobile application 60, which (in step 506) encrypts the firmware update and command, for example using a Bluetooth encryption protocol (alternatively, the encryption in step 506 could be performed by the DAD gateway 48). In step 508, the mobile application 60 transmits the encrypted firmware update and command to a communications module 86 on the DTC. In step 510, the communications module 86 decrypts the encryption applied by the DAD (for example, Bluetooth encryption). In step 512 the communications module 86 forwards the firmware update and command to the MCU 32, and in step 514 the bootstrap firmware in the MCU decrypts and installs the firmware update. The MCU 32 then sends an acknowledgement of the installation and a firmware version identifier all the way back to the DPD manager 36 in the following order: step 516 (MCU 32 to communications module 86), step 518 (communications module 86 to mobile application 60), step 520 (mobile application 60 to DAD gateway 48), step 522 (DAD gateway 48 to DPD manager gateway 46), step 524 (DPD manager gateway 46 to DPD manager 36). In step 526, the DPD manager 36 analyses the acknowledgement to determine whether firmware update was installed successfully, and records the firmware version identifier.

[0900] In embodiments, the transmissions in steps 500, 502, 506, 508, 518, 520, 522, 524 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

[0901] Once the MCU firmware update has been installed, the MCU is ready to receive and store other information related to the operation of the MCU in the field. A process for loading such information into the MCU and will now be described. The process has a number of uses. In one embodiment, the process is used to load an application selection script into the MCU for subsequent relocation to the OSE 80. An application selection script is used when changing the active personality on the DTC while the DTC is in the field. In embodiments in which the DTC has Bluetooth functionality, the process can be used to load Bluetooth encryption keys into the MCU for subsequent relocation to the Bluetooth module 90. In embodiments in which the DTC has WiFi functionality, the process can be used to load a TLS certificate or one or more fully qualified domain name (FQDN) for one or more TSM/TSP 38, for subsequent relocation to the WiFi module 88. The process follows the same steps shown in FIG. 11 and will therefore be described with reference to FIG. 11, but it will be understood that the information loaded into the MCU is different.

[0902] In step 498, the DPD manager 36 prepares a data package which includes a data payload and routing information in the form of a header. The header includes information indicative of the intended destination of the data payload. In an embodiment, PKI encryption is used to encrypt the data payload. In another embodiment, the payload is encrypted using AES or another type of suitable symmetric encryption. In another embodiment, the data package is a script which contains APDUs with encrypted payloads and a header.

[0903] In step 500, the DPD manager 36 forwards the data package to the DPD manager gateway 46 which then forwards the data package (in step 502) to the DAD gateway 48. In step 504, the DAD gateway 48 forwards the data package to the mobile application 60, which (in step 506) encrypts the data package, for example using a Bluetooth encryption protocol (alternatively, this step 506 could be performed by the DAD gateway 48). In step 508, the mobile application 60 transmits the encrypted data package to a communications module 86 on the DTC. In embodiments, the transmissions in steps 500, 502, 506, 508, 518, 520, 522, 524 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

[0904] In step 510, the communications module 86 decrypts the encryption applied by the DAD (for example, Bluetooth encryption). In step 512 the communications module 86 forwards the firmware update and command to the MCU 32, which (in step 514) processes the data package. For example, the MCU may relocate the payload of the data package (according to headers in the data package) to a different component on the DTC, such as the OSE 80, secure memory 84, or the communications module 86. The MCU 32 then sends an acknowledgement of the installation all the way back to the DPD manager 36 (steps 516, 518, 520, 522, 524 described previously). In step 526, the DPD manager 36 analyses the acknowledgement to determine whether the whether the information was loaded successfully.

[0905] As mentioned, FIG. 11 illustrates the general principle of provisioning the MCU with a data package containing a payload which is then relocated to different component of the DTC. FIG. 12 shows an example in which the payload is relocated from the MCU 32 to the OSE 80. The purpose of the process shown in FIG. 12 is to set up the OSE 80 as part of the initial set-up phase of provisioning. The process loads a script (containing APDUs) into the OSE 80 where the script is executed. In an embodiment, the scripts, when executed by the OSE, trigger one or more of the following items to be installed on the OSE: a hierarchy of SSDs, keys for the SSDs in the hierarchy, a template store 82 containing script templates (for future use in the application selection module), a script applet 81 arranged to access the script templates in the template store, and keys for an SSD of the application selection module. The applet 81, template store 82, and keys are used when activating a different personality on the DTC (this process is described below with reference to FIGS. 23 and 24). In an alternative embodiment, the applet 81 is included in ROM of the OSE during manufacture of the OSE chip instead of being installed via the process depicted in 12.

[0906] The process in FIG. 12 begins with step 528: the DPD manager 36 generates one or more scripts which, when executed on the OSE, trigger installations in the OSE (for example, as mentioned, the installation of a hierarchy of SSDs and keys, a template store 82 containing script templates, a script applet 81 arranged to access the script templates, and keys for an SSD of the application selection module). Each script contains a header and APDUs with encrypted payloads. The header includes information to indicate that the intended destination of the script is the OSE 80. In an embodiment, the format of the APDUs is in accordance with the SCP02 protocol.

[0907] In step 530 the DPD manager 36 forwards each script to the DPD manager gateway 46 which then forwards each script (in step 532) to the DAD gateway 48. In step 534, the DAD gateway 48 forwards the script to the mobile application 60, which (in step 536) encrypts the script, for example using a Bluetooth encryption protocol (alternatively, the encryption in step 536 could be performed by the DAD gateway 48). In step 538, the mobile application 60 communicates the encrypted script to a communications module 86 on the DTC. In embodiments, the transmissions in steps 530, 532, 534, 538, 554, 556, 558, 560 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

[0908] In step 540, the communications module 86 decrypts the encryption applied by the DAD to the script (for example, Bluetooth encryption). In step 542 the communications module 86 forwards the script to the MCU 32, which (in step 544) reads a header on each script. In this embodiment, the header indicates that the intended recipient of the script is the OSE 80, so the MCU 32 commences a loop 545 in which each APDU is forwarded (in step 546) to the OSE 80 and (in step 548) a response APDU or R-APDU is returned to the MCU.

[0909] In step 550, the MCU checks that the number of C-APDUs matches the number of R-APDUs. The MCU also checks the status words (also called status bytes) in the R-APDU. If an error occurs that requires action by the cardholder, an appropriate error message is displayed on a display screen 83A (shown in FIG. 5A). If there is no error, the MCU records the installation in a table stored in the MCU and generates an acknowledgement which indicates the script has been executed successfully. The acknowledgement is forwarded all the way back to the DPD manager 36 in the following order: step 552 (MCU 32 to communications module 86), step 554 (communications module 86 to mobile application 60), step 556 (mobile application 60 to DAD gateway 48), step 558 (DAD gateway 48 to DPD manager gateway 46), and step 560 (DPD manager gateway 46 to DPD manager 36). In step 562, the DPD manager 36 analyses the acknowledgement to determine whether the script was executed correctly.

[0910] FIG. 13 illustrates an embodiment of a provisioning process which sets up the DTPU 30 as part of the initial set-up phase in the field. The DTPU also includes a CASD which has been pre-installed onto the DTPU, typically in a factory before the DTC is distributed to a cardholder. The CASD is installed by a party which is trusted by both the DPD manager and the manager of each PDTP to be installed on the DTC.

[0911] The purpose of the process depicted in FIG. 13 is to load a script (containing APDUs) into the DTPU where the script is executed. In an embodiment, one or more scripts are loaded into the DTPU to make the following changes on the DTPU (as part of the initial set-up phase of provisioning): install a hierarchy of SSDs and keys in the DTPU (for example, a hierarchy as shown in any one of FIGS. 7-13), install an application selection module in the DTPU, install one or more containers (for example, one or more ELFs) in the DTPU. The APDUs for these changes could be combined into a single script or could be split into more scripts which are loaded separately and executed. Alternatively, a subset of these scripts can be loaded into the DTPU while the DTC is in the factory and the other scripts can be loaded into the DTPU while the DTC is in the field.

[0912] The process in FIG. 13 begins with step 564: the DPD manager 36 generates one or more scripts which, when executed on the DTPU, trigger installations in the DTPU (for example, as mentioned, a hierarchy of SSDs and keys, an application selection module, and one or more containers). Each script contains a header and APDUs with encrypted payloads. The header includes information which indicates that the intended destination of the script is the DTPU 30. In an embodiment, the format of the APDUs is in accordance with the SCP02 protocol.

[0913] In step 566 the DPD manager 36 forwards each script to the DPD manager gateway 46 which then forwards each script (in step 568) to the DAD gateway 48. In step 570, the DAD gateway 48 forwards the script to the mobile application 60, which (in step 572) encrypts the script, for example using a Bluetooth encryption protocol (alternatively, the encryption in step 572 could be performed by the DAD gateway 48). In step 574, the mobile application 60 transmits the encrypted script to a communications module 86 on the DTC. In embodiments, the transmissions in steps 566, 568, 570, 574, 590, 592, 594, 596 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

[0914] In step 576, the communications module 86 decrypts the encryption applied by the DAD to the script (for example, Bluetooth encryption). In step 578 the communications module 86 forwards the script to the MCU 32, which (in step 580) reads a header on each script. In this embodiment, the header indicates that the intended recipient of the script is the DTPU 30, so the MCU 32 commences a loop 581 in which each APDU is forwarded (in step 582) to the DTPU 30 and (in step 584) a response APDU or R-APDU is returned to the MCU.

[0915] In step 586, the MCU 30 checks that the number of C-APDUs matches the number of R-APDUs. The MCU also checks the status words (also called status bytes) in the R-APDU. If an error occurs that requires action by the cardholder, an appropriate error message is sent to a graphical user interface (not shown). If there is no error, the MCU 30 records the installation in a table stored in the MCU and generates an acknowledgement which indicates the script has been executed successfully. The acknowledgement is forwarded all the way back to the DPD manager 36 in the following order: step 588 (MCU 32 to communications module 86), step 559 (communications module 86 to mobile application 60), step 592 (mobile application 60 to DAD gateway 48), step 594 (DAD gateway 48 to DPD manager gateway 46), and step 596 (DPD manager gateway 46 to DPD manager 36). In step 598, the DPD manager 36 analyses the acknowledgement to determine whether the script was executed correctly.

Initial Set-Up of the DTC Through Pre-Provisioning in the Factory

[0916] In an alternative embodiment, the initial set-up phase of provisioning is performed in a factory (referred to as pre-provisioning) before the DTC is distributed to a cardholder in the field. The process of performing the initial set-up phase in the factory will now be described.

[0917] FIG. 14 is a sequence diagram illustrating an embodiment of a process for loading the firmware update into the MCU 30. The firmware update is the same as that described with reference to FIG. 11, but in FIG. 14 the update is installed in the factory instead of in the field. Again, the MCU has pre-installed bootstrap firmware prior to installing the firmware update. In embodiments, the bootstrap firmware is capable of communication using a transport layer security (TLS) cryptographic protocol.

[0918] The process begins with step 608: the DPD manager 36 prepares a firmware update, encrypts the update, and bundles the encrypted firmware update with an installation command. In an embodiment, PKI encryption is used to encrypt the firmware update. In step 610 the DPD manager 36 forwards the firmware update and installation command to the DPD manager gateway 46 which then forwards the firmware update and command (in step 612) to a perso bureau 600. In step 614, the perso bureau 600 (which has possession of the DTC at this point and has powered up the DTC) loads the firmware update and installation command into the MCU 32. In step 616, the bootstrap firmware in the MCU 32 decrypts and installs the firmware update, then in step 618 the MCU sends an acknowledgement of the installation and a firmware version identifier back to the perso bureau 600. In step 620, the perso bureau 600 forwards the acknowledgement and firmware version identifier to the DPD manager gateway 46 which then (in step 622) forwards the acknowledgement and firmware version identifier to the DPD manager 36. In step 624, the DPD manager 36 analyses the acknowledgement and firmware version identifier to determine whether the firmware was loaded correctly.

[0919] In embodiments, the transmissions in steps 610, 612, 620, 622 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

[0920] Once the MCU firmware update has been installed, the MCU is ready to receive and store other information related to the operation of the MCU in the field, including: an application selection script (for subsequent relocation to the OSE 80), Bluetooth encryption keys (for subsequent relocation to a Bluetooth module 90, if one is present), a TLS certificate or one or more FQDN (for subsequent relocation to a WiFi module 88, if one is present). A process for loading such information into the MCU and will now be described. The process follows the same steps shown in FIG. 14 and will therefore be described with reference to FIG. 14, but it will be understood that the information loaded into the MCU is different.

[0921] In step 608, the DPD manager 36 prepares a data package which includes a data payload and a header. In an embodiment, PKI encryption is used to encrypt the data payload. In another embodiment, the payload is encrypted using AES or another type of suitable symmetric encryption. In another embodiment, the data package is a script which contains a header and APDUs with encrypted payloads.

[0922] In step 610, the DPD manager 36 forwards the data package to the DPD manager gateway 46 which then forwards the data package (in step 612) to the perso bureau 600. In step 614, the perso bureau 600 (which has possession of the DTC at this point and has powered up the DTC) loads the data package and into the MCU 32. In step 616, the MCU 32 processes the data package. For example, the MCU may relocate the data package (according to headers in the data package) to a different component on the DTC, such as the OSE 80, secure memory 84, or the communications module 86. In step 618, the MCU sends an acknowledgement of the installation back to the perso bureau 600. In step 620, the perso bureau 600 forwards the acknowledgement to the DPD manager gateway 46 which then forwards the acknowledgement (in step 622) to the DPD manager 36. In step 624, the DPD manager 36 analyses the acknowledgement to determine whether the information was loaded was loaded successfully.

[0923] FIG. 15 illustrates an embodiment of a pre-provisioning process which sets up the OSE 80 as part of the initial set-up phase in the factory. The process loads one or more scripts (containing APDUs) into the OSE 80 where the script is executed. In an embodiment, the one or more scripts, when executed by the OSE, trigger one or more of the following items to be installed on the OSE: a hierarchy of SSDs, keys for the SSDs in the hierarchy, a template store 82 containing script templates, an applet 81 arranged to access the script templates in the template store, and keys for an SSD of the application selection module.

[0924] The process in FIG. 15 begins with step 628: the DPD manager 36 generates one or more scripts which, when executed on the OSE, trigger installations in the OSE (for example, as mentioned, the installation of a hierarchy of SSDs and keys, a template store 82 containing script templates, an applet 81 arranged to access the script templates, and keys for an SSD of the application selection module). Each script contains a header and APDUs with encrypted payloads. The header includes information which indicates that the intended destination of the script is the OSE 80. In an embodiment, the format of the APDUs is in accordance with the SCP02 protocol.

[0925] In step 630 the DPD manager 36 forwards each script to the DPD manager gateway 46 which then forwards each script (in step 632) to the perso bureau 600. In embodiments, the transmissions in steps 630, 632, 644, 646 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS. In step 634, the perso bureau 600 (which has possession of the DTC at this point and has powered up the DTC) loads each script into the MCU 32 which then reads a header on each script and (in step 636) forwards the script to the OSE 80. Is step 638, the OSE 80 executes the script, which triggers the installations on the OSE. The OSE 80 generates a R-ADPU to acknowledge the installation and the R-ADPU is forwarded in step 640 to the MCU 32. The MCU 32 forwards the R-ADPU (in step 642) to the perso bureau 600, which forwards the R-ADPU (in step 644) to the DPD manager gateway 46, which in turn forwards the R-ADPU (in step 646) to the DPD manager 36. In step 648, the DPD manager 36 analyses the R-ADPU to determine whether the installations were completed successfully.

[0926] FIG. 16 illustrates an embodiment of a pre-provisioning process which sets up the DTPU 30 as part of the initial set-up phase in the factory. The DTPU also includes a CASD which has been installed onto the DTPU prior to performing this process. The process depicted in FIG. 16 transmits one or more scripts to the DTPU 30, where the script is executed. In this embodiment, the DTPU 30 is operable to accept provisioning directly via the five contact pads in the contact plate 34 (shown in FIGS. 5A and 5B), without routing each script via the MCU 32, which is unlike provisioning the OSE 80 in the factory (shown in FIG. 15) and also unlike provisioning the DTPU in the field (shown in FIG. 13). In other embodiments of provisioning the DTPU 30 in the factory (not illustrated), the DTPU 30 is operable to accept provisioning via the MCU 32.

[0927] In an embodiment, the one or more scripts provisioned to the DTPU are operable to trigger the DTPU to make the following changes: install a hierarchy of SSDs and keys in the DTPU, install an application selection module in the DTPU, and install one or more containers in the DTPU. These changes can be considered part of the initial set-up phase of provisioning. The one or more scripts could be combined into a single script or could be split into more scripts which are loaded separately and executed. Alternatively, a subset of these scripts can be transmitted to the DTPU while the DTC is in the factory and the other scripts can be transmitted to the DTPU while the DTC is in the field. In an embodiment, the scripts transmitted to the DTPU while the DTC is in the factory are: scripts to install a security domain hierarchy in the DTPU, scripts to install an application selection module in the DTPU, and scripts to load one or more containers into the DTPU (other scripts are loaded into the DTPU in the field). In another embodiment, the scripts transmitted to the DTPU while the DTC is in the factory are: scripts to install a security domain hierarchy in the DTPU, and scripts to install an application selection module in the DTPU (other scripts are loaded into the DTPU in the field).

[0928] The process in FIG. 16 begins with step 652: the DPD manager 36 generates one or more scripts which, when executed on the DTPU, trigger installations in the DTPU (for example, as mentioned, a hierarchy of SSDs and keys, an application selection module, and one or more containers). Each script contains a header and APDUs with encrypted payloads. The header includes information which indicates the intended destination of the script is the DTPU 30. In an embodiment, the format of the APDUs is in accordance with the SCP02 protocol.

[0929] In step 654 the DPD manager 36 forwards each script to the DPD manager gateway 46 which then forwards each script (in step 656) to the perso bureau 600. In step 658, the perso bureau 600 loads the encrypted script into the DTPU 30 where it is executed (in step 660). The DTPU 30 generates an R-APDU to acknowledge the installation(s) and the R-APDU is forwarded in step 662 to the perso bureau 600, which forwards the R-APDU (in step 664) to the DPD manager gateway 46, which in turn forwards the R-APDU (in step 666) to the DPD manager 36. In step 668, the DPD manager 36 analyses the R-APDU to determine whether the installations were completed correctly. In embodiments, the transmissions in steps 654, 656, 664, 666 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

[0930] There are a number of ways in which the perso bureau 600 can transfer digital objects to the MCU, OSE and DTPU. Provisioning to the MCU 32 can occur in a number of ways: via the contact plate 34, via NFC, via Bluetooth, and via WiFi, depending on whether the DTC is equipped for NFC/Bluetooth/WiFi. In the embodiments in FIGS. 14 and 15, the perso bureau 600 communicates with the MCU 32 via contact plates on the DTC. In alternative embodiments in which the perso bureau 600 communicates with the MCU 32 via Bluetooth, NFC or WiFi, all communications between the perso bureau 600 and the MCU are relayed to the MCU by a suitable communications module on the DTC, for example a Bluetooth module, an NFC module or a WiFi module. In an embodiment, provisioning to the OSE 80 is via the MCU which routes digital objects from the MCU to the OSE (communications between the MCU and OSE 80 are via a serial interface).

[0931] In an embodiment, provisioning to the DTPU 30 occurs via the MCU which routes digital objects from the MCU to the DTPU. In an alternative embodiment, provisioning to the DTPU occurs via contact plate 34 on the DTC (as shown in FIGS. 5A and 5B) in accordance with ISO7816 (power can be supplied to the DTPU via a smartcard reader).

[0932] The role performed by the perso bureau 600 in steps 614, 618, 634, 642, 685 and 682 could alternatively be performed by another party at a different stage of manufacture of the DTC, for example an assembly factory for the DTC. If steps 614, 618, 634, 642, 685 and 682 are performed during manufacture before the electronic components have been laminated, communications with the MCU 32 can be via pins which directly contact parts of the circuitry that interface with the MCU. An advantage of performing this process during assembly is that an external power supply can be used to power the MCU (by applying contact pins to the exposed electronic components) which avoids using a battery on the DTC.

Provisioning in the Field to Install a New Personality

[0933] FIGS. 17 to 22 illustrate an embodiment of a process for installing a new personality on the DTC while the DTC is in the field. FIG. 17 shows an overview of the process and FIGS. 18 to 22 show aspects of the process in more detail.

[0934] Referring to FIG. 17, the process of installing a new personality begins when a cardholder 674 uses a mobile application 60 on a DAD to request (in step 678) that a specific new personality be added to the DTC. For example, the installation of the new personality may give the DTC the new ability to conduct transactions with a payment scheme that was not previously available to the DTC. In step 680, the mobile application 60 forwards the cardholder's request to the DPD manager 36, which forwards the request (in step 682) to a TSM/TSP 38, which in turn forwards the request (in step 684) to an issuer 18 (or another party acting on behalf of the issuer). The issuer 18 responds by sending (in step 686) a request to the cardholder 674 to verify and authenticate the cardholder's request. The request sent to the cardholder in step 686 can be sent in a number of ways, according to the cardholder's preferred contact method, for example via a push notification sent to an issuer's app on the DAD 14 via a remote notification service 22 (shown in FIG. 1) or via SMS, email or postal mail. The cardholder's verification and authentication is transmitted (in step 688) back to the issuer 18 which approves the request and sends the approval (in step 690) to the TSM/TSP 38, which in turn forwards the approval (in step 692) to the DPD manager 36.

[0935] Dashed lines in steps 696, 698, 700, 702, 704, 706, 710, 712, 718, 720 indicate that a number of intermediate steps have been omitted and these steps only show end points of the transmissions. The omitted intermediate steps are shown in FIGS. 18 and 19 and described below.

[0936] Referring to step 696 in FIG. 17, the DPD manager 36 generates a script which, when executed on the DTPU, installs a container for a selected payment scheme on the DTPU. The DPD manager 36 transmits the script (in step 696) to the DTPU 30. The DTPU executes the script, and in step 698 a R-ADPU is transmitted from the DTPU 30 back to the DPD manager 36. The details of steps 696-698 are described below with reference to FIGS. 18 and 19. In some embodiments, a container for the selected payment scheme is pre-provisioned and installed on the DTC in the factory, in which case the DPD manager does not perform step 696 and the response in step 698 does not take place either. The DPD manager 36 maintains a register which contains, amongst other things, the history of previous container installations on the DTC. If the register of the DPD manager indicates that a suitable container has previously been installed on the DTC for the selected payment scheme, then the DPD manager will not transmit a script to install such a container on the DTPU in step 696.

[0937] In step 700, the DPD manager 36 generates a script which, when executed on the DTPU, installs a new SSD and associated key in the security hierarchy on the DTPU. The new SSD is associated with the selected PDTP. The DPD manager 36 transmits the script to the DTPU 30 where it is executed, and in step 702 a R-ADPU is transmitted from the DTPU 30 back to the DPD manager 36. The details of steps 700-702 are described below with reference to FIGS. 18 and 19.

[0938] Referring to step 704 in FIG. 17, the DPD manager 36 generates a script which, when executed on the DTPU, installs a new DTP in the new SSD (which was created in step 700), and then transmits the script to the DTPU 30. The DPD manager 36 transmits the script (in step 704) to the DTPU 30. The DTPU executes the script, and in step 706 a R-ADPU is transmitted from the DTPU 30 back to the DPD manager 36. The details of steps 704-706 are described below with reference to FIGS. 18 and 19.

[0939] Referring to step 708 in FIG. 17, the DPD manager 36 notifies the TSM/TSP 38 that the scripts transmitted in steps 696, 700, and 704 have been successfully executed on the DTPU. In step 710, the TSM/TSP 38 transmits to the DTPU 30 a script which, when executed on the DTPU, rotates the key in the new SSD (the SSD and key were installed in step 700). The key rotation replaces the existing key with a symmetric key held by the TSM/TSP 38 and uses a CASD in the DTPU. The DTPU executes the script, and in step 712, R-APDUs are transmitted from the DTPU 30 to the TSM/TSP 38. The details of steps 710-712 are described below with reference to FIGS. 18 and 19.

[0940] Referring to step 714 in FIG. 17, the TSM/TSP 38 sends a request to the issuer 18 to personalise the new DTP (which was installed on the DTPU in steps 700-702). In step 716, the issuer 18 transmits to the TSM/TSP 38 a script which, when executed on the DTPU, personalises the new DTP. In step 718, the TSM/TSP 38 transmits the script to the DTPU 30. The DTPU executes the script, and in step 720 a R-ADPU is transmitted from the DTPU 30 to the TSM/TSP 38. The details of steps 718-720 are described below with reference to FIGS. 18 and 19.

[0941] In step 722, the TSM/TSP 38 sends an acknowledgement to the issuer 18 that the personalisation has been completed successfully. In step 724, the TSM/TSP 38 also sends an acknowledgement to the DPD manager 36 that the personalisation has been completed successfully, then the DPD manager 36 forwards the acknowledgement (in step 726) to the mobile application 60. In step 728, the issuer 18 also sends an acknowledgement to the mobile application 60 that the personalisation has been completed successfully and thereby notifies to the cardholder. Alternatively, or in addition, the issuer 18 can notify the cardholder through other channels about the successful personalisation, for example via SMS, email, a push notification to the mobile device, or through a different app such as a banking app.

[0942] As mentioned, steps 696, 700, 704, 710, 718 and 720 involve generating scripts. Each generated script contains a header and APDUs with encrypted payloads. The header includes information which indicates that the intended destination of the script is the DTPU 30. In an embodiment, the format of the APDUs is in accordance with the SCP02 protocol.

[0943] In an embodiment (not illustrated), the process in FIG. 17 includes additional steps in which the issuer 18 and/or TSM/TSP 38 transmit a notice to the cardholder to indicate that data is available to be downloaded and installed on the DTC. The notice can be transmitted to the mobile application 60 before or during the provisioning process shown in FIG. 17, such as prior to step 696 and/or step 710. Such a notice enables the cardholder to ensure that the DAD is in data communication with the DTC (for example, via Bluetooth), the DAD has sufficient battery power, and the mobile application 696 is set into a provisioning mode. In an embodiment, the action of setting the mobile application 696 into provisioning mode triggers a process in which the mobile application sends a command to the MCU (on the DTC) to do a number of things: stand by to receive a download (for example via Bluetooth), indicate on a display of the DTC that the DTC is ready to receive an update, and send a response to the mobile application 696 to confirm that these things have been done. The mobile application can then send an acknowledgement back to the DPD manager 36 or issuer 18 to indicate the mobile application has been set to provisioning mode and the DTC ready to receive a download.

[0944] As mentioned above, steps 696, 698, 700, 702, 704, 706, 710, 712, 718 and 720 in FIG. 17 only show the end points of those transmissions for simplicity. FIGS. 18 and 19 show two example processes that fill in the intermediate steps not shown in these steps.

[0945] Referring to FIG. 18, a first process 734 contains an embodiment of intermediate steps not shown in steps 696, 698, 700, 702, 704, and 706 of FIG. 17. The first process 734 begins with step 735 in which the DPD manager 36 generates a script (for execution on the DTPU) which contains a header (generated by the DPD manager) and APDUs with encrypted payloads, for example in accordance with the SCP02 protocol. In step 736, the DPD manager 36 forwards the script to the DPD manager gateway 46, which forwards the script (in step 738) to the DAD gateway 48 on the cardholder's DAD. The role of the DAD gateway 48 is to communicate with the provisioning network on behalf of the mobile device. In step 740, the DAD gateway 48 forwards the script to the mobile application 60, which encrypts the script (in step 742), for example using a Bluetooth encryption protocol. Alternatively, the encryption in step 742 could be performed by the DAD gateway 48 instead of the mobile application 60. In step 744, the mobile application 60 transmits the encrypted script to a communications module 86 on the DTC. The first process 734 contains a sub-process 746 which is shown in FIG. 19.

[0946] Referring to FIG. 19, the communications module 86 decrypts the Bluetooth encryption in step 750 and then forwards the script (in step 752) to the MCU 32. In step 754, the MCU reads the header in the script (for example, TLV data or tag-length-value data) which includes information that indicates the script is to be installed on the DTPU 30. The MCU 32 then begins a loop 764 containing steps 756-758. In step 756, the MCU forwards each script (with indicates the DTPU is the intended recipient) to the DTPU 30. Each script contains a command DTPU or C-DTPU. In step 758, the DTPU executes each C-APDU and sends a response-APDU or R-APDU back to the MCU. In step 760, the MCU checks that the number of C-APDUs matches the number of R-APDUs. In step 762, the MCU checks the status words (also called status bytes) in the R-APDU. If an error occurs that requires action by the cardholder, an appropriate error message is displayed (in step 766) on a display screen 83A (for example, as in FIG. 5A). If there is no error, the MCU sends an acknowledgement (in step 768) to the communications module 86 to indicate that the script has been executed successfully.

[0947] Referring now to FIG. 18, the first process 734 continues, starting with step 770 in which the communications module 86 forwards the acknowledgement to the mobile application 60. The acknowledgement is forwarded all the way to the DPD manager 36 in the following steps: step 772 (mobile application 60 to DAD gateway 48), step 774 (DAD gateway 48 to DPD manager gateway 46), and step 776 (DPD manager gateway 46 to DPD manager 36). The DPD manager 36 then analyses the acknowledgement to determine whether the script was executed correctly. If not, the DPD manager 36 can initiate a repeat of first process 734.

[0948] A second process 778 in FIG. 18 contains an embodiment of intermediate steps not shown in steps 710, 712, 718, and 720 of FIG. 17. The second process 778 begins with step 779 in which the TSM/TSP 38 generates a script (for execution on the DTPU) containing APDUs with encrypted payloads, for example in accordance with the SCP02 protocol. In step 780 the TSM/TSP 38 forwards the script to the DPD manager 36. The DPD manager 36 creates a modified script which includes the original script (provided by the TSM/TSP 38) and also includes a header (generated by the DPD manager 36). The header includes information which indicates the script should be forwarded to the DTPU 30 on the DTC. In step 782, the DPD manager 36 forwards the modified script to the DPD manager gateway 46, which forwards the modified script (in step 784) to the DAD gateway 48, which in turn forwards the modified script (in step 786) to the mobile application 60. In step 788, the mobile application 60 encrypts the received script, for example using a Bluetooth encryption protocol. In step 790, the mobile application 60 transmits the encrypted script to the communications module 86. The second process 778 contains the same sub-process 746 described above and shown in FIG. 19. Once the sub-process 746 has been completed, the process then continues in FIG. 18, starting with step 792 in which the communications module 86 forwards the acknowledgement to the mobile application 60. The acknowledgement is forwarded all the way to the TSM/TSP 38 in the following order: step 794 (mobile application 60 to DAD gateway 48), step 796 (DAD gateway 48 to DPD manager gateway 46), step 798 (DPD manager gateway 46 to DPD manager 36) and finally step 800 (DPD manager 36 to TSM/TSP 38). In step 800, the TSM/TSP 38 analyses the acknowledgement to determine whether the script was executed correctly. If not, the TSM/TSP 38 can initiate a repeat of second process 778.

[0949] In embodiments, the transmissions in steps 736, 738, 774, 776, 780, 782, 784, 796, 798, 800 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

[0950] The installation of a new personality on the DTC also includes a process for installing metadata in two places: a) the MCU on the DTC, and b) a DAD in data communication with the DTC. The metadata contains information associated with the new personality being installed. In an embodiment, the metadata includes: the scheme name, the issuer name, the cardholder's name, an AID list for the transaction applications of a PDTP associated with the personality, the full PAN, the last four digits of the full PAN, the expiry date, and the CVV. At least some of the metadata can be displayed to the cardholder on the DTC and/or the DAD to indicate the personality which is currently active. The cardholder may also generate their own metadata, for example the cardholder's nickname for a personality. In one embodiment, the mobile application 60 is arranged to capture the cardholder's nickname and store it on the DAD and/or the DTC. In another embodiment, the cardholder's nickname can be recorded via a cardholder-accessible website portal which communicates the nickname to the DPD manager 36.

[0951] Referring to FIG. 20, the metadata for the new personality is provided by the TSM/TSP 38 and transmitted in step 812 to the DPD manager 36. In step 814, the DPD manager 36 identifies a first subset of metadata 888 (shown in FIG. 21) within the received metadata and encrypts the first subset 888 with a first key and applies a header (generated by the DPD manager 36). Also in step 814, the DPD manager 36 identifies a second subset of metadata 890 (shown in FIG. 21) within the received metadata and encrypts the second subset with a second key and applies a header (generated by the DPD manager 36). In an embodiment, AES encryption is used in step 814, but any suitable method of encryption may be used. In this embodiment, the first subset of metadata 888 (encrypted with the first key) comprises scheme name, issuer name, cardholder name and AID list, and the second subset of metadata 890 (encrypted with the second key) comprises the full PAN, the last four digits of the full PAN, expiry date and CVV.

[0952] In step 816, the DPD manager 36 prepares two packages of encrypted metadata, each with a header (for example, TLV data) and including first and second subsets of metadata 888, 890. One package is for use by the DAD 14 and the other package is for use by the MCU 32. Each header in the metadata package includes information indicative of the intended destination of each metadata package (the MCU or the DAD).

[0953] In step 818, the DPD manager 36 transmits both packages of metadata to the DPD manager gateway 46. Steps 814-818 are performed by a content management system which forms part of the DPD manager 36.

[0954] In step 820, the DPD manager gateway 46 forwards both packages of metadata to the DAD gateway 48. In step 822, the DAD gateway 48 also applies encryption to the packages of encrypted metadata (for example, a Bluetooth encryption protocol), generates a checksum and then (in step 824) forwards the packages of encrypted metadata to the mobile application 60.

[0955] Referring now to FIG. 22 (which continues the process in FIG. 20, starting directly after step 824), in step 840 the mobile application 60 forwards the packages of metadata to the communications module 86 on the DTC. The communications module 86 then performs a number of functions in steps 842-854. In step 842 the communications module 86 decrypts the encryption applied in step 822 (for example, Bluetooth encryption). In step 844, the communications module 86 temporarily disables the DTC from receiving communications from outside the DTC (to prevent the communications module 86 being accessed in the next step while it holds keys). In step 846 the communications module 86 retrieves a copy of a first key (for example, an AES key) from a storage location on the DTC, and in step 848 the communications module 86 retrieves copy of a second key (for example, an AES key) from the same storage location. The storage location may for example comprise the MCU 32 or a separate secure memory on the DTC. The first key is capable of decrypting the encryption applied to the first subset of metadata (in step 814, FIG. 20), and the second key is capable of decrypting the encryption applied to the second subset of metadata (also in step 814).

[0956] In step 850, the communications module 86 uses the first stored key to decrypt the first subset of metadata, and in step 852 the communications module 86 uses the second stored key to decrypt the second subset of metadata. In step 854, the communications module 86 uses the header(s) accompanying the metadata to determine which metadata should be routed to the MCU, and in step 856 the metadata is forwarded to the MCU 32. In step 858, the MCU 32 responds by commanding the communications module 86 to delete the copies of the first and second keys that were retrieved in step 846, and in step 860 the communications module 86 sends an acknowledgement of the deletions to the MCU 32. In step 862, the MCU 32 commands the communications module 86 to reboot in order to clear the buffers and re-enable external communications to be received again, and in step 864 the communications module 86 sends an acknowledgement (of the successful reboot) to the MCU 32.

[0957] In step 866, the MCU 32 stores the received metadata in an MCU registry 35 on the DTC in a way that identifies the first and second subsets of metadata (the first and second subsets of metadata initially identified in steps 814-816). FIG. 21 shows an embodiment of the metadata stored in MCU registry 35. In this embodiment, the metadata is stored as a table in which a first column 888 of the table contains the first subset of metadata and comprises scheme name, issuer name, cardholder name and AID list. A second column 890 of the table contains the second subset of metadata and comprises the full PAN, the last four digits of the full PAN, expiry date and CVV. A third column 892 in the table is other metadata not included in the first and second subsets of metadata, and in this embodiment the third column 892 comprises a nickname (generated by the cardholder) associated with the personality. In step 868, the MCU registry 35 sends an acknowledgement to the MCU 32 that the metadata has been successfully stored.

[0958] In step 870, the MCU 32 uses headers (which accompanied the metadata received in step 856) to identify a metadata package (including metadata 888, 890) to be sent to the mobile application 60, and in step 870 the metadata package is forwarded to the communications module 86, which then forwards the metadata package to the mobile application 60. In step 874, the metadata package is installed in the mobile application 60. In step 876, the mobile application 60 sends an acknowledgement to the communications module 86 that the metadata package has been installed, and in step 878 the acknowledgement is forward to the MCU 32. The MCU 32 combines this acknowledgement with the acknowledgement received previously in step 868 (from the MCU registry 35). The combined acknowledgements are forwarded in a chain of communications to the TSM/TSP 38 in the following order: step 880 (MCU 32 to communications module 86), step 882 (communications module 86 to mobile application 60), step 884 (mobile application 60 to DPD manager gateway 46), and finally step 886 (DPD manager gateway 46 to DPD manager 36).

[0959] In embodiments, the transmissions in steps 812, 818, 886 are encrypted in accordance with a suitably secure cryptographic protocol, for example TLS.

Sequence Diagrams for Adopting a Personality while in the Field

[0960] FIGS. 23-24 illustrate an embodiment of a process which enables a cardholder of the DTC, while in the field, to select and activate one or more of a plurality of personalities installed on the DTC without the DTC communicating with a provisioning infrastructure 10 or provisioning network 16. The process in FIG. 23 contains sub-process 920 which is illustrated in FIG. 24.

[0961] Referring to FIG. 23, the process for selecting and activating a personality begins in step 900 when a cardholder 674 uses the display screen 83A (FIG. 5A) to browse the personalities currently installed on the DTC. The available personalities are represented on the display screen 83A by one or more items of metadata associated with each personality. An embodiment of metadata associated with a personality is shown in FIG. 21. In an embodiment, the metadata displayed on the display screen 83A is the payment scheme name, bank name and last four digits of the PAN, and logo for the payment scheme (the logo is not included in the embodiment of metadata shown in FIG. 21).

[0962] In step 902, the cardholder 674 selects one (or more) personality to be activated and the selection is recorded by the MCU 32. In this embodiment, the DTC 12 is operable to simultaneously have multiple active personalities. The MCU registry stores rules regarding which personalities are permitted to be simultaneously active, and the MCU refers to these rules before proceeding with a personality change. If the rules do not permit the requested personality change, the MCU 32 displays a message on the graphical display screen 83A to indicate that the personality change cannot proceed. In another embodiment, when a cardholder requests a new personality to be activated, the DTC 12 is operable to de-activate any other personality that the rules do not permit to be simultaneously active with the selected personality. In such an embodiment, the MCU 32 can be operable to request confirmation from the cardholder before proceeding to de-activate a personality. In another embodiment, the rules specify that only one personality can be active at any time.

[0963] In step 904, if the rules permit the requested personality change, the MCU 32 looks up the metadata stored in MCU registry 35 and identifies the metadata associated with each selected personality. The metadata for each personality contains AID information which specifies an AID for each transaction application of a PDTP associated with each selected personality. The MCU 32 uses the metadata to generate a list of AIDs associated with each selected personality.

[0964] In step 906, the MCU 32 sends a command (which contains the list of AIDs for the selected personality) to the script applet 81 to generate at least one script which, when executed by the application selection module 225 on the DTPU 30: de-activates all PDTPs on the DTPU, activates a PDTP associated with the selected personality, and sets the application selection module 225 with AIDs for the selected personality. The script generated in step 906 is equivalent to three scripts described earlier: script 207 shown in FIG. 8 (for cascade locking), script 213 shown in FIG. 9 for (targeted unlocking), and script 203 shown in FIG. 7 (for setting AIDs on the application selection module 225).

[0965] In step 908, the script applet 81 requests a script template from the template store 82 (which is stored on the OSE), and in step 910 the template store 82 returns the requested script template to the script applet 81. In step 912, the script applet 81 fills the script template with values to create a script. The created script is in the form of APDUs and derived from: AIDs for contact transaction applications associated with the selected PDTP(s), and AIDs for contactless transaction applications associated with the selected PDTP(s).

[0966] In step 914, the script applet 81 generates a session key using SSD key 104 (which is stored in the OSE 80), and a counter value associated with a targeted SCP02 keyset in the DTPU 30. The SSD key 104 stored in the OSE 80 is a copy of a key held by SSD 96 in the DTPU 30. As shown in FIGS. 8-9, the SSD 96 is a parent to the application selection module 225 in the security hierarchy. The purpose of the session key is to authenticate the script against the SSD 96 so that the script can be executed by the application selection module 225. The script applet 81 uses the session key to encrypt the payloads of the APDUs, for example in accordance with SCP02.

[0967] In step 916, the script applet 81 forwards the authenticated script to the MCU 32, which in step 918 forwards the authenticated script to the application selection module 225 in the DTPU. The next steps (sub-process 920) occur on the DTPU and are shown in FIG. 24.

[0968] Referring to FIG. 24, in step 948 the authenticated script is authenticated against SSD 96. In step 950, the script is passed to the PSE selection application 222 which is part of the application selection module 225. In step 952, the PSE selection application 222 uses GlobalPlatform Global lock privilege to execute a “Lock and Associated” command (as shown in FIG. 8) against the Lock SSD 206 which causes all PDTPs on the DTPU to be inoperable. In step 954, there is an acknowledgement that the Lock SSD 206 has been locked.

[0969] Steps 958 and 960 are a loop 956 in which the PSE selection application 222 processes the script (generated in steps 912, 914), reads the AIDs for contact transaction applications, and uses GlobalPlatform Global lock privilege to unlock (as shown in FIG. 9) each contact transaction application 940 associated with the AIDs. Step 960 is an acknowledgement of each transaction application 940 being unlocked. The loop 956 repeats until all contact transaction applications associated with AIDs in the script are unlocked.

[0970] Steps 964 and 966 are a loop 962 in which the PSE selection application 222 processes the script (generated in steps 912, 914), reads the AIDs for contactless transaction applications, and uses GlobalPlatform Global lock privilege to unlock (as shown in FIG. 9) each contactless transaction application 942 associated with the AIDs. Step 966 is an acknowledgement of each transaction application 940 being unlocked. The loop 962 repeats until all contactless transaction applications associated with AIDs in the script are unlocked.

[0971] In step 968, if the list of AIDs for contact transaction applications is empty, then the PSE selection application 222 is disabled. Otherwise, if the list of AIDs for contact transaction applications is not empty, then in step 770 the PSE selection application 222 is set with the AIDs of contact transaction applications that have been successfully unlocked (as shown in FIG. 7).

[0972] In step 972, the PSE selection application 222 initiates an update of the PPSE selection application 224. In step 974, if the list of AIDs for contactless transaction applications is empty, then the PPSE selection application 224 is disabled. Otherwise, if the list of AIDs for contact transaction applications is not empty, then in step 976 the PPSE selection application 224 is set with the AIDs of contactless transaction applications that have been successfully unlocked. In step 978, an acknowledgement is returned to the PSE selection application 222.

[0973] In step 980, the PSE selection application 222 uses GlobalPlatform Global lock privilege to unlock the Lock SSD 206, and in step 982 an acknowledgement is returned to the PSE selection application 222.

[0974] Referring to FIG. 23, the process continues with step 922 in which the application selection module 225 sends an acknowledgement (in the form of R-APDUs) to the MCU 32. In step 924, the MCU 32 checks the status words (also called status bytes) in the R-APDUs. If an error occurs that requires action by the cardholder, the MCU 32 displays an appropriate error message on the display screen 83A. In step 926, if the status words do not indicate an error, the MCU 32 updates the MCU registry 35 (not shown in FIG. 23) with the activation states of AIDs for contact and contactless transaction applications. In step 928, the MCU 32 updates the display screen 83A with information to indicate that the new personality has been activated. Finally, in step 930, the cardholder checks the display to confirm that the new personality has been activated as expected.

Further Embodiments of a Security Hierarchy on the DTPU

[0975] FIG. 10 illustrates another embodiment of a security hierarchy 241 suitable for hosting a plurality of personalities and for adopting a personality from the plurality of personalities while the DTC is in the field. Where the features are the same as those in FIG. 7, the same reference numerals have been used. In the embodiment in FIG. 10, Bank 1 has only one SSD 228, and this SSD is a parent to three PDTPs (230, 232, 234). Bank 2 also has only one SSD 236 which is a parent to two PDTPs (238, 240). This embodiment has fewer SSDs than in FIG. 7 but the PDTPs can be locked and unlocked using the same process illustrated in FIGS. 8-9. Cascade locking of the Lock SSD 206 causes all associated SSDs (228, 236) to be locked, and all associated PDTPs (230, 232, 234, 238, 240) to be inoperable. The application selection module 225 is operable to activate a targeted PDTP as described above with reference to FIGS. 8-9.

[0976] FIG. 25 illustrates another embodiment of a security hierarchy 251 suitable for hosting a plurality of personalities and for adopting a personality from the plurality of personalities while the DTC is in the field. In this embodiment, the PDTPs and associated SSDs are arranged in a flatter hierarchy than in the embodiments in FIGS. 7-9 and 10. Each PDTP is a child of an SSD which is a child of the Lock SSD 206 in the security hierarchy. “Bank 1” has three SSDs 252, 254, 256 are associated with (or are “children” of) Lock SSD 206 and “Bank 2” has two SSDS 258, 260 which are associated with the Lock SSD 206. Bank 1 and Bank 2 would each use their own SP-TSM to perform operations on the DTPU.

[0977] Each SSD of Bank 1 is a parent to a single PDTP 262, 264, 266 and each SSD of Bank 2 is a parent to a single PDTP 268, 270. Cascade locking (of the Lock SSD 206) causes all child SSDs (252, 254, 256, 258, 260) to be locked, and all associated PDTPs (262, 264, 266, 268, 270) to be inoperable. The application selection module 225 is operable to activate a targeted PDTP as described above with reference to FIGS. 8-9.

[0978] FIG. 26 illustrates another embodiment of a security hierarchy 281 suitable for hosting a plurality of personalities and for adopting a personality from the plurality of personalities while the DTC is in the field. In this embodiment, the DTC hosts seven personalities associated with three banks (Bank 1, Bank 2, Bank 3) and three payment schemes (Visa, Mastercard, American Express) and each bank uses the services of a TSP to perform operations on the DTPU: [0979] a TSP for Visa accounts has control of SSD 280 and associated SSDs (286, 290, 294) and associated PDTPs (288, 292, 296); [0980] a TSP for Mastercard accounts has control of SSD 282 and associated SSDs (298, 302) and associated PDTPs (300, 304); and [0981] a TSP for American Express accounts has control of SSD 284 and associated SSDs (306, 310) and associated PDTPs (308, 312).

[0982] As in the embodiments shown in FIGS. 7-9 and 10-25, cascade locking of the Lock SSD 206 in FIG. 26 causes all associated SSDs (280, 286, 290, 294, 282, 298, 302, 284, 306, 310) to be locked, and all associated PDTPs (288, 292, 296, 300, 304, 308, 312) to be inoperable. The application selection module 225 in FIG. 26 is operable to activate a targeted PDTP as described above with reference to FIGS. 8-9.

[0983] FIG. 27 illustrates another embodiment of a security hierarchy 313 suitable for hosting a plurality of personalities and for adopting a personality from the plurality of personalities while the DTC is in the field. In this embodiment, the DTC hosts ten personalities associated with four banks (Bank 1, Bank 2, Bank 3, Bank 4) and three payment schemes (Visa, Mastercard, American Express). Bank 1, Bank 2 and Bank 3 use the services of a TSP to perform operations on the DTPU, while Bank 4 would use its own SP-TSM to perform operations on the DTPU: [0984] a TSP for Visa accounts has control of SSD 280 and associated SSDs (286, 290, 294) and associated PDTPs (288, 292, 296); [0985] a TSP for Mastercard accounts has control of SSD 282 and associated SSDs (298, 302) and associated PDTPs (300, 304); [0986] a TSP for American Express accounts has control of SSD 284 and associated SSDs (306, 310) and associated PDTPs (308, 312); and [0987] an SP-TSM for Bank 4 has control of SSD 314 and associated SSDs (316, 320, 324) and associated PDTPs (318, 322, 326).

[0988] Cascade locking of the Lock SSD 206 causes all associated SSDs (280, 286, 290, 294, 282, 298, 302, 284, 306, 310, 314, 316, 320, 324) to be locked, and all associated PDTPs (288, 292, 296, 300, 304, 308, 312, 318, 322, 326) to be inoperable. The application selection module 225 is again operable to activate a targeted PDTP as described above with reference to FIGS. 8-9.

[0989] Throughout this specification and the claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” and “comprising”, will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

[0990] The reference to any prior art in this specification is not and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.