Battery life estimation
11580527 · 2023-02-14
Assignee
Inventors
Cpc classification
G01R31/382
PHYSICS
G06Q20/204
PHYSICS
G06Q20/341
PHYSICS
International classification
G06Q20/34
PHYSICS
G06Q20/10
PHYSICS
G01R31/36
PHYSICS
G01R31/382
PHYSICS
Abstract
Digital transaction 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 digital transaction apparatus further includes a remaining battery life estimation system operable to detect an occurrence of at least one electrical event and to measure the duration of the at least one electrical event, each electrical event having an associated power usage amount, and, subsequent to detection of an occurrence of an at least one electrical event, the remaining battery life estimation system calculates the total energy usage using the associated power usage amount in respect of the at least one electrical event and the duration of the at least one electrical event.
Claims
1. A digital transaction apparatus comprising: a Data Assistance Device (DAD), including: a user interface that is operable to at least select data, a data output device, and a DAD transmitter; and a Digital Transaction Card (DTC), including: a Digital Transaction Processing Unit (DTPU), and a DTC receiver, wherein the DAD and DTC are configured to transfer data, comprising selected data, from the DAD to the DTC, and the DTC being further configured to effect a digital transaction, based on the DTC operating in accordance with the selected data and transferred from the DAD to the DTC, and wherein the digital transaction apparatus further comprises: a remaining battery life estimation system implemented using the DTC and/or the DAD operating with the DTC, configured to detect an occurrence of at least one electrical event in the DTC and further configured to measure the duration of the at least one electrical event, each at least one electrical event being predetermined and associated with a predetermined nominal energy usage amount specified for at least one component of the DTC and recorded and stored in a data repository in the remaining battery life estimation system, and, based on detection of an occurrence of at least one electrical event in the DTC, the remaining battery life estimation system calculates the total energy usage in the DTC by using the associated predetermined nominal energy usage amount for at least one component of the DTC in respect of the at least one electrical event and the measured duration of the at least one electrical event in the DTC.
2. The digital transaction apparatus according to claim 1, wherein the DTC is configured to, in response to receiving the transferred data, operate according 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 wherein the DTC is configured to, based on receiving the transferred data, change a current personality of the DTC to a selected personality from the one or more selectable personalities; and wherein the DAD is configured to receive, by the DAD and by operation of the DAD user interface, an instruction to change the current personality of the DTC to the selected personality; transmit, by the DAD transmitter to the DTC receiver, data related to the selected personality; and the DTC is configured for, based on receiving the transferred data, implementing, in the DTC, a change from the current personality to the selected personality in accordance with the transferred data such that when the DTC operates with a digital transaction device to effect the digital transaction, the DTC operation indicates the selected personality to the digital transaction device.
4. The digital transaction apparatus according to claim 2, wherein data related to the plurality of selectable personalities is stored on the DTC, and wherein the DAD is configured for: receiving, by the DAD, and by operation of the DAD user interface, an instruction to change a current personality of the DTC to a selected personality from the one or more selectable personalities; transmitting, by the DAD transmitter to the DTC receiver, the instruction to change the current personality of the DTC to the selected personality; and the DTC being further configured for 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 DTC operation indicates the selected personality to the digital transaction device.
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 a plurality of selectable personalities and stored on the DTC, and the DTC is configured for individually selecting a personality from the plurality of personalities by operation of the DTC user interface.
9. The digital transaction apparatus according to claim 8, wherein the DTC is configured for, based on receiving the transferred data, implementing, in the DTC, a change from the current personality to the selected personality, and 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 DTC operation indicates the selected personality to the digital transaction device.
10. The digital transaction apparatus according to claim 7, wherein the DTC user interface includes scroll keys and a display, and wherein the DTC is configured to, in response to user input received via the scroll keys, select a personality from a plurality of personalities and to display information via the display that indicates the selected personality.
11. The digital transaction apparatus according to claim 1, wherein the DTC comprises a processor, external to the DTPU, configured for receiving the data transferred from the DAD and storing the transferred data in memory storage.
12. The digital transaction apparatus according to claim 1, wherein the DTC includes a display and the DTC is configured for displaying information via the display.
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 EMV device, responsive to executing the firmware, receives and executes an expanded set of commands that, when executed, writes 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 and communicates 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) comprising: a Digital Transaction Processing Unit (DTPU); and a DTC receiver and a processor that is configured to receive user-selected data from a transmitter associated with a Data Assistance Device (DAD), wherein the DTC is configured to operate in accordance with the received user-selected data to effect a digital transaction, and wherein the DAD and/or the DTC includes: a remaining battery life estimation system implemented using the DTC and/or the DAD operating with the DTC, and configured to detect an occurrence of at least one electrical event in the DTC and to measure a duration of the at least one electrical event in the DTC, each electrical event being predetermined and associated with a predetermined nominal energy usage amount specified for at least one component of the DTC recorded and stored in a data repository in the remaining battery life estimation system, and based on detection of an occurrence of at least one electrical event in the DTC, the remaining battery life estimation system calculates the total energy usage in the DTC by using the associated predetermined nominal energy usage amount for at least one component of the DTC in respect of the at least one electrical event and the measured duration of the at least one electrical event in the DTC.
19. A remaining battery life estimation apparatus, comprising: a data output device; memory; a computer-readable medium storing one or more instructions; and a processor, operably connected to the data output device, the memory, and the computer-readable medium, which is configured to, based on operations according to the processor executing the one or more instructions, detect an occurrence of at least one electrical event in an electronic device by the processor receiving a data signal from the electronic device, the electronic device being configured to effect a digital transaction, each at least one electrical event being predetermined and associated with a predetermined nominal energy usage amount specified for at least one component of the electronic device and recorded and stored in a data repository in the remaining battery life estimation apparatus, and measure, by the processor receiving at least one data signal from the electronic device, a duration of the at least one electrical event in the electronic device, and based on detection of an occurrence of the at least one electrical event in the electronic device, the remaining battery life estimation apparatus calculates, based on operations according to the processor executing the one or more instructions, the total energy usage in the electronic device by using the associated predetermined nominal energy usage amount in respect of the at least one electrical event for at least one component of the electronic device and the measured duration of the at least one electrical event in the electronic device; and couple information based on the calculated total energy usage to the data output device.
20. A remaining battery life estimation apparatus including comprising: a data output device; memory; a computer-readable medium storing one or more instructions; and a processor, operably connected to the data output device, the memory, and the computer-readable medium, which is configured to, based on operations according to the processor executing the one or more instructions, detect an occurrence of at least one electrical event in an electronic device by the processor receiving a data signal from the electronic device, the electronic device being configured to effect a digital transaction, each at least one electrical event being predetermined and associated with a predetermined nominal energy usage amount specified for at least one component of the electronic device and recorded and stored in a data repository in the remaining battery life estimation apparatus, and based on detection of an occurrence of the at least one electrical event in the electronic device, the remaining battery life estimation apparatus calculates, based on operations according to the processor executing the one or more instructions, the total energy usage in the electronic device by using the associated predetermined nominal energy usage amount in respect of the at least one electrical event for at least one component of the electronic device; and couple information based on the calculated total energy usage to the data output device.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) 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:
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
DETAILED DESCRIPTION OF THE EMBODIMENT(S) OF THE INVENTION
(20)
(21) 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.
(22) In the embodiment shown in
(23) Similar to a standard EMV device, the DTPU (104) of the embodiment shown in
(24) 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.
(25) 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.
(26) 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.
(27) 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
(28) 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).
(29) 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).
(30) 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).
(31) 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.
(32) 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).
(33) 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.
(34) 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.
(35) 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).
(36) 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.
(37)
(38) 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
(39) 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
(40) 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.
(41) The embodiment in
(42) Similarly, the embodiments described in
(43) With reference to
(44) In the embodiment of
(45) 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
(46) 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
(47) In the embodiment of
(48) 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
(49) With reference to
(50) 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.
(51)
(52) The DTC (350) has a battery (351) and a DTPU (357), where the latter may be an EMV chip or a chip complying with one or more of the EMV Co specifications. The DTC also has a processor (352), which is external to the processing unit in the DTPU, and the external processor (352) may be operating its own firmware or own version of firmware for control of the DTC operations outside of the DTPU (357). The DTC may also include other components such as a transceiver (360) (this may be an NFC transceiver or a Bluetooth™ transceiver, or some other transceiver infrastructure and protocol.) The DTC also includes an inductive coil which is used for NFC type communications. The DTC may also include a display (354) for displaying simple alphanumeric information, such as card numbers (or unique IDs for other types of digital transaction documents), error messages and the like.
(53) Additional elements are also depicted in DTC (350) including an electrodes (or external contacts) (358) and display driver (355).
(54) The DAD (smartphone) (301) includes a user interface (302), which may be a touch screen operable with soft buttons, and may include physical buttons elsewhere on the device (301).
(55) The digital transaction system (300) is operational to perform financial digital transactions in cooperation with a digital transaction device, such as a Point Of Sale/Electronic Funds Transfer at Point Of Sale (POS/EFTPOS) terminal, an Automatic Teller Machine (ATM), or another type of transaction terminal. The digital transaction system may also be operational to perform non-financial transactions with other types of digital transaction device, for example, age identification transactions with a digital transaction device adapted to read age identification cards. It will be appreciated that the DTC, in coordination with the smartphone is able to take on the “personality” of a number of digital transaction documents, including credit cards, debit cards, passports, and age identity cards.
(56) It will be appreciated that to facilitate the function for change of personality, along with other functions, the DTC requires a power source. As mentioned, the DTC (350) includes a battery (352) (which may be a rechargeable or non-rechargeable battery). In the example, the DTC has a display (356), however, the display is not suitable for displaying relatively complex information about the battery status and battery usage. Instead, the DTC operates with the smartphone, and the smartphone is suitable for displaying the battery status and/or battery usage information.
(57) The DTC further includes a Digital Transaction Processing Unit (DTPU) (358), which may be an EMV chip (where EMV is an abbreviation for Europay, MasterCard, and Visa) or a chip complying with one or more of the EMV Co specifications. The DTC also has a processor (354), which is external to the processing unit in the DTPU, and the external processor (354) may be operating its own firmware or own version of firmware for control of the DTC operations outside of the DTPU (358). The DTC may also include other components such as a transceiver (360) (this may be a Near Field Communication (NFC) transceiver or a Bluetooth™ transceiver, or some other transceiver infrastructure protocol. The DTC also includes an inductive coil (362), which may be used for NFC type communications. The DTC may also include a display (356) for displaying simple alphanumeric information, such as card numbers, error messages and the like—as mentioned above, the display is not suitable for showing more complex information, such as battery usage, which may include charts indicating percentages and other detailed information.
(58) All the DTC components consume power (or energy) while functioning, and require a power source, namely battery (352). A user will benefit from knowing the likely effective operational life expectancy of the battery (including likely remaining charge for a rechargeable and non-rechargeable battery, and likely remaining number of recharge cycles for a rechargeable battery). If the DTC were to cease functioning due to battery discharge, the user of the DTC may be inconvenienced. Accordingly, the DTC is adapted to record a number of details regarding the usage of the battery into its on-board memory, whether that usage is authorized (legitimate) usage or unauthorized (illegitimate) usage. It will be appreciated that both legitimate and illegitimate usage of the DTC contribute to energy discharge, and shortening the expected life of the battery.
(59) The usage of the DTC, in this embodiment, is recorded for each component as an event. The event recordal includes identification of the component of the DTC, identification of the event type operating on the component, along with duration of the event. Each event (or each event type for each component) has an associated nominal power usage amount, which is predetermined and recorded into a database or other data repository for access when calculating battery usage. The system is operational to use the recorded event information and the predetermined power usage amount to calculate the battery usage for the event, and then to calculate the total battery usage.
(60) It will be understood that the system (300) can calculate and record total battery usage for a non-rechargeable battery, and is thus enabled to indicate likely remaining life of the non-rechargeable battery. However, in this embodiment the DTC battery (352) is a rechargeable battery, and the system (300) is operable to record total battery usage so as to indicate, and is thus enabled to indicate likely remaining charge life for a recharge cycle. However, the system is also operable to record a grand total battery usage, and is thus enabled to indicate likely remaining life of the rechargeable battery (or the number of recharge cycles remaining before the battery is likely to stop operating or to start operating at below acceptable performance).
(61) In this embodiment, the DTC (350) records the usage (events, event types, components, and durations) into its memory. The DTC and smartphone (301) are able to link with each other for secure data transfer therebetween, such that the usage data is transferred to the smartphone. The usage data transferred to the smartphone can be deleted from the DTC (350), so that the DTC can record next usage data into its memory. It will be appreciated that the DTC may have limited memory capacity.
(62) In the embodiment described, the smartphone includes a software application, which operates with the DTCs collected usage data, and obtains corresponding associated nominal power usage amounts for the usage data.
(63) In an example scenario, the usage data may include a record indicating that the DTPU (358) was used for a transaction event (for example, a payment transaction with a digital transaction device, such as an POS/EFTPOS terminal), and the transaction event had a duration of 340 milliseconds. The corresponding associated nominal power usage amount for a transaction event using the DTPU is predetermined to be 5 milliwatts. The application on the smartphone will thus calculate the energy usage to be 0.000000472 Watthours. This usage amount, along with other usage amounts for other events, is added to a total usage recorded on the smartphone. Alternatively, the total usage can be recorded onto the DTC, or could be uploaded to another entity in the internet cloud. Further, this usage amount, along with other usage amounts for other events, is added to a nominal grand total usage also recorded on the smartphone (or elsewhere).
(64) The smartphone (301) is able to indicate to a user the amount of charge likely left on the battery for the particular charge cycle by comparing the total usage with an expected available total usage. The expected available total usage may be specified, for example, by the battery manufacturer, and can be recorded into a database or other data repository accessible by the smartphone. In some embodiments, the expected amount of charge left for each recharge cycle may diminish as the battery ages. The aging could be determined by a recorded date of inception for the battery, or by the grand total usage.
(65) The smartphone (301) is also able to indicate to a user the remaining life of the battery (the total number of expected recharge cycles remaining for the battery) by comparing the grand total usage (the usage of the battery across all previous recharge cycles and the present recharge cycle) with an expected available grand total usage. Again, the expected available grand total usage may be specified, for example, by the battery manufacturer, and can be recorded into a database or other data repository accessible by the smartphone. In an alternative embodiment, rather than the DTC recording the event duration for each event, the DTC can record the event solely by identifying the component used and the event type. Correspondingly, the predetermined associated nominal usage amounts are energy usage amounts (predetermined expected power over a predetermined expected time period for each event type), rather than power usage amounts. In such an embodiment, the calculation includes adding all the associated energy usage amounts corresponding to the recorded events (event type and component) to determine a total usage amount.
(66) As shown in
(67) Column headings in (362) show example information which can be recorded for the events or operations of components, including: whether an event or operation of a component is “authorised” (364), the “start_time” (365), the “finish_time” (366), the “time_length” (367) (difference between the “finish_time” (366) and “start_time” (365), otherwise referred to as the duration of an event, the “voltage” used from the power source (368), another “miscellaneous” value (369), the “GPS_location” (370), the time of unauthorized usage (371), the average time of unauthorized usage (372), the total time of unauthorised usage (373), “remaining_time” (374), “start_voltage” (375), “cur_voltage” 376 and “tot_value” (377).
(68) An application executing on the smartphone (301) may upload the battery status, which may be derived from the record (362) of battery usage. This may be displayed in screen section (304). The smartphone (301) can also display in another area of the screen (306), the battery life remaining as a percentage. The smartphone (301) can also display in screen area (306) whether there has been any unauthorised usage, for example one unauthorised NFC usage.
(69) Further, the user of the smartphone may optionally prefer to send data about battery usage to a third party. The data (363) may include battery time used, battery time remaining, voltage, battery usage details, transaction locations, transactions details, unauthorised usage and unauthorised usage details. The information (363) can be sent to, for example, an issuing financial institution (395), being the institution that issued the DTC, or the institution that issued the digital transaction document running on the DTC.
(70) With reference to
(71) With reference to
(72) With reference to
(73) 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.
(74) For example, the uppermost DTC (414) that is depicted in
(75) 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
(76) The third DTC (418) that is depicted in
(77) The fourth DTC (422) that is depicted in
(78) 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.
(79) 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.
(80) 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
(81) Also depicted in
(82) The Global Platform API (514) provides an interface to the functionality provided by the Global Platform Standard and in the embodiment depicted in
(83) 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.
(84) 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.
(85) With reference to
(86) The EMV device of the DTC (500) in
(87) In the example of
(88) 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
(89) 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.
(90) 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.
(91) 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
(92) In the embodiment of
(93) 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
(94) In the example of
(95) 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
(96) In the embodiment of
(97) 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
(98) The second set of limited administration keys (not shown) may be stored in the microcontroller unit (MCU) shown in
(99) With reference to
(100) Referring again to
(101) 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.
(102) 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.
(103)
(104) According to the protocol layer (602), the MCU (612) communicates according to established protocols with the EMV device (614). In the embodiment of
(105) 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
(106) 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.
(107) Also depicted in
(108) 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).
(109) With reference to
(110) With reference to
(111)
(112) With reference to
(113) 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).
(114) 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.
(115) 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
(116) 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).
(117) 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.
(118) With reference to
(119) With reference to
(120) 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).
(121) With specific reference to
(122) 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).
(123) 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).
(124) 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
(125) Operationally, when implementing the embodiment depicted in
(126) With reference to
(127) With reference to
(128) Similarly, in the embodiment of
(129) With reference to
(130) In yet a further embodiment,
(131) With reference to
(132) Of course, in the embodiment of
(133) 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
(134) 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
(135) 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
(136) 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.
(137) TABLE 1 is a chart of the aforementioned DTC embodiments (414, 416, 418 and 422) depicted in
(138) 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
(139) 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
(140) 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
(141) 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
(142) 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
(143) 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.
(144) 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 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.
(145) TABLE-US-00002 TABLE 2 Firmware-Modified EMV Device EMV Device Multiple Multiple having Personalities Personalities MCU Modified for Single for Multiple MCU with Contactless Card Card with 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
(146) 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.
(147) 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.
(148) 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).
(149) 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.
(150) 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.
(151) 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.
(152) 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.
(153) 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.