TRANSACTION RECORDING
20200356984 ยท 2020-11-12
Inventors
Cpc classification
G06Q20/227
PHYSICS
G06Q20/085
PHYSICS
G06Q20/341
PHYSICS
International classification
G06Q20/34
PHYSICS
Abstract
Digital transaction apparatus operable to perform at least one digital transaction with a least one digital transaction device, and further operable record at least one or more details regarding the transaction, the apparatus including a Data Assistance Device (DAD), including, a user interface that is operable to at least select data, and a DAD transmitter, a Digital Transaction Card (DTC), including a Digital Transaction Processing Unit (DTPU), and a DTC receiver, wherein the DAD and DTC are operable to transfer data from the DAD to the DTC and when subsequently using the DTC to effect a digital transaction, the DTC operates in accordance with the data selected and transferred from the DAD to the DTC, wherein, the DTC provides data regarding the at least one digital transaction to the DAD and the DAD is operable to record at least one or more details regarding the at least one digital transaction.
Claims
1. Digital transaction apparatus operable to perform at least one digital transaction with a least one digital transaction device, and further operable record at least one or more details regarding the transaction, the apparatus including: a Data Assistance Device (DAD), including: a user interface that is operable to at least select data, and a DAD transmitter; a Digital Transaction Card (DTC), including: a Digital Transaction Processing Unit (DTPU), and a DTC receiver, wherein the DAD and DTC are operable to transfer data from the DAD to the DTC and when subsequently using the DTC to effect a digital transaction, the DTC operates in accordance with the data selected and transferred from the DAD to the DTC, and wherein, the DTC provides data regarding the at least one digital transaction to the DAD and the DAD is operable to record at least one or more details regarding the at least one digital transaction.
2. The digital transaction apparatus according to claim 1, wherein the transferred data includes data pertaining to one or more selectable personalities.
3. The digital transaction apparatus according to claim 2, wherein data pertaining to the plurality of selectable personalities is stored on the DAD, and changing the current personality of the DTC to the selected personality includes: receiving, by the DAD and by operation of the DAD user interface, the instruction to change the current personality of the DTC to the selected personality; transmitting, by the DAD transmitter to the DTC receiver, data related to the selected personality; and implementing, in the DTC, a change from the current personality to the selected personality in accordance with the data such that when the DTC operates with a digital transaction device to effect the digital transaction, the digital transaction device recognizes the selected personality.
4. The digital transaction apparatus according to claim 2, wherein data related to the plurality of selectable personalities is stored on the DTC, and changing the current personality of the DTC to the selected personality includes: receiving, by the DAD, and by operation of the DAD user interface, the instruction to change the current personality of the DTC to the selected personality; transmitting, by the DAD transmitter to the DTC receiver, the instruction to change the current personality of the DTC to the selected personality; and implementing, in the DTC, a change from the current personality to the selected personality in accordance with the instruction such that when the DTC operates with a digital transaction device to effect the digital transaction, the digital transaction device recognizes the selected personality.
5. The digital transaction apparatus according to claim 1, wherein the selected and transferred data includes one or more instructions.
6. The digital transaction apparatus according to claim 5, wherein the one or more instructions include instructions to change a current personality of the DTC to a personality selected from a plurality of selectable personalities.
7. The digital transaction apparatus according to claim 1, wherein the DTC includes a user interface.
8. The digital transaction apparatus according to claim 7, wherein the selected data transferred from the DAD to the DTC including data pertaining to the plurality of selectable personalities and stored on the DTC are individually selectable by operation of the DTC user interface.
9. The digital transaction apparatus according to claim 8, wherein changing a current personality of the DTC to the selected personality includes: receiving, by operation of the DTC user interface, one or more instructions to change the current personality of the DTC to the selected personality; and implementing, in the DTC, a change from the current personality to the selected personality in accordance with the one or more instructions such that when the DTC operates with a digital transaction device to effect the digital transaction, the digital transaction device recognizes the selected personality.
10. The digital transaction apparatus according to claim 7, wherein the DTC user interface includes scroll keys and a display, and wherein the scroll keys enable user selection of a personality from the plurality of personalities and the display indicates the selectable personality.
11. The digital transaction apparatus according to claim 1, wherein the DTC includes a DTC external processor for receiving and storing transferred data.
12. The digital transaction apparatus according to claim 1, wherein the DTC includes a display for displaying information.
13. The digital transaction apparatus according to claim 1, wherein the DTPU is an EMV device including a software module having instruction code which, when executed, causes the EMV device to receive and execute commands according to the Global Platform Standard Command set including commands to install an Applet displaying a credit card personality.
14. The digital transaction apparatus according to claim 1, wherein the DTPU is an EMV device operating in accordance with firmware wherein the firmware has been modified to enable the EMV device to receive and execute an expanded set of commands that, when executed, allows the writing of data to a secure memory element of the EMV device.
15. The digital transaction apparatus according to claim 14, wherein a digital transaction device interfaces with the EMV device by physical connection with contact terminals of the EMV device, or by contactless connection (ISO 14443 Standard), or by interaction between a magnetic stripe reader associated with the digital transaction device and a magnetic stripe of the DTC.
16. The digital transaction apparatus according to claim 15, wherein the DTC is a wearable device including a watch, a wrist band, a ring or an item of jewelry.
17. The digital transaction apparatus according to claim 15, wherein the digital transaction device is any one or more of a POS/EFTPOS terminal, an ATM, an internet connected computer or a personal computer.
18. A Digital Transaction Card (DTC) operable to provide data regarding at least one digital transaction to a Data Assistance Device (DAD), the DTC including: a Digital Transaction Processing Unit (DTPU); and a DTC receiver that is operable to receive user-selected data from a transmitter associated with a Data Assistance Device (DAD), wherein the user-selected data that is received causes the DTC to operate in accordance with the user-selected data when the DTC is subsequently used to effect a digital transaction, and wherein the DTC provides data regarding the at least one digital transaction to the DAD and the DAD is operable to record at least one or more details regarding the at least one digital transaction.
19. A computer-readable medium storing one or more instructions that, when executed by one or more processors associated with a Digital Transaction Card (DTC), cause the one or more processors to: receive user selected data, from a Data Assistance Device (DAD); and subsequently effect at least one digital transaction with at least one digital transaction device wherein the DTC operates in accordance with the user-selected data and wherein, upon forming a communications link amongst the DTC, the digital transaction device and the DAD and performing the at least one digital transaction, the one or more instructions cause the DTC to provide data regarding the at least one digital transaction to the DAD and the DAD is caused to record one or more details regarding the at least one digital transaction.
20. A digital transaction apparatus operable to perform at least one digital transaction with at least one digital transaction device, and further operable to record at least one or more details regarding the transaction, the apparatus including: a Digital Transaction Card (DTC), including, a Digital Transaction Processing Unit (DTPU), and a DTC transceiver, the apparatus further including: a Data Assistance Device (DAD), including, a user interface, and a DAD transceiver, and wherein, the DTC provides data regarding the at least one digital transaction to the DAD and the DAD is operable to record one or more details regarding the at least one digital transaction.
Description
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0167] 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:
[0168]
[0169]
[0170]
[0171]
[0172]
[0173]
[0174]
[0175]
[0176]
[0177]
[0178]
[0179]
[0180]
[0181]
[0182]
[0183]
[0184]
[0185]
DETAILED DESCRIPTION
[0186]
[0187] 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.
[0188] In the embodiment shown in
[0189] Similar to a standard EMV device, the DTPU (104) of the embodiment shown in
[0190] 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.
[0191] 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.
[0192] 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.
[0193] 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
[0194] 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).
[0195] 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).
[0196] 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).
[0197] 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: [0198] Check if the nominated storage area (staging memory) contains data (an LDTDP) in a specified format; [0199] 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; [0200] 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; and [0201] 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.
[0202] 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).
[0203] 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.
[0204] 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.
[0205] 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).
[0206] 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.
[0207]
[0208] 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
[0209] 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
[0210] 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.
[0211] The embodiment in
[0212] Similarly, the embodiments described in
[0213] With reference to
[0214] In the embodiment of
[0215] 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
[0216] 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
[0217] In the embodiment of
[0218] 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
[0219] With reference to
[0220] When seeking to change the personality from a VISA card (206) to a MasterCard (208), the user operates the scroll keys of DTC (206a) 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 user interface of DTC (208a) to display and select a Null personality and effect same.
[0221] Each transaction creates several actions (parameters, or data sets/data points), and each action and selection of a transaction can be recorded. For example, a smartphone acting as a Data Assistance Device (DAD) may produce the following data types during, or in a near time proximity of a transaction: [0222] time of the transaction; [0223] GPS location of the Digital Transaction Card (DTC) as recorded by the smartphone; [0224] smartphone security level (logged in via Personal Identification Number (PIN), swipe or other); [0225] biometric authentication level supplied; [0226] random authorization question asked and answered; [0227] the time for which the DTC and DAD were linked; [0228] the token selected for the transaction; [0229] the One-Time-Pin (OTP) (or other password) duration; and [0230] the time that the transaction details were transmitted from the DTC to the DAD.
[0231] Further, the DTC (for example, operating as a credit card) may record a number of data types during a transaction, including: [0232] access time; and [0233] time read by terminal.
[0234] Any or all of the above details regarding a transaction can be recorded as part the transaction recordal.
[0235] In another embodiment, selected transaction details can be uploaded to a server (via an option on the smartphone). If the digital transaction document used in a digital transaction is a credit card/debit card, the selected transaction details can be uploaded to a server operated by the financial institution that is the issuer of the DTC. Passport use recordal may be uploaded to the server of a government agency.
[0236] In embodiments, financial institutions can collect data from a user's DAD across many DTCs used in a user's wallet.
[0237] Big data (which is a term generally accepted to mean extremely large data sets that may be analysed computationally to reveal patterns, trends, and associations, especially relating to human behaviour and interactions) may also benefit by some embodiments of the present invention. For example, appropriate institutions could have access to anonymous data that would be optionally uploaded by each user from an application on their smartphone. The data could be analysed for trends, such as: [0238] the days for which a DTC is used for selected items; [0239] the time for which a DTC is used for selected items; [0240] security levels applied for selected items; [0241] average prices paid for selected items; [0242] the instance of a sale price for selected items (information that is considered valuable by shopping aggregators); [0243] types of items purchased per age group (if user uploads age or age range); and [0244] types of items purchased by smartphone type.
[0245]
[0246] The flow chart starts with the commencement of a the transaction (320) and the next step is checking that the smartphone application has a current log-in (322). It will be understood that a smartphone is an example of a DAD. If the application (app) is current (324) then the process passes through step (328) to the step of recording the data, time, GPS, method of app log-in and any other details (338). However, if the app is not current (326) then the process proceeds to step (330) and requires the user to select a log-in method. The log-in method may be a PIN log-in (332), a swipe log-in (334), or a biometric log-in (336). After the log-in method has been selected the process proceeds to step (338) for recordal.
[0247] After records step (338), the process proceeds to step (340), wherein a DTC may be selected, along with tokens for the DTC and other selectable fields. This selection process for step (340) may be performed with the DAD (for example, a smartphone).
[0248] Following selection of the card (an example digital transaction document), tokens, and other selectable fields in step (340), records are updated with the selection (342), following which the DTC (44) can be used in a transaction with a digital transaction device, such as a Point Of Sale/Electronic Funds Transfer at Point Of Sale (POS/EFTPOS) terminal, or an Automatic Teller Machine (ATM).
[0249] In this example embodiment, the DTC (344) requires biometric authentication of the user before it may be used. The process includes the step of determining whether a biometric has already been verified (346). If the biometric has not already been verified (48), then the user may be directed to use the DTC biometric (352), which could scan a fingerprint on the biometric reader (354). However, if the biometric has already been verified (350), the process proceeds to step (370), wherein a random check of the biometric against an image stored on the DTC is performed.
[0250] Whether the finger is scanned as a biometric (354), or there is a random check of the biometrics which a user's is not verified (372), the process can proceed to step (356) wherein the biometric is verified or re-verified. If the biometric has not been verified or re-verified (358), then a re-attempt may be permitted (362). If the verification or re-verification (356) is successful (360) then the process can proceed to step (376) for updating the DTC with the biometric details. Further, if the random check of the biometric compared with the image stored on the DTC leads to verification (374), the process proceeds to step (376) wherein the DTC is updated with the biometric details.
[0251] With respect to the decision re-attempt regarding whether the (362) has been verified (364), if not (366), then the process proceeds to step (382), wherein the DTC is updated with recorded PIN or swipe used to log into the smartphone app (an application on the DAD). Further, if at step (370) the updating of the DTC with biometric details is not verified (380), this can also result in the process proceeding to step (382), wherein the DTC is updated with the recorded PIN and other details.
[0252] With respect to step (376), if the DTC is updated with biometric details but is verified (378), then the process proceeds to step (384), wherein the records are updated with login and other selectable options. These records may be written to a secure element on the DAD (e.g. smartphone), the DTC (e.g. the card used for the transaction), or could be written to a secure element or other type of memory in an internet connected device, remote from the DTC or the smartphone.
[0253] When the records have been updated and written to memory (384), the user can commence the transaction (386).
[0254] With reference to
[0255] With reference to
[0256] With reference to
[0257] 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.
[0258] For example, the uppermost DTC (414) that is depicted in
[0259] The second DTC (416) that is depicted also represents a card having minimal functionality/connectivity including an EMV device (410) that is either firmware-modified or software enhanced to enable wireless connectivity between the EMV device and a DAD (402), such as Bluetooth and/or NFC, to change the personality of the DTC (416). The DTC (416) also includes an MCU (not shown in
[0260] The third DTC (418) that is depicted in
[0261] The fourth DTC (422) that is depicted in
[0262] As previously described, whilst it is possible to implement embodiments with hardware and firmware that is adapted to enable a DTC comprising a DTPU to adopt one of many available personalities, it is preferable to achieve the results with an existing, certified DTPU, such as a device certified in accordance with the EMVCo specifications, without requiring any alteration to the DTPU or any essential operating firmware. As will be appreciated by skilled readers, avoiding the requirement to certify a newly developed DTPU has the benefit of avoiding a substantial cost associated with the certification process and avoids the substantial delay also associated with such a process.
[0263] Devices such as EMV devices operating with an operating system such as the MULTOS or JavaCard systems allow the secure execution of application software that is installed within the EMV subsystem. EMV subsystems are considered sufficiently secure to allow third party software to be installed and operated within the EMV subsystem subsequent to reissuance of an EMV device since the operating system will prevent any inappropriate alteration of the EMV device secure memory.
[0264] Accordingly, by installing application software in the EMV system that operates to receive commands that are already available and defined according to the current EMV subsystem, additional functionality beyond that provided by standard DTCs can be achieved. In the embodiment(s) described in
[0265] Also depicted in
[0266] The Global Platform API (514) provides an interface to the functionality provided by the Global Platform Standard and in the embodiment depicted in
[0267] The DTC (500) also includes a DTC external processor (524) which effects functions on the DTC (500). In particular, the DTC external processor (524) depicted as a microcontroller unit (MCU), which communicates with the EMV device and this communication arrangement enables the DTC external processor (524), in accordance with commands received by the DAD (526), to update the digital transaction document personalities and the applications residing within the EMV device.
[0268] The EMV device operating system (528) is hardware specific firmware that provides the basic functionality for the EMV device such as secure access to on-card memory storage, authentication and encryption. The operating system (528) includes a sequence of instruction code that resides in non-volatile memory in the EMV device.
[0269] With reference to
[0270] The EMV device of the DTC (500) in
[0271] In the example of
[0272] When multiple single-personality applets are stored in the MCU, Global Platform Standard (GPS) command(s) are sent to the EMV device, for example from a DAD (526) or the MCU, to install the relevant single-personality applet (501) onto the EMV device along with the appropriate command(s) to overwrite any previously installed applet thus changing the personality of the DTC to the personality associated with the applet (501). In this embodiment, the applet could be stored in the MCU secure memory, i.e. secured by hardware (secure element) or secured by software (encryption). The EMV contact plate (not shown in
[0273] When the multiple single-personality applets are stored in a personality section of the EMV device, GPS command(s) are sent to the EMV device, for example from a DAD (526) or the MCU, to transfer the relevant single-personality applet (501) from the secure element of the EMV device and install same thus effecting change to the personality of the DTC to the personality associated with the installed applet (501). In yet another embodiment, the multiple single-personality applets are stored in a DAD (526) and individual applets along with commands are transferred to the MCU (524) of the DTC for subsequent transmission to the EMV device.
[0274] The commands sent from the DTC external processor to the EMV device may be a set of commands that obscure the GPS commands such as make card 2 primary, whereby the external DTC processor sends make card 2 primary to the EMV device, and the EMV device executes the command by decoding the command and obtaining the GPS commands that will have the effect of making the DTC adopt the personality of card 2.
[0275] Each single-personality applet (501) that is stored for subsequent selection and transfer to the EMV device has an associated encryption key (513) used to decrypt the contents of the applet defining the individual personality thus allowing access and/or amendment to parameters pertaining to the individual personality. The function of keys is described in more detail below with respect to the embodiment of
[0276] In the embodiment of
[0277] If there is a preference to concurrently store applets containing one or more personalities in the EMV device, a single applet of the plurality of applets will need to be activated, or made primary, in order to ensure that only one particular personality defined by an applet is read by a network digital transaction device. The reader will appreciate that
[0278] In the example of
[0279] All of the applets (502, 504, 506, 508 and 510) reside within the secure memory of the EMV device of the DTC (500) and in the embodiment depicted in
[0280] In the embodiment of
[0281] In an embodiment, two or more sets of keys may be jointly issued to the DTC for each personality, including for example a first set of keys (530a to 530e) as shown in
[0282] The second set of limited administration keys (not shown) may be stored in the microcontroller unit (MCU) shown in
[0283] With reference to
[0284] Referring again to
[0285] In an embodiment where the MCU to EMV link is secure, encrypted commands are issued from the MCU to the EMV device but continue to invoke multiple Global Platform commands within the EMV device once the command from the MCU is decrypted by the EMV device. This arrangement reduces the quantity and complexity of encrypting and decrypting tasks to effect functions, which in turn, also reduces the overall power usage of the DTC and the time required to effect an action such as a request to change the personality of the DTC.
[0286] In this regard, the MCU sends formatted messages to the System I/O of the EMV device and the Operating System and Java Runtime Environment direct the message to the appropriate applet. In this embodiment, the MCU emulates an EFTPOS and/or ATM network transaction terminal internally on the DTC to effect communications confirming with commands recognised by the EMC device. Whilst the EMV device will receive and execute recognised GPS commands, there is no single command that will ensure that the correct personality is recognised by all network transaction devices. In this regard, network terminals software can interpret the personality stored on a physical card containing multiple personalities in different ways and may not always adopt the personality marked with the primary status. Accordingly, to ensure that a terminal properly interprets and adopts only one of a number of personalities stored in the EMV device, only the desired personality should be marked as active and primary, all other personalities should have a status of inactive. Therefore, according to this embodiment, a number of GPS commands that are usually only used by an entity authorised to issue cards are issued to the EMV device to amend the status of each and every personality stored on the EMV device to ensure that the user selected personality is recognised by any network terminal device in which the DTC may be used to effect a transaction.
[0287]
[0288] According to the protocol layer (602), the MCU (612) communicates according to established protocols with the EMV device (614). In the embodiment of
[0289] With reference to the message exchange layer (604), this layer communicates messages between either a merchant terminal and the EMV device (614) or the MCU (612) and the EMV device (614). The messages for this communication are APDUs. There are two primary categories for APDUs, namely, command APDUs and response APDUs. Effectively, APDU commands are the messaging protocol for communicating with an EMV device (614). The message exchange layer (604) also depicts the external contacts (616) of an EMV device (614). Further, the message exchange layer (604) also depicts an arbitration device (618) which arbitrates communication between the MCU (612) and the EMV device (614) or alternatively, communication that may occur between the EMV contacts (616) and the EMV device (614). As will be appreciated by skilled readers, communication between the EMV device contacts (616) and the EMV device (614) will occur when the DTC is used in a merchant terminal a dipping mode wherein the DTC is inserted into the merchant terminal and contacts within the merchant terminal directly engage with the EMV contacts (616). In this instance, communication between the EMV contacts (616) and the EMV device (614) must be effected without any interference in the communication attempted by another device such as the MCU (612). However, in instances where communication between the MCU (612) and the EMV device (614) is required, the arbitration device (618) effectively disconnects the communication path between the EMV contacts (616) and the EMV device (614) such that communication may be effected between the MCU (612) and the EMV device (614) without interference from any device making contact with the EMV contacts (616). As depicted in
[0290] With reference to the physical (electrical) layer (606), various additional components of the DTC are depicted including a dynamic magnetic stripe module (620), a display driver (622) and a corresponding display screen (624), a battery (626) and a crystal (628) that provides an oscillator that is used to determine the clock signal for all of the electronic devices on the DTC.
[0291] Also depicted in
[0292] Additional elements are also depicted in the physical (electrical) layer (606) including an EMV device antenna (634), an NFC antenna (636) connected to the communications module (610) and a Bluetooth antenna (638) also connected to the communication module (610).
[0293] With reference to
[0294] With reference to
[0295]
[0296] With reference to
[0297] In the event that the data received by the MCU (708) depicted by data flow (710) represents a command requiring the MCU (708) to communicate with the EMV device (712), then the MCU (708) transmits a signal to the arbitration device (714) depicted by data flow (716) to activate the arbitration device (714) to isolate the normal connection between the EMV device contacts and the EMV device (712). Further, in addition to isolating the normal communication between the EMV device contacts and the EMV device (712), the arbitration device (714) activates connection between the MCU (708) and the EMV device (712).
[0298] Once the arbitration device (714) has been activated to enable communication between the MCU (708) and the EMV device (712), the MCU (708) transfers data as depicted by data flow (718) to the EMV device (712). In the instance of the command issued by the mobile device (700) to effect a change in personality of the DTC, the EMV device (712) upon receiving and altering the EMV device (712) personality, in accordance with data provided as depicted by data flow (718), the EMV device (612) provides a return signal as depicted by data flow (720) to the MCU (708) confirming that the change in personality of the EMV device (712) has been effected. Once required communication between the EMV device (712) and the MCU (708) has been completed, the arbitration device (714) may restore communication between the EMV device (712) and the EMV device contacts.
[0299] At this point in time, the MCU (708) transmits a further signal to the arbitration device (714) to restore the normal communication between the EMV device contacts and the EMV device (712) and at the same time isolating the communication path between the MCU (708) and the EMV device (712). This signal is depicted in
[0300] At this stage, the MCU (708) generates and transmits a signal to the communications module (706) as depicted by data flow (724), said signal being a signal confirming the alteration of the EMV device (712) personality according to the instruction initiated at the user's mobile device (700). The communications module (706) upon receiving the signal (724) converts the signal for wireless transmission to the mobile device (700), the wireless signal depicted as data flow (726).
[0301] The user's mobile device (700) receives the wirelessly transmitted signal (726) and upon conversion of that wireless signal, the user's mobile device (700) internally processes the signal (726) and provides a visual indication to the user on the user interface of the mobile device (700) confirming the requested change in personality of the EMV device (712) and that the DTC will now operate according to the personality of the card requested by the user.
[0302] With reference to
[0303] With reference to
[0304] In this regard, the provision of an external contact plate (804) and an internal contact plate (806) is an artefact of the manufacturing process for digital transaction cards that include an EMV device (800). In embodiments of the present invention that include both an external contact plate (804) and an internal contact plate (806), the opportunity exists to route electrical connections between the external contact plate (804) and the internal contact plate (806) in an arrangement other than a direct one to one connection between corresponding electrodes of the external contact plate (804) and the internal contact plate (806).
[0305] With specific reference to
[0306] In order to provide a direct connection between counterpart electrodes of the external contact plates (804) and the internal contact plates (806), the arbitration device (807) operates to connect electrodes identified as GND (808), Vcc (810), RST (812), CLK (814), I/O (816) and the blank terminal (818) such that all are connected respectively to their counterpart connection of the internal contact plate (806) such that the aforementioned electrodes of the external contact plates (804) would be connected respectively to GND (820), Vcc (822), RST (824), CLK (826), I/O (828) and blank terminal (830).
[0307] Accordingly, when in an appropriate state, the arbitration device (807) would operate to connect the individual electrodes of the external contact plate (804) directly to their counterpart terminal of the internal contact plate (806) which in turn are connected to the appropriate connection points of the EMV device (800) to enable the EMV Device (800) to operate with digital transaction devices. In this configuration, the EMV device (800) would operate normally with digital transaction devices interfacing with individual electrodes of the external contact plate (804) and any electrical signals applied to any one of the external contact plate (804) electrodes, namely, GND (808), Vcc (810), RST (812), CLK (814), I/O (816) and blank terminal (818) would pass through the external contact plate (804) electrode through the arbitration device (807) and pass directly to the counterpart electrode of the internal contact plate (806) namely, GND (820), Vcc (822), RST (824), CLK (826), I/O (828) and blank terminal (830).
[0308] However, in instances where communication between an MCU (802) and the EMV device (800) is required, the arbitration device (807) adopts an alternative state and connects the data and control signal lines of the MCU (802) through the arbitration device (807) to the individual electrodes of the internal contact plate (806) which in turn are connected to the appropriate I/O and control lines of the EMV device (800). Accordingly, the arbitration device (807) in the embodiment graphically represented in
[0309] Operationally, when implementing the embodiment depicted in
[0310] With reference to
[0311] With reference to
[0312] Similarly, in the embodiment of
[0313] With reference to
[0314] In yet a further embodiment,
[0315] With reference to
[0316] Of course, in the embodiment of
[0317] When seeking to develop a Digital Transaction Card that is operable with an existing digital transaction network infrastructure, it is preferable that the Digital Transaction Card is operable to communicate with devices already present within an existing network infrastructure according to the communication capabilities and protocols recognised and established for devices in that network. In this regard, merchant terminals, and other devices such as Automatic Teller Machines, that presently exist in established digital transaction networks provide communication facilities between credit cards and devices according to the standards developed for Near Field Communications, physical contact with the EMV device contacts of a credit card and by swiping and reading the magnetic stripe on the rear face of a credit card. Accordingly, when seeking to provide a Digital Transaction Card operable with an existing transaction network yet including additional functionality, it is preferable to provide a Digital Transaction Card that is operable with an existing digital transaction network according to the current protocol standards and interfaces. As a result, it is preferred to provide a DTC that also has the capability to be used with a merchant terminal that relies upon the use of the magnetic stripe and as a result, in an embodiment of the invention, the DTC is provided with a dynamic magnetic stripe that is controlled by the magnetic stripe component (732) as depicted in
[0318] In this regard, since the DTC according to an embodiment of the invention is operable to adopt any one of a number of personalities that may be selected and activated by a user, the magnetic stripe on the rear face of the Digital Transaction Card requires a magnetic stripe that may be configured according to the personality of the Digital Transaction Card at any particular point in time. Accordingly, the MCU (802) is provided with a data connection with the magnetic stripe component (732) as depicted in
[0319] Further, since the Digital Transaction Card according to the embodiment of the invention depicted in the Figures may include a display, the MCU (802) is provided with direct connection with the display module (734) as depicted in
[0320] A Digital Transaction Card according to an embodiment of the invention provides a user with the ability to combine various Digital Transaction Cards onto a single card with the ability to select and activate any one of the various personalities that are stored on the card at any particular point in time for the purpose of effecting a transaction. Further, according to the embodiments depicted herein, the Digital Transaction Card is operable according to all of the available protocols and interfaces that presently exist in established digital transaction networks and therefore, a Digital Transaction Card according to an embodiment described in the present specification can be used with existing digital transaction networks anywhere in the world. This is particularly important for countries in which the installed digital transaction network includes devices that have yet to be upgraded to communicate with Digital Transaction Cards according to NFC capabilities and may be restricted to either direct physical contact with the EMV device contact plate or use of the magnetic stripe which may be prevalent in countries that are considered to fall within the category of developing nations. Further, even in developed nations wherein the existing digital transaction network infrastructure includes many terminals that have NFC communication capabilities, many consumers have not yet elected to adopt the E-Wallet services offered by many commercial operators since their mobile phone or smartphone device does not have NFC communication capabilities. In order to use the presently offered E-Wallet commercial services, it is necessary to implement those services on a smartphone that includes NFC communication facilities. Of course, a Digital Transaction Card according to an embodiment described in the present specification may communicate with any device that incorporates a Bluetooth communications facility which includes many older generation smartphones and hence, according to an embodiment of the invention, a user may select and activate a particular personality for a Digital Transaction Card by selecting and activating that personality on their smartphone equipped solely with Bluetooth communication facilities and communicate that instruction to a Digital Transaction Card according to established Bluetooth communication protocols. Having selected and activated a particular personality for their Digital Transaction Card using Bluetooth communication facilities, the Digital Transaction Card may be used to effect a transaction with an existing digital transaction network according to any of the currently available protocols and interfaces including magnetic stripe and physical contact with the EMV device contact plate.
[0321] TABLE 1 is a chart of the aforementioned DTC embodiments (414, 416, 418 and 422) depicted in symbol signifies that a feature is present, and the cross x symbol signifies that a feature is not present.
TABLE-US-00001 TABLE 1 Software-Enhanced (Java EMV with applet) EMV Device having Modified MCU with MCU with Contactless NFC Bluetooth Scroll/ Comms Comms Comms Card Enter Embodiment Capability MCU Capability Capability Battery Display Keys 414 x x x x x x 416 x
x
x x 418 x
x 4/8 Active Matrix 422 x
4/8 Active Matrix
indicates data missing or illegible when filed
[0322] In the first embodiment in TABLE 1, the DTC (414) requires the use of a Data Assistance Device (DAD) with a modified NFC capability such as a smartphone to communicate data and commands to an applet associated with the EMV device that can establish a secure session between the NFC-enabled DAD and the DTC via a contactless interface. In this regard, the DAD requires an application that establishes a secure session with the DTC. Data sent via the secure session includes APDU packets containing commands, for example Global Platform Commands, or APDU packets containing commands that authorize a management applet on the EMV device to send Global Platform Commands to applets containing card personalities. The commands sent to the management applet may include a sequence of commands to install a new personality or to change an operational parameter or status of an existing personality. DTC (414) further requires software encryption to isolate the EMV external contact plate, as described above with reference to
[0323] DTC (416) also requires the use of a Data Assistance Device (DAD), such as a smartphone, to communicate data and commands to an applet associated with the EMV device that can establish a secure session between the NFC-enabled DAD and the DTC via a contactless interface. The difference between DTCs (414) and (416) is that DTC (416) includes an MCU that can accept wireless communication (e.g. NFC), and can accept a secure session between the DAD and the DTC containing the MCU. The application on the DAD creates a secure session with the MCU within the DTC and data sent via the secure session includes APDU packets containing commands, for example Global Platform Commands, where the MCU forwards the commands to the EMV applet. DTC (416) may further include software encryption to isolate the EMV external contact plate, but also allows hardware encryption involving physical isolation of the EMV contact plate as described above with reference to
[0324] DTC (418) also requires the use of a Data Assistance Device (DAD), such as a smartphone, to communicate data and commands to an applet associated with the EMV device that can establish a secure session between an NFC or Bluetooth enabled DAD and the DTC via a contactless interface. DTC (418) includes an MCU that can accept wireless communication (e.g. Bluetooth and NFC), and can accept a secure session between the DAD and the DTC containing the MCU. The application on the DAD creates a secure session to the MCU within the DTC and data sent via the secure session includes APDU packets containing commands, for example Global Platform Commands, where the MCU forwards the commands to the EMV applet. In addition, DTC (518) is configured to accept commands that authorize the MCU to send APDU packets containing commands, for example Global Platform Commands, to amend parameters pertaining to a personality. DTC (518) may further include software encryption to isolate the EMV external contact plate, or hardware encryption involving physical isolation of the EMV contact plate as described above with reference to
[0325] When using DTC (422), 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. In any event, the DAD is necessary to initially set up the card and download/store multiple personalities, but subsequent to the initial setup, the card itself may be used to change the operational parameters of a card's personality using the scroll/enter keys (426). The DTC (422) contains an applet, and an MCU that can accept wireless communication (e.g. Bluetooth or NFC), a secure session between the DAD and the DTC containing the MCU (i.e. during the initial setup), and a secure session between the MCU and the EMV for subsequent amendments to the parameters of a personality involving transfer of data between the MCU and EMV (applet or management applet). The MCU is programmed to accept commands from a local interface, which may for example include the scroll/enter keys (426), and convert the keystrokes into commands. The application on the DAD creates a secure session with the MCU within the DTC during the initial setup of the DTC (422) and data sent via the secure session includes APDU packets containing commands, for example Global Platform Commands, where the MCU is authorised to forward the commands onto the EMV applet. In an alternative embodiment, data that is sent via the secure session will consist of commands that authorize the MCU to send APDU packets containing commands to a management applet on the EMV device. The Management applet then sends commands (for example global platform commands) to effect an amendment to an operational parameters or status to the appropriate applet. When the scroll/enter keys (426) are used to change the personality of the DTC (422), transmission is authorized by the local interface that authorizes the MCU to send APDU packets containing authorization commands to either the Management app or Global Platform Commands to the applet containing the card personality/personalities. DTC (422) may further include software encryption to isolate the EMV external contact plate, or hardware encryption involving physical isolation of the EMV contact plate as described above with reference to
[0326] DTC (422) 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. In addition, less time is required to effect updates or changes (i.e. changes to status/updates), minimal amounts of data is 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 (422) has a higher production cost and due to its complexity may have a higher propensity to fail.
[0327] Table 2 is a chart of the abovementioned DTC embodiments (414, 416, 418 and 422) when the EMV device associated with the DTC is firmware-modified, detailing the combination of features that are present in each embodiment. Again, the symbol signifies that a feature is present, and the 4c 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-US-00002 TABLE 2 Firmware-Modified EMV Device EMV Device Multiple Multiple having Personalities Personalities Modified for Single for Multiple MCU with MCU with Contactless Card Card NFC Bluetooth Scroll/ Comms Association Association Comms Comms Card Enter Embodiment Capability Scheme Schemes Capability Capability Display Keys 414
x x x x x 416 x x x
x x x 418 x
x 4/8 Active Matrix 422 x
4/8 Active Matrix
indicates data missing or illegible when filed
[0328] In the first embodiment in TABLE 2, the DTC (414) 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 (414) 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 Card Association Scheme and low cost and low propensity to fail since the DTC (414) does not include an MCU, display or scroll/enter keys.
[0329] The firmware-modified DTC (416) 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 (414) and (416) is that DTC (416) 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 (416) 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 Card Association 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.
[0330] DTC (418) in TABLE 2 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 (418) 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 (418) 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 (418) including an MCU and display (420) there is a higher cost associated with production of DTC (418) as compared with DTC (414) and (416).
[0331] When using the DTC (422) described in TABLE 2, 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 (426). 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 (426), and convert the keystrokes into commands. When the scroll/enter keys (426) are used to change the personality of the DTC (422) 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.
[0332] DTC (422) 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 (422) has a higher production cost and due to its complexity may have a higher propensity to fail.
[0333] 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.
[0334] 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.
[0335] 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.