DISABLING A DIGITAL PAYMENT DEVICE (DPD)
20220020000 · 2022-01-20
Inventors
Cpc classification
H04L9/0838
ELECTRICITY
H04L2209/56
ELECTRICITY
H04L9/3234
ELECTRICITY
H04L9/0897
ELECTRICITY
G06Q20/3263
PHYSICS
H04L9/0877
ELECTRICITY
H04L63/20
ELECTRICITY
G06Q20/227
PHYSICS
H04W12/35
ELECTRICITY
H04W12/47
ELECTRICITY
G06Q20/341
PHYSICS
International classification
Abstract
A Digital Transaction Processing Unit (DTPU) operable to host one or more transaction applications, each transaction application for digitally transacting with a Digital Transaction Device (DTD), the DTPU further operable to be reversibly placed into a disabled state such that the DTPU is inoperable for a digital transaction with a DTD.
Claims
1. A Digital Transaction Processing Unit (DTPU) operable to host one or more transaction applications, each transaction application for digitally transacting with a Digital Transaction Device (DTD), the DTPU further operable to be reversibly placed into a disabled state such that the DTPU is inoperable for a digital transaction with a DTD.
2. A DTPU in accordance with claim 1, wherein the DTPU is operable to be reversibly placed into the disabled state while in the field remote from a provisioning agent.
3. A DTPU in accordance with claim 1, wherein the DTPU is operable to be reversibly placed into the disabled state while in the field remote from a provisioning agent and while disconnected from intercommunication with the provisioning agent.
4. A DTPU in accordance with claim 1, wherein, when the DTPU is in the disabled state, each one of the one or more transaction applications is locked such that it is inoperable for a digital transaction with a DTD.
5. A DTPU 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.
6. A DTPU in accordance with claim 1, wherein the DTPU is included on a Digital Payment Device (DPD) operable for a digital transaction.
7. A DTPU in accordance with claim 5, wherein each hosted PDTP is associated with a corresponding personality hosted at least in part by the DPD.
8. A DTPU in accordance with claim 6, wherein the DPD includes an Operational Secure Element (OSE) for generating and/storing one or more scripts.
9. A DTPU in accordance with claim 6, wherein the DPD includes a Micro Controller Unit (MCU) for operating the DTPU to execute the one or more scripts.
10. A DTPU in accordance with claim 8, wherein the DTPU, upon execution of the one or more scripts, is operable to be reversibly placed into an enabled state, such that the DTPU is operable for a digital transaction with a DTD.
11. A Digital Transaction Processing Unit (DTPU) operable to host one or more transaction applications, each transaction application operable for digitally transacting with a Digital Transaction Device (DTD), the DTPU being operable to be reversibly placed into a dummy enabled state such that the DTPU is operable for a dummy digital transaction with a DTD.
12. A DTPU in accordance with claim 11, wherein the DTPU is operable to be reversibly placed into the dummy enabled state while in the field remote from a provisioning agent.
13. A DTPU in accordance with claim 11, wherein the DTPU is operable to be reversibly placed into the dummy enabled state while in the field remote from a provisioning agent and while disconnected from intercommunication with the provisioning agent.
14. A DTPU in accordance with claim 11, wherein at least one of the one or more transaction applications is a dummy transaction application.
15. A DTPU in accordance with claim 14, wherein, when the DTPU is in the dummy enabled state, the at least one dummy transaction application is unlocked such that it is operable for a dummy digital transaction with a DTD.
16. A DTPU in accordance with claim 14, wherein, when the DTPU is in the dummy enabled state, each of any other transaction application different from the at least one dummy transaction application is locked such that each of any other transaction applications is inoperable for a digital transaction with a DTD.
17. A DTPU in accordance with claim 11, wherein, when the DTPU is in the dummy enabled state, the DTPU is operable to provide dummy transaction information to the DTD, the dummy transaction information being associated with a dummy transaction application.
18. A DTPU in accordance with claim 17, wherein the dummy transaction information includes one or more of a dummy primary identifier associated with a dummy transaction application, a dummy tokenised primary identifier associated with a dummy transaction application, a dummy expiry date associated with a dummy transaction application.
19. A DTPU in accordance with claim 18, wherein the primary identifier is a Personal Account Number (PAN).
20. A method of hosting one or more transaction applications on a Digital Transaction Processing Unit (DTPU), each transaction application for digitally transacting with a Digital Transaction Device (DTD), wherein the method comprises: configuring the DTPU to be reversibly placed into a disabled state such that the DTPU is inoperable for a digital transaction with a DTD.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0700]
[0701]
[0702]
[0703]
[0704]
[0705]
[0706]
[0707]
[0708]
[0709]
[0710]
[0711]
[0712]
[0713]
[0714]
[0715]
[0716]
[0717]
DETAILED DESCRIPTION OF SOME EMBODIMENTS
[0718]
[0719] 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.
[0720] 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.
[0721] 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.
[0722] 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.
[0723] 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.
[0724] 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
[0725] Referring to
[0729] 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.
[0730] 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.
[0731] 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.
[0732] The DTC 12 includes a user interface 83A, 83B which can be used by a cardholder to select one of the personalities or transaction applications 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.
[0733] 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 associated 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.
[0734] In an embodiment, a personality is installed on the DTC 12 by providing various digital objects to the DTC. In at least some embodiments of the invention, the DTC 12 includes security arrangements to accept digital objects only from an authorised provider. Such security arrangements include being operable to check the authenticity of any digital objects to be installed. In an embodiment, digital objects associated with a personality installation are provided by a provisioning infrastructure 10 with suitable encryption and authentication protocols. An embodiment of a provisioning infrastructure 10 is described below.
[0735] In the following description of embodiments of the invention, the DTC is operable to host one or more personalities and to adopt a personality from the one or more personalities. The invention also includes embodiments in which the DTC is operable to host a personality associated with one or more transaction applications.
[0736] Referring to
[0737] 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
[0738] The MCU 32 is operable to perform various operations on the DTC 12, including: 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, reading and writing information to and from the secure memory 84, and managing the user interface 83A, 83B. The MCU 32 is also used during a process of provisioning the DTC 12, in which a personality or other functionality is installed on the DTC 12. Provisioning can occur while the DTC 12 is in a factory before distribution to the cardholder, or in at least some embodiments, when the DTC is physically remote from a provisioning infrastructure 10 (shown in
[0739] 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 supplementary 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 an ISD of the DTPU, at least one 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.
[0740] 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 distribution to a cardholder.
[0741] 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.
[0742] In at least some embodiments, the DTC is operable to simultaneously have multiple personalities in an active state. 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 license) 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 of the personalities are operable to 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.
[0743] 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.
[0744] 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 key(s) 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
[0745] 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.
[0746] 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.
[0747] In the embodiment depicted in
[0748] Referring to
The Communications Module of the DTC
[0749] At times, the DTC may need to be provisioned with digital objects from a provisioning infrastructure 10 (described below with reference to
[0750] 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
[0751] In an embodiment, 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.
[0752]
[0753] The contact plate 34 depicted in
[0754] 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.
[0755] The same communication links shown in
Metadata
[0756] 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.
[0757]
[0758] 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
[0759] 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.
[0760] 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.
[0761] 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.
[0762] 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.
[0763] 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.
Interactions with a Payment Network
[0764] Referring to
Embodiment of a Security Hierarchy
[0765]
[0766] 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.
[0767] 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
[0768] 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: [0769] SSD 242 is a parent to PDTP 230 for a Bank 1 Visa personality; [0770] SSD 244 is a parent to PDTP 232 for a Bank 1 Mastercard personality; [0771] SSD 246 is a parent to PDTP 234 for a Bank 1 American Express personality.
[0772] 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.
[0773] “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: [0774] SSD 248 is a parent to PDTP 238 for a Bank 2 Visa personality; [0775] SSD 250 is a parent to PDTP 240 for a Bank 2 Mastercard personality.
[0776] 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.
[0777] 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
[0778] 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
[0779] 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
[0780] 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.
[0781] 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.
[0782] 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.
[0783] 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.
[0784] 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.
[0785] 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.
[0786] 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
[0787] 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
[0788] In an alternative embodiment, script 203 is provided by the provisioning infrastructure 10 (shown in
[0789] 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.
[0790] 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
[0791] 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.
[0792] In an embodiment of a locking process illustrated in
[0793] a) locks (makes inactive) SSD 206,
[0794] b) locks all SSDs associated with (children of) the SSD 206 in the hierarchy, and
[0795] c) locks all transaction applications associated with (children of) the locked SSDs.
[0796] 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.
[0797] 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.
[0798] 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).
[0799] 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.
[0800] 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.
[0801] 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
[0802] 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
[0803] 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
[0804] 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
[0805] 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).
[0806] 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.
[0807] 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
[0808] 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
[0809] 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.
[0810] 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.
[0811] 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.
Unlocking a Targeted Transaction Application
[0812] In an embodiment, the process for unlocking a targeted transaction application is the same as the process described above for activating a targeted PDTP, except an individual transaction application is targeted instead of a group of transaction applications associated with a PDTP. Unlocking a targeted transaction application directly after a cascade locking process results in only the targeted transaction application being selectable in a transaction.
Disabling the DTC
[0813] There may be circumstances in which it is desirable to disable the DTC 12 to the extent that transactions cannot be performed with a DTD. In an embodiment, the DTC 12 is operable to be disabled in a factory and distributed to a cardholder in the disabled state, and thereafter enabled for normal operation. In another embodiment, the DTC is operable to be disabled in the field, for example: when the DTC is not in use, when unauthorised activity occurs on the DTC, prior to a provisioning event commencing, after a provisioning event, when a provisioning event has not been completed successfully, or when the DTC is lost or stolen.
[0814] In one embodiment of the DTC, the DTC 12 is operable to de-activate all PDTPs (lock all transaction applications) on the DTPU 30, such that the DTC is inoperable for transactions with a DTD. The de-activation is effected after the DTPU 30 executes at least one disabling script to de-activate all PDTPs. The MCU 32 is operable to provide the at least one disabling script to the DTPU 30. In an embodiment, the disabling script is generated by the script applet 81 using the method described above for generating script 207 (shown in
[0815] In another embodiment, the DTC is operable to lock all contact transaction applications but leave at least one contactless transaction application unlocked, making the DTC disabled for contact transactions but enabled for contactless transactions. In another embodiment, the DTC 12 is operable to lock all contactless transaction applications but leave at least one contact transaction application unlocked, making the DTC enabled for contactless transactions but operable for contactless transactions.
[0816] In another embodiment, the DTC is operable to de-activate the application selection module 225. In an embodiment, the DTC 12 is operable to set the application selection module 225 with an empty AID list such that, in a transaction, it generates an empty candidate list. The de-activation is effected after the DTPU 30 executes at least one disabling script to set the application selection module 225 with an empty AID list. The MCU 32 is operable to provide the at least one disabling script to the DTPU 30. In an embodiment, the disabling script is generated by the script applet 81 using the method described above for generating script 203 (shown in
[0817] In another embodiment, the DTC 12 is operable to de-activate the application selection module 225 by locking the PSE selection application 222 and the PPSE selection application 224, making them inoperable in a transaction with a DTD. In another embodiment, the DTC 12 is operable to lock only the PSE selection application 222, making it inoperable in a contact transaction, and in another embodiment the DTC 12 is operable to lock only the PPSE selection application 224, making it inoperable in a contactless transaction. De-activating the application selection module 225 (or parts of it) is effected after the DTPU 30 executes at least one disabling script, for example a script which targets SSD 96 to lock the PSE selection application 222 and/or the PPSE selection application 224.
[0818] In another embodiment, the DTC 12 is operable to de-activate all PDTPs and to at least partially de-activate the application selection module 225.
[0819] In another embodiment, the DTPU 30 includes a dummy PDTP which is associated with at least one dummy transaction application. Each dummy transaction application, when unlocked, is inoperable for a transaction with a DTD and may be treated by the DTD as an invalid transaction application. The DTC 12 is operable to activate the dummy PDTP and de-activate any other PDTP, thereby placing the DTD into a “dummy enabled” state which is inoperable to conduct normal transactions with a DTD. In an embodiment, the dummy PDTP is associated with metadata for the dummy PDTP, such as the metadata in
[0820] A command to disable the DTC 12 could come from an external party while the DTD is in a factory before distribution to a cardholder (for example in a perso bureau), or while the DTD is in the field. For example, while the DTC is in the field, a command to disable the DTC 12 could come from a manager of the DTC (for example a DPD manager 36 shown in
[0821] In another embodiment, the DTC 12 is operable to be disabled while in the field and without intercommunication with an external party. In an embodiment, rules for disabling the DTC (disabling rules) are stored in the MCU. In one embodiment, the disabling rules specify that the DTC 12 should be disabled after a pre-determined period of time has elapsed since completion of the last transaction (for example, after a month, a week, a day, an hour, a second). In another embodiment, the disabling rules specify that the DTC 12 should be disabled if certain unauthorised activity takes place (for example, too many rejected transactions, too many failed attempts to authenticate the cardholder). In another embodiment, the disabling rules specify that the DTC 12 should be disabled prior to a provisioning event commencing, after a provisioning event has been completed, or when a provisioning event has not been completed successfully.
[0822] In an embodiment of the DTC 12, the MCU 32 is operable to maintain the disabled DTC 12 in a disabled state until a valid passcode is received by the MCU, for example via the keypad 83B. In an embodiment, such a passcode is supplied by the DPD manager 36 to the cardholder in another channel, for example by text message or email. In an embodiment, the MCU is operable to compare the entered passcode with a passcode stored on the DTC, for example in the MCU 32, OSE 80 or secure memory 84. Once the MCU 32 receives a valid passcode that matches the stored passcode, the MCU is operable to provide a script (generated by the script applet 81) to the DTPU 30 which activates an active personality. In an embodiment, MCU 32 is operable to re-set the stored passcode after the cardholder enters a valid passcode. The re-set stored passcode is supplied by the provisioning infrastructure 10.
Sequence Diagrams for Adopting a Personality while in the Field
[0823]
[0824] Referring to
[0825] 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.
[0826] 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.
[0827] 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
[0828] 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).
[0829] 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
[0830] 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
[0831] Referring to
[0832] 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
[0833] 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
[0834] 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
[0835] 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.
[0836] 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.
[0837] Referring to
Sequence Diagrams for Adopting a Transaction Application while in the Field
[0838] Referring again to
[0839] Referring to
[0840] In step 902, the cardholder 674 selects one or more transaction application to be unlocked and the selection is recorded by the MCU 32. In this embodiment, the DTC 12 is operable to simultaneously have multiple unlocked transaction applications. The MCU registry stores rules regarding which transaction applications are permitted to be simultaneously unlocked, and the MCU refers to these rules before proceeding to unlock transaction applications. If the rules do not permit the requested unlocking of transaction applications, the MCU displays a message on the display screen 83A to indicate that the request cannot proceed.
[0841] In step 904, if the rules permit the requested unlocking of one or more transaction applications, the MCU 32 looks up the metadata stored in MCU registry 35 and identifies the metadata associated with each selected transaction application. The metadata contains an AID for with each selected transaction application. The MCU 32 uses the metadata to generate a list of AIDs associated with the selected transaction application(s).
[0842] In step 906, the MCU 32 sends a command (which contains the AID for each selected transaction application) to the script applet 81 to generate a script (which includes at least one command) which, when executed on the DTPU, locks all transaction applications on the DTPU and then unlocks each selected transaction application as described above with reference to the security hierarchy in
[0843] In step 914, the script applet 81 generates a session key using SSD key 104 (stored in the OSE 80, as shown in
[0844] Referring to
[0845] 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 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.
[0846] 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 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.
[0847] 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.
[0848] 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.
[0849] 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.
[0850] Referring to
Further Embodiments of a Security Hierarchy on the DTPU
[0851]
[0852]
[0853] 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
[0854]
[0858] As in the embodiments shown in
[0859]
[0864] 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
Provisioning Infrastructure
[0865]
[0866] 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 license). For example, the issuer 18 may be a financial institution or a party with a banking license. 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.
[0867] 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.
[0868] 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).
[0869] In the embodiment shown in
[0870] 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
[0871]
[0872]
[0873]
[0874] 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.
[0875] 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.
[0876] 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.
[0877] 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 digital wallet on a mobile device, 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.
[0878] In the embodiment in
[0879] 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 64. 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.
[0880] 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.
[0881] In the embodiments shown in
[0882] 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.
Some DAD Component Details and Mobile Application Setup
[0883] In the embodiment shown in
[0884] 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.
[0885] 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.
[0886] 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).
[0887] 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.
[0888] In the embodiment shown in
[0889] In the embodiment shown in
[0890] 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, 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.
[0891] 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, 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. 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.
[0892] 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.
[0893] 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.