FIELD OF THE INVENTION

[0001] The present invention relates generally to apparatus and methods for effecting digital transactions, including both financial and non-financial transactions. The apparatus and method may be particularly useful for transactions involving credit and/or debit cards.

BACKGROUND OF THE INVENTION

[0002] Credit cards, debit cards store cards and gift cards are examples of cards that are used for financial transactions throughout the world. Further, other types of cards such as passes, tags and small booklets (which may be referred to collectively as transaction documents) are used for various financial and non-financial transactions. For example, some jurisdictions require proof of age cards for transactions such as purchasing alcohol or entering into age restricted venues. Other examples of proof of age, or proof of identity, documents include driver licenses which are sometimes used for authentication in respect of transactions. In some countries, passports and/or other similar identification documents are issued in the form of a card, or a small booklet, and can be used for transactions where identification is required including, travel across borders or establishing a bank account.

[0003] Many transaction documents have a magnetic stripe, which can be encoded with information such as a unique identification number, expiry dates or other numerical or alphanumerical information. Other types of transaction documents include contactless stored value smart cards, for example, closed loop transport cards, such as Myki in Melbourne, Australia, and the Octopus Card in Hong Kong.

[0004] Transaction documents may include a chip, smart chip, or smart card chip (in this specification, such chips or devices and other similar types of microcircuit will be referred to generally as Digital Transaction Processing Units, or DTPUs). DTPUs typically include one or more of a Central Processing Unit (CPU), Read Only Memory (ROM), Random Access Memory (RAM), Electrically Erasable Programmable Read Only Memory (EEPROM), a crypto- coprocessor and an Input/Output (I/O) system. 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 encrypted data relevant to the type of transaction(s) for which the document will be used. The EMV device may be read by a scanner (for example, using contactless, close proximity communications according to ISO/IEC 14443 which is referred to as Near Field Communication (NFC throughout the specification)), by direct contact with chip connected electrodes, or by other means to obtain data from the chip. Such transaction documents enabled for use in digital transactions by means of a chip, a magnetic stripe, a chip and magnetic stripe, or Radio-Frequency IDentification (RFID) are referred to throughout this specification as digital transaction documents.

[0005] Digital transaction documents are configured to work with various components in a digital transaction system including terminals. For example, credit and debit cards work with EFTPOS (Electronic Funds Transfer at Point Of Sale) terminals for Point Of Sale (POS) transactions, and ATM (Automatic Teller Machine) terminals. Other digital transaction documents are configured to work with other types of terminals. Such terminals may be operably connected to financial institutions or other third party organizations to enable digital transactions to occur by authorizing the transaction or performing associated processing to enable the transaction.

[0006] In another example, identification cards, such as a proof of age cards, are implemented with a chip (or DTPU) containing some, or all, of the information of the card owner, along with verification information to confirm the authenticity of the card. Identification cards may be used in a digital transaction, whereby it is inserted into, swiped, or waived near, a terminal to confirm the age of the person holding the card. Other non-financial transactions can be implemented in a similar manner.

[0007] Terminals used for transactions with digital transaction documents are referred to throughout this specification as digital transaction system devices. For "Card-Present" transactions, the digital transaction system devices may include, for example, POS/EFTPOS terminals, ATMs, and network connected or stand-alone readers for reading other types of non- financial transaction documents. The digital transaction devices may also be suitable for "Card- Not-Present" transactions, for example, online transactions, Mail Order/Telephone Order (MOTO) transactions, and may include internet connected personal computers, smartphones, and tablets. Further, digital transaction system devices include telephones used to communicate with an operator who uses, for example, a network connected terminal to enter transaction document data.

[0008] Digital transaction documents have a unique IDentification (unique ID), typically having a number, an alphanumeric ID, or a unique name. The unique ID may be located on, or in, the digital transaction document, for example, printed or embossed on the document. The unique ID is also typically recorded on a database, controlled, for example, by the issuer of the digital transaction document, and accompanied by other information, such as name, address, age, and/or financial information relevant to the user/owner of the digital transaction document. Where a digital transaction document has a chip, an EMV device or other type of DTPU, the unique ID is typically stored on the chip, EMV device or DTPU, respectively. [0009] Credit cards are typically embossed or printed with a Personal/Primary Account Number (PAN) to uniquely identify the account card holder. A standardized PAN has four fields, namely, a system number, a bank/product number, a user account number, and a check digit. This type of PAN typically has 16 digits, but may have between 13 and 19 digits (for example, an American Express PAN has 17 digits). The first digit is the card issuer type (for example, Visa, MasterCard or American Express), and the next 5 to 7 digits is generally referred to as a Bank Identification Number (BIN) and represents the card network, the bank and the product for this bank. The last digit is reserved for a checksum of the previous digits of the PAN. An expiration date is associated with the PAN and generally includes a month and year code having four digits, but with limited range. The card holder's PAN, name or business, and the card's expiry date typically appear embossed or printed on the face of a card. Previously, some types of credit card had a magnetic stripe encoding some or all of the card information.

[0010] More recently, financial transaction cards have carried a Card Verification Value (CVV) or Card Verification Code (CVC) on the magnetic stripe to make it more difficult to replicate a card for fraudulent purposes. The CVC is usually a unique cryptogram, created based on the card data, for example, including the card PAN and expiry date, and a bank's (or a personalization bureau's) master key, and printed on the card after personalization data is entered on the card. As a consequence, a person seeking to use a card for fraudulent purposes requires possession of the card for a sufficient period of time to make a copy of the magnetic stripe in order to duplicate the card, or to read the card and manually record the card number, expiry date, and other details printed on the card.

[0011] The same principle was subsequently adopted for a second CVC, sometimes called Card Verification Value 2 (CVV2), which is commonly printed in the signature panel on the back of the card. The CVV2 is used primarily to help secure e-Commerce and MOTO transactions. This is a second unique cryptogram created from card data and the bank's master key (although this is a different cryptogram as compared with the magnetic stripe CVC). The CVV2 is not present on the magnetic stripe.

[0012] Some credit cards also have an associated Personal Identification Number (PIN) code, which is primarily used for "Card-Present" transactions. The PIN must generally be kept confidential, and must be entered on secure and certified terminals to make sure that no-one can gain access to the PIN. Further, in modern credit cards, the PIN can be stored on the chip (for example, an EMV device) in an encrypted form within a cryptogram block.

[0013] There are two main classifications of transactions for which credit cards are used including: "Card-Not-Present" transactions, when using the Internet or MOTO; and "Card-Present" transactions, such as used with POS/EFTPOS and ATM terminals. Card-Present transactions involve EMV device readers (including physical contact readers using electrode pins on a card and contactless reading using, for example, Near Field Communications (NFC)) and/or magnetic stripe readers. These transactions generally use the full 13 to 19 digit PAN and the 4-digit expiration date. Card-Not-Present transactions generally require the user to read out to an operator, or enter into a computer, the PAN and expiration date digits. In some instances, the CVC/CVV2 number is also required.

[0014] Other types of digital transaction documents may use various forms of security, such as PINs, passwords, and the like. However, some other types of digital transaction documents do not use such external security, and rely only upon the authenticity of the document itself, for example, using holograms and other security devices that are difficult to copy. Further, some types of non-credit card digital transaction documents may use chips for security, including chips similar to EMV devices.

[0015] Cards (or other digital transaction documents) may have data stolen, for example, using a Radio Frequency (RF) signal to power the card's EMV internal microprocessor and related transmitter. Generally, the card data, such as the PAN, expiration date and cardholder's name are transferred to a wireless terminal. The terminal can be a portable or stationary wireless terminal, and once near a card, uses the RF signal to energize the card to firstly, extract the card data and copy some to a memory storage device, or to online storage, such as, the cloud, and secondly, use a portable terminal in close proximity to the card to extract monies as a contactless payment (for example, a PayWave and/or tap payment, such transactions being referred to by traders as tap-and-pay or tap-and-go), in accordance with a level of transaction that does not require any authorization. Subsequently, stolen card data can be uploaded to a duplicate "fake card" or used in online transactions to make fraudulent purchases. Yet another method used to steal card data for fraudulent use involves hacking into computer databases that store card data. This data is then used for transactions, and a card owner may only become aware of this when they see a statement detailing the transactions made with their card, or card data.

[0016] Other ways card data is stolen include phishing scams where the card holder is tricked into entering a security code along with other card details via a fraudulent website. Phishing therefore reduces the effectiveness of security codes as an anti-fraud means. However, merchants who do not use security codes are typically subjected to higher card processing costs for transactions, and fraudulent transactions without security codes are more likely to be resolved in favor of the cardholder, which increases costs for merchants. Yet other ways that security of transactions may be compromised is by skimming and man-in-the-middle attacks.

[0017] With the emergence of e-Commerce, an increasing number of transactions are Card- Not-Present type transactions. However, this type of transaction is subject to an increasing number of attacks from fraudsters including attacks that have resulted in increased verification that has caused a "failure positive" result where the card holder is legitimate but the transaction is rejected.

[0018] Several solutions have been developed to address this growing fraud, including use of virtual account numbers, authentication of cardholders separately from the transaction, and use of a hardware token to authenticate the user. Another proposed solution comprises an institution, such as a bank sending a code to the user, typically by SMS to the user's smartphone, which can then be used to authenticate a Card-Not-Present transaction. This arrangement is generally referred to as an Out-Of-Band (OOB) message which unfortunately has been recently hacked. In any event, many of these solutions require expensive infrastructure changes, which merchants prefer to avoid and may only provide protection for a limited time until the arrangement is hacked.

[0019] With the increasing number of Card-Not-Present transactions, a suggested means of conducting such transactions is the electronic wallet (e-wallet), also known as a digital wallet. An e-wallet provides users with a means to pay for purchases from enabled on-line merchants. Upon registration, a user can store their card, billing and shipping information on a site hosted by a suitable document, such as a bank, and can access that information to pay for goods or services. However, e-wallets on an NFC enabled device, such as a smartphone, do not operate in a large percentage of Card-Present transactions, for example, POS/EFTPOS or ATM transactions since these network transaction devices generally do not support contactless payments and amongst the presently available contactless payment arrangements, different back end processes and merchant agreements are involved. As a result, the establishment and use of e-wallets has experienced limited commercial success and whilst they remain available to consumers, only approximately 10% of consumers have elected to install an e-wallet although the take-up rate by consumers is now starting to drop.

[0020] A user may prefer to have, and to carry around with them, many of their available credit cards, debit cards, store cards, government agency cards and loyalty cards since they prefer to physically hold and control the possession of those cards. Further, a user may require an identity card, driver's license, age verification card or passport. Carrying around a large number of individual digital transaction documents can be very inconvenient. Moreover, the person, having so many physical transaction documents, may become confused regarding the location of a particular digital transaction document, for example, a particular credit card, among all the other digital transaction documents.

[0021] An alternative solution to e-wallets that addresses the problem of users carrying a large number of credit or debit cards has been developed, wherein a credit card sized device has a keyboard (or touch pad arranged as a simplified keyboard) and a small limited function Graphical User Interface (GUI), which are used to select one card amongst a number of cards stored on the device, and to enter data for various transactions. However, the keyboards are of limited functionality due to their limited number of keys in the relatively small space available on the card (being the area of an average credit card). The keyboards are also considered difficult to use because of their small size, and as a result a large number of keystrokes may be required to effect any particular function. Further, the keyboard on a credit card is not a solution for other types of digital transaction document such as those documents used for proof of identity or proof of age. Other attempted solutions include products, such as Plastc, Coin, Final, and Wocket. However, the Plastc solution has some operational limitations, and the Wocket solution requires a specific Wocket device. None of these solutions has gained wide commercial acceptance. Moreover, it has been found that cards including a keyboard have an unacceptably high failure rate when given to customers in view of the repeated, perhaps daily, usage. It is suggested that the high failure rate may be, at least in part, due to the complications of having the keyboard on a card, which has limited space for such a complex electronic device.

[0022] Another problem with attempting to accommodate multiple credit cards, debit cards or other digital transaction documents on a single card are the limitations caused by the use of proprietary or standardized chips. Such chips or DTPUs are configured to securely store information for one digital transaction document only. For example, a credit card chip, such as an EMVCo standard chip, securely holds information typically including the credit card PAN, the expiry date, a security code (such as the CCV2 number), and a PIN. Transaction devices, such as POS/EFTPOS terminals, securely communicate with the DTPU to obtain some, or all, of the information from the DTPU for a transaction to be authorized and verified. Many DTPUs are also configured to resist attempts to write to the DTPUs secure record memory (which may also be referred to as a secure element, or part of a secure element), as many such attempts are made by those seeking to use the card fraudulently. It will be understood that a secure element may comprise secure memory and an execution environment, and is a dynamic environment in which application code and application data can be securely stored and administered. Further, it will be understood that, in a secure element, secure execution of the application can occur. A secure element may be located in a highly secure crypto chip (otherwise known as a smart card chip). The security of the DTPU may also prevent legitimately introducing one or more new digital transaction documents (including PANs, tokens expiry dates, PINs and other data attributes of those documents) into the secure record memory (secure element) of the DTPU so that the DTPU cannot take on another document's personality (a term which is used herein to describe a digital transaction document (or logical digital transaction document) and its attributes). [0023] Accordingly, it has been difficult to instigate use of single physical cards having multiple personalities (multiple credit and/or debit cards expressed or expressible on a single physical card), given the change in infrastructure required, including modified DTPUs (such as the EMVCo device), modified digital transaction devices (for example, modified POS/EFTPOS terminals), along with any other modification required in other parts of the credit/debit card payment infrastructure. Apart from the technical problems, Scheme providers such as Visa and MasterCard have various additional requirements including the presence of a hologram and logo of the Scheme on the physical card.

[0024] In this regard, it is desirable to provide a single EMV (or EMV type device), or other type of DTPU, on a Digital Transaction Card (DTC), for example, a credit card sized card, which is able to selectively assume the personality of a number of different digital transaction documents (or logical digital transaction documents). For example, a user may seek to use MasterCard account for one transaction, but to a use Visa account for a different transaction. Alternatively, a user may seek to use the DTC as a credit card, but to subsequently use it as an age identity card.

[0025] However, to-date, there has not been a sufficiently effective, efficient, and/or secure means and/or method for adapting a DTPU (such as an EMVCo specified device) to embody different personalities as compared with the personality of the DTPU that was initially installed.

[0026] Another problem with present digital transaction documents is the ability to obtain data from a credit card or other transaction document. Although devices such as EMV devices have been introduced in an attempt to limit data theft, such arrangements have not proved to be entirely successful in preventing this type of crime. Increasing credit card fraud may incur cost for a bank, a merchant, a user, or all three parties. Further, identity theft is an increasing concern for users since a stolen identity can be used to commit fraudulent financial transactions, and other types of crime.

[0027] For some digital transaction documents, such as credit cards, tokens are sometimes used to enhance security for transactions. For credit cards, tokens are typically numbers that are the same length as the credit card's PAN, and are substituted for the PAN in a transaction. The token should not be feasibly decryptable to obtain the original PAN by a person seeking to use the credit card fraudulently, and so that person is unable to mimic the credit card, and unable to use the credit cards PAN and a card holder's other personal details for on-line transactions. Accordingly, if using a credit card in a high risk, low security environment, tokens are a means of protecting sensitive data. The security of the token is based primarily on the infeasibility of determining the original PAN (or other data) whilst knowing only the surrogate token value. Tokenization may be used instead of, or in conjunction with, other encryption techniques in transactions with digital transaction documents. [0028] A token (or digital token) may be generated by a third party, such as a credit card issuer, a financial institution, or a security provider for the credit card. Tokens are also used for securing other non-financial transactions, such as those involving drivers' licenses. The token may be generated as a cryptogram using inputs from a selection of, for example, the credit card's PAN (or some other unique ID of a digital transaction document), and/or the card's expiry date. The token for a transaction may be selected from a number of tokens in a pool based on the ID of the merchant or the terminal where the transaction is occurring, the date of the transaction, the time of the transaction, or various other criteria. De-tokenization to retrieve the original PAN typically occurs during the processing of a transaction, and is usually performed by the credit card issuer, financial institution, or security provider who issued the token.

[0029] Usually, tokens are generated during the process of creating and issuing a credit card to its owner/user. Each card may have one or more associated tokens. Where a card has multiple tokens, each token can be selectively used for different transactions or different transaction types.

[0030] Tokens have a number of problems, including not being selectable by the user to allow the user control over security and how tokens are used. For example, a user may seek to be able to select tokens for certain transactions or transaction types. Another problem is that the same token may need to be used for a number of different transactions, thus limiting the security afforded by the token. This is especially the case for a digital transaction document such as a credit card. Even if a digital transaction document has a number of associated tokens, those tokens will need to be reused or reissued after a number of transactions. It is difficult to issue new tokens, for example, to a credit card, since the infrastructure for issuing new tokens has been developed to issue those new tokens at a time of creation and issuance of a new credit card.

[0031] One way to prevent fraudulent use of a stolen or compromised credit card or other types of transaction document is to simply cancel the document, including cancelation of that document's unique identifier (for example, cancelling the account number of a credit card), and issue a new document with a new expiration date. Providers of the document may have a mechanism to invalidate old documents (for example, invalidating old account numbers), and to issue new numbers to existing users. However, it can sometimes take a substantial amount of time to deliver a new document (for example, delivering a credit card through the mail), and the delay greatly inconveniences the user. In the instance of a credit card, the issuance of a new card causes a temporary cessation of the user's ability to maintain payments by auto debit from credit accounts.

[0032] Further, document owners generally prefer instant or near instant ("real time") feedback of information regarding use of their card for financial transactions or other types of transaction, such as use of a card or other such documents for identification, traveling and other purposes. Card owners may also prefer real time feedback regarding account balances and other information related to their card, or other digital transaction documents. Further, owners of cards and other digital transaction documents may prefer the ability to block usage of a document in real time, or with minimal delay. This may be useful if the owner becomes aware of, or suspects, fraudulent transaction(s) with the use of one or more of their digital transaction document(s).

[0033] 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 provide at least a useful alternative to prior art devices, systems and/or methods.

SUMMARY OF THE INVENTION

[0034] In one aspect, the present invention provides digital transaction apparatus operable with a plurality of logical digital transaction documents, each logical digital transaction document representing a digital transaction document for performing a digital transaction with at least one digital transaction device, the digital transaction apparatus including, a Data Assistance Device (DAD) including, a user interface and a DAD transmitter, wherein the DAD is configured to allow selection of one of the at least one logical digital transaction document by use of the user interface, and, a Digital Transaction Card (DTC) including a DTC receiver and a Digital Transaction Processing Unit (DTPU), wherein the DTPU is configured to accept the selected one logical digital transaction document transmitted to the DTC by the DAD, such that the DTC is operable as the digital transaction document according to the selected one logical digital transaction document.

[0035] In another aspect, the present invention provides a Data Assistance Device (DAD) including a user interface and a DAD transmitter, operable with a Digital Transaction Card (DTC) including a DTC receiver and a Digital Transaction Processing Unit (DTPU), the DAD and the DTC operable with a plurality of logical digital transaction documents, each logical digital transaction document representing a digital transaction document, for a digital transaction with at least one digital transaction device, wherein the DAD is configured to allow selection of one of the at least one logical digital transaction document by use of the DAD user interface, and, wherein the DAD is operable to cause the selected one logical digital transaction document to be transmitted to the DTPU, and, the DTC is operable to receive the digital transaction document of the selected one logical digital transaction document and engage with a digital transaction device as the digital transaction document.

[0036] In yet another aspect, the present invention provides a Digital Transaction Card

(DTC) including a DTC receiver and a Digital Transaction Processing Unit (DTPU), operable with a Data Assistance Device (DAD) including a user interface and a DAD transmitter, both the DAD and DTC operable with a plurality of logical digital transaction documents, each logical digital transaction document representing a digital transaction document for performing a digital transaction with at least one digital transaction device, wherein the DTPU is configured to accept a selected one logical digital transaction document transmitted to the DTC by the DAD, such that the DTC is operable to receive the digital transaction document of the selected one logical digital transaction document and engage with a digital transaction device as the digital transaction document. [0037] In a further aspect, the present invention provides a method of transacting using digital transaction apparatus including, a Data Assistance Device (DAD) including a user interface and a DAD transmitter, the digital transaction apparatus also including a Digital Transaction Card (DTC) including a DTC transceiver and a Digital Transaction Processing Unit (DTPU), the digital transaction apparatus operable with a plurality of logical digital transaction documents, each logical digital transaction document representing a digital transaction document, for a digital transaction with at least one digital transaction device, the method including, accepting the transmitted data into the DTPU representing a selected logical digital transaction document, such that the DTC is operable as the digital transaction document of the selected one logical digital transaction document when engaging with a digital transaction device.

[0038] In yet another aspect, the present invention provides a method of transacting using digital transaction apparatus including a Data Assistance Device (DAD) including a user interface and a DAD transmitter, the digital transaction apparatus also including a Digital Transaction Card (DTC) including a DTC receiver and a Digital Transaction Processing Unit (DTPU), the digital transaction apparatus operable with a plurality of logical digital transaction documents, each logical digital transaction document representing a digital transaction document, for a digital transaction with at least one digital transaction device, the method including, operating the DAD user interface to select one of at least one of the plurality of logical digital transaction documents, stored in the DAD memory, transmitting the selected logical digital transaction document to the DTC which receives the logical digital transaction document into the DTPU and operating the DTC with the digital transaction device to perform a digital transaction.

[0039] In yet another aspect, the present invention provides a method wherein a user receives a Digital Transaction Card (DTC) from an issuing authority for use in accordance with any one or more of the statements above.

[0040] In yet another aspect, the present invention provides a method wherein an issuing authority issues a Digital Transaction Card (DTC) in accordance with any one or more of the statements above.

[0041] In yet another aspect, the present invention provides a method wherein an issuing authority issues a Digital Transaction Card (DTC) for use in accordance with any one or more of the statements above.

[0042] In a further aspect, the present invention provides a method wherein an issuing authority issues operating code, including software and/or firmware, for a Data Assistance Device (DAD) and/or for a Digital Transaction Card (DTC) for use in accordance with any one or more of the statements above. SUMMARY OF EMBODIMENT(S) OF THE INVENTION

[0043] It will be understood by skilled readers that in embodiments of the invention, a digital transaction apparatus including, and requiring both, a Data Assistance Device (DAD) and a Digital Transaction Card (DTC) for a digital transaction provides a multi-factor verification (including authorization, authentication, and both authorization and authentication) for the digital transaction, the factors being that the user (for example, someone seeking to pay for goods and/or services using a financial digital transaction) requires two items, namely, the DAD and the DTC and also knowledge regarding how to effect a transaction with the two items. Accordingly, if a person has both a DAD and a DTC when seeking to conduct a digital transaction, the likelihood that the person has obtained both items by fraud, theft, or deception is significantly reduced. For example, if the DAD is a smartphone, then it is unlikely that a person seeking to conduct a fraudulent transaction would be able to steal a legitimate DTC and the owner's smartphone when compared with solely the theft of a legitimate credit card as presently used to conduct digital transactions. Further, if a person seeking to conduct a fraudulent transaction managed to steal a legitimate DTC, it would be very difficult for that person to emulate, or spoof, the DTC owner's smartphone, including any necessary additional hardware and software to operate with the DTC to conduct a digital transaction.

[0044] In embodiments, the DAD and DTC are operable to transfer data therebetween which may further assist to reduce the incidence of fraudulent digital transactions. For example, the DAD could be used to transmit a One Time PIN (OTP) to the DTC prior to each and every transaction, the OTP being requested by a digital transaction system device during a digital transaction and requiring entry of the PIN by the user to complete the transaction. In any event, it is expected that transferring data between the DAD and DTC will assist users to manage and monitor their digital transactions.

[0045] In embodiments, the present invention provides a method of conducting digital transactions using a digital transaction apparatus including a plurality of Logical Digital Transaction Document Packets (LDTDPs), each LDTDP representing a digital transaction document and including one or more of a unique Identification (unique ID) or a token associated with the unique ID for performing a digital transaction with at least one digital transaction device, the digital transaction apparatus further including, an LDTDP storage memory, a staging memory, a DAD, and a DTC, including a Digital Transaction Processing Unit (DTPU) and a secure record memory, the method including, operating the DAD to select one of the at least one LDTDPs stored in the LDTDP storage memory, copying the selected one LDTDP from LDTDP storage memory to staging memory, and copying the selected one LDTDP from staging memory to the secure record memory thus enabling the DTC to be operable as the digital transaction document associated with the selected one LDTDP. In other embodiments, a method of conducting digital transactions using a digital transaction apparatus that recognises a plurality of LDTDPs is provided, each LDTDP representing a digital transaction document and including one or more of a unique ID or a token associated with the unique ID for performing a digital transaction with at least one digital transaction device, the digital transaction apparatus further including, an LDTDP storage memory, a staging memory, a DAD, and a DTC, the DTC including a DTPU having a secure record memory, the method including, operating the DAD to select one of the at least one LDTDPs stored in the LDTDP storage memory, copying a selected one LDTDP from LDTDP storage memory to staging memory, copying the selected one LDTDP from staging memory to the secure record memory thus enabling the DTC to be operable as the digital transaction document associated with the selected one LDTDP. In these embodiments, the known operation of the existing DTPU, such as an EMV device, is exploited to place data pertaining to a particular personality in the memory location that will be accessed by the EMV device to establish the personality of the DTC.

[0046] In various embodiments, the digital transaction document may be a credit card, debit card, bank account, store card, passport, identity card, age verification card, loyalty card, government agency card, driver's license, and/or various other kinds and types of digital transaction document, which would be typically implemented as cards, documents or booklets, or implemented electronically. It will be understood that in this specification the term "logical" refers to a set of characteristics for each of the digital transaction documents, and those characteristics may be in part, or all, contained in an LDTDP representing the document or logical document. The characteristics may include data such as a unique ID for the digital transaction document, ownership information and expiry dates. The unique ID information may be a unique ID number. A change in the DTC parameters adopted by the DTPU from expressing one digital transaction document to expressing another digital transaction document may also be referred to as a change in the DTC "personality". In addition to changing parameters in a DTC such that it adopts a personality for the purpose of future transactions, in one particular embodiment, the DAD is operable to receive data pertaining to new personalities by accessing a website and is further operable to transmit relevant data/instructions to the DTC to adopt the personality of the newly acquired personality obtained by the DAD.

[0047] In embodiments, an LDTDP may include the unique ID and a token associated with the unique ID, the unique ID and token both associated with the digital transaction document represented by the LDTDP. In other embodiments, the LDTDP may include only the unique ID associated with the digital transaction document. In yet other embodiments, the LDTDP may include only the token associated with a particular unique ID, the unique ID (and, therefore, the token) associated with the digital transaction document. [0048] In some embodiments, each of a number of digital transaction documents may be associated with a single unique ID and a single token associated with the unique ID, each of some other digital transaction documents may be associated with a single unique ID and a number of different tokens associated with the unique ID, and each of yet other digital transaction documents may not be associated with any token (in which case such a digital transaction document will be associated only with a unique ID). In these embodiments, the unique ID and/or token for a digital transaction document (or logical digital transaction document) will be contained in an LDTDP. Where a document has a number of associated tokens, each token or token/unique ID pair, may be in a separate LDTDP. In embodiments, the unique ID for the digital transaction document contained in the LDTDP may be a Personal/Primary Account Number (PAN) if the document is a credit/debit type card, or similar kinds of unique IDs, such as unique alphanumeric ID's or unique names.

[0049] In some embodiments, the at least one of the plurality of LDTDPs is stored on the DAD, wherein the LDTDP storage memory is located on the DAD. In other embodiments, the at least one of the plurality of LDTDPs is stored in LDTDP storage memory located on the DTC, wherein selection of a LDTDP through the DAD is effected by an icon, name or other indicator associated with the LDTDP, although the LDTDP is not itself stored on the DAD. In this example, the selection of the LDTDP is communicated to the DTC by data indicating which LDTDP has been selected, and the DTC implements the selected LDTDP from its LDTDP storage memory based on the indicative data.

[0050] In yet other embodiments, a part of each of the at least one of the plurality of LDTDPs is stored on the DAD. Another part of each corresponding at least one LDTDP is stored on the DTC, wherein the selection is based on the part stored on the DAD. The part of the LDTDP selected is transmitted to the DTC, and the determination of which part of the LDTDP matches the selected part is made on the DTC. In this way, the two parts of the LDTDP can be combined to form the whole LDTDP, which can then be implemented by the DTC. In such an embodiment, the LDTDP storage memory is split between the DAD and the DTC.

[0051] In an embodiment, the DAD is enabled to store and provide for selection of an LDTDP, which is implemented as a digital transaction document on the DTC. The selection of the document associated with an LDTDP (or selection of the LDTDP) may occur before selection of a token associated with the LDTDP. Where a document has only one associated token, the selection of the document may be selection of the associated token, since a further selection process is not required. In some embodiments, selection of a token automatically indicates which LDTDP is to be selected, since the token is associated only with one document (or one LDTDP). [0052] In another embodiment, the user may select an LDTDP and a predetermined token is selected based on context determined by the DAD. For example, if the DAD determines different locations, then a token can be automatically selected based on the determined location.

[0053] In various embodiments, some digital transaction documents contained in an LDTDP will have only one associated token and other digital transaction documents will have multiple associated tokens. It will be understood that embodiments described in this specification include both options, unless otherwise stated or unless the inclusion of both options results in an embodiment that is not possible to implement.

[0054] In various embodiments, some identifying information in respect of a digital transaction document contained in an LDTDP will not need to be stored in the apparatus LDTDP storage memory (either in the device memory or the card memory) since the token(s) stored in the apparatus will be sufficient to identify its (their) associated digital transaction document(s). For example, where the digital transaction document is a credit card, the card number (the PAN) is not contained in the LDTDP and instead, the tokens associated with the credit card are sufficient to identify the particular credit card. In such an example, the credit card PAN may include the typical 4 leading digits which identifies the card as being of a certain type or brand (MasterCard, Visa, etc.). A token for the particular credit card may have the same four leading digits, but with different remaining digits, so that the token identifies the card with which it is associated. It will be understood by skilled readers that not having a PAN, for example, contained in the respective LDTDP and stored in the apparatus LDTDP storage memory (either in the DAD memory or the DTC memory) should increase security for the associated digital transaction document. In such examples, only the digital token containing LDTDPs are selected by the DAD, with the associated digital transaction document being automatically identified and selected.

[0055] In one embodiment, the DTPU CPU operates to copy data from the staging memory (staging area) to the EEPROM, or a part of the EEPROM, which has been set aside for secure record memory (secure element). In other embodiments, the DTPU CPU operates to copy part of the data from the staging memory to a part of the EEPROM, which has been set aside for secure record memory, and another part of the data to part of the EEPROM which has not been set aside for secure record memory. When, for example, an LDTDP is copied into secure record memory (secure element), the DTPU uses the digital transaction document information from the LDTDP (unique ID, token, commencement date/time, expiry date/time, etc.) to attain a personality, such that the DTC operates as the associated digital transaction document with the document's associated characteristics, such as commencement date/time, expiry date/time, etc.

[0056] It will be understood by skilled readers that a particular digital transaction document may be represented by one or more LDTDPs. For example, a digital transaction document associated only with a unique ID will be represented by a single LDTDP including that unique ID. In this example, the LDTDP being copied to secure record memory (which may be referred to as a secure element, or a secure element area) causes the DTC to operate as the digital transaction document associated with the unique ID.

[0057] In another example, a digital transaction document associated with a unique ID and a single token may be represented by a single LDTDP including the unique ID and the token. In this example, the LDTDP being copied to secure record memory (secure element) causes the DTC to operate as the digital transaction document associated with the tokenized unique ID. Alternatively, a digital transaction document associated with a unique ID and a single token may be represented by two LDTDPs, one of which includes the unique ID, the other including the token. In this alternative example, the LDTDP including the unique ID being copied to secure record memory (secure element) causes the DTC to operate as the digital transaction document associated with the unique ID (untokenized), whereas the LDTDP including the token associated with the unique ID being copied to secure record memory (secure element) causes the DTC to operate as the digital transaction document associated with the tokenized unique ID.

[0058] In yet another example, a digital transaction document associated with a unique ID and multiple tokens may be represented by various LDTDPs including both the unique ID and one of the multiple tokens, or could be represented by one LDTDP containing the unique ID, and a number of other LDTDPs, each containing one of the multiple tokens associated with the unique ID associated with the digital transaction document represented by all the LDTDPs, wherein the one of the LDTDPs being copied to secure record memory causes the DTC to operate as either the digital transaction document associated with the tokenized unique ID, or the digital transaction document associated with the untokenized unique ID.

[0059] Other arrangements for the LDTDPs may be contemplated, depending on the nature of the digital transaction document represented by the LDTDP (or LDTDPs).

[0060] In some embodiments, an LDTDP may also contain further data associated with a digital transaction document, such as an expiry date for the document. It may also be desirable in some circumstances to have multiple expiry dates in an LDTDP, for example, one expiry date for the unique ID (or for the associated digital transaction document) and another expiry date for a token associated with the unique ID. It will be understood that, where a digital transaction document has a number of associated tokens, each token may have a different expiry date, which will be contained in the respective LDTDP.

[0061] Further, the LDTDP for some digital transaction documents may include a commencement date, so that the period between commencement of validity and expiry of validity of the document (and/or one or more tokens associated therewith) can be controlled. For example, it may be desirable to have the digital transaction document valid for only one day if the document is a door pass, or some other card or pass, with a short validity requirement. Moreover, the commencement and expiry in the LDTDP could include times as well as dates for finer control of the validity period of the digital transaction document (and/or one or more tokens associated therewith).

[0062] In other embodiments, the further data contained in an LDTDP may include a security code associated with the unique ID of the document, and may also include a number of other different security codes associated with one or more tokens also contained in the LDTDP. For example, where the digital transaction document is a credit card, the security codes may be Card Verification Value 2 (CVV2) security codes, or similar. In this example, the unique ID is a PAN, which has an associated CVV2 security code, and the PAN has, perhaps, five associated tokens, each token also having an associated CW2.

[0063] In yet other embodiments, the LDTDP may contain a Personal Identification Number (PIN) for the digital transaction document. There may be one PIN associated with the unique ID of the document, and other (different) PINs, each associated with a token. In some embodiments, the PINs could be One-Time PINs (OTPs), which expire after being used for a single transaction. In other embodiments, the PINs may have a limited period of validity, for example, expiring one week after first use.

[0064] In other embodiments, the LDTDP may contain other data, such as name, date-of- birth, physical characteristics, and other personal data of a person who owns the digital transaction document. For example, if the digital transaction document is a passport, for certain transactions an LDTDP containing the passport unique ID and eye color of the owner may be desired for authentication and/or verification in such transactions.

[0065] The LDTDP may be described as including, containing, wrapping or embodying a unique ID, token and/or other data. Further, the LDTDP may be encrypted (or otherwise secured) to protect the data contained in the LDTDP. In yet other embodiments, the LDTDP may be secured by using a public/private key infrastructure. The public and private keys may be issued by, for example, the DTC's primary issuer. Alternatively, the public and private keys may be issued by a primary issuer of an LDTDP, for example, a credit card provider.

[0066] In some embodiments, the DTPU may include a System Input/Output (System I/O) for inputting and outputting data and/or encrypted data to and from the DTPU. The System I/O is a means by which the LDTDP can be copied into secure record memory (secure element), allowing the DTPU to operate with the personality of the logical digital transaction document contained in the LDTDP. The secure element could be located on one or more devices. It could also be located in a single device with a virtual partition, or a folder.

[0067] The DTPU may also include a processor, or Central Processing Unit (CPU), which operates to control the DPTU. Further, the DTPU may include a crypto-coprocessor for encrypting and decrypting data efficiently, thus allowing the DTPU CPU to operate more efficiently without having the burden of encryption and decryption tasks. In some embodiments, the DTPU CPU and crypto-processor co-operate to decrypt (unwrap, unpack, or otherwise deal with) a selected LDTDP, before or while being stored in secure record memory, such that the DTPU can operate with data from the LDTDP.

[0068] The DTPU may also include various different types of memory, such as Read Only Memory (ROM), Random Access Memory (RAM), and Electrically Erasable Programmable Read Only Memory (EEPROM). In some embodiments, one of the types of memory can be used for the secure record memory (also known as a secure element), with one of the other types of memory used for the staging memory (which may also be referred to as a staging area). Any one of the abovementioned types of memory could be used as LDTDP storage memory.

[0069] In some embodiments, the DTPU is an EMV device, or a device that conforms with one or more EMVCo specifications. In other embodiments, the DTPU is an EMV device (otherwise conforming to one or more EMVCo specifications), which is constructed to read a secure storage area (staging memory/staging area) for the purpose of establishing the personality of the card in which the DTPU is installed. The secure storage area, or staging memory, may be within the constructed EMV device, within the constructed EMV device storage area (memory), or within some other secure memory.

[0070] In embodiments, the CPU of the DTPU and/or a CPU that is external to the DTPU but resident within the DTC (referred to as an external DTC processor) is activated only after the CPU or the external CPU securely identifies itself to a linked DAD, such as a smartphone. In some embodiments, linking between the DAD (for example, a smartphone) and the DTC uses strong encryption for the ID and transfer of data. Links may be unique to each set (smartphone and DTC).

[0071] In embodiments, the linking between the DAD and the DTC is wireless, and may be formed using respective transceivers of the DAD and DTC. In yet other embodiments, the DTC is linkable" (i.e. operable to establish communications) with the DAD using a physical connection, such as a data cable. In such embodiments, the data cable may be adapted at one end to plug in to a communications port, such as a USB port, on the DAD, with the other end adapted to clamp or clip on to a part of the DTC. The DTC may have electrodes, or metal plates at or towards an edge thereof to connect with the cable when clamping or clipping the other end of the data cable to the DTC. In some embodiments, the respective transceivers for the DAD and the DTC may be suitable for Bluetooth™, Low Energy Bluetooth™, Wi-Fi, NFC, ANT+, or other types of contactless, or wireless communication transceivers. In embodiments, the DTC may include a button, or a similar device, to activate linking with the DAD.

[0072] In various embodiments, the DAD is operable to transfer data to the DTC without the formation of a direct link between the DAD and DTC. In such embodiments, the DAD is used to transfer data, for example, via the internet to a (cloud) connected third party device. A link between the DAD and the third party device for the data transfer can be temporary, and that link can be terminated once the data has been completely transferred. The third party device is connected, for example, to a network (perhaps via another third party, such as a payment processor), which enables the third party device to form a link and communicate with a digital transaction system device, such as a Point Of Sale / Electronic Funds Transfer at Point Of Sale (POS/EFTPOS) terminal or Automatic Teller Machine (ATM), subsequent to forming a link with the network and thence to the digital transaction system device. The third party device is enabled to transfer the data previously received from the DAD to the digital transaction system device. A holder of a DTC (which may be a person different from the owner and/or operator of the DAD) can take the DTC to the digital transaction device, and by insertion, or placing the DTC proximal to the device, the DTC holder can obtain data from the digital transaction system device. In this way, data from the DAD can be transferred indirectly and asynchronously to the DTC. This indirect data communication between the DAD and the DTC can also be reversed such that the DTC indirectly and asynchronously transfers data to the DAD, perhaps using the same infrastructure of the digital transaction system device, the network including the payment processor, the third party device and the internet. It will be recognised that the indirect and asynchronous data transfer may be useful where a first person has a DAD and wants to send data to a DTC in the control of a second person who is geographically remote from the first person. For example, a mother operating her DAD may prefer to increase spending limits of a DTC operated by her son who is travelling in a foreign country.

[0073] In embodiments, the external DTC CPU controls the reading and re-reading of the DTPU (for example, an EMV device), and updating the memory contents of the DTPU.

[0074] In embodiments, a DTC includes a wearable payment device such as a watch but also includes payment devices that are incorporated into pieces of jewellery such as finger rings, bangles and pendants. The DTC could also comprise an implantable payment device, which includes chip and transceiver arrangements which may be suitably configured for subcutaneous implantation. [0075] In other embodiments, the DAD may be a smartphone, or another suitable device such as a fob, or key fob, or a portable processing device with an internal/external wireless communications capability such as an NFC reader/writer which is configured to operate as a DAD. In some embodiments, the DAD may be, or may include a wearable device, such as a watch or other piece of jewellery. In this regard, some smartphones presently operate with wearable wrist (or watch-like) devices. It is envisaged that future smartphones may be wholly incorporated into a wearable device, and that the DAD can be such a device. In the circumstance that the DAD includes a smartphone operating with a wearable wrist (or watch-like) device, the wearable component may have its own unique ID, which can be used for securing linking and data transfer between the DAD and the DTC in cooperation with unique IDs, respectively, for a smart phone and the DTC.

[0076] In other embodiments, the DAD (smartphone), after securely connecting to the DTC, uploads correctly formatted data in an LDTDP to the nominated secure storage area (staging memory or staging area) and then transmits an instruction to either the DTPU CPU or the external DTC CPU to check if the nominated storage area contains the data in a specified format (e.g. a compliant LDTDP). If the data satisfies the specified format requirements and passes various checks, the DTPU CPU or the external DTC CPU copies or moves the data (LDTDP) to a specified area (secure record memory/secure element) within the DTPU (for example, within the EMV device). The DTPU CPU or the external DTC CPU then transmits an instruction to the DTPU (EMV device) to read the data (LDTDP) within the secure record memory and act according to the data (express the LDTDP as the associated digital transaction document) contained within this secure record memory (secure element). The DTPU CPU or the external DTC CPU can be programmed to search for specific headers and/or other data identifiers within a range of parameters before acting. In other embodiments, it is possible to copy all records of all LDTDPs to the staging memory, and to use an index to reference the selected LDTDP from those records. Copying all records in this manner reduces the requirement to write to and/or read from the staging memory, and therefore reduces risks of accessing that memory area, including security risks.

[0077] In some embodiments, the secure record memory (secure element) is located in the DTPU, the staging memory (staging area) is located external to 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 record memory (secure element) could be located within the external CPU on the DTC. Further, the LDTDP storage memory and/or the staging memory (staging area) could be located outside of the DTC, for example, as additional memory located on the DAD. Whilst the secure record memory (secure element) could be located outside of the DTPU, this arrangement could be considered less secure than locating the secure record memory within the DTPU. However, any security concerns could be mitigated by encrypting any data in a secure record memory located outside the DTPU. In yet other embodiments, the LDTDP storage memory could be located elsewhere other than the DAD or the DTC, and, for example, the LDTDP storage memory could be located in a cloud based storage system, or could be located on portable memory, which can be accessed from the DAD.

[0078] In embodiments, the DTC includes a card transceiver. In other embodiments, the DTC includes a Graphical User Interface (GUI) for displaying data associated with the digital transaction document or token associated with the selected or implemented LDTDP. For example, if the logical digital transaction document is a credit card, the GUI on the DTC may display the PAN, the selected token associated with the selected LDTDP containing the logical digital transaction document, the card brand logo, the expiry date of the credit card, and may also display a virtual, or mimicked, hologram of the credit card brand. In another embodiment, the DTC may only display the selected token, including the expiry data and/or the CVV2, and not the associated PAN. The DTC may also include a real hologram displayed somewhere on its surface.

[0079] The external DTC CPU (or external processor) may control operations external to the DTPU and/or control reading/writing and other input/output operations with the DTPU via the DTPU system I/O. The external DTC CPU may also accommodate security tasks external to the DTPU, and/or control the GUI. In some embodiments, the external DTC CPU may include firmware that is operable to write data (for example, LDTDP data) to staging memory, such that, when the DTPU is activated, the DTPU copies the data to secure record memory (secure element) in the DTPU. In embodiments, the firmware on the external DTC CPU may be updated and the DTC is provided with means for enabling firmware updates. The updates may include firmware that extends functionality of the DTC and any programs and/or applications running thereon. The updates may allow for correction or amendment of existing firmware functions that have been identified as faulty or sub-optimal. Other firmware updates may be issued to improve or extend security, or secure functioning of the DTC. The ability to update firmware may be contrasted with, for example, existing credit or debit cards using EMV devices, where there is no, or limited, ability to update the EMV firmware. Presently, firmware is "updated" by replacement of a credit card or debit card when it expires. In the circumstances that the DTC has a relatively long operational life, for example, 5 years or more, updating firmware during the operational file of a DTC enables the functionality of the DTC to be improved or enhanced without requiring return of the DTC to an issuing authority.

[0080] In embodiments, the DTC may only form a communications link with one DAD to the exclusion of all other DADs representing a secure communications link and transmission of data between the DAD and the DTC by respective transceivers (the DTC transceiver and the DAD transceiver). In some embodiments, the link is a secure/encrypted link. In other embodiments, each DAD may be linked with multiple DTCs. However, in this embodiment, each DTC may link with only one DAD, to the exclusion of all other DADs.

[0081] In embodiments, the linking between the DTC and the DAD may be implemented by using a unique identifier for the DTC and another unique identifier for the DAD. In some embodiments, the linking of the DTC and the DAD may occur (at least partially) before the DTC is sent to a user. For example, the linking may be implemented by a DTC issuer, including a bank, a card issuing facility, a card "personalization" facility, or other type of third party institution capable of implementing a "partial" linking. In one example, a partial linking may be implemented by the DTC issuer establishing the DTC and providing an application ready for download by a user to the user's DAD (for example, a smartphone), wherein activating the application causes the smartphone to search for, and link to, the DTC issued to the user. In other embodiments, the linking may be implemented by the user, and may occur when the user receives the DTC.

[0082] In some embodiments, the linking between the DTC and the DAD is permanent, or semi-permanent, and cannot be unlinked, or re-linked without permission and required action from, for example, one of the previously-mentioned third parties. For example, to unlink a DTC and the DAD uniquely linked to it, a unique code may be entered on the DAD and uploaded to the DTC. This will reset the DTC to a default state. In the default state, the DTC could "look" for a new specified unique identifier for a different DAD (for example, an IMEI number, or another suitable unique ID, of a smartphone). This unlinking/re-linking may be useful when the user replaces their DAD, such as a smartphone. In yet other embodiments, the linking may be temporary, and performed by the user. For example, a user may form a link a short time before an intended transaction is to occur, and, may unlink after the transaction is completed and at a predefined short duration after the transaction.

[0083] In an embodiment where the DTC and the DAD are dynamically linked (that is, linked by the user at a chosen time), the linking and selecting of the desired LDTDP from the DAD can occur in any order.

[0084] In embodiments, in order to have secure communication between the DTC and the DAD, the security may be implemented by linking the transaction card and the DAD, or the security may be implemented for data transmission between the transaction card and the DAD. In other embodiments, the security may be implemented for both the linking and the data transmission.

[0085] In some embodiments, the DTC includes a battery or capacitor to provide electrical power for memory storage. For example, embodiments of the card may include non-static type memory storage or, some form of powered transceiver, such a as Bluetooth™ transceiver. A battery can also be used to power the DTC to process encryption, and for changing the LDTDP containing the digital transaction document and/or digital token expressed by the DTC by implementing changes in the LDTDP containing the logical digital transaction document and/or the associated digital token.

[0086] In some embodiments, the DAD includes a processor, a user interface, a device transceiver and device memory. In various embodiments, the DAD may be a smartphone, computer tablet, laptop, Personal Computer (PC), fob device, or other suitable equipment capable of operating to allow a user to select an LDTDP and transmit data representing that selected LDTDP. The DAD may also be a custom built device suitable for the purpose. In other embodiments, the DAD may be a wearable device, such as a smart watch, or could be enabled to operate with such a wearable device. In embodiments where the DAD has a user interfaces capable of displaying images, the user interface may display a Scheme logo along with the name or other alphanumeric indicator of a personality. In the instance of a credit card, the display of a Scheme logo on the DAD user interface should appease Scheme providers who would otherwise prefer a physical card displaying that logo permanently.

[0087] In an embodiment, a selection is made from the user interface, which may include selecting from a touch activated screen, for example, on a smartphone. The touch activated screen may operate by displaying lists, drop-down lists, or other screen designs, or may employ icons on the screen. In an alternate embodiment, the user interface may be a simple display with buttons, for example, on a fob, or a key fob. Where the DAD is a PC or laptop, it may employ a screen and keyboard to provide a user interface. However, the DAD is generally preferred by users to be a portable device. On the DAD screen, an LDTDP may be represented symbolically with an icon relevant to the associated (logical) digital transaction document, or could use names or nicknames for the LDTDP. The names or nicknames could be assigned by the user, or a service provider.

[0088] For example, the document might be a MasterCard credit card and the LDTDP associated with the MasterCard may be represented on the DAD screen by a MasterCard logo. Additionally, or alternatively, the LDTDP may be represented by a combination of icon and alphanumeric information. For example, where a MasterCard has one or more associated tokens, each token contained in a separate LDTDP, the LDTDP for each MasterCard token may be represented on the DAD screen by the MasterCard logo and at least a part of the respective token number.

[0089] In various embodiments, the digital transaction devices may include POS/EFTPOS terminals, ATMs, internet connected computers or personal computers, and other such electronic devices. The digital transaction device may also include infrastructure such as a telephone and call centre enabled for Mail Order/Telephone Order (MOTO) type transactions.

[0090] In embodiments, the DTC and the digital transaction device may interface with each other by various methods. In some embodiments, the interface may be effected by insertion of the DTC into the digital transaction device. In other embodiments, the interface between the transaction card and the transaction device may be effected by Near Field Communication (NFC), wherein the card and/or the device each have a transceiver and antenna for communication. In yet other embodiments, the DTC may include a magnetic stripe, wherein the digital transaction device includes a magnetic stripe reader. In yet other embodiments, the DAD may include a transceiver configured for communication with the digital transaction device, so that transactions can optionally be made directly through the DAD. In yet other embodiments, the DTC is configured to be inserted into a POS/EFTPOS terminal, or an ATM, and is approximately the same size as a credit/debit card.

[0091] In further embodiments, the DTC may have a magnetic stripe, and the DAD may have a magnetic stripe reader and/or writer.

[0092] In an embodiment, the DTC may be adapted to express a default "Null" personality, wherein the data in place of an LDTDP containing a logical digital transaction document requiring unique identification could be a predetermined series of digits, for example, all zeros. In one example, where the logical digital transaction document represented by an LDTDP is a credit card, the unique identification may be the credit card PAN or an associated digital token, and setting the DTC back to expressing a Null personality is performed by over-writing or replacing the PAN or the associated digital token with all zeros. This may occur by writing to the staging memory and copying into the secure record memory, or by having the DTPU itself write into secure record memory (secure element).

[0093] In an optional embodiment, the DTC may be configured to store an LDTDP for an associated logical digital transaction document and/or associated digital tokens for a chosen period. The period may be predetermined by the issuer of the DTC and/or issuer of the digital tokens (which may be a different issuer to that of the DTC). Alternatively, the storage period may be chosen by the user. In other variations, the period may be dynamically selectable, and could be chosen by the user for each transaction, or for each selection and storage of a single LDTDP for an associated logical digital transaction document and/or associated digital token(s) on the DTC. In other embodiments, the storage period for the LDTDP for an associated logical digital transaction document and/or associated digital token(s) on the DTC could be determined based on the LDTDP selected, the transaction type, or both. [0094] In yet another embodiment, the DTPU of the DTC is configured to store/express the personality associated with only one LDTDP containing a logical digital transaction document and associated digital token(s) at any particular time. In this regard, to change the LDTDP in the DTPU, a user must overwrite or delete a previously-stored/expressed LDTDP containing a logical digital transaction document and its associated token(s) if there is one embodied in the DTC at that time. In another embodiment, the card may be configured to store/express more than one LDTDP (containing a logical digital transaction document and the associated token(s) for each document) concurrently.

[0095] In another embodiment, the DTC and its DTPU may be configured to store and/or express an LDTDP associated with a primary logical digital transaction document and its associated token(s), and one LDTDP associated with a secondary logical digital transaction document and its associated token(s). In yet another embodiment, the DTC and its DTPU may be configured to store and/or express one LDTDP associated with a primary logical digital transaction document and its associated token(s), and one or more LDTDP associated with secondary logical digital transaction documents and associated token(s) for each. The LDTDP associated with the primary logical digital transaction document and its associated token(s), in some embodiments, may be stored permanently on the DTC in its DTPU, with the one, or one or more, LDTDPs associated with secondary logical digital transaction documents and the associated token(s) for each being temporarily stored on the DTC in its DTPU. In yet other embodiments, the one, or one or more, LDTDPs associated with secondary logical digital transaction documents and the associated token(s) for each may be permanently stored and/or expressed on the DTC in its DTPU and referenced by a code stored on the DAD.

[0096] In yet other embodiments, the DAD may include an e-wallet, which can be configured to operate with one or more of the LDTDPs containing logical digital transaction documents and associated token(s) stored on the DAD. This arrangement can be used to top up funds where the associated digital transaction document is a debit card or a credit card. Further, the DAD may include functionality to allow a user to view transactions that are completed with the DTC (or by other means, such as online transactions) in real time. This may allow the user to monitor all transactions made by all LDTDPs associated with digital transaction documents in the apparatus (which may include a plurality of DTCs linked or linkable with the DAD) in, a single screen or with a single smartphone application. Further, the user could be shown the associated digital token that was used for a transaction. This may further allow the user to cancel, stop, pause or otherwise appropriately deal with one or more digital transaction documents if the user detects or perceives that one or more digital transaction documents have been misused or fraudulently used. The apparatus could also be adapted to allow the user to cancel, stop, pause or otherwise appropriately deal with one or more digital transaction documents on a token-by-token basis, so that only certain tokens associated with a document are disabled, but the document is still useable with other associated tokens. The user could also cancel, stop, pause or otherwise appropriately deal with one or more logical digital transaction documents if the user seeks to limit, for example, spending, or other financial or non-financial transactions occurring with one or more logical digital transaction documents. This may also be performed on a token-by-token basis.

[0097] In another embodiment, the DAD may be enabled to receive alerts for the user when a transaction, or a selected category or type of transaction, is conducted using the DTC. For example, the DAD may alert the user that an LDTDP containing a digital transaction document, such as a passport, has been used for identification at an airport. Further, the alerts can be implemented on a token-by-token basis. In another example, the DAD may alert the user that a credit card has been used to purchase services such as a taxi ride, not included in a list of authorized transaction categories, such as purchases of fuel and groceries, selected by the user.

[0098] In other embodiments, the DAD and/or the DTC may be configured to allow a user to classify transactions into categories. The categories could be predefined and/or defined by the user. The categorization could be configured in order to allow the user to monitor and/or limit transactions, such as spending with credit within that category. A category may be related to only one LDTDP and associated (logical) digital transaction document, or could be related to a number of LDTDPs and respective associated (logical) digital transaction documents. Tokens can also be used for categorization of transactions using the one LDTDP and associated digital transaction document.

[0099] In yet another embodiment, the DAD may be configured to allow the user to transfer funds to another user who has a DAD. The transfer may be limited to same or similar LDTDPs and associated (logical) digital transaction document types, and could be limited in amount. In a further embodiment, the DTC could be configured to transfer funds to another DTC (owned by the user or owned by another user), or to another DAD (owned by the user or another user).

[0100] Furthermore, in another embodiment, third parties, such as financial institutions, police, customs, government, employers, spouses, parents and other interested parties could be authorized and enabled to cancel, stop, pause or otherwise appropriately deal with (including temporary suspension) one or more LDTDPs containing logical digital transaction documents in the apparatus or selected token(s) associated with the document. This may be useful, for example, if a user has a gambling addiction, and prefers to have a third party monitor and prevent access to credit cards, debit cards, bank accounts or other kinds of financial logical digital transaction documents in order to prevent the user from excessive gambling. In the instance of an attempted fraudulent transaction and cancellation/re-issuance of a logical digital transaction document, the user may be provided with alerts advising the cancellation of a document and the availability of a replacement document for collection/download to a user's DAD and subsequent use to effect a transaction with a DTC adopting the personality of the newly issued (replacement) document.

[0101] In other embodiments, the DAD may be configured to store data representing loyalty points, frequent flyer points, or other associated transaction related documents, attached to a (logical) digital transaction document contained in an LDTDP, or plurality of (logical) digital transaction documents contained in respective LDTDPs. The DAD may also be enabled to update loyalty points, frequent flyer points and other associated transaction related documents during or after a transaction, or at other times. For example, loyalty points may be used during a transaction to reduce the cost of an item to be purchased using the DTC and the DAD. The DAD may also be enabled to add loyalty points, frequent flyer points and other associated transaction related documents if a user visits a particular shopping store, or is in a predetermined proximity of the store. In some embodiments, the loyalty points, frequent flyer points and other associated transaction related documents may be contained in an LDTDP as further data associated with the relevant (logical) digital transaction document and/or associated tokens.

[0102] In yet another embodiment, if the DTC includes an LDTDP containing a primary logical digital transaction document, for example, permanently stored and/or expressed on the DTC in the DTPU, the primary logical digital transaction document may be a false or fake logical digital transaction document, such that data copied from the DTC or DTPU where only the primary logical digital transaction document is stored on the DTC or DTPU will be useless for any digital transactions. Alternatively, the primary logical digital transaction document may be represented by a unique ID that is incomplete, expired or all zeros, such as a Null ID. For example, where the primary digital transaction document is a credit card, the PAN of the card could be incomplete, expired or all zeros. In this embodiment, only LDTDPs containing secondary logical digital transaction documents stored on the DTC and/or in the DTPU will be real and useable for a digital transaction when embodied on the DTC via the DTPU as a digital transaction document. Further, an LDTDP containing a secondary logical digital transaction document and its associated digital token(s) may be stored or embodied as a tokenized digital transaction document on the DTC and/or expressed in the DTPU for only a short period, for example, five minutes, in order to reduce the risk of theft of data representing the digital transaction document and token. This arrangement reduces the risk that an unauthorized user can emulate the associated digital transaction document and token. Alternatively, the LDTDP containing the primary logical digital transaction document stored on the DTC and/or expressed in the DTPU may comprise incomplete data, rendering the DTC/DTPU unusable for digital transactions until a user downloads and saves secondary data to the DTC/DTPU (along with associated token data), to render the primary logical digital transaction document complete and useable for digital transactions. [0103] In yet another embodiment, each LDTDP or a sub-set of LDTDPs stored on a DAD may have a PIN associated therewith (or contained therein). The PIN may be a static PIN, or could be a dynamically generated PIN. In other embodiments, the PIN may be displayed on the user interface of the DAD. Access to the PIN to display on the screen of the DAD may be by secured methods, such as finger swipe or other such security methods such as those commonly implemented on smartphones. In another embodiment, the DAD may be configured to allow the user to update a PIN for a particular LDTDP or for a number of LDTDPs. In embodiments, PINs could also be associated with particular tokens for a document in an LDTDP, such that each token for the document has a different PIN.

[0104] In an embodiment, the method includes operating the activated DTC with the digital transaction device to perform the digital transaction.

[0105] In some embodiments, tokens are provided for an LDTDP associated with a primary logical digital transaction document before the DTC is issued to a user. The tokens can be sent to the DAD through a secure network so that a token can be selected for a transaction with the associated LDTDP for the logical digital transaction document (already stored on the DTC or in the DTPU at issuance) at the time of a transaction. Alternatively, the tokens associated with the primary document could be loaded onto the DTC or DTPU at issuance, with selection effected by the DAD at the time of a transaction. Secondary logical digital transaction documents (optionally contained in LDTDPs) may be issued to the user through a secure network means to the DAD after issuance of the DTC, and the associated digital tokens for each secondary document can be issued with the associated secondary document (also optionally contained in the respective LDTDPs).

[0106] In yet another embodiment, tokens contained in one or more LDTDPs can be a fixed or extendible pool, which are used in a cyclical manner, with a next token selected in order. Alternatively, tokens could be selected from the pool randomly (or pseudo-randomly). In a further embodiment, tokens could be one use only, with a pool of used or expired tokens replaced when every token in the pool has been used or expired. It is also possible that the pool of tokens is replenished in advance of every token being used or expired, for example, when there are ten unused or unexpired tokens remaining in the pool, the user could be alerted to the need for token replenishment. It will be understood that single use tokens can improve security for an associated digital transaction document (and its containing LDTDP), and for the transactions. In another embodiment, the user could choose when to replace tokens in the token pool. In this embodiment, the user could request a new pool or an extension of their existing pool of tokens from a token provider. The new tokens could be provided already contained in respective LDTDPs for storage in LDTDP storage memory. [0107] In a further embodiment, a primary user of a given digital transaction document could assign tokens to a secondary user of that document. For example, a primary credit card holder could assign token(s) from a token pool to a subsidiary holder of that credit card. This may be used as a way to control the spending of the subsidiary credit card user to limits, amounts or categories of spending.

[0108] In yet other embodiments, where tokens are assigned for usage in only certain transaction types, a third party, such as a token issuer, government agency or other controller of token usage, has authority to allow issuance of only tokens for selected transaction types. In one example, the authority controlling issuance of tokens may only allow tokens to be issued for a credit card that are for non-gambling expenditure.

[0109] In some embodiments, the tokens are generated only by a third party provider who issues the tokens to users (optionally already contained in respective LDTDPs). The tokens may also be issued by another third party provider in other embodiments. Alternatively, in an embodiment, the tokens may be generated locally by the user, for example, by the DAD and stored into the LDTDP storage memory contained in LDTDPs. The locally generated tokens could be securely copied to a third party to be matched during a transaction to thereby authorize the transaction. A cryptogram may be created containing a token, along with one or more of the associated document's unique ID, expiry date, unique ID of the DAD, time, date, location, and various other random, pseudo-random or non-random inputs. A cryptogram may also be created using, for example, a public key from the DTC, a public key from the LDTDP (for example, if it is a credit card LDTDP), and/or a public key from the digital transaction device (for example, a POS/EFTPOS terminal). The cryptogram may also be created using public keys from other sources. A cryptogram created using one or more public keys will contain the one or more tokens, and other IDs and data.

[0110] Although various security and convenience benefits are evident to a skilled person upon reading the specification with one or more arrangements according to embodiments of the invention, to the present time there has not been a sufficiently effective, efficient, and/or secure means and/or method for adapting a DTPU (such as an EMVCo specified device) to embody different personalities as compared with the personality of the DTPU that was initially installed.

[0111] Although a modification to the essential operating firmware of a certified EMV device causes the device to lose its certification credentials, it remains possible to implement an embodiment of the invention with a firmware modification to an existing certified EMV device. Of course, once the firmware has been modified, re-certification of the device with the modified firmware is required before the device could be used. [0112] In this embodiment, the firmware of an existing EMV device is modified to enable the EMV device to receive and execute an increased set of commands from an external network transaction device (such as an ATM or EFTPOS device (or a device initiating a network transaction device)) that enables the secure memory of the EMV device to be modified.

BRIEF DESCRIPTION OF THE DRAWINGS

[0113] For a better understanding of the invention, and to show how it may be performed, optional embodiments thereof will now be described by way of non-limiting examples only and with reference to the accompanying drawings in which:

[0114] Fig. 1 is a diagrammatic representation of an apparatus in accordance with an embodiment of the invention, including an embodiment of a Digital Transaction Card (DTC) and an embodiment of a Data Assistance Device (DAD) in the form of a smartphone, wherein the apparatus is being used for a transaction with a digital transaction device, in this example, a Point of Sale/Electronic Funds Transfer at Point of Sales (POS/EFTPOS) terminal;

[0115] Fig. 2A is a diagrammatic representation of a DTC in communication with the DAD of Fig. 1 operating to select a digital transaction document by use of the DAD and selection of the personality of the DTC resulting from selection of the required personality on the DAD and communication of same to the DTC according to an embodiment;

[0116] Fig. 2B is a diagrammatic representation of a DTC illustrating the selection of digital transaction documents by use of a DTC user interface which in the embodiment of Fig. 2B includes various touch activated switches and a display;

[0117] Figs. 3A, 3B, 3C and 3D are diagrammatic representations of various embodiments of a DTC in the form of a watch, ring, smartphone protective case and a credit card body respectively, the credit card body of Figure 3D depicted according to a minimum viable product embodiment, without interface embodiment and with interface embodiment respectively;

[0118] Fig. 4 is a functional flow diagram showing various parts of a system and steps in a method in accordance with an embodiment of the present invention;

[0119] Fig. 5 is a functional flow diagram showing the system and steps in the method for setting up a Digital Transaction Card (DTC) in accordance with an embodiment of the present invention;

[0120] Fig. 6 is a functional flow diagram showing initial step-up with security;

[0121] Fig. 7 is a functional flow diagram showing steps in adding secondary logical digital transaction documents to the DTC;

[0122] Fig. 8 is a functional flow diagram showing steps of adding security for secondary logical digital transaction documents; [0123] Fig. 9 is a functional flow diagram showing steps in linking a Data Assistance Device (DAD) with a DTC in accordance with embodiments of the present invention;

[0124] Fig.10 is a series of screens in a DAD in accordance with a method in an embodiment of the present invention;

[0125] Fig. 1 1 shows a DTC in accordance with an embodiment of the present invention;

[0126] Fig. 12A shows screens of a DAD in a method in accordance with an embodiment of the present invention for a Card Present transaction;

[0127] Fig.12B is a similar view to Fig. 12A for a Card-Not-Present transaction;

[0128] Fig. 13 is a functional flow diagram showing an example of payment using a DTC DAD in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENT(S) OF THE INVENTION

[0129] Figure 1 details the primary components of an apparatus (100) according to an embodiment of the invention, including a Digital Transaction Card (DTC) (108), a Data Assistance Device (DAD) in the form of a smartphone (106) and a Digital Transaction Device (102), which in this example is a Point of Sale/Electronic Funds Transfer at Point of Sale (POS/EFTPOS) terminal (102). Such terminals (102) may be referred to herein as merchant terminals, and may engage with the DTC (108) according to a contactless close proximity communication capability according to ISO/IEC 14443 between a terminal transceiver (not shown) and a DTC transceiver (1 14). Terminal (102) may also engage with a smartphone transceiver (1 16) and communicate therewith in accordance with the ISO/IEC 14443 Communications protocol. It is also possible for terminals (102) to engage by physical contact with the DTC (108), or with a magnetic stripe on the DTC (108). In the embodiment shown, the terminal (102) requires insertion of the DTC (108) into the terminal (102) to engage by physical contact. In the embodiment of Figure 1 , the smartphone (106) wirelessly engages with the DTC (108) by NFC, whereas the DTC (108) wirelessly engages with the terminal (102) by communications according to ISO/IEC 14443 which is a sub-set of the NFC Communications format.

[0130] It will be understood that many types of smart devices, or computing devices, such as smartphones (106), are unable to interact with many types of POS/EFTPOS terminals (102) and Automatic Teller Machines (ATMs). In order to complete a transaction with such terminals, it is necessary to use a debit or credit card. However, debit or credit cards will each have a single "personality", or comprise the physical embodiment of only a single digital transaction document. For example, presently, a physical transaction card can only have the personality of a MasterCard or a Visa card, but cannot selectively and serially assume the personality of both a MasterCard and a Visa card, at different times.

[0131] In the embodiment shown in Figure 1 , the DTPU (104) on the DTC (108) is an EMV device (where EMV is an abbreviation for Europay, MasterCard, and Visa), or a device complying with one or more of the EMV Co specifications, which has been adapted to allow expression of a number of different personalities. Such current DTPUs or EMV devices may include Read Only Memory (ROM), Random Access Memory (RAM), and/or Electrically Erasable Programmable Read Only Memory (EEPROM). The DTPU (104) may contain other kinds of memory, and the DTPU (104) may include a Central Processing Unit (CPU) for controlling operations of the DTPU (104). The DTPU CPU may work in cooperation with a crypto-coprocessor which handles the tasks of encrypting and decrypting data, thus freeing the DTPU CPU to perform other processing tasks. Communications between the DTPU (104) and electrodes (1 12) on the surface of the DTC (108) are effected by a system Input/Output (system I/O) of the DTPU (104). [0132] Similar to a standard EMV device, the DTPU (104) of the embodiment shown in Figure 1 is located in a plastic credit card body using electrodes (1 12) for communicating externally. However, the DTPU (104) may also communicate externally with terminals (102) using a wireless transceiver.

[0133] In an embodiment in which the operating firmware of an EMV device is modified, the DTPU (104) EEPROM may be divided into two memory areas. In some embodiments, the division could be by partition (or virtual partition), by use of a suitable file structure, or by use of a suitable directory structure. In this example embodiment, part of the EEPROM is used as staging memory (staging area). During operation, the staging memory has at least one Logical Digital Transaction Document Packet (LDTDP) written into it from LDTDP storage memory. Another part of the EEPROM is used as the secure record memory (secure element). During operation, the at least one LDTDP is taken from staging memory, and written into the secure element, which is accessed by the DTPU CPU when the DTPU is activated to read the secure element. When the DTPU CPU accesses the LDTDP, the DTPU (104) is able to assume the personality represented by the LDTDPs, such that the DTC (108) can be used for transactions with that personality.

[0134] In other embodiments, instead of using a single EEPROM divided into two memory areas (staging and secure record memory areas), there may be provided two separate memory chips each containing one of a staging memory and a secure record memory. These memory devices (or chips) could be configured in the DTPU (104) to have no direct link, in order to increase security, particularly for the secure record memory, which should only be directly accessible by certain designated elements in the DTPU (104), such as the DTPU CPU.

[0135] In the DTC (108), in accordance with an embodiment of the invention, there may be located an external DTC CPU different from, and additional to, the DTPU CPU. The control of the DTPU (104) may be by control of the DTPU CPU. The external DTC CPU and the firmware associated therewith may allow data (including LDTDPs) to be communicated to the DTPU (104) through the system I/O. The external DTC CPU and firmware can be operated to instruct the DTPU CPU to copy data (for example, one or more LDTDPs) into the staging memory. The DTC CPU can also be operated to instruct the DTPU CPU to transfer the data in the staging memory to the secure record memory.

[0136] The data containing the LDTDPs can be stored in LDTDP storage memory, either in the smartphone (106) or on the DTC (108) itself in a memory separate from the memories in the DTPU (104). The arrangement depicted in Fig. 1 allows LDTDPs to be stored in LDTDP storage memory, and to be copied from LDTDP storage memory to staging memory. Copying from LDTDP storage memory to staging memory may be controlled by the external DTC CPU, which in turn controls operation of the DTPU CPU. The operation of the external DTC CPU may be controlled by the DAD (106), being operated by a user via the user DAD user interface 1 10.

[0137] In another step of an example operation, the data containing the one or more LDTDPs is loaded from staging memory into secure record memory of the DTPU (104).

[0138] In embodiments, a link is established between a smartphone (a DAD) (106) and a DTC (108), using strong encryption for the identification and transfer of data therebetween. The link may be unique to each pairing of a smartphone (106) with a DTC (108).

[0139] The external DTC processor (or DTC CPU) is typically activated only after securely identifying itself to the linked smartphone. The DTC processor on the DTC (108) controls the reading and re-reading of the DTPU (104), and updating of the DTPU (104) to express new personalities. In some embodiments, the external DTC CPU may be activated by pressing an on/off switch on the DTC (108). In other embodiments, the DTC CPU is activated (and powered) by the DAD (106).

[0140] In embodiments, after the smartphone (106) and DTC (108) are securely linked, the smartphone (106) uploads correctly formatted data (for example, an LDTDP) to the nominated secure storage area (for example, staging memory) by the external DTC CPU after meeting specific standards and passing various checks for compliance, and then transmits an instruction to the DTPU processor to do the following:

• Check if the nominated storage area (staging memory) contains data (an LDTDP) in a specified format;

• If the data meets a specified standard and passes various checks, the DTPU processor copies or moves the data to a specified area (secure record memory) within the DTPU;

• The processor then sends an instruction to the DTPU (104) to read the data within the specified area (secure record memory) and act according to the data contained within that area, which may be stated as the DTPU (104) expressing the personality of the particular document represented in the LDTDPs in the secure record memory;

• The DTPU processor may then be instructed to search for specific headers and other data identifiers within a range of parameters before acting on that data.

[0141] It will be understood by skilled readers that the DTPU (104) may be an EMV device constructed with an increased storage area, which is specifically instructed to check and/or monitor a secure storage area (this may be referred to as secure record memory or secure element). The EMV device may also accept commands from, for example, an external processor resident within the DTC (108).

[0142] In embodiments, the external DTC processor only transfers data into the memory area(s) of the DTPU (104), and once inside this memory area, the DTPU processor is responsible for further copying, reading, writing, and/or processing of the data. However, in other embodiments, the data may remain under the control of the external DTC processor, wherein the external DTC processor (CPU) may issue instructions to the DTPU processor (CPU) to operate to copy, read, write, and/or process the data.

[0143] In another embodiment, the DTPU processor verifies data before transferring same to the secure location (secure record memory). Further, the DTPU processor after completing the check and verification of data instructs the EMV device to load the data, or update itself.

[0144] In various embodiments, all memory storage (LDTDP storage memory, staging memory, and secure record memory) may be located on the EMV device. Alternatively, some memory storage could be located on a chip outside the DTPU, but linked to the EMV device. The memory storage may be file based, using data files (electronic files) located in a Directory File (DF), with a root directory, or Master File (MF).

[0145] The firmware on the external DTC processor may be native firmware (using machine language), but could be interpreted code executed according to an interpreter based operating system, including Java card, MultOS, or BasicCard. Because both the external DTC CPU and the DTPU CPU provide instructions, the external DTC CPU would benefit from having the same firmware as the DTPU CPU, therefore allowing instructions to be provided using the same format. In this regard, if and when updating firmware for the external DTC CPU, it can be beneficial to also update firmware for the DTPU CPU. In some embodiments, firmware for both the external DTC CPU and the DTPU CPU could be stored in the same location, accessible by both CPUs, therefore requiring only updates to one firmware repository. However, a single source of firmware may have security implications.

[0146] Figure 1 details a DTC (108) which may form a communication link via a DTC transceiver (1 14) with a smartphone transceiver (1 16) of smartphone (106) to enable data transfer therebetween. In embodiments of the invention where the digital transaction document in respect of which a user seeks to conduct a transaction, the user may operate the user interface (1 10) of the smartphone (106) to select a particular digital document and activate that digital document in the DTC (108). Once the DTC (108) adopts the required personality and assumes the characteristics of the digital transaction document selected by the user operating their smartphone (106), the DTC (108) may then be used to conduct transactions with the DTC (108). In this regard, the DTC (108) operates with all of the characteristics of the selected digital transaction document which once activated as the document to be installed as the document to which the DTC pertains, the document becomes the personality of the DTC. In other words, once a DTC becomes the physical embodiment of a document, the document transitions to a "personality" of the DTC.

[0147] In particular, the DTC (108) with the selected personality of choice for a digital transaction document, may then be used to conduct transactions according to the existing infrastructure of a digital payment transaction network including Automatic Teller Machines (not shown), and/or a merchant terminal (102) as shown in Figure 1 to effect a range of transactions.

[0148] In the case of using the DTC (108) with a selected digital transaction document as its personality, the merchant terminal (102) with which the DTC (108) communicates may be effected by use of any of the existing communication means between DTCs and merchant terminals and in Figure 1 . The example illustrated includes a transaction effected between the DTC (108) and a merchant terminal (102) by physical contact between the DTC (108) and the merchant terminal (102) which generally includes physical contact between an external contact plate (1 12) of a payment device incorporated in the DTC (108) and electrodes (not shown) resident within the merchant terminal (102).

[0149] Further examples of conducting a transaction between a DTC (108) and a merchant terminal (102) include the use of contactless close proximity communication capabilities of the DTC (108) and the merchant terminal (102) and in instances where the DTC (108) includes a magnetic stripe, using a magnetic stripe reader of the terminal (102) and the DTC (108) to effect the transaction.

[0150] The embodiment in Figure 1 has been described above in terms of an embodiment including a firmware modified EMV device.

[0151] Similarly, the embodiments described in Figures 2A, 2B and Figures 3A to 3D could be implemented with an arrangement involving a firmware modified EMV device.

[0152] With reference to Figure 2A, a DTC in the form of a physical card (200) with associated DAD user interface (202) is diagrammatically illustrated stepping through a process of selecting a different personality for the DTC (200).

[0153] In the embodiment of Figure 2A, the DTC (200) does not have a specific personality at the commencement of the process of selecting a personality. A user may operate a smartphone (204) and communicate with the DTC (200) in accordance with a contactless close proximity communication protocol in order to select the personality required of the DTC (200). In the particular example of Figure 2A, the smartphone (204) has executed software to present available card personalities to a user who has selected a VISA card as the preferred personality of the DTC (200). In an embodiment, it may be necessary for the user to provide biometric authentication such as a fingerprint in order to operate the smartphone (204) to select a personality for the DTC (200).

[0154] Once the smartphone (204) communicates the user's selection of a VISA card as the personality that should be adopted by the DTC (200), the relevant selection and/or data is transferred from the smartphone (204) to the DTC (200) and upon receipt of the selection and/or data representing the LDTDP of a VISA card, the DTC adopts the personality of the VISA card (206). At a subsequent point in time, the user may prefer to change the personality of the DTC to a MasterCard and may operate software on their smartphone to select a MasterCard personality for the purpose of effecting a personality change in the DTC. With reference to Figure 2A, the smartphone (204) has been operated to select a MasterCard personality and upon communicating the relevant selection and/or LDTDP data to the DTC (200), the DTC adopts a MasterCard personality and subsequent to which, the DTC (200) will operate as the consumers MasterCard (208).

[0155] Ultimately, once a consumer has completed conducting transactions with their DTC, they may prefer to render the DTC with a Null personality and with reference to Figure 2A, the smartphone (204) is operated to identify that the consumer prefers to lock their DTC by imparting a Null personality to the DTC. Upon communication of the user's request, the smartphone (204) causes the DTC (200) to adopt a Null personality (200).

[0156] In the embodiment of Figure 2A, the DTC (200, 206, 208) is a modified DTPU executing software that has been modified to allow/enable the DTC to adopt different personalities including a Null personality in accordance with data instructions transferred to the DTC by the DAD (204).

[0157] The communication between the DAD and DTC may be effected by the DAD processor communicating with a DTC external processor via respective transceivers (shown in Figure 1 as smartphone transceiver (1 16) and DTC transceiver (1 14) respectively) and wherein the DTC external processor having received instructions and/or from the DAD, co-operatively communicates with the EMV device to cause the EMV device to adopt a required personality in accordance with the instructions and/or received by the DTC from the DAD.

[0158] With reference to Figure 2B, the same steps depicted in Figure 2A are illustrated in Figure 2B regarding the change of personality of a Digital Transaction Card. The reader will note that the DTC in Figure 2B is a DTC with a Null personality (210) including a user interface, which is described in more detail below, particularly with reference to Figure 3D. In the instance of the embodiment depicted in Figure 2B, the request to change the personality of the DTC (210) is effected by the DTC user interface as compared with the DAD user interface (refer Figure 2A). As for the DTC (200) in Figure 2A, the Null personality DTC (210) in Figure 2B transitions to a VISA card (206) by the user operating the user interface on the Null personality DTC (210) which includes scroll and enter keys and a display on the DTC.

[0159] When seeking to change the personality from a VISA card (206) to a MasterCard (208), the user operates the DTC scroll keys observing the display which displays available personalities sequentially as the scroll keys are repeatedly depressed. Once a MasterCard personality is displayed, the user may depress the enter key and the DTC personality is altered accordingly. The DTC (208) can be changed to a Null personality again by the user operating the DTC user interface to display and select a Null personality and effect same.

[0160] With reference to Figure 3A, a DTC in the form of a wearable device (300) is illustrated along with a DAD in the form of a Smartphone (302) and a merchant terminal (304). In this particular embodiment, the wearable device (300) is a watch which also provides the function of displaying the current time and any other functions that are available according to the wearable device (300). Increasingly, wearable devices are being adopted by consumers to combine the functions of many individual items thereby reducing the complexity of conducting transactions since, once the functionality of a DTC 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 conduct transactions with the device that they would ordinarily wear. In the instance of Figure 3A, the wearable device (300) is illustrated communicating with the smartphone (302) and a merchant terminal (304) via contactless close proximity communication. Of course, despite all three devices being illustrated in close proximity, skilled readers will understand that it is not necessary for the wearable device (300) to be in contactless close proximity communication with both a smartphone (302) and a merchant terminal (304) simultaneously and the communication between respective devices may occur separately at different times.

[0161] With reference to Figure 3B, an alternative wearable device in the form of a ring (306) is detailed in contactless close proximity communication with a DAD in the form of a smartphone (302) and a merchant terminal (304). Once again, in the illustration in Figure 3B, communication between the smartphone (302), the wearable device in the form of a ring (306) and a merchant terminal (304) all occur using contactless close proximity communication.

[0162] With reference to Figure 3C, yet another embodiment is illustrated in which the DTC is provided in the form of a smartphone case (308). In this particular embodiment, a DAD in the form of a smartphone (302) communicates with a DTC in the form of smartphone case (308) which in turn communicates with a merchant terminal (304). All communications illustrated in Figure 3C occur in accordance with contactless close proximity communication according to ISO/IEC 14443 and in this particular embodiment, rather than a wearable device, the DTC takes the form of another convenient device, namely, a smartphone case (308) since users regularly purchase cases for their smartphones in order to protect their smartphone from damage. Of course, in the embodiment of Figure 3C, if a consumer were to user a DTC in the form of a smartphone case (308), and attach the case (308) to the smartphone (302), then the DAD in the form of the smartphone (302) and the DTC in the form of a smartphone case (308) are in the consumers possession at the same time.

[0163] The reader will appreciate that the DTC may be configured in a number of different ways, and there is a range of possible DTC embodiments from a DTC having minimal (or limited) functionality/connectivity but will be less expensive to produce and less prone to failure, to a DTC having maximum functionality and including features that assist user interaction and will therefore be considered more "user friendly" but will be more expensive to produce and will be more likely prone to failure. Figure 3D provides diagrammatic representations of four DTCs which have a credit card profile whereby each includes an EMV device (310) and an optional printed identification (312), which in the embodiment shown is the card owner's name, and whose features of functionality/connectivity represent significant differences in user experience with respect to digital transactions.

[0164] For example, the uppermost DTC (314) that is depicted in Figure 3D represents a card having minimal functionality/connectivity and includes an EMV device (310) that is firmware- modified and enables NFC wireless connectivity between the EMV device and a DAD (302) and to change the personality of the DTC (314), but excludes an external DTC processor (referred to as an MCU), Bluetooth connectivity and any form of display or scroll/enter keys. In one particular embodiment, DTC (314) that is configured with minimal functionality/connectivity can be issued to a user such that the EMV device (310) has pre-loaded multiple personalities. More commonly, after the DTC (314) is delivered to the user, the DAD (302) may be used to transfer one of multiple personalities onto the EMV device (310) or a number of personalities for simultaneous storage by the EMV device (310).

[0165] The second DTC (316) that is depicted also represents a card having minimal functionality/connectivity including an EMV device (310) that is firmware-modified and enables wireless connectivity between the EMV device and a DAD (302), such as Bluetooth and/or NFC, to change the personality of the DTC (316). The DTC (316) also includes an MCU (not shown in Figure 3D). A DTC (316) that is configured with relatively minimal functionality/connectivity but including an MCU can be issued to a user with the EMV device (310) having access to data performing to multiple personalities. Alternatively, after the DTC (316) is delivered to the user, the DAD (302) may be used to transfer one of multiple personalities onto the EMV device (310) or a number of personalities for simultaneous storage by the EMV device (310).

[0166] The third DTC (318) that is depicted in Figure 3D represents a medium functionality/connectivity card including an EMV device (310) that is firmware-modified and enables wireless connectivity between the EMV device (310) and a DAD (302), such as Bluetooth and/or NFC, and to change the personality of the DTC (318). The DTC (318) also includes a display (320) which may be in the form of a simplified 4-digit alphanumeric interface for displaying information, including but not limited to, the selected personality loaded (or previously stored) on the card, a unique ID or abbreviation of the selected personality, an expiry date for the document, a temporary PI number, a PAN number or part thereof, and/or a name of the card owner. A DTC (318) that is configured with mid-range functionality/connectivity can be issued to a user such that the EMV device (310) has access to data pertaining to multiple personalities. Alternatively, after the DTC (318) is delivered to the user, the DAD (302) may be used to transfer one of multiple personalities onto the EMV device (310), or a number of personalities for simultaneous storage by the EMV device (310).

[0167] The fourth DTC (322) that is depicted in Figure 3D represents a card having a high level of functionality/connectivity and includes an EMV device (310) that is firmware-modified and enablea NFC or Bluetooth wireless connectivity between the EMV device (310) and a DAD (302) and to transfer multiple personalities onto the EMV device (310) after delivery of the card. The DTC (322) also includes a more comprehensive display (324) and scroll/enter keys (326) which enable user input, including input effecting selection of a stored personality. The skilled addressee will appreciate that the inclusion of a user interface on the card enables the DTC (322) to be used even when a DAD (302) such as a user's smartphone is not present, for example, if the DAD is not being carried by the user or has a discharged battery.

[0168] TABLE 1 is a chart of the DTC embodiments depicted in Figure 3D (314, 316, 318 and 322) when the EMV device associated with the DTC is firmware-modified, detailing the combination of features that are present in each embodiment. The V symbol signifies that a feature is present, and the * symbol signifies that a feature is not present, and it is to be understood that this listing of embodiments represents only a selection of possible embodiments that may be configured with differing combinations of features and is not intended to represent an exhaustive listing. TABLE 1

Firmware-Modified EMV Device

EMV

Device MCU

Multiple Multiple MCU

having with Scroll

Personalities Personalities with NFC Card

Embodiment Modified Bluetooth / Enter for Single for Multiple Comms Display

Contactless Comms Keys

Scheme Schemes Capability

Comms Capability

Capability

314 X X X X X

316 X X X X X X

4/8

318 X X

Active

Matrix

4/8

322 X

Active

Matrix

[0169] In the first embodiment in TABLE 1 , the DTC (314) requires the use of a Data Assistance Device (DAD) with a modified NFC capability such as a smartphone to communicate data to an EMV device that is firmware-modified. As previously described, a firmware-modified EMV device has an external DTC CPU that includes firmware that is operable to write data (for example, LDTDP data) to staging memory, such that, when the DTPU is activated, the DTPU copies the data to secure record memory (secure element) in the DTPU in a manner that causes the DTC to adopt a particular card personality or assist in conducting a digital transaction in some other way. Data relating to each personality may be stored in memory associated with the DAD, wherein communications between the DAD and DTC may be in the form of instructions to download and copy the data into the secure element for the purpose of updating the personality of the DTC. The firmware-modified DTC (314) is limited to use with an NFC-enabled DAD and use of an EMV device having modified contactless communications capability in order to securely receive data received from the NFC-enabled DAD, but has the advantage of being able to adopt multiple personalities for a single Scheme and low cost and low propensity to fail since the DTC (314) does not include an MCU, display or scroll/enter keys.

[0170] The firmware-modified DTC (316) also requires the use of a Data Assistance Device (DAD), such as a smartphone, to communicate data to an EMV device that is firmware-modified as described above. The difference between DTCs (314) and (316) is that DTC (316) includes an MCU that can store data relating to multiple personalities (and/or data that may be relevant to changing some other digital transaction parameter) rather than storing same in the DAD memory, and can accept a secure session between a DAD with wireless connectivity (either NFC or Bluetooth) and the DTC containing the MCU which also has wireless connectivity (either NFC or Bluetooth). The advantages of using the firmware-modified DTC (316) include low cost and low propensity to fail, there being no requirement for an NFC-enabled DAD (in that the MCU can accept communication with a phone that is solely Bluetooth-enabled, for example), the ability to adopt multiple personalities for a single Scheme, and the presence of an MCU that can assist secure data transfer from the DAD and does not require the use of an EMV device having modified contactless communications capability.

[0171] DTC (318) in TABLE 1 also requires the use of a Data Assistance Device (DAD), such as a smartphone, to communicate data to a firmware-modified EMV device that can establish a secure session between a DAD with wireless connectivity (NFC and/or Bluetooth) and the DTC via a contactless interface. DTC (318) includes an MCU that can accept wireless communication from both NFC and Bluetooth-enabled DADs, and can thereby establish a secure session between a majority of phones and the DTC containing the MCU. The advantages of using DTC (318) include low-to-medium cost, low-to-medium propensity to fail, and there being no requirement to use solely an NFC-enabled DAD, but in view of DTC (318) including an MCU and display (320) there is a higher cost associated with production of DTC (318) as compared with DTC (314) and (316).

[0172] When using the DTC (322) described in TABLE 1 , the skilled addressee will understand that the use of a DAD such as a smartphone is not necessarily required, but may be used, to change the personality of the card or to assist in some other way in conducting a digital transaction. In any event, the DAD is necessary to initially set up the card and download/store multiple personalities in the MCU, but subsequent to the initial setup, the card itself may be used to change the operational parameters of a card's personality or to assist the digital transaction in some other way using the scroll/enter keys (326). An MCU is used to accept wireless communication (both Bluetooth and NFC) from the DAD during an initial setup, and is further programmed to accept commands from a local interface, which may for example include the scroll/enter keys (326), and convert the keystrokes into commands. When the scroll/enter keys (326) are used to change the personality of the DTC (322) or to perform some other task that assists the digital transaction, transmission is authorized by the local interface that authorizes the MCU to select stored data and copy same to the secure element.

[0173] DTC (322) has the advantage of locally selecting one from many multiple concurrent personalities stored on the card with no risk of discovery of card details during updates or changes (i.e. changes to status/updates) since card details are not transmitted. Further advantages include reduced time to effect updates or changes (i.e. changes to status/updates), minimal amounts of data being required to be transferred to effect a change in personality, and the ability to change DTC personalities without the use of a DAD. However, DTC (322) has a higher production cost and due to its complexity may have a higher propensity to fail.

[0174] Fig. 4 shows exemplary elements in a system in accordance with an embodiment of the present invention. One element is a Digital Transaction Card (DTC) 412 and another element is a Data Assistance Device (DAD) (414_. In this example, the DAD (414) is a smartphone, but could be a computer tablet, some other form of portable computing device, or a specific device manufactured for the purposes of the present invention.

[0175] The system is used for payment at one of two example digital transaction devices including a Point Of Sale/Electronic Funds Transfer at Point Of Sale (POS/EFTPOS) terminal (416A) and on-line transaction terminal (416B). The on-line transaction terminal may include a personal computer, or any other device enabled for such on-line (Card-Not-Present) transactions.

[0176] The DTC (412) has a primary digital transaction document (419), being a primary credit card. The primary credit card, has a logical digital transaction document, is loaded onto the DTC (412), which may occur before supply to the user (420). The user can link (415) to the smartphone (414) to the DTC (412), as it is supplied with the primary digital transaction document (primary credit card) (419) pre-loaded. The linking process (415) is shown in in Fig 4.

[0177] Fig. 4 also shows example steps in creating and issuing a DTC (412) to a user (420). There may be a number of actors in providing a DTC (412), including a personalisation company (402), a card (or DTC) integrator (404), a card (or DTC) manufacturer (406), and a security supplier (408). Other actors in issuance of a DTC (412) may include an issuing financial institution (440), such as a bank or other similar party. The issuing financial institution (440) may act as a security requestor (442), supplied with, for example, a seed (444). Customer service (446) of the issuing financial institution (440) may interact with the user (420) who requests the DTC (412) and supplies required information to the financial institution, such as name, date of birth, details of their DAD, which, in the example of a smartphone, may be the IMEI number, or another suitable unique ID of the smartphone.

[0178] The financial institution (440) can then generate a security cryptokey which is provided to the personalisation company (402) for creation of the DTC (412).

[0179] The DTC (412), in this embodiment, is a credit card-like transaction card. The DTC (412) has an EMV chip (where EMV is an abbreviation for Europay, MasterCard, and Visa) (422), a button (423), which can be used for linking the DTC with the smartphone (414), say, by using Bluetooth™ for doing the linking. The DTC 12 also has a DTC display 24 which may be a simplified graphical user interface for showing a unique ID for a selected logical digital transaction document loaded onto the DTC, and implemented on the DTC (412), such that it acts as that digital transaction document. In the example shown in Fig.1 , the digital transaction document is a primary, or one of plural secondary credit cards.

[0180] The DTC (412) also has means to display an expiry date for the particular digital transaction document it is operating as. The DTC also has a space for a display (428) for the name of the person (420) who owns the DTC. In some embodiments, the name of each and every logical digital transaction document will be the same, being the name of the user (420). However, in other embodiments the name associated with a particular logical digital transaction document may be different, for example, if a person is using the DTC (412) for both personal use, and company use. In this regard, the DTC name space (428) may be simply a printed name, or could be a simplified Graphical User Interface (GUI) enabled for displaying different names.

[0181] The DAD (414), being a smartphone, includes a smartphone interface (430), which, in Fig. 4, is a screen (430) that is touch sensitive.

[0182] The DAD (414), being a smartphone, has an IMEI number, or another unique ID, so as to uniquely identify the smartphone. The smartphone may use Android, and, or iOS operating systems, or any other suitable operating systems. In embodiments, the smartphone (414) includes wireless connection technology, for example, Near Field Communication (NFC) and/or Bluetooth™ or Bluetooth™ LE.

[0183] The DTC (412) has a DTC chip (a Digital Transaction Processing Unit (DTPU)) (422), which could be certified smart card chip so as to be ordinarily operable to communicate date only with an external read/write DAD. Examples of certified smart card chips may comply with one or both of the following certification standards ISO/IEC 7816, or ISO/IEC 14443. Further, the certified smart card chip (DTPU) may comply with other standards, such as Common Criteria EAL4+/EAL5+ (ISO/IEC 15408 information technology - security techniques - evaluation criteria for IT security parts 1 -3), FIPS 140-2 level 3 and 4, ISO/IEC 7816 identification cards, integrated circuit cards parts 1 -5, ISO/IEC 14443 identification cards - contactless integrated circuit cards - proximity cards parts 1 -4, and EMVCo.

[0184] Fig. 5 shows an example set-up for a DTC (512) operating in a system with a DAD (514), being a smartphone with a smartphone interface. In this example, the set-up commences with the user (520) extracting the IMEI number, or another suitable unique ID, (503) from the smartphone (514). The IMEI number, being a unique ID for the smartphone (514), is provided (505) to the relevant financial institution (502), also known as the issuing financial institution. The financial institution (502) records and process the submitted IMEI number, or other suitable unique ID, and the users details, and after recording these details, the financial institution look-up section (534) looks up records and populates an application with seed/secret key (538) information and sends an application link (540) via an Out-Of-Band (OOB) notice (544) to the smartphone (514). The application link (540) in, for example, an app (software application) for the smartphone (514), is made available via an internet download (554), for example, from the cloud (556), the app can operate by the user (520) clicking on it on the smartphone (514). When the seed/secret key (538) is downloaded to the smartphone (514), this part of the set-up is complete and the user (520) can proceed to link the smartphone and the DTC (512).

[0185] Fig. 5 also shows the DTC (512) with the DTC display (524) showing a unique ID (526), in this case being the number for the primary credit card, that is, the primary logical digital transaction document causing the DTC (512) to behave as the digital transaction document, that is, the primary credit card.

[0186] Fig. 5 also shows the role of the issuing financial institution (502) acting as security requestor (504) and obtaining keys (510), which are passed to customer service (508) and then passed to the look-up (534), using a counter (536) to develop the seed/secret key (538) and passed to the smartphone (514) via the app link (540).

[0187] Fig. 6 shows example steps in setting up a DTC (612), as provided by a personalization company (602), involving both a DTC integrator (604) and a contactless DTC manufacturer (606). The personalization company (602) also works with a token supplier (608), which in turn works with the issuing financial institution (610), being a security requestor (61 1 ). The financial institution (610) creates a seed (616) which is supplied via customer service (618) as an application (640) loaded with the smartphone's IMEI, or another unique ID of the smartphone, and security detail. [0188] In this way, Fig. 6 demonstrates one example method in which the DTC (612) can be supplied pre-loaded with a primary logical digital transaction document, in this example being a primary credit card. The DTC (612) and the smartphone (614) each have details of the primary logical digital transaction document, so that the user (620) can operate the smartphone (614) to select the primary logical digital transaction document on the DTC (612), and so as to cause the DTC (612) to act as the primary digital transaction document.

[0189] In this regard, it will be realized that in some embodiments, a logical digital transaction document can be stored, in part, on the DTC (612), and other parts of those logical digital transaction documents can be stored on the smartphone (614), so that the smartphone can be operated to select a particular logical digital transaction document desired for a transaction, and so that the smartphone can cause the DTC (612) to act as the digital transaction document associated with the selected logical digital transaction document.

[0190] Fig. 7 shows an example embodiment where a DTC (712), already having a primary logical digital transaction document loaded onto it, can have additional secondary logical digital transaction documents (718) loaded onto it via the smartphone (714). The second logical digital transaction document (718), in this example, are other credit cards.

[0191] In this example, the user (720) supplies or enters additional card (718) detail(s) to the primary card issuing financial institution (702) via its customer service section (708). In one embodiment, the primary card issuing financial institution could conduct verification by making a debit with a reference number or a debit and a credit of two unique monetary amounts, which could be conducted on each of the additional credit cards (718) added to the primary card. When the user (720) has a statement (710) issued by the particular secondary card issuing financial institution (716), the statement will show a debit with a reference number or a debit and a credit of two unique amounts. The user (720) reads the statement (710) and enters or submits the line details from the statement to verify the user (720) is the actual owner of each of the additional secondary credit cards added to the primary card (as represented in Fig. 4, for example). When the primary card (or DTC) issuing financial institution (702) is satisfied that the user (720) is the correct owner of the additional credit cards, the primary card issuing financial institution can request the user to take the additional cards into that financial institution (702) and have the cards read to extract public encryption keys for the cryptogram used, for example, a POS/EFTPOS terminal. Alternatively, the primary financial institution (702) could send a request to the financial institution (716), which has issued the additional card for the public encryption keys used in a cryptogram at a POS/EFTPOS terminal. When the primary card issuing financial institution (702) is satisfied that the user (720) is the correct owner of the additional cards (718), the institution (702) can send code via an OOB message to the users registered smartphone (714). The user (720) then has code that can be used, when selected, to load the DTC (712) with one of the secondary logical digital transaction documents (secondary credit cards) selected from the smartphone (714).

[0192] Fig. 8 shows process steps for adding extra security for each of the additional credit cards (818), the extra security provided via the customer service section (808) via OOB (810) to the smartphone (814).

[0193] Fig. 9 shows that a DTC may operate with different types of smartphone (914). However, the DTC is linkable with only one DAD (smartphone) to the exclusion of all other DADs.

[0194] As shown in Fig. 9, a user may decide to purchase a new smartphone, in which case the DTC (912) will need to be updated so as to be able to link with the new phone. In this example, the old smartphone is linked with the DTC (912), but the user wants to link the new smartphone (952) with the DTC (912). The linking is, for example, a two way encrypted transmission. The DTC (912) may be loaded with matching seed and dynamic key at the time of manufacturing, so as to be able to be linked only with the one smartphone (950). In order to link the DTC (912) with the new smartphone (952), a dynamic code is constructed from, for example, a dynamic key or a seed could be made available to the verified owner. The dynamic key or seed is used to disconnect or unlink the old smartphone (950) from the DTC (912). The DTC can then be loaded with a matching seed and/or dynamic key so as to link with the new smartphone (952). The seed and dynamic key being based on the smartphone's IMEI, or another suitable unique ID of the smartphone. It will be understood that the codes linking the DTC to the smartphone must be unique for each DTC, and could be unique, for example, to each DTC's serial number. In this regard, the linking between a smartphone and a DTC can only occur based on matching IMEI, or another suitable unique ID of the smartphone, and DTC serial number between the smartphone and the DTC.

[0195] Fig. 10 shows screens on a smartphone (1014) in an embodiment process for initial paring (linking) of a smartphone (1014) and a DTC (1012).

[0196] In the first screen (1002), the smartphone displays a heading "SETUP" (1004), and under the heading (1004) is a "SETUP" button (1006), and under the button (1004) is an indicator displaying "INTERNET CONNECTION".

[0197] The next screen (1032) shows a heading "SET UP" (1034), including an "APPLY FOR CODE" button (1036) and a "KEY" entry field (1038), and a "PAIR TO CARD" (alternatively, "PAIR TO DTC") button (1040). In the final screen, there is displayed a "CONGRATULATIONS" message (1044), indicating to the user (1020) that the smartphone (1014) is linked to the DTC (1012).

[0198] In an embodiment, the smartphone (1014) is linked with the DTC (1012), also by linking button (1023) which is pressed and held (1046) so that it can be linked to the smartphone (1014).

[0199] Fig. 1 1 shows an embodiment of a DTC having a front side (1 1 12f) and a rear side (1 1 12r) with a number of indicators showing, for example, personalization details related to the primary logical digital transaction document stored onto the DTC (1 1 12). On the front of the DTC (1 12f) there is printed the logo (1 104) of the primary card (1 1 19), along with a hologram (1 106), affixed to the DTC (1 1 12). The DTC (1 1 12) may also display the primary card expiry date (1 108). On the back of the DTC (1 1 12) there may be a panel for the primary card owner's signature (1 1 10). There may also be printed the Card Verification Value (CVV) (1 1 14), along with other identifying details. In some embodiments, where details are printed or otherwise permanently marked on the DTC (1 1 12) the details will pertain only to the primary logical digital transaction document stored on the DTC (1 1 12), such as a user's name, CVV, expiry date. Where a DTC (1 1 12) displays details in changeable GUIs, those details can pertain to the logical digital transaction document (including primary and secondary logical digital transaction documents) presently being expressed as the DTCs digital transaction document.

[0200] In an example transaction the merchant check for a valid DTC may include the following:

1. the DTC includes a full-color DTC (or, alternatively, a primary digital transaction document) issuer brand mark;

2. the DTC number is a valid length of 12 to 19 digits;

3. the first four digits of the DTC (or, alternatively, a primary digital transaction document) number displayed on the DTC display are the same as those printed directly below;

4. the expiration date is in the future and in the correct format "MM/YY";

5. the hologram, or Holomag tape can be located on the front or back of the DTC. If located on the front of the DTC, it may be located above the brand mark, if located on the back of the DTC, it may be located above or below the signature panel; 6. a magnetic stripe is present on the DTC, and located above the signature panel, and should appear to be smooth and straight with no signs of tampering. On some DTCs, Holomag tape may be used in place of the magnetic stripe; and

7. the four digits printed on the signature panel must match the last four digits of the account number, followed by the three digit Card Verification Code (CVC) number.

[0201] Fig. 12 shows an example embodiment using the smartphone (DAD) (1214) to select a different logical digital transaction document (different credit card) for updating the DTC (1212) for a transaction using the selected logical digital transaction document. The first smartphone screen (1202) has a "LOGIN" heading, followed by three buttons to select the security type, including a "PIN (Personal Identification Number)" button (1204), a "SWIPE" button (1206) and a "BIOMETRIC" button (1208). The user (1220) selects one of the options 1204, 1206 or 1208, then the smartphone (1212) displays the next screen (1210) showing a "PAYMENT OPTIONS" heading underneath which is shown a "CURRENTLY" heading (121 1 ) which indicates which document is currently operating on the DTC (1212). In this example, the smartphone screen (1 1210) shows that the currently operating digital transaction document is a "VISA" card (1213).

[0202] The user can operate the screen (1210) to select one of four other documents (credit cards) operable on the DTC (1212), and listed under the "CHANGE TO" heading (1215). The additional documents for financial transactions include "MASTERCARD" button (1217), "BANK DEBIT" button (1218), "AMERICA EXPRESS" button (1219) and "DINERS CLUB" button (1221 ). The user (1220) selects one of the documents under the "CHANGE TO" heading, which then causes the smartphone (1214) to display the next screen (1232), displaying the message "SET MASTERCARD AS PREFERRED PAYMENT METHOD" (1234), under which is displayed two buttons, "YES" (1236) and the "NO" button (1238). The User (1232) can press one of those buttons to determine whether the Mastercard will be the preferred payment method.

[0203] The next smartphone screen (1242) show security options for the user with the "SECURITY" heading (1244) and a "YES" button (1246), along with "NO" button (1248).

[0204] The next smartphone screen (1252) shows the status and includes the "STATUS" heading (1254), under which is an indicator showing "BIOMETRICS SET/ NOT SET" (1256). The screen (1242) also shows instructions "TOUCH CARD" (alternatively, "TOUCH DTC") (1256), along with an indicator "CARD LINKED" (alternatively, "DTC LINKED") (1258) showing that the smartphone (1214) and the DTC have been linked. [0205] The smartphone (1214) then transmits data to the DTC (1212) so as to update the DTC with the newly-selected document detail, and such that the DTC GUI display (1224) shows the newly-selected document (credit card) number (1260).

[0206] The smartphone then displays screen (1262) with further security including a "CREATE OTP" button (1264), which, when pressed by the user (1220), shows the One-Time- PIN (OTP) in a panel (1268).

[0207] The user can then present the DTC (1212) to a merchant terminal (1270), the DTC is then processed (1272) via communication with the DTC (or, alternatively, the primary digital transaction document) issuing financial institution (1274).

[0208] In some instances, a transaction may be outside standard limits and the smartphone (1214) can display on a screen (1280) a message "TRANSACTION OUTSIDE LIMITS" (1282). The User (1220) can then authorize the out-of-limits transaction by pressing the "YES" button (1284) under a message (1286) inviting the user to authorize the transaction. Alternatively, the user (1220) can press the "NO" button (1288), so that the transaction is not authorized and does not proceed.

[0209] Fig. 12B (which depicts a card-not-present transaction) is a similar view to Fig. 12A (card-present transaction) wherein the smartphone also displays screen (1261 ) having a panel (1263) for displaying a unique ID associated with the selected logical digital transaction document, in this example, the Personal/Primary Account Number (PAN) (1265) of the credit card (digital transaction document) selected. The smartphone screen (1281 ) also displays the expiry date under a heading "EXPIRY DATE" (1267). The smartphone screen (1261 ) may also display the CW of the selected document in the CVV display panel (1269).

[0210] Fig. 13 shows an example of an in-store or Card-Present (DTC-Present) transaction using the system in an embodiment of the present invention. In this example, the user (1320) decides to use the primary card for making a purchase. The primary card number (1321 ) is displayed on the DTC GUI display (1324). The user (1320) presents the DTC (1312) to the merchant POS/EFTPOS terminal (1316), being the digital transaction device. The POS/EFTPOS terminal requires the details of the primary credit card via a merchant acquirer (1318), which may be by use of card rails (1332). The primary card details are then passed via a payment processor, via a security supplier (1334), using appropriate security procedures, to the primary card (digital transaction document) issuing financial institution (1336).

[0211] In one example embodiment, after reading the primary card details from the DTC (1312), the POS/EFTPOS terminal creates a cryptogram generated from details including, for example, Biometrics (1338), and/or other security assurance data (1340), where a number is given to the type and level of authorization from details taken from the chip in the DTC (1312). The cryptogram may also include the merchant POS/EFTPOS terminal identification number, purchase price and other relevant details for forwarding to the merchant acquirer (1318).

[0212] Fig. 13 also shows an option on-line or Card-Not-Present (DTC-Not-Present) transaction using a smartphone or over the Internet (1342) using the primary credit card on the DTC (1312). The user reads the credit card number (1321 ), the expiry date and CW number, either from the DTC (1312) or the smartphone screen (1330) and enters those details on-line or reads those details out over the smartphone to a merchant. The merchant captures the information and the transaction can occur with the right authorization code being provided.

[0213] Fig. 13 also shows that the transaction DTC (1312) can be used with a selected other logical digital transaction document, the details of which are displayed on the DTC's GUI (1324), being the other logical digital transaction documents unique ID (1344).

[0214] In this way, the system may be used for Card-Present transactions and Card-Not- Present transactions.

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

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

[0217] It will be understood by persons skilled in the relevant field of technology that numerous variations and/or modifications may be made to the invention as detailed in the embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are therefore to be considered in all aspects as illustrative and not restrictive.