TW201800995A - Apparatus and method for communicating with a digital transaction processing unit (DTPU) - Google Patents

Abstract

A digital transaction apparatus includes a Data Assistance Device (DAD), a Digital Transaction Card (DTC). The DAD has a user interface that is operable to at least select data, and a DAD transmitter. The DTC has a Digital Transaction Processing Unit (DTPU), and a DTC receiver. The DAD and DTC are operable to transfer data from the DAD to the DTC and when subsequently using the DTC to effect a digital transaction, the DTC operates in accordance with the data selected and transferred from the DAD to the DTC, and wherein the DTPU operates in accordance with firmware wherein the firmware has been modified to enable the DTPU to receive and execute an expanded set of commands.

Description

Apparatus and method for communicating with a digital transaction processing unit

The present invention is generally directed to apparatus and methods for implementing digital transactions, including financial transactions and non-financial transactions. Devices and methods may be particularly useful for transactions involving credit cards and/or debit cards.

Credit cards, debit cards, memory cards and gift cards are examples of cards used for financial transactions worldwide. In addition, other types of cards (such as passbooks, labels, and booklets (which may be collectively referred to as transaction documents)) are used for various financial transactions and non-financial transactions. For example, some jurisdictions require proof of age cards for transactions, such as purchasing alcohol or entering a restricted age venue. Other examples of proof of age or proof of identity, the document contains a driver's license that is sometimes used to authenticate against the transaction. In some countries, passports and/or other similar identification documents are issued in the form of a card or a booklet and are available for transactions, where identification is required, including crossing the border or establishing a bank account. Many transaction files have a magnetic strip that can be encoded using information such as a unique identification number, expiration date, or other numerical or literary information. Other types of transaction documents include contactless stored value smart cards, such as closed loop transportation cards, such as Myki in Melbourne, Australia and Octopus Card in Hong Kong. The transaction file may comprise a wafer, smart chip or smart card chip (in the present specification, such chips or devices and other similar types of microcircuits will generally be referred to as digital transaction processing units, or DTPUs). The DTPU typically includes a central processing unit (CPU), read only memory (ROM), random access memory (RAM), electrically erasable programming read only memory (EEPROM), an encryption coprocessor, and an input. One or more of the /output (I/O) systems. For example, credit cards often use an EMV device (where EMV is an abbreviation for Europay, MasterCard, and Visa). The EMV device (or other type of DTPU) contains cryptographic material relating to the type of transaction(s) that the file will use. The EMV device can be directly contacted with the wafer connection electrode or by other components by a scanner (for example using non-contact proximity communication according to ISO/IEC 14443, referred to as near field communication (referred to as NFC in the specification)) Read to obtain data from the wafer. Such transaction files that are enabled for use in digital transactions by a wafer, a magnetic strip, a wafer and magnetic strip or radio frequency identification (RFID) are referred to herein as digital transaction files. The digital transaction file is configured to work with various components in a digital trading system that includes a terminal. For example, credit and debit cards work with EFTPOS (Electronic Funds Transfer at Point of Sale) terminals and ATM (Automated Teller Machine) terminals for point-of-sale (POS) transactions. Other digital transaction files are configured to work with other types of terminals. These terminals are operable to connect to financial institutions or other third party organizations to enable digital transactions to occur by authorizing transactions or performing associated processing to conclude a transaction. In another example, an identification card (such as an age certification card) is implemented using a wafer (or DTPU) containing some or all of the information of the card owner along with verification information to confirm the authenticity of the card. The ID card can be used for a digital transaction, which can therefore insert, swipe or revoke a terminal to confirm the age of the person holding the card. Other non-financial transactions can be implemented in a similar manner. A terminal for trading with a digital transaction file is referred to as a digital transaction system device in this specification. For "carded" transactions, digital trading system devices can include, for example, POS/EFTPOS terminals, ATMs and network connections, or stand-alone readers for reading other types of non-financial transaction files. Digital trading devices can also be suitable for "no card" transactions, such as online transactions, mail order/telephone order (MOTO) transactions, and can include Internet-connected PCs, smart phones and tablets. In addition, the digital transaction system device includes a telephone for communicating with an operator of one of the transaction file data input using, for example, a network connection. A digital transaction file has a unique identification (unique ID), usually with a number, a document ID, or a unique name. The unique ID can be located on a digital transaction file or in a digital transaction file (eg, printed or imprinted on a document). The unique ID is also typically recorded in, for example, one of the information controlled by the issuer of the digital transaction document and accompanied by other information such as name, address, age and/or financial information relating to the user/owner of the digital transaction file. On the library. Where a digital transaction file has a wafer, an EMV device, or other type of DTPU, the unique ID is typically stored on the wafer, EMV device, or DTPU, respectively. Credit cards are usually stamped or printed with a person/primary account number (PAN) to uniquely identify the account card holder. A standardized PAN has four fields, a system number, a bank/product number, a user account number, and a check digit. This type of PAN typically has 16 digits, but can have between 13 digits and 19 digits (eg, an American Express PAN has 17 digits). The first digital card issuer type (such as Visa, MasterCard, or American Express), and the next 5 to 7 digits are generally referred to as a bank identification number (BIN) and represent the bank's card network, bank, and product. The last digit is reserved as one of the previous digits of the PAN. A due date is associated with the PAN and generally contains one month and a year code with four digits but a limited range. The cardholder's PAN, name or company and card expiration date are usually displayed on the face of a card in embossed or printed form. Previously, some types of credit cards had a magnetic stripe that encoded some or all of the card information. Recently, financial transaction cards have carried a card verification value (CVV) or card verification code (CVC) on a magnetic stripe to make it difficult to duplicate a card for fraud. CVC is usually based on card data (such as a card containing the card PAN and the expiration date and a bank (or a humanized bureau) primary key generated and printed on the personalized data input card after printing a unique password on the card. Therefore, an attempt will be made The card used for fraudulent individuals needs to occupy the card for a sufficient period of time to make a copy of one of the magnetic strips to the card, or to read the card and manually record the card number, the expiration date and other details printed on the card. Subsequently, for a second CVC (Sometimes referred to as Card Verification Value 2 (CVV2), which is usually printed on the signature board on the back of the card) Adopt the same principle. CVV2 is mainly used to help protect e-commerce and MOTO transactions. This is the self-card information and the bank's primary key generation. One of the second unique passwords (although this is a different password than one of the magnetic strips CVC). CVV2 is not presented on the magnetic strip. Some credit cards also have an associated personal identification number (PIN) code, which is mainly used for "Card with" transactions. PINs must generally be kept confidential and must be entered on the security and authentication terminal to ensure that no one can access the PIN. In addition, in modern credit cards, the PIN can be stored in one encrypted form in a cryptographic block. On the chip (eg an EMV device) There are two main transaction categories for using a credit card, including: "no card" transactions when using the Internet or MOTO; and (such as) with POS/EFTPOS and ATM terminals "Card with" transactions. Card transactions involve EMV device readers (including physical contact readers that use electrode pins on a card and non-contact reading using, for example, near field communication (NFC)) and/or Magnetic stripe readers. These transactions typically use all 13 to 19 digit PAN and 4 digit expiration dates. Cardless transactions typically require the user to read the PAN and expiration date digits to an operator or to a computer. In the example, CVC/CVV2 numbers may also be required. Other types of digital transaction files may use various forms of security assurance, such as PINs, passwords, and the like. However, some other types of digital transaction files do not use such external security guarantees. And rely solely on the authenticity of the file itself, such as the use of holograms and other security devices that are difficult to replicate. In addition, some types of non-credit card digital transaction files can be used for security (package) Similar to the chip of an EMV device. The card (or other digital transaction file) may have, for example, data that is stolen using a radio frequency (RF) signal to power the card's EMV internal microprocessor and associated transmitter. Typically, the card data (such as PAN, expiration date and cardholder's name) transmitted to a wireless terminal. The terminal can be a portable or fixed wireless terminal, and once close to a card, RF signal is used to supply energy to the card to first extract card data. And copying some data to a memory storage device or online storage (such as the cloud) and secondly, using one of the portable terminals close to the card to withdraw money as a contactless payment according to a level of transaction that does not require any authorization ( For example, a PayWave and/or click-to-pay, which is referred to by a dealer as a touch or inductive payment. The stolen card information can then be uploaded to a copy of the "pseudo-card" or used for online transactions to effect fraudulent purchases. Another method for stealing card data for fraudulent purposes involves a computer database that invades the card data. This material is then used for the transaction, and a card owner can only be aware of this when they see a statement detailing the transaction that was implemented using their card or card material. Other ways of stealing card information include stubborn fishing, where the cardholder is tricked into entering a security code along with other card details via a fraudulent website. Therefore, phishing reduces the effectiveness of security code as a method of anti-fraud. However, merchants that do not use security codes typically experience higher card processing costs for transactions, and fraudulent transactions that do not require a security code are more likely to be decided by the cardholder, which increases the cost of the merchant. Other ways of damaging the security of the transaction are by skinning and man-in-the-middle attacks. With the advent of e-commerce, more and more transactions are cardless type transactions. However, this type of transaction suffers from more and more attacks from scammers, including attacks that have led to increased verification, and increased verification has caused a "validation error" result in which the cardholder is legal but the transaction is rejected. Several solutions have been developed to address this increased fraud, including the use of virtual account numbers, self-transaction to individually identify cardholders, and the use of a hardware beacon to authenticate users. Another proposed solution includes an institution, such as a bank that sends a code to a user (usually a smart phone that is sent to the user via SMS), which can then be used to authenticate a cardless transaction. This configuration is generally referred to as an out-of-band (OOB) message, which has recently been unfortunately compromised. In any event, many of these solutions require expensive infrastructure changes, and merchants would rather avoid the change and only provide protection for a limited time until the configuration is compromised. As the number of cardless transactions increases, one of the suggested ways to conduct such transactions is an e-wallet, also known as a digital wallet. An e-wallet provides a way for users to pay for purchases from online merchants that are enabled. After registration, a user can store their card, bill and ship the information to a location hosted by a suitable file (such as a bank) and can access the information to pay for the goods or services. However, an electronic wallet on an NFC-enabled device (such as a smart phone) does not operate in a large percentage of card transactions (such as POS/EFTPOS or ATM transactions), as these devices do not generally Support for contactless payments and contactless payment configuration at current kids, so different backend programs and merchant agreements are involved. Thus, the establishment and use of e-wallets has experienced limited commercial success and while e-wallets remain available to consumers, only about 10% of consumers have opted to install an e-wallet, although the rate of acceptance by consumers is now declining. A user may prefer to carry a number of available credit cards, debit cards, memory cards, government agency cards, and membership cards with them, as the user prefers to physically hold and control the possession of such cards. In addition, a user may need an ID card, driver's license, age verification card or passport. Carrying a large number of individual digital transaction files with you can be very inconvenient. Furthermore, an individual with so many physical transaction files can be confused about the location of a particular digital transaction file (e.g., a particular credit card) for all other digital transaction files. An alternative solution to an electronic wallet that addresses the issue of users carrying a large number of credit or debit cards has been developed, wherein a credit card sized device has a keyboard (or a touchpad configured to simplify the keyboard) and a smaller limited function graphics A user interface (GUI) that is used to select one of a number of cards stored on the device and to input data for various transactions. However, the keyboard has limited functionality due to its limited number of keys that are available in a relatively small space on the card (the average area of a credit card). The keyboard is also considered to be difficult to use due to its small size, and thus a large number of buttons may be required to implement any special function. In addition, the keyboard on a credit card is not a solution to other types of digital transaction files, such as those used to prove identity or prove age. Other attempted solutions include products such as Plastc, Coin, Final, and Wocket. However, the Plastec solution has some operational limitations, and the Wocket solution requires a specific Wocket device. None of these solutions have been widely accepted commercially. Furthermore, we have found that a card containing a keyboard has an unacceptably high error rate when given to a consumer in view of repeated (possibly daily) use. It has been suggested that this higher error rate may be due, at least in part, to the complexity of having a keyboard with a limited space for such a complex electronic device. Another problem with attempting to accommodate multiple credit cards, debit cards, or other digital transaction files on a single card is the limitation imposed by the use of proprietary or standardized wafers. These wafers or DTPUs are configured to only securely store information for a digital transaction file. For example, a credit card chip (such as an EMVCo standard chip) securely maintains information that typically includes a credit card PAN, expiration date, a security code (such as a CCV2 number), and a PIN. A transaction device (such as a POS/EFTPOS terminal) securely communicates with the DTPU to obtain some or all of the information to be authorized and verified from the DTPU. Many of the DTPUs are also configured to resist attempts to write to the DTPU Secure Record Memory (which may also be referred to as a secure element or part of a secure element) when many such attempts are made by a person attempting to fraudulently use the card. It should be understood that a secure element can include a secure memory and an execution environment, and wherein the application code and application data can be securely stored and managed in a dynamic environment. In addition, it should be understood that in a secure component, secure execution of the application can occur. A security element can be located in a highly secure hidden chip (also known as a smart card chip). The security of the DTPU also prevents the legal introduction of one or more new digital transaction files (including the PAN, symbol invalidation date, PIN and other data attributes of the files) into the secure recording memory (secure element) of the DTPU such that the DTPU The identity of another file cannot be presented (this article is used to describe a digital transaction file (or logical digit transaction file) and one of its attributes). Accordingly, it is difficult to facilitate the use of a single physical card with multiple identities (express or express multiple credit cards and/or debit cards on a single physical card), including modifications in the required infrastructure, including modified A DTPU (such as an EMVCo device), a modified digital transaction device (such as a modified POS/EFTPOS terminal), along with any other modifications required in other portions of the credit/debit card payment infrastructure. In addition to technical issues, card association solution providers (such as Visa and MasterCard) have a variety of additional requirements, including the presentation of a hologram and logo of a card association program on a physical card. Accordingly, it is desirable to provide a single EMV (or EMV) on a digital transaction card (DTC) capable of selectively assuming a number of different digital transaction files (or logical digit transaction files), such as a credit card sized card. Type device) or other type of DTPU. For example, a user may attempt to use a MasterCard account for a transaction but use a Visa account for a different transaction. Alternatively, a user may attempt to use the DTC as a credit card, but then use it as an age identification card. However, to date, there has been no sufficiently efficient, efficient, and/or secure manner and/or method for adapting a DTPU (such as an EMVCo specific device) to embody a different identity than the identity of the originally installed DTPU. Another problem with current digital trading documents is the ability to obtain information from a credit card or other transaction file. Although devices such as EMV devices have been introduced in an attempt to limit data theft, such configurations have not proven to be completely successful in preventing this type of crime. More and more credit card fraud can incur a price paid by a bank, a merchant, a user or all three parties. In addition, users are increasingly concerned about identity theft, which is due to a stolen identity that can be used to swindle financial transactions and other types of crimes. For some digital trading files (such as credit cards), the beacon is sometimes used to enhance the security of the transaction. For credit cards, the beacon is usually the same number as the length of the credit card's PAN and is replaced by a PAN in a transaction. The beacon should not be decodable to obtain the original PAN by an individual attempting to fraudulently use the credit card, and to enable the individual to impersonate the credit card and not be able to use the PAN of the credit card and other personal details of the cardholder for one of the online transactions. Accordingly, if a credit card is used in a high-risk, low-security environment, the beacon is one way to protect sensitive data. The security of the beacon is based primarily on the determination of the original PAN (or other material) while only knowing the impracticality of the proxy value. Beaconization can be used in place of or in conjunction with other encryption techniques in transactions using digital transaction files. A beacon (or digital beacon) may be generated by a third party (such as a credit card issuer, a financial institution, or a security provider of a credit card). The logo is also used to protect other non-financial transactions (such as transactions involving driving licenses). The beacon may be generated as a ciphertext input using one of the PAN (eg, some other unique ID of a digital transaction file) and/or one of the card's expiration dates. The beacon for a transaction may be selected from a number of beacons in a pool based on the ID of the merchant or the terminal in which the transaction occurred, the date of the transaction and the time of the transaction, or various other criteria. De-scaling typically occurs during the processing of a transaction to retrieve the original PAN, and de-authentication is typically performed by a credit card issuer, financial institution, or security vendor that issues the beacon. Typically, a beacon is generated during the process of generating and distributing a credit card to its owner/user. Each card may have one or more associated beacons. In the case where a card has multiple beacons, each beacon can be selectively used for different transactions or different transaction types. The beacon has several issues, including that it cannot be selected by the user to allow the user to control security and how to use the beacon. For example, a user may attempt to be able to select a beacon for a particular transaction or transaction type. Another problem is that the same beacon can be used for several different transactions, thus limiting the security afforded by the beacon. This is especially true for digital transaction files such as a credit card. Even if a digital transaction file has several associated beacons, the beacons will need to be reused or reissued after a number of transactions. It is difficult to issue new beacons, for example, to a credit card, as well as the infrastructure that has been developed to issue new beacons to issue such new beacons when a new credit card is generated and issued. One way to prevent theft of a stolen or damaged credit card or other type of transaction is to cancel the document only, including the unique identifier that canceled the document (for example, canceling a credit card account), and the issue has a new expiration date. A new file. The vendor of the file may have a mechanism for invalidating the old file (eg, invalidating the old account) and issuing the new number to the existing user. However, sometimes it takes a lot of time to deliver a new file (for example, a credit card is delivered via mail), and the delay is extremely inconvenient for the user. In the case of a credit card, the issuance of a new card causes the user to temporarily suspend the ability to pay by the automatic transfer from the credit account. In addition, file owners generally prefer instant or near-instantaneous ("instant") information about the use of their cards for financial transactions or other types of transactions, such as the use of a card or other such documents for identification, travel and other purposes. ) Feedback. Card owners may also prefer instant feedback on account balances and other information about the owner's card or other digital transaction documents. In addition, the owner of the card and other digital transaction files may prefer to block the ability to use a file on the fly or with minimal delay. This may be useful if the owner is aware of or suspects fraudulent transactions (several) due to the use of one or more of its digital transaction files. Currently, digital transaction cards (DTCs), such as credit/debit cards, have been able to pre-define keyboards and financial institutions (such as banks) via one of the ATMs or readers or readers/writers that are typically approved by a financial institution. ) Communication. The infrastructure of the current operation limits any interaction between the reader-writer approved by the financial institution and one of the EMV devices outside the approved external keyboard. Existing digital transaction terminals cannot be operated using a device such as a smart phone. For example, an electronic funds transfer (EFTPOS) or point of sale (POS) terminal at a point of sale can only be operated with a digital transaction card (DTC) (such as a credit/debit card) that is suitable for configuration. These credit or debit cards will each have a single "identity" or be expressed as a single file. For example, a given DTC may only have the identity of a MasterCard or a Visa card, but cannot selectively and continuously present the identity of both a MasterCard and a Visa card at different times. In addition, devices such as smart phones cannot communicate with known DTCs. For example, a smart phone cannot communicate with a credit or debit card using an existing communication protocol. Accordingly, it is not possible to reprogram, rewrite, or reconfigure a DTC to provide a different identity. In addition, it is known that DTCs (such as credit cards or debit cards) cannot be updated to express a desired identity (eg, changing a physical card from expressing a MasterCard to expressing a Visa card). Therefore, DTC cannot be used with one of the POS/EFTPOS terminals of the transaction. A Digital Transaction Processing Unit (DTPU) embedded in a standard credit or debit card typically contains contact electrodes present on the surface of a card configured to contact a corresponding contact electrode in, for example, a POS/EFTPOS terminal. This physical contact allows the DTPU to communicate with the POS/EFTPOS terminal and is connected to a payment infrastructure to complete a digital transaction. The DTPU is typically an EMV wafer (where EMV is abbreviated as one of Europay, MasterCard, and Visa) or one of the EMV Co specifications. Some current DTPU or EMV wafers may include an integrated circuit (IC), which is typically part of an EMV wafer formed from a substance such as germanium. The EMV die can further include read only memory (ROM), random access memory (RAM), and/or electrically erasable programming read only memory (EEPROM). The DTPU can contain other kinds of memory. In addition, the DTPU can include a central processing unit (CPU) for controlling the operation of the DTPU. The CPU can cooperate with an encryption coprocessor that handles the task of encrypting and decrypting data, thus allowing the CPU to freely perform other processing tasks. Communication between the DTPU and the electrodes is performed via a system input/output (system I/O). The IC of the EMV chip has one of the active sides, usually in a certain package form, and is adhered to a substrate using an adhesive. Contact electrodes, typically made of metal, are exposed to external termination devices and connected to the IC using bond wires. The substrate is placed in one of the holes in the body of the card. The substrate carrying the IC, the metal contact electrode, the package, and the wiring is fixed to the hole of the card body using a hot melt adhesive applied to the edge of the substrate. Some known DTCs include a numeric keypad for controlling the operation of an EMV wafer embedded in a card. The cards may also include a digital display and one or more buttons or keys to open and close the card. The card can use a specially constructed EMV wafer that allows the keyboard and any other components of the card to operate the EMV wafer for limited control of the wafer and operation of the display. However, this type of card is difficult to operate due to the limited functionality of the keyboard. In addition, the display can only display a very limited amount of data. These cards have proven to be cumbersome and difficult to operate, resulting in a very low acceptance of one of the consumers. Accordingly, devices such as smart phones and credit cards and debit cards are not capable of interoperating with each other. These cards may be designed to interact with one of the EM/AFTPOS terminals in a POS/EFTPOS terminal, and such POS/EFTPOS terminals may be included for processing transactions and via an EMV interface with inclusion such as an EMV release One of the back office agencies pays for one of the terminal modules for processing infrastructure communications. Devices such as smart phones can also communicate wirelessly with one of the POS/EFTPOS terminals. However, wireless communication between smart phones and POS/EFTPOS terminals has very low insight into merchants, such as replacing existing infrastructure to allow this type of operation to be expensive. In addition, direct communication between a smart phone and a POS/EFTPOS terminal can introduce several security issues with such transactions. It is an object of the present invention to overcome or at least ameliorate at least one of the above mentioned problems in the prior art and/or to provide at least one useful alternative to prior art devices, systems and/or methods.

In one aspect, The invention provides a digital transaction device comprising a data assisting device (DAD), The data assist device (DAD) contains: a user interface, It is operable to select at least data, And a DAD transmitter, a digital trading card (DTC), It contains: a digital transaction processing unit (DTPU), And a DTC receiver, Wherein the DAD and DTC are operable to transfer data from the DAD to the DTC and when subsequently using the DTC to implement a digital transaction, The DTC operates according to the data selected and transmitted from the DAD to the DTC, And wherein the DTPU operates according to the firmware, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the material into a temporary memory and transfer the data in the temporary memory to the secure recording memory.  In another aspect, The invention provides a data assisting device (DAD), It contains: a user interface, It is operable to select at least data; And a DAD transmitter, It is operable to transfer data from the DAD to a receiver associated with a digital transaction card (DTC) having one of a digital transaction processing unit (DTPU) operating according to a firmware, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the data into a temporary storage memory and transfer the data in the temporary storage memory to the secure recording memory. The data selected and transmitted to the DTC causes the DTC to operate in accordance with the selected material when the DTC is subsequently used to implement a digital transaction.  In another aspect, The invention provides a digital transaction card (DTC), It contains: a digital transaction processing unit (DTPU); And a DTC receiver, It is operable to receive user selected data from a transmitter associated with a data assist device (DAD), The data selected by the user received causes the DTC to operate according to the data selected by the user when the DTC subsequently uses to implement a digital transaction. And the DTPU according to the firmware operation, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the material into a temporary memory and transfer the data in the temporary memory to the secure recording memory.  In another aspect, The invention provides a digital trading method, It contains: Selecting data from a user interface of a data assist device (DAD); Transmitting the selected material to a receiver associated with a digital transaction card (DTC) having a digital transaction processing unit (DTPU) by a DAD transmitter associated with the DAD; And a digital transaction by the DTC, Wherein the DTC operates according to the data selected and transmitted from the DAD to the DTC, Where the DTPU operates according to the firmware, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the material into a temporary memory and transfer the data in the temporary memory to the secure recording memory.  In another aspect, The present invention provides a method of operating a data assist device (DAD), It contains: Selecting data from a user interface of the DAD; And transmitting, by the DAD transmitter associated with the DAD, the selected data to a receiver associated with a digital transaction card (DTC) having one of a Digital Transaction Processing Unit (DTPU) operating according to a firmware, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the data into a temporary storage memory and transfer the data in the temporary storage memory to the secure recording memory. The DTC operates in accordance with the selected and transmitted data when the DTC is subsequently used to implement a digital transaction.  In a further aspect, The present invention provides a method of operating a digital transaction card (DTC), It contains: Receiving data from a data assist device (DAD) containing information selected by the user; Realizing a digital transaction by the DTC, Wherein the DTC operates according to the data selected by the user, Where the DTPU operates according to the firmware, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the material into a temporary memory and transfer the data in the temporary memory to the secure recording memory.  In a further aspect, The invention provides a computer readable medium, It stores one or more instructions, When executed by one or more processors associated with a data assist device (DAD), The one or more instructions cause the one or more processors: Selecting data from a user interface of the DAD; And transmitting, by a DAD transmitter, the selected data to a receiver associated with a digital transaction card (DTC) having one of a digital transaction processing unit (DTPU) operating according to a firmware, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the data into a temporary storage memory and transfer the data in the temporary storage memory to the secure recording memory; The DTC operates in accordance with the selected and transmitted data when the DTC is subsequently used to implement a digital transaction.  In a further aspect, The invention provides a computer readable medium, It stores one or more instructions, When executed by one or more processors associated with a digital transaction card (DTC), The one or more instructions cause the one or more processors: Receiving data selected by the user from a data assist device (DAD); And subsequently implement a digital transaction, Wherein the DTC operates according to the data selected by the user, Wherein the DTC includes a Digital Transaction Processing Unit (DTPU) based on firmware operations, Wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, When executing the set of extension commands, Allow data to be written to one of the DTPU's secure record memory. The firmware is operable to instruct the DTPU to copy the material into a temporary memory and transfer the data in the temporary memory to the secure recording memory.  In a further aspect, The present invention provides a method, It includes receiving, from an issuing authority, a DTC configured to operate in accordance with any one or more of the above statements.  In a further aspect, The present invention provides a method, It includes a DTC that is issued by an issuer configured to operate in accordance with any one or more of the above statements.  In a further aspect, The present invention provides a method, It includes receiving, from an issuing authority, one of the DTCs configured to operate in accordance with any one or more of the above statements.  In a further aspect, The present invention provides a method, It includes a DTC that is issued by an issuer configured to operate in accordance with any one or more of the above statements.  In a further aspect, The present invention provides a method, It includes issuing, by an issuing authority, an opcode containing software and/or firmware to a data assist device (DAD) and/or a digital transaction card (DTC) to enable the DAD and/or DTC to act according to the above statement. One or more operations.  In a further aspect, The present invention provides a method, It includes issuing, by an issuing authority, an opcode containing software and/or firmware to a data assist device (DAD) and/or a digital transaction card (DTC) to enable the DAD and/or DTC to act according to the above statement. One or more methods of operation.  SUMMARY OF THE INVENTION (Several Embodiments) Those skilled in the art will appreciate that in an embodiment of the invention, A digital transaction device that includes and needs to be used for one of a digital transaction (DAD) and a digital transaction card (DTC) to provide multi-factor factor verification (including authorization, Identification and authorization and identification of both), Factor users (such as some users attempting to pay for goods and/or services using a financial digital transaction) require two items. That is, DAD and DTC and knowledge about how to use the two items to achieve a transaction. Correspondingly, If a person has both a DAD and a DTC in an attempt to conduct a digital transaction, Then the individual has been scammed, The possibility of stealing or defrauding to obtain two items is reduced. E.g, If the DAD is a smart phone, An individual attempting to commit a fraudulent transaction will not be able to steal a legitimate DTC and the owner's smart phone when compared to the theft of a legitimate credit card, such as one currently used for digital transactions. In addition, If an individual attempts to steal a legitimate DTC, It is difficult for the individual to imitate or deceive the smart phone of the DTC owner. Contains any additional hardware and software necessary to work with DTC for a digital transaction.  In an embodiment, DAD and DTC are operable to transfer data between DAD and DTC, It can further help reduce the occurrence of fraudulent digital transactions. E.g, The DAD can be used to transfer the PIN (OTP) to the DTC once and for each transaction. The OTP is requested by a digital trading system device during a digital transaction and requires the user to enter a PIN to complete the transaction. In any case, It is expected that transferring data between DAD and DTC will help users manage and monitor their digital transactions.  In an embodiment, The present invention provides a method for digital trading using a digital transaction device, The digital transaction device includes a plurality of logical digit transaction file packages (LDTDP). Each LDTDP represents a digital transaction file and includes a unique identification (a unique ID) or one or more of a beacon associated with the unique ID for performing a digital transaction using at least one digital transaction device, The digital transaction device further includes: An LDTDP storage memory; a temporary memory; a DAD; a DTC, It contains a digital transaction processing unit (DTPU), And a secure record memory, The method includes: Operating the DAD to select one of the at least one LDTDP stored in the LDTDP storage memory; Copying the selected one of the LDTDPs from the LDTDP storage memory to the temporary storage memory; And copying the selected one of the LDTDPs from the temporary memory to the secure record memory, The DTC is thus enabled to operate as a digital transaction file associated with the selected one of the LDTDPs. In other embodiments, Providing a method for digitally trading using a digital transaction device that identifies a plurality of LDTDPs, Each LDTDP represents a digital transaction file and includes a unique ID or one or more of a beacon associated with the unique ID for performing a digital transaction using at least one digital transaction device, The digital transaction device further includes an LDTDP storage memory, a temporary memory, a DAD and a DTC, The DTC includes a DTPU having a secure recording memory; The method includes: Operating the DAD to select one of the at least one LDTDP stored in the LDTDP storage memory; Copying the selected one of the LDTDPs from the LDTDP storage memory to the temporary storage memory; Copying the selected one of the LDTDPs from the temporary memory to the secure record memory, The DTC is thus enabled to operate as a digital transaction file associated with the selected one of the LDTDPs. In these embodiments, A known operation of an existing DTPU (such as an EMV device) is used to place data about a particular identity in the memory location to be accessed by the EMV device to establish the identity of the DTC.  In various embodiments, The digital transaction file can be a credit card, Debit card, Bank account, Memory card, passport, ID card, Age verification card, membership card, Government agency card, Driver's license and / or various other types and types of digital trading documents, They will usually be implemented as cards, Document or brochure or electronic implementation. It should be understood that in this specification the term "logic" is referred to as a group attribute of each of the digital transaction files. And these features may be partially or fully contained in one of the representative files or logical files LDTDP. Features may include a unique ID such as a digital transaction file, Information and information on the date of expiration. The unique ID information can be a unique ID number. The change in the DTC parameters adopted by the DTPU from the expression of one digital transaction file to the achievement of one of the other digital transaction files may also be referred to as a change in the DTC "identity". In addition to changing the parameters in a DTC to adopt an identity for future transactions, In a particular embodiment, The DAD is operable to receive information about the new identity by accessing a website and is further operable to transmit the relevant command to the DTC to adopt the identity of the newly acquired identity obtained by the DAD.  In an embodiment, An LDTDP can include a unique ID and a beacon associated with the unique ID. Unique IDs and beacons are associated with digital transaction files represented by LDTDP. In other embodiments, The LDTDP may only contain a unique ID associated with the digital transaction file. In other embodiments, The LDTDP may only contain the beacon associated with a particular unique ID. Unique ID (and therefore, The symbol is associated with a digital transaction file.  In some embodiments, Each of the plurality of digit transaction files can be associated with a single unique ID and a single beacon associated with the unique ID. Each of the other digital transaction files can be associated with a single unique ID and a number of different beacons associated with the unique ID. And each of the other digital transaction files may not be associated with any of the beacons (in that case, This digital trading file will only be associated with a unique ID). In these embodiments, The unique ID and/or beacon for a digital transaction file (or logical digit transaction file) will be included in an LDTDP. In the case where a file has several associated beacons, Each beacon or beacon/unique ID pair can be in a separate LDTDP. In an embodiment, If the file is a credit/debit type card or a similar type of unique ID (such as a unique number ID or unique name), The unique ID of the digital transaction file included in the LDTDP may be a person/primary account number (PAN).  In some embodiments, The at least one of the plurality of LDTDPs is stored on the DAD. The LDTDP storage memory is located on the DAD. In other embodiments, The at least one of the plurality of LDTDPs is stored in the LDTDP storage memory located on the DTC. Wherein an LDTDP is selected by the DAD and is represented by an icon, Name or other indicator implementation associated with the LDTDP, Although the LDTDP itself is not stored on the DAD. In this example, The selection of the LDTDP is communicated to the DTC by indicating which LDTDP has been selected. And the DTC implements the selected LDTDP from its LDTDP storage memory based on the indication data.  In other embodiments, A portion of each of the at least one of the plurality of LDTDPs is stored on the DAD. Another portion corresponding to at least one LDTDP is stored on the DTC. The selection is based on the portion that is stored on the DAD. The selected part of the LDTDP is transmitted to the DTC. And determining which part of the LDTDP matches the selected portion on the DTC. In this way, The two parts of the LDTDP can be combined to form the entire LDTDP, It can then be implemented by the DTC. In this embodiment, Share LDTDP storage memory between DAD and DTC.  In an embodiment, Enable DAD to store and provide an LDTDP option, It is implemented as a digital transaction file on the DTC. The selection of a file associated with an LDTDP (or the selection of an LDTDP) can occur prior to selecting a beacon associated with the LDTDP. In the case where a file has only one associated beacon, The choice of file can be the selection of the associated beacon. Because there is no need for a further selection procedure. In some embodiments, Selecting a beacon automatically indicates which LDTDP to select, Because the beacon is only associated with a file (or an LDTDP).  In another embodiment, The user can select an LDTDP and select a predetermined beacon based on the context determined by the DAD. E.g, If the DAD determines different positions, A beacon can be automatically selected based on the determined location.  In various embodiments, Some digital transaction files included in an LDTDP will only have an associated beacon. And other digital transaction files will have multiple associated beacons. It should be understood that the embodiments described in this specification contain two options, One embodiment is not possible unless otherwise specified or unless two options are included.  In various embodiments, Some identification information about a digital transaction file contained in an LDTDP will not need to be stored in the device LDTDP storage memory (in device memory or card memory), Because the (several) beacons stored in the device will be sufficient to identify its associated digital transaction file. E.g, In the case where the digital transaction file is a credit card, The card number (PAN) is not included in the LDTDP and is instead The beacon associated with the credit card is sufficient to identify a particular credit card. In this example, A credit card PAN may include identifying the card as a particular type or brand (MasterCard, Visa, etc. 4 typical leading digits. One of the specific credit cards can have four identical leading digits. But with different remaining digits, Enables the beacon to identify its associated card. It will be appreciated by those skilled in the art that PAN, which is included, for example, in each LDTDP and stored in the device LDTDP storage memory (in DAD memory or DTC memory), should increase the security of the associated digital transaction file. In these examples, The digital signal system containing only LDTDP is selected by DAD. It automatically identifies and selects the associated digital transaction file.  In an embodiment, The DTPU CPU operates to copy data from the scratch memory (scratch area) to the EEPROM. Or to a part of the EEPROM that has been reserved for the secure recording memory (secure element). In other embodiments, The DTPU CPU operates to copy portions of the data from the scratch memory to a portion of the EEPROM that has been reserved for the secure recording memory. And copy another part of the data to the part of the EEPROM that is not reserved for the secure recording memory. When, for example, an LDTDP is copied into a secure recording memory (secure element), DTPU uses digital transaction file information from the LDTDP (unique ID, Signal, Effective date/time, Expiration date/time, etc.) to get an identity, Making the DTC operate with the associated attributes of the file (such as the effective date/time, The associated digital transaction file for expiration date/time, etc.).  It is familiar to the reader that a particular digital transaction file may be represented by one or more LDTDPs. E.g, A digital transaction file associated with only one unique ID will be represented by a single LDTDP containing one of the unique IDs. In this example, Copying the LDTDP to a secure record memory (which may be referred to as a secure element or a secure element area) causes the DTC to operate as a digital transaction file associated with the unique ID.  In another example, A digital transaction file associated with a unique ID and a single beacon may be represented by a single LDTDP containing the unique ID and one of the beacons. In this example, Copying the LDTDP to the secure record memory (secure element) causes the DTC to operate as a digital transaction file associated with the singularized unique ID. Alternatively, A digital transaction file associated with a unique ID and a single beacon can be represented by two LDTDPs. An LDTDP contains the unique ID, Another LDTDP contains the beacon. In this alternative example, Copying the LDTDP containing the unique ID to the secure record memory (secure element) causes the DTC to operate as a digital transaction file associated with the unique ID (not calibrated), Copying the LDTDP containing the beacon associated with the unique ID to the secure record memory (secure element) causes the DTC to operate as a digital transaction file associated with the beaconed unique ID.  In another example, A digital transaction file associated with a unique ID and a plurality of beacons may be represented by various LDTDPs including both the unique ID and one of the plurality of beacons. Or by a number of other LDTDP representations including one of the unique IDs LDTDP and each of the plurality of beacons associated with a unique ID associated with the digital transaction file represented by all LDTDPs, Copying one of the LDTDPs to the secure record memory causes the DTC operation to be a digital transaction file associated with the singularized unique ID or a digital transaction file associated with the unsynchronized unique ID.  Other configurations of LDTDP are conceivable, It depends on the nature of the digital transaction file represented by LDTDP (or several LDTDPs).  In some embodiments, An LDTDP may also contain further information associated with a digital transaction file. Such as the expiration date of one of the files. It may also be desirable in some cases to have multiple expiration dates in an LDTDP (eg, one of the expiration dates for a unique ID (or for an associated digital transaction file) and one of the beacons associated with the unique ID. Another expiration date). It should be understood that in the case of a digital trading document having a number of associated beacons, Each beacon may have a different expiration date to be included in one of the respective LDTDPs.  In addition, The LDTDP for some digital trading documents may contain an effective date. A period between the invalidity and effectiveness of the effectiveness of the controllable file (and/or one or more of the beacons associated with the document). E.g, If the document is a room card or some other card or pass with a short-lived requirement, It can then be expected that the digital transaction file will be valid for only one day. Furthermore, The validation and expiration in the LDTDP may include the time and date of finer control of the validity period for the digital transaction file (and/or one or more of the beacons associated with the digital transaction file).  In other embodiments, Further information contained in an LDTDP may include a security code associated with the unique ID of the file, It may also include a number of other different security codes associated with one or more of the beacons also included in the LDTDP. E.g, In the case where the digital transaction file is a credit card, The security code can be a Card Verification Value 2 (CVV2) security code or the like. In this example, The unique ID is a PAN, It has an associated CVV2 security code, And the PAN may have five associated beacons, Each beacon also has an associated CVV2.  In other embodiments, The LDTDP may contain a Personal Identification Number (PIN) for one of the digital transaction files. There may be one PIN associated with the unique ID of the file, And other (different) PINs, Each is associated with a beacon. In some embodiments, The PIN can be an PIN (OTP) once. It expires after being used for a single transaction. In other embodiments, The PIN can have a limited effectiveness period. E.g, One week after the first use.  In other embodiments, LDTDP can contain other information. Such as name, date of birth, Entity characteristics and other personal data of an individual who owns a digital transaction file. E.g, If the digital transaction file is a passport, Then for a particular transaction, It is contemplated that one of the passport unique IDs and one of the owner's eye colors, LDTDP, will be identified and/or verified in such transactions.  LDTDP can be described as containing, contain, Winding or embodying a unique ID, Beacons and/or other materials. In addition, LDTDP can be encrypted (or otherwise protected) to protect the data contained in the LDTDP. In other embodiments, LDTDP can be protected using a public/private key infrastructure. Public and private keys may be issued by, for example, the principal issuer of DTC. Alternatively, The public and private keys may be issued by one of the major distributors of LDTDP (eg, a credit card provider).  In some embodiments, The DTPU may contain system input/output (system I/O) for inputting and outputting data and/or data encrypted to and from the DTPU. System I/O is a way, The LDTDP can be copied to the secure recording memory (secure element). This allows the DTPU to operate using the identity of the logical digit transaction file contained in the LDTDP. The security element can be located on one or more devices. It can also be located in a single device with a virtual partition or a folder.  The DTPU can also include a processor or central processing unit (CPU). It operates to control the DTPU. In addition, The DTPU may include an encryption co-processor for efficiently encrypting and decrypting data. This allows the DTPU CPU to operate more efficiently without the burden of encryption and decryption tasks. In some embodiments, The DTPU CPU and the encryption coprocessor cooperate to decrypt (unfree, before being stored in the secure record memory or in the secure record memory) Open or otherwise process a selected LDTDP, This allows the DTPU to operate with data from LDTDP.  DTPU can also contain a variety of different types of memory. Such as read-only memory (ROM), Random access memory (RAM) and electrically erasable programming read-only memory (EEPROM). In some embodiments, One of the types of memory can be used for secure recording of memory (also known as a secure element). One of the other types of memory is used for temporary storage memory (which may also be referred to as a temporary storage area). Any of the above types of memory can be used as the LDTDP storage memory.  In some embodiments, DTPU is an EMV device, Or one device that conforms to one or more EMVCo specifications. In other embodiments, DTPU is an EMV device (otherwise conforms to one or more EMVCo specifications), It is configured to read a secure storage area (temporary memory/temporary area) to establish the identity of the card in which the DTPU is installed. The secure storage area or scratch memory can be in the constructed EMV device, Within the constructed EMV device storage area (memory) or some other secure memory.  In an embodiment, The CPU of the DTPU and/or one of the CPUs external to the DTPU but resident in the DTC (referred to as an external DTC processor) is only started after the CPU or external CPU securely identifies itself to a linked DAD (such as a smart phone). In some embodiments, The link between the DAD (eg, a smart phone) and the DTC uses stronger encryption for the transmission of IDs and data. The link is unique to each set (smart phone and DTC).  In an embodiment, The link between DAD and DTC is wireless, And can be formed using the respective transceivers of DAD and DTC. In other embodiments, The DTC can be linked to the DAD using a physical connection (such as a data cable) (ie, operational to establish communication). In these embodiments, The data cable can be adapted at one end for insertion into one of the communication ports (such as a USB port) on the DAD. The other end is adapted to be clamped or clamped to a portion of the DTC. The DTC may have an electrode or a metal plate located at one edge of the DTC or toward one of the edges of the DTC to be connected to the cable when the other end of the data cable is clamped or clamped to the DTC. In some embodiments, The respective transceivers of DAD and DTC are suitable for BluetoothTM, Low Energy BluetoothTM, Wi-Fi, NFC, ANT+ or other types of contactless or wireless communication transceivers. In an embodiment, The DTC can include a button or a similar device to initiate a link to the DAD.  In various embodiments, The DAD is operable to transfer data to the DTC without the need to form a direct link between the DAD and the DTC. In these embodiments, The DAD is used to, for example, transfer data over a network to a third party connected to the cloud. A link between the DAD and a third party device for data transfer may be temporary, And once the data has been completely transferred, This link can be terminated. The third party device is connected to, for example, a network (possibly via another third party, Such as a payment processor), It enables third party devices to form a link and communicate with a digital trading system device such as a point of sale/electronic money transfer (POS/EFTPOS) terminal or automated teller machine (ATM) at the point of sale, A link to the network and thus to one of the digital transaction system devices is then formed. A third party device is enabled to transfer data previously received from the DAD to the digital transaction system device. One of the DTC holders (which may be different from the owner of the DAD and/or one of the operators) may bring the DTC to the digital transaction device. And by inserting, Or placing the DTC close to the device, DTC holders can obtain information from digital trading system devices. In this way, Information from the DAD can be transferred to the DTC indirectly and asynchronously. This indirect data communication between the DAD and the DTC can also be reversed so that the DTC may use digital trading system devices, a network containing payment processors, The same infrastructure of third-party devices and the Internet transmits indirect and asynchronous data to the DAD. We will be aware that indirect and asynchronous data transfer can be useful in the case where a first person has a DAD and wants to send data to a DTC under the control of a geographically remote second person. . E.g, One of the mothers who operate their DAD may prefer to increase the spending limit of one of the DTCs operated by their child (in a foreign country).  In an embodiment, The external DTC CPU controls the reading and re-reading and updating of the DTPU's memory contents by the DTPU (eg, an EMV device).  In an embodiment, A DTC includes a wearable payment device (such as a watch) but also includes the incorporation of several pieces of jewelry (such as a ring, Bracelet and pendant) payment device. The DTC can also include an implantable payment device. It includes a wafer and transceiver configuration that can be suitably configured for subcutaneous implantation.  In other embodiments, The DAD can be a smart phone or other suitable device (such as a chain or a key chain) or a portable processing device with one of the internal/external wireless communication capabilities (such as NFC reading configured to operate as one of the DADs) / writer). In some embodiments, The DAD can be or can include a wearable device such as a watch or other jewelry. According to this, Some smart phones are currently operated with wearable wrist (or similar) devices. It is envisaged that a future smart phone can be fully integrated into a wearable device and that the DAD can be a device. In the case where the DAD includes a smart phone that operates with a wearable wrist (or similar watch) device, A wearable component can have its own unique ID. It can be used for secure linking and data transfer between DAD and DTC, respectively, in cooperation with a smart phone and the unique ID of the DTC.  In other embodiments, After connecting securely to DTC, DAD (smart phone) correctly uploads the formatted data in an LDTDP to the specified secure storage area (temporary memory or scratchpad area) and then transmits a command to the DTPU CPU or external DTC CPU to check whether the specified storage area is Contains data in a specified format (eg, a compliant LDTDP). If the data meets the specified format requirements and passes various checks, The DTPU CPU or external DTC CPU then copies or moves the data (LDTDP) to a designated area (secure record memory/secure element) within one of the DTPUs (eg, within the EMV device). then, The DTPU CPU or external DTC CPU transfers a command to the DTPU (EMV device) to read the data in the secure record memory (LDTDP) and based on the data contained in the secure record memory (secure element) (express LDTDP as relevant) The digital transaction file). The DTPU CPU or external DTC CPU can be programmed to search for a particular header and/or other material identifier within one of the parameters prior to action. In other embodiments, It is possible to copy all records of all LDTDP to the scratch memory. And an index is used to reference the selected LDTDP from the records. Copying all records in this way reduces the need to write to the scratch memory and/or read from the scratch memory, And thus reduce the risk of accessing this memory area (including security risks).  In some embodiments, The secure recording memory (secure component) is located in the DTPU. The scratch memory (scratch area) is located outside the DTPU on the DTC. And the LDTDP storage memory (storage memory or a memory location) is located on the DAD. In other embodiments, The secure recording memory (secure element) can be located in an external CPU on the DTC. In addition, The LDTDP memory and/or scratch memory (scratch area) can be external to the DTC as, for example, additional memory located on the DAD. Although the secure recording memory (secure element) can be located outside the DTPU, However, this configuration can be considered as less secure than positioning the secure record memory within the DTPU. however, Any security issue can be mitigated by encrypting any data located in one of the secure record memories outside the DTPU. In other embodiments, The LDTDP memory can be located anywhere except DAD or DTC. And, for example, the LDTDP storage memory can be located in a cloud-based storage system. Or it can be located on a portable memory that can be accessed from the DAD.  In an embodiment, The DTC contains a card transceiver. In other embodiments, The DTC includes a graphical user interface (GUI) for displaying information associated with a digital transaction file or a symbol associated with a selected or implemented LDTDP. E.g, If the logical digit transaction file is a credit card, Then the GUI on the DTC can display PAN, Selected beacons associated with the selected LDTDP containing the logical digit transaction file, Card brand logo, The expiration date of the credit card, It can also display a virtual or simulated hologram of one of the credit card brands. In another embodiment, DTC can only display selected beacons. Contains the expiration date and / or CVV2, And not the associated PAN. The DTC may also contain an actual hologram displayed somewhere on its surface.  The external DTC CPU (or external processor) can control the operation outside the DTPU and/or control read/write operations and other input/output operations with the DTPU via the DTPU system I/O. The external DTC CPU can also accommodate security tasks and/or control GUIs external to the DTPU. In some embodiments, The external DTC CPU may include a firmware operable to write data (eg, LDTDP data) to the scratch memory such that when the DTPU is started, The DTPU copies the data to the secure record memory (secure element) in the DTPU. In an embodiment, The firmware on the external DTC CPU is updatable and the DTC has a way to achieve firmware updates. The update may include firmware that extends the functionality of the DTC and any programs and/or applications running thereon. The update allows for the correction or correction of existing firmware functions that have been identified as faulty or sub-optimized. Other firmware updates may be issued to improve or extend the security or security of DTC. The ability to update firmware can be compared to (for example, an existing credit card or debit card using an EMV device). There is no or limited ability to update the EMV firmware. current, The firmware is replaced with "update" by the time a credit card or debit card is expired. In the case where the DTC has a relatively long operational life (for example, 5 years or more), Updating the firmware during the operational lifetime of a DTC allows the functionality of the DTC to be improved or enhanced without having to return the DTC to an issuer.  In an embodiment, The DTC can only form a communication link with one of the DADs to exclude all other DADs representing a secure communication link and the transmission of data between the DAD and DTC of the respective transceiver (DTC transceiver and DAD transceiver). In some embodiments, The link is a secure/encrypted link. In other embodiments, Each DAD can be linked to multiple DTCs. however, In this embodiment, Each DTC can only be linked with one DAD to exclude all other DADs.  In an embodiment, The link between the DTC and the DAD can be implemented by using one of the DTC unique identification codes and another unique identification code of the DAD. In some embodiments, The link between the DTC and the DAD can occur (at least in part) before the DTC is sent to a user. E.g, The link can be made by a DTC issuer (including a bank, a card issuing facility, A card "personalized" facility or other type of third party that is capable of implementing a "partial" link. In an embodiment, A portion of the link may be implemented by a DTC issuer that establishes a DTC and provides an application that is easily downloaded by one user to the user's DAD (eg, a smart phone). The launch of the application causes a smart phone search and links to the DTC issued to the user. In other embodiments, The link can be implemented by the user and can occur when the user receives the DTC.  In some embodiments, The link between DTC and DAD is permanent or semi-permanent, It is not possible to unlink or relink without permission and without the required actions from, for example, one of the previously mentioned third parties. E.g, To unlock a DTC and the only link to its DAD, A unique code can be entered on the DAD and uploaded to the DTC. This will reset the DTC to a preset state. In the preset state, The DTC can "find" a newly assigned unique identifier for one of a different DAD (eg, one of the smart phones' IMEI number or another suitable unique ID). When a user replaces their DAD (such as a smart phone), This unwind/relink can be useful. In other embodiments, Links can be temporary, And executed by the user. E.g, A user can form a link shortly before an expected transaction occurs. And can be unlocked after the transaction is completed and after a predetermined short duration after the transaction.  In one embodiment in which the DTC and the DAD are dynamically linked (ie, linked by the user at a selected time), The links and selections of the desired LDTDP from the DAD can occur in any order.  In an embodiment, For secure communication between DTC and DAD, Security can be implemented by linking transaction cards and DADs or security can be implemented for data transfer between the transaction card and the DAD. In other embodiments, Security can be implemented for both link and data transfer.  In some embodiments, The DTC contains a battery or capacitor to provide power for memory storage. E.g, Embodiments of the card may include non-static type memory storage or some form of powered transceiver (such as a BluetoothTM transceiver). A battery can also be used to power the DTC to handle encryption and to change digital transaction files and/or digital signals represented by the DTC by implementing changes in the LDTDP containing logical digit transaction files and/or associated digital signals. LDTDP.  In some embodiments, The DAD contains a processor, a user interface, A device transceiver and device memory. In various embodiments, DAD can be a smart phone, Computer tablet, Laptop, Personal computer (PC), The chain device or other suitable device operable to allow a user to select an LDTDP and transmit data representative of the selected LDTDP. The DAD can also be customized for one of the purposes. In other embodiments, The DAD can be a wearable device (such as a smart watch) or can be enabled to operate in conjunction with the wearable device. In an embodiment in which the DAD has a user interface capable of displaying an image, The user interface can display a card association scheme logo with the same identity name or other text indicator. In the case of a credit card, Displaying a card association program logo on the DAD user interface should satisfy the card association solution provider that would otherwise prefer one of the physical display cards.  In an embodiment, Make a choice from the user interface, It can include a touch-activated screen selection from, for example, a smart phone. The touch-activated screen can be displayed by a list, Drop-down lists or other screen designs to operate or use the icons on the screen. In an alternate embodiment, The user interface can be a simple display with one of the buttons on, for example, a chain or a keychain. In the case of a DAD, a PC or a laptop, It can use a screen and keyboard to provide a user interface. however, Users generally prefer DAD as a portable device. On the DAD screen, An LDTDP may be represented graphically with one of the associated (logical) digital transaction files or may be symbolically represented using the name or nickname of the LDTDP. The name or nickname can be assigned by the user or a service provider.  E.g, The file can be a MasterCard credit card and the LDTDP associated with the MasterCard can be represented on the DAD screen by a MasterCard logo. Additionally or alternatively, The LDTDP can be represented by a combination of one of the illustrations and the number information. E.g, In the case where a MasterCard has one or more associated beacons (each beacon is contained in a separate LDTDP), The LDTDP of each MasterCard beacon can be represented on the DAD screen by at least a portion of the MasterCard logo and the respective beacon number.  In various embodiments, Digital trading devices can include POS/EFTPOS terminals, ATM, Internet-connected computers or personal computers and other such electronic devices. Digital trading devices can also include infrastructure. Such as a telephone call and a telephone service center enabled for mail order/telephone order (MOTO) type transactions.  In an embodiment, DTC and digital transaction devices can be interfaced to each other in a variety of ways. In some embodiments, Interfacing can be achieved by inserting the DTC into a digital transaction device. In other embodiments, The interface between the transaction card and the transaction device can be implemented by Near Field Communication (NFC). The card and/or device each have a transceiver and an antenna for communication. In other embodiments, The DTC can contain a magnetic strip. The digital transaction device includes a magnetic strip reader. In other embodiments, The DAD can include a transceiver configured to communicate with a digital transaction device. Make the transaction visible directly through the DAD. In other embodiments, The DTC is configured to plug into a POS/EFTPOS terminal or an ATM. And about the same size as a credit/debit card.  In a further embodiment, The DTC can have a magnetic strip. And the DAD can have a magnetic strip reader and/or writer.  In an embodiment, DTC can be adapted to express a default "zero" identity. The alternative information containing the LDTDP containing one of the logical digit transaction files that need to be uniquely identified may be a series of predetermined digits (eg, all zeros). In an example, In the case where a logical digit transaction file represented by an LDTDP is a credit card, The unique identification may be a credit card PAN or an associated digital beacon, And setting the DTC back to expressing a zero identity is performed by rewriting or replacing the PAN or associated digital beacon with all zero bits. This can occur by writing to the scratch memory and copying it into the secure record memory or by writing the DTPU itself into the secure record memory (secure element).  In an alternative embodiment, The DTC can be configured to store an associated logical digit transaction file and/or one of the associated digital signal symbols LDTDP for a selected period. This period may be predetermined by the issuer of DTC and/or the issuer of the digital signal (which may be one of the issuers of different DTCs). Alternatively, The storage period can be selected by the user. In other variations, Cycles can be dynamically selected, And may be selected by the user for each transaction or for a storage of a single LDTDP associated with one of the selected and one of the logical digit transaction files and/or associated digital signal(s) on the DTC. In other embodiments, The storage period of one of the associated logical digit transaction files and/or associated digital signal (LDTDP) on the DTC may be based on the selected LDTDP, The type of transaction or both.  In another embodiment, The DTPU of the DTC is configured to store/express an identity associated with only one logical digit transaction file and one of the associated digital signal(s) LDTDP at any particular time. According to this, To change the LDTDP in the DTPU, If an LDTDP is embodied in the DTC at the time, Then a user must rewrite or delete the LDTDP containing a logical digit transaction file and one of its associated (several) beacons previously stored/expressed. In another embodiment, The card can be configured to simultaneously store/express more than one LDTDP (containing a logical digit transaction file and associated (several) beacons for each file).  In another embodiment, The DTC and its DTPU can be configured to store and/or express one of the LDTDPs associated with a primary logical digit transaction file and its associated symbol(s). And one of the associated LDTDPs associated with the logical digit transaction file and its associated (several) beacons. In another embodiment, The DTC and its DTPU may be configured to store and/or express one of LDTDP and each of the secondary logical digit transaction files associated with a primary logical digit transaction file and its associated (several) transaction symbols ( Several) one or more LDTDPs associated with the beacon. In some embodiments, The LDTDP associated with the primary logical digit transaction file and its associated (several) beacons may be permanently stored on the DTC in its DTPU, One or more of the LDTDPs are associated with a secondary logical digit transaction file and associated (several) beacons on each DTC temporarily stored in its DTPU. In other embodiments, One or more LDTDPs associated with the secondary logical digit transaction file and the associated (several) beacons may be permanently stored and/or expressed on the DTC in their DTPU and stored on the DAD. One code reference.  In other embodiments, The DAD can contain an electronic wallet. It can be configured to operate with one or more of the LDTDPs containing the logical digit transaction file stored on the DAD and the associated (several) signal. This configuration can be used to fill the funds, The associated digital transaction file is a debit card or a credit card. In addition, The DAD may include allowing a user to view the use of the DTC (or by other means, The ability to perform transactions in real time, such as online trading. This may allow the user to monitor all LDTDP implementations associated with digital transaction files in a single screen or device having a single smart phone application that may include multiple DTCs linked to or linked to the DAD. All transactions. In addition, The user can be shown an associated digital beacon for a transaction. If the user detects or detects that one or more digital transaction files have been misused or fraudulently used, Then this can further allow the user to cancel, stop, Pause or otherwise properly process one or more digital transaction files. The device can also be adapted to allow the user to cancel on a beacon basis, stop, Pausing or otherwise properly processing one or more digital transaction files such that only certain symbols associated with a file are deactivated, However, the file can still be used with other associated beacons. If the user attempts to limit, for example, expenditures or other financial or non-financial transactions that occur with one or more logical digit transaction files, The user can also cancel, stop, Pause or otherwise properly process one or more logical digit transaction files. This can also be performed on the basis of a beacon.  In another embodiment, The DAD may be enabled to receive an alert from the user when using DTC for a transaction or a selected category or type of transaction. E.g, The DAD can alert the user that one of the digital transaction files (such as a passport) LDTDP has been used to identify at an airport. In addition, The alert can be implemented on the basis of a beacon-to-signal. In another example, The DAD can alert the user that a credit card has been used to purchase services that are not included in a list of authorized transaction types (such as a taxi ride). Such as the purchase of fuel and debris selected by the user.  In other embodiments, The DAD and/or DTC can be configured to allow a user to classify transactions into categories. The category may be predefined and/or defined by the user. Classification can be configured to allow users to monitor and/or limit transactions, Such as using a credit card within the category to pay. A class may be associated with only one LDTDP and associated (logical) digital transaction files. Or it may be associated with several LDTDPs and their associated (logical) digital transaction files. The beacon can also be used to classify transactions using an LDTDP and associated digital transaction files.  In another embodiment, The DAD can be configured to allow the user to transfer funds to another user having a DAD. Delivery may be limited to the same or similar LDTDP and associated (logical) digital transaction file types, And the number is limited. In a further embodiment, The DTC can be configured to transfer funds to another DTC (either owned by the user or owned by another user) or to another DAD (owned by the user or another user).  In addition, In another embodiment, Authorize and enable third parties (such as financial institutions, Policemen, customs, government, employer, spouse, Parents and other interested parties can cancel, stop, Pause or otherwise properly handle (including temporary suspension) one or more LDTDPs containing the logical digit transaction file in the device or the selected number of selected symbols associated with the file. If, for example, a user is gambling addiction, And prefer to have a third-party monitor and prevent access to credit cards, Debit card, Bank account or other kind of financial logic digital transaction file to prevent users from excessive gambling, This can be useful. In the case of an attempted fraudulent transaction and the cancellation/reissue of a logical digital transaction file, The user may have an alert to cancel a file and the availability of a file for collecting/downloading to a user's DAD and subsequently replacing one of the DTC transactions using one of the identities of adopting the newly issued (alternative) file.  In other embodiments, A DAD attached to one (logical) digital transaction file included in an LDTDP or a plurality of (logical) digital transaction files contained in the respective LDTDPs may be configured to store the member points, Information on documents relating to frequent flyers or other related transactions. The DAD may also be activated to update the member points during a transaction or after a transaction or at other times, Frequent flyers or other related transactions. E.g, The cost of using one of the DTC and DAD purchases can be reduced by using the member points during a transaction. If a user visits a particular store, Or near one of the stores, DAD can also be activated to add member points, Frequent flyers and other related transactions. In some embodiments, Member points, Documents relating to frequent flyer flights and other related transactions may be included in an LDTDP as further information associated with associated (logical) digital transaction files and/or associated beacons.  In another embodiment, If the DTC contains a primary logical digit transaction file containing, for example, a DTC permanently stored and/or expressed in the DTPU, The main logical digit transaction file can be a fake or forged logical digit transaction file. Data that is copied from DTC or DTPU (where only the primary logical digit transaction file is stored on DTC or DTPU) will be useless for any digital transaction. Alternatively, The main logical digit transaction file can be incomplete, A failure or a unique ID of one of the zeros (such as a zero ID) is indicated. E.g, In the case where the main digital transaction file is a credit card, The card's PAN may not be complete, Invalid or all zeros. In this embodiment, An LDTDP containing only secondary logical digit transaction files stored on the DTC and/or DTPU will be authentic and can be used for a digital transaction when presented as a digital transaction file via the DTPU on the DTC. In addition, LDTDP, which contains a secondary logical digit transaction file and its associated digital signal, can be stored or embodied as one of the DTC and/or expressed in the DTPU for a short period of time (eg Five minutes) to reduce the risk of stealing data representing digital trading documents and beacons. This configuration reduces the risk that an unauthorized user can imitate the associated digital transaction files and beacons. Alternatively, An LDTDP containing a primary logical digit transaction file stored on the DTC and/or expressed in the DTPU may include incomplete data. Display DTC/DTPU that is not available for digital transactions until a user downloads and saves the secondary data to the DTC/DTPU (along with the associated beacon data). Displays the main logical digit transaction file that is fully and available for digital transactions.  In another embodiment, A subset of each LDTDP or LDTDP stored on a DAD may have one of the PINs associated with (or included in) it. The PIN can be a static PIN. Or it can be a dynamically generated PIN. In other embodiments, The PIN can be displayed on the user interface of the DAD. The PIN can be accessed for display on the DAD screen by a secure method such as a finger swipe or other such secure method such as is typically implemented on a smart phone. In another embodiment, The DAD can be configured to allow a user to update a particular LDTDP or one of several LDTDP PINs. In an embodiment, The PIN can also be associated with a particular beacon of a file in an LDTDP. Make each message of the file have a different PIN.  In an embodiment, The method includes operating a DTC initiated using a digital transaction device to perform a digital transaction.  In some embodiments, The LDTDP is provided for use in association with a primary logical digit transaction file prior to issuing the DTC to a user. The beacon can be sent to the DAD over a secure network such that a transaction can be selected for a transaction with one of the associated LDTDPs for the logical digit transaction file (which has been stored on the DTC or in the DTPU at the time of issue). Alternatively, The beacon associated with the primary file can be loaded on the DTC or DTPU at the time of release. Among them, the choice is made by DAD at the time of the transaction. The secondary logical digit transaction file (as appropriate in the LDTDP) can be issued to the user via a secure network component to the DAD after the DTC is issued. And the associated digital signals of each secondary document may be issued with the associated secondary documents (also included in the respective LDTDP as appropriate).  In another embodiment, The beacon contained in one or more LDTDPs can be a fixed or extendable pool. It is used in a periodic manner, The next message is selected in sequence. Alternatively, The beacon can be randomly (or pseudo-randomly) selected from the pool. In a further embodiment, The signal has only one purpose. The pool in which the used or failed beacons are replaced when each of the cells in a pool has been used or expired. It is also possible to replenish the pool of beacons before each signal has been used or expired (for example, when there are ten unused or unavailable symbols remaining in the pool). Users can be alerted that they need to supplement the beacon. It should be understood that single-use beacons can improve the security of an associated digital transaction file (and its associated LDTDP) and transactions. In another embodiment, The user can choose when to replace the beacon in the beacon pool. In this embodiment, The user can request a new pool or one of its existing pools or beacons to extend from a beacon supplier. New beacons that are included in the respective LDTDP for storage in the LDTDP memory can be provided.  In a further embodiment, A primary user of a given digital transaction file can assign a beacon to a primary user of the file. E.g, A primary credit card holder can assign a (several) beacon from a pool of tokens to one of the credit card holders. This can be used as a control to limit the spending of sub-card credit card users. One of the types of quantity or expenditure.  In other embodiments, In the case of assigning a beacon to be used only in a particular transaction type, a third party (such as a signal issuer, Government agencies or other controllers used by the beacon have the right to allow the issuance of beacons only for the selected transaction type. In an example, The authority to control the issuance of a beacon may only allow the beacon to be issued for credit card use for one of the non-gambling expenses.  In some embodiments, The beacon is only generated by a third-party vendor that issues the beacon to the user (as appropriate in their respective LDTDP). In other embodiments, The beacon can also be issued by another third-party vendor. Alternatively, In an embodiment, The beacon can be locally generated by the user (eg, by DAD) and stored in the LDTDP storage memory contained in the LDTDP. The locally generated beacon can be securely copied to a third party to be matched during a transaction to thereby authorize the transaction. Generate a unique ID containing a beacon and associated files, Expiration date, The unique ID of the DAD, time, date, Location and various other random, Pseudo-random or non-random input one or more of the passwords. A password can also be used (for example) from one of the DTC public keys, A public key from one of the LDTDP public keys (for example, if it is a credit card LDTDP) and/or from a digital transaction device (such as a POS/EFTPOS terminal) is generated. Passwords can also be generated using public keys from other sources. Using one or more public keys to generate one of the passwords will contain one or more beacons and other IDs and data.  Although a person skilled in the art will appreciate various safety and convenience advantages after reading a specification having one or more configurations in accordance with embodiments of the present invention, But so far, There is no one of the different identities for adapting a DTPU (such as an EMVCo specific device) to reflect the identity of the DTPU compared to the originally installed, Efficient and / or safe methods and / or methods.  Although a modification to one of the basic operational firmware of a verification EMV device causes the device to lose its verification credentials, However, it is still possible to implement an embodiment of the invention using a firmware modification of one of the existing verification EMV devices. of course, Once the firmware has been modified, The device needs to be re-verified using the modified firmware before the device is ready for use.  In this embodiment, An existing EMV device firmware has been modified to enable the EMV device to enable the EMV device's secure memory to be modified by an external network transaction device (such as an ATM or EFTPOS device (or a network transaction device) A device)) receives and executes a set of add commands.  In other embodiments, The system (and associated method) allows for a point-to-point secure connection between the LDTDP storage memory and the secure recording memory (secure element) of the DTPU on the DTC. This direct communication channel allows data to be transferred directly from the storage memory to the secure recording memory.  In some embodiments, External control via peer-to-peer includes functionality that is generally not provided by many or any digital trading device. These features can include providing a DTC with a new identity. Making the DTC available as, for example, a credit card, Then after changing the identity, Can be used as an identification card. Other possible imitation features include, for example, setting spending limits on a DTC, Issue a DTC authorization request, Change a PIN (change digit 0000 to 1111, Or change the number of digits from four digits (eg 0000) to six digits (eg 101010)), Changing a public key (which is used to generate a password (transaction wrap) when used, for example, in a POS/EFTPOS terminal), And assign different identities for different locations or times. The type of function that can be used during external control via one of the peer-to-peer programs is not limited to the functions mentioned in this specification. And the present invention is intended to include all such features within the scope thereof.  It should be understood that no matter whether the data is transferred from the LDTDP store to the scratch memory and thus transferred to the secure record memory, Or the data is transferred directly from the LDTDP storage memory to the secure recording memory (secure element) via a point-to-point connection. DAD can be used by the operating system to facilitate data transfer. Including the creation of the required links, Connect and enter the required information (such as the name or identification of an LDTDP), And enter the authentication/authorization material (such as PIN). The DAD is operated by an aid from at least one program on the DTC.  The DTC may also include a processor or CPU for controlling operations external to the DTPU and/or for controlling read/write and other input/output operations of the DTPU with the DTPU system I/O. The DTC CPU can also handle security tasks and/or control GUIs outside the DTPU. In some embodiments, The DTC can include firmware that is operated by the CPU of the DTC. The firmware is operable to write data (eg, LDTDP data) to the scratch memory. So that when the DTPU is started, The DTPU copies the data to the secure record memory (secure element) in the DTPU. In an embodiment, The firmware on the DTC CPU is updatable, Among them DTC has a way to achieve firmware update. The update may include firmware that extends the functionality of the DTC and any programs and/or applications running thereon. The update allows for the correction or correction of existing firmware functions that have been identified as faulty or sub-optimized. Other firmware updates can be used to improve or extend the security or security of DTC. The ability to update firmware can be compared to (for example, an existing credit card or debit card using an EMV chip). There is no or limited ability to update the EMV firmware. current, The firmware is replaced with "update" by the time a credit card or debit card is expired. In the case where the DTC has a relatively long operational life (for example, 5 years or more), Updating the firmware can present one of the useful features of DTC.  In other embodiments, Real-time status information and other information from DTC is displayed on the user interface of the DAD to provide knowledge of whether a user has successfully used one of the DTC transactions. During a transaction (or alternatively, You can also use the interface to enter the information required for a transaction before a transaction begins. For example, enter a person identification number (PIN) or use other authentication methods (including fingerprint and retinal scan) for authorizing and/or authenticating a transaction. The PIN can be used for one transaction only or one PIN (OTP) for one selected time period.  In some embodiments, LDTDP can be stored on the DAD in the LDTDP storage memory. And at least one LDTDP can be selected via the DAD interface. Then copy to the DTC before a transaction or during a transaction, The DTC is enabled, via its DTPU, to assume the identity of the digital transaction file associated with the LDTDP transmitted to the DTC.  In an embodiment, Making a choice via the user interface implementation of the DAD, It can include a touch-activated screen selection from, for example, a smart phone. The touch-activated screen can be displayed by a list, Drop-down lists or other screen designs to operate or use the icons on the screen. The user interface can also be a simple display with one of the buttons on, for example, a chain or a keychain. In the case of a DAD, a PC or a laptop, It can use a screen and keyboard to provide a user interface. however, Users generally prefer DAD as a portable device. On the DAD screen, An LDTDP may be represented graphically with one of the associated (logical) digital transaction files or may be symbolically represented using the name or nickname of the LDTDP. The name or nickname can be assigned by the user or a service provider.  E.g, The file can be a MasterCard credit card. The LDTDP associated with the MasterCard is represented by a MasterCard logo on the DAD screen. Additionally or alternatively, The LDTDP can be represented by a combination of one of the illustrations and the number information. E.g, In the case where a MasterCard has one or more associated beacons (each beacon is contained in a separate LDTDP), The LDTDP of each MasterCard beacon can be represented on the DAD screen by at least a portion of the MasterCard logo and the respective beacon number.  In various embodiments, The DTC may also include a button or a similar device to initiate a link to the DAD. In some embodiments, The respective transceivers of DAD and DTC are suitable for BluetoothTM, Low Energy BluetoothTM, Wi-Fi, Near Field Communication (NFC), ANT+ or other types of contactless or wireless communication transceivers. In other embodiments, The transceiver may require contact between the DAD and the DTC to transfer data or establish a link between the DAD and the DTC.  In an embodiment, DTC can be adapted to express a default "zero" identity. The alternative information containing the LDTDP containing one of the logical digit transaction files that need to be uniquely identified may be a series of predetermined digits (eg, all zeros). In an example, In the case where the logical digit transaction file represented by LDTDP is a credit card, The unique identification may be a credit card PAN or an associated digital beacon, And setting the DTC back to expressing a zero identity is performed by rewriting or replacing the PAN or associated digital beacon with all zero bits. This can be done by writing to the scratch memory and copying it into the secure record memory or by writing the DTPU itself into the secure record memory (secure element).

在表1之第一實施例中，DTC (314)需要使用具有一經修改之NFC能力之一資料輔助器件(DAD) (諸如一智慧型電話)將資料傳達至經韌體修改之一EMV器件。如先前所描述，一經韌體修改之EMV器件具有包含可操作以將資料(例如LDTDP資料)寫入暫存記憶體之韌體之一外部DTC CPU，使得當啟動DTPU時，DTPU依一引起DTC採納一特定卡身份或助於以一些其他方式進行一數位交易的方式將資料複製到DTPU中之安全記錄記憶體(安全元件)。與各身份有關之資料可儲存於與DAD相關聯之記憶體中，其中DAD與DTC之間的通信可呈將資料下載及複製到安全元件以更新DTC之身份之命令形式。經韌體修改之DTC (314)受限於搭配一NFC啟用之DAD使用且使用具有經修改之非接觸式通信能力之一EMV器件以安全地接收自NFC啟用之DAD接收之資料，但具有以下優點：能夠針對一單一方案採納多個身份及低成本及起因於DTC (314)不包含一MCU、顯示器或翻捲鍵/輸入鍵之低失效傾向。 經韌體修改之DTC (316)亦需要使用一資料輔助器件(DAD) (諸如一智慧型電話)將資料傳達至如上文所描述之經韌體修改之一EMV器件。DTC (314)與DTC (316)之間的差異係DTC (316)包含可儲存有關多個身份之資料(及/或可與改變一些其他數位交易參數有關之資料)而非將資料儲存於DAD記憶體中之一MCU，且可接受具有無線連接性(NFC或藍芽)之一DAD與含有亦具有無線連接性(NFC或藍芽)之DTC之間的一安全會話。使用經韌體修改之DTC (316)之優點包含低成本及低失效傾向、不需要一NFC啟用之DAD (因為MCU可接受與(例如)僅藍芽啟用之一電話之通信)、針對一單一方案採納多個身份之能力及存在可助於自DAD安全傳送資料且不需要使用具有經修改之非接觸式通信能力之一EMV器件之一MCU。 表1中之DTC (318)亦需要使用一資料輔助器件(DAD) (諸如一智慧型電話)將資料傳達至可經由一非接觸式介面在具有無線連接性(NFC及/或藍芽)之一DAD與DTC之間建立一安全會話之一經韌體修改之EMV器件。DTC (318)包含可自NFC及藍芽啟用之DAD兩者接受無線通信之一MCU，且可藉此在大多數電話與含有MCU之DTC之間建立一安全會話。使用DTC (318)之優點包含低至中等成本、低至中等失效傾向，且不需要僅使用一NFC啟用之DAD，但鑑於DTC (318)包含一MCU及顯示器(320)，與DTC (314)及(316)相比，存在與DTC (318)之生產相關聯之一較高成本。 當使用表1中所描述之DTC (322)時，熟練的技術人士應瞭解並不一定需要但可使用一DAD (諸如一智慧型電話)以改變卡之身份或以一些其他方式助於進行一數位交易。在任何情況中，DAD係最初設置卡及在MCU中下載/儲存多個身份所必需，但在初始設置之後，卡自身可用以改變一卡之身份之操作參數或使用翻捲鍵/輸入鍵(326)以一些其他方式助於數位交易。在一初始設置期間，一MCU用以接受來自DAD之無線通信(藍芽及NFC兩者)，且經進一步程式化以接受來自一局部介面(其可(例如)包含翻捲鍵/輸入鍵(326))之命令且將鍵次轉換成命令。當翻捲鍵/輸入鍵(326)用以改變DTC (322)之身份或執行助於數位交易之一些其他任務時，傳輸由該局部介面授權，該局部介面授權該MCU選擇所儲存之資料且將該資料複製到安全元件。 DTC (322)具有以下優點：由於未傳輸卡細節，所以在更新或改變(即改變狀態/更新)期間，自同時儲存於卡上之諸多多個身份局部選擇一個身份而不會有發現卡細節之風險。進一步優點包含減少實現更新或改變(即改變狀態/更新)之時間、傳送以實現身份之一變化所需之最小量之資料及在無需使用一DAD之情況下改變DTC身份之能力。然而，DTC (322)具有一較高生產成本且歸因於其複雜性而可具有失效之一較高傾向。 參考本說明書中之任何先前技術不且不應被視為先前技術形成通用知識之部分之一確認或任何建議。 在本說明書及隨後之申請專利範圍中，除非內文另有要求，否則字語「包括」及變型(諸如「包括(comprises)」及「包括」(comprising))將理解為意謂包含一所述整體或步驟，或整體或步驟之群組，但不排除任何其他整體或步驟或整體或步驟之群組。 熟習相關技術領域者應瞭解可在不背離如廣泛描述之本發明之精神或範疇之情況下對本發明實行如實施例中所詳述之數種變動及/或修改。因此，在所有態樣中，本發明實施例被視為具繪示性且不具限制性。1 illustrates the main components of a device (100) in accordance with an embodiment of the present invention, Contains a digital trading card (DTC) (108), a data aid (DAD) and a digital transaction device (102) in the form of a smart phone (106), It is in this example a point of sale/electronic money transfer (POS/EFTPOS) terminal (102) at the point of sale. Such terminals (102) may be referred to herein as merchant terminals. And can be coupled according to a non-contact proximity communication capability according to ISO/IEC 14443 and DTC (108) between a terminal transceiver (not shown) and a DTC transceiver (114). The terminal (102) can also interface with a smart phone transceiver (116) and communicate with the smart phone transceiver (116) in accordance with the ISO/IEC 14443 communication protocol. The terminal (102) may also be engaged with the DTC (108) by physical contact. Or engage a magnetic strip on the DTC (108). In the embodiment shown, The terminal (102) needs to insert the DTC (108) into the terminal (102) for engagement by physical contact. In the embodiment of Figure 1, The smart phone (106) is wirelessly coupled to the DTC (108) by NFC. The DTC (108) is wirelessly coupled to the terminal (102) by communicating in accordance with ISO/IEC 14443, which is a subset of the NFC communication format. It should be appreciated that many types of smart devices or computing devices, such as smart phones (106), cannot interact with many types of POS/EFTPOS terminals (102) and automated teller machines (ATMs). In order to complete a transaction with one of these terminals, It is necessary to use a debit card or credit card. however, The debit or credit card will each have a single "identity" or an entity embodiment that includes only a single digit transaction file. E.g, current, A physical transaction card may have only one MasterCard or one Visa card identity. However, it is not possible to selectively and serially present the identity of both a MasterCard and a Visa card at different times. In the embodiment shown in Figure 1, DTPU (104) on DTC (108) is an EMV device (where EMV is Europay, One of MasterCard and Visa) or one of the EMV Co specifications, or one of the devices. It has been adapted to allow for the expression of several different identities. Such current DTPU or EMV devices may include read only memory (ROM), Random Access Memory (RAM) and/or Erasable Programmable Read-Only Memory (EEPROM). DTPU (104) can contain other types of memory, And the DTPU (104) may include a central processing unit (CPU) for controlling the operation of the DTPU (104). The DTPU CPU can cooperate with an encryption coprocessor. Its task of encrypting and decrypting data, This frees the DTPU CPU to perform other processing tasks. Communication between the DTPU (104) and the electrode (112) on the surface of the DTC (108) is accomplished by one of the DTPU (104) system inputs/outputs (system I/O). These and other components of a DTPU in accordance with an embodiment are described in more detail below with respect to Figures 4A and 4B. Figure 1 details a DTC (108), It can form a communication link with one of the smart phone transceivers (116) of the smart phone (106) via a DTC transceiver (114) to effect data transfer therebetween. In an embodiment of the invention (in which a user attempts to make a transaction with respect to a digital transaction file), The user can operate the user interface (110) of the smart phone (106) to select a particular digital transaction file and launch the digital file in the DTC (108). Once the DTC (108) takes the required identity and presents the characteristics of the digital transaction file selected by the user operating its smart phone (106), The DTC (108) can then be used to trade using the DTC (108). According to this, DTC (108) works with all the features of the selected digital trading file, Once the selected digital transaction file is launched as a file to be installed as a DTC, The document becomes the identity of DTC. In other words, Once a DTC becomes an entity embodiment of a file, The document is transformed into one of the DTC "identities." In particular, then, A DTC (108) having a selected identity for a digital transaction file selection may be used to digitize the transaction network according to one of the merchant terminals (102) including an automated teller machine (not shown) and/or one of the merchant terminals (102) as shown in FIG. The road has an infrastructure to trade to achieve a range of transactions. In the case of using a DTC (108) with a selected digit transaction file as its identity, The merchant terminal (102) (the DTC (108) communicates with the merchant terminal (102)) can be implemented by any of the existing communication methods between the DTC and the merchant terminal in FIG. The illustrated example includes physical contact between the DTC (108) and a merchant terminal (102) by the DTC (108) and the merchant terminal (102) (which typically includes incorporating DTC (108) One of the payment devices implements one of the transactions in which one of the external contact pads (112) is in physical contact with an electrode (not shown) resident in the merchant terminal (102). A further example of conducting a transaction between a DTC (108) and a merchant terminal (102) includes using the contactless proximity communication capability of the DTC (108) with the merchant terminal (102) and in which the DTC (108) In the case of a magnetic strip, The transaction is implemented using a magnetic strip reader of one of the terminal (102) and the DTC (108). The embodiment of Figure 1 is described above with respect to one embodiment of a firmware modified EMV device. Similarly, Figure 2A, The embodiment depicted in Figures 2B and 3A-3D can be implemented using one of the EMV devices involved in a firmware modification. Referring to Figure 2A, One of the DTCs in the form of a physical card (200) having one of the associated DAD user interfaces (202) is illustrated as stepping through one of the different identities of one of the DTCs (200). In the embodiment of Figure 2A, The DTC (200) does not have a specific identity when it begins to select an identity program. A user can operate a smart phone (204) and communicate with the DTC (200) in accordance with a contactless proximity communication protocol to select the identity required by the DTC (200). In the particular example of Figure 2A, The smart phone (204) has executed software to present the available card identity to a user who has selected a VISA card as a preferred identity for the DTC (200). In an embodiment, The user must provide a biometric measurement such as a fingerprint to operate the smart phone (204) to select one of the DTCs (200). Once the smart phone (204) communicates the user's choice of a VISA card as an identity that should be adopted by the DTC (200), The relevant selection and/or information is transmitted from the smart phone (204) to the DTC (200) and after receiving the selection and/or information of the LDTDP representing a VISA card, DTC adopts the identity of the VISA card (206). At a subsequent point in time, The user may prefer to change the identity of the DTC to a MasterCard and may operate the software on their smart phone to select a MasterCard identity in order to implement one of the DTC identity changes. Referring to Figure 2A, The smart phone (204) has been operated to select a MasterCard identity and after communicating the relevant selection and/or LDTDP data to the DTC (200), DTC adopts a MasterCard identity and after that, The DTC (200) will operate as a consumer MasterCard (208). finally, Once a consumer has completed trading with their DTC, The consumer may prefer to display the DTC-zero identity and refer to FIG. 2A. The smart phone (204) is operative to identify consumer preferences by locking a zero identity to the DTC to lock its DTC. After conveying the user’s request, The smart phone (204) causes the DTC (200) to adopt a zero identity (200). In the embodiment of Figure 2A, DTC (200, 206, 208) is a modified DTPU of the execution software, The software has been modified to allow/allow the DTC to adopt a different identity containing a zero identity based on the command transmitted to the DTC by the DAD (204). The communication between the DAD and the DTC can be implemented by a DAD processor that communicates with a DTC external processor via respective transceivers (shown as smart telephone transceiver (116) and DTC transceiver 114, respectively, in FIG. 1) and has The DTC external processor that receives the command from the DAD cooperatively communicates with the EMV device to cause the EMV device to adopt a desired identity based on the command received by the DTC from the DAD. Referring to Figure 2B, The same steps depicted in Figure 2A are depicted in Figure 2B with respect to changes in the identity of a digital transaction card. The reader should note that the DTC in Figure 2B contains a DTC with a user interface that has a zero identity (210). It is described in more detail below with particular reference to Figure 3D. In the case of the embodiment depicted in Figure 2B, The request to change the identity of the DTC (210) is implemented by the DTC user interface compared to the DAD user interface (refer to Figure 2A). For the DTC (200) in Figure 2A, The zero identity DTC (210) in Figure 2B is converted to a VISA card (206) by a user operating a user interface on the zero identity DTC (210). The Zero Identity DTC (210) contains the scroll key/input key and one of the displays on the DTC. When attempting to change an identity from a VISA card (206) to a MasterCard (208), The user operates the DTC scroll button, It is observed that the display sequentially displays the available identities when the scroll button is repeatedly pressed. Once a MasterCard identity is displayed, The user can press the enter key and change the DTC identity accordingly. The DTC (208) can be changed to a zero identity by the user operating the DTC user interface to display and select a zero identity and achieve the same change. Referring to Figure 3A, The figure shows a DTC in the form of a wearable device (300) together with a DAD in the form of a smart phone (302) and a merchant terminal (304). In this particular embodiment, The wearable device (300) is a watch, It also provides functionality to display the current time and any other functionality available to the wearable device (300). Wearable devices are increasingly being adopted by consumers to combine the functions of many individual projects. Thereby reducing the complexity of trading, Because once a DTC function is incorporated into a wearable device (300), It is no longer necessary to carry a separate DTC. Wearing the wearable device (300) enables the user to trade the device that the user typically wears. In the example of Figure 3A, The wearable device (300) is depicted in communication with the smart phone (302) and a merchant terminal (304) via contactless proximity communication. of course, Although all three devices are drawn very close, However, the reader should understand that the wearable device (300) does not have to be in contactless proximity communication with a smart phone (302) and a merchant terminal (304) at the same time and communication between the respective devices can occur separately at different times. Referring to Figure 3B, The figure details an alternative wearable device in the form of a ring (306) in the form of a DAD non-contact proximity communication in the form of a smart phone (302) and a merchant terminal (304). once again, In the illustration in Figure 3B, Smart phone (302), Communication between the wearable device in the form of a ring (306) and a merchant terminal (304) all takes place using contactless proximity communication. Referring to Figure 3C, Another embodiment is illustrated in the drawings. There is provided a DTC in the form of a smart phone box (308). In this particular embodiment, One of the DADs in the form of a smart phone (302) communicates with one of the DTCs in the form of a smart phone box (308). It then communicates with a merchant terminal (304). All of the communications depicted in FIG. 3C occur in accordance with contactless proximity communication (which is in accordance with ISO/C 14443) and in this particular embodiment, Instead of a wearable device, The DTC is in the form of another convenient device (ie a smart phone box (308)). Because users regularly buy their smart phone boxes to protect their smart phones from damage. of course, In the embodiment of Figure 3C, If a consumer uses a DTC in the form of a smart phone box (308), And attaching the box (308) to the smart phone (302), The DAD in the form of a smart phone (302) and the DTC in the form of a smart phone box (308) are then occupied by the consumer. The reader should be aware that DTC can be configured in a number of different ways. And there is a DTC that has minimal (or limited) functionality/connectivity but is less expensive to produce and less prone to failure, has maximum functionality and includes auxiliary user interaction and is therefore considered to be "easy to use" but therefore One of the possible DTC embodiments that are more expensive to produce and are more likely to fail one of the DTCs. Figure 3D provides an illustration of four DTCs, The DTCs have a credit card outline. Thereby each comprises an EMV device (310) and an optional print identification (312), The name of the card owner in the embodiment shown, And its functional/connectivity characteristics represent significant differences in user experience relative to digital transactions. E.g, The topmost DTC (314) depicted in Figure 3D represents one of the cards with minimal functionality/connectivity and includes one of the firmware modified EMV devices (310) and is between the EMV device and a DAD (302). NFC wireless connectivity to change the identity of DTC (314), But exclude an external DTC processor (called an MCU), Bluetooth connectivity and any form of display or roll-up/enter key. In a particular embodiment, The DTC (314) configured with minimal functionality/connectivity can be issued to a user such that the EMV device (310) is preloaded with multiple identities. More generally, After delivering the DTC (314) to the user, The DAD (302) can be used to transfer one of a plurality of identities to the EMV device (310) or to transmit several identities for simultaneous storage by the EMV device (310). The second DTC (316) depicted in the figure also represents one of the cards with minimal functionality/connectivity. It includes an EMV device (310) that is modified by firmware and that achieves wireless connectivity between the EMV device and a DAD (302), such as Bluetooth and/or NFC, to change the identity of the DTC (316). The DTC (316) also contains an MCU (not shown in Figure 3D). A DTC (316) configured to have a relatively minimal functionality/connectivity but including an MCU can be issued to a user. The EMV device (310) accesses data for performing multiple identities. Alternatively, After delivering the DTC (316) to the user, The DAD (302) can be used to transfer one of a plurality of identities to the EMV device (310) or to transmit several identities for simultaneous storage by the EMV device (310). The third DTC (318) depicted in Figure 3D represents a medium function/connectivity card, It includes an EMV device (310) that is modified by firmware and that achieves wireless connectivity between the EMV device (310) and a DAD (302), such as Bluetooth and/or NFC, to change the identity of the DTC (318). DTC (318) also includes a display (320), It may be used to display information (including but not limited to the selected identity of the load (or previously stored) on the card, a unique ID or abbreviation of the selected identity, One of the documents expires, a temporary PIN number, One of the PAN number or part thereof and/or one of the card owners' names simplifies the form of the 4-digit number interface. A DTC (318) configured to have a medium range of functionality/connectivity can be issued to a user such that the EMV device (310) accesses information about multiple identities. Alternatively, After delivering the DTC (318) to the user, The DAD (302) can be used to transfer one of a plurality of identities to the EMV device (310) or to transmit several identities for simultaneous storage by the EMV device (310). The fourth DTC (322) depicted in Figure 3D represents one of the cards with a high level of functionality/connectivity and includes a firmware modification and achieves NFC or blue between the EMV device (310) and a DAD (302). The bud is wirelessly connected and transmits a plurality of identities to one of the EMV devices (310) after the card is delivered (310). The DTC (322) also includes one of the integrated display (324) and the scroll key/input key (326) for achieving user input (including input to implement selection of a storage identity). Skilled technical people should understand that Even when there is no DAD (302) such as a user's smart phone (for example, if the user does not carry a DAD or the battery is dead), Including a user interface on the card enables the use of the DTC (322). 4A and 4B show components of a DTPU (400) and steps of an exemplary method for operating the device, in accordance with an embodiment, The device contains a DTPU (400), It is modified by firmware to allow for the update of different selected identity or transaction files. Similar to a standard EMV device, The DTPU (400) of the embodiment shown in Figures 4A and 4B is located in a plastic credit card body that uses electrodes (402) for external communication. however, The DTPU (400) can also use a wireless transceiver for external communication. The DTPU (400) has several components shown in a top plan view for ease of use in the panel (404) of Figures 4A and 4B. The component contains a ROM (406), RAM (408), A CPU (410) and an encryption coprocessor (412) and an EEPROM (414/416). The DTPU (400) also contains a system I/O (418), It is in communication with an electrode (402) for connection to an external device such as a POS or EFTPOS terminal. In one embodiment in which the operational firmware of an EMV device is modified, The DTPU (400) EEPROM can be divided into two memory regions (414) and (416). In some embodiments, Partitioning can be done by partitioning (or virtual partitioning) or by using a suitable file structure or by using a suitable directory structure. In this exemplary embodiment, A portion of the EEPROM is used as a temporary memory (scratch area) (414). During operation, The scratch memory (414) has at least one logical digit transaction file package (LDTDP) written from the LDTDP storage memory to the scratch memory. Another part of the EEPROM is used as a secure recording memory (secure element) (416). During operation, At least one LDTDP is taken out of the temporary storage memory (414), And written into the secure element (416), When the DTPU is activated to read the secure element (416), The LDTDP is accessed by the DTPU CPU (410). When the DTPU CPU (410) accesses the LDTDP, DTPU (400) can present the identity represented by LDTDP, A digital transaction card (DTC) associated with the DTPU (400) is made available for use with the identity transaction. In other embodiments, Instead of using a single EEPROM divided into two memory regions (temporary memory region and secure recording memory region), Two separate memory chips are available. Each contains a temporary memory and one of the secure recording memories. These memory devices (or wafers) can be configured in the DTPU (400) to have no direct link for added security. In particular, secure record memory that should be directly accessible only by certain specified components of the DTPU (400), such as the DTPU CPU (410). According to an embodiment of the invention, In DTC, An external DTC CPU (420) other than or in addition to the DTPU CPU (410) can be located. The control of the DTPU (400) can be controlled by the DTPU CPU (410). The external DTC CPU (420) and its associated firmware may allow data (including LDTDP) (422) (as shown by dashed line (424)) to be communicated to the DTPU (400) by the system I/O (418). The external DTC CPU (420) and firmware are operable to instruct the DTPU CPU (410) to copy material (e.g., one or more LDTDPs) to the scratch memory (416). The DTC CPU (420) is also operative to instruct the DTPU CPU (410) to transfer the data in the scratch memory (416) to the secure record memory (414). The data (422) containing the LDTDP can be stored in the smart phone or in the LDTDP storage memory on the DTC itself in one of the memories in the DTPU (400). The configuration depicted in Figures 4A and 4B allows the LDTDP to be stored in the LDTDP storage memory and copied from the LDTDP storage memory to the temporary storage memory (416), As shown by the dashed line (426). Copying from the LDTDP storage memory to the scratch memory (416) can be controlled by an external DTC CPU (420). It in turn controls the operation of the DTPU CPU (410). The operation of the external DTC CPU (420) can be controlled by a DAD (such as a smart phone). It is operated by a user via a DAD user interface. In another step of an example operation, Data (422) containing one or more LDTDPs is loaded from the scratch memory (416) into the secure record memory (414) of the DTPU (400). Copying the data (422) from the temporary memory (416) into the secure record memory (414) is indicated by the dashed line (428) in Figure 4B. One of the arrows indicates that the material (422) is copied into the secure record memory (414). In an embodiment, Use strong encryption to establish a link between a DAD (such as a smart phone) and a DTC to identify and transfer data between the DAD and the DTC. For each pair of smart phones with one DTC, This link can be unique. The external DTC processor (or DTC CPU) (420) typically only activates after it has securely identified itself to the linked smart phone. The DTC processor (420) on the DTC controls the reading and re-reading of the DTPU (400), And update the DTPU (400 to express the new identity. In some embodiments, The external DTC CPU (420) can be activated by pressing an on/off switch (forming the scroll key/input key on the DTC). In other embodiments, The DTC CPU (420) is activated (and powered) by the DAD. In an embodiment, After the DAD (smart phone) and DTC secure link, The DAD is uploaded by the external DTC CPU (420) to a specified secure data area (eg, a temporary memory (416)) after satisfying certain criteria and passing various compliance checks, such as an LDTDP. And then a command is transmitted to the DTPU processor to complete the following: · Check if the specified storage area (temporary memory (416)) contains data in a specified format (a LDTDP); · If the data (422) meets a specific standard and passes various checks, Then the DTPU processor (410) copies or moves the data to a designated area (secure record memory (414)) in the DTPU (400); · Next, The processor (410) sends a command to the DTPU (400) to read the data (422) in the designated area (secure record memory (414)) and act according to the data (422) contained in the area (414). , It may be stated that the DTPU (400) expresses the identity of a particular file represented in the LDTDP in the secure record memory (414); · Next, The DTPU processor (410) can be instructed to search for a particular header and other material identification code within one of the parameters prior to acting on the data. It is well understood by the reader that the DTPU (400) can be an EMV device that has been constructed to have an increased storage area. It is specifically instructed to inspect and/or monitor a secure storage area (this may be referred to as a secure recording memory or security element). The EMV device can also accept commands from, for example, an external processor (420) resident in the DTC. In an embodiment, The external DTC processor (420) only transfers the data to the (several) memory area of the DTPU (400). And once inside this memory area, The DTPU processor (410) is responsible for further replication, Read, Write and/or process data. however, In other embodiments, The data can be kept under the control of an external DTC processor (420). Wherein the external DTC processor (420) can issue commands to the DTPU CPU (410) for operation to copy, Read, Write and/or process data. In another embodiment, The DTPU processor (410) verifies the data before transmitting the data to a secure location (secure record memory). In addition, The DTPU processor (410) instructs the EMV device to load data or update itself after completing the inspection and verification of the data. In various embodiments, All memory storage (LDTDP storage memory, The scratch memory and secure recording memory can be located on the EMV device. Alternatively, Some memory storage can be located on a wafer (such as one of the microcontroller units (MCUs) outside the DTPU) but linked to the EMV device. Memory storage can be based on files. Used in a directory file (DF), A data file (electronic file) with a directory or master file (MF). The firmware on the external DTC processor can be a local firmware (using machine language). But according to an interpreter-based operating system (including Java card, Demodulation performed by MultOS or BasicCard). Because both the external DTC CPU (420) and the DTPU CPU (410) provide commands, So the external DTC CPU (420) will benefit from having the same firmware as the DTPU CPU (410), This allows commands to be provided in the same format. According to this, If and when updating the firmware of the external DTC CPU (420), The beneficial system also updates the firmware of the DTPU CPU (410). In some embodiments, The firmware of both the external DTC CPU (420) and the DTPU CPU (410) can be stored in the same location accessible by the two CPUs. Therefore, only one firmware repository needs to be updated. however, A single source of firmware can have a security implied. In order to make the DTPU work with the data (422), It is necessary to associate a specific code with an LDTDP. The code can be a standard code. And to control the operation of the DTPU (EMV chip) to identify the LDTDP as a set of codes or data within a standard limited command set. Alternatively, For each link DTC and DAD (eg smart phone), The code can be unique. In addition, A code can be changed for a given DTC/DAD pair on different days or at different times. We should be aware that the code changes can be provided for additional security of the transaction. In some embodiments, The code associated with LDTDP is separated from LDTDP. In other embodiments, The LDTDP can be configured to include the code in its package (referred to as a header). Figure 5A depicts a DTC subdivided into one of four separate layers, Command (500), Agreement (502), A message transaction layer (504) and an entity (electricity) layer (506). Also shown in FIG. 5A is a mobile device (508) that communicates data and commands to the DTC via a wireless protocol, such as NFC or Bluetooth. The commands and data are received by a transceiver (509). The transceiver (509) converts the wireless signals transmitted from the mobile device (508) into signals for reception by a communication module (510) embodied in a dedicated integrated circuit (ASIC). The communication module (510) then transmits the commands and data decoded from the transmission of the mobile device (508) to the MCU (512) and interprets the commands and data. In an embodiment, The proprietary commands transmitted by the transceiver (509) from the mobile device (508) to the DTC and ultimately to the MCU (512) are encrypted to protect the data and security of the DTC. According to the agreement layer (502), The MCU (512) communicates with the EMV device (514) in accordance with established protocols. In the embodiment of Figure 5A, The MCU (512) sends a set of commands to the EMV device (514) as needed, depending on the functionality requested by the mobile device (508), One of the groups of commands that are identical to an EMV device or that can be directly received from an external network transaction device (such as an ATM or EFTPOS device), which enables modification of one of the EMV devices (508), is increased. The form of the order. An Application Agreement Data Unit (APDU) is used to communicate with the EMV device (514) and the APDU is also defined in the set of add commands. In order to change the identity of the DTC card, The MCU (512) uses this set of add commands to communicate with the EMV device (514). Reference message transaction layer (504), This layer conveys information between a merchant terminal and an EMV device (514) or between an MCU (512) and an EMV device (514). The message used for this communication is APDU. There are two main types of APDUs. which is, Command APDU and respond to APDU. Actually, The APDU command is a communication protocol used to communicate with an EMV device (514). The message transaction layer (504) also depicts an external contact (516) of an EMV device (514). In addition, The message transaction layer (504) also depicts an arbitration device (518), It arbitrates communication between the MCU (195) and the EMV device (514) or alternatively, Communication occurs between the EMV contact (516) and the EMV device (514). As familiar to the reader, Communication between the EMV device contacts (516) and the EMV device (514) will occur when the DTC is used in an "dip mode" in a merchant terminal. The DTC is inserted into the merchant terminal and the contacts within the merchant terminal are directly coupled to the EMV contacts (516). In this example, Communication between the EMV contact (516) and the EMV device (514) must be accomplished without any interference in the communication attempted by another device, such as the MCU (512). however, In an example where communication between the MCU (512) and the EMV device (514) is required, The arbitration device (518) effectively disconnects the communication path between the EMV contact (516) and the EMV device (514) such that the communication can be in the MCU without interference from any device in contact with the EMV contact (516). (512) is implemented between the EMV device (514). As depicted in Figure 5A, Communication between the MCU (512) and the EMV contact (516) and the EMV device (514) is implemented by the APDU in the embodiment of Figure 5A. An APDU contains a mandatory four-byte header that defines the command and one of the zero to sixty-four kb data. A response APDU may be sent back to a merchant terminal or MCU (512) by the EMV device (514) and contains zero to 64 kilobyte data and two mandatory status bytes. Reference entity (electrical) layer (506), Depicting various additional components of the DTC, A dynamic magnetic strip module (520) is included, a display driver (522) and a corresponding display screen (524), A battery (526) and a crystal (528) providing one of the oscillators for determining the clock signal of all of the electronics on the DTC. Also depicted in Figure 5A is an illustration of the rear side of a DTC (530) containing one of the dynamic magnetic strips (532). Additional components are also depicted in the physical (electrical) layer (506). Includes an EMV device antenna (534), An NFC antenna (536) connected to one of the communication modules (510) and a Bluetooth antenna (538) also connected to one of the communication modules (510). Referring to Figure 5B, The abstraction layer depicted in Figure 5B is the same as that depicted in Figure 5A. Although the embodiment illustrated in FIG. 5B includes an embodiment of a user operation to implement a DTC roll-up key/input key (540) that includes the ability to change the DTC identity. In an embodiment, The DTC roll-up/input button (540) includes a touch-sensitive button that can be activated by touching only one of the buttons or pads on the DTC and can be used to scroll through various options including the available DTC identity. It can also be used to power on or off the DTC. Referring to Figure 5C, To more clearly illustrate the individual components of the physical (electric) layer, An enlarged version of one of the physical (electrical) layers (506) of Figures 5A and 5B is detailed. Figure 6A details the flow of data between devices resulting from the release of a command from a user's mobile device and the receipt of data from the DTC to the user's mobile device. In particular, 6A provides an illustration of one of the DTCs in accordance with an embodiment of the present invention, In fact, the illustration of Figure 6C adds a repetition of a mobile device (600). Covered by the diagram is a series of arrow segments depicting the flow of data (when the data is sent to and from the mobile device (600) and the individual components contained in the DTC), As depicted in Figure 6C. Referring to Figure 6A, In the case where a user issues a command from their mobile device (600) to the DTC, Commands and/or materials associated with the commands are communicated along data stream 602 and in the example depicted in FIG. 6A, Wirelessly communicated to DTC by NFC or Bluetooth wireless capabilities. The DTC receives commands issued by the mobile device (600) and indicated by the data stream (602) and receives commands and/or data as depicted by the data stream (604) at the communication module (606). The communication module (606) that has converted the received command and/or data (604) passes a signal along the data stream path 610 to the MCU (608) for processing by the MCU (608). If the data received by the MCU (608) depicted by the data stream (610) represents a command that requires the MCU (608) to communicate with the EMV device (612), The MCU (608) then transmits a signal to the arbitration device (614) (depicted by data stream (616)) to initiate the arbitration device (614) to isolate the normal connection between the EMV device contacts and the EMV device (612). In addition, In addition to isolating the normal connection between the EMV device contacts and the EMV device (612), The arbitration device (614) initiates a connection between the MCU (608) and the EMV device (612). Once the arbitration device has been activated (614) to achieve communication between the MCU (608) and the EMV device (612), The MCU (608) communicates the data as depicted by the data stream (618) to the EMV device (612). In the case where the command is issued by the mobile device (600) to effect a change in the identity of the DTC, After receiving and changing the identity of the EMV device (612), the EMV device (612) According to the information provided as depicted by the data stream (618), The EMV device (612) provides a return signal as depicted by the data stream (620) to the MCU (608), Confirm that the identity of the EMV device (612) has been changed. Once the required communication between the EMV device (612) and the MCU (608) has been completed, The arbitration device (614) can recover communication between the EMV device (612) and the EMV device contacts. at this time, The MCU (608) transmits a further signal to the arbitration device (614) to resume normal communication between the EMV device contacts and the EMV device (612) while isolating the communication path between the MCU (608) and the EMV device (612). . This signal is depicted in Figure 6A as a data stream (622). At this stage, The MCU (608) generates a signal and transmits it to the communication module (606) as depicted by the data stream (624). The signal is a signal that confirms the identity of the EMV device (612) based on the instruction initiated at the user's mobile device (600). The communication module (606) converts the signal for wireless transmission to the mobile device (600) into a wireless signal depicted as a data stream (626) after receiving the signal (624). The user's mobile device (600) receives the wireless transmission signal (626) and after converting the wireless signal, The user's mobile device (600) internally processes the signal (626) and provides a visual indication to the user of the user interface of the mobile device (600), A change in the identity of the requested EMV device (612) is confirmed and the DTC will now operate according to the identity of the card requested by the user. Figure 6A further depicts each of the data streams (628) and (630) from the MCU (608) to the dynamic magnetic strip (632) and display (634), respectively, such that the parameters of the dynamic magnetic strip are consistent with the parameters defining the user's selected identity. And display a selected name (such as, for example, one of the selected identities (such as VISA, MasterCard, AMEX, etc.) or one of the selected users defines the name (eg personal account card, Business account card, etc.)) related information. Referring to Figure 6B, A data stream is illustrated for FIG. 6A, Although in the embodiment depicted in Figure 6B, The request to select a particular DTC identity is implemented by the operation of the DTC scroll key/input key (636). The signal from the scroll key/input key (636) to the MCU (608) is depicted as a data stream (638). of course, As recognized by familiar readers, One particular advantage of the embodiment depicted in Figure 6B (where the DTC includes a DTC roll-up/input key (636) for effecting a change in DTC identity), It is not necessary to have a wireless communication capability (such as NFC or Bluetooth) on one of the smart phones (600) and smart phones (600) or DTCs. Referring to Figures 7A through 7F, Various embodiments are described to implement an operative communication between an EMV device (700) and an MCU (702) and an EMV device (700). In particular, Figures 7A through 7F contain additional details as compared to the previous figures, Details and connections between the external contact pads (704) and the EMV device (700) that are provided to enable communication between the transaction device (such as an EPTPOS terminal and an ATM terminal) and the external contact pads (704) and current inclusion This is related to the (several) connections between the internal contacts (706) in most, if not all, digital transaction cards containing an EMV device. According to this, Providing an external contact strip (704) and an internal contact strip (706) is one of the manufacturing artifacts of a digital transaction card containing an EMV device (700). In an embodiment of the invention comprising both an outer contact strip (704) and an inner contact strip (706), There is a route between the outer contact strip (704) and the inner contact strip (706) in one configuration except for a one-to-one direct connection between the outer contact strip (704) and the corresponding electrode of the inner contact strip (706). The opportunity to connect electrically. Specific reference to Figure 7A, Graphically depicting an embodiment, The electrical connection to the digital transaction device accessible by the external contact pad (704) is coupled to an arbitration device (707) and depending on the state of the arbitration device (707). The individual electrodes of the outer contact pads (704) can be electrically connected to the opposite electrodes of their inner contact pads (706) by an arbitration device (707). To provide a direct connection between the outer contact piece (704) and the opposite electrode of the inner contact piece (706), The arbitration device (707) operates to identify the connection as GND (708), Vcc (710), RST (712), CLK (714), The electrodes of I/O (716) and blank terminal (718) are such that all of the electrodes are respectively connected to the opposite electrodes of their inner contact pads (706) such that the electrodes of external contact pads (704) are respectively connected to GND (720), Vcc (722), RST (724), CLK (726), I/O (728) and blank terminal (730). Correspondingly, When in an appropriate state, The arbitration device (707) will operate to directly connect the individual electrodes of the outer contact pads (704) to the opposite terminals of their inner contact pads (706), It is in turn connected to the EMV device (700) to the appropriate connection point to enable the EMV device (700) to operate with the digital transaction device. In this configuration, The EMV device (700) will typically be coupled to an electrical signal (ie, GND (708), which is operated with a digital transaction device interfaced with an individual electrode of the external contact pad (704) and applied to any of the external contact pad (704) electrodes. Vcc (710), RST (712), CLK (714), I/O (716) and blank terminal (718)) pass the external contact pad (704) electrode through the arbitration device (707) and directly to the opposite electrode of the internal contact pad (706) (ie GND (720), Vcc (722), RST (724), CLK (726), I/O (728) and blank terminal (730)). however, In the case where communication between an MCU (702) and an EMV device (700) is required, The arbitration device (707) adopts an alternate state and connects the data and control signal lines of the MCU (702) to the individual electrodes of the internal contact pads (706) through the arbitration device (707). It is in turn connected to the appropriate I/O and control lines of the EMV device (700). Correspondingly, The arbitration device (707) in the graphically represented embodiment of Figure 7A acts as a set of monopoles for connecting the MCU (702) to the electrodes of the internal contact pads (706) and thus to the EMV device (700). Double throw switch, Or alternatively, When switching to its alternate mode, The arbitration device (707) disconnects any connection between the MCU (702) and the EMV device (700) and connects the external contact strip (704) electrode to the opposite electrode of the inner contact strip (706), It is in turn connected to the appropriate connector of the EMV device (700). Operable, When implementing the embodiment depicted in Figure 7A, Any communication between the MCU (702) and the EMV device (700) will require an electrode to be applied to the external contact pads (704) when the user of the digital transaction card does not need or attempt to trade with one of the digital transaction devices. . of course, Preventing or terminating a digital transaction if the arbitration device (707) is switched to an alternate state causes the connection between the external contact pad (704) electrode and the associated connection point of the EMV device (700) to no longer exist, The digital transaction will then terminate and will not be executed. Although this result can be accepted by a financial institution (the user attempts to conduct a digital transaction with the financial institution), However, it is not possible for the user to consider this acceptable interrupt and the arbitration device (707) preferably is not capable of interrupting communication with a digital transaction device (which is in communication with the EMV device (700)). In addition, Any potential disruption of the "transaction path" or data flow in the device may result in the need for a device or component or the need for revalidation. As previously described, A program for re-authentication of a component operating in an electronic digital transaction network can be time consuming and expensive and preferably avoids the program. Referring to Figure 7B, Graphically representing an alternative to the embodiment depicted in Figure 7B, The arbitration device (707) only controls the connection of the MCU (702) to the associated electrode of the internal contact strip (706) and thus the associated signal connection point of the EMV device (700). In this particular embodiment, The outer contact strip (704) electrode remains attached directly to the opposite electrode of its inner contact strip (706) and remains connected regardless of the state of the arbitration device (707). In this particular embodiment, The arbitration device (707) acts as a series of single-pole, single-shot switches. Because it is only operable to connect a single line from the MCU (702) to the electrodes of the inner contact pads (706) and thus to the signal connection points of the EMV device (700). of course, In the case of the embodiment of Figure 7B, It is necessary to consider the possibility of applying an electrical signal to the electrodes of the outer contact pads (704) during the period in which the arbitration device (707) has connected the MCU (702) to the EMV device (700). Those skilled in the art will appreciate that various hardware configurations may be employed to ensure that electrical signals that could damage a device are prevented from reaching the device. In an embodiment, The use of appropriate hardware components to transfer the inappropriate signal energy applied to the electrodes of the external contact pads prevents their transmission to the EMV device (700) and the arbitration device (707) or MCU (702). One additional consideration to consider is the connection of a device to an external contact pad (704). It is therefore possible to monitor and/or interfere with communication between the MCU (702) and the EMV device (700) and in this example, It is desirable to encrypt (732) any communication between the MCU (702) and the EMV device (700) in accordance with the embodiment of the configuration configuration depicted in Figure 7A to obstruct any attempt to pass the electrode access from the external contact pad (704). Signals between the MCU (702) and the EMV device (700) monitor or interfere with such communications. Referring to Figure 7C, An alternative configuration for the electrical connection of the MCU (702) and the EMV device (700) is depicted in the figure. The arbitration device (707) connects and/or disconnects the selective contacts of the outer contact pads (704) and the inner contact pads (706). As depicted in Figure 7C, Electrodes GND (708) and RST (712) are coupled to arbitration device (707) and arbitration device (707) is operative to connect the electrodes of external contact pads (704) with their opposite electrodes in internal contact pads (706) (ie, GND (720) and RST (724)). Correspondingly, The electrode of the arbitration device (707) not connected to the external contact piece (704) includes the electrode Vcc (710), CLK (712) and I/O (716). These particular electrodes are directly connected to the opposite electrode in their internal contact pads (706) (ie Vcc (722), CLK (726) and I/O (728)) and remain connected at all times. Similarly, In the embodiment of Figure 7C, Only the selected electrical connection point of the MCU (702) is connected to the arbitration device (707) to switchably connect to the electrodes of the inner contact pads (706). According to the embodiment depicted in Figure 7C, The MCU (702) has various electrodes (ie, GND (708), with external contact pads (704), Vcc (710, 722) and CLK (714, 726)) permanent connection. Similarly, The I/O electrodes of the outer contact pads (704) and the inner contact pads (706) are permanently connected to each other and permanently connected to the serial I/O communication connection points of the MCU (702). The embodiment depicted in Figure 7C has the advantage of reducing the attempt to monitor communication between the MCU (702) and the EMV device (700) by accessing the electrodes of the external contact pads (704) but suffers from some portion of the transaction flow. The switching device (i.e., arbitration device (707)) is interrupted and thus may require the re-validation of the device embodied in the DTC. Referring to Figure 7D, A further alternative embodiment is depicted in the drawings. The embodiment includes an external Vcc detection circuit (738) that functions to detect the presence of power coupled to the external contact pad electrode Vcc (710), It will indicate the connection of the external contact pads to one of the digital trading devices used to perform a digital transaction. In this embodiment, The external contact pad electrode Vcc (710) is coupled to the MCU (702) via an external Vcc detection circuit such that the MCU (702) can receive a signal confirming that power has been applied to the external contact pad electrode (710), Therefore, the digital transaction card is instructed to be inserted into a digital transaction device (for example, an EFTPOS terminal or an ATM). In this embodiment, The selected electrode of the external contact pad (ie, the GND (708) electrode and the RST (712) electrode) is connected to the opposite electrode (ie, GND (720) that can be connected to the MCU (702) or to its internal contact pads, respectively) ) Independently switchable devices (734 and 736) for electrodes and RST (724) electrodes. This embodiment has the advantage of providing the MCU (702) signal from one of the external Vcc detection circuits (738). The signal indicates that the user has selected to perform a digital transaction and, therefore, The MCU (702) may stop communication with the EMV device (700) to allow a digital transaction to be completed by the user and then after detecting power to the Vcc (710) electrode that is not connected to the external contact pad (704). Respond to communication between the MCU (702) and the EMV device (700). It will be appreciated by those skilled in the art that a Vcc detection circuit can be used in any embodiment to provide an indication to the MCU: Power has been applied to the Vcc electrode, It is therefore indicated that the DTC is inserted into a transaction device. In a further embodiment, Figure 7E depicts a configuration, The outer contact strip (704) electrode is directly and permanently connected to the opposite electrode in its inner contact strip (706) and is simultaneously permanently connected to the appropriate signal lines of the MCU (702) and the EMV device (700). In this particular configuration, The electrodes of the outer contact piece (704) and the inner contact piece (706) are permanently connected to both the MCU (702) and the EMV device (700), There is thus a need to encrypt (732) any communication between the MCU (702) and the EMV device (700) to obstruct any attempt to monitor or interfere with communication between the two devices by accessing the electrodes of the external contact pads (704). Although this particular embodiment has the disadvantage of requiring all communication between the MCU (702) and the EMV device (700) to be encrypted, However, it is manifested in the advantage of avoiding any interruption of the existing transaction process in an EMV device (700) when participating in a digital transaction and thus avoiding any need to revalidate the EMV device when incorporating a digital transaction card, Communication between the MCU (702) and the EMV device (700) is implemented in accordance with the embodiment depicted in Figure 7E. Referring to Figure 7F, A further alternative embodiment for implementing communication between an MCU (702) and an EMV device (700) is depicted in the figures. In this particular embodiment, The individual electrodes of the outer contact pads (704) are directly and permanently connected to opposite electrodes in their inner contact pads (706), It is in turn permanently connected to the associated electrical connection point of the EMV device (700). however, To implement communication between the MCU (702) and the EMV device (700), Each device has its own antenna, That is, the EMV device antenna (739) and the MCU controller antenna (740). In the embodiment of Figure 7F, Both the EMV device (700) and the MCU (702) have their own RF communication circuitry incorporated into their respective devices such that each device can communicate wirelessly. In an embodiment, The EMV device (700) and the MCU (702) are equipped with RF communication circuits that are electrically connectable to an antenna and that can communicate in accordance with NFC communication protocols. In this example, The EMV device (700) and the MCU (702) effectively communicate with each other by NFC communication over a digital transaction card. of course, In the embodiment of Figure 7F, It is necessary to encrypt (732) any communication between the EMV device (700) and the MCU (702) to avoid external third party monitoring by monitoring the communications by using an NFC receiving device but for the various embodiments described above, The embodiment of Figure 7F has the following advantages: There is typically no potential interruption of the transaction process between an external contact strip and an EMV device. therefore, It may be possible to avoid re-verification resulting from interrupting the transaction process between the external contact pads and the EMV device. One such embodiment for implementing communication between an EMV device (700) and an MCU (702) is incorporated into a digital transaction card. When attempting to develop a digital transaction card that can be used with an existing digital trading network infrastructure operation, Preferably, the coefficient bit transaction card is operable to communicate with devices already present in an existing network infrastructure that is identified and established for devices in the network in accordance with communication capabilities and protocols. According to this, Business terminals and other devices (such as automated teller machines) that exist in the established digital trading network, according to standards developed for near field communication, Contact with an EMV device contact entity of a credit card and provide communication facilities between the credit card and the device by commenting on and reading the magnetic strip on the back of a credit card. Correspondingly, When attempting to provide a digital trading card that can be paired with one of the additional features of a trading network operation, Preferably, a digital transaction card that can be operated with an existing digital transaction network is provided in accordance with current protocol standards and interfaces. therefore, It is preferred to provide a DTC that also has the ability to use a merchant terminal that relies on the use of one of the magnetic strips and, therefore, In an embodiment of the invention, The DTC has a dynamic magnetic strip controlled by a magnetic strip assembly (632) as depicted in Figures 6A and 6B. According to this, Since the DTC in accordance with an embodiment of the present invention is operable to adopt any of a number of identities that can be selected and activated by a user, Therefore, the magnetic strip on the back of the digital transaction card needs to be configured with a magnetic strip according to the identity of the digital transaction card at any particular point in time. Correspondingly, The MCU (702) has a data link to one of the magnetic strip assemblies (632) as depicted in Figures 6A and 6B and is operable to configure the magnetic strip on the back side of the digital transaction card such that it is at any particular point in time and digits The magnetic strip associated with the identity of the transaction card matches. In addition, Since the digital transaction card according to an embodiment of the invention depicted in the figures can include a display, Therefore, the MCU (608) has a direct connection to the display module (634) as depicted in Figures 6A and 6B. The driver can be used to provide information to the user's display (634) of the digital transaction card independently of a user's mobile device (600). According to one embodiment of the present invention, a digital transaction card provides the ability for a user to combine various digital transaction cards on a single card and select and activate any of the various identities stored on the card at any particular point in time to achieve The ability to trade. In addition, According to embodiments depicted herein, The digital transaction card can operate according to all available agreements and interfaces currently present in the established digital transaction network and, therefore, A digital transaction card in accordance with one of the embodiments described in this specification can be used with existing digital trading networks anywhere in the world. This means that the digital trading network installed therein contains devices that have been upgraded to communicate with digital trading cards based on NFC capabilities and may be subject to direct physical contact or use with EMV device contacts, which may be considered to be in the “developing country”. The country of the magnetic stripe that is popular in the country is particularly important. In addition, In the "developed countries" where many digital trading network infrastructures contain many terminals with NFC communication capabilities, Many consumers have not yet chosen to adopt e-wallet services provided by many commercial operators. Because its mobile phone or smart phone device does not have NFC communication capabilities. In order to use the currently available e-wallet business services, It is necessary to implement such services on a smart phone that includes one of the NFC communication facilities. of course, A digital transaction card in accordance with one of the embodiments described in this specification can communicate with any device incorporated into a Bluetooth communication facility that includes many legacy smart phones and, therefore, According to an embodiment of the invention, A user can select and activate the identity by selecting and launching a specific identity of a digital transaction card on a smart phone equipped with only a Bluetooth communication facility and communicating the command to the established Bluetooth communication protocol A digital trading card. The Bluetooth communication facility has been used to select and activate one of its digital transaction cards, The transaction card can be used to trade with one of the existing digital trading networks in accordance with any of the currently available protocols and interfaces that include magnetic strips and physical contact with the EMV device contacts. Table 1 is a DTC embodiment depicted in Figure 3D detailing the combination of features presented in various embodiments when the EMV device associated with the DTC is modified via firmware (314, 316, One of the charts for 318 and 322). ✓ The symbol indicates that there is a feature, And the X symbol indicates that a feature does not exist, It should be understood that this list of embodiments is merely representative of one of the possible embodiments that can be configured with different combinations of features and is not intended to represent an exhaustive list. Table 1 Firmware modified EMV device

In the first embodiment of Table 1, the DTC (314) needs to communicate data to one of the firmware modified EMV devices using a data assist device (DAD) having a modified NFC capability, such as a smart phone. As previously described, a firmware modified EMV device has an external DTC CPU including one of the firmware operable to write data (eg, LDTDP data) to the scratch memory such that when the DTPU is enabled, the DTPU causes DTC Copy the data to the secure record memory (secure element) in the DTPU by adopting a specific card identity or by facilitating a digital transaction in some other way. The information relating to each identity may be stored in a memory associated with the DAD, wherein the communication between the DAD and the DTC may be in the form of a command to download and copy the data to the secure element to update the identity of the DTC. The firmware modified DTC (314) is limited to use with an NFC enabled DAD and uses one of the modified non-contact communication capabilities EMV devices to securely receive data from NFC enabled DAD reception, but with the following Advantages: The ability to adopt multiple identities and low cost for a single solution and the low failure tendency of the DTC (314) without an MCU, display or scrolling key/input key. The firmware modified DTC (316) also requires the use of a data assist device (DAD), such as a smart phone, to communicate the data to one of the firmware modified EMV devices as described above. The difference between DTC (314) and DTC (316) is that DTC (316) contains information that can store multiple identities (and/or can be related to changing some other digital trading parameters) rather than storing the data in DAD. One of the MCUs in memory, and can accept a secure session between one of the DADs with wireless connectivity (NFC or Bluetooth) and the DTC with wireless connectivity (NFC or Bluetooth). The advantages of using firmware-modified DTC (316) include low cost and low failure propensity, no need for an NFC enabled DAD (because the MCU can accept communication with one of the phones, for example, only Bluetooth enabled), for a single The ability of the solution to adopt multiple identities and the presence of an MCU that facilitates the secure transfer of data from the DAD without the need to use one of the EMV devices with modified contactless communication capabilities. The DTC (318) in Table 1 also requires the use of a Data Assist Device (DAD) (such as a smart phone) to communicate data to a wireless connection (NFC and/or Bluetooth) via a contactless interface. A firmware-modified EMV device is established between a DAD and a DTC. The DTC (318) includes one of the MCUs that can accept wireless communication from both NFC and Bluetooth enabled DAD, and can thereby establish a secure session between most phones and the DTC containing the MCU. The advantages of using DTC (318) include low to medium cost, low to medium failure propensity, and do not require the use of only one NFC enabled DAD, but since DTC (318) includes an MCU and display (320), and DTC (314) Compared to (316), there is a higher cost associated with the production of DTC (318). When using the DTC (322) described in Table 1, the skilled artisan will understand that a DAD (such as a smart phone) may be used but may be used to change the identity of the card or in some other way to facilitate a Digital trading. In any case, the DAD is initially required to set up the card and to download/store multiple identities in the MCU, but after initial setup, the card itself can be used to change the operational parameters of a card identity or use the scroll key/input key (326) ) Help digital trading in some other way. During an initial setup, an MCU is used to accept wireless communications (both Bluetooth and NFC) from the DAD and is further programmed to accept from a local interface (which may, for example, include a scroll key/input key (326) ))) and converts the key to a command. When the scroll key/input key (326) is used to change the identity of the DTC (322) or perform some other task that facilitates digital transactions, the transmission is authorized by the local interface, the local interface authorizing the MCU to select the stored data and This material is copied to the secure element. DTC (322) has the advantage that since no card details are transmitted, during the update or change (ie, change state/update), a plurality of identities stored on the card are selected locally to select an identity without the discovery card details. Risk. Further advantages include reducing the time required to implement updates or changes (i.e., changing status/updates), transmitting the minimum amount of information needed to achieve one of the identity changes, and the ability to change the DTC identity without the use of a DAD. However, DTC (322) has a higher production cost and may have a higher tendency to fail due to its complexity. Reference to any prior art in this specification is not, and should not be construed as, In the context of this specification and the following claims, the words "including" and variations (such as "comprises" and "comprising") are to be understood to include a A whole or a step, or a group of the whole or a step, but does not exclude any other whole or step or group of steps or steps. It will be appreciated by those skilled in the art that various changes and/or modifications may be made to the present invention as described in the embodiments without departing from the spirit and scope of the invention. Therefore, in all aspects, the embodiments of the invention are considered as illustrative and not restrictive.

100‧‧‧ device
102‧‧‧Digital Trading Devices/Point of Sale/Electronic Funds Transfer (POS/EFTPOS) Terminal/Business Terminal at Point of Sale
104‧‧‧Digital Transaction Processing Unit (DTPU)
106‧‧‧Smart Phone
108‧‧‧Digital Trading Card (DTC)
110‧‧‧User interface
112‧‧‧External contact piece
114‧‧‧Digital Trading Card (DTC) Transceiver
116‧‧‧Smart Phone Transceiver
200‧‧‧ Physical Card/Digital Trading Card (DTC)/Zero Identity
202‧‧‧Data Aid Device (DAD) User Interface
204‧‧‧Smart Phone/Data Aid Device (DAD)
206‧‧‧ Visa (VISA) card
208‧‧‧Customer MasterCard/Digital Trading Card (DTC)
210‧‧‧Zero Identity/Zero Identity Digital Trading Card (DTC)
300‧‧‧ Wearable devices
302‧‧‧Smart Phone
304‧‧‧Business terminal
306‧‧‧ Ring
308‧‧‧Smart Phone Box
310‧‧‧EMV devices
312‧‧‧Optional print recognition
314‧‧‧Digital Trading Card (DTC)
316‧‧‧ Second Digital Trading Card (DTC)
318‧‧‧ Third Digital Trading Card (DTC)
320‧‧‧ display
322‧‧‧ Fourth Digital Trading Card (DTC)
324‧‧‧ display
326‧‧‧ scroll key/input key
400‧‧‧Digital Transaction Processing Unit (DTPU)
402‧‧‧electrode
406‧‧‧Read-only memory (ROM)
408‧‧‧ Random Access Memory (RAM)
410‧‧‧Digital Transaction Processing Unit Central Processing Unit (DTPU CPU) / Digital Transaction Processing Unit (DTPU) Processor
412‧‧‧Encryption coprocessor
414‧‧‧Electrically erasable programming, read-only memory (EEPROM)/memory area/temporary memory/secure record memory
416‧‧‧Memory area/secure record memory/secure element/temporary memory
418‧‧‧System Input/Output (I/O)
420‧‧‧External Digital Trading Card Central Processing Unit (DTC CPU) / Digital Trading Card (DTC) Processor
422‧‧‧Information
424‧‧‧dotted line
426‧‧‧dotted line
428‧‧‧dotted line
500‧‧‧Command layer
502‧‧ ‧ agreement layer
504‧‧‧Information transaction layer
506‧‧‧ entity (electric) layer
508‧‧‧ mobile devices
509‧‧‧ transceiver
510‧‧‧Communication Module
512‧‧‧Microcontroller Unit (MCU)
514‧‧‧EMV devices
516‧‧‧External Contact/EMV Contact/EMV Device Contact
518‧‧‧Arbitration device
520‧‧‧Dynamic magnetic strip module
522‧‧‧ display driver
524‧‧‧display screen
526‧‧‧Battery
528‧‧‧ crystal
530‧‧‧Digital Trading Card (DTC)
532‧‧‧Dynamic magnetic strip
534‧‧‧EMV device antenna
536‧‧‧Near Field Communication (NFC) antenna
538‧‧‧Blue Antenna
540‧‧‧Digital Trading Card (DTC) Rolling Key/Input Key
600‧‧‧Mobile devices/smart phones
602‧‧‧ data flow
604‧‧‧ data flow
606‧‧‧Communication module
608‧‧‧MCU
610‧‧‧Data flow/data flow path
612‧‧‧EMV devices
614‧‧‧Arbitration device
616‧‧‧ data flow
618‧‧‧ data flow
620‧‧‧ data flow
622‧‧‧ data flow
624‧‧‧Data stream/signal
626‧‧‧Data stream/wireless transmission signal
628‧‧‧ data flow
630‧‧‧ data flow
632‧‧‧Dynamic Magnetic Stripe/Magnetic Strip Assembly
634‧‧‧Display module/display
636‧‧‧Digital Trading Card (DTC) Rolling Key/Input Key
638‧‧‧ data flow
700‧‧‧EMV devices
702‧‧‧MCU
706‧‧‧Internal contact piece
707‧‧‧Arbitration device
708‧‧‧GND
710‧‧‧Vcc
712‧‧‧RST
714‧‧‧CLK
716‧‧‧Input/Output (I/O)
718‧‧‧Blank terminal
720‧‧‧GND
722‧‧‧Vcc
724‧‧‧RST
726‧‧‧CLK
728‧‧‧Input/Output (I/O)
730‧‧‧Blank terminal
732‧‧‧Encryption
734‧‧‧Independent Switchable Devices
736‧‧‧Independent Switchable Devices
738‧‧‧External Vcc detection circuit
739‧‧‧EMV device antenna
740‧‧‧MCU controller antenna

For a better understanding of one of the present invention, and to illustrate how to carry out the invention, an alternative embodiment of the invention will now be described by way of non-limiting example only One embodiment of one of the embodiments, the embodiment comprising an embodiment of a digital transaction card (DTC) and an embodiment of a data aid (DAD) in the form of a smart phone, wherein the device Used to trade with one of the digital trading devices (in this example, a point of sale / electronic funds transfer (POS/EFTPOS) terminal at the point of sale); FIG. 2A is in accordance with an embodiment and FIG. One of the DTC communication DTCs, the DTC is operative to select a digital transaction file by using the DAD and selecting the identity of the DTC originating from the selection of the desired identity on the DAD and communicating it to the DTC FIG. 2B is a diagram showing one of DTCs for selecting a digital transaction file by using a DTC user interface. In the embodiment of FIG. 2B, the DTC user interface includes various touch activation switches and a display; 3A, FIG. 3B, FIG. 3C and FIG. 3D are respectively shown in one Illustration of various embodiments of the DTC in the form of a watch, ring, smart phone protection box and a credit card body, the credit card body of FIG. 3D depicted in accordance with a minimum feasible product embodiment, respectively, without an interface embodiment and with interface implementation 4A is a diagram of one of the components of a digital transaction processing unit (DTPU) located on a digital transaction card (DTC) in accordance with an embodiment of the present invention; FIG. 4B is located in accordance with an embodiment of the present invention. One of the components of a DTPU on a DTC is further illustrated; FIG. 5A is an abstract illustration of one of a digital transaction card (DTC) in accordance with an embodiment of the present invention, wherein the DTC has been divided into four abstraction layers to explain A DAD receives a function for implementing a change in DTC identity when present in each of four defined abstraction layers; FIG. 5B is an abstract illustration of one of a digital transaction card (DTC) in accordance with an embodiment of the present invention , where the DTC has been divided into four abstraction layers to account for the functions that appear in each of the four defined abstraction layers when receiving a command to implement a change in DTC identity from a DAD; Figure 5C is an entity of Figures 5A and 5B One of the (electric) layers 6A provides a graphical representation of a data flow between individual components of a digital transaction card (DTC) when a DTC identity change from a DAD is implemented in accordance with an embodiment of the present invention; One embodiment collectively provides graphical support for one of an exemplary data stream interpretation and interaction between individual elements on a physical (electrical) layer of a DTC; FIG. 6B provides a borrowing in accordance with an embodiment of the present invention. An illustration of a data flow between individual components of a digital transaction card (DTC) when a DTC identity change is implemented using a DTC interface, the schema being provided in conjunction with one of an exemplary data stream in accordance with an embodiment of the present invention Illustrative of the interaction between individual components on a physical (electrical) layer of a DTC; FIG. 7A is a configuration for implementing communication between an MCU device and an EMV device, according to an embodiment An illustration in which a communication line between EMV external contact pads is switched; FIG. 7B is a diagram showing one of configurations for implementing communication between an MCU device and an EMV device, wherein the switching is extended, according to an embodiment For the MCU device and the EMV Data bus between and the data and control lines extending from the EMV external contact pads are directly connected to the EMV internal contact pads and the EMV device and are not switched; FIG. 7C is used to implement an MCU device and an embodiment according to an embodiment. One of the alternative configurations of communication between EMV devices, wherein a selected control line between the EMV external contact pads and the EMV device is switched and similarly, only selected data between the MCU device and the EMV device is switched. And a control circuit; FIG. 7D is a diagram of a further alternative configuration for implementing communication between an MCU device and an EMV device, including determining between an EMV external contact pad and the EMV device, in accordance with an embodiment An external Vcc detection circuit for controlling the switching line and/or the corresponding control line between the MCU device and the EMV device; FIG. 7E is a further alternative for implementing communication between an MCU device and an EMV device One of the embodiments illustrates that neither the data and/or the control line between the MCU device and the EMV device is switched, and further, the data and/or control lines between the EMV external contact pads and the EMV device are not cut And Figure 7F is an illustration of an alternative embodiment in which the configuration for enabling communication between an MCU device and an EMV device is relied upon by a separate antenna connected to the MCU device and the EMV device, respectively Communication between the MCU device and the EMV device, thereby achieving without the need to use the MCU device connected to any of the data and/or signal lines between the EMV external contact chip and the EMV device Communication between the MCU device and the EMV device.

100‧‧‧ device

102‧‧‧Digital Trading Devices/Point of Sale/Electronic Funds Transfer (POS/EFTPOS) Terminal/Business Terminal at Point of Sale

104‧‧‧Digital Transaction Processing Unit (DTPU)

106‧‧‧Smart Phone

108‧‧‧Digital Trading Card (DTC)

110‧‧‧User interface

112‧‧‧External contact piece

114‧‧‧Digital Trading Card (DTC) Transceiver

116‧‧‧Smart Phone Transceiver

Claims (43)

A digital transaction device comprising: a data assist device (DAD) comprising: a user interface operable to select at least data, and a DAD transmitter; a digital transaction card (DTC) comprising: a digital transaction processing unit (DTPU), and a DTC receiver, wherein the DAD and DTC are operable to transfer data from the DAD to the DTC, and when the DTC is subsequently used to implement a digital transaction, the DTC is selected according to And operating from the data transmitted by the DAD to the DTC, and wherein the DTPU operates according to firmware, wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, when the set of extended commands is executed, Writing data to a secure record memory of the DTPU, the firmware operable to instruct the DTPU to copy the data into a temporary memory and to transfer the data in the temporary memory to the secure record In memory. The digital transaction device of claim 1, wherein the DAD further comprises a receiver, and the DTC further comprises a transmitter, and thus, data can be transferred between the DAD and the DTC. The digital transaction device of claim 1 or claim 2, wherein the transmission material includes information about one or more selectable identities. The digital transaction device of claim 1, wherein the selected and transmitted material comprises one or more instructions. The digital transaction device of claim 4, wherein the one or more instructions include instructions for changing one of the current identities of the DTC to one of a plurality of selectable identity selections. The digital transaction device of claim 3, wherein the data relating to the plurality of selectable identities is stored on the DAD, and changing the current identity of the DTC to the selected identity comprises: by the DAD and by the DAD user The operation of the interface receives the instruction to change the current identity of the DTC to the selected identity; the data transmitted by the DAD transmitter to the DTC receiver in relation to the selected identity; and the implementation in the DTC based on the data The change from the current identity to the selected identity causes the digital transaction device to recognize the selected identity when the DTC cooperates with a digital transaction device to implement the digital transaction. The digital transaction device of claim 3, wherein the data relating to the plurality of selectable identities is stored on the DTC, and changing the current identity of the DTC to the selected identity comprises: using by the DAD and by the DAD The operation of the interface receives the instruction to change the current identity of the DTC to the selected identity; the instruction transmitted by the DAD transmitter to the DTC receiver for changing the current identity of the DTC to the selected identity And in the DTC, a change from the current identity to the selected identity is implemented in accordance with the instruction such that when the DTC cooperates with a digital transaction device to implement the digital transaction, the digital transaction device identifies the selected identity. The digital transaction device of claim 1, wherein the DTC comprises a user interface. The digital transaction device of claim 3, wherein the selected data transmitted from the DAD to the DTC with respect to the plurality of selectable identities and stored on the DTC is individually selectable by operation of the DTC user interface . The digital transaction device of claim 9, wherein changing the current identity of one of the DTCs to the selected identity comprises: receiving, by the operation of the DTC user interface, changing the current identity of the DTC to one of the selected identities or a plurality of instructions; and in the DTC, performing a change from the current identity to the selected identity in accordance with the one or more instructions such that when the DTC cooperates with a digital transaction device to implement the digital transaction, the digit The transaction device identifies the selected identity. The digital transaction device of claim 8, wherein the DTC scroll key enables a user to select an identity from the plurality of identities, and the display indicates the selectable identity. The digital transaction device of claim 1, wherein the DTC includes a DTC external processor for receiving and storing the transmitted data. The digital transaction device of claim 1, wherein the DTC includes a display for displaying information. The digital transaction device of claim 1, wherein the DTPU is an EMV device according to one of firmware operations, wherein the firmware has been modified to enable the EMV device to receive and execute a set of extended commands when executing the set of extended commands, Data is allowed to be written to the secure record memory of the EMV device. The digital transaction device of claim 14, wherein the data is LDTDP data, and the firmware is operative to write the LDTDP data to a temporary memory associated with the DTPU such that when the DTPU is activated, the DTPU This material is copied to the secure record memory. The digital transaction device of claim 14, wherein the digital transaction device is physically coupled to the contact terminal of the EMV device, or by a contactless connection (ISO 14443 standard), or by being associated with the digital transaction device An interaction between a magnetic strip reader and one of the magnetic strips of the DTC interfaces with the EMV device. The digital transaction device of claim 16, wherein the DTC is a wearable device comprising a watch, a wristband, a ring or a jewelry item. The digital transaction device of claim 16, wherein the digital transaction device is any one or more of a POS/EFTPOS terminal, an ATM, a computer connected to the Internet, or a personal computer. The digital transaction device of claim 3, wherein the identity is any one or more of the following: a credit card; a debit card; a bank account; a memory card; a passport; an identity card; an age verification card; Circuit storage card; a membership card; a borrowing card; a public transportation card; a government agency card; a driver's license, or any other card or document used to identify the owner of the card or document. The digital transaction device of claim 1, wherein the DAD is any one or more of the following: a smart phone; a computer tablet; a laptop; a personal computer (PC); a wearable device, comprising a A smart watch; a chain device; or any other processing device that includes a user interface and is operable to transmit instructions to a DTC. A data assist device (DAD) comprising: a user interface operable to select at least data; and a DAD transmitter operative to transfer data from the DAD to a digital transaction card (DTC) Connected to a receiver having a digital transaction processing unit (DTPU) operating according to firmware, wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands when executing the set of extended commands, Allowing data to be written to a secure record memory of the DTPU, the firmware operable to instruct the DTPU to copy the data into a temporary memory and to transfer the data in the temporary memory to the security In the record memory, the data selected and transmitted to the DTC causes the DTC to operate in accordance with the selected material when the DTC is subsequently used to implement a digital transaction. A DAD as claimed in item 21, wherein the DAD further comprises a receiver. A digital transaction card (DTC) comprising: a digital transaction processing unit (DTPU); and a DTC receiver operative to receive a user selected from a transmitter associated with a data assist device (DAD) Data, wherein the received data selected by the user causes the DTC to operate according to the data selected by the user when the DTC is subsequently used to implement a digital transaction, and wherein the DTPU operates according to a firmware, wherein the firmware Has been modified to enable the DTPU to receive and execute a set of extended commands that, when executed, allow data to be written to one of the DTPU's secure record memory, the firmware operable to instruct the DTPU to copy the material Go to a temporary memory and transfer the data in the temporary memory to the secure record memory. A digital transaction card as claimed in item 23, wherein the DTC further comprises a transmitter. A digital transaction method, comprising: selecting a data by a user interface of a data assisting device (DAD); transmitting the selected data to and having a digital transaction processing unit (DTPU) by a DAD transmitter associated with the DAD a digital transaction card (DTC) associated with one of the receivers; and a digital transaction by the DTC, wherein the DTC operates in accordance with the data selected and transmitted from the DAD to the DTC, wherein the DTPU is Operating, wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands that, when executed, allow data to be written to one of the DTPU's secure record memory, the firmware being operable The DTPU is instructed to copy the data into a temporary storage memory, and the data in the temporary storage memory is transferred to the secure recording memory. A digital transaction method as in claim 25, wherein the selected and transmitted material comprises one or more instructions. A digital transaction method of claim 26, wherein the selecting and transmitting data is related to a plurality of selectable identities, and changing the current identity of the DTC to a selected identity comprises: by the DAD and by the DAD user interface Operating to receive an instruction to change the current identity of the DTC to the selected identity; to transmit data to the DTC receiver to the selected identity by the DAD transmitter; and in the DTC, based on the data A change is transmitted from the current identity to the selected identity such that when the DTC cooperates with a digital transaction device to implement a digital transaction, the digital transaction device identifies the selected identity. The method of claim 25, wherein the DTC includes a user interface having an input key and a scroll key, and the selected data transmitted to the DTC is related to the plurality of selectable identities, the method further comprising: The DTC user interface selects one of the plurality of selectable identities and causes the DTC to subsequently adopt the selected identities. A digital transaction method as claimed in claim 28, wherein changing the current identity of one of the DTCs to the selected identity comprises: receiving, by the operation of the DTC user interface, changing the current identity of the DTC to one of the selected identities Or a plurality of instructions; and in the DTC, performing a change from the current identity to the selected identity based on the one or more instructions such that when the DTC cooperates with a digital transaction device to implement a digital transaction, The digital transaction device identifies the selected identity. The digital transaction method of any one of clauses 26 to 29, wherein the DTPU is an EMV device, and the changing from the current identity to the selected identity comprises writing the data about the selected identity to the EMV One of the devices secures the memory component such that when an EMV device is activated, the EMV device reads the data in the secure memory component, thereby causing the DTC to adopt the selected identity. A digital transaction method as in claim 30, wherein the data is stored in a temporary memory associated with the EMV device prior to writing the data to the secure memory component. A method of operating a data assist device (DAD), comprising: selecting a material by a user interface of the DAD; and transmitting the selected data to and having a firmware according to a DAD transmitter associated with the DAD a digital transaction card (DTC) associated with one of the digital transaction processing units (DTPUs), wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands when executing the set of extended commands Allowing the data to be written to one of the DTPU's secure record memory, the firmware operable to instruct the DTPU to copy the data into a temporary memory and transfer the data in the temporary memory to the In secure record memory, wherein the DTC operates in accordance with the selected and transmitted data when the DTC is subsequently used to implement a digital transaction. A method of operating a digital transaction card (DTC), comprising: receiving data from a data assist device (DAD) containing data selected by a user; implementing a digital transaction by the DTC, wherein the DTC is selected according to the user Data operation, wherein the DTPU operates according to a firmware, wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, allowing data to be written to the DTPU when the set of extended commands is executed Recording a memory operable to instruct the DTPU to copy the data into a temporary memory and transfer the data in the temporary memory to the secure recording memory. A method of claim 33, wherein the user selected material comprises one or more instructions. A computer readable medium storing one or more instructions that, when executed by one or more processors associated with a data assist device (DAD), cause the one or more processors : selecting data from a user interface of the DAD; and transmitting the selected data by a DAD transmitter to a digital transaction card (DTC) having one of a digital transaction processing unit (DTPU) operating according to firmware a receiver, wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands, and when executing the set of extended commands, to allow data to be written to one of the DTPU secure record memories, the firmware is operable Instructing the DTPU to copy the data into a temporary storage memory, and transferring the data in the temporary storage memory to the secure recording memory; wherein the DTC is subsequently used to implement a digital transaction in the DTC The operation is based on the selected and transmitted data. A computer readable medium storing one or more instructions that, when executed by one or more processors associated with a digital transaction card (DTC), cause the one or more processors Retrieving user selected data from a data assist device (DAD); and subsequently implementing a digital transaction, wherein the DTC operates in accordance with data selected by the user, wherein the DTC includes a digital transaction processing unit based on firmware operations (DTPU), wherein the firmware has been modified to enable the DTPU to receive and execute a set of extended commands that, when executed, allow data to be written to one of the DTPU's secure record memories, the firmware being operable The DTPU is instructed to copy the data into a temporary storage memory, and the data in the temporary storage memory is transferred to the secure recording memory. A computer readable medium as claimed in claim 36, wherein the user selected material comprises one or more instructions. A method comprising: receiving a DTC configured to operate according to request item 1 or request item 22 from an issue authority. A method comprising: issuing, by an issuing authority, a DTC configured to operate according to request item 1 or request item 22. A method comprising: receiving a DTC configured to operate according to a method of request item 25 or request item 33 from an issue authority. A method comprising: issuing, by an issuing authority, a DTC configured to operate in accordance with a method of request 25 or claim 33. A method comprising: issuing, by an issuing authority, an opcode comprising a software and/or firmware to a data assist device (DAD) and/or a digital transaction card (DTC) to enable the DAD and/or DTC to Operate according to request item 1. A method comprising: issuing, by an issuing authority, an opcode comprising a software and/or firmware to a data assist device (DAD) and/or a digital transaction card (DTC) to enable the DAD and/or DTC to Operate according to the method of claim 25.