TW202105226A - Security hierarchy on a digital transaction processing unit - Google Patents

Abstract

A Digital Transaction Processing Unit (DTPU) operable to host one or more transaction applications for digitally transacting with a Digital Transaction Device (DTD), the DTPU including a security hierarchy for hosting the one or more transaction applications, wherein the security hierarchy is configured to host at least one transaction application for transacting in contact digital transactions.

Description

Security Architecture of Digital Transaction Processing Unit

The present invention relates to a digital payment device (Digital payment device, DPD). In at least some specific embodiments, the present invention relates to methods of constructing or operating DPD.

In at least some specific embodiments, the present invention can be applied to be able to host credit cards, debit cards, mobile payment cards or non-payment cards and/or documents (including authorizations, ID cards, passports, and the like)物) DPD. In at least some specific embodiments, the present invention can also be applied to a DPD operated in conjunction with a digital assistance device (DAD) (such as a smart phone).

Credit cards, debit cards, and other types of physical cards or physical documents usually include a magnetic stripe that stores information about the following: ● The card or file; ● The holder of the physical card/document; ● The institution that has issued the physical card/document; and ● Other information, including card/document ID (such as Personal Account Number (PAN)), expiration date, and name of the card/document holder.

A physical credit/debit card usually also has the cardholder's name, the card expiration date, and the PAN imprinted or printed on the card, and may also include other security devices, such as a hologram. This physical credit/debit card can be used for transactions using digital transaction devices (DTD), such as automatic teller machines (ATM), point-of-sale (POS) terminals, and point-of-sale electronics Electronic Funds Transfer at Point-Of-Sale (EFTPOS) terminal, where the digital transaction devices can read the magnetic stripe when the user swipes the magnetic stripe or inserts the physical card into the device.

Some DTDs can use non-payment physical cards or file operations to implement non-payment digital transactions, including passport readers, age verification card readers, and the like.

Recently, physical cards, physical documents, and other devices (such as watches and other wearable devices) have integrated circuit chips that can store some of the same (or similar) information as the magnetic stripe, together with other information, and enhance security, and Has an improved identifier coded in the chip. The chips in these cards can be called Secure Element (SE). The card information stored in the SE can be regarded as the digital representation of the card or document, and is sometimes called a digital card. A physical card with SE can be called a chip card. SE is sometimes referred to as a financial chip with sufficient hardware security issued by financial institutions.

SE usually includes a central processing unit (Central Processing Unit, CPU), read only memory (Read Only Memory, ROM), random access memory (Random Access Memory, RAM), electronically erasable programmable read-only memory One or more of the system (Electrically Erasable Programmable Read Only Memory, EEPROM), a cryptographic co-processor, and an input/output (Input/Output, I/O) system. In some SE chips, part of the memory (sometimes called user memory or tamper-proof user memory) is reserved for storing applications and data specific to the cardholder and the operations required by the digital card .

The chip card (and the SE on it) may be able to be used for contact transactions, and includes a contact piece on the surface of the chip card, which is connected to communicate with the SE on the chip card. Contact transactions involve inserting the chip card (also known as "Dip") into a DTD with complementary contacts that can communicate with the chip card contacts. Contact transactions are regulated by the EMVCo standard. The chip card can also be used for contactless transactions when the SE is connected to the antenna and the DTD has a corresponding antenna, so that the SE and DTD can communicate via short-distance wireless communication when the chip card is close enough to the DTD ( Near Field Communication (NFC) is a part of and compatible with ISO/IEC_14443 communication. Some payment devices are in the form of wearable payment devices (such as watches), which have no contact strips and can only be used for contactless payment transactions. Many chip cards (such as credit or debit cards) are operable for both contact and contactless digital transactions. Some chip cards have a magnetic stripe with payment information encoded on it, together with SE.

In many scenarios, the SE hosts a single payment application that complies with the EMVCo standard. This SE may be known as a Europay/Mastercard/Visa (EMV) chip. In this description of the prior art, for chip cards and other chip devices configured for payment transactions, the term SE should be understood to include SE, which can be operated to host a payment application that complies with the EMVCo standard. A payment application can also be called an applet, a Java card application (Cardlet), an application, or a payment instance. The payment application is usually hosted in the user memory of the SE, for example, in the EEPROM of the chip.

Some SEs only implement the firmware layer, where all required card and customer details are encoded. Recently, more SEs (or SE/EMV) are configured to host operating systems that control various operations of the SE. In some such SEs, the operating system conforms to a set of standards called Global Platform (GP) card specification standards (which will be referred to as GP or GP standards), and this SE can also be operated to host payment applications that comply with the EMVCo standard. MULTOS is another operating system standard for chip credit and SE on debit cards. The SE with a MULTOS-compliant operating system is also used to host EMVCo-compliant payment applications.

Some public transportation travel cards include an SE, which operates for contactless digital transactions. Some documents (such as passports) may include an SE, which can be read by a device through a contactless transaction. This non-payment transaction SE is generally not operable to host EMVCo-compliant applications. However, this SE can host an operating system that complies with the GP standard or the MULTOS standard.

During the creation of the chip card, the cardholder-specific information (such as the cardholder’s name, PAN, and other detailed information) is known to be Personalized programs are written in the SE. This information is sometimes referred to as personalised information. Generally, the personalization of the SE involves writing the personalization data into the payment application (which has been previously instantiated in the SE). In other scenarios, the personal-specific data is written into a memory location that the SE can access through the payment application.

Personalization usually includes one or more types of personalization, each of which can be completed in different stages. The main types of personalization are: ● Electric personalization: it is carried out during the supply period, and the application code, user information (such as the cardholder’s name, PAN, and other detailed information), and password key (used to create a transaction password) are loaded In the SE, it is locked upon completion so that no further changes can be made, and the detailed information specific to the individual is forwarded to the issuer. Data is written into the magnetic stripe (if the card has one); and ● Personalization of graphics: the printing or embossing of text or pictures on the chip card and associated carrier products.

Generally, a personally-specific payment application includes a digital card, which is in the SE of a chip card.

In many SEs, GP commands/procedures are used when installing payment applications from payment solutions (such as Mastercard, Visa, or American Express), along with other aspects of digital cards, such as from issuer to chip card. The information assigned to the customer on the SE, including the PAN, has detailed information on the issuer.

Until recently, the SE in the chip card can only be operated by a single digital card type (and usually by a single payment application) in a single payment solution. For example, the Digital Transaction Card (DTC) can be operated as a Mastercard Credit card, Mastercard debit card, Visa credit card, Visa debit card, or American Express credit card, but cannot be operated by two or more digital card types and/or payment plans.

In an SE that contains financial-compliant hardware (with sufficient physical security to meet standards) and hosts an operating system that meets GP standards, each application on the SE (including payment applications) has an associated unique application identifier (Application IDentifier, AID). Each AID is a registered application provider IDentifier (Registered application provider IDentifier, RID) issued by the ISO/IEC 7816-5 registration authority, and the exclusive application provider that enables the application provider to distinguish the different applications provided It is composed of Proprietary Application Identifier eXtension (PIX). The AID can also be referred to as the name of the Application Definition File (ADF).

The communication with the SE chip is realized through the interface of transmitting Application Protocol Data Unit (APDU). These APDUs include command APDUs and response APDUs. APDU is used to communicate with SE's operating system that conforms to the GP standard. It is sometimes called GP standard command and GP standard response, sometimes called GP command and GP response, or sometimes simply called command and response. APDU is also used for communication between the SE and DTD (under ISO 7816, EMVCo, and other standards), but is different from the APDU used for GP commands/responses.

For some digital payment transactions, the physical card (whether chip card or only magnetic stripe card) does not need to be presented, and only selected detailed information from the card is provided to enable the transaction. This transaction includes Internet transactions and Mail Order/Telephone Order (MOTO) transactions. For example, in a payment transaction, the cardholder provides detailed information through the phone (via an automated system or to personnel) or via a secure Internet portal. The detailed information usually includes the chip card's PAN, the card holder The name of the card holder, the expiration date of the card, the Card Verification Value (CVV), and other security information.

The security of payment transactions is a major concern, as there have been many instances of fraudulent transactions by stealing physical cards/documents or stealing physical or digital card/document details. The credit/debit card can also have a CVV (or CVC on the magnetic stripe), which can make it more difficult to copy the card for fraudulent purposes.

For a magnetic stripe card (or a chip card with a magnetic stripe), the CVC is usually a password established based on the card data (for example, including the card's PAN and expiration date and a bank's master key). The bank’s authorized host re-establishes the CVC value by using the bank’s key to determine whether it complies with the CVC sent during the transaction. The CVC is printed on the card after entering the personalized data on the card and storing it in the magnetic stripe.

Thereafter, the same principle is applied to another CVC sometimes called Card Verification Value 2 (CVV2), which is usually printed in the signature box on the back of the card. The CVV2 is mainly used to help ensure the security of e-commerce and Internet or MOTO transactions. This is the second unique password created from the card data and the bank's master key (although this is a different password compared to the magnetic stripe CVC). The CVV2 is not present on the magnetic stripe.

Generally, a card issuer that issues a chip card with an SE installs a cryptographic key on it in order to generate a symmetric cryptographic key in the SE, which is used during card communication with the DTD to generate a password for digital transactions (such as Transaction Certificate (TC)). The passwords (or TCs) to sign the transaction are derived from information interacting with the SE on which the key is installed.

Many chip cards are operated by the Cardholder Verification Method (CVM), for example, only the Personal Identification Number (PIN) (as specified in many regions) known to the cardholder(s), It must be kept secret and must be entered on a secure and authenticated terminal to verify that the person is the authorized cardholder. Depending on the configuration of the issuer, the PIN may be stored in the SE for offline verification. The PIN can be stored locally in a secure tamper-proof memory (ie, the SE). Other chip cards with CVM may have biometric security means (Means), such as a fingerprint reader.

SE is usually provided by the manufacturer, with multiple containers for different payment schemes. Containers are sometimes called libraries, elementary load files (ELF), or packages. For example, three containers including Visa, Mastercard, and American Express can be provided to SE. These containers are usually in the ROM of the SE. Generally, due to the needs of the personalization period, in addition to the container that is used for the payment application hosted on the SE of the chip card, the container representing the payment solution is installed on a single digital card (the personal-specific payment application). After becoming effective, it is prohibited or becomes invalid during the personalization process. The container provides a series of functions for the payment application to be called when the transaction is implemented through the DTD. In some implementations, the container is a library of functions or classes (for example, in JavaCard).

Some financial-compliant SEs with operating systems that comply with the GP standard adopt a security class based on the GP standard for the management of the content of these SEs. The security hierarchy includes a tree diagram of security domains, including an Issuer Security Domain (ISD), which has the highest authority and controls the content and operations in the entire SE. The security hierarchy may also include one or more Supplementary Security Domains (SSD), each of which has subsidiary permissions and controls a subset of the content and operations of the ISD. This level may also include one or more SSDs attached to a higher SSD. Each security domain is implemented using an application with its own AID. The SE can have several levels, but there is only one ISD.

Each security domain can have an associated key (usually a symmetric key), where a copy of the key is stored in the corresponding security domain application, and another copy of the key is owned by the security domain The entity (or agent) is kept (or under its control).

The ISD key used for each SE can be a unique derivative of the master key owned by the issuing authority, and the master key of the issuing authority can be used to ensure the security of many SEs. The ISD key is generated by the issuing agency of the SE and installed on it, so that the issuing agency has control over the ISD of the SE. The ISD may be passed from the issuing agency to another entity, so the entity has control over the ISD in the SE. In the device, the mobile phone has an SE, and the owner of the ISD key transfers the ISD key to a key management server (Key Management Server, KMS). The SSD key generated by the KMS is installed on the SE. An agent with a key for a specific SSD has control over the SSD.

All ISD keys, SSD keys, and especially the master key are kept secret. Outside the SE, the ISD key and/or SSD key is owned by or under the control of an entity (or agent) that has control over the associated SSD. Otherwise, the ISD key and SSD key are only safely stored in the SE (more specifically, in the security domain applications). The key allows the owner to implement one or more operations on the financial-compliant SE through an operating system that conforms to the GP standard in the security domain associated with the key and based on the privileges assigned to the security domain during installation. When the owner of the key is allowed to perform operations in the security domain, the owner is deemed to be able to authenticate the security domain.

For a financial-compliant SE with an operating system that complies with the GP standard, the operations on the SE are implemented through a command set document (Script). Each command set document contains one or more APDUs. Generally, the instruction set document will be composed to implement one or more operations (one or more commands) on the SE, and may include one or more APDUs for implementing the one or more operations (or commands). Some instruction set documents do not require encryption because they do not need to verify the security domain. Other command set documents need to be secured by the key used in the security domain, so that the command set document can verify the domain. Sometimes the command set document is also encrypted and secured by the key used to verify the security domain. When the instruction set document makes its commands (that is, all its APDUs) implemented on the SE (whether in the security domain or not), this is sometimes referred to as playing or executing the instruction set document. The execution of the command set document includes: establishing a secure session (Session) with the SE (using the session key derived from the security domain key), so as to be able to securely communicate or transmit the command set document to the SE, The target security domain in the SE is verified, and the next step is authorized once transmitted.

Each key set also has a counter, which is incremented (to become the next expected counter value) after each instruction set document verifies the field. The purpose of the counter is to prevent the replay (or re-execution) of the same instruction set document in the field. The derivation of the conversation key includes the counter value, so that when the instruction set document is signed, the signature includes the counter value. If the counter value is incorrect, the derived session key will be incorrect, and the establishment of the secure session will fail. In addition, if the command set document is encrypted, the incorrect session key will not allow decryption.

Sometimes, instruction set documents (such as personalization for payment applications) are not provided outside the card personalization department (Personalization Bureau, Perso Bureau). Instead, all the command set document operations used to instantiate the payment application on the SE of the chip card and the personalization of the payment application (thus becoming the digital card on the SE of the chip card) are in The card personalization department does it (it can be done during the lamination stage of chip card manufacturing or post-lamination in the scheme authentication security area).

SE and the chip cards placed on it have a life cycle containing life cycle states, including: ● Operation ready (OP_READY): indicates that the runtime environment is available, and the ISD used as the selected application should be ready to receive, execute, and respond to APDU commands (instruction set documents); ● Initialization (INITIALIZED): Administrative management card production status. The state transition from OP_READY to INITIALIZED is irreversible. ● Ensure safety (SECURED): The expected operation card (both physical/chip card and digital card in the SE of the physical chip card) life cycle state after issuance. This state can be used by security domains and applications to strengthen their respective security policies. The state transition from INITIALIZED to SECURED is irreversible. ● Card lock (CARD_LOCKED): exists to provide the function of prohibiting the selection of security domains and applications. The transition from SECURED to CARD_LOCKED is reversible. Setting the card to the CARD_LOCKED state means that the card should only allow the application to be selected with the last application privilege. In this state, the card content is not allowed to change, including any type of data management (specifically, security domain keys and data); and ● TERMINATED: Send a letter of the life cycle of the card and the end of the card. The transition from any other state to the TERMINATED state is irreversible. Using this state TERMINATED permanently prohibits all card functions regarding any card content management and any life cycle changes. The status of this card is expected to be a mechanism by which the application program logically (or digitally) "destroy" the card.

Some chip cards have attempted to allow more than one personal magnetic stripe personality to be installed on the chip (usually non-SE, and even if SE is used, it is not configured to host EMVCo-compliant payment applications, and it is not compliant with finance The hardware is not configured to host the SE) of the operating system conforming to the GP standard. In this proposal, the user will select the magnetic stripe card used for the chip card operation (it is different from the digital card because it will be hosted by a financial-compliant SE). These magnetic stripe cards are installed "in the field" on a chip card copied from magnetic stripe track 1 or track 2 data of another physical card. Multiple magnetic stripe cards may include more than one card type from the same payment scheme (for example, a credit card and a debit card from Mastercard), or may include cards of different payment schemes (for example, a Visa debit card and an American Express credit card) Types of. Example products include products from Plassc, Coin, Final, and Wocket. However, the Plassc solution has operational limitations, and the Wocket solution needs to specify a Wocket device. These solutions have not yet gained widespread market acceptance, and some solutions have now ended or ceased operations. A serious problem that caused the failure of this previous solution is that it has not obtained organizational certification (such as EMVCo), so it is not suitable to use the corresponding payment solutions that require EMVCo certification and the DTD operations in payment networks that also need to comply with the EMVCo standard. Another problem faced by this proposal is that the service code includes a need for a specific type of chip, and the DTD must request the use of this type of chip. However, because these cards only have one copy of the magnetic stripe (the magnetic stripe). Bar card), the required type of chip does not exist, which will cause the transaction to fail. In addition, this recommendation does not work because the issuer (who possesses the cardholder's information) cannot be sure that: ● The ISD keys and SSDs of the chip are strictly controlled by only the issuer or the approved agent of the issuer; ● The issuer can use his SSD key (key rotation); ● The card meets all such financial standards; ● The card can hold the information of the issuer and can safely generate the issuer's password; ● The proposed cards can have the information installed in the security card personalization department facility that meets the issuer's specifications; and ● The SE is locked into any other changes by the life cycle of the change in the card personalization department.

Another component for conducting payment transactions is known as a digital wallet. Digital wallets refer to electronic devices and programs used to make payments for digital purchases without showing actual credit cards, debit cards, or cash. One type of digital wallet is a device-based digital wallet implemented on, for example, a smartphone. Digital wallets may also be implemented on wearable payment devices. Examples of device-based digital wallets include Apple Pay and Samsung Pay. Google Wallet (G Pay) and PayPal provide applications (Apps) that can be operated on smartphones. A device-based digital wallet implemented on an NFC-enabled device (such as a smart phone) can be used for contactless card presentation transactions with appropriately configured DTD (contactless terminal). Another type of digital wallet is a digital wallet based on the Internet, which allows users to add credit/debit card information (that is, information that can be obtained from a physical card) to allow the customer to make online purchases. GoogleWallet (used for payment between peers) and PayPal (used for online payment) are examples of digital wallets based on the Internet. Digital wallets are provided by Wallet Service Provider (WSP) to smartphone users (or users of another device or the Internet). Typically, the user will request to create an account and then provide the user with a digital wallet application for downloading to their smartphone.

Digital wallets capable of making contactless payments and/or payments between peers can include several different payment applications for virtual payment cards (such as Visa, Mastercard, American Express) or card types (credit cards, debit cards), which can be called It is a mobile payment card (Mobile Payment Card, MPC) and can be safely stored in the SE (usually eSE or Universal Integrated Circuit Card (UICC) chip) of the smartphone. You can also use some digital wallets to hold other non-payment cards, such as store loyalty cards or gift cards. These MPC and non-payment cards can be collectively referred to as virtual cards (Virtual Card, VC), although non-payment cards are usually not stored in digital wallets or in these more secure areas of the memory on the SE (sometimes called payment cards). Area).

There is a difference between the MPC constructed for the SE used in smartphones or other similar mobile payment devices and the digital card hosted by the SE on a physical (chip) card. The SE (eSE/UICC chip) used for payment devices (such as on a smartphone) is operated by a solution container, where the container can be configured for MPC operations (used for physical/ The digital card in the SE of the chip card must usually be able to make contact and contactless payments). The container is configured to instantiate the application and/or create an instance to fit the physical dimensions of the device (such as a chip card or smartphone) that will store it. The container on the chip card can support applications/instances of contact and contactless cards used in the solution of the container, and the container used for eSE/UICC chips such as those used in, for example, smartphones can only support contactless applications Application/instance of virtual card (or MPC). The container used for this eSE/UICC can be operated by more than one MPC, and the eSE/UICC of this device can be operated by more than one container. Relatively speaking, the solution container used for the SE of the chip card is limited to the compliance of the issued solution of the single digital card with the container of the solution, and all other containers installed on the SE and not containing the qualified digital card are in This personalization procedure is then prohibited or locked.

MPCs (and sometimes VCs or other applications and features) are usually created, managed, and assigned to smartphones by agents, including Trusted Service Manager (TSM) and/or payment certificate code service providers (Token Service Provider, TSP). The TSM/TSP is usually entrusted with the authority to transmit MPC data, including the secure channel used to use the user’s smartphone via the mobile network operator (Mobile Network Operator, MNO) Over-The-Air (Over-The-Air, OTA) Instructions for instantiating the payment application and the cardholder’s personalized data (the instantiation and the personalization are usually carried out by different entities, but both can be TSM). In addition to OTA communication, the TSM/TSP can transmit data via the Internet (Over The Internet, OTI) or via the wire (Over The Wire, OTW) via, for example, DTD. The secure channel is established according to the GP standard protocol, such as Secure Channel Protocol 02 (SCP02), which is a secure dedicated and usually synchronous communication link between the TSM/TSP and eSE/UICC chips on the smartphone .

Recently, another method to help provide MPC has emerged, called Secure Element Management Service (SEMS), such as NXP Loader Service (NXP Loader Service), which uses digital certificates to ensure that data is transferred from the supplier The agent securely transmits to the eSE/UICC chip on the smartphone.

TSM can also receive tokens from payment certificate code service providers (TSP) and other required card information from various parties, and use these to create MPC, which can be downloaded to the cardholder’s smart phone for security The link makes the cardholder available.

There are different TSMs for different roles. Secure Element Issuer (SEI) TSM (also known as Root TSM) manages the operations on the SE of the user’s smartphone or other types of mobile payment devices, including instances of payment applications And the establishment of SSDs; and the service provider (Service Provider, SP) TSM manages the creation and delivery of personalized instruction set documents to the user’s smartphone or other types of mobile payment devices. The SP TSM can be a TSP. In this case, the provided personal-specific instruction set document contains a payment voucher code PAN. In some situations, both the SEI and SP TSM roles can be performed by a single entity.

The TSM/TSP operation is completed by using one or more command set documents issued by the TSM/TSP (which are encrypted by the TSM/TSP with the key used to verify the specific security domain on the eSE/UICC).

Many other operations available in the card personalization department and TSM are not available to others. For example, when a user wants to change the main MPC on his smart phone, the user must connect to, for example, TSM to allow the TSM to perform the required operations through the command set document to change the main MPC in the digital wallet (Then send its secure communication back to the user’s smartphone). This may be difficult if the user is not located where a communication link to the TSM can be established.

As mentioned earlier, the SE is in the CARD_LOCKED state before leaving the card personalization department and cannot currently use the changes. After the SE chip is locked, only the card personalization department with the appropriate SSD key can change the status.

Some smart phone SEs may require a Controlling Authority Security Domain (CASD) in the security hierarchy. The CASD exists to facilitate the trust between the issuer of the SE and the issuer of the MPC to be hosted on the SE. The CASD facilitates the key exchange between the two parties. In particular, the SE (or financial chip) on the chip card has not yet installed CASD.

TSM also assists in the management of, for example, the TSM itself, banks (operating the cardholder’s card account and other accounts), credit/debit card providers (issue the cardholder’s card), and telecommunications companies (providing the cardholder’s mobile network). The end-to-end communication and data transmission between the cardholder’s smart phone and (in the case that the user’s smart phone contains eSE/UICC) are secure.

Key ceremony is a task performed to support some functions of TSM. The key ceremony is a standard process between parties who wish to securely share secrets. Secrets (such as ISD keys and the like) are generally stored in a hardware security module (Hardware Security Module, HSM). In the key ceremony, key managers from different entities enter part of the key into the HSM, which reconstructs the key in the HSM. The keys are created and encrypted inside the HSM (the keys are never unencrypted outside the HSM). Now, the two entities share a secret that can be used to encrypt the secure channel for communicating with the SE.

Provide the SP TSM with the account information (personal-specific data) and convert it into the APDU formatted for eSE/UICC in the smartphone, and then the TSM prepares the personal-specific data (converted into APDU) to For downloading to the smart phone of the cardholder, and sending this to its own HSM to encrypt the APDUs with the conversation keys (such as the SCP02 conversation key) used for the respective SSDs on the SE. The personal information is written into the payment application to become the MPC.

The TSM uses the master key (resident in the HSM) in the Key Management System (KMS) to generate a unique key for the designated SSD in the SE of the smart phone or CDMA phone, and the NFC data package (Including APDU) are encrypted by these unique keys. The encrypted data is transmitted over-the-air (OTA) to, for example, a mobile network operator (MNO) that has also performed a key ceremony. Alternatively, the data can be transmitted via Transport Layer Security (TLS). In addition, the data can also be OTI or OTW transmission, which does not involve MNO.

In the example operation, the MNO transmits the personalized command set document (including metadata to display a card image with the last four digits of the PAN on the display of the mobile phone) to the cardholder Smart phones or other mobile payment devices.

Checks can be performed, including the check of the user's location and the check of device fingerprints (such as those of an SE in a smart phone). This procedure ensures that the bank and MNO know that the information is reliable and deliver it to the correct account holder. The data is decrypted and installed on the smart phone, and then the cardholder can use his smart phone to make card payments. These programs and products of TSM/TSP, as well as its partner banks and telecommunications providers, have so far been restricted from operating within those organizations. For example, the MPCs instantiated and personally dedicated on the SE through the secure end-to-end program can only be available through those organizations and programs. If the cardholder wants to obtain a new MPC or change the operation card on his mobile device, it usually needs to go through the TSM/TSP and partner organizations.

As an alternative to using TSM/TSP, SEMS is used, such as the loader service developed by NXP Semiconductors N.V.. Another example of SEMS was implemented as a service in the recent release of the GP standard. The SEMS installs the container on the SE, but the personalized data used for the instantiated payment instance must still be completed by the SP TSM to establish the MPC.

The NXP loader service was developed to supply wearable payment devices and other smart devices using the Internet of Things (IoT). The NXP loader service requires a chip with the NXP application installed. Or, if you use SEMS from these GP standards, NXP specific applications will not be required.

SEMS is available in a series of NXP chips, and it is pre-configured on the SE as an applet and client. The loader service base entity uses credentials to delegate content management authority. The applet can be loaded on the SE without using the Secure Component Issuer (SEI) TSM. For Android devices, these necessary instruction set documents have been embedded in an Android application package (APK) and can trigger card content management services. For example, these command set documents can create security domains and introduce keys, load and update applets (including payment applications), instantiate and customize the applets, and delete security domains.

Although the convenience of the digital wallet is obvious, each MPC in the digital wallet can only be used for contactless payment (and in some instances, for online payment). Some POS/EFTPOS terminals do not support the required type of contactless payment, and ATM generally does not support contactless transactions. In addition, not all smartphones support NFC or digital wallets, and cannot be used for this transaction with any DTD. Therefore, the establishment and use of digital wallets have experienced limited commercial success.

Therefore, the market in this field continues to urgently need chip cards, such as credit cards and debit cards (that is, in the shape of traditional credit or debit cards, and have such contact pieces and NFC infrastructure of the chip card for contact and contactless transactions) . However, the main disadvantage of chip cards with SE is that they cannot support multiple digital cards in the SE. Each chip card is pre-installed and supplied with a single digital card (which is fixed during the life of the chip card). Users must carry a separate chip card for each digital card they wish to use.

In addition, it is not used to enable the current chip card (or other types of digital payment devices (DPD)) to provide new digital cards (including the instantiation of a new payment application and the personalization of the new payment application) to Everything needed for the chip card, and/or a known method or infrastructure for selecting and activating the individual unique features from a plurality of individual unique features hosted on the chip card. The current method of supplying new digital cards to chip cards (or other types of DPD) is only performed by the issuer in a highly secure environment.

In addition, there is no method or infrastructure for forming a communication link with the chip card currently in use. This chip card has not been operated by mobile payment card (MPC) or will be supplied by trusted service manager (TSM), token service provider (TSP), or secure element management service (SEMS), so there has been no incentive to do so. Even though some chip cards have been suggested to include communication functions, this chip card cannot form a direct or indirect communication link with the supply network (including TSM, TSP, or SEMS). The current method of loading a chip card with a digital card requires that the Perso Bureau has sufficient security to handle the issuer's bank-assisted security (SSD) key, bank password, private information, and account information. In addition, there has never been a method or infrastructure to form a communication link with the chip card currently in use, and there has been no motivation to do so because the chip card has not yet been operated by the MPC. Even though some chip cards have been suggested to include communication functions, this chip card cannot be connected to the supply network (including TSM, wallet service provider (WSP), and TSP, as well as a card issuance, payment, and/or supply network). Other entities, agents, and/or suppliers) to form direct or indirect communication links.

There is also no known method or infrastructure for the chip card used to supply the chip card that is currently in use (that is, away from and not connected to the supply network) to be changed to a different digital card. As mentioned above, the security element (SE) used for the chip card is deliberately placed in the card locked (CARD_LOCKED) state before leaving the card personalization department, so that it cannot be changed at the time of use. Even if the SE is not locked before leaving the card personalization department, it still cannot form a communication link with the chip card currently in use (away from the supply network).

Another problem of some existing and/or some suggested chip cards is that the components and/or methods used to host multiple digital cards or magnetic stripe cards on the SE do not conform to these existing (including previous and/or suggested /Future) Any one of the required standards, such as the GP standard and the EMVCo standard. As such, these existing and/or proposed chip cards will not be able to enter digital transactions with DTD (need to only interoperate with compatible chip cards).

In some smart phones and other types of mobile payment devices that use MPC in digital wallets, another disadvantage is that when users want to change between MPCs (for example, change from the MPC associated with the Mastercard credit card to the Visa transfer card When the associated MPC), the changed procedure usually requires communication between the smartphone and the agent (such as TSM). This may be inefficient for cardholders who wish to quickly change to the MPC of their multi-MPC smartphone. In some scenarios, the smartphone user will be in a location where the agent (TSM or other agents) cannot be contacted, and therefore will not be able to change the smartphone's MPC. In addition, since TSM does not manage contact MPC (or digital cards with contact and non-contact interfaces), cardholders cannot use the TSM to change contact MPC/digital cards.

Currently, there is no chip card with a suitable security level (for hosting and operating a card with multiple digital cards installed on it). In addition, there is no chip card suitable for the security level provided by the Trusted Service Manager (TSM) and/or the Token Service Provider (TSP).

In a first aspect, the present invention provides a digital transaction processing unit (Digital Transaction Processing Unit) operable to host one or more transaction application programs for digital transactions performed by a digital transaction device (DTD). Unit, DTPU), the DTPU includes a security class for hosting the one or more transaction application programs, wherein the security class is configured to host at least one transaction application program for trading by contacting digital transactions.

In a number of specific embodiments, the security layer is further configured to host at least one transaction application for conducting transactions with non-contact digital transactions.

In a number of specific embodiments, the security layer is further configured to host at least one transaction application for conducting transactions with both contactless and contact digital transactions.

In various embodiments, the security hierarchy includes one or more security domains. In some such embodiments, at least one of the one or more security domains is operable as a transaction application security domain for hosting at least one of the one or more transaction applications. In some embodiments, the at least one transaction application security domain is configured to be used by a digital payment device manager, a trust service management platform (TSM), a code service provider (TSP), and a secure component Provide at least one of the Secure Element Manager Service (SEMS).

In various embodiments, the DTPU is further operable to host one or more containers, each transaction application is derived from one of the one or more containers, and the security layer is operable to host the Wait for one or more containers. In some such embodiments, at least one of the one or more security domains is operable as a container security domain for hosting at least one of the one or more containers.

In various embodiments, the DTPU is further operable to host an application selection module operable to provide transaction application identifier information for communicating with the DTD in a digital transaction, the transaction application identifier The information indicates a transaction application that can be operated for digital transactions through the DTD. In some such specific embodiments, each transaction application identifier is an application identifier (AID) of the associated transaction application.

In various embodiments, the DTPU can be operated to reversibly unlock at least one of the one or more transaction applications, so that each at least one unlocked transaction application can operate for digital transactions via the DTD. In some such embodiments, the DTPU is operable to reversibly unlock at least one of the one or more transaction applications when the DTPU is active away from a supply agent.

In various embodiments, the DTPU is operable to reversibly lock at least one of the one or more transaction applications, so that each at least one unlocked transaction application cannot be operated on digital transactions via the DTD. In some such embodiments, the DTPU is operable to reversibly lock at least one of the one or more transaction applications when the DTPU is active away from a supply agent.

In various embodiments, the security hierarchy has a tree structure that includes a first branch that hosts the one or more containers, and the tree structure further includes a second branch that hosts one or Multiple trading applications. In some such specific embodiments, the first branch is a sibling branch (Sible) of the second branch in the tree structure.

In various embodiments, the DTPU can be operated to lock each of the one or more transaction applications by locking a parent (Parent) security domain of the second branch.

In a number of specific embodiments, the one or more transaction applications include at least one first transaction application and at least one second transaction application, and the at least one first transaction application is hosted by a first secure domain. The at least one second transaction application program is hosted by a second secure domain. In some such embodiments, the first security domain is operable to be controlled by only a first party, and the second security domain is operable to be controlled by only a second party.

In a number of specific embodiments, the first security domain is a coherent branch of the second security domain in the tree structure.

In a number of specific embodiments, the security hierarchy has a tree structure and the one or more transaction applications include a plurality of transaction applications, each of which is associated with a master identifier, wherein the information about the same master The transaction application of the identifier is the child of the same security domain, and the transaction application of a different primary identifier is the child of the different security domain. In some embodiments, the primary identifier is a personal account number (PAN).

In various embodiments, the application selection module is managed by the security layer outside the second branch. In some embodiments, the security hierarchy includes a third branch that hosts the application selection module. In a number of specific embodiments, the third branch is a sibling branch of the second branch. In a number of specific embodiments, the third branch is a sibling branch of the first branch.

In various embodiments, the application selection module is hosted by the DTPU outside the security hierarchy.

In various embodiments, the DTPU is included on a digital payment device (Digital Payment Device, DPD) that can be operated for digital transactions via a DTD.

In various embodiments, the one or more transaction applications are associated with one or more Personalized Digital Transaction Package (PDTP), so that each PDTP is associated with at least one corresponding transaction The application is associated, and each PDTP is associated with a corresponding personal characteristic, and the personal characteristic is at least partially managed by the DPD. In some such embodiments, each PDTP is a sub-domain of a security domain different from any one or more of the other PDTPs.

In various embodiments, the DTPU can be operated to disable a selected PDTP by locking a parent security domain of the PDTP, wherein each disabled PDTP cannot be operated for digital transactions via a DTD.

In various embodiments, the DPD includes an operational security element (OSE) for generating one or more instruction set documents (Script).

In various embodiments, the DPD includes an OSE for storing one or more instruction set files.

In various embodiments, the OSE can be operated to store one or more template instruction set documents and the microcontroller unit (MCU) can be operated to provide operating data to the OSE, and the OSE can be operated by The operation data customizes the one or more template command set documents to prepare the one or more command set documents. In some such embodiments, the operation data includes the AID of a selected transaction application to be unlocked.

In various embodiments, the DTPU can be operated to reversibly unlock a selected transaction application after executing the one or more instruction set documents.

In various embodiments, the DTPU can be operated to reversibly lock a selected transaction application after executing the one or more instruction set documents.

In various embodiments, the DPD includes an MCU for operating the DTPU to execute the one or more instruction set documents.

In various embodiments, the one or more transaction application programs include a first transaction application program for conducting financial transactions, and a second transaction application program for conducting other than financial transactions.

In various embodiments, the first transaction application is associated with a payment solution.

In various embodiments, the second transaction application program provides an identity document.

In a further aspect, the present invention provides a digital payment device (DPD), which includes a digital transaction processing unit (DTPU), which is operable to host one or more digital transactions through a digital transaction device (DTD) Multiple transaction applications, the DTPU is according to the first aspect of the present invention.

In a further aspect, the present invention provides a method for hosting one or more transaction application programs on a digital transaction processing unit (DTPU) for digital transactions via a digital transaction device (DTD), the DTPU including a In the security layer hosting the one or more trading applications, the method includes: The security level is configured to host at least one transaction application program used to conduct transactions by contact digital transactions.

In a number of specific embodiments, the method includes: The security level is configured to host at least one transaction application program used for transactions with non-contact digital transactions.

In a number of specific embodiments, the method includes: The security level is configured to host at least one transaction application program for conducting transactions with both non-contact and contact digital transactions.

In a number of specific embodiments, the method includes: One or more security domains are included in the security hierarchy.

In a number of specific embodiments, the method includes: Operate at least one of the one or more security domains as a transaction application security domain for hosting at least one of the one or more transaction applications.

In a number of specific embodiments, the method includes: The security layer hosts one or more containers, and each transaction application is derived from one of the one or more containers.

In a number of specific embodiments, the method includes: Operate at least one of the one or more security domains as a container security domain for hosting at least one of the one or more transaction applications.

In various embodiments, the method includes: the security layer hosting an application selection module operable to provide transaction application identifier information for communicating with the DTD in a digital transaction, the transaction application identifier The symbol information indicates a transaction application that can be operated for digital transactions via the DTD. Technology platform and / or related technology

The invention described in the specification of the present invention is operated in conjunction with a technology platform and/or related technologies including technology and its specific embodiments (which have or may have separate and independent creativity and patentability). The following describes the technical platform and/or related technologies, including the description terminology and some specific embodiments describing the technical platform and/or related technologies.

The description of certain parts of the technology platform and/or related technologies may include and/or contribute to specific embodiments of the present invention.

The description of certain parts of the technology platform and/or related technologies may include and/or help separate specific embodiments of patentable inventions or those separately patentable inventions.

The description of the technology platform and/or related technologies should not be considered prior art. Digital Transaction Processing Unit (DTPU)

In the specification of the present invention, the term digital transaction processing unit (DTPU) is used to indicate a wide range of secure elements (SE) suitable for different specific embodiments of the present invention and in each specific embodiment of its related technology.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is configured to use at least one of a payment personalised digital transaction package (PDTP) and a non-payment PDTP to be managed Digital transactions, operations and/or participation in digital transactions. However, most of the description of the present invention focuses on specific embodiments for payment of PDTP and related operations and constructions. Payment PDTP includes, for example, credit card PDTP, debit card PDTP, gift card PDTP, and travel card PDTP. Non-payment PDTP includes, for example, passport PDTP, age verification document PDTP, and ID PDTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is a financial card SE (sometimes referred to as an EMV chip). In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the DTPU is a UICC or an embedded UICC (eUICC). In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the DTPU is eSE. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of related technologies, the DTPU is an integrated secure element (ISE). In further embodiments of the present invention and/or in further embodiments of related technologies, the DTPU is implemented on the SIM. In still further embodiments of the present invention and/or in still further embodiments of related technologies, the DTPU is implemented on a smart microSD.

It will be understood that the form of the DPD will make some forms of the DTPU more suitable for the DPD than others. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DTPU is modified to suit the form of the DPD. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is a traditional financial card SE or EMV chip that has been modified or reused, and is configured to host more than one DTP/PDTP , Where each DTP/PDTP has one or more trading applications associated with it.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU can be operated to host at least one DTP/PDTP (and its associated one or more transactions) that comply with the EMVCo standard application). Generally, a transaction application that meets the EMVCo standard is a payment application (therefore, the DTP/PDTP is a payment DTP/PDTP).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is configured to host an operating system. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the operating system complies with the GlobalPlaform (GP) standard. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the operating system is a JavaCard conforming to the GP standard. In other embodiments of the present invention and/or in other embodiments of related technologies, the operating system conforms to MULTOS. In some specific embodiments of the present invention and/or in some specific embodiments of its related art, the DTPU (along with other components of the DPD) conforms to the GP card specification.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU complies with the Payment Card Industry (PCI) standard. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the DTPU complies with Common Criteria (CC) protection specifications.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU can be operated to host at least one DTP/PDTP (and its associated one or more transaction applications) that comply with the EMVCo standard Program), and the DTPU is configured to host an operating system that conforms to the GP standard and/or conforms to the JavaCard. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DTPU can be operated to host at least one DTP/PDTP (and its associated one or more transaction applications) that comply with the EMVCo standard Program), and the DTPU is configured to host an operating system that meets the MULTOS standard.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is operable for at least one of contact digital transactions and non-contact digital transactions.

In still other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the DTPU is a universal integrated circuit card (UICC) type chip or an eSE type chip (such as usually used in mobile phones). Used in), where the DPD (especially in the case of the DPD-based DTC) and UICC/eSE are adapted so that the DTC with UICC/eSE (or more generally, the DPD where appropriate) can be contactless and/ Or contact trading. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DTC (or more generally, the DPD where appropriate) is provided to allow the UICC/eSE to conduct contact transactions Components, such as external contact pads for contacting respective pads in the DTD for communication between the DTPU and the DTD, and provide the DTC (or more generally, the DPD where appropriate) with chips and one or more One antenna, or a chip with one or more antennas, allowing the UICC/eSE to conduct contactless transactions. In some of the specific embodiments of the present invention and/or in some of the related technologies, the chip is an external NFC chip operable for card emulation mode, and may be a contactless front end (Contactless front end). , CLF), where the CLF and eSE/UICC communicate via the SWP connection. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, UICC/eSE requires MCU to operate through NFC chip to make the DTC (or more generally, the DPD where appropriate) in ( Card) operate in emulation mode. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the NFC chip includes an antenna. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of related technologies, the DPD includes a Secure Processing Module (SPM), which is used for example via NFC And/or a fully integrated one-module solution for the communication between the DTPU and the outside of the DPU through the contact pads. In a further embodiment of the present invention and/or in a further embodiment of the related art, the SPM is an MCU in the SE. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the SPM includes an SE, a low-power MCU, and a power management integrated circuit (IC). Single chip.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, for contact transactions, the DPD provides components, for example, for communication between the DTPU and the DTD. To contact the contact pads of the respective electrodes in the DTD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the contact pads and/or their arrangement on the DPD complies with ISO7816-2. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD-based DTC is provided with contact pads for contact transactions. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DTC has a form substantially equivalent to a traditional credit/debit card form. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DTC includes 6 contact pads. In some other embodiments of the present invention and/or in some other embodiments of the related art, the DTC includes 8 contact pads.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, for non-contact transactions, the DPD is provided with, for example, chips and antennas for communicating with respective antennas in the DTD (Or chip with antenna) components. In some of the specific embodiments of the present invention and/or in some of the related technologies, adjusting the UICC/eSE for the external dimensions of the physical card includes modifying the height of the UICC/eSE.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU can be provided to the cardholder in a selected life cycle state. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the life cycle state includes: INITIALIZED, SECURED, CARD_LOCKED, and TERMINATED. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DTPU is operable for the LOCKED application lifecycle state. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU can be operated to execute commands, including one or more of the following: SELECT, initial update ( INITIALIZE UPDATE), EXTERNAL AUTHENTICATE, STORE DATA, OP READY. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU (in DPD) is provided in the OP_READY state. In some of the specific embodiments of the present invention and/or in some of the related technologies, the DTPU is provided to the card user in the OP_READY state. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the DTPU (in DPD) is provided in the INITIALIZED state. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the DTPU (in DPD) is provided in the SECURED state. In further specific embodiments of the present invention and/or in further specific embodiments of its related technology, the DTPU (in DPD) is provided in the CARD_LOCKED state, where it can be selectively restored to SECURED state and return to CARD_LOCKED state.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DTPU includes sufficient memory (such as user memory) to allow each payment solution container to install an application program Choose a module, at least one payment solution container, and one or more DTP/PDTP. In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, the application selection module includes a PSE (or contact transaction) selection application and/or a PPSE (or non- Contact transaction) select the application. In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, the application selection module is operable to function in addition to the functions of traditional PSE and/or PPSE applications and/or Its different functions. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the application selection module is installed on the DTPU, where the DTPU has existing PSE and/or PPSE applications, Make the application selection module overwrite the existing PSE and/or PPSE applications. In some other embodiments of the present invention and/or in some other embodiments of related technologies, the application selection module replaces the existing PSE and/or PPSE applications. In some other embodiments of the present invention and/or in some other embodiments of related technologies, the application selection module is adapted to co-exist with the existing PSE and/or PPSE applications. On DTPU, the application selection module has a higher priority than the existing PSE and/or PPSE applications. In some of the specific embodiments of the present invention and/or in some of the related technologies, the application selection module is installed on the DTPU, and the application selection module is adapted to be compatible with the existing PSE and / Or PPSE applications co-exist on the DTPU, and the application selection module has an application for its application that is different from the application identifiers of the existing (including existing standard) PSE and/or PPSE applications Identifier (AID).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is operable to accept a supply (remote or local) from a Trusted Service Management Platform (TSM). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the TSM is in the supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the TSM supply can be synchronized, asynchronous, or selectively synchronized and non-synchronized in the communication between the TSM and the DTPU. Synchronize both operations.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is operable to accept a supply (remote or local) from a payment voucher code service provider (TSP). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the TSP is in the supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the TSP supply can be synchronized, asynchronous, or selectively synchronized and non-synchronized in the communication between the TSP and the DTPU. Synchronize both operations.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU is operable to accept a supply (remote or local) from SEMS services. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the SEMS is in the supply network. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU can be operated by one or both of the NXP SEMS service (loader service) and the GP SEMS service.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the DTPU is operable to accept supplies from: ● Hybrid TSM/SEMS services in the supply network, where the supply of data from the supply network to the DTPU comes from one or both of the TSM and SEMS services; ● And/or a hybrid TSP/SEMS service in the supply network, where the supply of data from the supply network to the DTPU comes from one or both of the TSP and SEMS services; ● And/or the hybrid TSM/TSP service in the supply network, where the supply of data from the supply network to the DTPU comes from one or both of the TSM and TSP services; ● And/or a hybrid TSM/TSP/SEMS service in the supply network, where the supply of data from the supply network to the DTPU comes from any one or more of the TSM, the TSP, and the SEMS service.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, when the supply to the DTPU comes from the TSP, the TSP only provides one payment in order to personalize the DTP into a PDTP Voucher code PAN. It will be understood that traditionally, the TSP is configured to provide several payment voucher codes PAN in place of the main PAN. However, in some of the specific embodiments of the present invention and/or in some of the related technologies, the payment voucher code PAN is not substituted for the main PAN in the personalization of the DTP, but it can be regarded as Personalize the DTP to become the master PAN of the PDTP.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the DTPU is configured to host one or more PDTPs each associated with two or more transaction applications, and Each transaction application program is personalized by a different payment certificate code master identifier (for payment transaction applications, the payment certificate code master identifier is a payment certificate code personal account number or a payment certificate code PAN). In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, the PDTP provided with the payment voucher code transaction application can be referred to as the payment voucher code PDTP. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology for transaction applications, each payment certificate code master identifier (or payment certificate code PAN) is in the transaction application program The personal exclusive period is provided by TSP. In some such embodiments, the two or more payment voucher codes PAN are provided by the TSP during the personalization of the DTP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DTPU is configured to automatically select the PDTP used for the PDTP when the PDTP is selected as the effective PDTP of the DPD One of the PDTP transaction applications associated with the payment voucher code. In some such embodiments, the automatic selection is random or pseudo-random from the range of two or more payment voucher codes PDTP transaction applications. In this other embodiment, the selection is based on the preset sequence of the payment voucher code transaction applications within the range of two or more payment voucher code transaction applications. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, at least one of the two or more transaction applications is personally exclusive by the main identifier, and the The remaining parts of the two or more transaction applications are personalised by the payment voucher code master identifier.

It should be understood that in each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, in the case of using the payment certificate code transaction application, this can be provided to enhance privacy and/or security. , Because, for example, with a payment transaction application, the actual PAN of the transaction application (or the associated PDTP and associated PAN with personal characteristics) is not revealed for digital transactions. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the graphic display of the DPD (if it has a graphic display as required) may only display for payment from the selected The selected token of the voucher code PDTP is the PAN of the personalized transaction application, but the main PAN of the payment voucher code PDTP is not displayed.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, some forms of DPD will not be suitable for contact transactions (such as wearable devices), so the DTPU may be limited to non-contact Or digital transactions via the Internet (such as payment digital transactions).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DTPU can be operated to host a plurality of PDTPs. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DTPU is provided on the DPD without hosting any PDTP. In some specific embodiments, the DPD that DTPU does not host PDTP is provided to a third party (such as a bank or a card issuer), and the bank or card issuer provides one or more PDTPs for the DTPU to provide to the card holder. Custody before people use it. In other specific embodiments, the DPD that DTPU does not host PDTP is provided to the cardholder, and may be installed on the DTPU, and the cardholder may be provided with one or the other from a remote supply network or agent if necessary. Multiple DTP/PDTP. In this specific embodiment, the cardholder can receive the DPD for which the DTPU has hosted one or more PDTPs, and can supply the cardholder from a remote source as needed for installation on the DTPU One or more further DTP/PDTP of the network or proxy.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DTPU is operable to accept for loading (or installing) each one or more associated with the payment scheme. A container. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the installation of the one or more containers can provide the one or more containers far away from the DTPU (and the DPD). Implemented as a supply agent for each container.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, installing DTP/PDTP on the DTPU includes instantiating one or more associated with the DTP/PDTP on the DTPU Transaction applications, where the one or more transaction applications are associated with a container on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the container provides functions required by the one or more transaction applications for implementing digital transactions. Digital Payment Device (DPD)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, a digital payment device (DPD) is any device that can be operated by a DTPU for digital transactions (and is usually incorporated into the DTPU). ). Although the term DPD includes the term "payment" (Payment), in each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, DPD can still be used for payment digital transactions and non-payment digital transactions. Trade both.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD includes an infrastructure for allowing supply from a supply network to the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD includes a method for allowing access from a supply network when the DPD (and the DTPU) is away from the supply network The infrastructure supplied to the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD is a digital transaction card (DTC) in the form of a traditional credit or debit card or its form. DTC (in the form of a card) is generally operable for both contact and contactless transactions via DTD, as well as type transactions via the Internet.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD has the form of a wearable device, such as a ring, a watch, a bracelet, or a necklace. Generally, this device is not operable for contact payment transactions, and can only be operable for contactless transactions via DTD or via the Internet (card not shown) type transactions.

In other specific embodiments of the present invention and/or other specific embodiments of its related art, the DPD is a non-portable device, such as a refrigerator, a dishwasher, a washing machine, and other non-portable devices. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD is incorporated into the device. In other such specific embodiments of the present invention and/or in other such specific embodiments of its related art, the DPD is remote from or external to the device, but is linked to the device. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD may be in the form of a card (or part of the card form) that is linked to the non-portable device via a communication cable Part of the payment device, in which the card form can be operated to be inserted (introduced) into the DTD for contact payment. However, generally, this device is not operable for contact payment transactions, and can only be operable for contactless transactions via DTD or Internet type transactions.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the DPD is incorporated in the vehicle or is used for a tag placed in the vehicle. Generally, this device is not operable for contact payment transactions, and can only be operable for contactless transactions via DTD or via the Internet (card not shown) type transactions.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technology, the DPD includes a DTPU and a magnetic stripe for storing information (this will usually be used for the specific implementation of the DPD-based DTC Example) Both. In some specific embodiments of the present invention and/or in some specific embodiments of its related art, the magnetic strip is a dynamic magnetic strip.

In other specific embodiments of the present invention and/or in other specific embodiments of its related art, the DPD includes a user interface that can be operated to control the operation of the DPD (including one or more components of the DPD) , Such as the operation of the DTPU). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the user interface includes one or more buttons, which the user can press to activate assignments to the Operation of one or more buttons.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the user interface includes a Graphical User Interface (GUI). The GUI can be a screen with low power consumption, such as an electronic paper display. In other embodiments of the present invention and/or in other embodiments of the related art, the GUI may be provided by an LCD display (including a segment display and/or an active matrix display). In still other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the GUI is adapted to display in association with the personal-specific characteristics selected as the personal-specific characteristics of the operation of the DPD The logo or mark of the payment plan (including a trademark). In this regard, the GUI can be adapted to display a plurality of different signs or marks, wherein the displayed signs or marks are changed to conform to the payment scheme associated with the personal characteristic selected as the personal characteristic of the operation of the DPD. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the user interface includes a sliding sensor (or touch sensor) for sensing a use The finger of the person slides over the sliding sensor to implement a selected operation on the DPD. In still other embodiments of the present invention and/or in still other embodiments of the related art, the user interface includes a touch screen display in addition to or instead of a keypad (Keypad).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the user interface can be operated to allow the user to access a plurality of personal-specific features from the DPD (or on the DTPU) Among a plurality of PDTPs), select a person-specific feature from the DPD (or a plurality of PDTPs on the DTPU).

In this specification, many specific embodiments and variations of the present invention and/or specific embodiments of related technologies are described by DTC as the DPD. However, it will be understood that in many of these specific embodiments, the description applies to any form of DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD includes a receiver for receiving wireless communication. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD includes a transmitter for transmitting wireless communication. In some specific embodiments of the present invention and/or in some specific embodiments of its related art, the DPD includes a transmitter coupled to the receiver. This can be called the transceiver. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the transceiver (or the transmitter and/or the receiver) is adapted to implement the Bluetooth communication protocol. In other embodiments of the present invention and/or in other embodiments of related technologies, the transceiver (or the transmitter and/or the receiver) is adapted to implement the WiFi communication protocol. In still other embodiments of the present invention and/or in still other embodiments of related technologies, the transceiver (or the transmitter and/or the receiver) is adapted to implement the Zigbee communication protocol. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the transceiver (or the transmitter and/or the receiver) is adapted to implement the NFC communication protocol. In a further embodiment of the present invention and/or in a further embodiment of the related art, the transceiver (or the transmitter and/or the receiver) is adapted to implement two or more different communication protocols .

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD can be operated to link DAD for intercommunication. In some such specific embodiments of the present invention and/or in some of its related technologies, the link between the DPD and the DAD is via Bluetooth or Bluetooth Low Energy (BLE). In other specific embodiments of the present invention and/or in other specific embodiments of the related art, the link between the DPD and the DAD is via WiFi. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, when the DAD is linked to at least one supply agent for interworking, the link between the DPD and the DAD Allow communication between the DPD and at least one supply agent from one or more supply agents in the supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the supply agent is a DPD manager.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD is operable to be linked to at least one of one or more supply agents from a supply network for intercommunication. Supply agent. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the link between the DPD and the at least one provisioning agent uses the WiFi transceiver on the DPD via the Internet road. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the supply agent is a DPD manager. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related art, the DPD is operable to communicate with the DPD manager via the DPD manager gateway, and the DPD manager gate The channel provides an interface for communication between the DPD manager and the components of the DPD. In some further embodiments of the present invention and/or in some further embodiments of related technologies, the communication between the DPD manager and the DPD is a secure communication link. In still other embodiments of the present invention and/or in still other embodiments of related technologies, the secure communication link adopts Transport Layer Security (TLS). In some of the specific embodiments of the present invention and/or in some of the related technologies, the secure communication link adopts any one or more of secure channel protocols, including SCP02 and SCP03. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the secure communication link adopts SEMS security credentials for ensuring the security of the link. In still other embodiments of the present invention and/or in still other embodiments of related technologies, the secure communication link adopts two or more security layers. In some of the specific embodiments of the present invention and/or in some of the related technologies, one of the layers uses data encryption, including SCP02 (in many specific embodiments, use SCP02 i=55 settings), SCP03 (in many specific embodiments, use Advanced Encryption Standard (AES) encryption) any one or more of them, and the other layer of which uses Transport Layer Encryption (TLE) (used in Internet TCP/IP) ), which in some specific embodiments uses AES.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD includes an energy storage device. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the energy storage device includes one or more batteries. In some of these specific embodiments of the present invention and/or in some of these specific embodiments of the related art, in the DPD having the form of DTC, the battery is a flat battery. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the battery is a thin, flexible and printable battery. In other embodiments of the present invention and/or in other embodiments of the related art, the energy storage device includes one or more capacitors, and may include one or more super capacitors. In still other embodiments of the present invention and/or in still other embodiments of the related art, the energy storage device includes a combination of one or more batteries and one or more capacitors. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more batteries is a main battery. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more batteries is a rechargeable battery. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD is operable to use energy harvesting to recharge the at least one rechargeable battery, including when using the DTD Collect energy from a DTD during digital transactions.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, in the case that the DPD includes contact pads, the contact pads conform to the contact pads on traditional credit and/or debit cards. Standards. In this way, the SE on the physical card (such as credit and debit cards) usually uses the contact pad on the surface of the card to transfer data between the SE and the DTD in the payment/transaction network. Each contact strip has several contact pads for electrical signal (data) connection with the corresponding electrode in the DTD or other device. Many of the construction and operation of this contact pad are regulated by the standard ISO/IEC 7816. The contact pads used include: VCC, RESET, CLOCK, GROUND, and DATA contact pads to exchange APDU commands between a DTD and the DTPU of the DPD . As such, some contact pads are not used for this interaction, including contact pads #4 and #8. The contact pads #4 and #8 (or the data connection channels between the contact pads and the DTPU) can be used in the present invention and related technologies of the present invention for the components on the DPD and outside the DPD. Data transfer between. For example, contact pads #4 and #8 (or the data connection channels between those pads and the DTPU) can be used for data communication between the MCU and the outside of the DPD. For example, in some specific embodiments, the MCU can be supplied with digital objects (including command set files, metadata, and other files on the DPD) from the DTD that the DPD has introduced or inserted into it. Digital Transaction Card (DTC)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD coefficient bit transaction card (DTC). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD (or DTC) has a card form and is adapted for insertion (introduction) into the DTD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD (or DTC) has a card form and is adapted for wireless (contactless) digital transactions with the DTD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DTC has a traditional card form, such as a traditional credit card or a debit card. Microcontroller unit (MCU)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD of the present invention has a microcontroller unit (MCU), which controls various components of the DPD, such as a user interface, The buttons of the user interface, the graphic display of the user interface, the secure memory (such as OSE), the communication module (including, for example, Bluetooth and/or WiFi communication), and other components. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU can also control the selection operation of the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the MCU is operable to receive signals from the user interface of the DPD (including signals from buttons or other user input devices). Signal) to realize the operation on the DPD. For example, when the user of the DPD wants to change the personal characteristics of the DPD, the user presses the required button(s) on the DPD to realize the change, and the button(s) will signal Transmitted to the MCU, it can be operated to initiate actions on the DPD to change the personal characteristics of the operation, including (not necessarily in this order) updating one or more registries (including an MCU registration) on the DPD Table), lock all transaction applications (operated by the MCU of the OSE and the DTPU), unlock at least one of the one or more transaction applications in the PDTP associated with the selected personal characteristic (Operations managed by one of the MCU of the OSE and the DTPU), update the one or more selected applications in the application selection module (operations managed by one of the MCUs of the OSE and the DTPU), and The user interface (the graphical user interface) displays an appropriate indicator of the personal-specific feature of the current operation of the DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU complies with any one or more of the following certifications, agreements, and/or standards: CC PP-0084 EAL4+ and AVA_VAN .5 (It will be understood that this MCU can be regarded as SE). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the conformity is required for the use of data objects (such as cryptographic keys and command set documents) with the required security level Perform storage and/or operations.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the MCU assists in providing a long battery life for the DPD (if it has an optional battery) by operating with low power consumption . In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU is operable to accept supply from one or more of the DPD manager, TSM, and TSP (synchronized, non-synchronized, and non-synchronized). Synchronous, or both selective and asynchronous). In some specific embodiments of the present invention and/or in some specific embodiments of related technologies, the MCU can be operated by the SEMS service to accept the supply. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the MCU can use one or both of an NXP SEMS service (loader service) and a GP SEMS service Operate to accept the supply.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU link is used to communicate with the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the MCU includes one or more communication paths which are linked to the DTPU and the DPD (or DTC). The respective communication paths between the contact pads. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the communication paths between the contact pads of the DTPU and the DPD (or DTC) include the following One or more: 1. VCC, 2. RESET, 3. CLOCK, 5. GROUND, and 7. DATA (according to ISO/IE 7816 standard).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU link is used to communicate outside the DPD (or DTC) via the contact pad of the DPD (or DTC) . In some embodiments of the present invention and/or in some embodiments of related technologies, the MCU link is used for external communication via contact pads not used by the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU link is used for external communication via any or more of the following: contact pad 4 and contact pad 8 (according to ISO/IE 7816 standard).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU can use the contact pads of the DPD (or DTC) to communicate outside the DPD (or DTC) In this case, enable the MCU to accept supply when the DPD (or DTC) is close to the supply source (and physically contacts with it). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the supply source is a DTD, and the DPD (or DTC) is inserted (or introduced) into the DTD, wherein the The DTD can provide digital objects to the MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the supply source is located in a laminating facility or some other such card manufacturing facility, where the DPD (or DTC) and the The supply source contacts (even if the respective contact pads such as contact pad 4 and contact pad 8 (according to the ISO/IE 7816 standard) are in contact with the corresponding electrode), so that the supply source can provide digital objects to the MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the digital objects include one or more of the following: one or more instruction set documents (including encrypted And unencrypted instruction set documents), metadata about one or more DTP/PDTP for the DTPU, MCU firmware, firmware for other DPD components, and other DPD files.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU can be operated to securely store one or more instruction set files for execution on the DTPU, including the ability to pass One or more instruction set documents verified by the SSD on the DTPU. In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the MCU can be operated to securely store one or more instruction set document templates, and the one or more instruction set document templates ( Each system is operable for execution on the DTPU when further data is written. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU can be operated to securely store one or more cryptographic keys, each cryptographic key being used for encryption ( Signed) a command set document or a command set document template (when written with further data), so that the command set document or a command set document template (when written with further data) can be used in the DTPU Perform verification on the SSD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the MCU is operable to receive from the DTPU one or more from one or more respective security domains (such as SSD) Sequential counter value (sometimes called counter). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU is operable to request the one or more sequential counter values from the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU is operable to store one or more instruction set documents to request the one or more from the DTPU Sequence counter value. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU is operable to store one or more sequential counter value instruction set files and/or commands, where each instruction The set file and/or command is transmitted to the OSE, so that the OSE provides the sequential counter value request instruction set file and/or command to the MCU, and the MCU transmits it to the DTPU to retrieve (Retrieve) for supply back The sequence counter value of this MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each of the one or more sequential counter value commands is an unauthenticated command. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the MCU stores the one or more sequential counter value instruction set files and/or commands. In this context, the MCU There is no need to retrieve these instruction set documents and/or commands from the OSE.

In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, the MCU is secured for storage and operation by the instruction set document, the instruction set document template, and the cryptographic key. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the MCU conforms to (or operates in accordance with) one or more GP standards and/or common criteria.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the MCU may be operable to receive one or more instruction set documents from the OSE, and the MCU transmits them to the DTPU for use carried out. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technologies, the MCU is operable to receive one or more encrypted instruction set documents from the OSE, and the MCU transmits them to For applications under the SSD of the DTPU, the one or more encrypted instruction set documents can verify the SSD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the MCU is further operable to request one or more instruction set documents from the OSE, and the instruction set documents are used It runs on DTPU used for applications under SSD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the MCU is operable to pass parameters to the OSE so that the OSE can write data into one or more templates Instruction set documentation. In some other specific embodiments of the present invention and/or in some other specific embodiments of related technologies, the OSE is in the MCU. In further embodiments of the present invention and/or in further embodiments of the related art, the MCU and the DTPU are in a single integrated circuit chip (ICC). In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the MCU, the OSE, and the DTPU are in a single integrated circuit chip (ICC). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the ICC includes a firewall for preventing unauthorized communication between the MCU and the DTPU. In other embodiments of the present invention and/or in other embodiments of related technologies, the ICC includes a firewall for preventing unauthorized communication between MCU, OSE, and DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU is operable to perform security between one or more supply agents in the supply network and the DTPU Communication proxy server. In some of the specific embodiments of the present invention and/or in some of the related technologies, the secure communication includes the use of security protocols (including SCP02, SCP03, and other similar and/or related security communication protocols). One or more) communications. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the secure communication protocol includes the use of SCP02 i=55.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, in the case that the MCU is operable as a proxy server, the MCU may be operable to operate between the MCU and the one or The secure communication channel between multiple supply agents receives digital objects from one or more supply agents in the supply network, including encrypted instruction set documents, where these digital objects have been encrypted using SCP02 i=55. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the MCU that has received the digital object encrypted using SCP02 i=55 can be operated to disconnect on the secure communication channel After the connection, the received digital objects are retained, and the MCU is further operable to transmit the digital objects to the DTPU for execution.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU includes an MCU registry for metadata of the MCU registry, wherein the metadata is related to the DPD Data of one or more personal characteristics on the DTPU (each personal characteristic is associated with the DTP/PDTP hosted on the DTPU). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the MCU registry includes one or more metadata tables. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the first MCU registration metadata table includes a plurality of rows for one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the MCU); ● Individual characteristic index (an index used to facilitate reference to each individual characteristic on the DPD, and each individual characteristic is associated with the DTP/PDTP hosted in the DTPU); ● Personal characteristic identifier (for the personal characteristic of a payment card, this will be a PAN, including its issuer identification number (IIN)); ● The name of the payment plan for each individual's exclusive feature (in the case that the individual's exclusive feature is used in a payment card or the like); ● The name of the issuer of each individual characteristic; ● The expiration date of each individual characteristic; ● The nickname of each individual's unique characteristics; ● The CVV of each transaction application in the PDTP associated with the personal characteristic (in the case that the personal characteristic is used for a payment card or the like); ● The mark index of each individual characteristic (reference to the mark that will be displayed on the DPD for each individual characteristic when it is a valid personal characteristic of the DPD); ● The name of the holder of the personal characteristic (for payment cards or the like, this is usually called the card holder’s name); ● Individual feature activation status, which displays the current status of each individual feature (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: Enable on non-contact interface, 3: enable on both contact and non-contact interface); ● The default activation status of individual features, showing what status should be the default activation status of each individual feature in a prescribed situation, for example, if the activation status of the individual feature is lost (the following code can be used for this: 0 : Not preset for both contact and non-contact interfaces, 1: preset for contact interfaces, 2: preset for non-contact interfaces, 3: preset for both contact and non-contact interfaces); ● A flag indicating whether the activation status/default activation status of each individual feature has been changed; and ● The header of the AID list (Head) (used for the address of the first AID of one or more AIDs associated with the transaction application related to the DTP).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the second MCU registration metadata table includes multiple rows related to one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the MCU); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In this other specific embodiment of the present invention and/or in other specific embodiments of its related technology, in the case that each individual characteristic includes two or more transaction types, the MCU first registration metadata table includes Multiple lines about one or more of the following: ● The header of the transaction type list (used for each address of the first AID of two or more AIDs associated with the transaction type of the transaction application related to the individual’s unique characteristics, where each transaction application They are all associated with the DTP/PDTP hosted on the DTPU).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, in the case that each individual characteristic includes two or more transaction types, a further MCU registration meta-data table includes related Multiple lines of one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the MCU); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● The name of the transaction type; ● The nickname of the transaction type (this can be displayed on the DPD to indicate which transaction type is valid for personal characteristics, and can also be displayed for the user to choose between different transaction types as needed On the DPD); ● The association of the transaction type (that is, the associated transaction type includes: a bank account, used for purchase types of other transaction types that are different from the individual's exclusive characteristics; a currency account, used for purchases that are different from the personal unique Other currency types of these types of transactions; and other connections); ● Instruction method (during digital transactions, there must be a component used to indicate which transaction type is being used to the bank or other institution handling the transaction. These indicators can include: a serial number (usually used to indicate the primary or secondary card holder) Person), or the AID of the transaction application related to the transaction type). ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DPD (and/or DTPU) is configured to host one or more payment voucher code personal characteristics (that is, where Personal characteristics have one or more associated payment certificate code transaction applications, and each payment certificate code transaction application has a payment certificate code identifier (for payment card personal characteristics, this will be the payment certificate code PAN In the case of) ), the first MCU registration metadata table includes multiple rows related to one or more of the following items: ● The header of the payment voucher code transaction application list (used for the address of the first AID of each two or more AIDs associated with the payment voucher code transaction application related to the personal characteristic, each of which is the transaction application The programs are all associated with the DTP/PDTP hosted on the DTPU).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, in the case that each individual characteristic includes one or more payment voucher code transaction applications, a further MCU registration element The data table includes multiple rows about one or more of the following items: ● The address of each item in the table (used as a reference to the memory location in the MCU); ● The address of the next AID; ● The address of the associated (owned) personal characteristic; ● Indicate how to select the one or more payment voucher codes associated with the personal characteristic (which is selected by the user to be the valid personal characteristic) Transaction application selects payment voucher code. The selection method of transaction application includes: random or pseudo-random selection (automatically implemented by the DPD without the user’s input), sequential selection (where the DPD automatically selects the selected The AID of the next payment voucher code transaction application on the list of personal-specific features), and user selection (where the user selection will be for the payment voucher code transaction application that will be activated for the selected personal-specific feature). ● The name of the payment voucher code transaction application (this usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● The nickname of the payment voucher code transaction application (this can be displayed in the DPD The above is a name that indicates which payment voucher code transaction application is valid for personal characteristics, and it can also be displayed on the DPD for the user to choose between different payment voucher code transaction applications on demand .This usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface) Interface, 3: both contact and non-contact interfaces); ● Enabled state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: on Enable on non-contact interface, 3: enable on both contact and non-contact interface). Operating safety element (OSE)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD includes an operational security element (OSE) outside the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the OSE can be operated to securely store one or more commands for execution on the DTPU and/or by its The operation includes one or more commands encrypted in order to verify the SSD on the DTPU. In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the OSE can be operated to securely store one or more command templates and/or by its operation, the one or more Command templates (each when written with further data) are operable for execution on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the OSE is operable to generate one or more commands from each of the one or more command templates . In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the OSE can be operated to securely store one or more cryptographic keys and/or by its operation, each cryptographic key The key is used to encrypt the command or command template (when written by further data), so that the command or command template (when written by further data) can be used to verify the SSD used to run on the DTPU . In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the OSE can be operated to be used for secure storage of one or more instruction set files executed on the DTPU and/or Or operation, including one or more instruction set documents encrypted in order to verify the SSD on the DTPU. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the OSE can be operated to securely store and/or operate by one or more instruction set document templates, such one or Multiple instruction set document templates (each at the time of writing with further data) are operable for execution on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the OSE is operable to generate one or more from each of the one or more instruction set document templates Instruction set document. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the OSE can be operated to be securely stored and/or operated by one or more cryptographic keys, each cryptographic key The key is used to encrypt the command set document or the command set document template (when written with further data), so that the command set document or the command set document template (when written with further data) can be used in the The SSD executed on the DTPU is verified. It will be understood that this instruction set document is traditionally used by entities such as TSM, card personalization department, and the like for operations (such as personalization).

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the OSE can be operated to store and/or operate by digital objects other than the instruction set file and the cryptographic key, such as Firmware and/or files of other components on the DPD (such as MCU firmware and/or files).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the OSE is located on the MCU or on another chip that communicates with the MCU on the DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the OSE complies with any one or more of the following certifications, agreements, and/or standards: CC PP-0084 EAL4+ and AVA_VAN .5. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the conformance is required for the use of data objects with the required security level (such as for card management on the DTPU) Or the password key and command set file managed by SE) for storage and/or operation. In some embodiments, the separate OSE includes a secure firmware/architecture to be able to store one or more secure keys so that the storage and use of these keys and other OSE operations meet at least common criteria or PCI need.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the OSE can only be accessed by the MCU to retrieve data, files, and other digital objects, including instruction set files and Encrypted instruction set document.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the OSE is operable to receive a request from the MCU to provide one or more instruction set documents, one or more process Encrypt the instruction set document and one or more other digital objects, and provide the requested one or more instruction set documents, one or more encrypted instruction set documents, and one or more other digital objects to the MCU . In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the OSE is operable to receive an identifier from the MCU with each request to identify which one or more are required Instruction set document. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the identifier is used for the AID of the application (including selection application and transaction application) in the DTPU. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, the MCU requests the OSE to generate the instruction set from the OSE from the template instruction set document or the template command, respectively In the case of a document or command, the MCU can be operated to send an identifier through the request to identify the template command set document or the template command to be used by the OSE.

In other specific embodiments of the present invention and/or in other specific embodiments of the related art, the OSE can be operated to parameterize (or write one or more parameters into) one or more of the OSE In each of a plurality of template command set documents or template commands, one or more parameters from the MCU are received from the MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, the one or more parameters include an application program (including selection application and transaction application) in the DTPU The AID.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the OSE is operable to receive a key from the MCU representing the security domain (such as SSD) used in the DTPU One or more counters for the next expected counter value of the set.

In further embodiments of the present invention and/or in further embodiments of the related art, the OSE can be operated by one of the one or more cryptographic keys stored in the OSE Encrypt one or more instruction set documents so that the one or more encrypted instruction set documents verify the security domain (such as SSD) of the DTPU.

In still further embodiments of the present invention and/or in still further embodiments of the related art, the OSE can be operated by the one or more cryptographic keys stored in the OSE One and the counter encrypt one or more instruction set documents, so that the one or more encrypted instruction set documents verify the security domain (such as SSD) of the DTPU, wherein the encryption includes the counter, which represents The next expected counter value for this security domain.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the OSE can be operated to parameterize (or write one or more parameters into) one or more template instruction set documents In each of them. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, the one or more parameters include an application program (including selection application and transaction application) in the DTPU One of AID. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the OSE is operable to be encrypted by one of the one or more cryptographic keys stored in the OSE Each parameterized template instruction set document. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the OSE is operable to be operated by one of the one or more cryptographic keys stored in the OSE And a counter to encrypt each parameterized template command set document, wherein the derivative of the conversation key from the encryption key used for the encryption includes the counter, which represents the next expected counter value for the security domain.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the OSE includes an OSE registry for storing metadata, wherein the metadata is associated with the DPD hosted on the Data related to one or more personal characteristics (each personal characteristic is associated with the DTP/PDTP hosted on the DTPU). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the OSE registry includes one or more metadata tables. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, a first registration metadata table includes multiple rows related to one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the OSE); ● Individual characteristic index (an index used to facilitate reference to each individual characteristic on the DPD, and each individual characteristic is associated with the DTP/PDTP hosted in the DTPU); ● Personal characteristic identifier (for the personal characteristic of a payment card, this will be the PAN, including its IIN); ● The name of the payment plan for each individual's exclusive feature (in the case that the individual's exclusive feature is used in a payment card or the like); ● The name of the issuer of each individual characteristic; ● The expiration date of each individual characteristic; ● The nickname of each individual's unique characteristics; ● The CVV of each transaction application in the PDTP associated with the personal characteristic (in the case that the personal characteristic is used for a payment card or the like); ● The index of the logo of each individual's unique feature (the reference to the logo that will be displayed on the DPD of each individual's unique feature when it is a valid individual feature of the DPD) ● The name of the holder of the personal characteristic (for payment cards or the like, this is usually called the card holder’s name); ● Individual feature activation status, which displays the current status of each individual feature (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: Enable on non-contact interface, 3: enable on both contact and non-contact interface); ● The preset activation status of individual features, which shows the preset status of the activation of each individual feature in the specified situation, for example, if the activation status of the individual features is lost (the following code can be used for this: 0: Not Presets for both contact and non-contact interfaces, 1: Presets for contact interfaces, 2: Presets for non-contact interfaces, 3: Presets for both contact and non-contact interfaces); ● A flag indicating whether the activation status/default activation status of each individual feature has been changed; and ● The header of the AID list (used for the address of the first AID of one or more AIDs associated with the transaction application of the DTP).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, a second registration metadata table includes multiple rows related to one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the OSE); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, in the case that each individual characteristic includes two or more transaction types, the first OSE registration metadata table includes Multiple lines about one or more of the following: ● The header of the transaction type list (used for each address of the first AID of two or more AIDs associated with the transaction type of the transaction application related to the individual’s unique characteristics, where each transaction application They are all associated with the DTP/PDTP hosted on the DTPU).

In some of these specific embodiments of the present invention and/or in some of its related technologies, in the case that each individual characteristic includes two or more transaction types, a further OSE registration meta-data table includes related Multiple lines of one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the OSE); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● The name of the transaction type; ● The nickname of the transaction type (this can be a name displayed on the DPD to indicate which transaction type is effective for personal characteristics, and can also be used for the purpose of the user to choose between different transaction types as needed Displayed on the DPD); ● The association of the transaction type (that is, the associated transaction types include: a bank account, which is used for purchase types that are different from the other transaction types for the individual’s unique characteristics; a currency account, which is used for Other such transaction types in different currency types; and other connections); ● Instruction method (during digital transactions, there must be a component used to indicate which transaction type is being used to the bank or other institution handling the transaction. These indicators can include: a serial number (usually used to indicate the primary or secondary card holder) Person), or the AID of the transaction application related to the transaction type). ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DPD (and/or DTPU) is configured to host one or more payment voucher code personal characteristics (that is, where Personal characteristics have one or more associated payment certificate code transaction applications, and each payment certificate code transaction application has a payment certificate code identifier (for payment card personal characteristics, this will be the payment certificate code PAN In the case of) ), the first registration metadata table includes multiple rows related to one or more of the following: ● The header of the payment voucher code transaction application list (used for the address of the first AID of two or more AIDs associated with the payment voucher code transaction application associated with the individual’s unique characteristics, where each transaction All applications are associated with the DTP/PDTP hosted on the DTPU).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, in the case that each individual characteristic includes one or more payment voucher code transaction applications, a further OSE registration element The data table includes multiple rows about one or more of the following items: ● The address of each item in the table (used as a reference to the memory location in the OSE) (in other specific embodiments, the DAD can store the metadata in the table, so these addresses are not needed); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● Indicate how to obtain the personal characteristic (Which is selected by the user in order to serve as the valid personal characteristic) the associated one or more payment voucher code transaction applications select the payment voucher code transaction application selection method, the methods include: random or pseudo Random selection (automatically implemented by the DPD without the user's input), sequential selection (where the DPD automatically selects the AID of the next payment voucher code transaction application on the list of the selected personal characteristics), and the user Select (where the user selects the payment voucher code transaction application that will be activated for activating the selected personal characteristic). ● The name of the payment voucher code transaction application (this usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● The nickname of the payment voucher code transaction application (this can be displayed in the DPD The above is a name that indicates which payment voucher code transaction application is valid for personal characteristics, and it can also be displayed on the DPD for the user to choose between different payment voucher code transaction applications on demand .This usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface) Interface, 3: both contact and non-contact interfaces); ● Enabled state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: on Enable on non-contact interface, 3: enable on both contact and non-contact interface). DPD hardware security architecture

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD includes a DTPU, an MCU, and an OSE, wherein the DTPU is connected to the MCU for data communication therebetween, And the MCU is connected to the OSE for data communication. In some of the specific embodiments of the present invention and/or in some of the related technologies, the OSE is sufficient for safe storage and operation by means of cryptographic keys and instruction set documents (including template instruction set documents) Standards.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the MCU may be operable to manage some operations of the DTPU and the OSE, wherein the MCU stores on the OSE by request One or more of the instruction set documents indicate this operation on the DTPU. The one or more instruction set documents are transmitted through the MCU to be executed (or played) on the DTPU in the secure domain (usually SSD), and the one or more instruction set documents are compared against (against) the SSD. Verification, and where the command set documents are executed on the application in the security domain. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the instruction set document can be directly executed against the security domain. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU may request the OSE used to execute (or play) on the DTPU for multiple different domains ( Usually multiple instruction set documents of multiple different SSDs).

It will be understood that if the instruction set documents (encrypted instruction set documents) stored on the OSE cannot be changed, the counter must be set to comply with the DTPU (or the DTPU operating system) in order to prevent replay security. The counter expected by the target security domain. Actually, if you need to repeat operations on the DTPU, this may result in the need for the OSE to store a large number of instruction set documents. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, instead of storing a large number of instruction set files, the counter expected by the DTPU can be reset to, for example, "0" and stored in the These instruction set documents on OSE can set its counter from "0" upwards, so the same instruction set documents can be replayed repeatedly.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technologies, the OSE may store one or more cryptographic funds for signing (encrypting) one or more template instruction set documents key. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each cryptographic key is used to derive the conversation key, the push organism includes the counter, and the derived The dialog key encryption template command set document for. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, in addition to being encrypted by the session key used to verify the SSD on the DTPU, the one or more A complete set of template instruction documents. When the MCU requests one or more instruction set documents, the OSE can operate to encrypt the one or more template instruction set documents, each of which has its own cryptographic key used to derive the session key used for the encryption And counter.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the MCU may request multiple instructions for executing (or playing) in multiple respective security domains of the DTPU Therefore, the multiple instruction set documents are encrypted using multiple respective cryptographic keys and respective counters used in the multiple respective fields. Then, the encrypted instruction set documents are transmitted to the MCU to be transmitted to the DTPU for execution in the respective security domains of the DTPU. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, the counter is associated with a key set (which is associated with an SSD). The SSD may have multiple key sets and therefore multiple counters.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, in addition to some required information, the one or more template command set documents are complete and encrypted (by (From the conversation key derived from the encryption key and counter). In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, each template command set document needs to be associated with the target application (including selection application or transaction application) The AID is passed to the template instruction set document as a parameter, and the counter needs to be set and encrypted. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, when the MCU requests one or more instruction set documents, it transmits one or more files for respective applications One or more parameters of the AID, so that each of the command set documents can receive the AID, which is then encrypted by the respective cryptographic key and counter used in the security domain of the respective application.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the counter is passed from the MCU as a parameter when requesting an instruction set document from the OSE. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the counter can be obtained by the MCU by sending a request (which is an instruction set document) to the DTPU. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the request can be made through the instruction set document, so that the MCU initially requests the expected counter request instruction set from the OSE Document, the expected counter request instruction set document is sent to the DTPU, the MCU receives the expected counter from the DTPU, and then the MCU sets the counter of the template instruction set document in the subsequent instruction set document request (used to encrypt the Wait for the instruction set document), and transfer the expected counter as a parameter to the OSE.

One advantage of this architecture is that the instruction set documents are kept secure when they are transmitted through the MCU, which is required to comply with some security standards (such as the PCI standard). Cryptographic key security memory (Cryptographic Key Secure Memory, CKSM)

In each specific embodiment of the present invention and/or in a number of specific embodiments of its related technology, the DPD includes a secure memory for storage for establishing a secure communication channel or secure communication dialog outside the DPD At least one cryptographic key for. This secure memory can be called Cryptographic Key Secure Memory (CKSM). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the CKSM is operable to generate or derive one or more session keys from each at least one cryptographic key . In some other such specific embodiments of the present invention and/or in some other such specific embodiments of its related art, the CKSM is operable to generate or derive one or more sessions from each at least one cryptographic key Key, and generate or derive a counter from the DTPU.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the CKSM can be operated to securely store a single symmetric cryptographic key used to establish a secure communication session, wherein the secure communication session allows The DPD provides further digital objects including one or more of the following: one or more command set documents, one or more cryptographic keys used to establish subsequent secure communications, and further firmware (including the MCU and Firmware upgrade of other DPD components). In some of this embodiment of the present invention and/or in some of this embodiment of its related technology, the initial symmetric cryptographic key can be stored in (introduced) during the manufacturing or lamination of the DPD (for DTC only) Or write) in the CKSM.

In some other specific embodiments of the present invention and/or in some other specific embodiments of its related art, the CKSM can be operated to securely store part of a single asymmetric cryptographic key pair used to establish a secure communication session, Wherein the secure communication dialog allows further digital objects including one or more of the following items to be provided to the DPD: one or more command set documents, one or more cryptographic keys used to establish subsequent secure communications, one or more A certificate, and further firmware (including firmware upgrades of the MCU and other DPD components).

In other specific embodiments of the present invention and/or in other specific embodiments of its related art, the CKSM can be operated to store the firmware used for the DPD (for example, for use in the DPD (that is, remote from the supply network) In the hands of the user of the road), it is implemented on the MCU when the DPD is first enabled). In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the initial basic firmware for the DPD is stored on the MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the initial basic firmware allows the basic operations of the DPD (operations managed by the MCU), so that the After DPD, the MCU immediately accesses the stored part of the single symmetric cryptographic key and/or single asymmetric cryptographic key pair stored in the CKSM to establish a secure communication session, and enables the DPD to operate through the supply network The remote supply of one or more supply agents in the road obtains further firmware for implementation on the MCU. The further firmware (including firmware upgrades to the MCU and other DPD components) is safely provided to the MCU and allows the MCU (and the DPD) to participate in more complicated operations than is possible with the initial basic firmware, For example, the DPD supply includes one or more instruction set documents, one or more template instruction set documents, and one or more cryptographic keys. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the digital objects include instruction set documents and/or template instruction set documents (and, if necessary, cryptographic keys), Used to build (instantiate) applications on the DTPU, including one or more of the following: one or more security domain applications (including SSD), one or more containers (including package or ELF), One or more selection applications (including a PSE selection application and/or a PPSE selection application), and one or more trading applications (each belonging to or related to one or more DTP/PDTP ).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the CKSM has a CKSM registry for the storage of metadata, wherein the metadata is associated with a CKSM hosted on the DPD Or multiple personal characteristics related data (each personal characteristic is associated with the DTP/PDTP hosted on the DTPU). This registry is similar or identical to the aforementioned registry for the MCU and/or the OSE. Information support device (Data Assistance Device, DAD)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD is adapted to be operated by a data assist device (DAD). In each specific embodiment of the present invention and/or in multiple specific embodiments of the related technology of the system, the system includes a DAD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each of the DPD and the DAD has a transceiver for linking the DPD and the DAD to allow communication therebetween .

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the user links the DAD to the DAD by operating the user interface on the DAD and operating the user interface on the DPD DPD.

In other specific embodiments of the present invention and/or other specific embodiments of related technologies, the DAD includes one or more of a smart phone, a tablet computer, or any other suitable mobile computing device. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the DAD includes a non-mobile device, such as a personal computer. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the DAD includes a DTD adapted to communicate with the DPD via its receiver and/or transmitter.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DAD may be, for example, through Bluetooth/Bluetooth Low Energy (BLE), through Near Field Communication (NFC), or Connect to the DPD via WiFi, and establish a communication session with a remote agent via the Internet, for example.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DAD is operable to implement communication between the DPD (via the DAD) and a remote agent (such as a supply agent) . For example, the DAD can be used to realize the communication between the DPD and the Trusted Service Management Platform (TSM) via the DAD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DAD can be operated to link only a specified DPD, and the DPD can be performed through one or more of the following Unique identification: the ID of the DTPU, the ID of the MCU, and the ID of other DPD components. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DAD can be operated to link multiple DPDs, each of which can be uniquely identified through one or more of the following : The ID of the DTPU, the ID of the MCU, and the ID of other DPD components. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the DPD can be operated to link to only one DAD, and the DAD can be uniquely identified through its device fingerprint, which may include Its International Mobile Equipment Identity (IMEI) code. In still further embodiments, the DPD can be operated to link more than one DAD, each of which can be uniquely identified through its device fingerprint.

In other specific embodiments of the present invention and/or in other specific embodiments of its related art, the DAD is operable to communicate with at least one of one or more supply agents in the supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DAD is operable to communicate with the DPD manager in the supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DAD is operable to communicate with any one or more of TSM, TSP, and SEMS via the DPD manager. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related art, the DAD is operable to communicate with the DPD manager via the DPD manager gateway, and the DPD manager gate The channel provides an interface for communication between the DPD manager and the components of the DAD. In some further embodiments of the present invention and/or in some further embodiments of related technologies, the communication between the DPD manager and the DAD is a secure communication link. In still other embodiments of the present invention and/or in still other embodiments of related technologies, the secure communication link adopts Transport Layer Security (TLS). In some of the specific embodiments of the present invention and/or in some of the related technologies, the secure communication link adopts any one or more of secure channel protocols, including SCP02 and SCP03. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the secure communication link adopts SEMS security credentials for ensuring the security of the link. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the secure communication link adopts TLS and any one or more of the secure channel protocols for some communications, and for other Communication uses AES encryption, and uses TLS with further encryption for other communications.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DAD can use one or more of the following to implement the DPD and one or more supply agents in the supply network Communication between at least one of: Mobile Network Operator (MNO) (as the actor), Card Application Toolkit Transport Protocol (CAT-TP), HTTP, SMS, wireless (OTA) , And through the Internet (OTI).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DAD may be a DTD. It will be understood that DTD or its software will most likely need to be modified for this purpose.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DAD can be operated to build parameters for the DPD to share or configure Internet communications on the DPD , And directly connect to at least one of one or more supply agents in the supply network. This Internet connection may: ● Share the Internet access of DAD via BLE; ● Have a WiFi chip on the DPD, and directly connect to the supply agent (such as TSM via MNO) by sharing the WiFi hotspot on the phone or connecting to a WiFi router (it can be regarded as having the DAD on the DPD, but it is There is no need for a separate DAD method for Internet connection); ● It is Wifi2BLE bridge.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DAD can be operated to host DAD gateway software, wherein the DAD gateway enables the DAD to become the provisioning infrastructure (including A bridge between a supply network with one or more supply agents and the DPD.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the DAD can be operated as a hosting for interacting with the user of the DAD (also the user of the DPD) DAD application (sometimes called mobile application). The DAD application allows users to operate on the DAD. Some of its operations are synchronous (when the DAD and DPD link are used for intercommunication) or asynchronous (wherein The DAD and DPD are linked for intercommunication after the operation enters the DAD application program later) to realize the DPD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DAD is operable to obtain (download) the DAD application from the mobile application portal of the supply network. In some other such specific embodiments of the present invention and/or in some other such specific embodiments of its related technology, the DAD is operable to obtain (download) the DAD from vendors (such as Google Play and Apple App Store) application. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the mobile application portal is a component of the DPD manager. In some other embodiments of the present invention and/or in some other embodiments of related technologies, the DAD is operable to retrieve the configuration file for the DAD from the mobile application portal, The Bluetooth key is included for the DAD link to specify (pair with) the DPD. In some further embodiments of the present invention and/or in some further embodiments of related technologies, the configuration file will only be registered and approved as the designated DPD through the mobile application portal It is eligible to be downloaded to the DAD and provided.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DAD is operable to be used for the connection between one or more supply agents in the supply network and the DTPU on the DPD Proxy server for secure communication between. In some of the specific embodiments of the present invention and/or in some of the related technologies, the secure communication includes the use of security protocols (including SCP02, SCP03, and other similar and/or related security communication protocols). One or more) communications. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the secure communication protocol includes the use of SCP02 i=55.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, in the case that the DAD is operable as a proxy server, the DAD may be operable to operate between the DAD and the one or The secure communication channel between multiple supply agents receives digital objects from one or more supply agents in the supply network, including encrypted instruction set documents, where these digital objects have been encrypted using SCP02 i=55. In some of these specific embodiments of the present invention and/or in some of these specific embodiments of related technologies, the DAD of a digital object that has been encrypted using SCP02 i=55 can be operated to be disconnected in the secure communication channel After connection, the received digital objects are retained, and the DAD is further operable to transmit the digital objects to the DPD for execution on the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DAD includes a DAD registry for storage of metadata, wherein the metadata is hosted on the DPD Data related to one or more of the personal characteristics (each personal characteristic is associated with the DTP/PDTP hosted on the DTPU). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DAD registry is hosted on a secure memory chip in the DAD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the memory chip is a secure memory, such as a secure element.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DAD registry includes one or more metadata tables. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the first DAD registration metadata table includes multiple rows related to one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DAD) (In other specific embodiments, the DAD can store the metadata in the table, so there is no need for such Address); ● Individual characteristic index (an index used to facilitate reference to each individual characteristic on the DPD, and each individual characteristic is associated with the DTP/PDTP hosted in the DTPU); ● Personal characteristic identifier (for the personal characteristic of a payment card, this will be the PAN, including its IIN); ● The name of the payment plan for each individual's exclusive feature (in the case that the individual's exclusive feature is used in a payment card or the like); ● The name of the issuer of each individual characteristic; ● The expiration date of each individual characteristic; ● The nickname of each individual's unique characteristics; ● The CVV of each transaction application in the PDTP associated with the personal characteristic (in the case that the personal characteristic is used for a payment card or the like); ● The mark index of each individual characteristic (reference to the mark that will be displayed on the DPD for each individual characteristic when it is a valid personal characteristic of the DPD); ● The name of the holder of the personal characteristic (for payment cards or the like, this is usually called the card holder’s name); ● Individual feature activation status, which displays the current status of each individual feature (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: Enable on non-contact interface, 3: enable on both contact and non-contact interface); ● The default activation status of individual features, showing what status should be the default activation status of each individual feature in a prescribed situation, for example, if the activation status of the individual feature is lost (the following code can be used for this: 0 : No preset for both contact and non-contact interfaces, 1: preset for contact interfaces, 2: preset for non-contact interfaces, 3: preset for both contact and non-contact interfaces); ● A flag indicating whether the activation status/default activation status of each individual feature has been changed; and ● The header of the AID list (used for the address of the first AID of one or more AIDs associated with the transaction application associated with the DTP).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the second DAD registration metadata table includes multiple rows related to one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DAD) (In other specific embodiments, the DAD can store the metadata in the table, so there is no need for such Address); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, in the case that each individual characteristic includes two or more transaction types, the DAD first registration metadata table includes Multiple lines about one or more of the following: ● The header of the transaction type list (used for each address of the first AID of two or more AIDs associated with the transaction type of the transaction application related to the individual’s unique characteristics, where each transaction application They are all associated with the DTP/PDTP hosted on the DTPU).

In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, in the case that each individual characteristic includes two or more transaction types, a further DAD registration metadata table includes related Multiple lines of one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DAD) (In other specific embodiments, the DAD can store the metadata in the table, so there is no need for such Address); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● The name of the transaction type; ● The nickname of the transaction type (this can be a name displayed on the DPD to indicate which transaction type is effective for personal characteristics, and can also be used for the purpose of the user to choose between different transaction types as needed Displayed on the DPD); ● The association of the transaction type (that is, the associated transaction types include: a bank account, which is used for purchase types that are different from the other transaction types for the individual’s unique characteristics; a currency account, which is used for Other such transaction types in different currency types; and other connections); ● Instruction method (during digital transactions, there must be a component used to indicate which transaction type is being used to the bank or other institution handling the transaction. These indicators can include: a serial number (usually used to indicate the primary or secondary card holder) Person), or the AID of the transaction application related to the transaction type). ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DPD (and/or DTPU) is configured to host one or more payment voucher code personal characteristics (that is, where Personal characteristics have one or more associated payment certificate code transaction applications, and each payment certificate code transaction application has a payment certificate code identifier (for payment card personal characteristics, this will be the payment certificate code PAN In the case of) ), the first DAD registration metadata table includes multiple rows related to one or more of the following: ● The header of the payment voucher code transaction application list (used for the address of the first AID of two or more AIDs associated with the payment voucher code transaction application associated with the individual’s unique characteristics, where each transaction All applications are associated with the DTP/PDTP hosted on the DTPU).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, in the case that each individual characteristic includes one or more payment certificate code transaction applications, a further DAD registration element The data table includes multiple rows about one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DAD) (In other specific embodiments, the DAD can store the metadata in the table, so there is no need for such Address); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● Instruct how to select the selection method of the payment voucher code transaction application from the one or more payment voucher code transaction applications that are associated with the personal unique feature (which is selected by the user in order to be the valid personal unique feature), These methods include: random or pseudo-random selection (automatically implemented by the DPD without the user's input), sequential selection (where the DPD automatically selects the next payment voucher code transaction application on the list of the selected personal-specific characteristics AID of the program), and user selection (the user selection will be the payment voucher code transaction application that will be activated for activating the selected personal characteristic). ● The name of the payment voucher code transaction application (this usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● The nickname of the payment voucher code transaction application (this can be a name displayed on the DPD to indicate which payment voucher code transaction application is valid for personal characteristics, and can also be used by the user as needed The purpose of choosing between payment voucher code transaction applications is displayed on the DPD. This usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DAD registry is a copy of the registry on the DPD (such as the MCU or OSE registry). In some of these specific embodiments of the present invention and/or in some of these specific embodiments of related technologies, the MCU or OSE registry is the master registry of the DAD registry. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, the DAD registry is a subset of the registry on the DPD (such as the MCU or OSE registry). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DAD registry operation is a backup of the registry on the DPD (such as the MCU or the OSE registry). In some of the specific embodiments of the present invention and/or in some of the related technologies, when the DAD and DPD link are used for intercommunication, the DAD registry and the registry on the DPD (such as the MCU or OSE registry) synchronization, wherein the registry on the DPD is the main registry. Payment plan

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DTPU is configured to operate by one or more payment schemes. Example payment plans include Visa, Mastercard, American Express, and many others.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each payment scheme operating on a DTPU has an associated container for establishing and installing a DTP on the DTPU, where The DTP (and the PDTP, when the DTP is personalized), together with all the one or more transaction applications of the DTP/PDTP, are associated with the payment scheme of the container in which it is created. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each container is hosted under a separate security domain. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the security domains used for each container are Utility Security Domains (USD), each USD It is an application with an associated AID. The USD hosts the container in its secure domain, and each container has an AID. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, in the case where the same PDTP (or the associated personal-specific feature of the DPD) exists in the domestic and international networks, The two containers can be the base of PDTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, in the case of supplying DTP/PDTP from the TSP to the DTPU, the payment solution has control over the secure domain (SSD). In other embodiments of the present invention and/or in other embodiments of related technologies, the TSP has control over the SSD (and its related security domain). In some of these specific embodiments of the present invention and/or in some of its related technologies, transaction applications (or associated PDTPs) from different issuers have separate SSDs under the payment scheme SSD ( Subdomains).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, in the case of supplying DTP/PDTP from TSM to DTPU, the issuer TSM has the right to secure domain (SSD) control. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, transaction applications (or associated PDTPs) from different payment schemes have separate under the issuer’s TSM SSD SSD (subdomain).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, in the case that more than one payment scheme is hosted on the DTPU at the same time, the DTPU can be operated by the Selective operation of one or more subsets of one or more payment schemes. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each USD used for the container associated with the payment scheme in the subset is in an unlocked state and is used for Each USD in the container associated with the payment scheme outside the subset is locked. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, a container whose USD is in a locked state cannot extradite the transaction application instantiated through the container (Extradite) to the safe In the SSD in the part of the hierarchical hosting transaction application. In this way, the USD lock of the container effectively prohibits the container and its associated payment solution from being able to install any transaction application on the DTPU. In some other specific embodiments of the present invention and/or in some other specific embodiments of the related art, the container whose USD is locked cannot instantiate a trading application. In still other specific embodiments of the present invention and/or in still other specific embodiments of related technologies, the transaction application instantiated before the USD lock can continue to operate, but after the USD is locked, it does not Need to instantiate and/or introduce further applications. Supply infrastructure

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each DPD is supplied through the provisioning infrastructure.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the provisioning infrastructure is configured to be provisioned to each DPD when the DPD is away from the provisioning infrastructure. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related art, the supply network is configured to supply each DPD when the DPD is close to the supply network (that is, Bring the DPD into direct physical contact with at least a part of the supply network to be supplied).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the provisioning infrastructure includes one or more entities, services, and providers, which are used to provide DPD (including the DPD). Any one or more components, such as the MCU, the OSE, the CKSM, and the DTPU). In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the provisioning infrastructure further includes other entities, services, and suppliers, which are used to perform functions required for supplying DAD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, the supply infrastructure includes one or more supply networks. In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, each supply network includes one or more entities, services, and suppliers, which are used to provide DPD ( Including the functions required by the components of the DPD, such as the MCU and the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each supply network includes one or more supply agents. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each supply network includes one or more DPD managers. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each of the one or more DPD managers is operable to manage one or more DPDs.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the provisioning infrastructure includes one or more issuers. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, at least one issuer is authorized to issue DPD to the user. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each of the issuers is a card issuer or a financial institution. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each issuer authorizes the issuance of one or more digital cards or one or more digital cards for installation on the DPD Digital files, where each digital card or each digital file is represented by or included in the PDTP hosted on the DTPU of the DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the provisioning infrastructure includes one or more DAD application portals (also referred to as mobile application portals). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each DAD application portal is operable to provide a digital object to each DAD, and this digital object includes a digital file , Firmware, software, and DAD applications (sometimes called mobile applications or App). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each DAD application portal is operable to provide DAD applications (sometimes referred to as mobile applications) to Every DAD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each DAD application portal is operable to provide a DAD gateway to each DAD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the supply infrastructure includes one or more factories. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one factory can be operated to perform one or more of the following: manufacturing DPD components, assembling DPD, layer Press DPD (in the form of DTC), and test DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the provisioning infrastructure includes one or more key introduction partners, and each key introduction partner can be operated to One or more cryptographic keys are introduced into a DPD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more cryptographic keys is introduced into the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more cryptographic keys is directly introduced into the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more cryptographic keys is introduced into the DTPU via the MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more cryptographic keys is introduced into the MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more cryptographic keys is introduced into the OSE. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, at least one of the one or more cryptographic keys is introduced into the SKSM.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the supply infrastructure includes one or more card personalization departments, and each card personalization department can be operated for personal use One or more DTPs hosted on DPD’s DTPU, where each DTP has one or more associated transaction applications, and each of them personally through one or more instruction set documents provided by the card’s personalization department Exclusive. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the card personalization department is operable for key introduction for personalization of SSD.

It will be understood that the one or more factories of the supply infrastructure, the one or more key introduction partners, the one or more laminated factories, the one or more card personalization departments, and Other entities are configured to provide these physical DPDs (for example in the form of DTCs) and, if necessary, pre-provision these DPDs before transmitting them to their respective users.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the supply infrastructure includes one or more supply networks, which are interconnected with one or more issuers ( (Including those issued by financial institutions) to communicate. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, there is a one-to-many relationship between an issuer and multiple supply networks. In some other such specific embodiments of the present invention and/or in some other such specific embodiments of its related art, there is a one-to-many relationship between the supply network and multiple issuers. In still other embodiments of the present invention and/or in still other embodiments of related technologies, there is a many-to-many relationship between multiple issuers and multiple supply networks. In a further embodiment of the present invention and/or in a further embodiment of the related technology, there is a one-to-one relationship between the issuer and the supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the issuer is a part of the supply network. Supply network

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, each DPD is supplied through a supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the supply network is configured to supply to the DPD when the DPD is away from the supply network. In some other embodiments of the present invention and/or in some other embodiments of the related art, the supply network is configured to supply to the DPD when the DPD is close to the supply network (that is, The DPD is in direct physical contact with at least a part of the supply network to be supplied).

In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, the supply network includes one or more entities, services, and suppliers, which are used to provide DPD (including Any one or more components of the DPD, such as the MCU, the OSE, the CKSM, and the DTPU). In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the supply network further includes other entities, services, and suppliers, which are used to perform functions required for supplying DAD.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the supply network includes one or more supply agents.

In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the supply network includes a DPD manager for managing one or more operations on one or more DPDs. Supply agent

In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, the supply network includes one or more supply agents. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each supply agent is an entity for providing services and digital objects to one or more DPD (including DTC) Or organization. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, each supply agent is used to provide services and digital objects to one or more DAD entities or organizations.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each supply agent is a trust service management platform (TSM), a payment certificate code service provider (TSP), and a secure element management service (SEMS), and one of the DPD managers.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the digital object supplied by each supply agent includes one or more of the following: one or more commands ( Including GP commands), one or more command set documents, one or more command set document templates, one or more cryptographic keys, one or more files, and/or other data objects, such as data packets.

In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, each supply agent works when the DPDs are far away from the supply agent (that is, when the DPD and DAD are currently in use, usually Owned by DPD/DAD users) Provided to one or more DPDs. In some other such specific embodiments of the present invention and/or in some other such specific embodiments of its related art, each supply agent provides one or more DPDs when the DPDs are close to the supply agent (wherein These DPDs are not yet owned by DPD users).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each supply agent is operable to receive personally-specific data from the issuer for one or more transaction applications. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the supply agent is operable to convert the personally-specific data for each transaction application to one or more Among the APDUs, the one or more APDUs are written in one or more personal-specific command set documents. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, each supply agent is operable to personalize the one or more individuals for each transaction application The instruction set document is transmitted to the DPD manager. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager will use the one or more personal-specific instruction set documents for each transaction application It is sent to the personal-specific DPD for execution on the DTPU and for the transaction application that has been instantiated in the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, for a transaction application configured to pay for digital transactions, the personal-specific data includes but is not limited to the following One or more: a PAN, a transaction key, a cardholder’s name, an expiration date, a PIN, a CVV, and other information for risk management. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, for transaction applications configured for non-payment digital transactions, the personal-specific data includes but is not limited to the following One or more: a unique identifier, the name of one of the related personnel, an expiration date, a PIN, and other information for risk management.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD has a DTP hosted on the DTPU, and the DTP has one or more transaction applications associated with it In this case, each supply agent can be operated to provide at least one person-specific instruction set document for each of the one or more trading applications that it executes on the DTPU, so that when each trading application is personally exclusive At the time of conversion, it becomes a personal dedicated trading application and the DTP becomes a PDTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD has a DTP hosted on the DTPU, and the DTP has one or more transaction applications associated with it , And each transaction application will be associated with different transaction types, each supply agent can be operated to provide at least one person-specific instruction set document for each of the one or more transaction applications, At least one person-specific instruction set document for each trading application can be executed on the DTPU, where at least one person-specific instruction set document for each trading application includes personal-specific data for its transaction type , So that when each transaction application is personally exclusive, it becomes a personal-specific transaction application for the transaction type and the DTP becomes a PDTP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the further personal-specific data for the transaction type of the personal-specific transaction application includes a serial number, which is used for different purposes. Each other serial number of one or more other transaction types of the personal-specific transaction applications in the PDTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD has a DTP hosted on the DTPU, and the DTP has one or more transaction applications associated with it , And each transaction application will be personalized by the payment voucher code identifier, each supply agent can operate to provide each of the one or more transaction applications for execution on the DTPU At least one person-specific instruction set document for each transaction application program includes data for providing a payment voucher code identifier to the transaction application program, so that when each transaction application When the application is personally exclusive, it becomes a payment voucher code personally exclusive transaction application and the DTP becomes a PDTP. In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, it is used to provide information for each transaction application (including data used to provide a payment voucher code identifier) At least one person specializes in each supply agent of the instruction set document is TSP. DPD manager

In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the supply network includes a DPD manager for managing one or more operations on the DPD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the one or more operations include operations for instantiating one or more DTPs on the DTPU of the DPD . In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the one or more operations include operations for delivering metadata to the DPD.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager is operable to generate other than those provided by the traditional supply agents (such as TSM and TSP) Digital object and transfer this digital object to DPD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD manager is operable to transfer the digital objects to the DPD via DAD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD manager is operable to directly transmit digital objects to the DPD, for example, via a WiFi connection (ie no DAD). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager is operable to provide digital objects to at least one of DPD's MCU, OSE, CKSM, and DTPU By.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DPD manager is operable to receive digital objects provided by one or more supply agents, and to transfer those digital objects Transfer to DPD.

In some of the specific embodiments of the present invention and/or in some of the related technologies, the DPD manager can also operate to maintain a record of the DPD state, including the exclusive use of each individual installed on the DPD A record of a feature, and the feature of the DPD, such as the device model.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager can operate when the DPD is active (ie away from the supply network or the supply infrastructure) , To receive a request from the cardholder (DPD user) in order to install new personal features on the user’s DPD. The installation of personal features includes the following actions: create one or more SSDs (if (Required), instantiate one or more transaction applications in the DTPU (where the one or more transaction applications can be associated with DTP), personalize the one or more transaction applications on the DTPU Each of them (where the one or more personal-specific transaction applications can be associated with PDTP), and install metadata on the DPD (in a specific embodiment, on the MCU), the metadata and These transaction applications (and or DTP/PDTP) are associated, together with the installation of metadata elsewhere on the DPD, together with the installation of metadata on the DAD (if required), and the installation of metadata on the supply network together In the road (as on the DPD manager) or in the supply infrastructure. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DAD is operable to transmit every request of the cardholder (DPD user) to the DPD manager, And the DPD manager can operate to forward each cardholder (DPD user) request to the supply agent, which in turn can operate to forward each cardholder (DPD user) request to the issuer (The issuer is the issuer related to the additional request for the personal characteristic feature). In this specific embodiment, if the issuer approves the request, the issuer activates a program in which the DPD manager and at least one supply agent provide the digital objects installed on the DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD manager includes a DPD manager registry for the storage of metadata, wherein the metadata is related to the hosting Data related to one or more personal characteristics on the DPD (each personal characteristic is associated with the DTP/PDTP hosted on the DTPU).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager registry includes one or more metadata tables. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, a first DPD manager registration metadata table includes multiple rows related to one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DPD manager) (In other specific embodiments, the DPD manager can store the metadata in the table, so No such addresses are required); ● Individual characteristic index (an index used to facilitate reference to each individual characteristic on the DPD, and each individual characteristic is associated with the DTP/PDTP hosted in the DTPU); ● Personal characteristic identifier (for the personal characteristic of a payment card, this will be the PAN, including its IIN); ● The name of the payment plan for each individual's exclusive feature (in the case that the individual's exclusive feature is used in a payment card or the like); ● The name of the issuer of each individual characteristic; ● The expiration date of each individual characteristic; ● The nickname of each individual's unique characteristics; ● The CVV of each transaction application in the PDTP related to personal characteristics (when the personal characteristics are used for payment cards or the like); ● The index of the logo of each individual's unique feature (the reference to the logo that will be displayed on the DPD of each individual's unique feature when it is a valid individual feature of the DPD) ● The name of the holder of the personal characteristic (for payment cards or the like, this is usually called the card holder’s name); ● Individual feature activation status, which displays the current status of each individual feature (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: Enable on non-contact interface, 3: enable on both contact and non-contact interface); ● The default activation status of individual features, showing what status should be the default activation status of each individual feature in a prescribed situation, for example, if the activation status of the individual feature is lost (the following code can be used for this: 0 : Not preset for both contact and non-contact interfaces, 1: preset for contact interfaces, 2: preset for non-contact interfaces, 3: preset for both contact and non-contact interfaces); ● A flag indicating whether the activation status/default activation status of each individual feature has been changed; and ● The header of the AID list (used for the address of the first AID of one or more AIDs associated with the transaction application associated with the DTP).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the second DPD manager registration metadata table includes multiple rows related to one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DPD manager) (In other specific embodiments, the DPD manager can store the metadata in the table, so No such addresses are required); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, in the case that each individual characteristic includes two or more transaction types, the DPD manager first registers metadata The table includes multiple rows about one or more of the following: ● The header of the transaction type list (used for each address of the first AID of two or more AIDs associated with the transaction type of the transaction application related to the individual’s unique characteristics, where each transaction application They are all associated with the DTP/PDTP hosted on the DTPU).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, in the case that each individual characteristic includes two or more transaction types, a further MCU registration meta-data table includes related Multiple lines of one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DPD manager) (In other specific embodiments, the DPD manager can store the metadata in the table, so No such addresses are required); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● The name of the transaction type; ● The nickname of the transaction type (this can be a name displayed on the DPD to indicate which transaction type is effective for personal characteristics, and can also be used for the purpose of the user to choose between different transaction types as needed Displayed on the DPD); ● The association of the transaction type (that is, the associated transaction types include: a bank account, which is used for the purchase type of other transaction types that are different from the personal characteristic; a currency account, which is used for the personal characteristic The currency types of other such transaction types; and other connections); ● Instruction method (during digital transactions, there must be a component used to indicate which transaction type is being used to the bank or other institution handling the transaction. These indicators can include: a serial number (usually used to indicate the primary or secondary card holder) Person), or the AID of the transaction application related to the transaction type). ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DPD (and/or DTPU) is configured to host one or more payment voucher code personal characteristics (that is, where Personal characteristics have one or more associated payment certificate code transaction applications, and each payment certificate code transaction application has a payment certificate code identifier (for payment card personal characteristics, this will be the payment certificate code PAN In the case of) ), the first DPD manager registration metadata table includes multiple rows related to one or more of the following: ● The header of the payment voucher code transaction application list (used for the address of the first AID of two or more AIDs associated with the payment voucher code transaction application associated with the individual’s unique characteristics, where each transaction All applications are associated with the DTP/PDTP hosted on the DTPU).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, in the case that each individual characteristic includes one or more payment voucher code transaction applications, a further DPD manager The registration metadata table includes multiple rows about one or more of the following: ● The address of each item in the table (used as a reference to the memory location in the DPD manager) (In other specific embodiments, the DPD manager can store the metadata in the table, so No such addresses are required); ● The address of the next AID; ● The address of the associated (own) personal characteristic; ● Instruct how to select the selection method of the payment voucher code transaction application from the one or more payment voucher code transaction applications that are associated with the personal unique feature (which is selected by the user in order to be the valid personal unique feature), These methods include: random or pseudo-random selection (automatically implemented by the DPD without the user's input), sequential selection (where the DPD automatically selects the next payment voucher code transaction application on the list of the selected personal-specific characteristics AID of the program), and user selection (the user selection will be the payment voucher code transaction application that will be activated for activating the selected personal characteristic). ● The name of the payment voucher code transaction application (this usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● The nickname of the payment voucher code transaction application (this can be a name displayed on the DPD to indicate which payment voucher code transaction application is valid for personal characteristics, and can also be used by the user as needed The purpose of choosing between payment voucher code transaction applications is displayed on the DPD. This usually makes sense when the user of the payment voucher code transaction application is allowed to choose); ● Interface code (including 0: none (neither contact nor non-contact interface), 1: contact interface, 2: non-contact interface, 3: both contact and non-contact interface); ● Activated state (the following codes can be used for this: 0: disabled on all interfaces (contact and non-contact), 1: enabled on the contact interface, 2: enabled on the non-contact interface, 3: on contact and non-contact The interface is enabled on both).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD manager includes a DAD application server (sometimes referred to as a mobile application server) for Provide each application to a DAD (for example, an App that can manage the operation of the DAD through a DPD, where the DPD will be linked to the DAD). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the DAD application server is operable as the DPD manager gateway and the other components of the DPD manager (Such as the DPD content management system, the DPD application management system, and the DPD key manager). In some other embodiments of the present invention and/or in some other embodiments of the related art, the DAD application server may also be operated to store DAD applications for installation on the DAD ( Mobile application) configuration file. Digital Transaction Device (DTD)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD (usually DTC in this specific embodiment) can be operated to participate in the digital transactions through DTD is a POS terminal or EFTPOS terminal (such as the term used in Australia). In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the DTDs are ATMs. In still other specific embodiments of the present invention and/or in still other specific embodiments of the related art, the DTDs may be personal computers with DTC readers. In still further embodiments of the present invention and/or in still further embodiments of related technologies, the DTDs may be mobile devices (such as smart phones) with DPD readers. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, for a DPD that includes non-financial (or non-payment) personal characteristics, DTD may include one of the following or More than one: a passport reader, a driver’s license reader, and a transit agency validator.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DPD is also adapted to be operable to participate in the DTDs used by digital transactions, so as to be operable for communication between them. Link to the DPD Data Assist Device (DAD), and provide data, commands, files, and other digital objects and information between the DPD and the DTD (when used as a DAD).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DTPU in the DPD can be operated to host one or more transaction types associated with the PDTP and/or the payment voucher code PDTP Below, some DTDs used by the DPD to participate in digital transactions can be operated to display a list of available transaction types, that is, the DPD user or the DTD operator can choose from them to determine that the DTD will target the digital transaction And call which transaction applications are associated with the selected transaction type.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DTPU in the DPD can be operated to host one or more transaction types associated with PDTP and/or payment voucher code PDTP Next, some DTDs used by the DPD to participate in digital exchanges can be operated to automatically select transaction types. In some specific embodiments of the present invention and/or in some specific embodiments of its related technology, the DTD is presented with a transaction application identifier (AID) with a priority indicator for each transaction application identifier In the candidate list (candidate list), the DTD can be operated to select the transaction application identifier with the highest priority for the digital transaction.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, the DTPU in the DPD can be operated to host one or more transactions associated with PDTP and/or payment voucher code PDTP In the case of type, before presenting the DPD to the DTD for a digital transaction, select the transaction type on the DPD or through the DAD. In this case, by using the related one or more transaction applications The selected applications set by the identifiers, or through direct selection (where all other transaction applications are locked), only provide the DTD with the associated one or more transaction applications associated with the selected transaction type Program.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DPD can be operated to participate in the DTDs used by digital transactions, and can be operated to display data from the digital transaction period. When the transaction application identifiers of one of the one or more selected applications are selected, a candidate list of transaction application identifiers is constructed. Issuer

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the issuer is the party authorizing the payment service to be provided by the DPD. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the issuer is the party that authorizes the non-payment service provided by the DPD, such as the passport issuer. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the issuer may be a financial institution or a party authorized by a bank. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the issuer authorizes the supply network to supply the DPD when it is in use.

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, at least one of the one or more issuers authorizes the issuance of DPD to the user. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each issuer authorizes the issuance of one or more digital cards or one or more digital cards for installation on the DPD Digital files.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the issuer issues the DPD to the cardholder (or DPD user). In other specific embodiments of the present invention and/or other specific embodiments of related technologies, the DPD is issued by another authorized provider (sometimes referred to as an issuer or distributor of additional cards). However, in this manual, the system will be exemplified by the initial card issuer.

In other specific embodiments of the present invention and/or other specific embodiments of related technologies, the supply infrastructure can be operated by multiple issuers (for example, issuers of many different banks and/or financial institutions). In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the supply network may be associated with a single issuer.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the issuer will retain the authority for processing by the PDTP hosted on the DPD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the issuer has security control over at least a part of the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, this control can be achieved by allowing the issuer to have an SSD key for each of the SSDs. One or more SSDs in the DTPU have the authority to implement. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the issuer can operate to delegate authority to process (including security of at least a part of the DTPU) by the PDTP hosted on the DPD Control), and by having an SSD key for each of the SSDs, one or more SSDs in the DTPU are authorized. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, this delegation system is for TSP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the issuer may also have control (as the owner) of the personally-specific transaction key used for PDTP .

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the issuer may have a main purpose other than finance, but focus on issuing financial instruments (including credit and debit cards) to customers . For example, a ride-sharing provider may be an issuer who issues a card for payment for rides. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the issuer may be an entity or organization that provides non-financial documents (such as ID, passport, and age verification card).

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, the issuer is outside the supply network, but communicates with the supply network to provide the required digital objects, For example, personal-specific data and/or personal-specific command set documents.

In a further specific embodiment of the present invention and/or in a further specific embodiment of its technology, the issuer includes one or more of a TSM and a TSP. Security class

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the DTPU is provided with a security level, wherein the highest authority is assigned to the issuer security domain (ISD) and is lower than the ISD Each of the security domains is called a secondary security domain (SSD). In this hierarchy, the SSDs or the security domains under the SSDs can also be referred to as nodes. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of related technologies, the DTPU may include multiple security levels. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the DTPU is provided with a security level, wherein the installed first application is allocated to the issuer security domain (ISD).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each field in the security hierarchy is provided by a cryptographic key (in each specific embodiment, a symmetric key) ) To ensure security, the cryptographic key allows only one or more parties with (or possessing) the access authority of the same cryptographic key to access the secure domain for operations therein. When a party has authority or control over a secure domain, this usually means that the party owns or controls the cryptographic key used in the secure domain, so that the party can encrypt (or sign) instruction set documents with the cryptographic key. Therefore, the encrypted instruction set documents will target the security domain (or any one or more applications directly under the security domain), and verify the SSDs that will be allowed to perform operations under the security domain.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each bank (or financial institution), or issuing institution, or non-existing institution on the DPD (or on the DTPU) Bank/Issuing Authority (Non-Bank/Issuing Authority, NBIA) third parties may have different SSDs in the DTPU security hierarchy.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the security class is configured to allow one or more third parties (each of which is not a bank or issuing institution) to personalize the Application on DTPU. This third party can be referred to as a non-bank/issuer (NBIA) third party.

Generally, banks or issuing agencies, or NBIA third parties, and SSDs will reside under the ISD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each bank, issuing institution, or NBIA may be able to host in several different payment schemes or several different non-payment schemes PDTP or trading application. For example, "Bank A" may be able to use Visa and Mastercard to host PDTP or transaction applications, and "Bank B" may be able to use Visa, Mastercard, and American Express to host PDTP or transaction applications. In some of these specific embodiments of the present invention and/or in some of its related technologies, each payment or non-payment scheme hosted by a bank or issuing institution can be under its own separate SSD, where Each of these payment or non-payment scheme SSDs is directly under the SSD of the bank or issuing institution.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, there may be an SSD for "Bank A" on the DTPU, and the field of "Bank A" includes one in "Bank A". "PDTP A1" under "Payment Plan A1" (e.g. Visa) (e.g. a credit card PDTP); the field of "Bank A" also includes a "PDTP A2" under "Payment Plan A2" (e.g. Mastercard) (e.g. a transfer Card PDTP). The DTPU may further include an SSD for "Bank B"; and the field of "Bank B" includes a "PDTP B1" (such as a credit card PDTP) under "Payment Method B1" (such as American Express); The field of "B" also includes a "PDTP B2" (e.g. a debit card PDTP) under "Payment Plan B2" (e.g. Visa).

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, a third party who is not a bank may also have an SSD on the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the security level is configured to be suitable for operation by TSM. In this tier, there is a lower part of the tier (or sub-tier), in which the SSD at the top of the sub-tier is issued and one or more lower SSDs below the top SSD (each hosting PDTP) control. In some such specific embodiments of the present invention and/or in some of its related technologies, each lower SSD can be used for different payment schemes (eg Mastercard, Visa, American Express). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each DTP/PDTP has one or more SSDs, and each of these DTP/PDTP SSDs is at least A transaction application program is associated (each transaction application program is associated with the DTP/PDTP).

In other specific embodiments of the present invention and/or in other specific embodiments of its related art, the security hierarchy is configured to be suitable for operation by TSP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, in this level, there is a lower part of the level (or sub-level), where at the top of the sub-level The SSD is controlled by a payment scheme (such as VTS for Visa, MDES for Mastercard, or AETS for American Express) and one or more lower SSDs under the top SSD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each of the lower SSDs is used by one or more issuers to host one or more PDTPs (These SSDs can be owned by TSP), where each PDTP is used in the same payment scheme. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, each DTP/PDTP has one or more SSDs, and each of these DTP/PDTP SSDs is at least A transaction application program is associated (each transaction application program is associated with the DTP/PDTP).

In other specific embodiments of the present invention and/or in other specific embodiments of its related art, the security hierarchy is configured to be suitable for operation by both TSM and TSP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the security hierarchy includes sub-levels that are configured for both TSM and TSP operations as described above.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the security hierarchy includes a locked SSD, which is operable and used to lock all the SSDs below it. In some of the specific embodiments of the present invention and/or in some of the related technologies, the locked SSD can implement Cascade lock (this can be operated to lock all directly and indirectly related SSDs) Below the locked SSD), this is caused by a single locking command and has the advantage of not requiring every SSD in the hierarchy below the individually locked locked SSD.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the security layer includes an application selection module SSD, which is an SSD that selects one or more applications, including one One or both of the PSE selection application for contact digital transactions and a PPSE selection application for non-contact digital transactions.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the security hierarchy includes one or more utility security domains (USD), and it will be understood that the term is used in this specification "USD" means the SSD used for the container. Use each USD to host one or more containers for the payment scheme. In some of these specific embodiments of the present invention and/or in some of its related technologies, there are three USD, of which the first USD is hosted for the Visa container and the second USD is hosted for the ELF of Mastercard, And the third USD escrow is used for ELF of American Express.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the security domain (under ISD, USD, or SSD) in the security hierarchy is configured so that its key only accesses the The immediate security domain of ISD, USD, or SSD. In other specific embodiments of the present invention and/or in other specific embodiments of the related technology, the security domain is configured such that its key accesses all security domains under the immediate security domain.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technology, the bank or the issuing institution (for example, the bank or issuing institution that issued the DPD) will manage the ISD used for DTPU (including through the ISD holds and operates). In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, a third-party management agent (separate from the bank or issuing institution that issued the DPD) can be appointed to manage the ISD (including borrowing) used for DTPU. Owned and operated by the ISD). In yet other specific embodiments of the present invention and/or in yet other specific embodiments of related technologies, banks or issuing agencies and third-party management agents can manage ISDs used for DTPU.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DTPU has an SSD used in the field of banks or other types of issuing agencies. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, the DTPU has a plurality of SSDs used in the field of different banks or other types of issuing agencies. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, at least one SSD of the one or more SSDs hosts at least one PDTP or at least one transaction application. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, although the SSD used for banks or other types of issuing institutions can be installed on the DTPU, the specific SSD may not Host any DTP/PDTP or trading application.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technology, each DTP/PDTP is associated with a payment scheme. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, under a specific SSD used for banks or other types of issuing institutions, only one DTP/for each payment scheme is allowed. PDTP or a trading application. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, under a specific SSD used for banks or other types of issuing institutions, more than one for each payment scheme is allowed DTP/PDTP or more than one trading application.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DTPU can be operated to have multiple SSDs installed on it for different banks or other types of issuing institutions, but the DTPU is limited to allowing DTP/PDTP or transaction applications hosted on it to be associated with only one payment scheme. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technology, the DTPU is limited to allow DTP/PDTP or transaction applications hosted on it to be only related to a limited range of payment solutions United.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DTPU can be operated to host multiple SSDs, multiple PDTPs, and PDTPs under those SSDs for different banks or other types of issuing institutions. Or transaction applications (sometimes used in multiple payment schemes), some of which PDTP or transaction applications have an associated payment certificate code PDTP or payment certificate code transaction application, and some of these PDTP or transaction applications have no associated payment Voucher code PDTP or payment voucher code transaction application, some of which PDTP or transaction application and/or some payment voucher code PDTP or payment voucher code transaction application have associated multiple transaction types, and some PDTP or transaction application and/or Some payment voucher codes PDTP or payment voucher code transaction applications do not have an associated transaction type, and each PDTP or transaction application, payment voucher code PDTP or payment voucher code transaction application, and/or transaction type has one or more related transactions One or more related trading applications include a single dual-contact/non-contact interface trading application, each of the two trading applications has a contact or non-contact interface, or a dual interface and A mix of trading applications with a single interface. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DTPU hosts some or all of the various bank/issuer SSDs, PDTPs, or transaction applications, payment certificate codes PDTP or Payment certificate code transaction application, transaction type, and transaction application. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DTPU only hosts a single bank/issuer SSD, where a single PDTP has one or more associated transaction applications or a single transaction application.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DTPU can be operated to host only the above-mentioned limited range of various bank/issuing institution SSDs, personal-specific features, Payment certificate code PDTP or payment certificate code transaction application, transaction type, and transaction application. Control Agency Security Domain (CASD)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU includes a field, which is called a Control Agency Security Domain (CASD). CASD is an additional security domain usually available in mobile device applications on UICC or eSE chips.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the CASD is used to promote trust between the DPD manager and other parties (such as the issuer or NBIA).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the DPD manager is operable to install SSDs and instantiate transaction applications under those SSDs. In this case, The DPD manager has control over the cryptographic key used for each SSD it has installed. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager transfers control of one of the security domains to another party (such as the issuer or NBIA ), so the other party can operate on the one or more transaction applications in the security domain, but what is required is not that the DPD manager directly provides the cryptographic key for the SSD to the other party. A CASD controlled by a mutually trusted third party can be operated to assist in key rotation on the SSD so that the control of the SSD is passed to the other party, where the SSD is now controlled by the cryptographic key of the other party and has not yet been potentially sent to The DPD manager reveals this key. Then, the other party can verify the SSD with its cryptographic key so that it can operate on the one or more transaction applications in the secure domain. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the other party may personalize the one or more transaction applications.

In some of these specific embodiments of the present invention and/or in some of its related technologies, the CASD is provided to the "Finance" approved chip used as the DTPU (such as usually used in credit and debit cards). Used in). It will be understood that since this "finance" chip has not previously provided one or more of the following, it does not yet require CASD: new personal features from the supply agent, new DTP/PDTP, or new trading applications.

In other specific embodiments of the present invention and/or in other specific embodiments of its related art, the DTPU is a UICC/eSE type chip, in which the DTC (or more generally, the DPD where appropriate) is adapted to allow the UICC type chip operations are used for both contact and contactless transactions, and the DTPU has CASD installed therein.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the CASD is on the DTPU when it is issued by the chip manufacturer or supplier. In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the CASD can be provided to the DTPU when it is away from the supply agent or supply network. Cryptographic key

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each security domain (for example, including ISD or SSD security domain) in the security hierarchy has an associated cryptographic key or key Set, sometimes abbreviated as key or key set. If the operation will be performed in a specific security domain, a cryptographic key is required to generate a session key for encrypting the command set document or command, so that the command set document or command can verify the SSD in the security domain. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, one or more security domains are configured so that their keys only access the directly associated applications of the SSD, or may be It is configured so that its key accesses all the security domains of the SSD under the immediate SSD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, in the security hierarchy, there may be several different types of fields, including ISD, SSD, CASS, and USD (all of which are Have an SSD that is set as a flag to provide certain privileges). Transaction key

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, in a transaction via DTD, when participating in a digital transaction via the DTD, the DTPU and the issuing bank Need security between. In part, this security is provided by a cryptographic key included in the personalization of DTP (to become PDTP). The transaction key is usually owned by the PDTP issuer (which may be a bank or other such institution) and is only known to it.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, transaction funds for PDTP (or for any of the transaction applications associated with the PDTP) are used The key and other inputs used for each digital transaction between the DPD (or DTPU on it) and the DTD generate the transaction session key. Trading application

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD is operable to pay for digital transactions. Transaction applications used for payment transactions can be referred to as payment applications. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DPD can be operated for non-payment digital transactions (such as identification transactions), wherein the DPD can be a passport or driver’s license exclusive to individuals feature.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each transaction application has a transaction application identifier. In some specific embodiments of the present invention and/or in some specific embodiments of related technologies, the transaction application identifier is an application ID (AID).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, such as on JavaCard (or on DPD using JavaCard or similar JavaCard technology), the transaction application is implemented on the DTPU as Java applets, and these are sometimes called transaction apps, payment apps, or simply apps.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each transaction application is instantiated on the DTPU and includes data when personalizing it, such as the transaction application The PAN of PDTP through which the program is associated. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the PAN and other data of the personal-specific feature are located in another application that is also associated with the personal-specific feature. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related technology, the PAN and other data of the personal-specific characteristics are located in another memory area of the DTPU (for the transaction application Have the access right to read the PAN). The other information of the personal characteristic may include the expiration date of the personal characteristic, the name of the owner (cardholder's name) used for the personal characteristic, and the payment voucher code PAN of the personal characteristic.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD manager may be operable to provide instruction set files to the DTPU for instantiating the transaction application on the DTPU . In still other specific embodiments of the present invention and/or in still other specific embodiments of its related technologies, other supply agents (such as TSM and TSP) may be operable to provide instruction set documents to the DTPU for personalization Trading application.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, DTP has one or more associated transaction applications. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, the one or more transaction applications are associated with the DTP (assuming that the one or more transaction applications are not yet personal Exclusive).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, PDTP has one or more associated transaction applications. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, the one or more transaction applications are associated with the PDTP after the personalization of the one or more transaction applications Associated. Trading interface

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the transaction application program may have one or more interfaces, which are sometimes referred to as digital transaction interfaces or digital transaction communication channels. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, a single transaction application program with dual interfaces for both contact and non-contact transactions is provided, so it is useful for contact transaction applications The PSE (contact selection application) for program identification and the application selection module of PPSE (contactless selection application) for the identification of contactless trading applications provide the same AID.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, two trading applications are provided, one is a contact trading application with a contact trading interface, and the other is a contactless trading interface Contactless trading application. In this implementation, different AIDs are provided for the application selection modules for the PSE and for the PPSE.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, it is possible to provide both dual contact/non-contact interface transaction applications, and each of these two transaction applications Has a single contact or non-contact interface. Digital transaction

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, digital transactions occur between the DTPU and DTD of the DPD in the transaction network. In a number of specific embodiments, the digital transaction of the DPD is subject to the EMVCo standard specification for data transmission and security between the DTPU and the DTD. Although the present invention (and its related creative technology) envisages digital transactions for both financial and non-financial purposes, most of the description and specific embodiments are directed to financial digital transactions (sometimes called payment transactions or simply payment). Transaction Type

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each PDTP/personal-specific feature can have one or more transaction types (or digital transaction types) associated with it. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the transaction type may be an account, and if the PDTP/personal-specific feature has two associated transaction types, one transaction type may be An account used for U.S. dollar (USD) currency transactions, and another transaction type can be a Euro currency account. In some of these specific embodiments of the present invention and/or in some of its related technologies, the card user can choose which transaction type will be used for the PDTP/personal exclusive feature during the digital transaction, and can For example, choose among different currency accounts linked to the same PDTP/personal specific characteristics (or linked to the same primary identifier or PAN). In some of these specific embodiments of the present invention and/or in some of its related technologies, the different transaction types associated with a single PDTP/personal-specific feature may also include transaction types for the same account, but With different information registered for account records or statements (Statement).

In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each transaction type is associated with a transaction application of PDTP. In some of these specific embodiments of the present invention and/or in some of these specific embodiments of its related technologies, each transaction application associated with a transaction type will be individualized by the data to enable the associated transaction The digital transaction will be operated to associate the digital transaction with the transaction type.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, examples of different transaction types that can be associated with a single PDTP/personal-specific feature include: ● Two or more accounts in different currencies; ● Multiple accounts of different family members (partners, children, siblings, parents, etc.); ● Multiple accounts of different expenditure categories in the enterprise (or the same account with different registrations in the account statement); ● Enterprise/personal expenses (can be the same account, but different registered on the account statement); ● Different transaction types of multiple loyalty reward programs (maybe each is linked to the same account).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technology, the card user (or DPD user) can choose which transaction type will be used for the PDTP/personal exclusive during the digital transaction Features, and can be selected, for example, among different currency accounts that are linked to the same personal-specific feature (or to the same primary identifier or PAN for each of the transaction applications in the associated PDPD).

In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the DPD can be operated to automatically select which transaction type is used for the personal-specific features of the current operation of the DPD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, the DPD user programs the DPD to whatever personal-specific feature is selected as the operable personal-specific of the DPD The features always use the United States (US) currency account, as long as the US currency account is an available transaction type option for the selected operating personal feature. The programming for the automatic transaction type selection can be realized through the DPD user interface or through the DAD user interface when the DAD is linked to the DPD for communication therebetween. In yet another usage example for this specific embodiment, the DPD user may be traveling in Europe and can program the DPD to use the Euro account transaction type (or payment type), where this transaction type can be used exclusively for the selected individual feature. In some of these specific embodiments and in situations where a specific currency account transaction type for personal-specific features is better but not available, the DPD can be operated to default to the selected default transaction type. Digital transaction package (Digital Transaction Package, DTP) / personalized trading of digital packets (PDTP)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, a digital transaction package (DTP) is a grouping of one or more transaction applications, and each transaction application has a function for participating The contact and non-contact interface or both of digital transactions via DTD in the transaction network.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DTP uses a container to instantiate on the DTPU and introduce an SSD elsewhere in the security hierarchy of the DTPU. Once the target SSD is introduced, the DTP is subsequently personalised to become a personalised DTP (PDTP).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the SSD introduced by the DTP is installed at a selected location in the security hierarchy before the DTP is established and extradited. On DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the SSD is created by one or more instruction set documents provided to the DTPU by the DPD manager.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTP is established on the DTPU by referring to the container used for the specific payment scheme, and the specific payment scheme is provided to communicate with the DTP. A library of the functions of the one or more trading applications associated with it to operate on the DTPU used for trading. For example, the DTP for Visa credit card is created on the DTPU by transmitting the instruction set document of each command to the ELF (container) for the Visa credit card, wherein the container is created on the DTPU in a part of the memory of the DTPU. The one or more trading applications associated with DTP. At this stage, the DTP has not been personalized, so one or more of its associated trading applications do not have any one or more of the associated primary identifier (PAN), expiration date, transaction key, and other personally-specific data However, the DTP only has one or more associated trading applications and trading interfaces, none of which has been personalized.

In this specification, unless otherwise indicated or where the context requires or is beneficial, DTP only includes these transaction applications and/or associated payment interfaces. DTP does not include personally specific data, which is associated with the designated card. For example, the DTP used for credit cards does not include the PAN, cardholder name, expiration date, and other personally-specific information. The DTP may be personalized to become a Personalized Digital Transaction Package (PDTP). In this case, personally-specific information is provided to or through the DTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, personally-specific data is written into the DTP to become a PDTP. In some specific embodiments, the personalized data is provided to the DTPU (on which the DTP is installed in the form of an instruction set document), so that the DTPU can convert the DTP to PDTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, DTP/PDTP is operable for both contact and non-contact transactions (or has operable for contact and/or non-contact transactions). One or more related transaction applications that contact both transactions). In other embodiments, DTP/PDTP may only be operable for one of contact or contactless transactions (or have one or more associated transaction applications operable for contact only or contactless transactions).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, some DTP/PDTP are suitable for payment transactions, and some are suitable for non-payment transactions, such as safe storage and display (or safe display) of individuals ID, age verification, and other non-payment functions.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the instruction set documents that can create the DTP/PDTP may also be based on other DPD files and data (including metadata) Provided to the DPD, including: ● Can provide a file for the logo or mark of the payment scheme associated with the DTP/PDTP (which will be displayed on the graphical user interface of the DPD); ● A file containing one or more AIDs associated with the one or more trading applications (which are provided to the DTPU used to update the application selection module), in the operation of the DTPU (or the DPD) When the personal characteristics are changed to those associated with the PDTP, the PSE and PPSE selection applications are included. In alternative embodiments, the same or multiple modified application selection module files (including the AID used to provide the DTP/PDTP to the one or more trading applications) can be connected to provide the DTP/PDTP, where the modified application selection module file is installed on the DTPU to overwrite or replace the previously installed modified application selection module file; ● A file containing the PAN of PDTP displayed on the graphical user interface when the PDTP is used for the operation of the DTPU when the PDTP is used, and is associated with the operation personal characteristics (sometimes referred to as metadata) of the DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each PDTP is a form of personal-specific features, the PDTP is installed on the DTPU, and other forms of personal-specific features Metadata associated with the PDTP. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the metadata associated with the PDTP and constituting the personal characteristic is stored by any one or more of the following: the DPD , The DAD, and the DPD manager. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the metadata associated with the PDTP and constituting the personal characteristic is stored by any one or more of the following: TSM, TSP, and the issuer.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, if the payment solution does not have a container on the DTPU, or if the existing payment solution on the DTPU needs to replace the container , Then the DTPU can be provided with a container for the new payment scheme. If a new payment solution container is loaded on the DTPU, a new USD security domain is created and the new container is loaded (or installed) therein. In specific embodiments, the instruction set document(s) that can establish the USD can be provided by a party (such as the DPD manager), and the instruction set document(s) that can create the container under the USD can be provided by the Payment plan or provided by the DPD manager. In some such embodiments, the key rotation for the USD may be required before the container is installed in the USD through the payment scheme.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, each DTP/PDTP is associated with a separate security domain. In this specific embodiment, all commands (as APDUs) used for or associated with the DTP/PDTP must verify the security domain of the DTP/PDTP. Usually, the security domain is SSD. In some of the specific embodiments of the present invention and/or in some of the related technologies, the SSD of the DTP/PDTP can host contact and contactless instances (applications) together or store them in In a separate sub-security domain (sub-SSD).

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the security domain associated with DTP/PDTP (for example, associated with the personal-specific characteristics of the DPD) can be used for the The key set of the security domain (cryptographic key set, such as the SCP02 key set for OTA communication or SCP80/81 for OTI communication) is replaced with a new key set and re-personalized. In this specific embodiment, and especially when the instances (applications) are in separate subdomains, changing the key set will not affect the ELF (containers) or applications associated with the security domain /Instance.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, DTP/PDTP has a plurality of associated transaction applications, and one or more of the plurality of transaction applications are used for The first transaction type, and one or more of the plurality of transaction applications are used for the second transaction type. In this specific embodiment, the first transaction type is used for a first account associated with the PAN of the PDTP, and the second transaction type is used for a second account associated with the PAN of the PDTP. In specific embodiments, in the personalization, the one or more transaction applications associated with the first transaction type are personalized by data including a first serial number, and are associated with the second The one or more transaction applications associated with the transaction type are personalized by data including a second serial number.

In the example use of this specific embodiment, the DPD user may choose a PDTP with different transaction types of transaction applications from among several selectable PDTPs installed on the DTPU of the DPD, and then the DPD user may choose from Select the account used for the PDTP among the several selectable accounts of the PDTP, and the MCU of the DPD requests the command set documents from the OSE to (by targeting the locked SSD) lock all PDTPs (or with All the related transaction applications are locked in the DTPD. Then, the MCU requests an unlock instruction set document that only targets the one or more transaction applications in the selected PDTP associated with the selected transaction type (selected account), and the MCU uses the unlock instruction set The document is transferred to the DTPU for execution. In some embodiments, the unlocking instruction set document targets the application selection module (by targeting one of the PSE or PPSE selection applications in the application selection module) to update first The registration form of the application selection module may include the AID(s) of the one or more trading applications to be unlocked, and then the application selection module may unlock the one or more trading applications (In some scenarios, the SSDs of the targeted trading applications can remain locked when the trading applications target locking or unlocking). Then, the DPD can be presented to the DTD through contact (introduction) or non-contact (swing or tap) for digital transactions. The application selection module will provide the AIDs (in the candidate list) to the DTD, and the unlock transaction applications will be available for digital transactions through the DTD (if the DTD participates in direct selection instead of using the For PSE to conduct contact transactions, it is important not to lock the selected transaction application). During this digital transaction, the transaction application provides the PAN and the serial number (and other information) to the DTD, where the provided serial number allows the issuer (such as a bank) to associate the required PAN for transfer One of these one or more accounts is the target. Personal characteristics

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the personal-specific feature includes a PDTP (hosted on the DTPU), together with metadata associated with the PDTP. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the metadata is hosted by any one or more of the following: the DPD (for example, on the MCU), the DAD, and The DPD manager.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, personal-specific features or digital transaction personal-specific features include various aspects of the appearance and operation of the PDTP (such as the user of the PDTP) Observed). In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the personal-specific feature is also associated with the cardholder’s name, expiration date, CVV, and various other information. However, in In a number of specific embodiments, each individual’s unique characteristic is mainly related to its PAN or its unique identifier (for PAN, each issuer has a different combination of the first six PAN digits, and each holder Cardholder account number (the rest of the PAN digits are different). For personal characteristics of payment transactions (such as credit or debit cards), the PAN is always a number. Other types of transaction cards or documents (such as passports, driver's licenses, and age proof cards) may have special identifiers with alphanumeric characters.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, DTPU may have one or more personal specific features (PDTP), wherein each personal specific feature is associated with at least one PAN or Another unique identifier is associated.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each personal-specific feature (or associated DTP/PDTP) is associated with one or more transaction applications.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD can have more than one effective personal-specific feature at the same time. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD has valid financial personal-specific features (such as a credit card) and valid non-financial personal-specific features (such as a driver's license). These two different types of personal-specific features have different trading applications on the DTPU associated with the personal-specific features, and these different trading applications can be operated by different types of DTDs. Therefore, when the personal-specific features are valid on both the DPD (and the DTPU), they will not conflict when used in the different DTDs. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, there can be two financial personal-specific features available on the DPD at the same time, however, one-person-specific features will be limited to Only contact transactions, and the exclusive characteristics of another person will be limited to only non-contact transactions. If not, these two financial personal exclusive characteristics will cause conflicts in the performance of the DTD. Payment Voucher Code PDTP

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each PDTP can be associated with one or more payment voucher code transaction applications, which are used for each associated transaction The main identifier of the application has different payment voucher code values (for financial PDTP, the main identifier is PAN). In the case of using the symbolic PDTP, in order to enhance security, the graphic display of the DPD may only display the PAN used for the symbolic PDTP, but not the main PAN of the PDTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, when each of the one or more transaction applications associated with the DTP is personally exclusive When implementing DTP, each of the one or more transaction applications is personally exclusive by a different payment voucher code identifier associated with the one primary identifier.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the payment certificate code PDTP with the associated payment certificate code transaction application may be provided for enhanced security, because the actual PDTP The main identifier (or PAN) is not revealed for the transaction, but the main identifier of the payment voucher code is used. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the graphic display of the DPD (if it has a graphic display as required) may only display the transaction application for the unlocking payment voucher code The main identifier (or PAN) of the payment voucher code of the program, but the main identifier (or PAN) of the unlocking transaction application program is not displayed.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, among the one or more payment certificate code transaction application programs that use the payment certificate code PDTP associated with the personal characteristic One conducts digital transactions instead of the unpaid voucher code transaction application.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, one or more payment voucher code transaction applications are available (each payment voucher code transaction application is associated with one or more One of the payment voucher codes PDTP is associated, and each payment voucher code PDTP is associated with personal characteristics or payment voucher codes personal characteristics), the DPD can be operated for DPD users (sometimes called DPD) The holder, DTC user, or cardholder) chooses from the payment voucher code transaction application, and the unpaid voucher code transaction application is used for digital transactions. In further embodiments of the present invention and/or in further embodiments of related technologies, the DPD is operable for the DPD user to select among a plurality of payment voucher code transaction application programs for digital transactions One.

In still other specific embodiments of the present invention and/or in still other specific embodiments of its related technologies, the DPD is configured to use payment voucher code transaction applications, and at least one of the available payment voucher code transaction applications is used for The effective PDTP associated with the personal characteristics of the DPD operation. In further embodiments of the present invention and/or in further embodiments of related technologies, if there is an available payment voucher code transaction application program for a valid PDTP associated with the personal-specific feature of the DPD operation Within the range, the DPD is configured to automatically select one of the payment voucher code transaction applications. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the automatic selection is random or pseudo-random from the range. In other such specific embodiments, the selection is based on the preset sequence of the payment voucher code transaction application programs in the range.

Although a payment certificate code service provider (TSP) can be used in some embodiments to supply one or more DTP/PDTP (each PDTP is associated with the personal characteristic of the DPD) to the DTPU, it should be noted that this The supply may only use a single PAN for each PDTP as provided by the TSP (that is, a single PAN used to personalize one or more transaction applications associated with the DTP/PDTP) instead of the PDTP. Multiple payment voucher codes PAN related to the main PAN. Application selection module and application selection

When a DPD is provided to a DTD for a digital transaction, it must be determined which of the possible multiple PDTPs and/or which of the transaction applications related to the PDTP will be used to implement the payment transaction. Different DTDs in different parts of the world may be operated by different payment networks (transaction providers), so there can be several DTPUs with installed PDTP (with one or more transaction applications associated with each PDTP). The transaction is realized by only a subset of these several transaction applications. The procedure for selecting the one or more payment applications on the DPD that can implement payment transactions through the payment network available on the DTD is called application selection. Each transaction provider is far away from the agent of the DTD, and is able to perform the required actions for the transaction to be realized. For payment transactions between the payment DTC and the payment DTD, each transaction provider that can be operated by the DTD is a payment network, and can authorize payment from the cardholder's account to the DTD owner's account.

Application selection can occur in one of three ways: direct selection, selection through the payment system environment (PSE), or selection through the proximity payment system environment (PPSE). Use direct selection and PSE to conduct digital transactions via DTD. Use PPSE for non-contact digital transactions.

In direct selection, the DTD directly interrogates the SE/EMV+GP chip to find the unique AIDs for the payment applications. Then, the DTD will determine which of the available applications (if any) it can operate to implement payment transactions through the payment network available for the DTD. This procedure can have some uncertainty because DTDs operate in different ways. The DTD may simply select the first AID that it can operate or may browse all the available AIDs on the SE/EMV+GP chip. The DTC cannot control the direct selection procedure.

The PSE operates with the aid of an application program that has an associated unique AID and can be called a selection application, a PSE selection application, or a PSE application. The PSE method depends on the needs for both DTC and DTD used for contact transactions, and the fall-back option is directly selected. Depending on the region, the network, the build and configuration, or the supplier of the DTD, use PSE or select the method directly. For a standard credit or debit card with a single individual characteristic, the PSE application selection method is as follows: ● The DTD selects the PSE; ● The File Control Information (FCI) returned by the PSE includes the AID of the payment system directory; ● The DTD selects the payment system directory ADF; ● For each record in the ADF, the DTD reads the payment application AID; ● If the AID matches the AID (or more likely RID) on the DTD list of the payment application that can conduct transactions, the AID is entered into the candidate list created by the DTD; ● After processing the final record, the DTD selects the payment application AID based on the priority order saved by the PSE; ● Then, the DTD uses the selected payment application to process the payment transaction.

For the PSE, if the AID on the candidate list (sometimes referred to as the PSE list) does not match the AID for which the DTD is configured to operate, the DTD can be restored to direct selection.

PPSE also uses applications with unique AIDs to operate. The PPSE method is necessary for both DTC and DTD for contactless transactions. Unlike PSE, the PPSE application returns a list of available payment application AIDs in its FCI. For standard credit or debit cards with a single individual characteristic, the PPSE application selection method is as follows: ● The DTD selects the PPSE; ● The returned PPSE FCI has a list of AID and meta-information (such as payment application priority) for selection through the DTD; ● If the AID matches the AID in the DTD payment application list that can be used for transactions, then the AID is entered into the candidate list created by the DTD; ● After processing the last record, the DTD selects the payment application AID based on the priority order in the PPSE FCI; ● Then, the DTD uses the selected payment application to process the payment transaction.

The PSE application and PPSE application on the SE/EMV+GP chip are static, because the AID list used for these selected applications (usually filled during the personalization of traditional payment cards) is not within the operational life of the DTC. change. In addition, the traditional PSE and PPSE applications are adapted to function by the SE/EMV+GP chip with a single personal characteristic installed on it. Implementing PPSE on mobile payment devices (such as smart phones (on eSE)) is different from implementing PPSE for SE/EMV+GP on DTC. On mobile devices, PPSE dynamically adjusts the changes to the personal characteristics on the device, but PPSE on DTC does not need to adjust the changes, because with traditional DTC, these personal characteristics are issuing the DTC to the cardholder It remains fixed afterwards.

In some of the specific embodiments of the selection applications discussed below, the one or more transaction application identifiers set in the one or more selection applications will be understood to be one or more The identifier of the unlocking transaction application (associated with the effective (or enabled) PDTP of the DTPU, and the DTPU is associated with the personal characteristic of the DPD selected as the operable personal characteristic of the DPD). In some other specific embodiment selection application specific embodiments discussed below, the one or more transaction application identifiers set in the one or more selection applications will be understood to be one or Multiple unlocking payment voucher code transaction application identifiers (associated with the valid (or enabled) payment voucher code PDTP of the DTPU, the DTPU and the DPD personal characteristics selected as the operable personal characteristics of the DPD ( Or payment voucher code (personal exclusive feature) associated). In some other specific embodiment selection application specific embodiments discussed below, the one or more transaction application identifiers set in the one or more selection applications will be understood to be related to The identifier of one or more transaction applications associated with the selected transaction type itself (associated with the effective (or enabled) PDTP of the DTPU, and the DTPU is personally exclusive to the DPD selected as the operable personal characteristic of the DPD Feature correlation). In the specific embodiments of some other application selection modules discussed below, the one or more transaction application identifiers set in the one or more selection applications will be understood to be related to the selected One or more payment voucher codes associated with the transaction type. Identifier of the transaction application program (associated with the valid (or enabled) payment voucher code PDTP of the DTPU, and the DTPU is selected as the exclusive feature of the DPD to be operable) The personal characteristics of the DPD (or the personal characteristics of the payment voucher code) are associated).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DTPU includes an application selection module, wherein the application selection module includes a contact digital transaction (PSE Application) one or both of the selection application and a selection application for contactless digital transactions (PPSE application).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the application selection module is operable to be set by one or more transaction application identifiers. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the transaction application identifier is an application ID (AID).

In each specific embodiment of the present invention and/or in a number of specific embodiments of its related technology, when a personal-specific feature is selected as the effective personal-specific feature of the DPD, the application selection module uses the PDTP One or more transaction application identifier settings associated with the transaction applications (associated with the selected personal characteristics as the effective personal characteristics).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the personal-specific PDTP has a single associated transaction application (with dual contact/non-contact interface), and the single related The linked transaction application has an identifier (which in some embodiments is an AID). In this specific embodiment of the present invention and/or in this specific embodiment of its related art, each of the PSE and the PPSE selection application is set by the same identifier.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, PDTP has two associated transaction applications, one with a contact interface and the other with a non-contact interface, and these are associated Transaction application programs have different transaction application program identifiers from each other. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, the PSE selection application is set by the identifier of the transaction application having the contact interface, and the PPSE selection application is borrowed It is set by the identifier of the transaction application with the contactless interface.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, when the payment certificate code PDTP includes one or more payment certificate code transaction applications, and the PDTP is selected as the DTPU If one of the payment voucher code transaction applications is selected as the unlocking transaction application when the valid PDTP (or as one of the valid PDTPs) is selected, and when the unlocking transaction application is used to contact and non- In the case of the dual interface of both contact transactions, the transaction application identifier (AID) used to unlock the transaction application is provided to the application selection module to set the contact selection application with the same transaction application identifier Both the program and the non-contact selection application.

In still other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, in the case that the payment certificate code PDTP includes two or more payment certificate code transaction applications, and the PDTP is selected as the When the valid PDTP on DTPU (or as one of the valid PDTPs) is selected, two of the payment voucher code transaction applications (each with the same payment voucher code PAN) are selected as the unlock transaction applications, And when each of the unlocked transaction applications has one of a contact interface and a non-contact interface, the transaction application identifiers (AIDs) for each of the unlocked transaction applications are provided to the The application selection module is used to set each of the contact selection application and the non-contact selection application by using the respective transaction application identifiers used for the two unlock payment voucher code transaction applications.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, when the PDTP includes two or more transaction type transaction applications, and the PDTP is selected as the effective PDTP on the DTPU (Or as one of the valid PDTPs) when selecting one of these transaction type transaction applications as the unlocking transaction application, and when the unlocking transaction application is used for both contact and non-contact transactions In the case of dual interface, the transaction application identifier (AID) used to unlock the transaction application is provided to the application selection module to set the contact selection application and the contactless selection with the same transaction application identifier Both applications.

In still other specific embodiments of the present invention and/or in other specific embodiments of its related technology, in the case that the PDTP includes two or more transaction type transaction applications, and the PDTP is selected as the valid on the DTPU PDTP (or as one of the valid PDTPs) when selecting the second of the transaction applications (each with the same transaction type identifier) as the unlocking transaction application, and in the case of the unlocking transaction application In the case that each has a contact interface and a non-contact interface, the transaction application identifiers (AIDs) for each of the unlocked transaction applications are provided to the application selection module by The respective transaction application identifiers used for the two unlocked payment voucher code transaction applications are set to each of the contact selection application and the non-contact selection application.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the DTPU hosts multiple SSDs and multiple PDTPs (sometimes used In a variety of payment schemes), some PDTPs have an associated payment voucher code transaction application (payment voucher code PDTP), and some PDTPs do not have an associated payment voucher code transaction application, some of which PDTP and/or some payment voucher code PDTP has Multiple transaction types are associated, and some PDTPs and/or some payment voucher codes PDTP have no associated transaction types, and each PDTP, payment voucher code PDTP, and/or transaction type PDTP has one or more associated transaction applications, And the one or more associated trading applications include dual-contact/non-contact interface trading applications, each of the two trading applications has a contact or non-contact interface, or a mixture of dual-interface and single-interface trading applications . In this specific embodiment, how to set the transaction application identifier(s) for the one or more selected applications will depend on whether the selected PDTP, payment voucher code PDTP, or transaction type PDTP is consistent with a single Depending on whether the dual-interface trading application or two single-interface trading applications are associated.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the one or more selection application programs will interact with the selected operation PDTP, payment certificate code PDTP, and/or transaction type The transaction application identifier(s) of one or more transaction applications associated with PDTP (associated with the personal specific characteristics of the operation of the DPD) are placed in the registration table of the application selection module, with the identifier set up. In some embodiments, at least one of the selection applications is operable to automatically set its transaction application identifier when the transaction application identifier is placed in the application selection module registration table. In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, at least one of the selected applications has its identifier set when the identifier is placed in the registry, and A command is provided to the selected application to retrieve the identifier from the registry. In other specific embodiments of the present invention and/or in other specific embodiments of related technologies, the command is provided as an instruction set document or command delivered from the MCU.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the PPSE selection application automatically sets its transaction application identifier when the transaction application identifier is placed in the registry , And then PSE selects the application so that its transaction application identifier is set when the transaction application identifier is placed in the registry, and provides a command to the PSE selection application to retrieve the transaction application identifier from the registry symbol.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the one or more selection applications pass the identifier(s) as a parameter to the one or more The selected application is set by the transaction application identifier, wherein each of the one or more selected applications can be operated to reset itself by the passed transaction application identifier parameter.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, there are each of the same types associated with personal unique characteristics, payment voucher code PDTP, and/or transaction type PDTP ( Multiple trading applications with dual interface contact and non-contact, or single interface contact or non-contact), and each of these trading applications of the same type has a different trading application identifier with a priority indicator (in In the case of AID) in some specific embodiments, the one or more selection applications can be operated to set the plurality of transaction application identifiers of the transaction applications of the same type, and will be operated by The relative priority order indicator settings.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the one or more selection applications are called during the digital transaction and used in the one or more selection applications The transaction application identifier set in each of the programs constructs a candidate list of transaction application identifiers. The candidate list is used by the DTD in a digital transaction to determine which of the transaction applications hosted on the DTPU can operate the DTD to implement the digital transaction. In multiple specific embodiments where the selection application provides multiple transaction application identifiers (each for a different transaction application), the candidate list may include the priority order indicator provided by the selection application, which helps The DTD determines which of the transaction applications identified in the candidate list is best called by the DTD for digital transactions.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DTD can be operated to construct a candidate list of transaction application identifiers (in some specific embodiments, AIDs), which are The digital transaction is passed to the DTD so that the DTD can determine the identity of the unlocked trading application on the DPD that can be used for digital transactions. In some specific embodiments, the candidate list selects a new personal-specific feature (including selecting a payment voucher code transaction application associated with the PDTP of the personal-specific feature in the candidate list, and/or selecting a specific transaction type A trading application of the DPD) is constructed as a personal feature of the DPD. In some other such embodiments, the candidate list is constructed by the DTD when the DPD is provided to the DTD for digital transactions.

It will be understood that digital transactions are contact transactions or non-contact transactions, but not both. Therefore, the PSE selection application is called to provide the identifiers of the contact interface transaction application during the digital transaction, or during the digital transaction. Call the PPSE to select the application program to provide these identifiers of the non-contact interface transaction application program. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DPD is operable to pay through a QR code displaying a QR code by the DPD, the QR code representing the one or more One unlocked transaction application (or represents the PDTP/personal-specific features associated with the one or more unlocked transaction applications). Container (Container)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the basic load file (ELF) or package is called a container. It will be confirmed that the terms are interchangeable and applied as required by the technology used to implement the specific embodiments of the present invention. For example, if the specific embodiment is implemented on JavaCard (or uses similar JavaCard technology), the DTPU hosts a package for providing basic or general functions to the transaction application instantiated under the payment scheme. In this specification, the term "container" is intended as a general reference to ELF and package.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the container used in the present invention is implemented on the DTPU of the physical card (DTC) or on the DPD, and may be implemented by DTP/PDTP (see below) operations for both contact and contactless digital transactions.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, each container (for example, one or more ELFs containing the container) is associated with a payment scheme. In this security hierarchy, each container is installed (or hosted) under the associated USD. For example, the USD escrow used for the Visa payment scheme is used to establish one or more ELFs of Visa DTP on the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, a container is used to establish the DTP, and then it is introduced from under the USD of the container to an SSD elsewhere in the security hierarchy.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each USD can be locked or unlocked. The locking or unlocking of the container USD (or SSD) makes the container under it valid (unlocked) or invalid (locked) respectively. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, it is possible to restrict which payment schemes can operate on the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, for example, a payment solution (such as the Visa payment solution) may not need to use the DPD to host any of other payment solutions DTP/PDTP, such as Mastercard and American Express. The Visa payment scheme organization may request all USD used in payment schemes other than the USD in order to lock the Visa payment scheme. Then, the DPD will only be operable to create and install DTP/PDTP for the Visa payment solution. It can be understood that, in practice, which DTP/PDTP is established and installed on DTPU can be simply provided by simply not providing the components used to establish and install DTP/PDTP from payment schemes other than the required (or from multiple required) payment schemes Under the control of the supply network. However, allowing the locking/unlocking of the container USD provides additional assurance that the DPD can be controlled to only allow the establishment and installation of DTP/PDTP from one or more required payment schemes. Although the above description of containers focuses on those used in payment solutions, it will be understood that other types of containers can be hosted on DTPU, including programs used to create and host ID cards, passports, and other non-financial electronic documents A container for library functions.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DTPU includes at least some containers (ELF) installed, which are operable to be instantiated to pass through a TSP and a The instruction set documents provided by the two TSMs are further supplied (personal-specific) trading applications.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DTPU includes at least some containers, which are operable to be instantiated for further supply through a command set file provided by only one TSM (Personal exclusive) trading application.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DTPU includes at least some containers, which are operable to be instantiated for further supply through instruction set documents provided by only one TSP (Personal exclusive) trading application.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the container is operable to instantiate for further supply (personal-specific) through only the instruction set file provided by TSM In the case of a trading application, the DTPU can be operated to install another container, and it can be operated to instantiate a trading application for further supply (personal-specific) through only the instruction set file provided by the TSP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the container is operable to instantiate for further supply (personal-specific) through only the instruction set file provided by the TSP In the case of a trading application, the DTPU can be operated to install another container, and it can be operated to instantiate a trading application for further supply (personal-specific) through only the instruction set file provided by TSM. Digital object

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the supply network is operable to transmit digital objects to the DPD and the DAD, to the DPD via the DAD, and Via the DPD to the DAD. In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, the digital objects include commands, command set documents, command set document templates, metadata, firmware, and other files, It is used on the DPD and/or the DAD. Instruction set documentation and commands

In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, commands are transmitted to the DTPU to implement actions on the DTPU. In various situations, commands can be referred to as APDUs. In other situations, the command can be disassembled into APDUs.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, in the DTPU conforming to the GP standard, all commands transmitted to the DTPU are in the form of one or more instruction set documents.

In each specific embodiment of the present invention and/or in a number of specific embodiments of its related technology, some instruction set documents need to be processed by the SSD for the command used to authorize the security domain of the SSD. The session key derived from the password key of the verified SSD is encrypted.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, some instruction set documents do not need to be encrypted.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, some instruction set documents need to be encrypted, and the DPD can be operated to be stored and operated by a template instruction set document, wherein the template instruction The set document requires one or more parameters, and when the one or more parameters are written into the template command set document, the command set document is encrypted with a conversation key derived from a cryptographic key and a counter.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, some instruction set documents need to be encrypted, and the instruction set documents include a command instruction set document and a response instruction set document, wherein the response instruction set document It is generated when the DTPU has executed the command instruction set document, and the response instruction set document is transmitted by the DTPU via the DPD and returned to the relevant supply agent. Metadata (metadata) and the other end DPD files

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, each individual characteristic is associated with a single PDTP on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, each individual characteristic is also associated with metadata (related to the PDTP on the DTPU), wherein the metadata The data is recorded in a registry on any one or more of the following: the DPD (for example, in the MCU), the DAD, the DPD manager, and elsewhere. In this regard, personal characteristics include the PDTP and its associated metadata.

In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, the DPD is provided with files (sometimes referred to as DPD files and data) for the operation of selected components of the DPD , Where these files and/or data are not associated (or not directly associated) with the data and operations on the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD files and data include firmware commands for the operation of components, such as the DPD button, the DPD communication module , The DPD graphic display, and other such files and/or data. supply

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the supply network is operable to issue a certificate for supplying supply data associated with at least one DTP/PDTP to the DPD Of one or more supply entities. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the one or more supply entities include data, digital objects, software, or sending entities, which are used to establish communication At least one supply agent of the conversation generates or receives.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, supplying includes providing the one or more supply entities to the supply network and/or the supply infrastructure. DTPU includes data, digital objects, software, or sending entities, which are generated by the at least one supply agent. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the supply includes one or more responses from the DTPU back to the supply network, and the responses include data and digital data. One or more objects.

In some further embodiments of the present invention and/or in some further embodiments of its related technology, provisioning includes providing the one or more supply entities from the supply network and/or the supply infrastructure The MCU external to the DTPU or some other component of the DPD, including data, digital objects, software, or sending entities, is generated by the at least one supply agent. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, provisioning includes returning to one or more of the supply network from an MCU external to the DTPU or some other component of the DPD A response including one or more of data and digital objects. Supply information ( for this DTPU)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the supply data includes data associated with at least one DTP. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the data related to at least one DTP includes instruction set documents and/or commands for installing one or more SSDs on the On DTPU. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the data related to the DTP includes instruction set documents and/or commands, which are used to instantiate each in the one or One or more trading applications under one of multiple SSDs. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technologies, the data associated with at least one DTP includes instruction set documents and/or commands for personalization to make the DTP Become PDTP.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, one or more commands are sent from the supply network (or from at least one supply agent in the supply network) Collection documents and/or commands are provided to the DTPU to instruct the DTPU to establish or install the DTP, and to install or establish the DTP on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the instruction set document instructs the DTPU to refer to the container (e.g. Visa, Mastercard, American Express) associated with payment schemes ( For example, ELF) establishes the DTP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the at least one supply agent is the DPD manager.

In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, the supply data includes instruction set documents and/or commands for instantiating an application selection module on the DTPU Group, including one or both of a selection application for PSE and a selection application for PPSE, each of these PSE and PPSE selection applications can be operated to trade with the one or more One or more transaction application identifiers associated with applications (associated with the at least one DTP/PDTP) are provided to a DTD. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the supply data used to instantiate the application selection module is provided from the DPD manager.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the data associated with at least one DTP/PDTP includes a list of a PSE selection application and a PPSE selection application, Or one or both of a list of the application selection module, each list is used to modify its respective selection application to include one or more transaction application identifiers, which are associated with the at least one DTP/PDTP . In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, the list of PSE selection application and PPSE selection application is used for one of the MCU, OSE, or DPD outside the DTPU Installed or stored on other components, the MCU, the OSE, or other components can be operated to modify the PSE and PPSE selection applications on the DTPU with the data from each or both lists. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the at least one list is provided in the form of one or more instruction set documents and/or commands. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the at least one list is provided in the form of one or more template instruction set documents and/or template commands. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the one or more transaction application identifiers (AID) related to the at least one DTP/PDTP are in the metadata (Such as the metadata on the MCU), and provide the PSE selection application when selecting the personal characteristic (and/or payment voucher code transaction application, and/or transaction type) as the personal characteristic of the DPD operation The program and the PPSE select the application, or provide it to the application selection module.

In still other specific embodiments of the present invention and/or in still other specific embodiments of its related technologies, the data related to at least one DTP includes personally-specific data, including personalization for personalizing on the DTPU One or more commands and/or instruction set documents of at least one DTP, thus become a PDTP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the personal-specific data is provided by the TSM and/or TSP in the supply network. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the personally specific data is provided to the TSM and/or the TSP and converted by the TSM and/or the TSP One or more instruction set documents and/or commands. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the personal-specific instruction set documents and/or commands are provided from the TSM and/or the TSP to the DPD management , For delivery to the DPD.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the data related to at least one DTP/PDTP includes a container for providing functions related to the at least one DTP/PDTP, the A container is used to install on the DTPU, wherein the container is associated with the payment scheme for the DTP/PDTP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the container is operable to instantiate one or more of the DTP/PDTP (for contact and contactless payment) Multiple transaction applications to provide the functions required to operate DTP/PDTP for contact and contactless payments.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the digital object provided to the DTPU through the supply network includes the application selection module (including one or more PSE And PPSE selection application), the container, the DTP/PDTP, and any one or more of the personal data for the DTP (if provided separately). In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the digital objects used for the DTPU are established as APDUs through the supply network, or from digital objects through the supply network The object file is converted into APDU for installation on the DTPU. Supply information ( used for MCU or other DPD components outside the DTPU )

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the data associated with at least one DTP/PDTP includes at least one cryptographic key, which is associated with a respective at least one security domain Each at least one security domain is associated with the respective at least one DTP/PDTP. In this specific embodiment of the present invention and/or in this specific embodiment of its related art, the at least one cryptographic key is used to install or store on some other component of the MCU, OSE or DPD outside the DTPU . In some embodiments, the MCU, the CKSM, the OSE, and/or the other components can be operated to use the key to encrypt (verify) a template instruction set document and/or a template command to be used in the DTPU Documents and/or commands executed on the instruction set. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the at least one cryptographic key includes at least one key for a subsidiary security associated with the DTP/PDTP Domain (Subsidiary Security Domain, SSD). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the SSD key is used to encrypt/verify the communication between the MCU and the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the SSD key is stored in a secure memory on the DTC, wherein the secure memory is external to the DTPU . In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the secure memory system is a component of the MCU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the secure memory is in the OSE.

In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technology, the data associated with at least one DTP/PDTP includes at least one instruction set document for executing the at least one DTP The command on the DTPU associated with /PDTP. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, the at least one instruction set document is used to install or store some other component of the MCU, OSE, or DPD outside the DTPU on. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the MCU, the OSE, and/or the other components are operable to use the instruction set document to perform actions on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the at least one instruction set document is communicated with the security domain (where the DTP/PDTP will be executed on the DTPU) The associated SSD key encryption/verification instruction set document conforming to the standard. The instruction set document may include one or more commands for implementing one or more actions on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, the one or more actions include personalizing one or more transaction applications of the one or more DTPs Program. In other specific embodiments of the present invention and/or in other specific embodiments of its related technologies, the one or more actions include locking and/or unlocking a trading application.

In still other specific embodiments of the present invention and/or in still other specific embodiments of its related technologies, the data associated with at least one DTP/PDTP includes metadata for operating the DPD external to the DTPU Component, wherein the operation is associated with the at least one PDTP. In this specific embodiment of the present invention and/or in this specific embodiment of its related art, the metadata is used to install or store on some other component of the MCU or DPD outside the DTPU. In some specific embodiments of the present invention and/or in some specific embodiments of related technologies, the MCU and/or other components can be operated to display DTP/PDTP detailed information on the user interface and use the metadata . In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, data related to at least one PDTP is used by the DPD for displaying the primary identifier associated with the PDTP (for Payment card PDTP PAN), card image, cardholder name, expiration date, CVV, and other detailed information.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the digital object provided by the supply network to the MCU, OSE, or some other component of the DPD outside the DTPU includes The one or more command set documents, the one or more security keys, and the metadata. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, the digital objects used in the MCU, OSE, or some other component of the DPD outside the DTPU pass through the supply The network is created as a digital object for storage or installation on the MCU and/or other components.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the digital object provided by the supply network to the MCU, OSE, or some other component of the DPD outside the DTPU includes A list of updated application program selection modules includes a file related to the transaction application identifier (such as AID) of the DTP/PDTP installed or to be installed in the DTPU. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the MCU, OSE, or some other component of the DPD outside the DTPU can be operated to be selected by the updated application The transaction application identifiers in the module list update the application selection module. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the supply network provides the MCU, OSE, or some other component of the DPD outside the DTPU. The digital object is in the form of one or more command set documents and/or commands, and/or one or more template command set documents and/or template commands. Supply ( delivered to the DTPU)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the digital entities, data, and/or digital objects from the supply network to the DTPU are provided through a secure communication session Give this DTPU. In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the secure communication dialogue is based on one of the SCP01, SCP02, SCP03, SCP80, and SCP81 communication protocols. In some embodiments, the secure communication session is a synchronous secure communication session (Communication session).

In some specific embodiments of the present invention and/or in some specific embodiments of related technologies, the secure communication dialogue is based on SCP02 i=55. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the secure communication dialog is an asynchronous secure communication dialog.

In some specific embodiments of the present invention and/or in some specific embodiments of its related art, the supply network is selectively operable for both synchronous and asynchronous conversations. Supply ( delivered to MCU or other DPD components outside the DTPU )

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, from the supply network to the MCU, CKSM, OSE, or some other component of the DPD outside the DTPU Digital entities, data, and/or digital objects are provided to the MCU through a secure communication session. In some specific embodiments of the present invention and/or in some specific embodiments of related technologies, the secure communication dialog is based on the GP SCP11 communication protocol. In some specific embodiments of the present invention and/or in some specific embodiments of related technologies, the dialogue is a synchronous dialogue. In this other specific embodiment, the dialogue is an asynchronous dialogue. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the supply network is selectively operable for both synchronous and asynchronous conversations.

In some specific embodiments of the present invention and/or in some specific embodiments of its related technologies, the digital data from the supply network to the MCU, CKSM, OSE, or some other component of the DPD outside the DTPU Physical, data, and/or digital objects are provided through communication using TLS.

In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related technology, the digital entities and data from the supply network to the MCU outside the DTPU or some other component of the DPD , And/or digital objects are provided via SEMS or similar SEMS communication. Transaction application instantiation

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the supply network includes a DPD manager. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager is operable to provide one or more instruction set documents and/or commands to the DTPU of the DPD , To install one or more trading applications on the DTPU (each trading application is associated with the DTP). In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager is operable to provide one or more instruction set documents and/or commands to the DTPU of the DPD , To install one or more SSDs for each of one or more DTPs on the DTPU. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the DPD manager is operable to provide one or more instruction set documents and/or commands to the DTPU of the DPD , To instantiate each or more trading applications for one or more DTPs on the DTPU.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the DPD manager may be operable to implement key rotation for each of the one or more SSDs. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the key rotation will pass the control of each SSD to another supply agent in the supply network, Including a TSM, a TSP, or a SEMS for personalization of the one or more trading applications in the DTP. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related art, the key rotation is performed by rotating one or more key set documents and/or commands from the DPD manager Supply to the DTPU implementation. In other embodiments of the present invention and/or in other embodiments of the related art, the key rotation is implemented through CASD on the DTPU. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of the related art, the key rotation is performed by the TSM and/or TSP, but not by the DPD manager. Personalization

In each specific embodiment of the present invention and/or in a number of specific embodiments of its related technology, the DTP is designated to the specific card or other digital file by the process of personalizing the DTP to make the DTP a PDTP. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the personal-specific data may include one or more of the following: a primary identifier (for example, for a credit Or a PAN of a debit card, a cardholder’s name, expiration date, a PIN, a CVV, and other information.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, when DTP is associated with a single transaction application, the personal specific data (or personal specific detailed information) will be written Into the single transaction application (or associated with it).

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, when the DTP is associated with more than one transaction application, the personal-specific data (or personal-specific detailed information) Will be separately written into (or associated with) each of the more than one transaction application programs. In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, when DTP is associated with more than one transaction application, the same personal-specific data (or personal-specific details) The subset of information) will be separately written into (or associated with) each of the more than one trading application, where the personally-specific data (or personally-specific details) of each trading application used in the PDTP The subset of information) is different from the other parts of the one or more trading applications.

In some other specific embodiments of the present invention and/or in some other specific embodiments of its related technologies, when DTP is associated with one or more transaction applications, the personally-specific data (or personally-specific data) Detailed information) includes a payment voucher code master identifier (or payment voucher code PAN) for each of the one or more transaction applications, where each payment voucher code master identifier is associated with other such payments The main identifier of the voucher code is different, so that after personalization, the PDTP is a payment voucher code PDTP with one or more associated payment voucher code transaction applications. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the payment certificate code PDTP includes a transaction application program that uses the master identifier (a non-payment certificate code transaction) Application) personalization. In some other such specific embodiments of the present invention and/or in some other such specific embodiments of its related technologies, the payment certificate code PDTP only includes a payment certificate code transaction application. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the personal-specific data of the payment voucher code is provided by the TSP in the supply network.

In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, in the case that the PDTP can be operated by transaction type, each transaction type is associated with a transaction application (identified with the same master) The DTP is individualized by the transaction type identifier (or identification information) used in each transaction application. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the transaction type identifiers include a serial number for each associated transaction application. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, the transaction type identifiers include a master identifier that is personally exclusive to each associated transaction by a different payment voucher code application. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technology, the transaction type identifiers include the transaction application identifier (AID) of each transaction application (it will be understood that, The AID of each transaction application is provided when the transaction application is initially instantiated and introduced its associated DTP and/or the SSD of the DTP). The DPD is linked to DAD (use DTPU)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DAD can be operated to link only a specified DPD, and the DPD can be uniquely identified by the ID of the DTPU. In other specific embodiments of the present invention and/or in other specific embodiments of its related technology, the DAD can be operated to link multiple DPDs, each of which can be uniquely identified by its DTPU ID. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the DPD can be operated to link to only one DAD, and the DAD can be uniquely identified through its device fingerprint, which may include Its International Mobile Equipment Identity (IMEI) code. In still further embodiments of the present invention and/or in still further embodiments of related technologies, the DPD can be operated to link more than one DAD, each of which can be uniquely identified through its device fingerprint. The DPD linked to the DAD (DTPU using the DPD external MCU or other components)

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DAD can be operated to link only a specified DPD, and the DPD can be passed through the MCU or other DPD components outside the DTPU ID for unique identification. In other specific embodiments of the present invention and/or in other specific embodiments of its related art, the DAD can be operated to link multiple DPDs, each of which can be accessed through its MCU or other DPD components outside the DTPU ID for unique identification. In yet other specific embodiments of the present invention and/or in yet other specific embodiments of its related art, the DPD can be operated to link to only one DAD, and the DAD can be uniquely identified through its device fingerprint, which may include Its International Mobile Equipment Identity (IMEI) code. In still further embodiments of the present invention and/or in still further embodiments of related technologies, the DPD can be operated to link more than one DAD, each of which can be uniquely identified through its device fingerprint. Lock / unlock / valid / invalid / operable / inoperable terms

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD can be operated to store or generate transaction applications (and other applications) used to lock and unlock the DTPU Instruction set documents and/or commands. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, unlocked transaction applications can be accessed by DTD for digital transactions, while locked transaction applications cannot be stored by DTD for digital transactions. take. In some such specific embodiments of the present invention and/or in some such specific embodiments of its related technologies, the instruction set documents and/or commands used for locking/unlocking, and/or the commands used for locking/unlocking These template command set documents and/or template commands are stored on and/or generated by the OSE.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, PDTP is invalid when all its associated transaction applications are locked. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, PDTP is effective when at least one of its one or more associated transaction applications is unlocked.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the personal-specific feature is valid or operable when its associated PDTP is valid. In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the personal-specific feature is invalid or inoperable when its associated PDTP is invalid.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD can be operated to have more than one personal-specific feature effective or operable. In this specific embodiment of the present invention and/or in this specific embodiment of its related technology, if there are two or more operable personal-specific features, each personal-specific feature is used for a different function, for example, One-person-specific characteristics for payment and another-person-specific characteristics for identification. It will be understood that the personal characteristics used for payment use different types of DTDs from the personal characteristics used for identification, so that the operations of the personal characteristics in these different DTDs will not conflict.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD can be operated to have two payment personal-specific features valid or operable (the DTPU has two payment PDTP valid), however , One of these personal characteristics (and its associated PDTP) must only be used for contact transactions, and the other personal characteristics (and its associated PDTP) must only be used for contactless transactions. It will be understood that the personal-specific features (and their associated PDTPs) used for contact payments use DTDs that are different from the personal-specific features (and their associated PDTPs) used for contactless payments, so that the different DTDs The operation of these personal features (and their respective PDTPs) will not conflict.

For the operation of trading applications (or non-trading applications), other terms used include Activating/Inactivating, Blocking/Unblocking, Activating/Deactivating, and enabling Enabling/Disabling. In this manual, the terms Lock/Unlock will be better. These terms can also be called the state of the application, that is, the state of being locked or unlocked. Sometimes, instead of specifying that each of the one or more trading applications associated with the PDTP/personal-specific feature is locked/unlocked (if applicable to the context of the case), the PDTP/personal-specific feature will be described as locked/ Unlock or valid/invalid (if applicable to the background of the case).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the security level of the DTPU is configured to allow a single command (single instruction set document) to be transmitted to the DTPU to be locked for the DTPU All trading applications of all PDTP on the website. In various embodiments, this is provided through chain lock routines from SSDs located above all transaction applications and PDTPs in the security hierarchy (and above the SSDs associated with those transaction applications and PDTPs) . DPD changes

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the user is provided with a DPD pre-installed with one or more PDTP/personal-specific features, wherein the DPD is not operable for PDTP / Further supply of personal features.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the user is provided with a DPD pre-installed with one or more PDTP/personal-specific features, wherein the DPD is operable for PDTP / Further supply of personal characteristics (including personal characteristics metadata).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the user is provided with a DPD without pre-installed PDTP/personal-specific features, wherein the DPD is operable for PDTP/personal-specific The supply of features (including personal-specific feature metadata).

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the user is provided with a DPD pre-installed with one or more containers, wherein the DPD is operable for one or more containers The further supply.

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related art, the user is provided with a DPD without pre-installed containers, wherein the DPD is operable for the further supply of one or more containers .

In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, the user is provided with a DPD for installing an application selection module.

In each specific embodiment of the present invention and/or in multiple specific embodiments of related technologies, the user is provided with a DPD without an application selection module installed, wherein the DPD is operable for the application selection module The further supply. Certifications, agreements, and / or standards

In each specific embodiment of the present invention and/or in multiple specific embodiments of its related technology, the DPD or one of its components (including DTPU, MCU, OSE, CKSM, and other components on the DPD) conform to One or more of the following certifications, agreements, and/or standards:

GlobalPlatform industry configuration certification: ● Financial Configuration Specification v1.0; ● UICC configuration specification v2.0; ● UICC configuration specification v1.0.1.

GlobalPlatform functions and features: ● Secure message transmission (eg SCP 02 option i = '55'); ● Secure message transmission (eg SCP 03 option i = '10', '30', and '70'); ●Secure message transmission (such as SCP81 with TLS 1.0-1.2 with all PSK encryption suites); ● GlobalPlatform card specification v2.1.1 or 2.3; ● GlobalPlatform card v2.2.1 or 2.3 Amd. A; ● GlobalPlatform card v2.2.1 or 2.3 Amd. B (SCP81); ● GlobalPlatform card v2.2.1 or 2.3 Amd. C; ● GlobalPlatform card v2.2.1 or 2.3 Amd. D; ● GlobalPlatform card v2.1.1 (on the card GP applet API); ● Used for 3DES key management (including Put key and storage data GP command), and can also include DES, AES, RSA (1024 and 2048 bits), and ECC keys; ● Data storage (used for storage and retrieval of DGI objects); ● Used for 3DES card content management (used to load, install, and delete applications, etc.), and can also include AES, RSA (1024 and 2048 bits), and ECC algorithms; ● Security domain tree diagram (used to delete and extradite the security domain hierarchy); ● Confidential card content management (such as the personalization of the security domain using the control agency security domain (CASD)); ● Logical channel management.

GlobalPlatform privileges: ● Security domain; ● Trust path; ● Overall (Global) registration form; ● Total deletion; ● Global Lock; ● Authorization management. .

Financial certification: ● Contact L1 EMVCo agreement and electrical; ● Non-contact L1 EMVCo analog and digital; ● Contact with L2 EMVCo CPA and CCD; ● Contact L2 VISA Integrated Circuit Card Specification (VIS); ● Contactless L2 VISA contactless payment specification (VCPS); ● Contactless L2 VISA mobile payment application (VMPA); ● Contact L2 MasterCard M/chip; ● Non-contact L2 MasterCard PayPass M/chip prepayment (advance); ● Contactless L2 mobile MasterCard PayPass (MMPP); ● Contact L1 AEIPS chip card specification; ● Non-contact L2 ExpressPay card specification; ● Non-contact L2 Express mobile function (AEMF);

Transport layer agreement: ● NFC-P1 ISO 18092 and NFC-P2 ISO 21481; ● ETSI 102 613 (SWP) and ETSI 102 622 (HCI).

Trading interface agreement: ● ISO 7816; ● ISO 14443.

Each of the certifications, agreements, and/or standards listed above are incorporated into this manual for reference.

Figures 1A and 1B show the main components of a specific embodiment of a digital payment device (DPD) 12 according to the present invention. In the specific embodiments illustrated in the figures, the digital payment device (DPD) is illustrated as a DTC. In at least some specific embodiments, the DTC has a size and shape that conforms to the specifications of a conventional plastic transaction card (such as a credit card) suitable for an automated teller machine or a contact payment terminal. For example, the DTC may be based on at least one of ISO 7816-1 (physical characteristics), ISO 14443-1 (physical characteristics), and ISO 7816-2 (contact position). It will be understood that in other specific embodiments, the DPD may have different shapes and/or sizes, and may be configured for wearable applications (such as rings, pendants, or watches), non-wearable items (such as refrigerators or Vehicles), non-payment applications (such as identity documents), and transportation payment devices.

In the prior art, a plastic credit card or debit card has a single operable individual exclusive feature provided by a single issuer (for example, a single bank). Some cards in the prior art can be operated as a two-payment scheme consisting of a single domestic payment scheme (e.g. EFTPOS in Australia, Interac in Canada, or RuPay in India) and a single international payment scheme (e.g. Visa or Mastercard) (also known as Routing transactions for the payment network. This card includes a different transaction application for each payment plan, but only includes a transaction application for a single international payment plan and a single domestic payment plan. This prior art card does not include transaction applications for two different international payment schemes, and does not include transaction applications for two different domestic payment schemes. Whenever the card is used for transactions via a digital transaction device (DTD) (such as a POS terminal), a transaction application on the card is used. The DTD selects the appropriate trading application to be used, such as a domestic trading application or an international trading application. Some cards have separate transaction applications for contact and contactless transactions. Furthermore, the DTD selects the appropriate trading application to be used.

Since the transaction card of the prior art has only one operable personal exclusive feature, it is impossible to select the personal exclusive feature from one or more personal exclusive features hosted by the card. In the case that the card has a plurality of transaction applications, there is no facility on the card itself to select a specific transaction application for transactions.

In various embodiments of the present invention, the DTC 12 is operable to host one or more personal characteristics, and the DTC is operable to adopt personal characteristics selected from one or more managed personal characteristics. The one or more characteristics specific to the managed individual may be associated with at least one issuer. In a specific embodiment, the DTC 12 may be operable to host a plurality of personal characteristics including at least one personal characteristic related to a first issuer and at least one personal characteristic related to a second issuer. In a specific embodiment, the DTC may operate to host one or more personal-specific features associated with the same issuer.

In a specific embodiment, the DTC 12 is operable to host one or more transaction applications associated with at least one domestic payment solution. In a specific embodiment, the DTC 12 is operable to host one or more transaction applications associated with at least one international payment solution. In a specific 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 Program. In a specific 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 Program.

"Hosted" personal characteristics are personal characteristics installed on the DTC. The installed personal features are in a valid or inoperable state. Individual features that are in a valid state ("Active" (Active) individual features) can be used by the DTC in transactions via DTD. Personal features that are in an inoperable state ("Inoperable" personal features) cannot be used by the DTC in transactions via DTD. The inoperable personal exclusive feature can be made effective (enabled) when the DTC is active, and the effective personal exclusive feature can become inoperable (disabled) when the DTC is active. The DTC can be operated to enable the cardholder to activate or deactivate personal features when the DTC is active.

Enabling personal characteristics is also referred to as using personal characteristics. Changing the/these effective personal characteristics is also referred to as changing the personal characteristics. A specific embodiment of the program for enabling/adopting personal characteristics is described below with reference to FIGS. 7-8 and 9-10.

Referring to Figure 1A, an example of DTC 12 is shown, in which three personal features 7, 8, and 9 are installed on DTC 12 (hosted by it). These three personal characteristics 7, 8, and 9 correspond to three transaction accounts issued by various payment schemes and banks: ● Personal characteristic 7: Visa credit account (issued by Bank 1); ● Personal feature 8: Mastercard transfer account (issued by Bank 1); and ● Personal feature 9: American Express credit account (issued by Bank 2).

Each individual unique feature 7, 8, 9 represents a different trading account, and enables the DTC to conduct transactions through a designated trading account. To conduct transactions through a trading account, the DTC must adopt the personal characteristics associated with the trading account. The adoption is triggered by the cardholder.

Each managed personal characteristic 7, 8, 9 is associated with a single personal digital transaction package (PDTP). The effective personal-exclusive characteristics are associated with the effective PDTP, and the inoperable personal-exclusive characteristics are associated with the inoperable PDTP.

Each PDTP is associated with at least one trading application, so each personal characteristic is also associated with at least one trading application. A trading application that cannot be operated on the DTC transaction is called "Locked", and a trading application that can be operated on the DTC transaction is called "Unlocked". Even with direct selection, there is still no option to lock the trading application in the DTD transaction.

The DTC 12 includes a user interface 83A, 83B, which can be used by a cardholder to select one of the personal-specific features or transaction applications for use in transactions. In this embodiment, the user interface includes a display screen 83A (such as a dot matrix display) and a button keypad 83B. In another embodiment, the user interface includes a touch screen display instead of an auxiliary keyboard.

In a specific embodiment, the DTC 12 enables the cardholder to select and adopt a transaction application from a plurality of transaction applications associated with the same personal characteristics. For example, Figure 1C shows the personal characteristics of a Visa credit account associated with a plurality of transaction applications 7. The display screen 83A presents three relative options 6 (displayed as "App 1", "App 2", and "App 3") indicating three relative transaction applications (all of which are associated with the same personal characteristic 7). The three transaction applications can be associated with three different types of transactions, for example, transactions in three different currencies, or transactions related to three different types of fees.

In the case that a valid 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. This PDTP (and associated personal-specific features) is operable to be used in at least some transactions, and is therefore considered valid.

In a specific embodiment, the personal-specific features are installed on the DTC 12 by providing various digital objects to the DTC. In at least some embodiments of the present invention, the DTC 12 includes a security setting that only accepts digital items from an authorized provider. This security setting includes operations that can be used to check the authenticity of any digital objects to be installed (Authenticity). In a specific embodiment, the digital objects associated with the installation of personal specific features are provided through a provisioning infrastructure 10 with appropriate encryption and authentication protocols. Specific embodiments of the provisioning infrastructure 10 are described below.

In the following description of each specific embodiment of the present invention, the DTC can be operated to host one or more personal-specific features and use personal-specific features from the one or more personal-specific features. The present invention also includes specific embodiments in which the DTC can be operated to host a person-specific feature associated with one or more trading applications.

1B, the DTC includes a DTPU 30, which is operable to host at least one PDTP and at least one transaction application related to each PDTP. The DTC can be operated to reversibly unlock at least one transaction application on the DTPU, and reversibly lock any other transaction application on the DTPU.

The DTC 12 in this specific embodiment has an interface for conducting both contact and contactless transactions. In an alternative embodiment, the DTC 12 is operable to conduct contactless transactions only, and in a further alternative embodiment, the DTC 12 is operable to conduct contact transactions only. In the specific embodiment shown in FIG. 1B, as is known in the prior art, contact transactions are performed via the contact sheet 34 and contactless transactions are performed via the NFC antenna 92. The contact piece 34 has an external interface for the DTPU 30 and the MCU 32, and enables data communication between the DTPU 30 and the MCU 32. The MCU 32 is also used for data communication with the operating secure element (OSE) 80, the secure memory 84, the communication module 86, and the user interfaces 83A and 83B.

The MCU 32 can be operated to perform various operations on the DTC 12, including: routing digital objects to other components on the DTC 12, generating an AID list for the cardholder’s selected personal characteristics, and requesting the instruction set on the OSE 80 The command set document of the document applet 81, and the command set document is transferred to the DTPU 30, read and write information back and forth in the secure memory 84, and manage the user interfaces 83A, 83B. The MCU 32 is also used during the process of supplying the DTC 12, in which personal features or other functions are installed on the DTC 12. Provisioning may occur when the DTC 12 is shipped from the factory before being assigned to the cardholder, or in at least some specific embodiments, when the DTC is physically away from the provisioning infrastructure 10 (shown in FIG. 5). The infrastructure away from the supply 10 is referred to herein as "active".

In the depicted embodiment, DTPU 30 is a tamper-proof security element suitable for financial transactions and capable of safely hosting applications and their confidential and cryptographic data (such as cryptographic keys) in accordance with the relevant rules and security requirements. DTPU 30 has a GlobalPlatform (GP)-compliant operating system installed on it, and sufficient user memory to install a number of personal-specific features, including being operable to install multiple payment solution containers, multiple PDTPs, and Multiple secondary security domains (SSD) security hierarchy. The SSDs in the security hierarchy include at least one SSD 94 related to PDTP, and at least one SSD 96 related to an application selection module. The DTPU 30 stores at least one ISD key 98 used for one of the ISDs of the DTPU, at least one SSD key 100 used for each SSD 94 related to PDTP, and used for the SSD 96 related to the application selection module. A plurality of cryptographic keys of an SSD key 102. The keys 98, 100, 102 are used by the DTPU 30 to verify the instruction set document to be executed on it.

In a specific embodiment, the DTPU 30 is in the OP_READY or INITIALIZED state when it leaves the factory, and the state must be changed to SECURED (using the appropriate key for verification) before being assigned to the cardholder.

The GP-compliant operating system on the DTPU 30 includes a "Global Lock" privilege, which enables the locking and unlocking of trading applications on the DTPU. When all trading applications of the PDTP are locked, the PDTP and the associated personal exclusive features cannot be operated. When one or more of the PDTP trading applications are unlocked, the PDTP and the associated personal-specific features are considered valid. Since each PDTP is associated with a personal characteristic, disabling PDTP effectively disables the associated personal characteristic, and enabling PDTP enables the associated personal characteristic. The locking and unlocking of trading applications and the activation and deactivation of PDTP are explained below.

In at least some specific embodiments, the DTC is operable to have multiple valid personal-specific features at the same time. However, it is preferable that these simultaneously valid personal-specific features are those that will not have the potential to compete or conflict with each other during the transaction. For example, when making a contactless payment, the first personal characteristic associated only with the contact transaction application will not compete with the second personal characteristic associated only with the contactless transaction application, so there will be no conflict . Similarly, the personal characteristics used for a document (such as a driver's license) may not participate in financial transactions, so the personal characteristics of the document can be simultaneously effective by any personal characteristics used for financial transactions. In a specific embodiment, the MCU controls which of the personal-specific features can be operated to be effective at the same time. The MCU can refer to the rules stored on the DTC, such as in the MCU register (Register). This rule can be recorded in metadata associated with personal characteristics.

In a specific embodiment, the DTPU 30 may be operable to use the global lock privilege to lock all transaction applications installed on the DTPU, and then unlock the PDTP (which is associated with the personal characteristic selected by the cardholder) One or more trading applications connected, when the DTC is active, and the DTC is not communicating with the supply infrastructure 10. In a specific embodiment, this locking and unlocking of the transaction application can be triggered by the cardholder who interacts with the user interfaces 83A, 83B and selects personal characteristics. In an alternative embodiment, the locking and unlocking of the transaction application can be triggered by the cardholder who interacts with the DAD 14 and selects personal characteristics, and the DAD can be operated to interact with the DTC 12 for the cardholder’s personal exclusive Feature selection communication. The locking and unlocking of trading applications, and the activation and deactivation of PDTP are explained below.

As will be explained, the global locking action is implemented by executing one or more authenticated instruction set documents in the DTPU 30. The MCU 32 is operable to start a program that generates this verified instruction set document. The verified instruction set document is generated by the command generation unit (which is called the instruction set document applet 81 in this specific embodiment). The command set document applet 81 uses the command set document template from the template storage 82 and the key 104 to generate a verified command set document including commands. The template storage 82 stores one or more instruction set document templates, which do not activate the instruction set document before filling in certain values (for example, the AID of the target application in the DTPU). In the specific embodiment in FIG. 1B, the instruction set document applet 81, the template storage 82, and the SSD key 104 are all stored in the OSE 80. The procedure for generating a verified instruction set document is described in more detail below with reference to Figures 7-8 and 9-10.

Plastic credit or debit cards and digital wallets in the prior art do not have the ability to generate verified instruction set documents. In the case of the plastic card in the prior art, the verified instruction set document is prepared externally (for example, by the card personalization department) and provided to the card when the card is in a safe environment (for example, the card personalization department). In the case of the digital wallet in the prior art, the verified instruction set document is prepared externally (usually performed by TSM) and transmitted to the digital wallet for execution.

In the specific embodiment depicted, OSE 80 is a tamper-proof security element. In a specific embodiment, the GP-compliant operating system is installed on the OSE 80, and in another specific embodiment, the OSE 80 does not include a GP-compliant operating system. In a specific embodiment, a security layer with at least one SSD is installed on the OSE 80.

In the specific embodiment shown in FIG. 1B, the secure memory 84 does not include a tamper-proof storage area that complies with the GP operating system. For example, the secure memory 84 may include ultra-secure hardware-based cryptographic key storage and cryptographic countermeasures, which are designed to reduce or eliminate potential backdoors linked to software weaknesses. The MCU 32 has read and write access rights to the secure memory 84, and can be operated to store digital objects (such as Bluetooth keys and metadata related to personal characteristics) in the security of an operating system that does not need to comply with GP 84 in the memory. In an alternative embodiment, the DTC does not include a secure memory, but digital objects (such as Bluetooth keys and metadata) are stored in the MCU 32.

Referring to FIG. 3, an alternative specific embodiment of the DTC 12 is shown, in which the instruction set document applet 81, the template storage 82, the SSD key 104, and the MCU registry 35 are included on the secure MCU 33. In this specific embodiment, the functions of the OSE 80 (shown in FIG. 1B) are performed by the safety MCU 33. In addition, the DTPU 30 and the safety MCU 33 are incorporated into a single integrated circuit chip 37 (indicated by a dotted line 37 in FIG. 3). The instruction set document applet 81, the template storage 82, and the SSD key 104 should always be stored securely, because it enables the generation of instruction set documents that can be executed on the DTPU 30. Therefore, the safety MCU 33 should have a safety level according to these relevant rules and safety requirements. In an alternative embodiment (not shown), the secure MCU 33 and DTPU 30 are provided as separate chips. The communication modules of the DTC

Sometimes, it may be necessary to supply digital objects to the DTC from the supply infrastructure 10 far away from the DTC (described below with reference to FIGS. 17 to 19). The DTC is operable to communicate wirelessly with the provisioning infrastructure by communicating with a data assist device (DAD) (which in turn is operable to communicate with the provisioning infrastructure). For example, the DAD may be a mobile device, such as a smart phone. The DTC in this embodiment can also be operated to directly communicate with the provisioning infrastructure via WiFi (without DAD). For this wireless communication (equipped with the DAD and using WiFi), the DTC includes a communication module 86. In this embodiment, the communication 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 an NFC antenna 92. In the case of Bluetooth and NFC communication, the communication module allows the DTC 12 to link to (sometimes called pairing) the DAD for mutual communication.

The NFC antenna 92 is directly connected to the DTPU 30, while the Bluetooth module 90 and WiFi module 88 are connected to the MCU 32. The WiFi module 88, the Bluetooth module 90, and the NFC antenna 92 may be discrete components, but are collectively referred to as the communication module 86. In other specific embodiments of the DTC 12, the communication 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 a specific embodiment, the communication module 86 is composed of a Bluetooth module 90. In another specific embodiment, the communication module 86 is composed of a WiFi module 88. In another specific embodiment, the communication module 86 is composed of both a WiFi module 88 and a Bluetooth module 90. Alternatively, any other suitable equipment for wireless communication may be included in the communication module 86. MCU , OSE , and DTPU connections

In a specific embodiment, the communication link 106 between the MCU 32 and the OSE 80 uses a serial communication protocol. As is known in the prior art, the communication link 108 between the DTPU 30 and the contact piece 34 is based on the ISO 7816 standard. Unlike the prior art, the depicted specific embodiment exemplifies the communication link 110 between the MCU 32 and the contact piece 34. In a specific embodiment, the link 110 conforms to the ISO 7816 standard. In another specific embodiment, the link 110 uses a serial communication protocol. Links 108, 110 enable command APDU (C-APDU) to be transmitted from the MCU to DTPU 30, and enable response APDU (R-APDU) to be transmitted from the DTPU to the MCU.

FIG. 4 shows further details of the communication links (shown in FIG. 1B) between the contact piece 34 and the DTPU 30 and MCU 32. As known in the prior art, the DTPU 30 is connected to five patterned metal contact pads (with standard functions) in the contact sheet 34: VCC (contact pad 122), RESET (contact pad 124), CLOCK (contact pad 126) , GROUND (contact pad 128), and DATA (contact pad 130). The five contact pads (122, 124, 126, 128, 130) are conventionally used for financial transactions to exchange APDUs between the DTD (such as a POS terminal) and the DTPU 30. In the specific embodiment in FIG. 4, the five contact pads (122, 124, 126, 128, 130) are also connected to the MCU 32. As indicated in Figure 1B, the MCU also has a communication link with the other components on the DTC (OSE 80, user interfaces 83A, 83B, secure memory 84, Bluetooth module 90, and NFC antenna 92) , And these links are indicated by lines 136 in FIG. 4.

The contact strip 34 shown in FIG. 4 also includes two contact pads 132 and 134, which are connected to the MCU 32 but not to the DTPU 30. The contact pads 132, 134 are designated by ISO 7816 to be used in custom applications, and in this specific embodiment, the pads 132, 134 are provided to enable serial communication with the MCU 32. In this embodiment, the contact pad 132 is operable to transmit data to the MCU 32, and the contact pad 134 is operable to receive data from the MCU. The contact pads 132, 134 will most likely require custom contact pins. It is expected that the contact pads 132, 134 can be used for supplying digital objects to the MCU before the DTC is allocated to the cardholder, and used at the factory or in a similar environment (such as a card personalization department). For example, the digital objects supplied via the pads 132, 134 may include digital objects intended for the MCU 32 or used for (by the MCU) relocation (relocation) to the OSE 80, the secure memory 84, or the communication module 86 Digital objects. The five contact pads (122, 124, 126, 128, 130) enable the DTPU 30 to directly supply without using the MCU 32 to route digital objects to the DTPU, for example, when the DTC leaves the factory or is in contact mode with the DTD. When the instruction set document is transferred to the DTPU.

In at least some specific embodiments, a switch (not shown) is included to disconnect the MCU 32 from the contact pads 132, 134 when these contact pads are not in use, so as to prevent unnecessary voltages from inadvertently affecting the MCU and hackers from passing through. Risk of intrusion of contact pads 132 and 134.

The same communication link shown in FIG. 4 is also used between the contact piece 34, the DTPU 30, and the safety MCU 33 (instead of the MCU 32) in the specific embodiment shown in FIG. 3. Metadata

DTC 12 and DAD 14 store metadata associated with each individual characteristic hosted by the DTC. This metadata is used by the MCU when changing the effective personal characteristics on the DTC. The metadata enables the MCU to look up the AID of each transaction application associated with the selected personal characteristic, and then request the command set document applet 81 to generate one or more command set documents related to the AID(s). In a specific embodiment, at least some of the metadata is displayed on the display screen 83A to indicate the valid personal-specific characteristics/features.

Figure 2 shows a specific embodiment of metadata for a person's unique characteristics. In this specific embodiment, the metadata is stored as a table, where the first row 888 contains the name of the scheme, the name of the issuer, the cardholder’s name, and the AID list, and the second row 890 contains the complete PAN (personal account or main account). Account number), four digits after the complete PAN, expiration date, and CVV, and the third line 892 contains a nickname (generated by the cardholder) for the personal characteristic. In this specific embodiment, this metadata is stored on the MCU 32 in the MCU registry 35 (shown in FIG. 1B). In alternative embodiments, the metadata is stored outside the MCU 32. In one embodiment, the metadata is stored in the secure memory 84, and in another embodiment, the metadata is stored in the OSE 80.

In the specific embodiment where PDTP is associated with a plurality of transaction applications and DTC 12 is operable to unlock at least one transaction application (from the plurality of transaction applications) and lock all other such plurality of transaction applications, DTC 12 Store additional metadata about these plural trading applications. In a specific 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 find each AID associated with each selected transaction application, and then request the command set document applet 81 to generate one or more command set documents related to the AID(s). In a specific embodiment, the metadata for each transaction application includes at least the following information: main PAN, AID, identification information, nickname, operation mode (contact or non-contact). In a specific embodiment, the identification information in the metadata is the payment certificate code PAN. In another specific embodiment, the identification information is a serial number. The purpose of the identification information is to enable the issuer to identify the transaction application that has been used in the transaction. Supply the DTC

The purpose of supply is to provide a digital object to the DTC 12, for example, to give the DTC an operating function or to install a personal characteristic. Examples of this digital object include data, used to install the firmware required for the operation of the DTC (such as MCU firmware) and used to provide command set documents, keys, payment solution containers, metadata, and applications (including transaction applications) Program, PDTP, and select application). Instruction set documents can be provided to the DTC to perform many functions on the DTC, especially including installing a payment solution container, installing a DTP from a payment solution container, personalizing a DTP, and installing a DTP in the OSE or DTPU. Security class.

In a specific embodiment, the DTC is at least partially “pre-provisioned” when it leaves the factory, which means that the DTC is supplied with digital items in the factory environment before the DTC is allocated to the current cardholder. The DTC in this embodiment can be operated to be further supplied through the provisioning infrastructure 10 when it is in use. The pre-supply at the factory includes any component manufacturer, device assembly operation, device test operation, key introduction partner, laminating factory, card personalization department, or any related manufacturing or preparation of the DTC before it arrives at the site. Supply from other parties. At least some of the digital objects required to supply the DTC are provided to the factory through the supply infrastructure 10.

In one version, at least one of firmware, GP-compliant security level, cryptographic key, payment scheme container, PDTP, and selection application is pre-supplied to the factory DTC. For example, the DTC can be pre-supplied with a digital object to install several personal-specific features, and it can be operated as a pair of current DTC supply (through the provisioning infrastructure 10) to install at least one more personal-specific feature on the DTC. Alternatively, the DTC can be pre-supplied with one or more payment solution containers, and can be operated as a DTC supply at the time of use (through the provisioning infrastructure 10) to install PDTP from the one or more installed payment solution containers.

In an alternative embodiment, the DTC is allocated to the cardholder after no pre-supply at the factory, and can be operated to be substantially supplied through the supply infrastructure 10 when it is used. In this specific embodiment, the DTC is pre-supplied with a Rudimentary Bootstrap firmware (installed on the MCU) and a key (such as a TLS certificate), and a key used to decrypt subsequent firmware updates (such as PKI) Key), and DTPU key, so that the DTPU can be supplied in the SECURED state.

In an alternative embodiment, the DTC is pre-supplied with a plurality of personal-specific features at the factory, but the DTC cannot be supplied for current use. This specific embodiment of the DTC can also host a plurality of personal-specific features, and is used to adopt one-person-specific features from the plurality of personal-specific features when the DTC is currently in use. Interaction with payment network

Please refer to FIG. 5, at least some specific embodiments of the DTC 12 can be operated to perform financial transactions through a conventional payment network. The conventional payment network includes a DTC 70 (for example, a POS terminal), which is connected to the DTC 12 Communications; an Acquirer 72, a payment plan 74, and an issuer 18. In the specific embodiment shown in FIG. 5, the supply network 16 (described below) does not involve the procedures for conducting transactions. However, the supply network 16 together with the issuer 18 can operate as the DTC 12 supplying digital objects, so that the DTC 12 can conduct transactions with the conventional payment network. Specific embodiment of the security class

FIG. 6 illustrates a specific embodiment of the security class 201 on the DTPU, which is suitable for hosting a plurality of personal-specific features and suitable for adopting a person-specific feature from the plurality of personal-specific features when the DTC is active.

The security hierarchy 201 has a tree structure. The highest level of the security class is the Issuer Security Domain (ISD) 200. The ISD in this specific embodiment is the parent of three SSDs (202, 96, 206), each of which is the parent of the three branches of the same level of the tree structure and is described below. Each SSD in the hierarchy holds at least one cryptographic key operable to verify the instruction set document for the SSD. For example, the SSD 206 holds a key operable to verify any instruction set document for the SSD 206. Only the party who has a copy of the appropriate key used to specify the SSD can verify the instruction set document for the SSD.

SSD 96 is the parent layer of the first branch of the tree structure. The first branch includes a PSE selection application 222, a PPSE selection application 224, and a container 226. The copy of the key held by SSD 96 is also shared by OSE 80 (shown in Figure 1B) and supply network 16 (specifically, DPD manager 36, as shown in Figures 17 to 19. Therefore, OSE 80 and Each of the DPD managers 36 can be operated to verify the instruction set documents for the SSD 96 and the applications 222, 224 related to the SSD 96 (in the terminology of the tree structure, each of the applications 222, 224 This is the "child" of the SSD 96. The PSE and PPSE select applications to install from the container 226 (which is in the form of at least one basic load file (ELF)).

The SSD 206 is the parent layer of the second branch of one of the tree structure. The second branch is a branch of the same level of the first branch. SSD 206 is the parent layer of SSD 228 and SSD 236, each of which is under the control of a different party (for example, a bank). The SSD 228 controlled by "Bank 1" is the parent layer of three further SSDs 242, 244, 246, and each of these further SSDs is a PDTP (which includes at least one transaction application) for a single personal characteristic The parent layer: ● SSD 242 is the parent layer of PDTP 230 for Bank 1 Visa’s personal characteristics; ● SSD 244 is the parent layer of PDTP 232 which is used for the personal characteristics of Bank 1 Mastercard; ● SSD 246 is the parent layer of PDTP 234 for bank 1 American Express’s personal features.

Only Bank 1 has copies of these keys held by SSDs 228, 242, 244, and 246. Bank 1 will use its own SP-TSM to perform operations on SSDs 228, 242, 244, and 246.

"Bank 2" controls two further SSDs 248, 250, the parent layer of SSD 236, and each of these further SSDs is the parent layer of PDTP (which includes at least one transaction application) for a single personal characteristic: ● SSD 248 is the parent layer of PDTP 238 used for Bank 2 Visa’s personal features; ● SSD 250 is the parent layer of PDTP 240, which is used for the personal characteristics of Bank 2 Mastercard.

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

SSD 202 is the parent layer of the third branch of the tree structure. The third branch is the same level branch of the first and second branches. SSD 202 is the parent layer of three SSDs: SSD 210 (which is the parent layer of the payment solution container 216 for Visa), SSD 212 (which is the parent layer of the payment solution container 218 for Mastercard), and SSD 214 ( It is the parent layer of American Express’s payment scheme container 220. Each payment scheme container is used to generate (instantiate) non-personal-specific transaction applications, which (when combined with personal-specific data) are used to create Transaction applications. For example, the container 216 for Visa in Figure 6 will have been used to generate non-personalized Visa transaction applications for Bank 1 and Bank 2, and then personalize them to be included in Visa. Each transaction application in PDTP 230 and each transaction application included in Visa PDTP 238.

Within the DTPU is an additional security domain 208 known as the Control Agency Security Domain (CASD). The CASD 208 in this embodiment is an area trusted by the DPD manager and the PDTP on the DTPU. In this specific embodiment, Bank 1, and Bank 2 are the managers of the PDTPs on the DTPU. The CASD can be used for key rotation, that is, the key provided by one party (for example, the DPD manager) is exchanged for the key provided by the other party (for example, the PDTP manager). The key rotation can be used after the DPD manager installs an SSD (such as an SSD associated with a new personal-specific feature) to give control of the SSD to the relevant PDTP manager (such as Bank 1 or Bank 2). In some embodiments, the CASD is presented on the DTPU when it is issued by the chip manufacturer or supplier. In another specific embodiment, the CASD is installed when the DTC is in a safe factory environment and the issuer 18 has access rights to the DTC (to avoid the possibility of tampering by the issuer). In specific embodiments where there is trust between the DPD manager and each PDTP manager, CASD may not be required. In some such embodiments, the DTPU does not include a CASD. Specific embodiment of application selection module

The 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 that can be used for unlocking and therefore can be used for transactions with the DTD 70 (for example, the POS terminal 70 shown in FIG. 5) . In the specific embodiments described here, the identifier is the AID (application identifier) known in the prior art, but the identifier may be able to identify the transaction application and can be recognized and processed by the DTD 70 and conforms to Any information about the payment network, payment processing methods, and related standards and protocols of DPD for this payment network.

In at least some specific embodiments, the DTC 12 is operable to unlock the selected transaction application and lock any other transaction applications on the DTPU 30. Each selected trading application can be associated with one or more PDTPs. This specific embodiment of DTC 12 (when using DTD 70 for transactions) is operable to provide the AID for each unlocked transaction application on DTPU 30 to the DTD, but not for any locked transaction application. AID. The AID set provided by the DTC 12 to the DTD 70 is referred to herein as the "candidate list". During the transaction, the DTD 70 selects an AID from the candidate list, and the selected AID is subsequently used in the transaction.

In a specific embodiment of the present invention, the application selection module 225 is operable to generate the candidate list during the transaction, and the DTPU 30 is operable to provide the candidate list to the DTD 70. The candidate list must only include currently unlocked trading applications. If the personal-specific feature is subsequently activated or deactivated (and therefore the trading application is unlocked or locked respectively), the status change must be reflected in the candidate list during the subsequent transaction.

In a specific embodiment, the application selection module 225 is operable to generate a candidate list for a variety of transaction applications, including a transaction application related to payment schemes (for example, a credit or transfer account personal characteristic), and a related transaction application. A transaction application for non-payment of personal characteristics (such as an identity document), a transaction application for transferring personal characteristics of a smart card, a transaction application for contact transactions, a transaction application for contactless transactions, And a trading application with interfaces for both contact and contactless transactions. This transaction application includes transaction applications with different master PANs, transaction applications with the same master PAN, transaction applications with different payment certificate codes PAN, and transaction applications with different serial numbers.

In a specific embodiment in which the DTC 12 hosts at least one transaction application for the payment solution, the application selection module 225 includes a PSE selection application 222 and a PPSE selection application 224. In a specific embodiment where each transaction application hosted by the DTC 12 is a contact transaction application (only operable for contact transactions), the application selection module 225 may not include the PPSE selection application 224. In a specific embodiment where each transaction application hosted by the DTC 12 is a contactless transaction application (only operable for contactless transactions), the application selection module 225 may not include the PSE selection application 222. In all of these embodiments, the application selection module 225 is operable to perform the AID setting of the PSE selection application (if included) by unlocking each transaction application, and the PPSE selection application 224 by each A procedure to unlock the AID settings of contactless trading applications. When the status of any trading application changes (from locked to unlocked or vice versa), DTC 12 can be operated to repeat the AID setting of the trading application by each unlocking contact PSE select application 222 and by each unlocking Contact the AID of the trading application to set the PPSE selection application 224 procedure.

Although the currently described specific embodiments of the application selection module 225 include 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 may include a selection application for selecting a transaction application associated with a non-payment personal characteristic. This selection application can be operated similarly to the way the PSE and PPSE select applications.

In the DTC in the prior art, the PSE selection application and the PPSE selection application are set at the factory, and once the DTC is active, it will never be changed. Once the DTC is active, there is no facility to reset the PSE selection application and PPSE selection application.

In a specific embodiment of the present invention, the DTC 12 is operable to transmit at least one instruction set document 203 (the instruction set document 203 is shown in FIG. 6) containing one or more commands to the application selection module in the DTPU 30. Group 225 to set or reset the PSE selection application 222 and the PPSE selection application 224. In a specific embodiment, the instruction set document 203 includes an appropriately authenticated APDU, which includes an encrypted payload according to the SCP02 protocol. For security purposes, the instruction set document 203 must be verified as a prerequisite to be executed by the application selection module 225. The instruction set document 203 is verified against the SSD 96 (which is the parent layer of the application selection module 225 in the hierarchy in FIG. 6), and is executed through the PSE selection application 222 and/or the PPSE selection application 224. When the command set document 203 is executed, the PSE selection application is set by the AID of each unlocked contact trading application, and the PPSE selection application 224 is set by the AID of each unlocked contactless trading application.

In a specific embodiment, the instruction set document 203 is generated on the DTC 12 through the instruction set document applet 81 (in OSE 80). The input used to generate the command set document through the command set document applet 81 includes: a command set document template, which is provided by the template store 82 (in OSE 80); one AID for each unlocked transaction application (each AID Provided by MCU 32, such as from the metadata shown in FIG. 2); a key 104 (stored in OSE 80); and a counter value, which is associated with a targeted SCP02 key set in DTPU 30. The key 104 is a copy of the SSD key held by the SSD 96. As shown in FIG. 6, the SSD 96 is the parent layer of the application selection module 225 in the security hierarchy. The instruction set document applet 81 uses the key 104 and the counter value to generate a dialogue key for verifying the instruction set document 203 against the SSD 96, so that the instruction set document can be executed through the application selection module 225. As a part of the program for changing the effective personal characteristic(s), an example of the program for generating the instruction set document 203 is described below with reference to FIGS. 9 and 10.

In an alternative embodiment, the instruction set document 203 is provided by the provisioning infrastructure 10 (shown in FIG. 5) in the provisioning process. A specific embodiment of the provisioning infrastructure 10 that is operable to supply the DTC 12 when the DTC 12 is currently in use (away from the provisioning infrastructure 10) is described below with reference to FIGS. 17 to 19. In a specific embodiment, the instruction set document 203 is provided by the provisioning infrastructure 10 (specifically, the DPD manager 36), and is stored in the MCU 32 until needed. In another specific embodiment, the instruction set file 203 is stored in the OSE 80 and retrieved by the MCU 32 when needed. In another specific embodiment, the instruction set document 203 is stored in the secure memory 84 and retrieved by the MCU 32 when needed. Various types of instruction set documents 203 can be supplied and stored to satisfy the future needs of the DTC 12 before being supplied by the supply infrastructure 10.

In an alternative embodiment, the instruction set document 203 is pre-supplied (installed at the factory of the DTC 12) and stored before it is needed. Furthermore, the instruction set document 203 can be stored in the MCU 32, the OSE 80, or the secure memory 84 before being needed. In this specific embodiment, a plurality of instruction set documents 203 are stored to meet the future needs of the DTC 12 or to meet the future needs of the DTC 12 before it is supplied by the provisioning infrastructure 10.

In a specific embodiment, the instruction set document 203 includes each AID to be set. In an alternative embodiment, the PSE selection application 222 and/or the PPSE selection application 224 include a register that is operable to store the AID of the respective transaction application hosted by the DTPU 30. In this specific embodiment, the instruction set document 203 includes information that can identify a transaction application (for example, "05" indicates a designated transaction application), and the PSE selection application 222 and/or the PPSE selection application 224 means This register is used to find the AID corresponding to the trading application "05". When a new personal characteristic is installed on the DTC, the register is updated with each AID associated with the new personal characteristic. Disable PDTP

In a specific embodiment, changing the effective personal-specific features on the DTC involves locking all transaction applications hosted by the DTPU, and then unlocking each transaction application associated with the selected PDTP, which allows any other transaction application to be locking. Each locked transaction application cannot be operated during the transaction and cannot be directly selected by DTD.

In a specific embodiment of the locking procedure illustrated in FIG. 7 (which shows the same level 201 as shown in FIG. 6), the "Lock and Associated" command (which performs the following operations) is appropriately verified by For SSD 206, the command performs the following tasks: a) Lock (make it invalid) SSD 206; b) Lock all SSDs (its children) associated with SSD 206 in the tier; and c) Lock all transaction applications associated with the locked SSD (its children).

Therefore, in this specific embodiment, the lock and associated commands have: a) lock SSD 206, b) lock SSD 228, 236, 242, 244, 246, 248, 250, and c) disable PDTP 230, 232 , 234, 238, 240. Each padlock 211 indicates that the SSD is locked or the PDTP is not operable.

The locking of all SSDs related to the SSD 206 (and the disabling of all subsequent PDTPs) is referred to herein as a "cascade locking" procedure. In the chain locking procedure, the SSD 206 is referred to as a locked SSD for PDTP. Apply interlocking lock to lock SSD 206 so that all PDTPs are inoperable. From the cardholder's point of view, the interlocking lock disables all personal exclusive features (makes it inoperable). In a specific embodiment, the DTC can be operated to perform a chain lock when the effective personal-specific features on the DTC are changed.

The chain lock procedure is triggered when the DTPU receives at least one verified instruction set document 207 in the form of APDU. In a specific embodiment, the APDUs include an encrypted payload according to the SCP02 protocol and are verified against the SSD 96 (the parent SSD of the application selection module 225).

In this example, the instruction set document 207 instructs the application selection module 225 to lock the SSD 206 (as indicated by the arrow 209) through a chain lock command. In a specific embodiment, the application selection module 225 is operable to use the global lock privilege to lock the SSD 206 through the chain lock command.

In a specific embodiment, the instruction set document 207 targets the PSE selection application 222 to perform the chain lock procedure. In an alternative embodiment, the instruction set document 207 selects the application 224 for the PPSE to perform the chain lock procedure. In an alternative embodiment, the instruction set document 207 is for different unlocking applications to perform the chained locking process or to delegate the PSE or PPSE application to perform the chained locking process.

In an alternative embodiment (not shown), a single interlocking lock command is not used to disable PDTP. Instead, multiple lower-level SSDs are each targeted with separate lock commands. For example, by locking SSD 228 and SSD 236, all lower-level SSDs will be locked. In the example shown in FIG. 7, the SSD 228 is targeted by the lock command so that the SSD 242, 244, and 246 will be locked and the PDTP 230, 232, and 234 will be disabled. Similarly, the SSD 236 will be locked and the PDTP 238, 240 will be disabled by the lock command for the SSD 236. Alternatively, each of the SSDs 242, 244, 246, 248, 250 can be directed to a separate lock command to disable all PDTPs. In one version, the application selection module 225 uses the global lock privilege to target each SSD that is locked. In another mode, the global lock privilege and application selection module 225 are not used. In contrast, the lock command included in the instruction set document provided to DTPU 30 directly targets each SSD to be locked (for example, SSD 242). The instruction set document is in the form of APDU, and will be verified against the targeted SSD. In a specific embodiment, the registry in the MCU saves a record of the locked state of each SSD, and enables the DTC 12 to avoid generating instruction set files for SSDs that do not need to change the locked state.

In a specific embodiment, each verified instruction set document (such as the instruction set document 207) that can lock all PDTPs is generated on the DTC 12. In a specific embodiment, the MCU 32 commands the instruction set document applet 81 (in OSE 80) to generate each verified instruction set document. The input used to generate the command set document through the command set document applet 81 includes: a command set document template (provided by the template store 82 in OSE 80); an identifier, such as the AID that can identify each PDTP to be disabled (These identifiers are included in the metadata provided by MCU 32); a key 104 (stored in OSE 80); and a counter value, which is associated with a targeted SCP02 key set in DTPU 30 . The key 104 is a copy of the key held by the targeted SSD. In the case where the command set document targets the application selection module 225, the key is a copy of the key held by the parent SSD 96. An example of the program for generating the instruction set document 207 is described below with reference to FIG. 9 and FIG. 10. In the case that the command set document targets the PDTP parent SSD, the key 104 is a copy of the key held by the targeted SSD.

The instruction set document applet 81 uses the key 104 and the counter value to generate a dialogue key for verifying the instruction set document against the targeted SSD. Once the verified instruction set document has been generated through the instruction set document applet 81, the MCU 32 forwards the verified instruction set document to the DTPU 30 for execution. Enable targeted PDTP

In a specific embodiment, changing the effective personal-specific features on the DTC includes enabling a targeted PDTP. A targeted PDTP is directly activated after the chain lock procedure, resulting in that only the targeted PDTP is effective. Therefore, only the personal-specific features associated with the targeted PDTP are enabled. Referring to FIG. 8 (which shows the same level 201 shown in FIGS. 6 and 7), an inoperable PDTP can be activated by unlocking at least one transaction application associated with the PDTP. For example, the PDTP 230 can be activated by unlocking at least one transaction application associated with the PDTP 230.

In this example, the command set document 213 instructs the application selection module 225 (which has the global lock privilege) to target at least one transaction application associated with the Visa PDTP 230 through the application unlock command (as indicated by arrow 215 Instructions). In a specific embodiment, the application unlocking command is a SET STATUS command, which restores one or more transaction applications associated with the Visa PDTP 230 to their previous state (which is an unlocked state). Once the instruction set document 213 is executed, the Visa PDTP 230 becomes valid, which means that the transaction application associated with the PDTP 230 can be used in transactions, and the personal-specific features associated with the PDTP 230 are valid (which can be used by the cardholder) .

In an alternative embodiment, the instruction set document 213 is for different unlocking applications on the DTPU 30 (instead of the application selection module 225), so as to target each transaction application by an unlocking command, or The PSE or PPSE application is delegated to target each transaction application with an unlock command.

In a further alternative embodiment (not shown), the global lock privilege and application selection module 225 are not used. On the contrary, an instruction set document is provided to the DTPU 30 to instruct another application on the DTPU 30 to target each PDTP to be targeted. This application can unlock SSD. In a specific embodiment, an additional SSD called application unlocked SSD is provided, which is the parent layer of SSD 206 for the purpose of enabling PDTP. This application unlocks the SSD which is the parent layer of the locked SSD 206 in this layer, so it will not be locked during the chain lock process. In the example shown in FIG. 8, a command set document is provided to instruct the application to unlock the SSD to enable PDTP 230, and the application selection module 225 is not involved in the unlocking process.

In a specific embodiment, each verified instruction set document (such as the instruction set document 213) used to enable PDTP is generated on the DTC 12. In a specific embodiment, the MCU 32 commands the instruction set document applet 81 (in OSE 80) to generate each verified instruction set document. The input used to generate the command set document through the command set document applet 81 includes: a command set document template (provided by the template store 82 in OSE 80); an identifier, such as the AID ( The identifier is included in the metadata provided by the MCU 32); a key 104 (stored in OSE 80); and a counter value, which is associated with a targeted SCP02 key set in the DTPU 30. The key 104 is a copy of the key held by the targeted SSD. In the case that the command set document targets the application selection module 225, the key 104 is a copy of the key held by the parent SSD 96. An example of this procedure for generating the instruction set document 213 is described below with reference to FIG. 9 and FIG. 10. In the case where the instruction set document targets the PDTP parent SSD, the key 104 is a copy of the key held by the parent SSD (for example, in the case where the instruction set document targets PDTP 230, the key 104 is Is a copy of the key held by SSD 242).

The command set document applet 81 uses the key 104 and the counter value to generate a dialogue key for verifying the command set document against the targeted SSD. Once the verified instruction set document has been generated through the instruction set document applet 81, the MCU 32 forwards the verified instruction set document to the DTPU 30 for execution.

The instruction set document 213 may be included as a part of the chain lock instruction set document 207 or may be a separate instruction set document. In this specific embodiment, the instruction set document 213 targets the PDTP 230, which may include both contact and/or non-contact functions. The instruction set document 213 can be operated for a single transaction application or multiple transaction applications within the PDTP (for example, a contact transaction application or a contactless transaction application, or both a contact and a contactless transaction application).

The PSE selection application 222 and the PPSE selection application 224 are each operable to unlock any transaction application on the DTPU. In a specific embodiment, the PSE selection application 222 is used to unlock each contact transaction application in the targeted PDTP, and the PPSE selection application 224 is used to unlock each contactless transaction application within the targeted PDTP. In a specific embodiment, the PSE selection application 222 is operable to manage the PPSE selection application 224 (to reduce the processing burden). In this specific embodiment, the instruction set document 213 is for the PSE selection application 224 of the designated PPSE selection application 224 to unlock any targeted non-contact application program 222. In another specific embodiment, the PPSE selection application 224 can be operated to manage the PSE selection application 222. In this specific embodiment, the instruction set document 213 is for the designated PSE selection application 222 to unlock the PPSE selection application 222 of any targeted application. In an alternative embodiment, there are additional applications that manage both the PSE and PPSE selection applications 222, 224 (not shown, but they are part of the application selection module 225). In this specific embodiment, the instruction set document 213 is for delegating the PSE and PPSE selection applications 222, 224 to the additional application that will specifically unlock the transaction application as appropriate. Unlock targeted trading apps

In a specific embodiment, the procedure for unlocking a targeted transaction application is the same as the procedure described above for enabling as a targeted PDTP (except for replacing a set of transaction applications associated with PDTP to target individual transaction applications) ). Unlocking the targeted transaction application directly after the chain lock process results in that only the targeted transaction application can be selected in the transaction. A step-by-step diagram for the use of personal characteristics at the time of use

Figures 9 and 10 illustrate that the cardholder of the DTC (when currently in use) can select and activate one or more of the plurality of personal-specific features installed on the DTC, and the DTC is not related to the provisioning infrastructure 10 or provisioning A specific embodiment of the procedure of network 16 communication. The program of FIG. 9 includes the subroutine 920 illustrated in FIG. 10.

Please refer to Figure 9 now. The process for selecting and activating personal features starts at step 900 (the cardholder 674 used the user interfaces 83A, 83B (shown in Figure 1A) to browse the currently installed DTC. Personal characteristics). The available personal-specific features are indicated on the display screen 83A through one or more of the metadata associated with each personal-specific feature. A specific example of metadata related to personal characteristics is shown in FIG. 2. In a specific embodiment, the metadata displayed on the display screen 83A is the PAN's payment plan name, bank name, and the last four digits, and a logo for the payment plan (the logo is not included in Figure 2 In the specific embodiment of the metadata shown).

In step 902, the cardholder 674 selects one (or more) personal-specific features to be enabled, and the selection is recorded by the MCU 32. In this specific embodiment, the DTC 12 can be operated to have multiple valid personal-specific features at the same time. The MCU registry stores rules about which personal-specific features are allowed to be valid at the same time, and the MCU refers to these rules before continuing to make changes to the personal-specific features. If the rules do not allow the requested personal characteristic change, the MCU 32 displays a message on the graphic display 83A to indicate that the personal characteristic change cannot be continued. In another specific embodiment, when the cardholder requests a new personal-specific feature to be activated, the DTC 12 may be operable to disable any other personal-specific features that are not allowed to be activated at the same time as the selected personal-specific feature. In this specific embodiment, the MCU 32 is operable to request confirmation from the cardholder before continuing to deactivate the personal-specific features. In another specific embodiment, the rules specify that only one person-specific feature can be effective at any time.

In step 904, if the rules allow the requested personal characteristic change, the MCU 32 searches the metadata stored in the MCU registry 35 and identifies the metadata associated with each selected personal characteristic. The metadata used for each personal characteristic includes AID information, which specifies the AID for each transaction application of the PDTP associated with each selected personal characteristic. The MCU 32 uses the metadata to generate a list of AIDs associated with each selected personal characteristic.

In step 906, the MCU 32 sends the command (which contains the AID list for the selected personal characteristics) to the command set document applet 81 to generate at least one command set document, which is selected by the application program on the DTPU 30 When the module 225 runs: disable all PDTPs on the DTPU, enable PDTP related to the selected personal characteristic, and set the application selection module 225 by using the AID for the selected personal characteristic. The instruction set document generated in step 906 is equivalent to the three instruction set documents previously described: the instruction set document 207 (used for interlocking locking) shown in FIG. 7 and the instruction set document 213 (used for targeting Sex lock), and the instruction set document 203 shown in FIG. 6 (used to set the AID on the application selection module 225).

In step 908, the instruction set document applet 81 requests the instruction set document template from the template storage 82 (which is stored on the OSE), and in step 910, the template storage 82 returns the requested instruction set document template to the instruction set document Mini Program 81. In step 912, the command set document applet 81 fills in the command set document template with values to create a command set document. The established instruction set document is in the form of APDU and is derived from the following: the AID used for the contact transaction application associated with the selected PDTP(s); and used to relate to the selected PDTP(s) The AID of the linked contactless trading application.

In step 914, the command set document applet 81 uses the SSD key 104 (which is stored in the OSE 80) and the counter value associated with the targeted SCP02 key set in the DTPU 30 to generate a conversation key. The SSD key 104 stored in the OSE 80 is a copy of the key held by the SSD 96 in the DTPU 30. As shown in FIGS. 7 to 8, the SSD 96 is the parent layer of the application selection module 225 in the security hierarchy. The purpose of the dialogue key is to verify the instruction set document against the SSD 96 so that the instruction set document can be executed by the application selection module 225. The command set document applet 81 uses the conversation key to encrypt the payloads of the APDUs, for example, according to SCP02.

In step 916, the instruction set document applet 81 forwards the verified instruction set document to the MCU 32, and in step 918, it forwards the verified instruction set document to the application selection module 225 in the DTPU. The next step (subroutine 920) occurs on the DTPU and is shown in FIG. 10.

Please refer to FIG. 10. In step 948, the verified instruction set document is verified against the SSD 96 (ie, the component 204 in FIG. 10). In step 950, the instruction set document is transferred to the PSE selection application 222 which is a part of the application selection module 225. In step 952, the PSE selection application 222 uses the GlobalPlatform global locking privilege to lock the SSD 206 (which makes all PDTPs on the DTPU inoperable) to execute the "lock and associate" command (as shown in FIG. 7). In step 954, it is confirmed whether the locked SSD 206 is locked.

Step 958 and step 960 are loop 956, in which PSE selects the application 222 to process the instruction set document (generated in steps 912 and 914), reads the AIDs used to contact the trading application, and uses the GlobalPlatform global lock privilege to unlock (As shown in Figure 8) each contact transaction application 940 associated with the AIDs. Step 960 is to confirm each transaction application 940 unlocked. The loop 956 repeats until all contact transaction applications associated with the AID in the command set document are unlocked.

Steps 964 and 966 are loop 962, where the PSE selects the application 222 to process the instruction set document (generated in steps 912, 914), read the AIDs for the contactless transaction application, and use GlobalPlatform to lock the privileges globally Unlock (as shown in FIG. 8) each contactless transaction application 942 associated with the AIDs. Step 966 is to confirm each transaction application 940 unlocked. The loop 962 repeats until all contactless transaction applications associated with the AID in the command set document are unlocked.

In step 968, if the AID list used to contact the transaction application is blank, the PSE is prohibited from selecting the application 222. Otherwise, if the AID list used for the contact transaction application is not blank, then in step 770, the PSE selection application 222 uses the AID settings of the contact transaction application that has been successfully unlocked (as shown in FIG. 6).

In step 972, the PSE selection application 222 initiates the PPSE selection application 224 update. In step 974, if the AID list for the contactless transaction application is blank, the PPSE is prohibited from selecting the application 224. Otherwise, if the list of AIDs used for contact trading applications is not blank, then in step 976, the PPSE selection application 224 sets the AIDs by the contactless trading applications that have been successfully unlocked. In step 978, the confirmation returns to the PSE selection application 222.

In step 980, the PSE selection application 222 uses the GlobalPlatform global lock privilege to unlock the locked SSD 206, and in step 982, the confirmation returns to the PSE selection application 222.

Please refer to FIG. 9, the procedure continues from step 922, in which the application selection module 225 sends an acknowledgement (in the form of R-APDU) to the MCU 32. In step 924, the MCU 32 checks the status words (also referred to as status bytes) in the R-APDUs. If an error occurs that requires the cardholder to take an action, 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. 9) with the activation status of the AID for contact and contactless transaction applications. In step 928, the MCU 32 updates the display screen 83A with information to indicate that the new personal-specific feature has been activated. Finally, in step 930, the cardholder checks the display to confirm that the new personal-specific feature has been activated as expected. A step-by-step diagram for adopting a trading application when in use

Please refer to FIG. 9 to FIG. 10 again, and a specific embodiment of the procedure for selecting and adopting at least one transaction application program from a plurality of transaction application programs associated with personal characteristics will now be described. These steps are the same as those used to use the personal-specific features described above, but apply to individual trading applications instead of PDTP.

Please refer to Figure 9 now. The process for selecting and activating the transaction application starts at step 900 (the cardholder 674 at that time uses the graphical user interfaces 83A, 83B (Figure 1A) to browse the current installations for the selected personal features Trading application on DTC). The available transaction applications are indicated on the display screen 83A through one or more of the metadata associated with each individual characteristic. In a specific embodiment, the metadata displayed on the display screen 83A is the PAN transaction type, the name of the payment plan, the name of the bank, the last four digits, and the logo used for the payment plan. Examples of transaction types include currency, expense type, budget type, location, project, or the individual or organization that enjoys the expense. The transaction type may have been defined by the cardholder.

In step 902, the cardholder 674 selects one or more transaction applications to be unlocked, and the selection is recorded by the MCU 32. In this embodiment, the DTC 12 can be operated to have multiple unlocking transaction applications at the same time. The MCU registry stores rules about which trading applications are allowed to be unlocked at the same time, and the MCU refers to these rules before proceeding to unlock the trading applications. If the rules do not allow the unlocking of the requested transaction application, the MCU displays a message on the display screen 83A to indicate that the request cannot be continued.

In step 904, if the rules allow one or more transaction applications to request unlocking, the MCU 32 searches the metadata stored in the MCU registry 35 and identifies the metadata associated with each selected transaction application . This metadata contains the AID for each selected trading application. The MCU 32 uses the metadata to generate a list of AIDs associated with the selected transaction application(s).

In step 906, the MCU 32 transmits the command (which contains the AID for each selected transaction application) to the command set document applet 81 to generate the command set document (which includes at least one command), which is executed on the DTPU At this time, as described above with reference to the security levels of FIGS. 7 to 8, all transaction applications on the DTPU are locked, and then each selected transaction application is unlocked. In step 908, the instruction set document applet 81 requests the instruction set document template from the template storage 82 (which is stored on the OSE), and in step 910, the template storage 82 returns the requested instruction set document template to the instruction set document Mini Program 81. In step 912, the command set document applet 81 fills in the command set document template with multiple values to create a command set document. The created instruction set document is in the form of APDU and is derived from an AID for each selected contact trading application and an AID for each selected contactless trading application.

In step 914, the instruction set document applet 81 uses the SSD key 104 (stored in OSE 80, as shown in FIG. 1B) and the counter value associated with the targeted SCP02 key set in DTPU 30 to generate a conversation key. And use the conversation key to encrypt the payloads of the APDUs, for example, according to SCP02. The purpose of the dialog key is to verify the command set document against the application selection module 225. The SSD key stored in the OSE 80 is a copy of the key held by the SSD 96 associated with the application selection module 225 in the DTPU 30. In step 916, the instruction set document applet 81 forwards the instruction set document to the MCU 32, which forwards (at step 918) the instruction set document to the application selection module 225 in the DTPU. The next step (subroutine 920) takes place on the DTPU and is shown in FIG. 10.

Please refer to FIG. 10 now. In step 948, the instruction set document is verified against the SSD 96 of the application selection module 225 (ie, the component 204 in FIG. 10). In step 950, the instruction set document is transferred to the PSE selection application 222 which is a part of the application selection module 225. In step 952, the PSE selection application 222 uses the GlobalPlatform global locking privilege to lock the SSD 206 (examples of the locked SSD 206 are shown in Figure 6 to Figure 8) to execute the "lock and associate" command, which enables all transaction applications on the DTPU All programs are locked. In step 954, there is a confirmation that the locked SSD 206 is locked.

Step 958 and step 960 are loop 956, where PSE selects the application 222 to process the instruction set document (generated in steps 912, 914), reads the AIDs used to contact the trading application, and uses GlobalPlatform global lock privileges to unlock and Each contact transaction application 940 associated with these AIDs. Step 960 is the confirmation of each transaction application 940 unlocked. The loop 956 repeats until all contact transaction applications associated with the AID in the command set document are unlocked.

Steps 964 and 966 are loop 962, where the PSE selects the application 222 to process the instruction set document (generated in steps 912, 914), read the AIDs for the contactless transaction application, and use GlobalPlatform to lock the privileges globally Unlock each contactless transaction application 942 associated with these AIDs. Step 966 is the confirmation of each transaction application 940 unlocked. The loop 962 repeats until all contactless transaction applications associated with the AID in the command set document are unlocked.

In step 968, if the AID list used to contact the transaction application is blank, the PSE is prohibited from selecting the application 222. Otherwise, if the AID list used for contact trading applications is not blank, then in step 770, the PSE selection application 222 sets the AIDs by the contact trading applications that have been successfully unlocked.

In step 972, the PSE selection application 222 initiates the update of the PPSE selection application 224. In step 974, if the AID list for the contactless transaction application is blank, the PPSE is prohibited from selecting the application 224. Otherwise, if the AID list used for the contactless transaction application is not blank, then in step 976, the PPSE selection application 224 uses the AID settings of the contactless transaction application that has been successfully unlocked. In step 978, the confirmation returns to the PSE selection application 222.

In step 980, the PSE selection application 222 uses the GlobalPlatform global lock privilege to unlock the locked SSD 206, and in step 982, the confirmation returns to the PSE selection application 222.

Please refer to FIG. 9, the process continues from step 922, in which the application selection module 225 sends the confirmation (in the form of R-APDU) to the MCU 32. In step 924, the MCU 32 checks the status words (also referred to as status bytes) in the R-APDUs. If an error occurs that requires the cardholder to take an action, 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. 9) with the activation status of the AID for contact and contactless transaction applications. In step 928, the MCU 32 updates the display screen 83A with information to indicate that each selected transaction application has been activated. Finally, in step 930, the cardholder checks the display to confirm whether it is activated as expected. A further specific embodiment of the security hierarchy on the DTPU

FIG. 11 illustrates another specific embodiment of the security class 241 suitable for hosting a plurality of personal-specific features and suitable for adopting the personal-specific features from the plurality of personal-specific features when the DTC is currently in use. Where these features are the same as in Figure 6, the same reference numbers have been used. In the specific embodiment of FIG. 11, the bank 1 has only one SSD 228, and this SSD is the parent layer of three PDTPs (230, 232, 234). Bank 2 also has only one SSD 236, which is the parent layer of two PDTPs (238, 240). This specific embodiment has fewer SSDs than FIG. 6, but the PDTPs can be locked and unlocked using the same procedures illustrated in FIGS. 7-8. Locking the interlocking of the SSD 206 will cause all associated SSDs (228, 236) to be locked, and all associated PDTPs (230, 232, 234, 238, 240) will be inoperable. The application selection module 225 can be operated to enable a targeted PDTP, as described above with reference to FIGS. 7 to 8.

FIG. 12 illustrates another specific embodiment of the security class 251 suitable for hosting a plurality of personal-specific features and suitable for adopting the personal-specific features from the plurality of personal-specific features when the DTC is currently in use. In this specific embodiment, the PDTPs and associated SSDs are arranged at a flatter level than in the specific embodiments in FIGS. 6 to 8 and 11. Each PDTP is a child of an SSD (which is the child of the locked SSD 206 in the security class). "Bank 1" has three SSDs 252, 254, 256 associated with the locked SSD 206 (or its "children"), and "Bank 2" has two SSDs 258, 260 associated with the locked SSD 206. Each of Bank 1 and Bank 2 will use its own SP-TSM to perform operations on the DTPU.

Each SSD of Bank 1 is the parent layer of a single PDTP 262, 264, 266, and each SSD of Bank 2 is the parent layer of a single PDTP 268, 270. (Locking SSD 206) The interlocking lock causes all child SSDs (252, 254, 256, 258, 260) to be locked, and all associated PDTPs (262, 264, 266, 268, 270) will be inoperable. The application selection module 225 can be operated to enable a targeted PDTP, as described above with reference to FIGS. 7 to 8.

FIG. 13 illustrates another specific embodiment of the security class 281 suitable for hosting a plurality of personal-specific features and suitable for adopting one-person-specific features from the plurality of personal-specific features when the DTC is currently in use. In this specific embodiment, the DTC escrows seven personal-specific features associated with three banks (Bank 1, Bank 2, Bank 3) and three payment schemes (Visa, Mastercard, American Express), and each bank uses TSP These services perform operations on the DTPU: ● The TSP used for the Visa account has control over the SSD 280 and the associated SSD (286, 290, 294) and the associated PDTP (288, 292, 296); ● The TSP used for the Mastercard account has control over SSD 282 and associated SSD (298, 302) and associated PDTP (300, 304); and ● The TSP used for American Express accounts has control over SSD 284 and associated SSD (306, 310) and associated PDTP (308, 312).

As shown in Figures 6 to 8 and Figures 11 to 12, the interlocking locking of the locked SSD 206 in Figure 13 makes all associated SSDs (280, 286, 290, 294, 282, 298) , 302, 284, 306, 310) will be locked, and all associated PDTPs (288, 292, 296, 300, 304, 308, 312) will be inoperable. The application selection module 225 in FIG. 13 can be operated to enable a targeted PDTP, as described above with reference to FIGS. 7 to 8.

FIG. 14 illustrates another specific embodiment of a security class 313 suitable for hosting a plurality of personal-specific features and suitable for adopting personal-specific features from the plurality of personal-specific features when the DTC is currently in use. In this specific embodiment, the DTC hosts ten personal-specific features 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 these services of TSP to perform operations on the DTPU, and Bank 4 will use its own SP-TSM to perform operations on the DTPU: ● The TSP used for the Visa account has control over the SSD 280 and the associated SSD (286, 290, 294) and the associated PDTP (288, 292, 296); ● The TSP used for the Mastercard account has control over SSD 282 and associated SSD (298, 302) and associated PDTP (300, 304); ● The TSP used for American Express accounts has control over SSD 284 and associated SSD (306, 310) and associated PDTP (308, 312); and ● SP-TSM for Bank 4 has control over SSD 314 and associated SSD (316, 320, 324) and associated PDTP (318, 322, 326).

Locking the interlocking of SSD 206 will lock all associated SSDs (280, 286, 290, 294, 282, 298, 302, 284, 306, 310, 314, 316, 320, 324), and all associated PDTPs (288, 292, 296, 300, 304, 308, 312, 318, 322, 326) will be inoperable. The application selection module 225 is again operable to activate a targeted PDTP, as described above with reference to FIGS. 7 to 8.

FIG. 15 illustrates a specific embodiment of a further security class branch 331 suitable for hosting a plurality of personal-specific features and suitable for adopting one-person-specific features from the plurality of personal-specific features when the DTC is currently in use. This security level is also suitable for one or more operation modes (contact or non-contact).

The branch 331 locks the child domain (Child) of the SSD 206. SSD 228 is controlled by Bank 1 and is the parent domain of SSD 330 (which is associated with a first personal characteristic) and SSD 334 (which is associated with a second personal characteristic).

The first personal characteristic (related to SSD 330) is a personal characteristic of a bank 1 Visa transfer account associated with PDTP 332, which includes contact and contactless transaction applications.

The second personal characteristic (related to SSD 334) is a personal characteristic of a bank 1 Mastercard credit account with two operating modes. ● Contact mode, which corresponds to a trading application group 338 (a subset of the PDTP) containing at least one contact trading application; and ● Contactless mode, which corresponds to a trading application group 342 (a subset of the PDTP) containing at least one contactless trading application.

The trading application group 338 can only operate in the contact mode, while the trading application group 342 can only operate in the non-contact mode. In this embodiment, the two transaction application groups 338, 342 are associated with the same Mastercard personal characteristics (same PAN, same expiration date, same account name, etc.) and part of the same PDTP.

One of these two operating modes can be activated by locking one of the two trading application groups 338, 342 and unlocking the other group (making the other operating mode inoperable). Only one of the operation modes is valid, so that the cardholder can choose either contact mode or non-contact mode (but not both) to operate the personal exclusive features of Mastercard.

Alternatively, the two operating modes can be activated simultaneously by unlocking the two trading application groups 338 and 342. However, the bank 1 may choose not to allow the two operating modes to be valid at the same time, which is implemented in specific embodiments by including this information in the metadata associated with the personal characteristic.

In a specific embodiment, the DTC is operable to receive operation mode selection from the cardholder (via user interfaces 83A, 83B), and use the cardholder’s selection to trigger the MCU 32 to generate and The AID list associated with the operating mode to enable or disable the operating mode. The AID list specifies each transaction application required by the selected operating mode. The MCU can be operated to generate the AID list by referring to the metadata (stored in the MCU registry), and forward the AIDs to the command set document applet 81 in the OSE 80. The instruction set document applet 81 uses these AIDs to generate instruction set documents to be executed in the DTPU 30.

In one method, the instruction set documents are directed to the application selection module 225 in the DTPU. The DTPU uses the global lock privilege to lock all transaction applications in a chained manner, and then unlocks the selected operating mode. Each transaction application (group 338 or group 342). In another method, the instruction set documents are targeted to the SSD 336 and the SSD 340 by a lock command or an unlock command. For example, the command set document for locking the SSD 336 and unlocking the SSD 340 locks the transaction application group 338 and unlocks the transaction application group 342 without using the global lock privilege.

FIG. 16 illustrates a further specific embodiment of a branch 351 of the security class suitable for hosting a plurality of personal-specific features and suitable for adopting one-person-specific features from the plurality of personal-specific features when the DTC is currently in use. This security level is also suitable for adopting one or more accounts from a plurality of accounts associated with personal characteristics. In this specific embodiment, each individual characteristic has an account in a different currency.

The branch 351 locks the subdomain of the SSD 206. SSD 228 is controlled by Bank 1, and is the parent domain of SSD 330 (related to a first individual characteristic) and SSD 334 (related to a second individual characteristic).

The first personal feature (related to SSD 330) is the personal feature of Bank 1 Visa transfer account, which operates in two currencies: ● U.S. dollar transactions conducted in contact and non-contact modes, which correspond to the transaction application group 348 (a subset of the PDTP) with contact and non-contact interfaces; and ● Euro transactions conducted in contact and non-contact modes correspond to transaction application group 352 (a subset of the PDTP) with contact and non-contact interfaces.

In this embodiment, the transaction application groups 348 and 352 are associated with the same Visa personal characteristics (same PAN, same expiration date, same account name, etc.) and part of the same PDTP. One of these two currencies can be activated by locking one of the two transaction application groups 348, 352 and unlocking the other group (making the other currency inoperable). Only one of these currencies is valid, so that the cardholder can operate the Visa personal characteristics with only one of the two currencies.

Alternatively, two currencies can be activated. The bank 1 may choose not to allow the two currencies to be valid at the same time, which is implemented in a specific embodiment by including this information in the metadata associated with the personal characteristic.

In a specific embodiment, the DTC is operable to receive a currency selection from the cardholder (via user interfaces 83A, 83B), and use the currency selection to trigger the MCU 32 to generate a currency associated with the selected currency AID list to enable or disable currencies. The AID list specifies each transaction application required by the selected currency. The MCU can be operated to generate the AID list by referring to the metadata (stored in the MCU registry), and forward the AIDs to the command set document applet 81 in the OSE 80. The instruction set document applet 81 uses these AIDs to generate instruction set documents to be executed in the DTPU 30.

In one method, the instruction set documents are directed to the application selection module 225 in the DTPU. The DTPU uses the global lock privilege to lock all transaction applications in a chained manner, and then unlocks each associated with the selected currency Trading application. In another method, the instruction set documents use a lock command or an unlock command to target each of the SSD 346 and the SSD 350 without using the global lock privilege.

This second personal feature (related to SSD 334) is a personal feature of Bank 1 Mastercard credit account, which operates in two currencies and has two separate operating modes: ● The Australian dollar transaction conducted in contact mode corresponds to the transaction application group 356 (a subset of the PDTP) that includes at least one contact transaction application; ● The Australian dollar transaction conducted in the contactless mode corresponds to the transaction application group 360 (a subset of the PDTP) that includes at least one contactless transaction application; ● Japanese yen transactions conducted in contact mode correspond to the transaction application group 364 (a subset of the PDTP) with at least one contact transaction application; and ● A yen transaction conducted in a contactless mode corresponds to a transaction application group 368 (a subset of the PDTP) that has at least one contactless transaction application.

In this specific embodiment, the transaction application groups 356, 360, 364, 368 are associated with the same Mastercard personal characteristics (same PAN, same expiration date, same account name, etc.) and are part of the same PDTP. One or more of these two currencies and these two operating modes can be activated by locking or unlocking trading application groups 356, 360, 364, 368 (making the other currency and operating mode inoperable), which makes the holding Cardholders can operate the Mastercard personal features with the selected currency and the selected operating mode.

The bank 1 may choose not to allow some currencies and operating modes to be valid at the same time, which is implemented in specific embodiments by including this information in the metadata associated with the personal characteristic.

In a specific embodiment, the DTC is operable to receive selections from the cardholder, and use the selections to trigger the MCU 32 to command the command set document applet 81 to generate the command set document to be executed by the DTPU 30 (as above Explained) to enable or disable currency selection and operation modes.

In one method, the instruction set documents target the application selection module 225 in the DTPU. The DTPU uses the global locking privilege to lock all transaction applications in a chained manner, and then unlocks related to the selected currency and operation mode Each transaction application program connected, which in this specific embodiment is one or more of transaction application program groups 356, 360, 364, 368. In another method, the instruction set documents use a lock command or an unlock command to target each of the SSDs 354, 358, 362, 366 without using the global lock privilege. Supply infrastructure

FIG. 17 shows a specific embodiment of a provisioning infrastructure 10 configured to provision DTC 12 via a data assist device (DAD) 14 (such as a smart phone) when both the DTC and DAD are physically far away 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 issuer 18 in each specific payment embodiment can be any party that authorizes the DTC 12 to provide payment services (in at least some non-payment specific embodiments, the issuer can be the party that issues passports or documents such as passports. For example. The issuer 18 can be a financial institution or a party with a bank license. The issuer 18 also authorizes the supply network 16 to supply DTC 12 when the DTC is in use. In various specific embodiments, the issuer 18 issues DTC 12 to the cardholder It is also envisaged in other specific embodiments that the DTC 12 may be issued by another authorized provider (sometimes referred to as an issuer or distributor of additional cards). However, in this specification, the system will be issued by the initial card issuer 18. For example, it is shown that the supply infrastructure 10 is operated by only one issuer 18. However, in various embodiments, the supply infrastructure may be operated by multiple issuers (for example, issuers of many different banks and/or financial institutions) Operation. In other specific embodiments, the supply network may be combined with a single issuer.

The supply network 16 is operable to communicate with the DAD 14 via the wireless communication service 24 (to establish a communication link 20), and to communicate with the DTC 12 via the DAD 14 (using the wireless communication link 26). The issuer 18 or its agent is operable to communicate with the DAD 14 via the supply network 16 and link 20. The wireless communication network 24 may be any wireless network capable of transmitting sufficient data to and from the DAD 14, and may include, for example, an Internet service provider or a mobile network operator.

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 specific embodiments, the communication with the DTC 12 can take place via a DTD (such as a POS terminal) (Over The Wire, OTW), and the DTD is via a contact link (for example, by introducing the DTC into the DTD) Or directly to the DTC through the non-contact communication link between the DTD and the DTC (for example, via the NFC or Bluetooth between the DTD and the DTC). In other specific embodiments, the OTW communication may be via a contactless communication link (such as NFC or Bluetooth) to the DAD 14 and then from the DAD to the DTC 12 (such as via Bluetooth).

In the specific embodiment shown in FIG. 17, the DAD 14 and the DTC 12 are linked via a 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. 19), the DTC 12 includes a WiFi function, which enables the DTC to be directly connected to the wireless communication network 24 without the DAD 14 for intercommunication therebetween. However, when the WiFi communication between the DTC and the wireless communication network is initially established, the DAD can be used.

In various alternative embodiments, the link 26 between the DAD 14 and the DTC 12 is a non-wireless communication link. In one specific embodiment, the link 26 is the cable connection between the DTC 12 and the DAD 14. In another specific embodiment, the link 26 includes electrical contacts that are operable to be brought into data communication with electrical contacts on the DTC 12 (such as the contact piece 34 shown in FIG. 1B). In one mode, DAD 14 includes this electrical contact. In another mode, the DAD 14 is operable to be connected via a cable to a device that 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 embodiment, the DAD 14 is operable to connect wirelessly to the device, and the device includes electrical contacts and is operable to be brought into data communication with the electrical contacts on the DTC 12.

FIG. 17 also illustrates the remote notification service 22, which is operable to provide push notifications to the mobile application 60 on the DAD 14 (for example, a smart phone). For example, the push notification may request the cardholder to download the supply information to the DTC or DAD, such as installing a digital object with new personal features or firmware updates. This push notification may include a notification for the cardholder to check whether the DTC is powered and pair the DAD before downloading the digital object. This provisioning will be carried out through the provisioning infrastructure 10 using the procedures described below.

Figure 17 also illustrates a mobile application portal 62. In a specific embodiment, the mobile application portal 62 is operable to download the mobile application 60 to the DAD 14. In another specific embodiment, the mobile application portal 62 is operable to download the configuration file to the DAD 14. This configuration file may include a Bluetooth key for the designated DTC so that the DAD 14 can be paired with the DTC 12. In a specific embodiment, the configuration file can only be provided after it has been confirmed that the designated DTC is eligible to receive the download (for example, registering the DTC through the mobile application portal 62).

FIG. 18 shows the same specific embodiment shown in FIG. 17, but illustrates further details of the supply network 16 and the DAD 14. For simplicity, only MCU 32 is displayed in DTC 12, and other components of the DTC are omitted. The supply network 16 includes a first supply agent 36 and at least one second supply agent 38. The provisioning agent 36 includes a TSM function, but provides functions that are not provided by the known TSM, including management functions that support the operation of the DTC 12. In the following specific embodiments, the provisioning agent 36 will be referred to as the DPD manager 36.

In a number of specific embodiments, each supply agent 38 is a trust service management platform (TSM) or a payment voucher code service provider (Tokenised Service Provider, TSP), both of which are known in the prior art. In the following specific embodiments, at least one second supply agent 38 will be referred to as TSM/TSP 38.

TSM/TSP 38 is trusted by or managed by the issuer 18. The DPD manager 36 conducts data communication with the DAD 14 and the TSM/TSP 38, and the TSM/TSP conducts data communication with the issuer 18. In some embodiments, the components and functions of the supply network 16 may be provided by a single agent (supply agent), a single server, and/or a single site. However, it is envisaged that in most specific embodiments, these components and functions may be provided by a single agent (supply agent), a single server, and/or a single site. Various components and functions will be provided by different agents, although some of these components and functions are combined in a single agent or a single server. It is also possible that the issuer 18 and the supply network 16 are combined agents (combined supply agents), or multiple parts of the supply network are combined with the issuer.

The DPD manager 36 provides several important functions related to the provision and operation of the DTC 12. The DPD manager 36 is operable to generate digital objects other than those provided by the traditional TSM/TSP 38 and transmit the digital objects to the DTC 12.

The DPD manager 36 can also be operated to transfer digital objects representing the TSM/TSP 38 to the DTC 12. In particular, the DPD manager 36 is operable to receive the digital object provided by the TSM/TSP 38 and transmit the digital object to the DTC 12. The DPD manager 36 provides this function (representing the digital object transmission of TSM/TSP 38), because the prior art supply agent (such as TSM/TSP 38) is not suitable for supplying digital payment devices (such as DTC 12). One of the reasons is that the prior art TSM/TSP 38 is configured to directly communicate with the digital wallet on the mobile device, instead of communicating through an intermediary device (such as DAD 14). In addition, the prior art TSM/TSP 38 does not provide routing information to instruct the MCU 32 to provide the digital objects to the appropriate components on the DTC. In addition, only the prior art TSM/TSP 38 is known to provide contactless payment examples. In addition, only the prior art TSM/TSP 38 is known to provide metadata (such as the PAN's payment scheme name, brand, account name, and last four digits) to a single device (wallet on a mobile device). However, the present invention information Each of the specific embodiments provides metadata for two devices (namely, DTC 12 and DAD 14).

In the specific embodiment of FIGS. 17 to 18, the DPD manager 36 is operable to transmit the digital object to the DTC 12 via the DAD 14 via the link 26 (for example, using Bluetooth for communication between the DTC 12 and the DAD 14), and In the specific embodiment shown in FIG. 19, the DPD manager 36 is operable to directly transmit the digital object to the DTC 12 via the WiFi communication link 64. This digital object is provided to at least one of the MCU 32 of the DTC 12 and the DTPU 30. In the specific embodiments of FIGS. 17 to 18, providing the digital objects to the MCU and/or DTPU involves establishing the communication links 20, 26 with the DTC 12 via the DAD 14. In the specific embodiment of FIG. 19, providing the digital objects to the MCU and/or DTPU involves establishing a communication link 64 with the DTC 12.

In a specific embodiment, the DPD manager 36 includes routing information (such as a header), in which each digital object is transmitted to the DTC via the link 20, the link 26, or the link 64. In a specific embodiment, the routing information includes information indicating the expected destination of the digital object. In a specific embodiment, the information indicating the expected destination of the digital object specifies the component of the DTC, such as the DTPU. The MCU can be operated 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 operated to instruct the MCU to forward the digital object to the DTPU, or in another example, to store the digital object in the MCU. The DPD manager 36 also includes routing information, which has any digital object provided by the TSM/TSP 38, and transmits this digital object to the DTC 12 together with the routing information.

In a specific embodiment, the DPD manager 36 can also be operated to maintain a record of the status of the DTC 12, including the record of each individual characteristic installed on the DTC 12 (hosted by it), and the characteristic components of the DTC 12. For example, the device model. In a specific embodiment, the DPD manager 36 may be operable to request the DTC 12 to provide information indicating the status of the DTC. The DPD manager 36 can also operate as a new personal exclusive feature that will be installed on the DTC 12 when the DTC 12 is active, and receive a request from the cardholder. The DAD 14 can be operated to transmit each cardholder request to the DPD manager 36, and the DPD manager 36 can operate to forward each cardholder request to the TSM/TSP 38, which in turn can be operated as Forward each cardholder request to the issuer 18. In a specific embodiment, the DPD manager 36 may be operable to include additional information in the request to the issuer 18, for example, information specifying various aspects of the personal-specific features to be installed, including information about the personal-specific features. Information on the operating mode (contact, non-contact, or both). In another specific embodiment, the issuer 18 provides an online facility for the cardholder to directly submit the request without using the DAD 14. If the issuer 18 approves the cardholder’s request for new personal features to be installed, the issuer 18 initiates the program provided by both the DPD manager 36 and TSM/TSP 38 for the digital objects installed on the DTC 12 .

In the specific embodiments shown in FIGS. 17 to 19, only one issuer 18 and one TSM/TSP 38 are depicted in the supply infrastructure 10, but it should be understood that the supply infrastructure 10 may include multiple issuers , And the supply network 16 may include a plurality of supply agents. In a specific embodiment, the supply network 16 includes a plurality of TSMs. In another specific embodiment, the supply network 16 includes a plurality of TSPs. In another embodiment, the supply 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 directly managed by a separate issuer 18. TSP is generally a service provided by another party, such as a payment plan (such as Visa or Mastercard) on behalf of the issuer 18. In a specific embodiment, the supply infrastructure 10 includes at least one issuer for each TSP, and includes a separate TSP for each payment scheme supported by the supply infrastructure.

The TSM/TSP 38 includes a key manager 42 and is operable (among other functions) to negotiate SSD cryptographic key management on the DTC 12 representing the issuer 18. Each key manager 42 can be operated to issue an SSD key 44 to the DTC 12. The key manager 42 may sometimes be referred to as a security domain manager, or these functions of the key manager may be incorporated into it. Details of some DAD components and mobile application building

In the specific embodiments shown in FIGS. 17 to 19, the DAD 14 is a smart phone. However, in other specific embodiments, the DAD can be any suitable device, such as a personal computer (PC), a tablet PC, or other types The mobile computing device. In still other specific embodiments, the DAD may be a digital transaction device (DTD), such as an automated teller machine (ATM), which has been appropriately adapted to provide the functions required by the DAD in various embodiments of the present invention.

In other specific embodiments, it is envisaged that if configured by the function of communicating with the supply network 16 (possibly using WiFi or similar technology), the functions required by the DAD 14 of the present invention can be performed on the DTC. This DTC will also need to be equipped with appropriate processing, memory, and power to perform the required functions as performed by the DAD in each embodiment of the invention. Therefore, DAD 14 is an optional component used to implement various embodiments of the present invention.

DAD has installation software called DAD gateway 48, which enables DAD 14 to be used as a bridge between provisioning infrastructure 10 and DTC 12. The DAD gateway 48 is operable to communicate with the supply infrastructure 10 via the link 20 and to communicate with the DTC 12 via the link 26. Different from the mobile application 60 that is visible to the cardholder, the DAD gateway 48 provides functions that the cardholder of the DAD 14 cannot see. The DAD gateway 48 and the mobile application 60 can be part of the same software installation, but because they provide different types of functions, they are described as separate software items in this manual.

The DAD gateway 48 and the mobile application 60 can be requested and distributed by another authorized party. In some specific embodiments, the DAD gateway 48 and the mobile application 60 can only be provided to the DAD 14 immediately after confirming that the user of the DAD (or the DAD itself) is authorized to receive the mobile application, wherein the DAD provides Confirm the identity of the DAD (for example, if it is a smart phone, it is the International Mobile Equipment Identity (IMEI) of the DAD). Generally, the DAD user will be the same person as the DTC cardholder. In other specific embodiments, the confirmation of authorization includes confirming the identity of the DTC 12, which may include one or more of a unique serial number for the DTC, a Bluetooth ID, and a unique identifier for a DTPU on the DTC. One, and other unique identifiers that uniquely identify the DTC or its components alone or in combination. In some embodiments, the authorization confirmation includes a combination of a DAD identifier and one or more DTC identifiers.

In at least some specific embodiments, the DTC 12 can be operated to participate in a personal-specific feature installation program, which can be operated to install new personal-specific features on the DTC when the DTC is currently in use. In this process, the DPD manager 36 transmits digital objects to the DAD 14 and DTC 12, and the digital objects include command set documents and metadata associated with the personal characteristics. Examples of metadata associated with personal characteristics include the name of the plan, the name of the issuer, the name of the cardholder, the complete PAN, the last four digits of the PAN, the expiration date, and the CVV . In various embodiments, at least some metadata is stored on both DAD 14 and DTC 12.

In the specific embodiment shown in FIG. 17 to FIG. 18, the DPD manager 36 is operable to transfer digital objects for installing new personal features to DAD 14, and DAD 14 is operable to transfer these digital objects to DTC 12. After processing the digital objects, the DTC 12 is operable to transfer at least some metadata (contained in the received digital objects) back to the DAD 14 (for installation on it).

In the specific embodiment shown in FIG. 19, the DTC 12 includes a WiFi communication module 88 (shown in FIG. 1B), and the DTC is operable to communicate with the DPD manager 36 via the link 64 using the wireless communication network 24. The DPD manager 36 can be operated to transfer digital objects to bypass the DAD 14 and install the new personal-specific features directly to the DTC 12 via the link 64. In a specific embodiment, the cardholder triggers the download of the digital object to the DTC, for example, by pressing a button on the DTC. The DTC 12 and DAD 14 in FIG. 19 can also be operated to communicate via the link 26 (as in FIGS. 17 to 18) (for example, via Bluetooth or NFC). After processing the received digital objects, the DTC 12 is operable to transfer at least some metadata (contained in the received digital objects) back to the DAD 14 (for installation on it).

The process of installing new personal features on DTC 12 can be triggered in different ways. In the specific embodiment of the personal characteristic installation procedure, the procedure is triggered when the cardholder uses the mobile application 60 on the DAD 14 to select a new personal characteristic and request to install the personal characteristic on the DTC. In a specific embodiment, the personal characteristic is selected from a list of personal characteristics that can be downloaded to the cardholder. This list of personal characteristics may be determined by the issuer 18 based on the account held by the cardholder.

The DAD gateway 48 on the DAD 14 is operable to transmit the personal-specific feature installation request to the issuer 18 and/or the DPD manager 36. In an alternative specific embodiment of the personal-specific feature installation program, the process of installing new personal-specific features on DTC 12, and the cardholder participates in the user interface (not shown) on DTC 12 to select the new personal-specific feature and request It starts when the personal feature is installed on the DTC. The DTC 12 is operable to transmit the personal-specific feature 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 the cardholder’s personal-specific feature installation request is approved by the provisioning infrastructure 10 (usually approved by the issuer 18 and/or the DPD manager 36), the DPD manager 36 can operate to start the installation process.

Throughout this specification and the scope of the patent application thereafter, unless the background content requires it, the word "including", and variations such as "including" and "containing" will be understood to mean including the integers or steps or a set of Integers or steps, but does not exclude any other integers or steps or a set of integers or steps.

The reference to any prior art in this specification is not, and should not be regarded as a confirmation or any form of suggestion for such a situation, that the prior art constitutes a part of ordinary and general knowledge.

6: Option 7, 8, 9: personal characteristics 10: Supply infrastructure 12: DTC 14: DAD 16: supply network 18: Issuer 20: Communication link 22: Remote notification service 24: wireless communication network 26: Communication link 30: DTPU 32: MCU 33: Security MCU 34: contact piece 35: MCU registry 36: The first supply agent 37: Single integrated circuit chip 38: The second supply agent 42: Key Manager 44: key 48: DAD Gateway 60: mobile apps 62: Mobile application portal 64: communication link 70: DTD 72: Acquirer 74: payment plan 80:OSE 81: Instruction set document applet 82: Template save 83A: User interface 83B: User interface 84: Secure memory 86: Communication module 88: WiFi module 90: Bluetooth module 92: NFC antenna 94: SSD 96: SSD 98: Key 100: key 102: Key 104: SSD key 106: communication link 108: Communication link 110: Communication link 122: contact pad 124: contact pad 126: contact pad 128: contact pad 130: contact pad 132: Contact pad 134: contact pad 136: Line 200: Issuer security domain 201: Security Class 202: SSD 203: Instruction Set Document 204: Components 206: SSD 207: Instruction Set Document 208: Control Agency Security Domain 209: Arrow 210: SSD 211: Padlock 212: SSD 213: Instruction Set Document 214: SSD 215: Arrow 216: Container 218: container 220: container 222: PSE select application 224: PPSE select application 225: Application Selection Module 226: Container 228: SSD 230: PDTP 232: PDTP 234: PDTP 236: SSD 238: PDTP 240: PDTP 241: Security Class 242: SSD 244: SSD 246: SSD 248: SSD 250: SSD 251: Security Class 252: SSD 254: SSD 256: SSD 258: SSD 260: SSD 262: PDTP 264: PDTP 266: PDTP 268: PDTP 270: PDTP 280: SSD 281: Security Class 282: SSD 284: SSD 286: SSD 288: PDTP 290: SSD 292: PDTP 294: SSD 296: PDTP 298: SSD 300: PDTP 302: SSD 304: PDTP 306: SSD 308: PDTP 310: SSD 312: PDTP 313: Security Class 314: SSD 316: SSD 318: PDTP 320: SSD 322: PDTP 324: SSD 326: PDTP 330: SSD 331: branch 332: PDTP 334: SSD 336: SSD 338: Trading Application Group 340: SSD 342: Trading Application Group 346: SSD 348: Trading Application Group 350: SSD 351: branch 352: Trading Application Group 354: SSD 356: Trading Application Group 358: SSD 360: Trading Application Group 362: SSD 364: Trading Application Group 366: SSD 368: Trading Application Group 674: Cardholder 888: first line 890: second line 892: third line 900: steps 902: step 904: step 906: step 908: step 910: step 912: step 914: step 916: step 918: step 920: Subroutine 922: step 924: step 926: step 928: step 930: step 940: Trading Application 942: Trading Application 948: step 950: step 952: step 954: step 956: loop 958: step 960: step 962: loop 964: step 966: step 968: step 970: step 972: step 974: step 976: step 978: step 980: step 982: step

Fig. 1A is an illustration of the appearance of a specific embodiment of the DTC.

FIG. 1B is a diagram of components in a specific embodiment of DTC.

Fig. 1C is an illustration of the appearance of a specific embodiment of a coefficient transaction card (DTC).

Fig. 2 is a specific embodiment of metadata related to personal characteristics.

Figure 3 is a diagram of components in a further specific embodiment of the DTC.

FIG. 4 is a diagram of electrical connections among contact pads, MCU, and DTPU in a specific embodiment of DTC.

Figure 5 is a schematic diagram of specific embodiments of the provisioning infrastructure, DAD, DTC, and payment network.

Figure 6 is a tree diagram of a specific embodiment of the security hierarchy in the DTPU.

Figure 7 is a tree diagram of a specific embodiment of the security hierarchy in the DTPU.

Figure 8 is a tree diagram of a specific embodiment of the security hierarchy in the DTPU.

FIG. 9 is a sequence diagram showing a part of a specific embodiment of a procedure for using personal-specific features on DTC.

Fig. 10 is a sequence diagram showing a part of a specific embodiment of a procedure for using personal-specific features on DTC.

Fig. 11 is a tree diagram of a further specific embodiment of the security hierarchy in the DTPU.

Figure 12 is a tree diagram of a further specific embodiment of the security hierarchy in the DTPU.

FIG. 13 is a tree diagram of a further specific embodiment of the security hierarchy in the DTPU.

Fig. 14 is a tree diagram of a further specific embodiment of the security hierarchy in the DTPU.

Figure 15 is a diagram of specific embodiments of the provisioning infrastructure, DAD, and DTC.

Figure 16 is a diagram of specific embodiments of the provisioning infrastructure, DAD, and DTC.

Figure 17 is a diagram of specific embodiments of the provisioning infrastructure, DAD, and DTC.

Figure 18 is a diagram of specific embodiments of the provisioning infrastructure, DAD, and DTC.

Figure 19 is a diagram of specific embodiments of the provisioning infrastructure, DAD, and DTC.

7, 8, 9: personal characteristics

12: DTC

34: contact piece

83A: User interface

83B: User interface

Claims (50)

A digital transaction processing unit (DTPU) operable to host one or more transaction applications for digital transactions performed by a digital transaction device (DTD), the DTPU includes a digital transaction processing unit (DTPU) for hosting the one or more transaction applications The security level of the program, wherein the security level is configured to host at least one transaction application program used to conduct transactions by contacting digital transactions. For example, the DTPU in the scope of patent application 1, wherein the security layer is configured to host at least one transaction application program used for non-contact digital transactions. For example, the DTPU of item 1 or item 2 of the scope of patent application, wherein the security class is configured to host at least one transaction application used for both non-contact and contact digital transactions. For example, the DTPU of the first patent application, where the security level includes one or more security domains. For example, the DTPU of item 4 of the scope of patent application, in which at least one of the one or more security domains can be operated as a transaction application security domain for hosting at least one of the one or more transaction applications. For example, the DTPU of item 5 of the scope of patent application, wherein the at least one transaction application security domain is configured to be used by a digital payment device manager, a trust service management platform (TSM), a code service provider (TSP), and A provision of at least one of the Secure Element Manager Service (SEMS). For example, the DTPU in the scope of the patent application, where the DTPU can be operated to host one or more containers, and each transaction application is derived from one of the one or more containers, and the security level can be operated To host these one or more containers. For example, the DTPU of item 3 of the scope of patent application, wherein at least one of the one or more security domains can be operated as a container security domain for hosting at least one of the one or more containers. For example, the DTPU of item 1 of the scope of patent application, wherein the DTPU can be operated to host an application selection module that can be operated to provide transaction application identifier information for communicating with the DTD in digital transactions, the transaction application The program identifier information indicates a transaction application program that can be operated for digital transactions through the DTD. For example, the DTPU of item 9 of the scope of patent application, where each transaction application identifier is an application identifier (AID) of the associated transaction application. For example, the DTPU of item 1 of the scope of patent application, wherein the DTPU can be operated to reversibly unlock at least one of the one or more trading applications, so that at least one unlocked trading application of each can be used for the digital Trading and operation. For example, the DTPU of item 11 of the scope of patent application, wherein the DTPU can be operated to reversibly unlock at least one of the one or more transaction applications when the DTPU is currently used away from a supply agent. For example, the DTPU of item 1 of the scope of patent application, wherein the DTPU can be operated to reversibly lock at least one of the one or more transaction applications, so that each at least one unlocked transaction application cannot be used for digital transactions through the DTD And operation. For example, the DTPU of item 13 of the scope of patent application, wherein the DTPU can be operated to reversibly lock at least one of the one or more transaction applications when the DTPU is currently used away from a supply agent. For example, in the DTPU of the 7th patent application, the security layer has a tree structure including a first branch hosting the one or more containers, and the tree structure further includes a tree structure hosting the one or more containers. The second branch of a trading application. For example, the DTPU of item 15 of the scope of patent application, wherein the first branch is the same level branch of the second branch in the tree structure. For example, the 15th or 16th DTPU of the scope of patent application, wherein the DTPU can be operated to lock each of the one or more transaction applications by locking a parent security domain of the second branch. For example, the DTPU of item 4 of the scope of patent application, wherein the one or more transaction application programs include at least one first transaction application program and at least one second transaction application program, and the at least one first transaction application program is controlled by a first security Domain hosting, the at least one second transaction application is hosted by a second secure domain. For example, the DTPU of item 18 of the scope of patent application, wherein the first security domain is operable to be controlled by only a first party, and the second security domain is operable to be controlled by only a second party. For example, the DTPU of item 18 or item 19 of the scope of patent application, wherein the first security domain is the same level branch of the second security domain in the tree structure. For example, the DTPU of item 1 of the scope of patent application, wherein the security layer has a tree structure and the one or more transaction applications include a plurality of transaction applications, each of which is associated with a master identifier, wherein Transaction applications related to the same main identifier are sub-domains of the same security domain, and transaction applications related to a different main identifier are sub-domains of different security domains. For example, the DTPU of item 21 in the scope of patent application, where the primary identifier is a personal account number (PAN). For example, the DTPU of item 15 of the scope of patent application, wherein the application selection module is managed by the security layer outside the second branch. For example, the DTPU of item 23 of the scope of patent application, where the security layer includes a third branch hosting the application selection module. For example, the DTPU of item 24 of the scope of patent application, where the third branch is the same-level branch of the second branch. For example, the DTPU of item 24 or item 25 of the scope of patent application, wherein the third branch is the same-level branch of the first branch. For example, the DTPU of item 15 in the scope of patent application, where the application selection module is hosted by the DTPU outside the security level. For example, the DTPU in the first item of the scope of patent application, where the DTPU is included in a digital payment device (DPD) that can be operated for digital transactions via a DTD. For example, the DTPU of item 28 of the scope of patent application, in which the one or more transaction applications are associated with one or more personalized digital transaction packages (PDTP), so that each PDTP is associated with at least one corresponding transaction application Each PDTP is associated with a corresponding personal characteristic, and the personal characteristic is at least partially managed by the DPD. For example, the DTPU of item 29 of the scope of patent application, wherein each PDTP is a sub-domain of any one or more other security domains different from the PDTP. For example, the DTPU of item 29 or item 30 of the scope of patent application, wherein the DTPU can be operated to disable a selected PDTP by locking a parent security domain of the PDTP, and each disabled PDTP cannot be targeted by a DTD. Trading and operation. For example, the DTPU of any one of the 28th to 30th items in the scope of patent application, where the DPD includes an OSE used to generate one or more instruction set documents. For example, the DTPU of any one of the 28th to 30th items in the scope of patent application, where the DPD includes an OSE for storing one or more instruction set files. For example, the 32nd DTPU of the scope of patent application, in which the OSE can be operated to store one or more template instruction set documents and the MCU can be operated to provide operation data to the OSE, and the OSE can be operated by the operation data Customize the one or more template command set documents to prepare the one or more command set documents. For example, the DTPU of the 34th patent application, where the operation data includes the AID of a selected transaction application to be unlocked. For example, the 32nd DTPU of the scope of patent application, wherein the DTPU can be operated to reversibly unlock a selected transaction application after executing the one or more instruction set documents. For example, the DTPU of the 34th patent application, where the DTPU can be operated to reversibly lock a selected transaction application after executing the one or more instruction set documents. For example, the DTPU of any one of items 28 to 30 of the scope of patent application, wherein the DPD includes an MCU for operating the DTPU to execute the one or more instruction set documents. For example, the DTPU of the first item of the scope of patent application, where the one or more transaction applications include a first transaction application for financial transactions and a second transaction application for purposes other than financial transactions . For example, the 39th DTPU in the scope of patent application, in which the first transaction application is associated with a payment solution. For example, the DTPU of item 39 or item 40 of the scope of patent application, where the second transaction application provides an identity document. A digital payment device (DPD) including a digital transaction processing unit (DTPU), the DTPU is operable to host one or more transaction applications for digital transactions via a digital transaction device (DTD), the DTPU is patented Scope item 1. A method for hosting one or more transaction applications on a digital transaction processing unit (DTPU) for digital transactions via a digital transaction device (DTD), the DTPU includes a method for hosting the one or more transaction applications The security level of the program, the methods include: The security level is configured to host at least one transaction application program used to conduct transactions by contact digital transactions. For example, the method of item 43 of the scope of patent application, which includes: The security level is configured to host at least one transaction application program used for transactions with non-contact digital transactions. Such as applying for the method of item 43 or item 44 of the scope of patent, where the method includes: The security level is configured to host at least one transaction application program for conducting transactions with both non-contact and contact digital transactions. Such as applying for the method of item 43 or item 44 of the scope of patent, where the method includes: One or more security domains are included in the security hierarchy. For example, the method of item 46 in the scope of patent application, which includes: Operate at least one of the one or more security domains as a transaction application security domain for hosting at least one of the one or more transaction applications. Such as applying for the method of item 43 or item 44 of the scope of patent, where the method includes: The security layer hosts one or more containers, and each transaction application is derived from one of the one or more containers. For example, the method of item 46 in the scope of patent application, which includes: Operate at least one of the one or more security domains as a container security domain for hosting at least one of the one or more transaction applications. Such as applying for the method of item 43 or item 44 of the scope of patent, where the method includes: The security layer hosting can be operated as an application selection module that provides transaction application identifier information for communicating with the DTD in a digital transaction. The transaction application identifier information indicates that the transaction application identifier information can be directed to the digital transaction via the DTD. And the operation of a trading application.

Images